[Design of Messaging on JBoss (Messaging/JBoss)] - Some more comments on examples so far
by timfox
1) TopicSelector - please follow naming convention everyone else is using.
No need to use durable subscriptions here, we already have a durable subscription test.
Also when consuming messages print out the value of user id.
It's not clear from this example that only matching messages are selected. That's the point of the example, and it's not really mentioned at all.
There's no real explanation here of what the example is doing or why people would want to use selectors.
2) Request reply example
Best to create all the objects at the beginng otherwise it seems you're creating them on each message which would be anti-pattern.
Again, also there's no real explanation of what request-response is or why you'd want to do it.
3) Temporary queue example. Again, this example is not demonstrating anything relevant about temporary queues.
It's just sending a message to a queue, it could be any queue. It doesn't demonstrate deleting temp queues and it doesn't demonstrate scoping of temp queues (to connection).
The readme doesn't really have any useful information either.
4) TransactionalExample. Again (like I mentioned yesterday) this is not demonstrating anything really to do with transactions. It's just sending and consuming a message.
5) QueueRequestor example - no explanation of what the example is supposed to demonstrate.
Guys - you're all thinking too much like developers here! ;)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222610#4222610
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222610
15 years, 10 months
[Design the new POJO MicroContainer] - Re: Multiple ClassFileTransformers/Translators
by adrian@jboss.org
"alesj" wrote : WRT: https://jira.jboss.org/jira/browse/JBSPRING-1
|
"It does not work" is not a bug report. What's wrong with it?
If you want to send me private e-mails asking me to look at stuff,
at least give me something to look at. :-)
Either way, I'll usually just ignore this kind of "twaddle" until the author puts some work into the question to make it answerable.
anonymous wrote :
| I've created custom JBoss5 LTW: http://anonsvn.jboss.org/repos/jbossas/projects/spring-int/trunk/weaving/...
|
| But my actual question is really:
| * why do we use custom Translator instead of ClassFileTransformer
| ** perhaps the usage of Translator::unregisterClassLoader
|
You should use an agent.
The Transformer is only there for backwards compatibility with AOP from before the agent api was available.
Something that is almost certainly no longer relevant except for some old tests in the testsuite.
The only difference between the Transformer and the ClassFileTransformer
is that one is inside ClassLoader.defineClass() - i.e. all classloaders
while the other is only invoked from our ClassLoader.
|
| // Load the bytecode
| byte[] byteCode = ClassLoaderUtils.loadByteCode(name, is);
|
| // Let the policy do things before we define the class
| BaseClassLoaderPolicy basePolicy = policy;
| ProtectionDomain protectionDomain = basePolicy.getProtectionDomain(name, resourcePath);
| try
| {
|
| TRANSFORMER HERE
|
| byte[] transformed = policy.transform(name, byteCode, protectionDomain);
| if (transformed != null)
| byteCode = transformed;
| }
| catch (Throwable t)
| {
| throw new RuntimeException("Unexpected error transforming class " + name, t);
| }
|
| // Create the package if necessary
| URL codeSourceURL = null;
| if (protectionDomain != null)
| {
| CodeSource codeSource = protectionDomain.getCodeSource();
| if (codeSource != null)
| codeSourceURL = codeSource.getLocation();
| }
| definePackage(name, codeSourceURL);
|
| // Finally we can define the class
| Class<?> result;
|
| AGENT INSTRUMENTATION HERE
|
| if (protectionDomain != null)
| result = defineClass(name, byteCode, 0, byteCode.length, protectionDomain);
| else
| result = defineClass(name, byteCode, 0, byteCode.length);
|
anonymous wrote :
| * why do we have just one translator and not a list of them
| * why Translator per ClassLoaderSystem and not (also) per BaseClassLoaderPolicy
|
| Afaics the SpringLTW example will set the transformer to the whole ClassLoaderSystem,
| where it would actually only make sense to have it on apps CL policy.
|
If you want to add classloader specific ClassFileTransformers to the
BaseClassLoaderPolicy api that's ok with me.
I think a better integration point would be to have a Spring aop deployer like
our aop deployer to analyse (and in your case modify) the classloader
based on metadata?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4222607#4222607
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4222607
15 years, 10 months