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