You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Williams, Nick" <ni...@ul.com> on 2013/02/11 02:05:17 UTC
EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
As some of you know, I've been experimenting with Tomcat trunk (8.0) and the latest specs. I understand, of course, that this is all far from complete. While playing around this weekend, I noticed three things:
- Tomcat trunk still has EL 2.2 instead of the new EL 3.0
- javax.servlet.http.HttpSessionIdListener (possibly others, this is just the one I noticed) is missing from servlet-api.jar
- HttpServletRequest#changeSessionId() is not yet implemented
Is anyone on the list currently working on any of these three things, and if so, do you have any idea when some reasonably-stable iteration of them will be checked in to trunk?
Of course, I know it's entirely possible that simply nobody has even looked at them yet, and that's understandable this early in the game.
Nick
This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
RE: EL 3.0, HttpSessionIdListener,
HttpServletRequest#changeSessionId()
Posted by "Williams, Nick" <ni...@ul.com>.
(I'm replying to both your emails here. Forgive me.)
-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org]
Sent: Monday, February 11, 2013 2:38 PM
To: Tomcat Developers List
Subject: Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
>> Fascinating. Years ago I used to think the "spec" included a bunch of
>> already-compiled interfaces and you just copied the spec jar to your
>> implementation and then implemented the spec. I got the idea a while
>> ago that it wasn't quite that simple, but I had no idea y'all
>> literally just wrote the javax.* interfaces and classes from scratch
>> based on the spec.
>
>We have to so we have an ALv2 licensed version of the API.
Makes sense.
>> Is the spec repository public? I looked around a bit and I found some
>> jars (or is that what you meant, since you're using javap?), but no
>> repository.
>
>http://java.net/projects/servlet-spec/
>
>You'll almost certainly need to register to access it but it should be readable once you do.
Low and behold, I was already registered and didn't know it. Unfortunately, "You are not allowed to do that (read scm)."
>I argued for (and got) a name change from ProtocolHandler to HttpUpgradeHandler that hasn't been implemented yet. Name changes are usually easier for committers to handle though the IDE since the effort is minimal but the diff can be big and reviewing a large diff is a pain.
>
>I've just implemented this.
I noticed. Five minutes after I did all of my analysis there was this HUGE check-in by someone named Mark T that invalidated it all. :-P
>I haven't done anything about the method signature change.
Yea, I figure that requires some more work yet. By the way, the HttpUpgradeHandler you checked in is missing the public abstract void destroy() method, but I'm sure you probably already knew that.
>> javax.servlet.http.HttpServletRequestWrapper: changeSessionId()
>> missing
>Yep. Missing feature.
I'll work on this one.
>> javax.servlet.http.HttpSessionIdListener: missing in Tomcat
And this one as well, since it goes with changeSessionId()
>> javax.servlet.http.HttpUpgradeHandler: missing in Tomcat
>Missing features.
Not anymore, you just added it. :-)
<snip />
The diff since your lash check-ins shows it to be much closer to the spec now.
This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
Posted by Mark Thomas <ma...@apache.org>.
On 11/02/2013 19:38, Williams, Nick wrote:
> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Monday, February 11, 2013 10:46 AM
> To: Tomcat Developers List
> Subject: Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
>
>> For WebSocket I automate it a little by using javap on the spec repository and on Tomcat and then fixing the diffs to the public API by hand.
>
> Here's what I did. Tell me if this sounds about right. I may be way off base here.
Looks OK to me.
<snip/>
> I then compared servlet-api.jar.contents and javax.servlet-api-3.1-b05.jar.contents (I used FileMerge) and came up with this:
>
> javax.servlet.http.HttpServletRequest: changeSessionId() missing in Tomcat
Yep.
> javax.servlet.http.HttpServletRequest: public abstract void upgrade(javax.servlet.http.ProtocolHandler) throws IOException in Tomcat should be:
> public abstract <T extends javax.servlet.http.HttpUpgradeHandler> T upgrade(java.lang.Class<T>) throws IOException
I argued for (and got) a name change from ProtocolHandler to
HttpUpgradeHandler that hasn't been implemented yet. Name changes are
usually easier for committers to handle though the IDE since the effort
is minimal but the diff can be big and reviewing a large diff is a pain.
I've just implemented this.
I haven't done anything about the method signature change.
> javax.servlet.http.HttpServletRequestWrapper: changeSessionId() missing
Yep. Missing feature.
> javax.servlet.http.HttpServletRequestWrapper: public void upgrade(javax.servlet.http.ProtocolHandler) throws IOException in Tomcat should be:
> public <T extends javax.servlet.http.HttpUpgradeHandler> T upgrade(java.lang.Class<T>) throws IOException
> javax.servlet.http.HttpSessionIdListener: missing in Tomcat
> javax.servlet.http.HttpUpgradeHandler: missing in Tomcat
Missing features.
> javax.servlet.http.NoBodyOutputStream: public boolean canWrite() in Tomcat should be:
> public boolean isReady()
Another naming change that I hadn't caught up with. Done.
> javax.servlet.http.NoBodyResponse: overridden method setContentLengthLong(long) in Tomcat is not overridden in spec
> javax.servlet.http.NoBodyResponse: overridden method setHeader(String, String) in Tomcat is not overridden in spec
> javax.servlet.http.NoBodyResponse: overridden method addheader(String, String) in Tomcat is not overridden in spec
> javax.servlet.http.NoBodyResponse: overridden method setIntHeader(String, int) in Tomcat is not overridden in spec
> javax.servlet.http.NoBodyResponse: overridden method addIntHeader(String, int) in Tomcat is not overridden in spec
Not an issue.
> javax.servlet.http.NoBodyResponse: static initializer in spec not present in Tomcat (is this even a problem?)
This sort of thing is not an issue. It is only public and protected API
we need to worry about.
> javax.servlet.http.ProtocolHandler: superfluous Tomcat class does not exist in specification
See above.
> javax.servlet.http.WebConnection: should extend java.lang.AutoCloseable, does not in Tomcat
Missing feature.
> javax.servlet.GenericServlet: static initializer in spec not present in Tomcat (is this even a problem?)
> javax.servlet.HttpConstraintElement: static initializer in Tomcat not present in spec (is this even a problem?)
> javax.servlet.HttpMethodConstraintElement: static initializer in Tomcat not present in spec (is this even a problem?)
See above.
> javax.servlet.ServletOutputStream: public boolean canWrite() in Tomcat should be:
> public boolean isReady()
Rename. See above. Fixed.
> A lot of that is WebSocket related, methinks (upgrade, upgrade handler, no body response, protocol handler), so those are yours, and I don't think the static initializers matter (though I could be wrong). The rest of it (change session ID, session ID change listener, WebConnection needing to extend AutoCloseable, and the two canWrites needing to be isReady) seem like some pretty simple things that I could knock out in one evening, assuming my contributions wouldn't be stepping on anyone's toes.
Nope. This is all Servlet 3.1 stuff.
> Before I actually do any work on anything I'd love some feedback on my analysis.
See above.
The biggest part of the work in Servlet 3.1 is the non-blocking IO
support. Filip wrote an implementation for NIO only. The other two
connectors are not implemented. Further, after using the non-blocking IO
for WebSockets I think there is a issue in that the underlying
assumption that there is only ever one thread accessing a socket is not
correct. Removing that limitation in the main connector code is going to
be non-trivial.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: EL 3.0, HttpSessionIdListener,
HttpServletRequest#changeSessionId()
Posted by "Williams, Nick" <ni...@ul.com>.
-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org]
Sent: Monday, February 11, 2013 10:46 AM
To: Tomcat Developers List
Subject: Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
> For WebSocket I automate it a little by using javap on the spec repository and on Tomcat and then fixing the diffs to the public API by hand.
Here's what I did. Tell me if this sounds about right. I may be way off base here.
I compiled Tomcat trunk from latest and copied servlet-api.jar and javax.servlet-api-3.1-b05.jar (from Maven, updated January 10) into the same directory.
I ran the following commands, which gave me an "index" of sorts of the classes in the JAR files.
jar -tf servlet-api.jar | grep class | sed 's/.class//g' > servlet-api.jar.index
jar -tf javax.servlet-api-3.1-b05.jar | grep class | sed 's/.class//g' > javax.servlet-api-3.1-b05.jar.index
I then re-ordered the files in one of the index files so that they were in the same order (the one compiled on my system had sub-directories before files, the other one didn't, so that would throw off a compare).
I then ran javap against both JAR files:
javap -classpath servlet-api.jar -s $(cat servlet-api.jar.index) > servlet-api.jar.contents
javap -classpath javax.servlet-api-3.1-b05.jar -s $(cat javax.servlet-api-3.1-b05.jar.index) > javax.servlet-api-3.1-b05.jar.contents
I then compared servlet-api.jar.contents and javax.servlet-api-3.1-b05.jar.contents (I used FileMerge) and came up with this:
javax.servlet.http.HttpServletRequest: changeSessionId() missing in Tomcat
javax.servlet.http.HttpServletRequest: public abstract void upgrade(javax.servlet.http.ProtocolHandler) throws IOException in Tomcat should be:
public abstract <T extends javax.servlet.http.HttpUpgradeHandler> T upgrade(java.lang.Class<T>) throws IOException
javax.servlet.http.HttpServletRequestWrapper: changeSessionId() missing
javax.servlet.http.HttpServletRequestWrapper: public void upgrade(javax.servlet.http.ProtocolHandler) throws IOException in Tomcat should be:
public <T extends javax.servlet.http.HttpUpgradeHandler> T upgrade(java.lang.Class<T>) throws IOException
javax.servlet.http.HttpSessionIdListener: missing in Tomcat
javax.servlet.http.HttpUpgradeHandler: missing in Tomcat
javax.servlet.http.NoBodyOutputStream: public boolean canWrite() in Tomcat should be:
public boolean isReady()
javax.servlet.http.NoBodyResponse: overridden method setContentLengthLong(long) in Tomcat is not overridden in spec
javax.servlet.http.NoBodyResponse: overridden method setHeader(String, String) in Tomcat is not overridden in spec
javax.servlet.http.NoBodyResponse: overridden method addheader(String, String) in Tomcat is not overridden in spec
javax.servlet.http.NoBodyResponse: overridden method setIntHeader(String, int) in Tomcat is not overridden in spec
javax.servlet.http.NoBodyResponse: overridden method addIntHeader(String, int) in Tomcat is not overridden in spec
javax.servlet.http.NoBodyResponse: static initializer in spec not present in Tomcat (is this even a problem?)
javax.servlet.http.ProtocolHandler: superfluous Tomcat class does not exist in specification
javax.servlet.http.WebConnection: should extend java.lang.AutoCloseable, does not in Tomcat
javax.servlet.GenericServlet: static initializer in spec not present in Tomcat (is this even a problem?)
javax.servlet.HttpConstraintElement: static initializer in Tomcat not present in spec (is this even a problem?)
javax.servlet.HttpMethodConstraintElement: static initializer in Tomcat not present in spec (is this even a problem?)
javax.servlet.ServletOutputStream: public boolean canWrite() in Tomcat should be:
public boolean isReady()
A lot of that is WebSocket related, methinks (upgrade, upgrade handler, no body response, protocol handler), so those are yours, and I don't think the static initializers matter (though I could be wrong). The rest of it (change session ID, session ID change listener, WebConnection needing to extend AutoCloseable, and the two canWrites needing to be isReady) seem like some pretty simple things that I could knock out in one evening, assuming my contributions wouldn't be stepping on anyone's toes.
Before I actually do any work on anything I'd love some feedback on my analysis.
Nick
This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
Posted by Mark Thomas <ma...@apache.org>.
On 11/02/2013 18:22, Williams, Nick wrote:
> -----Original Message----- From: Mark Thomas
> [mailto:markt@apache.org] Sent: Monday, February 11, 2013 10:46 AM
> To: Tomcat Developers List Subject: Re: EL 3.0,
> HttpSessionIdListener, HttpServletRequest#changeSessionId()
>
>>> 1) Where do y'all get the javax.* code that's in your
>>> repository?
>>
>> The sources have varied over time (at one point Tomcat was the
>> reference implementation).
>>
>> These days it is essentially a manual process to create them from
>> the spec.
>
> Fascinating. Years ago I used to think the "spec" included a bunch of
> already-compiled interfaces and you just copied the spec jar to your
> implementation and then implemented the spec. I got the idea a while
> ago that it wasn't quite that simple, but I had no idea y'all
> literally just wrote the javax.* interfaces and classes from scratch
> based on the spec.
We have to so we have an ALv2 licensed version of the API.
>> For WebSocket I automate it a little by using javap on the spec
>> repository and on Tomcat and then fixing the diffs to the public
>> API by hand.
>
> Is the spec repository public? I looked around a bit and I found some
> jars (or is that what you meant, since you're using javap?), but no
> repository.
http://java.net/projects/servlet-spec/
You'll almost certainly need to register to access it but it should be
readable once you do.
Mark
>
>> Take a look at the svn history for the Servlet 3.0 files.
>
> I just did. That was very helpful, thanks.
>
> Nick
>
>
> This e-mail may contain privileged or confidential information. If
> you are not the intended recipient: (1) you may not disclose, use,
> distribute, copy or rely upon this message or attachment(s); and (2)
> please notify the sender by reply e-mail, and then delete this
> message and its attachment(s). Underwriters Laboratories Inc. and its
> affiliates disclaim all liability for any errors, omissions,
> corruption or virus in this message or any attachments.
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: EL 3.0, HttpSessionIdListener,
HttpServletRequest#changeSessionId()
Posted by "Williams, Nick" <ni...@ul.com>.
-----Original Message-----
From: Mark Thomas [mailto:markt@apache.org]
Sent: Monday, February 11, 2013 10:46 AM
To: Tomcat Developers List
Subject: Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
>> 1) Where do y'all get the javax.* code that's in your repository?
>
>The sources have varied over time (at one point Tomcat was the reference implementation).
>
>These days it is essentially a manual process to create them from the spec.
Fascinating. Years ago I used to think the "spec" included a bunch of already-compiled interfaces and you just copied the spec jar to your implementation and then implemented the spec. I got the idea a while ago that it wasn't quite that simple, but I had no idea y'all literally just wrote the javax.* interfaces and classes from scratch based on the spec.
>For WebSocket I automate it a little by using javap on the spec repository and on Tomcat and then fixing the diffs to the public API by hand.
Is the spec repository public? I looked around a bit and I found some jars (or is that what you meant, since you're using javap?), but no repository.
> Take a look at the svn history for the Servlet 3.0 files.
I just did. That was very helpful, thanks.
Nick
This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
Posted by Mark Thomas <ma...@apache.org>.
On 11/02/2013 16:00, Williams, Nick wrote:
> 1) Where do y'all get the javax.* code that's in your repository?
The sources have varied over time (at one point Tomcat was the reference
implementation).
These days it is essentially a manual process to create them from the
spec. For WebSocket I automate it a little by using javap on the spec
repository and on Tomcat and then fixing the diffs to the public API by
hand.
> 2) Where do y'all get the XSD files in
> http://svn.apache.org/repos/asf/tomcat/trunk/java/javax/servlet/resources/
Again, sources have varied over time.
They aren't required unless XML validation is enabled so we tend to add
them once the spec is final. We add the CDDL licensed versions and make
sure the LICENCE and NOTICE file are updated as necessary. Take a look
at the svn history for the Servlet 3.0 files.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: EL 3.0, HttpSessionIdListener,
HttpServletRequest#changeSessionId()
Posted by "Williams, Nick" <ni...@ul.com>.
> On 11/02/2013 01:05, Williams, Nick wrote:
>> As some of you know, I've been experimenting with Tomcat trunk (8.0)
>> and the latest specs. I understand, of course, that this is all far
>> from complete. While playing around this weekend, I noticed three
>> things:
>>
>>
>> - Tomcat trunk still has EL 2.2 instead of the new EL 3.0
>>
>> - javax.servlet.http.HttpSessionIdListener (possibly others,
>> this is just the one I noticed) is missing from servlet-api.jar
>>
>> - HttpServletRequest#changeSessionId() is not yet
>> implemented
>>
>> Is anyone on the list currently working on any of these three things,
>
>Not to my knowledge.
>
>> and if so, do you have any idea when some reasonably-stable iteration
>> of them will be checked in to trunk?
>
>EL 3.0 will be a fair amount of work. The ID change stuff is trivial.
Yea. I read the EL 3.0 specification last night. The lambda expressions and LINQ support are pretty cool, but I can definitely see how that's going to be a LOT of work...
Agreed that the ID change stuff is trivial. I was thinking about writing the change myself and submitting it to the list. I looked through the "Get Involved" section of the website and found info about submitting patches, code formatting, tools to use, etc. However, there's not a whole lot of info on "working on the next specification." If someone has the time to indulge me, I had a couple questions, like:
1) Where do y'all get the javax.* code that's in your repository? Do you write it from scratch based on the spec, or do you download it from somewhere? It's obviously not consistent with the classes in the javax.servlet:javax.servlet-api:3.1-b05 Maven artifact, but I don't know what's involved in updating that.
2) Where do y'all get the XSD files in http://svn.apache.org/repos/asf/tomcat/trunk/java/javax/servlet/resources/ and what's involved in adding new ones / updating? I noticed the Servlet 3.1 XSDs have not been added yet (which was surprising to me, since the deployment descriptor in my web app using web-app_3_1.xsd works). Don't know if just nobody has gotten around to it yet, or if there's a specific reason they're not there yet (Do you always wait until the spec is final? Do you put beta XSDs in there during development and update when the spec goes final?). There are 3.1 XSDs at http://java.net/nonav/projects/glassfish/sources/svn/show/trunk/main/appserver/deployment/schemas/src/main/resources/glassfish/lib/schemas, but that's just a guess.
Nick
>
>Mark
This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
Posted by Mark Thomas <ma...@apache.org>.
On 11/02/2013 01:05, Williams, Nick wrote:
> As some of you know, I've been experimenting with Tomcat trunk (8.0)
> and the latest specs. I understand, of course, that this is all far
> from complete. While playing around this weekend, I noticed three
> things:
>
>
> - Tomcat trunk still has EL 2.2 instead of the new EL 3.0
>
> - javax.servlet.http.HttpSessionIdListener (possibly others,
> this is just the one I noticed) is missing from servlet-api.jar
>
> - HttpServletRequest#changeSessionId() is not yet
> implemented
>
> Is anyone on the list currently working on any of these three things,
Not to my knowledge.
> and if so, do you have any idea when some reasonably-stable iteration
> of them will be checked in to trunk?
EL 3.0 will be a fair amount of work. The ID change stuff is trivial.
Mark
>
> Of course, I know it's entirely possible that simply nobody has even
> looked at them yet, and that's understandable this early in the
> game.
>
> Nick
>
>
> This e-mail may contain privileged or confidential information. If
> you are not the intended recipient: (1) you may not disclose, use,
> distribute, copy or rely upon this message or attachment(s); and (2)
> please notify the sender by reply e-mail, and then delete this
> message and its attachment(s). Underwriters Laboratories Inc. and its
> affiliates disclaim all liability for any errors, omissions,
> corruption or virus in this message or any attachments.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org