Getting injection point from Bean#create
by arjan tijms
Hi,
In a producer method it's trivial to get access to an InjectionPoint
instance representing the point where the value produced by the
producer will be injected.
When registering a Bean manually from an extension using
AfterBeanDiscovery#addBean, this is not immediately obvious.
After some fumbling with the CDI APIs I came up with the following
code that seems to work on both Weld and OWB (didn't test CanDI yet).
It uses a small "dummy" class, which is used to grab an InjectionPoint off:
In a Bean:
public Object create(CreationalContext<Object> creationalContext) {
InjectionPoint injectionPoint = (InjectionPoint)
beanManager.getInjectableReference(
resolve(beanManager,
InjectionPointGenerator.class).getInjectionPoints().iterator().next(),
creationalContext
);
With InjectionPointGenerator being the following class:
public class InjectionPointGenerator {
@Inject
private InjectionPoint injectionPoint;
}
And resolve being the following method:
public static <T> Bean<T> resolve(BeanManager beanManager, Class<T> beanClass) {
Set<Bean<?>> beans = beanManager.getBeans(beanClass);
for (Bean<?> bean : beans) {
if (bean.getBeanClass() == beanClass) {
return (Bean<T>)
beanManager.resolve(Collections.<Bean<?>>singleton(bean));
}
}
return (Bean<T>) beanManager.resolve(beans);
}
As mentioned, while this seems to work, I wonder if it's the best approach.
Kind regards,
Arjan
8 years, 10 months
PermGen with JBoss add-on
by Antonio Goncalves
Hi all,
The other day on #IRC I mentioned having PermGen issues with the JBossAS
add-on. It's confirmed. During the HoL there are plenty of people who had
the same issue : install the JBoss add-on, start wildfly 8.1, build the
app, deploy it, go to the index.html page (fine), click on an Entity, bang
! PermGen
Alexis Hassler investigated it during the lab (see below). Basically, no
matter what PermGen you set, it's not taken into account.
Again, I really think this add-on should be looked after carefully, it's
very unstable.
Antonio
---------- Forwarded message ----------
From: Alexis Hassler <alexis.hassler(a)gmail.com>
Date: Tue, Nov 11, 2014 at 11:37 AM
Subject: Re: Forge + Wildfly VM arguments
To: Antonio Goncalves <antonio.goncalves(a)gmail.com>
Pas de changement avec
as-setup --server wildfly8 --installDir /opt/java/wildfly-8.1.0.Final/
--jvmargs "-Xmx512m -XX:MaxPermSize=256m"
Alexis
http://www.jtips.info, http://blog.alexis-hassler.com,
http://www.lyonjug.org
2014-11-11 11:22 GMT+01:00 Alexis Hassler <alexis.hassler(a)gmail.com>:
> Avec un wf externe, démarré avec as-start.
>
>
>
>
> Pour info, en démarrant un wf 8.1 en ligne de commande "normale" :
> -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m
> -Djava.net.preferIPv4Stack=true
> -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> -Dorg.jboss.boot.log.file=/opt/java/wildfly-8.1.0.Final/standalone/log/server.log
> -Dlogging.configuration=file:/opt/java/wildfly-8.1.0.Final/standalone/configuration/logging.properties
>
> Alexis
> http://www.jtips.info, http://blog.alexis-hassler.com,
> http://www.lyonjug.org
>
>
--
Antonio Goncalves
Software architect, Java Champion and Pluralsight author
Web site <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
10 years
microbenchmark for CDI performance
by Mark Struberg
Hi!
Weld folks, I need some help with a micro benchmark:
You know we've talked about disk footprint in SE, so I hacked together a small microbenchmark and as a side effect we also got what is really needed to have CDI running
https://github.com/struberg/cdi-performance
I'm curious about missing some dependency excludes for Weld.
could you please run
$> mvn clean dependency:copy-dependencies -DincludeScope=compile -PWeld -Dweld.version=2.2.5.Final
$> ls -al target/dependency/
and tell me which dependencies can be without having some CDI functionality missing?
Feel free to pimp the pom and ship a pull request.
txs and LieGrue,
strub
10 years
Re: [cdi-dev] Feedback from Devoxx
by Werner Keil
> BTW, looks like Bob Lee is active because I can see he is planned to be in
>the expert group of Java Platform Module System
Just because he's listed to support it means nothing. AFAIK he was in one
of the prior JSRs like Jigsaw that went dormant eventually. And he
officially was in the EG of JSR 354 because he used to work for Square and
they seemed interested in financial services, but he never contributed
anything (Anatole also considered re-allocating him to Observer due to that)
Werner Keil | JCP Executive Committee Member, JSR 363 Co Spec Lead |
Eclipse UOMo Lead, Babel Language Champion | Apache Committer | DWX 15
Advisory Board Member
Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | #Java_Social |
#DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil
On Thu, Nov 27, 2014 at 8:01 AM, <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. [JBoss JIRA] (CDI-493) Allow firing of generic events from
> BeanManager (Sven Linstaedt (JIRA))
> 2. [JBoss JIRA] (CDI-493) Allow firing of generic events from
> BeanManager (Sven Linstaedt (JIRA))
> 3. [JBoss JIRA] (CDI-493) Allow firing of generic events from
> BeanManager (Sven Linstaedt (JIRA))
> 4. [JBoss JIRA] (CDI-492) Give ownership of servlet specific
> part to servlet specification (Antoine Sabot-Durand (JIRA))
> 5. Async event API (Antoine Sabot-Durand)
> 6. Re: Feedback from Devoxx (Antonio Goncalves)
>
>
> ----------------------------------------------------------------------
>
>
> Message: 6
> Date: Thu, 27 Nov 2014 08:00:42 +0100
> From: Antonio Goncalves <antonio.goncalves(a)gmail.com>
> Subject: Re: [cdi-dev] Feedback from Devoxx
> To: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CA+ZZq9_hcm7pqGhLPe2ewAOho-=
> ukyYk-nqUUXCOJDzL+7Q6FA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> BTW, looks like Bob Lee is active because I can see he is planned to be in
> the expert group of Java Platform Module System
>
> https://jcp.org/en/jsr/detail?id=376
>
> Antonio
>
> On Mon, Nov 17, 2014 at 2:57 PM, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> wrote:
>
> > Hi all,
> >
> > Just to give you a small feedback of my Devoxx week regarding CDI and CDI
> > 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
> >
> > 1) Great expectations:
> > I?m not going to state the obvious, but end user and other specs are
> > watching us and expect a lot from CDI 2.0 (the question of total EJB
> > replacement came more than once)
> >
> > 2) Antonin Stefanutti and myself delivered a very valuable content in our
> > CDI advanced university. I don?t remember being so proud of a talk
> material
> > I released before. I encourage you to give it an eye and use it if you
> > want. you can watch it on Slideshare [1] or grab the source slides on
> > Antonin?s Github repo [2]
> >
> > 3) Other spec are really willing to have a better integration.
> > I met JMS, Servlet, JSF and MVC spec leaders, they all are looking for a
> > better integration with CDI and are ok to take CDI specific part related
> to
> > their spec back in their spec (Servlet and JSF mostly). Working with them
> > will bring a more consistent Java EE and will reduce extra code from the
> > spec.
> >
> > 4) After months of discussion I finally met Jurgen Hoeller (Spring
> > Framework) and Christian Gruber (Dagger and Guice) and we all agreed on a
> > new version or MR of AtInject spec. Juergen will probably be the spec
> lead
> > and we hope to have the big work done before mid 2015 (cross finger) to
> met
> > our various agenda. That will probably add extra work for CDI 2.0 but
> will
> > bring clarity and a good signal to the community. Thanks to Antonio who
> > helped me on this.
> > For those who remember the history of JSR 330 and JSR 299 the following
> > picture will be nearly an historical one ;) [3]
> >
> >
> > Antoine
> >
> > [1] http://www.slideshare.net/antoinesd/going-further-with-cdi-41411812
> > [2] https://github.com/astefanutti/further-cdi
> > [3] http://twitter.com/antoine_sd/status/533710069255667712/photo/1
> > _______________________________________________
> > 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.
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | LinkedIn <
> http://www.linkedin.com/in/agoncal> |
> Pluralsight
> <http://pluralsight.com/training/Authors/Details/antonio-goncalves> |
> Paris
> JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20141127/1438ac37/at...
>
> ------------------------------
>
> _______________________________________________
> 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 19
> ***************************************
>
10 years
Feedback from Devoxx
by Antoine Sabot-Durand
Hi all,
Just to give you a small feedback of my Devoxx week regarding CDI and CDI 2.0 (for the rest, what happens in Devoxx stays in Devoxx ;) )
1) Great expectations:
I’m not going to state the obvious, but end user and other specs are watching us and expect a lot from CDI 2.0 (the question of total EJB replacement came more than once)
2) Antonin Stefanutti and myself delivered a very valuable content in our CDI advanced university. I don’t remember being so proud of a talk material I released before. I encourage you to give it an eye and use it if you want. you can watch it on Slideshare [1] or grab the source slides on Antonin’s Github repo [2]
3) Other spec are really willing to have a better integration.
I met JMS, Servlet, JSF and MVC spec leaders, they all are looking for a better integration with CDI and are ok to take CDI specific part related to their spec back in their spec (Servlet and JSF mostly). Working with them will bring a more consistent Java EE and will reduce extra code from the spec.
4) After months of discussion I finally met Jurgen Hoeller (Spring Framework) and Christian Gruber (Dagger and Guice) and we all agreed on a new version or MR of AtInject spec. Juergen will probably be the spec lead and we hope to have the big work done before mid 2015 (cross finger) to met our various agenda. That will probably add extra work for CDI 2.0 but will bring clarity and a good signal to the community. Thanks to Antonio who helped me on this.
For those who remember the history of JSR 330 and JSR 299 the following picture will be nearly an historical one ;) [3]
Antoine
[1] http://www.slideshare.net/antoinesd/going-further-with-cdi-41411812
[2] https://github.com/astefanutti/further-cdi
[3] http://twitter.com/antoine_sd/status/533710069255667712/photo/1
10 years
[JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-492:
------------------------------------------
[~edburns] I understand those concerns, but I think there are solution for most of them. The points given don't take into account evolutions that could be done in CDI and JSR 330 to make it possible.
To take all the points and give first ideas to solve them :
*backward compatibility* : introducing a qualifier for these beans (like it's done in Deltaspike to work with CDI 1.0 and 1.1) is a first lead like {{@Servlet}} to tell that these beans are owned by Servlet spec.
*Dependency on CDI* ; as you know we're going to work on a new AtInject version. We could imagine having the servlet impl only be dependent on AtInject (which will stay very small : around 10 interfaces / annotations). The only thing that is missing in AtInject today is the concept of {{@Producer}} that could be added to this new version (dagger want to move its {{@Provides}} annotation to AtInject.
The integration can off course be done at spec level (the worse case would be to have a dependency on CDI API). So I really don't understand Greg point.
For CDI 2.0 our approach is to talk with other specs to see what they need to improve their CDI integration. So let's talk about these needs before deciding it's not doable.
> 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)
10 years
[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 commented on CDI-493:
------------------------------------
Jozef Hartinger already mentioned something similar in [1], but I guess this was just forgotten.
[1] https://issues.jboss.org/browse/CDI-169?focusedCommentId=12637565&page=co...
> 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 firing 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)
10 years
[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:
-------------------------------
Description:
Currently we are allowed firing 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}
was:
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}
> 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 firing 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)
10 years
