Richard,

Here is locations of the equinox services/utils that I used.

<!-- copied from pax runner equinox platform profile configuration -->
<bundle>
      <name>Eclipse utilities</name>
      <url>
http://download.eclipse.org/equinox/drops/S-3.5M7-200904302300/org.eclipse.osgi.util_3.2.0.v20090429-1630.jar
</url>
    </bundle>
    <bundle>
      <name>Eclipse compendium services</name>
      <url>
http://download.eclipse.org/equinox/drops/S-3.5M7-200904302300/org.eclipse.osgi.services_3.2.0.v20090429-1630.jar
</url>
    </bundle>

It looks like equinox splits compendium between services and utils.
I also found DynamicImport confusing but I am not sure how it impacts the
whole class loading issue.  Still learning here :)

I would be happy to try a patched compendium bundle.  I would really hate to
keep evolving my own version of kernel :)

Thanks again

Dmitry

On Fri, May 15, 2009 at 10:26 AM, Richard S. Hall <he...@ungoverned.org>wrote:

> I think similar issues have been raised before. The only thing I can see
> that is different, is Felix' compendium does a "DynamicImport-Package: *" to
> avoid having hard dependencies on other packages.
>
> I am not exactly sure why this decision was made, but I think it was
> related to some situation where someone what some specific interface out of
> compendium, but didn't want to be constrained by its other requirements
> (e.g., javax.servlet, etc.).
>
> I am not sure if changing this would fix the issue. Dmitry, I could create
> a modified version of compendium to send to you if you want to test it to
> see if it fixes your issue. Could you send me a reference to Eclipse's
> compendium so I can look at its manifest?
>
> -> richard
>
>
> On 5/15/09 10:18 AM, Guillaume Nodet wrote:
>
>> Not sure exactly.  I don't think this comes from a problem with the
>> classes used, but maybe from the version of the package exported.
>> IIRC, equinox follows the not yet published spec of OSGi 4.2, so it
>> may already has bumped some of the packages, though I'm still not sure
>> how that would affect the bundles.
>>
>> We need to rule out a number of things: have you tried without
>> upgrading spring-dm ? What if you use felix instead of equinox ?
>>
>> On Fri, May 15, 2009 at 15:21, Dmitry Sklyut
>> <dskl...@chariotsolutions.com>  wrote:
>>
>>
>>> Hi All,
>>>
>>> I am trying to use Karaf with equinox and ran into a very strange
>>> classloading issue yesterday.
>>>
>>> Here is a situation:
>>> 1. Stock karaf with FELIX-1150 (
>>> https://issues.apache.org/jira/browse/FELIX-1150) applied (upgrade to
>>> Spring
>>> 2.5.6.SEC01 and SpringDM 1.2.0) and config.properties modified to point
>>> to
>>> equinox (i.e. karaf.framework=equinox)
>>> 2. Bundle "datasource" wraps h2database and c3p0 and publishes a
>>> DataSource
>>> 3. Bundle "hibernate" is session factory producing bundle.  It publishes
>>> SessionFactory and Spring PlatformTransactionManager using SpringDM.
>>> 4. All of the supporting spring libraries (transaction, orm, etc) and
>>> hibernate (pulled from BRITS) and supporting java spec bundles are also
>>> deployed.
>>>
>>> When deploying those two bundles I was constantly getting a CNF on
>>> org.hibernate.JDBCException in Karaf from bundle .  Those bundles were
>>> working just fine with Pax Runner.
>>> I thought that it was a problem with my bundles.  I tried everything,
>>> modified imports, tried require bundle (with reexport and without),
>>> finally
>>> tried Dynamic import = *.
>>> Still I was getting a CNF.
>>>
>>> I finally reconfigured Karaf to use:
>>> 1. org.eclipse.osgi.services-3.2.0.v20090429.jar vs.
>>>
>>> org/apache/felix/org.osgi.compendium/${felix.compendium.version}/org.osgi.compendium-${felix.compendium.version}.jar
>>> 2. org.eclipse.osgi.util-3.2.0.v20090429.jar because PAX runner uses it
>>> in
>>> minimal equinox configuraiton.
>>>
>>> Now everything seems to work.  So I have a solution for my issue, but I
>>> still don't have a "WHY" this issue came up.  Can anyone think of a
>>> "WHY"?
>>> Is it an isseu with Compendium services used in stock Karaf?
>>>
>>> I am willing to submit my changes as a patch but I would like to discuss
>>> this a little more to get it right.  I have a pax-construct project that
>>> generates required dependencies and bundles in question for testing if
>>> anyone is interested in trying this.
>>>
>>> Thanks in advance
>>>
>>> Dmitry
>>>
>>>
>>>
>>
>>
>>
>>
>>
>

Reply via email to