[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-420:
---------------------------------
+1
> 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
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> 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)
7 years, 7 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 commented on CDI-420:
-----------------------------------
2 weeks passed and no better idea. So I assume that we stick with:
{code}
<beans>
<trim/>
</beans>
{code}
In which case I would love to add this to DeltaSpike and do some advanced testing with it. I will add this to OWB and I assume Martin will also enhance Weld to support it. In which case we have already get very good feedback from real world projects.
> 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
> Labels: F2F2016
> Fix For: 2.0 (proposed)
>
>
> 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)
7 years, 7 months
proxy unwrapping
by Mark Struberg
Hi!
I found another one who did similar things than I did:
7 years, 7 months
[JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-633:
------------------------------------
[~manovotn] Not completely: {{javax.enterprise.event.Event<T>}} is meant for application driven event triggering. In order to narrow down the event type, you can either specify a {{java.lang.Class<T>}} or a for generics a {{javax.enterprise.util.TypeLiteral<U>}}.
As an extension developer, {{Event<T>}} is not sufficient as you can neither
# resolve {{Event<T>}} before{{AfterDeploymentValidation}} nor
# narrow down the event type by an extension-resolved {{java.lang.reflect.Type}}, which can not be hardcoded using {{TypeLiteral<U>}} as the static type is not known to the extension and TypeLiteral was not meant for being created out of some unknown {{Type}}.
So there is still a need for extending the existing method {{BeanManager#fire}} and of course keeping it backwards compatible as mentioned in CDI-493.
> Intoroduce BeanManager.event()
> ------------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-633:
-----------------------------------
[~tzwoenn] what you describe is what this proposal solves. {{BeanManager#fire}} cannot handle narrowing and does not allow to fire events asynchronously - and we cannot change that because of the famous backward compatibility.
Having {{BeanManager#event}} as a new method on BM will grant you acces to {{Event<Object>}} where you can narrow the type with {{select(...)}} and then {{fire()}} or {{fireAsync}}.
> Intoroduce BeanManager.event()
> ------------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Sven Linstaedt (JIRA)
[ https://issues.jboss.org/browse/CDI-633?page=com.atlassian.jira.plugin.sy... ]
Sven Linstaedt commented on CDI-633:
------------------------------------
For the current more extension-related BeanManager API ({{BeanManager#fire}}), which is not capable of handling event type narrowing by a specific {{java.lang.reflect.Type}}, a similar solution would be nice too.
> Intoroduce BeanManager.event()
> ------------------------------
>
> Key: CDI-633
> URL: https://issues.jboss.org/browse/CDI-633
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> * this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
> * the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (CDI-633) Intoroduce BeanManager.event()
by Martin Kouba (JIRA)
Martin Kouba created CDI-633:
--------------------------------
Summary: Intoroduce BeanManager.event()
Key: CDI-633
URL: https://issues.jboss.org/browse/CDI-633
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Martin Kouba
* this would allow to define the _specified type_ - the container may use the specified type to infer the parameterized type of the event types
* the method should return {{javax.enterprise.event.Event<Object>}} with no qualifiers
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE
by Stephan Knitelius (JIRA)
[ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.sy... ]
Stephan Knitelius commented on CDI-632:
---------------------------------------
I am not a fan of implicit bean archives, but wouldn't it be better if SE worked the same?
> Possible conflict for Implicit bean archive definition between core and SE
> --------------------------------------------------------------------------
>
> Key: CDI-632
> URL: https://issues.jboss.org/browse/CDI-632
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR2
> Reporter: Antoine Sabot-Durand
> Priority: Minor
>
> Section 12.1 (which should be satisfied in SE an EE) states:
> bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations.
> And section 15.1 reads:
> {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that :
> An archive which doesn’t contain a beans.xml file can’t be discovered as an implicit bean archive unless:
> * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or
> * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote}
> Perhaps this deserve a bit of clarification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-632:
-------------------------------------
Priority: Minor (was: Major)
> Possible conflict for Implicit bean archive definition between core and SE
> --------------------------------------------------------------------------
>
> Key: CDI-632
> URL: https://issues.jboss.org/browse/CDI-632
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR2
> Reporter: Antoine Sabot-Durand
> Priority: Minor
>
> Section 12.1 (which should be satisfied in SE an EE) states:
> bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations.
> And section 15.1 reads:
> {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that :
> An archive which doesn’t contain a beans.xml file can’t be discovered as an implicit bean archive unless:
> * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or
> * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote}
> Perhaps this deserve a bit of clarification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
