Hi, marc fleury wrote: > |Do you want all instances of javax.transaction.Transaction > |floating around the server to be instances of a JBoss-specific > |extension of this interface that knows how to serialize itself? > > yes
I still oppose this, for the reasons I already mentioned. Guess we better work to find a solution that we can both accept. Since you said nothing more about the pluggability issue, i assume we got this sorted out. Otherwise let me know. But since you are so strongly advocating wrapping up all calls to one of the central parts of the server, I guess that you have stronger arguments for it than just the code looking ugly in the MarshalledInvocation object. Please let me know your arguments. Note that the design with the TPCFactory and TPCImporter wasn't some quick hack. I gave it careful consideration. What I came up with is so common that it even has its own acronym in the transaction world: CRM (Communications Resource Manager): The entity that takes care of interfacing the core transaction service to the transports that need to support transaction propagation. I agree that changing the Transaction object to be Serializable would make the MarshalledInvocation implementation look more beautiful, but: 1) It would _only_ help the JRMP protocol invocation. 2) All calls to the transaction service from all other parts of JBoss will have to pass an extra layer, unless the transaction service has been hacked. 3) We have a bit extra load on the allocator and garbage collector, because multible copies of the same Transaction may float around the server. 3) Everybody would have to pay the penalty in 2), even if they do not use the JRMP protocol at all! I am willing to work with you to get your problem sorted out, but I am not willing to accept wrapping all calls to the Transaction and TransactionManager objects in an extra layer - unless you have some stronger arguments in support of it. Maybe, if you explicitly point out the problems you have with this in the current code, i can help you better. Please do. I think we can find a better solution. Best Regards, Ole Husgaard. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
