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

[Stuart McCulloch]

Here's a quick patch that does the split:
https://gist.github.com/mcculls/d22f01b0e380fdd9f9e2ac1e1bba7dd0

With these changes I get the following output:

mvn validate
[INFO] extension generated information: Build started at 1612479700634
[INFO] Scanning for projects...
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building maven demo 0
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] --- maven-demo-mojo:0:info (demo) @ maven-demo ---
[INFO] Information: Build started at 1612479700634
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 0.108 s
[INFO] Finished at: 2021-02-04T23:01:40Z
[INFO] Final Memory: 9M/309M
[INFO]
------------------------------------------------------------------------


On Thu, 4 Feb 2021 at 22:46, Stuart McCulloch <[hidden email]> wrote:

> Yes it's down to classloading - the extension and plugin have different
> classloaders and the InfoHolder class loaded by the extension is different
> to the one loaded by the plugin. They may share the same name and have the
> same original bytecode, but they were defined by different classloaders.
> You can see this by adding a constructor to InfoHolder and printing out its
> classloader (you can also print the class' hashcode to show it really is a
> different class, just with the same name.)
>
> To share the extension class with the plugin you'll need to add an
> extension descriptor to the jar:
>
>    https://maven.apache.org/ref/3.6.0/maven-core/extension.html
>
> But you'll also need to solve a second issue which comes down to the fact
> you're using the same jar as an extension and a plugin - the component
> metadata is going to be registered in both places, which will still lead to
> two separate copies (each component will be a singleton in its own 'realm'
> governed by the component metadata.)
>
> I would recommend using two separate projects - one for the extension and
> one for the plugin. The extension project will have the component and
> the extension descriptor, while the plugin project will just have the mojo
> and depend on the extension project.
>
>
> On Thu, 4 Feb 2021 at 20:40, Matthieu Brouillard <[hidden email]>
> wrote:
>
>> 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
>> >
>>
>

[Romain Manni-Bucau]

In CDI there is a definition which sounds like "an instance is a singleton
in its context", context being the bean lookup definition.
In maven it means calling Guice for current ClassRealm (the classloader of
currently executed component - plugin for ex) so it matches.
Long story short "singleton" concept never exists, it is always a singleton
under some restrictions ;).

That said I wonder when an extension has mojo if the mojos shouldnt inherit
from the extension classloader, it seems quite legitimate and I don't think
forcing to do 2 modules is a solution (but it is clearly a workaround as of
today).

Wdyt?

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 à 11:47, Tamás Cservenák <[hidden email]> a
écrit :

> Just add few cents to Stuart superb answer:
> the singleton scope depends on the "realm" (no idea how to call it better)
> where it is singleton, as the "lifespan" of realm may not be same/aligned.
> Core and Core Extension lifespan vs Mojo/Plugin lifespan is clearly not the
> same...
>
> Also, take a peek at maven classloading here
> http://takari.io/book/91-maven-classloading.html
>
>
> On Fri, Feb 5, 2021 at 10:40 AM Matthieu Brouillard <
> [hidden email]>
> wrote:
>
> > Thank you Stuart for the detailed reply.
> >
> > On Fri, Feb 5, 2021 at 12:02 AM Stuart McCulloch <[hidden email]>
> > wrote:
> >
> > > Here's a quick patch that does the split:
> > > https://gist.github.com/mcculls/d22f01b0e380fdd9f9e2ac1e1bba7dd0
> > >
> > > With these changes I get the following output:
> > >
> > > mvn validate
> > > [INFO] extension generated information: Build started at 1612479700634
> > > [INFO] Scanning for projects...
> > > [INFO]
> > > [INFO]
> > >
> ------------------------------------------------------------------------
> > > [INFO] Building maven demo 0
> > > [INFO]
> > >
> ------------------------------------------------------------------------
> > > [INFO]
> > > [INFO] --- maven-demo-mojo:0:info (demo) @ maven-demo ---
> > > [INFO] Information: Build started at 1612479700634
> > > [INFO]
> > >
> ------------------------------------------------------------------------
> > > [INFO] BUILD SUCCESS
> > > [INFO]
> > >
> ------------------------------------------------------------------------
> > > [INFO] Total time: 0.108 s
> > > [INFO] Finished at: 2021-02-04T23:01:40Z
> > > [INFO] Final Memory: 9M/309M
> > > [INFO]
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > > On Thu, 4 Feb 2021 at 22:46, Stuart McCulloch <[hidden email]>
> wrote:
> > >
> > > > Yes it's down to classloading - the extension and plugin have
> different
> > > > classloaders and the InfoHolder class loaded by the extension is
> > > different
> > > > to the one loaded by the plugin. They may share the same name and
> have
> > > the
> > > > same original bytecode, but they were defined by different
> > classloaders.
> > > > You can see this by adding a constructor to InfoHolder and printing
> out
> > > its
> > > > classloader (you can also print the class' hashcode to show it really
> > is
> > > a
> > > > different class, just with the same name.)
> > > >
> > > > To share the extension class with the plugin you'll need to add an
> > > > extension descriptor to the jar:
> > > >
> > > >    https://maven.apache.org/ref/3.6.0/maven-core/extension.html
> > > >
> > > > But you'll also need to solve a second issue which comes down to the
> > fact
> > > > you're using the same jar as an extension and a plugin - the
> component
> > > > metadata is going to be registered in both places, which will still
> > lead
> > > to
> > > > two separate copies (each component will be a singleton in its own
> > > 'realm'
> > > > governed by the component metadata.)
> > > >
> > > > I would recommend using two separate projects - one for the extension
> > and
> > > > one for the plugin. The extension project will have the component and
> > > > the extension descriptor, while the plugin project will just have the
> > > mojo
> > > > and depend on the extension project.
> > > >
> > > >
> > > > On Thu, 4 Feb 2021 at 20:40, Matthieu Brouillard <
> > [hidden email]
> > > >
> > > > wrote:
> > > >
> > > >> 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
> > > >> >
> > > >>
> > > >
> > >
> >
>

[Romain Manni-Bucau]

@Tamas, right but this page https://maven.apache.org/maven-jsr330.html does
say the opposite for example, this is why I think we should create a ticket
to revise the doc which is misleading as of today

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:43, Tamás Cservenák <[hidden email]> a
écrit :

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

[Romain Manni-Bucau]

Guess we can do something like that or more js like
http://tomee.apache.org/developer/classloading/index.html but specific to
maven, mojo classloading is almost obvious but core and extension ones are
not IMHO.
Then we can just mention that for the IoC + it uses Guice with a custom
registration impl.

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

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