Re: [PROPOSAL] Distributing the .jar files as binaries in release
In general, I like the idea because there are numerous
projects out there that use specific jars from tomcat
and this would greatly ease access. There is some
discussion going on elsewhere in the community for
distributing jars with this kind of model. The idea
is that an application's expressed dependencies on 3rd
party packages can include a URL to the specific jar
(including version specification). Thus deployment
host platforms can automatically retrieve and resolve
dependencies without the application developer having
to be responsible for unpacking, repackaging a subset
of tomcat (or whatever) and then possibly having to
provide the subset on his/her own server.
The caveats are that I don't know if there is
consensus yet on versioning format, there definitely
are too many competing package dependency schemes and
I'm not sure what the impact of jar refactoring will
be.
Overall, though, I like the idea.
My $.02
Mel
--- Costin Manolache [EMAIL PROTECTED] wrote:
[deleted]
I would like to start adding .jar files as part of
the release process
for tomcat - eventually even for 4.1.24 ( we just
need to upload the
current jars as a separate download ).
The proposal is very simple:
- jars will be placed in
/dist/jakarta/tomcat-x/binaries/
( the standard location in the current mirroring
scheme )
- we include only the .jars that are part of tomcat.
In time
we should make sure that the projects we depend on (
logging,
digester, etc ) start doing the same, and we can
adjust the
build process to get only the jars and support the
mirrors.
For example:
commons-logging.jar=${mirror}/jakarta/commons/binaries/commons-logging.jar
- the jar names should be fully versioned (
otherwise we can't keep
more than a version in the dist dir ), and a
symbolic link will point to
the latest release.
We would have:
catalina.jar - catalina-4.1.24.jar
tomcat-util.jar - tomcat-util-4.1.24.jar
etc.
- in tomcat5 we should start including the _major_
version number in the
jar name: catalina5.jar. A version number should be
used whenever we have
a break in backward compatibility.
[deleted]
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Patch: org.apache.catalina.util.RequestUtil
Hi folks!
I haven't contributed to tomcat in so long, I no
longer have a working password to apache.org! :-)
I.E. - my last commit predates the great break-in of
'01 and during that time I had moved, changed jobs,
etc. so I didn't get a new password back when they
were being reset. It feels cool to be posting to
tomcat-dev again! :-)
Well, sure enough, I have a change I need to commit.
Attached is a patch to fix an obscure use of a
deprecated java.lang.String method
(getBytes(int,int,byte[],int)). In this case the fix
is to simply use getBytes().
The patch I built applies the fix for
jakarta-tomcat-4.0/catalina/share/src/org/apache/catalina/util/RequestUtil.java
The same problem is also in the same file in the
jakarta-tomcat-catalina module. Are these sym-linked
together (i.e are they the same file?) or does the
change need to be submitted separately for identical
files in the separate modules?
I am working on a project that may require the removal
of the use of other deprecated API's and (among other
things) we are using an embedded form of tomcat that
may need to run on a VM that does not support
deprecated APIs. If someone would tell me who I
should contact to reset my committer account access
([EMAIL PROTECTED]), it would be very helpful.
Cheers,
Mel
Dr. Mel Martinez
[EMAIL PROTECTED]
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
Index: RequestUtil.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
retrieving revision 1.19
diff -u -r1.19 RequestUtil.java
--- RequestUtil.java21 Feb 2002 22:51:55 - 1.19
+++ RequestUtil.java12 Feb 2003 17:18:27 -
@@ -331,9 +331,7 @@
throws UnsupportedEncodingException {
if ((data != null) (data.length() 0)) {
-int len = data.length();
-byte[] bytes = new byte[len];
-data.getBytes(0, len, bytes, 0);
+byte[] bytes = data.getBytes();
parseParameters(map, bytes, encoding);
}
@@ -371,9 +369,7 @@
if (str == null)
return (null);
-int len = str.length();
-byte[] bytes = new byte[len];
-str.getBytes(0, len, bytes, 0);
+byte[] bytes = str.getBytes();
return URLDecode(bytes, enc);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PLAN] New Jasper
[mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 0:37 Nice to hear that, one comment, there is a jakarta-tomcat-jasper repository with code Costin and Mel did some time ago as an initial effort to refactor the 3.3 Jasper, i dont know which is the state of the code there but maybe it's good idea to use it for your effort.. Unfortunately, Mel has been COMPLETELY immersed in matters unrelated to Tomcat or Jasper for many months. You know, silly stuff like earning money with new job to pay for overpriced new house. :-| So the state of the Jasper refactoring has been pretty much frozen for ages. If someone wants to pick up the ball and run with it, don't worry about my ego. I'd just like to see SOMETHING done to fix Jasper! Kin-Man : If it helps, feel free to build on what we started. We did not get too far, unfortunately before my job situation changed (like a lot of folks last year, eh?). There were a few goals of the refactoring effort we started to keep in mind: 1) modularity (a) - able to use the result with various servlet engines. For example, it should be able to support a Jasper implementation as servlet, intercepter, command line or whatever. We did not want a Jasper that was tied to a particular Tomcat implementation or even to tomcat at all, except as barely required. It should be possible to plug Jasper into most any servlet container. Done correctly, this should STILL allow one to utilize optimizations provided by the particular engine. 1) modularity (b) - nearly ALL functionality of Jasper should be plug-replaceable in a clean, consistent fashion. This is necessary to support not just (1a), but also to make it easier to improve Jasper without proposing the annual rewrite from scratch. 2) able to support both jsp servlet specs 3) able to support pre-jdk 1.2 systems My scheme for this was to heavily utilize the factory pattern via a highly extendable Toolkit metaphor. The toolkit would be driven by configurations in .properties file. The configurations would first of all allow the toolkit to generate an extention of itself appropriate for the particular container (for ex., TC3 or TC4). Then the toolkit would be used to generate all the requisite pieces of functionality required for Jasper such as class loaders, parsers, compilers, caches, etc. I had started with the base toolkit with providing some base utility functions (all replaceable through configuration properties). Basically, any identifiable functionality of Jasper that can be represented with a consistent interface could be implemented with a toolkit factory method. Because the pattern allowed for the toolkit to generate extentions of itself, there is no limit to the factory methods that can be supported. The utilization of this pattern is pretty straightforward. A particular jasper implementation would ask the toolkit to first generate an extention of itself appropriate for the implementation, then it would ask for the appropriate pieces needed to build the functionality of Jasper into that implementation. At the time, I thought the idea had a ton of merit and wish I could devote the cycles to finishing it. I simply do NOT have the time necessary to do so. Take a look at it. If you feel it is something you can use, great! If not, that's also great! I would just like to see SOME progress at improving Jasper once and for all. I would be a little sad if our modularity goals were lost along the way, though. You definitely should use the jakarta-tomcat-jasper repository, though. Cheers and good luck! Mel Dr. Mel Martinez Extreme Blue/Cambridge IBM __ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.0.1 ClassLoader breaks singletons on webapp reload.
--- Kevin A. Burton [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So what patterns do developers follow when the want to deploy webapps with singletons that have support for reloading? Kevin You have a couple of basic strategies for having 'part' of your application persist as (a) loaded class(es) through the reload of other classes during run-time. One strategy is to save and restore your loaded state based on life-cycle events (servlet destroy() and init()) or using a ServletContextListener (if you are using a Servlet 2.3 compliant container). Before a web app is reloaded, it must be destroyed so you can use this opportunity to save the state, perhaps as a serialized object for speed, and then on reload you can check for the presence of persisted state information and use maybe a semaphore of some sort (i.e. a date threshold or a flag) to indicate whether you want to load it instead of going through your normal initialization routine. Restoring using serialized objects can often be much faster than a full startup going through a complex initialization cycle. The negative with this route is that it may require considerable rewriting of your application. Also, if you serialize data in classes that get modified, make sure you use a Serial Version ID and follow the rules for safely upgrading classes for serializable objects. See the serialization API docs for details and tips. Alternatively, and _possibly_ much simpler, you could place the classes that must persist through the dynamic reload of others into the 'shared' or 'common' classloader space so that they are not reloaded except on application server restart. This will force those classes to be loaded by the parent class loader of the web application classloaders and so will remain loaded and be referanceable from the objects created by the classes loaded by the web-app class loader. However, the reverse is not necessarily true. That is, objects created from classes loaded by the 'shared' or 'common' class loader can not 'see' the classes loaded by the child webapp class loader. This could be a problem if the long-lived part of your application tries to use classes only loaded by the web-app loader. This can be prevented in design by using interface classes that do not get reloaded and only referencing dynamically reloaded class implementation objects through those long-lived interface classes. Another potential negative about this strategy is that the classes loaded in the 'shared' or 'common' areas are visible to other web applications. That may be an issue if you are sharing use of the tomcat server with other applications. So either strategy MAY require significant rewrites to your application, depending on how your code is designed. Good luck, Mel Dr. Mel Martinez Extreme Blue/Cambridge IBM __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jasper34 - status
+1 I just want to throw in that I think this is going great. I am tracking the list and watching the changes as best I can via cvs web. I am dying to get my network and dev environment moved up here so I can contribute a ton of ideas and code that are in my head, but that is not going to happen for at least several weeks now. Sigh... Mel --- Costin Manolache [EMAIL PROTECTED] wrote: FYI, I'm not planning any major changes in the near future for jasper34. I'm reasonably happy with the first round of cleanup and refactoring, and I think we are moving in a good direction with the toolkit-isation of jasper and the various optimizations we discussed. I want to let the code stabilize a bit and get more feedback before I start the next step. I'll keep doing small changes and fixes, probably finish the line number mapping and start restoring what was broken during the first step ( jspc is one, jspservlet needs a bit more testing after the class loader changes ), plus some improvements in the runtime. I think the I/O changes, the Liaisons, the overal structure are 'under control', it's just a matter of finding the time to implement them. The big one is the internal API to be used for the tree and generators - it has to be as simple as possible in order to be able to move fast in creating inline versions for common tags and to allow various optimizations in taglibs. I think we can start experimenting in the current version with generating special code for some tags - and use this to learn more about it. ( I expect some more major jasper34 changes after 3.3 beta ) Costin __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: New CVS Repositories
Hi folks, Once again, I must apologize for my recent lack of participation. I've been traveling quite a bit (house hunting - it is official, we'll be moving to the greater boston area.) and so I have not been able to keep up with the list except in spurts. I've just now managed to catch up with all of the discussion on this. Craig did check with me via side mail before starting the proposal and I was and am in agreement with it. Just a bit of comment... --- Craig R. McClanahan [EMAIL PROTECTED] wrote: Per our discussion today, I have created two new CVS repositories associated with the Tomcat subproject: jakarta-tomcat-connectorsFor development of web connectors for various versions of Tomcat. jakarta-tomcat-jasperFor development of a next generation Jasper (JSP) implementation. I'm not sure if the proper repository name for a servlet-engine-independent version of Jasper (which is a primary goal of the jasper34 refactoring) should be 'jakarta-tomcat-jasper'. Why not just jakarta-jasper? Also, regardless of the name, we will need to make it clear to folks that the above repositories are developmental for now and that users should continue to use the tc3 and tc4 specific versions of Jasper that are included in those respective repositories. Regarding collaboration: This is open source. Let's stop espousing on the exact reasons or motivations on why anything is done by anybody. Different folks have very legitimate reasons for doing what they are doing. Otherwise, they would either not do them or they will fail and stop doing it. Thus, there are very good reasons to continue support and development of not only tc3.3 but also tc3.2, just like hundreds of other open source projects, some quite obscure. I am not going to list my reasons, but they have been (and still are) compelling to me and folks should just accept that. If this was not open source, and their were corporate cost/benefit considerations, then participation in a project might be questioned. But this is not, so it shouldn't be. In order to work together, we simply have to agree (VOTE) on the objectives of a project and do it. The primary objective here is that we will develop a version of Jasper that is independent of either version of tomcat and that it will be extendable to support JSP 1.2 spec (and hopefully beyond). I'm not going to worry too much on why other folks are contributing towards those objectives. And if other folks are contributing towards other objectives (i.e. projects) that I don't care about, I'm going to assume they have their reasons. Okay, I'm off my soap-box. I will try to stay involved with this effort as much as possible, but the truth is I am going to be deathly busy with the move up north over the next few weeks. When I started the jasper34 proposal I did not anticipate making such dramatic career/life changes so soon. Please be patient with me. :-) Or better yet, feel free to run with your own ideas from what I started. I'll be glad to play catch up as soon as I get my situation under control. There is definitely going to be an extended 'down' period though, during which I will probably not have a development system available. Cheers, Mel __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: [VOTE] New Committer: Kevin Seguin
+1 Mel --- GOMEZ Henri [EMAIL PROTECTED] 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 __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: [VOTE] New Committer: Bip Thelin
+1 Mel --- Remy Maucherat [EMAIL PROTECTED] wrote: - Original Message - From: Kief Morris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 22, 2001 2:22 AM Subject: [VOTE] New Committer: Bip Thelin 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. +1. Remy __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Jasper
--- [EMAIL PROTECTED] wrote: Hi, While Mel is working on the JspServlet proposal, I thought it would be a good idea to send my notes on jasper. I looked at both "branches" of jasper, with the idea of trying to merge them while preserving each "personality". As I expected, most of the code is still common, with only few variations that can be resolved by modularization. Unfortunately, the code requires some work in order to implement most of the optimizations I have in mind and before we can merge them. Some ideas are available at http://nagoya.apache.org/~costin/jasper.txt I don't know how much free time I'll have for that before 3.3 beta, but there are a lot of cool things that can be done in jasper ( and not only performance enhancements ). Costin, Thanks for the above thoughts (in jasper.txt). Very useful input. I'm going to more fully ingest that and merge aspects of it, where appropriate into my (really 'our') proposal. In the mean time, I've decided to get the current state of jasper34 checked in for you and others to start to take a look at it. Everything is checked in to CVS in two folders: jakarta-tomcat/proposals/jasper34 jakarta-tomcat/src/jasper34 Please peruse the above after you do an update and give me your feedback. Everything is in it's infancy and subject to change, so be kind :-) Cheers, Mel __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Jasper
--- Mel Martinez [EMAIL PROTECTED] wrote: --- [EMAIL PROTECTED] wrote: Hi, While Mel is working on the JspServlet proposal, I thought it would be a good idea to send my notes on jasper. I looked at both "branches" of jasper, with the idea of trying to merge them while preserving each "personality". As I expected, most of the code is still common, with only few variations that can be resolved by modularization. Unfortunately, the code requires some work in order to implement most of the optimizations I have in mind and before we can merge them. Some ideas are available at http://nagoya.apache.org/~costin/jasper.txt I don't know how much free time I'll have for that before 3.3 beta, but there are a lot of cool things that can be done in jasper ( and not only performance enhancements ). Costin, Thanks for the above thoughts (in jasper.txt). Very useful input. I'm going to more fully ingest that and merge aspects of it, where appropriate into my (really 'our') proposal. In the mean time, I've decided to get the current state of jasper34 checked in for you and others to start to take a look at it. Everything is checked in to CVS in two folders: jakarta-tomcat/proposals/jasper34 jakarta-tomcat/src/jasper34 Please peruse the above after you do an update and give me your feedback. Everything is in it's infancy and subject to change, so be kind :-) FYI: for those who don't have or want to have tc3.3 checked out, you can also access the proposal via CVSWeb by using the link: http://jakarta.apache.org/cvsweb/index.cgi/~checkout~/jakarta-tomcat/proposals/jasper34/JasperToolkit.html I expect this document to undergo rapid and dramatic changes, so check back occasionally on it. Mel __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
he toolkit is going to be the access to the web.xml info. Done properly, this service could be provided by a Tomcat-supplied object when running within tomcat, but implemented standalone when running in some other container. This will be one of the next services we will try to abstract into the toolkit model. It seems obvious that it relies on XML, though so it may be useful to solve the XML service refactoring first, though. Regarding Logging: This one might be pretty easy to decouple through the toolkit. I'll look into it. The beauty of this is it should be pretty easy to add services to the toolkit (or to a subclass) one at a time and then gradually adopt useage in the actual adapter implementation. I hope this is helpful. Mel Dr. Mel Martinez Senior Software Architect G1440, Inc., http://www.g1440.com [EMAIL PROTECTED] --- Greg Wilkins [EMAIL PROTECTED] wrote: Costin, [EMAIL PROTECTED] wrote: ... The end result will be a more portable jasper - that will be usable in multiple containers with minimal pain ( and with enough hooks to allow the container to provide specific features and optimizations ). Excellent - That sounds much easier for us to keep in sync with. Still, it would be good to have a maintainer to step forward and help us with the transition It may be good for somebody on the development team to have another servlet container to test against? It is not an easy project - and it would be great to get help, feedback and sugestions from jetty developers. Ok - I'll give brief over view of the changes and ideas that we have at the moment. The first change we made was to provide a logging facade class, so that the link with tomcat logging could be broken. Jasper code makes logging calls on a Jasper class, which we have implemented to call the Jetty logging facility.This probably should be generalized so that a dynamically selected logging facade can be configured for JSP. Secondly we replaced the XML parsing with our own wrappers for a JAXP parser. As Jetty is targetted for small memory footprint systems, we wish to avoid DOM as it is too heavy weight when you consider it is often only used only to read a config file (once loaded, the DOM classes stay in memory). I think a generic jasper should probably only assume a JAXP parser in the environment and then only use the SAX elements of it. Another concern I have is that I don't think that jasper should be parsing the web.xml file itself. Consider an deployment in an EJB container that uses JSP, the web.xml may be parsed 3 times, once by the EJB container looking for ejb-ref tags, once by the servlet container and then finally by the JspServlet.I think Jasper should be written to allow a deployer to push this configuration into it. Initially it would have to have it's own pusher that did parse the web.xml file, but eventually it would be good to make a proposal to the servlet spec guys to come up with an API to allow a servlet container to export the parts of the web.xml it does not know how to handle. For example - the jetty/jboss integration module under development now registers for callbacks when the container parses ejb-ref tags. The classloading configuration is a bit ugly. I'm not sure how this can be cleaned up, but currently in Jetty we have hard coded detection of the JspServlet so that the context classloader can be set as an InitParam. It would be better jasper could do a better job of trying to locate the context classloader itself. Finally I also have a few half formed ideas of how to improve the generation of web.xml fragments by the pre-compiler, so that it pays better attention to existing jsp mappings in the existing web.xml. Is there a jasper specific mailing list that we can tune into to monitor your jasper efforts? or is it just the general tomcat dev mailing list? If nobody steps forward to help maintain jetty-jasper (I call it jesper :-) and transition to the new portable version, then it would be good to have a focused mailing list to monitor and contribute to. And just to end on a positive note... our users that have switched from our older versions to our jasper based version have reported positive feedback with regards to performance and stability. regards On Mon, 9 Apr 2001, Greg Wilkins wrote: The Jetty project is in need of a Jasper maintainer for it's cut of the Jasper JSP engine. Jetty is a opensource java HTTP server and servlet container (see http://jetty.mortbay.com or http://sourceforge.net/projects/jetty) It is intended to be small, fast, yet fully functional. For JSP handling, we have taken a branch of the jasper code. The branch was required as we need to decouple the logging and XML parsing from tomcat. However, this branch is now a little bit of an orphan and requires a maintainer to : + Keep it
Re: SimpleSessionStore: NullPointerException
Bojan,
This sounds like the same error I ran into a couple of
weeks ago. Do you have SessionIdGenerator enabled in
your server.xml file? Unfortunately, if you don't the
default behavior is to barf because it (the sid
generator) never gets started and so the first time a
jsp page or servlet tries to getSession(), a null
pointer exception occurs. We need to figure out some
way to have a default sid generator get instantiated
in the absence of an explicit server.xml entry (or at
least a decent error message).
Mel
--- Bojan Smojver [EMAIL PROTECTED] wrote:
I'm not sure if this is something I'm doing...
Anyway, latest Tomcat 3.3
from CVS gives me this:
2001-04-10 20:23:06 - JspFactoryImpl: Exception
initializing page
context - java.lang.NullPointerException
at
java.util.Hashtable.remove(Hashtable.java:421)
at
org.apache.tomcat.modules.session.SimpleSessionStore$SimpleSessionManager.removeSession(SimpleSessionStore.java:329)
Basically, session remove around line 319 (don't
worry about 421, I've
been mucking around with it) attempts to stuff a
null into
sessions.remove and Hashtable goes nuts...
I've changed the code of the method to this:
if(session != null){
String sessionId=session.getId().toString();
if(sessionId != null)
sessions.remove(sessionId);
recycled.put(session);
session.setValid(false);
session.recycle();
// session.removeAllAttributes();
}
but that doesn't work either (although it avoids the
null problem). The
code from AccessInterceptor, class
FormSecurityCheckHandler, method
doService, reports 'Form login without a session'
(by the way this is
misspelt in the source, it says: 'From login without
a session') because
the session is null (actually the URL gets appended
with jsessionid=null
when I hit the login form).
The behaviour seems to be there even if cookies are
enabled.
Any ideas there?
Bojan
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
--- [EMAIL PROTECTED] wrote: The "toolkit" idea is perfect for what we need, and preferably with as little coupling/dependencies as possible between components. That's the goal! For a "cooperating" container only the Jsp parser and generator ( and the runtime ) are relevant, all other packages are services to be used in JspServlet or to change the behavior. Having a "jaser.core" that acts as a repository for jasper modules ( or JasperToolkit if it's only a class) is a good idea too. One important thing is to make sure the "runtime" services are clearly separated from the "compile" services. The way I want it to work is for the base JasperToolkit to only provide services common or potentially used by all adapter implementations. Then, an adapter implementation can use a specific subclass that provides any additional services specific to that implementation. Since this would be an adapter-savvy toolkit, it can use runtime smarts apropriate for that adapter. Now, it is possible that the core toolkit will include factory methods for services not used by a particular implementation. That's okay. The penalty for class-loading is only the interface classes used as return types by the factory methods since the implementation classes are only loaded when the factory methods actually get invoked. That keeps the toolkit pretty lightweight even if it has a few extra unneeded factories. That said, as soon as I get this posted, I'll be wide open to suggestions on better partitioning of services or adding ones I've missed. Maybe multiple base toolkits will be appropriate instead of one. For example, the one I'm designing is concerned with supporting the runtime adapter implementations. It might make sense to have a separate factory for generating the many classes used by the JSP parser itself. If so, maybe my current 'JasperToolkit' should instead be named 'AdapterToolkit', reserving the former name for the parser/compiler toolkit? This will be a good discussion to have. Well, I'm going to get back to work on it. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
I tried to respond to this earlier today, but aparently my mail message got zapped into the netherworld. --- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: On Tue, 10 Apr 2001, Mel Martinez wrote: I am writing the jasper34 refactoring proposal. I am late on getting it checked in because I have been distracted by other issues (job hunting, for one). I am nearly ready to submit it though. It is currently in the form of a UML class model generated with Together. I will submit it in html form inside the tomcat 3.3 proposals directory for review. Mel, could you bring me up to date on a couple of issues regarding this proposed proposal :-)? * Are you planning on supporting the new JSP 1.2 features? If not, this isn't going to be of much use for Tomcat 4.0. The toolkit refactoring strategy is agnostic as to JSP 1.2 or 1.1 features. That is the point. This model should make it EASIER to replace existing features and behavior with new implementations. Thus, while not aimed specifically at providing JSP 1.2 features, this should help get there. * Are you planning on maintaining compatibility with JDK 1.1? I don't personally like the idea of Tomcat 4.0's JSP environment being constrained by this -- either in the internal code of Jasper itself, or in the generated code for the servlet associated with each page. One of the benefits of the Abstract Factory pattern is to remove dependencies on particular language version or platform dependencies. The toolkit itself must be written to be compatible with jdk1.1, as required for tomcat 3.x. However, any given *implementation* of a service provided by the toolkit can ignore jdk1.1 and use nothing but the latest and greatest Java language features. Such an implementation could even be used on tomcat 3.3 - but in that case, the factory method that instantiates that service needs to be prepared to supply an alternative in the jdk1.1 case. Since it is likely a tc4 version of this will use a specific subclass of the toolkit to add new services, it can just ignore this issue. For overriding existing services with new implementations, that is done simply by setting a config property so again, tc4 would not have to concern itself with backward compatibility at all. The whole thing is analogous to the way AWT and JFC factories work, except this is much smaller and simpler. :-) I hope this is helpful. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: [STATUS] Tomcat 3.2.2
Mark, Re: the problem with the fact that some jdk1.2.2 implementations may have the bug and others may not. Could you possibly put a preamble in a static initializer that explicitely tests the URL decoding of some static strings? If the bug occurs, set a (static final) flag? That would give you a simple (static final) boolean test on whether to double the decoding or not, which would be about as minimal a runtime performance hit as you could hope for. Just a wild thought from left field. Mel --- Marc Saegesser [EMAIL PROTECTED] wrote: As usual, the problem turned out to be deeper then I first expected. Here's what happened. There was a bug in 3.2.1 that servlet paths and path info weren't being decoded as required by the spec. This was fixed in 3.2.2. It also turns out that there was bug in JDK1.2.2 that caused %HH escape characters in file: URLs to not be decoded. I originally thought the bug was in 1.3.0, but after re-reading the URL spec I accept that the bug was really in 1.2.2. The bottom line is that the behavior of file URLs is different on different versions of Java. Context.getResource() constructs a file: URL by concatenating the context root with the servlet path. On JDK1.3.0 systems, this now results in the servlet path getting decoded twice: once in RequestUtil and once by URL. Decoding URLs more than once causes all kinds of security problems. So, given that file: URLs behave differently on different system, we have to adjust the input to the URL constructor in Context.getResource() so that the file names passed in on systems without the bug have been URL encoded so that the URL can then decode them and get the correct file name. So now the question becomes determining if the system has the file: URL bug. I don't think you can just look at the version number because not every vendor's 1.2.2 implementation may be broken and every vendor's 1.3.x implementation may not be fixed. So it comes down to checking the behavior of URL to see what flavor you have. I've tried all kinds of combinations of toString(), toExternalForm(), sameFile(), etc. and so far the only reliable method I have for determining which version of URL you have is to actually use it to open an InputStream and see if it works. For example a simple routine could try to open file:%2e (i.e. the current directory). If it gets a FileNotFoundException then it assumes that it has a broken URL implementation, if it doesn't get an exception then it assumes that the URL implementation is correct. Context.getResource() can now check if the URL implementation is broken or not and do the right thing. This fixes the security hole, but opens up a new kind of attack. A malicious user on a JDK1.2.2 server could create a file called %2e in Tomcat's working directory. This would cause Tomcat to not find resources that it legitimately should find. This better than exposing the entire server to prying eyes, but it still doesn't feel right. I'm going to commit the fix as I have it now so that others can review it and maybe come up with a better approach. I'm now planning to release beta 3 Saturday morning (central US time). -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Friday, April 06, 2001 11:29 AM To: [EMAIL PROTECTED] Subject: [STATUS] Tomcat 3.2.2 I've got a fix for the URL double decode security problem in Tomcat 3.2.2. I'm going to release Tomcat 3.2.2 beta 3 tonight to make this fix publicly available. Because the only change in Beta 3 is the security fix, this beta cycle will only be one week long. If no other security issues are found, I'll call a vote for 3.2.2 final late next week. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Nick Bauman [EMAIL PROTECTED] wrote: Read Jon's article about the problems of JSP. http://jakarta.apache.org/velocity/ymtd/ymtd.html I read it and it made me rethink a lot of assumptions I had made about JSP. Without getting into the larger debate - actually agree with many of the article's issues - the following paragraph, though, bothers me: --- There are some fundamental issues that are being dealt with in the generated .jsp template. The first one is the class name. What happens is that the engine needs to produce a name that is unique in order to work around class loader issues that might crop up. Therefore, each and every time one modifies a .jsp page, a new file is created on disk in the temporary directory. Unfortunately, this directory ends up growing in size until someone decides to clean it up. The engine could probably do this for you, except then it might make the mistake of actually removing the wrong file. [from http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html ] The above paragraph describes a 'fundamental issue' that has absolutely nothing to do with the Java Server Pages specification and, rather, entirely to do with a particular implementation of the specification. As such, it has no legitimate argumentative value here and seems quite gratuitous. The statement 'The engine could probably do this for you, except then it might make the mistake of actually REMOVING THE WRONG FILE.' (emphasis mine) is a blatant appeal to fear. I highly doubt this was intentional on Jon's part, but that is what it is. Jon - you do not need to do this to support your arguments. Please retract this paragraph from the essay when convenient. Also, in your discussion on error handling, the fact that JSP's only catch Exceptions will be changed in JSP 1.2 spec to include all Throwables. And further, it could be argued that many of your complaints about poor compilation error messages are again, an artifact of implementation (maturity), rather than specification. However, I (were I to argue such) would have to concede that in that case the specification is possibly incomplete (failure to address standardizing the compile/debug part of the cycle). All-in-all, though, I won't argue with the basic point: Java Server Pages do NOT provide a tool-level separation between View and Control. And I wish others would stop pretending that it did. With my team, I try to stress that JSPs can (and actually should) be used to implement both View and Control aspects of MVC and to address this we have adopted (hopefully) strong standards for how we do JSP development. There is more to it, but basically we conceptually separate JSPs into four basic roles: presentation control, presentation content, request filtering and pure business. We then enforce naming conventions and required strategies to development of JSPs in these roles. I don't claim this is ideal, but it seems to work very well. I am interested in template solutions like Velocity, though and intend to look at it closely. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Nick Bauman [EMAIL PROTECTED] wrote: Read Jon's article about the problems of JSP. http://jakarta.apache.org/velocity/ymtd/ymtd.html I read it and it made me rethink a lot of assumptions I had made about JSP. Without getting into the larger debate - actually agree with many of the article's issues - the following paragraph, though, bothers me: --- There are some fundamental issues that are being dealt with in the generated .jsp template. The first one is the class name. What happens is that the engine needs to produce a name that is unique in order to work around class loader issues that might crop up. Therefore, each and every time one modifies a .jsp page, a new file is created on disk in the temporary directory. Unfortunately, this directory ends up growing in size until someone decides to clean it up. The engine could probably do this for you, except then it might make the mistake of actually removing the wrong file. [from http://jakarta.apache.org/velocity/ymtd/ymtd-generation.html ] The above paragraph describes a 'fundamental issue' that has absolutely nothing to do with the Java Server Pages specification and, rather, entirely to do with a particular implementation of the specification. As such, it has no legitimate argumentative value here and seems quite gratuitous. The statement 'The engine could probably do this for you, except then it might make the mistake of actually REMOVING THE WRONG FILE.' (emphasis mine) is a blatant appeal to fear. I highly doubt this was intentional on Jon's part, but that is what it is. Jon - you do not need to do this to support your arguments. Please retract this paragraph from the essay when convenient. Also, in your discussion on error handling, the fact that JSP's only catch Exceptions will be changed in JSP 1.2 spec to include all Throwables. And further, it could be argued that many of your complaints about poor compilation error messages are again, an artifact of implementation (maturity), rather than specification. However, I (were I to argue such) would have to concede that in that case the specification is possibly incomplete (failure to address standardizing the compile/debug part of the cycle). All-in-all, though, I won't argue with the basic point: Java Server Pages do NOT provide a tool-level separation between View and Control. And I wish others would stop pretending that it did. With my team, I try to stress that JSPs can (and actually should) be used to implement both View and Control aspects of MVC and to address this we have adopted (hopefully) strong standards for how we do JSP development. There is more to it, but basically we conceptually separate JSPs into four basic roles: presentation control, presentation content, request filtering and pure business. We then enforce naming conventions and required strategies to development of JSPs in these roles. I don't claim this is ideal, but it seems to work very well. I am interested in template solutions like Velocity, though and intend to look at it closely. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: 'Just say no to JSP' Re: [Fwd: Tomcat may reveal script source code by URL trickery]
--- Jon Stevens [EMAIL PROTECTED] wrote: Mel, Please do not CC me directly as I'm already on the list. Sorry - artifact of how I started the reply (from browsing the essay). Oops. I have filed your changes away for when I do my next revision of the site (there are several other people's comments that I want to integrate as well). I hear you and you made good suggestions. Also, I do have to say that those two nits are fairly minor given that the scope of the entire article is quite large. In other words, there is plenty of other valid reasons there to not use JSP and that those two nits are really minor in the grand scope of things. :-) Oh yes, I hope I made it clear that I don't think my two little nits in any way invalidate the larger points. I am simply offering them as constructive ways to improve the argument. Cheers, Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Jasper34 refactoring proposal status
Hi folks, First, I want to apologize for how long it has taken me to get this proposal done. There have been external factors beyond my control, but requiring my time (more on that below). The good news, is that it is almost done. Also, the level of detail should lend itself to rapid implementation (by doing the high-level design in Together, many of the classes are already coded and at least stubbed). Also, it should be possible to develop this completely in parallel with no impact on the current JspServlet. Also, I should shortly have lotsa time to devote to this. The bad news is that the external factors are that my company's equivalent of Daddy Warbucks (our funding source) has gotten cold feet and I am about to become a statistic of the fall of the dot-com economy. :-| Hence the sudden 'free time'... Should any of you know of an opening for a senior java developer/architect/CTO/director of development type-person, feel free to contact me and I'll be glad to share my resume'. My preference is for product development and I have a high interest in building development tools/frameworks and distributed architectures, but I'd love to hear about any interesting opportunity. We currently live in Baltimore, MD, but would consider relocating for the right opportunity. Also, if anybody can point me towards sites with info and help on being an independent contractor, I'd appreciate the tips. Okay, sorry about the off-topic - I realize this stuff better belongs on a Job-posting board. I'll get back to the UML diagrams now. :-) mel Dr. Mel Martinez [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: I have got a query regarding PrintWriter,
--- Anil [EMAIL PROTECTED] wrote:
I have been trying to intercept all the System.out
and System.err request
given in the tomcat. Here is the excerpts of the
Code.
I wrote a class WSPrintStream that extends
PrintStream and overided the
commonly used println(..) statements.
[definition of WSPrintStream trimmed except
to note that it is implemented by overriding
each println() method to fire a PropertyChangeEvent.]
now before the execution of tomcat server I added
this code
oldSystem_out = System.out;
WSPrintStream wsp = new
WSPrintStream(System.out);
System.setOut(wsp);
wsp.addPropertyChangeListener(this);
Now I can catch all the println statements in the
public void
propertyChange(
java.beans.PropertyChangeEvent evt){
when ever the System.out.println() is used in
the
System
But,,
This is a problem I encountered
If I use
java.io.PrintStream pw = new
java.io.PrintStream(System.out);
pw.println("helo try reading this");
Umm... just curious, but why not use
System.out.println("helo...");
instead of wrapping it here? Since (according
to your use of System.setOut(), then the following
should
be true:
System.out instanceof WSPrintStream
and System.out.println() - WSPrintStream.println()
this is not the real, problem though (see below).
I am not able to catch the message from going to the
default out put
stream.
i.e my WSPrintStream does not get invoked.
Your WSPrintStream subclass needs to override the
write(byte b) method. When you wrap one OutputStream
around another, the data is passed from one stream to
another through the OutputStream write() method.
The println() method is not part of OutputStream
interface
and so as far as the wrapping PrintStream object is
concerned they (your println methods) do not exist.
I hope this helps.
Cheers,
Dr. Mel Martinez
G1440, Inc.
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
Re: Tomcat 4.0-beta-2 Security Vulnerability
--- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: I suggest that we create a revised version of beta 2, clearly labelled so that people will know whether they have the corrected version or not -- and we should do this immediately (like today) to minimize the number of people who end up downloading twice. I suggest we call the updated version "Tomcat 4.0-beta-2-update-1" or something like that. Comments? Votes? I vote you just call it "Tomcat-4.0-beta-3". I don't recall ever being told there were limits to the number of betas one can produce. :-) I believe that a new beta number is justified by any significant bug fix or fixes and a security hole is definitely significant, even if the code change may be tiny. By labeling it 'beta-3' it is CLEARLY the latest build and CLEARLY newer than beta-2. fwiw, Dr. Mel Martinez G1440, Inc. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
Re: CGI support servlet (TC 4) -- feedback wanted
--- Bip Thelin [EMAIL PROTECTED] wrote: "Craig R. McClanahan" wrote: 2) Addition to default context Would this CGI servlet be added to the default context similar to SsiInvokerServlet? Yes. I would suggest that we do this, but leave it commented out. The reason is that the potential for mischief is *much* larger when we are talking about executing outside programs instead of just displaying content back to a web browser. I vote for making the Tomcat sysadmin have to enable this feature explicitly if they want it. Once we implement the #exec functionality in SSI, the same argument would apply here -- unless we added a config option to disable the #exec by default but left everything else alone. +1 on having CGI in web.xml but commented out, regarding SSI I suggest we add a configure property(like Apaches NoExec) that set's whether #exec is allowed or not. And if that property is not set it defaults to NoExec. So for a standard setup SSI would be allowed but you'd have to bug your Tomcat sysadmin to have the #exec option enabled. Sort of like a standard Apache setup. ..bip +1 on what Bip said. mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
--- Steve Downey [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
On Thu, 29 Mar 2001, Mel Martinez wrote:
activities that should be orthogonal. The only
dependency should be that the Compiler is a
consumer
of the products of the Mangler.
+1
If we treat the embedded implementation of Mangler
as a separate class,
which I think is a good idea, each style of JSP
compilation works with a
triad of somewhat dependant classes. An X-Compiler,
an X-Context and an
X-Mangler. If we're playing games with the name of
the generated class, like
decorating it with a version number, then some other
part of the system
needs to understand the Mangling scheme as well.
ClassName does some of this
work now, finding out what the 'real' name of the
class is.
Perhaps a Kit pattern is in order?
Ah yes, the venerable ToolKit!
This is basically what I'm going for, with two tiers:
- a static, default layer of factory methods that is
independent of the runtime adaptor scheme. This is
done via factories in a subclass of Constants. This
layer has default behavior that is configurable via
standard configuration properties (both via -D and via
resource file).
- a run-time layer of factory methods that overrides
the default layer based on run-time options such as
init-params. This is to be implemented in a subclass
of Options.
This pattern allows each adapter (i.e. JspC,
JspInterceptor) to adopt just the shared behavior that
is necessary by extending/re-implementing it's own
'options'-layer factories.
I must admit to not being totally sure whether
co-opting the current 'Constants' and 'Options' class
families is the best naming for this, but they do
clearly indicate the difference in scope. I could
break the factory methods out into separate, new
'ConstantsToolkit' and 'OptionsToolkit'
class/interface types, but since they would parallel
the original, I don't see the real advantage.
Refactoring Mangler is highly desireable from my day
job point of view, too,
since the current mangling scheme can cause problems
on Windows. Although we
might be able to move to Linux for developers
desktops soon.
I ran into that some time back (mangling issues) and
was one of my motivations for doing this refactoring
earlier in my day-job implementation of JspServlet
(tc3.3). The result of that effort works very well
and I'm borrowing heavily from it for this effort, but
this time I'm trying to put more support for (and
steal ideas from) other adapter options.
to be thorough, I took our worst behaved JSP page,
which happens to be our
home page, and benchmarked it under several engines.
TC33 blew the doors off
the competition, up to levels of 177 concurrent
connections, at which point
the benchmark tool starting melting down.]
That is always good stuff to hear! Costin deserves a
lot of the credit here, since that performance gain is
primarily (probably) coming from his JspInterceptor
implementation. I know we can never get JspServlet to
be completely as fast, but we should be able to get it
much closer than it currently is.
But in any case, should be independent of
everything
else - just a component that may be used by the
"container adapter" classes.
Costin
DIP, the dependencies should be on interfaces, not
on classes.
90% of the time I agree. Some abstractions require
base or abstract classes, though, if part of the
specification fixes actual behavior. This is often
the case when initialization must follow a fixed
pattern (i.e. a certain type of constructor signature
or other life-cycle methods must be supported).
This can sometimes be avoided if the interface is
well-thought out. For example, the problem with the
current Mangler interface is that it does not support
any way to input the core parameters (the jsp URI and
the scratchdir) from which it's method must derive
their data. In other words, we want a factory method
that works like so:
publc static Mangler createMangler(
String uri,String dir){..}
but we need a predictable way to communicate the
params to the created instance. There are three ways
to fix this in order to support abstract creation
through factory methods.
1) rewrite the Mangler interface to have an
init(String,String) method or 'setJspUri(String)' and
'setOutputDir(String)' methods - this would be
optimal, but would break existing implementations of
Mangler.
2) create a default basic or abstract implementation
of Mangler (call it 'JspMangler' or whatever) and give
it a public constructor that takes the params. The
factory method then becomes:
public static JspMangler createJspMangler(
String, String){...}
The problem with this one is that it forces all new
Mangler implementations to subclass JspMangler. This
is not necessarily a bad thing.
3) create a new interface called JspMangler (or
whatever) and adding the missing initializat
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Wow! I go away for a day and there is some great discussion on this thread! I've saved everybody's comments and will incorporate them into the proposal, which I will be working on tonight to formalize. When I've got it ready for review, I will put a proposal doc and any related files in html form into .../jakarta-tomcat/proposals/tomcat33/ From the discussion I think it is safe to say that the goals of this refactoring are: 1) focused primarily with cleaning up the object model of the org.apache.jasper.servlet package (i.e. JspServlet) so that we can reduce coupling between JspServlet and the core of Jasper. 2) we will try to increase separation between the JspServlet entry point into jasper from the various life-cycle services (class loading, mangling, compiling, etc) to make those services both replaceable for JspServlet and also reusable for alternate entry points, such as JspC or JspInterceptor. 3) we will try to clarify classpath and init-params configuration issues. 4) despite all this, we will strive to improve performance by reducing the call stack and by utilizing caching where possible. 5) fix more bugs than we introduce. I should have a first-draft class diagram and probably initial java code ready for the proposal tonight or early tomorrow. I tentatively propose to introduce the changes through the package name 'org.apache.jasper.servlet33', unless anyone objects AND has a better package name. :-) Cheers, Dr. Mel Martinez G1440, Inc. --- Steve Downey [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 3:46 PM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet On Wed, 28 Mar 2001, Steve Downey wrote: The second most common cause of bugs in Jasper is confusion over when to use File.separator and when to use '/'. It's hard to keep track of, since Jasper does deal with both files and URIs. And the File methods are used to regularize some URIs. Another reason to refactor. I would say this is also part of interfacing the jasper with the container, and not core to the jsp parser and jsp-java convertor ( which in my opinion represents the "core" of jasper ). There is the problem of importing jsps ( and few other cases where files are needed), but again that's related with the API that is needed to plug jasper into a ( cooperating ) container. SNIP ... importing jsp text, determining the file to write java to, finding tag library descriptors, finding the directory to direct the java compiler to write class files to... Files are inherent, at least as long as javac insists on having files. I would love to be able to compile a stream, or array of streams, but that's not happening near term. Almost everything else uses URI's to refer to things. So, for the most part, jasper should not be looking at, or using, files. Streams, yes, as in getResourceAsStream, but mostly not Files. Most current uses of File are wrong, and other parts of Jasper try to compensate. Actually, I don't think that importing needs Files. It should be able to use getResourceAsStream. That may need to work with Files, but that's something that the container deals with, not Jasper. 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. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
I acknowledge your suggestion and am going to put it in org.apache.jasper34.* That symbolically combines 3 and 4 while deferring more towards an incremental change from 3.3, which is the main focus. I think your other points are well put and that (commonality with tc4.0 jasper) will be a motivator and influence, but the primary goal should and will be to simply improve what is in tc3.3 jasper. Cheers, mel --- [EMAIL PROTECTED] wrote: Mel, Regarding the names and the scope of the changes. If we are going to do some refactoring ( and that's going to require work and testing anyway), then we should do it on a slightly broader scope, not only local to the servlet interface. Instead of org.apache.jasper.servlet33, I would suggest something like org.apache.jasperX.*, and have separate packages for the different components that we identify ( see my proposal for 5 components - some of them like the java-class compiler or even the mangler are general-purpose for any scripting system and could even be part of the an util package ). What would be really great is to coordinate this with someone on jasper4.0 side - we should be able to share most components, except probably few classes in the JSP generator ( and of course the runtime - which implements security and is heavily dependent on jsp1.2 ). Most of the parser and generator is identical, and I think we would all benefit by sharing as much as is possible. In other words - it would be great to try to make this proposal not limited to jasper33 servlet, but a jasper7.3 ( 4.0 + 3.3 ) proposal, refactoring and combining the 2 ( now divergent ) versions ( while keeping and increasing the ability to have alternative implementations for all components - like the runtime and some of the generator ). Of course, it's your choice - I will support a limited refactoring if that's what you want, but I think we should at least try to combine our efforts and re-unite ( at least ) jasper. Then all the optimizations ( like tag pooling ) and fixes and the sandboxing will be common for most part, with clear container-specific modules ( that would also prove and show how other containers can use jasper ), Costin On Wed, 28 Mar 2001, Mel Martinez wrote: Wow! I go away for a day and there is some great discussion on this thread! I've saved everybody's comments and will incorporate them into the proposal, which I will be working on tonight to formalize. When I've got it ready for review, I will put a proposal doc and any related files in html form into .../jakarta-tomcat/proposals/tomcat33/ From the discussion I think it is safe to say that the goals of this refactoring are: 1) focused primarily with cleaning up the object model of the org.apache.jasper.servlet package (i.e. JspServlet) so that we can reduce coupling between JspServlet and the core of Jasper. 2) we will try to increase separation between the JspServlet entry point into jasper from the various life-cycle services (class loading, mangling, compiling, etc) to make those services both replaceable for JspServlet and also reusable for alternate entry points, such as JspC or JspInterceptor. 3) we will try to clarify classpath and init-params configuration issues. 4) despite all this, we will strive to improve performance by reducing the call stack and by utilizing caching where possible. 5) fix more bugs than we introduce. I should have a first-draft class diagram and probably initial java code ready for the proposal tonight or early tomorrow. I tentatively propose to introduce the changes through the package name 'org.apache.jasper.servlet33', unless anyone objects AND has a better package name. :-) Cheers, Dr. Mel Martinez G1440, Inc. --- Steve Downey [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 3:46 PM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet On Wed, 28 Mar 2001, Steve Downey wrote: The second most common cause of bugs in Jasper is confusion over when to use File.separator and when to use '/'. It's hard to keep track of, since Jasper does deal with both files and URIs. And the File methods are used to regularize some URIs. Another reason to refactor. I would say this is also part of interfacing the jasper with the container, and not core to the jsp parser and jsp-java convertor ( which in my opinion represents the "core" of jasper ). There is the problem of importing jsps ( and few other cases where files are needed), but again that's related with the API that is needed to plug
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
--- Steve Downey [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 1:08 PM To: [EMAIL PROTECTED] Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet Hi Mel, In my view, jasper is composed from at least 5 big components: 1. The jsp-java translator. 2. The java-class compiler 3. The Mangler ( managing name mappings ) 4. Runtime - that should be completely independent of all other pieces, since jasper-generated servlets should run without jasper ( as simple servlets ) 5. Interface with the serlvet container ( JspServlet, JspInterceptor and the associated classes). ( putting all other components togheter ) Layer 5 has to include the JspC/CommandLineXXX components, also. They have to provide an environment that looks to the rest of the JSP compiler like a web context, while actually interacting more closely with the filesystem. I'm not going to make it a primary goal to fix JspC, but I should be able to make the components reusable so that a new version of JspC could be refactored to use the same classes as this new version of JspServlet. Mangler needs some work, too. JspC and JspServlet have drifted in their implementations. The bane of code sharing by cut and paste. I will try to address this as well. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
--- Glenn Nielsen [EMAIL PROTECTED] wrote: I have made some changes to the Jasper code in Tomcat 4 that you might want to look at. I will definitely be looking at TC 4. 1. In general the Java SecurityManager implemenation in Tomcat 4 and Jasper has significant improvements and is much cleaner. I copied some of this in my current implementation. Shoudn't be too hard to keep it in when I port. 2. Jasper class loading is much simpler in the Tomcat 4 version. It uses a single URLClassLoader for each JSP page, this allowed me to simplify a great deal how Jasper handles generation of class and package names (no more need to do incremental .java and .class files). And it removed alot of overhead at both JSP translation and runtime when Jasper tries to figure out which incremental class file to use/check. This sped up JSP compiles by 33% and runtime execution by 25%. The refactoring I propose would indeed use one class-loader per page. My current implementation does this leveraging a subclass of JasperLoader but I'll explore using URLClassLoader. I would need to make sure that it is compatible with jdk1.1 (a tc3.3 requirement) so if I used URLClassLoader, I'd need to provide a jdk1.1 replacement ala the way tomcat startup does. This actually should be pretty easy since I'm getting the loader via a factory method. And before you ask, I just don't have the time to back port these changes in TC3.3. Don't worry - I totally understand this! :-) mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
--- [EMAIL PROTECTED] wrote: However, this does point to the need for default behavior of tomcat session generation code (or any interceptor or module code) in the absence of expected configuration info in server.xml. That's a good point, but I'm wondering how could it be implemented. The whole idea of modules is that each can be replaced with a better version ( for example a more secure or more efficient scheme to generate the ids ), so we can't just check for specific modules. Well, there is a solution ( I'm not sure how can we code it ) - have an automated way to run watchdog and sanity to validate the config files. If watchdog/sanity are passing - then probably the config is valid :-) I'm not sure exactly the best way to do it here, since I have not had the time to follow all the code involved with session management. However, I do know that request.getSession() is a fundamental method of the API that should NOT crash just because the deployer has not specified a configuration option. The implementation of a specification should ALWAYS supply a default behavior that either works gracefully with default options OR fails gracefully while informing the deployment engineer or developer about the missing/incorrect configuration settings. If SimpleSessionManager/ServletSession can not work with a 'null' value for the Session ID, then it needs to fail gracefully or it needs to supply a default id generator. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
--- [EMAIL PROTECTED] wrote: 1) I don't off-hand know of any other generalized way to make a portable JSP compiler that can be plugged into any servlet 2.2 engine other than as a servlet. I'm not sure how that limits us feature-wise, other than the fact that it adds a layer of indirection between the request on the container and the actual ultimate jsp servlet. A small performance price to pay for portability. The only problem is that the price is much higher that that: - JspServlet must manage the servlet lifecycle - the container can no longer treat jsp-generate-servlets the same as regular servlets This is a limitation of the servlet api and thus the lack of access to a consistent set of servlet engine features necessary for full servlet life-cycle management that can be relied upon. Besides, who said that the container was guaranteed full-lifecycle management of ANY servlet? Any servlet could be created/loaded dynamically and managed by some other servlet without the container ever knowing about it (assuming the SecurityManager allowed it, of course :-). - initialization - how can you pass init parameters to the jsp ? This is one of the worst hacks and source of counteless problems ( AFAIK - I couldn't find any clean way to do that ) How exactly do you solve this with JspInterceptor? The specification doesn't really seem to cover init-params for individual JSP pages. The JSP container has no responsibility to provide individualized init-params for JSP servlets, only to invoke jspInit() prior to service(). In the absence of a specified mechanism, it is the responsibility of the JSP page author to initialize his page by implementing the jspInit() method (from which he/she can optionally load params from whereever he/she sees fit). In other words, this is not a limitation of JspServlet, but rather a limitation of the JSP specification. - class loader problems - again, the JspServlet must duplicate and override the class loading decisions of the container - other problems and issues This, again is more a limitation (or too much freedom) in how servlet containers are implemented. My point is that the servlet abstraction may not provide enough API support for what jasper need - in order to make it work you have to duplicate services that should be ofered by containers ( class loading, init, reloading, admin, etc ). The glass is half-full as well - because at least with the servlet api it is _possible_ to implement those services portably and thus provide a portable JSP compiler. And yes, it would be great if the JspServlet didn't have to implement redundant container services, that in no way really limits JspServlet's ability to fullfill all JSP specification features. And again - what is the alternative? I can't write a JspInterceptor solution for WebLogic or JRun. I don't want to discourage you from doing that - any refactoring will help and we badly need that. I just want to give you an alternate view, based on my experience - before you repeat mistakes we've already done :-) The mistakes aren't in using a servlet-based approach. This sort of feature (a plug-in to provid jsp compilation and loading services to a web server) is exactly what servlets are for. This in itself in no way limits what you can do with JSPs because all features of the JSP spec should be attainable through a servlet implementation. This DOES limit the reliance Jasper can have on value-added container features beyond the servlet API, but hey, you have to draw the line somewhere. The way to look at it is that a JspInterceptor-style solution is a value-added feature of the tomcat servlet engine. That is a positive. The portability of JspServlet is also a positive. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text
TC3.3 Proposal: Refactoring org.apache.jasper.servlet
As hinted at last week, I'd like to propose refactoring some of the classes in Jasper to improve the OO model a bit, make maintenance/extendability a bit easier and hopefully help the performance a bit as well for those of us using jasper as the JSP engine in other servlet engines (other than tomcat, that is). There are problems with using the current Jasper in other ServletEngines that do not show up with the tomcat JspIntercepter that need to be addressed. I'd like to refactor JspServlet, JspServletWrapper, JasperLoader, JasperEngineContext and JasperCompiler to better divide responsibilities along the following lines: JspServlet - entry point for JSP page (*.jsp), initialize Jasper and maintain cache of jsp servlet wrapper/handlers, otherwise do very little but pass on the request to the handler. I.E. represents the scope of the jasper engine. Possibly rename this to JasperServlet or just 'Jasper'. JspServletWrapper - rename as 'JspServlet/PageHandler' (or similar) and make this a full class (i.e. take it out of JspServlet). This class manages the life cycle of a single Jsp file, including methods to resolve relevant file paths (i.e. to .jsp file, .java file, .class file), package/class name mangling and modification checking. This class would be responsible for managing dynamic reloading of an out-of-date page. Only one instance of this class is created per page for the life JVM (or more accurately, for the life of the JspServlet). JspRequestWrapper/Handler/Context - encapsulate information relevant to one request - this would implement JspCompilationContext, since a compilation would be one possible event during the request. However, we'd remove some of the current behavior in JasperEngineContext that is really page-lifecycle behavior that belongs in the JspServlet/PageHandler. This class should be a lightweight information payload used by the page handler, loader and compiler for fullfillment of the request. By reducing the number of fields to only those that are request-specific and possibly by object pooling, the impact of instance creation (necessary for each request) can be greatly reduced. JasperLoader, Compiler, and a few other classes would be refactored (actually simply extended slightly through subclassing) to support these mods. Some of the current behavior would be refactored out to the page life-cycle handler. Compilers can probably be pooled for reuse. Along with the above class refactoring, we would add recursive modification checking and dynamic reloading to JspServlet, miscelaneous bug and performance fixes (ex: mangled filename caching), and factory methods to make it easier to modify behavior by pluging in replacement classes (such as the name mangler, loader and compiler). I'd like to improve the way classpaths are handled to make things more apparent to the developer using Jasper standalone how to set things up. The beauty of this is that this can all be done without rewriting much if any of the existing code in TC3.3. We can simply create a separate implementation of JspServlet, called 'Jasper' (or JasperServlet or whatever) or place the changes in a separate package and thus folks working with the current version would not be impacted by API changes. We can then deprecate the current classes gradually. It is imporant to note that this proposed refactoring would be to the standalone JspServlet page and request life-cycle management. This does not address any possibly needed refactoring of the actual Jasper compiler, which will remain the common element used by all three entry points: JspInterceptor, the current JspServlet and the proposed new jsp servlet. Maintaining runtime compatibility with JspInterceptor is, of course, mandatory. No changes should cause JspInterceptor to break. Maintaining consistency with JspInterceptor in terms of how it might do some ancillary things (name mangling, caching optimizations, classpath resolution etc.) should also be desired, but not required since, after all, JspInterceptor represents value-added for the tomcat servlet engine. To facilitate development, I can donate the bulk of this as finished code I've already written that simply needs to have appropriate package and class renaming applied. This proposal should be considered a rough draft. I need feedback, especially from others also using Jasper as standalone in other servlet engines (such as WebLogic Server, JRun, Jserv, etc.) on what problems they'd like to see solved. I'd also like suggestions on whether to put this into a separate package in Jasper (ex: org.apache.jasper.embedded) or to simply insert it into the existing org.apache.jasper.servlet package using new class names. I think I'm in favor of the latter approach. I don't think there will be much conflict or confusion with the approach I'd like to take. That said, I will have actually some time later this week to actually implement most of this. So feedback now is better than feedback later.
RE: apache 1.3.12 and tomcat 3.3-m2 connection problem ??
--- Jestin Jean-Francois
[EMAIL PROTECTED] wrote:
here are 2 articles speaking about the pushlet
http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet.html
http://www.javaworld.com/javaworld/jw-03-2000/jw-03-pushlet-2.html
here is a very simple sample pushlet :
{
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws
ServletException, IOException {
ObjectOutputStream out = new
ObjectOutputStream (response.getOutputStream());
response.setContentType("text/plain");
String start = "Http connection opened";
out.write(start.getBytes());
out.flush();
try {
for (int cnt=1; cnt 0; cnt++) {
Thread.sleep(1000);
String iter = "event=" + cnt + "\n";
out.write(iter.getBytes());
out.flush();
System.out.println("event=" + cnt +
"pushed.\n");
}
} catch (Exception e) {
System.out.println("error:"+e);
}
out.close();
}
}
This looks like a VERY bad idea - this will lock up a
connection to the server (and possibly a web server
process)! This will definitely not scale well. Also,
it is vulnerable to server crash, something likely to
happen if you had even a moderate amount of traffic
going to 'pushlets'.
It might be best to have the browser redirected over
to a separate, dedicated pushlet server (on a separate
box) for this. I sure wouldn't want it sharing
resources with the rest of my 'normal' servlets.
NitPick: You should send error messages to System.err,
not System.out. :-)
Cheers,
mel
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SimpleSessionStore.java
--- [EMAIL PROTECTED] wrote: Temporary(?) fix to stop crashes when creating a new Session in embedded use of Jasper (i.e. as standalone JspServlet ). Problem may occur in other situations as well, I'm not sure. I looked at that and I couldn't reproduce it - are you sure you have the right configuration ( i.e. SessionIdGenerator included in server.xml ) ? No, SessionIdGenerator was not included, I have a customized server.xml because I need to test both jasper with tomcat and then jasper in weblogic (as well as other reasons). I'll update my server.xml and I predict that will fix the problem. I now see that server.xml was beeing updated in my cvs logs, but failed to account for the change in my own version. However, this does point to the need for default behavior of tomcat session generation code (or any interceptor or module code) in the absence of expected configuration info in server.xml. Mel getNewSession is calling setState( STATE_NEW ), that calls the sessionState callback that allows modules to initialize the new session object - and SessionIdGenerator is setting the id ( using whatever random). I can't understand what's wrong - my only guess is that SessionIdGenerator is not included. I didn't had too much time this weekend ( to restart the nightly tests ), but I hope to resolve those issues soon. Costin object, the .toString() method to get a string representation of the session id returns null. When getNewSession() tries to use this value as a key into the sessions hashtable, a NullPointerException is thrown. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
TC3.3 - building javadoc
Currently, when you run the build script (for TC 3.3), build.xml has 'dist' dependent on the 'javadoc' target. The 'javadoc' target compiles javadoc pages for org.apache.tomcat.core and org.apache.tomcat.modules.*. I dunno about you, but this seems insufficient for 'dist'. Shouldn't the javadoc set for distribution include all or most of the packages? Also, it would probably be useful for dev documentation purposes to have some secondary javadoc targets like javadoc.tomcat.core', 'javadoc.tomcat.util', 'javadoc.tomcat.modules', 'javadoc.jasper', etc. That way when you work on the javadocs for a package you can rapidly compile just that section. This MIGHT encourage better documenting of code than is currently happening... :-) Anybody else think this is a good (or bad) idea? Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
bug in SimpleSessionStore/ServerSession id
I posted on this earlier (last night), but the tomcat-dev list is now so slow that I don't know if it ever really made it to the list. I'm encountering a bug now in SimpleSessionStore. In the inner class (gawd I hate inner classes :-)) SimpleSessionManager's getNewSession() method, a NullPointerException is thrown when the method tries to add the new session to the 'sessions' hashtable because the newly created session ID is null. This happens because, as near as I can tell, it is never set. I'm not sure who is working on this code or why it is not getting set, but it is very reproduceable - every time I try to access any servlet it crashes! :-) My app does not depend on sessions (we use a portable, non-servlet API dependent session management system) so it would be nice if this bit of code wasn't crashing on me. In my early post, if it ever made it, I proposed altering the MessageBytes.toString() function to never return a null (I think it is very bad form for a non-null object to return a null value from it's toString()) and instead simply return "null". However, I realize now that MessageBytes is a bit special in that it has a type T_NULL and that this could have larger impact if other code relies on this. Thus, I'd leave this for someone more knowledgeable with how MessageBytes is used to make that change if at all. The only thing I can think of to do right now is to modify the getNewSession() method to check the returned String representation of the session's id to see if it is null. If so, use "null". This fixes the crash and shouldn't, I believe, cause any new problems since the dang thing is null at this point anyway. I'm going to go ahead and commit this change, if this is bad, let me know or go ahead and change it back - but if so, please fix the underlying problem. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: TC3.3 - building javadoc
In the change I propose to make (I've already done it locally and it seems to work well) we'd have the following sorts of targets: target name="dist" depends="dist.prepare,javadoc,dist.war" target name="dist.prepare" depends="main,webapps,tomcat-jars-new" target name="javadoc" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.core" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.modules" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.util" depends="main,webapps,tomcat-jars-new" target name="javadoc.jasper" depends="main,webapps,tomcat-jars-new" ... etc... target name="dist.war" depends="dist.prepare" target name="dist.nojavadoc" depends="dist.war" Thus, the changed behavior would be that when you build 'dist' you would get ALL the javadocs generated. If you want to build 'dist' with no javadocs, just use build dist.war or build dist.nojavadoc If you want to build just a subset of the javadoc (with or without any other targets), just specify the particular javadoc. target in your list of targets. build dist.war javadoc.tomcat.core At this point, the javadoc targets are somewhat exclusive - generating one wipes the index.html of the previous build, although the actual doc pages are not wiped. There are ways to address this, but not worth the effort right now. Is this cool with folks? Note - I'll try to add a separate javadoc. target for most of the major tomcat packages but not all. mel --- "Ignacio J. Ortega" [EMAIL PROTECTED] wrote: Normally i use a custom build that generates org.apache.tomcat.* javadocs instead of the normal reduced set.. I'm +1 on this change for release.. Saludos , Ignacio J. Ortega -Mensaje original- De: Mel Martinez [mailto:[EMAIL PROTECTED]] Enviado el: viernes 23 de marzo de 2001 18:44 Para: [EMAIL PROTECTED] Asunto: TC3.3 - building javadoc Currently, when you run the build script (for TC 3.3), build.xml has 'dist' dependent on the 'javadoc' target. The 'javadoc' target compiles javadoc pages for org.apache.tomcat.core and org.apache.tomcat.modules.*. I dunno about you, but this seems insufficient for 'dist'. Shouldn't the javadoc set for distribution include all or most of the packages? Also, it would probably be useful for dev documentation purposes to have some secondary javadoc targets like javadoc.tomcat.core', 'javadoc.tomcat.util', 'javadoc.tomcat.modules', 'javadoc.jasper', etc. That way when you work on the javadocs for a package you can rapidly compile just that section. This MIGHT encourage better documenting of code than is currently happening... :-) Anybody else think this is a good (or bad) idea? Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: TC3.3 - building javadoc
In the change I propose to make (I've already done it locally and it seems to work well) we'd have the following sorts of targets: target name="dist" depends="dist.prepare,javadoc,dist.war" target name="dist.prepare" depends="main,webapps,tomcat-jars-new" target name="javadoc" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.core" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.modules" depends="main,webapps,tomcat-jars-new" target name="javadoc.tomcat.util" depends="main,webapps,tomcat-jars-new" target name="javadoc.jasper" depends="main,webapps,tomcat-jars-new" ... etc... target name="dist.war" depends="dist.prepare" target name="dist.nojavadoc" depends="dist.war" Thus, the changed behavior would be that when you build 'dist' you would get ALL the javadocs generated. If you want to build 'dist' with no javadocs, just use build dist.war or build dist.nojavadoc If you want to build just a subset of the javadoc (with or without any other targets), just specify the particular javadoc. target in your list of targets. build dist.war javadoc.tomcat.core At this point, the javadoc targets are somewhat exclusive - generating one wipes the index.html of the previous build, although the actual doc pages are not wiped. There are ways to address this, but not worth the effort right now. Is this cool with folks? Note - I'll try to add a separate javadoc. target for most of the major tomcat packages but not all. mel --- "Ignacio J. Ortega" [EMAIL PROTECTED] wrote: Normally i use a custom build that generates org.apache.tomcat.* javadocs instead of the normal reduced set.. I'm +1 on this change for release.. Saludos , Ignacio J. Ortega -Mensaje original- De: Mel Martinez [mailto:[EMAIL PROTECTED]] Enviado el: viernes 23 de marzo de 2001 18:44 Para: [EMAIL PROTECTED] Asunto: TC3.3 - building javadoc Currently, when you run the build script (for TC 3.3), build.xml has 'dist' dependent on the 'javadoc' target. The 'javadoc' target compiles javadoc pages for org.apache.tomcat.core and org.apache.tomcat.modules.*. I dunno about you, but this seems insufficient for 'dist'. Shouldn't the javadoc set for distribution include all or most of the packages? Also, it would probably be useful for dev documentation purposes to have some secondary javadoc targets like javadoc.tomcat.core', 'javadoc.tomcat.util', 'javadoc.tomcat.modules', 'javadoc.jasper', etc. That way when you work on the javadocs for a package you can rapidly compile just that section. This MIGHT encourage better documenting of code than is currently happening... :-) Anybody else think this is a good (or bad) idea? Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: bug in Jasper - bad lookups to Constants.getString()
--- [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2001, Mel Martinez wrote: StringManager's getString() currently deals with the MissingResourceException by simply returning a String consisting of a warning message about not being able to find the particular key. I don't think that is correct behavior. I think it should throw the MissingResourceException or return null and that calling code should deal with it. Otherwise the Ignoring exceptions is bad. Having to handle exceptions for trivial cases is bad too. I think that in this case, the pattern is so similar to a Collections retrieval that it makes sense to use 'null' as the return value in the event the String resource is not found rather than an exception. This should have the least impact on existing client code and is consistent with most other java usage of containers. The gain is that it will now at least be _possible_ for the client code to detect that a String was not found (by simply checking for null). If the code does not do this check, in most cases all that would happen is that "null" would be displayed. In rare cases, a nullpointerexception may be thrown (if they try to invoke a String method without first checking for null). We'll have to track those down as they occur. My feeling is that this is not the biggest priority, but you are right - StringManager and the whole resource handling needs a refactoring. Go for it, if you want to do it - I'll do whatever I can to help. ( I think thread pools or jasper or the admin are in a much bigger need for fixes and cleanup ) I'll be starting to tackle tc3.3 Jasper refactoring this week with a proposal and hopefully some discussion. Next week I'll have serveral days where I can devote quite a bit of time to implementing it. I am hoping the "commons" will ease our work - this is one of the things that are used in all jakarta projects, and it would be a good thing to share it ( in which case refactoring it and merging with the best out of what other projects are doing is worth the effort ) I'm only going to put this one tweak in the StringManager.getString() and start to refactor jasper to use StringManager for now. I'll also look at putting in a short-term fix for the standalone jasper classpath problem mentioned in another thread. Small steps. mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: jasper tag handler cleanup during exceptions
--- Casey Lucas [EMAIL PROTECTED] wrote:
As I started to add some code to remove pooled tag
handlers from
the tag pool if an exception is thrown during tag
usage, I came
across an issue...
To clean up tag handlers in the case of exceptions,
I need to
know when any exception is thrown. So I figured the
best way
to do this is to catch it. :) Yet in Tomcat 3, I can
only safely catch
(and rethrow) java.lang.Exception, java.lang.Error,
and
java.lang.RuntimeException. If I simply added a
catch for
java.lang.Throwable (like I wanted to), I can't
correctly propagate
the exception under Tomcat 3.
Casey,
How about if you simply nest your try{
}catch(Throwable t){} inside the 'main' try..catch
block, do your cleanup and then throw it outwards to
be handled normally, like so:
public void _jspService(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// init jsp page stuff goes here
try {
try{
// body of JSP here ...
}catch(Throwable t){
//do tag pool cleanup here
throw t;
}
} catch (Exception e) {
out.clear();
pageContext.handlePageException(e);
} finally {
out.close();
factory.releasePageContext(pageContext);
}
}
Would that accomplish what you are trying to do? You
should be able to do this by modifying
JspParseEventListener's generateHeader() and
generateFooter() methods.
mel
I can ignore other Throwables (besides the three
types mentioned)
but that means that tag handlers will not get
removed from the pool
if a different type of exception is thrown. -- I
don't really like it.
Alternatively, would it be ok to also catch
Throwable at the bottom
of the rendered code (below the java.lang.Exception
catch) then just
wrap it in a JasperException (or maybe just
ServletException)? If so,
I can do everything with just Throwables -- same
model for Tomcat 3
and 4. Would wrapping Throwables with
JasperExceptions mess up any
error propagation from the JSP?
Thanks Jasper gurus.
-Casey
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java ParserController.java TagLibraryInfoImpl.java
--- [EMAIL PROTECTED] wrote: remm01/03/20 16:08:53 Modified: jasper/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java ParserController.java TagLibraryInfoImpl.java Log: - Jasper should run from WARs (or any other repository which provides a directory context to access it). - All Watchdog 4 tests pass (servlets, JSP, JSP-XML). - Of course, the classes and JARs are still extracted from the WAR until the compilation technology is updated (javac wants files :(( ). :-) But javac doesn't have any reason to deal with the contents of the WAR directly. JSP 'files' read out of the .war are being converted to .java files stored in the working directory (i.e. /tmp or wherever). Javac just has to deal with the latter files. It should be possible to modify Jasper to work with an unexpanded .war archive. Not necessarily trivial, but definitely possible, in principle, with no need for new javac compilation tech. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java ParserController.java TagLibraryInfoImpl.java
--- Mel Martinez [EMAIL PROTECTED] wrote: --- [EMAIL PROTECTED] wrote: - Of course, the classes and JARs are still extracted from the WAR until the compilation technology is updated (javac wants files :(( ). :-) But javac doesn't have any reason to deal with the contents of the WAR directly. JSP 'files' read out of the .war are being converted to .java files stored in the working directory (i.e. /tmp or wherever). Javac just has to deal with the latter files. Please disregard this stupid inaccuracy. 'Brain momentarily dumped the fact that the compiler might need to see inside the .war for imported classes used in the compilation of the .jsp/.java file. Sigh... Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: bug in Jasper - bad lookups to Constants.getString()
Would the following be an acceptable solution?
We change the
Constants.message(key,args,verbosityLevel) method
behavior so that if getString(key,args) throws
a missing resource exception that it logs using the
key itself as the log message. Note that this would
also require changing the getString() method to throw
the MissingResourceException instead of the Error
object that it currently throws.
Looking at this, I am not sure why an Error is being
thrown here (in Constants.getString()). If Jasper is
operating in JspServlet mode inside some other
container (i.e. WebLogic, JRun, whatever) then should
it necessarily throw an Error? According to the spec,
Errors are reserved for conditions that are so serious
that they should normally not be caught by the
application. I.E., they should bring the JVM down.
The fact that Jasper (a servlet) is unable to find a
String in it's resource file sounds more like enough
error to throw a RuntimeException or even a
ServletException, but not an Error. That would allow
the containing ServletEngine to handl the error to
Jasper without bringing down other servlets - without
having to catch 'Error'.
I think the right way to handle this is to change the
getString() to just throw the
MissingResourceException. This requires no change to
the interfaces.
Then in org.apache.jasper.Constants change message()
to:
public static final void message(
String key,
Object[] args,
int
verbosityLevel){
if (jasperLog == null)
jasperLog = Log.getLog("JASPER_LOG", null);
if (jasperLog != null){
try{
jasperLog.log(
getString(key,args),
verbosityLevel);
}catch(MissingResourceException e){
jasperLog.log(
key,verbosityLevel);
}
}
This should work 99% of the time the way you describe
with much less pain in implementation.
Feedback welcome. If no one sends a -1 on this, I can
put this patch in fairly rapidly in tc3.3.
Mel
--- "Julien, Timothy" [EMAIL PROTECTED] wrote:
I believe there is a bug in Jasper when resources
(such as web.xml's dtd)
can't be loaded.
The basic problem is that keys are getting passed
into Constants.getString()
which aren't keys in the message resources file.
This happens because of
some exception handling, which basically constructs
an invalid key - namely,
a *value* in the message resources file.
JspUtil.parseXMLDocJaxp(String, InputStream)
{
try
{
...
}
catch(IOException io)
{
throw new
JasperException(Constants.getString("jsp.error.parse.xml",
new Object[] {
uri, io.toString()
}));
}
}
and then lower down the call stack:
public TldLocationsCache(ServletContext ctxt)
{
mappings = new Hashtable();
try
{
processWebDotXml(ctxt);
processJars(ctxt);
}
catch(JasperException ex)
{
Constants.message(ex.getMessage(), 1);
}
}
The trouble is that ex.getMessage() here contains a
*value* from the message
resource file, (as looked up in the first caught
Exception) not a *key*.
One fix would be in JspUtil.parseXMLDocJaxp(String,
InputStream) to pass
only the key (jsp.error.parse.xml) as the
JasperException's message - and
delay the lookup. But then you lose some
information (i.e., io.String()).
Maybe a better solution is to set a flag on
JasperException which marks its
message as being either key or value - so that
Constants.getString can be
called only when necessary. I realize this would
effect alot of code.
anyway, I'm happy to help in any way with the fix.
Tim Julien
HP Middleware
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Bugzilla issues
--- "Ignacio J. Ortega" [EMAIL PROTECTED] wrote: Hola a todos: There are so many Tomcat 3/Jasper bugs and the component itself assigned to Justyna Horward, it seems Justyna will not do much to help us with 3.X, if nobody complaints, if nobody complaints i will make somebody responsible of that component...( myself as a last resort to contact reporters at least ) Who wants to volunteer to own the Jasper component on Tomcat 3? Casey, Mel or Marc perhaps? nacho, I will be glad to help as much as possible on tc3.3 Jasper, as that module is pretty important to The Damn Day Job(tm) and i'm much more familiar with Jasper than any other part of the codebase. I'm a bit of a newbie still with the tomcat project in general though, so don't ask me to manage releases or anything like that. I'm also still learning bugzilla. I guess that qualifies as a "I'll only own it if no one else wants it". I think I might be more valuable as a #2 guy here for now. mel (walking backwards ...) __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: bug in Jasper - bad lookups to Constants.getString()
--- [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2001, Mel Martinez wrote:
Would the following be an acceptable solution?
We change the
Constants.message(key,args,verbosityLevel) method
behavior so that if getString(key,args) throws
a missing resource exception that it logs using
the
key itself as the log message. Note that this
would
also require changing the getString() method to
throw
the MissingResourceException instead of the Error
object that it currently throws.
+1 ( please check the tomcat side is doing the
same - we never had the problem but you never know )
Would StringManager be a better place for the fix ?
Costin
Possibly. I'll take a look tonight. I have to run
home now to watch my daughter watch disney movies and
then run around the house carrying her while she
pretends to fly for a few hours. :-)
Later,
Mel
Looking at this, I am not sure why an Error is
being
thrown here (in Constants.getString()). If Jasper
is
operating in JspServlet mode inside some other
container (i.e. WebLogic, JRun, whatever) then
should
it necessarily throw an Error? According to the
spec,
Errors are reserved for conditions that are so
serious
that they should normally not be caught by the
application. I.E., they should bring the JVM
down.
The fact that Jasper (a servlet) is unable to find
a
String in it's resource file sounds more like
enough
error to throw a RuntimeException or even a
ServletException, but not an Error. That would
allow
the containing ServletEngine to handl the error to
Jasper without bringing down other servlets -
without
having to catch 'Error'.
I think the right way to handle this is to change
the
getString() to just throw the
MissingResourceException. This requires no change
to
the interfaces.
Then in org.apache.jasper.Constants change
message()
to:
public static final void message(
String key,
Object[] args,
int
verbosityLevel){
if (jasperLog == null)
jasperLog = Log.getLog("JASPER_LOG",
null);
if (jasperLog != null){
try{
jasperLog.log(
getString(key,args),
verbosityLevel);
}catch(MissingResourceException e){
jasperLog.log(
key,verbosityLevel);
}
}
This should work 99% of the time the way you
describe
with much less pain in implementation.
Feedback welcome. If no one sends a -1 on this, I
can
put this patch in fairly rapidly in tc3.3.
Mel
--- "Julien, Timothy" [EMAIL PROTECTED]
wrote:
I believe there is a bug in Jasper when
resources
(such as web.xml's dtd)
can't be loaded.
The basic problem is that keys are getting
passed
into Constants.getString()
which aren't keys in the message resources file.
This happens because of
some exception handling, which basically
constructs
an invalid key - namely,
a *value* in the message resources file.
JspUtil.parseXMLDocJaxp(String, InputStream)
{
try
{
...
}
catch(IOException io)
{
throw new
JasperException(Constants.getString("jsp.error.parse.xml",
new Object[] {
uri, io.toString()
}));
}
}
and then lower down the call stack:
public TldLocationsCache(ServletContext ctxt)
{
mappings = new Hashtable();
try
{
processWebDotXml(ctxt);
processJars(ctxt);
}
catch(JasperException ex)
{
Constants.message(ex.getMessage(), 1);
}
}
The trouble is that ex.getMessage() here
contains a
*value* from the message
resource file, (as looked up in the first caught
Exception) not a *key*.
One fix would be in
JspUtil.parseXMLDocJaxp(String,
InputStream) to pass
only the key (jsp.error.parse.xml) as the
JasperException's message - and
delay the lookup. But then you lose some
information (i.e., io.String()).
Maybe a better solution is to set a flag on
JasperException which marks its
message as being either key or value - so that
Constants.getString can be
called only when necessary. I realize this
would
effect alot of code.
anyway, I'm happy to help in any way with the
fix.
Tim Julien
HP Middleware
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: jasper's -classpath
--- "Julien, Timothy" [EMAIL PROTECTED] wrote: How does Jasper construct its Classpath when compiling jsps? From what I see it is: System class path + something from Tomcat + the directory containing the jsp source. Note that when running Jasper in another container, the 'something from Tomcat' part is null - an init-parameter 'org.apache.cataline.jsp_classpath' for JspServlet, I think, is (obviously) missing when running in another container. When running in another container, the class path visible to jasper JSP's is like so: 0 - Classpath (via system class loader) 1 - classes visible to JspServlet's class loader (i.e. the servlet class loader for the container) 2 - classes visible to JasperLoader (the class loader used to load Jsp servlets after they have been compiled). In general, you may or may not have control over 0 (depends on how the container starts up) and what is available via (1) depends on how the container loads servlets. The control over (2) is a little shaky currently. The classpath available to JasperLoader for loading classes is basically whatever directories, jar or zip files have been added via the addJar() method. Unfortunately, as near as I can tell, this is not done anywhere. Now the classpath that is pulled out of the JspServlet's init-params looks like it is _supposed_ to be added to JasperLoader, but if it is I can't find where. It IS appended to the classpath used by the Compiler to compile the jsp's .java files into .class files, but that doesn't help you load the classes and run them. Before I got involved with the tomcat project directly, I solved this problem by extending a few jasper classes to refactor it and fix this and a few other problems specifically to address running Jasper in a non-tomcat container (I need to run it in WebLogic as well). In my solution, I did two things. (1) I outright added a system property to set a classpath for the jsp loader. (2) I calculate the classpath for the JasperLoader using the above property as well as the heretofore ignored init-param and make sure to add it to the loader when I construct the loader for the particular page (my implementation uses a loader for each page to support dynamic reloading). So somewhere between the creation of the loader and the attempt to load the class, which currently happens in JspServlet.doLoadJSP(), the classpath needs to be added to the loader. I say 'currently' because Costin is right when he says that jasper could use some refactoring. I'd like to propose some wholesale refactoring of the class model for the JspServlet and it's supporting classes to better partition responsibilities. I'll make a more formal proposal along these lines shortly. Question: Would Jasper be able to run out of a web-app, without hanving it in the system classpath? Could I stick all of Jaspers relevant jars in the WEB-INF/lib directory and get it to work? The behavior I am seeing says no. I would think that the classpath for compilation should include the jars in WEB-INF/lib directory. If the container properly implements the spec, then JspServlet and thus the jsp servlets should be able to 'see' the WEB-INF/lib classes for LOADING purposes via the servlet classloader. However, that classpath is not made available to the compiler for COMPILATION currently. The compiler sees the classpath of the JasperLoader.getClassPath() call (which as I've said above, is not necessarily set because that is initialized via missing addJar() calls) catenated to the init-param classpath. So the result is that currently, you can only LOAD classes that the parent servlet classloader can see and you can only COMPILE classes visible in the init-param classpath. If you know how the container's classloader behaves, and also manually setup the init-param classpath, you can work around this confusion. However, this needs to be fixed. I will try to take a stab at first a short-term fix to get it working right in the next couple of days and then as mentioned, I'd like to propose some more wholesale changes. Note - a lot of these problems don't exist with the JspInterceptor. These problems seem to be solely with the JspServlet as used separately from tomcat. Cheers, Dr. Mel Martinez __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: bug in Jasper - bad lookups to Constants.getString()
--- [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2001, Mel Martinez wrote: Would the following be an acceptable solution? We change the Constants.message(key,args,verbosityLevel) method behavior so that if getString(key,args) throws a missing resource exception that it logs using the key itself as the log message. Note that this would also require changing the getString() method to throw the MissingResourceException instead of the Error object that it currently throws. +1 ( please check the tomcat side is doing the same - we never had the problem but you never know ) Would StringManager be a better place for the fix ? Costin Yes. After looking into this, it would seem that there is no reason Jasper can't make use of StringManager to handle getting it's resource strings consistent with the way tomcat packages are doing so. This doesn't look too difficult to retro into Jasper. However ... StringManager's getString() currently deals with the MissingResourceException by simply returning a String consisting of a warning message about not being able to find the particular key. I don't think that is correct behavior. I think it should throw the MissingResourceException or return null and that calling code should deal with it. Otherwise the calling code really has no reason to suspect anything is wrong (that the returned string is not what it wanted). If an exception were to be thrown and caught (or a null is checked and found) then the calling code wuld have the option to use the key to construct a replacement String or whatever. However, I am a bit leary about changing code to throw an exception where one has been incorrectly swallowed like this. Currently unsuspecting code may exist that relies unknowingly on this swallowing of the exception by blindly just using whatever string is returned. Changing this may require a bit of testing to see all the effects caused by missing resource strings. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date
--- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: - Clip and Return This Portion - +1 [ ] I support the proposed release, and will work to support it +0 [ ] I support the proposed release, but cannot work on it at this time -0 [ ] I do not support the proposed release, but do not have an alternative to propose -1 [ ] I do not support the proposed release, for reasons specified below. Craig McClanahan (who votes +1) +0 Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: [PATCH] TC3.3 tomcat.bat doesn't pick up external CLASSPATH
--- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: On Mon, 19 Mar 2001, GOMEZ Henri wrote: It's a WANTED feature. With TC 3.3 there is a new classe loader system. Take a look at change3.3 file included in distro. A quick fix for your problem is to copy jaxp / crimson jars in TOMCAT_HOME/lib/common. Tomcat 4.0 follows the same philosophy (ignore the user's original CLASSPATH), for the same reasons. The CLASSPATH variable is the second largest source of user questions and problems on the TOMCAT-USER list (after configuring web connectors), and this philosophy avoids nearly all of those issues. Craig, In support of this, to make deployments more flexible, we added the configuration properties : -Dorg.apache.tomcat.apps.classpath and -Dorg.apache.tomcat.common.classpath to Tomcat 3.3 which seems to help quite a bit at managing the distinctions between the class loading spaces. Is there any chance someone working on TC 4.0 could add support for those properties as well so we have continuity in deployment configuration support? I'd be glad to do it, but I am currently not setup to work on or test tc4.0 yet and due to That Damn Day Job(tm), I'm not likely to get a chance to do so for a while (working on TC 3.3 is easier because it is part of our delivered solution). The code to support these properties is entirely inside org.apache.tomcat.startup.Main in tc3.3, and probably could be ported to tc4.0 relatively easily. If no one else can do it, I'll go ahead, but I've got a pretty full plate and it probably won't get done for at least a week or two. Cheers, Dr. Mel Martinez G1440, Inc. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: Tag names, Attribute Names and NMTOKEN values
--- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: On Mon, 19 Mar 2001, Marc Saegesser wrote: This question comes a bug (387) against Tomcat-3. The JSP specification defines tag names attribute names as containing NMTOKEN values. The specification does not define NMTOKEN so I assume that the XML definition applies. The XML definition of NMTOKEN allows strings that are not valid Java identifiers. Attribute names, however, pose a different problem. Attribute names map into Java method names and thus can't contain some of NMTOKEN characters. Either the specification should define a mapping of NMTOKEN values into Java identifers or state that attribute names must be valid Java identifier names. It seems to me that Jasper should be using the standard JavaBeans introspection mechanisms to decide what actual setter method to call (instead of just gluing "set" on the front of the property name and fixing the capitalization). If it does so, the tag developer can use a BeanInfo class associated with their tag to map non-standard property names into the names of legal getter and/or setter methods. I suppose this same could be said about our interpretation of attributes in other places in the code, such as for Intercepters, etc. In tc3.0, we can probably address this all at once inside the org.apache.tomcat.util.IntrospectionUtils class. I believe jasper already depends on tomcat_util.jar so this shouldn't introduce any new deployment dependency. mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: [VOTE] New commiter - Casey Lucas
+1 Mel --- [EMAIL PROTECTED] wrote: Hi, Please vote for Casey Lucas as commiter. Casey is working on various optimizations in Jasper, with some very promising results ( tag pooling ). He is working on supporting both branches of jasper, and create container-specific adapters. Costin __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: cvs commit: jakarta-tomcat/src/shell tomcat.sh
+1 On putting it in the logs directory. Mel --- David Rees [EMAIL PROTECTED] wrote: On Thu, Mar 15, 2001 at 07:33:19AM -, [EMAIL PROTECTED] wrote: costin 01/03/14 23:33:19 - added -noout option to redirect the stdout/stderr to a file Great, I've been modifying my tomcat scripts to do this by hand forever. - save the PID of the java process in conf/tomcat.pid ( of course, you don't need this because tomcat never hangs, but just in case :-) Shouldn't the pid file be saved in the logs directory as it seems to be customary to do so? (Apache puts it's .pid file in the log dir) -Dave __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/
Re: [VOTE] New Committer: Amy Roh
+1 Welcome aboard, Amy. Dr. Mel Martinez G1440, Inc. --- "Craig R. McClanahan" [EMAIL PROTECTED] wrote: Amy has recently joined the JSP/Servlet team at Sun, and has contributed several documentation updates and new tests for the test harness. She would like to work on bug fixes, as well as participate in the development of better admin tools, primarily on the Tomcat 4.0 code base. Votes please? Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [PATCH] fix for ApacheConfig.java paths for unix
Mike, Thanks for catching this. I tested assigning the path attributes, but forgot to test the defaults on the unix case. I'll try to get your patch tested and applied by the end of tomorrow. I've been a little side-tracked the last few days teaching client personnel. Mel --- Mike Braden [EMAIL PROTECTED] wrote: This patch is for the ApacheConfig.java classes. It changes the static (default) paths from absolute paths to relative paths. Without this fix, the paths are not configurable from the server.xml file as intended. The conf paths also default to / - i.e. /conf/jk/ and /conf/jserv/. When using absolute paths, the TOMCAT_HOME is ignored as well as any prefix that you set in server.xml. Tested on Solaris and Windows 2000 # cvs diff -u ApacheConfig.java Index: ApacheConfig.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/Ap acheConfig.java,v retrieving revision 1.7 diff -u -r1.7 ApacheConfig.java --- ApacheConfig.java 2001/03/05 02:56:49 1.7 +++ ApacheConfig.java 2001/03/13 16:32:59 @@ -118,13 +118,13 @@ // XXX maybe conf/ /** default path to JServ .conf location */ -public static final String APACHE_CONFIG="/conf/jserv/tomcat-apache.conf"; +public static final String APACHE_CONFIG="conf/jserv/tomcat-apache.conf"; /** default path to mod_jk .conf location */ -public static final String MOD_JK_CONFIG = "/conf/jk/mod_jk.conf"; +public static final String MOD_JK_CONFIG = "conf/jk/mod_jk.conf"; /** default path to workers.properties file */ -public static final String WORKERS_CONFIG = "/conf/jk/workers.properties"; +public static final String WORKERS_CONFIG = "conf/jk/workers.properties"; /** default mod_jk log file location */ -public static final String JK_LOG_LOCATION = "/logs/mod_jk.log"; +public static final String JK_LOG_LOCATION = "logs/mod_jk.log"; /** default location of mod_jserv Apache plug-in. */ public static final String MOD_JSERV; /** default location of mod_jk Apache plug-in. */ -- Mike Braden [EMAIL PROTECTED] [EMAIL PROTECTED] ATTACHMENT part 2 application/octet-stream name=ApacheConfig.patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Problem with JspWriterImpl
Hi Oren,
--- "Oren Deri, Nice-Eye" [EMAIL PROTECTED] wrote:
Hi,
when printing in jsp some String that is null
(String str = null;)
the output html is the string "null".
Look at the code of JspWriterImpl.print(String s)
public void print(String s) throws IOException {
if (s == null) {
s = "null";
}
write(s);
}
why did you return "null"? I changed it to "" insted
of "null" and it works
just fine.
:
It may 'work' just fine, in that it is not crashing,
or anything drastic, but the change you made is not
correct. The proper String representation of a null
Object reference is "null". This is part of the Java
Language Specification [sec 15.18.1.1]:
"If the reference is null, it is converted to the
string "null" (four ASCII characters n, u, l, l).
Otherwise, the conversion is performed as if by an
invocation of the toString method of the referenced
object with no arguments; but if the result of
invoking the toString method is null, then the string
"null" is
used instead."
The rational for this is very simple: A null
reference is not an empty String. An empty String is
not a null reference. Consider the following case:
String s = null;
Boolean b = null;
Map m = new HashMap();
m.put("key1",s);
m.put("key2,b);
System.out.println("key1 = "+m.get("key1"));
System.out.println("key2 = "+m.get("key2"));
Now, in both cases, I have stored IDENTICAL values
(null). (s==b)==true. As far as the map m is
concerned, s and b are both of type Object and have
identical reference values of null. Thus, they should
both print out identical String representations (and
they do: the characters n-u-l-l).
public void print(String s) throws IOException {
if (s == null) {
s = "";
}
write(s);
}
My questions:
Is my change can hurt the tomcat operation?
Yes because it is no longer in spec.
Why did you return "null" and not ""
(the original software is on weblogic but we moved
it to tomcat which have
better performance, in weblogic they return "" and
not "null") ?
Unfortunately, the WebLogic JSP implementation is not
within specification. It is broken. While this
change provides a convenience for the lazy JSP
developer, this deviation results in the writing of
JSP code that is not portable to other JSP compilers.
We were bitten by this same misbehavior this winter as
we ported a large body (several hundred pages) of code
from WLS to tomcat/jasper. We were forced to rewrite
zillions of lines of code by our developers (despite
repeated warnings about this) who failed to do the
simple task of checking for null values in their code.
Basically, if you want to use an empty String to
represent a null value, you should do something like:
s==null?"":s
in your code.
Note - we HAD to move off the WLS JSP compiler for
other more fundamental technical reasons as well.
I hope this explains things a bit for you.
Mel
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: 3.3 build
+0 Same sentiments as Nacho. I don't like it, but I can cave in to peer pressure with the best of 'em... :-) 'Course this means I'll have to change all my own damn customized scripts again... :-( Mel --- [EMAIL PROTECTED] wrote: Hi, I'm doing some fixes in the nightly build, and I was wondering about changing the default to what most other jakarta projects are using. I hate creating build in jakarta-tomcat - but since most other projects adopted this we should do it in 3.3 too. Now it's the right moment ( since we are preparing to build M2 - so we'll deal with all the build details and scripts ). Let me know what you think - I would be very happy to hear you strongly disagree with mixing the source and build result, but if no commiter -1 it I guess we should do it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [TC 3.3m1] New Bug in mod_jk auto config generation
This should be fixed in the nightly builds of tc3.3. As of last sunday, you should be able to explicitely control the setting of all these paths in the auto-generated files (and also where they get generated to) using attributes of the ApacheConfig ... / element in server.xml. If you get build the latest source, the attributes are documented in javadoc for org.apache.tomcat.modules.config.ApacheConfig. I'll try to get mods into the user docs this week. Mel --- Mike Braden [EMAIL PROTECTED] wrote: It looks like there have been some new changes to the Tomcat auto config generator. Now when you startup, TC3.3 says: 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jserv config = /conf/jserv/tomcat-apache.conf 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jk config = /conf/jk/mod_jk.conf-auto The jserv stuff is new. This is OK, except that now the config files are put in /conf on the server, not $TOMCAT_HOME/conf # ls /conf jk jserv Could someone please fix this? The above is from last nights build of TC3.3m1 at http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3/ It also looks like the mod_jk.conf-auto has been changed. The paths are not correct: was LoadModule jk_module libexec/mod_jk.so JkWorkersFile /usr/local/tomcat/conf/jk/workers.properties JkLogFile /usr/local/tomcat/logs/mod_jk.log now is LoadModule jk_module /usr/local/tomcat/libexec/mod_jk.so JkWorkersFile "/conf/jk/workers.properties" JkLogFile "/logs/mod_jk.log" Thanks, Mike. -- Mike Braden CNE, MCP+I, MCSE, CCNA, Sun Comp 2k Enterprise E10k Utenzi 808 Aviation Parkway Suite 1100 PO Box 13479 Research Triangle Park, NC 27709 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HTTP Status Codes and Error Pages
Ethan, You missed some good discussions on this two weeks ago between Costin and myself! :-) Not only is it (premature commit) caused by the RequestDispatcher.include() calling flushBuffer() but there are other out.flush() calls in jasper that contribute to the problem. I don't know if it will or can be fixed in the 3.2.2 release (Mark?). The RequestDispatcher.include() bug is fixed in tc3.3. Costin - were you going to make the changes (out.flush() - out.flushBuffers()) in JspParseEventListener.generateFooter() and PageContextImpl.include() that we had discussed? I had thought that you implied you were going to do it (that was before I was a committer) but I just noticed that the out.flush() calls are still the same as before. Send me a note and I'll do this if you can't get to it. Mel --- Ethan Wallwork [EMAIL PROTECTED] wrote: Here is some more info on this problem. I'm seem to be having some problems with the respnse getting committed too early. It still seems wrong that an error page ever get returned with status code 200 though. 1) client makes request to Tomcat 2) Tomcat calls service() on my main servlet 3) servlet does an include() on some (possibly non-existant) JSP 4) JSP file does not exist (expected) 5) FileNotFoundException thrown from include() 6) main servlet catches exception 7) main servlet calls sendError() 8) sendError throws IllegalStateException (response already committed) 9) my error servlet gets called 10) error page get generated and sent to client with HTTP status 200 OK The RequestDispatcher.include() method calls flushBuffer(), which commits the response. This seems to mean that if you have a servlet which includes a JSP, any errors that occur can never be handled properly. Yikes! Code comments indicate that this flushBuffer() is not required by the spec, but is instead there to work around a problem with the session interceptor (BugRat bug #316). -- Ethan -Original Message- From: Ethan Wallwork [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 1:03 PM To: Tomcat-Dev Subject: HTTP Status Codes and Error Pages I can't tell if this is a bug or intended behavior: I have a servlet that acts as the error page for my webapp. Note that this is set up using the web.xml file, not the errorPage directive in the JSPs (if that makes any difference?) When there is an error (say 500 Internal Server Error), it returns a WML page saying things went wrong. This page is being properly generated, but the HTTP response code being sent along with it is "200 OK"! The request attribute java.servlet.error.status_code is set to 500, as I would expect. Calling response.setStatus(500) in the error servlet changes nothing. This is the response I get, headers included: HTTP/1.0 200 OK Content-Type: text/vnd.wap.wml;charset=UTF-8 Cache-Control: no-cache Servlet-Engine: Tomcat Web Server/3.2 (final) (JSP 1.1; Servlet 2.2; Java 1.3.0; SunOS 5.8 sparc; java.vendor=Sun Microsystems Inc.) ?xml version="1.0"? !DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml" wml card title="Error 500" id="error" do label="Back" type="prev" prev/ /do p We're sorry, your request could be fulfilled. br/ 500 Internal Server Error /p /card /wml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Assigning Servlets to different ports.
There might be a more 'elegant' way but a simple brute
force solution is to create a simple dispatcher
servlet (or JSP) that does the following:
String host = request.getHeader("HOST");
String port = "80";
if(host.indexOf(":")-1){
port = host.substring(host.indexOf(":")+1);
}
//assume getDispatchMap() returns a map of
//ports to servlets, probably loaded from
//a configuration file or whatever
String target = (String)getDispatchMap().get(port);
RequestDispatcher rd =
context.getRequestDispatcher(target);
rd.forward(request,response);
That is a simple dispatcher pattern that should work.
The only thing you have to do is configure "/" to map
to the above servlet/jsp. You can do that in a
variety of ways.
The usual caveates and disclaimers apply to the above
code... :-)
Cheers,
Mel
--- William Wishon [EMAIL PROTECTED] wrote:
Hi,
My goal is to be able to have different servlets
mapped to "/" on different
ports. I have not found any way to do this in
server.xml, so I started
grep'ing and groveling through the code to find out
more. Now as far as I
can tell right now what I want to do is not possible
using Tomcat 3.2.1. My
question to this list is if anyone here can either
show me what I've missed
and tell me how to configure Tomcat to do what I
want. Or if someone can
help me out by pointing me in the right direction in
terms of patching the
3.2.1 sources to do what I want. Perhaps this is
now possible in the newer
versions of tomcat and I could back port a change.
Or ??? Any help is
greatly appreciated.
An example of what I'm trying to do is to have a GET
on "/" of port 8080
return webapps/app1/index.html and a GET of "/" on
port 8081 return
webapps/app2/index.html.
Thanks,
Bill
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, email:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
The attached PATCH modifies org.apache.tomcat.modules.config.ApacheConfig to add some needed flexibility. I need someone who is running apache and tomcat3.3 using mod_jserv to test it in that configuration and give their feedback. I've tested it with mod_jk on winNT and linux 6.2 and it seems to work fine. I would of course welcome any tests that would uncover things I may have overlooked. As soon as I have a reasonable amount of feedback to resolve any such oversights, I will commit the changes. The nature of the changes is as follows. First off, if you haven't been using the latest tomcat3.3, you need to tell it to auto-generate the Apache config files for jserv and jk. To do this, the only thing you need to do is insert an ApacheConfig/ config intercepter element inside the ContextManager tag like so: ContextManager ... ... ApacheConfig / ... /ContextManager That will make sure that ApacheConfig is invoked. In the absence of any attributes in the ApacheConfig/ tag the only difference in behavior should be that the LoadModule statements will be wrapped in IfModule !mod_name.c ... /IfModule tags to make the loads conditional. In addition to making the LoadModule statements conditional, I've also added some attributes to the ApacheConfig / tag that should greatly help setting up Apache and Tomcat deployments: confighome - default parent directory for the following paths. If not set, this defaults to TOMCAT_HOME. Ignored whenever any of the following paths is absolute. jservconfig - path to write apache jserv conf file to. If not set, defaults to "conf/jserv/tomcat-apache.conf". jkconfig - path to write apacke mod_jk conf file to. If not set, defaults to "conf/jk/mod_jk.conf". workersconfig - path to workers.properties file used by mod_jk. If not set, defaults to "conf/jk/workers.properties". modjserv - path to Apache JServ plugin module file. If not set, defaults to "modules/ApacheModuleJServ.dll" on windows, "modules/Jserv.nlm" on netware, and "libexec/mod_jserv.so" everywhere else. modjk - path to Apache mod_jk plugin file. If not set, defaults to "modules/mod_jk.dll" on windows, "modules/mod_jk.nlm" on netware, and "libexec/mod_jk.so" everywhere else. jklog - path to log file to be used by mod_jk. All of these attributes are optional. Please try the patch out and let me know if you have any problems. Send me a +1 if you think it should be committed. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH][tc3.3]Re: Proposed ApacheConfig.java change
eJServ.dll"
+ on windows, "modules/Jserv.nlm" on netware, and
+ "libexec/mod_jserv.so" everywhere else./li
+ libmodjk/b - path to Apache mod_jk plugin file. If not set,
+defaults to "modules/mod_jk.dll" on windows,
+"modules/mod_jk.nlm" on netware, and
+"libexec/mod_jk.so" everywhere else./li
+ libjklog/b - path to log file to be used by mod_jk./li
+
+/ul
+p
+@author Costin Manolache
+@author Mel Martinez
+ @version $Revision: 1.26 $ $Date: 2001/02/26 09:42:30 $
*/
public class ApacheConfig extends BaseInterceptor {
// XXX maybe conf/
-public static final String APACHE_CONFIG = "/conf/jserv/tomcat-apache.conf";
-public static final String MOD_JK_CONFIG = "/conf/jk/mod_jk.conf";
+
+/** default path to JServ .conf location */
+public static final String APACHE_CONFIG="/conf/jserv/tomcat-apache.conf";
+/** default path to mod_jk .conf location */
+public static final String MOD_JK_CONFIG = "/conf/jk/mod_jk.conf";
+/** default path to workers.properties file */
public static final String WORKERS_CONFIG = "/conf/jk/workers.properties";
+/** default mod_jk log file location */
public static final String JK_LOG_LOCATION = "/logs/mod_jk.log";
-
+/** default location of mod_jserv Apache plug-in. */
+public static final String MOD_JSERV;
+/** default location of mod_jk Apache plug-in. */
+public static final String MOD_JK;
+
+//set up some defaults based on OS type
+static{
+String os = System.getProperty("os.name").toLowerCase();
+if(os.indexOf("windows")=0){
+ MOD_JSERV = "modules/ApacheModuleJserv.dll";
+ MOD_JK = "modules/mod_jk.dll";
+}else if(os.indexOf("netware")=0){
+ MOD_JSERV = "modules/Jserv.nlm";
+ MOD_JK = "modules/mod_jk.nlm";
+}else{
+ MOD_JSERV = "libexec/mod_jserv.so";
+ MOD_JK = "libexec/mod_jk.so";
+}
+}
+
public static final String[] JkMount = { "ajp12", "ajp13" };
public static final int AJP12 = 0;
public static final int AJP13 = 1;
public static final String AJPV12 = "ajpv12";
+
+private File configHome = null;
+private File jservConfig = null;
+private File jkConfig = null;
+private File workersConfig = null;
+private File modJserv = null;
+private File modJk = null;
+private File jkLog = null;
+
+
+
public ApacheConfig() {
}
@@ -108,300 +183,664 @@
public void contextInit(Context ctx)
throws TomcatException
{
- ContextManager cm=ctx.getContextManager();
- if( cm.getState() = ContextManager.STATE_INIT ) {
- // a context has been added after the server was started.
- // regenerate the config ( XXX send a restart signal to
- // the server )
- execute( cm );
- }
+ ContextManager cm=ctx.getContextManager();
+ if( cm.getState() = ContextManager.STATE_INIT ) {
+ // a context has been added after the server was started.
+ // regenerate the config ( XXX send a restart signal to
+ // the server )
+ execute( cm );
+ }
}
-
-
+
+/**
+this method helps the context's XMLMapper to work when
+setting properties.
+*/
+public void setProperty(String name,String value){
+name = name.toLowerCase(); //case-insensitive
+if(name.equals("confighome")) setConfigHome(value);
+if(name.equals("jservconfig")) setJservConfig(value);
+if(name.equals("jkconfig")) setJkConfig(value);
+if(name.equals("workersconfig")) setWorkersConfig(value);
+if(name.equals("modjserv")) setModJserv(value);
+if(name.equals("modjk")) setModJk(value);
+if(name.equals("jklog")) setJkLog(value);
+}
+
+/**
+set a path to the parent directory of the
+conf folder. That is, the parent directory
+within which setJservConfig(), setJkConfig()
+and setWorkerConfig() paths would be resolved against
+if relative. For example if ConfigHome is set to "/home/tomcat"
+and JkConfig is set to "conf/mod_jk.conf" then the resulting
+path returned from getJkConfig() would be:
+"/home/tomcat/conf/mod_jk.conf"./p
+p
+However, if JkConfig, JservConfig or WorkersConfig
+are set to absolute paths, this attribute is ignored.
+p
+If not set, execute() will set
TC3.3 build not generating javadocs?
I notice that as of a day or two ago (my last major 'update' from CVS) that now when I build tomcat 3.3, even after a 'clean', that only a few of the javadocs get generated. Specifically, just those in org.apache.tomcat.modules. I realize that for some folks, they don't want to wait to rebuild all the javadocs everytime they build. So maybe it makes sense to have the script not build them by default. However, I'd like for someone to tell me how to modify the build.xml script to re-enable complete generation of the javadocs for all the packages. I am an Ant newbie and the build.xml looks strange and frightening to me! :-) Thanks, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
FYI: I'm pretty much done with the mods I wanted to make (I ended up adding a few extras) and am in the testing and documenting phase. Should be ready tomorrow. BTW: I figured out soon after my last post that the only thing I needed to do enable auto-generation of apache config files was to insert an ApacheConfig/ config intercepter element inside the ContextManager tag like so: ContextManager ... ... ApacheConfig / ... /ContextManager That returned it to the default 3.2.1 behavior. --- Dan Milstein [EMAIL PROTECTED] wrote: I would strongly vote for turning the auto-config back on by default for the following reasons (other than the fact that I explicity turned it back on when Keith fixed the ApacheConfig class): 1) This is how 3.2 worked, and how the docs specify that 3.3 works. I think that that is a strong argument in favor of having it enabled. The cost in startup performance is negligible and runtime is essentially zero so I advocate defaulting it to enabled. At a minimum, the ApacheConfig element should be present in the server.xml file to comment/uncomment out to toggle. 2) Configuration of mod_jk is notoriously complicated. Giving people the auto generated file is a big, big win. Aside from the proposed mod to make the LoadModule statement conditional, I've also added some attributes to the ApacheConfig / tag that should greatly help setting up Apache and Tomcat together: confighome - default parent directory for the following paths. If not set, this defaults to TOMCAT_HOME. Ignored whenever any of the following paths is absolute. jservconfig - path to write apache jserv conf file to. If not set, defaults to "conf/jserv/tomcat-apache.conf". jkconfig - path to write apacke mod_jk conf file to. If not set, defaults to "conf/jk/mod_jk.conf". workersconfig - path to workers.properties file used by mod_jk. If not set, defaults to "conf/jk/workers.properties". modjserv - path to Apache JServ plugin module file. If not set, defaults to "modules/ApacheModuleJServ.dll" on windows, "modules/Jserv.nlm" on netware, and "libexec/mod_jserv.so" everywhere else. modjk - path to Apache mod_jk plugin file. If not set, defaults to "modules/mod_jk.dll" on windows, "modules/mod_jk.nlm" on netware, and "libexec/mod_jk.so" everywhere else. jklog - path to log file to be used by mod_jk. All of these attributes are optional. 3) For the people who run it in standalone, we can provide a comment in the file telling them to "comment out the below". That way it would work out of the box for both types (standalone + behind Apache), and be very easy for people to tune to their needs. Since the syntax has changed (and I've never been a server.xml master), I'm not sure where the AutoConfig stuff would go now. Lemme know if you guys like/dislike the above changes. I should be able to have it ready early tomorrow (Sunday). I will post a PATCH version first so I can get some feedback on test configurations I don't have available. Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Proposed ApacheConfig.java change
Hi y'all. I'm in the process of making a small tweak so that the mod_jk.conf-auto file uses IfModule conditionals around the LoadModule statments. As discussed earlier, there should be a lot of deployment configuration value in this tweak. However, after upgrading to the latest and greatest tomcat 3.3 version out of CVS (as of last night) I've suddenly noticed that tomcat is no longer generating the mod_jk.conf-auto or tomcat-apache.conf files automatically. As near as I can tell, ApacheConfig.execute() is not being called. Is this a bug or do I need to configure something in server.xml now to make this happen? (With tc3.2.1 I didn't do anything in particular to cause these to be generated.) I look forward to some enlightenment. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Proposed ApacheConfig tweak:Re: Bugzilla #512 is Bunk
--- Stephen Jones [EMAIL PROTECTED] wrote:
In httpd.conf, you cannot do this:
VirtualHost blah
normal config for VirtualHost ...
Include
/usr/local/jakarta-tomcat/conf/mod_jk.conf-auto
/VirtualHost
There are three main purposes of including
mod_jk.conf-auto:
(1) To get the mod_jk Apache Module loaded, as
follows:
LoadModule jk_module libexec/mod_jk.so
The first (1) Apache directive is the problem: the
LoadModule directive
is illegal within the VirtualHost context.
(See
http://httpd.apache.org/docs/mod/mod_so.html#loadmodule
)
Without trying to change the fact that the LoadModule
call should not be inside a virtual host definition, a
simple patch that should fix this as a side benefit
(the main benefit is improved flexibility in deploying
tomcat and apache) would be to make a simple change to
ApacheConfig.java.
Specifically, ApacheConfig currently generates (based
on operating system type and other conditions) a line
similar to:
LoadModule jk_module modules/mod_jk.dll or
LoadModule jk_module modules/mod_jk.so
and so on. It should not be too difficult to modify
ApacheConfig.java to generate the following
declaration format instead:
IfModule !mod_jk.c
LoadModule jk_module modules/mod_jk.so
/IfModule
This would serve two purposes. Obviously, if the
module is already loaded, then LoadModule would not be
called. Thus, if you simply make sure to use
LoadModule to load mod_jk prior to the VirtualHost
definition, then I believe that if you include the
mod_jk.conf-auto file it should not cause a problem.
I.E. step (1) would be ignored.
The more important benefit would be to allow the
deployment engineer freedom to put the mod_jk.so (or
mod_jk.dll) module elsewhere than inside
${TOMCAT_HOME}/modules/. Inside httpd.conf, you would
simply specify where you want to load mod_jk.so/.dll
from prior to including mod_jk.conf-auto.
Some examples:
#...inside a solaris version of httpd.conf...
LoadModule jk_module /path/modules/solaris/mod_jk.so
Include
/usr/local/jakarta-tomcat/conf/mod_jk.conf-auto
#...while inside a linux version of httpd.conf:
LoadModule jk_module /path/modules/linux/mod_jk.so
Include
/usr/local/jakarta-tomcat/conf/mod_jk.conf-auto
and so on. This would make it easier to deploy the
same apache/tomcat configuration from CVS to multiple
platforms since you don't have to maintain a custom
mod_jk.conf for each platform.
The same fix should be applied to the other LoadModule
calls (such as for jserv).
I will try to put some time into creating this patch
later today. I don't think I can get it done for a
day or two though. Too busy with other things. I do
need this patch for my own purposes, though, so I will
definitely pursue it.
Does anybody see a problem with this proposal?
If I don't hear any nay-saying I'll proceed. I'll
post it first as a [PATCH] as I'll need folks using
jserv to test it out as well, but this looks pretty
straight forward.
Cheers,
Mel
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
TC3.3-propose change to org.apache.tomcat.startup.Main.java
Hi folks,
I'm still new here so help me with the correct
protocol here.
I'd like to propose a minor change to the Tomcat 3.3
class:
org.apache.tomcat.startup.Main
to support two additional configuration properties:
org.apache.tomcat.common.classpath and
org.apache.tomcat.shared.classpath
These properties, set using the -D option and then
made part of a ${TOMCAT_OPTS} block, would allow one
to specify additional classpath elements for the
'shared' and 'common' class loaders.
This is important for deployment flexibility because
it is simply not workable to have all needed classes
and jar files placed physically in the current
lib/shared/ and lib/common/ directories.
I have already rewritten Main locally and tested this
and it seems to work well. The protocol I've adopted
at this point is that any classpath elements specified
in either of the above two properties to be _appended_
to the classpath URL arrays built with the classes in
the shared and common directories. I.E. - the
physical directories take precedence during
class-loading. I am open to reversing that if folks
feel that conceptually the properties should take
precedence over the directories.
The changes to support this were minor but the result
greatly eases deployment hassles currently involved in
using Tomcat with complex deployment situations.
I am not a committer and only have 'anoncvs' access.
I will gladly email the file to someone who is.
Feedback encouraged.
Mel
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: TC3.3-propose change to org.apache.tomcat.startup.Main.java
--- "Ignacio J. Ortega" [EMAIL PROTECTED] wrote: Hola, Mel: Hi folks, I'm still new here so help me with the correct protocol here. Follow http://jakarta.apache.org/site/source.html guidelines Ignacio, Thanks! I'll follow that up. Basically send a cvs diff -u of the files or file involved in your patch.. to the list with a "[PATCH]" in subject.. One more advice ( I will change the site shortly to add this advice ) send your patch to the list as an attachment, not embedded in the message.. Sounds simple enough. Sounds good, and i think that if anybody takes this carefull measures before start tomcat, we can suppouse that he knows because he is starting in this way and why, the properties classpath should go before the tomcat internal lib directories.. That sounds reasonable too. The administrator doing this can always explicitely include 'lib/shared/X.jar' files in the classpath if he needs to flip the order. I'll reverse the precedence to put the property-specified paths first, then after testing it a bit, I'll clean out my debug statements and post a [PATCH] attachment for you. Look for it later today (I've got to run some errands right now). Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH]TC3.3 - org.apache.tomcat.startup.Main
The attached patch file contains diffs for adding the
following feature to startup.Main:
- supports two new configuration properties:
org.apache.tomcat.common.classpath and
org.apache.tomcat.shared.classpath
- builds URLs to each jar and directory in the
above two class paths and prepends them to
the URL arrays used to initialize the 'common'
and 'shared' classloaders. This allows one
to configure the common and shared ClassLoaders
without having to physically place files into
TOMCAT_HOME/lib/common/ and ../lib/shared
directories.
- added some needed javadoc comments (not nearly
enough).
- fixed a couple tiny bugs (nothing serious).
Hopefully a committer (Ignacio?) will have no trouble
with this patch file. Lemme know if you need any
help.
Cheers,
Mel
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Index: Main.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/startup/Main.java,v
retrieving revision 1.25
diff -u -r1.25 Main.java
--- Main.java 2001/02/10 19:17:28 1.25
+++ Main.java 2001/02/25 21:53:07
@@ -1,4 +1,10 @@
/*
+ * $Source$
+ * $Revision$
+ * $Date$
+ * $Author$
+ */
+/*
*
*
* The Apache Software License, Version 1.1
@@ -69,22 +75,101 @@
import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.compat.Jdk11Compat;
-// Depends:
-// JDK1.1
-// tomcat.util.IntrospectionUtils, util.compat
/**
- * Starter for Tomcat.
- *
- * This is a replacement/enhancement for the .sh and .bat files - you can
- * use JDK1.2 "java -jar tomcat.jar", or ( for jdk 1.1 ) you just need to
- * include a single jar file in the classpath.
- *
- * @author Costin Manolache
- * @author Ignacio J. Ortega
- *
+ Starter class for Tomcat.
+ p
+ This is a replacement/enhancement for the .sh and .bat files - you can
+ use JDK1.2 "java -jar tomcat.jar", or ( for jdk 1.1 ) you just need to
+ include a single jar file in the classpath.
+ p
+ This class creates three class loader instances:
+ ol
+ lia 'common' loader to be the parent of both the server
+ container and also webapp loaders./li
+ lia 'shared' loader to load classes used by all webapps, but
+ not the servlet engine./i
+ lia 'server' loader exclusively for the tomcat servlet engine./li
+ /ol
+ Both the 'shared' loader and 'server' loader have the common loader as
+ the parent class loader. The class path for each is assembled like so:
+ ul
+ licommon - all elements of the
+codeorg.apache.tomcat.common.classpath/code
+ property plus all *.jar files found in ${TOMCAT_HOME}/lib/common/./li
+ lishared - all elements of the
+codeorg.apache.tomcat.shared.classpath/code
+ property plus all *.jar files found in ${TOMCAT_HOME}/lib/shared/./i
+ liserver - all jar files found in ${TOMCAT_HOME}/lib, plus the class
+ folder ${TOMCAT_HOME}/classes and finally also the utility jar
+ file ${JAVA_HOME}/lib/tools.jar./li
+ /ol
+ After creating the above class loaders, this class instantiates, initializes
+ and starts an instance of the class
+codeorg.apache.tomcat.startup.Tomcat/code.
+ p
+ @author Costin Manolache
+ @author Ignacio J. Ortega
+ @author Mel Martinez [EMAIL PROTECTED]
+ @version $Revision$ $Date$
*/
public class Main {
+
+ /**
+ name of configuration property to set (using the -D option at
+ startup or via .properties file) to specify the classpath
+ to be used by the ClassLoader shared amongst all web applications
+ (but not by the servlet container). Specify this string as
+ normal file paths separated by the path.seperator delimiter for
+ the host platform. Example (unix):
+ precode
+ * org.apache.tomcat.shared.classpath = /home/mypath/lib/mylib.jar: \
+ * /home/mypath/classes/
+ /code/pre
+ */
+ public static final String TOMCAT_SHARED_CLASSPATH_PROPERTY =
+ "org.apache.tomcat.shared.classpath";
+
+ /**
+ the classpath shared among all web apps (in addition to any
+ jar files placed directly in $TOMCAT_HOME/lib/shared/).
+ */
+ public static final String TOMCAT_SHARED_CLASSPATH;
+
+ /**
+ name of configuration property to set (using the -D option at
+ startup or via .properties file) to specify the classpath
+ to be used by the ClassLoader common to both the servlet
RE: [PATCH]TC3.3 - org.apache.tomcat.startup.Main
--- "Ignacio J. Ortega" [EMAIL PROTECTED] wrote: Some comments on format and condign conventions ( in not the most appropiate for this :) : .- Wrap lines on the 80 chars boundary.. Oops! I did fine on the code - unfortunately went over on a couple of javadoc lines. Another comment line that's over was not mine. I'll be sure to check this in the future. .- Follow guidelines in http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html I'll assume you refer to the lack of guidelines followed in the rest of the file (I didn't want to sit there and rewrite everything). I did fix several if()'s without braces. .- do not use tabs at all I didn't know this (no tabs) was a tomcat guideline (many of the source files already have tabs in them) but I'll gladly stick to it from now on. I Know , i Know , this little comments can suppouse a flame bait :), everyone has his opinion perfectly admitible, but a unique coding style is a must in a project like Tomcat.., and it's on the guidelines.. I'm fine with that - but I don't see any real guidelines applied at all to the code I've looked at. Most notably, there is a noticeable lack of any effort at javadoc comments throughout the code. Not that I'm complaining. We all can do better. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: TC3.2.1 - response commit on included JSPs
Re: out.flush() sets the 'committed' state in the
response in tc3.2.1 JspWriterImpl.
--- [EMAIL PROTECTED] wrote:
Hi Mel,
First, JspWriter needs to be flushed at the end of
the page - it has a
buffer, and if the buffer is not commited the data
will be lost.
There is a method ( flushBuffer ) in JspWriterImpl,
and that method should
be called instead of flush().
Hi Costin,
Two points come to mind here. First off, I totally
agree that at the end of the page the buffer should be
'committed' to the underlying ServletOutputStream -
but I also believe that the ServletResponse should not
be committed from within a dynamically included
servlet or JSP page - is that distinction not clear?
Second, while there is a flushBuffer() method in
JspWriterImpl, this method is NOT a part of the
javax.servlet.jsp.JspWriter interface nor is it public
(it is protected).
An examination of JspWriterImpl.flush() shows that it
does it's own flushBuffer() before calling it's own
'out.flush()' (to cascade the flush to the underlying
ServletOutputStream) and then response.flushBuffer():
/**
* Flush the stream.
*
*/
public void flush() throws IOException {
synchronized (lock) {
flushBuffer();
if (out != null) {
out.flush();
// Also flush the response buffer.
response.flushBuffer();
}
}
}
(the above code is identical in both the tc3.2.1
version (JspWriterImpl rev1.4) and the latest in the
cvs web mainline branch (rev1.5).
Looking at JspWriterImpl.flushBuffer() it does indeed
look like it does all that you'd want it to do from
within an included request, as it simply writes the
current buffer to the underlying ServletOutputStream.
Where trouble is probably being caused is that when
flush is being called it also calls
response.flushBuffer() both directly as well as
indirectly (through cascaded out.flush() calls). If
we can prevent that from happening in the 'included'
case, perhaps that would be enough to fix the problem?
So, it seems from this, that a simple fix might be to
do the following :
/**
* Flush the stream.
*
*/
public void flush() throws IOException {
synchronized (lock) {
flushBuffer();
if (out != null !isIncluded) {
out.flush();
// Also flush the response buffer.
response.flushBuffer();
}
}
}
where we would redefine or create a new constructor:
public JspWriterImpl(
ServletResponse response,
int sz,
boolean autoFlush,
boolean isIncluded) {
this(response,sz,autoFlush);
this.isIncluded = isIncluded;
}
where isIncluded would default to false, of course.
And finally, the PageContextImpl would have to be
fixed
to use the new constructor. It would set the
isIncluded flag based on the presence of the request
attribute "javax.servlet.include.servlet_path".
In 3.2 we had a lot of problems with the buffers -
changing that may be a
bit dangerous. For 3.3, the whole buffering has been
re-designed and
refactored, and most problems we knew about in the
servlet container
are fixed ( but so far this issue hasn't been fixed
- to be honest I
didn't knew about it, I've been focused more on the
servlet side ).
I believe the problem here is solely on the jasper
side. This problem shows up whether running jasper
inside tomcat or inside weblogic server's servlet
engine.
It shouldn't be difficult to fix it, and since it is
a spec issue I think
this is a must_fix bug.
The best way to make sure it'll be indeed fixed is
to send a patch or at
least a test case ( a small war with some
servlets/jsps and a gtest
fragment that we can include in our nighlty tests ).
Are the above suggestions useful? I can test them out
on my own because I have a framework for overriding
and extending most all jasper behavior through
subclassing, but I am not a tomcat cvs committer nor
am I well setup yet to put the changes directly into
jasper code. I want to get more directly involved,
but I don't have the luxury of time just yet. Just
researching this problem is costing a lot of money so
far.
As for test cases, the problem should show up if you
try to include a .jsp file and then subsequently in
the calling page or servlet do something that requires
an uncommitted response (such as a redirect).
I'm going to try to tackle this and verify if my
ideas above will help or not. I'll report back later
on it.
Mel
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: TC3.2.1 - response commit on included JSPs
--- [EMAIL PROTECTED] wrote:
Second, while there is a flushBuffer() method in
JspWriterImpl, this method is NOT a part of the
javax.servlet.jsp.JspWriter interface nor is it
public
(it is protected).
We can make it public - and the generated servlets
already depends
on jasper runtime.
The problem is that flush() must still be executed
as expected,
i.e. if an included JSP or servlet is actually
calling flush(),
it expects the response to be commited.
But does that necessarily mean to commit it to the
browser? Or should it instead just commit it to the
buffer of the calling page (which is the actual
'client' here)? I think it is the latter case that is
correct.
It is possible to disable commit when a servlet/jsp
is included,
but then we disable a reasonable function (explicit
flush() ).
Or we can disable the commit just before the
final/implicit out.flush()
- but again we need an explicit API call.
Where trouble is probably being caused is that
when
flush is being called it also calls
response.flushBuffer() both directly as well as
indirectly (through cascaded out.flush() calls).
If
we can prevent that from happening in the
'included'
case, perhaps that would be enough to fix the
problem?
Then how do you distinguish explicit flush() calls ?
And the spec for flush() is clear IMHO - it should
propagate
and commit the response.
This may be correct for streams in general, but if
adhered to in servlet-servlet communication, then we
have to re-think the way we use flush().
Aside from the question of what an explicit flush()
should do, one also has to worry about what should
happen when the buffer of the underlying stream simply
fills up, forcing an implicit flush.
I'll try to commit some changes tonight. I'm going
to try
with the flushBuffer() - it seems to me this is the
right
way to do it ( and you can still do explicit flush()
inside an
included jsp and get the expected behavior )
I tried the change I suggested, which is to change
JspWriterImpl.flush() to (essentially):
public void flush(){
flushBuffer();
if(out!=null !isIncluded){
out.flush();
response.flushBuffer();
}
}
which effectively makes this equivalent to your
suggestion of replacing the use of out.flush() in the
finally{..} with out.flushBuffer(). I'll grant that
if we accept that flush() must always propagate then
the above solution is not 'elegant'. However, it does
work just as well. And it at least tries to adhere to
the principal that included servlets should not commit
the response.
Neither solution completely blocks an included servlet
from flushing the parent stream because as currently
written flushBuffer() can still end up flushing the
stream if it writes enough bytes to the underlying
stream to overfill it's buffer, causing an implicit
flush().
This could be prevented by rewriting flushBuffer(),
but I can't do that in my scheme because for some
reason it is declared 'final' in the current code.
Before I go, I want to cast a light on some other
misbehavior in this area. From the JSP 1.1 spec,
section 2.13.4, paragraph 6, on dynamic includes:
"If the page output is buffered then the buffer is
flushed prior to the inclusion."
The current jasper code in tc3.2.1 implements
jsp:include using PageContextImpl.include() which
simply does:
String path =
getAbsPathRelativeToContext(relativeUrlPath);
out.flush();
context.getRequestDispatcher(path).include(
request, response);
As it stands, this will always commit the response
prior to the include. This is not a problem for the
include, per se, but this is not what performing an
include should do because it alters the commit state
of the current page's response object.
In other words, the use of out.flush() (as currently
defined) just prior to the include means you can not
do something like so:
jsp:include page="/somepage.jsp" flush="true" /
%
response.sendRedirect("http://somewhere");
%
This breaks even if neither the current page or the
included page have actually written anything to the
stream simply because out.flush() is committing the
response prematurely.
So the core problem remains that flush() should NOT
commit the response.
As before, replacing the use of out.flush() in
PageContextImpl.include() with just the functionality
of out.flushBuffer() fixes the problem with the same
exception of the case where the amount of output
written to the underlying servletoutputstream causes
an implicit flush.
The solution you seem to favor is to make
JspWriterImpl.flushBuffer() public and then changing
the generated servlet code to have:
}finally{
((JspWriterImpl)out).flushBuffer();
...
}
and to similarly replace the out.flush() in
PageContextImpl.include().
This still would allow an explicit flush() or a buffer
overflow to commit the response.
I guess I'd be okay with that solution, but I'm not
sure I'm convinced that even an
Re: TC3.2.1 - response commit on included JSPs
--- Incze Lajos [EMAIL PROTECTED] wrote:
Maybe it's not correct in general but the JSP 1.1
syntax
contains the flush="true" attribute - obligatory in
case
of jsp:include. So, it's inconvenient but tomcat3 is
an
jsp 1.1 implementation. Am I missing something?
incze
The JSP 1.1 spec says that the current response buffer
should be flushed _prior_ to the inclusion. In other
words, the flush="true" requirement is talking about
what should happen at level of the calling page. In
normal java servlet code this is saying :
if(buffered flush==true){ //JSP1.1 flush always
true
out.flush();
}
requestDispatcher.include(...);
//continue...
All this is saying is that, at least for JSP 1.1, we
are required to write everything we've put in the
buffer now before we add more to the buffer from the
included resource. This requirement is supposed to
happen on the CALLING page, not in the INCLUDED page.
I will note that TC3.2.1 does not actually do this
correctly and if it tried, it would break because of
the same root cause to the problem I am talking about
here.
The problem I am talking about is independent of the
_calling_ page.
The problem is caused by the nature of the JSP servlet
that is generated by TC3.2.1. It cannot properly be
included (dynamically) from either a JSP *OR* a
servlet because when it exits, it always sets the
isCommitted() flag of the response. It should not do
that if the page is processing a request as an
'include' action because only the parent, calling
servlet or jsp should Commit the response.
As explained, the reason it always sets the
isCommitted() state is due to the sequence:
1) Every JSP page generated by TC3.2.1 has a finally{}
block that invokes out.flush() and...
2) For some reason the TC 3.2.1 JspWriterImpl
implementation of out.flush() commits the response
even BEFORE it calls response.flushBuffer()!
3) Also, out.flush() ALWAYS calls
response.flushBuffer() even if processing an included
request.
IMHO out.flush() should not commit the response. Only
response.flushBuffer() should commit the response.
And response.flushBuffer() should not be called from
an inside an 'include' request.
What probably SHOULD happen is the following:
1) Response.flushBuffer() alone should be used to set
the commit state. But it should NEVER be called from
within an include action which can be checked with:
Obj incl = request.getAttribute(
"javax.servlet.include.servlet_path");
if(incl==null){
response.flushBuffer();
}
2) It is probably fine for out.flush() to be called at
the end of every JSP page. Optionally, a check like
in
(1) could be used to call response.flushBuffer().
3) MOST IMPORTANTLY - JspWriterImpl needs to be
rewritten so as to flush the output stream, but NOT to
commit the response and NOT to call
response.flushBuffer()!
I'd say that I consider this a serious bug because it
makes it impossible for a JSP page to be included in
any other JSP or even a Java Servlet except as the
last committment to the response - which means that it
is essentially only a 'forward' action.
Also, the fact that out.flush() (incorrectly) commits
the response actually means that technically TC3.2.1
can not be made compliant with the very spec you cite
because if it DID enforce the flush="true" attribute
and then tried to include a resource (or do ANY output
or forward or redirect), an error would occur becuase
(as I've stated) the response would already be
committed as soon as out.flush() got called.
"Fortunately", tc3.2.1 is currently broken in this
regard and is NOT actually flushing the output before
the include. If the above problem in out.flush() is
fixed, then this should be fixed as well.
This bug has thrown a HUGE wrench into my current
project and I'm not sure how I'm going to address it
in the short term.
Hasn't someone noticed this before? Is this problem
fixed in either of the later versions (3.3 or 4.0)?
If so, I may need to upgrade and I really hate having
to upgrade to non-release versions of software since
that entails a whole lot of risk/justification I have
to explain to my clients.
Sigh... if it ain't one thing, it's another...
Mel
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
TC3.2.1 - response commit on included JSPs
Hi folks,
I've spotted what looks like a bug in the jasper
compiler of TC3.2.1 - if this is old news, just let me
know and I'll shut up.
There are two parts to this:
1) the _jspService() method generated by the jasper
compiler uses a try{ ... }catch{...}finally{...}
block. The finally clause looks like so:
}finally{
out.flush();
_jspxFactory.releasePageContext(pageContext);
}
Q: shouldn't the their be a check to see if the
current request is the result of a dynamic include
before we flush the buffer?
2) Examination of
org.apache.jasper.runtime.JspWriterImpl and the
response classes shows that flush() has set the
response.isCommitted() flag of the HttpServletResponse
object before response.flushBuffer() has been called.
Q: JavaDoc for the ServletResponse.flushBuffer()
method implies that it should be the one to set the
'committed' state of the response object:
"Forces any content in the buffer to be written to the
client. A call to this method automatically commits
the response, meaning the status code and headers will
be written."
Without getting stuck on the details of either of the
above issues, the real issue is that as it stands
above, if you do a dynamic include of a JSP page then
the response object is committed upon the return of
the method. I don't believe that is correct behavior.
Is this fixed in a later release? If so, which one
should I upgrade to?
Thanks,
mel
Dr. Mel Martinez
G1440, Inc.
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
apache AliasRewrites vs tomcat?
I'm trying to assertain just how Apache and Tomcat interact regarding aliases and rewrites. I'm using Apache 1.3.14 and tomcat 3.2.1 with mod_jk.c. I don't know if the latter is the 'latest' version. If I have apache configured to apply an alias or a rewrite rule to a reqest, I can tell from the logs that it is indeed getting applied: (2) init rewrite engine with requested uri /myapp/folder1/common/mypage.jsp (3) applying pattern '^/myapp/(.*)/common/(.*)' to uri '/myapp/folder1/common/mypage.jsp' (2) rewrite /myapp/folder1/common/mypage.jsp - /myapp/common/mypage.jsp (2) local path result: /myapp/common/mypage.jsp (1) go-ahead with /myapp/common/mypage.jsp [OK] The idea here is simple: the request /myapp/folder1/common/mypage.jsp should result in a request for /myapp/common/mypage.jsp The rewrite rule works great. This works great for static stuff served up by Apache. The problem is that Tomcat is not getting the translated request, it is getting the original one. Since no file in that path actually exists, naturally it returns a file not found error. Could someone please tell me if this behavior is correct or if this is a bug in mod_jk? Should I be using apj13? (I just noticed that the mod_jk.conf-auto has the contexts mounted to apj12 so I'll try changing that). I seem to recall that JServ obeyed the results of rewrites. Should I try using tomcat with mod_jserv? 'Would seem like walking backwards... Please help clear this up so I don't spend too much more time banging my head against this. Thanks, Mel __ Do You Yahoo!? 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]
Bug?[Tomcat 3.2.1] Or am I missing something...
Hi, I'm not sure what I'm missing here, but I'm running into a strange bit of behavior in Tomcat 3.2.1. I've got a jsp that uses classes in a jar file that is placed in the WEB-INF/lib folder like so: webapps/demo/simple.jsp webapps/demo/WEB-INF/lib/mylib.jar Early on one of the classes inside mylib.jar gets handed a reference to the ServletConfig object (as returned from javax.servlet.Servlet.getServletConfig()). At some point further on (through a sequence too complex to relate here just yet) this class invokes the 'getServletName()' method on the ServletConfig object using reflection (i.e. Method.invoke()). This results in an IllegalAccessException. Details are like so: com.g1440.naf.util.NFRuntimeException: com.g1440.naf.reflect.SimpleDecorator: illegal access attempt on : object = org.apache.tomcat.facade.ServletConfigImpl@5e83f9 : object class = org.apache.tomcat.facade.ServletConfigImpl : method = getServletContext : modifiers = public abstract : object class loader = sun.misc.Launcher$AppClassLoader@404536 : handler class loader = AdaptiveClassLoader( ) Nested Exception = java.lang.IllegalAccessException In the above diagnostics, 'handler' refers to the class that is simply calling (the equivalent of) ServletConfig cfg = getServletConfig(); ... Method.invoke(cfg,"getServletName",null); The 'ServletConfig.getServletName()' method is declared public in the API. Can anyone suggest to me why the above might be happening? I note that the implementation class: org.apache.tomcat.facade.ServletConfigImpl is declared package-level, (why?) but I wouldn't think this should affect my access to a public method. There seems to be some mumblings about access protection in the facade package but I'm not yet familiar with what is going on there yet. Any help is appreciated. As usual, I'm sure this is something boneheaded that I am doing wrong... Mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - 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
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. Some implementation details are: Configurable properties (loaded at startup and available through an extention of the Constants class): - default JSP_PACKAGE root (i.e. 'jsp_servlet') - PACKAGE_PREFIX string (i.e. '_') I've then created an extention of JspCompilerContext that adds method for deriving fully-qualified class names for the generated classes. Among these are assertion methods that force conformance with java naming conventions (allowed letters, disallowed keywords, etc) as described in the Java Language Specification. These two methods are: public static String manglePackageName(String s) and public static String mangleNameLetters(String s) Using these utilities and the above configurable properties I then have methods that actually derive the package and file names I need given a Jsp File. public static String buildPackageName(File file) let ifile/i correspond to the path "foo/somedir/myfile.jsp", JSP_PACKAGE="jsproot" and PACKAGE_PREFIX="x". In that case the return value would be "jsproot.xfoo.xsomedir". public static String buildClassName(File file) let ifile/i correspond to the path "foo/somedir/myfile.jsp", JSP_PACKAGE="jsproot" and PACKAGE_PREFIX="x". In that case the return value would be "xmyfile". public static String buildJavaFileName( String srcDir, String clsName) calculates the absolute filename for the .java file corresponding to the class clsName residing under the directory srcDir. For example if srcDir = "/opt/myapp/work" and clsName="jsproot.xfoo.xsomedir.myfile" then this returns the string "/opt/myapp/work/jsproot/xfoo/xsomedir/myfile.java" public static String buildClassFileName( String clsDir, String clsName) like buildJavaFileName() except result would be: "/opt/myapp/work/jsproot/xfoo/xsomedir/myfile.class" These static methods are used by the JspContext (which extends JspEngineContext) to derive the instance methods: public String getServletClassName() public String getServletPackageName() public String getFullJavaClassName() public String getServletJavaFileName() public String getServletClassFileName() The result is that you have a lot of control over the naming used by the generated classes. Further, the resulting .java files are much easier to find and look at when debugging. This mangling scheme does not do any incrementing because a new JspLoader is used each time a JSP gets reloaded dynamically. This package also provides a mechanism for recursively detecting changes to statically included JSP files. I would like to make this code available for integration into the jasper scheme but I will need to rename the packaging to something acceptable. As I mentioned before, the whole thing is implemented as an extension to Jasper, not a rewrite. Implementation should be as simple as re-registering the server to send *.jsp files to the JspServlet class in my extended package. A simplest option would to simply put the seven classes involved into a separate package like "org.apache.jasper.jspx". I've tested this thoroughly using the WebLogicServer as the servlet engine (bypassing their JSP compiler) and also New Atlanta's ServletExecDebugger. I am still setting up using the Tomcat Servlet Engine to try and test it there. I am having some unrelated difficulties there and will make a separate post on that. I've been working so far by extending the Jasper API as it exists in the tc 3.2.1 release. How mature is the 4.0 build? Should I I welcome queries on this code (I will share snippets in lew of the whole thing for now, if necessary) and suggestions on how to become more involved with the Jasper effort. Like all of you, my time is very tight, but this subject area is very important to my projects so I'd like to be involved as much as possible. Cheers, Dr. Mel Martinez Senior Software Architect G1440, Inc. [EMAIL PROTECTED] --- Glenn Nielsen [EMAIL PROTECTED] wrote: "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. That's true, but Steve Downey also found the spec reference I couldn't find (in Section 8.2 of the
Tomcat Setup and configuration
uld use my class as indicated above for servlet. However, it does not. At this point, I try making a variety of changes to the web.xml file, including registering my servlet class under a different name, changing url pattern servlet mappings and none of them seem to have any affect! I also tried putting the web.xml file into TOMCAT_HOME/conf instead, but that too does not seem to have any affect. Q: How do I get Tomcat to recognize the changes I make to the default web.xml file? Basically, I need to be able to change the servlet class used for *.jsp. Question #3 above is the most important to me. If anyone can help me out here, I would greatly appreciate it. Am I running into bugs already fixed in Tomcat 3.3 or 4.0? I will move to one of those builds if necessary, but that is not a preferred path because I don't like to tell my customers I'm deploying them with experimental code! :-) Thanks, Dr. Mel Martinez Senior Software Architect G1440, Inc. [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
Costin - Thanks a ton for your reply. Very helpful.
--- [EMAIL PROTECTED] wrote:
The intention ( in tc3.3 ) is to make all the
configurations "explicit",
instead of using conventions like "webapps will be
in home, libs in
install, etc".
This sound great. I am a big proponent of explicit
configuration (with implicit defaults, of course).
For issue #1, it's a bug - logs are "special" in 3.2
and they were not
made relative to the home. The workaround is to use
explicit paths.
In 3.3, the logs are corectly set relative to
TOMCAT_HOME.
Shouldn't they be by default set relative to the
application home? I.E. if we have one install of
tomcat on the system, (TOMCAT_HOME =
/opt/local/tomcat) and we have two different
applications on the box (using, perhaps different
ports) with different server.xml files and
ContextManager 'home' attributes), the log output
should be consider 'of the application' in each case
and should be implicitely written to paths relative to
the application 'home', not into TOMCAT_HOME. This
is simple OO partitioning of responsibilities.
If nobody objects to the config changes I'll also
add the ant-style syntax
for ${properties}, so you'll have more flexibility.
No objection. Sounds like a good idea. The
${property} syntax is consistent with the Security
Manager policy file format as well. I've implemented
it in my own application's configuration file scheme.
Down the road an include mechanism would be a good
idea to add as well (i.e. add a server.xml element
server-include which could take a path (or even a
URL) to an external config file that could be imported
into the DOM). Having built this sort of thing
before, I realize this not trivial (recursion,
protocol for conflict resolution, etc.) but the value
is high.
Issue #2 ( conf dir ) - again, in 3.3 most if this
is configurable via
individual module options. For example the
apache.conf is generated by a
module - and you'll be able to set the location to
anything you want
( or any other properties that affect its behavior )
Is this available in the current 3.3 milestone or
nightly builds?
Regarding Issue #3 - the web.xml is not used in
tomcat3.2,
and will not be used in tomcat3.3. All the server
config
is done using server.xml ( and the new context.xml )
files.
That sounds great. At least I now know what is (not)
going on! :-)
Q1: Why does it say in the documentation that
conf/web.xml is used as a default? Needs to be
corrected.
Q2: More importantly, I'm still left with: How do I
configure the use of a different servlet to handle
*.jsp requests?
Server.xml sets server behavior. For example, the
conversion between .jsp and java is a server
property.
The static interceptor is a server property.
Everything
that is not defined in the web.dtd belongs in
server.xml,
and it's specific to tomcat. What is defined in
web.dtd
and the spec belongs to WEB-INF/web.xml.
Okay, so it sounds like I need to reconfigure the
StaticInterceptor module. And I would do this... how?
Is this possible on 3.2.1 or do I need to go to 3.3
for this? Could someone point me in the right
direction here?
Thanks again for your help.
Mel
__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
--- [EMAIL PROTECTED] wrote: Ok, this is a clear example of what's wrong with the current status - there are 2 directories that can be set on ContextManager, one is "home" and the other one is "installDir". The env. variable is used to set home. Where is this stuff documented? There doesn't seem to be a DTD for server.xml. If one is set and the other not - both share the same value. InstallDir is the one used for jar files ( and all "shared" files ). home is supposed to be used for the local instance. ( the model is again a shared installation - /usr/local or /opt/tomcat and each user having it's own config and set of applications ). so you seem to be saying that one would set InstallDir - TOMCAT_HOME and home - APP_HOME. I'll test that out. By using explicit paths we can accomodate more use cases and be very clear about what goes where. yup. Down the road an include mechanism would be a good No need, it's already done ( and in 3.2 too ). Luv it. Thanks for pointing that out. One of the goals for 3.3 release is to have all those small things that makes configuration easy ( as usability enhancements ). These issues directly affect configuration management and are critical for managing complex deployments. I don't think enough people take this area seriously enough (code features now, worry about deployment later!). Q2: More importantly, I'm still left with: How do I configure the use of a different servlet to handle *.jsp requests? In 3.3 - in JspInterceptor you have "useJspServlet" and "jspServlet" that allows you to specify it on a global level ( or per context ! ). This is strongly discuraged - as it'll be much slower than using JspInterceptor's optimizations. Why exactly would it be 'much' slower? Does that presume that a custom JspServlet would be inherently slower or that the default org.apache.jasper.runtime.JspServlet is somehow accellerated by something JspInterceptor does? Hypothetical: If I were to modify org.apache.jasper.runtime.JspServlet (or make a replacement and pre-load it in the CLASSPATH) would that be 'much slower' (even though it should not require setting the 'useJspServlet' tag since it would appear to be the regular default class)? Just curious about your statement. If your jsp processor does something special, you can bundle it with your application and use the web.xml ( from WEB-INF ) to set it. Then your app will work on any container the way you expect. This may be suitable for some situations, but I have other situations where I need to have complete control over what JSP compiler is used by the servlet engine. This sort of configuration (specifying what servlet to route a request to) is easy with JServ, WebLogic Server and other servlet engines. I'm not sure why it shouldn't be just as simple on Tomcat. Especially since fundamentally Jasper is a standalone servlet package that runs fine on other servlet engines than Tomcat. One should be able to plug-in a different JSP processing servlet (or any default servlet) with no more work than changing a line in a configuration file. It sounds like 3.3 brings this ease in the JspInterceptor. I'm pretty intimate with the Jasper API, but still learning the Tomcat API. I'm still working on understanding how the Connector and Interceptor patterns are implemented. Thanks again for the help. Cheers, mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Common Session code 3.3/4.0 (was: [VOTE] New Committer: Kief Morris)
--- [EMAIL PROTECTED] wrote: IMHO it would be a mistake to write a session manager using the same abstractions as in a servlet container - after all the task is to store data and the requirements are pretty specific ) I'd like to poke my $.02 in and say I totally agree with Costin. The only 'connection' required between the servlet container apis and persistent session management is state maintenance, which can be encapsulated in some sort of session identifier (i.e. cookie typically) which can be built independent of the actual container by using the standard servlet APIs (v 2.2 is sufficient). Other than that, the actual implementation of a persistant session managment API does not have to have anything to do with the servlet container or even the servlet API. I have built such a beast and it is, as Costin advocates, independent of servlet container. It is proprietary, so I can't give it to the project, but the basic principal is simple: 1 - Use the standard servlet API's to establish a 'session identifier' (cookies work fine for 90% of the browser world out there). 2 - use this as a key into your persistant session store. Naturally, there are some other details involving assertaining the 'active' or inactive state of the session, time out of session ids,authentication controls, etc., but even all that does not have to depend on the servlet container. You should come up with a scheme that is pluggable as to where the actual data is stored (i.e. disk files vs (shared) RDBMS vs whatever). Just my $.02. Mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat Setup and configuration
--- [EMAIL PROTECTED] wrote: No, the overhead of using a servlet to invoke the jsp page is significant ( at least in my tests is shows a big difference ). JspInterceptor does a simple thing - after the jsp page is compiled to a servlet, the servlet will be "registered" to tomcat ( as if it was declared in web.xml ) and after that all invocations to the jsp page are identical with invocations for servlets ( with one exception - jsp_precompile param must be read on each request and if present, the request shouldn't be executed - that's the spec ). This almost implies some special behavior on the part of the base HttpJspPage class (i.e. 'JspBase') used to build the jsp servlet. Is that so? Is there any problem for jsp pages that use the %@page extends=... tag that don't extend org.apache.jasper.runtime.JspBase but rather instead (as per spec) simply implement javax.servlet.jsp.HttpJspPage? One of the things that really gripes me about the WebLogic JSP servlet engine and JSP compiler is that it has dependencies on the proprietary base class used to generate JSP servlets. There are a lot of problems with this so I hope that we don't send tomcat/jasper down that road. Try it yourself, send back the results :-) ( ab -n 1 -c 80 http://localhost:8080/foo.jsp with JspInterceptor in both modes ). ( useJspServlet means JspInterceptor will do nothing, just return ). ( of course, you can compare 3.3 with JspInterceptor with 3.2.1 without it - but there are other factors in that) It looks like I'll need to get the 3.3 version to try this out! :-) Thanks again, Costin. mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - 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
--- 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? Mel __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 SecurityManager and Jasper ClassLoader changes
--- 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]
Re: Tomcat 4 Jasper ClassLoading changes to support SecurityManager
I have done some work in this area that may be of
interest. I've created a package of 8 classes that
extend the Jasper compiler (as of Tomca 3.2.1) to
provide:
- dynamic recompiling/reloading of jsp pages
- recursive detection of changes to static includes
- support for inner classes
- customizable name mangling (giving finer control
over the package and class names of .java and
.class files generated
- configurable top-level package name
and a few other features. The result seems fairly
robust and not dependent on the any particular servlet
engine (I'm running it as a servlet to replace the jsp
compiler in WebLogic Server which has some design
problems that interfere with my project goals).
I achieved these features by simply extending the
existing API as of v 3.2.1, although from what I can
tell, there should be no problem using tomcat 4.0 as
well.
Motivation for doing it this way instead of rewriting
the jasper classes directly and submitting changes to
the project is chiefly time-constraints. I needed the
features for my own projects and I did not have time
to go through becoming more properly involved. My
reasoning was that at this point, I could count on
certain aspects of the API that are common to both
v3.2.1 and v4.0 to be fixed so it was safest and
quickest to simply extend from there without having to
risk conflicts with any internal changes other folks
might be making.
The total amount of code is small, only about 17k
lines across the 8 files in the package which are :
package com.g1440.naf.j2ee.jsp;
JspBase - extends HttpServlet implements HttpJspPage
JspCompiler - extends Compiler implements Mangler
JspConstants - extends Constants
JspContext - extends JspEngineContext
JspLoader - extends JasperLoader
JspOptions *
JspPageHandler - replaces JspServletWrapper
JspServlet - extends JspServlet
* - original intention was for JspOptions to extend
EmbeddedServletOptions but for some reason that class
is final. Not a major problem in reality.
The result needs to have some proprietary code (mostly
debug and configuration related) removed and perhaps
given a package rename to be generally useable. I'm
open to suggestions on how best to manage this.
The key point for my own self-interest here (and why
I'm piping up with this at this point) are that no
changes should occur to the existing Jasper API that
would conflict with this extension. Other than that,
the above does not have to be 'merged' with Jasper's
current codebase but could continue to exist as a
separate entity. However, I would like others to
share in the benefits. The code quality is good, with
extensive javadocs. Some effort would need to be put
into repackaging to pull it out of my current project,
so I can't turn it all over on a dime (I'm pretty
freakin' busy these days), but it was written with
that eventual goal in mind. If it is just considered
a distraction, I can disappear quietly back into the
darkness... :-)
While I've got your attention, btw, I'd like to toss a
design question out there:
Currently, the java code generated by the JSP compiler
places the scriptlet code inside _jspService() inside
a try{...}catch(Exception... block. The catch passes
the caught Exception to the page context
handlePageException() method.
Although I believe this is within the JSP spec, I kind
of object to indescriminant blockage of the Exception
class like this. It interferes with one's ability to
use custom RuntimeExceptions that one needs to
communicate up to a parent HttpJspPage base class.
I would like some mechanism to override the page
catch() block to not process certain exception classes
and simply toss them up like they were meant to be.
This could be handled by a configuration property that
lists the Exception types to ignore or some other
configurable mechanism. I suppose one can override
the handlePageException() but this does not seem
optimal.
Looking forward to feedback,
Dr. Mel Martinez
Software Architect
G1440, Inc.
[EMAIL PROTECTED]
--- "Craig R. McClanahan"
[EMAIL PROTECTED] 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 e
RE: An alternative to JSP
Brad Cox [mailto:[EMAIL PROTECTED]] wrote:
At 11:03 AM -0800 01/25/2001, Mel Martinez wrote:
That presumes the line termination
character of choice for the output is a linefeed
character.
Good point. Will fix when I get a moment.
Another issue is that the example creates catenated
String literals. I would hope that the actual code
produced would use appropriately initialized
StringBuffers or performance could be a problem.
I've been assuming that concatenation of constants is collapsed
at compile time. I'm sure this is true for SOME compilers but
less sure this is true across the board. Could you elaborate
on this point?
Concatenation of non-constants is, of course, a different
matter. I do use StringBuffers for these.
Dangerous to put too much faith in compilers, eh? :-)
In general, for any code that is catenating strings, als
msg = "some string" + param + "some other string";
it is usually faster to use a StringBuffer like so:
msg = new StringBuffer();
msg.append("some string").append(param).append("some other string");
However, that in itself does not necessarily improve performance. The
StringBuffer class defaults to a size of only 16 chars. Thus, as soon as
the catenation result exceeds 16 chars, it has to reallocate the internal
buffer. If you then exceed the new size (it will double in size or go to
just large enough to hold the new data, whichever is larger) on a subsequent
append, it will have to reallocate again, and again. Adding 10 chars at a
time to a StringBuffer will cause 3 reallocations by the time
you get to a hundred characters. Actual performance impact will depend on
your particular application and the nature of the data.
So basically operations that add lots of small chunks adding up to a much
larger whole, will force numerous reallocations up until you've catenated
just over half the data at which point it will finally bump up to enough
room for the entire result.
Given this tidbit of knowledge, you should try to anticipate how large the
final StringBuffer needs to be to hold the entire result. You don't have to
hit it exact, and if you make it too large, you may run up against memory
constraints (depends on your application and runtime).
My suggestion is to try to guess the halfway mark. That way, you won't be
wasting too much memory, but will significantly reduce the number of buffer
reallocations (which cost a call the System.arraycopy() each time!).
So in the above example, suppose I can anticipate that the non-constant
Strings are going to be on the order of ~25 chars and that the constant
strings add up to about 75 so that my final String will be around ~100
chars. If I initialize the StringBuffer to about 64 chars, I can be sure
that it won't resize more than once. If memory is not a problem, then I
might go for the fastest situation and just do something like
msg = new StringBuffer(128);
so that I can be fairly sure I won't be reallocating.
I hope that this is helpful. Actual mileage may vary.
I'll defer for now on the relative merits of JSP versus other schemes. I've
got too many other things to worry about.
Cheers,
Dr. Mel Martinezmailto:[EMAIL PROTECTED]
Software Architect phone:410-423-3931
G1440, Inc. http://www.g1440.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
