May 2011 - cdi-dev - Jboss List Archives

[JBoss JIRA] Commented: (CDI-14) Add instance() method to BeanManager

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-14?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-14: ---------------------------------- To clarify this a bit: Currently we need * BeanManager#getBeans * BeanManager#resolve * BeanManager#getReference I don't think Instance<Object> instance(); is enough. It should be more like Instance<T> instance(T, Annotation<? extends Qualifier>); right? But to be honest: imo we should not make too much functionality available in the BeanManager and bloat our interface if it is easily doable already. This is really only used in situations where you cannot @Inject your Instance object (means in unmanaged instances like a JPA EntityListener or similar). But in those rare cases, it's easily doable already. Maybe we just add an own section to the spec and explain how this 3 methods work together for getting the contextual reference? > Add instance() method to BeanManager > ------------------------------------ > > Key: CDI-14 > URL: https://issues.jboss.org/browse/CDI-14 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Resolution > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > > Currently obtaining a contextual reference is quite a complex operation, adding a method like: > Instance<Object> instance(); > would make it much easier. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (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 commented on CDI-30: ------------------------------ Ok, we will cover scope at the phone call next week and come up with a statement. > 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

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-30) An API for managing built in contexts

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-30: ---------------------------------- sure, go on. The question is though how broad CDI-1.1 should be finally. If it will only be a 'bugfix and consistency' release, then I'd say we move this to a later version. If it is more a CDI-2, then we should cleanup the conversations too. > 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

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (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 commented on CDI-30: ------------------------------ Mark, can we spin out your issues with CDI conversations to a new issue, as these are definitely something we should address. Regarding this issue around managing contexts, what I believe is useful here is to introduce a much more powerful, regular SPI that can manage all the built in contexts in a consistent fashion (unlike the proposal above which is just for conversations and very special case). This would also give people building their own contexts a "blueprint" to build their lifecycle management from which would introduce more uniformity for users. I will happily drive this issue, but I need a couple of weeks to write up a full proposal :-) > 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

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-48) Global Interceptor/Decorator ordering

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/CDI-48?page=com.atlassian.jira.plugin.sys... ] George Gastaldi commented on CDI-48: ------------------------------------ This also applies to ServiceHandler beans as defined in CDI-110 > Global Interceptor/Decorator ordering > ------------------------------------- > > Key: CDI-48 > URL: https://issues.jboss.org/browse/CDI-48 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Decorators, Interceptors, Packaging and Deployment > Affects Versions: 1.0 > Reporter: Stuart Douglas > Fix For: 1.1 (Proposed) > > > Currently interceptor/decorator ordering is specified on a per bean archive level. In the majority of cases the correct ordering is the same for every BDA in the application, so this violates DRY and opens the door to nasty bugs due to different ordering per module if beans.xml files get out of sync. > We should look at allowing the user to define interceptor and decorator ordering once per app and have this applied to all modules in the deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

Work done on CDI-1.1 spec

by George Gastaldi

Hello all ! I started some work on the specification, but I still have some doubts regarding to how should we develop this specification. I forked pmuir´s GitHub repository and commit it some changes to my fork, however, the build.xml script is not working and the DocBook found there is the final draft of JSR-299. I propose that : 1) A new GitHub repository be created. The jsr-299 folder must be copied to a jsr-346 folder or we should adopt a new structure (should the api be placed there also?). 2) Maven-based build instead of Ant (To be discussed). 3) EG members should fork the original repository and work on their issues on their forked repository, creating a branch for each issue / feature. This way, we could merge the specification changes as they are completed (To be discussed also). I believe that these doubts may be answered in the kick-off meeting, but I really would like to hear from you what would be a better choice. PS: BTW, it would be nice to have a Google calendar set or something to schedule these meetings. Regards, George Gastaldi

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-30) An API for managing built in contexts

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-30: ---------------------------------- hmm not sure if we really should add this. This was certainly a good thing back at the time when we discussed this. But from trying to use CDI's own @ConversationScoped in a real world JSF project I must say - it doesn't work out. Reason is that our CDI Conversation is lazy-starting which is way too late for JSF applications. Because what happens if you have a mandatory field not set or any other JSR-303 or JSF validation issue? In this case your action - which would make the conversation long-running - just doesn't get invoked! So you end up with a standard @RequestScoped behaviour and your bean will over and over get created again with each view hit. Also: CDI conversations doesn't prevent opening an action link in a new window or tab, which makes them unusable for multi windowed applications. I guess the same reasons apply why CODI introduced an own ConversationScoped and why Seam3 also introduced an own one, right? So, since the CDI @ConversationScoped is kind of naturally restricted, I'm not sure if it's really worth adding a complex management SPI for it. > 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

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-18) Global enablement of interceptors, decorators and alternatives

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Mark Struberg commented on CDI-18: ---------------------------------- > RE: The <first> <others> turned out to be not flexible enough for lots of situations. Thus I prefer > an ordinal with a float value. Hmmm.. Ok. My comment was targeted at the mechanism used in the faces-config.xml which I assume has the same mechanism (need to re-read the servlet 3.0 spec though). Problem there is that the ordering is for the whole config file, isn't? So you could only define the order of all the stuff in the beans.xml. Not sure if we need that, but in case of the faces-config.xml I definitely regretted it already: I did want to have the EL-order in a different way than the facelets resource order which doesn't work. > 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

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-92) Allow injection of Bean object for a bean

by Richard Hightower (JIRA)

[ https://issues.jboss.org/browse/CDI-92?page=com.atlassian.jira.plugin.sys... ] Richard Hightower commented on CDI-92: -------------------------------------- Got it. Makes sense. Sort of like BeanNameAware in Spring. :) > Allow injection of Bean object for a bean > ----------------------------------------- > > Key: CDI-92 > URL: https://issues.jboss.org/browse/CDI-92 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.0 > Reporter: Pete Muir > Fix For: 1.1 (Proposed) > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

1
0
0 / 0

[JBoss JIRA] Commented: (CDI-18) Global enablement of interceptors, decorators and alternatives

by Richard Hightower (JIRA)

[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ] Richard Hightower commented on CDI-18: -------------------------------------- <after> <others/> <name> C </name> </after> Section 8.2 of the Servlet Specification. > 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

13 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev May 2011