AW: Recognize shutdown event in tomcats Realm instance

[Arno Schäfer]

> Over-ride RealmBase.stopInternal() and don't forget to call
> super.stopInternal() when you do.

Thanks a lot Mark for the fast answer!
I have overlooked that, sorry.

- Arno

-
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

[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

[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: Why move to tomcat9 (UNCLASSIFIED)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 8/29/18 10:51, Lueders, Paul T CIV USARMY NGIC (US) wrote:
> I would like to migrate from tomcat 7.0.90 to the latest version
> of tomcat9.  Is there a document that lists the benefits of tomcat9
> and the differences between tomcat7 and tomcat9

http://tomcat.apache.org/whichversion.html

Shows what versions of various specifications are supported.

WebSocket support was added in 7.0.x so there isn't anything that you
are really *missing* by staying on 7.0.x.

However, there have been many changes to improve performance and
remove support for unused stuff (e.g. Java-BIO) that may improve
performance and scalability.

For my money, I'd plan on definitely moving to something other than
7.0.x soon, because (based upon your email address), I'm guessing it
takes a long time to get a big change like this made. Tomcat 7.0.x
isn't on the chopping-block, yet, but it *will* be the next one to be
left unsupported.

The major difference between 8.5.x and 9.0.x is that 9.0.x is even
stricter about a few things. I might try installing Tomcat 9.0.x into
a testing environment and start working-through the application to see
if there are any parts that stop working or start behaving less than
ideally. If you have any issues, post here and we can help. It may be
that 8.5.x is better for you in the short-term, but you should have
your sights set on 9.0.x for the future.

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAluG5oYACgkQHPApP6U8
pFgCPw//QMperLE6uap9fqYx8iA+7SBlHhWPJRIQS7HK/1Cj8xY29s2VYWyCj7Pr
mzMsE5VMY09aByQE/xuq8v4SLc3onWkwX3HReYsX4dAfd7G4tL90bgS1Iqmq3I3d
yd0dbJWiqfqVniAJ1ujtYo8uir3SShcUtwC+FPQjYcHUv0L4xn+T6Kigpgv440LN
QmGlZF4JuXXVKHRxiKNYrjDVpb2F38GYcpmn7fhcGO8zP4oqTG7hv+T6/5CO2hF/
d8mIvVrBzUqRAVfZS03mFkvqn3o6i3IAqe3mIswBvAgPvg+Ow+vWcqRjWdfbs1bd
2eVBSFLZiyGZHEVrIvdIpmXRiJicwFRBdimX3tFbir7ixinbSy2kUKX5EwuRiJIF
XrT5dt+0SnQ/GzSwTHC6ZgUg+4poF2db+EJWXLiGlOjyLCWNj454e4VfJdRf/fGv
KrhJ/rUCXEklAtfBoVrFryLkYmqefuaRtujo8G18zcgxJ/9uNbu3Na7xhKez1H7i
bc6+cngsLPjkfPU1WUjRkNrcDECSNCLtEiGl0hvf01qlaZXOzznbMEPy2iipNz4F
zV0EVNlak3VTY+mRa3XZJFiL+2GqvR4BUN/9YSXxY2k0hWaEUyP4duQvD5GZO4QJ
5arVye+a+jsdvXvHTACElq/K0CwLVAarQICSQUMHtU2ceZrgtDE=
=KsEi
-END PGP SIGNATURE-

-
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

[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

[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,

RE: Why move to tomcat9 (UNCLASSIFIED)

[Gillett, Phil]

We use Footprints 12 and the requirement IS to use Tomcat 7.x, which at this 
time are using 7.0.86 and need to update to 7.0.90 (having some problems at 
this time, though).
7.0.90 IS the latest version to fix the latest security issues.

-Original Message-
From: Mark Thomas  
Sent: Wednesday, August 29, 2018 10:23 AM
To: users@tomcat.apache.org
Subject: Re: Why move to tomcat9 (UNCLASSIFIED)

On 29/08/18 15:56, M. Manna wrote:
> The key benefit is - You get all recent CVE patches which protects 
> your product more from known vulnerabilities.

Not correct. All currently supported Tomcat versions (7.0.x, 8.5.x and
9.0.x) receive security fixes.

> You can see a comparison table here -
> http://tomcat.apache.org/whichversion.html
> 
> I would recommend that you review Servlet, Connector, and Java version 
> related changes carefully (if you have hard dependency on them). it 
> would be better to move to 8.5 first in my opinion, but no harm going 
> to 9.x directly if your product is okay.

The Tomcat community supports 3 major versions in parallel. Currently that is 
7.0.x, 8.5.x and 9.0.x. 7.0.x will be the next to reach end-of-life - although 
not for a good while yet. [1]

Depending on how long your organisation takes to upgrade from one major version 
to another, you might want to start your migration soon. The longer this 
process takes for your organisation, the better off you are moving to 9.0.x 
since it will be supported for longer than 8.5.x.

Also, see http://tomcat.apache.org/migration.html

Mark

[1] https://markmail.org/message/5klk3rtf4mb2aacv

> Regards,
> 
> On Wed, 29 Aug 2018 at 15:52, Lueders, Paul T CIV USARMY NGIC (US) < 
> paul.t.lueders@mail.mil> wrote:
> 
>> CLASSIFICATION: UNCLASSIFIED
>>
>> I would like to migrate from tomcat 7.0.90 to the latest version of 
>> tomcat9.  Is there a document that lists the benefits of tomcat9 and 
>> the differences between tomcat7 and tomcat9
>>
>> Thanks
>> Paul
>> CLASSIFICATION: UNCLASSIFIED
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


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


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

Re: Why move to tomcat9 (UNCLASSIFIED)

[Mark Thomas]

On 29/08/18 15:56, M. Manna wrote:
> The key benefit is - You get all recent CVE patches which protects your
> product more from known vulnerabilities.

Not correct. All currently supported Tomcat versions (7.0.x, 8.5.x and
9.0.x) receive security fixes.

> You can see a comparison table here -
> http://tomcat.apache.org/whichversion.html
> 
> I would recommend that you review Servlet, Connector, and Java version
> related changes carefully (if you have hard dependency on them). it would
> be better to move to 8.5 first in my opinion, but no harm going to 9.x
> directly if your product is okay.

The Tomcat community supports 3 major versions in parallel. Currently
that is 7.0.x, 8.5.x and 9.0.x. 7.0.x will be the next to reach
end-of-life - although not for a good while yet. [1]

Depending on how long your organisation takes to upgrade from one major
version to another, you might want to start your migration soon. The
longer this process takes for your organisation, the better off you are
moving to 9.0.x since it will be supported for longer than 8.5.x.

Also, see http://tomcat.apache.org/migration.html

Mark

[1] https://markmail.org/message/5klk3rtf4mb2aacv

> Regards,
> 
> On Wed, 29 Aug 2018 at 15:52, Lueders, Paul T CIV USARMY NGIC (US) <
> paul.t.lueders@mail.mil> wrote:
> 
>> CLASSIFICATION: UNCLASSIFIED
>>
>> I would like to migrate from tomcat 7.0.90 to the latest version of
>> tomcat9.  Is there a document that lists the benefits of tomcat9 and the
>> differences between tomcat7 and tomcat9
>>
>> Thanks
>> Paul
>> CLASSIFICATION: UNCLASSIFIED
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 


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

Re: Why move to tomcat9 (UNCLASSIFIED)

[M. Manna]

The key benefit is - You get all recent CVE patches which protects your
product more from known vulnerabilities.

You can see a comparison table here -
http://tomcat.apache.org/whichversion.html

I would recommend that you review Servlet, Connector, and Java version
related changes carefully (if you have hard dependency on them). it would
be better to move to 8.5 first in my opinion, but no harm going to 9.x
directly if your product is okay.

Regards,

On Wed, 29 Aug 2018 at 15:52, Lueders, Paul T CIV USARMY NGIC (US) <
paul.t.lueders@mail.mil> wrote:

> CLASSIFICATION: UNCLASSIFIED
>
> I would like to migrate from tomcat 7.0.90 to the latest version of
> tomcat9.  Is there a document that lists the benefits of tomcat9 and the
> differences between tomcat7 and tomcat9
>
> Thanks
> Paul
> CLASSIFICATION: UNCLASSIFIED
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Why move to tomcat9 (UNCLASSIFIED)

[Lueders, Paul T CIV USARMY NGIC (US)]

CLASSIFICATION: UNCLASSIFIED

I would like to migrate from tomcat 7.0.90 to the latest version of tomcat9.  
Is there a document that lists the benefits of tomcat9 and the differences 
between tomcat7 and tomcat9

Thanks
Paul
CLASSIFICATION: UNCLASSIFIED

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

Re: Recognize shutdown event in tomcats Realm instance

[Mark Thomas]

On 29/08/18 12:43, Arno Schäfer wrote:
> Hi all,
> 
> we use our own Realm implementation in our webapps. If tomcat shuts down, we 
> have to do some clean up
> in this instance to speed up the shutdown.
> In our web application we do this in the ServletContextListener instance in 
> 'contextDestroyed(...)' method.
> What is the right place to do this in tomcat's Realm instance? Do I have to 
> implement some notification code
> or does it work over a RealmBase method?

Over-ride RealmBase.stopInternal() and don't forget to call
super.stopInternal() when you do.

Mark

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

Recognize shutdown event in tomcats Realm instance

[Arno Schäfer]

Hi all,

we use our own Realm implementation in our webapps. If tomcat shuts down, we 
have to do some clean up
in this instance to speed up the shutdown.
In our web application we do this in the ServletContextListener instance in 
'contextDestroyed(...)' method.
What is the right place to do this in tomcat's Realm instance? Do I have to 
implement some notification code
or does it work over a RealmBase method?

I found nothing about that in the documentation.

Best regards
- Arno
_

Vorsitzender des Aufsichtsrats: Lothar Pauly
Vorstand: Diederik Vos (CEO) ? Ralph Gillessen (COO) ? René Gawron (CFO)
Martin Hodgson (Executive Director Management Consulting)
SQS AG ? Stollwerckstraße 11 ? 51149 Köln
Sitz der Gesellschaft: Köln ? Amtsgericht Köln, HRB 12764

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient
(or have received this e-mail in error) please notify the sender immediately 
and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.