[JBoss JIRA] (CDI-493) Allow firing of generic events from BeanManager
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-493?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt updated CDI-493:
-------------------------------
Summary: Allow firing of generic events from BeanManager (was: Allow firiing of generic events from BeanManager)
> Allow firing of generic events from BeanManager
> -----------------------------------------------
>
> Key: CDI-493
> URL: https://issues.jboss.org/browse/CDI-493
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Sven Linstaedt
>
> Currently we are allowed firiing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable.
> When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
> This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
> {code}
> BeanManager#fireEvent(Type, Object, Annotation...)
> BeanManager#resolveObserverMethods(Type, T, Annotation...)
> {code}
> which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
> The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type.
> Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
> With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like
> {code}
> <X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
> if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
> // register interceptor type
> } else {
> // register intercepted type
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 4 months
[JBoss JIRA] (CDI-493) Allow firiing of generic events from BeanManager
by Sven Linstaedt (JIRA)
Sven Linstaedt created CDI-493:
----------------------------------
Summary: Allow firiing of generic events from BeanManager
Key: CDI-493
URL: https://issues.jboss.org/browse/CDI-493
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Sven Linstaedt
Currently we are allowed firiing generic events from {{javax.enterprise.event.Event<X>#fire}} as long as it's type parameter X does not contain a TypeVariable.
When it comes to {{javax.enterprise.inject.spi.BeanManager#fireEvent}} and {{javax.enterprise.inject.spi.BeanManager#resolveObserverMethods}} this is unfortunately not possible due to type erasure. Because we lack the relevant generic information that are otherwise explicit stated via {{Event#select}}, we are not able to fire a generic event from {{BeanManager#fireEvent}}.
This proposal is about enhancing the API of BeanManager in order to supply the relevant type information, that are otherwise discarded by type erasure. A possible solution would look like adding two new methods to BeanManager
{code}
BeanManager#fireEvent(Type, Object, Annotation...)
BeanManager#resolveObserverMethods(Type, T, Annotation...)
{code}
which receive the selected event type as 1st parameter, validate that the actual event instance (2nd parameter) is assignable to the selected event type (the selected event type has to resolve all type variables; throwing an IllegalArgumentException otherwise) and fires the event afterwards.
The original two methods can delegate their calls to the new ones, having {{java.lang.Object}} as event type.
Additionally {{javax.enterprise.inject.spi.EventMetadata#getType()}} will return the resolved parameterized type.
With this proposal it would be possible to provide meta-extensions, that enable other extension to handle custom extension lifecycle events like
{code}
<X> void on(@Observes @BoundWith(InterceptorBinding.class) ProcessBoundedType<X> pbt) {
if (pbt.getBoundedType().isAnnotationPresent(Interceptor.class)) {
// register interceptor type
} else {
// register intercepted type
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 4 months
Re: [cdi-dev] Getting injection point from Bean#create
by arjan tijms
Hi,
On Thu, Nov 20, 2014 at 11:07 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
> Not sure what it means actually. InjectionPoint is highly contextual so
> having an exception (not a npe of course) would make sense to me.
>
> Bean#create is a "you know what you do" from my understanding since
> interceptors/decorators are not supported for instance so it shouldnt rely
> of things like that, no?
Sure, no interceptor/decorators, but the injection point -is- there of
course. I can see it being set in OWB as a special property on the
creational context if I walk down the stack trace in a debugger when
my Bean#create method is being called. An injection point is something
that implementations of Bean could always need, for instance to
retrieve the name of the field into which injection is taking place.
Of course, it being a "you know what you do", it's okay that it's not
as simple as having it injected into the Bean, and that some extra
code is needed to obtain it. As long as there is at least -a- way to
get hold of it.
The method I posted in the openings post does in fact work, but it
feels slightly hacky. If that's an acceptable way to get the injection
point, then so be it. But just wondering if it's not something that
works by chance and may break later.
Kind regards,
Arjan
9 years, 5 months
[JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification
by Ed Burns (JIRA)
[ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.sy... ]
Ed Burns commented on CDI-492:
------------------------------
I brought up this issue in the servlet EG and it was shot down. Here is the reasoning. As spec lead, I do agree with the reasoning so I have provisionally closed the issue unless we can find a way to address the concerns of the servlet EG:
{quote}
>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas said:
[...]
SD> I think however there may be some backwards compatibility issues for
SD> the standalone servlet container case.
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.
SD> This also works in reverse, if you deploy a new version of CDI to an
SD> older servlet container then no beans will be registered, however I
SD> think this is less of an issue.
SD> For servers that don't actually provide CDI API jars there may also
SD> be some linking issues. The producers need to be linked against the
SD> CDI API which in this case will be provided by the deployment, so it
SD> won't really be possible to just have them as a global library.
>>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins said:
[...]
GW> I share Stuarts concerns about classloading confusion. More over,
GW> I'm concerned that by making CDI to servlet mapping a responsibility
GW> of the servlet container, then we are going to have to do a
GW> container to CDI adaptation for every CDI implementation out there.
GW> The servlet specification already provides servlet container initializers,
GW> which have all the power required for CDI implementations to implement
GW> these CDI v Servlet cross concerns. Thus I think these things must
GW> remain a CDI impl responsibility as they are able to write container
GW> portable code that will handle these concerns. The inverse is not true if
GW> we make them container concerns.
Excellent points. I will use these to push back on
CDI-492-FobStuffToServlet. I will provisionally close this issue for
now at least.
{quote}
> 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
>
> [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.8#6338)
9 years, 5 months
Re: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL
by Werner Keil
>MS> side) is kind of a @WebAppScoped. This is really missing atm. But
>MS> again this must also be active in e.g. JMS invocations which form
>MS> kind a 'logical app'.
"logical app" what's wrong with @ApplicationScoped especially for JMS?
We got e.g. a very distributed Java EE app here at the current client where
JMS is a vital part, but it's not just used in the Web tier.
Werner
On Fri, Nov 21, 2014 at 3:14 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Getting injection point from Bean#create (Romain Manni-Bucau)
> 2. Re: Getting injection point from Bean#create (Romain Manni-Bucau)
> 3. Re: Getting injection point from Bean#create (arjan tijms)
> 4. Re: Getting injection point from Bean#create (Jozef Hartinger)
> 5. Re: [servlet-spec users] [jsr369-experts]
> [116-CDIRelatedBeansInServletSpec] PROPOSAL (Edward Burns)
>
>
> ----------------------------------------------------------------------
>
>
> Message: 5
> Date: Fri, 21 Nov 2014 06:14:25 -0800
> From: Edward Burns <edward.burns(a)oracle.com>
> Subject: Re: [cdi-dev] [servlet-spec users] [jsr369-experts]
> [116-CDIRelatedBeansInServletSpec] PROPOSAL
> To: Mark Struberg <struberg(a)yahoo.de>, users(a)servlet-spec.java.net,
> Cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <21615.18625.427842.794819(a)gargle.gargle.HOWL>
> Content-Type: text/plain; charset=us-ascii
>
> Mark added cdi-dev to the recipients list, but I am not subscribed to
> that (please don't add me, I rely on JJ to keep me up to date!), so this
> may bounce there.
>
> Also, Mark, there is no <jsr369-users(a)servlet-spec.java.net>. The users
> lists are re-used from JSR to JSR for each technology. Thus, I have put
> users(a)servlet-spec.java.net in place of the non-existent list.
>
> On Wednesday, 19 November 2014, 19:40, Edward Burns <
> edward.burns(a)oracle.com> wrote:
>
> [...]
>
> EB> section 15.5.15 "Contexts and Dependency Injection for Java EE
> EB> requirements".
>
> EB> The CDI spec is trying to trim itself down [...]
>
> EB> CDI Spec section 3.8 [1] places some requirements on CDI
> implementations
> EB> when running with Servlet. To better suit user desires for modularity
> EB> these requirements are better met by moving them to the Servlet
> EB> spec.
>
> [...]
>
> EB> To put these items in the Servlet spec, we may have to couch them in
> EB> terms similar to, "when running in an environment that also supports
> EB> CDI...".
>
> EB> PROPOSAL:
>
> EB> Include language in our spec section 15.5.15 which allows the CDI spec
> EB> to remove their language while preserving desired existing user
> EB> functionality.
>
> [...]
>
> >>>>> On Thu, 20 Nov 2014 13:47:19 +0000 (UTC), Mark Struberg <
> struberg(a)yahoo.de> said:
>
> MS> I'm not quite sure that it's worth it. The @RequestScoped and
> MS> @SessionScoped are already in the CDI spec package. And as you know
> MS> we must not split packages between different specs.
>
> >>>>> On Thu, 20 Nov 2014 22:32:39 +0100, arjan tijms <
> arjan.tijms(a)gmail.com> said:
>
> AT> I don't think it's about moving those scope annotations, but just
> AT> about the injection of HttpServletRequest, HttpSession and
> AT> ServletContext.
>
> Granted. The proposal does not touch those. Mark was just questioning
> if it was worth it. I am skeptical myself, but am responsive to
> community input.
>
> MS> It would feel quite unnatural to have annotations in the CDI APIs
> MS> but the description in the servlet spec. [...]
>
> I'll trust that Antoine Sabot-Durand (ASD) will take your reservations
> into account when deciding to press on with CDI-492-FobStuffToServlet or
> not.
>
> MS> What we probably could add (regardless whether on CDI or Servlet
> MS> side) is kind of a @WebAppScoped. This is really missing atm. But
> MS> again this must also be active in e.g. JMS invocations which form
> MS> kind a 'logical app'.
>
> That's a whole new thing, again for ASD to consider. As you observe, it
> doesn't belong in Servlet because JMS can also use it.
>
> Ed
>
> --
> | edward.burns(a)oracle.com | office: +1 407 458 0017
>
>
> ------------------------------
>
> _______________________________________________
> 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.
>
> End of cdi-dev Digest, Vol 48, Issue 16
> ***************************************
>
9 years, 5 months
Re: [cdi-dev] [servlet-spec users] [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL
by Mark Struberg
I'm not quite sure that it's worth it. The @RequestScoped and @SessionScoped are already in the CDI spec package. And as you know we must not split packages between different specs.
It would feel quite unnatural to have annotations in the CDI APIs but the description in the servlet spec. Also note that some of those scopes (mostly @RequestScoped) also get used for non-servlet tasks. E.g. java-concurrency-utils threads, @Asynchronous EJBs, JMS invocations, @PostConstruct of @Stateless @Startup beans, etc.
What we probably could add (regardless whether on CDI or Servlet side) is kind of a @WebAppScoped. This is really missing atm. But again this must also be active in e.g. JMS invocations which form kind a 'logical app'.
LieGrue,
strub
> On Wednesday, 19 November 2014, 19:40, Edward Burns <edward.burns(a)oracle.com> wrote:
> > Hello Volunteers,
>
> The Servlet spec PDF currently only mentions CDI on two pages (and one
> of them is a reference to the other). It appears the normative
> declaration of the requirements in Servlet regarding CDI is in our
> section 15.5.15 "Contexts and Dependency Injection for Java EE
> requirements".
>
> The CDI spec is trying to trim itself down and part of that effort
> requires fobbing off some requirements previously declared in the CDI
> spec itself to other related specs. In this case, we have the
> following:
>
> CDI Spec section 3.8 [1] 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,
>
> 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.
>
> To put these items in the Servlet spec, we may have to couch them in
> terms similar to, "when running in an environment that also supports
> CDI...".
>
> PROPOSAL:
>
> Include language in our spec section 15.5.15 which allows the CDI spec
> to remove their language while preserving desired existing user
> functionality.
>
> What do you all think? I know several of our constituents do not count
> CDI support among their user requirements. Is this going to be a
> problem?
>
> Ed
>
> [1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans
>
> --
> | edward.burns(a)oracle.com | office: +1 407 458 0017
>
9 years, 5 months
[JBoss JIRA] (CDI-437) The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-437?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-437:
-------------------------------------
Fix Version/s: 2.0 (discussion)
> The container cannot use the final value of AfterTypeDiscovery.getAlternatives() properly
> -----------------------------------------------------------------------------------------
>
> Key: CDI-437
> URL: https://issues.jboss.org/browse/CDI-437
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> {quote}
> Any observer of this event is permitted to add classes to, or remove classes from, the list of alternatives, list of interceptors or list of decorators. *The container must use the final values of these collections*, after all observers of AfterTypeDiscovery have been called, to determine the order of the enabled alternatives, interceptors, and decorators for application. The initial values of these collections are defined by the @Priority annotation.
> {quote}
> However, the container cannot use the final value of the alternatives collection properly. The problem occurs if an extension adds an alternative class.
> The container can either:
> * use the index from the list -> selected alternatives with the same priority will not cause {{AmbiguousResolutionException}} (this contradicts the spec), or
> * use the original priority, an alternative added by an extension will be selected for an application but without any priority value (this contradicts the spec) -> an extension would not be able to affect the final ordering
> The first option seems to be less harmful.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 5 months