Re: Apple's JAXP & 14compatibility.jar

Subject: Re: Apple's JAXP & 14compatibility.jar

From: Adam Ohren <email@hidden>

Date: Sun, 29 Apr 2007 00:18:38 -0400

Delivered-to: email@hidden

Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer; b=sPpm/bnhArJgFr1KvjO61gyy95pHf4cE91K5ls2XY+i9E/vdR3KlsYjbuBEekQcdCjo/YqZh5952zSlkj5itWq0KmURagb8e8SuNwhYSNphqNuernj8gFxxyU1nJT+9J/G2JR5x1iD3CU9jENf8ChlKJ/liCe7mzIeQtgbLZofk=

Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer; b=Mq5p6HrjcrAXBXnEh6rpAdO8hg3BEhLpofQrD5/bIPrEEtSPOsmrtqgSOMDIV+ogyq1WykOLeBcV5af9ELhuj1ZzOHTHQZxyJItrEF+fuK/WeVaaEu6/oTJW+1+UvgmmPZQd0+0EDOJ5kDfqHR8QzSUAzf8p5FtY2Wgn6uehxuY=

Hey GG,

Thanks for the insight. I'll try to see how that affects the issue. That'd be cool, in general, if I can get that to work out.

Because I would think that, more generally, this issue affects ANYone's ability to switch JAXP implementations. Has anyone tried to do this and been successful at using an engine other than the supplied Crimson?

Also, I looked at Sun's JDK documentation and the links you sent (thanks again, btw) for more information about how the JVM builds the user class path. It specifies the possible sources for constructing the search path. Wherever Apple's launcher is getting 14compatibility.jar's path from, it's not listed in the JDK as being a possible source.

http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html

So I guess just, nota bene all, the user classpath isn't what it's documented to be.

Adam Ohren

email@hidden

On Apr 28, 2007, at 3:03 PM, email@hidden wrote:

I don't think the order of choice is random. Sun's service-provider

interfaces, which I'm assuming JAXP uses, use a file in the manifest of a

jar, and the jars are searched in ClassLoader.getResources() order.

<http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service Provider>

If you can figure out what classpath is being used, and put a service

provide file in a suitable jar (even if the classes are in another jar),

you should be able to control JAXP's order. You might need to look at the

source of DocumentBuilderFactory.newInstance().

One problem is that NetBeans may not be staying alive long enough for you

to easily diagnose how to fix this. In other words, it's doing the "exit

on failure" thing, instead of the "limp-along" thing.

One way to figure out the class-loader tree is a little tool I wrote called

ListClassLoaders:

<http://lists.apple.com/archives/java-dev/2006/May/msg00274.html>

If you can convince NetBeans to stay running long enough, perhaps by not

installing the module that causes the failure, you can write a simple

plugin that does getResources() on the service-provider name that JAXP is

referencing. To figure out the SP name, you may have to dig into JAXP's

source. But once you know where Apple's SP insertion is located in the

sequence, all you have to do is get into a jar that comes before it. In

other words, if Apple can use SP discovery to insert its parser, you can

use SP discovery to insert yours before it. The trick is in figuring out

which jar to go in to get before it.

-- GG

_______________________________________________ Do not post admin requests to the list. They will be ignored. Java-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/java-dev/email@hidden This email sent to email@hidden