Tomcat 5.5.x (jasper-compiler-jdt.jar) Licensing

2010-04-25 Thread 100box...@gmail.com
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?

2010-04-25 Thread Godmar Back
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

2010-04-25 Thread Mark Thomas
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?

2010-04-25 Thread Pid
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

2010-04-25 Thread Behrang S. Zadeh
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

2010-04-25 Thread Hassan Schroeder
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

2010-04-25 Thread Behrang S. Zadeh
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

2010-04-25 Thread Hassan Schroeder
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

2010-04-25 Thread Behrang S. Zadeh
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