Skip navigation

7 Replies Latest reply on Jul 24, 2012 1:59 PM by tommybs

@Resource BundleContext context; fails in servlet!

tommybs Jul 22, 2012 2:45 PM

I've seen several pages from googling that to access OSGi services from a regular war file deployed in JBoss (7.1.1) you should to the following in your servlet:

@Resource

private BundleContext bundleContext;

When I access the servlet I get the following:

19:27:53,101 INFO [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/aps-admin-web-1.0.0]] (http--127.0.0.1-8080-1) Marking servlet aps-admin-web as unavailable

19:27:53,102 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/aps-admin-web-1.0.0].[aps-admin-web]] (http--127.0.0.1-8080-1) Allocate exception for servlet aps-admin-web: java.lang.IllegalArgumentException: Can not set org.osgi.framework.BundleContext field se.natusoft.osgi.aps.apsadminweb.osgiint.VaadinOSGiIntegrationServlet.bundleContext to org.jboss.osgi.framework.internal.SystemBundleContext

at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146) [classes.jar:1.6.0_33]

at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150) [classes.jar:1.6.0_33]

at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63) [classes.jar:1.6.0_33]

at java.lang.reflect.Field.set(Field.java:657) [classes.jar:1.6.0_33]

at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:111) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.as.web.deployment.component.WebComponentInstantiator$1.<init>(WebComponentInstantiator.java:57) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.as.web.deployment.component.WebComponentInstantiator.getReference(WebComponentInstantiator.java:55) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.as.web.deployment.WebInjectionContainer.instantiate(WebInjectionContainer.java:99) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.as.web.deployment.WebInjectionContainer.newInstance(WebInjectionContainer.java:78) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

at org.jboss.as.web.deployment.WebInjectionContainer.newInstance(WebInjectionContainer.java:72) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1156) [jbossweb-7.0.13.Final.jar:]

at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:952) [jbossweb-7.0.13.Final.jar:]

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188) [jbossweb-7.0.13.Final.jar:]

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]

at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]

at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]

at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]

at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_33]

Any suggestions ?

/Tommy

1. Re: @Resource BundleContext context; fails in servlet!

thomas.diesler Jul 23, 2012 3:19 AM (in response to tommybs)

The most likely reason is that your WAR does not have declared dependencies on the OSGi API. In our example deployments we do this

    @Deployment(name = SERVLET_DEPLOYMENT_NAME, managed = false, testable = false)
    public static WebArchive getServletArchive() {
        final WebArchive archive = ShrinkWrap.create(WebArchive.class, SERVLET_DEPLOYMENT_NAME);
        archive.addClasses(SimpleBeanClientServlet.class, SimpleClientServlet.class);
        archive.addAsWebInfResource("jbossas/webapp/jboss-web.xml", "jboss-web.xml");
        // [SHRINKWRAP-278] WebArchive.setManifest() results in WEB-INF/classes/META-INF/MANIFEST.MF
        archive.add(new Asset() {
            @Override
            public InputStream openStream() {
                ManifestBuilder builder = ManifestBuilder.newInstance();
                String osgidep = "org.osgi.core,org.jboss.osgi.framework";
                String apidep = ",deployment." + API_DEPLOYMENT_NAME;
                String ejbdep = ",deployment." + EJB3_DEPLOYMENT_NAME;
                builder.addManifestHeader("Dependencies", osgidep + apidep + ejbdep);
                return builder.openStream();
            }
        }, JarFile.MANIFEST_NAME);
        return archive;
    }

2. Re: @Resource BundleContext context; fails in servlet!

tommybs Jul 23, 2012 12:01 PM (in response to thomas.diesler)

Well, I can se that I'm missing org.jboss.osgi.framework. So the next question is, where can I find this ? It is not available in mavens central repository. I did find it in jboss repository at https://repository.jboss.org/nexus/content/groups/public, but those where only 1.0.0.Alpha1-6 versions an all of the jar files contains only a MANIFEST.MF and a pom.xml and nothing else!

I did however try to add it as a dependency thinking that it migh pull other dependencies with it, but it just gave me some shrinkwrap, jmx, and logging jars. Neither helped. So again, where can I find the org.jboss.osgi.framework dependency ?

And just so that there are no missunderstandings here, my WAR is a WAR and not a WAB! No osgi manifest headers! PAX which JBoss uses have gigantic problems deploying WAB files, it is simply impossible. So I gave up and tried this approach instead, using a plain WAR and @Resource injection of BundleContext. In the example above it looks like you are specifying org.jboss.osgi.framework as a package import in an osgi manifest.
Actions
3. Re: @Resource BundleContext context; fails in servlet!

tommybs Jul 23, 2012 12:24 PM (in response to tommybs)

I managed to find jbosgi-framework-core-1.1.8.Final which I included in WEB-INF/lib. It contains the "org.jboss.osgi.framework.internal.SystemBundleContext" class, but unfortunately that didn't help either. The problem remains.
Actions
4. Re: @Resource BundleContext context; fails in servlet!

tommybs Jul 23, 2012 12:56 PM (in response to tommybs)

I just found this thread:

https://community.jboss.org/thread/172622

There at least 2 people have the exact same problem as me. The problem has unfortunately not been resolve in that thread either :-). It however list a JIRA issue:

https://issues.jboss.org/browse/AS7-1974

This issue provides a workaround. I'm going to try that.
Actions
5. Re: @Resource BundleContext context; fails in servlet!

tommybs Jul 23, 2012 1:23 PM (in response to tommybs)

No, the workaround does not work, I get a ClassCastException. It looks likte the ModuleClassLoader does not implement BundleReference.
Actions
6. Re: @Resource BundleContext context; fails in servlet!

thomas.diesler Jul 24, 2012 3:24 AM (in response to tommybs)

If you read the thread carefully it actually is resolved.

Works for me, for Jenkins, and everybody else AFAIK.

You could start from the working examples that we provide in our jbosgi downloads

Above, you might be getting confused between maven dependencies and internal AS7 modules. The OSGi core API as well as the framework are system modules that come with AS7. Any deployment (i.e. your WAR) that wants to use these APIs needs to reference (and not include) these modules.
1 of 1 people found this helpful
Actions
7. Re: @Resource BundleContext context; fails in servlet!

tommybs Jul 24, 2012 1:59 PM (in response to thomas.diesler)

You are right, I was confused, very confused :-). It finally said click in my head now, and your first example started making sense to me. I added a "Dependencies: org.osgi.core,org.jboss.osgi.framework" to MANIFEST.MF and then it worked fine! In retrospect I have to admit it did seem a bit strange to include the jars in the war since that will and probably did cause classloader collisions, that is the implementing class had one version of BundleContext and my code had another.

Maybee I've had too much vacation, I need to get my brain active again :-).

Thanks for the help!
Actions

Go to original post