Re: ApacheCon North America, Denver, April 7-11

[Nick Williams]

On Mar 10, 2014, at 11:17 AM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 3/10/14, 11:43 AM, Nick Williams wrote:
>> 
>> On Mar 10, 2014, at 10:40 AM, Jeffrey Janner wrote:
>> 
>>>> -Original Message- From: Rich Bowen
>>>> [mailto:rbo...@rcbowen.com] Sent: Tuesday, March 04, 2014 2:59
>>>> PM To: d...@tomcat.apache.org; users@tomcat.apache.org Subject:
>>>> ApacheCon North America, Denver, April 7-11
>>>> 
>>>> Hello Tomcat enthusiasts,
>>>> 
>>>> as you are no doubt aware, ApacheCon North America will be held
>>>> in Denver, Colorado starting on April 7th. Tomcat will be
>>>> represented there by a full day of content in the following
>>>> talks: 
>>>> http://apacheconnorthamerica2014.sched.org/overview/type/tomcat
>>>> 
>>>> 
>>>> 
> We would love to see you in Denver next month. Register soon, as prices
>>>> go up on March 14th. http://na.apachecon.com/
>>>> 
>>>> -- Rich Bowen - rbo...@rcbowen.com - @rbowen
>>>> http://apachecon.com/ - @apachecon
>>> 
>>> Is it really April 7-11 or 7-9 as stated on the website
>>> homepage?
>> 
>> Both are correct. The "main events" (official speaking schedule)
>> encompasses April 7 - 9. April 10 and 11 are summits, unconferences
>> (Apache BarCamp), and tutorials.
> 
> Specifically, there is an Apache Tomcat summit on Friday the 11th. We
> hope to see as many of you there as can make it.
> 
> Did anyone mention that there is a ton of free beer at ApacheCons?

I will be there because I 'm speaking there.

I am /definitely/ excited about all the free beer. :-)

N

smime.p7s
Description: S/MIME cryptographic signature

Re: ApacheCon North America, Denver, April 7-11

[Nick Williams]

On Mar 10, 2014, at 10:40 AM, Jeffrey Janner wrote:

>> -Original Message-
>> From: Rich Bowen [mailto:rbo...@rcbowen.com]
>> Sent: Tuesday, March 04, 2014 2:59 PM
>> To: d...@tomcat.apache.org; users@tomcat.apache.org
>> Subject: ApacheCon North America, Denver, April 7-11
>> 
>> Hello Tomcat enthusiasts,
>> 
>> as you are no doubt aware, ApacheCon North America will be held in
>> Denver, Colorado starting on April 7th. Tomcat will be represented
>> there by a full day of content in the following talks:
>> http://apacheconnorthamerica2014.sched.org/overview/type/tomcat
>> 
>> We would love to see you in Denver next month. Register soon, as prices
>> go up on March 14th. http://na.apachecon.com/
>> 
>> --
>> Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ -
>> @apachecon
> 
> Is it really April 7-11 or 7-9 as stated on the website homepage?

Both are correct. The "main events" (official speaking schedule) encompasses 
April 7 - 9. April 10 and 11 are summits, unconferences (Apache BarCamp), and 
tutorials.

Nick

smime.p7s
Description: S/MIME cryptographic signature

Re: Apache Tomcat Summit at ApacheCon NA 2014

[Nick Williams]

I didn't know for sure whether I was coming until now, so I couldn't reply 
earlier. I'll be at ApacheCon (speaking on Log4j) and I will DEFINITELY attend 
a Tomcat summit!

I look forward to meeting you, Mark!

Nick

On Jan 28, 2014, at 6:47 PM, Mark Thomas wrote:

> On 23/01/2014 13:29, Mark Thomas wrote:
>> ApacheCon NA will be in Denver 7th to 11th April.
>> 
>> The schedule for ApacheCon NA 2014 has been firmed up. There is an
>> opportunity for a project summit on either the Thursday or the Friday.
>> Since the BarCamp has been scheduled for the Thursday the Friday seems
>> like the better option.
>> 
>> We have complete flexibility as to the organisation of the Summit. One
>> possible topic is with the Java EE 7 work pretty much complete, what new
>> features is the community interested in between now and when the Java EE
>> 8 work starts? Other suggestions for topics welcome.
>> 
>> To get this up and running we need an idea of how many folks might want
>> to attend so please reply to this thread on the users list if:
>> - you are interested in attending
>> - you have a topic / some topics to suggest
> 
> I've put in a formal request for this. I'll update the list as and when
> I get a reply.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: [OT] Out of memory exception - top posting

[Nick Williams]

On Jan 24, 2014, at 12:05 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Mark,
> 
> On 1/24/14, 10:18 AM, Mark H. Wood wrote:
>> On Thu, Jan 23, 2014 at 09:24:41PM -0500, Howard W. Smith, Jr.
>> wrote:
>>> On Thu, Jan 23, 2014 at 2:08 PM, André Warnier 
>>> wrote:
 Either people don't read the rules, or they do not understand
 the rule, or they just ignore it.
>>> 
>>> I agree. As a tomcat/tomee user, I joined the list, primarily, to
>>> listen in on topics (that interest me), so I learned, very
>>> quickly, that top-posting is not preferred, here.
>> 
>> 

My biggest problem is that the Apache projects aren't all consistent. I'm a 
contributor to several (including a committer for Logging). Some use only 
top-posting and discourage bottom-posting. Others (Tomcat) use only 
bottom-posting and discourage top-posting. It's very frustrating and makes 
switching between project lists error-prone.

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

Re: IllegalStateException sending WebSocket message that worked a few months ago

[Nick Williams]

On Nov 26, 2013, at 5:32 AM, Mark Thomas wrote:

> On 26/11/2013 04:56, Konstantin Kolinko wrote:
>> 2013/11/26 Nick Williams :
>>> 
>>> On Nov 25, 2013, at 9:11 PM, Konstantin Kolinko wrote:
>>> 
> 
>>>> There was this change:
>>>> http://svn.apache.org/viewvc?view=revision&revision=1544213
>>>> 
>>>> 
>>>>   55799: Correctly enforce the restriction in JSR356 that no
>>>>   more than one data message may be sent to a remote WebSocket 
>>>> endpoint at
>>>>   a time. (markt)
>>>> 
>>> 
>>> Problem is, I'm only sending one data message. That's it. The very first 
>>> and only data message I send triggers the first error. The second error is 
>>> before I even get to sending a data message; it's when I retrieve a stream. 
>>> Something's definitely broken. Even IF I were sending multiple messages 
>>> (again, I'm not); they should be queued, not result in an error that leaves 
>>> the Session in an inconsistent state indefinitely.
>> 
>> 
>> I reopened the bug,
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55799#c15
> 
> Fixed.
> 
> Mark

Your changes only partially fixed it. I'm still having problems with latest 
trunk. I have reopened the bug and attached a sample project to it that 
replicates the regression.

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

Re: IllegalStateException sending WebSocket message that worked a few months ago

[Nick Williams]

On Nov 25, 2013, at 9:11 PM, Konstantin Kolinko wrote:

> 2013/11/25 Nick Williams :
>> I've written a simple Servlet/WebSocket client that sends a message over the 
>> Session each time a GET request comes in. This worked a few months ago:
>> 
>>@Override
>>protected void doGet(HttpServletRequest request, HttpServletResponse 
>> response)
>>throws ServletException, IOException
>>{
>>ClusterMessage message = new ClusterMessage(this.nodeId,
>>"request:{ip:\"" + request.getRemoteAddr() +
>>"\",queryString:\"" + request.getQueryString() + "\"}");
>> 
>>try(OutputStream output = 
>> this.session.getBasicRemote().getSendStream();
>>ObjectOutputStream stream = new ObjectOutputStream(output))
>>{
>>stream.writeObject(message);
>>}
>>response.getWriter().append("OK");
>>}
>> 
>> But on the latest trunk, I get this error on the first request to doGet:
>> 
>> java.lang.IllegalStateException: The remote endpoint was in state 
>> [STREAM_WRITING] which is an invalid state for called method
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1014)
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.binaryPartialStart(WsRemoteEndpointImplBase.java:961)
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialBytes(WsRemoteEndpointImplBase.java:140)
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$WsOutputStream.doWrite(WsRemoteEndpointImplBase.java:838)
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$WsOutputStream.flush(WsRemoteEndpointImplBase.java:821)
>>
>> java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1823)
>>java.io.ObjectOutputStream.flush(ObjectOutputStream.java:719)
>>java.io.ObjectOutputStream.close(ObjectOutputStream.java:740)
>>com.wrox.ClusterNodeServlet.doGet(ClusterNodeServlet.java:72)
>>javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
>>javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
>>org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
>> 
>> On all subsequent requests, I get this error:
>> 
>> java.lang.IllegalStateException: The remote endpoint was in state 
>> [STREAM_WRITING] which is an invalid state for called method
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1014)
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.streamStart(WsRemoteEndpointImplBase.java:951)
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.getSendStream(WsRemoteEndpointImplBase.java:190)
>>
>> org.apache.tomcat.websocket.WsRemoteEndpointBasic.getSendStream(WsRemoteEndpointBasic.java:62)
>>com.wrox.ClusterNodeServlet.doGet(ClusterNodeServlet.java:68)
>>javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
>>javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
>>org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
>> 
>> I'm guessing I need to file a BZ, but I wanted to make sure. I don't see how 
>> I could possibly be doing anything wrong in this simple code.
>> 
> 
> 
> There was this change:
> http://svn.apache.org/viewvc?view=revision&revision=1544213
> 
>  
>55799: Correctly enforce the restriction in JSR356 that no
>more than one data message may be sent to a remote WebSocket endpoint 
> at
>a time. (markt)
>  

Problem is, I'm only sending one data message. That's it. The very first and 
only data message I send triggers the first error. The second error is before I 
even get to sending a data message; it's when I retrieve a stream. Something's 
definitely broken. Even IF I were sending multiple messages (again, I'm not); 
they should be queued, not result in an error that leaves the Session in an 
inconsistent state indefinitely.

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

IllegalStateException sending WebSocket message that worked a few months ago

[Nick Williams]

I've written a simple Servlet/WebSocket client that sends a message over the 
Session each time a GET request comes in. This worked a few months ago:

@Override
protected void doGet(HttpServletRequest request, HttpServletResponse 
response)
throws ServletException, IOException
{
ClusterMessage message = new ClusterMessage(this.nodeId,
"request:{ip:\"" + request.getRemoteAddr() +
"\",queryString:\"" + request.getQueryString() + "\"}");

try(OutputStream output = this.session.getBasicRemote().getSendStream();
ObjectOutputStream stream = new ObjectOutputStream(output))
{
stream.writeObject(message);
}
response.getWriter().append("OK");
}

But on the latest trunk, I get this error on the first request to doGet:

java.lang.IllegalStateException: The remote endpoint was in state 
[STREAM_WRITING] which is an invalid state for called method

org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1014)

org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.binaryPartialStart(WsRemoteEndpointImplBase.java:961)

org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialBytes(WsRemoteEndpointImplBase.java:140)

org.apache.tomcat.websocket.WsRemoteEndpointImplBase$WsOutputStream.doWrite(WsRemoteEndpointImplBase.java:838)

org.apache.tomcat.websocket.WsRemoteEndpointImplBase$WsOutputStream.flush(WsRemoteEndpointImplBase.java:821)

java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1823)
java.io.ObjectOutputStream.flush(ObjectOutputStream.java:719)
java.io.ObjectOutputStream.close(ObjectOutputStream.java:740)
com.wrox.ClusterNodeServlet.doGet(ClusterNodeServlet.java:72)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)

On all subsequent requests, I get this error:

java.lang.IllegalStateException: The remote endpoint was in state 
[STREAM_WRITING] which is an invalid state for called method

org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.checkState(WsRemoteEndpointImplBase.java:1014)

org.apache.tomcat.websocket.WsRemoteEndpointImplBase$StateMachine.streamStart(WsRemoteEndpointImplBase.java:951)

org.apache.tomcat.websocket.WsRemoteEndpointImplBase.getSendStream(WsRemoteEndpointImplBase.java:190)

org.apache.tomcat.websocket.WsRemoteEndpointBasic.getSendStream(WsRemoteEndpointBasic.java:62)
com.wrox.ClusterNodeServlet.doGet(ClusterNodeServlet.java:68)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)

I'm guessing I need to file a BZ, but I wanted to make sure. I don't see how I 
could possibly be doing anything wrong in this simple code.

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

Re: EL 3.0 Streams Edge Case - Am I wrong or is Tomcat wrong?

[Nick Williams]

On Nov 18, 2013, at 12:21 PM, Konstantin Kolinko wrote:

> 2013/11/18 Nick Williams :
>> 
> 
>>> 
>>> Regarding the list() example,
>>> "map(u -> [u.username, u.firstName, u.lastName])"  creates a
>>> List  with 3 elements and you are asking for "lastName"
>>> property on that list.
>> 
>> No, this is not correct. The lambda expression "u -> [u.username, 
>> u.firstName, u.lastName]" RETURNS a List. But "u" is a User. I am 
>> creating a List where the first element is the user's username, the 
>> second element is the user's first name, and the third element is the user's 
>> last name. That is completely valid. It is also essentially identical to 
>> Section 2.3.6.4's example "p->[p.name, p.unitPrice]."
>> 
>>> 
>>> It is no wonder that it results in NumberFormatException. (Whether
>>> there should be other handling for wrong property name here, I do not
>>> know. One should look into what resolvers are being used here).
>> 
>> It should not result in any exception. It should work, because the syntax is 
>> valid, as explained above. :-)
>> 
> 
> You apply map() which replaces each user with a list [u.username,
> u.firstName, u.lastName].
> 
> Then you try to apply sorted() to that list. That sorted() fails as it
> cannot evaluate "u1.lastName.compareTo(u2.lastName)".
> 
> As I said - provide a simple example.

Okay, I see where the confusion is. Indeed, when I moved "map" to after 
"sorted" the list-literal started working. So it's only the map-literal that is 
failing. My apologies; I'll revise the bug.

> 
>>> 
>>>>>> Section 2.3.6.4 of the specification uses the following example, where a 
>>>>>> LIST literal is used as the right-hand side of the mapping lambda 
>>>>>> expression:
>>>>>> 
>>>>>> products.stream().filter(p->p.unitPrice >= 10).
>>>>>>  .map(p->[p.name, p.unitPrice])
>>>>>>  .toList()
>>>>>> 
>>>>>> I tried to use this exact syntax, as shown in the spec, with my example:
>>>>>> 
>>>>>>  ${users.stream()
>>>>>> .filter(u -> fn:contains(u.username, '1'))
>>>>>> .map(u -> [u.username, u.firstName, u.lastName])
>>>>>> .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 
>>>>>> ? u1.firstName.compareTo(u2.firstName) : 
>>>>>> u1.lastName.compareTo(u2.lastName))
>>>>>> .toList()}
>>>>>> 
>>>>>> And now I get this lovely error:
>>>>>> 
>>>>>> javax.el.ELException: java.lang.NumberFormatException: For input string: 
>>>>>> "lastName"
>>>>>>  javax.el.BeanELResolver.invoke(BeanELResolver.java:185)
>>>>>>  
>>>>>> org.apache.jasper.el.JasperELResolver.invoke(JasperELResolver.java:147)
>>>>>>  org.apache.el.parser.AstValue.getValue(AstValue.java:158)
>>>>>>  ...
>>>>>> 
>>> 
>>> Best regards,
>>> Konstantin Kolinko
>> 
>> Thanks,
>> 
>> Nick

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

Re: EL 3.0 Streams Edge Case - Am I wrong or is Tomcat wrong?

[Nick Williams]

On Nov 18, 2013, at 12:05 PM, Konstantin Kolinko wrote:

> 2013/11/17 Nick Williams :
>> 
>> On Nov 17, 2013, at 6:00 AM, Konstantin Kolinko wrote:
>> 
>>> 2013/11/17 Nick Williams :
>>>> I have an EL 3.0 edge case that I need help understanding. Am I doing 
>>>> something wrong (I don't think so) or is the Tomcat 8.0 implementation 
>>>> missing something?
>>>> 
>>>> Consider the following EL expression:
>>>> 
>>>>   ${users.stream()
>>>>  .filter(u -> fn:contains(u.username, '1'))
>>>>  .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
>>>> u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
>>>>  .toList()}
>>>> 
>>>> This works as expected. However, it results in potentially evaluating 
>>>> u1.lastName.compareTo(u2.lastName) twice. My understanding is that the 
>>>> right-hand side of a lambda expression can be any valid EL expression, so 
>>>> I believe this should also work:
>>>> 
>>>>   ${users.stream()
>>>>  .filter(u -> fn:contains(u.username, '1'))
>>>>  .sorted((u1, u2) -> x = u1.lastName.compareTo(u2.lastName); x 
>>>> == 0 ? u1.firstName.compareTo(u2.firstName) : x)
>>>>  .toList()}
>>>> 
>>>> However, this doesn't evaluate. I get the following error instead:
>>>> 
>>>> org.apache.el.parser.ParseException: Encountered " "=" "= "" at line 3, 
>>>> column 38.
>>>> Was expecting one of:
>>>>   "." ...
>>>>   ")" ...
>>>>   etc ...
>>>> 
>>> 
>>> What if you add "(" ")" ?
>>> What operator has higher priority, "->" or ";" ?
>> 
>> "->" has higher priority than both "=" and ";", according to the spec. In 
>> this particular case, I'm not sure whether that means parenthesis are 
>> absolutely required or not. However, I can confirm that adding parenthesis 
>> here solves this problem, so perhaps that's what I was doing wrong for this 
>> error. This expression now works:
>> 
>>${users.stream()
>>   .filter(u -> fn:contains(u.username, '1'))
>>   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName); x 
>> == 0 ? u1.firstName.compareTo(u2.firstName) : x))
>>   .toList()}
>> 
> 
> Tomcat is performing correctly here.
> 
> (For a reference: the priorities are specified by Ch.1.16 of EL 3.0).
> 
>>>> Next I tried to reduce the properties present in each user using the 
>>>> stream "map" method. Once again, with the understanding that the 
>>>> right-hand side of a lambda expression can be any valid EL expression, I 
>>>> use an EL Map literal to construct a reduced set of properties:
>>>> 
>>>>   ${users.stream()
>>>>  .filter(u -> fn:contains(u.username, '1'))
>>>>  .map(u -> {'username':u.username, 'first':u.firstName, 
>>>> 'last':u.lastName})
>>>>  .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
>>>> u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
>>>>  .toList()}
>>>> 
>>>> However, that doesn't work and I get this error:
>>>> 
>>>> org.apache.el.parser.ParseException: Encountered "" at line 3, column 
>>>> 88.
>>>> Was expecting one of:
>>>>   "." ...
>>>>   ")" ...
>>>>   etc ...
>>>> 
>>> 
>>> I do not understand the above.  Can you provide a simple test case?
>>> Which one of the expressions does not work? Can you remove the others?
>> 
>> So, as mentioned above, the following expression works:
>> 
>>${users.stream()
>>   .filter(u -> fn:contains(u.username, '1'))
>>   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName); x 
>> == 0 ? u1.firstName.compareTo(u2.firstName) : x))
>>   .toList()}
>> 
>> If I now add the "map" operation to it, I get the EOF error. Nothing else 
>> about the expression changed:

Re: EL 3.0 Streams Edge Case - Am I wrong or is Tomcat wrong?

[Nick Williams]

Being convinced now that this is a Tomcat bug in violation of the spec--and not 
something I am doing wrong--I'm going to go ahead and file a bug now.

N

On Nov 17, 2013, at 9:32 AM, Nick Williams wrote:

> 
> On Nov 17, 2013, at 6:00 AM, Konstantin Kolinko wrote:
> 
>> 2013/11/17 Nick Williams :
>>> I have an EL 3.0 edge case that I need help understanding. Am I doing 
>>> something wrong (I don't think so) or is the Tomcat 8.0 implementation 
>>> missing something?
>>> 
>>> Consider the following EL expression:
>>> 
>>>   ${users.stream()
>>>  .filter(u -> fn:contains(u.username, '1'))
>>>  .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
>>> u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
>>>  .toList()}
>>> 
>>> This works as expected. However, it results in potentially evaluating 
>>> u1.lastName.compareTo(u2.lastName) twice. My understanding is that the 
>>> right-hand side of a lambda expression can be any valid EL expression, so I 
>>> believe this should also work:
>>> 
>>>   ${users.stream()
>>>  .filter(u -> fn:contains(u.username, '1'))
>>>  .sorted((u1, u2) -> x = u1.lastName.compareTo(u2.lastName); x 
>>> == 0 ? u1.firstName.compareTo(u2.firstName) : x)
>>>  .toList()}
>>> 
>>> However, this doesn't evaluate. I get the following error instead:
>>> 
>>> org.apache.el.parser.ParseException: Encountered " "=" "= "" at line 3, 
>>> column 38.
>>> Was expecting one of:
>>>   "." ...
>>>   ")" ...
>>>   etc ...
>>> 
>> 
>> What if you add "(" ")" ?
>> What operator has higher priority, "->" or ";" ?
> 
> "->" has higher priority than both "=" and ";", according to the spec. In 
> this particular case, I'm not sure whether that means parenthesis are 
> absolutely required or not. However, I can confirm that adding parenthesis 
> here solves this problem, so perhaps that's what I was doing wrong for this 
> error. This expression now works:
> 
>${users.stream()
>   .filter(u -> fn:contains(u.username, '1'))
>   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName); x 
> == 0 ? u1.firstName.compareTo(u2.firstName) : x))
>   .toList()}
> 
>>> Next I tried to reduce the properties present in each user using the stream 
>>> "map" method. Once again, with the understanding that the right-hand side 
>>> of a lambda expression can be any valid EL expression, I use an EL Map 
>>> literal to construct a reduced set of properties:
>>> 
>>>   ${users.stream()
>>>  .filter(u -> fn:contains(u.username, '1'))
>>>  .map(u -> {'username':u.username, 'first':u.firstName, 
>>> 'last':u.lastName})
>>>  .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
>>> u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
>>>  .toList()}
>>> 
>>> However, that doesn't work and I get this error:
>>> 
>>> org.apache.el.parser.ParseException: Encountered "" at line 3, column 
>>> 88.
>>> Was expecting one of:
>>>   "." ...
>>>   ")" ...
>>>   etc ...
>>> 
>> 
>> I do not understand the above.  Can you provide a simple test case?
>> Which one of the expressions does not work? Can you remove the others?
> 
> So, as mentioned above, the following expression works:
> 
>${users.stream()
>   .filter(u -> fn:contains(u.username, '1'))
>   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName); x 
> == 0 ? u1.firstName.compareTo(u2.firstName) : x))
>   .toList()}
> 
> If I now add the "map" operation to it, I get the EOF error. Nothing else 
> about the expression changed:
> 
>${users.stream()
>   .filter(u -> fn:contains(u.username, '1'))
>   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName);
>x == 0 ? u1.firstName.compareTo(u2.firstName) : x))
>   .map(u -> {'username':u.username, 'first':u.firstNam

Re: EL 3.0 Streams Edge Case - Am I wrong or is Tomcat wrong?

[Nick Williams]

On Nov 17, 2013, at 6:00 AM, Konstantin Kolinko wrote:

> 2013/11/17 Nick Williams :
>> I have an EL 3.0 edge case that I need help understanding. Am I doing 
>> something wrong (I don't think so) or is the Tomcat 8.0 implementation 
>> missing something?
>> 
>> Consider the following EL expression:
>> 
>>${users.stream()
>>   .filter(u -> fn:contains(u.username, '1'))
>>   .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
>> u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
>>   .toList()}
>> 
>> This works as expected. However, it results in potentially evaluating 
>> u1.lastName.compareTo(u2.lastName) twice. My understanding is that the 
>> right-hand side of a lambda expression can be any valid EL expression, so I 
>> believe this should also work:
>> 
>>${users.stream()
>>   .filter(u -> fn:contains(u.username, '1'))
>>   .sorted((u1, u2) -> x = u1.lastName.compareTo(u2.lastName); x 
>> == 0 ? u1.firstName.compareTo(u2.firstName) : x)
>>   .toList()}
>> 
>> However, this doesn't evaluate. I get the following error instead:
>> 
>> org.apache.el.parser.ParseException: Encountered " "=" "= "" at line 3, 
>> column 38.
>> Was expecting one of:
>>"." ...
>>")" ...
>>etc ...
>> 
> 
> What if you add "(" ")" ?
> What operator has higher priority, "->" or ";" ?

"->" has higher priority than both "=" and ";", according to the spec. In this 
particular case, I'm not sure whether that means parenthesis are absolutely 
required or not. However, I can confirm that adding parenthesis here solves 
this problem, so perhaps that's what I was doing wrong for this error. This 
expression now works:

${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName); x 
== 0 ? u1.firstName.compareTo(u2.firstName) : x))
   .toList()}

>> Next I tried to reduce the properties present in each user using the stream 
>> "map" method. Once again, with the understanding that the right-hand side of 
>> a lambda expression can be any valid EL expression, I use an EL Map literal 
>> to construct a reduced set of properties:
>> 
>>${users.stream()
>>   .filter(u -> fn:contains(u.username, '1'))
>>   .map(u -> {'username':u.username, 'first':u.firstName, 
>> 'last':u.lastName})
>>   .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
>> u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
>>   .toList()}
>> 
>> However, that doesn't work and I get this error:
>> 
>> org.apache.el.parser.ParseException: Encountered "" at line 3, column 
>> 88.
>> Was expecting one of:
>>"." ...
>>")" ...
>>etc ...
>> 
> 
> I do not understand the above.  Can you provide a simple test case?
> Which one of the expressions does not work? Can you remove the others?

So, as mentioned above, the following expression works:

${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName); x 
== 0 ? u1.firstName.compareTo(u2.firstName) : x))
   .toList()}

If I now add the "map" operation to it, I get the EOF error. Nothing else about 
the expression changed:

${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName);
x == 0 ? u1.firstName.compareTo(u2.firstName) : x))
   .map(u -> {'username':u.username, 'first':u.firstName, 
'last':u.lastName})
   .toList()}

javax.el.ELException: Failed to parse the expression [${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .sorted((u1, u2) -> (x = u1.lastName.compareTo(u2.lastName);
x == 0 ? u1.firstName.compareTo(u2.firstName) : x))
   .map(u -> {'username':u.username, 'first':u.firstName,
'last':u.lastName}]
...

org.apache.el.parser.ParseException: Encountered "" at line 6, column 38.

EL 3.0 Streams Edge Case - Am I wrong or is Tomcat wrong?

[Nick Williams]

I have an EL 3.0 edge case that I need help understanding. Am I doing something 
wrong (I don't think so) or is the Tomcat 8.0 implementation missing something?

Consider the following EL expression:

${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
   .toList()}

This works as expected. However, it results in potentially evaluating 
u1.lastName.compareTo(u2.lastName) twice. My understanding is that the 
right-hand side of a lambda expression can be any valid EL expression, so I 
believe this should also work:

${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .sorted((u1, u2) -> x = u1.lastName.compareTo(u2.lastName); x == 
0 ? u1.firstName.compareTo(u2.firstName) : x)
   .toList()}

However, this doesn't evaluate. I get the following error instead:

org.apache.el.parser.ParseException: Encountered " "=" "= "" at line 3, column 
38.
Was expecting one of:
"." ...
")" ...
etc ...

Next I tried to reduce the properties present in each user using the stream 
"map" method. Once again, with the understanding that the right-hand side of a 
lambda expression can be any valid EL expression, I use an EL Map literal to 
construct a reduced set of properties:

${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .map(u -> {'username':u.username, 'first':u.firstName, 
'last':u.lastName})
   .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
   .toList()}

However, that doesn't work and I get this error:

org.apache.el.parser.ParseException: Encountered "" at line 3, column 88.
Was expecting one of:
"." ...
")" ...
etc ...

Section 2.3.6.4 of the specification uses the following example, where a LIST 
literal is used as the right-hand side of the mapping lambda expression:

products.stream().filter(p->p.unitPrice >= 10).
.map(p->[p.name, p.unitPrice])
.toList()

I tried to use this exact syntax, as shown in the spec, with my example:

${users.stream()
   .filter(u -> fn:contains(u.username, '1'))
   .map(u -> [u.username, u.firstName, u.lastName])
   .sorted((u1, u2) -> u1.lastName.compareTo(u2.lastName) == 0 ? 
u1.firstName.compareTo(u2.firstName) : u1.lastName.compareTo(u2.lastName))
   .toList()}

And now I get this lovely error:

javax.el.ELException: java.lang.NumberFormatException: For input string: 
"lastName"
javax.el.BeanELResolver.invoke(BeanELResolver.java:185)
org.apache.jasper.el.JasperELResolver.invoke(JasperELResolver.java:147)
org.apache.el.parser.AstValue.getValue(AstValue.java:158)
...

I'm sure I'm doing something wrong here, but I'm not exactly sure what. On the 
other hand, it's possible that the Tomcat 8.0 implementation is just wrong. Can 
someone shed some light on this?

Thanks,

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

Re: @ServerEndpoint Guice

[Nick Williams]

On Nov 6, 2013, at 4:24 PM, Marko Sanković wrote:

> Nick, thanks for your quick response.
> 
> Unfortunately, specifying javax.websocket.server.ServerEndpointConfig.
> Configurator is still not enough. This is what I have tried so far:
> 
> @ServerEndpoint(value = "/wsendpoint", configurator =
> WsEndpointConfigurator.class)
> public class WsEndpoint {
>@Inject
>InjectedSimpleBean injectedSimpleBean;
>...
> }
> 
> and the WsEndpointConfigurator.java:
> 
> public class WsEndpointConfigurator extends Configurator {
> 
>@Inject
>Injector injector;
> 
>@Override
>public  T getEndpointInstance(Class endpointClass)
>throws InstantiationException {
>return (T) injector.getInstance(endpointClass);
>}
> }
> 
> As expected attribute injector is null. To my understanding configurator
> has to be instantiated through guice, same for the class that instantiates
> configurator (ServerEndpointConfig). How can I do that?
> 
> Tyrus has the sample of what I really need:
> https://tyrus.java.net/documentation/1.3/user-guide.html#d0e1075. In my
> case, I have to achieve that with Google Guice and Tomcat 7.0.47.
> 
> Thanks

Marko,

Guice is not going to be able to instantiate your WsEndpointConfigurator, so 
you cannot have your Injector injected. The same problem exists with Spring's 
SpringConfigurator. The container, not the framework, instantiates it. The 
solution is to call some static method to "look up" the injector. For 
SpringConfigurator, that means calling 
ContextLoader.getCurrentWebApplicationContext() and using the returned 
ApplicationContext to instantiate the endpoint. I do not know what the 
equivalent is in Guice because I have never used Guice before. However, I'm 
sure Guice has something similar. It wouldn't be very flexible if it didn't.

Nick

> 
> On 6 November 2013 16:23, Nick Williams wrote:
> 
>> 
>> On Nov 6, 2013, at 7:55 AM, Marko Sanković wrote:
>> 
>>> Hi,
>>> 
>>> For the last couple of hours I've been trying to inject a simple object
>>> into the class that is @ServerEndpoint annotated.
>>> 
>>> As stated: Tomcat implements the Java WebSocket 1.0 API defined by
>> JSR-356.
>>> 
>>> I'm using Guice as dependency injection framework and Tomcat 7.0.47.
>>> 
>>> This is how my websocket server endpoint looks like:
>>> 
>>> ...
>>> import com.google.inject.Inject;
>>> ...
>>> @ServerEndpoint("/wsendpoint")
>>> public class WsEndpoint {
>>> 
>>>   @Inject
>>>   InjectedSimpleBean injectedSimpleBean;
>>> 
>>>   ...
>>> }
>>> 
>>> I can connect to this endpoint, send and receive messages, but
>>> injectedSimpleBean attribute is null (as expected).
>>> 
>>> I guess I will have to change the
>>> way
>> java/org/apache/tomcat/websocket/server/DefaultServerEndpointConfigurator.java
>>> instantiates endpoint class, the getEndpointInstace method will have to
>>> call something like:
>>> 
>>> injector.getInstance(clazz);
>>> 
>>> but, then again the DefaultServerEndpointConfiguration will also have be
>>> instantiated by the injector.
>>> 
>>> Any help would be appreciated. Thanks
>> 
>> Changing the Tomcat-specific class won't be necessary. You can do this
>> with just the API. In your @ServerEndpoint annotation, you need to specify
>> a different configuration that extends
>> javax.websocket.server.ServerEndpointConfig.Configurator. Spring Framework
>> has a class [1] that does just this for its DI and other bean processing.
>> You can probably create a class modeled after that.
>> 
>> Nick
>> 
>> [1]
>> https://github.com/spring-projects/spring-framework/blob/master/spring-websocket/src/main/java/org/springframework/web/socket/server/endpoint/SpringConfigurator.java?source=cc
>> -
>> 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: @ServerEndpoint Guice

[Nick Williams]

On Nov 6, 2013, at 7:55 AM, Marko Sanković wrote:

> Hi,
> 
> For the last couple of hours I've been trying to inject a simple object
> into the class that is @ServerEndpoint annotated.
> 
> As stated: Tomcat implements the Java WebSocket 1.0 API defined by JSR-356.
> 
> I'm using Guice as dependency injection framework and Tomcat 7.0.47.
> 
> This is how my websocket server endpoint looks like:
> 
> ...
> import com.google.inject.Inject;
> ...
> @ServerEndpoint("/wsendpoint")
> public class WsEndpoint {
> 
>@Inject
>InjectedSimpleBean injectedSimpleBean;
> 
>...
> }
> 
> I can connect to this endpoint, send and receive messages, but
> injectedSimpleBean attribute is null (as expected).
> 
> I guess I will have to change the
> way 
> java/org/apache/tomcat/websocket/server/DefaultServerEndpointConfigurator.java
> instantiates endpoint class, the getEndpointInstace method will have to
> call something like:
> 
> injector.getInstance(clazz);
> 
> but, then again the DefaultServerEndpointConfiguration will also have be
> instantiated by the injector.
> 
> Any help would be appreciated. Thanks

Changing the Tomcat-specific class won't be necessary. You can do this with 
just the API. In your @ServerEndpoint annotation, you need to specify a 
different configuration that extends 
javax.websocket.server.ServerEndpointConfig.Configurator. Spring Framework has 
a class [1] that does just this for its DI and other bean processing. You can 
probably create a class modeled after that.

Nick

[1] 
https://github.com/spring-projects/spring-framework/blob/master/spring-websocket/src/main/java/org/springframework/web/socket/server/endpoint/SpringConfigurator.java?source=cc
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: any update on an anticipated release date for 7.0.43?

[Nick Williams]

On Sep 20, 2013, at 9:18 AM, Bob DeRemer wrote:

> 
> 
>> -Original Message-
>> From: Bob DeRemer [mailto:bob.dere...@thingworx.com]
>> Sent: Tuesday, September 17, 2013 12:28 PM
>> To: Tomcat Users List
>> Subject: RE: any update on an anticipated release date for 7.0.43?
>> 
>> 
>> 
>>> -Original Message-
>>> From: Mark Thomas [mailto:ma...@apache.org]
>>> Sent: Tuesday, September 17, 2013 11:49 AM
>>> To: Tomcat Users List
>>> Subject: Re: any update on an anticipated release date for 7.0.43?
>>> 
>>> On 17/09/2013 15:53, Bob DeRemer wrote:
 Has a decision (even tentative) been made on when 7.0.43 GA (w/ jsr
 356)
>>> will release?  Just curious if this will be before the end of September.
>>> 
>>> The native release this was blocked by has now happened. Running the
>>> unit tests has identified a series of problems with WebSocket and the
>>> APR/native connector on Windows. I think these are fixed but I need to
>>> wait for the unit test runs to complete. Literally as I typed the last
>>> sentence the Windows tests finished and they passed. Woot!
>>> 
>>> I'll be tagging 8.0.0-RC2 in the next few hours. I expect Violeta will
>>> be tagging
>>> 7.0.43 either later today or early tomorrow.
>> 
>> Awesome - thx for the update!
>> -bob
>> 
> 
> Is it still looking good for a 7.0.43 release this week?   I noticed nothing 
> has been tagged yet, so didn't know if there were some problems uncovered 
> that need to be fixed.

7.0.43 was tagged about 6 hours before you sent this message :-):

http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_43/

There is also currently a vote happening on the developer mailing list as to 
its stability and whether to release:

http://tomcat.markmail.org/thread/yjx2p5n62k2mdcrt

The Tomcat team encourages people willing to test proposed Tomcat releases 
before they are published to join the developer mailing list, download the 
proposed release, test it out, and report back any issues that they believe 
should block the release, if any, in the form of a non-binding vote on the 
release.

Hope this helps,

Nick



smime.p7s
Description: S/MIME cryptographic signature

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

[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.

[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  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):
>>>> 
>>>>
>>>>
>>>>spring_web
>>>>
>>>> 
>>>> 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 Collection load(Class
>> serviceType). However the results of the processing are put in a collection
>> with unpredictable iteration ord

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

[Nick Williams]

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):



spring_web


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).

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

smime.p7s
Description: S/MIME cryptographic signature

Re: Tomcat 8 Websocket API - Cookies & Headers

[Nick Williams]

On Aug 23, 2013, at 1:25 PM, Nick Williams wrote:

> In the modifyHandshake method of your Configurator, you can call 
> getUserProperties on the EndpointConfig argument. This returns a modifiable 
> Map that you can add values to. After modifyHandshake returns 
> and before onOpen is called, the values from that map are copied to the 
> Session, and you can retrieve them by calling Session#getUserProperties(). 
> That's how I'm passing Cookie and HttpSession objects into my endpoints' 
> onOpen methods. For example:
> 
> public class MyConfigurator extends ServerEndpointConfig.Configurator {
>public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest 
> request, HandshakeResponse response) {
> 
>super.modifyHandshake(config, request, response);
>config.getUserProperties.put("httpSessionObject", 
> request.getHttpSession());
>}
> }
> 
> Then later:
> 
> @OnOpen
> public void onOpen(Session session) {
> 
>HttpSession httpSession = (HttpSession) 
> session.getUserProperties().get("httpSessionObject");
> }
> 
> It ain't pretty. IMO, it was a serious design flaw in the spec not to provide 
> ways to get the HttpSession and Cookies from the Session object. Maybe I'll 
> try to get on the EG for the next version. :-)
> 
> N
> 
> On Aug 23, 2013, at 1:01 PM, toddfas wrote:
> 
>> Our existing web app has custom session management (does not use
>> JSESSIONID) and stores the session identifier in a cookie. The cookie is
>> marked httpOnly (and secure) so the client side Javascript opening the
>> websocket does not have access to it. I want to use this session identifier
>> in ServerEndPoint.onOpen to verify the user attempting to open the
>> Websocket connection and then be able to keep track of the user's context
>> as messages are received and sent over websocket.
>> 
>> Thanks for any additional ideas on how to accomplish this.
>> Todd
>> 
>> 
>> On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski  wrote:
>> 
>>> On Fri, Aug 23, 2013 at 7:03 PM, toddfas  wrote:
>>> 
>>>> Thanks very much for the quick response Niki!
>>>> 
>>>> I went down the configurator path too, but then I could not find a way
>>>> to pass the cookie values into the ServerEndPoint.onOpen where I need
>>>> to use it. I tried passing it via session.getRequestParameterMap() but
>>>> that is a Collections.unmodifiableMap(). In my scenario the
>>>> session.getHttpSession() is NULL so I can't put it in there. I didn't
>>>> like the idea of putting it in ThreadLocal (unless I am guaranteed by
>>>> the spec that ServerEndPoint.onOpen is always called on the same
>>>> thread that processes the handshake).
>>>> 
>>>> That was when I started thinking I must be missing something simple.
>>>> Any suggestions?
>>>> 
>>> 
>>> Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
>>> designates an established connection and that means you are already in the
>>> websocket world. I don;t see an easy way for doing this. Can you describe
>>> the use case in greater details. What problem do you solve by having access
>>> to the handshale request headers  (incl cookies) in that phase?
>>> 
>>>> 
>>>> Thanks,
>>>> Todd
>>>> 
>>>> 
>>>> On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski 
>>> wrote:
>>>>> On Fri, Aug 23, 2013 at 2:58 AM, toddfas  wrote:
>>>>> 
>>>>>> I'm trying to figure out how to get access to the cookies and headers
>>>>>> passed up in the Websocket handshake request on Tomcat 8.
>>>>>> 
>>>>>> In Tomcat 7 the whole HttpServletRequest was passed into the
>>>>>> WebSocketServlet. createWebSocketInbound method so it was easy to grab
>>>>>> from the request headers. In Tomcat 8 the querystring and URI are both
>>>>>> exposed by the javax.websocket.Session passed to
>>>>>> ServerEndPoint.onOpen, but I don't see a mechanism for getting the
>>>>>> cookies or headers.
>>>>>> 
>>>>> 
>>>>> You can supply an extension of
>>>>> 
>>>> 
>>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
>>>>> and get
>>>>> 
>>>> 
>>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
>>>>> through
>>>>> modifyHandshake invoked by the container during processing of client
>>>> 'GET'
>>>>> handshake message. Handshake request containes methods for inspecting
>>> the
>>>>> http request parameters and headers.
>>>>> 
>>>>> 
>>>>> 
>>>>>> We are integrating Websocket connections into an existing web app and
>>>>>> want to use the cookies set by our web app in the Websocket connection
>>>>>> process.
>>>>>> 
>>>>>> Thanks for any insight.
>>>>>> Todd

I'm sorry I top-posted! Didn't mean to. :-)

Nick


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

Re: Tomcat 8 Websocket API - Cookies & Headers

[Nick Williams]

In the modifyHandshake method of your Configurator, you can call 
getUserProperties on the EndpointConfig argument. This returns a modifiable 
Map that you can add values to. After modifyHandshake returns 
and before onOpen is called, the values from that map are copied to the 
Session, and you can retrieve them by calling Session#getUserProperties(). 
That's how I'm passing Cookie and HttpSession objects into my endpoints' onOpen 
methods. For example:

public class MyConfigurator extends ServerEndpointConfig.Configurator {
public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest 
request, HandshakeResponse response) {

super.modifyHandshake(config, request, response);
config.getUserProperties.put("httpSessionObject", 
request.getHttpSession());
}
}

Then later:

@OnOpen
public void onOpen(Session session) {

HttpSession httpSession = (HttpSession) 
session.getUserProperties().get("httpSessionObject");
}

It ain't pretty. IMO, it was a serious design flaw in the spec not to provide 
ways to get the HttpSession and Cookies from the Session object. Maybe I'll try 
to get on the EG for the next version. :-)

N

On Aug 23, 2013, at 1:01 PM, toddfas wrote:

> Our existing web app has custom session management (does not use
> JSESSIONID) and stores the session identifier in a cookie. The cookie is
> marked httpOnly (and secure) so the client side Javascript opening the
> websocket does not have access to it. I want to use this session identifier
> in ServerEndPoint.onOpen to verify the user attempting to open the
> Websocket connection and then be able to keep track of the user's context
> as messages are received and sent over websocket.
> 
> Thanks for any additional ideas on how to accomplish this.
> Todd
> 
> 
> On Fri, Aug 23, 2013 at 10:08 AM, Niki Dokovski  wrote:
> 
>> On Fri, Aug 23, 2013 at 7:03 PM, toddfas  wrote:
>> 
>>> Thanks very much for the quick response Niki!
>>> 
>>> I went down the configurator path too, but then I could not find a way
>>> to pass the cookie values into the ServerEndPoint.onOpen where I need
>>> to use it. I tried passing it via session.getRequestParameterMap() but
>>> that is a Collections.unmodifiableMap(). In my scenario the
>>> session.getHttpSession() is NULL so I can't put it in there. I didn't
>>> like the idea of putting it in ThreadLocal (unless I am guaranteed by
>>> the spec that ServerEndPoint.onOpen is always called on the same
>>> thread that processes the handshake).
>>> 
>>> That was when I started thinking I must be missing something simple.
>>> Any suggestions?
>>> 
>> 
>> Well, onOpen is called after the handshake is finished. [WSC-4.4-1] It
>> designates an established connection and that means you are already in the
>> websocket world. I don;t see an easy way for doing this. Can you describe
>> the use case in greater details. What problem do you solve by having access
>> to the handshale request headers  (incl cookies) in that phase?
>> 
>>> 
>>> Thanks,
>>> Todd
>>> 
>>> 
>>> On Thu, Aug 22, 2013 at 10:12 PM, Niki Dokovski 
>> wrote:
 On Fri, Aug 23, 2013 at 2:58 AM, toddfas  wrote:
 
> I'm trying to figure out how to get access to the cookies and headers
> passed up in the Websocket handshake request on Tomcat 8.
> 
> In Tomcat 7 the whole HttpServletRequest was passed into the
> WebSocketServlet. createWebSocketInbound method so it was easy to grab
> from the request headers. In Tomcat 8 the querystring and URI are both
> exposed by the javax.websocket.Session passed to
> ServerEndPoint.onOpen, but I don't see a mechanism for getting the
> cookies or headers.
> 
 
 You can supply an extension of
 
>>> 
>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/ServerEndpointConfig.Configurator.html
 and get
 
>>> 
>> http://docs.oracle.com/javaee/7/api/javax/websocket/server/HandshakeRequest.html
 through
 modifyHandshake invoked by the container during processing of client
>>> 'GET'
 handshake message. Handshake request containes methods for inspecting
>> the
 http request parameters and headers.
 
 
 
> We are integrating Websocket connections into an existing web app and
> want to use the cookies set by our web app in the Websocket connection
> process.
> 
> Thanks for any insight.
> Todd
> 
> -
> 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 com

Re: Exception by upgrading to WebSocket connection in 8.0.0-RC1

[Nick Williams]

On Aug 15, 2013, at 11:27 AM, Mark Thomas wrote:

> On 15/08/2013 08:41, Sergey Shcherbakov wrote:
> 
>> It looks like I am missing some bit of the Tomcat configuration (to call
>> preInit()?).
> 
> You shouldn't need to worry about that.
> 
>> Has anybody seen the issue,
> 
> No.
> 
>> what could be the reason?
> 
> I suspect that as both Spring 4 and Tomcat 8 are both in RC / milestone
> stage that Tomcat changed in a way Spring wasn't expecting.

Yes, I concur. Please file a bug at https://jira.springsource.org/browse/SPR 
ASAP so that they can get it fixed for RC2.

Nick

Re: /META-INF/context.xml seemingly ignored

[Nick Williams]

On Aug 4, 2013, at 11:16 AM, Konstantin Kolinko wrote:

> 2013/8/4 Mark Thomas :
>> On 04/08/2013 02:27, Nick Williams wrote:
>>> 
>>> 
>>> Yes. There's a TOMCAT_HOME/work/Catalina/localhost/support directory, but 
>>> TOMCAT_HOME/conf/Catalina is empty.
> 
> There should be conf/Catalina/localhost directory that is empty. (The
> Catalina directory is not empty).

Yes, my bad. conf/Catalina/localhost exists but is empty.

> 
>> 
>> As expected for Tomcat 8. copyXML is false by default.
>> 
>> (Yes the default has changed again.)
> 
> Huh? The copyXML is false by default in Tomcat 7 as well. I do not see
> any change here.
> 
> It might be good time to start migration guide page for Tomcat 8.

Agreed.

So, looking at this further, this might be an IntelliJ IDEA bug. I'm deploying 
the application using the Tomcat support in IDEA. IDEA creates a directory 
C:\Users\Nicholas\.IntelliJIdea12\system\tomcat\Unnamed_Customer-Support-v15\conf\Catalina\localhost
 and that directory contains support.xml with my context.xml contents. I'm 
betting it's not hooking that up properly. I'll research that route instead.

Sorry if I've wasted anyone's time looking into this.

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

Re: /META-INF/context.xml seemingly ignored

[Nick Williams]

On Aug 3, 2013, at 6:05 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 8/3/13 2:54 PM, Nick Williams wrote:
>> I'm using Tomcat 8.0.0-RC1. Hopefully I'm just missing something 
>> here. I created a web application with the following 
>> /META-INF/context.xml file (I tried both with and without the 
>> path="/support" attribute).
>> 
>> 
>>   
>> > loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/>
>> 
>> 
> 
> 
> If you are using META-INF/context.xml, then the "path" attribute is
> definitely illegal/ignored.
> 
> I haven't read the Javadoc for Tomcat 8 yet, but I think you want:
> 
>   
> 
> Instead of "loaderClass". At least, that's what it would have been for
> Tomcat 7.

className is for specified a different Loader implementation. loaderClass is 
for specifying a different ClassLoader. It's very confusing, but this is 
definitely right.

> 
>> The JAR containing the TomcatInstrumentableClassLoader is in 
>> TOMCAT_HOME/lib. However, when the application starts the class 
>> loader is still Tomcat's WebappClassLoader.
>> 
>> So, I moved the  element to TOMCAT_HOME/conf/context.xml
>> and now it works. When the application starts the class loader is
>> the TomcatInstrumentableClassLoader.
> 
> That's odd.
> 
>> Note that I have confirmed the context.xml file IS in META-INF at
>> the root of my web application (not in /WEB-INF/classes/META-INF).
>> I also noticed that TOMCAT_HOME/conf/Catalina/localhost is empty.
>> There are no files or other directories in that directory at all.
>> So, it would appear that my context.xml is not getting copied. I
>> don't know whether or not that matters. I am deploying my
>> application as an exploded directory (not a WAR), and it is in an
>> external directory (it is not in TOMCAT_HOME/webapps).
>> 
>> Am I doing something wrong here, or is this a bug?
> 
> Anything in the "work" directory? CATALINA_BASE/conf/[Engine]/[Host]/
> should be where context.xml files are copied, so .. this definitely
> looks fishy.

Yes. There's a TOMCAT_HOME/work/Catalina/localhost/support directory, but 
TOMCAT_HOME/conf/Catalina is empty.

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

/META-INF/context.xml seemingly ignored

[Nick Williams]

Guys,

I'm using Tomcat 8.0.0-RC1. Hopefully I'm just missing something here. I 
created a web application with the following /META-INF/context.xml file (I 
tried both with and without the path="/support" attribute).






The JAR containing the TomcatInstrumentableClassLoader is in TOMCAT_HOME/lib. 
However, when the application starts the class loader is still Tomcat's 
WebappClassLoader.

So, I moved the  element to TOMCAT_HOME/conf/context.xml and now it 
works. When the application starts the class loader is the 
TomcatInstrumentableClassLoader.

Note that I have confirmed the context.xml file IS in META-INF at the root of 
my web application (not in /WEB-INF/classes/META-INF). I also noticed that 
TOMCAT_HOME/conf/Catalina/localhost is empty. There are no files or other 
directories in that directory at all. So, it would appear that my context.xml 
is not getting copied. I don't know whether or not that matters. I am deploying 
my application as an exploded directory (not a WAR), and it is in an external 
directory (it is not in TOMCAT_HOME/webapps).

Am I doing something wrong here, or is this a bug?

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

Re: Help about my problem

[Nick Williams]

On Aug 3, 2013, at 1:55 AM, Mehdi Yousefi wrote:

> Hi
> Thanks for your attention
> it is up on port 8000
> but dident respond
> this is for some medical use and the boss did not  accept a risk of
> updating to last version

Well, your boss is wrong and foolish then. Since this is for a medical 
application of some sort, it is even /more/ imperative that you upgrade. There 
have been /numerous/ security issues discovered and fixed in Tomcat 6 in the 
last 6 years. By not upgrading, you are exposing all of that sensitive medical 
information to those security issues. You are putting your medical application 
at /greater/ risk by not upgrading.

> 
> my log after startup is
> 
> Aug 2, 2013 9:49:42 PM org.apache.catalina.core.AprLifecycleListener init
> INFO: The Apache Tomcat Native library which allows optimal performance in
> production environments was not found on the java.library.path:
> /usr/java/jdk1.6.0_02/jre/lib/i386/client:/usr/java/jdk1.6.0_02/
> jre/lib/i386:/usr/java/jdk1.6.0_02/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
> Aug 2, 2013 9:49:42 PM org.apache.coyote.http11.Http11Protocol init INFO:
> Initializing Coyote HTTP/1.1 on http-80 Aug 2, 2013 9:49:42 PM
> org.apache.catalina.startup.Catalina load INFO: Initialization processed in
> 266 ms Aug 2, 2013 9:49:42 PM org.apache.tomcat.util.digester.Digester
> fatalError SEVERE: Parse Fatal Error at line 1 column 1: Premature end of
> file. org.xml.sax.SAXParseException: Premature end of file. at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException
> (ErrorHandlerWrapper.java:195) at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError
> (ErrorHandlerWrapper.java:174) at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError
> (XMLErrorReporter.java:388) at
> com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1411)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next
> (XMLDocumentScannerImpl.java:1037) at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> (XMLDocumentScannerImpl.java:645) at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
> (XMLDocumentFragmentScannerImpl.java:508) at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:807) at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> (XML11Configuration.java:737) at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
> at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1205) at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> (SAXParserImpl.java:522) at
> org.apache.tomcat.util.digester.Digester.parse(Digester.java:1581) at
> org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:402)
> at org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance
> (MemoryUserDatabaseFactory.java:103) at
> org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:793) at
> org.apache.naming.NamingContext.lookup(NamingContext.java:140) at
> org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal
> (NamingContextBindingsEnumeration.java:113) at
> org.apache.naming.NamingContextBindingsEnumeration.next
> (NamingContextBindingsEnumeration.java:71) at
> org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans
> (GlobalResourcesLifecycleListener.java:137) at
> org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans
> (GlobalResourcesLifecycleListener.java:109) at
> org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent
> (GlobalResourcesLifecycleListener.java:81) at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
> at org.apache.catalina.core.StandardServer.start(StandardServer.java:703)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597) at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Aug 2, 2013
> 9:49:42 PM org.apache.naming.NamingContext lookup WARNING: Unexpected
> exception resolving reference org.xml.sax.SAXParseException: Premature end
> of file. at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> (AbstractSAXParser.java:1231) at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
> 

Re: Tomcat Websocket Implementation

[Nick Williams]

On Aug 2, 2013, at 12:42 PM, Nick Williams wrote:

> 
> On Aug 2, 2013, at 12:05 PM, Igor Urisman wrote:
> 
>> Dear all,
>> 
>> I'm looking into a solution that will make extensive use of websockets.
>> Details are unimportant, but here's the question that I'd like to have some
>> insight into.  The current implementation (official
>> example<http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/examples/WEB-INF/classes/websocket/chat/ChatWebSocketServlet.java?revision=1354477&view=markup>)
>> seems independent of the JSR
>> 356<http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm>.
>> Is work underway to implement the javax.websocket.* objects, or is what's
>> in org.apache.catalina.websocket it for the enforceable future?
> 
> Tomcat 8 has a completed (though not yet fully tested and vetted) 
> implementation of JSR-356. We're voting right now on the developer's mailing 
> list whether to release Tomcat 8.0.0-RC1 alpha.
> 
> Though Tomcat 8 is the only Tomcat that will support the Servlet, JSP, and EL 
> specifications included in Java EE 7 (they will not be back-ported to Tomcat 
> 7), a decision was made a while ago to deprecate the existing Tomcat 7 
> WebSocket implementation and back-port JSR-356 to Tomcat 7. This is the only 
> Java EE 7 component that will be back-ported to Tomcat 7, AFAIK. I don't 
> personally know this will happen (I'm not one of the developers), but since 
> the JSR-356 implementation in Tomcat 8 is complete now, it shouldn't be too 
> long.

**I don't personally know WHEN this will happen…

> 
> If you want to play with the JSR-356 implementation for now, feel free to 
> download and use Tomcat 8 RC1 when it releases in (hopefully) the next few 
> days. We encourage it, because the more people who download it and try it 
> out, the better our chances of chasing down and fixing bugs now instead of 
> after a general release.

You could also download the POTENTIAL release candidate that is being voted on 
right now 
(https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC1/bin/), but I 
can't guarantee that this is the actual release candidate that will come out.

> 
> Nick

Re: Tomcat Websocket Implementation

[Nick Williams]

On Aug 2, 2013, at 12:05 PM, Igor Urisman wrote:

> Dear all,
> 
> I'm looking into a solution that will make extensive use of websockets.
> Details are unimportant, but here's the question that I'd like to have some
> insight into.  The current implementation (official
> example)
> seems independent of the JSR
> 356.
> Is work underway to implement the javax.websocket.* objects, or is what's
> in org.apache.catalina.websocket it for the enforceable future?

Tomcat 8 has a completed (though not yet fully tested and vetted) 
implementation of JSR-356. We're voting right now on the developer's mailing 
list whether to release Tomcat 8.0.0-RC1 alpha.

Though Tomcat 8 is the only Tomcat that will support the Servlet, JSP, and EL 
specifications included in Java EE 7 (they will not be back-ported to Tomcat 
7), a decision was made a while ago to deprecate the existing Tomcat 7 
WebSocket implementation and back-port JSR-356 to Tomcat 7. This is the only 
Java EE 7 component that will be back-ported to Tomcat 7, AFAIK. I don't 
personally know this will happen (I'm not one of the developers), but since the 
JSR-356 implementation in Tomcat 8 is complete now, it shouldn't be too long.

If you want to play with the JSR-356 implementation for now, feel free to 
download and use Tomcat 8 RC1 when it releases in (hopefully) the next few 
days. We encourage it, because the more people who download it and try it out, 
the better our chances of chasing down and fixing bugs now instead of after a 
general release.

Nick


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

Re: WebappClassLoader problem

[Nick Williams]

On Jul 31, 2013, at 11:40 AM, Edward W. Rouse wrote:

> I'm losing my mind here. I finally went full standard to see if the changes
> in tomcat 7 would allow me to avoid custom class loaders and contexts, but
> ran into a catch-22 issue.
> 
> 
> 
> I was getting:
> 
> 
> 
> java.lang.ClassCastException:
> com.sun.xml.ws.transport.http.servlet.WSServletContainerInitializer cannot
> be cast to javax.servlet.ServletContainerInitializer
> 
>at
> org.apache.catalina.startup.ContextConfig.getServletContainerInitializer(Con
> textConfig.java:1654)
> 
>at
> org.apache.catalina.startup.ContextConfig.processServletContainerInitializer
> s(ContextConfig.java:1562)
> 
>at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1270)
> 
>at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:
> 878)
> 
>at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:
> 376)
> 
>at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor
> t.java:119)
> 
>at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java
> :90)
> 
>at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:
> 5322)
> 
> 
> 
> So I tracked down where the WSServletContainerInitializer was coming from
> and removed the jar file. Now I get:
> 
> 
> 
> SEVERE: Error configuring application listener of class
> org.apache.catalina.deploy.ApplicationListener@1b104d7
> 
> java.lang.ClassNotFoundException:
> com.sun.xml.ws.transport.http.servlet.WSServletContextListener
> 
>at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
> a:1714)
> 
>at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.jav
> a:1559)
> 
>at
> org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceMan
> ager.java:527)
> 
>at
> org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(Def
> aultInstanceManager.java:509)
> 
>at
> org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceM
> anager.java:137)
> 
>at
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:
> 4854)
> 
>at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:
> 5434)
> 
>at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> 
>at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:9
> 01)
> 
>at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> 
>at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
> 
>at
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1113)
> 
>at
> org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1
> 671)
> 
>at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> 
>at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 
>at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
> va:886)
> 
>at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:9
> 08)
> 
>at java.lang.Thread.run(Thread.java:662)
> 
> 
> 
> and what's in the context is:
> 
> 
> 
> 
> 
>  
> 
> className="org.apache.naming.resources.VirtualDirContext"
> 
>  extraResourcePaths="/idwm/*/=/usr/us/idwm/plugins/*/"/>
> 
> 
> 
> className="org.apache.catalina.loader.VirtualWebappLoader"
> 
>  virtualClasspath="/usr/us/idwm/plugins/*/WEB-INF/classes;
> 
>  /usr/us/idwm/plugins/*/WEB-INF/lib/*.jar;
> 
>  /usr/us/idwm/plugins/*/;"
> 
>/>
> 
>  
> 
> 
> 
> 
> 
> So now what? I'm using the classes provided by apache and I'm damned if I do
> and damned if I don't. Is there even a solution to this?

I've seen that before, with Persistence on GlassFish. Turned out I had the 
Persistence API JARs in /WEB-INF/lib in my web application. Since two identical 
classes loaded by two different class loaders are actually different classes, 
the cast failed.

My bet is you have the javax.websocket JAR(s) in /WEB-INF/lib in your web 
application. You can compile against these JARs, but they MUST NOT be in 
/WEB-INF/lib.

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

Re: "The Apache Tomcat Connector - Webserver HowTo" documentation for Apache Httpd 2.4.x and Tomcat 7

[Nick Williams]

On Jul 25, 2013, at 10:59 AM, Rainer Jung wrote:

> On 25.07.2013 17:14, srinivas yelamanchili wrote:
>> Hi,
>> I installed Apache Httpd 2.4.6 and Tomcat 7.0.42 from source code (.tar.gz) 
>> on Redhat Linux and looking for documentation to enable AJP and connect 
>> Tomcat with Httpd using AJP/APR
>> 
>> I have the following questions (and please let me know where I can post the 
>> same if this email group is the not the correct place) :
>> 
>> 1. The 'Tomcat Connectors JK 1.2' Binary Releases at
>> http://tomcat.apache.org/download-connectors.cgi
>> 
>> only seem to be available for Windows (and not for Redhat Linux).
>> Aren't there any binary releases for unix based systems?
> 
> They are very easy to build on Linux. Since there are so many
> distributions we currently do not provide "official" binaries.

Slightly off-topic question: is this a resources limitation (y'all don't have 
access to a build server with different agents running on different distros)  
or a time limitation (y'all don't have someone who can spend the time 
maintaining the builds)?

If it's a resources limitation, I have a publicly-accessible TeamCity server 
with an unlimited OpenSource license hosting Windows 7, Mac OS X 
SLeopard/Lion/MLion, Debian, RedHat, and SuSE agents that I would be happy to 
donate some resources from. It's not very busy and would have plenty of time to 
run CI, SNAPSHOT, and RC builds for all of the platforms.

Just curious.

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

Re: servlet 3.1, etc?

[Nick Williams]

On Jul 10, 2013, at 9:32 AM, Edoardo Panfili wrote:

> Il 10/07/13 12:18, Mark Thomas ha scritto:
>> On 10/07/2013 00:06, Jess Holle wrote:
>>> >Is there an ETA (in terms of both a version and rough date) for Tomcat
>>> >moving to the new spec versions introduced by Java EE 7?
>> Tomcat 8.
>> 
>> Implementation complete? Best guess is a couple of months. The more help
>> we get with the EL 3.0 implementation, the sooner we'll finish.
>> 
>> Stable? Best guess is late this year / early next.
>> 
> 
> very good news for me! thank you!
> I will try to build Tomcat from trunk.
> 
> It makes sense if I try it with JDK8 milestones? (I'd like to use java8 in my 
> application but is not essential)
> 
> thank you again
> Edoardo

My testing on Tomcat 8 has been exclusively on Java 8. It has been working very 
well (minus the incomplete EL 3.0 implementation, of course). If you have a 
need for Java 8, I encourage you to test Tomcat 8 on Java 8. It will help the 
Tomcat developers because you may find Tomcat bugs that exist on Java 8 but not 
on Java 7.

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

Re: Init params picked up before SCI?

[Nick Williams]

On Jun 17, 2013, at 2:33 PM, Mark Thomas wrote:

> On 17/06/2013 14:26, Nicholas Williams wrote:
>> On Jun 17, 2013, at 8:15, Nick Williams  
>> wrote:
>> 
>>> It seems obvious, but I couldn't find it mentioned in the spec, which 
>>> concerns me. Hopefully I'm overlooking something.
>>> 
>>> All s in the (merged?) deployment descriptor are guaranteed to 
>>> be picked up and placed in the ServletContext before any 
>>> ServletContainerInitializers are triggered, right?
>>> 
>>> Nick
>> 
>> Sorry, I meant s, not s. Methinks I'm
>> operating on too little sleep.
> 
> It is the logical way of doing things but I don't see any explicit language 
> either. The best I could find was section 8.3 which implies in paragraph 3 
> that that the combined web.xml needs to have been processed before the SCIs 
> are called.
> 
> Mark

Well at least I'm not going blind.

So how does Tomcat do it? It adds all the context-params to the context before 
triggering the SCIs?

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

Init params picked up before SCI?

[Nick Williams]

It seems obvious, but I couldn't find it mentioned in the spec, which concerns 
me. Hopefully I'm overlooking something.

All s in the (merged?) deployment descriptor are guaranteed to be 
picked up and placed in the ServletContext before any 
ServletContainerInitializers are triggered, right?

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

Re: Making sure I understand application startup order correctly

[Nick Williams]

On May 31, 2013, at 5:06 AM, Mark Thomas wrote:

> On 30/05/2013 23:42, Nick Williams wrote:
> 
>> I still have some uncertainties with a couple:
>> 
>> #2: 8.2.4 says of ServletContainerInitializers: "the order in which
>> these services are discovered MUST follow the application’s class
>> loading delegation model."
> 
> That is poor specification language. Discovery != invocation although I
> suspect that is what is meant.
> 
>> So, SCI /classes/ in the application
>> should be discovered before SCI classes in the container /if/ "parent
>> last" class loading is used (it is by default in Tomcat), and SCI
>> classes in the container should be discovered before SCI classes in
>> the application /if/ "parent first" class loading is used (it is by
>> default in WebSphere, for example). If they get reordered from the
>> order they're discovered in before they're fired, I'm not sure why
>> Tomcat is doing that. You say that Tomcat, specifically, respects the
>> fragment order (even though the spec doesn't say you must do so), but
>> SCIs provided by the container don't belong to fragments and thus
>> can't have a fragment order, so that ordering scheme only works for
>> SCIs provided by the application. So if Tomcat is ordering them
>> differently from the order they're discovered in, how is it
>> determining that order?
> 
> Tomcat first scans for JARs and fragments. Dummy fragments are created
> for any discovered JAR that doesn't have one. The JarScanner will always
> scan WEB-INF/lib before it scans the container regardless of the setting
> of delegate on the Context. That is one possible bug.
> 
> Tomcat then orders the fragments it has discovered. This includes
> fragments from container JARs. There is another potential bug here as
> fragments in container JARs should be ignored.
> 
> Tomcat then looks in the ordered fragments for SCIs. A possible bug here
> is that SCIs from the container should always be processed and currently
> they could be ignored based on ordering.
> 
> It appears to be possible for a container JAR with an SCI that should
> always be used to be excluded from a webapp. A third possible bug.
> 
> The counter point is that, as per the spec, it should be impossible to
> disable any container provided SCI on a per application basis.
> 
>> #6: 8.2.3(1) says "The order for listeners, servlets, filters if
>> relevant must be specified in either the web-fragment.xml or the
>> web.xml." 8.2.2(1)(b) says "The web.xml and WEB-INF/classes MUST be
>> processed before any of the web-fragments listed in the
>> absolute-ordering element." 8.2.2(2)(b) says "The web.xml and
>> WEB-INF/classes MUST be processed before any of the web-fragments
>> listed in the ordering element." So, I know for sure that 
>> in web.xml and web-fragment.xml come before
>> programmatically-registered filters (this was part of my mistake
>> before). What I'm still uncertain on is: - If there are /no/
>>  in web.xml or web-fragment.xml and filters are /only/
>> registered programmatically, is their order unspecified, or are they
>> in the order addFilter is called?
> 
> Again, look for isMatchAfter in the registration interface.
> 
>> - What comes first: @WebFilters or
>> programmatically-registered filters?
> 
> @WebFilters since annotations are merged into the associated web.xml.
> 
>> Or is this unspecified? - If
>> there are  and programmatically-registered filters, will the
>>  be placed on the chain in the order they are declared and
>> /then/ the programmatic filters placed on the chain in the order they
>> are declared, or is this unspecified?
> 
> isMatchAfter

Okay. I understand now. Here's one of the consequences of inability to order 
SCI is the spec (thankfully Tomcat supports it, but that's not portable):

I have two filters: a LoggingFilter (/*) and an AuthenticationFilter (each URL 
pattern that needs securing). The LoggingFilter sets up information about the 
current request (UUID, username, etc.) in the Log4j context map, and it must 
come before the AuthenticationFilter, which makes sure the user is logged in. 
That filter must, then, come before any other filters.

I add the filters in an SCI using isMatchAfter=false. Thankfully, Tomcat 
supports SCI ordering, so putting this in my deployment descriptor ensures that 
the WebSocket filter gets added after my filters:


spring_web



And, indeed, that worked. However, it's not guaranteed to work on all 
containers.

Off-topic, I should point out that I believe this is also a po

Re: Making sure I understand application startup order correctly

[Nick Williams]

On May 30, 2013, at 3:38 PM, Mark Thomas wrote:

> On 30/05/2013 21:04, Nick Williams wrote:
>> 
>> On May 29, 2013, at 6:58 AM, Pid wrote:
>> 
>>> On 29/05/2013 00:24, Nick Williams wrote:
>>>> Guys,
>>>> 
>>>> Can some of the fine experts on this list double check my
>>>> assertions below and let me know if I'm going wrong anywhere? I
>>>> hope I got it all right. :-)
>>>> 
>>>> Assertion #1 If metadata-complete="true" is present in the
>>>> deployment descriptor: A) The container does NOT scan
>>>> /WEB-INF/classes for annotations, B) The container does NOT scan
>>>> /WEB-INF/lib JARs for ServletContainerInitializers,
>>> 
>>> "The metadata-complete and invocation of
>>> ServletContainerInitializers are independent."
>>> 
>>> https://java.net/jira/browse/SERVLET_SPEC-36
>> 
>> Thanks. I'm assuming that I got everything else correct since this is
>> the only thing you corrected and nobody else replied.
> 
> Or pid just stopped at the first invalid assumption ;)
> 
>> But I want to make sure I understand the discussion at this link
>> correctly. Rajiv says here: "Ordering does not apply to
>> ServletContainerInitializers." Is that really correct? There's really
>> no way at all to order the invocation of
>> ServletContainerInitializers' onStartup methods??? Mark, you seemed
>> to be involved in this discussion a lot. Is this really true???
> 
> If that is what the spec lead says then yes. Tomcat will process them in
> the order they are found: i.e. respecting the fragment order but you
> can't rely on a) any other container doing the same, b) Tomcat
> continuing to do the same (although it is unlikely to change unless a
> spec feature mandates a change)
> 
>>>> C) The container does NOT scan /WEB-INF/lib JARs for
>>>> web-fragment.xml files
> 
> False. The scan still occurs because the ordering elements determines
> whether or not SCIs are scanned for.
> 
> , and D) The container does NOT scan
>>>> /WEB-INF/lib JARs for annotations.
>>>> 
>>>> Assertion #2 If class loading is configured "parent last," the
>>>> ServletContainerInitializers in the application are fired before
>>>> ServletContainerInitializers provided by the container. If class
>>>> loading is configured "parent first", the
>>>> ServletContainerInitializers provided by the container fire
>>>> before the ServletContainerInitializers in the application.
> 
> False. Ordering of SCIs from the container is undefined, as is the
> mechanism by which they get added to the app. It is a container specific
> process.
> 
>>>> Assertion #3 ServletContainerInitializers in the container and in
>>>> /WEB-INF/lib JARs are fired before any ServletContextListeners.
>>>> The order in which they are fired is determined by
>>>>  (web.xml) and/or  (web-fragment.xml),
>>>> but if neither of those are present the order is unspecified.
> 
> Listeners defined in a single web[-fragment].xml will be fired in the
> order they are defined.
> 
>>>> Assertion #4 The init methods of ServletContextListeners declared
>>>> in the container, in /WEB-INF/classes, and in /WEB-INF/lib JARS
>>>> are all fired BEFORE the init methods of any Filters or Servlets.
>>>> The destroy methods of ServletContextListeners declared in the
>>>> container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all
>>>> fired AFTER the destroy methods of any Filters or Servlets.
>>>> 
>>>> Assertion #5 The init methods of Filters declared in the
>>>> container, in /WEB-INF/classes, and in /WEB-INF/lib JARs are all
>>>> fired BEFORE the init methods of any Servlets. The destroy
>>>> methods of Filters declared in the container, in
>>>> /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER
>>>> the destroy methods of any Servlets.
>>>> 
>>>> Assertion #6 If any given ServletContainerInitializer is the
>>>> first ServletContainerInitializer to be fired when an application
>>>> starts up, and that ServletContainerInitializer adds a
>>>> ServletContextListener and a Filter to the ServletContext: A) The
>>>> Listener it adds will be the first Listener whose init method is
>>>> called and the last Listener whose destroy method is called,
> 
> False.
> 
>>>> B)
>>>

Re: Making sure I understand application startup order correctly

[Nick Williams]

On May 29, 2013, at 6:58 AM, Pid wrote:

> On 29/05/2013 00:24, Nick Williams wrote:
>> Guys,
>> 
>> Can some of the fine experts on this list double check my assertions below 
>> and let me know if I'm going wrong anywhere? I hope I got it all right. :-)
>> 
>> Assertion #1
>> If metadata-complete="true" is present in the deployment descriptor:
>> A) The container does NOT scan /WEB-INF/classes for annotations,
>> B) The container does NOT scan /WEB-INF/lib JARs for 
>> ServletContainerInitializers,
> 
> "The metadata-complete and invocation of ServletContainerInitializers
> are independent."
> 
> https://java.net/jira/browse/SERVLET_SPEC-36

Thanks. I'm assuming that I got everything else correct since this is the only 
thing you corrected and nobody else replied.

But I want to make sure I understand the discussion at this link correctly. 
Rajiv says here: "Ordering does not apply to ServletContainerInitializers." Is 
that really correct? There's really no way at all to order the invocation of 
ServletContainerInitializers' onStartup methods??? Mark, you seemed to be 
involved in this discussion a lot. Is this really true???

Nick

> 
> 
> p
> 
>> C) The container does NOT scan /WEB-INF/lib JARs for web-fragment.xml files, 
>> and
>> D) The container does NOT scan /WEB-INF/lib JARs for annotations.
>> 
>> Assertion #2
>> If class loading is configured "parent last," the 
>> ServletContainerInitializers in the application are fired before 
>> ServletContainerInitializers provided by the container. If class loading is 
>> configured "parent first", the ServletContainerInitializers provided by the 
>> container fire before the ServletContainerInitializers in the application.
>> 
>> Assertion #3
>> ServletContainerInitializers in the container and in /WEB-INF/lib JARs are 
>> fired before any ServletContextListeners. The order in which they are fired 
>> is determined by  (web.xml) and/or  
>> (web-fragment.xml), but if neither of those are present the order is 
>> unspecified.
>> 
>> Assertion #4
>> The init methods of ServletContextListeners declared in the container, in 
>> /WEB-INF/classes, and in /WEB-INF/lib JARS are all fired BEFORE the init 
>> methods of any Filters or Servlets. The destroy methods of 
>> ServletContextListeners declared in the container, in /WEB-INF/classes, and 
>> in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Filters 
>> or Servlets.
>> 
>> Assertion #5
>> The init methods of Filters declared in the container, in /WEB-INF/classes, 
>> and in /WEB-INF/lib JARs are all fired BEFORE the init methods of any 
>> Servlets. The destroy methods of Filters declared in the container, in 
>> /WEB-INF/classes, and in /WEB-INF/lib JARs are all fired AFTER the destroy 
>> methods of any Servlets.
>> 
>> Assertion #6
>> If any given ServletContainerInitializer is the first 
>> ServletContainerInitializer to be fired when an application starts up, and 
>> that ServletContainerInitializer adds a ServletContextListener and a Filter 
>> to the ServletContext:
>> A) The Listener it adds will be the first Listener whose init method is 
>> called and the last Listener whose destroy method is called,
>> B) The Filter it adds will be the first Filter whose init method is called 
>> and the last Filter whose destroy method is called, and
>> C) The Filter will be the first Filter on the Filter chain, always.
>> 
>> Thanks in advance,
>> 
>> Nick
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -- 
> 
> [key:62590808]
> 
> -
> 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

Making sure I understand application startup order correctly

[Nick Williams]

Guys,

Can some of the fine experts on this list double check my assertions below and 
let me know if I'm going wrong anywhere? I hope I got it all right. :-)

Assertion #1
If metadata-complete="true" is present in the deployment descriptor:
A) The container does NOT scan /WEB-INF/classes for annotations,
B) The container does NOT scan /WEB-INF/lib JARs for 
ServletContainerInitializers,
C) The container does NOT scan /WEB-INF/lib JARs for web-fragment.xml files, and
D) The container does NOT scan /WEB-INF/lib JARs for annotations.

Assertion #2
If class loading is configured "parent last," the ServletContainerInitializers 
in the application are fired before ServletContainerInitializers provided by 
the container. If class loading is configured "parent first", the 
ServletContainerInitializers provided by the container fire before the 
ServletContainerInitializers in the application.

Assertion #3
ServletContainerInitializers in the container and in /WEB-INF/lib JARs are 
fired before any ServletContextListeners. The order in which they are fired is 
determined by  (web.xml) and/or  (web-fragment.xml), 
but if neither of those are present the order is unspecified.

Assertion #4
The init methods of ServletContextListeners declared in the container, in 
/WEB-INF/classes, and in /WEB-INF/lib JARS are all fired BEFORE the init 
methods of any Filters or Servlets. The destroy methods of 
ServletContextListeners declared in the container, in /WEB-INF/classes, and in 
/WEB-INF/lib JARs are all fired AFTER the destroy methods of any Filters or 
Servlets.

Assertion #5
The init methods of Filters declared in the container, in /WEB-INF/classes, and 
in /WEB-INF/lib JARs are all fired BEFORE the init methods of any Servlets. The 
destroy methods of Filters declared in the container, in /WEB-INF/classes, and 
in /WEB-INF/lib JARs are all fired AFTER the destroy methods of any Servlets.

Assertion #6
If any given ServletContainerInitializer is the first 
ServletContainerInitializer to be fired when an application starts up, and that 
ServletContainerInitializer adds a ServletContextListener and a Filter to the 
ServletContext:
A) The Listener it adds will be the first Listener whose init method is called 
and the last Listener whose destroy method is called,
B) The Filter it adds will be the first Filter whose init method is called and 
the last Filter whose destroy method is called, and
C) The Filter will be the first Filter on the Filter chain, always.

Thanks in advance,

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

Re: Is there a way to make manager applications be first ones loaded?

[Nick Williams]

On May 28, 2013, at 4:49 PM, Nick Williams wrote:

> At $work, we have an automated build system that twice-daily compiles our 
> application and deploys it to the Tomcat servers in our QA environment. It 
> uses the Tomcat manager web service (and the Tomcat Ant tasks) to manage this 
> behavior. More precisely, it first builds the application, then undeploys the 
> old application, then shuts down Tomcat, then runs database upgrades against 
> the QA database, then starts Tomcat back up, and then finally deploys the 
> application.
> 
> We've been having a problem with random FileNotFoundExceptions whenever the 
> Ant task tries to deploy the WAR file using the Tomcat manager web service, 
> and we recently figured out what's going on. If the only application that's 
> running on Tomcat is our application, we don't have any problems. However, if 
> there are other applications, sometimes those applications start before the 
> manager application starts. Sometimes those applications take /several 
> minutes/ to start before the manager starts. However, the order they appear 
> in appears to be random. We can start Tomcat and immediately go to the 
> manager, then shut down Tomcat, start it back up with the same application, 
> and it suddenly be 2-3 minutes before the manager is available.
> 
> The FileNotFoundExceptions in our Ant build happen when the Ant task 
> successfully contacts Tomcat but Tomcat returns a 404 for the manager because 
> that application hasn't started yet. That's unpleasant.
> 
> So, is there a way to make the manager application or applications always be 
> the first ones loaded? We really need the Tomcat-supplied manager 
> applications to start first so that we can consistently automatically deploy 
> our applications.
> 
> Nick

Oh, and in the interest of completeness, we're currently using Java 7u21 and 
Tomcat 7.0.33.

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

Is there a way to make manager applications be first ones loaded?

[Nick Williams]

At $work, we have an automated build system that twice-daily compiles our 
application and deploys it to the Tomcat servers in our QA environment. It uses 
the Tomcat manager web service (and the Tomcat Ant tasks) to manage this 
behavior. More precisely, it first builds the application, then undeploys the 
old application, then shuts down Tomcat, then runs database upgrades against 
the QA database, then starts Tomcat back up, and then finally deploys the 
application.

We've been having a problem with random FileNotFoundExceptions whenever the Ant 
task tries to deploy the WAR file using the Tomcat manager web service, and we 
recently figured out what's going on. If the only application that's running on 
Tomcat is our application, we don't have any problems. However, if there are 
other applications, sometimes those applications start before the manager 
application starts. Sometimes those applications take /several minutes/ to 
start before the manager starts. However, the order they appear in appears to 
be random. We can start Tomcat and immediately go to the manager, then shut 
down Tomcat, start it back up with the same application, and it suddenly be 2-3 
minutes before the manager is available.

The FileNotFoundExceptions in our Ant build happen when the Ant task 
successfully contacts Tomcat but Tomcat returns a 404 for the manager because 
that application hasn't started yet. That's unpleasant.

So, is there a way to make the manager application or applications always be 
the first ones loaded? We really need the Tomcat-supplied manager applications 
to start first so that we can consistently automatically deploy our 
applications.

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

Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

[Nick Williams]

On May 22, 2013, at 11:35 AM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 5/22/13 10:18 AM, Nick Williams wrote:
>> 
>> On May 22, 2013, at 9:09 AM, Christopher Schultz wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> Mark,
>>> 
>>> On 5/21/13 2:38 PM, Mark Thomas wrote:
>>>> On 21/05/2013 19:01, Michael-O wrote:
>>>>> Mark,
>>>>> 
>>>>> I did receive an answer to the issue, citing your findings.
>>>>> See verbatim copy below:
>>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> I received the following update from our developer:
>>>>> 
>>>>> **
>>>>> The theoretical problem is that the thread is holding the app
>>>>> class loader so it remains reachable and the app is never
>>>>> unloaded. So if the user loads and unloads the app, the app
>>>>> classes remain in memory. Subsequent loading and unloading of
>>>>> the app will not get pinned in memory as the thread is
>>>>> already running so the subsequent loading and unloading will
>>>>> not cause additional class loaders to be pinned. It is a
>>>>> fixed size memory leak. It does not grow.
>>>>> 
>>>>> The thread suggests setting the context class loader to be
>>>>> the parent of the default context class loader. This may work
>>>>> in Tomcat but it's pretty random. I am researching the
>>>>> problem to determine what if anything the driver should do to
>>>>> work across all containers. A Tomcat specific fix is not
>>>>> acceptable.
>>>> 
>>>> Almost but not quite. The correct fix is to set the context
>>>> class loader of the Thread to the class loader that loaded the
>>>> Driver
>>> 
>>> +1
>>> 
>>>> or, alternatively, the class loader that loaded the thread
>>>> class.
>>> 
>>> Do you mean java.lang.Thread (primordial)? Or whatever subclass
>>> they are using? Maybe it would be more accurate to say "the
>>> ClassLoader of the runnable being run" which covers
>>> thread-subclasses or standard Runnables being run by a standard
>>> Thread.
>> 
>> Or why not just java.sql.DriverManager.class.getClassLoader()?
>> Since drivers are always stored in the DriverManager regardless of
>> what class loader they're loaded in (hence why you shouldn't put
>> the driver in WEB-INF/lib), isn't the alway-correct solution to use
>> the class loader that loaded the DriverManager for this thread?
> 
> I suspect that the DriverManager will always be loaded by the boot
> ClassLoader, since the default-dispatch for ClassLoaders is to chekc
> the parent first, then check "yourself". The DriverManager is at the
> top-level (well, there is primordial, but that doesn't really count)
> ClassLoader so you'll always get that.
> 
> I don't think that will work because the boot ClassLoader won't be
> able to load the JDBC driver's classes, since they are in the
> container's ClassLoader. (boot ClassLoader should be set to
> CATLAINA_BASE/bin/*.jar while the container's ClassLoader will be set
> to CATALINA_BASE/lib/*.jar).
> 
> Also remember that not all JDBC drivers are "registering" drivers:
> some were explicitly-written *not* to register themselves because of
> foolishness like this. When you are using a connection-pool, there's
> no reason to register the driver with the DriverManager because the
> pool itself acts kind of as the driver manager.
> 
> For example MySQL's Connector/J com.mysql.jdbc.Driver class extends
> "NonRegisteringDriver" and adds only a static initializer that
> basically does this:
> 
> static {
>DriverManager.register(new Driver());
> }
> 
> So if I wanted to (and I probably should!), I could change my "driver"
> configuration from com.mysql.jdbc.Driver to
> com.mysql.jdbc.NonRegisteringDriver and avoid the DriverManager
> entirely. (And your suggestion above would not really be valid
> anymore, since the DriverManager is not involved).
> 
> - -chris

Ahh. That makes sense.

And I will be changing my context.xml resource definitions now... :-)

Nick

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

Re: Follow-up: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread

[Nick Williams]

On May 22, 2013, at 9:09 AM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Mark,
> 
> On 5/21/13 2:38 PM, Mark Thomas wrote:
>> On 21/05/2013 19:01, Michael-O wrote:
>>> Mark,
>>> 
>>> I did receive an answer to the issue, citing your findings. See
>>> verbatim copy below:
>>> 
>>> Hi Michael,
>>> 
>>> I received the following update from our developer:
>>> 
>>> ** The
>>> theoretical problem is that the thread is holding the app class 
>>> loader so it remains reachable and the app is never unloaded. So
>>> if the user loads and unloads the app, the app classes remain in
>>> memory. Subsequent loading and unloading of the app will not get
>>> pinned in memory as the thread is already running so the
>>> subsequent loading and unloading will not cause additional class
>>> loaders to be pinned. It is a fixed size memory leak. It does not
>>> grow.
>>> 
>>> The thread suggests setting the context class loader to be the
>>> parent of the default context class loader. This may work in
>>> Tomcat but it's pretty random. I am researching the problem to
>>> determine what if anything the driver should do to work across
>>> all containers. A Tomcat specific fix is not acceptable.
>> 
>> Almost but not quite. The correct fix is to set the context class
>> loader of the Thread to the class loader that loaded the Driver
> 
> +1
> 
>> or, alternatively, the class loader that loaded the thread class.
> 
> Do you mean java.lang.Thread (primordial)? Or whatever subclass they
> are using? Maybe it would be more accurate to say "the ClassLoader of
> the runnable being run" which covers thread-subclasses or standard
> Runnables being run by a standard Thread.

Or why not just java.sql.DriverManager.class.getClassLoader()? Since drivers 
are always stored in the DriverManager regardless of what class loader they're 
loaded in (hence why you shouldn't put the driver in WEB-INF/lib), isn't the 
alway-correct solution to use the class loader that loaded the DriverManager 
for this thread?

> 
>>> As Mark Thomas pointed out it is critical that the driver is
>>> loaded in the boot or system or container class loader, not the
>>> app class loader. If the driver is in the app class loader then
>>> when the app is unloaded the driver also should be unloaded.
>>> Unfortunately this doesn't work. The driver itself remains
>>> reachable so the app class loader is reachable so the app is
>>> never unloaded. At present there is no general way to solve this
>>> problem. The necessary hooks are added in JDK 8.
>> 
>> I'd agree to this point.
>> 
>>> Most users put the driver in the container, not the app, so this
>>> is rarely a problem.
>> 
>> I don't agree with this. I often see this with JDBC drivers which
>> is why Tomcat has a pile of code specifically to unpick the mess
>> this creates.
> 
> They are missing the point: the leak cannot be avoided, even if the
> driver is (correctly) placed in the container-level ClassLoader and
> not the application. It's frustrating when driver authors take so long
> so understand what is going on and how easy (and reasonable) it is to
> fix the problem.
> 
>>> **
>>> 
>>> I will certainly have to fill out a bug to have it investigated
>>> officially.
>> 
>> That is good news.
>> 
>>> Seems like they understood the problem. But I do doubt that this
>>> is a fixed size moemory leak.
>> 
>> I think the point they are trying to make is that it is only the
>> first instance of the web application to be unloaded that will be
>> pinned in memory. Subsequent reloads won't trigger a leak. That is
>> correct.
> 
> That is little solace to folks who have more Class objects than just
> about anything else. With a huge number of support libraries being
> used to operate a fairly lean transaction-processing system, a single
> reload could bust the heap and/or PermGen.
> 
> Just because it's a fixed-size memory leak doesn't mean it isn't worth
> fixing. :(


Agreed.

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

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

On May 20, 2013, at 4:39 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 5/20/13 4:10 PM, Nick Williams wrote:
>> 
>> On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> Nick,
>>> 
>>> On 5/20/13 12:48 PM, Nick Williams wrote:
>>>> 
>>>> On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:
>>>> 
>>>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>>> 
>>>>> Nick,
>>>>> 
>>>>> On 5/19/13 11:25 AM, Nick Williams wrote:
>>>>>> Unfortunately, requiring users to call System.gc() before 
>>>>>> shutdown for logging to work properly is no better than 
>>>>>> requiring users to register a listener in a web
>>>>>> application for logging to work properly. Surely there's a
>>>>>> better way...
>>>>> 
>>>>> Do you initialize your logging system in a 
>>>>> ServletContextListener (or similar)? If so, then you should 
>>>>> destroy it at the same level.
>>>>> 
>>>>> If you aren't initializing your logging system in a 
>>>>> ServletContextListener... then how are you initializing it?
>>>>> 
>>>>> Long ago, I abandoned log4j's auto-initialization primarily 
>>>>> because it sometimes guesses wrong.
>>>> 
>>>> First, remember that this is Log4j 2, so things are obviously 
>>>> different.
>>> 
>>> It's different, but it's the same.
>>> 
>>>> Log4j initializes with the first call to
>>>> LogManager#getLogger(), whenever that occurs. In my case
>>>> loggers are static, so it happens when the classes are
>>>> initialized. In the specific case of the replication project
>>>> attached to the issue, it happens on the first request to the
>>>> only Servlet in the application.
>>> 
>>> Right. What I'm saying is that you should take full control over 
>>> the initialization (and destruction) of the logging system. Your
>>> ServletContextListeners should be invoked before your servlet 
>>> classes are loader.
>> 
>> And I'm saying you shouldn't /have/ to. It should "just work"
>> without you having to do much thinking. See below.
>> 
>>> 
>>>> Unfortunately, I've just about given up on it being possible to
>>>> make logging work "right" without a ServletContextListener.
>>>> Man oh man did I want to avoid that...
>>> 
>>> You act like a ServletContextListener is some evil hack that
>>> should be avoided at all costs. Instead, it's exactly the right
>>> mechanism to do what you are trying to do: configure something at
>>> webapp launch and de-configure it when the webapp is stopped.
>> 
>> Not what I'm saying at all. I love listeners. They are extremely 
>> helpful, and I use them all the time.
>> 
>> What I'm saying is that the concept of logging, philosophically,
>> is supposed to be as unobtrusive as possible. Something you don't
>> really have to think about how exactly it works; you just know to
>> get a logger and put logging statements in your code and things
>> "just work." The act of having to set up a listener to initialize
>> and deinitialize logging, to me, seems like more than Log4j users
>> should have to worry about. Perhaps just as importantly, Log4j 1
>> worked without a listener to initialize/deinitialize, so this is
>> yet again one more thing users are going to have to do to switch
>> from Log4j 1 to Log4j 2.
> 
> That's like saying that aspect-oriented programming should "just work"
> without having to run the AOP compiler against the code, first.
> 
> This at least used to be a problem in log4j 1 as well: you had to call
> LogManager.shutdown in order to free all the resources, flush all the
> buffers, etc. when your webapp unloaded, otherwise you ran the risk of
> pinning the old webapp's ClassLoader, etc. in memory. The only way to
> run LogManager.shutdown() on webapp unload is to configure a
> ServletContextListener.
> 
>> Thankfully, we can use web-fragments in Servlet 3.0 and higher to 
>> configure the listener behind-the-scenes without the user even 
>> knowing. That's much more acceptable in my book.
> 
&g

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 5/20/13 12:48 PM, Nick Williams wrote:
>> 
>> On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:
>> 
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> Nick,
>>> 
>>> On 5/19/13 11:25 AM, Nick Williams wrote:
>>>> Unfortunately, requiring users to call System.gc() before 
>>>> shutdown for logging to work properly is no better than
>>>> requiring users to register a listener in a web application for
>>>> logging to work properly. Surely there's a better way...
>>> 
>>> Do you initialize your logging system in a
>>> ServletContextListener (or similar)? If so, then you should
>>> destroy it at the same level.
>>> 
>>> If you aren't initializing your logging system in a 
>>> ServletContextListener... then how are you initializing it?
>>> 
>>> Long ago, I abandoned log4j's auto-initialization primarily
>>> because it sometimes guesses wrong.
>> 
>> First, remember that this is Log4j 2, so things are obviously 
>> different.
> 
> It's different, but it's the same.
> 
>> Log4j initializes with the first call to LogManager#getLogger(), 
>> whenever that occurs. In my case loggers are static, so it happens
>> when the classes are initialized. In the specific case of the 
>> replication project attached to the issue, it happens on the first
>> request to the only Servlet in the application.
> 
> Right. What I'm saying is that you should take full control over the
> initialization (and destruction) of the logging system. Your
> ServletContextListeners should be invoked before your servlet classes
> are loader.

And I'm saying you shouldn't /have/ to. It should "just work" without you 
having to do much thinking. See below.

> 
>> Unfortunately, I've just about given up on it being possible to
>> make logging work "right" without a ServletContextListener. Man oh
>> man did I want to avoid that...
> 
> You act like a ServletContextListener is some evil hack that should be
> avoided at all costs. Instead, it's exactly the right mechanism to do
> what you are trying to do: configure something at webapp launch and
> de-configure it when the webapp is stopped.

Not what I'm saying at all. I love listeners. They are extremely helpful, and I 
use them all the time.

What I'm saying is that the concept of logging, philosophically, is supposed to 
be as unobtrusive as possible. Something you don't really have to think about 
how exactly it works; you just know to get a logger and put logging statements 
in your code and things "just work." The act of having to set up a listener to 
initialize and deinitialize logging, to me, seems like more than Log4j users 
should have to worry about. Perhaps just as importantly, Log4j 1 worked without 
a listener to initialize/deinitialize, so this is yet again one more thing 
users are going to have to do to switch from Log4j 1 to Log4j 2.

Thankfully, we can use web-fragments in Servlet 3.0 and higher to configure the 
listener behind-the-scenes without the user even knowing. That's much more 
acceptable in my book. Users of Servlet 2.5 will still have to declare them 
manually, but I think they will probably be the minority users. So with a 
little more polishing of the Log4j 2 source code we can make this a little 
better. I just wish there was a solution that would work for both standalone 
applications /and/ web applications to initialize and deinitialize Log4j 
correctly without any users (including Servlet 2.5 users) having to think about 
it.

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

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 5/19/13 11:25 AM, Nick Williams wrote:
>> Unfortunately, requiring users to call System.gc() before shutdown
>> for logging to work properly is no better than requiring users to
>> register a listener in a web application for logging to work
>> properly. Surely there's a better way...
> 
> Do you initialize your logging system in a ServletContextListener (or
> similar)? If so, then you should destroy it at the same level.
> 
> If you aren't initializing your logging system in a
> ServletContextListener... then how are you initializing it?
> 
> Long ago, I abandoned log4j's auto-initialization primarily because it
> sometimes guesses wrong.

First, remember that this is Log4j 2, so things are obviously different.

Log4j initializes with the first call to LogManager#getLogger(), whenever that 
occurs. In my case loggers are static, so it happens when the classes are 
initialized. In the specific case of the replication project attached to the 
issue, it happens on the first request to the only Servlet in the application.

Unfortunately, I've just about given up on it being possible to make logging 
work "right" without a ServletContextListener. Man oh man did I want to avoid 
that...

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

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

On May 19, 2013, at 10:01 AM, Caldarale, Charles R wrote:

>> From: Nick Williams [mailto:nicho...@nicholaswilliams.net] 
>> Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown 
>> (memory leak, it looks like)
> 
>> Log4j 1 never required a listener to be configured to be shut down 
>> properly when an application is undeployed.
> 
> What bearing does that have on a different logging mechanism?

To be fair, Log4j 2 is not a different logging mechanism. It is a new version 
of Log4j 1. My point was mostly philosophical; it "feels wrong" to have to 
configure a listener just to support logging.

> 
>> It should be possible to do this without a listener.
> 
> Not easily.
> 
>> Could a `finalize` method be used instead of a shutdown hook/listener?
> 
> Finalizers should be avoided like the plague.  The gyrations the JVM has to 
> go through to handle them result in continual run time impacts, and require 
> at least two GC passes to actually get rid of the objects.

The extra performance impact is bad, yes, when you're talking about an object 
who has many short-lived instances in memory that could be garbage collected 
regularly. However, when you're talking about a lone singleton instance that is 
created when the application starts and garbage collected when the application 
shuts down, I would argue this is not a problem at all. Of course, I'm open to 
the idea that I could be proven wrong.

> 
>> What I don't know is if it is guaranteed to be called in non-web 
>> applications 
>> when the JVM just shuts down.
> 
> Finalizers are not called at JVM termination, since the process exit is 
> expected to release resources automatically.  You cannot actually count on a 
> finalizer ever being invoked; it's one of those "seemed like a good idea at 
> the time" things that is now widely regretted by JVM implementers.

After some experimentation, it would appear that it's not so much that 
finalizers are not called at JVM termination as it is that finalizers are not 
called if the garbage collector never runs, and the garbage collector isn't 
guaranteed to run at JVM shutdown. However, if you call System.gc() right 
before the JVM shuts down, finalizers appear to run every time. Unfortunately, 
requiring users to call System.gc() before shutdown for logging to work 
properly is no better than requiring users to register a listener in a web 
application for logging to work properly. Surely there's a better way...

While I do not disagree that finalizers are very often misused, they are not 
without their uses. I find it hard to believe that the Sun JRE 6 source code 
would contain 50 uses of finalizers if they should never be used. You'd think 
if they regretted creating the method so much they would deprecate it and/or 
document clearly that it's best to never implement a finalizer, but the 
documentation for finalizers makes no such assertion, even in the latest Java 8.

> 
> - Chuck
> 
> 
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
> MATERIAL and is thus for use only by the intended recipient. If you received 
> this in error, please contact the sender and delete the e-mail and its 
> attachments from all computers.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

On May 19, 2013, at 3:33 AM, Mark Thomas wrote:

> On 19/05/2013 05:57, Nick Williams wrote:
>> Can one of the very knowledgeable developers that have been
>> discussing memory leaks in the last few days (re: Possible
>> false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC
>> Pool and OracleTimeoutPollingThread) chime in on this Log4j 2 bug
>> [1]?
>> 
>> Log4j 2 appears to be registering a shutdown hook that, I believe,
>> will result in a memory leak in Tomcat. The
>> JreMemoryLeakPreventionListener does not detect it (which might be a
>> separate Tomcat bug, assuming I'm right that it's a memory leak). I
>> don't know nearly as much about class loaders and memory leaks in a
>> web application as some of the guys I've read talking on here the
>> last few days, and it would be helpful for us to get the
>> knowledgeable opinion of one or more Tomcat developers about how to
>> solve this.
> 
> It looks like Ralph has already answered this [2].
> 
> If log4j2 is initialised by the webapp, it needs to be shutdown by the
> webapp.

Ralph may have responded, but I don't believe it's the right answer. Log4j 1 
never required a listener to be configured to be shut down properly when an 
application is undeployed. It should be possible to do this without a listener. 
Just a thought, is there a way to detect if a ClassLoader is being shut 
down/unloaded? Could a `finalize` method be used instead of a shutdown 
hook/listener? I'm fairly confident the finalize method would always be called 
when the application is undeployed (though I could be wrong). What I don't know 
is if it is guaranteed to be called in non-web applications when the JVM just 
shuts down.

> 
>> (Note: I don't normally post to both lists, but since the memory leak
>> topic was occurring on the user's list, and I also wanted to get the
>> attention of as many developers as possible, I made an exception this
>> time.)
> 
> No matter how important you think your issue is, please do not cross
> post. As a general guide, if you aren't sure, use the users list. The
> committers are all active or lurking here so they will all see it and
> will move the discussion to the dev list of necessary.

My apologies.


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

LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

Can one of the very knowledgeable developers that have been discussing memory 
leaks in the last few days (re: Possible false-postive with 
JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and 
OracleTimeoutPollingThread) chime in on this Log4j 2 bug [1]?

Log4j 2 appears to be registering a shutdown hook that, I believe, will result 
in a memory leak in Tomcat. The JreMemoryLeakPreventionListener does not detect 
it (which might be a separate Tomcat bug, assuming I'm right that it's a memory 
leak). I don't know nearly as much about class loaders and memory leaks in a 
web application as some of the guys I've read talking on here the last few 
days, and it would be helpful for us to get the knowledgeable opinion of one or 
more Tomcat developers about how to solve this.

Thanks,

Nick

[1] https://issues.apache.org/jira/browse/LOG4J2-223

(Note: I don't normally post to both lists, but since the memory leak topic was 
occurring on the user's list, and I also wanted to get the attention of as many 
developers as possible, I made an exception this time.)

Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport

[Nick Williams]

On May 8, 2013, at 12:40 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 5/8/13 1:34 PM, Nick Williams wrote:
>> 
>> On May 8, 2013, at 12:08 PM, Michael-O wrote:
>> 
>>> Am 2013-05-08 14:38, schrieb Christopher Schultz:
>>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>> 
>>>> Nick,
>>>> 
>>>> On 5/8/13 8:08 AM, Nick Williams wrote:
>>>>> 
>>>>> On May 8, 2013, at 6:54 AM, Christopher Schultz wrote:
>>>>> 
>>>>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>>>> 
>>>>>> Michael,
>>>>>> 
>>>>>> On 5/8/13 3:01 AM, Michael-O wrote:
>>>>>>> I recently have started using the SlowQueryReport to
>>>>>>> tackle performance issues. The log message,
>>>>>>> unfortunately, does not contain the parameters passed to
>>>>>>> the prepared statements. Though AbstractQueryReport
>>>>>>> receives this information in
>>>>>>> 
>>>>>>> protected String report*Query(String query, Object[]
>>>>>>> args, final String name, long start, long delta)
>>>>>>> 
>>>>>>> but ignores this information. The report would highly
>>>>>>> benefit from. E.g., Commons DBUtils prints out the query
>>>>>>> and the parameters in the case of an exception. The sole
>>>>>>> query isn't really helpful.
>>>>>>> 
>>>>>>> Can we add this?
>>>>>> 
>>>>>> Sure.
>>>>>> 
>>>>>>> Should I file a ticket?
>>>>>> 
>>>>>> Yes. A BZ issue with a patch is likely to get done a whole
>>>>>> lot faster than one without a patch (plus you get credit
>>>>>> for your contribution).
>>>>>> 
>>>>>> - -chris
>>>>> 
>>>>> There needs to be an option to disable logging query
>>>>> parameters somehow. Query parameters are sometimes sensitive,
>>>>> and in some environments (medical, legal, etc.) logging them
>>>>> might even be in violation of the law.
>>>> 
>>>> +1
>>>> 
>>>> If you really want to get cute, allow the user to specify named
>>>> query parameters that should never be displayed "e.g.
>>>> 'password'", though this is a) perhaps not possible and b) not
>>>> reliable because you can bind parameters by position as well as
>>>> by name.
>>> 
>>> Java has no support for named parameters. How is that supposed to
>>> work?
>> 
>> Agreed that it the setting won't be effective if they don't use
>> prepared statements. Therefore, the setting name should reflect
>> this restriction.
>> 
>> I'm not sure what Chris is referring to. You are right, Java has no
>> support for named parameters, even in Java 8. Chris might be
>> thinking of Hibernate or Spring's JdbcTemplate, which permit using
>> named parameters. Ultimately, these get converted to indexed
>> parameters before the query is actually executed.
> 
> I'm talking about java.sql.ResultSet.updateFoo(String columnName, Foo
> fooData)
> 
> Or are all your queries SELECTs?

Interesting. My (possible incorrect) understanding of ResultSet.updateFoo is 
that it does not execute a SQL statement. The database server has the cursored 
log held in memory and a direct binary message is sent back to update that 
column on that record. Therefore, there is no SQL statement to be logged by the 
SlowQueryReport.

My (again, possibly incorrect) understanding of the SlowQueryReport is that it 
only applies to Statements, PreparedStatements, and CallableStatements. These 
only have indexed parameters.

smime.p7s
Description: S/MIME cryptographic signature

Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport

[Nick Williams]

On May 8, 2013, at 12:08 PM, Michael-O wrote:

> Am 2013-05-08 14:38, schrieb Christopher Schultz:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Nick,
>> 
>> On 5/8/13 8:08 AM, Nick Williams wrote:
>>> 
>>> On May 8, 2013, at 6:54 AM, Christopher Schultz wrote:
>>> 
>>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>> 
>>>> Michael,
>>>> 
>>>> On 5/8/13 3:01 AM, Michael-O wrote:
>>>>> I recently have started using the SlowQueryReport to tackle
>>>>> performance issues. The log message, unfortunately, does not
>>>>> contain the parameters passed to the prepared statements.
>>>>> Though AbstractQueryReport receives this information in
>>>>> 
>>>>> protected String report*Query(String query, Object[] args,
>>>>> final String name, long start, long delta)
>>>>> 
>>>>> but ignores this information. The report would highly benefit
>>>>> from. E.g., Commons DBUtils prints out the query and the
>>>>> parameters in the case of an exception. The sole query isn't
>>>>> really helpful.
>>>>> 
>>>>> Can we add this?
>>>> 
>>>> Sure.
>>>> 
>>>>> Should I file a ticket?
>>>> 
>>>> Yes. A BZ issue with a patch is likely to get done a whole lot
>>>> faster than one without a patch (plus you get credit for your
>>>> contribution).
>>>> 
>>>> - -chris
>>> 
>>> There needs to be an option to disable logging query parameters
>>> somehow. Query parameters are sometimes sensitive, and in some
>>> environments (medical, legal, etc.) logging them might even be in
>>> violation of the law.
>> 
>> +1
>> 
>> If you really want to get cute, allow the user to specify named query
>> parameters that should never be displayed "e.g. 'password'", though
>> this is a) perhaps not possible and b) not reliable because you can
>> bind parameters by position as well as by name.
> 
> Java has no support for named parameters. How is that supposed to work?

Agreed that it the setting won't be effective if they don't use prepared 
statements. Therefore, the setting name should reflect this restriction.

I'm not sure what Chris is referring to. You are right, Java has no support for 
named parameters, even in Java 8. Chris might be thinking of Hibernate or 
Spring's JdbcTemplate, which permit using named parameters. Ultimately, these 
get converted to indexed parameters before the query is actually executed.

Nick

smime.p7s
Description: S/MIME cryptographic signature

Re: Print parameters in Tomcat JDBC Pool's SlowQueryReport

[Nick Williams]

On May 8, 2013, at 6:54 AM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Michael,
> 
> On 5/8/13 3:01 AM, Michael-O wrote:
>> I recently have started using the SlowQueryReport to tackle 
>> performance issues. The log message, unfortunately, does not
>> contain the parameters passed to the prepared statements. Though 
>> AbstractQueryReport receives this information in
>> 
>> protected String report*Query(String query, Object[] args, final 
>> String name, long start, long delta)
>> 
>> but ignores this information. The report would highly benefit
>> from. E.g., Commons DBUtils prints out the query and the parameters
>> in the case of an exception. The sole query isn't really helpful.
>> 
>> Can we add this?
> 
> Sure.
> 
>> Should I file a ticket?
> 
> Yes. A BZ issue with a patch is likely to get done a whole lot faster
> than one without a patch (plus you get credit for your contribution).
> 
> - -chris

There needs to be an option to disable logging query parameters somehow. Query 
parameters are sometimes sensitive, and in some environments (medical, legal, 
etc.) logging them might even be in violation of the law.

Nick

smime.p7s
Description: S/MIME cryptographic signature

Re: Java 7 support on Tomcat 5.5

[Nick Williams]

On Apr 1, 2013, at 3:44 PM, Satheesh Babu wrote:

> Good Evening!
> 
> We're running our production applications in Tomcat 5.5/JRE 1.5, and there is 
> a need for us to migrate our applications to Java 7(JRE 1.7). There is no 
> information available either on java or on Apace Tomcat site regrading the 
> compatibility of java 7 with tomcat 5.5. Could you please let me know the 
> compatibility of Java 7/Tomcat 5.5 (or) do we need to upgrade tomcat to 6 
> (or) 7, for java 7.
> 
> I truly appreciate your response, thanks for your timely help.
> 
> Thanks,
> Satheesh Babu


First, this is the wrong list for such a question. This question belongs on the 
User's list. I am cross-posting on both lists this one time to inform you of 
this and to relocate the topic.

Second, good to hear that your organization is making the jump to Java 7. Java 
6 is no longer supported and Java 8 will be out soon.

Third, upgrade Tomcat. Tomcat 5.5 is extremely old and no longer supported. 
That's why you won't even find it on the Tomcat site proper [1] anymore, you 
can only find it in the archives. You will likely not find anyone on these 
lists willing to help you much with 5.5.

Finally, Tomcat 6 and 7 will both run quite fine on Java 7, but they will not 
compile on Java 7. If you want a version of Tomcat that compiles on Java 7, you 
will need to wait for Tomcat 8, which is currently in development and should 
(hopefully) be out later this year.

[1] http://tomcat.apache.org/
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Adding Content-Length response header

[Nick Williams]

On Mar 26, 2013, at 3:15 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Konstantin,
> 
> On 3/26/13 11:08 AM, Konstantin Kolinko wrote:
>> 2013/3/26 Christopher Schultz :
>>> 
>>> Like most folks on the list, I have quite a few dynamic
>>> resources being served through Tomcat. For nearly all of them,
>>> the Content-Length response header is /not/ included in the
>>> response because either content length isn't known when the
>>> response is committed, and therefore the Content-Length header
>>> simply cannot be sent or the response is not being buffered in
>>> the application, and so the application isn't counting bytes and
>>> doesn't know the content length even if it could be reported.
>>> 
>>> I'm wondering if Tomcat can do anything about that.
>>> 
>>> Here's the situation I have: I've got a response that I'm fairly
>>> sure fits into the response's buffer size, and I'd like to send
>>> a Content-Length header in that case. I could probably put a
>>> wrapper around the response's ServletOutputStream that counts
>>> bytes and then looks for "done" conditions (OutputStream.close,
>>> etc.), then adds a Content-Length header if the response hasn't
>>> yet been committed.
>>> 
>>> I wonder if Tomcat could do something like that more easily --
>>> since the buffer is being managed by Tomcat already, and Tomcat
>>> knows when the response will be committed/completed.
>>> 
>>> So,
>>> 
>>> A: Is this something that Tomcat can do already? I don't see any 
>>> configuration options that sound like they would do this kind of
>>> thing.
>>> 
>>> B: Is this something appropriate for a container to do in
>>> general?
>>> 
>>> C: If I were to write a Filter to accomplish this manually, are
>>> there any potential dangers if a traditional non-synchronous 
>>> request/response is being processed?
>> 
>> 1. Your Tomcat version = ?
> 
> Duh. I'm running both Tomcat 6.0.36 and Tomcat 7.0.35.
> 
>> 2. Are you interested in GET/POST requests, or HEAD requests?
>> 
>> HEAD requests were fixed by this commit, from 5 days ago 
>> http://svn.apache.org/r1459087
> 
> Mostly POST requests. I'll take a look at the commit to see what was
> changed and see if it might be relevant.

FYI, that commit 5 days ago was just when it was merged to 7.x. The issue was 
actually fixed nearly a year ago in trunk. I just pointed out last week that it 
should be merged to 7.

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

> 
>> 3. Tomcat is already able to provide Content-Length header when
>> all response fits into a buffer.
>> 
>> But, if an explicit flush() is called, Tomcat has to start sending 
>> data (usually using chunked encoding) and thus content length  is
>> not known at the time when response headers are being sent.
> 
> Hmm... I might be flushing the buffer explicitly. That's probably a
> stupid idea because Tomcat should ultimately flush everything for me.
> I'll check on that.
> 
>> What generates your response? A servlet, a filter, or a JSP?
> 
> All servlets in these cases. I'll follow-up with better answers to the
> above.
> 
> Thanks,
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBCAAGBQJRUgHzAAoJEBzwKT+lPKRYjp8QAJmDS7eebC0S8tM+yG0C+PTy
> tyczL2vaxu1bwLlt5LDwFwQ9q6S7NtPvGQiRIGqg3VDWz9H2q3UVDRR3v/zhyxdE
> ZPutdXWRPPmU26ZyEF4W3ttyxGmtm+y4zpAkUfLW/h0Zl9gVDV6TqwYX9GsylEyV
> /RrAN4AHKh2uBJc6SnV61wU5a+7LrBTy9Tlxi0om7UGf8sGoXTGDtmEpYYUfJDQu
> +cUN3OTaOStdBXR+gLQ17NSlY+/nTZVoMMIfrJHTVBjAWpAQQwAXCZMaCfmdbaYS
> EkNk8cehmnHyhYhy6JckbpC1qaugDwVERaOl86LcuSsKFzPAdFaoHS+XF6Qp2GDk
> gtiw6wpTiM6DF6f2BP6ZXJLcddmtZMhtygGsKLXyxmR9hguOKVioVPIi5GDnifZR
> 0PtTjmY1dis/Xcfe/WKIKJER8jRtiBpzLHOLpomFh95hL1y7dnfRUYv9EzlrtV1k
> TdQurstjKsd7P7XWUsSpyyjXmluCWZQoCJbzVwEdMMmar6kfaAGqgCj4FAHV/JTH
> wNKRqd461q1hj/dKKJk65KbyKSFP2y4zpF/irtVvH4y0JyNAJWzmxdC8XJHu3EAp
> Q9UsvPuZNtICR3twPoFzicJm1wXLV00TCg7XYiXExNZarDnzA6GAtOVMx5Oxmuaq
> osWzVzmulIbdy9enhTZR
> =AVzf
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Tomcat 8 + Tomcat Maven Plugin 2.2 + Tomcat8 Maven Plugin?

[Nick Williams]

On Mar 24, 2013, at 4:55 AM, Olivier Lamy wrote:

> Hi,
> Apologize for delayed response.
> I have not tested that. I don't know if embedder trunk (i.e tomcat8)
> is compatible.
> Did you try using tomcat8 snapshot as described here:
> http://tomcat.apache.org/maven-plugin-trunk/tomcat7-maven-plugin/adjust-embedded-tomcat-version.html

I had not seen that. Thanks!

However, after some time I determined that I needed enough customization 
(Tomcat 8, Web Start class loader requirements, logging, etc.) that the maven 
plugin just wasn't going to cut it. I got it working nicely using the 
tomcat-embed-*, as per "Re: Executable Tomcat JAR/WAR executes fine standalone, 
class loading errors in JNLP" [1] and bug 54745.

Thanks,

Nick

[1] http://tomcat.markmail.org/thread/6qzrm3akiy4e3e5v

> 
> 
> 2013/3/14 Nick Williams :
>> https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/maven/
>> 
>> In snapshots there is only tomcat6-maven-plugin and tomcat7-maven-plugin. 
>> So, even though my Maven dependencies are on Tomcat 8.0-SNAPSHOT, any 
>> "executable war" I build with the plugin has Tomcat 7 classes in it, meaning 
>> the application won't run (NoClassDefFound, etc.).
>> 
>> What needs to be done to get a tomcat8-maven-plugin snapshot started? Is 
>> this a whole new project that hasn't been started yet? Or does a new build 
>> configuration just need to be created?
> 
> 
> 
> -- 
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
> 
> -
> 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: Executable Tomcat JAR/WAR executes fine standalone, classloading errors in JNLP

[Nick Williams]

On Mar 21, 2013, at 4:31 PM, Nick Williams wrote:

> I have built an executable Tomcat JAR file. It has all of the Tomcat classes 
> and dependencies zipped into one big JAR. Inside that JAR is also a WAR file, 
> the native DLL, and logging.properties. My com.ul.io.Bootstrap class creates 
> an .extract directory in the CWD, extracts the native DLL, WAR file and 
> logging.properties, configures Tomcat logging, configures a Tomcat class 
> instance, adds the WAR file is a web app, starts the Tomcat class instance, 
> and waits for it.
> 
> If I run this JAR like this:
> 
>> java -jar PeripheralProxy-1.0.0.SNAPSHOT.jar
> 
> Everything works fine. It starts up, I can go to the application, no errors 
> in the logs ... everything is perfect. The output from stdout is below if 
> you're interested. Now, I take the same JAR file and sign it with the jar 
> signer. To make sure nothing got messed up, I run the signed JAR file:
> 
>> java -jar PeripheralProxy-1.0.0.SNAPSHOT-signed.jar
> 
> This worked to. Exact same stdout output, application works fine. Perfect! 
> Next I created a JNLP file with, among other things,  set to 
> . I open the JNLP file in my browser. It accepts the 
> certificate and starts the JAR file. First problem is logging doesn't work. 
> Not sure why. I had to enable the Java console in Java Control Panel to see 
> what was going on.
> 
> 1) It created the .extract directory, so the first step worked.
> 2) It extracted the WAR file, native DLL and logging.properties without a 
> problem, so that worked, too.
> 3) It could not deploy the application. At this point it began getting class 
> loading errors.
> 
> The output from the Java console is also below. Anyone have a clue what went 
> wrong? Obviously the classes ARE in the JAR file, otherwise it wouldn't work 
> from the command line.
> 
> 

Well, I got this working. I'm not sure anyone has ever successfully done this 
before, because I didn't really find much of anything on Google that helped. 
Here's what I had to do:

1) Sign the JAR and use . This was a given and I was already 
doing this.

2) Use tomcat-embed-logging-log4j instead of tomcat-embed-logging-juli. The Web 
Start deployer is NOT friendly to the way JULI deals with class loaders.

3) Don't put ANY classes in the WAR files included in the JAR file. ALL classes 
(Tomcat AND application AND dependency classes) must go in the 
root/embedded/same JAR. Otherwise the security manager detects that they were 
loaded differently and doesn't apply the  rule to them. 
There IS an alternative to this: System.setSecurityManager(null). But that's 
not pretty, and discouraged.

4) After instantiating the Tomcat instance and before starting it, set the 
parent class loaders to the current thread context class loader. Otherwise 
Tomcat tries to use the System class loader. You cannot use the System class 
loader in Java Web Start. None of the application classes are loaded by it.

Tomcat tomcat = new Tomcat();
ClassLoader loader = Thread.currentThread().getContextClassLoader();
tomcat.getEngine().setParentClassLoader(loader);
tomcat.getHost().setParentClassLoader(loader);
tomcat.getServer().setParentClassLoader(loader);
tomcat.getService().setParentClassLoader(loader);

5) Patch JarScanner. The JarScanner only scans JARs at URLs starting with file: 
and jndi:. It ignores http: and https: URLs, and in Web Start, all JAR URLs 
start with http: or https:. I filed bug 54745 about this, because it's a 
noninvasive patch that I think improves Tomcat.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Executable Tomcat JAR/WAR executes fine standalone, classloading errors in JNLP

[Nick Williams]

I have built an executable Tomcat JAR file. It has all of the Tomcat classes 
and dependencies zipped into one big JAR. Inside that JAR is also a WAR file, 
the native DLL, and logging.properties. My com.ul.io.Bootstrap class creates an 
.extract directory in the CWD, extracts the native DLL, WAR file and 
logging.properties, configures Tomcat logging, configures a Tomcat class 
instance, adds the WAR file is a web app, starts the Tomcat class instance, and 
waits for it.

If I run this JAR like this:

>java -jar PeripheralProxy-1.0.0.SNAPSHOT.jar

Everything works fine. It starts up, I can go to the application, no errors in 
the logs ... everything is perfect. The output from stdout is below if you're 
interested. Now, I take the same JAR file and sign it with the jar signer. To 
make sure nothing got messed up, I run the signed JAR file:

>java -jar PeripheralProxy-1.0.0.SNAPSHOT-signed.jar

This worked to. Exact same stdout output, application works fine. Perfect! Next 
I created a JNLP file with, among other things,  set to 
. I open the JNLP file in my browser. It accepts the 
certificate and starts the JAR file. First problem is logging doesn't work. Not 
sure why. I had to enable the Java console in Java Control Panel to see what 
was going on.

1) It created the .extract directory, so the first step worked.
2) It extracted the WAR file, native DLL and logging.properties without a 
problem, so that worked, too.
3) It could not deploy the application. At this point it began getting class 
loading errors.

The output from the Java console is also below. Anyone have a clue what went 
wrong? Obviously the classes ARE in the JAR file, otherwise it wouldn't work 
from the command line.

STDOUT CONTENTS: Successful run from command line
--
C:\Users\Nicholas\Desktop\PeripheralProxy\TomcatRunner\target>java -jar 
PeripheralProxy-1.0.0.SNAPSHOT.jar
jar:file:/C:/Users/Nicholas/Desktop/PeripheralProxy/TomcatRunner/target/PeripheralProxy-1.0.0.SNAPSHOT.jar!/PeripheralProxy.war
Mar 21, 2013 4:22:36 PM org.apache.catalina.core.AprLifecycleListener init
INFO: Loaded APR based Apache Tomcat Native library 1.1.27 using APR version 
1.4.6.
Mar 21, 2013 4:22:36 PM org.apache.catalina.core.AprLifecycleListener init
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], 
random [true].
Mar 21, 2013 4:22:36 PM org.apache.catalina.core.AprLifecycleListener 
initializeSSL
INFO: OpenSSL successfully initialized (OpenSSL 1.0.1d 5 Feb 2013)
Mar 21, 2013 4:22:37 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-apr-8973"]
Mar 21, 2013 4:22:37 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Tomcat
Mar 21, 2013 4:22:37 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/8.0.0-dev
Mar 21, 2013 4:22:37 PM org.apache.catalina.startup.ContextConfig 
getDefaultWebXmlFragment
INFO: No global web.xml found
Mar 21, 2013 4:22:38 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-apr-8973"]

CONSOLE CONTENTS: Failed run from JNLP
--
Java Web Start 11.0.2.79
Using JRE version 1.8.0-ea-b79 Java HotSpot(TM) 64-Bit Server VM
User home directory = C:\Users\Nicholas

c:   clear console window
f:   finalize objects on finalization queue
g:   garbage collect
h:   display this help message
m:   print memory usage
o:   trigger logging
p:   reload proxy configuration
q:   hide console
r:   reload policy configuration
s:   dump system and deployment properties
t:   dump thread list
v:   dump thread stack
0-5: set trace level to 

Match: beginTraversal
Match: digest selected JREDesc: JREDesc[version 1.8+, heap=-1--1, args=null, 
href=http://java.sun.com/products/autodl/j2se, sel=false, null, null], JREInfo: 
JREInfo for index 0:
platform is: 1.8
product is: 1.8.0-ea
location is: http://java.sun.com/products/autodl/j2se
path is: C:\Program Files\Java\jre8\bin\javaw.exe
args is: 
native platform is: Windows, amd64 [ x86_64, 64bit ]
JavaFX runtime is: JavaFX 8.0.0 found at C:\Program Files\Java\jre8\
enabled is: true
registered is: true
system is: true

Match: ignoring maxHeap: -1
Match: ignoring InitHeap: -1
Match: digesting vmargs: null
Match: digested vmargs: [JVMParameters: isSecure: true, args: ]
Match: JVM args after accumulation: [JVMParameters: isSecure: true, 
args: ]
Match: digest LaunchDesc: http://ohmqa.purehq.com/peripheral-proxy.jnlp
Match: digest properties: []
Match: JVM args: [JVMParameters: isSecure: true, args: ]
Match: endTraversal ..
Match: JVM args final: 
Match: Running JREInfo Versionmatch: 1.8.0.ea == 1.8.0.ea
 Match: R

Re: Tomcat Behavior on Multiple HTTP requests from same browser

[Nick Williams]

On Mar 19, 2013, at 8:49 PM, Saurabh Agrawal wrote:

> Hi Nick,
> 
> We currently have 8 tomcat nodes with each node configured to have 1000 
> maxThreads. We did a round of performance test for 8000 concurrent users and 
> the observation was that the number of active executor threads were far less.
> 
> My understanding was if 8000 concurrent users hit the site at the same time, 
> 8000 executor threads are required to suffice the requirement of all the 
> requests. However, I see far less executor threads in action when we put a 
> load of 8000 concurrent users.
> 

Yes, this is to be expected. Tomcat / the JVM will try to be as efficient as 
possible. A thread will only be in use during an active request. Just because 
you have 8,000 simultaneous users does not mean you have 8,000 simultaneous 
requests. Remember that "real" users will have some time between each request, 
ranging from a few seconds to several minutes depending on the page and the 
user. A good load testing tool like JMeter, The Grinder, or NeoLoad (just 
examples) will mimic this behavior by putting varying pauses between requests. 
It sounds like whatever tool you are using is doing this--that's good! So, 
8,000 simultaneous users might result in only 400-500 simultaneous requests 
(just a guess; depends on your application and its user base). In this case, 
you'd only see 400-500 threads used across the cluster.

In your small-scale test, where each request from your browser got the same 
thread, that could just be pure luck. If you're the only person using the 
server, it's likely that the Thread pool is extremely small, thus the odds are 
high that the same thread would get picked over and over again. However, in a 
high-load environment, this will not be the case, and the number of threads 
will nearly always be less than the number of simultaneous users.

I'm glad to see that you have a working cluster of some sorts and that you are 
performing load tests to evaluate its performance. This means you are on the 
right track, making some good decisions, and have obviously done a little 
reading. I suspect a little more reading of the Connector documentation will 
help you understand exactly how all of this works.

Nick

P.S. Please remember to bottom post. Don't top post.

> -Original Message-
> From: Nick Williams [mailto:nicho...@nicholaswilliams.net] 
> Sent: Wednesday, March 20, 2013 1:44 AM
> To: Tomcat Users List
> Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser
> 
> 
> On Mar 19, 2013, at 8:37 PM, Caldarale, Charles R wrote:
> 
>>> From: Saurabh Agrawal [mailto:sagra...@sapient.com] 
>>> Subject: Tomcat Behavior on Multiple HTTP requests from same browser
>> 
>>> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL, 
>>> tomcat will assign one of the worker threads (say Thread 1) from the pool
>>> to the HTTP request which will be processed and then response will be sent
>>> to the client. Now if I hit a link on homepage which is for login, a 
>>> separate
>>> HTTP request will be initiated from the same browser.
>> 
>>> What I want to understand is if the Tomcat will keep Thread 1 as persistent 
>>> thread to server the second request (for login) from the same browser or 
>>> will
>>> it assign a separate thread from the pool ?
>> 
>> Normally, the first available thread from the pool is used for each request. 
>>  However, if you are using the BIO  with keep-alives enable *and* 
>> the browser is using keep-alives, the same thread as long as the HTTP 
>> connection is active.
>> 
>> See the HTTP  doc, especially the Connector Comparison at the end.
>> 
>> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>> 
>> - Chuck
> 
> I think the most important thing to say here is that there is NO guarantee 
> that the browser will always keep the connection alive, therefore there is NO 
> guarantee that every request will get the same thread. You should never rely 
> on having access to the same thread from one request to the next. (That is 
> what HttpSessions are for.)
> 
> If you need to support 20,000 simultaneous users, you are going to need a 
> farm of servers. Just one server will not be enough. One simultaneous user 
> does not equal one thread needed: when a user is between requests, a thread 
> can be servicing some other request. You should read the Tomcat documentation 
> thoroughly, especial the sections on connection management, session 
> management and clustering.
> 
> Nick
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>

Re: Tomcat Behavior on Multiple HTTP requests from same browser

[Nick Williams]

On Mar 19, 2013, at 8:37 PM, Caldarale, Charles R wrote:

>> From: Saurabh Agrawal [mailto:sagra...@sapient.com] 
>> Subject: Tomcat Behavior on Multiple HTTP requests from same browser
> 
>> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL, 
>> tomcat will assign one of the worker threads (say Thread 1) from the pool
>> to the HTTP request which will be processed and then response will be sent
>> to the client. Now if I hit a link on homepage which is for login, a separate
>> HTTP request will be initiated from the same browser.
> 
>> What I want to understand is if the Tomcat will keep Thread 1 as persistent 
>> thread to server the second request (for login) from the same browser or will
>> it assign a separate thread from the pool ?
> 
> Normally, the first available thread from the pool is used for each request.  
> However, if you are using the BIO  with keep-alives enable *and* 
> the browser is using keep-alives, the same thread as long as the HTTP 
> connection is active.
> 
> See the HTTP  doc, especially the Connector Comparison at the end.
> 
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
> 
> - Chuck

I think the most important thing to say here is that there is NO guarantee that 
the browser will always keep the connection alive, therefore there is NO 
guarantee that every request will get the same thread. You should never rely on 
having access to the same thread from one request to the next. (That is what 
HttpSessions are for.)

If you need to support 20,000 simultaneous users, you are going to need a farm 
of servers. Just one server will not be enough. One simultaneous user does not 
equal one thread needed: when a user is between requests, a thread can be 
servicing some other request. You should read the Tomcat documentation 
thoroughly, especial the sections on connection management, session management 
and clustering.

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

Re: Getting HttpSession from HandshakeRequest/Configurator

[Nick Williams]

On Mar 17, 2013, at 5:56 PM, Nick Williams wrote:

> Based on my reading of the WebSocket spec mailing lists and API 
> documentation, if I want to get the HttpSession that exists when a WebSocket 
> connection is negotiated I need to extend ServerEndpointConfig.Configurator, 
> override #modifyHandshake(), and call #getHttpSession() on the 
> HandshakeRequest. However, I need a little clarification, because I'm not 
> seeing how this is going to work:
> 
> 1) Tomcat doesn't implement HandshakeRequest ... anywhere. So I'm not even 
> seeing how that method could ever be called with a non-null argument. 
> (Admittedly, I haven't run this yet ... I'm sending this preemptively while I 
> complete my code, to go ahead and get some feedback).
> 
> 2) None of the arguments to #modifyHandshake() provide access to the Session. 
> So how am I supposed to do anything with it? How can I associate the 
> HttpSession with the Session?

I answered my own questions:

1) That's because it didn't, and it wasn't ever calling modifyHandshake(). I 
created a bug and submitted a patch for this.

2) Apparently userProperties is the way to go. userProperties can be accessed 
from the EndpointConfig argument to #modifyHandshake() or from Session. I can 
store the HttpSession in there. Wish there were a less roundabout way of 
getting there...
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Getting HttpSession from HandshakeRequest/Configurator

[Nick Williams]

Martin,

Don't believe we've spoken before. Good to meet you.

I'm working on a book on Servlet 3.1 + WebSockets + Spring Framework 4 + 
Hibernate + Spring Security. My interest is purely the new Java WebSockets API. 
The existing Comet implementation in Tomcat 7.0 will be deprecated in 7.0 once 
the official API is complete and ported, and it will not be present in Tomcat 
8.0.

Thanks, though, for replying.

Nick

On Mar 17, 2013, at 7:18 PM, Martin Gainty wrote:

> Nick
> if you dont mind Comet's implementation of WebSocket events to Servlet-3.0 
> POST and GET then checkout 
> http://java.dzone.com/articles/tomcat-websockets-html5
> 
> I'll let you test drive to see if Ant 's WebSocketServlet fully supports all 
> aspects of the WebSocket spechttp://en.wikipedia.org/wiki/WebSocket
> 
> Keep us apprised,
> Happy Driving
> Martin __ Place Long-winded 
> disclaimer here
> 
>> From: nicho...@nicholaswilliams.net
>> Subject: Getting HttpSession from HandshakeRequest/Configurator
>> Date: Sun, 17 Mar 2013 17:56:23 -0500
>> To: users@tomcat.apache.org
>> 
>> Based on my reading of the WebSocket spec mailing lists and API 
>> documentation, if I want to get the HttpSession that exists when a WebSocket 
>> connection is negotiated I need to extend ServerEndpointConfig.Configurator, 
>> override #modifyHandshake(), and call #getHttpSession() on the 
>> HandshakeRequest. However, I need a little clarification, because I'm not 
>> seeing how this is going to work:
>> 
>> 1) Tomcat doesn't implement HandshakeRequest ... anywhere. So I'm not even 
>> seeing how that method could ever be called with a non-null argument. 
>> (Admittedly, I haven't run this yet ... I'm sending this preemptively while 
>> I complete my code, to go ahead and get some feedback).
>> 
>> 2) None of the arguments to #modifyHandshake() provide access to the 
>> Session. So how am I supposed to do anything with it? How can I associate 
>> the HttpSession with the Session?
>> -
>> 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

Getting HttpSession from HandshakeRequest/Configurator

[Nick Williams]

Based on my reading of the WebSocket spec mailing lists and API documentation, 
if I want to get the HttpSession that exists when a WebSocket connection is 
negotiated I need to extend ServerEndpointConfig.Configurator, override 
#modifyHandshake(), and call #getHttpSession() on the HandshakeRequest. 
However, I need a little clarification, because I'm not seeing how this is 
going to work:

1) Tomcat doesn't implement HandshakeRequest ... anywhere. So I'm not even 
seeing how that method could ever be called with a non-null argument. 
(Admittedly, I haven't run this yet ... I'm sending this preemptively while I 
complete my code, to go ahead and get some feedback).

2) None of the arguments to #modifyHandshake() provide access to the Session. 
So how am I supposed to do anything with it? How can I associate the 
HttpSession with the Session?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ThreadLocal variables and BIO/NIO/APR

[Nick Williams]

On Mar 15, 2013, at 4:05 PM, Mark Thomas wrote:

> On 15/03/2013 20:53, Nick Williams wrote:
>> If I understand this correctly (which I may not), BIO dedicates a
>> thread to a request from beginning to end and then recycles that
>> thread only when the request has completed (which is perfect), but
>> NIO and APR do not do that. More than one request may use a given
>> thread at (kind of) the same time. So my concern is that ThreadLocals
>> from one request could pollute ThreadLocals in another request. Is
>> this a concern, or are there reasons that won't happen?
> 
> Normally, all three connectors dedicate a thread to the processing of a
> request from beginning to end. You can safely use ThreadLocals in the
> manner you describe with any connector.
> 
> However, if you start to use Servlet 3.0 Async then you need to be a
> little more careful. Once you enter async mode ThreadLocals are almost
> certainly going to start causing problems. The same goes for Servlet 3.1
> non-blocking IO.
> 

Ahh. That makes sense. We are not currently using Async or non-blocking IO. We 
may at some point in the future. We will be sure to be careful with how we 
handle ThreadLocals at that point. Thanks!
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

ThreadLocal variables and BIO/NIO/APR

[Nick Williams]

I know, I know. "Don't use ThreadLocals." I've seen it on this list at least 
100 times. But avoiding ThreadLocal variables can be hard:

1) Spring Framework uses ThreadLocals for things like the RequestContext. You 
can't just turn that off.
2) Spring Security uses ThreadLocals for things like the security context. 
Can't turn that off, either.
3) Using ServletRequest#setAttribute()/getAttribute() or HttpSessions aren't 
always useable replacements for ThreadLocal variables. Doing this couples all 
aspects of your application to ServletRequests and/or HttpSessions. For 
example, in a multi-tenant environment, you need to establish some context that 
identifies which persistence location to use for obtaining and persisting data. 
Having to pass a request or session from servlet to service to repository is 
not ideal. Neither, for that matter, is having to have a "tenant" parameter (or 
any other type of identifying parameter) added to every single method in the 
entire application. And, when you're dealing with existing interfaces (Spring, 
Hibernate) that you have to implement, this isn't even an option sometimes.

So, with that in mind, the logical question is, how does one use ThreadLocals 
safely and reliably? The obvious first step is, "don't let them leak." That's 
easily solved. We have a filter that performs the setting of all of our 
ThreadLocals on the way in, and it also clears them on the way back out.  The 
ThreadLocalLeakPreventionListener helped us identify 1 or 2 situations where 
they were still leaking, and we fixed those, too. But, reading about the 
differences between BIO/NIO/APR, I'm concerned that may not be enough.

If I understand this correctly (which I may not), BIO dedicates a thread to a 
request from beginning to end and then recycles that thread only when the 
request has completed (which is perfect), but NIO and APR do not do that. More 
than one request may use a given thread at (kind of) the same time. So my 
concern is that ThreadLocals from one request could pollute ThreadLocals in 
another request. Is this a concern, or are there reasons that won't happen?

I don't really understand how any of this works, so some advice is greatly 
appreciated.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Embedded Tomcat JavaDoc Not Complete

[Nick Williams]

On Mar 15, 2013, at 3:15 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 3/15/13 3:56 PM, Nick Williams wrote:
>> I tried using a JAR URL. (If I remember correctly, it ended up 
>> looking something like 
>> jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war.
> 
> That
>> 
> doesn't look right.

That's what Class#getResource() returned.

> 
>> I tried it as both a directory and a WAR file. Tomcat did not like
>> it. It said "Could not deploy web application to [temporary webapps
>> directory location]" or something like that. I ended up, at
>> runtime, extracting the war file from the JAR file to a temporary
>> directory and deploying from there. That worked great, and it's how
>> the Tomcat Maven plugin executable war works, too.
> 
> Don't build your own URL. Instead, do this in your driver that calls
> Tomcat:
> 
> String docBase = getClass().getResource("/web);
> String ROOT = "";
> tomcat.addWebapp(ROOT, docBase);

I was using Class#getResource() just like this. However, Class#getResource() 
does not return a String. It returns a java.net.URL. I can't just pass that to 
addWebapp(), I had to toString() it. Just to be accurate, I ran it again and 
dumped the URL again (I was doing this before for debugging, but I had removed 
it). It's 
"jar:file:/C:/Users/Nicholas/Desktop/PeripheralProxy/TomcatRunner/target/Peripher
alProxy-1.0.0.SNAPSHOT.jar!/PeripheralProxy.war". So my memory was close, but 
not exact.

> 
> It's probably worth dumping-out the URL just to see what it looks
> like. Note that your CLASSPATH can affect what getResource() will
> return, so make sure you don't have too much classpath pollution.
> 
>>> I dunno anything about the Tomcat Maven plugin, but I think that
>>> an executable WAR file is exactly what you are trying to build.
>> 
>> It is. There are some issues (not bugs) with the Tomcat Maven
>> plugin executable war, the first one being that it's not very easy
>> to customize without using command-line arguments (makes it kind of
>> hard to "double-click" and run the executable war effectively).
>> Also, while there are snapshots for the Tomcat 8.0 embedded
>> artifacts, there is no Tomcat 8.0 version of the Tomcat Maven
>> plugin yet, so I literally can't use it. I ended up using a few
>> maven modules and the embedded Tomcat artifacts to create my own
>> executable WAR. Working great now.
> 
> Cool.
> 
>>>> This may be premature (getting it working is my priority), but
>>>> I should mention that performance is important to what I'm
>>>> doing here. I'd like to enable the native code. Some
>>>> applications and libraries include native DLLs/SOs/JNILIBs in
>>>> their JAR files, copy them to a temporary directory at runtime
>>>> and load them from the temporary location (to avoid having to
>>>> actually "install" the native libraries in the OS or JVM
>>>> directory structure). Is there a way to do this with an
>>>> embedded/executable Tomcat application so that the Tomcat
>>>> classes can take advantage of the native library?
>>> 
>>> I'm almost sure Java won't load a shared library out of a JAR
>>> file, so you'll have to use this same technique: extract some
>>> shared libraries out of your JAR file and throw them into
>>> java.io.tmpdir/pid/shared/* or whatever and then instruct the JVM
>>> to load them from there (or modify the java.library.path system
>>> property to point to that and let them load naturally).
>> 
>> Yea. I got that working. Embedded the DLLs in the JAR file and
>> then extracted at runtime. Learned a lot about how Tomcat loads the
>> native library and filed and created a patch for improvement
>> request #54700 as a result.
> 
> That bug report offers a silly suggestion: use a system property to
> configure where tcnative can be found because setting system
> properties at startup is inconvenient? I suppose that system property
> would be writable at runtime and so marginally more useful.

That was exactly the point. For my purposes, I have to sniff out the 
architecture at runtime (really not as hard as you suggest below, only took me 
about 10 minutes to write) and THEN determine which library to use. 
System#setProperty() makes it easy to then tell Tomcat where the library is. 
But you can't change the java.library.path at runtime with setProperty() (you 
can, it has just already been cached, so you have t

Re: Embedded Tomcat JavaDoc Not Complete

[Nick Williams]

On Mar 15, 2013, at 2:15 PM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Nick,
> 
> On 3/13/13 2:19 PM, Nicholas Williams wrote:
>> On Wed, Mar 13, 2013 at 12:10 PM, Christopher Schultz 
>>  wrote:
>>> You mean addWebapp methods? They seem fairly self-explanatory.
>> 
>> Yes. I meant addWebapp methods. That was a typo.
>> 
>> There are three of them. Only one is documented. Unfortunately,
>> the other two are not "self explanatory." I have no idea what the
>> "url," "path," and "name" parameters are (although "host" makes
>> sense). The documentation for the lone method that IS documented
>> only has "contextPath" and "baseDir" ... that doesn't line up with
>> the other two methods.
> 
> Yup, it's ugly.
> 
>>> Tomcat.addWebapp(String,String) says that the first argument is
>>> the context path. The context path for the ROOT webapp is "", not
>>> "/".
>> 
>> I didn't know this. I will change it. By the way, I got this code
>> from the tutorial at 
>> https://devcenter.heroku.com/articles/create-a-java-web-application-using-embedded-tomcat.
> 
> They
>> 
> should probably update their HOWTO: "/" isn't a valid context
> path, though it might actually work since "//" ~= "/" in the URL world.

Yep.

> 
>>> The second argument is a "baseDir" which says (via 
>>> Context.setDocBase) it can be an absolute pathname, a relative 
>>> pathname (to the cwd I suppose, or maybe relative to the hosts's 
>>> appbase), or a URL.
>> 
>> Well there's part of the problem with the documentation. The 
>> documentation for the method says "Add a webapp using normal 
>> WEB-INF/web.xml if found." and the documentation for the "baseDir" 
>> parameter says nothing. There's no information here that would
>> have led me to look at the Context#setDocBase() method. Nada. I
>> will try out making it a URL.
> 
> I was reading the code, not the Javadoc: it makes it a lot easier.
> Since the "baseDir" gets passed into Context.setDocBase, I read the
> javadoc for that method to get the real story.

That's how I ended up getting it running: I starting reading code instead of 
documentation.

> 
>>> You are passing a relative path name which probably won't
>>> resolve to a resource "inside" the JAR file you are using. Try
>>> fetching a resource URL for the "web/" path from the ClassLoader
>>> and pass that instead of just "web/".
>> 
>> I will give this a try.
>> 
>>> You didn't say what actually happens: just stated your
>>> requirements and showed your code. Does Tomcat fail to start?
>>> Does it fail to listen on your port? Does it fail to respond to
>>> requests?
>> 
>> My bad. I'm always seeing y'all tell people to explain the
>> problem, and here I go not explaining the problem just like all the
>> rest of them. :-P ... When I ran the application using the batch
>> file generated by the mojo plugin, almost everything was good
>> (Tomcat started up, started listening on the right port, found all
>> the classes it was supposed to find, etc.). However, I got a
>> "severe" error that the web application directory
>> (webAppDirLocation) did not exist and the application could not be
>> deployed. Understandable, since I didn't know what to use for
>> this.
> 
> The likely problem is that your appBase was just "web" and Tomcat was
> trying to load that from the disk (directly) instead of looking inside
> your JAR file. Using a JAR-URL (which the ClassLoader should give you)
> should work. The URL should look something like /path/to/your.jar!/web
> or something like that.

I tried using a JAR URL. (If I remember correctly, it ended up looking 
something like 
jar:url://C:/Users/Nicholas/Desktop/Project/target/Test.jar!/Test.war.) I tried 
it as both a directory and a WAR file. Tomcat did not like it. It said "Could 
not deploy web application to [temporary webapps directory location]" or 
something like that. I ended up, at runtime, extracting the war file from the 
JAR file to a temporary directory and deploying from there. That worked great, 
and it's how the Tomcat Maven plugin executable war works, too.

> 
 tomcat.start();
>>> 
>>> You should probably call tomcat.init() first, though some of the 
>>> Tomcat test cases don't do it so you're probably okay.
>> 
>> Yea, the tutorial I was using didn't say anything about that. 
>> Interesting that "init" and "start" are separate. If "init" was 
>> required and "start" didn't call "init" I would think that "start" 
>> would throw an IllegalStateException. Since it doesn't, my guess
>> is that calling "start" is sufficient, though I will certainly add 
>> "init." I would love to now the semantic difference between "init"
>> and "start." The documentation just says "Initialize the server"
>> and "Start the server."
> 
> Take a look at the Javadoc for LifecycleListener, one of the
> interfaces that the Tomcat class implements. The Javadoc for any
> implemented yet not documented method from that interface gets
> inherited in the javadoc for the implemen

Re: Standard or OCSP Native Lib?

[Nick Williams]

On Mar 15, 2013, at 10:21 AM, Mladen Turk wrote:

> Otherwise it'll just slow you down.

That's what I was looking for. I didn't see any indication anywhere that OCSP 
came with a performance hit, so my thought was, "why wouldn't you just always 
use the OCSP version?" Thanks for clarifying this.

> Since the current implementation does not have enable/disable configuration
> the only way was to make it compile time enabled/disabled.
> 
> In future I see those two will become one version with runtime selection.

That would certainly be an improvement, in my mind. :-)

Thanks,

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

WebSockets problem Re: NullPointerException in MapperListener; Tomcat#start() does not create a Container?

[Nick Williams]

On Mar 14, 2013, at 4:25 PM, Konstantin Kolinko wrote:

> 2013/3/15 Nick Williams :
>> 
>> On Mar 14, 2013, at 2:56 PM, Nick Williams wrote:
>> 
>>> Using a variety of tutorials I found online and the documentation for 
>>> o.a.c.startup.Tomcat, I created the following main method to start up an 
>>> embedded Tomcat. I'm using 7.0.37 Tomcat JARs.
>>> 
>>>   public static void main(String... arguments) throws Exception
>>>   {
>>>   Tomcat tomcat = new Tomcat();
>>>   tomcat.setBaseDir(".basedir");
>>>   tomcat.setPort(8973);
>>>   tomcat.enableNaming();
>>>   tomcat.init();
>>>   tomcat.start();
>>> 
>>>   System.out.println("X: " + 
>>> tomcat.getConnector().getService().getContainer());
>>> 
>>>   tomcat.getServer().await();
>>>   }
>>> 
>>> The System.out.println is for debugging purposes, because I'm getting a 
>>> NullPointerException. Obviously I'm doing something wrong, because about an 
>>> hour of Googling turned up precisely zero results of anyone who's getting a 
>>> NullPointerException in MapperListener#findDefaultHost. For some reason, it 
>>> looks like a Container is never created. What gives? Here's the full output 
>>> of running the JAR file:
> 
> 
> Why do you expect that default "Host" exist, if you have not created
> one, nor asked for one, nor deployed a web application,  all of them
> auto-create it if it is missing.
> 
> There may be different implementations of a Host. It needs
> configuration (name). Thus initially there is none created.
> 
> Calling tomcat.getHost() should be enough.
> 
> Note, that Tomcat needs a default web application (aka context with
> path "", aka ROOT) for certain features (error reporting) to work
> properly.

I understand what I was doing wrong, now. I was trying to take any web 
application errors out of the picture so that I could solve any other problems 
I was having first. I didn't realize that you couldn't start normally if you 
didn't have any applications to deploy, so I was actually causing more problems 
by removing the adding of my web application.

I don't need tomcat.getService().setContainer(tomcat.getEngine()) anymore now 
that I'm calling addWebapp on a proper web application.

Mark, my application successfully deploys to the ROOT context in the embedded 
Tomcat and a test servlet (/healthCheck) starts up properly and requests to it 
resolve properly. However, my WebSocket endpoints were not working. I was 
getting 404 errors for any requests to them. It tracked it down to missing 
service providers. The following files are missing from the 
org.apache.tomcat.embed:tomcat-embed-core artifact:

META-INF/services/javax.servlet.ServletContainerInitializer
META-INF/services/javax.websocket.ContainerProvider
META-INF/services/javax.websocket.server.ServerContainerProvider
META-INF/services/javax.websocket.server.ServerEndpointConfig.Configurator

When I added those to my uber-jar embedded JAR file, WebSockets started working 
properly. So, looks like something about the way that artifact is built is 
omitting those files accidentally. I can file a bug about this if you need me 
to.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: NullPointerException in MapperListener; Tomcat#start() does not create a Container?

[Nick Williams]

On Mar 14, 2013, at 2:56 PM, Nick Williams wrote:

> Using a variety of tutorials I found online and the documentation for 
> o.a.c.startup.Tomcat, I created the following main method to start up an 
> embedded Tomcat. I'm using 7.0.37 Tomcat JARs.
> 
>public static void main(String... arguments) throws Exception
>{
>Tomcat tomcat = new Tomcat();
>tomcat.setBaseDir(".basedir");
>tomcat.setPort(8973);
>tomcat.enableNaming();
>tomcat.init();
>tomcat.start();
> 
>System.out.println("X: " + 
> tomcat.getConnector().getService().getContainer());
> 
>tomcat.getServer().await();
>}
> 
> The System.out.println is for debugging purposes, because I'm getting a 
> NullPointerException. Obviously I'm doing something wrong, because about an 
> hour of Googling turned up precisely zero results of anyone who's getting a 
> NullPointerException in MapperListener#findDefaultHost. For some reason, it 
> looks like a Container is never created. What gives? Here's the full output 
> of running the JAR file:
> 
> Mar 14, 2013 2:39:04 PM org.apache.coyote.AbstractProtocol init
> INFO: Initializing ProtocolHandler ["http-bio-8973"]
> Mar 14, 2013 2:39:04 PM org.apache.catalina.core.StandardService startInternal
> INFO: Starting service Tomcat
> Mar 14, 2013 2:39:04 PM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["http-bio-8973"]
> Mar 14, 2013 2:39:04 PM org.apache.catalina.core.StandardService startInternal
> SEVERE: Failed to start connector [Connector[HTTP/1.1-8973]]
> org.apache.catalina.LifecycleException: Failed to start component 
> [Connector[HTTP/1.1-8973]]
>at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
>at 
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
>at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>at 
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
>at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>at org.apache.catalina.startup.Tomcat.start(Tomcat.java:335)
>at com.ul.Bootstrap.main(Bootstrap.java:15)
> Caused by: org.apache.catalina.LifecycleException: Failed to start component 
> [org.apache.catalina.connector.MapperListener@768debd]
>at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
>at 
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1022)
>at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>... 6 more
> Caused by: java.lang.NullPointerException
>at 
> org.apache.catalina.connector.MapperListener.findDefaultHost(MapperListener.java:252)
>at 
> org.apache.catalina.connector.MapperListener.startInternal(MapperListener.java:104)
>at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>... 8 more
> 
> X: null

I resolved the NullPointerException by calling 
tomcat.getService().setContainer(tomcat.getEngine()) between init() and 
start(). Everything is working fine now, and I can go to 
http://localhost:8973/MyServlet and it's working great, but I still suspect I'm 
doing something wrong, since no documentation or tutorials anywhere mention 
needing to do that and it seems that the container should automatically be set 
on the service...

I'm open to suggestions if anybody has any, but at least it's working now.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

NullPointerException in MapperListener; Tomcat#start() does not create a Container?

[Nick Williams]

Using a variety of tutorials I found online and the documentation for 
o.a.c.startup.Tomcat, I created the following main method to start up an 
embedded Tomcat. I'm using 7.0.37 Tomcat JARs.

public static void main(String... arguments) throws Exception
{
Tomcat tomcat = new Tomcat();
tomcat.setBaseDir(".basedir");
tomcat.setPort(8973);
tomcat.enableNaming();
tomcat.init();
tomcat.start();

System.out.println("X: " + 
tomcat.getConnector().getService().getContainer());

tomcat.getServer().await();
}

The System.out.println is for debugging purposes, because I'm getting a 
NullPointerException. Obviously I'm doing something wrong, because about an 
hour of Googling turned up precisely zero results of anyone who's getting a 
NullPointerException in MapperListener#findDefaultHost. For some reason, it 
looks like a Container is never created. What gives? Here's the full output of 
running the JAR file:

Mar 14, 2013 2:39:04 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8973"]
Mar 14, 2013 2:39:04 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Tomcat
Mar 14, 2013 2:39:04 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8973"]
Mar 14, 2013 2:39:04 PM org.apache.catalina.core.StandardService startInternal
SEVERE: Failed to start connector [Connector[HTTP/1.1-8973]]
org.apache.catalina.LifecycleException: Failed to start component 
[Connector[HTTP/1.1-8973]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:459)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:335)
at com.ul.Bootstrap.main(Bootstrap.java:15)
Caused by: org.apache.catalina.LifecycleException: Failed to start component 
[org.apache.catalina.connector.MapperListener@768debd]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1022)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 6 more
Caused by: java.lang.NullPointerException
at 
org.apache.catalina.connector.MapperListener.findDefaultHost(MapperListener.java:252)
at 
org.apache.catalina.connector.MapperListener.startInternal(MapperListener.java:104)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 8 more

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

Re: Can Tomcat 8 snapshots be published to Maven?

[Nick Williams]

On Mar 14, 2013, at 7:25 AM, Martin Grigorov wrote:

> On Thu, Mar 14, 2013 at 12:49 PM, Mark Thomas  wrote:
> 
>>> 
>> https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/
 
 Mark
>>> 
>>> Sweet! Thanks! So will I need to add https://repository.apache.org/ as
>>> a custom repository in my POM, or will Maven Central eventually pick up
>>> the change?
>> 
> 
> Yes, you will need to add this repository to your pom.xml.
> 
> See
> https://github.com/apache/wicket/blob/master/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml#L173
> This is the pom.xml we use for Apache Wicket archetype for -SNAPSHOT
> versions.
> 
> When Tomcat developer release the modules they will go to
> https://repository.apache.org/content/repositories/RELEASES/org/apache/tomcat/
> and this will be sync-ed to Maven central repository.
> 
> 
>> 
>> I thought central did pick these up but a re-read of the docs says not.
>> 
>> Mark

Yea, I figured out after sending this email that I just needed the following in 
my POM:



apache-snapshots
Apache Snapshots Repository

https://repository.apache.org/content/repositories/snapshots
default

true



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

Tomcat 8 + Tomcat Maven Plugin 2.2 + Tomcat8 Maven Plugin?

[Nick Williams]

https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/maven/

In snapshots there is only tomcat6-maven-plugin and tomcat7-maven-plugin. So, 
even though my Maven dependencies are on Tomcat 8.0-SNAPSHOT, any "executable 
war" I build with the plugin has Tomcat 7 classes in it, meaning the 
application won't run (NoClassDefFound, etc.).

What needs to be done to get a tomcat8-maven-plugin snapshot started? Is this a 
whole new project that hasn't been started yet? Or does a new build 
configuration just need to be created?

Re: Can Tomcat 8 snapshots be published to Maven?

[Nick Williams]

On Mar 13, 2013, at 7:44 PM, Mark Thomas wrote:

> On 12/03/2013 22:08, Nick Williams wrote:
>> 
>> On Mar 12, 2013, at 12:39 PM, Mark Thomas wrote:
>> 
>>> On 12/03/2013 17:38, Mark Thomas wrote:
>>>> On 12/03/2013 17:27, Nick Williams wrote:
>>>>> I'm experimenting with using Tomcat embedded. I need Tomcat 8.0,
>>>>> because I need Servlet 3.1 and WebSocket features. I can accomplish
>>>>> this manually I'm sure, but all of the tutorials out there for using
>>>>> Tomcat embedded (that I've found) show it using Maven, and frankly I
>>>>> prefer to use Maven when I can.
>>>>> 
>>>>> So I went on the Maven central repository and saw that the newest
>>>>> Tomcat on there was 7.0.37. Some projects publish SNAPSHOT artifacts
>>>>> from nightly trunk builds, but it appears that Tomcat does not. Two
>>>>> questions:
>>>>> 
>>>>> 1) Is there a repository other than central that has nightly trunk
>>>>> snapshots published?
>>>> No.
>>>> 
>>>>> 2) If not, is it possible to start getting nightly trunk snapshots
>>>>> published?
>>>> Yes.
>>> 
>>> Scratch that. It is a manual process so nightly snapshots won't happen. 
>>> Snapshots are still possible.
>>> 
>> 
>> Okay. So what needs to be done to make this happen? I know nothing about 
>> publishing snapshots (or anything, for that matter) to Maven. If I can help 
>> in some way I'm willing to learn, but I imagine it takes someone with 
>> "Tomcat Authority" to publish Tomcat artifacts.
> 
> https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/
> 
> Mark

Sweet! Thanks! So will I need to add https://repository.apache.org/ as a custom 
repository in my POM, or will Maven Central eventually pick up the change?

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

Re: Embedded Tomcat JavaDoc Not Complete

[Nick Williams]

On Mar 12, 2013, at 10:47 PM, Nick Williams wrote:

> The JavaDoc for o.a.c.startup.Tomcat [1] is not complete. Importantly, it is 
> lacking complete information about all three addWebapp classes. Ultimately, I 
> want to create one giant JAR file with my classes, Tomcat classes, servlet 
> classes, etc., with a com.mycompany.Bootstrap specified as the Main class in 
> MANIFEST.MF. Here's (roughly) what I expect it to look like (though, if it 
> should be different to make something work correctly, please correct me):
> 
> - MyEmbeddedWebApp.jar
>- com
>- mycompany
>- ...
>- javax
>- ...
>- META-INF
>- MANIFEST.MF
>- org
>- apache
>- ...
>- web
>- index.html
>- WEB-INF
>- web.xml
> 
> How do I correctly start up Tomcat so that my (lone) web app 
> (MyEmbeddedWebApp.jar!/web/WEB-INF/web.xml) is correctly deployed to the root 
> context (/) with index.html and etc. resources available?
> 
> [1] 
> http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html

By the way, com.mycompany.Bootstrap currently looks like the code below. It's 
the webAppDirLocation variable and addWebapp method call that I'm struggling 
with.

public class Bootstrap
{
public static void main(String... arguments) throws Exception
{
String webAppDirLocation = "web/";
Tomcat tomcat = new Tomcat();
tomcat.setPort(8973);
tomcat.addWebapp("/", new File(webAppDirLocation).getAbsolutePath());

tomcat.start();
tomcat.getServer().await();
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Embedded Tomcat JavaDoc Not Complete

[Nick Williams]

The JavaDoc for o.a.c.startup.Tomcat [1] is not complete. Importantly, it is 
lacking complete information about all three addWebapp classes. Ultimately, I 
want to create one giant JAR file with my classes, Tomcat classes, servlet 
classes, etc., with a com.mycompany.Bootstrap specified as the Main class in 
MANIFEST.MF. Here's (roughly) what I expect it to look like (though, if it 
should be different to make something work correctly, please correct me):

- MyEmbeddedWebApp.jar
- com
- mycompany
- ...
- javax
- ...
- META-INF
- MANIFEST.MF
- org
- apache
- ...
- web
- index.html
- WEB-INF
- web.xml

How do I correctly start up Tomcat so that my (lone) web app 
(MyEmbeddedWebApp.jar!/web/WEB-INF/web.xml) is correctly deployed to the root 
context (/) with index.html and etc. resources available?

[1] 
http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Can Tomcat 8 snapshots be published to Maven?

[Nick Williams]

On Mar 12, 2013, at 12:39 PM, Mark Thomas wrote:

> On 12/03/2013 17:38, Mark Thomas wrote:
>> On 12/03/2013 17:27, Nick Williams wrote:
>>> I'm experimenting with using Tomcat embedded. I need Tomcat 8.0,
>>> because I need Servlet 3.1 and WebSocket features. I can accomplish
>>> this manually I'm sure, but all of the tutorials out there for using
>>> Tomcat embedded (that I've found) show it using Maven, and frankly I
>>> prefer to use Maven when I can.
>>> 
>>> So I went on the Maven central repository and saw that the newest
>>> Tomcat on there was 7.0.37. Some projects publish SNAPSHOT artifacts
>>> from nightly trunk builds, but it appears that Tomcat does not. Two
>>> questions:
>>> 
>>> 1) Is there a repository other than central that has nightly trunk
>>> snapshots published?
>> No.
>> 
>>> 2) If not, is it possible to start getting nightly trunk snapshots
>>> published?
>> Yes.
> 
> Scratch that. It is a manual process so nightly snapshots won't happen. 
> Snapshots are still possible.
> 

Okay. So what needs to be done to make this happen? I know nothing about 
publishing snapshots (or anything, for that matter) to Maven. If I can help in 
some way I'm willing to learn, but I imagine it takes someone with "Tomcat 
Authority" to publish Tomcat artifacts.

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

Can Tomcat 8 snapshots be published to Maven?

[Nick Williams]

I'm experimenting with using Tomcat embedded. I need Tomcat 8.0, because I need 
Servlet 3.1 and WebSocket features. I can accomplish this manually I'm sure, 
but all of the tutorials out there for using Tomcat embedded (that I've found) 
show it using Maven, and frankly I prefer to use Maven when I can.

So I went on the Maven central repository and saw that the newest Tomcat on 
there was 7.0.37. Some projects publish SNAPSHOT artifacts from nightly trunk 
builds, but it appears that Tomcat does not. Two questions:

1) Is there a repository other than central that has nightly trunk snapshots 
published?
2) If not, is it possible to start getting nightly trunk snapshots published?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Having WebSocket Issues (Tomcat 8)

[Nick Williams]

On Mar 11, 2013, at 5:50 PM, Mark Thomas wrote:

> On 11/03/2013 22:38, Nick Williams wrote:
>> However, I do still have the original question: Will I always need to
>> use a listener to add my endpoints programmatically like I did below?
>> Or will Tomcat eventually scan for endpoints? The examples
>> downloadable from the GlassFish project "just work" ... there is no
>> listener or call to ServerContainerProvider.getServerContainer(). Not
>> sure if that's GlassFish doing something special that's not in the
>> spec, or if the Tomcat implementation just doesn't have this feature
>> yet.
> 
> The SCI should be scanning for them already.
> 

My endpoint class was not get recognized/instantiated. I had a breakpoint in 
the constructor and I never hit it. Only when I added the listener that called 
addEndpoint(EchoEndpoint.class) did it start getting instantiated (and I 
started hitting the breakpoint and being able to call the endpoint). However, I 
have now deleted the listener, and the endpoint is still getting instantiated. 
I'm very confused. I didn't change a line of code in the endpoint. It's exactly 
like it was before, when it wasn't getting instantiated. *scratches head*

I'm going crazy over here…

Oh, well. It least it's working.

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

Re: Having WebSocket Issues (Tomcat 8)

[Nick Williams]

I got this working by changing ServerContainerProvider#getServerContainer() to 
be public, per the spec. I submitted bug 54671 with patch.

However, I do still have the original question: Will I always need to use a 
listener to add my endpoints programmatically like I did below? Or will Tomcat 
eventually scan for endpoints? The examples downloadable from the GlassFish 
project "just work" ... there is no listener or call to 
ServerContainerProvider.getServerContainer(). Not sure if that's GlassFish 
doing something special that's not in the spec, or if the Tomcat implementation 
just doesn't have this feature yet.

N

On Mar 11, 2013, at 4:59 PM, Nick Williams wrote:

> I'm trying to create what I thought was a very simple WebSocket example, but 
> boy have I had difficulties…
> 
> I started by basically coping the EchoAnnotation example from the Tomcat 
> examples. However, it was like my endpoint was never getting instantiated. 
> (Is this temporary? Will Tomcat 8 ultimately scan for and instantiate these 
> endpoints? Or will the server container always have to be created manually?)
> 
> I then noticed the listener that the examples application was using to 
> initialize the container and add the endpoints. I didn't want to tie my 
> example to the Tomcat classes, so I tried to do it a bit more generically 
> based on the WebSocket API. Below you will find the listener I created. It 
> compiles just fine, but on deployment I get the very unusual error further 
> down. What's up with this? Is this just an example of Tomcat being behind the 
> RC1 API?
> 
> import javax.servlet.ServletContextEvent;
> import javax.servlet.ServletContextListener;
> import javax.servlet.annotation.WebListener;
> import javax.websocket.server.ServerContainer;
> import javax.websocket.server.ServerContainerProvider;
> 
> @WebListener
> public class WebSocketInitializerListener implements ServletContextListener
> {
>@Override
>public void contextInitialized(ServletContextEvent servletContextEvent)
>{
>try
>{
>ServerContainer container = 
> ServerContainerProvider.getServerContainer();
>container.addEndpoint(EchoEndpoint.class);
>}
>catch (Exception e)
>{
>System.err.println(e.toString());
>e.printStackTrace(System.err);
>throw new RuntimeException("Could not start WebSocket container.");
>}
>}
> 
>@Override
>public void contextDestroyed(ServletContextEvent servletContextEvent)
>{
> 
>}
> }
> 
> SEVERE: Exception sending context initialized event to listener instance of 
> class com.wrox.WebSocketInitializerListener
> java.lang.IllegalAccessError: tried to access method 
> javax.websocket.server.ServerContainerProvider.getServerContainer()Ljavax/websocket/server/ServerContainer;
>  from class com.wrox.WebSocketInitializerListener
>   at 
> com.wrox.WebSocketInitializerListener.contextInitialized(WebSocketInitializerListener.java:17)
>   at 
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4769)
>   at 
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5210)
>   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
>   at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
>   at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
>   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698)
>   at 
> org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1492)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:487)
>   at 
> org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
>   at 
> org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:468)
>   at 
> org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:415)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invok

Having WebSocket Issues (Tomcat 8)

[Nick Williams]

I'm trying to create what I thought was a very simple WebSocket example, but 
boy have I had difficulties…

I started by basically coping the EchoAnnotation example from the Tomcat 
examples. However, it was like my endpoint was never getting instantiated. (Is 
this temporary? Will Tomcat 8 ultimately scan for and instantiate these 
endpoints? Or will the server container always have to be created manually?)

I then noticed the listener that the examples application was using to 
initialize the container and add the endpoints. I didn't want to tie my example 
to the Tomcat classes, so I tried to do it a bit more generically based on the 
WebSocket API. Below you will find the listener I created. It compiles just 
fine, but on deployment I get the very unusual error further down. What's up 
with this? Is this just an example of Tomcat being behind the RC1 API?

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;
import javax.websocket.server.ServerContainer;
import javax.websocket.server.ServerContainerProvider;

@WebListener
public class WebSocketInitializerListener implements ServletContextListener
{
@Override
public void contextInitialized(ServletContextEvent servletContextEvent)
{
try
{
ServerContainer container = 
ServerContainerProvider.getServerContainer();
container.addEndpoint(EchoEndpoint.class);
}
catch (Exception e)
{
System.err.println(e.toString());
e.printStackTrace(System.err);
throw new RuntimeException("Could not start WebSocket container.");
}
}

@Override
public void contextDestroyed(ServletContextEvent servletContextEvent)
{

}
}

SEVERE: Exception sending context initialized event to listener instance of 
class com.wrox.WebSocketInitializerListener
java.lang.IllegalAccessError: tried to access method 
javax.websocket.server.ServerContainerProvider.getServerContainer()Ljavax/websocket/server/ServerContainer;
 from class com.wrox.WebSocketInitializerListener
at 
com.wrox.WebSocketInitializerListener.contextInitialized(WebSocketInitializerListener.java:17)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4769)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5210)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698)
at 
org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1492)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:487)
at 
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
at 
org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:468)
at 
org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:415)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:487)
at 
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:791)
at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1465)
at 
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:75)
at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1306)
at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1398)
at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:827)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

Re: Multiple JSESSIONID

[Nick Williams]

APOLOGIES FOR TOP POSTING! (see below, were I correctly inline post this 
apology)

On Mar 1, 2013, at 1:58 PM, Nick Williams wrote:

> Browsers send all of the cookies because that's the compliant thing to do. 
> RFC-2109 [1] says:
> 
>> If multiple cookies satisfy the criteria above, they are ordered in
>> the Cookie header such that those with more specific Path attributes
>> precede those with less specific.  Ordering with respect to other
>> attributes (e.g., Domain) is unspecified.
> 
> 
> Based on that, assuming Tomcat follows the rules Christopher says it does, 
> you should be okay. The /app/myapplication cookie should always come first, 
> and assuming it is valid Tomcat should always prefer it.
> 
> Nick
> 
> [1] http://www.ietf.org/rfc/rfc2109.txt

My apologies for top posting! I don't normally do that. Slip of the keyboard...

> 
> On Mar 1, 2013, at 1:46 PM, Jose María Zaragoza wrote:
> 
>> Thanks for your answers.
>> 
>> I wonder why browsers don't send only one JSESSIONID
>> If I request an URL as www.mydomain.com/app/myapplication/action.do
>> and it has got 2 cookies with the same name, one for www.mydomain.com/
>> and another for www.mydomain.com/app/myapplication/  , IMHO, that a
>> browser should send the most restrictive
>> 
>> Indeed, I don't know if there is some browser working like that.
>> 
>> 
>> Christopher,
>> if the browser sends a JSESSIONID to Tomcat and this JSESSIONID is not
>> tracked by the server , does any error happen ?  or is it created a
>> new session with a new identifier ?
>> 
>> Thanks and regards
>> 
>> 
>> 
>> 2013/2/28 Caldarale, Charles R :
>>>> From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
>>>> Subject: Re: Multiple JSESSIONID
>>> 
>>>>> That's interesting. I would recommend a servlet filter that captures
>>>>> addCookie and friends to see where that "extra" one is being added.
>>> 
>>>> The two JSESSIONIDs immediately above are in the request, so they're added
>>>> by the browser, not the server
>>> 
>>> Unless the browser is part of a hacking attack, the JSESSIONID cookies 
>>> originally came from the server.  The filter would have to be applied to 
>>> both the ROOT and /app/myapplication contexts, so it might best be placed 
>>> in conf/web.xml to cover all webapps.
>>> 
>>> - Chuck
>>> 
>>> 
>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
>>> MATERIAL and is thus for use only by the intended recipient. If you 
>>> received this in error, please contact the sender and delete the e-mail and 
>>> its attachments from all computers.
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Multiple JSESSIONID

[Nick Williams]

Browsers send all of the cookies because that's the compliant thing to do. 
RFC-2109 [1] says:

> If multiple cookies satisfy the criteria above, they are ordered in
> the Cookie header such that those with more specific Path attributes
> precede those with less specific.  Ordering with respect to other
> attributes (e.g., Domain) is unspecified.


Based on that, assuming Tomcat follows the rules Christopher says it does, you 
should be okay. The /app/myapplication cookie should always come first, and 
assuming it is valid Tomcat should always prefer it.

Nick

[1] http://www.ietf.org/rfc/rfc2109.txt

On Mar 1, 2013, at 1:46 PM, Jose María Zaragoza wrote:

> Thanks for your answers.
> 
> I wonder why browsers don't send only one JSESSIONID
> If I request an URL as www.mydomain.com/app/myapplication/action.do
> and it has got 2 cookies with the same name, one for www.mydomain.com/
> and another for www.mydomain.com/app/myapplication/  , IMHO, that a
> browser should send the most restrictive
> 
> Indeed, I don't know if there is some browser working like that.
> 
> 
> Christopher,
> if the browser sends a JSESSIONID to Tomcat and this JSESSIONID is not
> tracked by the server , does any error happen ?  or is it created a
> new session with a new identifier ?
> 
> Thanks and regards
> 
> 
> 
> 2013/2/28 Caldarale, Charles R :
>>> From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
>>> Subject: Re: Multiple JSESSIONID
>> 
>>>> That's interesting. I would recommend a servlet filter that captures
>>>> addCookie and friends to see where that "extra" one is being added.
>> 
>>> The two JSESSIONIDs immediately above are in the request, so they're added
>>> by the browser, not the server
>> 
>> Unless the browser is part of a hacking attack, the JSESSIONID cookies 
>> originally came from the server.  The filter would have to be applied to 
>> both the ROOT and /app/myapplication contexts, so it might best be placed in 
>> conf/web.xml to cover all webapps.
>> 
>> - Chuck
>> 
>> 
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
>> MATERIAL and is thus for use only by the intended recipient. If you received 
>> this in error, please contact the sender and delete the e-mail and its 
>> attachments from all computers.
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Multiple JSESSIONID

[Nick Williams]

On Feb 28, 2013, at 10:50 AM, Christopher Schultz wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jose,
> 
> On 2/28/13 2:43 AM, Jose María Zaragoza wrote:
>> I've seen in my web browser that it has got 2 JSESSIONID for the
>> same domain at the same time
>> 
>> 
>> JSESSIONID: x www.mydomain.com /
>> 
>> and
>> 
>> JSESSIONID:  www.mydomain.com /app/myapplication/
> 
> You might want to instrument your web application to find our why you
> are getting JSESSIONIDs with different paths. Do you have a ROOT
> webapp that can generate sessions? Perhaps you have JSPs in your ROOT
> webapp that don't have session="false" in its header?
> 
>> Cheking request to my Tomcat server, I see
>> 
>> POST /app/myaplication/action/play.do
>> 
>> Cookie: DWRSESSIONID=F71Wlww0mrwuExOQoE3aLslewQj; 
>> JSESSIONID=x; 
>> JSESSIONID=yy;
> 
> That's interesting. I would recommend a servlet filter that captures
> addCookie and friends to see where that "extra" one is being added.

The two JSESSIONIDs immediately above are in the request, so they're added by 
the browser, not the server, so a filter wouldn't do you any good there. He 
could, however, put a filter on the ROOT web application (assuming he has 
enough control over it to do so) to figure out what is creating the session in 
the ROOT application. Chris, you may have known that and meant something 
different, and if so, my apologies for misunderstanding.

> 
>> How does Tomcat server handle this situation ? I'm talking about 
>> session managing Does it read the first JSESSIONID ? Does it read
>> every JSESSIONID ? Can this cause problems ?
> 
> Tomcat will read session ids until it finds one that is valid: having
> multiple JSESSIONID cookies is not a problem unless *both* are valid
> for some reason. In that case, I suspect you'll get the first (that
> is, the one that occurs first in the HTTP request) JSESSIONID and the
> other one will essentially be ignored.
> 
>> I know I can rename JSESSIONID  when it's serve by my Tomcat
>> server, but I want to be sure that I need to do that
> 
> You probably don't need to do that.

Need, not absolutely, no. However, changing the name of the session cookie in 
the deployment descriptor of the /app/myapplication app WOULD eliminate any 
conflict between the two sessions for sure, and if it is valid that both the 
/app/myapplication application and the ROOT (/) application are creating 
sessions, that might be the safest thing to do.

Nick

> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEAREIAAYFAlEvitoACgkQ9CaO5/Lv0PDBGACfby+4zBL7VYhC8vgLu3VE93ZJ
> wG8AmgL2DerJA9o+BL8t7aV9rgZGl4fH
> =qVg7
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Tomcat 7 doesn't start on Windows

[Nick Williams]

On Feb 28, 2013, at 9:40 AM, Mark Thomas wrote:

> On 28/02/2013 07:38, Nick Williams wrote:
>> 
>> On Feb 28, 2013, at 3:46 AM, Stadelmann Josef wrote:
>> 
>>> Where does CATALINA_HOME point to?
>>> Josef
>> 
>> Rune reported yesterday that he solved the problem by resetting the registry 
>> values. There was some strange garbage in one of the registry values. I'd 
>> love to know how it got there, but we probably never will.
> 
> Maybe this:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54609

I stand corrected. That's probably it. Rune reported using 7.0.37, just like in 
the bug report, and his registry path looked like this:

"C:\Program Files\Apache Software Foundation\Tomcat 7.0\bin\Tomcat7.exe" 
ogs\commons-daemon.2013-02-27.log//RS//Tomcat7

So, yea. That bug appears to be his issue. That is bizarre. I will be following 
this bug to see what in the world caused it.

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



smime.p7s
Description: S/MIME cryptographic signature

Re: Tomcat 7 doesn't start on Windows

[Nick Williams]

On Feb 28, 2013, at 3:46 AM, Stadelmann Josef wrote:

> Where does CATALINA_HOME point to?
> Josef

Rune reported yesterday that he solved the problem by resetting the registry 
values. There was some strange garbage in one of the registry values. I'd love 
to know how it got there, but we probably never will.

N

> 
> -Ursprüngliche Nachricht-
> Von: André Warnier [mailto:a...@ice-sa.com] 
> Gesendet: Mittwoch, 27. Februar 2013 13:38
> An: Tomcat Users List
> Betreff: Re: Tomcat 7 doesn't start on Windows
> 
> Giles wrote:
>> On 27 February 2013 11:52, André Warnier  wrote:
>>> computer repair centre wrote:
 On Wed, Feb 27, 2013 at 10:18 AM, Rune Stilling  wrote:
> Hi again
> 
> Thanks for your answers. I have given up. I have tried some of the
> suggestions:
> 
> * Uninstall all JVM's and Tomcats (and reinstall)
> * Checked dependcies, yes there were two, that are also present on 
> another machine running Tomcat7 (TCP/IP, ADF)
> * Tried to use client/jvm.dll instead of server/jvm.dll
> 
> Nothing helps - I can still only run the service from the command prompt.
> I find it strange though, that Tomcat isn't able to log anything at 
> all about this, but maybe it's all Windows fault?
> 
> Hopefully things will work on a new VPS, and I'll quit the old one.
> 
> /Rune
> 
> Den 26/02/2013 kl. 13.04 skrev Rune Stilling :
> 
> 
> 
> ---
> -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
 
 Hi Rune,
 
 Please can you provide the value of the JAVA_HOME environment variable?
 
>>> That has nothing to do with the matter. The wrapper (tomcat7.exe) 
>>> takes the path of the JVM to run from the Registry, not from environment 
>>> variables.
>>> Run tomcat7w.exe and check the Java tab.
>> 
>> But it is used by service.bat when installing the service. This issue 
>> could be caused by using the 64-bit installation with the 32-bit JVM.
>> This would explain why calling the wrapper directly from the command 
>> line does execute successfully.
>> 
> 
> I believe that the above statement is false.
> Whether you run the command
> "tomcat7 //TS/Tomcat7"
> from a command-line window, or you let the Windows Service Manager run the 
> same command, does not change the fact that "tomcat7(.exe)" takes its 
> parameters from the same place in the Registry.
> So if it works one way, and not the other, it is not because of that Registry 
> setting nor bacause the JAVA_HOME environment variable.
> 
> 
> -
> 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
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Tomcat 7 doesn't start on Windows

[Nick Williams]

On Feb 27, 2013, at 7:36 AM, Rune Stilling wrote:

> Hi André
> 
> Thanks for an excellent summary. There's one thing that I haven't been 
> precise enough about I can see.
> 
> I CANNOT run Tomcat via the RS-parameter:
> 
> Tomcat7.exe //RS/Tomcat7
> 
> If I try the log produces the following:
> 
> [2013-02-27 14:33:55] [info]  [548184] Commons Daemon procrun (1.0.13.0 
> 64-bit) started
> [2013-02-27 14:33:55] [info]  [548184] Running 'Tomcat7' Service...
> [2013-02-27 14:33:55] [error] [548184] StartServiceCtrlDispatcher for 
> 'Tomcat7' failed
> [2013-02-27 14:33:55] [error] [548184] The service process could not connect 
> to the service controller.
> [2013-02-27 14:33:55] [error] [548184] Commons Daemon procrun failed with 
> exit value: 4 (Failed to run service)
> [2013-02-27 14:33:55] [error] [548184] The service process could not connect 
> to the service controller.

This is expected. Per Microsoft's website [1] you cannot run services 
interactively from the command line. (You can start them from the command line, 
i.e. with `sc start`, but you cannot run them from the command line, i.e. with 
`Tomcat7.exe //RS/Tomcat7`.) This is why from the command line it works with 
`Tomcat7.exe //TS/Tomcat7` ... that command tells Tomcat to not attempt to 
connect to the service controller.

"The service process could not connect to the service controller" in this case 
is unrelated to the fact that you can't start the Tomcat service from the 
service controller. If you got this message when you tried to start the Tomcat 
service normally, then I would be worried.

One thing I would point out is that your JAVA_HOME environmental variable is 
not correct. This should NOT affect Tomcat when it is running as a service, as 
far as I know. JAVA_HOME should be the home directory of a JDK (e.g., 
C:\Program Files\Java\jdk7) and JRE_HOME should be the home directory of a JRE 
(e.g., C:\Program Files\Java\jre7). Your JRE_HOME is correct, but your 
JAVA_HOME is C:\Program Files\Java. Again, this doesn't matter when Tomcat is 
run as a service. Also, Tomcat only NEEDS a JRE_HOME (and only when running not 
as as service), it does not NEED a JAVA_HOME. But if you have a JAVA_HOME, it 
should be correct.

I've encountered and solved hundreds of Tomcat-as-a-Windows-Service problems 
before, but I have never seen Tomcat not log anything. If you don't mind, could 
you run Tomcat7w.exe, screenshot each tab (Alt + Print Screen gets a screenshot 
for just the window instead of the whole thing), put the screenshots online 
somewhere public, and then post links to the screenshots here? My money is on 
finding something amiss there.

Question: When you run the service installer, it installs Tomcat at C:\Program 
Files\Apache Software Foundation\Tomcat 7.0, correct? (Unless, of course, you 
changed it at install time.)

Question: I know at some point you said this, but I can't find the email 
anymore. Can you remind me what version of Windows you are running on?

[1] http://msdn.microsoft.com/en-us/library/ms686324(VS.85).aspx

> 
> What I CAN do is to run it via the TS-parameter:
> 
> Tomcat7.exe //TS/Tomcat7
> 
> But - I'll try what you suggested anyways.
> 
> /Rune
> 
> Den 27/02/2013 kl. 14.20 skrev André Warnier :
> 
>> Rune Stilling wrote:
>>> Is there some registry key I could check related to the installation 
>>> process?
>> Call up the Registry Editor, and search for "tomcat7".
>> 
>> You should find essentially 2 places :
>> 
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tomcat7
>> (under this one, you will find the parameters which Windows needs to know 
>> about the service (such as, how to start it) ("it" being "tomcat7.exe")
>> 
>> HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\
>> (under this one, you will find the parameters which "tomcat7.exe" (the 
>> "service wrapper") needs to know (such as, which JVM to start and with which 
>> parameters)
>> 
>> (and remember, tomcat7.exe is a renamed "prunsrv.exe", which is one of the 2 
>> modules that are part of "procrun").
>> 
>> --
>> 
>> Let's step back a bit.
>> 
>> 1) you install Tomcat on the machine, using the "Windows installer" package 
>> from tomcat.apache.org.
>> 
>> 2) this installer creates the Registry value :
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tomcat7\ImagePath = 
>> "C:\apache-tomcat-\bin\tomcat7.exe //RS//Tomcat7"
>> (or similar)
>> This Registry value is the one that will be used by the Windows Service 
>> Manager, to know which program to launch when you click on "Services.. 
>> Tomcat7...start".
>> 
>> 3) when you login as a user onto the machine, open a command window, and run 
>> the above command ("C:\apache-tomcat-\bin\tomcat7.exe //RS//Tomcat7"), 
>> the tomcat7.exe program runs, and starts a JVM which starts Tomcat, as a 
>> Service.
>> And that works fine, tomcat logs are produced etc.
>> 
>> 4) when instead, you open the Windows Service Manager dialog, and ask 
>> Windows to

Re: tomcat 7.0.22 - allowTrace="false" not working

[Nick Williams]

On Feb 22, 2013, at 7:49 AM, Konstantin Kolinko wrote:

> 2013/2/18 Sachin :
>> I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our
>> security certifying vendor tests application against.
>> 
>> And it logs -  The URL "http://localhost:8080/app/"; has the following
>> allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found
>> in the request with id 19.
>> 
>> 
>> Thanks & Regards
>> Sachin
>> 
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Monday, February 18, 2013 11:34 PM
>> To: Tomcat Users List
>> Subject: Re: tomcat 7.0.22 - allowTrace="false" not working
>> 
>> On 18/02/2013 15:00, Sachin wrote:
>>> Hi,
>>> 
>>> I want to disable http TRACE method in my application which is running
>>> on tomcat 7.0.22 web-server.
>>> Though apache tomcat configuration for http says that it is set to
>>> false by default, it allows TRACE. I tried setting it to false
>>> specifically, but still it allows.
>>> I searched through your mail archives hosted on 4-5 sites and general
>>> web but could not find a working solution. Please help.
>>> 
>>> Here is 'connector' (only 1) from my server.xml
>>> 
>>>  >>  connectionTimeout="2" allowTrace="false"
>>> redirectPort="8443" />
> 
> 
> The TRACE method vulnerability occurs only if a web server produces
> proper TRACE response, which includes an echo of original request. See
> http://www.kb.cert.org/vuls/id/867593
> 
> If that scanner detects anything else than such response, it is a mere
> false positive.
> 
> One example of false positive is that if you send an OPTIONS request
> to almost any servlet, the "Allow" header in its response by default
> will include the TRACE method (as implemented in
> javax.servlet.http.HttpServlet class).

Konstantin, I had said Monday [1] that I had observed Tomcat doing that before, 
but Mark corrected my and pointed out that that was fixed in Tomcat three years 
ago, and that the 7.0.x branch has never behaved that way.  *scratches head*

[1] 
http://tomcat.markmail.org/search/?q=allowTrace#query:allowTrace+page:2+mid:bvqkjjps2nvzui3z+state:results
[2] 
http://tomcat.markmail.org/search/?q=allowTrace#query:allowTrace+page:2+mid:gg2h43ihalbdzi4j+state:results

> 
> If allowTrace="false" (as it is by default), Tomcat will stop any
> TRACE request before it reaches the web application.
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: tomcat 7.0.22 - allowTrace="false" not working

[Nick Williams]

On Feb 18, 2013, at 1:11 PM, Mark Thomas wrote:

> On 18/02/2013 19:03, Nick Williams wrote:
>> On Feb 18, 2013, at 12:55 PM, Mark Thomas wrote:
>> 
>>> On 18/02/2013 18:19, Sachin wrote:
>>>> I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our
>>>> security certifying vendor tests application against.
>>>> 
>>>> And it logs -  The URL "http://localhost:8080/app/"; has the following
>>>> allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was 
>>>> found
>>>> in the request with id 19.
>>> 
>>> That looks like a false positive although I'm not sure how it is happening. 
>>> You'd have to dig into the test to look at the HTTP request and response 
>>> headers to see what is goign on.
>>> 
>>> Mark
>> 
>> IIRC, I think I witnessed a while back Tomcat report that TRACE was allowed 
>> in an OPTIONS request, but then refuse the request when an actual TRACE was 
>> made. I've also seen this happen with PUT. Perhaps w3af is taking the 
>> OPTIONS response at face value instead of actually testing whether a TRACE 
>> request is allowed? I would suggest that w3af should do both, but I would 
>> also suggest that Tomcat should not include TRACE in the OPTIONS response if 
>> TRACE is really disallowed, and likewise for the other methods.
> 
> No supported Tomcat version has behaved that way for over three years 
> including the entire of the 7.0.x branch.
> 
> Mark

Okay. This was a couple of years ago that I saw this, and it was Tomcat 6.0 at 
the time, so that would probably explain why I saw what I saw. It would not 
explain the false positive he is seeing on 7.0.22, since the entire 7.0.x 
branch has handled this correctly.

Nick

smime.p7s
Description: S/MIME cryptographic signature

Re: tomcat 7.0.22 - allowTrace="false" not working

[Nick Williams]

On Feb 18, 2013, at 12:55 PM, Mark Thomas wrote:

> On 18/02/2013 18:19, Sachin wrote:
>> I'm testing it with w3af(http://w3af.sourceforge.net) since that's what our
>> security certifying vendor tests application against.
>> 
>> And it logs -  The URL "http://localhost:8080/app/"; has the following
>> allowed methods: GET, HEAD, OPTIONS, POST, TRACE. This information was found
>> in the request with id 19.
> 
> That looks like a false positive although I'm not sure how it is happening. 
> You'd have to dig into the test to look at the HTTP request and response 
> headers to see what is goign on.
> 
> Mark

IIRC, I think I witnessed a while back Tomcat report that TRACE was allowed in 
an OPTIONS request, but then refuse the request when an actual TRACE was made. 
I've also seen this happen with PUT. Perhaps w3af is taking the OPTIONS 
response at face value instead of actually testing whether a TRACE request is 
allowed? I would suggest that w3af should do both, but I would also suggest 
that Tomcat should not include TRACE in the OPTIONS response if TRACE is really 
disallowed, and likewise for the other methods.

My $0.02.

N

> 
> 
>> 
>> 
>> Thanks & Regards
>> Sachin
>> 
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Monday, February 18, 2013 11:34 PM
>> To: Tomcat Users List
>> Subject: Re: tomcat 7.0.22 - allowTrace="false" not working
>> 
>> On 18/02/2013 15:00, Sachin wrote:
>>> Hi,
>>> 
>>> I want to disable http TRACE method in my application which is running
>>> on tomcat 7.0.22 web-server.
>>> Though apache tomcat configuration for http says that it is set to
>>> false by default, it allows TRACE. I tried setting it to false
>>> specifically, but still it allows.
>>> I searched through your mail archives hosted on 4-5 sites and general
>>> web but could not find a working solution. Please help.
>>> 
>>> Here is 'connector' (only 1) from my server.xml
>>> 
>>>   >> connectionTimeout="2" allowTrace="false"
>>>  redirectPort="8443" />
>> 
>> How are you testing this?
>> 
>> I just tested 7.0.x trunk and see the documented behaviour. Further, there
>> has been no change in the code that handles this in a number of years.
>> 
>> 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
> 



smime.p7s
Description: S/MIME cryptographic signature

OT: New Email Address

[Nick Williams]

FYI, since some of you may be used to seeing emails from me come from nicholas 
dot williams at ul dot com: I have used my work email addresses for the Tomcat 
list for some time, but I have switched now to my personal email address for a 
variety of reasons:

1) I'm tired of the "privileged or confidential information" notice it adds to 
the bottom of all of my emails to the list.
2) My employer has now implemented a program to forcibly delete all emails 
older than 1 year, preventing me from keeping emails I reference often.
3) Nearly all of my Tomcat business these days is personal- or 
self-employment-related, not employer-related, so it's more convenient.

Just remember when you see future emails from nicholas at nicholaswilliams dot 
net that it's the same person you're used to seeing.

Thanks,

Nick

smime.p7s
Description: S/MIME cryptographic signature

RE: Ant Tasks Question

[Nick Williams]

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, April 03, 2012 9:03 AM
To: Tomcat Users List
Subject: Re: Ant Tasks Question

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick,

On 4/2/12 5:43 PM, Nick Williams wrote:
> As for the ant-i-fication of the JspC compiler, I, too get the
> impression that it was rather an afterthought. However, it is not
> necessary or even that common for tasks to be called *Task, as
> Konstantin pointed out. Most of them /aren't/ named *Task.

I was mostly gathering corroborating evidence to suggest that JspC being an
Ant task was not its original intent: it's mostly geared towards being a CLI
tool and has some support for Ant slapped-onto it.
I'm not sure why Konstantin got so agitated about my comments about the
class name: it's obviously the least significant part of my argument.

> I'm aware that I can translate and compile as separate tasks, but
> that's not what I was looking for. I actually DO want to translate and
> compile with the same task, because I want the Eclipse compiler
> shipped with Tomcat to be used for compiling the JSPs.

Well, you can already do that from within JspC (though the CLI doesn't
actually use it) by setting "compiler" to either
"org.apache.jasper.compiler.JDTCompiler" or
"org.apache.jasper.compiler.AntCompiler" (or really anything that implements
org.apache.jasper.compiler.Compiler). The default is to use the JDTCompiler
when the translate and compile steps are performed together. I have no idea
how to invoke the JDT compiler from the command-line given just the .jar
file that contains it: I suspect you'd be able to poke-around and figure out
how to do that as a separate Ant task, which might give you more
flexibility.

> But your comment helps me out in expressing my desire: I feel like it
> should be able to fork and use whatever JVM I specify for executing
> the JspC task, whether I'm using JspC for translation and compilation
> or just translation.

Fair enough. Just because I'm curious: why do you care which JVM is being
used for the translation step?

> I agree that fork support should be expected of a nice player in the
> Ant ecosystem.

I'll have to read the code for some of the built-in Ant tasks to see how
that's traditionally done. It might make sense for the Jasper and task to
become a separate class from JspC, even if it heavily utilizes JspC itself.
Ideally, JspC would be "merely" the CLI wrapper around a Compiler and a
separate class would handle the Ant-related stuff. I would even buy a common
superclass for the two, but it's often tough to tell what is there to
support Ant and what isn't.

> Maybe what we really need, instead of attempting to retrofit JspC to
> be more Task-y, is add a new Task to o.a.catalina.ant (JasperTask?
> JspCompileTask?) and trying to follow some better practices with the
> new practice. What are the community thoughts on this? I can see both
> upsides and downsides to doing this.

Heh. I should have read this first. I obviously agree.

> I'll file enhancement requests in Bugzilla later today or tomorrow for
> the namespace and forking issues.

I'll look for those.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk97AyIACgkQ9CaO5/Lv0PCWjwCeIIJh0Qp9iooqN0ZRa23YOI55
GUwAoJGNiPlt/IO7r2PffDcEKKtDgdTu
=qORp
-END PGP SIGNATURE-

-


I have filed issues 53031 and 53032 to go along with 53011 and 53012 that I
filed earlier. I look forward to working on them.

I don't really care what JVM is being used for the translation phase. The
reason I care what JVM is being used for the /compilation/ phase is that our
build machine has multiple JVMs (Java 6 32-bit, Java 7 32-bit, Java 6
64-bit, Java 7 64-bit). Our Ant script should be run only using the Java 7
64-bit JVM. However, everything else in the build script (java, javac,
junit, etc.) is configured to explicitly use the Java 7 JVM, so that if
anyone ever messed up the build agent and switched it to using Java 6 to run
Ant, everything would still compile under Java 7. Except that, in this case,
the Jasper task would suddenly be running under Java 6.

This isn't even a big issue for us, because if somebody messes up the build
configuration, that just needs to be fixed. I understand that I can separate
the translation phase from the compilation phase. But I want the compilation
phase to use the Eclipse compiler, just like if it was running under Tomcat,
and javac can't be configured to use the Eclipse compiler (that I know of).
Like I said, it's not even a big deal for us, but it seem

RE: Ant Tasks Question

[Nick Williams]

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Monday, April 02, 2012 4:24 PM
To: Tomcat Users List
Subject: Re: Ant Tasks Question

2012/4/3 Christopher Schultz :
>
> On 3/29/12 10:07 PM, Nick Williams wrote:
>> This works great for list, deploy, undeploy, stop, start, etc. All of
>> those tasks work. But the jasper/jasper2 tasks are weird. They
>> silently do nothing.
>
> Hmm. I've been playing around with the JspC intermittently for about a
> year, now, and I've noticed that the ant-i-fication of the JspC
> compiler seems to be a bit of an afterthought. For instance, the class
> that implements it isn't even called [something]Task.java.
>
> It's possible that this task in particular just doesn't work properly
> in a namespaced context. Can any ant experts comment on that?
>

Who cares how it is named?  There are hardly any built-in Ant tasks that
are named as *Task. See o.a.tools.ant.taskdefs package.


I think you just cannot load both TC6 and TC7 implementations at the same
time into the same classloader.

Either one implementation or the other should win (or you would just get a
mess).



>> Finally, there's the matter of specifying a JVM. Other java/javac
>> tasks allow you to specify an executable (javac)/jvm (java) to use
>> when executing the task. I can't find anything in the documentation
>> that reveals a way to do this with the Jasper tasks. Can the Jasper
>> tasks ONLY run in the same JVM as Ant?
>
> Obviously, you can compile the .java files that the precompiler
> produces by separating the translation (.jsp -> .java) and compilation
> (.java -> .class) into two separate steps (where the latter is
> , which can be customized in the way you describe). So, do you
> mean that you want to choose the JVM that is used when actually
> performing the translation step?
>
> It looks like JspC itself has a getFork() method that unconditionally
> returns false. I'm not sure /why/, but this task wasn't expected to be
> able to run in a forked context.
>
> Without knowing the reasons for the above, I would say that in general
> running in a forked context shouldn't be forbidden - rather it should
> be expected of a nice player in the ant ecosystem. It seems like
> generating a command-line from all the options taken from the ant
> attributes and stuff shouldn't be in impossible feat.
>
> Can you file an enhancement in bugzilla for both of these issues?

Let's discuss first.
Filing something is useless if it is loosely specified and if there is
little community interest in it.

Best regards,
Konstantin Kolinko

-


The point of namespaces (in Ant specifically and XML in general) /is/ to
avoid naming conflicts with like-named tasks. I successfully use
namespaces for accessing all of the other tasks for Tomcat 6 and 7 without
one or the other "winning"; there's no reason I shouldn't be able to do
the same with the JspC task.

For that matter, loading them both isn't even the issue, it appears. If I
remove the "tomcat6" namespace from my Ant file and /only/ have the
"tomcat7" namespace, "tomcat7:jasper" still doesn't work. Furthermore, if
I declare explicit tomcat6-jsp-compile and tomcat7-jsp-compile tasks in
the same Ant task, they /do/ both work perfectly and independently without
either of them "winning". So loading them both in the same Ant task isn't
the issue. Calling it from the namespace appears to be. Which is very odd.

I see no issues with discussing it a little more before filing Bugzillas.
However, I would point out that the Bugzilla enhancement request is
/exactly/ where you want to work on the specifications for the
enhancement, IMO. It provides a perfect repository for the discussion on
the specification for a particular issue.

Nick

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

RE: Ant Tasks Question

[Nick Williams]

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, April 02, 2012 3:31 PM
To: Tomcat Users List
Subject: Re: Ant Tasks Question

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick,

On 3/29/12 10:07 PM, Nick Williams wrote:
> This works great for list, deploy, undeploy, stop, start, etc. All of
> those tasks work. But the jasper/jasper2 tasks are weird. They
> silently do nothing.

Hmm. I've been playing around with the JspC intermittently for about a year,
now, and I've noticed that the ant-i-fication of the JspC compiler seems to
be a bit of an afterthought. For instance, the class that implements it
isn't even called [something]Task.java.

It's possible that this task in particular just doesn't work properly in a
namespaced context. Can any ant experts comment on that?

> Finally, there’s the matter of specifying a JVM. Other java/javac
> tasks allow you to specify an executable (javac)/jvm (java) to use
> when executing the task. I can’t find anything in the documentation
> that reveals a way to do this with the Jasper tasks. Can the Jasper
> tasks ONLY run in the same JVM as Ant?

Obviously, you can compile the .java files that the precompiler produces by
separating the translation (.jsp -> .java) and compilation (.java -> .class)
into two separate steps (where the latter is , which can be
customized in the way you describe). So, do you mean that you want to choose
the JVM that is used when actually performing the translation step?

It looks like JspC itself has a getFork() method that unconditionally
returns false. I'm not sure /why/, but this task wasn't expected to be able
to run in a forked context.

Without knowing the reasons for the above, I would say that in general
running in a forked context shouldn't be forbidden - rather it should be
expected of a nice player in the ant ecosystem. It seems like generating a
command-line from all the options taken from the ant attributes and stuff
shouldn't be in impossible feat.

Can you file an enhancement in bugzilla for both of these issues?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk96DJgACgkQ9CaO5/Lv0PCTwgCfc00h+M/g0IEK+7oaxQ8pq2yc
/C8AoKC9kMhWLlsCt/rsJFXzmpmf8SrW
=qK/l
-END PGP SIGNATURE-

-


As for the ant-i-fication of the JspC compiler, I, too get the impression
that it was rather an afterthought. However, it is not necessary or even
that common for tasks to be called *Task, as Konstantin pointed out. Most of
them /aren't/ named *Task. However, if you are basing your comment on
Tomcat's naming standard for Ant tasks, then you do have a valid point. JspC
is the only Tomcat task that isn't named *Task. For that matter, it's the
only Tomcat task that isn't in o.a.catalina.ant.

I'm aware that I can translate and compile as separate tasks, but that's not
what I was looking for. I actually DO want to translate and compile with the
same task, because I want the Eclipse compiler shipped with Tomcat to be
used for compiling the JSPs. But your comment helps me out in expressing my
desire: I feel like it should be able to fork and use whatever JVM I specify
for executing the JspC task, whether I'm using JspC for translation and
compilation or just translation.

I agree that fork support should be expected of a nice player in the Ant
ecosystem.

Maybe what we really need, instead of attempting to retrofit JspC to be more
Task-y, is add a new Task to o.a.catalina.ant (JasperTask? JspCompileTask?)
and trying to follow some better practices with the new practice. What are
the community thoughts on this? I can see both upsides and downsides to
doing this.

I'll file enhancement requests in Bugzilla later today or tomorrow for the
namespace and forking issues.

Thanks,

Nick

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

Ant Tasks Question

[Nick Williams]

We use both Tomcat 6 and 7 ant tasks in our build scripts. I don’t want to
declare every single task by hand (I can’t just use taskdef with
catalina.tasks, because Tomcat 6 and 7 tasks declare task names that
conflict with each other), so I use namespaces:



http://tomcat.apache.org/ant/tomcat/6";

xmlns:tomcat7="
http://tomcat.apache.org/ant/tomcat/7";>



…























http://tomcat.apache.org/ant/tomcat/6";


classpathref="tomcat.6.ant.classpath" />



http://tomcat.apache.org/ant/tomcat/7";


classpathref="tomcat.7.ant.classpath" />



…









…





This works great for list, deploy, undeploy, stop, start, etc. All of those
tasks work. But the jasper/jasper2 tasks are weird. They silently do
nothing.









Neither of these do anything. And by “nothing” I mean that I use `ant
-verbose` when running Ant, verbose=”1” within the Jasper tasks, and
there’s no output from the Jasper task, not a single line of
output/logging, and the build completes in 0 seconds with no compiled JSPs
output.



However, if I define the Jasper task explicitly, using the exact same paths
(as you can clearly see):















And call the Jasper tasks using the exact same options:







Everything works. It compiles 2,487 JSPs in 275s, and outputs exactly what
I expect, including 2,487 compiled JSPs and two logging messages. From what
I understand about Ant, there should be absolutely no difference, and yet
there apparently is, because they behave differently. Any idea what gives?



Then there’s the matter of the logging. The
tomcat7-jsp-compile/tomcat6-jsp-compile tasks (the only ones that work)
outputs two logging messages:



Mar 29, 2012 8:50:35 PM org.apache.jasper.compiler.TldLocationsCache
tldScanJar

INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable
debug logging for this logger for a complete list of JARs that were scanned
but no TLDs were found in them. Skipping unneeded JARs during scanning can
improve startup time and JSP compilation time.



However, they are output in such a way so as Ant sees them as warnings. So
when the Ant build completes, it completes “with 2 warnings.” If I set
verbose=”1” on the Jasper tasks, the Ant build completes “with 4976
warnings.” Obviously these aren’t warnings. Can something be done about the
output to keep it from registering as a warning?



Finally, there’s the matter of specifying a JVM. Other java/javac tasks
allow you to specify an executable (javac)/jvm (java) to use when executing
the task. I can’t find anything in the documentation that reveals a way to
do this with the Jasper tasks. Can the Jasper tasks ONLY run in the same
JVM as Ant?



Thanks,



Nick

RE: Precompile JSPs, avoid thousands of servlets?

[Nick Williams]

> Please tell me you are using the Tomcat precompiler

We didn't used to be doing ANY JSP precompilation, but now we are
precompiling during our continuous integration build using JspC and ANT.
We're still shipping uncompiled JSPs, but at least we're verifying
everything at build time now. We didn't even used to do that...

No, we are not trying to hit all of the URLs. Hah! 2,491 JSPs...

> It's amazing what people will write all by themselves.

Yes, indeed it is.

Nick


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, March 15, 2012 2:42 PM
To: Tomcat Users List
Subject: Re: Precompile JSPs, avoid thousands of servlets?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick,

On 3/15/12 2:29 PM, Nick Williams wrote:
>> It seems reasonable that Jasper could be separated from the core of
>> Tomcat.
>
> We may consider attempting integrating Jasper into our product at a
> later date to see if that works. Not in this version of the product,
> however.
>
>> Are you simply trying to reduce the first-access time of each JSP?
>
> The performance improvement is always nice, but irrelevant. That can
> be achieved with startup compilation. The bigger issue is making sure
> that all of our JSPs compile. We can compile them at build time, but
> that only guarantees they'll compile for that particular version of
> that particular server. At one point, we had two JSPs that would
> compile in Tomcat 5.5.26-5.5.33 and Tomcat 6.0.20-6.0.32, but not
> Tomcat 5.5 < 5.5.26, not Tomcat 6 > 6.0.32, and not Tomcat 7. We have
> since fixed this issue and are trying to bring our JSPs to a more
> stable state.

Gotcha. Please tell me you are using the Tomcat precompiler and not just
deploying the webapp and trying to hit all of the URLs. Tomcat has a
precompiler for (I believe) all currently-supported versions.

> (We didn't build this product from the ground up, by the way, just in
> case you were wondering. We acquired it from a single developer who
> had written all 1.1 million lines of code by himself, never shared the
> details of the code with anyone else, never used any 3rd-party
> frameworks, never used any design patterns, and had ported (read: not
> re-written) the project from Pascal to C++/MFC to Java/Java EE over
> the course of 20 years.)

I've been there. I was on a consulting gig once where we replaced about 70%
of the code of the product with 3rd-party OSS libraries that had been
written after the inception of the project, but the original developers
never had the inclination to switch. Things like logging frameworks, O-R
mappers, and even a rudimentary XSLT engine (but it wasn't called that at
the time).

It's amazing what people will write all by themselves.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9iRe0ACgkQ9CaO5/Lv0PCvrgCfes0V1ej1G1vuZkV+y+wqnuwH
rBQAn20yt4RZWIhLQBgGbHIC/+aX3rMl
=MGxB
-END PGP SIGNATURE-

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

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

RE: Precompile JSPs, avoid thousands of servlets?

[Nick Williams]

> It seems reasonable that Jasper could be separated from the core of
> Tomcat.

We may consider attempting integrating Jasper into our product at a later
date to see if that works. Not in this version of the product, however.

> Are you simply trying to reduce the first-access time of each JSP?

The performance improvement is always nice, but irrelevant. That can be
achieved with startup compilation. The bigger issue is making sure that all
of our JSPs compile. We can compile them at build time, but that only
guarantees they'll compile for that particular version of that particular
server. At one point, we had two JSPs that would compile in Tomcat
5.5.26-5.5.33 and Tomcat 6.0.20-6.0.32, but not Tomcat 5.5 < 5.5.26, not
Tomcat 6 > 6.0.32, and not Tomcat 7. We have since fixed this issue and are
trying to bring our JSPs to a more stable state.

(We didn't build this product from the ground up, by the way, just in case
you were wondering. We acquired it from a single developer who had written
all 1.1 million lines of code by himself, never shared the details of the
code with anyone else, never used any 3rd-party frameworks, never used any
design patterns, and had ported (read: not re-written) the project from
Pascal to C++/MFC to Java/Java EE over the course of 20 years.)

N

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Thursday, March 15, 2012 1:14 PM
To: Tomcat Users List
Subject: Re: Precompile JSPs, avoid thousands of servlets?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick,

On 3/15/12 1:21 PM, Nick Williams wrote:
>> Hmm... do you have complete control over the version of Tomcat that
>> your clients use?
>
> Unfortunately, we do not have complete control over this.

This doesn't look good for you :(

>> The JSP compiler uses Tomcat-specific classes and they are not part
>> of any public API...
>
> Yea, I just looked at the sources for the compiled JSPs and see that
> they're full of references to proprietary Tomcat classes.
> Looks like this is the case no matter which App Server I compile the
> JSPs with ... they end up full of classes from that App Server.
> I guess that makes sense, what with Tag Pooling and everything else.

Exactly: compiled JSPs are more than just raw scriptlets and tag-source
placed into a .java file and compiled. Since the JSP API defines mostly
interfaces and leaves it up to the containers to implement, this is
necessarily the case. There isn't even a standard API for launching a JSP
(other than calling "service"), though I'm sure everyone's implementation
looks basically the same. The fact is that each JSP is going to need a bunch
of support code that simply must come from the container.

There is another possibility: tear-out Jasper from Tomcat and write your own
JSPServlet that you map to *.jsp in your own webapp. It will probably be a
bunch of work, and you'll either have to keep it in sync with the Tomcat
sources or risk getting stale as bugs are fixed and improvements are made.

The advantage, though, is that you could package it with your webapp and the
it doesn't matter what container the client uses: the JSPs will run Jasper
no matter what.

I don't know how hard that would be -- I've never tried it :)

It seems reasonable that Jasper could be separated from the core of Tomcat.
I wonder if anyone else would be interested in such a clean separation.

>> ...though switching content-generation frameworks isn't a task I
>> would wish on a bitter enemy.
>
> Agreed. I wouldn't either.
>
> At this point, it looks like we're going to have to stick to shipping
> the raw JSP files in the application and having them be compiled by
> the container (either at startup or runtime ... one way or another).

There are several ways to trigger compilation at start up (or immediately
thereafter). Are you simply trying to reduce the first-access time of each
JSP? Or is this a solution looking for a real-world problem?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9iMYIACgkQ9CaO5/Lv0PAXOwCeP9hcYtRyOjM2HvCy9KqetMOG
NBcAoKCPHBlNwovMEOw/o4ejU/s+SpML
=arEm
-END PGP SIGNATURE-

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

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

RE: Precompile JSPs, avoid thousands of servlets?

[Nick Williams]

Terence,

In addition to my previous reply to Chris, most of our JSPs are not SUPPOSED
to be accessed as web pages, although some are meant to be. Also,
unfortunately, all of them ARE accessible as web pages due to bad design
(something I intend to change).

Nick


-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com]
Sent: Tuesday, March 13, 2012 1:46 PM
To: Tomcat Users List
Subject: Re: Precompile JSPs, avoid thousands of servlets?

  On 1:59 PM, Nick Williams wrote:
> We maintain a very large application, with somewhere around 2,000 JSP
> files (in addition to ~250,000 lines of pure Java). We have decided it
> is about time we ship our application with precompiled JSP files.
>
>
>
> The Ant tasks from Tomcat to support this effort have been extremely
> helpful, and I have no serious complaints about them. We can even use
> our own package name for the JSPs. Great!
>
>
>
> Our first challenge is that we support Tomcat, GlassFish, WebLogic and
> WebSphere, so our JSPs have to be precompiled in such a way that they
> will run in any of those web containers. We’ll overcome that challenge
> I’m sure; if we have to include some extra libraries, we’ll make it work.
>
>
>
> Our second  challenge is the 11,500-line web.xml file that results
> from this process. I understand that Ant does a lot of the hard work
> for me, but a web.xml file this large bothers me, even if I don’t have
> to look at it during every day development. What’s more, we’re
> actually trying to *move
> away* from having a web.xml file (of any real substance) and using new
> Servlet 3.0 features.
>
>
>
> I could swear I saw an example a while ago (while searching Google, of
> course) of a web.xml file with a single servlet that responded to
> requests for ALL JSPs that had be precompiled, but I can’t find it
> anywhere anymore.
> I’m sure I *could* write my own servlet to accomplish this, but I’d
> sure like to use something existing that already has common usage.
>
>
>
> Does anyone have any ideas?
>


At least web.xml is auto-generated.  Are all of the JSPs accessible as web
pages?  What I've seen uses annotations and then you have to live with the
startup time.

-Terence Bandoian

P.S. Sorry about the direct e-mail.

-
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: Precompile JSPs, avoid thousands of servlets?

[Nick Williams]

> Hmm... do you have complete control over the version of Tomcat that your
> clients use?

Unfortunately, we do not have complete control over this.

> The JSP compiler uses Tomcat-specific classes and they are not part of any
> public API...

Yea, I just looked at the sources for the compiled JSPs and see that they're
full of references to proprietary Tomcat classes. Looks like this is the
case no matter which App Server I compile the JSPs with ... they end up full
of classes from that App Server. I guess that makes sense, what with Tag
Pooling and everything else.

> ...though switching content-generation frameworks isn't a task I would
> wish on a bitter enemy.

Agreed. I wouldn't either.

At this point, it looks like we're going to have to stick to shipping the
raw JSP files in the application and having them be compiled by the
container (either at startup or runtime ... one way or another).

> My recommendation would be to stick with a single monolithic web.xml...

Thanks for the recommendation, but I guess it's moot now.

Y'all have all been a lot of help. Thanks!

Nick


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Monday, March 12, 2012 9:48 PM
To: Tomcat Users List
Subject: Re: Precompile JSPs, avoid thousands of servlets?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick,

On 3/12/12 4:43 PM, Nick Williams wrote:
> We maintain a very large application, with somewhere around 2,000 JSP
> files (in addition to ~250,000 lines of pure Java). We have decided it
> is about time we ship our application with precompiled JSP files.

Hmm... do you have complete control over the version of Tomcat that your
clients use?

> Our first challenge is that we support Tomcat, GlassFish, WebLogic and
> WebSphere, so our JSPs have to be precompiled in such a way that they
> will run in any of those web containers. We’ll overcome that challenge
> I’m sure; if we have to include some extra libraries, we’ll make it
> work.

You are toast, as far as Tomcat's precompiler is concerned. The JSP compiler
uses Tomcat-specific classes and they are not part of any public API (that
is, not stable) so they are very sensitive to the exact version of Tomcat --
sometimes down to the point release (like
7.0.22 and 7.0.23 might be incompatible).

My recommendation would be to allow your webapp to be precompiled at (or,
rather, immediately before) deploy-time by providing different procedures
(maybe ant tasks?) for each container.

> Our second  challenge is the 11,500-line web.xml file that results
> from this process. I understand that Ant does a lot of the hard work
> for me, but a web.xml file this large bothers me, even if I don’t have
> to look at it during every day development. What’s more, we’re
> actually trying to *move away* from having a web.xml file (of any real
> substance) and using new Servlet 3.0 features.

Note that there are glaring problems with web-fragments including questions
about precedence in the face of conflicts for things like overlapping
url-patterns, etc. My recommendation would be to stick with a single
monolithic web.xml except in cases where you have a definite isolated chunk
of features that can be encapsulated into a separate JAR file.

> I could swear I saw an example a while ago (while searching Google, of
> course) of a web.xml file with a single servlet that responded to
> requests for ALL JSPs that had be precompiled, but I can’t find it
> anywhere anymore. I’m sure I *could* write my own servlet to
> accomplish this, but I’d sure like to use something existing that
> already has common usage.

Maybe the "invoker" servlet? I'm not entirely sure if I'm kidding, actually.

> Does anyone have any ideas?

Perhaps JSP isn't the best solution for you... how much dynamic-ness do you
need in all these content-generating files? Maybe another technology
(Freemarker? I don't think Velocity has a precompiler...) would meet you
needs better than JSP, though switching content-generation frameworks isn't
a task I would wish on a bitter enemy).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9etWwACgkQ9CaO5/Lv0PBFMwCgoiB1f1TERHAwtEaLm+zgBq2X
MQEAniSMx+hMCqTUuuIev1Ruehn0DK3x
=AbQf
-END PGP SIGNATURE-

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

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

RE: Tomcat, JSP and LDAP

[Nick Williams]

Just a thought ... Spring Security
(http://static.springsource.org/spring-security/site/) is a fabulous
framework for LDAP authentication AND authorization (we're using it
currently with our Windows domain), doesn't require any changes to the app
server or web server, and is relatively easy to get set up and working.

And it's okay if your project is mainly JSPs, because SS can do security
restrictions based on URL patterns, class names, method names, etc.

Just an idea. Beyond Spring Security, I have pretty much no LDAP experience
or knowledge at all. But I was able to get SS up and running in less than a
day.

N

-- 
Nick Williams | Senior Software Developer
UL PureSafety
Health & Safety Software Solutions
Toll Free: 888.202.3016 x 177  |  Direct: 615.277.3177  |  Fax: 615.367.3887
730 Cool Springs Blvd, Suite 400  |  Franklin, TN 37067  |
www.puresafety.com  |  www.ul.com

UL acquired PureSafety on December 6, 2011. Learn More.

-Original Message-
From: Neil Munro [mailto:neilmu...@gmail.com]
Sent: Thursday, March 15, 2012 11:22 AM
To: users@tomcat.apache.org
Subject: Tomcat, JSP and LDAP

Hi all,
 I am trying to implement a means to authenticate a user on a web
app via ldap, I have been trying for some time and am now intimately
familiar with the files I need to edit, but not exactly how.

I know that much of the ldap stuff goes into the server.xml file inside of
the tomcat conf directory, it is here I have been trying to configure an
ldap realm. I have attached the files I have been working with, the basic
idea is that a user must first log on before they can access any area of the
site, also all users can log in, and access all areas of the site.

A user is presented with the login page, and if they cannot be authenticated
they are alerted and are given the option to redirect back to the login
page. Which I have working, thought I think that's simply because I cannot
get the logging in bit work.

I do not have access to the LDAP server or schema and cannot implement
changes to that, I can however alter the tomcat server, jsp files etc.
I am trying to write a company wide web app, and have free reign, but it's
historically been written in jsp so we want to keep as much of that as we
can.

Software and versions: Tomcat 6.0.35, Java 1.4 through to 1.7 (I am required
to have all installed) and Windows 7 64.

Any help would be fantastic as I have read lots of resources but there's no
definitive tutorial to set such a thing up.

Thanks,
Neil Munro

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

Precompile JSPs, avoid thousands of servlets?

[Nick Williams]

We maintain a very large application, with somewhere around 2,000 JSP files
(in addition to ~250,000 lines of pure Java). We have decided it is about
time we ship our application with precompiled JSP files.



The Ant tasks from Tomcat to support this effort have been extremely
helpful, and I have no serious complaints about them. We can even use our
own package name for the JSPs. Great!



Our first challenge is that we support Tomcat, GlassFish, WebLogic and
WebSphere, so our JSPs have to be precompiled in such a way that they will
run in any of those web containers. We’ll overcome that challenge I’m sure;
if we have to include some extra libraries, we’ll make it work.



Our second  challenge is the 11,500-line web.xml file that results from
this process. I understand that Ant does a lot of the hard work for me, but
a web.xml file this large bothers me, even if I don’t have to look at it
during every day development. What’s more, we’re actually trying to *move
away* from having a web.xml file (of any real substance) and using new
Servlet 3.0 features.



I could swear I saw an example a while ago (while searching Google, of
course) of a web.xml file with a single servlet that responded to requests
for ALL JSPs that had be precompiled, but I can’t find it anywhere anymore.
I’m sure I *could* write my own servlet to accomplish this, but I’d sure
like to use something existing that already has common usage.



Does anyone have any ideas?

RE: SEVERE: The web application created a ThreadLocal (but I removed it)

[Nick Williams]

We acquired a product with about a million lines of code. The original
author had no formal software design education and had ported the product
from Pascal to C++ to Java EE. There are many interesting designs in the
code, and no separation of control by any measure. We have a multi-year
roadmap in place to reengineer the software, but it’s going to be a gradual
process, and the transition will involve many temporary “hacks” so to speak.



The use of ThreadLocals in several places helps us achieve the
reengineering in that we can design interfaces now that don’t require us to
pass around some of the “God objects” we’re trying to get rid of, while
still using them in the temporary implementations of these interfaces.
Unfortunately, the use of ThreadLocals was, at first, rather halphazard and
uneducated by some members of the team.



With that said, after spending about another day looking through code,
there really just were a few other places that ThreadLocals were being
set() but not remove()d. I have now resolved all memory leak issues Tomcat
was reporting. This will be followed up by a heavy dose of education for
the team about when it is and isn’t appropriate to use ThreadLocals during
this reengineering phase.



Thanks for responding!



Nick



-- 
*Nick Williams |* Senior Software Developer

*UL PureSafety*
Health & Safety Software Solutions

Toll Free: 888.202.3016 x 177  |  Direct: 615.277.3177  |  Fax: 615.367.3887
730 Cool Springs Blvd, Suite 400  |  Franklin, TN 37067  |
www.puresafety.com  |  www.ul.com
--

*UL acquired PureSafety on December 6, 2011. Learn
More.<http://www.puresafety.com/public/knowledge-exchange/news/2011/12/06/ul-expands-occupational-health-safety-presence-training-capabilit>
*





-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Sunday, February 26, 2012 8:45 PM
To: Tomcat Users List
Subject: Re: SEVERE: The web application created a ThreadLocal (but I
removed it)



-BEGIN PGP SIGNED MESSAGE-

Hash: SHA1



Nick,



On 2/22/12 7:52 PM, Nick Williams wrote:

> Now, at the end of each request, I am calling:

>

> threadLocalInstance.set(null);

>

> threadLocalInstance.remove();



If you are creating a ThreadLocal for each request (that needs the

object) and then disposing of it, why bother with the ThreadLocal in the
first place? Is this a case of wanting global-variable semantics and just
being lazy about (not) passing arguments around?



> I’m still getting these four messages, and I can’t seem to get them to

> go away. But I have tracked down these specific instances and I

> *am* calling set(null) and remove() on these instances.



Does it always happen? Perhaps you are encountering an exception and your
.remove() isn't being called in certain cases. Consider a 'finally' block?



> Is something about the Tomcat code somehow locating “phantom”

> references to ThreadLocals that have actually been removed and ARE

> really eligible for GC, or am I really just not always clearing those

> ThreadLocals and I just still haven’t tracked down the source?



Tomcat just looks at the ThreadLocals still left over in a Thread after
your webapp is stopped. There's nothing "phantom" about them.



- -chris

-BEGIN PGP SIGNATURE-

Version: GnuPG/MacGPG2 v2.0.17 (Darwin)

Comment: GPGTools - http://gpgtools.org

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/



iEYEARECAAYFAk9K7icACgkQ9CaO5/Lv0PBFsgCfT1Y+Mj4C40rwNUAp1wk38e+e

m1IAn22T17lUBZAQ3t9zYBoll5TzEL30

=3Ndj

-END PGP SIGNATURE-



-

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

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

SEVERE: The web application created a ThreadLocal (but I removed it)

[Nick Williams]

I have been getting the ThreadLocal cleanup warning messages appearing in
the Tomcat log for some time now. I finally got around to investigating
these and cleaning it all up. Most of the ThreadLocals I removed, because
they were being abused. However, some needed to hang around, so I used them
more carefully.



Now, at the end of each request, I am calling:



threadLocalInstance.set(null);

threadLocalInstance.remove();



And most of the messages went away. However, a few were still sticking
around. I wanted to track them down, but that’s hard since ThreadLocals
don’t have names. So, I replaced all instances of ThreadLocal in my project
with Spring Framework’s NamedThreadLocal (which simply overrides toString()
to provide better debugging), and here is the resulting log:



Feb 22, 2012 6:21:23 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap

SEVERE: The web application [/xxx] created a ThreadLocal with key of type
[org.springframework.core.NamedThreadLocal] (value
[GridDataHandler:reminders]) and a value of type [MyPackage.MyClass] (value
[MyPackage.MyClass @1068452]) but failed to remove it when the web
application was stopped. This is very likely to create a memory leak.

Feb 22, 2012 6:21:23 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap

SEVERE: The web application [/xxx] created a ThreadLocal with key of type
[org.springframework.core.NamedThreadLocal] (value
[GridDataHandler:accidentinvestigation]) and a value of type
[MyPackage.MyClass] (value [MyPackage.MyClass @d92404]) but failed to
remove it when the web application was stopped. This is very likely to
create a memory leak.

Feb 22, 2012 6:21:23 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap

SEVERE: The web application [/xxx] created a ThreadLocal with key of type
[org.springframework.core.NamedThreadLocal] (value
[GridDataHandler:encounterlisting]) and a value of type [MyPackage.MyClass]
(value [MyPackage.MyClass @1cbad1a]) but failed to remove it when the web
application was stopped. This is very likely to create a memory leak.

Feb 22, 2012 6:21:23 PM org.apache.catalina.loader.WebappClassLoader
clearThreadLocalMap

SEVERE: The web application [/xxx] created a ThreadLocal with key of type
[org.springframework.core.NamedThreadLocal] (value
[GridDataHandler:reminders]) and a value of type [MyPackage.MyClass] (value
[MyPackage.MyClass @d19d73]) but failed to remove it when the web
application was stopped. This is very likely to create a memory leak.



I’m still getting these four messages, and I can’t seem to get them to go
away. But I have tracked down these specific instances and I *am* calling
set(null) and remove() on these instances.



Is something about the Tomcat code somehow locating “phantom” references to
ThreadLocals that have actually been removed and ARE really eligible for
GC, or am I really just not always clearing those ThreadLocals and I just
still haven’t tracked down the source?



Thanks,



Nick



-- 
*Nick Williams |* Senior Software Developer

*UL PureSafety*
Health & Safety Software Solutions

Toll Free: 888.202.3016 x 177  |  Direct: 615.277.3177  |  Fax: 615.367.3887
730 Cool Springs Blvd, Suite 400  |  Franklin, TN 37067  |
www.puresafety.com  |  www.ul.com
--

*UL acquired PureSafety on December 6, 2011. Learn
More.<http://www.puresafety.com/public/knowledge-exchange/news/2011/12/06/ul-expands-occupational-health-safety-presence-training-capabilit>
*

RE: JK Connector failure after IIS recycle - version 1.2.30

[Nick Williams]

Thanks for the insight. I'll give it a little more time, but I'm being
pushed by my superiors here for an answer that I can't give, so I'll have
to file a bug before long.

Does anyone know if there are any other (open source OR commercial/paid)
alternatives to integrating Tomcat with IIS and/or Apache?

N

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Wednesday, May 25, 2011 3:49 PM
To: Tomcat Users List
Subject: Re: JK Connector failure after IIS recycle - version 1.2.30

Nick Williams wrote:
> Does anyone have any feeback? Do I need to report a bug?
>

My own experience with this list, is that when someone reports an issue or
asks a question
which fits with the knowledge or experience of the people on the list,
usually the
reaction time is short.  So the fact that nobody has answered within the
last 3 working
days is unusual, and may be just an indication that nobody has a clue.
On the other hand, it may just mean that none of the relatively few people
qualified to
answer has been around yet, or has seen your original post.

About the bug report : I suppose you could, but 3 working days since the
initial problem
report may be a bit premature for an issue which, by your own description,
sounds for now
like a one-off and difficult for you or someone else to reproduce.



-
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