[JBoss JIRA] Commented: (CDI-4) Need a way to provide ordering for Event observers (@Observes)
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-4?page=com.atlassian.jira.plugin.syst... ]
Mark Struberg commented on CDI-4:
---------------------------------
One thing we could pretty easily do is to add a Float value representing an ordinal. But that really doesn't fit well to the general observer/observable pattern. What is your exact use case? From a quick think-through I don't see anything which cannot be done in a different way also.
> 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, 11 months
[JBoss JIRA] Commented: (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.syst... ]
Pete Muir commented on CDI-3:
-----------------------------
The proposal is to add a new event AfterAnnotatedTypeDiscovery which is between BBD and ABD and can do such a job. This isn't clear from Stuart's report I know :-)
> Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
> ------------------------------------------------------------------------------------------------------------
>
> Key: CDI-3
> URL: https://issues.jboss.org/browse/CDI-3
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 1.1 (Proposed)
>
>
> At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes.
> Some of the things that the bean interface will not let you mimic are:
> - Interceptors
> - Disposal methods
> - Producer fields for normal scoped beans
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Commented: (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.syst... ]
Mark Struberg commented on CDI-3:
---------------------------------
Not sure if this works with the lifecycle. Adding an AnnotatedType _after_ scanning the beans would most probably create kind of a chicken-egg problem. So this would require us to repeat over the bean processing over and over again until nothing changes anymore. This sounds not really sane ;)
> Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
> ------------------------------------------------------------------------------------------------------------
>
> Key: CDI-3
> URL: https://issues.jboss.org/browse/CDI-3
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 1.1 (Proposed)
>
>
> At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes.
> Some of the things that the bean interface will not let you mimic are:
> - Interceptors
> - Disposal methods
> - Producer fields for normal scoped beans
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[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
12 years, 11 months
CDI-110
by George Gastaldi
I was just browsing the issues, and found out one issue on the TBD
list that really shouldn´t be left out on CDI 1.1.
"Provide support for binding an invocation handler to an interface or
abstract class" - https://issues.jboss.org/browse/CDI-110
In fact, it is the ServiceHandler feature implemented in Seam Solder.
There is a use case that is the same as listed on
http://docs.jboss.org/seam/3/solder/latest/reference/en-US/html/serviceha...
that makes it necessary and could be better adopted on other use cases
as well.
I may also be responsible on implementing this.
What do you guys think ?
Regards,
George
12 years, 11 months
Fw: Re: CDI 1.1
by Mark Struberg
btw, can the mailing daemon be configured to automatically contain the list as mail-to? :)
LieGrue,
strub
--- On Wed, 4/27/11, Mark Struberg <struberg(a)yahoo.de> wrote:
> From: Mark Struberg <struberg(a)yahoo.de>
> Subject: Re: [cdi-dev] CDI 1.1
> To: "Peter Muir" <pmuir(a)redhat.com>
> Date: Wednesday, April 27, 2011, 12:06 PM
> is fine with me.
>
> I just found it a good idea to encourage people to use the
> voting feature of jira. People are not using it often since
> it is most times ignored. If the votes actually have a real
> impact, then people will use it more often - which would in
> turn provide a good feedback for the EG.
>
> LieGrue,
> strub
>
> --- On Wed, 4/27/11, Peter Muir <pmuir(a)redhat.com>
> wrote:
>
> > From: Peter Muir <pmuir(a)redhat.com>
> > Subject: Re: [cdi-dev] CDI 1.1
> > To: "Mark Struberg" <struberg(a)yahoo.de>
> > Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org>
> > Date: Wednesday, April 27, 2011, 12:01 PM
> > I see. We can consider doing
> > something like this - I guess what I have asked people
> to do
> > initially is equivalent to the feasibility check. We
> can
> > open it up to the community for after the kick off con
> call
> > and get their feedback on whether we are going in the
> right
> > direction. How does that sound?
> >
> > On 27 Apr 2011, at 12:57, Mark Struberg wrote:
> >
> > > The EG and extended EG first worked through all
> the
> > Jira issues and did some documentation and
> feasibility
> > checks. Before finishing the spec he called for
> feedback in
> > the community basically asking them to vote for the
> jira
> > issues (directly in jira) they see as most important
> to get
> > fixed.
> > >
> > >
> > > http://weblogs.java.net/blog/edburns/archive/2011/04/25/vote-your-top-fiv...
> > >
> > > http://java.net/jira/secure/IssueNavigator.jspa?requestId=10523
> > >
> > > Actually your own uidata issue comes out on top
> ;)
> > >
> > > LieGrue,
> > > strub
> > >
> > > --- On Wed, 4/27/11, Peter Muir <pmuir(a)redhat.com>
> > wrote:
> > >
> > >> From: Peter Muir <pmuir(a)redhat.com>
> > >> Subject: Re: [cdi-dev] CDI 1.1
> > >> To: "Mark Struberg" <struberg(a)yahoo.de>
> > >> Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org>
> > >> Date: Wednesday, April 27, 2011, 11:49 AM
> > >> Can you briefly explain the system he
> > >> used?
> > >>
> > >> On 27 Apr 2011, at 12:47, Mark Struberg
> wrote:
> > >>
> > >>> Congratulations Pete!
> > >>>
> > >>> What do you think about a public voting
> as Ed
> > did with
> > >> JSF-2.2?
> > >>> Could give some good feedback.
> > >>>
> > >>> LieGrue,
> > >>> strub
> > >>>
> > >>>
> > >>> --- On Wed, 4/27/11, Peter Muir <pmuir(a)redhat.com>
> > >> wrote:
> > >>>
> > >>>> From: Peter Muir <pmuir(a)redhat.com>
> > >>>> Subject: [cdi-dev] CDI 1.1
> > >>>> To: "cdi-dev" <cdi-dev(a)lists.jboss.org>
> > >>>> Date: Wednesday, April 27, 2011,
> 11:25 AM
> > >>>> Hi everyone
> > >>>>
> > >>>> Welcome to the CDI 1.1 expert group.
> I've
> > started
> > >> to
> > >>>> collect some resources at https://github.com/pmuir/cdi/wiki. Please take some
> > >>>> time to read through them.
> > >>>>
> > >>>> I would like everyone to work their
> way
> > through
> > >> the various
> > >>>> lists of issues in JIRA https://github.com/pmuir/cdi/wiki/CDI-1.1-issues and
> > >> do
> > >>>> four things:
> > >>>>
> > >>>> * If you are aware of an issue that
> is
> > not
> > >> recorded, please
> > >>>> create one
> > >>>> * If you think an issue on the TBC
> list
> > should be
> > >> addressed
> > >>>> in CDI 1.1 then please make a note
> of
> > this, and
> > >> prepare an
> > >>>> email to this list explaining why
> you
> > think the
> > >> issue should
> > >>>> be included. Please restrict yourself
> to
> > three
> > >> such issues.
> > >>>> * If you think an issue on the
> proposed
> > list
> > >> shouldn't be
> > >>>> addressed then please make a note of
> this,
> > and
> > >> prepare an
> > >>>> email to this list explaining why
> you
> > think the
> > >> issue
> > >>>> shouldn't be included. Please
> restrict
> > yourself to
> > >> three
> > >>>> such issues.
> > >>>> * Write a note to the list indicating
> what
> > issues
> > >> you are
> > >>>> going to take a lead on. For major
> issues,
> > prepare
> > >> a 2
> > >>>> minute summary for the concall so
> that you
> > can
> > >> brief people
> > >>>> on the issue.
> > >>>>
> > >>>> The (soft) deadline for this exercise
> is
> > Wednesday
> > >> 11th
> > >>>> May. Of course, we can continue to
> debate
> > the
> > >> merits of
> > >>>> issues after this, but to make things
> run
> > smoothly
> > >> it will
> > >>>> help a lot if we can get this done
> > quickly!
> > >>>>
> > >>>> I propose we have conference call on
> > Thursday 12th
> > >> May to
> > >>>> kick off, overview the main issues
> facing
> > us and
> > >> run through
> > >>>> who will take what issues. Here is
> my
> > proposed
> > >> slot - http://www.timeanddate.com/worldclock/fixedtime.html?msg=CDI+Kick+off+con...
> > >>>> - it's difficult to find something
> > suitable for
> > >> everyone,
> > >>>> but this does allow both people in
> > Australia (late
> > >> night)
> > >>>> and the US West Coast (our two
> extremes)
> > to
> > >> particpate.
> > >>>>
> > >>>> Any comments or suggestions welcome,
> > >>>>
> > >>>> Pete
> > >>>>
> > _______________________________________________
> > >>>> cdi-dev mailing list
> > >>>> cdi-dev(a)lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >>>>
> > >>
> > >>
> >
> >
>
12 years, 11 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
12 years, 11 months
Summarize finding a BeanManager (for Java SE, integration with older Java EE and unit testing)
by Rick Hightower
We need a general purpose way of finding a BeanManager.
+1 for me.
This way should include JNDI lookup to a fallback BeanManagerLocator that
uses a ServiceLoader
+1 for me.
I think the behavior should look like this:
- Lookup BeanManager in JNDI
- If not found, try to load BeanManagerLocator from system property.
- If not found, try to load BeanManagerLocator from ServiceLoader.
- If more than one BeanManagerLocator found, sort by priority or die if
there is more than one. (not sure about the sort, I think it should die, but
can be convinced otherwise).
- Once the BeanManagerLocator is found, use it to return a BeanManager
In addition,
I think we need a simplified interface for BeanManager.
https://github.com/CDISource/cdisource/blob/master/beancontainer/api/src/...
This could just be a utility class, but it should be included with CDI 1.1.
I think the BeanManager interface is too low level.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
12 years, 11 months
We'll get started soon
by Peter Muir
Hi all
It's great to see participation picking up here. The JCP EC vote on the JSR proposal finished yesterday (the grapevine tells me that there are no problems with the vote :-) and we are just waiting on the JCP updating their site (I would guess Easter is getting in the way).
Once that comes through, I'll send an official welcome email, but in the meantime you can review the wiki I put together at https://github.com/pmuir/cdi/wiki which should provide some useful resources.
In the welcome email I'll discuss the schedule I would like us to follow, and ask for people to take a lead on certain issues, so please check the issue tracker https://issues.jboss.org/browse/CDI and see if there is anything which grabs your fancy.
Pete
12 years, 11 months
