JBoss OSGI and Wildfly Alpha 3: in or out?

[ampie]

Thomas, after working through documentation and announcements and stuff, I am still unclear as to whether JBoss OSGI will still be available as a set of modules and a subsystem in Wildfly 8 Alpha 3 +. The documentation packaged with JBoss OSGI 2.0 seems to be assuming the type of integration still available in earlier versions of Wildfly 8, so I'm not sure if it is relevant at all.  More specifically, I am wondering whether we will still be able to use the standard JBoss config files, (e.g. standalone.xml)  to activate JBoss OSGI, and will JBoss OSGI still automatically detect OSGI new bundles and deploy them? If it is still possible to do all of these, how do we go about "reintroducing" the JBoss OSGI subsystem? Where do we get the module directory structure  from? Do we have to do it by hand? Will you be releasing documentation on how to do this any time soon?

Please we urgently need clarity on these issues. These are potential "make or break" issues for quite a long term initiative we are about to embark on and we really need to address these concerns. As I have said before, the extent to which we will be using Redhat technologieson this initiative hinges on these issues, and some solid, well thought through answers would go a long way in doing some damage control. As always your input will be much appreciated.

[ampie]

OK, for those who are interested, I have found some answers. As part of the JBoss OSGI Wildfly  build, the build now generates a zipped patch file that contains the directory structure required for both the "bundles" and the "modules" directories in the wildfly root directory. It also contains a "standalone-osgi.xml" configuration file that activates the osgi subsystem. I gather that this zip file can now be extracted in the root where wildfly was extracted and we can continue as in the past.

I will test my assumption and report back for those who are interested. I will also test my POC against this configuration to see what has changed, if anything.

If you want to generate the patch yourself, git clone https://github.com/tdiesler/jbosgi and do a mvn clean install -Dmaven.test.skip=true from the wildfly directory. The patch will be build as wildfly/build/target/jbosgi-wildfly-build-2.1.0-SNAPSHOT-patch.zip.

[thomas.diesler]

I'll do a jbosgi release that targets 8.0.0.Alpha3 early next week. We had a hickup in nexus that didn't make the 139MB wildfly-distro available for download - this is now fixed. Going forward I plan to keep a steady release cycle going that always targest the latest wildfly release.

[thomas.diesler]

The release is out: JBossOSGi-2.1.0 Released

[uliromahn]

Why isn't this part of the standard Wildfly 8 build / release???

I have just build the latest Wildfly-8.0.0.Beta1-SNAPSHOT and there is no sign of OSGi (except for some osgi libraries in the modules directory)!

Any idea when JBossOSGi will be part of the standard Wildfly 8 distro again?

Thanks and keep up the great work with JBossOSGi.

-Uli

[dlmiles]

It is important for the Wildfly GA release mechanism to receive unit testing from all not-included satellite projects to ensure cohesive compatibility with the GA release.

Over the history of JBoss community AS releases too many things have been broken with the released version, that require custom patches to fix.

[jrantav]

I think it is interesting that Wildfly page claims:

OSGi Core 4.2

WildFly is geared toward OSGi development as much as it is to Java EE.

Thanks to the modular design of the WildFly core, adding OSGi compliance is a natural fit. Not only does WildFly provide OSGi compliance, it also offers integration between the OSGi and Java EE component models.

However, JBOSGi user guide tells us that:

Starting from WildFly-8.0.0.Alpha3, OSGi support is not part of WildFly any more. JBoss OSGi project provides examples, documentation and the subsystem that adds OSGi functionality to WildFly.

How is WildFly geared toward OSGi development when support is no longer part of WildFly?

Maybe WildFly front page should be updated.

[thomas.diesler]

Darryl,

this job runs on a daily basis. It tests the jbosgi master against the latest successful wildfly master build.

[apanday]

Hi,

May I jump a bit late into the discussion?

I'm very new to jboss and I'm trying to figure out how to deploy an OSGi bundle into jboss7 or wildfly (whichever works to start with)

I have downloaded both wildfly-8.0.0.Final and jboss-eap-6.2.0.GA, and wrote the simplest OSGi bundle I could think of (an activator with a println in its start and stop methods).

With jboss-eap I found a standalone-osgi.xml config, and when I use it I can see a log "OSGi Framework started", but if I deploy my bundle (via the Deployments tab of the console) it doesn't seem to do anything with it (at least I can't see my println).

Strangely, a thread dump (jstack) on the jboss instance doesn't show anything related to the felix framework (I thought it was based on felix?)

In the console, I can see an OSGi menu under "Runtime Operations", with a table of 16 "bundles", non of which has symbolic names...

With wildfly i'm even further as I can't find a way to start the OSGi container.

I'm probably doing something wrong but it doesn't seem quite as obvious as the advertisement suggests.

Any help would be greatly appreciated!

Additionally, is it possible to deploy/start the felix webconsole in jboss/wildfly ?

Thanks

[apanday]

update:

i managed to deploy my hello bundle. (I had to clear all references in the config xml, the standalone/data directory and the deployments directory before retrying, or it would remain in the initial failed stage)

the failure was due to my import of

org.osgi.framework;version="[1.7,2)"

I had to remove the specified version: what version of the framework does jboss export?

a stack trace from my bundle show packages like "org.jboss.osgi.framework.internal" but no apache felix.. was the framework reimplemented in jboss? or is everything wrapped/subclasssed from felix?

also, even with my bundle properly starting, the list of bundles in the console still shows no symbolic-name or version information; is this a bug in the console?

thanks, I'm trying to evaluate jboss as an OSGi container for mixed web and raw osgi applications.