February 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] (WELD-1020) NPE during cleanup after Servlet API3 AsyncContect

by Manuel Hartl (Created) (JIRA)

NPE during cleanup after Servlet API3 AsyncContect -------------------------------------------------- Key: WELD-1020 URL: https://issues.jboss.org/browse/WELD-1020 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.1.4.Final, 1.1.2.Final Environment: Windows7, Tomcat 7.0.23 Reporter: Manuel Hartl When using Weld with Servlet API3.0 AsyncContext, there will be a NullPointerException, when Weld tries to cleanup the request. There seems to be a problem when asyncContext.complete() is called in a thread that was not the original thread that received the request example for the exception: java.lang.NullPointerException at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:71) at org.jboss.weld.context.http.HttpRequestContextImpl.deactivate(HttpRequestContextImpl.java:86) at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:103) at org.jboss.weld.servlet.api.helpers.ForwardingServletListener.requestDestroyed(ForwardingServletListener.java:42) at org.apache.catalina.core.StandardContext.fireRequestDestroyEvent(StandardContext.java:5973) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:283) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1515) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:523) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1575) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- 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, 2 months

4
3
0 / 0

[JBoss JIRA] (WELD-1055) Exception when deploying EJB with duplicated Interceptors-annontation is not informative enough

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-1055?page=com.atlassian.jira.plugin.... ] Ales Justin updated WELD-1055: ------------------------------ Fix Version/s: 1.2.0.Beta1 Description: {noformat} 13:11:12,017 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."xxx.ear".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."xxx.ear".WeldService: org.jboss.interceptor.proxy.InterceptorException: Duplicate interceptor class definition when bindingorg.jboss.interceptor.reader.SimpleInterceptorMetadata@1db7445 on AROUND_INVOKE {noformat} The exception should contains information regarding the interceptor or the annotated class: org.jboss.interceptor.builder.InterceptionModelImpl Line 162: {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor + " on " + interceptionType.name());{code} should at least be {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor.getInterceptorClass().getClassName() + " on " + interceptionType.name());{code} was: {noformat} 13:11:12,017 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."xxx.ear".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."xxx.ear".WeldService: org.jboss.interceptor.proxy.InterceptorException: Duplicate interceptor class definition when bindingorg.jboss.interceptor.reader.SimpleInterceptorMetadata@1db7445 on AROUND_INVOKE {noformat} The exception should contains information regarding the interceptor or the annotated class: org.jboss.interceptor.builder.InterceptionModelImpl Line 162: {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor + " on " + interceptionType.name());{code} should at least be {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor.getInterceptorClass().getClassName() + " on " + interceptionType.name());{code} > Exception when deploying EJB with duplicated Interceptors-annontation is not informative enough > ----------------------------------------------------------------------------------------------- > > Key: WELD-1055 > URL: https://issues.jboss.org/browse/WELD-1055 > Project: Weld > Issue Type: Enhancement > Affects Versions: 1.1.5.Final > Reporter: Simon Walter > Assignee: Marko Lukša > Priority: Minor > Fix For: 1.2.0.Beta1 > > > {noformat} > 13:11:12,017 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: > Failed to start service jboss.deployment.unit."xxx.ear".WeldService: > org.jboss.msc.service.StartException in service jboss.deployment.unit."xxx.ear".WeldService: > org.jboss.interceptor.proxy.InterceptorException: > Duplicate interceptor class definition when bindingorg.jboss.interceptor.reader.SimpleInterceptorMetadata@1db7445 on AROUND_INVOKE > {noformat} > The exception should contains information regarding the interceptor or the annotated class: > org.jboss.interceptor.builder.InterceptionModelImpl Line 162: {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor + " on " + interceptionType.name());{code} should at least be > {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor.getInterceptorClass().getClassName() + " on " + interceptionType.name());{code} -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WELD-1055) Exception when deploying EJB with duplicated Interceptors-annontation is not informative enough

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-1055?page=com.atlassian.jira.plugin.... ] Ales Justin reassigned WELD-1055: --------------------------------- Assignee: Marko Lukša > Exception when deploying EJB with duplicated Interceptors-annontation is not informative enough > ----------------------------------------------------------------------------------------------- > > Key: WELD-1055 > URL: https://issues.jboss.org/browse/WELD-1055 > Project: Weld > Issue Type: Enhancement > Affects Versions: 1.1.5.Final > Reporter: Simon Walter > Assignee: Marko Lukša > Priority: Minor > Fix For: 1.2.0.Beta1 > > > {noformat} > 13:11:12,017 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: > Failed to start service jboss.deployment.unit."xxx.ear".WeldService: > org.jboss.msc.service.StartException in service jboss.deployment.unit."xxx.ear".WeldService: > org.jboss.interceptor.proxy.InterceptorException: > Duplicate interceptor class definition when bindingorg.jboss.interceptor.reader.SimpleInterceptorMetadata@1db7445 on AROUND_INVOKE > {noformat} > The exception should contains information regarding the interceptor or the annotated class: > org.jboss.interceptor.builder.InterceptionModelImpl Line 162: {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor + " on " + interceptionType.name());{code} should at least be > {code}throw new InterceptorException("Duplicate interceptor class definition when binding" + interceptor.getInterceptorClass().getClassName() + " on " + interceptionType.name());{code} -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WELD-1063) Don't combine slf4j-ext:1.6.4 (which requies cal10n-api:0.7.4) with a lower incompatible version cal10n-api:0.7.2

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created WELD-1063: -------------------------------------- Summary: Don't combine slf4j-ext:1.6.4 (which requies cal10n-api:0.7.4) with a lower incompatible version cal10n-api:0.7.2 Key: WELD-1063 URL: https://issues.jboss.org/browse/WELD-1063 Project: Weld Issue Type: Bug Reporter: Geoffrey De Smet {code} IncompatibleDependencyOverwrite error for ch.qos.cal10n:cal10n-api:0.7.2 paths to dependency are: +-org.jboss.weld:weld-core:1.1.5.Final +-ch.qos.cal10n:cal10n-api:0.7.2 and +-org.jboss.weld:weld-core:1.1.5.Final +-org.slf4j:slf4j-ext:1.6.4 +-ch.qos.cal10n:cal10n-api:0.7.4 {code} The classpath will use cal10n-api:0.7.2 and slf4j-ext:1.6.4, but the latter expects a higher version. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] (WELD-1064) Upgrade dependency jboss-interceptors-api from 1.0.0.Beta1 to 1.0.0.Final

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created WELD-1064: -------------------------------------- Summary: Upgrade dependency jboss-interceptors-api from 1.0.0.Beta1 to 1.0.0.Final Key: WELD-1064 URL: https://issues.jboss.org/browse/WELD-1064 Project: Weld Issue Type: Task Reporter: Geoffrey De Smet Priority: Minor Now it's: {code} +-org.jboss.weld:weld-core:1.1.5.Final +-org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Beta1 {code} {code} +-org.jboss.weld:weld-core:1.1.5.Final +-javax.enterprise:cdi-api:1.0-SP4 +-org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Beta1 {code} But that's not in sync with what is used on JBoss AS 7.0.2 (which is an older release then weld 1.1.5.Final). {code} +-org.jboss.as:jboss-as-ee:7.0.2.Final +-org.jboss.spec.javax.interceptor:jboss-interceptors-api_1.1_spec:1.0.0.Final {code} -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] (WELD-1011) Move jboss interceptors into Weld

by Jozef Hartinger (Created) (JIRA)

Move jboss interceptors into Weld --------------------------------- Key: WELD-1011 URL: https://issues.jboss.org/browse/WELD-1011 Project: Weld Issue Type: Task Components: Interceptors and Decorators Affects Versions: 1.1.3.SP1 Reporter: Stuart Douglas Assignee: Jozef Hartinger Fix For: 2.0.0.Alpha1 (12:36:44 PM) stuartdouglas: jharting: you could actually do that for the 2.0 branch already (12:37:20 PM) stuartdouglas: it should be pretty easy just to move the code out of jboss interceptors and into weld trunk (12:40:01 PM) stuartdouglas: Its not high priority, and I would talk to Marius first -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] (CDITCK-267) Section 6.6.2 fourth bullet needs a test

by Jason Porter (JIRA)

Jason Porter created CDITCK-267: ----------------------------------- Summary: Section 6.6.2 fourth bullet needs a test Key: CDITCK-267 URL: https://issues.jboss.org/browse/CDITCK-267 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Jason Porter CDI 1.0 Specification states (Section 6.6.2): {quote} A bean is called a passivation capable dependency if any contextual reference for that bean is preserved when the object holding the reference is passivated and then activated. The container must guarantee that: • all session beans are passivation capable dependencies, • all beans with normal scope are passivation capable dependencies, • all passivation capable beans with scope @Dependent are passivation capable dependencies, • all resources are passivation capable dependencies, and • the built-in beans of type Instance, Event, InjectionPoint and BeanManager are passivation capable dependencies. A custom implementation of Bean is a passivation capable dependency if it implements Scope() returns a normal scope type. {quote} There is no test for the fourth bullet. Such resources would include the entitymanager and other items from JNDI (mind is drawing a blank atm). -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] (WELD-1067) Thread safety issue in BeansClosure

by Magesh Bojan (JIRA)

Magesh Bojan created WELD-1067: ---------------------------------- Summary: Thread safety issue in BeansClosure Key: WELD-1067 URL: https://issues.jboss.org/browse/WELD-1067 Project: Weld Issue Type: Bug Affects Versions: 1.1.4.Final Environment: AS 7.1.0.CR1b Reporter: Magesh Bojan The getClosure() method does not synchronize on get. This leads to multiple Weld deployments on AS7 calling the get method, all at once and leads to the following error: java.lang.NullPointerException at org.jboss.weld.manager.BeanManagerImpl.getMostSpecializedBean(BeanManagerImpl.java:931) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:605) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:228) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:207) at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:75) at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:46) at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:46) at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:322) at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:80) at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- 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, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-34) Make special note in the spec about @Named beans (via a stereotype) cannot be selected with Instance.select()

by Shane Bryzak (JIRA)

Make special note in the spec about @Named beans (via a stereotype) cannot be selected with Instance.select() ------------------------------------------------------------------------------------------------------------- Key: CDI-34 URL: https://issues.jboss.org/browse/CDI-34 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Shane Bryzak Priority: Minor For example, say we have the following bean: public @Model class Foo implements IFoo { } And we have the following injection point within another bean: @Inject Instance<Foo> fooInstance; It is not possible to select Foo via name using the Instance: // This results in an UnsatisfiedDependencyException Foo foo = fooInstance.select(new NamedLiteral("foo")).get(); Instead, Foo must be annotated directly with the @Named annotation itself: /* * This Foo can be selected by name */ public @Named @RequestScoped Foo implements IFoo { } This special case might be worthwhile mentioning in the next revision of the spec. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
7
0 / 0

[JBoss JIRA] Created: (CDITCK-212) DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created

by Stuart Douglas (JIRA)

DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created ---------------------------------------------------------------------------------------------------------- Key: CDITCK-212 URL: https://issues.jboss.org/browse/CDITCK-212 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Stuart Douglas Context applicationContext = getCurrentManager().getContext(ApplicationScoped.class); destroyContext(applicationContext); setContextActive(applicationContext); myApplicationBeanInstance = applicationContext.get(myApplicationBean); The spec does not require that the application scope can be destroyed and re-created, if fact it could be argued that this behaviour violates the spec, as the application context is supposed to last for the lifetime of the application. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues February 2012