Re: [VOTE] Release Apache Tomcat 8.5.84 [test-failure question]

[Mark Thomas]

On 16/11/2022 16:48, Christopher Schultz wrote:

All,

I'm getting a test failure on Windows for this test:

TEST-javax.servlet.http.TestHttpServletDoHeadValidWrite513.NIO.txt

Looking at the log file, it seems to be complaining that it can't 
clean-up after itself:


Testsuite: javax.servlet.http.TestHttpServletDoHeadValidWrite513
Tests run: 288, Failures: 25, Errors: 0, Skipped: 0, Time elapsed: 
41.399 sec


[...]

Testcase: testDoHead[10: 16 false 1 FULL 513 false] took 0.177 sec
 FAILED
Failed to delete at least one file
junit.framework.AssertionFailedError: Failed to delete at least one file
 at 
org.apache.catalina.startup.LoggingBaseTest.tearDown(LoggingBaseTest.java:142)
 at 
org.apache.catalina.startup.TomcatBaseTest.tearDown(TomcatBaseTest.java:243)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


Then lots more like this.

This appears to be a problem with the test case itself, agreed?


Agreed.

Mark


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

Re: [VOTE] Release Apache Tomcat 8.5.84 [test-failure question]

[Christopher Schultz]

All,

I'm getting a test failure on Windows for this test:

TEST-javax.servlet.http.TestHttpServletDoHeadValidWrite513.NIO.txt

Looking at the log file, it seems to be complaining that it can't 
clean-up after itself:


Testsuite: javax.servlet.http.TestHttpServletDoHeadValidWrite513
Tests run: 288, Failures: 25, Errors: 0, Skipped: 0, Time elapsed: 
41.399 sec


[...]

Testcase: testDoHead[10: 16 false 1 FULL 513 false] took 0.177 sec
FAILED
Failed to delete at least one file
junit.framework.AssertionFailedError: Failed to delete at least one file
	at 
org.apache.catalina.startup.LoggingBaseTest.tearDown(LoggingBaseTest.java:142)
	at 
org.apache.catalina.startup.TomcatBaseTest.tearDown(TomcatBaseTest.java:243)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)


Then lots more like this.

This appears to be a problem with the test case itself, agreed?

Thanks,
-chris

On 11/16/22 11:03, Christopher Schultz wrote:

The proposed Apache Tomcat 8.5.84 release is now available for voting.

The notable changes compared to 8.5.83 are:

- Fix concurrency issue in evaluation of expression language containing
    lambda expressions.

- Correct the date format used with the expires attribute of HTTP
    cookies. A single space rather than a single dash should be used to
    separate the day, month and year components to be compliant with RFC
    6265.

- Update to Commons Daemon 1.3.2.

Along with lots of other bug fixes and improvements.

For full details, see the changelog:
https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.84/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1407

The tag is:
https://github.com/apache/tomcat/tree/8.5.84/
079a46c1c1e56b1743e752a44450469690880a56

The proposed 8.5.84 release is:
[ ] Broken - do not release
[ ] Stable - go ahead and release as 8.5.84 (stable)

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


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

Re: Question about the log variable in Filters

[tianshuang]

Well, actually the Filter class will only be loaded once by the common 
classloader, to ensure that the latest log configuration in the webapp is used, 
we have to remove the static modifier to ensure that the log instance is 
recreated with the new configuration (if the configuration changes).

Thanks,
tianshuang

> On Aug 31, 2022, at 18:52, Konstantin Kolinko  wrote:
> 
> ср, 31 авг. 2022 г. в 13:25, tianshuang :
>> 
>> Hi,
>> 
>> In this commit 
>> ,
>>  the static modifier was removed from the log variable in the Filters class, 
>> but I don't understand why it needs to be removed. As far as I know, when a 
>> class is loaded by different classLoader, each classLoader creates its own 
>> instance of static variable. So, is it necessary to remove the static 
>> modifier here?
>> 
>> commit url: 
>> https://github.com/apache/tomcat/commit/dd44360b2ce8e5e1b79c756723158944264f556e
> 
> See classloader hierarchy here:
> 
> https://tomcat.apache.org/tomcat-10.1-doc/class-loader-howto.html
> https://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html
> 
> When Webapp classloader loads the Filter class, it does not "load the
> class" (i.e. does not read the bytes from a jar archive and does not
> produce a Class out of those bytes). It delegates the task to its
> parent in the classloader hierarchy. Thus, the Filter class is loaded
> by the Common classloader.
> 
> At the same time, the logging configuration for each web application
> may be different:
> A web application may provide its own copy of logging.properties file
> by placing it into its own WEB-INF/classes/ directory.
> 
> https://tomcat.apache.org/tomcat-8.5-doc/logging.html#Using_java.util.logging_(default)
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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

Re: Question about the log variable in Filters

[Konstantin Kolinko]

ср, 31 авг. 2022 г. в 13:25, tianshuang :
>
> Hi,
>
> In this commit 
> ,
>  the static modifier was removed from the log variable in the Filters class, 
> but I don't understand why it needs to be removed. As far as I know, when a 
> class is loaded by different classLoader, each classLoader creates its own 
> instance of static variable. So, is it necessary to remove the static 
> modifier here?
>
> commit url: 
> https://github.com/apache/tomcat/commit/dd44360b2ce8e5e1b79c756723158944264f556e

See classloader hierarchy here:

https://tomcat.apache.org/tomcat-10.1-doc/class-loader-howto.html
https://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html

When Webapp classloader loads the Filter class, it does not "load the
class" (i.e. does not read the bytes from a jar archive and does not
produce a Class out of those bytes). It delegates the task to its
parent in the classloader hierarchy. Thus, the Filter class is loaded
by the Common classloader.

At the same time, the logging configuration for each web application
may be different:
A web application may provide its own copy of logging.properties file
by placing it into its own WEB-INF/classes/ directory.

https://tomcat.apache.org/tomcat-8.5-doc/logging.html#Using_java.util.logging_(default)

Best regards,
Konstantin Kolinko

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

Question about the log variable in Filters

[tianshuang]

Hi,

In this commit 
,
 the static modifier was removed from the log variable in the Filters class, 
but I don't understand why it needs to be removed. As far as I know, when a 
class is loaded by different classLoader, each classLoader creates its own 
instance of static variable. So, is it necessary to remove the static modifier 
here?

commit url: 
https://github.com/apache/tomcat/commit/dd44360b2ce8e5e1b79c756723158944264f556e

Thanks,
tianshuang

Re: Question ad using System.gc()

[Rony G. Flatscher (Apache)]

On 04.08.2022 15:17, Konstantin Kolinko wrote:

чт, 4 авг. 2022 г. в 14:45, Rony G. Flatscher (Apache) :

While testing a taglib library that allows javax.script languages to be used in 
JSPs one observation
was directed at garbage collection. It seems that Java's garbage collection in 
this particular use
case is carried out quite lazily (which is fine in the general case). There is 
however a use case
where resources are not only held (and visible) by Java, but also by native 
code which releases its
resources only after the Java garbage collection reclaimed the Java peer 
(employing
PhantomReferences and a cleaner as finalize() has been deprecated for removal).

In the course of stress tests there are hundreds of ScriptEngines created (each 
JSP request will
cause a ScriptEngine to be created per script language used in that JSP). It 
seems that the lazily
employed gc() allows situations where there are more than 100 unreferenced 
ScriptEngines tangling.
The implementation of a ScriptEngine that serves as the peer for a native 
programming language
instance would employ a System.gc() in the case that 100 or more such 
unreferenced ScriptEngines
exist in the currently running JVM.

If resources are hard to initialize or hard to clean up it might be a
good idea to pool them.

Is it possible to release those resources, e.g. by implementing a
Tag.release() method? Making use of tag handler pooling provided by
the JSP specification / Tag Extension API for "classical" tag
handlers.


This would work only for BSF script engines (the Apache scripting framework that predates the 
official Java scripting framework javax.script a.k.a. jsr223) as there terminate() is available.



The question: would you see a problem in employing System.gc() independent of 
the JVM and/or Tomcat?
Theoretically it may be invoked every second or two (unless of course the 
System's garbage collector
ran and allowed the unreferenced ScriptEngine resources to be cleaned). In 
practice (outside of
artificial stress tests) this may never be triggered as long as the JVM garbage 
collector runs from
time to time.


Problems may be

a) Overheating the Planet, by doing useless work.

:)

That is what bitcoin miners already do somewhere, so I do not think
that your use case adds much.

Indeed.

If you do a "resource.close()" call to release a resource, you are
specifically doing some required work. If you call a GC  (via
System.gc() or maybe explicitly via JMX), some work performed by GC is
useless (not resulting in any memory being freed) and some is useful.

What is the balance between the useless and useful work and whether
the JVM can be configured to make the balance better is what
determines whether calling the GC is a good idea in your use case.

E.g. it might occur that it would be cheaper to just kill the whole
JVM once the memory is full and start over with a new instance.

Still have to arrive at that point.

b) Getting less of performance / throughput than you desire.

That is what those stress tests are supposed to let you to estimate.

Just rigging the tests might be a bad idea (as VW engineers found
through the Dieselgate), as it may hide a problem that may be observed
by real users.

+1

P.S.: If this question should rather be asked in the Tomcat user list please 
let me know.

We do discuss "[OT]" (offtopic) questions here sometimes.
And this question looks to be more related to Taglibs (a set of tag
library projects under Tomcat PMC) rather than to Tomcat itself. Their
development is discussed here.


Thank you very much for your thoughts and efforts, Konstantin!

---rony


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

Re: Question ad using System.gc()

[Konstantin Kolinko]

чт, 4 авг. 2022 г. в 14:45, Rony G. Flatscher (Apache) :
>
> While testing a taglib library that allows javax.script languages to be used 
> in JSPs one observation
> was directed at garbage collection. It seems that Java's garbage collection 
> in this particular use
> case is carried out quite lazily (which is fine in the general case). There 
> is however a use case
> where resources are not only held (and visible) by Java, but also by native 
> code which releases its
> resources only after the Java garbage collection reclaimed the Java peer 
> (employing
> PhantomReferences and a cleaner as finalize() has been deprecated for 
> removal).
>
> In the course of stress tests there are hundreds of ScriptEngines created 
> (each JSP request will
> cause a ScriptEngine to be created per script language used in that JSP). It 
> seems that the lazily
> employed gc() allows situations where there are more than 100 unreferenced 
> ScriptEngines tangling.
> The implementation of a ScriptEngine that serves as the peer for a native 
> programming language
> instance would employ a System.gc() in the case that 100 or more such 
> unreferenced ScriptEngines
> exist in the currently running JVM.

If resources are hard to initialize or hard to clean up it might be a
good idea to pool them.

Is it possible to release those resources, e.g. by implementing a
Tag.release() method? Making use of tag handler pooling provided by
the JSP specification / Tag Extension API for "classical" tag
handlers.

>
> The question: would you see a problem in employing System.gc() independent of 
> the JVM and/or Tomcat?
> Theoretically it may be invoked every second or two (unless of course the 
> System's garbage collector
> ran and allowed the unreferenced ScriptEngine resources to be cleaned). In 
> practice (outside of
> artificial stress tests) this may never be triggered as long as the JVM 
> garbage collector runs from
> time to time.
>

Problems may be

a) Overheating the Planet, by doing useless work.

That is what bitcoin miners already do somewhere, so I do not think
that your use case adds much.

If you do a "resource.close()" call to release a resource, you are
specifically doing some required work. If you call a GC  (via
System.gc() or maybe explicitly via JMX), some work performed by GC is
useless (not resulting in any memory being freed) and some is useful.

What is the balance between the useless and useful work and whether
the JVM can be configured to make the balance better is what
determines whether calling the GC is a good idea in your use case.

E.g. it might occur that it would be cheaper to just kill the whole
JVM once the memory is full and start over with a new instance.


b) Getting less of performance / throughput than you desire.

That is what those stress tests are supposed to let you to estimate.

Just rigging the tests might be a bad idea (as VW engineers found
through the Dieselgate), as it may hide a problem that may be observed
by real users.

>
> P.S.: If this question should rather be asked in the Tomcat user list please 
> let me know.

We do discuss "[OT]" (offtopic) questions here sometimes.
And this question looks to be more related to Taglibs (a set of tag
library projects under Tomcat PMC) rather than to Tomcat itself. Their
development is discussed here.

Best regards,
Konstantin Kolinko

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

Question ad using System.gc()

[Rony G. Flatscher (Apache)]

While testing a taglib library that allows javax.script languages to be used in JSPs one observation 
was directed at garbage collection. It seems that Java's garbage collection in this particular use 
case is carried out quite lazily (which is fine in the general case). There is however a use case 
where resources are not only held (and visible) by Java, but also by native code which releases its 
resources only after the Java garbage collection reclaimed the Java peer (employing 
PhantomReferences and a cleaner as finalize() has been deprecated for removal).


In the course of stress tests there are hundreds of ScriptEngines created (each JSP request will 
cause a ScriptEngine to be created per script language used in that JSP). It seems that the lazily 
employed gc() allows situations where there are more than 100 unreferenced ScriptEngines tangling. 
The implementation of a ScriptEngine that serves as the peer for a native programming language 
instance would employ a System.gc() in the case that 100 or more such unreferenced ScriptEngines 
exist in the currently running JVM.


The question: would you see a problem in employing System.gc() independent of the JVM and/or Tomcat? 
Theoretically it may be invoked every second or two (unless of course the System's garbage collector 
ran and allowed the unreferenced ScriptEngine resources to be cleaned). In practice (outside of 
artificial stress tests) this may never be triggered as long as the JVM garbage collector runs from 
time to time.


What do you think?

---rony

P.S.: If this question should rather be asked in the Tomcat user list please 
let me know.


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

RE: Question

[jonmcalexander]

Thank you so much Mark!!! Yesterday was a PEBKAC day.


Sent with BlackBerry Work (www.blackberry.com)

From: Mark Thomas 
Sent: Feb 4, 2021 1:57 AM
To: dev@tomcat.apache.org
Subject: Re: Question

On 04/02/2021 05:04, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Hi Folks! Another wild and crazy question.
>
> So, Tomcat 10.0.2. I see that it uses Jakarta EE 9, and the README states it 
> requires at least Java 8. So, will it run just fine on Java 1.8x or does the 
> Jakarta EE 1.9 have to be installed?

You only need Java 8.

There is no such thing as Jakarta EE 1.9.

Jakarta EE 9 is a collection of APIs and specifications for how those
APIs are expected to behave. Tomcat implements a subset of those
specifications and APIs (Servlet, WebSocket, EL, Server Pages,
Authentication and Annotations).

Note that you cannot take an application that works on Tomcat 9 and use
it unchanged on Tomcat 10 because in the move from Java EE 8 (Tomcat 9)
to Jakarta EE 9 (Tomcat 10) the java package name used by all the APIs
changed from javax... to jakarta...

The Tomcat community has provided a migration tool that converts
applications from Java EE 8 to Jakarta EE 9:
https://github.com/apache/tomcat-jakartaee-migration

HTH,

Mark


>
> Thanks,
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
>
> Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
> 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
> 12/30/2020, 12/31/2020
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
>
>


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


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

Re: Question

[Mark Thomas]

On 04/02/2021 05:04, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Hi Folks! Another wild and crazy question.
> 
> So, Tomcat 10.0.2. I see that it uses Jakarta EE 9, and the README states it 
> requires at least Java 8. So, will it run just fine on Java 1.8x or does the 
> Jakarta EE 1.9 have to be installed?

You only need Java 8.

There is no such thing as Jakarta EE 1.9.

Jakarta EE 9 is a collection of APIs and specifications for how those
APIs are expected to behave. Tomcat implements a subset of those
specifications and APIs (Servlet, WebSocket, EL, Server Pages,
Authentication and Annotations).

Note that you cannot take an application that works on Tomcat 9 and use
it unchanged on Tomcat 10 because in the move from Java EE 8 (Tomcat 9)
to Jakarta EE 9 (Tomcat 10) the java package name used by all the APIs
changed from javax... to jakarta...

The Tomcat community has provided a migration tool that converts
applications from Java EE 8 to Jakarta EE 9:
https://github.com/apache/tomcat-jakartaee-migration

HTH,

Mark


> 
> Thanks,
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
> 
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
> 
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
> 
> jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
> 
> Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
> 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
> 12/30/2020, 12/31/2020
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
> 
> 


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

Question

[jonmcalexander]

Hi Folks! Another wild and crazy question.

So, Tomcat 10.0.2. I see that it uses Jakarta EE 9, and the README states it 
requires at least Java 8. So, will it run just fine on Java 1.8x or does the 
Jakarta EE 1.9 have to be installed?

Thanks,

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

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

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

jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>

Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
12/30/2020, 12/31/2020
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: 10.0.x Release Question

[Mark Thomas]

On 23/01/2021 16:59, Volodymyr Siedlecki wrote:
> Hello,
> 
> Since 10.0.0 is still in beta, is there an expected timeframe of a non-beta
> release?
> Will it be 10.0.1 or another future release?

That depends on how the community votes on the 10.0.1 release.

Personally, I think 10.0.x is stable but we'll need to wait and see what
the consensus is.

Mark

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

10.0.x Release Question

[Volodymyr Siedlecki]

Hello,

Since 10.0.0 is still in beta, is there an expected timeframe of a non-beta
release?
Will it be 10.0.1 or another future release?

Thank you for your help,
Volodymyr

RE: Migration Guide question

[jonmcalexander]

Thanks Mark!

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

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

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

jonmcalexan...@wellsfargo.com

Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
12/30/2020, 12/31/2020
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Mark Thomas 
> Sent: Monday, January 11, 2021 1:59 AM
> To: Tomcat Developers List 
> Subject: Re: Migration Guide question
> 
> On 11/01/2021 05:04, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Quick question.
> >
> > In looking at the Migration Guides, there is a guide for going from 7.0x to
> 8.0x and a guide for going from 8.0x to 8.5x. However, there isn't a guide for
> going from Tomcat 7x to 8.5x. With 7.0 going EOL at the end of March, is
> there any hope of a migration plan for developers going from 7x to 8.5x?
> 
> Unlikely. Any such guide would just be a concatenation of the 7.0.x to 8.0.x
> guide and the 8.0.x to 8.5.x guide. Creating a 7.0.x to 8.5.x guide would just
> create a maintenance overhead.
> 
> I've just scanned through those docs and don't see anything else that would
> be required.
> 
> Mark
> 
> 
> >
> > Thanks,
> >
> > Dream * Excel * Explore * Inspire
> > Jon McAlexander
> > Infrastructure Engineer
> > Asst Vice President
> >
> > Middleware Product Engineering
> > Enterprise CIO | Platform Services | Middleware | Infrastructure
> > Solutions
> >
> > 8080 Cobblestone Rd | Urbandale, IA 50322
> > MAC: F4469-010
> > Tel 515-988-2508 | Cell 515-988-2508
> >
> >
> jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
> >
> > Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020,
> > 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020,
> 12/29/2020, 12/30/2020, 12/31/2020 This message may contain confidential
> and/or privileged information. If you are not the addressee or authorized to
> receive this for the addressee, you must not use, copy, disclose, or take any
> action based on this message or any information herein. If you have received
> this message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation.
> >
> >
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional
> commands, e-mail: dev-h...@tomcat.apache.org


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

Re: Migration Guide question

[Mark Thomas]

On 11/01/2021 05:04, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Quick question.
> 
> In looking at the Migration Guides, there is a guide for going from 7.0x to 
> 8.0x and a guide for going from 8.0x to 8.5x. However, there isn't a guide 
> for going from Tomcat 7x to 8.5x. With 7.0 going EOL at the end of March, is 
> there any hope of a migration plan for developers going from 7x to 8.5x?

Unlikely. Any such guide would just be a concatenation of the 7.0.x to
8.0.x guide and the 8.0.x to 8.5.x guide. Creating a 7.0.x to 8.5.x
guide would just create a maintenance overhead.

I've just scanned through those docs and don't see anything else that
would be required.

Mark


> 
> Thanks,
> 
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
> 
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
> 
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
> 
> jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
> 
> Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
> 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
> 12/30/2020, 12/31/2020
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
> 
> 


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

Migration Guide question

[jonmcalexander]

Quick question.

In looking at the Migration Guides, there is a guide for going from 7.0x to 
8.0x and a guide for going from 8.0x to 8.5x. However, there isn't a guide for 
going from Tomcat 7x to 8.5x. With 7.0 going EOL at the end of March, is there 
any hope of a migration plan for developers going from 7x to 8.5x?

Thanks,

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

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

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

jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>

Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
12/30/2020, 12/31/2020
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

Re: Question regarding PoEditor

[Mark Thomas]

On 18/04/2020 06:51, Maxim Solodovnik wrote:
> Hello,
> 
> some time ago Mark announce the ability to use POEditor so users can
> contribute translations
> 
> I have started to import Apache OpenMeetings strings to PoEditor to
> provide our users easier way to contribute
> But found our strings doesn't fit into Free plan :(
> 
> Can you share how you were able to get "More Strings"? :))

If you go to the project (not your account) settings in POEditor, there
should be an option to request that the project be marked as Open
Source. That then gets you unlimited Strings for that project.

Mark

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

Question regarding PoEditor

[Maxim Solodovnik]

Hello,

some time ago Mark announce the ability to use POEditor so users can
contribute translations

I have started to import Apache OpenMeetings strings to PoEditor to provide
our users easier way to contribute
But found our strings doesn't fit into Free plan :(

Can you share how you were able to get "More Strings"? :))

-- 
Best regards,
Maxim

Re: Question Regarding McastServiceImpl#setupSocket

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gurkan,

On Thursday, May 30th, 2019, Gurkan Erdogdu
 wrote:
> 
> In  macOS test server, when configuring the mcastBindAddress as 
> 192.168.1.139 and address as 228.0.0.4 , the code does not use 
> mcastBindAddress , instead it uses multicast  address for socket
> binding and throws exception when sending the datagram packet. Here
> is the exception:
> 
> Exception in thread "main"
> org.apache.catalina.tribes.ChannelException: java.io.IOException:
> Can't assign requested address (sendto failed); No faulty members
> identified. at
> org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(Chan
nelCoordinator.java:207)
>
> 
at
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordin
ator.java:111)
> at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelI
nterceptorBase.java:165)
>
> 
at
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor
.start(MessageDispatchInterceptor.java:228)
> at
> org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelI
nterceptorBase.java:165)
>
> 
at
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:48
3)
> at test.MemberShipTest.main(MemberShipTest.java:44) Caused by:
> java.io.IOException: Can't assign requested address (sendto
> failed) at java.net.PlainDatagramSocketImpl.send(Native Method) at
> java.net.DatagramSocket.send(DatagramSocket.java:693) at
> org.apache.catalina.tribes.membership.McastServiceImpl.send(McastServi
ceImpl.java:505)
>
> 
at
org.apache.catalina.tribes.membership.McastServiceImpl.send(McastService
Impl.java:482)
> at
> org.apache.catalina.tribes.membership.McastServiceImpl.start(McastServ
iceImpl.java:268)
>
> 
at
org.apache.catalina.tribes.membership.McastService.start(McastService.ja
va:289)
> at
> org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(Chan
nelCoordinator.java:196)
>
> 
... 6 more
> 
> When I changed the address to mcastBindAddress while creating the
> socket, no more exception occurred.

I wonder if the problem is that everyone uses multicast on Linux (or
Windows?) and nobody noticed that the code was wrong for the
non-Linux(/Windows?) case. There is this note in setupSocket:

203 if (mcastBindAddress != null) {
204 try {
205 log.info(sm.getString("mcastServiceImpl.bind",
address, Integer.toString(port)));
206 socket = new MulticastSocket(new
InetSocketAddress(address,port));
207 } catch (BindException e) {
208 /*
209  * On some platforms (e.g. Linux) it is not possible
to bind
210  * to the multicast address. In this case only bind to t
he
211  * port.
212  */
213 log.info(sm.getString("mcastServiceImpl.bind.failed"));
214 socket = new MulticastSocket(port);
215 }
216 } else {
217 socket = new MulticastSocket(port);
218 }

So either nobody ever sets the mcastBindAddress, or nobody uses a
system where is actually uses that address.

I'd accept the patch as proposed, or a PR with your name on it, but I
don't have a good place to test it in other environments. Can you file
a BZ issue or make a pull-request with your changes? Others with
better familiarity with the multicast clustering can give it a better
review.

Could you write a unit-test for it?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzwHWQACgkQHPApP6U8
pFgHkxAAxqNGrVLq6G0NahXhKSYLcyF9X5OGv0bMjqg7DjFyOqAJK5X4NKpCqgox
6QUZRoS+3GWMv+uJYd8nQvV3/UBOFboD7NqKnrvgPOSTIG4IPCgp18aLec6+7W/C
mb9DfPqiANVKim5TxY7a+XctNYyN+3Rh0Zxy60SRnR4qJBzztbHBKBJlSHLgwNiG
/LGhmYlDbtOFQVuYOji4CRP3y4XnQ6LvhVLhwsbZ2q+NS0G5u2iQH3wo1fqbbFcQ
InKL2rFQJUBRQOla2f6nF8moedeEFtGbr19N8+2PqJPLJUmiBWkJhjepl/PBMvT8
rT1XUtfYMYUzByD1QwZI9SnX+HpwWn32uTue369+wsAzXMULwwlDgIuGVhIog5CV
UmU2MKWGpglWCWJK0UejV5xkhjzsdLxJD2a6RrNY8y683dL/PqwppGyGxI6uo9Ja
9Qe6MpM+qvAZHp1/7hB+KgH03HmLxXRBSl2DZbcVjmmQGhKTh3AHiI/D/8mrk8Ny
YqmkmWNTt4gTBPP9A3OQJYTsbV3MQBsLqyheYHquaHiLVdOsN9bfrXNfAV3bk9Ni
lxOE4LjAHwpXRALwtD+i3E1wGCjfeAqwMYxxZyHZGU6HXrQynQJITb11rhwo+NUN
y1615lCjNw076+bv67w3H4tjc8eewsNGPU5+8Uipq+2iXfe/pVU=
=f3l5
-END PGP SIGNATURE-

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

Re: Question Regarding McastServiceImpl#setupSocket

[Gurkan Erdogdu]

 Hi ChrisIn  macOS test server, when configuring the mcastBindAddress as 
192.168.1.139 and address as 228.0.0.4 , the code does not use mcastBindAddress 
, instead it uses multicast  address for socket binding and throws exception 
when sending the datagram packet. Here is the exception:
Exception in thread "main" org.apache.catalina.tribes.ChannelException: 
java.io.IOException: Can't assign requested address (sendto failed); No faulty 
members identified.
    at 
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:207)
    at 
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:111)
    at 
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:165)
    at 
org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.start(MessageDispatchInterceptor.java:228)
    at 
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:165)
    at 
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:483)
    at test.MemberShipTest.main(MemberShipTest.java:44)
Caused by: java.io.IOException: Can't assign requested address (sendto failed)
    at java.net.PlainDatagramSocketImpl.send(Native Method)
    at java.net.DatagramSocket.send(DatagramSocket.java:693)
    at 
org.apache.catalina.tribes.membership.McastServiceImpl.send(McastServiceImpl.java:505)
    at 
org.apache.catalina.tribes.membership.McastServiceImpl.send(McastServiceImpl.java:482)
    at 
org.apache.catalina.tribes.membership.McastServiceImpl.start(McastServiceImpl.java:268)
    at 
org.apache.catalina.tribes.membership.McastService.start(McastService.java:289)
    at 
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:196)
    ... 6 more
When I changed the address to mcastBindAddress while creating the socket, no 
more exception occurred.Regards.Gurkan
On Thursday, May 30, 2019, 5:56:46 PM GMT+3, Christopher Schultz 
 wrote:  
 
 -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gurkan,

On 5/29/19 02:28, Gurkan Erdogdu wrote:
> Hi In an McastServiceImpl#setupSocket method, if the user
> configures the mcastBindAddress, it will use the socket to bind to
> this address. But, in the code below, it uses the "address" field
> while creating the socket. Is this correct ?
> 
> if (mcastBindAddress != null) { try { 
> log.info(sm.getString("mcastServiceImpl.bind", address, 
> Integer.toString(port))); socket = new MulticastSocket(new 
> InetSocketAddress(address,port)); } catch (BindException e) {

That definitely does look weird.

The constructor for McastServiceImpl is even more strange:

    /**
    * @param bind - the bind address (not sure this is used yet)
    * @param mcastAddress - the mcast address
    */
    public McastServiceImpl([...],
        InetAddress bind,
        InetAddress mcastAddress,
        [...])
    throws IOException {
        [...]
        this.address = mcastAddress;
        this.mcastBindAddress = bind;
        [...]
    }

There are two items, here:

1. An address to bind to (locally)
2. A multicast target address

The constructor takes these two and calls them:

1. bind
2. mcastAddress

But the class members are called:

1. mcastBindAddress
2. address

The mcastBindAddress appears to be ignored in all but one place, where
the socket's interface is changed to it at McastServiceImpl.java:223:

220    if (mcastBindAddress != null) {
221        if(log.isInfoEnabled())
222            log.info(sm.getString("mcastServiceImpl.setInterface",
mcastBindAddress));
223        socket.setInterface(mcastBindAddress);
224    } //end if

I don't know enough about multicast to know what is supposed to be
happening, here. AFAIK, mcast is a broadcast mechanism and so there is
no difference between the "target" address and the "bind" address: you
just throw packets at the interface:port and that's that.

The code could probably use some clean-up, or at least some better
in-code documentation by someone who has a good understanding of the
whole situation.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzv7ysACgkQHPApP6U8
pFjuNg/8DkSdnsKkoTmGS1N37IXVcdj5cyHlmPC+BdP3NWE4oky0j5uFrGUqcaRG
UJLsPMvtZwgSaQ/wxgin4maluAmK77Agt76r6tXJNbbpdglXVyz7ONWO8a5xmk9R
ltqLWnHVw4a/HB5vatxFgqWWc6L1qWnocJL7/sWUn1M9y9Ee43/+h5OYnaBn9bCM
R1jqVhZAodC2k1eD3HXedCMaVIA4k2fZF+TteOHNu2rDr01mJVZzPjNJ/zy4sNg7
L0P0uuqCp3ylh563c3t+slL/9XFoVDNytD46qJlmDDcOYczNjf5An6dyWBJEX348
d0FdWOw5h45lJKhMd1L9WNLymxj3gQ9a3okfhiEqyunsZA4SbMNCPgy4an8tzBsd
HsX1dNgD6P8aoy2umG6SvqgAoPb0mZxlVVT1NdbXN0uybdv/mUJgjDHNsbaCYOxG
UNBfT/p5VQxURhRuNqHsFYvHtA6pxt8mZBbwsHC6b/uOYgPXPrLbM4oQztF2YEzI
RDOr2kmA+JbEj5qKOeQa3BVGT5bUeLRWH+fDFiXq6ubdBdvHAifPJyGdYgAFLvZq
jm85WJJeNvluwB602JUJ/FFxCYe6sKL7jaqfZJClqZrscUDxve0Fckh9xLrQ/il2
0W1VqfxuWeFL6P0SgJOr7aZxbdA293o1/X10E9o6sMuWoCtHfk8=
=jSBA
-END PGP SIGNATURE-

Re: Question Regarding McastServiceImpl#setupSocket

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gurkan,

On 5/29/19 02:28, Gurkan Erdogdu wrote:
> Hi In an McastServiceImpl#setupSocket method, if the user
> configures the mcastBindAddress, it will use the socket to bind to
> this address. But, in the code below, it uses the "address" field
> while creating the socket. Is this correct ?
> 
> if (mcastBindAddress != null) { try { 
> log.info(sm.getString("mcastServiceImpl.bind", address, 
> Integer.toString(port))); socket = new MulticastSocket(new 
> InetSocketAddress(address,port)); } catch (BindException e) {

That definitely does look weird.

The constructor for McastServiceImpl is even more strange:

/**
 * @param bind - the bind address (not sure this is used yet)
 * @param mcastAddress - the mcast address
 */
public McastServiceImpl([...],
InetAddress bind,
InetAddress mcastAddress,
[...])
throws IOException {
[...]
this.address = mcastAddress;
this.mcastBindAddress = bind;
[...]
}

There are two items, here:

1. An address to bind to (locally)
2. A multicast target address

The constructor takes these two and calls them:

1. bind
2. mcastAddress

But the class members are called:

1. mcastBindAddress
2. address

The mcastBindAddress appears to be ignored in all but one place, where
the socket's interface is changed to it at McastServiceImpl.java:223:

220 if (mcastBindAddress != null) {
221 if(log.isInfoEnabled())
222 log.info(sm.getString("mcastServiceImpl.setInterface",
mcastBindAddress));
223 socket.setInterface(mcastBindAddress);
224 } //end if

I don't know enough about multicast to know what is supposed to be
happening, here. AFAIK, mcast is a broadcast mechanism and so there is
no difference between the "target" address and the "bind" address: you
just throw packets at the interface:port and that's that.

The code could probably use some clean-up, or at least some better
in-code documentation by someone who has a good understanding of the
whole situation.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzv7ysACgkQHPApP6U8
pFjuNg/8DkSdnsKkoTmGS1N37IXVcdj5cyHlmPC+BdP3NWE4oky0j5uFrGUqcaRG
UJLsPMvtZwgSaQ/wxgin4maluAmK77Agt76r6tXJNbbpdglXVyz7ONWO8a5xmk9R
ltqLWnHVw4a/HB5vatxFgqWWc6L1qWnocJL7/sWUn1M9y9Ee43/+h5OYnaBn9bCM
R1jqVhZAodC2k1eD3HXedCMaVIA4k2fZF+TteOHNu2rDr01mJVZzPjNJ/zy4sNg7
L0P0uuqCp3ylh563c3t+slL/9XFoVDNytD46qJlmDDcOYczNjf5An6dyWBJEX348
d0FdWOw5h45lJKhMd1L9WNLymxj3gQ9a3okfhiEqyunsZA4SbMNCPgy4an8tzBsd
HsX1dNgD6P8aoy2umG6SvqgAoPb0mZxlVVT1NdbXN0uybdv/mUJgjDHNsbaCYOxG
UNBfT/p5VQxURhRuNqHsFYvHtA6pxt8mZBbwsHC6b/uOYgPXPrLbM4oQztF2YEzI
RDOr2kmA+JbEj5qKOeQa3BVGT5bUeLRWH+fDFiXq6ubdBdvHAifPJyGdYgAFLvZq
jm85WJJeNvluwB602JUJ/FFxCYe6sKL7jaqfZJClqZrscUDxve0Fckh9xLrQ/il2
0W1VqfxuWeFL6P0SgJOr7aZxbdA293o1/X10E9o6sMuWoCtHfk8=
=jSBA
-END PGP SIGNATURE-

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

Question Regarding McastServiceImpl#setupSocket

[Gurkan Erdogdu]

HiIn an McastServiceImpl#setupSocket method, if the user configures the 
mcastBindAddress, it will use the socket to bind to this address. But, in the 
code below, it uses the "address" field while creating the socket. Is this 
correct ?

if (mcastBindAddress != null) {
 try {
    log.info(sm.getString("mcastServiceImpl.bind", address, 
Integer.toString(port)));
    socket = new MulticastSocket(new 
InetSocketAddress(address,port));
    } catch (BindException e) {
Regards.Gurkan

Re: commons-daemon packaging question

[Konstantin Kolinko]

пт, 5 апр. 2019 г. в 22:48, Coty Sutherland :
>
> Hi,
>
> I'm looking into commons-daemon in Tomcat and it appears that the Windows
> executables (prunsrv and prunmgr) don't require the commons-daemon.jar to
> run Tomcat like the *nix binary (jsvc) does. Can someone confirm that (I
> tested it and it seems to work fine without the jar)? If it's unused I can
> remove it to clean up the packaging a bit.

1) I always remove it when I install Tomcat on Windows as a service,
at the same time as I remove *.sh, *.xml, *.tar.gz files.

For the last N years, N > 5.

2) It is referenced by Class-Path attribute of
bootstrap.jar/META-INF/MANIFEST.MF

(If it is missing, people may ask. If something else is placed under
that name, it will be in Tomcat classpath.)

Best regards,
Konstantin Kolinko

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

commons-daemon packaging question

[Coty Sutherland]

Hi,

I'm looking into commons-daemon in Tomcat and it appears that the Windows
executables (prunsrv and prunmgr) don't require the commons-daemon.jar to
run Tomcat like the *nix binary (jsvc) does. Can someone confirm that (I
tested it and it seems to work fine without the jar)? If it's unused I can
remove it to clean up the packaging a bit.



Thanks,
Coty

Re: 8.5.38 release date question

[Mark Thomas]

On 28/01/2019 18:27, Matt Stoddart wrote:
> Hi all,
> 
> Thanks for all the development support. Is there an expected release date
> for 8.5.38? My company is significantly impacted by
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63022 and we're eager to
> release a fix.

Tag is expected early February. Release likely around 5 days later.

Mark

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

8.5.38 release date question

[Matt Stoddart]

Hi all,



Thanks for all the development support. Is there an expected release date
for 8.5.38? My company is significantly impacted by
https://bz.apache.org/bugzilla/show_bug.cgi?id=63022 and we're eager to
release a fix.



Thanks,

--Matt

Re: Bug 62140 implementation question

[Mitch Claborn]

My only thought was the single-source value.  If it would be a lot of 
extra work to do the text file, then I think the original design is fine.



Mitch

On 10/02/2018 09:56 AM, Marek Czernek wrote:
Well, I personally would prefer if it was  a soure-able (or call-able 
for windows) script; otherwise, you'd have to parse the text file to 
check which part of the text you want to output, since you don't want to 
output all the text at once, but only for one particular verb.


Any particular benefits for a text file over two scripts? It's true it's 
single-sourced, but given that all scripts are essentially duplicated 
into .sh and .bat, I don't feel like that outweighs the ease of use and 
extensibility of the help script files.


On 10/2/18 4:45 PM, Mitch Claborn wrote:
Are the available verbs the same for both .sh and .bat? If so, perhaps 
a text file that contains the actual help text that could be output 
from both .bat and .sh.



Mitch

On 10/01/2018 02:48 PM, Marek Czernek wrote:

Hi there,

I'd like to resolve Bug 62140 [0]. I just wanted to gather some 
opinions about the implementation details. In my mind, the following 
solution is quite reasonable:


1. Create new help scripts, such as help.sh and help.bat. These files
    contain a method for each functional verb that prints some info
    about the verb and exits with 0.
2. Source the files in both catalina.sh and catalina.bat
3. When user enters catalina.[sh|bat] $verb help (or -h, --help?),
    execute one of the methods.

In my mind, the above solution is quite straightforward. Any gotchas, 
or obvious problems?


[0] https://bz.apache.org/bugzilla/show_bug.cgi?id=62140

Cheers,


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



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

Re: Bug 62140 implementation question

[Marek Czernek]

Well, I personally would prefer if it was  a soure-able (or call-able 
for windows) script; otherwise, you'd have to parse the text file to 
check which part of the text you want to output, since you don't want to 
output all the text at once, but only for one particular verb.


Any particular benefits for a text file over two scripts? It's true it's 
single-sourced, but given that all scripts are essentially duplicated 
into .sh and .bat, I don't feel like that outweighs the ease of use and 
extensibility of the help script files.


On 10/2/18 4:45 PM, Mitch Claborn wrote:
Are the available verbs the same for both .sh and .bat? If so, perhaps 
a text file that contains the actual help text that could be output 
from both .bat and .sh.



Mitch

On 10/01/2018 02:48 PM, Marek Czernek wrote:

Hi there,

I'd like to resolve Bug 62140 [0]. I just wanted to gather some 
opinions about the implementation details. In my mind, the following 
solution is quite reasonable:


1. Create new help scripts, such as help.sh and help.bat. These files
    contain a method for each functional verb that prints some info
    about the verb and exits with 0.
2. Source the files in both catalina.sh and catalina.bat
3. When user enters catalina.[sh|bat] $verb help (or -h, --help?),
    execute one of the methods.

In my mind, the above solution is quite straightforward. Any gotchas, 
or obvious problems?


[0] https://bz.apache.org/bugzilla/show_bug.cgi?id=62140

Cheers,


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


--

Marek Czernek

JWS/JBCS Associate Quality Engineer, RHCA

Find me at www.halfastack.com

Re: Bug 62140 implementation question

[Mitch Claborn]

Are the available verbs the same for both .sh and .bat? If so, perhaps a 
text file that contains the actual help text that could be output from 
both .bat and .sh.



Mitch

On 10/01/2018 02:48 PM, Marek Czernek wrote:

Hi there,

I'd like to resolve Bug 62140 [0]. I just wanted to gather some opinions 
about the implementation details. In my mind, the following solution is 
quite reasonable:


1. Create new help scripts, such as help.sh and help.bat. These files
    contain a method for each functional verb that prints some info
    about the verb and exits with 0.
2. Source the files in both catalina.sh and catalina.bat
3. When user enters catalina.[sh|bat] $verb help (or -h, --help?),
    execute one of the methods.

In my mind, the above solution is quite straightforward. Any gotchas, or 
obvious problems?


[0] https://bz.apache.org/bugzilla/show_bug.cgi?id=62140

Cheers,


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

Bug 62140 implementation question

[Marek Czernek]

Hi there,

I'd like to resolve Bug 62140 [0]. I just wanted to gather some opinions 
about the implementation details. In my mind, the following solution is 
quite reasonable:


1. Create new help scripts, such as help.sh and help.bat. These files
   contain a method for each functional verb that prints some info
   about the verb and exits with 0.
2. Source the files in both catalina.sh and catalina.bat
3. When user enters catalina.[sh|bat] $verb help (or -h, --help?),
   execute one of the methods.

In my mind, the above solution is quite straightforward. Any gotchas, or 
obvious problems?


[0] https://bz.apache.org/bugzilla/show_bug.cgi?id=62140

Cheers,
--

Marek Czernek

JWS/JBCS Associate Quality Engineer, RHCA

Find me at www.halfastack.com

Re: Question about r1780601

[Rémy Maucherat]

2017-03-21 17:45 GMT+01:00 Violeta Georgieva :

> Hi,
>
> I was checking some back ports related to bug 60897.
> This [1] was not back ported to the older versions.
> Do we really want it only for Tomcat 9?
>

It can now be backported since nobody complained about it, although it will
increase code size, causing more reports like the BZ. I broke things once
with the fix, hence no new backport.

Rémy

>
> Regards,
> Violeta
>
> [1] https://svn.apache.org/viewvc?view=revision=1780601
>

Question about r1780601

[Violeta Georgieva]

Hi,

I was checking some back ports related to bug 60897.
This [1] was not back ported to the older versions.
Do we really want it only for Tomcat 9?

Regards,
Violeta

[1] https://svn.apache.org/viewvc?view=revision=1780601

Re: Question on submitting bugs/patches for multiple versions of Tomcat

[Mark Thomas]

On 18/01/2017 10:48, Michael Orr wrote:
> Hi folks,
> 
> I've submitted a patch for Tomcat 7 (bug #60597) and have patches
> prepared for 8.5 and 9 as well.  Do I just attach these patch files to
> the same bug in Bugzilla or should I create two new bugs - one for
> each major version of Tomcat?

Just attach them to the same bug.

Thanks,

Mark


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

Question on submitting bugs/patches for multiple versions of Tomcat

[Michael Orr]

Hi folks,

I've submitted a patch for Tomcat 7 (bug #60597) and have patches
prepared for 8.5 and 9 as well.  Do I just attach these patch files to
the same bug in Bugzilla or should I create two new bugs - one for
each major version of Tomcat?

Thanks,

Michael

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

Re: Question about Windows zip distro

[Mark Thomas]

On 09/01/2017 18:24, Coty Sutherland wrote:
> Hi all,
> 
> Do we intentionally ship the shell scripts along with the
> tomcat-native and commons-daemon-native tarballs in bin for the
> Windows distribution?

Yes.

The only variation is the difference in line-endings.

I believe the intention is to provide users with as much flexibility as
possible (i.e. you can use the .zip on Linux if you really want to)
while making it work out of the box for the more obvious/popular use cases.

Mark


> 
> +++
> $ ll apache-tomcat-7.0.73-windows-x64.zip/apache-tomcat-7.0.73/bin/ |
> egrep '(tar.gz|sh)$'
> -rw-r--r--. 1 coty coty   21646 Nov  7 23:29 catalina.sh
> -rw-r--r--. 1 coty coty  204944 Nov  7 23:29 commons-daemon-native.tar.gz
> -rw-r--r--. 1 coty coty1922 Nov  7 23:29 configtest.sh
> -rw-r--r--. 1 coty coty7888 Nov  7 23:29 daemon.sh
> -rw-r--r--. 1 coty coty1965 Nov  7 23:29 digest.sh
> -rw-r--r--. 1 coty coty3547 Nov  7 23:29 setclasspath.sh
> -rw-r--r--. 1 coty coty1902 Nov  7 23:29 shutdown.sh
> -rw-r--r--. 1 coty coty1904 Nov  7 23:29 startup.sh
> -rw-r--r--. 1 coty coty  391853 Nov  7 23:29 tomcat-native.tar.gz
> -rw-r--r--. 1 coty coty5024 Nov  7 23:29 tool-wrapper.sh
> -rw-r--r--. 1 coty coty1908 Nov  7 23:29 version.sh
> +++
> 
> If not, I can amend the build.xml so that it doesn't include them; I
> just thought it looks odd (and would save us 631.9K off the zip size).
> 
> 
> 
> Thanks,
> Coty
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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

Question about Windows zip distro

[Coty Sutherland]

Hi all,

Do we intentionally ship the shell scripts along with the
tomcat-native and commons-daemon-native tarballs in bin for the
Windows distribution?

+++
$ ll apache-tomcat-7.0.73-windows-x64.zip/apache-tomcat-7.0.73/bin/ |
egrep '(tar.gz|sh)$'
-rw-r--r--. 1 coty coty   21646 Nov  7 23:29 catalina.sh
-rw-r--r--. 1 coty coty  204944 Nov  7 23:29 commons-daemon-native.tar.gz
-rw-r--r--. 1 coty coty1922 Nov  7 23:29 configtest.sh
-rw-r--r--. 1 coty coty7888 Nov  7 23:29 daemon.sh
-rw-r--r--. 1 coty coty1965 Nov  7 23:29 digest.sh
-rw-r--r--. 1 coty coty3547 Nov  7 23:29 setclasspath.sh
-rw-r--r--. 1 coty coty1902 Nov  7 23:29 shutdown.sh
-rw-r--r--. 1 coty coty1904 Nov  7 23:29 startup.sh
-rw-r--r--. 1 coty coty  391853 Nov  7 23:29 tomcat-native.tar.gz
-rw-r--r--. 1 coty coty5024 Nov  7 23:29 tool-wrapper.sh
-rw-r--r--. 1 coty coty1908 Nov  7 23:29 version.sh
+++

If not, I can amend the build.xml so that it doesn't include them; I
just thought it looks odd (and would save us 631.9K off the zip size).



Thanks,
Coty

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

Re: a small question of org.apache.tomcat.util.digester.Digester

[Mark Thomas]

On 12/12/2016 12:01, 储巍 wrote:
> Hi！
> 
> when I read the code of Tomcat 9. I have the following question.
> 
> CLass：org.apache.tomcat.util.digester.Digester
> Method：endDocument()
> 
> What's the purpose of the following code block. I think it is same as 
> "stack.clear()" in method clear().
> while (getCount() > 1) {
>   pop();
> }

Take another look. They are not the same.

Mark


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

a small question of org.apache.tomcat.util.digester.Digester

[储巍]

Hi！

when I read the code of Tomcat 9. I have the following question.

CLass：org.apache.tomcat.util.digester.Digester
Method：endDocument()

What's the purpose of the following code block. I think it is same as 
"stack.clear()" in method clear().
while (getCount() > 1) {
  pop();
}





13621135...@163.com

Re: Question about AccessLog.setRequestAttributesEnabled

[Mark Thomas]

On 17/11/2016 09:06, Violeta Georgieva wrote:
> Hi,
> 
> There is an issue [1] about an incorrect javadoc
> for org.apache.catalina.AccessLog.setRequestAttributesEnabled
> 
> I have a question about the default value.
> 
> With the following change [2], back in 2011, the default for all
> implementations was set to "true".
> But with change [3] the default value, only for AccessLogValve, was set to
> "false".
> 
> Was that intentional?

Based on my commit comments I believe the change was deliberate.

> If yes than I will remove the default value definition from the interface
> and I will extend the java doc for the implementations with the concrete
> default value.

+1

Thanks,

Mark

> 
> 
> Thanks,
> Violeta
> 
> [1] http://marc.info/?l=tomcat-dev=147936375104497=2
> [2]
> https://github.com/apache/tomcat/commit/0dc6dbef18d8277037fa2023b76d9bb444622b32
> [3]
> https://github.com/apache/tomcat/commit/98b583e5cfdd0250c3a7a24f85ce2963f9f8ca72
> 


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

Question about AccessLog.setRequestAttributesEnabled

[Violeta Georgieva]

Hi,

There is an issue [1] about an incorrect javadoc
for org.apache.catalina.AccessLog.setRequestAttributesEnabled

I have a question about the default value.

With the following change [2], back in 2011, the default for all
implementations was set to "true".
But with change [3] the default value, only for AccessLogValve, was set to
"false".

Was that intentional?

If yes than I will remove the default value definition from the interface
and I will extend the java doc for the implementations with the concrete
default value.


Thanks,
Violeta

[1] http://marc.info/?l=tomcat-dev=147936375104497=2
[2]
https://github.com/apache/tomcat/commit/0dc6dbef18d8277037fa2023b76d9bb444622b32
[3]
https://github.com/apache/tomcat/commit/98b583e5cfdd0250c3a7a24f85ce2963f9f8ca72

Re: Question about o.a.t.util.digester.Digester.useContextClassLoader

[Mark Thomas]

On 13/09/2016 17:24, Violeta Georgieva wrote:
> Hi,
> 
> There are places in org.apache.tomcat.util.digester.Digester that do not
> consider useContextClassLoader.
> I would like to ask whether this is intentional or I can change that and
> use the provided classloader when useContextClassLoader is false.

Digester has a getClassLoader() method that handles all logic. I don't
see any reason not to use that everywhere.

Mark


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

Question about o.a.t.util.digester.Digester.useContextClassLoader

[Violeta Georgieva]

Hi,

There are places in org.apache.tomcat.util.digester.Digester that do not
consider useContextClassLoader.
I would like to ask whether this is intentional or I can change that and
use the provided classloader when useContextClassLoader is false.

Thanks a lot,
Violeta

Re: question regarding current versioning scheme

[Mark Thomas]

On 09/09/2016 17:32, Jarosław Górny wrote:
> Hi,
> 
> I need to write a piece of code for the tool I'm working on, to
> compare Tomcat version strings ;) I've been advised on #tomcat channel
> to ask here, so here I am. Please forgive me, but I haven't found
> relevant information on the homepage / docs.
> 
> I see that for 9.x branch there are the builds named 9.0.0.Mx (where x
> are natural numbers starting from 1). I think I haven't seen that
> versioning in previous branches. Should one consider those "M-builds"
> as alpha releases?

Yes. The M is for milestone. The idea, before Oracle stopped work on the
Servlet 4.0 spec and delayed JavaEE 8 indefinitely, was to use
milestones until the spec was final and implemented and then switch to
normal numbering with the usual alpha/beta/stable markers.

Apparently there will be an announcement on JavaEE 8 at JavaOne.
Certainly things are looking up. The Servlet 4.0 spec has starting
moving forward again.

What we end up doing will depend very much on what Oracle say at JavaOne.

> And going further, how beta & RC versions would be called this time? I
> think (at least for 8.x and 7.x) there were no versions like
> "8.0.0-beta", but initial "release" numbers were dubbed as beta (eg.
> 8.0.1, 8.0.2 etc.) Is this going to be maintained?

Yes.

> basically, tl;dr; version:
> are the strings like: "A.B.C.Mx" and "A.B.C" all that I can expect now?

Yes. Probably. Well...

The truthful answer is we don't know. A compelling reason for a new
numbering scheme may come up next week and could we decide to switch.
That is very unlikely but it could happen.

What I can say is that, given how the Tomcat community typically decides
to act, it is extremely unlikely we'd change numbering schemes without a
very, very good reason.

Sorry I can't be absolutely certain but the nature of open source
development based on a meritocracy is that no-one can say for certain
what will or will not happen in the future.

Mark

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

question regarding current versioning scheme

[Jarosław Górny]

Hi,

I need to write a piece of code for the tool I'm working on, to
compare Tomcat version strings ;) I've been advised on #tomcat channel
to ask here, so here I am. Please forgive me, but I haven't found
relevant information on the homepage / docs.

I see that for 9.x branch there are the builds named 9.0.0.Mx (where x
are natural numbers starting from 1). I think I haven't seen that
versioning in previous branches. Should one consider those "M-builds"
as alpha releases?

And going further, how beta & RC versions would be called this time? I
think (at least for 8.x and 7.x) there were no versions like
"8.0.0-beta", but initial "release" numbers were dubbed as beta (eg.
8.0.1, 8.0.2 etc.) Is this going to be maintained?

basically, tl;dr; version:
are the strings like: "A.B.C.Mx" and "A.B.C" all that I can expect now?

Thanks in advance!

-- 
Jarosław Górny

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

[Bug 57670] New: Question about javaEncoding of a generated-from-jsp java file

[bugzilla]

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

Bug ID: 57670
   Summary: Question about javaEncoding of a generated-from-jsp
java file
   Product: Tomcat 7
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Jasper
  Assignee: dev@tomcat.apache.org
  Reporter: bluewolf.ch...@gmail.com

I've already checked
https://bz.apache.org/bugzilla/show_bug.cgi?id=19622
that there's no specific reason that UTF-8 is hard-coded for javaEncoding.

Why are the jsp page encoding and the encoding of generated java file different
each other?
Couldn't we just use the jsp page encoding for generating and compiling its
java file?

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 57670] Question about javaEncoding of a generated-from-jsp java file

[bugzilla]

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

Mark Thomas ma...@apache.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Mark Thomas ma...@apache.org ---
Bugzilla is not a support forum.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: Question about taglibs. Issue 37466

[Jeremy Boynes]

On Feb 17, 2015, at 8:23 AM, Jeremy Boynes jboy...@apache.org wrote:
 
 On Feb 17, 2015, at 4:34 AM, Konstantin Kolinko knst.koli...@gmail.com 
 wrote:
 
 2015-02-14 20:04 GMT+03:00 Stephan van Loendersloot (LIST)
 step...@republika.nl:
 Hi everyone,
 
 I have a question about this issue:
 https://bz.apache.org/bugzilla/show_bug.cgi?id=37466
 
 I tried to switch to the latest Tomcat TagLibs implementation, but due to
 this fixed bug, it seems that posted form parameters aren't visible anymore
 in relative pages imported by c:import tags.
 
 The JSTl specicication 1.2, Section 7.2 (page 57) states that relative URLs
 should be processed in the exact same way as the include action of the JSP
 specification (jsp:include) when used in the same application context.
 
 The older, Jakarta TagLibs don't have this problem, but the Tomcat TagLibs
 do...
 
 Can anyone tell me if the fix breaks the specification guidelines, or did I
 misread the whole thing?
 
 
 
 BZ 37466 fix (r495005) was committed 8 years ago.
 
 You need to provide an example that reproduces your issue.  Wrapping a
 request with overwritten getMethod() should not break parsing of POST
 parameters.  The parameters parsing is done by tomcat internals and
 operates on the original request, not on the wrapper.
 
 I think there may be an issue here but would like an example to confirm. This 
 change was introduced between 1.1 and 1.2 and after GlassFish forked away.
 
 The original thread that led to BZ 37466 related to HEAD requests where the 
 original HttpServletRequest was being passed to a RequestDispatcher. What I 
 took from the thread is that this would result an empty response from the 
 imported resource which the application was not expecting - it tried to parse 
 empty content and failed. The r495005 patch attempts to fix this by forcing 
 the method to GET, mirroring the semantic of an external absolute URL where 
 the JSTL spec mandates a GET request is made when using HTTP.
 
 I’m not convinced this change was correct. For relative URLs it specifies the 
 “whole environment is available … as well as request parameters” and by 
 forcing the method to GET we are indicating that there is no request body to 
 parse and so parameters in the original POST body should be skipped. As 
 Konstantin said, Tomcat does not take account of wrappers so will still 
 extract parameters from the request body but that may not be true for other 
 containers or if the application code is parsing the request content.
 
 Perhaps the issue here is actually with Tomcat’s implementation of 
 HttpServlet and/or DefaultServlet where it appears doHead() never returns 
 content even for dispatched includes. If these only suppressed content for 
 the original response but did return content for included responses then BZ 
 37466 would not be an issue. This would also seem to be necessary to return 
 the same headers for HEAD as GET e.g. ensuring that the Content-Length 
 returned included bytes from the included resource.
 
 Stephan, please can you submit an example showing what’s failing for you and 
 include info on which container you are using and what version of taglibs you 
 are upgrading from.
 

In the original issue, a JSP page was using c:import to read a XML resource 
for parsing:
  c:import url=/org/apache/taglibs/standard/tag/el/core/Test37466.xml 
varReader=xmlSource”

This is dispatched and handled by DefaultServlet:
  service() (from HttpServlet) uses getMethod() to determine that doHead() 
should be called
  doHead() calls serveResource() with content = false
  if content is false, serveResource() does not write any data to the response
  the value captured by the HttpResponseWrapper will be empty

If instead, a JSP is used to serve the included resource its _jspService method 
does not check the HTTP method and always emits content.

This can be verified with a simple JSP that does a jsp:include of a .txt or 
.jsp resource where the Content-Length header is different depending on whether 
a GET or HEAD request is made.

Similarly, HttpServlet’s doHead() method is implemented by wrapping the 
response in a NoBodyResponse and then calling doGet().

The patch for 37466 attempts to fix this by overriding getMethod() to always 
return GET. This avoids the issue with DefaultServlet but breaks other servlets 
that actually use the method to dispatch e.g. anything that expects to handle a 
POST request in doPost().

I think instead the fix should be in Tomcat’s HttpServlet and DefaultServlet 
which should not suppress the output if they being called as an include. I’ll 
open an issue against Tomcat and propose a patch for this.

—
Jeremy


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Question about taglibs. Issue 37466

[Stephan van Loendersloot (LIST)]

Hi Konstantin, Jeremy,

Yes I can provide a simple example shortly...

Apologies for breaking the first rule of questioning: provide all 
details about operating system, container, libraries, etc.


Would it be best if I continue this discussion here or at Jira?


On 17-02-15 17:23, Jeremy Boynes wrote:
On Feb 17, 2015, at 4:34 AM, Konstantin Kolinko 
knst.koli...@gmail.com wrote:


 2015-02-14 20:04 GMT+03:00 Stephan van Loendersloot (LIST)
 step...@republika.nl:
 Hi everyone,

 I have a question about this issue:
 https://bz.apache.org/bugzilla/show_bug.cgi?id=37466

 I tried to switch to the latest Tomcat TagLibs implementation, but 
due to
 this fixed bug, it seems that posted form parameters aren't visible 
anymore

 in relative pages imported by c:import tags.

 The JSTl specicication 1.2, Section 7.2 (page 57) states that 
relative URLs
 should be processed in the exact same way as the include action of 
the JSP
 specification (jsp:include) when used in the same application 
context.


 The older, Jakarta TagLibs don't have this problem, but the Tomcat 
TagLibs

 do...

 Can anyone tell me if the fix breaks the specification guidelines, 
or did I

 misread the whole thing?



 BZ 37466 fix (r495005) was committed 8 years ago.

 You need to provide an example that reproduces your issue.  Wrapping a
 request with overwritten getMethod() should not break parsing of POST
 parameters.  The parameters parsing is done by tomcat internals and
 operates on the original request, not on the wrapper.

I think there may be an issue here but would like an example to 
confirm. This change was introduced between 1.1 and 1.2 and after 
GlassFish forked away.


The original thread that led to BZ 37466 related to HEAD requests 
where the original HttpServletRequest was being passed to a 
RequestDispatcher. What I took from the thread is that this would 
result an empty response from the imported resource which the 
application was not expecting - it tried to parse empty content and 
failed. The r495005 patch attempts to fix this by forcing the method 
to GET, mirroring the semantic of an external absolute URL where the 
JSTL spec mandates a GET request is made when using HTTP.


I’m not convinced this change was correct. For relative URLs it 
specifies the “whole environment is available … as well as request 
parameters” and by forcing the method to GET we are indicating that 
there is no request body to parse and so parameters in the original 
POST body should be skipped. As Konstantin said, Tomcat does not take 
account of wrappers so will still extract parameters from the request 
body but that may not be true for other containers or if the 
application code is parsing the request content.


Perhaps the issue here is actually with Tomcat’s implementation of 
HttpServlet and/or DefaultServlet where it appears doHead() never 
returns content even for dispatched includes. If these only suppressed 
content for the original response but did return content for included 
responses then BZ 37466 would not be an issue. This would also seem to 
be necessary to return the same headers for HEAD as GET e.g. ensuring 
that the Content-Length returned included bytes from the included 
resource.


Stephan, please can you submit an example showing what’s failing for 
you and include info on which container you are using and what version 
of taglibs you are upgrading from.


Thanks
Jeremy




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

Re: Question about taglibs. Issue 37466

[Jeremy Boynes]

 On Feb 18, 2015, at 3:10 AM, Stephan van Loendersloot (LIST) 
 step...@republika.nl wrote:
 
 Hi Konstantin, Jeremy,
 
 Yes I can provide a simple example shortly...
 
 Apologies for breaking the first rule of questioning: provide all details 
 about operating system, container, libraries, etc.
 
 Would it be best if I continue this discussion here or at Jira?

I reopened 37466[1]. Please add your example as an attachment there.
Thanks
Jeremy

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=37466


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Question about taglibs. Issue 37466

[Jeremy Boynes]

On Feb 17, 2015, at 4:34 AM, Konstantin Kolinko knst.koli...@gmail.com wrote:
 
 2015-02-14 20:04 GMT+03:00 Stephan van Loendersloot (LIST)
 step...@republika.nl:
 Hi everyone,
 
 I have a question about this issue:
 https://bz.apache.org/bugzilla/show_bug.cgi?id=37466
 
 I tried to switch to the latest Tomcat TagLibs implementation, but due to
 this fixed bug, it seems that posted form parameters aren't visible anymore
 in relative pages imported by c:import tags.
 
 The JSTl specicication 1.2, Section 7.2 (page 57) states that relative URLs
 should be processed in the exact same way as the include action of the JSP
 specification (jsp:include) when used in the same application context.
 
 The older, Jakarta TagLibs don't have this problem, but the Tomcat TagLibs
 do...
 
 Can anyone tell me if the fix breaks the specification guidelines, or did I
 misread the whole thing?
 
 
 
 BZ 37466 fix (r495005) was committed 8 years ago.
 
 You need to provide an example that reproduces your issue.  Wrapping a
 request with overwritten getMethod() should not break parsing of POST
 parameters.  The parameters parsing is done by tomcat internals and
 operates on the original request, not on the wrapper.

I think there may be an issue here but would like an example to confirm. This 
change was introduced between 1.1 and 1.2 and after GlassFish forked away.

The original thread that led to BZ 37466 related to HEAD requests where the 
original HttpServletRequest was being passed to a RequestDispatcher. What I 
took from the thread is that this would result an empty response from the 
imported resource which the application was not expecting - it tried to parse 
empty content and failed. The r495005 patch attempts to fix this by forcing the 
method to GET, mirroring the semantic of an external absolute URL where the 
JSTL spec mandates a GET request is made when using HTTP.

I’m not convinced this change was correct. For relative URLs it specifies the 
“whole environment is available … as well as request parameters” and by forcing 
the method to GET we are indicating that there is no request body to parse and 
so parameters in the original POST body should be skipped. As Konstantin said, 
Tomcat does not take account of wrappers so will still extract parameters from 
the request body but that may not be true for other containers or if the 
application code is parsing the request content.

Perhaps the issue here is actually with Tomcat’s implementation of HttpServlet 
and/or DefaultServlet where it appears doHead() never returns content even for 
dispatched includes. If these only suppressed content for the original response 
but did return content for included responses then BZ 37466 would not be an 
issue. This would also seem to be necessary to return the same headers for HEAD 
as GET e.g. ensuring that the Content-Length returned included bytes from the 
included resource.

Stephan, please can you submit an example showing what’s failing for you and 
include info on which container you are using and what version of taglibs you 
are upgrading from.

Thanks
Jeremy



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Question about taglibs. Issue 37466

[Konstantin Kolinko]

2015-02-14 20:04 GMT+03:00 Stephan van Loendersloot (LIST)
step...@republika.nl:
 Hi everyone,

 I have a question about this issue:
 https://bz.apache.org/bugzilla/show_bug.cgi?id=37466

 I tried to switch to the latest Tomcat TagLibs implementation, but due to
 this fixed bug, it seems that posted form parameters aren't visible anymore
 in relative pages imported by c:import tags.

 The JSTl specicication 1.2, Section 7.2 (page 57) states that relative URLs
 should be processed in the exact same way as the include action of the JSP
 specification (jsp:include) when used in the same application context.

 The older, Jakarta TagLibs don't have this problem, but the Tomcat TagLibs
 do...

 Can anyone tell me if the fix breaks the specification guidelines, or did I
 misread the whole thing?



BZ 37466 fix (r495005) was committed 8 years ago.

You need to provide an example that reproduces your issue.  Wrapping a
request with overwritten getMethod() should not break parsing of POST
parameters.  The parameters parsing is done by tomcat internals and
operates on the original request, not on the wrapper.

Best regards,
Konstantin Kolinko

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

Question about taglibs. Issue 37466

[Stephan van Loendersloot (LIST)]

Hi everyone,

I have a question about this issue: 
https://bz.apache.org/bugzilla/show_bug.cgi?id=37466


I tried to switch to the latest Tomcat TagLibs implementation, but due 
to this fixed bug, it seems that posted form parameters aren't visible 
anymore in relative pages imported by c:import tags.


The JSTl specicication 1.2, Section 7.2 (page 57) states that relative 
URLs should be processed in the exact same way as the include action of 
the JSP specification (jsp:include) when used in the same application 
context.


The older, Jakarta TagLibs don't have this problem, but the Tomcat 
TagLibs do...


Can anyone tell me if the fix breaks the specification guidelines, or 
did I misread the whole thing?


Thanks in advance!


-- Stephan van Loendersloot.



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

Question of new SessionIdGenerator implementation.

[Keiichi Fujino]

I have a question of new SessionIdGenerator implementation.
If reloading Manager( or Context), SessionIdGenerator is re-created based
on sessionIdGeneratorClass that is cached to Manager.
However, attributes of jvmRoute and sessionIdLength are default value.
I think these attributes are need to take over when reloading.
Or another workaround?


-- 
Keiichi.Fujino

Re: Question of new SessionIdGenerator implementation.

[Konstantin Kolinko]

2014-10-14 10:12 GMT+04:00 Keiichi Fujino kfuj...@apache.org:
 I have a question of new SessionIdGenerator implementation.
 If reloading Manager( or Context), SessionIdGenerator is re-created based
 on sessionIdGeneratorClass that is cached to Manager.
 However, attributes of jvmRoute and sessionIdLength are default value.
 I think these attributes are need to take over when reloading.
 Or another workaround?

Looking at ManagerBase.startInternal(), I think that

1) jvmRoute shall not be set on SessionIdGenerator element. It is
set on Engine and is inherited from there. The documentation on
jvmRoute attribute in config/sessionidgenerator.html explicitly
mentions that effect.

It ManagerBase.startInternal() there is the following code:
 sessionIdGenerator.setJvmRoute(getJvmRoute());

2) For sessionIdLength I think one shall be able to configure it on
SessionIdGenerator, so the current behaviour is a bug and is worth
to be added to Bugzilla.

The workaround is to set that attribute on Manager element. (This
contradicts documentation that says that this attribute on Manager
element is deprecated).

The fix is probably to let SessionIdGenerator to implement Lifecycle interface.

The this.sessionIdGenerator = null; assignment in
ManagerBase.stopInternal() originates from r1044874. That is a wrong
place to clear sessionIdGenerator reference. A better place would be
destroyInternal(), or just do not clear it.

The old code before r1044874 was calling randoms.clear(); there. I
think it is easier to expose that method via Lifecycle.stop().

Best regards,
Konstantin Kolinko

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

Re: Question of new SessionIdGenerator implementation.

[Konstantin Kolinko]

2014-10-14 16:17 GMT+04:00 Konstantin Kolinko knst.koli...@gmail.com:
 2014-10-14 10:12 GMT+04:00 Keiichi Fujino kfuj...@apache.org:
 I have a question of new SessionIdGenerator implementation.
 If reloading Manager( or Context), SessionIdGenerator is re-created based
 on sessionIdGeneratorClass that is cached to Manager.
 However, attributes of jvmRoute and sessionIdLength are default value.
 I think these attributes are need to take over when reloading.
 Or another workaround?

 Looking at ManagerBase.startInternal(), I think that

 1) jvmRoute shall not be set on SessionIdGenerator element. It is
 set on Engine and is inherited from there. The documentation on
 jvmRoute attribute in config/sessionidgenerator.html explicitly
 mentions that effect.

 It ManagerBase.startInternal() there is the following code:
  sessionIdGenerator.setJvmRoute(getJvmRoute());

 2) For sessionIdLength I think one shall be able to configure it on
 SessionIdGenerator, so the current behaviour is a bug and is worth
 to be added to Bugzilla.

 The workaround is to set that attribute on Manager element. (This
 contradicts documentation that says that this attribute on Manager
 element is deprecated).

 The fix is probably to let SessionIdGenerator to implement Lifecycle 
 interface.

 The this.sessionIdGenerator = null; assignment in
 ManagerBase.stopInternal() originates from r1044874. That is a wrong
 place to clear sessionIdGenerator reference. A better place would be
 destroyInternal(), or just do not clear it.

 The old code before r1044874 was calling randoms.clear(); there. I
 think it is easier to expose that method via Lifecycle.stop().

I filed
https://issues.apache.org/bugzilla/show_bug.cgi?id=57089

Best regards,
Konstantin Kolinko

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

tomcat staging 8.0.0 RC7 question

[Ludovic Champenois]

Hi,
I see there is a maven staging repo at
https://repository.apache.org/content/repositories/orgapachetomcat-047

but it seems I am missing the 2 artifacts:
The POM for org.eclipse.jdt.core.compiler:ecj:jar:4.3.1 is missing, no
dependency information available
The POM for org.apache.tomcat:tomcat-util-scan:jar:8.0.0-RC7 is missing, no
dependency information available

I am not too concerned about the eclipse compiler, but I can't find the
tomcat-util-scan:jar for testing...
Thanks,
Ludo

Re: tomcat staging 8.0.0 RC7 question

[Mark Thomas]

On 17/12/2013 00:47, Ludovic Champenois wrote:
 Hi,
 I see there is a maven staging repo at
 https://repository.apache.org/content/repositories/orgapachetomcat-047
 
 but it seems I am missing the 2 artifacts:
 The POM for org.eclipse.jdt.core.compiler:ecj:jar:4.3.1 is missing, no
 dependency information available
 The POM for org.apache.tomcat:tomcat-util-scan:jar:8.0.0-RC7 is missing, no
 dependency information available
 
 I am not too concerned about the eclipse compiler, but I can't find the
 tomcat-util-scan:jar for testing...

That JAR wasn't added to the Maven publishing script - an error I've
just fixed.

There will be an RC8 shortly. I just need to re-run the unit tests and
make sure everything passes. It is late here so I'll do that tomorrow my
time. RC8 should be available in around 12 hours or so.

Mark


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

Re: tomcat staging 8.0.0 RC7 question

[Ludovic Champenois]

Cool!
Thank you,
Ludo


On Mon, Dec 16, 2013 at 4:55 PM, Mark Thomas ma...@apache.org wrote:

 On 17/12/2013 00:47, Ludovic Champenois wrote:
  Hi,
  I see there is a maven staging repo at
  https://repository.apache.org/content/repositories/orgapachetomcat-047
 
  but it seems I am missing the 2 artifacts:
  The POM for org.eclipse.jdt.core.compiler:ecj:jar:4.3.1 is missing, no
  dependency information available
  The POM for org.apache.tomcat:tomcat-util-scan:jar:8.0.0-RC7 is missing,
 no
  dependency information available
 
  I am not too concerned about the eclipse compiler, but I can't find the
  tomcat-util-scan:jar for testing...

 That JAR wasn't added to the Maven publishing script - an error I've
 just fixed.

 There will be an RC8 shortly. I just need to re-run the unit tests and
 make sure everything passes. It is late here so I'll do that tomorrow my
 time. RC8 should be available in around 12 hours or so.

 Mark


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

Couple of question about javax.el.BeanELResolver

[Violeta Georgieva]

Hi,

I have the following question about:

1. Method setValue
There is some mismatch in the javadoc. In the method description there is
the following statement:

If the property exists but does not have a setter, then a
PropertyNotFoundException is thrown.

But the throws clause states:

PropertyNotWritableException - if this resolver was constructed in
read-only mode, or if there is no setter for the property.

Our implementation currently throws PropertyNotFoundException.
I'm going to change it to throw PropertyNotWritableException.
What do you think?

Also I'm going to report a bug for this against the spec.

2. Method isReadOnly
There is not explicit statement what should be returned in case
base/property are null.
However there is statement that:

If this resolver was constructed in read-only mode, this method will
always return true.

What do you think about this change:

@@ -195,7 +195,7 @@
 throw new NullPointerException();
 }
 if (base == null || property == null) {
-return false;
+return readOnly;
 }

 context.setPropertyResolved(base, property);

Thanks
Violeta

Re: Couple of question about javax.el.BeanELResolver

[Konstantin Kolinko]

2013/7/11 Violeta Georgieva miles...@gmail.com:
 Hi,

 I have the following question about:

 1. Method setValue
 There is some mismatch in the javadoc. In the method description there is
 the following statement:

 If the property exists but does not have a setter, then a
 PropertyNotFoundException is thrown.

 But the throws clause states:

 PropertyNotWritableException - if this resolver was constructed in
 read-only mode, or if there is no setter for the property.

 Our implementation currently throws PropertyNotFoundException.
 I'm going to change it to throw PropertyNotWritableException.
 What do you think?

 Also I'm going to report a bug for this against the spec.


The javadoc at http://docs.oracle.com/javaee/7/api/javax/el/BeanELResolver.html
 says:

If this resolver was constructed in read-only mode, this method will
always throw PropertyNotWritableException.

I think it is what should actually happen. It is also easier to check
a boolean property either than use reflection to lookup whether a
property exists. I see no specification bug here.

 2. Method isReadOnly
 There is not explicit statement what should be returned in case
 base/property are null.
 However there is statement that:

 If this resolver was constructed in read-only mode, this method will
 always return true.


The same as for ResourceBundleELResolver. (That resolver is inherently
read-only but you recently changed it to return false in a similar
method).

The return value does not matter if the property has not been marked
as resolved. The docs require the caller to ignore the return value in
such a case.


 What do you think about this change:

 @@ -195,7 +195,7 @@
  throw new NullPointerException();
  }
  if (base == null || property == null) {
 -return false;
 +return readOnly;
  }

  context.setPropertyResolved(base, property);


Best regards,
Konstantin Kolinko

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

Re: Couple of question about javax.el.BeanELResolver

[Mark Thomas]

On 11/07/2013 13:49, Violeta Georgieva wrote:
 Hi,
 
 I have the following question about:
 
 1. Method setValue
 There is some mismatch in the javadoc. In the method description there is
 the following statement:
 
 If the property exists but does not have a setter, then a
 PropertyNotFoundException is thrown.
 
 But the throws clause states:
 
 PropertyNotWritableException - if this resolver was constructed in
 read-only mode, or if there is no setter for the property.
 
 Our implementation currently throws PropertyNotFoundException.
 I'm going to change it to throw PropertyNotWritableException.
 What do you think?

On balance, PropertyNotWritableException seems the better option in this
case.

 Also I'm going to report a bug for this against the spec.

+1.

 2. Method isReadOnly
 There is not explicit statement what should be returned in case
 base/property are null.
 However there is statement that:
 
 If this resolver was constructed in read-only mode, this method will
 always return true.
 
 What do you think about this change:
 
 @@ -195,7 +195,7 @@
  throw new NullPointerException();
  }
  if (base == null || property == null) {
 -return false;
 +return readOnly;
  }

If base != null and property == null my reading of the javadoc is a
PropertyNotFoundException should be thrown.

Generally, I think there needs to be a tightening up of language
throughout the EL Javadoc. I'm not sure how best to raise this with the
EG. A bug per ambiguity could be a lot of bugs but I suspect a single
bug won't result in the issue being fully addressed. Maybe one bug per
class is the way to go and list all the ambiguities in the Javadoc for
that class.

Mark


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

Re: Couple of question about javax.el.BeanELResolver

[Violeta Georgieva]

2013/7/11 Konstantin Kolinko wrote:

 2013/7/11 Violeta Georgieva miles...@gmail.com:
  Hi,
 
  I have the following question about:
 
  1. Method setValue
  There is some mismatch in the javadoc. In the method description there
is
  the following statement:
 
  If the property exists but does not have a setter, then a
  PropertyNotFoundException is thrown.
 
  But the throws clause states:
 
  PropertyNotWritableException - if this resolver was constructed in
  read-only mode, or if there is no setter for the property.
 
  Our implementation currently throws PropertyNotFoundException.
  I'm going to change it to throw PropertyNotWritableException.
  What do you think?
 
  Also I'm going to report a bug for this against the spec.
 

 The javadoc at
http://docs.oracle.com/javaee/7/api/javax/el/BeanELResolver.html
  says:

 If this resolver was constructed in read-only mode, this method will
 always throw PropertyNotWritableException.

 I think it is what should actually happen. It is also easier to check
 a boolean property either than use reflection to lookup whether a
 property exists. I see no specification bug here.

There is no bug in the specification, but in the javadoc.
I meant to open a bug to ask for a consistent javadoc.

  2. Method isReadOnly
  There is not explicit statement what should be returned in case
  base/property are null.
  However there is statement that:
 
  If this resolver was constructed in read-only mode, this method will
  always return true.
 

 The same as for ResourceBundleELResolver. (That resolver is inherently
 read-only but you recently changed it to return false in a similar
 method).

 The return value does not matter if the property has not been marked
 as resolved. The docs require the caller to ignore the return value in
 such a case.

I agree.

Re: Couple of question about javax.el.BeanELResolver

[Violeta Georgieva]

2013/7/11 Mark Thomas wrote:

 On 11/07/2013 13:49, Violeta Georgieva wrote:
  Hi,
 
  I have the following question about:
 
  1. Method setValue
  There is some mismatch in the javadoc. In the method description there
is
  the following statement:
 
  If the property exists but does not have a setter, then a
  PropertyNotFoundException is thrown.
 
  But the throws clause states:
 
  PropertyNotWritableException - if this resolver was constructed in
  read-only mode, or if there is no setter for the property.
 
  Our implementation currently throws PropertyNotFoundException.
  I'm going to change it to throw PropertyNotWritableException.
  What do you think?

 On balance, PropertyNotWritableException seems the better option in this
 case.

  Also I'm going to report a bug for this against the spec.

 +1.

thanks


  2. Method isReadOnly
  There is not explicit statement what should be returned in case
  base/property are null.
  However there is statement that:
 
  If this resolver was constructed in read-only mode, this method will
  always return true.
 
  What do you think about this change:
 
  @@ -195,7 +195,7 @@
   throw new NullPointerException();
   }
   if (base == null || property == null) {
  -return false;
  +return readOnly;
   }

 If base != null and property == null my reading of the javadoc is a
 PropertyNotFoundException should be thrown.

you are right on a second reading this should throw exception


 Generally, I think there needs to be a tightening up of language
 throughout the EL Javadoc. I'm not sure how best to raise this with the
 EG. A bug per ambiguity could be a lot of bugs but I suspect a single
 bug won't result in the issue being fully addressed. Maybe one bug per
 class is the way to go and list all the ambiguities in the Javadoc for
 that class.

 Mark


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

[Bug 54942] New: a design question of websocket

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54942

Bug ID: 54942
   Summary: a design question of websocket
   Product: Tomcat 7
   Version: 7.0.39
  Hardware: PC
OS: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: gaochan...@126.com
Classification: Unclassified

hi,boys:
there is a design question in the bound!
for example:
in my wesocketservlet, i write a loop in broadcast.
eg.
private void broadcast(String message) throws IOException{
String mmstr = ;
while(true) {
  for (ChatMessageInbound connection : connections) {
String msg = update：[ + mmstr +] is over;
 CharBuffer buffer = CharBuffer.wrap(msg);
connection.getWsOutbound().writeTextMessage(buffer);
  }   
}  
}

now,how did the servlet know it when the brower is closed?
i hope you could add a boolean in the connection so that i can filter the
connection,then change the condition of while

(true).or just a empty while with a Thread.sleep().

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 54942] a design question of websocket

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=54942

Chuck Caldarale chuck.caldar...@unisys.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Chuck Caldarale chuck.caldar...@unisys.com ---
Bugzilla is not a question and answer forum.  Post your query on the Tomcat
users' mailing list.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner

[Violeta Georgieva]

2013/3/20 Mark Thomas wrote:
 On 20/03/2013 13:55, Violeta Georgieva wrote:
 Hi,

 I have a question for the loader that is used in
 o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader,
 JarScannerCallback, SetString) (7.0.x trunk).

 Why don't we use the loader that is provided as a method parameter,
 but instead of this we are using the thread context class loader?

 It looks like a left over from when the code was first refactored to
 create the StandardJarScanner. I agree, we should use the passed in
 class loader.

Can I introduce this change for 7.0.39 or it is late already?


 row 196 ClassLoader loader =
 row 197Thread.currentThread().getContextClassLoader();

 And why don't we start scanning from its parent, but instead of this
 we start with it directly?

 Because of the possibility of external repositories having been
 configured. There are other ways this could be handled but the current
 code works. In Tomcat 8 the new resources implementation makes all this
 a lot simpler.

I understand.


 I can see that in tomcat/trunk we are using the provided loader and we
 start scanning from its parent.

 The Javadoc needs correcting as well.


I'll correct it also.


Thanks
Vily

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

Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner

[Mark Thomas]

On 21/03/2013 08:09, Violeta Georgieva wrote:
 2013/3/20 Mark Thomas wrote:
 On 20/03/2013 13:55, Violeta Georgieva wrote:
 Hi,

 I have a question for the loader that is used in
 o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader,
 JarScannerCallback, SetString) (7.0.x trunk).

 Why don't we use the loader that is provided as a method parameter,
 but instead of this we are using the thread context class loader?

 It looks like a left over from when the code was first refactored to
 create the StandardJarScanner. I agree, we should use the passed in
 class loader.
 
 Can I introduce this change for 7.0.39 or it is late already?

Go for it. The Base64 encoder/decoder discussion needs to be resolved
first so there is plenty of time for this.

Mark


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

Question for the loader used in o.a.t.util.scan.StandardJarScanner

[Violeta Georgieva]

Hi,

I have a question for the loader that is used in
o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader,
JarScannerCallback, SetString) (7.0.x trunk).

Why don't we use the loader that is provided as a method parameter,
but instead of this we are using the thread context class loader?

row 196 ClassLoader loader =
row 197Thread.currentThread().getContextClassLoader();

And why don't we start scanning from its parent, but instead of this
we start with it directly?

I can see that in tomcat/trunk we are using the provided loader and we
start scanning from its parent.

Thanks
Violeta

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

Re: Question for the loader used in o.a.t.util.scan.StandardJarScanner

[Mark Thomas]

On 20/03/2013 13:55, Violeta Georgieva wrote:
 Hi,
 
 I have a question for the loader that is used in
 o.a.t.util.scan.StandardJarScanner.scan(ServletContext, ClassLoader,
 JarScannerCallback, SetString) (7.0.x trunk).
 
 Why don't we use the loader that is provided as a method parameter,
 but instead of this we are using the thread context class loader?

It looks like a left over from when the code was first refactored to
create the StandardJarScanner. I agree, we should use the passed in
class loader.

 row 196 ClassLoader loader =
 row 197Thread.currentThread().getContextClassLoader();
 
 And why don't we start scanning from its parent, but instead of this
 we start with it directly?

Because of the possibility of external repositories having been
configured. There are other ways this could be handled but the current
code works. In Tomcat 8 the new resources implementation makes all this
a lot simpler.

 I can see that in tomcat/trunk we are using the provided loader and we
 start scanning from its parent.

The Javadoc needs correcting as well.

Mark

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

Question on SERVLET_SPEC-57 (getSubmittedFileName)

[Nick Williams]

I'm implementing the Part#getSubmittedFileName method introduced in 
SERVLET_SPEC-57 [1].

o.a.c.core.ApplicationPart already has a getFilename method that accomplishes 
this that is not part of the interface but IS public. This method is used only 
in o.a.c.connector.Request (once), but that's easy to change. The concern is 
that renaming this method might break applications that depend on the old 
method name (despite the fact that using Tomcat proprietary code makes their 
application non-portable). Is it a problem to rename this method in a new major 
version, or should Part have both methods, with one calling the other?

[1] http://java.net/jira/browse/SERVLET_SPEC-57
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

[Mark Thomas]

Renaming the method is fine.

We don't change the API for the sake of it but if there is a need to then it is 
fine.

Mark

Nick Williams nicho...@nicholaswilliams.net wrote:

I'm implementing the Part#getSubmittedFileName method introduced in
SERVLET_SPEC-57 [1].

o.a.c.core.ApplicationPart already has a getFilename method that
accomplishes this that is not part of the interface but IS public. This
method is used only in o.a.c.connector.Request (once), but that's easy
to change. The concern is that renaming this method might break
applications that depend on the old method name (despite the fact that
using Tomcat proprietary code makes their application non-portable). Is
it a problem to rename this method in a new major version, or should
Part have both methods, with one calling the other?

[1] http://java.net/jira/browse/SERVLET_SPEC-57
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org


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

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

[Nick Williams]

On Mar 9, 2013, at 3:15 PM, Nick Williams wrote:

 I'm implementing the Part#getSubmittedFileName method introduced in 
 SERVLET_SPEC-57 [1].
 
 o.a.c.core.ApplicationPart already has a getFilename method that accomplishes 
 this that is not part of the interface but IS public. This method is used 
 only in o.a.c.connector.Request (once), but that's easy to change. The 
 concern is that renaming this method might break applications that depend on 
 the old method name (despite the fact that using Tomcat proprietary code 
 makes their application non-portable). Is it a problem to rename this method 
 in a new major version, or should Part have both methods, with one calling 
 the other?
 
 [1] http://java.net/jira/browse/SERVLET_SPEC-57

Based on what others had done in the past, I deprecated getFilename and wrapped 
it around getSubmittedFileName. Patch has been submitted via bug #54658. If I 
need to remove getFilename instead of deprecating it, I can resubmit my patch 
if asked.

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

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

[Nick Williams]

On Mar 9, 2013, at 3:49 PM, Mark Thomas wrote:

 Renaming the method is fine.
 
 We don't change the API for the sake of it but if there is a need to then it 
 is fine.
 
 Mark

Look at you top-posting. :-P

You replied just as I was. I deprecated getFilename and wrapped it around 
getSubmittedFileName and submitted patch via bug #54658.

Let me know if I should just remove it and re-submit patch.

Nick

 
 Nick Williams nicho...@nicholaswilliams.net wrote:
 
 I'm implementing the Part#getSubmittedFileName method introduced in
 SERVLET_SPEC-57 [1].
 
 o.a.c.core.ApplicationPart already has a getFilename method that
 accomplishes this that is not part of the interface but IS public. This
 method is used only in o.a.c.connector.Request (once), but that's easy
 to change. The concern is that renaming this method might break
 applications that depend on the old method name (despite the fact that
 using Tomcat proprietary code makes their application non-portable). Is
 it a problem to rename this method in a new major version, or should
 Part have both methods, with one calling the other?
 
 [1] http://java.net/jira/browse/SERVLET_SPEC-57
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 


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

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

[Konstantin Kolinko]

2013/3/10 Nick Williams nicho...@nicholaswilliams.net:

 On Mar 9, 2013, at 3:49 PM, Mark Thomas wrote:

 Renaming the method is fine.

 We don't change the API for the sake of it but if there is a need to then it 
 is fine.

 Mark

 Look at you top-posting. :-P

 You replied just as I was. I deprecated getFilename and wrapped it around 
 getSubmittedFileName and submitted patch via bug #54658.

 Let me know if I should just remove it and re-submit patch.

 Nick


 Nick Williams nicho...@nicholaswilliams.net wrote:

 I'm implementing the Part#getSubmittedFileName method introduced in
 SERVLET_SPEC-57 [1].

 o.a.c.core.ApplicationPart already has a getFilename method that
 accomplishes this that is not part of the interface but IS public. This
 method is used only in o.a.c.connector.Request (once), but that's easy
 to change. The concern is that renaming this method might break
 applications that depend on the old method name (despite the fact that
 using Tomcat proprietary code makes their application non-portable). Is
 it a problem to rename this method in a new major version, or should
 Part have both methods, with one calling the other?

 [1] http://java.net/jira/browse/SERVLET_SPEC-57


1. The @Deprecated method needs a @deprecated Javadoc comment as well,
explaining what the replacement is.

2. o.a.c.manager.HTMLManagerServlet.extractFilename() would better be
replaced with a call to the new API.

(BTW, the current code there is the same as in Part.getFilename()).

Best regards,
Konstantin Kolinko

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

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

[Mark Thomas]

Nick Williams nicho...@nicholaswilliams.net wrote:


On Mar 9, 2013, at 3:49 PM, Mark Thomas wrote:

 Renaming the method is fine.
 
 We don't change the API for the sake of it but if there is a need to
then it is fine.
 
 Mark

Look at you top-posting. :-P

:-) 

Sorry. Mobile client wasn't configured properly.


You replied just as I was. I deprecated getFilename and wrapped it
around getSubmittedFileName and submitted patch via bug #54658.

Let me know if I should just remove it and re-submit patch.

No need. We can backport it to 7.0.x with the deprecation and then remove it in 
8.0.x after.

Note Konstantin's comments though.

Mark

Nick

 
 Nick Williams nicho...@nicholaswilliams.net wrote:
 
 I'm implementing the Part#getSubmittedFileName method introduced in
 SERVLET_SPEC-57 [1].
 
 o.a.c.core.ApplicationPart already has a getFilename method that
 accomplishes this that is not part of the interface but IS public.
This
 method is used only in o.a.c.connector.Request (once), but that's
easy
 to change. The concern is that renaming this method might break
 applications that depend on the old method name (despite the fact
that
 using Tomcat proprietary code makes their application non-portable).
Is
 it a problem to rename this method in a new major version, or should
 Part have both methods, with one calling the other?
 
 [1] http://java.net/jira/browse/SERVLET_SPEC-57

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


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



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

Re: Question on SERVLET_SPEC-57 (getSubmittedFileName)

[Nick Williams]

On Mar 9, 2013, at 4:57 PM, Mark Thomas wrote:

 Nick Williams nicho...@nicholaswilliams.net wrote:
 
 
 On Mar 9, 2013, at 3:49 PM, Mark Thomas wrote:
 
 Renaming the method is fine.
 
 We don't change the API for the sake of it but if there is a need to
 then it is fine.
 
 Mark
 
 Look at you top-posting. :-P
 
 :-) 
 
 Sorry. Mobile client wasn't configured properly.

A likely story.

 
 
 You replied just as I was. I deprecated getFilename and wrapped it
 around getSubmittedFileName and submitted patch via bug #54658.
 
 Let me know if I should just remove it and re-submit patch.
 
 No need. We can backport it to 7.0.x with the deprecation and then remove it 
 in 8.0.x after.
 
 Note Konstantin's comments though.

Done and updated patch submitted.

 1. The @Deprecated method needs a @deprecated Javadoc comment as well,
 explaining what the replacement is.

Done.

 
 2. o.a.c.manager.HTMLManagerServlet.extractFilename() would better be
 replaced with a call to the new API.
 
 (BTW, the current code there is the same as in Part.getFilename()).

Done. Hurray for removing duplicated code!

 
 Mark
 
 Nick
 
 
 Nick Williams nicho...@nicholaswilliams.net wrote:
 
 I'm implementing the Part#getSubmittedFileName method introduced in
 SERVLET_SPEC-57 [1].
 
 o.a.c.core.ApplicationPart already has a getFilename method that
 accomplishes this that is not part of the interface but IS public.
 This
 method is used only in o.a.c.connector.Request (once), but that's
 easy
 to change. The concern is that renaming this method might break
 applications that depend on the old method name (despite the fact
 that
 using Tomcat proprietary code makes their application non-portable).
 Is
 it a problem to rename this method in a new major version, or should
 Part have both methods, with one calling the other?
 
 [1] http://java.net/jira/browse/SERVLET_SPEC-57
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 


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

Question about bug 51526

[Violeta Georgieva]

Hi,

I would like to work on this enhancement request [1].
What do you think? Is it Ok to provide implementation for it in Tomcat 7?

Thanks
Violeta

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51526

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

Re: Question about bug 51526

[Mark Thomas]

On 11/02/2013 18:23, Violeta Georgieva wrote:
 Hi,
 
 I would like to work on this enhancement request [1].
 What do you think? Is it Ok to provide implementation for it in Tomcat 7?

For addWebapp, processing META-INF/context.xml seems reasonable to me. I
don't have an issue with that feature being back-ported from trunk to
7.0.x. Other committers may disagree.

Mark

 
 Thanks
 Violeta
 
 [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51526
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 


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

RE: Tomcat 8 question

[Williams, Nick]

Thanks, Mark.

Also, thanks Violeta for pointing out Mark's slides where he mentions JSP 2.3.

Nick

On 20/01/2013 07:14, Violeta Georgieva wrote:
 Hi,

 2013/1/20 Williams, Nick

 So, will Tomcat 8 be targeted for EE 7, or will it wait until
 JSP-next comes out, even if that takes a good deal longer than EE 7?

 Also, I know that a lot depends on the timeline of EE 7, but now that
 that date is approaching, do we have a GENERAL timeframe for Tomcat
 8? Are we talking late 2013? Or could it take until 2014?


 Check Mark's presentation [1]

There will be a maintenance release of the JSP specification. The only 
potential change I am aware of is limiting the HTTP methods that JSPs respond 
to to HEAD, GET and POST.

How long the first Tomcat 8 release (that fully implements the specs) takes 
depends on how much time folks spend on implementing them. I'll have an update 
on Tomcat 8 progress at ApacheCon NA next month and the slides will be 
available from the usual place once I have written them.

As always, help is appreciated.

Mark

This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.


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

Re: Tomcat 8 question

[Mark Thomas]

On 20/01/2013 07:14, Violeta Georgieva wrote:
 Hi,
 
 2013/1/20 Williams, Nick
 
 So, will Tomcat 8 be targeted for EE 7, or will it wait until JSP-next
 comes out, even if that takes a good deal longer than EE 7?

 Also, I know that a lot depends on the timeline of EE 7, but now that that
 date is approaching, do we have a GENERAL timeframe for Tomcat 8? Are we
 talking late 2013? Or could it take until 2014?


 Check Mark's presentation [1]

There will be a maintenance release of the JSP specification. The only
potential change I am aware of is limiting the HTTP methods that JSPs
respond to to HEAD, GET and POST.

How long the first Tomcat 8 release (that fully implements the specs)
takes depends on how much time folks spend on implementing them. I'll
have an update on Tomcat 8 progress at ApacheCon NA next month and the
slides will be available from the usual place once I have written them.

As always, help is appreciated.

Mark


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

Tomcat 8 question

[Williams, Nick]

Back in August 2011 (a long time ago, I know) Mark wrote a blog posting about 
Tomcat 8 and Java 7:

http://www.tomcatexpert.com/blog/2011/08/25/apache-tomcat-8-and-java-7-will-they-work-together

In it, he said We create a new major version of Tomcat when there are new 
versions of three specifications-Servlet, JavaServer Pages (JSP) and Expression 
Language (EL). I know I keep hearing about Tomcat 8 being for Java EE 7, but 
as of yet I haven't found any evidence at all that EE 7 will include a new 
version of the JSP specification. I have found several lists, one of them only 
a week old, of all the specifications in EE 7, and JSP-next was not among them. 
My Google searches for JSP 2.3 and JSP 3.0 yielded no results that actually 
had anything to do with the next JSP specification.

So, will Tomcat 8 be targeted for EE 7, or will it wait until JSP-next comes 
out, even if that takes a good deal longer than EE 7?

Also, I know that a lot depends on the timeline of EE 7, but now that that date 
is approaching, do we have a GENERAL timeframe for Tomcat 8? Are we talking 
late 2013? Or could it take until 2014?

Thanks,

Nick

This e-mail may contain privileged or confidential information. If you are not 
the intended recipient: (1) you may not disclose, use, distribute, copy or rely 
upon this message or attachment(s); and (2) please notify the sender by reply 
e-mail, and then delete this message and its attachment(s). Underwriters 
Laboratories Inc. and its affiliates disclaim all liability for any errors, 
omissions, corruption or virus in this message or any attachments.

Re: Tomcat 8 question

[Violeta Georgieva]

Hi,

2013/1/20 Williams, Nick

 So, will Tomcat 8 be targeted for EE 7, or will it wait until JSP-next
 comes out, even if that takes a good deal longer than EE 7?

 Also, I know that a lot depends on the timeline of EE 7, but now that that
 date is approaching, do we have a GENERAL timeframe for Tomcat 8? Are we
 talking late 2013? Or could it take until 2014?


Check Mark's presentation [1]

Regards
Violeta

[1]
http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat8-preview.pdf

Question about a change in the el-api in v7.0.14

[Emmanuel Poitier]

All,

This is my first post for the Tomcat project, and I do hope it is the
right place for this question, as it is involving a change in the
development branch.

I have implemented my own EL based on the EL API. The EL API interface
provided in Tomcat I used up to v7.0.12 made all my test pass, and then
when I switched to v7.0.14, I have two errors returned when accessing an
Integer instance from a Map of properties.

Please see below the patch I have extracted between v7.0.12 and v7.0.14
explaining the issue I have seen and I would like to understand the
reason of returning an Object.class and not the class type of the value
stored ?

Thanks in advance for your help, and if this is not the right place I
should ask this question, just tell me and I will send it to the user
mailing list.

diff -uNrbB javax/el/ListELResolver.java
../../apache-tomcat-7.0.14-src/java/javax/el/ListELResolver.java
--- javax/el/ListELResolver.java2011-04-01 17:16:46 +
+++ ../../apache-tomcat-7.0.14-src/java/javax/el/ListELResolver.java   
2011-05-09 21:44:02 +
@@ -74,8 +74,7 @@
 throw new PropertyNotFoundException(
 new
ArrayIndexOutOfBoundsException(idx).getMessage());
 }
-Object obj = list.get(idx);
-return (obj != null) ? obj.getClass() : null;
+return Object.class;
 }
 
 return null;
diff -uNrbB javax/el/MapELResolver.java
../../apache-tomcat-7.0.14-src/java/javax/el/MapELResolver.java
--- javax/el/MapELResolver.java2011-04-01 17:16:46 +
+++ ../../apache-tomcat-7.0.14-src/java/javax/el/MapELResolver.java   
2011-05-09 21:44:02 +
@@ -64,8 +64,7 @@
 
 if (base instanceof Map?,?) {
 context.setPropertyResolved(true);
-Object obj = ((Map?,?) base).get(property);
-return (obj != null) ? obj.getClass() : null;
+return Object.class;
 }

 return null;

Best regards,
-- 
Emmanuel Poitier- Chief Executive Officer (CEO)
Enman

Telephone:+33 (0)2 54 67 15 38  
Mobile:+33 (0)64 9461 586
Email:emmanuel.poit...@enman.fr 
Web site:http://enman.fr

attachment: emmanuel_poitier.vcf

smime.p7s
Description: Signature cryptographique S/MIME

Re: Question about a change in the el-api in v7.0.14

[Mark Thomas]

On 07/01/2013 10:03, Emmanuel Poitier wrote:
 All,
 
 This is my first post for the Tomcat project, and I do hope it is the
 right place for this question, as it is involving a change in the
 development branch.

This is one of a the few questions that could be asked on either list.
As a general rule, if you are unsure you should use the users mailing list.

 I have implemented my own EL based on the EL API. The EL API interface
 provided in Tomcat I used up to v7.0.12 made all my test pass, and then
 when I switched to v7.0.14, I have two errors returned when accessing an
 Integer instance from a Map of properties.
 
 Please see below the patch I have extracted between v7.0.12 and v7.0.14
 explaining the issue I have seen and I would like to understand the
 reason of returning an Object.class and not the class type of the value
 stored ?
 
 Thanks in advance for your help, and if this is not the right place I
 should ask this question, just tell me and I will send it to the user
 mailing list.

If you want to understand the reason for a change, then the first place
you should look is the change history for the files in question.

The ASF provides a web based interface to this at [1]. The organisation
of Tomcat's part of the tree is described in [2]. The history you need
to read is [3] which will lead you to [4] and the Expression Language
2.2 specification sections 2.14.7 and 2.15.7

all of which will explain why the change was made.

Mark


[1] http://svn.apache.org/viewvc/
[2] http://tomcat.apache.org/svn.html
[3]
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/ListELResolver.java?view=log
[4] https://issues.apache.org/bugzilla/show_bug.cgi?id=51177


 
 diff -uNrbB javax/el/ListELResolver.java
 ../../apache-tomcat-7.0.14-src/java/javax/el/ListELResolver.java
 --- javax/el/ListELResolver.java2011-04-01 17:16:46 +
 +++ ../../apache-tomcat-7.0.14-src/java/javax/el/ListELResolver.java   
 2011-05-09 21:44:02 +
 @@ -74,8 +74,7 @@
  throw new PropertyNotFoundException(
  new
 ArrayIndexOutOfBoundsException(idx).getMessage());
  }
 -Object obj = list.get(idx);
 -return (obj != null) ? obj.getClass() : null;
 +return Object.class;
  }
  
  return null;
 diff -uNrbB javax/el/MapELResolver.java
 ../../apache-tomcat-7.0.14-src/java/javax/el/MapELResolver.java
 --- javax/el/MapELResolver.java2011-04-01 17:16:46 +
 +++ ../../apache-tomcat-7.0.14-src/java/javax/el/MapELResolver.java   
 2011-05-09 21:44:02 +
 @@ -64,8 +64,7 @@
  
  if (base instanceof Map?,?) {
  context.setPropertyResolved(true);
 -Object obj = ((Map?,?) base).get(property);
 -return (obj != null) ? obj.getClass() : null;
 +return Object.class;
  }
 
  return null;
 
 Best regards,
 -- 
 Emmanuel Poitier- Chief Executive Officer (CEO)
 Enman
 
 Telephone:+33 (0)2 54 67 15 38
   Mobile:+33 (0)64 9461 586
 Email:emmanuel.poit...@enman.fr   
   Web site:http://enman.fr
 


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

Re: Question about a change in the el-api in v7.0.14

[Emmanuel Poitier]

Mark,

thanks for the prompt answer, and yes I do know now why the change was made.

Le 07/01/2013 11:20, Mark Thomas a écrit :
 On 07/01/2013 10:03, Emmanuel Poitier wrote:
 All,

 This is my first post for the Tomcat project, and I do hope it is the
 right place for this question, as it is involving a change in the
 development branch.
 This is one of a the few questions that could be asked on either list.
 As a general rule, if you are unsure you should use the users mailing list.

 I have implemented my own EL based on the EL API. The EL API interface
 provided in Tomcat I used up to v7.0.12 made all my test pass, and then
 when I switched to v7.0.14, I have two errors returned when accessing an
 Integer instance from a Map of properties.

 Please see below the patch I have extracted between v7.0.12 and v7.0.14
 explaining the issue I have seen and I would like to understand the
 reason of returning an Object.class and not the class type of the value
 stored ?

 Thanks in advance for your help, and if this is not the right place I
 should ask this question, just tell me and I will send it to the user
 mailing list.
 If you want to understand the reason for a change, then the first place
 you should look is the change history for the files in question.

 The ASF provides a web based interface to this at [1]. The organisation
 of Tomcat's part of the tree is described in [2]. The history you need
 to read is [3] which will lead you to [4] and the Expression Language
 2.2 specification sections 2.14.7 and 2.15.7

 all of which will explain why the change was made.

 Mark


 [1] http://svn.apache.org/viewvc/
 [2] http://tomcat.apache.org/svn.html
 [3]
 http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/ListELResolver.java?view=log
 [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=51177


 diff -uNrbB javax/el/ListELResolver.java
 ../../apache-tomcat-7.0.14-src/java/javax/el/ListELResolver.java
 --- javax/el/ListELResolver.java2011-04-01 17:16:46 +
 +++ ../../apache-tomcat-7.0.14-src/java/javax/el/ListELResolver.java   
 2011-05-09 21:44:02 +
 @@ -74,8 +74,7 @@
  throw new PropertyNotFoundException(
  new
 ArrayIndexOutOfBoundsException(idx).getMessage());
  }
 -Object obj = list.get(idx);
 -return (obj != null) ? obj.getClass() : null;
 +return Object.class;
  }
  
  return null;
 diff -uNrbB javax/el/MapELResolver.java
 ../../apache-tomcat-7.0.14-src/java/javax/el/MapELResolver.java
 --- javax/el/MapELResolver.java2011-04-01 17:16:46 +
 +++ ../../apache-tomcat-7.0.14-src/java/javax/el/MapELResolver.java   
 2011-05-09 21:44:02 +
 @@ -64,8 +64,7 @@
  
  if (base instanceof Map?,?) {
  context.setPropertyResolved(true);
 -Object obj = ((Map?,?) base).get(property);
 -return (obj != null) ? obj.getClass() : null;
 +return Object.class;
  }
 
  return null;

 Best regards,
 -- 
 Emmanuel Poitier- Chief Executive Officer (CEO)
 Enman

 Telephone:+33 (0)2 54 67 15 38   
  Mobile:+33 (0)64 9461 586
 Email:emmanuel.poit...@enman.fr  
  Web site:http://enman.fr


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


Best regards,
-- 
Emmanuel Poitier- Chief Executive Officer (CEO)
Enman

Telephone:+33 (0)2 54 67 15 38  
Mobile:+33 (0)64 9461 586
Email:emmanuel.poit...@enman.fr 
Web site:http://enman.fr

attachment: emmanuel_poitier.vcf

smime.p7s
Description: Signature cryptographique S/MIME

Re: Question about bug 54284

[Mark Thomas]

On 03/01/2013 14:30, Violeta Georgieva wrote:

 I think that when the filter name is NULL the proper behaviour is to return
 IllegalArgumentException.
 From other point of view the method's javadoc specifies only
 IllegalStateException and UnsupportedOperationException.
 If the method starts returning IllegalArgumentException it will be
 backwards incompatible change and also not compliant with the specification.
 
 What do you think?

I think that there is strong implication from the Javadoc that the name
is required. That said, when using this API a name isn't absolutely
necessary so it could be made optional (ignoring the JMX name issues).

IllegalArgumentException is a runtime exception so as long as it is not
added to the method signature (it doesn't need to be) that will not
break the API tests in the TCK.

 Are there any clarifications in the Servlet 3.1 specification?

Not that I am aware of. I'd suggest creating a Jira issue and requesting
clarification. I usually find to helpful to suggest a solution in the
Jira which in this case I think is that the name should be required.

The issue can be left in the NEEDINFO state with a link to the Servlet
Jira until we get clarification.

Mark


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

Re: Question about bug 54284

[Violeta Georgieva]

Thanks

2013/1/3 Mark Thomas ma...@apache.org

 On 03/01/2013 14:30, Violeta Georgieva wrote:

  I think that when the filter name is NULL the proper behaviour is to
 return
  IllegalArgumentException.
  From other point of view the method's javadoc specifies only
  IllegalStateException and UnsupportedOperationException.
  If the method starts returning IllegalArgumentException it will be
  backwards incompatible change and also not compliant with the
 specification.
 
  What do you think?

 I think that there is strong implication from the Javadoc that the name
 is required. That said, when using this API a name isn't absolutely
 necessary so it could be made optional (ignoring the JMX name issues).

 IllegalArgumentException is a runtime exception so as long as it is not
 added to the method signature (it doesn't need to be) that will not
 break the API tests in the TCK.

  Are there any clarifications in the Servlet 3.1 specification?

 Not that I am aware of. I'd suggest creating a Jira issue and requesting
 clarification. I usually find to helpful to suggest a solution in the
 Jira which in this case I think is that the name should be required.

 The issue can be left in the NEEDINFO state with a link to the Servlet
 Jira until we get clarification.

 Mark


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

[Bug 53836] New: This question is about Bug ID 40000

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=53836

  Priority: P2
Bug ID: 53836
  Assignee: dev@tomcat.apache.org
   Summary: This question is about Bug ID 4
  Severity: normal
Classification: Unclassified
OS: Linux
  Reporter: npun...@consultantemail.com
  Hardware: PC
Status: NEW
   Version: 7.0.26
 Component: Catalina
   Product: Tomcat 7

There was a workaround provided for this situation with Tomcat version 5.5.
Just wanted to confirm if it was ever fixed in the later versions. 

We are suspecting a similar issue in our environment with Tomcat 7.0.26 and
would like to know the following:

Under a situation where Tomcat's active jdbc connections = maxActive and
maxWait=-1, if Tomcat stops responding, what would be the status of the
Tomcat manager application. Will it be accessible? This will confirm if we are
hitting this bug or not as the regular application was not accessible during
the Incident but Tomcat manager application was accessible. We had to restart
the Tomcat instance to fix the situation.

Here's our config:

Resource name=
auth=Container
type=javax.sql.DataSource
driverClassName=oracle.jdbc.OracleDriver
url=jdbc:oracle:thin:@xx:1523:SID
username=some_user
password=xxx
maxActive=12
validationQuery=SELECT 1 FROM DUAL
accessToUnderlyingConnectionAllowed=true
testOnBorrow=true
maxIdle=10
maxWait=-1 /

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 53836] This question is about Bug ID 40000

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=53836

Mark Thomas ma...@apache.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Mark Thomas ma...@apache.org ---
Bugzilla is not a support forum where you can ask questions. That is what the
users mailing list is for.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

[Bug 53836] This question is about Bug ID 40000

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=53836

--- Comment #2 from Nikhil npun...@consultantemail.com ---

Hello,

Thanks for your response. I have mailed Armin who reported 4, about the
issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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

Re: A small question regarding connector.Request.getCoyoteRequest method

[Mark Thomas]

On 28/05/2012 14:07, N V Hari Krishna wrote:
 Hello all,
 
 I had few questions regarding
 org.apache.connector.Request.getCoyoteRequest() method.
 
 My questions are:
 
 Request.getCoyoteRequest() method's corresponding response method
 org.apache.catalina.connector.Response.getCoyoteResponse method
 is deprecated. I believe the intention behind that is to hide the coyote
 response object out of Tomcat. Is it correct?

No.

 If yes, but the Request.getCoyoteRequest() method is not deprecated. Does
 the coyote.Request class is allowed out of Tomcat (i.e. in my valve)? Is it
 intended for external use? Can I use coyote.Request object directly in my
 valve?

Not applicable. Premise of the questions is incorrect (see above).

 In other words: Why Response.getCoyoteResponse() method is deprecated and
 Request.getCoyoteRequest() is not deprecated?

The answer may be found in the svn logs. Look in tomact/tc7.0.x/trunk to
see why the method was deprecated.

Follow-up questions belong on the users mailing list.

Mark

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

Re: A question regarding using Tomcat

[Konstantin Kolinko]

2011/12/20 Mayank Tripathi may...@customerxps.com:
 Hi ,

 Greetings for the day.

 I've a question about using the tomcat as a TCP server. Given that tomcat
 uses basic TCPConnections how can we use it as TCP server?Are there some
 settings we need to turn on or given we already have our TCPClient how
 tomcat will be able to receive data from a port which is not wrapped in to
 HTTP?

1. Usage questions belong to users@ list, not dev@.

2. Tomcat is not a generic TCP server. It supports only certain client
protocols: HTTP(S) and AJP. That is what Connector implementations are
available.

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

A question regarding using Tomcat

[Mayank Tripathi]

Hi ,

Greetings for the day.

I've a question about using the tomcat as a TCP server. Given that tomcat
uses basic TCPConnections how can we use it as TCP server?Are there some
settings we need to turn on or given we already have our TCPClient how
tomcat will be able to receive data from a port which is not wrapped in to
HTTP?

Thanks,
Mayank

Re: question on IP for VirtualContext

[Mark Thomas]

On 16/11/2011 20:31, Sylvain Laurent wrote:
 Hello,
 
 To fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51741
 (Eclipse WTP Serve modules without publishing broken with tc7), I'd
 like to enhance the existing
 org.apache.naming.resources.VirtualDirContext with some features very
 much like in org.eclipse.jst.server.tomcat.loader.WtpDirContext ( you
 can find the source in
 http://dev.eclipse.org/viewcvs/viewvc.cgi/servertools/plugins/org.eclipse.jst.server.tomcat.core/org.eclipse.jst.server.tomcat.runtime.70.loader-src.zip?view=corevision=1.5root=WebTools_Project
 )

How is that code licensed?

Mark


 
 Tomcat's VirtualDirContext is already very close to Eclipse
 WtpDirContect, both of them have @author Fabrizio Giustina in their
 javadocs... How far am I allowed to borrow features from
 WtpDirContext back in VirtualDirContext ? how can I make this right
 for all the Intellectual Property and licenses point of view?
 
 Thanks for your help, Sylvain


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

Question regarding of an implementation of a custom Valve

[Gregor S.]

Hi guys,

for some reasons, I need to implement a Valve within Tomcat 6, and
everything's running smoothely.

I put the Valve into my Context-definition, fire up Tomcat  there we go.

However, I just don't see how I can access any parameters inside the
Valve-specification inside the Context-definition.

Let's say I have the following Valve-definition inside my Context:

Valve className=com.cr.web.util.LoginValve
   path=somePath/

How can I access the attribute path in the above definition?

I looked up the source of AccesslogValve, but I didn't see any
browsing of the Valve/

Is it that I just have to specify a getter / setter inside my
Valve-source for the corresponding attribute inside the
Valve-specification, and it will be picked up automatically?

Sorry if this is a lame question, but I'm not into Tomcat's source,
and before spending hours and hours, I'd rather ask the guys who
should know ;)

TIA!

Gregor

-- 
just because you're paranoid, don't mean they're not after you...
gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD
skype:rc46fi
gplus.to/gregor
twitter.com/#/2smart4u

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

Re: Question regarding of an implementation of a custom Valve

[Francis Galiegue]

On Fri, Oct 21, 2011 at 19:26, Gregor S. rc4...@googlemail.com wrote:
 Hi guys,

 for some reasons, I need to implement a Valve within Tomcat 6, and
 everything's running smoothely.

 I put the Valve into my Context-definition, fire up Tomcat  there we go.

 However, I just don't see how I can access any parameters inside the
 Valve-specification inside the Context-definition.

 Let's say I have the following Valve-definition inside my Context:

 Valve className=com.cr.web.util.LoginValve
   path=somePath/

 How can I access the attribute path in the above definition?

 I looked up the source of AccesslogValve, but I didn't see any
 browsing of the Valve/

 Is it that I just have to specify a getter / setter inside my
 Valve-source for the corresponding attribute inside the
 Valve-specification, and it will be picked up automatically?


Yes, exactly. In your case, .getPath() and .setPath(String).

-- 
Francis Galiegue, fgalie...@gmail.com
It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries (Stéphane Faroult, in The
Art of SQL, ISBN 0-596-00894-5)

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

DO NOT REPLY [Bug 51756] Question on driver URL Tomcat JDBC Pool with Sybase

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51756

windson.rangavajh...@gmail.com changed:

   What|Removed |Added

Summary|Tomcat JDBC Pool does not   |Question on driver URL
   |work with Sybase|Tomcat JDBC Pool with
   ||Sybase

--- Comment #2 from windson.rangavajh...@gmail.com 2011-09-05 10:25:21 UTC ---
hi

Thanks for taking your time to look at this error. I got the issue resolved.
Our db server expects appName and processId for connection, which were not
getting passed correctly. I appended them to the driver URL and it worked fine.
Please close this request for now. I am changing the subject accordingly.
Please feel free to change as per your convenience.

Thanks!

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

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

DO NOT REPLY [Bug 51756] Question on driver URL Tomcat JDBC Pool with Sybase

[bugzilla]

https://issues.apache.org/bugzilla/show_bug.cgi?id=51756

Mark Thomas ma...@apache.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

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

Question about endAccess method in org.apache.catalina.session.StandardServlet

[Ben Souther]

I'm wondering if anyone can tell me why the endAccess method (which
resets the lastAccessedTime) in
org.apache.catalina.session.StandardServlet is called by the
org.apache.catalina.connector.request.recycle() method.


/**  
 * End the access.
 */
@Override
public void endAccess() {

isNew = false;

/**
 * The servlet spec mandates to ignore request handling time
 * in lastAccessedTime.
 */
if (LAST_ACCESS_AT_START) {
this.lastAccessedTime = this.thisAccessedTime;  // = 
Here
this.thisAccessedTime = System.currentTimeMillis();
} else {
this.thisAccessedTime = System.currentTimeMillis();
this.lastAccessedTime = this.thisAccessedTime;  // = 
Here
}

if (ACTIVITY_CHECK) {
accessCount.decrementAndGet();
}

}


I'm asking because this, along with another change in TC7 breaks a
feature in my application (that has been working well in 5.5 and 6.x) by
causing every request, even to static resources like html pages, and
images, to reset the session counter.


The feature, for the curious, is an AJAX timer that can sync up with the
server to let the user know how much time is left in their session. With
listeners, I was able to store references to all active sessions in a
context scoped object.  The AJAX timer is able to read the maxInactive
and lastAccessedTime properties of the user's session, without tripping
the counter, to show them how much time is left in their session.  It
improves the security of our app by redirecting the user to the login
screen if they left the browser running until the app's session expired.
It's nice that it's able to double check to insure that it didn't switch
screens on the user until the server's session has definitely expired.


I'm able to get this working by commenting out the lines in this method
and by altering the
org.apache.catalina.connector.request.getSessionInternal method so that
it gets session handles without calling the access() method of the
session.


The spec states that every call to getSession() and getSession(boolean)
should reset the session timer but it isn't clear as to whether
requests that don't call these methods should or shouldn't update the
timer.

I'd be more than happy to put together a small patch that gets Tomcat to
handle this the way it did in version 6 if anyone is interested.

Thanks for your time.
-Ben










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

Re: Question about endAccess method in org.apache.catalina.session.StandardServlet

[Mark Thomas]

On 08/06/2011 18:33, Ben Souther wrote:
 I'm wondering if anyone can tell me why the endAccess method (which
 resets the lastAccessedTime) in
 org.apache.catalina.session.StandardServlet is called by the
 org.apache.catalina.connector.request.recycle() method.

Because the spec requires that behaviour.

 The spec states that every call to getSession() and getSession(boolean)
 should reset the session timer but it isn't clear as to whether
 requests that don't call these methods should or shouldn't update the
 timer.

The spec is crystal clear on this point. (read section 7.6)

 I'd be more than happy to put together a small patch that gets Tomcat to
 handle this the way it did in version 6 if anyone is interested.

Any such patch is highly unlikely to be accepted since it would cause
Tomcat to violate the Servlet 3.0 spec.

This is really a question for the users list. Any follow-up questions
should be asked their.

Mark



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