Re: Web.xml file question

[Christopher Schultz]

Lance,

On 11/21/23 11:33, Campbell, Lance wrote:

Tomcat 10.1
Java migration from 8 to 11
Eclipse

I am trying to migrate my thirteen tomcat web applications from java 8 to java 
11. And from tomcat 9 to tomcat 10.1 .

I have been using the web.xml file for years with Java 8 and tomcat 9. However, 
when I built my dynamic web application with eclipse I don't see a web.xml 
file. I looked at the example web application in the tomcat 10.1 download. Is 
the below top part of the web.xml file appropriate for java 11 running 10.1


https://jakarta.ee/xml/ns/jakartaee

   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

   xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee

   https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd;

   version="6.0"

   metadata-complete="true">


It seems so. Here is the default web.xml for that branch of the server:
https://github.com/apache/tomcat/blob/10.1.x/conf/web.xml

-chris

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

Web.xml file question

[Campbell, Lance]

Tomcat 10.1
Java migration from 8 to 11
Eclipse

I am trying to migrate my thirteen tomcat web applications from java 8 to java 
11. And from tomcat 9 to tomcat 10.1 .

I have been using the web.xml file for years with Java 8 and tomcat 9. However, 
when I built my dynamic web application with eclipse I don't see a web.xml 
file. I looked at the example web application in the tomcat 10.1 download. Is 
the below top part of the web.xml file appropriate for java 11 running 10.1


https://jakarta.ee/xml/ns/jakartaee

  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

  xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee

  https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd;

  version="6.0"

  metadata-complete="true">

Thanks,

Lance

Re: Need Help : Tomcat 9.0.75 not honoring session timeout configured in tomcat web.xml for FORM Authentication

[Christopher Schultz]

Channa,

On 10/27/23 00:07, Channa Puchakayala wrote:

Tomcat Version : 9.0.75

Operating System: Windows and Linux

Bits: 64

Tomcat 9.0.75 not honoring  session timeout configured in 
tomcat/conf/web.xml for FORM Authentication and it is effecting customers.


==

    

     30 // 30 minutes

     

=

Verified the Tomcat source code

-FormAuthenticator overriding above configured session timeout setting 
(30 minutes)  with value (120 seconds)


-As per FormAuthenticator.Java, this change/issue started from Tomcat 
Version : 9.0.74 for FORM Authentication and it overwrites the original 
session-timeout value


-This issue/behavior not observed in 9.0.73

Verified the Tomcat documentation

-Verified the tomcat changelog, there is a fix/change went in Tomcat 
9.0.74 below related to FORM Based Authentication Session @ 
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html 
<https://tomcat.apache.org/tomcat-9.0-doc/changelog.html>, looks which 
is causing this issue.



Can you please state clearly what the issue actually is? This is 
documented behavior of Tomcat. There is a well-documented setting that 
you can adjust if necessary.


Are you reporting a problem? If so, it is not clear from your message above.

What test did you perform?
What did you expect to happen?
What actually happened that was different from your expectation?

-chris


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

RE: Tomcat 9.0.75 ignoring session timeout configured in tomcat conf web.xml

[Channa Puchakayala]

Hi All,

Bug already raised below against Tomcat for the same issue.

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

Thank You Mark.

Regards
Channa

-Original Message-
From: Mark Thomas 
Sent: Friday, October 27, 2023 11:25 AM
To: Tomcat Users List 
Subject: Re: Tomcat 9.0.75 ignoring session timeout configured in tomcat
conf web.xml

26 Oct 2023 05:01:49 Channa Puchakayala
:

> Hi All,
>
>
> Tomcat Version : 9.0.75
> Operating System: Windows and Linux
> Bits: 64
>
>
> Tomcat 9.0.75 ignoring session timeout configured in
> tomcat/conf/web.xml, it is overriding previous session timeout setting
> and effecting existing customers.
> ==
>
> 30
> 
> =
>
>
> Looks this change/issue started from Tomcat Version : 9.0.74 for
> FormAuthenticator, why it overwrites the original session-timeout ? is
> it bug ? Could you please help/suggest.

Have you checked the open issues in bugzilla?

Have you checked Bugzilla / CI changelog to see if the issue has already
been fixed for the next release?

Mark

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

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Need Help : Tomcat 9.0.75 not honoring session timeout configured in tomcat web.xml for FORM Authentication

[Mark Thomas]

1. Do not cross-post the same question to multiple lists.

2. Do not post the same question multiple times if you don't get an 
answer as quickly as you would like. We all all volunteers here. If you 
want a guaranteed SLA then pick you preferred vendor and pay for support.


Mark


27 Oct 2023 05:07:20 Channa Puchakayala 
:



Hi All,
 

Tomcat Version : 9.0.75
Operating System: Windows and Linux
Bits: 64   
 

Tomcat 9.0.75 not honoring  session timeout configured in 
tomcat/conf/web.xml for FORM Authentication and it is effecting 
customers.

==
   
    30 // 30 minutes
    
=
 

Verified the Tomcat source code
-    FormAuthenticator overriding above configured session timeout 
setting (30 minutes)  with value (120 seconds)
-    As per FormAuthenticator.Java, this change/issue started from 
Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the 
original session-timeout value

-    This issue/behavior not observed in 9.0.73
 

Verified the Tomcat documentation
-    Verified the tomcat changelog, there is a fix/change went in 
Tomcat 9.0.74 below related to FORM Based Authentication Session @ 
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is 
causing this issue.


--
Harden the FORM authentication process against DoS attacks by using a 
reduced session timeout if the FORM authentication process creates a 
session. The duration of this timeout is configured by 
the *authenticationSessionTimeout* attribute of the FORM authenticator. 
(markt)


-
 

Is it bug ? Could you please help/suggest.
 

Thanks
Channa
 


This electronic communication and the information and any files 
transmitted with it, or attached to it, are confidential and are 
intended solely for the use of the individual or entity to whom it is 
addressed and may contain information that is confidential, legally 
privileged, protected by privacy laws, or otherwise restricted from 
disclosure to anyone else. If you are not the intended recipient or the 
person responsible for delivering the e-mail to the intended recipient, 
you are hereby notified that any use, copying, distributing, 
dissemination, forwarding, printing, or copying of this e-mail is 
strictly prohibited. If you received this e-mail in error, please 
return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


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

Re: Tomcat 9.0.75 ignoring session timeout configured in tomcat conf web.xml

[Mark Thomas]

26 Oct 2023 05:01:49 Channa Puchakayala 
:



Hi All,
 

Tomcat Version : 9.0.75
Operating System: Windows and Linux
Bits: 64   
 

Tomcat 9.0.75 ignoring session timeout configured in 
tomcat/conf/web.xml, it is overriding previous session timeout setting 
and effecting existing customers.

==
   
    30
    
=
 

Looks this change/issue started from Tomcat Version : 9.0.74 for 
FormAuthenticator, why it overwrites the original session-timeout ? is 
it bug ? Could you please help/suggest.


Have you checked the open issues in bugzilla?

Have you checked Bugzilla / CI changelog to see if the issue has already 
been fixed for the next release?


Mark

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

Need Help : Tomcat 9.0.75 not honoring session timeout configured in tomcat web.xml for FORM Authentication

[Channa Puchakayala]

Hi All,



Tomcat Version : 9.0.75

Operating System: Windows and Linux

Bits: 64



Tomcat 9.0.75 not honoring  session timeout configured in
tomcat/conf/web.xml for FORM Authentication and it is effecting customers.

==

   

30 // 30 minutes



=



Verified the Tomcat source code

-FormAuthenticator overriding above configured session timeout
setting (30 minutes)  with value (120 seconds)

-As per FormAuthenticator.Java, this change/issue started from
Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the
original session-timeout value

-This issue/behavior not observed in 9.0.73



Verified the Tomcat documentation

-Verified the tomcat changelog, there is a fix/change went in
Tomcat 9.0.74 below related to FORM Based Authentication Session @
https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is
causing this issue.

--

Harden the FORM authentication process against DoS attacks by using a
reduced session timeout if the FORM authentication process creates a
session. The duration of this timeout is configured by the
authenticationSessionTimeout attribute of the FORM authenticator. (markt)

-



Is it bug ? Could you please help/suggest.



Thanks

Channa

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature

Tomcat 9.0.75 ignoring session timeout configured in tomcat conf web.xml

[Channa Puchakayala]

Hi All,



Tomcat Version : 9.0.75

Operating System: Windows and Linux

Bits: 64



Tomcat 9.0.75 ignoring session timeout configured in tomcat/conf/web.xml,
it is overriding previous session timeout setting and effecting existing
customers.

==

   

30



=



Looks this change/issue started from Tomcat Version : 9.0.74 for
FormAuthenticator, why it overwrites the original session-timeout ? is it
bug ? Could you please help/suggest.



Thanks

Channa

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: tomcat9 access denied /var/lib/tomcat9/conf/web.xml

[Mark Thomas]

The security manager is deprecated in newer versions of Java. If you are 
new to Tomcat, whatever problem using the security manager is intended 
to solve, I'd strongly encourage you to find an alternative solution.


The codebase refers to the JAR trying to read the file, not the file the 
JAR is trying to read.


I suspect the Debian distribution hasn't updated the catalina.policy 
file to take account of the way Debian redistributes the Tomcat files 
around the file system. If you really do want to use the security 
manager, you'll need to take that up with the Debian folks.


Mark


On 21/12/2022 17:20, Alban Espié-Guillon wrote:

Hello,

I'm very new to tomcat, forgive me if I did not found my answer 
elsewhere, i'm currently out of of ideas.


I'm trying to setup a standalone tomcat9 (9.0.31-1~deb10u7) on Debian 
11, with security manager enabled.


I'm seeing in catalina logs the following stacktrace (full stacktrace 
provided in attachment):


37 21-Dec-2022 16:12:04.587 SEVERE [main] 
org.apache.tomcat.util.descriptor.web.WebXmlParser.parseWebXml Parse 
error in application web.xml file at [file:/var/lib/tomcat9/conf/web.xml]
38 java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" 
"accessClassInPackage.org.apache.tomcat.util.buf")


Disabling the security manager makes it disappear, but I don't 
understand why tomcat has an issue reading 
/var/lib/tomcat9/conf/web.xml, which is a simlink to 
/etc/tomcat9/web.xml, and I did not edit the file as you see:


# ll /etc/tomcat9/web.xml
-rw-r- 1 root tomcat 169K Feb  5  2020 /etc/tomcat9/web.xml

I tried to add the following policy in case of it could help:

grant codeBase "file:/var/lib/tomcat9/conf/web.xml" {
     permission java.security.AllPermission;
};

But the error was still logged.



-
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

tomcat9 access denied /var/lib/tomcat9/conf/web.xml

[Alban Espié-Guillon]

Hello,

I'm very new to tomcat, forgive me if I did not found my answer 
elsewhere, i'm currently out of of ideas.


I'm trying to setup a standalone tomcat9 (9.0.31-1~deb10u7) on Debian 
11, with security manager enabled.


I'm seeing in catalina logs the following stacktrace (full stacktrace 
provided in attachment):


37 21-Dec-2022 16:12:04.587 SEVERE [main] 
org.apache.tomcat.util.descriptor.web.WebXmlParser.parseWebXml Parse 
error in application web.xml file at [file:/var/lib/tomcat9/conf/web.xml]
38 java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" 
"accessClassInPackage.org.apache.tomcat.util.buf")


Disabling the security manager makes it disappear, but I don't 
understand why tomcat has an issue reading 
/var/lib/tomcat9/conf/web.xml, which is a simlink to 
/etc/tomcat9/web.xml, and I did not edit the file as you see:


# ll /etc/tomcat9/web.xml
-rw-r- 1 root tomcat 169K Feb  5  2020 /etc/tomcat9/web.xml

I tried to add the following policy in case of it could help:

grant codeBase "file:/var/lib/tomcat9/conf/web.xml" {
    permission java.security.AllPermission;
};

But the error was still logged.

--
Alban Espié-Guillon
OW2 System Administrator
21-Dec-2022 16:12:02.714 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name:   Apache Tomcat/9.0.31 (Debian)
21-Dec-2022 16:12:02.715 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:  Oct 25 2022 15:43:18 UTC
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 9.0.31.0
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:   Linux
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:4.19.0-22-amd64
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:  amd64
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/java-11-openjdk-amd64
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version:   11.0.16+8-post-Debian-1deb10u1
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor:Debian
21-Dec-2022 16:12:02.716 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /var/lib/tomcat9
21-Dec-2022 16:12:02.717 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /usr/share/tomcat9
21-Dec-2022 16:12:02.746 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED
21-Dec-2022 16:12:02.746 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED
21-Dec-2022 16:12:02.746 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
21-Dec-2022 16:12:02.746 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
21-Dec-2022 16:12:02.747 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
21-Dec-2022 16:12:02.747 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.awt.headless=true
21-Dec-2022 16:12:02.747 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dfile.encoding=utf8
21-Dec-2022 16:12:02.747 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Xmx1024m
21-Dec-2022 16:12:02.747 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
21-Dec-2022 16:12:02.747 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
21-Dec-2022 16:12:02.747 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
21-Dec-2022 16:12:02.748 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs=
21-Dec-2022 16:12:02.748 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.security.manager
21-Dec-2022 16:12:02.748 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.security.policy==/var/lib/tomcat9/policy/catalina.policy
21-Dec-2022 16:12:02.749 INFO [main] org.apache.catalina.startup.VersionLoggerList

RE: xsd version used for web.xml etc

[S Abirami]

Thanks a lot Mark.

-Original Message-
From: Mark Thomas  
Sent: Thursday, October 21, 2021 4:23 PM
To: users@tomcat.apache.org
Subject: Re: xsd version used for web.xml etc

On 21/10/2021 10:37, S Abirami wrote:
> Hi Thomas,
> 
> How I can identify whether the schema validation enabled or not.
> I checked startup logs and other configuration.
> 
> I am unable to find it.

The quick test is to add an unknown element to web.xml and see what happens. If 
you get an error, validation is enabled. If it is ignored, validation is not 
enabled.

It is typically configured in $CATALINA_BASE/conf/context.xml

See https://tomcat.apache.org/tomcat-9.0-doc/config/context.html
Of particular interest:
xmlNamespaceAware
xmlValidation

Mark


> 
> Regards,
> Abirami.S
> 
> -Original Message-
> From: Mark Thomas 
> Sent: Thursday, October 21, 2021 2:40 PM
> To: users@tomcat.apache.org
> Subject: Re: xsd version used for web.xml etc
> 
> On 21/10/2021 09:45, S Abirami wrote:
>> Hi All,
>>
>> In web.xml, if we didn't define any xsd schema or dtd schema which version 
>> of xsd will be loaded for Tomcat 9.0.45.
> 
> By default none - whether a schema is defined or not. Schemas are only loaded 
> if validation is enabled.
> 
> With validation disabled, Tomcat will treat the content of a web.xml file as 
> if it is using the schema associated with the Servlet 4.0 specification.
> 
> 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: xsd version used for web.xml etc

[Mark Thomas]

On 21/10/2021 10:37, S Abirami wrote:

Hi Thomas,

How I can identify whether the schema validation enabled or not.
I checked startup logs and other configuration.

I am unable to find it.


The quick test is to add an unknown element to web.xml and see what 
happens. If you get an error, validation is enabled. If it is ignored, 
validation is not enabled.


It is typically configured in $CATALINA_BASE/conf/context.xml

See https://tomcat.apache.org/tomcat-9.0-doc/config/context.html
Of particular interest:
xmlNamespaceAware
xmlValidation

Mark




Regards,
Abirami.S

-Original Message-
From: Mark Thomas 
Sent: Thursday, October 21, 2021 2:40 PM
To: users@tomcat.apache.org
Subject: Re: xsd version used for web.xml etc

On 21/10/2021 09:45, S Abirami wrote:

Hi All,

In web.xml, if we didn't define any xsd schema or dtd schema which version of 
xsd will be loaded for Tomcat 9.0.45.


By default none - whether a schema is defined or not. Schemas are only loaded 
if validation is enabled.

With validation disabled, Tomcat will treat the content of a web.xml file as if 
it is using the schema associated with the Servlet 4.0 specification.

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: xsd version used for web.xml etc

[S Abirami]

Hi Thomas,

How I can identify whether the schema validation enabled or not.
I checked startup logs and other configuration.

I am unable to find it.

Regards,
Abirami.S

-Original Message-
From: Mark Thomas  
Sent: Thursday, October 21, 2021 2:40 PM
To: users@tomcat.apache.org
Subject: Re: xsd version used for web.xml etc

On 21/10/2021 09:45, S Abirami wrote:
> Hi All,
> 
> In web.xml, if we didn't define any xsd schema or dtd schema which version of 
> xsd will be loaded for Tomcat 9.0.45.

By default none - whether a schema is defined or not. Schemas are only loaded 
if validation is enabled.

With validation disabled, Tomcat will treat the content of a web.xml file as if 
it is using the schema associated with the Servlet 4.0 specification.

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

RE: xsd version used for web.xml etc

[S Abirami]

Thanks Thomas.

-Original Message-
From: Mark Thomas  
Sent: Thursday, October 21, 2021 2:40 PM
To: users@tomcat.apache.org
Subject: Re: xsd version used for web.xml etc

On 21/10/2021 09:45, S Abirami wrote:
> Hi All,
> 
> In web.xml, if we didn't define any xsd schema or dtd schema which version of 
> xsd will be loaded for Tomcat 9.0.45.

By default none - whether a schema is defined or not. Schemas are only loaded 
if validation is enabled.

With validation disabled, Tomcat will treat the content of a web.xml file as if 
it is using the schema associated with the Servlet 4.0 specification.

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

Re: xsd version used for web.xml etc

[Mark Thomas]

On 21/10/2021 09:45, S Abirami wrote:

Hi All,

In web.xml, if we didn't define any xsd schema or dtd schema which version of 
xsd will be loaded for Tomcat 9.0.45.


By default none - whether a schema is defined or not. Schemas are only 
loaded if validation is enabled.


With validation disabled, Tomcat will treat the content of a web.xml 
file as if it is using the schema associated with the Servlet 4.0 
specification.


Mark

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

RE: xsd version used for web.xml etc

[S Abirami]

Hi All,

TOMCAT_BASE/conf/web.xml will be constructed by us during installation.

So that web.xml also will not have xsd definition.

Regards,
Abirami.S

-Original Message-
From: Jean-Pierre Urkens  
Sent: Thursday, October 21, 2021 2:25 PM
To: Tomcat Users List 
Subject: RE: xsd version used for web.xml etc

My guess, the one that is specified in TOMCAT_BASE/conf/web.xml

-Original Message-
From: S Abirami 
Sent: donderdag 21 oktober 2021 10:46
To: Tomcat Users List 
Subject: xsd version used for web.xml etc

Hi All,

In web.xml, if we didn't define any xsd schema or dtd schema which version of 
xsd will be loaded for Tomcat 9.0.45.

Regards,
Abirami.S

-
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: xsd version used for web.xml etc

[Jean-Pierre Urkens]

My guess, the one that is specified in TOMCAT_BASE/conf/web.xml

-Original Message-
From: S Abirami 
Sent: donderdag 21 oktober 2021 10:46
To: Tomcat Users List 
Subject: xsd version used for web.xml etc

Hi All,

In web.xml, if we didn't define any xsd schema or dtd schema which version
of xsd will be loaded for Tomcat 9.0.45.

Regards,
Abirami.S

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

xsd version used for web.xml etc

[S Abirami]

Hi All,

In web.xml, if we didn't define any xsd schema or dtd schema which version of 
xsd will be loaded for Tomcat 9.0.45.

Regards,
Abirami.S

Re: How to write a filter in web.xml to accept partially a URL ?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gilbert,

On 4/25/20 08:47, Gilbert Soucy wrote:
> Hello,
>
> I am new to tomcat and I need to filter the URLs to accept all
> clients for part of a URL and reject for all clients another part
> of this URL.
>
> In details, I want:
>
> /abc/def/xyz/*   : accepts all /abc/def/*:  reject
> if URL does  not match /abc/def/xyz*
>
>
> I found that the order in which the filters are done is explained
> in this link (
> https://stackoverflow.com/questions/17086712/servlet-filters-order-of-
execution
>
>
).
>
> Based on this, I did the following 2 filters:
>
> 1) Accept All : this one is the most precise url-pattern and is
> listed 1st. When matching, I hope to accept all IP addresses
>
> 2) Block All  :  this one is more general and should match the
> rest of the URL when the 1st fitler does not match. I hope to
> reject all the IP in this case
>
> Here are the filters, in the order that I add them in web.xml :
>
>  Accept All
> org.apache.catalina.filters.RemoteAddrFilter
>
>

> allow
> \d+\.\d+\.\d+\.\d+ 
>   Accept All
> /abc/def/xyz/* 
>
>  Block All
> org.apache.catalina.filters.RemoteAddrFilter
>
>

> deny
> \d+\.\d+\.\d+\.\d+ 
>   Block All
> /abc/def/* 
>
>
> The result is that all URLs  (  i.e.  /abc/def/* ) are jected and
> /abc/def/xyz/*  is never accepted.
>
> Is there a way to do what I am trying to do ?

Your approach won't work because the servlet container is required to
run all requests through all filters matching the incoming
url-pattern. Since the more-general filter will prohibit all access,
the behavior of the more-specific filter doesn't really matter: the
more-specific filter cannot affect the behavior of the more-general
filter in the way you want because it wasn't written that way.

Since you aren't actually using the RemoreAddrFilter for its intended
purpose (just trying to replicate httpd's "Deny from all" or "Accept
from all" semantics), you can do this in a few ways.

1. Write a Filter to check the path

The filter would be simple:

public SelectiveRemoteAddrFilter implements Filter {
  public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain) throws IOException, ServletException {
if(request.getRequestURI().startsWith("/abc/def/xyz/")) {
// Accept All
chain.doFilter(request, response);
} else {

((HttpServletResponse)response).sendError(HttpServletResponse.SC_FORBIDD
EN);
}
  }
}

2. Use servlet-mappings instead of filter-mappings

While filter-mappings are cumulative and therefore multiple filters
can be run on a request, servlet-mappings result in exactly one
servlet being invoked for any particular request.

  
do-something-servlet
/abd/def/xyz/*
  

  
return-forbidden-servlet
/abd/def/*
  

You'll need to decide what do-something-servlet is and you can fairly
easily implement return-forbidden-servlet yourself.

3. Get tricky

You could even avoid writing code altogether and do it like this,
since filters can be mapped to servlets instead of url-patterns:

  
forbidden

org.apache.catalina.servlets.DefaultServlet
  

  
do-something-servlet
/abd/def/xyz/*
  

  
forbidden
/abd/def/*
  

  
Block All
forbidden
  

This allows you to do with with only configuration and not any code
other than what you already have for your own application.

4. Use url-rewrite

Have a look at this:
https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html

Or this:
https://tuckey.org/urlrewrite/

I believe you could build what you desire with configuration of either
of the two tools above.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6lwMkACgkQHPApP6U8
pFj7dhAAhykAxTmwiOGa61T5OjRg9LZH5bN9z28kWfzlD//nd7bQ6GiEI/OSOX3o
SjrNCMvAtTqAjMNhadvqZeAVjorOQ3VWA3hRKVoVSCwY0y894okFypN6vctYZRjU
J6/Ufj1m2lm1Abx2ak11M60ctbGkUcqnnMcHfyOTzaW8QVqYK6c6EJxpEkMHiQ6W
I9ix3UtzuTn7Lc4EwLwrup9ehJN/vVISnr+b9vV1T0bfHftN6gT7rG7gyZS4V4cB
t45Qs+fLgsKOxKsxd357aKHuMiQzHmb5NKvXwHuuBvMCnkblxCfDJDQcRdxaQuFU
yBJ0IjwZK4HnBaplSlLKB5gZdlxEqnBV90bsHdt37ugJuu+EhFUYKRdh+9CVl/L9
0TGYcLffurYkiR0cRusq0kHl+qXt7oXapmgzBk5JO9ht/+9qXlhlTb0l50mYfOQr
oICVTTUVT9HXLNnHI8+11wv9/RiDZPXe9VIspY5WtLwGC/EzrbXaoK3t7E99Z5Ps
UYHvvgWCXK0J+O/KxD8cYemvVfaZQlE7YtcR1uUGsFrLUnCPun6Jv2SEE1jritHB
n1lCBTysY7S273zZsi5ByEyRwqbBn4qj6pE+9VQ8sY+Jg34WH6Tpa1mYyPj+Lleq
kgqJxZUWZYddIiwlo9H55G17GEmCcqoQoDZLrfnHzHRAHmucj98=
=7tgi
-END PGP SIGNATURE-

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

Re: How to write a filter in web.xml to accept partially a URL ?

[Frank Tornack]

Hi Gilbert,

maybe you have more luck with the security-constraint in tomcat.

kindly 
Frank

Am Samstag, den 25.04.2020, 08:47 -0400 schrieb Gilbert Soucy:
> Hello,
> 
> I am new to tomcat and I need to filter the URLs to accept all
> clients for
> part of a URL and reject for all clients another part of this URL.
> 
> In details, I want:
> 
> /abc/def/xyz/*   : accepts all
> /abc/def/*:  reject if URL does  not match /abc/def/xyz*
> 
> 
> I found that the order in which the filters are done is explained in
> this
> link (
> https://stackoverflow.com/questions/17086712/servlet-filters-order-of-execution
> ).
> 
> Based on this, I did the following 2 filters:
> 
> 1) Accept All : this one is the most precise url-pattern and is
> listed
> 1st. When matching, I hope to accept all IP addresses
> 
> 2) Block All  :  this one is more general and should match the
> rest of
> the URL when the 1st fitler does not match. I hope to reject all the
> IP in
> this case
> 
> Here are the filters, in the order that I add them in web.xml :
> 
> 
>   Accept All
>   org.apache.catalina.filters.RemoteAddrFilter class>
>   
> allow
> \d+\.\d+\.\d+\.\d+
>   
> 
> 
>   Accept All
>   /abc/def/xyz/*
> 
> 
> 
>   Block All
>   org.apache.catalina.filters.RemoteAddrFilter class>
>   
> deny
> \d+\.\d+\.\d+\.\d+
>   
> 
> 
>   Block All
>   /abc/def/*
> 
> 
> 
> The result is that all URLs  (  i.e.  /abc/def/* ) are jected and
> /abc/def/xyz/*  is never accepted.
> 
> Is there a way to do what I am trying to do ?
> 
> Thank you
> 
> Gilbert


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

How to write a filter in web.xml to accept partially a URL ?

[Gilbert Soucy]

Hello,

I am new to tomcat and I need to filter the URLs to accept all clients for
part of a URL and reject for all clients another part of this URL.

In details, I want:

/abc/def/xyz/*   : accepts all
/abc/def/*:  reject if URL does  not match /abc/def/xyz*


I found that the order in which the filters are done is explained in this
link (
https://stackoverflow.com/questions/17086712/servlet-filters-order-of-execution
).

Based on this, I did the following 2 filters:

1) Accept All : this one is the most precise url-pattern and is listed
1st. When matching, I hope to accept all IP addresses

2) Block All  :  this one is more general and should match the rest of
the URL when the 1st fitler does not match. I hope to reject all the IP in
this case

Here are the filters, in the order that I add them in web.xml :


  Accept All
  org.apache.catalina.filters.RemoteAddrFilter
  
allow
\d+\.\d+\.\d+\.\d+
  


  Accept All
  /abc/def/xyz/*



  Block All
  org.apache.catalina.filters.RemoteAddrFilter
  
deny
\d+\.\d+\.\d+\.\d+
  


  Block All
  /abc/def/*



The result is that all URLs  (  i.e.  /abc/def/* ) are jected and
/abc/def/xyz/*  is never accepted.

Is there a way to do what I am trying to do ?

Thank you

Gilbert

Re: Modify web.xml in production war file

[Martynas Jusevičius]

André,

installers are platform-specific, Docker images are not. You do the changes
within the image which is Linux-based, and then deploy the image on any
host platform that supports Docker. Moreover you’re able to deploy
different versions of Tomcat (or other image) on the same system.

Most images have an entrypoint, which is the shell script making changes to
server.xml in this case:
https://github.com/AtomGraph/letsencrypt-tomcat/blob/master/entrypoint.sh


On Wed, 17 Jul 2019 at 02.34, André Warnier (tomcat)  wrote:

> On 16.07.2019 19:54, Martynas Jusevičius wrote:
> > Grigor,
> >
> > I think this is a use case that Docker containers at least partially
> > address.
> >
> > I find deploying containers way easier to share/deploy and more
> > platform-independent than WAR files.
> >
> > I’ve created a Tomcat-based image that accepts ENV variables and modifies
> > server.xml using their values:
> > https://github.com/AtomGraph/letsencrypt-tomcat
> >
> > I think you should be able to do the same with web.xml.
>
> I have not seen your solution. But a question comes to mind : does this
> not just move the
> problem, from tomcat to the Docker container then ?
>
> Why not provide a (shell ? perl ?) installer/updater script, along with
> the application
> WAR, which modifies the application's web.xml (or the server's web.xml) in
> function of
> some site-specific parameter file, which is located somewhere outside the
> tomcat
> directories and remains there ?
>
>
>
> >
> > Martynas
> >
> > On Fri, 12 Jul 2019 at 21.44, Grigor Aleksanyan
> >  wrote:
> >
> >> Hi Everyone,
> >>
> >> We have been shipping web application with war packaging in our
> production
> >> builds which contains a web.xml with few security sections.
> >> This web.xml defines security constraints that are in most cases not
> what
> >> the final deployment uses. This means that to update the war we need to
> >> save new web.xml somewhere, copy the new war, run the server so that it
> >> extracts the war, then shut down the server and copy web.xml back. This
> is
> >> a headache for our cloud based web services upgrade as well as in all
> other
> >> deployment scenarios, including tests.
> >>
> >> To facilitate deployment we've added a new packaging of another war
> file,
> >> which is the same as our original war but its web.xml doesn't contain
> any
> >> security sections.
> >> With an empty web.xml (in terms of security), the security can be
> defined
> >> via server's conf/web.xml, where it belongs, since the security is in
> >> reality defined by the server rather than the war application.
> >> It would be great if we could just replace our default web.xml but if
> some
> >> user uses our default web.xml, they would become unsecured after an
> >> upgrade, so we opted for a separate war.
> >>
> >> Do you guys see any other way of achieving what we aim to achieve with
> the
> >> new war file with default web.xml (backwards compatibility is a
> constraint
> >> in our case)?
> >> Maybe there is a way of ignoring security sections in the war or we can
> >> make it configurable in the code based on some config/env variable?
> >>
> >> Please let me know if you have any considerations about this, any help
> >> would be appreciated.
> >>
> >> Thank you,
> >> -Grigor
> >>
> >> --
> >>
> >>
> >> *
> >> *
> >> *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY
> >> CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.
> IT
> >> IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED
> >> REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE
> >> INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY
> E-MAIL
> >> OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS
> MESSAGE
> >> FROM YOUR SYSTEM.
> >>
> >> E-SIGNATURE NOTICE: Unless specifically set forth
> >> herein, the transmission of this communication is not intended to be a
> >> legally binding electronic signature, and no offer, commitment or assent
> >> on
> >> behalf of OneMarketData, LLC is expressed or implied by the sending of
> >> this
> >> email, or any attachments hereto.
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Modify web.xml in production war file

[Mark Eggers]

André:

See comments inline.

On 7/16/2019 4:37 PM, André Warnier (tomcat) wrote:
> On 16.07.2019 19:54, Martynas Jusevičius wrote:
>> Grigor,
>>
>> I think this is a use case that Docker containers at least partially
>> address.
>>
>> I find deploying containers way easier to share/deploy and more
>> platform-independent than WAR files.
>>
>> I’ve created a Tomcat-based image that accepts ENV variables and modifies
>> server.xml using their values:
>> https://github.com/AtomGraph/letsencrypt-tomcat
>>
>> I think you should be able to do the same with web.xml.
> 
> I have not seen your solution. But a question comes to mind : does this
> not just move the problem, from tomcat to the Docker container then ?
> 
> Why not provide a (shell ? perl ?) installer/updater script, along with
> the application WAR, which modifies the application's web.xml (or the
> server's web.xml) in function of some site-specific parameter file,
> which is located somewhere outside the tomcat directories and remains
> there ?

What I've done depends on how complex the target environment is.

For simple environments, I do the following:

1. Create a maven deploy job for Jenkins
2. The maven job:
   a. has the base WAR as a dependency
   b. stuff that needs replacing is in the maven job
3. Jenkins supplies environment variables used for replacing
   a. environment variables are set based on target characteristics
   b. all values are recorded in the Jenkins job log

Like I said, this works for simple changes, and obviously not for
Tomcat-related changes. I currently don't keep a copy of the WAR file,
which may lead to some challenges when trying to reproduce a deployment.
However, I've not run into any issues yet.

For more complex environments (where I have to change Tomcat), then I
think a Docker solution is reasonable. I'm currently looking at this
with using Redis as a session manager, and log4j2 for logging.

I can take a standard Tomcat Docker image, and use a Docker file to make
all the alterations. If I drive this from Maven, I can manage the WAR
and other dependencies as well.

Finally, I can take the resulting Docker image (altered Tomcat,
environment-specific WAR file), and push it to a private repository with
some suitable label. Now I have a good / reproducible way to regenerate
my environment - for example, disaster recovery.

Run this entire mess from Jenkins (or your CI/CD tool of choice), and
you get a simple way to deploy applications.

It all depends on the requirements, I guess.

. . . just my two cents.
/mde/

>>
>> Martynas
>>
>> On Fri, 12 Jul 2019 at 21.44, Grigor Aleksanyan
>>  wrote:
>>
>>> Hi Everyone,
>>>
>>> We have been shipping web application with war packaging in our
>>> production
>>> builds which contains a web.xml with few security sections.
>>> This web.xml defines security constraints that are in most cases not
>>> what
>>> the final deployment uses. This means that to update the war we need to
>>> save new web.xml somewhere, copy the new war, run the server so that it
>>> extracts the war, then shut down the server and copy web.xml back.
>>> This is
>>> a headache for our cloud based web services upgrade as well as in all
>>> other
>>> deployment scenarios, including tests.
>>>
>>> To facilitate deployment we've added a new packaging of another war
>>> file,
>>> which is the same as our original war but its web.xml doesn't contain
>>> any
>>> security sections.
>>> With an empty web.xml (in terms of security), the security can be
>>> defined
>>> via server's conf/web.xml, where it belongs, since the security is in
>>> reality defined by the server rather than the war application.
>>> It would be great if we could just replace our default web.xml but if
>>> some
>>> user uses our default web.xml, they would become unsecured after an
>>> upgrade, so we opted for a separate war.
>>>
>>> Do you guys see any other way of achieving what we aim to achieve
>>> with the
>>> new war file with default web.xml (backwards compatibility is a
>>> constraint
>>> in our case)?
>>> Maybe there is a way of ignoring security sections in the war or we can
>>> make it configurable in the code based on some config/env variable?
>>>
>>> Please let me know if you have any considerations about this, any help
>>> would be appreciated.
>>>
>>> Thank you,
>>> -Grigor
>>>
>>> -- 
>>>
>>>
>>> *
>>> *
>>> *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE 

Re: Modify web.xml in production war file

[tomcat]

On 16.07.2019 19:54, Martynas Jusevičius wrote:

Grigor,

I think this is a use case that Docker containers at least partially
address.

I find deploying containers way easier to share/deploy and more
platform-independent than WAR files.

I’ve created a Tomcat-based image that accepts ENV variables and modifies
server.xml using their values:
https://github.com/AtomGraph/letsencrypt-tomcat

I think you should be able to do the same with web.xml.


I have not seen your solution. But a question comes to mind : does this not just move the 
problem, from tomcat to the Docker container then ?


Why not provide a (shell ? perl ?) installer/updater script, along with the application 
WAR, which modifies the application's web.xml (or the server's web.xml) in function of 
some site-specific parameter file, which is located somewhere outside the tomcat 
directories and remains there ?






Martynas

On Fri, 12 Jul 2019 at 21.44, Grigor Aleksanyan
 wrote:


Hi Everyone,

We have been shipping web application with war packaging in our production
builds which contains a web.xml with few security sections.
This web.xml defines security constraints that are in most cases not what
the final deployment uses. This means that to update the war we need to
save new web.xml somewhere, copy the new war, run the server so that it
extracts the war, then shut down the server and copy web.xml back. This is
a headache for our cloud based web services upgrade as well as in all other
deployment scenarios, including tests.

To facilitate deployment we've added a new packaging of another war file,
which is the same as our original war but its web.xml doesn't contain any
security sections.
With an empty web.xml (in terms of security), the security can be defined
via server's conf/web.xml, where it belongs, since the security is in
reality defined by the server rather than the war application.
It would be great if we could just replace our default web.xml but if some
user uses our default web.xml, they would become unsecured after an
upgrade, so we opted for a separate war.

Do you guys see any other way of achieving what we aim to achieve with the
new war file with default web.xml (backwards compatibility is a constraint
in our case)?
Maybe there is a way of ignoring security sections in the war or we can
make it configurable in the code based on some config/env variable?

Please let me know if you have any considerations about this, any help
would be appreciated.

Thank you,
-Grigor

--


*
*
*CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY
CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.  IT
IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED
REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE
INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY E-MAIL
OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS MESSAGE
FROM YOUR SYSTEM.

E-SIGNATURE NOTICE: Unless specifically set forth
herein, the transmission of this communication is not intended to be a
legally binding electronic signature, and no offer, commitment or assent
on
behalf of OneMarketData, LLC is expressed or implied by the sending of
this
email, or any attachments hereto.







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

Re: Modify web.xml in production war file

[Martynas Jusevičius]

Grigor,

I think this is a use case that Docker containers at least partially
address.

I find deploying containers way easier to share/deploy and more
platform-independent than WAR files.

I’ve created a Tomcat-based image that accepts ENV variables and modifies
server.xml using their values:
https://github.com/AtomGraph/letsencrypt-tomcat

I think you should be able to do the same with web.xml.

Martynas

On Fri, 12 Jul 2019 at 21.44, Grigor Aleksanyan
 wrote:

> Hi Everyone,
>
> We have been shipping web application with war packaging in our production
> builds which contains a web.xml with few security sections.
> This web.xml defines security constraints that are in most cases not what
> the final deployment uses. This means that to update the war we need to
> save new web.xml somewhere, copy the new war, run the server so that it
> extracts the war, then shut down the server and copy web.xml back. This is
> a headache for our cloud based web services upgrade as well as in all other
> deployment scenarios, including tests.
>
> To facilitate deployment we've added a new packaging of another war file,
> which is the same as our original war but its web.xml doesn't contain any
> security sections.
> With an empty web.xml (in terms of security), the security can be defined
> via server's conf/web.xml, where it belongs, since the security is in
> reality defined by the server rather than the war application.
> It would be great if we could just replace our default web.xml but if some
> user uses our default web.xml, they would become unsecured after an
> upgrade, so we opted for a separate war.
>
> Do you guys see any other way of achieving what we aim to achieve with the
> new war file with default web.xml (backwards compatibility is a constraint
> in our case)?
> Maybe there is a way of ignoring security sections in the war or we can
> make it configurable in the code based on some config/env variable?
>
> Please let me know if you have any considerations about this, any help
> would be appreciated.
>
> Thank you,
> -Grigor
>
> --
>
>
> *
> *
> *CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY
> CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.  IT
> IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED
> REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE
> INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY E-MAIL
> OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS MESSAGE
> FROM YOUR SYSTEM.
>
> E-SIGNATURE NOTICE: Unless specifically set forth
> herein, the transmission of this communication is not intended to be a
> legally binding electronic signature, and no offer, commitment or assent
> on
> behalf of OneMarketData, LLC is expressed or implied by the sending of
> this
> email, or any attachments hereto.
>
>

Re: Modify web.xml in production war file

[Mark Thomas]

On July 12, 2019 6:43:49 PM UTC, Grigor Aleksanyan 
 wrote:
>Hi Everyone,
>
>We have been shipping web application with war packaging in our
>production
>builds which contains a web.xml with few security sections.
>This web.xml defines security constraints that are in most cases not
>what
>the final deployment uses. This means that to update the war we need to
>save new web.xml somewhere, copy the new war, run the server so that it
>extracts the war, then shut down the server and copy web.xml back. This
>is
>a headache for our cloud based web services upgrade as well as in all
>other
>deployment scenarios, including tests.
>
>To facilitate deployment we've added a new packaging of another war
>file,
>which is the same as our original war but its web.xml doesn't contain
>any
>security sections.
>With an empty web.xml (in terms of security), the security can be
>defined
>via server's conf/web.xml, where it belongs, since the security is in
>reality defined by the server rather than the war application.
>It would be great if we could just replace our default web.xml but if
>some
>user uses our default web.xml, they would become unsecured after an
>upgrade, so we opted for a separate war.
>
>Do you guys see any other way of achieving what we aim to achieve with
>the
>new war file with default web.xml (backwards compatibility is a
>constraint
>in our case)?
>Maybe there is a way of ignoring security sections in the war or we can
>make it configurable in the code based on some config/env variable?
>
>Please let me know if you have any considerations about this, any help
>would be appreciated.
>
>Thank you,
>-Grigor

You might be able to do something with the altDDName attribute of the Context 
element.

Generally, though I think folks build deployment specifically  WARs with the 
'right' configuration.

Mark

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

Modify web.xml in production war file

[Grigor Aleksanyan]

Hi Everyone,

We have been shipping web application with war packaging in our production
builds which contains a web.xml with few security sections.
This web.xml defines security constraints that are in most cases not what
the final deployment uses. This means that to update the war we need to
save new web.xml somewhere, copy the new war, run the server so that it
extracts the war, then shut down the server and copy web.xml back. This is
a headache for our cloud based web services upgrade as well as in all other
deployment scenarios, including tests.

To facilitate deployment we've added a new packaging of another war file,
which is the same as our original war but its web.xml doesn't contain any
security sections.
With an empty web.xml (in terms of security), the security can be defined
via server's conf/web.xml, where it belongs, since the security is in
reality defined by the server rather than the war application.
It would be great if we could just replace our default web.xml but if some
user uses our default web.xml, they would become unsecured after an
upgrade, so we opted for a separate war.

Do you guys see any other way of achieving what we aim to achieve with the
new war file with default web.xml (backwards compatibility is a constraint
in our case)?
Maybe there is a way of ignoring security sections in the war or we can
make it configurable in the code based on some config/env variable?

Please let me know if you have any considerations about this, any help
would be appreciated.

Thank you,
-Grigor

-- 


*
*
*CONFIDENTIALITY NOTE:* THIS E-MAIL MESSAGE AND ANY ATTACHMENTS MAY 
CONTAIN CONFIDENTIAL AND PRIVILEGED INFORMATION OF ONEMARKETDATA, LLC.  IT 
IS FOR THE SOLE USE OF THE INTENDED RECIPIENT(S) AND ANY UNAUTHORIZED 
REVIEW, USE, COPYING OR DISCLOSURE IS PROHIBITED. IF YOU ARE NOT THE 
INTENDED RECIPIENT, PLEASE CONTACT THE SENDER IMMEDIATELY BY REPLY E-MAIL 
OR BY TELEPHONE AT +1 201 710 5977, AND DESTROY ALL COPIES OF THIS MESSAGE 
FROM YOUR SYSTEM.

E-SIGNATURE NOTICE: Unless specifically set forth 
herein, the transmission of this communication is not intended to be a 
legally binding electronic signature, and no offer, commitment or assent on 
behalf of OneMarketData, LLC is expressed or implied by the sending of this 
email, or any attachments hereto.

Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working

[Leonid Rozenblyum]

I see... It's really weird... We'll double check that.

On Fri, Jun 21, 2019 at 7:00 PM Mark Thomas  wrote:

> On 21/06/2019 13:48, Leonid Rozenblyum wrote:
> > Thank you!
>
> I've looked and the behaviour in 8.0.30 appears to be the same. The
> changes I was thinking of were a) much further back and b) unlikely to
> impact distributable.
>
> Mark
>
>
> >
> > On Fri, Jun 21, 2019 at 3:29 PM Mark Thomas  wrote:
> >
> >> On 21/06/2019 12:39, Leonid Rozenblyum wrote:
> >>> Hi Mark!
> >>> Thanks for the explanation.
> >>>
> >>> So now it's mandatory for us to mark every web application
> >> 
> >>> (and also ensure no dependencies in classpath are actual web fragments
> >>> without distributable accidentally)
> >>>
> >>> About our upgrade:
> >>> We've upgraded Tomcat
> >>> Tomcat 8.0.30 -> Tomcat 9.0.16
> >>> (we are planning also the next update to Tomcat 9.0.21 to mitigate a
> >> https
> >>> issue but that's another story)
> >>>
> >>> In 8.0.30 just a  in conf/web.xml has been enabled and
> >>> that caused DeltaManager working (was able to check by catalina logs
> and
> >> by
> >>> JMX manager and by the actual fact that session replication was
> working).
> >>
> >> Interesting. I'll need to go back and check what was going on there.
> >> There were some changes in that area as the Servlet EG clarified the
> >> expected behaviour for "plugability" features. I didn't think anything
> >> changed for distributable but it was a little while ago so I may have
> >> forgotten.
> >>
> >> I'll report back what I find.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas  wrote:
> >>>
> >>>> On 21/06/2019 09:54, Leonid Rozenblyum wrote:
> >>>>> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager
> stopped
> >>>>> initializing.
> >>>>> StandardManager is used instead in cluster environment.
> >>>>
> >>>> Could you be more specific about version numbers please.
> >>>>
> >>>>> our global conf/web.xml contains  as before.
> >>>>
> >>>> That is the default for conf/web.xml so it should not be necessary to
> >>>> set it.
> >>>>
> >>>>> I found a possible workaround: to copy the  tag to
> the
> >>>>> web.xml in the web applications itself.
> >>>>
> >>>> That is expected. Web applications need to be explicitly marked as
> >>>> distributable.
> >>>>
> >>>>> However shouldn't it be inherited from the global conf/web.xml?
> >>>>
> >>>> No. For a web application to be distributable:
> >>>>
> >>>> - WEB-INF/web.xml needs to be marked as distributable
> >>>> - any web-fragment.xml files present in the web app need to be marked
> as
> >>>>   distributable
> >>>>
> >>>> Internally, Tomcat creates additional web-fragment.xml files for JAR
> >>>> files that do not have one. These are marked as distributable by
> default
> >>>> to ensure they don't prevent the web app from being distributable.
> >>>>
> >>>> Internally, the global, host and tomcat specific web.xml files are
> also
> >>>> treated as fragments. They too are marked as distributable by default
> >>>> for the same reason.
> >>>>
> >>>> Tomcat creates these fragments internally as it allows us to re-use
> the
> >>>> web.xml merge code.
> >>>>
> >>>>> Is it a known behavior change?
> >>>>
> >>>> The process has been essentially the same from the early 8.0.x
> releases
> >>>> since that is where web-fragment.xml files were introduced.
> >>>>
> >>>> 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: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working

[Mark Thomas]

On 21/06/2019 13:48, Leonid Rozenblyum wrote:
> Thank you!

I've looked and the behaviour in 8.0.30 appears to be the same. The
changes I was thinking of were a) much further back and b) unlikely to
impact distributable.

Mark


> 
> On Fri, Jun 21, 2019 at 3:29 PM Mark Thomas  wrote:
> 
>> On 21/06/2019 12:39, Leonid Rozenblyum wrote:
>>> Hi Mark!
>>> Thanks for the explanation.
>>>
>>> So now it's mandatory for us to mark every web application
>> 
>>> (and also ensure no dependencies in classpath are actual web fragments
>>> without distributable accidentally)
>>>
>>> About our upgrade:
>>> We've upgraded Tomcat
>>> Tomcat 8.0.30 -> Tomcat 9.0.16
>>> (we are planning also the next update to Tomcat 9.0.21 to mitigate a
>> https
>>> issue but that's another story)
>>>
>>> In 8.0.30 just a  in conf/web.xml has been enabled and
>>> that caused DeltaManager working (was able to check by catalina logs and
>> by
>>> JMX manager and by the actual fact that session replication was working).
>>
>> Interesting. I'll need to go back and check what was going on there.
>> There were some changes in that area as the Servlet EG clarified the
>> expected behaviour for "plugability" features. I didn't think anything
>> changed for distributable but it was a little while ago so I may have
>> forgotten.
>>
>> I'll report back what I find.
>>
>> Mark
>>
>>
>>>
>>> On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas  wrote:
>>>
>>>> On 21/06/2019 09:54, Leonid Rozenblyum wrote:
>>>>> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped
>>>>> initializing.
>>>>> StandardManager is used instead in cluster environment.
>>>>
>>>> Could you be more specific about version numbers please.
>>>>
>>>>> our global conf/web.xml contains  as before.
>>>>
>>>> That is the default for conf/web.xml so it should not be necessary to
>>>> set it.
>>>>
>>>>> I found a possible workaround: to copy the  tag to the
>>>>> web.xml in the web applications itself.
>>>>
>>>> That is expected. Web applications need to be explicitly marked as
>>>> distributable.
>>>>
>>>>> However shouldn't it be inherited from the global conf/web.xml?
>>>>
>>>> No. For a web application to be distributable:
>>>>
>>>> - WEB-INF/web.xml needs to be marked as distributable
>>>> - any web-fragment.xml files present in the web app need to be marked as
>>>>   distributable
>>>>
>>>> Internally, Tomcat creates additional web-fragment.xml files for JAR
>>>> files that do not have one. These are marked as distributable by default
>>>> to ensure they don't prevent the web app from being distributable.
>>>>
>>>> Internally, the global, host and tomcat specific web.xml files are also
>>>> treated as fragments. They too are marked as distributable by default
>>>> for the same reason.
>>>>
>>>> Tomcat creates these fragments internally as it allows us to re-use the
>>>> web.xml merge code.
>>>>
>>>>> Is it a known behavior change?
>>>>
>>>> The process has been essentially the same from the early 8.0.x releases
>>>> since that is where web-fragment.xml files were introduced.
>>>>
>>>> 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: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working

[Leonid Rozenblyum]

Thank you!

On Fri, Jun 21, 2019 at 3:29 PM Mark Thomas  wrote:

> On 21/06/2019 12:39, Leonid Rozenblyum wrote:
> > Hi Mark!
> > Thanks for the explanation.
> >
> > So now it's mandatory for us to mark every web application
> 
> > (and also ensure no dependencies in classpath are actual web fragments
> > without distributable accidentally)
> >
> > About our upgrade:
> > We've upgraded Tomcat
> > Tomcat 8.0.30 -> Tomcat 9.0.16
> > (we are planning also the next update to Tomcat 9.0.21 to mitigate a
> https
> > issue but that's another story)
> >
> > In 8.0.30 just a  in conf/web.xml has been enabled and
> > that caused DeltaManager working (was able to check by catalina logs and
> by
> > JMX manager and by the actual fact that session replication was working).
>
> Interesting. I'll need to go back and check what was going on there.
> There were some changes in that area as the Servlet EG clarified the
> expected behaviour for "plugability" features. I didn't think anything
> changed for distributable but it was a little while ago so I may have
> forgotten.
>
> I'll report back what I find.
>
> Mark
>
>
> >
> > On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas  wrote:
> >
> >> On 21/06/2019 09:54, Leonid Rozenblyum wrote:
> >>> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped
> >>> initializing.
> >>> StandardManager is used instead in cluster environment.
> >>
> >> Could you be more specific about version numbers please.
> >>
> >>> our global conf/web.xml contains  as before.
> >>
> >> That is the default for conf/web.xml so it should not be necessary to
> >> set it.
> >>
> >>> I found a possible workaround: to copy the  tag to the
> >>> web.xml in the web applications itself.
> >>
> >> That is expected. Web applications need to be explicitly marked as
> >> distributable.
> >>
> >>> However shouldn't it be inherited from the global conf/web.xml?
> >>
> >> No. For a web application to be distributable:
> >>
> >> - WEB-INF/web.xml needs to be marked as distributable
> >> - any web-fragment.xml files present in the web app need to be marked as
> >>   distributable
> >>
> >> Internally, Tomcat creates additional web-fragment.xml files for JAR
> >> files that do not have one. These are marked as distributable by default
> >> to ensure they don't prevent the web app from being distributable.
> >>
> >> Internally, the global, host and tomcat specific web.xml files are also
> >> treated as fragments. They too are marked as distributable by default
> >> for the same reason.
> >>
> >> Tomcat creates these fragments internally as it allows us to re-use the
> >> web.xml merge code.
> >>
> >>> Is it a known behavior change?
> >>
> >> The process has been essentially the same from the early 8.0.x releases
> >> since that is where web-fragment.xml files were introduced.
> >>
> >> 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
>
>

Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working

[Mark Thomas]

On 21/06/2019 12:39, Leonid Rozenblyum wrote:
> Hi Mark!
> Thanks for the explanation.
> 
> So now it's mandatory for us to mark every web application 
> (and also ensure no dependencies in classpath are actual web fragments
> without distributable accidentally)
> 
> About our upgrade:
> We've upgraded Tomcat
> Tomcat 8.0.30 -> Tomcat 9.0.16
> (we are planning also the next update to Tomcat 9.0.21 to mitigate a https
> issue but that's another story)
> 
> In 8.0.30 just a  in conf/web.xml has been enabled and
> that caused DeltaManager working (was able to check by catalina logs and by
> JMX manager and by the actual fact that session replication was working).

Interesting. I'll need to go back and check what was going on there.
There were some changes in that area as the Servlet EG clarified the
expected behaviour for "plugability" features. I didn't think anything
changed for distributable but it was a little while ago so I may have
forgotten.

I'll report back what I find.

Mark


> 
> On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas  wrote:
> 
>> On 21/06/2019 09:54, Leonid Rozenblyum wrote:
>>> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped
>>> initializing.
>>> StandardManager is used instead in cluster environment.
>>
>> Could you be more specific about version numbers please.
>>
>>> our global conf/web.xml contains  as before.
>>
>> That is the default for conf/web.xml so it should not be necessary to
>> set it.
>>
>>> I found a possible workaround: to copy the  tag to the
>>> web.xml in the web applications itself.
>>
>> That is expected. Web applications need to be explicitly marked as
>> distributable.
>>
>>> However shouldn't it be inherited from the global conf/web.xml?
>>
>> No. For a web application to be distributable:
>>
>> - WEB-INF/web.xml needs to be marked as distributable
>> - any web-fragment.xml files present in the web app need to be marked as
>>   distributable
>>
>> Internally, Tomcat creates additional web-fragment.xml files for JAR
>> files that do not have one. These are marked as distributable by default
>> to ensure they don't prevent the web app from being distributable.
>>
>> Internally, the global, host and tomcat specific web.xml files are also
>> treated as fragments. They too are marked as distributable by default
>> for the same reason.
>>
>> Tomcat creates these fragments internally as it allows us to re-use the
>> web.xml merge code.
>>
>>> Is it a known behavior change?
>>
>> The process has been essentially the same from the early 8.0.x releases
>> since that is where web-fragment.xml files were introduced.
>>
>> 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

Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working

[Leonid Rozenblyum]

Hi Mark!
Thanks for the explanation.

So now it's mandatory for us to mark every web application 
(and also ensure no dependencies in classpath are actual web fragments
without distributable accidentally)

About our upgrade:
We've upgraded Tomcat
Tomcat 8.0.30 -> Tomcat 9.0.16
(we are planning also the next update to Tomcat 9.0.21 to mitigate a https
issue but that's another story)

In 8.0.30 just a  in conf/web.xml has been enabled and
that caused DeltaManager working (was able to check by catalina logs and by
JMX manager and by the actual fact that session replication was working).

On Fri, Jun 21, 2019 at 12:29 PM Mark Thomas  wrote:

> On 21/06/2019 09:54, Leonid Rozenblyum wrote:
> > Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped
> > initializing.
> > StandardManager is used instead in cluster environment.
>
> Could you be more specific about version numbers please.
>
> > our global conf/web.xml contains  as before.
>
> That is the default for conf/web.xml so it should not be necessary to
> set it.
>
> > I found a possible workaround: to copy the  tag to the
> > web.xml in the web applications itself.
>
> That is expected. Web applications need to be explicitly marked as
> distributable.
>
> > However shouldn't it be inherited from the global conf/web.xml?
>
> No. For a web application to be distributable:
>
> - WEB-INF/web.xml needs to be marked as distributable
> - any web-fragment.xml files present in the web app need to be marked as
>   distributable
>
> Internally, Tomcat creates additional web-fragment.xml files for JAR
> files that do not have one. These are marked as distributable by default
> to ensure they don't prevent the web app from being distributable.
>
> Internally, the global, host and tomcat specific web.xml files are also
> treated as fragments. They too are marked as distributable by default
> for the same reason.
>
> Tomcat creates these fragments internally as it allows us to re-use the
> web.xml merge code.
>
> > Is it a known behavior change?
>
> The process has been essentially the same from the early 8.0.x releases
> since that is where web-fragment.xml files were introduced.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working

[Mark Thomas]

On 21/06/2019 09:54, Leonid Rozenblyum wrote:
> Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped
> initializing.
> StandardManager is used instead in cluster environment.

Could you be more specific about version numbers please.

> our global conf/web.xml contains  as before.

That is the default for conf/web.xml so it should not be necessary to
set it.

> I found a possible workaround: to copy the  tag to the
> web.xml in the web applications itself.

That is expected. Web applications need to be explicitly marked as
distributable.

> However shouldn't it be inherited from the global conf/web.xml?

No. For a web application to be distributable:

- WEB-INF/web.xml needs to be marked as distributable
- any web-fragment.xml files present in the web app need to be marked as
  distributable

Internally, Tomcat creates additional web-fragment.xml files for JAR
files that do not have one. These are marked as distributable by default
to ensure they don't prevent the web app from being distributable.

Internally, the global, host and tomcat specific web.xml files are also
treated as fragments. They too are marked as distributable by default
for the same reason.

Tomcat creates these fragments internally as it allows us to re-use the
web.xml merge code.

> Is it a known behavior change?

The process has been essentially the same from the early 8.0.x releases
since that is where web-fragment.xml files were introduced.

Mark

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

Tomcat 9 distributable tag from global conf/web.xml and DeltaManager not working

[Leonid Rozenblyum]

Hello. After recent Tomcat upgrade from 8.0 to 9.0 DeltaManager stopped
initializing.
StandardManager is used instead in cluster environment.

our global conf/web.xml contains  as before.

I found a possible workaround: to copy the  tag to the
web.xml in the web applications itself.

However shouldn't it be inherited from the global conf/web.xml?
Is it a known behavior change?

Re: web.xml mime-mappings

[Luis Rodríguez Fernández]

Hello Baron,

There are no dumb questions, no worries :)

Are you referring to the $CATALINA_BASE/conf/web.xml by chance? This is the
default web.xml [1] that defines default values for all the webapps
deployed in your tomcat server. Me personally I rarely modify it.

 Me, as a sample web.xml I usually take either the one distributed in the
always good $CATALINA_BASE/webapps/examples/WEB-INF/web.xml or the one from
the classic "hello, world" app [2]

Hope it helps,

Luis

[1] https://tomcat.apache.org/tomcat-9.0-doc/default-servlet.html
[2] https://tomcat.apache.org/tomcat-9.0-doc/appdev/sample/






El jue., 1 nov. 2018 a las 3:01, Baron Fujimoto ()
escribió:

> Apologies in advance if this is a dumb question.
>
> I usually base our config files off of the sample config files as a
> starting point.
>
> The sample web.xml contains many mime-mapping elements (1000+ I think). Is
> there any good reason to include these if your application isn't going to
> use the vast majority of these mime-types? I.e., is it recommended to edit
> it down to just those that the application is likely to use? It seems like
> it would be less unwieldy if I did this, but I just want to make sure
> there's no compelling downside to it.
>
> --
> Baron Fujimoto  :: UH Information Technology Services
> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

web.xml mime-mappings

[Baron Fujimoto]

Apologies in advance if this is a dumb question.

I usually base our config files off of the sample config files as a starting 
point.

The sample web.xml contains many mime-mapping elements (1000+ I think). Is 
there any good reason to include these if your application isn't going to use 
the vast majority of these mime-types? I.e., is it recommended to edit it down 
to just those that the application is likely to use? It seems like it would be 
less unwieldy if I did this, but I just want to make sure there's no compelling 
downside to it.

-- 
Baron Fujimoto  :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

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

Re: cors filter in WEB-INF/web.xml

[Luis Rodríguez Fernández]

Hello Masber,

In order to get accurate answers it would be helpful if you could provide
details like:

- Platform details: OS, jdk/jre, apache-tomcat version...
- "I went through documentation" which one? perhaps
https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter
- "my web client still complains" I guess that you get some error response
here; have you checked your logs?

Hope it helps,

Luis





2018-07-28 9:00 GMT+02:00 masber masber :

> Dear Apache Tomcat community,
>
>
> I am learning Tomcat and would like to create a crosfilter, I went through
> the documentation and added the code suggested but my web client still
> complains.
>
>
> This is the content of my web.xml file:
>
>
> 
>
> Archetype Created Web Application
>
>
> 
>
> jersey-servlet
>
> org.glassfish.jersey.servlet.
> ServletContainer
>
>
> 
>
> jersey.config.server.provider.packages param-name>
>
> returnitRest
>
> 
>
>
> 
>
> jersey.config.server.provider.classnames param-name>
>
> org.glassfish.jersey.media.multipart.
> MultiPartFeature
>
> 
>
>
> 
>
> javax.ws.rs.Application
>
> returnitRest.AppConfig
>
> 
>
>
> 1
>
> 
>
>
> 
>
> jersey-servlet
>
> /rest/*
>
> 
>
>
> 
>
>   CorsFilter
>
>   org.apache.catalina.filters.CorsFilter
>
>   
>
> cors.allowed.origins
>
> *
>
>   
>
>   
>
> cors.allowed.methods
>
> GET,POST,HEAD,OPTIONS,PUT
>
>   
>
>   
>
> cors.allowed.headers
>
> Content-Type,X-Requested-With,accept,Origin,
> Access-Control-Request-Method,Access-Control-Request-Headers
>
>   
>
>   
>
> cors.exposed.headers
>
> Access-Control-Allow-Origin,Access-Control-
> Allow-Credentials
>
>   
>
>   
>
> cors.support.credentials
>
> true
>
>   
>
>   
>
> cors.preflight.maxage
>
> 10
>
>   
>
> 
>
> 
>
>   CorsFilter
>
>   /*
>
> 
>
> 
>
>
> I was wondering whether someone could help me to understand what I am
> doing wrong?
>
>
> thank you very much
>
>


-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

cors filter in WEB-INF/web.xml

[masber masber]

Dear Apache Tomcat community,


I am learning Tomcat and would like to create a crosfilter, I went through the 
documentation and added the code suggested but my web client still complains.


This is the content of my web.xml file:




Archetype Created Web Application




jersey-servlet


org.glassfish.jersey.servlet.ServletContainer




jersey.config.server.provider.packages

returnitRest






jersey.config.server.provider.classnames


org.glassfish.jersey.media.multipart.MultiPartFeature






javax.ws.rs.Application

returnitRest.AppConfig




1






jersey-servlet

/rest/*






  CorsFilter

  org.apache.catalina.filters.CorsFilter

  

cors.allowed.origins

*

  

  

cors.allowed.methods

GET,POST,HEAD,OPTIONS,PUT

  

  

cors.allowed.headers


Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers

  

  

cors.exposed.headers


Access-Control-Allow-Origin,Access-Control-Allow-Credentials

  

  

cors.support.credentials

true

  

  

cors.preflight.maxage

10

  





  CorsFilter

  /*






I was wondering whether someone could help me to understand what I am doing 
wrong?


thank you very much

Re: SPENGO config in Tomcat's web.xml

[Mark Thomas]

On 08/06/18 17:26, Randy Oun wrote:
> Hello Tomcat user group.
> 
> I am setting update Tomcat 8.5.23 with Kerberos/SPNEGO.  Since the Tomcat
> server will be only hosting one web application and we only want SPNEGO
> only on certain environments we were trying to add security contraints to
> Tomcat's web.xml instead of the application's web.xml.
> 
> Unfortunately it doesn't seem like it is taking effect.  The only change is
> is adding the app's URI context to the url-pattern in Tomcat's web.xml.
> 
> Is something misconfigured?

Yes.

The global web.xml is merged into the application web.xml for every web
application.

You want to use exactly the same URLs (no leading "/app") in the global
web.xml as you do in the application web.xml.

As an aside, configuring application specific settings in the global
web.xml is not recommended. If you ever need to deploy a second web
application you are going to have difficulties.

Mark



>  If not, what can I do to get this to work?
> 
> In TOMCAT_HOME/conf/web.xml...
> -
> 
> 
>   
> NoSSO
> URIs that should not trigger
> SPNEGO
> /app/ping
>  /app/ws/*
>  /app/service/*
>   
> 
>   
>   
> 
>   SSO
>   Default context path that will trigger
> Kerberos-SPNEGO SSO
>   /app/*
> 
> 
>   **
> 
>   
>   
> SPNEGO
> SPNEGO Realm
>   
> 
> In app web.xml...
> ---
> 
> 
>   
> NoSSO
> URIs that should not trigger
> SPNEGO
> /ping
>  /ws/*
>  /service/*
>   
> 
>   
>   
> 
>   SSO
>   Default context path that will trigger
> Kerberos-SPNEGO SSO
>   /*
> 
> 
>   **
> 
>   
>   
> SPNEGO
> SPNEGO Realm
>   
> 
> Thanks!
> 
> Randy
> 


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

SPENGO config in Tomcat's web.xml

[Randy Oun]

Hello Tomcat user group.

I am setting update Tomcat 8.5.23 with Kerberos/SPNEGO.  Since the Tomcat
server will be only hosting one web application and we only want SPNEGO
only on certain environments we were trying to add security contraints to
Tomcat's web.xml instead of the application's web.xml.

Unfortunately it doesn't seem like it is taking effect.  The only change is
is adding the app's URI context to the url-pattern in Tomcat's web.xml.

Is something misconfigured?  If not, what can I do to get this to work?

In TOMCAT_HOME/conf/web.xml...
-


  
NoSSO
URIs that should not trigger
SPNEGO
/app/ping
 /app/ws/*
 /app/service/*
  

  
  

  SSO
  Default context path that will trigger
Kerberos-SPNEGO SSO
  /app/*


  **

  
  
SPNEGO
SPNEGO Realm
  

In app web.xml...
---


  
NoSSO
URIs that should not trigger
SPNEGO
/ping
 /ws/*
 /service/*
  

  
  

  SSO
  Default context path that will trigger
Kerberos-SPNEGO SSO
  /*


  **

  
  
SPNEGO
SPNEGO Realm
  

Thanks!

Randy

Re: Deleting web.xml on tomcat exit

[Olaf Kock]

On 06.06.2018 21:36, Mark Thomas wrote:

On 06/06/18 20:30, Jan Tosovsky wrote:

Dear All,

I use tomcat as a Liferay portal engine. It is usually stopped in two steps.
There is Shutdown button available in Liferay Control panel, which stops the
webapp. Once this is finished, it is safe to stop tomcat via the standard
shutdown script.

If tomcat is stopped differently:
* tomcat is shutdown without shutting down the Liferay
* java crashes (out of memory)
* tomcat is killed
* OS is rebooted (driven by server hosting)

it sometimes (not always) deletes some web content, usually JSP pages, to my
experience especially of the ROOT app (in case of Liferay the default Tomcat
ROOT app is replaced with the core Liferay app).

After the last incident even the core config file ROOT/WEB-INF/web.xml was
missing. And without it tomcat was not able to launch the portal properly.

When you know what has happened it is 'easy' to fix.

But I am quite curious why anything is even deleted in such 'crash'
scenarios.

I met this in various tomcat versions, let say 7.0.xx- 8.0.xx running on
Oracle JDK 7-8 on both Windows 7-10 and CentOS 6-7.

Any idea why this happen?

There is no way I can think of that Tomcat would do this. I'd suggest
two things:
1. Talk to Liferay support
2. Change the file permissions


Indeed - I'd also recommend to bring this to the Liferay forums (or 
Liferay support, if you have a support (Enterprise) contract). I've 
never heard such behavior from Liferay, and shutdown in two steps is not 
typically necessary.


In case your shutdown processes run out of memory, it might be as simple 
as allocating a bit more memory, or to validate your custom plugins for 
their memory requirements during shutdown. I'm not aware that Liferay 
uses excessive memory during shutdown.


To add a few more pointers to look at: If you're on a 6.x version of 
Liferay, there's the possibility to deploy hooks that physically 
overwrite JSPs. These might get undeployed and redeployed, but there are 
some caveats to pay attention to - specifically to only overwrite a 
single JSP from a single hook. Technically, you'd be able to overwrite 
Liferay's web.xml from such a hook, but this is utterly useless and 
shouldn't be done. Only in case you're doing this, I could imagine a 
case where web.xml disappears.


But, Mark's recommendation is solid: Check the Liferay forums, this 
doesn't look like a tomcat issue. Send me the link to the forum post and 
I'll take a look at it there.


Olaf


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

Re: Deleting web.xml on tomcat exit

[Mark Thomas]

On 06/06/18 20:30, Jan Tosovsky wrote:
> Dear All,
> 
> I use tomcat as a Liferay portal engine. It is usually stopped in two steps.
> There is Shutdown button available in Liferay Control panel, which stops the
> webapp. Once this is finished, it is safe to stop tomcat via the standard
> shutdown script.
> 
> If tomcat is stopped differently:
> * tomcat is shutdown without shutting down the Liferay
> * java crashes (out of memory)
> * tomcat is killed
> * OS is rebooted (driven by server hosting)
> 
> it sometimes (not always) deletes some web content, usually JSP pages, to my
> experience especially of the ROOT app (in case of Liferay the default Tomcat
> ROOT app is replaced with the core Liferay app).
> 
> After the last incident even the core config file ROOT/WEB-INF/web.xml was
> missing. And without it tomcat was not able to launch the portal properly.
> 
> When you know what has happened it is 'easy' to fix.
> 
> But I am quite curious why anything is even deleted in such 'crash'
> scenarios. 
> 
> I met this in various tomcat versions, let say 7.0.xx- 8.0.xx running on
> Oracle JDK 7-8 on both Windows 7-10 and CentOS 6-7.
> 
> Any idea why this happen?

There is no way I can think of that Tomcat would do this. I'd suggest
two things:
1. Talk to Liferay support
2. Change the file permissions

Mark

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

Deleting web.xml on tomcat exit

[Jan Tosovsky]

Dear All,

I use tomcat as a Liferay portal engine. It is usually stopped in two steps.
There is Shutdown button available in Liferay Control panel, which stops the
webapp. Once this is finished, it is safe to stop tomcat via the standard
shutdown script.

If tomcat is stopped differently:
* tomcat is shutdown without shutting down the Liferay
* java crashes (out of memory)
* tomcat is killed
* OS is rebooted (driven by server hosting)

it sometimes (not always) deletes some web content, usually JSP pages, to my
experience especially of the ROOT app (in case of Liferay the default Tomcat
ROOT app is replaced with the core Liferay app).

After the last incident even the core config file ROOT/WEB-INF/web.xml was
missing. And without it tomcat was not able to launch the portal properly.

When you know what has happened it is 'easy' to fix.

But I am quite curious why anything is even deleted in such 'crash'
scenarios. 

I met this in various tomcat versions, let say 7.0.xx- 8.0.xx running on
Oracle JDK 7-8 on both Windows 7-10 and CentOS 6-7.

Any idea why this happen?

Thanks,

Jan


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

Re: Modify JspServlet config in application web.xml?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Richárd,

On 1/27/18 7:18 AM, Richárd Olivér Legéndi wrote:
> Thanks a lot, Christopher and Mark!
> 
> Wow, lot of knowledge and pointers to move forward. I've debugged a
> bit around both ContextConfig and JspServlet, and it is exactly as
> you described. This saves a hell lot of work for me and helps avoid
> some stressful meetings :D
> 
> Thanks a lot! Also for the reference of the Servlet spec, I think
> it's time to go through it.

It's one of the most readable spec documents I've ever read. Well
worth the read for anyone who will be doing anything web-related with
Java EE.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpt/SwACgkQHPApP6U8
pFh8mRAAgvJLHaZmWe6640lbYHiKrkzW8pr9SF3F/JLZI1VsSJGQYJLqSfHeWETs
BCjyKibw/9x/iIq9WbLUA5W1liUMnp0o0kvj7U+zbYrTmqqpcfy8aoFstbfjVrVz
mdrloK0qgtrFjGyx0Z8aWOnuDd5DvNJPDv0GVPia50+zX3xWD63/w7RuqVqeoKOM
GF3q2G1AZ1COagnPMdYf6T/vMFVoS5YnllSowDYPbxEUt8bvqdXjllbDKZhTrgON
CUDaqIsfyCRcw5MpSh0tfkktC0SSL3iVsj0GGU8XNb2akDpu4Cd8k1GLyeLZfqJm
G9WFVU1ckiGlyDcnGOGKQtinMKLmf2EwwlK84pc2q7y7DCzWn18Vq0HiKBRA4sNf
yQJtLHsumhhIyl05Pv1WHnmlJiqUYoD8i9JX8RmVFjV79q2j7jVvBDa9Rpkblgxz
DwTkPkOY77h0JL7+VmjKkTG+NF8Xua9w6Fbq1Hf6P2ufxnm44xA9zB8kpPvVyLcC
dJZ6QTvAfUkw7eA6y2X+ixxZ4RGWlLxSNC/X7aySiMVuS++IhDieAA5TRkbwZC1v
OwayUOWFjtqSAdP50t3xMJwanv2bH55PD6wSoh+vLsPYZyfdMeqj4YCIcPgTHQbD
sGpnZZ3/P6Pz/Yj5V6zAtJrYIg2rUQ0oV2rR8CTH2zdmbzq7FXs=
=S0xs
-END PGP SIGNATURE-

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

Re: Modify JspServlet config in application web.xml?

[Richárd Olivér Legéndi]

Thanks a lot, Christopher and Mark!

Wow, lot of knowledge and pointers to move forward. I've debugged a bit
around both ContextConfig and JspServlet, and it is exactly as you
described. This saves a hell lot of work for me and helps avoid some
stressful meetings :D

Thanks a lot! Also for the reference of the Servlet spec, I think it's time
to go through it.

Have a nice weekend, guys!

Best,
Richard


On 25 January 2018 at 11:33, Mark Thomas <ma...@apache.org> wrote:

> On 25/01/18 05:25, Christopher Schultz wrote:
>
> 
>
> > You can also use  in WEB-INF/web.xml for the JSP servlet.
> > You will probably have to copy those settings you want from the JSP
> > configuration in conf/web.xml because I don't think Tomcat will merge
> > init-param between the two files.
>
> Tomcat should merge the init-param entries. The rules for merging the
> default web.xml file are as follows.
>
> 1. Web fragments, annotations etc. are merged into the main web.xml as
> per the Servlet spec merge rules to created an updated main web.xml.
>
> 2. The default web.xml is them merged into the updated main web.xml as
> if the default web.xml was a web fragment again following the Servlet
> spec rules with one exception. If there is a conflict, rather than
> triggering an error, the updated main web.xml always takes precedence.
>
> The code that does this is in ContextConfig and WebXml.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Modify JspServlet config in application web.xml?

[Mark Thomas]

On 25/01/18 05:25, Christopher Schultz wrote:



> You can also use  in WEB-INF/web.xml for the JSP servlet.
> You will probably have to copy those settings you want from the JSP
> configuration in conf/web.xml because I don't think Tomcat will merge
> init-param between the two files.

Tomcat should merge the init-param entries. The rules for merging the
default web.xml file are as follows.

1. Web fragments, annotations etc. are merged into the main web.xml as
per the Servlet spec merge rules to created an updated main web.xml.

2. The default web.xml is them merged into the updated main web.xml as
if the default web.xml was a web fragment again following the Servlet
spec rules with one exception. If there is a conflict, rather than
triggering an error, the updated main web.xml always takes precedence.

The code that does this is in ContextConfig and WebXml.

Mark

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

Re: Modify JspServlet config in application web.xml?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Richárd,

On 1/24/18 4:31 PM, Richárd Olivér Legéndi wrote:
> Yy! I'm sending a tech mail to an open source community after
> years! You can't believe what a relief it is :-)

Welcome to the community!

> Anyway, I would like to ask your help about some config topic.
> 
> I would need the following configuration *only *for my webapp:
> 
>  jsp 
> org.apache.jasper.servlet.JspServlet
>
> 

> mappedfile 
> false   
> trimSpaces 
> true  
> 3
> 
> So far I thought this is a setting which is global for Tomcat
> (i.e., it can only be configured in Tomcat's *web.xml*). This is
> something I am not allowed to do, because the Tomcat has other apps
> too.
> 
> I have made some experiments and for me it seems when I run the app
> locally on my developer machine these settings take place even when
> it is only in the *web.xml* of my own application.
> 
> Could someone enlighten me what is the exact mechanism here?

When Tomcat deploys your context ("webapp"), it merges the global
conf/web.xml and the application's WEB-INF/web.xml with the
application's configuration overriding anything in the global
configuration. Therefore, if you replace the "jsp" servlet
configuration in WEB-INF/web.xml, it will (a) work and (b) only affect
that single application.

> The docs <http://www2.hu-berlin.de/newlogic/docs/jasper-howto.html>
> also say *"The servlet which implements Jasper is configured using
> init parameters in your global $CATALINA_BASE/conf/web.xml"* so I'm
> confused if this is an expected behaviour, only a "developer
> setting" or it could work in a more restrictive production
> environment too. What I can think of is that the servlet generator
> has different contexts for all the applications, and if there is no
> specific setting then it inherits the one defined in the global
> *web.xml*.

You can also use  in WEB-INF/web.xml for the JSP servlet.
You will probably have to copy those settings you want from the JSP
configuration in conf/web.xml because I don't think Tomcat will merge
init-param between the two files.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlppajUACgkQHPApP6U8
pFjeyw//Zg07qWt1IJV9i2UvEJqkd7fcWXo/1XMwIvJPKXSBYU6r4HzSw5o8O2WQ
SNDpFhGE08YLTVQ86h8rQk9CgT1xLbuFcJixuxC/CoLB4MfiECpVZJyDukilt9j6
JUgGOEAmxmqetkb9y/5dkUe34KxjNC1nTx3MQTSCw3vCk2W4JL8WT1w/XU1XOGtB
mgtZm8eu5WQU1baUkUN5du35TxnpXSJ51PnI9XWEhto3gZ0PvPNKSnqYK1OMJPn7
FBGDrTv050+OocIDC4TPyh+V0zt3f67zvyYk4SIwDXE++9dJ0UYtjnS2zzlerAug
F5PUhbWYBdMUivirGP8wZ3cfRGxzvXRnZA29+u6e57PaCTBeec2C/oc8pyuBSlkD
dQVgc9/MdrVm+I1ukfYwiuQwD7NEUNAPe83e/lQerpJQ5MwWlMtH9EI0Tdo1c6AC
JwYgDRICvDhdBhJS6JrbrsmAbT3TAgHxoCTduktFHKsqPj5Ujc+9+4C9sU9PB1Ch
3/CoXT1H0pEZkxeCOK6C+J7pIOvO5tPOmu1z9BpVc80q9YXkjrJCGLWAhj82iCrA
KoKHhPQpp4AoviUBO+Gi/cBh18OOLeyIb4UIza+lec64OERerIgHqZo7HX4Z/cT5
LbG1mquwAdpIzjIWCYvoTRgsepZCwu0WgV2xYcP6YvP4/6NJ+Dg=
=uEFM
-END PGP SIGNATURE-

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

Modify JspServlet config in application web.xml?

[Richárd Olivér Legéndi]

Hi All,

Yy! I'm sending a tech mail to an open source community after years!
You can't believe what a relief it is :-)

Anyaway, I would like to ask your help about some config topic.

I would need the following configuration *only *for my webapp:


jsp
org.apache.jasper.servlet.JspServlet

mappedfile
false


trimSpaces
true

3

So far I thought this is a setting which is global for Tomcat (i.e., it can
only be configured in Tomcat's *web.xml*). This is something I am not
allowed to do, beceause the Tomcat has other apps too.

I have made some experiments and for me it seems when I run the app locally
on my developer machine these settings take place even when it is only in
the *web.xml* of my own application.

Could someone enlighten me what is the exact mechanism here?

The docs <http://www2.hu-berlin.de/newlogic/docs/jasper-howto.html> also
say *"The servlet which implements Jasper is configured using init
parameters in your global $CATALINA_BASE/conf/web.xml"* so I'm confused if
this is an expected behaviour, only a "developer setting" or it could work
in a more restrictive production environment too. What I can think of is
that the servlet generator has different contexts for all the applications,
and if there is no specific setting then it inherits the one defined in the
global *web.xml*.

Any links / pointers / suggestions would be more than welcome!

Thanks a lot in advance, guys!

Best,
Richard

Re: Tomcat keeps changing my web.xml listener-class

[Blake McBride]

Never mind.  Found the problem.  It wasn't tomcat, it was me.

Thanks!

Blake


On Sun, Oct 15, 2017 at 3:19 PM, Blake McBride <blake1...@gmail.com> wrote:

> Hi,
>
> I am running tomcat 8.5.16 with 64 bit Oracle Java 8.0.144 on a LinuxMint
> box.  My Java REST app worked fine until I renamed my packages.  So, for
> example, my startup listener was in a package named:
>
> com.abc.utils.StartupListner
>
> webapps/myapp/WEB-INF/web.xml reflected that with:
>
> com.abc.utils.StartupListener
>
> and it all worked.  I change all my classes and I changed
> webapps/myapp/WEB-INF/web.xml to:
>
> io.def.utils.StartupListener
>
> However, whenever I startup tomcat my something is changing
> webapps/myapp/WEB-INF/web.xml back to:
>
> com.abc.utils.StartupListener
>
> I updated webapps/myapp/WEB-INF/web.xml back to:
>
> io.def.utils.StartupListener
>
> and then searched everything in the tomcat tree for "com.abc" but it
> didn't exist anywhere.  However, when I run tomcat again, it again changes
> webapps/myapp/WEB-INF/web.xml back to:
>
> com.abc.utils.StartupListener
>
> My app is not being distributed as a war file.  I have it all extracted
> under the webapps directory.
>
> I can't figure out what is causing tomcat to remember the old package
> path.  Sure appreciate any help.
>
> Thanks!
>
> Blake McBride
>
>
>
>

Tomcat keeps changing my web.xml listener-class

[Blake McBride]

Hi,

I am running tomcat 8.5.16 with 64 bit Oracle Java 8.0.144 on a LinuxMint
box.  My Java REST app worked fine until I renamed my packages.  So, for
example, my startup listener was in a package named:

com.abc.utils.StartupListner

webapps/myapp/WEB-INF/web.xml reflected that with:

com.abc.utils.StartupListener

and it all worked.  I change all my classes and I changed
webapps/myapp/WEB-INF/web.xml to:

io.def.utils.StartupListener

However, whenever I startup tomcat my something is changing
webapps/myapp/WEB-INF/web.xml back to:

com.abc.utils.StartupListener

I updated webapps/myapp/WEB-INF/web.xml back to:

io.def.utils.StartupListener

and then searched everything in the tomcat tree for "com.abc" but it didn't
exist anywhere.  However, when I run tomcat again, it again changes
webapps/myapp/WEB-INF/web.xml back to:

com.abc.utils.StartupListener

My app is not being distributed as a war file.  I have it all extracted
under the webapps directory.

I can't figure out what is causing tomcat to remember the old package
path.  Sure appreciate any help.

Thanks!

Blake McBride

Re: web.xml

[Guang Chao]

On Wed, Sep 6, 2017 at 6:16 AM, Alejandro Vargas M. <
alejandro.var...@kymsolutions.com> wrote:

> Good afternoon,
>
> I have a website on a client, and they ran a vulnerability test, and it
> throws a vulnerability that any user can see web.xml from a web browser,
>
> how can I hide to see web.xml or any other file from the browser?
>

Do you have a reverse proxy or a webserver directly serving static files?


>
> Thanks.
>
>
> --
>
>
>
>
> Alejandro Vargas Mayorga
> *Gerente Desarrollo C.A. & C.*
> *Tel. 506- 7232-3366*
> *Email:**alejandro.var...@kymsolutions.com*
> <%20alejandro.var...@kymsolutions.com>
> *www.kymsolutions.com* <http://www.kymsolutions.com/>
> * Visite nuestra aula virtual! *
>



-- 
Guang <http://javadevnotes.com/java-string-to-float-examples/>

Re: web.xml

[M. Manna]

Is a GET/POST call you are using to get the xml content? Have you
reproduced this yourself. Or is it from that security report?



On 5 Sep 2017 23:17, "Alejandro Vargas M." <
alejandro.var...@kymsolutions.com> wrote:

Good afternoon,

I have a website on a client, and they ran a vulnerability test, and it
throws a vulnerability that any user can see web.xml from a web browser,

how can I hide to see web.xml or any other file from the browser?


Thanks.


-- 




Alejandro Vargas Mayorga
*Gerente Desarrollo C.A. & C.*
*Tel. 506- 7232-3366*
*Email:**alejandro.var...@kymsolutions.com*
<%20alejandro.var...@kymsolutions.com>
*www.kymsolutions.com* <http://www.kymsolutions.com/>
* Visite nuestra aula virtual! *

Re: web.xml

[tomcat]

On 06.09.2017 00:16, Alejandro Vargas M. wrote:

Good afternoon,

I have a website on a client, and they ran a vulnerability test, and it throws a
vulnerability that any user can see web.xml from a web browser,

how can I hide to see web.xml or any other file from the browser?


1) if web.xml is inside the webapp/WEB-INF/ subdirectory, then tomcat will *never* allow a 
browser to see it.
2) if this tomcat is (logically) behind a front-end webserver, then make sure that it is 
not this front-end webserver which allows the client browser to see this file






Thanks.


--




Alejandro Vargas Mayorga
/*Gerente Desarrollo C.A. & C.*/
*Tel. 506- 7232-3366*
*Email:**alejandro.var...@kymsolutions.com* 
<mailto:%20alejandro.var...@kymsolutions.com>*
**www.kymsolutions.com* <http://www.kymsolutions.com/>*
Visite nuestra aula virtual! *




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

web.xml

[Alejandro Vargas M.]

Good afternoon,

I have a website on a client, and they ran a vulnerability test, and it 
throws a vulnerability that any user can see web.xml from a web browser,


how can I hide to see web.xml or any other file from the browser?


Thanks.


--




Alejandro Vargas Mayorga
/*Gerente Desarrollo C.A. & C.*/
*Tel. 506- 7232-3366*
*Email:**alejandro.var...@kymsolutions.com* 
<mailto:%20alejandro.var...@kymsolutions.com>*

**www.kymsolutions.com* <http://www.kymsolutions.com/>*
Visite nuestra aula virtual! *

RE: When do I actually need to add JNDI references to web.xml?

[KARR, DAVID]

> -Original Message-
> From: KARR, DAVID
> Sent: Tuesday, March 14, 2017 1:20 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: When do I actually need to add JNDI references to web.xml?
> 
> I have a small CXF/REST/Spring/JDBC app that I've run on TomEE and
> Tomcat.  I define datasources and environment entries and retrieve those
> from the application code using JNDI interfaces.  This all works fine.
> 
> What confuses me is that whenever I read in various unrelated docs about
> setting and using JNDI entries, even in applications running in Tomcat,
> it says that I also have to put resource reference elements into my
> application's "web.xml" file.  I don't think I've EVER added those
> elements to a web.xml file, and I've defined and used JNDI resources in
> many applications, including the current one.
> 
> As I'm getting these resources through Spring, does that somehow make it
> unnecessary to add those elements?
> 
> When are they actually required?

I suppose I can self-answer this somewhat, but I'd still appreciate another POV.

>From what I understand, I can see two reasons why the resource reference might 
>be required:
* If the application code needs to reference it with a different name than is 
in JNDI
* If an application framework needs to inspect the configuration model of an 
application, to see those declared references, to perform background 
infrastructure actions associated with those references

The first is pretty obvious, but I just read about a large framework that looks 
for these declared references to perform automated actions.

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

When do I actually need to add JNDI references to web.xml?

[KARR, DAVID]

I have a small CXF/REST/Spring/JDBC app that I've run on TomEE and Tomcat.  I 
define datasources and environment entries and retrieve those from the 
application code using JNDI interfaces.  This all works fine.

What confuses me is that whenever I read in various unrelated docs about 
setting and using JNDI entries, even in applications running in Tomcat, it says 
that I also have to put resource reference elements into my application's 
"web.xml" file.  I don't think I've EVER added those elements to a web.xml 
file, and I've defined and used JNDI resources in many applications, including 
the current one.

As I'm getting these resources through Spring, does that somehow make it 
unnecessary to add those elements?

When are they actually required?

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

Re: web.xml and @WebServlet priority when more rules match

[Mark Thomas]

On 12/10/2016 08:02, Mladen Adamović wrote:
> Lets assume that web.xml has a rule
> 
> 
> One
> /something/e*
> 
> 
> While class Two.class has an annotation:
> 
> @WebServlet(name = "Two", urlPatterns = {"/something/er*"})
> 
> From the Servlet 3.0 specification
> 
> 8.2.3. (point 4). `The web.xml of the web application has the highest
> precedence when resolving conflicts between the web.xml, web-fragment.xml
> and annotations.`

Note that the order of precedence is:
web.xml -> web-fragment.xml -> annotations

> While 12.2 states: The container will recursively try to match the longest
> path-prefix. This is done by stepping down the path tree a directory at a
> time, using the ’/’ character as a path separator. The longest match
> determines the servlet selected.
> 
> So for the request /something/error Tomcat will choose Two.class?

No. Neither will match. Prefix matches have to end with "/*". The two
mappings above are exact matches.

> And more general, in the case there are both annotation and web.xml rule
> with the same prefix length, it will choose a first occurrence in web.xml?

The mapping from web.xml will be used.

If there are two mappings in web.xml with identical URL patterns then an
error will occur.

Mark


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

web.xml and @WebServlet priority when more rules match

[Mladen Adamović]

Lets assume that web.xml has a rule


One
/something/e*


While class Two.class has an annotation:

@WebServlet(name = "Two", urlPatterns = {"/something/er*"})

>From the Servlet 3.0 specification

8.2.3. (point 4). `The web.xml of the web application has the highest
precedence when resolving conflicts between the web.xml, web-fragment.xml
and annotations.`

While 12.2 states: The container will recursively try to match the longest
path-prefix. This is done by stepping down the path tree a directory at a
time, using the ’/’ character as a path separator. The longest match
determines the servlet selected.

So for the request /something/error Tomcat will choose Two.class?

And more general, in the case there are both annotation and web.xml rule
with the same prefix length, it will choose a first occurrence in web.xml?

If no one knows the answers but knows where to look in the source code,
that could be beneficial as well.

Thanks

Re: add mapping for jsp servlet in web.xml?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rob,

On 10/1/16 8:59 AM, Rob Nikander wrote:
> Hi,
> 
> I’m upgrading from Tomcat 6 to Tomcat 8. The web.xml has a mapping
> like this, to use the jsp servlet for all files in a certain
> directory:
> 
>  jsp 
> /some-stuff/* 
> 
> In Tomcat 6 this worked, but in 8, this *replaces* the existing
> mapping from the default web.xml (so .jsp files don’t work).
> 
> Is there way a simple way to add the mapping, rather than replace
> existing mappings?

Replacing the mapping would surprise me and I would consider it a bug.

Can you package a sample WAR with source that demonstrates this issue?
(Easiest "source" to package would just be two .jsp files where one
will run and the other will not).

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

iQIcBAEBCAAGBQJX9BhnAAoJEBzwKT+lPKRYHA8P/3Q20HEoTv/+OUsKI01pqN++
Ppuof/i4gGtaxcAoywXtcu4DNMw5rv2ryt8xEegr3j7vDNsYIfylHX9mYrVjmFoI
2DsEikmHrSb2GO1tU66U7h7Y1pxXzkyr3Gpnh4ZnVXOU7Bj+8gqinbcbg4/1N72T
3d25cAH5UOUmyK/PtDTDT1+193f+eFZe8z8IEtaC7rzbmydQPObSkfwUdO1SYBNn
lvCy/mjRj9uUU81ZnwritY0r+9uQsR3Iwtaekl1E5qjVVzz5tTlmJi2KlaXnESGT
9FrLEx4BfHi6fycMHXv/0SN5oYujDlBIPTe4nChh76Y9SGdccrIXoJMwDUrJTm9q
Ig7lB6w60w/aqx6k1SvTFtR95PIK5nK4yDCr7bxp82vBNNFu5PceXybEEdTZaLFw
qsTez8/txAvEW3IuWFXPmUAG3+obeDJpWAU9fdPt37UxdMDho155StB+wuKe7cFq
4wDdQBpOCQYrJ2d2VP5iP0JXj7co2aOIkWh8ujoauQBB48Vb0xfKahcNPy+fU0bO
HVFF9FG9O9c8i/z5wX1pcSj7KhSe/DoOtYFVB8V/IAZAa8NhMAqF5KN1e+jvGzBk
GI8Ri54HMTbDKkJb+WRnEOKsjxJ+7v5froj2vCrY9+vuKq18clu6qZiRi3dx09nn
TfBTOTh5/RR8OdBB7e04
=uZFx
-END PGP SIGNATURE-

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

add mapping for jsp servlet in web.xml?

[Rob Nikander]

Hi,

I’m upgrading from Tomcat 6 to Tomcat 8. The web.xml has a mapping like this, 
to use the jsp servlet for all files in a certain directory:


   jsp
   /some-stuff/*
 

In Tomcat 6 this worked, but in 8, this *replaces* the existing mapping from 
the default web.xml (so .jsp files don’t work).

Is there way a simple way to add the mapping, rather than replace existing 
mappings?

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

Re: Using server Web.xml Mime Types Data

[Mark Thomas]

On 8 September 2016 17:06:13 BST, George Sexton <geor...@mhsoftware.com> wrote:
>
>
>On 9/7/2016 11:44 AM, Mark Thomas wrote:
>> On 07/09/2016 00:58, George Sexton wrote:
>>> Is there any easy way that I can use the mime types in the Tomcat
>server
>>> level web.xml file?
>>>
>>> I know I can parse the XML myself, I was just wondering if there's a
>way
>>> to get the data already defined.
>> ServletContext.getMimeType(String filename) ?
>
>Thanks for the tip. I honestly did search for some solutions before 
>posting. I feel like a fool now. :(

I wouldn't. Not asking the question would have been the foolish thing to do. If 
it makes you feel better, I had to look at how the Default servlet did it to be 
sure I had the right method.

Mark


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

Re: Using server Web.xml Mime Types Data

[George Sexton]

On 9/7/2016 11:44 AM, Mark Thomas wrote:

On 07/09/2016 00:58, George Sexton wrote:

Is there any easy way that I can use the mime types in the Tomcat server
level web.xml file?

I know I can parse the XML myself, I was just wondering if there's a way
to get the data already defined.

ServletContext.getMimeType(String filename) ?


Thanks for the tip. I honestly did search for some solutions before 
posting. I feel like a fool now. :(


Some days are diamonds, and some days are just pieces of coal.



Mark

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



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com

Re: java.lang.ClassNotFoundException: org.apache.catalina.filters.HttpHeaderSecurityFilter for app specific web.xml under Tomcat 8.0.9 (bundled with Netbeans)

[Violeta Georgieva]

Hi Mladen,

2016-09-08 13:04 GMT+03:00 Mladen Adamović :
>
> Hi Mark,
>
> It seems that in Tomcat 8 it was added in
> Tomcat 8.0.23 (merged from Tomcat 7 I guess)

Typically we back port features to previous versions and not vice versa.

That feature was first developed in Tomcat 9 branch and then back ported.

Regards,
Violeta

>
>- [image: Add:] 54618
>: Add a new
>HttpHeaderSecurityFilter that adds the Strict-Transport-Security,
>X-Frame-Options and X-Content-Type-Options HTTP headers to the
response.
>(markt)
>
> And Netbeans embedded version I was using was 8.0.9, I guess that was the
> problem.
>
>
> On Thu, Sep 8, 2016 at 11:43 AM, Mark Thomas  wrote:
>
> > On 08/09/2016 10:12, Mladen Adamović wrote:
> > > I want in some specific apps to enable HttpHeaderSecurityFilter (I
might
> > > have some insecure applications at the same server).
> >
> > 
> >
> > > But I've got the error message when running from Tomcat 8.0.9.0. This
> > > happened in a development environment, this Tomcat was installed with
> > > Netbeans 8.0.1.
> > >
> > > 08-Sep-2016 09:35:37.108 SEVERE [http-nio-8084-exec-7]
> > > org.apache.catalina.core.StandardContext.filterStart Exception
starting
> > > filter httpHeaderSecurity
> > >  java.lang.ClassNotFoundException: org.apache.catalina.filters.
> > > HttpHeaderSecurityFilter
> >
> > 
> >
> > > What could be the reason Tomcat is displaying ClassNotFoundExpceiotn
for
> > > org.apache.catalina.filters.HttpHeaderSecurityFilter, since this
exists
> > > since Tomcat 7?
> >
> > Read this:
> > http://svn.us.apache.org/repos/asf/tomcat/tc7.0.x/
> > trunk/webapps/docs/changelog.xml
> >
> > and this:
> > http://svn.us.apache.org/repos/asf/tomcat/tc8.0.x/
> > trunk/webapps/docs/changelog.xml
> >
> > Search for "HttpHeaderSecurityFilter" and read all the matching
> > changelog entries.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >

Re: java.lang.ClassNotFoundException: org.apache.catalina.filters.HttpHeaderSecurityFilter for app specific web.xml under Tomcat 8.0.9 (bundled with Netbeans)

[Mladen Adamović]

Hi Mark,

It seems that in Tomcat 8 it was added in
Tomcat 8.0.23 (merged from Tomcat 7 I guess)

   - [image: Add:] 54618
   : Add a new
   HttpHeaderSecurityFilter that adds the Strict-Transport-Security,
   X-Frame-Options and X-Content-Type-Options HTTP headers to the response.
   (markt)

And Netbeans embedded version I was using was 8.0.9, I guess that was the
problem.


On Thu, Sep 8, 2016 at 11:43 AM, Mark Thomas  wrote:

> On 08/09/2016 10:12, Mladen Adamović wrote:
> > I want in some specific apps to enable HttpHeaderSecurityFilter (I might
> > have some insecure applications at the same server).
>
> 
>
> > But I've got the error message when running from Tomcat 8.0.9.0. This
> > happened in a development environment, this Tomcat was installed with
> > Netbeans 8.0.1.
> >
> > 08-Sep-2016 09:35:37.108 SEVERE [http-nio-8084-exec-7]
> > org.apache.catalina.core.StandardContext.filterStart Exception starting
> > filter httpHeaderSecurity
> >  java.lang.ClassNotFoundException: org.apache.catalina.filters.
> > HttpHeaderSecurityFilter
>
> 
>
> > What could be the reason Tomcat is displaying ClassNotFoundExpceiotn for
> > org.apache.catalina.filters.HttpHeaderSecurityFilter, since this exists
> > since Tomcat 7?
>
> Read this:
> http://svn.us.apache.org/repos/asf/tomcat/tc7.0.x/
> trunk/webapps/docs/changelog.xml
>
> and this:
> http://svn.us.apache.org/repos/asf/tomcat/tc8.0.x/
> trunk/webapps/docs/changelog.xml
>
> Search for "HttpHeaderSecurityFilter" and read all the matching
> changelog entries.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: java.lang.ClassNotFoundException: org.apache.catalina.filters.HttpHeaderSecurityFilter for app specific web.xml under Tomcat 8.0.9 (bundled with Netbeans)

[Mark Thomas]

On 08/09/2016 10:12, Mladen Adamović wrote:
> I want in some specific apps to enable HttpHeaderSecurityFilter (I might
> have some insecure applications at the same server).



> But I've got the error message when running from Tomcat 8.0.9.0. This
> happened in a development environment, this Tomcat was installed with
> Netbeans 8.0.1.
> 
> 08-Sep-2016 09:35:37.108 SEVERE [http-nio-8084-exec-7]
> org.apache.catalina.core.StandardContext.filterStart Exception starting
> filter httpHeaderSecurity
>  java.lang.ClassNotFoundException: org.apache.catalina.filters.
> HttpHeaderSecurityFilter



> What could be the reason Tomcat is displaying ClassNotFoundExpceiotn for
> org.apache.catalina.filters.HttpHeaderSecurityFilter, since this exists
> since Tomcat 7?

Read this:
http://svn.us.apache.org/repos/asf/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml

and this:
http://svn.us.apache.org/repos/asf/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Search for "HttpHeaderSecurityFilter" and read all the matching
changelog entries.

Mark

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

java.lang.ClassNotFoundException: org.apache.catalina.filters.HttpHeaderSecurityFilter for app specific web.xml under Tomcat 8.0.9 (bundled with Netbeans)

[Mladen Adamović]

I want in some specific apps to enable HttpHeaderSecurityFilter (I might
have some insecure applications at the same server).

I've edited web.xml of one application (not the tomcat/conf/web.xml file to
add this filter):


httpHeaderSecurity
org.apache.catalina.filters.HttpHeaderSecurityFilter
true

   hstsMaxAgeSeconds
   31536000



httpHeaderSecurity
/*
/
REQUEST


But I've got the error message when running from Tomcat 8.0.9.0. This
happened in a development environment, this Tomcat was installed with
Netbeans 8.0.1.

08-Sep-2016 09:35:37.108 SEVERE [http-nio-8084-exec-7]
org.apache.catalina.core.StandardContext.filterStart Exception starting
filter httpHeaderSecurity
 java.lang.ClassNotFoundException: org.apache.catalina.filters.
HttpHeaderSecurityFilter
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.apache.catalina.core.DefaultInstanceManager.loadClass(
DefaultInstanceManager.java:540)
at org.apache.catalina.core.DefaultInstanceManager.
loadClassMaybePrivileged(DefaultInstanceManager.java:531)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(
DefaultInstanceManager.java:150)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter(
ApplicationFilterConfig.java:258)
at org.apache.catalina.core.ApplicationFilterConfig.
(ApplicationFilterConfig.java:105)
at org.apache.catalina.core.StandardContext.filterStart(
StandardContext.java:4603)
at org.apache.catalina.core.StandardContext.startInternal(
StandardContext.java:5210)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(
ContainerBase.java:724)
at org.apache.catalina.core.ContainerBase.addChild(
ContainerBase.java:700)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714)
at org.apache.catalina.startup.HostConfig.deployDescriptor(
HostConfig.java:581)
at org.apache.catalina.startup.HostConfig.deployApps(
HostConfig.java:455)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1496)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(
BaseModelMBean.java:300)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(
DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(
JmxMBeanServer.java:801)
at org.apache.catalina.manager.ManagerServlet.check(
ManagerServlet.java:1437)
at org.apache.catalina.manager.ManagerServlet.deploy(
ManagerServlet.java:884)
at org.apache.catalina.manager.ManagerServlet.doGet(
ManagerServlet.java:335)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(
WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)
at org.netbeans.modules.web.monitor.server.MonitorFilter.
doFilter(MonitorFilter.java:393)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)
at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(
SetCharacterEncodingFilter.java:108)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
AuthenticatorBase.java:615)
at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:136)
at org.apache.catalina.valves.ErrorReportValve.invoke

Re: Using server Web.xml Mime Types Data

[Mark Thomas]

On 07/09/2016 00:58, George Sexton wrote:
> Is there any easy way that I can use the mime types in the Tomcat server
> level web.xml file?
> 
> I know I can parse the XML myself, I was just wondering if there's a way
> to get the data already defined.

ServletContext.getMimeType(String filename) ?

Mark

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

RE: Using server Web.xml Mime Types Data

[Jeffrey Janner]

George,
As I recall, anything in the server's web.xml is merged with the application's 
web.xml unless overridden by the applications own settings, i.e. if not defined 
in the app web.xml file.
Was there something specific you were asking that didn't come across in your 
question?
Jeff

> -Original Message-
> From: George Sexton [mailto:geor...@mhsoftware.com]
> Sent: Tuesday, September 06, 2016 6:59 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Using server Web.xml Mime Types Data
> 
> Is there any easy way that I can use the mime types in the Tomcat server
> level web.xml file?
> 
> I know I can parse the XML myself, I was just wondering if there's a way
> to get the data already defined.
> 
> 
> --
> George Sexton
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.connectdaily.com

Using server Web.xml Mime Types Data

[George Sexton]

Is there any easy way that I can use the mime types in the Tomcat server 
level web.xml file?


I know I can parse the XML myself, I was just wondering if there's a way 
to get the data already defined.



--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.connectdaily.com

Re: using filter on web.xml

[Francesco Viscomi]

Thanks Andrè.
the login page indeed has nothing inside, i just want to activate the
filter, because inside the filter there is the logic to authenticate the
user;
Anyway i really appreciate your suggestion.

Francesco

2016-05-15 14:09 GMT+02:00 André Warnier (tomcat) :

> On 15.05.2016 13:58, Francesco Viscomi wrote:
>
>> Hi all,
>> I've declared a filter in web.xm as:
>>
>> 
>>  ShibbolethHeaderReaderFilter
>>  ShibbolethHeaderReaderFilter
>> IdPC
>>  
>>
>>
>> it.loset.idpcp.ri.filters.ShibbolethHeaderReaderFilterIdpc
>>
>>  
>>  configurationFile
>>
>> resources/shibboleth-spp-config.xml
>>  
>>  
>>
>>  
>>  ShibbolethHeaderReaderFilter
>>  /protected/*
>>  
>>
>>
>>
>>
>> where it.loset.idpcp.ri.filters.ShibbolethHeaderReaderFilterIdpc
>> is a jar file that i don't know the source;
>>
>>
>> Now i do i call as:
>> http://localhost:8080/srlo/protected/login.html
>>
>> and i get HTTP Status 404 the resource is not available.
>>
>>
>>
>>
>> My question is, why the filter do not activated: in the url the is the
>> word
>> protect and the mapping of the filter is
>> /protected/*
>>
>>
> I don't know the details of it, and not much at all about Shibollet, but
> usually in an authentication scenario which involves a login page to
> authenticate a user, one would not include the login page in question, in
> the area that is protected by the authentication.
> This would ususally result in an endless logic loop.
> Think about it.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Ing. Viscomi Francesco

Re: using filter on web.xml

[tomcat]

On 15.05.2016 13:58, Francesco Viscomi wrote:

Hi all,
I've declared a filter in web.xm as:


 ShibbolethHeaderReaderFilter
 ShibbolethHeaderReaderFilter
IdPC
 

it.loset.idpcp.ri.filters.ShibbolethHeaderReaderFilterIdpc

 
 configurationFile

resources/shibboleth-spp-config.xml
 
 

 
 ShibbolethHeaderReaderFilter
 /protected/*
 




where it.loset.idpcp.ri.filters.ShibbolethHeaderReaderFilterIdpc
is a jar file that i don't know the source;


Now i do i call as:
http://localhost:8080/srlo/protected/login.html

and i get HTTP Status 404 the resource is not available.




My question is, why the filter do not activated: in the url the is the word
protect and the mapping of the filter is
/protected/*



I don't know the details of it, and not much at all about Shibollet, but usually in an 
authentication scenario which involves a login page to authenticate a user, one would not 
include the login page in question, in the area that is protected by the authentication.

This would ususally result in an endless logic loop.
Think about it.



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

using filter on web.xml

[Francesco Viscomi]

Hi all,
I've declared a filter in web.xm as:


ShibbolethHeaderReaderFilter
ShibbolethHeaderReaderFilter
IdPC


it.loset.idpcp.ri.filters.ShibbolethHeaderReaderFilterIdpc


configurationFile

resources/shibboleth-spp-config.xml




ShibbolethHeaderReaderFilter
/protected/*





where it.loset.idpcp.ri.filters.ShibbolethHeaderReaderFilterIdpc
is a jar file that i don't know the source;


Now i do i call as:
http://localhost:8080/srlo/protected/login.html

and i get HTTP Status 404 the resource is not available.




My question is, why the filter do not activated: in the url the is the word
protect and the mapping of the filter is
/protected/*





-- 
Ing. Viscomi Francesco

RE: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml

[Caldarale, Charles R]

> From: Junqiang Zhang [mailto:junqiangzh...@gmail.com] 
> Subject: Re: Tomcat can not locate the folders of CSS files inside a web app,
> if the url-pattern of a servlet is set to / inside web.xml

Don't top-post.  See item 6 under 
http://tomcat.apache.org/lists.html#tomcat-users

> I did map my servlet to the url-pattern "/".

The point we're trying to make is that you must not use a servlet mapping of 
"/" unless your servlet can handle the duties of DefaultServlet, including 
delivering static content such as CSS files and images.  Your mappings need to 
be more specific (as you appear to have already discovered, based on your first 
message).

> Is there any setting could let web browsers find the static content inside 
> the webapp
> directory? If I put the static content into some other places, can web 
> browsers find 
> the css file?

Note that web browsers do not "find" the content inside the webapp directory; 
that's entirely up to the servlets of the webapp, including Tomcat's built-in 
DefaultServlet - if you haven't disabled it by mapping something else to "/".  
Correct your servlet mapping and things will work as desired.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml

[Junqiang Zhang]

Thank all you guys very much for replying to my post.

I did map my servlet to the url-pattern "/". Is there any setting
could let web browsers find the static content inside the webapp
directory? If I put the static content into some other places, can web
browsers find the css file?

Does Jetty work the same way as Tomcat regarding this problem?

I have tried putting the webapp content in either ROOT directory or
mywebapp directory inside Tomcat/webapps. Web browsers could not find
the css file.

I copied the content of web.xml below.




http://xmlns.jcp.org/xml/ns/javaee;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
  http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd;
  version="3.1"
  metadata-complete="true">

  
search
com.dealfar.mainpage
  

  
search
/
  




On Tue, Mar 8, 2016 at 5:02 AM, Chris Gamache <cgama...@gmail.com> wrote:
> Chuck,
>
> That's precisely the point I was trying to make.
>
> CG
>
> On Mon, Mar 7, 2016 at 2:05 PM, Caldarale, Charles R <
> chuck.caldar...@unisys.com> wrote:
>
>> > From: Chris Gamache [mailto:cgama...@gmail.com]
>> > Subject: Re: Tomcat can not locate the folders of CSS files inside a web
>> app,
>> > if the url-pattern of a servlet is set to / inside web.xml
>>
>> > /mywebapp/css/style.css is where that file should be located if exists in
>> > the spot indicated in the tree diagram.
>>
>> > I don't think the default servlet plays in to this...
>>
>> Clearly it does, as Violeta stated.  Since the webapp is overriding the
>> mapping for "/", Tomcat's DefaultServlet will never get used, so there is
>> _nothing_ available to deliver static content.
>>
>>  - Chuck
>>
>>
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail and
>> its attachments from all computers.
>>
>>
>> -
>> 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: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml

[Chris Gamache]

Chuck,

That's precisely the point I was trying to make.

CG

On Mon, Mar 7, 2016 at 2:05 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Chris Gamache [mailto:cgama...@gmail.com]
> > Subject: Re: Tomcat can not locate the folders of CSS files inside a web
> app,
> > if the url-pattern of a servlet is set to / inside web.xml
>
> > /mywebapp/css/style.css is where that file should be located if exists in
> > the spot indicated in the tree diagram.
>
> > I don't think the default servlet plays in to this...
>
> Clearly it does, as Violeta stated.  Since the webapp is overriding the
> mapping for "/", Tomcat's DefaultServlet will never get used, so there is
> _nothing_ available to deliver static content.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml

[Caldarale, Charles R]

> From: Chris Gamache [mailto:cgama...@gmail.com] 
> Subject: Re: Tomcat can not locate the folders of CSS files inside a web app, 
> if the url-pattern of a servlet is set to / inside web.xml

> /mywebapp/css/style.css is where that file should be located if exists in
> the spot indicated in the tree diagram.

> I don't think the default servlet plays in to this...

Clearly it does, as Violeta stated.  Since the webapp is overriding the mapping 
for "/", Tomcat's DefaultServlet will never get used, so there is _nothing_ 
available to deliver static content.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml

[Chris Gamache]

Junqiang Zhang has the expectation of the paths to the files correct.
/mywebapp/css/style.css is where that file should be located if exists in
the spot indicated in the tree diagram.

I don't think the default servlet plays in to this...

Can you post your web.xml ? I think perhaps one of your mappings is sitting
on "/*" which would keep tomcat from serving static resources.

On Mon, Mar 7, 2016 at 1:52 PM, Violeta Georgieva <violet...@apache.org>
wrote:

> Hi,
>
> 2016-03-07 19:37 GMT+02:00 Junqiang Zhang <junqiangzh...@gmail.com>:
> >
> > I have tested on Tomcat versions 8.0.30, 8.0.32, and 9.0.0.M3.
> >
> > A web app is put inside a folder (let's say the name of the foder is
> > mywebapp) inside the Tomcat webapps directory. The folder for css
> > files (let's say the name of folder is css) is located inside this web
> > app folder. There is no index.html or index.jsp inside the web app
> > folder. The structure is as the follows.
> >
> > Tomcat
> > webapps
> > ---mywebapp
> >  ---css
> >   ---styles.css
> >  ---images
> >  ---META-INF
> >  ---scripts
> >  ---WEB-INF
> >  ---classes
> >   ---someservlet.class
> >     ---lib
> > ---src
> > ---someservlet.java
> >---web.xml
> >
> >
> > If the url-pattern of someservlet.class is set to / inside web.xml,
>
> Tomcat's "default" servlet [1] is mapped to "/".
> The "default" servlet is a servlet that serves static resources as well as
> serves the directory listings (if enabled).
>
> You should know that when you map your servlet to "/" then you will
> override the "default" servlet mapping.
> So you should ensure that your servlet will do the same as "default" one in
> order to serve the static resources.
>
> When you map your servlet to "/someclass" then the static resources will be
> served by "default" servlet as expected.
>
> Regards,
> Violeta
> [1] http://tomcat.apache.org/tomcat-8.0-doc/default-servlet.html
>
> > someservlet.class can be access using
> > http://www.somewebsite.com/mywebapp
> >
> > The problem is that web browsers cannot locate styles.css at
> > http://www.somewebsite.com/mywebapp/css/styles.css. Therefor,
> > styles.css cannot be applied on the html file generated by
> > someservlet.class. Probably other folders or files inside mywebapp
> > directory cannot be accessed by web browsers too.
> >
> > If the url-pattern of someservlet.class is set to /someclass inside
> > web.xml, someservlet.class can be access using
> > http://www.somewebsite.com/mywebapp/someclass . Web browsers can
> > correctly locate styles.css at
> > http://www.somewebsite.com/mywebapp/css/styles.css
> >
> > Any solution to this problem? Does it solve this problem if I use
> > Jetty or Glassfish?
> >
> > Thanks.
> > Junqiang
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>

Re: Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml

[Violeta Georgieva]

Hi,

2016-03-07 19:37 GMT+02:00 Junqiang Zhang <junqiangzh...@gmail.com>:
>
> I have tested on Tomcat versions 8.0.30, 8.0.32, and 9.0.0.M3.
>
> A web app is put inside a folder (let's say the name of the foder is
> mywebapp) inside the Tomcat webapps directory. The folder for css
> files (let's say the name of folder is css) is located inside this web
> app folder. There is no index.html or index.jsp inside the web app
> folder. The structure is as the follows.
>
> Tomcat
> webapps
> ---mywebapp
>  ---css
>   ---styles.css
>  ---images
>  ---META-INF
>  ---scripts
>  ---WEB-INF
>  ---classes
>   ---someservlet.class
> ---lib
> ---src
>     ---someservlet.java
>---web.xml
>
>
> If the url-pattern of someservlet.class is set to / inside web.xml,

Tomcat's "default" servlet [1] is mapped to "/".
The "default" servlet is a servlet that serves static resources as well as
serves the directory listings (if enabled).

You should know that when you map your servlet to "/" then you will
override the "default" servlet mapping.
So you should ensure that your servlet will do the same as "default" one in
order to serve the static resources.

When you map your servlet to "/someclass" then the static resources will be
served by "default" servlet as expected.

Regards,
Violeta
[1] http://tomcat.apache.org/tomcat-8.0-doc/default-servlet.html

> someservlet.class can be access using
> http://www.somewebsite.com/mywebapp
>
> The problem is that web browsers cannot locate styles.css at
> http://www.somewebsite.com/mywebapp/css/styles.css. Therefor,
> styles.css cannot be applied on the html file generated by
> someservlet.class. Probably other folders or files inside mywebapp
> directory cannot be accessed by web browsers too.
>
> If the url-pattern of someservlet.class is set to /someclass inside
> web.xml, someservlet.class can be access using
> http://www.somewebsite.com/mywebapp/someclass . Web browsers can
> correctly locate styles.css at
> http://www.somewebsite.com/mywebapp/css/styles.css
>
> Any solution to this problem? Does it solve this problem if I use
> Jetty or Glassfish?
>
> Thanks.
> Junqiang
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Tomcat can not locate the folders of CSS files inside a web app, if the url-pattern of a servlet is set to / inside web.xml

[Junqiang Zhang]

I have tested on Tomcat versions 8.0.30, 8.0.32, and 9.0.0.M3.

A web app is put inside a folder (let's say the name of the foder is
mywebapp) inside the Tomcat webapps directory. The folder for css
files (let's say the name of folder is css) is located inside this web
app folder. There is no index.html or index.jsp inside the web app
folder. The structure is as the follows.

Tomcat
webapps
---mywebapp
 ---css
  ---styles.css
 ---images
 ---META-INF
 ---scripts
 ---WEB-INF
 ---classes
  ---someservlet.class
---lib
---src
---someservlet.java
   ---web.xml


If the url-pattern of someservlet.class is set to / inside web.xml,
someservlet.class can be access using
http://www.somewebsite.com/mywebapp

The problem is that web browsers cannot locate styles.css at
http://www.somewebsite.com/mywebapp/css/styles.css. Therefor,
styles.css cannot be applied on the html file generated by
someservlet.class. Probably other folders or files inside mywebapp
directory cannot be accessed by web browsers too.

If the url-pattern of someservlet.class is set to /someclass inside
web.xml, someservlet.class can be access using
http://www.somewebsite.com/mywebapp/someclass . Web browsers can
correctly locate styles.css at
http://www.somewebsite.com/mywebapp/css/styles.css

Any solution to this problem? Does it solve this problem if I use
Jetty or Glassfish?

Thanks.
Junqiang

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

Re: property replacement in WEB-INF/web.xml

[Christopher Schultz]

André,

On 1/13/16 9:36 AM, André Warnier (tomcat) wrote:
> Hi gurus.
> 
> Under tomcat 8 and Linux, I am deploying an externally-provided web
> application, which in its web.xml configuration file, has a parameter
> like this :
> 
> 
>   logroot
>   /var/log/tomcat8
> 
> 
> This works, but I would like to make this more "generic", and would like
> to replace the above param-value by something like this :
> 
> 
>   logroot
>   ${CATALINA_BASE}/logs
> 
> 
> with CATALINA_BASE being the well-known environment value set prior to
> starting (the JVM which runs) Tomcat (and "${CATALINA_BASE}/logs" being
> actually a link which points to "/var/log/tomcat8" in this case).
> 
> Can I do this ? and if yes, what is the exact way to do this right ?
> 
> (In a log4j configuration file, I can use "${env:CATALINA_BASE}" for
> this, but this is not available under Tomcat, or is it ?)

I think you want to use the system property version of that value, which is:


  logroot
  <param-value}${catalina.base}/logs


I can't find it in the Tomcat documentation that this will work in a web
application's web.xml, but that's definitely how it works for server.xml

-chris

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

property replacement in WEB-INF/web.xml

[tomcat]

Hi gurus.

Under tomcat 8 and Linux, I am deploying an externally-provided web application, which in 
its web.xml configuration file, has a parameter like this :



  logroot
  /var/log/tomcat8


This works, but I would like to make this more "generic", and would like to replace the 
above param-value by something like this :



  logroot
  ${CATALINA_BASE}/logs


with CATALINA_BASE being the well-known environment value set prior to starting (the JVM 
which runs) Tomcat (and "${CATALINA_BASE}/logs" being actually a link which points to 
"/var/log/tomcat8" in this case).


Can I do this ? and if yes, what is the exact way to do this right ?

(In a log4j configuration file, I can use "${env:CATALINA_BASE}" for this, but this is not 
available under Tomcat, or is it ?)



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

Multiple authentication-methods in single a web-app/web.xml

[Torsten Rieger]

Hi,



we are developing a tool with a central repository-server, communication is
implementes based on apache-cxf.

We use a legacy SOAP-based webservice with HTTP-transport and it worked
fine with basic auth.

Since we extended our server-side application with a rest-webservice we
want to change the auth-method to FROM-BASED for the rest-webservice,
because we need session-support for secure image delivery to web-browser
(img-tags) identified by session-id.

Changing the SOAP webservice to form-based authentications seems not to be
possible.

Is it possible to configure two or more auth-methods in a single
/web.xml or exists a workaround to use two auth-methods?



Regards,

Torsten

Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

[Thusitha Thilina Dayaratne]

Hi,


 Hi Chris,

 Thanks a lot for the quick response. Please find inline answers.

 On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
  I'm in the process of migrating embedded tomcat 7.0.59 application
  to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
  get a NullPointerException when trying to access the server home
  page. I fixed that manually setting an empty TldCache instance in
  the context as follows
 
  [snip]
 
 
  Now it is not throwing the NPE. but instead of that I'm getting
  following exception
 
  org.apache.jasper.JasperException: The absolute uri:
  http://tiles.apache.org/tags-tiles cannot be resolved in either
  web.xml or the jar files deployed with this application at
 

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

 I
 
 looks like you are missing the Tiles JAR. Is it located in your
 WEB-INF/lib directory?
 These jar files are located in a folder called plugins. We are reading
them
 from our JarScanner

  I'm also using a extended JarScanner as follows

 
  public class CarbonTomcatJarScanner extends StandardJarScanner{

  Without trying to read and understand all this code, can you explain
  why you are using your own JarScanner instead of Tomcat's? Perhaps
  there is a way to do this where you don't need to write your own
  JarScanner.

 According the servlet 3.0 spec, tldScanner classes are picked up
 during web-app load phase from
 the classPath using SPI mechanism. Normal sequence is to scan;
  - WEB-INF/lib
  - parent URL classPath
 However with the BundleClassLoader being the parent classLoader of
 Tomcat web-app classLoder, it fails to pick up
 TLD scanner references reside in plugins directory. That is why we
 have used a our own JarScanner

  It seems that this is relate to JarScanner. Can someone tell me
  what I have done wrong here? Or a way to fix this? Is this occur
  because I set TldCache manually?

 I'm curious as to why the TldCache isn't being set up correctly in the
 first place. In your other recent thread (NPE in
 JspCompilationContext.getTldResourcePath), there were a couple of
 questions from the community that it doesn't look like you have
 answered. Perhaps answering those might help you solve both problems
 at once.
 I'm not so quite sure about that. I manually set the TldCache and manually
 added the JasperInitializer to the StandardContext
 to get rid of the NPE
 I will try to answer the an answered questions in other thread.

You may want to have a look at Eclipse Gemini Web (OSGi Web Container
Reference Implementation)
Thanks for the reference. We are using eclipse equinox jasper. Could
that be a reason that TldCache not getting initialized?

I'm using In tomcat 7 when creating EmbeddedServletOptions (get call from
JspServlet init method) inside the constructor tldLocationsCache is
initiated as

tldLocationsCache = TldLocationsCache.getInstance(context);

in the getInstance method, if context don't have cache set it will set
a new empty cache and return that.

public static synchronized TldLocationsCache getInstance(
ServletContext ctxt) {
if (ctxt == null) {
throw new IllegalArgumentException(ServletContext was null);
}
TldLocationsCache cache = (TldLocationsCache) ctxt.getAttribute(KEY);
if (cache == null) {
cache = new TldLocationsCache(ctxt);
ctxt.setAttribute(KEY, cache);
}
return cache;
}

In tomcat 8 that method looks like follows. So if cache is not set at
the context then this will return null

public static TldCache getInstance(ServletContext servletContext) {
if (servletContext == null) {
throw new IllegalArgumentException(Localizer.getMessage(
org.apache.jasper.compiler.TldCache.servletContextNull));
}
return (TldCache)
servletContext.getAttribute(SERVLET_CONTEXT_ATTRIBUTE_NAME);
}

In my application I have 2 contexts. One is the StandardContext which
is created by the root app, and another context which is created by
equinox jasper.

I have manually added the SCI for the Tomcat OSGi bundle and then
TldCache is get initialized by the JasperInitializer onStartup method.

But how can I initialize the TldCache for jsp? ATM I manually set the
already initialized Tldcache for the jsp.


Can someone tell me what might be the issue here? What I've done wrong here?

In tomcat 7.0.59. We didn't use SCI to initialize the Jasper.


Thanks

Best Regards

/Thusitha


On Fri, Mar 20, 2015 at 1:55 PM, Thusitha Thilina Dayaratne 
thusit...@wso2.com wrote:

 Hi,

 
  Hi Chris,
 
  Thanks a lot for the quick response. Please find inline answers.
 
  On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
   I'm in the process of migrating embedded tomcat 7.0.59 application
   to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
   get a NullPointerException when trying to access the server home
   page. I fixed that manually setting an empty TldCache instance in
   the context as follows

Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

[Thusitha Thilina Dayaratne]

Hi,


 Hi Chris,

 Thanks a lot for the quick response. Please find inline answers.

 On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
  I'm in the process of migrating embedded tomcat 7.0.59 application
  to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
  get a NullPointerException when trying to access the server home
  page. I fixed that manually setting an empty TldCache instance in
  the context as follows
 
  [snip]
 
 
  Now it is not throwing the NPE. but instead of that I'm getting
  following exception
 
  org.apache.jasper.JasperException: The absolute uri:
  http://tiles.apache.org/tags-tiles cannot be resolved in either
  web.xml or the jar files deployed with this application at
 

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

 I
 
 looks like you are missing the Tiles JAR. Is it located in your
 WEB-INF/lib directory?
 These jar files are located in a folder called plugins. We are reading
them
 from our JarScanner

  I'm also using a extended JarScanner as follows

 
  public class CarbonTomcatJarScanner extends StandardJarScanner{

  Without trying to read and understand all this code, can you explain
  why you are using your own JarScanner instead of Tomcat's? Perhaps
  there is a way to do this where you don't need to write your own
  JarScanner.

 According the servlet 3.0 spec, tldScanner classes are picked up
 during web-app load phase from
 the classPath using SPI mechanism. Normal sequence is to scan;
  - WEB-INF/lib
  - parent URL classPath
 However with the BundleClassLoader being the parent classLoader of
 Tomcat web-app classLoder, it fails to pick up
 TLD scanner references reside in plugins directory. That is why we
 have used a our own JarScanner

  It seems that this is relate to JarScanner. Can someone tell me
  what I have done wrong here? Or a way to fix this? Is this occur
  because I set TldCache manually?

 I'm curious as to why the TldCache isn't being set up correctly in the
 first place. In your other recent thread (NPE in
 JspCompilationContext.getTldResourcePath), there were a couple of
 questions from the community that it doesn't look like you have
 answered. Perhaps answering those might help you solve both problems
 at once.
 I'm not so quite sure about that. I manually set the TldCache and manually
 added the JasperInitializer to the StandardContext
 to get rid of the NPE
 I will try to answer the an answered questions in other thread.

You may want to have a look at Eclipse Gemini Web (OSGi Web Container
Reference Implementation)
Thanks for the reference. We are using eclipse equinox jasper. Could that
be a reason that TldCache not getting initialized?

Thanks
Best Regards
/Thusitha


On Fri, Mar 20, 2015 at 12:00 AM, Violeta Georgieva miles...@gmail.com
wrote:

 Hi,

 2015-03-19 5:34 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:
 
  Hi Chris,
 
  Thanks a lot for the quick response. Please find inline answers.
 
  On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
   I'm in the process of migrating embedded tomcat 7.0.59 application
   to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
   get a NullPointerException when trying to access the server home
   page. I fixed that manually setting an empty TldCache instance in
   the context as follows
  
   [snip]
  
  
   Now it is not throwing the NPE. but instead of that I'm getting
   following exception
  
   org.apache.jasper.JasperException: The absolute uri:
   http://tiles.apache.org/tags-tiles cannot be resolved in either
   web.xml or the jar files deployed with this application at
  
 

 org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)
 
  I
  
  looks like you are missing the Tiles JAR. Is it located in your
  WEB-INF/lib directory?
  These jar files are located in a folder called plugins. We are reading
 them
  from our JarScanner
 
   I'm also using a extended JarScanner as follows
 
  
   public class CarbonTomcatJarScanner extends StandardJarScanner{
 
   Without trying to read and understand all this code, can you explain
   why you are using your own JarScanner instead of Tomcat's? Perhaps
   there is a way to do this where you don't need to write your own
   JarScanner.
 
  According the servlet 3.0 spec, tldScanner classes are picked up
  during web-app load phase from
  the classPath using SPI mechanism. Normal sequence is to scan;
   - WEB-INF/lib
   - parent URL classPath
  However with the BundleClassLoader being the parent classLoader of
  Tomcat web-app classLoder, it fails to pick up
  TLD scanner references reside in plugins directory. That is why we
  have used a our own JarScanner
 
   It seems that this is relate to JarScanner. Can someone tell me
   what I have done wrong here? Or a way to fix this? Is this occur
   because I set TldCache manually?
 
  I'm curious as to why the TldCache isn't being set up correctly in the
  first place. In your other

Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

[Violeta Georgieva]

Hi,

2015-03-19 5:34 GMT+02:00 Thusitha Thilina Dayaratne thusit...@wso2.com:

 Hi Chris,

 Thanks a lot for the quick response. Please find inline answers.

 On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
  I'm in the process of migrating embedded tomcat 7.0.59 application
  to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
  get a NullPointerException when trying to access the server home
  page. I fixed that manually setting an empty TldCache instance in
  the context as follows
 
  [snip]
 
 
  Now it is not throwing the NPE. but instead of that I'm getting
  following exception
 
  org.apache.jasper.JasperException: The absolute uri:
  http://tiles.apache.org/tags-tiles cannot be resolved in either
  web.xml or the jar files deployed with this application at
 

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

 I
 
 looks like you are missing the Tiles JAR. Is it located in your
 WEB-INF/lib directory?
 These jar files are located in a folder called plugins. We are reading
them
 from our JarScanner

  I'm also using a extended JarScanner as follows

 
  public class CarbonTomcatJarScanner extends StandardJarScanner{

  Without trying to read and understand all this code, can you explain
  why you are using your own JarScanner instead of Tomcat's? Perhaps
  there is a way to do this where you don't need to write your own
  JarScanner.

 According the servlet 3.0 spec, tldScanner classes are picked up
 during web-app load phase from
 the classPath using SPI mechanism. Normal sequence is to scan;
  - WEB-INF/lib
  - parent URL classPath
 However with the BundleClassLoader being the parent classLoader of
 Tomcat web-app classLoder, it fails to pick up
 TLD scanner references reside in plugins directory. That is why we
 have used a our own JarScanner

  It seems that this is relate to JarScanner. Can someone tell me
  what I have done wrong here? Or a way to fix this? Is this occur
  because I set TldCache manually?

 I'm curious as to why the TldCache isn't being set up correctly in the
 first place. In your other recent thread (NPE in
 JspCompilationContext.getTldResourcePath), there were a couple of
 questions from the community that it doesn't look like you have
 answered. Perhaps answering those might help you solve both problems
 at once.
 I'm not so quite sure about that. I manually set the TldCache and manually
 added the JasperInitializer to the StandardContext
 to get rid of the NPE
 I will try to answer the an answered questions in other thread.

You may want to have a look at Eclipse Gemini Web (OSGi Web Container
Reference Implementation)

Regards,
Violeta

 Thanks
 Best Regards
 /Thusitha

Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thusitha,

On 3/18/15 11:34 PM, Thusitha Thilina Dayaratne wrote:
 Hi Chris,
 
 Thanks a lot for the quick response. Please find inline answers.
 
 On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
 I'm in the process of migrating embedded tomcat 7.0.59
 application to Tomcat 8.0.20. Tomcat is been bundle as a OSGI
 bundle. First I get a NullPointerException when trying to
 access the server home page. I fixed that manually setting an
 empty TldCache instance in the context as follows
 
 [snip]
 
 
 Now it is not throwing the NPE. but instead of that I'm
 getting following exception
 
 org.apache.jasper.JasperException: The absolute uri: 
 http://tiles.apache.org/tags-tiles cannot be resolved in
 either web.xml or the jar files deployed with this application
 at
 
 org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

 
 I
 
 looks like you are missing the Tiles JAR. Is it located in your 
 WEB-INF/lib directory?
 These jar files are located in a folder called plugins. We are
 reading them from our JarScanner
 
 I'm also using a extended JarScanner as follows
 
 
 public class CarbonTomcatJarScanner extends
 StandardJarScanner{
 
 Without trying to read and understand all this code, can you
 explain why you are using your own JarScanner instead of
 Tomcat's? Perhaps there is a way to do this where you don't need
 to write your own JarScanner.
 
 According the servlet 3.0 spec, tldScanner classes are picked up 
 during web-app load phase from the classPath using SPI mechanism.
 Normal sequence is to scan; - WEB-INF/lib - parent URL classPath 
 However with the BundleClassLoader being the parent classLoader of 
 Tomcat web-app classLoder, it fails to pick up TLD scanner
 references reside in plugins directory. That is why we have used a
 our own JarScanner
 
 It seems that this is relate to JarScanner. Can someone tell
 me what I have done wrong here? Or a way to fix this? Is this
 occur because I set TldCache manually?
 
 I'm curious as to why the TldCache isn't being set up correctly
 in the first place. In your other recent thread (NPE in 
 JspCompilationContext.getTldResourcePath), there were a couple
 of questions from the community that it doesn't look like you
 have answered. Perhaps answering those might help you solve both
 problems at once.
 
 I'm not so quite sure about that. I manually set the TldCache and
 manually added the JasperInitializer to the StandardContext to get
 rid of the NPE I will try to answer the an answered questions in
 other thread.

Well, just because you aren't getting an NPE any longer doesn't mean
that you actually solved the root of the problem. The root of the
problem is that your TLDs aren't being loaded. You just ended up
putting a band-aid on the cache, which is still empty.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVCxIkAAoJEBzwKT+lPKRYHkAP/jFYoFQLJXZZ9sf/+UBo9jEx
oDXHloweXQ7T1V8aVu2ksH9mgzPtofSbYTwjeiQimQsAkUW0rFAcBPCrgsnzrrN6
xJss6aFMLC3aac1+linQaWaeSj4WX3lhbe1lghP0yqN18UxsoTuzUg6JqgQ5fs9w
7bAixbQko9GREJbPuT93IvpEcKx6hKwVre2m8VdkDsaNgELHDSqNykcoGLDOobdX
RKG+tggg1bsOnJ/aDcN75faOwKE7dNtLysi/d4UpgMYRzMcxVo8CT1u2ttTbFeBe
iiBYtdPZ1Fcosa8bLKj71LVFQ79+Id13kY0bxXczBM+SL88N5KEOI0fCqd94ysQq
OIY3Ppr2CTNLHl7zZskSTYtqCUe6TeaP6n+YW3VsxKfjlukJRjnVMjwrWQqqPs5n
SxmDRG7iF1YNXltHntK8pslgjQy69oGCsJiqMt3fhRmsF1Nnm/F/JR1oDYVWSJ3y
AKDa+0+pUqFuJRb4KGXAfi6Q6AXEp613LOX1P8psOg3DbE68CCrXXpuoFU9AGkma
XKr8aLf6MKtvj/aeoK/rTRlCVAPXztzfH4iHQq7zSQbJoSv0xORznszgoEXScYsj
Cs/ufky+hb/DEBVb1hhPLIYUMCMx0xuBn7RD7X7OVzyoS1Onv+zu06hfeAK1MVO/
83f4J5mbTh+myhiHwkXA
=i+Iu
-END PGP SIGNATURE-

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

org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

[Thusitha Thilina Dayaratne]

Hi,

I'm in the process of migrating embedded tomcat 7.0.59 application to
Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle.
First I get a NullPointerException when trying to access the server home
page. I fixed that manually setting an empty TldCache instance in the
context as follows

if(config.getServletContext().getAttribute(org.apache.jasper.compiler.TldCache)
== null){
Constructor? constructor =
Class.forName(org.apache.jasper.compiler.TldCache).getConstructor(ServletContext.class,
Map.class, Map.class);
Object instance =
constructor.newInstance(config.getServletContext(), new
HashMapString, TldResourcePath(), new HashMapTldResourcePath,
TaglibXml());

config.getServletContext().setAttribute(org.apache.jasper.compiler.TldCache,
instance);
}

Now it is not throwing the NPE. but instead of that I'm getting
following exception

org.apache.jasper.JasperException: The absolute uri:
 http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml
 or the jar files deployed with this application
 at
 org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)
 at
 org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:277)
 at
 org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:75)
 at
 org.apache.jasper.compiler.TagLibraryInfoImpl.generateTldResourcePath(TagLibraryInfoImpl.java:240)
 at
 org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:124)
 at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:411)
 at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
 at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1430)
 at org.apache.jasper.compiler.Parser.parse(Parser.java:139)
 at
 org.apache.jasper.compiler.ParserController.doParse(ParserController.java:227)
 at
 org.apache.jasper.compiler.ParserController.parse(ParserController.java:100)
 at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:199)
 at org.apache.jasper.compiler.Compiler.compile(Compiler.java:356)
 at org.apache.jasper.compiler.Compiler.compile(Compiler.java:336)
 at org.apache.jasper.compiler.Compiler.compile(Compiler.java:323)
 at
 org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:570)
 at
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:356)
 at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
 at org.wso2.carbon.ui.JspServlet.service(JspServlet.java:175)
 at org.wso2.carbon.ui.TilesJspServlet.service(TilesJspServlet.java:80)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
 at
 org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service(ContextPathServletAdaptor.java:37)
 at
 org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
 at
 org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128)
 at
 org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
 at
 org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service(DelegationServlet.java:64)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:721)
 at
 org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:466)
 at
 org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:391)
 at
 org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:318)
 at
 org.eclipse.equinox.http.servlet.internal.RequestDispatcherAdaptor.forward(RequestDispatcherAdaptor.java:30)
 at
 org.eclipse.equinox.http.helper.ContextPathServletAdaptor$RequestDispatcherAdaptor.forward(ContextPathServletAdaptor.java:362)
 at
 org.apache.tiles.servlet.context.ServletTilesRequestContext.forward(ServletTilesRequestContext.java:198)
 at
 org.apache.tiles.servlet.context.ServletTilesRequestContext.dispatch(ServletTilesRequestContext.java:185)
 at
 org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:419)
 at
 org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:370)
 at org.wso2.carbon.ui.action.ActionHelper.render(ActionHelper.java:52)
 at org.wso2.carbon.ui.TilesJspServlet.service(TilesJspServlet.java:101

Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

[Thusitha Thilina Dayaratne]

Hi Chris,

Thanks a lot for the quick response. Please find inline answers.

On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
 I'm in the process of migrating embedded tomcat 7.0.59 application
 to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
 get a NullPointerException when trying to access the server home
 page. I fixed that manually setting an empty TldCache instance in
 the context as follows

 [snip]


 Now it is not throwing the NPE. but instead of that I'm getting
 following exception

 org.apache.jasper.JasperException: The absolute uri:
 http://tiles.apache.org/tags-tiles cannot be resolved in either
 web.xml or the jar files deployed with this application at

org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

I

looks like you are missing the Tiles JAR. Is it located in your
WEB-INF/lib directory?
These jar files are located in a folder called plugins. We are reading them
from our JarScanner

 I'm also using a extended JarScanner as follows


 public class CarbonTomcatJarScanner extends StandardJarScanner{

 Without trying to read and understand all this code, can you explain
 why you are using your own JarScanner instead of Tomcat's? Perhaps
 there is a way to do this where you don't need to write your own
 JarScanner.

According the servlet 3.0 spec, tldScanner classes are picked up
during web-app load phase from
the classPath using SPI mechanism. Normal sequence is to scan;
 - WEB-INF/lib
 - parent URL classPath
However with the BundleClassLoader being the parent classLoader of
Tomcat web-app classLoder, it fails to pick up
TLD scanner references reside in plugins directory. That is why we
have used a our own JarScanner

 It seems that this is relate to JarScanner. Can someone tell me
 what I have done wrong here? Or a way to fix this? Is this occur
 because I set TldCache manually?

I'm curious as to why the TldCache isn't being set up correctly in the
first place. In your other recent thread (NPE in
JspCompilationContext.getTldResourcePath), there were a couple of
questions from the community that it doesn't look like you have
answered. Perhaps answering those might help you solve both problems
at once.
I'm not so quite sure about that. I manually set the TldCache and manually
added the JasperInitializer to the StandardContext
to get rid of the NPE
I will try to answer the an answered questions in other thread.

Thanks
Best Regards
/Thusitha

On Thu, Mar 19, 2015 at 3:08 AM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Thusitha,

 On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
  I'm in the process of migrating embedded tomcat 7.0.59 application
  to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
  get a NullPointerException when trying to access the server home
  page. I fixed that manually setting an empty TldCache instance in
  the context as follows
 
  [snip]
 
 
  Now it is not throwing the NPE. but instead of that I'm getting
  following exception
 
  org.apache.jasper.JasperException: The absolute uri:
  http://tiles.apache.org/tags-tiles cannot be resolved in either
  web.xml or the jar files deployed with this application at
 
 org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

 It
 
 looks like you are missing the Tiles JAR. Is it located in your
 WEB-INF/lib directory?

  I'm also using a extended JarScanner as follows
 
  public class CarbonTomcatJarScanner extends StandardJarScanner{

 Without trying to read and understand all this code, can you explain
 why you are using your own JarScanner instead of Tomcat's? Perhaps
 there is a way to do this where you don't need to write your own
 JarScanner.

  It seems that this is relate to JarScanner. Can someone tell me
  what I have done wrong here? Or a way to fix this? Is this occur
  because I set TldCache manually?

 I'm curious as to why the TldCache isn't being set up correctly in the
 first place. In your other recent thread (NPE in
 JspCompilationContext.getTldResourcePath), there were a couple of
 questions from the community that it doesn't look like you have
 answered. Perhaps answering those might help you solve both problems
 at once.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJVCfBVAAoJEBzwKT+lPKRYdSoP/1jjvwNnNlTDSaR8ptkN3TLk
 u37oZ5qmuNNTcY/F7Clh0cEmslvu8e3oqqTZQ7IBT9PMwBUmyoUhN2PtljQLY3UQ
 QFPQyARHKdf6f+MJx3zFBpJr/mlzrMtaNXMGXtCMkesD6Kf8FdWn70/irKG69/fv
 TyGI8lD07p/lRbkKIsg7uFuWItuRgCG4SO00XqmpTEnE22kpjwW9IRp1Ajn6EFk0
 cKuRNXZzkXoTSqMT+PpqwZf/dr3Bx7cBajievhoBIXL41EhMI2gYpzhSKljkwb9x
 mP3bMDl7XyYX43Ka5ojyZaI1RXouGK95X8TKpyr+nxjuFUX1asQdJ40vAb6zICO7
 UTDUDJep7Kr0x9VtX/EiRuNJVl0zETe8uAUVmKhGovZ6xpAXUN0T/tb3BcfHAqXl
 65WmcqfeELdNYyQdd2FTK7t9UXWDVKv0v/C0GXSnZxGO1pWLv7brEF2gikEXucum
 zRZiQLA+EZ5jLtkRJ/Vhe15IDpzspvsZKoe3BTAIICe0AYScy80rZHNW1DOdW8JK

Re: org.apache.jasper.JasperException: The absolute uri: http://tiles.apache.org/tags-tiles cannot be resolved in either web.xml or the jar files deployed with this application

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thusitha,

On 3/18/15 5:39 AM, Thusitha Thilina Dayaratne wrote:
 I'm in the process of migrating embedded tomcat 7.0.59 application
 to Tomcat 8.0.20. Tomcat is been bundle as a OSGI bundle. First I
 get a NullPointerException when trying to access the server home 
 page. I fixed that manually setting an empty TldCache instance in
 the context as follows
 
 [snip]
 
 
 Now it is not throwing the NPE. but instead of that I'm getting 
 following exception
 
 org.apache.jasper.JasperException: The absolute uri:
 http://tiles.apache.org/tags-tiles cannot be resolved in either
 web.xml or the jar files deployed with this application at 
 org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:55)

It
 
looks like you are missing the Tiles JAR. Is it located in your
WEB-INF/lib directory?

 I'm also using a extended JarScanner as follows
 
 public class CarbonTomcatJarScanner extends StandardJarScanner{

Without trying to read and understand all this code, can you explain
why you are using your own JarScanner instead of Tomcat's? Perhaps
there is a way to do this where you don't need to write your own
JarScanner.

 It seems that this is relate to JarScanner. Can someone tell me
 what I have done wrong here? Or a way to fix this? Is this occur
 because I set TldCache manually?

I'm curious as to why the TldCache isn't being set up correctly in the
first place. In your other recent thread (NPE in
JspCompilationContext.getTldResourcePath), there were a couple of
questions from the community that it doesn't look like you have
answered. Perhaps answering those might help you solve both problems
at once.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVCfBVAAoJEBzwKT+lPKRYdSoP/1jjvwNnNlTDSaR8ptkN3TLk
u37oZ5qmuNNTcY/F7Clh0cEmslvu8e3oqqTZQ7IBT9PMwBUmyoUhN2PtljQLY3UQ
QFPQyARHKdf6f+MJx3zFBpJr/mlzrMtaNXMGXtCMkesD6Kf8FdWn70/irKG69/fv
TyGI8lD07p/lRbkKIsg7uFuWItuRgCG4SO00XqmpTEnE22kpjwW9IRp1Ajn6EFk0
cKuRNXZzkXoTSqMT+PpqwZf/dr3Bx7cBajievhoBIXL41EhMI2gYpzhSKljkwb9x
mP3bMDl7XyYX43Ka5ojyZaI1RXouGK95X8TKpyr+nxjuFUX1asQdJ40vAb6zICO7
UTDUDJep7Kr0x9VtX/EiRuNJVl0zETe8uAUVmKhGovZ6xpAXUN0T/tb3BcfHAqXl
65WmcqfeELdNYyQdd2FTK7t9UXWDVKv0v/C0GXSnZxGO1pWLv7brEF2gikEXucum
zRZiQLA+EZ5jLtkRJ/Vhe15IDpzspvsZKoe3BTAIICe0AYScy80rZHNW1DOdW8JK
IJd9mn2itG78WqiGZH5QdIB3KvkXYpRMRyTlVlqQvkcby8Q2ineGU2ibeao6b3AH
LtcmNdg1IU4QaatEtblgrLw/7CSoUNnnYMNDU7S1zXcwEnvjiqCzt482oPli5q+c
kvAaju0Xgig8M9u8Paer
=V7TO
-END PGP SIGNATURE-

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

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

[Ryan Scharer]

Thanks! That comment was an enormous help. I was able to achieve what I
wanted just by setting metadata-complete to true. I had previously assumed
that that would disable jar scanning. Instead it simply disables
web-fragment scanning.

What still confuses me is why the only mechanism provided by the spec to
enable or disable scanning of a particular jar is by referring to the
name of a related web-fragment. What about jars that have annotations but
no web-fragment? Likely I'm still misunderstanding something fundamental.

Anyway, I now have the functionality I need. Thanks again for the
assistance.

-R

On Fri, Feb 13, 2015 at 2:54 PM, Mark Thomas ma...@apache.org wrote:

 On 13/02/2015 18:49, Ryan Scharer wrote:
  Chris,
 
  I share your misgivings about magic, though if it exhibits
 well-documented
  and predictable behavior I usually just shrug and go along with it. Sadly
  that doesn't seem to be the case here.

 It is documented but I'd agree it could be better documented.

  I'll set aside some time to step
  through the Tomcat code to try to figure this out,

 Save yourself the effort and read this from line ~1085.


 http://svn.eu.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?view=annotate

 Mark

  though in the meantime
  my best bet may be to repackage the 3rd party jar minus its web-fragment.
 
  -R
 
  On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz 
  ch...@christopherschultz.net wrote:
 
  Ryan,
 
  On 2/13/15 12:59 PM, Ryan Scharer wrote:
  I'm not sure if this is a bug or not, but I can't find any relevant
   information in the spec to suggest the behavior is expected.
 
  There's a web-fragment in my classpath that I'd like to skip. The
  only way to accomplish this that I know of is to put an
  absolute-ordering stanza in my web.xml and omit an others/.
  Though this has the desired effect of skipping the web-fragment I
  don't want, it has the very negative side effect that my
  ServletContainerInitializer doesn't get handed all instances of
  WebApplicationInitializer anymore, despite its @HandlesTypes
  annotation. If I add the others/, classpath scanning works fine,
  but the undesired web-fragment comes back. I've tested this in the
  latest 7.x and 8.x Tomcat releases.
 
  This begs two questions:
 
  1. Why does specifying an absolute-ordering without an others/
  kill classpath scanning, or at least the part of Tomcat
  responsible for finding types specified by @HandlesTypes and giving
  it to interested parties? 2. Is there an alternate way to skip a
  web-fragment, short of ripping it out of the jar, which I really
  don't want to do?
 
  It's unclear to me why absolute-ordering affects JAR scanning...
  absolute-ordering should affect only the processing of web-fragments.
  The Tomcat documentation for absolute-ordering makes it sounds like
  you have to mention a JAR name while the spec documentation makes it
  seem like you need to use the name element from web-fragments that
  are detected in JAR files.
 
  The whole thing is a can of worms, honestly.
 
  As for your inability to skip a web-fragment... that seems
  straightforward to me: if you have others/ specified, then
  everything else will be processed in that order, including the
  web-fragment you don't want. There does not seem to be a way to
  blacklist a web-fragment short of completely removing it from your
  project's libraries.
 
  But the fact that the lack of others causes Tomcat to fail to do JAR
  scanning is surprising to me. I tend to prefer explicit configuration
  over all this scanning-related magic so I'm afraid I don't have any
  experience with this kind of thing. In fact, it's this kind of
  foolishness that makes me stick with explicitly-specified
  configurations instead of magic ones. Good luck figuring out how the
  magic works / is supposed to work!
 
  -chris
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 


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

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

[Mark Thomas]

On 15/02/2015 17:42, Ryan Scharer wrote:
 Thanks! That comment was an enormous help. I was able to achieve what I
 wanted just by setting metadata-complete to true. I had previously assumed
 that that would disable jar scanning. Instead it simply disables
 web-fragment scanning.
 
 What still confuses me is why the only mechanism provided by the spec to
 enable or disable scanning of a particular jar is by referring to the
 name of a related web-fragment. What about jars that have annotations but
 no web-fragment?

Tomcat will give these a name equal to the name of the JAR file so you
can use it in ordering. That is a Tomcat specific feature.

 Likely I'm still misunderstanding something fundamental.

Probably not. There are some functionality gaps in the way pluggability
was designed and this is essentially one of them.

 Anyway, I now have the functionality I need. Thanks again for the
 assistance.

Great. That is the main thing.

Mark


 
 -R
 
 On Fri, Feb 13, 2015 at 2:54 PM, Mark Thomas ma...@apache.org wrote:
 
 On 13/02/2015 18:49, Ryan Scharer wrote:
 Chris,

 I share your misgivings about magic, though if it exhibits
 well-documented
 and predictable behavior I usually just shrug and go along with it. Sadly
 that doesn't seem to be the case here.

 It is documented but I'd agree it could be better documented.

  I'll set aside some time to step
 through the Tomcat code to try to figure this out,

 Save yourself the effort and read this from line ~1085.


 http://svn.eu.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?view=annotate

 Mark

 though in the meantime
 my best bet may be to repackage the 3rd party jar minus its web-fragment.

 -R

 On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz 
 ch...@christopherschultz.net wrote:

 Ryan,

 On 2/13/15 12:59 PM, Ryan Scharer wrote:
 I'm not sure if this is a bug or not, but I can't find any relevant
  information in the spec to suggest the behavior is expected.

 There's a web-fragment in my classpath that I'd like to skip. The
 only way to accomplish this that I know of is to put an
 absolute-ordering stanza in my web.xml and omit an others/.
 Though this has the desired effect of skipping the web-fragment I
 don't want, it has the very negative side effect that my
 ServletContainerInitializer doesn't get handed all instances of
 WebApplicationInitializer anymore, despite its @HandlesTypes
 annotation. If I add the others/, classpath scanning works fine,
 but the undesired web-fragment comes back. I've tested this in the
 latest 7.x and 8.x Tomcat releases.

 This begs two questions:

 1. Why does specifying an absolute-ordering without an others/
 kill classpath scanning, or at least the part of Tomcat
 responsible for finding types specified by @HandlesTypes and giving
 it to interested parties? 2. Is there an alternate way to skip a
 web-fragment, short of ripping it out of the jar, which I really
 don't want to do?

 It's unclear to me why absolute-ordering affects JAR scanning...
 absolute-ordering should affect only the processing of web-fragments.
 The Tomcat documentation for absolute-ordering makes it sounds like
 you have to mention a JAR name while the spec documentation makes it
 seem like you need to use the name element from web-fragments that
 are detected in JAR files.

 The whole thing is a can of worms, honestly.

 As for your inability to skip a web-fragment... that seems
 straightforward to me: if you have others/ specified, then
 everything else will be processed in that order, including the
 web-fragment you don't want. There does not seem to be a way to
 blacklist a web-fragment short of completely removing it from your
 project's libraries.

 But the fact that the lack of others causes Tomcat to fail to do JAR
 scanning is surprising to me. I tend to prefer explicit configuration
 over all this scanning-related magic so I'm afraid I don't have any
 experience with this kind of thing. In fact, it's this kind of
 foolishness that makes me stick with explicitly-specified
 configurations instead of magic ones. Good luck figuring out how the
 magic works / is supposed to work!

 -chris

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





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


 


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

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ryan,

On 2/13/15 12:59 PM, Ryan Scharer wrote:
 I'm not sure if this is a bug or not, but I can't find any relevant
  information in the spec to suggest the behavior is expected.
 
 There's a web-fragment in my classpath that I'd like to skip. The 
 only way to accomplish this that I know of is to put an 
 absolute-ordering stanza in my web.xml and omit an others/. 
 Though this has the desired effect of skipping the web-fragment I 
 don't want, it has the very negative side effect that my 
 ServletContainerInitializer doesn't get handed all instances of 
 WebApplicationInitializer anymore, despite its @HandlesTypes 
 annotation. If I add the others/, classpath scanning works fine, 
 but the undesired web-fragment comes back. I've tested this in the 
 latest 7.x and 8.x Tomcat releases.
 
 This begs two questions:
 
 1. Why does specifying an absolute-ordering without an others/ 
 kill classpath scanning, or at least the part of Tomcat
 responsible for finding types specified by @HandlesTypes and giving
 it to interested parties? 2. Is there an alternate way to skip a 
 web-fragment, short of ripping it out of the jar, which I really 
 don't want to do?

It's unclear to me why absolute-ordering affects JAR scanning...
absolute-ordering should affect only the processing of web-fragments.
The Tomcat documentation for absolute-ordering makes it sounds like
you have to mention a JAR name while the spec documentation makes it
seem like you need to use the name element from web-fragments that
are detected in JAR files.

The whole thing is a can of worms, honestly.

As for your inability to skip a web-fragment... that seems
straightforward to me: if you have others/ specified, then
everything else will be processed in that order, including the
web-fragment you don't want. There does not seem to be a way to
blacklist a web-fragment short of completely removing it from your
project's libraries.

But the fact that the lack of others causes Tomcat to fail to do JAR
scanning is surprising to me. I tend to prefer explicit configuration
over all this scanning-related magic so I'm afraid I don't have any
experience with this kind of thing. In fact, it's this kind of
foolishness that makes me stick with explicitly-specified
configurations instead of magic ones. Good luck figuring out how the
magic works / is supposed to work!

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU3j/eAAoJEBzwKT+lPKRYRa8P/0sf9hPQmY5Ivd4lQ5jJGzJy
6u/mdQbNclsbMBFBGDReq0VJFTsKCqd857VpaxIdQmbCeHLc94+zDvGHYNpHddAw
MjztFPIXkrLqahc1dWwztMQWQGFrOcFM5KmUeGWbZynHUirJknOlc/gx9xQbD61O
a46h6iL1Dn3okBnGBIbmuWVmg1dyC2Pvg+qLgO4etfIaeuvSds2XXW6OgmnyWmM5
neBRnnruFixDtz5xmiBArbRgqnVa59xVnUkvKfUPqtI3MQWq9X8a5/f5rXgfohMd
BpgV/yPf6gm9fuFPVPSPLJof0UvenxeYiGMW+1BjIpi3Qt5Me4Ba8CYrmFXf2r2d
g5flulx8k+9uZvLlE9vW8xKe+S4OK8vUif5PTcUv7oMTT3ASo1uvMb3Z0/WxNHvu
NW/9eGIgGshOENfHu59+bBsPQhu/dsNdvwrdGXYlELjx3X64pCYLkdQr5ZTNBZar
UOiIiLpUNgeUC0L10XC205e116G1P3ofVQqo5PZiFntu8sF9AUp+YL/6I3OQ6Q8B
wDej78On3ZDmkJAkKZKgVaeAOXY64FF2B5T6QayPABJ/z+LU/DLP8zySLXY9o6I1
FGZoweHmM0cWX3VpuyN167Hd5PEJyjlMpy6NZ+qMbWf3LnQvrrx15vpgd6cypm7B
5Uolv99PqOrAJOE+F/NV
=sw5S
-END PGP SIGNATURE-

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

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

[Ryan Scharer]

Chris,

I share your misgivings about magic, though if it exhibits well-documented
and predictable behavior I usually just shrug and go along with it. Sadly
that doesn't seem to be the case here. I'll set aside some time to step
through the Tomcat code to try to figure this out, though in the meantime
my best bet may be to repackage the 3rd party jar minus its web-fragment.

-R

On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Ryan,

 On 2/13/15 12:59 PM, Ryan Scharer wrote:
  I'm not sure if this is a bug or not, but I can't find any relevant
   information in the spec to suggest the behavior is expected.
 
  There's a web-fragment in my classpath that I'd like to skip. The
  only way to accomplish this that I know of is to put an
  absolute-ordering stanza in my web.xml and omit an others/.
  Though this has the desired effect of skipping the web-fragment I
  don't want, it has the very negative side effect that my
  ServletContainerInitializer doesn't get handed all instances of
  WebApplicationInitializer anymore, despite its @HandlesTypes
  annotation. If I add the others/, classpath scanning works fine,
  but the undesired web-fragment comes back. I've tested this in the
  latest 7.x and 8.x Tomcat releases.
 
  This begs two questions:
 
  1. Why does specifying an absolute-ordering without an others/
  kill classpath scanning, or at least the part of Tomcat
  responsible for finding types specified by @HandlesTypes and giving
  it to interested parties? 2. Is there an alternate way to skip a
  web-fragment, short of ripping it out of the jar, which I really
  don't want to do?

 It's unclear to me why absolute-ordering affects JAR scanning...
 absolute-ordering should affect only the processing of web-fragments.
 The Tomcat documentation for absolute-ordering makes it sounds like
 you have to mention a JAR name while the spec documentation makes it
 seem like you need to use the name element from web-fragments that
 are detected in JAR files.

 The whole thing is a can of worms, honestly.

 As for your inability to skip a web-fragment... that seems
 straightforward to me: if you have others/ specified, then
 everything else will be processed in that order, including the
 web-fragment you don't want. There does not seem to be a way to
 blacklist a web-fragment short of completely removing it from your
 project's libraries.

 But the fact that the lack of others causes Tomcat to fail to do JAR
 scanning is surprising to me. I tend to prefer explicit configuration
 over all this scanning-related magic so I'm afraid I don't have any
 experience with this kind of thing. In fact, it's this kind of
 foolishness that makes me stick with explicitly-specified
 configurations instead of magic ones. Good luck figuring out how the
 magic works / is supposed to work!

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org

 iQIcBAEBCAAGBQJU3j/eAAoJEBzwKT+lPKRYRa8P/0sf9hPQmY5Ivd4lQ5jJGzJy
 6u/mdQbNclsbMBFBGDReq0VJFTsKCqd857VpaxIdQmbCeHLc94+zDvGHYNpHddAw
 MjztFPIXkrLqahc1dWwztMQWQGFrOcFM5KmUeGWbZynHUirJknOlc/gx9xQbD61O
 a46h6iL1Dn3okBnGBIbmuWVmg1dyC2Pvg+qLgO4etfIaeuvSds2XXW6OgmnyWmM5
 neBRnnruFixDtz5xmiBArbRgqnVa59xVnUkvKfUPqtI3MQWq9X8a5/f5rXgfohMd
 BpgV/yPf6gm9fuFPVPSPLJof0UvenxeYiGMW+1BjIpi3Qt5Me4Ba8CYrmFXf2r2d
 g5flulx8k+9uZvLlE9vW8xKe+S4OK8vUif5PTcUv7oMTT3ASo1uvMb3Z0/WxNHvu
 NW/9eGIgGshOENfHu59+bBsPQhu/dsNdvwrdGXYlELjx3X64pCYLkdQr5ZTNBZar
 UOiIiLpUNgeUC0L10XC205e116G1P3ofVQqo5PZiFntu8sF9AUp+YL/6I3OQ6Q8B
 wDej78On3ZDmkJAkKZKgVaeAOXY64FF2B5T6QayPABJ/z+LU/DLP8zySLXY9o6I1
 FGZoweHmM0cWX3VpuyN167Hd5PEJyjlMpy6NZ+qMbWf3LnQvrrx15vpgd6cypm7B
 5Uolv99PqOrAJOE+F/NV
 =sw5S
 -END PGP SIGNATURE-

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

Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

[Ryan Scharer]

Hey folks,

I'm not sure if this is a bug or not, but I can't find any relevant
information in the spec to suggest the behavior is expected.

There's a web-fragment in my classpath that I'd like to skip. The only way
to accomplish this that I know of is to put an absolute-ordering stanza
in my web.xml and omit an others/. Though this has the desired effect of
skipping the web-fragment I don't want, it has the very negative side
effect that my ServletContainerInitializer doesn't get handed all instances
of WebApplicationInitializer anymore, despite its @HandlesTypes annotation.
If I add the others/, classpath scanning works fine, but the undesired
web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat
releases.


This begs two questions:

   1. Why does specifying an absolute-ordering without an others/ kill
   classpath scanning, or at least the part of Tomcat responsible for finding
   types specified by @HandlesTypes and giving it to interested parties?
   2. Is there an alternate way to skip a web-fragment, short of ripping it
   out of the jar, which I really don't want to do?

Thanks!

-Ryan

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

[Mark Thomas]

On 13/02/2015 17:59, Ryan Scharer wrote:
 Hey folks,
 
 I'm not sure if this is a bug or not, but I can't find any relevant
 information in the spec to suggest the behavior is expected.
 
 There's a web-fragment in my classpath that I'd like to skip. The only way
 to accomplish this that I know of is to put an absolute-ordering stanza
 in my web.xml and omit an others/. Though this has the desired effect of
 skipping the web-fragment I don't want, it has the very negative side
 effect that my ServletContainerInitializer doesn't get handed all instances
 of WebApplicationInitializer anymore, despite its @HandlesTypes annotation.
 If I add the others/, classpath scanning works fine, but the undesired
 web-fragment comes back. I've tested this in the latest 7.x and 8.x Tomcat
 releases.
 
 
 This begs two questions:
 
1. Why does specifying an absolute-ordering without an others/ kill
classpath scanning, or at least the part of Tomcat responsible for finding
types specified by @HandlesTypes and giving it to interested parties?

Because the Servlet spec says so.

Servlet 3.1, section 8.2.2, 1. d. (page 8-73)

... Irrespective of the setting of metadata-complete, jars excluded by
absolute-ordering elements are not scanned for classes to be handled
by any ServletContainerInitializer.

2. Is there an alternate way to skip a web-fragment, short of ripping it
out of the jar, which I really don't want to do?

There is no way I am aware of that allows you to skip the
web-fragment.xml but still scan the JAR for SCIs and @HandlesTypes
matches to those SCIs.

Depending on what is in the web-frgament.xml you might be able to put
entries in the main web.xml to override them.

Mark


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

Re: Why does 'absolute-ordering' in web.xml without 'others' kill classpath scanning?

[Mark Thomas]

On 13/02/2015 18:49, Ryan Scharer wrote:
 Chris,
 
 I share your misgivings about magic, though if it exhibits well-documented
 and predictable behavior I usually just shrug and go along with it. Sadly
 that doesn't seem to be the case here.

It is documented but I'd agree it could be better documented.

 I'll set aside some time to step
 through the Tomcat code to try to figure this out,

Save yourself the effort and read this from line ~1085.

http://svn.eu.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/startup/ContextConfig.java?view=annotate

Mark

 though in the meantime
 my best bet may be to repackage the 3rd party jar minus its web-fragment.
 
 -R
 
 On Fri, Feb 13, 2015 at 1:18 PM, Christopher Schultz 
 ch...@christopherschultz.net wrote:
 
 Ryan,
 
 On 2/13/15 12:59 PM, Ryan Scharer wrote:
 I'm not sure if this is a bug or not, but I can't find any relevant
  information in the spec to suggest the behavior is expected.

 There's a web-fragment in my classpath that I'd like to skip. The
 only way to accomplish this that I know of is to put an
 absolute-ordering stanza in my web.xml and omit an others/.
 Though this has the desired effect of skipping the web-fragment I
 don't want, it has the very negative side effect that my
 ServletContainerInitializer doesn't get handed all instances of
 WebApplicationInitializer anymore, despite its @HandlesTypes
 annotation. If I add the others/, classpath scanning works fine,
 but the undesired web-fragment comes back. I've tested this in the
 latest 7.x and 8.x Tomcat releases.

 This begs two questions:

 1. Why does specifying an absolute-ordering without an others/
 kill classpath scanning, or at least the part of Tomcat
 responsible for finding types specified by @HandlesTypes and giving
 it to interested parties? 2. Is there an alternate way to skip a
 web-fragment, short of ripping it out of the jar, which I really
 don't want to do?
 
 It's unclear to me why absolute-ordering affects JAR scanning...
 absolute-ordering should affect only the processing of web-fragments.
 The Tomcat documentation for absolute-ordering makes it sounds like
 you have to mention a JAR name while the spec documentation makes it
 seem like you need to use the name element from web-fragments that
 are detected in JAR files.
 
 The whole thing is a can of worms, honestly.
 
 As for your inability to skip a web-fragment... that seems
 straightforward to me: if you have others/ specified, then
 everything else will be processed in that order, including the
 web-fragment you don't want. There does not seem to be a way to
 blacklist a web-fragment short of completely removing it from your
 project's libraries.
 
 But the fact that the lack of others causes Tomcat to fail to do JAR
 scanning is surprising to me. I tend to prefer explicit configuration
 over all this scanning-related magic so I'm afraid I don't have any
 experience with this kind of thing. In fact, it's this kind of
 foolishness that makes me stick with explicitly-specified
 configurations instead of magic ones. Good luck figuring out how the
 magic works / is supposed to work!
 
 -chris

 -
 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: META-INF/context.xml and deploy issue (web.xml removed?)

[martin....@sfr.fr]

Hi Mark, and thank you for your answer,

Mark wrote:
 
 undeloy - means stop the app and remove any references to it from
 CATALINA_BASE/conf/engine/host and CATALINA_BASE/webapps

OK

 
 deploy - means tell Tomcat about the app and start it. This may reesult
 in files being copied to CATALINA_BASE/conf/engine/host and/or
 CATALINA_BASE/webapps

Sorry but copied from where if it has been removed during undeploy step
? (there is no war file anywhere here).


-- 
Martin

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

Re: META-INF/context.xml and deploy issue (web.xml removed?)

[David kerber]

On 12/8/2014 6:31 AM, martin@sfr.fr wrote:

Hi Mark, and thank you for your answer,

Mark wrote:


undeloy - means stop the app and remove any references to it from
CATALINA_BASE/conf/engine/host and CATALINA_BASE/webapps


OK



deploy - means tell Tomcat about the app and start it. This may reesult
in files being copied to CATALINA_BASE/conf/engine/host and/or
CATALINA_BASE/webapps


Sorry but copied from where if it has been removed during undeploy step
? (there is no war file anywhere here).


From what Mark said, undeploy doesn't remove the app's directory and 
file structure, just the references he lists above.  However, I think 
he's talking in general, rather than in the specific case of undeploying 
your app and then deploying it.



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

Re: META-INF/context.xml and deploy issue (web.xml removed?)

[m...@ow2.org]

Hi,

Is anyone can help me to find out what I am missing ?
Thanks

Le 02/12/2014 10:36, m...@ow2.org a écrit :
 Hello,

 I'm facing an issue with tomcat 6. In order to setup a JDNI, we
 added a context.xml file to our application (XWiki) in the
 already-deployed folder webapps/xwiki/META-INF/ and configured the
 existing webapps/xwiki/WEB-INF/web.xml accordingly.

 update of web.xml triggered the app reload which is expected.

 At this point I wanted to adjust the database configuration, ie by
 modifying webapps/xwiki/META-INF/context.xml. When I do this the
 changes are not taken into account because the file
 Catalina/localhost/xwiki.xml is not overwritten by Tomcat.

 The solution that came into my mind has been to force Tomcat to
 update the file bt deleting Catalina/localhost/xwiki.xml - which
 has indeed make Tomcat undeploy and deploy the app again.

 Here are my questions: 1) As there is no war file involved, what
 does undeploy and deploy means ? What is being done exactly ?

 2) Why is the file webapps/xwiki/WEB-INF/web.xml is missing, after
 I remove xwiki.xml and the app is redeployed ? (no web.xml = no
 deployment so at the moment I have to manually restore a backup of
 this file)

 Thanks !




-- 
Martin

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

Re: META-INF/context.xml and deploy issue (web.xml removed?)

[Jose María Zaragoza]

2014-12-04 9:48 GMT+01:00 m...@ow2.org m...@ow2.org:
 Hi,

 Is anyone can help me to find out what I am missing ?
 Thanks

Hi:

I asked a similar question time ago

http://grokbase.com/t/tomcat/users/13chhkj0qx/modify-content-in-meta-inf-context-xml

I hope it helps you

Regards





 Le 02/12/2014 10:36, m...@ow2.org a écrit :
 Hello,

 I'm facing an issue with tomcat 6. In order to setup a JDNI, we
 added a context.xml file to our application (XWiki) in the
 already-deployed folder webapps/xwiki/META-INF/ and configured the
 existing webapps/xwiki/WEB-INF/web.xml accordingly.

 update of web.xml triggered the app reload which is expected.

 At this point I wanted to adjust the database configuration, ie by
 modifying webapps/xwiki/META-INF/context.xml. When I do this the
 changes are not taken into account because the file
 Catalina/localhost/xwiki.xml is not overwritten by Tomcat.

 The solution that came into my mind has been to force Tomcat to
 update the file bt deleting Catalina/localhost/xwiki.xml - which
 has indeed make Tomcat undeploy and deploy the app again.

 Here are my questions: 1) As there is no war file involved, what
 does undeploy and deploy means ? What is being done exactly ?

 2) Why is the file webapps/xwiki/WEB-INF/web.xml is missing, after
 I remove xwiki.xml and the app is redeployed ? (no web.xml = no
 deployment so at the moment I have to manually restore a backup of
 this file)

 Thanks !




 --
 Martin

 -
 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