June 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-544) Use org.jboss.spec.javax.interceptor instead of the current Interceptors 1.1 API artifact

by Marius Bogoevici (JIRA)

Use org.jboss.spec.javax.interceptor instead of the current Interceptors 1.1 API artifact ----------------------------------------------------------------------------------------- Key: WELD-544 URL: https://jira.jboss.org/browse/WELD-544 Project: Weld Issue Type: Feature Request Components: Infrastructure Affects Versions: 1.0.1.Final Reporter: Marius Bogoevici Priority: Critical Fix For: 1.0.2.CR1 -- 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
5
0 / 0

[JBoss JIRA] Created: (CDITCK-94) Route serialization/deserialization through SPI

by Pete Muir (JIRA)

Route serialization/deserialization through SPI ----------------------------------------------- Key: CDITCK-94 URL: https://jira.jboss.org/jira/browse/CDITCK-94 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Infrastructure Reporter: Pete Muir Fix For: 1.1.0.CR1 This allows a porting package to mirror the behavior of an app server which may provide special behavior here. -- 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
4
0 / 0

[JBoss JIRA] Created: (CDITCK-165) Bug in org.jboss.jsr299.tck.tests.context.NormalContextTest # testSameNormalScopeBeanInjectedEverywhere

by Gurkan Erdogdu (JIRA)

Bug in org.jboss.jsr299.tck.tests.context.NormalContextTest # testSameNormalScopeBeanInjectedEverywhere ------------------------------------------------------------------------------------------------------- Key: CDITCK-165 URL: https://jira.jboss.org/browse/CDITCK-165 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.2.CR1 Reporter: Gurkan Erdogdu In this method, this tests tries to compare the session context instance equality. I think this is not correct. Normal scoped beans returns "Proxy" for actual instances. In SimpleBeanA and SimpleBeanB bean instances, @Inject SimpleBeanZ z, may return a different proxy instances that represents the same SimpleBeanZ contextual instance. In OWB, we return different proxy instances for normal scoped beans, therefore instanceOfA.getZ() == instanceOfB.getZ( ) --> False, because we return different proxy instances for instanceOfA.getZ() and instanceOfB.getZ() that both of them represents the same z instance. Test may be updated to compare some instance variables of z instance. -- 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
3
0 / 0

[JBoss JIRA] Created: (CDITCK-169) PersistenceContextInjectionTest is using an invalid isOpen() call

by Marius Bogoevici (JIRA)

PersistenceContextInjectionTest is using an invalid isOpen() call ----------------------------------------------------------------- Key: CDITCK-169 URL: https://jira.jboss.org/browse/CDITCK-169 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.2.CR1 Reporter: Marius Bogoevici Fix For: 1.0.2.Final, 1.1.0.CR1 org.jboss.jsr299.tck.tests.implementation.simple.resource.persistenceContext.PersistenceContextInjectionTest: The Java EE resource producer field pattern is tested by a couple of methods. During the test, the EntityManager.isOpen() method is used for testing, but calling isOpen() from within the test method is invalid, because the EntityManager is transaction-scoped and not application-managed, and the call happens outside the scope of a JTA transaction. Proposed solution: inject the produced EM in an EJB and perform the check from within a transaction. -- 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

3
6
0 / 0

[JBoss JIRA] Created: (WELD-473) required meta-annotations for a qualifier specified differently in spec and API

by Wolfgang Frech (JIRA)

required meta-annotations for a qualifier specified differently in spec and API ------------------------------------------------------------------------------- Key: WELD-473 URL: https://jira.jboss.org/jira/browse/WELD-473 Project: Weld Issue Type: Bug Affects Versions: 1.0.1.Final Environment: n/a Reporter: Wolfgang Frech The specification and the API documentation differ on the required and optional meta-annotations of a qualfiier. JSR-299, 2.3.2 Defining new qualfier type specifies @Target(METHOD, FIELD, PARAMETER, TYPE} ("is") @Retention(RUNTIME) ("is") @Qualifier, but only optional ("may") API-Doc of Qualifier specifies @Qualifier @Retention(RUNTIME) @Documented (optional, typical) @Target optional, but various element types as targets possible Both agree on Retention only. As a third source I might have a look at the code and the implemented validity check. I have not so far. I am a bit fussy about this because a missing @Target of my first custom scope messed up the proxying. -- 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
3
0 / 0

[JBoss JIRA] Created: (WELDX-70) Automate testing of archetypes

by Steven Boscarine (JIRA)

Automate testing of archetypes ------------------------------ Key: WELDX-70 URL: https://jira.jboss.org/jira/browse/WELDX-70 Project: Weld Extensions Issue Type: Task Components: Archetypes Affects Versions: Archetypes 1.0.0-BETA1 Reporter: Steven Boscarine Assignee: Steven Boscarine This may be a difficult and funky task. I haven't been able to find examples of people automating maven calls. This may be a very pioneering task if done in Java. I do it presently with a shell script. Here's what needs to happen: An archetype needs to be built from source. (mvn clean install) A project needs to be created from the archetype. (mvn archetype:generate -DartifactId=myproject) The project's tests need to be run. (mvn clean test -f myproject/pom.xml) -- 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
5
0 / 0

[JBoss JIRA] Created: (WELD-489) Update the jsf dependency version in weld-api-bom to 2.0

by Adam Warski (JIRA)

Update the jsf dependency version in weld-api-bom to 2.0 -------------------------------------------------------- Key: WELD-489 URL: https://jira.jboss.org/jira/browse/WELD-489 Project: Weld Issue Type: Task Components: Infrastructure Affects Versions: 1.0.1.Final Reporter: Adam Warski Currently it's 1.2_13, and the newest version of the api is 2.0.2-FCS. The version of the bom is 1.0-SP1 -- 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
5
0 / 0

[JBoss JIRA] Created: (WELD-414) Make Weld docs available for JBoss AS 6

by Pete Muir (JIRA)

Make Weld docs available for JBoss AS 6 --------------------------------------- Key: WELD-414 URL: https://jira.jboss.org/jira/browse/WELD-414 Project: Weld Issue Type: Task Components: Documentation Reporter: Pete Muir Assignee: Dan Allen Priority: Critical Fix For: 1.0.2.CR1 Magnolia is the tool we use to build out the JBoss community site. Please take a moment and go to http://www.jboss.org/author. Username: ********** Password: ********** Scroll down and open jbossas --> docs --> 6-x Highlight 6-x and press the "Open page..." button at the bottom. The main AS6 docs page will open in another tab or window. >From here you can see how AS6 documentation will be broken up into "Core" and "Component". Click on the "JavaServer Faces (JSF)" link You'll get an idea of what you can do with your section. As you can see, we want to provide something beyond the DocBook documentation we've had in the past. We want a developer to be able to come to the docs section and find everything he might need to work with a particular part of AS6, including spec info, javadoc, sample code, and links to other info. Of course, we don't want to fork the stuff we already have but we also need to recognize that developers want to use AS6 as a single product and they come to AS6 with an "AS6" mindset. So they are thinking, "How do I use the EJB features built into AS6?" or "How do I use the Weld framework built into AS6?". We need to provide documentation that answers those questions from an AS6 point of view. But I'm using the word "documentation" in a loose sense. It doesn't have to be a single document. The aggregation of AS6 information is done with Magnolia and not necessarily with a single DocBook monograph. I am assuming that most components will have at least some AS6-specific content that needs to go somewhere. If it's possible/practical to use Maven profiles to pull in special content and create an AS6 version of a document then that would be best. If not, then AS6-specific content could be put into its own small document. The rest can be referenced with links to the component's project documentation. As for where the doco lives in what part of SVN, I don't think that it really matters. I like the idea that each component team is responsible for handling their section however is most practical for them. I just want to make sure that at the end of the day an AS6 user has everything he needs in a way that is easy to find and understand. Action items for you: * Take a look at http://jboss.org/help/projectpageguide.html to learn about Magnolia. * Find the section on Weld and start building out the page(s) * Work out how best to incorporate the Weld ref guide into the JBoss AS docs - remove irrelevant sections - apply JBoss AS styling -- 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
3
0 / 0

[JBoss JIRA] Created: (WELD-476) OutOfMemory Exception When Deploying (Bootstrapping) Single BDA with 621 classes

by Roger Kitain (JIRA)

OutOfMemory Exception When Deploying (Bootstrapping) Single BDA with 621 classes -------------------------------------------------------------------------------- Key: WELD-476 URL: https://jira.jboss.org/jira/browse/WELD-476 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 1.0.1.Final Environment: GlassFish v3.01 Macos w/ 4 GB memory Reporter: Roger Kitain Upon deploying a war with WEB-INF/beans.xml and 621 classes under WEB-INF/classes, an outofmemory exception is produced: org.glassfish.deployment.common.DeploymentException: java.lang.OutOfMemoryError: Java heap space at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:167) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:310) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:141) at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:573) at org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:459) at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:391) at org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:376) at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:195) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) Caused by: com.google.common.collect.ComputationException: java.lang.OutOfMemoryError: Java heap space at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:602) at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:462) at com.google.common.collect.CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2045) at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:164) at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:61) at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:88) at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:134) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:377) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:165) ... 18 more Caused by: java.lang.OutOfMemoryError: Java heap space at java.lang.Class.copyMethods(Class.java:2745) at java.lang.Class.getDeclaredMethods(Class.java:1791) at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:197) at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:193) at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:67) at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:192) at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:282) at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:140) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:50) at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:38) at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:592) at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:462) at com.google.common.collect.CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2045) at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:164) at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:61) at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:88) at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:134) at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:377) at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:165) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:125) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:224) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:310) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235) at org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:141) at org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:573) There is nothing special about the BDA passed to weld - a single BDA with 621 classes. -- 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

4
16
0 / 0

[JBoss JIRA] Created: (WELD-443) Rewrite all beans to use builders and immutable objects

by Pete Muir (JIRA)

Rewrite all beans to use builders and immutable objects ------------------------------------------------------- Key: WELD-443 URL: https://jira.jboss.org/jira/browse/WELD-443 Project: Weld Issue Type: Feature Request Components: Built-in beans, Class Beans (Managed and Session), Producers (Methods, Fields and Disposers) Reporter: Pete Muir Priority: Critical Fix For: 1.0.2.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

13 years, 9 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues June 2010