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
