Fwd: Advice please for Tomcat 8.5.53-dev with log4j2

[Brian Burch]

Thanks very much for your speedy and helpful reply, Mark.

Stupidly, I had forgotten to re-subscribe to the mailing list, so I 
found your reply in the archive and cannot reply to it in-line!


not really!

I stumbled across 
https://logging.apache.org/log4j/2.x/log4j-appserver/index.html.


This short page has significant overlap with your suggestions, but there 
are differences too. I'll compare both before I say much more.


However, I suspected my "current best effort" had disabled the internal 
tomcat logging (juli) but failed to enable log4j2. The message I quoted 
from catalina.out looked suspiciously like it had been handled by the 
jvm Logger, which is consistent with your suggestion.


I tried building log4j2 from source and gave up. It is a bit of a 
nuisance that my development system uses both OpenJDK 8 and 11 because I 
keep forgetting which is required by my different projects. The log4j2 
toolchains requirement for java 9 was just too much to contemplate!


I downloaded the apache-log4j-2.13.1 binaries, so I will deploy those 
jars in my tests.


I also noted from the web advice above that log4j2 looks for it's 
configuration file under the name log4j2-tomcat.xml, not log4j2.xml. I'm 
not keen on the advice to deploy the jars to new tomcat directories 
called catalina.home/log4j2/lib and ./log4j2/conf, so I favour your 
suggestion of using catalina.home/bin for my first tests.


I really appreciate your thoughtful advice. It would be useful for me to 
pare the advice down to its essentials and then update the tomcat 8 wiki 
advice.


Brian


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

Re: Tomcat 7.0.100 upgrade issues

[RK Ashburn]

Thank  you Martin.
1,2 and 3  (All) are working.


Ramesh

On Tue, Mar 17, 2020 at 6:01 PM Martin Grigorov 
wrote:

> Hi,
>
> On Tue, Mar 17, 2020 at 6:34 PM RK Ashburn 
> wrote:
>
> > Hi Tomcat 7 team,
> > We have been using tomcat 7.0.99 and now we upgraded to 7.0.100 and our
> web
> > applications stopped working.
> >
> > Here are changes that we noted from release notes and took action:
> >
> > 1. Updated AJP connector setting and  added secretRequired="false"
> >
> > However below are still issues, could not find any setting that needed to
> > be added:
> >
> > 2.  However our application @Controller @RequestMapping are stopped
> > working.
> > (we did not use web.xml instead used WebApplicationInitializer and
> > WebMvcConfigurerAdapter)
> >
> > 3. Also noticed getRemoteUser() returns null
> >
> >
> > Appreciate your response.
> >
>
> 7.0.103 is being voted at the moment.
> You can get it from
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.103/bin/ and
> test it.
> 2) has been fixed.
> If 1) and 3) still do not work then please provide more details.
>
> Martin
>
>
> > Thank you
> > Ramesh Kasavaraju
> >
>

Re: Security audit raises questions (Tomcat 7.0.93)

[James H. H. Lampert]

On 3/17/20 3:50 PM, Mark Thomas wrote:

The XXS might be valid. I assume the tool provided a sample URL you
could use to validate the finding. That should point you in the right
direction but feel free to ask here if more help is required.

Near as I can tell, it did but it didn't provide a sample URL.

Note that *all* I have is a PDF of the report, and I think the URL may 
have gotten mangled by spanning a page-break. I've posted a screenshot 
(with identifying information redacted) of what I'm looking at in the 
report:


https://www.flickr.com/gp/64159238@N03/02i78o


As to DELETE and OPTIONS, you get no argument from me about whether a 
DELETE will actually *do* anything (I've got a query out to our web 
developer on that), and on restricting OPTIONS being a case of "Security 
by obscurity"; however, this is a case of "The Customer is Always Right."


I found a page on disabling HTTP methods with a security constraint:

https://www.techstacks.com/howto/disable-http-methods-in-tomcat.html

But I'm not sure (1) how security constraints interact with other 
security constraints, and (2) whether they can go in the conf/web.xml as 
well as individual webapps' web.xml files.


As I said, I've got a query out to our web developers about *our* 
webapp, but does Manager make any use of DELETE or OPTIONS?


--
JHHL

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

Re: Security audit raises questions (Tomcat 7.0.93)

[Martynas Jusevičius]

Tomcat does not allow DELETE by default? I’m using 8.0.x with Jersey and I
don’t think I used any config to enable it.

On Tue, 17 Mar 2020 at 23.50, Mark Thomas  wrote:

> On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" <
> jam...@touchtonecorp.com> wrote:
> >
> >On 3/17/20 3:18 PM, Martynas Jusevičius wrote:
> >> why should DELETE or OPTIONS not be enabled? They are standard HTTP
> >methods.
> >
> >True, but (quoting the audit report)
> >> . . . [DELETE] may allow a remote attacker to delete arbitrary files
> >. . . .
>
> There is a big difference between supporting a method (recognising it is a
> known HTTP method) and allowing it.
>
> Tomcat does not allow DELETE by default. Your app might but one assumes if
> it does the developers know what they were doing and secured it
> appropriately...
>
> Tomcat takes the view that OPTIONS should list all supported methods, not
> just methods allowed, for a given resource.
>
> >and (again quoting the report)
> >> Web servers that respond to the OPTIONS HTTP method expose what other
> >> methods are supported by the web server, allowing attackers to narrow
> >> and intensify their efforts.
>
> That is a security by obscurity argument. The Tomcat devs have never given
> much ,(any?) weight to arguments made on that basis.
>
> The XXS might be valid. I assume the tool provided a sample URL you could
> use to validate the finding. That should point you in the right direction
> but feel free to ask here if more help is required.
>
> Mark
>
>
> >--
> >JHHL
> >
> >-
> >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: [ANN] Apache Tomcat 9.0.33 available

[Pierre Chiu]

Thank guys for your hard work. With this version, I can use h2, compress
and rewrite all together.

On Tue, Mar 17, 2020 at 10:05 AM Mark Thomas  wrote:

> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat 9.0.33.
>
> Apache Tomcat 9 is an open source software implementation of the Java
> Servlet, JavaServer Pages, Java Unified Expression Language, Java
> WebSocket and JASPIC technologies.
>
> Apache Tomcat 9.0.33 is a bugfix and feature release. The notable
> changes compared to 9.0.31 include:
>
> - Add new attribute persistAuthentication to both StandardManager and
>   PersistentManager to support authentication persistence.
>   Patch provided by Carsten Klein
>
> - A zero length AJP secret will now behave as if it has not been
>   specified.
>
> - Add the TLS request attributes used by IIS to the attributes that
>   an AJP Connector will always accept.
>
> Please refer to the change log for the complete list of changes:
> http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
>
>
> Downloads:
> http://tomcat.apache.org/download-90.cgi
>
> Migration guides from Apache Tomcat 7.x and 8.x:
> http://tomcat.apache.org/migration.html
>
> Enjoy!
>
> - The Apache Tomcat team
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Security audit raises questions (Tomcat 7.0.93)

[Mark Thomas]

On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" 
 wrote:
>
>On 3/17/20 3:18 PM, Martynas Jusevičius wrote:
>> why should DELETE or OPTIONS not be enabled? They are standard HTTP
>methods.
>
>True, but (quoting the audit report)
>> . . . [DELETE] may allow a remote attacker to delete arbitrary files
>. . . .

There is a big difference between supporting a method (recognising it is a 
known HTTP method) and allowing it.

Tomcat does not allow DELETE by default. Your app might but one assumes if it 
does the developers know what they were doing and secured it appropriately...

Tomcat takes the view that OPTIONS should list all supported methods, not just 
methods allowed, for a given resource.

>and (again quoting the report)
>> Web servers that respond to the OPTIONS HTTP method expose what other
>> methods are supported by the web server, allowing attackers to narrow
>> and intensify their efforts.

That is a security by obscurity argument. The Tomcat devs have never given much 
,(any?) weight to arguments made on that basis.

The XXS might be valid. I assume the tool provided a sample URL you could use 
to validate the finding. That should point you in the right direction but feel 
free to ask here if more help is required.

Mark


>--
>JHHL
>
>-
>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: Security audit raises questions (Tomcat 7.0.93)

[James H. H. Lampert]

On 3/17/20 3:34 PM, Martin Grigorov wrote:

Reading the quoted text I'd suggest you to throw this tool in the bin.
I hope you didn't pay for it.


Are you suggesting that we throw a paying customer "in the bin?"

It is not OUR audit; it is the CUSTOMER's audit (the report 
self-identifies as being "performed by InsightVM from Rapid7 LLC", which 
until a few minutes ago, I'd never heard of). And the customer is always 
right.


--
JHHL

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

Re: Security audit raises questions (Tomcat 7.0.93)

[Martin Grigorov]

On Wed, Mar 18, 2020 at 12:31 AM James H. H. Lampert <
jam...@touchtonecorp.com> wrote:

>
> On 3/17/20 3:18 PM, Martynas Jusevičius wrote:
> > why should DELETE or OPTIONS not be enabled? They are standard HTTP
> methods.
>
> True, but (quoting the audit report)
> > . . . [DELETE] may allow a remote attacker to delete arbitrary files . .
> . .
> and (again quoting the report)
> > Web servers that respond to the OPTIONS HTTP method expose what other
> > methods are supported by the web server, allowing attackers to narrow
> > and intensify their efforts.
>

Reading the quoted text I'd suggest you to throw this tool in the bin.
I hope you didn't pay for it.

Martin


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

Re: Security audit raises questions (Tomcat 7.0.93)

[James H. H. Lampert]

On 3/17/20 3:18 PM, Martynas Jusevičius wrote:

why should DELETE or OPTIONS not be enabled? They are standard HTTP methods.


True, but (quoting the audit report)

. . . [DELETE] may allow a remote attacker to delete arbitrary files . . . .

and (again quoting the report)

Web servers that respond to the OPTIONS HTTP method expose what other
methods are supported by the web server, allowing attackers to narrow
and intensify their efforts.

--
JHHL

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

Re: Security audit raises questions (Tomcat 7.0.93)

[Martynas Jusevičius]

Hi,

why should DELETE or OPTIONS not be enabled? They are standard HTTP methods.

On Tue, Mar 17, 2020 at 11:05 PM James H. H. Lampert
 wrote:
>
> Ladies and Gentlemen:
>
> One of our customers did a security audit on the Tomcat server we
> maintain on their system, and it found a few issues:
>
> First, it found a cross-site scripting vulnerability.
>
> Second, it found the HTTP DELETE method enabled.
>
> Third, it found a click-jacking vulnerability.
>
> Fourth, it found the HTTP OPTIONS method enabled.
>
> Back in October, the click-jacking vulnerability came up on another
> customer box; I've found the thread, and just now set up the filter and
> filter-mapping in conf/web.xml, so that is hopefully taken care of in
> the next restart.
>
> But I have no idea what to do about the cross-site scripting
> vulnerability, or the DELETE and OPTIONS methods, and I'm having trouble
> understanding the materials I've found.
>
> --
> JHHL
>
> -
> 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

Security audit raises questions (Tomcat 7.0.93)

[James H. H. Lampert]

Ladies and Gentlemen:

One of our customers did a security audit on the Tomcat server we 
maintain on their system, and it found a few issues:


First, it found a cross-site scripting vulnerability.

Second, it found the HTTP DELETE method enabled.

Third, it found a click-jacking vulnerability.

Fourth, it found the HTTP OPTIONS method enabled.

Back in October, the click-jacking vulnerability came up on another 
customer box; I've found the thread, and just now set up the filter and 
filter-mapping in conf/web.xml, so that is hopefully taken care of in 
the next restart.


But I have no idea what to do about the cross-site scripting 
vulnerability, or the DELETE and OPTIONS methods, and I'm having trouble 
understanding the materials I've found.


--
JHHL

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

Re: Tomcat and IPv6

[Martin Grigorov]

Hi,

On Tue, Mar 17, 2020 at 9:22 PM 
wrote:

> We have a team having issues with Tomcat, AJP, and switching to IPv6. They
> are currently running version 9.0.31. Below are the errors being received:
>
> [Tue Mar 17 10:50:38 2020] [1412:139846332929792] [error]
> ajp_service::jk_ajp_common.c (2796): (Greenworker1) connecting to tomcat
> failed (rc=-3, errors=13, client_errors=0).
> [Tue Mar 17 10:50:38 2020] [1412:139846332929792] [error]
> service::jk_lb_worker.c (1686): All tomcat instances failed, no more
> workers left
> [Tue Mar 17 10:50:38 2020] [1408:139846332929792] [error]
> ajp_send_request::jk_ajp_common.c (1725): (Greenworker1) connecting to
> backend failed. Tomcat is probably not started or is listening on the wrong
> port (errno=111)
>
> Here is the connector from the server.xml
>
>  packetSize="65536"
> maxKeepAliveRequests="-1" protocol="AJP/1.3" secretRequired="false"
> address="::" />
>

Check Tomcat's logs.
Check whether it has bound at port 6209: netstat -antp | grep 6209

Martin


>
>
> And here is the info from web server workers.properties
>
> cat workers.properties
>
> # for OLTP web instance
> # Define a worker named 'worker1' (more workers can be added as comma
> separated values)
> worker.list=loadbalancer
>
> # Default Worker Properties
> worker.workerDefault.type=ajp13
> worker.workerDefault.port=6209
> worker.workerDefault.lbfactor=1
> worker.workerDefault.socket_timeout=300
> worker.workerDefault.socket_keepalive=true
> worker.workerDefault.connection_pool_timeout=300
> worker.workerDefault.connection_pool_minsize=1
> worker.workerDefault.connection_pool_size=225
> worker.workerDefault.max_packet_size=65536
>
> # Node #1 properties
> worker.Greenworker1.reference=worker.workerDefault
> worker.Greenworker1.host=
>
> # Node #2 properties
> #worker.Greenworker2.reference=worker.workerDefault
> #worker.Greenworker2.host=
>
> # Node #3 properties
> #worker.Greenworker3.reference=worker.workerDefault
> #worker.Greenworker3.host=
>
> # Load-balancing behaviour
> worker.loadbalancer.type=lb
> worker.loadbalancer.balance_workers=Greenworker1
> worker.loadbalancer.sticky_session=1
>
>
> For HOST1, etc. should this be the IPv6 address or what?
>
> Thanks,
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13,
> 12/20 - 12/31
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
>
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the addressee,
> you must not use, copy, disclose, or take any action based on this message
> or any information herein. If you have received this message in error,
> please advise the sender immediately by reply e-mail and delete this
> message. Thank you for your cooperation.
>
>

Re: Tomcat 7.0.100 upgrade issues

[Martin Grigorov]

Hi,

On Tue, Mar 17, 2020 at 6:34 PM RK Ashburn 
wrote:

> Hi Tomcat 7 team,
> We have been using tomcat 7.0.99 and now we upgraded to 7.0.100 and our web
> applications stopped working.
>
> Here are changes that we noted from release notes and took action:
>
> 1. Updated AJP connector setting and  added secretRequired="false"
>
> However below are still issues, could not find any setting that needed to
> be added:
>
> 2.  However our application @Controller @RequestMapping are stopped
> working.
> (we did not use web.xml instead used WebApplicationInitializer and
> WebMvcConfigurerAdapter)
>
> 3. Also noticed getRemoteUser() returns null
>
>
> Appreciate your response.
>

7.0.103 is being voted at the moment.
You can get it from
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.103/bin/ and
test it.
2) has been fixed.
If 1) and 3) still do not work then please provide more details.

Martin


> Thank you
> Ramesh Kasavaraju
>

Re: [External] Re: Starting up Tomcat 8

[Maxfield, Rebecca A]

Ah, some problems are arising because, I suppose, the startup process wants to 
create or touch something in ../logs and that's now all the way over in 
/var/lib/tomcat8. How do I move on from here?


On 3/17/20, 4:40 PM, "Maxfield, Rebecca A"  wrote:

I see it now in /usr/share/tomcat8/bin, thank you! Can I just run 
startup.sh from there or is that not right?

On 3/17/20, 4:37 PM, "André Warnier (tomcat/perl)"  wrote:

On 17.03.2020 21:18, Maxfield, Rebecca A wrote:
> Both are Linux. The new is Debian, the old ??

On a Debian Linux system, tomcat 8 installed via the standard Debian 
package manager 
results in some files appearing in the following directories (and maybe 
others)
- /etc/tomcat8
- /usr/share/tomcat8
- /var/lib/tomcat8
- /var/log/tomcat8
- .. ?
Some of the entries in these directories are links pointing somewhere 
else. It is 
sometimes a bit difficult to follow. But it works, and it allows tomcat 
to be managed 
using the Debian usual commands for starting/stopping services, install 
updates etc..

Use this command to see a full list of the directories/files used :
dpkg --listfiles tomcat8

(Note : this gives a list of directories/files initially reated or 
installed by the 
standard Debian tomcat8 package. But it does not include anything 
created/installed later 
on maybe to "customise" tomcat8 on that machine).

> 
> On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)"  
wrote:
> 
>  On 17.03.2020 19:52, Maxfield, Rebecca A wrote:
>  > Hello,
>  >
>  > I manage a project that currently runs on Tomcat 7 but is 
migrating to a new server where Tomcat 8 was installed by the server admin. 
When I navigate to the /var/lib/tomcat8 folder, I don’t see a ./bin folder or 
any startup.sh or similar. Is this something that has changed from Tomcat 7 to 
Tomcat 8, or does this imply that it was not installed completely/correctly?
>  >
>  What is the platform (OS) of the new server ? (and the old one)
>  Maybe it was installed using a package provided by the platform, 
in (eminently variable)
>  other directories.
>  
>  
>  
>  
-
>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
>  
>  
>  
>  
>  
>  
>  › This email was sent from outside of Providence College
>  › Do not click any suspicious links or open any attachments that 
you are not expecting
>  › Never send any sensitive or financial information (Including 
passwords, social security numbers, credit card numbers, and gift cards) via 
email
>  
> 
> 
> -
> 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: [External] Re: Starting up Tomcat 8

[Maxfield, Rebecca A]

I see it now in /usr/share/tomcat8/bin, thank you! Can I just run startup.sh 
from there or is that not right?

On 3/17/20, 4:37 PM, "André Warnier (tomcat/perl)"  wrote:

On 17.03.2020 21:18, Maxfield, Rebecca A wrote:
> Both are Linux. The new is Debian, the old ??

On a Debian Linux system, tomcat 8 installed via the standard Debian 
package manager 
results in some files appearing in the following directories (and maybe 
others)
- /etc/tomcat8
- /usr/share/tomcat8
- /var/lib/tomcat8
- /var/log/tomcat8
- .. ?
Some of the entries in these directories are links pointing somewhere else. 
It is 
sometimes a bit difficult to follow. But it works, and it allows tomcat to 
be managed 
using the Debian usual commands for starting/stopping services, install 
updates etc..

Use this command to see a full list of the directories/files used :
dpkg --listfiles tomcat8

(Note : this gives a list of directories/files initially reated or 
installed by the 
standard Debian tomcat8 package. But it does not include anything 
created/installed later 
on maybe to "customise" tomcat8 on that machine).

> 
> On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)"  
wrote:
> 
>  On 17.03.2020 19:52, Maxfield, Rebecca A wrote:
>  > Hello,
>  >
>  > I manage a project that currently runs on Tomcat 7 but is 
migrating to a new server where Tomcat 8 was installed by the server admin. 
When I navigate to the /var/lib/tomcat8 folder, I don’t see a ./bin folder or 
any startup.sh or similar. Is this something that has changed from Tomcat 7 to 
Tomcat 8, or does this imply that it was not installed completely/correctly?
>  >
>  What is the platform (OS) of the new server ? (and the old one)
>  Maybe it was installed using a package provided by the platform, in 
(eminently variable)
>  other directories.
>  
>  
>  
>  -
>  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>  For additional commands, e-mail: users-h...@tomcat.apache.org
>  
>  
>  
>  
>  
>  
>  › This email was sent from outside of Providence College
>  › Do not click any suspicious links or open any attachments that you 
are not expecting
>  › Never send any sensitive or financial information (Including 
passwords, social security numbers, credit card numbers, and gift cards) via 
email
>  
> 
> 
> -
> 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: [External] Re: Starting up Tomcat 8

[tomcat/perl]

On 17.03.2020 21:18, Maxfield, Rebecca A wrote:

Both are Linux. The new is Debian, the old ??


On a Debian Linux system, tomcat 8 installed via the standard Debian package manager 
results in some files appearing in the following directories (and maybe others)

- /etc/tomcat8
- /usr/share/tomcat8
- /var/lib/tomcat8
- /var/log/tomcat8
- .. ?
Some of the entries in these directories are links pointing somewhere else. It is 
sometimes a bit difficult to follow. But it works, and it allows tomcat to be managed 
using the Debian usual commands for starting/stopping services, install updates etc..


Use this command to see a full list of the directories/files used :
dpkg --listfiles tomcat8

(Note : this gives a list of directories/files initially reated or installed by the 
standard Debian tomcat8 package. But it does not include anything created/installed later 
on maybe to "customise" tomcat8 on that machine).




On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)"  wrote:

 On 17.03.2020 19:52, Maxfield, Rebecca A wrote:
 > Hello,
 >
 > I manage a project that currently runs on Tomcat 7 but is migrating to a 
new server where Tomcat 8 was installed by the server admin. When I navigate to 
the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or 
similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does 
this imply that it was not installed completely/correctly?
 >
 What is the platform (OS) of the new server ? (and the old one)
 Maybe it was installed using a package provided by the platform, in 
(eminently variable)
 other directories.
 
 
 
 -

 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 
 
 
 › This email was sent from outside of Providence College

 › Do not click any suspicious links or open any attachments that you are 
not expecting
 › Never send any sensitive or financial information (Including passwords, 
social security numbers, credit card numbers, and gift cards) via email
 



-
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: [External] Re: Starting up Tomcat 8

[Maxfield, Rebecca A]

Both are Linux. The new is Debian, the old ??

On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)"  wrote:

On 17.03.2020 19:52, Maxfield, Rebecca A wrote:
> Hello,
>
> I manage a project that currently runs on Tomcat 7 but is migrating to a 
new server where Tomcat 8 was installed by the server admin. When I navigate to 
the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or 
similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does 
this imply that it was not installed completely/correctly?
>
What is the platform (OS) of the new server ? (and the old one)
Maybe it was installed using a package provided by the platform, in 
(eminently variable)
other directories.



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






› This email was sent from outside of Providence College
› Do not click any suspicious links or open any attachments that you are 
not expecting
› Never send any sensitive or financial information (Including passwords, 
social security numbers, credit card numbers, and gift cards) via email

Re: Starting up Tomcat 8

[tomcat/perl]

On 17.03.2020 19:52, Maxfield, Rebecca A wrote:

Hello,

I manage a project that currently runs on Tomcat 7 but is migrating to a new 
server where Tomcat 8 was installed by the server admin. When I navigate to the 
/var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or 
similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does 
this imply that it was not installed completely/correctly?


What is the platform (OS) of the new server ? (and the old one)
Maybe it was installed using a package provided by the platform, in (eminently variable) 
other directories.




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

Tomcat and IPv6

[jonmcalexander]

We have a team having issues with Tomcat, AJP, and switching to IPv6. They are 
currently running version 9.0.31. Below are the errors being received:

[Tue Mar 17 10:50:38 2020] [1412:139846332929792] [error] 
ajp_service::jk_ajp_common.c (2796): (Greenworker1) connecting to tomcat failed 
(rc=-3, errors=13, client_errors=0).
[Tue Mar 17 10:50:38 2020] [1412:139846332929792] [error] 
service::jk_lb_worker.c (1686): All tomcat instances failed, no more workers 
left
[Tue Mar 17 10:50:38 2020] [1408:139846332929792] [error] 
ajp_send_request::jk_ajp_common.c (1725): (Greenworker1) connecting to backend 
failed. Tomcat is probably not started or is listening on the wrong port 
(errno=111)

Here is the connector from the server.xml




And here is the info from web server workers.properties

cat workers.properties

# for OLTP web instance
# Define a worker named 'worker1' (more workers can be added as comma separated 
values)
worker.list=loadbalancer

# Default Worker Properties
worker.workerDefault.type=ajp13
worker.workerDefault.port=6209
worker.workerDefault.lbfactor=1
worker.workerDefault.socket_timeout=300
worker.workerDefault.socket_keepalive=true
worker.workerDefault.connection_pool_timeout=300
worker.workerDefault.connection_pool_minsize=1
worker.workerDefault.connection_pool_size=225
worker.workerDefault.max_packet_size=65536

# Node #1 properties
worker.Greenworker1.reference=worker.workerDefault
worker.Greenworker1.host=

# Node #2 properties
#worker.Greenworker2.reference=worker.workerDefault
#worker.Greenworker2.host=

# Node #3 properties
#worker.Greenworker3.reference=worker.workerDefault
#worker.Greenworker3.host=

# Load-balancing behaviour
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=Greenworker1
worker.loadbalancer.sticky_session=1


For HOST1, etc. should this be the IPv6 address or what?

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 
- 12/31

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Starting up Tomcat 8

[Maxfield, Rebecca A]

Hello,

I manage a project that currently runs on Tomcat 7 but is migrating to a new 
server where Tomcat 8 was installed by the server admin. When I navigate to the 
/var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or 
similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does 
this imply that it was not installed completely/correctly?

Thank you!

Re: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31

[Mark Thomas]

On 17/03/2020 17:56, Amit Pande wrote:
> Using Tomcat 9.0.31.
>
> When using large JSON payload (little less than 2 MB) for POST
requests, randomly (all random failures seen are on Windows and not on
*ix), we are seeing:
>
> JSON parse error: Unexpected end-of-input in VALUE_STRING; nested
exception is com.fasterxml.jackson.databind.JsonMappingException:
Unexpected end-of-input in VALUE_STRING  at [Source:
(PushbackInputStream); line: 1, column: 17] (through reference chain:
com.abc.xyz ["str"]) - JSON parse error: Unexpected end-of-input in
VALUE_STRING; nested exception is
com.fasterxml.jackson.databind.JsonMappingException: Unexpected
end-of-input in VALUE_STRING  at [Source: (PushbackInputStream); line:
1, column: 17] (through reference chain: com.abc.xyz["str"])at
>
> For smaller payloads, no issues are observed.
>
> Will this also be addressed by upgrading to 9.0.32/33?

Maybe.

The only way for you to be sure that the issue you describe is the same
as Bug 64202 is for you to download 9.0.33 and test it in your test
environment.

Mark


>
> Thanks,
> Amit
>
> -Original Message-
> From: Manuel Dominguez Sarmiento 
> Sent: Tuesday, March 17, 2020 10:52 AM
> To: Tomcat Users List ; Christopher Schultz

> Subject: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31
>
> Great, I just saw that :-)
>
> On 17/03/2020 11:24, Christopher Schultz wrote:
> Manuel.
> 
> On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote:
 Hi Mark, when is 9.0.32 expected to be released? We've seen this 
 issue reported by several users, even if we haven't run into this 
 particular case directly (yet)
> 9.0.33 was announced about 20 minutes ago :)
> 
> -chris
> 
 On 17/03/2020 09:51, Mark Thomas wrote:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64202
>
> Mark
>
> On 17/03/2020 11:46, Srijith Kochunni wrote:
>> Hi All,
>>
>>
>>
>> This is to seek help on a strange issue that we are observing.
>> We recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, in 
>> our application, in order to address vulnerability in AJP 
>> connector. Ever since then we have started seeing upload failures 
>> with our upload servlet when processing large files.
>> Small files do get uploaded, but when we upload large files and we 
>> do Multipart file upload, we are randomly and yet consistently 
>> seeing that we get the following exception.
>>
>>
>>
>> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
>>
>>
> Processing of multipart/form-data request failed. Stream ended
>> unexpectedly
>>
>> at
>> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploa
>> d
> Base.java:351)
>>
>>
>>
> 
>> Caused by:
>> org.apache.commons.fileupload.MultipartStream$MalformedStreamExcept
>> i
> on:
>>
> Stream ended unexpectedly
>> at
>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeA
>> v
> ailable(MultipartStream.java:1005)
>>
>>
>>
> at
>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(
>> M
> ultipartStream.java:903)
>>
>>
>>
> at java.io.InputStream.read(InputStream.java:101)
>> at
>> org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)
>>
>>
>>
> at
>> org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)
>>
>>
>>
> at
>> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploa
>> d
> Base.java:347)
>>
>>
>>
>>
>>
> It appears that the connection is getting reset in the
>> middle of the upload, but the client is very much up and we get 
>> PR_CONNECT_RESET_ERROR on the browser.
>>
>>
>>
>> My code on the server side is as simple as
>>
>>
>>
>> DiskFileItemFactory factory = new DiskFileItemFactory();
>>
>> ServletFileUpload fileUpload = new ServletFileUpload(factory);
>>
>>
>>
>> List fileItems = fileUpload.parseRequest(originalRequest);
>>
>>
>>
>>
>>
>> We would like to know if anyone else has observed this and if there 
>> is any way we can debug this further. When I try to attach and 
>> debug, the upload however seems to go through fine and is only 
>> failing when I am not attached to the process. Any help / 
>> suggestions would be much appreciated.
>>
>>
>>
>>
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Srijith.
>>
>>
>>
>>
>>
>>
> 
> -
>
>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

 -


> To unsubscribe, e-mail: 

RE: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31

[Amit Pande]

Using Tomcat 9.0.31.

When using large JSON payload (little less than 2 MB) for POST requests, 
randomly (all random failures seen are on Windows and not on *ix), we are 
seeing:

JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is 
com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in 
VALUE_STRING  at [Source: (PushbackInputStream); line: 1, column: 17] (through 
reference chain: com.abc.xyz ["str"]) - JSON parse error: Unexpected 
end-of-input in VALUE_STRING; nested exception is 
com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in 
VALUE_STRING  at [Source: (PushbackInputStream); line: 1, column: 17] (through 
reference chain: com.abc.xyz["str"])at

For smaller payloads, no issues are observed.

Will this also be addressed by upgrading to 9.0.32/33?

Thanks,
Amit

-Original Message-
From: Manuel Dominguez Sarmiento  
Sent: Tuesday, March 17, 2020 10:52 AM
To: Tomcat Users List ; Christopher Schultz 

Subject: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31

Great, I just saw that :-)

On 17/03/2020 11:24, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Manuel.
>
> On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote:
>> Hi Mark, when is 9.0.32 expected to be released? We've seen this 
>> issue reported by several users, even if we haven't run into this 
>> particular case directly (yet)
> 9.0.33 was announced about 20 minutes ago :)
>
> - -chris
>
>> On 17/03/2020 09:51, Mark Thomas wrote:
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64202
>>>
>>> Mark
>>>
>>> On 17/03/2020 11:46, Srijith Kochunni wrote:
 Hi All,



 This is to seek help on a strange issue that we are observing.
 We recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, in 
 our application, in order to address vulnerability in AJP 
 connector. Ever since then we have started seeing upload failures 
 with our upload servlet when processing large files.
 Small files do get uploaded, but when we upload large files and we 
 do Multipart file upload, we are randomly and yet consistently 
 seeing that we get the following exception.



 [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:


> Processing of multipart/form-data request failed. Stream ended
 unexpectedly

 at
 org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploa
 d
> Base.java:351)



> 
 Caused by:
 org.apache.commons.fileupload.MultipartStream$MalformedStreamExcept
 i
> on:

> Stream ended unexpectedly
 at
 org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeA
 v
> ailable(MultipartStream.java:1005)



> at
 org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(
 M
> ultipartStream.java:903)



> at java.io.InputStream.read(InputStream.java:101)
 at
 org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)



> at
 org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)



> at
 org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploa
 d
> Base.java:347)





> It appears that the connection is getting reset in the
 middle of the upload, but the client is very much up and we get 
 PR_CONNECT_RESET_ERROR on the browser.



 My code on the server side is as simple as



 DiskFileItemFactory factory = new DiskFileItemFactory();

 ServletFileUpload fileUpload = new ServletFileUpload(factory);



 List fileItems = fileUpload.parseRequest(originalRequest);





 We would like to know if anyone else has observed this and if there 
 is any way we can debug this further. When I try to attach and 
 debug, the upload however seems to go through fine and is only 
 failing when I am not attached to the process. Any help / 
 suggestions would be much appreciated.







 Thanks,



 Srijith.






>>> 
>>> -
>>>
>>>
> 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
>>
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5w3bkACgkQHPApP6U8
> pFg/gg/+MHNKYcFiWA3njQuNxqY2DRumdXryFIep9Ezi6L7KpLAwfGSpi+BMZLew
> 53d+JjWPhjLebjB2zEQAXdXvl9fHtHWDJoH4QKXYcjm7Lljj1ZpsGNR99EPWV1hX
> 

Tomcat 7.0.100 upgrade issues

[RK Ashburn]

Hi Tomcat 7 team,
We have been using tomcat 7.0.99 and now we upgraded to 7.0.100 and our web
applications stopped working.

Here are changes that we noted from release notes and took action:

1. Updated AJP connector setting and  added secretRequired="false"

However below are still issues, could not find any setting that needed to
be added:

2.  However our application @Controller @RequestMapping are stopped
working.
(we did not use web.xml instead used WebApplicationInitializer and
WebMvcConfigurerAdapter)

3. Also noticed getRemoteUser() returns null


Appreciate your response.
Thank you
Ramesh Kasavaraju

Re: Uploads breaking post upgrade to 9.0.31

[Manuel Dominguez Sarmiento]

Great, I just saw that :-)

On 17/03/2020 11:24, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Manuel.

On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote:

Hi Mark, when is 9.0.32 expected to be released? We've seen this
issue reported by several users, even if we haven't run into this
particular case directly (yet)

9.0.33 was announced about 20 minutes ago :)

- -chris


On 17/03/2020 09:51, Mark Thomas wrote:

https://bz.apache.org/bugzilla/show_bug.cgi?id=64202

Mark

On 17/03/2020 11:46, Srijith Kochunni wrote:

Hi All,



This is to seek help on a strange issue that we are observing.
We recently did a minor upgrade of Tomcat from 9.0.30 to
9.0.31, in our application, in order to address vulnerability
in AJP connector. Ever since then we have started seeing upload
failures with our upload servlet when processing large files.
Small files do get uploaded, but when we upload large files and
we do Multipart file upload, we are randomly and yet
consistently seeing that we get the following exception.



[org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:



Processing of multipart/form-data request failed. Stream ended

unexpectedly

at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpload

Base.java:351)







Caused by:
org.apache.commons.fileupload.MultipartStream$MalformedStreamExcepti

on:



Stream ended unexpectedly

at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAv

ailable(MultipartStream.java:1005)





at

org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(M

ultipartStream.java:903)





at java.io.InputStream.read(InputStream.java:101)

at
org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)




at

org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)




at

org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpload

Base.java:347)







It appears that the connection is getting reset in the

middle of the upload, but the client is very much up and we
get PR_CONNECT_RESET_ERROR on the browser.



My code on the server side is as simple as



DiskFileItemFactory factory = new DiskFileItemFactory();

ServletFileUpload fileUpload = new ServletFileUpload(factory);



List fileItems = fileUpload.parseRequest(originalRequest);





We would like to know if anyone else has observed this and if
there is any way we can debug this further. When I try to
attach and debug, the upload however seems to go through fine
and is only failing when I am not attached to the process. Any
help / suggestions would be much appreciated.







Thanks,



Srijith.







-



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


-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5w3bkACgkQHPApP6U8
pFg/gg/+MHNKYcFiWA3njQuNxqY2DRumdXryFIep9Ezi6L7KpLAwfGSpi+BMZLew
53d+JjWPhjLebjB2zEQAXdXvl9fHtHWDJoH4QKXYcjm7Lljj1ZpsGNR99EPWV1hX
dS0aqPo0bfq7cjlg3Euh1vxC+BLccIJOvpC1l4L/UhTkCfDP8O5Yzy8KXkZVl9q3
AFSIHOjC09/1Z51QHHBrOsbuRkN69/Ouuks9pTGA4A53xjN0jBYyiBa8NaOoxt5U
M4H3ipfdDJf41lwPbhBZ51dip0EAh6frI1tWkDKFkJsyms3Byj6sE4sLLw+ViSLy
H0FvbAw75nFBeZlO7Fl0IKKgFxtHaJmMhfBf2sXzkorEv0SQVE/c/5CO4ry+to0O
+9HdtkXXRVfaeCfCdltyvMAWOPDuFGF1Y2MKwFeHT1c/nDcMuzhEUP6QS8SKAJc+
uEsPe4PiJ4441MOF+E9Nj4SpKgfdtnL5M3r36N/Yad23eQGRzhzaB5c6uoPd6HAY
TCcdxf1BXaX+RxjQFbwG4xwmGLrmYiH99tZJ63xm47KbVONdvKCJX5lovcOYiheJ
3PgqNSLojcjMwreyBFVe6oK/CKKolp4i5sEJsfc9GpegBj73aRuMHccaS5RTAn+B
c22P1jzpHbCPkrl5M7dIe00keMAixF0TZ/wWOqp2yMdL8Rx2nUc=
=K4Sn
-END PGP SIGNATURE-

-
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: Uploads breaking post upgrade to 9.0.31

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Manuel.

On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote:
> Hi Mark, when is 9.0.32 expected to be released? We've seen this
> issue reported by several users, even if we haven't run into this
> particular case directly (yet)

9.0.33 was announced about 20 minutes ago :)

- -chris

> On 17/03/2020 09:51, Mark Thomas wrote:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64202
>>
>> Mark
>>
>> On 17/03/2020 11:46, Srijith Kochunni wrote:
>>> Hi All,
>>>
>>>
>>>
>>> This is to seek help on a strange issue that we are observing.
>>> We recently did a minor upgrade of Tomcat from 9.0.30 to
>>> 9.0.31, in our application, in order to address vulnerability
>>> in AJP connector. Ever since then we have started seeing upload
>>> failures with our upload servlet when processing large files.
>>> Small files do get uploaded, but when we upload large files and
>>> we do Multipart file upload, we are randomly and yet
>>> consistently seeing that we get the following exception.
>>>
>>>
>>>
>>> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
>>>
>>>
Processing of multipart/form-data request failed. Stream ended
>>> unexpectedly
>>>
>>> at
>>> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpload
Base.java:351)
>>>
>>>
>>>
>>>

>>>
>>> Caused by:
>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamExcepti
on:
>>>
>>>
Stream ended unexpectedly
>>>
>>> at
>>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAv
ailable(MultipartStream.java:1005)
>>>
>>>
>>>
>>>
at
>>> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(M
ultipartStream.java:903)
>>>
>>>
>>>
>>>
at java.io.InputStream.read(InputStream.java:101)
>>>
>>> at
>>> org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)
>>>
>>>
>>>
at
>>> org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)
>>>
>>>
>>>
at
>>> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpload
Base.java:347)
>>>
>>>
>>>
>>>
>>>
>>>
It appears that the connection is getting reset in the
>>> middle of the upload, but the client is very much up and we
>>> get PR_CONNECT_RESET_ERROR on the browser.
>>>
>>>
>>>
>>> My code on the server side is as simple as
>>>
>>>
>>>
>>> DiskFileItemFactory factory = new DiskFileItemFactory();
>>>
>>> ServletFileUpload fileUpload = new ServletFileUpload(factory);
>>>
>>>
>>>
>>> List fileItems = fileUpload.parseRequest(originalRequest);
>>>
>>>
>>>
>>>
>>>
>>> We would like to know if anyone else has observed this and if
>>> there is any way we can debug this further. When I try to
>>> attach and debug, the upload however seems to go through fine
>>> and is only failing when I am not attached to the process. Any
>>> help / suggestions would be much appreciated.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Srijith.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> -
>>
>>
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
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5w3bkACgkQHPApP6U8
pFg/gg/+MHNKYcFiWA3njQuNxqY2DRumdXryFIep9Ezi6L7KpLAwfGSpi+BMZLew
53d+JjWPhjLebjB2zEQAXdXvl9fHtHWDJoH4QKXYcjm7Lljj1ZpsGNR99EPWV1hX
dS0aqPo0bfq7cjlg3Euh1vxC+BLccIJOvpC1l4L/UhTkCfDP8O5Yzy8KXkZVl9q3
AFSIHOjC09/1Z51QHHBrOsbuRkN69/Ouuks9pTGA4A53xjN0jBYyiBa8NaOoxt5U
M4H3ipfdDJf41lwPbhBZ51dip0EAh6frI1tWkDKFkJsyms3Byj6sE4sLLw+ViSLy
H0FvbAw75nFBeZlO7Fl0IKKgFxtHaJmMhfBf2sXzkorEv0SQVE/c/5CO4ry+to0O
+9HdtkXXRVfaeCfCdltyvMAWOPDuFGF1Y2MKwFeHT1c/nDcMuzhEUP6QS8SKAJc+
uEsPe4PiJ4441MOF+E9Nj4SpKgfdtnL5M3r36N/Yad23eQGRzhzaB5c6uoPd6HAY
TCcdxf1BXaX+RxjQFbwG4xwmGLrmYiH99tZJ63xm47KbVONdvKCJX5lovcOYiheJ
3PgqNSLojcjMwreyBFVe6oK/CKKolp4i5sEJsfc9GpegBj73aRuMHccaS5RTAn+B
c22P1jzpHbCPkrl5M7dIe00keMAixF0TZ/wWOqp2yMdL8Rx2nUc=
=K4Sn
-END PGP SIGNATURE-

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

[ANN] Apache Tomcat 8.5.53 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.53.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled
forward from the 9.0.x branch. The notable changes since 8.5.51 include:

- Add new attribute persistAuthentication to both StandardManager and
  PersistentManager to support authentication persistence.
  Patch provided by Carsten Klein

- A zero length AJP secret will now behave as if it has not been
  specified.

- Add the TLS request attributes used by IIS to the attributes that
  an AJP Connector will always accept.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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

[ANN] Apache Tomcat 9.0.33 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.33.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.33 is a bugfix and feature release. The notable
changes compared to 9.0.31 include:

- Add new attribute persistAuthentication to both StandardManager and
  PersistentManager to support authentication persistence.
  Patch provided by Carsten Klein

- A zero length AJP secret will now behave as if it has not been
  specified.

- Add the TLS request attributes used by IIS to the attributes that
  an AJP Connector will always accept.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html


Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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

Re: Problem compiling jsps after switching to 8.5.51

[Marek Neumann]

> Am 17.03.2020 um 12:21 schrieb Mark Thomas :
> 
> On 17/03/2020 09:29, Marek Neumann wrote:
>> Hi Mark,
>> 
>> I tested with 8.5.53 and the problem still persists. Any idea what we can do?
> 
> Provide us with the simplest possible set of steps to recreate this so
> we can figure out what the root cause is. At a guess, you aren't using
> the EL API provided by the Apache Tomcat project.

How can I verify this? Is it because the JspC is called directly from 
jspc-maven-plugin? Which EL API is used in this case?

This is the stacktrace:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.eclipse.jetty:jetty-jspc-maven-plugin:9.4.24.v20191120:jspc (jspc) on 
project ...: Failure processing jsps
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failure processing 
jsps
at org.eclipse.jetty.jspc.plugin.JspcMojo.execute (JspcMojo.java:278)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
Caused by: org.apache.tools.ant.BuildException: Generation completed with [17] 
errors in [43] milliseconds
at org.apache.jasper.JspC.execute (JspC.java:1543)
at org.eclipse.jetty.jspc.plugin.JspcMojo.compile (JspcMojo.java:347)
at org.eclipse.jetty.jspc.plugin.JspcMojo.execute (JspcMojo.java:272)

Thanks,
Marek

> 
> 
>> 
>> Thanks,
>> 
>> Marek
>> 
>>> Am 

Re: Uploads breaking post upgrade to 9.0.31

[Manuel Dominguez Sarmiento]

Hi Mark, when is 9.0.32 expected to be released? We've seen this issue 
reported by several users, even if we haven't run into this particular 
case directly (yet)


On 17/03/2020 09:51, Mark Thomas wrote:

https://bz.apache.org/bugzilla/show_bug.cgi?id=64202

Mark

On 17/03/2020 11:46, Srijith Kochunni wrote:

Hi All,



   This is to seek help on a strange issue that we are observing. We 
recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, in our 
application, in order to address vulnerability in AJP connector. Ever since 
then we have started seeing upload failures with our upload servlet when 
processing large files. Small files do get uploaded, but when we upload large 
files and we do Multipart file upload, we are randomly and yet consistently 
seeing that we get the following exception.



[org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing 
of multipart/form-data request failed. Stream ended unexpectedly

 at 
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351)

 

Caused by: 
org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream 
ended unexpectedly

 at 
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:1005)

 at 
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:903)

 at java.io.InputStream.read(InputStream.java:101)

 at org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)

 at org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)

 at 
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:347)



   It appears that the connection is getting reset in the middle of the 
upload, but the client is very much up and we get PR_CONNECT_RESET_ERROR on the 
browser.



My code on the server side is as simple as



 DiskFileItemFactory factory = new DiskFileItemFactory();

 ServletFileUpload fileUpload = new ServletFileUpload(factory);



 List fileItems = fileUpload.parseRequest(originalRequest);





   We would like to know if anyone else has observed this and if there is 
any way we can debug this further. When I try to attach and debug, the upload 
however seems to go through fine and is only failing when I am not attached to 
the process. Any help / suggestions would be much appreciated.







Thanks,



Srijith.








-
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

[ANN] Apache Tomcat 10.0.0-M3 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.0.0-M3.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is under development to aid
this process.

Apache Tomcat 10.0.0-M3 is a milestone release of the 10.0.x
branch and has been made to provide users with early access to the new
features in Apache Tomcat 10.0.x so that they may provide feedback. The
notable changes compared to 10.0.0-M1 include:

- Disable session persistence by default (on restart)

- Add new attribute persistAuthentication to both StandardManager and
  PersistentManager to support authentication persistence.
  Patch provided by Carsten Klein

- A zero length AJP secret will now behave as if it has not been
  specified.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: Uploads breaking post upgrade to 9.0.31

[Mark Thomas]

https://bz.apache.org/bugzilla/show_bug.cgi?id=64202

Mark

On 17/03/2020 11:46, Srijith Kochunni wrote:
> Hi All,
> 
> 
> 
>   This is to seek help on a strange issue that we are observing. We 
> recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, in our 
> application, in order to address vulnerability in AJP connector. Ever since 
> then we have started seeing upload failures with our upload servlet when 
> processing large files. Small files do get uploaded, but when we upload large 
> files and we do Multipart file upload, we are randomly and yet consistently 
> seeing that we get the following exception.
> 
> 
> 
> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: 
> Processing of multipart/form-data request failed. Stream ended unexpectedly
> 
> at 
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351)
> 
> 
> 
>Caused by: 
> org.apache.commons.fileupload.MultipartStream$MalformedStreamException: 
> Stream ended unexpectedly
> 
> at 
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:1005)
> 
> at 
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:903)
> 
> at java.io.InputStream.read(InputStream.java:101)
> 
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)
> 
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)
> 
> at 
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:347)
> 
> 
> 
>   It appears that the connection is getting reset in the middle of 
> the upload, but the client is very much up and we get PR_CONNECT_RESET_ERROR 
> on the browser.
> 
> 
> 
>My code on the server side is as simple as
> 
> 
> 
> DiskFileItemFactory factory = new DiskFileItemFactory();
> 
> ServletFileUpload fileUpload = new ServletFileUpload(factory);
> 
> 
> 
> List fileItems = fileUpload.parseRequest(originalRequest);
> 
> 
> 
> 
> 
>   We would like to know if anyone else has observed this and if there is 
> any way we can debug this further. When I try to attach and debug, the upload 
> however seems to go through fine and is only failing when I am not attached 
> to the process. Any help / suggestions would be much appreciated.
> 
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> 
> 
> Srijith.
> 
> 
> 
> 
> 
> 


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

Uploads breaking post upgrade to 9.0.31

[Srijith Kochunni]

Hi All,



  This is to seek help on a strange issue that we are observing. We 
recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, in our 
application, in order to address vulnerability in AJP connector. Ever since 
then we have started seeing upload failures with our upload servlet when 
processing large files. Small files do get uploaded, but when we upload large 
files and we do Multipart file upload, we are randomly and yet consistently 
seeing that we get the following exception.



[org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing 
of multipart/form-data request failed. Stream ended unexpectedly

at 
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351)



   Caused by: 
org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream 
ended unexpectedly

at 
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:1005)

at 
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:903)

at java.io.InputStream.read(InputStream.java:101)

at org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)

at org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)

at 
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:347)



  It appears that the connection is getting reset in the middle of the 
upload, but the client is very much up and we get PR_CONNECT_RESET_ERROR on the 
browser.



   My code on the server side is as simple as



DiskFileItemFactory factory = new DiskFileItemFactory();

ServletFileUpload fileUpload = new ServletFileUpload(factory);



List fileItems = fileUpload.parseRequest(originalRequest);





  We would like to know if anyone else has observed this and if there is 
any way we can debug this further. When I try to attach and debug, the upload 
however seems to go through fine and is only failing when I am not attached to 
the process. Any help / suggestions would be much appreciated.







Thanks,



Srijith.

Re: Advice please for Tomcat 8.5.53-dev with log4j2

[Mark Thomas]

On 17/03/2020 06:05, Brian Burch wrote:
> I have a very frozen and stable tomcat 7.0.68 system with a lot of apps.
> It was build from source and uses the extras tomcat-juli.jar with
> log4j-1.2.17.jar.
> 
> Both tomcat and my webapps log successfully via log4j (except, of
> course, the access log valve).
> 
> The time has come to bring the whole system up to date, but I don't want
> to jump too far in a single leap, so I am trying to port the production
> environment to a new server image. (The old system is ubuntu 16.04.6 LTS
> 32-bit. The new system is 18.04.3 LTS 64-bit).



> I would be very grateful for any advice to make my tomcat8 use log4j2. I
> hope this advice will permit me to recommend some improvements to the
> relevant pages of the tomcat wiki...

I haven't test this extensively so there may be some edge case that need
fixing.

Some background for those who may be less familiar with the topic.

JULI, as provided by Tomcat, is a packaged renamed version of Apache
Commons Logging hard-coded to output to java.util.logging.

The old log4j extras package (still present in Tomcat 7) was a packaged
renamed version of Apache Commons Logging hard-coded to output to log4j v1.

Essentially, there were two logging implementations and you picked the
one you wanted.

With log4j v1 reaching end-of-life, Tomcat 8.5.x onwards has the option
of outputting to log4j v2 but the way it is configured is very different.

log4j v2 provides an adaptor that lets it "intercept" log messages sent
to java.util.logging. The idea is that this adapter is used with Tomcat
8.5.x onwards.

The configuration steps are (using v2.13.1):

0. Leave the Tomcat logging configuration as is.

1. Add the required log4j JARs. They are:
   - log4j-jul-2.13.1.jar
   - log4j-api-2.13.1.jar
   - log4j-core-2.13.1.jar

Where you put them doesn't really matter. For consistency with Tomcat
I'd place them in the bin directory.

2. Add the required configuration file. For consistency with Tomcat I'd
call it log4j2.xml and place it in the conf directory. The file I used was:



  

  

  
  

  

  


This is essentially the default config but with the logging level
changed to info so you actually see something.

3. You then need to configure:
   - the java.util.logging logging manager so log4j v2 intercepts the
 log messages
   - the configuration file so the right messages are logged
   - the classpath so the log4j v2 JARs are found.

You can do all of this in setenv.[sh|bat]. The file I used was:

!#/bin/sh
JAVA_OPTS="-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
-Dlog4j.configurationFile=$CATALINA_BASE/conf/log4j2.xml"
CLASSPATH=$CATALINA_BASE/bin/log4j-jul-2.13.1.jar:$CATALINA_BASE/bin/log4j-core-2.13.1.jar:$CATALINA_BASE/bin/log4j-api-2.13.1.jar

Excuse the poor formatting with line wrapping and adjust appropriately
if you are on Windows.

I used CATALINA_BASE above but it works equally well with CATALINA_HOME.
If you have split HOME and BASE you can configure this on either.

All of this was with Tomcat 10 but it should be the same with 9.0.x and
8.5.x.

A patch or PR to add the above (once you have confirmed it is complete)
to https://github.com/apache/tomcat/blob/master/webapps/docs/logging.xml
would be very helpful.

> Thanks in anticipation,
> 
> Brian
> 
> (back on the list after nearly 4 years away!)

Welcome back.

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

Re: Problem compiling jsps after switching to 8.5.51

[Mark Thomas]

On 17/03/2020 09:29, Marek Neumann wrote:
> Hi Mark,
> 
> I tested with 8.5.53 and the problem still persists. Any idea what we can do?

Provide us with the simplest possible set of steps to recreate this so
we can figure out what the root cause is. At a guess, you aren't using
the EL API provided by the Apache Tomcat project.

Mark


> 
> Thanks,
> 
> Marek
> 
>> Am 28.02.2020 um 12:36 schrieb Mark Thomas :
>>
>> On 28/02/2020 10:57, Marek Neumann wrote:
>>> After going to the latest 8.5 release we have problems with jasper 
>>> compiling jsps:
>>>
>>> [WARNING] org.apache.jasper.JasperException: javax.el.ELException: Unable 
>>> to find ExpressionFactory of type: # Licensed to the Apache Software 
>>> Foundation (ASF) under one or more
>>>
>>> We are using jetty-jspc-maven-plugin in version 9.4.24 to compile. There 
>>> was a change to service loading: 
>>> https://github.com/apache/tomcat/commit/ef13eb8fd9962432d244a7aad9cd85998d4cd3b9#diff-305be246f9d4a2068624785e76ee06efR1
>>>
>>> Somehow the apache expression implementation 
>>> (org.apache.el.ExpressionFactoryImpl) cannot be found anymore. Is there 
>>> anything that need to be changed in our setup? Going back to 8.5.50 for 
>>> jasper-el solves the problem.
>>
>> This is likely the same as:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=64153
>>
>> Waiting for 8.5.52 is probably the simplest solution.
>>
>> You should be OK to compile with 8.5.50 but run with 8.5.51 if you need to.
>>
>> Mark
>>
>> -
>> 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: Problem compiling jsps after switching to 8.5.51

[Marek Neumann]

Hi Mark,

I tested with 8.5.53 and the problem still persists. Any idea what we can do?

Thanks,

Marek

> Am 28.02.2020 um 12:36 schrieb Mark Thomas :
> 
> On 28/02/2020 10:57, Marek Neumann wrote:
>> After going to the latest 8.5 release we have problems with jasper compiling 
>> jsps:
>> 
>> [WARNING] org.apache.jasper.JasperException: javax.el.ELException: Unable to 
>> find ExpressionFactory of type: # Licensed to the Apache Software Foundation 
>> (ASF) under one or more
>> 
>> We are using jetty-jspc-maven-plugin in version 9.4.24 to compile. There was 
>> a change to service loading: 
>> https://github.com/apache/tomcat/commit/ef13eb8fd9962432d244a7aad9cd85998d4cd3b9#diff-305be246f9d4a2068624785e76ee06efR1
>> 
>> Somehow the apache expression implementation 
>> (org.apache.el.ExpressionFactoryImpl) cannot be found anymore. Is there 
>> anything that need to be changed in our setup? Going back to 8.5.50 for 
>> jasper-el solves the problem.
> 
> This is likely the same as:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64153
> 
> Waiting for 8.5.52 is probably the simplest solution.
> 
> You should be OK to compile with 8.5.50 but run with 8.5.51 if you need to.
> 
> Mark
> 
> -
> 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

Advice please for Tomcat 8.5.53-dev with log4j2

[Brian Burch]

I have a very frozen and stable tomcat 7.0.68 system with a lot of apps. 
It was build from source and uses the extras tomcat-juli.jar with 
log4j-1.2.17.jar.


Both tomcat and my webapps log successfully via log4j (except, of 
course, the access log valve).


The time has come to bring the whole system up to date, but I don't want 
to jump too far in a single leap, so I am trying to port the production 
environment to a new server image. (The old system is ubuntu 16.04.6 LTS 
32-bit. The new system is 18.04.3 LTS 64-bit).


I have read (very carefully) the tomcat8 logging.html, 
extras.html#Full_commons-logging_implementation and 
class-loader-howto.html. I am aware of 
https://bz.apache.org/bugzilla/show_bug.cgi?id=58588. They have confused 
me, even though I've read them a lot in the past!


I have built tomcat 8.5.53-dev under OpenJDK 1.8.0_232 (64 bit), and 
also the extras. tomcat also executes under jdk8.


Extras no longer builds the full logging jar, so I am apparently forced 
to use the tomcat-juli.jar from the main build. log4j has moved from 
version 1 to 2, with quite a few changes, so I decided to implement 
log4j2 right from the start.


To simplify my conversion effort, I decided to get tomcat itself logging 
via laog4j2 before I converted any of the webapps. That has been a 
frustrating and unsuccessful task so far!


I can confirm the experience of others - unless tomcat-juli.jar is in 
the same directory as bootstrap.jar (catalina.home/bin), startup fails 
with ClassNotFoundException.


I do NOT have a logging.properties file in conf.

catalina.base/lib has my log4j2.xml, along with log4j-api.jar, 
log4j-core.jar and log4j-jul.jar. I have tried them in a lot of places, 
including catalina.home/bin, catalina.base/system, common and server, 
but nothing seems to improve.


/var/log/tc8/catalina.out reports (apologies for nasty line breaks):

Mar 17, 2020 8:45:34 AM 
org.apache.catalina.startup.VersionLoggerListener log
INFO: Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager


But there are no initialisation messages from log4j2.

The log4j2 Root Logger has AppenderRef to a RollingFileAppender with 
fileName="${logdir}/catalina.log" (where logdir resolves to 
/var/log/tomcat/).


I am not convinced catalina.out is being handled by log4j2 at all!

I would be very grateful for any advice to make my tomcat8 use log4j2. I 
hope this advice will permit me to recommend some improvements to the 
relevant pages of the tomcat wiki...


Thanks in anticipation,

Brian

(back on the list after nearly 4 years away!)

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