Guillaume Nodet wrote:
Using a service may not always work.
For example the RMI JMX connector will access the JNDI
registry and will need the bundle in its classpath and this can
requirement can not be removed afaik (the code is in jmx).
What about extension bundles ? I've seen that in the spec.
Could they help me somehow ?
Do you mean framework and/or boot class path extensions? It could help
you if you want to install the stuff on the the class path...
Perhaps Karl can provide some advice on the what level of support that
we have for this right now...
-> richard
On 5/15/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Guillaume Nodet wrote:
> Hi everybody !
>
> We 're considering building the next version of ServiceMix (
> http://incubator.apache.org/servicemix/)
> on top of OSGI, and Felix sounds like a natural choice.
> I've downloaded the code and build it and discussed a bit with
Carlos at
> JavaOne who told me
> about the new plugins.
> So I've written a few osgi bundles (
>
http://svn.apache.org/repos/asf/incubator/servicemix/branches/osgi/servicemix-osgi/
>
> )
> that are quite redundant with the MOSGi work. However when trying to
> work
> on a bundle for a JNDI implementation
> based on xbean-naming, i have problems where the needed classes (the
jndi
> initial factory class) are not available from
> the client osgi bundle. Is there any way to solve this problem ? I
> don't
> really want to import the needed package
> in all the bundles :-(
I suppose there are ugly ways to solve it. You could put that stuff on
the class path and set boot class path delegation. You could have your
clients dynamically import "*". However, both of these approaches are
not very good.
If your clients just need to use a JNDI service, you could have a JNDI
bundle that published a JNDI service into the service registry and
client bundles could look up the JNDI service in there, rather than
trying to create their own.
Just some thoughts off the top of my head...perhaps other people have
more experience with it.
> Btw, the MOSGi work seems nice, but there are some references to
> things not
> checked in. Is this part still
> maintain ? Can someone check in the needed modules or I can provide a
> patch
> to remove these references.
Stephane Frenot is developing it, feel free to bug him. :-)
-> richard
