FORM authentication (again)
I'm still struggling with getting form authentication working with the latest snapshots. With 4.0b1 it works fine. With the latest snapshots no cookie is sent, authentication succeeds but redirection to the secured page fails. Can someone advise whether this is a bug or is some additional setup needed compared to 4.0b1 Many thanks Tim Tim Dudgeon [EMAIL PROTECTED] -- DISCLAIMER: This message contains proprietary information some or all of which may be confidential and/or legally privileged. It is for the intended recipient only who may use and apply the information only for the intended purpose. Internet communications are not secure and therefore the British Biotech group does not accept legal responsibility for the contents of this message. Any views or opinions presented are only those of the author and not those of the British Biotech group. If you are not the intended recipient please delete this e-mail and notify the author immediately by calling ++44 (0)1865 748747; do not use, disclose, distribute, copy, print or rely on this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: first cut at tag pooling implementation
Thanks Casey! This looks very promising. How long before you have a patch for jasper available? I would like to do some testing of your tag pooling on Jasper in Tomcat 4.0. Regards, Glenn Casey Lucas wrote: Great! You will do before/after performance comparisons? In the process... Ok, here are some basic numbers. For simple performance testing I wrote a jsp that uses an outer tag (BodyTag iteration style) and an inner tag. I placed timings around the outer tag. Based on 3.3 (nightly from a couple of days ago) and running 1 iterations, over 10 runs each from one browser... tag processing took avg of: pre tag pooling: 7362 milliseconds tag pooling patches (pooling enabled): 1586 milli tag pooling patches (pooling disabled): 6494 milli Yes, I know most pages don't have 1 tags and my tests are far from rigorous, but I just wanted to get a rough estimation. I found it interesting that the patched (but pooling disabled) runs were faster than the originals. The only thing that I can think of that might be different is that the old code had some references to a static variable that I removed. I'm not sure if that could/ would make a difference. Maybe there was something else going on. Have you tested your changes with Watchdog? Well I tried to run the patches with watchdog and became worried when some of the tests failed. But the ones that failed appeared to be the same ones that failed with the originals. Are the nightly builds supposed to pass watchdog tests? Hopefully the 3.3m2 stuff will work cleanly with watchdog and I can test against that. -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Plugging realms and JAAS into Tomcat 3.2
Hi, I am trying to find out if it is possible to plug ones own proprietary user realm into Tomcat 3.2. I have JAAS login modules that authenticate against this user realm and populate the JAAS Subject with principals (user names, groups, roles). However, I need to get this JAAS created security context into the Web container's security context, so that, for example, IsUserInRole() can be used to determine Roles from the original user realm and any calls to EJB container will get the security context. Rgds Antony -- Antony Bowesman Teamware Group [EMAIL PROTECTED] tel: +358 9 5128 2562 fax: +358 9 5128 2705 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 3.3 Milestone 2 status
Hi, We are now in the process of constructing Tomcat 3.3 Milestone 2. Until further notice, please consider the jakarata-tomcat MAIN branch frozen. Thanks, Larry __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: how to specify Tomcat policy
Hello,
How do I specify that a specific policy file is to be taken into
consideration while running applications(JSPs) on tomcat?
This kind of question should be posted to users-list, rather than this
list.
During the "PolicyInterceptor.contextInit()", the instances Permission
are retrieved from Policy object by "getPermissions()". And the instance
of CodeSource is specified as the argument for
"Policy.getPermissions()".
For each context, this instance of CodeSource is constructed with the
URL object pointing the docBase directory of that context.
So, to add the instances of Permission to each context, the codeBase for
that Permission must match the docBase for that context.
What does this mean?
To give the permissions for the Java library under some specific
context, we should specify the docBase directory for that context as the
codeBase.
Specifying "WEB-INF" directory as the codeBase will not work.
Only when the "codeBase" in the "tomcat.policy" matches the "docBase" in
the "server.xml", the permissions will be applied to that context.
For example, please append the following entities to your
"tomcat.policy":
grant codeBase "file:/export/home/foo/webapp/bar" {
permission java.io.FilePermission "/export/home/foo/webapp/-", "read,
write, delete, execute";
};
And "/export/home/foo/webapp/bar" is the "docBase" directory specified
in "server.xml".
--
Happy Java programming!
Jun Inamori
OOP-Reserch
E-mail: [EMAIL PROTECTED]
URL:http://www.oop-reserch.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Plugging realms and JAAS into Tomcat 3.2
Hi Antony, Normally 3.2 is frozen, and only bug fixes should go in. But the good news is that for what you want, only a simple add-on module is needed ( and if it's available before 3.2 is final, we can probably include it in package - if not it'll be a separate download ). It should be reasonably easy - all you need to do is implement a module, with setters for all properties that you need for configuration, using the Simple or JDBC authenticators as a template. In 3.2 you'll need to implement authorize() and authenticate() hooks. Tomcat 3.x doesn't care how the authentication is done - it just calls the authentication chain and if a module returns OK and sets the roles then everything is ok. ( same model as in Apache/IIS/NES ) In 3.3 the auth code has been cleaned and reorganized, but it works in the same way. Please let me know if you need any help ( Nacho is probably a better source :-), it would be a great contribution. Costin On Wed, 14 Mar 2001, Antony Bowesman wrote: Hi, I am trying to find out if it is possible to plug ones own proprietary user realm into Tomcat 3.2. I have JAAS login modules that authenticate against this user realm and populate the JAAS Subject with principals (user names, groups, roles). However, I need to get this JAAS created security context into the Web container's security context, so that, for example, IsUserInRole() can be used to determine Roles from the original user realm and any calls to EJB container will get the security context. Rgds Antony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] JSPC broke again - can't find servlet.jar
C:\Build\Tomcat-4\jakarta-tomcat-4.0\dist\binjspc -d \tmp\jspc -webapp ..\webapps\examples\jspUsing CLASSPATH: ..\classes;..\lib\jasper-runtime.jar;..\lib\namingfactory.jar;..\jasper\crimson.jar;..\jasper\jasper-compiler.jar;..\jasper\jaxp.jar;..\bin\servlet.jarException in thread "main" java.lang.NoClassDefFoundError: javax/servlet/ServletException at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) patch is straightforward: ---bin/jasper.bat Tue Mar 6 10:18:44 2001+++bin/jasper.bat Wed Mar 14 10:14:16 2001@@ -42,7 +42,7 @@set CLASSPATH=%JASPER_HOME%\classesfor %%i in (%JASPER_HOME%\lib\*.jar) do call %JASPER_HOME%\bin\jpappend.bat %%ifor %%i in (%JASPER_HOME%\jasper\*.jar) do call %JASPER_HOME%\bin\jpappend.bat %%i-set CLASSPATH=%CLASSPATH%;%JASPER_HOME%\bin\servlet.jar+set CLASSPATH=%CLASSPATH%;%JASPER_HOME%\common\lib\servlet.jarecho Using CLASSPATH: %CLASSPATH% rem - Execute The Requested Command --- <><><><><><><><><><><><><><><><><><><><><>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: [VOTE] New Committer: Amy Roh
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: and I would love to see more people working for other companies in jobs involving tomcat and willing to become commiters, and this vote will make it easier for them to do so. Yeah, I was working for one... With another Tomcat committer, and thank god that Sun is _really_ serious about Tomcat, because if it was for some other company, right now my Apache involvement would be somewhere between a trash bin and the toilet... Pier (on a plane to Dublin :) -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
Dan Milstein [EMAIL PROTECTED] wrote: Please, please, please, let's not get into another debate about 3.x vs 4.x -- I am really enjoying this list being useful again, and not clogged with flame wars. But flame wars are "FUN" :) :) :) Joking of course Pier (on a plane to Dublin :) -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
GOMEZ Henri [EMAIL PROTECTED] wrote: I'll be +1 if Amy contribute to ALL TOMCAT current projects : ie : Tomcat 3.1, 3.2, 3.3 and 4.0 Sweetie... I'm not going to touch ONE LINE of the 3.x code... Now, do you want to take away my committers privilege? IS EVERYONE GETTING NUTS AGAIN AROUND HERE :/ Pier (on a plane to Dublin :) -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
Amy Roh [EMAIL PROTECTED] wrote: First of all, I would like to thank to everyone who voted +1 for me becoming a committer. I am very excited to get involved in such a project and am very happy that I no longer need to bug Craig or Remy to commit my code for me. :-) Whoh!!! :) Now I can flame you also @apache.org, not only @betaversion.org :) :) :) :) And for response to Gomez "Personal to Amy, are you agree working also on TC 3.3?" Has every committer for this project been contributing to ALL TOMCAT current projects? Personally, I don't quite understand the need for contribution to *EVERY* branch of tomcat from an EACH committer nor the ability for a developer to focus on different branches at the same time unless you're a superman (Craig for example):-) That's "bribing" the boss (but for real, how can he _really_ commit code from under 6 feet of snow stranded on the east coast and with basically no email access), Craig, one day you'll have to share the secret... I think our focus should be on making Tomcat a better product rather than focusing on which version should get more attention. However, that's just my humble opinion... I strongly agree with you... Just to make the long story short, it's true, tomcat 4.0 seems to be a "Sun" corporate project... Indeed at Sun there is a plan for it (TC4.0 is in J2EE 1.3), but most of us working in the team were there _before_ we were even working there... Catalina, so far, started years ago when Craig was working on Jserv 2.0, and was working somewhere else, regarding me and Remy, well, we have a different story, but most of us were not at Sun when TC4.0 started... And we were already somehow "involved" in it. I believe we were just lucky to find a company willing to pay us to maintain our current involvement in the open source community "for real"... It would be like saying that Apache 2.0 is a "Covalent" project... C'mon guys... :) :) :) Pier (on a plane to Dublin :) -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Strange problem with URL_PKG_PREFIXES
Remy, Thanks for helping me look into this problem. I believe that short term, prepending the apache pkg prefix is a simple way to make results consistent. I thought that some of my problem might be from having out of date 'org.jnp.interface' library. I have looked all morning, and cannot find anything outside of JBoss that includes this jar, so I have no explaination why Jakarta is able to get a naming context from JBoss instead of Class load fail!!! How do I find out where a servlet class loader is obtaining a class from (which jar path)? I am trying to make the ejb-link use jnp://ttt1:1099/EJBresource work. I need to resolve this type of URL link in Jakarta to allow seperation between the JSP server and the EJB server. The org.apache.naming.NamingContext does not seem to pass the correct information to NamingManager so it can connect to the jnpURLNaming Can you think of anything else to try? Remy Maucherat writes: According to NamingManager documentation, first it will look for 'org.jnp.interfaces.java.javaURLContextFactory' which does not exist, so it should next look for 'org.apache.naming.java.javaURLContextFactory' which does exist. So, this should work. Indeed, my mistake. It should work, since the IC will only call lookup on the Context produced by the IC factory *after* checking the URLs. BTW, the 'org.apache.naming' prefix is concatenated onto the URL prefixes by jakarta. Since I can't figure out where the problem is coming from, I can change it and make 'org.apache.naming' a prefix. Also, when the jnp.jar is removed, it still fails with the same error. How can this be made to work? Don't you get a no initial context factory found when you remove JNP ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] New Committer: Amy Roh
On Wed, 14 Mar 2001, Pier P. Fumagalli wrote: GOMEZ Henri [EMAIL PROTECTED] wrote: I'll be +1 if Amy contribute to ALL TOMCAT current projects : ie : Tomcat 3.1, 3.2, 3.3 and 4.0 Sweetie... I'm not going to touch ONE LINE of the 3.x code... Now, do you Bravo ! That's the spirit of "community" and open source, isn't it ... Ok, I'll follow your example and stay away from mod_webapp - after all Pier's attitude should be an example for us all, he's been around for a long time. :-) Costin P.S. Note the :-) at the end - i.e. joke sign. I still think it would be a good idea to merge mod_jk and mod_webapp, even if Pier is not going to touch 3.x code. Some of the ideas are good, and getting them into mod_jk will be good for the users - and that's what matters. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FORM authentication (again)
On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: I'm still struggling with getting form authentication working with the latest snapshots. With 4.0b1 it works fine. With the latest snapshots no cookie is sent, authentication succeeds but redirection to the secured page fails. Can someone advise whether this is a bug or is some additional setup needed compared to 4.0b1 I just fixed this bug yesterday -- could you try last night's nightly distribution? Many thanks Tim Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.3 Milestone 2 status
Hi, The jakarta-tomcat project has been tagged in CVS, so commits may resume. If you need Tomcat 3.3 Milestone 2 source, be sure to checkout with the tag tomcat_33_m2. I have built the Windows connectors for Milestone 2. Those who wish to contribute additional connectors may e-mail me directly. Cheers, Larry -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 14, 2001 9:36 AM To: '[EMAIL PROTECTED]' Subject: Tomcat 3.3 Milestone 2 status Hi, We are now in the process of constructing Tomcat 3.3 Milestone 2. Until further notice, please consider the jakarata-tomcat MAIN branch frozen. Thanks, Larry __ Larry Isaacs [EMAIL PROTECTED] SAS Institute Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Build Failed - SendMailFactory.java:148 : Wrong number of arguments
[javac] C:\jakarta\jakarta-tomcat-4.0 \catalina\src\share\org\apache\naming\factory\SendMailFactory.java:148: Wrong number of arguments in method. [javac] Session.getInstance(props)); -Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] New Committer: Amy Roh
Yeah, I was working for one... With another Tomcat committer, and thank god that Sun is _really_ serious about Tomcat, because if it was for some other company, right now my Apache involvement would be somewhere between a trash bin and the toilet... I also works in a little company, SLIB, and management here let me spend time on Tomcat and Apache stuff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Is Tomcat Stable Enough ?
Hi Jerry! "Jerry G. Wang" wrote: is Tomcat stable for production environment ? on which platform does it perform better ? does anyone know where i can get this info ? I think your question is more of an user question, since it does not deal with development of Tomcat. From my experience: Tomcat 3.2.1 is stable enough, and I suppose Tomcat 3.2.2 will be even more stable. The connection to Apache seems to be a big source of problems. Haven't tried it though -- standalone Tomcat works fine for me. If you're serving static content, you'd like to make it. If you're talking about production requirements, you'd be surprised: JRun, for example, is a piece of crap compared to it. iPlanet is quite stable, but then it's got bugs -- sometimes does not work as advertised. Tomcat works ok on Win2000 and Solaris. It performs better (not surprisingly) on Solaris -- I guess a Linux box would do ok. All this info is quite unspecific; if you want more detailed information, you should ask what is worrying you -- requests/second, number of connections, thread pools or whatever. "Production environment" sounds like a broad subject to me. Un saludo, Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: JSP doInitBody/doAfterBody with no body
Marc Saegesser wrote: The follow email discussion happened on tomcat-dev back in January. In reviewing the open bugs for Tomcat 3.2.2 I came across this issues again and I'm trying to decide if it should dealt with, marked invalid, etc. Did anyone hear anything back from jsp-comments? For that matter, has any *ever* heard anything back from jsp-comments? I've never received a single response to any message I've ever sent to that address. I brought this to the JSR-053 working group yesterday, and Eduardo has promised to try to resolve the issue with a mail today or tomorrow. My reading of the spec, though, is that no matter if an action element has a body or not, all body methods must always be called if BodyTag is implemented. Not doing so means that the tag developer needs to deal with different usage scenarios in the code, and that should not be necessary. Hans -- Jeff Turner wrote: Having a look through bug 652: BodyTag doInitBody and doAfterBody called on tags without body (http://znutar.cortexity.com/BugRatViewer/ShowReport/652) I don't think this is a bug. The JSP spec, p88, says: "If an action element can have a non-empty body and is interested in the content of that body, the methods doInitBody() and doAfterBody(), defined in the BodyTag interface are involved." My interpretation of this is: * Tag "foo" may have body * x:fooBlah/x:foo - body methods called * x:foo/ - no body methods called Note, "can have", not "if it does have". So an element without a body, but that *could* have a body according to the TLD, still has do*Body methods called. .. if it has a body *in the usage of it*, sure. Of course. But if it's not *used* with a body, then the body methods should not be called. So: my:tagfoo/my:tag has do*Body() called (obviously). my:tag/my:tag has do*Body() called (the body will just be blank) my:tag/ has do*Body() called, because according to the XML spec, this is shorthand for the my:tag/my:tag notation, and therefore processes equivalently. I see the two last ones as distinctly different, whereas the first two are identical semantically. And I have a couple of tags that indeed makes a major difference between x:foo/x:foo and x:foo/. Interestingly, JRun3.0 has the opposite bug, and doesn't call setBodyContent if the tag doesn't have a body but could. To me that is correct. Eg, in JRun the following action breaks: util:include url="foo.html"/ Why? How is this tag dependent on a body to be supplied? But this works: util:include url="foo.html"/util:include The taglib in question is from the Jakarta Taglibs project. To me this hints at a bug in the Jakarta Taglibs. It might be beneficial to send a query about this to the JSP spec writers, since it's a rather important issue. I have CC'ed [EMAIL PROTECTED] regards, Rickard -- Rickard berg Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Henri, Dan,
There are some discussions below about the usage
of msg/rmsg. What did you guys finally decide
on that? Just reuse msg? I'm seeing the problem
Dan mentioned on message larger than the ajp13
buffer (8K).
thanks,
shinta
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 13, 2001 4:49 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown
1) First off, I strongly believe that this work (which I think is an
excellent feature, BTW), belongs in the 3.3 branch, and
*not* in 3.2.
+1, there was a message about including latest mod_jk
features/corrections
back to Tomcat 3.2.x but TC 3.2 Release Manager and others clairly
stated that TC 3.2.x must be just correction of bugs without any
new features. I asked about back-porting mod_jk/ajp13 since now
Apache 2.0 or upload works fine with mod_jk/ajp from TC 3.3 branches
but are not in TC 3.2. The decision was not to provide corrections
to TC 3.2.
Although it feels like a bug that we need to restart Apache
every time we restart TC, it's documented behavior, and I
consider fixing it more of a feature enhancement.
The scope of work you're doing here is considerable,
and the code you're modifying is complex (and involves lots of
different possible situations). I would not feel
comfortable committing
this to 3.2 unless it had seen a *lot* of testing in the 3.3
branch. (Am
I incorrect in remembering that there has been discussion of
putting this
into 3.2?)
Right many works, some testing but back-port could introduce
bugs in TC3.2.
The decision was to not port mod_jk back to tc 3.2. But
people could still
build mod_jk from Tomcat 3.3 and use against there Tomcat
3.2.x. That's why
I milite for a jakarta sub-project (web-connector). These
kind of connector
work must outside Tomcat trees. (Votes ?)
2) Specific problems (line numbers by patch against the 3.3
code base)
- msg/rmsg: Here is how I think you want the code to work:
msg always holds the basic request information, so, in case
of an error, we
can
resend the message. rmsg is used as the buffer for response
information.
Dan you're our resident hacker/expert on mod_jk native part
This is a good idea, but there are a few problems -- first, and most
importantly, if there is POST data, the msg buffer
immediately gets reused to send that information to TC (ll.
596-600).
In that case, on line 691, if you retry after a connection
reset event,
you'd be using a buffer filled with POST data instead of a
buffer with
header information.
I'm not too confortable with msg/rmsg that's why I asked for your code
revue (and it's excellent ;-)
Possibly you could fix this by calling
ajp13_marshal_into_msgb again when
you retry -- I don't know how the state of the
web_server_service object
(s),
changes over time, so I don't know for sure if this would
work or not. But
that's where I'd look next.
Or you could pass rmsg into the sendrequest, and use that to
send the POST data over. I dunno.
Your use of msg/rmsg in getreply seems faulty to me. I don't
think you need msg there at all, and I'm sure that you've
got a problem
with
mixing the two of them. Specifically, on l. 636, you call
rc = ajp13_process_callback(rmsg, p, s, l);
But, then a few lines later, you do:
else if(JK_AJP13_HAS_RESPONSE == rc) {
rc = connection_tcp_send_message(p, msg, l);
Right, we must drop rmsg use and do all stuff with msg.
If you look at ajp13_process_callback, at the GET_BODY_CHUNK
case, you'll see that it's reading request data into the
buffer passed in
as a param
(which is what getreply is calling 'rmsg'). But then, when you call
connection_tcp_send_message, you'll be sending over whatever
was in msg, rather than what the web server has read from
the browser.
You can fix this by changing connection_tcp_send_message to
use 'rmsg' (and
then you don't need to pass msg into getreply at all).
This problem will happen in case of a file upload, or
whenever there is
enough POST data to exceed a single ajp13 buffer (8K).
Furthermore, in that
case, I'm not sure if there's going to be any way to restart
the connection
intelligently. If the browser has already sent over 500 K
of a 1M file
upload when TC dies, I think we need to just kill that
request, rather than
trying to restart it. I don't think the request is
recoverable. I'm not sure
how to detect this in your code, but I think it needs to be
thought about.
Upload are a real problem since we just couldn't replay the upload
in case of Tomcat failure. Solution could be to ask browser to
resend but HOW (HTTP expert needed here)
- The for loop on l. 689 makes me nervous. Could you rewrite that:
int i;
for(i = 0 ; i JK_RETRIES ; i++)
That way
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
craigmcc01/03/14 14:36:42 Modified:catalina/src/conf web.xml Log: Add a mime type for DTD files so that browsers don't try to interpret them as HTML (due to the lack of a Content-Type header, as specified for 2.3). Revision ChangesPath 1.14 +4 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- web.xml 2001/01/29 03:40:57 1.13 +++ web.xml 2001/03/14 22:36:36 1.14 @@ -601,6 +601,10 @@ extensionswf/extension mime-typeapplication/x-shockwave-flash/mime-type /mime-mapping + mime-mapping +extensiondtd/extension +mime-typetext/plain/mime-type + /mime-mapping !-- Establish the default list of welcome files -- welcome-file-list
Re: Build Failed - SendMailFactory.java:148 : Wrong number of arguments
Requires JavaMail 1.2. Glenn Amy Roh wrote: [javac] C:\jakarta\jakarta-tomcat-4.0 \catalina\src\share\org\apache\naming\factory\SendMailFactory.java:148: Wrong number of arguments in method. [javac] Session.getInstance(props)); -Amy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
The available method for ServletInputStream subclasses(tomcat_32 branch)
In working with some internal groups, we have some classes that perform file uploads (anyone heard of GroupWise Webaccess?). One of the things they have done in their servlets that handle this is call the available method on the ServletInputStream so that they can delay the thread for a small amount of time if there isn't anything available to be read from the socket. This allows the machine and other threads to do other processing, and allows the thread that wants to read the data to gracefully handle a client prematurely shutting down the connection. This functionality works on other servlet engines (JServ, WebSphere, Novell Servlet Gateway) but doesn't work on Tomcat because the available() method was never implemented in any of the subclasses. So when availabe() is called, it just resolves down to java.io.InputStream which is documented as returning 0 because subclasses should override this method. There are 2 ways to fix this: 1. In BufferedServletInputStream, implement an available() method that returns limit-bytesRead or 0 whichever is greater. The limit class variable is set to the value of the Content-Length header and bytesRead is the number of bytes read since limit was set. (See the attached patch). This is the easy fix but doesn't address the feature of available that says it will return the number of bytes that can be read "without blocking". Obviously, if there is a large amount of data, a read will most likely block at some point depending on how much is asked for. 2. Update BufferedServletInputStream to call reqA.available and then update the following files to provide this interface: Request.java RequestImpl.java HttpRequestAdapter.java AJP12RequestAdapter.java Ajp13RequestAdapter.java JNIRequestAdapter.java Each of these classes would need to provide an appropriate available() method. I'm willing to figure this out and implement #2 if it is deemed the better approach and only provided #1 because it was a "quick" fix. I'm also willing to figure this out for the 3.3 tree for either implementation. I would like to get it into the 3.2.2 branch since that is what most of use here are currently using. Any response (other than flames:-) appreciated. diff.out
Re: Is Tomcat Stable Enough ?
The connection to Apache seems to be a big source of problems. Haven't tried it though -- standalone Tomcat works fine for me. If you're serving static content, you'd like to make it. TC 3.2.1 did have some serious connector issues (particularly with ajp13, which a lot of people used because of its SSL support). There are many bug fixes in 3.2.2 for the mod_jk and ajp13 code. It is much improved. Just so you know... -Dan -- Dan Milstein // [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons - web connector
I don't see the advantages to having a separate project for the connectors.
Can someone explain that to me?
The main disadvantage that I see is that the connectors and Tomcat are very
tightly linked -- I think having one developer list for TC and the
connectors makes a lot of sense. I think having one bug system for TC and
the connectors makes a lot of sense (especially since it's not always clear
if the bug is in TC or in the connector when it is reported). Ditto for the
user list, where TC/connector configuration issues are ever popular.
Would this separate project include both C and Java code? It would have to,
if it would have any meaning (just working on one side of the protocols
would be a nightmare to sync up with a "separate" project). But if there's
Java code in there, there's going to have to be different code for each
different engine which the connector talks to (e.g. TC 3, TC 4). Pulling
that code out of the main projects makes no sense to me. It is totally
dependent on the rest of the project code.
I'm not sure if I'd want to be a committer on a different project -- once
3.3 is released, I'm planning on working on the 4.x branch. The first thing
I'd like to do (which I threatened to do a long time ago!), would be to
write an ajp13 connector and/or merge mod_webapp with mod_jk. That is
"connector" work, but I, personally, am more interested in the servlet
engine as a whole than on "just" the connectors.
-Dan
GOMEZ Henri wrote:
Still no response for this sub-project proposal.
The upcoming PMC could be an occasion to speak about it.
I saw at least 4 potentials commiters working on it :
- Dan Milstein, our resident hacker/expert of mod_jk.
- Keith Wannamaker, webdav specialist
- Pier P. Fumagalli, mod_jserv and mod_webapp father
- I, Henri Gomez, mod_jk and adaptation to Apache 2.0
We start speaking of an updated mod_jk with ajp13++ (ajp14)
which must fix current known problem like :
- lack of security between Apache / Tomcat
Tomcat accept connection from anybody to it's ajp12/ajp13
connector. We may add so trivial authentification scheme
at least at connect time.
Nothing too expensive but last days on Tomcat list there is
an interesting Thread on 'Encrypting password' ('challenge-response')
- problem with large upload between client - apache - tomcat.
If tomcat is broken between the upload we just couldn't do anything
with remaining data and load-balancing/fault-tolerant will be no help
there. We must have a persitant storage used in these upload case (flat
file ?)
- context loading/unloading information could be sent from
Tomcat to Apache to let him choose a working Tomcat for
the requested context. Indispensable in production site with
many virutal where admin will want to update specific context.
- mod_jk handle load-balancing but many will just want a simple
fault-tolerant configuration. I Tomcat1 fail just go to Tomcat2,
and just in that case.
Thanks to comment.
Hi to all,
What about a new sub-project, web connector, where all
the developpement on mod_jserv and mod_jk
(and why not mod_webapp) could live.
Apache 1.3 and 2.0 are allready supported by mod_jk but also
IIS, AOL, and NES (iPlanet) even JNI.
Tomcat's 3.x and 4.x provide interfaces (modules,
interceptor or whatever) that these connectors will implement :)
A project which could be in The Commons even if there is
still C code inside but also many java part (TC mod/interceptor).
We could (must) see Tomcat 4.x use mod_jk or Tomcat 3.x use
mod_webapp from Apache 2.0...
Comments ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler ParserController.java
horwat 01/03/14 16:31:41
Modified:jasper/src/share/org/apache/jasper/compiler
ParserController.java
Log:
Bug Fix: jspc didn't work well under windows since file separator assumed to be "/"
in ParserController.resolveFileName
Bugzilla: #821 #487
Revision ChangesPath
1.10 +2 -2
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java
Index: ParserController.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ParserController.java 2000/12/22 18:37:39 1.9
+++ ParserController.java 2001/03/15 00:31:41 1.10
@@ -417,12 +417,12 @@
* baseDirStack.
*/
private String resolveFileName(String inFileName) {
-boolean isAbsolute = inFileName.startsWith("/");
+boolean isAbsolute = inFileName.startsWith(File.separator);
String fileName =
isAbsolute ?
inFileName : (String)baseDirStack.peek() + inFileName;
String baseDir =
- inFileName.substring(0, inFileName.lastIndexOf("/") + 1);
+ inFileName.substring(0, inFileName.lastIndexOf(File.separator) + 1);
baseDirStack.push(baseDir);
return fileName;
}
cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
horwat 01/03/14 16:37:18 Modified:jasper/src/bin jasper.bat jasper.sh Log: Fix jspc classpath, point to new servlet.jar file location. Submitted by: Steve Downey Revision ChangesPath 1.4 +2 -2 jakarta-tomcat-4.0/jasper/src/bin/jasper.bat Index: jasper.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/bin/jasper.bat,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jasper.bat2001/03/01 01:30:13 1.3 +++ jasper.bat2001/03/15 00:37:17 1.4 @@ -11,7 +11,7 @@ rem JAVA_HOME rem Must point at your Java Development Kit installation. rem -rem $Id: jasper.bat,v 1.3 2001/03/01 01:30:13 remm Exp $ +rem $Id: jasper.bat,v 1.4 2001/03/15 00:37:17 horwat Exp $ rem --- rem - Save Environment Variables That May Change -- @@ -42,7 +42,7 @@ set CLASSPATH=%JASPER_HOME%\classes for %%i in (%JASPER_HOME%\lib\*.jar) do call %JASPER_HOME%\bin\jpappend.bat %%i for %%i in (%JASPER_HOME%\jasper\*.jar) do call %JASPER_HOME%\bin\jpappend.bat %%i -set CLASSPATH=%CLASSPATH%;%JASPER_HOME%\bin\servlet.jar +set CLASSPATH=%CLASSPATH%;%JASPER_HOME%\common\lib\servlet.jar echo Using CLASSPATH: %CLASSPATH% rem - Execute The Requested Command --- 1.3 +3 -2 jakarta-tomcat-4.0/jasper/src/bin/jasper.sh Index: jasper.sh === RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/bin/jasper.sh,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jasper.sh 2001/03/01 01:30:13 1.2 +++ jasper.sh 2001/03/15 00:37:18 1.3 @@ -13,7 +13,7 @@ # JAVA_HOME # Must point at your Java Development Kit installation. # -# $Id: jasper.sh,v 1.2 2001/03/01 01:30:13 remm Exp $ +# $Id: jasper.sh,v 1.3 2001/03/15 00:37:18 horwat Exp $ # - @@ -58,6 +58,7 @@ CP=$CP:$JASPER_HOME/classes for i in $JASPER_HOME/lib/*.jar $JASPER_HOME/jasper/*.jar ; do CP=$CP:$i +CP=$CP:$JASPER_HOME/common/lib/servlet.jar done # convert the existing path to windows @@ -71,7 +72,7 @@ # - Execute The Requested Command - -if [ "$1" = "debug" ] ; then +if [ "$1" = "jspc" ] ; then shift java $JASPER_OPTS -classpath $CP \
HttpSessionFacade
Hi, I have a question regarding the use of HttpSessionFacade. It appears that many instances of this object can wrap the same *real* session. These objects are th en recycled by tomcat (unbinding the facade from the real session). This recycli ng happens prior to the session being invalidated which can cause troubles on se rvlet objects which use the session. What are the rules that govern when a facade is recycled? Previous mailing-list threads recommend to use the context to store servlet app lication data but I'm confused as to why the HttpSession object provides an inte rface to set/get data if not for the application to store data that should be pe rsisted accross requests but used within a single session. thanks, dominic.
pathTranslated and pathInfo... More unsafe paths
But wait...
/WEB-INF/../../env.xml
is inside of
/WEB-INF/../env.xml
(see example below)
Do you have to specify all the sub-directories that a webapp uses?
Also, I've noticed an interesting and occasionsl unsafe path where a
space is being introduced just before the path I supply to
getResourceAsStream.
If I say servContext.getResourceAsStream("\path\foo.html");
I occasionally get an exception stating an unsafe path of...
w:\foo\bar\tomcat\webapps \path\foo.html
A space is being introduced just before the path I supply, but only
sometimes.
Is there a reliable way to get the document root?
PathTranslated and PathInfo don't work the way they used to.
Running Tomcat 3.2.1
-Chris
Larry Isaacs wrote:
David,
For security, web applications aren't allow to access files outside
of the web application. That is why /WEB-INF/../env.xml is okay
and /WEB-INF/../../env.xml isn't.
Larry
-Original Message-
From: David Soroko [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 13, 2001 7:53 AM
To: [EMAIL PROTECTED]
Subject: Unsafe path ?
Hi all
From within a servlet I am trying to read a file in the following way
getServletContext().getResourceAsStream(getInitParameter("envFile"));
When the parameter envFile has the value /WEB-INF/../../env.xml
I am getting the following message from Tomcat:
Unsafe path D:\Jupiter\tomcat\webapps\dir1\dir2\dir3
/WEB-INF/../../env.xml
Any ideas why is that?
Interestingly, when the parameter envFile has the value
/WEB-INF/../env.xml
Tomcat has no problems reading the file.
This is on Tomcat 3.2/Wintel.
TIA
--
Christopher Hull
Engineering Group Manager, Senior Software Architect
Mediagate Inc.
iPost Card http://web.mediagate.com/chris.hull
iPost Voice 408 261 7201
email [EMAIL PROTECTED]
Re: pathTranslated and pathInfo... More unsafe paths
On Wed, 14 Mar 2001, christopher hull wrote:
But wait...
/WEB-INF/../../env.xml
is inside of
/WEB-INF/../env.xml
(see example below)
When you start with a slash, that means you are resolving a URL relative
to some "base". The base that is used depends on the context you are
using it in:
* For things like request dispatchers, and ServletContext.getResource(),
the base is the context root of your web application.
* For things sent to the browkser, like a hyperlink:
a href="/WEB-INF/../../env.xml"Click Me/a
the link would be resolved (by the browser) against the server root
of your web server.
Do you have to specify all the sub-directories that a webapp uses?
Also, I've noticed an interesting and occasionsl unsafe path where a
space is being introduced just before the path I supply to
getResourceAsStream.
If I say servContext.getResourceAsStream("\path\foo.html");
This is actually an invalid path. URLs always use forward slashes, even
if some browsers (and some servers) let you get away with backslashes.
I occasionally get an exception stating an unsafe path of...
w:\foo\bar\tomcat\webapps \path\foo.html
A space is being introduced just before the path I supply, but only
sometimes.
Are you absolutely positive that the webapps directory is named
"webapps" and not "webapps " (with a trailing space)?
Is there a reliable way to get the document root?
You can get the context root of your webapp by calling:
String rootPath =
getServletContext().getRealPath("/");
if you are running under a servlet container that runs from unpacked
directories (like Tomcat 3.2.1 does). If you are running under a servlet
container that runs web apps directly from a WAR file, there is no such
thng as the pathname of the context root, and the above call will return
null.
PathTranslated and PathInfo don't work the way they used to.
Tomcat 3.1 had bugs in these calls -- Tomcat 3.2.1 works correctly.
Running Tomcat 3.2.1
-Chris
Craig McClanahan
Re: [PROPOSAL] The Commons - web connector
On Wed, 14 Mar 2001, Dan Milstein wrote:
I don't see the advantages to having a separate project for the connectors.
Can someone explain that to me?
I don't think the proposal meant a separate top level project, with
separate list, etc.
It meant to decouple mod_jk and the connector from tomcat 3.3
As you can see in previous mails, there are people who "will not touch any
line of tomcat 3.x".
I think mod_jk and the connector part of tomcat3.3 is a great piece of
work, with a lot of great ideas - and it doesn't depend in any way of
tomcat3.3 - the same as mod_webapp is not specific to tomcat4.0
I think it will help to have a "common" and "neutral" repository, with
the goal of creating a connector based on the best ideas from mod_jk and
mod_webapp - or ( as mod_jk is designed ) multiple protocols that are used
in by both tomcat3.3, tomcat4.0 and maybe other containers.
As I said, the connector is in charge with implementing a protocol of
communication between the server and container - it doesn't depend on
having "Interceptors" or "Valves", it doesn't depend on having 6 core
classes or 20 interfaces, it doesn't depend on having a Loader interface
or using the standard ClassLoader.
Of course, there are parts that are specific to a container - but the idea
is to share what's common.
In the same way, it would be great to develop a single set of
general-purpose utilities - like ThreadPools, MessageBytes, etc - that
will combine the best out of both codebases and may be used by others as
well. And it would be great to have common code for jasper, with
specialized classes implementing what's different - 90% of the code in
jasper3.3 and jasper4.0 is common ( but is diverging every day ).
Right now the biggest problem is the fact that some people refuse to
accept there are other ideas and solutions. This leads to duplications all
across jakarta, not only in tomcat3.3/4.0.
And the only solution I know out of this is to concentrate in what's
common, and respect the differences.
The main disadvantage that I see is that the connectors and Tomcat are very
tightly linked -- I think having one developer list for TC and the
The protocol and most of the connector is not linked in any way to the
underlying architecture of tomcat ( i.e. the Interceptor is just a
wrapper, a way to plug in the connector ).
The list, bug system, etc will stay the same, of course, it's just that
it'll be less "coupled" with tomcat3.3, and may have a more independent
evolution.
would be a nightmare to sync up with a "separate" project). But if there's
Java code in there, there's going to have to be different code for each
different engine which the connector talks to (e.g. TC 3, TC 4). Pulling
that code out of the main projects makes no sense to me. It is totally
dependent on the rest of the project code.
Tomcat 3.3 should work with mod_webapp, tomcat4.0 should work with mod_jk.
There are differences - but most of the code should be common. The C code
should be the same, and on the Java side the only thing that is different
is the interface on the upper side.
I'm not sure if I'd want to be a committer on a different project -- once
I don't think it should be a different project - but the hope is that more
commiters will contribute on a 3.3-4.0 common connector.
3.3 is released, I'm planning on working on the 4.x branch. The first thing
After 3.3 is released I guess most of us will be working on something else
- for me it'll the "next" generation of container, combining the best of
3.x and 4.x.
Having a connector that combines the best of mod_jk and mod_webapp will
be a great step in that direction.
I'd like to do (which I threatened to do a long time ago!), would be to
write an ajp13 connector and/or merge mod_webapp with mod_jk. That is
"connector" work, but I, personally, am more interested in the servlet
engine as a whole than on "just" the connectors.
Same for me. I would be happy to help in anything that is a "merge" that
combines the best of both.
Costin
( BTW, I already have a prototype and a name for the combined thing :-)
GOMEZ Henri wrote:
Still no response for this sub-project proposal.
The upcoming PMC could be an occasion to speak about it.
I saw at least 4 potentials commiters working on it :
- Dan Milstein, our resident hacker/expert of mod_jk.
- Keith Wannamaker, webdav specialist
- Pier P. Fumagalli, mod_jserv and mod_webapp father
- I, Henri Gomez, mod_jk and adaptation to Apache 2.0
We start speaking of an updated mod_jk with ajp13++ (ajp14)
which must fix current known problem like :
- lack of security between Apache / Tomcat
Tomcat accept connection from anybody to it's ajp12/ajp13
connector. We may add so trivial authentification scheme
at least at connect time.
Nothing too expensive but last days on Tomcat list there is
an interesting Thread on 'Encrypting password' ('challenge-response')
-
Re: pathTranslated and pathInfo... More unsafe paths
Wow! Thanks for the quick response.
The problem it turns out has nothing to do with spaces. When
getResourceAsStream() can't find a resource, it displays a space just
after the root for convenience. It turns out that getResourceAsStream
is case sensitive. Is there a way to tell getResourceAsStream
not to be?
Thanks;
-Chris
Craig R. McClanahan wrote:
On Wed, 14 Mar 2001, christopher hull wrote:
But wait...
/WEB-INF/../../env.xml
is inside of
/WEB-INF/../env.xml
(see example below)
When you start with a slash, that means you are resolving a URL relative
to some "base". The base that is used depends on the context you are
using it in:
* For things like request dispatchers, and ServletContext.getResource(),
the base is the context root of your web application.
* For things sent to the browkser, like a hyperlink:
a href="/WEB-INF/../../env.xml"Click Me/a
the link would be resolved (by the browser) against the server root
of your web server.
Do you have to specify all the sub-directories that a webapp uses?
Also, I've noticed an interesting and occasionsl unsafe path where a
space is being introduced just before the path I supply to
getResourceAsStream.
If I say servContext.getResourceAsStream("\path\foo.html");
This is actually an invalid path. URLs always use forward slashes, even
if some browsers (and some servers) let you get away with backslashes.
I occasionally get an exception stating an unsafe path of...
w:\foo\bar\tomcat\webapps \path\foo.html
A space is being introduced just before the path I supply, but only
sometimes.
Are you absolutely positive that the webapps directory is named
"webapps" and not "webapps " (with a trailing space)?
Is there a reliable way to get the document root?
You can get the context root of your webapp by calling:
String rootPath =
getServletContext().getRealPath("/");
if you are running under a servlet container that runs from unpacked
directories (like Tomcat 3.2.1 does). If you are running under a servlet
container that runs web apps directly from a WAR file, there is no such
thng as the pathname of the context root, and the above call will return
null.
PathTranslated and PathInfo don't work the way they used to.
Tomcat 3.1 had bugs in these calls -- Tomcat 3.2.1 works correctly.
Running Tomcat 3.2.1
-Chris
Craig McClanahan
--
Christopher Hull
Engineering Group Manager, Senior Software Architect
Mediagate Inc.
iPost Card http://web.mediagate.com/chris.hull
iPost Voice408 261 7201
email [EMAIL PROTECTED]
Re: pathTranslated and pathInfo... More unsafe paths
On Wed, 14 Mar 2001, christopher hull wrote: Wow! Thanks for the quick response. The problem it turns out has nothing to do with spaces. When getResourceAsStream() can't find a resource, it displays a space just after the root for convenience. It turns out that getResourceAsStream is case sensitive. Is there a way to tell getResourceAsStream not to be? Servlets are case sensitive. Tomcat 3.1 and 3.2 (without the .1 updates) had problems in this area that caused huge security holes because they were NOT completely case sensitive. If you still want non-case-sensitive Tomcat, well, you've got the source code ... but you are totally on your own. Thanks; -Chris Craig McClanahan
cvs commit: jakarta-tomcat-4.0/tester/web/WEB-INF web.xml
craigmcc01/03/14 19:24:13
Modified:tester Tag: J2EE_13_BRANCH build.xml
tester/src/bin Tag: J2EE_13_BRANCH tester.xml
tester/src/tester/org/apache/tester Tag: J2EE_13_BRANCH
SetBufferSize01.java TestClient.java
tester/web/WEB-INF Tag: J2EE_13_BRANCH web.xml
Added: tester/src/tester/org/apache/tester Tag: J2EE_13_BRANCH
Aggregate01.java Aggregate02.java ErrorPage01.java
ErrorPage02.java ErrorPage03.java ErrorPage04.java
Include02.java Include02a.java Jndi01.java
Jndi02.java Resources01.java Resources02.java
Resources03.java Resources04.java Session01.java
Session02.java Session03.java SessionBean.java
TesterException.java Xerces01.java
Xerces01Parser.java
Log:
Create branch for J2EE RI, and port the current unit test suite from the
HEAD branch. Currently, the following unit tests fail:
- ErrorPage: All
- Resources: #4, #5, #14, #15
- ServletResponse: #3, #4
- HttpSession: #4, #8
but these will be corrected as the corresponding bug fix patches get
ported into the branch.
Revision ChangesPath
No revision
No revision
1.1.2.1 +1 -1 jakarta-tomcat-4.0/tester/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/build.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- build.xml 2000/12/18 05:06:12 1.1
+++ build.xml 2001/03/15 03:24:06 1.1.2.1
@@ -3,7 +3,7 @@
!-- = Initialize Property Values === --
property name="build.compiler" value="classic"/
- property name="servletapi.home" value="../../jakarta-servletapi"/
+ property name="servletapi.home" value="../../jakarta-servletapi-4"/
property name="tester.build"value="../../build/tester"/
property name="tester.deploy" value="../../build/tomcat-4.0"/
property name="tester.dist" value="../../dist/tester"/
No revision
No revision
1.7.2.1 +355 -39 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- tester.xml2001/01/06 02:38:12 1.7
+++ tester.xml2001/03/15 03:24:06 1.7.2.1
@@ -2,15 +2,17 @@
!-- == Global Properties === --
property name="catalina.home" value="../../build/tomcat-4.0"/
+ property name="debug" value="0"/
property name="host" value="localhost"/
property name="port" value="8080"/
!-- property name="protocol" value="HTTP/1.0"/ --
property name="protocol" value=""/ !-- Use HttpURLConnection --
property name="context.path" value="/tester"/
+ property name="manager.path" value="/manager"/
taskdef name="tester" classname="org.apache.tester.TestClient"/
- target name="all"
depends="ROOT,CaseSensitive,RequestDispatcher,ServletRequest,ServletResponse"/
+ target name="all"
depends="ROOT,CaseSensitive,ErrorPage,Jndi,RequestDispatcher,Resources,ServletRequest,ServletResponse,HttpSession"/
target name="ROOT"
@@ -19,9 +21,19 @@
!-- Should be able to see the home page --
tester host="${host}" port="${port}" protocol="${protocol}"
- request="/index.html"
+ request="/index.html" debug="${debug}"
status="200"/
+!-- Should be able to use relative path to document root --
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="/examples/.." debug="${debug}"
+ status="302"/
+
+!-- Should not be able to use relative path above document root --
+tester host="${host}" port="${port}" protocol="${protocol}"
+ request="/examples/../.." debug="${debug}"
+ status="404"/
+
/target
@@ -31,119 +43,372 @@
!-- Make sure that static resources are matched case sensitively --
tester host="${host}" port="${port}" protocol="${protocol}"
- request="/index.HTML"
+ request="/index.HTML" debug="${debug}"
status="404"/
!-- Should be able to execute the Date example --
touch file="${catalina.home}/webapps/examples/jsp/dates/date.jsp"/
tester host="${host}" port="${port}" protocol="${protocol}"
- request="/examples/jsp/dates/date.jsp"
+
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
remm01/03/14 21:34:56
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
Log:
- Add org.apache.naming as a prefix in the
javax.naming.Context.URL_PKG_PREFIXES property.
Revision ChangesPath
1.17 +5 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- Catalina.java 2001/02/26 03:52:47 1.16
+++ Catalina.java 2001/03/15 05:34:56 1.17
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.16 2001/02/26 03:52:47 glenn Exp $
- * $Revision: 1.16 $
- * $Date: 2001/02/26 03:52:47 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
1.17 2001/03/15 05:34:56 remm Exp $
+ * $Revision: 1.17 $
+ * $Date: 2001/03/15 05:34:56 $
*
*
*
@@ -97,7 +97,7 @@
* /u
*
* @author Craig R. McClanahan
- * @version $Revision: 1.16 $ $Date: 2001/02/26 03:52:47 $
+ * @version $Revision: 1.17 $ $Date: 2001/03/15 05:34:56 $
*/
public class Catalina {
@@ -673,7 +673,7 @@
String oldValue =
System.getProperty(javax.naming.Context.URL_PKG_PREFIXES);
if (oldValue != null) {
-value = oldValue + ":" + value;
+value = value + ":" + oldValue;
}
System.setProperty(javax.naming.Context.URL_PKG_PREFIXES, value);
System.setProperty(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
cvs commit: jakarta-tomcat/src/shell tomcat.sh
costin 01/03/14 23:33:19
Modified:.changes3.3
src/share/org/apache/tomcat/modules/config
ProfileLoader.java
src/share/org/apache/tomcat/modules/server
Ajp12Interceptor.java
src/share/org/apache/tomcat/startup Tomcat.java
src/shell tomcat.sh
Log:
Few more usability changes ( in the main branch )
- generate the ajp12.id file when the server is moving to "READY" state,
i.e. after all initialization ( including starting the connectors )
- added -wait option to tomcat.sh, so that the script returns when the
server is ready ( it just looks for ajp12.id file )
- added -noout option to redirect the stdout/stderr to a file
- 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 :-)
- also, the -security option is no longer processed in the shell script,
it is part of the java start code ( and all config is now in server.xml,
including the policy file - no need to edit the shell script )
The first 2 changes will make it easier to write test scripts (
tomcat.sh will return when it's ready and you can start sending request ).
None of them should affect existing use - but may simplify some tasks
Please review - I don't know if this is needed in the BAT files
( you don't have a kill command, etc )
Revision ChangesPath
1.9 +19 -0 jakarta-tomcat/changes3.3
Index: changes3.3
===
RCS file: /home/cvs/jakarta-tomcat/changes3.3,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- changes3.32001/03/13 23:43:47 1.8
+++ changes3.32001/03/15 07:33:17 1.9
@@ -113,6 +113,24 @@
BUILD/STARTUP
+- On startup, after the server is initialized, the Ajp12Interceptor will
+ generate conf/ajp12.id containing it's port and secret ( if any ), to
+allow easy stop.
+
+- the unix start scripts now take a "-wait" option ( "tomcat.sh start -wait" )
+making the script wait until the server is started. This is good for
+automated tests.
+
+- the unix scripts will generate a conf/tomcat.pid file with the pid
+of the java process that is put in background. This should be used as
+a last resort if normal shutdown fails.
+
+- the -security option is passed and processed in Java. All sandboxing
+options are specified using PolicyInterceptor ( including the
+policy file, etc ) - the command line is no longer used. This allows
+people embeding tomcat the same control and reduces the complexity of
+the shell script.
+
- org.apache.tomcat.startup.Main now builds 3 distinct class loaders: (1)
one to be used only by the servlet container. (2) one to be shared by all
web applications and (3) one that is common to both the above.
@@ -123,6 +141,7 @@
to the 'apps' and 'common' classloaders by including them in the classpath
properties "-Dorg.apache.tomcat.apps.classpath" and
"-Dorg.apache.tomcat.common.classpath", respectively.
+
- generate separate jar files for each component ( utils, core, facade,
modules ) That insures the layers are properly separated, utils can be reused.
1.4 +1 -1
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ProfileLoader.java
Index: ProfileLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ProfileLoader.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ProfileLoader.java2001/03/08 18:42:43 1.3
+++ ProfileLoader.java2001/03/15 07:33:18 1.4
@@ -363,7 +363,7 @@
ClassLoader appLoader;
Vector modules=new Vector();
-public Profile() {};
+public Profile() {}
public String getName() {
return name;
1.13 +6 -2
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp12Interceptor.java
Index: Ajp12Interceptor.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp12Interceptor.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Ajp12Interceptor.java 2001/02/07 07:01:25 1.12
+++ Ajp12Interceptor.java 2001/03/15 07:33:18 1.13
@@ -101,10 +101,14 @@
secret=s;
}
-public void engineInit(ContextManager cm )
+public void engineState(ContextManager cm, int state )
throws TomcatException
{
- super.engineInit(cm);
+ if( state!=ContextManager.STATE_START )
+ return;
+ // the engine is now started,
Re: cvs commit: jakarta-tomcat/src/shell tomcat.sh
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
