Re: ELContext no longer available to tagfiles

[Mark Thomas]

On 24/03/17 22:52, Mike Strauch wrote:
> On Fri, Mar 24, 2017 at 3:21 PM, Mike Strauch
>  wrote:
>> ...  I’ll take a look.
> 
> Appears to be working.  Thanks again!

Great. Thanks for the confirmation.

Mark


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

Re: ELContext no longer available to tagfiles

[Mike Strauch]

On Tue, Mar 7, 2017 at 2:54 AM, Mark Thomas  wrote:
>
> I think I have fixed this. The fix includes a simplistic test case.
> Verification of the fix would be appreciated.
>
> Mark

Hey Mark,

Apologies, I just noticed your reply.  I see the fix in the 8.0.42
release.  I’ll take a look.

-- 
Mike Strauch
Lead Software Engineer, Hannon Hill
w. www.hannonhill.com
e mike.stra...@hannonhill.com

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

Re: ELContext no longer available to tagfiles

[Mike Strauch]

On Fri, Mar 24, 2017 at 3:21 PM, Mike Strauch
 wrote:
> ...  I’ll take a look.

Appears to be working.  Thanks again!

-- 
Mike Strauch
Lead Software Engineer, Hannon Hill
w. www.hannonhill.com
e mike.stra...@hannonhill.com

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

Re: Tomcat Not Responding (Resolved)

[Igal @ Lucee.org]

Chris,

On 3/24/2017 2:13 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Igal,

On 3/24/17 1:22 PM, Igal @ Lucee.org wrote:

I've traced the issue to an NPE thrown from my servlet.  I patched
it (https://github.com/lucee/Lucee/commit/0f30a7ef) and now it
works fine.

That's good to know, but an NPE thrown from an application shouldn't
be able to lock-up Tomcat. Can you reproduce this using an SSCCE[1]?


I agree.  That's the reason I created a simple html file and tested it, 
as those do not go through the Lucee servlet.


I will try to produce a reduced test case, but not sure how simple that 
would be.



Igal

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

Re: siteMinder implementation for our application

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Amith,

On 3/24/17 2:32 PM, Kikkeri, Amith wrote:
> Our application runs on tomcat7 (Port 80) and we don't use a web 
> server. We are implementing SSO and planning to use siteMinder.
> When trying to install siteMinder web agent, we realized that it is
> not recognizing tomcat. Please let me  know if there is an option
> to make siteMinder webagent work with tomcat7.

I'm sorry, but I don't understand how a web-based hotel-booking
platform has to do with SSO with Tomcat.

> If it is mandatory to use a web server, can we use IIS.

That depends upon what exactly you are trying to do. Can you give some
more explanation?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJY1Y0hAAoJEBzwKT+lPKRYKxYP/1VHqp90dyYWTYBjnmleaJFO
wptbgwMcE8r6GZQu0aefWH/4BKELkEkYvpGTYs3N59J72yILCQCnzD7QXp4cX9dt
/kxEIxNcHltFxZVU4SQhoxuRHhHksyR6NiloV9cV1OFn+sHiE+uphtzYtLd2rdBV
XsiUWOLTL2WIUn0/DidEAJsQ74789l3FIWPr6v6juAVZ4kekhGZ2+gCxCEnaLNZp
EHUh17US9bNTlT7nT7ozHjy5oivzJmfBYOB7VgZvhNfXUAYzMTUHKH4ceI2yndtA
SjOkF+ZVI9JPe/sNkB4+68287w5i01ImEAR/7plUSnR6PRdHa53pkKt3fGIR0X61
YWK38tgnNBSiORtZPwsEFlYGHYP8HubfSDTNqETqWzRSzFRFSNe/dXY7qeQfTt4+
LXilH5pnUsWiQXGuDv1rg+yje3tsBnTmmEX4aW8jhdyMhvVA4WqxMxczXJylaWsY
XlES/dGIspxZyTDViaVI1rY9FTEapu1xI112WAW0QtjPsgWz1cY8NaaYmPiMvq8+
nXLaOPsWSD0mChwMCwnypxoNmOrkq8wIPZHHPe6Az6vuENVCiCJbSv+Ex6UB1IMz
QjET0G534bTJ58TYBNpE7Ra09h8/mzXBa/oXgHt45glRbeNZBS9hSWfIMH4T9DBW
0NkX1kTnO7sCcfwhVLow
=hiJK
-END PGP SIGNATURE-

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

Re: Tomcat Not Responding (Resolved)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Igal,

On 3/24/17 1:22 PM, Igal @ Lucee.org wrote:
> On 3/23/2017 1:43 AM, Mark Thomas wrote:
>> If Tomcat is unresponsive, that would suggest a problem with
>> either the Acceptor or the Poller but both of those threads look
>> normal to.
>> 
>> You are going to need to do some more debugging.
>> 
>> Ideally, you need to configure your favourite IDE to do remote
>> debugging and then once the problem occurs, step through the code
>> as a single connection is handled and see where things go wrong.
> 
> I've traced the issue to an NPE thrown from my servlet.  I patched
> it (https://github.com/lucee/Lucee/commit/0f30a7ef) and now it
> works fine.

That's good to know, but an NPE thrown from an application shouldn't
be able to lock-up Tomcat. Can you reproduce this using an SSCCE[1]?

- -chris

[1] http://sscce.org/
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJY1YvyAAoJEBzwKT+lPKRYBrUP+wQKAw4Z/Pj1m77BHXikXBwG
zHqt0dHai2IXOMGI3uDcyugsO9f/+4LqhZvMoD7M4gsO9AgjO9lyhWI/CLzLj75Q
2UK68MmeTKyzRPTyEgmFzfwu3YlH8ymRQ84Qg9hS+ICyAmtCQNGvDQvzqnminKSG
oNgt+cCmMwPZxLpNSZF4iuFiIvu++CwuynMbn5x3mscfc3ZcdjrHfAVWJwgGDStG
XxPE/NpBIwEOZ5SpWCu0rpieLPuuDa/g2Orp4wlSn/It4kNTtr3LgznyVUBMHodx
R1CRIueV08eW0TVhqmN+7uwzRP8es1o2NuQX0sz6123DRBOV4abZCpzJjG+ul4jf
qFW+uZw8yD9rbAS8ttZlgO1SasjV9BLsQ+YY4IejVubfZbS+CR08VNO3fPEvSVm6
huw1W1EsjPDeBWa8khvRqv/aFEHkwt0/bC52fdk8DwUI7hqgr7xaMER+nwW7LqcS
6AbjrQhl1wfklBH8zOwLZUXc3PRA/+qCq4W+Q8mzleQ/uW2yC151zyAz9VZYAakh
gQ7mh+VJsSCLvxVUvZFOSBxk+06HVh1dSOgHoIUat4OqYz7pDA7OEidgpfLYK6/z
hps8alYBJnDLcORG8/OtApvrPKz6Ysskuw2nY5tOdClH8a/rvhS3mA64e9zRsZ9+
UU9JHytsNlKFO0a8W1dY
=0ChH
-END PGP SIGNATURE-

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

Re: ForkJoinPool behaviour changed from 9.0.0-M15 to 9.0.0-M17

[Francesco Bassi]

Thanks a lot.
Your support is great and appropriate, as usual.

I still think there's something wrong with this topic, but more on the Java
8 side.
I'll do some more investigations and, in case, involve them!

--fb

On Fri, Mar 24, 2017 at 8:05 PM, Mark Thomas  wrote:

> On 24 March 2017 17:51:27 GMT+00:00, Francesco Bassi 
> wrote:
> >Hello.
> >I have a weird problem that happens only wih tomcat 9.0.0-M17+:
> >
> >- I need to process a parallel java stream inside a custom ForkJoinPool
> >
> >If I run the code with 9.0.0-M15, I see that all the threads are
> >properly
> >created using my factory.
> >
> >If I run the code with 9.0.0-M17+, some of the threads that are used in
> >the
> >Stream processing are not coming from my factory, but instead are
> >instance
> >of
> >org.apache.catalina.startup.SafeForkJoinWorkerThreadFactor
> y$SafeForkJoinWorkerThread.
> >
> >
> >Sample prototype code:
> >
> >ForkJoinPool pool = new ForkJoinPool(2, p -> new
> >MyForkJoinWorkerThread(p), null, false);
> >pool.submit(() -> {
> >Stream stream = createMyStream();
> >return stream.parallel().map(t -> {
> >System.out.println("THREAD: " +
> >Thread.currentThread().getClass());
> >return t;
> >}).collect(Collectors.toArrayList());
> >}).get();
> >
> >
> >It seems that something from the newer tomcats "interferes" with the
> >ForkJoinPool mechanism in some weird way.
> >Can someone help me to understand what's going on?
>
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#JRE_Memory_
> Leak_Prevention_Listener_-_org.apache.catalina.core.
> JreMemoryLeakPreventionListener
>
> Look for forkJoinCommonPoolProtection
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: ForkJoinPool behaviour changed from 9.0.0-M15 to 9.0.0-M17

[Mark Thomas]

On 24 March 2017 17:51:27 GMT+00:00, Francesco Bassi  wrote:
>Hello.
>I have a weird problem that happens only wih tomcat 9.0.0-M17+:
>
>- I need to process a parallel java stream inside a custom ForkJoinPool
>
>If I run the code with 9.0.0-M15, I see that all the threads are
>properly
>created using my factory.
>
>If I run the code with 9.0.0-M17+, some of the threads that are used in
>the
>Stream processing are not coming from my factory, but instead are
>instance
>of
>org.apache.catalina.startup.SafeForkJoinWorkerThreadFactory$SafeForkJoinWorkerThread.
>
>
>Sample prototype code:
>
>ForkJoinPool pool = new ForkJoinPool(2, p -> new
>MyForkJoinWorkerThread(p), null, false);
>pool.submit(() -> {
>Stream stream = createMyStream();
>return stream.parallel().map(t -> {
>System.out.println("THREAD: " +
>Thread.currentThread().getClass());
>return t;
>}).collect(Collectors.toArrayList());
>}).get();
>
>
>It seems that something from the newer tomcats "interferes" with the
>ForkJoinPool mechanism in some weird way.
>Can someone help me to understand what's going on?


http://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#JRE_Memory_Leak_Prevention_Listener_-_org.apache.catalina.core.JreMemoryLeakPreventionListener

Look for forkJoinCommonPoolProtection

Mark

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

siteMinder implementation for our application

[Kikkeri, Amith]

Hi,
Our application runs on tomcat7 (Port 80) and we don't use a web server. We are 
implementing SSO and planning to use siteMinder. When trying to install 
siteMinder web agent, we realized that it is not recognizing tomcat. Please let 
me  know if there is an option to make siteMinder webagent work with tomcat7.

If it is mandatory to use a web server, can we use IIS.

Any help appreciated.

Thanks.
Regards,
Amith Kikkeri

ForkJoinPool behaviour changed from 9.0.0-M15 to 9.0.0-M17

[Francesco Bassi]

Hello.
I have a weird problem that happens only wih tomcat 9.0.0-M17+:

- I need to process a parallel java stream inside a custom ForkJoinPool

If I run the code with 9.0.0-M15, I see that all the threads are properly
created using my factory.

If I run the code with 9.0.0-M17+, some of the threads that are used in the
Stream processing are not coming from my factory, but instead are instance
of
org.apache.catalina.startup.SafeForkJoinWorkerThreadFactory$SafeForkJoinWorkerThread.


Sample prototype code:

ForkJoinPool pool = new ForkJoinPool(2, p -> new
MyForkJoinWorkerThread(p), null, false);
pool.submit(() -> {
Stream stream = createMyStream();
return stream.parallel().map(t -> {
System.out.println("THREAD: " +
Thread.currentThread().getClass());
return t;
}).collect(Collectors.toArrayList());
}).get();


It seems that something from the newer tomcats "interferes" with the
ForkJoinPool mechanism in some weird way.
Can someone help me to understand what's going on?

thanks,

--fb

RE: location of tomcat-juli.jar

[Jeffrey Janner]

> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, March 24, 2017 12:00 PM
> To: Tomcat Users List 
> Subject: Re: location of tomcat-juli.jar
> 
> On 24 March 2017 16:06:21 GMT+00:00, Jeffrey Janner
>  wrote:
> >I was re-reading the RUNNING.txt  to see why I had to copy
> >tomcat-juli.jar to the CATALINA_BASE/bin directory instead of just
> >having it run out of CATALINA_HOME/bin.
> >It seemed annoying to me to have to copy it to all my  CATALINA_BASE
> >instances every time I upgraded, but I thought I ran into problems not
> >having it there.
> >Then I ran into this bit of documentation:
> >
> >In CATALINA_BASE:
> >
> >* bin  - Only the following files:
> >
> >   * setenv.sh (*nix) or setenv.bat (Windows),
> >   * tomcat-juli.jar
> >
> >
> >In CATALINA_BASE:
> >
> >* bin  - Only the following files:
> >
> >   * setenv.sh (*nix) or setenv.bat (Windows),
> >   * tomcat-juli.jar
> >
> >So I guess my question is, can I really just leave it out of my
> >CATALINA_BASE directory without causing any issues?
> >I want to say I had issues with it not being there, but cannot recall
> >what they were.
> >And if there is no difference, why make the suggestion in the
> >RUNNING.txt file at all?
> 
> You copied the wrong bits from RUNNING.txt
> 
> You can place the jar in CATALINA_HOME if you wish.
> 
> The historical reason for allowing both is if you want different
> implementations in different instances you need to put the right
> implementation JAR in CATALINA_BASE.
> 
> Mark
> 
Thanks Mark.  Thought I'd copied the right part for the second setting.  Here 
it is:

In CATALINA_HOME:

 * bin  - Startup and shutdown scripts

  The following files will be used only if they are absent in
  CATALINA_BASE/bin:

  setenv.sh (*nix), setenv.bat (Windows), tomcat-juli.jar

But, thanks for pointing out that if I don't need a specialized 
tomcat-juli.jar, it's OK to not copy to CATALINA_BASE.
It will make upgrades for my 100+ instances easier from now on.

Jeff

Re: Aw: Re: Was bug 58646 (NullPointerException in InternalNioOutputBuffer) also fixed for 8.5.5?

[Andrew Garland]

Mark,

FYI I created https://bz.apache.org/bugzilla/show_bug.cgi?id=60918 which is
a bug report for 8.5.11 with similar characteristics to the one reported in
bug 58646 



--
View this message in context: 
http://tomcat.10.x6.nabble.com/Was-bug-58646-NullPointerException-in-InternalNioOutputBuffer-also-fixed-for-8-5-5-tp5056250p5061726.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

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

Re: Tomcat Not Responding (Resolved)

[Igal @ Lucee.org]

On 3/23/2017 1:43 AM, Mark Thomas wrote:

If Tomcat is unresponsive, that would suggest a problem with either the
Acceptor or the Poller but both of those threads look normal to.

You are going to need to do some more debugging.

Ideally, you need to configure your favourite IDE to do remote debugging
and then once the problem occurs, step through the code as a single
connection is handled and see where things go wrong.


I've traced the issue to an NPE thrown from my servlet.  I patched it 
(https://github.com/lucee/Lucee/commit/0f30a7ef) and now it works fine.


Thank you,

Igal Sapir
Lucee Core Developer
Lucee.org 

Re: location of tomcat-juli.jar

[Mark Thomas]

On 24 March 2017 16:06:21 GMT+00:00, Jeffrey Janner 
 wrote:
>I was re-reading the RUNNING.txt  to see why I had to copy
>tomcat-juli.jar to the CATALINA_BASE/bin directory instead of just
>having it run out of CATALINA_HOME/bin.
>It seemed annoying to me to have to copy it to all my  CATALINA_BASE
>instances every time I upgraded, but I thought I ran into problems not
>having it there.
>Then I ran into this bit of documentation:
>
>In CATALINA_BASE:
>
>* bin  - Only the following files:
>
>   * setenv.sh (*nix) or setenv.bat (Windows),
>   * tomcat-juli.jar
>
>
>In CATALINA_BASE:
>
>* bin  - Only the following files:
>
>   * setenv.sh (*nix) or setenv.bat (Windows),
>   * tomcat-juli.jar
>
>So I guess my question is, can I really just leave it out of my
>CATALINA_BASE directory without causing any issues?
>I want to say I had issues with it not being there, but cannot recall
>what they were.
>And if there is no difference, why make the suggestion in the
>RUNNING.txt file at all?

You copied the wrong bits from RUNNING.txt

You can place the jar in CATALINA_HOME if you wish.

The historical reason for allowing both is if you want different 
implementations in different instances you need to put the right implementation 
JAR in CATALINA_BASE.

Mark

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

Re: location of tomcat-juli.jar

[Igal @ Lucee.org]

I'm using different directories for CATALINA_HOME and CATALINA_BASE 
without copying the bin directory to BASE.  Never had an issue with it.


Be sure to have the full path of tomcat-juli.jar in the Java Classpath 
setting.  That's what matters to Java.  You can place the Jar file 
anywhere you want as long as the Classpath points to it and the user 
that runs Tomcat has read privileges to that file.  But obviously the 
easiest thing is to leave it in %CATALINA_HOME%/bin.


I've done that both on Windows and *nix systems.

Igal Sapir
Lucee Core Developer
Lucee.org 

On 3/24/2017 9:06 AM, Jeffrey Janner wrote:

I was re-reading the RUNNING.txt  to see why I had to copy tomcat-juli.jar to 
the CATALINA_BASE/bin directory instead of just having it run out of 
CATALINA_HOME/bin.
It seemed annoying to me to have to copy it to all my  CATALINA_BASE instances 
every time I upgraded, but I thought I ran into problems not having it there.
Then I ran into this bit of documentation:

In CATALINA_BASE:

* bin  - Only the following files:

* setenv.sh (*nix) or setenv.bat (Windows),
* tomcat-juli.jar


In CATALINA_BASE:

* bin  - Only the following files:

* setenv.sh (*nix) or setenv.bat (Windows),
* tomcat-juli.jar

So I guess my question is, can I really just leave it out of my CATALINA_BASE 
directory without causing any issues?
I want to say I had issues with it not being there, but cannot recall what they 
were.
And if there is no difference, why make the suggestion in the RUNNING.txt file 
at all?


Jeff

location of tomcat-juli.jar

[Jeffrey Janner]

I was re-reading the RUNNING.txt  to see why I had to copy tomcat-juli.jar to 
the CATALINA_BASE/bin directory instead of just having it run out of 
CATALINA_HOME/bin.
It seemed annoying to me to have to copy it to all my  CATALINA_BASE instances 
every time I upgraded, but I thought I ran into problems not having it there.
Then I ran into this bit of documentation:

In CATALINA_BASE:

* bin  - Only the following files:

   * setenv.sh (*nix) or setenv.bat (Windows),
   * tomcat-juli.jar


In CATALINA_BASE:

* bin  - Only the following files:

   * setenv.sh (*nix) or setenv.bat (Windows),
   * tomcat-juli.jar

So I guess my question is, can I really just leave it out of my CATALINA_BASE 
directory without causing any issues?
I want to say I had issues with it not being there, but cannot recall what they 
were.
And if there is no difference, why make the suggestion in the RUNNING.txt file 
at all?


Jeff