Troubleshooting Resolve OutOfMemory no Jetty c/ o Sonar

 

 

Olá Pessoal,,

O troubleshooting de hoje é para quem tentou fazer o deploy do sonar.war localmente no jJtty e recebeu o velho e famoso OutOfMemory permgen. Chato né?

 

E como resolver?

No windows, vá até a pasta onde está o jetty e procure o arquivo start.ini e adicione no final do arquivo:

 –exec

-Xmx512m

-XX:MaxPermSize=256m

No linux: 

Você precisa alterar o arquivo jetty.sh que está dentro da pasta bin. Adicione o trecho abaixo na linha 81, removendo o #.

export JAVA_OPTIONS=”-Xmx512m -XX:MaxPermSize=265m”

Pronto, isso já resolverá o problema. Agora basta executar o start.bat ou jetty.sh, depende do seu OS.

Abracos, see ya!!

Resolvendo LazyInitializationException em 5 minutos

Olá Pessoal,

No post de hoje vamos ver como podemos resolver o LazyInitializationException em 5 minutos. Dificilmente um desenvolvedor não passou por essa exceção. Não vou entrar em detalhes sobre o motivo  da exceção LazyInitializationException, até por que já falei em um post aqui no blog, usando a solução com filter.

Lets go…

Na prática

Para mostrar a solução na prática, vou pegar um exemplo simples. Vamos considerar o relacionamento de que um Type  tem muitos Users, veja

@Entity

@Table(name = “type”)

public class Type implements java.io.Serializable { 

private static final long serialVersionUID = 2644022136811709451L; 

private Long id;

private String description;

private Set<User> users = new HashSet<User>(); 

public Type() {

}

@Id

@GeneratedValue

@Column(name = “ID”, unique = true, nullable = false)

public Long getId() {

return this.id;

}

@OneToMany(fetch = FetchType.LAZY, mappedBy = “type”,  targetEntity=User.class)

public Set<User> getUsers() {

return this.users;

}

//getters/setters omitidos

}

User.java

@Entity

@Table(name = “user”, uniqueConstraints = @UniqueConstraint(columnNames = “EMAIL”))

public class User implements java.io.Serializable,Comparable<User> { 

private static final long serialVersionUID = 9108778602728711429L; 

//declaração de variaveis omitidas 

@ManyToOne(fetch = FetchType.LAZY)

@JoinColumn(name = “TYPE_ID”,nullable=false)

public Type getType() {

return this.type;

}

//getters/setters omitidos

} 

Nada de especial até aqui, apenas o relacionamento que já conhecemos.

O problema

Agora que temos o problema, quando o User.java tentar acessar o Type e a conexão já foi fechada, já sabemos que vamos resolver LazyInitializationException. Uma forma para resolver é usando  join fetch, que evitará o problema pelo seguinte motivo:

– Apenas uma consulta será feita e evitamos o problema N + 1;

– A realização da consulta vai deixar de ser Lazy para Eager. Isso é diferente de você mudar de Lazy para Eager.

No DAO

Devemos ter a consulta assim:

public class UserDAO{

public List<User> readAll() {

                //avoiding LazyInitializationException join fetch

                String hql = “select u from User u join fetch u.type”;

                Query query = getCurrentSession().createQuery(hql);

                return query.list();

        }

}

Pronto. Resolvido seu problema com LazyInitializationException. Mas um detalhe importante é que para cada coleção que temos, é uma consulta que devemos ter. Se Type tem uma coleção de acesso, é uma consulta.

Bom é isso. Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!! 

Troubleshooting cglib AOP Exception

 

Olá Pessoal,

O post esse acho que é o menor que já escrevi. Vamos ver como resolver a exceção AopConfigException quando estamos adicionando ao nosso projeto Java. veja:

O problema

Se você está recebendo:

org.springframework.aop.framework.AopConfigException: Cannot proxy target class because CGLIB2 is not available. Add CGLIB to the class path or specify proxy interfaces.

Solução

Adicione cglib ao seu projeto, faça o download http://cglib.sourceforge.net/

Muito simples não?

Abraços, see ya!! 

Troubleshooting shutdown Jboss AS 7

 

 

Olá Pessoal,

No troubelshooting de hoje vamos ver como dar um shootdown no Jboss AS 7. Como é? Isso é fácil. Bem, não tanto quanto parece. Gastei umas 3h até achar a solução correta e que ainda não fiquei conformado que seria a melhor. Não sei porque o pessoal da JBoss não fez algo mais simples, mas enfim.

lets go..

 

Starting… 

Se você está rodando o Jboss AS 7 com via maven e depois que fez o deploy quer parar o servidor, o que fazer? Se rodou pelo Eclipse e dá um terminate no console, apenas acontece o undeploy da aplicação. Mas se você acessar o servidor http://localhost:8080 ele continua rodando. Iai, como resolver? Eu vivi umas 3h no inferno até resolver, porque eu não queria fazer o deploy da minha app usando o Run as Server do Eclipse, até porque essa opção do Eclipse requer que tenha o Jboss na minha máquina local e aponte pra onde está instalado, e via maven, deixo ele se virar para achar minhas dependências e plugins.

 

Solução 

É uma piada a solução, mas é essa aqui:

1. Se tiver usando o Windows vá onde o maven fez o deploy da sua aplicação (via cmd), no console do Eclipse quando você executou mvn jboss:run ele diz onde foi o deploy. 

2. Entre na pasta bin e execute o comando abaixo 

jboss-cli.bat –connect command=:shutdown

3. Depois dê enter e pronto. Você acabou de derrubar o servidor. 

Note: Se for Linux use o arquivo jboss-cli.sh o restante é igual.

Simples, não?

Abraços see ya!!!

Troubleshooting PersistenceExceptionTranslationInterceptor Spring

 

Olá Pessoal,

O troubleshooting de hoje é para qume está sobrendo com o Hibernate e Spring.  Vamos ver os erros e como podemos resolver. 

Caused by: java.lang.IllegalStateException: No persistence exception translators found in bean factory. Cannot perform exception translation.

                at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.detectPersistenceExceptionTranslators

Esse erro acontece normalmente quando estamos usando a versão do Hibernate 4 no Spring, porém usando as configurações do Hibernate 3. A resolução é simples, veja:

No hibernate 3 usamos o translation assim:

<bean class=”org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor”/>

No Hibernate 4.x deve ser assim:

<bean class=”org.springframework.orm.hibernate4.HibernateExceptionTranslator”/>

O sessionFactory também deve ser alterado, veja:

No Hibernate 3 é assim:

<bean id=”sessionFactory” class=”org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean”>

Mas no Hibernate 4 deve ser assim:

<bean id=”sessionFactory” class=”org.springframework.orm.hibernate4.LocalSessionFactoryBean”>

Pronto! Assim resolvemos a exception de translation com Hibernate. Fiquem espertos com esses detalhes para não gastar tanto tempo.

Abracos, see ya!!