[Design of AOP on JBoss (Aspects/JBoss)] - Re: Creation of method tables in ClassAdvisor
by flavia.rainone@jboss.com
Jaikiran wrote : What is the purpose of this code? I guess, there is some specific scenario where this comes into picture
Yes, there is a scenario where this comes into picture. If you navigate through the call hierarchy, you will see that this method is being invoked by both createMethodTables and populateMethodTables, but you will see that createMethodTables invokes populateMethodTables for the superclass of the advised classe:
protected void createMethodTables()
| throws Exception
| {
| initAdvisedMethodsMap();
| populateMethodTables(clazz.getSuperclass());
| addDeclaredMethods(clazz);
| }
Plus, populateMethodTables is recursive on the superclass:
private void populateMethodTables(Class<?> superclass)
| throws Exception
| {
| if (superclass == null) return;
| if (superclass.equals(Object.class)) return;
|
| populateMethodTables(superclass.getSuperclass());
| ...
|
So, we will first verify if the superclass has the unadvised method, if it has, we will use it. There are specific scenarios where the superclass may have the unadvised method, such as when there is a method in the superclass that matches a pointcut. In this scenario, the invocation to getDeclaredMethod that you mentioned is not going to fail.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230855#4230855
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230855
16 years, 11 months
[Design of JBoss ESB] - Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
by Kevin.Conner@jboss.com
"beve" wrote : This is to support pass-through of JMS properties. Previously we just passed through all properties which caused problems with some JMS Providers.
But should this not be the responsibility of the gateway and EPR to handle?
"beve" wrote : The issue we had was when working with IBMQ in combination with JBossMQ. JBossMQ throws an exception if a provider specific jms property, one starting with "JMS_verndor_name" was not recognized as it's own.
This was seen with a single provider, oracle, we were not passing these between different providers.
"beve" wrote : Well this might make our life easier but perhaps this could hurt performance. These properties could be optimization properties that the provider can take advantage of.
Okay, so it sounds like we need a more flexible solution. Do you have any examples of the properties which you are allowed to set?
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230851#4230851
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230851
16 years, 11 months
[Design of JBoss ESB] - Re: DefaultJMSPropertiesSetter, DefaultESBPropertiesSetter a
by beve
anonymous wrote : why does the ESB aware need to handle property mappings?
This is to support pass-through of JMS properties. Previously we just passed through all properties which caused problems with some JMS Providers.
The issue we had was when working with IBMQ in combination with JBossMQ. JBossMQ throws an exception if a provider specific jms property, one starting with "JMS_verndor_name" was not recognized as it's own. JBoss Messaging would simply ignore an unrecognized provider property.
The use case was a jms gateway that was connected to IBMQ. A JMS Message would in this case contain provider specific properties to IBMQ. By filtering out these properties they would never be seen by JBossMQ.
We created this for cases where other JMS Providers might do the same as JBossMQ and added the ability to filter out properties.
anonymous wrote : should the DefaultJmsPropertiesSetter also be filtering?
Yeah, it probably should. If there is a mix of JMS Provders this will probably cause troubles like the one you are seeing at the moment :(
anonymous wrote : should we be ignoring JMS_XXX on a global basis?
Well this might make our life easier but perhaps this could hurt performance. These properties could be optimization properties that the provider can take advantage of.
/Daniel
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230846#4230846
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230846
16 years, 11 months
[Design of AOP on JBoss (Aspects/JBoss)] - Creation of method tables in ClassAdvisor
by jaikiran
Need some input on a couple of things in the org.jboss.aop.ClassAdvisor http://anonsvn.jboss.org/repos/jbossas/projects/aop/branches/Branch_2_1/a.... During initialization and creation of method tables, the ClassAdvisor in it's addDeclaredMethod does this:
| protected void addDeclaredMethods(Class<?> superclass) throws Exception
| {
| Method[] declaredMethods = superclass.getDeclaredMethods();
| for (int i = 0; i < declaredMethods.length; i++)
| {
| if (ClassAdvisor.isAdvisable(declaredMethods[ i]))
| {
| long hash = MethodHashing.methodHash(declaredMethods[ i]);
| advisedMethods.put(hash, declaredMethods[ i]);
| try
| {
| Method m = declaredMethods[ i];
| Method un = superclass.getDeclaredMethod(ClassAdvisor.notAdvisedMethodName(superclass.getName(),
| m.getName()),
| m.getParameterTypes());
| un.setAccessible(true);
| unadvisedMethods.put(hash, un);
| }
| catch (NoSuchMethodException ignored)
| {
| }
| }
| }
| }
|
| public static String notAdvisedMethodName(String className,
| String methodName)
| {
| return className.replace('.', '$') + "$" + methodName +
| NOT_TRANSFORMABLE_SUFFIX;
| }
|
| /**
| * Suffix added to unadvised methods.
| */
| public static final String NOT_TRANSFORMABLE_SUFFIX = "$aop";
|
|
|
Assuming i have this expression:
| <domain name="XXX" extends="YYY" inheritBindings="true">
| <bind pointcut="execution(public * *->*(..))">
| ...
| </bind>
|
| package org.myapp;
|
|
| public class SomeClass
| {
| public void method1()
| {
| ..
| }
|
| public void method2()
| {
| ..
| }
| }
|
1) So the addDeclaredMethod piece of code, above, is going to generate for each method an "unadvised method name" as:
| org$myapp$SomeClass$method1$aop
| org$myapp$SomeClass$method2$aop
|
and later on when the
| superclass.getDeclaredMethod(ClassAdvisor.notAdvisedMethodName(superclass.getName(), m.getName()),m.getParameterTypes());
|
is called it's always going to throw a NoSuchMethodException, isn't it?
What is the purpose of this code? I guess, there is some specific scenario where this comes into picture
2) The MethodHashing.methodHash() does some very specific/involved logic. How is it different from a normal method.hashCode()?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230825#4230825
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230825
16 years, 11 months