Frequently Asked Questions

When launching a jvm, the CLASSPATH normally has an explicit ordering that has a behavior that is analogous to the PATH search order used by Windows and UNIX shells.

XBean depends on the fact that xbean.properties is loaded and merged from the classpath with precedence matching the classpath's ordering. Consider the CLASSPATH a.jar:b.jar and imagine that both a.jar and b.jar contain xbean.properties which defines /Foo.bar. The /Foo.bar definition in a.jar will override that in b.jar because of the explicit ordering of the classpath.

Now, webapps have no such well-defined ordering. The webapp classloader loads all the classes in WEB-INF/classes and WEB-INF/lib in an arbitrary order. How do we ensure that xbean.properties files are processed in a predictable order?

We'll in 90% of cases, we really don't care and there isn't much overriding of properties going on between JARs. However, to accommodate this 10% of cases where this ordering is imporant, XBean honors the priority attribute of xbean.properties. The priority is an integer ordinal upon which all the files are sorted, with lowest number having precendence. This makes it trivial re-order an otherwise arbitrarily ordered classpath, should this become important.

The loading sequence is (from highest to lowest priority):

1. System Properties (i.e. -D parameters passed to jvm)
2. xbean.configpath (i.e. delimited path of URLs/files pointing to properties files)
3. WEB-INF/xbean.properties (when running in webapp)
4. classpath

This means that passing -D/Foo.bar=abc will override any /Foo.bar configuration found in the classpath, WEB-INF/xbean.properties, or the xbean.configpath.

An entry found in a file loaded through the xbean.configpath will override the same property in WEB-INF/xbean.properties and the classpath, but not one passed through System properties.

It is a system property that may be set to tell XBean where to look to find some additional bean configuration. Specifically, it is a comma delimited list of URLs and files that XBean will try to load into its configuration database.

Let's say you start your app with:

 java -Dxbean.configpath=./abc.properties,./def.properties MyMainClass

This would cause the XBean container to try to load ./abc.properties and ./def.properties and merge them into the configuration set.

No, it loads all of the configuration all at once. While there are certain advantages to lazy loading, it causes some serious complications. Non-lazy loading allows:

1. Startup tends to be a bit more deterministic, especially with regard to the webapp contexts.
2. All beans can be known and validated at startup time.
3. It becomes possible to have services start when the container is loaded.

Not yet, though this on the XBean roadmap. XBeans and MBeans would be quite complementary. In fact, this is where I got the name XBean.

Just about anything that passes for a Java object can be exposed as an XBean service. XBean does not have built-in support for these things, though they would be trivial to implement. In keeping with the mission of developing a lightweight microkernel, integration with these things within XBean proper is not currently in the roadmap. However, that may change if/when people decide it is important.

XBean does not implement yet another classloader, quite intentionally. Implementing a custom classloader is the responsibility of the application server, not the XBean microkernel.

The same classloader that is used to load XBean itself.

In an web application server context you should only put j2xtreme-xbean-*.jar in your WEB-INF/lib directory. Loading it from the system classloader or anything delegated up from the webapp classloader is likely to have some interesting consequences. Most notably, global scope will be more-global than your web application, which starts to violate the J2EE security rules for isolating web-applications.

In a standalone context, you can load it out of any classloader you please, but most likely the system classloader.

See the XBean QuickStart Guide for an explanation.

Thread scope begins implicitly as soon as a thread-scoped service is requested. There is no need to demarcate the beginning of a thread's scope.

Thread scope ends when either ServiceContext.unbindThread() is invoked explicity, or the method is invoked by the XBean servlet filter.

Use the ServiceContext.addLostScopeListener() method. This method allows you to register interest in a particular service. When it goes out of scope, the lostScope() method of the listener that you registered will be invoked.

For convenience's sake, the XBean container will automatically register an XBean Service if it happens to implement the LostScopeListener interface.

No, not really, except that an XBean service that is "in scope" is guaranteed not to be garbage collected. The converse is not necessarily true.

XBean scope is really the scope of the name-to-service-instance mapping, not the service itself.

In most usage they should be quite similar. An XBean service with global scope will have the same lifecycle as a singleton java object loaded from within a web application. A bean with application scope will have the same lifecycle as an object that is stuffed in the ServletContext attribute pool.

In fact, in the current implementation, this is how each of these is stored.

So the short answer is, read the Servlet spec to understand the interaction between the webapp and classloader.

Never fear, just about anything can be exposed as an XBean Service. In fact, the XBean container exposes HttpServletRequest and friends which aren't even managed by the XBean container!

To accomplish this (to expose Foo, which has no public no-arg constructor), you need to do a few things:

1. Implement com.j2xtreme.xbean.ServiceFactory for the class you are intending to expose. This interface defines two rather self-explanatory methods that must be implemented. You can name it FooServiceFactory for clarity, though it doesn't matter what you name it.
2. Expose the ServiceFactory that you defined as a named XBean Service. That means writing a service entry in xbean.properties for FooServiceFactory. We will call it /FooServiceFactory for simplicity.
3. In the service definition for the instance of Foo that you wish to epose (call it /Foo, you set a special property, $factory and point it to the service factory. That is: /Foo.$factory=xbean:/FooServiceFactory.

Now, when you request /Foo, instead of trying to instantiate a configure a JavaBean, the XBean container will resolve your designated ServiceFactory and use it to obtain and expose the service.