August 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-8279) @Inject constructor on session bean does not work

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8279?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated JBAS-8279: ---------------------------- Component/s: Weld/CDI > @Inject constructor on session bean does not work > ------------------------------------------------- > > Key: JBAS-8279 > URL: https://jira.jboss.org/browse/JBAS-8279 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Reporter: David Allen > Fix For: 6.0.0.CR1 > > > The following test does not work in the JBoss AS containers: > org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest::testConstructorAnnotatedInjectCalled -- 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

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] Moved: (JBAS-8278) Not correctly reporting deployment problem in non-contextual injection to TCK

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8278?page=com.atlassian.jira.plugin.sy... ] Pete Muir moved WELDINT-49 to JBAS-8278: ---------------------------------------- Project: JBoss Application Server (was: Weld Integration) Key: JBAS-8278 (was: WELDINT-49) Security: Public Fix Version/s: 6.0.0.CR1 (was: 6.0.0.CR1) > Not correctly reporting deployment problem in non-contextual injection to TCK > ----------------------------------------------------------------------------- > > Key: JBAS-8278 > URL: https://jira.jboss.org/browse/JBAS-8278 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 6.0.0.CR1 > > > testDefinitionErrorDetected(org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.InjectionPointTest) -- 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

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-8278) Not correctly reporting deployment problem in non-contextual injection to TCK

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8278?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated JBAS-8278: ---------------------------- Component/s: Weld/CDI > Not correctly reporting deployment problem in non-contextual injection to TCK > ----------------------------------------------------------------------------- > > Key: JBAS-8278 > URL: https://jira.jboss.org/browse/JBAS-8278 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Reporter: Pete Muir > Assignee: Pete Muir > Fix For: 6.0.0.CR1 > > > testDefinitionErrorDetected(org.jboss.jsr299.tck.tests.lookup.injectionpoint.broken.not.bean.InjectionPointTest) -- 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

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-256) Create an Infinispan-backed HA-JNDI DistributedTreeManager impl

by Brian Stansberry (JIRA)

Create an Infinispan-backed HA-JNDI DistributedTreeManager impl --------------------------------------------------------------- Key: JBCLUSTER-256 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-256 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-ISPN Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Server-Cache-ISPN 1.0.0.Final Use the Infinispan tree API. -- 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

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-255) Create an Infinispan-backed DistributedState impl

by Brian Stansberry (JIRA)

Create an Infinispan-backed DistributedState impl ------------------------------------------------- Key: JBCLUSTER-255 URL: https://jira.jboss.org/jira/browse/JBCLUSTER-255 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-ISPN Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: HA-Server-Cache-ISPN 1.0.0.Final IF we keep DS at all. Should be simple as the API maps readily to AtomicMap. -- 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

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-286) Create an Infinispan-backed SSOClusterManager

by Scott Marlow (JIRA)

Create an Infinispan-backed SSOClusterManager --------------------------------------------- Key: JBCLUSTER-286 URL: https://jira.jboss.org/browse/JBCLUSTER-286 Project: JBoss Clustering Issue Type: Task Security Level: Public (Everyone can see) Components: HA-Server-Cache-ISPN Reporter: Scott Marlow Assignee: Scott Marlow -- 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

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8277) WeldDeployer should ignore classes which cause ClassNotFoundException and NoClassDefFoundError

by Heiko Braun (JIRA)

WeldDeployer should ignore classes which cause ClassNotFoundException and NoClassDefFoundError ---------------------------------------------------------------------------------------------- Key: JBAS-8277 URL: https://jira.jboss.org/browse/JBAS-8277 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Weld/CDI Affects Versions: 6.0.0.M4 Reporter: Heiko Braun Assignee: Pete Muir We are working on the GWT/CDI integration. If an application packages GWT client classes that depend on gwt-user.jar and the weld deployer kicks in it chokes in classes that import GWT client API. This happens because the usage of reflection to scan for annotation meta data, loads all classes and forces all dependencies to be present. These classes can be excluded from the web application packaging, but it's nothing people usally do, because they are required when running the GWT hosted mode. So in order to simplify things, I would suggest we simply log and skip classes that cannot be scanned due to CNFE and the like, instead of preventing the deployment at 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

13 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-627) Move exo platform stuff to releases repository

by Paul Gier (JIRA)

Move exo platform stuff to releases repository ---------------------------------------------- Key: JBBUILD-627 URL: https://jira.jboss.org/browse/JBBUILD-627 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Reporter: Paul Gier Assignee: Paul Gier Fix For: Repository Support 2010 The exoplatform files (org.exoplatform) should be moved to the releases repository instead of the thirdparty-releases repository. Also there are some files in the old repository that wasn't moved to Nexus. http://repository.jboss.org/maven2/org/exoplatform/ws/exo.ws.frameworks.j... https://repository.jboss.org/nexus/content/repositories/thirdparty-releas... -- 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

13 years, 9 months

1
3
0 / 0

[JBoss JIRA] Commented: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on JBAS-8276: --------------------------------- Moved to JBoss AS. > Weld Extension vs. Tomcat deployer in JBoss 6 > --------------------------------------------- > > Key: JBAS-8276 > URL: https://jira.jboss.org/browse/JBAS-8276 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M4 > Reporter: Heiko Braun > > When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension: > 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app > 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data? -- 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

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-8276) Weld Extension vs. Tomcat deployer in JBoss 6

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8276?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated JBAS-8276: ---------------------------- Assignee: Marius Bogoevici Component/s: Weld/CDI > Weld Extension vs. Tomcat deployer in JBoss 6 > --------------------------------------------- > > Key: JBAS-8276 > URL: https://jira.jboss.org/browse/JBAS-8276 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Weld/CDI > Affects Versions: 6.0.0.M4 > Reporter: Heiko Braun > Assignee: Marius Bogoevici > > When I deploy a web application that contains CDI beans to JBoss6-M4 I can see that bean deployment being executed two times. First the CDI deployer kicks in, then Tomcat deployer re-deploys the war archive, which causes a second execution of the extension: > 12:20:34,082 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:34,516 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:34,564 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:34,583 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:34,720 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > 12:20:39,776 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] undeploy, ctxPath=/funky-app > 12:20:40,246 INFO [org.jboss.weld.Version] WELD-000900 1.0.1 (SP4) > 12:20:40,733 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Discovered Errai Service: class com.foo.server.HelloWorldService > 12:20:40,844 INFO [org.jboss.errai.cdi.server.CDIExtensionPoints] Register CDI component as MessageCallback: @Service @ApplicationScoped com.foo.server.HelloWorldService > 12:20:40,856 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] deploy, ctxPath=/funky-app > 12:20:40,929 INFO [org.jboss.resteasy.cdi.CdiInjectorFactory] Found BeanManager at java:comp/BeanManager > Shouldn't it be the execution the extension tight to the tomcat deployer lifecycle? I.e. be dependent on it's meta data? -- 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

13 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2010