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
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.
- 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.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev