Re: setURLStreamHandlerFactory--why?
If you are concerned about security, allowing a web app to set the default URLStreamHandler is not a very secure thing to do because it gives the webapp the ability to see all URL streams globally in the JVM. When using Tomcat with the Java SecurityManager, web apps are not normally granted permission to set the URLStreamHandlerFactory. Regards, Glenn "Kyle F. Downey" wrote: > > I'm working with the latest b4-dev from CVS. > > Is there a reason the StandardLoader establishes a URLStreamHandlerFactory > (a precious resource, since you can set it only once) just for the "jndi:" > protocol? If all it's used for is to find the protocol handler, that could > be done less intrusively by using the built-in package-based mechanism. > > My reason for wanting to change this is that it makes using custom URL > handlers just about impossible from within a webapp. The package-based > mechanism fails for webapps because java.net.URL loads URLStreamHandlers > only from the system classpath--so unless you put it in the very > lowest-level CLASSPATH (edit catalina.sh or catalina.bat, add along with > bootstrap.jar) it will not be able to instantiate the handler. Installing > your own URLStreamHandlerFactory is a drastic solution, but in this case, > the only (code-level) solution. > > I will submit a patch to replace the URLStreamHandlerFactory with the > naming-pattern based mechanism, if you all consider this a bug rather > than a feature. > > --kd -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Catalina and log4j
Ceki,
This is welcome news!
It isn't clear to me whether the standard servlet API logging methods could use log4j
behind the scense to do logging. This would be very nice, especially if you could
configure log4j logging for each scope (Engine, Host, DefaultContext, Context) in
server.xml.
And even configure different destinations for different types of message levels.
Regards,
Glenn
Ceki Gülcü wrote:
>
> Hello,
>
> I am toying with the idea of migrating catalina logging to log4j. Let me begin by
>saying that I am far from being familiar with catalina internals but I am getting
>there slowly.
>
> After a short initial study and some experimentation, here are some tentative
>conclusions:
>
> 1) The way logging is done currently in catalina is not optimal or, in plain
>English, sucks. Like most project using their own logging API, there are real
>benefits in using a more specialized package like log4j instead of the home-brewed
>solution. More on this below.
>
> 2) Since catalina uses its own class loader, it would be possible to have catalina
>use log4j for logging without affecting other parts of Tomcat. This is probably not
>entirely true since Tomcat uses a logging hierarchy. I'll ignore this issue for the
>time being until I understand the implications. More importantly, existing servelets
>using log4j will be unaffected because they will be using a classloader in a
>different branch of the cl-tree.
>
> Benefits of the move to log4j would be:
>
> - No more need to do
>
> if(debug > 1)
> log("Some message");
>
> instead one would write
>
> log.debug("Some message");
>
> where log is an instance of org.apache.log4j.Category.
>
> - No more need to have a log() method in each catelina class, as in
>
>private static void log(String message) {
> System.out.print("Bootstrap: ");
> System.out.println(message);
> }
>
> in Bootstrap.java. Log4j would use the category name to identify the source of the
>log statement.
>
> - Instead of
>
>try {
> } catch (IOException e) {
> System.out.println("Cannot create URL for " +
> filenames[i]);
>e.printStackTrace(System.out);
> }
>
> one would write
>
> try {
> } catch (IOException e) {
> log.error("Cannot create URL for " + filenames[i], e);
> }
>
> One advantage is that the code becomes shorter. More importantly, the error can be
>reported to any defined log4j appender attached to "log" category instance not just
>to System.out.
>
> - The user would configure logging in Tomcat using a separate configuration file,
>simplifying the actual Tomcat configuration. I am assuming that the DTD for
>sevlet.xml is not part of the Servlet spec so it can be modified without fear of
>contradicting the spec.
>
> Anyway, I am still studying the problem but it looks pretty encouraging for the
>moment. Your comments are welcome. Ceki
>
>
> --
> Ceki Gülcü
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: Catalina and log4j
Ceki Gülcü wrote: > > > One important point to remember is that each webapp classloader could load a fresh >copy of log4j so that each webapp has its own logging universe. > This would significantly increase the memory footprint required for logging in the JVM. I would prefer that log4j be global. Regards, Glenn ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [VOTE] New Committer: Bip Thelin
+1 Welcome aboard Bip Kief Morris wrote: > > I would like to propose Bip Thelin as a new committer. He has made a number > of contributions of patches over the past several months, including SSI and > JDBCRealm, and most recently, is doing solid work on session persistence. > > Kief -- ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Tomcat 4 stderr & stdout
>From their behaviour, it appears that Tomcat 3.x and Tomcat 4 handle use of stderr and stdout differently. Running under unix with either works great for me. But under windows others I work with have had problems. When running Tomcat 4 with -security and -djava.security.debug=all, the security debug output gets dumped to the DOS shell. Any attempt to use the DOS redirect to file fails to capture the output. This makes it nearly impossible to debug Java SecurityManager security exceptions. Anyone know the difference between Tomcat 3.x and Tomcat 4 in how they handle stdout and stderr? Or have any ideas of how to capture the output from Tomcat 4 under windows? Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: jsp's and getPathInfo()
Hi Gus,
Which version of Tocmat are you using? Are you using Apache
as a front end to Tomcat?
I searched bugzilla and didn't find any bugs reported for
any version of Tomcat related to passing pathinfo with
a jsp page request.
Glenn
Gus Mueller wrote:
>
> Hi.
>
> I'm finding that when I try and append extra "path" info to my jsp's like
> I have in the past my servlets, I get back a page not found.
>
> Ok, I can sort of understand that- it's not a real page.. but...
> If I have a url that's like this:
>
> http://localhost/foo/bar.jsp
> and I make a request like this:
> http://localhost/foo/bar.jsp/extra/path/info?querystring
>
> It gives me back a 404... this isn't the case with servlets.
> I can do:
>
> http://localhost/foo/servlet
> as the real servlet and:
> http://localhost/foo/servlet/extra/path/info?querysting
> works just find.
>
> eh? Is this supposed to not work with jsp's? Or have I found a bug I can
> fix?
>
> For what it's worth, I hacked up ContextManager.java and added this at the
> top of processRequest() to get it to at least find my url.
>
> String r = req.getRequestURI();
> int x = 0;
> if ((x = r.indexOf(".jsp/")) > 0) {
> String pathinfo = r.substring(x + 4);
> String without_path = r.substring(0, x + 4);
>
> req.setRequestURI(without_path);
> req.setPathInfo(pathinfo);
> }
>
> Granted the req.getPathInfo() still returns null when I try and use it
> in my jsp's later on, but at least it can find my pages now...
>
> Thoughts? Suggestions? Am I out of my mind?
>
> thanks,
>
> -gus
>
> --
> "Christmas means carnage!" -- Ferdinand, the duck
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: Tomcat 4 stderr & stdout
Ignore this, the difference was that the user was starting Tomcat in a DOS shell instead of as an NT Service. Glenn Nielsen wrote: > > >From their behaviour, it appears that Tomcat 3.x and Tomcat 4 handle > use of stderr and stdout differently. > > Running under unix with either works great for me. > > But under windows others I work with have had problems. > When running Tomcat 4 with -security and -djava.security.debug=all, > the security debug output gets dumped to the DOS shell. Any attempt > to use the DOS redirect to file fails to capture the output. This > makes it nearly impossible to debug Java SecurityManager security exceptions. > > Anyone know the difference between Tomcat 3.x and Tomcat 4 in how they > handle stdout and stderr? Or have any ideas of how to capture the > output from Tomcat 4 under windows? > > Thanks, > > Glenn > > ---------- > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| > MOREnet System Programming | * if iz ina coment. | > Missouri Research and Education Network | */ | > -- -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat 4 stderr & stdout
"Craig R. McClanahan" wrote: > > On Tue, 24 Apr 2001, Glenn Nielsen wrote: > > > >From their behaviour, it appears that Tomcat 3.x and Tomcat 4 handle > > use of stderr and stdout differently. > > > > Running under unix with either works great for me. > > > > But under windows others I work with have had problems. > > When running Tomcat 4 with -security and -djava.security.debug=all, > > the security debug output gets dumped to the DOS shell. Any attempt > > to use the DOS redirect to file fails to capture the output. This > > makes it nearly impossible to debug Java SecurityManager security exceptions. > > > > Anyone know the difference between Tomcat 3.x and Tomcat 4 in how they > > handle stdout and stderr? Or have any ideas of how to capture the > > output from Tomcat 4 under windows? > > > > I'd bet that somewhere in the 3.x code there is a line: > > System.setErr(System.out); > > to reset the error stream to the same as standard output. > > I'm OK with you putting that into Bootstrap.java, as long as you make sure > it works with a security manager installed :-). > Hah! As you can tell from my recent commits I am still making some SecurityManager changes. Some of them were found from trying to run Struts in Tomcat 4 using the SecurityManager and a very restrictive security policy. BTW, great job with struts. It looks very complete and well documented. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Redirecting the Response of a JSP to a String
Jon Stevens wrote: > > on 4/26/01 2:11 PM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote: > > > A fifth solution for just sending email is to use the Mailer taglib at > > http://jakarta.apache.org/taglibs/mailer/ > > > > Regards, > > > > Glenn > > The requested URL /taglibs/mailer/ was not found on this server. > > :-) > > -jon Arghh... Make that: http://jakarta.apache.org/taglibs/doc/mailer-doc/intro.html Thanks Jon! Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Redirecting the Response of a JSP to a String
Just create a sendmail.jsp which uses the mailer taglib, then use to include it, it won't generate any content, just send the email. Pass any parameters as request scope attributes or using There are always tradeoffs. Using runtime includes reduces the memory foot print, but increases the runtime overhead by processing additional JSP pages. Using the compile time include increases the memory foot print, but reduces the runtime overhead. If neither of the above are acceptable, I would try writing a bean that initializes a static string for the template of the email body to send. Then use bean properties to set the values of custom strings to embed in the templated text. To retrieve the final message body, use a get property. If this were something you needed to use frequently, create a base class that does this, then extend it for each different type of data to process. This would meet your goal of having something that can be shared across an application without increasing the memory foot print or incurring the overhead of runtime inclusion of another JSP page. Regards, Glenn Arun Katkere wrote: > > How does this help? I thought you couldn't inside custom tags > that access the body (like the mail tag you mention) due to limitations of > jsp 1.1 ( requires flush to be true) and servlet 2.2 (you > can't wrap response objects). > > i.e., you can' write jsp like: > > from="[EMAIL PROTECTED]" subject="mail taglib"> > > > > > Of course, you can inline it, but then the only way to achieve reuse (i.e., > to access directly or to send it as mail) is with <%@include%>, which is not > as clean (and result in humongous methods which hit JVM limits). > > -arun > > > -Original Message- > > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, April 26, 2001 2:12 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Redirecting the Response of a JSP to a String > > > > > > A fifth solution for just sending email is to use the Mailer taglib at > > http://jakarta.apache.org/taglibs/mailer/ > > > > Regards, > > > > Glenn > > > > Sasha Haghani wrote: > > > > > > Hi there, > > > > > > -- > > > DISCLAIMER: This a Tomcat question, where the solution > > will likely require > > > some tinkering with the implementation. What I'm to do is > > probably a > > > non-standard use case. I think knowledge of the Tomcat internals is > > > required to answer this. I hope this question is > > appropriate for this list > > > -- if not I apologize in advance. Also, sorry for the length... > > > -- > > > > > > I'd like to be able to invoke a JSP on-demand from a Java > > class and redirect > > > the response output stream to a String. This could be used > > to dynamically > > > generate the body of an e-mail, for instance. The key > > difference is that > > > there isn't a *real* corresponding HTTP request or browser > > socket connection > > > which would trigger JSP compilation and execution. > > > > > > I've come up with 3 potential solutions. Any input or > > comment on these from > > > this list is much appreciated. > > > > > > -- > > > SOLUTION 1: Connect to the Servlet Engine like a browser using a > > > URLConnection object and retrieve the response from there. > > > > > > -> This solution is probably the most portable (across > > Servlet Engines) but > > > likely isn't the most performant. > > > > > > -- > > > SOLUTION 2: Using Tomcat Interceptors. > > > > > > -> I don't know anything about these but would there be > > anyway to catch and > > > redirect the response using an Interceptor. I assume such > > a solution would > > > only work with Tomcat. > > > > > > -- > > > SOLUTION 3: A custom Interceptor Servlet with a custom > > Response object. > > > > > > -> A custom method could be called on such a GenericServlet > > and these > > > servlet would include the body of the JSP using the > > > RequestDispatcher.include method. A custom Response object > > would output the > > > Writer stream to a String or StringBuffer. > > > > > > I've attached some sample source code which outlines what I > > have in mind. > > > > > > Could someone give me a reality check on whether this is > > even feasible
Re: Jasper34: sandboxing/Priviledged
That is commented out in the 3.2 jasper branch, and isn't in the Tomcat 4.0 branch of jasper. It looks like you can remove it. Regards, Glenn [EMAIL PROTECTED] wrote: > > Glenn, I hope you're around... > > Can you explain ( again ) the rationale for the doPriviledged() in > PageContextImpl ? > > >From what I see, the release() doesn't do anything special, and > init() does only the System.getProperty - but there are other ways to do > that without a full Priviledged. > > 3.3 seems to work fine in sandbox mode without this ( well, it used to > have similar code but we managed to get rid of it ). > > My main concern is performance ( since doPriviledged tends to be expensive > and init/release happen per request ) ( and of course the "why keep it if > it's not needed" ). > > The other concern is that in one use case for jasper34 it may create > problems. We would like JspC-generated pages to work in any container - > that means the runtime and generated code must be included in the WAR ( > since not all containers are using jasper - yet ). In that case the > runtime will run without priviledges ( well, in general it's better to > keep the permissions low ). > > Costin -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat 3.2.2 beta 4
Yeah, I'll see what I can do to fix this. But It may be a day or two. Marc Saegesser wrote: > > Bloody hell. I was just about to launch into a wonderful tirade about why > we shouldn't have change Tomcat just to work around some buggy compiler from > Microsoft when I realized the real problem isn't what you think it is. > > The problem isn't the definition of the inner class, but the use of the > PrivilegedAction interface. This interface didn't appear until JDK1.2 and > my guess is that your using JDK1.1. > > Tomcat 3.2.x, because it implements the Servlet 1.1 specification must > maintain compatibility with JDK1.1 so this is a real Tomcat bug and it will > need to be fixed before releasing Tomcat 3.2.2. > > Glenn, can you take a look at this? > > > -Original Message- > > From: Dave Oxley [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 01, 2001 12:32 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Tomcat 3.2.2 beta 4 > > > > > > I posted this before but got no response. > > > > The change to SessionUtil.java 1.5.2.2 to 1.5.2.3 (3.2.1->3.2.2b1) has > > caused the Microsoft Virtual Machine to fall over when running > > Tomcat. The > > M$ VM does not like internal classes defined within methods (I > > think this is > > the problem) and throws a NoClassDefFoundException. > > > > I am running Windows2000 with IE5.5(a vm update came with 5.5) > > although it > > is probably the same on all M$ VMs. > > > > This means that I cannot debug servlets in Visual J++ which is a real > > problem for us. (Until we find an IDE as stable and fast as VJ++!) > > > > Dave > > [EMAIL PROTECTED] > > > > _____ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat 3.2.2 beta 4
Costin,
The code you are referring to in 3.3 makes it easy to abstract out
jdk 1.2 dependencies at build and runtime? If so, I have no
problems with you back porting that into 3.2.
If these classes are generic enough, perhaps they could be put
into the commons.
Regards,
Glenn
[EMAIL PROTECTED] wrote:
>
> On Tue, 1 May 2001, Marc Saegesser wrote:
>
> > Costin,
> >
> > The toLowerCase() patch look OK.
> >
> > If Glenn can fix the session id stuff easily then I think thats the best
> > approach right now.
>
> Adding the jdkcompat package can't hurt - it'll be a minimal change in
> SessionUtil plus the addition of 3 classes.
>
> I'll wait for Glenn - it's probably a 15 minutes fix if we use the stuff
> from 33.
>
> Costin
>
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, May 01, 2001 2:58 PM
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED]
> > > Subject: RE: Tomcat 3.2.2 beta 4
> > >
> > >
> > > Marc,
> > >
> > > I can quickly backport the jdkcompat package from 3.3 - it would be
> > > cleaner than hacking generateSessionId.
> > >
> > > The package is "standalone", doesn't depend on any 3.3 feature - and
> > > it's quite simple and effective.
> > >
> > > Also, if you could review the following patch that will fix "case
> > > sensitive match for host names " ( the patch is ported from 3.3 ).
> > >
> > > Costin
> > >
> > > Index: src/share/org/apache/tomcat/util/PrefixMapper.java
> > > === RCS
> > > file:
> > > /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/PrefixMa
> > > pper.java,v
> > > retrieving revision 1.3.2.2 diff -r1.3.2.2 PrefixMapper.java
> > > 125a126
> > > > host=host.toLowerCase();
> > > 165a167
> > > > host=host.toLowerCasse();
> > > 181a184
> > > > host=host.toLowerCase();
> > > 201c204
> > > < if( host!=null )
> > > ---
> > > > if( host!=null ) {
> > > 202a206,209
> > > > if( myMap==null ) {
> > > > myMap=(PrefixMapper)vhostMaps.get( host.toLowerCase() );
> > > > }
> > > > }
> > >
> > >
> > >
> >
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: [VOTE] New Committer: Kevin Seguin
+1 I am very interested in mod_jk/ajp13 support for Tomcat 4. GOMEZ Henri wrote: > > I would like to propose Kevin Seguin as a new committer. > > He make a great job in developping the ajp13 protocol > for Tomcat 4.0 and this code will be a great help for > sites wanting to upgrade from 3.2.x to 4.0 while still > using mod_jk > > Henri -- ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: JSP re-compile performance under heavy load
You might consider changing the design of how you cache your data. There are several JSP taglibs out that implement caching of data. You can also do a runtime include of a static file instead of a JSP. Regards, Glenn [EMAIL PROTECTED] wrote: > > Hi All, > > I'm curious if any of you have code that tests the performance of JSP > recompiles while tomcat is under load. I've read that some changes were > made in this area recently, and it directly effects a design I'm > considering. > > If performance testing code exists, could someone send it to me? > > Thanks, > > Jason Henriksen > > P.S.: (If you're curious how I got into this sitation, here's the > rationale: ) > > Basically, I'm treating the disk drive as a cache. I expect to have well > over 5,000 different query result pages, each of which could take over a > minute to generate because they require some fairly thick SQL. The good > news is that only about 100 of them will be 'active' at any given time. > The non-active pages, can be built, saved on disk and then safely ignored > (Thus being served with no database hit). However, when the object in the > DB changes I should be able to show the update on the JSP page within 15 > minutines of the database change occuring. > > My plan is to generate a page for each of my 5,000 objects up front and > then wait until a DB object changes. When it does, I'll regenerate the > page for just that object. That way everyone see's the new static page, > and the database can continue doing it's regular job of managing user > accounts, and other such non-cacheable business. (The disk cache is also > preferable to holding the results for all 5000 object queries in memory > because the results will be fairly large. My disk space is near infinite, > but my memory is not). > > So if I have 1000 people looking at the results for Object A when it needs > to be re-compiled how will Tomcat respond? I know it does fine job > handling updated JSPs in a development environment, I'm curious how it's > expected to perform doing that kind of operation under load. (I understand > that my mileage my vary, I'm just looking for what you guys would expect to > happen, or do you suggest some other desgin?) Thus, I'm look for test-code > and/or result numbers. > > -- > Warning : The information contained in this message may be privileged and >confidential and protected from disclosure. If the reader of this message is not the >intended recipient, you are hereby notified that any dissemination, distribution or >copying of this communication is strictly prohibited. If you have received this >communication in error, please notify us immediately by replying to this message and >then delete it from your computer. All e-mail sent to this address will be received >by the Providian Financial corporate e-mail system and is subject to archiving and >review by someone other than the recipient. > > == -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [PROPOSAL/VOTE] New Repositories for Collaborative Development
+1 "Craig R. McClanahan" wrote: > > Over the last few weeks, there has been a lot of discussion on > collaborative development, across the various Tomcat branches, on two > major areas: > > * Web connectors > > * A new Jasper (the "jasper34" proposal) > > and efforts have begun in the HEAD branch "proposals" directory of the > jakarta-tomcat repository. I'd like to propose a slightly different > approach -- create two new repositories (perhaps > "jakarta-tomcat-connectors" and "jakarta-tomcat-jasper") to be the homes > of these development efforts, independent of any of the existing code > bases. The reasoning for this approach is as follows: > > * Avoid any appearance of politics or attachment based > on which repository the code is hosted in > > * Make it easier to enforce the technical separation of > this code from any existing Tomcat base code (you have > to declare external dependencies pretty directly) > > * Avoid the need for everyone working on these shared > components to have *all* of the Tomcat code on all branches > checked out all the time -- you can focus on the repository > for your favorite Tomcat plus the common stuff you care about > > * Smaller CVS repositories means faster CVS checkouts for everyone > on daedalus, on all projects > > Because these repositories would both be part of the overall Tomcat > subproject, all existing and new Tomcat committers would have commit > access to both of them, just as we all have access to "jakarta-tomcat" and > "jakarta-tomcat-4.0" today. > > Comments? Questions? Votes? > > Craig McClanahan -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [PROPOSAL/VOTE] Tomcat 4.0 Beta 4 Release
+1 I am currently trying to track down a problem related to use of the SecurityManager with jndi named class/jar files in a web app under MS Window systems. It works fine under Unix. Regards, Glenn "Craig R. McClanahan" wrote: > > Now that the "Proposed Final Draft 2" versions of the Servlet 2.3 and JSP > 1.2 specs have been published (with Tomcat 4.0 updated to support the > latest changes), and a ton of bug fixes have been made, I would like to > propose that we create a "Tomcat 4.0 Beta 4" release as follows: > > Release Manager: Craig McClanahan > Code Freeze: Thursday, May 10, 2001 at 05:00pm Pacific Time > > See the file "RELEASE-NOTES-4.0-B4.txt" for a reasonably up-to-date list > of the changes to date. This document will be updated with any additional > changes that are made, plus a list of known outstanding issues. > > Between now and the code freeze, I'd like us to focus on fixing > outstanding bugs and catching the configuration documentation up to > date. I'm OK with continuing work on the new distributed session stuff in > the mean time (as long as it is not enabled in the default > configuration), but please hold off on making substantive changes in the > core container until after the Beta 4 release. > > Comments? Votes? > > The usual rules apply: > [ ] +1 = I agree with this proposal and will support it > [ ] +0 = I agree with this proposal, but do not have time to support it > [ ] -0 = I do not agree with this proposal, but don't want to try >to block it > [ ] -1 = I do not agree with this proposal (requires reasons) > > Craig -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Bad link to tomcat 3.2.2beta3 on tomcat site
The link on the below page is to Tomcat 3.2.2 beta 3 instead of beta 4, beta 3 doesn't exist on the server. http://jakarta.apache.org/site/binindex.html Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: problems running a servlet that uses core catalina classes
In Tomcat 4 the "core" catalina classes in servlet/lib/catalina.jar are hidden from servlets. A servlet should use the standard Servlet 2.3 classes to access public information for the request. Your servlet would not be portable across differenct servlet containers if you used internal servlet container classes. In addition, making those interal tomcat classes visible to web applications could allow the security of the servlet container and web applications to be compromised. Regards, Glenn Fabien Le Floc'h wrote: > > Hello, > > I am sorry to bother you. But I am trying to write a servlet that uses some core >apache classes and I have problems running it. > > - If I use a war archive, tomcat does not find the tomcat classes/servlet classes >when it starts the servlet. (ClassNoDefFound error). If I then add the catalina.jar >and servlet.jar to the classpath, I have a conflict between classes loaded >dynamically by tomcat and classes in the classpath. (More precisely I have an object >whose class is ServletWrapper but is not an instance of ServletWrapper. This is >because (I guess) the object is created by the Tomcat classloader and it is compared >with an instance of the classpath objects), > > - If I put the jar file in the common/lib directory, it finds the servlet classes >but not the tomcat classes. > > - If I put the jar file in server/lib directory, it does not load my servlet. > > The only way I can make it work is to put it in the catalina.jar file. But that is >not nice at all. > > Could someone help me with this? > > Thank you. > > Fabien Le Floc'h > > P.S.: I was wondering if it was user or developer oriented... As I want to use core >Tomcat classes I thought it was developer but maybe I am wrong. Then I apologize. -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Bad link to tomcat 3.2.2beta3 on tomcat site
Jon Stevens wrote: > > on 5/8/01 3:15 PM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote: > > > The link on the below page is to Tomcat 3.2.2 beta 3 instead > > of beta 4, beta 3 doesn't exist on the server. > > > > http://jakarta.apache.org/site/binindex.html > > > > Thank you for asking for permission to commit to the jakarta-site2 module. > You can now fix it yourself. If you need help understanding things, RTM: > > <http://jakarta.apache.org/site/jakarta-site2.html> > > :-) > > -jon > I didn't ask for permission, but thanks for adding me. ;-) Looks like Marc already took care of it. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: problems running a servlet that uses core catalina classes
Look at the Manager servlet for Tomcat 4 or the admin servlet for Tomcat 3.x.
Regards,
Glenn
Ted Neward wrote:
>
> Glenn, just out of curiosity, how could someone create an "administrative"
> web-app for controlling and administering Tomcat? (One of the things I've
> been toying with was the idea of doing just such an "administrative"
> interface--installing new webapps, restarting, viewing statistics,
> monitoring the server's progress, and so on.)
>
> Ted Neward
> {.NET||Java} Instructor, DevelopMentor (http://www.develop.com)
> http://www.javageeks.com/~tneward/index.html
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> > Behalf Of Glenn Nielsen
> > Sent: Tuesday, May 08, 2001 5:12 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: problems running a servlet that uses core catalina classes
> >
> >
> > In Tomcat 4 the "core" catalina classes in
> > servlet/lib/catalina.jar are hidden
> > from servlets. A servlet should use the standard Servlet 2.3 classes to
> > access public information for the request. Your servlet would
> > not be portable
> > across differenct servlet containers if you used internal servlet
> > container classes.
> >
> > In addition, making those interal tomcat classes visible to web
> > applications
> > could allow the security of the servlet container and web
> > applications to be compromised.
> >
> > Regards,
> >
> > Glenn
> >
> > Fabien Le Floc'h wrote:
> > >
> > > Hello,
> > >
> > > I am sorry to bother you. But I am trying to write a servlet
> > that uses some core apache classes and I have problems running it.
> > >
> > > - If I use a war archive, tomcat does not find the tomcat
> > classes/servlet classes when it starts the servlet.
> > (ClassNoDefFound error). If I then add the catalina.jar and
> > servlet.jar to the classpath, I have a conflict between classes
> > loaded dynamically by tomcat and classes in the classpath. (More
> > precisely I have an object whose class is ServletWrapper but is
> > not an instance of ServletWrapper. This is because (I guess) the
> > object is created by the Tomcat classloader and it is compared
> > with an instance of the classpath objects),
> > >
> > > - If I put the jar file in the common/lib directory, it finds
> > the servlet classes but not the tomcat classes.
> > >
> > > - If I put the jar file in server/lib directory, it does not
> > load my servlet.
> > >
> > > The only way I can make it work is to put it in the
> > catalina.jar file. But that is not nice at all.
> > >
> > > Could someone help me with this?
> > >
> > > Thank you.
> > >
> > > Fabien Le Floc'h
> > >
> > > P.S.: I was wondering if it was user or developer oriented...
> > As I want to use core Tomcat classes I thought it was developer
> > but maybe I am wrong. Then I apologize.
> >
> > --
> > --
> > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> > MOREnet System Programming | * if iz ina coment. |
> > Missouri Research and Education Network | */ |
> > --
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: Class Reloading
[EMAIL PROTECTED] wrote: > > On Fri, 11 May 2001, Craig R. McClanahan wrote: > > > > The introspection problem is not very serious - it doesn't work if > > > sandboxing is enabled ( at least from what I know - if it works then it's > > > a very serious VM bug ). > > > > > > > It doesn't work if you start Tomcat 4.0 with a security manager. That's > > what I'm cleaning up, because it's the right long term direction. But > > we're also going to add facades for those who want to run without a > > security manager installed. > > If the security manager is not used everything has AllPermissions - the > fact that someone can access the internal objects is quite small compared > with the fact that it could call System.exit() and read/change any file > that tomcat has access to. > > Anyway: +1 on facades :-) > > Costin Exactly. If you are concerned about security you need to run Tomcat with -security so that the Java SecurityManager is used. It doesn't make sense to implement code for container security in Tomcat that doesn't use the SecurityManager. Why reinvent the wheel? Regards. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Catalina and log4j
"Craig R. McClanahan" wrote: > > On Sat, 21 Apr 2001, Glenn Nielsen wrote: > > > Ceki Gülcü wrote: > > > >> One important point to remember is that each > >> webapp classloader could load a fresh copy of log4j so that each > >> webapp has its own logging universe. > > > > > This would significantly increase the memory footprint required for > > logging in the JVM. I would prefer that log4j be global. > > > > Log4J is nothing compared to having multiple XML parsers in memory :-) > > Actually, it is technically feasible to do this either way -- if you put > the Log4J JAR file in common/lib instead of server/lib it becomes > available to the webapps as well. The disadvantage is that the static > variables really are global instead of once per web app (which they would > be if each webapp installed its own copy), so they would share the same > set of Log4J categories, appenders, and so on. > Comments about per webapp vs global installation of jar's: Tomcat 4 defers to the web application ClassLoader first before loading classes from the parent classloaders, as suggested by the Servlet 2.3 spec. Bloating of JVM memory usage due to alot of web applications all having WEB-INF/lib/foo.jar installed could cause a problem with scaling if there are 100's of web applications installed. In our use of Tomcat 4 we will be installing all of the most commonly used taglib jar files and API's in $CATALINA_HOME/lib so they can be shared by multiple web applications. Of course the customer can always override this by installing the jar file locally in WEB-INF/lib, but we will try to encourage them to use the globally installed versions if they can. Ideas for log4j: log4j itself could be installed for Tomcat in $CATALINA_HOME/server/lib. Logging categories, priorities, and destinations could be configured in server.xml scoped at the Engine, Host, DefaultContext, and Context levels. The normal servletAPI log methods would use log4j under the hood. The Tomcat 4 global log4j instance would not be visible to individual web applications. In addition, create a JNDI Factory for log4j so that a logging category for a web application can be exported to it using a JNDI logging resource named something like "jndi:/comp/env/log". That resource would only make available to the web application the few methods needed to determine if a logging priority was enabled and to log a message at a priority. This would allow a web application to use log4j without making log4j internals visible to the web application. A manager servlet could even be written to allow changing of log priorities for the web application. And a tag library provided for use in JSP pages. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Redirecting the Response of a JSP to a String
A fifth solution for just sending email is to use the Mailer taglib at http://jakarta.apache.org/taglibs/mailer/ Regards, Glenn Sasha Haghani wrote: > > Hi there, > > -- > DISCLAIMER: This a Tomcat question, where the solution will likely require > some tinkering with the implementation. What I'm to do is probably a > non-standard use case. I think knowledge of the Tomcat internals is > required to answer this. I hope this question is appropriate for this list > -- if not I apologize in advance. Also, sorry for the length... > -- > > I'd like to be able to invoke a JSP on-demand from a Java class and redirect > the response output stream to a String. This could be used to dynamically > generate the body of an e-mail, for instance. The key difference is that > there isn't a *real* corresponding HTTP request or browser socket connection > which would trigger JSP compilation and execution. > > I've come up with 3 potential solutions. Any input or comment on these from > this list is much appreciated. > > -- > SOLUTION 1: Connect to the Servlet Engine like a browser using a > URLConnection object and retrieve the response from there. > > -> This solution is probably the most portable (across Servlet Engines) but > likely isn't the most performant. > > -- > SOLUTION 2: Using Tomcat Interceptors. > > -> I don't know anything about these but would there be anyway to catch and > redirect the response using an Interceptor. I assume such a solution would > only work with Tomcat. > > -- > SOLUTION 3: A custom Interceptor Servlet with a custom Response object. > > -> A custom method could be called on such a GenericServlet and these > servlet would include the body of the JSP using the > RequestDispatcher.include method. A custom Response object would output the > Writer stream to a String or StringBuffer. > > I've attached some sample source code which outlines what I have in mind. > > Could someone give me a reality check on whether this is even feasible or > advisable. Particularly with regard to rolling my own Response > implementation which redirects Writer to a String. Would this kind of > kludge cause any problems for Tomcat? > > -- > Any comments, help or suggestions that anyone can provide are much, much > appreciated. Also, I'd love to hear alternative solutions. Thanks so much. > > Regards, > > Sasha Haghani, > Toronto, Canada. -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: FW: Java World Editors' Choice Awards
I will be there also. And yes, it is always nice to put faces to emails. :-) Marc Saegesser wrote: > > I will be there. I'm looking forwarding to putting faces to lots of names. > > I *will* get 3.2.2 out the door before I leave for JavaOne. Really, I will. > > Marc "Just ship it" Saegesser > > > -Original Message- > > From: Arieh Markel [mailto:[EMAIL PROTECTED]] > > Sent: Monday, May 14, 2001 5:53 PM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Re: FW: Java World Editors' Choice Awards > > > > > > > > > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > > > Delivered-To: mailing list [EMAIL PROTECTED] > > > User-Agent: Microsoft-Entourage/9.0.1.3108 > > > Subject: FW: Java World Editors' Choice Awards > > > From: Jon Stevens <[EMAIL PROTECTED]> > > > To: tomcat-dev <[EMAIL PROTECTED]> > > > Cc: <[EMAIL PROTECTED]> > > > > > > I'm totally amazed no one from here has responded to Scott yet > > (especially > > > you Sun people). > > > > > > Come on people, please get in touch with him. > > > > For what is worth, (having contributed some code to TC 3.2) > > I will be at JavaOne during that week. > > > > Is anybody else going to be present there ? > > > > Arieh > > > > > > > > -jon > > > > > > -- Forwarded Message > > > From: [EMAIL PROTECTED] > > > Date: Mon, 14 May 2001 11:13:13 -0700 > > > To: [EMAIL PROTECTED] > > > Subject: Java World Editors' Choice Awards > > > > > > Jon, > > > > > > I haven't heard from anyone yet. Can you represent Tomcat at > > the ceremony? > > > It'll be on Tuesday evening , June 5, here in San Francisco. Up to four > > > people can attend. If yes, would you send me your contact > > information, as > > > outlined in the email below? > > > > > > Regards, > > > Scott > > > > > > - Forwarded by Scott Plamondon/ITWORLD on 05/14/2001 11:13 AM - > > > > > > Dear Jakarta Project, > > > > > > Congratulations! JavaWorld has selected Jakarta Project's > > Tomcat 3.2 as a > > > finalist in the Most Innovative Java Product category of our Editors' > > > Choice Awards. > > > > > > Established in 1997, the awards recognize those innovative companies, > > > organizations, and individuals committed to developing new Java > > tools and > > > technologies that drive the platform forward. More than 100 products and > > > technologies were nominated by vendors, readers, as well as JavaWorld > > > editors and writers. We'll publish the complete list of > > finalists in each > > > category by 5 p.m. PDT on Friday, May 4 (go to: > > > http://www.javaworld.com/jw-05-2001/jw-0504-finalists.html). > > > > > > As a finalist, members of your product team will be invited to attend > > > JavaWorld's Editors' Choice Awards ceremony at the JavaOne > > Conference and > > > Expo from June 4-8 in San Francisco, where a winner in each > > category will > > > be announced. Invitations to the ceremony, with the date and > > location, will > > > be mailed in mid-May. > > > > > > With that in mind, I need to confirm your organization's contact > > > information. Please let me know to whom we should send the invitation at > > > your earliest convenience: > > > > > > Contact Name: > > > Title: > > > Product Name: > > > Address: > > > City, State, Zip: > > > Phone: > > > Email: > > > > > > If you have any questions, please don't hesitate to email me at this > > > address or call 415-975-2651. > > > > > > Regards, > > > > > > Scott Plamondon > > > Senior Editor > > > JavaWorld > > > [EMAIL PROTECTED] > > > 415-975-2651 > > > > > > > > > > > > > > > -- End of Forwarded Message > > > > -- > > Arieh Markel Sun Microsystems Inc. > > Network Storage500 Eldorado Blvd. MS UBRM11-194 > > e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 > > Pray for snow Phone: (303) 272-8547 x78547 > > (e-mail me with subject SEND PUBLIC KEY to get public key) -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper performance
I would like to propose that the new Jasper require jdk 1.2. The current version of jasper can be used by those who have jdk 1.1.x. Then we don't have to worry about jumping through hoops trying to get the new jasper to run both in 1.1 and 1.2, plus we can optimize for 1.2. In addition JSP 1.2 will require jdk 1.2 or greater. Regards, Glenn [EMAIL PROTECTED] wrote: > > > Jasper performance has already been identified as an area needing > > improvement. > > > > Discussions and work on this has already started in the main tomcat > > branch in CVS jakarta-tomcat/proposals/jasper34, but this may be > > moving to the CVS repository jakarta-tomcat-jasper. > > > > This work just started recently, I don't know when it will be ready. > > It will take few months - it's not that easy. > > We already added tag pooling in tomcat3.3, and that have a significant > effect on performance if you are using tags - but that's just the > beginning. > > The first step is to reorganize the code. Then we'll try to make the code > generator more customizable ( probably by using XSLT for some of the > operations ). The real performance enhancement will come when we start > tunning the generated code - there are many ideas around, but we need the > refactoring first. > > BTW, jasper will share most of the code for the 1.1 and 1.2 APIs, so all > enhancements will be available in both 3.x and 4.x ( and other containers > as well ). > > If you have ideas, code or opinions - please get involved, we need you :-) > > Costin > > > > > Rickard Öberg wrote: > > > > > > Hi! > > > > > > We are using Tomcat/JBoss and are pleased with the actual functionality. > > > What is killing us right now is the performance of the code generated by > > > Jasper, especially when using taglibs in complex ways. The generated > > > code is way too unoptimized. > > > > > > So, if this has not been asked before (in which case a RTFA is ok, > > > although I've looked already), my question is: > > > When will Jasper be rewritten? > > > Are there any such projects underway now? > > > Have there been any discussions about this yet? > > > Am I the only one seeing this problem, or are more people concernced > > > about it? > > > > > > Thanks, > > > Rickard > > > > > > -- > > > Rickard Öberg > > > Software Development Specialist > > > xlurc - Xpedio Linköping Ubiquitous Research Center > > > Author of "Mastering RMI" > > > Email: [EMAIL PROTECTED] > > > > -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Webapp initialization (tomcat 4)
Tomcat 4.0 supports JNDI and JDBC DataSource pooling. I configure a named JNDI JDBC DataSource in the , which is then available to all web applications for a Host. Here is an example from my server.xml (sensitive paramater data replaced with generic) userdbuserid passworddbpasswd driverClassName org.gjt.mm.mysql.Driver driverName jdbc:mysql://localhost/test factory org.apache.naming.factory.SendMailFactory smtphost your.smtp.host user joeuser from [EMAIL PROTECTED] Regards, Glenn Peter Mutsaers wrote: > > Hello, > > I have some questions on webapp initialization. > > sorry to send this to both tomcat-user and tomcat-dev; since I use > tomcat 4 I wasn't sure where to send this to. I hope that my questions > are answered by some brand new, not yet documented features of > tomcat-4 :) > > Browsing through documents, it seems like the only way to create some > initial objects (such as a JDBC connection pool) in the ServetContext > is to create a Servlet with load-on-startup, which then in its init() > method can do some initialization. > > This seems a bit clumsy to me, since I don't really need the Servlet > to handle requests. I just need some hook to initialize my > ServletContext with some objects. > > Are there other (better) ways to do this? > > If not: can I force the Servlet to be destroyed after my init() is > ready? > > Another topic: Am I correct in believing that > ServletContext.getContext(uri) is the only way to obtain stuff from > another webapps' ServletContext? > > In fact what I would like is to create a JDBC Connection Pool to be > shared amongst various webapps. I could create this pool Object in one > webapp (via the clumsy Servlet load-on-startup), then copy a reference > to the ServletContexts of the other webapps. This creates some > ordering problems (the other webapps may not run until the webapp > setting up the connection pool is ready). > > It would be nicer if Tomcat, before initialising the webapps, would > offer the possibility for me to run some code. This code (in my case > creating the pool) should then create some initial context that all > webapps can access (in order to create a reference in their own > ServletContext). > > I was hoping that in servlet.xml, within the scope I could > specify some Object to be shared between all 's. > > Is something like this available? > > After a day of searching through specs, mailing-list archives etc I > hope someone can help me :) > > -- > Peter Mutsaers | Dübendorf| UNIX - Live free or die > [EMAIL PROTECTED] | Switzerland | Sent via FreeBSD 4.3-stable -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Java World Editors' Choice Awards
Although I will be at JavaOne, my contributions to Tomcat 3.2 is negligible when compared to the whole, really only the Java SecurityManager with some mentoring from Costin. I will be happy to watch others accept if Tomcat 3.2 gets the award. I propose that a list of tomcat developers who will be attending Java One be compiled, then vote on who we would like to represent us if Tocmat 3.2 gets the award. Then those names can be sent to Scott. Regards, Glenn "Craig R. McClanahan" wrote: > > On Tue, 15 May 2001, Marc Saegesser wrote: > > > Jon, > > > > Sorry, I thought someone had already done that. I'll send Scott my contact > > info since I'm the one trying to push this puppy out the door. > > > > Has anyone else already responded to Scott's email? > > > > Yes ... and I'll be there (barring unavoidable schedule > conflicts). > > Costin, you were heavily involved in 3.2 as well, so it would be good if > you could go. > > Craig > > > > -Original Message- > > > From: Jon Stevens [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, May 15, 2001 11:19 AM > > > To: tomcat-dev > > > Subject: Re: Java World Editors' Choice Awards > > > > > > > > > PEOPLE! > > > > > > Reply to Scott! > > > > > > -jon > > > > > > on 5/15/01 2:41 AM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote: > > > > > > > I will be there also. And yes, it is always nice to put faces > > > to emails. :-) > > > > > > > > Marc Saegesser wrote: > > > >> > > > >> I will be there. I'm looking forwarding to putting faces to > > > lots of names. > > > >> > > > >> I *will* get 3.2.2 out the door before I leave for JavaOne. > > > Really, I will. > > > >> > > > >> Marc "Just ship it" Saegesser > > > >> > > > >>> -Original Message- > > > >>> From: Arieh Markel [mailto:[EMAIL PROTECTED]] > > > >>> Sent: Monday, May 14, 2001 5:53 PM > > > >>> To: [EMAIL PROTECTED] > > > >>> Cc: [EMAIL PROTECTED] > > > >>> Subject: Re: FW: Java World Editors' Choice Awards > > > >>> > > > >>> > > > >>> > > > >>>> Mailing-List: contact [EMAIL PROTECTED]; > > > run by ezmlm > > > >>>> Delivered-To: mailing list [EMAIL PROTECTED] > > > >>>> User-Agent: Microsoft-Entourage/9.0.1.3108 > > > >>>> Subject: FW: Java World Editors' Choice Awards > > > >>>> From: Jon Stevens <[EMAIL PROTECTED]> > > > >>>> To: tomcat-dev <[EMAIL PROTECTED]> > > > >>>> Cc: <[EMAIL PROTECTED]> > > > >>>> > > > >>>> I'm totally amazed no one from here has responded to Scott yet > > > >>> (especially > > > >>>> you Sun people). > > > >>>> > > > >>>> Come on people, please get in touch with him. > > > >>> > > > >>> For what is worth, (having contributed some code to TC 3.2) > > > >>> I will be at JavaOne during that week. > > > >>> > > > >>> Is anybody else going to be present there ? > > > >>> > > > >>> Arieh > > > >>> > > > >>>> > > > >>>> -jon > > > >>>> > > > >>>> -- Forwarded Message > > > >>>> From: [EMAIL PROTECTED] > > > >>>> Date: Mon, 14 May 2001 11:13:13 -0700 > > > >>>> To: [EMAIL PROTECTED] > > > >>>> Subject: Java World Editors' Choice Awards > > > >>>> > > > >>>> Jon, > > > >>>> > > > >>>> I haven't heard from anyone yet. Can you represent Tomcat at > > > >>> the ceremony? > > > >>>> It'll be on Tuesday evening , June 5, here in San Francisco. > > > Up to four > > > >>>> people can attend. If yes, would you send me your contact > > > >>> information, as > > > >>>> outlined in the email below? > > > >>>> > > > >>>> Regards, > > > >>>> Scott > > > >>>
Re: Webapp initialization (tomcat 4)
Peter Mutsaers wrote: > > >> "Glenn" == Glenn Nielsen <[EMAIL PROTECTED]> writes: > > Glenn> Tomcat 4.0 supports JNDI and JDBC DataSource pooling. I > Glenn> configure a named JNDI JDBC DataSource in the > Glenn> , which is then available to all web > Glenn> applications for a Host. > > Glenn> Here is an example from my server.xml (sensitive paramater > Glenn> data replaced with generic) > > Thanks, this looks like the way to do it. > > I guess I have to put my implementing class in $CATALINA_HOME/classes? > Or in $CATALINA_HOME/lib/classes?!? > $CATALINA_HOME/common/lib or $CATALINA_HOME/common/classes > Is this, and the tag, somewhere documented? for example I'm > wondering about the auth= attribute. > The only docs I know of at this time are the examples in server.xml or the source. > -- > Peter Mutsaers | Dübendorf| UNIX - Live free or die > [EMAIL PROTECTED] | Switzerland | Sent via FreeBSD 4.3-stable -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper performance
I totally agree with this. Improving performance of JSP page translation
or compilation are very low priorities. Runtime performance is important,
and as Christopher mentioned, good error reporting is very important.
Glenn
Christopher Kirk wrote:
>
> >From my view, the problem with JSP->Java->Class isn't performance its
> debugging. JSP is hard to work with when you make a mistake, very often the
> error message is less than helpful. A very large step in improving this is
> by making the line number given by the stack trace match the line numbers of
> the JSP page. This currently is not the case because of the intermediate
> step of a java file. It would be beneficial to compile JSP straight to Java,
> complete with debugging information included in the class file.
>
> - Chris.
>
> > -Original Message-
> > From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]]
> > Sent: 17 May 2001 12:51
> > To: [EMAIL PROTECTED]
> > Subject: RE: Jasper performance
> >
> >
> > I dont know if I really understood. You (some) are
> > thinking to compile a
> > jsp using xslt. I didnt know that that was possible. I mean,
> > can a jsp be
> > loaded as a dom object? I think that it cannot because a nice
> > guy can write
> > some code like <% out.writeln(""); %> and that is, it
> > is not more xml
> > compliant. (please tellme if I am wrong).
> > If the problem is the compilation time I can hardly
> > believe that we can
> > do something faster that a java compiler. Not because we dont have the
> > skill, but because there are groups working in this kind of
> > implementations.
> > We should be blindly proud to think out compiler would be faster than
> > theirs. Also, I consider that a waste of time.
> > Let me do some guessing. I know, I should be reading the
> > code, but I
> > have been realy overloaded for the last months. Lets see if I have
> > understood the problem.
> > Saving a file for compilation is slow. So we need a
> > faster solution.
> > But, why is it slow?
> > It sounds like we are saving the .java in file and then invoking a
> > javacc process. The new process needs loads the compiler
> > classes, compiles
> > them (?) and then compiles our .java source.
> > If we could have the compiler just loaded on our own
> > memory space, we
> > could invoke it saving the loading compiling (?) time. We
> > could also send
> > the .java 'file' in memory and expect the .class 'file' also
> > in memory.
> > Yes, may be we need some modifications in the compiler,
> > but as part of
> > the apache project we are at a good position for asking it an
> > having a good
> > answer.
> >
> > Chau,
> >
> > Gaston
> >
> > ps: sorry for doing so much guessing but next month I will
> > have much more
> > time.
> > ps
> >
>
> -
> This e-mail is intended only for the addressee(s) named above. It
> may contain confidential or privileged information and if you are
> not the intended addressee you are not authorized to disclose,
> copy, distribute or place any reliance on it whatsoever and we
> request that you inform our postmaster ([EMAIL PROTECTED]) that
> you have received this e-mail. Any attachment(s) to this message
> has been checked for viruses, but please rely on your own virus
> checker and procedures. If you contact us by e-mail, we will
> store your name and address to facilitate communications.
> -
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: Jasper performance
Jon Stevens wrote: > > on 5/17/01 6:46 AM, "Dennis Doubleday" <[EMAIL PROTECTED]> wrote: > > > At 08:35 PM 5/16/01, Jon wrote: > > > >> Also, there is a reason for the #foreach... > >> > >> <http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html> > > > > Jon, > > > > I agree with most of your points. I am a new Velocity user and I am very > > impressed by its combination of power and simplicity. Reading/writing XSLT > > specs is an exercise in masochism. > > > > However, I don't see how Velocity is really avoiding the fundamental > > problem described in the document you referenced. If you are an ISP hosting > > Velocity-based pages, you are certainly going to have to let that 14 year > > old kid install both templates and class files; templates by themselves > > won't accomplish much. So the incompetent or malicious client can easily > > make the same mistake in his Command class that he would have made in the > > JSP page, and therefore also create a DOS attack on all servlets hosted in > > that JVM. No? > > Controlling what goes into the Context is key. > > There is nothing stating that you have to give the 14 year old access to > creating .java files. Instead, the alternative approach is to place certain > objects within the Context which allow the 14 year old to do a limited set > of actions. This follows along with the Pull Model: > > <http://jakarta.apache.org/turbine/pullmodel.html> > > This is the approach that Tea <http://opensource.go.com/> uses as well as > the general idea behind taglibs. The problem with taglibs is that there is > no restriction on the ability to put Java code in the page. It is part of > the JSP specification to be able to do that. Sure, you can disable it (as > Costin said), but then you are breaking the JSP specification. And I know > how important "standards" are to everyone... > But now that both Tomcat 3.2 and Tomcat 4 support the Java SecurityManager you can control security at the container level regardless of whether someone is using the CFM servlet, velocity, CoCoon, JSP, etc. > -jon > > -- > If you come from a Perl or PHP background, JSP is a way to take > your pain to new levels. --Anonymous > <http://jakarta.apache.org/velocity/ymtd/ymtd.html> -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper performance
[EMAIL PROTECTED] wrote: > > On Thu, 17 May 2001, Glenn Nielsen wrote: > > > > This is the approach that Tea <http://opensource.go.com/> uses as well as > > > the general idea behind taglibs. The problem with taglibs is that there is > > > no restriction on the ability to put Java code in the page. It is part of > > > the JSP specification to be able to do that. Sure, you can disable it (as > > > Costin said), but then you are breaking the JSP specification. And I know > > > how important "standards" are to everyone... > > > > > > > But now that both Tomcat 3.2 and Tomcat 4 support the Java SecurityManager > > you can control security at the container level regardless of whether someone > > is using the CFM servlet, velocity, CoCoon, JSP, etc. > > I guess he's refering to DOS attacks ( like a while(true); in java code > or allocating lots of memory ). You won't have much of a templating language if you don't allow some sort of looping. Kind of hard to restrict that. To handle both of the above cases it requires monitoring the performance of the JVM Tomcat is running in, monitoring Tomcat, and individual servlets/jsp's. Then a sysadmin can revoke priviliges for anyone who does something like the above intentionally or from ignorance. It would be nice if self monitoring were built into Tomcat so sysads could track statistics on performance of the JVM, Tomcat in general, and individual servlets/JSP's. Even setting thresholds when automated email notifications could be done. Lets give sysadmins the information they need, then they can take action against problem users. I still think that using the SecurityManager implementation in Tomcat with a well tuned security polciy can provide one of the most secure environments available for running web based applications. This is just my opinion, feel free to try and convince me some other technology is more secure. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper performance
Jon Stevens wrote:
>
> on 5/17/01 12:47 PM, "Glenn Nielsen" <[EMAIL PROTECTED]> wrote:
>
> > But now that both Tomcat 3.2 and Tomcat 4 support the Java SecurityManager
> > you can control security at the container level regardless of whether someone
> > is using the CFM servlet, velocity, CoCoon, JSP, etc.
>
> Not true.
>
> <http://jakarta.apache.org/velocity/ymtd/ymtd-hosting.html>
>
> Hashtable strings = new Hashtable();
> int i=0;
> while (true)
> {
> strings.put ("dead"+i, new StringBuffer(99));
> }
>
> There is no amount of security that will prevent someone from putting that
> into their JSP page other than disabling the ability to put scriptlets into
> things. If you do that, then you are simply where you should have been in
> the first place...using Velocity.
>
Yes, but using velocity templates limits a great deal what customers
can do when compared to a general purpose servlet container where
web applications can be deployed. There is a great deal more to
security than just preventing a 'trusted user' who can publish content
from doing something stupid. No where in your YMTD document do I see
anything about security, just your reference above to a trusted user
DoS. Heck, if one of my customers wants to use Velocity, they can do
so if it can be deployed as a web application, but it will have to
run within the security policies we set for the Tomcat Java SecurityManager. ;-)
Regards,
Glenn
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: JSP and SecurityManager [was RE: 3.2.2. When's it shipping?]
Hmm, I had thought those were getting added automatically, like the read FilePermission for the context root. Sure, you can add those to the default grant policy entry in tomcat.policy. Glenn Marc Saegesser wrote: > > The null check is simple enough and its already been tested in 3.3 so I feel > comfortable making the change without a beta. I'll commit the change today. > > Another question regarding using the security manager and JSP. If I use the > default tomcat.policy file I can't access any JSP pages because I get an > access denied expcetion getting the line.separator property. If I add > > permission java.util.PropertyPermission "line.separator", "read"; > permission java.util.PropertyPermission "file.separator", "read"; > > to tomcat.policy the pages are served correctly. Glenn, is there any > problem adding these two lines to the default policy? Am I missing > something else? > > > -Original Message- > > From: Antony Bowesman [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 18, 2001 1:50 AM > > To: [EMAIL PROTECTED] > > Subject: Re: 3.2.2. When's it shipping? > > > > > > Marc Saegesser wrote: > > > > > > I bloody hope so. > > > > > > Here's the plan. Beta 5 was released on Friday, May 11. This beta > > > cycle is planned for one week. Unless someone reports a show > > > stopping bug, and so far I haven't seen one, on Friday, May 18th. > > > I'll call release vote on tomcat-dev. This vote lasts for one week > > > and every committer gets to vote. A public release vote is open for > > > one week. So, the best case right now is May 28th. > > > > Not sure if this would be a showstopper however, there is a bug in > > jasper/runtime/JspFactoryImpl.java which causes a NullPointerException. > > Fixed in 3.3 but not in 3.2.2 > > > > I'm relatively new to tomcat so am not sure of the bug reporting process > > but I sent report of a bug to this list a couple of days ago. > > > > Just tested it with b5 - bug still exists. > > > > tomcat run -security > > > > gives nullPointerException in jasper/runtime/JspFactoryImpl.java > > > > due to no check for pageContext == null in releasePageContext > > > > This is fixed in 3.3 > > > > if (pc == null) return > > > > Rgds > > Antony > > > > > > > > > -Original Message- > > > > From: Dave Oxley [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, May 17, 2001 12:54 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: 3.2.2. When's it shipping? > > > > > > > > > > > > What is the current state of 3.2.2 development? Is it going to > > > > ship any time > > > > soon? > > > > > > > > Dave. > > > > [EMAIL PROTECTED] > > > > -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [VOTE] Final release of Tomcat 3.2.2
Marc Saegesser wrote: > > The latest beta cycle for Tomcat 3.2.2 has completed with no new bugs > identified. As the release manager I propose that we release the tomcat_32 > branch as Tomcat 3.2.2. Please indicate your vote for the release using the > ballot below. > > I will tabulate and post the results of this vote on Friday, May 25. At > that time, if the vote has passed, I will tag, build and distribute the > release. The vote must pass by majority approval which means the proposal > must receive at least three +1 votes and more +1 votes than -1 votes. > > Marc Saegesser > > - > > Vote to release the tomcat_32 branch as Tomcat 3.2.2. > > [ ] +1. I agree with the proposal and I will help support > the release. > [x] +0. I agree with the proposal but I will not be able > to help support the release. > [ ] -0. I don't agree with the proposal but I won't stop > the release. > [ ] -1. I disagree with the proposal and will explain my > reasons. Great job Marc, Thanks! -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
+1 I was working on doing the same for jakarta-taglibs
"Craig R. McClanahan" wrote:
>
> I'd like to propose a modification to the way that the build scripts for
> Tomcat 4 work, based on experience gained in the Jakarta Commons project,
> Struts, and a couple of non-Jakarta projects that use the same approach.
>
> Basically, the changes go like this:
>
> * Ant must be installed as an application, and $ANT_HOME/bin must be
> on your PATH environment variable so that the "ant" command can be
> used directly from the shell command prompt.
>
> * Dispense with "build.bat" and "build.sh" scripts, because we will be
> executing Ant directly.
>
> * Dispense with environment variables to point at all of the dependencies.
> This will be replaced by references in "build.properties" files as
> discussed further below.
>
> * The top-level build.xml script for Tomcat will include the lines:
>
>
> so that values specific to your environment can be set locally (i.e.
> in the top level "jakarta-tomcat-4.0" directory, or globally (in
> your user home directory).
>
> * Because of the way that Ant works, these conventions create an ordered
> hierarchy for property assignment (first definition wins):
> - User's properties that are specific to this project
> - User's global properties file (in the user.home directory)
> - Default properties declared in build.xml (after the lines above).
>
> * Subordinate build.xml scripts (in catalina, jasper, etc.) will include:
>
>
>
> so that you can use "ant" directly in those directories as well, and
> still pick up all of your local dependencies.
>
> * Because the "build.properties" files are local to your development
> system, they are *not* checked in to CVS (in fact, they will get
> added to the ".cvsignore" list). However, an example properties file
> "build.properties.sample" will be checked in that documents the
> variables that must, or can, be set.
>
> * Besides being easier (than environment variables) to manipulate, using
> properties files in this way has several advantages:
> - Using "${user.home}/build.properties" lets you share property
> assignments across all projects using the same conventions.
> - Using "build.properties" lets you override global property settings
> for a different project (say, for example, that you want to use a
> different XML parser for building Tomcat than for building other
> projects).
> - You can do variable substitutions in your "build.properties" settings
> just like you can when setting properties explicitly - Ant resolves
> them when the properties files are loaded.
>
> * Now, to execute a build, you simply type
> ant dist
> instead of "./build.sh dist" or "build dist" depending on platform.
>
> If this proposal is accepted, I'll go ahead and do the necessary grunt
> work this week.
>
> Comments? Questions?
>
> Craig
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Tomcat4 Default Error Handling
Is there a way change the default way Tomcat 4 handles reporting of errors to a remote user that can be configured globally? I would like to set the default behaviour to something less intimidating than a stack trace inc ase a customer hasn't configured error handling in their JSP pages or web application web.xml. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: New Tomcat web site
Great job Marc! Marc Saegesser wrote: > > The jakarta-tomcat-site repository has been created and populated. The > Jakarta web site has been updated to point to the new stuff. The README.txt > file in the root directory has basic instructions. > > I claim no great ability at site design or word-smithing so consider this a > merely a jumping off point. If you see something you don't like please > change it. All Tomcat committers have access to this repository. > > Enjoy. > > Marc Saegesser -- ---------- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat4 Default Error Handling
Sounds like something to add to the Tomcat 4 todo list. I see this as something that could be configurable at the , , , or . With the ability to specify a Handler or static page for both HTTP status codes and Exceptions. These could be overridden by a web applications web.xml. Regards, Glenn "Craig R. McClanahan" wrote: > > On Tue, 22 May 2001, Glenn Nielsen wrote: > > > Is there a way change the default way Tomcat 4 handles reporting of > > errors to a remote user that can be configured globally? I would > > like to set the default behaviour to something less intimidating than > > a stack trace inc ase a customer hasn't configured error handling in > > their JSP pages or web application web.xml. > > > > There isn't anything global at the moment. Part of the challenge is that > most of the things you might *like* to do are pretty application specific. > > One approach we can consider is to pull out the logic that generates the > default error pages (it's in StandardWrapperValve) into separate > system-level servlets - or something similar - that you can > configure. Then we could add a Context-level configuration property that > let you select the correct handler. > > > Regards, > > > > Glenn > > > > Craig -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper performance/3.3 tag pooling
Rickard Öberg wrote: > > [EMAIL PROTECTED] wrote: > > > > We know the pool is synchronized and that may create problems under heavy > > > > load, and we know how to fix this ( by using a per/thread pool without > > > > synchronization ). > > > > > > That is one solution, but what do you do with the pool after page > > > request? > > > > I'm not sure I understand. Each thread has a number of associated objects > > that are recycled and reused - a Request object will "stick" with a > > thread. > > > > Same can be done for the tag pools - except that this may use a lot of > > memory ( but less than allocating/freeing ). It is possible to use a > > middle ground, or tune this - but for maximum performance you can have a > > local pool in each Request. > > What I was considering is this: a pool is a managed resource, since it > can shrink and grow. After a page request, you will want to reuse the > pool and its contents, but you can't stick the contents into a global > pool, because at next request how are you to know how many instances of > a tag to put in the request-associated pool. I.e., thread-associated > pools perform local optimizations per request/page, but for pools to be > of any use they need to do global optimizations, i.e. pool the tags in a > global pool. Otherwise you'll have lots of pools of tags and no way to > manage them globally. > > Example: > Page request. No pools created yet. > Page uses tag "foo" 10 times. Pool, associated with request/thread, > created containing one "foo" tag instance. > Concurrent page request with the above. > Page uses tag "foo" 5 times. Another pool, associated with > request/thread, created containing one "foo" tag instance. > Both requests end: what to do with the pools? > 1 Keep separate, each containing one instance > 2 Merge so that there is only one pool for "foo" tags > If 1, then there's no way to do proper global optimizations, i.e. say > "don't create more than x tag instances". > If 2, then at next request, what should the page associated "foo" pool > contain? 1 tag instance, 2 tag instances..? The only way to really know > is for the page to do its thing, and pull the tags from the global pool. > And then you're in "synch" land again. > > Do you understand now? I realize the above is a bit fuzzy... > > > > I hope that Costin will be able to reproduce what I found. > > > > I hope not :-) > > > > Again - thanks for doing the tests and checking the code, and hope to see > > more contributions and maybe few patches :-) > > Jasper performance is a high priority thing for us (nr 1. on our "system > performance fixing" list actually), so if possible, absolutely. I can't > say I've delved that far into Jasper yet though. It was a bit hard to > read. > > > IMHO the right answer is "depends". And it depends on the actual use case, > > on how many objects are created and where the synchronization occurs. For > > tomcat, where we expect hundred of concurent requests and each would > > create almost a hundred object ( that was the case in 3.0 ) - I doubt any > > VM could make a difference. > > Have you then considered the middle way I proposed, where each page > creates the tags it needs, but only once. In my experience, the > performance kills is in iterative and recursive use of tags, e.g.: > > > > which will create one "foo" tag per iteration in 3.2. *That's* the > biggest problem IMHO. Creating the "iterate" and "foo" tag once for that > page is not, considering that the overhead of managing pools of these > tag instances is more resource draining, and hard to do properly on a > global scale. > I just had an idea (dangerous things) regarding tag pooling optimizations. When Jasper translates a page it should be able to generate information about which tag handler classes it needs, and for each tag handler, the profile of the attribute/value pairs. At runtime Jasper could make one call to a tag pooling synchronized method to get all available instances of the tag handlers it needs. Any tag handlers/attribute profiles it couldn't obtain, it would have to create. Then it would manage its own local tag pool during the execution of the request. On termination of the request, after the page has been committed to the remote client, it would make one call to a tag pooling synchronized method to recycle/add the tag handlers it used. So there would only be 2 synchronized methods per page for implementing tag pooling regardless of how many tags are used. And you have the benifits of minimizing JVM memory usage by sharing a global JVM tag pool. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper34: Manglers
[EMAIL PROTECTED] wrote: > > Another issue: > > At this moment we have 4 different manglers ( == converters between > jsp files and valid class names ): > - original ( uses a nice .class file hack to do versioning ) > - jspc ( similar with original, but without versioning - AFAIK) > - jasper33 ( versioning, simpler names without %, use a separate .ver > file to avoid messing with class files ) > - jasper40 ( no versioning, uses a separate class loader per page ) > > If nobody objects, I would like to reduce this to 2 ( 33 and 40 ). I would > go with only 1, but each has nice advantages ( 40 has a predictible name, > 33 avoids messing with class loaders ). > > If you have any reason to keep the old ones - let me know. We can add them > later if needed ( I like the class hack, but it would take time to keep it > updated ). > > Costin I am +1 for removing the original class hack version, in its current implementation it added alot of overhead both at compile and runtime. Another advantage of jasper40 using a URLClassLoader for each individual JSP page is that you don't accumulate outdated classes in the classloader that eat up JVM memory when a JSP is recompiled. I haven't looked at jasper33, so please let me know if that is not a problem with it. Regards, Glenn ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [j-t-c] OS poll
Solaris 7 & 8 both Sparc and x86, and FreeBSD. GOMEZ Henri wrote: > > Hi, > > A quick poll to get informations about OS used by > j-t-c developpers & users ... > > I: Redhat 6.2 / 7.1 > > - > Henri Gomez ___[_] > EMAIL : [EMAIL PROTECTED](. .) > PGP KEY : 697ECEDD...oOOo..(_)..oOOo... > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: [j-t-c] OS poll => [j-t-c] webserver poll
Apache 1.3/mod_ssl GOMEZ Henri wrote: > > Now which webservers are you using : > > - Apache 1.3(Apache, Apache/SSL or Apache-mod_ssl) > - Apache 2.0 > - Domino > - IIS 4/5/2000 > - JNI > - Netscape/IPlanet > ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat 4.0/Solaris why doesn't tomcat follow soft links?
Under unix the Java SecurityManager doesn't like soft links. The reason is that the SecurityManager uses the real path when evaluating the codebase. Using Tomcat 4 you can configure the Context docBase to the realpath to the users public html directory. Regards, Glenn Robert Evans wrote: > > Greetings, > > I am in the process of configuring Tomcat to be used with several classes > at the Johns Hopkins University. I would like to have each student have > their own webapp in their public_html directory. > > I tried Tomcat 3.2.1, but couldn't get the security policy to work right > (all jsp pages kept wanting to use the examples directory?) > > I am trying Tomcat 4.0B5, and was going to use soft links in the webapps > directory to point to each students public_html directory. The only > problem is that Tomcat doesn't seem to want to follow the soft links. If I > make a real directory in the webapps dir, everything works fine, but if I > try to use a soft linked one, I get: > > Http Status 503 - This application is not currently available > > The requested service(This application is not currently available) is > not currently available > > Any suggestions/help would be greatly appreciated. If I don't get this > working within a week, it'll be back to the Java Web Server. :-( > > Bob -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Plans for Tomcat 3.2.3 and later
+1 I will help with any SecurityManager issues Marc Saegesser wrote: > > Now that Tomcat 3.2.2 is out it's time to starting thinking about 3.2.3. My > thoughts are to have a release for 3.2.3 in three or four months. This will > be strictly a bug fix release. The only hard and fast release requirements > are to fix any specification compliance issues that may be discovered in > 3.2.2 and that are no regression failures. Beyond that, any bugs are fair > game and 3.2.3 will roll these up into a public release. I'll volunteer to > be the release manager for this release (unless someone else is crazy enough > to want the job). Any discussion? Comments? I'll put together a formal > release plan in the next couple days. > > Marc Saegesser -- ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat Admin Web Interface
"Craig R. McClanahan" wrote: > > On Thu, 14 Jun 2001, M B wrote: > > > Hello All, > > > > In response to the recent postings regarding Tomcat > > documentation and administration (Re: ~rant~ Docs, > > user list, etc.), I am willing to contribute much > > effort in this area. In addition to documentation, I > > am particularly interested in helping to build an > > administrative web interface for Tomcat 4.0, something > > similar to JRun Management Console, for example. > > > > That would be awesome! > > > Naturally, I want to coordinate my efforts with the > > Tomcat community. Can anyone please point out where I > > should begin, or who I should contact? Is there a > > project for this? The Catalina TODO identifies John > > Shin as volunteer for producing an admin interface, > > but I thought I should email this list before > > contacting him directly. > > > > He volunteered long, long, ago but I haven't heard anything from him > lately. > > As it happens, I've been accumulating a list of functional requirements > for admin capabilities that I'd like to post for discussion. I'll be > finished with what I'm thinking in the next couple of days. > > What I'd like to see us do on issues like this is to discuss and agree on > a functional specs document that is checked in to the CVS repository, and > then start working together on the pieces. It's a little more formal than > the usual :-) open source approach, but I think it will help in the long > run. Does that sound like a useful plan? > Sounds good. Have you considered using SOAP to implement Tomcat admin transactions? Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper34: static output changes
+1
[EMAIL PROTECTED] wrote:
>
> Ok, time to discuss the first mini-optimization.
>
> Right now jasper has 2 ways to output data - one is the common
> out.println("String ");
>
> The other ( not very used ) is using an additional file to store the
> strings, and it's enabled by "largefile" option.
>
> The output system is probably the most important part of jasper ( except
> taglibs ) with regard to performance.
>
> My proposal is to drop the first option, which is also failing for chunks
> bigger than 64k ( due to .class file limitations on constant pool
> strings), and use the second ( with some changes ) in all cases.
>
> The main problem is that the java file will be less readable (
> out.println( strings[4] ) instead of the real string ). That can be
> resolved easily by generating a comment with the real string ( most users
> will not read the java file - now that we are close to line number
> mapping it'll happen even less ).
>
> Note that this is nothing new for jasper - the option has been present in
> jasper and is tested.
>
> The main benefits:
>
> - full control over static content allocation. If the strings are part of
> the constant pool, they are loaded with the class and garbage collected
> only if the class itself is gc. By loading them from the file we could
> easily add a LRU cache for the static chunks and reduce the runtime memory
> usage quite significantly.
>
> - ability for containers to control the static content. For a large file
> the connector could send only the file and offsets to apache, instead of
> reading and sending the large chunk.
>
> - it will work with large files without requiring users to set options
> ( that could be resolved by detecting large chunks and turning it on
> automatically )
>
> - a single output model - easier to test and optimize than 2.
>
> Let me know if you see any problem with that - it'll probably happen next
> week, I'm still stuck with the JspServlet.
>
> Costin
>
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources FileDirContext.java
Remy Maucherat wrote:
>
> Quoting [EMAIL PROTECTED]:
>
> > glenn 01/06/22 13:20:54
> >
> > Modified:catalina/src/share/org/apache/naming/resources
> > FileDirContext.java
> > Log:
> > Fix path for windows file separator
> > @@ -843,6 +842,8 @@
> > * @param name Normalized context-relative path (with leading
> > '/')
> > */
> >protected File file(String name) {
> > + if( File.separatorChar == '\\' )
> > +name = name.replace('/',File.separatorChar);
> >
> >File file = new File(base, name);
> >if (file.exists() && file.canRead()) {
>
> Is this really needed ?
> I think this should be abstracted by the new File call.
>
Yes, it was needed. There were a few cases under windows when the
file separator was incorrect, causing FileDirContext to fail.
As long as we make sure the file separator is correct, you can
abstract it out any way you think works best.
Regards,
Glenn
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
Re: Classpath Ordering: Questions, and possible contrib.
[EMAIL PROTECTED] wrote: > > On Sat, 23 Jun 2001, Craig R. McClanahan wrote: > > > > > A) the hierarchy should go: > > > > > > > >SystemCL > > > > | <-- LAYER 1 > > > > lib/common CL > > > >/ \ <-- LAYER 2 > > > > lib/container lib/apps CL > > > >|<-- LAYER 3 > > > > WEB-INF/lib << same CL, but with URLs > > > > WEB-INF/classes from both dirs, in this > > > > order... > > > > > > You are absolutely right, that's the intended hierarchy. > > > > One thing you might want to note for the future is that, in servlet 2.3, > > the order of loading in the web-app classloader is specified to be > > reversed from this (i.e. WEB-INF/classes first, then WEB-INF/lib). The > > new spec also permits a web-app classloader to override classes in parent > > classloaders by using a "look then delegate" policy, rather than "delegate > > than look" in the usual Java2 fashion. (Tomcat 4's classloaders do both > > of these things, against a very similar overall hierarchy.) > > > Neither of these behaviors is specified for 2.2, so you're pretty much > > free to do what you want. But you should think about implementing similar > > policies now, to improve the portability of apps to containers supporting > > 2.3. > > That's why we have pluggable loader - if someone wants such a behavior > he's free to implement a loader. For servlet 2.2 we are not required, and > I'm not going to. And it shouldn't matter anyway - since the common loader > is supposed to have minimal stuff ( javax, other things that should not be > overriden without major risks for security - even if the 2.3 spec would > require them to be - I'm talking about some common utils ). > > I believe there are important security issues, but I'm sure the spec took > this into consideration - so probably I'm wrong ( of course, this will be > easy to verify later on, there are quite a few ways someone could try to > exploit a reversed order - but again I'm sure this was taken care of and > it'll be just the fun of trying :-). > Yes there are security issues related to the Servlet 2.3 spec webapp CL. Fortunately, the Java SecurityManager can protect you if you use checkPackageDefinition() in the CL. This can prevent a Servlet 2.3 webapp CL from redefining system or other sensitive classes. > Costin -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Classpath Ordering: Questions, and possible contrib.
[EMAIL PROTECTED] wrote: > > On Sat, 23 Jun 2001, Glenn Nielsen wrote: > > > > I believe there are important security issues, but I'm sure the spec took > > > this into consideration - so probably I'm wrong ( of course, this will be > > > easy to verify later on, there are quite a few ways someone could try to > > > exploit a reversed order - but again I'm sure this was taken care of and > > > it'll be just the fun of trying :-). > > > > > > > Yes there are security issues related to the Servlet 2.3 spec webapp CL. > > Fortunately, the Java SecurityManager can protect you if you use > > checkPackageDefinition() in the CL. This can prevent a Servlet 2.3 webapp > > CL from redefining system or other sensitive classes. > > That's only part of the problem and only part of the solution :-) I'm not > going to argue to much about this - the archives of tomcat-dev are > available, no need to repeat :-) > Are you refering to class loading security, or class loading in general? > It all depends on how you define 'sensitive classes' - what is not > sensitive and how you decide so ? It's turning the problem around, from > "don't trust anything" to "don't trust specific things" - and that's > considered dangerous by some other people. > Thats the beauty of the Java SecurityManager. As Craig mentioned, certain packages are automatically restricted from being defined or accessed by a webapp in Tomcat 4. But if the system administrator for Tomcat 4 decides they want to restrict definition or access to other packages, all they need to do is edit their $JAVA_HOME/jre/lib/java.security properties file. Then grant those permissions as needed in the policy file to any trusted webapps that may need them. By default, webapps would not have privileges to define and/or access those packages unless you explicitely granted them. Requiring use of the Java SecurityManager with Tomcat 4 has been discussed. I don't recall if a decision was reached on that. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Project blocking problem
The version of jasper used in Tomcat 4 already solves this problem by breaking out the jsp generated java source and class files by directory. Regards, Glenn [EMAIL PROTECTED] wrote: > > Hi All, > > I've just come to a problem using tomcat that is completely blocking my > development. I have a JSP in this directory: > \jsp\VarDep2\BR-brand-card\BR-smartcard-CardB\cardBenefits.jsp > > My HTML developers are using Windows machines. When I generate the .class > file from compiling the JSP I get this: > > D:\jasondev\Jakarta\tomcat322\ >work\localhost_8080%2Fbap\jsp\VarDep_00032\BR_0002dbrand_0002dcard\ > >BR_0002dsmartcard_0002dCardB\_0002fjsp_0002fVarDep_00032_0002fBR_0002dbrand_0002dcard_0002fBR_0002dsmartcard_0002dCardB_0002fcardBenefits_0002ejspcardBenefits_jsp_0.class > > Which appears to be breaking the 256 character file name limit under windows. The >directory structure is very important in my design, and > cannot be changed without destroying the value of my software. Plus, since we're >going to production in Solaris, it's only an issue for the > Windows people. I need this fixed in order to support them, so I'm going to try and >open up Tomcat to fix it my self. > > I'm hoping that some of you can provide a list of places that I'll need to change >things. I understand that this is no small undertaking, > but putting the whole directory structure into the name can't be that great a thing >to do anyway. (Anybody know why it's being done this > way?) > > I really need all the help I can get. Any suggestions (Even suggestions of a good >shrink) are appreciated. > > Jason > > ps: Sorry about this warning message, I cannot prevent it from being appended: > > -- > Warning : The information contained in this message may be privileged and >confidential and protected from disclosure. If the reader of this message is not the >intended recipient, you are hereby notified that any dissemination, distribution or >copying of this communication is strictly prohibited. If you have received this >communication in error, please notify us immediately by replying to this message and >then delete it from your computer. All e-mail sent to this address will be received >by the Providian Financial corporate e-mail system and is subject to archiving and >review by someone other than the recipient. > > == -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Tomcat Documentation Project
[EMAIL PROTECTED] wrote: > > Leaving aside the issue of file format for just one second... > > Are we agreed on the following? > > 1. Tomcat documentation sucks :-) > Thats a strong word, some parts are very good, some could use work. > 2. There needs to be a new CVS project called jakarta-tomcat-doc. > > My reasoning is that we want to avoid the fragmentation of documentation > into different trees for 3.2, 3.3, and 4.0. Why? Because a lot of > documentation would apply equally to all versions. > > Looking at it in reverse, the fact that someone is using an old version > of Tomcat shouldn't mean they're forced to use an old version of the > documentation. Instead, a chapter on, say, web application deployment > may need to have a sidebar describing changes between 3.x and 4.x, but > assuming 4.x isn't *radically* different, they can both use the same > core text. (In cases where 4.x *is* radically different, it would just > have a separate document/chapter, with the 4.x specificity clearly > labelled in the title.) > > I know the 4.x crew have begun the process of creating a separate > documentation set, including xdocs, and this is great. If it's too much > work to integrate 3.x and 4.x then maybe they should remain separate CVS > projects too, but it may still be desirable to have a separate CVS > project anyway. > My big concern about your proposal is that the documentation would get disjointed. With too many if this version or that version qualifiers in the docs. I really think the docs should be built for each specific container, providing documentation only for that container. This would be better for the user since they are only using one of the three versions of Tomcat. I could see a need for jakarta-tomcat-doc for anything that is generic and not Tomcat version or connector specific. Then let the document builds for the individual Tomcat versions pull in anything they can use from the generic docs or the individual connector docs in jakarta-connectors. In summary: jakarta-tomcat-doc only provides generic documentation, like JSP 1.1 web app, etc. jakarta-connectors does separate documentation for each connector/protocol. jakarta-tomcat/jakarta-tomcat-4.0 does their own version specific docs and merges in any useful docs from jakarta-tomcat-doc and/or jakarta-connectors. > 3. There needs to be a better index/TOC for the documentation we do > have, and a reorganization of the redundant / outdated / wrong parts of > the existing docs (the Apache config stuff comes to mind). > It is always a good thing to keep docs up to date. > 4. Someone or some small group of people should take responsibility for > making this happen (before we "run out of steam"), regularly submitting > proposals and keeping the rest of the group apprised of developments and > decisions, but retaining some authority. Let's call this person/people > the Documentation Czar. I'm not proposing he/they have any real > authority over the content, but just over organizing it, deciding where > to place it, and forming "to do" lists for documents/chapters that need > to be written or proofed or tech edited or revised. > It would be great if someone were willing to volunteer. > If we agree on the above, then there's a good chance I'd volunteer to be > the Doc Czar, even though I think it's a lot of work. I've been managing > the jGuru Tomcat FAQ for a year, and the Servlets FAQ for longer, so I > at least have some idea of the scope of this kind of organizational > task. (Note that I'm not suggesting I actually *write* all this new > documentation... :-) > > Maybe a better term would be "Doc Editor" or "Editorial Board". And > maybe I'm being too anal in proposing it; maybe the open source process > will ensure the job gets done by interested developers even without the > title. > > - Alex > > -- > Alex Chaffee mailto:[EMAIL PROTECTED] > jGuru - Java News and FAQs http://www.jguru.com/alex/ > Creator of Gamelan http://www.gamelan.com/ > Founder of Purple Technology http://www.purpletech.com/ > Curator of Stinky Art Collective http://www.stinky.com/ -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: First day - RE: PROPOSAL: Tomcat docs
Antony Bowesman wrote: > > Punky Tse wrote: > > > > Rob, > > Please see below for rephrased version of Introduction and > > Administrator Guide. > > > > I combined the Introduction and Administrator's Guide to Administrator > > Guide. Actually this is my proposed TOC. And I believe that we need > > separate document for different Tomcat servers. e.g. 3.3 and 4.0. > > > > > > > II. Server Administration > > > > 6. Configuring Server > > > > 7. Configuring Web Applications > > > > 8. Security > > How about > 8.1 Concepts - Explanation of J2EE and Java 2 security models > 8.2 Authentication with Realms > 8.2.1 Simple realm > 8.2.2 JDBC Realm > 8.2.3 Custom realms > 8.3 Authorization > 8.3.1 J2EE role based > > In particular, it should try to explain in simpler terms than the API > spec how J2EE roles are designed to work, covering the mapping from > developer roles to deployment roles. > > 8.3.2 Java 2 security policy > I would break the above into two sections. Access Control (for all the Realm based access control) and Server Security (for configuring and using Tomcat with the Java SecurityManager) These really are two completely different topics. And use of Realms isn't "Security", it is "Access Control". Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: First day - RE: PROPOSAL: Tomcat docs
Antony Bowesman wrote: > > Glenn Nielsen wrote: > > > > Antony Bowesman wrote: > > > > > > > 8. Security > > > > > > How about > > > 8.1 Concepts - Explanation of J2EE and Java 2 security models > > > 8.2 Authentication with Realms > > > 8.2.1 Simple realm > > > 8.2.2 JDBC Realm > > > 8.2.3 Custom realms > > > 8.3 Authorization > > > 8.3.1 J2EE role based > > > > > > In particular, it should try to explain in simpler terms than the API > > > spec how J2EE roles are designed to work, covering the mapping from > > > developer roles to deployment roles. > > > > > > 8.3.2 Java 2 security policy > > > > > > > I would break the above into two sections. > > > > Access Control (for all the Realm based access control) > > > > and > > > > Server Security (for configuring and using Tomcat with the Java > > SecurityManager) > > > > These really are two completely different topics. And use of > > Realms isn't "Security", it is "Access Control". > > Not sure I'd agree with your removal of Java Security Manager from a > chapter about access control. The first line of the JavaTM 2 Platform > Security Introduced: document at > > http://java.sun.com/j2se/1.3/docs/guide/security/index.html > > says > > * Policy-based, easily-configurable, fine-grained access control > > Access control is one element of securing a server, as is > authentication, encryption, non repudiation, SSL etc. > > Access control is performed by Java 2 security manager as well as J2EE > and they compliment each other. JAAS (JDK1.3 extension) which extends > the Java 2 model and which is now included in JDK1.4 extends the Java 2 > security model to provide principal based access control on top of code > source. So access control is firmly part of Java security. > > There should be additional sections on 'server security' that includes > configuring the server for use with SSL. > I have seen the general term 'security' used instead of a more descriptive term like SSL Encryption, SecurityManager, or Access Control. My point is that these are very different things, and the documentation should be constructed so that users use those terms rather than the general term "Security". Security Overview - types of security J2EE Security Model User Access Control (Realms & roles) Java SecurityManager SSL Data Encryption Yes, JAAS can be used to control access for executing code based on what role the user is in. At this point there is no support in Tomcat for JAAS. There are two ways I see JAAS being used within Tomcat sometime in the future. 1. Policy based JAAS access control to Tomcat's manager or admin servlet. 2. Some Policy configuration tool for webapps that supports normal Java SecurityManager configuration and JAAS policy based access control. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: webapp classloader ProtectionDomain (running secured tomcat)
This is true form tomcat 3.x, but not for Tomcat 4. Tomcat 4 allows setting of different policies for different locations within a webapp. Regards, Glenn Vladimir Grishchenko wrote: > > Hi there, > I've posted the message below to tomcat-user but it didn't get much > attention. Is any work being done to address this? > > Thanks, > --V. > > > Hi all, > > It seems that webapp classloader puts all classes loaded from > a webapp directory into the same ProtectionDomain regardless > of the location where the class was loaded from (like classes > dir or a jar file). It means that any security grant entry granting > permssions to a webapp codesource effectively grants the same set > of permissions to each and every class in web application. This > is probably fine in most cases but leaves no possibility to fine > tune security within web-application. My particular problem is > that I'm trying to use JAAS to enable access control with custom > JAAS policy implementation. CodeSOurce partitioning that Sun > suggests requires that the code sensitive to user-based > operations shoud be put into separate ProtectionDomain for JAAS > mechanisms to work. The only way to do this with Tomcat is to put > classes someplace out of webapp directory, so they don't inherit > any permissions assigned to webapp ProtectionDomain. I think that > webapp class loader should put classes loaded from class directory > and every jar file into diffrent protection domains, like class > loaders that load classes from the system classpath in Java. > > Well, if all that makes any sense to you may be there's something > I'm missing here? > Just wanted to get other people's opinions... > > --Vlad. > > *** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact > the sender by reply e-mail and destroy all copies of the original > message. > *** -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: InstanceListener syntax?
Remy Maucherat wrote: > > > Hi folks, > > > > can someone give me the definitive syntax for the InstanceListener? > > Also, is it possible to setup an Engine (or Host) level InstanceListener > > that would get applied to all context's within said Engine or Host? > > > > Having to add a InstanceListener to every context just to get the old > > tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a > > bit onerous. > > Glenn, would the default context help here ? > > Remy Its in the code for DefaultContext, but I don't know if it has been tested. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: Jasper and parsed tree
To me this seems a bit off topic for the list. This list is for Tomcat development. Tomcat implements the Servlet and JSP specifications. The below has nothing to do with Tomcat development IMHO. Regards, Glenn Brad Cox wrote: > > At 11:40 AM +0800 7/13/01, John Yu wrote: > > >Well, assuming that the JavaCC grammar is capable of dealing with all > >>the intricacies of JSP syntax (and the license issues dealt with), it's > >>certainly possible. But I'd be really hesitant to say "let's go replace > >>the parser" without discussing and agreeing on an overall architecture > > >first. > > I've just uploaded a demonstration of the feasibility of binding web > applications to html, template files, properties files, and databases > at pre-compile time instead of run-time as most template languages do > now. The advantages are considerable; negligible run-time overhead > (28kb), compile-time type checking, and so forth. > > The template language syntax is primitive currently. I'm thinking > about modifying the Velocity parser to emit java statements for > compilation at compile time instead of interpreting the AST at > runtime. Comments on the desirability of this approach are welcome, > particularly offers to help! ;) > > The feasibility demo is at http://virtualschool.edu/jwaa. > > Tomcat/Velocity developers; I'd be most interested in your responses > to my complaints about the emphasis on properties/XML files in Tomcat > and Velocity... near the end of the template language document > (there's a link to this document at the very top). > -- > --- > For industrial age goods there were checks and credit cards. > For everything else there is mybank.dom at http://virtualschool.edu/mybank > Brad Cox, PhD; [EMAIL PROTECTED] 703 361 4751 -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
Re: BugRat Report #690 has been filed.
This isn't a Tomcat bug, its the way security works (whether correct or not).
Perhaps this should be sent in as a Java bug report to Sun.
This is documented in tomcat-security.html, you have to comment out
the line:
package.access=sun.
in your $JAVA_HOME/jre/lib/security/java.security file.
BugRat Mail System wrote:
>
> Bug report #690 has just been filed.
>
> You can view the report at the following URL:
>
><http://znutar.cortexity.com/BugRatViewer/ShowReport/690>
>
> REPORT #690 Details.
>
> Project: Tomcat
> Category: Bug Report
> SubCategory: New Bug Report
> Class: swbug
> State: received
> Priority: high
> Severity: serious
> Confidence: public
> Environment:
>Release: Tomcat 3.2.1
>JVM Release: 1.2.2
>Operating System: Windows 2000 Pro
>OS Release: ?
>Platform: Intel
>
> Synopsis:
> jsp compliation error
>
> Description:
> The default javasoft/JRE/1.2/lib/security/java.security file restricts use of the
>sun. packages.
>
> Both Tomcat and EmbededTomcat fail with the following error:
>
> Unable to compile class for JSP
> java.security.AccessControlException: access denied (java.lang.RuntimePermission
>accessClassInPackage.sun.tools.java
>
> Adding the following to the default tomcat.policy file does not correct the error:
>
> grant {
> permission java.lang.RuntimePermission "accessClassInPackage.sun.tools.java";
> };
>
>
>--
> Name: Report-690.html
>Report-690.html Type: Hypertext Markup Language (text/html)
> Encoding: 7bit
> Description: DataSource attachment 'Report-690.html'
>
>Part 1.3Type: Plain Text (text/plain)
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
"Craig R. McClanahan" wrote: > > Now that we've all recovered from New Years (and watched Oregon State teach > Notre Dame a few things about football -- go Beavers! :-), it's time to lay out > the next steps in Tomcat 4.0's lifetime. Here's what I propose: > > (1) Tomcat 4.0 Beta 1 > > The code for Tomcat 4.0 has proven to be quite solid and reasonably bug free > (except for the new web connector -- see below), so it's time to start doing > beta cycles to increase the exposure and testing it receives. I would like us > to move quickly towards a "release quality" build, and therefore propose to > create Tomcat 4.0 Beta 1 on Friday 5, 2001 -- after having a chance to integrate > a few more bug fixes for issues that were reported in the last couple of weeks. > > The web connector code is much less tested than the standalonie connector, so I > propose that we highlight the fact that this portion of Tomcat 4.0 is still > alpha quality. The build process has been organized so that we can create two > files (mod_webapp.so and warp.jar) and publish updates separately, if needed, > without doing a complete release. This will help us isolate and fix such > problems more quickly. > +1 for separate mod_wepp/warp releases. > The existing "jakarta-tomcat-4.0" repository will be branched with label > "tomcat_40_branch", and each 4.0.x beta and release will receive a label such as > "tomcat_40_b1". The "main" branch of this repository will be active for bug > fixes on 4.0, while major new development will shift to the 4.1 repository > described below. -0 I'm not sure what the above branches buy us, will all bug fixes and commits still go to the main 4.0 branch? With the other beta branches just being a snapshot of the code when the beta was released? > > (2) Tomcat 4.1 Repository > > As we approach a release quality build for Tomcat 4.0, it is also time to split > the development of major new functionality (such as the distributed session > management currently under discussion) into a development process that does not > destabilize the 4.0 release code. We can do this with a branch or a new > repository. After thinking about the relative merits of this for a bit, and > consulting with others who have managed similar evoluations, I think a new > repository is the way to go. > > Therefore, I propose to create a new "jakarta-tomcat-4.1" repository on Friday > as well, based originally on the code that is marked for Tomcat 4.0 beta 1. > Because this code is just another portion of the overall code base for Tomcat, > all existing Tomcat committers will have write access to it (just as they do > with "jakarta-tomcat" and "jakarta-tomcat-4.0" today) -- no extra committer > votes are required. > > NOTE: Pending this change, I would ask that we *not* commit changes to the 4.0 > repository for new features that will appear in 4.1, until *after* the split. > > At the same time, I will modify the build processes that create nightly > distributions of Tomcat to create a build of the most recent 4.0 tree and the > most recent 4.1 tree, so that people interested in either version can follow > along as they prefer. > -1 I would rather see a feature freeze for 4.0, and continue to focus efforts on completing, testing, and bug fixing 4.0. (I want to have the Java SecurityManager as a 4.0 feature) Once 4.0 is released then fork the code. This way we will stay focused on the 4.0 release. Could an updated list of features and their status be posted? > (3) New "jakarta-servletapi-4.0" CVS Repository > > Consistent with the suggested approach for separate Tomcat repositories for each > major version, I suggest that we also split the repository for the servlet 2.3 / > JSP 1.2 API classes. Currently, this code is in a branch (SERVET_23_JSP_12) of > the "jakarta-servletapi" repository, which makes life tougher on build scripts > than is necessary. > > Therefore, I propose that we also create a new repository for these API classes > (the "4.0" part of the number matching the Tomcat major version number), with > these classes pulled out of the "jakarta-servletapi" repository -- which will > remain the current code base for servlet 2.2 / JSP 1.1. > -1 I would rather not see the servletapi tied to a Tomcat version, it is something that should stand alone. jakarta-servletapi-23, and the old jakarta-servletapi could be changed to jakarata-servletapi-22. > Votes please? > > Craig McClanahan > > Votes please? > > --
Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Glenn Nielsen wrote: > > "Craig R. McClanahan" wrote: > > > > Now that we've all recovered from New Years (and watched Oregon State teach > > Notre Dame a few things about football -- go Beavers! :-), it's time to lay out > > the next steps in Tomcat 4.0's lifetime. Here's what I propose: > > > > (1) Tomcat 4.0 Beta 1 > > > > The code for Tomcat 4.0 has proven to be quite solid and reasonably bug free > > (except for the new web connector -- see below), so it's time to start doing > > beta cycles to increase the exposure and testing it receives. I would like us > > to move quickly towards a "release quality" build, and therefore propose to > > create Tomcat 4.0 Beta 1 on Friday 5, 2001 -- after having a chance to integrate > > a few more bug fixes for issues that were reported in the last couple of weeks. > > > > The web connector code is much less tested than the standalonie connector, so I > > propose that we highlight the fact that this portion of Tomcat 4.0 is still > > alpha quality. The build process has been organized so that we can create two > > files (mod_webapp.so and warp.jar) and publish updates separately, if needed, > > without doing a complete release. This will help us isolate and fix such > > problems more quickly. > > > > +1 for separate mod_wepp/warp releases. > > > The existing "jakarta-tomcat-4.0" repository will be branched with label > > "tomcat_40_branch", and each 4.0.x beta and release will receive a label such as > > "tomcat_40_b1". The "main" branch of this repository will be active for bug > > fixes on 4.0, while major new development will shift to the 4.1 repository > > described below. > > -0 I'm not sure what the above branches buy us, will all bug fixes and commits >still go to the main 4.0 branch? With the other beta branches just being a > snapshot >of the code when the beta was released? -0 -> +1 after reading comments > > > > (2) Tomcat 4.1 Repository > > > > As we approach a release quality build for Tomcat 4.0, it is also time to split > > the development of major new functionality (such as the distributed session > > management currently under discussion) into a development process that does not > > destabilize the 4.0 release code. We can do this with a branch or a new > > repository. After thinking about the relative merits of this for a bit, and > > consulting with others who have managed similar evoluations, I think a new > > repository is the way to go. > > > > Therefore, I propose to create a new "jakarta-tomcat-4.1" repository on Friday > > as well, based originally on the code that is marked for Tomcat 4.0 beta 1. > > Because this code is just another portion of the overall code base for Tomcat, > > all existing Tomcat committers will have write access to it (just as they do > > with "jakarta-tomcat" and "jakarta-tomcat-4.0" today) -- no extra committer > > votes are required. > > > > NOTE: Pending this change, I would ask that we *not* commit changes to the 4.0 > > repository for new features that will appear in 4.1, until *after* the split. > > > > At the same time, I will modify the build processes that create nightly > > distributions of Tomcat to create a build of the most recent 4.0 tree and the > > most recent 4.1 tree, so that people interested in either version can follow > > along as they prefer. > > > > -1 I would rather see a feature freeze for 4.0, and continue to focus efforts >on completing, testing, and bug fixing 4.0. (I want to have the Java > SecurityManager >as a 4.0 feature) Once 4.0 is released then fork the code. This way we will >stay focused on the 4.0 release. Could an updated list of features and their >status be posted? > -1 -> +1 But I hope we stay focused on getting 4.0 released so it doesn't just sit there for months like 3.2 did. > > (3) New "jakarta-servletapi-4.0" CVS Repository > > > > Consistent with the suggested approach for separate Tomcat repositories for each > > major version, I suggest that we also split the repository for the servlet 2.3 / > > JSP 1.2 API classes. Currently, this code is in a branch (SERVET_23_JSP_12) of > > the "jakarta-servletapi" repository, which makes life tougher on build scripts > > than is necessary. > > > > Therefore, I propose that we also create a new repository for these API classes > > (the
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler Compiler.java
"Scott M. Stirling" wrote: > > On 05 Jan 2001 16:35:09 -0800, Hans Bergsten wrote: > > "Scott M. Stirling" wrote: > > > 1. Doesn't it seem a bit sloppy to leave a bunch of classes loaded that > > > will never get dumped unless the server is shutdown? Just a matter of > > > elegance, I suppose. > > [Hans Bergsten] > > > Yes, it does. But AFAIK there's no way you can just unload a class > > from the JVM; you would have to drop the class loader for the > > context and reload all classes that are still valid. That doesn't > > seem like the right thing to do in this situation IMHO. > > It depends how class loading in Tomcat works. I'm familiar with JRun > 3.0, which works like this (I'm not giving away any family secrets, this > stuff is documented in various places in Allaire docs): > > - servlets & JavaBeans (even those called by JSPs) - loaded by a > classloader with web-app scope. If a single servlet changes, the whole > web-app's classloader is dumped so the servlet can be dynamically > reloaded. No need to actively reload the other classes that got dumped > with the classloader. They'll be reloaded as needed when requests come > in for them. > > - JSPs are each loaded in their own classloader. So if a JSP is changed > and reloaded, the old classloader is dumped and a new one created. > JavaBeans are delegated to the web-app classloader, for whatever reason. > > All this may change in future versions, when JRun reloads tag handlers > dynamically. I have no idea how Tomcat handles these classloader > issues, but it would be interesting to hear about if anyone can distill > it briefly. > Tomcat has a webapp classloader and Jasper has a class loader for JSP pages. The webapp classloader is caching everything loaded from the WEB-INF/classes or WEB-INF/lib directories. Since Jasper is running within the web app, if the webapp context gets reloaded, jasper gets reloaded. Jasper IMHO is convoluted in the way it loads JSP's. It munges the names when creating the java source and class, and increments each of these files each time the JSP is compiled. All those old versions of the classes stay resident in the Jasper class loader and all the old java and class files clutter up the work dir. While I am implementing the Java SecurityManager in Tomcat 4 I am also going to cleanup how Jasper loads classes so that there is one URLClassLoader per JSP page. And that URLClassLoader gets reinstantiated when the JSP page gets recompiled. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: BugRat Report #690 has been filed.
I stand corrected.
The below problem was a bug in Tomcat. Wrapping the RequestDispatcher
forward() and include() methods with a doPrivileged() if a SecurityManager
is being used fixed the problem. When Tomcat 3.2.2 is released you will
no longer need to edit the jre/lib/security/java.security file to comment
out the package.access=sun. line.
This fix is in the 3.2 CVS branch, and will be in the Tomcat 3.2.2 release.
Regards,
Glenn
Glenn Nielsen wrote:
>
> This isn't a Tomcat bug, its the way security works (whether correct or not).
> Perhaps this should be sent in as a Java bug report to Sun.
>
> This is documented in tomcat-security.html, you have to comment out
> the line:
>
> package.access=sun.
>
> in your $JAVA_HOME/jre/lib/security/java.security file.
>
> BugRat Mail System wrote:
> >
> > Bug report #690 has just been filed.
> >
> > You can view the report at the following URL:
> >
> ><http://znutar.cortexity.com/BugRatViewer/ShowReport/690>
> >
> > REPORT #690 Details.
> >
> > Project: Tomcat
> > Category: Bug Report
> > SubCategory: New Bug Report
> > Class: swbug
> > State: received
> > Priority: high
> > Severity: serious
> > Confidence: public
> > Environment:
> >Release: Tomcat 3.2.1
> >JVM Release: 1.2.2
> >Operating System: Windows 2000 Pro
> >OS Release: ?
> >Platform: Intel
> >
> > Synopsis:
> > jsp compliation error
> >
> > Description:
> > The default javasoft/JRE/1.2/lib/security/java.security file restricts use of the
>sun. packages.
> >
> > Both Tomcat and EmbededTomcat fail with the following error:
> >
> > Unable to compile class for JSP
> > java.security.AccessControlException: access denied (java.lang.RuntimePermission
>accessClassInPackage.sun.tools.java
> >
> > Adding the following to the default tomcat.policy file does not correct the error:
> >
> > grant {
> > permission java.lang.RuntimePermission "accessClassInPackage.sun.tools.java";
> > };
> >
> >
>--
> > Name: Report-690.html
> >Report-690.html Type: Hypertext Markup Language (text/html)
> > Encoding: 7bit
> > Description: DataSource attachment 'Report-690.html'
> >
> >Part 1.3Type: Plain Text (text/plain)
>
> --
> --
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> --
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: BugRat Report #690 has been filed.
Craig, Bug fixes for use of the Java SecurityManager are done and working well. I do want to add another doc for setting up the SecurityManager when using MS Windows OS's. Glenn "Craig R. McClanahan" wrote: > > Glenn Nielsen wrote: > > > I stand corrected. > > > > The below problem was a bug in Tomcat. Wrapping the RequestDispatcher > > forward() and include() methods with a doPrivileged() if a SecurityManager > > is being used fixed the problem. When Tomcat 3.2.2 is released you will > > no longer need to edit the jre/lib/security/java.security file to comment > > out the package.access=sun. line. > > > > This fix is in the 3.2 CVS branch, and will be in the Tomcat 3.2.2 release. > > > > Glenn (and others), > > Have we accumulated enough bug fixes where it's worth creating a 3.2.2 release, or >are there more issues that should be > dealt with first? > > > > > Regards, > > > > Glenn > > > > Craig > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] Tomcat 4 SecurityManager implementation
Context threads will be named threads with the name set to the string representing the file URL of the Context. i.e. "file:/usr/local/tomcat/webapps/examples". All other threads should be named with a name which doesn't start with "file:". The setContext() method will maintain a HashMap which maps ApplicationSecurity to its thread name. When a permission check fails the security manager will see if the current thread or any of its parent threads are for a web app context. If it is for a context, the permission check will be done using the permissions for that web application context. If the permission is for file read, permission will be granted for the context root directory. With the changes to jasper below, the normal permission check will work for everything except when a web app context is using a class from the shareable ClassLoader. So the overhead of using the Thread naming conventions to perform the second web app context security check should be minimal, most of the time if the first permission check fails, the second one would also. Jasper JSP class loading Jasper will have the old 1.1 compatability code stripped out. The work directory will be moved inside the web application context /WEB-INF/ directory. This will make security configuration easier and security checks more efficient. The jasper work dir for a context would be /WEB-INF/work/. This should be safe, other important files which need to be protected from outside view are stored in WEB-INF such as java properties files and class files. /WEB-INF/work will not be added to the contexts class path. Jasper will be modified so that each individual jsp page will have its own URLClassLoader. When each jsp page has its own URLClassLoader we can remove the need to munge and version the jsp java and class file names. We can also create directory paths in the work dir for the context that matches the jsp page path in the context. This will make it easier to view the generated source for a jsp page. When a jsp page is recompiled, a new instance of the URLClassLoader for that page will be created. These changes will also prevent implementation of a SecurityManager from coupling Jasper to Tomcat like it is in the 3.x branch. Future enhancements --- See if it is possible and secure to let an individual web application set its security policies in its own policy file located in its /WEB-INF/ directory. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Peter Donald wrote:
>
> At 12:46 14/1/01 -0600, Glenn Nielsen wrote:
> >Tomcat 4 Java SecurityManager Proposal
> >
> >
> >Tomcat 4 will require the Java SecurityManager, use of the
> >SecurityManager will be optional when Tomcat is embedded in
> >another application.
>
> Why not always have it optional possibly determined by a system property
> value ? This way you won't have people complainig about slow down if they
> don't care about security ;) It will also be easier to integrate into other
> products.
>
> >Setting policies for web application contexts
> >-
> >
> >A web application has its security based on either the default grant in
> >tomcat.policy or an entry for the context which uses the Context path
> >file URL as the codeBase. This policy will be in affect for any Class running
> >within the Context thread no matter which ClassLoader loaded the class
> >which triggered a security check. A default permission to read files in
> >the Context path is granted.
> >
> >// Default permissions for a Context, all contexts have these permissions
> >grant {
> >permission java.util.PropertyPermission "file.separator", "read";
> >permission java.util.PropertyPermission "path.separator", "read";
> >permission java.util.PropertyPermission "line.separator", "read";
> >};
> >
> >// Additional Permissions for tomcat examples context
> >grant codeBase="file:${tomcat.home}/webapps/examples/- {
> >permission java.util.PropertyPermission "*", "read";
> >};
>
> I have actually implemented something similar this in Avalon about 7 hours
> ago checking it in. Avalon has notion of .sars (Server Application
> Archives) which are very similar to .wars in idea. I was having some issues
> with JVM wide policy which you advocate above so I started playing around
> with a per-sar policy.
>
> To do this I had to subclass SecureClassLoader (I did this via
> URLClassLoader) and overide it's method
>
> protected PermissionCollection getPermissions( final CodeSource codeSource );
>
Duh! Somehow that method never popped out when I was looking at the URLClassLoader
class. That will make things even easier.
Your per application config below would work for Tomcat, but it would be nice
to see if a standard java policy file per web application could be used instead.
> I overode this to access a per-sar Policy object. If no policy was given it
> would give full access to the system. As I was embedding policy information
> in another file (an XML file) it looked something like
>
>
>
>
>
>
>
>
>
>
>
>
> To do this I implemented AbstractPolicy (for generic facilities) and
> SarPolicy (for configuring it from XML file). I have attached the relevent
> classes just in case you are interested.
>
> >Future enhancements
> >---
> >
> >See if it is possible and secure to let an individual
> >web application set its security policies in its own
> >policy file located in its /WEB-INF/ directory.
>
> This is a great facility - when implementing the equivelent for Avalon I
> found it vital for a usable system ;)
>
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] Tomcat 4 Java Security Manager, rev 2
P connection.
This is because the security permissions allowed for the current class
are based on the intersection of its permissions with the permissions of
all the parent classes on the stack.
Security restrictions for using classes
---
StandardClassLoader will implement the SecurityManager.checkPackageAccess()
method to determine whether the ClassLoader has permission to access the
packages "sun.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"accessClassInPackage.{package name}", it will not be allowed to use a
Class in the package.
Security restrictions for defining classes
--
StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
method to determine whether the ClassLoader has permission to define a class
in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"defineClassInPackage.{package name}", it will not be allowed to define
a Class in the package.
Changing security policies at runtime
-
Anytime a Context is reloaded the security policies will be refreshed
from the tomcat policy file.
StandardClassLoader
---
All of the code for implementing system, restricted, and allowed
checks will be removed. This will be handled by the SecurityManager.
Remove the ability to configure a contexts classloader in the
server.xml Context element.
Implement the URLClassLoader getPermissions() method when the
StandardClassLoader is used for a web application context.
A FilePermission "context root", "read" will be added to
those permissions configured for the context in the policy file.
Jasper JSP class loading
Jasper will have the old 1.1 compatability code stripped out.
Jasper will be modified so that each individual jsp page
will have its own URLClassLoader. When each jsp page has
its own URLClassLoader we can remove the need to munge and version
the jsp java and class file names. We can also create directory
paths in the work dir for the context that matches the jsp page
path in the context. This will make it easier to view the
generated source for a jsp page. When a jsp page is recompiled,
a new instance of the URLClassLoader for that page will be
created.
Implement the URLClassLoader getPermissions() method.
A FilePermission "context root", "read" will be added to
those permissions configured for the context in the policy file.
These changes will also prevent implementation of a SecurityManager
from coupling Jasper to Tomcat like it is in the 3.x branch.
Future enhancements
---
See if it is possible and secure to let an individual
web application set its security policies in its own
policy file located in its /WEB-INF/ directory.
Another alternative would be to create a tool in the
admin servlet that will allow editing of policy file
entries for a context. This tool would have permission
to rewrite the tomcat.policy file, updating the
codeBase entries for the context.
Status of the code
--
I have the security implementation in place for the
Tomcat core. I am now tracking down those places
where internal tomcat code has to be wrapped inside
a doPrivileged().
Once I get Tomcat 4 core done, I will move on to Jasper.
Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades
Looks like there are enough +1's and no -1's to implement the architecture
change required for the SecurityManager.
I was hoping someone more familiar with the Tomcat 4 architecture would step
up to do this. But since one else has, I'll take a stab at it since I am
implementing the SecurityManager.
Regards,
Glenn
"Craig R. McClanahan" wrote:
>
> BACKGROUND:
>
> One of the unique (AFAIK) features of Tomcat 3.2 as a servlet container is the
> fact that you can choose to run Tomcat under a Java SecurityManager (when
> running under a Java2 JDK), with corresponding fine-grained control over the
> resources that a particular web application can access. In addition, the
> security manager can be used to constrain an application from accessing Tomcat
> internals (for example, by trying to cast the HttpServletRequest it receives
> back to the Tomcat internal implementation class).
>
> This feature has long been on the wish list for 4.0, and recently Glenn Nielsen
> <[EMAIL PROTECTED]> has volunteered to complete it. Those involved in
> 3.2 will recall that Glenn was also the primary "mover and shaker" in
> implementing the security manager feature there.
>
> Currently, as a stopgap security measure, Tomcat 4.0's web application
> classloader implements some specific restrictions on access to particular Java
> packages -- for example, an application level class is not allowed to load any
> class in the org.apache.catalina.* hierarchy. While this does indeed protect
> the internal implementation classes, it becomes redundant once running under a
> security manager is installed -- the checkPackageAccess() method serves this
> purpose in a much more powerful and controlled approach.
>
> THE CURRENT SITUATION:
>
> Currently, the internal object that implements the Java Servlet API objects
> exposed to application components implement the corresponding API interfaces
> directly. For example:
>
> public class StandardSession
> implements HttpSession, Session, Serializable {
>
> ...
>
> }
>
> so that, when an application calls request.getSession, an instance of this class
> (suitably cast to HttpSession) is returned. The application cannot cast the
> returned object to an org.apache.catalina.session.StandardSession, because of
> the customized restrictions implemented in the web application class loader.
>
> Switching to the security manager for protection requires a change in this
> approach, because the security permissions of a StandardSession are based on
> where *that* class was loaded from, and not from the interfaces it implements.
>
> THE PROPOSAL:
>
> For each Servlet API interface that represents an internal Catalina object
> exposed to an application object, create a new
> org.apache.catalina.facade.XFacade class according to the following basic
> pattern:
>
> * Pass the internal object to the constructor (the facade
> will be a wrapper around it).
>
> * Implement the appropriate servlet API interface (so the
> facade object can be passed to application components)
>
> * For each public method in the interface, implement a doPrivileged
> block that calls the corresponding method on the underlying
> internal Catalina object.
>
> For example, the session facade object would look something like this:
>
> package org.apache.catalina.facade;
>
> import javax.servlet.http.HttpSession;
> import org.apache.catalina.Session;
>
> public class SessionFacade implements HttpSession {
>
> protected Session session = null;
>
> public SessionFacade(Session session) {
> super();
> this.session = session;
> }
>
> public String getId() {
> AccessController.doPrivileged(
> new PrivilegedAction()
> {
> public Object run() {
> return (session.getId());
> }
> }
> );
> }
>
> ... same pattern for all other public methods ...
>
> }
>
> Additionally, the logic that implements request.getSession() would be modified
> to look up and return the facade object associated with the current session,
> instead of the actual StandardSession object itself.
>
> RECOMMENDATION:
>
> Implementing the remainder of the security manager logic in Tomcat 4.0 was part
> of the agreed-upon original release plan, and Glenn has volunteered to undertake
> the other changes necessary to Catalina and Jasper to make this happen (and
> there are lots of them -- thanks Glenn!). It seems that addi
Re: [PROPOSAL] Revised Tomcat 4.0-beta-2 Release Plan
+ 1 for the plan, and I will assist as indicated "Craig R. McClanahan" wrote: > > Over the last week or so, there has been some interest in changes to Tomcat > 4.0-beta-1, including some changes in fundamental APIs within Catalina. It > would be desireable to make these changes before a 4.0 release is completed, so > that we can strive to maintain API compatibility, to the maximum degree > possible, throughout the 4.x lifetime. > > Therefore, I would like to propose "unfreezing" the 4.0 codebase, and opening it > again to new development, with some of the major items listed below. The > revised release plan for Tomcat 4.0 Beta 2 would then become: > > Proposed Release Manager: Craig McClanahan (unless someone > else wants to volunteer for this part) > Proposed Code Freeze Date: February 5, 2001 (two weeks from today) > > Major Work To Be Completed: > > * Finish the Valves API Changes originally suggested by > Peter Donald, and formalized in my proposal last weekend > (I am working on this; it is nearly ready for testing). > > * Finish the new package layer needed to implement the > security manager (Glenn Nielsen is working on this; Remy > Maucherat has volunteered to assist). > > * Backport the changes to the Resources implementation > from 4.1 to the 4.0 repository. This implementation is the > basis for being able to run webapps independent of the filesystem > (for example, direct from a WAR file or from a database that is > configured appropriately). (Remy Maucherat has volunteered > to do this). > > NOTE: WIth this change, we will no longer need to maintain the > "jakarta-tomcat-4.1" repository, or do double commits on fixes. > We can recreate the 4.1 repository when 4.0 is refrozen, based > on the current code at that time. > > * Major improvements and updates to the mod_webapp connector > module, as well as bug fixes between now and release. (Pierpaollo > Fumagalli has volunteered to work on this). > > * Integrate the changes for persistent session storage, as well as > session passivation and activation, proposed by Kief Morris. This > will initially be checked into a temporary branch for experimentation, > but will likely be found solid enough to incorporate into 4.0-b2. (I > will do the commits now, but will also propose Kief as a committer > in his own right if he's interested). > > * Miscellaneous bug fixes from BugRat reports, as well as bug reports > on the mailing lists. (a variety of patches have already been proposed). > > * POSSIBLE ITEM: Tweak the lifecycle APIs so that we can implement > running Catalina under the "invocation" interface in the services directory. > Among other things, this will allow running Tomcat 4.0 stand alone on > port 80, without having to run as root. (No volunteer yet to work on this). > > Craig McClanahan > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
jakarta-watchdog-4.0 fixes
jakarta-watchdog-4.0 needs two things fixed: 1. build.sh uses the shell /bin/bash instead of /bin/sh 2. build.xml refers to jakarta-servletapi-4 instead of jakarta-servletapi-4.0 I would commit these fixes, but I don't have commit for jakarta-watchdog-4.0 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: jakarta-watchdog-4.0 fixes
"Craig R. McClanahan" wrote: > > Glenn Nielsen wrote: > > > jakarta-watchdog-4.0 needs two things fixed: > > > > 1. build.sh uses the shell /bin/bash instead of /bin/sh > > > > Fixed. > Thanks > > > > 2. build.xml refers to jakarta-servletapi-4 instead of jakarta-servletapi-4.0 > > > > It is supposed to. The API classes for servlet 2.3 / JSP 1.2 got moved to a new > repository named "jakarta-servletapi-4" (not 4.0 because it will be constant > throughout Tomcat 4.x) instead of being a branch on the "jakarta-servletapi" > repository (whose main branch has the servlet 2.2 / JSP 1.1 API classes). > Ok > > > > I would commit these fixes, but I don't have commit for jakarta-watchdog-4.0 > > > > That can be fixed if you'd like to help update the test suite ... want me to > propose you? (WATCHDOG-DEV is the relevant mailing list). > That would come in handy if I get time to setup watchdog tests for SecurityManager related issues. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 watchdog failures
The latest Tomcat 4 from CVS has the following watchdog errors the _second_ time you run watchdog, it all passes the first time. FAIL GET /jsp-tests/jsp/core_syntax/scripting/scriptlet/positiveScriptlet.jsp HTTP/1.0 FAIL GET /jsp-tests/jsp/core_syntax/scripting/scriptlet/positiveScriptletXML.jsp HTTP/1.0 FAIL GET /servlet-tests/DoInit1Test HTTP/1.0 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 Jasper ClassLoading changes to support SecurityManager
In order to make it easier to integrate the SecurityManager into Jasper for Tomcat 4 and to change some of Japsers annoying behaviours, I have been working on switching Jasper over to the URLClassLoader. I have the class loading changes in place and Jasper passes all watchdog tests. I wanted to run these changes past everyone before I finish cleaning up the changes and committing it. (I still have some work to do on JspC and still need to add support for the SecurityManager.) Jasper now creates a URLClassLoader for each JSP page and defers any other class loading to the web app context class loader. Using a single class loader per JSP allowed me to remove all the code that increments the class version number, i.e. the work directory no longer has multiple *.java and *.class files for the same JSP page. These changes also made it easy for me to put the java source and class files in the same directory tree as found in the web app context. When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. These changes simplified the code quite a bit and also gave a performance improvement. When running watchdog tests the new jasper was ~25% faster than the current jasper on a first compile or on first jsp class access after restart. On recompile of a jsp page it was 37% faster. Execution of JSP servlet after it had already been compiled and loaded was slightly faster. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 Jasper ClassLoading changes to support SecurityManager
"Craig R. McClanahan" wrote:
>
> Glenn Nielsen wrote:
>
> > In order to make it easier to integrate the SecurityManager into Jasper
> > for Tomcat 4 and to change some of Japsers annoying behaviours, I have
> > been working on switching Jasper over to the URLClassLoader.
> >
> > I have the class loading changes in place and Jasper passes all watchdog
> > tests. I wanted to run these changes past everyone before I finish
> > cleaning up the changes and committing it. (I still have some work to
> > do on JspC and still need to add support for the SecurityManager.)
> >
> > Jasper now creates a URLClassLoader for each JSP page and defers any other
> > class loading to the web app context class loader. Using a single class
> > loader per JSP allowed me to remove all the code that increments the
> > class version number, i.e. the work directory no longer has multiple
> > *.java and *.class files for the same JSP page. These changes also made
> > it easy for me to put the java source and class files in the same directory
> > tree as found in the web app context. When Jasper is run in a servlet
> > container it no longer puts the class files in a package, they are now
> > in the default package.
> >
>
> I'm a little uncomfortable with making Jasper's servlets not belong to a package
> any longer. My issue relates to developers who (mistakenly) try to reference
> beans in that are not in any package -- currently, that does not
> work in Tomcat, or in any other container that uses an implicit package. But,
> with this change, such an incorrect bean usage would work in Tomcat, but would
> cause portability problems for apps that depend on that behavior.
>
> I'd much rather see the generated servlets that Jasper creates continue to be
> placed in a package, to protect developers from themselves on this issue.
>
The class name used is the mangled jsp file name with the .jsp replaced with _jsp.
For /examples/jsp/date/date.jsp the class name would be "date_jsp.class" located
in "${tomcat.home}/work/localhost/examples/jsp/date/".
The URLClassLoader for the JSP page will only load the class "date_jsp" or inner
classes like "date_jsp$SomeClass". All other classes will be delegated to the
parent web app context class loader.
>From looking at the current JasperLoader, they behave the same way.
If jsp:useBean requires that a Bean class exist in a package it should handle
that. (I haven't found that in the JSP1.1 spec yet)
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 Jasper ClassLoading changes to support SecurityManager
"Craig R. McClanahan" wrote:
>
> Glenn Nielsen wrote:
>
> > "Craig R. McClanahan" wrote:
> > >
> > > Glenn Nielsen wrote:
> > >
> > > > In order to make it easier to integrate the SecurityManager into Jasper
> > > > for Tomcat 4 and to change some of Japsers annoying behaviours, I have
> > > > been working on switching Jasper over to the URLClassLoader.
> > > >
> > > > I have the class loading changes in place and Jasper passes all watchdog
> > > > tests. I wanted to run these changes past everyone before I finish
> > > > cleaning up the changes and committing it. (I still have some work to
> > > > do on JspC and still need to add support for the SecurityManager.)
> > > >
> > > > Jasper now creates a URLClassLoader for each JSP page and defers any other
> > > > class loading to the web app context class loader. Using a single class
> > > > loader per JSP allowed me to remove all the code that increments the
> > > > class version number, i.e. the work directory no longer has multiple
> > > > *.java and *.class files for the same JSP page. These changes also made
> > > > it easy for me to put the java source and class files in the same directory
> > > > tree as found in the web app context. When Jasper is run in a servlet
> > > > container it no longer puts the class files in a package, they are now
> > > > in the default package.
> > > >
> > >
> > > I'm a little uncomfortable with making Jasper's servlets not belong to a package
> > > any longer. My issue relates to developers who (mistakenly) try to reference
> > > beans in that are not in any package -- currently, that does not
> > > work in Tomcat, or in any other container that uses an implicit package. But,
> > > with this change, such an incorrect bean usage would work in Tomcat, but would
> > > cause portability problems for apps that depend on that behavior.
> > >
> > > I'd much rather see the generated servlets that Jasper creates continue to be
> > > placed in a package, to protect developers from themselves on this issue.
> > >
> >
> > The class name used is the mangled jsp file name with the .jsp replaced with _jsp.
> > For /examples/jsp/date/date.jsp the class name would be "date_jsp.class" located
> > in "${tomcat.home}/work/localhost/examples/jsp/date/".
> > The URLClassLoader for the JSP page will only load the class "date_jsp" or inner
> > classes like "date_jsp$SomeClass". All other classes will be delegated to the
> > parent web app context class loader.
> >
> > >From looking at the current JasperLoader, they behave the same way.
> >
> > If jsp:useBean requires that a Bean class exist in a package it should handle
> > that. (I haven't found that in the JSP1.1 spec yet)
> >
>
> I'm sorry ... I wasn't clear enough. My concern is not with the JSP page class, it's
> with the bean class.
>
> Consider that you have a bean class Foo.java (no package). If your JSP page says:
>
>
>
> this will fail under current Tomcat implementations, but succeed with your suggested
> change. The reason relates to the way that Java interprets an "unpackaged" class
>name
> -- it assumes the same package as the calling class.
>
Does this mean that all "unpackaged" classes loaded by a JSP page should fail with
CNFE?
If so, that is easy to implement in the ClassLoader without putting the servlets
generated
for the JSP pages in a package.
Glenn
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: An alternative to JSP
This list is for discussing issues related to developing the Tomcat servlet container, not design of web applications. Could this discussion get moved elsewhere? Thanks, Glenn Brad Cox wrote: > > At 11:23 AM -0500 01/26/2001, Brad Cox wrote: > >so the user's session will be lost if they ever browse > >to a hard-coded html pag > > I meant to say... > > for browsers that don't support cookies or if the user has disabled cookies. > -- > --- > Dr. Brad Cox; [EMAIL PROTECTED] > Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 > http://superdistributed.com: A new paradigm for a new millinneum > PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 Jasper ClassLoading changes to support SecurityManager
Steve Downey wrote: > > I've been looking at Jasper because it is severly broken on NT, or any other > filesystem that has limited length filenames. The prefix encoding of the > servlet path extends the filename of the .java and .class files well past > the limit. This is actually preventing me from using Tomcat in developement > and production right now. > > Putting all of the files in the unnamed package worries me. For the reasons > that Craig mentioned, as well as the unforseen side effects, since the > unnamed package is imported by default. > > Also, I suspect that it further diverges the behaviour of the > CommandLineCompiler and the JSPCompiler. These are for two different purposes and already are signicantly different. > > The CommandLineCompiler is supposed to produce classes that, with some > additional support classes, can be installed in any servlet container. If > all of the classes are in the same package, namespace collisions are an > issue. The prefix mangling is an attempt to get around the collision > problem. However, it is working against the language itself. The Java > mechanism for distinguishing classes is the package mechanism. Avoiding > packages because they require opening directories, and opening directories > is inefficient, is somewhat perverse, and is the direct cause of [for me] a > show stopping bug. > I am still working on JspC, but its ability to put the generated servlet classes in a package will be retained. The class name mangling was needed to get around the problem of Jasper having one single class loader for ALL jsp pages in a web app context. This is not a problem in the new jasper because each individual jsp page has its own URLClassLoader designed to only allow loading of that pages JSP servlet, all other class load requests are delegated to the parent class loader. This way their is no possiblity of any class naming collisions. If jasper were using the default java class loader then the naming collison problems you mentioned would be a concern. > [eg > ./workflow/mynetfolio/openorders/openordersdetails/openorder_detail_cancel_c > ontent.jsp > turns into > > C:\netbeans\temp\jspwork\1c7b23dd\workflow\mynetfolio\openorders\openordersd > etails\_0002fworkflow_0002fmynetfolio_0002fopenorders_0002fopenordersdetails > _0002fopenorder_0005fdetail_0005fcancel_0005fcontent_0002ejspopenorder_0005f > detail_0005fcancel_0005fcontent_jsp_0.java > which overflows the 256 char path limit > ] > [Don't bother discussing the various ways the NT file system is brain > damaged. I'll agree, but it doesn't fix my problem ] > > Getting back to Glenn's work. I believe that the classes generated need to > be in a package related to the path the jsp was compiled from. It's the most > natural mapping, and works around the mangling except in perverse borderline > cases. > There can be problems with using the context directory path. What if you have the context /examples with the following jsp /examples/org/apache/catalina/some.jsp? It would want to put the jsp in the same package as org.apache.catalina, this is a security problem. > And yes, to answer the obvious question, I don't expect someone else to fix > this for me. The new Jasper does fix this for you. > > -Original Message- > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 25, 2001 5:46 PM > To: [EMAIL PROTECTED] > Subject: Tomcat 4 Jasper ClassLoading changes to support SecurityManager > > In order to make it easier to integrate the SecurityManager into Jasper > for Tomcat 4 and to change some of Japsers annoying behaviours, I have > been working on switching Jasper over to the URLClassLoader. > > I have the class loading changes in place and Jasper passes all watchdog > tests. I wanted to run these changes past everyone before I finish > cleaning up the changes and committing it. (I still have some work to > do on JspC and still need to add support for the SecurityManager.) > > Jasper now creates a URLClassLoader for each JSP page and defers any other > class loading to the web app context class loader. Using a single class > loader per JSP allowed me to remove all the code that increments the > class version number, i.e. the work directory no longer has multiple > *.java and *.class files for the same JSP page. These changes also made > it easy for me to put the java source and class files in the same directory > tree as found in the web app context. When Jasper is run in a servlet > container it no longer puts the class files in a package, they are now > in the default package. > > These changes simplified the code quite a bit and also gave a performance > improvement. > > When running watchdog tests t
Tomcat 4 CVS running a web app from a war file
I updated Tomcat 4 which has the new code that allows running directly from a WAR file. A few comments about this. I will refer to the 'examples' context in my comments. The directory 'work/localhost/examples/classes is created for the contents of 'webapps/examples/WEB-INF/classes. First, what if there were a directory named 'webapps/examples/classes' which contained JSP pages, wouldn't this conflict with where you put the WEB-INF classes? Wouldn't it be better to put them in work/localhost/examples/WEB-INF/classes ? Second, if a WAR is already unarchived in the webapp directory, i.e. both examples.war and examples/ exists, why is the 'work/localhost/examples/classes' directory created? Which takes precedence, the shadowed war file in work/localhost/examples ? or the unarchived copy in webapps/examples? What is the expected behaviour of this feature if you drop a war file in a webapp directory? What if you update a war file? 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 CVS running a web app from a war file
Remy Maucherat wrote: > > > I updated Tomcat 4 which has the new code that allows running directly > > from a WAR file. A few comments about this. > > > > I will refer to the 'examples' context in my comments. > > > > The directory 'work/localhost/examples/classes is created for > > the contents of 'webapps/examples/WEB-INF/classes. > > > > First, what if there were a directory named 'webapps/examples/classes' > > which contained JSP pages, wouldn't this conflict with where you put > > the WEB-INF classes? Wouldn't it be better to put them > > in work/localhost/examples/WEB-INF/classes ? > > > > Second, if a WAR is already unarchived in the webapp directory, > > i.e. both examples.war and examples/ exists, why is the > > 'work/localhost/examples/classes' directory created? > > All this is created fro Jasper. The compiler (javac) needs to have real > class files and real JARs on the HD. These files are *not* used for anything > else. > No classloading or resource loading occurs from there, so it won't conflict > with other stuff in the webapp. > Then those jar files and class files need to be in a directory that won't possibly conflict with jasper if a user has a directory named "classes" in the root of their context which contains JSP's. Please use WEB-INF/lib and WEB-INF/classes in the work dir context directory. > > Which takes precedence, the shadowed war file in work/localhost/examples ? > > or the unarchived copy in webapps/examples? > > > > What is the expected behaviour of this feature if you drop a war file in > > a webapp directory? What if you update a war file? > > Note: Jasper is temporarily broken when running from a WAR. > Ok, its broke. But how is this supposed to work? Inquiring minds want to know. Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: problem in using SecurityManager with tomcat
Look at tomcat.sh, the shell arg "-security" needs to be shifted out so it isn't
passed on as an option just before java org.apache.tomcat.startup.Tomcat is started.
BTW, this is fixed for the next Tomcat 3.2.x release.
Regards,
Glenn
Gauri Sukhatankar wrote:
>
> Hi,
>
> I am having problems in using the SecurityManager with tomcat 3.2.1.
> There seems to be a bug or documention mismatch.
> Please let me know if you have any ideas on fixing this:
>
> I am using Tomcat 3.2.1 to run a servlet that acts as an RMI client.
> Based on the documentation
> (http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/uguide/tomcat-security-
> unix.html) I have done the following to allow for listen, accept, resolve socket
> security permissions through my web application:
>
> 1. Edited server.xml to use Policy:
>
>
> 2. Edited tomcat.policy
>
> 3. Started tomcat with the "-security" option.
>>> tomcat.sh start -security
>
>
> Although the script "tomcat.sh" accepts the "-security" option, the class:
> org.apache.tomcat.startup.Tomcat
> exits with a Usage error :
>
> Usage: java org.apache.tomcat.startup.Tomcat {options}
> Options are:
> -config file (or -f file) Use this file instead of server.xml
> -help (or help)Show this usage report
> -home dir (or -h dir) Use this directory as tomcat.home
> -stop
>
> On the other hand, if i don't use policy I get an access control exception with
> this stack trace:
>
> java.security.AccessControlException: access denied (java.net.SocketPermission
> 172.20.71.30:1099 connect,resolve)
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Compiled Code)
> at java.lang.Throwable.(Compiled Code)
> at java.lang.Exception.(Compiled Code)
> at java.lang.RuntimeException.(RuntimeException.java:47)
> at java.lang.SecurityException.(SecurityException.java:39)
> at
> java.security.AccessControlException.(AccessControlException.java:57)
> at java.security.AccessControlContext.checkPermission(Compiled Code)
> at java.security.AccessController.checkPermission(Compiled Code)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkConnect(SecurityManager.java:1021)
> at java.net.Socket.(Socket.java:258)
> at java.net.Socket.(Socket.java:98)
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFacto
> ry.java:29)
> at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(Compiled
> Code)
> at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:497)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:194)
> at sun.rmi.transport.tcp.TCPChannel.newConnection(Compiled Code)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
> at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
> at java.rmi.Naming.lookup(Naming.java:89)
> at RMIServlet.connectToServer(RMIServlet.java:72)
> at RMIServlet.init(RMIServlet.java:21)
> at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317)
> at org.apache.tomcat.core.Handler.init(Handler.java:215)
> at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296)
> at org.apache.tomcat.core.Handler.service(Handler.java:254)
> at
> org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
> at
> org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797)
> at
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
> at
> org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConne
> ctionHandler.java:210)
> at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code)
> at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code)
> at java.lang.Thread.run(Thread.java:479)
>
> Thanks in advance,
>
> Gauri Sukhatankar
> Sun Microsystems, Inc.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
> > Tomcat 3.3 Release Plan Ballot: > > [ ] +1I am in favor of this plan and will help > [X] +0I am in favor of this plan, but am unable to help > [ ] -0I am not in favor of this plan > [ ] -1I am against this plan being executed, and my > reason is: > > <-> > ------ Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] CVS Commit: Keith Wannamaker
+1 Jon Stevens wrote: > > Ok, > > He has been sending lots of excellent patches as well as the fact that he > already has an apache.org account. I think we should give him commit access. > > We need two more +1's from others with commit access. > > -jon > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- ---------- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 SecurityManager and Jasper ClassLoader changes
I have completed the changes necessary to implement the Java SecurityManager in Tomcat 4. I have also completed switching Jasper over to using the URLClassLoader. With these changes in place all watchdog tests pass and JspC works as well as it did before I changed Jasper. I'll commit all the changes tomorrow after I do a final update from CVS and finish the docs. This has been fun. At one point I had to find a work around to prevent HotSpot from core dumping with an internal error! 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 SecurityManager and Jasper ClassLoader changes
In answer, here is a copy of the original message I posted. Glenn Original Message Subject: Tomcat 4 Jasper ClassLoading changes to support SecurityManager Date: Thu, 25 Jan 2001 16:46:20 -0600 From: Glenn Nielsen <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] In order to make it easier to integrate the SecurityManager into Jasper for Tomcat 4 and to change some of Japsers annoying behaviours, I have been working on switching Jasper over to the URLClassLoader. I have the class loading changes in place and Jasper passes all watchdog tests. I wanted to run these changes past everyone before I finish cleaning up the changes and committing it. (I still have some work to do on JspC and still need to add support for the SecurityManager.) Jasper now creates a URLClassLoader for each JSP page and defers any other class loading to the web app context class loader. Using a single class loader per JSP allowed me to remove all the code that increments the class version number, i.e. the work directory no longer has multiple *.java and *.class files for the same JSP page. These changes also made it easy for me to put the java source and class files in the same directory tree as found in the web app context. When Jasper is run in a servlet container it no longer puts the class files in a package, they are now in the default package. These changes simplified the code quite a bit and also gave a performance improvement. When running watchdog tests the new jasper was ~25% faster than the current jasper on a first compile or on first jsp class access after restart. On recompile of a jsp page it was 37% faster. Execution of JSP servlet after it had already been compiled and loaded was slightly faster. Regards, Glenn Mel Martinez wrote: > > --- Glenn Nielsen <[EMAIL PROTECTED]> wrote: > > I have completed the changes necessary to implement > > the Java SecurityManager > > in Tomcat 4. I have also completed switching Jasper > > over to using the > > URLClassLoader. > > Glenn, > > Could you describe (briefly) the nature of the change > in terms of the API? I.E. Did you just reimplement > JasperLoader to extend URLClassLoader or did you > create a new loader class entirely? > > I am currently using the tc3.x jasper API by extending > it (to add a variety of needed features) and am going > to have to make the plunge to tc4.x eventually. Up > till now I am pretty sure I've avoided any dependency > that would preclude using the tc4.x version. Just > staying on my toes here. > > Thanks, > > Mel > > __ > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
"Craig R. McClanahan" wrote: > > [EMAIL PROTECTED] wrote: > > > When Jasper is run in a servlet > > container it no longer puts the class files in a package, they are now > > in the default package. > > > > As was discussed earlier on TOMCAT-DEV, this is going to cause > portability problems for people who use beans that are not in packages. > With this > change, such beans will work in Tomcat but not when the app is moved to > a different container that *does* put JSP-generated servlets into a > package. > > The previous behavior (Jasper-generated servlets go into a package) > avoided this, because it essentially disallowed non-packaged beans. > Therefore, I prefer it. > > (Also, I seem to remember a discussion on the expert group for JSP 1.2 > that non-packaged beans and generarted classes should be disallowed, but > I have not yet located any reference to this in the 1.2 spec.) > If you check the code for JasperLoader you will find that it requires all classes to be in a package, the only class that does not have to be in a package is the JSP page itself. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
"Craig R. McClanahan" wrote: > > Glenn Nielsen wrote: > > > "Craig R. McClanahan" wrote: > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > When Jasper is run in a servlet > > > > container it no longer puts the class files in a package, they are now > > > > in the default package. > > > > > > > > > > As was discussed earlier on TOMCAT-DEV, this is going to cause > > > portability problems for people who use beans that are not in packages. > > > With this > > > change, such beans will work in Tomcat but not when the app is moved to > > > a different container that *does* put JSP-generated servlets into a > > > package. > > > > > > The previous behavior (Jasper-generated servlets go into a package) > > > avoided this, because it essentially disallowed non-packaged beans. > > > Therefore, I prefer it. > > > > > > (Also, I seem to remember a discussion on the expert group for JSP 1.2 > > > that non-packaged beans and generarted classes should be disallowed, but > > > I have not yet located any reference to this in the 1.2 spec.) > > > > > > > If you check the code for JasperLoader you will find that it requires > > all classes to be in a package, the only class that does not have to > > be in a package is the JSP page itself. > > > > That's true, but Steve Downey also found the spec reference I couldn't find (in > Section 8.2 of the JSP 1.2 Proposed Final Draft). The JSP page class is > required to be in a package for 1.2. > Ok, I'm convinced thanks to Steve and Craig. I'll put compiled jsp pages in the package "org.apache.jsp" (JspC can still specify a package). I will have to make some changes to the Jasper class loader to support this. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
Mel Martinez wrote: > > The package naming solution I've opt'ed for in my own > enhancement to Jasper (which I'll gladly share) is to > derive package names that are related to the location > of the jsp relative to the server context. This is > simple, flexible and should avoid collisions. > There is no need for all this complexity to generate a package name in the new Jasper. The way jasper now loads jsp pages, each page is completely isolated from all other pages. Every jsp page compiled could be a class named "org.apache.jsp.MyJSP" without any concern whatsoever about conflicts because each individual page has its own class loader. I will modify the current jasper class loader to support putting the jsp pages in a package, but this is just to comply with the JSP 1.2 spec. All of the previous code in jasper to do all the package and class name mangling was to overcome the limitations of how the Jasper class loader for jsp pages was designed. The new jasper makes it very easy to find and view the java source for a translated jsp page, it is located in work/somehost/someapp/some/context/path/MyJSP.java. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
Mel Martinez wrote: > > --- Glenn Nielsen <[EMAIL PROTECTED]> wrote: > > > There is no need for all this complexity to generate > > a package name > > in the new Jasper. > > Hmmm... compared to the gobbledy-gook that was being > done before, I'd hardly call what I did complex. > Aside from options, all it does is very simply asign > the JSP page a package name based on it's directory > hierarchy and place the .java and .class files in same > - this is consistant with strict java naming > convention. > > The way jasper now loads jsp > > pages, each page is > > completely isolated from all other pages. Every jsp > > page compiled > > could be a class named "org.apache.jsp.MyJSP" > > without > > any concern whatsoever about conflicts because each > > individual page > > has its own class loader. > > Ah, I see, you avoid file-level conflicts by placing > the generated code into separate directory paths, even > though the package names (currently) do not reflect > the directory locations. Yup, that should work, > although i wouldn't say it is any less complex and I > don't think it is consistent with standard java > package/directory naming conventions. > > > The new jasper makes it very easy to find and view > > the java source for > > a translated jsp page, it is located in > > work/somehost/someapp/some/context/path/MyJSP.java. > > > > Does it not seem logical to assign a package to the > MyJSP class based on all or part of the above path? > > This may seem like esthetics, I suppose. Not > something we should get stressed about. > > What you've done is a great improvement over what was > there. Does it work with tc 3.3? > It should work for tc 3.x, but I don't have the time to back port it. -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper CommandLineContext.java
Steve Downey wrote: > > Placing all generated servlet classes into the same package only works if > the loader cooperates. If the container does not use a separate, special, > classloader for each page, it will not be able to distinguish the different > instances of MyJSP.class, or in my case of index.class. JSP pages are portable between containers and JSP engines. But there is no requirement that a runtime servlet compiled by a specific JSP engine be compatible with other JSP engines. The class loading for a compiled jsp page is done by jasper for a page compiled by jasper. > > That implies that the command line compiler must produce distinguishable > class names for each jsp that is produced, as it is a requirement that the > servlet class be portable among containers, as long as support classes the > jsp implementation depends on are packaged in the WAR file (section 2.1.5 > Compiling JSP Pages). The interface contract is supposed to be the only > dependency between the container and the servlet. > It still can, just tell JspC what package to put the generated servlets in on the command line. > Following on to this, I would prefer that the classes that the command line > compiler and the runtime compiler, differ as little as possible. It should > be possible to make them identical. That way, the code that is developed and > tested can be identical to the code that is shipped to QA and to production. > It doesn't matter what package jasper puts compiled runtime servlets in, it is all internal to jasper. Regards, Glenn > -Original Message- > From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 06, 2001 9:48 PM > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: > jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper > CommandLineContext.java > > Mel Martinez wrote: > > > > The package naming solution I've opt'ed for in my own > > enhancement to Jasper (which I'll gladly share) is to > > derive package names that are related to the location > > of the jsp relative to the server context. This is > > simple, flexible and should avoid collisions. > > > > There is no need for all this complexity to generate a package name > in the new Jasper. The way jasper now loads jsp pages, each page is > completely isolated from all other pages. Every jsp page compiled > could be a class named "org.apache.jsp.MyJSP" without > any concern whatsoever about conflicts because each individual page > has its own class loader. I will modify the current jasper class loader > to support putting the jsp pages in a package, but this is just to comply > with the JSP 1.2 spec. > > All of the previous code in jasper to do all the package and class name > mangling was to overcome the limitations of how the Jasper class loader > for jsp pages was designed. > > The new jasper makes it very easy to find and view the java source for > a translated jsp page, it is located in > work/somehost/someapp/some/context/path/MyJSP.java. > > 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > <><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission > may contain confidential information and is intended only for the person(s) > named. Any use, copying or disclosure by any other person is strictly > prohibited. If you have received this transmission in error, please notify > the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 status
I was wondering what the status of getting Tomcat 4 ready for its next beta release currently is. I have finished implementing the Java SecurityManager and the changes to jasper class loading. I know we took a step back to make a few architectural changes. Are those all in place now? Can we move toward another beta release? Whats the status of mod_webapp and the Warp connector? 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.2.2 Release Plan
Marc Saegesser wrote: > > Tomcat 3.2.2 Release Plan Ballot: > > [X] +1I am in favor of this plan and will help > [ ] +0I am in favor of this plan, but am unable to help > [ ] -0I am not in favor of this plan > [ ] -1I am against this plan being executed, and my > reason is: > I can test on Solaris sparc/x86 JRE 1.3 and FreeBSD 3.x with jdk1.2 beta. And test with the java security manager enabled. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 mod_webapp segmentation fault bug
Tomcat 4 mod_webapp segmentation fault bug. If I start apache, then start tomcat 4, the apache process will seg fault when a request gets mapped to tomcat. If I reload apache, the problem is fixed. [Mon Feb 12 14:55:08 2001] [notice] child pid 19336 exit signal Segmentation Fault (11) Apache 1.3.9 SunOS slate.spg.more.net 5.7 Generic_106541-12 sun4u sparc SUNW,Ultra-250 $ java -server -version java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-RC) Java HotSpot(TM) Server VM (build 1.3.0-RC, mixed mode) Latest tomcat 4 from CVS. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 Apache mod_webapp/Warp NPE
org.apache.catalina.connector.warp.WarpHost.invoke(WarpHost.java:111) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162) at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879) at org.apache.catalina.connector.warp.WarpEngine.invoke(WarpEngine.java:115) at org.apache.catalina.connector.warp.WarpRequestHandler.process(WarpRequestHandler.java:165) at org.apache.catalina.connector.warp.WarpHandler.run(WarpHandler.java:156) at java.lang.Thread.run(Thread.java:484) -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 Watchdog 4 test failures using xerces
) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897) at java.lang.Thread.run(Thread.java:484) Is this a problem with crimson also? Or is this a general problem in Tomcat4? 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 JNDI Resource config
I have been looking through the source for configuring JNDI Resources and ResourceParams. For now, it looks like these can only be configured in the Context scope. Is there any reason why this couldn't be changed so that a JNDI DataSource could be configured at the Engine or Host scope? This would come in handy when you want to configure a JDBC DataSource or JavaMail DataSource that is common to either the entire Engine or an entire Host. Then the resources available to a web app context would be all those configured for the Engine, Host, and the individual Context. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 class loaders
I was looking at the classloader documentation in cvs at catalina/docs/dev/classloaders.html and comparing it to how Tomcat 4 actually sets up the classloaders. I found some discrepancies. According to the docs the System class loader (CLASSPATH) has bin/bootstrap.jar and $JAVA_HOME/lib/tools.jar. But in catalina.sh bin/servlet.jar and bin/naming.jar are also added. According to the docs the Common class loader includes bin/servlet.jar and bin/naming.jar, but these are already in the System classpath. What need is their to create another layer of class loading using the Common class loader if it is duplicating jar files already in the class path. Perhaps the Common class loader could be removed? In the docs the Server class loader includes all jar files in /server, but when the class loader is created, it also adds /classes if it exists. The Shared class loader includes all jar files in /lib, as documented. Question? What if I have some API I want to install that is shared by web applications, but this API needs to use a properties file? There is no place to install it. Perhaps we could remove /classes from the Server class loader and add it instead to the Shared class loader. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PROPOSAL] Tomcat 4 class loaders
After thinking about this some more I have a proposal to change the Tomcat 4 class loading. The class loaders that Catalina uses are organized as follows, where the parent class loader is above the child class loaders: Bootstrap | System | Common /|\ Catalina Webapp1 Webapp2 ... Bootstrap - This class loader contains the basic runtime classes provided by the Java Virtual Machine, such as the java.* classes. Depending on how your particular JVM is organized, this may actually be more than one class loader, or may not exist at all. It is generally not referenced directly. System - This class loader is initialized from the contents of the CLASSPATH environment variable. The standard Catalina startup scripts assemble the following repositories for the system class path: $CATALINA_HOME/system/lib/bootstrap.jar - The Bootstrap class that is used to initialize the Catalina server, and the class loader implementation classes it depends on. $CATALIA_HOME/system/lib/servlet.jar - The Servlet and JSP API classes, placed here so that they are shared between Catalina and the web applications that run under it. $CATALIA_HOME/system/lib/naming.jar - The JNDI implementation used by Tomcat 4. $JAVA_HOME/lib/tools.jar - Contains the Java compiler used to compile the servlets generated from JSP pages. Common - This class loader is where common Java API's shared by web applications and by Catalina are stored. For example, this is where a JDBC driver could be installed so that both web applications and catalina have access to it. Catalina may need to access the JDBC driver if you configure a JNDI JDBC DataSource in your server.xml and a web application may need access if the JNDI JDBC DataSource is configured in the web apps web.xml file. This class loader is initialized to include all JAR files in the $CATALINA_HOME/common/lib directory, and $CATALINA_HOME/common/classes. Catalina - This class loader is initialized to include all JAR files in the $CATALINA_HOME/server/lib directory, which should contain Catalina itself (i.e. all classes whose fully qualified names begin with org.apache.catalina.), and any JAR files that it depends on, and $CATALINA_HOME/server/classes. Because these classes are loaded from a separate class loader, which is not visible to the Webapp class loader, they are not visible to web applications. Webapp - A class loader is created for each web application that is installed in Catalina, and initialized to include the WEB-INF/classes directory (if it exists), plus all JAR files in the WEB-INF/lib directory, for this web app. Because of the parentage hierarchy, web applications can indirectly see (and therefore load classes from) the Common, System, and Bootstrap class loaders, but not from the Catalina class loader. The above changes remove one class loading layer from a web app, allows Common classes to use property files and resources, and cleans up the directories where jar files and classes are located. Comments? Regards, Glenn Glenn Nielsen wrote: > > I was looking at the classloader documentation in cvs at > catalina/docs/dev/classloaders.html and comparing it to > how Tomcat 4 actually sets up the classloaders. I found > some discrepancies. > > According to the docs the System class loader (CLASSPATH) > has bin/bootstrap.jar and $JAVA_HOME/lib/tools.jar. But in > catalina.sh bin/servlet.jar and bin/naming.jar are also added. > > According to the docs the Common class loader includes > bin/servlet.jar and bin/naming.jar, but these are already in > the System classpath. What need is their to create another > layer of class loading using the Common class loader if it > is duplicating jar files already in the class path. Perhaps > the Common class loader could be removed? > > In the docs the Server class loader includes all jar files in > /server, but when the class loader is created, it also adds > /classes if it exists. > > The Shared class loader includes all jar files in /lib, as documented. > > Question? > > What if I have some API I want to install that is shared by web > applications, but this API needs to use a properties file? There > is no place to install it. Perhaps we could remove /classes from > the Server class loader and add it instead to the Shared class loader. > > Regards, > > Glenn > > -- > Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| &
Re: [PROPOSAL] Tomcat 4 class loaders
Remy Maucherat wrote: > > > The above changes remove one class loading layer from a web app, > > allows Common classes to use property files and resources, and cleans > > up the directories where jar files and classes are located. > > The Catalina core would see the shared libraires, which is a very bad idea > IMO. We'll get into the same kind of class conflicts and sealing violations > we now face because Jasper uses JAXP 1.1. > I really can't see any real benefits (but I can see a lot of problems) in > removing the shared class loader. > Thats right! Ok, I retract my proposal for changing the class loaders. > What we can do is add a lib/classes/ repository to the shared classloader. > I still think it would be a good idea to change the directory structure of where the lib/classes are located to make it clearer where to install libraries/resources. System class loader uses jars located in $CATALINA_HOME/system/lib $CATALINA_HOME/system/classes Common class loader uses jars/classes/resources located in $CATALINA_HOME/common/lib $CATALINA_HOME/common/classes Shared class loader for web applications uses jars/classes/resources located in $CATALINA_HOME/lib $CATALINA_HOME/classes Catalina private jars/classes/resources located in $CATALINA_HOME/server/lib $CATALINA_HOME/server/classes The classes directories would only be added to the list of URL's for a class loader if it exists And remove servlet.jar and naming.jar from the catalina.sh start script. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4 class loaders
Remy Maucherat wrote: > > > Remy Maucherat wrote: > > > > Thats right! Ok, I retract my proposal for changing the class loaders. > > > > > What we can do is add a lib/classes/ repository to the shared > classloader. > > > I still think it would be a good idea to change the directory structure of > > where the lib/classes are located to make it clearer where to install > > libraries/resources. > > I agree with most of the following changes, except that I think it would > create too many places where you can put libraries (and some are not useful > IMO in the current situation). > > > System class loader uses jars located in > > $CATALINA_HOME/system/lib > > $CATALINA_HOME/system/classes > > -0 to -1. > Why have a system directory ? > Right now, the system CL only contains bootstrap.jar (and also tools.jar, > but it's not in one of TC subfolders), so I would just leave it in bin (it's > simpler, and people will start to get confused in there are too many places > where you can put your libraries). > I see your point. bootstrap.jar can be left in /bin > > Common class loader uses jars/classes/resources located in > > $CATALINA_HOME/common/lib > > $CATALINA_HOME/common/classes > > +1. > > > Shared class loader for web applications uses jars/classes/resources > located in > > $CATALINA_HOME/lib > > $CATALINA_HOME/classes > > +1. > > > Catalina private jars/classes/resources located in > > $CATALINA_HOME/server/lib > > $CATALINA_HOME/server/classes > > -0. > I don't see any situation where splitting the server directory would be > useful. > > > The classes directories would only be added to the list of URL's for > > a class loader if it exists > > > > And remove servlet.jar and naming.jar from the catalina.sh start script. > > +1. > > Note: Craig may veto these changes because we're so late in the dev cycle. > > Remy > This really isn't much of a change. Just a few changes to build.xml and startup/Bootstrap.java, plus updating the docs. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 tasks to complete prior to beta 2 release
What should be completed prior to the Tomcat 4 beta 2 release? Here is my list of what would be nice to get done for the Tomcat 4 beta 2 release. Test Craig's Jasper compiler XML parser class loading changes. Apache mod_webapp/Warp connector at beta quality. I consider this to be a critical component. What is the status, Pier? Modify the directory location where catalina looks for lib/classes as mentioned in my class loading proposal. Finish writing the documentation. Anything else? 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 4 Jasper class loading watchdog tests
I tested Tomcat 4 after Craig's changes to jasper. Initial watchdog run w/o Java SecurityManager, all tests passed. Second run of watchdog immediately after the first run, the following three tests failed. FAIL GET /jsp-tests/jsp/core_syntax/scripting/scriptlet/positiveScriptlet.jsp HTTP/1.0 FAIL GET /jsp-tests/jsp/core_syntax/scripting/scriptlet/positiveScriptletXML.jsp HTTP/1.0 FAIL GET /servlet-tests/DoInit1Test HTTP/1.0 Shutdown tomcat then restart and run watchdog tests, all tests passed. Second run of watchdog immediately after previous run, the following three tests failed. FAIL GET /jsp-tests/jsp/core_syntax/scripting/scriptlet/positiveScriptlet.jsp HTTP/1.0 FAIL GET /jsp-tests/jsp/core_syntax/scripting/scriptlet/positiveScriptletXML.jsp HTTP/1.0 FAIL GET /servlet-tests/DoInit1Test HTTP/1.0 Clean out logs and work directory. Initial watchdog run with Java SecurityManager had a host of failed tests. After adding a grant for $CATALINA_HOME/jasper in catalina.policy and minor patches to catalina/core/StandardWrapper.java and jasper/servlet/JspServlet.java, all watchdog tests pass with the same results as above tests w/o SecurityManager. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
