Hmm, not sure it is a good example, plugins do play IoC game already and is the cleanest way to move forward otherwise you will leak the counter or need to play with thread locals which is worse for plugins using this pattern (will forbid plugins to use threads).
That said you can still replace all this code by anything you want, even an IoC lookup and call using a classfiletransformer in ClassRealm plugin classloader. It is just a way to rewrite original code to something else. Le sam. 14 mars 2020 à 17:59, Enrico Olivelli <[email protected]> a écrit : > Il giorno sab 14 mar 2020 alle ore 17:53 Romain Manni-Bucau > <[email protected]> ha scritto: > > > > Assuming maven core/boot is components, a component registry can > instrument > > plugins and subclassloaders with classfiletransformers so maybe ok to > keep > > it in the IoC. > > Romain, > can please you elaborate more ? > > I am thinking this this case: > > class MyCoolCache { > private static final Counter counter = > MetricsSystem.getCounter("cacheHits"); > public T get(K key) { > .... counter.increment(); > } > } > > I am a developer of a plugin and I want to set some metric to see the > runtime behaviour of my component, I don't want my class to play the > IoC game > > You can see it like a "Logger". Loggers are not subject to IoC because > usually you may want a Logger absolutely everywhere and without > changing/refactoring your code. > If I want to add a "temporary" metric I don't want to need to change > constructors, add getters/setters.... > > > Enrico > > > > > Le sam. 14 mars 2020 à 15:14, Enrico Olivelli <[email protected]> a > > écrit : > > > > > I am starting this work. > > > I have pushed a copy of current maven core master to maven-studies. > > > > > > Then I have added my "maven-metrics" module. > > > This module contains only the API to be implemented by Metrics > > > Providers and a No-op implementation. > > > > > > You can find the draft API here. > > > > https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics > > > > > > It is not final it is just the first import to git, I have to see some > > > real world Maven cases before designing the final one. > > > > > > Now I am going to instrument some Maven core subsystem and implement a > > > simple Metrics Provider in order to see some data. > > > > > > My very first problem is to boot the MetricsProvider and to give > > > access to it from any Java class and module. > > > Maven uses Dependency Injection and this is cool, but with this > > > approach you will not be able to instrument non-component classes, > > > like internal Caches or Network facilities. > > > > > > I am leaning towards using some kind of "global static reference" > > > (like a pure Java Singleton) to hold a reference to the Metrics > > > subsystem. > > > > > > By default the Metrics Provider will be the No-op implementation, so > > > third party tools won't see NULLs. > > > > > > in MavenCli I will "boot" (and manage the whole lifecycle) the Metrics > > > Provider and set this "global reference". > > > > > > The Metrics Provider API will be in the main Maven classloader and the > > > Metrics Provider will have to be loaded in the same > > > context/classloader. > > > Plugins and internal classes will use the API and not directly the > > > provider implementation. > > > I don't know how classloading works very well in the case of > Maven/Plexus. > > > > > > Any suggestion is very appreciated. > > > > > > I have very very limited time for this work, but I see value and I > > > will move forward when I have cycles > > > > > > Cheers > > > > > > Enrico > > > > > > > > > > > > Il giorno ven 31 gen 2020 alle ore 00:27 <[email protected]> ha > > > scritto: > > > > > > > > maven-studies looks like the right location: > > > > https://github.com/apache/maven-studies > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > ----- Mail original ----- > > > > De: "Enrico Olivelli" <[email protected]> > > > > À: "Maven Developers List" <[email protected]> > > > > Envoyé: Jeudi 30 Janvier 2020 04:31:14 > > > > Objet: Re: Maven Runtime Metrics > > > > > > > > I sound like to draft a prototype. > > > > > > > > Any suggestion about which repository should contain this new Metrics > > > API? > > > > > > > > > > > > Enrico > > > > > > > > Il Mar 28 Gen 2020, 13:54 Romain Manni-Bucau <[email protected]> > ha > > > > scritto: > > > > > > > > > technically we can shade microprofile, metrics/dropwizard or even > > > sirona > > > > > but maven requires quite a different model. A typical example is > the > > > expiry > > > > > or weighted model will not fit the reporting maven needs (very long > > > running > > > > > instances vs "batch" like executions) and the weighted impl can be > an > > > issue > > > > > but is spec-ed by MP (so the shaded impl would also have this > > > unexpected > > > > > impl) > > > > > > > > > > What about by just adding counters, enabling to inject them in > mojos - > > > > > maybe with a qualifier? - and then see if we need to move to > something > > > more > > > > > widely used or not (but my past experiences kind of tend to show > it is > > > not > > > > > needed). > > > > > > > > > > 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 mar. 28 janv. 2020 à 13:42, Enrico Olivelli < > [email protected]> a > > > > > écrit : > > > > > > > > > > > Il Mar 28 Gen 2020, 13:30 Lennart Jörelid < > [email protected]> > > > ha > > > > > > scritto: > > > > > > > > > > > > > Would it be possible to use an existing standard for the > > > specification > > > > > of > > > > > > > such a metrics API? > > > > > > > > > > > > > > > > > > > In my opinion we should have our own model, Maven will impose > this > > > new > > > > > API > > > > > > to plugins and we cannot depend on third party tools as Romain > also > > > said > > > > > > > > > > > > Okay for annotations > > > > > > > > > > > > Enrico > > > > > > > > > > > > Something like a shaded version of Microprofile Metrics, where > the > > > API > > > > > can > > > > > > > consist entirely of Annotations. > > > > > > > (There are programmatic approaches as well, but I suppose we > are > > > > > > interested > > > > > > > in limiting the footprint of metrics within the Maven codebase > as > > > much > > > > > as > > > > > > > possible). > > > > > > > > > > > > > > ... implying, of course, that we would need to make a > > > Maven-specific > > > > > > > implementation as discussed above. > > > > > > > > > > > > > > On Tue, Jan 28, 2020 at 10:17 AM Enrico Olivelli < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau < > > > > > > > > [email protected]> ha scritto: > > > > > > > > > > > > > > > > > +1 generally since all extensions doing that report wrong > data > > > > > > > > > -1 to use a mainstream impl if not shaded - it would just > > > bring us > > > > > > new > > > > > > > > > conflicts i think. > > > > > > > > > > > > > > > > > > > > > > > > > Totally agree. > > > > > > > > In my view any "impl" will be plugged with an "extension". > > > > > > > > We will provide only a default no-op implementation > > > > > > > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Side note being: we can start we just counters so no lib is > > > fine > > > > > > imho. > > > > > > > > > > > > > > > > > > Le mar. 28 janv. 2020 à 08:56, Enrico Olivelli < > > > > > [email protected]> > > > > > > a > > > > > > > > > écrit : > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I would like to work on introducing an explicit support > in > > > Maven > > > > > > Core > > > > > > > > for > > > > > > > > > > recording "metrics". > > > > > > > > > > As far as I know (and I have still limited knowledge > about > > > the > > > > > > > > internals) > > > > > > > > > > you can write an "extension" and you can intercept main > > > lifecycle > > > > > > > > events, > > > > > > > > > > and using these hooks you can try to record metrics. > > > > > > > > > > But my proposal is from another point of view and I want > to > > > go > > > > > > > deeper. > > > > > > > > > > > > > > > > > > > > We are adding caches, making refactors....all good > things, > > > but we > > > > > > > > should > > > > > > > > > > have a way to track how Maven is behaving in a measurable > > > manner. > > > > > > > > > > > > > > > > > > > > Usually in order to capture realtime metrics you are > using > > > some > > > > > > > Metrics > > > > > > > > > > framework, like Prometheus, Dropwizards....and you attach > > > your > > > > > > > process > > > > > > > > > to a > > > > > > > > > > metrics database and capture all of the values. > > > > > > > > > > Then you can process all of the data, realtime and/or > > > offline, > > > > > you > > > > > > > can > > > > > > > > > > create dashboards, you can also fine tune your > configuration > > > or > > > > > > > change > > > > > > > > > your > > > > > > > > > > code. > > > > > > > > > > > > > > > > > > > > These frameworks deal with time series created by > capturing > > > > > > > Counters, > > > > > > > > > > Summaries, Gauges. > > > > > > > > > > > > > > > > > > > > I would like to introduce an API to be used by Maven Core > > > and by > > > > > > > Plugin > > > > > > > > > to > > > > > > > > > > expose internal metrics, like: > > > > > > > > > > - internal caches size > > > > > > > > > > - memory usage > > > > > > > > > > - disk reads/writes > > > > > > > > > > - network traffic > > > > > > > > > > - any kind of specific metric for plugins (like "number > of > > > tests > > > > > > > > > executed", > > > > > > > > > > "number of files sent to javac...") > > > > > > > > > > - .... all of the usual stuff you track in order to > > > understand > > > > > > wha's > > > > > > > > > going > > > > > > > > > > on > > > > > > > > > > > > > > > > > > > > I am saying a Maven Metrics API because we must not > stick to > > > a > > > > > > single > > > > > > > > > > "provider" (say "DropWizard"), it will be a bad choice > in the > > > > > long > > > > > > > > term. > > > > > > > > > > > > > > > > > > > > The API will expose to Maven Core and to plugins a way > to get > > > > > > access > > > > > > > to > > > > > > > > > > Metrics and report useful values. > > > > > > > > > > > > > > > > > > > > @InjectMe > > > > > > > > > > MetricsProvider metrics; > > > > > > > > > > > > > > > > > > > > metrics.getCounter("javacFiles").add(....) > > > > > > > > > > metrics.getSummary("downloadTime").add(....) > > > > > > > > > > > > > > > > > > > > I don't want to go down into details as this is only a > > > > > preliminary > > > > > > > > email > > > > > > > > > > but in my view we could let the user attach an > > > "implementation" > > > > > > just > > > > > > > by > > > > > > > > > > dropping in an "extension", in order not to ship with > Maven > > > Core > > > > > a > > > > > > > lot > > > > > > > > of > > > > > > > > > > third party dependencies. > > > > > > > > > > > > > > > > > > > > I have some "production" experience with this topic > > > (actually I > > > > > did > > > > > > > > > > something like that in my company and in ZooKeeper > project) > > > so I > > > > > > will > > > > > > > > be > > > > > > > > > > happy to prepare and share a design document. > > > > > > > > > > > > > > > > > > > > With this work we will open up the way to knowing how a > Maven > > > > > build > > > > > > > > > works, > > > > > > > > > > with the 'time dimension', on the local machine of the > > > developer > > > > > > but > > > > > > > > even > > > > > > > > > > on CI servers. > > > > > > > > > > > > > > > > > > > > Any comment is very welcome > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > Enrico > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > -- > > > > > > > +==============================+ > > > > > > > | Bästa hälsningar, > > > > > > > | [sw. "Best regards"] > > > > > > > | > > > > > > > | Lennart Jörelid > > > > > > > | EAI Architect & Integrator > > > > > > > | > > > > > > > | jGuru Europe AB > > > > > > > | Mölnlycke - Kista > > > > > > > | > > > > > > > | Email: [email protected] > > > > > > > | URL: www.jguru.se > > > > > > > | Phone > > > > > > > | (skype): jgurueurope > > > > > > > | (intl): +46 708 507 603 > > > > > > > | (domestic): 0708 - 507 603 > > > > > > > +==============================+ > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
