[Design the new POJO MicroContainer] - Re: OnDemand as an aspect
by charles.crouch＠jboss.com
"david.lloyd(a)jboss.com" wrote : What's the use case? My impression was that last time the topic of on-demand beans came up, we didn't want to use them this way because it would cause e.g. the first request which uses the bean to do all the dirty work, which isn't useful for most cases (it only provides the illusion of a quick startup).
We had/have exactly this use case with the Embedded Console in JBAS5.1.CR1. In order to start the Embedded Console you need to, amongst other things, initialize Seam and have it scan the console .war, and then run a scan of the JBAS instance looking for whats deployed. Right now those two things are taking around 20seconds to execute iirc. There is certainly some optimization that could be done here, but we're never going to get those things down to say 1second. Therefore it makes sense on app server startup not to penalize people who aren't going to use the console with the time costs of starting it up. So given this on-demand deployment isnt supported right now we hacked around it with a web filter and listener that delayed the Seam bootstrap and scanning until the first request to a page. If we had the ability to mark the deployment as on-demand we wouldn't have needed to do this.
Cheers
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228718#4228718
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228718
15 years, 7 months
[Design of POJO Server] - Expensive calls to getDeclaredMethods while creating joinpoi
by jaikiran
While working on performance improvement of EJB3 deployments (EJBTHREE-1800), i have been seeing that most of the time is spent in AOP (ex: finding annotations, creating interceptor chains etc...).
The sample app that i am trying is 100 EJBs with 100 methods each. (The performance degrades drastically as the number of methods increases)
One of the issues relates to the way a joinpoint for a method is created
Here's the flow:
- (AOP) Interceptor chain for EJB containers is created
- While the chain is being created, the corresponding AspectFactory are created
| protected Object createBean(ClassLoader cl) throws Throwable
| {
| ClassLoader loader = cl;
| if (loader == null)
| loader = Configurator.getClassLoader(classLoader);
| BeanInfo info = null;
| if (bean != null)
| info = configurator.getBeanInfo(bean, loader, accessMode);
|
| Joinpoint joinpoint = configurator.getConstructorJoinPoint(info, constructor, null);
|
| ....//blah blah blah
|
| invokeLifecycle("create", create, info, loader, result);
| invokeLifecycle("start", start, info, loader, result);
|
| return result;
| }
|
The invokeLifecycle tries to call the create() and start() methods if any:
| protected void invokeLifecycle(String methodName, LifecycleMetaData lifecycle, BeanInfo info, ClassLoader cl, Object target) throws Throwable
| {
| if (lifecycle == null || lifecycle.isIgnored() == false)
| {
| String method = methodName;
| if (lifecycle != null && lifecycle.getMethodName() != null)
| method = lifecycle.getMethodName();
| List<ParameterMetaData> parameters = null;
| if (lifecycle != null)
| parameters = lifecycle.getParameters();
| MethodJoinpoint joinpoint;
| try
| {
| joinpoint = configurator.getMethodJoinPoint(info, cl, method, parameters, false, true);
| }
| ...// blah blah
|
The calls goes to AbstractKernelConfigurator.getMethodJoinPoint:
| public MethodJoinpoint getMethodJoinPoint(BeanInfo info, ClassLoader cl, String name, List<ParameterMetaData> parameters, boolean isStatic, boolean isPublic) throws Throwable
| {
| return Configurator.findMethod(info, cl, name, parameters, isStatic, isPublic);
| }
|
The findMethod ultimately leads to this implementation in org.jboss.joinpoint.plugins.Config
| public static MethodInfo findMethodInfo(ClassInfo classInfo, String name, String[] paramTypes, boolean isStatic, boolean isPublic, boolean strict) throws JoinpointException
| {
|
| ...// blah blah
|
| MethodInfo result = locateMethodInfo(current, name, paramTypes, isStatic, isPublic, strict);
| if (result != null)
| return result;
| current = current.getSuperclass();
| }
|
The implementation for locateMethodInfo looks unnecessarily expensive:
| private static MethodInfo locateMethodInfo(ClassInfo classInfo, String name, String[] paramTypes, boolean isStatic, boolean isPublic, boolean strict)
| {
| MethodInfo[] methods = classInfo.getDeclaredMethods();
| if (methods != null)
| {
| for (int i = 0; i < methods.length; ++i)
| {
| if (name.equals(methods[ i].getName()) &&
| equals(paramTypes, methods[ i].getParameterTypes()) &&
| (strict == false || (methods[ i].isStatic() == isStatic && methods[ i].isPublic() == isPublic)))
| return methods[ i];
| }
| }
| return null;
| }
|
This locateMethodInfo is passed with the method name and params, so any specific reason why it needs to get all the declared methods and then do a equals on them instead of using the other API on ClassInfo which accepts the method name and params:
MethodInfo getDeclaredMethod(String name, TypeInfo[] parameters);
The current implementation leads to a performance degradation when the number of methods increases (All this piece of code is trying to do is find a couple of methods named create() and start()).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228711#4228711
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228711
15 years, 7 months
[Design of JBoss Identity] - Re: WS-Trust Integration in JBoss Identity
by alessio.soldano＠jboss.com
Anil,
I've done some basic research regarding CXF. First of all, let me clarify there's currently nothing implemented in Native stack regarding ws-trust, so the only way I see users using ws-trust is they call the STS you're implementing as they would do with any other service endpoint. Then they manually create the messages for the service provider, etc.
I think that's basically the Option A you wrote before, isn't it?
We'll offer WS-Trust functionalities with JBossWS-CXF instead. I've just committed some testcases adapted from the Apache CXF sources that basically call the WS-Trust 1.0 test STS and endpoint of the WCF interoperability plugfest (http://fisheye.jboss.org/changelog/JBossWS/?cs=9974).
A brief chat with Daniel Kulp (the CXF prj lead) confirmed that currently CXF has implementation for WS-Trust client side only, so no token validation at server side, etc.
On client side, CXF currently have means of easily configuring the STS client: http://cwiki.apache.org/CXF20DOC/ws-trust.html: that works fine in JBossWS-CXF and would work with any STS implementation I think. We might want some kind of better integration tough.
So, to sum up, the whole server side is still missing, so there's currently no interception point for that. I'll take a look at the identity stuff to understand what we could do better on client side for now.
Please tell me if I'm missing something in the whole picture (which might be)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228710#4228710
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228710
15 years, 7 months
[Design the new POJO MicroContainer] - OnDemand as an aspect
by alesj
Thinking about his more + reading existing jboss-dev ml entries,
I think we need much more transparent "On_Demand" integration.
e.g. if some service wants to be an entry point of "igniting" On_Demand beans
it needs to implement certain MC On_Demand mechanism
| ControllerContext context = controller.getContext(name, null);
| if (context == null)
| throw new IllegalArgumentException("No such context: " + name);
|
| controller.enableOnDemand(context);
| controller.change(context, ControllerState.INSTALLED);
|
| if (ControllerState.INSTALLED.equals(context.getState()) == false)
| throw new IllegalArgumentException("Couldn't fully install service: " + context);
|
| delegate = (SomeBean)context.getTarget();
|
And this is _very_ invasive.
A natural solution is probably the usage of AOP aspects.
We should be able to describe the service's need for such On_Demand beans
via ctor, method or field interceptor.
e.g.
| @OnDemand(beans = {"TransactionManager", "ThreadPool"})
| public void someMethod(int x)
| {
| ...
| }
|
Having only such beans array value is probably too static,
we would want to introduce much more dynamic behavior.
e.g. @OnDemand(factory = SomeDynamicOnDemandFactory.class)
Or grabbing some info out of the invoked Member itself.
Then these AOP aspect would hide the MC mechanism,
with the user only having to annotate his bean,
either in xml or directly on the class.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4228702#4228702
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4228702
15 years, 7 months