5:01 a.m.
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>
To: Peter Muir <pmuir(a)redhat.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
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> 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> 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> wrote:
>>
>>http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>_______________________________________________
>>>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