You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/05/15 17:29:26 UTC
Using felix on the server side
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 :-(
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.
--
Cheers,
Guillaume Nodet
Re: Using felix on the server side
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <he...@ungoverned.org> 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
>>
>
>
>
Re: Using felix on the server side
Posted by Stuart McCulloch <st...@jayway.net>.
FYI, a similar question came up on the Equinox mailing list:
http://www.nabble.com/OSGi---RMI-t3733259.html
On 16/05/07, Felix Meschberger <Fe...@day.com> wrote:
> Hi Guillaume,
>
> I have a use case where I create a JNDI InitialContext inside a bundle.
> Before calling the InitialContext, though, I had to set the current threads
> context loader to be the bundle's class loader (do not forget to reset the
> context loader afterwards). This allowed JNDI to load classes which are
> available from the bundle.
>
> Now, depending on how you get at the environment (HashMap) to give the
> InitialContext constructor, you will have to provide more in the bundle. For
> example, our use cases just takes a set of properties provided by an
> administrator. This set may include any class name, hence I set the Bundle
> with a "*" DynamicImport to provide InitialContextFactory class configured -
> provided it is available somewhere in the framework.
>
> Regards
> Felix
>
> On 5/15/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > Yeah, but what if the org.jnp.interfaces.NamingContextFactory is not in
> > the
> > classpath ?
> > That's what happen in my case. I guess in your case, the OSGI runs inside
> > JBoss
> > so there's no classpath problem.
> > What I want is to use OSGI as the container and start a JNDI from a
> > bundle.
> >
> > On 5/15/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
> > >
> > > Oops... my earlier response was for R3. For R4, I had to set the
> > > following in config.properties:
> > >
> > > #
> > > # JNDI properties.
> > > #
> > > java.naming.provider.url=localhost:1099
> > > java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
> > > java.naming.factory.url.pkgs=org.jboss.naming
> > >
> > >
> > >
> > > Rick Litton
> > >
> > >
> > > -----Original Message-----
> > > From: Rick Litton [mailto:Rick.Litton@ktd-kyocera.com]
> > > Sent: Tuesday, May 15, 2007 1:06 PM
> > > To: dev@felix.apache.org
> > > Subject: RE: Using felix on the server side
> > >
> > > 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).
> > >
> > > I'm not sure that this is entirely true. I created an RMI service
> > > bundle similar to what Richard suggested and it was not required to be
> > > declared in the classpath. What was just needed was to set the
> > > jndi.properties directory in the classpath so that the properties can
> > > easily be modified. Other than that, it was just like any *normal*
> > > bundle.
> > >
> > > Rick Litton
> > >
> > >
> > > -----Original Message-----
> > > From: Guillaume Nodet [mailto:gnodet@gmail.com]
> > > Sent: Tuesday, May 15, 2007 12:53 PM
> > > To: dev@felix.apache.org
> > > Subject: Re: Using felix on the server side
> > >
> > > 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 ?
> > >
> > > On 5/15/07, Richard S. Hall <he...@ungoverned.org> 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/servi
> > > cemix-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
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Principal Engineer, IONA
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
>
--
Cheers, Stuart
Re: Using felix on the server side
Posted by Felix Meschberger <Fe...@day.com>.
Hi Guillaume,
I have a use case where I create a JNDI InitialContext inside a bundle.
Before calling the InitialContext, though, I had to set the current threads
context loader to be the bundle's class loader (do not forget to reset the
context loader afterwards). This allowed JNDI to load classes which are
available from the bundle.
Now, depending on how you get at the environment (HashMap) to give the
InitialContext constructor, you will have to provide more in the bundle. For
example, our use cases just takes a set of properties provided by an
administrator. This set may include any class name, hence I set the Bundle
with a "*" DynamicImport to provide InitialContextFactory class configured -
provided it is available somewhere in the framework.
Regards
Felix
On 5/15/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> Yeah, but what if the org.jnp.interfaces.NamingContextFactory is not in
> the
> classpath ?
> That's what happen in my case. I guess in your case, the OSGI runs inside
> JBoss
> so there's no classpath problem.
> What I want is to use OSGI as the container and start a JNDI from a
> bundle.
>
> On 5/15/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
> >
> > Oops... my earlier response was for R3. For R4, I had to set the
> > following in config.properties:
> >
> > #
> > # JNDI properties.
> > #
> > java.naming.provider.url=localhost:1099
> > java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
> > java.naming.factory.url.pkgs=org.jboss.naming
> >
> >
> >
> > Rick Litton
> >
> >
> > -----Original Message-----
> > From: Rick Litton [mailto:Rick.Litton@ktd-kyocera.com]
> > Sent: Tuesday, May 15, 2007 1:06 PM
> > To: dev@felix.apache.org
> > Subject: RE: Using felix on the server side
> >
> > 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).
> >
> > I'm not sure that this is entirely true. I created an RMI service
> > bundle similar to what Richard suggested and it was not required to be
> > declared in the classpath. What was just needed was to set the
> > jndi.properties directory in the classpath so that the properties can
> > easily be modified. Other than that, it was just like any *normal*
> > bundle.
> >
> > Rick Litton
> >
> >
> > -----Original Message-----
> > From: Guillaume Nodet [mailto:gnodet@gmail.com]
> > Sent: Tuesday, May 15, 2007 12:53 PM
> > To: dev@felix.apache.org
> > Subject: Re: Using felix on the server side
> >
> > 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 ?
> >
> > On 5/15/07, Richard S. Hall <he...@ungoverned.org> 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/servi
> > cemix-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
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
RE: Using felix on the server side
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Guillaume Nodet wrote:
> I guess in your case, the OSGI runs inside
> JBoss so there's no classpath problem.
> What I want is to use OSGI as the container and start a JNDI from a
bundle.
Actually, in our case we run Felix outside of JBoss and use JBoss as an
external app server. Of course, we would prefer to have both (backend
Felix and FE app server) on a single JVM which is the most ideal
scenario...
Rick Litton
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: Tuesday, May 15, 2007 1:20 PM
To: dev@felix.apache.org
Subject: Re: Using felix on the server side
Yeah, but what if the org.jnp.interfaces.NamingContextFactory is not in
the
classpath ?
That's what happen in my case. I guess in your case, the OSGI runs
inside
JBoss
so there's no classpath problem.
What I want is to use OSGI as the container and start a JNDI from a
bundle.
On 5/15/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
>
> Oops... my earlier response was for R3. For R4, I had to set the
> following in config.properties:
>
> #
> # JNDI properties.
> #
> java.naming.provider.url=localhost:1099
> java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
> java.naming.factory.url.pkgs=org.jboss.naming
>
>
>
> Rick Litton
>
>
> -----Original Message-----
> From: Rick Litton [mailto:Rick.Litton@ktd-kyocera.com]
> Sent: Tuesday, May 15, 2007 1:06 PM
> To: dev@felix.apache.org
> Subject: RE: Using felix on the server side
>
> 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).
>
> I'm not sure that this is entirely true. I created an RMI service
> bundle similar to what Richard suggested and it was not required to be
> declared in the classpath. What was just needed was to set the
> jndi.properties directory in the classpath so that the properties can
> easily be modified. Other than that, it was just like any *normal*
> bundle.
>
> Rick Litton
>
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Tuesday, May 15, 2007 12:53 PM
> To: dev@felix.apache.org
> Subject: Re: Using felix on the server side
>
> 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 ?
>
> On 5/15/07, Richard S. Hall <he...@ungoverned.org> 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/servi
> cemix-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
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Using felix on the server side
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, but what if the org.jnp.interfaces.NamingContextFactory is not in the
classpath ?
That's what happen in my case. I guess in your case, the OSGI runs inside
JBoss
so there's no classpath problem.
What I want is to use OSGI as the container and start a JNDI from a bundle.
On 5/15/07, Rick Litton <Ri...@ktd-kyocera.com> wrote:
>
> Oops... my earlier response was for R3. For R4, I had to set the
> following in config.properties:
>
> #
> # JNDI properties.
> #
> java.naming.provider.url=localhost:1099
> java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
> java.naming.factory.url.pkgs=org.jboss.naming
>
>
>
> Rick Litton
>
>
> -----Original Message-----
> From: Rick Litton [mailto:Rick.Litton@ktd-kyocera.com]
> Sent: Tuesday, May 15, 2007 1:06 PM
> To: dev@felix.apache.org
> Subject: RE: Using felix on the server side
>
> 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).
>
> I'm not sure that this is entirely true. I created an RMI service
> bundle similar to what Richard suggested and it was not required to be
> declared in the classpath. What was just needed was to set the
> jndi.properties directory in the classpath so that the properties can
> easily be modified. Other than that, it was just like any *normal*
> bundle.
>
> Rick Litton
>
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Tuesday, May 15, 2007 12:53 PM
> To: dev@felix.apache.org
> Subject: Re: Using felix on the server side
>
> 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 ?
>
> On 5/15/07, Richard S. Hall <he...@ungoverned.org> 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/servi
> cemix-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
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
RE: Using felix on the server side
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
Oops... my earlier response was for R3. For R4, I had to set the
following in config.properties:
#
# JNDI properties.
#
java.naming.provider.url=localhost:1099
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming
Rick Litton
-----Original Message-----
From: Rick Litton [mailto:Rick.Litton@ktd-kyocera.com]
Sent: Tuesday, May 15, 2007 1:06 PM
To: dev@felix.apache.org
Subject: RE: Using felix on the server side
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).
I'm not sure that this is entirely true. I created an RMI service
bundle similar to what Richard suggested and it was not required to be
declared in the classpath. What was just needed was to set the
jndi.properties directory in the classpath so that the properties can
easily be modified. Other than that, it was just like any *normal*
bundle.
Rick Litton
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: Tuesday, May 15, 2007 12:53 PM
To: dev@felix.apache.org
Subject: Re: Using felix on the server side
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 ?
On 5/15/07, Richard S. Hall <he...@ungoverned.org> 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/servi
cemix-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
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
RE: Using felix on the server side
Posted by Rick Litton <Ri...@ktd-kyocera.com>.
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).
I'm not sure that this is entirely true. I created an RMI service
bundle similar to what Richard suggested and it was not required to be
declared in the classpath. What was just needed was to set the
jndi.properties directory in the classpath so that the properties can
easily be modified. Other than that, it was just like any *normal*
bundle.
Rick Litton
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: Tuesday, May 15, 2007 12:53 PM
To: dev@felix.apache.org
Subject: Re: Using felix on the server side
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 ?
On 5/15/07, Richard S. Hall <he...@ungoverned.org> 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/servi
cemix-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
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Using felix on the server side
Posted by Guillaume Nodet <gn...@gmail.com>.
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 ?
On 5/15/07, Richard S. Hall <he...@ungoverned.org> 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
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Using felix on the server side
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
Re: Using felix on the server side
Posted by Guillaume Nodet <gn...@gmail.com>.
I do understand that not everything can be hosted at Apache.
The only problem is that the example does not work. I think
it would be better to make the default configuration work
and add some comments in the README for additional
stuff. Btw, one of the files listed is not accessible and that was
my main problem I guess.
On 5/17/07, stephane frenot <st...@insa-lyon.fr> wrote:
>
> Hello guillaume,
> those external references are here, because they cannot be hosted by
> apache
> since they contain code that is not in the apache licensing scheme.
>
> I left them on my servers as a temporary solution, since OSGi and MOSGi
> are
> fully dynamic and can make remote download.
>
> In your example you underline log.jar, felix took some time to include a
> standard log service that was historically available in oscar framework.
> This log.jar is a felixisation of oscar log.jar. I think it can be
> substitued with the newer one.
>
> Linux probe MBean bundle uses a specific linux library to interact with
> /proc to get low level data from linux environment. The liblinux library
> license was not sufficiently clear from my opinion to be hosted on apache.
>
> These bundles are still referenced in felix propreties as examples and use
> cases.
>
> Feel free to ask question if you have problems with mosgi framework, I am
> still documenting and improving it.
>
> Regards
> /stephane
>
>
>
> 2007/5/16, Guillaume Nodet <gn...@gmail.com>:
> >
> > I was talking about the mosgi.doc/config.properties.core
> > that contains some references to a personal folder.
> > I know this is a demo file, but ...
> >
> > Anyway, here's a diff. As you can see, I have also removed references
> > to javax.transaction which are part of J2EE but not J2SE.
> >
> > Index: config.properties.core
> > ===================================================================
> > --- config.properties.core (revision 538675)
> > +++ config.properties.core (working copy)
> > @@ -15,7 +15,8 @@
> > file:bundle/org.apache.felix.shell-0.9.0-incubator-SNAPSHOT.jar \
> > file:bundle/org.apache.felix.shell.tui-0.9.0-incubator-SNAPSHOT.jar \
> > file:bundle/org.apache.felix.bundlerepository-
> > 0.9.0-incubator-SNAPSHOT.jar\
> > -
> http://ares.insa-lyon.fr/~sfrenot/devel/mosgi/insajmx/trunk/lib/log.jar\
> > + file:../org.osgi.compendium/target/org.osgi.compendium-
> > 0.9.0-incubator-SNAPSHOT.jar \
> > + file:../log/target/org.apache.felix.log-0.9.0-incubator-SNAPSHOT.jar \
> >
> >
> >
> file:../mosgi.jmx.remotelogger/target/org.apache.felix.mosgi.jmx.remotelogger-
> > 0.9.0-incubator-SNAPSHOT.jar \
> > file:../mosgi.jmx.agent/target/org.apache.felix.mosgi.jmx.agent-
> > 0.9.0-incubator-SNAPSHOT.jar \
> > file:../mosgi.jmx.registry/target/org.apache.felix.mosgi.jmx.registry-
> > 0.9.0-incubator-SNAPSHOT.jar \
> > @@ -25,17 +26,14 @@
> >
> >
> >
> file:../mosgi.managedelements.bundlesprobes/target/org.apache.felix.mosgi.managedelements.bundlesprobes-
> > 0.9.0-incubator-SNAPSHOT.jar \
> >
> >
> >
> file:../mosgi.managedelements.memoryprobe/target/org.apache.felix.mosgi.managedelements.memoryprobe-
> > 0.9.0-incubator-SNAPSHOT.jar \
> >
> >
> >
> file:../mosgi.managedelements.obrprobe/target/org.apache.felix.mosgi.managedelements.obrprobe-
> > 0.9.0-incubator-SNAPSHOT.jar \
> > -
> >
> >
> http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.linuxprobes/target/org.apache.felix.mosgi.managedelements.linux
> > probes-0.8.0-SNAPSHOT.jar
> > +
> >
> >
> file:../mosgi.jmx.httpconnector/target/org.apache.felix.mosgi.jmx.httpconnector-
> > 0.9.0-incubator-SNAPSHOT.jar \
> > + file:../javax.servlet/target/javax.servlet-
> 0.9.0-incubator-SNAPSHOT.jar
> >
> > -# if we need the http jmx connector
> > -#
> >
> >
> file:../mosgi.jmx.httpconnector/target/org.apache.felix.mosgi.jmx.httpconnector-
> > 0.8.0-SNAPSHOT.jar
> >
> > -
> >
> >
> >
> mosgi.jmxconsole.tab.url.osgiprobestab=file:../mosgi.managedelements.osgiprobes.tab/target/org.apache.felix.mosgi.managedelements.osgiprobes.tab-0.9.0-incubato
> > r-SNAPSHOT.jar
> >
> >
> >
> mosgi.jmxconsole.tab.url.bundlesprobestab=file:../mosgi.managedelements.bundlesprobes.tab/target/org.apache.felix.mosgi.managedelements.bundlesprobes.tab-0.9.0
> > -incubator-SNAPSHOT.jar
> >
> >
> >
> mosgi.jmxconsole.tab.url.obrprobetab=file:../mosgi.managedelements.obrprobe.tab/target/org.apache.felix.mosgi.managedelements.obrprobe.tab-0.9.0-incubator-SNAP
> > SHOT.jar
> > -
> >
> >
> mosgi.jmxconsole.tab.url.memoryprobetab=http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.memoryprobe.tab/target/o
> > rg.apache.felix.mosgi.managedelements.memoryprobe.tab-0.8.0-SNAPSHOT.jar
> > -
> >
> >
> mosgi.jmxconsole.tab.url.linuxprobestab=http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.linuxprobes.tab/target/o
> > rg.apache.felix.mosgi.managedelements.linuxprobes.tab-0.8.0-SNAPSHOT.jar
> >
> >
> +#mosgi.jmxconsole.tab.url.memoryprobetab=../mosgi.managedelements.memoryprobe.tab/target/org.apache.felix.mosgi.managedelements.memoryprobe.tab-
> > 0.9.0-incubator
> > -SNAPSHOT.jar
> >
> > #mosgi.jmxconsole.rmiport.core=1100
> >
> > @@ -51,7 +49,7 @@
> > #obr.repository.url=
> > http://bundles.osgi.org/obr/browse?_xml=1&cmd=repository
> >
> > #fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
> > /dev/hda3 | awk '{printf "%s", $4}'
> > -fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
> > /dev/hda3 | xargs | cut -d ' ' -f 3
> > +#fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
> > /dev/hda3 | xargs | cut -d ' ' -f 3
> >
> >
> > #
> > @@ -89,7 +87,6 @@
> > javax.swing.text.rtf; \
> > javax.swing.tree; \
> > javax.swing.undo; \
> > - javax.transaction; \
> > org.omg.CORBA; \
> > org.omg.CORBA_2_3; \
> > org.omg.CORBA_2_3.portable; \
> > @@ -149,8 +146,6 @@
> > javax.swing.text.rtf; \
> > javax.swing.tree; \
> > javax.swing.undo; \
> > - javax.transaction; \
> > - javax.transaction.xa; \
> > javax.xml.parsers; \
> > javax.xml.transform; \
> > javax.xml.transform.dom; \
> > @@ -294,8 +289,6 @@
> > javax.swing.text.rtf; \
> > javax.swing.tree; \
> > javax.swing.undo; \
> > - javax.transaction; \
> > - javax.transaction.xa; \
> > javax.xml; \
> > javax.xml.datatype; \
> > javax.xml.namespace; \
> >
> >
> > On 5/16/07, Yvan Royon <yv...@gmail.com> wrote:
> > >
> > > Hi Guillaume,
> > >
> > > On 5/15/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > > >
> > > > 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.
> > >
> > > Mmmh, I believe the svn is up to date.
> > > Could you tell which references are failing?
> > >
> > > MOSGi aims to be simple, so quite a few things are missing by choice
> > > (for instance, only Standard MBeans are supported). But I am quite
> > > sure that others are missing by mistake...
> > >
> > > --
> > > Yvan ROYON
> > > INRIA Ares team, CITI Lab, INSA Lyon
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
>
>
>
> --
> Stephane Frenot |
> ARES INRIA / CITI, INSA-Lyon|mailto:stephane.frenot@insa-lyon.fr
> Bat. Léonard de Vinci |http://ares.insa-lyon.fr/~sfrenot/
> 21 av Jean Capelle | ICQ:643346 (et oui !)
> F-69621 Villeurbanne Cedex |+33 472 436 422/+33 617 671 714
> --------------------------------------------------------------------------
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Using felix on the server side
Posted by stephane frenot <st...@insa-lyon.fr>.
Hello guillaume,
those external references are here, because they cannot be hosted by apache
since they contain code that is not in the apache licensing scheme.
I left them on my servers as a temporary solution, since OSGi and MOSGi are
fully dynamic and can make remote download.
In your example you underline log.jar, felix took some time to include a
standard log service that was historically available in oscar framework.
This log.jar is a felixisation of oscar log.jar. I think it can be
substitued with the newer one.
Linux probe MBean bundle uses a specific linux library to interact with
/proc to get low level data from linux environment. The liblinux library
license was not sufficiently clear from my opinion to be hosted on apache.
These bundles are still referenced in felix propreties as examples and use
cases.
Feel free to ask question if you have problems with mosgi framework, I am
still documenting and improving it.
Regards
/stephane
2007/5/16, Guillaume Nodet <gn...@gmail.com>:
>
> I was talking about the mosgi.doc/config.properties.core
> that contains some references to a personal folder.
> I know this is a demo file, but ...
>
> Anyway, here's a diff. As you can see, I have also removed references
> to javax.transaction which are part of J2EE but not J2SE.
>
> Index: config.properties.core
> ===================================================================
> --- config.properties.core (revision 538675)
> +++ config.properties.core (working copy)
> @@ -15,7 +15,8 @@
> file:bundle/org.apache.felix.shell-0.9.0-incubator-SNAPSHOT.jar \
> file:bundle/org.apache.felix.shell.tui-0.9.0-incubator-SNAPSHOT.jar \
> file:bundle/org.apache.felix.bundlerepository-
> 0.9.0-incubator-SNAPSHOT.jar\
> - http://ares.insa-lyon.fr/~sfrenot/devel/mosgi/insajmx/trunk/lib/log.jar\
> + file:../org.osgi.compendium/target/org.osgi.compendium-
> 0.9.0-incubator-SNAPSHOT.jar \
> + file:../log/target/org.apache.felix.log-0.9.0-incubator-SNAPSHOT.jar \
>
>
> file:../mosgi.jmx.remotelogger/target/org.apache.felix.mosgi.jmx.remotelogger-
> 0.9.0-incubator-SNAPSHOT.jar \
> file:../mosgi.jmx.agent/target/org.apache.felix.mosgi.jmx.agent-
> 0.9.0-incubator-SNAPSHOT.jar \
> file:../mosgi.jmx.registry/target/org.apache.felix.mosgi.jmx.registry-
> 0.9.0-incubator-SNAPSHOT.jar \
> @@ -25,17 +26,14 @@
>
>
> file:../mosgi.managedelements.bundlesprobes/target/org.apache.felix.mosgi.managedelements.bundlesprobes-
> 0.9.0-incubator-SNAPSHOT.jar \
>
>
> file:../mosgi.managedelements.memoryprobe/target/org.apache.felix.mosgi.managedelements.memoryprobe-
> 0.9.0-incubator-SNAPSHOT.jar \
>
>
> file:../mosgi.managedelements.obrprobe/target/org.apache.felix.mosgi.managedelements.obrprobe-
> 0.9.0-incubator-SNAPSHOT.jar \
> -
>
> http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.linuxprobes/target/org.apache.felix.mosgi.managedelements.linux
> probes-0.8.0-SNAPSHOT.jar
> +
>
> file:../mosgi.jmx.httpconnector/target/org.apache.felix.mosgi.jmx.httpconnector-
> 0.9.0-incubator-SNAPSHOT.jar \
> + file:../javax.servlet/target/javax.servlet-0.9.0-incubator-SNAPSHOT.jar
>
> -# if we need the http jmx connector
> -#
>
> file:../mosgi.jmx.httpconnector/target/org.apache.felix.mosgi.jmx.httpconnector-
> 0.8.0-SNAPSHOT.jar
>
> -
>
>
> mosgi.jmxconsole.tab.url.osgiprobestab=file:../mosgi.managedelements.osgiprobes.tab/target/org.apache.felix.mosgi.managedelements.osgiprobes.tab-0.9.0-incubato
> r-SNAPSHOT.jar
>
>
> mosgi.jmxconsole.tab.url.bundlesprobestab=file:../mosgi.managedelements.bundlesprobes.tab/target/org.apache.felix.mosgi.managedelements.bundlesprobes.tab-0.9.0
> -incubator-SNAPSHOT.jar
>
>
> mosgi.jmxconsole.tab.url.obrprobetab=file:../mosgi.managedelements.obrprobe.tab/target/org.apache.felix.mosgi.managedelements.obrprobe.tab-0.9.0-incubator-SNAP
> SHOT.jar
> -
>
> mosgi.jmxconsole.tab.url.memoryprobetab=http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.memoryprobe.tab/target/o
> rg.apache.felix.mosgi.managedelements.memoryprobe.tab-0.8.0-SNAPSHOT.jar
> -
>
> mosgi.jmxconsole.tab.url.linuxprobestab=http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.linuxprobes.tab/target/o
> rg.apache.felix.mosgi.managedelements.linuxprobes.tab-0.8.0-SNAPSHOT.jar
>
> +#mosgi.jmxconsole.tab.url.memoryprobetab=../mosgi.managedelements.memoryprobe.tab/target/org.apache.felix.mosgi.managedelements.memoryprobe.tab-
> 0.9.0-incubator
> -SNAPSHOT.jar
>
> #mosgi.jmxconsole.rmiport.core=1100
>
> @@ -51,7 +49,7 @@
> #obr.repository.url=
> http://bundles.osgi.org/obr/browse?_xml=1&cmd=repository
>
> #fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
> /dev/hda3 | awk '{printf "%s", $4}'
> -fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
> /dev/hda3 | xargs | cut -d ' ' -f 3
> +#fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
> /dev/hda3 | xargs | cut -d ' ' -f 3
>
>
> #
> @@ -89,7 +87,6 @@
> javax.swing.text.rtf; \
> javax.swing.tree; \
> javax.swing.undo; \
> - javax.transaction; \
> org.omg.CORBA; \
> org.omg.CORBA_2_3; \
> org.omg.CORBA_2_3.portable; \
> @@ -149,8 +146,6 @@
> javax.swing.text.rtf; \
> javax.swing.tree; \
> javax.swing.undo; \
> - javax.transaction; \
> - javax.transaction.xa; \
> javax.xml.parsers; \
> javax.xml.transform; \
> javax.xml.transform.dom; \
> @@ -294,8 +289,6 @@
> javax.swing.text.rtf; \
> javax.swing.tree; \
> javax.swing.undo; \
> - javax.transaction; \
> - javax.transaction.xa; \
> javax.xml; \
> javax.xml.datatype; \
> javax.xml.namespace; \
>
>
> On 5/16/07, Yvan Royon <yv...@gmail.com> wrote:
> >
> > Hi Guillaume,
> >
> > On 5/15/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > >
> > > 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.
> >
> > Mmmh, I believe the svn is up to date.
> > Could you tell which references are failing?
> >
> > MOSGi aims to be simple, so quite a few things are missing by choice
> > (for instance, only Standard MBeans are supported). But I am quite
> > sure that others are missing by mistake...
> >
> > --
> > Yvan ROYON
> > INRIA Ares team, CITI Lab, INSA Lyon
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
--
Stephane Frenot |
ARES INRIA / CITI, INSA-Lyon|mailto:stephane.frenot@insa-lyon.fr
Bat. Léonard de Vinci |http://ares.insa-lyon.fr/~sfrenot/
21 av Jean Capelle | ICQ:643346 (et oui !)
F-69621 Villeurbanne Cedex |+33 472 436 422/+33 617 671 714
--------------------------------------------------------------------------
Re: Using felix on the server side
Posted by Guillaume Nodet <gn...@gmail.com>.
I was talking about the mosgi.doc/config.properties.core
that contains some references to a personal folder.
I know this is a demo file, but ...
Anyway, here's a diff. As you can see, I have also removed references
to javax.transaction which are part of J2EE but not J2SE.
Index: config.properties.core
===================================================================
--- config.properties.core (revision 538675)
+++ config.properties.core (working copy)
@@ -15,7 +15,8 @@
file:bundle/org.apache.felix.shell-0.9.0-incubator-SNAPSHOT.jar \
file:bundle/org.apache.felix.shell.tui-0.9.0-incubator-SNAPSHOT.jar \
file:bundle/org.apache.felix.bundlerepository-0.9.0-incubator-SNAPSHOT.jar\
- http://ares.insa-lyon.fr/~sfrenot/devel/mosgi/insajmx/trunk/lib/log.jar \
+ file:../org.osgi.compendium/target/org.osgi.compendium-
0.9.0-incubator-SNAPSHOT.jar \
+ file:../log/target/org.apache.felix.log-0.9.0-incubator-SNAPSHOT.jar \
file:../mosgi.jmx.remotelogger/target/org.apache.felix.mosgi.jmx.remotelogger-
0.9.0-incubator-SNAPSHOT.jar \
file:../mosgi.jmx.agent/target/org.apache.felix.mosgi.jmx.agent-
0.9.0-incubator-SNAPSHOT.jar \
file:../mosgi.jmx.registry/target/org.apache.felix.mosgi.jmx.registry-
0.9.0-incubator-SNAPSHOT.jar \
@@ -25,17 +26,14 @@
file:../mosgi.managedelements.bundlesprobes/target/org.apache.felix.mosgi.managedelements.bundlesprobes-
0.9.0-incubator-SNAPSHOT.jar \
file:../mosgi.managedelements.memoryprobe/target/org.apache.felix.mosgi.managedelements.memoryprobe-
0.9.0-incubator-SNAPSHOT.jar \
file:../mosgi.managedelements.obrprobe/target/org.apache.felix.mosgi.managedelements.obrprobe-
0.9.0-incubator-SNAPSHOT.jar \
-
http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.linuxprobes/target/org.apache.felix.mosgi.managedelements.linux
probes-0.8.0-SNAPSHOT.jar
+
file:../mosgi.jmx.httpconnector/target/org.apache.felix.mosgi.jmx.httpconnector-
0.9.0-incubator-SNAPSHOT.jar \
+ file:../javax.servlet/target/javax.servlet-0.9.0-incubator-SNAPSHOT.jar
-# if we need the http jmx connector
-#
file:../mosgi.jmx.httpconnector/target/org.apache.felix.mosgi.jmx.httpconnector-
0.8.0-SNAPSHOT.jar
-
mosgi.jmxconsole.tab.url.osgiprobestab=file:../mosgi.managedelements.osgiprobes.tab/target/org.apache.felix.mosgi.managedelements.osgiprobes.tab-0.9.0-incubato
r-SNAPSHOT.jar
mosgi.jmxconsole.tab.url.bundlesprobestab=file:../mosgi.managedelements.bundlesprobes.tab/target/org.apache.felix.mosgi.managedelements.bundlesprobes.tab-0.9.0
-incubator-SNAPSHOT.jar
mosgi.jmxconsole.tab.url.obrprobetab=file:../mosgi.managedelements.obrprobe.tab/target/org.apache.felix.mosgi.managedelements.obrprobe.tab-0.9.0-incubator-SNAP
SHOT.jar
-
mosgi.jmxconsole.tab.url.memoryprobetab=http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.memoryprobe.tab/target/o
rg.apache.felix.mosgi.managedelements.memoryprobe.tab-0.8.0-SNAPSHOT.jar
-
mosgi.jmxconsole.tab.url.linuxprobestab=http://perso.citi.insa-lyon.fr/sfrenot/devel/mosgi/managedelements/trunk/mosgi.managedelements.linuxprobes.tab/target/o
rg.apache.felix.mosgi.managedelements.linuxprobes.tab-0.8.0-SNAPSHOT.jar
+#mosgi.jmxconsole.tab.url.memoryprobetab=../mosgi.managedelements.memoryprobe.tab/target/org.apache.felix.mosgi.managedelements.memoryprobe.tab-
0.9.0-incubator
-SNAPSHOT.jar
#mosgi.jmxconsole.rmiport.core=1100
@@ -51,7 +49,7 @@
#obr.repository.url=
http://bundles.osgi.org/obr/browse?_xml=1&cmd=repository
#fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
/dev/hda3 | awk '{printf "%s", $4}'
-fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
/dev/hda3 | xargs | cut -d ' ' -f 3
+#fr.inria.ares.managedelements.linuxprobes.dfcmd=df -h /dev/hda3 | grep
/dev/hda3 | xargs | cut -d ' ' -f 3
#
@@ -89,7 +87,6 @@
javax.swing.text.rtf; \
javax.swing.tree; \
javax.swing.undo; \
- javax.transaction; \
org.omg.CORBA; \
org.omg.CORBA_2_3; \
org.omg.CORBA_2_3.portable; \
@@ -149,8 +146,6 @@
javax.swing.text.rtf; \
javax.swing.tree; \
javax.swing.undo; \
- javax.transaction; \
- javax.transaction.xa; \
javax.xml.parsers; \
javax.xml.transform; \
javax.xml.transform.dom; \
@@ -294,8 +289,6 @@
javax.swing.text.rtf; \
javax.swing.tree; \
javax.swing.undo; \
- javax.transaction; \
- javax.transaction.xa; \
javax.xml; \
javax.xml.datatype; \
javax.xml.namespace; \
On 5/16/07, Yvan Royon <yv...@gmail.com> wrote:
>
> Hi Guillaume,
>
> On 5/15/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > 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.
>
> Mmmh, I believe the svn is up to date.
> Could you tell which references are failing?
>
> MOSGi aims to be simple, so quite a few things are missing by choice
> (for instance, only Standard MBeans are supported). But I am quite
> sure that others are missing by mistake...
>
> --
> Yvan ROYON
> INRIA Ares team, CITI Lab, INSA Lyon
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Using felix on the server side
Posted by Yvan Royon <yv...@gmail.com>.
Hi Guillaume,
On 5/15/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> 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.
Mmmh, I believe the svn is up to date.
Could you tell which references are failing?
MOSGi aims to be simple, so quite a few things are missing by choice
(for instance, only Standard MBeans are supported). But I am quite
sure that others are missing by mistake...
--
Yvan ROYON
INRIA Ares team, CITI Lab, INSA Lyon
Re: Using felix on the server side
Posted by Guillaume Nodet <gn...@gmail.com>.
On 5/16/07, Karl Pauls <ka...@gmail.com> wrote:
>
> Good to know it actually works :-)
>
> FYI, classpath extension bundles do work as of the current trunk
> provided Felix has been loaded using an URLClassloader (which is the
> case in most situations e.g., JSE, JBoss) - just keep it in mind in
> case you want to embedded Felix and use a custom classloader.
> Bootclasspath extensions, however, are not supported. The same is true
> for extension bundle refreshes in regard to automatic restarts of the
> framework (updates are effective after a manual restart only).
Could this be fixed by adding the bundle in a custom classloader
and make all bundles use this classloader as the parent ? This would work
wether Felix is loaded with a known classloader or not I guess.
Furthermore, I have one more outstanding patch that fixes a
> performance issue in case more then one (actually more like > 50)
> Felix instances are embedded and are using the same extension bundles.
> I intent to commit it soonish.
>
> regards,
>
> Karl
>
> On 5/16/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > On 5/15/07, Guillaume Nodet <gn...@gmail.com> 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 have used an extension bundle so that the needed bundle is added to
> the
> > container classloader and is available
> > to all the other bundles without any modifications. It seems to work
> > nicely.
> > FYI, the config in the pom to generate the needed artifact is the
> following
> >
> > <instructions>
> > <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
> > <Export-Package>*;version=${pkgVersion}</Export-Package>
> > <Import-Package>!*</Import-Package>
> > <Fragment-Host>system.bundle;
> > extension:=framework</Fragment-Host>
> > </instructions>
> >
> > 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.
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > >
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: Using felix on the server side
Posted by Karl Pauls <ka...@gmail.com>.
Good to know it actually works :-)
FYI, classpath extension bundles do work as of the current trunk
provided Felix has been loaded using an URLClassloader (which is the
case in most situations e.g., JSE, JBoss) - just keep it in mind in
case you want to embedded Felix and use a custom classloader.
Bootclasspath extensions, however, are not supported. The same is true
for extension bundle refreshes in regard to automatic restarts of the
framework (updates are effective after a manual restart only).
Furthermore, I have one more outstanding patch that fixes a
performance issue in case more then one (actually more like > 50)
Felix instances are embedded and are using the same extension bundles.
I intent to commit it soonish.
regards,
Karl
On 5/16/07, Guillaume Nodet <gn...@gmail.com> wrote:
> On 5/15/07, Guillaume Nodet <gn...@gmail.com> 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 have used an extension bundle so that the needed bundle is added to the
> container classloader and is available
> to all the other bundles without any modifications. It seems to work
> nicely.
> FYI, the config in the pom to generate the needed artifact is the following
>
> <instructions>
> <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
> <Export-Package>*;version=${pkgVersion}</Export-Package>
> <Import-Package>!*</Import-Package>
> <Fragment-Host>system.bundle;
> extension:=framework</Fragment-Host>
> </instructions>
>
> 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.
> >
> > --
> > Cheers,
> > Guillaume Nodet
> >
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
--
Karl Pauls
karlpauls@gmail.com
Re: Using felix on the server side
Posted by Guillaume Nodet <gn...@gmail.com>.
On 5/15/07, Guillaume Nodet <gn...@gmail.com> 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 have used an extension bundle so that the needed bundle is added to the
container classloader and is available
to all the other bundles without any modifications. It seems to work
nicely.
FYI, the config in the pom to generate the needed artifact is the following
<instructions>
<Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
<Export-Package>*;version=${pkgVersion}</Export-Package>
<Import-Package>!*</Import-Package>
<Fragment-Host>system.bundle;
extension:=framework</Fragment-Host>
</instructions>
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.
>
> --
> Cheers,
> Guillaume Nodet
>
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/