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 <[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
