Re: Multipart form submission does not work over SSL HTTP2 on Tomcat 9

[Violeta Georgieva]

Hi,

2016-03-19 23:21 GMT+02:00 Ajay Verma :
>
> Hello,
> I'm trying to get multipart forms working in Tomcat 9 over HTTP2 (with
TLS enabled).
>
> The SSL Connector configuration in server.xml (Tomcat 9) is given
below
> 
> 
>  certificateFile="conf/2_toeflmadeeasy.com.crt"  />
>   Multipart form submission does not work (the form
variable values are not retrieved on server in the servlet) with above
connector.The sample multipart form html code is given below
> 
> File 1:
> File 2:
> 
> 
> I am trying to get form parameters by using the
getParameter("form_submission_type") method on HttpServletRequest, and it
returns null under HTTP2. If I remove the line ) it works. But now I
am not on HTTP2.
>
> Anyone have any ideas how I can get it to work on HTTP2?

Is it possible for you to test your configuration with the manager
application that comes with Tomcat distribution?
It uses multipart.

I tested it on my side and the manager application is working with HTTP/2
and multipart.

Regards,
Violeta

> Thanks in advance for any suggestions and comments.
> Ajay

Re: "Distinct and non-overlapping" context roots

[Paul Benedict]

By the way, I should mention that with Apache AJP in front of a container,
this kind of partial matching stuff gets really interesting. :-)

Cheers,
Paul

On Tue, Mar 22, 2016 at 11:47 AM, Paul Benedict 
wrote:

> Yes, I gave them the same example I used here. They confirmed it is
> "overlapping". Here is the example again:
>
> /context/something <-- context is /context
> /context/something/somethingelse <-- context is /context/something
>
> Cheers,
> Paul
>
> On Tue, Mar 22, 2016 at 11:34 AM, David kerber 
> wrote:
>
>> On 3/22/2016 12:31 PM, Paul Benedict wrote:
>>
>>> Mark, I did get some clarification. Thanks for asking.
>>>
>>> The EE spec states an "application" may not have overlapping context
>>> roots.
>>> I got clarification that "application" refers only to an EAR. Therefore,
>>> an
>>> EE server should be validating this condition.
>>>
>>
>> I've been following this thread just a bit, and have a question about
>> it:  what does "overlapping" mean to them?  To me, if one was a subset
>> (completely contained inside) of another one, that would not be
>> overlapping.  Overlapping would imply that two apps would both match some
>> URLs, while other URLs would only match one or the other.  Is that how they
>> define overlapping?
>>
>>

Re: Multipart form submission does not work over SSL HTTP2 on Tomcat 9

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark,

On 3/19/16 9:18 PM, Mark Olsson wrote:
> On Sat, Mar 19, 2016 at 2:21 PM, Ajay Verma
>  wrote:
> 
>> Hello, I'm trying to get multipart forms working in Tomcat 9 over
>> HTTP2 (with TLS enabled).
>> 
>> The SSL Connector configuration in server.xml (Tomcat 9) is
>> given below> protocol="org.apache.coyote.http11.Http11AprProtocol"
>> maxThreads="150" SSLEnabled="true"> > className="org.apache.coyote.http2.Http2Protocol" /> 
>>  > certificateKeyFile="conf/toeflssl.key" 
>> certificateFile="conf/2_toeflmadeeasy.com.crt"  /> 
>>   Multipart form submission does not work (the
>> form variable values are not retrieved on server in the servlet)
>> with above connector.The sample multipart form html code is given
>> below> enctype="multipart/form-data"> > id="form_submission_type" name="form_submission_type" 
>> value="test"> File 1:> size="20" value=""> File 2:> name="file2" size="20" value=""> > value="Submit" name="submit">  I am trying to get form
>> parameters by using the getParameter("form_submission_type")
>> method on HttpServletRequest, and it returns null under HTTP2. If
>> I remove the line > className="org.apache.coyote.http2.Http2Protocol" />) it works.
>> But now I am not on HTTP2.
>> 
>> Anyone have any ideas how I can get it to work on HTTP2? Thanks
>> in advance for any suggestions and comments. Ajay
>> 
> 
> I can't speak for Tomcat 9, but for T8 getParameter() won't work on
> a multi-part form.  I vaguely recall there's a Tomcat way of
> getting the parameters, but I ended up using Apache's FileUpload
> library which will generate a list of files and parameters for the
> request.  Though I have no idea if FileUpload will work with HTTP2
> or not.

If you are using servlet 3.0+, there's no reason to use a separate
file-upload library.

Use HttpServletRequest.getParts() and related API calls.

I'm not sure if this has anything to do with http2.

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

iEYEARECAAYFAlbxowMACgkQ9CaO5/Lv0PD5HwCgvtMzf8YX2pZ/9ZzxGPsVceDg
kQUAmgMoMbqhThf1u6O7Ja0rDWrygtEi
=jIxq
-END PGP SIGNATURE-

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

Re: "Distinct and non-overlapping" context roots

[Paul Benedict]

Yes, I gave them the same example I used here. They confirmed it is
"overlapping". Here is the example again:

/context/something <-- context is /context
/context/something/somethingelse <-- context is /context/something

Cheers,
Paul

On Tue, Mar 22, 2016 at 11:34 AM, David kerber  wrote:

> On 3/22/2016 12:31 PM, Paul Benedict wrote:
>
>> Mark, I did get some clarification. Thanks for asking.
>>
>> The EE spec states an "application" may not have overlapping context
>> roots.
>> I got clarification that "application" refers only to an EAR. Therefore,
>> an
>> EE server should be validating this condition.
>>
>
> I've been following this thread just a bit, and have a question about it:
> what does "overlapping" mean to them?  To me, if one was a subset
> (completely contained inside) of another one, that would not be
> overlapping.  Overlapping would imply that two apps would both match some
> URLs, while other URLs would only match one or the other.  Is that how they
> define overlapping?
>
>

Re: "Distinct and non-overlapping" context roots

[David kerber]

On 3/22/2016 12:31 PM, Paul Benedict wrote:

Mark, I did get some clarification. Thanks for asking.

The EE spec states an "application" may not have overlapping context roots.
I got clarification that "application" refers only to an EAR. Therefore, an
EE server should be validating this condition.


I've been following this thread just a bit, and have a question about 
it:  what does "overlapping" mean to them?  To me, if one was a subset 
(completely contained inside) of another one, that would not be 
overlapping.  Overlapping would imply that two apps would both match 
some URLs, while other URLs would only match one or the other.  Is that 
how they define overlapping?





So two inferences follow:
1) In the case of an EAR bundling a WAR that specifies the root context, no
other WAR can be allowed in the EAR since any other context would overlap
with the root context.
2) Without an EAR, there are no overlapping restrictions except for
(obviously) identical context roots.

And two extra pieces of information worth knowing:
a) Supposedly GlassFish imposes the "overlapping" restriction on the entire
application server, not just the EAR.
b) The specification doesn't prevent the slash character in the context
name, but I got the distinct impression that's something to fix in the
future.

Cheers,
Paul

On Tue, Mar 22, 2016 at 11:12 AM, Mark Thomas  wrote:


On 22/03/2016 15:57, Paul Benedict wrote:

FYI, the EE spec lead and Servlet spec lead consulted. They said I should
log a ticket against the Servlet specification on this matter. That is
something I think I shall do. I found some wording in the specification
that should likely have more detail.


Did you get any clarity on what the Java EE spec authours actually meant?

Mark



Cheers,
Paul

On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas 

wrote:



On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
ch...@christopherschultz.net> wrote:

Mark,

On 3/17/16 1:28 PM, Mark Thomas wrote:

On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict

 wrote:

This question is not about Tomcat per se, but it does affect it.

It's

really about the EE specification in regards to any servlet

container.

I'd
like to get professional opinions on this part of the specification.

I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph

3c:


The Deployer must... "Assign a context root for each web module
included in
the Java EE application. The context root is a relative name in the

web

namespace for the application. Each web module must be given a

distinct

and
non-overlapping name for its context root."

So given this scenario:
/context/something <-- context is /context
/context/something/somethingelse <-- context is /context/something

The specification puts no limitations on the context root character

set

(so
it can include a slash). With that said, would you consider these
"overlapping" contexts? I noticed one application server supporting
this
paradigm without issue, but it seems like a violation of the
specification.
Please advise.

Also, since Tomcat doesn't support "applications" (EAR?), how should
the
specification be interpreted in the absence of that artifact?

[1]
http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/

Cheers,
Paul


That requirement makes no sense as I understand it. You always have

overlapping context paths because of the ROOT context.


I think this is one for the EG to clarify what they meant.

It is also worth noting that the servlet spec explicitly states thst
requests are matched against the longest matching context path.


How can Tomcat tell the difference between requests to:

/webappA/someresource/foo (which does exist in webappA path=/webappA)
and
/webappA/someresource/foo (which does not exist in webappB
path="/webappA/someresource)

In the above case, Tomcat should choose the second, because
/webappA/someresource matches webappB's context path, which is longer
than webappA's context path, right?


Correct. That should result in a 404.

We've use this trick to return something useful if a user requests the
docs Web app when it isn't installed.

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: "Distinct and non-overlapping" context roots

[Paul Benedict]

Mark, I did get some clarification. Thanks for asking.

The EE spec states an "application" may not have overlapping context roots.
I got clarification that "application" refers only to an EAR. Therefore, an
EE server should be validating this condition.

So two inferences follow:
1) In the case of an EAR bundling a WAR that specifies the root context, no
other WAR can be allowed in the EAR since any other context would overlap
with the root context.
2) Without an EAR, there are no overlapping restrictions except for
(obviously) identical context roots.

And two extra pieces of information worth knowing:
a) Supposedly GlassFish imposes the "overlapping" restriction on the entire
application server, not just the EAR.
b) The specification doesn't prevent the slash character in the context
name, but I got the distinct impression that's something to fix in the
future.

Cheers,
Paul

On Tue, Mar 22, 2016 at 11:12 AM, Mark Thomas  wrote:

> On 22/03/2016 15:57, Paul Benedict wrote:
> > FYI, the EE spec lead and Servlet spec lead consulted. They said I should
> > log a ticket against the Servlet specification on this matter. That is
> > something I think I shall do. I found some wording in the specification
> > that should likely have more detail.
>
> Did you get any clarity on what the Java EE spec authours actually meant?
>
> Mark
>
> >
> > Cheers,
> > Paul
> >
> > On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas 
> wrote:
> >
> >> On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
> >> ch...@christopherschultz.net> wrote:
> >>> Mark,
> >>>
> >>> On 3/17/16 1:28 PM, Mark Thomas wrote:
>  On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
> >>>  wrote:
> > This question is not about Tomcat per se, but it does affect it.
> >>> It's
> > really about the EE specification in regards to any servlet
> >>> container.
> > I'd
> > like to get professional opinions on this part of the specification.
> >
> > I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
> >>> 3c:
> >
> > The Deployer must... "Assign a context root for each web module
> > included in
> > the Java EE application. The context root is a relative name in the
> >>> web
> > namespace for the application. Each web module must be given a
> >>> distinct
> > and
> > non-overlapping name for its context root."
> >
> > So given this scenario:
> > /context/something <-- context is /context
> > /context/something/somethingelse <-- context is /context/something
> >
> > The specification puts no limitations on the context root character
> >>> set
> > (so
> > it can include a slash). With that said, would you consider these
> > "overlapping" contexts? I noticed one application server supporting
> > this
> > paradigm without issue, but it seems like a violation of the
> > specification.
> > Please advise.
> >
> > Also, since Tomcat doesn't support "applications" (EAR?), how should
> > the
> > specification be interpreted in the absence of that artifact?
> >
> > [1]
> > http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
> >
> > Cheers,
> > Paul
> 
>  That requirement makes no sense as I understand it. You always have
> >>> overlapping context paths because of the ROOT context.
> 
>  I think this is one for the EG to clarify what they meant.
> 
>  It is also worth noting that the servlet spec explicitly states thst
>  requests are matched against the longest matching context path.
> >>>
> >>> How can Tomcat tell the difference between requests to:
> >>>
> >>> /webappA/someresource/foo (which does exist in webappA path=/webappA)
> >>> and
> >>> /webappA/someresource/foo (which does not exist in webappB
> >>> path="/webappA/someresource)
> >>>
> >>> In the above case, Tomcat should choose the second, because
> >>> /webappA/someresource matches webappB's context path, which is longer
> >>> than webappA's context path, right?
> >>
> >> Correct. That should result in a 404.
> >>
> >> We've use this trick to return something useful if a user requests the
> >> docs Web app when it isn't installed.
> >>
> >> 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: "Distinct and non-overlapping" context roots

[Mark Thomas]

On 22/03/2016 15:57, Paul Benedict wrote:
> FYI, the EE spec lead and Servlet spec lead consulted. They said I should
> log a ticket against the Servlet specification on this matter. That is
> something I think I shall do. I found some wording in the specification
> that should likely have more detail.

Did you get any clarity on what the Java EE spec authours actually meant?

Mark

> 
> Cheers,
> Paul
> 
> On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas  wrote:
> 
>> On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>> Mark,
>>>
>>> On 3/17/16 1:28 PM, Mark Thomas wrote:
 On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
>>>  wrote:
> This question is not about Tomcat per se, but it does affect it.
>>> It's
> really about the EE specification in regards to any servlet
>>> container.
> I'd
> like to get professional opinions on this part of the specification.
>
> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
>>> 3c:
>
> The Deployer must... "Assign a context root for each web module
> included in
> the Java EE application. The context root is a relative name in the
>>> web
> namespace for the application. Each web module must be given a
>>> distinct
> and
> non-overlapping name for its context root."
>
> So given this scenario:
> /context/something <-- context is /context
> /context/something/somethingelse <-- context is /context/something
>
> The specification puts no limitations on the context root character
>>> set
> (so
> it can include a slash). With that said, would you consider these
> "overlapping" contexts? I noticed one application server supporting
> this
> paradigm without issue, but it seems like a violation of the
> specification.
> Please advise.
>
> Also, since Tomcat doesn't support "applications" (EAR?), how should
> the
> specification be interpreted in the absence of that artifact?
>
> [1]
> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>
> Cheers,
> Paul

 That requirement makes no sense as I understand it. You always have
>>> overlapping context paths because of the ROOT context.

 I think this is one for the EG to clarify what they meant.

 It is also worth noting that the servlet spec explicitly states thst
 requests are matched against the longest matching context path.
>>>
>>> How can Tomcat tell the difference between requests to:
>>>
>>> /webappA/someresource/foo (which does exist in webappA path=/webappA)
>>> and
>>> /webappA/someresource/foo (which does not exist in webappB
>>> path="/webappA/someresource)
>>>
>>> In the above case, Tomcat should choose the second, because
>>> /webappA/someresource matches webappB's context path, which is longer
>>> than webappA's context path, right?
>>
>> Correct. That should result in a 404.
>>
>> We've use this trick to return something useful if a user requests the
>> docs Web app when it isn't installed.
>>
>> 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: "Distinct and non-overlapping" context roots

[Paul Benedict]

FYI, the EE spec lead and Servlet spec lead consulted. They said I should
log a ticket against the Servlet specification on this matter. That is
something I think I shall do. I found some wording in the specification
that should likely have more detail.

Cheers,
Paul

On Tue, Mar 22, 2016 at 10:49 AM, Mark Thomas  wrote:

> On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
> >Mark,
> >
> >On 3/17/16 1:28 PM, Mark Thomas wrote:
> >> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
> > wrote:
> >>> This question is not about Tomcat per se, but it does affect it.
> >It's
> >>> really about the EE specification in regards to any servlet
> >container.
> >>> I'd
> >>> like to get professional opinions on this part of the specification.
> >>>
> >>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
> >3c:
> >>>
> >>> The Deployer must... "Assign a context root for each web module
> >>> included in
> >>> the Java EE application. The context root is a relative name in the
> >web
> >>> namespace for the application. Each web module must be given a
> >distinct
> >>> and
> >>> non-overlapping name for its context root."
> >>>
> >>> So given this scenario:
> >>> /context/something <-- context is /context
> >>> /context/something/somethingelse <-- context is /context/something
> >>>
> >>> The specification puts no limitations on the context root character
> >set
> >>> (so
> >>> it can include a slash). With that said, would you consider these
> >>> "overlapping" contexts? I noticed one application server supporting
> >>> this
> >>> paradigm without issue, but it seems like a violation of the
> >>> specification.
> >>> Please advise.
> >>>
> >>> Also, since Tomcat doesn't support "applications" (EAR?), how should
> >>> the
> >>> specification be interpreted in the absence of that artifact?
> >>>
> >>> [1]
> >>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
> >>>
> >>> Cheers,
> >>> Paul
> >>
> >> That requirement makes no sense as I understand it. You always have
> >overlapping context paths because of the ROOT context.
> >>
> >> I think this is one for the EG to clarify what they meant.
> >>
> >> It is also worth noting that the servlet spec explicitly states thst
> >> requests are matched against the longest matching context path.
> >
> >How can Tomcat tell the difference between requests to:
> >
> >/webappA/someresource/foo (which does exist in webappA path=/webappA)
> >and
> >/webappA/someresource/foo (which does not exist in webappB
> >path="/webappA/someresource)
> >
> >In the above case, Tomcat should choose the second, because
> >/webappA/someresource matches webappB's context path, which is longer
> >than webappA's context path, right?
>
> Correct. That should result in a 404.
>
> We've use this trick to return something useful if a user requests the
> docs Web app when it isn't installed.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: "Distinct and non-overlapping" context roots

[Mark Thomas]

On 22 March 2016 14:46:31 GMT+00:00, Christopher Schultz 
 wrote:
>Mark,
>
>On 3/17/16 1:28 PM, Mark Thomas wrote:
>> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict
> wrote:
>>> This question is not about Tomcat per se, but it does affect it.
>It's
>>> really about the EE specification in regards to any servlet
>container.
>>> I'd
>>> like to get professional opinions on this part of the specification.
>>>
>>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph
>3c:
>>>
>>> The Deployer must... "Assign a context root for each web module
>>> included in
>>> the Java EE application. The context root is a relative name in the
>web
>>> namespace for the application. Each web module must be given a
>distinct
>>> and
>>> non-overlapping name for its context root."
>>>
>>> So given this scenario:
>>> /context/something <-- context is /context
>>> /context/something/somethingelse <-- context is /context/something
>>>
>>> The specification puts no limitations on the context root character
>set
>>> (so
>>> it can include a slash). With that said, would you consider these
>>> "overlapping" contexts? I noticed one application server supporting
>>> this
>>> paradigm without issue, but it seems like a violation of the
>>> specification.
>>> Please advise.
>>>
>>> Also, since Tomcat doesn't support "applications" (EAR?), how should
>>> the
>>> specification be interpreted in the absence of that artifact?
>>>
>>> [1]
>>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>>>
>>> Cheers,
>>> Paul
>> 
>> That requirement makes no sense as I understand it. You always have
>overlapping context paths because of the ROOT context.
>> 
>> I think this is one for the EG to clarify what they meant.
>> 
>> It is also worth noting that the servlet spec explicitly states thst
>> requests are matched against the longest matching context path.
>
>How can Tomcat tell the difference between requests to:
>
>/webappA/someresource/foo (which does exist in webappA path=/webappA)
>and
>/webappA/someresource/foo (which does not exist in webappB
>path="/webappA/someresource)
>
>In the above case, Tomcat should choose the second, because
>/webappA/someresource matches webappB's context path, which is longer
>than webappA's context path, right?

Correct. That should result in a 404.

We've use this trick to return something useful if a user requests the docs Web 
app when it isn't installed.

Mark


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

Re: [SECURITY] CVE-2016-0763 Apache Tomcat Security Manager Bypass

[Chris Patterson]

El 22/02/2016 a las 06:23 a.m., Mark Thomas escribió:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CVE-2016-0763 Apache Tomcat Security Manager Bypass

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
- - Apache Tomcat 7.0.0 to 7.0.67
- - Apache Tomcat 8.0.0.RC1 to 8.0.30
- - Apache Tomcat 9.0.0.M1 to 9.0.0.M2

Description:
ResourceLinkFactory.setGlobalContext() is a public method and was
accessible by web applications running under a security manager
without any checks. This allowed a malicious web application to inject
a malicious global context that could in turn be used to disrupt other
web applications and/or read and write data owned by other web
applications.

Mitigation:
Users of affected versions should apply one of the following mitigations
- - Upgrade to Apache Tomcat 9.0.0.M3 or later
- - Upgrade to Apache Tomcat 8.0.32 or later
   (8.0.31 has the fix but was not released)
- - Upgrade to Apache Tomcat 7.0.68 or later
- - Upgrade to Apache Tomcat 6.0.45 or later


Credit:
This issue was discovered by The Apache Tomcat Security Team.

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWyu+yAAoJEBDAHFovYFnnPIgP/j9nli2IrsZEyhDyJ6XqAcg9
AisYAv7iSQ63zLe27CERDdOS9BBFI9j+MwkabF0FzmTGxugLyRwpKLt8Y3BV/723
Jwgds8phJcOm5oouzblUBfx/HdFDRI8+J6q7CNoSh61yXatuKRe5upc51W9G8/Vd
YS6b5XNqavBgvkQZudITIsr4N9vqxb+QVS9iMJfrACikgeq6QR6rwkJWAEcUYHrn
RESKuCTPzw8yf1Q1C8Ar9BUdSx8MRFDHfV8stKmjQWslud0EOP5bObWXBsv9vrQ7
XNKVKA69Hp1Kk++ORHUPnv6B2bCRsD5mZmBwqcvi6jVMuVMKaiLgCqJqfXcJEb4+
D86kjsBCQchGWSsFEwzmoQI++wW60Mn5QRlibF90LHAJLfZLo+cCsOUZABqgv3+j
xwA6HpR5ToMepO5CNcL76wDoBJDEPRXjIuVY6RhWnS7UXi4kuqp/qxtWBifn07X/
Ncbm5TWhf4ESnS5YOPMNefA5aDQJKRclymyXB37VxMwHdJ/zkY8uV48SeG9ACHNt
KBaXiS7FiNKLWqbzZijsXM2a40benXn6ocxStyApF7h15k/8/pyyq4DC55TBMitK
/L+RHHp9RAS+wP98xyYpFnuVI8/LkHSJwnLvTURDQlr1Fi/AJ5YIB+Y9GPE2sigA
90lXXPnmrbSsQR10jD/j
=5LII
-END PGP SIGNATURE-

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





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

Re: How to debug deployment process of my application in IntelliJ IDEA

[Sean Dawson]

I'm thinking this is more of an IntelliJ question than a Tomcat one?  Can
you post to their support/groups?


On Mon, Mar 21, 2016 at 3:54 AM, Artur Owczarek 
wrote:

> I'm learning how Spring MVC works. I'd like to debug the process of
> deployment on different containers (using IntelliJ) as well as how my
> application works after deployment. I created the simplest application
> possible. It does nothing except registering dispatcher servlet. Now I set
> breakpoint somewhere in my servlet and debug application. It stops as
> expected. When I click on frames of my thread, I can download sources of
> spring (because the dependencies are in my pom.xml). These framed have
> yellow background in default IntelliJ Theme. There are also frames with
> white background. The ones with black foreground belong to my application.
> The ones with grey letters are from org.apache.catalina. I can't view
> corresponding source code because it's not been attached. When I edit
> configurations, I can configure application server and add source code. I
> downloaded matching tomcat source code and added it in Application Servers
> windows. IntelliJ added these directories as source code. Unfortunatelly I
> still can't see the source code. What shall I do to see the source code of
> tomcat? I'm using tomcat 8.
>

Re: Time zone in all web application pages revert to UTC !

[Christopher Schultz]

Utkarsh,

On 3/22/16 2:40 AM, Utkarsh Dave wrote:
> We are having this weird issue seen in all the web application pages where
> time gets changed to UTC after some days.

Aren't you using DateFormats for your date/time printing?

> As a workaround it works fine until Tomcat is restarted, but after some
> days time in UTC is seen again. This is regardless of any time/time zone
> configured on the server (IST/PST).
> We are on linux 6.6 (with ntp running) and use java 1.7.0.95.
> Need your thoughts on this? Let me know if you need further information
> If i write a new java class inside tomcat directory and print the output to
> one of the log files and display java.util.TimeZone.getDefault().getID().
> it will give correct result.
> Is some attribute within Tomcat or jsp that gets reset ?

Tomcat will not attempt to change the default time zone of the JVM.

How do you print timestamps in your web application? This can easily be
corrected, but it might be a lot of work if you have been using bad
practices.

-chris

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

Re: Apache Connector: Questions to v1.2.41

[Christopher Schultz]

Josef,

On 3/22/16 9:46 AM, Prandstetter Josef wrote:
> First of all I want to state, that we recommend / promote using Apache 
> Connector related to our software and our customer are very happy with Apache 
> Connectors. Thx to all of the team!
> 
> On the WebSite I can see Apache Connector 1.2.41 is available since several 
> months:
> 
> http://tomcat.apache.org/connectors-doc/
> 
> 
> 1.   If I have a look at the following website (or other mirrors) I can 
> read, that v1.2.40 is still the latest stable version:
> 
> http://mirror.klaus-uwe.me/apache/tomcat/tomcat-connectors/jk/binaries/windows/
> 
> 
> 
> Are there plans to name 1.2.41 as a stable version?
> 
> 
> 
> 2.   If I have a look at the same site I can see no precompiled 
> distribution package for 1.2.41
> 
> http://mirror.klaus-uwe.me/apache/tomcat/tomcat-connectors/jk/binaries/windows/
> 
> 
> 
> Are the plans to release a v1.2.41 package?
> Especially we would be interested in a 64bit package for IIS.
> 
> 
> 3.   Is there a very, very rough timeline for an update? Eg. v1.2.42 or 
> whatever?
> 
> 
> 4.   I found a dead link at 
> http://wiki.apache.org/tomcat/FAQ/Performance_and_Monitoring
> The link to "Fronting Tomcat with Apache or IIS - Best Practices" isn't 
> correct and could maybe updated to another site like:
> http://documents.mx/documents/fronting-tomcat-with-apache-or-iis-best-practices.html

Producing binaries for every combination of architecture/OS/web
server/compiler was becoming impossible to manage, so we stopped doing it.

If you are running under some kind of UNIX-like OS, mod_jk should build
quite easily out of the box. If you are having trouble, please let us
know and we can probably help.

If you are running Windows, I highly recommend using the pre-built
binaries for mod_jk from Apache Lounge. While not technically affiliated
with the ASF, they have been producing binaries for various
httpd-related project for quite some time, and I've heard no complaints.
http://www.apachelounge.com/

Hope that helps,
-chris

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

Re: "Distinct and non-overlapping" context roots

[Christopher Schultz]

Mark,

On 3/17/16 1:28 PM, Mark Thomas wrote:
> On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict  
> wrote:
>> This question is not about Tomcat per se, but it does affect it. It's
>> really about the EE specification in regards to any servlet container.
>> I'd
>> like to get professional opinions on this part of the specification.
>>
>> I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph 3c:
>>
>> The Deployer must... "Assign a context root for each web module
>> included in
>> the Java EE application. The context root is a relative name in the web
>> namespace for the application. Each web module must be given a distinct
>> and
>> non-overlapping name for its context root."
>>
>> So given this scenario:
>> /context/something <-- context is /context
>> /context/something/somethingelse <-- context is /context/something
>>
>> The specification puts no limitations on the context root character set
>> (so
>> it can include a slash). With that said, would you consider these
>> "overlapping" contexts? I noticed one application server supporting
>> this
>> paradigm without issue, but it seems like a violation of the
>> specification.
>> Please advise.
>>
>> Also, since Tomcat doesn't support "applications" (EAR?), how should
>> the
>> specification be interpreted in the absence of that artifact?
>>
>> [1]
>> http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/
>>
>> Cheers,
>> Paul
> 
> That requirement makes no sense as I understand it. You always have 
> overlapping context paths because of the ROOT context.
> 
> I think this is one for the EG to clarify what they meant.
> 
> It is also worth noting that the servlet spec explicitly states thst
> requests are matched against the longest matching context path.

How can Tomcat tell the difference between requests to:

/webappA/someresource/foo (which does exist in webappA path=/webappA)
and
/webappA/someresource/foo (which does not exist in webappB
path="/webappA/someresource)

In the above case, Tomcat should choose the second, because
/webappA/someresource matches webappB's context path, which is longer
than webappA's context path, right?

(This is yet another reason why confusing URL prefixes should be avoided
whenever possible.)

-chris

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

Apache Connector: Questions to v1.2.41

[Prandstetter Josef]

Dear All,

First of all I want to state, that we recommend / promote using Apache 
Connector related to our software and our customer are very happy with Apache 
Connectors. Thx to all of the team!

On the WebSite I can see Apache Connector 1.2.41 is available since several 
months:

http://tomcat.apache.org/connectors-doc/


1.   If I have a look at the following website (or other mirrors) I can 
read, that v1.2.40 is still the latest stable version:

http://mirror.klaus-uwe.me/apache/tomcat/tomcat-connectors/jk/binaries/windows/



Are there plans to name 1.2.41 as a stable version?



2.   If I have a look at the same site I can see no precompiled 
distribution package for 1.2.41

http://mirror.klaus-uwe.me/apache/tomcat/tomcat-connectors/jk/binaries/windows/



Are the plans to release a v1.2.41 package?
Especially we would be interested in a 64bit package for IIS.


3.   Is there a very, very rough timeline for an update? Eg. v1.2.42 or 
whatever?


4.   I found a dead link at 
http://wiki.apache.org/tomcat/FAQ/Performance_and_Monitoring
The link to "Fronting Tomcat with Apache or IIS - Best Practices" isn't correct 
and could maybe updated to another site like:
http://documents.mx/documents/fronting-tomcat-with-apache-or-iis-best-practices.html

Best Regards,
Josef Prandstetter

Re: Time zone in all web application pages revert to UTC !

[Johan Compagner]

On 22 March 2016 at 07:40, Utkarsh Dave  wrote:

> Hi Users and Tomcat team,
>
> We are having this weird issue seen in all the web application pages where
> time gets changed to UTC after some days.
> As a workaround it works fine until Tomcat is restarted, but after some
> days time in UTC is seen again. This is regardless of any time/time zone
> configured on the server (IST/PST).
> We are on linux 6.6 (with ntp running) and use java 1.7.0.95.
> Need your thoughts on this? Let me know if you need further information
> If i write a new java class inside tomcat directory and print the output to
> one of the log files and display java.util.TimeZone.getDefault().getID().
> it will give correct result.
> Is some attribute within Tomcat or jsp that gets reset ?
>
>
>
Are you using in 1 of your web applications something like Pack200 ?

Because that one set the the default timezone to UTC  (and tries to set
it back but if you are using in in a multi threaded way then it will
eventually stick to UTC)

Ofcourse there can be other stuff that just does that, sets the default
time zone at one point..

Time zone in all web application pages revert to UTC !

[Utkarsh Dave]

Hi Users and Tomcat team,

We are having this weird issue seen in all the web application pages where
time gets changed to UTC after some days.
As a workaround it works fine until Tomcat is restarted, but after some
days time in UTC is seen again. This is regardless of any time/time zone
configured on the server (IST/PST).
We are on linux 6.6 (with ntp running) and use java 1.7.0.95.
Need your thoughts on this? Let me know if you need further information
If i write a new java class inside tomcat directory and print the output to
one of the log files and display java.util.TimeZone.getDefault().getID().
it will give correct result.
Is some attribute within Tomcat or jsp that gets reset ?

-Thanks
Utkarsh