Tomcat 5.5.x (jasper-compiler-jdt.jar) Licensing
Hello, I have a question about the use of jasper-compiler-jdt.jar in Apache Tomcat 5.5.x. Is this component in use with Apache Tomcat 5.5.x considered to be licensed under the Apache License, Version 2.0 or the Eclipse Public License v 1.0? (If this is out of context for this list please ignore.) Also, if the jasper-compiler-jdt.jar is licensed under the Eclipse Public License v 1.0, I am looking for a legal definition of commercial decision. In particular I am trying to find what constitutes a commercial distribution under the Eclipse Public License v 1.0 (EPL v1 section 4http://www.eclipse.org/legal/epl-v10.html). Thank you, John
Re: Q: how to obtain notification when a WebApp is unloaded/reloaded?
On Sun, Apr 25, 2010 at 12:29 PM, users-digest-h...@tomcat.apache.orgwrote: -- Forwarded message -- From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Date: Fri, 23 Apr 2010 12:29:26 -0400 Subject: Re: Q: how to obtain notification when a WebApp is unloaded/reloaded? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Godmar, On 4/14/2010 10:20 AM, Godmar Back wrote: I have added a ServletContextListener, but it is very much a solution I strongly dislike. The reason is that my application is layered on top of another application (ZK), and I don't really want to touch web.xml. 'web.xml' describes how ZK is configured to run inside Tomcat or another J2EE server. My applications runs on top of ZK, and having to go and made changes to the underlying deployment descriptor violates basic principles of layering. It also creates a maintenance problem (unless an application can have multiple .xml files that are combined to form a deployment descriptor). Whenever ZK is updated, a new version of web.xml will be installed, and I would then have to merge my listener declaration into the new file. What is your deployment procedure? We use ant for our deployments and it's trivial to use the xslt task to mutate XML files such as web.xml. If you do this, you can set up your deployment process once and not worry about it, even if ZK publishes an update. My deployment procedure is extremely simple - I do a CVS checkout into the webapps dir. Immediate deployment (without having to bother creating war files, etc. etc.) To reply to an earlier comment that I should use a separate web.xml - I don't see how this would be possible. listener-classorg.libx.editionbuilder.GCHelper$ShutdownListener/listener-class /listener I think the class needs to be a top level class with a parameter free constructor. I'm not sure if it needs to be top-level, but it will at least need to be static. Can you post the code for GCHelper$ShutdownListener? Just to be clear - there is no problem with GCHelper$ShutdownListener. Its methods are invoked on application shutdown the first time. It is a static class and it doesn't need to be top-level. The problem arises when the web application is recompiled. Recompilation works in two steps. First, I remove all files in the classes directory (/bin/rm -rf WEB-INF/classes), then I run javac to recompile the classes from a script. Once Tomcat sees that the files have been removed, it'll declare the web application dead and stops reloading it. This is very unfortunate. A work-around I'm trying now is as follows: I don't delete the .class files when recompiling. This way, Tomcat will never see them gone. Of course, this will leave stale .class files around when classes are renamed. However, these can be handled by periodically shutting down Tomcat and cleaning the WEB-INF/classes directory. One of my team members uses Eclipse to develop - I assume it will cause the same problems should Eclipse clean the class directory before recompiling, as it can be configured to do. - Godmar
Re: Tomcat 5.5.x (jasper-compiler-jdt.jar) Licensing
On 25/04/2010 17:28, 100box...@gmail.com wrote: Hello, I have a question about the use of jasper-compiler-jdt.jar in Apache Tomcat 5.5.x. Is this component in use with Apache Tomcat 5.5.x considered to be licensed under the Apache License, Version 2.0 or the Eclipse Public License v 1.0? The bulk of the content is EPL 1.0 (there is a very small amount of AL2 content). (If this is out of context for this list please ignore.) Also, if the jasper-compiler-jdt.jar is licensed under the Eclipse Public License v 1.0, I am looking for a legal definition of commercial decision. In particular I am trying to find what constitutes a commercial distribution under the Eclipse Public License v 1.0 (EPL v1 section 4http://www.eclipse.org/legal/epl-v10.html). The ASF can not advise you on how to interpret any license file. For that, you'll need to hire lawyer. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Q: how to obtain notification when a WebApp is unloaded/reloaded?
On 25/04/2010 18:24, Godmar Back wrote: On Sun, Apr 25, 2010 at 12:29 PM, users-digest-h...@tomcat.apache.orgwrote: -- Forwarded message -- From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Date: Fri, 23 Apr 2010 12:29:26 -0400 Subject: Re: Q: how to obtain notification when a WebApp is unloaded/reloaded? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Godmar, On 4/14/2010 10:20 AM, Godmar Back wrote: I have added a ServletContextListener, but it is very much a solution I strongly dislike. The reason is that my application is layered on top of another application (ZK), and I don't really want to touch web.xml. 'web.xml' describes how ZK is configured to run inside Tomcat or another J2EE server. My applications runs on top of ZK, and having to go and made changes to the underlying deployment descriptor violates basic principles of layering. It also creates a maintenance problem (unless an application can have multiple .xml files that are combined to form a deployment descriptor). Whenever ZK is updated, a new version of web.xml will be installed, and I would then have to merge my listener declaration into the new file. What is your deployment procedure? We use ant for our deployments and it's trivial to use the xslt task to mutate XML files such as web.xml. If you do this, you can set up your deployment process once and not worry about it, even if ZK publishes an update. My deployment procedure is extremely simple - I do a CVS checkout into the webapps dir. Immediate deployment (without having to bother creating war files, etc. etc.) To reply to an earlier comment that I should use a separate web.xml - I don't see how this would be possible. listener-classorg.libx.editionbuilder.GCHelper$ShutdownListener/listener-class /listener I think the class needs to be a top level class with a parameter free constructor. I'm not sure if it needs to be top-level, but it will at least need to be static. Can you post the code for GCHelper$ShutdownListener? Just to be clear - there is no problem with GCHelper$ShutdownListener. Its methods are invoked on application shutdown the first time. It is a static class and it doesn't need to be top-level. Interesting. This didn't work for me a while back. The problem arises when the web application is recompiled. Recompilation works in two steps. First, I remove all files in the classes directory (/bin/rm -rf WEB-INF/classes), then I run javac to recompile the classes from a script. Once Tomcat sees that the files have been removed, it'll declare the web application dead and stops reloading it. If you're able to delete recompile within the refresh window, you might stand a chance with this strategy, but it seems a little risky otherwise. This is very unfortunate. A work-around I'm trying now is as follows: I don't delete the .class files when recompiling. This way, Tomcat will never see them gone. Of course, this will leave stale .class files around when classes are renamed. However, these can be handled by periodically shutting down Tomcat and cleaning the WEB-INF/classes directory. If you've got a mechanism for executing a recompile now, why not compile the files to another location and delete/copy them into Tomcat rather than the way you're doing it now. One of my team members uses Eclipse to develop - I assume it will cause the same problems should Eclipse clean the class directory before recompiling, as it can be configured to do. I think you're operating at the limits of what one could expect Tomcat to cope with. p - Godmar signature.asc Description: OpenPGP digital signature
Context accesible in two context paths while it must be accessible in only one
Hi all, I have defined a very simple Web application and stored it under webapps/example. I have also defined a Context file for it named example.xml and placed it under conf/Catalina/localhost. The content of example.xml file is: Context path=/example1 docBase=example debug=1 Logger className=org.apache.catalina.logger.FileLogger prefix=localhost_example_log. suffix=.txt timestamp=true/ /Context Now I assume that this Web app must only be accessible via http://localhost:8080/example1. However it is accessible via both http://localhost:8080/example1 and http://localhost:8080/example. Any ideas why is this happening? The deployment server is *Tomcat 5.0.30*. The whole server directory can be downloaded from: http://public.me.com/behrangsa Thanks in advance, Behrang
Re: Context accesible in two context paths while it must be accessible in only one
On Sun, Apr 25, 2010 at 4:58 PM, Behrang S. Zadeh behran...@gmail.com wrote: I have defined a very simple Web application and stored it under webapps/example. Now I assume that this Web app must only be accessible via http://localhost:8080/example1. A bad assumption; Tomcat will deploy it as /example. Get rid of that 'example.xml' and rename your deployment directory to whatever you want it to be. -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context accesible in two context paths while it must be accessible in only one
So what's the purpose of the path=... element then? On Mon, Apr 26, 2010 at 11:53 AM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Sun, Apr 25, 2010 at 4:58 PM, Behrang S. Zadeh behran...@gmail.com wrote: I have defined a very simple Web application and stored it under webapps/example. Now I assume that this Web app must only be accessible via http://localhost:8080/example1. A bad assumption; Tomcat will deploy it as /example. Get rid of that 'example.xml' and rename your deployment directory to whatever you want it to be. -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context accesible in two context paths while it must be accessible in only one
On Sun, Apr 25, 2010 at 7:02 PM, Behrang S. Zadeh behran...@gmail.com wrote: So what's the purpose of the path=... element then? Only useful if you're deploying outside the given host's appBase. There's lots of discussions of this in the archives :-) -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Context accesible in two context paths while it must be accessible in only one
Thanks! You made my day! :) On Mon, Apr 26, 2010 at 12:06 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Sun, Apr 25, 2010 at 7:02 PM, Behrang S. Zadeh behran...@gmail.com wrote: So what's the purpose of the path=... element then? Only useful if you're deploying outside the given host's appBase. There's lots of discussions of this in the archives :-) -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
