date:20130916

On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski nick...@gmail.com wrote:

On Fri, Sep 13, 2013 at 8:55 PM, Nick Williams
nicho...@nicholaswilliams.net wrote:

On Sep 13, 2013, at 12:42 PM, Igor Urisman wrote:

I couldn't agree more. WebSocket is provided by the container. But the
time any app code gets to run, Spring of Fall, container ought to be
done.
-Igor.

On Fri, Sep 13, 2013 at 10:38 AM, Christopher Schultz
ch...@christopherschultz.net wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 9/13/13 7:50 AM, Konstantin Kolinko wrote:
I see no issue here, as both WebSocket implementation and Spring's
WebApplicationInitializer rely on use of
javax.servlet.ServletContainerInitializer to initialize
themselves.

Reading the Servlet specification 3.1, I see no words in the
specification on the ordering of ServletContainerInitializer
instances. (It would be reasonable that they were covered by ch.
8.2.2 Ordering of web.xml and web-fragment.xml, but I see no
explicit wording there).

The fact that Tomcat uses an SCI is an implementation detail, so I'm
not sure the spec is relevant. I think it's reasonable for an SCI to
expect that the environment Tomcat provides is available without
having to resort to implementation-specific hacks like re-ordering
their own SCIs with respect to Tomcat's.

The problem of SCIs and ordering is one that will surely be a matter of
extensive discussion for Servlet 3.2. I intend to lobby heavily for a
solution to SCI ordering in Servlet 3.2; importantly, a solution that uses
existing facilities so that 3.0 and 3.1 containers can implement it
retroactively with the existing API.

From a discussion Mark and I had several months ago, Tomcat actually
orders SCIs according to the web fragment ordering. This isn't portable,
because it's not required in the spec--some containers do this, others
don't. The Spring web fragment has no defined order (see [1]). However, you
can define an absolute order in your deployment descriptor (web.xml):

absolute-ordering
others /
namespring_web/name
/absolute-ordering

Since Tomcat orders SCIs according to web-fragment order, this /should/
work. However, I don't know whether container-provided SCIs abide by this.
For example: In Jetty, container SCIs always come before application SCIs
(and if Tomcat did this, you wouldn't be having a problem).

Chris is correct that this is an implementaion detail and current
implementation uses initialization mechanism which is not precise. Since
the container exposes the ws implementation and by the spec the
ServletContext should contain the ServerContainer implementaion as
attribute, I expect that to be found in whatevet application related
framework I use. Perhaps the implementaion can be improved in way that
WsSci is invoked first.

Ordering of SCIs is still a problem for Servlet 3.2.

Mark, what is your opinion on the topic? I looked at the implementation of
WebappServiceLoader and perhaps it could be improved in a sense of the
ordering of the web-fragments. What I noticed is that the jars of the
web-fragments are processed according the ordering defined in the
descriptors. WebappServiceLoader public CollectionT load(ClassT
serviceType). However the results of the processing are put in a collection
with unpredictable iteration order (servicesFound), Hence later when the
results are obtained from the scanned resources and new instances of SCis
are obtained the instantiation order is undefined.

Thoughts?

Someone more familiar with the implementation (like Mark) could
undoubtedly tell you whether this will work, but it won't hurt to try.
Again, if it does work, it may only work in Tomcat; it might not work in
any other containers.

[1]
https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/resources/META-INF/web-fragment.xml

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

On 16/09/2013 10:00, Niki Dokovski wrote:
On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski nick...@gmail.com wrote:

On Fri, Sep 13, 2013 at 8:55 PM, Nick Williams
nicho...@nicholaswilliams.net wrote:

On Sep 13, 2013, at 12:42 PM, Igor Urisman wrote:

I couldn't agree more. WebSocket is provided by the container. But the
time any app code gets to run, Spring of Fall, container ought to be
done.
-Igor.

On Fri, Sep 13, 2013 at 10:38 AM, Christopher Schultz
ch...@christopherschultz.net wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

absolute-ordering
others /
namespring_web/name
/absolute-ordering

Ordering of SCIs is still a problem for Servlet 3.2.

Thoughts?

The only requirement on ordering is at the end of section 8.2 which
requires that application SCIs are discovered before container SCIs.
That is the opposite to what is being requested here.

The issue needs to be raised with the EG. I'd suggest you create a JIRA.

Mark

[1]
https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/resources/META-INF/web-fragment.xml

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

Re: Filtering HTTP OPTIONS request method from logs?

2013-09-16 Thread Jim Barber


On 16/09/2013 4:46 PM, André Warnier wrote:

Apologies for top posting, just following the trend.

OPTIONS are used quite a bit by e.g. DAV clients.
Won't you want also to add an IP filter then, to be able to block selectively 
only the requests from the proxies themselves ?

Cédric Couralet wrote:

Hi,

I'm also interested in a method to filter those OPTIONS.
With the same setup, I basically created my own AccessLogValve wich
does the filtering, something like :

/**
 * Don't log request when HTTP Method is one of the exclude List
 */
@Override
public void log(Request request, Response response, long time) {

if (Arrays.asList(exclude.split(,)).contains(request.getMethod())) {
return;
}

super.log(request, response, time);
}

But there must be something better.


2013/9/16 Jim Barber jim.bar...@ddihealth.com:

Hi all.

I'm hoping someone on this list can help me since I've been reading docs,
mailing lists, FAQs, and so on for hours now, and I'm not having much luck
finding an answer to my question.

I am using Tomcat version 7.0.42 as packaged in Debian Linux.
In front of my Tomcat servers, I am using haproxy for load balancing.
The haproxy load balancers are using the HTTP OPTIONS request method to
check
if the Tomcat servers are alive and healthy.

This results in log entries like the following in the Tomcat accesslog file:

10.122.32.4 - - [16/Sep/2013:17:12:49 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:51 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:53 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:55 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:57 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:59 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:01 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:03 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:05 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:07 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:09 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:11 +1000] OPTIONS / HTTP/1.0 200 -

At the moment I'm getting one of these every 2seconds, but I haven't enabled
the second load balancer for HA purposes yet.
When I do that, I'll be getting twice as many hits of this type.

This is going to result in rather large log files full of noise that I'm not
interested in.
I've been trying to work out how to filter these out.
Basically I don't want to log anything that is using the HTTP OPTIONS
Request
Method, but still want to log anything else that Tomcat usually logs.

I have a feeling it will come down to modifying the following entry in the
/etc/tomcat7/server.xml file:

Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
   prefix=localhost_access_log. suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /

Specifically adding the condition=VALUE attribute, but I have no idea
what to set
VALUE to.
The docs say that if ServletRequest.getAttribute(VALUE) returns null for
the
attribute defined in condition, then the item will be logged.
Is there an ServletRequest attribute that is null when the http request
method
is not using OPTIONS?

Or am I completely off track and there is a different way to filter these
access log messages?

Regards,

--
Jim Barber


Hi André.

I'm not sure I follow what you're saying.
I don't want an IP filter, since I need the HTTP OPTIONS check from the load
balancers to reach the Tomcat servers and a response to come back, or else the
load balancers will think the tomcat instance is unhealthy.
I just don't want that check to be logged at all.

Although there are other things that use the HTTP OPTIONS check, these load
balancers are only exposed to internal traffic requesting specific servlets
from the Tomcat servers, and so there won't be anything else of interest using
the HTTP OPTIONS request methods to the Tomcat servers.


Hi Cédric.

What you posted is some Java code that needs to be compiled and then the
resulting class file put somewhere where Tomcat can find it right?
Is it only partial code where 'exclude' was some sort of pre-populated
comma separated string?
Just checking as it doesn't look like anything that you can put direct into a
Tomcat configuration file to me.
Or is it?

Regards,

Jim Barber

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

Re: Filtering HTTP OPTIONS request method from logs?

2013-09-16 Thread André Warnier


Jim Barber wrote:

On 16/09/2013 4:46 PM, André Warnier wrote:

Apologies for top posting, just following the trend.

OPTIONS are used quite a bit by e.g. DAV clients.
Won't you want also to add an IP filter then, to be able to block 
selectively only the requests from the proxies themselves ?


Cédric Couralet wrote:

Hi,

I'm also interested in a method to filter those OPTIONS.
With the same setup, I basically created my own AccessLogValve wich
does the filtering, something like :

/**
 * Don't log request when HTTP Method is one of the exclude List
 */
@Override
public void log(Request request, Response response, long time) {

if 
(Arrays.asList(exclude.split(,)).contains(request.getMethod())) {

return;
}

super.log(request, response, time);
}

But there must be something better.


2013/9/16 Jim Barber jim.bar...@ddihealth.com:

Hi all.

I'm hoping someone on this list can help me since I've been reading 
docs,
mailing lists, FAQs, and so on for hours now, and I'm not having 
much luck

finding an answer to my question.

I am using Tomcat version 7.0.42 as packaged in Debian Linux.
In front of my Tomcat servers, I am using haproxy for load balancing.
The haproxy load balancers are using the HTTP OPTIONS request method to
check
if the Tomcat servers are alive and healthy.

This results in log entries like the following in the Tomcat 
accesslog file:


10.122.32.4 - - [16/Sep/2013:17:12:49 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:51 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:53 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:55 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:57 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:12:59 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:01 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:03 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:05 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:07 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:09 +1000] OPTIONS / HTTP/1.0 200 -
10.122.32.4 - - [16/Sep/2013:17:13:11 +1000] OPTIONS / HTTP/1.0 200 -

At the moment I'm getting one of these every 2seconds, but I haven't 
enabled

the second load balancer for HA purposes yet.
When I do that, I'll be getting twice as many hits of this type.

This is going to result in rather large log files full of noise that 
I'm not

interested in.
I've been trying to work out how to filter these out.
Basically I don't want to log anything that is using the HTTP OPTIONS
Request
Method, but still want to log anything else that Tomcat usually logs.

I have a feeling it will come down to modifying the following entry 
in the

/etc/tomcat7/server.xml file:

Valve className=org.apache.catalina.valves.AccessLogValve
directory=logs
   prefix=localhost_access_log. suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /

Specifically adding the condition=VALUE attribute, but I have no 
idea

what to set
VALUE to.
The docs say that if ServletRequest.getAttribute(VALUE) returns 
null for

the
attribute defined in condition, then the item will be logged.
Is there an ServletRequest attribute that is null when the http request
method
is not using OPTIONS?

Or am I completely off track and there is a different way to filter 
these

access log messages?

Regards,

--
Jim Barber


Hi André.

I'm not sure I follow what you're saying.
I don't want an IP filter, since I need the HTTP OPTIONS check from the 
load
balancers to reach the Tomcat servers and a response to come back, or 
else the

load balancers will think the tomcat instance is unhealthy.
I just don't want that check to be logged at all.

Although there are other things that use the HTTP OPTIONS check, these load
balancers are only exposed to internal traffic requesting specific servlets
from the Tomcat servers, and so there won't be anything else of interest 
using

the HTTP OPTIONS request methods to the Tomcat servers.


Hi Cédric.

What you posted is some Java code that needs to be compiled and then the
resulting class file put somewhere where Tomcat can find it right?

yes.


Is it only partial code where 'exclude' was some sort of pre-populated
comma separated string?

yes, it was only the basic idea.

Just checking as it doesn't look like anything that you can put direct 
into a

Tomcat configuration file to me.
Or is it?

No.

There isn't any configuration option currently that I know of, which answers 
your need.
So the solution would be indeed to either modify the AccessLogValve code (which is openly 
available), or override it (as Cedric seems to have done).


The remark that I made about the filtering of the OPTIONS requests in the logs by origin 
IP was generic, not specific to your case.
I do see a lot of such OPTIONS requests being logged also on servers which I manage,

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

On Mon, Sep 16, 2013 at 12:09 PM, Mark Thomas ma...@apache.org wrote:

On 16/09/2013 10:00, Niki Dokovski wrote:
On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski nick...@gmail.com
wrote:

On Fri, Sep 13, 2013 at 8:55 PM, Nick Williams
nicho...@nicholaswilliams.net wrote:

On Sep 13, 2013, at 12:42 PM, Igor Urisman wrote:

I couldn't agree more. WebSocket is provided by the container. But
the
time any app code gets to run, Spring of Fall, container ought to be
done.
-Igor.

On Fri, Sep 13, 2013 at 10:38 AM, Christopher Schultz
ch...@christopherschultz.net wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

The problem of SCIs and ordering is one that will surely be a matter of
extensive discussion for Servlet 3.2. I intend to lobby heavily for a
solution to SCI ordering in Servlet 3.2; importantly, a solution that
uses
existing facilities so that 3.0 and 3.1 containers can implement it
retroactively with the existing API.

From a discussion Mark and I had several months ago, Tomcat actually
orders SCIs according to the web fragment ordering. This isn't
portable,
because it's not required in the spec--some containers do this, others
don't. The Spring web fragment has no defined order (see [1]).
However, you
can define an absolute order in your deployment descriptor (web.xml):

absolute-ordering
others /
namespring_web/name
/absolute-ordering

Since Tomcat orders SCIs according to web-fragment order, this /should/
work. However, I don't know whether container-provided SCIs abide by
this.
For example: In Jetty, container SCIs always come before application
SCIs
(and if Tomcat did this, you wouldn't be having a problem).

Ordering of SCIs is still a problem for Servlet 3.2.

Mark, what is your opinion on the topic? I looked at the implementation
of
WebappServiceLoader and perhaps it could be improved in a sense of the
ordering of the web-fragments. What I noticed is that the jars of the
web-fragments are processed according the ordering defined in the
descriptors. WebappServiceLoader public CollectionT load(ClassT
serviceType). However the results of the processing are put in a
collection
with unpredictable iteration order (servicesFound), Hence later when the
results are obtained from the scanned resources and new instances of SCis
are obtained the instantiation order is undefined.

Thoughts?

The only requirement on ordering is at the end of section 8.2 which
requires that application SCIs are discovered before container SCIs.
That is the opposite to what is being requested here.

The issue needs to be raised with the EG. I'd suggest you create a JIRA.

Here is one created by Nick.
https://java.net/jira/browse/SERVLET_SPEC-79

Mark

[1]

https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/resources/META-INF/web-fragment.xml

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

Re: Filtering HTTP OPTIONS request method from logs?

2013-09-16 Thread Felix Schumacher

Am Montag, den 16.09.2013, 10:01 +0200 schrieb Cédric Couralet:
 Hi,
 
 I'm also interested in a method to filter those OPTIONS.
 With the same setup, I basically created my own AccessLogValve wich
 does the filtering, something like :
 
 /**
  * Don't log request when HTTP Method is one of the exclude List
  */
 @Override
 public void log(Request request, Response response, long time) {
 
 if (Arrays.asList(exclude.split(,)).contains(request.getMethod())) {
 return;
 }
 
 super.log(request, response, time);
 }
 
 But there must be something better.
If you look at the documentation fot the AccessLogValve
(http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Access_Log_Valve) 
you will find three config-parameters conditionIf, conditionUnless and the 
old one condition.

In your case you could set conditionUnless to junk and use a filter
to mark every request you don't want to log by setting an attribute
junk to a non-null value on that request.

In your Filter-class you would then implement the doFilter method
something like this

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest) {
   HttpServletRequest httpRequest = (HttpServletRequest) request;
   if (OPTIONS.equals(httpRequest.getMethod())) {
   request.setAttribute(junk, true);
   }
}
chain.doFilter(request, response);
}

You would probably check for the remoteIp, too, to be sure to only
exclude the HAProxy requests from your log-files.

Regards
 Felix

 
 
 2013/9/16 Jim Barber jim.bar...@ddihealth.com:
  Hi all.
 
  I'm hoping someone on this list can help me since I've been reading docs,
  mailing lists, FAQs, and so on for hours now, and I'm not having much luck
  finding an answer to my question.
 
  I am using Tomcat version 7.0.42 as packaged in Debian Linux.
  In front of my Tomcat servers, I am using haproxy for load balancing.
  The haproxy load balancers are using the HTTP OPTIONS request method to
  check
  if the Tomcat servers are alive and healthy.
 
  This results in log entries like the following in the Tomcat accesslog file:
 
  10.122.32.4 - - [16/Sep/2013:17:12:49 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:12:51 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:12:53 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:12:55 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:12:57 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:12:59 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:13:01 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:13:03 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:13:05 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:13:07 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:13:09 +1000] OPTIONS / HTTP/1.0 200 -
  10.122.32.4 - - [16/Sep/2013:17:13:11 +1000] OPTIONS / HTTP/1.0 200 -
 
  At the moment I'm getting one of these every 2seconds, but I haven't enabled
  the second load balancer for HA purposes yet.
  When I do that, I'll be getting twice as many hits of this type.
 
  This is going to result in rather large log files full of noise that I'm not
  interested in.
  I've been trying to work out how to filter these out.
  Basically I don't want to log anything that is using the HTTP OPTIONS
  Request
  Method, but still want to log anything else that Tomcat usually logs.
 
  I have a feeling it will come down to modifying the following entry in the
  /etc/tomcat7/server.xml file:
 
  Valve className=org.apache.catalina.valves.AccessLogValve
  directory=logs
 prefix=localhost_access_log. suffix=.txt
 pattern=%h %l %u %t quot;%rquot; %s %b /
 
  Specifically adding the condition=VALUE attribute, but I have no idea
  what to set
  VALUE to.
  The docs say that if ServletRequest.getAttribute(VALUE) returns null for
  the
  attribute defined in condition, then the item will be logged.
  Is there an ServletRequest attribute that is null when the http request
  method
  is not using OPTIONS?
 
  Or am I completely off track and there is a different way to filter these
  access log messages?
 
  Regards,
 
  --
  Jim Barber
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 



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

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

2013-09-16 Thread Nick Williams


On Sep 16, 2013, at 4:09 AM, Mark Thomas wrote:

 On 16/09/2013 10:00, Niki Dokovski wrote:
 On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski nick...@gmail.com wrote:
 
 
 
 
 On Fri, Sep 13, 2013 at 8:55 PM, Nick Williams 
 nicho...@nicholaswilliams.net wrote:
 
 
 On Sep 13, 2013, at 12:42 PM, Igor Urisman wrote:
 
 I couldn't agree more.  WebSocket is provided by the container.  But the
 time any app code gets to run, Spring of Fall, container ought to be
 done.
 -Igor.
 
 
 On Fri, Sep 13, 2013 at 10:38 AM, Christopher Schultz 
 ch...@christopherschultz.net wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Konstantin,
 
 On 9/13/13 7:50 AM, Konstantin Kolinko wrote:
 I see no issue here, as both WebSocket implementation and Spring's
 WebApplicationInitializer rely on use of
 javax.servlet.ServletContainerInitializer to initialize
 themselves.
 
 Reading the Servlet specification 3.1, I see no words in the
 specification on the ordering of ServletContainerInitializer
 instances. (It would be reasonable that they were covered by ch.
 8.2.2 Ordering of web.xml and web-fragment.xml, but I see no
 explicit wording there).
 
 The fact that Tomcat uses an SCI is an implementation detail, so I'm
 not sure the spec is relevant. I think it's reasonable for an SCI to
 expect that the environment Tomcat provides is available without
 having to resort to implementation-specific hacks like re-ordering
 their own SCIs with respect to Tomcat's.
 
 
 The problem of SCIs and ordering is one that will surely be a matter of
 extensive discussion for Servlet 3.2. I intend to lobby heavily for a
 solution to SCI ordering in Servlet 3.2; importantly, a solution that uses
 existing facilities so that 3.0 and 3.1 containers can implement it
 retroactively with the existing API.
 
 From a discussion Mark and I had several months ago, Tomcat actually
 orders SCIs according to the web fragment ordering. This isn't portable,
 because it's not required in the spec--some containers do this, others
 don't. The Spring web fragment has no defined order (see [1]). However, you
 can define an absolute order in your deployment descriptor (web.xml):
 
absolute-ordering
others /
namespring_web/name
/absolute-ordering
 
 Since Tomcat orders SCIs according to web-fragment order, this /should/
 work. However, I don't know whether container-provided SCIs abide by this.
 For example: In Jetty, container SCIs always come before application SCIs
 (and if Tomcat did this, you wouldn't be having a problem).
 
 
 Chris is correct that this is an implementaion detail and current
 implementation uses initialization mechanism which is not precise. Since
 the container exposes the ws implementation and by the spec the
 ServletContext should contain the ServerContainer implementaion as
 attribute, I expect that to be found in whatevet application related
 framework I use. Perhaps the implementaion can be improved in way that
 WsSci is invoked first.
 
 Ordering of SCIs is still a problem for Servlet 3.2.
 
 
 Mark, what is your opinion on the topic? I looked at the implementation of
 WebappServiceLoader and perhaps it could be improved in a sense of the
 ordering of the web-fragments. What I noticed is that the jars of the
 web-fragments are processed according the ordering defined in the
 descriptors. WebappServiceLoader  public CollectionT load(ClassT
 serviceType). However the results of the processing are put in a collection
 with unpredictable iteration order (servicesFound), Hence later when the
 results are obtained from the scanned resources and new instances of SCis
 are obtained the instantiation order is undefined.
 
 Thoughts?
 
 The only requirement on ordering is at the end of section 8.2 which
 requires that application SCIs are discovered before container SCIs.
 That is the opposite to what is being requested here.

Actually, that's not exactly what it says (quoted from 8.2.4):

 Implementations of the ServletContainerInitializer interface will be 
 discovered by the runtime's service lookup mechanism or a container specific 
 mechanism that is semantically equivalent to it. In either case, 
 ServletContainerInitializer services from web fragment JAR files that are 
 excluded from an absolute ordering MUST be ignored, and the order in which 
 these services are discovered MUST follow the application’s class loading 
 delegation model.

A lot of this depends on what your definition of discovered means. If 
discovered means invoked (I would suggest it does not), this sounds to me 
to mean that the container SCIs must run first if the container class loader is 
prioritized first (parent first class loading, optional in Tomcat), and the 
application SCIs must run first if the container class loader is prioritized 
last (parent last class loading, the default in Tomcat). But I don't think 
that's what it means. Can you point to a clarification anywhere in which 
discover is defined as invoke? That would be

Re: Using EL expressions in an ObjectFactory

2013-09-16 Thread Daniel Mikusa

On Sep 16, 2013, at 3:03 AM, Xavier Dury kal...@hotmail.com wrote:

 Hi,
 
 I switched to org.apache.tomcat:tomcat-jasper-el:8.0.0-RC1 as javax.el 3.0 
 implementation and tested with the following code:
 
 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));
 
 but I get the following error:
 
 javax.el.ELException: Function ':File' not found
   at org.apache.el.parser.AstFunction.getValue(AstFunction.java:136)
   at 
 org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
   at javax.el.ELProcessor.getValue(ELProcessor.java:129)
   at javax.el.ELProcessor.eval(ELProcessor.java:115)
   at 
 org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)
 
 Are methods importClass, importStatic and importPackage on ELManager already 
 implemented in apache EL?

Sorry, I don't think I was clear enough in my last response.  This does not 
work with Tomcat 8.0.0-RC1, but has been fixed (see the bug I referenced 
earlier).  You'll need to either build and use Tomcat trunk or wait until the 
next RC release is available.

Dan

 
 Regards,
 
 Xavier
 
 
 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Fri, 13 Sep 2013 15:38:29 -0400
 To: users@tomcat.apache.org
 
 On Sep 13, 2013, at 3:27 AM, Xavier Dury kal...@hotmail.com wrote:
 
 When I try the following:
 
 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));
 
 I get javax.el.ELException: java.lang.IllegalArgumentException: Cannot 
 convert ./ of type class java.lang.String to class java.net.URI.
 
 I'm using glassfish javax.el 3.0 implementation for my tests. Maybe the 
 problem comes from this specific implementation.
 
 Yes, that would be the problem. I've noticed the same behavior w/GlassFish's 
 EL 3.0 implementation. Try building Tomcat trunk and using it's 
 implementation or using the next Tomcat 8 RC when it's available. Neither 
 should have that problem.
 
 Dan
 
 
 
 
 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Thu, 12 Sep 2013 17:10:21 -0400
 To: users@tomcat.apache.org
 
 On Sep 12, 2013, at 7:58 AM, Xavier Dury kal...@hotmail.com wrote:
 
 Ok,
 
 I fixed the styling and the documentation. If anything else must be 
 changed, don't hesitate.
 
 In your docs, you state the following remark...
 
 Try to avoid overloaded methods/constructors as much as possible in EL 
 3.0 expression as the ELProcessor will use the first one it will find by 
 reflection.
 
 Can you clarify what you mean by this? There was a problem in RC-1 that 
 sounds similar, but it's been fixed.
 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=55483
 
 Is this a problem in trunk? Point being, if you're seeing an issue with EL 
 3.0, we should try to fix it.
 
 Dan
 
 
 
 Date: Thu, 12 Sep 2013 12:01:26 +0100
 From: ma...@apache.org
 To: users@tomcat.apache.org
 Subject: Re: Using EL expressions in an ObjectFactory
 
 On 12/09/2013 11:49, Xavier Dury wrote:
 Hi,
 
 I implemented a simple ExpressionFactory @
 https://github.com/kalgon/expression-factory.
 
 I would love to see this ExpressionFactory next to
 org.apache.naming.factory.BeanFactory in tomcat.
 
 No objections in principle.
 
 Haven't looked at the new code in detail. A few initial observations:
 - I'm assuming this is a contribution as per section 5 of the Apache
 License, version 2.0
 - There is no documentation
 - Tomcat code standards use 4 spaces for indents, not tabs
 - Some @Override markers look to be missing
 
 Mark
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

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

RE: Using EL expressions in an ObjectFactory

2013-09-16 Thread Xavier Dury

I built tomcat from trunk (rev 1523639) and I'm having the same issue I had 
with glassfish EL implementation when using overloaded methods:

javax.el.ELException: Cannot convert ./ of type class java.lang.String to class 
java.net.URI
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:482)
at 
org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:48)
at javax.el.ELContext.convertToType(ELContext.java:473)
at 
org.apache.el.lang.EvaluationContext.convertToType(EvaluationContext.java:155)
at javax.el.ELUtil.invokeConstructor(ELUtil.java:261)
at javax.el.StaticFieldELResolver.invoke(StaticFieldELResolver.java:203)
at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
at org.apache.el.parser.AstFunction.getValue(AstFunction.java:138)
at 
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
at javax.el.ELProcessor.getValue(ELProcessor.java:129)
at javax.el.ELProcessor.eval(ELProcessor.java:115)
at 
org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)

So I guess it's normal behaviour, isn't it?

I don't think EL spec does mandate implementations to make their best effort to 
find a suitable method when invoking overloaded methods.

Xavier


 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Mon, 16 Sep 2013 07:48:33 -0400
 To: users@tomcat.apache.org

 On Sep 16, 2013, at 3:03 AM, Xavier Dury kal...@hotmail.com wrote:

 Hi,

 I switched to org.apache.tomcat:tomcat-jasper-el:8.0.0-RC1 as javax.el 3.0 
 implementation and tested with the following code:

 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));

 but I get the following error:

 javax.el.ELException: Function ':File' not found
 at org.apache.el.parser.AstFunction.getValue(AstFunction.java:136)
 at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
 at javax.el.ELProcessor.getValue(ELProcessor.java:129)
 at javax.el.ELProcessor.eval(ELProcessor.java:115)
 at 
 org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)

 Are methods importClass, importStatic and importPackage on ELManager already 
 implemented in apache EL?

 Sorry, I don't think I was clear enough in my last response. This does not 
 work with Tomcat 8.0.0-RC1, but has been fixed (see the bug I referenced 
 earlier). You'll need to either build and use Tomcat trunk or wait until the 
 next RC release is available.

 Dan


 Regards,

 Xavier

 
 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Fri, 13 Sep 2013 15:38:29 -0400
 To: users@tomcat.apache.org

 On Sep 13, 2013, at 3:27 AM, Xavier Dury kal...@hotmail.com wrote:

 When I try the following:

 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));

 I get javax.el.ELException: java.lang.IllegalArgumentException: Cannot 
 convert ./ of type class java.lang.String to class java.net.URI.

 I'm using glassfish javax.el 3.0 implementation for my tests. Maybe the 
 problem comes from this specific implementation.

 Yes, that would be the problem. I've noticed the same behavior 
 w/GlassFish's EL 3.0 implementation. Try building Tomcat trunk and using 
 it's implementation or using the next Tomcat 8 RC when it's available. 
 Neither should have that problem.

 Dan



 
 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Thu, 12 Sep 2013 17:10:21 -0400
 To: users@tomcat.apache.org

 On Sep 12, 2013, at 7:58 AM, Xavier Dury kal...@hotmail.com wrote:

 Ok,

 I fixed the styling and the documentation. If anything else must be 
 changed, don't hesitate.

 In your docs, you state the following remark...

 Try to avoid overloaded methods/constructors as much as possible in EL 
 3.0 expression as the ELProcessor will use the first one it will find by 
 reflection.

 Can you clarify what you mean by this? There was a problem in RC-1 that 
 sounds similar, but it's been fixed.

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

 Is this a problem in trunk? Point being, if you're seeing an issue with 
 EL 3.0, we should try to fix it.

 Dan


 
 Date: Thu, 12 Sep 2013 12:01:26 +0100
 From: ma...@apache.org
 To: users@tomcat.apache.org
 Subject: Re: Using EL expressions in an ObjectFactory

 On 12/09/2013 11:49, Xavier Dury wrote:
 Hi,

 I implemented a simple ExpressionFactory @
 https://github.com/kalgon/expression-factory.

 I would love to see this ExpressionFactory next to
 org.apache.naming.factory.BeanFactory in tomcat.

 No objections in

Re: Apache Tomcat 7.x: Host+Alias and HTTP 301

2013-09-16 Thread jieryn

Greetings,

On Sat, Jul 20, 2013 at 12:36 AM, jieryn jie...@gmail.com wrote:
 I have multiple host names which resolve to the same
 application context, e.g. app.host1.com (host) and app.host2.com
 (alias). I have implemented this within conf/server.xml via Host and
 Alias definitions.

Just to close the loop here, I eventually did solve this with
URLRewrite filter. The documentation I was looking at was inaccurate
or maybe just mismatched against the version of the library being
used.. Alas, here is the working URLRewrite rule:

  rule
noteDomain name change from $OLDHOST1, with $OLDHOST2 Alias, to
$NEWHOST./note
condition type=server-name operator=equal
next=or$OLDHOST1/condition
condition type=server-name operator=equal$OLDHOST2/condition
from^(.*)$/from
to last=true type=permanent-redirecthttp://$NEWHOST/$1/to
  /rule

Thanks!

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

Re: too many apache digester logs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Fachhoch,

On 9/13/13 10:08 PM, fachhoch wrote:
 One more interesting thing I added  this server to my eclispe IDE
 and run from eclipse I don't get   digester logs , but when run
 from console  lots of digester logs.

This corroborates my sense that your configuration is either incorrect
or not actually being read.

I can't seem to find any information about how to get JULI into
debug mode itself (e.g. dump information about the log config
itself, and not just writing debug statements from other code). If you
can figure that out, it would be very helpful to diagnose your problem.

Perhaps someone else on the list knows how to get JULI into debug mode?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNw2+AAoJEBzwKT+lPKRYQNgP/R+47+K5+giaBh+S0gYHneY/
drKThTTy4azFyfhNbYiRNdbpp1EZUMBZAqagOkMX/2IIGYeK6mznKTNvKCyXURsL
a967A6MjpRzEuojVofmujstkfQFfDRoyulUDJ25hvqzYEUS7c2Zkl4wvtLGlM7nY
QZ6rc7Y9co6VqMb5NlMyJDZRBVYgXa28B9fb20cNZh0Q6Bsoi84eayVHwxMvEjE2
rL0YkdO23074eT615ZBYnan1mW3EEnUrcQfnXw/rhlM4/dgKnDCop8z5iUq4j6Dm
BGSnPDtTi93H3laavmJwuOCW628OVkDXhdcN0HehHM4Rmj2QsY1jt4KT4DL3yfFB
3VoZzxjbNRX531jK/ecyXLR1hR4OOl7WuXqvDf47yREIvSmZxCQhyXP3lFa9XzQm
+sC4TpbI/XYI9OfD3OPSPrg7yvSpvaQC6niOS/6wKA8QR04bSPgHqnP8Xn8ahYSA
Y5U5faASkt7q1iSaA014ummQIwBE7dwoZjkQp5X2o+8NEnHdifb5Vt4205TRntka
n46n+tyUeYj8i5A37+P6EtEoLSJsG5wRQPujXw0kzFmM/c8/cPsGcJr5iqP2CvJD
cbD8WAESurzhnNsy2iDJwJXuN9DLHAkddGGATJHZIcWp9P9rl+SQG1FPrwxgub0V
dBZVmBsXRTea5RbirTW5
=LlBp
-END PGP SIGNATURE-

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

Re: Multi-URL Access 1 Webapp

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 9/14/13 7:27 PM, Chris Arnold wrote:
 Chuck,
 
 On 9/13/13 4:38 PM, Caldarale, Charles R wrote:
 From: Chris Arnold [mailto:carn...@electrichendrix.com]
 Subject: Multi-URL Access 1 Webapp
 
 Tomcat 7.0.3 i believe
 
 Not bloody likely - 7.0.3 was never released.  If you really are 
 running on 7.0.3, you need to upgrade ASAP.
 
 We have a web app that you access from
 http://domain.tld/share. What we want to do is have clients
 access the same web app only from http://share.domain.tld. The
 domain part of that URL will change per client. So, some will
 get to it like http://share.domain1.tld and some will get to it
 from http://share.domain2.tld. Can tomcat do this or should i
 take a different approach?
 
 Assuming you get the various names registered in the appropriate 
 DNS boxes, yes.  Read the Tomcat doc and wiki, especially these 
 bits: http://tomcat.apache.org/tomcat-7.0-doc/config/host.html 
 http://wiki.apache.org/tomcat/TomcatDevelopmentVirtualHosts
 
 You can also use a filter to forward requests to the desired URL:
  http://tuckey.org/urlrewrite/
 
 
 I would say that it would be helpful to know how your webapp
 detects which client is being accessed. Are you sniffing that
 from the URL in a single webapp, or are you configuring a
 single webapp for each client (i.e. multiple webapps
 concurrently deployed).
 
 
 Not configuring a single app for each user. http://share.domain.tld
 hits apache and apache should forward the connection to tomcat

If you just need 1 deployed webapp, then simply change your webapp to
sniff the client's name from the URL. You don't need to change
anything: you still only need one (default) virtual host in Tomcat,
and you can do whatever you want (e.g. single virtual host) in httpd.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNw4JAAoJEBzwKT+lPKRYucwQAITvXSYc8b2k4JySHaiJD469
GG/mQt3NlLiTKdfiZA+CZHwuZ5oa5jAQXyMXY8LOqyecDZKMioZFakNdrA61sdP3
yx5EQwjYidTE7oYJwk4YDcSDWie4zubyA05kSbRHk6+vUJNyR0X+TXKSmqL/0b+f
Jz7bu1VuK/y4ZUg03pa7SqVxbOY+P+Yse0traiZoqcGZBWfN2nGIbpkQezJohmx6
k4sJNUGvJI92cimWPhyiI4nV9zYCf6HPc90GKYDA+HumNCnqdKNQWEp2Ybmf1vu4
biMLHQOzwg+9rLtM/0FwYz8YT7tLR7WIpQWYJqiI9UBQ3vyaUWpyjHVGF+rKbIJF
jBoQxltHEOBZhFelRA1o2eqfOHp4DJtaxWbGh18ZRGb+BOyDN4Fj/YrnE2zxZGuM
Vm5yXzxXlCcf04lO5XqTKoGfKh5P6cOaBnwCodPWJkKikVkS9Iva3tkmyE9eK5IJ
0EC/SAF6dL8c60pmBHAluYB4eA/9gumU0K65yx5sjDgHXXf1CPWVE2Flpnzm2m4F
2hqmETvrdLkeg7J6T0y3VJkN9hc0KKMAqwnfdtp0J7O9zChlbVgpYeQE9b/3f1V3
UM0MualN6iXG4MNhPRVyj/LvL+K/IjMQXWrrhaxvJhICTwXOLbBAwElsbUCpjcsv
1nK77XRwar7RQQmkdZjE
=2/CS
-END PGP SIGNATURE-

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

Re: Using EL expressions in an ObjectFactory

On 16/09/2013 14:43, Xavier Dury wrote:
 I built tomcat from trunk (rev 1523639) and I'm having the same issue I had 
 with glassfish EL implementation when using overloaded methods:
 
 javax.el.ELException: Cannot convert ./ of type class java.lang.String to 
 class java.net.URI
   at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:482)
   at 
 org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:48)
   at javax.el.ELContext.convertToType(ELContext.java:473)
   at 
 org.apache.el.lang.EvaluationContext.convertToType(EvaluationContext.java:155)
   at javax.el.ELUtil.invokeConstructor(ELUtil.java:261)
   at javax.el.StaticFieldELResolver.invoke(StaticFieldELResolver.java:203)
   at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
   at org.apache.el.parser.AstFunction.getValue(AstFunction.java:138)
   at 
 org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
   at javax.el.ELProcessor.getValue(ELProcessor.java:129)
   at javax.el.ELProcessor.eval(ELProcessor.java:115)
   at 
 org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)
 
 So I guess it's normal behaviour, isn't it?
 
 I don't think EL spec does mandate implementations to make their best effort 
 to find a suitable method when invoking overloaded methods.

My intention with the Tomcat EL implementation is to replicate, as far
as possible, the matching process that the Java compiler uses.

If you open a bug and include a test case along the lines of this
one[1], I'll take a look.

Mark

[1]
http://svn.apache.org/viewvc/tomcat/trunk/test/javax/el/TestUtil.java?view=annotate

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

Re: Filtering HTTP OPTIONS request method from logs?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jim,

On 9/16/13 3:42 AM, Jim Barber wrote:
 I'm hoping someone on this list can help me since I've been reading
 docs, mailing lists, FAQs, and so on for hours now, and I'm not
 having much luck finding an answer to my question.
 
 I am using Tomcat version 7.0.42 as packaged in Debian Linux. In
 front of my Tomcat servers, I am using haproxy for load balancing. 
 The haproxy load balancers are using the HTTP OPTIONS request
 method to check if the Tomcat servers are alive and healthy.
 
 This results in log entries like the following in the Tomcat
 accesslog file:
 
 10.122.32.4 - - [16/Sep/2013:17:12:49 +1000] OPTIONS / HTTP/1.0
 200 - 10.122.32.4 - - [16/Sep/2013:17:12:51 +1000] OPTIONS /
 HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:12:53 +1000]
 OPTIONS / HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:12:55
 +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
 [16/Sep/2013:17:12:57 +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4
 - - [16/Sep/2013:17:12:59 +1000] OPTIONS / HTTP/1.0 200 - 
 10.122.32.4 - - [16/Sep/2013:17:13:01 +1000] OPTIONS / HTTP/1.0
 200 - 10.122.32.4 - - [16/Sep/2013:17:13:03 +1000] OPTIONS /
 HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:13:05 +1000]
 OPTIONS / HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:13:07
 +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
 [16/Sep/2013:17:13:09 +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4
 - - [16/Sep/2013:17:13:11 +1000] OPTIONS / HTTP/1.0 200 -
 
 At the moment I'm getting one of these every 2seconds, but I
 haven't enabled the second load balancer for HA purposes yet. When
 I do that, I'll be getting twice as many hits of this type.
 
 This is going to result in rather large log files full of noise
 that I'm not interested in.

Playing the devil's advocate here a bit...

Why wouldn't you be interested in getting these logs? They are
requests being handled by your web server. They require (a small
amount of) time and resources to process, and indicate that your lb is
still reaching-out to determine the status of the app server.

My recommendation would be to leave those logs in there (they
accurately describe a real request) and filter them out if you want to
do some kind of analytics against your log files and consider those
OPTIONS requests to be noise.

 Valve className=org.apache.catalina.valves.AccessLogValve 
 directory=logs prefix=localhost_access_log. suffix=.txt 
 pattern=%h %l %u %t quot;%rquot; %s %b /
 
 Specifically adding the condition=VALUE attribute, but I have
 no idea what to set VALUE to.

It's not that simple: if you want to use condition, then you have a
write a Valve (can't be a Filter, since it must run *before* the
AccessLogValve) that tests the request and sets a request attribute
that will then trigger this condition.

Honestly, it's not worth it IMO.

Just use logrotate + gzip and don't worry about disk space.

If you filter-out those requests, there will come a time when you'll
look back and say wow, I wish we had all those lb requests in the log
so we could tell what's happening.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNw90AAoJEBzwKT+lPKRY5a0QAJBJK54sxoOAgmRwA3ZD7+O+
X1ckD5i/8oqhw3WSpK3F2+C979RZ0aWnt8/htAin9/Rq97MF0CxzDZIa/TYDKt+m
e4I4Mt/42Df604zRGM5pIXTj74wlCsaTdiDGgAalOgRZoj96w9bt+MM8hmNb91wK
/7UBHVXRaJbmlpLTPng+5d6R5f73LydPzcxbKGMExm889Qr3DVFLmQggx8+Gr6Ge
q36bCadfAXRNUQ606fj71XLwLENBQovHd25oF34l4ikwLiNrbh1RrCKYmk5n2QS2
nN6Lk98cb7hWIRae6XuMUPkVzm8W2dQS7gWUWZ2VEfLY1QKV4tYVma6PQaCP051N
tZ06wElAI/jqfRhoiYp4wJQdVw10z+BjD/3OyNpJhDydmwNAzZB80IsooLHAMFyf
3kIr/bDHL4sPcCXSxrn6XQEbb85bPYajccE2yKF7lisrNDMf049DMld+e94kaph6
tKoW+OqJDhFNYLfwlTBbJKGkh6zxkFadV621ltq++bHVSB4Xrg2Ut5w0ivv8g8CE
0lZnvZJdZigHRvhqwmbFE4xMfEdE1kQaZW2zkgDri4PXbftQV2SBZxacFE1T8SmH
02c4OMkXtzhlCBibg2SWXCrKql+nytGRpnfnmXqwaVWQfFFYIroksd15ATXKhS55
UeZ31WFFuZ+r05GAJobG
=lfwU
-END PGP SIGNATURE-

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

Re: Using EL expressions in an ObjectFactory

2013-09-16 Thread Daniel Mikusa

On Sep 16, 2013, at 9:43 AM, Xavier Dury kal...@hotmail.com wrote:

 I built tomcat from trunk (rev 1523639) and I'm having the same issue I had 
 with glassfish EL implementation when using overloaded methods:
 
 javax.el.ELException: Cannot convert ./ of type class java.lang.String to 
 class java.net.URI
   at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:482)
   at 
 org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:48)
   at javax.el.ELContext.convertToType(ELContext.java:473)
   at 
 org.apache.el.lang.EvaluationContext.convertToType(EvaluationContext.java:155)
   at javax.el.ELUtil.invokeConstructor(ELUtil.java:261)
   at javax.el.StaticFieldELResolver.invoke(StaticFieldELResolver.java:203)
   at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
   at org.apache.el.parser.AstFunction.getValue(AstFunction.java:138)
   at 
 org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
   at javax.el.ELProcessor.getValue(ELProcessor.java:129)
   at javax.el.ELProcessor.eval(ELProcessor.java:115)
   at 
 org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)
 
 So I guess it's normal behaviour, isn't it?

No.  Your example works fine for me,  rev# 1523651.

public class ElFileTest {
@Test
public void testElAndFile() throws IOException {
ELProcessor proc = new ELProcessor();
proc.getELManager().importClass(java.io.File);
File f = (File) proc.eval(File('./'));
Assert.assertEquals(new File(./).getCanonicalPath(), 
f.getCanonicalPath());
}
}

Dan

 
 I don't think EL spec does mandate implementations to make their best effort 
 to find a suitable method when invoking overloaded methods.
 
 Xavier
 
 
 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Mon, 16 Sep 2013 07:48:33 -0400
 To: users@tomcat.apache.org
 
 On Sep 16, 2013, at 3:03 AM, Xavier Dury kal...@hotmail.com wrote:
 
 Hi,
 
 I switched to org.apache.tomcat:tomcat-jasper-el:8.0.0-RC1 as javax.el 3.0 
 implementation and tested with the following code:
 
 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));
 
 but I get the following error:
 
 javax.el.ELException: Function ':File' not found
 at org.apache.el.parser.AstFunction.getValue(AstFunction.java:136)
 at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
 at javax.el.ELProcessor.getValue(ELProcessor.java:129)
 at javax.el.ELProcessor.eval(ELProcessor.java:115)
 at 
 org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)
 
 Are methods importClass, importStatic and importPackage on ELManager 
 already implemented in apache EL?
 
 Sorry, I don't think I was clear enough in my last response. This does not 
 work with Tomcat 8.0.0-RC1, but has been fixed (see the bug I referenced 
 earlier). You'll need to either build and use Tomcat trunk or wait until the 
 next RC release is available.
 
 Dan
 
 
 Regards,
 
 Xavier
 
 
 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Fri, 13 Sep 2013 15:38:29 -0400
 To: users@tomcat.apache.org
 
 On Sep 13, 2013, at 3:27 AM, Xavier Dury kal...@hotmail.com wrote:
 
 When I try the following:
 
 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));
 
 I get javax.el.ELException: java.lang.IllegalArgumentException: Cannot 
 convert ./ of type class java.lang.String to class java.net.URI.
 
 I'm using glassfish javax.el 3.0 implementation for my tests. Maybe the 
 problem comes from this specific implementation.
 
 Yes, that would be the problem. I've noticed the same behavior 
 w/GlassFish's EL 3.0 implementation. Try building Tomcat trunk and using 
 it's implementation or using the next Tomcat 8 RC when it's available. 
 Neither should have that problem.
 
 Dan
 
 
 
 
 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Thu, 12 Sep 2013 17:10:21 -0400
 To: users@tomcat.apache.org
 
 On Sep 12, 2013, at 7:58 AM, Xavier Dury kal...@hotmail.com wrote:
 
 Ok,
 
 I fixed the styling and the documentation. If anything else must be 
 changed, don't hesitate.
 
 In your docs, you state the following remark...
 
 Try to avoid overloaded methods/constructors as much as possible in EL 
 3.0 expression as the ELProcessor will use the first one it will find by 
 reflection.
 
 Can you clarify what you mean by this? There was a problem in RC-1 that 
 sounds similar, but it's been fixed.
 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=55483
 
 Is this a problem in

Re: Invalid Jar Index : Java 6/tomcat 5.5/linux

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sabari,

On 9/16/13 9:36 AM, Sabari Gandhi wrote:
 I am sending this  error again with more details:
 
 I am currently using Java 6 and tomcat 5.5 and my environment is
 linux.

You are about to hear this from every reply: upgrade. Tomcat 5.5 is no
longer supported. I am unaware of any critical security issues in
Tomcat 5.5.latest, but if any are identified, they will not be fixed.

You should upgrade as soon as possible to Tomcat 7.0. Most webapps
should have no trouble running with the new version of Tomcat, as the
servlet spec is supposed to be (mostly) backward-compatible. Newer
versions of Tomcat are more strict with a lot of spec concepts,
though, so you may have to make some modifications in order to upgrade.

But you really need to do it ASAP.

 I see an mysterious exception when I try to access a simple jsp
 page after tomcat is started. *When I added a new maven project
 (which in turn will create a new jar) I see the exception when i am
 trying to access an simple index.jsp. When I name the project and
 jar as mhs-beacon-agent I see the following error and when the
 project is renamed as mhs-sample-agent I don't see this error*.
 
 [...]
 
 sun.misc.InvalidJarIndexException: Invalid index 
 sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:931) 
 sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840) 
 sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:810)

 
sun.misc.URLClassPath.findResource(URLClassPath.java:176)

Looks like a damaged JAR file. What happens if you try this from the
command-line:

$ jar tf /path/to/file.jar

 We also set up remote debugging in linux and see the exception is
 happening when it is trying to look up for javax/servlet , since
 sun.misc.URLClassPath is suns own proprietary code i am not able to
 debug the code. When I extracted two jar file and did an folder /
 folder comparison I don't see any differences in index.list file or
 manifest.mf apart from the name differences. I am seeing this
 exception only in linux environment and not on mac (which is my
 developer environment)Any help is greatly appreciated.

How are you transferring the JAR file from your Mac to Linux? Possibly
a newline-mangling during FTP? (I'm reaching, here).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNxJxAAoJEBzwKT+lPKRYuMAQAJmjgNGGlwl4b83vk6MdUCXe
uDFVBQqo9BAj2MDXV8o7FxmCm35xDDlHcDkV5fpg5jAvHscaMf409NjNXZBIE3om
IVbere8KTlSu0VekjhJ35O/guto/B/j/gOu/g6iL3ARPfo9tAnIAGAAWlB+Up+cr
62+7bBbUB67VR8GiOxwboD5J27LSCt5mq8t3N9HfKb264HBpdb9ssYeopGQXD5p7
zAijNYULjL3Dp7I0hnH+RFWXID6OC7OuE02iYwmUy6sbPU6vnMWDTKa1fRTLXsPd
lnvto3a91e3RvdVC8PczXsS3qfvWokANZOaDU93qqV1IJEfGW5ZTBSuAGcR/scWu
0+3wB/ocdtN4NbNGSO9v39f5NkJxGUpDIhucW4Eq+NMUJabNCTp1mwz/iUf3h1O1
XnEEwwqSxUGb2xdECfjXeFO9hdaY59TONbr5FKmO5iWniBPYAZNYYiSQnN9DnPRM
1t7ob34uQRYloV5+FR8X0oSwwvKhTEPgxrDx/LJDOFx4NhuFVY4i1g8iuPvhqK/3
pq3wgExD9cMDIa2MaJqnNV9pi395Mnlkj7gEgi+jtGhgSJ6A6WvfZxQryA0zyLO4
tcZwO/Potpq+oOJvehwMD8kAN1v73FC10pWM1gSm6bpMzwF3wXr9jSPJDxRPUiHH
0fXuVGWFjwn1JXgnRJ8Y
=mwfN
-END PGP SIGNATURE-

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

Re: too many apache digester logs

2013-09-16 Thread Konstantin Kolinko

2013/9/16 Christopher Schultz ch...@christopherschultz.net:
 On 9/13/13 10:08 PM, fachhoch wrote:
 One more interesting thing I added  this server to my eclispe IDE
 and run from eclipse I don't get   digester logs , but when run
 from console  lots of digester logs.

 This corroborates my sense that your configuration is either incorrect
 or not actually being read.

 I can't seem to find any information about how to get JULI into
 debug mode itself (e.g. dump information about the log config
 itself, and not just writing debug statements from other code). If you
 can figure that out, it would be very helpful to diagnose your problem.

 Perhaps someone else on the list knows how to get JULI into debug mode?


1. My guess is that there is logging.properties file somewhere in
the webapp's classpath,
as I mentioned.

Apparently there is no internal logging in JULI (apart logging some
unexpected errors), but you may a) run with a debugger (see Tomcat
FAQ), b) recompile it with whatever debug statements you need.

The configuration is loaded in
org.apache.juli.ClassLoaderLogManager#readConfiguration(ClassLoader).

2. When you start Tomcat from within Eclipse IDE, by default it does
not use Tomcat's org.apache.juli.ClassLoaderLogManager,  but JRE's
default java.util.logging.LogManager. Thus you are not using JULI.

That is because Eclipse by default does not provide
-Djava.util.logging.manager and -Djava.util.logging.config.file
arguments to the JVM that it launches for Tomcat. Those are
configurable.

Best regards,
Konstantin Kolinko

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

Re: Invalid Jar Index : Java 6/tomcat 5.5/linux

2013-09-16 Thread Daniel Mikusa

On Sep 16, 2013, at 9:36 AM, Sabari Gandhi sgan...@kivasystems.com wrote:

 
 Hi,
 
 I am sending this  error again with more details:
 
 I am currently using Java 6 and tomcat 5.5

Don't use Tomcat 5.5.  It has not been supported for almost a year now.  
Upgrade ASAP.

 and my environment is linux. I see an mysterious exception when I try to 
 access a simple jsp page after tomcat is started. When I added a new maven 
 project (which in turn will create a new jar) I see the exception when i am 
 trying to access an simple index.jsp. When I name the project and jar as 
 mhs-beacon-agent I see the following error and when the project is renamed as 
 mhs-sample-agent I don't see this error. We also set up remote debugging in 
 linux and see the exception is happening when it is trying to look up for 
 javax/servlet , since sun.misc.URLClassPath is suns own proprietary code i 
 am not able to debug the code. When I extracted two jar file and did an 
 folder / folder comparison I don't see any differences in index.list file or 
 manifest.mf apart from the name differences. I am seeing this exception only 
 in linux environment and not on mac (which is my developer environment)Any 
 help is greatly appreciated. Thanks !! 
 
 Exception: 
 
 sun.misc.InvalidJarIndexException: Invalid index

Sounds like your JAR might be corrupted.  If this is a custom JAR, rebuild it.  
If it's a dependency you've downloaded with Maven, you might try clearing out 
the folders for the problem JAR(s) under ~/.m2/repository and rebuilding.  If 
a JAR downloaded by Maven is corrupted, the corrupted file it will sit on your 
local HD forever and cause problems.  Manually deleting the Maven folders for 
the JAR usually clears up the problem.

Other thought.  Upgrade your JVM.  If it's as old as your Tomcat version, you 
could be simply hitting a bug.

Dan

 sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:931)
 sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
 sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:810)
 sun.misc.URLClassPath.findResource(URLClassPath.java:176)
 java.net.URLClassLoader$2.run(URLClassLoader.java:551)
 java.net.URLClassLoader$2.run(URLClassLoader.java:549)
 java.security.AccessController.doPrivileged(Native Method)
 java.net.URLClassLoader.findResource(URLClassLoader.java:548)
 java.lang.ClassLoader.getResource(ClassLoader.java:1139)
 java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:227)
 org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1177)
 org.apache.jasper.servlet.JasperLoader.getResourceAsStream(JasperLoader.java:144)
 org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:194)
 org.apache.jasper.compiler.JDTCompiler$1.findType(JDTCompiler.java:179)
 org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:119)
 org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:178)
 org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:407)
 org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndSetImports(CompilationUnitScope.java:167)
 org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.completeTypeBindings(LookupEnvironment.java:190)
 org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:301)
 org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:315)
 org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:425)
 org.apache.jasper.compiler.Compiler.compile(Compiler.java:298)
 org.apache.jasper.compiler.Compiler.compile(Compiler.java:277)
 org.apache.jasper.compiler.Compiler.compile(Compiler.java:265)
 org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:564)
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:299)
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:315)
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:265)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
 org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:415)
 org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:234)
 org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:300)
 javax.faces.webapp.FacesServlet.service(FacesServlet.java:95)
 org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122)
 
 
 Code:
 For complete code see the following URL.
 http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/misc/URLClassPath.java#URLClassPath.JarLoader.validIndex%28java.lang.String%29
 
  /* Note that the addition of the url to the list of visited
   850 * jars incorporates a check for presence in the 
 hashmap
   851 */
   852boolean

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/16/13 5:09 AM, Mark Thomas wrote:
 The only requirement on ordering is at the end of section 8.2
 which requires that application SCIs are discovered before
 container SCIs. That is the opposite to what is being requested
 here.
 
 The issue needs to be raised with the EG. I'd suggest you create a
 JIRA.

While raising the issue with the EG might be appropriate, there's no
mandate from the EG that WebSocket services be initialized from an
SCI. I see this as a Tomcat problem, not a spec problem.

I believe it's reasonable for webapp code to expect a sane environment
during initialization. In this case, an architectural decision at the
container-implementation level (to use an SCI to get WebSocket going)
has collided with a reasonable expectation of a webapp implementer. I
don't believe the solution is to have the EG rule on this... the
solution is to make Tomcat meet expectations.

If that means changing from using an SCI to some other mechanism,
obviously the EG's opinion is moot. If you want to get the EG's ruling
and then work within that construct to get Tomcat's WebSocket SCI
working nicely in the above scenario, that's fine. But you shouldn't
use an unfavorable (or useless) ruling by the EG as cover for not
supporting this use case.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNxPsAAoJEBzwKT+lPKRY99UP/Rt2D/c9NYATnRcvDEmE7Zu9
ey1cyJ8vdcfqb3xKZKEG/N1EPwxRds8NmkuP/B4Z1uAtrV6g84DIyuBfKVg+/IZm
fyzLZG55A8GPNfiuoe5ajT4TqmhI8ngg3oYfYy42RCd8sUPWI/T3CXNAA07khLS4
E5o5bbZ+JAV4RptyLGJsdZDceijrxPKWl3KmKKTByn7hGTmcCHSlGbYmdPXJ5oMr
QX3phw7Qb42u+smpPZ1XcE2pfYy8lhJE/LlbxgWWHIaK+fSod2O9cy1U0Ls1V4kG
MIA0Vlglr5+FXPwJfW9BzNZ5pDsqAN80ip4Sk91MWiHcPscWdXRIvZS8Yjv3KVi6
r88q1F/FONClI7CxLnE0GcTjP8ZHOqVZzCxJF9CHP1pRjhEtsUEYBNe5MqXkDwE+
rDrlfwPnIAMUOdz6DeFX1es/p+k6adDaKIj+vzHtcWyeOekp1zjHFIyoO+ClmmiR
mv/VI4RXIn9PuUzaUruGojiJ+gzk4UCupoJ4EamiNBKXko9P5PBXFmszBJY7LlZY
GpWcudMTdyDE/E8ht1zWSnaSvIusbkQR+5WVTXONAOT+a2oGwqKJ8MCbb3opykG8
Vu6CAKisz67Qb9LhM2Jj6Xa6dtfXBBjlxDfJbadWcORst2hX4Jx0kag0czHyROHz
VyMgKgN3NwCuoRTgKcah
=z09t
-END PGP SIGNATURE-

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

Re: Filtering HTTP OPTIONS request method from logs?

2013-09-16 Thread Felix Schumacher

Am Montag, den 16.09.2013, 10:02 -0400 schrieb Christopher Schultz:
 Jim,
 
 On 9/16/13 3:42 AM, Jim Barber wrote:
  I'm hoping someone on this list can help me since I've been reading
  docs, mailing lists, FAQs, and so on for hours now, and I'm not
  having much luck finding an answer to my question.
  
  I am using Tomcat version 7.0.42 as packaged in Debian Linux. In
  front of my Tomcat servers, I am using haproxy for load balancing. 
  The haproxy load balancers are using the HTTP OPTIONS request
  method to check if the Tomcat servers are alive and healthy.
  
  This results in log entries like the following in the Tomcat
  accesslog file:
  
  10.122.32.4 - - [16/Sep/2013:17:12:49 +1000] OPTIONS / HTTP/1.0
  200 - 10.122.32.4 - - [16/Sep/2013:17:12:51 +1000] OPTIONS /
  HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:12:53 +1000]
  OPTIONS / HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:12:55
  +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
  [16/Sep/2013:17:12:57 +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4
  - - [16/Sep/2013:17:12:59 +1000] OPTIONS / HTTP/1.0 200 - 
  10.122.32.4 - - [16/Sep/2013:17:13:01 +1000] OPTIONS / HTTP/1.0
  200 - 10.122.32.4 - - [16/Sep/2013:17:13:03 +1000] OPTIONS /
  HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:13:05 +1000]
  OPTIONS / HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:13:07
  +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
  [16/Sep/2013:17:13:09 +1000] OPTIONS / HTTP/1.0 200 - 10.122.32.4
  - - [16/Sep/2013:17:13:11 +1000] OPTIONS / HTTP/1.0 200 -
  
  At the moment I'm getting one of these every 2seconds, but I
  haven't enabled the second load balancer for HA purposes yet. When
  I do that, I'll be getting twice as many hits of this type.
  
  This is going to result in rather large log files full of noise
  that I'm not interested in.
 
 Playing the devil's advocate here a bit...
 
 Why wouldn't you be interested in getting these logs? They are
 requests being handled by your web server. They require (a small
 amount of) time and resources to process, and indicate that your lb is
 still reaching-out to determine the status of the app server.
 
 My recommendation would be to leave those logs in there (they
 accurately describe a real request) and filter them out if you want to
 do some kind of analytics against your log files and consider those
 OPTIONS requests to be noise.
I have had one case where I wanted to get rid of those requests too, so
I can understand the OP. But I have to admint I had a scary feeling
about it.

 
  Valve className=org.apache.catalina.valves.AccessLogValve 
  directory=logs prefix=localhost_access_log. suffix=.txt 
  pattern=%h %l %u %t quot;%rquot; %s %b /
  
  Specifically adding the condition=VALUE attribute, but I have
  no idea what to set VALUE to.
 
 It's not that simple: if you want to use condition, then you have a
 write a Valve (can't be a Filter, since it must run *before* the
 AccessLogValve) that tests the request and sets a request attribute
 that will then trigger this condition.
That is not true, you can use a filter, since the logging will happen
*after* the request and can and will check the request attribute then.

 
 Honestly, it's not worth it IMO.
 
 Just use logrotate + gzip and don't worry about disk space.
 
 If you filter-out those requests, there will come a time when you'll
 look back and say wow, I wish we had all those lb requests in the log
 so we could tell what's happening.
As I admitted above that may very well be the case :)

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



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

RE: Using EL expressions in an ObjectFactory

2013-09-16 Thread Xavier Dury

I found the problem:

I was using javax.el:javax.el-api:3.0.0 as EL api jar... now, if I use the 
el-api provided by tomcat, everything works fine.

Xavier

 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Mon, 16 Sep 2013 10:05:14 -0400
 To: users@tomcat.apache.org

 On Sep 16, 2013, at 9:43 AM, Xavier Dury kal...@hotmail.com wrote:

 I built tomcat from trunk (rev 1523639) and I'm having the same issue I had 
 with glassfish EL implementation when using overloaded methods:

 javax.el.ELException: Cannot convert ./ of type class java.lang.String to 
 class java.net.URI
 at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:482)
 at 
 org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:48)
 at javax.el.ELContext.convertToType(ELContext.java:473)
 at 
 org.apache.el.lang.EvaluationContext.convertToType(EvaluationContext.java:155)
 at javax.el.ELUtil.invokeConstructor(ELUtil.java:261)
 at javax.el.StaticFieldELResolver.invoke(StaticFieldELResolver.java:203)
 at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256)
 at org.apache.el.parser.AstFunction.getValue(AstFunction.java:138)
 at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
 at javax.el.ELProcessor.getValue(ELProcessor.java:129)
 at javax.el.ELProcessor.eval(ELProcessor.java:115)
 at 
 org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)

 So I guess it's normal behaviour, isn't it?

 No. Your example works fine for me, rev# 1523651.

 public class ElFileTest {
 @Test
 public void testElAndFile() throws IOException {
 ELProcessor proc = new ELProcessor();
 proc.getELManager().importClass(java.io.File);
 File f = (File) proc.eval(File('./'));
 Assert.assertEquals(new File(./).getCanonicalPath(), f.getCanonicalPath());
 }
 }

 Dan

 I don't think EL spec does mandate implementations to make their best effort 
 to find a suitable method when invoking overloaded methods.

 Xavier

 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Mon, 16 Sep 2013 07:48:33 -0400
 To: users@tomcat.apache.org

 On Sep 16, 2013, at 3:03 AM, Xavier Dury kal...@hotmail.com wrote:

 Hi,

 I switched to org.apache.tomcat:tomcat-jasper-el:8.0.0-RC1 as javax.el 3.0 
 implementation and tested with the following code:

 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));

 but I get the following error:

 javax.el.ELException: Function ':File' not found
 at org.apache.el.parser.AstFunction.getValue(AstFunction.java:136)
 at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:188)
 at javax.el.ELProcessor.getValue(ELProcessor.java:129)
 at javax.el.ELProcessor.eval(ELProcessor.java:115)
 at 
 org.apache.naming.factory.ExpressionFactoryTest.elImplementationShouldWork(ExpressionFactoryTest.java:43)

 Are methods importClass, importStatic and importPackage on ELManager 
 already implemented in apache EL?

 Sorry, I don't think I was clear enough in my last response. This does not 
 work with Tomcat 8.0.0-RC1, but has been fixed (see the bug I referenced 
 earlier). You'll need to either build and use Tomcat trunk or wait until 
 the next RC release is available.

 Dan

 Regards,

 Xavier

 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Fri, 13 Sep 2013 15:38:29 -0400
 To: users@tomcat.apache.org

 On Sep 13, 2013, at 3:27 AM, Xavier Dury kal...@hotmail.com wrote:

 When I try the following:

 ELProcessor processor = new ELProcessor();
 processor.getELManager().importClass(java.io.File);
 processor.eval(File('./'));

 I get javax.el.ELException: java.lang.IllegalArgumentException: Cannot 
 convert ./ of type class java.lang.String to class java.net.URI.

 I'm using glassfish javax.el 3.0 implementation for my tests. Maybe the 
 problem comes from this specific implementation.

 Yes, that would be the problem. I've noticed the same behavior 
 w/GlassFish's EL 3.0 implementation. Try building Tomcat trunk and using 
 it's implementation or using the next Tomcat 8 RC when it's available. 
 Neither should have that problem.

 Dan

 Subject: Re: Using EL expressions in an ObjectFactory
 From: dmik...@gopivotal.com
 Date: Thu, 12 Sep 2013 17:10:21 -0400
 To: users@tomcat.apache.org

 On Sep 12, 2013, at 7:58 AM, Xavier Dury kal...@hotmail.com wrote:

 Ok,

 I fixed the styling and the documentation. If anything else must be 
 changed, don't hesitate.

 In your docs, you state the following remark...

 Try to avoid overloaded methods/constructors as much as possible in EL 
 3.0 expression as the ELProcessor will use the first one it will find 
 by reflection.

 Can you clarify what you mean by

Re: too many apache digester logs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Konstantin,

On 9/16/13 10:17 AM, Konstantin Kolinko wrote:
 2013/9/16 Christopher Schultz ch...@christopherschultz.net:
 On 9/13/13 10:08 PM, fachhoch wrote:
 One more interesting thing I added  this server to my eclispe
 IDE and run from eclipse I don't get   digester logs , but when
 run from console  lots of digester logs.
 
 This corroborates my sense that your configuration is either
 incorrect or not actually being read.
 
 I can't seem to find any information about how to get JULI into 
 debug mode itself (e.g. dump information about the log config 
 itself, and not just writing debug statements from other code).
 If you can figure that out, it would be very helpful to diagnose
 your problem.
 
 Perhaps someone else on the list knows how to get JULI into debug
 mode?
 
 
 1. My guess is that there is logging.properties file somewhere
 in the webapp's classpath, as I mentioned.
 
 Apparently there is no internal logging in JULI (apart logging
 some unexpected errors), but you may a) run with a debugger (see
 Tomcat FAQ), b) recompile it with whatever debug statements you
 need.
 
 The configuration is loaded in 
 org.apache.juli.ClassLoaderLogManager#readConfiguration(ClassLoader).

I've
 
added some code to ClassLoaderLogManager to dump the URL where
logging.properties is being found to System.err. You can enable this
logging in Tomcat 8 (RC2+) and Tomcat 7.0.43 (not yet released) by
setting the system property
org.apache.juli.ClassLoaderLogManager=true and restarting Tomcat.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNxr7AAoJEBzwKT+lPKRYXUgQAKy7f0Bq0w5stBOqsgpyWqf3
XyQXFfIlYTSWn4QE3KsN/DRGYVDtGSrrmvfSx3AuhzA8Hy68/OIjhIAgmxB7eDoE
DoT3zP1VkaR+hdssvhnrqk6R8LPNe6mnM9SmWwN0rJtelKcGahfyetfVadD4cJZB
2c3FZAvwxrHYm5DvhTzy+vxEZ1lj4eGnQBL8f47P3tUdhe87Z2zBU0Q6n0gaanQg
+3OJd1bjQCTm7IeRaM7lkgVFAT4pNW2ZMKFqXuXtzEeKIpTSfvUz/2s+3oroyKzz
4G1E8mLoZvrG+p4RY96VQXd9mr0b2RPN3T5SVyBuCW8hAQPaVS0wKbodNMKijJ3A
lD+NeGzFuc8W1VsGBa895dfVRkUqHIcMMUyZaL+4Y0W+jRuUlFnVSVjkJY4cW0g/
hq+N8vuo+S8cinmL32s5WLNx3/+NiEIYmwbGCa8rG328c+V5KQsn2YExXjAYHbI3
3+FHydjWUi8QaQX7wMh1xFtaecUq3wMQ8oTdAQLP9OCzsmw9neMqbJj4a40gm+Gg
5b1Gdi31Bm6hIzdzFMLZIKRiuIHsd6K4qrEDkepBsj31qjFln8m21auFLW9u2oLy
cc7Eg/z4O4gkfUVzTSszWh8oEyevMeFJAP+GD7quqIuPDqWwPhX3tU1VgP3k3uzI
WoYaSuNRJC5RCpLBsgTH
=Xj/c
-END PGP SIGNATURE-

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

Re: Filtering HTTP OPTIONS request method from logs?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Felix,

On 9/16/13 10:25 AM, Felix Schumacher wrote:
 Am Montag, den 16.09.2013, 10:02 -0400 schrieb Christopher
 Schultz:
 Jim,
 
 On 9/16/13 3:42 AM, Jim Barber wrote:
 I'm hoping someone on this list can help me since I've been
 reading docs, mailing lists, FAQs, and so on for hours now, and
 I'm not having much luck finding an answer to my question.
 
 I am using Tomcat version 7.0.42 as packaged in Debian Linux.
 In front of my Tomcat servers, I am using haproxy for load
 balancing. The haproxy load balancers are using the HTTP
 OPTIONS request method to check if the Tomcat servers are alive
 and healthy.
 
 This results in log entries like the following in the Tomcat 
 accesslog file:
 
 10.122.32.4 - - [16/Sep/2013:17:12:49 +1000] OPTIONS /
 HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:12:51 +1000]
 OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
 [16/Sep/2013:17:12:53 +1000] OPTIONS / HTTP/1.0 200 -
 10.122.32.4 - - [16/Sep/2013:17:12:55 +1000] OPTIONS /
 HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:12:57 +1000]
 OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
 [16/Sep/2013:17:12:59 +1000] OPTIONS / HTTP/1.0 200 - 
 10.122.32.4 - - [16/Sep/2013:17:13:01 +1000] OPTIONS /
 HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:13:03 +1000]
 OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
 [16/Sep/2013:17:13:05 +1000] OPTIONS / HTTP/1.0 200 -
 10.122.32.4 - - [16/Sep/2013:17:13:07 +1000] OPTIONS /
 HTTP/1.0 200 - 10.122.32.4 - - [16/Sep/2013:17:13:09 +1000]
 OPTIONS / HTTP/1.0 200 - 10.122.32.4 - -
 [16/Sep/2013:17:13:11 +1000] OPTIONS / HTTP/1.0 200 -
 
 At the moment I'm getting one of these every 2seconds, but I 
 haven't enabled the second load balancer for HA purposes yet.
 When I do that, I'll be getting twice as many hits of this
 type.
 
 This is going to result in rather large log files full of
 noise that I'm not interested in.
 
 Playing the devil's advocate here a bit...
 
 Why wouldn't you be interested in getting these logs? They are 
 requests being handled by your web server. They require (a small 
 amount of) time and resources to process, and indicate that your
 lb is still reaching-out to determine the status of the app
 server.
 
 My recommendation would be to leave those logs in there (they 
 accurately describe a real request) and filter them out if you
 want to do some kind of analytics against your log files and
 consider those OPTIONS requests to be noise.
 I have had one case where I wanted to get rid of those requests
 too, so I can understand the OP. But I have to admint I had a scary
 feeling about it.
 
 
 Valve className=org.apache.catalina.valves.AccessLogValve 
 directory=logs prefix=localhost_access_log. suffix=.txt 
 pattern=%h %l %u %t quot;%rquot; %s %b /
 
 Specifically adding the condition=VALUE attribute, but I
 have no idea what to set VALUE to.
 
 It's not that simple: if you want to use condition, then you
 have a write a Valve (can't be a Filter, since it must run
 *before* the AccessLogValve) that tests the request and sets a
 request attribute that will then trigger this condition.
 
 That is not true, you can use a filter, since the logging will
 happen *after* the request and can and will check the request
 attribute then.

Thanks for pointing that out. After I had sent my message, I realized
that and decided not to post a followup after reading yours.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNxs2AAoJEBzwKT+lPKRYJlIQAIZmTn6OA6aeNuENOAbXiXYs
U+RrWYN4HKIStoVY50Z+2x5r/5ji7j/Juqlyas649Onn05mr3p4stOhzXJXXq9v4
+jeCJLm7VK19tIB12HmjMoTKdf6GapimC0X/WQcEVXVPU2i7R9NAsltcAJGkx4cA
mmpCR/y15B4qt41UgteiIEV+8G7GGka1Zqr+J9qu/HWpAg0MWtWuVdggBjOYNRA/
RPGc2Ya3UUokaj4UAodyyQlOU4fWBXUb56w3MRlZ3z0ueA3noHT+2m8xTeAhHKrj
sYJR7bDUFkFM2z8xN3+AIcAWE5wM/AA+shuXGQDtKGvxd88rOIQhFJOFHr8h2Mkl
PIdxPcGGoj2Cn5RUkOdauhzc0TuwS7+e0zpXGJiTXdKQ0VjjPupqkde6z1v/q4IS
swzKBOPYf5xlhhEaI1hm7SvjTTulNfwT428nWMFlu3Z/9nXdkLQFcbKs3LRzYT0I
K6Y4GKX89IGCNbv3nplRQayHWYphtHEQ2eKB005hWo9Lw9IEduGMKdBX8fwcFrAL
IR3tSQoM6JaVfi2q0S6x4U/bk1asSc4FpD6UPjA4FXDHZ1cTyH7+j8IF/J5fzqlq
AxBXDSeA82CFtz+9hqc45F5ifQv6FSDR5JI1NZckYcKzXkHvtLmOyA4EP0BuiG6p
Pe7DPMTkGK3G46/9zaym
=Ggr6
-END PGP SIGNATURE-

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

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

On 16/09/2013 15:21, Christopher Schultz wrote:
 Mark,
 
 On 9/16/13 5:09 AM, Mark Thomas wrote:
 The only requirement on ordering is at the end of section 8.2 
 which requires that application SCIs are discovered before 
 container SCIs. That is the opposite to what is being requested 
 here.
 
 The issue needs to be raised with the EG. I'd suggest you create
 a JIRA.
 
 While raising the issue with the EG might be appropriate, there's
 no mandate from the EG that WebSocket services be initialized from
 an SCI. I see this as a Tomcat problem, not a spec problem.

If you read the Servlet spec it is clear that SCIs are intended for
adding capability such as WebSocket. The example used is JSP support
which is clearly in the same category.

 I believe it's reasonable for webapp code to expect a sane
 environment during initialization. In this case, an architectural
 decision at the container-implementation level (to use an SCI to
 get WebSocket going) has collided with a reasonable expectation of
 a webapp implementer. I don't believe the solution is to have the
 EG rule on this... the solution is to make Tomcat meet
 expectations.

The issue is with the lack of clarity from the EG with respect to
ordering. I read section 8.2 one way but it is open to interpretation.
Rather than change Tomcat once, then get clarification from the EG and
then have to change it again, I'd rather get clarification first and
then make any necessary changes. Clearly, there are going to have to
be changes. I can think of several ways to tackle this issue. I'd
rather design the solution with the EG mandated behaviour (even if
that is 'we don't care') in mind.

 If that means changing from using an SCI to some other mechanism,

That isn't going to happen.

 obviously the EG's opinion is moot. If you want to get the EG's
 ruling and then work within that construct to get Tomcat's
 WebSocket SCI working nicely in the above scenario, that's fine.
 But you shouldn't use an unfavorable (or useless) ruling by the EG
 as cover for not supporting this use case.

I am not looking for excuses not to support the use case. I am looking
for those that care about this issue to do the work of getting
clarification from the EG. This isn't an environment where someone
just throws a problem over the wall and waits for someone else to fix it.

Mark

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

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

On Monday, September 16, 2013, Christopher Schultz wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Mark,

 On 9/16/13 5:09 AM, Mark Thomas wrote:
  The only requirement on ordering is at the end of section 8.2
  which requires that application SCIs are discovered before
  container SCIs. That is the opposite to what is being requested
  here.
 
  The issue needs to be raised with the EG. I'd suggest you create a
  JIRA.

 While raising the issue with the EG might be appropriate, there's no
 mandate from the EG that WebSocket services be initialized from an
 SCI. I see this as a Tomcat problem, not a spec problem.


I'm willing to take a look at the issue in the next few days and propose
smth for review.
Niki



 I believe it's reasonable for webapp code to expect a sane environment
 during initialization. In this case, an architectural decision at the
 container-implementation level (to use an SCI to get WebSocket going)
 has collided with a reasonable expectation of a webapp implementer. I
 don't believe the solution is to have the EG rule on this... the
 solution is to make Tomcat meet expectations.

 If that means changing from using an SCI to some other mechanism,
 obviously the EG's opinion is moot. If you want to get the EG's ruling
 and then work within that construct to get Tomcat's WebSocket SCI
 working nicely in the above scenario, that's fine. But you shouldn't
 use an unfavorable (or useless) ruling by the EG as cover for not
 supporting this use case.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.14 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSNxPsAAoJEBzwKT+lPKRY99UP/Rt2D/c9NYATnRcvDEmE7Zu9
 ey1cyJ8vdcfqb3xKZKEG/N1EPwxRds8NmkuP/B4Z1uAtrV6g84DIyuBfKVg+/IZm
 fyzLZG55A8GPNfiuoe5ajT4TqmhI8ngg3oYfYy42RCd8sUPWI/T3CXNAA07khLS4
 E5o5bbZ+JAV4RptyLGJsdZDceijrxPKWl3KmKKTByn7hGTmcCHSlGbYmdPXJ5oMr
 QX3phw7Qb42u+smpPZ1XcE2pfYy8lhJE/LlbxgWWHIaK+fSod2O9cy1U0Ls1V4kG
 MIA0Vlglr5+FXPwJfW9BzNZ5pDsqAN80ip4Sk91MWiHcPscWdXRIvZS8Yjv3KVi6
 r88q1F/FONClI7CxLnE0GcTjP8ZHOqVZzCxJF9CHP1pRjhEtsUEYBNe5MqXkDwE+
 rDrlfwPnIAMUOdz6DeFX1es/p+k6adDaKIj+vzHtcWyeOekp1zjHFIyoO+ClmmiR
 mv/VI4RXIn9PuUzaUruGojiJ+gzk4UCupoJ4EamiNBKXko9P5PBXFmszBJY7LlZY
 GpWcudMTdyDE/E8ht1zWSnaSvIusbkQR+5WVTXONAOT+a2oGwqKJ8MCbb3opykG8
 Vu6CAKisz67Qb9LhM2Jj6Xa6dtfXBBjlxDfJbadWcORst2hX4Jx0kag0czHyROHz
 VyMgKgN3NwCuoRTgKcah
 =z09t
 -END PGP SIGNATURE-

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

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

On 16/09/2013 16:57, Mark Thomas wrote:
 The issue is with the lack of clarity from the EG with respect to
 ordering. I read section 8.2 one way but it is open to interpretation.

I've dug back through the Servlet 3.0 mailing list.

The text at the end of section 8.2 is aimed at the case where the same
SCI implementation exists in the container and the web app. It doesn't
appear that it was intended to affect ordering.

There are a number of grey areas that were raised at the same time that
have not been resolved. Ordering was one. How to handle the case where
an SCI is provided by the container and the web app but excluded from
the web app via ordering was another.

It certainly looks at this point as if the order is anything you like.
Personally, I'd prefer something rather more deterministic.

Mark


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

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/16/13 11:57 AM, Mark Thomas wrote:
 On 16/09/2013 15:21, Christopher Schultz wrote:
 Mark,
 
 On 9/16/13 5:09 AM, Mark Thomas wrote:
 The only requirement on ordering is at the end of section 8.2 
 which requires that application SCIs are discovered before 
 container SCIs. That is the opposite to what is being requested
  here.
 
 The issue needs to be raised with the EG. I'd suggest you
 create a JIRA.
 
 While raising the issue with the EG might be appropriate,
 there's no mandate from the EG that WebSocket services be
 initialized from an SCI. I see this as a Tomcat problem, not a
 spec problem.
 
 If you read the Servlet spec it is clear that SCIs are intended
 for adding capability such as WebSocket. The example used is JSP
 support which is clearly in the same category.
 
 I believe it's reasonable for webapp code to expect a sane 
 environment during initialization. In this case, an
 architectural decision at the container-implementation level (to
 use an SCI to get WebSocket going) has collided with a reasonable
 expectation of a webapp implementer. I don't believe the solution
 is to have the EG rule on this... the solution is to make Tomcat
 meet expectations.
 
 The issue is with the lack of clarity from the EG with respect to 
 ordering. I read section 8.2 one way but it is open to
 interpretation. Rather than change Tomcat once, then get
 clarification from the EG and then have to change it again, I'd
 rather get clarification first and then make any necessary changes.
 Clearly, there are going to have to be changes. I can think of
 several ways to tackle this issue. I'd rather design the solution
 with the EG mandated behaviour (even if that is 'we don't care') in
 mind.
 
 If that means changing from using an SCI to some other
 mechanism,
 
 That isn't going to happen.
 
 obviously the EG's opinion is moot. If you want to get the EG's 
 ruling and then work within that construct to get Tomcat's 
 WebSocket SCI working nicely in the above scenario, that's fine. 
 But you shouldn't use an unfavorable (or useless) ruling by the
 EG as cover for not supporting this use case.
 
 I am not looking for excuses not to support the use case. I am
 looking for those that care about this issue to do the work of
 getting clarification from the EG. This isn't an environment where
 someone just throws a problem over the wall and waits for someone
 else to fix it.

Sorry, I didn't mean to suggest that you were actually looking for a
reason to ignore the problem.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSNzB5AAoJEBzwKT+lPKRYAnMP/RzRhc0HJ80uE0rwMwfy4N+X
lgy5A5vFLCox5WloT1se80lqgMXEWgJPpMF/9qZv2mrmu5wTnEZQoZh2O8iwYt6Q
zOP2YKj8KmbAZhrse1Ui+DBNwbzdVV2Ek5xuSqahvSpoU31sLUhDsx893NAp/tYi
Q62O9V/7fso2d2z5TbzdrWqWsLwrm2HYp0nrCIZhkZjw46lZnza2SLNs++/CP4OF
4BJgdcojh6B7UN0v9nNaFr0xdQ+2wqIDv73XdCoq311yRaB1kH5FIXJDtTFuC1/9
fruWDDz1oIB7B8qJKMTPhWIa1fzAxx/dfLUkDMyT59nInkXtvNS7Xs3eb1kWM9Kn
IO1WPTY1jstFqYLndxpYAJzb/0Mo5ugPB//Ph62w4bX+6EN7VExw7fK5pANDLLuI
qjDg0j2/lLm4KXQi2eYUzKMxQiIc9RhHqa98xMp5NqToW3bwL2wRUa3Pd7TojSc+
+zgW4Ho8oxkSpL96OTJ5fAyyptZ7kxUr+gWsOszRjWGwCjP6iq2KYsAo4BVqm1SY
URFG3wArhX+u0IuN2dhmY7SjPiA98dQG3Rdv7T+yzfHVDqnlQZCPW9D4xTeHDrfC
hsNdPKymYiV+rCzWDFRY7DFuBmnE+c0wCpSh+AJQv9/OOYweeHY692qf43aSBOH7
5eutoqXpNWCUgbn3N4AX
=q9aQ
-END PGP SIGNATURE-

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

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

2013-09-16 Thread Nick Williams


On Sep 16, 2013, at 11:21 AM, Mark Thomas wrote:

 On 16/09/2013 16:57, Mark Thomas wrote:
 The issue is with the lack of clarity from the EG with respect to
 ordering. I read section 8.2 one way but it is open to interpretation.
 
 I've dug back through the Servlet 3.0 mailing list.
 
 The text at the end of section 8.2 is aimed at the case where the same
 SCI implementation exists in the container and the web app. It doesn't
 appear that it was intended to affect ordering.
 
 There are a number of grey areas that were raised at the same time that
 have not been resolved. Ordering was one. How to handle the case where
 an SCI is provided by the container and the web app but excluded from
 the web app via ordering was another.
 
 It certainly looks at this point as if the order is anything you like.
 Personally, I'd prefer something rather more deterministic.

Agreed. That's why I filed [1].

My understanding based on our previous conversations is that Tomcat *currently* 
orders SCIs according to the web-fragment ordering. Looking back on those 
conversations, what's not clear to me now is:

1) How does Tomcat *currently* order the groups of SCIs? Container before 
application or application before container? I *think* the answer is always 
application before container.
2) Does web-fragment ordering *currently* affect whether container SCIs come 
before application or vice versa? I *think* the answer is it does not.

IMO, SCI ordering should be the same as web-fragment ordering. With that said, 
that's the suggestion I made in [1]. Unfortunately, there have been no comments 
from the EG yet. I know it will be a while before they start working on Servlet 
3.2, but my hope was to get the EG involved on this particular issue early, so 
that some guidance can be given to 3.0 and 3.1 containers for how they might 
tweak their existing behavior (if possible, if the API doesn't change any) to 
provide consistent behavior across containers (JBoss also uses web-fragment 
ordering, and WebLogic and WebSphere appear to as well, but Jetty, GlassFish, 
and Resin use the order as returned from the ClassLoader). Consistency in 
Servlet 3.0 and 3.1 containers would be a high win, IMO.

I'm trying to join the JCP as an individual process so that I can, hopefully, 
be a little more influential in this process. Unfortunately the process is 
onerous and it appears that I will not be allowed to join. (As an individual, 
my employer, who has absolutely no control or say over what I do in my spare 
time, is required to sign Exhibit B saying they won't claim ownership of my 
contributions, but my employer won't sign it because it's unnecessary and 
serves no business purpose to us to enter into a legally binding agreement for 
you to do something that we don't care about on your own time.) It would be 
great if any existing JCP members could bring [1] to their attention and maybe 
get some people together for a discussion.

N

[1] https://java.net/jira/browse/SERVLET_SPEC-79

smime.p7s
Description: S/MIME cryptographic signature

Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.

On Mon, Sep 16, 2013 at 6:57 PM, Mark Thomas ma...@apache.org wrote:

 On 16/09/2013 15:21, Christopher Schultz wrote:
  Mark,
 
  On 9/16/13 5:09 AM, Mark Thomas wrote:
  The only requirement on ordering is at the end of section 8.2
  which requires that application SCIs are discovered before
  container SCIs. That is the opposite to what is being requested
  here.
 
  The issue needs to be raised with the EG. I'd suggest you create
  a JIRA.
 
  While raising the issue with the EG might be appropriate, there's
  no mandate from the EG that WebSocket services be initialized from
  an SCI. I see this as a Tomcat problem, not a spec problem.

 If you read the Servlet spec it is clear that SCIs are intended for
 adding capability such as WebSocket. The example used is JSP support
 which is clearly in the same category.

  I believe it's reasonable for webapp code to expect a sane
  environment during initialization. In this case, an architectural
  decision at the container-implementation level (to use an SCI to
  get WebSocket going) has collided with a reasonable expectation of
  a webapp implementer. I don't believe the solution is to have the
  EG rule on this... the solution is to make Tomcat meet
  expectations.

 The issue is with the lack of clarity from the EG with respect to
 ordering. I read section 8.2 one way but it is open to interpretation.
 Rather than change Tomcat once, then get clarification from the EG and
 then have to change it again, I'd rather get clarification first and
 then make any necessary changes. Clearly, there are going to have to
 be changes. I can think of several ways to tackle this issue. I'd
 rather design the solution with the EG mandated behaviour (even if
 that is 'we don't care') in mind.

  If that means changing from using an SCI to some other mechanism,

 That isn't going to happen.

  obviously the EG's opinion is moot. If you want to get the EG's
  ruling and then work within that construct to get Tomcat's
  WebSocket SCI working nicely in the above scenario, that's fine.
  But you shouldn't use an unfavorable (or useless) ruling by the EG
  as cover for not supporting this use case.

 I am not looking for excuses not to support the use case. I am looking
 for those that care about this issue to do the work of getting
 clarification from the EG. This isn't an environment where someone
 just throws a problem over the wall and waits for someone else to fix it.


It's prefereable to have the EG clear the issue and then implement
accordingly. However the Java EE 7 was just published and I don't expect
any changes soon. I think SCI ordering is a topic leading to a release of
the spec. This case is not just a clarification. It is related to spec text
updates and probably changes in the compatability test set as well. I don't
know whether there are ongoing internal EG discussions but there are no
public comments on the JIRA issue. It is the same with WebSocket EG - there
are number of issues without any comments. JavaOne 2013 is around corner
and if someone is visiting perhaps face to face with someone from EG could
be arranged.



 Mark

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

Re: use password expiration with datasource realm