[JBoss JIRA] Created: (WELD-332) Link against EL API 2.2 (rather than 2.1)
by Dan Allen (JIRA)
Link against EL API 2.2 (rather than 2.1)
-----------------------------------------
Key: WELD-332
URL: https://jira.jboss.org/jira/browse/WELD-332
Project: Weld
Issue Type: Feature Request
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.0.GA
Reporter: Dan Allen
Fix For: 1.0.1.CR1
We should link against the EL API 2.2 rather than 2.1. EL 2.2 has support for parametrized method expressions, which Red Hat pushed strongly for to get into Java EE 6. Therefore, we should not only be supporting it, but showing it off. Right now, using a parametrized method expression in a Facelets view throws an exception.
We also need to push this upstream into JBoss AS 6 so that EL 2.2 is supported out of the box. Right now, it ain't.
javax.faces.view.facelets.TagAttributeException: /home.xhtml @26,140 action="#{game.check(game.guess)}" Error Parsing: #{game.check(game.guess)}
com.sun.faces.facelets.tag.TagAttributeImpl.getMethodExpression(TagAttributeImpl.java:225)
com.sun.faces.facelets.tag.jsf.ActionSourceRule$ActionMapper2.applyMetadata(ActionSourceRule.java:97)
com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:74)
javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:122)
javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:96)
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153)
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:120)
com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:204)
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:114)
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:97)
com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:172)
com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:386)
com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:357)
com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:102)
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:86)
javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:91)
com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:75)
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:301)
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:360)
com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:339)
com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:191)
com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:149)
com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:86)
com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:75)
com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:145)
com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:715)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:311)
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:68)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
--
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, 10 months
[JBoss JIRA] Created: (CDITCK-60) Use of @WebServiceRef is not portable
by Santiago Pericas-Geertsen (JIRA)
Use of @WebServiceRef is not portable
-------------------------------------
Key: CDITCK-60
URL: https://jira.jboss.org/jira/browse/CDITCK-60
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Environment: solaris x86 / JDK 16u6 / GF v3
Reporter: Santiago Pericas-Geertsen
Fix For: 1.0.1.CR1
The tests,
*.context.application.ejb.ApplicationContextSharedTest.testApplicationContextShared
*.context.application.ejb.EJBApplicationContextTest.testApplicationScopeActiveDuringCallToEjbTimeoutMethod
*.context.application.ejb.EJBApplicationContextTest.testApplicationScopeActiveDuringWebServiceInvoation
use the @WebServiceRef annotation in a non-portable way causing a failure in GF v3. The structure of the test is as follows:
----------
import javax.ejb.Local;
@javax.ejb.Local
public interface FeederService
{
public void refillFood();
public boolean adequateFood();
}
------------------------
@Stateless
@WebService
public class BirdFeederService implements FeederService
{
...
}
--------------
@Stateless
public class CommonKingfisher implements Bird
{
@WebServiceRef
private FeederService birdFeeder;
public void eat()
{
birdFeeder.refillFood();
}
--------------------
The use of @WebServiceRef is not portable because FeederService is not a JAX-WS SEI.
--
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, 10 months
[JBoss JIRA] Created: (CDITCK-59) EAR package is not portable
by Santiago Pericas-Geertsen (JIRA)
EAR package is not portable
---------------------------
Key: CDITCK-59
URL: https://jira.jboss.org/jira/browse/CDITCK-59
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.1.CR1
Environment: Solaris x86 / JDK 6u16 / GF v3
Reporter: Santiago Pericas-Geertsen
Priority: Critical
The following TCK tests,
testInjectionOfDependentPrimitiveProductIntoNormalBean
testInjectionOfDependentSerializableProductIntoNormalBean
testNonSerializableProducerFieldDeclaredPassivatingThrowsIllegalProductException
testPassivatingScopeProducerMethodReturnsUnserializableObjectNotOk
related to the EAR,
org.jboss.jsr299.tck.tests.context.passivating.PassivatingContextTest.ear
fail with the following exception in GF v3,
attached to this wiki [1] which generates the following exception when deployed:
java.lang.RuntimeException: by java.lang.IllegalAccessError: class org.jboss.jsr299.tck.tests.context.passivating.NumberConsumer_$$_javassist_389 cannot access its superclass org.jboss.jsr299.tck.tests.context.passivating.NumberConsumer
at javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:344)
at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:314)
at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:273)
at org.jboss.weld.util.Proxies.createProxyClass(Proxies.java:153)
at org.jboss.weld.util.Proxies.createProxy(Proxies.java:136)
The reason for this failure is that the WAR in the EAR above does not include a Class-Path entry in its manifest to be able to load classes from the JAR. This manifest entry is required for portability. Note that GF v3 now uses the TCCL with Javassist.
--
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, 10 months
[JBoss JIRA] Created: (WELD-356) @PersistenceContext not injected in target bean when bean is intercepted
by William Draï (JIRA)
@PersistenceContext not injected in target bean when bean is intercepted
------------------------------------------------------------------------
Key: WELD-356
URL: https://jira.jboss.org/jira/browse/WELD-356
Project: Weld
Issue Type: Bug
Components: Interceptors and Decorators
Affects Versions: 1.0.0.GA
Environment: JBoss 6.0.0.M1 and GlassFish V3 final
Reporter: William Draï
Say you have this bean :
@MyInterceptorBinding
public class MyServiceBean implements MyService {
@PersistenceContext
protected EntityManager entityManager;
@Inject @Any
private Event<MyEvent> myEvent;
public Object persist(Object obj) {
entityManager.persist(obj);
myEvent.fire(new MyEvent());
return obj;
}
}
Where @MyInterceptorBinding is a simple interceptor binding with a trivial interceptor implementation :
@MyInterceptorBinding @Interceptor
public class MyInterceptor {
@AroundInvoke
public Object doInvoke(InvocationContext context) {
Object result = null;
try {
return context.proceed();
}
catch (Exception e) {
throw new RuntimeException("error", e);
}
}
The MyEvent field of the bean is correctly injected with an MyEventImpl, but the entityManager is null.
When the bean is not interceptor, the entityManager field is correctly injected.
--
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, 10 months
[JBoss JIRA] Created: (WELD-317) SFSB initialization fails to detect injectable initializer methods of super class
by Vivek Pandey (JIRA)
SFSB initialization fails to detect injectable initializer methods of super class
----------------------------------------------------------------------------------
Key: WELD-317
URL: https://jira.jboss.org/jira/browse/WELD-317
Project: Weld
Issue Type: Bug
Components: Bootstrap and Metamodel API
Affects Versions: 1.0.0.GA
Environment: glassfish v3, jdk6 u15, weld tck 1.0.1
Reporter: Vivek Pandey
This is regarding org.jboss.jsr299.tck.tests.lookup.injection.enterprise.SessionBeanInjectionOrderingTest. It tests order in which a SFSB's postConstruct and its superclass's initializers are called. Basically the super class's initializer should be called first before the subclass's postConstruct. However there seems to be a bug in Weld, as it skips the superclass initializer for this SFSB.
@Stateful
public class MegaPoorHenHouse extends PoorHenHouse implements MegaPoorHenHouseLocal
{
//There is no initializer() method in it, but Weld adds one during bean deploy
@PostConstruct
public void postConstruct() {
//
}
}
class PoorHenHouse extends HenHouse
{
@Inject
public void initialize() {
//
}
}
Weld does not invoke PoorHenHouse.initialize(). There seems to be a bug there. I think Beans.getInitializerMethods() should start looking for injectable initialize() method starting from the superclass at the end of the chain.
Looking in to the debugger it seems that during Bean deploy Weld is adding initialize() method to MegaPoorHenHouse. Inside Beans.getInitializerMethods(), when the MegaPoorHenHouse is processed to find initializer methods it finds the initializer method and adds it to seenMethod list. Since on the MegaPoorHenHouse the intializer() method dynamically added by Weld is not an injection point so its not added to the list of initializedMethods. Latter when the super class PoorHenHouse is processed to find injectable initialize() method isOverridden() returns true, as initialize() method was added to seenMethod list while processing the subclass, and the legitimate intialize() method on the this super class is skipped.
===>if (!isOverridden(method, seenMethods))
{
MethodInjectionPoint<?, ?> initializerMethod = MethodInjectionPoint.of(declaringBean, method);
initializerMethods.add(initializerMethod);
}
--
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, 10 months
[JBoss JIRA] Created: (CDITCK-78) Weld does not scan packaged jar in EAR file for Extension or the packaging is wrong
by Vivek Pandey (JIRA)
Weld does not scan packaged jar in EAR file for Extension or the packaging is wrong
-----------------------------------------------------------------------------------
Key: CDITCK-78
URL: https://jira.jboss.org/jira/browse/CDITCK-78
Project: CDI TCK
Issue Type: CTS Challenge
Security Level: Public (Everyone can see)
Affects Versions: 1.0.1.CR1
Reporter: Vivek Pandey
Either its a bug in Weld or its packaging issue of org.jboss.jsr299.tck.tests.extensions.container.event.ContainerEventTest.ear appears to be incorrect.
Here is the content of this ear file of a jsr299 tck test:
org.jboss.jsr299.tck.tests.extensions.container.event.ContainerEventTest.ear
-META-INF/services/javax.enterprise.inject.spi.Extension ==> with entries for Observer classes
- org.jboss.jsr299.tck.tests.extensions.container.event.ContainerEventTest.jar
- ...
The META-INF/services//javax.enterprise.inject.spi.Extension entries are defined as:
org.jboss.jsr299.tck.tests.extensions.container.event.ProcessBeanObserver
org.jboss.jsr299.tck.tests.extensions.container.event.ProcessInjectionTargetObserver
org.jboss.jsr299.tck.tests.extensions.container.event.ProcessAnnotatedTypeObserver
Weld does not scan org.jboss.jsr299.tck.tests.extensions.container.event.ContainerEventTest.jar for presence of Extension in the included jar file. If this behavior is not what jsr299 spec desires then a tleast the packaging should be such that the META-INF/services Extension classes are moved inside the jar file. JSR 299 is not clear on this but It seems that it should be expected to scan all the jars files included in the EAR file for presence of Extension.
--
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, 10 months