EAP6.1.ALPHA Infinispan no longer works as OSGI capability

[djchapm]

This isn't due to infinispan build, it is because there is a new dependency on org.jboss.staxmapper - which doesn't have the basic bundle clauses like "Export-Package:" in the manifest.  I think the rest of the dependencies are okay.

Here is the manifest for org.jboss.staxmapper  1.1.0.Final:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: bstansberry
Build-Jdk: 1.6.0_29
Specification-Title: StAX Mapper
Specification-Version: 1.1.0.Final
Specification-Vendor: JBoss by Red Hat
Implementation-Title: StAX Mapper
Implementation-Version: 1.1.0.Final
Implementation-Vendor-Id: org.jboss
Implementation-Vendor: JBoss by Red Hat
Implementation-URL: http://www.jboss.org/staxmapper
Java-Vendor: Apple Inc.
Java-Version: 1.6.0_29
Os-Arch: x86_64
Os-Name: Mac OS X
Os-Version: 10.6.8
Scm-Url: http://github.com/jboss/jboss-parent-pom/staxmapper

[djchapm]

Bump... should we do a Jira?  I originally submitted this to Redhat as we have a support license.  They said that they don't do support for Alpha release, and also - they are keeping OSGI in 'preview' mode for EAP 6.1 - to my dismay - so I was told to create this post here.  Thinking it's time to consider an alternative to jbosgi even though it had a nice roadmap - if I'm unable to get official support on a real world enterprise production app.  I'm also concerned that Redhat is changing plans regarding jbosgi due to recent aquisition of ServiceMix/FUSE. 

Likewise - it seems that for many issues - the Redhat/JBOSGI development team only supports the Head instead of providing any sort of patch.  This makes it difficult because the head is currently JBoss 7.2, however the only supported version by Redhat license is 7.1.3.Final in EAP 6.0.1.  Best they just come out and say - sorry, we're not done yet, don't waste your time trying to use it because any defect you find won't be fixed for you.

Nothing against community members.

Cheers,

  Dan C>

[ctomc]

Hi,

please create jira for this,

and if you are up to it even send pull request https://github.com/jbossas/staxmapper

Every new technology that appears in EAP for first time is marked as technology preview, as it is hard to get everything right first time.

As for osgi goes, as far as I know guys are fully committed to it.

Currently they are working on R5 implementation and are quite far with its implementation. for more info see https://issues.jboss.org/browse/JBOSGI-616

There have been many improvements & new features recently committed recently to AS head, which you can try by using AS8 nightly.

--

tomaz

[jaikiran]

Daniel, I have zero knowledge about OSGi, but I'm curious why a dependency on a new library which doesn't have OSGi metadata, breaks things. Like I said, I have no knowledge of OSGi, so the failure might be expected. Can you add some details like what exactly is failing and how?

[thomas.diesler]

Yes please show us how infinispan defines that dependency on staxmapper

[djchapm]

Here's the manifest in the infinispan-core-5.2.1.Final.jar.  It's in the Export-Package as a "uses:" and in the Import-Package entries.

To Jaikiran - Something may be deployed as a capability if it's built using the bnd tool to include all required manifest entries like those you see here - "Bundle-*", Export-Package and Import-Package needs.

Thomas I was able to configure standalone in EAP 6.0.1 with the required infinispan entries and was then able to access all my infinispan configs in my OSGI modules.  As far as I can tell - this new dependency on staxmapper now prevents it from deploying as a capability. 

Thanks,

  Dan C

Manifest-Version: 1.0
Bnd-LastModified: 1360340587508
Build-Jdk: 1.6.0_33
Built-By: mircea
Bundle-Description: Infinispan core module
Bundle-DocURL: http://www.infinispan.org/
Bundle-License: http://repository.jboss.org/licenses/lgpl-2.1.txt
Bundle-ManifestVersion: 2
Bundle-Name: Infinispan Core
Bundle-SymbolicName: org.infinispan.core
Bundle-Vendor: JBoss, a division of Red Hat
Bundle-Version: 5.2.1.Final
Created-By: Apache Maven Bundle Plugin
Export-Package: org.infinispan.jmx;uses:="org.infinispan.factories,org.i
nfinispan.configuration.global,javax.management,org.infinispan.factorie
...<CUT>

Main-Class: org.infinispan.Version
Specification-Title: Infinispan Core
Specification-Vendor: JBoss, a division of Red Hat
Specification-Version: 5.2.1.Final
Tool: Bnd-1.50.0

[thomas.diesler]

Unfortunately, this post is useless

Please show us how you configure infinispan and friends as capabilities. Then we need to see the debug log that shows infinispan's requirements. The log should also show the resource that provides the capability that you think infinispan should wire to.

I'm not an infinispan expert. Would it make sense to provide a (number of) infinispan services that a client can interact with? I assume that clients currently use some sort of InfinispanFooFactory or "new InfinispanFoo" semantic.

It is generally good practise to bind to some service instead of specific implementaiton classes.

[djchapm]

Okay - but you did ask to see "how infinispan defines that dependency on staxmapper" - not sure what else you expected.

Here are my capabilities that work in EAP 6.0.1. 

        <subsystem xmlns="urn:jboss:domain:osgi:1.2" activation="eager">
            <properties>
                <property name="org.jboss.osgi.system.modules.extra">
                    org.apache.log4j
                </property>
                <property name="org.osgi.framework.startlevel.beginning">
                    1
                </property>
                <property name="org.osgi.framework.system.packages.extra">
                    org.apache.log4j;version=1.2
                </property>
            </properties>
            <capabilities>
                <capability name="javax.servlet.api:v25"/>
                <capability name="javax.transaction.api"/>
                  <capability name="org.apache.felix.log" startlevel="1"/>
                  <capability name="org.jboss.osgi.logging" startlevel="1"/>
                <capability name="org.apache.felix.configadmin" startlevel="1"/>
                <capability name="org.jboss.as.osgi.configadmin" startlevel="1"/>
                <capability name="org.infinispan:infinispan-core:5.1.8.Final-redhat-1"/>
                <capability name="org.jboss.marshalling"/>
                <capability name="org.jboss.marshalling.river"/>
                <capability name="org.jgroups"/>
                <capability name="sun.jdk"/>
                <capability name="org.infinispan:infinispan-cdi:5.1.8.Final"/>
                <capability name="javax.cache:cache-api:0.5"/>
                  <capability name="org.apache.aries:org.apache.aries.util:1.0.0"/>
                  <capability name="org.apache.aries.proxy:org.apache.aries.proxy:1.0.0"/>
                  <capability name="org.apache.aries.blueprint:org.apache.aries.blueprint:1.0.0"/>
            </capabilities>
        </subsystem>

So start server, startup all the bundles... works fine.

Now do the same in 6.1.ALPHA release but update both infinispan entries to 5.2.1.Final and when you start you will see the missing dependency on staxmapper.  I've looked in manifests, this dependency is not there in 5.1.8.  So what I was asking was for JBoss to add appropriate entries to staxmapper manifest so that I could set it as capability.

Feel free to correct me if I'm not using capabilities correctly here.  And apologies if you think this is useless... seems like a problem to me though but I'll admit I'm no expert.  This is the reason SpringDM/Gemini has created alternate versions of so many open source libraries - so that they could be deployed in an OSGI environment.

Thanks,

  Dan C>

[thomas.diesler]

We support non-osgi module capabilities in the configuration. In this case we scan the module entries and export every path as package capability. Try adding the module that contains the missing package as capability and have look at the debug log. It should list the exported package-capability and later the package-requirement from infinispan. This could still fail if the requirement defined by infinispan is more specific than the generated capability from staxmapper.