January 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Stuart Douglas (JIRA)

Allow Extensions to specify the annotations that they are interested in ----------------------------------------------------------------------- Key: CDI-43 URL: https://issues.jboss.org/browse/CDI-43 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Stuart Douglas Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-38) Send servlet events as CDI events

by Pete Muir (JIRA)

Send servlet events as CDI events --------------------------------- Key: CDI-38 URL: https://issues.jboss.org/browse/CDI-38 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir Seam Servlet provide these as well -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (CDI-39) Add a standard format for defining metadata about extensions

by Pete Muir (JIRA)

Add a standard format for defining metadata about extensions ------------------------------------------------------------ Key: CDI-39 URL: https://issues.jboss.org/browse/CDI-39 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir e.g. add optional name, description and version fields to an optional annotation. Makes it easy for modules to track what is being loaded -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (WELD-830) Stateless scope

by Adam Warski (JIRA)

Stateless scope --------------- Key: WELD-830 URL: https://issues.jboss.org/browse/WELD-830 Project: Weld Issue Type: Feature Request Components: Scopes & Contexts Reporter: Adam Warski >From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): Here's my use-case: I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either (a) be normal-scoped (proxyable) (b) implement Serializable and leave the bean dependent-scoped If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (CDI-36) ObserverMethod.notify() does not forward qualifiers for Event

by Jordan Ganoff (JIRA)

ObserverMethod.notify() does not forward qualifiers for Event ------------------------------------------------------------- Key: CDI-36 URL: https://issues.jboss.org/browse/CDI-36 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Jordan Ganoff There's currently no way to get the qualifiers for a fired event. ObserverMethod.notify() only passes the event object itself. Without the qualifiers it is difficult to bridge the gap between CDI events and some other event infrastructure (e.g. JMS). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()

by Jozef Hartinger (JIRA)

fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType() ----------------------------------------------------------------------------- Key: CDI-33 URL: https://issues.jboss.org/browse/CDI-33 Project: CDI Specification Issues Issue Type: Task Reporter: Jozef Hartinger Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired. However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (CDI-35) add support for 'optional' beans

by Mark Struberg (JIRA)

add support for 'optional' beans -------------------------------- Key: CDI-35 URL: https://issues.jboss.org/browse/CDI-35 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Mark Struberg sometimes it's neat to mark a bean as @Optional depending if a specified class can get loaded or not. This is a simple way to implement deployment specific functionality. An example would be a BvalSupportBean which only should become active if the JSR-303 bean validation API can be found on the classpath. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (CDI-30) An API for conversation management

by Nicklas Karlsson (JIRA)

An API for conversation management ---------------------------------- Key: CDI-30 URL: https://issues.jboss.org/browse/CDI-30 Project: CDI Specification Issues Issue Type: Feature Request Components: Specification Affects Versions: 1.0 Reporter: Nicklas Karlsson I think it would be useful to have a ConversationManager API for CDI that would allow for portable modules that use the conversation context. Weld has been using the following interface, which has also been approved by Mark Struberg representing OpenWebBeans and by Reza Rahman representing CanDI and I hope it can be used for the basis of discussions on this topic: public interface ConversationManager { /** * Checks the state of the conversation context * * @return true if the conversation context is active, false otherwise */ public abstract boolean isContextActive(); /** * Sets up and activates the conversation context * * @return The conversation manager * * @throws IllegalStateException if the context is already active */ public abstract ConversationManager setupContext(); /** * Destroys the conversations and deactivates the conversation context * * @return The conversation manager * * @throws IllegalStateException if the context is already deactive */ public abstract ConversationManager teardownContext(); /** * Resumes a long running conversation. If the cid is null, nothing is done and the current * transient conversation is resumed * * * @param cid The conversation id to restore * @return The conversation manager * @throws NonexistentConversationException If the non-transient conversation is not known * @throws BusyConversationException If the conversation is locked and not released while waiting * @throws IllegalStateException if the conversation context is not active */ public abstract ConversationManager setupConversation(String cid); /** * Destroys the current conversation if it's transient. Stores it for conversation * propagation if it's non-transient * * @return The conversation manager * @throws IllegalStateException if the conversation context is not active */ public abstract ConversationManager teardownConversation(); /** * Gets the current non-transient conversations * * @return The conversations, mapped by id * @throws IllegalStateException if the conversation context is not active */ public abstract Map<String, Conversation> getConversations(); /** * Returns a new, session-unique conversation ID * * @return The conversation id * @throws IllegalStateException if the conversation context is not active */ public abstract String generateConversationId(); } -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (CDI-32) A method of controlling event ordering

by Nicklas Karlsson (JIRA)

A method of controlling event ordering -------------------------------------- Key: CDI-32 URL: https://issues.jboss.org/browse/CDI-32 Project: CDI Specification Issues Issue Type: Feature Request Components: Specification Affects Versions: 1.0 Reporter: Nicklas Karlsson It would be handy to have a way of controlling the order in which synchronous events are being called -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (CDI-31) Asynchronous events

by Nicklas Karlsson (JIRA)

Asynchronous events ------------------- Key: CDI-31 URL: https://issues.jboss.org/browse/CDI-31 Project: CDI Specification Issues Issue Type: Feature Request Components: Specification Affects Versions: 1.0 Reporter: Nicklas Karlsson Consider including asynchronous events as their were specified in one of the previous drafts. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues January 2011