Hi Richard
did you find some time to look into this issue? ;-)
Thanks
Kristian
2009/3/6 Richard S. Hall :
> Thanks. I will try to get to it (and some of your other OBR issues), but I
> am fairly busy the next week or so, so be patient, but feel free to bug me
> nicely. :-)
>
> -> richard
>
> On
Hi,
I tried to launch KF with Crimson and Httpserver bundles in an embedded system
but I get this error:
Removed corrupt bundle dir (Manifest is missing):
/tmp/knopflerfish_osgi_2.2.0/knopflerfish.org/osgi/fwdir/bs/8
Removed corrupt bundle dir (Manifest is missing):
/tmp/knopflerfish_osgi_2.2.
hi Francesco
thank you for your idea but i need to try upnp devices running out of an
OSGI framework .i tried to run the samples given by Domoware in this link
http://domoware.isti.cnr.it/howToUse.html
that i found in the documentation in Felix subproject upnp but i don't know
how to launch them (
2009/3/24 chihi asma
> Hi,
>
> I tried to launch KF with Crimson and Httpserver bundles in an embedded
> system but I get this error:
> Removed corrupt bundle dir (Manifest is missing):
> /tmp/knopflerfish_osgi_2.2.0/knopflerfish.org/osgi/fwdir/bs/8
> Removed corrupt bundle dir (Manifest is miss
well,
then you can test them by installing the Intel Tool Kit
and running the *Networked Light* sample
http://www.intel.com/cd/ids/developer/asmo-na/eng/downloads/upnp/overview/index.htm
If you use Domoware sample you basically use the same approach I
suggested , because they run on OSGi v3 ..
Well, I don't think there is an easy answer to your question. You
could require that all your admin bundles are signed by a known
certificate and then give permissions to that one. Or do the same
based on location.
If that is not an option then you probably will have to create an
admin command tha
Sounds like you have two issues.
It looks like you are exposing your bundles to two copies of
org.apache.log4j. Try removing org.apache.log4j from your class path.
It also looks like you have not properly configured the
org.osgi.framework.system.packages to export javax.naming, which should
OBR should look at the install bundles (and the system bundles) when
resolving dependencies.
However, it is only able to reconstruct standard capabilities from a
bundle (i.e., import-package, export-package, etc.).
-> richard
On 3/23/09 1:01 PM, James Kingsbery wrote:
I'm trying to understan
Thanks for bugging me. No, I haven't looked at it yet. I still plan to,
but the last two weeks were a nightmare taking care of other issues and
preparing for EclipseCon, now I am at EclipseCon. So, probably this week
is not good either, but I will try to look into within a week or so.
Promise.
I'm using Felix embedded in my application, so my OSGi bundles should
not have access to classes on the standard classpath (unless I use boot
delegation or extender bundles) right? The reason I ask is that in the
app, I'm using library Blah version 2.4. I then load an OSGi bundle
that contain
On 3/24/09 1:12 PM, Dan J Hrivnak wrote:
I'm using Felix embedded in my application, so my OSGi bundles should
not have access to classes on the standard classpath (unless I use
boot delegation or extender bundles) right? The reason I ask is that
in the app, I'm using library Blah version 2.4.
Make sure classes are not made available via the ThreadContextClassloader.
regards,
Karl
On Tue, Mar 24, 2009 at 9:12 PM, Dan J Hrivnak
wrote:
> I'm using Felix embedded in my application, so my OSGi bundles should not
> have access to classes on the standard classpath (unless I use boot
> dele
Thanks. The library has a static method that returns the version. I'll
look into the rest of my configuration more carefully and see what's
going on, but that's good to know that Felix is doing what I thought it
should.
Richard S. Hall wrote:
On 3/24/09 1:12 PM, Dan J Hrivnak wrote:
I'm us
13 matches
Mail list logo
