Re: [jbosscache-dev] finishing JBCACHE-964 - refactoring JDBCCacheLoaderOld and any source depending on it to "migration" path
I had some further thoughts to this:
I have decided not to move JDBCCacheLoaderOld to the migration area. The
reason is because in tests/perf there're some manual tests which
benchmark old and new JDBCCacheLoader implementations, and I think these
should stay there. Moving this to migration would require migration
source and main source to be compiled before then compiling the test
classes for migration and then source, which would require some major
restructuring of the build file.
We might want to do all this at a later stage when we look at the
division of modules as mentioned in Manik's reply.
One thing I'm gonna be committing though is a new class called
JDBCCacheLoaderOldConfig. Current AdjListJDBCCacheLoaderConfig, which is
a production class has, in my opinion, an unnecessary dependency on
JDBCCacheLoaderOldConfig:
public AdjListJDBCCacheLoaderConfig()
{
setClassName(JDBCCacheLoaderOld.class.getName());
}
/**
* For use by {@link JDBCCacheLoaderOld}.
*
* @param base generic config object created by XML parsing.
*/
AdjListJDBCCacheLoaderConfig(IndividualCacheLoaderConfig base)
{
setClassName(JDBCCacheLoaderOld.class.getName());
populateFromBaseConfig(base);
}
Besides, this also leads to setClassName being called twice, first with
the old one and then Mircea's new JDBCCacheLoader.
Instead, I'm making JDBCCacheLoaderOldConfig extend
AdjListJDBCCacheLoaderConfig and set the class to JDBCCacheLoaderOld. It
makes more sense to me to do it that way.
I should be committing this later tonight, closing JBCACHE-964 in time
for CR1.
Manik Surtani wrote:
+1 on this for now.
In future we should discuss how we deal with such modules though, esp
once we move to maven/svn. I'll kick off a discussion on this fairly soon.
Cheers,
Manik
On 19 Apr 2007, at 23:08, Galder Zamarreno wrote:
> Hi,
>
> JBCACHE-964 is getting close to completion. I have docu and some
> refactoring pending which I'd like to get some consensus on:
>
> JDBCCacheLoaderOld is a classloader that it's in the main code for
> legacy purpouses. As part of JBCACHE-964, I have created a migration
> directory that includes a classloader to transform data from 1.x to 2.x.
>
> I was talking to Manik about moving JDBCCacheLoaderOld to this
> migration directory, removing it from the main source directory. That
> means that if a customer wants to use it, they need to add
> jbosscache-cacheloader-migration.jar to their classpath which is fine,
> making the customer think twice before doing it.
>
> As part of this refactoring, AdjListJDBCCacheLoaderCompatibilityTest
> which relies on JDBCCacheLoaderOld would also be moved to the tests
> directory of the migration path (quite likely
> migration/tests/functional) and similar thing would occur to
> OldImplBenchmark (possibly to migration/tests/perf which does not
> exist right now)
>
> This would require a bit of refactoring but I think it's minimal and
> removes non trunk source/test code from the main codebase.
>
> Thoughts?
>
> --
> 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
--
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
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat