Wednesday, March 24, 2010

Using the Quartz Enterprise Scheduler in J2EE

http://www.theserverside.com/news/1377023/Using-the-Quartz-Enterprise-Scheduler-in-J2EE

Before we dive down the details let's assume that you have a business use case that requires a Job to run every 30 minutes. In this article we will discuss how can you achieve this using the Cron Triggers functionality of Quartz.

Define Your Job as an EJB Method

The first step in scheduling a job in J2EE application is to create the EJB and implement the business logic as an EJB Method. For example, I have created a stateless EJB named TestEJB and I've a method named yourMethod that I want to schedule as a job. For clarity, following is the code snippet of my EJB bean implementation class and EJB deployment descriptor:

package howto.quartz.ejb;
import java.rmi.*;
import javax.ejb.*;
public class TestEJBBean implements SessionBean {
  public TestEJBBean() {
  }
  // EJB life cycle methods are omitted for brevity
  ........
  public void yourMethod() throws RemoteException {
    System.out.println("TestEJB Job");
  }
}


Use Quartz API to Schedule Your Job from a Generic Servlet

Quartz uses its own thread pool and these threads are not container threads. Servlet API allows user threads and hence you have to create a Servlet and use Quartz API to schedule your Job. Quartz provides the QuartzInitializerServlet to be used as the entry point for the Quartz job scheduling service. We want to submit the yourMethod of TestEJB as the job in this example. So we will have to create a GenericServlet named howto.quartz.servlet.QuartzServlet and implement the init() method that submits EJB method as a Cron Trigger. In this example, I'm setting the cron expression as an initialization parameter instead of hard coding in the Servlet. The following is the code for the Servlet:

public class QuartzServlet extends GenericServlet {
  public void init(ServletConfig config) throws ServletException {
    super.init(config);
    System.out.println("Scheduling Job ..");
    JobDetail jd = new JobDetail("Test Quartz","My Test Job",EJBInvokerJob.class);
    jd.getJobDataMap().put("ejb", "java:comp/env/ejb/TestEJB");
    jd.getJobDataMap().put("method", "yourMethod");
    Object[] jdArgs = new Object[0];
    jd.getJobDataMap().put("args", jdArgs);
    CronTrigger cronTrigger = new CronTrigger("Test Quartz", "Test Quartz");

    try {
      String cronExpr = null;
      // Get the cron Expression as an Init parameter
      cronExpr = getInitParameter("cronExpr");
      System.out.println(cronExpr);
      cronTrigger.setCronExpression(cronExpr);
      Scheduler sched = StdSchedulerFactory.getDefaultScheduler();
      sched.scheduleJob(jd, cronTrigger);
      System.out.println("Job scheduled now ..");
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
  public void service(ServletRequest arg0, ServletResponse arg1)
throws ServletException, IOException {
  }
  public String getServletInfo() {
    return null;
  }
}


Auto starting the Servlets

We want the job to be submitted as soon the application is deployed or the container is started. We have to initialize the QuartzInitializerServlet and howto.quartz.servlet.QuartzServlet that we implemented whenever the web module is restarted. In order to achieve that we need to create the following entry in the deployment descriptor for the web module (web.xml):

<servlet>
 <servlet-name>QuartzInitializer</servlet-name>
 <display-name>Quartz Initializer Servlet</display-name>
 <servlet-class>org.quartz.ee.servlet.QuartzInitializerServlet</servlet-class>
 <load-on-startup>1</load-on-startup>
</servlet>
<servlet>
 <servlet-name>QuartzServlet</servlet-name>
 <display-name>Quartz Servlet</display-name>
 <servlet-class>howto.quartz.servlet.QuartzServlet</servlet-class>
 <init-param>
  <param-name>cronExpr</param-name>
  <param-value>0 0/30 * * * ?</param-value>
 </init-param>
 <load-on-startup>2</load-on-startup>
</servlet>

The Servlet accesses the TestEJB so we need to create the ejb-ref entry in the web.xml as follows:

<ejb-ref>
 <ejb-ref-name>ejb/TestEJB</ejb-ref-name>
 <ejb-ref-type>Session</ejb-ref-type>
 <home>howto.quartz.ejb.TestEJBHome</home>
 <remote>howto.quartz.ejb.TestEJB</remote>
</ejb-ref>


Assembling/Packaging the Application

The web module accesses the Quartz API so we need to package the Quartz libraries in the WAR module. We need to put these libraries e.g. quartz.jar, commons-logging.jar, commons-pool-1.1.jar, etc. in the WEB-INF/lib of the WAR module. The quartz settings that you need for your environment must be specified in the quartz.properties and this file must be put in the WEB-INF/classes directory of the WAR module.

The ejb-jar that contains the TestEJB and the WAR containing the Quartz libraries and QuartzServlet needs to be packaged as an EAR and deployed to the J2EE container.

Note:
For OC4J, you need to configure it to allow User Threads.
Configure your J2EE container to allow user threads to be created by your application as Quartz scheduler creates threads those are treated as user threads. For example, you need to start OC4J as follows to allow user threads:

java -jar oc4j.jar -userThreads


Deploy Your J2EE Application

Then deploy your application in your J2EE container. Make sure that your application is set automatically started when your application server is started. For example, if you are using OC4J make sure that you set the auto-start for your application and load-on-startup for the web module to true. To be sure make sure that you have the following entries in the server configuration files:

server.xml:

<application name="quartz" path="../applications/quartz-app.ear" auto-start="true" />

http-web-site.xml:

<web-app application="quartz" name="quartz-web" load-on-startup="true" root="/quartz" />

Now you are ready to go!

Your EJB method now is scheduled as a recurring Job that occurs in every 30 minutes.

Sunday, March 21, 2010

Workaround for WebLogic Workshop update error.

If you had installed WebLogic Portal 10.3 and are trying to install a couple of plug ins to Workshop/Eclipse, but whenever you select any item to install, you will get this error:

WebLogic Portal (10.3.0) requires feature "com.m7.nitrox (1.0.20)", or compatible.

This is a bug, CR379999. that will be fixed WLP 10.4. In the meantime, here's the workaround from the bug report:

Download the plugin manually, and either 1) create an extension location on the file system from it and add that via Help|Software Updates|Manage Configuration, or 2) extract it to one of the workshop eclipse folders (i.e. tools/eclipse_pkgs/2.0/eclipse_3.3.2, tools/eclipse_pkgs/2.0/pkgs/eclipse, workshop_10.3/workshop4WP/eclipse, wlportal_10.3/eclipse).

Additionally, you can comment out the com.* import lines in your %BEA_HOME%\wlportal_10.3\eclipse\features\com.bea.wlp_10.3.0\feature.xml, like this:





Thursday, March 18, 2010

How to get the invocation hierarchy in Java?

In Java, we can see the invocation hierarchy sometimes in Java. Especially, the log4j can log the class into log file with package name, method and line even. How can we implement the similar functionality?

First, how can we get the invocation class and method? Stack trace.

StackTraceElment[] ste = new Throwable().getStackSTrace();

In the array of StackTraceElement, we can find the hierarchy of current stack. By this, we can get the invocation map of whole stack.

StackTraceElment APIs:
String getClassName()
Returns the fully qualified name of the class containing the execution point represented by this stack trace element.
String getFileName()
Returns the name of the source file containing the execution point represented by this stack trace element.
int getLineNumber()
Returns the line number of the source line containing the execution point represented by this stack trace element.
String getMethodName()
Returns the name of the method containing the execution point represented by this stack trace element.

In Java 5, The Thread introduced two new methods: getStackTrace() and getAllStackTraces(). Now we don't need to use (new Throwable()).getStackTrace() and by using Thread.getCurrentThread().getStackTrace() to get the stack trace info. Not only doing so, but also we can get stack trace of other threads if we have the enough permission.

Stub caching and concurrent reuse problems in Axis

Reference Stub caching and concurrent reuse problems

Somebody tried to cache the generated stubs for reusing by concurrent clients
because instantiating of them takes too long. But every time he started 4+ concurrent clients for the same web-service, he would receive some weird exceptions from the core of Axis. This happened only in case of caching the stubs and not issue for creating new stub for every client but the performance.

Some people replied the question and mentioned the cache of stub was not hoped and the internals of the stubs may screw up if cached! If you are using the usual no
args constructor of the stub, the stub may need to create its own configuration context and that may take significant time. You can cache the config context and create the stub passing in your config context, instead of caching stub.

In the mail list, also somebody mentioned they had found two important factors to keep in mind when reusing stubs:

  1. The stubs are not thread safe, so you cannot use the same stub in
    two concurrent threads

  2. Recently discovered that even the stub constructor is not thread safe! So two concurrent threads cannot call the constructor at the same time.



If you have a typical architecture that reuses client processing threads, then each needs their own stub but once it creates a stub it can continue to use that indefinitely.

Another useful thing to do is:

options.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, new Boolean(true));

Thursday, March 11, 2010

Spring Batch vs Quartz

A. What is Spring Batch?
It is a generalized (lightweight) Enterprise Batch processor. So it is a system that is designed to autonomously preform a set of operations data. For example, say that at the end of the month you are required to generate a survey on all claims processed by an insurance agency. The process to do this requires going though each claim (across multiple departments) and pulling various pieces of metadata -- combine the data into a summary. -- This is the kind of thing you design a batch program for -- especially if the requirements may change over time (like as laws change) so you need flexibility.

B. Why go for Spring Batch?
Well it is lightweight and pretty easy to work with however this is really an architecture question and without knowing much about the existing system you are working with I don't know if I can answer that.

C.How can we use Quartz for scheduling Spring Batch?
Quartz is an excellent concurrent scheduler. It is really not difficult to setup and configure. However -- before using Quartz you may wish to see if these features are already included in your infrastructure. For example many application servers provide scheduling.

Saturday, February 27, 2010

Yahoo! YSlow

Yahoo! YSlow
YSlow analyzes web pages and suggests ways to improve their performance based on a set of rules for high performance web pages. YSlow is a Firefox add-on integrated with the Firebug web development tool. YSlow grades web page based on one of three predefined ruleset or a user-defined ruleset. It offers suggestions for improving the page's performance, summarizes the page's components, displays statistics about the page, and provides tools for performance analysis, including Smush.it™ and JSLint.

Tuesday, February 02, 2010

JSF 2.0 with Spring 3 and Spring Security 3 on Google Application Engine

JSF 2.0 with Spring 3 and Spring Security 3 on Google Application Engine

In this post I'm going to show a simple fully integrated CRUD style application working on Google Application Engine.

Credit Card Mod10 Validation

The follow code was got from WikiPedia and did a little modification. It is very neat and elegant.

public static boolean isValidCC(String num) {
  final int[][] sumTable = {{0,1,2,3,4,5,6,7,8,9},{0,2,4,6,8,1,3,5,7,9}};
  int sum = 0, flip = 0;
  for (int i = num.length() - 1; i >= 0; i--, flip++){
    int n = num.charAt(i) - '0';
    if (n < 0 || n > 9)
      return false;
    sum += sumTable[flip & 0x1][n];
  }
  return (sum == 0) ? false : (sum % 10 == 0);
}


The follow code used a variable as a switch to double the value.

public static boolean isValidCC(String number) {
  int sum = 0;
  int mul = 1;
  for (int i = number.length() - 1; i >= 0; i--) {
    int n = number.charAt(i) - '0';
    if (n < 0 || n > 9)
      return false;
    n *= (mul == 1) ? mul++ : mul--;
    sum += (n>9 ? n-9 : n);
  }
  return (sum == 0) ? false : (sum % 10 == 0);
}


The follow code used the position to double the value.

public static boolean isValidCC(String number) {
  int sum = 0;
  for (int i = number.length() - 1; i >= 0; i--) {
    int n = number.charAt(i) - '0';
    if (n < 0 || n > 9)
      return false;
    if ((number.length()-i)%2 == 0)
      n *= 2;
    sum += (n>9 ? n-9 : n);
  }
  return (sum == 0) ? false : (sum % 10 == 0);
}


The follow code used any way to double the value.

protected boolean isValidCC(String number) {
  int digits = number.length();
  int oddOrEven = digits & 1;
  long sum = 0;
  for (int i= 0; i < digits; i++) {
    int n = number.charAt(count) -'0';
    if (n < 0 || n > 9)
      return false;
    if (((i& 1) ^ oddOrEven) == 0)
      n *= 2;
    sum += (n>9 ? n-9 : n);
  }
  return (sum == 0) ? false : (sum % 10 == 0);
}


The follow code much easier to understand.

public static boolean isValidCC(String number) {
  int sum = 0;
  boolean alternate = false;
  for (int i = number.length() - 1; i >= 0; i--) {
    int n = Integer.parseInt(number.substring(i, i + 1)); //May throw out a runtime exception
    if (alternate) {
      n *= 2;
    sum += (n>9 ? (n%10)+1 : n);
    alternate = !alternate;
  }
  return (sum == 0) ? false : (sum % 10 == 0);
}

Friday, January 29, 2010

URL rewriting

Both of these methods revolve around the concept of URL rewriting. Basically it involves suffixing the URL with a HTTP_QUERY_STRING, which mostly is a session id used to keep track of a particular users context.

URL re-writing is used get over the usage of cookies which are dependent on browser configuration, thus not reliable at all.

The difference between the methods is in their usage and not their functionality. Both perform the same task of re-writing a URL.

encodeRedirectURL
When you send a redirect header to the browser using response.sendRedirect(string URL)

Example, you want to redirect to different page.

if (name == null){
  response.sendRedirect(response(encodeRedirectURL("errorPage.jsp"))
}


encodeURL
On the other hand, you provide a link to shopping cart page to a user.

printWriter.println("A HREF=" + response.encodeURL("shoppingCart.jasp") + ">")


Essentially they do same thing of re-writing the URl for non-cookie compliant browser.

encodeURL() is used for all URLs in a servlet's output. It helps session ids to be encoded with the URL.

encodeRedirectURL() is used with res.sendRedirect only.It is also used for encoding session ids with URL but only while redirecting.

Monday, January 25, 2010

Xerces

Xerces is a collection of software libraries for parsing, validating, serializing and manipulating XML. The library implements a number of standard APIs for XML parsing, including DOM, SAX and SAX2.

XML Data Binding

XML data binding refers to the process of representing the information in an XML document as an object in computer memory. This allows applications to access the data in the XML from the object rather than using the DOM or SAX to retrieve the data from a direct representation of the XML itself.

Java Architecture for XML Binding (JAXB)
JABX allows Java developers to map Java classes to XML representations. JAXB provides two main features: the ability to marshal Java objects into XML and the inverse, i.e. to unmarshal XML back into Java objects. In other words, JAXB allows storing and retrieving data in memory in any XML format, without the need to implement a specific set of XML loading and saving routines for the program's class structure.

Usage of JAXB
The tool "xjc" can be used to convert XML Schema and other schema file types (as of Java 1.6, RELAX NG, XML DTD, and WSDL are supported experimentally) to class representations. Classes are marked up using annotations from javax.xml.bind.annotation.* namespace, for example, @XmlRootElement and @XmlElement. XML list sequences are represented by attributes of type java.util.List. Marshallers and Unmarshallers are created through an instance of JAXBContext.
In addition, JAXB includes a "schemagen" tool which can essentially perform the inverse of "xjc", creating an XML Schema from a set of annotated classes.

XMLBeans
It is a tool that allows access to the full power of XML in a Java friendly way. The idea is to take advantage of the richness and features of XML and XML Schema and have these features mapped as naturally as possible to the equivalent Java language and typing constructs. XMLBeans uses XML Schema to compile Java interfaces and classes that can then be used to access and modify XML instance data. Using XMLBeans is similar to using any other Java interface/class: with methods like getFoo or setFoo, just as when working with Java. While a major use of XMLBeans is to access XML instance data with strongly typed Java classes there are also APIs that allow access to the full XML infoset (XMLBeans keeps XML Infoset fidelity) as well as to allow reflection into the XML schema itself through an XML Schema Object model.

Usage of XMLBean
To accomplish the above objectives, XMLBeans provides three major APIs:
  • XmlObject
  • XmlCursor
  • SchemaType
    XmlObject: The java classes that are generated from an XML Schema are all derived from XmlObject. These provide strongly typed getters and setters for each of the elements within the defined XML. Complex types are in turn XmlObjects. For example getCustomer might return a CustomerType (which is an XmlObject). Simple types turn into simple getters and setters with the correct java type. For example getName might return a String.
    XmlCursor: From any XmlObject the developer can get an XmlCursor. This provides efficient, low level access to the XML Infoset. A cursor represents a position in the XML instance. The cursor can be moved around the XML instance at any level of granularity needed from individual characters to Tokens.
    SchemaType: XMLBeans provides a full XML Schema object model that can be used to reflect on the underlying schema meta information. For example, the developer might generate a sample XML instance for an XML schema or perhaps find the enumerations for an element so that they may be displayed.
  • XML Parser

    Java API for XML Processing - JAXP
    is one of the Java XML programming APIs. It provides the capability of validating and parsing XML documents. The three basic parsing interfaces are:
  • the Document Object Model parsing interface or DOM interface
  • the Simple API for XML parsing interface or SAX interface
  • the Streaming API for XML or StAX interface (added in JDK 6; separate jar available for JDK 5)

    XML Parsing
    Traditionally, XML APIs are either:
  • tree based - the entire document is read into memory as a tree structure for random access by the calling application
  • event based - the application registers to receive events as entities are encountered within the source document.
    Both have advantages; the former (for example, DOM) allows for random access to the document, the latter (e.g. SAX) requires a small memory footprint and is typically much faster.

    These two access metaphors can be thought of as polar opposites. A tree based API allows unlimited, random, access and manipulation, while an event based API is a 'one shot' pass through the source document.

    Event-based XML Parsing Libs
    SAX is the Simple API for XML, originally a Java-only API. SAX was the first widely adopted API for XML in Java, and is a "de facto" standard.

    A parser which implements SAX (ie, a SAX Parser) functions as a stream parser, with an event-driven API. The user defines a number of callback methods that will be called when events occur during parsing. The SAX events include:
  • XML Text nodes
  • XML Element nodes
  • XML Processing Instructions
  • XML Comments

    Events are fired when each of these XML features are encountered, and again when the end of them is encountered. XML attributes are provided as part of the data passed to element events. SAX parsing is unidirectional; previously parsed data cannot be re-read without starting the parsing operation again.

    DOM-based XML Parsing Libs
    JDOM
    An open source Java-based document object model for XML that was designed specifically for the Java platform so that it can take advantage of its language features. JDOM integrates with Document Object Model (DOM) and Simple API for XML (SAX), supports XPath and XSLT. It uses external parsers to build documents.

    DOM4J
    An open source Java library for working with XML, XPath and XSLT. It is compatible with DOM, SAX and JAXP standards.

    Streaming API for XML (StAX)
    An application programming interface (API) to read and write XML documents, originating from the Java programming language community.

    StAX was designed as a median between these two opposites. In the StAX metaphor, the programmatic entry point is a cursor that represents a point within the document. The application moves the cursor forward - 'pulling' the information from the parser as it needs. This is different from an event based API - such as SAX - which 'pushes' data to the application - requiring the application to maintain state between events as necessary to keep track of location within the document.

    StAX XML Parsing Libs
    Apache Axiom
    A a light weight XML object model based on top of Stax and also provides lazy object building.
  • Friday, January 22, 2010

    Contexts and Dependency Injection for Java EE (CDI) - Part 2


    Custom Object Factories with CDI Producers/Disposers
    In a majority of cases, @Inject and @Qualifier annotations gives the container static control over object creation. However, there are cases where it makes a lot of sense for you to control object creation and destruction yourself in Java code. Good examples are complex object creation/destruction, legacy/third-party API integration, objects that need to be constructed dynamically at runtime and creating injectable strings, collections, numeric values and so on. Along the same lines as the traditional object factory pattern, this is what CDI producers and disposers allow you to do. Another way of looking at this is that the container allows you to step in and take manual control over creating/destroying objects when it makes sense.

    In the following code, we'll show you how to create a simple abstraction over the low-level JMS API using CDI producers and disposers. As you might already know, plain JMS code can be pretty verbose because the API is so general purpose. Using CDI, we can create a custom JMS object factory that hides most of the verbose code to handle the JMS connection and session, keeping the actual JMS API client code pretty clean.
    @Stateless
    public class OrderService {
    @Inject @OrderSession private Session session;
    @Inject @OrderMessageProducer private MessageProducer producer;

    public void sendOrder(Order order) {
    try {
    ObjectMessage message = session.createObjectMessage();
    message.setObject(order);
    producer.send(message);
    } catch (JMSException e) {
    e.printStackTrace();
    }
    }
    }

    Rather than injecting the JMS connection factory and queue, we are instead actually injecting the JMS session and message producer, using qualifiers specific to messaging for orders (@OrderSession, @MessageProducer). The session and message producer is being injected from a shared object factory with a set of CDI producers and disposers handling the JMS session, connection and message producer life-cycle behind the scenes.

    Here is the code for the custom object factory:
    public class OrderJmsResourceFactory {
    @Resource(name="jms/ConnectionFactory")
    private ConnectionFactory connectionFactory;

    @Resource(name="jms/OrderQueue")
    private Queue orderQueue;

    @Produces @OrderConnection
    public Connection createOrderConnection() throws JMSException {
    return connectionFactory.createConnection();
    }

    public void closeOrderConnection (
    @Disposes @OrderConnection Connection connection)
    throws JMSException {
    connection.close();
    }

    @Produces @OrderSession
    public Session createOrderSession (
    @OrderConnection Connection connection) throws JMSException {
    return connection.createSession(true, Session.AUTO_ACKNOWLEDGE);
    }

    public void closeOrderSession(
    @Disposes @OrderSession Session session) throws JMSException {
    session.close();
    }

    @Produces @OrderMessageProducer
    public MessageProducer createOrderMessageProducer(
    @OrderSession Session session) throws JMSException {
    return session.createProducer(orderQueue);
    }

    public void closeOrderMessageProducer(
    @Disposes @OrderMessageProducer MessageProducer producer)
    throws JMSException {
    producer.close();
    }
    }

    The underlying order queue and connection factory is being injected into the JMS object factory via the Java EE 5 @Resource annotation. The methods annotated with @Produces are producer methods. The return values of these methods are made available for injection. When needed, you can apply qualifiers, scopes, names and stereotypes to these return values by applying annotations to the producer methods. In our example, we are applying the @OrderConnection, @OrderSession and @OrderMessageProducer qualifiers to the injectable JMS connections, sessions and message producers we are programmatically constructing. The produced objects belong to the default dependent scope.

    Very interestingly, you should note that producer methods can request injected objects themselves through their method parameters. For example, when the container creates an order session by invoking the createOrderSession method, it sees that the method needs a JMS connection qualified with the @OrderConnection qualifier. It then resolves this dependency by invoking the createOrderConnection producer method. The createOrderMessageProducer producer method is similarly dependent on the createOrderSession producer.

    On the other side of the equation any method with a parameter decorated with the @Disposes annotation signifies a disposer. In the example, we have three disposers disposing of JMS connections, sessions and message producers qualified with the @OrderConnection, @OrderSession and @OrderMessageProducer qualifiers. Just as producer methods are called into action as the objects they produce are needed, the disposer associated with an object is called when the object goes out of scope. For the interest of readability, all disposers must belong in the same bean as their matching producer methods.

    Having covered some of the mechanical syntax details, let's now take a step back and look at the example from a functional standpoint. When the order service needs the injected order session and message producer, the associated producer methods are invoked by CDI. In the course of creating the session and message producer, CDI also creates the JMS connection, since it is a declared dependency for the producer methods. The producer methods utilize the underlying queue and connection factory injected into our JMS object factory as needed. All these injected objects are then cleaned up properly when they go out of scope.

    This example should demonstrate to you how the relatively simple concept of producers and disposers can be combined in innovative and powerful ways when you need it.

    Custom Scopes and Resource Factories
    Think about the implications of the example above. Because the JMS resources are in the dependent scope, they are tied to the life-cycle of the order service EJB. The service is a stateless session bean that is discarded from the object pool when not in use, along with the injected JMS resources. Now imagine that the service is a singleton or application scoped managed bean instead and is thus very long lived. This means that this code would cause the container to create and inject open connections/sessions that are not released for a while, potentially causing performance problems. Can you think of a way to solve this problem?

    Hint: one way to solve this is to use a custom @TransactionScoped or @ThreadScoped for the JMS resources. This is being considered for addition to the Resin container (as such, it is probably a good optimization even for the EJB case). Also under consideration: Adding generic JMS/JDBC abstractions based on CDI similar to the example as part of Resin that you can simply use out-of-the-box. Can you imagine how the JDBC abstraction might look like? Would it be useful to you?

    CDI producers and disposers support even more powerful constructs such as utilizing injection point meta-data, using producer fields, or using producers with Java EE resources and so on - you should check out the CDI specification for details (alternatively, feel free to check out the Weld reference guide that's a little more reader-friendly). Utilizing producers and scoped beans with JSF is particularly interesting and we will look at this in a later article focusing on CDI's interaction with JSF.

    To give you a taste of some of the more advanced features, let's look at a producer example using injection point meta-data. By using injection point meta-data in producers, you can get runtime information about where the object you are programmatically creating will be getting injected into. You can use this data in very interesting ways in your code. Here is an example that constructs and injects a custom logger into a service:

    @Stateless
    public class BidService {
    @Inject private Logger logger;
    ...
    }

    public class LoggerFactory {
    @Produces
    public Logger getLogger(InjectionPoint injectionPoint) {
    return Logger.getLogger(
    injectionPoint.getMember().getDeclaringClass().getSimpleName());
    }
    }

    As you can see from the example above, all you need to do to get access to injection point meta-data is include the InjectionPoint interface as a producer method parameter. When CDI invokes your producer, it will collect meta-data at the injection point (the logger instance variable in this case) and pass it to your producer. The injection point interface can tell you about the bean being injected, the member being injected, qualifiers applied at the injection point, the Java type at the injection point, any annotations applied and so on. In the example, we are creating a logger specific to the class that holds the logger using the name of the class that is the injection target.

    The injection point interface is actually part of the CDI SPI geared toward portable extensions, which we will discuss in a later article.

    OpenWebBeans Portable Extensions
    One of the goals of the Apache CDI implementation, OpenWebBeans, is to expose various popular Apache projects as CDI portable extensions. It's very likely you will see something similar to the logger example above as a CDI portable extension for Log4J (CDI portable extensions for Apache commons is probably very likely too).

    Naming Objects
    As we discussed, one of the primary characteristics of CDI is that dependency injection is completely type-safe and not dependent on character-based names that are prone to mistyping and cannot be checked via an IDE, for example. While this is great in Java code, beans would not be resolvable without a character-based name outside Java such as in JSP or Facelet markup. CDI bean name resolution in JSP or Facelets is done via EL. By default, CDI beans are not assigned any names and so are not resolvable via EL binding. To assign a bean a name, it must be annotated with @Named like so:

    @RequestScoped @Named
    public class Bid {
    ...
    }

    The default name of the bean is assigned to be "bid" - CamelCase with the first letter lower-cased. The bean would now be resolvable via EL binding as below:

    <h:inputText id="amount" value="#{bid.amount}"/>

    Similarly, objects created by producer methods are assigned the name of the method or the Java property name by default when the producer is annotated via @Named. The list of products produced in the example below is named "products", for instance:
    @Produces @ApplicationScoped @Named
    public List getProducts() { ... }
    You can most certainly override default names as needed as shown below:
    @Produces @ApplicationScoped @Catalog @Named("catalog")
    public List getProducts() { ... }

    @ConversationScoped @Named("cart")
    public class ShoppingCart {

    In most cases, you would likely not override bean names, unless overriding names improves readability in the context of JSP/Facelet EL binding.

    Names in Dependency Injection
    Technically, @Named is defined to be a qualifier by JSR 330. This means that you can use character-based names to resolve dependencies in JSR 299 if you really, really want to. However, this is discouraged in CDI and there are few good reasons to do it instead of using more type-safe Java based qualifiers (can you think of what the reasons might be?).

    Looking up CDI Beans
    While dependency injection is the way to go most of the time, there are some cases where you cannot rely on it. For example, you may not know the bean type/qualifier until runtime, it may be that there are simply are no beans that match a given bean type/qualifier or you may want to iterate over the beans which match a certain bean type/qualifier. The powerful CDI Instance construct allows for programmatic bean look-up in such cases. Let's see how this works via a few examples.

    In the simplest case, you may want to know about the existence of a bean with a certain type (let's say a Discount) because you are not certain if it was deployed given a particular system configuration. Here is how you can do it:
    @Inject private Instance discount;
    ...
    if (!discount.isUnsatisfied()) {
    Discount currentDiscount = discount.get();
    }

    In the example above, we are injecting the typed Instance for the discount bean. Note, this does not mean that the discount itself is injected, just that you can look-up discounts as needed via the typed Instance. When you need to query for the discount, you can check if it exists via the isUnsatisfied method. You can also check for ambiguous dependencies if you need to. If the discount was deployed, you can then actually get the resolved bean and use it. If you need to, you can apply qualifiers to an Instance. For example, you can look for a holiday discount as below:
    @Inject @Holiday private Instance discount;
    Now let's assume that there might be multiple matches for a particular bean type/qualifier - there is likely more than one discount, for example. You can handle this case by placing the @Any annotation on an Instance as below and iterating over all the matches:
    @Inject @Any private Instance anyDiscount;
    ...
    for (Discount discount: anyDiscount) {
    // Use the discount...
    }

    Note that Instance is an Iterable as a convenience, which is why the abbreviated foreach loop syntax above works. If needed, you can narrow down the matches by qualifier and/or sub-type at runtime. This is how you could filter by qualifier:
    @Inject @Any private Instance anyDiscount;
    ...
    Annotation qualifier = holiday ? new Holiday() : new Standard();
    Discount discount = anyDiscount.select(qualifier).get();


    The select method allows you to narrow down the potential discount matches by taking one or more qualifiers as arguments. If it's a holiday, you would be interested in holiday discounts instead of standard discounts in the example code. You can also pass a bean sub-type to the select method as below:
    Instance sellerDiscount =
    anyDiscount.select(SellerDiscount.class, new Standard());

    There is much more to the Instance construct that you should definitely check out by taking a look at the CDI specification itself (or the Weld reference guide). You can also use the CDI SPI intended for creating portable extensions to look up beans in a more generic fashion. We will cover portable extensions in a future article in the series.

    Tuesday, January 19, 2010

    JAX-WS Implementations

    There are multiple APIs for the Java platform, e.g. for database access or web applications. The developer has to code against a standard not against a product. The particular tools and servers stay replaceable. For example a web application can be operated with both the Application Server IBM Web Sphere and the Web Container Apache Tomcat. Due to the standardization by the Java Enterprise Edition the exchange of a server can be done with little effort.

    Unfortunately, Web Services are a different story. Indeed there is the JAX-WS specification, but there are still too many unanswered questions as well as alternative approaches of applying Web Services. Which SOAP implementation is suitable depends on the requirements and the environment. The sections below are describing the tools and standards that are available for developers of Web Services.

    Apache Axis2
    Axis 2 is the follow-up of the popular Axis1 framework. Axis2 is based on a completely new architecture and has been re-developed from scratch.

    The deployment of services for Axis 1 has often been criticized. Therefore Axis 2 has a completely new deployment model. An Axis 2 runtime is a Web application and can be installed on every JEE compliant Application Server. The Axis 2 web application itself is a container for Web Services now. Web Services are packed into an own file format with the file extension aar. Due to these archives, Web Services can be installed and configured by a simple user interface at run time. In Axis 2 the services can be configured by the traditional deployment descriptors, e.g. the file services.xml.

    Modules providing additional functionality, for example WS-* standard support, can also be installed during runtime. A Web Service is regarded as an independent package which can be installed into the Axis 2 runtime environment.

    Writing an Axis 2 project requires a lot of knowledge about the build tool Ant. Knowledge about the build tool is essential to write an Axis 2 project. For example the WSDL2JAVA task is generating a temporary project including a build-file. Then the projects build-file has to call the generated build-file. If a Web Service uses a library, e.g. a JDBC driver, then the library has to be copied into the generated project using Ant on each build. So development with Axis 2 will be very difficult if you are not familiar with Ant.

    Apache CXF
    CXF is also a project of the Apache software foundation. CXF came up from a fusion of the XFire and Ionas Celtix projects.

    CXF was developed with the intention to integrate it into other systems. This is reflected in CXF API and the use of the Spring framework. Therefore it is very simple to integrate CXF into existing systems.

    CXF respectively its predecessor XFire was integrated into numerous open and closed source projects like ServiceMix or Mule.

    A proprietary API as well as the standardized JAX-WS interface are available for the development and use of Web Services.

    JAX-WS
    The Java API for XML based Web Services is the successor of the JAX-RPC specification. JAX-WS respectively its predecessor is message based and supports asynchronous communication. The Configuration is managed by annotations therefore Java 5 or higher is required. JAX-WS isn't downwardly compatible to its predecessor JAX-RPC. With JAX-WS it is pretty easy to write and consume Web Services. The default values of numerous parameters are comfortable for the programmer, so that simple Pojos declared with a @WebService annotation can be used as a Service. Listing 1 shows a simple implementation of a Web Service using the @WebService annotation.

    import javax.jws.WebService;
    import javax.jws.WebMethod;

    @WebService
    public class HelloWorldService {

    public String helloWorld() {
    return "Hello World!";
    }
    }

    Listing 1: HelloWorld Web Service using JAX-WS

    A suitable WSDL document can also be generated from the class. Other annotations can concertedly exert influence of the WSDL document. For example other namespaces or element names can be used. If JAXB is already known, its annotations can be used to define the serialization in every detail. With the contract first approach a Service Interface, JAXB annotated classes for serialization and a skeleton for the implementation can be generated. According to the WSDL document the generated classes can have numerous annotations. Annotations are also the main point of criticism of JAX-WS. Despite this criticism the JAX-WS specification came out well. It is well attuned and combinable with other Java and Java EE specifications. For example, Listing 2 shows a stateless EJB 3.0 Bean which acts as a Web Service at the same time.

    @WebService
    @Stateless
    public class MyService{
    public String hello(String name) {
    return "Hallo"+name;
    }
    }

    Listing 2: Stateless SessionBean acting as Web Service

    JAX-WS Reference Implementation
    The JAX-WS Reference Implementation represents the core piece of the Web Services protocol stack Metro. The Metro Stack provides support for the following Web Services standards:

    WS-Addressing
    WS-Policy
    Web Services Security aka WS-Security
    WS-Transaction
    WS-Reliable Messaging
    WS-Trust
    WS-SecureConversation

    Metro is documented in detail. Apart from the JAX-WS, JAXB and JWS specifications there are numerous tutorials und samples. The Netbeans IDE as well as the tutorials of the enterprise pack makes it particularly easy to get started. Of course, Eclipse can also be used for the development with Metro.

    Web applications containing Web Services which have been realized with JAX-WS are executable in the Glassfish Application Server. To make services also executable in other application servers, two libraries (JAX-WS and JAXB) have to be installed. Application servers such as JBoss, WebSphere or Tomcat can be upgraded with JAX-WS within about 10 minutes.

    Performance
    Due to the modern streaming XML parser, the performance of all three SOAP engines is very well. The ping time for a locale roundtrip is about 2-4 milliseconds (message size about 3KB, Dual Core Notebook). Therefore the time delay by the SOAP communication is negligible in many projects.

    WS-* Standards
    The support of the WS-Standard family can also be decisive for the selection of a SOAP engine. For example, messages sent to services can be secured with signatures as described in the Web Service Security standard (in short WSS). Table 1 shows the support for WS*-Standards of the toolkits.

    Conclusion
    None of the Web Services frameworks is in general superior to the others. Axis 2 is structured modularly, has many features and can be used as an application server for Web Services. A special feature of Axis 2 is the support of removable binding frameworks, for example XMLBeans. Axis 2 together with the XMLBeans framework included is well suited for Web Services which are using very complex schema definitions. The disadvantages of Axis 2 are its complexity as well as the insufficient JAX-WS support. Therefore anyone who wants to work with JAX-WS should choose Apache CXF or the reference implementation.

    Those who prefer a seamless integration with the Spring framework are well advised with the JAX-WS implementation. Furthermore CXF is slim and easy to use. CXF is the tool of choice if a SOAP engine has to be embedded into an existing software.

    Who just wants to code against the standard is well advised with the JAX-WS implementation. The enterprise pack of the Netbeans development environment supports JAX-WS RI very well. Only a few clicks are needed to build a server or to call a Web Service.

    I hope this article could help you with the decision for a WS toolkit.

    StandardsAxis2CXFJAX-WS/Metro
    WS-AddressingXXX
    WS-CoordinationX(2)X
    WS-MetadataExchangeX
    WS-PolicyXXX
    WS-ReliableMessagingX(3)XX
    Web Services SecurityX(1)X(4)X
    WS-SecureConversationX(1)X
    WS-SecurityPolicyX
    WS-TransactionX(2)X
    WS-TrustXX
    WS-Federation

    Table 1: Support for WS-* Standards (stand: Juli 2008)

    (1) Supported by the additional module Apache Rampart
    (2) Supported by the additional module Apache Kandula2
    (3) Supported by the additional module Apache Sandesha2
    (4) By Apache WSS4J Interceptor

    JAX-RCP vs JAX-WS

    JAX-RPC
    A specification/API for Java developers to develop SOAP based interoperable web services. This API is now obsolete, and may be dropped from the next JEE version.

    JAX-WS
    The successor to JAX-RPC. It requires Java 5.0, and is not backwards-compatible to JAX-RPC. This article describes the high-level differences to JAX-RPC.

    SAAJ
    Another specification/API for using SOAP envelopes with or without attachments. It operates on a lower level than JAX-RPC or JAX-WS, both of which will use SOAP envelopes based on SAAJ if needed.

    JAX-RPC 2.0 (Java API for XML Based RPC) has been renamed to JAX-WS 2.0 (Java API for XML Web Services).

    This was done for a number of reasons, but the main reasons are:
    The JAX-RPC name is misleading, developers assume that all JAX-RPC is about is just RPC, not Web Services.

    By renaming JAX-RPC to JAX-WS we can eliminate this confusion. JAX-RPC 2.0 uses JAXB for all databinding.

    As the bindings are different in JAX-RPC 1.1, it introduced a number of source compatibility issues. The migration from JAX-RPC 1.1 to JAX-RPC 2.0 is not cookie cutter as generated Java code and schemas will be different than those generated by JAX-RPC 1.1.

    Although the renaming does not ease this migration, it does let the developer know that these are two separate technologies, hence the more difficult migration is more palatable.

    Maintaining binary compatibility with the JAX-RPC 1.1 APIs, was hindering our goal of ease-of-development. Because we had this binary compatibility requirement, many legacy APIs were exposed such as the various methods on javax.xml.rpc.Service and the javax.xml.rpc.Call. Having these legacy APIs around would confuse developers. By renaming JAX-RPC 2.0 to JAX-WS 2.0 we no longer have this binary compatibility requirement and we can rid the APIs of these legacy methods and interfaces and we can focus on a new set of APIs that are easier to understand and use.

    WebService Implementations
    Apache Axis
    An open source implementation of the Java WS APIs for sending and receiving SOAP messages. Axis 1 supports JAX-RPC and SAAJ, while Axis 2 supports SAAJ and JAX-WS.

    Apache SOAP
    The first SOAP implementation. It is now obsolete. It's better to use Apache Axis to avail oneself of the latest features.

    Sun JWSDP
    Sun Java Webservices Developer Pack, is an implementation of JAX-RPC, SAAJ and various other XML Java technologies. It is now deprecated in favor of GlassFish.

    Metro
    The web services stack used in GlassFish?. It supports SAAJ, JAX-WS, WS-Security and other standards.

    JAX-RS
    It is a Java API for RESTful web services.
    Jersey is the reference implementation of the JAX-RS API, as defined in the JSR-311 standard for RESTful web services.

    For more info, see http://faq.javaranch.com/java/WebServicesFaq.

    Friday, January 15, 2010

    Who is the best JPA Provider in WebLogic?

    http://www.theserverside.com/news/thread.tss?thread_id=44219

    Posted by: Gavin King on February 10, 2007 in response to Message #227266
    And by the way - I'm a bit out of date, but the actual measurements I did a year or so ago of simple CRUD performance of Hibernate vs. Kodo gave a mixed bag of results. They are slightly faster on creation/destruction of the persistence context and on inserts, we are a bit faster on queries. For mass operations on many objects, they are faster if you use standard APIs, we are quicker if you use StatelessSession. Etc.

    Nowhere did I find anything that was a big enough difference that you would prefer one product over the other on the basis of performance alone.

    Which confirmed to me that the BEA marketing line of the time that "Kodo is faster than Hibernate" is just the usual marketing BS, which was my initial reaction.

    Thursday, January 14, 2010

    EJB3 Weblogic 10 and backward compability

    (http://blog.sunfire.nu/2008/12/ejb3-weblogic-10-and-backward.html)

    Been trying to develop EJB3s that will be hosted on a Weblogic 10 server, and some client applications that will be running on Weblogic 8.
    Took me a while to figure out how to get the JDNI names and stuff right for the EJBs as well as how to be compatible with EJB2 spec (since Weblogic 8 and JDK1.4 doesn't support EJB3).

    There are of course a million tutorials and examples to find using google, so that's were I started. Found one here to start with but I ended up getting ClassCastExceptions. Looking at the EJB3 specs I found the mappedName attribute of the @Stateless annotation, and after setting that I got my client code working. Since mappedName is vendor-specific the information will not be applicable if you're running a different application server.

    package ejb;
    public interface TestRemote {
    public String echo(String s);
    }
    ----------------------
    package ejb;
    import javax.ejb.*;

    @Stateless(mappedName="Base")
    @Remote(TestRemote.class)
    public class TestBean implements TestRemote {
    public String echo(final String s) {
    return "echo: " + s;
    }
    }

    The clients can now perform a lookup like this:

    Properties p = new Properties();
    p.put("java.naming.factory.initial","weblogic.jndi.WLInitialContextFactory");
    p.put("java.naming.provider.url", "t3://localhost:7001");
    p.put("java.naming.security.principal", "weblogic");
    p.put("java.naming.security.credentials", "weblogic");
    InitialContext ctx = new InitialContext(p);
    TestRemote test = (TestRemote) ctx.lookup("Base#ejb.TestRemote");
    test.echo("Hello");

    After getting my clients to access the EJB3s (the clients were using WLS10 libraries and JDK6) and calling methods on them I moved on to get them to work with WLS8 clients.
    This turned out to involve a little more effort, suddenly it wasn't enough to write POJOs and annotations.
    First of all, we need to create a EJB2 equivivalent business interface for our EJB3 interface (TestRemote) that must extend javax.ejb.EJBObject and contain the same methods that must throw java.rmi.RemoteException.

    package ejb;
    public interface TestRemote2 extends javax.ejb.EJBObject {
    public String echo(String s) throws java.rmi.RemoteException;
    }

    Second, we need a Home interface that the EJB2 client can lookup and use to create the EJB:

    package ejb;
    import java.rmi.RemoteException;
    import javax.ejb.*;
    public interface TestRemoteHome extends EJBHome {
    public TestRemote2 create() throws CreateException, RemoteException;
    }

    Notice that the create method returns the EJB2 interface (of course...).
    Finally, we update the bean class itself:

    package ejb;

    import javax.ejb.*;

    @Stateless(mappedName="Base")
    @Remote(TestRemote2.class)
    @RemoteHome(TestRemoteHome.class)
    public class TestBean implements TestRemote {
    public String echo(final String s) {
    return "echo: " + s;
    }
    }

    Ok, we changed the Remote annotation to contain the EJB2 interface instead and we added the RemoteHome annotation as well to specify the Home interface to publish. Notice that we still implement TestRemote (not the EJB2 interface) so at least we don't have to worry about RemoteExceptions here.

    The client code looks like this:

    // Context setup as before
    Object o = ctx.lookup("Base#ejb.TestRemoteHome");
    TestRemoteHome home = (TestRemoteHome)PortableRemoteObject.
    narrow(ctx.lookup("Base#ejb.TestRemoteHome"),
    TestRemoteHome.class);
    TestRemote21 test = home.create();
    test.echo("Hello");

    That's all there is to it.

    Update after comments:
    To enable both EJB3 and EJB2 beans you just add the interfaces in the @Remote annotation like this:
    @Remote({TestRemote2.class, TestRemote.class})

    Why use ejb-ref in web.xml?

    The advantage is indirection. If the code directly references EJBs in your servlets through JNDI, it will work just when the JNDI name does not be changed during deployment.

    By using an ejb-ref you create an alias for the bean. During coding, the alias is used to locate the beans home.

    eg. context.lookup("java:comp/env/ejb/myBean");

    The developer also creates an entry in the web.xml like this:

    EJB remote reference:
    <ejb-ref>
    <ejb-ref-name>ejb/myBean</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <ejb-ref-home>some.package.MyBeanHome</ejb-ref-home>
    <ejb-ref-remote>some.package.MyBeanRemote</ejb-ref-remote>
    <ejb-link>MyAppEJB.jar#myBean</ejb-link>
    </ejb-ref>
    EJB local reference:
    <ejb-local-ref>
    <ejb-ref-name>ejb/myBean</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local>com.myapp.session.MyBeanLocal</local>
    <ejb-link>MyAppEJB.jar#myBean</ejb-link>
    </ejb-local-ref>




    On deployment, the deployer creates a mapping between the alias ejb/myBean and the JNDI name that the bean is actually deployed with. This will allows the deployer to change a beans' JNDI name without modifying the code (If you used JNDI directly, you have to modify it).

    The name referenced in the ejb-link (in this example, myBean) corresponds to the <ejb-name> element of the referenced EJB's descriptor. With the addition of the <ejb-link> syntax, the <ejb-reference-description> element is no longer required if the EJB being used is in the same application as the servlet or JSP that is using the EJB.

    In WebLogic, since the JAR path is relative to the WAR file, it begins with "../". Also, if the ejbname is unique across the application, the JAR path may be dropped and just put the bean name at there.

    Mapping is vendor specific feature. For example, in WebLogic this is done in the weblogic.xml file.

    Friday, January 08, 2010

    How to get the JNDI of EJB in WebLogic 10g R3

    If you want to the EJB accessible from general classes instead of managed beans, you have to let it can be searchable in JNDI tree. But you can not get the JNDI if you didn't set the mappedName in WebLogic 10g R3.

    A sample:

    @Stateless ( name="UserBean", mappedName="ejb.User")
    public class UserBean implements UserLocal, UserRemote {
    }


    After you deployed it in Webglogic 10, you can get access to the remote interface with:

    String JNDI_NAME = "ejb.User#" + UserRemote.class.getName();
    UserRemote user = (UserRemote) new InitialContext().lookup(JNDI_NAME);

    New features in JEE 6

    JEE 6 new features:
    profiles, pruning, and extensibility
    Enterprise JavaBeans (EJB), Java Servlet, and Java Persistence API (JPA)
    new APIs/technologies: Java API for RESTful Web Services (JAX-RS) and Java Contexts and Dependency Injection (JCDI/Web Beans)

  • Extensibility: This mechanism provides a way to include additional technologies and frameworks that are not part of the standard platform.

  • Profiles: This build on the standard Java EE platform technologies, sometimes using only a subset of those technologies, and sometimes adding Java technologies that are not part of the standard platform.

  • Pruning: Pruning provides a way to remove some technologies from the platform.


  • Enterprise JavaBeans 3.1
  • Removal of local business interface: EJB 3.0 removed the complex home and remote interfaces and made way for the plain old Java interface (POJI). EJB 3.1 goes one step further by dictating that business interfaces also are not mandatory.


  • @Stateless
    public class StockQuoteBean {...}

  • Introduction of Singleton beans: The concept of Singleton beans was introduced primarily to share application-wide data and support concurrent access. All Singleton beans are transactional and thread safe by default, making way for flexible concurrency options. Java EE 6 also introduces concurrency annotations to perform locked read/write operations on getter and setter methods.


  • @Singleton
    @Startup
    public class CounterBean {
    private int count;
    @PostConstruct
    public void initialize() {
    count=5;
    }
    }

  • Packaging EJB components directly in a WAR file: One of the major advancements in EJB 3.1 is the option for including EJB in a WAR file directly instead of creating a separate JAR file.

  • Embeddable API for executing EJB in Java SE environment: The idea behind this feature is to allow EJBs to run in Java SE environments; that is, the client and the EJB run in the same JVM. The javax.ejb.EJBContainer class represents an embeddable container. Embeddable containers support EJB Lite.

  • Asynchronous Session Bean: A session bean can support asynchronous method invocations. Bean methods annotated with @Asynchronous are invoked asynchronously. Asynchronous methods can return a Future object of the java.util.concurrent API. This will be useful for the client to get the status of the invocation, retrieve the return value of a method, check for an exception, or even cancel the invocation.

  • EJB Lite: The concept of profiles is applied to the EJB specification as well. Many enterprise applications do not require the complete set of features in EJB, so EJB Lite, a minimal subset of the EJB API, is introduced in EJB 3.1. EJB Lite provides vendors the option to implement a subset of the EJB APIs within their products. Applications created with EJB Lite can be deployed on any server that supports EJB technology, irrespective of whether it is full EJB or EJB Lite.


  • EJB Lite has the following subset of the EJB API:
    * Session bean components (Stateless, stateful, singleton session beans)
    * Supports only synchronous invocation
    * Container-managed and bean-managed transactions
    * Declarative and programmatic security
    * Interceptors
    * Support for deployment descriptor (ejb-jar.xml)



    Servlet 3.0 will introduce are:
  • Support for Annotations: Instead of making an entry in a deployment descriptor (web.xml), developers can use annotations to mark a servlet.

  • @WebServlet is used to mark a class that extends HttpServlet as a servlet.
    @WebFilter is used to mark a class that implements Filter as a filter
    @WebInitParam is used to specify an init parameter
    @WebListener is used to specify a listener

    @WebServlet("/stockquote")
    public class StockQuoteServlet extends HttpServlet {...}

    @WebServlet(name="StockQuoteServlet", urlPatterns={"/stockquote","/getQuote"})
    public class StockQuoteServlet extends HttpServlet {...}

    @WebFilter("/login")
    public class LoginFilter implements Filter {...}

  • Web fragments: Web fragments are meant to provide modularity. They provide logical partitioning of the deployment descriptor web.xml so that frameworks such as Struts and JavaServer Faces (JSF) can have their own piece of information added in the JAR file, and the developer doesn't have to edit web.xml.

    Web fragments are identified by using web-fragment as the root element. Developers can use all the elements in the deployment descriptor. The only condition is that the root element must be and hence have the name web-fragment.xml. This element is typically placed in the WEB-INF\lib folder. Any JAR file placed in the WEB-INF\lib folder can include the web fragment.

    When an application has multiple web fragments, the order of execution can be resolved using absolute ordering or relative ordering. In both cases, XML tags are used to identify the order. Absolute ordering is specified using in web.xml and relative ordering is specified using in web-fragment.xml.

    When the element is not mentioned or set to false in the deployment descriptor, the container skips processing web.xml and processes annotations and web fragments. If is set to true, then the container skips processing annotations and web fragments and processes based on the information available in web.xml, because this takes precedence.

  • Asynchronous processing: Servlets allow asynchronous processing in Java EE 6 to support AJAX. A servlet often has to wait for a response from a resource such as a database or a message connection. Asynchronous processing avoids the blocking request so that the thread can return and perform some other operation. Developers can mark servlets as asynchronous by setting the value true to the asyncSupported attribute of the @WebServlet or @WebFilter annotation. In addition to the annotation, some new APIs such as AsyncContext have been introduced, and methods such as startAsync have been added to the ServletRequest and ServletResponse classes.


  • JAX-RS 1.1 and JCDI 1.0
  • JAX-RS fully supports REST principles, and provides POJO resources to which developers can add annotations to make them support REST. Due to the nature of HTTP, JAX-RS supports only stateless interactions. Sun provides a reference implementation for JAX-RS codenamed Jersey.

  • JCDI allows developers to bind Java EE components to lifecycle contexts, to inject these components, and to enable them to support loosely coupled communication.
  • Contexts and Dependency Injection for Java EE (CDI) - Part 1

    (See details: http://www.theserverside.com/tt/articles/content/DependencyInjectioninJavaEE6/article.html)
    Contexts and Dependency Injection for Java EE (CDI) - JSR 299.
    Leader: Gavin King

    CDI is the de-facto API for comprehensive next-generation type-safe dependency injection for Java EE, which aims to synthesize the best-of-breed dependency injection features from solutions like Seam, Guice and Spring while adding many useful innovations of its own.

    Java EE 5
    What you can do is:
  • Injecting container resources such as JMS connection factories, data sources, queues, JPA entity managers, entity manager factories and EJBs via the @Resource, @PersistenceContext, @PersistenceUnit and @EJB annotations into Servlets, JSF backing beans and other EJBs.


  • What you could not is:
  • Injecting EJBs into Struts Actions or JUnit tests and you could not inject DAOs or helper classes that were not written as EJBs because they do not necessarily need to be transactional.

  • More broadly, it was difficult to integrate third-party/in-house APIs or use Java EE 5 as a basis to build such APIs that are not just strictly business components.


  • CDI is designed to solve in a highly type-safe, consistent and portable way that fits the Java philosophy well.

    Comparison with existing technologies.
  • Spring IoC - CDI is likely to feel more type-safe, futuristic and annotation-driven.

  • Seam - CDI has a lot more advanced features.

  • Guice - CDI is perhaps more geared towards enterprise development than it.


  • CDI enhances the Java EE programming model in two more important ways - both of which come from Seam.
  • First, it allows you to use EJBs directly as JSF backing beans.

  • Second, CDI allows you to manage the scope, state, life-cycle and context for objects in a much more declarative fashion, rather than the programmatic way most web-oriented frameworks handle managing objects in the request, session and application scopes.


  • CDI has no component model of its own but is really a set of services that are consumed by Java EE components such as managed beans, Servlets and EJBs.

    Managed beans are a key concept introduced in Java EE 6 to solve some of the limitations when using Java EE 5 style resource injection.

    A managed bean is just a bare Java object in a Java EE environment. Other than Java object semantics, it has a well-defined create/destroy life-cycle that you can get callbacks for via the @PostConstruct and @PreDestroy annotations. Managed beans can be explicitly denoted via the @ManagedBean annotation, but this IS NOT ALWAYS needed, especially with CDI. From a CDI perspective, this means that almost any Java object can be treated as managed beans and so can be full participants in dependency injection.

    Traditional JSF backing beans are now managed beans.
    All EJB session beans are now also redefined to be managed beans with additional services (thread-safety and transactions by default).

    Servlets are NOT yet redefined to be managed beans.

    CDI also integrates with JSF via EL bean name resolution from view technologies like Facelets and JSP as well as automatic scope management.

    CDI's integration with JPA consists of honoring the @PersistenceContext and @PersistenceUnit injection annotations, in addition to @EJB and @Resource.

    Note
    CDI DOES NOT directly support business component services such as transactions, security, remoting, messaging and the like that are in the scope of the EJB specification.

    JSR 299 utilizes the Dependency Injection for Java (JSR 330) specification as its foundational API, primarily by using JSR 330 annotations such as @Inject, @Qualifier and @ScopeType. Led by Rod Johnson and Bob Lee, JSR 330 defines a minimalistic API for dependency injection solutions and is primarily geared towards non-Java EE environments.

    CDI essentially adapts JSR 330 for Java EE environments while also adding a number of additional features useful for enterprise applications.



    Dependency Injection Basics


    @Stateless
    public class BidService {
    @Inject
    private BidDao bidDao;

    public void addBid (Bid bid) {
    bidDao.addBid(bid);
    }
    }

    public class DefaultBidDao implements BidDao {
    @PersistenceContext
    private EntityManager entityManager;

    public void addBid (Bid bid) {
    entityManager.persist(bid);
    }
    }

    public interface BidDao {
    public void addBid (Bid bid);
    }


    The bid DAO managed bean is being injected into the bid service EJB session bean via the @Inject annotation. CDI resolves the dependency by looking for any class that implement the BidDao interface. When CDI finds the DefaultBidDao implementation, it instantiates it, resolves any dependencies it has (like the JPA entity manager injected via @PersistenceContext) and injects it into the EJB bid service. Since no explicit bean scope is specified for either the service or the DAO, they are assumed to be in the implicit dependent scope.

    Qualifiers are additional pieces of meta-data that narrow down a particular class when more than one candidate for injection exists.

    @Stateless
    public class BidService {
    @Inject @JdbcDao
    private BidDao bidDao;
    ...
    }

    @JdbcDao
    public class LegacyBidDao implements BidDao {
    @Resource(name="jdbc/ActionBazaarDB")
    private DataSource dataSource;
    ...
    }


    Context Management Basics

    Every object managed by CDI has a well-defined scope and life-cycle that is bound to a specific context. As CDI encounters a request to inject/access an object, it looks to retrieve it from the context matching the scope declared for the object. If the object is not already in the context, CDI will get reference to it and put it into the context as it passes the reference to the target. When the scope corresponding to the context expires, all objects in the context are removed.

    Available Scope Definition
    Dependent, ApplicationScoped, RequestScoped, SessionScoped, ConversationScoped

    Besides the built-in scopes above, it is also possible to create custom scopes via the @Scope annotation

    @Named
    @RequestScoped
    public class BidManager {
    @Inject
    private BidService bidService;
    ...
    }

    @Stateless
    public class BidService {
    @Inject
    private BidDao bidDao;

    @Inject
    private BiddingRules biddingRules;
    ...
    }

    @ApplicationScoped
    public class DefaultBiddingRules implements BiddingRules {
    ...
    }


    @Named annotation makes the bid manager accessible from EL.



    JSR 330 defines a minimalistic API for dependency injection solutions and is primarily geared towards non-Java EE environments. In particular, it does not define scope types common in server-side Java such as request, session and conversation. It also does not define specific integration semantics with Java EE APIs like JPA, EJB and JSF.

    Thursday, January 07, 2010

    Performance monitoring for web applications

    MessAdmin is a light-weight and non-intrusive tool for monitoring and interacting with Java HttpSession. MessAdmin can be added to any J2EE application, with zero change to the monitored application!


    ZK's performance meter utility provides developers with the means to determine execution times in different stages of an Ajax request and response cycle.
    Sam Chuang illustrates his implementation of a ZK performance monitor here: http://docs.zkoss.org/wiki/A_ZK_Performance_Monitor.

    What Is The Relation Between JSR-299 and JSR-330 In Java EE 6?

    http://java.dzone.com/articles/what-relation-betwe-there

    JSR-330 (Dependency Injection for Java) led by Rod Johnson (SpringSource) and Bob Lee (Google Inc.) became a part of Java EE 6. JSR-330 is very simplistic. It comes with own few annotations from the package: javax.inject. The package contains the following elements: Inject, Qualifier, Scope, Singleton, Named and Provider. Its the definition of the basic dependency injection semantics.

    JSR-299 (Java Contexts and Dependency Injection), with Gavin King as lead, uses JSR-330 as base and enhances it significantly with modularization, cross cutting aspects (decorators, interceptors), custom scopes, or type safe injection capabilities. JSR-299 is layered on top of JSR-330.

    It is amusing to see that the built-in qualifier @Named is not recommended and should be used only for integration with legacy code:

    "The use of @Named as an injection point qualifier is not recommended, except in the case of integration with legacy code that uses string-based names to identify beans."
    [3.11 The qualifier @Named at injection points, JSR-299 Spec, Page 32]

    The relation between JSR-299 and JSR-330 is comparable to the relation between JPA and JDBC. JPA uses internally JDBC, but you can still use JDBC without JPA. In Java EE 6 you can just use JSR-330 for basic stuff, and enhance it on demand with JSR-299. There is almost no overlap in the practice. You can even mix JSR-299 / JSR-330 with EJB 3.1 - to streamline your application.

    Friday, December 18, 2009

    JBoss Riftsaw - Open Source BPEL

    Riftsaw supports short-lived and long-running process executions, process persistence and recovery, process versioning, JBoss deployment architecture enabling hot deployment of your BPEL processes and integration with JBossESB and UDDI using jUDDI. An Eclipse-based BPEL designer is bundled with JBossTools 3.1.

    Riftsaw is based on Apache Ode, and adds support to run on any JAX-WS compliant WebServices stack and it ships with a new GWT based Admin console.

    From BPEL to the ESB and Back - Introduction to the Riftsaw-JBoss ESB Integration

    jBPM goes BPMN!

    http://www.jorambarrez.be/blog/2009/12/04/jbpm-goes-bpmn/

    What is BPMN2?
    Basically, the Business Process Modeling Notation (BPMN) started out a pure graphical notation standard for business processes, maintained by the Object Management Group (OMG). Version 2.0, which currently is in beta, adds execution semantics to the specification and this is of course where it gets interesting for jBPM.

    The primary benefit of BPMN2 is that it is a standard accepted by the IT industry, which means that process models become portable (graphical and execution-wise) across process engines such as jBPM. Since process executions are the raison-d-être of jBPM, it is only natural we are now investing in BPMN2. People who are familiar with JPDL (the current native language of jBPM) will have generally no difficulties in learning the BPMN2 language, as many constructs and concepts are shared. In fact, from a high-level point of view, BPMN2 and JPDL are in concept solving the same problem

    What is different jBPM and Riftsaw?

    Riftsaw is based up-on Apache ODE and there is no BPEL engine available on top of the PVM(Process Virtual Machine). There is no BPEL in jBPM4 anymore. There is just jPDL and BPMN2 which is still in development.

    jBPM3 BPEL is a BPEL 1.x implementation while Riftsaw is a BPEL 2.0 implementation.

    SCA Spring in Weblogic 10.3.2 & Soa Suite 11g

    Are you ready for SCA? Currently, the SCA is much more popular. The follow links are a introduction of SCA Spring on WebLogic 10g.

    SCA Spring in Weblogic 10.3.2 & Soa Suite 11g
    SCA Spring in Weblogic 10.3.2 & Soa Suite 11g Part 2

    Friday, December 11, 2009

    Java Persistence API Pro

    (From http://hobione.wordpress.com/jpapro/)




    Java Persistence API Pro


    Book Reference: Pro EJB 3: Java Persistence API (Pro)


    Chapter 1


    Why Persistence?

    As all we know that understanding the relational data is key to successful enterprise development. Moving data back and forth between to database system and the object model of a Java application is a lot harder than it needs to be. Java developers either seem to spend a lot of time converting row and column data into objects, or they find themselves tied to proprietary frameworks that try to hide the database from the developer. The Java Persistence API is set to have a major impact on the way we handle persistence within Java. For the first time, developers have a standard way of bridging the gap between object-oriented domain models and relational database systems.


    Java Object – Database Relational Mapping:

    The main thought behind to convert JDBC result sets into something object-oriented as follows.

    ” The domain model has a class. The database has a table. They look pretty similar. It should be simple to convert from one to the other automatically” The science of bridging gap between the object model and the relational model is known as object-relational mapping, aka O-R mapping or ORM.


    Inheritance (Life is a dirty beach without JPA):

    A defining element of an object-oriented domain model is to opportunity to introduce generalized relationships between like classes. Inheritance is the natural way to express these relationship and allows for polymorphisms in the application. When a developer start to consider abstract superclasses or parent classes with no persistent form, inheritance rapidly becomes a complex issue in object-relational mapping. Not only is there a challenge with storage of the class data, but the complex table realtionship are difficult to query efficiently.


    JPA saves our soul (SOS):

    The Java Persistence API is a lightweight, POJO-based framework for Java persistence. Although object-relational mapping is a major component of the API, it also offers solutions to the architectural challenges of integrating persistence into scalable enterprise applications.


    Overview: JPA = Simple + elegant + powerful + flexible

    Natural to use and easy to learn.


    POJO: It means there is nothing special about any object that is made persistent. Java Persistence API is entirely metadata driven and it can be done by adding annotations to the code or using externally defined XML.


    Non-Intrusiveness: The persistence API exists as a separate layer from persistence objects. The application must be aware of the persistence API, the persistence objects themselves need not be aware.


    Object Queries: Query Language that derived from EJB QL and modeled after SQL for its familiarity, but it is not tied to the database schema. Queries use a schema abstraction that is based on the state of an entity as opposed to the columns in which the entity is stored. It returns results that are in the form of entities that enable querying across the Java domain model instead of across database tables.


    Mobile Entities:


    Simple Configuration:


    Integration and Testability:


    Chapter 2


    Entity Overview: The entity is not a new thing. In fact, entities have been around longer than many programming languages and certainly longer than Java. Peter Chen who first introduced entity-relational modeling (1976) described entities as things that have attributes and relationships.


    Here is an example of an Entity class from a regular Java Class:


     

    package examples.model;

    import javax.persistence.Entity;
    import javax.persistence.Id;

    @Entity
    public class Employee {
    @Id
    private int id;
    private String name;
    private long salary;

    public Employee() {}
    public Employee(int id) {
    this.id = id;
    }

    public int getId() {
    return id;
    }

    public void setId(int id) {
    this.id = id;
    }

    public String getName() {
    return name;
    }

    public void setName(String name) {
    this.name = name;
    }

    public long getSalary() {
    return salary;
    }

    public void setSalary(long salary) {
    this.salary = salary;
    }

    public String toString() {
    return "Employee id: " + getId() + " name: " + getName() + " salary: " + getSalary();
    }
    }

    To turn Employee into an entity we first needed to annotate the class with @Entity. This is primarily just a marker annotation to indicate to the persistence engine that the class is an entity. The second annotation was needed to use as the unique identifying key in the table. All entities of type Employee will get stored in a table called EMPLOYEE.


    Entity Manager: Until an entity manager is used to actually create, read or write an entity, the entity is nothing more than a regular (non-persistent) Java object. An entity manager is the show for the game. The set of managed entity instances within an entity instances withing an entity manager at any given time is called it’s persistence context. Only one Java instance with the same persistent identity may exist in a persistence context any any time. For example, if an Employee with a persistent identity (or id) of 158 exists in the persistence context, then no other object with its id set to 158 may exist within that same persistence context. All entity managers come from factories of type EntityManagerFactory. For Java SE application should use EntityTransaction instead of Entity Manager.


    Obtaining an Entity Manger: The static createEntityMangerFactory() method creates EntityManagerFactory from persistence unit name “EmployeeServices”:


     

    EntityManagerFactory emf = Persistence.createEntityManagerFactory("EmployeeService");

    Now we have a factory, we can obtain an entity manager from it:


     
    EntityManager em = emf.createEntityManager();

    Persisting an Entity: Insert. It creates a new employee and persist it to the database table


     

    public Employee createEmployee(int id, String name, long salary) {
    Employee emp = new Employee(id);
    emp.setName(name);
    emp.setSalary(salary);
    em.persist(emp);
    return emp;
    }

    Finding an Entity: Read


     
    public Employee findEmployee(int id) {
    return em.find(Employee.class, id);
    }

    In this case where no employee exists for the id that is passed in, when the method will return null, since that is what find() will return.


    Removing and Entity: Delete


     
    public void removeEmployee(int id) {
    Employee emp = findEmployee(id);
    if (emp != null) {
    em.remove(emp);
    }
    }

    Updating an Entity: Update


     
    public Employee raiseEmployeeSalary(int id, long raise) {
    Employee emp = em.find(Employee.class, id);
    if (emp != null) {
    emp.setSalary(emp.getSalary() + raise);
    }
    return emp;
    }

    Queries: Instead of using Structured Query Language (SQL) to specify the query criteria, in persistence world, we query over entities and using a language called Java Persistence Query Language (JPQL).

    A query is implemented in code as a Query object and it constructed using EntityManger as a factory.

    As a first class object, this query can in turn be customized according to the needs of the application.

    A query can be defined either statically or dynamically (more expensive to execute). Also there is kind of query called named query as well.


     
    public Collection<Employee> findAllEmployees() {
    Query query = em.createQuery("SELECT e FROM Employee e");
    return ( Collection <Employee> ) query.getResultList();
    }

    To execute the query, simply invoke getResultList() on it and this returns a List. Note that a List <Employee> is not returned b/c no class is passed into the call, so no parameterization of the type is able to occur. The return type is indirect by the persistence provider as it processes the JPQL String. By doing this ( Collection<Employee> ) to make a neater return type.


    Chapter 3


    EJB definitions:


    Chapter 4


    Object-Relational Mapping


    Lazy Fetching: The data to be fetched only when or if it is required is called lazy loading, deferred loading, lazy fetching, on-demand fetching, jun-in-time reading, indirection. Data may not be loaded when the object is initially read from the database but will be fetched only when it is referenced or accessed. The FetchType could be LAZY or EAGER. Lazy = until it is referenced. The default is to eagerly load all basic mappings.


     

    package examples.model;

    import static javax.persistence.FetchType.LAZY;

    import javax.persistence.Basic;
    import javax.persistence.Column;
    import javax.persistence.Entity;
    import javax.persistence.Id;
    import javax.persistence.Lob;

    @Entity
    public class Employee {
    @Id
    private int id;
    private String name;
    private long salary;

    @Basic(fetch=LAZY)
    @Lob @Column( name = "PIC" )
    private byte[] picture;

    public int getId() {
    return id;
    }

    public void setId(int id) {
    this.id = id;
    ......

    @Basic annotation is required. The comments field to be fetched lazily will allow an Employee instance returned from a query to have the comment field empty. It will be transparently read and filled in by the provider (Toplink/Hibernate) once the comments filed get accessed.


    Two things to be aware of.

    First and foremost: The directive to lazily fetch an attribute is meant only to be a hint to the persistence provider to help the application achieve better performance. The provider is not required to respect the request, since the behavior of the entity is not compromised if the provider goes ahead and loads the attribute.


    Second: It may appear that this is a good idea for certain attributes but it is almost never a good idea to lazily fetch for simple types. The only time when lazy loading of a basic mapping should be considered are when either there are many columns in a table (for example, dozens or hundreds) or when the columns are large (for example, very large character strings or byte strings).


    Large Object:


    Using jQuery with Other Libraries

    The jQuery library, and virtually all of its plugins are constrained within the jQuery namespace. As a general rule, "global" objects are stored inside the jQuery namespace as well, so you shouldn't get a clash between jQuery and any other library (like Prototype, MooTools, or YUI).

    That said, there is one caveat: By default, jQuery uses "$" as a shortcut for "jQuery".

    However, you can override that default by calling jQuery.noConflict() at any point after jQuery and the other library have both loaded.

    When you use jQuery with other libraries, jQuery still is functional.
    You can use jQuery directly

      // Use jQuery via jQuery(...)
      jQuery(document).ready(function(){
        jQuery("div").hide();
      });


    or reassign jQuery to another shortcut

      var $j = jQuery;
      // Use jQuery via $j(...)
      $j(document).ready(function(){
        $j("div").hide();
      });


    For more detail, please see http://docs.jquery.com/Using_jQuery_with_Other_Libraries.

    Thursday, December 10, 2009

    Why use Map.entrySet() instead of Map.keySet()?

    (From http://www.coderanch.com/t/382487/Java-General/java/Why-use-Map-entrySet)

    If you just need keys, use keySet(). If you just need values, use values(). If you're going to use keys and values in your subsequent code, then you're best off using entrySet().

    I frequently see people do this without entrySet(), and it usually looks something like this:

    for (Iterator it = map.keySet().iterator(); it.hasNext(); ) {
    Foo key = (Foo) it.next();
    Bar value = (Bar) map.get(key);
    // now do something with key and value
    }

    This works, but it's making the JVM do extra work for no good reason. Every time you call get() you're making the JVM spend time doing a hashcode lookup, or navigating a tree and evaluating a comparator. These operations may be fast, or not, but why do them if you don't have to? A Map.Entry gives you both key and value, together, in the most efficient manner possible.

    for (Iterator it = map.entrySet().iterator(); it.hasNext(); ) {
    Map.Entry e = (Map.Entry) it.next();
    Foo key = (Foo) e.getKey();
    Bar value = (Bar) e.getValue();
    // now do something with key and value
    }


    Under JDK 5 and later it's a little nicer:

    for (Map.Entry e : map.entrySet()) {
    Foo key = e.getKey();
    Bar value = e.getValue();
    // now do something with key and value
    }

    Thursday, December 03, 2009

    Import a certificate to keystore.

    Import a certificate into default key store 'cacerts'.

    keytool -import -trustcacerts -keystore cacerts -alias drssomp0117 -file drss117.2048.crt

    Wednesday, December 02, 2009

    Java JDK 1.4 JCE Provider issue.

    Bundled JCE provider in jdk1.4 can't cope with keys bigger than 2048. If you are working on a websrvice, which needs using https to access, you maybe will be in trouble as commocial certificates most need 4096. In Java 1.5 and higher, it is OK as longer key was supported as default. How to sovle this issue? You have to find an alternative JCE provider that supports key size 4096.

    Provider resources:
    http://www.bouncycastle.org/java.html
    http://www.cryptix.org/