January 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-347) META-INF/beans.xml not sufficient to activate CDI in WAR

by Dan Allen (JIRA)

META-INF/beans.xml not sufficient to activate CDI in WAR -------------------------------------------------------- Key: WELD-347 URL: https://jira.jboss.org/jira/browse/WELD-347 Project: Weld Issue Type: Bug Components: GlassFish Integration Affects Versions: 1.0.0.GA Reporter: Dan Allen Assignee: Dan Allen Fix For: 1.0.1.CR1 In GlassFish V3, if a WAR is deployed containing WEB-INF/classes/META-INF/beans.xml, CDI does not get activated (no beans are detected). Activation only happens if the WAR contains WEB-INF/beans.xml. I'm not sure why GlassFish V3 is having a problem finding beans.xml in the META-INF directory of the WAR classpath. I can't tell if it is a problem in Weld or a problem in GlassFish V3 somewhere. -- 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

12 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (WELD-407) Provide warnings if AnnotatedType is not sensible

by Pete Muir (JIRA)

Provide warnings if AnnotatedType is not sensible ------------------------------------------------- Key: WELD-407 URL: https://jira.jboss.org/jira/browse/WELD-407 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Reporter: Pete Muir Priority: Minor Fix For: 1.0.2.CR1 For example, if there are no constructors specified at all, or if the javaMember doesn't belong to the actual class hierarchy of the annotatedType -- 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

12 years, 9 months

3
7
0 / 0

[JBoss JIRA] Created: (WELD-388) Fluent messages

by Nicklas Karlsson (JIRA)

Fluent messages --------------- Key: WELD-388 URL: https://jira.jboss.org/jira/browse/WELD-388 Project: Weld Issue Type: Feature Request Affects Versions: 1.0.0.GA Reporter: Nicklas Karlsson Priority: Minor Make error messages read more fluent instead of the "Message : detail" format sometimes seen -- 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

12 years, 9 months

3
8
0 / 0

[JBoss JIRA] Created: (WELD-376) Callouts poorly formatted in HTML docs

by Pete Muir (JIRA)

Callouts poorly formatted in HTML docs -------------------------------------- Key: WELD-376 URL: https://jira.jboss.org/jira/browse/WELD-376 Project: Weld Issue Type: Task Components: Documentation Affects Versions: 1.0.0.GA Reporter: Jozef Hartinger Fix For: 1.0.1.CR1 Global problems - a significant number of links is missing the value of href attribute (these links point nowhere) - JBoss AS 5.2.x have become obsolete recently (changed to 6.0.0.M1) - the documentation references this obsolete version. i.e. Chapters 6, section 18.1 - there is a number of unnecessary blank pages in the PDF version - Section 2.1.2. Scope - there is a missing *want* in the Note in the sentence: "If you don't the bean to live in the session indefinitely..." - Section 6.2 Deploying to JBoss AS - there is a missing space in the sentence "Create a new file namedlocal.build.properties ..." - Section 6.2 Deploying to JBoss AS - is not finished - there is a TODO at the very end of the section - Secion 7.1. The numberguess example in depth - the numbers which mark an important line of a code sample (1), (2), etc... are broken in the second sample of the section (web.xml). They are placed on wrong places (wrong line, beggining of the line instead of end) and they are followed by "ml_plain">" in the HTML version. Besides, I would emphasize more the benefit of the typesafe resolution i.e. in section 1.2 - (that all the unsatisfied and ambiguous dependencies are discovered at the deployment time - you do not need to click anything to find out that the you set some dependencies wrong - more formal verification) - I don't say it is not there already. I just had a feeling that it is not stated explicitly enough. -- 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

12 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (WELDX-34) Split out user API for SE module, and move to the api project/BOM

by Pete Muir (JIRA)

Split out user API for SE module, and move to the api project/BOM ----------------------------------------------------------------- Key: WELDX-34 URL: https://jira.jboss.org/jira/browse/WELDX-34 Project: Weld Extensions Issue Type: Feature Request Components: Java SE Reporter: Pete Muir We maintain a separate API project (SVN trunk etc.), BOM etc. Any developer-visible API for the SE extension (so perhaps any non-spec events you can observe?) should go here -- 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

12 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (WELDX-51) Create a single jar file for Weld SE that includes all dependencies

by Pete Muir (JIRA)

Create a single jar file for Weld SE that includes all dependencies ------------------------------------------------------------------- Key: WELDX-51 URL: https://jira.jboss.org/jira/browse/WELDX-51 Project: Weld Extensions Issue Type: Feature Request Components: Java SE Reporter: Pete Muir Fix For: Java SE 1.0.0.CR3 To make using Weld SE easy, we should create a single jar (primarily for use at runtime, at compile time you would depend just on cdi-api of course) * cdi-api * weld-api * weld-spi * weld-core * weld-se -- 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

12 years, 9 months

5
14
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: (WELDX-65) JEE Archetypes need to support JBoss AS 6.0 when it is released.

by Steven Boscarine (JIRA)

JEE Archetypes need to support JBoss AS 6.0 when it is released. ---------------------------------------------------------------- Key: WELDX-65 URL: https://jira.jboss.org/jira/browse/WELDX-65 Project: Weld Extensions Issue Type: Feature Request Reporter: Steven Boscarine Whenever a new milestone or the final version of JBoss AS 6.0 is released, we need to confirm that our archetypes work with it. -- 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, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (WELDX-66) Update web.xml to servlet 3.0

by Steven Boscarine (JIRA)

Update web.xml to servlet 3.0 ----------------------------- Key: WELDX-66 URL: https://jira.jboss.org/jira/browse/WELDX-66 Project: Weld Extensions Issue Type: Sub-task Components: Archetypes Affects Versions: Archetypes 1.0.0-BETA1 Reporter: Steven Boscarine Assignee: Steven Boscarine JBoss AS 6.0.M1 only supported Servlet 2.5. We need to update the web.xml to support Servlet 3.0 in the JEE archetypes. -- 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, 2 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues January 2010