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
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 Aug 30, 2012, at 11:20 PM, Alan Bateman alan.bate...@oracle.com 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
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.
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
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)
Hi Joe,
On Aug 30, 2012, at 1:08 AM, Joe Wang huizhe.w...@oracle.com 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.
On Aug 30, 2012, at 1:33 AM, Joe Wang huizhe.w...@oracle.com 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
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 8:59 AM, Joe Wang huizhe.w...@oracle.com 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
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
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
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 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
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
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
Hi Joe,
On Aug 28, 2012, at 7:35 AM, Joe Wang huizhe.w...@oracle.com wrote:
--
datatype/FactoryFinder.java:
244 } catch (ServiceConfigurationError e) {
245 throw new DatatypeConfigurationException(e.getMessage(),
e.getCause());
You are munging the message of
On 8/28/2012 1:19 AM, Paul Sandoz wrote:
Hi Joe,
On Aug 28, 2012, at 7:35 AM, Joe Wanghuizhe.w...@oracle.com wrote:
--
datatype/FactoryFinder.java:
244 } catch (ServiceConfigurationError e) {
245 throw new DatatypeConfigurationException(e.getMessage(),
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
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
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
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
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
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
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
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
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.
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
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
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 the same
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
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
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
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
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
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 areas that
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
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
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
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
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 =
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
43 matches
Mail list logo
