Tag Archives: java

Java @Schedule error

I was trying to scheduling a method from a EJB class using the @Schedule annotation of the javax.ejb package.

@Schedule(second=”*/5″, minute=”*”, hour=”*”)
public void listarMsgs()
{
logger.log(Level.INFO, “do something…”);
}

But every time the method was called it  appeared a error like this:

Failed to reinstate timer…

Googling for about some time I figure out that it was a kind bug of the application server, JBoss Wildfly. I’m using the 9 version.

The solution was clear the folder under the standalone/data/timer-service-data that is where the server creates the xml of the schedule job.

Microservices boundaries

Fronteira entre serviços

Sob a nova perspectiva de softwares como microservices surge um desafio em identificar as fronteiras entre estes que compõem a aplicação.

Duas abordagens podem ser consideradas, ambas baseadas no princípio da Single Responsible Principle (Princípio da Responsabilidade Única):

A primeira estabelece que os microservices devem ser identificados por meio do verbo de execução de sua responsabilidade. Por exemplo, em uma aplicação de Gerência de Estoques, como a twarehouse em tetraTI, ao analisarmos as ações de entrada de produtos, o cadastro e análise daqueles com baixa em estoque, teríamos assim 3 candidatos a microservices: Entrada de Produtos Service, Cadastro de Produtos Service e Analisador de Baixa Service.

A outra abordagem é a de definir fronteiras por meio da identificação das entidades ou recursos oferecidos pelo sistema. Dessa forma e utilizando o exemplo acima teríamos serviços como Movimentação Service, responsável por todas as operações de movimentação. Ou Analisador de Estoque Service, que forneceria informações em tempo real sobre o estoque.

É muito sutil a escolha ou identificação de serviços por meio de suas fronteiras, que juntos definem a aplicação em si. Para enfrentar este desafio deste novo conceito de SaaS e usufruir de suas vantagens será necessário bom senso e experiência por parte do arquiteto.

Fonte: Devmedia e Building Microservices Book.

Conteúdo estático no Wildfly em produção

upload-cloud

Neste Post demonstrarei como utilizar de forma eficiente imagens como conteúdo estático em uma aplicação Java Web com JSF que rode em um ambiente Linux e num servidor WildFly 8.x.

A ideia é utilizar imagens no cadastro de produtos, fazendo seu upload e exibindo-as em diversas partes.

upload_1

As ferramentas necessárias são o PuTTy para criação do diretório no servidor e um editor xml para configuração do Handler no arquivo de configuração do WildFly. No meu caso utilizei o próprio Eclise IDE. Claro que assumindo que já exista uma aplicação com as devidas configurações e rodando. Disponibilizarei a classe que utilizo para tratar o upload da imagem também.

Criando a estrutura de diretório: a aplicação está hospedada num servidor integrator.com.br, portanto definia a seguinte estrutura:

upload_2

Para criação dos diretório é necessário pelo PuTTy criar os diretórios a partir da pasta home, assim: /home/<<usuário>>/var/static/images/pecas.

Configurando o handler no WildFly: agora que as pastas estão criadas é necessário mapear esta estrutura no servidor de aplicação para que possamos acessá-lo. Para isso configuramos o arquivo de configuração, standalone.xml, da seguinte forma:

upload_3

O handler mapeará o caminho definido em /imagens/meu-espaco. Para acessar o conteúdo do diretório basta acessar a url http://<<endereço_do_servidor>>/imagens/meu-espaco.  A opção directory-listing permite que seu conteúdo seja listado:

upload_4

A classe para upload da imagem: o mecanismo de upload é simples graças ao componente Upload da biblioteca PrimeFaces. Sua utilização é simples:
upload_5

A classe FotoProdutoBean encaminhará a ação à Camada de Serviço de produto, que utilizará a classe FotoHelper para escrever o conteúdo do download para o diretório definido.

upload_6

A constante CAMINHO_DAS_FOTOS contém o caminho para o nosso diretório de conteúdo estático, isto é, nossas fotos de produtos (peças): /home/meuvisua/var/static/images/pecas/.

Exibindo as imagens: Enfim, para exibir a imagem basta uma tab <img> html com o mapeamento. Desta forma:

upload_7

Só isso! Ao utilizarmos o handler para mapear um diretório fora do servidor de aplicação tornamos nosso conteúdo estático independente. Num cenário de atualização ou substituição do servidor nada será afetado. Ainda, assim evitamos também salvarmos essas imagens direto no banco, impactando a performance.

Se alguém tiver uma solução melhor ou alternativa, comentem.

Até o próximo.