On 31/08/2012 18:12, Joe Wang wrote:
:
Okay, let's streamline the factories. I think we should:
1) align to the SAX/DOM since these are most frequently used, and
proven. Any changes to other factories will have lower impact in
comparison;
2) no spec change involved: for example, the StAX factories have
newFactory/newInstance(String factoryId, ClassLoader classLoader),
while others define the first parameter as factory classname, e.g.
newInstance(String factoryClassName, ClassLoader classLoader). We
also know that some factories have throws clause while others don't.
In this effort of making factories behave consistently, we'll restrain
from making any spec change.
SecuritySupport.getContextClassLoader for the parsers looks like it does
the right thing and it would be good to get that propagated to the other
places where it's not quite right.
On spec changes then I think they will need to be examined. You mention
StAX but when I read the javadoc for methods such as
XMLEventFactory.newFactory then it has wooly wording such as " The
Services API will look for a classname in the file
META-INF/services/javax.xml.stream.XMLEventFactory in jars available to
the runtime". I think part of the reason for the inconsistent lookup
throughout this API is that it wasn't properly specified in the first
place so it needs to be on the radar to get the specification sorted out
too. Whether this is done as part of sorting out the factory finders or
as part of changing the code to use ServiceLoader probably doesn't
matter I guess. However, I think we do need to create a table of
specified behavior, actual behavior, and proposed behavior for each
factory and for each of the security manager vs. no security manager
cases too.
The other thing for a first phase is a good set of tests. They are going
to be needed to understand the before and after behavior anyway.
-Alan
