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 2008/03/03 11:17:53 UTC
Classloaders and FrameworkUtil
Currently, there is a problem if you have both org.osgi.core jar and
the framework jar in your classpath because both can not be easily
used together.
For example I'm writing junit tests that use LDAP filters. The OSGi
standard way to create those is to call:
osg.osgi.framework.FrameworkUtil.createFilter(...)
Unfortunately, the org.osgi.core jar defines an implementation which
is not compatible with the felix framework, because it looks for a
class named FrameworkUtil in a package defined by a system property
(org.osgi.vendor.framework). This class is not defined by the felix
framework. This is usually not a problem in the OSGi container,
because the classpath is correctly set, but when writing junit tests
in maven, it sometimes quite tricky to order the classpath correctly
(I haven't found a way in my case).
So I', wondering if I could write a patch that would add this class
and that would allow the standard call to work even if the classpath
is not correctly ordered.
Actually, it's just a copy of the org.osgi.framework.FrameworkUtil
class in the org.apache.felix.framework class I suppose.
Thoughts ? Would such a patch be accepted ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Classloaders and FrameworkUtil
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Guillaume Nodet wrote:
> That was my initial idea, but wouldn't it break compatibility at some point ?
> It would require users to set a system property or to change the class in the
> org.osgi package to have a default property which would be the felix one ?
> I'm not sure what the spec requires exactly ...
>
It would require that the system property always be correctly set,
yes...which would suck.
> Well, I can always use my own copy of the said class in my own package
> and specify the system property correctly ...
>
Might be the best approach for you.
-> richard
>
>> -> richard
>>
>>
>>
>
>
>
>
Re: Classloaders and FrameworkUtil
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Mar 3, 2008 at 3:31 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Guillaume Nodet wrote:
> > Currently, there is a problem if you have both org.osgi.core jar and
> > the framework jar in your classpath because both can not be easily
> > used together.
> > For example I'm writing junit tests that use LDAP filters. The OSGi
> > standard way to create those is to call:
> > osg.osgi.framework.FrameworkUtil.createFilter(...)
> >
> > Unfortunately, the org.osgi.core jar defines an implementation which
> > is not compatible with the felix framework, because it looks for a
> > class named FrameworkUtil in a package defined by a system property
> > (org.osgi.vendor.framework). This class is not defined by the felix
> > framework. This is usually not a problem in the OSGi container,
> > because the classpath is correctly set, but when writing junit tests
> > in maven, it sometimes quite tricky to order the classpath correctly
> > (I haven't found a way in my case).
> >
> > So I', wondering if I could write a patch that would add this class
> > and that would allow the standard call to work even if the classpath
> > is not correctly ordered.
> > Actually, it's just a copy of the org.osgi.framework.FrameworkUtil
> > class in the org.apache.felix.framework class I suppose.
> >
> > Thoughts ? Would such a patch be accepted ?
> >
>
> I am not interested in a patch to add a duplicate class to the code
> base, especially since I am always trying to eliminate classes to keep
> the size down. However, perhaps we can try to think if there is another
> approach. The simple approach is to put FrameworkUtil in a different
> package and then just use the standard version of the class to look it up.
That was my initial idea, but wouldn't it break compatibility at some point ?
It would require users to set a system property or to change the class in the
org.osgi package to have a default property which would be the felix one ?
I'm not sure what the spec requires exactly ...
>
> But I don't think we are the only framework to implement it this way,
> i.e., replacing the default impl of FrameworkUtil directly. I think most
> try to avoid the level of indirection.
>
> So, I'd prefer a different solution.
Well, I can always use my own copy of the said class in my own package
and specify the system property correctly ...
>
> -> richard
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Classloaders and FrameworkUtil
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Guillaume Nodet wrote:
> What do you mean by "plain jane jar" ? I don't see anything in the spec
> specifying how the filter creating should be done, so I suppose the current
> code is specific to the felix jar. Then, it would make more sense to just
> return throw a meaninfull exception instead of including some code that has
> no purpose at all.
>
It is not of "no purpose"...as I understand it, the current code in the
OSGi class looks up a system property to find the class. Thus, it is
possible to use the plain OSGi jar file if you set this system property
when you launch your application.
As I mentioned previously, I believe that most framework impls do not
set this property, but instead directly replace FrameworkUtil, but I
could be mistaken.
-> richard
> On Tue, Mar 4, 2008 at 4:34 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> Guillaume Nodet wrote:
>> > So what about the following one:
>> > * in framework, move the FrameworkUtil class from org.osgi.core to
>> > org.apache.felix.framework
>> > * in framework, add a META-INF/services/org.osgi.vendor.framework
>> > property file pointing to org.apache.felix
>> > * in org.osgi.core, add some code to look into the META-INF/services
>> > if the system property is not set (or use a default value for the
>> > System.property)
>> >
>>
>> Well, for org.osgi.core, we are trying to distribute the plain jane OSGi
>> jar, so it doesn't make sense to modify it, I don't think.
>>
>> -> richard
>>
>>
>>
>> >
>> > On Mon, Mar 3, 2008 at 3:31 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>> >
>> >> Guillaume Nodet wrote:
>> >> > Currently, there is a problem if you have both org.osgi.core jar and
>> >> > the framework jar in your classpath because both can not be easily
>> >> > used together.
>> >> > For example I'm writing junit tests that use LDAP filters. The OSGi
>> >> > standard way to create those is to call:
>> >> > osg.osgi.framework.FrameworkUtil.createFilter(...)
>> >> >
>> >> > Unfortunately, the org.osgi.core jar defines an implementation which
>> >> > is not compatible with the felix framework, because it looks for a
>> >> > class named FrameworkUtil in a package defined by a system property
>> >> > (org.osgi.vendor.framework). This class is not defined by the felix
>> >> > framework. This is usually not a problem in the OSGi container,
>> >> > because the classpath is correctly set, but when writing junit tests
>> >> > in maven, it sometimes quite tricky to order the classpath correctly
>> >> > (I haven't found a way in my case).
>> >> >
>> >> > So I', wondering if I could write a patch that would add this class
>> >> > and that would allow the standard call to work even if the classpath
>> >> > is not correctly ordered.
>> >> > Actually, it's just a copy of the org.osgi.framework.FrameworkUtil
>> >> > class in the org.apache.felix.framework class I suppose.
>> >> >
>> >> > Thoughts ? Would such a patch be accepted ?
>> >> >
>> >>
>> >> I am not interested in a patch to add a duplicate class to the code
>> >> base, especially since I am always trying to eliminate classes to keep
>> >> the size down. However, perhaps we can try to think if there is another
>> >> approach. The simple approach is to put FrameworkUtil in a different
>> >> package and then just use the standard version of the class to look it up.
>> >>
>> >> But I don't think we are the only framework to implement it this way,
>> >> i.e., replacing the default impl of FrameworkUtil directly. I think most
>> >> try to avoid the level of indirection.
>> >>
>> >> So, I'd prefer a different solution.
>> >>
>> >> -> richard
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>>
>>
>
>
>
>
Re: Classloaders and FrameworkUtil
Posted by Guillaume Nodet <gn...@gmail.com>.
What do you mean by "plain jane jar" ? I don't see anything in the spec
specifying how the filter creating should be done, so I suppose the current
code is specific to the felix jar. Then, it would make more sense to just
return throw a meaninfull exception instead of including some code that has
no purpose at all.
On Tue, Mar 4, 2008 at 4:34 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> Guillaume Nodet wrote:
> > So what about the following one:
> > * in framework, move the FrameworkUtil class from org.osgi.core to
> > org.apache.felix.framework
> > * in framework, add a META-INF/services/org.osgi.vendor.framework
> > property file pointing to org.apache.felix
> > * in org.osgi.core, add some code to look into the META-INF/services
> > if the system property is not set (or use a default value for the
> > System.property)
> >
>
> Well, for org.osgi.core, we are trying to distribute the plain jane OSGi
> jar, so it doesn't make sense to modify it, I don't think.
>
> -> richard
>
>
>
> >
> > On Mon, Mar 3, 2008 at 3:31 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> >
> >> Guillaume Nodet wrote:
> >> > Currently, there is a problem if you have both org.osgi.core jar and
> >> > the framework jar in your classpath because both can not be easily
> >> > used together.
> >> > For example I'm writing junit tests that use LDAP filters. The OSGi
> >> > standard way to create those is to call:
> >> > osg.osgi.framework.FrameworkUtil.createFilter(...)
> >> >
> >> > Unfortunately, the org.osgi.core jar defines an implementation which
> >> > is not compatible with the felix framework, because it looks for a
> >> > class named FrameworkUtil in a package defined by a system property
> >> > (org.osgi.vendor.framework). This class is not defined by the felix
> >> > framework. This is usually not a problem in the OSGi container,
> >> > because the classpath is correctly set, but when writing junit tests
> >> > in maven, it sometimes quite tricky to order the classpath correctly
> >> > (I haven't found a way in my case).
> >> >
> >> > So I', wondering if I could write a patch that would add this class
> >> > and that would allow the standard call to work even if the classpath
> >> > is not correctly ordered.
> >> > Actually, it's just a copy of the org.osgi.framework.FrameworkUtil
> >> > class in the org.apache.felix.framework class I suppose.
> >> >
> >> > Thoughts ? Would such a patch be accepted ?
> >> >
> >>
> >> I am not interested in a patch to add a duplicate class to the code
> >> base, especially since I am always trying to eliminate classes to keep
> >> the size down. However, perhaps we can try to think if there is another
> >> approach. The simple approach is to put FrameworkUtil in a different
> >> package and then just use the standard version of the class to look it up.
> >>
> >> But I don't think we are the only framework to implement it this way,
> >> i.e., replacing the default impl of FrameworkUtil directly. I think most
> >> try to avoid the level of indirection.
> >>
> >> So, I'd prefer a different solution.
> >>
> >> -> richard
> >>
> >>
> >>
> >
> >
> >
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Classloaders and FrameworkUtil
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Guillaume Nodet wrote:
> So what about the following one:
> * in framework, move the FrameworkUtil class from org.osgi.core to
> org.apache.felix.framework
> * in framework, add a META-INF/services/org.osgi.vendor.framework
> property file pointing to org.apache.felix
> * in org.osgi.core, add some code to look into the META-INF/services
> if the system property is not set (or use a default value for the
> System.property)
>
Well, for org.osgi.core, we are trying to distribute the plain jane OSGi
jar, so it doesn't make sense to modify it, I don't think.
-> richard
>
> On Mon, Mar 3, 2008 at 3:31 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> Guillaume Nodet wrote:
>> > Currently, there is a problem if you have both org.osgi.core jar and
>> > the framework jar in your classpath because both can not be easily
>> > used together.
>> > For example I'm writing junit tests that use LDAP filters. The OSGi
>> > standard way to create those is to call:
>> > osg.osgi.framework.FrameworkUtil.createFilter(...)
>> >
>> > Unfortunately, the org.osgi.core jar defines an implementation which
>> > is not compatible with the felix framework, because it looks for a
>> > class named FrameworkUtil in a package defined by a system property
>> > (org.osgi.vendor.framework). This class is not defined by the felix
>> > framework. This is usually not a problem in the OSGi container,
>> > because the classpath is correctly set, but when writing junit tests
>> > in maven, it sometimes quite tricky to order the classpath correctly
>> > (I haven't found a way in my case).
>> >
>> > So I', wondering if I could write a patch that would add this class
>> > and that would allow the standard call to work even if the classpath
>> > is not correctly ordered.
>> > Actually, it's just a copy of the org.osgi.framework.FrameworkUtil
>> > class in the org.apache.felix.framework class I suppose.
>> >
>> > Thoughts ? Would such a patch be accepted ?
>> >
>>
>> I am not interested in a patch to add a duplicate class to the code
>> base, especially since I am always trying to eliminate classes to keep
>> the size down. However, perhaps we can try to think if there is another
>> approach. The simple approach is to put FrameworkUtil in a different
>> package and then just use the standard version of the class to look it up.
>>
>> But I don't think we are the only framework to implement it this way,
>> i.e., replacing the default impl of FrameworkUtil directly. I think most
>> try to avoid the level of indirection.
>>
>> So, I'd prefer a different solution.
>>
>> -> richard
>>
>>
>>
>
>
>
>
Re: Classloaders and FrameworkUtil
Posted by Guillaume Nodet <gn...@gmail.com>.
So what about the following one:
* in framework, move the FrameworkUtil class from org.osgi.core to
org.apache.felix.framework
* in framework, add a META-INF/services/org.osgi.vendor.framework
property file pointing to org.apache.felix
* in org.osgi.core, add some code to look into the META-INF/services
if the system property is not set (or use a default value for the
System.property)
On Mon, Mar 3, 2008 at 3:31 PM, Richard S. Hall <he...@ungoverned.org> wrote:
>
> Guillaume Nodet wrote:
> > Currently, there is a problem if you have both org.osgi.core jar and
> > the framework jar in your classpath because both can not be easily
> > used together.
> > For example I'm writing junit tests that use LDAP filters. The OSGi
> > standard way to create those is to call:
> > osg.osgi.framework.FrameworkUtil.createFilter(...)
> >
> > Unfortunately, the org.osgi.core jar defines an implementation which
> > is not compatible with the felix framework, because it looks for a
> > class named FrameworkUtil in a package defined by a system property
> > (org.osgi.vendor.framework). This class is not defined by the felix
> > framework. This is usually not a problem in the OSGi container,
> > because the classpath is correctly set, but when writing junit tests
> > in maven, it sometimes quite tricky to order the classpath correctly
> > (I haven't found a way in my case).
> >
> > So I', wondering if I could write a patch that would add this class
> > and that would allow the standard call to work even if the classpath
> > is not correctly ordered.
> > Actually, it's just a copy of the org.osgi.framework.FrameworkUtil
> > class in the org.apache.felix.framework class I suppose.
> >
> > Thoughts ? Would such a patch be accepted ?
> >
>
> I am not interested in a patch to add a duplicate class to the code
> base, especially since I am always trying to eliminate classes to keep
> the size down. However, perhaps we can try to think if there is another
> approach. The simple approach is to put FrameworkUtil in a different
> package and then just use the standard version of the class to look it up.
>
> But I don't think we are the only framework to implement it this way,
> i.e., replacing the default impl of FrameworkUtil directly. I think most
> try to avoid the level of indirection.
>
> So, I'd prefer a different solution.
>
> -> richard
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Classloaders and FrameworkUtil
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Guillaume Nodet wrote:
> Currently, there is a problem if you have both org.osgi.core jar and
> the framework jar in your classpath because both can not be easily
> used together.
> For example I'm writing junit tests that use LDAP filters. The OSGi
> standard way to create those is to call:
> osg.osgi.framework.FrameworkUtil.createFilter(...)
>
> Unfortunately, the org.osgi.core jar defines an implementation which
> is not compatible with the felix framework, because it looks for a
> class named FrameworkUtil in a package defined by a system property
> (org.osgi.vendor.framework). This class is not defined by the felix
> framework. This is usually not a problem in the OSGi container,
> because the classpath is correctly set, but when writing junit tests
> in maven, it sometimes quite tricky to order the classpath correctly
> (I haven't found a way in my case).
>
> So I', wondering if I could write a patch that would add this class
> and that would allow the standard call to work even if the classpath
> is not correctly ordered.
> Actually, it's just a copy of the org.osgi.framework.FrameworkUtil
> class in the org.apache.felix.framework class I suppose.
>
> Thoughts ? Would such a patch be accepted ?
>
I am not interested in a patch to add a duplicate class to the code
base, especially since I am always trying to eliminate classes to keep
the size down. However, perhaps we can try to think if there is another
approach. The simple approach is to put FrameworkUtil in a different
package and then just use the standard version of the class to look it up.
But I don't think we are the only framework to implement it this way,
i.e., replacing the default impl of FrameworkUtil directly. I think most
try to avoid the level of indirection.
So, I'd prefer a different solution.
-> richard