Re: cvs commit: jakarta-servletapi-5/jsr154/src/share/dtd web-app_2_4.xsd
Hi,
I remember there was an issue that the default DD in conf/web.xml was
not valid by the schema - is this change related to that issue?
Thanks
Petr
[EMAIL PROTECTED] wrote:
jfarcand2004/08/24 10:01:34
Modified:jsr154/src/share/dtd web-app_2_4.xsd
Log:
Update the web-app_2_4.xsd according
to the JSR154 maintenance release.
o The restriction facet of mime-typeType should be updated
from:-
xsd:pattern value=[\p{L}\-\p{Nd}]+/[\p{L}\-\p{Nd}\.]+/
to:-
xsd:pattern value=[^\p{Cc}^\s]+/[^\p{Cc}^\s]+
submitted by: Yutaka Yoshida at sun dot com
Revision ChangesPath
1.14 +2 -2 jakarta-servletapi-5/jsr154/src/share/dtd/web-app_2_4.xsd
Index: web-app_2_4.xsd
===
RCS file: /home/cvs/jakarta-servletapi-5/jsr154/src/share/dtd/web-app_2_4.xsd,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- web-app_2_4.xsd 18 Mar 2004 16:40:34 - 1.13
+++ web-app_2_4.xsd 24 Aug 2004 17:01:34 - 1.14
@@ -30,7 +30,7 @@
xsd:annotation
xsd:documentation
- Copyright 2002 Sun Microsystems, Inc., 901 San Antonio
+ Copyright 2004 Sun Microsystems, Inc., 901 San Antonio
Road, Palo Alto, California 94303, U.S.A. All rights
reserved.
@@ -804,7 +804,7 @@
xsd:simpleContent
xsd:restriction base=j2ee:string
- xsd:pattern value=[\p{L}\-\p{Nd}]+/[\p{L}\-\p{Nd}\.]+/
+ xsd:pattern value=[^\p{Cc}^\s]+/[^\p{Cc}^\s]+/
/xsd:restriction
/xsd:simpleContent
/xsd:complexType
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Costin Manolache wrote: Shapira, Yoav wrote: Hi, I have a couple of only-slightly-related comments, but related nonetheless so I'll put them here. Re: endorsed directories. Do we still want to support JDK 1.3 in Tomcat 5.1? Since we're gearing up for JDK 1.5, we might want to make 1.4 the minimum. I'm +0.5 on this. First, endorsed directories are _not_ for 1.3, but for 1.4 ( to override the build-in parser and the check they do on load ). 1.3 works fine with just having the parser in classpath, or in /jre/lib/ext, and it's quite simple to add code to the loader to add the parser packages only if 1.3 is detected. I'm using JDK1.3 most of the time, and I think a lot of other people and companies are still using it. I don't mind having the default distribution built for 1.4+ ( no xerces ), with instructions on how to get the additional jars for 1.3. But I think it would be very bad to not be able to run in 1.3 - and I don't see any good reason to justify forcing the users to upgrade. Hi Tomcat developers, I must say I don't fully understand the above. So what exactly will happen if the common/endorsed directory is removed? What will stop working and on which platform(s)? Are there any specific pointers to bug ids or discussions, that would explain why the endorsed directory was added in the first place? I know configuring the XML parser and JAXP was always pain, but I don't know what specifically was the problem. Any insights you can bring into this will be appreciated. Thanks in advance. Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
FYI - progress on the 5.0.28 changes: Petr Jiricka wrote: - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. Thanks to Jan Luehe, these fixes are now integrated to the TOMCAT_5_0 branch. See also the release notes for the list of issues ported from trunk. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) My coworkers at Sun are investigating the possible approaches to make the same distribution of Tomcat work on both JDK 1.4 and 1.5, including Costin's idea. If you have any additional thoughts or suggestions in this area, please post them. Thanks Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Shapira, Yoav wrote: Hi, A TOMCAT_5_0 branch was created at the time 5.0.27 was released. I'm not gung-ho about making significant Tomcat 5.0 additions and enhancements, given the advanced state of Tomcat 5.1 development. If there's a showstopper, security, or spec-compliance bug than of course it will be fixed and additional releases made. I didn't know there was a branch already! Thanks - that's great. As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans. However, if you really want this strongly, feel free to submit patches back-porting the CVS HEAD patches onto the TOMCAT_5_0 branch code, and we'll look at them. Thanks. As for JDK 1.5 specifically: Tomcat 5.1 will support JDK 1.5 without needing to modify anything. Tomcat 5.0 doesn't make that claim, but it does let you modify parsers as you want using the standard endorsed classloading mechanism. Of course I've already said that on the bug report ;) I guess there are two possible perceptions of this problem. One is that we should strive for the cleanest possible architecture, and have multiple releases each targetting a particular platform. The other is that there should be a single universal release that supports a range of platforms, and the architecture should be able to accomodate all of them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK. Hi, Oh and BTW, definitely -1 on committing to regular monthly releases. They'll come when they're ready: that's always been the process. And ready itself is also ambiguously defined as a critical fix, significant enhancements, large number of bug fixes, or a combination thereof. If the average duration between releases for us has been 1 month, that's great, but it's a coincidence that I don't want to commit to ;) There are far too many variables in our work for that. Agreed, it is not reasonable to commit to regular release schedule (based on my own experience ;) In my mind, release schedule is an approximate guideline, not committment. Yoav Shapira Millennium Research Informatics Petr -Original Message- From: Petr Jiricka [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: Tomcat 5.0.28 release Hi, we have been using Tomcat in the NetBeans product for about 4 years now (since the 3.2 beta releases), so first off, Thanks! for all your great work. Tomcat provides NetBeans users with the ability to run their applications out of the box, debug in on the Java and JSP level, and generally serves as an excellent testing environment for web applications developed using NetBeans. Now, on behalf of the Sun Developer Tools group, I'd like to propose a next release of the Tomcat 5.0.x codeline, i.e. Tomcat 5.0.28. The goals of this release would be the following: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue
Re: Tomcat 5.0.28 release
Remy Maucherat wrote: Petr Jiricka wrote: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. I do manage to integrate patches in the JBoss tree without the need for a stable release, whenever I really need a particular fix. IMO, you should be prepared to do the same once in a while, it's easier for everyone. I believe Tomcat is used in a number of high profile servers (in addition to your usage), so making a release each time someone needs something (I suppose in the few days before a freeze of the relevant products, it would probably be every 5 minutes ;) ) isn't possible. The advantage of stable releases is that these are much more thoroughly tested by the community than ad-hoc builds. Also, a stable release is a way of saying to the community that we believe that what we have now works together, it is safe to use the fixes that have come in. We should not be asking why to do a release - let's ask why not?. We could easily do a custom build with just the bugfixes we need, but I think the community would benefit if the fixes are exposed in a public release. As for the other part of your question - yes, our main motivation for a new release is to use it in our product, but we are not talking about days. In fact, we have been testing NetBeans with Tomcat 5 since January, and submitted a fair number of bug reports since then. I believe monthly releases are reasonable - we are definitely not talking about a release every 5 minutes :) - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) This is disruptive for 5.0.x. So, sorry, but I vote no for that one. My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). Ok, we have a different opinion here, see my reply to Yoav. - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. This makes sense, but you need to indicate which patches need to be backported. I expect it's the JSP debugging related fixes then ? Yes, we'd like to see the JSP debugging bugfixes in, but I am not only talking about bugfixes requested by Sun. If the community feels strongly that a particular bugfix should be ported to 5.0.x, then it can be done. This should be a community effort, not a Sun release. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase. Nice plan :) (ok, actually, we did that already before starting the refactoring, as Yoav mentioned) Thanks again. Petr Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.28 release
Costin Manolache wrote: I'm sorry, but can't remember - why do we still need the endorsed ? I tought they were a temporary solution for JDK1.4 and some validation problems - tomcat should work fine with any SAX/DOM parser, including the one in JDK1.4. This would be good, if it's indeed possible. I just tried removing common/endorsed/*.jar from Tomcat 5.0.27, and it seemed to work ok on JDK 1.4.2_04. I didn't try any XML tags in JSTL (which often prove fragile wrt. parser configuration), but at first sight it works. The only problem is JDK1.3 - and I agree that it would be better to just provide a patch for 1.3 ( or ask the user to install a parser in jre/ext or classpath, to get the same behavior as in 1.4 ). Or even better - in Bootstrap check if we're in 1.3 and add the parser to the classpath, otherwise use whatever is in jdk ( and maybe turn validation of if the version of jdk and parser is not the right one ). In any case - modularizing the distribution would be really good. Having a core JDK1.5 distro, and additional packages to add JDK1.4 and JDK1.3 support is good. It would also be good to distribute more components as optional plug-ins. I agree this is a good plan, as long as there is a way to build a single distribution that supports all the supported platforms (or at least JDK 1.4.x + 1.5). Thanks Petr Again - I missed a lot of discussions, probably most of this has been discussed, I'll try more searches on the archives :-) Costin Tim Funk wrote: Didn't we already try that with the tomcat 4 LE edition? -Tim Remy Maucherat wrote: My current idea for the new branch is to ship a JDK 1.5 bundle with a separate zip/tar.gz to easily install the additional binaries when using JDK 1.4-. This will be smaller (no JMX, no Xerces) and maybe higher quality (more testing of the bundled components ?). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.0.28 release
Hi, we have been using Tomcat in the NetBeans product for about 4 years now (since the 3.2 beta releases), so first off, Thanks! for all your great work. Tomcat provides NetBeans users with the ability to run their applications out of the box, debug in on the Java and JSP level, and generally serves as an excellent testing environment for web applications developed using NetBeans. Now, on behalf of the Sun Developer Tools group, I'd like to propose a next release of the Tomcat 5.0.x codeline, i.e. Tomcat 5.0.28. The goals of this release would be the following: - Continue to deliver a stable release of Tomcat in roughly 1 month intervals. One of the reasons why Tomcat is so highly valued in the community is because the time between finding a bug and deliveing the fix is very short, thanks to the short release cycles. The community appreciates the high quality of releases resulting from this release model. - The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor. - The goal of 5.0.28 would be to support the upcoming JDK 1.5 release (now called JDK 5.0) out of the box, so no post-install setup steps are necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is necessary to manually remove file common/endorsed/xml-apis.jar to make Tomcat work with JDK 5.0, see also bug report 29579 or Tomcat release notes. This not only degrades the initial experience on 1.5, but also poses problems in the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.) - Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered. From a codeline perspective, we are suggesting to create a Tomcat 5.0.x branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase. Thanks in advance for your comments. Petr Jiricka Sun Developer Tools group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Contribution: OS/2 Rexx scripts for Tomcat
BTW, we also received contribution of OS/2 startup scripts, see http://www.netbeans.org/issues/show_bug.cgi?id=42678 Is OS/2 support a goal for Tomcat? Is Tomcat tested at all on OS/2? Petr Jaroslav Kacer wrote: Hello Tomcat developers! I have rewritten Tomcat scripts into the Rexx language that is commonly used on OS/2 systems and I'd like to include them to the Tomcat distribution. The scripts are available at http://hobbes.nmsu.edu/cgi-bin/h-search?key=tomcat_5-0-27_os2.zip Could someone download and include them into CVS? Or is there a special way I must follow? Thank you in advance for your answer. Best Regards, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Embedding Jasper / JSP compiling
Dennis Thrysøe wrote: Hi, I'm currently working on embedding a jasper engine within a servlet container that I'm writing. During this work I have run into the following questions: 1) Is the only advantage to using fork=true, that the javac memory leak issue is avoided? 2) Has the javac memory leak issue been fixed in newer versions of the JDK? 3) Is there any way to have the Java code generated from JSPs compiled using my own classloader? I was thinking, that if I used fork=false, maybe javac would just use the present classloader. I'd say this is not possible now. Should be a topic for Java compiler API: http://jcp.org/en/jsr/detail?id=199 Petr Any help with the above questions would be greatly appreciated, since it seems that I'm on a fairly difficult endeavour here. TIA, -dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on 5.0.23
Remy Maucherat wrote: Shapira, Yoav wrote: Hi, I have a strange issue with 5.0.23 that's making me question my stable vote from earlier today. It has to do with a 3rd party servlet which checks for the presence of a cookie, if not found prompts for some user information, and then redirects (response.sendRedirect) to another page. The exact same code base and test case works in 5.0.19 but not in 5.0.23. Was something relevant changed? Looking at the changelog, I'd like clarification on: Optimization: delay parsing of the cookies (remm) I'm running Sun JDK 1.4.2 on Solaris 8 (all patches installed). As I mentioned it works with tomcat 5.0.19. I'll proceed to try the intermediate builds 5.0.20, 5.0.21, and 5.0.22 to further narrow the possibilities. Thanks, I did find what the problem was: I did some testing, so I checked out an earlier revision of the file (CoyoteRequest, of course). Unfortunately, I'm using a new CVS tool with which I have less experience (tortoise) - not that I wanted to, but WinCVS decided to simply stop working one day - which doesn't display tags in a visible way, and the result is that an older revision of the file is in the build :( Well, this sounds quite alarming to me. Looks like there is no guarantee that the contents of the build really contains the intended codeline. Could some practices be established that would prevent such situation from happening? For example: - use command line CVS to check out sources for production builds - for production builds, always do a clean check out (use an empty directory) - write an Ant script that checks out sources for production build Would this help? Thanks Petr I'll have to do a new 5.0.24 build today, then. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
conf/web.xml still uses the servlet 2.3 DTD format?
Hello list, I noticed that Tomcat 5.0.12 still has the Servlet 2.3 DD in conf/web.xml: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; Are there any plans to upgrade it to web-app_2_4.xsd ? Thanks Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs
Bill Barker wrote: - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, September 22, 2003 10:31 PM Subject: Re: [PROPOSAL] Narrow down the list of JARs to be scanned for TLDs Jan Luehe wrote: Currently, any JARs in the classloader delegation chain of a webapp's classloader are scanned for packaged TLDs. This is convenient, as it allows a JAR-packaged taglib to be simply dropped in common/lib and shared by all webapps, rather than requiring each webapp to bundle the taglib in its own WEB-INF/lib. However, scanning all available JARs for TLDs is not very efficient, especially if the names of the JAR-packaged taglibs are known in advance. The proposal is to add a configurable String property (tldJarNames) on Context, which specifies the comma-separated list of JAR file names (without any path info) that must be scanned for TLDs. Catalina will continue to traverse the classloader delegation chain, but only consider those JARs that match the names in the comma-separated list. If a JAR appears more than once in the classloader delegation chain, we will pick its first occurrence. If the tldJarNames property is not set, Catalina will continue to scan all JARs in the classloader delegation chain for TLDs. Comments? Same as Yoav. -0. much pain, no gain. Seeing as how it's already been committed, +0. Has it? I saw some commits in the area of jar scanning, but not this one. As Jan has already pointed out, it should improve the startup time for Tomcat 5 (since scanning TLD files is a major hit). I too agree that limiting the number of jars scanned could substantially improve first start performance, however I am worried that the solution as suggested by Jan will make it too easy for the users to shoot themselves to the foot. Also, unless the user does some manual setup, there will be no performance gain,right? So wouldn't it be better to have a hardcoded list of well-known jar files that should be excluded from scanning? This would include all jars found in the Tomcat installation. I also think that under no circumstances the jar files in WEB-INF/lib should be excluded from scanning, as that is in conflict with the spec. Or is there something I am missing about the proposal? Petr Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Expose pre-compiled JSPs without servlet mapping
Remy Maucherat wrote: Jan Luehe wrote: Currently, if webapp developers do not want to expose the source of their JSP files, they have to precompile them and add a servlet mapping for each JSP to their web.xml (e.g., with the help of jspc). If the webapp contains a large number of JSPs, the web.xml is going to grow pretty big. Would it make sense to have Jasper try to load a class file corresponding to a JSP, even if the webapp does not have the JSP source file and does not specify any servlet mapping for that JSP? I think it would, I agree it would be a nice feature. Or even if the JSP does exist, but the developer prefers to precompile JSPs in order to eliminate the initial compilation lag. So if someone accesses a JSP for which there is no servlet mapping, the JspServlet will first determine if the JSP exists, and if it doesn't, it will try to load the corresponding class file. If the class file does not exist, a 404 is returned. Would it look in WEB-INF/classes for the servlet class files, or in tempdir ? Currently JspServlet looks in tempdir, but the precompiled classes are stored in WEB-INF/classes (by appendix A of the JSP spec). Loading the servlet from WEB-INF/classes may have the problem that classes from this place are loaded by the WebApp's classloaders, so they will not bubble up to JasperLoader, which may result in problems with reloading JSPs (without redeploying the whole app). Won't this be a problem? In SunONE Studio, we provide our own JspServlet, which has a somewhat modified reloading logic for JSPs. In addition to checking whether the JSP is newer than the class (in which case it recompiles and reloads the page), it also checks whether the class was modified since the page was last loaded (even if class timestamp JSP timestamp), and if it is, it reloads the page without recompiling it. This will eliminate the need for adding servlet mappings for precompiled JSPs to the web.xml. I think this is a good goal. One advantage of having the servlet mappings is that precompiled JSPs may be selectively exposed, whereas with the proposed scheme, *any* precompiled JSP would be exposed. We could define a config option in JspServlet that would disable the proposed behaviour and require a servlet mapping in order for a precompiled JSP to be exposed. Another advantage is that it would allow having a more lightweitght classloading mechanism for precompiled pages, which would also support lightweight JSP reloading. Comments? -0. A compiled JSP is a servlet, and tools exist to automate the inclusion in web.xml (please have a look at the tomcat-deployer package; I belive it can't get much easier). Its size is irrelevant IMO (if you want it to be smaller, you should look into improving the specification instead). Remy, I agree that it would be useful to have this in the spec. In fact, Ana (in cc:) has already brought this up with Mark Roth. For doing the same thing with regular servlet, we had the InvokerServlet, and look at how much security issues we did run into because of it. If you'd really like to implement your feature, you could add a JSP mode to the InvokerServlet, as there's much functionality in common (and the InvokerServlet creates real Catalina wrappers, with complete stats, etc, like if it had a web.xml mapping). I think that JspServlet is a better place to implement this. The only thing you'd need to change is the reloading logic, and possibly address any classloading issues. Petr Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tag file precompilation
Hi, is Tomcat planning to provide a tag file compiler, which would compile tag files developed outside the web application, into a tag library? Secion JSP.8.4.4 of the JSP 2.0 spec says that this should be possible. Thanks Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] minor Jasper patch
Hello list,
I noticed a minor capitalization error in Jasper. Here's a patch.
Thanks
Petr
RCS file:
/home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Dumper.java,v
retrieving revision 1.4
diff -u -r1.4 Dumper.java
--- Dumper.java 23 Feb 2003 20:57:05 - 1.4
+++ Dumper.java 21 Jul 2003 13:30:18 -
@@ -169,9 +169,9 @@
}
public void visit(Node.UseBean n) throws JasperException {
- printAttributes(jsp:usebean, n.getAttributes(), );
+ printAttributes(jsp:useBean, n.getAttributes(), );
dumpBody(n);
- printString(/jsp:usebean);
+ printString(/jsp:useBean);
}
public void visit(Node.PlugIn n) throws JasperException {
*CVS exited normally with code 1*
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jasper bug exposed through Struts ?
Hello list, recently I filed the following bug against Struts: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20155 However, it is not quite clear that this is a Struts bug. The Struts developers argue in the bug report that this may be a bug in Jasper and its classloading behavior. Or at the very least, that there is a flaw in the jasper-howto document, and in the build.xml example, which should include application jar files in Jspc classpath: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jasper-howto.html Can the Jasper experts please comment on this ? Where is the problem ? Thanks Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: where to download tomcat 4.1 nightly builds?
I was able to find them for Tomcat 5: http://jakarta.apache.org/builds/jakarta-tomcat/nightly-5/ but not for Tomcat 4.1. Speaking of 5.0, is it known when the next milestone/beta of Tomcat 5 will be released ? Is there any scheduled ? Thanks Petr Kevin Jones wrote: ditto for 5.0. Where are the nightlies gone - I've downloaded them in the past but they seem to have disappeared off the site? Kevin Jones Developmentor www.develop.com -Original Message- From: Andreas Schildbach [mailto:[EMAIL PROTECTED]] Sent: 06 January 2003 09:10 To: [EMAIL PROTECTED] Subject: where to download tomcat 4.1 nightly builds? hi all, where can i download the latest tomcat 4.1 nightly build? the jakarta download page gets me to http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/, which appears to be empty. regards, andreas -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Make jasper more graceful wrt. tag library jar files
Team, I submitted a patch which allows jasper to better support iterative development, by not locking jars on Windows, and by allowing redeployment from the same jar: http://issues.apache.org/bugzilla/show_bug.cgi?id=14854 I am not an expert on Tomcat code, so I would welcome if some of you can take a look at it and apply it, if you think it's fine. Thanks Petr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] jasper2 detection of compile time page include changes
I also like the idea, however I would like to see some modifications which would allow this idea to work for application development, not only in deployment environments. When developing applications, the requirement is to see the changes immediately, not after a period of time. So there should be an option to run the check on each request (the option can be implemented as an init parameter of JSPServlet). This option would be used in a development case, and the background thread solution would be used in the live deployment scenario. Note that in the former case, not all files in the application need to be checked, only the ones included in the currently requested page. Petr Jiricka software engineer NetBeans / Forte for Java Sun Microsystems Kin-Man Chung wrote: +1 on the idea. With minor changes, we can also implement a compiler server that compiles out-of-date pages in the background thread. This would greatly improve the response time for accessing the pages, when recompilations are needed. Date: Wed, 24 Apr 2002 10:52:51 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Subject: [PROPOSAL] jasper2 detection of compile time page include changes To: [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit X-Accept-Language: en Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org A common problem Tomcat users have is that Jasper does not detect when a compile time included file %@include file=...% changes so that it can recompile dependent JSP pages. This propsoal maps out a possible solution for this. Create a new class (JspDependency) which is used to store mapping of JSP pages to dependent compile time included files. This class will be created for each web application context and the data it depends upon serialized to a special file in the work directory on context stop, and read from that file on context startup. Proposed filename is JSP_DEPENDENCY.ser. Here is how this integrates into Jasper: On context start instantiate a JspDependency object and read in the dependencies from JSP_DEPENDENCY.ser. If there are dependencies, start a background thread which checks for changes in compile time included files once each 5-15 minutes. Perhaps make this configurable. If changes are detected, set flags for dependent JSP pages which are affected. Using a thread to accomplish this rather than having JSP Load do the dependency checks should reduce the request latency overhead for detecting these changes. The JSP Load method will call a method in JspDependency to determine whether the current page needs to be recompiled due to dependency changes. This will just be a quick test of a boolean, actual dependency checks are done by the background thread. The JSP page compiler will call a method in JspDependency to remove all dependencies for the current JSP page on compile start, then call an add method for each compile time include dependency found. After a JSP page compile has completed any changes to dependencies are written back out to the JSP_DEPENDENCY.ser file. Comments or suggestions? Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Release Plan for Apache Tomcat 4.1
Remy Maucherat wrote: Remy Maucherat wrote: The goal of the Apache Tomcat 4.1 final release is to provide a stable container that supports 100% of the mandatory requirements of the Servlet 2.3 and JSP 1.2 specifications, as well as to improve and add many useful additional features on top of the existing Apache Tomcat 4.0 releases. And what do we do with 4.0? I still have problems with resources and lifecycles there and no enough time to fix them. I plan to propose releasing a 4.0.4 Beta 3 after a few bugfixes are merged (the one for bug 8092, mainly; probably also a few others, like 7575 and 6662 Hi Remy, this is good to hear, do you have any more specific plans and suggested dates for 4.0.4 Final ? Thanks Petr Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Problems with Tomcat 4.0.2 and tag libraries
Hi,
I am running across some weird bugs in Tomcat 4.0.2 which we didn't
encounter in 4.0.1 (or 4.0.2 beta2).
It looks like bugzilla ( http://nagoya.apache.org/bugzilla/ ) is not
working, so I can't look up whether this has been reported.
When I execute a simple web page which uses the Standard Tag Library (JSTL)
EA 3 (see the page source below), I am getting the exception below.
All the JSTL jar files are in WEB-INF/lib and the web.xml file does not
contain any tag library declarations (which I believe is correct by JSP
1.2).
Any ideas ?
Thanks
Petr
--
%@page contentType=text/html%
html
headtitleJSP Page/title/head
body
%@taglib uri=http://java.sun.com/jstl/ea/core; prefix=c%
c:forEach var=row items=$productQuery.rows
TR
TDc:expr value=$row.get('id')//TD
TDc:expr value=$row.get('cdtitle')//TD
TDc:expr value=$row.get('artist')//TD
TDc:expr value=$row.get('country')//TD
TDc:expr value=$row.get('price')//TD
TD
form method=get action=ShopCart.jsp
input type=hidden name=cdId value=c:expr value=$row.get('id')/
input type=hidden name=cdTitle value=c:expr
value=$row.get('cdtitle')/
input type=hidden name=cdPrice value=c:expr
value=$row.get('price')/
input type=submit name=operation value=Add
/form
/TD
/TR
/c:forEach
/body
/html
org.apache.jasper.JasperException: This absolute uri
(http://java.sun.com/jstl/ea/core) cannot be resolved in either web.xml or
the jar files deployed with this application
at
org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:194)
at
org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:174)
at
org.apache.jasper.compiler.JspParseEventListener.processTaglibDirective(JspP
arseEventListener.java:1162)
at
org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEve
ntListener.java:758)
at
org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingList
ener.java:121)
at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:255)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1145)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1103)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1099)
at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:213)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:210)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe
rvlet.java:177)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:189)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:190)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
Re: MBeans dev
- Original Message - From: David Graff [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 10:44 PM Subject: Re: MBeans dev Craig, Thank you for the explanation of that. Very cool deal. The server.xml is pretty ugly to edit manually. It is, but my guess is that soon tools will start to appear that will allow you to edit server.xml through a visual GUI. Regarding JMX, I believe that the J2EE Management APIs (JSR 77) are based on JMX, right ? So supporting JMX is a prerequisite for supporting the J2EE management stuff. Petr - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, February 07, 2002 16:18 Subject: Re: MBeans dev On Thu, 7 Feb 2002, Renato wrote: Date: Thu, 7 Feb 2002 18:14:59 From: Renato [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MBeans dev Hi all, I've seen a lot of development regarding MBean lately and I'm a little lost about what are the new functionality that Catalina will have. Could somebody explain what MBean are ( and for what they are useful ) or give some directives, where I can read about ? ( I know there is plenty of material about Message Beans in J2EE but I imagine these MBeans for Tomcat are somehow different, aren't they ? ) The MBean that is referred to here is a managed bean from the Java Management Extensions (JMX) APIs. You can read about it (and get the spec) from http://java.sun.com/products/JavaManagement. The basic idea is that each component object within Catalina (Engine, Host, Context, Valve, Logger, Realm, and so on) has a corresponding MBean through which it can be created, configured, and removed on-the-fly. In addition, the JMX APIs have the notion of being able to save the configuration state in such a way that it can be reused the next time you start up the server. For Tomcat, we're using the JMX APIs in the administration webapp that will, when it's done, let you never have to touch the server.xml file again -- all of the configuration can be done interactively through a tool. The fact that we're doing it all through MBeans also means that managing a Tomcat 4 instance can also be easily built in to any other management tool that knows how to speak JMX. Thanks for the patience Renato. Craig McClanahan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Why is Tomcat Javadoc bundled with Tomcat 4 ?
Hi, I saw that Tomcat 4.0.2 beta 2 distribution contains directories webapps/tomcat-docs/catalina/docs/api and webapps/tomcat-docs/jasper/docs/api, which include Javadocs for Tomcat code. It seems to me that these are only of interest to developers who want to develop Tomcat and Tomcat extensions, but not to average web application developers, users and administrators. Those who want to develop Tomcat will need to download/check out sources so they can build the Javadoc from sources. Webapps developers have all they need in Tomcat even without these directories. Given that the API documentation significantly increases the size of the Tomcat download bundle, and given its limited usefulness, couldn't these directories be removed from the Tomcat build ? Thanks Petr -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Minor Jasper cleanup
Hi,
the following patch cleans up some relics and unused code from Tomcat 3.2.
Petr
Index: TagLibraryInfoImpl.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compil
er/TagLibraryInfoImpl.java,v
retrieving revision 1.25
diff -u -r1.25 TagLibraryInfoImpl.java
--- TagLibraryInfoImpl.java 12 Dec 2001 18:43:16 - 1.25
+++ TagLibraryInfoImpl.java 9 Jan 2002 11:31:22 -
@@ -109,8 +109,6 @@
* @author Pierre Delisle
*/
public class TagLibraryInfoImpl extends TagLibraryInfo {
- static private final String TAGLIB_TLD = META-INF/taglib.tld;
- static private final String WEB_XML = /WEB-INF/web.xml;
Hashtable jarEntries;
@@ -261,12 +259,6 @@
}
}
}
- }
-
- /** Returns true if the given URI is relative in this web application,
false if it is an internet URI.
- */
- private boolean isRelativeURI(String uri) {
- return (uri.indexOf(':') == -1);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone?
Neeme, I didn't try myself, but the basic scheme for debugging servlets is the following: 1) Modify the Tomcat startup script so JVM runs in the debugging mode - we use something like the following: C:\jdk1.3.1\jre\..\bin\java -classic -Xdebug -Xnoagent -Xrunjdwp:transport=d t_socket,address=pjiricka-ws:1180,suspend=y -Djava.compiler=NONE "-Xbootclasspath:C:\jdk1.3.1\jre\..\lib\tools.jar;C:\jdk1.3.1\jre\lib\rt.jar ;C:\jdk1.3.1\jre\lib\i18n.jar;C:\jdk1.3.1\jre\lib\sunrsasign.jar;C:\jdk1.3.1 \jre\classes;" ..etc, but this may differ based on your platform, JDK version etc. This involves a bit of magic, so you may have to play with it a bit. 2) Set breakpoints in the IDE where you want them 3) In NetBeans, choose Debug - Attach, and in the "Attach" dialog choose Default Debugger (JPDA), SocketAttach, and port=1180 (the number you gave to the VM in the Xrunjdwp parameter. 4) Invoke requests from your web browser, the debugger should stop on the breakpoint. Of course there are many possible combinations, like you can use the JDK 1.1 debugging architecture (which is not as stable as JPDA, though), you can use shared memory access, etc. There is a good overview of possible options at http://java.sun.com/products/jpda/doc/conninv.html . I hope this helps. Petr - Original Message - From: "Neeme Praks" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 23, 2001 2:12 PM Subject: Tomcat 3.3 or 4.0 under Netbeans 3.2 anyone? Is there anyone out there who has gotten Tomcat 3.3 or 4.0 working under Netbeans 3.2 IDE? It doesn't have to be very integrated with the IDE, I just want to debug my servlets, no JSP or anything... I tried, but due to the new (pretty advanced) classloading scheme, I'm not sure how to accomplish this... Can someone give some hints? Petr? Neeme
Re: [STATUS] Tomcat 3.2.2 beta 2
Marc, thanks many times for making this happen. I would like to ask about the status of one particular issue. This is a long outstanding issue whose one effect is that you can not serve files with file names containing multibyte characters. I can still reproduce this problem in 3.2.2 b2. I talked to Costin about this some time ago, and from what I understand, he thinks this problem is difficult to tackle in the 3.2 source base, and that the solution is only possible in 3.3 and 4.0, so I don't much hope that this can be fixed for 3.2.2 final. Either way, I think this should be at least documented in the release notes. To reproduce: 1) Create a file under the document base and name it so it contains characters in a multibyte character set (Japanese, Korean, ...) 2) Type its URL into a web browser I didn't see a bugzilla entry for this, should I create one ? Costin, do you know anything about this issue ? Is my description accurate ? Thanks Petr - Original Message - From: "Marc Saegesser" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 24, 2001 12:02 AM Subject: [STATUS] Tomcat 3.2.2 beta 2 The tomcat_322_b2 tag is now available. The binary and source distributions have been uploaded. I've got a couple more download tests to finish before I update the website and send the announcement messages. If anyone has binaries that they want included in the distribution please send them to me and I'll add them to the download area. Thanks for everyone help getting this release wrapped up.
Re: [report] Classloading problems between Catalina and Cocoon
- Original Message - From: "Pier P. Fumagalli" [EMAIL PROTECTED] To: "James Duncan Davidson" [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: "Cocoon" [EMAIL PROTECTED]; "Tomcat" [EMAIL PROTECTED]; "James Davidson" [EMAIL PROTECTED]; "Servlet API Experts" [EMAIL PROTECTED]; "JAXP Expert Group" [EMAIL PROTECTED] Sent: Friday, February 23, 2001 4:17 AM Subject: Re: [report] Classloading problems between Catalina and Cocoon James Duncan Davidson [EMAIL PROTECTED] wrote: on 2/22/01 8:40 AM, Tom Reilly at [EMAIL PROTECTED] wrote: That said, I think javac is never going to be this compiler, at least not any time soon. They just re-wrote it and I doubt they'll do it again. A more mobile open source project like KJC is probably more realistic. There was very high interest at the time that this was percolating around, but if Bill M. has now left, well... Then its a staffing concern. Rgh. I'm still digging, so... A compiler relying on a ClassLoader instead of single .class files is definitely required, not only in Servlet world, but also in the IDE space. I heard that Forte was having issues with the current JavaC too, we might want to check with them what were their requirements (and if I'm not wrong, they were exactly the same as ours!) (Replying late, as I am behind in my e-mail.) Yes, we (Forte/NetBeans) are having very similar problems as Cocoon and JSP. What we did is we patched Javac to allow loading java files from other sources than java.io.File, and did some other changes, too. We are distributing the patched version with the IDE (see file /modules/ext/javac.jar in the IDE distribution). We tried to submit the changes back to the Javac team (Bill M., I heard), but weren't successful. So maybe we could try again now ? It looks like there is enough interest in the community. Do you know who we should contact now ? Petr Pier -- -- -- Pier P. Fumagalli mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Re: [report] Classloading problems between Catalina and Cocoon
- Original Message - From: "frederic barachant" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 27, 2001 5:14 PM Subject: Re: Re: [report] Classloading problems between Catalina and Cocoon Hi guys. i've been watching the list for a week by now, to understand how things work here. I'm a not so long C/C++ coder (7 years in graphics programming and GUI design) and went to Java last year. I'm very enthusiastic about it, and all products from apache, gnu,... (using gcc, apache and tomcat). Despite these tools are really cool, i still think there is a lack of user friendly interfacing that could bring these tools to the higher level (or lower, depending on how you see that :) The question is are you aware of projects of GUIs for Tomcat and others? If yes, i'm sorry to disturb you, but would like a to have a link anyway. If no, do you think a swing interface could be plugged to tomcat? (not talking of integrating it directly, but more an external remote utility that could operate from anywhere) Have a nice day, peace. Frederic, I am not quite sure what you expect from a GUI tool for Tomcat. All the major IDEs (Forte, JBuilder, VisualAge) allow you to develop servlets/JSPs in the IDE and test and debug them in Tomcat. IDEs in general are quite tightly integrated with servers. And there is more to be expected in the future. There are initiatives to design a standard interface between tools and J2EE servers, which would allow you to manage your servers from a GUI and deploy to it. If you are interested, you can look at http://java.sun.com/aboutJava/communityprocess/jsr/jsr_077_management.html http://java.sun.com/aboutJava/communityprocess/jsr/jsr_088_deploy.html Petr /-/ Frederic "pepe" barachant IO labs GFX and TOOLS for and from Lightwave and Aura I C Q : ASK Visit http://www.io-labs.com and http://www.kframed.com right now ! join our board http://www.io-labs.com/cgi-local/ikonboard/ikonboard.cgi for latest news - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Web application security problem on windows
Does not the following address this issue for Tomcat 3.2 ? (from $TOMCAT_HOME/doc/readme) 6.7 URL's are now case sensitive on all operating systems As of Tomcat 3.2, URL's are case sensitive for all operating systems, including operating systems which have case insensitive file systems, such as Windows. This represents a change from Tomcat 3.1, where URL's were case insensitive on case insensitive OS's. This was done for a number of reasons, security and portability among them. Petr -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 11:21 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Web application security problem on windows Web applications running on Windows (or other systems with non case sensitive file systems) can have secure content accessed by using different case. The problem is a design problem for security-constraints and an implementation problem for WEB-INF For example I have been able to access /WeB-iNf/web.xml on several public servers running tomcat/catalina on NT. The current release of Jetty3 also is vulnerable and probably most other servlet containers. As URLs are case sensitive, the security constraints are bypassed by the different case request. However, once these requests are converted to real filenames or file URLs, the JVM is able to provide a file for them. The impact of this can be significant, as it allows unauthorized access to WEB-INF/web.xml. Furthermore any code in WEB-INF/classes or WEB-INF/lib may be accessed and decompiled and inspected for other vulnerabilities. Also vulnerable are any servlets written using getResource or getRealPath APIs that pass/use pathInfo. If these servlets are protected by a security constraint including alpha numeric characters, then they are vulnerable. For example, a security constraint of /secret/* will not protect a JSP like /secret/private.jsp. As a request to /SeCrEt/private.jsp will correctly bypass the security constraint, while the JspServlet at *.jsp will be able to find a matching jsp source file using getRealPath and/or getResource. Which will be compiled and a result returned. Note that both the security constraint and the JSP servlet are acting correctly for their given path specifications. NB. I have verified that jasper (3.1) is vulnerable to this attack. A general fix will be difficult to find, as many servlets use getRealPath and their own file handling. Furthermore, the real case of a file cannot be determined easily (getCanonicalPath does not return the actual file's case on at least one popular JVM (sun JDK1.2.2 on linux accessing a remote NT file system). Thus a general check for case matching cannot be made. I am currently of the opinion that design changes are needed in the security-constraint mechanism to at least allow case insensitive url-patterns to be used. A better solution would be to specify the behaviour of multiple security constraints, plus allow relaxing constraints. This may even be possible within the current web.dtd? If the most specific security constraint takes precedent (as it probably does), then a reasonable solution can be reached by placing a restrictive constraint on / and then defining less restrictive constraints on more specific paths. This may be a valid interpretation of the current specification, but if so, it needs to be clarified. Note that protection of the WEB-INF directory is separate to considerations of user defined security constraints, other than it probably shares a common implementation. WEB-INF should be protected from case base access regardless of any action taken on security constraints. A final point is that this may show that it may not have been a good idea to place WEB-INF and all it's content within the document root. Perhaps an alternate web application directory layout can be considered with a document root as a sibling or child rather than a parent of WEB-INF. eg. if WEB-INF/docroot exists, then it becomes the document root. regards PS. sorry if this has been raised before in these forums, but my searches could not find anything -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)2074394045 Mort Bay Consulting Australia and UK.Mbl Phone: +44-(0)7775534369 http://www.mortbay.com AU Phone: +61-(0)2 99772395
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
So what are our goals, anyhow ? I think we should concentrate on the following goals (in this order): 1) Provide a quality RI of Servlet 2.2/JSP 1.1. This is something that Tomcat 3.0 claimed to be, but until now we are still not quite sure ! 2) Provide a production quality implementation of Servlet 2.2/JSP 1.1, so the users don't have to ask "JServ ot Tomcat ?". 3) Provide support for future versions of the specifications, as both RI and production quality environment. Now, how do individual versions of Tomcat meet these goals ? Tomcat 3.1 meets neither, IMHO. Tomcat 3.2 does not meet 3), and it meets 1) much better than 3.1, enen though not perfectly. Are we happy with this ? Can we release 3.2 as it is now, or do we want to be 100% sure that we have 1) or even 2) ? Tomcat 4.x meets all, but it's not going to happen for a while. From this I think that clearly there is need for further development in the 3.x codebase, until we fully meet 1) and 2). Namely, we should release 3.2 ASAP. I consider it a big mistake that we (including myself) stopped development of 3.2 and didn't finish it yet. And I wouldn't want us to make the same mistake for 3.3: we don't necessarily need more features and new specification support in 3.3, particularly if that's going to delay the delivery of goal 2) (which should also happen ASAP). So 3.3 makes sense, but without support for the new specs, webdav etc. If we never finish what we started, then (as Rob said) we are a bunch of kids playing around in the org tree. My 2 Kc. Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
