On 29 July 2014 11:12, Jörg Schaible <joerg.schai...@swisspost.com> wrote:
> Gilles wrote:
>
>>> [...]
>>>
>>> == Java classloader ==
>>>
>>> The Java runtime system only allows a single instance of a class to
>>> exist in a given classloader.
>>> Classes are uniquely identified using the package name and class
>>> name.
>>>
>>> For example, the class {{{Utils}}} in the package
>>> {{{org.apache.commons.example}}} can only appear once in a
>>> classloader.
>>>
>>> The classloader uses the classpath to find the classes needed by an
>>> application.
>>>
>>> If the classpath contains more than one jar which contains the above
>>> Utils class, then the JVM will load only one of the instances.
>>>
>>> If the class instances in the different jars are identical, then this
>>> is not a problem, but if there are two different versions of the
>>> class, the classloader may choose the wrong one. And different JVMs
>>> may process the classpath in a different order.
>>
>> Is that correct?
>>
>> Excerpt from
>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/classpath.html:
>> -----
>> The order in which you specify multiple class path entries is
>> important.
>> The Java interpreter will look for classes in the directories in the
>> order they appear in the class path variable.
>> -----
>>
>> Gilles
>>
>>> [...]
>
> If your jars are in the WEB-INF/lib folder of a web application ... do you
> know in which sequence the application server adds those jars to the
> classpath ??
No idea, but not really relevant to this issue, as the user has full
control over which jars are in the folder.
The issue with the Maven classpath is that the contents depend on the
{gid, aid} pairs.
Maven must be given the correct info.
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
