The Buttso Blathers

WebLogic Server 12c - Identifying versions of modules, libraries, frameworks

2011-12-12T14:42:00.000+10:30

Now that WebLogic Server 12c has been released, it's interesting to look at the various libraries, modules and open-source frameworks it uses.

One approach to doing this is to use the wls-cat utility to search for a known class from the framework, module or open-source framework you are interested in looking at, and observing where the class is loaded from and the corresponding library version.

JavaServer Faces

One important item to note here is that as of the WebLogic Server 12c release, the JSF implementation has been added directly to the WebLogic Server classpath. This is a change from the WebLogic Server 11g release where the JSF implementation was provided as an optional shared-library, which needed to be deployed in order for applications to use JSF. With WebLogic Server 12c, JSF is now an integral part of the server and can be used without the necessity of deploying and referencing the shared-library.

javax.faces.webapp.FacesServlet:

com.sun.faces.facelets.Facelet:

Using:

JSF 2.1
Mojarra 2.1.5

Java Persistence API / EclipseLink

javax.persistence.Entity:

org.eclipse.persistence.jpa.JpaEntityManager:

Using:

JPA 2.0
EclipseLink 2.3

Context and Dependency Injection/Weld

javax.enterprise.inject.Model:

org.jboss.weld.Container:

Using:

CDI 1.0
Weld 1.1.3-SP1

SLF4J

org.slf4j.Logger:

Using:

SLF4J 1.6.1

WebLogic Server 12c - Maven Usage Notes

2011-12-12T10:42:00.001+10:30

Note: apologies for the formatting, this posting was a cut and paste from a .docx document and thus has all the styles inlined. In the interests of time, I thought it was better to just post it as-is and make it available, rather than try and reformat it. Which I know I'd keep pushing off until eternity.

This document provides a short overview of installing, configuring and using the new wls-maven-plugin provided in WebLogic Server 12c.

Convention Over Configuration

With the wls-maven-plugin:12.1.1.0 we have followed the theme of Maven and used a convention-over-configuration approach. This means that for a set of the commonly used configuration elements, we have adopted a sensible, consistent set of default values that can be used across all of the goals. This reduces the amount of configuration necessary to use the plugin and helps achieve uniform goal executions, even in different environments.

The common configuration elements are:

middlewareHome: ${project.basedir}/Oracle/Software

weblogicHome: “wlserver” or “wlserver_12.1”, depending on the install type

domainHome: ${project.basedir}/Oracle/Domains

source: ${project.build.directory}/${project.build.finalName}.${project.packaging}

adminurl: t3://localhost:7001

While these configuration parameters have default values, they can all be overridden in a pom.xml file or on the command line as need be.

However by having them be sensible defaults, they can be left out of a configuration section and used consistently across all of the goals.

As an example, it’s possible to issue the following commands that all use the same WLS installation and domain without specifying any repetitive values:

$ wls:install -
DartifactLocation=/Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip

$ wls:create-domain –Duser=weblogic –Dpassword=welcome1

$ wls:start-server

Installing the Plugin

For WLS 12c, the wls-maven-plugin is provided as a pre-built jar file and the

accompanying pom.xml file is also provided as an easily accessible file in the same directory.

$MW_HOME/wlserver/server/lib/wls-maven-plugin.jar

$MW_HOME/wlserver/server/lib/pom.xml

The wls-maven-plugin is installed using the following commands:

$ cd $MW_HOME/wlserver/server/lib

$ mvn install

$ mvn install:install-file –Dfile=wls-maven-plugin.jar –DpomFile=pom.xml

The default pom.xml file now has the required setting to enable the use of the “wls” goal prefix enabled by default.

To use the “wls” goalPrefix, you will need to edit the Maven settings.xml file and add the following entry:

<pluginGroups>

<pluginGroup>com.oracle.weblogic</pluginGroup>

</pluginGroups>

Once you have installed the plugin, you can very simply validate it using the wls:help goal.

$ mvn wls:help

This goal does not require a project or pom.xml and will display the list of goals available in the wls-maven-plugin if the plugin has been successfully installed.

Basic Configuration of Plugin

Below is an example of a basic Java EE 6 Web Application pom.xml file that enables the use of the wls-maven-plugin.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<artifactId>maven-demo</artifactId>

<version>1.0-SNAPSHOT</version>

<name>maven-demo</name>

<endorsed.dir>${project.build.directory}/endorsed</endorsed.dir>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

<groupId>javax</groupId>

<artifactId>javaee-web-api</artifactId>

<scope>provided</scope>

</dependency>

</dependencies>

<build>

...

<plugin>

<groupId>com.oracle.weblogic</groupId>

<artifactId>wls-maven-plugin</artifactId>

<version>12.1.1.0</version>

</plugin>

</plugins>

</build>

</project>

Install

This goal installs WLS into a local directory to enable it to be used execute the other goals, as well as a installation to create a WLS domain that can be used to deploy and test the application represented as the Maven project.

To install, you need a distribution to install. This is specified using the <artifactLocation> configuration element in the wls-maven-plugin section of the pom.xml, or specify it using the –DartifactLocation property when Maven is invoked.

The target directory for the installation is specified using the optional weblogicHome configuration element. This is set to ${basedir}/Oracle/Software by default. Specifying a <middlewareHome> value will direct the install to be performed in the specified location.

I will focus on the zip distribution since it reflects a development usage model.

The location of the zip distribution can be specified as one of the following:

a) local file reference

For a local file reference, you specify the path on the local file system

<groupId>com.oracle.weblogic</groupId>

<artifactId>wls-maven-plugin</artifactId>

<artifactLocation>

/Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip

</artifactLocation>

</configuration>

</plugin>

The execution of the wls:install goal is shown below.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:install

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:install (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: install ++

[INFO] ++====================================================================++

[INFO] Installing /Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip into /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software

[INFO] Installing the product, this may take some time.

[INFO] Executing: [cmd:[/bin/bash, -c, chmod +x ./configure.sh; ./configure.sh]]

[INFO] Process being executed, waiting for completion.

[INFO] [exec] **************************************************

[INFO] [exec] WebLogic Server 12c (12.1.1.0) Zip Configuration

[INFO] [exec]

[INFO] [exec] MW_HOME: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software

[INFO] [exec] JAVA_HOME: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

[INFO] [exec] **************************************************

...

[INFO] [exec] BUILD SUCCESSFUL

[INFO] [exec] Total time: 0 seconds

[INFO] [configure script] exit code: 0

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1:53.210s

[INFO] Finished at: Wed Nov 23 15:46:53 CST 2011

[INFO] Final Memory: 3M/81M

[INFO] ------------------------------------------------------------------------

b) URL reference

<groupId>com.oracle.weblogic</groupId>

<artifactId>wls-maven-plugin</artifactId>

<artifactLocation>

http://test.us.oracle.com:7001/downloads/wls1211_dev.zip

</artifactLocation>

</configuration>

</plugin>

The execution of the wls:install goal is shown below.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:install

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:install (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: install ++

[INFO] ++====================================================================++

[INFO] Installing http://test.us.oracle.com:7001/downloads/wls1211_dev.zip into /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software

[INFO] Attempt to download artifact from maven repo failed - Artifact not found

[INFO] Attempt to download the weblogic server instance directly from url.

[INFO] Downloading the file ...

...

[INFO] [exec] BUILD SUCCESSFUL

[INFO] [exec] Total time: 0 seconds

[INFO] [configure script] exit code: 0

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 4:23.710s

[INFO] Finished at: Wed Nov 23 15:53:21 CST 2011

[INFO] Final Memory: 3M/81M

[INFO] ------------------------------------------------------------------------

c) Maven Artifact

Here the distribution is retrieved from the local Maven repository itself. This means it needs to have been installed into the repository or pulled over from a remote repository at some point.

To install wls1211-dev.zip into Maven repository the following type of command can be used:

sbutton:~ $ mvn install:install-file -Dfile=wls1211_dev.zip
-DgroupId=com.oracle.weblogic -DartifactId=wls-dev
-Dpackaging=zip -Dversion=12.1.1.0

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building Maven Stub Project (No POM) 1

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom ---

[INFO] Installing /Users/sbutton/Downloads/wls/wls_1211/wls1211_dev.zip to /Users/sbutton/.m2/repository/com/oracle/weblogic/wls-dev/12.1.1.0/wls-dev-12.1.1.0.zip

[INFO] Installing /var/folders/cL/cLTyZKXjGgmQhEpoV+U-DE+++TI/-Tmp-/mvninstall7575420374983698784.pom to /Users/sbutton/.m2/repository/com/oracle/weblogic/wls-dev/12.1.1.0/wls-dev-12.1.1.0.pom

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 11.089s

[INFO] Finished at: Wed Nov 23 15:30:17 CST 2011

[INFO] Final Memory: 3M/81M

[INFO] ------------------------------------------------------------------------

This installs wls1211-dev.zip as a Maven artifact with the following coordinate:

com.oracle.weblogic:wls-dev:zip:12.1.1.0

To use this Maven artifact as the distribution to install, the plugin looks like the below.

<groupId>com.oracle.weblogic</groupId>

<artifactId>wls-maven-plugin</artifactId>

<artifactLocation>

com.oracle.weblogic:wls-dev:zip:12.1.1.0

</artifactLocation>

</configuration>

</plugin>

The execution of the wls:install goal is shown below.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:install

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:install (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: install ++

[INFO] ++====================================================================++

[INFO] Installing com.oracle.weblogic:wls-dev:zip:12.1.1.0 into /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software

[INFO] Installing the product, this may take some time.

[INFO] Executing: [cmd:[/bin/bash, -c, chmod +x ./configure.sh; ./configure.sh]]

[INFO] Process being executed, waiting for completion.

[INFO] [exec] **************************************************

[INFO] [exec] WebLogic Server 12c (12.1.1.0) Zip Configuration

[INFO] [exec]

[INFO] [exec] MW_HOME: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software

[INFO] [exec] JAVA_HOME: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

[INFO] [exec] **************************************************

[INFO] [exec]

...

[INFO] [exec]

[INFO] [exec] Your environment has been set.

[INFO] [exec]

[INFO] [exec] BUILD SUCCESSFUL

[INFO] [exec] Total time: 0 seconds

[INFO] [configure script] exit code: 0

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1:57.549s

[INFO] Finished at: Wed Nov 23 15:35:32 CST 2011

[INFO] Final Memory: 4M/81M

[INFO] ------------------------------------------------------------------------

Unless the <middlewareHome> configuration paramter is specified, the installation is performed in the ${basedir}/Oracle/Software directory.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ ls -l

total 8

drwxr-xr-x 3 sbutton staff 102 23 Nov 15:44 Oracle

-rw-r--r-- 1 sbutton staff 3597 23 Nov 15:43 pom.xml

drwxr-xr-x 3 sbutton staff 102 23 Nov 15:03 src

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ ls -l Oracle/Software/

total 64

-rw-r--r-- 1 sbutton staff 5808 23 Nov 15:45 README.txt

-rw-r--r-- 1 sbutton staff 3064 23 Nov 15:45 configure.cmd

-rwxr-xr-x 1 sbutton staff 2857 23 Nov 15:45 configure.sh

-rw-r--r-- 1 sbutton staff 3189 23 Nov 15:45 configure.xml

-rw-r--r-- 1 sbutton staff 133 23 Nov 15:45 domain-registry.xml

drwxr-xr-x 508 sbutton staff 17272 23 Nov 15:46 modules

-rw-r--r-- 1 sbutton staff 1138 23 Nov 15:45 registry.template

-rw-r--r-- 1 sbutton staff 1320 23 Nov 15:46 registry.xml

drwxr-xr-x 3 sbutton staff 102 23 Nov 15:45 utils

drwxr-xr-x 7 sbutton staff 238 23 Nov 15:46 wlserver

Create-Domain

This goal creates a standard WLS domain from the specific WLS installation.

The location of the domain is specified using the optional <domainHome> configuration element. By default <domainHome> is set to ${basedir}/Oracle/Domains so it will be created in an Oracle/Domains subdirectory of the root directory of the Maven project.

The WLS installation to be used is specified using the optional <middlewareHome> configuration element. This is set to ${basedir}/Oracle/Software by default, so if the default location has been used to execute the install goal, it can be left out of this goal.

To create a domain, a user and password are required. These can be specified as configuration parameters using the <user> and <password> properties or they can be specified on the command line.

<groupId>com.oracle.weblogic</groupId>

<artifactId>wls-maven-plugin</artifactId>

com.oracle.weblogic:wls-dev:zip:12.1.1.0

</artifactLocation>

<user>weblogic</user>

<password>welcome1</user>

</configuration>

</plugin>

The execution of the wls:install goal is shown below.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:create-domain

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:create-domain (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: create-domain ++

[INFO] ++====================================================================++

[INFO] Domain creation script:

readTemplate('/Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Software/wlserver/common/templates/domains/wls.jar')

cd('/Security/base_domain/User/weblogic')

set('Name', 'weblogic')

set('Password', '***')

writeDomain('/Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain')

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 39.345s

[INFO] Finished at: Wed Nov 23 16:01:13 CST 2011

[INFO] Final Memory: 24M/81M

[INFO] ------------------------------------------------------------------------

Unless the <domainHome> configuration property is specified, the domain will be created in the ${basedir}/Oracle/Domains directory of the project.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ ls -l Oracle/Domains/mydomain

total 16

drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 autodeploy

drwxr-xr-x 10 sbutton staff 340 23 Nov 16:01 bin

drwxr-xr-x 10 sbutton staff 340 23 Nov 16:01 config

drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 console-ext

-rw-r--r-- 1 sbutton staff 462 23 Nov 16:01 fileRealm.properties

drwxr-xr-x 7 sbutton staff 238 23 Nov 16:01 init-info

drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 lib

drwxr-xr-x 6 sbutton staff 204 23 Nov 16:01 security

drwxr-xr-x 3 sbutton staff 102 23 Nov 16:01 servers

-rwxr-x--- 1 sbutton staff 293 23 Nov 16:01 startWebLogic.sh

Start-Server

This goal executes a startWebLogic command on a given domain, starting the WebLogic Server instance for use.

This goal also uses the <middlewareHome> and <domainHome> configuration elements to specify the location of the WLS installation and domain to use.

If you have followed the convention-over-configuration approach and adopted the default values, these configuration elements do not need to be specified.

If you have installed WLS or created a domain in a different location, you must specify the location using the <middlewareHome> and <domainHome> configuration elements in the pom.xml or specify them as parameters on the command line.

Using the convention-over-configuration approach, the default domain ${basedir}/Oracle/Domains/mydomain using the WLS installation in ${basedir}/Oracle/Software can be started as shown below.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:start-server

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:start-server (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: start-server ++

[INFO] ++====================================================================++

.[INFO] Starting server in domain /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain

[INFO] Check stdout file for details: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain/server-2388282492279558044.out

[INFO] Process being executed, waiting for completion.

.........

[INFO] Server started successful

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 9.137s

[INFO] Finished at: Wed Nov 23 16:23:07 CST 2011

[INFO] Final Memory: 4M/81M

[INFO] ------------------------------------------------------------------------

Deploy

The deploy goal deploys an application.

The convention-over-configuration approach uses the defaults available for middlewareHome, adminurl, and the source file to deploy allowing the goal to be executed without any additional configuration.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:deploy

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:deploy (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: deploy ++

[INFO] ++====================================================================++

weblogic.Deployer invoked with options: -noexit -user weblogic -deploy -source /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/target/maven-demo.war

Task 0 initiated: [Deployer:149026]deploy application maven-demo on AdminServer.

Task 0 completed: [Deployer:149026]deploy application maven-demo on AdminServer.

Target state: deploy completed on Server AdminServer

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 5.803s

[INFO] Finished at: Wed Nov 23 16:36:52 CST 2011

[INFO] Final Memory: 6M/81M

[INFO] ------------------------------------------------------------------------

Stop-Server

The stop-server goal stops an executing server using the stopWebLogic script on the specified domain.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:stop-server

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:stop-server (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: stop-server ++

[INFO] ++====================================================================++

[INFO] Stop server in domain: /Users/sbutton/Projects/Java/wls-maven-doc/maven-demo/Oracle/Domains/mydomain

[INFO] Process being executed, waiting for completion.

[INFO] [exec] Stopping Weblogic Server...

[INFO] [exec]

[INFO] [exec] Initializing WebLogic Scripting Tool (WLST) ...

[INFO] [exec]

[INFO] [exec] Welcome to WebLogic Server Administration Scripting Shell

[INFO] [exec]

[INFO] [exec] Type help() for help on available commands

[INFO] [exec]

[INFO] [exec] Connecting to t3://localhost:7001 with userid weblogic ...

[INFO] [exec] Successfully connected to Admin Server 'AdminServer' that belongs to domain 'mydomain'.

[INFO] [exec]

[INFO] [exec] Warning: An insecure protocol was used to connect to the

[INFO] [exec] server. To ensure on-the-wire security, the SSL port or

[INFO] [exec] Admin port should be used instead.

[INFO] [exec]

[INFO] [exec] Shutting down the server AdminServer with force=false while connected to AdminServer ...

[INFO] [exec] WLST lost connection to the WebLogic Server that you were

[INFO] [exec] connected to, this may happen if the server was shutdown or

[INFO] [exec] partitioned. You will have to re-connect to the server once the

[INFO] [exec] server is available.

[INFO] [exec] Disconnected from weblogic server: AdminServer

[INFO] [exec] Disconnected from weblogic server:

[INFO] [exec]

[INFO] [exec] Exiting WebLogic Scripting Tool.

[INFO] [exec]

[INFO] [exec] Done

[INFO] [exec] Stopping Derby Server...

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 8.921s

[INFO] Finished at: Wed Nov 23 16:41:14 CST 2011

[INFO] Final Memory: 4M/81M

[INFO] ------------------------------------------------------------------------

APPC

The appc goal executes the WebLogic Server application compiler tool to prepare the application for deployment.

This benefits from the convention-over-configuration model, allowing it to be executed using the defaults of the project.

An example of the goal being executed is shown below. Note this example uses the –verbose flag to highlight the activities the appc utility is performing. This is not normally necessary.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:appc -Dverbose

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:appc (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: appc ++

[INFO] ++====================================================================++

[JspcInvoker]Checking web app for compliance.

[jspc] -webapp specified, searching . for JSPs

[jspc] Compiling /index.jsp

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 5.281s

[INFO] Finished at: Wed Nov 23 16:43:12 CST 2011

[INFO] Final Memory: 16M/81M

[INFO] ------------------------------------------------------------------------

WLST

The WLST goal enables the WebLogic Scripting Tool (WLST) to be used to execute scripts that configure resources or perform other operational actions on a WebLogic Server domain. The WLST used by the wlst Maven goal is the standard environment WebLogic Server WLST environment so all existing scripts should be able to be used.

Benefitting again from the convention-over-configuration, the middlewareHome and domainHome locations do not need to be specified if the defaults are used.

The WLST goal can execute an external script specified using the <fileName> configuration element or a sequence of WLST calls can be specified within the pom.xml using the <script> configuration element.

<groupId>com.oracle.weblogic</groupId>

<artifactId>wls-maven-plugin</artifactId>

com.oracle.weblogic:wls-dev:zip:12.1.1.0

</artifactLocation>

<user>weblogic</user>

<password>welcome1</user>

<filename>create-datasource.py</fileName>

</configuration>

</plugin>

An execution of the wlst goal is shown below.

sbutton:~/Projects/Java/wls-maven-doc/maven-demo $ mvn wls:wlst -DfileName=create-datasource.py

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building maven-demo 1.0

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- wls-maven-plugin:12.1.1.0:wlst (default-cli) @ maven-demo ---

[INFO] ++====================================================================++

[INFO] ++ wls-maven-plugin: wlst ++

[INFO] ++====================================================================++

*** Creating DataSource ***

Connecting to t3://localhost:7001 with userid weblogic ...

Successfully connected to Admin Server 'AdminServer' that belongs to domain 'mydomain'.

Warning: An insecure protocol was used to connect to the

server. To ensure on-the-wire security, the SSL port or

Admin port should be used instead.

Location changed to edit tree. This is a writable tree with

DomainMBean as the root. To make changes you will need to start

an edit session via startEdit().

For more help, use help(edit)

Starting an edit session ...

Started edit session, please be sure to save and activate your

changes once you are done.

Activating all your changes, this may take a while ...

The edit lock associated with this edit session is released

once the activation is completed.

Activation completed

Location changed to serverRuntime tree. This is a read-only tree with ServerRuntimeMBean as the root.

For more help, use help(serverRuntime)

**** DataSource Details ****

Name: cp

Driver Name: Oracle JDBC driver

DataSource: oracle.jdbc.xa.client.OracleXADataSource

Properties: {user=demo}

State: Running

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 10.686s

[INFO] Finished at: Wed Nov 23 16:55:25 CST 2011

[INFO] Final Memory: 13M/81M

[INFO] ------------------------------------------------------------------------

weblogic.xml and prefer-application-packages

2011-08-11T16:05:00.000+09:30

Short and sweet this one, purely for my own future simple reference.

To use prefer-application-packages in weblogic.xml, it looks like this:

<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd">

  <jsp-descriptor>
    <keepgenerated>true</keepgenerated>
    <debug>true</debug>
  </jsp-descriptor>

  <context-root>/quicktest</context-root>
  
  <container-descriptor>
    <prefer-application-packages>
        <package-name>org.codehaus.jackson.*</package-name>
        <package-name>org.codehaus.jettison.*</package-name>
        <package-name>org.objectweb.asm.*</package-name>
    </prefer-application-packages>
  </container-descriptor>

</weblogic-web-app>

Unofficial Java SE 7 Builds for Mac OS X

2011-07-13T10:00:00.000+09:30

Not sure how I overlooked this, but according to this page here:

http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port

There are prebuilt (unofficial) binaries for Java SE 7 on Mac OS X here:

http://code.google.com/p/openjdk-osx-build/downloads/list?q=label:Featured

Good stuff.

Plugging in a later version of EclipseLink to WebLogic Server

2011-07-04T18:00:00.000+09:30

Talking with Doug Clarke of EclipseLink fame and fortune last week, it sounds like there is some real interest from developers in wanting to update WebLogic Server to use later versions of the EclipseLink in order to access it's evolving feature set.

Which should offer no surprises really, EclipseLink rocks.

Investigation

Turning to the situation at hand, the main points to be addressed are:

1. The later versions of EclipseLink are JPA 2.0 based, so we'll assume that the predominant use case is centered around using JPA 2.0.

WebLogic Server supports JPA 2.0 through the application of a Smart Update patch or via manual adjustments to the PRE_CLASSPATH to incorporate two additional JAR files that enable the use of JPA 2.0.

We'll consider this one easy to handle using documented features.

2. WebLogic Server provides a version of EclipseLink that is loaded as one it's standard feature bearing modules and thus is present by default in the classpath of WebLogic Server for deployed applications. For WLS 10.3.5, this version is org.eclipse.persistence_1.1.0.0_2-1.jar.

WebLogic Server has a feature called the Filtering Classloader, which enables applications to selectively override the libraries from WebLogic Server that an application sees. This should allow an application to be configured to not use the default version of EclipseLink that WebLogic Server provides. This requires each application to specifically provide a weblogic-application.xml file that lists the <prefer-application-packages> configuration set to explicitly filter our the org.eclipselink.persistence package.

3. Any change to the EclipseLink version should be isolated to just an application, and not applied to an entire WebLogic Server installation or domain.

To make the later version of EclipseLink available, there are a few simple options available that could be explored: a) the EclipseLink jar file could be added to the CLASSPATH of WebLogic Server; b) the EclipseLink jar file could be dropped into the $domain/lib directory; c) the newer version of EclipseLink could be used to replace the existing EclipseLink jar file shipped with WebLogic Server, retaining the same name; d) the WebLogic Server shared-library mechanism could be used to deploy the EclipseLink libraries which applications can then selectively reference.

For the sake of expediency, I won't bother going through the pros/cons with each of those options and will just pick a winner from my perspective: the use of a shared-library to provide a selectively consumable version of EclipseLink.

Let's just examine this for a moment -- a WebLogic Server shared-library is an artifact that can be deployed to a WebLogic Server target, which can then be referenced by an application being deployed, whereupon WebLogic Server will merge the contents of the shared-library with the application. This enables common libraries to be deployed and used by multiple applications. Furthermore, shared-libraries can take the format of a standard Java EE archives, where descriptors can be provided which are then also merged with the final application deployment.

Given those capabilities:

a) it's possible to construct and deploy an EAR file based shared-library that contains a later version of EclipseLink and a weblogic-application.xml file which provides a preset prefer-application-packages setting that filters the org.eclipselink.persistence.* package.

b) to use a later version of EclipseLink, an application simply needs to include it's own weblogic-application.xml that imports the EclipseLink shared-library it need to use.

Thus, we have a supported deployment format (can be targeted at single nodes, clusters, whatever ...) to provide later versions of EclipseLink, which can be shared and selectively used by applications as desired.

Implementation

To test this out in an end-to-end manner, I performed the following steps:

1. Downloaded eclipselink-2.2.0.v20110202-r8913.zip from the EclipseLink web site.

2. Created a small ant project to produce an eclipselink-shared-lib.ear file. The layout of the shared-library is just a standard Java EE EAR file and contains the following items:

META-INF/weblogic-application.xml
META-INF/application.xml
lib/eclipselink.jar

The weblogic-application.xml file contains the following configuration elements:

<weblogic-application>
<prefer-application-packages>
 <package-name>org.eclipse.persistence.*</package-name>
</prefer-application-packages>
</weblogic-application>

The application.xml was a necessary element to support the runtime library merging. As you can see from the below, it's basically a NOOP configuration file.

<application>
<display-name>eclipselink-shared-lin</display-name>
<module>
 <java></java>
</module>
</application>

The ant build script produces an EAR file from these elements with one important addition that marks the EAR file as a shared-library for WebLogic Server by adding a number of attributes to the META-INF/MANIFEST.MF file:

<target name="package" depends="prepare">
 <jar destfile="dist/${ant.project.name}.ear">
 <metainf dir="etc" includes="*.xml"/>
 <manifest>
 <attribute name="Extension-Name" value="eclipselink"/>
 <attribute name="Specification-Version" value="2.0"/>
 <attribute name="Implementation-Version" value="2.2.0"/>
 </manifest>
 <fileset dir="build" includes="**/*"/>
 </jar>
</target>

At deployment time, WebLogic Server will use the attributes as meta-data for the deployed shared-library.

The final EAR file looks like this:

sbutton:~/Projects/Java/eclipselink-shared-lib/dist $ jar tf eclipselink-shared-lib.ear
META-INF/
META-INF/MANIFEST.MF
META-INF/application.xml
META-INF/weblogic-application.xml
lib/
lib/eclipselink.jar

For reference, the simple ant project to build the eclipselink-shared-lib.ear file is here: eclipselink-shared-lib.zip.

3. Deployed eclipselink-shared-lib.ear to WebLogic Server. This results in a new library being available on the server, eclipselink#2.0@2.2.0.

4. Created a test application that imports eclipselink#2.0@2.2.0 and outputs the version of it that it is seeing.

The application uses a weblogic.xml to reference the eclipselink#2.0@2.2.0 shared-library that was deployed, which picks up both the new version of eclipselink.jar as well as the filtering-classloader description the library contains:

weblogic-application.xml:

<weblogic-application>
 <library-ref>
 <library-name>eclipselink</library-name>
 <specification-version>2.0</specification-version>
 <implementation-version>2.2.0</implementation-version>
 </library-ref>
</weblogic-application>

Within the application, used a simple servlet that outputs the version of EclipseLink it is seeing:

out.printf("EclipseLink Version: %s", org.eclipse.persistence.Version.getVersionString());

5. Packaged the application into an EAR file and deployed it to WebLogic Server as an application.

When the application is accessed it reports the new version of EclipseLink supplied via the shared-library:

EclipseLink Version: 2.2.0.v20110202-r8913

6. Performed a negative test by undeploying the application, removed the weblogic-application.xml file from it and redeployed it.

When the application is accessed it reports the default version of EclipseLink that WebLogic Server supplies:

EclipseLink Version: 2.1.3.v20110304-r9073

7. With the basic premise validated, add a JPA module to validate the code-weaving EclipseLink performs works as expected. To verify the version EclipseLink is using the EclipseLink log level was set to fine and the console output reviewed, which showed up as Eclipse Persistence Services - 2.2.0.v20110202-r8913

Summary

The use of WebLogic Server shared-libraries appears to be a very suitable model for providing later versions of EclipseLink that automatically filter out the WebLogic Server supplied versions, which applications can selectively choose to import when they need the later versions.

This was just a simple test of the concept of using WebLogic Server shared-libraries to do this. The EclipseLink/TopLink team are in the throes of formally certifying this approach, so keep an eye out for it on the EclipseLink site if it does pass full muster!

Building and Running OpenJDK 7 on Mac OS X - A Breeze

2011-06-17T14:52:00.000+09:30

Preparing a little for the Adelaide JUG meeting yesterday, where Java SE 7 was going to be the topic of discussion, I finally thought it was time to grab the OpenJDK 7 source, get it built and working on my Mac.

http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port

After checking off the pre-reqs, the process was as simple as following the small set of very clear instructions on the Wiki page.

The only small side excursion I had was that my bash environment had a JAVA_HOME env var set, which aborted the build at one point. Unsetting that and restarting the build, it then ran flawlessly for about 30mins before out popped a shiny new Open JDK 7 build.

Having never manually installed a JDK on my Mac (Apple updates have served me well) the instructions for how and where to install it was very helpful. And so simple! Particularly with how it results in the new JDK being visible to the /usr/libexec/java_home utility:



sbutton:~ $ /usr/libexec/java_home  -V 

Matching Java Virtual Machines (4):

1.6.0_24-b07-334, x86_64: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

1.6.0_24-b07-334, i386: "Java SE 6" /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home

1.7.0, x86_64: "OpenJDK 7" /Users/sbutton/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home

1.7.0, i386: "OpenJDK 7" /Users/sbutton/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home

Voila!

sbutton:~ $ export JAVA_HOME=`/usr/libexec/java_home  -v 1.7`

sbutton:~ $ java -version

openjdk version "1.7.0-internal"

OpenJDK Runtime Environment (build 1.7.0-internal-sbutton_2011_06_16_11_39-b00)

OpenJDK 64-Bit Server VM (build 21.0-b15, mixed mode)

Now looking forward to trying out some of the new language features with NetBeans 7.0.

All in all, a total breeze! Kudos to the OpenJDK Mac porters group.

WebLogic Server: Listing Groups of an Authenticated User

2011-06-14T16:40:00.001+09:30

Another question from a colleague today: "for a given authenticated user, how can I see what groups the user belongs to?"

Yep, good question Pas. Not sure, but worth some time to find out.

Hunting through the WebLogic Security Documentation, I found a good description and diagram of how a Subject is related to a Principal.

A principal is an identity assigned to a user or group as a result of authentication. Both users and groups can be used as principals by application servers such as WebLogic Server. The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals.

As part of a successful authentication, principals are signed and stored in a subject for future use.

Any principal that is going to represent a WebLogic Server user or group needs to implement the WLSUser and WLSGroup interfaces, which are available in the weblogic.security.spi package.

Thus presumably, if you can get hold of the Subject, then you should be able to see the Principals associated with the User, of which some should reflect the Group(s) the User belongs to.

But how do you get the Subject?

I kept reading through documentation, but I couldn't see any really obvious description of where/how the Subject could be obtained.

Then, after almost giving up and resorting to looking through the Javadoc, I found this small reference:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13711/thin_client.htm#i1030501

In Example 3-3, notice that the JSP is calling an API (request.getRemoteUser()) to get the name of the user that logged in.

A different API, weblogic.security.Security.getCurrentSubject(), could be used instead. To use this API to get the name of the user, use it with the SubjectUtils API as follows:
String username = weblogic.security.SubjectUtils.getUsername(
weblogic.security.Security.getCurrentSubject());

Note: In the actual doc, there's a missing opening parenthesis in the supplied code snippet. I've added it in orange in the above.

Looking at the Javadoc, the weblogic.security.Security class has a static method that returns a javax.security.auth.Security object.

I also found a post from Edward Biemond here: http://blog.whitehorses.nl/2010/01/29/weblogic-web-application-container-security-part-1/ that discusses this area, from a slightly different more practical perspective perhaps.

With the Subject accessible and the description of the WLUser and WLGroup interfaces above, the group(s) an authenticated user belongs to can be readily discovered.

    import weblogic.security.Security;
    import weblogic.security.spi.WLSUser;
    import weblogic.security.spi.WLSGroup;
    ...
    private void doSubjectStuff(PrintWriter out,
      HttpServletRequest request,
      HttpServletResponse response) {



        Subject subject = Security.getCurrentSubject();

        

        StringBuffer groups = new StringBuffer();

        String user = null;

        boolean first = true;



        for(Principal p: subject.getPrincipals()) {

            if(p instanceof WLSGroup) {

                if(first) {

                    first=false;

                } else {

                    groups.append(", ");

                }

                groups.append(p.getName());

            } else if (p instanceof WLSUser) {

                user = p.getName();

            }

        }

        

        out.printf("<p>RemoteUser: %s, User: %s, belongs to: %s</p>", 

                request.getUserPrincipal().getName(),

                user, 

                groups);

    }

Calling this from a servlet, deployed within a simple web application that uses BASIC authentication mapped to a couple of WebLogic Server groups, the following output is displayed when the user "steve" logs in:

RemoteUser: steve, User: steve, belongs to: AppTesters, Deployers

Note, as Edmond also points out, the groups that are provided in the Subject are the WebLogic Server groups the user belongs to, and not the logical role-name defined in the web.xml file.

web.xml:
<security-role> <role-name>ADMINS</role-name> </security-role>

weblogic.xml:
<security-role-assignment> <role-name>ADMINS</role-name> <principal-name>AppTesters</principal-name> <principal-name>Administrators</principal-name> </security-role-assignment>

The primary new takeaway point I got from this was the use of the weblogic.security.Security class to obtain an instance of the current Subject.

Using SLF4J with WebLogic Server Logging

2011-06-07T16:10:00.002+09:30

Just recently, I needed to take a look at the SLF4J (Simple Logging Facade 4 Java) API, and more specifically, to how it could be employed on WebLogic Server.

Simple Logging Facade for Java

http://www.slf4j.org/

SLF4J follows the Commons-Logging model in that it provides a "Simple Logging Facade" with an API that can be used to insert log messages into application code, without specifying the specific Logging framework that is to be used. The actual work of capturing and emitting the log message is handled by "pluggable" SLF4J binding, which are added at deployment/runtime time (or server start) and handle the actual logging implementation work. There are pre-built bindings for the common logging frameworks such as JDK logging, Log4J, LogBack, as well as a simple Logging implementation that appears to simply print log messages to stdout.

Basic Problem

Having a look at a project that was using SLF4J with WebLogic Server, the question that came up was how could we direct the SLF4J logs into the standard WebLogic Server log facilities.

In it's basic form, with the slf4j-simple-1.6.0.jar binding being used, the SLF4J logs were not consistent with the rest of the WebLogic Server logs.

<Jun 7, 2011 3:22:04 PM CST> <Notice> <WebLogicServer> <BEA-000395> <Following extensions directory contents added to the end of the classpath:

/Users/sbutton/Projects/Domains/wls1035/lib/slf4j-api-1.6.0.jar:/Users/sbutton/Projects/Domains/wls1035/lib/slf4j-simple-1.6.0.jar> 

<Jun 7, 2011 3:22:05 PM CST> <Info> <WebLogicServer> <BEA-000377> <Starting WebLogic Server with Java HotSpot(TM) 64-Bit Server VM Version 19.1-b02-334 from Apple Inc.> 

<Jun 7, 2011 3:22:05 PM CST> <Info> <Management> <BEA-141107> <Version: WebLogic Server 10.3.5.0  Fri Apr 1 20:20:06 PDT 2011 1398638 > 

. . .

. . .

<Jun 7, 2011 3:22:13 PM CST> <Notice> <WebLogicServer> <BEA-000331> <Started WebLogic Admin Server "myserver" for domain "mydomain" running in Development Mode> 

<Jun 7, 2011 3:22:13 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RUNNING> 

<Jun 7, 2011 3:22:13 PM CST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode> 

14 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO com.oracle.demo.wlsslf4j.TestServlet - *** This is an info: class com.oracle.demo.wlsslf4j.TestServlet

14 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] WARN com.oracle.demo.wlsslf4j.TestServlet - *** This is a warning: class com.oracle.demo.wlsslf4j.TestServlet

14 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] ERROR com.oracle.demo.wlsslf4j.TestServlet - *** This is an error: class com.oracle.demo.wlsslf4j.TestServlet

The question was: without writing a specific WLS binding, is there a way to enable the SLF4J logs to be directed into the WebLogic Server logs so they are consistently formatted and able to be viewed in the WebLogic Server console with the rest of the logs?

One Solution

The solution was quite straightforward in the end, simply by combining two pieces of existing functionality:

1. The SLF4J distribution ships with a binding for JDK logging called slf4j-jdk14-1.6.0.jar. This results in the SLf4J logs being directed into the JDK logging framework.

2. WebLogic Server ships with a JDK logging handler which will pick up log messages emitted from JDK logging framework and direct them into the WebLogic Server logging system.

The weblogic.logging.ServerLoggingHandler is documented here: http://download.oracle.com/docs/cd/E14571_01/web.1111/e13739/logging_services.htm#CHDBBEIJ

To get it all working, all it required was making the relevant libraries available to WebLogic Server and wiring them together using a logging.properties file.

Copy Libraries into WebLogic Server

SLF4J basically comes as two components. There's the API which is used by applications, and then there's the bridgings that handle the actual production of log messages into the desired form.

To make SLF4J available to WebLogic Server, I employed the simplest way I know - copy them into the domain/lib directory. This has a certain set of limitations in terms of updating versions without a server restart, etc. but it's a really simple way to get things working in the first instance.

sbutton:~/Projects/Domains/wls1035 $ ls -l lib/

total 88

-rw-r--r--  1 sbutton  staff    702  6 Jun 13:15 readme.txt

-rw-r--r--  1 sbutton  staff  25496  7 Jun 15:19 slf4j-api-1.6.0.jar

-rw-r--r--  1 sbutton  staff   8887  7 Jun 15:34 slf4j-jdk14-1.6.0.jar

Create a logging.properties file

The logging.properties file is a standard way to control JDK logging. Since we have directed SLf4J logs into JDK logging framework by making the slf4j-jdk14-1.6.0 binding available, we can configure JDK logging to use the ServerLoggingHandler provided by WebLogic Server, so as to direct its logs into the WebLogic Server logging system.

The JDK logging framework and its configuration options are all well documented, starting from Nov 2001 here: http://download.oracle.com/javase/1.4.2/docs/guide/util/logging/overview.html

Here is the logging.properties file that was used:

####

# Specify the handlers to create in the root logger

handlers = weblogic.logging.ServerLoggingHandler



# Register handlers for the com.oracle.demo package and its child loggers

com.oracle.demo.handlers = weblogic.logging.ServerLoggingHandler



# Do not send the org.hibernate.validator log messages to the root handler

com.oracle.demo.useParentHandlers = false



# Set the default logging level for the root logger

.level = ALL

com.oracle.demo.level = ALL



# Set the default logging level for new ServerLoggingHandler instances

weblogic.logging.ServerLoggingHandler.level = ALL

To direct the JDK logging framework to use the logging.properties file, the standard System property java.util.logging.config.file is used. With WebLogic Server, this can be easily accomplished by setting the JAVA_OPTIONS System property with the corresponding value.



$ export JAVA_OPTIONS="-Djava.util.logging.config.file=/Users/sbutton/Projects/Domains/wls1035/logging.properties"

Start WebLogic Server and Observe

With the libraries copied into the domain/lib directory, the logging.properties file created and specified as $JAVA_OPTIONS, starting WebLogic Server should now allow the logs created via SLF4J to be directed into the WebLogic Server logging framework. This should let them be seen on stdout in a consistent form with the standard WebLogic Server log messages, as well as via the WebLogic Server console through it's log viewer.

SL4J logs in stdout

<Jun 7, 2011 3:52:01 PM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to RUNNING> 

<Jun 7, 2011 3:52:01 PM CST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode> 

<Jun 7, 2011 3:52:07 PM CST> <Warning> 

<com.oracle.demo.wlsslf4j.TestServlet> <BEA-000000> <*** This is a warning: class com.oracle.demo.wlsslf4j.TestServlet> 

<Jun 7, 2011 3:52:07 PM CST> <Error> <com.oracle.demo.wlsslf4j.TestServlet> <BEA-000000> <*** This is an error: class com.oracle.demo.wlsslf4j.TestServlet>

SL4J logs in WebLogic Server console

VI customizations for syntax coloring, auto-indenting and more

2011-05-30T16:48:00.001+09:30

A colleague recently sent me a VIM resource file to configure how VIM displays code.

A small set of simple changes, but the effect is very nice and makes the casual viewing of code, scripts, etc. much nicer with line numbering, auto-indenting, syntax color coding, etc.

$ cat ~/.vimrc

set shiftwidth=2 
set tabstop=2 
set number 
set ruler 
set expandtab 
set smartindent 
set autoindent 
set showmatch 
:syntax enable 
highlight Statement ctermfg=white
highlight PreProc ctermfg=3
set pastetoggle=<F10>

This is what it looks with a Java file:

Thanks Mark.

Applying WLS CAT to WLS 10.3.3

2011-05-26T15:14:00.000+09:30

To help answer an OTN question today regarding the use of the domain/lib directory on WLS 10.3.3, I went to use the CAT utility (as I've become accustomed) and then realized we'd only added it from the WLS 10.3.4 onwards.

As far as I'm aware, we don't make use of any newer APIs in WLS 10.3.4 within CAT, so I simply copied out the wls-cat.war file from a WLS 10.3.4 installation and deployed it to the WLS 10.3.3 domain I was using for the test.

The WLS CAT application deployed successfully and then seemed to work normally, letting me locate exactly where class I was using was being loaded from on WLS 10.3.3.

Of course this is totally unsupported, but if you're in need of WLS CAT on an earlier 10.3.x release and of the adventurous spirit, give it a shot. You can always undeploy it if it doesn't work for you.

Deploying a Random JSF 2.0 Example on WebLogic Server using Maven and NetBeans and Maven

2011-05-19T12:58:00.000+09:30

I had a bit of a hunt around yesterday looking for some JSF 2.0 example applications to deploy. I quickly came across a comprehensive JSF 2.0 tutorial @ http://www.coreservlets.com/JSF-Tutorial/jsf2/ published by Marty Hall.

For each of the tutorial sections on this site, the example code and pages that are used to demonstrate the concepts and discussion are published as accessible source code.

So I thought I'd try a few of them out with WebLogic Server 10.3.5.

The examples I looked at didn't contain a build script, so I very simply converted them into Maven projects, which I then was able to open immediately in NetBeans (this feature rocks!). I then built, packaged and ran the application on a WebLogic Server 10.3.5 domain, all from NetBeans.

All up, I'd say it tool ~2 mins to get the example loaded and building in NetBeans and deployed to WebLogic Server.

It takes a lot more to describe it below than it does to actually do it.

Here's what I did to get the data-tables example to build, package and deploy to WebLogic Server.

1. Download the zip file from http://www.coreservlets.com/JSF-Tutorial/jsf2/code/data-tables.zip.

2. Extract the zip file to a local directory, which produces:

/data-tables/WebContent
/data-tables/src
/data-tables/build

3. Generate a Java EE Web Application using the Maven Archetype mechanism. What a great feature this is in Maven.

$ mvn archetype:generate
...
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
...
263: remote -> webapp-j2ee13 (-)
264: remote -> webapp-j2ee14 (-)
265: remote -> webapp-javaee6 (-)
266: remote -> webapp-jee5 (-)
...
Choose a number: 107: 266
Choose version:
1: 1.0
2: 1.0.1
3: 1.1
4: 1.2
Choose a number: 4:
Define value for property 'groupId': : coreservlets
Define value for property 'artifactId': : data-tables
Define value for property 'version': 1.0-SNAPSHOT: :
Define value for property 'package': coreservlets: :
Confirm properties configuration:
groupId: coreservlets
artifactId: data-tables
version: 1.0-SNAPSHOT
package: coreservlets
Y: : y

4. Copy the WebContent and src directories from the data-tables example into the new Maven project structure.

$ cp -rp ~/Projects/Java/data-tables/WebContent/* src/main/webapp/
$ cp -rp ~/Projects/Java//data-tables/src/ src/main/java/

5. Start NetBeans and simply open the data-tables/pom.xml file to load the project into the IDE.

Click around and explore the project to get a sense of what it contains.

6. Add the jsf-api dependency to the POM so the ManagedBean classes can be compiled.

You can either manually add this direct to the pom.xml as:

 <dependency>
 <groupId>javax.faces</groupId>
 <artifactId>jsf-api</artifactId>
 <version>2.0</version>
 <scope>provided</scope>
 </dependency>

Or use the "Add Dependency" option on the project to search for it and enter it via a dialog:

7. Add a weblogic.xml deployment descriptor to reference the JSF 2.0 shared-library deployed on the WLS domain.

I simply coped in an existing version of the file I had used before. You can also use the "New --> WebLogic --> WebLogic Descriptor" option in NetBeans to add it.

Add a library-ref to the jsf-2.0.war shared-library deployed on the WLS 10.3.4 domain.

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
<context-root>/data-tables-1.0-SNAPSHOT</context-root>
<library-ref>
 <library-name>jsf</library-name>
 <specification-version>2.0</specification-version>
 <implementation-version>1.0.0.0_2-0-2</implementation-version>
</library-ref>
</weblogic-web-app>

8. Run the project, select the WLS 10.3.5 Server type and watch it get built and packaged via Maven and deployed by NetBeans. This will start the WLS 10.3.5 server if necessary.

9. View the example application in a browser

Summary: there it is, a random JSF 2.0 example application, converted to a Maven project, opened in NetBeans and deployed to WebLogic Server 10.3.5, all in ~ 2mins.

First Adelaide Java User Group Session @ Oracle

2011-05-19T10:21:00.001+09:30

Tonight sees the first time that the Adelaide Java User Group meeting is being hosted @ the local Oracle office.

The session should be interesting with Derek Webber presenting on his area of expertise in Meta-programming with Groovy.

Meta-programming with Groovy

Meta-programming is a term to describe modifying code at runtime and is a very old idea in Computer Science. Groovy (now at 1.8) is a language that builds features directly on top of Java and aims to help developers be more productive. It’s meta-programming features provide a great number of opportunities to developers that are either really difficult to access or are all but impossible in plain Java. I will provide an overview of the Groovy Meta Object Protocol, along examples of what you can do with it. In particular it helps with:

easier reflection and adding behaviour dynamically
monkeypatching and extending existing 3rd party code
builders and domain-specific languages (DSLs)

For any local Adelaide folks interested in attending, the registration link is here:
http://www.jugevents.org/jugevents/event/registration.form?event.id=38181

Observing Bean Validation at JPA Level

2011-05-17T14:07:00.000+09:30

A quick followup to yesterdays posting regarding the use of JSF 2.0, JPA 2.0 and Bean Validation.

To verify the validation of the constraints at the JPA level, and not at the JSF front end, I decided to add a simple Servlet which calls the WidgetFacadeLocal directly to create a new Widget entity.

This led to a small, interesting side excursion.

Since the NetBeans project was defined as a Java EE 6 Web Application, when the new Servlet was added, the default option was to not generate a web.xml descriptor to describe the Servlet configuration and mapping, and instead to define the Servlet using the @WebServlet annotation on the Servlet class itself.

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

Now this won't deploy in this form to WebLogic Server 10.3.4 since it doesn't yet implement the Servlet 3.0 specification and support @WebServlet. But ... WebLogic Server has provided it's own specific annotation for Servlets since the 10.3 timeframe.

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13712/annotateservlet.htm#i161636

Therefore to have this Servlet deploy and run on WebLogic Server, without introducing a web.xml file, the @WLServlet annotation can simply be added to the Servlet class, looking like this:

@WebServlet(name = "TestValidationServlet", urlPatterns = {"/TestValidationServlet"})
@weblogic.servlet.annotation.WLServlet(name = "TestValidationServlet", mapping = "/TestValidationServlet")
public class TestValidationServlet extends HttpServlet {
 ....
}

At compile time, add a reference to $WL_HOME/modules/com.bea.core.weblogic.web.api_1.4.0.0.jar to make the annotation available and it'll build and package successfully.

With that small excursion done, and the Servlet able to be deployed to WebLogic Server with the addition of the single @WLServlet annotation, the JPA validation can be tested.

This can be simply done again by injecting the stateless session bean WidgetFacadeLocal using an @EJB annotation, then creating a Widget with a known invalid property, and attempting to persist it through the session bean. Any validation constraints that are violated will be detected and returned in an EJBException that can be checked, and displayed.

...
@EJB WidgetFacadeLocal widgetFacade;
...
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
 throws ServletException, IOException {
 ....
 try {
 Widget widget = new Widget();
 widget.setName("My Widget");
 widget.setEmail("bogus.email.com");
 widgetFacade.create(widget);

 } catch (EJBException ejbex) {
 out.printf("EJBException, caused by: %s", ejbex.getCause().getClass().getName());
 if (ejbex.getCausedByException() instanceof ConstraintViolationException) {
 ConstraintViolationException cve = (ConstraintViolationException) ejbex.getCausedByException();
 out.printf("Constraint Validations:");

 out.println("<ul>");
 for(ConstraintViolation cv: cve.getConstraintViolations()) {
 out.printf("<li>%s, %S, %s, %s</li>",
 cv.getRootBeanClass().getSimpleName(),
 cv.getPropertyPath(),
 cv.getMessage(),
 cv.getInvalidValue());
 }
 out.println("<ul>");
 }
 }
}

Here the Widget has an email address which is not valid, as well as missing the mandatory pricePerUnit property.

Deploying this to the WebLogic Server 10.3.4 domain used previously with JPA 2.0 enabled, and Bean Validation library added to the server classpath, the simple test shows that the Bean Validations are checked. An exception is returned that contains the set of constraint violations that occurred, which can be displayed to a user.

This demonstrates the use of implicit Bean Validation through using JPA 2.0 running on WebLogic Server 10.3.4.

Again, the key is to firstly ensure that the Server ClassPath is set to include the following libraries to expose and enable JPA 2.0 and have the Bean Validation implementation be visible to the JPA 2.0 provider:

$WLS_HOME/modules/com.oracle.jpa2support_1.0.0.0_2-0.jar
$WLS_HOME/modules/javax.persistence_1.0.0.0_2-0-0.jar
$GF_HOME/glassfish3/glassfish/modules/bean-validator.jar

And secondly, ensure that either the default JPA provider on the domain is set to TopLink, or the provider is specifically set to be org.eclipse.persistence.jpa.PersistenceProvider in persistence.xml within the application.

JSF 2.0, JPA 2.0 and Bean Validation on WebLogic Server

2011-05-16T16:13:00.002+09:30

For some time now, I’ve been meaning to build a simple application to demonstrate the use of JSF 2.0, JPA 2.0 and Bean Validation with WebLogic Server 10.3.4. But I hadn’t gotten around to it until I had a couple of hours free late last week.

Seeing as I didn’t have all that much time, I thought I’d try and repurpose the Java EE 6 CRUD (create-remove-update-delete) application that NetBeans generates for GlassFish 3.x, and see if I could get it to run on WebLogic Server.

The short answer to that was a resounding yes, with only a few minor changes or tricks.

In this blog, I’m going to step through what I did and highlight the changes that I played around with in order to make it work. I'm not going to make this a tutorial (at this point) since most of the steps that are required are simply using the NetBeans IDE and its wizards to generate the requisite components and pages.

Developing the Application

The starting point for this app was a single table, Widgets, created in a local Derby database.
Using NetBeans 7.0, a new Java EE Enterprise Application was created, using Java EE 6 and targetted at the GlassFish 3.1 server installed with NetBeans. This produces two child projects: a Web project and an EJB project.
In the EJB project, use the "Entity Classes from Database" to generate a JPA 2.0 Entity from the Widget table.

Worth pointing out here is the use of the Bean Validation specification to declare constraints on the various fields of the Widget entity.

I particularly appreciated the smarts NetBeans uses to provide a suggested @Pattern regular expression for an email field

@Pattern(regexp="[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?", message="Invalid email")//if the field contains email address consider using this annotation to enforce field validation
@Size(max = 100)
@Column(name = "EMAIL")
private String email;
Next, invoke the "Sessions Bean For Entity Classes ..." to generate a session facade with CRUD methods for the Widget entity.

Worth noting here are two points: First, the use of a Generics based Abstract class for the base CRUD operations, which is then subclassed by the WidgetFacade session bean to work specifically with the Widget entity. Second, the use of the JPA 2.0 Criteria API to build a number of queries in the base class.

public List<T> findRange(int[] range) {
 javax.persistence.criteria.CriteriaQuery cq getEntityManager().getCriteriaBuilder().createQuery();
 cq.select(cq.from(entityClass));
 javax.persistence.Query q = getEntityManager().createQuery(cq);
 q.setMaxResults(range[1] - range[0]);
 q.setFirstResult(range[0]);
 return q.getResultList();
}

This session bean is created with a local interface since the EJB 3.0 implementation in WebLogic Server requires the use of a business interface.
In the persistence.xml file, a trick worth keeping in mind here which may save you some pain later is to explicitly specify the JPA provider to use. This helps later on when you deploy the completed application to WebLogic Server, where the default JPA provider is Kodo/OpenJPA. This can be overridden at the WLS domain level, but setting it in persistence.xml within the application itself is an easy way to do it now.

<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

For more details on changing the default JPA provider for a WLS domain, see here:

http://buttso.blogspot.com/2010/05/changing-default-jpa-provider-in.html
With the EJB project now complete, the JSF pages can be generated for the application. In the Web project, this is done using the "JSF Pages from Entity Classes ..." wizard.

What this wizard generates is a set of JSF pages to represent each of the CRUD operations, a Controller ManagedBean to handle the various tasks required by each of the JSF view pages and the data interactions (with paging) and a EJB 3.1 @Stateless session bean to act as a session facade on the Widget entity.

The new EJB in WAR packaging option available with Java EE 6 is not yet available on WebLogic Server, so the first trick here is to change the Web project to use the session facade that has already been generated in the EJB project. This is possible because the NetBeans wizards generate the same underlying code for the session facade whether it is for an EJB specific project or as part of the JSF Pages for Entity Classes wizard.

Delete the session bean bean in the Web project, then adjust the JSF controller to use the local interface for the session bean in the EJB project:

//@EJB
//private sab.demo.widget.service.WidgetFacade ejbFacade;
@EJB
private sab.demo.widget.service.WidgetFacadeLocal ejbFacade;

Note that EJB 3.1 supports a No-Interface view of an EJB, which WebLogic Server doesn't yet support. So here we have changed the injection point to use the Local interface from our EJB project.

There is also a getFacade method which needs this simple type change as well:

//private WidgetFacade getFacade() {
private WidgetFacadeLocal getFacade() {
return ejbFacade;
}
Delete the persistence.xml file generated within the Web project, since this will now be supplied with the EJB project.
Modify the web.xml file and change the "version" attribute to be "2.5" to specify a valid version for WebLogic Server:

<web-app version="2.5" ... >
Using the "New ..." wizard, add a WebLogic Deployment descriptor to the Web project, and specify a shared library reference to the JSF 2.0 shared library that WebLogic Server supplies.

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app>
 <context-root>Widget</context-root>
 <library-ref>
 <library-name>jsf</library-name>
 <specification-version>2.0</specification-version>
 <implementation-version>1.0.0.0_2-0-2</implementation-version>
 </library-ref>
</weblogic-web-app>

See the links for more details about JSF 2.0 and WebLogic Server, including instructions for how to deploy and reference the shared-library:

http://buttso.blogspot.com/2010/05/jsf-20-support-in-weblogic-server-1033.html
http://buttso.blogspot.com/2011/03/jsf-with-managed-beans-and-dependency.html
Build the final application into an EAR file that is ready for deployment.

Deploying the Application to WebLogic Server

To deploy a JSF 2.0 application to WebLogic Server, the JSF 2.0 shared-library must be deployed. See links referenced above for details on how to do this.

http://buttso.blogspot.com/2010/05/jsf-20-support-in-weblogic-server-1033.html
http://buttso.blogspot.com/2011/03/jsf-with-managed-beans-and-dependency.html
To use JPA 2.0 with WebLogic Server, two optional libraries within the WebLogic Server installation must be placed into the classpath. This can be automated through the use of a SmartUpdate patch, or it can be performed manually by setting a PRE_CLASSPATH environment variable and specifying the required libraries before starting the WebLogic Server domain.

$ export PRE_CLASSPATH=/Users/sbutton/Java/wls-1035-dev/modules/com.oracle.jpa2support_1.0.0.0_2-0.jar:/Users/sbutton/Java/wls-1035-dev/modules/javax.persistence_1.0.0.0_2-0-0.jar
See the documentation for more details as needed:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13720/using_toplink.htm#CIHDJHHI
The application is also using the Bean Validation specification which is not supplied with WebLogic Server 10.3.4. To ensure that the JSF 2.0 and JPA 2.0 implementation in TopLink can see the Bean Validation implementation and automatically enlist it's services, I added it as an additional library to the PRE_CLASSPATH environment variable:

$ export PRE_CLASSPATH=${PRE_CLASSPATH):/Users/sbutton/Java/glassfish-31/glassfish3/glassfish/modules/bean-validator.jar

Note here I am just referencing the library from a local GlassFish installation I have. I could copy this library out into a separate location or even download it independently and reference it. Call me lazy if you will ... :-)
Start a WebLogic Server domain
Using the WebLogic Console, configure the required datasource (jdbc/sample) to point at the Derby database and test to ensure it is working.
Using the console, deploy the application.

Test the application

With the application deployed, it can be tested to observe the JSF 2.0, JPA 2.0 and Bean Validation uses working on WebLogic Server.

For instance, create a new Widget and specify an incorrect email address. You'll see that JSF will automatically detect the invalid value based on the @Pattern constraint set on the Widget entity, and display the accompanying message as an error message on the page.

Correcting the email address value, the entry can be successfully be saved.

Looking at the stdout on the console where the WLS domain was started, the use of JPA 2.0 via EclipseLink and the automatic enlistment of the Bean Validation implementation can be seen in the lines below:

<May 16, 2011 3:58:26 PM CST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
May 16, 2011 3:58:40 PM org.hibernate.validator.util.Version <clinit>
INFO: Hibernate Validator 4.1.0.Final
May 16, 2011 3:58:40 PM org.hibernate.validator.engine.resolver.DefaultTraversableResolver detectJPA
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
<May 16, 2011 3:58:40 PM CST> <Notice> <EclipseLink> <BEA-2005000> <2011-05-16 15:58:40.781--ServerSession(1625943009)--EclipseLink, version: Eclipse Persistence Services - 2.1.3.v20110304-r9073>
<May 16, 2011 3:58:40 PM CST> <Notice> <EclipseLink> <BEA-2005000> <2011-05-16 15:58:40.782--ServerSession(1625943009)--Server: 10.3.5.0>
<May 16, 2011 3:58:41 PM CST> <Notice> <EclipseLink> <BEA-2005000> <2011-05-16 15:58:41.266--ServerSession(1625943009)--file:/Users/sbutton/Projects/Domains/wls1035/servers/AdminServer/tmp/_WL_user/Widget/qb0nwv/Widget-EJB.jar_Widget-EJBPU login successful>

If you forget to specify the JPA provider using the <provider> element in config.xml and deploy the application to a default WLS domain, then you may see the following error message when you try and access the application:

This exception indicates that an application is using the JPA 2.0 API, but WebLogic Server can't find a JPA 2.0 provider. This is the default condition of a WLS domain where the Kodo/Open JPA 1.0 provider is supplied at runtime.

This can be easily modified as described above by specifying an explicit <provider> value for EclipseLink (or Hibernate if you are using that) or by altering the default JPA provider at the domain level using the WebLogic Console:

Summary

It proved to be quite straight forward to take the Java EE 6 CRUD application generated by NetBeans and alter it slightly to deploy and run successfully on WebLogic Server 10.3.4, using it's JSF 2.0 and JPA 2.0 support.

Markus Quick Tests RichFaces 4.0 on WLS 10.3.4

2011-05-11T11:21:00.000+09:30

Nice to see this blog from Markus Eisele (belatedly on my part) in which he describes how to do a quick test of the RichFaces 4.0 showcase deployed on WLS 10.3.4 using it's optional support for JSF 2.0:

http://blog.eisele.net/2011/04/running-richfaces-400final-showcase-on.html

Thanks Markus, will try it out.

WebLogic Server 10.3.5 Available

2011-05-09T17:19:00.000+09:30

Oracle WebLogic Server 10.3.5 was released for download on OTN over the weekend.

See the Quick View/Download page @
http://www.oracle.com/technetwork/middleware/fusion-middleware/downloads/index.html

Tutorial: JSF 2.0 and JPA 2.0 with WebLogic Server using NetBeans

2011-03-16T14:24:00.001+10:30

The NetBeans team have produced a new tutorial demonstrating using JSF 2.0, JPA 2.0 with WebLogic Server 10.3.4 and NetBeans 7.0. The application uses the JPA entity and JSF page generation wizards to quickly produce a working application based on a sample schema.

Developing an Enterprise Application for Oracle WebLogic Server

From the WebLogic Server perspective, this tutorial demonstrates some of the nice integration points NetBeans now has with WebLogic Server.

For instance, the tutorial shows how NetBeans discovers and presents the set of WebLogic Server supplied JSF shared-libraries to the developer to select from.

It shows the resulting automatic configuration of the weblogic deployment descriptor to reference the chosen shared library, and finally it shows the automatic deployment that of the selected JSF shared library that NetBeans performs if necessary.

This all goes to make the use of JSF with WebLogic Server very straight forward.

The tutorial also highlights the simple approach NetBeans exposes for developers to Enable JPA 2.0 on the target WebLogic Server domain that is being used for the application.

All together this is a tutorial well worth taking a look at and stepping through to look at the generated code and pages.

JSF with Managed Beans and Dependency Injection and WebLogic Server

2011-03-10T13:22:00.001+10:30

A question appears from time to time on various forums postings regarding the use of dependency injection within JSF Managed Beans when running on WebLogic Sever. The usual problem reported is that the dependency injection simply does not work.

A recent example of this is here:

http://forums.oracle.com/forums/thread.jspa?messageID=9418272&tstart=0#9418272

The Short Story

The short story is that WebLogic Server does indeed support the use of dependency injection, within Managed Beans in JSF applications. The simplest way to get it to work is to use the documented mechanism of deploying and using the WebLogic Server supplied JSF shared-library, in which the WebLogic Server specific implementation of the com.sun.faces.spi.InjectionProvider class is supplied, and automatically configured as the InjectionProvider implementation on the Web container.

It is this WebLogic Server specific class -- com.bea.faces.WeblogicInjectionProvider – in which the actual dependency injection calls are realized. Without this class being present, the dependency injection calls from JSF essentially become NOOPs.

See the documentation for more detailed instructions on how to deploy the JSF shared-library to WebLogic Server and reference it within applications.

Configuring JSF and JSTL Libraries
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13712/configurejsfandjtsl.htm#i163440

The Longer Story

To provide support for multiple versions of JSF, WebLogic Server uses its it’s shared-library mechanism. In a WebLogic Server installation, there are a set of “deployable-libraries” provided that can be deployed as libraries to a WebLogic Server domain to extend its base functionality, in this specific instance by providing a JSF runtime.

The JSF 2.0 shared-library is represented by the jsf-2.0.war archive. This archive contains the standard JSF and JSTL jar files, plus an additional library wls.jsf.di.jar.

The wls.jsf.di.jar library contains a single class com.bea.faces.WeblogicInjectionProvider, which is the WebLogic Server specific implementation of the com.sun.faces.spi.InjectionProvider interface required to support dependency inject from JSF.

Furthermore, WebLogic Server detects when JSF is present in a web application by examining if the “jsf” shared-library is referenced, or if the Faces Servlet is configured, and automatically sets the ServletContext parameter com.sun.faces.injectionProvider parameter to the com.bea.faces.WebLogicInjectionProvider class to specify the InjectionProvider to use.

** See http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and for the details of this standard JSF SPI mechanism.

public class com.bea.faces.WeblogicInjectionProvider implements com.sun.faces.spi.InjectionProvider {

    public com.bea.faces.WeblogicInjectionProvider();

    public void inject(java.lang.Object)  throws com.sun.faces.spi.InjectionProviderException;

    public void invokePostConstruct(java.lang.Object)  throws com.sun.faces.spi.InjectionProviderException;

    public void invokePreDestroy(java.lang.Object) throws com.sun.faces.spi.InjectionProviderException;

Thus without this wls.jsf.di.jar library and the com.bea.faces.WeblogicInjectionProvider class it contains that implements the JSF dependency injection SPI, any dependencies declared in the JSF application are not able to be fulfilled.

Using WebLogic Server JSF Shared Libraries

The simplest way to use dependency injection in JSF with WebLogic Server is to follow the documented approach for deploying and using JSF shared-library as referenced above. Once the shared-library is deployed, applications use it by providing a reference in a weblogic deployment descriptor to the JSF library. At runtime, WebLogic Server will arrange to have the contents of the shared-library made available for the application to use.

For deployment of shared-libraries to WebLogic Server, the standard tools such as the console, or the weblogic.Deployer utility are used, specifying the deployment type as a library.

With the JSF shared-library deployed to WebLogic Server, applications can reference it using a weblogic deployment descriptor.

An example weblogic.xml deployment descriptor referencing the deployed JSF@2.0 shared-library is shown below.

<?xml version="1.0" encoding="UTF-8"?>

<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">

  <jsp-descriptor>

    <keepgenerated>true</keepgenerated>

  </jsp-descriptor>

  <context-root>/WLS-JSF-EJB-DI-WEB</context-root>

  <library-ref>

    <library-name>jsf</library-name>

    <specification-version>2.0</specification-version>

    <implementation-version>1.0.0.0_2-0-2</implementation-version>

  </library-ref>

</weblogic-web-app>

This is the documented and supported approach and is what we recommend based on the current architecture we use to support JSF.

Embedding JSF within a Web Application

A common arrangement for applications using JSF, is to provide the JSF jar files within the web archive itself, so that they are always available when the application is deployed. It is this case typically where problems surface with dependency injection not working, since the WeblogicInjectionProvider class provider is not present, resulting in a NOOP when dependency injection calls are made.

If this embedding approach is to be used, then the undocumented (and daresay unsupported at this time) approach to getting dependency injection to work in JSF, is to extract the wls.jsf.di.jar file from the jsf-1.2.war or jsf-2.0.war files from a WebLogic Server installation, and put it into the WEB-INF/lib directory of the web application, alongside the JSF jars. When the application is deployed, the WeblogicInjectionProvider will be available. This works because the web application initialization code we have, in addition to looking at the shared-library references, also checks to see whether the Faces Servlet -- javax.faces.webapp.FacesServlet -- is configured in web.xml. If so, it sets the InjectionProvider property appropriately on the ServletContext of the web application, delegating the dependency injection operations to the WeblogicInjectionProvider.

A Simple Example

Right, with that explained (hopefully) lets take a look at a simple example in NetBeans.

Here is a Java EE project with two modules: WLS-JSF-EJB-DI-WEB and WLS-JSF-EJB-DI-EJB:

In WLS-JSF-EJB-DI-EJB there is a single EJB 3.0 stateless session bean defined as follows:

package oracle.com.demo.ejb;

import javax.ejb.Local;

@Local

public interface DateTimeLocal {

    String getCurrentDateTime();

    String getCurrentTime();

    String getCurrentDate();

    int getDateStyle();

    int getTimeStyle();

    void setDateStyle(int style);

    void setTimeStyle(int style);

This purpose of this EJB is to return a formatted string representing the current date and time. The formatting of the date is controlled via the DateStyle and TimeStyle properties.

In the WLS-JSF-EJB-DI-WEB module, there is a single DateTimeManagedBean class, annotated with @ManagedBean (no faces-config.xml here!) and a single JSF facelet that uses the Managed Bean to displays the formatted date and time. It also allows the user to change the formatting, again via the Managed Bean.

The Managed Bean class uses an @EJB annotation to inject an instance of the DateTimeLocal EJB, and then delegates all work to it, in order obtain the appropriately formatted date and time string.

package oracle.com.demo.web.beans;

import javax.ejb.EJB;

import javax.faces.bean.ManagedBean;

import oracle.com.demo.ejb.DateTimeLocal;

@ManagedBean

public class DateTimeManagedBean {

    @EJB

    DateTimeLocal dateTimeEJB;

    public int getDateStyle() {

        return dateTimeEJB.getDateStyle();

    public int getTimeStyle() {

        return dateTimeEJB.getTimeStyle();

    public void setDateStyle(int style) {

        dateTimeEJB.setDateStyle(style);

    public void setTimeStyle(int style) {

        dateTimeEJB.setTimeStyle(style);

    public String getCurrentDateTime() {

        return dateTimeEJB.getCurrentDateTime();

    public String getCurrentDate() {

        return dateTimeEJB.getCurrentDate();

    public String getCurrentTime() {

        return String.format("%s", dateTimeEJB.getCurrentTime());

    public String applyFormats() {

        return "index.xhtml"; //

The index.xhtml facelet uses the Managed Bean to sets and apply the formatting properties and obtain the current date and time in the desired format.

Finally, a weblogic.xml file is provided in the WEB-INF directory that specifies the use of the jsf#2.0 shared-library.

** NetBeans offers great support for WebLogic here. When you add the “JSF Framework” to a project that is configured to run on WebLogic Server, NetBeans automatically offers you the choice of JSF implementations it is aware of on the server and generates the weblogic.xml file. It will also transparently deploy the specified JSF shared-library to the target WebLogic Server domain if it is not already deployed.

When deployed to WebLogic Server 10.3.4, the resulting page looks like this:

Changing the format properties and applying them, the Managed Bean gets updated, which in turn makes the changes on the DateTimeLocal EJB, which ultimately returns the date and time in the specified format:

This simple application demonstrates the successful use of JSF with a Managed Bean, which injects and uses an EJB 3.0 stateless session bean.

I creates this sample application to assist an OTN question that was asked – the project can be be downloaded from here: http://bit.ly/wlsjsfejb.

Using the “weblogic” prefix with the WebLogic Maven Plugin

2011-02-25T15:44:00.001+10:30

The documentation for the WebLogic Maven Plugin describes a technique whereby the goals exposed by the plugin can be called using the short name (or prefix) weblogic.

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13702/maven_deployer.htm#DEPGD383

This means that instead of calling a goal using this form:

$ com.oracle.weblogic:weblogic-maven-plugin:help

You can use the much more convenient form of:

$ weblogic:help

Sounds great. However there is a documentation bug (logged and fixed for next release) which misses out one crucial step in the process.

After extracting the pom.xml file from weblogic-maven-plugin.jar and editing it to specify the <build> configuration that maps the plugin goalPrefix as weblogic;

And before you issue the “mvn install:install-file –Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xml”;

You first need to execute a simple “mvn install” command in the directory in which the pom.xml file resides;

Then you use the “mvn install:install-file ….” goal to install the weblogic-maven-plugin.jar file.

Blow by Blow

Let’s recap those steps:

Generate the weblogic-maven-plugin.jar using the MW_HOME/wlserver_10.3/server/lib/wljarbuilder.jar file.
Extract the pom.xml file from weblogic-maven-plugin.jar and copy/move it into the current working directory:

$ jar xvf weblogic-maven-plugin.jar META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml

$ mv META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml .
Edit both ~/.m2/settings.xml and pom.xml to add the entries as described in the documentation:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13702/maven_deployer.htm#BABGICBH
Execute “mvn install” to initially configure the plugin in the Maven repository:

$ mvn install

** Extra info: if you look at the ~/.m2/repository/com/oracle/weblogic directory, you should now see a file called maven-metadata-local.xml in which the weblogic-maven-plugin is defined and mapped to the prefix weblogic. If you neglect this step, then this file is not created and the weblogic-maven-plugin is not able to be accessed using the weblogic prefix.
Execute “mvn install:install-file” to install the weblogic-maven-plugin.jar file into the repository, using the pom.xml to supply the coordinates:

$ mvn install:install-file –Dfile=weblogic-maven-plugin.jar –DpomFile=pom.xml

With that one extra step done you should now be able to execute a weblogic-maven-plugin goal simply using the weblogic prefix.

I find a quick test using weblogic:help is the easiest way to verify it is working correctly:

Not working?

It’s crucial that the additional “mvn install” step is performed before you install the actual weblogic-maven-plugin.jar library for this to work.

If you have installed the weblogic-maven-plugin as documented and either now want to use the short-name or tried the short-name and it didn’t work, then what I’d suggest is that you blow away the ~/.m2/repository/com/oracle directory and start again from scratch. That should get you a clean install in which the weblogic prefix is mapped correctly to the weblogic-maven-plugin.

WebLogic Schema Files

2011-02-22T11:25:00.001+10:30

If you are looking for the location of the public hosted schema files for WebLogic Server 10.3.x, here is is a starting link, select the version you are interested in: http://xmlns.oracle.com/weblogic/index.html.

Note: due to the recent OTN conversion to a different content management system, this may now be subjected to a redirection.



$ wget http://xmlns.oracle.com/weblogic/index.html

--2011-02-22 11:17:26--  http://xmlns.oracle.com/weblogic/index.html

Resolving xmlns.oracle.com... 141.146.9.91

Connecting to xmlns.oracle.com|141.146.9.91|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://www.oracle.com/technology/weblogic/index.html [following]

Using Secure Config Files with the WebLogic Maven Plugin

2011-02-21T12:44:00.008+10:30

WebLogic Server has long had a mechanism to provide a more secure way of connecting to the Administration Server from client utilities such that the username and password do not need to be specified and therefore can’t be seen from the process list or command shell history.

This secure config authenticaiton mechanism works by first storing the username and password in encrypted form in an external file, and then using this later as the input credential with which to connect to the WebLogic Server domain, along with the key that was used to encrypt the file.

** From a security perspective, controlling access to these files is vital since they permit connection access to the server, but that’s not the focus of this blog.

Securing Access from WLST Online:
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13715/using_wlst.htm#i1092142

Utility weblogic.Deployer, User Credential Arguments:
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13702/wldeployer.htm#DEPGD325

WLST, storeUserConfig Command:
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13813/reference.htm#WLSTC428

WLST, Connection Examples:
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13813/reference.htm#WLSTC157

This security mechanism is particularly interesting with the use of WebLogic Maven Plugin.
In order to connect to the Administration Server to perform the desired deployment operation, the weblogic-maven-plugin must supply valid credentials. For quick and simple cases, this is typically done by specifying the username and password directly in the Maven pom.xml file.

Here is an example:

<project>

...

  <properties>

  <weblogic.adminurl>t3://localhost:7001</weblogic.adminurl>

  <weblogic.user>weblogic</weblogic.user>

  <weblogic.password>welcome1</weblogic.password>

  </properties>

...

  <plugin>

    <groupid>com.oracle.weblogic</groupid>

    <artifactid>weblogic-maven-plugin</artifactid>

    <version>10.3.4</version>

    <configuration>

      <adminurl>${weblogic.adminurl}</adminurl>

      <user>${weblogic.user}</user>

      <password>${weblogic.password}</password>

      <source>

${project.build.directory}/${project.build.finalName}.${project.packaging}

      </source>

      <name>${project.build.finalName}</name>

    </configuration>

  </plugin>

...

</project>

As can be clearly seen, this results in the username and password entries being stored in clear-text form in the pom.xml file.

To avoid this password exposure, it would be ideal if the secure connection mechanism described above could be used, replacing the clear text username and password entries with the respective external userConfig and userKey files that specify the credentials that are used to perform the connection.

The documentation for the WebLogic Maven Plugin doesn’t explicitly describe this as a connection option for any of the goals it exposes:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13702/maven_deployer.htm#BABFHAID

But it does contain a reference to the weblogic.Deployer guide for additional usage information:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13702/wldeployer.htm#g1048318

Which in turn, does support the use of the userconfigfile and userkeyfile parameters to specify the connection credentials:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13702/wldeployer.htm#i1024421

Looking at the Mojo classes in the weblogic-maven-plugin.jar file, which implement the goals exposed by the plugin, we can see that there is support for all these additional properties being set on the Mojo by Maven:

public class weblogic.tools.maven.plugins.DeployerMojo extends weblogic.tools.maven.plugins.BaseMojo{

java.util.List flags;

  protected boolean failonerror;

  protected java.lang.String adminurl;

  protected java.lang.String user;

  protected java.lang.String password;

  protected java.lang.String userConfigFile;

  protected java.lang.String userKeyFile;

  protected boolean advanced;

  protected boolean debug;

  protected boolean examples;

  protected boolean help;

  protected boolean noversion;

  protected boolean nowait;

  protected boolean purgetasks;

  protected boolean remote;

  protected java.lang.Integer timeout;

  protected boolean verbose;

  protected boolean version;

  protected boolean external_stage;

  protected boolean stage;

  protected java.lang.String id;

  protected java.lang.String name;

  protected boolean nostage;

  protected java.lang.String source;

  protected java.lang.String targets;

  protected java.lang.Integer retiretimeout;

  protected java.lang.Integer rmiGracePeriod;

  protected java.lang.String action;

  protected boolean upload;

  protected java.lang.String plan;

  protected java.lang.String planversion;

  protected boolean adminmode;

  protected java.lang.String appversion;

  protected boolean graceful;

  protected boolean ignoresessions;

  protected java.lang.String securityModel;

  protected boolean isLibrary;

  protected java.lang.String libSpecVer;

  protected java.lang.String libImplVer;

  protected java.lang.String submoduletargets;

  protected boolean usenonexclusivelock;

  protected boolean allversions;

  protected boolean enableSecurityValidation;

  protected java.lang.String deleteFiles;

  public weblogic.tools.maven.plugins.DeployerMojo();

  public void execute() throws org.apache.maven.plugin.MojoExecutionException;

  protected java.lang.String[] getArgsRedeployer(java.util.List);

Therefore to use this more secure connection approach, it should be a simple case of creating and storing the relevant userconfig and userkey files using WLST, and referencing them in the Maven pom.xml file, right?

The answer to this is, yes, but …

It turns out we have a very minor bug that prevents this from working in WLS 10.3.4. The bug number is 10382796 for reference. It has already been fixed for the next release of WLS. Should you wish to use this secure connection mechanism, I’d suggest opening a support TAR, referencing the bug number and asking for a backport of the bug fix.

Having access to the bug fix, I can walk through the steps required to configure and use this connection mechanism and show it in operation.

1. Create the userConfigFile and userKeyFile from the weblogic.WLST utility

This is a straight forward step and is well documented in the links shown above.

Connect to the running WebLogic Server domain using WLST and issue the storeUserConfig command, specifying the locations of the userConfig and userKey files that will be generated:

>storeUserConfig(‘/tmp/wls.config’,’/tmp/wls.key’)

In this case, we have created the files as ‘/tmp/wls.config’ and ‘/tmp/wls.key’.

We can validate these files work correctly using the weblogic.Deployer utility to connect to the WebLogic Server domain, using the userconfigfile and –userkeyfile parameters:

$ java weblogic.Deployer -adminurl t3://localhost:7001 -userconfigfile /tmp/wls.config -userkeyfile /tmp/wls.key –listapps

2. Install WebLogic Maven Plugin and Crypto Library into Maven Repository

Summary of steps in this section: in order to use the WebLogic Maven Plugin from Maven, it needs to generated from a WebLogic Server installation, then installed into the local repository. Furthermore, to use the secure config file connection mechanism, an additional library must also be installed into the repository to support the encryption operations. This must be manually installed first, then added as dependency of the weblogic-maven-plugin via its pom.xml. Finally, the weblogic-maven-plugin.jar file is installed.

Install Dependency crytpo.jar into Maven Repository

The <MW_HOME>/modules/crypto.jar is required to support the use of the secure config file connection mechanism by the weblogic-maven-plugin. It must be installed into the Maven repository first.

$ cd <MW_HOME>

$ cd modules

$ mvn install:install-file -Dfile=cryptoj.jar -DgroupId=com.oracle.cryptoj -DartifactId=cryptoj -Dversion=1.0 -Dpackaging=jar

Generate weblogic-maven-plugin.jar and extract pom.xml

To generate the weblogic-maven-plugin and its pom.xml file, follow steps 1, 2 from the documentation:

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13702/maven_deployer.htm#DEPGD379

$ java -jar wljarbuilder.jar -profile weblogic-maven-plugin

$ jar xvf weblogic-maven-plugin.jar META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml

$ mv META-INF/maven/com.oracle.weblogic/weblogic-maven-plugin/pom.xml .

** It is important that the pom.xml file be available in the directory in which wewill invoke the first “mvn install” command shown below. The easiest way to do this is as shown above, copy/move it into the same directory as the weblogic-maven-plugin.jar file so all the files we will work with are located together.

Edit pom.xml to specify cryptoj dependency and goalPrefix

There are two changes that need to be made to the pom.xml file. The first change is to add the cryptoj library as a dependency to the weblogic-maven-plugin. The second is to add a configuration section to allow the use of the shortname weblogic to invoke the Maven goals.

Here is the final pom.xml with changes at lines [16-22] and [24-35]:

   1:  <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

   2:    <modelVersion>4.0.0</modelVersion>

   3:    <groupId>com.oracle.weblogic</groupId>

   4:    <artifactId>weblogic-maven-plugin</artifactId>

   5:    <packaging>maven-plugin</packaging>

   6:    <version>10.3.4</version>

   7:    <name>Maven Mojo Archetype</name>

   8:    <url>http://maven.apache.org</url>

   9:    <dependencies>

  10:      <dependency>

  11:        <groupId>org.apache.maven</groupId>

  12:        <artifactId>maven-plugin-api</artifactId>

  13:        <version>2.0</version>

  14:      </dependency>

15:

  16:      <!-- Dependency on cryptoj library -->

  17:      <dependency>

  18:        <groupId>com.oracle.cryptoj</groupId>

  19:        <artifactId>cryptoj</artifactId>

  20:        <version>1.0</version>

  21:      </dependency>

  22:    </dependencies>

23:

  24:    <!-- Use weblogic goalPrefix -->

  25:    <build>

  26:      <plugins>

  27:        <plugin>

  28:          <artifactId>maven-plugin-plugin</artifactId>

  29:          <version>2.3</version>

  30:          <configuration>

  31:             <goalPrefix>weblogic</goalPrefix>

  32:          </configuration>

  33:        </plugin>

  34:      </plugins>

  35:    </build>

  36:  </project>

Install weblogic-maven-plugin

Now we want to actually install the weblogic-maven-plugin into the Maven repository. There are two install commands that are issued here, which both need to be followed. The first command implictly uses the edited pom.xml file and configures the weblogic-maven-plugin inside the Maven repository. The second command performs the actual installation of the weblogic-maven-plugin library into the Maven repository.

** Ensure the pom.xml file we have edited is in the directory in which you will execute the commands.

$ mvn install

$ mvn install:install-file -Dfile=weblogic-maven-plugin.jar -DpomFile=pom.xml

We should see output from these commands as shown in the screencaps below:

3. Configure pom.xml to use secure config file for authentication

Now that the secure configuration files have been generated, the cryptoj dependency and the oracle-maven-plugin installed into the Maven repository, we can configure your Maven pom.xml file to use them to connect to the WebLogic Server domain.

Instead of using the <username> and <password> elements as part of the weblogic-maven-plugin <configuration> stanza to specify the connection credentials, we use the <userConfigFile> and <userKeyFile> elements and point to the location of the files we generated from WLST earlier.

A fully configured Maven pom.xml for a Java EE 5 Web application is shown below.

Lines [13-18] shows the creation of properties that identify the location of the relevant external files we generated from WLST.

Lines [67-69] shows the use of the <userConfigFile> and <userKeyfile> elements to specify the use of the secure config file authentication model.

Example pom.xml:

   1:  <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

   2:    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

   3:    <modelVersion>4.0.0</modelVersion>

4:

   5:    <groupId>sab.demo.maven</groupId>

   6:    <artifactId>webapp</artifactId>

   7:    <packaging>war</packaging>

   8:    <version>1.0-SNAPSHOT</version>

9:

  10:    <name>webapp JEE5 Webapp</name>

  11:    <url>http://maven.apache.org</url>

12:

  13:    <!-- weblogic-maven-plugin properties -->

  14:    <properties>

  15:      <weblogic.adminurl>t3://localhost:7001</weblogic.adminurl>

  16:      <weblogic.configfile>/tmp/wls.config</weblogic.configfile>

  17:      <weblogic.keyfile>/tmp/wls.key</weblogic.keyfile>

  18:    </properties>

19:

  20:    <dependencies>

21:

  22:      <dependency>

  23:        <groupId>javax.servlet</groupId>

  24:        <artifactId>servlet-api</artifactId>

  25:        <version>2.5</version>

  26:        <scope>provided</scope>

  27:      </dependency>

28:

  29:      <dependency>

  30:        <groupId>javax.servlet.jsp</groupId>

  31:        <artifactId>jsp-api</artifactId>

  32:        <version>2.1</version>

  33:        <scope>provided</scope>

  34:      </dependency>

35:

  36:      <dependency>

  37:        <groupId>junit</groupId>

  38:        <artifactId>junit</artifactId>

  39:        <version>3.8.1</version>

  40:        <scope>test</scope>

  41:      </dependency>

42:

  43:    </dependencies>

44:

  45:    <build>

  46:      <plugins>

  47:        <plugin>

  48:          <groupId>org.apache.maven.plugins</groupId>

  49:          <artifactId>maven-compiler-plugin</artifactId>

  50:          <version>2.0.2</version>

  51:          <configuration>

  52:            <source>1.5</source>

  53:            <target>1.5</target>

  54:          </configuration>

  55:        </plugin>

56:

  57:      <plugin>

  58:          <groupId>com.oracle.weblogic</groupId>

  59:          <artifactId>weblogic-maven-plugin</artifactId>

  60:          <version>10.3.4</version>

  61:          <configuration>

  62:              <adminurl>${weblogic.adminurl}</adminurl>

  63:              <!--

  64:              <user>${weblogic.user}</user>

  65:              <password>${weblogic.password}</password>

  66:              -->

  67:              <!-- Use external connection files -->

  68:              <userConfigFile>${weblogic.configfile}</userConfigFile>

  69:              <userKeyFile>${weblogic.keyfile}</userKeyFile>

  70:              <source>

  71:                  ${project.build.directory}/${project.build.finalName}.${project.packaging}

  72:              </source>

  73:              <name>${project.build.finalName}</name>

  74:          </configuration>

  75:       </plugin>

76:

  77:      </plugins>

78:

  79:      <finalName>webapp</finalName>

  80:    </build>

  81:  </project>

Verify it Works

With all configuration and installation tasks performed, we can now verify that the weblogic-maven-plugin can successfully connect to the WebLogic Server domain.

To do this, I typically use the weblogic:list-apps goal – this doesn’t perform any deployment operation, but does connect to the target server, authenticates, and returns a list of the currently deployed applications.

The output from executing weblogic:list-apps is shown below. Note the [INFO] output which shows the underlying weblogic.Deployer command that is issued, in which the –userconfigfile and –userkeyfile parameters are used:

$ mvn weblogic:list-apps

[INFO] Scanning for projects...

[INFO]

[INFO] ------------------------------------------------------------------------

[INFO] Building webapp JEE5 Webapp 1.0-SNAPSHOT

[INFO] ------------------------------------------------------------------------

[INFO]

[INFO] --- weblogic-maven-plugin:10.3.4:list-apps (default-cli) @ webapp ---

weblogic.Deployer invoked with options:  -noexit -adminurl t3://localhost:7001 -userconfigfile /tmp/wls.config -userkeyfile /tmp/wls.key -listapps

wls-rest

jersey-bundle [LibSpecVersion=1.1.1,LibImplVersion=1.1.5.1] <ACTIVE VERSION>

jsr311-api [LibSpecVersion=1.1.1,LibImplVersion=1.1.1] <ACTIVE VERSION>

ops-ear

webapp

jackson-jaxrs [LibSpecVersion=1.0,LibImplVersion=1.1.1] <ACTIVE VERSION>

jettison [LibSpecVersion=1.1,LibImplVersion=1.1] <ACTIVE VERSION>

jackson-core-asl [LibSpecVersion=1.0,LibImplVersion=1.1.1] <ACTIVE VERSION>

jackson-mapper-asl [LibSpecVersion=1.0,LibImplVersion=1.1.1] <ACTIVE VERSION>

Number of Applications Found : 9

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 6.150s

[INFO] Finished at: Mon Feb 21 12:31:22 CST 2011

[INFO] Final Memory: 12M/81M

[INFO] ------------------------------------------------------------------------

Summary

In this post, I’ve shown how the the WebLogic Maven Plugin can support the use of secure config files to prevent the need to specify administrator passwords in clear text in the Maven pom.xml.

I would like to again note that there is a very minor known bug that prevents this being used with the WLS 10.3.4 release, which has already been fixed in the next release code line.

If you are wanting to use this feature and need to get a patch, the bug to refer to is #10382796.

Using JAX-RS with WebLogic Server 10.3.4

2011-02-11T13:45:00.003+10:30

There's been a flurry of blogs recently about using JAX-RS.

It may have slipped under the radar a little, but WebLogic Server 10.3.4 now also provides support for deploying applications that use JAX-RS Web Services.

Here's the documentation for it:

Programming RESTful Web Services

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13734/rest.htm#WSADV550

With WebLogic Server, the JAX-RS support is handled in the same manner as JSF, in that a set of optional shared-libraries are provided that can be deployed to the server, which makes the JAX-RS framework available for deployed applications to use. Applications then reference these shared-libraries using the relevant weblogic deployment descriptor.

What I'd like to do in this blog is to show JAX-RS working on WebLogic Server 10.3.4 and at the same time, how the NetBeans 7.0 Beta release supports WebLogic Server to make the development of JAX-RS based applications quick and efficient by removing some of the work required in deploying and referencing the libraries. .

1. Launch NetBeans and register a WebLogic Server 10.3.4 instance.

I won't go through the individual steps as this is very straight forward. In my particular case, I have a brand new domain I am using, so there are no applications or shared-libraries deployed.

2. Create a new Java EE Web project

The next step is to create a new Java EE Web project using the NetBeans project wizards. This project will host our JAX-RS resource and is what we will deploy and test on WebLogic Server.

Create a new Java Web Project and fill in the project details.

For the Server, I specify the WebLogic Server domain that I registered earlier, leave the Context-Path and finish the project creation and click finish to create the new project.

3. Add a JAX-RS resource to the project.

With the Java Web project created, I can now add a new JAX-RS resource to it, again using a NetBeans wizard -- the simplest way to test this is to use the "RESTful Web Services from Patterns" wizard and select the "Simple Root Resource"option.

Select the “Simple Root Resource” option.

Fill in the details for the resource to be created. In this case, I am specifying a MIME Type of "text/html" to make the default end point easy to test from a browser.

On the last page of the wizard, I am presented with options for how to configure the project. NetBeans has knowledge of how WebLogic Server employs JAX-RS and presents them to you.

I select the option to have NetBeans automatically configure the JAX-RS servlet adapter in web.xml and then I select the "Use server bundled Jersey Library" option.

The JAX-RS resource is then created and added to the project.

Looking at the project, I can see a number of things have changed:

The existing web.xml descriptor has been modified to expose the Jersey Servlet adapter.

A new weblogic.xml deployment descriptor has been added, which references the required JAX-RS shared-library that will be deployed on the server.

And a new class has been added that represents the JAX-RS resource.

After editing the generated getHtml method to return a string I'll recognize, the project is ready to be deployed and tested.

4. Deploy and run the project

Selecting "Run" from the project menu, NetBeans will perform the task of compiling and deploying the project to the target WebLogic Server domain.

NetBeans performs the necessary deployment operations.

Now the interesting thing that happens as part of this "run" process (and why it takes 27 seconds most likely) is that NetBeans has recognized that the target WebLogic Server domain doesn't have the necessary shared-library that the project is using. To resolve this problem, it seamlessly deploys the required library from the $WL_HOME/common/deployable-libraries directory as part of the deployment process.

Once the deployment of the project has completed, looking at the registered WebLogic Server domain, I can now see the jersey-bundle#1.1.1@1.1.5.1 library present on the server.

We can now test the JAX-RS resource.

5. Test the JAX-RS Resource

Expanding the project, there is a "RESTful Web Services" folder that presents a view of the JAX-RS resources in the project. To test the end-point, I select the method and click the "Test Resource URI" option.

This opens a browser window and shows the results of successfully calling the getHtml method.

So there you have it, a JAX-RS resource created in NetBeans, deployed and running on WebLogic Server 10.3.4.

As a final piece to add to this blog, I'll also show off another new feature that NetBeans 7.0 has added to further support WebLogic Server. The new "local deployment" model deploys applications from an exploded, local directory. This means that deployment to WebLogic Server is now much better since a code change doesn't require a full packaging and "deployment" cycle to test. In fact, using NetBeans with WebLogic Server nows offer compile-on-save and test functionality!

6. Add another method and test

With the application deployed, I can now change the class to add more functionality. I'll add two new methods that sayHello and sayBye to a user. In these methods, I'll use the @PathParam and @QueryParam annotations respectively to extract the value from the URI and set it automatically on the method call.

To test these new methods, all I need to do is save the change, NetBeans automatically compiles the class and I can immediately test if from the browser, without needing to issue a redeployment operation!

First off, let's say hello. I use the path variable here to to specify my name:

http://localhost:7001/wls-rs-demo/resources/TestResource/hello/steve

Then I'll say goodbye, this time using a query parameter to specify my name:

http://localhost:7001/wls-rs-demo/resources/TestResource/bye?name=steve

And that's all there is to getting a basic JAX-RS resource up and running on WebLogic Server, developed and deployed in next to no time using NetBeans 7.0.

Installing NetBeans 6.9 Fails when XCode is Running

2010-06-28T14:06:00.000+09:30

I've been trying to install the NetBeans 6.9 official release (netbeans-6.9-ml-java-macosx.dmg) but it kept on failing during the "Preparing Installation" phase. No detailed errors were shown other than a generic statement to contact my software vendor.

Turned out, at least on my MacBook Pro, that the cause seemed to be that XCode was running at the same time. As soon as I quit from XCode and ran the NetBeans installer from the same installation package, it worked without any problems and installed NetBeans successfully.

Don't know if this is isolated to NetBeans or more generally to the installer technology used on the Mac, but it seems that there was some contention with Xcode, which resulted in the installer not working.

Dynamically Setting JAVA_HOME on Mac OS X

2010-06-24T16:26:00.000+09:30

This was a new discovery to me today, so please ignore if this is widely used and known.

On Mac OS X, there is a very specific, managed directory structure for the various Java versions that are installed. The general directory is "/System/Library/Frameworks/JavaVM.framework/". For those of us new to Mac OS X, the sub-directories under there look a little foreign.

To run WLS, you need to set JAVA_HOME to the appropriate directory before you can start a domain. Hardcoding the directory into either .bashrc or the startWebLogic.sh scripts does the trick.

But today I stumbled on another little utility that can be used to dynamically determine the current JAVA_HOME, as set in the user preferences:

NAME
       java_home - return a value for $JAVA_HOME

SYNOPSIS
       /usr/libexec/java_home [options]

DESCRIPTION
       The  java_home  command  returns  a path suitable for setting the JAVA_HOME environment variable.  It
       determines this path from the user's preferred Java in the Java Preferences application.   Additional
       constraints may be provided to filter the list of JVMs available.  By default, if no constrants match
       the available list of JVMs, the default order is used.  The path is printed to standard output.

Thus setting JAVA_HOME dynamically in scripts, shell profiles can be done simply like this:

export JAVA_HOME=`/usr/libexec/java_home`

NetBeans 6.9 Released

2010-06-21T15:42:00.000+09:30

I've been using NetBeans 6.8 quite a bit lately to explore new functionality in Java EE 6.

Just noticed on the weekend (somewhat belatedly) that their latest 6.9 version has been finalized and released. At a measly 178mb for the core IDE with Java EE 6 support and an embedded GlassFish v3.0.1 server for the dev/test runtime, it sounds like a download well worth making.