Middleware

Bysutradi

Duplicar uma QM no IBM WebSphere MQ

Veja abaixo os passo para fazer a duplicação de uma QM no IBM WebSphere MQ (não gastará mais que 2 minutos).

1. Criar nova QM via MQ Explorer

2. Gerar DUMP da QM

cd /opt/mqm/bin

./dmpmqcfg -m -t all -x all > /var/mqm/backup/

3. Restaurar Backup na nova QM

./runmqsc < /var/mqm/backup/

4. Acessar o MQ Explorer e alterar a porta do LISTENER (para evitar conflito com a QM de origem).

Simples e rápido.

Bysutradi

Personalization aplicado à apresentação de menus no Portal

As vezes nos deparamos com solicitações que nos fazem implementar soluções complementares para chegar ao resultado esperado.
Não diferente disso, precisei fazer com que o menu principal criado no WebSphere Portal tivesse o seguinte comportamento: quando o usuário não tiver permissão de acesso a uma página, o menu deve ser apresentado em cinza sem ação de mouse (e não direcionar para a página de destino). Quando o usuário tiver permissão, deve apresentar a página com os portlets. Resumindo: alguns usuários visualizarão a página “Exemplo” que conterá portlets e outros visualização um rótulo “Exemplo”, em cinza, que não possui link.
Porém, este é um comportamento diferente do padrão do produto: quando você não tem acesso a algo, este algo não é carregado/exibido.

Qual a solução encontrada?

A solução que encontramos foi usar o recurso de Personalization (que sobrepões as regras de acesso por usuários/grupos), criando regras opostas aplicadas nas duas páginas com o mesmo nome. Na página “Exemplo” (que contém os portlets) foram aplicadas as regras de permissão normal (com os grupos de acesso normais). Na página “Exemplo” (com mesmo nome, mas sem acesso aos portlets), aplicamos uma regra de personalização oposta à regra aplicada na página “Exemplo” (que contém os portlets) e adicionamos um parâmetro para que o tema possa saber que deve ser criado na cor cinza. A tratativa de exibição em cinza foi feita no tema.

Bysutradi

Usando Cookies em Portlets com JSF 2 no IBM WebSphere Portal 8

Para se usar Cookies em portlets (JSR 286), de acordo com a especificação, bastaria apenas adicionar o XML abaixo no arquivo portlet.xml e implementar o método doHeaders no Portlet.

<container-runtime-option>
	<name>javax.portlet.renderHeaders</name>
	<value>true</value>
</container-runtime-option>

Porém, se você requer usar Cookies em portlets (JSR 286) com JSF 2 no IBM WebSphere Portal, encontrará o problema abaixo:

[14/02/14 12:03:12:180 BRST] 0000006d servlet       E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An exception was thrown by one of the service methods of the servlet [PortletMensagem] in application [PA_PortletMensagem]. Exception created : [java.lang.NullPointerException
	at com.ibm.faces20.portlet.FacesPortlet.init(FacesPortlet.java:131)
	at com.empresa.mensagem.PortletMensagemPortlet.init(PortletMensagemPortlet.java:38)
	at javax.portlet.GenericPortlet.init(GenericPortlet.java:107)

Diante deste cenário, pensamos em soluções alternativas definitivas (também chamada de POG) para conseguir chegar no resultado esperado.

Paralelamente ao andamento da implementação que a equipe estava fazendo, INCONFORMADO, resolvi procurar a tal classe que apresentava o erro e verificar (decompilar) o que ela estava fazendo.

Após verificar o que a classe estava fazendo, consegui entender o problema e encontrar a solução.

Juntamente com a opção “renderHeaders”, também necessitaríamos adicionar a opção “actionScopedRequestAttributes”. Veja como ficou nosso portlet.xml agora.

<container-runtime-option>
	<name>javax.portlet.renderHeaders</name>
	<value>true</value>
</container-runtime-option>
<container-runtime-option>
	<name>javax.portlet.actionScopedRequestAttributes</name>
	<value>true</value>
</container-runtime-option>

Após a adição destes dois itens, o portlet passou a entrar normalmente no doHeaders e conseguimos manipular os Cookies.

Bysutradi

Configurar Logging Profile no JBoss EAP 6.1

O JBoss EAP 6.1 contém um recurso chamado Logging Profile, que permite que as aplicações possam usar um profile de Log definido no servidor.

Porém, a documentação da Red Hat para o EAP apresenta somente a configuração necessária para usar o Logging Profile em standalone.

Se for usar seu EAP 6.1 em modo Domain, a configuração muda “ligeiramente” do que está na documentação da Red Hat.

Vou apresentar abaixo o que você precisa fazer.

1. Inicie seu JBoss em modo Domain.

2. Em uma outra janela  do seu terminal (ou CMD), execute o script jboss-cli.

./jboss-cli.sh -c

3. Execute os comandos abaixo para criar um Logging Profile, um Logging Handler.

/profile=full-ha/subsystem=logging/logging-profile=MY_LOGGING_PROFILE/:add
/profile=full-ha/subsystem=logging/logging-profile=MY_LOGGING_PROFILE/file-handler=MY_LOGGING_PROFILE_HANDLER:add(file={path=>"MY-LOG-FILE.log", "relative-to"=>"jboss.server.log.dir"})
/profile=full-ha/subsystem=logging/logging-profile=MY_LOGGING_PROFILE/file-handler=MY_LOGGING_PROFILE_HANDLER:change-log-level(level="DEBUG")
/profile=full-ha/subsystem=logging/logging-profile=MY_LOGGING_PROFILE/logger=com.mycompany.myapp:add(level=TRACE)
/profile=full-ha/subsystem=logging/logging-profile=MY_LOGGING_PROFILE/logger=com.mycompany.myapp:assign-handler(name="MY_LOGGING_PROFILE_HANDLER")

A diferença para a configuração na Red Hat é a definição do profile no início de cada comando.

Estes comandos alteram o arquivo domain.xml adicionando o trecho de código abaixo no profile “full-ha“.

<logging-profiles>
   <logging-profile name="MY_LOGGING_PROFILE">
        <file-handler name="MY_LOGGING_PROFILE_HANDLER">
            <level name="DEBUG"/>
            <file relative-to="jboss.server.log.dir" path="MY-LOG-FILE.log"/>
        </file-handler>
        <logger category="com.mycompany.myapp">
            <level name="TRACE"/>
            <handlers>
                <handler name="MY_LOGGING_PROFILE_HANDLER"/>
            </handlers>
        </logger>
    </logging-profile>
</logging-profiles>

4. Configure seu pom.xml para adicionar o nome do Logging Profile no MANIFEST.MF.

Para projetos WAR

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-war-plugin</artifactId>
	<version>2.3</version>
	<configuration>
		<filteringDeploymentDescriptors>true</filteringDeploymentDescriptors>
		<archive>
		<manifestEntries>
      <Logging-Profile>MY_LOGGING_PROFILE</Logging-Profile>
    </manifestEntries>
    </archive>
	</configuration>
</plugin>

Para projetos JAR/EJB

<plugin>
 <groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jar-plugin</artifactId>
	<version>2.4</version>
	<configuration>
		<filteringDeploymentDescriptors>true</filteringDeploymentDescriptors>
		<archive>
		<manifestEntries>
      <Logging-Profile>MY_LOGGING_PROFILE</Logging-Profile>
    </manifestEntries>
    </archive>
	</configuration>
</plugin>

Estas configurações foram validadas em projetos WAR com JSF e projetos EJB 3, implantados no EAP 6.1 em uma configuração MASTER com 1 SERVER GROUP com 1 SERVER.

Momendo #ficadica

Aqui #ficadica para alguém da Red Hat fazer a adição em sua documentação do EAP para que outros profissionais possam otimizar suas configurações ao ler as documentações do produto.

Momento #naogostei

Agora que as configurações foram feitas e foram validadas tecnicamente em projetos, vou colocar aqui o que acabou me deixando um pouco frustrado com Red Hat / JBoss.

Me frustrou bastante o fato que a documentação do EAP (pelo menos para este item) apresentar somente configurações com foco no modo Standalone.

Outro ponto que achei ruim foi o fato que, os códigos de erro que os comandos me apresentaram durante esta aprendizagem, não foram encontrados em mecanismos de busca, aumentando o tempo necessário para encontrar uma solução.