Demoiselle Framework no WebLogic 12c

Pra quem não sabe, o Demoiselle é um framework que roda sob a plataforma Java EE 6, desenvolvido e mantido pelo SERPRO para ser usado em projetos de todas as esferas do Governo.

No dia 1 de Novermbro do ano passado (2013), foi lançada a versão 2.4.0 conforme o Twitter dos mantenedores do framework. Decidi então saber qual seria a dificuldade de rodar um projeto Demoiselle no Oracle WebLogic 12c.

O WebLogic 12c (versão 12.1.1) foi lançado em Dezembro de 2011 e é compatível e certificado na plataforma Java EE 6, mas foi no ano passado em Julho que recebeu um update (a versão 12.1.2) com uma série de novas features e algumas correções, completando assim o release 12c do Cloud Application Foundation, que serve de infraestrutura para toda a tecnologia Fusion Middleware da Oracle.

Criando um projeto de exemplo e um pacote WAR

Uma grande vantagem do Demoiselle é que é um framework desenvolvido inteiramente com Apache Maven, e possui archetypes para facilitar a criação de novos projetos. Para este teste, vou usar o seguinte archetype:

<groupId>br.gov.frameworkdemoiselle.archetypes</groupId>
<artifactId>demoiselle-jsf-jpa</artifactId>
<version>2.4.0</version>

O comando para criar um projeto a partir deste archetype pode ser este:

$ mvn archetype:generate \
-DarchetypeGroupId=br.gov.frameworkdemoiselle.archetypes \
 -DarchetypeArtifactId=demoiselle-jsf-jpa \
 -DarchetypeVersion=2.4.0 \
 -DgroupId=br.gov.frameworkdemoiselle.sample \
-DartifactId=demoiselle-sample-2.4.0 \
 -Dversion=1.0.0-SNAPSHOT \
 -DinteractiveMode=false

O nome do projeto será demoiselle-sample-2.4.0. 

Ajuste a configuração JPA do projeto

O Demoiselle vem com um arquivo persistence.xml no diretório src/main/resources/META-INF e este arquivo deve ser editado da seguinte maneira: 

1. Comente a configuração que está ativa logo no início do arquivo (específica para JBoss)
2. Descomente a segunda configuração para GlassFish, chamada "GlassFish 3 with JTA transaction"
3. Modifique o JNDI do Data Source para o seguinte valor: jdbc/demoiselle

Geração do pacote WAR

Agora para ter um arquivo WAR pronto para ser instalado no WebLogic, basta gerar o pacote: 

$ mvn -Pglassfish3 package

Repare que especifico o profile chamado glassfish3. Isto porque o Demoiselle possui uma série de profiles para cada servidor de aplicação (tomcat6, tomcat7, glassfish3, jboss6, jboss7). No momento em que escrevo este blog, meu pedido para acrescentar o profile do WebLogic 12c ainda não foi aceito. Acompanhe o pull request no GitHub para maiores detalhes e atualizações.

Mas não tem problema especificar o profile já existente glassfish3, pois este atende às especificações do Java EE 6, e o WAR resultante funciona perfeitamente no WebLogic 12c. 

Agora você deve ter no diretório target do projeto, um arquivo chamado demoiselle-sample-2.4.0-1.0.0-SNAPSHOT.war. Anote o local e o nome deste arquivo para depois fazermos deploy deste artefato.

Download, Instalação, Configuração e Deploy no WebLogic 12c

Sobre como fazer download e como instalar o WebLogic, já escrevi em 2012, How to Install WebLogic 12c ZIP on Linux (em inglês). Se tiver alguma dúvida, comente no post!

Quanto à configuração, a única coisa que precisamos fazer é criar um Data Source apontando para um banco de dados. Desde a versão 10.3.3 o WebLogic já vem com o Derby como parte da instalação, permitindo assim configurar um Data Source para um banco de dados em memória. No WebLogic 12c, o Derby já está ativo e para criar um Data Source é bem fácil.

Primeiro, acesse o diretório onde o domínio foi criado, e depois inicialize o servidor:

$ ./startWebLogic.sh

Agora acesse a URL do console administrativo Web no endereço http://localhost:7001/console. Informe o usuário/senha que você definiu durante a instalação (geralmente, é weblogic/welcome1). O passo-a-passo da configuração é bem simples:

1. No menu esquerdo, clique em Services, Data Sources
2. Clique no botão New
3. Selecione a opção Generic Data Source
4. Informe o valor jdbc/demoiselle nos dois campos texto (Name e também JNDI Name)
5. Selecione o tipo de banco de dados Derby na combobox
6. Clique em Next
7. Na tela seguinte não há o que fazer. Clique em Next
8. Na tela seguinte também não há o que fazer. Clique em Next
9. Na tela onde diz "Connection Properties", informe o valor demoiselle no campo Database Name
10. Nesta tela, informe localhost como o Host Name
11. Nesta tela, informe demoiselle nos campos Username, Password, Confirm Password
12. Clique em Next
13. Na tela seguinte verifique os dados, e experimente a configuração clicando no botão Test Configuration
14. Clique em Next
15. Selecione o AdminServer e finalmente, clique em Finish

Agora você deve ter um Data Source chamado jdbc/demoiselle, de acordo com a configuração feita anteriormente no persistence.xml do projeto.

WLST - WebLogic Scripting Tool

O WebLogic vem com uma feature muito legal chamada WLST, que permite você escrever scripts em Python para automatizar tarefas administrativas no servidor de aplicação. Se você achou o passo-a-passo acima complicado, experimente rodar este script especificamente para criar o Data Source jdbc/demoiselle usando o Derby. O procedimento é simples:

1. Faça download do arquivo no Gist
2. Acesse a pasta do domínio WebLogic
3. Digite o seguinte comando para incorporar as variáveis de ambiente do domínio WebLogic na shell:
   
   $ source bin/setDomainEnv.sh
4. Digite o seguinte comando para invocar o script:
   
   $ java weblogic.WLST <caminho para o arquivo>/create-demoiselle-ds.py

Deployment da aplicação Demoiselle

Aproveitando o ambiente do domínio na sua shell (após executar "source bin/setDomainEnv.sh"), é muito simples fazer o deploy da aplicação. Execute o seguinte comando:

$ java weblogic.Deployer \  -username weblogic \  -password welcome1 \  -deploy <caminho para o projeto>/demoiselle-sample-2.4.0/target/demoiselle-sample-2.4.0-1.0.0-SNAPSHOT.war

Lembre-se de ajustar o usuário e senha do seu domínio WebLogic tanto no comando acima, quanto no script WLST. Por conveniência, deixei já o comumente utilizado u:weblogic p:welcome1.

Caso queira usar a interface Web, o processo é simples. Clique no menu Deployments, depois no botão Install e basta seguir as instruções da tela.

Testando a aplicação Demoiselle

Agora que a aplicação está rodando, você pode testar acessando a URL da aplicação, que provavelmente é esta: http://localhost:7001/demoiselle-sample-2.4.0-1.0.0-SNAPSHOT/index.jsf

Qualquer dúvida, é só comentar! Ou me procurar no Twitter @brunoborges. :-)

Abs!

Você Está Pronto Para O Próximo Update do Java?

Oracle criou dois novos recursos, o 
Java RIA Security Checklist e o Java Security Resource Center para ajudar você a se preparar para a próxima atualização do Java SE, Java SE 7 update 51 (agendado para Janeiro de 2014). Esta versão modifica os requisitos de deployment para aplicações em Applet & Web Start com dois novos requisitos: 

1. Uso do atributo Manifest, chamado Permissions
2. Assinaturas de código válidas

Estas mudanças não afetarão desenvolvedores de aplicações back-end, ou cliente standalone; o escopo é limitado somente para Java Applets & Java Web Start (RIAs). Leia alguns destes detalhes no meu post anterior Mudanças no Java SE 7u51 para Applets e Web Start.

Java RIA Security Checklist


A mudança agendada para o Java SE 7u51 irá fazer com que o controle de segurança "default" (security slider) requererá o atributo Permissions no Manifest, e que o código esteja assinado devidamente com um certificado de código válido. O Java RIA Security Checklist
 provê as melhores práticas para ajudar os times de desenvolvimento a identificarem as tarefas necessárias para atender a estes novos requisitos.

Security Resource Center


A Oracle lançou o novo Java Security Resource Center para agrupar informações relacionadas a segurança para a comunidade Java, de acordo com o perfil de cada profissional: desenvolvedor, administrador de sistemas, usuário doméstico, ou especialista em segurança.

Recursos Adicionais

• Java Platform Group Product Management blog – Oferece informação, boas práticas, e exemplos relacionados a Java SE, segurança, e usabilidade.
• Java SE 7 Security Documentation

• Java Tutorial for Signing Code
• Jar File Manifest Attributes for Security

Nota:
 Para garantir que sistemas de usuários finais (end users) estejam protegidos quando usando conteúdo baseado em Java, a Oracle recomenda que você esteja sempre atualizado para a mais recente versão. Você pode remover versões antigas do Java seja durante o processo de atualização, ou com usando a ferramenta Java Uninstall Tool em Java.com.

O futuro do WebLogic 12c

Antes de falar do WebLogic 12c, uma informação importante é que prorrogamos o suporte do WebLogic 11g (versão 10.3.6) até 2018, e o suporte estendido até 2021. Isto dará maior tranquilidade aos clientes a planejarem suas migrações, reduzindo assim riscos e custos, principalmente aos clientes de Fusion Apps e SOA Suite/BPM. 

A versão atual do WebLogic 12c é a 12.1.2, lançada este ano em Junho, juntamente com todo o Cloud Application Foundation 12c (Coherence, Oracle HTTP Server, Tuxedo, etc). A versão anterior 12.1.1 já era certificada em Java EE 6, e agora esta nova versão traz uma série de recursos e funcionalidades para integrar suas aplicações com o banco de dados Oracle 12c, facilitar o operacional através de Dynamic Clustering e Elastic JMS, mais otimizações para Exalogic e JMS, administração do Oracle Coherence pelo console administrativo do WebLogic, plugins para desenvolvimento de projetos com Apache Maven, geração automática de serviços REST para seus projetos JPA com o TopLink RESTful Data Services, e muito mais.

O WebLogic 12.1.2 também substituiu o antigo instalador da BEA e os utilitários de patch BSU com o Oracle Universal Installer e o utilitário opatch para a aplicação de patches. Muitos clientes Oracle já conhecem estas ferramentas, que já eram utilizadas para outros produtos, como o próprio Banco de Dados.

Ou seja, uma série de novidades que justificam a liderança do WebLogic no mercado de Application Servers. Mas ao olhar os próximos passos e o roadmap para as versões do WebLogic 12.1.3 e 12.1.4, há motivo de sobra para se interessar na versão 12c.

A versão WebLogic 12.1.3 deverá ser a primeira homologada para diversos produtos 12c do FMW como SOA Suite 12c. Além disso, alguns novos recursos serão incluídos para melhorar ainda mais a experiência do administrador de infraestrutura para escalar ambientes com mais servidores. Por exemplo, a feature de Elastic JMS permitirá o uso do Server Migration sem perder mensagens durante esta execução. Estamos trabalhando para oferecer na versão 12.1.4 o suporte para auto-scaling de clusters dinâmicos, com base em limites e métricas definidas pelo usuário. O WebLogic 12.1.4 também deverá ter uma API para controlar os clusters dinâmicos. Desta forma, os usuários poderão facilmente programar a hora de parar, iniciar ou remover nós de um cluster dinâmico.

O WebLogic 12c conta com o driver JDBC 12c, oferecendo melhor integração com o Oracle DB 12c, e uma destas features é chamada de "Application Continuity". Esta feature permite que após uma falha de comunicação com um nó de um Oracle RAC, a transação com o banco de dados seja transferida sem qualquer efeito colateral para outro nó do cluster, garantindo disponibilidade. Na versão WebLogic 12.1.4, será introduzido também um novo recurso chamado de Multitenant Applications. Desta forma usuários poderão definir um modelo WebLogic para uma aplicação, para um ou mais clientes desta aplicação, que terá o seu próprio cluster, etc.

O conteúdo acima foi originalmente postado aqui.

AVISO LEGAL: O texto acima visa delinear nossa direção geral dos produtos. Destina-se apenas para fins informativos, e não pode ser incorporado em qualquer contrato. Não é um compromisso e não deve ser usado na tomada de decisões de compra. O desenvolvimento, lançamento e tempo dos recursos ou funcionalidades descritos para os produtos da Oracle permanecem a critério exclusivo da Oracle.

Reality of Open Source Users in Mobile and Cloud Era

- "I built my Android app entirely with Open Source products, both in the app, and in the backend server running on Amazon. I'm charging US$ 1,99 for it in the Google Play Store" 

- "That's wonderful! Where is the source code of your app? Have you contributed back to these Open Source products? Will you release your product as Open Source?"

In this new era of Cloud Computing and Mobile apps, there's an increasing number of for-profit products that takes advantage of Open Source products, but barely contribute anything back to them, either by buying support, or non-expensive things such as reporting bugs, fixes, or helping documentation. Developers are building SaaS applications for Salesforce.com, or Mobile apps for Android and iOS devices, and usually charge for these. Of course, they want to make money as anyone else.

Whenever I ask someone that makes money with _their_ software built on top of Open Source, if they will ever release the source code, they usually answer: "my case is different". Well, why is your case different? Why can't I buy your app from Google Play Store, and still access the code on GitHub? Or build it on my own, customize it, etc? That's the point of Open Source, right? Wrong, in their minds.

Majority of software developers actually tend to think that Open Source is free as in free beer. And that's it. No matter how hard you try to explain otherwise, the industry will almost always see Open Source software as free software. And due to the new way to sell software, I really think that Mobile apps and Cloud SaaS/PaaS offers will, sooner or later, kill good Open Source softwares, and leave this space only for conceptual and initial implementations for Open Standards and APIs, or for general use and development platforms and languages such as Java, Ruby, etc.

Perhaps you want to read Will Cloud kill Open Source? Is the Future Open Standards? Your thoughts are welcome :-)

6 Facts About GlassFish Announcement

Since Oracle announced the end of commercial support for future Oracle GlassFish Server versions, the Java EE world has started wondering what will happen to GlassFish Server Open Source Edition. Unfortunately, there's a lot of misleading information going around. So let me clarify some things with facts, not FUD.

Fact #1 - GlassFish Open Source Edition is not dead

GlassFish Server Open Source Edition will remain the reference implementation of Java EE. The current trunk is where an implementation for Java EE 8 will flourish, and this will become the future GlassFish 5.0. Calling "GlassFish is dead" does no good to the Java EE ecosystem. The GlassFish Community will remain strong towards the future of Java EE. Without revenue-focused mind, this might actually help the GlassFish community to shape the next version, and set free from any ties with commercial decisions.

Fact #2 - OGS support is not over

As I said before, GlassFish Server Open Source Edition will continue. Main change is that there will be no more future commercial releases of Oracle GlassFish Server. New and existing OGS 2.1.x and 3.1.x commercial customers will continue to be supported according to the Oracle Lifetime Support Policy. In parallel, I believe there's no other company in the Java EE business that offers commercial support to more than one build of a Java EE application server. This new direction can actually help customers and partners, simplifying decision through commercial negotiations.

Fact #3 - WebLogic is not always more expensive than OGS

Oracle GlassFish Server ("OGS") is a build of GlassFish Server Open Source Edition bundled with a set of commercial features called GlassFish Server Control and license bundles such as Java SE Support. OGS has at the moment of this writing the pricelist of U$ 5,000 / processor. One information that some bloggers are mentioning is that WebLogic is more expensive than this. Fact 3.1: it is not necessarily the case. The initial edition of WebLogic is called "Standard Edition" and falls into a policy where some “Standard Edition” products are licensed on a per socket basis. As of current pricelist, US$ 10,000 / socket. If you do the math, you will realize that WebLogic SE can actually be significantly more cost effective than OGS, and a customer can save money if running on a CPU with 4 cores or more for example. Quote from the price list:

“When licensing Oracle programs with Standard Edition One or Standard Edition in the product name (with the exception of Java SE Support, Java SE Advanced, and Java SE Suite), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.”

For more details speak to your Oracle sales representative - this is clearly at list price and every customer typically has a relationship with Oracle (like they do with other vendors) and different contractual details may apply.

And although OGS has always been production-ready for Java EE applications, it is no secret that WebLogic has always been more enterprise, mission critical application server than OGS since BEA. Different editions of WLS provide features and upgrade irons like the WebLogic Diagnostic Framework, Work Managers, Side by Side Deployment, ADF and TopLink bundled license, Web Tier (Oracle HTTP Server) bundled licensed, Fusion Middleware stack support, Oracle DB integration features, Oracle RAC features (such as GridLink), Coherence Management capabilities, Advanced HA (Whole Service Migration and Server Migration), Java Mission Control, Flight Recorder, Oracle JDK support, etc.

Fact #4 - There’s no major vendor supporting community builds of Java EE app servers

There are no major vendors providing support for community builds of any Open Source application server. For example, IBM used to provide community support for builds of Apache Geronimo, not anymore. Red Hat does not commercially support builds of WildFly and if I remember correctly, never supported community builds of former JBoss AS. Oracle has never commercially supported GlassFish Server Open Source Edition builds. Tomitribe appears to be the exception to the rule, offering commercial support for Apache TomEE.

Fact #5 - WebLogic and GlassFish share several Java EE implementations

It has been no secret that although GlassFish and WebLogic share some JSR implementations (as stated in the The Aquarium announcement: JPA, JSF, WebSockets, CDI, Bean Validation, JAX-WS, JAXB, and WS-AT) and WebLogic understands GlassFish deployment descriptors, they are not from the same codebase.

Fact #6 - WebLogic is not for GlassFish what JBoss EAP is for WildFly

WebLogic is closed-source offering. It is commercialized through a license-based plus support fee model. OGS although from an Open Source code, has had the same commercial model as WebLogic. Still, one cannot compare GlassFish/WebLogic to WildFly/JBoss EAP. It is simply not the same case, since Oracle has had two different products from different codebases. The comparison should be limited to GlassFish Open Source / Oracle GlassFish Server versus WildFly / JBoss EAP.

But the message now is much clear: Oracle will commercially support only the proprietary product WebLogic, and invest on GlassFish Server Open Source Edition as the reference implementation for the Java EE platform and future Java EE 8, as a developer-friendly community distribution, and encourages community participation through Adopt a JSR and contributions to GlassFish.

In comparison

Oracle's decision has pretty much the same goal as to when IBM killed support for Websphere Community Edition; and to when Red Hat decided to change the name of JBoss Community Edition to WildFly, simplifying and clarifying marketing message and leaving the commercial field wide open to JBoss EAP only. Oracle can now, as any other vendor has already been doing, focus on only one commercial offer.

Some users are saying they will now move to WildFly, but it is important to note that Red Hat does not offer commercial support for WildFly builds. Although the future JBoss EAP versions will come from the same codebase as WildFly, the builds will definitely not be the same, nor sharing 100% of their functionalities and bug fixes. This means there will be no company running a WildFly build in production with support from Red Hat.

This discussion has also raised an important and interesting information: Oracle offers a free for developers OTN License for WebLogic. For other environments this is different, but please note this is the same policy Red Hat applies to JBoss EAP, as stated in their download page and terms. Oracle had the same policy for OGS.

TL;DR;

GlassFish Server Open Source Edition isn’t dead. Current and new OGS 2.x/3.x customers will continue to have support (respecting LSP). WebLogic is not necessarily more expensive than OGS. Oracle will focus on one commercially supported Java EE application server, like other vendors also limit themselves to support one build/product only. Community builds are hardly supported. Commercially supported builds of Open Source products are not exactly from the same codebase as community builds.

What's next for GlassFish and the Java EE community?

There are conversations in place to tackle some of the community desires, most of them stated by Markus Eisele in his blog post. We will keep you posted.