May 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (CDITCK-143) Bug in SimpleLifecycleTest

by Gurkan Erdogdu (JIRA)

Bug in SimpleLifecycleTest -------------------------- Key: CDITCK-143 URL: https://jira.jboss.org/jira/browse/CDITCK-143 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gurkan Erdogdu MEthods : testBeanCreateInjectsDependenciesAndInvokesInitializerToInstantiateInstance testCreateReturnsSameBeanPushed Those methods test CreationalContext#push. But implementation does not require to support push method according to specification. -- 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

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-116) Typo in dd-override-report

by Jozef Hartinger (JIRA)

Typo in dd-override-report -------------------------- Key: CDITCK-116 URL: https://jira.jboss.org/jira/browse/CDITCK-116 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.1.GA Reporter: Jozef Hartinger Priority: Trivial The document says "Deployment Descripters overriden by the TCK" while it should say "Deployment Descriptors overriden by the TCK" -- 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

2
5
0 / 0

[JBoss JIRA] Created: (CDITCK-140) TCK uses cyclic @PostConstruct calls which is forbidden by JSR-250

by Mark Struberg (JIRA)

TCK uses cyclic @PostConstruct calls which is forbidden by JSR-250 ------------------------------------------------------------------ Key: CDITCK-140 URL: https://jira.jboss.org/jira/browse/CDITCK-140 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Reporter: Mark Struberg from JSR-250-1.1.MREL section 2.5: "The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization. This method MUST be invoked before the class is put into service." Which I read as "may only get used by others after the @PostConstruct annotated method did run". This is backed by the following example public BeanA { private @Inject BeanB b; private int x = 0; public int getX() { return x; } @PostConstruct void init() { x = b.getX()+7; } } public BeanB { private @Inject BeanA a; private int x = 0; public int getX() { return x; } @PostConstruct void init() { x = a.getX()+9; } } which value do a.x and b.x get finally? This would simply be non-deterministic - and therefore forbidden by the JSR-250 spec. Such kind of circular @PostConstruct method calls happen e.g. in CircularDependencyTest Pig -> Food -> Pig -- 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

3
9
0 / 0

[JBoss JIRA] Created: (CDITCK-134) Injection point not on a passivation capable bean

by Pete Muir (JIRA)

Injection point not on a passivation capable bean ------------------------------------------------- Key: CDITCK-134 URL: https://jira.jboss.org/jira/browse/CDITCK-134 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Reporter: Gurkan Erdogdu Fix For: 1.0.2.CR1 org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField These packages tests decorator injection points to check if they are passivation capable dependency or not, however the injection point is not on a passivation capable bean -- 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

3
12
0 / 0

[JBoss JIRA] Created: (CDITCK-120) Seems a bug in DependentContextTest

by Gurkan Erdogdu (JIRA)

Seems a bug in DependentContextTest ----------------------------------- Key: CDITCK-120 URL: https://jira.jboss.org/jira/browse/CDITCK-120 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gurkan Erdogdu org.jboss.jsr299.tck.tests.context.dependent.DependentContextTest belows test methods directly use Bean#create method to create actual bean instances. But this method must not be used directly, instead of BeanManager#getReference must be used. Therefore tests are failed. Methods ----------------- testDependentScopedDecoratorsAreDependentObjectsOfBean testDependentScopedInterceptorsAreDependentObjectsOfBean -- 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

3
10
0 / 0

[JBoss JIRA] Created: (WELD-269) Registration of a custom implementation of the Decorator interface fails

by Jozef Hartinger (JIRA)

Registration of a custom implementation of the Decorator interface fails ------------------------------------------------------------------------ Key: WELD-269 URL: https://jira.jboss.org/jira/browse/WELD-269 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 org.jboss.jsr299.tck.tests.decorators.custom.CustomDecoratorTest.testCustomImplementationOfDecoratorInterface() -- 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

3
9
0 / 0

[JBoss JIRA] Created: (WELDX-105) make common annotation literals public

by Dan Allen (JIRA)

make common annotation literals public -------------------------------------- Key: WELDX-105 URL: https://jira.jboss.org/browse/WELDX-105 Project: Weld Extensions Issue Type: Feature Request Affects Versions: 1.0.0.Alpha2 Reporter: Dan Allen Priority: Minor Common annotation literals would be a useful utility for extension writers, however they are currently package protected. Make them public so that extension writers don't have to keep recreating it (possibly doing it incorrectly). NamedLiteral DefaultLiteral Why not have the following literals as well? AnyLiteral NewLiteral -- 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

14 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (WELD-508) incorrect choice of dependency in example: jboss-ejb3-api-3.1.0.jar

by asookazian (JIRA)

incorrect choice of dependency in example: jboss-ejb3-api-3.1.0.jar ------------------------------------------------------------------- Key: WELD-508 URL: https://jira.jboss.org/jira/browse/WELD-508 Project: Weld Issue Type: Bug Components: Examples Affects Versions: 1.0.1.Final Reporter: asookazian Priority: Minor C:\java\weld-1.0.1-Final\examples\jsf\translator>mvn clean install [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Compilation failure C:\java\weld-1.0.1-Final\examples\jsf\translator\ejb\src\main\java\org\jboss\wel d\examples\translator\SentenceTranslator.java:[3,-1] cannot access javax.ejb.Sta teless bad class file: C:\Documents and Settings\asookazian\.m2\repository\org\jboss\ej b3\jboss-ejb3-api\3.1.0\jboss-ejb3-api-3.1.0.jar(javax/ejb/Stateless.class) class file has wrong version 50.0, should be 49.0 -- 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

3
4
0 / 0

[JBoss JIRA] Created: (WELD-531) Weld swallowing stacktrace when multiple container errors

by Dan Allen (JIRA)

Weld swallowing stacktrace when multiple container errors --------------------------------------------------------- Key: WELD-531 URL: https://jira.jboss.org/browse/WELD-531 Project: Weld Issue Type: Bug Affects Versions: 1.0.1.Final Reporter: Dan Allen When there are multiple container errors (for instance, definition errors at startup), Weld cycles through the errors and builds a localized message. However, it drops the cause of the exception. If the message is further up the chain (i.e., in the exception cause), this leads to exceptions such as: Exception #0: null The user is lost as to what the real problem is. Typically root causes are: - NoClassDefFoundError - NullPointerException The problem is not that the message is null. The problem is that the underlying cause is dropped. This came up recently when using Arquillian as reported in this forum post: https://community.jboss.org/message/544395#544395 When placed in a debugger, it turned out that a NoClassDefFoundError was being thrown. There was no way for the user to trace that to the source. I think that what Weld needs to do is follow the cause until it finds a non-null message. -- 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

14 years, 6 months

2
9
0 / 0

[JBoss JIRA] Created: (WELD-448) invoking sendRedirect() in a JSP causes WELD-001303

by Dan Allen (JIRA)

invoking sendRedirect() in a JSP causes WELD-001303 --------------------------------------------------- Key: WELD-448 URL: https://jira.jboss.org/jira/browse/WELD-448 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.0.1.CR2 Reporter: Dan Allen Fix For: 1.0.1.GA When sendRedirect() is used inside of a JSP page, it results in the exception WELD-001303: No active contexts for scope type @ConversationScoped A source of this error is a typical /index.jsp redirector page: <% response.sendRedirect("home.jsf"); %> The ConversationPropagationFilter is wrapping all requests (not just JSF requests). The conversation scope is only active during JSF requests. The problem comes when ConversationPropagationFilter traps calls to sendRedirect(). It first checks whether the conversation is transient. But this check mandates that the conversation scope be active. ConverationPropagationFilter.java: ... @Override public void sendRedirect(String path) throws IOException { ConversationImpl conversation = conversation(ctx); if (!conversation.isTransient()) { ... } super.sendRedirect(path); } ... ConversationImpl.java ... public boolean isTransient() { checkConversationActive(); return _transient; } ... I don't understand why isTransient() is enforcing that a conversation be active. If it's not active, then that should be considered transient (or there needs to be a portable way of checking if it's active. -- 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, 6 months

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues May 2010