+1000 This will greatly simplify many things, such as the trunk invoker client.
I'd like to suggest that we also consider basing UserTransaction on a transaction manager instance on the client: this would allow UserTransaction to use the same propagation mechanism as distributed transactions (shipping xids). Again, this would be easy with jmx on the client. Setting everything up without jmx would be considerably more difficult. david jencks On 2002.11.07 22:33:57 -0500 Dain Sundstrom wrote: > Why don't we require jmx on the client side? > > I bet it takes almost no memory and it has a small jar size. If do > require it on the client side, we can reuse all the services we are > building on the server, like a jcache mbean. It would also simply > server to client messages, which will be used for cache invalidations > and jms messages. This is because we can reuse the invoker > architecture. There will still be a problem with socket back channels > to clients on the other side of a firewall, but we would get a ton of > reuse and simplification. > > -dain > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
