Re: Why unpackWars=true default?

[Glenn Nielsen]

Remy Maucherat wrote:

Glenn Nielsen wrote:


Chris Brown wrote:



My main gripe with the unpackWARs setting is that if WARs are 
unpacked, it
makes it more troublesome to upgrade, because a newer version of the WAR
file is ignored if any previous version has already been unpacked 
(until the
unpacked files are deleted).  If the WAR file is updated, it's 
*probably*
safe to assume that this was done voluntarily, and so any previous 
unpacked
version should be removed then replaced.


I think this has merit, perhaps there should be a /update command for the
web application manager. It would do a stop, remove the unpacked war 
directory,
allow the war file to be updated with a newer version, unpacks the 
war, then does
a start. 


I always thought doing that was too risky to be wise.




I don't see where this is risky, it is the same as doing the /remove then
/install manager commands but without removing the temp work directory
when doing the remove.  Just a short cut so you can do it in one step rather
than two.

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Remy Maucherat]

Glenn Nielsen wrote:

Chris Brown wrote:



My main gripe with the unpackWARs setting is that if WARs are 
unpacked, it
makes it more troublesome to upgrade, because a newer version of the WAR
file is ignored if any previous version has already been unpacked 
(until the
unpacked files are deleted).  If the WAR file is updated, it's *probably*
safe to assume that this was done voluntarily, and so any previous 
unpacked
version should be removed then replaced.


I think this has merit, perhaps there should be a /update command for the
web application manager. It would do a stop, remove the unpacked war 
directory,
allow the war file to be updated with a newer version, unpacks the war, 
then does
a start. 

I always thought doing that was too risky to be wise.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Glenn Nielsen]

Chris Brown wrote:



My main gripe with the unpackWARs setting is that if WARs are unpacked, it
makes it more troublesome to upgrade, because a newer version of the WAR
file is ignored if any previous version has already been unpacked (until the
unpacked files are deleted).  If the WAR file is updated, it's *probably*
safe to assume that this was done voluntarily, and so any previous unpacked
version should be removed then replaced.



I think this has merit, perhaps there should be a /update command for the
web application manager. It would do a stop, remove the unpacked war directory,
allow the war file to be updated with a newer version, unpacks the war, then does
a start. Please file a bugzilla report for an enhancement if you think this would
address the problem you identified.


Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Chris Brown]

To clarify, when I said I "consider" WARs as if they were EXEs, I mean that
in many cases I think it's good practice to have a WAR file that doesn't try
to modify itself internally (bit like having an EXE or whatever that
modifies its contents or self-modifying assembler code...).

Some webapps benefit from customisation, and are good candidates for
unpacking, others are best left as a single unit which store environment
settings externally.

My main gripe with the unpackWARs setting is that if WARs are unpacked, it
makes it more troublesome to upgrade, because a newer version of the WAR
file is ignored if any previous version has already been unpacked (until the
unpacked files are deleted).  If the WAR file is updated, it's *probably*
safe to assume that this was done voluntarily, and so any previous unpacked
version should be removed then replaced.

I don't really care if it's considered a deployment format or an executable
format ; whether it's unpacked on disk, in memory, or whatever is
irrelevant, as long as it works : it's up to the servlet engine to implement
this as it wants (given that JSPs need to be compiled, obviously something
needs to be created outside the WAR).

Having said that, if we're meant to deploy as unpacked files, why bother
with methods such as ServletContext.getResource() (when we could just use
getRealPath if we systematically unpacked these files) ?

- Chris

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 22, 2003 1:31 AM
Subject: Re: Why unpackWars=true default?


> On Tue, Jan 21, 2003 at 09:14:29AM -0500, Shapira, Yoav wrote:
> > >consider the ".war" file like an ".exe" or executable JAR file.
> >
> > And I think this is where my interest comes from.  Your considerations
> > are exactly the opposite of Costin's (I think it was Costin anyways),
> > who considers the .war file a *deployment* format only, like an RPM or a
> > Windows Installer file, not to be run as an executable.
>
> I thought the raison d'etre of war's was acting like a single .exe.
>
> Or at least the default -- just as you're not expected to unpack jars.
>
> Matt



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Why unpackWars=true default?

[mlh]

On Tue, Jan 21, 2003 at 09:14:29AM -0500, Shapira, Yoav wrote:
> >consider the ".war" file like an ".exe" or executable JAR file.
> 
> And I think this is where my interest comes from.  Your considerations
> are exactly the opposite of Costin's (I think it was Costin anyways),
> who considers the .war file a *deployment* format only, like an RPM or a
> Windows Installer file, not to be run as an executable.

I thought the raison d'etre of war's was acting like a single .exe.

Or at least the default -- just as you're not expected to unpack jars.

Matt

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Why unpackWars=true default?

[Shapira, Yoav]

Howdy,

>always apply).  All custom data in our apps is either stored in the
>user.home directory, the preferences API, JNDI, or whatever.  We tend
to
>consider the ".war" file like an ".exe" or executable JAR file.

And I think this is where my interest comes from.  Your considerations
are exactly the opposite of Costin's (I think it was Costin anyways),
who considers the .war file a *deployment* format only, like an RPM or a
Windows Installer file, not to be run as an executable.

I think a lot of users are confused on this point.  That's not tomcat's
fault by any means.  I think tomcat goes above and beyond the spec with
its support for packed/unpacked wars, XML app descriptors, and the whole
automatic app deployment feature.  

Personally, I think of a .war as a deployment format.  I think what the
server does with it (e.g. unpack, copy into a database in Oracle iAS,
etc.) is an implementation detail that users shouldn't know about.

Thanks everyone for answering my original question.  It was very
interesting to read responses from the developers.
  
Yoav Shapira
Millennium ChemInformatics

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Chris Brown]

> Would it be better to remove unpackWARs from tomcat5 since there isn't
> that much of a concern for backwards compatibilty on major releases?
>
> -Tim

It should always be at least an option to deploy WAR files without unpacking
them.

Systematically unpacking WARs would cause problems: the unpacked version is
always used in preference to the packed version by Tomcat, so if
unpackWARs="true", then overwriting the original ".war" file has no effect
(because of the preference for using the directory if it exists), making
upgrade deployment of webapps very problematic, leading to lots of support
calls for us ("I replaced the WAR file, but nothing happens!").

It seems like a bad idea in many cases (obviously not all) to allow
modifications within the webapp itself on production deployments (small
sites and development releases of webapps are examples where this wouldn't
always apply).  All custom data in our apps is either stored in the
user.home directory, the preferences API, JNDI, or whatever.  We tend to
consider the ".war" file like an ".exe" or executable JAR file.

- Chris



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Glenn Nielsen]

Costin Manolache wrote:

Shapira, Yoav wrote:



Hi,



From my review it looks like Tomcat 4 has always defaulted to
unpackWARs=true.  I have no problem with that being the default.
And it would not be good to change at this time since Tomcat 4
has been released for quite a while.


More importantly, it would break webapps which rely on the filesystem,
and would cause 1000 duplicates with blocker severity about


"getRealPath


always returning null" to be filed ;-)


I agree ;)  This is why I said I was NOT suggesting it be changed ;)

Was it a conscious decision to make it true by default back when tomcat
4.0 came out?  Or just kind of happened?



IMO packed WARs are evil and shouldn't be ever used at runtime. They 
increase the code complexity, reduce the ability to integrate with web 
servers, fail if the code uses the file system. 

Even if you can get an InputStream and avoid using the filesystem -
there are a lot of things that won't work - random access to files,
NIO, etc. 

WAR is a _deployment_ format - just like RPM or PKG or install shield
.exe files. Nobody is running programs directly from the RPM or from inside
the uninstalled install shield application.

I would be pretty happy if packed wars will be deprecated or strongly
discouraged in 5.0 - but strongly -1 on changing the default.
 

Costin
 

I agree with Costin, I would be -1 for removing unpackWARs or changing its default.

Glenn




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Why unpackWars=true default?

[Costin Manolache]

Shapira, Yoav wrote:

> Hi,
> 
>>>  From my review it looks like Tomcat 4 has always defaulted to
>>> unpackWARs=true.  I have no problem with that being the default.
>>> And it would not be good to change at this time since Tomcat 4
>>> has been released for quite a while.
>>
>>More importantly, it would break webapps which rely on the filesystem,
>>and would cause 1000 duplicates with blocker severity about
> "getRealPath
>>always returning null" to be filed ;-)
> 
> I agree ;)  This is why I said I was NOT suggesting it be changed ;)
> 
> Was it a conscious decision to make it true by default back when tomcat
> 4.0 came out?  Or just kind of happened?

IMO packed WARs are evil and shouldn't be ever used at runtime. They 
increase the code complexity, reduce the ability to integrate with web 
servers, fail if the code uses the file system. 

Even if you can get an InputStream and avoid using the filesystem -
there are a lot of things that won't work - random access to files,
NIO, etc. 

WAR is a _deployment_ format - just like RPM or PKG or install shield
.exe files. Nobody is running programs directly from the RPM or from inside
the uninstalled install shield application.

I would be pretty happy if packed wars will be deprecated or strongly
discouraged in 5.0 - but strongly -1 on changing the default.
 

Costin
 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Why unpackWars=true default?

[Shapira, Yoav]

Hi,

>>  From my review it looks like Tomcat 4 has always defaulted to
>> unpackWARs=true.  I have no problem with that being the default.
>> And it would not be good to change at this time since Tomcat 4
>> has been released for quite a while.
>
>More importantly, it would break webapps which rely on the filesystem,
>and would cause 1000 duplicates with blocker severity about
"getRealPath
>always returning null" to be filed ;-)

I agree ;)  This is why I said I was NOT suggesting it be changed ;)  

Was it a conscious decision to make it true by default back when tomcat
4.0 came out?  Or just kind of happened?

Thanks,

Yoav Shapira
Millennium ChemInformatics  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Tim Funk]

Not to put words into other peoples mouth, but this was Craig's opinion 
awhile ago (from tomat-user):

http://marc.theaimsgroup.com/?l=tomcat-user&m=104000918909139&w=2

Would it be better to remove unpackWARs from tomcat5 since there isn't 
that much of a concern for backwards compatibilty on major releases?

-Tim


Glenn Nielsen wrote:
 From looking at the docs for both Tomcat 4.0 and Tomcat 4.1 in the
section on automatic application deployment it states for both that
the default for unpackWARs is true.  The section on the unpackWARs
attribute does not mention the default value, perhaps it should.

 From my review it looks like Tomcat 4 has always defaulted to
unpackWARs=true.  I have no problem with that being the default.
And it would not be good to change at this time since Tomcat 4
has been released for quite a while.

Glenn

Shapira, Yoav wrote:


Howdy,
Why is the unpackWars flag set to true by default in tomcat 4.1?

I'm not suggesting the setting be changed, just curious about the
reasoning.

Thanks,

Yoav Shapira
Millennium ChemInformatics



--
To unsubscribe, e-mail:   

For additional commands, e-mail: 

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Remy Maucherat]

Glenn Nielsen wrote:

 From looking at the docs for both Tomcat 4.0 and Tomcat 4.1 in the
section on automatic application deployment it states for both that
the default for unpackWARs is true.  The section on the unpackWARs
attribute does not mention the default value, perhaps it should.

 From my review it looks like Tomcat 4 has always defaulted to
unpackWARs=true.  I have no problem with that being the default.
And it would not be good to change at this time since Tomcat 4
has been released for quite a while.


More importantly, it would break webapps which rely on the filesystem, 
and would cause 1000 duplicates with blocker severity about "getRealPath 
always returning null" to be filed ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Why unpackWars=true default?

[Glenn Nielsen]

From looking at the docs for both Tomcat 4.0 and Tomcat 4.1 in the
section on automatic application deployment it states for both that
the default for unpackWARs is true.  The section on the unpackWARs
attribute does not mention the default value, perhaps it should.

From my review it looks like Tomcat 4 has always defaulted to
unpackWARs=true.  I have no problem with that being the default.
And it would not be good to change at this time since Tomcat 4
has been released for quite a while.

Glenn

Shapira, Yoav wrote:

Howdy,
Why is the unpackWars flag set to true by default in tomcat 4.1?

I'm not suggesting the setting be changed, just curious about the
reasoning.

Thanks,

Yoav Shapira
Millennium ChemInformatics



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 
For additional commands, e-mail: