December 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-785) "Minor refactor and fix test to be more robust" commit to weld/core/master causes a big performance decline

by Martin Gencur (JIRA)

"Minor refactor and fix test to be more robust" commit to weld/core/master causes a big performance decline ----------------------------------------------------------------------------------------------------------- Key: WELD-785 URL: https://issues.jboss.org/browse/WELD-785 Project: Weld Issue Type: Bug Components: Conversations, Scopes & Contexts Reporter: Martin Gencur Assignee: Pete Muir Fix For: 1.1.0.CR1 This commit causes a big performance decline when the application is being accessed from higher number of sessions. Now the stress test can only reach 6500 sessions at most. Removing this commit gets the max number of sessions up to 12600. This is mainly caused by heap memory not being freed sufficiently. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (WELD-770) Intercepting a bean with constructor injection causes an InstantiationException

by Adam Warski (JIRA)

Intercepting a bean with constructor injection causes an InstantiationException ------------------------------------------------------------------------------- Key: WELD-770 URL: https://jira.jboss.org/browse/WELD-770 Project: Weld Issue Type: Bug Components: Proxies Affects Versions: 1.1.0.Beta2 Reporter: Adam Warski Used to work fine until AS6 CR1 (tested in M2 and M4). Stack trace: org.jboss.arquillian.impl.event.FiredEventException: java.lang.RuntimeException: Could not inject members at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:68) at org.jboss.arquillian.impl.context.AbstractEventContext.fire(AbstractEventContext.java:115) at org.jboss.arquillian.impl.EventTestRunnerAdaptor.before(EventTestRunnerAdaptor.java:97) at org.jboss.arquillian.testng.Arquillian.arquillianBeforeTest(Arquillian.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443) at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160) at org.testng.internal.Invoker.invokeMethod(Invoker.java:494) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121) at org.testng.TestRunner.runWorkers(TestRunner.java:908) at org.testng.TestRunner.privateRun(TestRunner.java:617) at org.testng.TestRunner.run(TestRunner.java:498) at org.testng.SuiteRunner.runTest(SuiteRunner.java:329) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296) at org.testng.SuiteRunner.run(SuiteRunner.java:201) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:92) Caused by: java.lang.RuntimeException: Could not inject members at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:103) at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:52) at org.jboss.arquillian.impl.handler.TestCaseEnricher.callback(TestCaseEnricher.java:42) at org.jboss.arquillian.impl.handler.TestCaseEnricher.callback(TestCaseEnricher.java:32) at org.jboss.arquillian.impl.event.MapEventManager.fire(MapEventManager.java:63) ... 27 more Caused by: org.jboss.weld.exceptions.DeploymentException: pl.softwaremill.weldbugs.bug3.org$jboss$weld$bean-c545a346-00cf-487d-9f47-7f2cbd100daf$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug3$TestBean3_2_$$_WeldProxy at org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:569) at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.produce(ManagedBean.java:250) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:332) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:59) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:669) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:743) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:137) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:869) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:881) at org.jboss.weld.manager.SimpleInjectionTarget$1.proceed(SimpleInjectionTarget.java:122) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:54) at org.jboss.weld.manager.SimpleInjectionTarget.inject(SimpleInjectionTarget.java:116) at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectNonContextualInstance(CDIInjectionEnricher.java:113) at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:93) ... 31 more Caused by: org.jboss.weld.exceptions.DefinitionException: pl.softwaremill.weldbugs.bug3.org$jboss$weld$bean-c545a346-00cf-487d-9f47-7f2cbd100daf$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug3$TestBean3_2_$$_WeldProxy at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:224) at org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:564) ... 44 more Caused by: java.lang.InstantiationException: pl.softwaremill.weldbugs.bug3.org$jboss$weld$bean-c545a346-00cf-487d-9f47-7f2cbd100daf$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug3$TestBean3_2_$$_WeldProxy at java.lang.Class.newInstance0(Class.java:340) at java.lang.Class.newInstance(Class.java:308) at org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:396) at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureReflectionAccess.java:216) at org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.java:391) at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:219) ... 45 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (WELD-771) Interception of beans with final methods causes final methods to be invoked on the proxy

by Stuart Douglas (JIRA)

Interception of beans with final methods causes final methods to be invoked on the proxy ---------------------------------------------------------------------------------------- Key: WELD-771 URL: https://jira.jboss.org/browse/WELD-771 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.Beta2 Reporter: Stuart Douglas Fix For: 1.1.0.Beta3 We currently allow method level interceptors on beans that also have private methods, which causes the final methods to be invoked on the proxy. There are two options here: - Fix WELD-437 (implement interception through subclassing) - Pick this up in the verification phase and either log a warning or throw an exception -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (WELD-705) Changes made to a superclass's AnnotatedType by extensions not taken into account while sending ProcessAnnotatedType events pertaining to the subclass

by Sivakumar Thyagarajan (JIRA)

Changes made to a superclass's AnnotatedType by extensions not taken into account while sending ProcessAnnotatedType events pertaining to the subclass ------------------------------------------------------------------------------------------------------------------------------------------------------ Key: WELD-705 URL: https://jira.jboss.org/browse/WELD-705 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 1.1.0.Beta1 Environment: Jersey extension in GlassFish faces this issue Reporter: Sivakumar Thyagarajan Fix For: 1.1.0.Beta2 It appears that Weld does not take into account changes made to a superclass's AnnotatedType by extensions, when sending ProcessAnnotatedType events pertaining to the subclass. Please find attached a netbeans project that demonstrates the problem. It is a web app containing a CDI extension that patches the annotated types it sees to remove all their fields. BeanOne has one field: @Inject BeanManager beanManager; BeanTwo extends BeanOne and doesn't add any fields. There are no other injection points. The portable extensions patches the annotated type for BeanOne and removes the BeanManager injection point. However on execution, this output appears in the server log: (all the diagnostic output is at warning level...) === WARNING: Handling BeforeBeanDiscovery event WARNING: Handling ProcessAnnotatedType event for beans.BeanOne WARNING: type has 0 fields WARNING: replaced annotated type for class beans.BeanOne WARNING: Handling ProcessAnnotatedType event for beans.BeanTwo WARNING: type has 0 fields WARNING: replaced annotated type for class beans.BeanTwo WARNING: Handling ProcessManagedBean event for beans.BeanTwo WARNING: found injection point interface javax.enterprise.inject.spi.BeanManager @javax.enterprise.inject.Default() WARNING: Handling ProcessManagedBean event for beans.BeanOne === I.e. in BeanOne the field has been correctly nuked, but it comes back in BeanTwo. Weld may be holding a reference to the old AnnotatedType for BeanOne as part of its internal representation for BeanTwo and uses that instead of the replacement provided by the extension. Since annotated types are self-contained, so Weld should not even look at BeanOne at that point. The same behavior can be observed on both GF 3.0.1 (=WELD-000900 1.0.1 (SP3)) and GF 3.1-b16 (=WELD-000900 1.1.0.01 (glassfish)). A glassfish issue tracking this Jersey extension problem is at https://glassfish.dev.java.net/issues/show_bug.cgi?id=13132 -- 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, 11 months

4
14
0 / 0

[JBoss JIRA] Created: (WELD-782) Better exception message when bean creation fails in EL resolver

by Dan Allen (JIRA)

Better exception message when bean creation fails in EL resolver ---------------------------------------------------------------- Key: WELD-782 URL: https://jira.jboss.org/browse/WELD-782 Project: Weld Issue Type: Bug Components: Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.0.Beta2 Reporter: Dan Allen When bean creation fails in the EL resolver, Weld reports a misleading error message (defined by ElMessages.RESOLUTION_ERROR) WELD-001000 Error resolving property orderBean against base null The problem is that the EL resolver just wraps the bean creation in a try/catch block and reports this message if it fails (near end of AbstractWeldELResolver#getValue()). The includes any failures that come from a post-construct/initializer method. At this point in the code, base is always null because a bean is being resolved by name (the bean name is in the propertyString). Weld should clarify that bean creation failed during bean creation and remove the null reference in the message. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (WELD-711) Calling Contextual.destroy on an instance still references an instance on BeanManager

by George Gastaldi (JIRA)

Calling Contextual.destroy on an instance still references an instance on BeanManager ------------------------------------------------------------------------------------- Key: WELD-711 URL: https://jira.jboss.org/browse/WELD-711 Project: Weld Issue Type: Bug Components: Scopes & Contexts Affects Versions: 1.1.0.Beta1, 1.0.1.Final Reporter: George Gastaldi Attachments: report.txt Using the seam-faces module @ViewScoped extension, when the object is destroyed by Contextual.destroy, weld still references an instance, avoiding being garbage-collected. {code} Contextual contextual = ... Object instance = ... CreationalContext creational = ... contextual.destroy(instance, creational); {code} -- 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, 11 months

4
28
0 / 0

[JBoss JIRA] Updated: (WELD-13) Switch to using a builder to make immutable bean objects

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/WELD-13?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated WELD-13: -------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR1) > Switch to using a builder to make immutable bean objects > -------------------------------------------------------- > > Key: WELD-13 > URL: https://issues.jboss.org/browse/WELD-13 > Project: Weld > Issue Type: Feature Request > Components: Class Beans (Managed and Session) > Reporter: Pete Muir > Fix For: 1.2.0.Beta1 > > > Currently we do a lot of init in the *Bean which, to be flexible, isn't in the constructor, which stops the Bean objects being truly immutable. It's also not nice to read. > A challenge will be the two phase bootstrap. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (WELD-53) Full review of built in Reflection layer

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/WELD-53?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated WELD-53: -------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR1) > Full review of built in Reflection layer > ---------------------------------------- > > Key: WELD-53 > URL: https://issues.jboss.org/browse/WELD-53 > Project: Weld > Issue Type: Feature Request > Components: Resolution (Typesafe and by Name) > Reporter: Pete Muir > Fix For: 1.2.0.Beta1 > > > A few things: > * should we use javassist? > * need a full review of how we deal with Annotated* -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (WELD-437) Use subclasses for interceptors and decorators

by Pete Muir (JIRA)

Use subclasses for interceptors and decorators ---------------------------------------------- Key: WELD-437 URL: https://jira.jboss.org/jira/browse/WELD-437 Project: Weld Issue Type: Bug 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, 11 months

3
9
0 / 0

[JBoss JIRA] Created: (CDITCK-192) All test wars are invalid javaee artifacts since they have "Class-Path: null" manifest header

by David Jencks (JIRA)

All test wars are invalid javaee artifacts since they have "Class-Path: null" manifest header --------------------------------------------------------------------------------------------- Key: CDITCK-192 URL: https://jira.jboss.org/browse/CDITCK-192 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.2.CR3 Reporter: David Jencks cf javaee_platform-6_0-fr-spec.pdf EE.8.2.1: Only JAR format files or directories containing class files or resources to be loaded directly by a standard class loader should be the target of a Class-Path reference; such files are always named with a .jar extension. Top level JAR files that are processed by a deployment tool should not contain Class-Path entries; such entries would, by definition, reference other files external to the deployment unit. A deployment tool is not required to process such external references. 2 So there should be no Class-Path header, and if there is it should only have .jar files in it. -- 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, 11 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues December 2010