[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, 8 months
[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, 8 months
[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, 8 months
[JBoss JIRA] Created: (WELD-839) weld-servlet
by Ara Minosian (JIRA)
weld-servlet
------------
Key: WELD-839
URL: https://issues.jboss.org/browse/WELD-839
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.1.0.Final
Environment: Windows 7 64, GAE, java version "1.6.0_23" 64, JSF 2.0.3
Reporter: Ara Minosian
Weld-servlet 1.0.1. works fine. I try to find common issue without success. I investigated examples but saw only JSF 1.2 support. I post to forum without any answer, so decided that problem exists.
25.01.2011 21:58:20 com.google.apphosting.utils.jetty.JettyLogger info
INFO: Logging to JettyLogger(null) via com.google.apphosting.utils.jetty.JettyLogger
25.01.2011 21:58:20 com.google.apphosting.utils.config.AppEngineWebXmlReader readAppEngineWebXml
INFO: Successfully processed G:\ideaworkspace\ideal\agost\target\agost-1.0\WEB-INF/appengine-web.xml
25.01.2011 21:58:20 com.google.apphosting.utils.config.AbstractConfigXmlReader readConfigXml
INFO: Successfully processed G:\ideaworkspace\ideal\agost\target\agost-1.0\WEB-INF/web.xml
25.01.2011 21:58:20 com.google.apphosting.utils.jetty.JettyLogger info
INFO: jetty-6.1.x
25.01.2011 21:58:22 org.jboss.weld.bootstrap.WeldBootstrap <clinit>
INFO: WELD-000900 1.1.0 (Final)
25.01.2011 21:58:22 org.jboss.weld.environment.servlet.Listener contextInitialized
WARNING: @Resource injection not available in simple beans
25.01.2011 21:58:22 org.jboss.weld.bootstrap.WeldBootstrap startContainer
INFO: WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
25.01.2011 21:58:23 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: failed com.google.apphosting.utils.jetty.DevAppEngineWebAppContext@2d189c{/,G:\ideaworkspace\ideal\agost\target\agost-1.0}: java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationContextFacade
25.01.2011 21:58:23 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: failed JettyContainerService$ApiProxyHandler@1bfa3d3: java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationContextFacade
25.01.2011 21:58:23 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: Error starting handlers
java.lang.NoClassDefFoundError: org/apache/catalina/core/ApplicationContextFacade
at org.jboss.weld.environment.tomcat.WeldForwardingAnnotationProcessor.getStandardContext(WeldForwardingAnnotationProcessor.java:92)
at org.jboss.weld.environment.tomcat.WeldForwardingAnnotationProcessor.replaceAnnotationProcessor(WeldForwardingAnnotationProcessor.java:69)
at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:192)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at com.google.appengine.tools.development.JettyContainerService.startContainer(JettyContainerService.java:185)
at com.google.appengine.tools.development.AbstractContainerService.startup(AbstractContainerService.java:149)
at com.google.appengine.tools.development.DevAppServerImpl.start(DevAppServerImpl.java:219)
at com.google.appengine.tools.development.DevAppServerMain$StartAction.apply(DevAppServerMain.java:164)
at com.google.appengine.tools.util.Parser$ParseResult.applyArgs(Parser.java:48)
at com.google.appengine.tools.development.DevAppServerMain.<init>(DevAppServerMain.java:113)
at com.google.appengine.tools.development.DevAppServerMain.main(DevAppServerMain.java:89)
Caused by: java.lang.ClassNotFoundException: org.apache.catalina.core.ApplicationContextFacade
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at com.google.appengine.tools.development.IsolatedAppClassLoader.loadClass(IsolatedAppClassLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 21 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[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, 8 months
[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, 8 months
[JBoss JIRA] Created: (WELD-826) A documentation for Weld doesn't display callouts properly (in html version)
by Martin Gencur (JIRA)
A documentation for Weld doesn't display callouts properly (in html version)
----------------------------------------------------------------------------
Key: WELD-826
URL: https://issues.jboss.org/browse/WELD-826
Project: Weld
Issue Type: Bug
Components: Documentation
Affects Versions: 1.1.0.Final
Reporter: Martin Gencur
The html page cannot load images for Callouts - both in source code snippets and then in the legend for it.
Example: search for "Field injection of TextTranslator instance" in the documentation, the image next to it is the following:
<img xmlns="" xmlns:rf="java:org.jboss.highlight.XhtmlRendererFactory" src="file:/Users/pmuir/workspace/weld/core/target/checkout/docs/reference/target/docbook/staging/images/images/seamframework/docbook/callouts/1.png" alt="1" border="0" height="17px" width="17px"/>
which cannot function, of course :)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months