December 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-778) Weld must be able to support extension discovery in the modules of an multi-module application (EAR)

by Marius Bogoevici (JIRA)

Weld must be able to support extension discovery in the modules of an multi-module application (EAR) ---------------------------------------------------------------------------------------------------- Key: WELD-778 URL: https://jira.jboss.org/browse/WELD-778 Project: Weld Issue Type: Feature Request Affects Versions: 1.1.0.Beta2 Reporter: Marius Bogoevici Fix For: Spec Clarification Required Currently, only extensions which are visible to the entire application (i.e. all modules) are installed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
9
0 / 0

[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

3
6
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

3
4
0 / 0

[JBoss JIRA] Created: (WELD-729) Servlet / listener / filter injection support for Jetty 7 and up

by Dan Allen (JIRA)

Servlet / listener / filter injection support for Jetty 7 and up ---------------------------------------------------------------- Key: WELD-729 URL: https://jira.jboss.org/browse/WELD-729 Project: Weld Issue Type: Feature Request Components: Servlet Container Support Affects Versions: 1.1.0.Beta1 Reporter: Dan Allen Fix For: 1.1.0.Beta2 Jetty changed it's packaging in version 7 when it moved to the Eclipse runtimes project. Therefore, the following required class check only works in earlier versions of Jetty. private static final String JETTY_REQUIRED_CLASS_NAME = "org.mortbay.jetty.servlet.ServletHandler"; boolean jetty = true; try { Reflections.classForName(JETTY_REQUIRED_CLASS_NAME); } catch (IllegalArgumentException e) { jetty = false; } A second check should be performed for the class org.eclipse.jetty.servlet.ServletHandler. But then we have the issue that the WeldServletHandler extends a class only in Jetty 6. So we'll likely need a special classifier for weld-servlet that runs on jetty 7 and above. -- 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, 1 month

4
12
0 / 0

[JBoss JIRA] Created: (WELDX-83) Injection into servlet Listeners on Tomcat standalone

by Matija Mazi (JIRA)

Injection into servlet Listeners on Tomcat standalone ----------------------------------------------------- Key: WELDX-83 URL: https://jira.jboss.org/jira/browse/WELDX-83 Project: Weld Extensions Issue Type: Bug Components: Servlet Containers Affects Versions: Servlet Containers 1.0.1, Servlet Containers 1.0.2.CR1 Environment: Tomcat 6.0.24 standalone Reporter: Matija Mazi I've written tests for injection into Filters and Listeners; the Filter injection test passes but the Listener injection test fails on standalone Tomcat 6.0.24. (I think injection into Listeners works on JBoss Web, though.) The patch containing the tests is attached. -- 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, 1 month

4
14
0 / 0

[JBoss JIRA] Created: (WELD-783) @EJB injection fails in @Named bean when interceptor is present

by Alexander Hanschke (JIRA)

@EJB injection fails in @Named bean when interceptor is present --------------------------------------------------------------- Key: WELD-783 URL: https://jira.jboss.org/browse/WELD-783 Project: Weld Issue Type: Bug Components: CDI API, Interceptors and Decorators Affects Versions: 1.0.1.Final Environment: Windows 7, NetBeans 6.9.1, GlassFish 3.0.1, Mojarra 2.0.2 (FCS b10), Java 1.6.0_22 Reporter: Alexander Hanschke I have a @Named bean in which I'd like to inject a component, using @Inject as well as a stateless session bean, using @EJB. The ejb is accessed using the no-interface view. Both references get injected properly in that case, but when I use an interceptor on one of the methods, only the references annotated with @Inject get injected, whereas those annotated with @EJB don't. The interceptor doesn't need to do anything special, this behaviour occurs even if only proceed() is invoked on the invocation context - the interceptor is always invoked correctly. The following snippet explains the issue: @Named public class MyController { @EJB private SomeDao dao; @Interceptors(MyInterceptor.class) public void control() { dao.doDataAccessStuff(); /* NPE */ } } --------------------------------------------------------------- @Stateless public class MyDao { public void doDataAccessStuff() { ... } } --------------------------------------------------------------- public class MyInterceptor { @AroundInvoke public Object intercept(InvocationContext context) throws Exception { return context.proceed(); } } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (WELD-810) WeldValueExpression must override methods isReadOnly and isLiteralText.

by Rogerio Baldini (JIRA)

WeldValueExpression must override methods isReadOnly and isLiteralText. ----------------------------------------------------------------------- Key: WELD-810 URL: https://issues.jboss.org/browse/WELD-810 Project: Weld Issue Type: Bug Components: CDI API Affects Versions: 1.1.0.CR3 Reporter: Rogerio Baldini Priority: Critical WeldValueExpression must override other methods of ancestor ForwardingValueExpression to push a new CreationalContextCallable() in ELCreationalContextStack. If it wasn´t done, it will throw IllegalStateException("No CreationalContext registered for EL evaluation, it is likely that the the expression factory has not been wrapped by the CDI BeanManager, which must be done to use the ELResolver from CDI"). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
7
0 / 0

[JBoss JIRA] Created: (WELDX-86) Need Servlet 3.0 API in POMs

by Steven Boscarine (JIRA)

Need Servlet 3.0 API in POMs ---------------------------- Key: WELDX-86 URL: https://jira.jboss.org/jira/browse/WELDX-86 Project: Weld Extensions Issue Type: Bug Components: Weld Extensions Affects Versions: Archetypes 1.0.0.Beta1 Reporter: Steven Boscarine Assignee: Steven Boscarine Forgot to add the Servlet 3.0 API. It was held off on because JBoss 6 M1 was still using 2.5, however, the archetypes have no servlet API of any sort. I'm fixing right away. -- 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, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (WELDRAD-22) Create an archetype for using Weld in EAP 5.1

by Shane Bryzak (JIRA)

Create an archetype for using Weld in EAP 5.1 --------------------------------------------- Key: WELDRAD-22 URL: https://jira.jboss.org/browse/WELDRAD-22 Project: Weld Archetypes Issue Type: Feature Request Reporter: Shane Bryzak We need an archetype for Weld-based projects running in EAP 5.1. -- 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, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (WELDRAD-21) Upgrade to JPA and use static metamodel generator for typesafe queries

by Nicklas Karlsson (JIRA)

Upgrade to JPA and use static metamodel generator for typesafe queries ---------------------------------------------------------------------- Key: WELDRAD-21 URL: https://jira.jboss.org/browse/WELDRAD-21 Project: Weld Archetypes Issue Type: Feature Request Reporter: Nicklas Karlsson If I'm not mistaken the full-EE archetype speaks of JPA 2 but the deps seem to point to JPA 1. Also, it would be nice to have the hibernate static metamodel generator plugged in and a simple typesafe query example for JPA 2 -- 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, 3 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