<< Back to previous view

[GLASSFISH-15936] Enabled interceptor class is neither annotated @Interceptor nor registered through a portable extension Created: 10/Feb/11  Updated: 13/Jun/11  Resolved: 13/Jun/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1_b41
Fix Version/s: 3.1.1_b05

Type: Bug Priority: Major
Reporter: mwessendorf Assignee: Sivakumar Thyagarajan
Resolution: Fixed Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: File CDIBUG2.war    
Tags: 3_1-exclude
Participants: mwessendorf and Sivakumar Thyagarajan

 Description   

Deploying the attached WAR (beans.xml placed in WEB-INF/beans.xml) I am getting a "DeploymentException".

Please note that the JARs in WEB-INF/lib do ship CDI extensions and they are registered in META-INF/beans.xml (of the particular JAR)



 Comments   
Comment by mwessendorf [ 10/Feb/11 05:11 AM ]

[#|2011-02-10T14:04:31.547+0100|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=100;_ThreadName=Thread-1;|Exception while loading the app : WELD-001417 Enabled interceptor class <class>org.apache.myfaces.extensions.cdi.jpa.impl.TransactionalInterceptor</class> in file:/home/matzew/work/source/JAX2011/glassfish3/glassfish/domains/domain1/generated/jsp/CDIBUG2/loader_13252949/META-INF/beans.xml@25 is neither annotated @Interceptor nor registered through a portable extension
org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.apache.myfaces.extensions.cdi.jpa.impl.TransactionalInterceptor</class> in file:/home/matzew/work/source/JAX2011/glassfish3/glassfish/domains/domain1/generated/jsp/CDIBUG2/loader_13252949/META-INF/beans.xml@25 is neither annotated @Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:500)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:373)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:390)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:190)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:298)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:354)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:369)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1260)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1248)
at org.glassfish.admingui.common.util.LocalDeploymentFacility$LocalDFCommandRunner.run(LocalDeploymentFacility.java:143)
at org.glassfish.deployment.client.AbstractDeploymentFacility.deploy(AbstractDeploymentFacility.java:406)
at org.glassfish.admingui.common.util.DeployUtil.invokeDeploymentFacility(DeployUtil.java:100)
at org.glassfish.admingui.common.util.DeployUtil.deploy(DeployUtil.java:76)
at org.glassfish.admingui.common.handlers.DeploymentHandler.deploy(DeploymentHandler.java:191)
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.jsftemplating.layout.descriptors.handler.Handler.invoke(Handler.java:442)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:420)
at com.sun.jsftemplating.layout.descriptors.LayoutElementBase.dispatchHandlers(LayoutElementBase.java:394)
at com.sun.jsftemplating.layout.event.CommandActionListener.invokeCommandHandlers(CommandActionListener.java:150)
at com.sun.jsftemplating.layout.event.CommandActionListener.processAction(CommandActionListener.java:98)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:88)
at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:769)
at javax.faces.component.UICommand.broadcast(UICommand.java:300)
at com.sun.webui.jsf.component.WebuiCommand.broadcast(WebuiCommand.java:166)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:223)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.doChainInvoke(StandardPipeline.java:600)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:96)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:228)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)

Comment by mwessendorf [ 10/Feb/11 05:12 AM ]

It says:

Enabled interceptor class <class>org.apache.myfaces.extensions.cdi.jpa.impl.TransactionalInterceptor</class> in file:/home/matzew/work/source/JAX2011/glassfish3/glassfish/domains/domain1/generated/jsp/CDIBUG2/loader_13252949/META-INF/beans.xml@25 is neither annotated @Interceptor nor registered through a portable extension

However, this is just wrong:
https://svn.apache.org/repos/asf/myfaces/extensions/cdi/tags/extcdi-0.9.2/jee-modules/jpa-module/impl/src/main/java/org/apache/myfaces/extensions/cdi/jpa/impl/TransactionalInterceptor.java

Comment by Sivakumar Thyagarajan [ 11/Feb/11 05:11 AM ]

Analysis: This occurs because of the issue https://issues.jboss.org/browse/WELD-846 (see related GlassFish issue http://java.net/jira/browse/GLASSFISH-15721) around handling Beans from multiple accessible Bean Deployment Archives in a WAR.

In this deployment scenario, there are two bean archives in WEB-INF/lib that houses enabled Interceptors. In GlassFish this is rightly represented as:
[|ID: CDIBUG2, bdaType= WAR, accessibleBDAs #:19, [WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2,WEB-INF/lib/interceptor,,,,,,,,,,,,,,,,,,], Bean Classes #: 3,[net.wessendorf.enterprise.faces.HelloController, net.wessendorf.enterprise.service.PersonService, net.wessendorf.enterprise.service.PersonServerImpl], ejbs=[]

---->ID: WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2, bdaType= UNKNOWN, accessibleBDAs #:2, [WEB-INF/lib/interceptor,CDIBUG2,], Bean Classes #: 369,[...], ejbs=[]
---->ID: WEB-INF/lib/interceptor, bdaType= JAR, accessibleBDAs #:2, [WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2,CDIBUG2,], Bean Classes #: 2,[net.wessendorf.enterprise.cdi.Timer, net.wessendorf.enterprise.cdi.LoggingInterceptor], ejbs=[]

However when Weld is validating this Bean archive during deployment, while the code tries to find out if the enabled intercetors in the BeanManager of WEB-INF/lib/interceptor.jar are in the list of its accessible interceptors, the list of accessible interceptors is incorrect and the validator fails.

Workaround:
Since a right fix for this issue requires a new integration of Weld 1.2.0.Beta when it becomes available, please use the workaround described in GLASSFISH-15721 at [1] to work around the issue for GF3.1.

  • extract the contents of the two Bean archives WEB-INF/lib/interceptor and WEB-INF/lib/myfaces-extcdi-dist-jsf20-0.9.2 into WEB-INF/classes

[1] http://java.net/jira/browse/GLASSFISH-15721?focusedCommentId=301147&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_301147

Comment by Sivakumar Thyagarajan [ 11/Feb/11 05:13 AM ]

FYI.

I ensured that this scenario works against a local GlassFish 3.1 integration of trunk build of Weld/core merged with the changes in https://github.com/stuartwdouglas/core/tree/WELD-846. The application deployed with no changes and I was able to use the app

– server log snippet –
[#|2011-02-11T18:24:31.580+0530|INFO|glassfish3.2|org.apache.myfaces.extensions.cdi.jpa.impl.JpaModuleStartupObserver|_ThreadID=25;_ThreadName=http-thread-pool-8080(4);|[Started] MyFaces CODI JPA-Module v0.9.2

#]

[#|2011-02-11T18:24:31.610+0530|WARNING|glassfish3.2|org.apache.myfaces.extensions.cdi.core.impl.CoreStartupObserver|_ThreadID=25;_ThreadName=http-thread-pool-8080(4);|Core-Module couldn't log the current configuration.Startup will continue!|#]

[#|2011-02-11T18:24:31.619+0530|WARNING|glassfish3.2|org.apache.myfaces.extensions.cdi.jsf2.impl.ProjectStageObserver|_ThreadID=25;_ThreadName=http-thread-pool-8080(4);|The value of the JSF 2 project stage (Development) is different from the CODI project stage (Production)|#]

[#|2011-02-11T18:24:31.630+0530|INFO|glassfish3.2|org.apache.myfaces.extensions.cdi.scripting.impl.ScriptingModuleStartupObserver|_ThreadID=25;_ThreadName=http-thread-pool-8080(4);|[Started] MyFaces CODI Scripting-Module v0.9.2

#]

[#|2011-02-11T18:24:31.649+0530|INFO|glassfish3.2|org.apache.myfaces.extensions.cdi.bv.impl.BeanValidationModuleStartupObserver|_ThreadID=25;_ThreadName=http-thread-pool-8080(4);|[Started] MyFaces CODI Bean-Validation-Module v0.9.2|#]

[#|2011-02-11T18:24:36.226+0530|SEVERE|glassfish3.2|net.wessendorf.enterprise.service.PersonServerImpl|_ThreadID=26;_ThreadName=http-thread-pool-8080(3);|

HEY THERE!!!!!|#]

[#|2011-02-11T18:24:40.981+0530|SEVERE|glassfish3.2|net.wessendorf.enterprise.service.PersonServerImpl|_ThreadID=25;_ThreadName=http-thread-pool-8080(4);|

HEY THERE!!!!!|#]

[#|2011-02-11T18:26:35.755+0530|SEVERE|glassfish3.2|net.wessendorf.enterprise.service.PersonServerImpl|_ThreadID=26;_ThreadName=http-thread-pool-8080(3);|

HEY THERE!!!!!|#]
– server log snippet –

Comment by Sivakumar Thyagarajan [ 24/May/11 10:25 AM ]

Marked as 3_1_1-review. Need to verify that the integration of 1.1.1 fixes this and close it.

Comment by Sivakumar Thyagarajan [ 13/Jun/11 09:49 AM ]

Confirmed that the integration of Weld 1.1.1 into GlassFish 3.1.1(b4+) fixes this.

This issue has been fixed since the integration of Weld 1.1.1.Final (that fixes root cause WELD-846) into GlassFish 3.1.1(b4+) and GlassFish trunk.

Generated at Thu Apr 24 01:20:07 UTC 2014 using JIRA 4.0.2#472.