Como gerar classes Java para o Hibernate a partir de tabelas de banco de dados MySql no Eclipse Indigo

1. Instale o JBoss Tools no Eclipse usando o Update Site
   No Eclipse Indigo, na barra de menu, clique em Help / Install New Software
   Cole este endereço no campo de texto Work with e clique em Add... http://download.jboss.org/jbosstools/updates/development/indigo/
   O plugin é obrigatório o JBoss Data Services / Hibernate Tools, mas é bom instalar todos eles
   
2. Crie um Hibernate Configuration
   Abra a perspectiva Hibernate
   No painel Hibernate Configurations, clique com o botão direito em um espaço vazio e vá em Add Configuration
   No campo Project, selecione o projeto onde as classes Java serão criadas
   No combo box Database Connection selecione uma conexão MySql existente ou crie uma nova clicando no botão New
   No campo Property file, clique em Setup / Create new
   No campo Configuration file, clique em Setup / Create new
   Clique em OK
   
3. Execute o Hinernate Code Generation
   Edite o arquivo hibernate.cfg.xml. Remova a propriedade name na tag session-factory. Deixe-a sem atributos.
   Adicione o hibernate-tools.jar ao classpath do projeto. Esse jar pode ser encontrado em <eclipse folder> \ plugins \ org.jboss.tools.hibernateextension4_0_3.4.0.v20111213-1944-H40-M5 \ lib \ tools
   Na perspectiva Hibernate, na barra de menu, clique em Run / Hibernate Code Generation / Hibernate  Code Generation Configurations
   Em Console configuration, selecione a configuração recém criada
   Em Output directory, selecione a pasta raiz do código fonte
   Em package, preencha com o nome de pacote desejado
   Em revenge.xml, clique em Setup / Create new
   Em reveng. stratagy, Click em Browse e selecione a classe org.hibernate.cfg.reveng.DefaultReverseEngineeringStrategy
   Clique no botão Run
   
4. Verifique as classes geradas
   Abra a perspectiva Java EE
   Dê um refresh nos arquivos do projeto
   Veja que as classes de entidade e DAO foram geradas
   

Geração de ID's para Oracle e MySql usando Hibernate

Aqui você tem exemplos de geração automática de ID's para banco de dados Oracle e MySql usando Hibernate.

Oracle

...

@Entity
@Table(name = "grupo")
public class Grupo implements GenericModel {


@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "GRUPO_ID_SEQ")
@SequenceGenerator(name = "GRUPO_ID_SEQ", sequenceName = "GRUPO_ID_SEQ", allocationSize = 1)
@Column(nullable=false)
private Long id_grupo;

...

A sequence GRUPO_ID_SEQ deve existir no banco de dados.

Considerando que MySql não tem sequences, se você tentar usar o código acima com MySql você terá a  exceção abaixo em tempo de execução:

Caused by: org.hibernate.MappingException: Dialect does not support sequences
at org.hibernate.dialect.Dialect.getSequenceNextValString(Dialect.java:619)
at org.hibernate.id.SequenceGenerator.configure(SequenceGenerator.java:88)
at org.hibernate.id.SequenceHiLoGenerator.configure(SequenceHiLoGenerator.java:66)
at org.hibernate.id.IdentifierGeneratorFactory.create(IdentifierGeneratorFactory.java:127)

MySQL

...
@Entity
@Table(name = "grupo")
public class Grupo implements GenericModel {


@Id
@GeneratedValue
@Column(nullable=false)
private Long id_grupo;

...

O campo id_grupo deve ser marcado como auto incremento no MySql.

PASSEI: 1Z0-894 Oracle Certified Expert Java Platform, Enterprise Edition 6 JavaServer Pages and Servlet Developer

Fiz a prova no dia 09/12 e consegui passar! Raspando, mas passei.

Estava tirando 70% nos Mocks e esperava passar com uma pontuação de 75% ou 80%, mas a prova foi mais difícil do que eu esperava e passei com 68%.

Como havia postado 22/09, eu baseei meus estudos no Mock e Study Guide da EPractize Labs, porque eu já havia lido o livro Head First J2EE1.4 da Katy Sierra algumas vezes em outras ocasiões. Também dei uma lida na spec de Servlet 3.0.

Eu não recomendo a EPractize Labs. O Study Guide é muito superficial e o Mock tem muitos erros. Além disso o Mock não está coerente com a prova real. A prova não cobra quase nada de Custom Tags e cobra muito da spec de Servlet 3.0, mas o Mock está ao contrário.

O que eu acredito que me salvou foi a página do Piotr (http://piotrnowicki.com/2011/03/jee-6-scwcd-mock-questions/) que tem 67 questões focadas na especificação de Servlet 3.0 e também o Mock da Enthuware (http://enthuware.com/index.php/mock-exams/oracle-certified-expert/oce-jsp-servlet-mock-questions).

Esse Mock é mais barato e a qualidade dele é infinitamente maior. A prova disso é que além de ser 100% Test Pass Garantee, eles devolvem o dinheiro caso você encontre 3 erros. Muitas questões do exame foram bem parecidas com as do Mock.

A minha dica para quem for se preparar para essa prova é:

* Estudar o livro Head First Servlets & JSP, segunda edição (JEE5): http://shop.oreilly.com/product/9780596516680.do?green=25526262438&cmp=af-mybuy-9780596516680.IP
* Estudar a Spec JSR-315 de Servlets 3.0: http://jcp.org/aboutJava/communityprocess/mrel/jsr315/index.html
* Responder as questões do Piotr
* Fazer o Mock do Enthuware

Seguindo esses passos com tempo, com certeza você se sairá melhor do que eu :-)

Bons estudos!

Telnet no Windows Vista

O Windows Vista tem telnet client sim! Só não está habilitado, afinal de contas, por que as vovózinhas iriam querer essa funcionalidade?

Para habilitar, vá no Menu Iniciar, clique em "Executar...", digite "optionalfeatures" (sem aspas) e clique OK.

A janela "Windows Features" vai aparecer, então você pode habilitar o telnet client. Aproveite para habilitar uns jogos também :-). Clique OK e espere muitos minutos.

Precisa reiniciar para se divertir com o telnet.

Como encontrar a tabela de UtcTimeOffsetCode em arquivos TAP3

Uma das informações nos registros Moc (Mobile Originated Calls) e Mtc (Mobile Terminated Calls) é o Call Event Start Time Stamp.

O Call Event Start Time Stamp é formado pelo Local Time Stamp (YYYYMMDDHHMMSS) e pelo Utc Time Offset Code.

Utc Time Offset Code (5F-81-68) pode ser qualquer número inteiro de 0 a 99 e com esta informação, você será capaz de descobrir o UTC Time Offset (5F-81-67).

O problema é esta informação não é padronizado para todos os arquivos TAP, é uma informação auto-contida nos arquivos TAP3, em outra seção. Em outras palavras, cada arquivo TAP3 tem o sua própria lista de Utc Time Offset Code mapeada para um UTC Offset real.

Esta tabela é chamada de Utc Time Offset Info e está localizada na seção Network Information. A sessão Utc Time Offset Info pode ter um ou mais Utc Time Offset Definition e cada Utc Time Offset Definition tem seu o mapeamento entre o Utc Time Offset Code e o Utc Time Offset.

No exemplo das figuras, o código 65 foi mapeado para o UTC Offset -05:00:

O TAP3 foi projetado desta forma para minimizar a quantidade de dados transferidos e para evitar a repetição de informações idênticas no nível de chamada / evento.

Dica:
Programas para trabalhar com arquivos TAP3:
TAP3 Editor (http://www.combil.com/tap3ed2.htm): Usado para ver os registros do TAP3 de forma estruturada
ASN1VE (http://www.obj-sys.com/asn1-viewer.php): Usado para ver o conteúdo binário dos dados ASN.1

Log4j mistura logs entre as aplicações no Weblogic

Tenho um Web Service JWS executado em Weblogic 10.2 e seus logs estavam sendo misturados com outra aplicação web rodando no mesmo servidor.

Eu pensei que as aplicações foram totalmente independentes dentro do servidor, mas elas não são. Elas compartilham alguns classloaders. Veja imagem abaixo:

Esse problema ocorre porque o jog4j.jar é compartilhado entre as aplicações e isto ocorre porque ele é buscado do mesmo classloader.

Para resolver este problema, é necessário que cada aplicativo tenha o seu próprio log4j.jar dentro do .war. (ou .ear quando aplicável). É importante que todas as aplicações tenham seu próprio log4j. Se um deles não tiver, o problema vai continuar.

Além de ter o log4j.jar, também é necessário editar o weblogic-application.xml para avisar o Weblogic para  usar as classes do log4j do classloader da aplicação.

Segue um exemplo de weblogic-application.xml:

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<prefer-application-packages>
   <package-name>org.apache.log4j.*</package-name>
</prefer-application-packages>
</weblogic-application>

Se você estiver usando ant para construir o seu webservice JWS no Weblogic com a task jwsc, segue um trecho de build.xml que você pode usar para colocar o log4j no .war e usar um weblogic-application.xml personalizado.

No .war o log4j.jar deve ser colocado na pasta WEB-INF/lib e no .ear o weblogic-application.xml deve ser colocado na pasta META-INF.

<target name="jwsc" description="build web service">
  
    <delete dir="${build.dir}"/>
    <mkdir dir="${build.dir}"/>  
  
    <jwsc
        srcdir="${webapp.dir}"
        destdir="${build.dir}" 
     verbose="on" debug="on"
     keepGenerated="no" >

     <jws file="${jwsc.file}"
           compiledWsdl="${jwsc.jws.compiledWsdl}"
           contextPath="${jwsc.jws.contextPath}" 
           type="JAXWS" explode="false" >
</jws>
    </jwsc>
  
    <war destfile="${war.built}" update="true" >
        <fileset dir="${webapp.dir}">
           <include name="**/*.jar" />
   </fileset>
    </war>

    <copy file="${service.src}/resource/weblogic-application.xml" todir="${build.dir}/META-INF/" overwrite="true" />
  
 </target>


É importante que ${war.built} aponte para o ,war e o ${webapp.dir} aponte para a pasta com o fonte do webservice que possui pasta WEB-INF, que possui pasta lib, que possui log4j.jar.


Links:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/programming/classloading.html
https://forums.oracle.com/forums/thread.jspa?threadID=689458
http://www.coderanch.com/t/554020/Web-Services/java/adding-jar-files-building-war
http://ant.apache.org/manual/Tasks/war.html

Por que o log4j não está logando?

Recentemente tive um problema com o mecanismo de log em um sistema que tive que dar manutenção.


Ele simplesmente estava ignorando a configuração log4j.properties e logava as mensagens com nível INFO.


Depois de algum tempo eu descobri que ele estava usando common-logging ao invés do log4j puro.


Não há nenhum problema em usar o commons-logging, ela funciona bem. O problema real era que apenas o commons-logging-api.jar e o log4j.jar foram incluídos no classpath. Estava faltando o commons-logging.jar.


Para suportar o log4j, o commos-logging precisa de dois jars no classpath: commons-logging e commons-logging-api.


Depois de adicionar o commons-logging.jar no classpath, o log4j.properties começou a ser lido e respeitado.


Leia mais sobre commons-logging aqui: http://commons.apache.org/logging/guide.html#Jars Included in the Standard Distribution