August 2011 - weld-issues - Jboss List Archives

[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

6
9
0 / 0

[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

7
8
0 / 0

[JBoss JIRA] Created: (WELD-953) WEB-INF/beans.xml is ignored on jetty 6 (and GWT hosted mode)

by Geoffrey De Smet (JIRA)

WEB-INF/beans.xml is ignored on jetty 6 (and GWT hosted mode) -------------------------------------------------------------- Key: WELD-953 URL: https://issues.jboss.org/browse/WELD-953 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Geoffrey De Smet Using @Inject in a class in a war file does not do nothing if there is only a WEB-INF/beans.xml and everything is deployed to Jetty 6. Similar for GWT hosted mode (which uses jetty 6 under the covers). Workaround: move it to META-INF/beans.xml -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
4
0 / 0

[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

4
3
0 / 0

[JBoss JIRA] Created: (WELD-948) Weld parent points to jboss nexus in repository settings

by Max Rydahl Andersen (JIRA)

Weld parent points to jboss nexus in repository settings -------------------------------------------------------- Key: WELD-948 URL: https://issues.jboss.org/browse/WELD-948 Project: Weld Issue Type: Bug Reporter: Max Rydahl Andersen Priority: Critical I was playing with mvn today and wanted to use: <dependency> <groupId>org.jboss.spec</groupId> <artifactId>jboss-javaee-6.0</artifactId> <version>1.0.0.Final</version> <type>pom</type> <scope>provided</scope> </dependency> as described on http://community.jboss.org/wiki/WhatsTheCauseOfThisExceptionJavalangClass... And I wanted to see what happens when I *only* have maven central setup. To my surprise I saw this in mvn log: Downloaded: http://repo1.maven.org/maven2/javax/enterprise/cdi-api/1.0-SP4/cdi-api-1.... (7 KB at 10.0 KB/sec) Downloading: http://repo1.maven.org/maven2/org/jboss/weld/weld-parent/17/weld-parent-1... Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/weld/w... Downloaded: https://repository.jboss.org/nexus/content/groups/public/org/jboss/weld/w... (31 KB at 4.1 KB/sec) And yes it seems weld-parent explicitly lists repository.jboss.org in its parent pom forcing this repo to be used for resolving dependencies afaics. Even if I have nexus configured to control my dependencies it will visit that ;( Our pom's should not force the choice of repository. Please re-release without these references. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (WELD-947) Fix reference to other chapter (in 5.6. The @New qualifier)

by Ondrej Zizka (JIRA)

Fix reference to other chapter (in 5.6. The @New qualifier) ----------------------------------------------------------- Key: WELD-947 URL: https://issues.jboss.org/browse/WELD-947 Project: Weld Issue Type: Bug Components: Documentation Reporter: Ondrej Zizka Priority: Minor http://docs.jboss.org/weld/reference/latest/en-US/html_single/#d0e2044 At the end of "5.6. The @New qualifier", there's: {quote} This feature is particularly useful with producer methods, as we'll see in the next chapter. {quote} The next chapter is about something else. The referenced chapter is: III. Loose coupling with strong typing 8. Producer methods -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (WELD-929) Typos in documentation

by Jozef Hartinger (JIRA)

Typos in documentation ---------------------- Key: WELD-929 URL: https://issues.jboss.org/browse/WELD-929 Project: Weld Issue Type: Bug Components: Documentation Affects Versions: 1.1.1.Final Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1.2.Final contexts.xml: spell check failed on 'abilty' contexts.xml: spell check failed on 'containber' contexts.xml: spell check failed on 'deactivaed' contexts.xml: spell check failed on 'discociating' contexts.xml: spell check failed on 'easiy' contexts.xml: spell check failed on 'http' (should be HTTP) contexts.xml: spell check failed on 'Http' (should be HTTP) contexts.xml: spell check failed on 'implmentations' contexts.xml: spell check failed on 'Javadoc' (should be JavaDoc) environments.xml: spell check failed on 'Programatic' environments.xml: spell check failed on 'situtations' extend.xml: spell check failed on 'dicussed' extend.xml: spell check failed on 'instatiate' extend.xml: spell check failed on 'Javadoc' gettingstarted.xml: spell check failed on 'eclispe' gettingstarted.xml: spell check failed on 'Glassfish' (should be GlassFish) injection.xml: spell check failed on 'alterative' injection.xml: spell check failed on 'ambigous' injection.xml: spell check failed on 'annotatons' injection.xml: spell check failed on 'appling' injection.xml: spell check failed on 'decare' injection.xml: spell check failed on 'prodcuer' injection.xml: spell check failed on 'refactoring' interceptors.xml: spell check failed on 'Whoah' part5.xml: spell check failed on 'Glassfish' (should be GlassFish) resources.xml: spell check failed on 'nonportable' (should be non-portable) ri-spi.xml: repeated instance(s) of 'that'. ri-spi.xml: spell check failed on 'configuation' ri-spi.xml: spell check failed on 'intercepter' ri-spi.xml: spell check failed on 'programtically' weldexamples.xml: spell check failed on 'ommitted' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
4
0 / 0

[JBoss JIRA] Created: (WELD-958) URLScanner parses the wrong META-INF/beans.xml files if the parent classloader has a META-INF/beans.xml file

by Geoffrey De Smet (JIRA)

URLScanner parses the wrong META-INF/beans.xml files if the parent classloader has a META-INF/beans.xml file ------------------------------------------------------------------------------------------------------------ Key: WELD-958 URL: https://issues.jboss.org/browse/WELD-958 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Geoffrey De Smet Priority: Critical Note that WELD-714 (fixed for 1.1.0.CR1) does NOT fix this in weld 1.1.2.Final. Here's the code that causes the problem: {code} public class URLScanner { ... protected void handleArchiveByFile(File file, ...) ... { ... ZipFile zip = new ZipFile(file); Enumeration<? extends ZipEntry> entries = zip.entries(); // Replace out the default classloader with one for the zip URLClassLoader classLoader = new URLClassLoader(new URL[] { file.toURI().toURL() }); // PROBLEM PART 1: delegates first to parent classloader while (entries.hasMoreElements()) { ZipEntry entry = entries.nextElement(); String name = entry.getName(); handle(..., classLoader.getResource(name), ...); // PROBLEM PART 2: if parent classloader contains that name, the file content is ignored! } ... } ... } {code} Here's what's happens with this input: {code} file = /tmp/tomcat-embedded-6/work/arquillian-tomcat-embedded-6/localhost/guvnor-webapp-5.3.0-SNAPSHOT/WEB-INF/lib/seam-persistence-api-3.1.0.Beta2.jar classLoader = URL is file:/tmp/tomcat-embedded-6/work/arquillian-tomcat-embedded-6/localhost/guvnor-webapp-5.3.0-SNAPSHOT/WEB-INF/lib/seam-persistence-api-3.1.0.Beta2.jar for each entry, when: name = "META-INF/beans.xml" classLoader.getResource(name) = file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml // WRONG // Should be = .../seam-persistence-api-3.1.0.Beta2.jar!META-INF/beans.xml {code} As a direct result, URLScanner.handle(...) handles the same wrong META-INF/beans.xml file multiple times (one for each real META-INF/beans.xml): {code} Handle file META-INF/beans.xml from file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml Handle file META-INF/beans.xml from file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml Handle file META-INF/beans.xml from file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml ... {code} For more info, see this gist: https://gist.github.com/1180446 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-205) Add test to verify extensions in non-bean archives are loaded

by Dan Allen (JIRA)

Add test to verify extensions in non-bean archives are loaded ------------------------------------------------------------- Key: CDITCK-205 URL: https://issues.jboss.org/browse/CDITCK-205 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Dan Allen Priority: Minor Add a test to answers this question: Does an extension have to be in an bean archive in order to be loaded? Section 11.5 states: "An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services." If one assumes that "service provider" refers to the term defined in the jar specification [1], then one would conclude that an extension does not have to be in a bean archive to be recognized (these are orthogonal concerns). A test for this scenario is available in the OpenTCK project and may be ported to the CDI TCK. [2] [1] http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Se... [2] 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

12 years, 6 months

2
2
0 / 0

[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

12 years, 6 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues August 2011