[jbosscache-dev] finishing JBCACHE-964 - refactoring JDBCCacheLoaderOld and any source depending on it to "migration" path

[Galder Zamarreno]

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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 
> -- 
> Manik Surtani
> 
> Lead, JBoss Cache
> JBoss, a division of Red Hat
> 
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
> 
> 

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat