Re: [cdi-dev] CDI 1.1 EDR1 posted :-)

What do you exactly mean with JavaSE contexts? Do you mean that we should _explicitely_ declare that @ApplicationScoped, @RequestScoped and @SessionScoped must be active by default in SE apps? In OWB and CODI we we provide the same contexts for both SE and EE already. But their behaviour is slightly different. This is really a big benefit not only for SE apps, but also when it comes to unit testing, as you don't need to boot a whole container. Arquillian is pretty fast already, but doing it 'native' is still 10 times faster. In OWB/CODI we started have something like the following in our Extension which registers our scopes if (projectStage = ProjectStage.UnitTest) { registerDummyScopes()... } else { registerRealScopes(); } where the dummy scopes are just dumb Maps per Thread. And sometimes we just have a Context Facade which gets the 'real' context implementation as a @Dependent MyContextImpl bean. In codi-core-impl we just provide a pure SE only implementation, in codi-jsf12-impl we provide a @Specializes @Dependent Jsf12MyContextImpl extends MyContextImpl and in codi-jsf20-impl an @Specializes @Dependent Jsf20MyContextImpl extends Jsf12MyContextImpl This works pretty well because the context registration is only done in @Observes AfterBeanDiscovery, thus you can fully use CDI itself in the Contexts. The only thing you must take care is that internally used Contexts got registered before your own. E.g. the CODI @RestScoped an @WindowScoped storage internally, thus @WindowScoped must get registered upfront. Means, technically it is easily doable, but it's some homework to do for Containers and Extensions. LieGrue, strub > ________________________________ > From: Rick Hightower <richardhightower(a)gmail.com&gt; > To: Peter Muir <pmuir(a)redhat.com&gt; > Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Friday, October 14, 2011 2:24 AM > Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) > > > > > Basically if CDI does these.... > > •Split specification into core and Java EE integration > •Bootstrap support > •Java SE context definition > > > 1, 1.1, and 1.2 need to be rewritten. > > > The spec CDI 1.0 started out very JSF and EJB centric. CDI is, and is becoming more so, more general. > > > > > > > Then all of the intro material from > On Thu, Oct 13, 2011 at 11:23 AM, Peter Muir <pmuir(a)redhat.com&gt; wrote: > > I would be more than happy to accept rewrites here. >> >> >> I think the best way is for you to offer a proposal and then we discuss it here... >> >> >> Thanks! >> >> -- >> Pete Muir >> http://in.relation.to/Bloggers/Pete >> >> On 13 Oct 2011, at 19:16, Rick Hightower <richardhightower(a)gmail.com&gt; wrote: >> >> >> I think CDI has changed its purpose and scope enough that some of the intro material which made total sense when CDI was forming is now missing the mark. >>> >>> >>> CDI sort of evolved what was possible. The intro is still talking about the CDI you are going to build and the problem it is trying to solve. >>> >>> >>> CDI 1.1, problem has been solved well, and CDI redefined what was there. >>> >>> >>> Anyway... the intro material does not match the current scope and where CDI is today. >>> >>> >>> I think its important because some folks will never get past the intro... :) >>> >>> >>> Don't want CDI to be pigeon holed into some role it has but it is so much more than that. >>> >>> >>> It is more general purpose than that. >>> >>> >>> I want to table this. I can offer some rewrites.. But wanted to throw this out there. >>> >>> >>> On Wed, Oct 5, 2011 at 5:21 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >>> >>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>> >>> >>> >>> -- >>> Rick Hightower >>> (415) 968-9037 >>> Profile >>> >>> > > > > -- > Rick Hightower > (415) 968-9037 > Profile > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > >