1 2 3 Previous Next 31 Replies Latest reply on Apr 24, 2013 4:43 AM by hongweichen Go to original post
      • 15. Re: How to get the BundleContext inside Web Application?

        We have support for BundleContext injection for EJB3 and Servlet as tested/documented here. If you try to inject the BundleContext into something else (i.e. a managed bean) you are leaving the boundaries of guarantees. Hence it may or may not work.


        The technical reason for this is that OSGi bundles are not (yet) treated in the same way as javaee deployments. Many of the deployment unit processors (DUP) simply ignore OSGi bundles because they cannot handle them properly. Over the next AS7 releases we move the OSGi resolver down a level and make sure that every (javaee) module is also seen by the OSGi layer and vice versa.

        • 16. Re: How to get the BundleContext inside Web Application?

          Wel, more or less that was my conclusion also while I've played with webapp/bundle combination (although wasn't aware about lower level techical details - thanks for clarification),
          so I've turned away from resource injection and tried BundleContextProvider option as I thought it is option to make a "bridge" between webapp and osgi container,
          but as I mentioned previously, even that way I was unable to achieve "webapp talk to bundle" goal.


          It is not that I really need that, I am just in how to say "play and learn" process, checking out what is and what is not possible, are there workarounds etc.


          Once again, thank you very much as you've provided more help than I've hoped.

          • 17. Re: How to get the BundleContext inside Web Application?

            I'm trying to get BundleContext from an EJB3, I call the EJB directly from my JSF Page, but I get this ERROR:

            Any ideas??


            Thanks a lot,





            15:00:11,682 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBOSGIWeb].[Faces Servlet]] (http-- Servlet.service() for servlet Faces Servlet threw exception: java.lang.IllegalArgumentException: Can not set org.osgi.framework.BundleContext field managed.ManagedBean.context to org.jboss.osgi.framework.internal.SystemBundleContext

                at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146) [rt.jar:1.6.0_19]

                at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150) [rt.jar:1.6.0_19]

                at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63) [rt.jar:1.6.0_19]

                at java.lang.reflect.Field.set(Field.java:657) [rt.jar:1.6.0_19]

                at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:111) [jboss-as-ee-7.1.0.Final.jar:7.1.0.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:106) [jboss-as-ee-7.1.0.Final.jar:7.1.0.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.0.Final.jar:7.1.0.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.0.Final.jar:7.1.0.Final]

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

                at org.jboss.as.web.deployment.component.WebComponentInstantiator$2.<init>(WebComponentInstantiator.java:96) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]

                at org.jboss.as.web.deployment.component.WebComponentInstantiator.initializeInstance(WebComponentInstantiator.java:94) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]

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

                at org.jboss.as.web.deployment.jsf.JsfInjectionProvider.invokePostConstruct(JsfInjectionProvider.java:69) [jboss-as-web-7.1.0.Final.jar:7.1.0.Final]

                at com.sun.faces.mgbean.BeanBuilder.invokePostConstruct(BeanBuilder.java:223) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:105) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:409) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:269) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:244) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:116) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72) [jbossweb-7.0.10.Final.jar:]

                at org.apache.el.parser.AstValue.getValue(AstValue.java:147) [jbossweb-7.0.10.Final.jar:]

                at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:189) [jbossweb-7.0.10.Final.jar:]

                at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.component.UIOutput.getValue(UIOutput.java:169) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getValue(HtmlBasicInputRenderer.java:205) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.getCurrentValue(HtmlBasicRenderer.java:355) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:164) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at org.primefaces.renderkit.CoreRenderer.renderChild(CoreRenderer.java:59) [primefaces-2.2.1.jar:]

                at org.primefaces.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:43) [primefaces-2.2.1.jar:]

                at org.primefaces.component.panel.PanelRenderer.encodeContent(PanelRenderer.java:229) [primefaces-2.2.1.jar:]

                at org.primefaces.component.panel.PanelRenderer.encodeMarkup(PanelRenderer.java:152) [primefaces-2.2.1.jar:]

                at org.primefaces.component.panel.PanelRenderer.encodeEnd(PanelRenderer.java:75) [primefaces-2.2.1.jar:]

                at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1764) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.render.Renderer.encodeChildren(Renderer.java:168) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1757) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1760) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:402) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]

                at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.0.0.Final.jar:2.0.0.Final]

                at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.10.Final.jar:]

                at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.10.Final.jar:]

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

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

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

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

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

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

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

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

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

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

                at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_19]

            • 18. Re: How to get the BundleContext inside Web Application?

              One obvious cause would be that the module with the injection target does not see the org.osgi.core API module. If the user does not define such explicit dependency, which he would normaly not do in case of standard javaee deployments (i.e. jsf deployment), it is up to some jsf specific deployment unit processor (DUP) to setup such dependency. Many DUPs however don't do this just yet because they do not expect to work or call into OSGi.


              Try adding


              Dependencies: org.osgi.core


              to your manifest. This is the JBoss propriatary way to define additional dependencies. When you have TRACE logging enabled for org.jboss.modules you should see the dependecy and class loading details.

              • 19. Re: How to get the BundleContext inside Web Application?

                OK, now I think I owe apology to Thomas for bothering him as BundleContextProvider approach actually WORKS!


                It would be less painful if I were reading example more carefully, specially pom.xml.


                Now, I am talking strictly from point of war and using BundleContextProvider...


                I have missed out...actually I didn't know (that is, didn't follow example carefully) that if I want my module (in this case war) to import
                other deployment module (in this case, bundle bridging to BundleContext of OSGi container) i need to add following to manifest:


                deployment.nameOfDeployment:versionOfDeployment or if you prefer entry for maven war plugin:




                Notice that "deployment." precedes bundle name and version thus indicating it is dependency to another deployment.


                And even better news (just succeeded), injecting via @Resource also WORKS if Dependencies are properly set


                Many thanks!


                Edit: JBoss ruleZ


                Message was edited by: Rastko Soskic

                • 20. Re: How to get the BundleContext inside Web Application?

                  Yes, with the MANIFEST DEPENDENCY all works fine.

                  It is not so good for me, because I would like not to declare the dependency in my webapp, because I would be able to call dinamically every new deployed bundle to have dynamism.

                  I hope in next JBOSS version this would change!


                  I have a last question, when I try to get a Service from Bundle Context I get a null ServiceReference.

                  My service in osgi bundle is declared with Blueprint, like this:

                       <bean id="businessBean" class="jboss.osgi.BusinessService" init-method="startup">


                      <service id="BusinessService" interface="jboss.osgi.ServiceInterface" ref="businessBean">


                              <entry key="service.exported.interfaces" value="*"/>




                  My code is:

                  BundleContext bundleContext = bcp.getBundleContext();

                  ServiceReference ref = bundleContext.getServiceReference(ServiceInterface.class.getName());

                  ServiceInterface service = (ServiceInterface) bundleContext.getService(ref);

                  output = service.callme(input);


                  Is there something wrong in it?

                  Thanks a lot!


                  • 21. Re: How to get the BundleContext inside Web Application?

                    UR welcome - thanks for trying out our tech

                    • 22. Re: How to get the BundleContext inside Web Application?

                      Are you using the correct BundleContext? BundleContext.getServiceReference() does a check on assignability. It would only return a reference if you ultimately can use the service associated with it. The service consumer must have a wire to the service type, otherwise you would get a CCE on BundleContext.getService()


                      There are special and IMHO somewhat undefined rules if the system bundle context or service factories are involved. Please start a new thread if we need to go into the details of that or you issue is unrelated to the subject of this thread.

                      • 23. Re: How to get the BundleContext inside Web Application?

                        Hi Rastko, Can you explicitly define the naming/linkage between this statement and your actual bundle?



                        If you can contribute, my case is: https://community.jboss.org/message/756371 and very similar at this point.  Would be curious to see further progress that you have made getting past these hurdles in as7.



                        • 24. Re: How to get the BundleContext inside Web Application?

                          Hi Daniel, yes I succeeded in linking "non bundle" deployment...actually... war with osgi bundle by explicitly specifying name and version
                          via <Dependencies> tag.
                          And, of course, by making sure they match in terms of how they are (name and version) specified in manifest of bundle.


                          I've added reply to your topic. I hope that will help. If not, simply provide details of issue you are facing with so I can check out
                          and possibly help more.

                          • 25. Re: How to get the BundleContext inside Web Application?

                            Thanks Rastko.  So I was able to get my non-osgi jboss 7.1.2 web app to see my bundle.  And to deploy my bundle etc.

                            I am still unclear on the best practice for how to reference these services and it seems you've had similar questions in your other posts and have gone down the same road.


                            Would be great if I could do something in my web app like:

                            @Inject @EchoService

                            ServiceInterface s;


                            Where I have a bundle producting "EchoService".  But it seems that CDI between bundle and web app is not liked by the server.


                            A partner on my team has implemented the ServiceTracker method in an interesting way which I think is a workaround to using @Resource BundleContext.  They have an OSGI Bundle that has a static method that returns the BundleContext.  Then they use that to setup service tracker, and obtain a handle to the service implementation provided by a second bundle.


                            Seems like the long way around to me.


                            What is the preferred method for obtaining a service defined in a blueprint bundle?


                            And FYI - @Resource BundleContext still doesn't work for me.  Gives a JNDI error... I'm trying to inject it in a rest service just to test, but the service will not initialize.


                            It's been very difficult trying to find a quality example showing a clean example of non osgi web-app to osgi service implementations.



                            • 26. Re: How to get the BundleContext inside Web Application?

                              Daniel, you can work with me to get this sorted.



                              BundleContext context


                              is supposed to work. If it does not for a given EE component I like to know about it, add test coverage and fix it.

                              • 27. Re: How to get the BundleContext inside Web Application?

                                OSGi bundle with static method to obtain BundleContext is actually method which Thomas proposed quite a while ago
                                within JBoss examples and is approach I use for injection into non EE resources (e.g. spring beans - injection via annotation into EE resource
                                worked for me though - EDIT: injection of bundle context, NOT particular service).

                                Now about services, well...
                                ...due to fact that OSGi spec (regardless blueprint used or no) defines services as
                                dynamic resources which can come and go,
                                service tracker (despite you consider them as long way around ) is actually correct way to
                                react to their appearing or disappearing.


                                So, I (personally) vote for accessing OSGi container via BundleContext
                                and tracking services via tracker. You can decouple them (OSGi services) behind some general interface so your life is a bit easier
                                should need arise to provide some other way of servicing web app.


                                So... as service can come and go... even between injection into some other resource and
                                actual use of it... service tracker truly is right approach to handle that.
                                I don't think it would be
                                trivial ensuring that OSGi service can't disappear once it is injected (referenced) by some EE resource.


                                Imho, OSGi container and "ordinary web app" (if we keep "bundled web apps" that is pax-web away)
                                are actually pretty different worlds so way to connect them could be long way around.


                                Could be matter of personal taste but I do think that if something is web app then it should be web app
                                where OSGi is quite fine to be used as "service provider" but we have to be willing to pay the price
                                which comes with such approach. OSGi is great for pluggable architectures but turning web app into
                                bundle just to be able to say "I have OSGi bundled web app" is not something that I personally would
                                be willing to do.

                                • 28. Re: How to get the BundleContext inside Web Application?

                                  OSGi bundle with static method to obtain BundleContext is actually method which Thomas proposed quite a while ago


                                  Where did I say that?


                                  In 7.2.x we dont make a distinction between WAR/WAB any more. OSGi webapps (WAB) are deployed onto JBossWeb and can take the full advantage of what this web server provides and being OSGi bundles at the same time. Checkout [AS7-5051] Allow EE deployments as OSGi bundles for functionality related to that.

                                  • 29. Re: How to get the BundleContext inside Web Application?

                                    Here? https://community.jboss.org/message/628165#628165


                                    OK, I forgot to clarify that I am talking in scope of 7.0 and 7.1.0 releases.


                                    Haven't dealt with 7.2 yet.