You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Alex Boisvert <bo...@intalio.com> on 2006/06/20 18:03:24 UTC
Deployment
Hi Lance,
Could you share with us your current thoughts on the deployment API?
Since the mention of the ties with the Integration API, I was thinking
we might want to extend BpelServer with:
void deploy( String pathToUnpackedResources )
throws DeploymentException;
void undeploy( String pathToUnpackedResources )
throws DeploymentException;
which would allow deployment/undeployment of processes after init() or
start() have been called. (File-system layout to be determined...)
I'm wondering if this is similar to what you had in mind...
alex
Re: Deployment
Posted by Assaf Arkin <ar...@intalio.com>.
On 6/20/06, Holger Hoffstätte <ho...@wizards.de> wrote:
>
> Paul Brown wrote:
> >> Alex Boisvert wrote:
> >> > void deploy( String pathToUnpackedResources )
> >> > void undeploy( String pathToUnpackedResources )
> >> Please use Files as arguments instead of Strings. They exist for a
> >> reason. :)
> >
> > In that vein, URL would probably be preferable to File, as it can
> > reach inside of JARs or across the net as well as onto the filesystem.
>
> I read *path* To *UnpackedResources* as local.
+1
And you want to browse that path and get files from it. URLs don't do that
very well unless you decide they are file paths.
> That said, it's not always the case that the set of URL protocols in
> > one location is the same as within the server, and with that in mind,
> > Strings are preferable.
>
> Erm..that is true but how do Strings help then, when the server still has
> to interpret them? Is it a path, an URL, a plane? File removes that
> ambiguity, and the server has a local temporary work directory anway.
+1
We're writing both sides of the API, so whatever is easier
(*cough*file*cough*) to use.
assaf
cheers
> Holger
>
--
CTO, Intalio
http://www.intalio.com
Re: Deployment
Posted by Holger Hoffstätte <ho...@wizards.de>.
Paul Brown wrote:
>> Alex Boisvert wrote:
>> > void deploy( String pathToUnpackedResources )
>> > void undeploy( String pathToUnpackedResources )
>> Please use Files as arguments instead of Strings. They exist for a
>> reason. :)
>
> In that vein, URL would probably be preferable to File, as it can
> reach inside of JARs or across the net as well as onto the filesystem.
I read *path* To *UnpackedResources* as local.
> That said, it's not always the case that the set of URL protocols in
> one location is the same as within the server, and with that in mind,
> Strings are preferable.
Erm..that is true but how do Strings help then, when the server still has
to interpret them? Is it a path, an URL, a plane? File removes that
ambiguity, and the server has a local temporary work directory anway.
cheers
Holger
Re: Deployment
Posted by Paul Brown <pa...@gmail.com>.
> Alex Boisvert wrote:
> > void deploy( String pathToUnpackedResources )
> > void undeploy( String pathToUnpackedResources )
> Please use Files as arguments instead of Strings. They exist for a reason. :)
In that vein, URL would probably be preferable to File, as it can
reach inside of JARs or across the net as well as onto the filesystem.
That said, it's not always the case that the set of URL protocols in
one location is the same as within the server, and with that in mind,
Strings are preferable.
Just $0.02.
--
paulrbrown@gmail.com
http://mult.ifario.us/
Re: Deployment
Posted by Holger Hoffstätte <ho...@wizards.de>.
Alex Boisvert wrote:
> void deploy( String pathToUnpackedResources )
> void undeploy( String pathToUnpackedResources )
Please use Files as arguments instead of Strings. They exist for a reason. :)
Holger
Re: Deployment
Posted by Alex Boisvert <bo...@intalio.com>.
Ok, good to hear from you!
take care,
alex
Lance Waterman wrote:
> Hi Alex,
>
> Sorry - I have been out sick for a couple of days and am catching up.
> I will
> take a look at Paul's feedback today and hopfully get things moving
> forward.
>
> Lance
>
> On 6/20/06, Alex Boisvert <bo...@intalio.com> wrote:
>>
>>
>> Hi Lance,
>>
>> Could you share with us your current thoughts on the deployment API?
>> Since the mention of the ties with the Integration API, I was thinking
>> we might want to extend BpelServer with:
>>
>> void deploy( String pathToUnpackedResources )
>> throws DeploymentException;
>>
>> void undeploy( String pathToUnpackedResources )
>> throws DeploymentException;
>>
>> which would allow deployment/undeployment of processes after init() or
>> start() have been called. (File-system layout to be determined...)
>>
>> I'm wondering if this is similar to what you had in mind...
>>
>> alex
>>
>>
>
--
Intalio :: The Business Process Management Company
Re: Deployment
Posted by Lance Waterman <la...@gmail.com>.
Hi Alex,
Sorry - I have been out sick for a couple of days and am catching up. I will
take a look at Paul's feedback today and hopfully get things moving forward.
Lance
On 6/20/06, Alex Boisvert <bo...@intalio.com> wrote:
>
>
> Hi Lance,
>
> Could you share with us your current thoughts on the deployment API?
> Since the mention of the ties with the Integration API, I was thinking
> we might want to extend BpelServer with:
>
> void deploy( String pathToUnpackedResources )
> throws DeploymentException;
>
> void undeploy( String pathToUnpackedResources )
> throws DeploymentException;
>
> which would allow deployment/undeployment of processes after init() or
> start() have been called. (File-system layout to be determined...)
>
> I'm wondering if this is similar to what you had in mind...
>
> alex
>
>
Re: Deployment
Posted by Paul Brown <pa...@gmail.com>.
Hi, Alex --
> Could you share with us your current thoughts on the deployment API?
> Since the mention of the ties with the Integration API, I was thinking
> we might want to extend BpelServer with:
I'm slowing Lance down a little bit here, as I have his document for
review right now. (He did a lot of work on it...) I'll have my
comments out to Lance by tonight, but don't let me get in the way of
the current conversation.
--
paulrbrown@gmail.com
http://mult.ifario.us/