problems building the tomcat Source
I have been trying to build the Source for Tomcat but an error creeps up. Exception in thread "main" java.lang.NoClassDefFoundError: sun/tools/javac/Main at org.apache.tools.ant.taskdefs.Javac.doClassicCompile(Javac.java:218) at org.apache.tools.ant.taskdefs.Javac.execute(Target.java:120) I have downloaded and installed jdk1.3 tomcat source 3.1.1 jakarta-ant jakarta-tools all in the same directory. running on Win98 system Anybody has any Idea what the problem could be. Any help would will be appreciated Thanks Anil Oommen Technical Member [EMAIL PROTECTED]
Re: JDBC-Session store
Craig R. McClanahan typed the following on 07:05 PM 3/27/2001 -0800 Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? Yes, in fact I was just working on this last week, playing around with different ways of attacking this. Replacing dependencies on StandardManager, StandardSession with dependencies on the Manager and Session interfaces is relatively easy, with a few additions to the interfaces required. Another problem I've been tackling is the architecture of the Manager hierarchy. The problem is that there is code currently in StandardManager which is needed by (and currently, duplicated in) PersistentManager, which isn't good for maintenance. StandardManager implements the Lifecycle interface and functionality to expire sessions with a background thread. These are also used by PersistentManager, with the session management code being extended to handle swapping out idle sessions and similar tasks. Currently, StandardManager also has persistence code, which is used only to handle saving sessions on restarts. This code doesn't use the Store system. There are two approaches which seem like they would address this. One solution is to make StandardManager and PersistentManager subclasses of a common superclass with the functionality common to both. Another is to make PersistentManager a subclass of StandardManager. The first approach, making a hierarchy, appeals to me because it makes it easier to experiment with alternative session managers. DistributedManager would become a sibling to StandardManager and PersistentManager. This solution requires either moving the common functionality into the ManagerBase class, or creating an intermediary abstract class. The second approach allows the ManagerBase to remain a clean implementation of the Manager interface, although it extends the hierarchy an extra level. The second approach doesn't appeal to me, mainly because it seems likely to get a bit muddled over time. Either way, another issue I see is that StandardManager, as long as it supports persistence on restarts, is going to use a fair amount of the code from PersistentManager. This isn't necessarily a bad thing, it will keep PersistentManager fairly simple. But I would prefer to make it easy to develop a fully working Manager which doesn't include any persistence whatsoever: either StandardManager could have this (requiring users who want restart persistence to use PersistentManager), or there could be a separate SimpleManager. The first of the two solutions: making StandardManager and PersistentManager siblings rather than one a subclass of the other, seems likely to offer cleaner support for a StandardManager without persistence and/or a SimpleManager. Once the beta is tagged (this weekend?) I can start committing some work on this. Kief
RE: problems building the tomcat Source
do you have tools.jar on your classpath? c:\jdk1.3\lib\tools.jar Kevin Jones DevelopMentor www.develop.com -Original Message- From: Anil [mailto:[EMAIL PROTECTED]] Sent: 28 March 2001 10:23 To: [EMAIL PROTECTED] Subject: problems building the tomcat Source I have been trying to build the Source for Tomcat but an error creeps up. Exception in thread "main" java.lang.NoClassDefFoundError: sun/tools/javac/Main at org.apache.tools.ant.taskdefs.Javac.doClassicCompile(Javac.java:218) at org.apache.tools.ant.taskdefs.Javac.execute(Target.java:120) I have downloaded and installed jdk1.3 tomcat source 3.1.1 jakarta-ant jakarta-tools all in the same directory. running on Win98 system Anybody has any Idea what the problem could be. Any help would will be appreciated Thanks Anil Oommen Technical Member [EMAIL PROTECTED]
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] So far jasper has been one of the most stable pieces on tomcat ( most bugs I know about are related with the interfacing between jasper and the container ). And it has a huge potential for performance improvement - if we do the right refactoring and provide the right internal APIs. Costin 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. 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.
What does this jk_ call do?
I'm trying to trace down why I'm getting a failure on load.
Here's the section of code that throws the error.
CODE SOURCE="jk_jni_worker.c"
if(jk_get_worker_jvm_path(props, p-name, str_config)) {
p-jvm_dll_path = jk_pool_strdup(p-p, str_config);
}
if(!p-jvm_dll_path || !jk_file_exists(p-jvm_dll_path)) {
jk_log(l, JK_LOG_EMERG, "Fail- no jvm_dll_path\n");
return JK_FALSE;
}
/CODE
Although the JVM's directory is in my path, it seems that this
fails. One--I don't know if the file doesn't exist or the
char * jvm_dll_path is null (next time, break the debug info out!),
but regardless, my Tomcat installation (using IIS 5 and the
isape_redirector) throws this error before even starting.
So, if you can tell me what the call does, then I can look on
my system to see if I've got some ungodly config issue.
Of course, all help is MUCHO appreciated.
--
. . . powerlifter
lift 'til your eyez bleed
365 bench - 505 deadlift - 515 squat
SSL-Keytool Problem
Hi, Nell, You need a RSA provider. You can download a SunJSSE RSA provider which is free from the java.sun home site. After installing the JSSE, you need to copy the lib/*.jar to the jre's lib/ext directory. I am pretty sure this will work. Forrest
[FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
The "Proposed Tomcat 4.0-Beta-2 Code Freeze Date" thread started on the 19th and fizzled out without any publicly visible conclusions. The suggested tag date, i.e. the 22nd, has passed and no new one has been proposed. Sorry to be pushy but is there a new consensus as to when to tag. As far as I could see only Glenn strongly opposed the 22nd date and I got the impression he could be talked out of it. It's been quite a while since beta 1 and the viewing public anxiously awaits a new release :-) Yours, George. PS does anyone else feel that a once a week status report would be a really good idea - nothing too big just a few lines from Craig say on what he felt had been achieved in the last week, general feelings on progess and non-binding comments on possible future beta/milestone dates? This would keep nuisances like me from posting this kind of thing and give everyone a feeling they knew how and where things were going. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: JDBC-Session store
Kief Morris wrote: Excellent! Let us know if you need any help. I will, BTW how is the work on distributed sessions coming along? Is it possible to distribute sessions over x number of machines and that if one goes down you could go to the other and happily continue your session? ..bip
Re: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
On 27 Mar, George C. Hawkins wrote: PS does anyone else feel that a once a week status report would be a really good idea - nothing too big just a few lines from Craig say on what he felt had been achieved in the last week, general feelings on progess and non-binding comments on possible future beta/milestone dates? This would keep nuisances like me from posting this kind of thing and give everyone a feeling they knew how and where things were going. You sound like a manager talking. I have lots of status from Craig. I see his CVS updates and all of the conversations he is involved on this list. To specifically write a status report would seem to me to be a bit much to ask. Further I can see Tomcat improve with my nightly update of the cvs tree. -1 on status reports =eas=
Re: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
On 27 Mar, George C. Hawkins wrote: PS does anyone else feel that a once a week status report would be a really good idea - nothing too big just a few lines from Craig say on what he felt had been achieved in the last week, general feelings on progess and non-binding comments on possible future beta/milestone dates? This would keep nuisances like me from posting this kind of thing and give everyone a feeling they knew how and where things were going. You sound like a manager talking. I have lots of status from Craig. I see his CVS updates and all of the conversations he is involved on this list. To specifically write a status report would seem to me to be a bit much to ask. Further I can see Tomcat improve with my nightly update of the cvs tree. At this point, I would recommend using the nightly builds until b2 is released, if you're interested in trying out TC4. Remy
Status of JSVC ?
Hi All, Hope all is going well around the globe. Just wanted to ask about the status of the jsvc code in TC4.0 branch ? What is the future/direction of this code ? I've been able to successfully patch TC3.2 so that it behaves correctly when sent UNIX TERM and KILL signals via the apache Service interface and jsvc - but I don't want to spend too much time here if there is no foreseen use of the code (or if there is a replacement in the works ? jsr096 ?) Any information is appreciated. Cheers, Marcus -- . ,,$, Marcus Crafter ;$' ':Computer Systems Engineer $: : Open Software Associates GmbH $ o_)$$$: 82-84 Mainzer Landstrasse ;$,_/\ :' 60327 Frankfurt Germany ' /( \_' Email : [EMAIL PROTECTED] .Business Hours : +49 69 9757 200 : After Hours: +49 69 49086750
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
Yes - from my experience, this was the problem deploying Jasper in another container. Tim Julien HP Middleware -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 11:33 AM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] So far jasper has been one of the most stable pieces on tomcat ( most bugs I know about are related with the interfacing between jasper and the container ). And it has a huge potential for performance improvement - if we do the right refactoring and provide the right internal APIs. Costin 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. 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.
standard test apps
Are there standard test apps for testing a Servlet container? I am running watchdog, and several struts apps; Java pet store requires EJB's, so thats no good. Any known apps out there that are either standard or opensource? Tim Julien HP middleware
Re: Filters and Transfer-Encoding: chunked
- Original Message - From: "Robert Petersen" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 27, 2001 3:20 AM Subject: Filters and Transfer-Encoding: chunked I am facing a problem when useing a filter. The problem is that the "Transfer-Encoding" header does not appear to be getting set. In this case the filter is doing some simple xsl transformations and passing on the results to the response's output stream. Unfortunatly because the content is not being chunked by Tomcat the socket just sits there open. I'm not sure how tomcat knows to chunk the data. When working with an unfiltered jsp page the data gets chunked as expected. Does the filter need to do anything to "chunk" the data? No, I don't think so. I was able to use filter to set different headers including "Content-Encoding" to write out to the response's outputstream just fine. Hope this help. Cheers, Amy Thanks, Robert Petersen
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. Costin ( BTW, my interest is more in the jsp-java convertor area, I would be interested to try a more customizable generator that would use XSL templates, but that depends on a modularization and refactoring that would make the generator a clear and replaceable component. This is a long-term plan, of course - some people will kill me if I don't start working on charsets and encodings )
RE: Listeners
On Wed, 28 Mar 2001, Kevin Jones wrote: Here's the rationale for this behavior (and the fact that Tomcat also marks the app unavailable if it didn't initialize all the listeners and filters successfully): But it doesn't, at least not in the latest nightly. I have a listener configured and the class file is missing. Tomcat seems not to have initialised any of the listeners but the application is still available. That's a bug. The intent was to mark the app as unavailable in that circumstance. Let's say you are implementing user authentication yourself, and using filters. You specify connection information to a database in your filter params, but mistype the password so that the connection cannot be established, so your filter's init() method throws an exception. If Tomcat just logged this as a warning and went on deploying your app, it would now be running with *no* authentication, potentially exposing sensitive information. Is that what you *really* want to have happen? One might argue missing listeners would be less severe a risk than missing filters, but IMHO that isn't the container's judgement to make -- the user has an incomplete application deployed; better to make them go fix it rather than trying to run only part of it. But it is a judgement the container is making - In my app it doesn't matter much if the filters/listeners are missing. I would argue that for listeners the behaviour should be the same as for load-on-startup servlets and that the principle of least surprise would be applied. I would guess that initially most listeners would be ported from load-on-startup servlets (mine are), of one of those servlets was missing the application still started, and the servlets still executed. Least surprise tells me that listeners should behave the same way. Is there some way we could configure this in server.xml or do you think that is overkill. In the absence of spec requirements one way or the other, that is probably rational -- adding an attribute on Context (and DefaultContext)) that defines this would not be terribly difficult. BTW should we also add a note in the spec. about this? Who is "we" ? :-) We can certainly communicate that suggestion to [EMAIL PROTECTED] and to the expert group. Kevin Jones DevelopMentor www.develop.com Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 28 March 2001 04:14 To: Tomcat-Dev Subject: Re: Listeners On Tue, 27 Mar 2001, Kevin Jones wrote: Tomcat 4.0 stops configuring listeners if one of the listeners in the list isn't present, should it carry on configuring the rest of the listeners it finds? The spec is silent on this and it seems odd that if somebody (maybe accidentally) deletes a listener class all other following listeners are not configured (any listener preceding the missing listener would already have been initialised). Here's the rationale for this behavior (and the fact that Tomcat also marks the app unavailable if it didn't initialize all the listeners and filters successfully): Let's say you are implementing user authentication yourself, and using filters. You specify connection information to a database in your filter params, but mistype the password so that the connection cannot be established, so your filter's init() method throws an exception. If Tomcat just logged this as a warning and went on deploying your app, it would now be running with *no* authentication, potentially exposing sensitive information. Is that what you *really* want to have happen? One might argue missing listeners would be less severe a risk than missing filters, but IMHO that isn't the container's judgement to make -- the user has an incomplete application deployed; better to make them go fix it rather than trying to run only part of it. I've also raised this as a bug, Thanks, Kevin Craig
Re: FW: Tomcat 4 service
On Wed, 28 Mar 2001, Kevin Jones wrote: I posted this to tomcat-user with no response. Does such a beast exist? If not I'll volunteer to port the Tomcat 3.2 code. Just point me at it! There is some basic code aimed at allowing the creation of such a beast in the "service" directory of the source repository. Besides just being able to start and stop Tomcat as a service, one of the goals is to interact with the connector startup so we can run Tomcat 4 on port 80 without having to be root. This will require a couple of changes to the Connector interface as well as a Tomcat-4 specific version of the service startup stuff. It would be great if you wanted to work on this! Kevin Jones DevelopMentor www.develop.com Craig -Original Message- From: Kevin Jones [mailto:[EMAIL PROTECTED]] Sent: 27 March 2001 22:44 To: Tomcat-User Subject: Tomcat 4 service I have tomcat 3.2 running as a service under W2K. I seem to remember that this wasn't available for Tomcat 4 (running it as a service that is), or is the code now available? Thanks, Kevin Jones DevelopMentor www.develop.com
Re: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
On Tue, 27 Mar 2001, George C. Hawkins wrote: The "Proposed Tomcat 4.0-Beta-2 Code Freeze Date" thread started on the 19th and fizzled out without any publicly visible conclusions. The suggested tag date, i.e. the 22nd, has passed and no new one has been proposed. Sorry to be pushy but is there a new consensus as to when to tag. As far as I could see only Glenn strongly opposed the 22nd date and I got the impression he could be talked out of it. It's been quite a while since beta 1 and the viewing public anxiously awaits a new release :-) Yours, It was asked that we hold off for a bit. Would doing the release this Friday meet everyone's preferences? If so, I will go ahead and submit the vote request formally. George. PS does anyone else feel that a once a week status report would be a really good idea - nothing too big just a few lines from Craig say on what he felt had been achieved in the last week, general feelings on progess and non-binding comments on possible future beta/milestone dates? This would keep nuisances like me from posting this kind of thing and give everyone a feeling they knew how and where things were going. There are bad pests in the world, but you're being a good pest here :-). I will try to keep everyone more up to date. Just as a warning, I've got one more incredibly busy couple of weeks (O'Reilly Enterprise Java Conference this week and ApacheCon next week) that will interfere with the volume of my contributions. Craig
Re: standard test apps
On Wed, 28 Mar 2001, Julien, Timothy wrote: Are there standard test apps for testing a Servlet container? I am running watchdog, and several struts apps; Java pet store requires EJB's, so thats no good. Any known apps out there that are either standard or opensource? It's not formally a test app, but experience with Struts says that the ability to run the Struts example app "out of the box" is a pretty useful real world compatibility test :-). Both development branches of Tomcat also have some unit tests within their own source hierarchies (in Tomcat 4 it is the "tester" subdirectory). Some of the tests are specific to Tomcat, but most of them should work on any servlet container that has the appropriate set of webapps configured. Tim Julien HP middleware Craig
Embedded and Classpath
When I instantiate Catalina's Embedded class from within my application, shouldn't it automatically inherit my application's classpath? I've tried mapping a servlet that is part of my application's package to a URL pattern and it fails with an IllegalArgumentException saying "servlet mapping specifies an unknown servlet name [name_of_servlet]". My goal is to allow access to a servlet that is part of a package which for numerous reasons cannot live within the webapps directory tree. Is there any way to do this? I'm using 4.0 b1 TIA Klaus Sonnenleiter
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
-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.
Re: JDBC-Session store
Bip Thelin typed the following on 05:07 PM 3/27/2001 -0800 Kief Morris wrote: Excellent! Let us know if you need any help. I will, BTW how is the work on distributed sessions coming along? Is it possible to distribute sessions over x number of machines and that if one goes down you could go to the other and happily continue your session? No, we're much earlier in the development cycle than that - we haven't implemented any distributed session support at all. The work we're doing on PersistentManager is groundwork for distributed sessions. This work is 90% finished, so after restructuring the relevant class hierarchy a bit and finishing PersistentManager, we'll be ready to tackle DistributedManager. The session management system consists of implementations of the Manager, Session, and Store interfaces found in the root org.apache.catalina package. When we finish with it, we should have three implementations of Manager: StandardManager, PersistentManager, and DistributedManager. Any Store implementations should, in theory, be usable by either of the second two. So your JDBCStore class, if it works with PersistentManager, should also work with DistributedManager. The only difference is how the Store is used by the Manager: PersistentManager only stores the sessions of one JVM, while DistributedManager will store them for multiple JVMs. In reality, I suspect that DistributedManager will require changes to the current Store interface, so if you implement JDBCManager now and get it working with PersistentManager, it may have to be updated as we work on DistributedManager. If you want to help with DistributedManager, doing JDBCStore might be a good first step for you to get your head into the code. One issue I haven't figured out yet is how to configure Catalina to use different Store implementations - PersistentManager currently has FileStore hard-coded. If you want to dig into that it would be a bonus. Catalina's configuration system is really slick. There should be some messages of mine from a few months ago in the archive for this list where I puzzled over some of the particular issues of implementing DistributedManager which may or may not be worth looking over. Kief
Re: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
Craig R. McClanahan typed the following on 01:23 PM 3/28/2001 -0800 It's been quite a while since beta 1 and the viewing public anxiously awaits a new release :-) It was asked that we hold off for a bit. Would doing the release this Friday meet everyone's preferences? If so, I will go ahead and submit the vote request formally. What are the issues for holding off? Kief
RE: JDBC-Session store
-Original Message- Bip Thelin typed the following on 05:07 PM 3/27/2001 -0800 Kief Morris wrote: Excellent! Let us know if you need any help. I will, BTW how is the work on distributed sessions coming along? Is it possible to distribute sessions over x number of machines and that if one goes down you could go to the other and happily continue your session? No, we're much earlier in the development cycle than that - we haven't implemented any distributed session support at all. The work we're doing on PersistentManager is groundwork for distributed sessions. This work is 90% finished, so after restructuring the relevant class hierarchy a bit and finishing PersistentManager, we'll be ready to tackle DistributedManager. What is schedule for these two nice managers? Tomcat 4.1, maybe?
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: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
- Original Message - From: "Kief Morris" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 28, 2001 3:32 PM Subject: Re: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date? Craig R. McClanahan typed the following on 01:23 PM 3/28/2001 -0800 It's been quite a while since beta 1 and the viewing public anxiously awaits a new release :-) It was asked that we hold off for a bit. Would doing the release this Friday meet everyone's preferences? If so, I will go ahead and submit the vote request formally. What are the issues for holding off? I believe that someone is working on the "sealing viloation" fix that he wanted to include in beta 2. Amy Kief
URL-Rewriting with mod_SSL
Hello , I have wrote some Java Servlets, that works with Session Tracking. I use the response.encodeURL Methode for it. when the client has disabled cookies, the jsessionID is suffixed. Thats fine ;-) this will work with Tomcat , and Tomcat over Apache. Now, when I User mod_ssl for the connection, the jsessionID is gone, an no session traking is possible without cookies. My System is : Apache 1.3.17-10, jdk 1.3.0 ,mod_ssl-2.7.1-0, jakarta-tomcat 3.2.1 and I've tried jakarta-Tomcat3.2.2b2 Has someone the same experience, some workaround or so ?? plz write brack, it's urgently and very important, thank you for inconvenience, Michael [EMAIL PROTECTED]
Re: JDBC-Session store
"Craig R. McClanahan" wrote: [...] Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? I couldn't find anything about how to add the PersistenManager in server.xml or in the manuals, however, after backtracking the maillist I found a "patch" by Kief that seems to have been forgotten, I'll cat it to the end of this mail. Maybe it can find it's way into the server.xml after all. Cheers, Bip --[ server.xml patch from Kief Morris ] --- server.xml.orig Sat Dec 16 20:03:29 2000 +++ server.xml Fri Jan 12 22:01:04 2001 @@ -179,6 +179,53 @@ Ejb name="ejb/EmplRecord" type="Entity" home="com.wombat.empl.EmployeeRecordHome" remote="com.wombat.empl.EmployeeRecord"/ +!-- + PersistentManager + Uncomment the section below to test Persistent Sessions. + + saveOnRestart: If true, all active sessions will be saved + to the Store when Catalina is shutdown, regardless of + other settings. All Sessions found in the Store will +be + loaded on startup. Sessions past their expiration are + ignored in both cases. + maxActiveSessions: If 0 or greater, having too many active + sessions will result in some being swapped out. +minIdleSwap + limits this. -1 means unlimited sessions are allowed. + 0 means sessions will almost always be swapped out +after + use - this will be noticeably slow for your users. + minIdleSwap: Sessions must be idle for at least this long + (in seconds) before they will be swapped out due to + maxActiveSessions. This avoids thrashing when the site +is + highly active. -1 or 0 means there is no minimum - +sessions + can be swapped out at any time. + maxIdleSwap: Sessions will be swapped out if idle for this + long (in seconds). If minIdleSwap is higher, then it +will + override this. This isn't exact: it is checked +periodically. + -1 means sessions won't be swapped out for this reason, + although they may be swapped out for maxActiveSessions. + If set to = 0, guarantees that all sessions found in +the + Store will be loaded on startup. + maxIdleBackup: Sessions will be backed up (saved to the Store, + but left in active memory) if idle for this long (in +seconds), + and all sessions found in the Store will be loaded on +startup. + If set to -1 sessions will not be backed up, 0 means +they + should be backed up shortly after being used. + + To clear sessions from the Store, set maxActiveSessions, +maxIdleSwap, + and minIdleBackup all to -1, saveOnRestart to false, then +restart + Catalina. + -- + !-- + Manager className="org.apache.catalina.session.PersistentManager" + debug="0" + saveOnRestart="true" + maxActiveSessions="-1" + minIdleSwap="-1" + maxIdleSwap="-1" + maxIdleBackup="-1" + Store className="org.apache.catalina.session.FileStore"/ + /Manager + -- Environment name="maxExemptions" type="java.lang.Integer" value="15"/ Parameter name="context.param.name" value="context.param.value"
[PATCH] HttpRequestAdapter returns wrong server port for a standanlone httpS connection
Hi
i've found a little bug (Tomcat 3.2.1) in the
src/share/org/apache/tomcat/service/http/HttpRequestAdapter.java
file.
Bug Description:
if you are running tomcat in standalone mode as user ,root'
with JSSE (Java Secure Socket Extension) on port 443 you
have URLs like:
https://some.host/your/uri.html
in this case ,request.getServerPort()' returns 80 and not 443
[PATCH]
Method getServerPort() line 263... looks like
else{
serverPort=80;
}
changed to:
else
{
if ( this.getScheme().equals( "https" ))
{
serverPort=443;
}
else
{
serverPort=80;
}
}
bye
- Thorsten
PS: I'm not subscribed to this mailing list so i don't read any
reply on this mail to this list.
_
__
/___ ___/|
|__/ /|__|/Thorsten Ludewig
/ / / /|
/__/ / / / Home Page: http://www.fh-wolfenbuettel.de/~th/
|__|/ /_/ E-Mail: [EMAIL PROTECTED]
/_/| Phone: +49 5331 939 488
|_|/ FAX: +49 5331 939 482
Re: JDBC-Session store
Grr, seems my message got stuck somewhere so I'll resend it. "Craig R. McClanahan" wrote: [...] Kief, a while back (when the work on PersistentManager was going on), the need for a little refactoring work on Manager vs. StandardManager would be useful. Have you thought any more about what we should do here? I couldn't find anything about how to add the PersistenManager in server.xml or in the manuals, however, after backtracking the maillist I found a "patch" by Kief that seems to have been forgotten, I'll cat it to the end of this mail. Maybe it can find it's way into the server.xml after all. Cheers, Bip --[ server.xml patch from Kief Morris ] --- server.xml.orig Sat Dec 16 20:03:29 2000 +++ server.xml Fri Jan 12 22:01:04 2001 @@ -179,6 +179,53 @@ Ejb name="ejb/EmplRecord" type="Entity" home="com.wombat.empl.EmployeeRecordHome" remote="com.wombat.empl.EmployeeRecord"/ +!-- + PersistentManager + Uncomment the section below to test Persistent Sessions. + + saveOnRestart: If true, all active sessions will be saved + to the Store when Catalina is shutdown, regardless of + other settings. All Sessions found in the Store will +be + loaded on startup. Sessions past their expiration are + ignored in both cases. + maxActiveSessions: If 0 or greater, having too many active + sessions will result in some being swapped out. +minIdleSwap + limits this. -1 means unlimited sessions are allowed. + 0 means sessions will almost always be swapped out +after + use - this will be noticeably slow for your users. + minIdleSwap: Sessions must be idle for at least this long + (in seconds) before they will be swapped out due to + maxActiveSessions. This avoids thrashing when the site +is + highly active. -1 or 0 means there is no minimum - +sessions + can be swapped out at any time. + maxIdleSwap: Sessions will be swapped out if idle for this + long (in seconds). If minIdleSwap is higher, then it +will + override this. This isn't exact: it is checked +periodically. + -1 means sessions won't be swapped out for this reason, + although they may be swapped out for maxActiveSessions. + If set to = 0, guarantees that all sessions found in +the + Store will be loaded on startup. + maxIdleBackup: Sessions will be backed up (saved to the Store, + but left in active memory) if idle for this long (in +seconds), + and all sessions found in the Store will be loaded on +startup. + If set to -1 sessions will not be backed up, 0 means +they + should be backed up shortly after being used. + + To clear sessions from the Store, set maxActiveSessions, +maxIdleSwap, + and minIdleBackup all to -1, saveOnRestart to false, then +restart + Catalina. + -- + !-- + Manager className="org.apache.catalina.session.PersistentManager" + debug="0" + saveOnRestart="true" + maxActiveSessions="-1" + minIdleSwap="-1" + maxIdleSwap="-1" + maxIdleBackup="-1" + Store className="org.apache.catalina.session.FileStore"/ + /Manager + -- Environment name="maxExemptions" type="java.lang.Integer" value="15"/ Parameter name="context.param.name" value="context.param.value"
RE: JDBC-Session store
Blob is a bad idea. Serialize the objects and store them as varchar. We implemented a home grown session store and the varchar route works lot better. I believe IBM's WebSphere session store also uses varchars. Krishna -Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 2:13 AM To: [EMAIL PROTECTED] Subject: JDBC-Session store I've been looking at the FileStore implementation and you(Kief/Craig) basically store a java object in the textfile, using the same approach with a DB usually(?!) involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want to store the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of reluctant to save objects in to a RDBMS and sort or "overriding" the native formats. Have anyone got any ideas on how to solve this in a good way? Preferably so it would work with JDBC 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go ahead and implement it as either a blob or a STRUCT whichever works out best. Thanks, Bip
Re: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
"Craig R. McClanahan" wrote: On Tue, 27 Mar 2001, George C. Hawkins wrote: The "Proposed Tomcat 4.0-Beta-2 Code Freeze Date" thread started on the 19th and fizzled out without any publicly visible conclusions. The suggested tag date, i.e. the 22nd, has passed and no new one has been proposed. Sorry to be pushy but is there a new consensus as to when to tag. As far as I could see only Glenn strongly opposed the 22nd date and I got the impression he could be talked out of it. It's been quite a while since beta 1 and the viewing public anxiously awaits a new release :-) Yours, It was asked that we hold off for a bit. Would doing the release this Friday meet everyone's preferences? If so, I will go ahead and submit the vote request formally. I am trying to track down a classloading bug that prevents Jasper from being able to translate a JSP page when it uses a taglib. This bug is only seen when running Tomcat 4 with the SecurityManager and a policy that grants explicit permissisons to Tocmat itself, like FilePermissions, instead of granting Tomcat AllPermission. I should be able to get this fixed by friday. I have noticed one other item I would like to see fixed. On contest startup, if a web apps web.xml is not valid, SAX fails. The error is sent to catalina.out instead of to the host or context log. In a web hosting environment this makes it difficult for the individual who's site is hosted to find out about the invalid web.xml. No reason to hold up B2 for this though. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
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 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
Re: JDBC-Session store
In the Java world, varchar should support UNICODE characters, not 8-bit bytes. Yes, I know some data bases do not store UNICODE, but some (Oracle, InstantDB etc) do. The other problem with character, is character encoding, when/if the encoding of the application does not match the native character encoding of the table, a translation is performed, and the results are not always reversible. The correct type used to store serialized data is byte, or varbyte, or even blob. Remember, Java characters are unsigned sixteen bit numbers not eight bit data elements (called char by 'C', 'C++' and many databases). - Original Message - From: Krishna R. Baddam [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 28, 2001 7:25 PM Subject: RE: JDBC-Session store Blob is a bad idea. Serialize the objects and store them as varchar. We implemented a home grown session store and the varchar route works lot better. I believe IBM's WebSphere session store also uses varchars. Krishna -Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 2:13 AM To: [EMAIL PROTECTED] Subject: JDBC-Session store I've been looking at the FileStore implementation and you(Kief/Craig) basically store a java object in the textfile, using the same approach with a DB usually(?!) involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want to store the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of reluctant to save objects in to a RDBMS and sort or "overriding" the native formats. Have anyone got any ideas on how to solve this in a good way? Preferably so it would work with JDBC 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go ahead and implement it as either a blob or a STRUCT whichever works out best. Thanks, Bip
sealing violation still exists? Was: [FOLLOWUP] Proposed Tomcat 4.0-Beta-2 Code Freeze Date?
I believe that someone is working on the "sealing viloation" fix that he wanted to include in beta 2. Can someone confirm (from a CVS build) that this bug still exists? The biggest thing that I need to see from someone else's machine is: * use the CVS jakarta-servletapi-4, * use the CVS jakarta-regexp-1.3-dev, * and make /double-backflippingly/ sure that the jars Catalina uses are still Sealed: true. The jars in your webapp shouldn't matter, but the ones in the various lib directories of Catalina must still be sealed (as they are by default) In unix, my favorite way of testing this is: cd $CATALINA_HOME; for j in `find . -name "*.jar"`; do echo $j; unzip -c $j META-INF/MANIFEST.MF | grep Sealed; done You should see that jaxp.jar and crimson.jar ARE, repeat, ARE sealed. If they are not, and you don't get the sealing violation, then you are a victim of the earlier CVS commits of unsealed jars. However, if you jump through my little hoops and you still don't (or do) get the sealing violation, PLEASE send me (and/or the list) email. The problem has vanished on my development machine, so it makes tracking the problem a nightmare. Craig knows all of this, but the more input I can get the better. -- /v\atthew -- Matthew L DanielNever put off until tomorrow what you can do today. Wizard There might be a law against it by that time. [EMAIL PROTECTED]-- `/usr/bin/fortune`
Re: SSL-Keytool Problem
You can download a SunJSSE RSA provider which is free from the java.sun home site. Also look at http://www.openjce.org/ as that may or may not fit your licensing needs better than Sun's license. After installing the JSSE, you need to copy the lib/*.jar to the jre's lib/ext directory. Don't forget to add the provider to your JRE_HOME/lib/security/java.security file. It should go after security.provider.1 but before security.provider.2 (at least with OpenJCE). YMMV. -- /v\atthew -- Matthew L DanielNever put off until tomorrow what you can do today. Wizard There might be a law against it by that time. [EMAIL PROTECTED]-- `/usr/bin/fortune`
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
( BTW, my interest is more in the jsp-java convertor area, I would be interested to try a more customizable generator that would use XSL templates, but that depends on a modularization and refactoring that would I remember back in the "old days" when the JSP spec actually contained a representation of JSP syntax as XML tags (jsp:expression and whatnot), but Tomcat didn't support it because (as I recall) Sun deprecated it. I'm with Costin, I think that would be/was just super-cool. I just wanted you to know you're not alone, Costin. :-) -- /v\atthew -- Matthew L DanielNever put off until tomorrow what you can do today. Wizard There might be a law against it by that time. [EMAIL PROTECTED]-- `/usr/bin/fortune`
Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
On Wed, 28 Mar 2001, Matthew L Daniel wrote: ( BTW, my interest is more in the jsp-java convertor area, I would be interested to try a more customizable generator that would use XSL templates, but that depends on a modularization and refactoring that would I remember back in the "old days" when the JSP spec actually contained a representation of JSP syntax as XML tags (jsp:expression and whatnot), but Tomcat didn't support it because (as I recall) Sun deprecated it. I'm with Costin, I think that would be/was just super-cool. The XML syntax is part of JSP1.2, but the JSP parser can easily generate SAX events from a "normal" JSP that match the 1.2 XML representation. Just to make clear - this is more of an experimental/cool/maybe project, and a refactoring that would allow other generator modules to be plugged in would make possible to do this kind of experiments while sharing the same infrastructure and without hurting jasper's stability ( i.e. I'm not proposing to replace the current stable code with some cool stuff - just to make things more modular so experiments in code generation can happen). I think Mel's original proposal had this right - developing the new JspServlet interface along with the old one, and allowing the user to use either ( until the new one is clearly ready and we can deprecate the old one ). Same should happen in the generator, compiler and for all other components of jasper. And the good news is that the refactoring shouldn't be very difficult - the most important thing is to agree on the components, move the code in new packages and then try to simplify the interfaces. After that we can test and make sure we still have the good jasper, and start playing with new JspServlet, parsers, generators, manglers, etc. Costin
Re: CHINANSL Security Advisory(CSA-200105)
Dear "lovehacker", Tomcat 3.0 is an old version and has several known security holes. That is why we recommend that people run the latest released version which is currently 3.1.1 or 3.2.1 (depending on the branch you are interested). Also, Tomcat 3.2.2b2 is also available on our website which fixes the recently announced cross site scripting issue. I would appreciate it if you would test and report your security holes against the released versions and not the old versions. I see no further action necessary unless your hole is also present in the current code base (I suspect that it isn't). I also may have missed your posting, but giving advance notice to [EMAIL PROTECTED] and/or [EMAIL PROTECTED] would be more appropriate than posting to bugtraq first. thanks, Jon S. Stevens [EMAIL PROTECTED] ASF Member PMC Member - Jakarta Group -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html on 3/27/01 10:40 PM, "lovehacker" [EMAIL PROTECTED] wrote: Topic: Tomcat 3.0 for win2000 Directory traversal Vulnerability vulnerable: Tomcat 3.0 for win2000 maybe for other operating system also. discussion: A security vulnerability has been found in Windows NT/2000 systems that have Tomcat 3.0 installed.The vulnerability allows remote attackers to access files outside the document root directory scope. exploits: http://target:8080/../../winnt/win.ini% 00examples/jsp/hello.jsp It is possible to cause the Tomcat server to send back the content of win.ini. solution: None Copyright 2000-2001 CHINANSL. All Rights Reserved. Terms of use. CHINANSL Security Team [EMAIL PROTECTED] CHINANSL INFORMATION TECHNOLOGY CO.,LTD (http://www.chinansl.com)
RE: FW: Tomcat 4 service
There is some basic code aimed at allowing the creation of such a beast in the "service" directory of the source repository. Besides just being able to start and stop Tomcat as a service, one of the goals is to interact with the connector startup so we can run Tomcat 4 on port 80 without having to be root. This will require a couple of changes to the Connector interface as well as a Tomcat-4 specific version of the service startup stuff. It would be great if you wanted to work on this! I'll take a look, but I'm slightly confused (not unusual :-) ) You say above about non-roots not being able to run Tomcat on port 80. This is NT/W2K we're talking about right? Or is there some connection between the service code and *nix? Kevin Jones DevelopMentor www.develop.com -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 28 March 2001 22:19 To: Tomcat-Dev Subject: Re: FW: Tomcat 4 service On Wed, 28 Mar 2001, Kevin Jones wrote: I posted this to tomcat-user with no response. Does such a beast exist? If not I'll volunteer to port the Tomcat 3.2 code. Just point me at it! There is some basic code aimed at allowing the creation of such a beast in the "service" directory of the source repository. Besides just being able to start and stop Tomcat as a service, one of the goals is to interact with the connector startup so we can run Tomcat 4 on port 80 without having to be root. This will require a couple of changes to the Connector interface as well as a Tomcat-4 specific version of the service startup stuff. It would be great if you wanted to work on this! Kevin Jones DevelopMentor www.develop.com Craig -Original Message- From: Kevin Jones [mailto:[EMAIL PROTECTED]] Sent: 27 March 2001 22:44 To: Tomcat-User Subject: Tomcat 4 service I have tomcat 3.2 running as a service under W2K. I seem to remember that this wasn't available for Tomcat 4 (running it as a service that is), or is the code now available? Thanks, Kevin Jones DevelopMentor www.develop.com
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 jasper into a (
Re: 4Dimension
The vendor's web site is : http://www.4d.com :) and he's still alive :))) I found something like Java for 4D but it seem to have no special documentation ... ? From: Rob Tanner [EMAIL PROTECTED] Reply-To: Rob Tanner [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: 4Dimension Date: Wed, 28 Mar 2001 23:44:07 -0800 Does the vendor for 4Dimension even exist anymore? I did a quick query and turned up about three pages of stuff, mainly just catalogues of what databases are being used in various projects, etc. I found a whole lot more stuff when I tried "fouth dimension", but it nothing to do with computers. I figured if I could find the vendor's web site, I might be able to glean something useful. But the effort seems to have been a bust. -- Rob --On Thursday, March 29, 2001 07:39:03 AM + baumans pascal [EMAIL PROTECTED] wrote: Hi lists; My servlets (on a Linux Machine) need to query a database named 4D (running on a Mac-Os) Do Somebody know how I can query these DB from Linux ? Maybe with ODBC link, but I don't find any docs about it !!! Can somebody help ? Greets. Baumans Pascal. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _ _ _ _ __ _ _ _ _ /\_\_\_\_\/\_\ /\_\_\_\_\_\ /\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT, /\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR /\/_/_/_/_/ /\_\ /\/_//\/_/ /\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin \/_/ \/_/ \/_/_/_/_/ \/_/ appears profound) Rob Tanner McMinnville, Oregon [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
4Dimension
Hi lists; My servlets (on a Linux Machine) need to query a database named 4D (running on a Mac-Os) Do Somebody know how I can query these DB from Linux ? Maybe with ODBC link, but I don't find any docs about it !!! Can somebody help ? Greets. Baumans Pascal. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
