Re: JSR330 in extensions and plugins, Singleton or not Singleton

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Paul Hammant-3
CDI came after JSR330 I think. I was on the JSR330 experts group. I could
be wrong there.

Back history of dependency injection - it was an antidote to classic GoF
service-locator being used everywhere in Javaland. When we co-created
PicoContainer we were careful to avoid Singleton as a term or idiom for
good within the classbase and documentation. GoF singleton being a sibling
of service locator.  Spring used the term in XML, then later as an
annotation (after Guice used Singleton as an annotation when Java5 kicked
off).  Then JSR330 gets to include it in the set of annotations.

Anyway, I always told readers "single managed instance" was the thing you
were trying to do. That could be one per JVM for a flat classloader design.
Or in a hierarchy of classloaders (Tomcat, Intellij, a stupid Jesktop
<http://jesktop.sourceforge.net/> thing I worked on) it would be one per
meaningful separate part of a tree of classloaders in a JVM.

These days, twice a year I get to give an opinion of a technology in a
language that purports to be DI, but is actually
Container.getInstance().getComponent(<some key>) by various obfuscations
(service locator *not* DI at all).

- Paul
Reply | Threaded
Open this post in threaded view
|

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Tamás Cservenák
When I read "jsr330" (in maven context), I always "replace it" with SISU in
my head, as Maven is SISU powered.
So there is nothing undefined for me, as SISU defines all the "blind spots"
IMO.

Maven, while it may look so, will NOT work with any other JSR330
implementation, just SISU.
Maven 3 was made to work with SISU (or SISU was made to replace Plexus, or
both :)

My five cents.

T

On Fri, Feb 5, 2021 at 12:28 PM Romain Manni-Bucau <[hidden email]>
wrote:

> Issue with JSR330 is that it is a standard "nothing" since it does not
> define any behavior behind the annotations so it is pointless to have this
> standard since all the behavior is vendor dependent and therefore we must
> fix that by a good doc.
> Wonder if we should define more explicitly and not accross 4-5 doc pages
> this.
> Anyone with more knowledge of the plexus migration knows if it is just too
> much hidden and not well linked between these pages or if we have to create
> a ticket to fix it - or even import some sisu doc/highlights?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 5 févr. 2021 à 12:11, Paul Hammant <[hidden email]> a
> écrit :
>
> > CDI came after JSR330 I think. I was on the JSR330 experts group. I could
> > be wrong there.
> >
> > Back history of dependency injection - it was an antidote to classic GoF
> > service-locator being used everywhere in Javaland. When we co-created
> > PicoContainer we were careful to avoid Singleton as a term or idiom for
> > good within the classbase and documentation. GoF singleton being a
> sibling
> > of service locator.  Spring used the term in XML, then later as an
> > annotation (after Guice used Singleton as an annotation when Java5 kicked
> > off).  Then JSR330 gets to include it in the set of annotations.
> >
> > Anyway, I always told readers "single managed instance" was the thing you
> > were trying to do. That could be one per JVM for a flat classloader
> design.
> > Or in a hierarchy of classloaders (Tomcat, Intellij, a stupid Jesktop
> > <http://jesktop.sourceforge.net/> thing I worked on) it would be one per
> > meaningful separate part of a tree of classloaders in a JVM.
> >
> > These days, twice a year I get to give an opinion of a technology in a
> > language that purports to be DI, but is actually
> > Container.getInstance().getComponent(<some key>) by various obfuscations
> > (service locator *not* DI at all).
> >
> > - Paul
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Paul Hammant-3
In reply to this post by Paul Hammant-3
>
> JSR 330 has a TCK that defines a lot. A system that purports to facilitate
> injection into contained components (plugins or lesser) doesn’t have to
> implement all facets of that TCK but could do so out of the box by just
> using (say) guice or dagger in a class loader tree implementation.
Reply | Threaded
Open this post in threaded view
|

Re: JSR330 in extensions and plugins, Singleton or not Singleton

Romain Manni-Bucau
@Paul: not really, none define any behavior (note that the class loader
tree implementation is a vendor choice, several certified EE servers do
handle singleton per tree or per loader of the tree and it is compliant).
Only @inject tests are
https://github.com/eclipse-ee4j/injection-tck/blob/2ef97bfc0439f28730d4d1793f1ef9ff21309450/src/main/java/org/atinject/tck/auto/Convertible.java#L176
which are mainly smoke tests to let vendors handle instances as they want
(proxy or not, eager vs lazy, scope/context definition etc). All that still
leads to the fact that the Maven IoC is not obvious on our doc, no?

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 5 févr. 2021 à 13:55, Paul Hammant <[hidden email]> a
écrit :

> >
> > JSR 330 has a TCK that defines a lot. A system that purports to
> facilitate
> > injection into contained components (plugins or lesser) doesn’t have to
> > implement all facets of that TCK but could do so out of the box by just
> > using (say) guice or dagger in a class loader tree implementation.
>