June 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (CDITCK-220) BuiltInBeansTest.testUserTransactionBean()

by David Blevins (JIRA)

BuiltInBeansTest.testUserTransactionBean() ------------------------------------------ Key: CDITCK-220 URL: https://issues.jboss.org/browse/CDITCK-220 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: David Blevins We're passing this test, but wanted to drop a note that it should be updated. We just need to update this bean like so: {code} @Stateful @TransactionManagement(BEAN) public class UserTransactionInjectedBean implements UserTransactionInjectedBeanLocal { @Inject transient UserTransaction userTransaction; public UserTransaction getUserTransaction() { return userTransaction; } } {code} Only @Stateful session bean explicitly marked as @TransactionManagement(BEAN) are allowed to get UserTransaction via lookup or injection, the EJB TCK tests cover this pretty well. In OpenEJB we have deploy-time checks for this if @Resource is used to get a UserTransaction and we'd like to expand that checking to properly cover @Inject injection as well. Even though we are currently injecting that object and passing the test, it's a "false" pass and at runtime that UserTransaction object is hardwired to throw exceptions if used by a non-CMT bean. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
7
0 / 0

[JBoss JIRA] Created: (CDITCK-51) Support EEJB environment in harness

by Pete Muir (JIRA)

Support EEJB environment in harness ----------------------------------- Key: CDITCK-51 URL: https://jira.jboss.org/jira/browse/CDITCK-51 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Infrastructure Affects Versions: 1.0.0.GA Reporter: Pete Muir Fix For: 1.1.0.CR1 -- 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

12 years

2
3
0 / 0

[JBoss JIRA] Created: (CDITCK-42) Investigate using dependency:copy-dependencies rather than dependency:copy as it looks in the reactor

by Pete Muir (JIRA)

Investigate using dependency:copy-dependencies rather than dependency:copy as it looks in the reactor ----------------------------------------------------------------------------------------------------- Key: CDITCK-42 URL: https://jira.jboss.org/jira/browse/CDITCK-42 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Infrastructure Reporter: Pete Muir Fix For: 1.0.0.CR3 -- 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

12 years

2
4
0 / 0

[JBoss JIRA] Created: (CDITCK-223) EnterpriseBeanLifecycleTest.testCreateSFSB

by David Blevins (JIRA)

EnterpriseBeanLifecycleTest.testCreateSFSB ------------------------------------------ Key: CDITCK-223 URL: https://issues.jboss.org/browse/CDITCK-223 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: David Blevins This test is good except the last part where it checks for Serializable as an interface: {code} // Verify that the instance returned is a proxy by checking for all local interfaces assert getCurrentConfiguration().getBeans().isProxy(stadtInstance); Set<Class> interfaces = new HashSet<Class>(Arrays.asList(stadtInstance.getClass().getInterfaces())); Class c = stadtInstance.getClass(); Class[] cs = c.getInterfaces(); assert interfaces.contains(KleinStadt.class); assert interfaces.contains(SchoeneStadt.class); assert interfaces.contains(Serializable.class); {code} It isn't valid to check Serializable is a business local interface. Remote proxies are required to be serializable, but there's no explicit requirement for local proxies. Most vendors may do that for internal purposes (makes supporting passivation easier), but that's not something CDI needs to worry about. Our proxies actually are serializable -- they just don't implement the interface directly. It's done through another internal interface that takes care of a few other details, so this assert fails. On that note, we should probably change these asserts to: {code} // Verify that the instance returned is a proxy by checking for all local interfaces assert getCurrentConfiguration().getBeans().isProxy(stadtInstance); assert stadtInstance instanceof KleinStadt; assert stadtInstance instanceof SchoeneStadt; {code} Probably CDI doesn't need to care about the details on how the vendor ensures a proxy is assignable to the business local interfaces. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
2
0 / 0

[JBoss JIRA] Created: (WELD-845) Do not bundle slf4j static logger binding in weld-servlet.jar

by Kariem Hussein (JIRA)

Do not bundle slf4j static logger binding in weld-servlet.jar ------------------------------------------------------------- Key: WELD-845 URL: https://issues.jboss.org/browse/WELD-845 Project: Weld Issue Type: Feature Request Components: Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.0.Final Reporter: Kariem Hussein Bundling a static logger implementation with the weld-servlet.jar generates a warning that would not be necessary. The weld-servlet.jar (_uber jar_) is still (or arguably more) useful without the binding. Opened this ticket as [requested by Pete|http://seamframework.org/Community/Slf4jBindingInWeldservletjar#comm...] in response to a forum thread. This could be done similar to WELDSE-12 (requested in [this comment|https://issues.jboss.org/browse/WELDSE-12?focusedCommentId=125079...]). Assumed that WELDX and it successor SOLDER are not the right projects for this request. Related forum posts: * [slf4j Binding in weld-servlet.jar|http://seamframework.org/Community/Slf4jBindingInWeldser...] * [slf4j StaticLoggerBinder - This code should have never made it into the jar|http://seamframework.org/Community/Slf4jStaticLoggerBinderThisCodeSho...] * [Weld SE and slf4j|http://seamframework.org/Community/WeldSEAndSlf4j] -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
6
0 / 0

[JBoss JIRA] Created: (WELD-911) Shared dependent instance injection with circular reference through decorator

by Christian Bauer (JIRA)

Shared dependent instance injection with circular reference through decorator ----------------------------------------------------------------------------- Key: WELD-911 URL: https://issues.jboss.org/browse/WELD-911 Project: Weld Issue Type: Bug Components: Scopes & Contexts Affects Versions: 1.1.1.Final Reporter: Christian Bauer CDI spec section 6.4 says about @Dependent that "No injected instance of the bean is ever shared between multiple injection points." The following test shows that the same instance of @Dependent Foo is shared between multiple injection points, one in TestDecoratorInjection, the other in BarDecorator. {code} import org.jboss.weld.environment.se.Weld; import org.jboss.weld.environment.se.WeldContainer; import javax.annotation.PostConstruct; import javax.decorator.Decorator; import javax.decorator.Delegate; import javax.enterprise.inject.Any; import javax.inject.Inject; import javax.inject.Singleton; @Singleton public class TestDecoratorInjection { public static final Weld weld = new Weld(); public static final WeldContainer weldContainer = weld.initialize(); public static void main(final String[] args) throws Exception { weldContainer.instance().select(TestDecoratorInjection.class).get().test(); } @Inject Foo foo; // Dependent instance of TestDecoratorInjection void test() { foo.test(); } public static class Foo { @PostConstruct void init() { System.out.println("INIT FOO"); } @Inject Bar bar; // Dependent instance of Foo void print() { System.out.println("FOO"); } void test() { bar.print(); } } public static interface Bar { void print(); } public static class BarImpl implements Bar { @Override public void print() { System.out.println("Bar"); } } @Decorator public static abstract class BarDecorator implements Bar { @Inject @Delegate @Any Bar delegate; @Inject Foo foo; // Dependent instance of what?! @Override public void print() { foo.print(); } } } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (WELD-760) Duplicate interceptor: More than one jar

by Robson Saraiva Ximenes (JIRA)

Duplicate interceptor: More than one jar ---------------------------------------- Key: WELD-760 URL: https://jira.jboss.org/browse/WELD-760 Project: Weld Issue Type: Bug Components: Weld SPI Affects Versions: 1.0.1.Final Environment: Just Weld 1.0.1.Final Reporter: Robson Saraiva Ximenes Assignee: Marius Bogoevici I'm getting the following error when I try to use my Interceptor: Duplicate interceptor class definition... The entire description for this issue was related here: http://seamframework.org/Community/AnotherInterceptorProblem -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
10
0 / 0

[JBoss JIRA] Created: (WELD-537) More details to WELD-000072 Managed bean declaring a passivating scope must be passivation capable.

by Nicklas Karlsson (JIRA)

More details to WELD-000072 Managed bean declaring a passivating scope must be passivation capable. --------------------------------------------------------------------------------------------------- Key: WELD-537 URL: https://jira.jboss.org/browse/WELD-537 Project: Weld Issue Type: Feature Request Components: Class Beans (Managed and Session) Affects Versions: 1.0.1.Final Reporter: Nicklas Karlsson The error message should be more detailed, currently ManagedBean.initializeAfterBeanDiscovery can have multiple conditions that set the passivationCapableBean to false (non-serializable interceptors etc) but it's hard to tell exactly what is wrong. -- 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

12 years, 1 month

5
8
0 / 0

[JBoss JIRA] Created: (WELD-909) Dual faces mapping and cid parameter for conversational redirect

by Nicklas Karlsson (JIRA)

Dual faces mapping and cid parameter for conversational redirect ---------------------------------------------------------------- Key: WELD-909 URL: https://issues.jboss.org/browse/WELD-909 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.1.Final Reporter: Nicklas Karlsson Given a page like {code} <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core"> <h:head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <title>Concept</title> </h:head> <h:body> <f:view> <h:form> <h:commandButton value="redirect" action="page?faces-redirect=true"/> <h:commandButton value="non-transient" action="#{backingBean.nonTransient}"/> </h:form> </f:view> </h:body> </html> {code} and a backing bean like {code} package fi.nik.concept; import javax.enterprise.context.Conversation; import javax.inject.Inject; import javax.inject.Named; @Named public class BackingBean { @Inject private Conversation conversation; public String nonTransient() { conversation.begin(); return "page?faces-redirect=true"; } } {code} clicking "redirect" with non-transient conversations work fine but clicking "non-transient" duplicates the faces mappings and cid to something like http://localhost:8080/concept/faces/faces/page.xhtml?cid=1&cid=1 and clicking "redirect" after keeps the URL like that. It works normally after that (since the faces mapping is still hit and the cid is repeated with the same value) but it looks a bit odd. Would have written a test for it but git on Windows is... a bit nonlinear at times. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

5
7
0 / 0

[JBoss JIRA] Created: (WELD-580) Around-Invoke Interceptors with wrong signature should cause DefinitionException

by Aslak Knutsen (JIRA)

Around-Invoke Interceptors with wrong signature should cause DefinitionException -------------------------------------------------------------------------------- Key: WELD-580 URL: https://jira.jboss.org/browse/WELD-580 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.0.1.Final Reporter: Aslak Knutsen Around-invoke methods have the following signature: Object <METHOD>(InvocationContext) throws Exception Interceptors that does not follow that should cause a DefinitionException. In current impl they are registered, enabled but can not be resolved on Bean lookup. -- 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

12 years, 1 month

7
17
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues June 2011