Romain, On 6/14/13 5:38 AM, Romain Manni-Bucau wrote: > can work this way, today that's not as easy as it could to replace tomat > scanning(s) (tld, classes) by tomee one. > > About CDI: you basically need to pass all classes on jars with a beans.xml > to the CDI container so @HandlesType doesn't match this need really well.
It's a pathological case, but there's nothing stopping you from doing this:
@HandlesType('java.lang.Object')
That way, you'll get everything. Then you can scan the Class objects to
your heart's content looking for whatever you need. CDI can be
implemented this way: just replace the "library" JAR scanner with an SCI
that responds as if it had scanned all the classes itself.
I have to imaging any JAR scanner would be written with a callback
interface, so just loop-over all the Classes in the Set you get and
fire-off those call-backs: you get the scanning for free already done by
Tomcat. Set a global-ish flag in the library saying that scanning has
been done and stop.
Then your fall-back scanner runs just in case SCIs aren't available
(pre-3.0 container for example -- the Servlet EG recently clarified that
even a webapp with a pre-3.0 deployment descriptor still needs to have
all its 3.0-type features fired which is a decision which seems
astoundingly foolish to me) -- check the aforementioned flag and skip
"traditional" scanning if you already got it for free.
The only thing "missing" is a "standard" scanner -- which was what I was
suggesting. If you implement a standard scanner and it's good, maybe
Tomcat will adopt it.... and wire it through SCIs because that's what
web containers do.
-chris
signature.asc
Description: OpenPGP digital signature
