[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[JBoss JIRA] Created: (CDITCK-206) Add test to verify visibly of beans registered explicitly through an extension in non-bean archives
by Dan Allen (JIRA)
Add test to verify visibly of beans registered explicitly through an extension in non-bean archives
---------------------------------------------------------------------------------------------------
Key: CDITCK-206
URL: https://issues.jboss.org/browse/CDITCK-206
Project: CDI TCK
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: Dan Allen
Add a test that answers this question:
Can an extension register a bean programmatically for a class that resides in another non-bean archive?
This question requires a short example which is available in the OpenTCK test suite and may be ported to the CDI TCK [1].
Assume one archive, a.jar, has the following contents:
org/opentck/javaee/cdi/spi/beforebeandiscovery/BeanClassToRegister.class
A second archive, b.jar, has the following contents:
org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherBeanClassToRegister.class
org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherManualBeanRegistrationExtension.class
org/opentck/javaee/cdi/spi/beforebeandiscovery/ManualBeanRegistrationExtension.class
META-INF/services/javax.enterprise.inject.spi.Extension
AnotherBeanClassToRegister has an injection point of type BeanClassToRegister:
public class AnotherBeanClassToRegister {
@Inject
private BeanClassToRegister collaborator;
}
BeanClassToRegister and AnotherBeanClassToRegister are added as beans programmatically in respective extensions listed in the service provider descriptor:
public class ManualBeanRegistrationExtension implements Extension {
public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) {
event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class));
}
}
public class AnotherManualBeanRegistrationExtension implements Extension {
public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) {
event.addAnnotatedType(bm.createAnnotatedType(AnotherBeanClassToRegister.class));
}
}
The two libraries, a.jar and b.jar are bundled in a web archive, test.war
WEB-INF/lib/a.jar
WEB-INF/lib/b.jar
WEB-INF/beans.xml
Deploying this archive to the reference implementation fails with an error message that the injection point from above cannot be satisfied. There appears to be a visibility problem across bean archives in this case.
Adding META-INF/beans.xml to a.jar and removing the ManualBeanRegistrationExtension from b.jar resolves the issue in the reference implementation.
[1] https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent...
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (WELD-878) WeldPhaseListener fails to activate conversation context if conversation is not found
by Jarkko Hyöty (JIRA)
WeldPhaseListener fails to activate conversation context if conversation is not found
-------------------------------------------------------------------------------------
Key: WELD-878
URL: https://issues.jboss.org/browse/WELD-878
Project: Weld
Issue Type: Bug
Components: Conversations, Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.1.0.Final
Environment: Glassfish 3.1 B43 updated with weld-1.1.0-SNAPSHOT (weld-osgi-bundle-1.1.0-20110329.041630-9.jar)
Reporter: Jarkko Hyöty
It seems that org.jboss.weld.jsf.WeldPhaseListener fails to activate conversation context if a conversation is not found by the supplied conversation id. This problem is potentially related to [SEAMCATCH-46],[WELD-855].
JSR-299 6.7.4 Conversation context lifecycle has a requirement that 'If the propagated conversation cannot be restored, the container _must associate the request with a new transient conversation_ and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore view phase of the JSF lifecycle.'. However, the implementation of org.jboss.weld.jsf.WeldPhaseListener.activateConversations fails to do that if a conversation is not found by the conversation id.
{code}
private void activateConversations(FacesContext facesContext)
{
ConversationContext conversationContext = instance().select(HttpConversationContext.class).get();
String cid = getConversationId(facesContext, conversationContext);
log.debug(RESUMING_CONVERSATION, cid);
if (cid != null && conversationContext.getConversation(cid) == null)
{
throw new NonexistentConversationException(NO_CONVERSATION_FOUND_TO_RESTORE, cid);
}
conversationContext.activate(cid);
}
{code}
Recovering from the exception becomes difficult since the context is not active. Typical symptom is 'java.lang.IllegalStateException: Unable to load current conversations from the associated request, something went badly wrong when associate() was called
at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:413)'
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (CDITCK-176) Decorator Elements in beans.xml use <decorator> not <class>
by Pete Muir (JIRA)
Decorator Elements in beans.xml use <decorator> not <class>
-----------------------------------------------------------
Key: CDITCK-176
URL: https://jira.jboss.org/browse/CDITCK-176
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.2.CR2
Reporter: Pete Muir
Fix For: 1.0.2.CR3
Affected tests:
testPassivationCapableBeanWithNonPassivatingDecoratorBeanConstructorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor.DecoratorWithNonPassivatingBeanConstructorTest)
testPassivationCapableBeanWithNonPassivatingInitializerInDecoratorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod.DecoratorWithNonPassivatingInitializerMethodTest)
testPassivationCapableBeanWithNonPassivatingDecoratorInjectedFieldFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField.DecoratorWithNonPassivatingInjectedFieldTest)
testEnterpriseBeanWithNonPassivatingDecoratorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.enterpriseBeanWithNonPassivatingDecorator.EnterpriseBeanWithNonPassivatingDecoratorTest)
testDecoratorListedTwiceInBeansXmlNotOK(org.jboss.jsr299.tck.tests.decorators.definition.broken.decoratorListedTwiceInBeansXml.DecoratorListedTwiceInBeansXmlTest)
testNonExistantDecoratorClassInBeansXmlNotOK(org.jboss.jsr299.tck.tests.decorators.definition.broken.nonExistantClassInBeansXml.NonExistantDecoratorClassInBeansXmlTest)
--
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
13 years, 2 months