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 <[EMAIL PROTECTED]> 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/
