A search of the classloader for potential JAXB classes is performed every time a web services application is invoked. If the search process for your application is lengthy, there are ways to reduce the amount of time the system spends creating the JAXBContext for your application.
Here is an example trace that indicates this situation12/2/11 6:24:40:548 PST] 0000003e JAXBUtils 1 org.apache.axis2.jaxws.message.databinding.JAXBUtils createJAXBContextValue Package com.company.queryall.v1 does not have any JAXB classes. It is removed from the JAXB context path.
For each occurrence of this message, you should include an empty jaxb.index file in the package to indicate there are no JAXB classes. If this action is not taken, the time consuming JAXB class search occurs.
Completing the following actions might reduce the amount of time required to create the JAXBContext
If any of the packages for a JAXBContext do not contain an ObjectFactory or jaxb.index file, a search of the classloader for potential JAXB classes for each package is performed. This search can be very time consuming when a large classloader is involved. You can use to the com.ibm.ws.websvcs.getJAXBContext.cacheClassList.persist JVM custom property to permanently cache the search results for each package searched. Later JAXBContext requests use the cached list of classes instead of performing a new search of those packages.
The cache is removed when an application is updated or uninstalled. While this approach might not improve performance as much as providing a list of packages, it does not require any changes to the application.
This action is recommended as a first step even if you intend to use jaxb.index files.
The list of packages that contain JAXB classes can be used when every package contains either an ObjectFactory class, or a jaxb.index file that specifies the JAXB classes for the package. When you provide the list of JAXB classes in the ObjectFactory class or a jaxb.index file, no search for JAXB classes is required.
Using a list of packages provides the greater performance improvement might require you to manually create jaxb.index files and changes to the application. If you decide to use this approach, you can review the debug trace logs for does not contain an ObjectFactory messages to determine how many packages need to be updated.
A jaxb.index file can be used if you want the optimum performance and are willing to make changes to the application. The ObjectFactory class is normally created only with the top-down tooling (wsimport). Therefore, any packages developed with bottom-up tooling (wsgen) probably do not contain an ObjectFactory class. The jaxb.index file is used to identify the JAXB classes within the package and lessen the amount of time it takes for context creation. The JAXBContext.newInstance() method accepts jaxb.index files in the same way that it accepts the ObjectFactory class.
If a required JAXB class file is missed and not included in the package jaxb.index file, an error will occur indicating the class is not known to the JAXBContext and the class should be added to the jaxb.index file.
Every package used in a JAXBContext must have either an ObjectFactory class or a jaxb.index file to prevent the JAXB class search. This means that the trace files must be examined, and each instance of the missing ObjectFactory class or a jaxb.index file must be addressed. If any package for the JAXBContext is identified as not containing an ObjectFactory class or a jaxb.index file, the time consuming JAXB class search is performed. The format of the jaxb.index file is documented in the Oracle Javadoc for JAXBContext.newInstance() at http://docs.oracle.com/javaee/5/api/javax/xml/bind/JAXBContext.html.
There are not any options to change or improve the actual JAXBContext instance creation. The time spent to instantiate the context is affected by many factors, such as the number of JAXB classes, the number of packages, and the size of the class path. The JAXBContext created is held in a soft reference cache in memory. As a result, garbage collection might discard a JAXBContext if available memory becomes low. The next request that requires the discarded JAXBContext must then recreate the JAXBContext. While this recreation process is not significant for most JAXBContext, there are exceptions where the newInstance() step itself takes a significant amount of time.
If the JAXBContext for an application has a large newInstance() creation times, consider using the following JVM custom properties to place the JAXBContext in a cache that persists until the JVM or application is restarted.