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.
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.
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?
Yes please show us how infinispan defines that dependency on staxmapper
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.
Bundle-Description: Infinispan core module
Bundle-Name: Infinispan Core
Bundle-Vendor: JBoss, a division of Red Hat
Created-By: Apache Maven Bundle Plugin
Specification-Title: Infinispan Core
Specification-Vendor: JBoss, a division of Red Hat
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.
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">
<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"/>
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.
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.