Contexts behavior in SE and Async Event for EDR1
by Antoine Sabot-Durand
Hi guys,
We should finally decide how to manage normal scope context (other than application context ) in SE and during Async Event for EDR1.
Having only RequestContext active during async event as Martin suggest in the PR makes sense and would be consistent with its behavior during async EJB call.
Mark asked twice to activate Request Context all the time in SE (making it a new Application Context). I’m not found of it, but I’ml not the only one to decide here.
What is you feeling about this ?
Antoine
8 years, 10 months
Fwd: Added chapter for context in Java SE.
by Antoine Sabot-Durand
Discussion that was accidentally in private mode
---------- Forwarded message ---------
From: Mark Struberg <struberg(a)yahoo.de>
Date: ven. 19 juin 2015 à 18:17
Subject: Re: [cdi-dev] Added chapter for context in Java SE.
To: Sabot-Durand Antoine <antoine(a)sabot-durand.net>
Good evening Antoine!
Is this mail deliberately private or did you just forget to cc cdi-dev?
In any case, feel free to forward my reply to the public list.
You bring up a good point. Is JavaSE really a NEW mode?
Or is it rather making official what was initially intended? This was
looong before your time - this was back when the spec still was coined
‚WebBeans‘. Back then we originally wanted to make a DI for ALL Java. We
even wanted to use the javax.inject package looong before there was even an
atinject spec. But ‚politics‘ forced us to add the JavaEE moniker. Ask
Gavin or Pete over a Beer or a good Scotch if you like to hear those story
:)
I rather would _not_ make it a new mode but just stretch the officially
supported usage of the CDI programming model 1:1 to JavaSE as well. That is
what exists with DeltaSpike CdiCtrl and what user already use in a _broad_
way. People imo like to be able to re-use their CDI jars regardless whether
it is SE or EE. If we define that the programming model is behaving
different between SE and EE than I fear we might upset a lot or users.
LieGrue,
strub
PS: trying to make it to Paris, but need to check with customers and
probably have to move a few university lectures. So not sure.
> Am 17.06.2015 um 18:28 schrieb Antoine Sabot-Durand <
antoine(a)sabot-durand.net>:
>
> Mark,
>
> CDI for Java SE breaks the compatibility with the rest of CDI since it's
a new feature. And again this will be discussed in CDI-530. I find more
logical to propose a restraint feature in the EDR and open it later than
the contrary.
> Unless you think that CDI-530 is irrelevant and that context control in
SE are useless...
>
> Antoine
>
> Le lun. 15 juin 2015 à 23:05, Mark Struberg <struberg(a)yahoo.de> a écrit :
> Again: this breaks compat with the rest of CDI.
> CDI defines that the request context is basically always on by default.
> So we need this to be enabled by default as well imp.
>
> LieGrue,
> Strub
>
>
> Gesendet von Yahoo Mail für iPad
>
> Um 15.06.2015 16:26:12 schrieb Antoine Sabot-Durand:Hi all,
>
>
> I added a Scopes and contexts in Java SE chapter to specify that only
Application Context is active under Java SE.
> This part will probably refine later thru CDI-530
>
> Antoine
>
8 years, 10 months
[JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.sy... ]
arjan tijms commented on CDI-492:
---------------------------------
{quote}I understand those concerns, but I think there are solution for most of them.{quote}
Just wondering if there's any progress here or someone still looking into this?
Like Antoine I can't help but feel the issues raised are worth looking into to see if they can be solved. A part of the solution can simply be education, as perhaps it's just a matter of not everyone being fully up to date with how CDI works.
> Give ownership of servlet specific part to servlet specification
> ----------------------------------------------------------------
>
> Key: CDI-492
> URL: https://issues.jboss.org/browse/CDI-492
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java EE integration
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 (discussion)
>
>
> [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_...] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically,
> {quote}
> A servlet container must provide the following built-in beans, all of which have qualifier @Default:
> * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest
> * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession,
> * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext,
> These beans are passivation capable dependencies, as defined in Passivation capable dependencies.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
Added chapter for context in Java SE.
by Antoine Sabot-Durand
Hi all,
I added a Scopes and contexts in Java SE chapter to specify that only Application Context is active under Java SE.
This part will probably refine later thru CDI-530
Antoine
8 years, 10 months
[JBoss JIRA] (CDI-536) Redundant statement in "2.6.2. Default bean names" chapter
by Tomas Remes (JIRA)
Tomas Remes created CDI-536:
-------------------------------
Summary: Redundant statement in "2.6.2. Default bean names" chapter
Key: CDI-536
URL: https://issues.jboss.org/browse/CDI-536
Project: CDI Specification Issues
Issue Type: Bug
Reporter: Tomas Remes
Priority: Minor
This chapter currently says:
{quote}
In the following circumstances, a default name must be assigned by the container:
- A bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified by the value member.
{quote}
and then:
{quote}
If a bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified the value of the value member is defaulted.
{quote}
These 2 statements declare the same IMO.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (CDI-536) Redundant statement in "2.6.2. Default bean names" chapter
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-536?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes updated CDI-536:
----------------------------
Affects Version/s: 1.2.Final
> Redundant statement in "2.6.2. Default bean names" chapter
> ----------------------------------------------------------
>
> Key: CDI-536
> URL: https://issues.jboss.org/browse/CDI-536
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Tomas Remes
> Priority: Minor
>
> This chapter currently says:
> {quote}
> In the following circumstances, a default name must be assigned by the container:
> - A bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified by the value member.
> {quote}
> and then:
> {quote}
> If a bean class or producer method or field of a bean declares a @Named annotation and no bean name is explicitly specified the value of the value member is defaulted.
> {quote}
> These 2 statements declare the same IMO.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
Today's meeting cancelled
by Antoine Sabot-Durand
Hi all,
Im’ not sure to make it for our meeting today. I’m going to JCP EC and Devoxx UK in London, and just learn that I’ll probably have a meeting at the time of our meeting.
The goal is still to release EDR this week. I thanks you for your feedback pointing incosistencies in my proposal for async events (some of them were due to 2 losts commits ;) ).
I’ll answer to your review today or tomorrow, so keep doing them.
regards,
Antoine
8 years, 11 months