[Design the new POJO MicroContainer] - Re: MDR doesn't work on annotated privates
by adrian＠jboss.org
"adrian(a)jboss.org" wrote :
| Alternatively, we could change MethodSIgnature to include the "DeclaringClass"
| in its equals(). But then people who don't know the DeclaringClass,
| e.g. populating metadata from xml would have to do the findMethod().getDeclaringClass()
| upfront to populate the MethodSignature, otherwise the equals() would no longer work.
|
If you're willing to put the analysis work into making sure that adding the
declaring class to the signature's equals() doesn't break existing use cases
then I would be to change my position.
e.g. the MC "knows" the declaring class when it populates the xml
since it matches the xml elements to ClassInfo/MethodInfo, etc.
| private void updateAnnotations(MutableMetaDataRepository repository, ClassLoader classloader, ComponentMutableMetaData component, KernelControllerContext context, MethodInfo methodInfo, Set<AnnotationMetaData> annotations, boolean add)
| {
| if (annotations == null || annotations.isEmpty())
| return;
|
| Signature signature = new MethodSignature(methodInfo);
| ScopeKey scope = new ScopeKey(CommonLevels.JOINPOINT_OVERRIDE, methodInfo.getName());
| updateAnnotations(repository, classloader, component, context, signature, scope, annotations, add);
| }
|
but that doesn't mean everywhere else knows.
If you are not willing to do the analysis, then I'm not prepared to spend
weeks fixing things broken by this change. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170740#4170740
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170740
17 years, 7 months
[Design the new POJO MicroContainer] - Re: MDR doesn't work on annotated privates
by adrian＠jboss.org
"wolfc" wrote : "adrian(a)jboss.org" wrote : How's it supposed to know whether addAnnotation(Method, Annotation)
| | should be a MethodSignature or DeclaredMethodSignature?
| That's always a declared method, because else you won't be able to follow the Java rules for annotations on methods.
|
| Not it's not a DeclaredMethodSignature. The metadata contexts associated
| with those are not populated with the data loaded into MethodSignatures.
|
| The DeclaredMethodSignatures is a hack so you can shadow
| methods on the super class.
|
| It's not the same semantic. The semantic is designed to be the same as
| Class.get{Declared}Method(String name, Class.. parameters);
| the idea is you don't need to know the method/class, only its signature,
| that's why the class/key is called "Signature". :-)
|
| anonymous wrote :
| | Right now MethodSignature semantics is horribly broken as AnnotatedElementLoaderNotPublicUnitTestCase.testSameName shows.
|
| No it's not. It just does not do the horrible semantic you want it to do
| which is why we introduced the DeclaredMethodSignature.
|
| The test currently passes anyway, but then it is a useless test.
|
| The test that demonstrates the semantic you asked for is
| AnnotatedElementLoaderDeclaredMethodSignatureTestCase.
|
| The root of your difficulty is this call
|
| | MetaData superMethodMetaData = metaData.getComponentMetaData(Signature.getSignature(superMethod));
| |
|
| which doesn't return the superMethod metadata.
|
| When you should be doing
|
|
| | MetaData superMethodMetaData = metaData.getComponentMetaData(new DeclaredMethodSignature(superMethod));
| |
|
| We could add a new method:
|
| | public static Signature getSignature(Class<?> clazz, Member member)
| | {
| | if (member == null)
| | throw new IllegalArgumentException("Null member");
| |
| | if (member instanceof Method)
| | {
| | Method method = Method.class.cast(member);
| | Method other = method;
| | // See if we are masking the method
| | if (clazz != method.getDeclaringClass())
| | other = ReflectionUtils.findMethod(clazz, method);
| | // Yes
| | if (other.equals(method) == false)
| | return new DeclaredMethodSignature(member);
| | // No
| | else
| | return new MethodSignature(method);
| | }
| | ...
| |
|
| But then it would be horribly slow for all other users.
|
| Alternatively, we could change MethodSIgnature to include the "DeclaringClass"
| in its equals(). But then people who don't know the DeclaringClass,
| e.g. populating metadata from xml would have to do the findMethod().getDeclaringClass()
| upfront to populate the MethodSignature, otherwise the equals() would no longer work.
|
| Since Signature.equals() is designed to work before the classes are loaded
| that would be difficult - though not impossible with javassist,
|
| Nothing actually uses it that way at the moment, but there are obvious performance
| improvements (on the roadmap) to be gained by not duplicating annotation
| loading, javassist parsing and caching work across AOP, annotation scanning, ClassInfo, etc.
|
| If you continue to just say it is a bug, instead of suggesting how we make
| your semantic work without breaking (including performance) every other
| use case, I'd be inclined to just remove the *experimental* DeclaredMethodSignature
| and tell you to do the hack yourself in your code. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170737#4170737
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170737
17 years, 7 months
[Design the new POJO MicroContainer] - Re: MDR doesn't work on annotated privates
by wolfc
"adrian(a)jboss.org" wrote : How's it supposed to know whether addAnnotation(Method, Annotation)
| should be a MethodSignature or DeclaredMethodSignature?
That's always a declared method, because else you won't be able to follow the Java rules for annotations on methods.
"adrian(a)jboss.org" wrote : A general metadata loader (in this case the memory loader for storing the xml)
| doesn't even know what the class is so it can't even search to see whether
| it is a private Method that is masked by a different method in that class or one
| of its super classes.
<session>
| <ejb-name>SameMethodNameBean</ejb-name>
| <post-construct>
| <lifecycle-callback-class>SameMethodNameSuper</lifecycle-callback-class>
| <lifecycle-callback-method>postConstructInSuper</lifecycle-callback-method>
| </post-construct>
| </session>
I can see that this should translate to a DeclaredMethodSignature, while
<session>
| <ejb-name>SameMethodNameBean</ejb-name>
| <post-construct>
| <lifecycle-callback-method>postConstructInSuper</lifecycle-callback-method>
| </post-construct>
| </session>
this could be a MethodSignature.
It's just that somewhere the overloading rules for methods must be obeyed, so that in the second xml SameMethodNameSuper.postConstructInSuper doesn't get the PostConstruct annotation.
Right now MethodSignature semantics is horribly broken as AnnotatedElementLoaderNotPublicUnitTestCase.testSameName shows.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170725#4170725
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170725
17 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Message redistribution in JBM 2.0 - request for feedback
by timfox
As you know, JBM 1.4 contains message redistribution with clustered queues.
This means, if you have a clustered queue over several nodes in a cluster, and consumers on one node are faster than consumers on another node, then messages will be pulled from one node to another transparently to satisfy demand.
The idea here is it should give optimal use of server resources for processing messages.
Problem is this behaviour can confuse users. The classic case is they set up a cluster of N nodes with a clustered queue, send messages to a single node and wonder why all their consumers on different nodes aren't processing the messages. This is because the local node still has spare cpu cycles so there is no point in allowing other nodes to consume, since that would involve unnecessary network round tripping. So it's actually the optimal use of resources.
Regarding JBM 2.0 I'd appreciate any feedback on whether you think this feature is of value. Or the customer confusion value outweighs its value, or if you think it should behave in some other way.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170708#4170708
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4170708
17 years, 7 months