RE: [jbosscache-dev] migrating data stored in 1.x format to VAM format
by Galder Zamarreno
Quick (but a bit lengthy :( ) update on this:
- I've created a new Marshaller called Legacy1xMarshaller (anyone's got a better name?) which extends o.j.c.m.AsbtractMarshaller that would do the job of marshalling stuff in the 1.x fashion. This is to be used by JDBCCacheLoader and FileCacheLoader if configured to use 1.x marshalling. This has the benefit that the code in these cache loaders only have to do getMarshaller().whatever... , making it very simple to switch from VAM to Legacy Marshaller.
- In order to do this, I need to add a new method to o.j.c.m.Marshaller called objectToStream(OutputStream). The reason for doing is so that FileCacheLoader just needs to call getMarshaller().objectToStream() when it's trying to store data. This will avoid having an if statement in storeAttributes() checking which Marshaller is used, and calling objectToObjectStream with the corresponding ObjectOutpuStream.
- The decision maker for which Marshaller to use is to be done in AbstractCacheLoader which will store the Marshaller used by CacheLoader. getMarshaller() would decide upon configuration, which Marshaller to use, whether the default cache.getMarshaller() which is VAM or the legacy one, making it quite clean to switch from to another.
- Configuration wise, I created Legacy1xMarshallingCacheLoaderConfig (I couldn't come up with a better name!) which extends IndividualCacheLoaderConfig. JDBCCacheLoaderConfig and FileCacheLoaderConfig will extend Legacy1xMarshallingCacheLoaderConfig instead.
- Inside Legacy1xMarshallingCacheLoaderConfig, I search for cache.loader.marshalling.1.x (name again!) boolean property in the <properties> section. If true, it uses legacy marshalling, and if false, which is default value, VAM.
- I have extended CacheLoaderTestsBase to create FileCacheLoaderLegacyMarshallingTest which tests the FileCacheLoader with legacy marshalling. I'll be doing the same for JDBCCacheLoader.
- Finally and one of the most important aspects, previous marhalling relies on these classes:
org.jboss.invocation.MarshalledValue;
org.jboss.invocation.MarshalledValueInputStream;
Which used to be located in jboss-minimal.jar in 1.x. There's v similar classes in AOP but not the same, so I'm gonna be creating a legacy directory in lib with this library. To avoid compile time dependency, Legacy1xMarshaller will be instantiated via reflection, so only people who actually use this will need this library. The library has no conflicts with existing 2.x libraries.
The last problem is that these two classes access org.jboss.logging.Logger that used to be in jboss-common.jar. Now this jar certainly classes with jboss-common-core.jar in 2.x, so what's I've done is get jboss-logging-spi.jar 2.0.2.GA and put it in the legacy directory.
So, we end up having two legacy libraries in lib/legacy but they're only needed at runtime if using 1.x marhalling. I guess it's the price to pay to make customer's life a bit easier.
The other alternative would be for 1.x marshaller not to use this org.jboss.invocation.* classes and just write to Object streams but I think these classes have an impact in the format of the marshalled data. Brian, do you know a bit more about the role of these classes?
A bit more complicated than initially expected but I can't see any easier way of providing backwards compatibility. Hopefully we should be able to phase it out asap, 3.x? :)
What this has shown as well is how different CacheLoaders marshalled things in a slightly different way which makes having a common framework for this even more necessary, i.e. VAM. :D
Hope you're not snoring by now ;)
If you have better ideas for the naming I used, speak up :)
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 31 January 2007 01:01
To: Manik Surtani
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] migrating data stored in 1.x format to VAM format
+1, VAM should be the default.
Only people who are resilient to change their existing stores to VAM should use the 1.x option, which would need explicitly definition.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: 30 January 2007 22:55
To: Galder Zamarreno
Cc: jbosscache-dev(a)lists.jboss.org
Subject: Re: [jbosscache-dev] migrating data stored in 1.x format to VAM format
I see what you mean, although I would like the default to be to use
the VAM.
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
On 30 Jan 2007, at 20:45, Galder Zamarreno wrote:
> Actually, the more I think about this, the less I like the idea of
> switching the marshalling from 1.x to 2.x at the CacheLoaders
> level, or at least forcing them to do so.
>
> Customers that want to use JBossCache 2.x might be reluctant to
> migrate their data from one format to the other. I can see how an
> existing customer might think this is a proper pain in the ass,
> independent of the benefits, and might reduce adoption among them.
>
> We want to remove barriers upgrading, but at the same time, we want
> new customer to use new marshalling, so I'd actually implement the
> possibility to use 1.x marshalling which is plan java serialization
> at the CacheLoader level. This could easily achieved adding a
> property to the <properties> section.
>
> Just note that this does not apply to the marshalling done at
> replication level as there's no hard data that needs migrating.
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-
> bounces(a)lists.jboss.org] On Behalf Of Galder Zamarreno
> Sent: 25 January 2007 13:07
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] migrating data stored in 1.x format to
> VAM format
>
> Hi all,
>
> I'm deferring http://jira.jboss.com/jira/browse/JBCACHE-879 to
> BETA2 because I still need to write this: http://jira.jboss.com/
> jira/browse/JBCACHE-882
>
> The reason I'm deferring it is because I can't see a
> straightforward way of doing such thing right now. Ideally, you
> should be able run a 1.x version (cache1) and a 2.x version
> (cache2) of JBC in the same VM so that you can do a loop of
> cache1.get() and call cache2.put(). However, I have doubts that
> that this approach will be free of class loading issues. What do
> you think?
>
> I was wondering whether Region based could help here, but I can't
> see right now how this could be done.
>
> Something I had in mind is having the capability of to start a
> cache with either 1.x marshalling or VAM marshalling, but oriented
> at being used only at the cache loader level. It wouldn't make much
> sense for replication because there's no hard data there.
>
>
> I thought that you could start two instances of cache 2.x, first
> with 1.x. marshalling and the other one with VAM both pointing to
> different JDBCCacheLoader stores. You could then get from the first
> using normal mmarshalling and put in the second one which has VAM
> marshalling active, what do you think?
>
> If you like the approach, I should be have it ready by BETA2.
>
> This last approach looks simpler to me, what do you think?
>
> Galder Zamarreño
> Sr. Software Maintenance Engineer
> JBoss, a division of Red Hat
>
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
19 years
Jarring jars
by Manik Surtani
The list of jars JBoss Cache ships with is growing. And this is, as
you can imagine, a PITA.
* Core libs - commons-logging, jgroups, concurrent (needed by JGroups
< 2.5), jboss-serialization, jboss-common-core
* Pojocache libs - trove, jboss-aop, javassist, microcontainer jars
(4 jars here!!)
* JDK1.4-compat distro: 4 extra jars here
* Optional jars: c3p0 (DB connection pooling for standalone use),
bdbje and jdbm for specific cache loaders.
Looking at how Bill's packaged libs up for embedded EJB, he's got an
ant task that jars up all the jars into a single file.
<jar jarfile="UberJar.jar">
<zipfileset file="jar1.jar" />
<zipfileset file="jar2.jar" />
...
</jar>
What do you think? This way the JBoss Cache distro can ship with a
minimal number of jars:
* Core: jboss-cache.jar, jboss-cache-deps.jar
* PojoCache: jboss-cache.jar, jboss-cache-deps.jar, pojo-cache-deps.jar
* JDK1.4-compat: jboss-cache.jar, jboss-cache-deps-JDK14.jar
* Optional jars
What do you guys think of this approach? It may mean a replication
of jars (you may already have commons-logging or jboss-serialization
in your libs) but these jars are small and not a huge impact on
size. What about wanting to swap out jars, e.g., JGroups?
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)surtani.org
Yahoo/AIM/Skype: maniksurtani
19 years
