Paul, Alan,
Confusion was what jaxp meant to give :) I was told that the
factory/object finders, security support classes were duplicated, and
needed to be kept in sync. But they are not even in their original
form, unfortunately.
Both of you mentioned that it's desirable to make SCE the cause for the
configuration exception. DatatypeConfigurationException is different
from all others in that, it's an Exception while others Error, it takes
Throwable as cause while others Exception. I did not want to change the
signatures of the other configuration error classes, that is, the
constructors would need to take Throwable instead of Exception (as they
should have already done).
As a comprise, I've wrapped the error message in a confguration error.
Would you think it's sufficient to add to the message what you did below
(e.g. " could not be loaded or instantiated using java.util.ServiceLoader"?
Or are you into making signature changes? (sth. I thought we didn't
want to for this patch)
--Joe
On 8/29/2012 8:56 AM, Paul Sandoz wrote:
On Aug 29, 2012, at 10:56 AM, Paul Sandoz<paul.san...@oracle.com> wrote:
Hi Joe,
I would urge you to reconsider errors using SL, since SL is being explicitly
called out as part of the specification.
You can make any such SL-related errors more meaningful (yes, i want the stack
trace telling what bits of SL code were called!) and remove any potential for
CCEs, due to linkage errors [*], by passing the SCE instance to the constructor
of DatatypeConfigurationException or the FactoryConfigurationError variants e.g.
244 } catch (ServiceConfigurationError e) {
245 throw new DatatypeConfigurationException(""Provider " + className +
" could not be loaded or instantiated using java.util.ServiceLoader", e);
Doh, please shoot me now, i was labouring under the misapprehension that SCE
was extending from Exception and not Error.
Apologies for the confusion.
Paul.
