[Design of EJB 3.0] - Change to Advisor, EJB3 Acceptance Testing
by ALRubinger
The following is going into AOP, so we'll need to verify all's OK on our end (at times we hack into AOP internals):
[kabir@~/sourcecontrol/jboss-aop/branches/Branch_2_1/subversion/aop]
| $svn diff -r87077:87081 src/main/java/org/jboss/aop/Advisor.java
| Index: src/main/java/org/jboss/aop/Advisor.java
| ===================================================================
| --- src/main/java/org/jboss/aop/Advisor.java (revision 87077)
| +++ src/main/java/org/jboss/aop/Advisor.java (revision 87081)
| @@ -82,6 +82,7 @@
| import org.jboss.metadata.spi.signature.MethodSignature;
| import org.jboss.util.NestedRuntimeException;
| import org.jboss.util.NotImplementedException;
| +import org.jboss.util.collection.ConcurrentSet;
|
| /**
| * Manages the interceptor chains of an aspect context (usually, this context is
| @@ -176,7 +177,7 @@
| /** Contains all the interceptor instances applied to this context. */
| protected HashMap<AspectDefinition, Map<String, Interceptor>> adviceInterceptors = new HashMap<AspectDefinition, Map<String, Interceptor>>();
| /** Contains all definitions of PER_INSTANCE aspects applied to this context. */
| - protected volatile CopyOnWriteArraySet<AspectDefinition> perInstanceAspectDefinitions = UnmodifiableEmptyCollections.EMPTY_COPYONWRITE_ARRAYSET;
| + protected volatile Set<AspectDefinition> perInstanceAspectDefinitions = UnmodifiableEmptyCollections.EMPTY_CONCURRENT_SET;
| /** Contains all definitions of PER_JOINPOINT scoped aspects applied to this sccontext*/
| protected volatile ConcurrentHashMap<AspectDefinition, Set<Joinpoint>> perInstanceJoinpointAspectDefinitions = UnmodifiableEmptyCollections.EMPTY_CONCURRENT_HASHMAP;
| /** The {@code java.lang.String} class */
| @@ -2079,13 +2080,13 @@
|
| protected void initPerInstanceAspectDefinitionsSet()
| {
| - if (perInstanceAspectDefinitions == UnmodifiableEmptyCollections.EMPTY_COPYONWRITE_ARRAYSET)
| + if (perInstanceAspectDefinitions == UnmodifiableEmptyCollections.EMPTY_CONCURRENT_SET)
| {
| synchronized(lazyCollectionLock)
| {
| - if (perInstanceAspectDefinitions == UnmodifiableEmptyCollections.EMPTY_COPYONWRITE_ARRAYSET)
| + if (perInstanceAspectDefinitions == UnmodifiableEmptyCollections.EMPTY_CONCURRENT_SET)
| {
| - perInstanceAspectDefinitions = new CopyOnWriteArraySet<AspectDefinition>();
| + perInstanceAspectDefinitions = new ConcurrentSet<AspectDefinition>();
| }
| }
| }
https://jira.jboss.org/jira/browse/JBAOP-716
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224733#4224733
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224733
17 years
[Design of JBoss jBPM] - Re: Mail session configuration
by bradsdavis
Actually instead of extending a specific mail producer, what if the templating did this:
| <template name="exampleTemplate">
| <mail-producer class="org.jbpm.pvm.internal.email.producer.impl.ScriptMailProducer">
| <subject>Example subject.</subject>
| <body>This is an example.</body>
| <language>JUEL</language> //or whatever
| <mail-producer>
| </template>
|
And then the templated mail producer itself could be plugable.
So within the templated mail producer we would have something like...
| public class TemplateMailProducer implements MailProducer {
|
| protected String templateName;
|
| public Collection<Email> produce(Execution exe, MailContext mailContext) throws Exception {
| //Find out which producer is being used in the template.
| MailProducer templatedProducer = readTemplate(templateName);
|
| return templatedProducer.produce(exe, mailContext);
| }
|
| protected MailProducer readTemplate(String templateName)
| {
| return null; //Actually do the reading and create the appropriate producer.
| }
| }
|
|
The nice thing about this solution is that we could reuse the mail-producer reader since it will be basically the same thing as if it were defined in the JPDL itself.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224728#4224728
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224728
17 years
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Large messages broken
by timfox
"clebert.suconic(a)jboss.com" wrote :
| Also... there are a few considerations the new code will have:
|
| I - Since we are now based on streams, and not files any more.... it won't be possible to resend messages without reseting the messageBody.
|
| So.. you won' t be able to do something like:
|
| Message largeMessage = consumer1.receive(...);
| producer1.send(largeMessage); // the first one would work though
| producer2.send(largeMessage);
|
I don't see a problem there as long as we document the behaviour
anonymous wrote :
| (This would work on the server though (Bridge), as on the server we are still file based)
|
|
| II - One thing I' m not sure how to proceed yet. The user may receive a large-message and do nothing with the buffer.
|
| for (....)
| | {
| | Message msg = buffer.receive(...);
| |
| | // you read the body partially... and discover that message should just be ignored... so you only read the buffer partially. The code will go to the next message
| | }
| |
|
|
|
| Right now, I' m solving this by emptiying the buffer when the next buffer.receive() is called. But then the following would fail:
|
|
| Msg msg = consumer.receive(...);
| Msg msg2 = consumer.receve(...)
|
| msg.getBody().readWhatever(); // the buffer is gone at this point.
|
|
|
Again, I think that's acceptable as long as document the behaviour
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224727#4224727
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224727
17 years