sexta-feira, 27 de março de 2020

Multiplas SSHs Key para Repositórios Git

As vezes precisamos de mais de uma chave SSH para podermos acessar repositórios Git com usuários diferentes, como por exemplo seu usuário pessoal e o usuário do trabalho. 

       Se os projetos estiverem no mesmo repositório a configuração é um pouco diferente; se forem em locais difetentes: GitHub, GitLab, BitBucket, etc,  é mais simples.

       Vamos começar. A primeira parte é igual, não importa se os projetos estão em um mesmo repositório ou não, que é a geração da chave.

Estamos assumindo que você já possui uma chave configurada para um usuário e quer criar a segunda chave SSH. Então, vamos começar executando o git-bash, um terminal Linux para o Windows que também faz parte da instalação do Git. Após aberto o git-bash, digite:

ssh-keygen -t rsa -b 4096 -C "seu-email-outro-usuario@aqui.com"

Você será indagado sobre onde salvar a chave, sendo que não podemos criar a chave SSH no caminho e nome default, pois já existe uma chave SSH lá. Mude o caminho ou o nome do arquivo, por exemplo, acrescentando .ssh/id_rsa_trabalho no final do nome da chave. Continue a geração, entrando com a senha e confirmando:

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Caso não queira informar uma senha, pode apenas confirmar sem digitar nada (é recomendado criar uma senha, claro!). Então o prompt lhe informa que a sua chave privada e a sua chave publica estão no caminho indicado previamente, que se for o default é: C:\Users\seu-usuario\.ssh.

Copie e adicione sua chave pública à sua conta no repositório, o comando abaixo copia sua chave para a memória e deixa pronto para colar no lá:

clip < ~/.ssh/id_rsa_trabalho.pub

Nesse momento temos a nossa segunda chave SSH, precisamos configurar quando usar cada uma. Para isso, dentro do diretório do C:\Users\seu-usuario\.ssh que é onde ficam as chaves por padrão, crie um arquivo chamado config. Nesse arquivo vamos configurar o acesso a cada repositório por uma chave.

      Segue o exemplo de um arquivo para acessar o GitHub e o Bitbucket com usuários diferentes, e o bitbucket sendo acessado através da nossa nova chave:

Host bitbucket.org
    HostName bitbucket.org
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa_trabalho

Host github.com
    HostName github.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa


Pronto! Se você queria acessar projetos em repositórios diferentes com chaves diferentes sua máquina já está configurada, basta clonar normalmente seus projetos.

     Agora se você quer acessar com duas chaves no mesmo repositório, precisamos do pulo do gato. Já viu que quando vai clonar um projeto seu a URL é mais ou menos assim:

git@github.com:GbDanielO/p-calendar-ptbr.git

      Veja que vem o nome do repositório, como no destaque, depois o nome do projeto. Vamos usar isso pra diferenciar qual chave usar, mas ao invés de separar por ":" vamos separar por "traço". Vamos imaginar que a nossa url fosse: git@github.com:trabalho/p-calendar-ptbr.git. Você precisa fazer dessa forma:


Host github.com-trabalho
    HostName github.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa_trabalho

Host github.com
    HostName github.com
    PreferredAuthentications publickey

    IdentityFile ~/.ssh/id_rsa

       Note que o HostName é igual para as duas configurações, o que muda é o Host, que identifica qual chave usar. ATENÇÃO! Agora com essa mudança, sua forma de fazer o clone do projeto no repositório trabalho mudou. O outro acesso continua como antes.

       Ficará dessa forma:

git clone git@github.com-trabalho:trabalho/p-calendar-ptbr.git

       Pronto, no demais é tudo igual.




Fonte:
https://superuser.com/questions/366649/ssh-config-same-host-but-different-keys-and-usernames
https://backefront.com.br/diferentes-sshkey-mesmo-computador/
https://victortorres.net.br/2018/12/03/mais-de-uma-chave-ssh-no-git 



sexta-feira, 6 de março de 2020

E se eu tiver o persistence.xml e o hibernate.cfg.xml na mesma aplicação?

    As vezes existem projetos legados que usam a implementação do hibernate diretamente ao invés do JPA, e pode ser de interesse passar a usar a especificação ao invés da implementação diretamente. Porém nem sempre isso pode ser feito de uma vez: imagine um aplicação que usa muita criteria do hibernate.

    Nesse caso, você pode criar um arquivo persistence.xml e dentro dele chamar o arquivo do hibernate para aproveitar as configurações do arquivo que já existe, isto é possível através da seguinte propriedade dentro do persistence.xml:


<property name="hibernate.ejb.cfgfile" value="/hibernate.cfg.xml"/>

sexta-feira, 28 de fevereiro de 2020

Configurando Context-Params no Tomcat

    É comum um aplicação precisar de parâmetros de contexto para algumas definições, e nesse artigo vou mostrar como fazer isso no Tomcat 7. Em outras versões pode mudar um pouco mas o princípio é o mesmo para criar os parâmetros e para lê-los.

    No Tomcat, a pasta conf tem dentro dela arquivos de configuração, entre eles o context.xml. Nesse arquivo criamos configurações como o DataSource e parâmetros que podem ser acessados pela aplicação.

    Nesse arquivo, podemos criar parâmetros de duas formas:
  
<Environment name="nomeEmpresa" value="Minha Empresa.com" type="java.lang.String" 
override="false"/>
 
    Ou: 
 
<Parameter name="nomeEmpresa" value="Minha Empresa.com" override="false"/> 


   
    A diferença entre elas é a forma de acesso pela aplicação. A primeira pode ser acessada via InitialContext do pacote javax.naming através de um lookup e a segunda via ServeletContext.

    Vamos ver o acesso ao parâmetro declarado como Environment:

InitialContext context = new InitialContext();
Context xmlNode = (Context) context.lookup("java:comp/env");
String nomeEmpresa = (String) xmlNode.lookup("nomeEmpresa");

    Agora vamos ver o acesso ao parâmetro declarado como Parameter:

String nomeEmpresa = request.getSession().getServletContext().getInitParameter("nomeEmpresa");

  Pronto, dessa forma você pode declarar quantos parâmetros precisar.


Fonte: https://stackoverflow.com/questions/41227888/i-want-to-read-the-parameters-of-tomcat-context-xml  

quinta-feira, 23 de janeiro de 2020

Construindo um converter para JSF

    Nesse poste vou mostrar um converter simples do JSF. A diferença entre converters do JSF 1.* para o 2.* é que no 1.* é necessário declarar o converter no arquivo faces-config.xml enquanto que no 2.* é usado a anotação @FacesConverter.

    O papel do converter é dizer ao JSF como levar para o lado cliente e trazer de volta os objetos das classes que você construiu. É exigido, por exemplo, para a construção de Selects.

    Na prática, pela grande quantidade de classes de um projeto, geralmente se constrói um converter genérico para evitar o trabalho de ter que construir um converter para cada classe.

@FacesConverter(forClass=Paciente.class)
public class PacienteConverter implements Converter {
   
    PacientesDAO pacientesDAO = new PacientesDAO();
   
    @Override
    public Object getAsObject(FacesContext context, UIComponent component, String value) {
        if (value == null) {
              return null;
        }
        Long id = new Long(value);
            Paciente paciente = (Paciente) pacientes.porId(id);
        return paciente;
         
    }

    @Override
    public String getAsString(FacesContext context, UIComponent component, Object value) {
        if (value == null) {
              return null;
        }
             
        Paciente paciente = (Paciente) value;
             
        return  paciente.getId().toString();
    }

}

    Para este artigo é isso, abraços.

segunda-feira, 13 de janeiro de 2020

Comandos GIT para novos repositórios

    Nesse post trago apenas dicas básicas sobre o GIT que estão disponíveis geralmente nos próprios repositórios (GitHub, GitLab, Bitbucket, etc).
Configuração global do GIT 
 
git config --global user.name "seu_nome"
git config --global user.email "seu_email" 
Criando um novo repositório
git clone url_do_seu_projeto (git@blablabla)
cd pasta_projeto
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master 
Criando um repositório para um projeto existente
cd pasta_projeto
git init
git remote add origin url_do_seu_projeto (git@blablabla)
git add .
git commit -m "Initial commit"
git push -u origin master
 Migrando um projeto de um repositório para outro
cd pasta_projeto
git remote rename origin old-origin
git remote add origin url_do_seu_projeto (git@blablabla)
git push -u origin --all
git push -u origin --tags 
 
     Caso não queira Guardar o histórico de branchs, tags, comites, etc, pode-se 
apagar a pasta .git no projeto e fazer como se o projeto nunca tivesse sido 
gerenciado pelo GIT.
 

segunda-feira, 9 de dezembro de 2019

Inicializando e parando o Tomcat no Linux com o comando "service"

    Nesse post vou mostrar como configurar o Tomcat para ser inicializado e parado através do comando "service", e como colocar o servidor de aplicação para ser startado juntamente com a máquina.

    Vamos a configuração: Crie um arquivo em /etc/init.d/ chamado tomcat (não precisa de extensão) com o seguinte conteúdo:

#config tomcat
 

export CATALINA_HOME="/opt/apache-tomcat-7.0.69"

ERROR=0

case "$1" in
  start)
    echo $"Iniciando o Tomcat"
    sh $CATALINA_HOME/bin/startup.sh
    ;;

  stop)
    echo $"Parando servidor Tomcat"
        sh $CATALINA_HOME/bin/shutdown.sh
    ;;

  restart)
    echo $"Parando servidor Tomcat"
    sh $CATALINA_HOME/bin/shutdown.sh
    echo $"Iniciando servidor Tomcat"
    sh $CATALINA_HOME/bin/startup.sh
    ;;

  *)
    echo $"Uso: $0 {start|stop|restar}"

 exit 1
 ;;

esac

exit $ERROR


    Na parte destacada em amarelo, lembrar de colocar o caminho e versão do Tomcat do seu servidor. Agora vamos dar a permisão de leitura e execução:

chmod +rx /etc/init.d/tomcat

   Pronto, agora para inicializar o Tomcat bastausar o comando:

service tomcat start 
   
   E para parar:

service tomcat stop

   O restart por sua vez executa os dois comandos. Agora vamos configurar para iniciar o script no start do servidor. Basta executar este comando:

update-rc.d tomcat defaults

   Através deste comando é criado o link simbólico para a execução na inicialização do Linux. Para remover ele basta executar o seguinte:

update-rc.d tomcat remove

   Para esse post é só! Como sempre, espero ter ajudado...
 

sábado, 7 de dezembro de 2019

Debug remoto no Tomcat com o Eclipse

    Nesse post vou mostrar como preparar o Tomcat para Debug remoto com o Eclipse.

    Primeiro precisamos criar um arquivo na pasta raiz do Tomcat, e esse arquivo muda de extensão e de conteúdo de acordo com o S.O..

    Vamos primeiro ao do Windows: pode chamá-lo de startupDebug.bat e o conteúdo básico deve ser o seguinte:

set JPDA_ADDRESS=8000
set JPDA_TRANSPORT=dt_socket
bin/catalina.bat jpda start


    No ambiente linux o arquivo pode ser chamado de startupDebug.sh e deve ter permissão de leitura e execução (+rx). O conteúdo básico é o seguinte:

export JPDA_ADDRESS=8000
export JPDA_TRANSPORT=dt_socket
bin/catalina.sh jpda start


    Feito isso, quando quisermos debugar o Tomcat pelo eclipse, basta executar o Tomcat a partir desse script, ao invés do startup.bat (ou startup.sh em ambientes Linux) que executamos de costume. A porta de acesso ao sistema via browser continua a mesma de antes, a nova porta configurada foi para o debug. Será necessário liberação da porta no firewall em caso de acesso a servidores protegidos.

    Tendo feito isso e com a aplicação já startada, vamos ao eclipse configurar o debug remoto.

    No eclipse, no menu Run vá em Debug Configurations, a seguinte janela abrirá:


    Clique com o botão direito do mouse na opção Remote Java Aplication e escolha a opção New Configuration.  A imagem abaixo mostra em realce cada ponto de configuração, que são bem intuitivos. Após escolher a aplicação e dizer o endereço da aplicação onde está o localhost, no campo Port coloque a porta que configuramos no arquivo e clieque em Debug.








    Pronto, se todas as configurações estiverem corretas, o eclipse vai se conectar com a aplicação e você poderá debugar normalmente o código. Abraços!