Hi Richard,
I agree with you, and I understand why the existing active bundles remain wired
to the uninstalled bundle until refresh. However it sounded like the newly
installed bundle was wiring to the uninstalled bundle. This doesn’t sound
right… the framework shouldn’t create new wires into
On 11/5/15 05:04 , Neil Bartlett wrote:
Hi Richard,
I agree with you, and I understand why the existing active bundles remain wired
to the uninstalled bundle until refresh. However it sounded like the newly
installed bundle was wiring to the uninstalled bundle. This doesn’t sound
right… the
On 05/11/15 18:26, Neil Bartlett wrote:
Thanks Richard, that’s very clear.
It almost makes me think that, if we were designing the OSGi APIs all
over again, management agents should be required to open a batch
operation in order to do any install/update/uninstall. The operations
in the batch
Thanks Richard, that’s very clear.
It almost makes me think that, if we were designing the OSGi APIs all over
again, management agents should be required to open a batch operation in order
to do any install/update/uninstall. The operations in the batch would not take
effect in the framework
On 11/5/15 12:26 , Neil Bartlett wrote:
Thanks Richard, that’s very clear.
It almost makes me think that, if we were designing the OSGi APIs all over
again, management agents should be required to open a batch operation in order
to do any install/update/uninstall. The operations in the
is
expected to behave. See section 4.4.9 of the OSGi core specification 6.
Renato
> Subject: Re: Uninstalled API bundle, yet implementation still resolves and
> starts
> To: users@felix.apache.org
> From: he...@ungoverned.org
> Date: Wed, 4 Nov 2015 08:31:30 -0500
>
>
&
I 'solved' it by restarting the device. I rather don't, as I like
solution where I can upgrade functionality without shutting down.
Basically my structure is as follows:
Bundle A: API
Bundle S: Service (uses and provides some API implementation from A)
Bundle X1..N: Provide functionality for S
Sorry
Hadn't realised it was a running framework!
On Wed, Nov 4, 2015 at 11:11 AM, Neil Bartlett wrote:
>
> > On 4 Nov 2015, at 11:07, Robert Onslow wrote:
> >
> > Delete the directory called felix-cache??
>
> No, in his second email he says that
On 11/4/15 06:52 , i...@cuhka.com wrote:
I 'solved' it by restarting the device. I rather don't, as I like
solution where I can upgrade functionality without shutting down.
You don't need to shut down, you just need to refresh the framework. If
you update A and S, the old version of A is
Maybe I should also not that there are still started bundles that use
the old API, I haven't updated them yet. But I thought that are all
different classloaders, isolating from each other.
Citeren i...@cuhka.com:
Is this assumption incorrect?
> On 4 Nov 2015, at 10:37, i...@cuhka.com wrote:
>
> I have an API bundle and and implementation bundle. I removed both the API
> and implementation, re-installed the implementation and started the
> implementation. To my suprise the framework was willing to start the bundle,
> even though
Delete the directory called felix-cache??
On Wed, Nov 4, 2015 at 10:42 AM, Neil Bartlett wrote:
>
> > On 4 Nov 2015, at 10:37, i...@cuhka.com wrote:
> >
> > I have an API bundle and and implementation bundle. I removed both the
> API and implementation, re-installed the
> On 4 Nov 2015, at 11:07, Robert Onslow wrote:
>
> Delete the directory called felix-cache??
No, in his second email he says that other bundles are still running that use
the old API. So we’re talking about a series of changes made in a running OSGi
Framework, and
13 matches
Mail list logo