Posts Tagged ‘java’

Felix and Websphere 7

December 25, 2010

Recently I have ran into issues running Apache’s Felix Project in IBM Websphere 7. When you try and start an embedded Felix OSGi container you get class cast exceptions that classes are not properly matching the interfaces. Specifically I saw that the bundles implementations don’t match BundleActivator interface. Also you could see issues with the “getBundleContext” method not existing on the Bundle class. After some gnashing of teeth I have found the fix for this and its took a little digging so hopefully this will save folks time with the same issue.

The problem…

Websphere 7 (and possibly 6.1+) is including on the classpath org.osgi.core packages which include versions of the interfaces used included in the Felix jars. Also the classes get loaded into the bootstrap classloader which is prefered by Felix when when loading classes. The net result is if you have class loading set to parent first (the default setting) you will see missing methods on interfaces being called, specifically Bundle.getBundleContext. If you have parent last classloading set you will still see issues and all your bundles will not be able to initialize because of class casting issues on BundleActivator (or maybe other interfaces as well). The casting issues are from classes being loaded from different classloaders, bootstrap verses application, when that happens classes even if they have the exact same methods on them will not properly cast to each other. I believe you’ll see most of your issues in the System Bundles for class casting.

The Solution…

There is a pretty simple two part solution which can be accomplished via no code changes…

  1. Ensure your Felix and related classes are included in your war file or some other class loader ahead of the bootstrap class loader in a ‘parent last’ setting. Generally this means set your Web Application to parent last class loading. If you are loading Felix classes from somewhere else ensure the class loader you are loading them with is a parent last classloader.
  2. Update the org.osgi.framework.bundle.parent configuration to ‘framework’. The easiest way to do this just add that exact property name as a system property with value ‘framework’. By default Felix delegates class loading to the bootstrap class loader overriding the class loading strategy set on the initializing code which is what is causing the class cast exception due to multiple versions of the classes getting loaded.

For more configuration properties available for Felix visit http://felix.apache.org/site/apache-felix-framework-configuration-properties.html

Advertisements

XML4J to Xerces Version

September 22, 2010

I have always thought the fact that IBM packages in their websphere JRE libraries a re-packaging of several xml jars specifically Xerces and Xalan. They call it the XML4J jar (the file name will be xml.jar). You can check out the version of the XML4J which is associated with your IBM JRE by running the following

java  org.apache.xerces.impl.Version

That’s supposed to give you the Xerces version However that’s the XML4J version not the Xerces version. I was able to find on an IBM support forum (http://www.ibm.com/developerworks/forums/thread.jspa?messageID=13919023) which lists out the version mapping. I have place it below as well for folks to see as well.

XML4J Version Xerces Version
3.2.x 1.4.1 + defect fixes
4.0.x 2.0 + defect fixes
4.2.x 2.4 + defect fixes
4.3.x 2.6.2 + defect fixes
4.4.x 2.6.2 + defect fixes
4.5.x 2.8.1 + defect fixes

Keep Your Project Files in the WAR

July 13, 2010

Have you ever created a project and had someone say (maybe that person was yourself) “we better put that file in an external place so I can be changed at runtime just in case”? Chances are if you did and followed through on it without a specific requirement for it then I would be willing to bet you ended up never changing the file at runtime (presuming you have a relatively strict change process at your shop). I have put myself in the same situation many times creating overly complex software which involved many random file system structures external to the central package (in JEE the WAR file) because of the “in case we need it” rationale. I want to convince people that we should stop unless its required.

When you start creating file system dependencies or other dependencies on your code outside the package you are basically trading increased complexity for flexibility. In most cases I have seen this trade off made (outside of requirements) because people are trying to anticipate issues with the code but it actually just heightens the probability for issues in the future because of the increased complexity. It’s not that you won’t code it right the first time but in the future it can and probably will cause confusion and problems with new developers without a lot of extra work. The extra work being creating hooks in the build process, handling potential environment differences, and deployment issues beyond the initial build.

In the end if you have the belief you can code it write in the first place then just code the simplest solution right, don’t over shot the mark. Unless you have a compelling need avoid creating external dependencies on your application.

Think Thread Safety

June 2, 2010

In multi-threaded languages such as Java issues related to thread safety can be the most difficult to debug because they depend on timing during program execution. I would guess that most programmers know about thread safety but they aren’t aware of when they need to be thinking about it. The answer is ALWAYS! Many times they just assume that the framework they are working with will take care of any thread safety concerns but thats not the case. Any time you modify code or are creating new code you need to ask yourself “do I need to be thread safe?”  So why do we get caught is the pitfall today with newer frameworks and how can you tell if your being thread safe?

Pitfall: The Singleton…

With the advent of Spring and lots of other frameworks one of the dominate design patterns is the Singleton. By default for efficiency reasons many frameworks when creating objects, create only one instance that is executed on by all threads calling the code. This means your objects need to be stateless when integrating with many frameworks. For many developers this is tough because we want to make objects with lots of state, or have existing objects with state that we want to integrate into the framework with little to no refactoring. That combined with the fact that the actual call of your method will be wrapped in multiple points of indirection in many cases and it will work when you are testing in the simplest case tricks you into thinking your code is integrating properly when you are not. A through read of documentation in almost all cases for the framework fixes the matter but the reality is most folks learn from tutorials and experience first. Don’t get me wrong thread safety has and will be a concern of great significance whether or not your using singletons, but its one of the major patterns used today making it that much more important.

Thread Safe Or Not?

Now with the pitfall identified, how can you identify what needs to be changed and where possible issues are? Without going into much more detail for some specific situations that won’t be possible and I’ll avoid getting into that amount of detail for post length sake. At least I can provide a general rule you can follow to identify if a class is thread safe and once you have determined when the calling code demands you’ll be able to identify if there is an issue…

If a class has no synchronization and accesses a variable that has state that is not appropriate to share with other executions of the class, then the class is NOT thread safe.

For this rule “variable that has state” would include any variables that can be changed by code external to your class’s methods or changed by the methods internal to the class. This rule ignores usage of execution synchronization to simplify the discussion mainly. Take a look at classes like this and make sure they are being used appropriately and not concurrently by different threads.

Not being thread safe isn’t a bad thing. But when creating or updating existing code, knowing whether you need to create something thread safe or not is the something you always need to take into consideration. If you don’t know if the code calling your code will be calling it in a thread safe fashion STOP and research the callers to determine if you need to be thread safe.

Hidden Gems in Apache Sling

April 12, 2010

One of my favorite open source projects that I’m currently following is Apache Sling. Its a RESTful interface to a Java Content Repository JCR (specifically Apache Jackrabbit out of the box) and also an application framework. I’m less excited about it for the application framework part, but mainly because RESTful content is just that exciting (I’m weird, I know).

Sling is still in the Apache incubator and in my opinion lacking in depth of documentation. Also don’t be fooled into thinking this is a Content Management System, its a system interface into your content which you could build a user interface to manage content on top of. I recently have been doing some searching for additional documentation and peaking around in the source and wanted to expose what I think are two real hidden gems that weren’t easy to find (for me): JSON Query Servlet and JQuery JCR Explorer.

JSON Query Servlet

When you first take a look at Sling you see the ability to be able to request and add specific content nodes RESTfully but no way to query for set of content. This was a real let down because I was interested if  Sling could almost eliminate server side code creation in creating a SOFEA style application. After doing some searching though I found a blog ( http://in-the-sling.blogspot.com/2008/09/how-to-use-json-query-servlet.html ) which detailed the JSON Query servlet which I did not find documentation for on the Sling site.

The query servlet allows you to do xpath or sql like queries on the content repository and get the content back in JSON format. An example xpath query URL would be http://localhost:8080/content.query.json?queryType=xpath&statement=//parentcontentnode/node/*

No install necessary its included within version 5 in the incubator. The drawback is without figuring out access controls it makes your content wide open to anyone who knows your using Sling.

JQuery JCR Explorer Bundle

One of the other things that isn’t included with Sling out of the box is the ability to browse the content repository. You could argue whether or not such a piece of functionality should belong to Sling itself, but it definitely be a nice to have. I looked else where for a quality Open Source JCR Repository explorer. From the explorers I found the best one was an Add-on bundle in the Sling SCM repository at  http://svn.apache.org/repos/asf/sling/trunk/contrib/explorers/jquery. Its a pretty simply jQuery based repository browser which has some issues but overall works well.

To install you’ll need to first build the bundle with maven, ‘mvn package’ should do it. Then start Sling and visit the OSGi administrative interface for the container your running Sling in and install the bundle via the normal process. Once you have installed you’ll have a new ‘explorer’ selector available to visit each piece of content in your JCR. To see the root go to http://localhost:8080/.explorer.html

Should I use Open-Session-In-View?

April 4, 2010

The Open-Session-In-View pattern is a very popular strategy for managing open hibernate sessions  for the duration of a request in a server side java web application (possibly for other technologies as well). Basically the pattern uses a servlet filter to open a session on each request as soon as its received and then on completion of processing closes the session. Some people love it, some hate it, and some just use it because they don’t know what else to do.  As with anything I think that there are times to use it and times when its not appropriate. I want to provide some guidelines which I have found are helpful in understanding when it is appropriate.

I’ll assume you know the problem this pattern solves so we won’t talk about that (check out this link for discussion on that). But we’ll need to at least discuss the major implication of the open-session-in-view which is a database connection open for an entire request then cover the guidelines which fall out of that.

Database Connection Open for the Entire Request

Because the pattern is opening a hibernate session first thing on each request which implies that a database connection could be open for basically the entire request. For the purpose of this discussion we’ll assume that the open session ALWAYS correlates to an open database connection for the entire request. In the default case with many versions of hibernate, an open session doesn’t open a connection until it is needed but lets assume the worst case scenario. This will ensure that the pattern is match for you in all situations.

Problems with Open Sessions

If you have an open session over your entire request which is going to have an open database connection associated with it, the problem is that you will be tying up a database connection which is a limited resource in any setting for work which doesn’t necessarily involve the connection. Unless your in a high traffic application this generally won’t affect you but later I’ll show where it could even without large traffic volumes.

Why Most People Don’t Mind Open Sessions

Now most people probably don’t care about having an open session for the entire request or a database connection because in today’s relational database driven web world in a majority of cases 90+ percent of your overhead in a request time is database word anyways. So an extra 10% of time for a session or database connection is worth the cost to drive down complexity in your application.

Exceptions to the Trade Off

The  exceptions to this trade off hopefully becomes pretty clear, when you have application logic which is going to consume most of the processing time of a request the trade off for driving down complexity loses to excessive session and connection time. In many cases your talking a minority of requests which fall into this trap so overall the trade off is still worth it you just need a couple workarounds. In a high request volume situation which limited resources for hibernate sessions/database connections your open-session-view could become a liability.

Guidelines for Open-Session-In-View Usage

  1. Use it when it only when it drives your code complexity down! This pattern isn’t for all applications. when you have complex database interaction either involving multiple databases or complex transaction strategies, it may not make sense. Or if you don’t have hibernate lazy loading issues happening its probably not useful either.
  2. Use when the session/database connection usage is a HIGH percentage of a request’s processing time already. When looking at each request which involves hibernate session/database access and check to see if thats the vast majority of processing time in the request. If this doesn’t apply then either think about another pattern or creating an exception case for those types of requests via filter or some other means.
  3. Use when the only threat to request time is database access itself. If there is potential for something to go wrong like a HTTP to get hung because not timeout is set then this about creating an exception for those types of requests or think about another pattern.
  4. Use when a HIGH percentage of ALL requests filtered require session/database connection access. If you have an application which a low percentage of requests which come into it need database interaction AND you cannot distinguish these requests via your filter or some other means, then don’t use this pattern.
  5. The pattern is preferably used on lower request volume applications. Just a preference in case you are trying to squeeze application resources.

Examples of Where to Avoid Usage

  1. File upload requests – most cases this isn’t an issue but the right combination of semi-large file and slow client network connection could tie up an open session/database connection for some time. Potentially timing out the database connection.
  2. Requests which trigger Service calls – specifically I’m thinking of web service calls where if the timeout on the socket then if the service becomes unresponsive then you’l potentially time up an open session/database connection. Again potentially timing out the database connection.

OSGi Enabled War

March 25, 2010

If you have ever taken a look at OSGi and thought that it wasn’t going to fit into any of your web applications because of your application server, you may not be out of luck after all. Apache’s Felix project has made a relatively straight forward way of creating an OSGi enabled war file that fits within most applications servers. I’ll go over the basic process and point you to important examples on Felix’s site.

You’ll need to create two projects.

  1. A Bridge War project – this project will manage passing requests back to OSGi (Felix) via a ProxyServlet.
  2. OSGi bundle with Servlet registered – If you already have this skip it but we’ll hit way to register servlets with OSGi.

We’ll start with the Bridge war. You can see a working example on Felix’s site here.

Bridge Dependencies

<dependency>
     <groupId>javax.servlet</groupId>
     <artifactId>servlet-api</artifactId>
     <version>2.5</version>
     <scope>provided</scope>
</dependency>
<dependency>
     <groupId>org.osgi</groupId>
     <artifactId>org.osgi.compendium</artifactId>
     <version>4.0.0</version>
</dependency>
<dependency>
     <groupId>org.apache.felix</groupId>
     <artifactId>org.apache.felix.framework</artifactId>
     <version>1.8.1</version>
</dependency>
<dependency>
     <groupId>org.apache.felix</groupId>
     <artifactId>org.apache.felix.http.proxy</artifactId>
     <version>2.0.4</version>
</dependency>
<dependency>
     <groupId>org.apache.felix</groupId>
     <artifactId>org.apache.felix.http.bridge</artifactId>
     <version>2.0.4</version>
     <scope>provided</scope>
</dependency>
<dependency>
     <groupId>org.apache.felix</groupId>
     <artifactId>org.apache.felix.webconsole</artifactId>
     <version>1.2.8</version>
     <scope>provided</scope>
</dependency>

Special Dependency Handling

Two dependencies mentioned are actually OSGi bundles and need to get copied to the place you’ll load bundles from. Those two dependencies are…

  1. org.apache.felix.webconsole
  2. org.apache.felix.http.bridge

Here an sample of how the example how in maven2 you can get those dependencies copied to a special spot

<plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-dependency-plugin</artifactId>
     <executions>
          <execution>
               <id>copy-bundles</id>
               <goals>
                    <goal>copy-dependencies</goal>
               </goals>
               <configuration>
                    <includeArtifactIds>
                         org.apache.felix.http.bridge,org.apache.felix.webconsole
                    </includeArtifactIds>
                    <stripVersion>true</stripVersion>
                    <outputDirectory>
                         PLACE TO PACKAGE OR LOAD BUNDLES
                    </outputDirectory>
               </configuration>
          </execution>
     </executions>
</plugin>

Ok now that we have the dependencies out of the way here is the coding that needs to be done.

Step One – Create a start up hook to initialize Felix

The simplest place for this is a ServletContextListner.contextInitialized but it just needs to be a place which is guaranteed to be executed before your webapp tries to initialize the ProxyServlet which you’ll configure in step 3. Here is example code of how to initialize Felix.

Properties props = new Properties();
//Load a framework.properties from somewhere accessible to your application server.
//We'll just use the current threads context classloader as an example. Adjust to your situation.
props.load(Thread.currentThread().getContextClassLoader().getResourceAsStream("/framework.properties"));
HashMap<String, Object> map = new HashMap<String, Object>();
for (Object key : props.keySet()) {
map.put(key.toString(), props.get(key));
}
BundleActivator activator = ...//We will talk about this in the next step.
map.put(FelixConstants.SYSTEMBUNDLE_ACTIVATORS_PROP, Arrays.asList(activator));
Felix container = new Felix(map);
//You will probably want to keep a reference to keep the container around to
//be able to stop. Depends on where you binding the lifecycle of Felix to.
container.start();

Step Two – Create a class to load your OSGi Bundles for the war

Here we’ll need to create something that implements BundleActivator for the bridge war. We want to create bundle activator that finds and installs bundles for the war file. I’ll provide one that simply looks on the file system at an external location for *.jar files and assumes they are all OSGi bundles. Check out Felix’s example to see how to load bundles internal to the war packaging.

public final class WebActivator
implements BundleActivator
{
public void start(BundleContext context)
throws Exception
{
ArrayList<Bundle> installed = new ArrayList<Bundle>();
File bundleDir = new File("/path/to/bundles");
File[] bundles = bundleDir.listFiles(new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(".jar");
}
});
for (File file : bundles) {
//Load the bundle. file.toURI().toURL()... can probably be done in an easier way not the  point here though.
Bundle bundle = context.installBundle(file.toURI().toURL().toExternalForm());
installed.add(bundle);
}
for (Bundle bundle : installed) {
bundle.start();
}
}
public void stop(BundleContext context)
throws Exception
{
//Nothing necessary
}
}

Step Three – Update your web.xml with ProxyServlet

Add the ProxyServlet mapping for the Felix bridge. Below is an example which forwards everything to the proxy servlet.

<servlet>
<servlet-name>proxy</servlet-name>
<servlet-class>org.apache.felix.http.proxy.ProxyServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>proxy</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

Step Four – Create a bundle with a servlet in it.

Now you need to create an actual bundle project. I’ll assume you have created a bundle project before, if not check out Felix’s documentation and tutorials. I’ll just point out the basics of how to register your servlet in your new or existing BundleActivator to receive requests. Also I’ll provide the additional dependencies that are needed for you bundle.

Additional Dependencies for a bundle project

<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.http.api</artifactId>
<version>2.0.4</version>
</dependency>

Activator Example

public final class Activator
implements BundleActivator
{
private ServiceTracker tracker;
private CustonActionServlet servlet = new CustonActionServlet();
public void start(BundleContext context)
throws Exception
{
this.tracker = new ServiceTracker(context, ExtHttpService.class.getName(), null)
{
@Override
public Object addingService(ServiceReference ref)
{
Object service =  super.addingService(ref);
serviceAdded((ExtHttpService)service);
try {
//You can map the servlet to any context. This will actually map it to all requests.
((ExtHttpService)service).registerServlet("/", servlet, null, null);
} catch (Exception e) {
e.printStackTrace();
}
return service;
}
@Override
public void removedService(ServiceReference ref, Object service)
{
((ExtHttpService)service).unregisterServlet(servlet);
super.removedService(ref, service);
}
};
this.tracker.open();
}
public void stop(BundleContext context)
throws Exception
{
this.tracker.close();
}
}

If this isn’t making sense take a look Felix’s Example HTTP Servlet and Filter Bundle. This bundle shows also how Felix supports HTTP Filters as well.

Step Five: Build and Run!

Now you have everything in place you simply need to build your bundle then add it to the bundles location where your webapp will be looking for it. Then build your bridge webapp and run it with your favorite appserver.

Additional Notes and Thoughts

First off this is only useful for scenarios where using an application server that doesn’t provide some kind of OSGi integration out of the box. But if you are in a non-OSGi enabled application server you could use this pattern and start Felix in a central location available to all web applications and start integrating services across all applications which where the power in this would be. The trick to this is getting an entire legacy webapp tucked behind the servlet bridge which seems simple enough but there are lots of little issues here and there to work out. I’m working on a porting over several applications using different frameworks, I’ll put up updates if they turn out positive.