Running cocoon as a war archive

[Irv Salisbury <ir...@gmail.com>]

I have always run cocoon as an expanded war directory.  Our current
customer is requesting we run as a war file.  Are there any resources
or problems people have found with this strategy?

Thanks,

Irv

Re: Running cocoon as a war archive

[Torsten Curdt <tc...@apache.org>]

> I would say, yes, this would normally belong in
> users@cocoon.apache.org.  However, having been around the cocoon lists
> for over 2 years now and my last 8 or 9 posts not getting answered on
> the users list, I tend to pose the "hard" questions to dev.

<snip/>

...that sounds alright to me - don't worry *too* much ;)

Why don't you try to zip it up and give that a try?

You might get some errors on startup you will
need to resolve. ...but that should be pretty
straight forward.

cheers
--
Torsten

Re: Running cocoon as a war archive

[Irv Salisbury <ir...@gmail.com>]

Thank you for your comments.

I would say, yes, this would normally belong in
users@cocoon.apache.org.  However, having been around the cocoon lists
for over 2 years now and my last 8 or 9 posts not getting answered on
the users list, I tend to pose the "hard" questions to dev.  (Yes I
view this as hard) Sorry if I have offended anyone.  I really wanted
the developers insight into the technical hurdles of doing this.  As
you might have seen from my weblogic posts (which went unanswered on
the users list), the dev list has a different take on things.  I
understand these are busy lists, and that also means there are
developers who do not answer on the users list.  This is a critical
time for this project and cocoon's place in it.  I would really like
it to work.

Once again, sorry.  I will pose the list to the users next time.  I
still welcome any and all thoughts on running cocoon as a war archive
versus as an expanded web directory.

Irv

On 7/5/05, Andrew Franz <af...@optushome.com.au> wrote:
> Irv Salisbury wrote:
> 
> >I have always run cocoon as an expanded war directory.  Our current
> >customer is requesting we run as a war file.  Are there any resources
> >or problems people have found with this strategy?
> >
> >Thanks,
> >
> >Irv
> >
> >
> >
> >
> 
> I had occasion to deal with an individual who insisted on this approach.
> It stems from a desire to 'lock down' production servers to prevent any
> changes. In practice, no software is perfect and there are times when a
> simple one-line change will immediately fix the problem. When you need
> to do this, you don't want to be making a one-line change in a staging
> environment and then re-deploying a 50Mb war file. Also you can't be
> totally certain that no other changes have been made in the staging
> environment. I would argue from a management perspective that deploying
> an expanded servlet is less risky and allows more responsive support. If
> the individual insists on the .war file approach, one possible approach
> is to run a staging servlet (expanded) in parallel with the production
> servlet (war file) - this has the advantage of the identical
> environment, available to test under production conditions & available
> as a backup in an emergency.
> 
> On the technical level, there are issues with anything that needs to be
> written to, such as HSQLDB.
>     See
> http://www.mail-archive.com/cocoon-users@xml.apache.org/msg07183.html
> 
> Doesn't this belong in users@cocoon.apache.org?
>

Re: Running cocoon as a war archive

[Andrew Franz <af...@optushome.com.au>]

Irv Salisbury wrote:

>I have always run cocoon as an expanded war directory.  Our current
>customer is requesting we run as a war file.  Are there any resources
>or problems people have found with this strategy?
>
>Thanks,
>
>Irv
>
>
>  
>

I had occasion to deal with an individual who insisted on this approach. 
It stems from a desire to 'lock down' production servers to prevent any 
changes. In practice, no software is perfect and there are times when a 
simple one-line change will immediately fix the problem. When you need 
to do this, you don't want to be making a one-line change in a staging 
environment and then re-deploying a 50Mb war file. Also you can't be 
totally certain that no other changes have been made in the staging 
environment. I would argue from a management perspective that deploying 
an expanded servlet is less risky and allows more responsive support. If 
the individual insists on the .war file approach, one possible approach 
is to run a staging servlet (expanded) in parallel with the production 
servlet (war file) - this has the advantage of the identical 
environment, available to test under production conditions & available 
as a backup in an emergency.

On the technical level, there are issues with anything that needs to be 
written to, such as HSQLDB.
    See 
http://www.mail-archive.com/cocoon-users@xml.apache.org/msg07183.html

Doesn't this belong in users@cocoon.apache.org?