felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Classloaders and FrameworkUtil
Date Tue, 04 Mar 2008 15:56:11 GMT
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 <heavy@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 <heavy@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
>>  >>
>>  >>
>>  >>
>>  >
>>  >
>>  >
>>  >
>>
>>     
>
>
>
>   

Mime
View raw message