Fwd: Xpath api dependency in nakamura?

7 views
Skip to first unread message

Carl Hall

unread,
Jun 21, 2011, 8:16:10 PM6/21/11
to sakai-...@googlegroups.com, Zach A. Thomas, azec...@unicon.net
Moving the conversation to the mail list.

---------- Forwarded message ----------
From: Carl Hall <ca...@hallwaytech.com>
Date: Tue, Jun 21, 2011 at 5:14 PM
Subject: Re: Xpath api dependency in nakamura?
To: "Zach A. Thomas" <za...@aeroplanesoftware.com>
Cc: Aaron Zeckoski <azec...@unicon.net>


I don't see any javadocs or exports for com.sun.* which is usually a
terrible package to use anyway. The class Kaltura is looking for is in
the system jar but none of the com.sun.* packages are exported from
there nor do I expect that they will be. The XPath API bundle is
already available as part of Nakamura but the class Kaltura wants is
usually delivered from the jaxp-ri jar[1].

For at least 1 bundle if not 2, jaxp-ri is embedded as a dependency.
We're probably at a point now that we should use include the
servicemix bundle for jaxp-ri. Please file a JIRA for this, so that it
doesn't fall through the cracks. I'm on vacation till next week and
can look at it when I'm back if no one else has handled it. Including
the servicemix bundle in bundles/list.xml is a pretty painless patch
anyway.

As far as bypassing the instantiation of XmlUtils, you'd have to go
into the Kaltura code and tell it to not use the class or bypass using
any classes that call the code that access that class. Lazy
instantiation/access will allow OSGi to not include classes that
aren't used but you can't stop it once the call goes out. There are
some tricks you can try but, honestly, it'd be a lot more work than
bringing in the jaxp-ri library.

1 http://www.findjar.com/class/com/sun/org/apache/xpath/internal/XPathAPI.html

On Tue, Jun 21, 2011 at 3:29 PM, Zach A. Thomas
<za...@aeroplanesoftware.com> wrote:
> This is likely to be a version conflict, though I've never seen this particular one. I agree, it's strange that it would be complaining about something from core Java.
>
> I don't have any particular insight, but Carl might. Is there a way to instantiate the Kaltura client that bypasses the call to XmlUtils?
>
> cheers,
> Zach
> On Jun 21, 2011, at 3:31 PM, Aaron Zeckoski wrote:
>
>> I am running into an issue where I cannot get the kaltura library to
>> connect to the server because of a runtime failure:
>> 21.06.2011 16:26:03.127 *ERROR* [FelixPackageAdmin] net.unicon.kaltura
>> [net.unicon.kaltura.service.KalturaService] The activate method has
>> thrown an exception (java.lang.NoClassDefFoundError:
>> com/sun/org/apache/xpath/internal/XPathAPI)
>> java.lang.NoClassDefFoundError:
>> com/sun/org/apache/xpath/internal/XPathAPI
>>       at com.kaltura.client.utils.XmlUtils.getTextValue(XmlUtils.java:60)
>>       at com.kaltura.client.services.KalturaSessionService.start(KalturaSessionService.java:62)
>>       at net.unicon.kaltura.service.KalturaService.makeKalturaClient(KalturaService.java:346)
>>       at net.unicon.kaltura.service.KalturaService.init(KalturaService.java:211)
>>       at net.unicon.kaltura.service.KalturaService.activate(KalturaService.java:162)
>>       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>       at java.lang.reflect.Method.invoke(Method.java:597)
>>
>> It looks like I am missing the xpath API which is totally confusing
>> since it is included in core java as far as I can see. When I try to
>> deploy my package in a standalone felix it works fine so I am guessing
>> this is nakamura specific. Any ideas?
>>
>> -AZ
>>
>>
>> --
>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
>

Ian Boston

unread,
Jun 22, 2011, 3:42:10 AM6/22/11
to sakai-...@googlegroups.com
Hi,
Please embed the jaxp-ri jar rather than add it as a bundle. I dont
want Nakamura to explicitly depend on com.sun.* packages. If you must
have it as a bundle, then do it in the NYU build please.
Thanks
Ian
> --
> You received this message because you are subscribed to the Google Groups "Sakai Nakamura" group.
> To post to this group, send email to sakai-...@googlegroups.com.
> To unsubscribe from this group, send email to sakai-kernel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sakai-kernel?hl=en.
>
>

Aaron Zeckoski

unread,
Jun 22, 2011, 2:14:08 PM6/22/11
to Carl Hall, sakai-...@googlegroups.com, Zach A. Thomas
Looks like adding this should work (maybe along with some tweaks to my
import-package). I will give it a try now.

<dependency>
<groupId>org.sakaiproject.nakamura</groupId>
<artifactId>org.sakaiproject.nakamura.jaxp-api</artifactId>
<version>1.3.0</version>
<scope>provided</scope>
</dependency>


<Import-Package>com.sun.org.apache.xpath.*,!com.sun.*,!junit.*,*</Import-Package>

Is this what you were thinking?
-AZ

Carl Hall

unread,
Jun 23, 2011, 12:21:41 AM6/23/11
to Aaron Zeckoski, sakai-...@googlegroups.com, Zach A. Thomas
o.s.n.jaxp-api doesn't export com.sun.org.apache.xpath. As far as I know, we shouldn't have any bundles that export com.sun.* at all. If we do it's wrong. You'll want to use the Embed-Dependency directive with the bundle plugin to embed the jaxp-ri artifact into your bundle rather than importing the class from outside of the bundle.

Aaron Zeckoski

unread,
Jun 24, 2011, 4:38:38 PM6/24/11
to Carl Hall, sakai-...@googlegroups.com, Zach A. Thomas
I ended up rewriting the underlying kaltura library to remove the
dependency. It transforms the kaltura integration bundle into GPL as a
result but what can you do.

Thanks for the help
:-)
-AZ

Reply all
Reply to author
Forward
0 new messages