October 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-724) Failure to load beans.xml from multiple locations

by Clint Popetz (JIRA)

Failure to load beans.xml from multiple locations ------------------------------------------------- Key: WELD-724 URL: https://jira.jboss.org/browse/WELD-724 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.Beta1 Reporter: Clint Popetz URLScanner is depending on there being only one instance of META-INF/beans.xml on the classpath when loading beans.xml from jar. I don't have a standalone example of this, because it's occurring within eclipse, but in our case when scanning at startup the scanner would see beans.xml in the weld core jar but rather than loading it, would load two copies of a META-INF/beans.xml that it found on the classpath outside of that jar. Attached is a patch that fixes this for us. -- 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

15 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (WELD-663) Remove caching of reflection info from Weld* classes when not used

by David Allen (JIRA)

Remove caching of reflection info from Weld* classes when not used ------------------------------------------------------------------ Key: WELD-663 URL: https://jira.jboss.org/browse/WELD-663 Project: Weld Issue Type: Task Components: Bootstrap and Metamodel API Affects Versions: 1.1.0.Beta1 Reporter: David Allen Assignee: David Allen Fix For: 1.1.0.Beta2 If any methods which return reflection data from the Weld* introspection classes are called only once during the execution/deployment of an application, then the caching of that data is unnecessary. -- 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

15 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (WELD-652) Remove JBoss AS update instructions from the ref guide, they no longer work consistently

by Pete Muir (JIRA)

Remove JBoss AS update instructions from the ref guide, they no longer work consistently ---------------------------------------------------------------------------------------- Key: WELD-652 URL: https://jira.jboss.org/browse/WELD-652 Project: Weld Issue Type: Task Affects Versions: 1.1.0.Beta1 Reporter: Pete Muir Priority: Minor Fix For: 1.1.0.Beta2 -- 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

15 years, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (WELD-650) Documentation issues

by Jozef Hartinger (JIRA)

Documentation issues -------------------- Key: WELD-650 URL: https://jira.jboss.org/browse/WELD-650 Project: Weld Issue Type: Bug Components: Documentation Affects Versions: 1.1.0.Beta1 Reporter: Jozef Hartinger Assignee: Pete Muir Attachments: code_samples.png readme.txt - the second paragraph says "This is feature complete release of the CDI specification." IMHO it should say "This is a feature complete implementation of the CDI specification." - the licensing section says "the Apache License, Version 2.0" it should say "ASL 2.0" or "Apache Source License 2.0" - Source code reference should be "http://github.com/weld" not "http://anonsvn.jboss.org/repos/weld" examples/readme.txt - the pastecode example is not mentioned - se/helloworld should be se/hello-world - remove wicket example reference examples/se/numberguess/readme.txt - mentions Web Beans - restricts maven to version 2 (maven 3 users should not be limited) examples/se/helloworld/readme.txt - mentions Web Beans - instructions are wrong (examples/se/hello-world should be used instead of examples/se/numberguess) - restricts maven to version 2 (maven 3 users should not be limited) Javadoc - doc/apidoc contains CDI javadoc only (no Weld-specific docs) Reference documentation - remove wicket references - entire section 7.2 - update SCM references (Chapter 17) - code sample references (numbers) not rendered correctly in the HTML version (see the attached screenshot) -- 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

15 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (WELD-261) Tidy up OSGi exports

by Pete Muir (JIRA)

Tidy up OSGi exports -------------------- Key: WELD-261 URL: https://jira.jboss.org/jira/browse/WELD-261 Project: Weld Issue Type: Task Components: OSGi support Reporter: Pete Muir Priority: Critical Fix For: 1.0.1.CR1 -- 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

15 years, 4 months

1
5
0 / 0

[JBoss JIRA] Created: (CDITCK-62) The Weld Porting Package Impls provided by the TCK should support OSGI

by Kyle Grucci (JIRA)

The Weld Porting Package Impls provided by the TCK should support OSGI ---------------------------------------------------------------------- Key: CDITCK-62 URL: https://jira.jboss.org/jira/browse/CDITCK-62 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Environment: All Reporter: Kyle Grucci Fix For: 1.0.1.CR1 The current porting package impl classes provided with the TCK work with Weld in a non-OSGI environment. It would be great in the future if the impls can also work out of the box with Weld in an OSGI environment. -- 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

15 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (WELD-206) Tests for OSGi bundle to ensure the correct bundle headers are generated

by Pete Muir (JIRA)

Tests for OSGi bundle to ensure the correct bundle headers are generated ------------------------------------------------------------------------ Key: WELD-206 URL: https://jira.jboss.org/jira/browse/WELD-206 Project: Weld Issue Type: Task Reporter: Pete Muir Assignee: Roger Kitain Priority: Critical Fix For: 1.0.0.CR2 -- 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

15 years, 4 months

1
6
0 / 0

[JBoss JIRA] Created: (WELDSERVLET-28) add beforeContextInitialized and other servlet event

by he youlin (JIRA)

add beforeContextInitialized and other servlet event ---------------------------------------------------- Key: WELDSERVLET-28 URL: https://jira.jboss.org/browse/WELDSERVLET-28 Project: Weld Servlet Issue Type: Feature Request Reporter: he youlin Sometimes i want to get ServletContextEvent weld event after weld container started and before validateBeans,so i can do some init work in weld extension.And I can wrap servletContext as a weld bean in this weld event's observe then i can use the servletContext bean in all weld extension of event's observe after container started.So we can do more init work of servlet container such as tomcat or jetty servlet inject or spring's init work. see http://seamframework.org/Community/ShouldSeamServletEventMoveToWeldservle... -- 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

15 years, 4 months

2
9
0 / 0

[JBoss JIRA] Created: (WELD-678) ServletConversationManager is not serializable because of ManagedConversation dependency

by Sivakumar Thyagarajan (JIRA)

ServletConversationManager is not serializable because of ManagedConversation dependency ---------------------------------------------------------------------------------------- Key: WELD-678 URL: https://jira.jboss.org/browse/WELD-678 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.0.Beta1 Environment: GlassFish 3.1 cluster and a CDI-enabled web application deployed with availability-enabled=true Reporter: Sivakumar Thyagarajan Deploying a CDI-enabled JSF application (with conversation scoped beans) with availability-enabled=true (to enable HTTP session replication) in latest GlassFish 3.1 cluster, and using the application results in the following error while persisting the HTTP session. On further debugging, it appears that ServletConversationManager has a reference to ManagedConversations which are non-serializable and appears to be a regression (ie introduced after WELD-214). > [#|2010-09-13T20:04:52.789+0530|INFO|glassfish3.1|org.apache.catalina.session.ManagerBase|_ThreadID=17;_ThreadName=Thread-1;|PWC2785: Cannot serialize session attribute org.jboss.weld.context.SessionContext#org.jboss.weld.bean-weld-ManagedBean-class org.jboss.weld.conversation.ServletConversationManager for session b7ed19d916e9a008293e41c15971 > java.io.NotSerializableException: org.jboss.weld.conversation.ManagedConversation > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) > at java.util.concurrent.ConcurrentHashMap.writeObject(ConcurrentHashMap.java:1247) > at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) > at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) > at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) > at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) > at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) > at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) > at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:2063) > at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) > at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) > at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) > at org.apache.catalina.session.StoreBase.writeSession(StoreBase.java:269) > at org.glassfish.web.ha.session.management.HAStoreBase.getByteArray(HAStoreBase.java:229) > at org.glassfish.web.ha.session.management.ReplicationStore.doValveSave(ReplicationStore.java:153) > at org.glassfish.web.ha.session.management.ReplicationWebEventPersistentManager.doValveSave(ReplicationWebEventPersistentManager.java:154) > at org.glassfish.web.ha.session.management.HASessionStoreValve.doPostInvoke(HASessionStoreValve.java:163) -- 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

15 years, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (WELD-497) Check for null in BeanManager.getReference()

by Jozef Hartinger (JIRA)

Check for null in BeanManager.getReference() -------------------------------------------- Key: WELD-497 URL: https://jira.jboss.org/jira/browse/WELD-497 Project: Weld Issue Type: Bug Components: Resolution (Typesafe and by Name) Affects Versions: 1.0.1.Final Reporter: Jozef Hartinger Assignee: Pete Muir Priority: Minor Fix For: 1.0.2.CR1 Weld currently throws the following exception if the "bean" parameter is null during getReference() invocation Caused by: java.lang.NullPointerException at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:810) An exception with self-explanatory message should be thrown instead. Also, check the other parameters for null values. -- 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

15 years, 4 months

3
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues October 2010