felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per-Erik Svensson <pererik.svens...@gmail.com>
Subject Re: GUI to control installing bundles from an OBR
Date Thu, 03 Mar 2011 18:39:19 GMT
Hi Bruce,

I've been trying to do some initial usage testing of the bundle repository
too and what I learned is that the implementation implements apache-defined
interfaces in the package org.apache.felix.bundlerepository. These
interfaces are exported by the bundle repository, so you could use them. I
think though, that it would be better to use the org.osgi.service.obr
interfaces. Those are also implemented by the bundle repository (by wrapper
classes) but they will only be available if you have the "OSGi OBR service
API" bundle installed (downloadable from the felix download page). That is,
the org.osgi.service.obr.RepositoryAdmin service will only be available if
the obr service api is available in the framework. So, with all this said, I
would suggest you try this route instead of using the apache-packages
directly.

The org.osgi.service.obr.Resolver will have a deploy(boolean start) method
instead of the deploy(int flags), so it should be in line with the one that
you have documentation for.

If you still want to use the flags (and be tied to the felix
implementaitons), they are:

NO_OPTIONAL_RESOURCES = 0x0001;
NO_LOCAL_RESOURCES = 0x0002;
NO_SYSTEM_BUNDLE = 0x0004;
DO_NOT_PREFER_LOCAL = 0x0008;
START = 0x0010;

and should be available through the
org.apache.felix.bundlerepository.Resolver interface (which should be
exported by the bundle repository). Exactly what they do, i cannot answer at
this point (have to look closer at the ResolverImpl) but a fair guess is
that sending in the START flag would be the same as sending in true to the
"standard" deploy-method.

Anyhow, this is what I concluded when I tried to use the bundle repository a
few weeks back. Sadly, I didn't have time to look further into the
deploy-method (we don't deploy through this API at all, only use it to list
bundles that would resolve, download them "manually" and place them in a
FileInstall-controlled directory - it's all very incomplete though as we are
in alpha-stage with this functionality).

A question to others: Does anyone know who the owner of the bundle
repository implementation is and what other projects that may depend on its
somewhat awkward details? (Awkward to me that is, I'm sure there are good
reasons for keeping a parallell interface-hierarchy.)

Regards,
Per-Erik Svensson


On Thu, Mar 3, 2011 at 5:02 PM, Bruce Hartman <BHartman@westell.com> wrote:

> I have to work this into our own bundle/application management system.
>  Unfortuneatly, I can't use or link to external controls.
>
> Since our applications may consist of more than one bundle, I need to
> create an xml file that links our applications to the list of bundles in the
> OBR.  Should I even use an OBR at this point?  I could just put the bundle
> information in the same xml file and use that information to install,
> uninstall, update, start and stop applications (manipulating bundles using
> the bundle context seems trivial) - basically build my own OBR.
>
> What direction do you think I should go?  Should I use an OBR or make my
> own?
>
> If I should use the OBR, should I be using the RepositoryAdmin service?
>
> If I should use RepositoryAdmin, what goes in the parameter (the flags) of
> the 1.6.2+ Resolver.deploy(int args) method?
>
> Thanks for your help, and please let me know if I need to clarify.
>
> Bruce
>
> P.S.  Thanks for the advice Richard.  If I can't get this working, I'll
> look at the source code for the Felix Web Console.  However, I suspect that
> they are not linking to an OBR, but using the bundle context to manipulate
> the bundles.  I'm thinking that since I have the OBR working up to the point
> that I'm trying to deploy the bundle (if I could only figure out what flags
> to put in), I may use the bundle context to install the bundle at that point
> - since I can query the url from the resource from the
> RepositoryAdmin.discoverResources() call.
>
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Thursday, March 03, 2011 8:29 AM
> To: users@felix.apache.org
> Subject: Re: GUI to control installing bundles from an OBR
>
> Doesn't Felix Web Console offer a GUI for OBR as well as for managing
> bundles? You could look into using that.
>
> -> richard
>
> On 3/2/11 16:42, Bruce Hartman wrote:
> > Hi, I'm attempting to create a GUI that will display available bundles,
> and whether they are installed, uninstalled, need to be updated, stopped or
> started, etc.
> >
> > I'm creating an OBR with all the bundles we will supply.
> >
> > My question is open ended - pretty much, "how do I do this".  Here is
> what I'm planning to do.  Please feel free to tell me if I'm on the right
> track, or if there's a better mechanism.  Thanks in advance.
> >
> > I am planning to get the RepositoryAdmin service, from the Felix bundle
> repository 1.6.2, to load my OBR, and install bundles from it (when the user
> presses the "install" button).
> >
> > Does this sound like the best way to do this?
> >
> > If it does, I have a couple of questions about the Resolver object (which
> I can get from the RepositoryAdmin object):
> > 1.  Where is the Javadocs for the Felix bundle repository - 1.6.2?
> > 2.  The Resolver object has a deploy method.  The only documentation for
> this that I could find used the deploy(boolean start) method.  However, in
> 1.6.2, the method deploy takes an int.  Digging around, I could see that
> this was for passing in some kind of flags.  Is there some documentation for
> what the flags are and what they mean?  Otherwise, would deploy(0) be equal
> to the old deploy(false)?
> >
> > Thanks so much for responses.
> >
> > Bruce
> >
> >
> ***************************************************************************************
> > This e-mail and its attachments are a private communication sent from
> Westell Technologies, Inc.,
> > a telecommunications company.  Its contents may contain confidential and
> proprietary information that is protected.
> > If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution or use of the
> > information contained in or attached to this message is strictly
> prohibited.  If you have received this e-mail in error,
> > please notify the sender by replying to this message, and then delete it
> from your system.  Thank you.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
> ***************************************************************************************
> This e-mail and its attachments are a private communication sent from
> Westell Technologies, Inc.,
> a telecommunications company.  Its contents may contain confidential and
> proprietary information that is protected.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution or use of the
> information contained in or attached to this message is strictly
> prohibited.  If you have received this e-mail in error,
> please notify the sender by replying to this message, and then delete it
> from your system.  Thank you.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message