Sunday, January 1, 2012

JSF 2.0 Managed Bean Annotations and CDI on WebLogic 12c

WebLogic 12c now supports Java 6 so we can now try out the JSF 2.0 Managed Bean annotations together with CDI JSR-299. In this blogpost I will use OEPE 12c as my IDE and deploy everything on WebLogic 12c. Off course I will tell you my experiences to get all this working in Eclipse and WebLogic 12c.

First let's start with the JSF 2.0 Managed Bean Annotations.

We need to remove the managed bean definitions from the faces-config.xml file. Then make sure that you don't use the metadata-complete attribute ( metadata-complete="true" ) on the faces-config element, this will disable the search for JSF Managed Beans.


Then we can add the JSF Managed Bean annotations to the java class. We can use @ManagedBean ( javax.faces.bean ) together with the right scope annotation like RequestScoped, SessionScoped or ViewScoped ( CDI does not have this View Scope ). You will see this bean in the Faces Configuration View.



Next part of this blog is about CDI, this will be more tricky, it is possible but does not work so well in OEPE and WebLogic. I didn't have these problems with the same OEPE, Code and using Glassfish 3.11.

So to enable CDI we need to add a beans.xml file to the WEB-INF folder. Like this with a empty beans element, this will trigger CDI.

When we try to run the JSF application again then you probably will hit this NPE in the jboss Weld framework.


<javax.enterprise.resource.webcontainer.jsf.renderkit> <BEA-000000> <javax.faces.FacesException
javax.faces.FacesException
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:142)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at org.apache.myfaces.extensions.validator.core.startup.ExtValLifecycleWrapper.render(ExtValLifecycleWrapper.java:79)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at org.jboss.weld.el.ELCreationalContextStack.getCreationalContextStore(ELCreationalContextStack.java:33)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:47)




The solution is to remove the JSP entries and rename your files from jspx to xhtml.
From this.

<?xml version="1.0" encoding="iso-8859-1"?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
          xmlns:f="http://java.sun.com/jsf/core" 
          xmlns:h="http://java.sun.com/jsf/html"
          xmlns:trh="http://myfaces.apache.org/trinidad/html"
          xmlns:tr="http://myfaces.apache.org/trinidad">
  <jsp:directive.page contentType="text/html;charset=utf-8"/>
  <f:view>
    <tr:document title="Bean and ExtVal validation">
      <tr:form>

To this, where we define the used jsf namespaces on the html element. 


Next we can try to create a new managed bean where we will use the Named annotation together with the SessionScoped annotation of javax.enterprise.context


We can also inject an EJB or a Managed Bean with the Inject annotation.


I can also replace @EJB with @Inject but then I should move my EJBs to my Dynamic Web Project else I will get an Weld error.  Probably with OEPE you have an different JPA project and this ejb.jar will be deployed together with the WAR in an EAR. 
I didn't test this but you need to enable CDI on this ejb project or EAR.

That's not all you also need to change the WebLogic Publishing mode of OEPE. This should be Publish as an exploded archive else Inject won't work. ( Thanks to Steve Button for the tip. ).
 

This is the error I got WELD-001408 Unsatisfied dependencies for type [DataBeanCDI] with qualifiers [@Default] at injection point [[field] @Inject private nl.amis.web.beans.DataBean.dataBeanCDI]

And now the most annoying bug, the CDI managed beans will work only once on WebLogic 12c. When you deploy or run your application the second time then the CDI Managed bean can't be found. The solution is you need to restart the WebLogic Server. This makes development with CDI almost impossible.

In Glassfish 3.11 I didn't have all these problems so I hope Oracle will update OEPE & WebLogic 12c very soon.

Here you can find my example code.

 

Tuesday, December 27, 2011

Using Bean Validation together with ExtVal in JPA and JSF

With the release of WebLogic 12c we can finally try out the native support for Bean Validation ( JSR-303) in JPA & JSF. With JSR-303 we can use this validation framework on the back-end side ( EJB Session Bean ) and on the managed bean of the JSF Web applications, so one framework which can do it all. It will save us a lot of time in making business rules and no need for validators on our JSF UI Components.
To make this even better I will combine this with Apache MyFaces Extensions Validator. This framework can be used with JSF ( there is a generic library and a special one for Trinidad ) and its supports the Bean Validation. ExtVal also has some extra features.



  • Type-safe group validation
  • Model validation
  • Severity aware validation
  • Client-side validation
  • Sorted violation messages
  • Dependency injection support for constraint validators
  • Mapped constraint source (e.g. for using DTO's with BV)
  • Support of @Valid


In this blog I won't give you all the possible validations options you can have in the Bean Validation or in ExtVal framework but I will try to give you a jumpstart, how to setup this up and get everything working.

Before I start I got this working with WebLogic 12c and use OEPE 12c as my IDE. For the JSF part I use Apache MyFaces Trinidad 2.0.0 which support JSF 2.0.

Let's start with the JPA part.

Here I have created a department entity which is based on the department table of the HR demo schema in the Oracle database.

On the departmentName attribute I added some validation annotations like NotNull , Size and Pattern.


On the Pattern annotation I added a custom resource bundle message ( use {} ), I only do it for pattern annotation because Size or NotNull will have it's own default message in JSF.

Bean validation is the default now so we would see the Eclipselink error anymore. So when we try to persist an entity which violates these annotations we get an error like this.

With a javax.validation.ConstraintViolationException on a prePersist callback event. This error won't give you a lot of information about the error.

You got the option to disable the Bean Validation in Eclipselink by setting the validation-mode to NONE. This way you will get the constraint error.


Like this.

So how we can retrieve these validations errors. For example I can do this on the client side before I invoke the EJB Session bean or do it inside the Session Facade methods.

We need to use the resource annotation to retrieve the Validator.
(@Resource Validator validator; )
In the department persist we can pass on the department entity to the validatior.
Set<ConstraintViolation<Department>> violations = validator.validate(department);
And loop through the violations with this as result.

error size: 2
invalid value for: 'departmentName': Name must between 2 and 30 characters
invalid value for: 'departmentName': {departmentNameValidation}



Now we can go the JSF part.
Here I do the same but then from a managed bean which is called from a commandButton.



I changed the violations to Faces Messages and skip the persist part.


This is all standard Bean Validation stuff so let's check out the ExtVal part.

I added the following libraries to the lib folder of the WEB-INF

The jsr303-tck and the validation-api jars are from Hibernate Validator and the rest is from MyFaces ExtVal. Where I remove the myfaces-extval-generic-support-2.0.5.jar because I could use the trinidad one.

To test the validation I made a simple JSF Trinidad page where you can see there are no validator or convertors defined.



In the Trinidad table I show all the departments and change for example the department Name to 1 char which violates the Size annotation.

When I use invalid characters for the department Name then I get the resource bundle message.

To make this resourcebundle work I need to set a context parameter in the web.xml which points to our own resourcebundle.

<context-param>
    <param-name>org.apache.myfaces.extensions.validator.CUSTOM_MESSAGE_BUNDLE</param-name>
    <param-value>resources.application</param-value>
</context-param>

The last part is to show you the ExtVal part. I used this managed bean which are used in the JSF page.


departmentName use the Bean Validation framework and departmentLocation use the ExtVal framework.
With this as result.


When you want to know more about ExtVal or Bean Validation you definitely should read this example chapter of Bart Kummel's Book about MyFaces Development.

Here is the example project on github. https://github.com/biemond/OEPE_examples/tree/master/beanValidation


Sunday, December 18, 2011

WebLogic SCA with WebLogic 12c and OEPE 12.1

Fusion Middleware Software like OSB or SOA Suite is not yet available on WebLogic 12c but this does not mean you can't develop SCA Applications. With the help of the Oracle Enterprise for Eclipse 12.1.1 ( OEPE ) we can build WebLogic SCA application and deploy it on WebLogic 12c. This allows you to write Java applications using POJOs and, through different protocols, expose components as SCA services and access other components via references. You do this using SCA semantics configured in a Spring application context. In SCA terms, a WebLogic Spring SCA application is a collection of POJOs plus a Spring SCA context file that wires the classes together with SCA services and references.

In this blogpost I will show you all the steps so you can try it yourself.

Before we start, we need to install WebLogic 12c, configure a new domain and startup the AdminServer.
The first step is to install the WebLogic SCA shared library and target it to the AdminServer.

Log in to the WebLogic Console and go to deployments windows.
Install this war  located at wlserver_12. 1\common\deployable-libraries\weblogic-sca-1.1.war as a shared library and target it to the AdminServer.

Next step is to download OEPE 12.1.1, extract it and create a new workspace.

In this workspace we need to create a new Dynamic Web Project.
Use wls 12 as Target runtime and also create an Ear project which will include the war.


Open the project options of your Dynamic Web Project and go to Project Facets.
Here we need to enable Oracle WebLogic SCA and Spring.
Click on Further configuration required.


Next step is to download the Spring library. Click on the download button and select Spring Framework 2.5.6 of Oracle.


Click on Next.

We need to add the WebLogic SCA Shared Library, this will be added to the weblogic.xml deployment descriptor of your Web Project.


You can open the weblogic.xml file of your Web project and in the Shared Libraries you should see the reference.

When you are in the Web Perspective then you can open the spring-context.xml in the beans section of the Spring Elements.


Or in the java perspective this is located in the jsca folder of the META-INF folder.


In the Spring-context.xml we will add some spring beans which have an EJB & Web Service SCA service and we also add some SCA references.

In this demo I will start with a SCA service with has a ws binding , this service has a target to a spring bean. This spring has a property to a SCA reference which an EJB binding.
The SCA reference calls a SCA Service which off course also has an EJB binding. The service target the next spring bean which the calls the last spring bean.

We start with the last spring bean and end with the first SCA service.
This the LoggerOutput class which just do a system out.
Because we want to expose the next spring bean as a SCA service we need to have an interface which we can use in the SCA service.
And now the implementation which calls the last spring bean LoggerOutput
Now we have everything to make our first SCA application. This is how the spring-context will look like.
This SCA service will be invoked in the second part of this blogpost where we will call this EJB from a web service. We can use the same ILoggerComponent interface for the SCA Service ( this time a web service ) and the SCA reference will call the already created EJB SCA service. We only need a new spring bean which pass on the message to the EJB. For this I use this LoggerPassThrough class.
Here is the total spring-context.xml
We are ready to deploy it and do a test run. Select your EAR project, right click and do run on Server.
Provide the details of your WebLogic 12c domain.


You can use soapUI to invoke the SCA Web Service http://localhost:7001/WebLogicSCA/LoggerService_Uri?WSDL
or invoke the SCA EJB Service
ILoggerComponent logEJB = (ILoggerComponent)context.lookup("LoggerService_EJB30_JNDI");

WebLogic also has an extension for WebLogic SCA , in the Console , go to the Preferences , Extensions and enable weblogic-sca-console.  You need to restart your WebLogic Server.

After this you can click on your SCA deployment and see your SCA Services and references.

Download the code at github
https://github.com/biemond/OEPE_examples/tree/master/wls12cSCA