[JBoss JIRA] Created: (CDI-113) Add some design time readable metadata for built-in beans of CDI-implementations.
by Alexey Kazakov (JIRA)
Add some design time readable metadata for built-in beans of CDI-implementations.
---------------------------------------------------------------------------------
Key: CDI-113
URL: https://issues.jboss.org/browse/CDI-113
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Alexey Kazakov
We need such metadata for tooling.
It would be very helpful to have some metadata for beans which implement spec required services (BeanManager, ...)
Or for any other beans which CDI implementations register programmatically and which should be available for users.
For example Weld loads some beans from jars which don't have beans.xml but some of those beans are available for injections.
So far we don't have any documented way to recognize such beans.
--
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: (CDI-104) Support automatic dependency injection for non-managed objects
by Dan Allen (JIRA)
Support automatic dependency injection for non-managed objects
--------------------------------------------------------------
Key: CDI-104
URL: https://issues.jboss.org/browse/CDI-104
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Beans
Affects Versions: 1.0
Reporter: Dan Allen
Allow objects created using the "new" keyword (or created by some other means) to be injected automatically.
Conceptually it would look something like this:
@AutoInject
public class AccountService {
private final Account account;
@Inject
private PaymentProcessor paymentProcessor;
AccountService(Account account) {
this.account = account;
}
public void doPayment(double amount) {
paymentProcessor.processPayment(account, amount);
}
}
We could then create the object using new and the fields will still be injected:
AccountService a = new AccountService(account);
a.doPayment(10);
The inverse design would also be an option. An instance of Account could be retrieved from JPA and the AccountService would be injected into it during construction.
To implement this feature may require a javaagent, which will modify the bytecode of @AutoInject annotated classes as they are loaded, so that the constructor bytecode looks up the values to inject and sets the injected field values appropriately. (There are other options suggested in the linked thread).
The primary use case for this feature is to support rich domain models, though the usefulness of this feature extends beyond this case, so I don't think the feature should be dismissed if you don't agree with the rich domain models design.
The feature also brings the "new" keyword back into the picture of modern programming. You can still create objects in the classic way, but benefit from modern programming model patterns (specifically CDI).
Spring has a similar feature in it's AOP package: http://static.springsource.org/spring/docs/3.0.x/spring-framework-referen...
--
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] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-33:
------------------------------
bq. 1) Spec intent. Read in the context of the specification it is apparent that the ProcessAnnotatedType event is intended, as its name implies, to process all annotated types exposed to the container. No method on the event indicates that it is meant only for beans declared specifically in a bean archive but instead the methods act on the generic AnnotatedType interface. Additionally, while the spec says the container must fire the event for each bean discovered in the archive it does explicitly state that this is the only scenario the event may be fired in(if and only if). Even the Weld reference implementation made this intuitive assumption in Weld issue 486
Unfortunately, whilst I wish the spec read the other way, the consensus is that it reads the way Weld 1.1 is implemented. To quote the spec (as you mention above):
bq. The container must fire an event for each Java class or interface it discovers in a bean archive, before it reads the declared annotations.
bq. For each Java class or interface deployed in a bean archive, the container must: • create an AnnotatedType representing the type and fire an event of type ProcessAnnotatedType,
With this in mind, reading the spec the only time the container must fire an event is when a class is deployed in a bean archive, it makes no mention of beans added in other ways. Assuming you have a typo above, and mean that the spec doesn't say that this is the only time the event should be fired, agreed, however Weld as the RI needs to promote portability, and making this event available outside of the spec required places would promote non-portability.
Agreed that the intent may have been the other way, but that did not get written down and we are stuck with what we have.
bq. 2) Inconsistency of the veto method. Assume that the spec did intend for the event to only be triggered for auto discovered beans. When utilizing the bean discovery mechanism assemblers must be cognizant of each class included in the archive so that the dependency injection “auto wires” properly. The value of the veto method in this situation only seems limiting since in an assembled archive all types are assumed to have been already vetted by the assembler. Also, evaluate this scenario. An extension will malfunction if a given annotated type is exposed to the container so it must invoke the veto method to signal to the container to ignore the type. If the ProcessAnnotatedType event is not triggered for types added by another extension than it is entirely possible than another extension could introduce the problematic type and cause a conflict. Not allowing extensions interact with each other’s introduced types or forbidding the introduction of an extension to mediate between conflicting extensions will introduce irreconcilable extension conflicts.
Agreed, with hindsight applied, it seems obvious that the spec should require it for both, however a spec is a spec and (especially by the RI) must be followed as written, and not as we guess the writers intended. So, unless there is a logical inconsistency between two paragraphs of the spec (which there are in a couple of places, in which we've gone with the stronger of the two) we need to follow the spec. There is no logical inconsistency between sections of the spec here, just between what many view as the correct way to do it, and the way the spec is written.
bq. 3) Minimal impact of firing event. Given that for all other event types there is no differentiation between container discovered types and extension added types observers of the ProcessAnnotatedType event would not be impacted at all. The only scenario where a portability issue would arise is where an extension developer intuitively assumed the event would be fired for all annotated types . Given that Weld is the CDI RI it could set the standard for how the spec should be interpreted. I can’t imagine why another implementation would not follow suite with the more liberal interpretation of when the event should be fired given the limitations above.
It is not the role of the RI to define or clarify the specification, but simply to provide a reference as to implementing the spec. I can put you in touch with folks at the JCP if you want to debate these points further, but this is how it is currently defined. I can't get around that :-(
bq. 4) Everyone is painfully familiar with the JCP process and the length of time it takes to approve a JSR and for it to be adopted. Please consider adding critical and simple clarifications like this to a JSR maintenance release rather than forcing us all to wait years for a CDI 1.1 release.
I will look into this.
> 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: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> 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, 9 months
[JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Dan Allen (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Dan Allen commented on CDI-33:
------------------------------
Reading Aaron's comment, I wonder if perhaps the right solution is adding a source property to the event. That way, if another extension adds a type, the observers can detect it was added by an extension and even get the extension instance. We would then need an interface to identify the scanner, or make the source the BeanManager in that case.
{code:java}
if (event.getSource() instanceof Extension) {
// we know this type was introduced by an extension
} else {
// picked up by the scanner
}
{code}
> 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: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> 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, 9 months
[JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Aaron Anderson (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Aaron Anderson commented on CDI-33:
-----------------------------------
Please consider the following:
1) Spec intent. Read in the context of the specification it is apparent that the ProcessAnnotatedType event is intended, as its name implies, to process all annotated types exposed to the container. No method on the event indicates that it is meant only for beans declared specifically in a bean archive but instead the methods act on the generic AnnotatedType interface. Additionally, while the spec says the container must fire the event for each bean discovered in the archive it does explicitly state that this is the only scenario the event may be fired in(if and only if). Even the Weld reference implementation made this intuitive assumption in Weld issue 486
2) Inconsistency of the veto method. Assume that the spec did intend for the event to only be triggered for auto discovered beans. When utilizing the bean discovery mechanism assemblers must be cognizant of each class included in the archive so that the dependency injection “auto wires” properly. The value of the veto method in this situation only seems limiting since in an assembled archive all types are assumed to have been already vetted by the assembler. Also, evaluate this scenario. An extension will malfunction if a given annotated type is exposed to the container so it must invoke the veto method to signal to the container to ignore the type. If the ProcessAnnotatedType event is not triggered for types added by another extension than it is entirely possible than another extension could introduce the problematic type and cause a conflict. Not allowing extensions interact with each other’s introduced types or forbidding the introduction of an extension to mediate between conflicting extensions will introduce irreconcilable extension conflicts.
3) Minimal impact of firing event. Given that for all other event types there is no differentiation between container discovered types and extension added types observers of the ProcessAnnotatedType event would not be impacted at all. The only scenario where a portability issue would arise is where an extension developer intuitively assumed the event would be fired for all annotated types . Given that Weld is the CDI RI it could set the standard for how the spec should be interpreted. I can’t imagine why another implementation would not follow suite with the more liberal interpretation of when the event should be fired given the limitations above.
4) Everyone is painfully familiar with the JCP process and the length of time it takes to approve a JSR and for it to be adopted. Please consider adding critical and simple clarifications like this to a JSR maintenance release rather than forcing us all to wait years for a CDI 1.1 release.
> 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: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> 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, 9 months
[JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-33:
------------------------------
Yes, unfortunately in Weld 1.0 we did fire PAT for extension added annotated types, which is a clear violation of the 1.0 spec. In CDI 1.1 we intend to address this issue and have an event fired for extension added types.
> 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: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> 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, 9 months
[JBoss JIRA] Commented: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Aaron Anderson (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Aaron Anderson commented on CDI-33:
-----------------------------------
In my opinion, treating container discovered annotated types differently than extension added types completely breaks the intended type abstraction of the CDI extension framework. The CDI extensions I am developing uses the ProcessAnnotatedType event to convert custom annotations to CDI respected ones. I disable bean discovery and instead manually add types on the BeforeBeanDiscovery event for greater control. After upgrading to Weld 1.1 final from RC2 my extensions are completely broken and I have no way to fix them. A CDI developer cannot simply fire a ProcessAnnotatedType event of their own since the event contains a veto method which can only be honored by the container. Plus firing this event manually places unnecessary complexity on the developer as this should be handled by the container.
> 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: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: 1.1 (Proposed)
>
>
> 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, 9 months
Re: [cdi-dev] calling 'equals' on a proxy?
by Adam Bien
There is a very good chapter about @Stateful and EJB:
Stateful Session Beans
A stateful session object has a unique identity that is assigned by the container at the time the object is created. A client of the stateful session bean business interface can determine if two business interface or no-interface view references refer to the same session object by use of the equals method.
For example,
@EJB Cart cart1; @EJB Cart cart2; ... if (cart1.equals(cart1)) { // this test must return true
...
} ... if (cart1.equals(cart2)) { // this test must return false
}
...
All stateful session bean references to the same business interface for the same stateful session bean instance will be equal. All references to the no-interface view of the same stateful session bean instance will be equal. Stateful session bean references to different interface types or between an interface type and a no-interface view or to different session bean instances will not have the same identity.
Page 53,
thanks,
adam
On 17.03.2011, at 01:13, Mark Struberg wrote:
> Stateless session beans are always special (because they *tataaa* contain no state). Since CDI beans almost always contain some state info, the 'else' part of the paragraph -> return false; will always be taken.
>
> But always returning false for all CDI beans also doesn't sound quite right to me...
>
> There is no special paragraph about equals on Stateful session beans or EMPs in the EJB spec, isn't?
>
>
> LieGrue,
> strub
>
> --- On Wed, 3/16/11, Adam Bien <abien(a)adam-bien.com> wrote:
>
> From: Adam Bien <abien(a)adam-bien.com>
> Subject: Re: [cdi-dev] calling 'equals' on a proxy?
> To: "Peter Muir" <pmuir(a)redhat.com>
> Cc: "Mark Struberg" <struberg(a)yahoo.de>
> Date: Wednesday, March 16, 2011, 11:51 PM
>
> @Mark -> please file the issue.
> On 17.03.2011, at 00:02, Peter Muir wrote:
> Adam or mark, can you file a CDI issue to track this?
>
> --Pete Muirhttp://in.relation.to/Bloggers/Pete
> On 16 Mar 2011, at 19:06, Adam Bien <abien(a)adam-bien.com> wrote:
>
> Equals behavior is similarly specificied in the EJB 3.1 spec. Probably we could borrow something:
> "The equals method always returns true when used to compare references to the same business inter- face type of the same stateless session bean. The equals method always returns true when used to com- pare references to the no-interface view of the same stateless session bean. Stateless session bean references to either different business interface types or between an interface type and a no-interface view or to different session beans will not be equal." EJB 3.1, Page 54
> greetings!,
> adam
> On 14.03.2011, at 12:52, Pete Muir wrote:
> Stuart, you had this one worked out right? I believe the spec says the behaviour is unspecified.
>
> On 7 Mar 2011, at 15:52, Mark Struberg wrote:
>
> Hi Pete, others!
>
> Do you remember our discussion about what should happen if equals() gets called on a proxy?
>
> Should it route to the equals method of the currently proxied instance?
>
> LieGrue,
> strub
>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> Consultant, Author, Speaker, Java Champion Weblog: blog.adam-bien.com press: press.adam-bien.com eMail: abien(a)adam-bien.com twitter: twitter.com/adambien Mobile: 0049(0)170 280 3144
> Author: 7 (Java SE/EE, SOA) Books, about 100 articles
>
>
>
>
>
>
>
>
>
>
>
> Consultant, Author, Speaker, Java Champion Weblog: blog.adam-bien.com press: press.adam-bien.com eMail: abien(a)adam-bien.com twitter: twitter.com/adambien Mobile: 0049(0)170 280 3144
> Author: 7 (Java SE/EE, SOA) Books, about 100 articles
>
>
>
>
>
>
>
>
>
>
>
>
>
Consultant, Author, Speaker, Java Champion
Weblog: blog.adam-bien.com
press: press.adam-bien.com
eMail: abien(a)adam-bien.com
twitter: twitter.com/adambien
Mobile: 0049(0)170 280 3144
Author: 7 (Java SE/EE, SOA) Books, about 100 articles
13 years, 9 months
CDI 1.1 JSR draft
by Pete Muir
All,
I've attached the CDI 1.1 JSR proposal from Red Hat. I appreciate any comments, questions or suggestions for amendment you may have. Please send feedback to me or to cdi-dev(a)lists.jboss.org.
Please let me know if you would like to support the JSR, and if you would like to be on the EG, or can recommend someone who should.
I don't have access to the 299 EG list, but if someone else does and can forward to it, that would be much appreciated. Jason or Roberto, could you send this to the jsr-316 list for review, would be much appreciated.
Regards,
Pete
13 years, 10 months
