[9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader
Georgiy Rakov
georgiy.rakov at oracle.com
Fri Oct 2 17:36:26 UTC 2015
On 02.10.2015 18:52, Miroslav Kos wrote:
> There is an updated version:
> http://cr.openjdk.java.net/~mkos/8131334/specdiff.07/index.html
> Two changes:
> 1) SAAJMetaFactory javadoc - new (self contained) paragraph describing
> the algorithm for the factory + apiNote
> 2) package javadoc: added back SAAJMetaFactory + "all these factories
> define newInstance method ..." changed to "first three ..." + sentence
> about instantiating SAAJMetaFactory
>
>
> On 02/10/15 16:21, Georgiy Rakov wrote:
>> According to the spec ofSAAJMetaFactory.newInstance method there is
>> the last step of lookup procedure:
>> * <LI>Default to
>> com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl.
> I mentioned the default impl. I believe it's specific enough - in jdk8
> version there is nothing regarding this ...
>> If this step is still performed, I believe this should be mentioned
>> like it's made in the last step of the lookup procedure described in
>> javax.xml.soap: "...or platform default implementation is used...".
>> BTW it would be good to mention what newMessageFactory and
>> newSOAPFactory of this default implementation return (I guess the
>> default implementations of corresponding factories).
> I don't think it's necessary.
From conformance testing perspective it's not clear what to expect from
MessageFactory.newInstance and SOAPFactory.newInstance when there is no
configuration at all (ServiceLoader is not configured, jaxm.properties
is missing, corresponding system property is not set). For instance
returning null doesn't contradict spec. Not specifying it actually means
that this is left up to implementation. Any conformance tests written
and expecting non-null result could be successfully challenged by an
external implementer returning null since there is no spec about it.
Thus we merely cannot write conformance tests verifying MessageFactory
and SOAPFactory default implementations if this is the way how they are
to be obtained. I'm telling about the way of obtaining the default
implementation because there are actually another way that is to
configure ServiceLoader to return default implementation. But I don't
like this idea, since there are other questions arise, for instance if
we should normatively specify that ServiceLoader should be configured to
return default implementation.
The rest looks great.
Thanks,
Georgiy.
More information about the core-libs-dev
mailing list