Cdi handle interfaces too which are not Object.
About throwing away classloader that's what we do in tomee.
Le 14 juin 2013 18:09, "Christopher Schultz" <ch...@christopherschultz.net>
a écrit :
> 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
>
>
