[JBoss JIRA] (WELD-1045) ProcessBeanAttributes not fired for interceptors and decorators
by Martin Kouba (Created) (JIRA)
ProcessBeanAttributes not fired for interceptors and decorators
---------------------------------------------------------------
Key: WELD-1045
URL: https://issues.jboss.org/browse/WELD-1045
Project: Weld
Issue Type: Bug
Reporter: Martin Kouba
Assignee: Jozef Hartinger
Fix For: 2.0.0.Alpha1
The spec (CDI 1.1) states: "The container must fire an event for each enabled bean, interceptor or decorator deployed in a bean archive, before registering the Bean object."
However ProcessBeanAttributes is not fired for interceptors and decorators.
Probably because of *BeanDeployerEnvironment.addInterceptor(InterceptorImpl<?>)* and *BeanDeployerEnvironment.addDecorator(DecoratorImpl<?>)* do not add intercetors and decorators bean to classBeanMap - the source of beans used in *org.jboss.weld.bootstrap.BeanDeployer.processBeans()*.
--
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
11 years, 9 months
[JBoss JIRA] Created: (WELD-935) Do not deploy shaded jars like weld-servlet (as a bad replacement for weld-servlet-core) because they break dependency conflict resolution and introduce classpath issues
by Geoffrey De Smet (JIRA)
Do not deploy shaded jars like weld-servlet (as a bad replacement for weld-servlet-core) because they break dependency conflict resolution and introduce classpath issues
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: WELD-935
URL: https://issues.jboss.org/browse/WELD-935
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.1.Final
Reporter: Geoffrey De Smet
Shading = repackaging a dependency class inside your own jar (instead of depending on the jar of that class).
I've just spend quite some time trying to find such a classpath issue, which manifested it self as "NoSuchMethodError on slf4j LocationAwareLogger.log(...)"
It turns out the weld-servlet jar was shading some of the slf4j classes.
Shading is evil. Here's why:
- It breaks maven/gradle/buildr/ivy dependency conflict resolution. If guvnor uses slf4j 1.6 and weld-servlet; and weld-servlet shades slf4J 1.5; maven will not detect a slf4j version conflict and will therefor have no chance to put only 1 version of slf4J in the classpath. As a result, there's no telling which slf4J version will be used (the first in the classpath, but that is very unstable)
- It distorts ANT's classpath: putting the weld-servlet jar (with slf4J 1.5) in your classpath can effectively turn the explicit slf4j-1.6.0.jar in your classpath into dead code or combine it with binary incompatibly slf4j extensions such as xstream-for-slf4j-1.6.0.jar (fictive example).
- Because the slf4j classes are actually in the weld-servlet jar, they cause bloat: the user might have already downloaded the real slf4j jar.
- Most importantly, because the (Red Hat and other) guys who create RPM's out of our jars say so. See slide 13 of this Fosdem presentation: http://sochotni.fedorapeople.org/fosdem2011-sochotnicky.pdf (video : http://ia600608.us.archive.org/16/items/fosdem_2011_free_java_guide_to_pa...)
Summary: shading will cause grief for your users. Why subject your users to grief? In this case, don't give them a good and a bad choice, only give them a good choice.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (WELD-1057) One WELD's performance
by z xj (JIRA)
z xj created WELD-1057:
--------------------------
Summary: One WELD's performance
Key: WELD-1057
URL: https://issues.jboss.org/browse/WELD-1057
Project: Weld
Issue Type: Quality Risk
Components: Performance and Scalability
Affects Versions: 1.1.2.Final
Reporter: z xj
Synopsis:
The time of deployment by WELD will grow exponentailly if JAR files in application increases.
Version:
WELD 1.1.2
Details:
The current implementation below checks circular references when deploying.
org.jboss.weld.bootstrap.WeldBootstrap.DeploymentVisitor#visit()
However, if application EAR file includes many JARs or WARs, the time spent on circularity check increases exponentially.
--
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
11 years, 11 months
[JBoss JIRA] (WELD-1058) Perm heap bloat
by z xj (JIRA)
z xj created WELD-1058:
--------------------------
Summary: Perm heap bloat
Key: WELD-1058
URL: https://issues.jboss.org/browse/WELD-1058
Project: Weld
Issue Type: Bug
Components: GlassFish Integration, Performance and Scalability
Affects Versions: 1.1.2.Final
Reporter: z xj
Synopsis:
The proxy classes generated at application start time are kept after stopping application. It will result in perm heap bloat if application's start/stop are repeated.
Version:
WELD 1.1.2
Details:
The current RI uses javassist to generate the corresponding proxy class of Principal, UserTransaction, ValidatorFactory and Validator at application start time. Javassist load those proxy classes via system's class loader and that class loader is not discarded after stopping application, therefore those proxy classes remain there. At application development phase, repeating application's start/stop will lead to memory leak with this behavior.
--
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
11 years, 11 months
[JBoss JIRA] Created: (WELD-769) Intercepting a method in a bean where another method is final causes a VerifyError
by Adam Warski (JIRA)
Intercepting a method in a bean where another method is final causes a VerifyError
----------------------------------------------------------------------------------
Key: WELD-769
URL: https://jira.jboss.org/browse/WELD-769
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: by java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V
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.WeldException: by java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:268)
at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:198)
at org.jboss.weld.bean.ManagedBean.applyInterceptors(ManagedBean.java:564)
... 44 more
Caused by: javassist.CannotCompileException: by java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:117)
at org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:376)
at org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:264)
... 46 more
Caused by: java.lang.VerifyError: class pl.softwaremill.weldbugs.bug2.org$jboss$weld$bean-1ed4ae51-6ceb-40b2-899a-ed6d1f90409e$jar-ManagedBean-class_pl$softwaremill$weldbugs$bug2$TestBean2_$$_WeldProxy overrides final method someMethod.()V
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
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.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:143)
at org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:109)
... 48 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 11 months
[JBoss JIRA] (WELD-993) Cannot declare web service resource using @WebServiceRef
by Martin Kouba (Created) (JIRA)
Cannot declare web service resource using @WebServiceRef
--------------------------------------------------------
Key: WELD-993
URL: https://issues.jboss.org/browse/WELD-993
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.2.Final
Reporter: Martin Kouba
Following web service resource definition (see CDI 1.0 section 3.5 Resources) results in:
*WELD-000025 Tried to create an EEResourceProducerField, but no @Resource, @PersistenceContext, @PersistenceUnit, @WebServiceRef or @EJB is present*
{code}
public class SheepWSProducer {
@Produces
@WebServiceRef
SheepWS sheepWS;
}
{code}
There is no CDI TCK test for this yet.
The problem is very likely related to weird checking code in *org.jboss.weld.bean.builtin.ee.EEResourceProducerField.checkEEResource()* - the first group evaluates to false and is inverted to true with "!" operator and thus exception is thrown:
{code}
...
if (!
(
getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.RESOURCE_ANNOTATION_CLASS)
|| getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_CONTEXT_ANNOTATION_CLASS)
|| getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_UNIT_ANNOTATION_CLASS)
|| getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.EJB_ANNOTATION_CLASS)
)
|| getWeldAnnotated().isAnnotationPresent(wsApiAbstraction.WEB_SERVICE_REF_ANNOTATION_CLASS)
)
{
throw new IllegalStateException(INVALID_RESOURCE_PRODUCER_FIELD, getWeldAnnotated());
}
...
{code}
Should be replaced with something like:
{code}
...
if (!
(
getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.RESOURCE_ANNOTATION_CLASS)
|| getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_CONTEXT_ANNOTATION_CLASS)
|| getWeldAnnotated().isAnnotationPresent(persistenceApiAbstraction.PERSISTENCE_UNIT_ANNOTATION_CLASS)
|| getWeldAnnotated().isAnnotationPresent(ejbApiAbstraction.EJB_ANNOTATION_CLASS)
|| getWeldAnnotated().isAnnotationPresent(wsApiAbstraction.WEB_SERVICE_REF_ANNOTATION_CLASS)
)
)
{
throw new IllegalStateException(INVALID_RESOURCE_PRODUCER_FIELD, getWeldAnnotated());
}
{code}
--
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
11 years, 11 months