February 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-493) Convert weld-core-tests test suite to use Arquillian

by Aslak Knutsen (JIRA)

Convert weld-core-tests test suite to use Arquillian ---------------------------------------------------- Key: WELD-493 URL: https://jira.jboss.org/jira/browse/WELD-493 Project: Weld Issue Type: Task Components: Testing Infrastructure (Mocks and Harness Integration) Reporter: Aslak Knutsen Assignee: Aslak Knutsen Rewrite the weld-core-test suite to use Arquillian. src/test/ -> rewrite to use Arquillian src/main/ -> move to Arquillian weld container -- 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, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (WELD-831) Weld throws an NPE thrown during failover between to jboss servers

by Fin Steenbjerg (JIRA)

Weld throws an NPE thrown during failover between to jboss servers ------------------------------------------------------------------ Key: WELD-831 URL: https://issues.jboss.org/browse/WELD-831 Project: Weld Issue Type: Feature Request Environment: OS: MS Windows (XP) AS: Jboss 6.0.0 Final JDK: 1.6.0_23 (sun/oracle jdk) Reporter: Fin Steenbjerg In a two node jboss environment a failover throws an exception (see description in the forum reference): 2011-01-18 20:55:13,222 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/clusteredcdi.web]] (ajp-127.0.0.1-8209-1) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException at org.jboss.weld.context.ForwardingContextual.toString(ForwardingContextual.java:52) [:6.0.0.Final] at java.lang.String.valueOf(String.java:2826) [:1.6.0_23] at java.lang.StringBuilder.append(StringBuilder.java:115) [:1.6.0_23] at org.jboss.weld.context.SerializableContextualInstanceImpl.toString(SerializableContextualInstanceImpl.java:67) [:6.0.0.Final] at java.lang.String.valueOf(String.java:2826) [:1.6.0_23] at java.lang.StringBuilder.append(StringBuilder.java:115) [:1.6.0_23] at org.jboss.weld.context.beanstore.AttributeBeanStore.attach(AttributeBeanStore.java:120) [:6.0.0.Final] at org.jboss.weld.context.AbstractBoundContext.activate(AbstractBoundContext.java:75) [:6.0.0.Final] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:161) [:6.0.0.Final] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:180) [:6.0.0.Final] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final] at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135) [:6.0.0.Final] at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94) [:6.0.0.Final] at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [:6.0.0.Final] at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62) [:6.0.0.Final] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final] at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final] at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:504) [:6.0.0.Final] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:437) [:6.0.0.Final] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final] at java.lang.Thread.run(Thread.java:662) [:1.6.0_23] Steps to Reproduce: I have attached an ear file containing a single war module. Inside this war module there is a single class named Pojo (the source is there too) and a single xhtml page which uses the pojo class via CDI. It's very simple. (I have added a servlet filter that prints the session attributes for each request - but that can be removed if it is not wanted). Test Setup The jboss setup to use in order reproduce the problem is as follows: 1. A single Jboss installation with two server configurations called node01 and node02 (these are both copies of the all configuration) 2. An apache server in front of the two jboss nodes. The apache uses mod_cluster plugin. 3. The setup is started with the following script (sorry it is for ms windows): start %~dp0..\..\apache-2.2\bin\httpd.exe && sleep 10 && start %~dp0run.bat -c node01 -Djboss.jvmRoute=node01 -Djboss.mod_cluster.proxyList=127.0.0.1:6666 -Djboss.mod_cluster.excludedContexts=ROOT -Djboss.service.binding.set=ports-01 && sleep 10&& start %~dp0run.bat -c node02 -Djboss.jvmRoute=node02 -Djboss.mod_cluster.proxyList=127.0.0.1:6666 -Djboss.mod_cluster.excludedContexts=ROOT -Djboss.service.binding.set=ports-02 && sleep 45 && start http://localhost:8080/mod_cluster-manager 4. Deploy the the clusteredcdi.ear file to farm folder belonging to one of the jboss configurations being used. Test execution 1. Make a request via the apache server http://localhost:8080/clusteredcdi.web/faces/pages/cdi.xhtml 2. Enter something into the form and submit via the "set new value" button. 3. Kill the jboss server process that handled the request 4. Refresh the browser window in which the request above was submitted. 5. The error occurs. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (WELD-702) Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e

by sreekanth manga (JIRA)

Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e ------------------------------------------------------------------------------------------------------------------------ Key: WELD-702 URL: https://jira.jboss.org/browse/WELD-702 Project: Weld Issue Type: Bug Components: Testing Infrastructure (Mocks and Harness Integration) Environment: Linux,Glassfish v3.1 Reporter: sreekanth manga Priority: Minor This issue seems to be glassfish specific issue.Couple of tests are failing with non glassfish supported use of annotaion @WebServlet.. 1)In the test, org.jboss.weld.tests.scope.RemoteScopeTest, there is a servlet by name RemoteClient using the annotation "@WebServlet("*")". 2)In the test resource.EMFFactoryTest, there are 3 servlets EMFConsumerTest1, EMFConsumerTest2, EMFConsumerTest3 which uses the annotation @WebServlet("emfconsumer") with out a leading "/" . As per discussion in weld dev alias, this syntax is supported is vendor specific feature of JBoss. Glassfish server log: ================ #|2010-10-04T20:28:02.679+0530|SEVERE|glassfish3.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app [jsr88-637718205897341632]|#] [#|2010-10-04T20:28:02.745+0530|SEVERE|glassfish3.1|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=15;_ThreadName=Thread-1;|Exception while deploying the app [jsr88-637718205897341632] : Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*].at org.glassfish.apf.AnnotationInfo@73fce83e at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:367) at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:375) at org.glassfish.apf.impl.AnnotationProcessorImpl.processAnnotations(AnnotationProcessorImpl.java:289) at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:195) at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:134) at com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(Archivist.java:611) at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:460) at com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(Archivist.java:447) at com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors(Archivist.java:423) at com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(Archivist.java:398) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:263) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:272) at com.sun.enterprise.deployment.archivist.Archivist.open(Archivist.java:233) at com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive(ApplicationFactory.java:165) at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:171) at org.glassfish.javaee.core.deployment.DolProvider.load(DolProvider.java:85) at com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer(ApplicationLifecycle.java:729) at com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos(ApplicationLifecycle.java:671) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:343) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:239) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:351) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:360) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:375) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1080) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:101) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1229) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1218) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:375) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:209) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:824) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:721) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1014) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:220) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57) at com.sun.grizzly.ContextTask.run(ContextTask.java:69) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:530) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:511) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.IllegalArgumentException: Invalid url Patterns for class org.jboss.weld.tests.scope.RemoteClient: [*]. at com.sun.enterprise.deployment.annotation.handlers.WebServletHandler.processAnnotation(WebServletHandler.java:191) at com.sun.enterprise.deployment.annotation.handlers.WebServletHandler.processAnnotation(WebServletHandler.java:118) at com.sun.enterprise.deployment.annotation.handlers.AbstractWebHandler.processAnnotation(AbstractWebHandler.java:121) at com.sun.enterprise.deployment.annotation.handlers.WebServletHandler.processAnnotation(WebServletHandler.java:68) at org.glassfish.apf.impl.AnnotationProcessorImpl.process(AnnotationProcessorImpl.java:344) ... 45 more |#] -- 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, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (CDITCK-205) Add test to verify extensions in non-bean archives are loaded

by Dan Allen (JIRA)

Add test to verify extensions in non-bean archives are loaded ------------------------------------------------------------- Key: CDITCK-205 URL: https://issues.jboss.org/browse/CDITCK-205 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Dan Allen Priority: Minor Add a test to answers this question: Does an extension have to be in an bean archive in order to be loaded? Section 11.5 states: "An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services." If one assumes that "service provider" refers to the term defined in the jar specification [1], then one would conclude that an extension does not have to be in a bean archive to be recognized (these are orthogonal concerns). A test for this scenario is available in the OpenTCK project and may be ported to the CDI TCK. [2] [1] http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Se... [2] https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (CDITCK-206) Add test to verify visibly of beans registered explicitly through an extension in non-bean archives

by Dan Allen (JIRA)

Add test to verify visibly of beans registered explicitly through an extension in non-bean archives --------------------------------------------------------------------------------------------------- Key: CDITCK-206 URL: https://issues.jboss.org/browse/CDITCK-206 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Dan Allen Add a test that answers this question: Can an extension register a bean programmatically for a class that resides in another non-bean archive? This question requires a short example which is available in the OpenTCK test suite and may be ported to the CDI TCK [1]. Assume one archive, a.jar, has the following contents: org/opentck/javaee/cdi/spi/beforebeandiscovery/BeanClassToRegister.class A second archive, b.jar, has the following contents: org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherBeanClassToRegister.class org/opentck/javaee/cdi/spi/beforebeandiscovery/AnotherManualBeanRegistrationExtension.class org/opentck/javaee/cdi/spi/beforebeandiscovery/ManualBeanRegistrationExtension.class META-INF/services/javax.enterprise.inject.spi.Extension AnotherBeanClassToRegister has an injection point of type BeanClassToRegister: public class AnotherBeanClassToRegister { @Inject private BeanClassToRegister collaborator; } BeanClassToRegister and AnotherBeanClassToRegister are added as beans programmatically in respective extensions listed in the service provider descriptor: public class ManualBeanRegistrationExtension implements Extension { public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) { event.addAnnotatedType(bm.createAnnotatedType(BeanClassToRegister.class)); } } public class AnotherManualBeanRegistrationExtension implements Extension { public void registerBeans(@Observes BeforeBeanDiscovery event, BeanManager bm) { event.addAnnotatedType(bm.createAnnotatedType(AnotherBeanClassToRegister.class)); } } The two libraries, a.jar and b.jar are bundled in a web archive, test.war WEB-INF/lib/a.jar WEB-INF/lib/b.jar WEB-INF/beans.xml Deploying this archive to the reference implementation fails with an error message that the injection point from above cannot be satisfied. There appears to be a visibility problem across bean archives in this case. Adding META-INF/beans.xml to a.jar and removing the ManualBeanRegistrationExtension from b.jar resolves the issue in the reference implementation. [1] https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (CDITCK-175) Tests from org.jboss.jsr299.tck.tests.interceptors.definition.broken.finalClassInterceptor should be separated

by Marius Bogoevici (JIRA)

Tests from org.jboss.jsr299.tck.tests.interceptors.definition.broken.finalClassInterceptor should be separated -------------------------------------------------------------------------------------------------------------- Key: CDITCK-175 URL: https://jira.jboss.org/browse/CDITCK-175 Project: CDI TCK Issue Type: Bug Reporter: Marius Bogoevici The package contains a few tests that exercise deployment errors due to invalid intercepted class definitions. The tests must be separated (perhaps in individual packages) in order to make sure that the test cases run in isolation (since there are multiple sources of errors, the deployment will fail if at least one is satisfied, but we want to test all). -- 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, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (WELD-347) META-INF/beans.xml not sufficient to activate CDI in WAR

by Dan Allen (JIRA)

META-INF/beans.xml not sufficient to activate CDI in WAR -------------------------------------------------------- Key: WELD-347 URL: https://jira.jboss.org/jira/browse/WELD-347 Project: Weld Issue Type: Bug Components: GlassFish Integration Affects Versions: 1.0.0.GA Reporter: Dan Allen Assignee: Dan Allen Fix For: 1.0.1.CR1 In GlassFish V3, if a WAR is deployed containing WEB-INF/classes/META-INF/beans.xml, CDI does not get activated (no beans are detected). Activation only happens if the WAR contains WEB-INF/beans.xml. I'm not sure why GlassFish V3 is having a problem finding beans.xml in the META-INF directory of the WAR classpath. I can't tell if it is a problem in Weld or a problem in GlassFish V3 somewhere. -- 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, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-176) Decorator Elements in beans.xml use <decorator> not <class>

by Pete Muir (JIRA)

Decorator Elements in beans.xml use <decorator> not <class> ----------------------------------------------------------- Key: CDITCK-176 URL: https://jira.jboss.org/browse/CDITCK-176 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.2.CR2 Reporter: Pete Muir Fix For: 1.0.2.CR3 Affected tests: testPassivationCapableBeanWithNonPassivatingDecoratorBeanConstructorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingBeanConstructor.DecoratorWithNonPassivatingBeanConstructorTest) testPassivationCapableBeanWithNonPassivatingInitializerInDecoratorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInitializerMethod.DecoratorWithNonPassivatingInitializerMethodTest) testPassivationCapableBeanWithNonPassivatingDecoratorInjectedFieldFails(org.jboss.jsr299.tck.tests.context.passivating.broken.decoratorWithNonPassivatingInjectedField.DecoratorWithNonPassivatingInjectedFieldTest) testEnterpriseBeanWithNonPassivatingDecoratorFails(org.jboss.jsr299.tck.tests.context.passivating.broken.enterpriseBeanWithNonPassivatingDecorator.EnterpriseBeanWithNonPassivatingDecoratorTest) testDecoratorListedTwiceInBeansXmlNotOK(org.jboss.jsr299.tck.tests.decorators.definition.broken.decoratorListedTwiceInBeansXml.DecoratorListedTwiceInBeansXmlTest) testNonExistantDecoratorClassInBeansXmlNotOK(org.jboss.jsr299.tck.tests.decorators.definition.broken.nonExistantClassInBeansXml.NonExistantDecoratorClassInBeansXmlTest) -- 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, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (WELD-707) Intercepted bean method notifyAll() cannot be declared final

by Adam Warski (JIRA)

Intercepted bean method notifyAll() cannot be declared final ------------------------------------------------------------ Key: WELD-707 URL: https://jira.jboss.org/browse/WELD-707 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.0.Beta1 Reporter: Adam Warski This started showing up after upgrading from M4 to M5, so to Weld 1.1.0. I'm using weldx, and as per the conversation on IRC with Pete this may be the cause. Exact message: WELD-001504 Intercepted bean method [method] public final native pl.softwaremill.service.organization.OrganizationService.notifyAll() (intercepted by pl.softwaremill.cdiext.transaction.TransactionalInterceptor) cannot be declared final -- 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
7
0 / 0

[JBoss JIRA] Created: (WELD-744) Interceptor and Decorator validation assumes that producer fields and methods will be public

by Pete Muir (JIRA)

Interceptor and Decorator validation assumes that producer fields and methods will be public -------------------------------------------------------------------------------------------- Key: WELD-744 URL: https://jira.jboss.org/browse/WELD-744 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.0.Beta1 Reporter: Pete Muir Fix For: 1.1.0.CR1 Needs to iterate over the class hierarchy looking at declared methods -- 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

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues February 2011