[ https://jira.jboss.org/jira/browse/WBRI-329?page=com.atlassian.jira.plugi... ] Pete Muir commented on WBRI-329: -------------------------------- On 5 Aug 2009, at 18:56, Kenneth Saks wrote: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WBRI-329?page=com.atlassian.jira.plugi... ] Pete Muir updated WBRI-329: --------------------------- Summary: Move EJB injection to InjectionTarget (was: NPE in org.jboss.webbeans.ejb.SessionBeanInterceptor @PostConstruct) Fix Version/s: 1.0.0.CR1 Description: Currently we perform 299 style injection into EJBs via an interceptor, I would prefer to move this to use the InjectionTarget SPI. (was: SessionBeanInterceptor @PostConstruct is throwing an NPE when the ejb container creates an instance of any session bean component type. The trace below is for a Singleton. These are all cases where there is no 299-specific interaction that causes the bean instance creation. It's just the ejb container creating the instance through some other path , e.g. to eagerly instantiate the Singleton during application startup or to resolve a direct JNDI lookup() from some application code. I haven't tried a stateful session bean creation via 299-apis or injection yet. SessionBeanInterceptor.initBean() first calls (EnterpriseBean<Object>) EnterpriseBeanProxyMethodHandler.getEnterpriseBean(), which returns null. It then calls (EnterpriseBean<Object>) CurrentManager.rootManager().getNewEnterpriseBeanMap().get(beanClass), which also returns null. That leads to the NPE on the line "this.beanId = this.bean.getId();" SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton SimpleSingleton at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:689) at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:432) at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:93) at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:62) at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:138) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:223) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:193) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:290) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:174) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:270) at com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:422) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:437) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:524) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:140) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:313) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:180) 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:208) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:752) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:660) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:911) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:164) 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.NIOContext.execute(NIOContext.java:510) at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:357) at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:257) at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:194) at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:129) at com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork(FixedThreadPool.java:379) at com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:360) at java.lang.Thread.run(Thread.java:637) Caused by: javax.ejb.CreateException: Initialization failed for Singleton SimpleSingleton at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:521) at com.sun.ejb.containers.AbstractSingletonContainer.access$100(AbstractSingletonContainer.java:70) at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:687) ... 37 more Caused by: java.lang.NullPointerException at org.jboss.webbeans.ejb.SessionBeanInterceptor.initBean(SessionBeanInterceptor.java:110) at org.jboss.webbeans.ejb.SessionBeanInterceptor.postConstruct(SessionBeanInterceptor.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:939) at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:61) at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:372) at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:355) at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:514) ... 39 more ) The original issue reported by Ken has sparked this move. His original report is SessionBeanInterceptor @PostConstruct is throwing an NPE when the ejb container creates an instance of any session bean component type. The trace below is for a Singleton. These are all cases where there is no 299-specific interaction that causes the bean instance creation. It's just the ejb container creating the instance through some other path , e.g. to eagerly instantiate the Singleton during application startup or to resolve a direct JNDI lookup() from some application code. I haven't tried a stateful session bean creation via 299-apis or injection yet. SessionBeanInterceptor.initBean() first calls (EnterpriseBean<Object>) EnterpriseBeanProxyMethodHandler.getEnterpriseBean(), which returns null. It then calls (EnterpriseBean<Object>) CurrentManager.rootManager().getNewEnterpriseBeanMap().get(beanClass), which also returns null. That leads to the NPE on the line "this.beanId = this.bean.getId();" SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton SimpleSingleton at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:689) at com.sun.ejb.containers.AbstractSingletonContainer.instantiateSingletonInstance(AbstractSingletonContainer.java:432) at org.glassfish.ejb.startup.SingletonLifeCycleManager.initializeSingleton(SingletonLifeCycleManager.java:93) at org.glassfish.ejb.startup.SingletonLifeCycleManager.doStartup(SingletonLifeCycleManager.java:62) at org.glassfish.ejb.startup.EjbApplication.start(EjbApplication.java:138) at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:223) at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:193) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:290) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:174) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:270) at com.sun.enterprise.v3.admin.CommandRunnerImpl$4.execute(CommandRunnerImpl.java:422) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:437) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:524) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:140) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:313) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:180) 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:208) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:752) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:660) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:911) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:164) 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.NIOContext.execute(NIOContext.java:510) at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKey(SelectorHandlerRunner.java:357) at com.sun.grizzly.SelectorHandlerRunner.handleSelectedKeys(SelectorHandlerRunner.java:257) at com.sun.grizzly.SelectorHandlerRunner.doSelect(SelectorHandlerRunner.java:194) at com.sun.grizzly.SelectorHandlerRunner.run(SelectorHandlerRunner.java:129) at com.sun.grizzly.util.FixedThreadPool$BasicWorker.dowork(FixedThreadPool.java:379) at com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:360) at java.lang.Thread.run(Thread.java:637) Caused by: javax.ejb.CreateException: Initialization failed for Singleton SimpleSingleton at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:521) at com.sun.ejb.containers.AbstractSingletonContainer.access$100(AbstractSingletonContainer.java:70) at com.sun.ejb.containers.AbstractSingletonContainer$SingletonContextFactory.create(AbstractSingletonContainer.java:687) ... 37 more Caused by: java.lang.NullPointerException at org.jboss.webbeans.ejb.SessionBeanInterceptor.initBean(SessionBeanInterceptor.java:110) at org.jboss.webbeans.ejb.SessionBeanInterceptor.postConstruct(SessionBeanInterceptor.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:939) at com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:61) at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:372) at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:355) at com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:514) ... 39 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WBRI-329?page=com.atlassian.jira.plugi... ] Pete Muir commented on WBRI-329: -------------------------------- Actually, I don't think we need a toggle. Web Beans should know [1] whether a class is one on which it should provide EE-style injection. In answer to your questions: Web Beans will only ever provide annotation based EE-style injection, so it won't inject bar2. I hope that we can use this to provide injection for contextual session beans as well as non-contextual ejbs; if this is true we don't need the interceptor. I need to work through the implications of this though. [1] I think this must be via an SPI as POJOs (no annotations) can be defined to be component classes via xml IIRC. In other words, Web Beans would query the EE server to find out whether it should perform EE-style injection or not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WBRI-329?page=com.atlassian.jira.plugi... ] Pete Muir commented on WBRI-329: -------------------------------- Ah, I missed a sentence out, I think. My suggestion is that for existing EE components (such as EJBs, servlets etc.) which the EE spec defines injection for, that Web Beans doesn't perform EE-style injection on these classes. Web Beans will only do CDI-style injection on these classes. CDI also allows other non-contextual instances (for example a Wicket component) and CDI style managed beans to receive EE-style injections (which no EE container supports today AFAIK). For CDI-style managed beans and other (not EE component) non-contextual instances, Web Beans would perform EE-style injection using the existing SPI. This, to me, seems the least intrusive path to go, whilst fully supporting the spec. As for your proposed SPI change around injection, yes I can see that the increase in flexibility offered might be useful. I would actually not limit this callback to "doEEStyleInjection", but simply make it a generic callback - inject(instance) - which can be used by any environment which wishes to perform other injection. This has come up as a requirement for JBoss AS for example. My only concern is that this places a fair amount of additional work on integrators over the simple "resolve" methods, so we need to provide a similar, simple mechanism that doesn't involve integrators having to scan the class for property and field annotations, build a caching system etc. Possibly we can make this an "either-or" approach, though that is generally an ugly semantic to express in an API. The argument about "iterate over every field" isn't really valid, Web Beans has to examine every field anyway (for example field injection, producer fields) so there is no overhead here, and we use an optimized approach already. I doubt a container can optimize this more. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WBRI-329?page=com.atlassian.jira.plugi... ] Pete Muir commented on WBRI-329: -------------------------------- I understand that your approach is easier on EE containers, however we also support non-EE environments. Consider for example an SE app which also wants to use JPA - for such an integration, it's much easier to support a resolve. Hence my suggested "either-or" approach. I wasn't talking about the 299 SPI inject - that is for injecting non-contextual instances. I was talking about a Web Beans SPI that allows the container to perform extra injections on any instance that is receiveing injection. I.e. a way for the container to provide additional injections (such as Java EE, or JBoss MC or...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/WBRI-329?page=com.atlassian.jira.plugi... ] Pete Muir commented on WBRI-329: -------------------------------- That is my proposal, I just need to find a decent way to express that through an API. Yes, probably this is a good approach. I thought about whether we still need an interceptor - we do (I think) so we can track EJB instance destruction. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira