This contents of the following file is incorrect:
It should simply be:
as the 'switching' is already achieved as per:
Logged In: YES
Firstly, I'd much rather you raised this on a discussion
list rather than as a bug report. As I make clear on the bug
submission page (in highlighted text) I like to keep the bug
register for confirmed bugs, so that people searching don't
find lots of noise.
Secondly, I don't think you're right. The Javadoc for
XPathFactory has the line
as an example.
However, I agree that I may be relying more on discussions
that took place as the spec was being developed rather than
on what is finally written down, and I can't say I've done
extensive testing here.
Logged In: YES
Sorry that I didn't follow procedure, I was in a bit of a
rush and didn't read the page fully.
I'm going to see if I can file a bug against the jaxp
javadoc as it is unclear, however my original report stands
as the fore mentioned file is not compliant with the jar
file specification and hence doesn't work causing errors.
A service provider identifies itself by placing a provider-
configuration file in the resource directory META-INF/
services. The file's name should consist of the fully-
qualified name of the abstract service class. The file
should contain a newline-separated list of unique concrete
provider-class names. Space and tab characters, as well as
blank lines, are ignored. The comment character is
'#' (0x23); on each line all characters following the first
comment character are ignored. The file must be encoded in
I'll start again in the forum when i've got the javadoc
fixed, please close the call.
An interim response from Norm Walsh on this:
/ Michael Kay email@example.com was heard to say:
| What's the correct format for the
| META-INF\services\javax.xml.xpath.XPathFactory file?
Unfortunately, I think there's a bug in the way this file is
parsed in Java 1.5 (which will be/has been fixed in 1.6). A
possible solution to work with both 1.5 and 1.6 is to create
a services file with both kinds of entries, where each entry
is duplicated, in one case just listing the class name and
in the other following the format of a properties files (as
it is done now).
In other words,
I've been meaning to test this, but there's been a fire
drill this week so I haven't found time.
If you get to try it before I do, please let me know if it's
a practical workaround.
Be seeing you,
The bug being talked about by Norm Walsh I believe is:
I have filed a bug report will sun about the javadoc still
being 'fuzzy' about the property file. It is being reviewed
but apparantly I've to wait an average of 3 weeks for sun
to confirm my problem.