1 2 Previous Next 28 Replies Latest reply on Jun 17, 2010 3:06 PM by 392 Guest

    JAX-RS on Glassfish 3.1: @EJB injection?

    ljnelson-JavaNet
      I need to know if @EJB injection is supposed to be working for a JAX-RS resource class in Glassfish 3.1 b04 or later. Specifically, I have a resource class that I would like to place the following in:   @EJB // happy to either leave empty or supply the proper "lookup" string   private FooManager myEjb; This does not work in JBoss.  It is required by the Java EE specification.  On Glassfish, I find that it does not work either, which surprises me; I feel like I've seen it working before. Any known issues around this? Thanks, Laird
        • 1. Re: JAX-RS on Glassfish 3.1: @EJB injection?
          392 Guest
          Hi Laird, For this to work you need to identify the resource class a managed  bean. There are three options: 1) Annotate with @ManagedBean (Jersey will defer to the app container  to instantiate and it will managed the life-cycle); 2) Annotate with @Stateless or @Singleton to make it an EJB; or 3) Annotation with with a CDI-based scope annotation such as  @RequestScoped. There are currently some limitations for 1) and 3). Constructor  injection is not supported. We are investigating improved CDI  integration such that those limitations will be removed for 3). Hth, Paul. On Jun 15, 2010, at 3:23 PM, glassfish@javadesktop.org wrote: > I need to know if @EJB injection is supposed to be working for a JAX- > RS resource class in Glassfish 3.1 b04 or later. > > Specifically, I have a resource class that I would like to place the  > following in: > >  @EJB // happy to either leave empty or supply the proper "lookup"  > string >  private FooManager myEjb; > > This does not work in JBoss.  It is required by the Java EE  > specification.  On Glassfish, I find that it does not work either,  > which surprises me; I feel like I've seen it working before. > > Any known issues around this? > > Thanks, > Laird > [Message sent by forum member 'ljnelson'] > > http://forums.java.net/jive/thread.jspa?messageID=474333 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net > For additional commands, e-mail: users-help@glassfish.dev.java.net > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For additional commands, e-mail: users-help@glassfish.dev.java.net
          • 2. Re: JAX-RS on Glassfish 3.1: @EJB injection?
            ljnelson-JavaNet
            > For this to work you need to identify the resource > class a managed  > bean. There are three options: Hi, Paul; thanks for the quick reply.  Is this mechanism--which I have no problem with--mandated by the Java EE specification, or is it simply a short term issue with Jersey? That is, does the specification indicate (I didn't see where) that such additional annotations are required, or is this simply something we have to do because Jersey isn't yet mature enough in this regard to honor the spec requirements? Thanks again, Laird
            • 3. Re: JAX-RS on Glassfish 3.1: @EJB injection?
              392 Guest
              On Jun 15, 2010, at 3:53 PM, glassfish@javadesktop.org wrote: >> For this to work you need to identify the resource >> class a managed >> bean. There are three options: > > Hi, Paul; thanks for the quick reply.  Is this mechanism--which I  > have no problem with--mandated by the Java EE specification, or is  > it simply a short term issue with Jersey? > > That is, does the specification indicate (I didn't see where) that  > such additional annotations are required, or is this simply  > something we have to do because Jersey isn't yet mature enough in  > this regard to honor the spec requirements? > It is spec compliant. But we still have some work to do to honor some  optional requirements. For JAX-RS 1.1 we were very conservative with CDI because it was  standardized very late in the process of the Java EE 6 schedule. This  is why the EG did not mandate that the JAX-RS artifacts can be used  with @Inject and hence constructor injection may not be supported. It  is optional. JAX-RS defines it's own programming model that has some restrictions  with @ManagedBean and CDI thus you cannot always expect existing JAX- RS applications to deploy if the JAX-RS components automatically  become managed beans or CDI managed beans when CDI is enabled. Hence  why those annotations previously referred to are explicitly required. One thing we overlooked was a deployment option to say "all root  resource and provider classes are implicitly managed in the  @RequestScope, unless otherwise managed explicitly". So for this we  are considering a jersey-specific deployment option. This requires  some deep integration with CDI to modify the bean model. Paul. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For additional commands, e-mail: users-help@glassfish.dev.java.net
              • 4. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                ljnelson-JavaNet
                > It is spec compliant. But we still have some work to > do to honor some  > optional requirements. OK.  So the essential gist is that a resource class needs to be a managed bean (either in the @ManagedBean sense or the CDI sense).  Obviously, unannotated, a resource class [i]is[/i] a CDI managed bean, but you're saying that the Java EE 6 specification, somewhere, says that a resource class must be explicitly marked as a managed bean, owing to, among other things, the lateness of the inclusion of CDI into the Java EE specification. Is that all correct? My takeaway: as long as I'm not using constructor injection--which I'm not--then simply marking my resource class as @RequestScoped or @ManagedBean will enable further injections to take place properly. Right? Thanks again, Laird
                • 5. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                  392 Guest
                  On Jun 15, 2010, at 4:22 PM, glassfish@javadesktop.org wrote: >> It is spec compliant. But we still have some work to >> do to honor some >> optional requirements. > > OK.  So the essential gist is that a resource class needs to be a  > managed bean (either in the @ManagedBean sense or the CDI sense).   > Obviously, unannotated, a resource class [i]is[/i] a CDI managed  > bean, but you're saying that the Java EE 6 specification, somewhere,  > says that a resource class must be explicitly marked as a managed  > bean, owing to, among other things, the lateness of the inclusion of  > CDI into the Java EE specification. > > Is that all correct? > The JAX-RS spec is a little vague on the matter but is implied :-)  meaning we could improve things and make it much clearer! The vagueness is around CDI. JAX-RS root resource classes are by  default managed in a per-request scope and any JAX-RS implementation,  that is required to support the JAX-RS programming model, will realize  the requirement to explicitly opt in for CDI so as not to break  existing JAX-RS applications. The portable way of doing this is for  the application to explicitly annotate. The use of @ManagedBean or @Stateless or @Singleton already requires  explicit use. > My takeaway: as long as I'm not using constructor injection--which  > I'm not--then simply marking my resource class as @RequestScoped or  > @ManagedBean will enable further injections to take place properly. > > Right? > Correct. Paul. > Thanks again, > Laird > [Message sent by forum member 'ljnelson'] > > http://forums.java.net/jive/thread.jspa?messageID=474344 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net > For additional commands, e-mail: users-help@glassfish.dev.java.net > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For additional commands, e-mail: users-help@glassfish.dev.java.net
                  • 6. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                    ljnelson-JavaNet
                    Thanks, Paul; that answers my question.  I will also point the JBoss fellows at this thread as the RestEasy developers list is currently adrift trying to figure all this out. Best, Laird
                    • 7. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                      ljnelson-JavaNet
                      OK, almost there. I have an ear with the following structure for which dependency injection is still not working: ear/lib/jar-containing-resources.jar ear/lib/jar-containing-resources.jar/META-INF/beans.xml ear/ejb-jar.jar ear/war-file.war My resource class is in the jar-contianing-resources.jar.  Note that I have placed an empty beans.xml file in that jar file's META-INF directory, per the CDI specification. I am "publishing" my application according to section 2.3 of the JAX-RS 1.1 specification.  That is, I have an empty Application subclass annotated with @ApplicationPath and no web.xml file. The result is that--nicely!--I can confirm that resource classes need not be in a web application; they can indeed be in the lib directory of an ear.  My application is published, and "answers the phone" as I would expect. However, my @RequestScoped resource, which contains an @EJB-annotated field, does not have that field injected. Did I put my beans.xml in the wrong place?  Am I missing anything else obvious?  If not, I will happily attach my test project to this thread. Best, Laird
                      • 8. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                        ljnelson-JavaNet
                        Sorry to report that all suggestions in this realm fail. The attached Maven project demonstrates that injection of any kind within a resource class is broken using Glassfish 3.1b04 or later.  I don't know enough to know whether this is a bug or pilot error.  I will let this sit for a while and then file a bug if there are no responses. Best, Laird
                        • 9. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                          ljnelson-JavaNet
                          To be very clear: CDI does not work with the project as it is attached. If instead of @RequestScoped I annotate my resource with @ManagedBean, then not only is the EJB injected properly (!) but so is the "control group" CDI resource.  It appears that without @ManagedBean, no resource injection of any kind--CDI, EJB or otherwise--occurs; with it, it appears that all resource injection occurs. Thoughts?  This is getting crazy. Best, Laird
                          • 10. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                            392 Guest
                            Hi Laird, Your example works fine for me on GlassFish 3.0. BTW you need to  update the top level pom to include the war module. However, it fails on GlassFish 3.0.1 b20 as shipped with NetBeans 6.9  RC 2. SEVERE: Exception while loading the app org.glassfish.deployment.common.DeploymentException: WELD-001409  Injection point has ambiguous dependencies.  Injection point:  field  ljnelson.frobnicator.jaxrs.FrobnicatorResource.junk;  Qualifiers:   [@javax.enterprise.inject.Default()]; Possible dependencies:  [org.jboss.weld.bean-/Users/paulsandoz/Downloads/glassfish-bugs/ frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar-ManagedBean-class  ljnelson.frobnicator.jaxrs.Junk, org.jboss.weld.bean-/Users/paulsandoz/ Downloads/glassfish-bugs/frobnicator/ear/target/gfdeploy/ ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-war-1.0- SNAPSHOT_war/-ManagedBean-class ljnelson.frobnicator.jaxrs.Junk] It looks like Weld is getting confused thinking there are two possible  dependencies for Junk, because it is in a jar included in the war. I  dunno if this is specially a Weld issue or the integration of Weld  into GF. See end of email for more of the log. I get the same exception if i deploy to GlassFish 3.1 b04. Can you log an issue? There seems to be another bug with 3.0.1 and 3.1 related to the web  container thinking the Jersey ServletContainer is a CDI managed bean  when in fact it was instantiated by Jersey's  ServletContainerInitializer. Paul. GlassFish 3.0.1 log -------------------------- INFO: WELD-000900 1.0.1 (SP3) INFO: Instantiated an instance of  org.hibernate.validator.engine.resolver.JPATraversableResolver. INFO: Portable JNDI names for EJB FrobnicatorBean : [java:global/ ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-ejb-1.0-SNAPSHOT/ FrobnicatorBean, java:global/ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/ frobnicator-ejb-1.0-SNAPSHOT/FrobnicatorBean! ljnelson.frobnicator.api.Frobnicator] INFO: Registering the Jersey servlet application, named  ljnelson.frobnicator.war.Application, at the servlet mapping, / frobnication/*, with the Application class of the same name INFO: Updating configuration from org.apache.felix.fileinstall- autodeploy-bundles.cfg INFO: Installed /Applications/NetBeans/glassfish-3.0.1-b20/glassfish/ modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir = / Applications/NetBeans/glassfish-3.0.1-b20/glassfish/domains/domain1/ autodeploy/bundles, felix.fileinstall.debug = 1,  felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir  = /var/folders/vd/vdTgcMYGEb0tkynCTcnFH++++TI/-Tmp-/ fileinstall--7810245262067255821, felix.fileinstall.filter = null} INFO: Loading application ljnelson_frobnicator-ear_ear_1.0- SNAPSHOT#frobnicator-war-1.0-SNAPSHOT.war at /frobnicator-war SEVERE: Exception while loading the app org.glassfish.deployment.common.DeploymentException: WELD-001409  Injection point has ambiguous dependencies.  Injection point:  field  ljnelson.frobnicator.jaxrs.FrobnicatorResource.junk;  Qualifiers:   [@javax.enterprise.inject.Default()]; Possible dependencies:  [org.jboss.weld.bean-/Users/paulsandoz/Downloads/glassfish-bugs/ frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar-ManagedBean-class  ljnelson.frobnicator.jaxrs.Junk, org.jboss.weld.bean-/Users/paulsandoz/ Downloads/glassfish-bugs/frobnicator/ear/target/gfdeploy/ ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-war-1.0- SNAPSHOT_war/-ManagedBean-class ljnelson.frobnicator.jaxrs.Junk]          at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:181)          at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java: 125)          at  org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java: 239)          at  com .sun .enterprise .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:339)          at  com .sun .enterprise .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)          at  org .glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java: 272)          at com.sun.enterprise.v3.admin.CommandRunnerImpl $1.execute(CommandRunnerImpl.java:305)          at  com .sun .enterprise .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)          at  com .sun .enterprise .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)          at com.sun.enterprise.v3.admin.CommandRunnerImpl.access $900(CommandRunnerImpl.java:83)          at com.sun.enterprise.v3.admin.CommandRunnerImpl $ExecutionContext.execute(CommandRunnerImpl.java:1235)          at com.sun.enterprise.v3.admin.CommandRunnerImpl $ExecutionContext.execute(CommandRunnerImpl.java:1224)          at  com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java: 365)          at  com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)          at  com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java: 166)          at  com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java: 100)          at  com .sun .enterprise .v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)          at  com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)          at  com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)          at  com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)          at  com .sun .grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java: 170)          at  com .sun .grizzly .DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java: 135)          at  com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: 102)          at  com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: 88)          at  com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java: 76)          at  com .sun .grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java: 53)          at  com .sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java: 57)          at com.sun.grizzly.ContextTask.run(ContextTask.java:69)          at com.sun.grizzly.util.AbstractThreadPool $Worker.doWork(AbstractThreadPool.java:330)          at com.sun.grizzly.util.AbstractThreadPool $Worker.run(AbstractThreadPool.java:309)          at java.lang.Thread.run(Thread.java:637) Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001409  Injection point has ambiguous dependencies.  Injection point:  field  ljnelson.frobnicator.jaxrs.FrobnicatorResource.junk;  Qualifiers:   [@javax.enterprise.inject.Default()]; Possible dependencies:  [org.jboss.weld.bean-/Users/paulsandoz/Downloads/glassfish-bugs/ frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar-ManagedBean-class  ljnelson.frobnicator.jaxrs.Junk, org.jboss.weld.bean-/Users/paulsandoz/ Downloads/glassfish-bugs/frobnicator/ear/target/gfdeploy/ ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-war-1.0- SNAPSHOT_war/-ManagedBean-class ljnelson.frobnicator.jaxrs.Junk]          at  org .jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java: 280)          at  org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:122)          at  org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:141)          at  org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:331)          at  org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java: 317)          at  org .jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java: 399)          at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:178)          ... 30 more SEVERE: Exception while deploying the app java.lang.IllegalStateException: Unknown JCDI-enabled managed bean  com.sun.jersey.spi.container.servlet.ServletContainer@13f6edc5 of  class class com.sun.jersey.spi.container.servlet.ServletContainer          at  com .sun .enterprise .container .common .impl .managedbean .ManagedBeanManagerImpl.destroyManagedBean(ManagedBeanManagerImpl.java: 534)          at  com .sun .enterprise .container .common .impl .util .InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java: 340)          at  com .sun .web .server .J2EEInstanceListener.handleAfterEvent(J2EEInstanceListener.java:324)          at  com .sun .web .server.J2EEInstanceListener.instanceEvent(J2EEInstanceListener.java: 108)          at  org .apache .catalina.util.InstanceSupport.fireInstanceEvent(InstanceSupport.java: 381)          at  org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java: 1740)          at  org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:2036)          at  org.apache.catalina.core.StandardContext.stop(StandardContext.java:5482)          at com.sun.enterprise.web.WebModule.stop(WebModule.java:513)          at  org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java: 1042)          at  com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java: 2130)          at  com.sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java: 2085)          at  com.sun.enterprise.web.WebApplication.stop(WebApplication.java:134)          at org.glassfish.internal.data.EngineRef.stop(EngineRef.java: 166)          at com.sun.enterprise.v3.server.ApplicationLifecycle $1.actOn(ApplicationLifecycle.java:229)          at  com .sun .enterprise .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:359)          at  com .sun .enterprise .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:199)          at  org .glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java: 286)          at com.sun.enterprise.v3.admin.CommandRunnerImpl $1.execute(CommandRunnerImpl.java:322)          at  com .sun .enterprise .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:337)          at  com .sun .enterprise .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:965)          at com.sun.enterprise.v3.admin.CommandRunnerImpl.access $1200(CommandRunnerImpl.java:92)          at com.sun.enterprise.v3.admin.CommandRunnerImpl $ExecutionContext.execute(CommandRunnerImpl.java:1088)          at com.sun.enterprise.v3.admin.CommandRunnerImpl $ExecutionContext.execute(CommandRunnerImpl.java:1077)          at  com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java: 366)          at  com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:203)          at  com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java: 166)          at  com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java: 113)          at  com .sun .enterprise .v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)          at  com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:802)          at  com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:705)          at  com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:986)          at  com .sun .grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java: 178)          at  com .sun .grizzly .DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java: 135)          at  com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: 102)          at  com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: 88)          at  com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java: 76)          at  com .sun .grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java: 53)          at  com .sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java: 57)          at com.sun.grizzly.ContextTask.run(ContextTask.java:69)          at com.sun.grizzly.util.AbstractThreadPool $Worker.doWork(AbstractThreadPool.java:526)          at com.sun.grizzly.util.AbstractThreadPool $Worker.run(AbstractThreadPool.java:507)          at java.lang.Thread.run(Thread.java:637) On Jun 15, 2010, at 11:47 PM, glassfish@javadesktop.org wrote: > To be very clear: CDI does not work with the project as it is  > attached. > > If instead of @RequestScoped I annotate my resource with  > @ManagedBean, then not only is the EJB injected properly (!) but so  > is the "control group" CDI resource.  It appears that without  > @ManagedBean, no resource injection of any kind--CDI, EJB or  > otherwise--occurs; with it, it appears that all resource injection  > occurs. > > Thoughts?  This is getting crazy. > > Best, > Laird > [Message sent by forum member 'ljnelson'] > > http://forums.java.net/jive/thread.jspa?messageID=474391 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net > For additional commands, e-mail: users-help@glassfish.dev.java.net > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For additional commands, e-mail: users-help@glassfish.dev.java.net
                            • 11. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                              392 Guest
                              On Jun 16, 2010, at 10:49 AM, Paul Sandoz wrote: > Hi Laird, > > Your example works fine for me on GlassFish 3.0. BTW you need to  > update the top level pom to include the war module. > > However, it fails on GlassFish 3.0.1 b20 as shipped with NetBeans  > 6.9 RC 2. > Same also occurs for the final GlassFish 3.0.1. Paul. > SEVERE: Exception while loading the app > org.glassfish.deployment.common.DeploymentException: WELD-001409  > Injection point has ambiguous dependencies.  Injection point:  field  > ljnelson.frobnicator.jaxrs.FrobnicatorResource.junk;  Qualifiers:   > [@javax.enterprise.inject.Default()]; Possible dependencies:  > [org.jboss.weld.bean-/Users/paulsandoz/Downloads/glassfish-bugs/ > frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- > SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar-ManagedBean-class  > ljnelson.frobnicator.jaxrs.Junk, org.jboss.weld.bean-/Users/ > paulsandoz/Downloads/glassfish-bugs/frobnicator/ear/target/gfdeploy/ > ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-war-1.0- > SNAPSHOT_war/-ManagedBean-class ljnelson.frobnicator.jaxrs.Junk] > > It looks like Weld is getting confused thinking there are two  > possible dependencies for Junk, because it is in a jar included in  > the war. I dunno if this is specially a Weld issue or the  > integration of Weld into GF. > > See end of email for more of the log. > > I get the same exception if i deploy to GlassFish 3.1 b04. > > Can you log an issue? > > There seems to be another bug with 3.0.1 and 3.1 related to the web  > container thinking the Jersey ServletContainer is a CDI managed bean  > when in fact it was instantiated by Jersey's  > ServletContainerInitializer. > > Paul. > > GlassFish 3.0.1 log > -------------------------- > INFO: WELD-000900 1.0.1 (SP3) > INFO: Instantiated an instance of  > org.hibernate.validator.engine.resolver.JPATraversableResolver. > INFO: Portable JNDI names for EJB FrobnicatorBean : [java:global/ > ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-ejb-1.0- > SNAPSHOT/FrobnicatorBean, java:global/ljnelson_frobnicator- > ear_ear_1.0-SNAPSHOT/frobnicator-ejb-1.0-SNAPSHOT/FrobnicatorBean! > ljnelson.frobnicator.api.Frobnicator] > INFO: Registering the Jersey servlet application, named  > ljnelson.frobnicator.war.Application, at the servlet mapping, / > frobnication/*, with the Application class of the same name > INFO: Updating configuration from org.apache.felix.fileinstall- > autodeploy-bundles.cfg > INFO: Installed /Applications/NetBeans/glassfish-3.0.1-b20/glassfish/ > modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg > INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir = / > Applications/NetBeans/glassfish-3.0.1-b20/glassfish/domains/domain1/ > autodeploy/bundles, felix.fileinstall.debug = 1,  > felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir  > = /var/folders/vd/vdTgcMYGEb0tkynCTcnFH++++TI/-Tmp-/ > fileinstall--7810245262067255821, felix.fileinstall.filter = null} > INFO: Loading application ljnelson_frobnicator-ear_ear_1.0- > SNAPSHOT#frobnicator-war-1.0-SNAPSHOT.war at /frobnicator-war > SEVERE: Exception while loading the app > org.glassfish.deployment.common.DeploymentException: WELD-001409  > Injection point has ambiguous dependencies.  Injection point:  field  > ljnelson.frobnicator.jaxrs.FrobnicatorResource.junk;  Qualifiers:   > [@javax.enterprise.inject.Default()]; Possible dependencies:  > [org.jboss.weld.bean-/Users/paulsandoz/Downloads/glassfish-bugs/ > frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- > SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar-ManagedBean-class  > ljnelson.frobnicator.jaxrs.Junk, org.jboss.weld.bean-/Users/ > paulsandoz/Downloads/glassfish-bugs/frobnicator/ear/target/gfdeploy/ > ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT/frobnicator-war-1.0- > SNAPSHOT_war/-ManagedBean-class ljnelson.frobnicator.jaxrs.Junk] >        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:181) >        at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java: > 125) >        at  > org > .glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java: > 239) >        at  > com > .sun > .enterprise > .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:339) >        at  > com > .sun > .enterprise > .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183) >        at  > org > .glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java: > 272) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl > $1.execute(CommandRunnerImpl.java:305) >        at  > com > .sun > .enterprise > .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320) >        at  > com > .sun > .enterprise > .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl.access > $900(CommandRunnerImpl.java:83) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl > $ExecutionContext.execute(CommandRunnerImpl.java:1235) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl > $ExecutionContext.execute(CommandRunnerImpl.java:1224) >        at  > com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java: > 365) >        at  > com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java: > 204) >        at  > com > .sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java: > 166) >        at  > com > .sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java: > 100) >        at  > com > .sun > .enterprise > .v3.services.impl.ContainerMapper.service(ContainerMapper.java:245) >        at  > com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java: > 791) >        at  > com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693) >        at  > com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954) >        at  > com > .sun > .grizzly > .http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170) >        at  > com > .sun > .grizzly > .DefaultProtocolChain > .executeProtocolFilter(DefaultProtocolChain.java:135) >        at  > com > .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: > 102) >        at  > com > .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: > 88) >        at  > com > .sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76) >        at  > com > .sun > .grizzly > .ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53) >        at  > com > .sun > .grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57) >        at com.sun.grizzly.ContextTask.run(ContextTask.java:69) >        at com.sun.grizzly.util.AbstractThreadPool > $Worker.doWork(AbstractThreadPool.java:330) >        at com.sun.grizzly.util.AbstractThreadPool > $Worker.run(AbstractThreadPool.java:309) >        at java.lang.Thread.run(Thread.java:637) > Caused by: org.jboss.weld.exceptions.DeploymentException:  > WELD-001409 Injection point has ambiguous dependencies.  Injection  > point:  field ljnelson.frobnicator.jaxrs.FrobnicatorResource.junk;   > Qualifiers:  [@javax.enterprise.inject.Default()]; Possible  > dependencies: [org.jboss.weld.bean-/Users/paulsandoz/Downloads/ > glassfish-bugs/frobnicator/ear/target/gfdeploy/ljnelson_frobnicator- > ear_ear_1.0-SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar- > ManagedBean-class ljnelson.frobnicator.jaxrs.Junk,  > org.jboss.weld.bean-/Users/paulsandoz/Downloads/glassfish-bugs/ > frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- > SNAPSHOT/frobnicator-war-1.0-SNAPSHOT_war/-ManagedBean-class  > ljnelson.frobnicator.jaxrs.Junk] >        at  > org > .jboss > .weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280) >        at  > org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:122) >        at  > org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:141) >        at  > org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:331) >        at  > org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java: > 317) >        at  > org > .jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java: > 399) >        at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:178) >        ... 30 more > > > > SEVERE: Exception while deploying the app > java.lang.IllegalStateException: Unknown JCDI-enabled managed bean  > com.sun.jersey.spi.container.servlet.ServletContainer@13f6edc5 of  > class class com.sun.jersey.spi.container.servlet.ServletContainer >        at  > com > .sun > .enterprise > .container > .common > .impl > .managedbean > .ManagedBeanManagerImpl > .destroyManagedBean(ManagedBeanManagerImpl.java:534) >        at  > com > .sun > .enterprise > .container > .common > .impl > .util > .InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java: > 340) >        at  > com > .sun > .web > .server > .J2EEInstanceListener.handleAfterEvent(J2EEInstanceListener.java:324) >        at  > com > .sun > .web > .server.J2EEInstanceListener.instanceEvent(J2EEInstanceListener.java: > 108) >        at  > org > .apache > .catalina > .util.InstanceSupport.fireInstanceEvent(InstanceSupport.java:381) >        at  > org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java: > 1740) >        at  > org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java: > 2036) >        at  > org.apache.catalina.core.StandardContext.stop(StandardContext.java: > 5482) >        at com.sun.enterprise.web.WebModule.stop(WebModule.java:513) >        at  > org > .apache.catalina.core.ContainerBase.removeChild(ContainerBase.java: > 1042) >        at  > com > .sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java: > 2130) >        at  > com > .sun.enterprise.web.WebContainer.unloadWebModule(WebContainer.java: > 2085) >        at  > com.sun.enterprise.web.WebApplication.stop(WebApplication.java:134) >        at org.glassfish.internal.data.EngineRef.stop(EngineRef.java: > 166) >        at com.sun.enterprise.v3.server.ApplicationLifecycle > $1.actOn(ApplicationLifecycle.java:229) >        at  > com > .sun > .enterprise > .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:359) >        at  > com > .sun > .enterprise > .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:199) >        at  > org > .glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java: > 286) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl > $1.execute(CommandRunnerImpl.java:322) >        at  > com > .sun > .enterprise > .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:337) >        at  > com > .sun > .enterprise > .v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:965) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl.access > $1200(CommandRunnerImpl.java:92) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl > $ExecutionContext.execute(CommandRunnerImpl.java:1088) >        at com.sun.enterprise.v3.admin.CommandRunnerImpl > $ExecutionContext.execute(CommandRunnerImpl.java:1077) >        at  > com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java: > 366) >        at  > com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java: > 203) >        at  > com > .sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java: > 166) >        at  > com > .sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java: > 113) >        at  > com > .sun > .enterprise > .v3.services.impl.ContainerMapper.service(ContainerMapper.java:245) >        at  > com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java: > 802) >        at  > com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:705) >        at  > com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:986) >        at  > com > .sun > .grizzly > .http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:178) >        at  > com > .sun > .grizzly > .DefaultProtocolChain > .executeProtocolFilter(DefaultProtocolChain.java:135) >        at  > com > .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: > 102) >        at  > com > .sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java: > 88) >        at  > com > .sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76) >        at  > com > .sun > .grizzly > .ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53) >        at  > com > .sun > .grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57) >        at com.sun.grizzly.ContextTask.run(ContextTask.java:69) >        at com.sun.grizzly.util.AbstractThreadPool > $Worker.doWork(AbstractThreadPool.java:526) >        at com.sun.grizzly.util.AbstractThreadPool > $Worker.run(AbstractThreadPool.java:507) >        at java.lang.Thread.run(Thread.java:637) > > > On Jun 15, 2010, at 11:47 PM, glassfish@javadesktop.org wrote: > >> To be very clear: CDI does not work with the project as it is  >> attached. >> >> If instead of @RequestScoped I annotate my resource with  >> @ManagedBean, then not only is the EJB injected properly (!) but so  >> is the "control group" CDI resource.  It appears that without  >> @ManagedBean, no resource injection of any kind--CDI, EJB or  >> otherwise--occurs; with it, it appears that all resource injection  >> occurs. >> >> Thoughts?  This is getting crazy. >> >> Best, >> Laird >> [Message sent by forum member 'ljnelson'] >> >> http://forums.java.net/jive/thread.jspa?messageID=474391 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net >> For additional commands, e-mail: users-help@glassfish.dev.java.net >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net > For additional commands, e-mail: users-help@glassfish.dev.java.net > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For additional commands, e-mail: users-help@glassfish.dev.java.net
                              • 12. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                                ljnelson-JavaNet
                                Thanks, Paul, for the quick response. I apologize for the configuration; I thought I had proofed the thing better than that.  I've been through so many configurations that a bad one slipped through the cracks. I found some other issues as well. It turns out that looking for resources in the .ear does NOT work.  That is, once I cleared up the skinny .war problem (there was indeed a jar file in the war; there shouldn't have been) then the application did not deploy. I'm attaching another copy which I regard as the copy that I should have attached in the first place; again I'm sorry for having put one out there that wasn't proofed accurately. Thanks again for looking into this. Best, Laird
                                • 13. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                                  ljnelson-JavaNet
                                  First bug filed: https://glassfish.dev.java.net/issues/show_bug.cgi?id=12268 This relates to the fact that the ear/lib directory is not scanned for resource classes.  The Java EE 6 specification implies that it should be.  A discussion on the Jersey mailing list also indicates that this should be possible: http://jersey.576304.n2.nabble.com/Specification-question-regarding-packaging-td4941418.html#a4941418 I will file another bug related to dependency injection.
                                  • 14. Re: JAX-RS on Glassfish 3.1: @EJB injection?
                                    392 Guest
                                    On Jun 16, 2010, at 2:15 PM, glassfish@javadesktop.org wrote: > Thanks, Paul, for the quick response. > > I apologize for the configuration; I thought I had proofed the thing  > better than that.  I've been through so many configurations that a  > bad one slipped through the cracks. > > I found some other issues as well. > > It turns out that looking for resources in the .ear does NOT work.   > That is, once I cleared up the skinny .war problem (there was indeed  > a jar file in the war; there shouldn't have been) then the  > application did not deploy. > > I'm attaching another copy which I regard as the copy that I should  > have attached in the first place; again I'm sorry for having put one  > out there that wasn't proofed accurately. > But in any case it did show up another issue with CDI where your  previous example did work on 3.0 but not on 3.0.1 and 3.1 b04. When i deploy the new example you provide i get the following  deployment error: SEVERE: Exception while loading the app org.glassfish.deployment.common.DeploymentException: WELD-001201 Error  loading beans.xml java.io.IOException: Cannot open a foreign URL;  this.url=jar:file:/Users/paulsandoz/Downloads/glassfish-bugs%25202/ frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar!/META-INF/beans.xml;  foreign.url=jar:file:/Users/paulsandoz/Downloads/glassfish-bugs%25202/ frobnicator/ear/target/gfdeploy/ljnelson_frobnicator-ear_ear_1.0- SNAPSHOT/lib/frobnicator-jaxrs-1.0-SNAPSHOT.jar!/META-INF/beans.xml          at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:167)          at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java: 125)          at  org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java: 237)          at  com .sun .enterprise .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:355)          at  com .sun .enterprise .v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:199)          at  org .glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java: 286) If i remove the beans.xml then i can deploy and then i get the  following in the logs when i access the URL:    http://localhost:8080/frobnicator-war/frobnication/frobnicator INFO: WEB0671: Loading application [ljnelson_frobnicator-ear_ear_1.0- SNAPSHOT#frobnicator-war-1.0-SNAPSHOT.war] at [/frobnicator-war] INFO: ljnelson_frobnicator-ear_ear_1.0-SNAPSHOT was successfully  deployed in 2,800 milliseconds. INFO: Updating configuration from org.apache.felix.fileinstall- autodeploy-bundles.cfg INFO: Installed /Users/paulsandoz/Applications/GlassFish/3.1/b04/ glassfishv3/glassfish/modules/autostart/org.apache.felix.fileinstall- autodeploy-bundles.cfg INFO: {felix.fileinstall.poll (ms) = 5000, felix.fileinstall.dir = / Users/paulsandoz/Applications/GlassFish/3.1/b04/glassfishv3/glassfish/ domains/domain1/autodeploy/bundles, felix.fileinstall.debug = -1,  felix.fileinstall.bundles.new.start = true, felix.fileinstall.tmpdir  = /var/folders/vd/vdTgcMYGEb0tkynCTcnFH++++TI/-Tmp-/ fileinstall--6530420101675025480, felix.fileinstall.filter = null} INFO: GlobalStatsProvider registered INFO: Initiating Jersey application, version 'Jersey: 1.1.5 01/20/2010  04:04 PM' INFO: Adding the following classes declared in META-INF/services/ jersey-server-components to the resource configuration:    class com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider    class com.sun.jersey.multipart.impl.MultiPartConfigProvider    class com.sun.jersey.multipart.impl.MultiPartReader    class com.sun.jersey.multipart.impl.MultiPartWriter INFO: Instantiating the Application class, named  ljnelson.frobnicator.war.Application. The following root resource and  provider classes are registered: [class  ljnelson.frobnicator.jaxrs.FrobnicatorResource] INFO: Binding the Managed bean class  ljnelson.frobnicator.jaxrs.FrobnicatorResource to  ManagedBeanComponentProvider SEVERE: The RuntimeException could not be mapped to a response, re- throwing to the HTTP container java.lang.IllegalStateException: Dependency injection of junk failed          at  ljnelson .frobnicator .jaxrs.FrobnicatorResource.doFrobnication(FrobnicatorResource.java:54) The reason being is i do not think @ManagedBean supports 330 injection  rules when CDI is not enabled. So if you modify the resource method to  do:    @GET    @Produces("text/plain")    public String doFrobnication() { //    if (this.junk == null) { //      throw new IllegalStateException("Dependency injection of junk  failed"); //    }      if (this.frobnicator == null) {        throw new IllegalStateException("Dependency injection of  frobnicator failed");      }      return frobnicator.frobnicate();    } it works for me. Paul. > Thanks again for looking into this. > > Best, > Laird > [Message sent by forum member 'ljnelson'] > > http://forums.java.net/jive/thread.jspa?messageID=474474 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net > For additional commands, e-mail: users-help@glassfish.dev.java.net > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net For additional commands, e-mail: users-help@glassfish.dev.java.net
                                    1 2 Previous Next