Finding the context configuration for a deployed webapp

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Finding the context configuration for a deployed webapp

Matt Wringe
Hi,

I want to programatically undeploy and application in jetty (I am
writing a jetty remote deployment app for cargo). I have figured out how
to remotely deploy a web application (its a bit of a hack relying on the
jetty.home environment variable and the webbapp directory always being
called 'webapps') and remove the war.

The thing I am stuck on right now is that I can't seem to figure out how
to find out if a webapp was started with or without a context xml file
in /contexts. And if it was started with a web.xml file, which file was
it.

If I remove a webapp without removing the context xml file, then I
failures in jetty.

Any thoughts on this?

Thanks,

Matt Wringe


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Finding the context configuration for a deployed webapp

Jan Bartel
Hi Matt,

Why not write your deployer to always deploy with a context.xml
file? You can make a default one if the user doesn't supply one.

I guess the key thing would be able to relate the name of the context.xml
file to the webapp, and the easiest way to do that would be by convention
- something like contextpath with "/" replaced by "_".

cheers
Jan

Matt Wringe wrote:

> Hi,
>
> I want to programatically undeploy and application in jetty (I am
> writing a jetty remote deployment app for cargo). I have figured out how
> to remotely deploy a web application (its a bit of a hack relying on the
> jetty.home environment variable and the webbapp directory always being
> called 'webapps') and remove the war.
>
> The thing I am stuck on right now is that I can't seem to figure out how
> to find out if a webapp was started with or without a context xml file
> in /contexts. And if it was started with a web.xml file, which file was
> it.
>
> If I remove a webapp without removing the context xml file, then I
> failures in jetty.
>
> Any thoughts on this?
>
> Thanks,
>
> Matt Wringe
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>


--
Jan Bartel, Webtide LLC | [hidden email] | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Finding the context configuration for a deployed webapp

Matt Wringe

On Mon, 2008-06-09 at 16:07 +1000, Jan Bartel wrote:
> Hi Matt,
>
> Why not write your deployer to always deploy with a context.xml
> file? You can make a default one if the user doesn't supply one.
>
> I guess the key thing would be able to relate the name of the context.xml
> file to the webapp, and the easiest way to do that would be by convention
> - something like contextpath with "/" replaced by "_".

This still doesn't work, I need to be able to deploy and undeploy any
webapp to the server, regardless of how it was added to the server. I
can do that right now, except if the web app used an xml file
in /contexts it will fail when the server starts up (because the webapp
file has been removed).

I will just add this to the other notes I have about the limitations of
the Cargo deployer with Jetty.

>
> cheers
> Jan
>
> Matt Wringe wrote:
> > Hi,
> >
> > I want to programatically undeploy and application in jetty (I am
> > writing a jetty remote deployment app for cargo). I have figured out how
> > to remotely deploy a web application (its a bit of a hack relying on the
> > jetty.home environment variable and the webbapp directory always being
> > called 'webapps') and remove the war.
> >
> > The thing I am stuck on right now is that I can't seem to figure out how
> > to find out if a webapp was started with or without a context xml file
> > in /contexts. And if it was started with a web.xml file, which file was
> > it.
> >
> > If I remove a webapp without removing the context xml file, then I
> > failures in jetty.
> >
> > Any thoughts on this?
> >
> > Thanks,
> >
> > Matt Wringe
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Finding the context configuration for a deployed webapp

Jan Bartel
Matt,

It seems reasonable to me that a cargo remote deployer would
only be able to undeploy something that it deployed in the first
place. Are you really sure you need to have an omnipotent deployer
that can un/deploy anything on a remote jetty instance?

cheers
Jan

Matt Wringe wrote:

> On Mon, 2008-06-09 at 16:07 +1000, Jan Bartel wrote:
>> Hi Matt,
>>
>> Why not write your deployer to always deploy with a context.xml
>> file? You can make a default one if the user doesn't supply one.
>>
>> I guess the key thing would be able to relate the name of the context.xml
>> file to the webapp, and the easiest way to do that would be by convention
>> - something like contextpath with "/" replaced by "_".
>
> This still doesn't work, I need to be able to deploy and undeploy any
> webapp to the server, regardless of how it was added to the server. I
> can do that right now, except if the web app used an xml file
> in /contexts it will fail when the server starts up (because the webapp
> file has been removed).
>
> I will just add this to the other notes I have about the limitations of
> the Cargo deployer with Jetty.
>
>> cheers
>> Jan
>>
>> Matt Wringe wrote:
>>> Hi,
>>>
>>> I want to programatically undeploy and application in jetty (I am
>>> writing a jetty remote deployment app for cargo). I have figured out how
>>> to remotely deploy a web application (its a bit of a hack relying on the
>>> jetty.home environment variable and the webbapp directory always being
>>> called 'webapps') and remove the war.
>>>
>>> The thing I am stuck on right now is that I can't seem to figure out how
>>> to find out if a webapp was started with or without a context xml file
>>> in /contexts. And if it was started with a web.xml file, which file was
>>> it.
>>>
>>> If I remove a webapp without removing the context xml file, then I
>>> failures in jetty.
>>>
>>> Any thoughts on this?
>>>
>>> Thanks,
>>>
>>> Matt Wringe
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>


--
Jan Bartel, Webtide LLC | [hidden email] | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Finding the context configuration for a deployed webapp

Matt Wringe

On Tue, 2008-06-10 at 09:16 +1000, Jan Bartel wrote:
> Matt,
>
> It seems reasonable to me that a cargo remote deployer would
> only be able to undeploy something that it deployed in the first
> place. Are you really sure you need to have an omnipotent deployer
> that can un/deploy anything on a remote jetty instance?
its not something that is absolutely needed, I believe what I have now
is sufficient. I was only trying to get it on par with the other
containers that are supported in Cargo.

Thanks for all your help :)

>
> cheers
> Jan
>
> Matt Wringe wrote:
> > On Mon, 2008-06-09 at 16:07 +1000, Jan Bartel wrote:
> >> Hi Matt,
> >>
> >> Why not write your deployer to always deploy with a context.xml
> >> file? You can make a default one if the user doesn't supply one.
> >>
> >> I guess the key thing would be able to relate the name of the context.xml
> >> file to the webapp, and the easiest way to do that would be by convention
> >> - something like contextpath with "/" replaced by "_".
> >
> > This still doesn't work, I need to be able to deploy and undeploy any
> > webapp to the server, regardless of how it was added to the server. I
> > can do that right now, except if the web app used an xml file
> > in /contexts it will fail when the server starts up (because the webapp
> > file has been removed).
> >
> > I will just add this to the other notes I have about the limitations of
> > the Cargo deployer with Jetty.
> >
> >> cheers
> >> Jan
> >>
> >> Matt Wringe wrote:
> >>> Hi,
> >>>
> >>> I want to programatically undeploy and application in jetty (I am
> >>> writing a jetty remote deployment app for cargo). I have figured out how
> >>> to remotely deploy a web application (its a bit of a hack relying on the
> >>> jetty.home environment variable and the webbapp directory always being
> >>> called 'webapps') and remove the war.
> >>>
> >>> The thing I am stuck on right now is that I can't seem to figure out how
> >>> to find out if a webapp was started with or without a context xml file
> >>> in /contexts. And if it was started with a web.xml file, which file was
> >>> it.
> >>>
> >>> If I remove a webapp without removing the context xml file, then I
> >>> failures in jetty.
> >>>
> >>> Any thoughts on this?
> >>>
> >>> Thanks,
> >>>
> >>> Matt Wringe
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe from this list, please visit:
> >>>
> >>>     http://xircles.codehaus.org/manage_email
> >>>
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email