[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-420:
-----------------------------------
With getting more and more feedback for cdi-1.1 and 1.2 in the last 2 years it became clear that the bean-discovery-mode 'annotated' is not or less not used by developers! Simply by the fact that not picking up interfaces and stuff create way too many problems with Extensions. That's why I'm pushing this idea again. I just like to rename the new bean-discovery-mode to 'scoped'.
The behaviour is the following:
1.) Scan all interfaces and classes etc just like with 'all'
2.) Fire the ProcessAnnotatedType event for all of them (just like with 'all')
3.) But for all classes in a jar or classpath entry with bean-diescovery-mode=
scoped' _only_ create Bean<T> of those AnnotatedTypes which either
* have an explicit CDI scope annotation, or
* are an Interceptor or a Decorator, or
* are a JavaEE bean, or
* have a StereoType
This will
* improve boot times
* reduce the memory footprint by not storing away tons of useless Bean<T> instances
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg updated CDI-420:
------------------------------
Summary: add a bean-discovery-mode 'scoped' (was: add a bean-discovery-mode 'detected')
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
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
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-579:
-----------------------------------
[~atijms] It is really a subtle problem. By adding a beans.xml with bd 'none' it would get picked up by CDI-1.0 containers...
> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
> Key: CDI-579
> URL: https://issues.jboss.org/browse/CDI-579
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Mark Struberg
> Priority: Minor
>
> The bean-discovery-wording is a bit odd.
> This has been in since CDI-1.1
> {code}
> 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.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-579:
---------------------------------
I am kind of leaning towards not to change anything. In practice, extension is a special archive. If someone wants beans to be discovered, just explicitly add a beans.xml quite easily, as mentioned by Mark. In this way, it is nice and clear. An extension is normally big as well. If someone wants it to be excluded for bean discovery, people have to add a beans.xml with bean-discovery-mode="none".
> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
> Key: CDI-579
> URL: https://issues.jboss.org/browse/CDI-579
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Mark Struberg
> Priority: Minor
>
> The bean-discovery-wording is a bit odd.
> This has been in since CDI-1.1
> {code}
> 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.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Arjan t commented on CDI-579:
-----------------------------
Was thinking about the following:
Mojarra is normally a container jar. Since it uses CDI there's a CDI extension. Since container jars are not automatically scanned, annotated classes can be added via {{BeforeBeanDiscovery.addAnnotatedType}}.
But Mojarra can also be used from an application archive and put into WEB-INF/lib.
Now it helps that it's not an implicit bean archive, otherwise the same class would be added twice; by the extension and via the scanning process. Probably it would be better to have a beans.xml file with bean-discovery-mode of none, but perhaps this was the use case for the "Extension disqualifies a jar as 'implicit bean archive'" was added?
> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
> Key: CDI-579
> URL: https://issues.jboss.org/browse/CDI-579
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Mark Struberg
> Priority: Minor
>
> The bean-discovery-wording is a bit odd.
> This has been in since CDI-1.1
> {code}
> 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.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-579:
----------------------------------------
[~jharting] yep, that's theory and practise. Servlet spec broke it largely between 3.0 and 3.1 for instance.
> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
> Key: CDI-579
> URL: https://issues.jboss.org/browse/CDI-579
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Mark Struberg
> Priority: Minor
>
> The bean-discovery-wording is a bit odd.
> This has been in since CDI-1.1
> {code}
> 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.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-579:
-------------------------------------
bq. Changing something not used or wrong is fine, even for specs, it is done in most new versions actually.
https://java.net/projects/javaee-spec/pages/CompatibilityRequirements
> Extension disqualifies a jar as 'implicit bean archive'?
> --------------------------------------------------------
>
> Key: CDI-579
> URL: https://issues.jboss.org/browse/CDI-579
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Mark Struberg
> Priority: Minor
>
> The bean-discovery-wording is a bit odd.
> This has been in since CDI-1.1
> {code}
> 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.
> is not a bean archive.
> {code}
> That means even if you have an @ApplicationScoped MyService class in a jar which has a single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least according to this wording?
> Feels mega-weird to me and might conflict with the implicit beans archive definition a few lines below.
> I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months