Re: [jakartaee-platform-dev] Scanning specification

[arjan tijms <arjan.tijms@xxxxxxxxx>]

Hi,

On Thu, Mar 18, 2021 at 7:46 PM Thomas Bitonti <bitonti@xxxxxxxxxx> wrote:

+1

Jandex provides an approximate solution, but needs more lightweight ways to access index data.

At Piranha we created somewhat of what I think is a simpler API on top of Jandex. It's not super well thought out by any means and the javadocs are not really there yet, but we could use it as an additional source for inspiration.

See: https://github.com/piranhacloud/piranha/blob/master/webapp/api/src/main/java/cloud/piranha/webapp/api/AnnotationManager.java#L40

Requirements become more complicated if the scope of caching becomes larger than a single JAR.

I think at least for a 1.0 we should not really extend beyond what existing solutions like Jandex do today; i.e. the prime goal should be an index per jar, and an API to work with that index.

We probably also want to standardize the (binary?) file format of the index, so users don't have to create an index per vendor in their archives.

Kind regards,

Arjan Tijms

HK2 and Jandex are both inspirations to start from. In HK2, build-time scanning has an important role, and the so-called hk2-inhabitant-generator is often used. See this article from Jonathan that shows this: https://blog.payara.fish/hk2-the-hundred-kilobyte-kernel




On Wed, Mar 17, 2021 at 4:01 PM Thiago Henrique Hupner <thihup@xxxxxxxxx> wrote:

+1

Em qua, 17 de mar de 2021 12:00, Reza Rahman <reza_rahman@xxxxxxxxx> escreveu:
+1. I believe this has been discussed in the Servlet specification in the past. I know David Blevins has mentioned this over the years too.

On Mar 17, 2021, at 10:53 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:



I changed the title so an not to hijack the thread RE: Profiles.

 

I’d be in favour of a scanner spec or even SPI to also include a common Jar index format so all Jakarta specs could use the scan metadata and any cached metadata from the jar. HK2 already has a rudimentary api for Types Repository (glassfish-hk2/Types.java at master · eclipse-ee4j/glassfish-hk2 (github.com)) and a Scanner glassfish-hk2/Parser.java at master · eclipse-ee4j/glassfish-hk2 (github.com)

 

What is the best way to kick of an initial discussion? An issue in the Platform Project repo?

 

Steve

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Jesse McConnell
Sent: 17 March 2021 12:03
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Additional profiles

 

Speaking of scanning, that ought to be a spec in of itself at this point, so the entire application gets scanned once and all of the various APIs can make use of that scan data, servlet would definitely benefit from this. That would be a good extension to the core profile, which I quite like the name of.

 

Looking back to David's original premise though, it appears that we're less creating novel profiles and more just segmenting the existing ones and building up. Is this a situation where web profile would rely upon a specific version of a specification or a version of a core profile? 

 

I do support separately releasing profiles.

 

Jesse 

 

On Wed, Mar 17, 2021, 05:56 arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

 

On Wed, Mar 17, 2021 at 3:11 AM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:


 - Faces and standard tag libs add significantly to startup times due to TDL scanning and annotation scanning.

 

Actually Faces (at least Mojarra) doesn't do any annotation scanning itself. It uses the annotations that are handed to it via the @HandlesTypes in the ServletContainerInitializer. I guess it depends on the Servlet container if this triggers explicit extra annotation scanning or not.

 

Faces and Pages do .tld (and in case of Faces -taglib.xml) scanning indeed which has some cost since it looks for patterns.

 

Kind regards,

Arjan Tijms

 

 

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev