 * @Produces
 * @RequestScoped
 * public MyClass produceMyClass(InterceptionFactory factory) {
 *     factory.configure().add(new AnnotationLiteral() {
 *     });
 *     return factory.createInterceptedInstance(new MyClass());
 * }

But all the current interceptor implementations backing @Transactional do
something like:

public Object proceed(InvocationContext ctx) throws Exception {
        Transactional transactionalAnnotation =
                ctx.getMethod().getAnnotation(Transactional.class);

So that clearly won't work.

The spec text for InterceptionFactory also doesn't mention this caveat at
all. So I wonder, what was the intended approach for   InterceptionFactory
and intercepter bindings with attributes?

Or was InterceptionFactory solely intended for intercepter bindings without
(non-binding) attributes?

Kind regards,
Arjan Tijms

>
>
>
>> Is there a standard way to get the bindings? Perhaps getting hold of the
>> Bean that represents the current Interceptor?
>>
>
> You can inject a bean with scope @Dependent, qualifier @Default and type
> Interceptor into any interceptor instance. However, this will not help for
> @Nonbinding value members of an interceptor binding.
>
>
>> Kind regards,
>> Arjan Tijms
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the
>> code under the Apache License, Version 2 (http://www.apache.org/license
>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>> provider waives all patent and other intellectual property rights inherent
>> in such information.
>>
>>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170919/bf71e020/attachment-0001.html 

From mkouba at redhat.com  Tue Sep 19 07:59:12 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 19 Sep 2017 13:59:12 +0200
Subject: [cdi-dev] Interceptor bindings from interceptor when using 2.0
 interception factory
In-Reply-To: 
References: 

Message-ID: 

Dne 19.9.2017 v 13:37 arjan tijms napsal(a):
> Hi,
> 
> On Mon, Aug 28, 2017 at 9:41 AM, Martin Kouba  > wrote:
> 
>         Set bindings = (Set)
>         invocationContext.getContextData().get("org.jboss.weld.interceptor.bindings");
> 
> 
>     In fact, a more safe way is to use the Weld API, cast the invocation
>     context to org.jboss.weld.interceptor.WeldInvocationContext and use
>     the appropriate methods.
> 
> 
> Looking in the code that seems to do the same thing, at least in Weld 3.0.1.

No really. Weld stores the bindings also in context data but the API is 
using a direct reference to a stored set.

> 
> Going via getContextData() is much easier though for code that has to 
> support both Weld and OWB.

Yep, standardizing the key is the only viable solution without 
interceptors spec change. However, it's not typesafe, easy-to-use, etc.

> 
> 
> 
>     Yes. There is already a spec issue:
>     https://issues.jboss.org/browse/CDI-468
>      but this would require a
>     change in interceptors spec.
> 
> 
> I read the issue, thanks for the pointer. I do wonder if the entry in 
> the context data isn't the easiest option regardless. That might only 
> require an update in the CDI spec. Essentially, just standardise the key 
> being used?
> 
> Currently the interceptor factory is an absolutely fantastic feature, 
> but its usefulness is greatly diminished by the fact that no interceptor 
> at this moment can (reliably) retrieve the interceptor bindings for all 
> CDI implementations.
> 
> The spec even uses dynamically adding @Transactional as an example;
> 
>   * >   * @Produces
>   * @RequestScoped
>   * public MyClass produceMyClass(InterceptionFactory factory) {
>   *     factory.configure().add(new AnnotationLiteral() {
>   *     });
>   *     return factory.createInterceptedInstance(new MyClass());
>   * }
> 
> 
> But all the current interceptor implementations backing @Transactional 
> do something like:
> 
> public Object proceed(InvocationContext ctx) throws Exception {
>          Transactional transactionalAnnotation =
>                  ctx.getMethod().getAnnotation(Transactional.class);

And this is obviously wrong. Recently, we've reviewed a Narayana PR 
which is about to fix this problem:
https://github.com/jbosstm/narayana/pull/1211

I personally think that JTA TCK is missing some essential tests here.

> 
> So that clearly won't work.
> 
> The spec text for InterceptionFactory also doesn't mention this caveat 
> at all. So I wonder, what was the intended approach for   
> InterceptionFactory and intercepter bindings with attributes?
> 
> Or was InterceptionFactory solely intended for intercepter bindings 
> without (non-binding) attributes?

I don't think this is an InterceptionFactory-specific problem. It's a 
general issue. It should work the same if you use an extension to add an 
interceptor binding.

> 
> Kind regards,
> Arjan Tijms
> 
> 
> 
> 
> 
>         Is there a standard way to get the bindings? Perhaps getting
>         hold of the Bean that represents the current Interceptor?
> 
> 
>     You can inject a bean with scope @Dependent, qualifier @Default and
>     type Interceptor into any interceptor instance. However, this will
>     not help for @Nonbinding value members of an interceptor binding.
> 
> 
>         Kind regards,
>         Arjan Tijms
> 
> 
>         _______________________________________________
>         cdi-dev mailing list
>         cdi-dev at lists.jboss.org 
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>         
> 
>         Note that for all code provided on this list, the provider
>         licenses the code under the Apache License, Version 2
>         (http://www.apache.org/licenses/LICENSE-2.0.html
>         ). For all
>         other ideas provided on this list, the provider waives all
>         patent and other intellectual property rights inherent in such
>         information.
> 
> 
>     -- 
>     Martin Kouba
>     Senior Software Engineer
>     Red Hat, Czech Republic
> 
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From arjan.tijms at gmail.com  Tue Sep 19 09:22:26 2017
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 19 Sep 2017 15:22:26 +0200
Subject: [cdi-dev] Interceptor bindings from interceptor when using 2.0
 interception factory
In-Reply-To: 
References: 

Message-ID: 

Hi,

On Tue, Sep 19, 2017 at 1:59 PM, Martin Kouba  wrote:

>
>>
> No really. Weld stores the bindings also in context data but the API is
> using a direct reference to a stored set.

Ah, ok, thx

> Going via getContextData() is much easier though for code that has to
>> support both Weld and OWB.
>>
>
> Yep, standardizing the key is the only viable solution without
> interceptors spec change. However, it's not typesafe, easy-to-use, etc.

I hear you. The question is when the earliest opportunity will be to update
the interceptor spec then. With the whole Java EE transfer I guess this
will have to wait at least until that transfer is complete. Hopefully in
the new process we can have something like a hierarchical responsibility
for specs, such that if e.g. Interceptors and AtInject is not explicitly
open, but CDI is, that the CDI EG can take responsibility for it and make
changes there.

For now though, if OWB could also store the bindings under some key,
interceptors that are intended to be portable can practically check both
keys then. Not ideal, but may be a good intermediate solution.

> And this is obviously wrong. Recently, we've reviewed a Narayana PR which
> is about to fix this problem:
> https://github.com/jbosstm/narayana/pull/1211
>
> I personally think that JTA TCK is missing some essential tests here.

Agreed, and the Java EE Security TCK misses those same tests as well, as it
also ships with interceptors.

I don't think this is an InterceptionFactory-specific problem. It's a
> general issue. It should work the same if you use an extension to add an
> interceptor binding.
>

You're right, the InterceptionFactory just brought it to the surface again
for people testing CDI 2.0 features.

Handling stereotypes as per the issue can be a problem as well. I wonder,
wouldn't it be convenient if CDI offers a utility method to look for an
annotation where it would automatically recurses into stereotypes?

I created something like for OmniFaces a while ago:

https://github.com/omnifaces/omnifaces/blob/develop/src/main/java/org/omnifaces/util/BeansLocal.java#L221

Kind regards,
Arjan Tijms

>
>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>         Is there a standard way to get the bindings? Perhaps getting
>>         hold of the Bean that represents the current Interceptor?
>>
>>
>>     You can inject a bean with scope @Dependent, qualifier @Default and
>>     type Interceptor into any interceptor instance. However, this will
>>     not help for @Nonbinding value members of an interceptor binding.
>>
>>
>>         Kind regards,
>>         Arjan Tijms
>>
>>
>>         _______________________________________________
>>         cdi-dev mailing list
>>         cdi-dev at lists.jboss.org 
>>         https://lists.jboss.org/mailman/listinfo/cdi-dev
>>         
>>
>>         Note that for all code provided on this list, the provider
>>         licenses the code under the Apache License, Version 2
>>         (http://www.apache.org/licenses/LICENSE-2.0.html
>>         ). For all
>>         other ideas provided on this list, the provider waives all
>>         patent and other intellectual property rights inherent in such
>>         information.
>>
>>
>>     --     Martin Kouba
>>     Senior Software Engineer
>>     Red Hat, Czech Republic
>>
>>
>>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170919/4735003b/attachment.html 

From issues at jboss.org  Tue Sep 19 09:26:00 2017
From: issues at jboss.org (arjan tijms (JIRA))
Date: Tue, 19 Sep 2017 09:26:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current
 injection point from Bean#create
In-Reply-To: 
References: 

Message-ID: 

    [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465682#comment-13465682 ] 

arjan tijms commented on CDI-610:
---------------------------------

Just wondering, any updates for this? Would this be in scope for CDI 2.1 perhaps?

> Add API to obtain current injection point from Bean#create
> ----------------------------------------------------------
>
>                 Key: CDI-610
>                 URL: https://issues.jboss.org/browse/CDI-610
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Portable Extensions
>            Reporter: arjan tijms
>
> There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}.
> A previously somewhat accepted way (though not specified) was:
> {code}
>   Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class));
>   InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext);
> {code}
> This however broke in some version of Weld.
> Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}.
> Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Sep 19 11:09:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Tue, 19 Sep 2017 11:09:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current
 injection point from Bean#create
In-Reply-To: 
References: 

Message-ID: 

    [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465789#comment-13465789 ] 

Martin Kouba commented on CDI-610:
----------------------------------

Maybe we don't need to extend the API but instead clarify that for a {{@Dependent}} bean it should be possible to obtain {{InjectionPoint}} from within {{Contextual.create()}} (e.g. using {{BeanManager.createInstance().select(InjectionPoint.class).get()}}) and during invocation of a callback specified by {{BeanConfigurator.produceWith()}} (https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/beanConfigurator/BeanConfiguratorExtension.java#L40).

Note that {{CreationalContext}} is currently bound to a bean instance, not an injection point, e.g. an instance might be reused when resolving all injection points of a bean instance. (of course this is just an impl detail)

> Add API to obtain current injection point from Bean#create
> ----------------------------------------------------------
>
>                 Key: CDI-610
>                 URL: https://issues.jboss.org/browse/CDI-610
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Portable Extensions
>            Reporter: arjan tijms
>
> There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}.
> A previously somewhat accepted way (though not specified) was:
> {code}
>   Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class));
>   InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext);
> {code}
> This however broke in some version of Weld.
> Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}.
> Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Sep 20 02:59:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 20 Sep 2017 02:59:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-610) Add API to obtain current
 injection point from Bean#create
In-Reply-To: 
References: 

Message-ID: 

    [ https://issues.jboss.org/browse/CDI-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465789#comment-13465789 ] 

Martin Kouba edited comment on CDI-610 at 9/20/17 2:58 AM:
-----------------------------------------------------------

Maybe we don't need to extend the API but instead clarify that for a {{@Dependent}} bean it should be possible to obtain {{InjectionPoint}} from within {{Contextual.create()}} (e.g. using [BeanManager.createInstance().select(InjectionPoint.class).get()|https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/custom/JuicyBarBean.java#L41]) and during invocation of a callback specified by {{BeanConfigurator.produceWith()}} (e.g. https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/beanConfigurator/BeanConfiguratorExtension.java#L40).

Note that {{CreationalContext}} is currently bound to a bean instance, not an injection point, e.g. an instance might be reused when resolving all injection points of a bean instance. (of course this is just an impl detail)

was (Author: mkouba):
Maybe we don't need to extend the API but instead clarify that for a {{@Dependent}} bean it should be possible to obtain {{InjectionPoint}} from within {{Contextual.create()}} (e.g. using {{BeanManager.createInstance().select(InjectionPoint.class).get()}}) and during invocation of a callback specified by {{BeanConfigurator.produceWith()}} (https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/beanConfigurator/BeanConfiguratorExtension.java#L40).

Note that {{CreationalContext}} is currently bound to a bean instance, not an injection point, e.g. an instance might be reused when resolving all injection points of a bean instance. (of course this is just an impl detail)

> Add API to obtain current injection point from Bean#create
> ----------------------------------------------------------
>
>                 Key: CDI-610
>                 URL: https://issues.jboss.org/browse/CDI-610
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Portable Extensions
>            Reporter: arjan tijms
>
> There's currently not a clear way on how to obtain the *current* injection point (if any) from {{Bean#create}}.
> A previously somewhat accepted way (though not specified) was:
> {code}
>   Bean bean = beanManager.resolve(beanManager.getBeans(InjectionPoint.class));
>   InjectionPoint injectionPoint = (InjectionPoint) beanManager.getReference(bean, InjectionPoint.class, creationalContext);
> {code}
> This however broke in some version of Weld.
> Since getting the injection point is an often used feature in producers, I'd like to propose to introduce an easy API for this, so {{Bean}} implementations can use this just as easily. E.g. something like: {{BeanManager#getCurrentInjectionPoint()}}.
> Also see: http://cdi-development-mailing-list.1064426.n5.nabble.com/Getting-injection-point-from-Bean-create-td5710505i20.html

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From rinsvind at gmail.com  Thu Sep 21 06:22:48 2017
From: rinsvind at gmail.com (Todor Boev)
Date: Thu, 21 Sep 2017 13:22:48 +0300
Subject: [cdi-dev] =?utf-8?b?0J7QttC10L3QuNGFINGB0LU=?=
In-Reply-To: 
References: 
Message-ID: 

I am extremely sorry this was accidentally posted to cdi-dev.

2017-09-18 11:18 GMT+03:00 Todor Boev :

>
>
>
>
> *______________________*
>
> *Todor Boev*
>
> OSGi Platform
>
> *Software AG*
>
>
>
> *From:* Yakub, Esin
> *Sent:* Monday, September 18, 2017 8:20 AM
> *To:* Z_Country_Bulgaria
> *Subject:* ?????? ??
>
>
>
> ????????? ?? ? ??????? J
>
>
>
> ???
> 
> ? ?????????? ?????, ? ?? ??? ??? ??
> 
> .
>
>
>
> ??????? ???????!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170921/58a019e9/attachment.html 

From issues at jboss.org  Mon Sep 25 04:39:01 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 25 Sep 2017 04:39:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-455) Allow building of TypeLiteral's
 with dynamic types
In-Reply-To: 
References: 

Message-ID: 

     [ https://issues.jboss.org/browse/CDI-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated CDI-455:
-----------------------------
    Fix Version/s: 2.1 (Discussion)

> Allow building of TypeLiteral's with dynamic types
> --------------------------------------------------
>
>                 Key: CDI-455
>                 URL: https://issues.jboss.org/browse/CDI-455
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Lucas Ventura Carro
>             Fix For: 2.1 (Discussion)
>
>
> It could be useful the building of {{TypeLiteral}}'s, but using dynamic types. This way, the types can be indicated at runtime and not in compile. This functionality is "doable" as it is done at [Guice|https://github.com/google/guice], a similar injection framework, and as [this post shows|http://luisfsgoncalves.wordpress.com/2010/09/08/generic-bindings-with-guice/].

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Mon Sep 25 04:39:01 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 25 Sep 2017 04:39:01 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-455) Allow building of TypeLiteral's
 with dynamic types
In-Reply-To: 
References: 

Message-ID: 

    [ https://issues.jboss.org/browse/CDI-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467709#comment-13467709 ] 

Martin Kouba commented on CDI-455:
----------------------------------

I think we should add {{Event.select()}} and {{Instance.select()}} variants which also accept {{java.lang.reflect.Type}}. The argument should be checked at runtime and {{IllegalArgumentException}} should be thrown if the type is not a subtype of the event/required type.

Also the trick with {{ChocolateEater}} described above would only work for simple parameterized types and not for more complex use cases.

> Allow building of TypeLiteral's with dynamic types
> --------------------------------------------------
>
>                 Key: CDI-455
>                 URL: https://issues.jboss.org/browse/CDI-455
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>            Reporter: Lucas Ventura Carro
>             Fix For: 2.1 (Discussion)
>
>
> It could be useful the building of {{TypeLiteral}}'s, but using dynamic types. This way, the types can be indicated at runtime and not in compile. This functionality is "doable" as it is done at [Guice|https://github.com/google/guice], a similar injection framework, and as [this post shows|http://luisfsgoncalves.wordpress.com/2010/09/08/generic-bindings-with-guice/].

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Tue Sep 26 10:39:00 2017
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Tue, 26 Sep 2017 10:39:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-717) Element mistakenly removed from
 beans_2_0.xsd
In-Reply-To: 
References: 

Message-ID: 

Matej Novotny created CDI-717:
---------------------------------

             Summary: Element mistakenly removed from beans_2_0.xsd
                 Key: CDI-717
                 URL: https://issues.jboss.org/browse/CDI-717
             Project: CDI Specification Issues
          Issue Type: Bug
    Affects Versions: 2.0 .Final
            Reporter: Matej Novotny

While creating and editing {{beans_2_0.xsd}} there was one line removed as part of [this PR|https://github.com/cdi-spec/cdi/pull/348]. This line is present in {{beans_1_1.xsd}} -> [see the code|https://github.com/cdi-spec/cdi/blob/master/api/src/main/resources/beans_1_1.xsd#L83].

To sum up the meaning of this line, it allows presence of any other non-defined element from _other namespace (than target namespace)_ and further on enforces validation of such element against corresponding XSD.

As a consequence of this change, following {{beans.xml}} is valid with CDI 1.2 ({{beans_1_1.xsd}}) but no longer against CDI 2.0 ({{beans_2_0.xsd}}):
{code}

{code}

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From issues at jboss.org  Wed Sep 27 05:40:00 2017
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Wed, 27 Sep 2017 05:40:00 -0400 (EDT)
Subject: [cdi-dev] [JBoss JIRA] (CDI-718) Bean creation and dependency
 injection should not be performed before AfterDeploymentValidation
In-Reply-To: 
References: 

Message-ID: 

Martin Kouba created CDI-718:
--------------------------------

             Summary: Bean creation and dependency injection should not be performed before AfterDeploymentValidation
                 Key: CDI-718
                 URL: https://issues.jboss.org/browse/CDI-718
             Project: CDI Specification Issues
          Issue Type: Clarification
            Reporter: Martin Kouba
             Fix For: 2.1 (Discussion)

The spec is clear that it is not allowed to invoke {{BeanManager.getReference()}},  {{BeanManager.getInjectableReference()}} and {{BeanManager.createInstance()}} before {{AfterDeploymentValidation}}. I.e. it could be safely used during {{AfterDeploymentValidation}} and after the application initialization finished. The reason is that  before ADV the set of beans/interceptors/decorators may not be complete and extensions can still affect the resolution.

However, using {{InjectionTarget}}, {{UnmanagedInstance}} and {{Contextual.create()}} has the same risks. I think we should clarify the usage so that the spec is consistent.

WRT backward compatibility - note that the container is permitted to define a non-portable mode to overcome problems with legacy applications not using CDI SPI properly.

--
This message was sent by Atlassian JIRA
(v7.2.3#72005)

From arjan.tijms at gmail.com  Wed Sep 27 14:36:28 2017
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 27 Sep 2017 20:36:28 +0200
Subject: [cdi-dev] Moving build-in bean for Principal to Java EE
	Security?
In-Reply-To: 
References: 
Message-ID: 

Hi,

Just a small ping ;)

Kind regards,
Arjan Tijms

On Sun, Sep 17, 2017 at 7:59 PM, arjan tijms  wrote:

> Hi,
>
> I wonder, wouldn't it be a good idea to let JSR 375 take ownership of the build-in
> bean in the Java EE part of CDI for Principal?
>
> The CDI spec proposed to the servlet spec to take ownership of the build-
> in beans for the Servlet owned artefacts (such as
> HttpServletRequest) before.
>
> Kind regards
> Arjan Tijms
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170927/ff1e5383/attachment.html 

From mkouba at redhat.com  Fri Sep 29 02:43:04 2017
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 29 Sep 2017 08:43:04 +0200
Subject: [cdi-dev] Moving build-in bean for Principal to Java EE
	Security?
In-Reply-To: 
References: 

Message-ID: <0de6a01e-096c-3442-2c7b-261aeedbf93b@redhat.com>

+1

Is there a spec issue?

Martin

Dne 27.9.2017 v 20:36 arjan tijms napsal(a):
> Hi,
> 
> Just a small ping ;)
> 
> Kind regards,
> Arjan Tijms
> 
> On Sun, Sep 17, 2017 at 7:59 PM, arjan tijms  > wrote:
> 
>     Hi,
> 
>     I wonder, wouldn't it be a good idea to let JSR 375 take ownership
>     of the build-in bean in the Java EE part of CDI for Principal?
> 
>     The CDI?spec proposed to the servlet spec to take ownership of the
>     build-inbeans?for the Servlet owned artefacts (such as
>     HttpServletRequest)?before.
> 
>     Kind regards
>     Arjan Tijms
> 
> 
> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic