ill probably be handled
by the management agent in a similar fashion as you currently do, I imagine.
-> richard
-Original Message-
From: "Felix Meschberger" <[EMAIL PROTECTED]>
Subj: Re: OBR Resolver.deploy() and framework start level
Date: Tue 13. Feb
On 2/12/07, Steven E. Harris <[EMAIL PROTECTED]> wrote:
Felix Meschberger <[EMAIL PROTECTED]> writes:
> Actually, the bundle set descriptor is a bundle itself, which has a
> special manifest header naming other bundles (or resources in OBR
> speak) to be managed. The reference is by bundle symb
Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
And, in general, it is not a good idea to make expedient decisions
because then it is hard to back away from them later.
I understand.
The resource gives you the symbolic name and version, which uniquely
identi
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
> And, in general, it is not a good idea to make expedient decisions
> because then it is hard to back away from them later.
I understand.
> The resource gives you the symbolic name and version, which uniquely
> identifies the bundle.
Yes, though un
Felix Meschberger <[EMAIL PROTECTED]> writes:
> Actually, the bundle set descriptor is a bundle itself, which has a
> special manifest header naming other bundles (or resources in OBR
> speak) to be managed. The reference is by bundle symbolic name and a
> version range.
This is interesting. The
Hi,
On 2/10/07, Steven E. Harris <[EMAIL PROTECTED]> wrote:
Felix Meschberger <[EMAIL PROTECTED]> writes:
> In fact we do exactly this at our place: Define bundle sets and have
> a management agent control the lifecycle
What defines a set of bundles? Is it their symbolic names?
Actually, t
Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
In truth, I wasn't much of a fan of the whole "start" flag in the
first place. I think OBR should be a deployment tool only.
That would be fine, but at present there's no connection in the OBR
interface between the
Felix Meschberger <[EMAIL PROTECTED]> writes:
> In fact we do exactly this at our place: Define bundle sets and have
> a management agent control the lifecycle
What defines a set of bundles? Is it their symbolic names?
> and just use OBR to get the bundles in the first place and make sure
> any
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
> In truth, I wasn't much of a fan of the whole "start" flag in the
> first place. I think OBR should be a deployment tool only.
That would be fine, but at present there's no connection in the OBR
interface between the Resources consumed and exposed a
Hi,
On 2/10/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
[] I think OBR should be a deployment tool only. I think it should
be kept as simple as possible, but no simpler to its job. We can create
another tool to manage the run-time life cycles of bundles...
This is exactly, what I was
Niclas Hedhman wrote:
On Friday 09 February 2007 07:28, Steven E. Harris wrote:
o First, I think that Resolver.deploy() should mark an
already-installed bundle to be started if called with a true "start"
parameter.
Doesn't the whole issue get resolved if you call a start() method e
On Friday 09 February 2007 07:28, Steven E. Harris wrote:
> o First, I think that Resolver.deploy() should mark an
> already-installed bundle to be started if called with a true "start"
> parameter.
Doesn't the whole issue get resolved if you call a start() method explicitly
after a deploy??
Steven E. Harris wrote:
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
At worst, I think that it should be possible for you to create your
own shell command (or direct functionality in your management agent)
that does the deploy like the current command then add an additional
step to loop thr
"Richard S. Hall" <[EMAIL PROTECTED]> writes:
> At worst, I think that it should be possible for you to create your
> own shell command (or direct functionality in your management agent)
> that does the deploy like the current command then add an additional
> step to loop through and start all res
Felix Meschberger <[EMAIL PROTECTED]> writes:
> If you stop the bundle, the bundle is stopped (if not started) and
> permanently marked stopped.
That started to dawn on me as I was finishing writing my message: the
absence of being permanently marked as started is the same as being
permanently ma
Felix Meschberger wrote:
Hi Steven,
Let me comment your second question first:
There is a tiny little adjective in the spec: "permanently marked".
So, when
you start a bundle, regardless of it actually startes or not due to start
level restrictions, the bundle is permanently marked started. I
Hi Steven,
Let me comment your second question first:
There is a tiny little adjective in the spec: "permanently marked". So, when
you start a bundle, regardless of it actually startes or not due to start
level restrictions, the bundle is permanently marked started. If you stop
the bundle, the b
I've discovered behavior in Felix and its OBR implementation that
seems wrong to me, and I'd like to figure out whether it's a bug or
working as intended.
First, the scenario: Say that an application wishes to deploy a bundle
using the OBR, and it knows the bundle's symbolic name. It uses a
filter
18 matches
Mail list logo
