WLS 1033 Class Caching for Faster Startup in Development Mode

Another incremental development feature that was added to WLS 10.3.3 is a Class Caching option, designed to reduce startup time of a development server.

See the documentation for more details:

http://download.oracle.com/docs/cd/E14571_01/web.1111/e13706/classloading.htm#WLPRG493

Configuring Class Caching

WebLogic Server now allows you to enable class caching for faster start ups. Once you enable caching, the server records all the classes loaded until a specific criterion is reached and persists the class definitions in an invisible file. When the server restarts, the cache is checked for validity with the existing code sources and the server uses the cache file to bulk load the same sequence of classes recorded in the previous run. If any change is made to the system classpath or its contents, the cache will be invalidated and re-built on server restart.
The advantages of using class caching are:

• Reduces server startup time.
  
• The package level index reduces search time for all classes and resources.
  

The cache uses optimization techniques to minimize the initial cache recording time. Cache recording continues until a specific class has been recorded.

Moving up to Mac

It would be somewhat remiss of me to not mention that I've recently become a convert to the world of Mac, purchasing myself a 15" MacBook Pro. 

I was a little hesitant about moving over to it, but I have to say, it's been fairly painless so far (thanks to VMware Fusion for the few remaining Windows apps I have no control over) and the rewards of using Mac OS X instead of Windows XP are plentiful. 

As I sit here writing this, with a Terminal window open with WLS running happily in the background, I just noticed that Time Machine has kicked in and started an incremental backup. 

And don't even get me started on the wonders of using Trackpad, Expose and Spaces ... my only question is why did I wait so long?!

More on the WLS Zip Distribution

My colleague Prash has recently added a post to the official WebLogicServer blog discussing the new WLS zip file distribution.

http://blogs.oracle.com/WebLogicServer/2010/05/the_new_wls_zip_distribution_w.html

He has helpfully included the contents of the readme.txt that ships within the zip file, just click on the link towards the bottom of the page to see it.

Moving WLS 1033 Developer Zip Location

I just ran into a usage issue with the WLS 10.3.3 Developer Zip file distribution that I thought I'd share.

What I did was to move the unzipped WLS Developer Zip from one directory location to another.

>mv /Users/sbutton/Java/wls-1033-dev /Users/Shared/Java

Upon doing that, I found I could no longer create new domains when the server was started, despite it working previously.

<May 20, 2010 12:18:13 PM CST> <Info> <Management> <BEA-141254> <Generating new domain directory in /Users/sbutton/Domains/dev>
<May 20, 2010 12:18:14 PM CST> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason:

There are 1 nested errors:

weblogic.management.ManagementException: Failure during domain creation
    at weblogic.management.internal.DomainDirectoryService.generateDomain(DomainDirectoryService.java:235)
    at weblogic.management.internal.DomainDirectoryService.ensureDomainExists(DomainDirectoryService.java:153)
    at weblogic.management.internal.DomainDirectoryService.start(DomainDirectoryService.java:73)
    at weblogic.t3.srvr.ServerServicesManager.startService(ServerServicesManager.java:461)
    at weblogic.t3.srvr.ServerServicesManager.startInStandbyState(ServerServicesManager.java:166)
    at weblogic.t3.srvr.T3Srvr.initializeStandby(T3Srvr.java:802)
    at weblogic.t3.srvr.T3Srvr.startup(T3Srvr.java:489)
    at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:446)
    at weblogic.Server.main(Server.java:67)
Caused by: com.oracle.cie.domain.DomainConfigException: Unable to locate default template
    at com.oracle.cie.domain.DomainInfoHelper.createDefaultDomain(DomainInfoHelper.java:1759)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at weblogic.management.internal.DomainDirectoryService.generateDomain(DomainDirectoryService.java:230)
    ... 8 more

>
<May 20, 2010 12:18:14 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FAILED>
<May 20, 2010 12:18:14 PM CST> <Error> <WebLogicServer> <BEA-000383> <A critical service failed. The server will shut itself down>
<May 20, 2010 12:18:14 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to FORCE_SHUTTING_DOWN> 

After some head scratching, I finally realized it was probably to do with the security settings that are applied by the "configure.sh" script that needs to be executed when the zip file is first extracted.

After re-running configure.sh from the new directory location, the domain was then able to be created as normal.

So if you do move the directory holding the extracted WLS 10.3.3 Developer Zip distribution around, remember to run the configure.sh script again.

Changing Default JPA Provider in WebLogic Server 10.3.3

WebLogic Server has been providing both OpenJPA/Kodo and EclipseLink as JPA providers since WLS 10.3.1.

Unless an explicit <provider>...</provider> is specifed in the persistence.xml file of a deployed application, WLS will use OpenJPA/Kodo by default.

With the release of WLS 10.3.3, we have now provided a way to change the default JPA provider at the domain level, allowing you to switch between OpenJPA/Kodo or EclipseLink as the default that WLS will use.

The default JPA provider setting is exposed via a new MBean: JPAMBean on the DomainMBean, and persists the configuration into the config.xml file.

To easiest way to change the default JPA provider it to use the console and select the desired provider value.

JSF 2.0 Support in WebLogic Server 10.3.3

With the release of WebLogic Server 10.3.3 (now available on OTN) we have added support for JSF 2.0 by providing a JSF 2.0 shared-library that can be deployed and used with WebLogic Server.

The new JSF 2.0 shared-library is located here in a WLS 10.3.3 installation:

>$WL_HOME/common/deployable-libraries/jsf-2.0.war.

The shared-library name and spec/implementation version details are listed in the documentation here:

http://download.oracle.com/docs/cd/E14571_01/web.1111/e13712/configurejsfandjtsl.htm#sthref43

The JSF 2.0 shared-library follows the same model as the previous JSF libraries shipped with WLS, where it needs to be deployed and referenced using a &gt;library-ref&lt; in a WLS deployment descriptor by applications that wish to use it.

The JSF 2.0 library supports Dependency Iinjection of Java EE resources and the use of the Java EE 5 lifecycle annotations in Managed Beans as described in the specification.  This is done through the inclusion of a WLS specific class that implements the com.sun.faces.spi.InjectionProvider interface provided in the WEB-INF/lib/wls.jsf.di.jar library within the jsf-2.0.war shared-library.

We also continue to provide support for earlier JSF 1.2 releases.