7:03 a.m.
Consolidate JMS related aspects into one JMS aspect
---------------------------------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 1.2.1
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:31 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Consolidate JMS related aspects into one JMS aspect
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Ovidiu Feodorov updated JBMESSAGING-681:
----------------------------------------
Fix Version/s: Unscheduled
(was: 1.2.1)
Consolidate JMS related aspects into one JMS aspect
---------------------------------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: Unscheduled
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:15 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Consolidate JMS related aspects into one JMS aspect
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Tim Fox updated JBMESSAGING-681:
--------------------------------
Fix Version/s: 2.0.0 Beta 1
(was: Unscheduled)
Consolidate JMS related aspects into one JMS aspect
---------------------------------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 2.0.0 Beta 1
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:32 a.m.
New subject: [JBoss JIRA] Commented: (JBMESSAGING-681) Consolidate JMS related aspects into one JMS aspect
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=comments#action_12... ]
Tim Fox commented on JBMESSAGING-681:
-------------------------------------
We should remove AOP usage from the standard stack, and use java.lang.reflect proxies as
EJB3 does to allow users to specify a stack of interceptors on both client and server
side.
The functionality currently in the client side JMS aspects should be moved into a set of
standard classes:
ConnectionFactory, Connection, Session, Consumer.
Note that this *do not* correspond to JMS connection factory, connection, consumer
classes. These are a simpler abstraction.
We maintain the standard JMS object implementations which should delegate to these
classes.
Consolidate JMS related aspects into one JMS aspect
---------------------------------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 2.0.0 Beta 1
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:32 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor AOP usage
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Tim Fox updated JBMESSAGING-681:
--------------------------------
Summary: Refactor AOP usage (was: Consolidate JMS related aspects into one JMS
aspect)
Refactor AOP usage
------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 2.0.0 Beta 1
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:34 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor AOP usage
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Tim Fox updated JBMESSAGING-681:
--------------------------------
Assignee: Clebert Suconic (was: Tim Fox)
Priority: Critical (was: Major)
Refactor AOP usage
------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Beta 1
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:18 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Tim Fox updated JBMESSAGING-681:
--------------------------------
Summary: Refactor client side model (was: Refactor AOP usage)
Description:
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
was:
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Beta 1
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:31 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Tim Fox updated JBMESSAGING-681:
--------------------------------
Fix Version/s: 2.0.0 Alpha
(was: 2.0.0 Beta 1)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:02 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: patch.diff
Backup point as I don't have where to commit this yet.
patch applied on Jeff's branch, version 3385
This is just a simple refactoring where the new model isn't being target yet.
On this patch, you would still find ClosedInterpcetor, FailoverValveinterceptor,
ConsumerAspect and ClusteringAspect... all other aspects would have to be removed by hand.
(as the patch won't remove them).
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:21 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: diff_3385.patch.2
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: diff_3385.patch.2, patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:24 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: (was: diff_3385.patch.2)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup2.patch, patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:24 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: backup2.patch
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup2.patch, patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:33 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: backup3.patch
Backup3 : patch on this branch:
URL: https://svn.jboss.org/repos/messaging/branches/Branch_JBMESSAGING-544
Repository Root: https://svn.jboss.org/repos/messaging
Repository UUID: b6fe21fe-e719-0410-baf4-a14e395396c4
Revision: 3408
Deleted files:
D src/main/org/jboss/jms/server/endpoint/advised
D src/main/org/jboss/jms/server/endpoint/advised/ConnectionAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/BrowserAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/SessionAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/ConnectionFactoryAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/ConsumerAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/AdvisedSupport.java
D src/main/org/jboss/jms/server/container/ServerLogInterceptor.java
D src/main/org/jboss/jms/client/container/ConnectionAspect.java
D src/main/org/jboss/jms/client/container/ClientLogInterceptor.java
D src/main/org/jboss/jms/client/container/JmsClientAspectXMLLoader.java
D src/main/org/jboss/jms/client/container/StateCreationAspect.java
D src/main/org/jboss/jms/client/container/ExceptionInterceptor.java
D src/main/org/jboss/jms/client/container/ClusteringAspect.java
D src/main/org/jboss/jms/client/container/SessionAspect.java
D src/main/org/jboss/jms/client/container/ProducerAspect.java
D src/main/org/jboss/jms/client/container/BrowserAspect.java
D src/main/org/jboss/jms/client/container/DelegateIdentity.java
D src/main/org/jboss/jms/client/container/ConsumerAspect.java
D src/main/org/jboss/jms/client/ClientAOPStackLoader.java
D src/etc/aop-messaging-client.xml
D src/etc/aop-messaging-client-debug.xml
D src/etc/prepare-aop.xml
D src/etc/aop-messaging-server.xml
D tests/src/org/jboss/test/messaging/tools/aop/PoisonInterceptor.java
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup2.patch, backup3.patch, patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:52 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: backup5.patch
Backup5:
clebert@clebert-laptop:/extra/clebert/workspaces/jboss-messaging-trunk/mina$ svn info
Path: .
URL: https://svn.jboss.org/repos/messaging/branches/Branch_JBMESSAGING-544
Repository Root: https://svn.jboss.org/repos/messaging
Repository UUID: b6fe21fe-e719-0410-baf4-a14e395396c4
Revision: 3435
Node Kind: directory
Schedule: normal
Last Changed Author: jmesnil
Last Changed Rev: 3431
Last Changed Date: 2007-12-06 10:38:05 -0600 (Thu, 06 Dec 2007)
D src/main/org/jboss/jms/server/endpoint/advised
D src/main/org/jboss/jms/server/endpoint/advised/ConnectionAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/BrowserAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/SessionAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/ConnectionFactoryAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/ConsumerAdvised.java
D src/main/org/jboss/jms/server/endpoint/advised/AdvisedSupport.java
D src/main/org/jboss/jms/server/container/ServerLogInterceptor.java
D src/main/org/jboss/jms/client/container/ClientLogInterceptor.java
D src/main/org/jboss/jms/client/container/ConnectionAspect.java
D src/main/org/jboss/jms/client/container/JmsClientAspectXMLLoader.java
D src/main/org/jboss/jms/client/container/StateCreationAspect.java
D src/main/org/jboss/jms/client/container/ExceptionInterceptor.java
D src/main/org/jboss/jms/client/container/ClusteringAspect.java
D src/main/org/jboss/jms/client/container/BrowserAspect.java
D src/main/org/jboss/jms/client/container/ProducerAspect.java
D src/main/org/jboss/jms/client/container/SessionAspect.java
D src/main/org/jboss/jms/client/container/DelegateIdentity.java
D src/main/org/jboss/jms/client/container/ConsumerAspect.java
D src/main/org/jboss/jms/client/ClientAOPStackLoader.java
D src/etc/aop-messaging-client.xml
D src/etc/aop-messaging-client-debug.xml
D src/etc/prepare-aop.xml
D src/etc/aop-messaging-server.xml
D tests/src/org/jboss/test/messaging/tools/aop/PoisonInterceptor.java
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup2.patch, backup3.patch, backup5.patch, patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:25 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: (was: backup2.patch)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup5.patch, patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:25 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: (was: backup3.patch)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup5.patch, patch.diff
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:27 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: (was: backup5.patch)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup-r3568.patch
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:27 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: (was: patch.diff)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup-r3568.patch
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:27 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: backup-r3568.patch
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup-r3568.patch
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:29 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: status-r3568.patch
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Attachments: backup-r3568.patch, status-r3568.patch
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:06 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: (was: status-r3568.patch)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:06 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Attachment: (was: backup-r3568.patch)
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:11 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Comment: was deleted
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:11 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Comment: was deleted
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:11 a.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Comment: was deleted
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:04 p.m.
New subject: [JBoss JIRA] Closed: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic closed JBMESSAGING-681.
---------------------------------------
Resolution: Done
The interceptor part is being done as part of this linked feature request now.
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:18 p.m.
New subject: [JBoss JIRA] Reopened: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic reopened JBMESSAGING-681:
-----------------------------------------
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Clebert Suconic
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:34 p.m.
New subject: [JBoss JIRA] Updated: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Clebert Suconic updated JBMESSAGING-681:
----------------------------------------
Assignee: Tim Fox (was: Clebert Suconic)
Since you're doing most of this work, I'm assigning this back to you
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:24 p.m.
New subject: [JBoss JIRA] Closed: (JBMESSAGING-681) Refactor client side model
[ http://jira.jboss.com/jira/browse/JBMESSAGING-681?page=all ]
Tim Fox closed JBMESSAGING-681.
-------------------------------
Resolution: Done
Refactor client side model
--------------------------
Key: JBMESSAGING-681
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-681
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Priority: Critical
Fix For: 2.0.0 Alpha
Currently, client side JMS functionality is implemented in a set of aspects:
SessionAspect, TransactionAspect, FactoryAspect, etc. There seems no good reason to have
these as separate aspects since we either provide all the jms functionality or none of
it.
Having the functionality distributed across several aspects makes it hard to communicate
between them meaning the code is messy and hard to follow.
We should consolidate into one aspect, from which hang a set of classes Session,
Connection, Consumer etc which implement the jms functionality in a nice OO way. This will
make the code simpler and easier to understand and possibly more performant since we would
avoid unnecessary calls through the stack.
The classes should be chosen to represent generic messaging, not just JMS (e.g. no need
for a producer).
We also need to have an extension point so customers can add their own vanilla
interceptors.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6558
days inactive
7081
days old
28 comments
4 participants
participants (4)
-
Clebert Suconic (JIRA) -
Ovidiu Feodorov (JIRA)
-
Tim Fox (JIRA) -
Tim Fox (JIRA)