Yes, singleton would be an issue, since OBR currently does not support it.

-> richard

Roshan A. Punnoose wrote:
Actually I found my issue. What happened is the LocalResource in the
ResolverImpl does find all bundles associated in the current
BundleContext and will update with the latest stream if an update is
required. However, my bundle that I wanted to update had a
symbolicName=temp;singleton=true, and the repository xml did not have
the "singleton" property. So the ResolverImpl did not recognize that I
had a "temp" bundle already installed and only required an update. What
should happen I believe is that the LocalResourceImpl should parse the
symbolicName to "temp" and not "temp;singleton=true".
Roshan

-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Monday, December 03, 2007 4:36 PM
To: dev@felix.apache.org
Subject: Re: [FELIX] OBR tied to the BundleContext

Roshan,

I am not sure I understand the situation you are describing.

Adding a repository XML to repo admin will not be impacted by what bundles are currently installed in the framework. OBR just maintains a list of available bundles. If you try to install a bundle from a repository, OBR's resolve process will look at what is installed locally

to make decisions about what it needs to download.

If a bundle is already installed, it should not download it again, unless it determines that it needs a different version or something.

-> richard

Roshan A. Punnoose wrote:
Hi,

Looking into the OBR code, I think it might be useful to have the OBR
RepositoryAdmin tied to the BundleContext and the bundles that are
already active in OSGi container. Right now, I am running the felix
OBR
bundle in Equinox, but it does not tie to the BundleContext. So when I
try and add an OBR repository xml containing plugins that already
exist
in the container, it throws an exception because these bundles already
exist in the container. However, if the OBR bundle was tied to the
BundleContext, it should see that there are already Resources/Bundles
available to the container and not try and deploy these.

I can see where to do it in the code, and I can submit a patch for it.
Is this a path that seems reasonable to you?

Roshan


Reply via email to