[Design of JBossCache] - Re: Default classloader for deserialization
by scott.stark@jboss.org
"bstansberry(a)jboss.com" wrote :
| Problem with this is it requires an integration layer to register the classloader, manage the lifecycle, etc. It's also built around an assumption that different regions of the cache use different classloaders. Overly complex and painful for a simple ear that wants to deploy a cache from the ear and use it.
|
| It would be nice to make it easy for a user to specify during the configuration stage that the TCCL should be registered as the classloader for the entire cache and that the ordinary create/destroy lifecycle methods should deal with the classloader.
|
To me this is another wrapper that integrates well with this usage. Its an mbean service/mc bean that performs the same deployment level integration as the other jboss cache based aspects. This is an independent distributed cache usage outside of any ejb3/hibernate/session usage?
I guess I'm not clear on what the point of this thread is. The only concern it raises is that if we are promoting indpendent use of jboss cache, it leads to an obvious conflict of versions when an ear is trying to deploy a version of jboss cache that differs from that bundled with the server. This either requires obfuscation of the package names or very careful control of the container class loading setup.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989454#3989454
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989454
19 years, 4 months
[Design of JBossCache] - Re: Default classloader for deserialization
by bstansberry@jboss.com
JBC does have a mechanism for encapsulating the classloading aspect (TreeCacheMarshaller) and an API for code that uses it to register the classloader and manage the lifecycle. We need to be sure to use this mechanism for our own services that use JBC (i.e. doing that in Hibernate is the fix for JBCLUSTER-150.)
Problem with this is it requires an integration layer to register the classloader, manage the lifecycle, etc. It's also built around an assumption that different regions of the cache use different classloaders. Overly complex and painful for a simple ear that wants to deploy a cache from the ear and use it.
It would be nice to make it easy for a user to specify during the configuration stage that the TCCL should be registered as the classloader for the entire cache and that the ordinary create/destroy lifecycle methods should deal with the classloader.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989444#3989444
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989444
19 years, 4 months
[Design of JCA on JBoss] - Re: JBossTS/JBossJCA XA/Local transactions
by mark.little@jboss.com
"bill.burke(a)jboss.com" wrote : Our JCA implementation already does this:
|
| log.warn("Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure.");
|
I'll talk to the team tomorrow, but how to implement it and what to issue in terms of warnings is straightforward. But it will come with some vary clear references to the docs which will explain what's going on. Supporting this makes me uncomfortable. Adding text and warnings so try to prevent users from doing this makes me less uncomfortable ;-)
anonymous wrote :
| I thought this message had been turned off, I guess it was just clarified I think the old message was something very cryptic like:
|
| "You are not getting the behavior you expect"
|
| And this confused the shit outta people.
|
Yes, that's not a good warning.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989415#3989415
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989415
19 years, 4 months