quinta-feira, 22 de janeiro de 2026

Configurando dominio personalizado no blogger.com

INTRODUÇÃO

Ao criar um site no blogger.com, podemos usar o dominio que ele mesmo sugere como por exemplo: meusite.blogspot.com. Mas para usar o nosso próprio domínio registrado como por exemplo: www.meusite.com, nesse artigo vamos mostrar como realizar essas configurações.


CONFIGURAÇÃO

1. Blogger.com

Acessar o blogger.com, no painel lateral esquerdo superior, selecionar o blog. Depois disso, clique em configurações. Procure a seção "Publicação" e clique em "Domínio personalizado". Nesse momento, vai abrir um pop-up para o preenchimento, coloque o seu domínio como "www.meusite.com", precisa colocar o "www" para não dar erros. Ao clicar em salvar, vai aparecer uma mensagem de erros e informando os códigos chave-valor do CNAME que deverão ser usado no item 2 desse artigo.

Serão mostrados dois CNAMEs:

  • CNAME 
    • Nome: www
    • Valor: ghs.google.com

  • CNAME
    • Nome: código_seu_blog
    • Valor: url_gerada_seu_blog
Onde o primeiro CNAME quase sempre deve-se usar esse conjunto de dados (chave-valor). Mas no segundo CNAME, será gerado um código exclusivo do seu blog e o valor será como fosse uma url, também um código gerado para o seu blog.

Além disso, entre também na mesma seção "Publicação", ative o redirecionamento do dominio algo como meusite.com para www.meusite.com.
Por último, entre na seção "HTTPS" e ative todas essas configurações para aumentar a segurança do seu blog.

Observação: Anotar os códigos gerados assim que aparecer no pop-up porque depois não conseguimos mais obter nesse site. Pois deve seguir uma regra de segurança que quando um código alfanumérico é gerado, só mostra na primeira vez e depois não mostra mais.


2. Site de registro do dominio

Nesse momento, precisa entrar no site onde você fez o registro do domínio e entrar na seção de configuração do DNS. Basta adicionar as seguintes configurações:


Tipo: A

Nome: @

Valores: 216.239.32.21, 216.239.34.21, 216.239.36.21 e 216.239.38.21


Tipo: CNAME

Nome: www

Valor: ghs.google.com


Tipo: CNAME

Nome: código_seu_blog

Valor: url_gerada_seu_blog


Os valores CNAMEs foram obtidos no item 1 no painel dentro do blogger.com, usar os valores aqui.


Observações:

Excluir ou fazer backup de outras configurações do tipo A ou CNAME que podem conflitar com as configurações acima e acabar não funcionando, deixando o site fora do ar.

Sobre tempo de vida, pode deixar os valores padrão atribuídos automaticamente. Além disso, remover encaminhamento do domínio para outro domínio se caso essa configuração foi realizada pelo usuário ou o site de registro criou-a automaticamente. Caso contrário, vai dar erros no acesso ao site. Por último, depois disso, essas configurações podem levar horas ou até 48 horas para serem aplicadas. O ideal é realiza-la hoje e no outro dia ou depois de uma ou duas horas, realizarem os testes.









quarta-feira, 21 de janeiro de 2026

Apache Web Server Httpd - Configurações com e sem Proxy Reverso

INTRODUÇÃO


Na configuração do proxy reverso do apache Web Server, podemos ter situações onde queremos mapear paths com ou sem o proxy reverso. Isso tudo dentro do mesmo servidor Apache, sem precisar criar outro servidor Apache (isto é, criar outro container para subir outro Apache para resolver o problema sem proxy reverso).


CONFIGURAÇÃO


Para fazer isso, nos arquivos de configurações do apache, com a extensão .conf, por exemplo[1], devemos informar a diretiva "!" para o proxy reverso não estar ativo para um determinado path, por exemplo.

Conforme documentação[2], temos o seguinte exemplo de configuração:

ProxyPass            /site/recursos/docs !

ProxyPassReverse     /site/recursos/docs !

ProxyPass            /site/recursos "http://backend.exemplo.com"

ProxyPassReverse     /site/recursos "http://backend.exemplo.com"


Nesse caso, ao acessar o path "/site/recursos/docs" não funcionará o proxy reverso. Mas o que estiver configurado no Apache além disso (como acesso a diretório ou outras configurações) pode funcionar, sem conflitar com a configuração do Proxy Reverso.


Observação: A ordem dos paths é importante, colocando primeiro o path mais detalhado possível para o mais geral. Pois na execução do proxy reverso, verá se o path "/site/recursos" tem proxy reverso, nesse caso, a primeira configuração é "/site/recursos/docs" o que não "bate" (match), e indo para a configuração seguinte que dará "match" e será executada (indo para a URL http://backend.exemplo.com).

Se fosse o contrário (configurações invertidas, onde temos o path "/site/recursos" primeiro), ao chamar a URL "/site/recursos/docs" fará um match com a configuração "/site/recursos" apenas no começo (porque esse path é mais geral) e será válido o match, sendo executado o proxy reverso da configuração "/site/recursos" que chamará a URL http://backend.exemplo.com o que estará errado, segundo as nossas configurações.


A seguir, temos o restante da configuração para mapear o path "/site/recursos/docs" para o sistema de arquivos (File System) do servidor:


DocumentRoot "/var/local/docs"

Alias /site/recursos/docs "/var/local/docs"

<Directory "/var/local/docs">

    Options Indexes FollowSymLinks MultiViews

    AllowOverride None

    Require all granted

</Directory>


A configuração do proxy reverso e depois a configuração do diretório (nesse ordem) devem estar dentro da tag "VirtualHost" do arquivo de configuração do Apache Httpd.


CONCLUSÃO

Com essa configuração conseguimos desativar o proxy reverso somente para um determinado path e evitando o conflito com outras configurações de proxy reverso para outros paths. Sem isso, precisaríamos criar outros servidores/containers para isolar isso, o que sempre pode não ser possível.


REFERÊNCIAS


[1] Dependendo da versão do Apache e até do sistema operacional subjacente, pode ter mudanças na organização dos arquivos de configuração. Uma vez entendido essas mudanças, a essência das configurações descritas nesse artigo, permanece a mesma, somente variando a sintaxe e localização desses arquivos de configuração.

[2] https://httpd.apache.org/docs/2.4/mod/mod_proxy.html


Docker - Acessando outra aplicação localmente no mesmo host

INTRODUÇÃO 

Ao usar o docker para criar containers para a sua solução, pode haver a necessidade de uma aplicação A dentro de um container A acessar outra aplicação B em outro container B ou no próprio host hospedeiro. Se chamar pela URL localhost:X (onde X é a porta), a sua aplicação A que está dentro do container A, procurará por esse serviço no próprio container A e que não existirá! Pois não tem nenhuma aplicação registrada na porta X no container A. Pois essa aplicação estará no container B!


EXEMPLO

Container A

Aplicação: Web (Pode ser uma aplicação frontend React/Vue/Angular)

Porta: 3000


Container B

Aplicação: Banco de dados PostgreSQL

Porta: 5432


Observação:

Nesse exemplo, estamos simplificando a comunicação para explicar os conceitos desse artigo. Logicamente numa aplicação real, teremos mais containers e camadas de aplicações, como por exemplo o frontend num container X chamando o backend no container Y e depois chamando o banco de dados num container Z.


OBJETIVO

A aplicação Web A acessar o banco de dados no container B.


PROBLEMA

A aplicação Web A deseja acessar o banco de dados que está em outro container, mas se acessar chamando a URL localhost e na porta 5432, dará erros, de conexão recusada, pois no container A não possui nenhuma aplicação registrada na porta 5432.


SOLUÇÃO

Usar a URL: host.docker.internal nas suas configurações locais para o docker entender que é para buscar fora do próprio container que está efetuando a chamada. No exemplo acima, usariamos a URL com porta, como host.docker.internal:5432.



sexta-feira, 24 de janeiro de 2025

Subindo um servidor http local para listar e mostrar arquivos de um diretório em python

 INTRODUÇÃO

Em muitas aplicações e testes na programação de aplicações ou integração de sistemas, as vezes, necessitamos subir um servidor http num diretório especifico. E ao chamar esse servidor web no browser, queremos ver a lista de arquivos no diretório e clicar nos links para baixar os próprios arquivos do diretório que foi mapeado pelo web server.

Mas, para um usuário comum, isso seria meio que "ridículo", pois no próprio sistema operacional (OS), seja Windows, Linux ou Mac, o próprio OS mostra isso na sua própria interface. Porém quando estamos fazendo integrações entre sistemas e queremos otimizar tarefas, para o sistema em si, é mais prático usar a mesma arquitetura de comunicação (via WEB) pois a aplicação já deve chamar outros endpoints em REST/JSON, SOAP/XML e essa integração seria mais fácil tendo esse servidor mapeando diretórios.

Por outro lado, a aplicação em qualquer linguagem, pode acessar o sistema de arquivos (File System) do próprio OS para ler esses diretórios, mas vamos adotar uma arquitetura única de comunicação usando WEB. Para isso, podemos subir um servidor em várias linguagens, mas vamos mostrar uma ferramenta em python para subir em pouquissimos minutos.


DESENVOLVIMENTO

Entre no console/terminal em linha de comando, acesse a pasta desejada (comandos como cd, ls, pwd). Na pasta desejada execute o seguinte comando:

python -m http.server

ou

python3 -m http.server


RESULTADOS

O comando anterior vai abrir um servidor web em python e ficará disponível na porta 8000.

Para isso, basta acessar o browser e digitar 

http://localhost:8000/

O resultado deverá mostrar a lista de arquivos daquele diretório desejado.

Para finalizar o servidor é só dar CTRL+C ou fechar o terminal que o servidor web será finalizado.


MAIS CONFIGURAÇÕES

Para poder mudar a porta e mais configurações, execute o comando de ajuda abaixo:

python -m http.server --help


CONCLUSÃO

Conseguimos subir um servidor web em python de forma rápida para testes. Além do python, podemos usar também configurar um agente no Apache Flume em https://logging.apache.org/flume/

Mas esse projeto da Apache será movido para: https://logging.apache.org/dormant.html


quinta-feira, 11 de fevereiro de 2021

Selenium Java - Como limpar campos

 INTRODUÇÃO

Vamos mostrar nessa publicação maneiras de se limpar os campos, para que na execução funcione corretamente.


PROCEDIMENTO

// Busca elemento do driver, passando o By
WebElement elemento = driver.findElement(by);
// Seleciona texto do começo do campo até o fim, segurando SHIFT e depois, aplica o Backspace
elemento.sendKeys(Keys.HOME, Keys.chord(Keys.SHIFT, Keys.END), Keys.BACK_SPACE);

// Seleciona todo o texto dando o comando "CONTROL + A" e depois, aplica o Backspace
elemento.sendKeys(Keys.chord(Keys.CONTROL, "a"), Keys.BACK_SPACE);

// Apaga qualquer texto no componente
elemento.clear();

OBSERVAÇÕES

O motivo de estarmos usando praticamente três funções "repetidas" é porque durante a execução, a função "elemento.clear()" não funciona corretamente, ora limpa o campo, ora não limpa.
Da mesma maneira para as outras funções. Pois alguns componentes podem ter lógica JavaScript embutida sendo executada, navegadores distintos podem ter comportamentos distintos para a mesma execução do selenium para o mesmo campo e outros problemas.


REFERÊNCIAS

https://www.selenium.dev/documentation/en

terça-feira, 4 de agosto de 2020

Criando arquivo .sh para executar aplicação Java com passagem de parâmetros

Conforme mostrado no artigo http://www.josepojr.com/2020/07/criando-arquivo-bat-para-executar.html
a configuração para Windows, mas para Linux, temos pequenas mudanças conforme exemplo abaixo:


java -Dfile.encoding=UTF-8 -cp ".:libs/*" pacote.minha.classe.Main $*

Aonde "$*" permite que passamos parâmetros dentro da execução do script .sh no Linux.
Também, alteramos o símbolo separador de path do windows que é um ponto-e-vírgula ";" para dois pontos ":" e colocamos aspas no valor do parâmetro "cp".
Importante não deixa espaço em branco depois de "$*" para a aplicação Java não entender que aquele espaço em branco é um argumento passado para o programa.

Criando shell script para executar aplicações Java no Linux com dependências

INTRODUÇÃO


Nessa publicação explicaremos como criar o arquivo .sh para iniciar uma aplicação Java com as suas dependências (Pastas libs contendo Jars, por exemplo). Para isto, vamos criar uma aplicação simples chamada "ExemploJava".


CONFIGURAÇÃO


Essa aplicação terá uma pasta chamada "libs" para conter os jars de bibliotecas de terceiros que a aplicação pode usar (ou não) e será referenciada no classpath da aplicação Java.

Outra pasta chamada de "bin" conterá os pacotes e classes do projeto. Por exemplo, se tivermos uma classe fictícia chamada "A" dentro do pacote "a.b.c", portanto o nome completo da classe será "a.b.c.A". E dentro da pasta "bin", teremos a pasta "a" e dentro desta a pasta "b". E por último, dentro da pasta "b", teremos a pasta "c" que conterá o arquivo "A.java" definindo a classe pública "A".

Estas duas pastas estarão dentro da pasta "ExemploJava" e o script .sh ("exemploJava.sh" por exemplo) estará dentro desta pasta.

Para efeito prático, vamos adotar a classe "A" como a classe com o método main (inicializadora da aplicação Java).

Portanto, o conteúdo do arquivo .sh será:

java -Dfile.encoding=UTF-8 -cp ".:bin/:libs/*:" a.b.c.A 


Aonde temos:

-Dfile.encoding=UTF-8
aonde informa a codificação usada, muito recomendável usar unicode no UTF-8 pois é uma codificação internacional e preparada para lidar com diversos alfabetos e idiomas.


-cp ".:bin/:libs/*:"
aonde informamos as pastas, jars e arquivos .class que estarão no classpath. Estando no classpath, nossa aplicação pode carregar e usar as classes. Se não estiver no classpath, pode dar erros em tempo de execução, lançado exceções dos tipos "java.lang.ClassNotFoundException" ou "java.lang.NoClassDefFoundError" por exemplo. Além disso, se forem colocados paths (caminhos) errados, ao rodar a aplicação não dará erro a priori (por causa desses paths sem jars ou arquivos .class), mas quando a classe Main for executada e for carregando as dependências, pode chegar numa classe que não estará no classpath. Portanto, muito cuidado para colocar o caminho correto para que as dependências dentro desses caminhos sejam carregadas corretamente para dentro da JVM.

Nesse exemplo, usamos a pasta bin para conter os arquivos .class ou recursos. Mas também é possível empacotar tudo num jar e colocar nesse argumento diretamente (":meuarquivo.jar") ou colocar esse jar na pasta "bin" ou "libs".
Lembrando também que os dois-pontos ":" é o separador de paths (caminhos) entre um jar ou diretório do outro. O sinal ponto "." representa o diretório atual que o script está sendo rodado.


a.b.c.A
É o nome completo para a classe Main que será iniciada pela JVM no comando "java".
Sem essa classe Main, o comando "java" abortará, mostrando uma mensagem de erro dizendo que não foi informado uma classe com o método estático "void main(String args[])".


OBSERVAÇÃO


Muito importante, depois da classe main "A", deverá ter um espaço em branco!
Caso contrário, ao executar o script sh, dará erros dizendo que a classe "a.b.c.A" não foi localizada e nem carregada! Pois, o shell script fornecerá como parâmetro a classe de nome completo "a.b.c.A\n" com a QUEBRA DE LINHA inclusa! E logicamente, no nosso classpath (formado pelo núcleo do Java e mais as pastas informadas no parâmetro "cp") essa classe de nome completo "a.b.c.A\n" não existirá! E pior, difícil de localizar esse tipo de erro, pois a quebra de linha "\n" fica invisível no terminal!

segunda-feira, 6 de julho de 2020

Criando arquivo .bat para executar aplicação Java com passagem de parâmetros

Nesse artigo, vamos mostrar como fazer a criação do arquivo .bat para ser executado no sistema operacional Windows, chamando uma aplicação Java e podendo passar parâmetros.

Para isso, vejam esse exemplo:


set PARAMETROS=%*
java -Dfile.encoding=UTF-8 -cp .;libs/* pacote.minha.classe.Main %PARAMETROS%



Aonde a variável "PARAMETROS" define a maneira de passar o parâmetro na execução do arquivo.bat.

Para executar esse bat, salve como "arquivo.bat" e depois execute em linha de comando digitando da seguinte maneira:

arquivo.bat a b c

Aonde os parâmetros "a", "b" e "c" serão passados para a classe Main declarada em "pacote.minha.classe.Main" aonde informa a classe com o método estático "void main(String args[])" aonde que em Java é o método que é chamado na execução de um programa.

Portanto, esses parâmetros passados estarão contidos na variável "args"do programa Java. Logicamente, nesse exemplo, estou usando o parâmetro com o nome "args", mas se o nome for diferente, a passagem dos parâmetros ocorrerá normalmente e sua aplicação poderá passar!

Para o parâmetro ".;libs/*" indica uma pasta chamada "libs" e todos os jars que estiverem contidas dentro dessa pasta serão carregados no classpath da aplicação, se caso for necessário. E o "." indica o diretório atual, para procurar jars no mesmo diretório do arquivo.bat. E por último, o ";" apenas separa os diretórios listados, podendo carregar vários diretórios de jars para a aplicação rodar.

Temos abaixo um exemplo de classe Main:

public class Main {

    public static void main(String args[]) {
        for(int i=0; i < args.length; i++) {
             System.out.println("Parametro passado: " + args[i]);
        }
   }
}

Também é possível chamar diretamente o jar no arquivo.bat:

set PARAMETROS=%*
java -jar A.jar %PARAMETROS%

Aonde temos todas as dependências do jar embutidas num único jar.

segunda-feira, 13 de novembro de 2017

Problemas no uso do método System.currentTimeMillis() e uso do método System.nanoTime() na linguagem Java



INTRODUÇÃO

No desenvolvimento de sistemas usando a linguagem Java, é corriqueiro o uso do método de obter a quantidade de milissegundos do tempo atual (contando desde 1970).
Mas nesse artigo mostraremos problemas na chamada sucessiva desse método (que retorna o mesmo valor, como o tempo não "andasse") e possível solução para contornar os problemas.


PROBLEMA

Ao executarmos o seguinte código Java:



import java.text.SimpleDateFormat;
import java.util.Calendar;

public class TesteTempos {

    public static void main(String[] args) {
       
         final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd_HHmmssS");

         final long time1 = System.currentTimeMillis();
         final long time2 = System.currentTimeMillis();
       
         final long nano1 = System.nanoTime();
         final long nano2 = System.nanoTime();
       
         final String txt1 = sdf.format(Calendar.getInstance().getTime());
         final String txt2 = sdf.format(Calendar.getInstance().getTime());
       
         System.out.println(time1);
         System.out.println(time2);
         System.out.println();
         System.out.println(nano1);
         System.out.println(nano2);
         System.out.println();
         System.out.println(txt1);
         System.out.println(txt2);
    }
}



Resultado (no console):

1510339299662
1510339299662

2068554850479041
2068554850479809

20171110_164139662
20171110_164139663


Note que as duas chamadas de System.currentTimeMillis() geram o mesmo valor. Isso é ruim num processamento num servidor JavaEE (por exemplo) aonde queremos tempos diferentes e não iguais! Se temos tempos iguais, nosso código pode dar erros em tempo de execução em alguma lógica que obrigue ser diferente (Exemplo: uso da data como parte da chave primária composta de um banco de dados).


SOLUÇÃO

Usar a chamada System.nanoTime() para gerar valores sempre distintos caso necessitamos (por exemplo, queremos inserir dois registros no banco de dados, sendo que esses tempos são parte de chave primária composta da tabela do banco de dados). Nesse caso, evitamos que a JVM retorne valores iguais!

Note também que a chamada a Calendar.getInstance().getTime() tem praticamente o mesmo efeito da chamada System.currentTimeMillis(), mas a diferença de 1 milissegundos está no fato no tempo de formatação da data pelo objeto da classe java.text.SimpleDateFormat.


CONCLUSÃO

Nesse artigo mostramos problemas no uso sucessivo da chamada System.currentTimeMillis() e maneiras de contorná-los! Em muitos casos envolvendo regras de negócio que necessitem chamadas sucessivas de tempos atuais, mas que retornem valores distintos, importante ter atenção e usar o método System.nanTime().


terça-feira, 17 de novembro de 2015

CONFIGURANDO A EXCLUSÃO DO USO DE MÓDULOS PADRÃO NO JBOSS 7



INTRODUÇÃO
 
Nos artigos anteriores (http://www.josepojr.com/2013/10/ordem-de-carregamento-de-classes-jars.html e http://www.josepojr.com/2013/01/isolamento-de-classloaders-no-jboss-as-7.html) foi mostrada a configuração do jboss 7 no arquivo jboss-deployment-structure.xml e algumas regras de preferência no carregamento de dependências. Nesse artigo, vamos mostrar como evitar que um módulo padrão que já vem instalado dentro do JBoss 7 (pasta $JBOSS_HOME/modules) seja carregado. E consequentemente, podemos usar os nossos arquivos .jar sem problemas de dependências e lançamentos de exceções do tipo NoSuchMethodException (método não existente). Esse tipo de exceção pode ocorrer se em tempo de projeto (usando uma IDE por exemplo), usamos os jars de uma biblioteca como por exemplo Apache Http Client na versão 4.5, mas no JBoss 7, já temos por exemplo, uma versão dessa mesma biblioteca na versão 4.2, por exemplo. E ao invocar métodos que só existam na versão 4.5, mas na versão 4.2, os mesmos não existe, o erro NoSuchMethodException pode aparecer. Isso porque em tempo de compilação foi usada a versão 4.5, mas em tempo de execução (projeto war ou ear implantado dentro do JBoss 7), a versão 4.2 (dentro da pasta $JBOSS_HOME/modules) pode ser carregada primeiro em detrimento a versão 4.5 (que pode ou não estar na pasta EAR/lib).
Por isso, precisamos configurar o arquivo .ear gerado para que não ocorra esses erros de dependências que será mostrado nesse artigo.


DESENVOLVIMENTO

Como por exemplo, vamos usar a biblioteca Apache Http Client que pode ser baixada do site:
Esses componentes permite qualquer programa acessar servidores web no protocolo HTTP ou HTTPS. Para isso, fornece modelos para a construção de clientes HTTP no seu programa Java. Sem esses componentes, teríamos que escrever do “zero” (projeto desde o início, novo) um cliente HTTP dentro do nosso programa Java. Isso é possível usando as classes java.net.Socket, java.io.InputStream, java.io.OutputStream e outras semelhantes dentro do JRE (Java Runtime, ambiente de execução do Java mais a máquina virtual) fornecido em toda instalação Java em qualquer dispositivo.
Mas, teríamos que perder um tempo enorme para fazer todas essas chamadas, sendo que com o uso desses componentes e com poucas linhas de códigos já temos um cliente HTTP para usarmos no nosso código.
Portanto, como esse projeto é tem uma licença bem semelhante a um software Open Source e é usado em diversos projetos, o JBoss 7 já vem com essa biblioteca da Apache já configurada como módulo dentro do servidor JBoss 7.
Ao mesmo tempo em que isso é bom, pois já temos um módulo dessa biblioteca para usarmos em nosso projeto, ao mesmo tempo também é ruim, pois queremos usar uma versão mais recente da biblioteca em nossos projetos, por exemplo.
Para isso, vamos configurar o arquivo jboss-deployment-structure.xml para não usar o Apache Http Client existente como módulo dentro do JBoss:

<?xml version="1.0" encoding="UTF-8"?>

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
<deployment>
<exclusions>
<module name="org.apache.httpcomponents" slot="main" />
</exclusions>
<dependencies>
<module name="javax.api"/>
<module name="org.jboss.resteasy.resteasy-jaxrs"/>
<module name="org.infinispan"/>
<module name="deployment.MeuProjeto.ear.MeuEJB.jar"/>
<module name="deployment.MeuProjeto.ear.MeuWAR.war"/>
</dependencies>
</deployment>
<!-- durante o deploy. -->
<sub-deployment name="MeuEJB.jar">
<exclusions>
<module name="org.apache.httpcomponents" slot="main" />
</exclusions>
<local-last value="true"/>
</sub-deployment>
<sub-deployment name="MeuWAR.war">
<dependencies>
<module name="deployment.MeuProjeto.ear.MeuEJB.jar"/>
</dependencies>
<local-last value="true"/>
</sub-deployment>
</jboss-deployment-structure>


Só colocar os trechos marcados em VERMELHO no arquivo jboss-deployment-structure.xml do seu projeto. Nesse exemplo, estamos dizendo que o projeto EJB chamado “MeuEJB.jar” precisa usar a biblioteca Apache Http Client própria e não do JBoss 7. E também, estamos excluindo o uso no ear como um todo como mostra o trecho em VERMELHO dentro da tag <deployment>.
Na pasta /lib dentro do projeto EAR (ou conhecida como EAR/lib) devem estar os jars do Apache Http Client obtido no site:


CONCLUSÃO

Mostramos que o uso de configurações dentro do arquivo jboss-deployment-structure.xml permite refinar algumas configurações que terão impacto tanto no tempo de implantação (deploy) ou em tempo de execução, quando a aplicação for chamada pela primeira vez.
Com isso, podemos usar as versões mais recentes das bibliotecas de terceiros sem conflitar com as mesmas bibliotecas de outras versões já instaladas dentro do JBoss 7.


REFERÊNCIAS











quinta-feira, 19 de fevereiro de 2015

Configurando Exceção de Rede (Network) no Ubuntu

INTRODUÇÃO

Quando acessamos o Linux, mas especificamente o Ubuntu 14.04 (rode o comando uname -a para saber a versão do Linux) geralmente estamos numa rede com o servidor Proxy ativado. E geralmente para usarmos, precisamos configurar o Linux com o IP e PORTA do servidor Proxy. Além disso, há casos que o servidor Proxy exige autenticação, isto é, fornecer o USUARIO e SENHA para o servidor Proxy aceitar as requisições.

Nesse artigo, vamos mostrar como configurar o proxy de modo geral no Linux Ubuntu versão 14.04 e como configurar os softwares de gerenciamento de pacotes como o APT-GET e APTITUDE a baixarem os pacotes pelo proxy.



CONFIGURANDO O PROXY PARA O LINUX EM GERAL


1) Abrir arquivo /etc/environment

sudo vim /etc/environment


2) Coloque as seguintes linhas (2 linhas no total) no arquivo /etc/environment:

http_proxy=http://USUARIO:SENHA@IP:PORTA/
https_proxy=https://USUARIO:SENHA@IP:PORTA/



Aonde:

USUARIO: Usuário para fazer o login no servidor proxy
SENHA: Senha para fazer o login no servidor proxy

Observação: Se o servidor proxy não requerer usuário e senha, usar como:

http_proxy=http://IP:PORTA/
https_proxy=https://IP:PORTA/


3) Reiniciar as conexões de rede, execute o seguinte comando:

sudo /etc/init.d/networking restart



CONFIGURANDO O PROXY PARA O APT-GET e APTITUDE

Para configurar o proxy para funcionar nos softwares APT-GET e APTITUDE façam o seguinte:

1) Abrir arquivo /etc/apt/apt.conf

sudo vim /etc/apt/apt.conf



2) Coloque as seguintes linhas (4 linhas no total, para cada ";") no arquivo /etc/apt/apt.conf

Acquire::http::proxy "http://USUARIO:SENHA@IP:PORTA/";
Acquire::https::proxy "https://USUARIO:SENHA@IP:PORTA/";
Acquire::ftp::proxy "ftp://USUARIO:SENHA@IP:PORTA/";
Acquire::socks::proxy "socks://USUARIO:SENHA@IP:PORTA/";



Aonde:

USUARIO: Usuario para fazer o login no servidor proxy
SENHA: Senha para fazer o login no servidor proxy

Observação: Se o servidor proxy não requerer usuário e senha, usar como:

Acquire::http::proxy "http://IP:PORTA/";
Acquire::https::proxy "https://IP:PORTA/";
Acquire::ftp::proxy "ftp://IP:PORTA/";
Acquire::socks::proxy "socks://IP:PORTA/";



TESTES - ACESSO A INTERNET

1) No terminal do Linux, executar o seguinte comando:

wget http://www.josepojr.com

Aonde "http://www.josepojr.com" é URL de teste que pode ser qualquer site. E o comando wget, acessará o site na porta especificada (no caso 80, que é a porta HTTP padrão) fazendo uma requisição HTTP GET dentro do console.


2) Pode-se utilizar o comando ping:

ping www.josepojr.com


3) Ou pode-se utilizar o comando telnet:

telnet www.josepojr.com 80



TESTES - USO DE GERENCIADOR DE PACOTES APT-GET e APTITUDE

1) Execute o seguinte comando para atualizar os pacotes:

sudo apt-get update
sudo aptitude update


2) Atualizar pacotes com APTITUDE (Recomendável):

sudo aptitude safe-upgrade



REFERÊNCIAS:

http://pt.kioskea.net/faq/8815-reiniciar-a-interface-em-linha-de-comando
https://danjared.wordpress.com/2011/03/09/configurar-el-proxy-en-ubuntu/
https://www.gnu.org/software/wget/


segunda-feira, 23 de junho de 2014

Apache Web Service + JBoss Mod cluster (Loadbalance) + JBoss AS 7 no CentOS 6.5 - 64 bits


INTRODUÇÃO

explicamos detalhadamente a instalação do Apache Web Service (conhecido como "httpd") com o JBoss Mod Cluster já instalado. Nesse artigo, vamos explicar a configuração para o Apache Web Service "limpo", isto é, o httpd instalado no CentOS sem nenhum módulo adicional, em outras palavras, com a configuração padrão do httpd para o CentOS.



DESENVOLVIMENTO

Instalando e configurando o Apache Web Service (httpd).

Instalar os seguintes pacotes no CentOS 6.5 64 bits.

yum install httpd httpd-devel apr-devel openssl-devel mod_ssl -y

Depois disso, iniciar serviço do httpd com o comando:

service httpd start

Ou na interface gráfica dentro do CentOS, No menu "Sistema" > "Administração" > "Serviços", conforme mostra a figura a seguir:



Depois de iniciar o servidor httpd, o resultado no endereço http://127.0.0.1 (local) ou outro endereço que está configurado na interface de rede do CentOS, deve ser a página inicial do servidor httpd, conforme mostra a figura a seguir:





Depois de testar o servidor httpd, agora baixe (desligue) o httpd que vamos inserir módulos do projeto JBoss ModCluster para poder configurar o loadbalance (Balanceador de carga, isto é, de requisições HTTP).

Para isso, entre nesse site: http://mod-cluster.jboss.org/
faça o download da versão 1.2.6.Final para o sistema operacional linux-x86_64

Observação: Não baixe as versões que venha com o httpd incluído, pois estaremos usando o httpd fornecido dentro dos repositórios de pacotes .rpm do CentOS 6.5. Dá para notar que o tamanho do arquivo com o httpd é da ordem de megabytes, enquanto o arquivo só com os módulos é da ordem de kilobytes.

Ao baixar o arquivo, descompacte o arquivo *.tar.gz com o seguinte comando:

tar xvfz mod_cluster-1.2.6.Final-linux2-x64-so.tar.gz 

Dentro do arquivo compactado, teremos 4 arquivos binários com a extensão *.so que são:

mod_advertise.so
mod_manager.so
mod_proxy_cluster.so
mod_slotmem.so

Esses são os 4 módulos que vão ser inseridos na pasta /etc/httpd/modules, então, deve-se copiar esses arquivos para esse diretório, tomando cuidado para que o dono e grupo dos arquivos sejam sempre root.
Caso contrário, ao iniciar o httpd, o mesmo reportará erros de permissão nos módulos e não conseguirá ser iniciado.

Agora vamos para o diretório  /etc/httpd/conf e edite o arquivo httpd.conf com os seguintes dados:

Comente a linha do módulo proxy_balancer_module para não entrar em conflito com o modulo de proxy do JBoss Cluster (mod_proxy_cluster) que estaremos incluindo:

#LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

Insira as seguintes linhas depois das outras linhas com o nome "LoadModule":

LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so


Inserir a seguinte linha depois da linha com o comando "Include conf.d/*.conf"

MemManagerFile /var/cache/mod_cluster

Por último, inserir o comando "IfModule" para o módulo "manager_module" conforme mostra código a seguir:

<IfModule manager_module>
   Listen 0.0.0.0:6666
   ManagerBalancerName mycluster
   <VirtualHost *:6666>
       <Location />
       Order deny,allow
       Deny from all
       Allow from all
  
       KeepAliveTimeout 300
       MaxKeepAliveRequests 0
       ServerAdvertise Off
       EnableMCPMReceiver Off
  
       <Location /mod_cluster_manager>
            SetHandler mod_cluster-manager
            Order deny,allow
            Deny from all
            Allow from all
       </Location>
   </VirtualHost>
</IfModule>


Depois disso, iniciar o servidor com o comando:

service httpd start

Observação: Nesse momento, é importante iniciar o servidor dessa maneira para que o mesmo possa imprimir no console os erros que possam ocorrer. Se iniciar pela interface gráfica e se tiver erros no arquivo httpd.conf, o servidor não iniciará e ficar com um alerta dizendo que está morto, ou a interface gráfica ficará travada. Também podemos olhar os logs no diretório /etc/httpd/logs mas o trabalho para chegar até ai e usar os velhos comandos como tail -f error.log seria muito demorado. Quando ocorre erros, o erro já foi reportado no próprio console, depois de executar o comando service httpd start.


Configurando o JBoss AS 7 para funcionar com o httpd + mod_cluster

Próximo passo é configurar o JBoss AS 7 para se conectar no httpd com o mod_cluster instalado. Para isso, altere o arquivo de configuração standalone-full-ha.xml da pasta $JBOSS_HOME/standalone/configuration conforme as configurações abaixo:

<subsystem xmlns="urn:jboss:domain:modcluster:1.1">
    <mod-cluster-config advertise-socket="modcluster" proxy-list="127.0.0.1:6666" connector="ajp">
         <dynamic-load-provider history="10" decay="2">
              <load-metric type="cpu" weight="2" capacity="1" />
              <load-metric type="sessions" capacity="512" />
         </dynamic-load-provider>
    </mod-cluster-config>
</subsystem>

<subsytem xmlns="urn:jboss.domain:web:1.2" default-virtual-server="default-host" instance-id="%{jboss.node.name}" native="false">
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" />
    <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" />
    <virtual-server name="default-host" enable-welcome-root="true" >
          <alias name="localhost" />
    </virtual-server>
</subsystem>

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}" >
    <socket-binding name="ajp" port="8009" />
    <socket-binding name="http" port="8080" />

</socket-binding-group>

Depois disso, abrir navegador no endereço http://127.0.0.1, conforme mostra a figura seguir:



Note que a página inicial do httpd "sumiu", isto é, ficou no lugar da página inicial do JBoss AS 7. Isso mostra que o balanceador de carga (mod_cluster) + httpd (servidor web) estão funcionando juntos e corretamente!



CONCLUSÃO

Mostramos nesse artigo como configurar, instalar o JBoss ModCluster dentro do Apache Web Service e assim, funcionando junto com o servidor JBoss AS 7. Lembrando que podemos instanciar N servidores jboss para trabalhar com o mesmo servidor httpd, desta maneira, se um servidor jboss cair (for derrubado), o httpd com o mod_cluster instalado, detectará que uma instância do cluster de JBoss AS 7 caiu e não enviará mais requisições a essa instância.

Para realizar o acesso externo no CentOS, veja mais informações nesse link: http://tidahora.com.br/index.html/doku.php?id=instalando_o_mantis_no_centos_6. Esse artigo cita a instalação de um outro programa web como o Mantis (https://www.mantisbt.org/), mas cita a desativação do serviço SELINUX com a edição do arquivo /etc/selinux/config e pede para mudar a seguinte linha:

SELINUX = disabled

Para desabilitar o SELINUX. Depois, no menu "Sistema" > "Administração" > "Firewall" e configure o par porta/protocolo para o Firewall deixar fazer o acesso. Lembrando de clicar em "Aplicar" para as configurações possam estar valendo no sistema.
Por último, configurar o Iptables no linux para deixar realizar o acesso pelas portas necessárias. A configuração disso está fora do escopo desse artigo, podendo ser realizada pelo link http://www.guiafoca.org/cgs/guia/avancado/ch-fw-iptables.html.
Ou como solução paliativa e para fins de desenvolvimento e testes, pode se desativar o serviço de Iptables no menu "Sistema" > "Administração" > "Serviços".


REFERÊNCIAS

http://jbossdivers.wordpress.com/2014/03/23/configurando-um-ambiente-wildfly-8-profissional/






quinta-feira, 5 de junho de 2014

Overclock de Notebook


INTRODUÇÃO

Nesse artigo vamos falar um pouco sobre overclock de notebook, de maneira a melhorar o desempenho e consequentemente, esticar a vida útil do produto. Caso contrário, teríamos que comprar outro notebook em um curso prazo de tempo. Para isso, vamos falar de algumas técnicas e modificações no notebook para melhorar o desempenho. E por último, é importante destacar que o overclock aplicado no notebook não visa necessariamente aumentar a frequência do processador para além da fabricada (1,8 GHz) e sim, aplicar técnicas que visam dissipar calor, melhorar throughput (fluxo, vazão, por unidade de tempo, usando qualquer medida, como por exemplo, bytes por segundo, etc) entre os dados que trafegam entre a CPU-Memória e outros.


DESENVOLVIMENTO

Todo semicondutor como CI, transistores, diodos e outros ao entrarem em funcionamento, gastam energia por unidade de tempo (Joules / segundo) que é chamada de potência. Quanto maior a potência dissipada, maior o calor dissipado pelo semicondutor.
O aquecimento em semicondutores como CI, transistores, diodos e outros, faz com que os elétrons ganhem energia extra para mudar de níveis de tensão, sem precisar do chaveamento lógico que ocorre durante o funcionamento da CPU. Com isso, o estado interno da CPU (Registradores, memória, etc) tem funcionamento instável o que pode levar a erros de cálculos e constantes travamentos. Por isso, precisamos dissipar esse calor, pois evitarmos seria impossível, pois se o semicondutor não dissipa calor, ele não está dissipando potência e consequentemente, não realiza trabalho e por último, não funciona.

Conforme a figura a seguir, vemos o notebook a sofrer overclock. Esse notebook tem 2 GB de ram (o máximo suportado), roda Ubuntu Linux 14.10 (se usar outro sistema operacional como Windows, o notebook não suportaria e ficaria extremamente lento), frequência de CPU de 1,8 GHz.



Como vemos na figura a seguir, mostramos as principais regiões que dissipam mais calor, como CPU, placa de vídeo (NVIDIA) e memória.




Na figura a seguir, destacamos as áreas que mais dissipam calor com a cor VERMELHA.
Essas regiões foram identificadas pelo aquecimento excessivo no notebook.



Para resolver o problema do aquecimento, precisaríamos abrir mais espaço de ventilação, pois os furos originais na memória são praticamente insuficientes! E também, é difícil para um projetista de produtos como notebook, pensa em desenhar (projetar) um notebook que possa resistir por longos tempos de uso e sobre uso severo (sistema operacional que usa toda a memória, frequência baixa da CPU, baixo throughput (fluxo, por unidade de tempo, bytes por segundos ou outras grandezas, de qualquer área) entre a CPU – Memória – Placa de Vídeo.
Esses furos foram realizados em sua maioria por uma furadeira de maneira a permitir maior passagem de ar entre os módulos de memória e placa de vídeo. Sem esses furos, foi constatado que a CPU ficava esperando a memória, pois ficava sempre em 99 % de uso, depois disso, houve melhor vazão (throughput) de dados entre CPU-Memória e consequentemente, a CPU dá uns picos de 100% e caí rapidamente para 5%, nisso eliminamos o gargalo (ponto de maior estrangulamento num fluxo de dados ou em qualquer outra área, como logística, química e outras.) de comunicação CPU-Memória.





Na próxima figura, vemos que a base (rodapé) que segura o notebook apoiado em uma mesa precisou ser serrado, pois o mesmo, atrapalhava a circulação de ar da CPU do notebook. É como se o ar quente ficasse “parado” e deixando a CPU mais quente ainda. Ou de forma análoga, é como um carro sem sistema de arrefecimento, aonde o motor vai esquentando, o ar quente em volta não “saí”, isto é, não se dissipa, e deixa o motor mais quente, até queimar o motor. No caso da CPU, isso leva ao travamento da mesma.





Na próxima figura, usamos uma mesa que possui ventoinhas para deixar o notebook mais frio. Esse acessório, também chamado de “cooler de notebook” é encontrado em praticamente todas as lojas de informática. Nisso, estamos ajudando o notebook a dissipar o calor, pois não adianta nada, ter boa circulação de ar (com os furos na parte da memória e placa de vídeo) e o ar não “circula”. Ai entra o papel da mesa para forçar a circulação de ar, de modo a eliminar o ar quente que foi dissipado do notebook.




Na próxima figura, mostramos o gráfico de uso da CPU que se mantém em 5 % com alguns picos de quase 80 %, mas depois “volta” aos 5% e baixo calor nas memórias, placa de vídeo e CPU.
Quando a CPU e memória ficavam quentes, isto é, temperaturas próximas a 60 graus celsius, a CPU ficava mais lenta e depois de um tempo e usando programas pesados como a IDE Eclipse Kepler para desenvolvimento em linguagem Java, a CPU travava.




CONCLUSÕES

Mostramos de maneira simples como melhorar o desempenho do computador enquanto não se tem “grana” para comprar o outro notebook. Além disso, fica claro que intervenções são necessárias para melhorar a circulação de ar no notebook. Para notebooks novos, isso violaria a garantia, mas para notebooks antigos (como esse do artigo), ganharia mais tempo de uso.


REFERÊNCIAS




quarta-feira, 19 de março de 2014

Primeiros Passos com o Raspberry PI



INTRODUÇÃO

Nesse artigo vamos explicar como configurar o Raspberry PI de modo a deixá-lo operacional ao usuário. Para quem não conhece, o Raspberry PI é um mini computador portátil e de baixo custo. A proposta do Raspberry PI é custar aproximadamente US$ 35,00. No Brasil, o seu preço somando os impostos como taxas de importações, etc, o preço é de aproximadamente R$ 199,00. Mesmo assim, comparando com outros computadores que chegam a custar milhares de reais, o Raspberry PI mostrou-se um computador de baixo custo e útil. Na próxima seção, vamos descrever as suas características e configurações.


DESENVOLVIMENTO

Na figura a seguir, vemos como o Raspberry PI foi configurado e conectado para poder funcionar como um computador com vídeo em HD (saída HDMI), conexão a internet (saída cabo de rede ethernet), mouse, teclado (2 saídas USB), dispositivo de armazenamento, que vai fazer o “papel” do disco rígido que é um cartão portátil SD. E por último, a fonte de alimentação que geralmente é uma fonte de algum smartphone que forneça no mínimo 700 mA de corrente e 5 volts de tensão. Nessa figura, está sendo usado uma fonte de smartphone da marca “samsung” de 1A e 5 volts.

Custos:

1 Raspberry PI modelo B de 512 MB – R$ 199,00
1 Caixa de proteção transparente* – R$ 35,00
1 Fonte de 1 A – 5 volts – carregador de smartphone – R$ 99,00
1 Cartão SD de 16 GB – R$ 65,00
1 Mouse – R$ 30,00
1 Teclado – R$ 30,00

Total: R$ 458,00

OBS: Nessa lista não foram inclusos os cabos de rede, hdmi, roteador, monitor ou televisão.


* A caixa de proteção foi comprada depois de ser tirada essa foto, mas a caixa ajuda a proteger o aparelho, apesar que o ideal mesmo é deixar o Raspberry PI aberto para ter mais ventilação e menos problemas com aquecimento. Bom, esses testes de stress não foram feitos e não foram notados problemas com aquecimento nele.







Nas próximas figuras, serão mostrados os passos necessários para instalar/configurar o sistema operacional Raspbian. Esse sistema operacional é derivado do debian (http://www.debian.org) e foi ajustado para ser instalado no hardware do Raspberry PI. Nessas figuras, estamos supondo que o leitor já tenha o cartão SD formatado e com o NOOBS (New Out Of Box Software) instalado. Caso não tenha o cartão SD instalado com NOOBS, acesse a página (http://www.raspberrypi.org/quick-start-guide) para poder seguir os passos para a instalação do NOOBS. Esse software permitirá escolher o sistema operacional da melhor maneira possível, pois se o sistema operacional escolhido der “pau” ou não funcionar, tem uma opção que é clicar em “shift” na inicialização do sistema para entrar no modo resgate e reinstalar o mesmo.



Instalação do sistema operacional pelo NOOBS.








Configurando o Raspbian

Nessa próxima etapa vamos configurar o Raspbian com a localização do usuário, teclado, habilitar um servidor SSH para comunicação remota e outros. Lembrando que um servidor SSH habilitado permite acesso remoto de outro micro ao raspberry em console e conexão segura. Esse tipo de servidor já vem junto com o Raspbian no momento da instalação. O acesso a servidores SSH pode ser feito por clientes SSH como o WinSCP (http://winscp.net para windows). Outra opção é usar o programa SAMBA (http://www.samba.org) para compartilhar arquivos entre windows e linux. Nesse caso, precisaria instalar pacotes “.deb” relacionados ao SAMBA para instalar o servidor SAMBA de arquivos.



















CONCLUSÃO

Nesse artigo mostramos um pouco do minicomputador portátil Raspberry PI e algumas configurações para poder usá-lo. Lembrando que o Raspberry PI pode ser conectado com outras placas controladoras como Arduíno (http://www.arduino.cc) através das portas GPIO (http://elinux.org/Rpi_Low-level_peripherals). E também, podemos instalar servidores web como o Apache WebService (chamado de httpd no linux, http://httpd.apache.org) para rodar no Raspberry PI. Mas usar servidor web + banco de dados (PostgreSQL, http://www.postgresql.org) + servidor de aplicações JBoss (http://www.wildfly.org)
no mesmo Raspberry PI não é possível, digo isso em questões de performance, pois esse minicomputador não “aguenta” e fica lento. O ideal é montar um cluster de Raspberry PI e colocá-los interconectados por um roteador de alta velocidade e baixa latência, nesse caso, cada Raspberry PI teria apenas um servidor. Por exemplo, o Raspberry PI nome “A” rodaria só o banco de dados Postgresql, o Raspberry PI nome “B” rodaria o servidor Apache (httpd) e por último, o Raspberry PI nome “C” rodaria o servidor de aplicações JBoss.
Além disso, existe outro projeto no site http://arkos.io que visa fornecer um sistema operacional linux modificado para subir alguns servidores como web, banco de dados e outros. O mais interessante no projeto é o painel de gerenciamento desse sistema operacional (dashboard), que mostram as informações de maneira organizada e fácil de administrar. Pois para quem administra servidores, precisa sempre ter uma lista de comandos para verificar logs (o famoso comando “tail -f -n 50 arquivo.log”), iniciar, parar httpd, verificar banco de dados, etc. Quase sempre essa lista existe explicitamente num papel ou implicitamente na memória do administrador. Mas esse projeto tem o problema de estar no estado “Beta” e ainda precisa amadurecer mais para ter um uso mais confiável no Raspberry PI.



REFERÊNCIAS

Site oficial do projeto

Artigos técnicos

Faqs

Techtudo


Sites para compra de Raspberry PI:

Laboratório da garagem

Robocore

Farnell