Re: [VOTE] Release Tomcat 3.2.4
Vote to release the tomcat_32 branch as Tomcat 3.2.4. [ ] +1. I agree with the proposal and I will help support the release. [X] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Asking Tomcat 4.x to accept a different JNDI initial factory
Hi Remy,
I know that you are busy but may I know when we will see this change?
I just checked the CVS repository about 1 hour ago and it's not there
yet. Will it make it into the next release? We are trying to debate when
we should move to Tomcat 4 as we are currently on Tomcat 3.
thanks a lot!!!
Oops. I forgot. Sorry.
Remy
On Monday, November 5, 2001, at 03:53 PM, Remy Maucherat wrote:
Hi folks,
Tomcat 4.x has its own JNDI server. But I would like it to use a
different initial factory. One of the ways is to pass the value
-Djava.naming.factory.initial=com.mycompany.rmi.jndi.CtxFactory
But Catalina.java has hard coded
org.apache.naming.java.javaURLContextFactory as its factory,
completely ignoring the System property. I added the codes to
Catalina.java (see diff below). Is my analysis correct? If not, what
should I do?
Thanks, hanming
% cd jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup
% diff Catalina.java Catalina.java.org
452,455d451
value =
System.getProperty(javax.naming.Context.INITIAL_CONTEXT_FACTORY);
if (value == null) {
value =
org.apache.naming.java.javaURLContextFactory;
}
457c453
value);
---
org.apache.naming.java.javaURLContextFactory);
Yes, doing that may be more reasonable. I'll apply the patch.
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] New committer: Michael Smith
Hi, I'd like to nominate Michael Smith [msmith at apache.org] as a committer on the Tomcat subproject. Michael already has commit access on the Slide subproject, and has contributed important bug fixes for Tomcat 4 as well as mod_jk. He has my +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH: jakarta-tomcat-connectors build on MSVC6
On Mon, 19 Nov 2001, Remy Maucherat wrote: In general, I think all jakarta commiters should have cross-project permissions - maybe with the additional requirement that you need a review-then-commit process when commiting to a project you are not 'regular' commiter. There are many 'integration' bugs ( project X doesn't work with project Y ) that would be solved much quicker this way. But this is something for the PMC to decide. I'll vote +1 for any apache commiter ( i.e. jakarta, xml, httpd... ) who wants to become a commiter on tomcat. Good, but according to the current policy, it's not automatic, so I'm posting a regular vote. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.1 Security Changes
Currently, all supporting jar files for servlets which come with Tomcat 4 are placed in the $CATALINA_HOME/server/lib directory with the Tomcat 4 core jar files. This is a potential security problem because the default catalina.policy grants AllPermission to all jar files located in $CATALINA_HOME/server/lib. I don't think the default policy for these servlets should be AllPermission. Especially for the SSI and CGI servlets. If you give the appropriate permissions to allow SSI and CGI, you're actually giving AllPermissions anyway (since you're allowing a native script or executable to run, which is not constrained by the Java sandbox), so I'm missing the point here. To make the default catalina.policy more secure and make configuring security policies easier, I recommend the following changes: 1. Create $CATALINA_HOME/servlets/lib and $CATALINA_HOME/servlets/classes. This is where global servlets provided with Tomcat 4 can be installed. 2. Move the following jar files into $CATALINA_HOME/servlets/lib servlets-cgi.renametojar servlets-common.jar servlets-default.jar servlets-invoker.jar servlets-manager.jar servlets-snoop.jar servlets-ssi.jar This one is disabled by default too. servlets-webdav.jar 3. Update the class loader creation in Bootstrap.java for the catalina loader to look for jar files and classes in $CATALINA_HOME/servlets in addition to $CATALINA_HOME/server. 4. Update the default catalina.policy so that it provides explicit permissions for each jar file in $CATALINA_HOME/servlets/lib. 5. Update the documentation regarding the above changes. Please vote +1 so I can implement the above changes. This seems reasonable. (Of course, it's going to break all the scripts yet again ;-)) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.0.1 ClassLoader breaks singletons on webapp reload.
OK. I have a webapp deployed with the main package under WEB-INF/classes and all dependent libraries under WEB-INF/lib as .jars. If I recompile my application, update the necessary classes in WEB-INF/classes, Tomcat does manage to reload the app but my application is now totally hosed. The reason is that Tomcat didn't just reload the changed classes but it reloaded everything including the all classes under WEB-INF/ Is there anyway I can tell Tomcat to JUST reload the changed classes and not the whole webapp? No. A class loader can only load one class once (you can't have it forget a class that has been loaded before). The problem is that any singletons I have (which depended on correct initialization) are now broken and I have lost all state. I remember talking to Craig about ClassLoaders a while back and he mentioned that the JVM has now way for a ClassLoader to unload a class so they have to start out with a new ClassLoader. Is there any way around this? No. Of course, there's a reason for this, as a selective reloading would be a very complex thing to do. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.0.1 ClassLoader breaks singletons on webapp reload.
Remy Maucherat [EMAIL PROTECTED] writes: OK. snip No. Of course, there's a reason for this, as a selective reloading would be a very complex thing to do. So what patterns do developers follow when the want to deploy webapps with singletons that have support for reloading? You can probably use the servlet lifecycle events (init and destroy) for this. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4.1 Security Changes
Remy Maucherat wrote: If you give the appropriate permissions to allow SSI and CGI, you're actually giving AllPermissions anyway (since you're allowing a native script or executable to run, which is not constrained by the Java sandbox), so I'm missing the point here. Yes, once control is handed over to a native executable from the CGI servlet, all sandbox protections are lost. But perhaps the Tomcat admin only wants to allow the user to execute specific CGI scripts which are known to be secure and can not be modified. By configuring a policy for the CGI servlet the admin can restrict what CGI scripts can be read and executed using a FilePermission. Yes, you could do that. That's still quite risky (any vulnerability in the script itself, and your server is compromised). This seems reasonable. (Of course, it's going to break all the scripts yet again ;-)) Which scripts? - The Catalina scripts (obviously) - The installer scripts - My Slide build script But it's ok, really. It's not like it's the first time or the last time it happens ;-) You can do the updates to the Catalina scripts, and I'll do the rest. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/binsetenv.shcatalina.sh tool-wrapper.sh
on 11/27/01 3:09 PM, Patrick Luby [EMAIL PROTECTED] wrote: Jon, What I could do is not distribute the setenv.sh file and, instead, check for the existence of this file. If it exists (which would only occur if the user has created the file), then catalina.sh and tools-wrapper.sh would source it. I think that would comply with your requirement. Yes. Also, should we put the setenv.sh somewhere else as well. In documentation. If the above sounds OK, I can cvs remove the setenv.sh file and make the sourcing conditional. Yes. Thanks for the quick response. Just as a side note, we need to be more cautious about upgrades and how users perform them. The server.xml is a big sore spot as well because that is another file that needs to be changed by the users. Yes. I'm very cautious in the Windows installer to not overwrite the config files. It has lots of problems (which are slowly getting resolved), but not that one ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] Tomcat 4.0.2 Release Plan
Hi, I think it's the appropriate time to consider starting a new release cycle for Tomcat 4.0. There has been a variety of significant bugs fixed since 4.0.1 (although there hasn't been any fixes for any showstopper bug). I don't plan to propose a formal release plan for this release, as it is a bugfix-only release, and it will be released as soon as there are no more must-fix issues remaining in the most current release candidate. - A few more code merge will happen between now and the first beta release (at least one to add JAVA_HOME support in the install script). - The release notes will document all the fixes which occured since 4.0.1. - The release notes will list the must-fix bugs. This generally includes bugs whose severity in Bugzilla is 'blocker' (P1), 'critical' (P2) or 'major' (P3). - Tomcat 4.0.2 won't have any regressions over 4.0.1. - All betas for 4.0.2 should be considered release candidates if the must-fix issues list is empty. - Tomcat 4.0.2 beta 1 should be released between 12/02 and 12/16. - This vote will run until 12/01. ballot [ ] +1: I approve this plan, and I'll help [ ] +0: I approve this plan [ ] -0: I'm against this plan, but I won't veto it [ ] -1: I'm against this plan, and my reason is: /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 4.0.2 Release Plan
On Tue, 27 Nov 2001, Remy Maucherat wrote: - A few more code merge will happen between now and the first beta release (at least one to add JAVA_HOME support in the install script). - The release notes will document all the fixes which occured since 4.0.1. - The release notes will list the must-fix bugs. This generally includes bugs whose severity in Bugzilla is 'blocker' (P1), 'critical' (P2) or 'major' (P3). - Tomcat 4.0.2 won't have any regressions over 4.0.1. - All betas for 4.0.2 should be considered release candidates if the must-fix issues list is empty. - Tomcat 4.0.2 beta 1 should be released between 12/02 and 12/16. - This vote will run until 12/01. ballot [ ] +1: I approve this plan, and I'll help [X] +0: I approve this plan [ ] -0: I'm against this plan, but I won't veto it [ ] -1: I'm against this plan, and my reason is: There are few things I would like to see fixed before releasing: - the jvmroute ( I'll do a patch if nobody else does it ) Well, I'm not going to do it, since I can't really test it. - backporting the 'trusted apps having access to catalina internals' from 4.1 Really ? Why's that ? I was planning not to port that change. I would be happier to see 4.0.2 released a bit later, I hope we can freeze j-t-c/mod_jk around 12/15, but we need few weeks for testing. If 4.0.2 is released on 12/16, it needs to use a branch ( same code as in 4.0.1 ). And since when do you care about 4.0 schedule ? ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 4.0.2 Release Plan
There are few things I would like to see fixed before releasing: - the jvmroute ( I'll do a patch if nobody else does it ) YES PLEASE +1, will give tomcat 4.0 access to load balancing feature of mod_jk ;) Ok, I'm all for it, but one of you guys will have to implement it ;) - backporting the 'trusted apps having access to catalina internals' from 4.1 I would be happier to see 4.0.2 released a bit later, I hope we can freeze j-t-c/mod_jk around 12/15, but we need few weeks for testing. If 4.0.2 is released on 12/16, it needs to use a branch ( same code as in 4.0.1 ). The dates were for 4.0.2 beta 1. Since it is a bugfix release, the final was supposed to go out only when we're happy with the bugs status. Yes, could we wait some time and fix one of the problem of users about the webconnector ? I'm still working on packaging mod_webapp, (yes yes) against the recent Apache 2.0.28 beta Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Committer: Jazmin Jonson
As Bill Barker suggested, I would like to propose Jazmin Jonson as a new committer. She has contributed a numerous patches to Tomcat4 admin application. Votes please? +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 4.0.2 Release Plan
[EMAIL PROTECTED] wrote: - backporting the 'trusted apps having access to catalina internals' from 4.1 How exactly is the 'trusted apps having access to catalina internals' implemented? The parent CL is the Catalina CL (instead of being the shared CL). Recently some of that code in the WebappClassLoader was reverted after I demonstrated that the Java SecurityManager and a catalina.policy could prevent access to catalina internals. I also posted a proposal last week recommending some changes in where the servlet jar files were located to make it easier to write a policy file and prevent inadvertant granting of AllPermission to servlets in $CATALINA_HOME/server/lib. IMHO, if the SecurityManager is used, it is the only thing that would be needed to control security of 'trusted apps'. At one point Craig and I discussed making use of the Java SecurityManager the default way to start Tomcat 4. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/servlet JspServlet.java
kinman 01/11/29 11:40:52 Modified:jasper/src/share/org/apache/jasper/servlet JspServlet.java Log: PR: 5169 Submitted by: [EMAIL PROTECTED] (Ryan Lubke) -- Spec says jsp_precompile=false means jsp_precompile=true (weird, huh?). Fix to conform. I'm confused ! Why don't we just return true all the time, then ? ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
patrickl01/11/29 09:18:10 Modified:catalina/src/share/org/apache/catalina/startup Catalina.java Log: Fix for situation where an SSL connector is enabled but external dependencies (e.g. no .keystore file, etc.) are not correctly installed. Previous to this change, Tomcat would never invoke Lifecycle.start() if any connectors threw an exception. Hence, Tomcat appear to be hung. With this change, Tomcat will now properly start all connectors that are properly configured and won't get hung up by any improperly configured connectors. If desired, I can backport this change to the tomcat_40_branch for the upcoming 4.0.2 release. I don't agree. If server.initialize throws an exception, why would we want to try to start it anyway (just in case it manages to be able to do something). I think we should not call await (and shutdown) if something went wrong during init. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat classloader problem?
I'm hoping someone here can help me with this. The folks on soap-user directed me to tomcat-user, and the tomcat-user folks suggested I try tomcat-dev. So here I am... I'm experiencing a problem with SOAP message-style services when using Tomcat 4.01. When trying to access any message-style SOAP service, my client receives a no signature match fault. I have no problem with RPC-style SOAP services, the same message-style SOAP services work fine with Tomcat 3.2.3, and the signature of the my message-style services is of the correct form; ie: public void serviceName( Envelope env, SOAPContext req, SOAPContext res ) throws IOException, MessagingException; What makes me think that this may be a Tomcat classloader problem is that I can make the fault go away by removing $CATALINA_HOME/webapps/soap/WEB-INF/classes/org/. But I don't understand why this makes the fault go away, and it's clearly an unacceptable hack. I've attached the following: details.txt-- detailed problem description echomsg.tar.gz -- a simple example details Any help in correcting/understanding this will be appreciated. Sorry for the size of this post, but I'm trying to provide all of the details necessary to resolve this. Thanks, The problem is that there are class conflicts, as half of the SOAP classes are in the webapp CL, and will be loaded from there (since the CL won't delegate), and the rest will be loaded from the shared CL. The conflicts will occur because the SOAP classes loaded from the shared CL will also load a different copy of the same SOAP classes from soap.jar. Moving soap.jar to $CATALINA_HOME/webapps/soap/WEB-INF/lib/soap.jar should solve the problem, and could be used as a workaround. Alternately, you can remove from $CATALINA_HOME/webapps/soap/WEB-INF/classes/ the classes which are also present in the JAR. Note: I don't consider this a Catalina problem, but more a questionable packaging choice of the SOAP binary. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0.1 and persistent connection problem
Dear Sir I already did some research about this problem. But still be confused. I want to take advantage of the persistent connection of Http/1.1. In my experiement, if HTTP/1.1 client connects to the tomcat 4.0.1 Http/1.1 directly, the persistent connection can be established. However, it is usless because actually all companies employ http proxies. Furthermore, a lot of them such as the squid is a http/1.0 proxy. in my application, the client (http/1.1) - squid proxy(http/1.0) tomcat 4.0.1.(Http/1.1) I found that tomcat 4.0.1 always sends a FIN package after it sends the response even i send the Connection: Keep-Alive in the request header. Also, I know the tomcat does also received Connection: Keep-Alive header via proxy. I did a comparison between tomcat4.0.1 and apache 1.3.9, the results show that if If I add Connection: Keep-Alive header in the request, apache server will keep the connection alive even the proxy/client sends a HTTP/1.0 package. However, It seems that tomcat 4.0.1 doesn't support this feature. I think this feature isn't defined in specification, however, it is so important that it provide the only way(am i right?) to establish persistent connection in real world which is consisted of unexpected HTTP/1.0 proxies. I don't know whether my understanding is correct or not. Any comments are welcome. That's correct. Tomcat 4 doesn't support legacy HTTP/1.0 keepalive. As usual, if you want to have it fixed you can contribute patches. Keepalives over HTTP/1.0 are not that useful in a JSP / servlets environment, as in many many cases, the content-length of the response is not set. Overall, I think it's time for HTTP/1.0 to go away (1.1 has been around for some time now). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK versions
There is an important issue to discuss - labeling mod_jk. As you know, we are trying to make some improvements in jk, start using APR, etc. That will involve few significant changes - and some people may want to have a more 'stable' jk. There are 4 versions of jk: Let's call 1.0 what is present in tomcat3.2.x repository. Let's call 1.1 what is present in 3.3 repository. It is backward compatible with Jk1.0, has many fixes, etc. 1.2 - what is in jakarta-tomcat-connectors/jk, the same as 1.1 plus support for Apache2.0 ( Jk1.1 doesn't support apache2.0 since it wasn't available at that time ). This version also have support for tomcat4.0 and initial code for ajp14. I would call '1.2' the version that was in CVS around Oct 15 ( i.e. after both 3.3 and 4.0.1 were released, before any refactoring was started ). So far all the changes in the main tree were small. However some biger changes are needed and are already in progress. We'll have a simpler build system, support for APR, lot more flexibility, simpler configuration. I would like to call the next version of jk 2.0, as a number of internal APIs will change. ( all those numbers are made up - we can call them 1, 2, 3, 4 instead of 1.0, 1.1, ... ). What I would like to do is make a branch for mod_jk 1.2, and eventually build a snapshot. Eventually we should start a release plan and have a vote on the names and such. Since names/labels/versions are allways fun thing to discuss, I'm open to any other naming scheme - but we need to have one, it's extremely confusing otherwise. I will not check anything else into mod_jk until this is decided ( since my next commit is pretty big and likely to brake things, I did a lot of changes in uri_map, etc. - I need a stable branch labeled before doing the commit ). +1. Tag it (or branch it) ! Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] about kjc
Hi, tomcat users and developrs! /* I have post this patch twice. This is third time. */ Do you know kjc which is one of the completely opensource Java compiler? If not, you can see detail at http://www.dms.at/kopi. Accoding to Edouard G. Parmelan's report (http://rpmfind.net/tools/Kaffe/messages/1291.html), KJC HAVE BEATEN SUN'S JAVA COMPILER since version 1.5 about JLS compatibility. It was a grate news for Java open source community;) I and teik-san (san means Mr. in Japanese) wrote two kjc plugin for tomcat. One is for 3.3.x, and the other is for 4.0.x. If you take kjc plugin, it's good advertisement and help for kjc. Do you respect opensource? If so, could you take them? BTW, kjc is distributed under GPL. But you can take these patch in legal. Because you don't need to include kjc in tomcat. When you want to use kjc, only then you have to include it. In the fact, I wrote kjc plugin for Ant and it's really in it. So, you can also use kjc with Ant fine:) +1 for this patch as it is legal since it uses reflection. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] about kjc
On Sat, 1 Dec 2001, Jon Stevens wrote: +1 for this patch as it is legal since it uses reflection. Remy I thought that using reflection to work with GPL code was still considered illegal by the FSF. As long ASF/jakarta doesn't have a list of 'accepted licences' that we can include/bundle with our code, and most jakarta projects already depend/bundle lots of proprietary code, I don't see why this patch would be a problem. It doesn't require us to distribute GPL code. Yes, I don't really see any problem here. If the ASF feels it's still not OK, then I'll remove the file (it's fully independent from the rest). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AJP Todo
Hi, On the TODO list for AJP, there is: - Implementing jvmroute. - Adding a mechanism like there is in Tomcat 3.3 to automatically generate a configuration file. That should be relatively easy to do using a server listener (or a host listener). I'm not going to do either of these. I have no clue how to do the first one, and no time to do the second one. So I'm counting on all the guys who voted +1 for supporting AJP 1.3+ on Tomcat 4. I did bootstrap the porting of the docs already, and I've also fixed the problems with compiling against the CVS HEAD, so I think I've done my part :) If you want to see full support for AJP in TC 4.0.2, it's up to you guys :) If people are willing to actively support it, and if the risk for creating a security vulnerability is low, we could also enable the AJP 1.3 connector and the server listener by default (and declare it officially supported), so that 4.0.2 behaves almost like 3.3 for AJP 1.3 related stuff. Thanks, Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
On Sat, 1 Dec 2001, Bill Barker wrote:
I have no objection to help porting ${Server}Config to 4.x, but I'm
still a
Catalina novice. The 3.3 API is more command and control, so it is
easier
to get to the information. It will take me a little time to find out
how to
get the servlet-mappings in Catalina.
I'm a bit unhappy with the config generator in 3.3 - I think we can do
better.
If you want to work on this, it would be great to make it a bit more
independent of the container. Right now it is very tightly coupled,
in order for it to work you need to start tomcat, it doesn't work very
well with context reloads, etc.
I'd leave it being tied to the container, and getting the lifecycle /
container events. It's (at least it should be) a simple piece of code, and
although most of the code could be static utility methods, I'd implement the
wrapper as a listener, instead of a webapp.
Of course, we don't have any way to change the mappings without restarting
apache, but that can be fixed as we add more ajp14 features ( jk_uriMap
can be changed at run time, we just need the protocol support to send
update requests ).
One idea was to generate a .properties file for each webapp, following the
same style with webapps/ directory. If a webapp is reloaded we can
regenerate the app's mappings and get jk to reload only that file.
We could also use a bit of XSLT or a xmlmapper to do that from web.xml,
without starting the server. This would allow the configuration to be done
'off line'.
Tomcat 4. I did bootstrap the porting of the docs already, and I've also
fixed the problems with compiling against the CVS HEAD, so I think I've
done
Great, many thanks !
my part :) If you want to see full support for AJP in TC 4.0.2, it's up
to
you guys :)
Well, if you can also port the 'trusted app' - it would be really great.
I said I would, but it will require adding a few method to the Context
interface (so please, no screaming over API breakage ;-)).
Remy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK versions
I will not check anything else into mod_jk until this is decided ( since my next commit is pretty big and likely to brake things, I did a lot of changes in uri_map, etc. - I need a stable branch labeled before doing the commit ). Ok, let's release mod_jk to 1.2 and start 2.0. The refactoring is massive but until it will be finished we'll need a running and working mod_jk. What we should do : - Release it (1.2) - make binaries for all knowns platform (Apache w/o SSL, IIS, iPlanet, Domino) - Create a link to this repository which could be used by both Tomcat 3.2, 3.3, 4.0 - And may be start to think about creating web pages for J-T-C +1. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ErrorReportValve
Em Quinta, 6 de Dezembro de 2001 10:54, Pedro Morais escreveu: Hi! I've being looking at the code for TC 4.0.1 and I think it's impossible to disable the ErrorReportValve. Ok, replying to my own email. I've found out that I can set the errorReportValve value on an Host element; there problem is, I havent been able to find a valid way to set it to null. Do you think this patch is valid? It ignore the class name if it's the empty string. If you give it a non-existing class, that would also get the job done (although it will print out a nasty stack trace; I'll remove that too). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [j-t-c] ajp and headaches
- Original Message - From: Kevin Seguin [EMAIL PROTECTED] To: Tomcat-Dev (E-mail) [EMAIL PROTECTED] Sent: Sunday, December 09, 2001 12:07 PM Subject: [j-t-c] ajp and headaches after many months of being away, i've recently gotten back into the fray of jakarta-tomcat-connectors. my goal is as it was many months ago - an ajp (v1.3) connector for tomcat 4. after discovering that things are not working entirely correctly on the HEAD of cvs, i started digging into the code in both places. maybe it's just me, but i found trying to follow the java code particularly painful. i realize there is some development and refactoring going on with ajp14 and all, but man!, it ain't pretty in there :) As far as the Java portion of the connector is concerned, the code is based on the current HTTP connector, which I don't think is very good (obviously, I don't like it at all, I wouldn't be experimenting with rewriting it otherwise). so, partly out of sheer necessity, and partly because i think it would be useful, i'm considering doing a major rewrite - no, let's call it refactoring :) - of the java code in j-t-c/jk. the goal would be correctness, clean up and simplification. i would start with ajp13, but keep in mind there is ajp14, ajp15, etc., to come. i think i would do this on a branch, too, call it ajp_refactoring, or something like that. what are the thoughts on this? I also think a refctoring is needed. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AJP Todo
If the web app is deployed as a directory, you can call context.getDocBase() for this. If the context is deployed as a WAR file, there is no such thing as the document base as an absolute path. In such a scenario, you need to choose one of the following options: Unfortunately, if the context is declared in server.xml, getDocBase returns the docBase declared in server.xml (e.g. examples in the shipping server.xml). I can't see how to turn this into an absolute path. * Forward *all* requests to Tomcat for processing This is my preference. The problem is determining if it is deployed as a WAR file or not given the context. This one is probably just my stupidity however :). You should be able to use Context.getResource and then use instanceof to see if it's a FileDirContext, a WARDirContext or something else altogether (in which case, you should do the same as if it was a WAR, I think). * Reject a webapp that is deployed this way Please don't do that :) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Thread Behaviour
It seems like tomcat has no control about the threads that were opened, any suggestions, please? Yes, no attempt is being made at killing processing threads that were created. OTOH, they should be reused if some high load situation occurs again (no new threads will be created). Unless you're really short on OS resources, I don't see that being a huge problem. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/webapp/java WarpConnector.java
Ah! That is why it stops building against 4.0.1 ;-(
That's a backward compatible change, and it's very low impact. If you add
the method, it will still build with 4.0, 4.0.x, and the HEAD branch.
Remy
[EMAIL PROTECTED] wrote:
remm01/11/30 23:20:29
Modified:webapp/java WarpConnector.java
Log:
- Add the findLifecycleListeners method, so that webapp builds against
the
HEAD of the CVS.
Revision ChangesPath
1.26 +8 -0
jakarta-tomcat-connectors/webapp/java/WarpConnector.java
Index: WarpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/webapp/java/WarpConnector.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- WarpConnector.java2001/10/31 08:10:29 1.25
+++ WarpConnector.java2001/12/01 07:20:29 1.26
@@ -449,6 +449,14 @@
}
/**
+ * Get the lifecycle listeners associated with this lifecycle. If
this
+ * Lifecycle has no listeners registered, a zero-length array is
returned.
+ */
+public LifecycleListener[] findLifecycleListeners() {
+return lifecycle.findLifecycleListeners();
+}
+
+/**
* Remove a codeLifecycleEvent/code listener from this
* codeConnector/code.
*
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTES] Tomcat 4.0.2 beta 1
Hi, After some delay, I'd like to release the first beta of Tomcat 4.0.2 this week (the sooner, the better, so I plan to package the release as soon as this vote is considered approved). This release has already been approved, and although there are some issues which will need to be addressed before 4.0.2 final is released, there is no open showstopper problems. A few additional fixes may be made before beta 1 is released. The list of changes and fixes is available at: http://cvs.apache.org/viewcvs.cgi/~checkout~/jakarta-tomcat-4.0/Attic/RELEAS E-NOTES-4.0.2-B1.txt?rev=1.1.2.4 ballot [ ] +1: Make the release [ ] -1: I'm opposed to the release until the following issues are fixed: /ballot There is also a new feature that has been added in the HEAD branch which could be worth porting: the instance pooling for STM servlets. I wrote the code as an experiment, but it appears to be working very well (I didn't notice any thread safety issues during load testing). ballot [ ] +1: Add the feature to the 4.0 branch [ ] -1: Don't add the feature, because: /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0.2 beta 1
The stuff I'd like to see added in TC 4.0.2 (release) is vmroute for supporting load-balancing via mod_jk ? What about ? I thought Costin wanted to do it in another way in his JK2 connector ? There's also the auto configuration which isn't going to be very well documented or working in the first beta, but will be in the final. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JK binaries
Hi, I'm trying to figure out what I should do with the AJP binaries, as the CVS is a bit messy at the moment (and it includes two versions of the sources). I can: - keep the current binary for b1 - try to upgrade, but I'd like to know which one I should use (and the build script should be fixed) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Connector compatibility between TC 4.0 and 4.1
Hi, After a lot of efforts, it turns out the connectors (in j-t-c) still can't be compiled against both the 4.0 branch and the HEAD branch of the Tomcat CVS. There are a few solutions to this: 1) Force the connectors to be built against the HEAD branch. They should run fine on Tomcat 4.0 (although that needs some testing). 2) The main problem is the move of the ServerSocketFactory interface from o.a.c.net to o.a.c. We could revert that change, and fixing the rest is extremely simple. Which one do you think is best ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
4.0.2-b1 binaries uploaded
Hi, I've finished uploading the 4.0.2-b1 binaries: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.2-b1/ All known packaging issues over 4.0.1 should have been fixed (gifs corruption, installer not finding JDK, and probably others). The RPMs and the connector native binaries are not there yet. The beta release does not include updated versions of the JK or WARP protocols; they will be updated in a later beta of Tomcat 4.0.2. I'll post the official announcement later today or tomorrow (and the CVS tag will be placed at that time), so there's still time to fix problems. If something is wrong, please let me know. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JK binaries
i take it all back :) i just updated j-t-c/jk and i can't build it. and i don't have time to try to figure it out right now. sorry. so, maybe it's best for now to go with the current binary. Yes, we're in the middle of Costin's refactoring, so it's not a very good time to upgrade. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
[EMAIL PROTECTED] wrote: Keeping all container adapters in j-t-c has the extra benefit that we can share more code among them. It still feels wierd to me. Imagine if JNDI did things this way... we'd have to have every provider installed just to build it. :) I think if the layer of abstraction is at the right point you can get a compromise between code reuse and modularity. Otherwise, since the container adapters are in a different module than the containers themselves, there are always going to be cases where container improvements break the connector build. This is because they are tagged differently, etc.. Right now it seems to be structured that j-t-c is the application and the containers are its libraries. It seems like it should really be the other way around. But that's just my non-committer $0.02. And I run Tomcat stand-alone anyway... the engineer in me just had to say something. :) The standalone connector (at least the future version of it) for TC 4.x is also in j-t-c, and I'd like it to work with both versions of TC with only one codebase. Why ? It saves time, and that also avoid mistakes (like forgetting to apply a patch on one of the versions). This connector would then be optional with TC 4.0.x (use it if you need better performance), and would be the default in the next 4.x release (if of course, it turns out it's better than the current one). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Connector compatibility between TC 4.0 and 4.1
On Thu, 20 Dec 2001, Remy Maucherat wrote: Hi, After a lot of efforts, it turns out the connectors (in j-t-c) still can't be compiled against both the 4.0 branch and the HEAD branch of the Tomcat CVS. There are a few solutions to this: 1) Force the connectors to be built against the HEAD branch. They should run fine on Tomcat 4.0 (although that needs some testing). If we add void setFactory(org.apache.catalina.ServerSocketFactory $1), then it'll be impossible to build it against 4.0. If we don't - it's impossible to build against 4.1. 2) The main problem is the move of the ServerSocketFactory interface from o.a.c.net to o.a.c. We could revert that change, and fixing the rest is extremely simple. That's the only solution AFAIK. The proposal was heavily weigthed towards 2), since I think it's the only acceptable solution. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java
A 4.x person might want to take a look to make sure this doesn't happen there, too. It doesn't. GET /index.html HTTP/1.1 Host: localhost If-modified-since: Thu, 20 Dec 2001 21:37:49 GMT HTTP/1.1 304 Not Modified Date: Thu, 20 Dec 2001 21:40:01 GMT Server: Apache Tomcat/4.1-dev (HTTP/1.1 Connector) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
craigmcc01/12/21 10:42:23 Modified:catalina build.xml Log: Do not compile org.apache.naming.NamingService unless JMX is present. It looks like I had missed that one. Thanks for fixing it :) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
glenn 01/12/26 03:00:55 Modified:catalina/src/share/org/apache/catalina/startup Catalina.java Log: Something changed recently causes the catalina java process to hang at this point on shutdown unless there is an explicit System.exit(). Could this have something to do with the STM changes? It does work fine for me. The change is a bad idea anyway, since the shutdown is asynchronous (it would be almost equivalent to not attemping to shutdown and kill the process). Moved the removeShutdownHook() call after server.stop() to ensure that server.stop() doesn't get called a second time by the CatalinaShutdownHook. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Catalina.java
Remy Maucherat wrote: It does work fine for me. The change is a bad idea anyway, since the shutdown is asynchronous (it would be almost equivalent to not attemping to shutdown and kill the process). The way I am using Tomcat isn't typical, the instance that fails to terminate on shutdown is being used as a stand alone soap server which uses https. The only web application is the soap server. It doesn't work in this case. This configuration had worked fine with Tomcat 4.0.1. This is the first time I tried running the soap server with 4.1-dev, I wanted to test the DbcpDataSourceFactory. I didn't realize that the container stop was asynchronous, so you are right, using System.exit() like this is not a good solution. If you look at the code you will notice that the comment says FIX ME ???. :-) I put the System.exit() in as a temp fix. I don't think it's a good idea to put something in that you know is broken. We might forget about it (esp since there's some vacation to help). The only cause I can come up with which would prevent the java process from terminating is if there are still threads running which weren't terminated by the stop. Hence the speculation that the problem has something to do with the STM changes. If there's no STM servlets, it shouldn't do that. Also, if you look at the code, I don't see why it would cause some problems. Is it Apache SOAP ? I'll try to look at it if it is. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Beta5]HttpRequestBase POST buglet
[I sent this to the users list on Friday - someone sent me email
telling me I should send it to this group - sorry for the double
post]
I just started using TomCat B5 using the builtin HTTPConnector.
When POST-ing a form, none of the name-value pairs of the
Query string make it through.
I found the below minor logic bug, and it now is working for me.
--- HttpRequestBase.java.orig Fri May 18 16:36:30 2001
+++ HttpRequestBase.javaFri May 18 16:39:40 2001
@@ -616,7 +616,7 @@
if (semicolon = 0)
contentType = contentType.substring(0, semicolon).trim();
if (POST.equals(getMethod()) (getContentLength() 0)
- (this.stream == null)
+ (this.stream != null)
application/x-www-form-urlencoded.equals(contentType)) {
try {
int max = getContentLength();
Reading the URL parameters is done just above :
// Parse any parameters specified in the query string
String queryString = getQueryString();
try {
RequestUtil.parseParameters(results, queryString, encoding);
} catch (Throwable t) {
}
This is for reading parameters in the body of the post. The test means that
if the servlet accessed the stream, we should not attempt to parse the
parameters.
The test is a bit too strict (we could check if bytes have been read from
the stream instead), but that's it.
You should check if you don't call getInputStream in your servlet before
calling getParameters.
Remy
Re: [Tomcat 4] PROPOSAL: Revision to Build Procedures
Quoting Craig R. McClanahan [EMAIL PROTECTED]: I'd like to propose a modification to the way that the build scripts for Tomcat 4 work, based on experience gained in the Jakarta Commons project, Struts, and a couple of non-Jakarta projects that use the same approach. +1 Remy
Re: Packaged tag libraries
I have been having some problems with packaged tag libraries and have seen other mentions of this problem on the tomcat-user list. Basically the problem is that when a taglib is packaged as specified in the JSP 1.2 spec the following error is returned when trying to use a tag in that library: org.apache.jasper.JasperException: File /util not found where /util is the uri specified in the .tld file. Anyway the full details are in an email posted to the user list. So the root of the problem appears to be that the TldLocationsCache does not correctly process .jar files found in the WEB-INF/lib directory. When inside the processJars() method the call to ctxt.getResource(/WEB-INF/lib); returns a URL of - jndi:/orangefood/of/WEB-INF/lib The code only process the returned URL if the protocol is file. So I am not sure if the TldLocationsCache should be more robust and handle a protocol of jndi or if the servlet should return a file URL. In any case this is causing some problems for a few people. I'd be happy to do any additional investigation if necessary. Yes indeed. It appears that piece of code should be rewritten using the new getResourcePaths call to replace the direct filesystem access. Remy
Re: Packaged tag libraries
Maybe I'm running a version that is too old (daily build from 5/12/2001) but I cant find the method you sugest. What object is getResourcePaths on? ServletContext. Remy
Re: cvs commit:jakarta-tomcat/src/share/org/apache/tomcat/util/buf DateTool.java
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: It has all to do with standards. Tabs have been used for indentation for at least the last 15 years ( that's when I started playing with computers- and the tab was there ). But the point is that we're using SPACES... Since _EVER_... Discussion closed. I really doubt you guys have been using spaces everywhere since JServ. Look at Craig's source for JServ 2 (err, I mean, Catalina) : there are tabs everywhere ;) Frankly, I don't think we should make a big deal of the whole issue. Remy
RE: Filter Chains slow first time it is called
Quoting Craig R. McClanahan [EMAIL PROTECTED]: On Wed, 30 May 2001, Craig R. McClanahan wrote: Hello Paul, This definitely sounds like something wrong with Tomcat 4 -- most likely a combination of things related to the browser (which can affect which HTTP version is in use), your filters, and the ultimate servlet or JSP page being called. To help narrow things down a bit: * Do you have a small test case we can use to investigate this? If so, you can send it either to TOMCAT-DEV or to me in private mail. * Are your clients using HTTP/1.0 or HTTP/1.1? * Does your filter create a wrapper on the servlet response, or is it just passing things through? I suspect that somewhere along the line the output stream isn't getting flushed or closed in a timely manner -- the above information will be helpful to be able to identify where. Craig I just added some more unit tests that do output filtering, and they all work immediately. I now more strongly suspect that this problem is related to some combination of using HTTP/1.1, the particular filters and wrappers being executed, and Tomcat not flushing something somewhere when it is supposed to -- but a real-life example would be tremendously helpful in tracking it down further. I suspect it's a special case problem. I quickly tried with the FilterExample in the examples webapp (which does not actually wrap anything), and it works ok. Remy
Re: [PATCH] RE: Packaged tag libraries
Ok well here is a patch to TldLocationsCache that should all Jasper to correctly process packaged tab libraries. I tested on my system and it works well. I changed processJars() to use the getResourcePaths method as Remy suggested. I pulled tldConfigJar() as it did a bunch of stuff with URL's that appeared to be overly complex. I put the logic from that method right in the processJars() and accessed the jar files directly (i.e. w/out a url or connection). I changed parseTldForUri() because it was looking for a child taglib and then a uri it should have just looked for a uri right off. Lastly I'm not sure why the diff produced some 'goofy' stuff. If somebody lets me know how to fix it I won't do it in the future. Really lastly - this is my first attempt at sending in a patch to an open source project so if somehow I've f'ed up the etiquette, then please be gentle. Nice work, but you shouldn't use getRealPath() and access as a file, as getRealPath() can return null. Although it is indeed more complex, tldConfigJar() is the way to go, as it should work in all cases. Remy
Re: [T4] Classloader funk
I'm using T4b5. So, what I did was re-compile some Scarab classes. Those classes are located in scarab/WEB-INF/classes. I have class reloading turned on and when Catalina reloaded the classes, this got output to System.out.println() in my terminal window... What it *looks* like is that when the Session object attempts to be re-serialized, that whatever is in scarab/WEB-INF/lib (ie: turbine.jar) doesn't get added to the classpath before the re-serialization happens. CL was indeed broken when stopping the manager. I have committed something which should fix it. [Note : My build environment is totally messed up, so I wasn't able to test with Watchdog or the tester] Remy
Re: [T4] Classloader funk
On Wed, 30 May 2001, Remy Maucherat wrote: CL was indeed broken when stopping the manager. I have committed something which should fix it. [Note : My build environment is totally messed up, so I wasn't able to test with Watchdog or the tester] Downloading as I type. I'll let you know if I see anything. Jon, could you give me one of your patented cookbooks for recreating this just in case? My current unit tests do deserialization on reload, and the classes are loaded from a JAR file in WEB-INF/lib, so there must also be something else different about what Scarab is doing. Really ? Perhaps my fix wouldn't fix anything then ... The trace Jon posted was really clear about where the problem was, though : ... org.apache.catalina.session.StandardSession.writeObjectData(StandardS ession.java:707) at org.apache.catalina.session.StandardManager.unload(StandardManager.ja va:502) at org.apache.catalina.session.StandardManager.stop(StandardManager.java :648) at org.apache.catalina.core.StandardContext.reload(StandardContext.java: 2316) ... The catalina internal thread was indeed unbound before calling reload (so that's why the manager failed to load the class when trying to serialize). Remy
Re: [T4] Classloader funk
on 5/30/01 9:16 PM, Remy Maucherat [EMAIL PROTECTED] wrote: I have committed something which should fix it. Note: In the future, giving credit for the find in the CVS commit message is appreciated. :-) Sorry. The latest nightly (05/31) should have the fix. Does it work now ? Remy
Re: tomcat-4.0 and JSP class reloading
Quoting Craig R. McClanahan [EMAIL PROTECTED]: See below. On Thu, 31 May 2001, Remy Maucherat wrote: I'm not sure this proposed change would really make any difference. The parent classloader here is the web app classloader already, which is the same thing that the context class loader is set to. NOTE: If we do something like this, we need to make sure that getResource() and getResourceAsStream() work in JasperLoader as well. I'll do some more investigation today. Apparently, the problem was that the parent reference wasn't reset after reloading. So using a dynamic call would solve this. Remy
Re: [T4] Nightly snapshots aren't working...
Quoting Jon Stevens [EMAIL PROTECTED]: I need my fix man! http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/ I think that's because of a few files which won't build with 1.2 (but will with 1.3), which is a problem with Craig's build env (he's using 1.2.2). Wait until he gets back from J1 ;) Remy
Re: [T4] Three things
Quoting Jon Stevens [EMAIL PROTECTED]: #1. I have been able to compile Tomcat 4 for the FIRST time in about 6 months without a lot of painful work. Woo hoo! Champagne ! The new build.properties based build is much easier :) #2. The latest cvs version fixes about 99% of the speed issues that once existed. Things are MUCH MUCH MUCH faster than before. I say 99% because there still seems to be a small slowness during startup...it looks something like this (from the turbine.log file)... [Wed Jun 06 18:36:26 PDT 2001] -- INFO -- Finish Initializing service (late): UploadService [Wed Jun 06 18:36:32 PDT 2001] -- INFO -- Start Initializing service (late): MapBrokerService Before the fix, there would be several of these largish delays and they would take between 9-10 seconds each, now I'm only seeing this one largish delay... I don't really know what you're doing there (but I think I'll look at the source code ;)) If you're loading tons of classes or something like that, static resource access (at least the initial access) can be a bit slow right now. If you look at the implementation, it's because of a largely innefficient reuse of the attributes base classes from the JNDI base package. That can be fixed easily, and would get the performance back to about the same as the direct FS access. #3. I still haven't gotten a chance to test all the classloader stuff. I will report back when I have tested it. Ok. Remy (still @J1)
Re: buffers in jakarta-tomcat-connectors
Hi, Unless someone has reasons not to, I will start changing the build process to use the buffers and low-level objects in j-t-c. Over the weekend I'll try to finish the move of all connector code into j-t-c, where it belongs. I would also try to add jasper34 ( as originally discussed ). It does not interfere in any way with jasper33, in the same way as AJP14 does not interfere with AJP13. Please let me know if you have a better idea. +1 Remy
Re: javax.servlet.request.key-size/cipher-suite attributes aren't being set in Tomcat 4.0-b2 and later
I submitted a bug report using the Apache Bug Database regarding this. However, something seems to be wrong with that database because I don't see it in there now. Anyone know what happened to this bug? There are some new attributes in Tomcat 4 which allow you to query for SSL related information such as the cipher suite that is being used and the key size. BTW, it would be nice if this information were in Tomcat 3.x as well. In Tomcat 4-b1, this works fine. In later versions of Tomcat, these attributes don't appear to be being set. The following is the output in Tomcat 4-b1. javax.servlet.request.key-size javax.servlet.request.cipher-suite Key size: 128 Cipher suite: SSL_RSA_WITH_RC4_128_MD5 Here it is in Tomcat 4-b5. The same is true for several other post b1 versions. javax.servlet.request.cipher_suite javax.servlet.request.key_size Key size: null Cipher suite: null Craig closed the bug, adding an explanation : http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1940 Remy
Re: [T4] Strange error
Not really sure what caused this, but I just saw it printed to my window that I'm running T4 in...this is from fairly recent CVS... java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.next(HashMap.java:736) at java.util.AbstractCollection.toArray(AbstractCollection.java:173) at org.apache.catalina.loader.StandardClassLoader.modified(StandardClass Loader.java:550) at org.apache.catalina.loader.StandardLoader.run(StandardLoader.java:129 1) at java.lang.Thread.run(Thread.java:496) P.s. I'm pretty convinced at this point that class reloading is still broken in T4. I will be working on a test case when I have more time and the problem becomes unbearable. :-) There are a couple of puts in findClass that are not synced. Maybe that's the problem here ... I didn't get that particular exception before, though. Remy
Re: [j-t-c] OS poll
Quoting Glenn Nielsen [EMAIL PROTECTED]: Solaris 7 8 both Sparc and x86, and FreeBSD. Win2k / Cygwin / XEmacs. Remy GOMEZ Henri wrote: Hi, A quick poll to get informations about OS used by j-t-c developpers users ... I: Redhat 6.2 / 7.1 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
RE: Problems with aliased hosts (ver 4.0b5) - please help
Quoting Deacon Marcus [EMAIL PROTECTED]: Hi, Please, if you don't have the time to fix it or it's low priority let me know which classes control this behavior so I could try to fix it myself. Oops, sorry. It's the J1 effect : don't put any urgent requests that week. I think you should have filed a bug. The host mapping is done in org.apache.catalina.core.StandardEngine/StandardEngineMapper. It may be a problem at init (maybe the alias list is incorrectly initialized) or runtime. Remy
Re: Problems with aliased hosts (ver 4.0b5) - please help
Hi, I think I got it, could someone please check and add it ? I've just committed the fix. Thanks ! Remy
Always loading default web.xml ?
Hi, I have the impression that we're always loading the default web.xml, even if the webapp already contains one, and add to the mappings which are defined there. I think it's ok when no mapping are defined, or no mapping is defined on the root node, but it's not as soon as a mapping is defined on either / or /* (which would indicate that the user wants to have all requests in the webapp handled by a particular servlet). Here, I'd like to have one servlet handle everything, including *.jsp, while leaving the default web.xml intact (so that Jasper is still active in other contexts) ;-) If the feature isn't present somewhere already (and I missed it), I think we should add it. Remy
Re: Always loading default web.xml ?
On Tue, 12 Jun 2001, Remy Maucherat wrote: Hi, I have the impression that we're always loading the default web.xml, even if the webapp already contains one, and add to the mappings which are defined there. Yep. Tomcat loads the default mappings from this file, then it loads your own mappings (which override anything set in the defaults). I think it's ok when no mapping are defined, or no mapping is defined on the root node, but it's not as soon as a mapping is defined on either / or /* (which would indicate that the user wants to have all requests in the webapp handled by a particular servlet). Here, I'd like to have one servlet handle everything, including *.jsp, while leaving the default web.xml intact (so that Jasper is still active in other contexts) ;-) If you map to /* in your own web.xml, it overrides any *.jsp mappings in the defaults (because of the priority ordering defined in the servlet spec). What is it that you feel you cannot do? Well, it insisted to map / on the default servlet (so that 127.0.0.1:8080 was going to my servlet; 127.0.0.1:8080/ was going to the default servlet; the rest should go to my servlet). I didn't try again wo see if Jasper was active, but it was still set as a servlet mapping in my context (according to the logs), which of course isn't that useful. The code loads the default config before the app config. Perhaps what we could do when we add a new mapping from the app config is remove the redundant mappings. I added a new feature to my custom host as a workaround : it retrieves the array of children, parses the servlet mappings, and removes anything which isn't mapped to /*. I don't need reloading at all on that host, so I think I should be ok. Remy
[T4] Lifecycle problem
Hi, I'm fighting a lifecycle problem at the moment. When stopping and then restarting the examples, I get : 001-06-13 18:52:00 ContextConfig[/examples] Configuration error in default web.xml java.lang.IllegalArgumentException: addChild: Child name 'default' is not unique at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) at org.apache.catalina.core.StandardContext.addChild(StandardContext.java:1195) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.util.xml.AddChild.end(XmlMapper.java:806) [...] at javax.xml.parsers.SAXParser.parse(SAXParser.java:108) at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:275) at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:7 27) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:818) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java: 216) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppor t.java:155) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1131) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3173) at org.apache.catalina.core.StandardHost.start(StandardHost.java:757) at org.apache.catalina.servlets.HTMLManagerServlet.start(HTMLManagerServlet.jav a:375) at org.apache.catalina.servlets.HTMLManagerServlet.doGet(HTMLManagerServlet.jav a:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) [...] The context config kicks in, and starts trying to add child wrappers which are already there. There's also the problem that the web.xml file could have modified, and the context may contain stale info (like security constraints, ...). I think we have to recycle the context object to solve this ... The context's stop() method could be the right place to do it. Or we could also do it in the ContextConfig (which listens to the events). Remy
Re: [T4] Lifecycle problem
On Wed, 13 Jun 2001, Remy Maucherat wrote: Can we accomplish this by erasing all the defined servlets, servlet mappings, MIME mappings, security constraints, and so on? Recycling the Context object would mean we're impacting the surrounding environment (i.e. the Host objects that contain those Contexts) as well. I don't see why we couldn't do that, and it appears to be enough here. I think it would be cleaner to put that code in ContextConfig.stop(). Remy
Re: cvs commit: jakarta-tomcat-connectors/coyote - Imported sources
Yep, yep :) What about the native part ? Since you plan to use http/1.1 as protocol, I feel you may didn't need a strong connector only something like proxy ? Whatever, happy to see you in j-t-c Remy ;) The goals with those new objects are : - Remove any dependencies with the rest of Tomcat 3.x - Remove anything which looked servlet container specific - Remove interceptors (I didn't think they belonged here) - Don't change things too much so that it's easy to port the TC 3 connectors if needed - It should be a lot easier to write a connector for Coyote that it is to write a connector for Tomcat 4 - A Tomcat 4 adapter will be written It doesn't deal with the native part at all, it just is an updated API for the Java side. I'll start to write an HTTP/1.1 connector for it, and see how well it goes. That may cause changes in the API if there are design problems. Remy
[T4] More mapping problems
Hi Craig, (putting on my Catalina user hat) I found a case where I think adding the default configuration mapping is done wrong. For example, you can choose to map a servlet to /*, in which case you would expect it to handle all requests. That's not what happens because the default config will add a mapping of the default servlet on /. The mapper will then send a request on / to the default servlet, and every other URL to the other servlet. In addition to just checking if the mappings are indentical, I think we should check inclusion too (here, / is included in /*). (back to the developer hat) Is it ok if I implement this behavior ? Remy
Re: Initial comments on coyote
Hi Remy, I looked at coyote, and it looks good ( the Request and Response are simplified and have no deps on a higher layer ). Few issues: - Note - the user should be able to store any object as a note, there is no reason to require recycle on it ( if you want you could turn it into Recyclable and check objects in the note[] for this interface ). I guess it's also easy for the client adapter to handle the recycling by itself if it wants to. I think I'll move back to storing objects there. - AdapterListener/AdapterEventCode - that's an excelent idea ( to use the standard Event/Listener model on connectors). But I think you should follow the full pattern ( method signature doesn't match, Event must extend j.u.Event ). I'm also not sure what's your intention for the even direction ( is it intended to notify the layer above about the connector events or to notify the connector about server events - I think both are needed ) That's up in the air. I'd like to see what I need when I try to port (it won't be a port since I'll rewrite parts of it to support additional things, like pluggable content encoding support + more performance) the HTTP connector. I didn't use the standard Java pattern mostly because I didn't like it. - Connector/Adapter interfaces - I'm not sure we need them from now, but if you want to follow the event/listener model it would be nice to use it here to. I really like the idea of using only the simple Event/Listener pattern, I think it would be very easy for developers to understand the code and would allow maximum flexibility and decoupling. Would you mind moving the Request/Response in o.a.t.util.http ? They depend on MimeHeader, etc - and it would make sense to call them HttpRequest or JTCRequest or something like that ( Request is used in 3.3, 4.0 - it would be confusing ). Perhaps. (Hey, there's no code left if I do that ;-)) Remy
Re: [t4] FYI: usual problems building according to README...
Hi tc4 people, I'm putting myself through the regular build TC4 from source hell that I do whenever I want to test the latest version. (this is on WinNT4) It's a lot easier now, actually :) I came across the following issues, you may be aware of them already but I thought I'd report 'em just in case... 1) It no longer builds on JDK1.2. The README indicates 1.2 or later is required. Yes indeed. It will be fixed. 2) it seems to be depending on old versions of the projects it depends on: It looks like you're still using the build scripts. You shouldn't. Instead, you should run Ant directly, and use a build.properties file. It's really a lot easier. 3) seems theres co-ordination problem between the jakarta-servletapi-4 and jakarta-tomcat. When I build I get the following error: BUILD FAILED D:\apps\jakarta\src\40b5\jakarta-tomcat-4.0\build.xml:129: D:\apps\jakarta\src\40b5\jakarta-servletapi-4\docs\api not found. build dist for the servlet API does create javadoc, but they are in the dist\docs\api dir... Apart from that it went well though :-) I'm cookin' with gas now... I think that's caused by 2) Remy
Re: [t4] FYI: usual problems building according to README...
Hi remy, Thanks for the reply. It's a lot easier now, actually :) It wasn't that hard b4, just the README was always a little out of date... 2) it seems to be depending on old versions of the projects it depends on: It looks like you're still using the build scripts. You shouldn't. Instead, you should run Ant directly, and use a build.properties file. It's really a lot easier. Don't give me that much credit :-). I'm just following the instructions... if I ought to be running Ant directly, then the instructions should say that ... :-) We're planning to do that, actually, and we're waiting a bit before removing the outdated scripts. I don't suppose now I've got your attention you'd like to comment on the Jasper calling response.flushBuffer() when included from servlet problem I reported the other day??? :-) Its really bugging me not knowing if it's a bug or I'm missing something... I didn't comment, because I have no idea what to answer. I know very little about Jasper. Remy
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
on 6/18/01 7:12 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - All the JARs in /WEB-INF/lib are extracted and copied to the work directory, even if the resources are filesystem based. Otherwise, it is not possible to actually manipulate the JARs which are in the webapp while they're open, at least under Windows. This operation is relatively fast anyway. So, what is the side effect of this? Will that directory now grow without bounds? Obviously, the side effect is not that huge. Try it first, and complain later if it's really a problem :) I'm not sure I like a hack like this that is clearly winblows specific. Can you do this conditionally depending on platform? It's not a hack, it's just about robustness. Maybe it would be a problem on some other platform, I just don't know. Remy
Re: [t4] yet another classloader muckup...
Quoting Jon Stevens [EMAIL PROTECTED]: I haven't tried a recent snapshot of Catalina (after remy's recent classloader changes)...but, this is something that is being reported on the Turbine mailing list as well as I have seen it on my own... What happens is that when the classloader reloads, for some reason, Village is not found in the WEB-INF/lib directory (even though it is there) and we get a NCDFE... This problem would have been very easy to fix anyway (I got a report on it two days ago, and I already had fixed it for the thread which checks for classes modification), but ... Craig/Remy, think you can help? Will Remy's recent changes fix this problem? Yes, the problem will be fixed. Remy Without doing anything else, approximately 5 to 20 seconds later the following exception appears in the Catalina console window: java.lang.NoClassDefFoundError: com/workingdogs/village/KeyDef at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1631) at org.apache.turbine.om.peer.BasePeer.doUpdate(BasePeer.java:1578) at org.apache.turbine.om.security.peer.TurbineUserPeer.doUpdate(TurbineUserPeer .java:463) at org.apache.turbine.services.security.db.DBUserManager.store(DBUserManager.ja va:272) at org.apache.turbine.services.security.BaseSecurityService.saveUser(BaseSecuri tyService.java:379) at org.apache.turbine.services.security.TurbineSecurity.saveUser(TurbineSecurit y.java:261) at org.apache.turbine.om.security.TurbineUser.valueUnbound(TurbineUser.java:649 ) at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession. java:953) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:551) at org.apache.catalina.session.StandardManager.processExpires(StandardManager.j ava:744) at org.apache.catalina.session.StandardManager.run(StandardManager.java:815) at java.lang.Thread.run(Thread.java:484) This class appears to exist in village-1.5.1.jar so I don't see why the exception is occurring or if it relates to my screen transition problem.
Re: [t4] weird build error...
With Jikes... build-main: [javac] Compiling 280 source files to /Users/jon/checkout/jakarta-tomcat-4.0 /catalina/build/classes [javac] /Users/jon/checkout/jakarta-tomcat-4.0/catalina/src/share/org/apache /catalina/loader/WebappLoader.java:806: class org.apache.catalina.loader.Context Notifier is defined in StandardLoader.java. Because it is used outside of its so urce file, it should be defined in a file called ContextNotifier.java. [javac] ContextNotifier notifier = new ContextNotifier((Context) contain er); [javac] ^ [javac] Note: 13 files use or override a deprecated API. Recompile with -d eprecation for details. [javac] 2 warnings It builds ok with javac, though. I'll try to fix it. Remy
Re: cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
on 6/18/01 7:30 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Obviously, the side effect is not that huge. Try it first, and complain later if it's really a problem :) I'm not sure I like a hack like this that is clearly winblows specific. Can you do this conditionally depending on platform? It's not a hack, it's just about robustness. Maybe it would be a problem on some other platform, I just don't know. Remy Ok, I guess I can't complain because this doesn't seem to extract any WEB-INF/lib jars into the work directory. :-) I'm using the latest cvs of tomcat... ... ... ? And it's still loading the classes ? When it's been proven that it's working as it should under Unix without copying away the JARs, then we can consider not moving away the JARs. At least under Windows, it's definitely needed, though. We could also not copy the JARs when reloading is disabled. Remy
Re: Re:cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
And it's still loading the classes ? Yup, everything is running fine... Weird. I'm serious...nothing is going into my work/localhost/scarab (the only directories in the work directory) directory... Do you have version 1.63 of StandardContext, as well as 1.4 (or 1.3, it's the same minus the traces mentioned below) of WebappLoader, and 1.2 of WebappClassLoader ? I added some e.printStackTrace() in WebappLoader to display if something bad happens when actually copying the files. It may be some platform specific file-related bug. I don't think I have hardcoded anything as work-only-on-windows, though ;-) Remy
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderLocalStrings.properties WebappLoader.java
on 6/20/01 6:39 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - Add additional log info so that I can figure out what's up with Scarab running on Jon's box. It's no longer displayed on the console, but instead put in the log files. - Rename StandardLoader - WebappLoader in the logs. - Add additional message strings. Cvs update... cvs server: Updating catalina/src/share/org/apache/catalina/loader P catalina/src/share/org/apache/catalina/loader/LocalStrings.properties P catalina/src/share/org/apache/catalina/loader/WebappLoader.java Building Tomcat... build-main: [javac] Compiling 1 source file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes [copy] Copying 1 file to /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes Building Scarab (after having updated the catalina.jar file)... prepare-tomcat: [echo] Build Dir: /Users/jon/checkout/scarab/build/../target [copy] Copying 1 file to /Users/jon/checkout/scarab/target This is my server.xml... Server.xml: Context path=/scarab docBase=scarab reloadable=true debug=99 Logger className=org.apache.catalina.logger.FileLogger prefix=scarab_log. suffix=.txt timestamp=true/ Loader checkInterval=1 className=org.apache.catalina.loader.StandardLoader/ Hey ! That's not my *new* logger :) :) That's the old one. The new one is org.apache.catalina.loader.WebappLoader At least if it does wrong or if you don't want to use the new loader until it's 100% ready, you have a nice workaround :) Manager debug=99/ /Context Enclosed is the log files...XmlMapper: stuff is the only thing printed to System.out. Nothing in my work/localhost/scarab directory. Now I have an explanation :) Remy
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java
on 6/20/01 8:42 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - Whenever a Loader element was specified in a Context, a StandardLoader was created, regardless on whether or not a className attribute was specified. This is now fixed, and the className attribute now works correctly. - The class implementing the loader interface must have a constructor accepting as parameter the parent class loader of the loader. - If no class name is specified, it will create a WebappLoader. - Thanks to Jon and his patience for helping me locate and fix that bug :) HA! I'm not *that* psycho! :-) Lol. I thought it was really weird at first, then I added some traces, then I finally figured out something was hardcoded somewhere in the mapper. I will test again later...I'm tired of bug tracking today... :-) No problem ! Remy
Re: cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java
on 6/20/01 9:14 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Lol. I thought it was really weird at first, then I added some traces, then I finally figured out something was hardcoded somewhere in the mapper. Still nothing in the work directory. I really don't understand how this has worked for you at all and isn't working for me. Are you actually testing your code before checking it in? Lol. If you think the bug isn't fixed fast enough, you can either : - send new logs instead of just saying it still doesn't work - it's oss, so you can fix it youself :) - keep on using the old CL, which works ok in most cases Remy
Re: Re:cvscommit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startupCatalina.java
on 6/21/01 5:45 PM, Remy Maucherat [EMAIL PROTECTED] wrote: If you think the bug isn't fixed fast enough, you can either : I never said or even implied such a thing. Speed isn't the issue. - send new logs instead of just saying it still doesn't work The log files are the same as before. You haven't changed the logging aspects. Well, looking at your logs that's true, the logs are unchanged. The important changes were in the startup/Catalina class, which I assume you picked up. I have to fix a few other places where the CL classname was hardcoded to StandardLoader, but that definitely shouldn't have affected you. - it's oss, so you can fix it youself :) I see your point, but I'm just hoping that Sun is not depending on the OSS community to fix their primary RI servlet container. As far as *I* am concerned, that is not true. Sun only needs a good servlet container. There's a lot of improvements over what Sun provides which have to be contributed by the community for Tomcat to be a great product, and the main one IMO is real world testing, as many bugfixes as possible (since it saves a lot of time trying to reproduce the bug, which is also generally very hard to do). I hope you don't think Tomcat 4 is developed like closed source software. If I thought that was the case, I would be out of here already. - keep on using the old CL, which works ok in most cases See my last posting. It is broken as well. According to the logs, you're somehow still using it : From scarab_log : 2001-06-21 18:20:58 StandardLoader[/scarab]: Reloading checks are enabled for this Context I have removed the StandardLoader class from my checked out CVS tree without any problems. I'm leaving it in the TC CVS at the moment, as a backup. If you update and do a grep for StandardLoader in your Catalina source, you'll see that it now only occurs in the messages strings, and in the StandardLoader class source itself. So I don't see any logical reason why you would end up with it being your loader. If you're paranoid, you can do as I did and delete StandardLoader from your tree. Remy
Re: [t4] again...classloader stuff...
Quoting Jon Stevens [EMAIL PROTECTED]: on 6/21/01 7:13 PM, Remy Maucherat [EMAIL PROTECTED] wrote: If you're paranoid, you can do as I did and delete StandardLoader from your tree. Remy Or I can check out your recent fixes... - Forgot to rename StandardClassLoader - WebappClassLoader. :-) The env is set up by the Standard[Webapp]Loader, so the problem was there. The fix above should fix problems with the extensions feature. Ok...with the latest CVS update, now the .jar files are being copied over and basic classreloading is working. Thank you for fixing things. Cool. But when I log into Turbine and then try to cause a classreloader to reload, I'm still getting this crash below and it causes the SESSION.ser file to be left in the work directory which ends up screwing things up if I quit/restart tomcat because it tries to read that file on startup and it is invalid or corrupt or noclassdeffound... Ok, I'll make sure I find an explanation. If I remember well, you had problems in the manager, right ? These should be gone. Is it with the default config of Turbine with some example app ? Remy
Re: [t4 patch] delete the damn file. :-)
Quoting Jon Stevens [EMAIL PROTECTED]:
Untested...
If there is an exception thrown during the processing, the file won't
get
deleted because it isn't in a try/finally statement...
That looks like a good idea (more robust).
I would add the finally block to the second try (the one in the sync(sessions)
block) (apparently, if the first one is failing, it's only because no file
exists).
Remy
cvs diff StandardManager.java
Index: StandardManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/se
ssion/StandardManager.java,v
retrieving revision 1.10
diff -r1.10 StandardManager.java
353a354,355
try {
445,447c447,451
// Delete the persistent storage file
file.delete();
---
} finally {
// Delete the persistent storage file
if (file != null file.exists() )
file.delete();
}
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources FileDirContext.java
Quoting [EMAIL PROTECTED]:
glenn 01/06/22 13:20:54
Modified:catalina/src/share/org/apache/naming/resources
FileDirContext.java
Log:
Fix path for windows file separator
@@ -843,6 +842,8 @@
* @param name Normalized context-relative path (with leading
'/')
*/
protected File file(String name) {
+ if( File.separatorChar == '\\' )
+name = name.replace('/',File.separatorChar);
File file = new File(base, name);
if (file.exists() file.canRead()) {
Is this really needed ?
I think this should be abstracted by the new File call.
Remy
Re: cvs commit: jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/unshared UnsharedSessionBean.java
craigmcc01/06/22 14:57:08 Log: Add some unit tests for bean references from a servlet (Session01 or Session03) to beans in the following locations: * SessionBean is in the same /WEB-INF/lib/tester.jar JAR file as the servlet classes are * UnsharedSessionBean is unpacked under /WEB-INF/classes in the tester web app, but should be loaded by the same webapp class loader that loads the servlet. * SharedSessionBean is in a JAR file under $CATALINA_HOME/lib, so it should be loaded by the parent classloader There definitely appears to be a problem with class loading, and trying this stuff fails under either WebappClassLoader and StandardClassLoader. Right now, I've commented things in the build.xml file out so that all the classes get built into tester.jar, and running the HttpSession target all succeeds. If you uncomment the following sets of lines in build.xml, though: * 75-76 to copy UnsharedSessionBean to /WEB-INF/classes * 95-96 to exclude SharedSessionBean and UnsharedSessionBean from tester.jar * 151-156 to create and deploy SharedSessionBean into the $CATALINA_HOME/lib directory then you will get NoClassDefFound exceptions when trying to execute either Session01 or Session03. Conclusion: class loading fails when a class within a JAR file under /WEB-INF/lib references a class in /WEB-INF/classes, or in a shared JAR file in the parent class loader. I don't think that test case is valid. Both of the following explanations are theories. I could be wrong. Comments by CL gurus are welcome. Case A (Craig's test) : Basically, what happens here is : - The Webapp CL which manages the tester webapp loads Session01 - It then notices it needs to be linked with other classes (SessionBean, SSB, and USB) - It loads USB, no problem - It asks the parent CL to load SSB, because it can't find it - Parent loads SSB, checks linking - It notices it needs to load SB - It can't find SB (since it's in his child CL repository) I don't see how we can have that work. It's a case where classes from the shared loader depend on classes from the webapp loader. Case B (Jon's reloading) : - Class A which depends on class B (which is also loaded by CL 1 - everything would be ok if it was loaded by the parent CL) gets loaded (perhaps along with class B) by CL 1 - Touch class A - Reload - CL 1 gets destroyed, and CL 2 is created, and contains the same repositories as CL 1 - all the classes loaded by CL 1 are still there - Later, reload new class A - New class A needs class B, which CL 2 doesn't know - CL 2 loads another class B - The other objects instance of the old class B are unaffected, which leads to an error at some point To solve this, I would try doing a ctx.stop + ctx.start (instead of ctx.reload) whenever class reloading is needed. I think the current reloading will only be able to reload reliably things like the HelloWorld servlet (ie, classes which are fully independent from other classes from the webapp). Remy
Re: cvs commit:jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/unsharedUnsharedSessionBean.java
on 6/22/01 5:09 PM, Remy Maucherat [EMAIL PROTECTED] wrote: I'm not too sure about that yet ... Jon's case is quite complex, and is definitely not the same thing as your test case. Remy I don't think that my case is that out of the ordinary though. Essentially, classes in a .jar file are attempting to instantiate classes in the WEB-INF/classes directory using Class.forName(). It works fine in normal usage, it just doesn't work when the classloader reloads things. I'm curious how other people are able to use Catalina with these bugs in it. Anyone? Well, if I remember well, reloading was broken. So ... Remy
Re: [jtc - coyote] couple questions about the Request object
1) why is Request final? i was planning on extending it in org.apache.ajp.AjpRequest, but can't do so since it's final. it's no big deal, i can create org.apache.ajp.AjpRequestAdapter instead, just kind of curious. Well, before, the primary use for extending the request and response was implementing the read and write methods. Well, now there are some interfaces which you can implement as separate objects. You can also associate additional parameters to the request or response, so I thought that extending wouldn't be needed. Maybe the output and input will be a buffer too, since now you can associate them to a stream. 2) any reason why there is no way to set/get attributes on Request? I thought it was servlet API specific, so I would implement them in the adapter. as mentioned, the reason i ask is i was planning on taking advantage of Request in org.apache.ajp so that a bunch of work wasn't duplicated. Remy
Re: DirContextURLStreamHandlerFactory
Hey Folks,
this is a follow-up question to a post made by Kavi on 6/25 regarding
running Tomcat on HP's Core Services Framework.
We encountered a problem with a dual URLStreamHandlerFactory - Catalina
installs its own, in order to provide the jndi: URL for e.g. reading
WEB-INF/web.xml - alas Core Services Framework has also installed its own
factory, in order provide similar capabilities. We have tried eliminating
our own, in which case everything works as expected; if we extend the
DirContextURLStreamHandler and place it in a package we understand, we can
actually instantiate the DirContextURLStreamHandler (extension) and
startup
etc. seems to be fine, except that the installation of the context- and
session listeners fail... my guess is that because Catalina fails to
install its factory (because we've already installed our own) it doesn't
complete the initialization of the DirContext stuff.
No, the failure is silently caught and ignored. The CL is then failing
because it is using URLs based on that protocol.
Is there a way to
provide this service for Catalina or is it a requirement that it gets to
install its own factory ?
In the newest builds, it's not a requirement anymore, but some URL
manipultation oprations will fail if it's not properly set. Something like :
new URL(jar: + servletContext.getResource(/foo.jar).toString() + !/)
If the factory you set returns a handler for protocol jndi, it should
work, like the stream handler factory does :
/**
* Creates a new URLStreamHandler instance with the specified protocol.
* Will return null if the protocol is not codejndi/code.
*
* @param protocol the protocol (must be jndi here)
* @return a URLStreamHandler for the jndi protocol, or null if the
* protocol is not JNDI
*/
public URLStreamHandler createURLStreamHandler(String protocol) {
if (protocol.equals(jndi)) {
return new DirContextURLStreamHandler();
} else {
return null;
}
}
We realize that only one factory can be installed
and since - in this scenario - we are the host or services provider it
would be natural for us to provide this; we also realize that Catalina
probably wasn't written with this in mind, but we'd be interested in
finding
out whether or not this is doable.
(We're currently working with Tomcat 4.0 beta 5).
You should upgrade to one of the latest builds, and work from there. The CL
was improved a lot, and should now be much more robust (and it doesn't rely
on URLs anymore).
I added a protocol Hanlder for the custom protocol Catalina is using. You
can now also try to set it using the java.protocol.handler.pkgs system
property, and add the org.apache.naming.resources package to it. I didn't
try using that yet, so I can't gurantee it would work.
Remy
Re: Hot Deploy?
Quoting Vinay Menon [EMAIL PROTECTED]: Hello Folks, Is 'hot deploy' something that is being planned for Tomcat 4.0. I use Tomcat with JBoss and do not use an EAR file to deploy to the combination ... instead deploy a server side jar for JBoss and the compiled classes for Tomcat. If I stick to the current method of deployment will Tomcat 4.0 support automatic loading of modified classes? Currently I get ClassCastExceptions if I recompile classes - cause the classloaders get confused I guess! We fixed a huge number of CL related problems and bugs since b5, so you may want to try again with a recent nightly build. Remy
Re: [PRE-PROPOSAL] jakarta-tomcat-doc sub-project : WAS:[TomcatDocu mentation Redactors To Hire]
We've started writing some new docs in XML (catalina/docs/dev/xdocs). The HTML generation is done with XSL, but the DTD should be the same as the one used by Anakia. I noticed the xdocs directory, but I didn't see anything in there. I sent Craig an email about it a week ago, but haven't heard back from him. Am I doing something wrong? (re: CVS, not emailing Craig =) - rob web cvs weenie slifka It's in docs/dev/xdocs, not docs/xdocs : http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat-4.0/catalina/docs/ dev/xdocs/ Remy
Re: Probably a simple problem with an equally simple solution...
Quoting Kedar Hirve [EMAIL PROTECTED]: I was trying to develop my own valve to plug into Catalina, but running into some problems. I wrote up a little class that implements Valve and has empty code for getInfo() and invoke(). I put it in its own package called valvetest, compiled it just fine, put that folder with the class in it in Catalina's startup classpath, and added a valve element to my server.xml. Catalina could find the class when it started, but would give me an IllegalArgumentException - argument type mismatch for the valve. Finally I decided to stick the classes into catalina.jar, and it worked. The odd thing here is that before I jarred it, Catalina found the class just fine, and even _ran its constructor_. Though I have one solution for this now (jarring it into catalina.jar), I'm not terribly satisfied with that. I wanted to know if there's a more convenient way of adding my custom components without modifying catalina.jar. It doesn't work even if you put the valve class in server/classes (common/classes should work too) ? Remy
Re: My small, simple problem continued... (null container for my valve)
Oh, WOW. It did work, and I didn't even have to modify Catalina's startup classpath. I had tried putting the class under common\lib and server\lib, but I didn't know that common\classes would work. But now I've got another problem... In the lib folders, you can only put jars. Un-jarred classes should be in the classes folders. That's mentioned in the CL docs. The best place to put your valve here is in server/classes/ Again, I have this barebones valve class I wrote, and I've gotten it to load up without exception in Catalina. Now, oddly enough, I find that my valve has a null container, even though its nested in a context in my server.xml: Context className=org.apache.catalina.core.StandardContext path=/ debug=0 docBase=/ reloadable=true Logger className=org.apache.catalina.logger.FileLogger verbosity=1 directory=/logs/kedlog prefix=valvetest timestamp=true / Valve className=org.apache.catalina.valvetest.KedValve / /Context Is there some initialization I need to do, or am I forgetting some tags in my server.xml? Does your valve extend ValveBase or implement Contained ? Remy
Re: InstanceListener syntax?
Hi folks, can someone give me the definitive syntax for the InstanceListener? Also, is it possible to setup an Engine (or Host) level InstanceListener that would get applied to all context's within said Engine or Host? Having to add a InstanceListener to every context just to get the old tomcat 3.2 pre/post Lifecycle event (Init,service,destroy) support is a bit onerous. Glenn, would the default context help here ? Remy
Re: t4 - status check
What is the status of T4? I haven't seen a huge amount of commits from Craig and Remy recently Did you hear about Sun's shutdown last week ? ;-) Just before the shutdown, I rewrote the CL, and then waited to see if people would get back at me with problems. Nobody did, so I assume there's no problem. As far as I (the I here means that this concerns the parts of Catalina I'm working on : almost everything when Catalina is run standalone) am concerned, TC 4.0 is done, and is in bugfix / tweaking mode. At the moment, I'm working on an improved HTTP/1.1 connector, which is in late design / early implementation phase. It's unlikely it will be included in the 4.0 release, because we wouldn't have enough time to test it. and it seems like the whole adaptor stuff will never get finished cause it seems like a big political, testing and configuration mess. Adaptor means web server connector here ? I'm not asking for a timeline, just a status report. Remy
Re: StandardContext.getNamingContextName returns non unique name
StandardContext.getNamingContextName() returns name of the form /host/context no matter which engine the context is part of. This will create a problem for running multiple services serving the same webapp. It should be returning the name of the form /engine/host/context Let me know if this is a bug or am I missing something? Yes, I know. I'm wondering if mutiple engines are supposed to be used to implement virtual-virtual hosts, though :) Remy
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loaderWebappClassLoader.java
on 7/12/01 2:22 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: - Implementation note : class and JAR reloading is not supported in non standard class repositories. Define non standard. Not in the webapp repositories. Remy
Re: Tomcat 4.0 (7/11) nightly build
Prasad Subramanian [Contractor] at [EMAIL PROTECTED] wrote: Hi , I was trying to get the latest nightly build for Tomcat 4.0 from the website and I found that there are two files a tar.Z and a tar.gz with a size of 1 k. I am unable to get the build from these. I would appreciate any help in getting the latest (07/11) nightly build. Means that the build didn't succeed for that day... Either too much latency on Daedalus while downloading the sources, or something screwed up... I think the builds are down because of the servlet API update. Remy
Tomcat 4 installer - testers needed
Hi all, I spent some time this afternoon trying Nullsoft Installer, and to see what it could do, I wrote an installation script for Tomcat 4.0. I'd like to get some feedback and testing on the generated installer. It should run on Win9x and up, although I only tested it on Win2k. (This binary is based on the current CVS tree) http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/jakarta-tomcat-4 .0-20010714.exe Remy
Re: [PATCH] Splash screen for Tomcat 4.0 Windows Installer
hi everyone, hope everyone is fine and fit, I hope this patch gets accepted... its a splash screen for the jakarta-tomcat 4.0 nullsoft based installer. i made this splash screen because when i got a mail from Remy, in the morning, i thought to make something for the project, so i made a nice splash screen for it. Cool. The attachement didn't make it through, though. Remy
Re: Alternative to NSI
Quoting Daniel Ritchey [EMAIL PROTECTED]: Microsoft has its own installation mechanism built in to Win2000 WinXP and offers a download to add it Win9x. Its the same thing that the binary release of Apache for windows is packaged in. Just thought I would throw that out there, I don't know if it has any advantages over NSI. Ok, but how do you build the MSI ? I know InstallShield can generate that, but that costs (lots of) cash ... There are a few advanced features missing in NSI, but more or less gets the job done. It is also very simple to use. I had a tweaked version of the script, but unfortunately my main HD died on me a few moments ago. The tweaks weren't too complex so I should be able to put them back in quickly. What would I do without IMAP (thanks Pier ;-)) and CVS ? (since of course I never back up anything) :-) Remy
RE: Tomcat 4 installer - testers needed
Quoting [EMAIL PROTECTED]: Remy, I tried the Installation both win2K and win98. They did work pretty well. The only problem I noticed is that when JAVA_HOME is not set before installation some how start Tomcat Menu Item items Target is set to something like C:\%JAVA_HOME%\bin\java -cp (that's called : The Explorer tries to be Smart Syndrome ;-)) This only happens if JAVA_HOME is not set before installtion though. Other than that everything looks cool. I don't know how we could get around that ... Or we can assume that java.exe is in the user's path. Jasper will need JAVA_HOME to run, though, to be able to use javac. Remy
Re: Tomcat 4 installer - testers needed
Or we can assume that java.exe is in the user's path. Jasper will need JAVA_HOME to run, though, to be able to use javac. kind of an unrelated question, but ... is there a jar file or something that can be distributed with tomcat that contains the compiler stuff so that only the jre is needed, not the jdk? i think i've heard you cannot distribute tools.jar (where i think the compiler is). Yes, we indeed cannot redistribute tools.jar (g). Remy
RE: Tomcat 4 installer - testers needed
Quoting [EMAIL PROTECTED]: Remy, Probably we shoudln't be appending c:\ to JAVA_HOME if JAVA_HOME is not set(So that it works fine after JAVA_HOME is properly set). If you look at the script, you'll notice that there's no c:\ in the link. It's just the windows explorer which gets smart and figures out I forgot the drive letter. I'll try to figure out a workaround. I think there's a command I can use to retrieve the value of an env variable, and see if it's blank (in which case, I can display a message and quit). Remy (reinstalling his OS on his new HD)
