[JBoss JIRA] Commented: (CDI-26) Embedded Mode
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-26?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-26:
------------------------------
>From Rick Hightower:
There should be a standard, minimalistic way to bootstrap a CDI container outside of Java EE. This is useful for unit testing extensions, and for other JSRs that need to do annotation processing, injection and interception. Instead of those other JSRs defining their own mechanism for annotation processing, injection and interception they can just use CDI.
Also Java EE has clients (for JMS, RMI, Services). The same features on the serverside (injection, interceptions, proxying) are equally useful on the client side.
There should also be some clear walls between what is included in Java SE CDI and Java EE CDI. Java SE CDI being a subset and core of Java EE CDI. This modularity should be better defined in the specification.
> Embedded Mode
> -------------
>
> Key: CDI-26
> URL: https://issues.jboss.org/browse/CDI-26
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> Weld and other CDI impls allow an embedded mode.
> See http://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#... for example
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] Created: (CDI-122) Create a standard way to bootstrap a CDI container outside of a Java EE environment for unit testing and other JSRs that need CDI features
by Richard Hightower (JIRA)
Create a standard way to bootstrap a CDI container outside of a Java EE environment for unit testing and other JSRs that need CDI features
------------------------------------------------------------------------------------------------------------------------------------------
Key: CDI-122
URL: https://issues.jboss.org/browse/CDI-122
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Packaging and Deployment
Affects Versions: 1.1 (Proposed)
Environment: Java SE
Reporter: Richard Hightower
Fix For: 1.1 (Proposed)
There should be a standard, minimalistic way to bootstrap a CDI container outside of Java EE. This is useful for unit testing extensions, and for other JSRs that need to do annotation processing, injection and interception. Instead of those other JSRs defining their own mechanism for annotation processing, injection and interception they can just use CDI.
Also Java EE has clients (for JMS, RMI, Services). The same features on the serverside (injection, interceptions, proxying) are equally useful on the client side.
There should also be some clear walls between what is included in Java SE CDI and Java EE CDI. Java SE CDI being a subset and core of Java EE CDI. This modularity should be better defined in the specification.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] Commented: (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-18:
------------------------------
Can you be more specifc Rick as to what elements you are thinking of?
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] Issue Comment Edited: (CDI-30) An API for managing built in contexts
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ]
Pete Muir edited comment on CDI-30 at 5/1/11 1:17 PM:
------------------------------------------------------
Weld used 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:
{code}
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();
}
{code}
Subsequently we replaced this with a set of general purpose APIs for managing all built in contexts including conversations.
was (Author: petemuir):
Weld used 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();
}
Subsequently we replaced this with a set of general purpose APIs for managing all built in contexts including conversations.
> An API for managing built in contexts
> -------------------------------------
>
> Key: CDI-30
> URL: https://issues.jboss.org/browse/CDI-30
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Nicklas Karlsson
> Fix For: 1.1 (Proposed)
>
>
> Add management API for built in contexts allowing them to be reused as needed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] Commented: (CDI-9) Interceptors are not applied to custom bean types
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-9?page=com.atlassian.jira.plugin.syst... ]
Pete Muir commented on CDI-9:
-----------------------------
No, this isn't clear in the spec. As Marius says "any managed bean that is not itself an interceptor or decorator..." - Bean's which are added via addBean aren't defined as managed beans - from 2.1 "A managed bean is a bean that is implemented by a Java class. " whilst a bean added via addBean is implemented any way the user desires.
> Interceptors are not applied to custom bean types
> -------------------------------------------------
>
> Key: CDI-9
> URL: https://issues.jboss.org/browse/CDI-9
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Interceptors, Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: TBD
>
>
> Beans added through the SPI do not have interceptors applied.
> Even though bean does not have a getInterceptorBindings() method, interceptors applied to stereotypes should still work.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] Commented: (CDI-8) Decorators are not applied to custom beans
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-8?page=com.atlassian.jira.plugin.syst... ]
Pete Muir commented on CDI-8:
-----------------------------
No, this isn't clear in the spec. As Marius says "any *managed* bean that is not itself an interceptor or decorator..." - Bean's which are added via addBean aren't defined as *managed* beans - from 2.1 "A managed bean is a bean that is implemented by a Java class. " whilst a bean added via addBean is implemented any way the user desires. If we removed the word managed from the sentence then it would be as Mark says.
> Decorators are not applied to custom beans
> ------------------------------------------
>
> Key: CDI-8
> URL: https://issues.jboss.org/browse/CDI-8
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Decorators, Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: TBD
>
>
> Beans added with AfterBeanDiscovery.addBean() do not have decorators applied
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Dan Allen (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Dan Allen commented on CDI-4:
-----------------------------
I don't really think it's counter intuitive. A special circumstance, sure. But not counter intuitive. In a stateful system, there are times when one observer is going to need to affect the state of the system in such a way that it needs to come before other observers of the same event. We have this in Servlet, we have this in JSF and I think we need to have it in CDI too.
One concrete use case is an observer that responds to the Servlet Initialized Event (assuming we had such an integration) to prepare the request and initialize other context variables so that all other observers of the same event can use these prepared resources. The inverse is needed on destroy.
> Need a way to provide ordering for Event observers (@Observes)
> --------------------------------------------------------------
>
> Key: CDI-4
> URL: https://issues.jboss.org/browse/CDI-4
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.0
> Environment: All
> Reporter: Lincoln Baxter III
> Fix For: TBD
>
>
> There needs to be a way to specify some kind of ordering for Event observers.
> Understandably, this is somewhat counter-intuitive to the general concept of observing an event, but there is going to be need for this in an upcoming JBoss project. While it can be done manually, it might be nice to have a built-in API.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] Closed: (CDI-10) Add ability to access a bean instance from a proxy
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-10?page=com.atlassian.jira.plugin.sys... ]
Pete Muir closed CDI-10.
------------------------
Fix Version/s: (was: TBD)
Resolution: Won't Fix
As Mark says there is a workaround, and Stuart also doesn't see a need for this anymore... Closing therefore.
> Add ability to access a bean instance from a proxy
> --------------------------------------------------
>
> Key: CDI-10
> URL: https://issues.jboss.org/browse/CDI-10
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Stuart Douglas
>
> There are occasions when it would be useful to access a bean instance directly from a proxy. This could be achieved by making all proxies assignable to an interface (say BeanProxy) that provides a getBeanInstance() method.
> Client code that needs access to the actual instance can check if the object is assignable to the BeanProxy interface and then call getBeanInstance() to get the actual instance if required.
> This is something that is probably more useful to extension writers than the end user, but there have already been a few requests on the weld forum about this so it is probably worth considering.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months