[Design of POJO Server] - Re: Removing ClassLoading from jboss-bootstrap
by adrian＠jboss.org
"ALRubinger" wrote : https://jira.jboss.org/jira/browse/JBBOOT-24
|
| As it stands, Bootstrap is sensitive to arbitrary JARs on the application CP (and picked up by the extension ClassLoader). This becomes especially apparent when starting up from an Embedded environment, where we may have a full dependency set on the test CP.
|
| AS currently sidesteps this problem by careful inclusion of classes in the run.jar.
|
| What I'd like to do is remove setting of the TCCL from jboss-bootstrap entirely, leaving this task up to the client (launcher). Some local tests yield much better results and allow the bootstrap to become adaptable to a wider range of runtime environments.
|
The basic idea is to have a pluggable bootstrap. The bootstrap.start() should run
under its own classloader as TCL not the classpath otherwise all sort of side effects
break (e.g. loading property editors, and other dynamic classloading, etc.).
In JBoss the bootstrap is two stage (actually it is multiple).
1) To load the bootstrap implementation itself (the mc + profile service)
2) To load the bootstrap xmls
As long as the called code doesn't have to worry about setting the TCL itself
(error prone and it is not likely to know what the correct CL is)
I don't have a problem.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223631#4223631
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223631
17 years
[Design of EJB 3.0] - Re: EJBTHREE-1800 Improving InjectInterceptorsFactory
by jaikiran
One more place which i think can be improved for performance is the InterceptorRegistry, which currently checks for the presence of any @Interceptor and @InterceptorOrder on the bean classes/methods. Currently, the InterceptorRegistry does the following for method-level logic:
1) Get *all* (public, private, protected etc...) methods on the bean class
2) For each of these methods check for the presence of @Interceptors
3) Build a collection of Interceptor classes applicable to this method (which effectively is default intereceptors, class interceptors and any interceptors declared for that method)
4) Check for the presence of @InterceptorOrder on each of these methods
I think we can improve this logic. The EJB3 spec says:
"EJB3 Spec, Section 12.7" wrote : A business method interceptor method may be defined to apply to a specific business method invocation, rather than to all of the business methods of the bean class.
|
So we can improve step#1 to:
1) Get only public methods of a bean class and its super classes (since a business method cannot be anything other than public). This effectively eliminates a lot of irrelevant methods from further processing
No change in logic for step#2 and #3
2) For each of these methods check for presence of @Interceptors
3) Build a collection of Interceptor classes applicable to this method (which effectively is default intereceptors, class interceptors and any interceptors declared for that method)
A bit of improvement in step#4
4) Only if the collection of interceptor classes for this method is non-empty, then go ahead with the check for @InterceptorOrder. If there are no relevant interceptors for this method then there's no point in checking the @InterceptorOrder
I haven't given this change a try yet - will do now. But any thoughts about this change?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223568#4223568
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223568
17 years
[Design of EJB 3.0] - EJBTHREE-1800 Improving InjectInterceptorsFactory
by jaikiran
While working on EJBTHREE-1800, i noticed that the InjectInterceptorsFactory while creating a per joinpoint, does the following:
1) Retrieves *all* methods on the interceptor/bean class
2) For each of these methods, checks whether it's overridden
3) If not, then checks whether the method has an @AroundInvoke
This currently leads to a performance degradation. As the number of methods increase (on the bean or the interceptor class), so does the timing of this logic.
Keeping in mind, the following requirements in the EJB3 spec:
AroundInvoke methods have the following signature: Object (InvocationContext) throws Exception
the logic in this InjectInterceptorsFactory can be improved as follows:
1) Get only those methods with accept InvocationContext as a param type and return type is Object (internally we still have to scan all public, private, package etc... methods of the class as per the spec, but filtering out the relevant methods will help in step#2 and #3)
2) For each of these (filtered) methods which follow the AroundInvoke method signature, check if it has a @AroundInvoke declared
3) If there's a @AroundInvoke, then go on to check whether the method is overridden. If yes, ignore.
Initial local tests with this change, does show some good improvements. Any other thoughts?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223562#4223562
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223562
17 years