No meeting tomorrow
by Antoine Sabot-Durand
Hi all,
I'll be on PTO tomorrow, so no meeting, yet, we have a lot of PR open to
review, so if you have time, please go thru them and give feedback or +1 if
you're ok for the addition, it will help us go forward.
Antoine
8 years, 7 months
[JBoss JIRA] (CDI-638) Introduce a new xsd for CDI 2.0
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-638:
----------------------------------------
Summary: Introduce a new xsd for CDI 2.0
Key: CDI-638
URL: https://issues.jboss.org/browse/CDI-638
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Antoine Sabot-Durand
CDI-420 made us to introduce the {{<trim/>}} attribute to {{beans.xml}}, so we need to introduce a new grammar ({{beans_2_0.xsd}})for CDI 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-490:
----------------------------------
[~meetoblivion] Yes, that's a good idea. My original point was that an app may behave differently depending on the target CDI runtime, i.e. an interceptor with {{@Priority}} might be also used in CDI 1.0 (the priority would be just ignored). But it's probably a very rare use case.
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Assignee: John Ament
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec)
by Antoine Sabot-Durand
Hi All,
Ed burns (in cc) contacted me yesterday to follow our brief encounter at
Java One to re-open SERVLET_SPEC-116 (CDI-492 on our side).
As you can see in the discussion below, I gave some leads to solve their
issues and suggested that we help them to work on them.
Perhaps we could start by setting up an online meeting with all interested
person on both EG?
Antoine
---------- Forwarded message ----------
From: *Antoine Sabot-Durand* <asd(a)redhat.com>
Date: Wed, Oct 12, 2016 at 10:22 AM
Subject: Re:
[SERVLET_SPEC-116-CDIRelatedBeansInServletSpec][CDI-492-FobStuffToServlet]
Revitalization attempt
To: Edward Burns <edward.burns(a)oracle.com>
Cc: Shing Wai Chan <shing.wai.chan(a)oracle.com>
Hi Ed,
Glad to ear that. as you can check on our side [1] we are ready to help you
solve these point
Solutions are reachable:
For the backward compatibility issue raised by Stuart:
As I already said, the backward compatibility could be solved by either a
qualifier or by adding to CDI an easy way to detect its version and decide
of the bean creation on servlet side according to it.
For the portable implementation issue:
I don't understand what is the problem here. CDI provide a powerful SPI
that allows development of portable extensions. Unless I miss something, I
see no reason why this code shouldn't be developed at the spec level and so
being portable. BTW we are of course ready to help you right this code.
For the class loading issue:
2 solutions here:
- accept to have an inactive class in your implementation (a CDI portable
extension) linked to a missing library (cdi-api). As it will never be
called no error should be raised
- do like JAX-RS by creating a specific jar for CDI support in your
implementation. The jar would be included in Java EE and not in Servlet
only server
That's only from my understanding and knowledge of the problem, if we go to
a discussion with all CDI EG, we may find even more better solutions.
I suggest that start a workgroup including member of the EG on both side to
work on this issues resolution
Wdyt?
Antoine
[1]
http://cdi-development-mailing-list.1064426.n5.nabble.com/Which-version-o...
On Tue, Oct 11, 2016 at 5:26 PM, Edward Burns <edward.burns(a)oracle.com>
wrote:
Hello Antoine,
When I briefly bumped into you at JavaOne, you expressed a desire to
revisit this issue. Since we didn't make time to meet at JavaOne, I am
following up over email.
Way back at the beginning of Servlet 4.0, I attempted to get this one
resolved. We filed two JIRAS, as in the subject, and had some
discussion [1] [2]. We ended up resolving SERVLET_SPEC_116 as
WORKS_AS_DESIGNED for this reason, the "classloader and backward
compatibility concern":
>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas <
sdouglas(a)redhat.com> said:
SD> Say I have an application that packages Weld (or OWB) that I have
SD> deployed on a Servlet 3.1 container, and I now want to move it to a
SD> Servlet 4.0 container. The older version of Weld will still provide
SD> the HttpServletRequest beans (as it is required to do by spec) and
SD> the servlet container will also provide these beans (as we are
SD> required to do by spec) and as a result if you try and inject them
SD> you will get a bean resolution error as two beans resolve to the
SD> injection point.
>>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins <gregw(a)intalio.com>
said:
GW> While initially I thought that the words "when running in an
GW> environment that also supports CDI..." would be sufficient to make
GW> this OK, I'm now doubting that. I share Stuarts concerns about
GW> classloading confusion.
>>>>> On Fri, 21 Nov 2014 07:03:33 -0800, Edward Burns <
edward.burns(a)oracle.com> said:
EB> Ajran, while your observations are accurate, the backward
EB> compatibility issues raised by Stuart and seconded by Greg are
EB> showstoppers for this change in my opinion at this point.
There was an additional concern, the "portable implementation concern":
it is not possible to provide portable implementations of the code
necessary to implement the new requirements that would be in the Servlet
spec, taken from CDI section 3.8:
CDI3.8> A servlet container must provide the following built-in
CDI3.8> beans, all of which have qualifier @Default:
CDI3.8> a bean with bean type javax.servlet.http.HttpServletRequest,
CDI3.8> allowing injection of a reference to the HttpServletRequest
CDI3.8> a bean with bean type javax.servlet.http.HttpSession,
CDI3.8> allowing injection of a reference to the HttpSession,
CDI3.8> a bean with bean type javax.servlet.ServletContext, allowing
CDI3.8> injection of a reference to the ServletContext,
CDI3.8> These beans are passivation capable dependencies, as defined
CDI3.8> in Passivation capable dependencies.
In my understanding, the portable implementation concern has been adequately
addressed by API in CDI 2.0. Is that correct?
Do you have any suggestion for how to address the classloader and
backward compatibility concern?
Thanks,
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
[1]
https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2014-...
[2]
https://java.net/projects/servlet-spec/lists/users/archive/2014-11/messag...
8 years, 7 months
[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-490:
--------------------------------
[~mkouba] we can add a warning indicating the ordering was not deterministic in CDI 1.1/1.2, (CDI 1.0 wouldn't be relevant since you can only activate via {{beans.xml}}) and that it is becoming deterministic in CDI 2.0.
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Assignee: John Ament
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (CDI-490) Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-490?page=com.atlassian.jira.plugin.sy... ]
John Ament reassigned CDI-490:
------------------------------
Assignee: John Ament
> Clarify what happens when an interceptor/decorator is enabled using both @Priority and beans.xml
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-490
> URL: https://issues.jboss.org/browse/CDI-490
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators, Interceptors
> Affects Versions: 1.2.Final
> Reporter: Jozef Hartinger
> Assignee: John Ament
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> Suppose an InterceptorA has @Priority and is also listed in the beans.xml file of a particular BDA. Such interceptor is for sure enabled because:
> {quote}An interceptor is said to be enabled if it is enabled in at least one bean archive or is listed in the final
> list of interceptors for the application, as defined in Section 11.5.2, “AfterTypeDiscovery event”.{quote}
> it matches both parts of the statement.
> As for ordering, the following statement defines invocation order:
> {quote}Interceptors enabled using @Priority are called before interceptors enabled using beans.xml.{quote}
> Since InterceptorA is enabled by both @Priority and beans.xml, the following applies:
> "Interceptors enabled using @Priority" = \{ InterceptorA \}
> "interceptors enabled using beans.xml" = \{ InterceptorA \}
> We can perform substitution in the statement and we get:
> *\{ InterceptorA \} are called before \{ InterceptorA \}*
> which does not seem right.
> The specification should explicitly address this scenario. There are several options (some of them are better, some are worse):
> 1) Invoke the interceptor twice - each time in the corresponding order given by priority and position in beans.xml
> 2) Invoke the interceptor once in the @Priority part of the invocation chain (@Priority has precedence)
> 3) Invoke the interceptor once in the beans.xml part of the invocation chain (beans.xml has precedence)
> 4) Forbid an interceptor to be enabled by both @Priority and beans.xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
John Ament updated CDI-420:
---------------------------
Affects Version/s: 1.1.Final
1.2.Final
(was: TBD)
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Mark Struberg
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
John Ament updated CDI-420:
---------------------------
Issue Type: Feature Request (was: Bug)
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Mark Struberg
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months