April 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (CDITCK-44) Test coverage files are generated in directory from which maven is run

by Karel Piwko (JIRA)

Test coverage files are generated in directory from which maven is run ---------------------------------------------------------------------- Key: CDITCK-44 URL: https://jira.jboss.org/jira/browse/CDITCK-44 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Infrastructure Affects Versions: 1.0.0.CR2 Reporter: Karel Piwko When running maven target (install) from another directory than cdi-tck root, test coverage is generated in directory from which maven was fired. This caused unexpected FileNotFound when artifacts are to be installed: [trunk]$ mvn cdi-tck/pom.xml -Dtck-audit=true clean install [INFO] Installing /home/kpiwko/devel/weld/trunk/cdi-tck/target/coverage-cdi.html to /home/kpiwko/.m2/repository/org/jboss/jsr299/tck/jsr299-tck-impl/1.0.0-SNAPSHOT/jsr299-tck-impl-1.0.0-SNAPSHOT-coverage-cdi.html [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error installing artifact: File /home/kpiwko/devel/weld/trunk/cdi-tck/target/coverage-cdi.html does not exist Target directory is generated in trunk. This bug causes problems with automatized testing on Hudson. -- 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, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (CDITCK-209) TCK tests should not cleanup app context explicitly

by Ales Justin (JIRA)

TCK tests should not cleanup app context explicitly --------------------------------------------------- Key: CDITCK-209 URL: https://issues.jboss.org/browse/CDITCK-209 Project: CDI TCK Issue Type: Task Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Ales Justin Fix For: 1.1.0.CR1 Atm X cleans up app context, which breaks context lifecycle handling asymmetry. See WELD-858 for the use case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (WELD-363) Weld throws NPE in Google App Engine

by Shane Bryzak (JIRA)

Weld throws NPE in Google App Engine ------------------------------------ Key: WELD-363 URL: https://jira.jboss.org/jira/browse/WELD-363 Project: Weld Issue Type: Bug Reporter: Shane Bryzak Weld is throwing the following NPE in Google App Engine - this is not happening on the first page render, rather on a refresh (Pete mentioned it is probably a serialization issue). If you delete the session cookie and refresh the page again the exception is not thrown. EXCEPTION javax.servlet.ServletException: java.lang.NullPointerException at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:240) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:135) at com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:235) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5235) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:5233) at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24) at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:363) at com.google.net.rpc.impl.Server$2.run(Server.java:838) at com.google.tracing.LocalTraceSpanRunnable.run(LocalTraceSpanRunnable.java:56) at com.google.tracing.LocalTraceSpanBuilder.internalContinueSpan(LocalTraceSpanBuilder.java:536) at com.google.net.rpc.impl.Server.startRpc(Server.java:793) at com.google.net.rpc.impl.Server.processRequest(Server.java:368) at com.google.net.rpc.impl.ServerConnection.messageReceived(ServerConnection.java:448) at com.google.net.rpc.impl.RpcConnection.parseMessages(RpcConnection.java:319) at com.google.net.rpc.impl.RpcConnection.dataReceived(RpcConnection.java:290) at com.google.net.async.Connection.handleReadEvent(Connection.java:466) at com.google.net.async.EventDispatcher.processNetworkEvents(EventDispatcher.java:759) at com.google.net.async.EventDispatcher.internalLoop(EventDispatcher.java:205) at com.google.net.async.EventDispatcher.loop(EventDispatcher.java:101) at com.google.net.rpc.RpcService.runUntilServerShutdown(RpcService.java:251) at com.google.apphosting.runtime.JavaRuntime$RpcRunnable.run(JavaRuntime.java:394) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NullPointerException at org.jboss.weld.introspector.ForwardingAnnotated.isAnnotationPresent(ForwardingAnnotated.java:50) at org.jboss.weld.injection.FieldInjectionPoint.<init>(FieldInjectionPoint.java:62) at org.jboss.weld.injection.FieldInjectionPoint.of(FieldInjectionPoint.java:55) at org.jboss.weld.injection.FieldInjectionPoint$SerializationProxy.readResolve(FieldInjectionPoint.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeReadResolve(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.util.ArrayList.readObject(Unknown Source) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeReadObject(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.util.HashMap.readObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeReadObject(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at com.google.apphosting.runtime.jetty.SessionManager.deserialize(SessionManager.java:385) at com.google.apphosting.runtime.jetty.SessionManager.loadSession(SessionManager.java:307) at com.google.apphosting.runtime.jetty.SessionManager.getSession(SessionManager.java:282) at org.mortbay.jetty.servlet.AbstractSessionManager.getHttpSession(AbstractSessionManager.java:237) at org.mortbay.jetty.Request.getSession(Request.java:998) at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:393) at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:117) at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:341) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:725) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:238) ... 27 more -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (WELD-864) poor performance @Inject + Interceptor

by wojtek k (JIRA)

poor performance @Inject + Interceptor -------------------------------------- Key: WELD-864 URL: https://issues.jboss.org/browse/WELD-864 Project: Weld Issue Type: Bug Components: Interceptors and Decorators, Performance and Scalability Affects Versions: 1.1.0.Final Environment: OS name: "linux", version: "2.6.37-gentoo", arch: "i386", family: "unix" Java version: 1.6.0_24, vendor: Sun Microsystems Inc. Reporter: wojtek k I did some performance test using Weld Interceptors. I compared beans injected @Inject and @EJB. Beans had the same logic. Here are my results METHOD_INVOKED_COUNT=100000 This took time: 48872ms [@EJB Class EJB-Interceptor] This took time: 49133ms [@EJB Method EJB Interceptor] This took time: 48939ms [@EJB Class Method-Interceptor] This took time: 49115ms [@EJB Method Weld-Interceptor] This took time: 48812ms [@EJB No Interceptor] This took time: 4619ms [@Inject No Interceptor] This took time: 201270ms [@Inject Class Weld-Interceptor] This took time: 203329ms [@Inject Method Weld-Interceptor] This took time: 34ms [POJO] As you can see @Inject + Interceptor have poor performance. EJB Bean -> @Stateless Weld Bean ->@SessionScoped (2 instances was created) If you need source code for this test please inform me -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

4
10
0 / 0

[JBoss JIRA] Created: (WELD-818) Interceptors won't work on base beans if there's at least double inheritance

by Tomasz Szymanski (JIRA)

Interceptors won't work on base beans if there's at least double inheritance ---------------------------------------------------------------------------- Key: WELD-818 URL: https://issues.jboss.org/browse/WELD-818 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.0.CR3, 1.1.0.CR4 Environment: Mac OS X 10.6.5, Java SUN 1.6.0_22, mvn version 3.0.1 Reporter: Tomasz Szymanski Imagine you have an abstract BaseBean that is extended by abstract MiddleBean that is extended by the ImplementingBean. ImplementingBean is annotated with @Interceptable that is an Interceptor binding for TestInterceptor. Now calling any of the methods from any of those classes on an ImplementingBean should invoke the interceptor. The result is that the methods from MiddleBean and ImplementingBean are intercepted, while methods from BaseBean are not (!). If the BaseBean calls any method from either MiddleBean or ImplementingBean the call *will* get intercepted. If there's only one inheritance, it will work well. For 2 and more, only the parent of ImplementingBean gets intercepted. Please check the attached arquillian test. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
8
0 / 0

[JBoss JIRA] Created: (WELD-822) WeldClassImpl.getDeclaredMethods() may ignore superclass methods if the hierarchy is deep

by Marius Bogoevici (JIRA)

WeldClassImpl.getDeclaredMethods() may ignore superclass methods if the hierarchy is deep ----------------------------------------------------------------------------------------- Key: WELD-822 URL: https://issues.jboss.org/browse/WELD-822 Project: Weld Issue Type: Bug Components: Reflection layer Affects Versions: 1.1.0.CR4 Reporter: Marius Bogoevici Assignee: Marius Bogoevici Fix For: 1.2.0.Beta1 See the use case described in issue WELD-818. The foo() method is not returned by getDeclaredMethods() for ImplementationBean. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (WELD-882) Interceptors do not get applied to super-super-* class' methods.

by Ales Justin (JIRA)

Interceptors do not get applied to super-super-* class' methods. ---------------------------------------------------------------- Key: WELD-882 URL: https://issues.jboss.org/browse/WELD-882 Project: Weld Issue Type: Bug Reporter: Ales Justin Assignee: Ales Justin If the bean chain is longer than 2, the 3rd super-super-class' methods don't get intercepted. ClientDAO extends AbstractTimestampedDAO AbstractTimestampedDAO extends AbstractGenericDAO @Tx AbstractGenericDAO::save(E entity); ClientDAO cdao = ...; cdao::save(entity); <--- no @Tx interceptors apply * https://github.com/alesj/core/compare/2deep -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (WELD-881) Duplicate interceptors in concrete parameterized subclasses

by Marius Bogoevici (JIRA)

Duplicate interceptors in concrete parameterized subclasses ----------------------------------------------------------- Key: WELD-881 URL: https://issues.jboss.org/browse/WELD-881 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Reporter: Marius Bogoevici Assignee: Marius Bogoevici Fix For: 1.2.0.Beta1 If a concrete parameterized class extends a generic class, the methods that are inherited from the superclass, but not overridden have duplicate interceptors. e.g. class Parent<T> { @SomeBinding void doStuff(T param); } class Child extends Parent<String> { } This is due to getWeldMethods returning bridge methods and InterceptionModel not being able to figure out the difference between bridge methods and originals - possibly an unfixed case of WELD-568. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
1
0 / 0

[JBoss JIRA] Commented: (WELD-26) Add database support to login example

by Rob van den Bogaard (JIRA)

[ https://issues.jboss.org/browse/WELD-26?page=com.atlassian.jira.plugin.sy... ] Rob van den Bogaard commented on WELD-26: ----------------------------------------- Sorry for not responding for a while. Thanks again for the replies and updates. Unfortunately our development team moved away from Java for the time being... (I'll keep an eye on JBoss/Weld anyway :)) > Add database support to login example > ------------------------------------- > > Key: WELD-26 > URL: https://issues.jboss.org/browse/WELD-26 > Project: Weld > Issue Type: Task > Components: Examples > Reporter: Pete Muir > Priority: Minor > Fix For: 1.2.0.Beta1 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (WELD-27) Consider using JBoss maven plugin, not ant for example builds

by Ales Justin (JIRA)

[ https://issues.jboss.org/browse/WELD-27?page=com.atlassian.jira.plugin.sy... ] Ales Justin updated WELD-27: ---------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.1.Final) > Consider using JBoss maven plugin, not ant for example builds > ------------------------------------------------------------- > > Key: WELD-27 > URL: https://issues.jboss.org/browse/WELD-27 > Project: Weld > Issue Type: Task > Components: Examples > Reporter: Pete Muir > Assignee: Dan Allen > Fix For: 1.2.0.Beta1 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues April 2011