Re: Possible Discrepancy in ClassLoading order when running in Linux

2018-08-29 Thread M. Manna
Please ignore my question.

Seems like someone decided to try out a "Special" classloader - didn't have
the information before.

Thanks for responding anyway.

Regards,

On Wed, 29 Aug 2018 at 20:20, M. Manna  wrote:

> Thanks mark. We aren’t using delegation, but even with delegation classes
> directory are looked up first in the order.
>
> Tomcat version 8.5.32.
>
> Thanks,
>
> On Wed, 29 Aug 2018 at 19:31, Mark Thomas  wrote:
>
>> On 29/08/18 19:09, M. Manna wrote:
>> > Hello,
>> >
>> > I am not sure if this is a bug or something specific to our
>> implementation,
>> > so wanted to share that with others. Please forgive my idiocy.
>> >
>> > We took a verbose classloading on Windows and it loaded two classes from
>> > two different locations.
>> >
>> > 1) *SomeUtils*.class from *com.my.package.name <
>> http://com.my.package.name>*
>> > - placed in WEB-INF/classes
>> > 2) *SomeOtherUtils*.class from *com.my.package.name
>> > * - placed in myjar.jar in WEB-INF/lib
>> >
>> > In Windows, we can load the SomeUtils.class from the "classes" directory
>> > (correct) and SomeOtherUtils.class from jar (in lib directory, also
>> > correct). The class *SomeUtils *exist in *both **lib *and *classes*.
>> but as
>> > per documentation, webapp loader will load things from classes dir
>> first,
>> > and then lib. And it won't load the same class from *lib *if found in
>> *classes
>> > *first. And it also honours the contract "Child loader must not load
>> same
>> > class loaded by parent". So identical package name isn't a problem.
>> >
>> > When we deployed in Linux, it didn't quite happen. We saw that "lib" was
>> > always looked up first. We understand that SomeUtils.class duplicated in
>> > both lib and classes is not a "Good" practice. But what we don't
>> understand
>> > is why webapp classloader isn't searching classes directory and finding
>> it
>> > first? Is there something fundamentally different when it comes to Linux
>> > e.g. ordering/searching which is out of tomcat's control?
>> >
>> > We don't have the verbose log from Linux yet, but meanwhile any info is
>> > helpful.
>>
>> Tomcat version?
>>
>> WEB-INF/classes should always be searched before WEB-INF/lib by default
>> but there are ways to configure the resources implementation to modify
>> the search order.
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>


Re: Possible Discrepancy in ClassLoading order when running in Linux

2018-08-29 Thread M. Manna
Thanks mark. We aren’t using delegation, but even with delegation classes
directory are looked up first in the order.

Tomcat version 8.5.32.

Thanks,

On Wed, 29 Aug 2018 at 19:31, Mark Thomas  wrote:

> On 29/08/18 19:09, M. Manna wrote:
> > Hello,
> >
> > I am not sure if this is a bug or something specific to our
> implementation,
> > so wanted to share that with others. Please forgive my idiocy.
> >
> > We took a verbose classloading on Windows and it loaded two classes from
> > two different locations.
> >
> > 1) *SomeUtils*.class from *com.my.package.name <
> http://com.my.package.name>*
> > - placed in WEB-INF/classes
> > 2) *SomeOtherUtils*.class from *com.my.package.name
> > * - placed in myjar.jar in WEB-INF/lib
> >
> > In Windows, we can load the SomeUtils.class from the "classes" directory
> > (correct) and SomeOtherUtils.class from jar (in lib directory, also
> > correct). The class *SomeUtils *exist in *both **lib *and *classes*. but
> as
> > per documentation, webapp loader will load things from classes dir first,
> > and then lib. And it won't load the same class from *lib *if found in
> *classes
> > *first. And it also honours the contract "Child loader must not load same
> > class loaded by parent". So identical package name isn't a problem.
> >
> > When we deployed in Linux, it didn't quite happen. We saw that "lib" was
> > always looked up first. We understand that SomeUtils.class duplicated in
> > both lib and classes is not a "Good" practice. But what we don't
> understand
> > is why webapp classloader isn't searching classes directory and finding
> it
> > first? Is there something fundamentally different when it comes to Linux
> > e.g. ordering/searching which is out of tomcat's control?
> >
> > We don't have the verbose log from Linux yet, but meanwhile any info is
> > helpful.
>
> Tomcat version?
>
> WEB-INF/classes should always be searched before WEB-INF/lib by default
> but there are ways to configure the resources implementation to modify
> the search order.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Possible Discrepancy in ClassLoading order when running in Linux

2018-08-29 Thread Mark Thomas
On 29/08/18 19:09, M. Manna wrote:
> Hello,
> 
> I am not sure if this is a bug or something specific to our implementation,
> so wanted to share that with others. Please forgive my idiocy.
> 
> We took a verbose classloading on Windows and it loaded two classes from
> two different locations.
> 
> 1) *SomeUtils*.class from *com.my.package.name *
> - placed in WEB-INF/classes
> 2) *SomeOtherUtils*.class from *com.my.package.name
> * - placed in myjar.jar in WEB-INF/lib
> 
> In Windows, we can load the SomeUtils.class from the "classes" directory
> (correct) and SomeOtherUtils.class from jar (in lib directory, also
> correct). The class *SomeUtils *exist in *both **lib *and *classes*. but as
> per documentation, webapp loader will load things from classes dir first,
> and then lib. And it won't load the same class from *lib *if found in *classes
> *first. And it also honours the contract "Child loader must not load same
> class loaded by parent". So identical package name isn't a problem.
> 
> When we deployed in Linux, it didn't quite happen. We saw that "lib" was
> always looked up first. We understand that SomeUtils.class duplicated in
> both lib and classes is not a "Good" practice. But what we don't understand
> is why webapp classloader isn't searching classes directory and finding it
> first? Is there something fundamentally different when it comes to Linux
> e.g. ordering/searching which is out of tomcat's control?
> 
> We don't have the verbose log from Linux yet, but meanwhile any info is
> helpful.

Tomcat version?

WEB-INF/classes should always be searched before WEB-INF/lib by default
but there are ways to configure the resources implementation to modify
the search order.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Possible Discrepancy in ClassLoading order when running in Linux

2018-08-29 Thread M. Manna
Hello,

I am not sure if this is a bug or something specific to our implementation,
so wanted to share that with others. Please forgive my idiocy.

We took a verbose classloading on Windows and it loaded two classes from
two different locations.

1) *SomeUtils*.class from *com.my.package.name *
- placed in WEB-INF/classes
2) *SomeOtherUtils*.class from *com.my.package.name
* - placed in myjar.jar in WEB-INF/lib

In Windows, we can load the SomeUtils.class from the "classes" directory
(correct) and SomeOtherUtils.class from jar (in lib directory, also
correct). The class *SomeUtils *exist in *both **lib *and *classes*. but as
per documentation, webapp loader will load things from classes dir first,
and then lib. And it won't load the same class from *lib *if found in *classes
*first. And it also honours the contract "Child loader must not load same
class loaded by parent". So identical package name isn't a problem.

When we deployed in Linux, it didn't quite happen. We saw that "lib" was
always looked up first. We understand that SomeUtils.class duplicated in
both lib and classes is not a "Good" practice. But what we don't understand
is why webapp classloader isn't searching classes directory and finding it
first? Is there something fundamentally different when it comes to Linux
e.g. ordering/searching which is out of tomcat's control?

We don't have the verbose log from Linux yet, but meanwhile any info is
helpful.

Thanks,