December 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-627) Clarify the implementation and usage of WeldClass.getWeldMethods, WelldClass.getDeclaredWeldMethods

by Marius Bogoevici (JIRA)

Clarify the implementation and usage of WeldClass.getWeldMethods, WelldClass.getDeclaredWeldMethods --------------------------------------------------------------------------------------------------- Key: WELD-627 URL: https://jira.jboss.org/browse/WELD-627 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 1.0.1.Final Reporter: Marius Bogoevici Fix For: 1.1.0.BETA2 The goal for getWeldMethods and getDeclaredWeldMethods is to mimic the behavior of getMethods and getDeclaredMethods as they are defined on java.lang.Class. Introduce a new method - called e.g. getWeldBusinessMethods that returns the methods of the class that can be used for business methods invocations on a particular bean. -- 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, 9 months

5
8
0 / 0

[JBoss JIRA] Created: (WELD-516) RunnableDecorator incorrectly assumes >0 Runnable beans

by Morten Christensen (JIRA)

RunnableDecorator incorrectly assumes >0 Runnable beans ------------------------------------------------------- Key: WELD-516 URL: https://jira.jboss.org/jira/browse/WELD-516 Project: Weld Issue Type: Bug Affects Versions: 1.0.1.Final Environment: Java 6 + WeldSE Reporter: Morten Christensen The class org.jboss.weld.environment.se.threading.RunnableDecorator incorrectly assumes that there will be at least one bean that implements Runnable. If there are no beans that implements Runnable then an error like this will happen: org.jboss.weld.DeploymentException: Injection point has unstatisfied dependencies. Injection point: field org.jboss.weld.environment.se.threading.RunnableDecorator.runnable; Qualifiers: [@javax.enterprise.inject.Default()] at org.jboss.weld.Validator.validateInjectionPoint(Validator.java:232) at org.jboss.weld.Validator.validateBean(Validator.java:80) at org.jboss.weld.Validator.validateRIBean(Validator.java:100) at org.jboss.weld.Validator.validateBeans(Validator.java:282) at org.jboss.weld.Validator.validateDeployment(Validator.java:267) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:389) at org.jboss.weld.environment.se.Weld.initialize(Weld.java:81) at org.jboss.weld.environment.se.StartMain.go(StartMain.java:45) at org.jboss.weld.environment.se.StartMain.main(StartMain.java:57) I guess the field "runnable" inside this class should be changed to use Instance<Runnable> instead. -- 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, 9 months

6
12
0 / 0

[JBoss JIRA] (WELD-1023) Fail-fast when an <alternative> declaration in beans.xml is unused

by Geoffrey De Smet (Created) (JIRA)

Fail-fast when an <alternative> declaration in beans.xml is unused ------------------------------------------------------------------ Key: WELD-1023 URL: https://issues.jboss.org/browse/WELD-1023 Project: Weld Issue Type: Enhancement Reporter: Geoffrey De Smet I have this in my beans.xml: <alternatives> <class>org.drools.guvnor.server.repository.TestRepositoryStartupService</class> </alternatives> The class exists, but because of whatever reason (CDI-18 in this case), it's not used. Yet, everything starts up happily and I think I am using my alternative (while I am not). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

6
6
0 / 0

[JBoss JIRA] (WELD-1020) NPE during cleanup after Servlet API3 AsyncContect

by Manuel Hartl (Created) (JIRA)

NPE during cleanup after Servlet API3 AsyncContect -------------------------------------------------- Key: WELD-1020 URL: https://issues.jboss.org/browse/WELD-1020 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.1.4.Final, 1.1.2.Final Environment: Windows7, Tomcat 7.0.23 Reporter: Manuel Hartl When using Weld with Servlet API3.0 AsyncContext, there will be a NullPointerException, when Weld tries to cleanup the request. There seems to be a problem when asyncContext.complete() is called in a thread that was not the original thread that received the request example for the exception: java.lang.NullPointerException at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:71) at org.jboss.weld.context.http.HttpRequestContextImpl.deactivate(HttpRequestContextImpl.java:86) at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:103) at org.jboss.weld.servlet.api.helpers.ForwardingServletListener.requestDestroyed(ForwardingServletListener.java:42) at org.apache.catalina.core.StandardContext.fireRequestDestroyEvent(StandardContext.java:5973) at org.apache.catalina.connector.CoyoteAdapter.asyncDispatch(CoyoteAdapter.java:283) at org.apache.coyote.http11.AbstractHttp11Processor.asyncDispatch(AbstractHttp11Processor.java:1515) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:523) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1575) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

4
3
0 / 0

[JBoss JIRA] (WELD-1011) Move jboss interceptors into Weld

by Jozef Hartinger (Created) (JIRA)

Move jboss interceptors into Weld --------------------------------- Key: WELD-1011 URL: https://issues.jboss.org/browse/WELD-1011 Project: Weld Issue Type: Task Components: Interceptors and Decorators Affects Versions: 1.1.3.SP1 Reporter: Stuart Douglas Assignee: Jozef Hartinger Fix For: 2.0.0.Alpha1 (12:36:44 PM) stuartdouglas: jharting: you could actually do that for the 2.0 branch already (12:37:20 PM) stuartdouglas: it should be pretty easy just to move the code out of jboss interceptors and into weld trunk (12:40:01 PM) stuartdouglas: Its not high priority, and I would talk to Marius first -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-34) Make special note in the spec about @Named beans (via a stereotype) cannot be selected with Instance.select()

by Shane Bryzak (JIRA)

Make special note in the spec about @Named beans (via a stereotype) cannot be selected with Instance.select() ------------------------------------------------------------------------------------------------------------- Key: CDI-34 URL: https://issues.jboss.org/browse/CDI-34 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Shane Bryzak Priority: Minor For example, say we have the following bean: public @Model class Foo implements IFoo { } And we have the following injection point within another bean: @Inject Instance<Foo> fooInstance; It is not possible to select Foo via name using the Instance: // This results in an UnsatisfiedDependencyException Foo foo = fooInstance.select(new NamedLiteral("foo")).get(); Instead, Foo must be annotated directly with the @Named annotation itself: /* * This Foo can be selected by name */ public @Named @RequestScoped Foo implements IFoo { } This special case might be worthwhile mentioning in the next revision of the spec. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (CDITCK-212) DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created

by Stuart Douglas (JIRA)

DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created ---------------------------------------------------------------------------------------------------------- Key: CDITCK-212 URL: https://issues.jboss.org/browse/CDITCK-212 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Stuart Douglas Context applicationContext = getCurrentManager().getContext(ApplicationScoped.class); destroyContext(applicationContext); setContextActive(applicationContext); myApplicationBeanInstance = applicationContext.get(myApplicationBean); The spec does not require that the application scope can be destroyed and re-created, if fact it could be argued that this behaviour violates the spec, as the application context is supposed to last for the lifetime of the application. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
2
0 / 0

[JBoss JIRA] Created: (CDITCK-213) Interceptor classes in TCK do not follow the Interceptor spec

by Bob Nettleton (JIRA)

Interceptor classes in TCK do not follow the Interceptor spec ------------------------------------------------------------- Key: CDITCK-213 URL: https://issues.jboss.org/browse/CDITCK-213 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton There are some interceptor-related suites in the CDI TCK that are not portable in some situations. The interceptor classes listed here: org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.MissileInterceptor org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.MissileInterceptor org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.MissileInterceptor These interceptor classes do not have a public, no-args constructor, which is required by the Interceptor 1.1 specification. This means that the tests may not be portable to all environments, since application servers may choose to treat this as an error condition. The following tests are affected by this issue: org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.SessionBeanInterceptorOrderTest.testInterceptorsDeclaredUsingInterceptorsCalledBeforeInterceptorBinding org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest.testNonContextualSessionBeanReferenceIsIntercepted org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.SessionBeanInterceptorDefinitionTest.testSessionBeanIsIntercepted I request that these tests be excluded from the 1.0.4 suite, and that the interceptors be fixed for subsequent versions of the test suite. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-219) SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut uses too short of a sleep delay time

by Bob Nettleton (JIRA)

SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut uses too short of a sleep delay time ---------------------------------------------------------------------------------------------------------- Key: CDITCK-219 URL: https://issues.jboss.org/browse/CDITCK-219 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton The following test case: org.jboss.jsr299.tck.tests.context.session.SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut uses the following line to sleep after asking the application server to invalidate the session: " Thread.sleep(1500);" The test attempts to verify that the session context is destroyed properly after the timeout. The problem with this test is that it appears as if it could potentially introduce a timing problem. Since Thread.sleep() behaves slightly differently for each platform, and as far as I can tell is not even guaranteed to sleep as long as requested in some situations, there is a chance that the client may make the second request before 1.5 seconds has expired. Since the behavior of System.getTimeMillis() is also system-dependent, I'd be inclined to think that 1.5 seconds is probably not a long enough timeout in order to keep this test from having intermittent failures. I request that this test case be excluded, and that this test be modified in a later version of the TCK to use a larger sleep value. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (CDITCK-217) InjectionIntoWebServiceEndpoint test uses hard-coded HTTP port

by Bob Nettleton (JIRA)

InjectionIntoWebServiceEndpoint test uses hard-coded HTTP port -------------------------------------------------------------- Key: CDITCK-217 URL: https://issues.jboss.org/browse/CDITCK-217 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton The following test in the CDI TCK: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest.testInjectionIntoWebServiceEndpoint appears to use a hard-coded HTTP port in the following web service client class: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.SheepWSEndPointService This test is quite different from the rest of the suite, in that the configured HTTP port is not used in this client. It appears that the test is non-portable in its current state. I request that this test be excluded. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

4
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues December 2011