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 StA
On 8/31/2012 4:20 AM, Alan Bateman wrote:
On 31/08/2012 08:59, Joe Wang wrote:
Yes, it works just fine under normal conditions.
Note the old process: read the service file using TCCL (if null,
system cl), if nothing found, then BCL
Somehow I was under the impression ServiceLoader does jus
On 31/08/2012 08:59, Joe Wang wrote:
Yes, it works just fine under normal conditions.
Note the old process: read the service file using TCCL (if null,
system cl), if nothing found, then BCL
Somehow I was under the impression ServiceLoader does just that so
that we could delegate to it. It'
On Aug 30, 2012, at 11:20 PM, Alan Bateman wrote:
> On 30/08/2012 19:38, Joe Wang wrote:
>> Hi Paul, Alan,
>>
>> I've read your latest comments. Before getting back to you on those items,
>> I felt it's important we get the classloader handling correctly. If it's as
>> what I suspected (as
On 8/30/2012 2:20 PM, Alan Bateman wrote:
On 30/08/2012 19:38, Joe Wang wrote:
Hi Paul, Alan,
I've read your latest comments. Before getting back to you on those
items, I felt it's important we get the classloader handling
correctly. If it's as what I suspected (as I described in the last
On 30/08/2012 19:38, Joe Wang wrote:
Hi Paul, Alan,
I've read your latest comments. Before getting back to you on those
items, I felt it's important we get the classloader handling
correctly. If it's as what I suspected (as I described in the last
email), we may have problem with using Serv
Hi Paul, Alan,
I've read your latest comments. Before getting back to you on those
items, I felt it's important we get the classloader handling correctly.
If it's as what I suspected (as I described in the last email), we may
have problem with using ServiceLoader.
I've read Paul's explanat
On Aug 30, 2012, at 8:59 AM, Joe Wang wrote:
> Alan, Paul,
>
> While I was writing a summery as you suggested below, I noticed an issue with
> using ServiceLoader. I was trying to use the word 'delegate' but found the
> ServiceLoader might be doing sth. different than the original jaxp proce
On 30/08/2012 00:08, Joe Wang wrote:
I actually updated the webrev yesterday with your suggestion.
Can you send a link? I checked the original location [1] but it's
doesn't seem to have updated since Monday evening.
-Alan
[1] http://cr.openjdk.java.net/~joehw/jdk8/7169894/
On Aug 30, 2012, at 1:33 AM, Joe Wang wrote:
> Paul, Alan,
>
> Confusion was what jaxp meant to give :)
My eyes wobble when i look at all that class loading code!
> I was told that the factory/object finders, security support classes were
> duplicated, and needed to be kept in sync. But
Hi Joe,
On Aug 30, 2012, at 1:08 AM, Joe Wang wrote:
> I actually updated the webrev yesterday with your suggestion.
>
OK! Sorry if i am being stubbornly persistent!
> Recall our discussions back in June, the suggestion was to delegate to the
> ServiceLoader, e.g. ServiceLoader.load(servi
Alan, Paul,
While I was writing a summery as you suggested below, I noticed an issue
with using ServiceLoader. I was trying to use the word 'delegate' but
found the ServiceLoader might be doing sth. different than the original
jaxp process.
Here's the spec:
The ServiceLoader.load(service) i
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
I actually updated the webrev yesterday with your suggestion.
Recall our discussions back in June, the suggestion was to delegate to
the ServiceLoader, e.g. ServiceLoader.load(serviceClass). The rational
was that the ServiceLoader uses context and then bootstrap class loader.
The spec for pub
On Aug 29, 2012, at 10:56 AM, Paul Sandoz 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
On 28/08/2012 05:57, Joe Wang wrote:
:
In DocumentBuilderFactory and SAXParserFactory the javadoc reads "
Otherwise the default implementation is returned if it is on the
classpath or installed as a module". I think this statement needs to
be re-worked, first to remove the word "module" as
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
On 8/28/2012 1:19 AM, Paul Sandoz wrote:
Hi Joe,
On Aug 28, 2012, at 7:35 AM, Joe Wang wrote:
--
datatype/FactoryFinder.java:
244 } catch (ServiceConfigurationError e) {
245 throw new DatatypeConfigurationException(e.getMessage(),
e.getCause());
You are munging th
Hi Joe,
On Aug 28, 2012, at 7:35 AM, Joe Wang wrote:
>>
>> --
>>
>> datatype/FactoryFinder.java:
>>
>> 244 } catch (ServiceConfigurationError e) {
>> 245 throw new DatatypeConfigurationException(e.getMessage(),
>> e.getCause());
>>
>> You are munging the message of the
On 8/27/2012 6:19 AM, Paul Sandoz wrote:
Hi Joe,
This is starting to look cleaner.
Yeah, if Alan hasn't asked, I'd sooner keep them as they were :) JAXP
is old, I never fancied getting those formats corrected. But I can't do
this much to classes I'd update, but probably not to the impl c
On 8/27/2012 6:19 AM, Alan Bateman wrote:
On 24/08/2012 17:52, Joe Wang wrote:
Hi,
Here is a modified patch:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
The factory finders contain some format changes, a NetBeans format
work. The real changes are as the follows:
1) In factory
Hi Joe,
This is starting to look cleaner.
--
datatype/FactoryFinder.java:
244 } catch (ServiceConfigurationError e) {
245 throw new DatatypeConfigurationException(e.getMessage(),
e.getCause());
You are munging the message of the exception and it's cause. Perhaps it would
On 24/08/2012 17:52, Joe Wang wrote:
Hi,
Here is a modified patch:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
The factory finders contain some format changes, a NetBeans format
work. The real changes are as the follows:
1) In factory classes: reinstated the implementation reso
Hi,
Here is a modified patch:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
The factory finders contain some format changes, a NetBeans format work.
The real changes are as the follows:
1) In factory classes: reinstated the implementation resolution
mechanism, the 3rd step mainly
Hi Paul, Alan,
I'm back on this change.
On 6/25/2012 12:19 PM, Joe Wang wrote:
On 6/25/2012 9:34 AM, Paul Sandoz wrote:
H Joe,
I just focused on javax.xml.datatype and assumed the rest follows the
same pattern :-)
Yeah, they are mostly similar, except Schema and XPath that do a
little e
On 6/25/2012 9:34 AM, Paul Sandoz wrote:
H Joe,
I just focused on javax.xml.datatype and assumed the rest follows the same
pattern :-)
Yeah, they are mostly similar, except Schema and XPath that do a little
extra check.
Like Alan i am still not sure about swallowing the ServiceConfigur
On 25/06/2012 18:03, Joe Wang wrote:
:
I'm not sure about catching and ignoring the
ServiceConfigurationError (or "keep on trucking" as Paul termed it in
one of the replies). The existing specification reads " Any Exception
thrown during the instantiation process is wrapped as a
Configura
On Jun 25, 2012, at 9:38 AM, Joe Wang wrote:
> New webrev:
> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
>
In javax.xml.datatype.DatatypeFactory:
245 if
(provider.getClass().getName().contains(fallbackClassName)) {
Strictly speaking the above should be
"provider.get
On 6/25/2012 5:14 AM, Alan Bateman wrote:
On 25/06/2012 08:38, Joe Wang wrote:
Hi all,
Thanks for all the comments!
I've updated the patch for the following recommended changes:
1. ServiceConfigurationError instead of ConfigurationError
2. Use factory class, class.forName section removed
3.
H Joe,
I just focused on javax.xml.datatype and assumed the rest follows the same
pattern :-)
Like Alan i am still not sure about swallowing the ServiceConfigurationError.
It enables something that did not work before so i guess it does not take
anything away, if choose that this should be par
On 25/06/2012 08:38, Joe Wang wrote:
Hi all,
Thanks for all the comments!
I've updated the patch for the following recommended changes:
1. ServiceConfigurationError instead of ConfigurationError
2. Use factory class, class.forName section removed
3. Use load method without specifying classloade
Hi all,
Thanks for all the comments!
I've updated the patch for the following recommended changes:
1. ServiceConfigurationError instead of ConfigurationError
2. Use factory class, class.forName section removed
3. Use load method without specifying classloader
4. To be clear on how the process ha
On 6/22/2012 2:39 AM, Alan Bateman wrote:
On 21/06/2012 22:53, Joe Wang wrote:
:
We're not considering this change for jdk7 or older, i.e. I haven't
thought about fixing 6975142. For jdk8, it seems we have to live
with the way it is in (2), a seemly incompatible behavior in backward
compa
On 21/06/2012 22:53, Joe Wang wrote:
:
We're not considering this change for jdk7 or older, i.e. I haven't
thought about fixing 6975142. For jdk8, it seems we have to live with
the way it is in (2), a seemly incompatible behavior in backward
compatible mode, although, it is a very rare case
On Jun 21, 2012, at 8:02 PM, Joe Wang wrote:
>
>>
>> On the implementation changes then I agree with Paul's comment that there is
>> a lot of duplication. I realize you have inherited some technical debt but
>> now seems a good opportunity to clean this up instead of changing
>> essentially th
On 6/21/2012 2:00 PM, Alan Bateman wrote:
On 21/06/2012 19:02, Joe Wang wrote:
:
For the class loader, as discussed with Paul, since the ServiceLoader
does so much, we may be able to skip the 'using different
classloader' part, that is, simply calling load without classloader.
The javado
On 6/21/2012 11:04 AM, Alan Bateman wrote:
On 21/06/2012 18:34, Joe Wang wrote:
:
When iterating over the service instances you are catching
ConfigurationError
264 ServiceLoader loader =
ServiceLoader.load(serviceClass, cl);
265 final Iterator providers = loader.ite
On 21/06/2012 19:02, Joe Wang wrote:
:
For the class loader, as discussed with Paul, since the ServiceLoader
does so much, we may be able to skip the 'using different classloader'
part, that is, simply calling load without classloader. The javadoc
states that it's equivalent to load with co
On 21/06/2012 18:34, Joe Wang wrote:
:
When iterating over the service instances you are catching
ConfigurationError
264 ServiceLoader loader = ServiceLoader.load(serviceClass,
cl);
265 final Iterator providers = loader.iterator();
266 while (providers.hasNex
On 6/21/2012 5:44 AM, Alan Bateman wrote:
On 21/06/2012 08:55, Joe Wang wrote:
:
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
It's great to get this work started.
The javadoc changes look okay to me and fine for this change. However
there are a few areas that could be made
On 6/21/2012 2:35 AM, Paul Sandoz wrote:
Hi Joe,
It looks a good start.
Thanks for the detailed review!
There is duplication in the 6 factory finding classes, can some of it
be consolidated in one shared factory helper class?
The duplication of FactoryFinder and SecuritySupport classes
On Jun 21, 2012, at 2:44 PM, Alan Bateman wrote:
> On 21/06/2012 08:55, Joe Wang wrote:
>> :
>> webrev:
>> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
> It's great to get this work started.
>
> The javadoc changes look okay to me and fine for this change. However there
> are a few ar
On 21/06/2012 08:55, Joe Wang wrote:
:
webrev:
http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/
It's great to get this work started.
The javadoc changes look okay to me and fine for this change. However
there are a few areas that could be made clearer, like specifying the
behavior for t
Hi Joe,
It looks a good start.
There is duplication in the 6 factory finding classes, can some of it be
consolidated in one shared factory helper class?
Taking javax.xml.datatyoe.FactoryFinder as an example:
When iterating over the service instances you are catching ConfigurationError
264
jaxp tck passed.
Joe
On 6/21/2012 12:55 AM, Joe Wang wrote:
Hi,
This is a patch to replace the manual process in the 3rd step of the
JAXP implementation resolution mechanism with ServiceLoader. Please
see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for
more details about the
Hi,
This is a patch to replace the manual process in the 3rd step of the
JAXP implementation resolution mechanism with ServiceLoader. Please see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for more
details about the issue.
Note that FactoryFinder is duplicated for each JAXP s
46 matches
Mail list logo