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/