RE: [jbosscache-dev] migrating data stored in 1.x format to VAM format

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: _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev