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