typically xbean scan all "configured" classpath (the archive passed as
parameter to the constructor)
we have a custom annotation finder where the find method returns when it
matches an item (it doesnt finish the scan). It is used to detect a module
type (webapp, jar, ...) for instance. We use it t
Yes, I'm seeing the xbean call waiting in most of the stack traces during
the long startup.
What do you mean by yours is a fail-fast one? Does is it revert to the
xbean one if something goes wrong? What kind of things can cause that to
happen? Or is it an option to use your one instead of t
yep, the scanning on big apps is the place to optimize. that's why we
created the scan.xml file.
that part is in xbean (subproject of geronimo) and it should be optimized
there, not in openejb (even if some bridge can let us do it in openejb if
we dont want to wait).
the parallel scanning is dang
Thanks Romain,
I've been doing some simple profiling and investigating the single-thread
issue further.
The findAnnotations method seems to be the slowest area on the hardware
we're testing, and with a large app it accounts for over 85% of the startup
time.
Could that be multithreaded with
Hi Neale,
well you find a big part of the overhead: the scanning, you can add all
which is not done by tomcat (JPA, EJB init, CDI...). Well maybe tomcat +
webapp startup should be compared to a tomee + webapp startup.
you spoke about multithreading which seems to be a good idea but it can
lead to
