March 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] (WELD-1016) Weld creates multiple interceptor instances per target instance

by Jozef Hartinger (Created) (JIRA)

Weld creates multiple interceptor instances per target instance --------------------------------------------------------------- Key: WELD-1016 URL: https://issues.jboss.org/browse/WELD-1016 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.2.Final Reporter: Jozef Hartinger Fix For: 1.1.4.Final, 2.0.0.Final The CDI spec says: {quote} An interceptor instance is a dependent object of the object it inter-cepts. {quote} The Interceptors spec says: {quote} The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated. When the target instance is created, a corresponding interceptor instance is created for each associated interceptor class. These interceptor instances are destroyed when the target instance is removed. {quote} and also {quote} An interceptor instance may hold state. {quote} It is clear that at most one instance of an interceptor class should be created for an instance of a CDI bean. However, Weld currently creates an instance per method per target instance. Having a simple intercepted bean: {code:JAVA} @ApplicationScoped @LionBinding public class Lion public Object foo() { return null; } public Object bar() { return null; } } {code} * multiple invocations of a single method (e.g. foo()) are intercepted by the same interceptor instance * when invoking different methods on the same bean instance, every method is intercepted by a different interceptor instance - which is wrong -- 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, 1 month

6
9
0 / 0

[JBoss JIRA] Created: (WELD-580) Around-Invoke Interceptors with wrong signature should cause DefinitionException

by Aslak Knutsen (JIRA)

Around-Invoke Interceptors with wrong signature should cause DefinitionException -------------------------------------------------------------------------------- Key: WELD-580 URL: https://jira.jboss.org/browse/WELD-580 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.0.1.Final Reporter: Aslak Knutsen Around-invoke methods have the following signature: Object <METHOD>(InvocationContext) throws Exception Interceptors that does not follow that should cause a DefinitionException. In current impl they are registered, enabled but can not be resolved on Bean lookup. -- 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

12 years, 1 month

7
17
0 / 0

[JBoss JIRA] Created: (WELD-687) Refactoring InstantiatorFactory to allow per-deployment configuration

by Marius Bogoevici (JIRA)

Refactoring InstantiatorFactory to allow per-deployment configuration --------------------------------------------------------------------- Key: WELD-687 URL: https://jira.jboss.org/browse/WELD-687 Project: Weld Issue Type: Feature Request Affects Versions: 1.1.0.Beta1 Reporter: Marius Bogoevici Fix For: 1.1.0.Beta2 InstantiatorFactory is currently using static fields for storing the enabled/disabled status for unsafe instantiators, as well as the instantiator that should be used. In a shared library scenario, the instantiator factory will be enabled if at least one of the deployed applications contains the META-INF/org.jboss.weld.enableUnsafeProxies resource. -- 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

12 years, 1 month

6
14
0 / 0

[JBoss JIRA] (WELD-1092) Configure m2e to ignore Checkstyle Plugin

by Andrew Rubinger (JIRA)

Andrew Rubinger created WELD-1092: ------------------------------------- Summary: Configure m2e to ignore Checkstyle Plugin Key: WELD-1092 URL: https://issues.jboss.org/browse/WELD-1092 Project: Weld Issue Type: Task Reporter: Andrew Rubinger Prevents clean import of Weld into Eclispe. Configure the Weld Parent POM to instruct m2e not to attempt to apply the Checkstyle plugin for use in the IDE. -- 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, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (WELD-905) @Alternative broken if multiple implementations are in the classpath

by Gerhard Petracek (JIRA)

@Alternative broken if multiple implementations are in the classpath -------------------------------------------------------------------- Key: WELD-905 URL: https://issues.jboss.org/browse/WELD-905 Project: Weld Issue Type: Bug Components: Resolution (Typesafe and by Name) Affects Versions: 1.1.1.Final Reporter: Gerhard Petracek Priority: Critical example (broken): bean-archive #1: - BeanA - BeanA1 (@Alternative) - beans.xml (activates BeanA1 as alternative) bean-archive #2: - BeanA2 (@Typed()) - beans.xml (empty) BeanA1 doesn't get used (without an error or a warning BeanA is used instead - even though BeanA1 is activated as alternative in the same bean-archive) example (working): bean-archive #1: - BeanA - BeanA1 (@Alternative) - beans.xml (activates BeanA1 as alternative) jar #2 (no bean-archive): - BeanA2 (@Typed()) BeanA1 gets activated as alternative (as expected) because jar #2 isn't a bean-archive (that's the difference compared to the broken example). that prevents >e.g.< portable extensions from providing extension-points to work around the broken @Alternative spec. section. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
15
0 / 0

[JBoss JIRA] Created: (WELD-571) Interceptors not working for dependent scoped beans when using InjectionTarget

by Francois Swiegers (JIRA)

Interceptors not working for dependent scoped beans when using InjectionTarget ------------------------------------------------------------------------------ Key: WELD-571 URL: https://jira.jboss.org/browse/WELD-571 Project: Weld Issue Type: Bug Affects Versions: 1.0.1.Final Reporter: Francois Swiegers When creating an intercepted bean of dependent scope using an InjectionTarget, the interceptor is not active. -- 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

12 years, 1 month

5
18
0 / 0

[JBoss JIRA] (WELD-1084) Introduce class InterceptorBinding

by Marko Lukša (JIRA)

Marko Lukša created WELD-1084: --------------------------------- Summary: Introduce class InterceptorBinding Key: WELD-1084 URL: https://issues.jboss.org/browse/WELD-1084 Project: Weld Issue Type: Task Reporter: Marko Lukša Assignee: Marko Lukša Currently, there is no special class representing interceptor bindings. The bindings are represented as {{Annotation}}. Thus it is impossible to know whether {{Set<Annotation>}} contains only annotations representing interceptor bindings or other annotations also. Also, Annotation instances are proxied and their {{equals}} is broken, so that {{annotation1.equals(annotation2)}} will return false even if both annotation1 and annotation2 represent the same annotation (e.g. @MyAnnotation). Furthermore, when considering if two interceptor bindings are equal, all the non-binding members of the annotation should be ignored. If instead of just passing around {{Annotation}}s, we passed {{InterceptorBinding}}s, a lot of the code would be clearer and we'd also probably have no bugs related to the proxy.equals bug. -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] (WELD-1086) NPE while using Weld EE to test EJB

by Anthony O. (JIRA)

Anthony O. created WELD-1086: -------------------------------- Summary: NPE while using Weld EE to test EJB Key: WELD-1086 URL: https://issues.jboss.org/browse/WELD-1086 Project: Weld Issue Type: Bug Components: Testing Infrastructure (Mocks and Harness Integration) Affects Versions: 1.1.2.Final Reporter: Anthony O. As seen in [this post on the Arquillian forum|https://community.jboss.org/message/723563], we cannot test that simple class as an NPE is thrown from {{org.jboss.arquillian.container.weld.ee.embedded_1_1.mock.MockEjBServices}} which seems to be a copy of Weld code as [Aslak Knutsen|https://community.jboss.org/people/aslak] said. {code} @RunWith(Arquillian.class) public class EJBTest { @Deployment public static JavaArchive createTestArchive() { return ShrinkWrap .create(JavaArchive.class, "test.jar") .addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); } @Stateless public static class SomeService { public String someMethod() { return "test"; } } @Inject SomeService someService; @Test public void testStatelessCall() { Assert.assertEquals("test", someService.someMethod()); } } {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

12 years, 1 month

4
7
0 / 0

[JBoss JIRA] (WELD-1091) Test failures on JDK7

by Stuart Douglas (JIRA)

Stuart Douglas created WELD-1091: ------------------------------------ Summary: Test failures on JDK7 Key: WELD-1091 URL: https://issues.jboss.org/browse/WELD-1091 Project: Weld Issue Type: Bug Affects Versions: 1.1.5.Final, 1.2.0.Beta1 Reporter: Stuart Douglas Assignee: Stuart Douglas JDK seems to have changed which methods get the BRIDGE flag, and javassist is really retarded at handling bridge methods. -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (WELD-655) maven-jetty-plugin not configured correctly

by Jozef Hartinger (JIRA)

maven-jetty-plugin not configured correctly ------------------------------------------- Key: WELD-655 URL: https://jira.jboss.org/browse/WELD-655 Project: Weld Issue Type: Bug Components: Examples Affects Versions: 1.1.0.Beta1 Reporter: Jozef Hartinger Fix For: 1.1.0.Beta2 Following instructions from the reference documentation (Chapter 6.5. Deploying to Jetty) I get the following error after running "mvn war:inplace jetty:run -Pjetty" [ERROR] Failed to execute goal org.mortbay.jetty:maven-jetty-plugin:6.1.21:run (default-cli) on project weld-jsf-numberguess: jetty-env.xml file does not exist at location /home/jharting/jboss/testing/Weld-1.1.0.Beta1/weld-1.1.0.Beta1/examples/jsf/numberguess/src/main/resources/jetty-env.xml -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.mortbay.jetty:maven-jetty-plugin:6.1.21:run (default-cli) on project weld-jsf-numberguess: jetty-env.xml file does not exist at location /home/jharting/jboss/testing/Weld-1.1.0.Beta1/weld-1.1.0.Beta1/examples/jsf/numberguess/src/main/resources/jetty-env.xml at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:141) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160) at org.apache.maven.cli.MavenCli.main(MavenCli.java:124) 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: jetty-env.xml file does not exist at location /home/jharting/jboss/testing/Weld-1.1.0.Beta1/weld-1.1.0.Beta1/examples/jsf/numberguess/src/main/resources/jetty-env.xml at org.mortbay.jetty.plugin.AbstractJettyRunMojo.checkPomConfiguration(AbstractJettyRunMojo.java:258) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:382) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133) ... 19 more The jetty-env.xml file is present in src/main/webapp-jetty/WEB-INF/jetty-env.xml. -- 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

12 years, 1 month

6
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues March 2012