[JBoss JIRA] (WELD-996) ClassCastException validating custom Interceptor implementation
by Jozef Hartinger (Created) (JIRA)
ClassCastException validating custom Interceptor implementation
---------------------------------------------------------------
Key: WELD-996
URL: https://issues.jboss.org/browse/WELD-996
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.2.Final
Reporter: Jozef Hartinger
Priority: Critical
Fix For: 1.2.0.Beta1
Having a custom implementation of the Interceptor interface registered with Weld, the validation always fails if the interceptor happens to intercept a passivation capable bean. Weld incorrectly casts the interceptor to InterceptorImpl which is not valid for extension-provided interceptors.
{noformat}
java.lang.ClassCastException: org.jboss.seam.classic.intercept.ClassicInterceptor cannot be cast to org.jboss.weld.bean.InterceptorImpl
at org.jboss.as.weld.services.WeldService.start(WeldService.java:96)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.ClassCastException: org.jboss.seam.classic.intercept.ClassicInterceptor cannot be cast to org.jboss.weld.bean.InterceptorImpl
at org.jboss.weld.bootstrap.Validator.validateInterceptors(Validator.java:171)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:151)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:351)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:336)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:404)
at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
... 5 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] Created: (WELD-831) Weld throws an NPE thrown during failover between to jboss servers
by Fin Steenbjerg (JIRA)
Weld throws an NPE thrown during failover between to jboss servers
------------------------------------------------------------------
Key: WELD-831
URL: https://issues.jboss.org/browse/WELD-831
Project: Weld
Issue Type: Feature Request
Environment: OS: MS Windows (XP)
AS: Jboss 6.0.0 Final
JDK: 1.6.0_23 (sun/oracle jdk)
Reporter: Fin Steenbjerg
In a two node jboss environment a failover throws an exception (see description in the forum reference):
2011-01-18 20:55:13,222 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/clusteredcdi.web]] (ajp-127.0.0.1-8209-1) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
at org.jboss.weld.context.ForwardingContextual.toString(ForwardingContextual.java:52) [:6.0.0.Final]
at java.lang.String.valueOf(String.java:2826) [:1.6.0_23]
at java.lang.StringBuilder.append(StringBuilder.java:115) [:1.6.0_23]
at org.jboss.weld.context.SerializableContextualInstanceImpl.toString(SerializableContextualInstanceImpl.java:67) [:6.0.0.Final]
at java.lang.String.valueOf(String.java:2826) [:1.6.0_23]
at java.lang.StringBuilder.append(StringBuilder.java:115) [:1.6.0_23]
at org.jboss.weld.context.beanstore.AttributeBeanStore.attach(AttributeBeanStore.java:120) [:6.0.0.Final]
at org.jboss.weld.context.AbstractBoundContext.activate(AbstractBoundContext.java:75) [:6.0.0.Final]
at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:161) [:6.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:180) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62) [:6.0.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:504) [:6.0.0.Final]
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:437) [:6.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
Steps to Reproduce:
I have attached an ear file containing a single war module. Inside this war module there is a single class named Pojo (the source is there too) and a single xhtml page which uses the pojo class via CDI. It's very simple. (I have added a servlet filter that prints the session attributes for each request - but that can be removed if it is not wanted).
Test Setup
The jboss setup to use in order reproduce the problem is as follows:
1. A single Jboss installation with two server configurations called node01 and node02 (these are both copies of the all configuration)
2. An apache server in front of the two jboss nodes. The apache uses mod_cluster plugin.
3. The setup is started with the following script (sorry it is for ms windows):
start %~dp0..\..\apache-2.2\bin\httpd.exe
&& sleep 10
&& start %~dp0run.bat -c node01 -Djboss.jvmRoute=node01 -Djboss.mod_cluster.proxyList=127.0.0.1:6666 -Djboss.mod_cluster.excludedContexts=ROOT -Djboss.service.binding.set=ports-01
&& sleep 10&& start %~dp0run.bat -c node02 -Djboss.jvmRoute=node02 -Djboss.mod_cluster.proxyList=127.0.0.1:6666 -Djboss.mod_cluster.excludedContexts=ROOT -Djboss.service.binding.set=ports-02
&& sleep 45
&& start http://localhost:8080/mod_cluster-manager
4. Deploy the the clusteredcdi.ear file to farm folder belonging to one of the jboss configurations being used.
Test execution
1. Make a request via the apache server http://localhost:8080/clusteredcdi.web/faces/pages/cdi.xhtml
2. Enter something into the form and submit via the "set new value" button.
3. Kill the jboss server process that handled the request
4. Refresh the browser window in which the request above was submitted.
5. The error occurs.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WELD-988) beans.xml schema validation should be configurable to turn if off
by Manuel Hartl (Created) (JIRA)
beans.xml schema validation should be configurable to turn if off
-----------------------------------------------------------------
Key: WELD-988
URL: https://issues.jboss.org/browse/WELD-988
Project: Weld
Issue Type: Enhancement
Components: Bootstrap and Metamodel API
Affects Versions: 1.1.2.Final
Environment: Windows7 / weld 1.1.2 / tomcat6
Reporter: Manuel Hartl
Priority: Minor
- when you use the standard beans.xml schema location in your beans.xml (referencing http://java.sun.com/xml/ns/javaee/beans_1_0.xsd) then WELD tries to look it up on the internet.
- Currently (10.10.2011) oracle seems to have technical issues with their web servers and returns an html error page when accessing the URL. this leads to a very long startup of our weld applications because of url retrieval timeouts and in most cases even leads to a stopping of the web application
-> in my opinion there should be configuration option (system property?) to turn schema validation of beans.xml off.
for production environments this is often not neccessary and maybe even will result in a speedup.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] Created: (WELD-702) Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e
by sreekanth manga (JIRA)
Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e
------------------------------------------------------------------------------------------------------------------------
Key: WELD-702
URL: https://jira.jboss.org/browse/WELD-702
Project: Weld
Issue Type: Bug
Components: Testing Infrastructure (Mocks and Harness Integration)
Environment: Linux,Glassfish v3.1
Reporter: sreekanth manga
Priority: Minor
This issue seems to be glassfish specific issue.Couple of tests are failing with non glassfish supported use of annotaion @WebServlet..
1)In the test, org.jboss.weld.tests.scope.RemoteScopeTest, there is a servlet by name RemoteClient using the annotation "@WebServlet("*")".
2)In the test resource.EMFFactoryTest, there are 3 servlets EMFConsumerTest1, EMFConsumerTest2, EMFConsumerTest3 which uses the annotation @WebServlet("emfconsumer") with out a leading "/" .
As per discussion in weld dev alias, this syntax is supported is vendor specific feature of JBoss.
Glassfish server log:
================
#|2010-10-04T20:28:02.679+0530|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app [jsr88-637718205897341632]|#]
[#|2010-10-04T20:28:02.745+0530|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app [jsr88-637718205897341632] : Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e
Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375)
at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134)
at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:611)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:460)
at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:447)
at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:423)
at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:398)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:263)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:272)
at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:233)
at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:171)
at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:85)
at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:729)
at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:671)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:343)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:239)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:351)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:360)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:375)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:101)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1229)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1218)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:375)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220)
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:530)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].
at com.sun.enterprise.deployment.annotation.handlers.WebServletHandler.processAnnotation(WebServletHandler.java:191)
at com.sun.enterprise.deployment.annotation.handlers.WebServletHandler.processAnnotation(WebServletHandler.java:118)
at com.sun.enterprise.deployment.annotation.handlers.AbstractWebHandler.processAnnotation(AbstractWebHandler.java:121)
at com.sun.enterprise.deployment.annotation.handlers.WebServletHandler.processAnnotation(WebServletHandler.java:68)
at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344)
... 45 more
|#]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] Created: (WELD-949) Move firing of ContainerInitialized event from StartMain to the end of Weld.initialize()
by Ondrej Zizka (JIRA)
Move firing of ContainerInitialized event from StartMain to the end of Weld.initialize()
----------------------------------------------------------------------------------------
Key: WELD-949
URL: https://issues.jboss.org/browse/WELD-949
Project: Weld
Issue Type: Feature Request
Components: Java SE Support
Affects Versions: 1.1.1.Final
Reporter: Ondrej Zizka
Priority: Optional
I suggest to move firing of ContainerInitialized event from StartMain to the end of Weld.initialize().
Rationale:
* Having this done by Weld.initialize() is more expectable() than having it restricted to a concrete class.
* With the event fired from the end of initialize(), users who bootstrap Weld on their own would not need to introduce their own "startup", or worse, fire ContainerInitialized on their own.
* Backward compatible - currently only StartMain() fires the event. In case of this change, firing would be removed from StartMain(), so the current behavior would not change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] Created: (WELD-877) "IllegalStateException: Context is already active" when error-page of exception-type com.sun.faces.context.FacesFileNotFoundException
by Cory Prowse (JIRA)
"IllegalStateException: Context is already active" when error-page of exception-type com.sun.faces.context.FacesFileNotFoundException
-------------------------------------------------------------------------------------------------------------------------------------
Key: WELD-877
URL: https://issues.jboss.org/browse/WELD-877
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.1.0.Final
Environment: Glassfish 3.1
Reporter: Cory Prowse
Weld throws an exception of "IllegalStateException: Context is already active" when attempting to access a facelets page that doesn't exist (one that matches the url-pattern for the FacesServlet).
Attached is a minimal war (contains no class files) which exhibits this error.
The web application works if the "WEB-INF/beans.xml" file is removed (not a solution for an application using Weld).
Simplified stack trace is:
[#|2011-03-31T20:16:28.406+1000|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=169;_ThreadName=Thread-2;|org.apache.catalina.core.StandardHostValve@1042d3b: Exception Processing ErrorPage[exceptionType=com.sun.faces.context.FacesFileNotFoundException, location=/notFound.xhtml]
javax.servlet.ServletException: Context is already active
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:422)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
...
Caused by: java.lang.IllegalStateException: Context is already active
at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:301)
at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:110)
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
... 27 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] Created: (WELD-891) Singleton is not set exception for extension observer of BeforeShutdown event
by Aaron Anderson (JIRA)
Singleton is not set exception for extension observer of BeforeShutdown event
-----------------------------------------------------------------------------
Key: WELD-891
URL: https://issues.jboss.org/browse/WELD-891
Project: Weld
Issue Type: Bug
Components: Events
Affects Versions: 1.1.1.Final
Environment: Weld SE
Reporter: Aaron Anderson
Attachments: weldext.zip
When updating to Weld 1.1.1.Final from Weld 1.1.0.Final (this version works fine) the following exception is thrown during a Weld shutdown() invocation:
225509 [main] ERROR org.jboss.weld.Bootstrap - Exception(s) thrown during observ
er of BeforeShutdown
225509 [main] ERROR org.jboss.weld.Bootstrap -
java.lang.IllegalStateException: Singleton is not set
at org.jboss.weld.bootstrap.api.helpers.IsolatedStaticSingletonProvider$
IsolatedStaticSingleton.get(IsolatedStaticSingletonProvider.java:52)
at org.jboss.weld.context.AbstractSharedContext.getBeanStore(AbstractSha
redContext.java:54)
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:93)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.j
ava:690)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.
java:264)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.jav
a:234)
at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractC
ontainerEvent.java:88)
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdow
nImpl.java:62)
at org.jboss.weld.bootstrap.events.BeforeShutdownImpl.fire(BeforeShutdow
nImpl.java:50)
at org.jboss.weld.bootstrap.WeldBootstrap.shutdown(WeldBootstrap.java:49
1)
at org.jboss.weld.environment.se.ShutdownManager.shutdown(ShutdownManage
r.java:45)
at org.jboss.weld.environment.se.org$jboss$weld$bean-classpath-ManagedBe
an-org$jboss$weld$environment$se$ShutdownManager$@javax$enterprise$context$Appli
cationScoped()${}_$$_WeldClientProxy.shutdown(org$jboss$weld$bean-classpath-Mana
gedBean-org$jboss$weld$environment$se$ShutdownManager$@javax$enterprise$context$
ApplicationScoped()${}_$$_WeldClientProxy.java)
at org.jboss.weld.environment.se.Weld.shutdown(Weld.java:169)
at org.apache.ode.server.event.EventTest.tearDownAfterClass(EventTest.ja
va:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
Method.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
lable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe
thod.java:41)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.ja
va:37)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:35)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4
Provider.java:146)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider
.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.inv
oke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(Suref
ireStarter.java:145)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(S
urefireStarter.java:87)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:
69)
Running the code through a debugger it looks like my CDI extension, which is not annotated with a scope annotation, is being placed in the ApplicationScope context but when Weld shutdowns the following code is invoked
WeldBootstrap line 490:
try
{
applicationContext.invalidate();
BeforeShutdownImpl.fire(deploymentManager, beanDeployments);
}
which invalidates the context the extension exists in before invoking the shutdown event on the extension thus causing the exception.
Please download and run the attached maven example by running mvn clean test
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] Created: (WELD-916) Weld 1.1.1 not working with Solder 3.0.0.Final
by Daniel Kvasnička (JIRA)
Weld 1.1.1 not working with Solder 3.0.0.Final
----------------------------------------------
Key: WELD-916
URL: https://issues.jboss.org/browse/WELD-916
Project: Weld
Issue Type: Bug
Components: Servlet Container Support
Affects Versions: 1.1.1.Final
Environment: JDK6, Tomcat 6, weld-servlet 1.1.1.Final, seam-solder 3.0.0.Final, seam-servlet 3.0.0.Final
Reporter: Daniel Kvasnička
Priority: Blocker
org.jboss.weld.environment.servlet.provider.WeldServletBeanManagerProvider is compiled using org.jboss.weld.extensions.beanManager.BeanManagerProvider, which no longer exists in Seam Solder.
Also it looks like the same code is still in Git repository in the latest version.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months