Handler Chains: New schema namespace and root node

There's been a change in what is accepted for a handler chain XML file within OEPE, and possibly the WLS runtime libraries.

It used to be accepted to use http://www.bea.com/ns/weblogic/90" for the default namespace but you'll need to start using: java.sun.com/xml/ns/javaee

Also the root node needed for handler chain files needs to be: handler-chains instead of the old weblogic-wsee-clientHandlerChain.

Just to be clear here is an old example file:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-wsee-clientHandlerChain
xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</weblogic-wsee-clientHandlerChain>


And the newer one:

<?xml version="1.0" encoding="UTF-8"?>
<handler-chains
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee">
<handler>
<j2ee:handler-name>clienthandler1</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler1
</j2ee:handler-class>
<j2ee:init-param>
<j2ee:param-name>ClientParam1</j2ee:param-name>
<j2ee:param-value>value1</j2ee:param-value>
</j2ee:init-param>
</handler>
<handler>
<j2ee:handler-name>clienthandler2</j2ee:handler-name>
<j2ee:handler-class>
helloservice.ClientHandler2
</j2ee:handler-class>
</handler>
</handler-chains>

JAXB reference implementation and MOXy

JAXB is an important part of JAX-WS web services. It provides object to XML mapping and the reverse.

In OEPE, a wizard using WLS ant scripts has been used for the last two plus years to create JAXB types using Glassfish libraries. Glassfish is the reference implementation Java EE server (currently version 3).

The reference implementation (RI) for JAXB resides under Metro, the web services stack within Glassfish.

Since the JAXB RI under Metro provides great basic functionality for JAXB marshalling/unmarshalling of types and not a lot of add-on features/extensions, there are further implementations that can be used.

One resides under the EclipseLink persistent services framework and it's called MOXy.

MOXy provides support for mapping between schema and Java types, more specialized JPA mapping support and some better performance, to name a few features.

Here's a link below:

http://wiki.eclipse.org/EclipseLink/FAQ/WhatIsMOXy

JSF message bundles and locales

Java Server Faces supports localization or internationalization (I18N). You choose the term. I find them to be synonymous terms and will use them interchangeably.

If you want to split hairs go here:

http://www.w3.org/International/questions/qa-i18n

I18N allows you to accomodate your software to different languages whether it be English, German or Chinese; thereby supporting web clients around the world.

One easy way to make JSP localization work is use it in a JSF enabled dynamic web project inside an OEPE enabled Eclipse IDE.

You'll need to update the faces-config.xml file, adding properties files that you've made and locales that you support.

Here's a faces-config.xml file example:

<faces-config version="1.2">
<application>
<message-bundle>resources.application</message-bundle>
<message-bundle>resources.Greeting_fr</message-bundle>
<message-bundle>resources.Greeting_en</message-bundle>
<message-bundle>resources.Greeting_de</message-bundle>
<locale-config>
<default-locale>en</default-locale>
<supported-locale>fr</supported-locale>
<supported-locale>de</supported-locale>
</locale-config>
</application>
</faces-config>

Each message-bundle element tag lists a language locale property file. In my case I put the properties files under src/resources. Note that the properties files listed inside the message-bundle tags don't come with *.properties file extension. It's implied.

Under locale-config I place supported languages. In my case I have English, French and German. My default is English.

The great thing about OEPE is the ability to add message-bundle and locale-config elements to the faces-config.xml file by using the Faces Configuration Editor. You can easily add new languages that are supported and browse for new language message bundles.

When I do want to use message bundles I can test it with the loadBundle tag and outputFormat tags inside a JSF enabled JSP page.

Here's an excerpt from the JSP page:

<f:loadBundle basename="resources.Greeting" var="greeting1" />
<h:outputFormat value="#{greeting1['login']}">
<f:param value="Joe"></f:param>
<f:param value="05/19/2010"></f:param>
</h:outputFormat>
<h:outputFormat value="#{greeting1['welcome']}"></h:outputFormat>

Note that I specify "resources.Greeting" for basename.

The first part before the dot is the folder and the second half means all the Greeting_*.properties files.

My properties files are:

1) Greeting_de.properties
2) Greeting_en.properties
3) Greeting_fr.properties.

I don't need to add the underscore.properties to basename since it's implied, meaning any file will be used for a localized message depending on the client preferred language.

The country will be figured out by what the browser passes to the server. In Internet Explorer I can change my preferred language and see a different message. This is done under Tools > Internet Preferences > General > Languages. I can easily add and rearrange the preferred languages within that Internet Explorer dialog and reload the web page to see the language change on the fly.

Importance of quality, time and features

In an ideal world quality, time and features should be given equal weight in the software development lifecycle. The ranking for most firms it seems is: 1) quality 2) time 3) features. Quality should always be given precedence. If things need to go, due to scheduling, etc..., you need to throw out features first, then time and always try to maintain quality standards. Makes sense and we practice that here too.

Want to upgrade OEPE/Eclipse?

I've been testing upgrade of OEPE from one version to another.

Upgrade might not be as intuitive as for other applications that could be as easy as one-click.

To get the latest/greatest you need to add an upgrade site under Help > Install New Software > Add.

For Galileo builds (which is the latest/greatest that we support) people should use this URL:

http://download.oracle.com/otn_software/oepe/galileo/

Then you can use the Check for Upgrades choice.

One thing that some people might need to do is update their proxy settings under Window > Preferences > General > Network Connections. If I'm behind a firewire I choose Manual and then the URL and port

Hot Swap/Fast Swap on WLS using OEPE

Testing fast swap today using OEPE on WLS server(s).

Part of the day I was wondering if there's a difference in how hot swap works with weblogic-application.xml versus weblogic.xml.

It seemed with some dynamic web projects with a JSP that referenced a POJO fast swap - and fast swap was enabled in the EAR's weblogic-application.xml - messages didn't seem to be logged versus when fastswap was enabled in weblogic.xml in the actual project, they were. Make sense?

Tested fast swap too in debug mode but isn't that kinda redundant? Fast Swap/Hot Swap has been in the debug mode of WLS for a long time right? So how does enabling fast swap when Debug mode essentially hot redeploy?

At least that's my impression from this article:

http://technology.amis.nl/blog/5665/fast-swap-in-weblogic-103-and-jdeveloper-11g-redeploy-after-compile-in-running-application

Lesson learned from testing new Eclipse server adapters?

I work for Oracle. It's a huge company and even bigger now from the Sun acquisition.

There are a multitude of offices around the world and even with offices many people work from home or some other remote location. My team in particular is spread out from Germany to the West Coast of the United States. We inhabit many time zones and face to face collaboration is rare; except for yearly team get-togethers or review periods where I might see my manager or other colleagues. Weekly meetings on the phone are 10 AM my time but for someone in Germany it's 6 PM or on the West Coast it's 9 AM.

When we do have interaction it is limited to phone, web conferencing, IM (whether internal or use of Yahoo IM), and VNC sessions.

We've been currently testing upgrade from one release of OEPE to another. We support many different scenarios for upgrade including server upgrade. Although not a full upgrade compared to other upgrades - because the focus is on server adapters - there are still things that need to be done properly.

Since this was my first foray into testing server adapter upgrade there were some things I needed to learn by asking my more experienced colleague. Knowledge transfer occurred over IM. Unfortunately, there were a couple of steps missing in the initial transfer since after my testing there was an issue that came up.

While testing I thought the server adapter upgrade process was a little too short. I should have listened to my instincts and maybe asked some more questions since I was not doing a full upgrade to our current BETA product.

Things that needed to be done were edit to JAR files under the plugins directory:

1) org.eclipse.wst.server.discovery
2) org.eclipse.wst.server.ui

The specific file that needed to be edited in both was: serverAdapterSites.xml

Extraneous sites needed to be removed and an internal update site for testing needed to overwrite either the Ganymede or Galileo default sites.

Regardless, if you feel your testing is a little too straightforward you might ask yourself if you're going far enough or doing the correct steps for the test to succeed; especially if you're in an isolated environment where some steps that might be easily communicated from face-to-face interaction might easily be lost through newer means of communication.