[JBoss JIRA] Created: (WELD-239) AbstractProducerBean.checkReturnValue seems to check against the wrong injection point
by Huy Le (JIRA)
AbstractProducerBean.checkReturnValue seems to check against the wrong injection point
--------------------------------------------------------------------------------------
Key: WELD-239
URL: https://jira.jboss.org/jira/browse/WELD-239
Project: Weld
Issue Type: Bug
Components: Producers (Methods, Fields and Disposers)
Affects Versions: 1.0.0.CR1
Environment: Weld 1.0.0.CR1, embedded Jetty
Reporter: Huy Le
I was running a modified version of the numberguess example (attached to this issue) and got the following exception which doesn't seem quite right:
javax.enterprise.inject.IllegalProductException: Producers cannot produce non-serializable instances for injection into non-transient fields of passivating beans
Producer: org.jboss.weld.bean-web-module-ProducerMethod-org.jboss.weld.examples.numberguess.FacesContextManager.getFacesContext()
Injection Point: field org.jboss.weld.examples.numberguess.Game.maxNumber
at org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:201)
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:287)
at org.jboss.weld.context.AbstractMapContext.get(AbstractMapContext.java:104)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:139)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:97)
at javax.faces.context.FacesContext_$$_javassist_7.getELContext(FacesContext_$$_javassist_7.java)
at org.jboss.weld.examples.numberguess.Generator.getMaxNumber(Generator.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:111)
at org.jboss.weld.examples.numberguess.Generator_$$_javassist_6.getMaxNumber(Generator_$$_javassist_6.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:227)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstance(MethodInjectionPoint.java:148)
at org.jboss.weld.bean.ProducerMethod$1.produce(ProducerMethod.java:117)
at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:286)
at org.jboss.weld.context.DependentContext.get(DependentContext.java:62)
at org.jboss.weld.BeanManagerImpl.getReference(BeanManagerImpl.java:899)
at org.jboss.weld.BeanManagerImpl.getReference(BeanManagerImpl.java:945)
at org.jboss.weld.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:967)
at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:78)
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:683)
at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695)
at org.jboss.weld.bean.ManagedBean$1$1.proceed(ManagedBean.java:195)
at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:51)
at org.jboss.weld.bean.ManagedBean$1.inject(ManagedBean.java:189)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:115)
at org.jboss.weld.context.AbstractMapContext.get(AbstractMapContext.java:104)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.getProxiedInstance(ClientProxyMethodHandler.java:139)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:97)
at org.jboss.weld.examples.numberguess.Game_$$_javassist_5.getNumber(Game_$$_javassist_5.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Not sure if my analysis is correct, but it seems that:
1. FieldInjectionPoint for maxNumber is set as the current injection point in BeanManagerImpl
2. Producer method for maxNumber is invoked
3. The getELContext method is invoked on the FacesContext proxy
4. The getProxiedInstance method is invoked on ClientProxyMethodHandler which causes the producer method for FacesContext to be invoked
5. The checkReturnValue on AbstractProducerBean is invoked, but it is checking the FacesContext return value against the injection point for maxNumber (since this is still the current injection point) an an IllegalProductException is thrown since maxNumber must be serializable (but not FacesContext)
--
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
14 years, 5 months
[JBoss JIRA] Created: (WELD-238) Classes specified in beans.xml/interceptors should not need to be annotated with @Interceptor
by Jozef Hartinger (JIRA)
Classes specified in beans.xml/interceptors should not need to be annotated with @Interceptor
---------------------------------------------------------------------------------------------
Key: WELD-238
URL: https://jira.jboss.org/jira/browse/WELD-238
Project: Weld
Issue Type: Bug
Components: Interceptors and Decorators
Affects Versions: 1.0.0.CR1
Reporter: Jozef Hartinger
Assignee: Marius Bogoevici
Fix For: 1.0.0.CR2
Currently, the RI requires every class defined in beans.xml under "interceptors" element to be annotated with @Interceptor. Otherwise, the container throws the following exception : "org.jboss.jsr299.tck.DeploymentError: org.jboss.weld.DeploymentException: Class org.jboss.jsr299.tck.tests.interceptors.definition.custom.Interceptor1 is enabled as an interceptor, but it does not have the appropriate annotation"
However, this is too restrictive (and conflicting with the spec), since in case when the interceptor is registered via portable extension (using custom implementation of the Interceptor interface), the class should not be required to be annotated with @Interceptor.
--
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
14 years, 5 months
[JBoss JIRA] Created: (WELD-226) 'Default' event observer doesn't get notified when firing events (with qualifiers) directly with the manager
by Fabio Wang (JIRA)
'Default' event observer doesn't get notified when firing events (with qualifiers) directly with the manager
------------------------------------------------------------------------------------------------------------
Key: WELD-226
URL: https://jira.jboss.org/jira/browse/WELD-226
Project: Weld
Issue Type: Bug
Components: Events
Affects Versions: 1.0.0.CR1
Environment: Apache Tomcat 6.0.20
Reporter: Fabio Wang
An observer with this signature:
observe(@Observes XEvent event) {...}
is not notified when an event is fired like this:
manager.fireEvent(new XEvent(), new AnyLiteralQualifier(), new AnyLiteralQualifier2(), ...);
If the observer specifies any of the LiteralQualifiers (or any subset of them, except the empty one), then it's notified.
However, if fired like this:
manager.fireEvent(new XEvent(), new DefaultLiteral(), new AnyLiteralQualifier(), new AnyLiteralQualifier2(), ...);
with the DefaultLiteral among the qualifiers, then it works as expected.
Firing an event with an Event<XEvent> also works.
--
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
14 years, 5 months
[JBoss JIRA] Created: (WELD-221) Infinite Mutual Recursion in HierarchyDiscovery.resolveType
by Clint Popetz (JIRA)
Infinite Mutual Recursion in HierarchyDiscovery.resolveType
-----------------------------------------------------------
Key: WELD-221
URL: https://jira.jboss.org/jira/browse/WELD-221
Project: Weld
Issue Type: Bug
Affects Versions: 1.0.0.CR1
Reporter: Clint Popetz
Assignee: Pete Muir
The following:
abstract class ChoiceParent<T> { }
class Choice<T, E> extends ChoiceParent<T>
{
public Choice<T, E> aMethod()
{
return null;
}
}
will produce an infinite recursion between resolveType and resolveTypeParameter if weld tries to load it. I've added a class to test/ in org.jboss.weld.test.unit.implementation.annotatedItem that triggers this, but it caused the build to fail, so it's been excluded. To enable, remove the @Classes annotation from the top of org.jboss.weld.test.unit.implementation.annotatedItem.ClassAnnotatedItemTest, which is excluding the deployment of Choice and ChoiceParent
--
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
14 years, 5 months