On 12/15/10 9:12, Bjorn Roche wrote:
On Dec 15, 2010, at 8:53 AM, Justin Edelson wrote:
On Dec 15, 2010, at 8:17 AM, Bjorn Roche <[email protected]> wrote:
On Dec 14, 2010, at 9:45 PM, Richard S. Hall wrote:
On 12/14/10 9:42 PM, Richard S. Hall wrote:
You should read the OSGi R4.2 specification of the OSGi JavaDoc
Sorry, that should say, "...the OSGi R4.2 specification OR the OSGi
JavaDoc..."
Thanks for your reply. Correct me if I'm wrong, but I don't think
the OSGi reference will have JavaDocs for the Felix Object, which is
what I was looking for.
I think the point is that you shouldn't need to use the Felix object.
OSGi 4.2 standardized framework launching, so you should use the
standard facility.
Thank you Justin, that certainly makes sense as far as I am concerned.
Still, I find it odd that a large codebase like this doesn't have
JavaDocs. Most of it is available as OSGi, okay, but not all. Maybe I
am wrong, but I think it would alleviate some confusion if the
JavaDocs were there. (for example, I might have known I was barking up
the wrong tree).
http://www.osgi.org/javadoc/r4v42/
if you are interested in learning about OSGi or various other
tutorials, etc. available on the web. If you haven't already done
so, you should also read:
http://felix.apache.org/site/apache-felix-framework-launching-and-embedding.html
As the above page explains, Felix implements the OSGi standard
Framework interface, which is why you'll want to read the OSGi
JavaDoc. I guess we could generate the OSGi JavaDoc and make it
available on our site somewhere, but I'm pretty sure someone else
has put it online already.
This was the first thing I read, but it didn't seem to deal with the
Felix/Non-Felix (or OSGi/non-OSGi) case, so I started looking at the
presentations which were more helpful. I'll look this over again.
I'm not clear on what you're trying to accomplish, but in general, it
isn't possible to expose classes from inside the framework to classes
running outside of the framework, at least not without custom
classloaders and/or a service registry. And at that point, you're
better off going all-OSGi.
That is a major bummer, but I suppose I got my hopes up from a few
slides in a presentation which, of course, I couldn't understand fully
without actually hearing the presentation. Thank you for the
clarification.
The web page I referenced on launching and embedding is pretty clear here:
"The main complication for providing a host application service to
bundles is the fact that both the host application and the bundles must
be using the same class definitions for the service interface classes.
Since the host application cannot import classes from a bundle, this
means that the service interface classes *must* be accessible on the
class path, typically as part of the host application itself."
And likewise:
"The main complication for the host application using a service from a
bundle is the fact that both the host application and the bundle must be
using the same class definitions for the service interface classes.
Since the host application cannot import classes from a bundle, this
means that the service interface classes *must* be accessible on the
class path, typically as part of the host application itself."
That page also references something called Transloader that can
supposedly help, but I don't know anything about it.
-> richard
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
