JBossInBossa 2010

February 4th, 2010 by rafaelliu No comments »

O evento ocorrerá dias 16 e 17 de Abril em São Paulo

O JBossInBossa 2010 é a conferência anual da comunidade JBoss brasileira, ele contará com palestrantes internacionais que são líderes de projetos opensource, bem como palestras da comunidade brasileira que desenvolve e fomenta tecnologias relaciodas além do time brasileiro JBoss que atua em diversos projetos de missão crítica que usam tecnologias de ponta em projetos em todos os lugares do Brasil.

Mais informações: JBossInBossa

Agente JON/Jopr não sobre no boot

January 26th, 2010 by rafaelliu 1 comment »

JON 2.3.0.GA

O jeito mais comun de se adicionar o JON/Jopr para subir no boot (Red Hat Enterprise Linux)

  1. criar um link simbólico:
    ln -sf $RHQ_AGENT_HOME/bin/rhq-agent-wrapper.sh /etc/init.d/rhq-agent
  2. adicionar à lista de serviços:
    chkconfig --add rhq-agent

Agora basta rebootar e… Não funciona. Agora tente executar /etc/init.d/rhq-agent start. Funciona!!

A razão é que o bash script rhq-agent-wrapper.sh tenta achar o $RHQ_AGENT_HOME automaticamente através do path do script. Dá para ver isso na linha:

_DOLLARZERO=`readlink "$0" || echo "$0"`

Para quem não conhece bash script o $0 é o argumento 0, que corresponde ao caminho do arquivo sendo executado. O que acontece nessa linha é que a variável recebe o caminho do link derreferenciado, caso o arquivo seja um link, ou o caminho do arquivo, caso seja um arquivo mesmo (aliás é por isso que usamos um link no passo 1, senão o script acharia que /etc/init.d é o $RHQ_AGENT_HOME).

O chkconfig é a ferramenta usada no RHEL para registrar serviços. Nela registramos que serviços queremos subir em que níveis de inicialização. Esses níveis são (direto do inittab):

#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)

O problema é que o chkconfig usa, para registrar os serviços, links simbólicos nas pastas /etc/rcX.d (onde X é o nível de inicialização). O que acontece então é o que é executado é um link simbólico em /etc/rc3.d apontando para o link simbólico /etc/init.d apontando para $RHQ_AGENT_HOME/bin. Algo do tipo:

/etc/rc3.d/S93rhq-agent -> /etc/init.d/rhq-agent -> $RHQ_AGENT_HOME/bin/rhq-agent-wrapper.sh

E o comando readlink não é recursivo por padrão, ou seja, se o link derreferenciado apontar para outro link, o readlink não o derreferencia.. A solução está no readlink –help: adicionar a flag -e.

Ou seja, basta mudar a linha 102 para:

_DOLLARZERO=`readlink -e "$0" || echo "$0"`

Fonte: JIRA

Criando um portlet para o GateIn

January 24th, 2010 by rafaelliu 4 comments »

Já vimos que portlets são na verdade aplicações web que podem ser reutilizadas, vamos ver nesse post como criar essas aplicações web. Para quem usa o Eclipse para criação e publicação de aplicações no JBoss está em casa. Vamos precisar:

  • Eclipse JEE
  • GateIn 3 Beta5 para JBoss

Primeiramente vamos criar uma Dynamic Web Project comun no Eclipse e crie um novo Target Runtime.

Selecione JBoss 5.0 e peça para criar um server, aponte esse servidor para o local de instalação do GateIn:

Agora que temos nosso projeto criado, vamos precisar adicionar as bibliotecas do GateIn localizadas em <JBOSS_HOME>/server/default/deploy/gatein.ear/lib ao Build Path:

Portlets são muito similares a servlets: assim como estendemos a classe HttpServert para criar servlets, estendemos a classe GenericPortlet para gerar portlets. Crie a seguinte classe:

public class VaiPlanetaPortlet extends GenericPortlet {
 
	@Override
	protected void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
		response.getWriter().print("Vai Planeta!!");
	}
 
}

Note os parâmetros request e response e o print(), não lembra servlets? Agora só falta declarar esse nosso portlet! De novo fazendo uma analogia a servlets: do mesmo modo que servlets são declarados no web.xml, portlets são declarados no portlet.xml. Crie então um arquivo portlets.xml no WEB-INF com o seguinte conteúdo:

<?xml version="1.0" encoding="UTF-8"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0">
	<portlet>
		<portlet-name>VaiPlanetaPortlet</portlet-name>
		<portlet-class>net.rafaelliu.VaiPlanetaPortlet</portlet-class>
 
		<supports>
			<mime-type>text/html</mime-type>
		</supports>
 
		<portlet-info>
			<title>Portlet Vai Planeta</title>
		</portlet-info>
	</portlet>
</portlet-app>

Pronto, já temos nosso portlet. Faça deploy dele como faria com uma aplicação web comun e importe o portlet no GateIn.

NullPointerException e o @EJB

January 11th, 2010 by rafaelliu 3 comments »

Um pouco de história…

Assim que a especificação JEE 5 saiu, com EJB 3 e suas anotações, houve interesse imediato da comunidade. O JBoss ainda em sua versão 4, não implementava completamente a especificação JEE 5, mas devido ao grande interesse e como um passo em direção ao JEE 5, suporte ao EJB 3 foi introduzido.

Isso causou alguma confusão a respeito ao uso da anotação @EJB (ou @Resource, @WebServiceRef, em fim) para injeção. Para quem não conhece, a anotação @EJB pode ser usada para injetar EJBs em Servlets puros, JSF Managed Beans, JAX-WS endpoints, entre outros. Foi a partir do JBoss 5, essa sim versão implementando JEE 5, que suporte a essa anotação foi introduzido.

Para os impacientes…

Mesmo usando o JBoss 5, ainda assim é preciso definir no seu web.xml que a versão Servlet sendo utilizada é a 2.5, especificação que contém esse tipo de injeção:

Note o post não se aplica ao uso dessas anotações para injeção em EJBs, que já é suportado desde de o JBoss 4 e não tem relação alguma com web.xml.

Ajude a traduzir o GateIn

January 11th, 2010 by rafaelliu 4 comments »

Muito anúncio Polishop mas…

Quer ajudar o GateIn e ganhar seu nome na lista de contribuidores? Traduza o GateIn para português! É fácil: acesse a wiki e veja

Portais em 1 minuto

January 4th, 2010 by rafaelliu No comments »

Até agora já postei algumas vezes sobre a nova solução de portal da JBoss, o GateIn. Enquanto escrevia meu terceiro post (aguardem!!) me dei conta que muitos podem não ter a mínima idéia do que estou falando. O que é uma ferramenta de portal? Eu preciso de uma ferramenta dessas? Como ela pode me ajudar? Como faço para utilizá-la? Bom, tomei um tempo para escrever um pouco sobre conceitos.

O que são portais?

Antes de saber como o GateIn pode ajudá-lo a construir portais, vamos ao que são portais (por simplicidade vou chamar portlet containers também de portais).

Um portal é um site que organiza grandes quantidades de informações em um único lugar, disponibilizando-as de forma consistente e organizada. Usualmente possuem serviço de busca de conteúdo e navegabilidade. Podem também oferecer meios de interação como canais de help desk, ouvidoria, etc. Alguns exemplos devem dar uma noção mais concreta, eles são: intranets de grandes empresas, órgãos do governo como MCT, Transparência e portais públicos como o UOL, Terra, Yahoo.

Com o conceito em mente, vamos partir para a parte técnica da pergunta: como uma solução de portal pode te ajudar? O GateIn implementa (e estende) as JSR 168 e JSR 286, Portlet 1.0 e 2.0, que são as especificações Java para definição de modos, estados, ciclo de vida e tudo que concerne o uso de portlets em portais. O que nos leva à próxima pergunta..

O que são portlets?

Lembro de quando programava em ASP, como achava SSI o ó do borogodó. Desde de aquele tempo as formas de reutilização vêm ficando cara vez mais sofisticada, passando pelo <jsp:include>, o Tiles (com o nem tão saudoso Struts) até o Facelets (agora parte da especificação JSF 2.0).

Portlets têm outra abordagem à reutilização, ao invés de dividir a aplicação em partes reutilizáveis, eles encapsulam aplicações em componentes reutilizáveis. Não entendeu? Eu desenho:

Aplicação web comum

Portlets

Esses componentes são diferentes de aplicações web, e não basta fazer deploy delas em um container web, elas precisam de um container especial. Esse container é o portal:

É através do desenvolvimento de portlets que são adicionadas funcionalidades e conteúdo ao portal. Uma vez desenvolvido, é feito seu deploy no GateIn.

Pensando para portais

Para desenvolver portais é preciso um pensamento diferente. Do mesmo jeito que os serviços SOA são organizados em processos, os portlets são sindicados em um portal. Os mesmo cuidados de se pensar serviços como unidades reutilizáveis são precisos para portlets. Do mesmo jeito, para tirar o máximo do desenvolvimento de portais é preciso de uma governança para prover reuso, catalogar, monitorar e auditar portlets. Gartner chegou a sugerir portais como um ponto de entrada para SOA.

Vejo ferramentas de portal como uma necessidade que surgiu do desenvolvimento em cima de servidores de aplicação (como o JBoss). Servidores de aplicação não foram criados para servir conteúdo web, isso é apenas uma de suas funcionalidades, eles fazem muito mais do que isso. Portais por outro lado foram desenvolvidos exclusivamente para conteúdo web, e por isso trazem uma gama de facilidades voltadas para esse fim.

Show me the money

(StarCraft? não?) Embora tenha batido muito no aspecto de reusabilidade, que acho o mais central, existem várias outras facilidades:

  • Sindicância de conteúdo: é possível consolidar conteúdos ou outras aplicações web sob a mesma apresentação;
  • Single Sign-on: federando-se aplicações web, é possível tirar vantagem de SSO. Uma vez que o usuário esteja logado no portal suas credenciais podem ser propagadas para as aplicações contidas nele;
  • Personalização: como o portal toma conta da apresentação, é possível ter vários níveis de personalização como tematização e internacionalização;
  • Reusabilidade: aplicações e conteúdos podem ser reaproveitados em diferentes locais dentro do portal ou mesmo em outros portais;
  • Automatização: a criação de menus de navegação, breadcrumb, site map, segurança, layout, etc. são providas out of the box.

Devido às várias facilidades providas, a palavra “portal” das ferrramentas de portal assumiu um sentido mais amplo do que o conceituado no começo do post. Sites de pequeno porte, que na realidade partilham pouco com portais, podem se beneficiar do uso dessas ferramentas.

Para ver tudo isso em ação, dêem uma olhada no post de lançamento do GateIn.

Novidade

December 28th, 2009 by rafaelliu 2 comments »

O blog está de hospedagem nova! Depois de alguns problemas com o host passado, mudei para o Helio Host. Estou bem satisfeito até agora (é gratuito, custa nada dar uma divulgada..). Aproveitando o clima de mudança mudei também o tema, agora menos dark.

Feliz natal e ano novo a todos!

Conferência Internacional de Segurança de Aplicações (AppSec Brasil 2009)

October 22nd, 2009 by rafaelliu No comments »

Acontecerá nos dias de 27 a 30 de outubro:

A comunidade Comunidade TI-Controle e o Centro de Informática da Câmara dos Deputados apresentam a Conferência Internacional de Segurança de Aplicações, que será realizada com o apoio do OWASP (Open Web Application Security Project) em Brasília, capital do Brasil. A conferência consistirá de dois dias de treinamentos, seguidos de dois dias de plenárias em trilha única.

Mais informações: AppSec Brasil 2009

Atraso de vida: IE6

October 22nd, 2009 by rafaelliu No comments »

Sou o mais novo participante da campanha. Instalei até plugin do WP

2644891323_e5fb590a93

Deployment no GateIn

September 17th, 2009 by rafaelliu 2 comments »

EDIT: com o novo componente WCI não é mais preciso fazer alterações no web.xml. Em outra ocasião escrevo sobre esse componente.

Vi no JIRA recentemente uma issues aberta indicando problema no deploy de portlets no GateIn. Para quem também não sabe para onde ir vou mostrar como fazer o deploy de portlets nesse portal.

Primeiro precisamos alterar o web.xml da aplicação adicionando:

<filter>
	<filter-name>ResourceRequestFilter</filter-name>
	<filter-class>org.exoplatform.portal.application.ResourceRequestFilter</filter-class>
</filter>
<filter-mapping>
	<filter-name>ResourceRequestFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>
 
<servlet>
	<servlet-name>GateInServlet</servlet-name>
	<servlet-class>org.gatein.wci.api.GateInServlet</servlet-class>
	<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
	<servlet-name>GateInServlet</servlet-name>
	<url-pattern>/gateinservlet</url-pattern>
</servlet-mapping>

Depois basta ir no GateIn, logado com usuário de pelo menos um dos grupos:

  • /organization/management/executive-board
  • /platform/administrators

Logaremos como root, e ir no menu Group -> Administration -> Application Registry:

gatein1

O Application Registry é uma forma de repositório do GateIn. É lá que temos acesso aos portlets e gadgets disponíveis, e onde podemos mudar permissões de acesso e ver detalhes da configuração de cada um deles. Agora clicamos em Auto Import e damos um OK para a mensagem de confirmação:

gatein2

Com isso o GateIn fará um scan de todos os deploys de aplicações web e instalará portlets definidos nelas. Os seus portlets devem aparecer na barra lateral:

gatein3 :)