[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 edited comment on CDI-420 at 5/4/16 8:36 AM:
-----------------------------------------------------------
As already clarified with [~antoinesabot-durand] it is not possible to amend the behaviour of "annotated".
But it actually *only* provides a benefit for bean-discovery-mode="all" as you will _not_ get interfaces etc for ProcessAnnotatedType if you use "annotated". Thus this new flag only makes sense in combination with "all". Which makes it basically an own sub-flavour and thus it's really the same like introducing a new bean-discovery-mode in the end.
was (Author: struberg):
As already clarified with [~antoinesabot-durand] it is not possible to amend the behaviour of "annotated".
But it also provides a benefit for "all" as you will _not_ get interfaces etc for ProcessAnnotatedType if you use "annotated". Thus this new flag only makes sense in combination with "all". Which makes it basically an own sub-flavour and thus it's really the same like introducing a new bean-discovery-mode in the end.
> 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)
7 years, 11 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:
-----------------------------------
As already clarified with [~antoinesabot-durand] it is not possible to amend the behaviour of "annotated".
But it also provides a benefit for "all" as you will _not_ get interfaces etc for ProcessAnnotatedType if you use "annotated". Thus this new flag only makes sense in combination with "all". Which makes it basically an own sub-flavour and thus it's really the same like introducing a new bean-discovery-mode in the end.
> 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)
7 years, 11 months
CDI-508 - Which java classes can be managed beans
by John D. Ament
All,
I think I had an action item to get this clarified, not 100% sure, but let
me give this a shot.
Tomas raised a PR for CDI-508 to clarify which classes are meant to be
managed beans. You can find that PR here:
https://github.com/cdi-spec/cdi/pull/282/
The line that doesn't sound right to me in the change is to go from:
It is not a non-static inner class.
to
It is not a non-static nested class.
I'll use the java programming language tutorial as a point of reference,
you can read the page I'll refer to here:
https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
Basically, non-static nested classes are AKA inner classes. The term
"non-static inner class" shouldn't exist, and that means the original text
doesn't make sense, and should probably be inferred as "It is not an inner
class"
>From reading this part of the spec, it becomes unreadable due to the double
negative (probably why the aka exists). My proposal was to change the line
to instead read (in a positive way) "It is a static nested class" but I can
also understand if we want to do this in an exclusion pattern rather than
an inclusion pattern.
Thoughts?
John
7 years, 11 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-420:
-----------------------------------
I agree with adding either a tag or an attribute. It is IMHO not worth a whole new mode as it is pretty much similar to "annotated" one.
Which leads me to a question. [~struberg] did you really mean to add a sample with {{<beans bean-discovery-mode="all"}}? I agree with Martin that it would fit better to the {{annotated}} type.
> 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)
7 years, 11 months
New builders API
by John D. Ament
Hey guys
Based on the last f2f I was in, I took an action item to look at how
applications can leverage the new builder methods/classes from this PR:
https://github.com/cdi-spec/cdi/pull/287
To do this, I took some existing OSS CDI extensions and converted parts to
use the new APIs instead of the old ones.
The results were iffy to be honest. Here's some of the key issues I
noticed:
- AfterBeanDiscovery#addBean - vs AfterBeanDiscovery.addBean(Bean<?> bean)
In the latter, it's clearer to a developer which attributes are required vs
optional. Builders typically use sensible defaults. Maybe that was the
intention here, but I couldn't really get that sense when converting over.
It also wasn't clear what to do when done. I suspect I just leave it, but
without some kind of closing "build()" or "done()" method, it becomes
ambiguous.
- Annotated*Configurator
TBH, I have no idea what I was configuring in this one at the first pass.
I started with a method. I wanted to replace the method's annotations. It
seemed like I could set that up using the configurator, but I ended up
having to do setAnnotated at the end anyways, so I'm not sure what the
configurator bought me.
The one nice thing I saw was the simpler to use lambda functions. Being
able to stream through things like annotated method made the code much
cleaner.
For the open source code, I'll try to get some gists together that show the
changes. Maybe there's something I'm missing, so wouldn't mind a second
set of eyes on the changes to see.
John
7 years, 11 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-420:
----------------------------------
So you would basically allow to "tweak" one of the existing bean discovery mode. If so I think we should tweak the {{annotated}} mode. Having a separate tag/attribute is not very nice (it's rather confusing) but it seems better than adding a new bean discovery mode which is almost identical to {{annotated}}.
> 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)
7 years, 11 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 edited comment on CDI-420 at 5/4/16 5:37 AM:
-----------------------------------------------------------
We had an additional idea in a recent discussion: Keep the current bean-discovery-modes but adding another beans.xml tag or attribute in addition to bean-discovery-mode which enables this functionality.
Examples:
{code}
<beans bean-discovery-mode="all" auto-dependent="false">
</beans>
{code}
or
{code}
<beans bean-discovery-mode="all">
<auto-dependent>false</auto-dependent>
</beans>
{code}
Of course we need to discuss
a.) whether it should be an attribute or tag
b.) the name of the attribute or tag
c.) if the logic should be 'disabling' (auto-dependent="false") or 'enabling' (only-scoped-beans="true")
was (Author: struberg):
We had an additional idea in a recent discussion: Keep the current bean-discovery-modes but adding another beans.xml tag or attribute in addition to bean-discovery-mode which enables this functionality.
Examples:
{quote}
<beans bean-discovery-mode="all" auto-dependent="false">
</beans>
{quote}
or
{quote}
<beans bean-discovery-mode="all">
<auto-dependent>false</auto-dependent>
</beans>
{quote}
Of course we need to discuss
a.) whether it should be an attribute or tag
b.) the name of the attribute or tag
c.) if the logic should be 'disabling' (auto-dependent="false") or 'enabling' (only-scoped-beans="true")
> 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)
7 years, 11 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:
-----------------------------------
We had an additional idea in a recent discussion: Keep the current bean-discovery-modes but adding another beans.xml tag or attribute in addition to bean-discovery-mode which enables this functionality.
Examples:
{quote}
<beans bean-discovery-mode="all" auto-dependent="false">
</beans>
{quote}
or
{quote}
<beans bean-discovery-mode="all">
<auto-dependent>false</auto-dependent>
</beans>
{quote}
Of course we need to discuss
a.) whether it should be an attribute or tag
b.) the name of the attribute or tag
c.) if the logic should be 'disabling' (auto-dependent="false") or 'enabling' (only-scoped-beans="true")
> 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)
7 years, 11 months
[JBoss JIRA] (CDI-457) Clarify how to properly create and destroy dependent instances
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-457?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-457:
----------------------------------
[~meetoblivion] Please don't change the description of an issue if the discussion already started - this makes the discussion less understandable.
And no, {{@TransientReference}} can be only applied to a parameter injection point - @Dependent scoped contextual instances injected into this parameters is destroyed when the invocation completes.
> Clarify how to properly create and destroy dependent instances
> --------------------------------------------------------------
>
> Key: CDI-457
> URL: https://issues.jboss.org/browse/CDI-457
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Reporter: John Ament
> Assignee: John Ament
>
> Using @TransientReference today for class definitions allows you to mark it as dependent.
> We should allow arbitrary producers to include transient references.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months