11:51 a.m.
Remy Maucherat wrote:
On Wed, 2009-10-28 at 18:23 +0200, Dimitris Andreadis wrote:
> - Papaki annotation scanning requirements/variants
I already integrated extracted working stuff into Deployers:
- http://anonsvn.jboss.org/repos/jbossas/projects/mc-ann/trunk/
-
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/dep...
Ok. Indeed, I cannot use any form of optimized scanning for JARs
which
are in WARs at the moment. It works, but it is slower.
My guess would be that this slowness comes from the way Metadata project
uses this annotation scanning.
And afaik, you also went back to the old load-all-scan-all-classes approach.
See AS trunk for the exact processing style (to summarize, I need to
be
able to scan and process annotations separately for classes
in /WEB-INF/classes and in each individual JAR in /WEB-INF/lib).
This looks like an additional requirement on top of scan-all-in
deployment unit.
I would still try to scan it all - as that's the only proper way to
account for restrictions.
Then there could be an api that would group this annotations according
to source location.
12:05 p.m.
On Wed, Oct 28, 2009 at 5:51 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
My guess would be that this slowness comes from the way Metadata
project
uses this annotation scanning.
And afaik, you also went back to the old load-all-scan-all-classes approach.
Nothing changed in metadata. However, due to the Servlet spec, I had
to switch back to using the old annotation deployer rather than
OptAnnotationMetaDataDeployer to process the stuff that is in WARs. So
that did drop performance a bit. Not exactly huge, but it's
measurable, and could become a problem for WARs with tons of JARs.
> See AS trunk for the exact processing style (to summarize, I need
to be
> able to scan and process annotations separately for classes
> in /WEB-INF/classes and in each individual JAR in /WEB-INF/lib).
This looks like an additional requirement on top of scan-all-in
deployment unit.
I would still try to scan it all - as that's the only proper way to
account for restrictions.
Then there could be an api that would group this annotations according
to source location.
Right, the grouping per location is the extra feature that is needed
for Servlet 3.0.
Rémy
12:16 p.m.
Nothing changed in metadata. However, due to the Servlet spec, I had
to switch back to using the old annotation deployer rather than
OptAnnotationMetaDataDeployer to process the stuff that is in WARs.
Yeah, that's what I meant.
But like I said, the problem is in how Metadata uses this info.
Instead of just pull model, we have a push-pull-push model. :-)
could become a problem for WARs with tons of JARs.
This is something you cannot do much faster.
The fact is that you have to scan everything the users expects to be
scanned,
and mostly this is everything, small or huge, doesn't matter.
The things that (should/will) help here are:
* scan only once, everybody else just uses this info,
no additional scanning; which is not the case atm
* restrict what should be scanned; jboss-scanning.xml
* use exact class import/export info; osgi/jboss-classloading.xml
* pre-indexed scanning; META-INF/anns.ser
Right, the grouping per location is the extra feature that is needed
for Servlet 3.0.
I/We will add this once we decide what to do.
Which current impl we actually use and maintain. ;-)
12:34 p.m.
On Wed, Oct 28, 2009 at 6:16 PM, Ales Justin <ales.justin(a)gmail.com> wrote:
The things that (should/will) help here are:
* scan only once, everybody else just uses this info,
no additional scanning; which is not the case atm
* restrict what should be scanned; jboss-scanning.xml
* use exact class import/export info; osgi/jboss-classloading.xml
* pre-indexed scanning; META-INF/anns.ser
There's an easy to spot opportunity to serialize the meta data that
comes out of the MergedJBossWebMetaDataDeployer too. This could be a
most efficient strategy, in addition to the improvements you've
listed.
> Right, the grouping per location is the extra feature that is
needed
> for Servlet 3.0.
I/We will add this once we decide what to do.
Which current impl we actually use and maintain. ;-)
Ok !
Rémy
5531
days inactive
5531
days old
jboss-development@lists.jboss.org
3 comments
2 participants
participants (2)
-
Ales Justin -
Rémy Maucherat