Is fragment bundle supported in servicemix?

[mike.ramnarine]

Posted for Daisy (moved from email) ..

Hi,

I am trying to create FTP fragment bundle and to test it with its host bundle, cxf bundle. 

Does servicemix support fragment bundle? It seems felix doesn't support fragment bundle yet. Please see this JIRA for details:

http://issues.apache.org/jira/browse/FELIX-29

We tried to use fragment/host bundle mechanism to solve CXF extensors discovery issues. Basically we have problem with how CXF can discover extensors from osgi container. If fragment bundle is not supported, are there other options?

Thanks,

Daisy

[mike.ramnarine]

Fragment bundles are attached to a host bundle by the OSGi framework, and are treated as if they are part of the host bundle, including class loading.  See section 3.14 on page 68 of the OSGi 4.1 core specification.

We are attempting to use this mechanism as a way to avoid requiring an update to CXF class loading/lookup to find classes in OSGi bundles.

We have found that Equinox has implemented fragment bundles, and at least one project has used them successfully in Equinox.  But given JIRA FELIX-29 we wonder - does SMX4 support OSGi fragment bundles yet?  And if not, when?

-Mike

[seumas.soltysik]

In the email thread James said:

"I don't understand what a fragment bundle is or why its required for CXF. e.g. can't you just query the OSGi registry to find extensions?

Is a fragment bundle something Felix specific?"

As Mike mentioned, fragments are part of the spec and Equinox is capable of handling fragment bundles. Fragments declare a dependency on another bundle(host) and are then included in the classloader of the host. This feature looks like it provides a simple solution for allowing CXF to discover extensions as it currently does now through its own bundle classloader. This means that there would be need to change any CXF code. If this functionality is not available we would need to change CXF code to discover extensions using the OSGi services framework. If we do go this way then we need to put together a detailed plan for this and get buy in from the CXF folks.

[jstrachan]

I don't understand why extensions need to be in the same class loader as the core? Why not use the OSGi registry?

[seumas.soltysik]

Well the way the CXF loads extensions is that it searches for a spring config file for a component(typically in the META-INF dir of a jar) and then passes the spring config onto an ApplicationContext to load and create classes specified in the config. Therefore the bundle that loads CXF needs to be able to access an extensions spring config file and then it needs access to the extensions classloader to create the beans specified in the class and inject certain CXF elements such as the Bus. So I don't think the registry will help here. It is not just a matter of creating an extension and registering that extension with the service registry and then having CXF internals peruse the registry for CXF extensions. CXF needs to be responsible for creating the extension so that it can inject CXF elements into the extension.

[jstrachan]

Think of it the other way around.

Each extension depends on the Bus and is developed using Spring Dynamic Modules. As each extension bundle is deployed into OSGi, Spring DM will boot up the Spring XML file with the right class loader and inject the Bus into the extension (where it can register itself directly if it wants) - or the Spring XML just registers the extension point into the OSGi registry.

i.e. rather than the Bus having to have every possible extension in the same classloader - let the extensions plugin to the bus - using Spring DM to do all the work

[dkulp_dkulp]

James,

That assumes there is a single Bus for the entire ESB, not a "bus per deployed application".   CXF is designed more around the ideas of the latter, not the former.   A bunch of configuration things and such depend directly on the latter.

Dan

edit.....

This kind of makes me think about the idea we've tossed around about heiarchical busses where busses could have a parent bus that is more global.   Might need to revisit that idea.

Edited by: dkulp on Mar 20, 2008 9:09 PM

[dkulp_dkulp]

The more I keep thinking about it, the more I keep thinking that in the context of the OSGi stuff, the auto discovery stuff that CXF does keeps making less and less sense.   It probably makes more sense to me to do a better job documenting the stuff that you can ) and have users do that in the spring configs for their apps.   (we can make it easier with a generated cxf-all.xml and artix-all.xml for artix that would include everything that would be auto discovered)

More and more I'm seeing people go that route on the CXF dev lists.   It makes a lot sense and actually results in much faster application startup as stuff that ISN'T needed isn't loaded and configured.

In this case, the whole discussion is irrelevant providing the cxf extension xmls are available to the spring loader.

[gnodet_gnodet]

dkulp wrote:

The more I keep thinking about it, the more I keep thinking that in the context of the OSGi stuff, the auto discovery stuff that CXF does keeps making less and less sense.   It probably makes more sense to me to do a better job documenting the stuff that you can <import>   (like <import resource="classpath:META-INF/cxf/cxf.xml" />) and have users do that in the spring configs for their apps.   (we can make it easier with a generated cxf-all.xml and artix-all.xml for artix that would include everything that would be auto discovered)

More and more I'm seeing people go that route on the CXF dev lists.   It makes a lot sense and actually results in much faster application startup as stuff that ISN'T needed isn't loaded and configured.

In this case, the whole discussion is irrelevant providing the cxf extension xmls are available to the spring loader.

+1

It make a bit more work for the user (but not much) and allows more control than relying on the extension discovery mechanism.

[seumas.soltysik]

Dan,

Could you clarify what you are proposing, perhaps with an example. My understanding of your proposal is that we create a spring xml doc which contains all the spring config elements from the various config files that exist in CXF. A user would then import this file into their own spring config file. Is this correct?

So in essence we would be completely by-passing the BusApplicationContext and simply use the ApplicationContext of the OSGi container.

[dkulp_dkulp]

Seumas,

That's exactly it.  

(or just import SOAP + HTTP if that's all you need or just SOAP + JMS, etc...)