Re: [jboss-dev] Further profling: Where should I focus?
Ales Justin wrote:
> IMO, we should just remove AOP entirely as our customers probably
are
> not going to use it.
This is exactly what will happen - remove AOP - if we disable it by
default and re-write lifecycle handling to plain OO, w/o any costly
pointcut matching.
The only cost is lookup for potential @AOPEnable on the bean.
While we still keep optional cool feature of creating an AOP proxy for a
bean.
> For @JMX just write another deployer and do it
> regularly. Similarly with lifecycle and other features.
Regularly?
If you mean to register an mbean, that is actually not what we/users want.
See my response to Dimitris this morning.
There probably is a way to make AOP irrelevant to boot performance, but
you need to consider pluses and minuses nevertheless...Everybody
(thousands) of users are effected by boot performance, while only a
handful care about @JMX, etc.
While this could be a deployer feature, I think it's far more
complex to
do it than tie it into the bean's lifecycle.
e.g. scan for @JMX, remembering the handle, checking if it's overridden
for an instance, ... while we already have all this implemented in
bean's lifecycle handling, it's just not optimized yet.
What do you mean by "similarly with lifecycle and other features"?
@JMX, @JNDI, @Password, ... is the lifecycle callback.
All these annotations that trigger AOP. Are they under the jboss
namespace? Controlled by us?
You might want to consider meta-annotations and turning @AOPEnabled into
one. i.e.
@AOPEnabled
public @interface JMX {...}
You look at the bean's class annotations, then look at those annotations
for @AOPEnabled.
> Again, if you want to take this route, I'd be happy to do the
work.
> I am willing to spend the next month on boot performance and AS.
Excellent.
So will I and the rest of MC team.
Well, I need to know what I could do to help. Is Kabir fine on the AOP
stuff? VFS3 seems to be ok? What about removing JMX Kernel Backward
Compatibility and upgrading services to MC? I can tackle any of these
problems with little guidance I just don't want to be duplicating any
work (like with the deployer sorting).
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com