December 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-464) Decorators are not applied to custom beans

by Stuart Douglas (JIRA)

Decorators are not applied to custom beans ------------------------------------------ Key: WELD-464 URL: https://jira.jboss.org/jira/browse/WELD-464 Project: Weld Issue Type: Bug Reporter: Stuart Douglas Beans added with AfterBeanDiscovery.addBean() do not have decorators applied -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (CDI-4) Need a way to provide ordering for Event observers (@Observes)

by Lincoln Baxter III (JIRA)

Need a way to provide ordering for Event observers (@Observes) -------------------------------------------------------------- Key: CDI-4 URL: https://jira.jboss.org/browse/CDI-4 Project: CDI Specification Issues Issue Type: Feature Request Environment: All Reporter: Lincoln Baxter III There needs to be a way to specify some kind of ordering for Event observers. Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API. -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (WELD-573) Event qualifier resolution is upside down

by Pete Muir (JIRA)

Event qualifier resolution is upside down ----------------------------------------- Key: WELD-573 URL: https://jira.jboss.org/browse/WELD-573 Project: Weld Issue Type: Bug Components: Events Reporter: Pete Muir Priority: Blocker Fix For: 1.1.0.BETA1 Currently, we are checking that every qualifier on an observer method is on the event, should be that every qualifier on the event is on the observer method. See TypeSafeObserverResolver#matches() -- 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, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (CDI-6) Clarify InjectionTarget method parameters

by Jozef Hartinger (JIRA)

Clarify InjectionTarget method parameters ----------------------------------------- Key: CDI-6 URL: https://jira.jboss.org/browse/CDI-6 Project: CDI Specification Issues Issue Type: Task Components: Specification Affects Versions: 1.0 Reporter: Jozef Hartinger For the inject() method, the spec says: "inject() performs dependency injection upon the given object". It is not clear to me what does the "given object" refer two. if the CDI implementation uses proxies to implement interceptors and decorators, I can see two candidates for "the given object": - the product of the produce() method including interceptors and decorators -> a proxy - the target instance -> the object created by calling a constructor (no interception/decoration) Arguments for the first option - Let's have and extension that adds additional dependency injection capabilities by providing a custom InjectionTarget implementation and wrapping default InjectionTarget instances with custom ones. The custom InjectionTarget implementation does the additional DI in the inject() method and delegates to the default InjectionTarget instance to finish the injection. This implementation needs a direct access to the target instance (it cannot access field values through a proxy) - Interceptor-like behavior - similarity to interceptors, where the InvocationContext.getTarget() returns the (non-intercepted) target instance Arguments for the second option - the contract of the produce() method says: "produce() calls the constructor annotated @Inject if it exists, or the constructor with no parameters otherwise, as defined in Section 5.5.1, "Injection using the bean constructor", and returns the resulting instance. If the class has inter- ceptors, produce() is responsible for building the interceptors and decorators of the instance." which means it returns an intercepted/decorated instance. -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-5) 9.5.1 Around-Invoke Interceptor example have wrong signature

by Aslak Knutsen (JIRA)

9.5.1 Around-Invoke Interceptor example have wrong signature ------------------------------------------------------------ Key: CDI-5 URL: https://jira.jboss.org/browse/CDI-5 Project: CDI Specification Issues Issue Type: Bug Components: Specification Affects Versions: 1.0 Reporter: Aslak Knutsen The Interceptor example in section 9.5.1 use a illegal method signature for Around-Invoke interceptors: @AroundInvoke public void aroundInvoke() throws Exception { ... } (void and no InvocationContex argument) Around-invoke methods have the following signature: Object <METHOD>(InvocationContext) throws Exception -- 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, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes

by Stuart Douglas (JIRA)

Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes ------------------------------------------------------------------------------------------------------------ Key: CDI-3 URL: https://jira.jboss.org/browse/CDI-3 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes. Some of the things that the bean interface will not let you mimic are: - Interceptors - Disposal methods - Producer fields for normal scoped beans -- 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, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (CDI-2) Interceptor bindings defined at method level should override those at the class level

by Pete Muir (JIRA)

Interceptor bindings defined at method level should override those at the class level ------------------------------------------------------------------------------------- Key: CDI-2 URL: https://jira.jboss.org/browse/CDI-2 Project: CDI Specification Issues Issue Type: Bug Components: Specification Reporter: Pete Muir We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec. In section 9.5.2 of the spec: If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- 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, 11 months

1
2
0 / 0

[JBoss JIRA] Created: (WELD-812) Session serialization fails because of non-serializable org.jboss.weld.injection.SimpleInjectionPoint

by Sivakumar Thyagarajan (JIRA)

Session serialization fails because of non-serializable org.jboss.weld.injection.SimpleInjectionPoint ----------------------------------------------------------------------------------------------------- Key: WELD-812 URL: https://issues.jboss.org/browse/WELD-812 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.0.CR2 Reporter: Sivakumar Thyagarajan Fix For: 1.1.0.Final Our HA session serialization and failure testcase fails from the RC2 integration. This test case used to pass earlier(with BETA2). It appears that since Weld 1.1.0.RC2, the session has a non-serializable SimpleInjectionPoint in its closure of references that prevents serialization of the session. Please see the GlassFish issue http://java.net/jira/browse/GLASSFISH-15278 for more information. This prevents our HA failover scenarios. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
9
0 / 0

[JBoss JIRA] Created: (CDITCK-201) InjectionIntoWebServiceEndPointTest bundles incorrect artifacts

by Jozef Hartinger (JIRA)

InjectionIntoWebServiceEndPointTest bundles incorrect artifacts --------------------------------------------------------------- Key: CDITCK-201 URL: https://issues.jboss.org/browse/CDITCK-201 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.CR1 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.0.4.Final This is a problem with TCK not bundling correct web service artifacts which causes mismatch between client and server. Service has: @WebService(name="SheepWS") public class SheepWSEndPoint { ... @WebMethod public boolean testSheepInjected() { return (sheep != null) && initializerCalled; } } WSDL is created by the runtime/tools using testSheepInjected() method. So without customizations, wsimport generates the following artifacts from that wsdl: WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/TestSheepInjected.class WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/TestSheepInjectedResponse.class But, the bundled artifacts in the war are : WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/IsSheepInjected.class WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/IsSheepInjectedResponse.class and the annotations in these classes don't reflect what WSDL has(or what service is expecting) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

1
4
0 / 0

[JBoss JIRA] Created: (WELD-787) CurrentInjectionPoint ThreadLocal leak with Weld Servlet

by Aslak Knutsen (JIRA)

CurrentInjectionPoint ThreadLocal leak with Weld Servlet -------------------------------------------------------- Key: WELD-787 URL: https://issues.jboss.org/browse/WELD-787 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.1.0.Beta2 Environment: Weld Servlet 1.1.0-SNAPSHOT / Beta2 / Beta1 on Tomcat 6 Reporter: Aslak Knutsen Nov 22, 2010 7:13:40 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: The web application [/active1] created a ThreadLocal with key of type [null] (value [org.jboss.weld.injection.CurrentInjectionPoint$1@30b95f2]) and a value of type [java.util.Stack] (value [[]]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. The CurrentInjectionPoint push/pop works, since the Stack object on the Thread is Empty when undeploy. CurrentInjectionPoint.cleanup is called during the contextDestroyed lifecycle, but the event is executed on the main Thread, not the HTTP thread. This results in the Empty Stack leak. ThreadLocals active during a HTTP request has to be cleaned up at the end of the Request. There are no guarantees that you will ever see that Thread again. CurrentInjectionPoint.cleanup should probably be moved to the requestDestroyed lifecycle. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 12 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues December 2010