[JBoss JIRA] (WELD-1133) Session EJB deployment failure
by Joseph Snyder (JIRA)
Joseph Snyder created WELD-1133:
-----------------------------------
Summary: Session EJB deployment failure
Key: WELD-1133
URL: https://issues.jboss.org/browse/WELD-1133
Project: Weld
Issue Type: Bug
Components: GlassFish Integration, Infrastructure
Affects Versions: 1.1.8.Final, 1.1.7.Final, 1.1.6.Final, 1.1.5.Final
Environment: linux
Reporter: Joseph Snyder
Starting with Weld 1.1.5.Final there are several CTS failures when running CTS against GlassFish. One specific test failure is org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.EnterpriseBeanSpecializationIntegrationTest. When the application associated with this test is deployed the deployment fails (see "Deployment Failure" below). I investigated the specs and it appears that weld is expecting the type of the session ejb (Office) to include the interface defined by the session bean that it extends (Building).
The CDI spec states in section "4.3.1 Direct and indirect specialization"
...
Furthermore, X must have all the bean types of Y. If X does not have some bean type of Y, the container automatically detects the problem and treats it as a definition error.
..
However this is in direct violation of the ejb 3.1 specification section 4.9.2.1 Session Bean Superclasses:
...
As an example, the client views exposed by a particular session bean are not inherited by a subclass that also happens to define a session bean.
@Stateless
public class A implements Foo { ... }
@Stateless
public class B extends A implements Bar { ... }
Assuming Foo and Bar are local business interfaces and there is no associated deployment descriptor, session bean A exposes local business interface Foo and session bean B exposes local business interface Bar, but not Foo.
...
Deployment Failure:
[#|2012-05-09T18:19:20.875-0400|SEVERE|44.0|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=12;_ThreadName=Thread-2;|WELD-001511 Specializing bean Session bean [class org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.Office with qualifiers [@Any @Default]; local interfaces are [OfficeLocal] does not have bean type interface org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.BuildingLocal of specialized bean Session bean [class org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.Building with qualifiers [@Any @Default]; local interfaces are [BuildingLocal]
org.glassfish.deployment.common.DeploymentException: WELD-001511 Specializing bean Session bean [class org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.Office with qualifiers [@Any @Default]; local interfaces are [OfficeLocal] does not have bean type interface org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.BuildingLocal of specialized bean Session bean [class org.jboss.jsr299.tck.tests.inheritance.specialization.enterprise.Building with qualifiers [@Any @Default]; local interfaces are [BuildingLocal]
--
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
12 years, 6 months
[JBoss JIRA] (WELD-1141) Bean proxy class has non-varargs method for original varargs method
by Adam Michalik (JIRA)
Adam Michalik created WELD-1141:
-----------------------------------
Summary: Bean proxy class has non-varargs method for original varargs method
Key: WELD-1141
URL: https://issues.jboss.org/browse/WELD-1141
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.8.Final
Reporter: Adam Michalik
Test case:
@RequestScoped
public class TestVarargs {
public void varargsMethod(String... strings) {}
}
public class TestClass {
@Inject
TestVarargs testVarargs;
public void runTest() {
testClass(testVarargs.getClass());
testClass(TestVarargs.class);
}
private void testClass(Class<?> clazz) {
for (Method m : clazz.getMethods()) {
if (m.getName().equals("varargsMethod")) {
System.out.println(clazz + " : " + m + " : " + m.isVarArgs());
}
}
}
}
Prints:
class TestVarargs$Proxy$_$$_WeldClientProxy : public void TestVarargs$Proxy$_$$_WeldClientProxy.varargsMethod(java.lang.String[]) : false
class TestVarargs : public void TestVarargs.varargsMethod(java.lang.String[]) : true
The method generated in Weld proxy class is not a varargs method while the original one was. This breaks proper method lookup in tools that use reflection - in my case it was ZK EL resolver: for ${bean.method('String arg')} where signature is method(String...) there was proper code to handle a varargs call but only if the method was indeed declared as Method.isVarargs(), which was not the case when ${bean} was a Weld proxy.
--
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
12 years, 6 months
[JBoss JIRA] (WELD-1135) Investigate faster ways of performing type safe resolution
by Stuart Douglas (JIRA)
Stuart Douglas created WELD-1135:
------------------------------------
Summary: Investigate faster ways of performing type safe resolution
Key: WELD-1135
URL: https://issues.jboss.org/browse/WELD-1135
Project: Weld
Issue Type: Bug
Reporter: Stuart Douglas
Fix For: 1.2.0.CR1
At the moment quite a lot of bootstrap time is spent resolving injection points and events. By far the majority of this time is spent resolving container events that form part of the portable extensions SPI. As these events are parameterised types the resolution cannot be cached (as ProcessAnnotatedType<ClassA> can resolve differently to ProcessAnnotatedType<ClassB> ).
We should investigate if there is a faster way to do this, if not in the general case then at least for these container events.
--
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
12 years, 6 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
12 years, 6 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
12 years, 6 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
12 years, 6 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
12 years, 6 months