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

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

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

Matthieu BROUILLARD-3
Hum some words have disappeared from my previous mail.
The project URL is https://github.com/McFoggy/maven-jsr330-demo
<https://github.com/McFoggy/maven-jsr330-demoYou>.
And the corrected sentence is: You will see that the project is simple...
Sorry for the double post.


On Thu, Feb 4, 2021 at 9:27 PM Matthieu Brouillard <[hidden email]>
wrote:

> Hi all,
>
> As I was trying to cleanup & simplify my plugins by moving to JSR330, I
> came across a weird use case in which a `@Singleton` object exists multiple
> times (several instances) during the build:
> - it is first used by an extension, to store some value
> - then used in a mojo to retrieve and print the value
>
> Before opening an issue, I wanted to be sure that I did not make some
> errors in the simplified project and that my expectations of how it should
> work are OK.
>
> I pushed a simplified project with README here:
> https://github.com/McFoggy/maven-jsr330-demoYou will that the project is
> simple:
> - the @Singleton information store
> - the extension filling the store
> - the mojo
>
> Thanks for any enlightenment.
>
> PS: can the issue come from different classloaders being probably used?
>
> Matthieu
>
Reply | Threaded
Open this post in threaded view
|

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

Paul Hammant-3
OK, my bad, I thought we were talking about Maven's internals for itself.

Classloader trees, hidden implementations, security policies for the JVM
are stand out features that they nailed in 1995/6/7.

I once drew a pretty pic of Tomcat's classloader setup -
https://paulhammant.com/images/tomcat_classloader.jpg - not from
actually knowledge, but from "that's how I would do it"

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

> @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.
> >
>