[kepler-users] Kepler 2.0, intermodular libraries conflict

Tue Aug 10 03:00:27 PDT 2010

Hi David and Matt,

First of all, what do you exactly mean by "running the tests"? Are there  
some general Kepler test suites which should be passed? Or does it mean  
that in order to update libraries, I should check functionality of  
different Kepler actors, etc.?

Second, I'll try to use separate class loader for my module. I've already  
found the docs about it.

Thank you for answers,
Tomek

Matt Jones <jones at nceas.ucsb.edu>:

> I think it would be a good idea to upgrade these jar files to more recent
> releases, assuming that testing shows no adverse effects on the modules  
> that
> depend on them.  As these are in very low-level modules, there may be  
> many
> different modules that depend on them, so we would need to test several
> different suites, and there may need to be some refactoring if any of  
> these
> libraries has modified their APIs.  Do you know if the APIs have  
> changed, or
> were they only extended in backwards-compatible ways?
>
> Although two of these are used extensively (log4j and xerces) and so
> rightfully belong in common, the httpclient jar file might be more
> restricted in which modules use it.  Its probably worth looking at the
> dependency tree and seeing which actors use that jar file, and consider
> splitting those actors out into their own module(s) to reduce these  
> types of
> conflicts.
>
> So, if you want to propose particular upgrades for the jars in common and
> actors modules, please try replacing them and running the tests and we'll
> try to fit the changes into an upcoming release -- file an enhancement
> request with the results of your testing and we can take it from there.   
> In
> any case, as David said, you may be able to override for your module by
> using your own classloader to get started over the shorter term.
>
> Matt
>
> PS This kind of development discussion is more appropriate for the
> kepler-dev list -- kepler-users is more about using the system, rather  
> than
> developing extensions to it, although the line between the two is very  
> grey.
>
> On Mon, Aug 9, 2010 at 1:01 PM, David Welker  
> <david.v.welker at gmail.com>wrote:
>
>> Hi Tomasz,
>>
>> This issue can be a little tricky.
>>
>> The first thing to note is that you can override other jars. If you put
>> different jars in your module, they will be used by your module AND all  
>> of
>> Kepler instead of the jars that are there. The problem with this arises  
>> in
>> situations where your jars are not compatible with Kepler. Then things  
>> can
>> break. But this is the first approach to try. Just put your jars in  
>> your own
>> module and see if things work. It sounds like you have already done  
>> this.
>>
>> The second thing to note is that it is possible to use multiple class
>> loaders. That is, you can use a separate class loader to load different  
>> jars
>> for your module than for the rest of Kepler. Documentation about how to  
>> do
>> this is included in the build system documentation. This might work. The
>> thing is, I have had problems with this recently when someone was  
>> trying to
>> use a different class loader for Log4j. So, this is not guaranteed to  
>> work
>> and this feature has some bugs that cause it to not work at least some  
>> of
>> the time. Also, of course your IDE is probably not going to know about  
>> the
>> separate class loader, and your IDE might get confused.
>>
>> The third thing to note is that it might be possible to talk to the  
>> Kepler
>> leadership team and get these jars upgraded in Kepler. This would be a  
>> very
>> reasonable request to make if neither of the above solutions work for  
>> you.
>>
>> -David
>>
>> On Fri, Aug 6, 2010 at 9:11 AM, Tomasz Żok <tzok at man.poznan.pl> wrote:
>>
>>> Hi,
>>>
>>> I am developing a new module which uses several external .jar  
>>> libraries.
>>> These are mostly well known and widely used libraries like log4j, etc.
>>> However I found out that there is a conflict in library versions that
>>> disables my module totally. I pinpointed the issue to the minimal  
>>> subset of
>>> conflicting jars:
>>> actors/lib/jar/commons-httpclient-3.0.1.jar
>>> common/lib/jar/log4j-1.2.8.jar
>>> common/lib/jar/sms/xercesImpl.jar
>>>
>>> My module uses:
>>> commons-httpclient-3.1.jar
>>> log4j-1.2.16.jar
>>> xercesImpl-2.7.1.jar
>>>
>>> My libraries are in the classpath when I run Kepler, but they are not
>>> loaded, because the three conflicting ones precede them. What should I  
>>> do in
>>> such situation? Should I somehow formally ask Kepler devs to update  
>>> theirs
>>> or should I do anything with my libraries?
>>>
>>> Best regards,
>>> Tomek
>>>
>>>
>>> --
>>> Tomasz Zok
>>> Poznan Supercomputing and Networking Center
>>> ul. Noskowskiego 10, 61-704 Poznan, POLAND
>>> http://www.man.poznan.pl
>>> _______________________________________________
>>> Kepler-users mailing list
>>> Kepler-users at kepler-project.org
>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>>>
>>
>>
>> _______________________________________________
>> Kepler-users mailing list
>> Kepler-users at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>>
>>

-- 
Tomasz Zok
Poznan Supercomputing and Networking Center
ul. Noskowskiego 10, 61-704 Poznan, POLAND
http://www.man.poznan.pl