Oracle WebLogic Development-Only Installer

One of the biggest issues I always had with WebLogic was the installation. Even if the installer iteself was very straight forward and easy, the installation took longer with every new release containing new features. This was already adressed in the past with the possibility to select from some of the most common components. But it still took some time to setup the basic installation.
Starting with WebLogic Server 10.3.3.0 Oracle now provides a Development-Only Installer as a ZIP file. It supports Windows, Linux, and Mac OS X systems. It contains all necessary artifacts for development of applications on WebLogic Server. The following parts are NOT included in the distribution:

• Samples
• Derby database
• WebServer plug-ins
• Native JNI libraries for unsupported platforms
• Sun SDK and Oracle JRockit SDK
• Coherence
• Oracle Enterprise pack for Eclipse

Download and extract
Get the 423 MB ZIP File from the offical OTN download page.
And extract it's contents to a folder of your choice. This will become your "Middleware home directory". Please do not use any existing one. Make shure you place it seperate from any existing fusion middleware (FMW) installations.
You can see, another ZIP file and a simple readme.txt with nothing but a link to the FMW documentation was extracted. Extract this one, too.

Install and configure the JDK
As the installer comes without any JDK, you should have either the Sun jdk 160_18 or the Oracle JRockit 160_17_R28 in place. If not: Install one of them. The following examples I assume that you have a Windows system running.
Next is to setup JAVA_HOME and MW_HOME variables in your command shell. Open one and type:
set JAVA_HOME=C:\jrockit_160_17_R28.0.0-679
set MW_HOME=C:\myfmwhome

Configure your installation
Now you have to run the installation configuration script in the %MW_HOME% directory. You need to do this only only once. Again only if you move the installation to another location/machine.
configure.cmd
Now you have setup your WLS environment in the current shell by typing:
%MW_HOME%\wlserver\server\bin\setWLSEnv.cmd

Create a domain and start it
A domain is automatically created if you create a domain directory with any name you like and simply start your WLS.
mkdir C:\myfmwhome\mydomain
%JAVA_HOME%\bin\java.exe -Xmx1024m -XX:MaxPermSize=128m weblogic.Server
Once the domain is created, you can shutdown WLS and restart it with the scripts provided in the newly created domain.
If you want some additional control, you can also use the GUI based configuration wizzard:
%MW_HOME%/wlserver/common/bin/config.cmd
But you can also do this using WLST or the unpack command. WebLogic Server domain and extension templates are available in the %MW_HOME%/wlserver/common/templates/domains and %MW_HOME%/wlserver/common/templates/applications directories to help you get started with domain creation. For further details refer to the WLS product documentation.

Note: It is recommended that you create the domains outside the %MW_HOME%. This example does not follow this recommendation for simplicity ;)

Applying patches
As the smart update tool is not supported, patching has to be done manually. You have to get the needed patch jars from Oracle Support and apply it manually to the classpath.

Upgrading
In-place upgrade of installation is not supported in the zip distribution. If needed, you have to re-download the zip distribution and extract it again to a new location. Of course you could keep the already generated domains.

Deleting
simply delete the %MW_HOME% directory. Ensure that you don't delete any of your domains. Keeping them in a separate directory makes this easier.


Further readings:
Complete WebLogic Server Documentation

WebLogic Server 10.3.3.0 released. It now has JSF 2.0 support!!

Believe it or not. Here it is. WebLogic Server finaly supports JSF 2.0 with it's latest release 10.3.3.0.
And here is the short howto:

- Download and install one of the latest Oracle WebLogic Server 11g Rel 1 (10.3.3) Installers from OTN. (Give the ZIP Installer a try. Aweseome lightweight!)
- Create a new sample domain (call it whatever you want) and start the admin server
- Open the administration console (http://localhost:7001/console/)
- deploy the JSF 2.0 library (Deployments - Install - wlserver_10.3\common\deployable-libraries\jsf-2.0.war
- Find your favorite JSF 2.0 sample (I'll take the guessNumber thing from the mojarra-2.0.2 distribution)
- Add a weblogic.xml file to the WEB-INF/ folder with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
<library-ref>
<library-name>jsf</library-name>
<specification-version>2.0</specification-version>
<implementation-version>1.0.0.0_2-0-2</implementation-version>
<exact-match>true</exact-match>
</library-ref>
</weblogic-web-app>

- Package the guessNumber app
- Deploy the app to the WebLogic server
- give it a try: http://localhost:7001/guessNumber

As you can see, the new JSF 2.0 features are available :) great work!
And the best of all, this is not even explicitly mentioned in the "what's new documentation for WLS" :) A single line indicates JSF support for 2.0, 1.2, 1.1.

Oracle Introduces Java Virtualization Solution for Oracle WebLogic Suite

As seen in a press anouncement a few days ago, Oracle is revealing parts of the future for it's WebLogic Suite.

It includes two new products:
- Oracle Virtual Assembly Builder and
- Oracle WebLogic Suite Virtualization Option

Oracle Virtual Assembly

The Virtual Assembly Builder is a new product designed to help organizations deploy multi-tier enterprise applications in virtualized environments. It also enables administrators to configure and provision these applications. This is done by using the frameworks capabilities for
(a) automatically capturing the configuration of an existing reference application environment and packaging all its components into a collection of customized software appliances, or
(b) starting with pre-created, general purpose software appliances representing the various components in an application topology.
See the datasheet online (PDF, ~300kb)

Oracle WebLogic Suite Virtualization Option

The Virtualization Option brings together Oracle WebLogic Server with JRockit Virtual Edition. It is optimized for virtualized environments and able to deliver higher application performance and increased hardware utilization. By adding essential system functions to the JRockit JVM, WLS on Oracle JRockit Virtual Edition can now execute directly on the hypervisor, eliminating the need to deploy and administer a guest operating system.
See the datasheet online (PDF, ~300kb)

Getting started with (GSW #3): Grails on Weblogic 11g (WLS 10.3.2.0)

Next in my GSW series is a topic I want to write about since some time. One of my co-workers left the company (never will get it, why ;)) and moved on to a Groovy company. After having heard him talking about the "fancy" part in Groovy I was looking for a way to get this into my favorite Java EE appserver. Found it in Grails.

Grails is a dynamic web application framework built on Java and Groovy, leveraging best of breed APIs from the Java EE sphere including Spring, Hibernate and SiteMesh. Grails brings to Java and Groovy developers the joys of convention-based rapid development while allowing them to leverage their existing knowledge and capitalize on the proven and performant APIs Java developers have been using for years.
(Quote: http://www.grails.org)

Prerequisites
- You should have an Oracle Weblogic Server 11g R1P1 in place. If you don't,
get it from the Oracle Technology Network's download page.
- Grep a copy of the lates Grails 1.3-M1 (download takes some time..)

Installation
Extract the 48MB archive into any folder to your haddrive. You should stay away from spaces or any other weird characters. X:\grails on Windows or ~/grails on Unix is a nice place.
Now you need a suitable environment variable that points to your installation folder. On Windows you do this with
set GRAILS_HOME="X:\grails try export GRAILS_HOME=~/grails
Now check, if you have a JAVA_HOME environment variable defined. If not, do this now. It should point to your JDK installation. You find one inside the Weblogic product installation directory. (e.g. %WLS_HOME%\jdk160_14_R27.6.5-32).
Next is to append a reference to the "bin" directory within the Grails directory to your PATH variable (eg %GRAILS_HOME%\bin on Windows or $GRAILS_HOME/bin on Unix).
Open a command window on windows or simply type "grails" in your shell. You should see a help message.

Create an empty Grails project
Once you have installed Grails and veryfied that everything is running you can start using it. First step is to
create a new project. Use the built-in target for creating one. Change to the command line and enter:
grails create-app
Some magic happens to the std_out. Watch out for the script to prompt you for the name of your application. I used "wlssample" here. After the script executed completely you find a new directory in the filesystem which is named after the application name you entered. Explore the directory structure. If you are used to Java EE webapplications you probably will not find anything surprising here.

Create a Domain Class
Having an empty app does not make sense. Let's add a persistent object, a Domain Class to it.
Make shure you cd'ed to the root directory of your new project.
grails create-domain-class
The script asks for a Domain Class name. Enter one. Responding to the command with "book" will create a file
called Book.groovy in %appname%/grails-app/domain. You can edit it with your favorite text editor or IDE.
Modify it to look like this:
class Book {
String title
String author
}

Create a Controller
Ok. An app, a Domain Object. We are still missing the UI. All this starts with a Controller. Grails Controllers are central to Grails applications. They handle web requests and URLs of the request map to a controller class and a closure within the class.
Another target assists you with this. Run the
grails create-controller
target and type in the name of the controller. In this example I use the name "Book" again, which generates a controller called BookController.groovy in the directory %appname%/grails-app/controllers.
To make this example as simple as possible we use a feature called dynamic Scaffolding. It allows you to auto-generate a whole application for a given domain class. In your case for the Domain Class Book. Open the controller and change it to look like this:
class BookController {
def scaffold = Book
}


Fire it up with Tomcat
To see, if you did everything the right way you can fire up the included tomcat and take a first look at your application. Type:
grails run-app
and point your browser to
http://localhost:8080/wlssample/
You should see something like in the following screenshot. Congratulations! You have your fist Grails App up and running.

Package a WAR File
But we want to run this on our Weblogic. To get this up an running we need to create a web application archive (WAR) file from the project. There is a simple script out there to package it. Type:
grails prod war
This will place a %appname%-0.1.war file in the %appname%/target directory. Now browse to your weblogic console application (typically found here http://localhost:7001/console/), login and click left on "Deployments". Click the "install" button and browse to the target folder. Select the %appname%-0.1.war file and click "Next". Choose "Install this deployment as an application" and click "Next". Don't change anything on the next screen. Simply klick "Finish".
If everything went perfect, you will see two simple confirmation messages stating that the deployment has been successfully installed. Now point your browser to:
http://localhost:7001/wlssample-0.1/
There you are! Congratulations. You have your sample Grails app up and running in Weblogic Server!

Further Links and Readings
Grails Documentation
IDE Integration
More Plugins

JVM 1.5 GC Tuning and WebLogic Server - Part II garbage collection algorithms

You now know a bit more about the heap sizes (part I). Next is to dive into the actuall garbage collection algorithms.

Choosing the garbage collection algorithm
The Java HotSpot JM (up to version 5) includes four garbage collectors. All the collectors are generational. Memory in the Java HotSpot virtual machine is organized into three generations: a young generation, an old generation, and a permanent generation. When the young generation fills up, a young generation collection (sometimes referred to as a minor collection) of just that generation is performed. When the old or permanent generation fills up, what is known as a full collection (sometimes referred to as a major collection) is typically done.
Commonly, the young generation is collected first, because it is usually the most efficient way to remove garbage from the young generation. Then what is referred to as the old generation collection algorithm for a given collector is run on both the old and permanent generations.

Serial Collector
With the serial collector, both young and old collections are done serially (using a single CPU), in a stop-the-world fashion. That is, application execution is halted while collection is taking place.

In the J2SE 5.0 release, the serial collector is automatically chosen as the default garbage collector on machines that are not server-class machines. The VM does an autodetection on this depending on the processors and the physical memory. Or your could even explicitly define a server or client VM by using the
-server or
-client
The serial collector can be explicitly requested by using the
-XX:+UseSerialGC
command line option.
As you can guess, this is NOT the right collector for high volume server side applications running on 64-bit linux with lot of heap. If you compare this behaviour to the problem that was described in the first part, I bet you now know about the cause for it. But looking at the Weblogic startup script makes it clear. This is not the garbage collection algorithm that is used. So, let's go on.

Parallel/Throughput Collector
But what to do with bigger applications? It is simple: try the
parallel collector. It is also known as the throughput collector and was developed in order to take advantage of available CPUs rather than leaving most of them idle while only one does garbage collection work.
The parallel collector uses a parallel version of the young generation collection algorithm utilized by the serial collector. It is still a stop-the-world collector, but performing the young collection in parallel with many CPUs. The old generation garbage collection is still done using the same collection algorithm as the serial collector. And the behaviour is still the same. If you have bigger heaps this is probably also not the right collector for you. Applications that can benefit from the parallel collector are those that do not have pause time constraints, since infrequent, but potentially long, old generation collections will occur.

The parallel collector is automatically chosen as the default garbage collector on
-server class maschines. It can be explicitly requested with the following option: -XX:+UseParallelGC

Parallel Compacting Collector
The parallel compacting collector was introduced in J2SE 5.0 update 6. It enhances the parallel collector with a new algorithm for old generation garbage collection.
With the parallel compacting collector, the old and permanent generations are collected in a stop-theworld, but mostly parallel fashion with sliding compaction.
As with the parallel collector, the parallel compacting collector is beneficial for applications that are run on machines with more CPUs. In addition, the parallel operation of old generation collections makes it more suitable for applications that have pause time constraints. You can even change the number of threads used for garbage collection via the following option:
–XX:ParallelGCThreads=n
If you want to use this collector, you have to specify the following option:
-XX:+UseParallelOldGC

Concurrent Mark-Sweep (CMS)/low-latency Collector
For many applications, end-to-end throughput is not as important as fast response time. Young generation collections do not typically cause long pauses. However, old generation collections, though infrequent, can impose long pauses, especially when large heaps are involved. To address this issue, the HotSpot JVM includes a collector called the concurrent mark-sweep (CMS) collector.
The CMS collector collects the young generation in the same manner as the parallel collector. Most of the collection of the old generation using the CMS collector is done concurrently with the execution of the application. The CMS collector is the only collector that is non-compacting. That is, after it frees the space that was occupied by dead objects, it does not move the live objects to one end of the old generation. Another disadvantage the CMS collector has is a requirement for larger heap sizes than the other collectors. Unlike the other collectors, the CMS collector does not start an old generation collection when the old generation becomes full. Instead, it attempts to start a collection early enough so that it can complete before that happens. Otherwise, the CMS collector reverts to the more time-consuming stop-the-world algorithm used by the parallel and serial collectors. To avoid this, the CMS collector starts at a time based on statistics regarding previous collection times and how quickly the old generation becomes occupied. It will also start a collection if the occupancy of the old generation exceeds something called the initiating occupancy. The value of the initiating occupancy is set by the option
–XX:CMSInitiatingOccupancyFraction=n
n is the percentage of the old generation size. Defaulting to 68.

Compared to the parallel collector, the CMS collector decreases old generation pauses at the expense of longer young generation pauses, some reduction in throughput, and extra heap size requirements. Use the CMS collector if your application needs shorter garbage collection pauses and can afford to share processor resources with the garbage collector when the application is running. Applications with a relatively large set of long-lived data running on multi CPU maschines tend to benefit from the CMS collector.

If you want the CMS collector to be used, you must explicitly select it by specifying the option
-XX:+UseConcMarkSweepGC
An incremental mode can be enabled via
–XX:+CMSIncrementalMode

Further options
Now you basically know everything about the four garbage collection algorithms. To be honest, there are plenty of additional options and tuning methods implemented in the JVM. You can for example tune the behaviour of the parallel collectors to fit definied goals (pause time, throughput or footprint) or you can even enable special tuning parameters for defined operating systems. A complete list of Java VM options is available online.
From now on, you are going to explore your system from a runtime view. There is one basic principle that should guide you:
"Premature optimization is the root of all evil." (Donald Knuth)
There is only one cause for switching or tuning the JVM GC in general. You are running into problems. In common cases this is a "java.lang.OutOfMemoryError" exception. But also very long gc pause times in a stop-the-world fashion could force you to get your hands on it.

More tools
I allready pointed you to some diagnostic and monitoring tools in the first part. But there are more available. If you are on unix/linux based systems, you can take advantage of jmap and jstat. Both provide in depth details about your running JVMs and can assist you in digging deeper into the problem. HPROF and HAT can also assist you.

If you look around for further documents and best practices, you will notice a lot of stuff out there. The best place to start are the following two documents. Choose the one, fitting your JVM version:
- Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine
- Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning

JVM 1.5 GC Tuning and WebLogic Server - Part I Heap

The Java SE is used for a wide variety of applications. Beginning with small applets on desktops to web services or Java EE applications on large servers. In support of this diverse range of deployments, the HotSpot virtual machine implementation provides multiple garbage collectors, each designed to satisfy different requirements. However, users, developers and administrators that need high performance are burdened with the extra step of selecting the garbage collector that best meets their needs. Because the standard is not always the best choice. This is all about tuning and configuring the JVM to fit your needs. What to do and where to look. If you read on, I assume that you have a basic understanding of the memory management in the jvm. If not, you can read more about it in the Memory Management in the Java HotSpot Virtual Machine whitepaper (PDF).
Because this is a slightly complex area, I sliced this article into two parts. This is part one. All about sizing the heap.

All the above is especially true for Java 1.5 (they are still out there ;)) and for very large systems with a lot of hits/second. We recently came across a nice system. 16 cores, 32 GB of RAM. All running on a 64-bit Linux. It should have been a sufficient box for our small WebLogic Server (10.0) running on top of it. But starting with a lot of heap and the default -server jvm in place showed some very nasty effects. Everything went smooth up to a certain point, where the JVM started with full garbage collection. The single run took up to 69.6645960 secs. Wow. Disappointing. What happend? What next?

First step is to understand what happens. Find out everything you need. Have a look at my previous post about Application Server unresponsive or stuck? Take a deeper look!. Gather every information necessary. If nothing leads you into the opposite direction, have a deeper look at the JVM.
There are some tools out there. Let's start with the JConsole. You enable it by adding the following parameters to your JVM:


-Dcom.sun.management.jmxremote.port=50050 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false


Now you can have a more detailed look at what's happening.

If you are looking at the above example, you can see the system doing a stop-the-world garbage collection ("Full Garbage Collection"). In this case, it freed about 3GB heap and took nearly 30 seconds. If you do not have any "fancy" tools at hand, you probably need this small java option:

-verbose:gc

It prints every action of the garbage collector out to the console. This should be enough for analysis, even if you do not have such a nice graphic.

[GC 325407K->83000K(776768K), 0.2300771 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]


In this example, you see two minor collections and one major one. The numbers before and after the arrow indicate the combined size of live objects before and after garbage collection. The number in parenthesis is the total available space, not counting the space in the permanent generation, which is the total heap minus one of the survivor spaces. The minor collection took about a quarter of a second.
You need more information

-XX:+PrintGCDetails

The flag prints additional information about the collections. An example of the output for the J2SE Platform version 1.5 using the serial garbage collector:

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]]

At each garbage collection the virtual machine chooses a threshold number of times an object can be copied before it is tenured. This threshold is chosen to keep the survivors half full. It is helpful to show this threshold and the ages of objects in the new generation. Enable it using the following option:

-XX:+PrintTenuringDistribution

The output looks like this:

Desired survivor size 1015808 bytes, new threshold 1 (max 15)
- age 1: 2031616 bytes, 2031616 total


What next? Can someone have done any mistake in here? If you are concerned that your application might have hidden calls to System.gc() buried in libraries, you should invoke the JVM with the

-XX:+DisableExplicitGC

option to prevent calls to System.gc() and triggering a garbage collection. If this does not change a bit, move on.

All you have to do now is to change the generation sizes and choose the correct garbage collection algorithm. Of course, you could also think about moving to a different JVM first. Beside Hotspot you also can look at JRockit. In my case, I will stick to Hotspot.

Choosing the Heap Size
The JVM heap size determines how often and how long the VM spends collecting garbage. An acceptable rate for garbage collection is application-specific. If you set a large heap size, full garbage collection is slower, but it occurs less frequently. If you set your heap size in accordance with your memory needs, full garbage collection is faster, but occurs more frequently. The goal of tuning your heap size is to minimize the time that your JVM spends doing garbage collection while maximizing the number of clients that your application can handle at a given time.
As a rule of thumb, you should have 4GB per WebLogic instance running on a 64-bin OS. You set this with the following options. Set them to a multiple of 1024 that is greater than 1MB. Setting min and max values to the same saves some time for extending the heap during runtime.

-Xms 4096
-Xmx 4096


You should adjust the size of the young generation to be one-fourth the size of the maximum heap size. Again this is a multiple of 1024 that is greater than 1MB.
Increasing the young generation becomes counterproductive at half the total heap or less (whenever the young generation guarantee cannot be met).

-XX:NewSize 1024
-XX:MaxNewSize 1024

The New generation area is divided into three sub-areas: Eden, and two survivor spaces that are equal in size. Configure the ratio of the Eden/survivor space size with the following option.

-XX:SurvivorRatio=8


Part II will cover the garbage collection algorithms which best fit your needs. Stay tuned.

Eclipselink 1.2.0 JPA, Spring 2.5.6, MySQL 5.4, JTA and Oracle WebLogic 10.3.2.0

I came across a nice post from viralpatel.net. They are showing how to implement a simple url-shortener called "shorty". Really nice. But the technology decision was not that awesome. I am ok with Hibernate. But Struts? No. Thanks :) That reminds me of good old times. And they are gone.

Let's modernize the software stack a bit. We give it a try with the help of:
- Oracle WebLogic 10.3.2.0
- EclipseLink 1.2.0 (1.2.0.v20091016-r5565)
- Spring 2.5.6
- MySQL 5.4
- Maven
- Eclipse

First approach was to migrate shorty completely to the new platform. After playing around a bit, I discovered some things to take care of running it on wls. Therefore I'll stick to the basic JTA/JPA/WLS parts and I am not going to re-implement the complete webtier. I am not using Spring 3.x here, because it still does not exist on ibiblio.org :)

Create your project with maven
First step is to have a simple project setup. Maven is the best place to start. Create a new maven project:

mvn archetype:create \
-DgroupId=my.example.com \
-DartifactId=shortywls \
-DarchetypeArtifactId=maven-archetype-webapp

Next is to update the dependencies. We basically need some Java EE 5 jars, spring and some web components. An explicit EclipseLink dependency is not needed, cause we are going to stick to the JPA 1.0. Using Wls 10.3.2.0 makes this your default JPA provider! Add the following lines to your pom.xml

<dependencies>
<dependency>
<groupId>javaee</groupId>
<artifactId>javaee-api</artifactId>
<version>5</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>2.5.6</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.1.2</version>
</dependency>
<dependency>
<groupId>taglibs</groupId>
<artifactId>standard</artifactId>
<version>1.1.2</version>
</dependency>
</dependencies>

We are missing a place where to put our java files. Change to your newly created project directory and add a src\main\java folder to it. Now you are ready to go. This is the point, where it is best to start developing in your favorite IDE. If you are using eclipse, let maven do the preparation.

maven eclipse:eclipse

After that, you only have to import the newly created project into Eclipse.

Setup your Weblogic domain
Before we actually start implementing, we have to configure our infrastructure a bit. First is to create your weblogic domain. Use whatever you like. I love to take advantage of the Configuration Wizard (win). Find it in the start menue or browse to %WLS_HOME%\wlserver_10.3\common\bin\config.exe If your have entered the basics, create the domain and fire it up. Next is to access the Weblogic Server Administration Console (http://localhost:7001/console). Make shure, you have your MySQL instance up an running and have a database and a user with all needed rights created prior to the next steps. Now browse to -Summary of Services -JDBC -JDBC Data Sources and choose "New".
Enter a Name and JNDI name for your new DataSource and choose MySQL as Database Type and the appropriate Driver. Click "Next" and choose the transaction options. Another "Next" click guids you to the connection properties. Enter your database name, hostname and port together with your username. A last "Next" click adds a "Test Configuration" to the button line on the top. Klick it and make shure, the Message says: "Connection test succeeded." After that, you have to restart your instance. Do this, even if the console tries to make you believe that this is not necessary.



If you are wondering, why we did not add either a dependency to the mysql-jconnector or a jar to the domain/server directory. This is quite simple. The Wls already ships with a mysql-connector-java-commercial-5.0.3-bin.jar. You can find it here %WLS_HOME%\wlserver_10.3\server\ext\jdbc\mysql.

configuring shortywls
Let's start over with JPA configuration. Add a persistence.xml to src\main\resources.
Insert the EclipseLink PersistenceProvider and your jta-data-source reference. If you like to know, what EclipseLink is doing also add the needed logging.level. Don't forget to tell EclipseLink about it's target server. In our case "WebLogic_10".

<persistence-unit name="shortyWeb" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>localJTA</jta-data-source>
<class>shorty.domain.Link</class>
<properties>
<property name="eclipselink.target-server" value="WebLogic_10" />
<property name="eclipselink.logging.level" value="FINEST" />
</properties>
</persistence-unit>

That's all. We are done with JPA :) The next bigger part is to do the basic configuration for spring. First step is to add the needed spring features to the web.xml located in src\main\webapp\WEB-INF. First is the place for your applicationContext.xml followed by the ContextLoaderListener and the Spring DispatcherServlet. Completed by the servlet mapping. Don't forget to add a shortyAppDispatcher-servlet.xml to your src\main\webapp\WEB-INF.

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>shortyAppDispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>shortyAppDispatcher</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>

If this is done, you have to take a closer look at the specific spring configuration. Add the configured applicationContext.xml to src\main\webapp\WEB-INF. That's where all the magic happens. I'll focus on the JPA/JTA parts here. The rest is basic spring configuration, you can find a great documentation on the springsource website.

There are some Weblogic specific tweaks, you have to do. In terms of load-time-weaving you have to use the WebLogicLoadTimeWeaver.

<context:load-time-weaver
weaver-class="org.springframework.instrument.classloading.weblogic.WebLogicLoadTimeWeaver" />

The <tx:jta-transaction-manager /> does a self discovery of the transaction manager of the actuall server. Hence we are running on Wls this forces spring to use the org.springframework.transaction.jta.WebLogicJtaTransactionManager. The <tx:annotation-driven /> let you use the org.springframework.transaction.annotation.*'s

<tx:jta-transaction-manager />
<tx:annotation-driven
transaction-manager="transactionManager" />

If you have the jta transaction manager and the load-time-weaving in place, you need to add the jpaVendorAdapter. No Weblogic specific magic in here. Only the reference to the database platform and some debug information.

<bean id="jpaVendorAdapter"
class="org.springframework.orm.jpa.vendor.EclipseLinkJpaVendorAdapter">
<property name="databasePlatform"
value="org.eclipse.persistence.platform.database.MySQLPlatform" />
<property name="generateDdl" value="true" />
<property name="showSql" value="true" />
</bean>

Last bit to tie all parts together is the EntityManagerFactory. Spring JPA offers three ways of setting up JPA EntityManagerFactory. The only working solution here is the LocalContainerEntityManagerFactoryBean. If you try to use the LocalEntityManagerFactoryBean or the JNDI lookup, you will experience a "Error binding to externally managed transaction" Exception
It has a reference to the jpaVendorAdapter and the persistenceUnitName.

<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="jpaVendorAdapter" ref="jpaVendorAdapter" />
<property name="persistenceUnitName" value="shortyWeb" />
</bean>

Implementing shortywls
Now we are done with configuration :) Switch back to Eclipse and do the implementation work.
You can basically stick to the viralpatel.net. Adapting spring, you need at least a dao which defines the transactional attributes to the methods.
Happy coding!

GlassFish vs. WebLogic - 10 visions for the future

The Sun/Oracle merger raised some questions about the future of different components. One of interest to me is the GlassFish Application Server. Beside the Oracle WebLogic it is the next Java EE Application Server in Oracle's portfolio.
Not really much concrete has been said about the future coexistence of both. But some postings, slides and webcasts are around. Time to summarize them and draw some conclustions. To be honest: Non of the thoughts here are confirmed by anybody. Especially not by Oracle! I don't know if the described things will happen and I don't have any detailed insights in both products timelines or roadmaps. Happy to discuss everything and read about your thoughts.

1) "GlassFish continues as the Java EE reference implementation and as an open source project"
This is a statement, that is totally clear. Nothing will change. It will continue as an Open Source project and you will have a new RI for any of the comming Java EE versions.

2) GlassFish software licensing
Most of the components of the GlassFish plattform are available under a Dual License consisting of the Common Development and Distribution License (CDDL) v1.0 and GNU Public License (GPL) v2. Details for GFv2 kann be found on the GF Wiki. This will stay the same for most of the modules. Except for those, making the way into WebLogic Server. I expect this to be at least the following three: Metro, Jersey, Grizzly

3) Equinox will NOT be the OSGI platform for the Weblogic DM Server
As presented on last years OOW (WebLogic Server Architecture, OSGi and Java Enterprise Edition, Adam Leftik and Jeff Trent), the Equinix Platform has some drawbacks (Lacks a Generic Application Framework, Application Isolation, RFC-133 Context Class Loader). Therefore I expect the Weblogic DM server to use something else. I don't know if this will have any effect on GF. It is possible that the OSGI platform of GF will change, too.

4) There will be NO GlassFish v3 with clustering capabilities
The slide #15 of the Oracle + Sun: Application Server webcast states, that GF will be for productive and agile development. WLS is the availabillity and scalability solution. Therefore the v2 was the last GF with clustering facilities.

5) Metro, Jersey and Grizzly will make it to the WebLogic 11g
As mentioned by Thomas Kurian in the strategy webcast. These are great assets from the GF family and I believe that those three projects will make it to WLS.

6) There will be tool support for migrating GF Apps to WLS
The complete development to production staging process will be adressed by upcomming Oracle solutions. JDeveloper and/or OEPE will have plugins/support for automatic migration of GF apps to WLS. The WLS split deployment directory structure will also be enhanced with staging features. There will probably also be new maven plugins supporting dev and productive builds with GF and WLS.

7) Embedded GlassFish will be bundled with the OEPE
Beeing the development platform of the future, it is obvious that OEPE will bundle an embedded GF in the future.

8) JDeveloper will get support for GF
Beeing the development platform of Oracle could lead to having build in support for GF development in JDeveloper.

9) NetBeans will become the Java ME IDE
Having more and more GF support in JDeveloper and OEPE leads to a further specialization of NetBeans. It will become the Java ME IDE of the Future.

10) There will be a complete ADF implementation for GF
ADF will become available on GF, too.

Need new boxes ;) Oracle, please help ;)

As you might have read: I was switching office rooms today. Somehow, I really do not like moving at all. But one good thing happened. I found some (very) old boxes and put them on my cabinet. Do you remember them? I absolutely need new ones :)
@Oracle: Can you help? :-D

Oracle + Sun: Application Server Strategy

The facts from the software strategy application server webcast (12:55 minutes):

0) Complete.Open.Integrated. set of products
From Hardware, to Database, to Middleware up to Applications.

0.1) Application Grid is the relevant part of Fusion Middleware
It's the plattform that powers the Oracle Applications.
Supports all your application environments.
Contains: Weblogic, Coherence, JRockit, Tuxedo, Enterprise Manager

0.2) Sun portfolio:
GlassFish Enterprise Server, Java System WebServer, GlassFish Web Space Server, GlassFish Web Stack

1) Combined Oracle-Sun Solution Focus (transcript)

• GlassFish continues as the Java EE reference implementation and as an open source project
Oracle's strategic application server Oracle WebLogic Server, together with GlassFish, provide world class Java EE infrastructure
• GlassFish Enterprise Server and WebLogic Server expected to share core components
• Oracle plans to add GlassFish Enterprise Server to all WebLogic offerings
• HotSpot and JRockit become OracleÄs strategic JVMs
• Java System Web Server part of new Oracle Web Tier offering
• GlassFish Web Stack maintained for existing customers
• GlassFish Message Queue remains as the GlassFIsh messaging infrastructure

2) Licensing, Support and Maintenance (transcript)

• Oracle plans to license GlassFish Server and Java System Web Server with all WebLogic Server offerings
• GlassFIsh also available as standalone offering
• GlassFish will continue to be supported and maintained for an extended time period for customers current on support
• GlassFish v2.1 Premier Support up to Jan 2013, Extended support up to Jan 2015)
  
• GlassFish v3.0 Premier Support up to Jan 2014, Extended support up to Jan 2017)
  
• Full details for support will be published next weeks.

3) Engaging with Oracle

• GlassFish open source projects thrive. Ongoing commitment by Oracle to java.net and other open source projects that make-up GlassFish
• Continued collaboration, Blogs (The Aquarium), Enhancements (java.net) and the GlassFish Wiki
• More information: Oracle.com/AppServer
  

JPA 2.0 and Oracle Weblogic 10.3.2.0 (11g)

Everything is about JEE 6 these days. And believe me, I really love the new spec. What I am really missing is the JEE 6 version of a Weblogic server. Anyway, I am still giving parts of the spec some tries on the latest version. Up to now, this was not too successfull. JSF 2.0 is not working. Next was to give JPA 2.0 a try. The guys from the EclipseLink project already did this for me. There is a complete analysis about the possible solutions online in the EclipseLink wiki space. You basically have two differnt options available at the moment to use even parts of the new JPA 2.0.

Change your server/domain install to use new versions of javax.persistence.* and org.eclipse.persistence.* or bundle the related libraries with your application. Both cases have some drawbacks at the moment.

I decided to give it a try anyway and just wanted to give you a more detailed explanation, of what to do to make the second approach work.

First is to get the latest EclipseLink 2.x and the JPA 2.0 API libraries. I was using javax.persistence_2.0.0.v200911041116.jar and eclipselink.jar both taken from the eclipselink-2.0.0.v20091127-r5931.zip download.

Now you have to setup an EAR and a WAR project within your favorite IDE. I am using the Oracle Enterprise Pack for Eclipse (OEPE) for this. Add both jars to the APP-INF/lib folder of your EAR project and change the weblogic-application.xml descriptor by adding the following lines to it:

<wls:prefer-application-packages>
<wls:package-name>org.eclipse.persistence.*</wls:package-name>
<wls:package-name>javax.persistence.*</wls:package-name>
/wls:prefer-application-packages>

Now you have to add a src/META-INF folder to your WAR project. Create a MANIFEST.MF file with the following two lines:

Manifest-Version: 1.0
Class-Path: javax.persistence_2.0.0.v200911041116.jar eclipselink.jar

Place your persistence.xml in the same place. Mine looks like this:

<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="example" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>ds/localJTA</jta-data-source>
<class>...</class>
<properties>
<property name="eclipselink.target-server" value="WebLogic_10"/>
<property name="eclipselink.logging.level" value="FINEST"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables" />
</properties>
</persistence-unit>
</persistence>

This is basically everything. Now you can start to put your Entities and business in your webapplication. But remeber to:
- add every Entity as a <class>...</class> entry to your persistence.xml as dynamic class weaving will not work with this approach.
- Reorder the Java Build Path of your IDE to have the EAR libraries in front of any server libraries. Only this way, you will be able to use the new API features.
- As the schema of the persistence.xml states, you are only able to use JPA 1.0 declarations in it.
- Injecting the EntityManager will not work. You have to get it manually from javax.persistence.Persistence like this:

EntityManagerFactory emf = Persistence.createEntityManagerFactory("example");
EntityManager em = emf.createEntityManager();


After all, this is not a full blown approach to JPA 2.0. But better than nothing. Let's hope for a early preview of EclipseLink 2.0 on Weblogic Server.

Weblogic 11g calling GlassFish v3, Foreign JNDI Provider

And here is the second post about WLS/GF interoperability.
After answering the question How to call an EJB deployed on Weblogic 11g (WLS 10.3.2.0) from GlassFish v3? I now wanted to know, how do it the other way around.

Obvisously it would work the same way, I did on the GF side. Anyway, there is another feature build into Weblogic that makes this more easy for the developer. It is called Foreign JNDI. Foreign JNDI is an API that allows you to access objects on a remote JNDI tree without having to connect directly to the remote tree. It enables you to make links to a JNDI tree on another server or provider including, but not limited to, WebLogic Server, or a JNDI tree in a java program. Once you have configured Foreign JNDI, you can use an object that is somewhere else with the same ease that you would use an object bound in your WebLogic server instance. This is again using RMI-IIOP communication. Ok. Let's start.

You need an EJB to deploy to GF. Of course, this has to be a EJB 3.x. I wrote a quite simple one called GFTest. It has one business method public void sayHelloOnServer() which puts a text to stdout.
And again, you need EJB 2.x style remote interfaces for this.
That should look similar to this:

@Stateless(mappedName="GFTest")
@Remote(GFTestRemote.class)
@RemoteHome(GFTestRemoteHome.class)
public class GFTest implements GFTestRemote

GFTest is the EJB 3.x business interface. GFTestRemoteHome is the EJB 2.x EJBHome which creates the GFTestRemoteObject EJBObject. it is best to put all interfaces into a separate client project.
If everything is ready, deploy the ejb. In my previous post I recommended to run the appc compiler to generate stubs and skeletons. As proven today, this is not realy needed. You only need the interface classes on your client project. Thats totally suffient.

Now let's move over to the Weblogic administration console (http://localhost:7001/console) and configure the foreign JNDI Provider. The steps to take are described in the admin console online help.
First you have to create a foreign JNDI provider. (Summary of Services / Summary of Foreign JNDI Providers / New) and give it a name you like. Now click on the newly created provider and configure it. Settings are as follows:
Initial Context Factory: weblogic.jndi.WLInitialContextFactory
Provider URL: iiop://your_host:your_port (standard case is iiop://localhost:3700)

Next is to create a foreign JNDI object link. Switch from the general to the links tab and click new. Give it a name, you like, it is for administrational proposes only. Then configure the following settings:
Local JNDI Name: The local binding name for the object (in my case GFTest2)
Remote JNDI Name: corbaname:iiop:your_host:your_port#remote_binding_name (in my case corbaname:iiop:localhost:3700#GFTest).

After that, you have to restart the server instance.

Start your favorite IDE for your Weblogic projects and setup a client project. Again, I am one of those webguys and therefore I setup a simple Dynamic Webproject with OEPE. The remote interfaces should be available to the project (client.jar, or classess folder).

The only thing you have to do now, is to get an InitialContext and lookup your EJBHome.

InitialContext context = new InitialContext();
GFTestRemoteHome home =
(GFTestRemoteHome) context
.lookup("GFTest2");

The only thing left to do is to create your GFTestRemoteObject on which to call your business method.

GFTestRemoteObject object = home.create();
object.sayHelloOnServer();

Now you are done!Compared to the manual lookup this is extremely simple and does not force you to take care of the connection handling, urls and jndi names in the code at all.

GlassFish v3 calling Weblogic 11g

I was playing around with interoperability problems lately. The question was: How to call an EJB deployed on Weblogic 11g (WLS 10.3.2.0) from GlassFish v3? What looks simple on the first hand, is not too easy.
Here are the steps to take.

First of all, it is not handy to put any wls libraries into GF's classloader. Therefore you should stick to the most basic communication method available. This is RMI-IIOP. Ok. Let's start.

You need an EJB to deploy to WLS. Of course, this has to be a EJB 3.0. I wrote a quite simple one called Logger. It has one business method void logString(String message) which gets a string and puts it to stdout.
If you are going to use RMI-IIOP, you have to have EJB 2.x style remote interfaces.
That should look similar to this:


@Stateless(mappedName = "Logger")
@Remote(LoggerRemote.class)
@RemoteHome(LoggerRemoteHome.class)
public class Logger implements LoggerRemote


LoggerRemote is the EJB 3.x business interface. LoggerRemoteHome is the EJB 2.x EJBHome which creates the LoggerRemoteObject EJBObject. Put all interfaces into a separate client project (ejb-client-jar).
If everything is ready, deploy the ejb. Now it is time to compile the Stubs and Skeletons for your ejb-client-jar.
Take your jar or ear and put it in weblogic.appc compiler.

java weblogic.appc ejbinteropEAR.ear

This will generate the ejbinteropClient.jar with all needed additional classes. Start your favorite IDE for your GF projects and setup a client project. I badly needed to try some Servlet 3.0 features and wrote a small
@WebServlet(name = "InterobTest", urlPatterns = {"/InterobTest"}) servlet for that.
The ejbinteropClient.jar needs to be in your projects classpath.
First thing to do is, to build an InitialContext.

// Build Properties Object
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
h.put(Context.PROVIDER_URL,
"iiop://localhost:7001");
h.setProperty("org.omg.CORBA.ORBInitialHost",
"localhost");
h.setProperty("org.omg.CORBA.ORBInitialPort",
"7001");
// Get InitialContext with Properties
InitialContext ic = new InitialContext(h);

Now you are half way through. Now lookup your remote object

Object home = ctx.lookup(JNDI_NAME);

This took some time. Ok, not having the java.net forums online since a few days did realy not speed this up.
Anyway, the magic in this is the JNDI_NAME.
It is constructed out of several parts:


String JNDI_NAME =
"corbaname:iiop:localhost:7001#"+
"Logger#ejbinterop.LoggerRemoteHome";


First part is the static part containing your host and port of the target WLS instance. Second is the binding name for your RemoteHome interface in Weblogic Server's JNDI tree.



The only thing left to do is to narrow your RemoteHome from the stubclass


LoggerRemoteHome home =(LoggerRemoteHome)
PortableRemoteObject
.narrow(home,
LoggerRemoteHome.class);


and create your LoggerRemoteObject on which to call your business method on.


LoggerRemoteObject obj= home.create();
obj.logString("Testlog");


Now you are done! A few simple lines of code, which could cause you to get grey hair if you are missing any part.
For me it was quite helpfull, to turn on all related debug settings in WebLogic server. Go to Environment / Servers / Your Server / Debug and enable all needed scopes and attributes. If the call is successfull, you see some detailed debug information on the stdout (don't forget to change the log level!).

WLS 10.3.2.0, JScaLite TechPreview .. examples ... working :)!

I had some quite dissapointing trials running the new JScaLite examples, shipped with the Oracle WebLogic Server 11g R1 Patch Set 1 (WLS 10.3.2.0).
Seems as if my calls were heared at Oracle and they started to write some blogposts about the new Weblogic SCA container tech preview.
Raghav Srinivasan posted "Getting Started with SCA" and this finaly gave me the missing hints about what to do, getting the examples running.

Here is the complete HowTo:

Follow the steps, already described in my previous post
1) Install WLS 10.3.2.0 (with examples)
2) setup environment variables
3) change example.properties
4) deploy the weblogic-sca-1.0.war
5) point the war files to the library (weblogic.xml)

Now, here comes the music:
6) Change the spring-context.xml files
one located in both example war files:
- JSca_GetTotQty_EAR\JSca_GetTotQty_WAR\WEB-INF\classes\META-INF\jsca
- JSca_GetTotPrice_EAR\JSca_GetTotPrice_WAR\WEB-INF\classes\META-INF\jsca

Replace the <beans tag at the beginning with the following:

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca"
xmlns:wlsb="http://xmlns.oracle.com/weblogic/weblogic-sca-binding"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://xmlns.oracle.com/weblogic/weblogic-sca
http://xmlns.oracle.com/weblogic/weblogic-sca/1.0/weblogic-sca.xsd
http://xmlns.oracle.com/weblogic/weblogic-sca-binding
http://xmlns.oracle.com/weblogic/weblogic-sca-binding/1.0/weblogic-sca-binding.xsd">

replace all <binding with <wlsb:binding

7) Now your are ready to build the examples (ant build)
8) and deploy them (ant deploy)

Working behind a corporate proxy leads to a fancy warning:

<Warning> <org.springframework.beans.factory.xml.XmlB
eanDefinitionReader> <BEA-000000> <Ignored XML validation warning
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema documen
t 'http://xmlns.oracle.com/weblogic/weblogic-sca-binding/1.0/weblogic-sca-wlsb:b
inding.xsd', because 1) could not find the document; 2) the document could not b
e read; 3) the root element of the document is not <xsd:schema>.

This is because of the fact, the the WLS does not have access to the needed schema files. Therefore the deployment takes quite some time until the timeouts appear.

Anyhow, if you switch your configuration and use a proxy in your setDomainEnv.bat/.sh JAVA_PROPERTIES
like this: -Dhttp.proxyHost=myproxyserver.com -Dhttp.proxyPort=80

you run into another problem, a SAX Parser exception:

org.xml.sax.SAXParseException: White spaces are required between publicId and systemId

That is not too funny, as the deployment will fail with this. Therefore, you better accept the warnings and get the app deployed :)


9) You can run the examples from the command line (ant run) this opens up your favorite browser and
points it to the URL http://<host&gt;:<port&gt;/ShoppingCartCtx/ShoppingCart

Enterprise Modules Project (Gemini), oracle, springsource and weblogic server

This happened three days ago. SpringSource and Oracle proposed the Enterprise Modules Project (Gemini) to the Eclipse community, whose primary goal is to provide access to standard enterprise technology implementations within a modular framework. The project will include important OSGi EEG implementations (Blueprint Service Implementation and Web Container Integration) contributed by SpringSource as well as contributed code by Oracle. All sub projects will be consumable as modules (or OSGi bundles) and will provide implementations for important and popular enterprise standards.

Up to now, there is no official feedback available in the community forums. Even if the announcement did fire up some press comments (google.com. You can find the SpringSource press release here.

The overall lead for the project is Mike Keith. The project mentors are Wayne Beaton, Doug Clarke and Adrian Colyer.

Gemini is organized under 6 subprojects:
* RFC 66 — Web Container
* RFC 98 — Transactions
* RFC 122 — Database Access
* RFC 124 — Blueprint Services
* RFC 139 — JMX Integration
* RFC 142 — JNDI Integration
* RFC 143 — JPA Integration
* RFC 146 — JCA Connector Integration

As you can see, some important JEE specs are still missing (e.g. EJB & JMS).

Most notably, this project would continue the recently presented invests taken by Oracle in OSGi and a WebLogic DM server. It could lead to a defined standard ways of building and running enterprise technologies (such as Java EE) in OSGi. The EEG has a wide participation: beside Oracle and SpringSource you can find IBM, IONA/Progress, Tibco, ProSyst, Siemens and LinkedIn on the list.

On a midrange timeframe both technologies could grow together. While Java EE defines a suite of application-level APIs, OSGi specifies the infrastructure obligations, needed running them. With the power of OSGi some of the many existing Java EE issues could be solved:
* Application versioning
* Facilitates application module reuse
* Hot upgrades/patches

So OSGi could be the enabler for the next generation of Java server infrastructure.

WLS 10.3.2.0, JScaLite TechPreview .. examples ... broken :(

Released only yesterday and now on my harddrive. The WLS 10.3.2.0 (Oracle WebLogic Server 11g R1 Patch Set 1).
Beside the fact, that the release notes are missing and the documentation is not updated to the latest version, everything looks quite the same.
There was time for me to look at the Technical Preview Parts of the Oracle Weblogic SCA implementation called JScaLite.
As a more or less frequent reader of my blog, you know, that I like to work with the provided samples. They are basically a good start for understanding new features and provide a basic skeletton for your own trials.
Shipped with the WLS 10.3.2.0 you can find a sca example. It is based on a shopping cart application. The following figure (taken from the examples documentation) explains the high level architecture:



This example demos the most important features of JscaLite container. The demoed features include:

•EJB 3.0 Service Bindings
•Web Service Bindings
•EJB 2.0 Reference Bindings
•EJB 3.0 Reference Bindings
•Web Service Reference Bindings
•Default Binding
•JSCA Binding
•Local Reference Resolution (References to services that are part of the same JSca application)
•JSCA application deployment / undeployment

Ok. Let's start over again. First step is to install the package. After you downloaded the 815 MB installer (windows) you are guided through the installation process, as usual. After that, you create your domain and start adjusting the example.properties (%SERVER_HOME%\wlserver_10.3\samples\server\examples\src).
Now you should setup your environment variables (setDomainEnv.cmd is a good start) and start building the examples (ant build).
Up to this, everything works fine. If you try to deploy (ant deploy) you come across some problems:
- the build.xml does not make use of the example.properties => change it
- the deployable library for sca (weblogic-sca-1.0.war) is not deployed => deploy it
- the weblogic.xml dd does not point to the correct library => change it

So far, so good :) Anyhow .. this is where the little journey ends. From now on, I did not manage to fix the remaining issues.

you get a
java.io.FileNotFoundException: class path resource [META-INF/spring-sca.xsd] cannot be opened because it does not exist

if you try to deploy it. Even providing the file within the WEB-INF/classes/META-INF/ this does not solve the problems. A redeployment, ended up with a


org.xml.sax.SAXParseException: cvc-complex-type.2.1: Element 'sca:service' must have no character or element information item [children], because the type's content type is empty.


Played around a bit with different approaches and finally gave up on this. If anybody got this working ... let me know.

Oracle WebLogic Server 11g R1 Patch Set 1 available (WLS 10.3.2.0), contains JScaLite!

The Patch Set 1 release of WebLogic Server 11g Release 1 was release yesterday. Up to know, there is no detailed readme or my oracle support information available about the contained bugfixes.

This Patch Set includes a Technical Preview of WebLogic SCA. When Oracle introduced the new version of the Oracle SOA Suite 11g, it introduced a new abstraction layer, the Service Component Architecture (SCA). The SCA can be seen from a technical point of view, as a container that holds a set of SOA components. These components interact with each other and can be exposed to the outside world as a service. The components itself can call external services, these are called references. In WebLogic SCA, you can write Java applications using Plain Old Java Objects (POJOs) and expose components as SCA references and services, using SCA semantics configured in a Spring application context. WebLogic SCA applications run in WebLogic Server (via the WebLogic SCA Runtime) and can be used as components in Oracle SOA composites. You select the SCR Runtime during installation.

The runtime itself is called JscaLite and is JscaLite a lightweight Spring 2.5 (or higher) SCA container for standalone WLS. JScaLite aligns itself with the Spring C&I specification 1.1 except for SCA Properties.

Download it directly from Oracle
You can find the online documentation here.

Oracle TechCasts from OpenWorld 2009 about WebLogic Server online

Justin Kestelyn posted audio versions of the Oracle OpenWorld Live "TechCast" chats

Oracle TechCasts are audio podcasts, hosted by OTN's Justin Kestelyn, with technical experts about new tools, technologies, and trends in application development.

The following two are most relevant for WebLogic Server.

Nov. 9, 2009, Oracle OpenWorld Live 2009: Oracle WebLogic Server Looks Toward OSGi
Senior Director Product Management Mike Lehmann details the recent history of WebLogic Server development and also looks toward the future, to OSGi and virtualization.



Download mp3

Nov. 9, 2009, Oracle OpenWorld Live 2009: Oracle WebLogic Server On Tap from the Private Cloud
Product Manager Bill Dettelback explains some of the ways Oracle WebLogic Server can and should be deployed to private clouds in "platform as a service" (PaaS) mode.



Download mp3

Twitter Search in #weblogic console

A need to have "toy" for all twitter addicted WebLogic admins out there :-)
This is a quite lean console-extension, that searches for the #weblogic hashtag on twitter and displays it's results on top of every page of the wls admin console.

This example again makes use of JTwitter 1.2.
Download the war file and drop it to your domains console-ext directory.
If needed, add -DproxySet=true -DproxyHost=proxy -DproxyPort=1234 to your setDomainEnv scripts JAVA_PROPERTIES.

Now restart the server and access the console via http://host:port/console/



If you don't want to console to be deployed everytime you access it, you should switch of "on-demand deployment of internal applications". (Your domain => Configuration => General.

Howto write your own console-extension:
Have a look at the Extending the Administration Console for Oracle WebLogic Server Guide (PDF) and give it a try.

Brief summary:
- Setup WAR Project with your fav IDE
- Create ext_jsp folder
- Create portlets folder
- Create WEB/INF/netuix-extension.xml file
- Create portlets/yourPortletFile.portlet
- Create ext_jsp/yourJSPpage.jsp

As you might have guessed, this is a realy simple example. Only one JSP. No backend logic at all. You might think of different enhancements. But there was no time left for me, trying this out.

Mike Lehmann on #Weblogic, #JEE6 and Open Standards - #OOW09 Followup

One of my personal highlights at Oracle OpenWorld 2009 was the OTN techcast series. Livestreaming from the OTN lounge Justin brought up some very interesting guests to talk to. I got the chance to ask some questsions during the session with Mike Lehmann. Mike is the Senior Director of Product Management, Fusion Middleware Oracle Weblogic Server and Java Plattform.
See the complete techcast here. I am asking some live questions during the last five minutes.



The whole session only last a quarter of an hour. Therefore some questions still were unanswered. I asked Mike to kindly answer them by email afterwards. That is, what he did. A big "Thank you for doing that!" goes out to Mike!

AppSrvs have become some kind of comodity these days. What do you believe are the true differentiators for weblogic server?

One of the key benefits of adopting a standard like Java EE is it levels the playing field but there continues even in the core Java server space to be quite a large number of unique differentiators just for the core application server. I will outline examples of these below. We also have seen that the architectural styles and approaches that our community is using to build applications has changed over the years and we have adopted our server infrastructure offering to address these challenges our customers are facing with a new model we call the Application Grid which we think ups the ante on perceived commoditization and potentially redefines what customers expect in an application infrastructure.

On the Java EE side, once one gets beyond the API conformance, you typically see application servers like WebLogic differentating in a number of areas. Ones that are key to WebLogic Server include capabilities like - I have chosen a few representative ones rather than an end to end list:

Development Model

Capabilities like FastSwap which enables customers to replace Java classes (add methods, fields etc) without having to go through a redeployment or bounce of the server. It is an example of a server side capability above and beyond what the JDK proper offers in this space.

- Capabilities like Shared Libraries and Filtering Classloader support that enable developers to include multiple versions of common jars within the infrastructure without impacting the runtime (e.g. xml parsers v1 and v2 or different versions of logging infrastructure or different versions of popular frameworks)

Operations Model

WebLogic Diagnostics Framework - most application servers have some sort of ability to see stack traces or see baseline metrics when executing but the ability to formally set SLA's on the infrastructure and when they are breached dump out sophisticated diagnostics images is not common at all. Certainly it is unknown or limited in open source.

Consistent and deep scripting infrastructure - WLST in WLS - This seems like such a simple requirement but ironically as you probably well know is not a capability that exists in open source or typically in very primitive fashion. WLS's scripting and automation infrastructure is extremely rich and key to what customers achieve remarkably low operational costs on WebLogic compared to writing and invent equivalents on other platforms.

Runtime Model
Capabilities like side by side deployment - the ability to deploy a new version of an application without impacting existing users on a single JVM. Not requiring complex cluster dances to enable customers to transition to the new version of the application.

Thread management with Workload Manager - most other appliccation servers are very primitive here and it is an art versus a more deterministic well understood exercise as it is within WebLogic Server.

Messaging infrastruture - here beyond the basic JMS you see in most servers, WebLogic takes messaging out of the box within a Java EE server to another level not requiring customers to buy separate JMS infrastructure because of the richness we have here. We are remarkably succcessful in the JMS side and frankly it is not only highly differentiated for our standalone messaging customers where we compete against pure play messaging vendors but also to our huge SOA install base who depend on it for capabilities such as the Oracle Service Bus and our BPM solution.

High Availability

Capabilities like Whole Server Migration and Service migration - capabilities that many other servers leave to the imagination of the adminstrator.

These are some very simple examples but represent that even in so called commodity infrastructure there is in fact a long list of features that do result in significant value add to customers choosing application servers and frankly we believe significant operational, development and administrative cost savings that simply can not be achieved by competitive solutions.

Now we have also worked on adapting to how we see our customers deploying our infrastructure. In particular with this concept called the Application Grid. We define the Application Grid as: "The application grid approach to middleware infrastructure allows a set of applications to easily react to peaks and valleys in demand and adjusts capacity to improve overall performance by optimizing shared resources. It also allows for rapid application deployment and automated adjustments—enabling greater efficiency, competitiveness, and simplification in your IT environment.' Product wise in the Java space, the Application Grid consists of three major runtime products - Oracle WebLogic Server for mission critical Java EE applications, Oracle Coherence as an in memory data grid and JRockit for high performance low latency JVM infrastructure and in the management space Oracle Enterprise Manager.

The simple way of thinking about the Application Grid is very much like RAC in the Oracle Database. RAC is all about better quality of service on commodity hardware - improving scalability, reliability and availability on large clusters of commodity hardware. This has clearly been a sensibility in the middle tier for many years but frankly most application server vendors have done little to tackle it square on to make it an out of the box feature. We have done this in several areas within the Application Grid. Two examples that are top of mind are around state management and operational management. In the area of state management as you saw from OpenWorld we talk alot about scaling infrastructure using Coherence but it is not enough simply add Coherence to your infrastructure, it has to be seamlessly integrated with your applications - in our world frequently running on WebLogic Server. In Fusion Middleware 11g we did exactly this - we introduced seamless integration for statement management via Coherence integration with WebLogic Server. We have seen results that frankly extremely compelling and validate our vision of the Application Grid such as customers achieve several fold increase in capacity off of existing hardware and others being able to scale out dramatically further than they were prior to the introduction of Coherence into their infrastructure.

On the management side our investment in Enterprise Manager as an overall strategic management platform for WebLogic and Fusion Middleware has been a great win fairly significantly differentiating us from other vendors. Our ability to not just manage single instances of WebLogic Server, not just single domains of WebLogic Server but manage across multiple datacenters we think plays to where many of our customers are going where issues like Active Passive and Active Active topologies across data centers are actively being used and evaluated by our customers. A management solution that covers that breadth is extremely important to achieve success in these topologies and is a key value proposition that underlies our vision of the Application Grid.

So a long answer to a simple question - yes, there remain a long and compelling list of differentiators for WebLogic Server proper. The evolution of what most customers are now facing in the infrastructure frankly changes the game to not just an application server versus application server but a larger scale application infrastructure problem domain where we think architectural approaches like the Application Grid redefine expectations of customers entirely.

Looking out to GF v3, comming out with a first JEE6 release in the beginning of december. What do you advice erly adopting JEE6 customers to do? Switch? Wait? For how long?

We will have to of course wait to see when Java EE 6 officially released and as you know GlassFish is the reference implementation of it. Currently the public schedules indicate that it will be released before the end of this year and we are optimistic that Sun and the JCP can achieve these goals and thus enable the rest of the industry to also update their products to be Java EE 6 compatible.

As you may know Oracle already has made big strides in WebLogic Server 10g R3 and the recent WebLogic Server 11g to areas that Java EE 6 formalizes - the lighter weight Web profile. In WebLogic Server 10g R3 we introduced the ability to install a lighter weight core WebLogic Server as an option- as low as ~170M - and the ability to turn off containers like JMS and EJB through a single command line option. You may also be aware that Oracle itself is the provider of the JPA reference implementation EclipseLink which we ship in our commercial offering fully supported. Both of these are big areas of Java EE 6 that customers of WebLogic can use today in production environments well ahead of Java EE 6 being available to achieve some of the productivity benefits that many expect to see with Java EE 6.

Of course this approach does not mean WebLogic Server is already Java EE 6 compatible. We are both active participants in the standards community closing down Java EE 6 and actively working on our next major release where we hope to achieve Java EE 6 compatibility assuming the standard comes through the standards process in a time fashion. So what do I recommend to people today? Get involved by looking what is in Java EE 6 and for an understanding of where the experience will be, take a look at what you already get with production products like WebLogic Server 11g today that are remarkably close to some of the key characteristics customers are expecting in Java EE 6.

I saw a GlassFish presentation at Oracle Develop and was impressed by the startup times. What about further reducing development round trip time for WLS developers? Do you plan to optimize this further with the next releases?

We are always very actively engaged in increasing all the performance metrics of WebLogic Server and have strict release criteria that gate our release cycles. We actively engage in both public benchmarks like the SPECjAppServer2004 benchmark - where recently at OpenWorld we once again announced a world record result on single node infrastructure - but also on key metrics like startup time, deployment time, console access time, runtime performance metrics and many more. Already our effort on a lighter weight footprint WebLogic Server does provide significant improvements for developers and our ultimate compatibility with the Java EE 6 Web profile will further improve this. We will continue to heavily invest in as a quick startup time, quick deployment time and overall development cycle is hugely important for us to continue to be credible and adopted within the developer community.

Oracle has ever been an active member of the JCP. What do you expect other companies (e.g. IBM) to do, expecting that the sun deal closes? Will they further contribute to Java or does the whole setup needs to be changed?

Oracle has a long and actively engaged relationship with the Java Community Process and plans to continue this active involvement and participation in the community. It is not possible for me to comment beyond this due to the position we are in with the acquisition of Sun.

The WLS development team is about four times bigger than the Sun GlassFish team is. From a developers point of view I do not understand, why the adoption of new specifications take that long. What about doing more technical previews with weblogic server?

It is difficult for me to comment on development team size as neither company publicly states development numbers on the core application server so this would be speculation. Clearly the Fusion Middleware development team is tackling a broader set of middleware than Sun and thus is sized to deal with that problem domain but that is much different than solving the Java EE problem domain. And correspondingly the Sun middleware team has investments beyond GlassFish proper and would have an equally difficult time with such a comparison.

I can comment on the technical previews. Oracle has historically been very active in providing technical previews probably the most notable in the recent past was with the Oracle Application Server where we actively released ahead of production and every competitor on the market support of JPA and EJB 3.0 in J2EE 1.4 conforming to the final specification. Correspondingly BEA prior to the acquisition was also aggressive in this space being one of the first commercial vendors to come to market with a preview of Java EE 5.0 support. We would like to continue this going forward and our investment in developing EclipseLink in open source where daily snapshots of the software are available by the very nature of the development process are a great example of this. Bottom line: both Oracle pre-BEA and BEA pre-Oracle actively engaged the developer community with technical previews, we hope to continue that going forward.

How do you see the future of WLS within Fusion Middleware? Will it continue to be the fondation, but still be available as a solid standalone product? Or will the integration into the stack finally lead to a highly optimized Oracle Applicationserver (again)? And what would be your wish about the future?

We see WebLogic Server as both a compelling standalone product as it is today and also as the foundation of Fusion Middleware as it is today with Fusion Middleware 11g. Generally we see the roadmap of WebLogic Server in three dimensions:

1. Just Enough Application Server - this is aimed at the light weight, agile Java EE profile nature we see developers evolving to today and is represented nicely by the Java EE 6 Web profile and Oracle long investment in OSGi as a key modularization technology for application servers. Areas here include not only the runtime but deep integration into build, test, and continuous integration and qa environments - aimed at the full development lifecycle not just the core server infrastructure. This has applicability for the general standalone WebLogic Server market as well as customers adopting Fusion Middleware who want fast, lightweight development and deployment environments.

2. Large Scale Shared Services Infrastructure - this is aimed at customers who are deploying WebLogic Server in large deployments both large clusters and across multiple datacenters with an cost of operations that is significantly less than any other competitor on the market. A different mind set around extremely efficient and automated administration, operations and management has to be built into the product than that of working in smaller clusters like other more simply API compliant servers. Again this has huge applicability to our general standalone WebLogic Server market where this is a hard requirement but also our customers who are adopting Fusion Middleware across their enterprise.

3. Fusion Middleware and Fusion Applications - Clearly as you note, we have a clear business incentive to make WebLogic Server the best application server for Fusion Middleware and Fusion Applications. Ironically while some folks think this could be seen as a bad thing for standalone WebLogic Server customers, I tend to look at it as the opposite: Fusion Middleware and Fusion Applications represent some of the most challenging and functionally rich software infrastructure on the planet and an application server that is capable of running these sets of applications and infrastructure has unique and differentiated capabilities for our customers who also need a rock solid, proven infrastructure for their equivalently challenging and feature rich application infrastructures.

I think this is a challenging mission so when you ask for my wish for the future, it is to deliver on this mission. Oracle WebLogic combined with the Oracle organization that continues to have a world class engineering team that is uniquely positioned to change the industry's view of what application server infrastructure by executing against this set of goals.

Some customers complain about "vendor lock in" things and sometimes they switch to open source appservers. What would you tell those customers? why should they further invest into Weblogic?

Oracle has long had the mantra that there is a difference between open source and open standard. Open standards are one that are developed in conjunction with participants from the entire industry - commercial and open source vendors/participants. Java EE is a great example of this. Open source is a different approach - effectively making the source code available and in a number of cases, like with commercial offerings, can and do step up to being compatible with open standards.

WebLogic Server is a Java EE compatible server and as such applications developed on it that are conformant to Java EE standards have the optional choice and risk reduction strategy of being able to deploy on other Java EE compatible application servers. If customer decides to develop on an open source server and adopt a non-open standards framework (e.g. not Java EE) then they are taking on a risk that they may be locked into that server and unable to migrate unless they re-write their application. Some customers take this risk and face the challenge of those vendors - as you have seen in the open source market - being acquired and the resulting lack of certainty over the future of these non-open standard approaches. With Oracle because of corporate wide mandate and commitment to open standards as long as customers are building to standards like Java EE they have a strong certainty that they can mitigate any risk of vendor lockin by looking to alternative application servers.

Oracle also understands the attraction of open source - particularly since some areas of open source evolve faster due to lack of overhead associated with reaching a consensus across all major industry players and that can be sometimes advantageous to bring to market some technologies. This was particularly apparent in the web framework space with Apache Struts many years ago and Spring more recently. This is why in conjunction with a strong adherence to open standards you have seen Oracle actively participate and support open source projects be it contributions such as Apache Trinidad, EclipseLink (both standards and open source - ) or Spring (our contribution of WebLogic transaction integration to the project and Spring Pitchfork) or finally our Ecliplse Plug ins for Java EE (Oracle Enterprise Eclipse Pack [OEPE]). Our contributions in open source are actually fairly unique and are exemplified by EclipseLink. You will see that EclipseLink is not a fork from our commercial offering - it is one and the same. This is the same with OEPE where we develop in open source and ship it/support it as the commercial offering within our software packaging.

Bottom line: We believe we have the best open standards server implementation on the planet and agressively are standards compliant. We are also strong believers in open source and actively participate in numerous communities supporting open source development. Our efforts are backed by a development organization, support organization and sales organization who strongly believe in this mission, so we believe investing further in WebLogic Server is frankly in customers best interest and gives them the benefit of world class, standards based infrastructure with maximum risk mitigation while leveraging the best open source has to offer.

What would be your personal favorite feature of Weblogic 11g if you could make a wish?

I have been quite fond, as you have heard me speak at OpenWorld, of a feature we call ActiveCache which is the direct integration of Oracle WebLogic Server and Oracle Coherence to manage state in a separate tier from WebLogic Server. We see this giving pretty substantial benefits to our customers - reported benefits of doubling capacity on the same hardware as an example - for a remarkable simple and declarative change to ones application infrastructure. Coherence seriously changes how one can write applications when one takes the leap that you have a completely reliable and redundant in memory data grid available to your applications like you do with ActiveCache. We have seen customers using WebLogic and Coherence go from using it for basic state management to simple caching to using it for architectures where data is lazily written to back end databases to enable even more capacity into processor bound backend infrastructures and finally to complex computational risk analysis on that same in memory data. A truly exciting an unique technology that I think we are just seeing a small taste of what we will be able to do with it in coming releases.

What does the OTN Community mean to you? And how do you try to integrate or take advantage of their feedback?

OTN is of huge value to my team as product managers planning releases of WebLogic Server and our engineering team as they work on individual features. There are literally millions of developers who participate in OTN in numerous ways - forums, contributing articles, wikis, contributing code samples and directly feeding back to product teams. We as the product teams use it constantly as vehicle to developers with podcasts, blogs and participation in forums. We frankly have a lot of difficulty keeping up because it has grown so large - I think because of the quality of material and the quality of the community - but fortunately we have not only ourselves within Oracle to scale it we also have programs such Oracle ACE Directors where our top users also become very active and well known within the community and contribute and guide discussions.