[JBoss JIRA] (CDI-591) Easy way to get an interceptor model
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-591:
----------------------------------
Hm, then I don't understand why not use {{InvocationContext.getMethod()}} (using {{BeanManager.createAnnotatedType()}} does not guarantee you will work with the AT processed by extensions anyway).
> Easy way to get an interceptor model
> ------------------------------------
>
> Key: CDI-591
> URL: https://issues.jboss.org/browse/CDI-591
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Romain Manni-Bucau
>
> Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
> {code}
> @Inject
> @Intercepted
> AnnotatedType<?> type;
> @Inject
> @Intercepted
> AnnotatedMethod<?> method;
> {code}
> would be great
> Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
[JBoss JIRA] (CDI-591) Easy way to get an interceptor model
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-591:
----------------------------------------
No, needs both the annotated method and type. The binding is the obvious interesting thing but often there are companion annotations the interceptor needs to read. Workaround today is to use the bean manager to "create" the annotated type and filter methods to find it but this is not fluent and as easy as it could.
> Easy way to get an interceptor model
> ------------------------------------
>
> Key: CDI-591
> URL: https://issues.jboss.org/browse/CDI-591
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Romain Manni-Bucau
>
> Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
> {code}
> @Inject
> @Intercepted
> AnnotatedType<?> type;
> @Inject
> @Intercepted
> AnnotatedMethod<?> method;
> {code}
> would be great
> Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
[JBoss JIRA] (CDI-468) Extend javax.interceptor.InvocationContext
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-468?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-468:
-----------------------------
Fix Version/s: 2.0 (discussion)
> Extend javax.interceptor.InvocationContext
> ------------------------------------------
>
> Key: CDI-468
> URL: https://issues.jboss.org/browse/CDI-468
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Arne Limburg
> Fix For: 2.0 (discussion)
>
>
> Currently there is no easy way to obtain the interceptor binding annotation for an interceptor call. The interceptor binding annotation is needed to access @Nonbinding attributes and behave accordingly.
> I propose to extend the javax.interceptor.InvocationContext interface with a method
> public Annotation getInterceptorBinding() or
> public <A extends Annotation> A getInterceptorBinding(Class<A> type)
> The @AroundInvoke method of CDI Interceptors may use this extended interface as parameter instead of the original one to obtain the interceptor binding annotation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
[JBoss JIRA] (CDI-591) Easy way to get an interceptor model
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-591?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-591:
----------------------------------
So are the interceptor bindings the only info you're interested in? If so, there is CDI-468 already.
> Easy way to get an interceptor model
> ------------------------------------
>
> Key: CDI-591
> URL: https://issues.jboss.org/browse/CDI-591
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Romain Manni-Bucau
>
> Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
> {code}
> @Inject
> @Intercepted
> AnnotatedType<?> type;
> @Inject
> @Intercepted
> AnnotatedMethod<?> method;
> {code}
> would be great
> Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
[JBoss JIRA] (CDI-591) Easy way to get an interceptor model
by Romain Manni-Bucau (JIRA)
Romain Manni-Bucau created CDI-591:
--------------------------------------
Summary: Easy way to get an interceptor model
Key: CDI-591
URL: https://issues.jboss.org/browse/CDI-591
Project: CDI Specification Issues
Issue Type: Epic
Reporter: Romain Manni-Bucau
Since CDI 1.1 we can get the intercepted Bean<?> but we can't get the annotated type and method associated easily (= an injection). Would be great to enable it since often in an interceptor you need the binding to read some configuration (@Nonbinding) to change a bit the behavior.
{code}
@Inject
@Intercepted
AnnotatedType<?> type;
@Inject
@Intercepted
AnnotatedMethod<?> method;
{code}
would be great
Side note: would be better to be in the InvocationContext but not sure it is an option. Or it would need a CdiInvocationContext inheriting from InvocationContext probably.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
[JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer
by Antonin Stefanutti (JIRA)
[ https://issues.jboss.org/browse/CDI-590?page=com.atlassian.jira.plugin.sy... ]
Antonin Stefanutti commented on CDI-590:
----------------------------------------
I've been facing that need as well in a number of extensions. Ideally, there would be a way to declare producer for parameterized types that contain bounded wildcard type parameters. A way to provide a set of return types that can guarantee type safe resolution at deployment time would be great as well.
> Provide a way to produce any type in a producer
> -----------------------------------------------
>
> Key: CDI-590
> URL: https://issues.jboss.org/browse/CDI-590
> Project: CDI Specification Issues
> Issue Type: Epic
> Reporter: Romain Manni-Bucau
>
> Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list
> It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner.
> Idea would be for injection point aware producers with a qualifier to producer Object and match all types.
> It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type".
> I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
Canceling meeting
by Antoine Sabot-Durand
H guys,
I have to cancel the meeting today.
Please continue reviewing the open PR, especially PR 270.
Antoine
7 years, 2 months
[JBoss JIRA] (CDI-560) A bean archive does not have to contain a beans.xml file
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-560?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-560:
---------------------------------
This issue can be closed or resolved.
> A bean archive does not have to contain a beans.xml file
> --------------------------------------------------------
>
> Key: CDI-560
> URL: https://issues.jboss.org/browse/CDI-560
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Concepts
> Affects Versions: 2.0-EDR1
> Environment: Section 5.1 Modularity: The library is a bean archive if it contains
> a beans.xml file, as defined in Bean archives.
> It contradicts with the section 12.1
> An archive which:
> contains a beans.xml file with the bean-discovery-mode of none, or,
> contains an extension and no beans.xml file
> is not a bean archive.
> Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none".
> I think it is better to be "The library may be a bean archive, as defined in Bean archives."
> Reporter: Emily Jiang
> Priority: Minor
> Fix For: 2.0 (proposed)
>
>
> Section 5.1 Modularity: The library is a bean archive if it contains
> a beans.xml file, as defined in Bean archives.
> It contradicts with the section 12.1
> {quote}
> An archive which:
> * contains a beans.xml file with the bean-discovery-mode of none, or,
> * contains an extension and no beans.xml file
> is not a bean archive.
> {quote}
> Therefore, an archive with beans.xml is not a bean archive if the bean-discovery-mode = "none".
> I think it is better to be "The library may be a bean archive, as defined in Bean archives."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
[JBoss JIRA] (CDI-590) Provide a way to produce any type in a producer
by Romain Manni-Bucau (JIRA)
Romain Manni-Bucau created CDI-590:
--------------------------------------
Summary: Provide a way to produce any type in a producer
Key: CDI-590
URL: https://issues.jboss.org/browse/CDI-590
Project: CDI Specification Issues
Issue Type: Epic
Reporter: Romain Manni-Bucau
Note: this is a follow up "adding generic producers to CDI 2.0?" thread on the list
It is common to rely on a subsystem (another IoC, a coercing system, ...) to produce values. Today a producer can't say "I produce anything in a safe" manner.
Idea would be for injection point aware producers with a qualifier to producer Object and match all types.
It needs another flag (can be in @Qualifier or another annotation it is not really important) to say "I produce safely any type".
I did a PoC on github: https://github.com/rmannibucau/generic-producer-cdi but think it can be a nice feature of CDI 2.0 since it would avoid users to have to dig into extensions for several simple cases (configuration, bridge to other IoC...)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 2 months
Re: [cdi-dev] @ThreadScoped?
by Mark Struberg
See Bean#getScope() and BeanManager#getContext()
Just uses Class and no Annotation instance.
Lgm
--------------------------------------------
On Sun, 20/3/16, Romain Manni-Bucau <rmannibucau(a)gmail.com> wrote:
Subject: Re: [cdi-dev] @ThreadScoped?
To: "Mark Struberg" <struberg(a)yahoo.de>
Cc: cdi-dev(a)lists.jboss.org, "Reza Rahman" <reza_rahman(a)lycos.com>
Date: Sunday, 20 March, 2016, 20:47
Le 20 mars 2016 20:40,
"Mark Struberg" <struberg(a)yahoo.de>
a écrit :
>
> A scope
annotation cannot have a flag.
>
Why? Technically it can
> LieGrue,
> strub
>
>
>
>
>
On Sunday, 20 March 2016, 20:25, Reza Rahman <reza_rahman(a)lycos.com>
wrote:
>
>
> >
> >
> >As discussed
elsewhere in this EG, even in the most pessimistic
reading
of the current spec, all that would
be needed is a flag on the existing
annotation. It's not out of the question at
all.
> >
> >On
Mar 20, 2016, at 1:36 PM, Manfred Riem <mnriem(a)gmail.com>
wrote:
> >
>
>
> >Why is changing @RequestScoped
out of the question?
> >>
> >>
> >>From
my perspective when an AsyncContext is started the request
is
still there.
>
>>
> >>
>
>>It is just being served by a different thread.
> >>
> >>
> >>Certainly there is a need to work
with the Servlet EG to figure out how
to
transfer “ownership” to the AsyncContext.
> >>
> >>
> >>Anyway my 2 cents
> >>
> >>
> >>Thanks!
>
>>
> >>
>
>>Kind regards,
> >>Manfred
Riem
> >>
>
>>
> >>On Mar 19, 2016, at
3:35 PM, Stephan Knitelius <stephan(a)knitelius.com>
wrote:
> >>>
> >>>I would certainly agree with
the assertion that in general it's not
advisable to execute a request with multiple
threads and that usually
single threaded
execution is sufficient.
>
>>>
> >>>However I
don't think ignoring it is an option. Concurrent
operations
can be launched even from CDI
beans. Yet we don't properly support context
propagation nor a context spanning all threads
launched from a request.
>
>>>
> >>>I know that
changing @requestScoped is probably out of the question,
but at least we should consider adding a new
context spanning all threads
and defining a
logical solution for context propagation that can be
explained to the end user.
>
>>>
> >>>
> >>>
>
>>>
> >>>On Fr., 11.
März 2016 at 17:17, Mark Struberg <struberg(a)yahoo.de>
wrote:
> >>>
> >>>Yes, but certain things in EE
are assumed to be handled on a single
thread. And if you run on a servr then this is
really not a blocker most
times. If I get
many paralllel requests hitting my box then I do not need
async handling _that_ often. The whole overhead
for setting up the new
thread, etc often
heavily exceeds the benefits.
>
>>>>So I would not put too much energy into
it…
> >>>>
> >>>>LieGrue,
> >>>>strub
>
>>>>
> >>>>>
Am 11.03.2016 um 15:44 schrieb Reza Rahman <reza_rahman(a)lycos.com>:
> >>>>>
>
>>>>> This is essentially in keeping with the
minimalist nature of the EE
concurrency JSR.
I believe most of it is left to vendors to do the right
thing for users. May be a good idea is this
language can be tightened up.
>
>>>>>
>
>>>>>> On Mar 11, 2016, at 6:01 AM, Mark
Struberg <struberg(a)yahoo.de>
wrote:
>
>>>>>> E
>
>>>>>> From the servlet spec:
> >>>>>>
> >>>>>> „Java
Enterprise Edition features such as Section 15.2.2,
“Web
Application Environment” on page
15-174 and Section 15.3.1, “Propagation of
Security Identity in EJBTM Calls” on page
15-176 are available only to
threads
executing the initial request or when the request is
dispatched to
the container via the
AsyncContext.dispatch method. Java Enterprise Edition
features may be available to other threads
operating directly on the
response object
via the AsyncContext.start(Runnable) method.“
> >>>>>>
> >>>>>> check
„available only to threads executing the initial
request“
> >>>>>>
> >>>>>> Also if you look
at the servlet AsyncContext then all the wording
is written as MAY and not as MUST.
> >>>>>>
> >>>>>> LieGrue,
> >>>>>> strub
> >>>>>>
> >>>>>>
> >>>>>>> Am 10.03.2016
um 19:52 schrieb Romain Manni-Bucau <
rmannibucau(a)gmail.com>:
> >>>>>>>
> >>>>>>> Hi Mark,
> >>>>>>>
> >>>>>>> think 2.3.3.4
states the opposite.
>
>>>>>>>
>
>>>>>>>
>
>>>>>>> Romain Manni-Bucau
> >>>>>>> @rmannibucau
| Blog | Github | LinkedIn | Tomitriber
> >>>>>>>
> >>>>>>> 2016-03-10
19:43 GMT+01:00 Mark Struberg <struberg(a)yahoo.de>:
> >>>>>>> Back from
JavaLand conference, so sorry for not kicking in
earlier.
>
>>>>>>>
>
>>>>>>> I not quite get the
argumentation chain. It’s that all triggered
by async servlet requests? And isn’t the
servlet spec also saying that all
the
request param etc may max be assigned to a single thread AT
A TIME!
> >>>>>>>
> >>>>>>> Means that it
might not be on multiple threads in parallel, but
the data is allowed to get moved from one
thread to another (disapearing
from the
first one), right?
>
>>>>>>> Would really need to dig into
the wording of the async servlets
spec
again, maybe has this in the back of his head?
> >>>>>>>
> >>>>>>> LieGrue,
> >>>>>>> strub
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Am
08.03.2016 um 14:43 schrieb Romain Manni-Bucau <
rmannibucau(a)gmail.com>:
> >>>>>>>>
> >>>>>>>> Hi
guys,
>
>>>>>>>>
>
>>>>>>>> following request scope
thread and to center the discussion on
the
thread safety part: do we work on this?
>
>>>>>>>>
>
>>>>>>>> Background: @RequestScoped
is often used as a ThreadLocal
instance
solution. A lot of SE or Batch implementations rely on it
from
what I saw as well as async
implementations reusing existing business logic
with this thread safety constraint.
> >>>>>>>>
> >>>>>>>> Proposal:
providing a @ThreadScoped implementation is cheap for
CDI and implemenation and would avoid the
headache we can have with
@RequestScoped.
Will also remove the quite dark side of the spec
regarding
servlet request and request scope
since now we would have a more natural
solution for all of these situation so
@RequestScoped goals wouldn't
collide as
much.
>
>>>>>>>>
>
>>>>>>>> Questions:
> >>>>>>>> - is it
automatically started as request scoped is (JMS, @Async,
...)? Alternative could be some configuration
in beans.xml (merged accross
the app):
> >>>>>>>>
> >>>>>>>>
<beans>
>
>>>>>>>> <scopes>
>
>>>>>>>> <thread>
> >>>>>>>>
<active>JMS</active>
> >>>>>>>>
<active>ASYNCHONOUS</active>
>
>>>>>>>> </thread>
> >>>>>>>>
</scopes>
>
>>>>>>>> </beans>
> >>>>>>>>
> >>>>>>>> -
start/stop API (this is typically an API the user should
be
able to control for its own threads)
> >>>>>>>> - CDI
2.*0*?
>
>>>>>>>>
>
>>>>>>>> wdyt?
>
>>>>>>>>
>
>>>>>>>> Romain Manni-Bucau
> >>>>>>>>
@rmannibucau | Blog | Github | LinkedIn | Tomitriber
> >>>>>>>>
_______________________________________________
> >>>>>>>> cdi-dev
mailing list
>
>>>>>>>> cdi-dev(a)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.
>
>>>>>>>
>
>>>>>>>
>
>>>>>>
>
>>>>>>
>
>>>>>>
_______________________________________________
> >>>>>> cdi-dev mailing
list
> >>>>>> cdi-dev(a)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.
> >>>>>
> >>>>>
_______________________________________________
> >>>>> cdi-dev mailing
list
> >>>>> cdi-dev(a)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.
> >>>>
> >>>>
>
>>>>_______________________________________________
> >>>>cdi-dev mailing list
> >>>>cdi-dev(a)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.
>
_______________________________________________
> >>>cdi-dev mailing list
> >>>cdi-dev(a)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.
> >>
>
>_______________________________________________
> >cdi-dev mailing list
> >cdi-dev(a)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.
> >
>
>
>
>
_______________________________________________
> cdi-dev mailing list
>
cdi-dev(a)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.
7 years, 2 months
