RE: When to notify of changed session IDs?
-Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Tuesday, February 12, 2013 3:07 AM To: dev@tomcat.apache.org Subject: Re: When to notify of changed session IDs? On 12.02.2013 06:03, Williams, Nick wrote: I have attached a diff file for my changes, which I'm not sure will get through because I don't know whether the developer's list allows attachments. I know the user's list doesn't. But seeing as how this is new development (Servlet 3.1) and not a bug, I didn't have anything else to attach the diff on. The attachment got stripped. Please open a bugzilla issue and attach it there. That way it won't get lost. Thanks! Rainer I created bug 54552 and attached my patch to that bug. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: When to notify of changed session IDs?
-Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Tuesday, February 12, 2013 4:32 AM To: dev@tomcat.apache.org Subject: Re: When to notify of changed session IDs? On 12.02.2013 06:03, Williams, Nick wrote: I tried to run all of the Junit tests locally, but when it completed 30 minutes later I had dozens of failures and dozens of errors. After reviewing the messages carefully, I am 99.9% sure that none of these are due to changes I made. I don't think I have my local environment set up right to run unit tests. (I would appreciate some guidance on this if anyone has any.) The majority of the failures were due to java.lang.ClassNotFoundException: org.apache.tomcat.util.http.ValuesEnumerator. I am quite comfortable saying I didn't cause that, but I'm certainly not sure what did. Tests for Tomcat trunk currently run fine for me, only one error in TestWebSocket, all other tests pass. Did you svn up your working copy? How do you run the tests? Do you know, whether you get the same error when running the tests without your patches? Regards, Rainer Yes, I svn uped my working copy. I run tests with ant test. Unfortunately, I did not run the tests before I started working (stupid I know), and doing so would require me to revert all of my changes, recompile and run another 30-minute testing session :-/. Before I spend all that time (which I'm willing to do if I need to) I'd love if someone would suggest some things I might be doing wrong. I'd prefer to only have to run those tests one more time. :-) 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: When to notify of changed session IDs?
-Original Message- From: Greg Turnquist [mailto:greg.l.turnqu...@gmail.com] Sent: Tuesday, February 12, 2013 8:14 AM To: Tomcat Developers List Subject: Re: When to notify of changed session IDs? An alternative idea would be to checkout another copy of svn, pointed at the version where you started. I do this all the time when I don't want to backtrack in my current working set. I'm not sure why I didn't think of that. I created another working copy from trunk, built the clean copy that didn't have any of my changes, ran tests with ant test, and I'm still getting failing and erred tests. Clearly something isn't right on my end... :-/ This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: When to notify of changed session IDs?
-Original Message- From: Williams, Nick [mailto:nicholas.willi...@ul.com] Sent: Tuesday, February 12, 2013 12:54 PM To: Tomcat Developers List Subject: RE: When to notify of changed session IDs? An alternative idea would be to checkout another copy of svn, pointed at the version where you started. I do this all the time when I don't want to backtrack in my current working set. I'm not sure why I didn't think of that. I created another working copy from trunk, built the clean copy that didn't have any of my changes, ran tests with ant test, and I'm still getting failing and erred tests. Clearly something isn't right on my end... :-/ Importantly, if I run ant test over and over again on the same revision (without my changes), I don't always get the same number of failures or errors, and it's not always the same tests that fail/err. :-/ This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
-Original Message- From: Mark Thomas [mailto:ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
-Original Message- From: Mark Thomas [mailto:ma...@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.ClassT) 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.ClassT) 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: EL 3.0, HttpSessionIdListener, HttpServletRequest#changeSessionId()
(I'm replying to both your emails here. Forgive me.) -Original Message- From: Mark Thomas [mailto:ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
When to notify of changed session IDs?
After discussing with Mark T, I'm working on implementing HttpServletRequest.changeSessionId() and the calling of HttpSessionIdListeners as introduced in the Servlet 3.1 specification. I'd like to help and it seemed like a trivial enough item for me to tackle (I may regret saying that :-P). Tomcat already has some utilities built-in for changing session IDs, so that helped me significantly. Currently I'm seeing that there are a couple places where session IDs can already change in Tomcat: - Request is authenticated via some container-provided mechanism and changeSessionIdOnAuthentication is enabled - A session ID is changed on one node in a cluster and it notifies the other nodes to do the same When any of these happen, Context.fireContainerEvent() is called with Context.CHANGE_SESSION_ID_EVENT. The Servlet 3.1 spec document doesn't deal with the new HttpSessionIdListener directly, but the javadoc for Servlet 3.1 says that all HttpSessionIdListeners will be of session ID changes. It doesn't say when HttpServletRequest.changeSessionId() is called, it says about HttpSession ID changes. So, from where I standing, this means to me: - When HttpServletRequest.changeSessionId() is called and changes the session ID, OR the container authenticates a request and changeSessionIdOnAuthentication is enabled resulting in the session ID changing, OR a session ID is changed on one node in a cluster and it notifies the other nodes to do the same, or a session ID is changed for any other reason, HttpSessionIdListeners should be notified. - When HttpServletRequest.changeSessionId() is called and changes the session Id, Context.fireContainerEvent() should be called with Context.CHANGE_SESSION_ID_EVENT just like if the session ID were changed some other way. Does anyone disagree with this? This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: When to notify of changed session IDs?
-Original Message- From: Williams, Nick [mailto:nicholas.willi...@ul.com] Sent: Monday, February 11, 2013 5:24 PM To: Tomcat Developers List (dev@tomcat.apache.org) Subject: When to notify of changed session IDs? After discussing with Mark T, I'm working on implementing HttpServletRequest.changeSessionId() and the calling of HttpSessionIdListeners as introduced in the Servlet 3.1 specification. I'd like to help and it seemed like a trivial enough item for me to tackle (I may regret saying that :-P). Tomcat already has some utilities built-in for changing session IDs, so that helped me significantly. Currently I'm seeing that there are a couple places where session IDs can already change in Tomcat: - Request is authenticated via some container-provided mechanism and changeSessionIdOnAuthentication is enabled - A session ID is changed on one node in a cluster and it notifies the other nodes to do the same When any of these happen, Context.fireContainerEvent() is called with Context.CHANGE_SESSION_ID_EVENT. The Servlet 3.1 spec document doesn't deal with the new HttpSessionIdListener directly, but the javadoc for Servlet 3.1 says that all HttpSessionIdListeners will be of session ID changes. It doesn't say when HttpServletRequest.changeSessionId() is called, it says about HttpSession ID changes. So, from where I standing, this means to me: - When HttpServletRequest.changeSessionId() is called and changes the session ID, OR the container authenticates a request and changeSessionIdOnAuthentication is enabled resulting in the session ID changing, OR a session ID is changed on one node in a cluster and it notifies the other nodes to do the same, or a session ID is changed for any other reason, HttpSessionIdListeners should be notified. - When HttpServletRequest.changeSessionId() is called and changes the session Id, Context.fireContainerEvent() should be called with Context.CHANGE_SESSION_ID_EVENT just like if the session ID were changed some other way. Does anyone disagree with this? With the above assumptions that I believe are correct, I have completed the changes necessary for this to work. It is compiling and running without any issues that I can see on my machine, I can successfully change a session ID by calling HttpServletRequest.changeSessionId(), and HttpSessionIdListeners are notified when I change a session ID. Everything appears to be working perfectly. I tried to run all of the Junit tests locally, but when it completed 30 minutes later I had dozens of failures and dozens of errors. After reviewing the messages carefully, I am 99.9% sure that none of these are due to changes I made. I don't think I have my local environment set up right to run unit tests. (I would appreciate some guidance on this if anyone has any.) The majority of the failures were due to java.lang.ClassNotFoundException: org.apache.tomcat.util.http.ValuesEnumerator. I am quite comfortable saying I didn't cause that, but I'm certainly not sure what did. I have attached a diff file for my changes, which I'm not sure will get through because I don't know whether the developer's list allows attachments. I know the user's list doesn't. But seeing as how this is new development (Servlet 3.1) and not a bug, I didn't have anything else to attach the diff on. I'd appreciate feedback on the diff and any information anyone has about next steps. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
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.
OT: Servlet 3.1 / JSP 2.3
This is only slightly related to Tomcat, in that Servlet 3.1 / JSP 2.3 work is happening in trunk/8.0. Hence the OT. I was looking through the JSRs for EE 7 last night and realized I couldn't find anything about JSP 2.3 in any of them. I know JSP 2.3 exists because of Mark Thomas's presentation (http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat8-preview.pdf). But I cannot find a JSR for it. Is it part of JSR 340 (the Servlet 3.1 specification), or is there a JSR I haven't found yet, or has no JSR been created yet? Also, I figured since I couldn't find any information about it on Oracle's site or the JCP site that it must not be very far along, and yet here it is, on the Maven central repository (uploaded January 12, 2013), without any indication in the version that it's beta or milestone or anything of the sort: http://search.maven.org/#artifactdetails%7Cjavax.servlet.jsp%7Cjavax.servlet.jsp-api%7C2.3.0%7Cjar Does anybody know the answer to this? 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: OT: Servlet 3.1 / JSP 2.3
There is no JSR and no Expert Group. JSP 2.3 will be handled as a maintenance release of 2.2. Well that explains why I couldn't find it the JSR. :-P The changes are (as far as I am aware): - fix typos - limit HTTP methods that JSPs respond to (to HEAD, GET, POST) - changes required as a result of EL 3.0 (don't know what these will be) - anything else Oracle has thought of since I last spoke to the person maintaining the JSP spec Sounds innocuous enough ... probably. That last one is scary. ;-) That is from the spec lead. Does this mean that it IS the final JSP 2.3 API? Or is it still in progress? It will be interesting to see what a diff of the javap output between that and JSP 2.2 shows. /me Starts downloading that JAR Since you're already doing this, do you mind sharing the diff? There will be an update of my Tomcat 8 presentation at ApacheCon NA in Portland in a few weeks time. I look forward to it. Wish I could afford (time and $) to go. I'll have to settle with reading the slides afterwards. 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: OT: Servlet 3.1 / JSP 2.3
It looks like a work-in-progress to me. The only change I see to the public API is dropping some runtime exceptions from a handful of method declarations. Interesting. It sure would be nice if the Maven artifact had SOME indication of this, like beta in the version or something similar like the Servlet 3.1 (3.1-b05) and EL 3.0 (3.0-b04) artifacts. There's not even a status page for the project. I know that it's not a JSR and there's no expert group, but I'd hoped for at least some kind of status page... Since I gather that you're in contact with someone who knows what's going on over there, and likely will have to garner more information for your ApacheCon presentation, I'd love if you'd share whatever you find out. :-) 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Compiling JSPs with JDK 1.8 in Tomcat 8
So, it turns out the SMAP was causing my Java 8 compiler issues. When I added that suppressSmap = true, it successfully compiled the JSP using Java 8, and the lambda expression in my JSP works. Like you said, some kind of problem there that will need to be address eventually. Not sure what it is. Last night I had compilerSourceVM and compilerTargetVM set to 1.8, compiler set to modern, and tools.jar, ant.jar and ant-launcher.jar all on my classpath, and I was still getting the warning org.apache.jasper.compiler.JDTCompiler generateClass WARNING: Unknown source VM 1.8 ignored. I promise :-). If I made just one more change, setting compilerClassName to the AntCompiler class, it stopped using the Eclipse compiler and I was instead getting an error Unknown tag: 18. That error went away if I removed the lambda expression from my JSP, so I (incorrectly) assumed the Ant compiler didn't like Java 8 syntax. Turns out it was the SMAP that was causing that problem. This morning the only thing I changed was to add the suppressSmap = true and it started compiling. However, now I take off the compilerClassName parameter and it still works. Perhaps I've just been looking at this too long. I can't duplicate the behavior I was seeing last night anymore... Oh, well. It works. For everyone's future reference, this is everything that's necessary to compile JSPs in Java 8 in Tomcat 8: 1) Add to JSP servlet in conf\web.xml: init-param param-namecompiler/param-name param-valuemodern/param-value /init-param init-param param-namecompilerSourceVM/param-name param-value1.8/param-value /init-param init-param param-namecompilerTargetVM/param-name param-value1.8/param-value /init-param init-param param-namesuppressSmap/param-name param-valuetrue/param-value /init-param 2) Create setenv.bat (or setenv.sh, depending on your OS): set CLASSPATH=/path/to/jdk/tools.jar;/path/to/ant/ant.jar;/path/to/ant/ant-launcher.jar Interesting problem I'd welcome feedback on: I have an OS environmental variable JAVA_HOME set to C:\Program Files\Java\jdk1.8 (so, JAVA_HOME is set to the JDK home). My belief was that I SHOULD be able to leave off the tools.jar. However, that does not work. C:\Users\Nicholasecho %JRE_HOME% %JRE_HOME% C:\Users\Nicholasecho %JAVA_HOME% C:\Program Files\Java\jdk1.8 When starting, catalina.bat output says Using JRE_HOME: C:\Program Files\Java\jdk1.8, so it's right there, and it has to be getting it from JAVA_HOME since JRE_HOME isn't set. However, upon first access of a JSP: org.apache.jasper.JasperException: Unable to compile class for JSP root cause Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK. It is currently set to C:\Program Files\Java\jdk1.8\jre Why (and how) is the JAVA_HOME getting changed to the JRE? *scratches head* N -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Tuesday, January 22, 2013 6:14 PM To: Tomcat Developers List Subject: Re: Compiling JSPs with JDK 1.8 in Tomcat 8 On 22/01/2013 22:40, Williams, Nick wrote: As you can see from my testing and comment in bug 54461 (https://issues.apache.org/bugzilla/show_bug.cgi?id=54461), after much effort I discovered that complier is indeed a parameter, but so is compilerClassName. In order to use anything other than the Eclipse JDT compiler, compilerClassName must be set to the class name of an alternative org.apache.jasper.compiler.Compiler That statement is not correct. The only other implementation at the moment is org.apache.jasper.compiler.AntCompiler. The compiler parameter ONLY affects the AntCompiler compiler right now, and is ignored if the JDTCompiler is in use. (No matter what I set compiler to, I get org.apache.jasper.compiler.JDTCompiler generateClass WARNING: Unknown source VM 1.8 ignored warnings UNLESS I also set compilerClassName to AntCompiler.) Again, those statements are incorrect. You are doing something wrong. See org.apache.jasper.JspCompilationContext#createCompiler() That aside, my original problem is still unanswered. It appears AntCompiler, like JDTCompiler, still uses some compiler other than the JDK's built-in javac compiler. Whether I specify classic, modern, or extJavac as the compiler for AntCompiler, I get syntax errors for the lambda expression in my JSP. The same lambda expression compiles fine in my JDK compiler. That first statement is also not correct. Ant uses whichever compiler you tell it to use via the compiler init parameter. So, is there any way to use the JDK compiler to compile JSPs? Yes. The docs [1] cover what you need to do to use javac. To summarise: - set compiler init parameter for the JSP servlet to modern (or any other value from the Ant docs) in $CATALINA_BASE/conf/web.xml
RE: Compiling JSPs with JDK 1.8 in Tomcat 8
As you can see from my testing and comment in bug 54461 (https://issues.apache.org/bugzilla/show_bug.cgi?id=54461), after much effort I discovered that complier is indeed a parameter, but so is compilerClassName. In order to use anything other than the Eclipse JDT compiler, compilerClassName must be set to the class name of an alternative org.apache.jasper.compiler.Compiler implementation. The only other implementation at the moment is org.apache.jasper.compiler.AntCompiler. The compiler parameter ONLY affects the AntCompiler compiler right now, and is ignored if the JDTCompiler is in use. (No matter what I set compiler to, I get org.apache.jasper.compiler.JDTCompiler generateClass WARNING: Unknown source VM 1.8 ignored warnings UNLESS I also set compilerClassName to AntCompiler.) That aside, my original problem is still unanswered. It appears AntCompiler, like JDTCompiler, still uses some compiler other than the JDK's built-in javac compiler. Whether I specify classic, modern, or extJavac as the compiler for AntCompiler, I get syntax errors for the lambda expression in my JSP. The same lambda expression compiles fine in my JDK compiler. So, is there any way to use the JDK compiler to compile JSPs? Or, am I stuck compiling JSPs at Java 7 until either Eclipse or Ant starts supporting Java 8? Thanks, Nick -Original Message- From: Williams, Nick [mailto:nicholas.willi...@ul.com] Sent: Monday, January 21, 2013 9:42 PM To: Tomcat Developers List (dev@tomcat.apache.org) Subject: Compiling JSPs with JDK 1.8 in Tomcat 8 I'm running an experimental environment with JDK 1.8 and Tomcat 8.0 (trunk). I understand, of course, that there are some inherent instabilities associated with doing this, but something just doesn't seem quite right. I want JSPs to compile with Java 8, not Java 7. I understand that the Eclipse compiler obviously doesn't support that yet (and, if history is any indication, it won't until sometime in late 2014), so I wanted to configure JSPs to compile with something other than the JDT compiler. Using the documentation at http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html, I added the following init parameters to the JSP servlet in conf\web.xml: init-param param-namecompiler/param-name param-valuejavac/param-name /init-param init-param param-namecompilerSourceVM/param-name param-value1.8/param-name /init-param init-param param-namecompilerTargetVM/param-name param-value1.8/param-name /init-param However, I was getting JDT warnings about unrecognized source value 1.8, meaning the JDT compiler was still being used. After lots of Googling, I discovered that the documentation was wrong about the compiler init parameter. The correct parameter name is compilerClassName, not compiler. (Subsequently, I filed https://issues.apache.org/bugzilla/show_bug.cgi?id=54461 about this documentation bug.) So I changed it to compilerClassName and then started getting errors about not being able to find a compiler (at least I knew I had the parameter name right now, because it stopped using the Eclipse compiler). I changed the value to com.sun.tools.javac.Main (another thing I found while Googling) and still got the no-compiler error. I added tools.jar to the classpath (even though JAVA_HOME was set to a JDK home, not a JRE home, which I thought would take care of that), and then I got the following error: org.apache.jasper.JasperException: java.lang.ClassCastException: com.sun.tools.javac.Main cannot be cast to org.apache.jasper.compiler.Compiler. I felt like I was now making progress, so I went to the javadocs and found the two classes that implement org.apache.jasper.compiler.Compiler: org.apache.jasper.compiler.AntCompiler and org.apache.jasper.compiler.JDTCompiler. I set the value of compilerClassName to org.apache.jasper.compiler.AntCompiler and added the Ant JARs to the classpath, and now I'm getting a new error: org.apache.jasper.JasperException: Unable to compile class for JSP Caused by java.lang.ClassNotFoundException: javac1.8 I'm at a loss here. Am I completely missing something? Or is it not possible to set Tomcat 8.0 to compile JSPs with Java 8? 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Compiling JSPs with JDK 1.8 in Tomcat 8
I'm running an experimental environment with JDK 1.8 and Tomcat 8.0 (trunk). I understand, of course, that there are some inherent instabilities associated with doing this, but something just doesn't seem quite right. I want JSPs to compile with Java 8, not Java 7. I understand that the Eclipse compiler obviously doesn't support that yet (and, if history is any indication, it won't until sometime in late 2014), so I wanted to configure JSPs to compile with something other than the JDT compiler. Using the documentation at http://tomcat.apache.org/tomcat-7.0-doc/jasper-howto.html, I added the following init parameters to the JSP servlet in conf\web.xml: init-param param-namecompiler/param-name param-valuejavac/param-name /init-param init-param param-namecompilerSourceVM/param-name param-value1.8/param-name /init-param init-param param-namecompilerTargetVM/param-name param-value1.8/param-name /init-param However, I was getting JDT warnings about unrecognized source value 1.8, meaning the JDT compiler was still being used. After lots of Googling, I discovered that the documentation was wrong about the compiler init parameter. The correct parameter name is compilerClassName, not compiler. (Subsequently, I filed https://issues.apache.org/bugzilla/show_bug.cgi?id=54461 about this documentation bug.) So I changed it to compilerClassName and then started getting errors about not being able to find a compiler (at least I knew I had the parameter name right now, because it stopped using the Eclipse compiler). I changed the value to com.sun.tools.javac.Main (another thing I found while Googling) and still got the no-compiler error. I added tools.jar to the classpath (even though JAVA_HOME was set to a JDK home, not a JRE home, which I thought would take care of that), and then I got the following error: org.apache.jasper.JasperException: java.lang.ClassCastException: com.sun.tools.javac.Main cannot be cast to org.apache.jasper.compiler.Compiler. I felt like I was now making progress, so I went to the javadocs and found the two classes that implement org.apache.jasper.compiler.Compiler: org.apache.jasper.compiler.AntCompiler and org.apache.jasper.compiler.JDTCompiler. I set the value of compilerClassName to org.apache.jasper.compiler.AntCompiler and added the Ant JARs to the classpath, and now I'm getting a new error: org.apache.jasper.JasperException: Unable to compile class for JSP Caused by java.lang.ClassNotFoundException: javac1.8 I'm at a loss here. Am I completely missing something? Or is it not possible to set Tomcat 8.0 to compile JSPs with Java 8? Thanks, Nick This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
RE: Tomcat 8 question
Thanks, Mark. Also, thanks Violeta for pointing out Mark's slides where he mentions JSP 2.3. Nick On 20/01/2013 07:14, Violeta Georgieva wrote: Hi, 2013/1/20 Williams, Nick So, will Tomcat 8 be targeted for EE 7, or will it wait until JSP-next comes out, even if that takes a good deal longer than EE 7? Also, I know that a lot depends on the timeline of EE 7, but now that that date is approaching, do we have a GENERAL timeframe for Tomcat 8? Are we talking late 2013? Or could it take until 2014? Check Mark's presentation [1] There will be a maintenance release of the JSP specification. The only potential change I am aware of is limiting the HTTP methods that JSPs respond to to HEAD, GET and POST. How long the first Tomcat 8 release (that fully implements the specs) takes depends on how much time folks spend on implementing them. I'll have an update on Tomcat 8 progress at ApacheCon NA next month and the slides will be available from the usual place once I have written them. As always, help is appreciated. Mark This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat 8 question
Back in August 2011 (a long time ago, I know) Mark wrote a blog posting about Tomcat 8 and Java 7: http://www.tomcatexpert.com/blog/2011/08/25/apache-tomcat-8-and-java-7-will-they-work-together In it, he said We create a new major version of Tomcat when there are new versions of three specifications-Servlet, JavaServer Pages (JSP) and Expression Language (EL). I know I keep hearing about Tomcat 8 being for Java EE 7, but as of yet I haven't found any evidence at all that EE 7 will include a new version of the JSP specification. I have found several lists, one of them only a week old, of all the specifications in EE 7, and JSP-next was not among them. My Google searches for JSP 2.3 and JSP 3.0 yielded no results that actually had anything to do with the next JSP specification. So, will Tomcat 8 be targeted for EE 7, or will it wait until JSP-next comes out, even if that takes a good deal longer than EE 7? Also, I know that a lot depends on the timeline of EE 7, but now that that date is approaching, do we have a GENERAL timeframe for Tomcat 8? Are we talking late 2013? Or could it take until 2014? Thanks, Nick This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
RE: antlib.xml vs catalina.tasks (was: Re: r1346638)
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Sunday, June 24, 2012 11:15 AM
To: Tomcat Developers List
Subject: antlib.xml vs catalina.tasks (was: Re: r1346638)
2012/6/6 Mark Thomas ma...@apache.org:
On 06/06/2012 00:22, Konstantin Kolinko wrote:
2012/6/6 Mark Thomas ma...@apache.org:
On 05/06/2012 23:42, Konstantin Kolinko wrote:
2012/6/6 ma...@apache.org:
Author: markt
Date: Tue Jun 5 22:38:53 2012
New Revision: 1346638
URL: http://svn.apache.org/viewvc?rev=1346638view=rev
Log:
Remove unused file
Removed:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/ant/antlib.xml
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1346635
Please explain, why do you think that this file is unused?
Because:
- it is not referenced anywhere in the code base
It should not be referenced. We do not bundle Ant with Tomcat.
- it does not include JspC
Those tasks are related to server management. You do not need to
precompile JSPs for that.
It can be solved by adding the two missing tasks.
- all our code examples (including the docs) use catalina.tasks to
do the same thing
Though we do not directly use
org/apache/catalina/ant/antlib.xml
we certainly do use the one here:
org/apache/catalina/ant/jmx/antlib.xml
The latter one is mentioned in the docs:
http://tomcat.apache.org/tomcat-7.0-doc/monitoring.html
I would also say that antlib sounds like a more modern approach.
Anyway I am -1 on removing this file from stable versions. It may
break systems and I do not see what problem this removal solves.
The problem it solves is unnecessary duplication leading to additional
maintenance effort and bugs when they get out of sync. I don't see the
point of having two files that do the same thing. I don't particularly
care whether we keep catalina.tasks or antlib.xml. I just deleted the
one we weren't using anywhere and hadn't documented anywhere.
I can restore the file in 7.0.x easily enough.
If you prefer antlib.xml to catalina.tasks then I have no objection to
you making antlib.xml the standard in 8.0.x onwards as long as the
documentation is updated to that effect as well.
Current status:
==
1) Mark restored antlib.xml in Tomcat 7 and I restored it in trunk.
2) I aligned antlib.xml with *.tasks files in trunk and TC7 (proposed for 6.0
as well)
We have two pairs of antlib.xml vs *.tasks files, in o.a.c.ant and in
o.a.c.ant.jmx.
Several notes in comparison of antlib.xml vs *.tasks files:
=
1. Documentation
* The *.tasks files are not explicitly mentioned in documentation, but are used
- by bin/catalina-tasks.xml
- by sample application in appdev documentation (appdev/build.xml.txt, also
copied to appdev/sample/build.xml at build time)
- by Deployer (res/deployer/build.xml)
* Jasper documentation (jasper-howto.html) recommends bin/catalina-tasks.xml
* Deployer documentation (deployer-howto.html) does not mention anything
explicitly, but references the build.xml file included with deployer package.
* Monitoring and Management documentation (monitoring.html) documents two ways
to configure jmx tasks
a) using antlib, b) using import + catalina-tasks.xml
2. Using antlib is easier when you can put your jars into Ant classpath (as
recommended for jmx tasks). It is not easy for jasper, as many jars are
involved there.
In Ant documentation there is example how to use typedef + namespaces [1].
[1] http://ant.apache.org/manual/Tasks/typedef.html
3. JMX tasks in jmx/antlib.xml file and in jmxaccessor.tasks have different
names.
The latter ones are suitable to use without namespaces, as they are named as
jmxSomething.
To get rid of *.tasks files a plan can be the following:
===
(in Tomcat 8 only)
I have not yet tested whether import in Ant correctly operates with
namespaces.
I have not yet tested whether namespace uris in Ant need to start with
antlib: prefix.
I suspect that there is no need for antlib prefix in URIs when explicit
typedef is used.
If the above works, then plan is the following.
1. Update bin/catalina-tasks.xml to define Tomcat and JMX tasks like the
following:
[[[
project name=catalina-tasks
descriptionCatalina Ant Manager, JMX and JSPC Tasks/description
!-- set catalina.home if it's not already set --
dirname property=catalina.home.bin.dir file=${ant.file.catalina-tasks}/
property name=catalina.home value=${catalina.home.bin.dir}/../
typedef resource=org/apache/catalina/ant/antlib.xml
uri=urn:org.apache.catalina.ant
classpath
fileset file=${catalina.home}/bin/tomcat-juli.jar/
fileset file=${catalina.home}/lib/jasper.jar/
fileset file=${catalina.home}/lib/jasper-el.jar/
fileset file=${catalina.home}/lib/el-api.jar/
