On 9/10/14 1:25 PM, Alan Bateman wrote:
On 10/09/2014 10:49, Daniel Fuchs wrote:
Hi,
Please find below a proposed patch for
8043306 - Provide a replacement for the API that allowed to listen
for LogManager configuration changes
https://bugs.openjdk.java.net/browse/JDK-8043306
Hi Stanimir,
On 9/12/14 9:47 AM, Stanimir Simeonoff wrote:
Hello,
Just a note, acc is going to leak the context class loader until the
listener is removed. That should be noted in the documentation.
Good point. But I expect the concrete listener class will also be
usually loaded by the
Hi Peter,
On 9/12/14 8:26 AM, Peter Levart wrote:
Oh yes. I put it there just to avoid it being flagged by
NetBeans:
'equals() method not checking type of its parameters'
I guess it would be better to just return this == other;
(which unfortunately doesn't remove the warning)
What about
Thanks Stanimir,
On 9/12/14 11:24 AM, Stanimir Simeonoff wrote:
On leaks. The c-tor of LogManager leaks the thread group and the current
AccessControlContext till JVM shutdown. The constructor code should be
something like the one below with Cleaner getting ThreadGroup in its
c-tor as well.
On 9/12/14 1:55 PM, Peter Levart wrote:
On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
However the listeners are to be invoked in the same order they have been
added.
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were
On 9/12/14 2:37 PM, Alan Bateman wrote:
On 12/09/2014 11:45, Daniel Fuchs wrote:
I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were using HashMap to store listeners,
and therefore the order in which listeners were
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
On 9/12/14 3:54 PM, Alan Bateman wrote:
On 12/09/2014 14:38, Daniel Fuchs wrote:
Would modifying the specification of addConfigurationListener()
as follows
-libs-dev@openjdk.java.net
On 9/12/14 4:42 PM, Alan Bateman wrote:
On 12/09/2014 15:16, Daniel Fuchs wrote:
Thanks Alan!
I have updated the webrev with your suggestions:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
-- daniel
A minor suggestion for readConfiguration is that Any
On 9/16/14 1:12 PM, Pavel Rappo wrote:
Hi everyone,
Could you please review my change for JDK-8044627?
http://cr.openjdk.java.net/~prappo/8044627/webrev.00/
-Pavel
Hi Pavel,
Given that helper.loadClass uses the context class loader,
Should you also simply use
Done.
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06
On 9/16/14 3:56 PM, Alan Bateman wrote:
On 15/09/2014 17:03, Daniel Fuchs wrote:
:
Here is a new webrev - with updated test case:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
I think this quite good now
On 9/16/14 4:14 PM, Pavel Rappo wrote:
Daniel,
Given that helper.loadClass uses the context class loader,
Should you also simply use
ServiceLoaderInitialContextFactory loader =
ServiceLoader.load(InitialContextFactory.class);
at lines 680-681 ?
It needs to be the
Hi,
Please find below a patch for [1]
8059269: FileHandler may throw NPE if pattern is a simple name and
the lock file already exists
[1] https://bugs.openjdk.java.net/browse/JDK-8059269
The webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.00
This is a
On 29/09/14 05:01, Alan Bateman wrote:
On 26/09/2014 19:33, Daniel Fuchs wrote:
Hi,
Please find below a patch for [1]
8059269: FileHandler may throw NPE if pattern is a simple name and
the lock file already exists
[1] https://bugs.openjdk.java.net/browse/JDK-8059269
The webrev
On 29/09/14 13:42, Alan Bateman wrote:
On 29/09/2014 09:51, Daniel Fuchs wrote:
The files created by the test (both log files and lock files) will be
removed by the finally block at lines 150 - 174 - so the test shouldn't
leave any files open (which I verified by running the test on a JDK
On 29/09/14 15:12, Alan Bateman wrote:
On 29/09/2014 13:53, Daniel Fuchs wrote:
- 233 FileChannel.open(Paths.get(file + .lck), CREATE_NEW, WRITE);
- 234 FileChannel.open(Paths.get(file + .1.lck), CREATE_NEW, WRITE);
+ 233 FileChannel.open(Paths.get(file + .lck), CREATE_NEW, WRITE
Hi,
Please find below a fix for
8025690: Default FileHandler constructor doesn't
throw NullPointerException if pattern is empty and count 1
https://bugs.openjdk.java.net/browse/JDK-8025690
The default constructor of FileHandler is specified to throw
a NullPointerException if the
, at 10:04 AM, Daniel Fuchs daniel.fu...@oracle.com
mailto:daniel.fu...@oracle.com wrote:
Hi,
Please find below a fix for
8025690: Default FileHandler constructor doesn't
throw NullPointerException if pattern is empty and count 1
https://bugs.openjdk.java.net/browse/JDK-8025690
Hi Lance,
On 30/09/14 23:55, Lance Andersen wrote:
On Sep 30, 2014, at 5:20 PM, Daniel Fuchs daniel.fu...@oracle.com
mailto:daniel.fu...@oracle.com wrote:
On 9/30/14 9:09 PM, Lance Andersen wrote:
Shouldn't the other constructors indicate that an NPE will occur
similar to the default
Hi Lance,
I probably don't know enough about rowset to qualify as reviewer
for this change, but I had a look at the tests - and I believe
they look good.
I wonder whether there should be some additional tests that would
run with a security manager on?
The only thing unusual I noticed is that
Hi,
On 19/08/14 16:00, Jason Mehrens wrote:
Stanimir,
Looks like the int overflow on the metered stream is an issue that hasn't been
tracked. The other issues have been reported under
https://bugs.openjdk.java.net/browse/JDK-6433253
and https://bugs.openjdk.java.net/browse/JDK-8028786
Hi,
Please find below a trivial fix for
8028788: Logger.enterring uses String concatenation in a loop
https://bugs.openjdk.java.net/browse/JDK-8028788
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8028788/webrev.00
best regards
-- daniel
Best
Lance
On 7 Oct 2014, at 11:59, Daniel Fuchs daniel.fu...@oracle.com
mailto:daniel.fu...@oracle.com wrote:
Hi,
Please find below a trivial fix for
8028788: Logger.enterring uses String concatenation in a loop
https://bugs.openjdk.java.net/browse/JDK-8028788
webrev:
http://cr.openjdk.java.net
On 07/10/14 21:50, Jason Mehrens wrote:
Hi Daniel,
The only thing I noticed is a missing @since tag on the FileHandler.
Oops, thanks for catching that Jason.
-- daniel
Jason
Date: Tue, 7 Oct 2014 15:13:13 +0200
From: daniel.fu...@oracle.com
To:
17:13, Daniel Fuchs wrote:
Hi,
Please find below a patch for:
8059767: FileHandler should allow 'long' limits and handle overflow
of MeteredStream.written.
https://bugs.openjdk.java.net/browse/JDK-8059767
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8059767/webrev.00
Hi Konstantin,
I'm not qualified as a (R)eviewer for changes in this area,
but I believe you can do:
HotSpotDiagnosticMXBean mbean =
ManagementFactory.getPlatformMXBean(HotSpotDiagnosticMXBean.class);
to get a handle on the MBean. You don't need to go through
the MBeanServer and
Hi,
Please find below a fix for:
8042147: test sun/util/logging/SourceClassName.java failed:
Unexpected source: java.util.Currency info
https://bugs.openjdk.java.net/browse/JDK-8042147
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8042147/webrev.00/
It seems that something
Thanks Jason.
I wonder if that may be another issue. Interesting. I'll see if I can
work out a test case
for that tomorrow. With the test case provided in the bug - tested on 7,
8, and 9,
the only file that remained at the end was 'log' (which is as it should
be - and I ran
the test case
,
-- daniel
Stanimir
On Thu, Oct 9, 2014 at 4:59 PM, Daniel Fuchs daniel.fu...@oracle.com
mailto:daniel.fu...@oracle.com wrote:
Thanks Jason.
I wonder if that may be another issue. Interesting. I'll see if I
can work out a test case
for that tomorrow. With the test case provided
, though (ext3 [concurrently] deleting large files
for example).
Stanimir
On Thu, Oct 9, 2014 at 4:59 PM, Daniel Fuchs daniel.fu...@oracle.com
mailto:daniel.fu...@oracle.com wrote:
Thanks Jason.
I wonder if that may be another issue. Interesting. I'll see if I
can work out a test
a strong
reference on the loggers for which a Handler is explicitly
configured in the configuration file. It would ensure that
these loggers are still around when reset() is called.
best regards,
-- daniel
Stanimir
On Thu, Oct 9, 2014 at 4:59 PM, Daniel Fuchs daniel.fu...@oracle.com
On 10/10/14 16:36, Stanimir Simeonoff wrote:
The Handler automatic closure remains problematic as they don't have a
defined lifecycle. close() should be invoked after there are no
references and it requires calling a potentially overridden method. It
can be carried by
Hi,
Please find below a possible fix for:
8060132: Handlers configured on abstract nodes in logging.properties are
not always properly closed
https://bugs.openjdk.java.net/browse/JDK-8060132
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.00/
Other options have been
time to get it straight).
Agreed.
http://cr.openjdk.java.net/~dfuchs/webrev_8060132/webrev.01
best regards, and thanks for all the valuable inputs comment from
you and Jason - I really appreciate it :-)
-- daniel
Cheers
Stanimir
On Fri, Oct 10, 2014 at 5:51 PM, Daniel Fuchs daniel.fu
/webrev_8059767/webrev.02
I also logged JDK-8060457 to follow up and cleanup that in
all handlers subclasses (no impact on the actual
implementation / behavior - it's just cleanup).
Attempting the cleanup in this fix was just too much noise.
best regards,
-- daniel
On 08/10/14 11:46, Daniel Fuchs
alan.bate...@oracle.com wrote:
On 14/10/2014 14:34, Daniel Fuchs wrote:
Hi Pavel,
I saw your mail on build-dev.
I guess the issue will resolve itself once we have the
modular image.
I wonder whether the way to go for now would be
to add a single META-INF/services file - as you suggest
Changeset: 9e013ce42dd7
Author:dfuchs
Date: 2012-11-07 13:24 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e013ce42dd7
6720349: (ch) Channels tests depending on hosts inside Sun
Summary: This changeset make the nio tests start small TCP or UDP servers from
within the
Changeset: 3b6a2fe6d75c
Author:dfuchs
Date: 2012-11-28 15:14 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b6a2fe6d75c
8003476: Cleanup warnings in com.sun.jmx.snmp code
Reviewed-by: alanb, smarks
! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java
!
Hi,
This is a first webrev in a series that addresses a change intended
for JDK 8:
7169894: JAXP Plugability Layer: using service loader
I've been building up on Joe's work and Paul Alan comments
from an earlier discussion thread [1]
This here addresses changes in the javax.xml.parsers
On 12/4/12 3:42 PM, Daniel Fuchs wrote:
In the class descriptions it suggests that the default implementation
may be installed as a module but we aren't there yet so I'm not sure
about using the term module. I think it should be okay to say
installed as an extension as ServiceLoader uses
On 12/5/12 3:45 PM, Alan Bateman wrote:
On 04/12/2012 15:55, Daniel Fuchs wrote:
So that would be the wording:
* Uses the service-provider loading facilities, defined by the
* {@link java.util.ServiceLoader} class, to attempt to locate
* and load an implementation
for( : ) syntax in findServiceProvider
* improved // comments explaining why the additional layer of
RuntimeException is needed when wrapping ServiceConfigurationError.
best regards,
-- daniel
On 12/4/12 2:54 PM, Alan Bateman wrote:
On 03/12/2012 19:04, Daniel Fuchs wrote:
Hi,
This is a first webrev
,
-- daniel
Mandy
On 12/5/2012 8:17 AM, Daniel Fuchs wrote:
Hi,
Please find below a revised version of the changes for
the javax.xml.parsers package.
It hopefully incorporates all comments I have received so far.
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.01/
* better
Updated the javadoc for newInstance():
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.02/
-- daniel
On 12/6/12 11:04 AM, Alan Bateman wrote:
On 05/12/2012 16:17, Daniel Fuchs wrote:
Hi,
Please find below a revised version of the changes for
the javax.xml.parsers
here is a new - and hopefully simpler webrev:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.04/
best regards,
-- daniel
On 12/7/12 7:37 PM, Mandy Chung wrote:
On 12/7/12 8:32 AM, Alan Bateman wrote:
On 07/12/2012 15:15, Daniel Fuchs wrote:
Hi Alan,
I have updated
On 12/11/12 2:01 PM, Alan Bateman wrote:
On 10/12/2012 17:12, Daniel Fuchs wrote:
[...]
So here is a new - and hopefully simpler webrev:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.04/
best regards,
-- daniel
This looks fine to me, just a stray p/p at L64
/javax.xml.datatype/webrev.01
-- daniel
Note: I have applied the same cleanup to the parsers package:
javax.xml.parsers:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.05/
On 12/11/12 6:47 PM, Daniel Fuchs wrote:
Hi,
Here is a new webrev in the series that addresses using
/JDK-7169894/javax.xml.datatype/webrev.02
I also reported the changes to javax.xml.parsers:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.06/
-- daniel
On 12/12/12 2:08 PM, Daniel Fuchs wrote:
Hi,
Please find below a refreshed webrev which adds a bit of cleanup
Hi,
Here is a new webrev in the series that addresses using ServiceLoader in
JAXP for JDK 8.
7169894: JAXP Plugability Layer: using service loader
This changeset addresses modification in the javax.xml.stream
package.
It is similar to changes proposed for the javax.xml.parsers
package [1],
Hi,
Thanks for the review.
I updated the webrev to keep track of your suggested change.
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.01/
-- daniel
On 12/18/12 4:00 PM, Alan Bateman wrote:
I looked through this installment and aside from an aside from an
alignment
Hi,
Here is a new webrev in the series that addresses using ServiceLoader in
JAXP for JDK 8.
7169894: JAXP Plugability Layer: using service loader
This changeset addresses modification in the javax.xml.transform
package.
It is similar to changes proposed for the javax.xml.parsers
package [1],
On 12/18/2012 8:39 AM, Daniel Fuchs wrote:
Hi,
Thanks for the review.
I updated the webrev to keep track of your suggested change.
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.01/
-- daniel
On 12/18/12 4:00 PM, Alan Bateman wrote:
I looked through this installment
On 12/18/12 9:06 PM, Mandy Chung wrote:
In FactoryFinder.newInstanceNoServiceLoader method, L223, 226 -
NoSuchMethodException will be thrown if such method doesn't exist.
creationMethod will not be null.
Thanks - yes - you're right of course - no need to check for null...
L236 - this change
that?
Yes sorry about that - it's my mistake. I had wrapped that call in a
previous version then decided to revert
to the original code but I obviously did it too fast!
Thanks for catching it - the tests didn't!
-- daniel
-Joe
On 12/18/2012 8:42 AM, Daniel Fuchs wrote:
Hi,
Here is a new webrev
On 12/19/12 12:10 AM, Joe Wang wrote:
It's different. If 'foo.bar' is specified but not found, it indicates
a configuration error. If the factory falls back to an impl by the
default factory id, it would serve to hide the error.
Yes - I fully agree with that.
Note that newInstance/newFactory
On 12/27/12 12:06 AM, Joe Wang wrote:
Hi,
This is a patch to clean up compiling warnings in jaxp.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473
Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/
Thanks,
Joe
Hi Joe,
In FactoryFinder.java - line 213,
am sorely
tempted to recommend that we do 3. and clarify
the spec on this point.
(3: Only call ServiceLoader.load(type) when the provided
factoryId is equal to type.getName())
Best regards,
-- daniel
On 12/19/12 10:45 AM, Daniel Fuchs wrote:
On 12/19/12 12:10 AM, Joe Wang wrote:
It's different
to be the same as a property name is that the author
basically was saying that it's equivalent to a name as in a property,
not the value, therefore different from the DOM/SAX API -- a bad
choice I would think.
Thanks,
Joe
On 1/4/2013 6:31 AM, Daniel Fuchs wrote:
Hi guys,
Happy new year to you all
,
-- daniel
On 1/7/2013 2:34 AM, Daniel Fuchs wrote:
Thanks Joe.
To make things clear I have pushed a revised webrev with solution 3.
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.02.3/
The lines of interest are in FactoryFinder.java - right hand side:
267
Hi,
Here is a new webrev in the series that addresses using ServiceLoader in
JAXP for JDK 8.
7169894: JAXP Plugability Layer: using service loader
This changeset addresses modification in the javax.xml.validation
package.
It is a bit more complex than the changes required for the other
Thanks for the comments Alan!
I have implemented them and refreshed the webrev for the record:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.04/
-- daniel
On 1/9/13 4:43 PM, Alan Bateman wrote:
On 08/01/2013 12:20, Daniel Fuchs wrote:
:
I've clarified the spec. I
Hi Mandy,
Please find clarifications in line:
On 1/9/13 9:30 PM, Mandy Chung wrote:
On 1/9/2013 9:26 AM, Daniel Fuchs wrote:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.04/
Daniel - thanks for updating the spec for the newFactory(String,
ClassLoader) method
On 1/9/13 9:30 PM, Mandy Chung wrote:
L152: would it be better to replace the base service class name with
the classname (i.e. javax.xml.XMLEventFactory)
152* If {@code factoryId} is the base service class name,
153* use the service-provider loading facilities, defined by the
Hi,
Here is a new webrev in the series that addresses using ServiceLoader in
JAXP for JDK 8.
7169894: JAXP Plugability Layer: using service loader
This changeset addresses modification in the javax.xml.xpath
package.
This changes are very similar to the changes proposed for
the
Thanks Mandy! Good catch!
I've updated the webrev:
http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.06/
-- daniel
On 1/11/13 6:23 PM, Mandy Chung wrote:
On 1/11/2013 5:59 AM, Daniel Fuchs wrote:
Hi Mandy,
This is done. I have updated the webrev:
http
On 1/11/13 8:05 PM, Joe Wang wrote:
I don't have any data on how much the service mechanism may be used,
Xerces would surely be the one most frequently used. I'm more concerned
with the spec change that would require TCK change (the addition of
SchemaFactoryConfigurationError related tests).
On 2/19/13 11:27 AM, Weijun Wang wrote:
Hi All
I'm using LinkedList to maintain a history and the elements are ordered
by their timestamps. Every now and then I would expunge the list, that
is to say, iterating through the list and when an element is old enough
all elements after (and
Hi guys,
I'd like to propose a small change to jaxp/build.xml and
jaxp/nbproject/project.xml - in order to allow editing
JAXP sources in NetBeans, as well as generating the JAXP
javadoc for previewing purposes.
I actually stole the javadoc target from
jdk/make/netbeans/common/shared.xml
The
filename name=javax//
207
208
209 filename name=org/w3c//
210 filename name=org/xml/sax//
211 /or
-- daniel
Regards,
Joe
On 3/25/2013 4:45 AM, Daniel Fuchs wrote:
Hi guys,
I'd like to propose a small change to jaxp/build.xml
Hi Joe,
On 3/25/13 5:52 PM, huizhe wang wrote:
On 3/25/2013 9:35 AM, Daniel Fuchs wrote:
On 3/25/13 5:20 PM, huizhe wang wrote:
Hi Daniel,
Thanks for doing this.
JAXP doesn't have these packages: java/, org/ietf/jgss/, and
org/omg/. Since this is the jaxp repo, it would be fine if only
in the editor.
I have also restrained the packageset for the javadoc
target as suggested by Joe.
-- daniel
On 3/25/13 12:45 PM, Daniel Fuchs wrote:
Hi guys,
I'd like to propose a small change to jaxp/build.xml and
jaxp/nbproject/project.xml - in order to allow editing
JAXP sources in NetBeans, as well
Hi,
This a fix for:
JDK-8008738 - Issue in
com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK
tests to fail intermittently.
http://cr.openjdk.java.net/~dfuchs/JDK-8008738/webrev.02/
The issue here is that com.sun.org.apache.xml.internal.serializer.Encodings
tries to
Changeset: b95c5c8ee60a
Author:jgish
Date: 2013-04-16 13:25 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/rev/b95c5c8ee60a
8011347: JKD-8009824 has broken webrev with some ksh versions
Reviewed-by: mduigou
! make/scripts/webrev.ksh
Hi,
These changes correspond to the changes that have been already reviewed
under the umbrella name of JDK-7169894 (which was closed cloned into
JDK-8005954 for administrative reasons) - re-based on the latest jdk8-tl
forest tip.
So this is basically JDK-7169894, re-based merged at the tip -
On 4/17/13 6:30 PM, Alan Bateman wrote:
On 17/04/2013 16:41, Daniel Fuchs wrote:
Hi,
These changes correspond to the changes that have been already reviewed
under the umbrella name of JDK-7169894 (which was closed cloned into
JDK-8005954 for administrative reasons) - re-based on the latest
Changeset: fad6560cb32a
Author:dfuchs
Date: 2013-04-17 15:23 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fad6560cb32a
8005954: JAXP Plugability Layer should use java.util.ServiceLoader
Summary: This fix replaces manual processing of files under META-INF/services
in JAXP
Changeset: 1c2079d11a79
Author:dfuchs
Date: 2013-04-19 17:22 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/1c2079d11a79
8010495: Update JAXP NetBeans project - add support for generating javadoc
Summary: Make it possible to use NetBeans to edit the jaxp sources and to
clauses.
changes in test Makefile have been removed: I rebased my patch on
jdk8 tip, which already has these test Makefile changes.
best regards,
-- daniel
On 4/30/13 11:18 AM, Alan Bateman wrote:
On 15/04/2013 15:09, Daniel Fuchs wrote:
Hi,
This a fix for:
JDK-8008738 - Issue
Hi Joe,
I am not a JAXP expert - so I've been discovering most
of this code as I read it. It would be impossible for me
to assess whether there's some setFeature or setProperty
missing somewhere for instance. So with my limited
knowledge I have only these few remarks:
==
1.
Hi,
On 5/3/13 8:02 PM, Mandy Chung wrote:
2. Investigate what DiagnosticCommandImpl.getAttributes and
setAttributes should do per DynamicMBean spec. The current
implementation throws UOE which seem to be okay. It's good to confirm
what is specified or not specified per DynamicMBean spec
By
Changeset: 2602eab5f086
Author:dfuchs
Date: 2013-05-07 11:35 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2602eab5f086
8008738: Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes
some JCK tests to fail intermittently
Summary: Encodings.java sometimes
This is a fix for JDK-8013900: More warnings compiling jaxp.
http://cr.openjdk.java.net/~dfuchs/JDK-8013900/webrev.00/
Although the title might suggest a trivial fix, it goes a bit
beyond a simple warning fix because the root cause of those warnings
is that some classes redefine equals without
, and to
make the index in LocalVariableGen final - since it was
never changed after the instance construction (and takes
part in the HashCode computation).
best regards,
-- daniel
previous version:
[1] http://cr.openjdk.java.net/~dfuchs/JDK-8013900/webrev.00/
On 5/13/13 4:36 PM, Daniel Fuchs wrote
Changeset: da203779cb33
Author:jgish
Date: 2013-05-16 11:19 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da203779cb33
8013380: Removal of stack walk to find resource bundle breaks Glassfish startup
Summary: Use caller's classloader to load resource as an alternative to
Done
-- daniel
On 5/16/13 5:20 PM, Jim Gish wrote:
Thanks.
Daniel -- could you please push
http://cr.openjdk.java.net/~jgish/TestRB.7.2/
http://cr.openjdk.java.net/%7Ejgish/TestRB.7.2/ ?
Jim
On 05/16/2013 08:13 AM, Alan Bateman wrote:
On 16/05/2013 03:46, Mandy Chung wrote:
On 5/15/2013
Changeset: 68209420aac2
Author:dfuchs
Date: 2013-05-17 10:40 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68209420aac2
8013900: More warnings compiling jaxp.
Summary: Some internal implementation classes in Jaxp were redefining equals()
without redefining hashCode(). This
Changeset: 6443f5627744
Author:dfuchs
Date: 2013-05-17 10:40 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6443f5627744
8013900: More warnings compiling jaxp.
Summary: Some internal implementation classes in Jaxp were redefining equals()
without redefining hashCode().
Hi,
This is a request for review to backport the changes for:
https://jbs.oracle.com/bugs/browse/JDK-8008738
to jdk7u-dev.
The changeset for jdk7u-dev only slightly differs from that
for jdk 8, on these two counts:
1. JAXP needs to be compiled with the bootstrap JDK - which
means that JAXP
Hi,
This is a request for review of the backport of
https://jbs.oracle.com/bugs/browse/JDK-8013900
to jdk7u-dev.
The changeset for jdk7u-dev [1] had to be altered on one count
compared to the changes pushed in jdk8 [2]:
Since jaxp needs to be compiled using the bootstrap
compiler, it was not
Hi,
In order to prepare for modularization, we need to review all
the places where META-INF/services is parsed directly.
The Xalan and Xerces internal ObjectFactory still have some
places where such parsing is implemented.
The usual fix in such cases is to replace this 'ad-hoc' parsing
by calls
Changeset: e93beba07830
Author:dfuchs
Date: 2013-06-06 20:47 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/e93beba07830
8013434: Xalan and Xerces internal ObjectFactory need rework
Summary: With this changeset, DTMManager and XSLTCDTMManager will always use
their own
On 6/10/13 1:11 PM, Alan Bateman wrote:
The warnings from the build of the corba repository on missing hashCode
methods have been annoying me for some time. I was hoping they would
annoy others too but looks like I blinked first :-)
Here's the webrev with the changes that I'd like to push to
On 6/10/13 9:04 PM, Mike Duigou wrote:
StubDelegateImpl.java::
- Could just call Objects.hashCode(ior);
RepIdDelegator::
- Could also call Objects.hashCode(delegate) as it extends nothing the
super.equals(delegate) is calling Object.equals
Depends on whether you intend to backport the patch
Hi Joe,
Looks good.
I wonder whether using java.util.logging would be more (or less)
appropriate than
System.err.println()?
best regards,
-- daniel
On 6/10/13 9:26 PM, huizhe wang wrote:
Thanks Lance!
As Daniel noted, I added warnings to these additional property
settings, but there are
Hi,
Please find below an attempt at fixing
test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
This is an intermittent failure which I haven't managed to reproduce,
so I am reduced to figure out what could have gone wrong by analyzing
the code.
AFAICT the NPE is thrown when
.
best regards,
-- daniel
Mandy
On 6/13/2013 6:47 AM, Daniel Fuchs wrote:
Hi,
Please find below an attempt at fixing
test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
This is an intermittent failure which I haven't managed to reproduce,
so I am reduced to figure out what
Hi Joe,
Looks good to me. Not a reviewer - as you know ;-)
-- daniel
On 6/11/13 5:36 AM, huizhe wang wrote:
Hi,
This is a quick fix on a regression caused by a previous patch. The
XMLReaderFactory uses a class variable (_jarread) to indicate if service
file has already been read. Along with
Hi,
Please find below a webrev for fixing
8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
intermittently
http://cr.openjdk.java.net/~dfuchs/JDK-8014218/webrev.00/
Without the fix - it's quite easy to make the test fail - especially
if you copy paste the @run line a few
On 6/17/13 4:22 PM, Chris Hegarty wrote:
On 17/06/2013 14:21, Daniel Fuchs wrote:
Hi,
Please find below a webrev for fixing
8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
intermittently
http://cr.openjdk.java.net/~dfuchs/JDK-8014218/webrev.00/
Without the fix - it's quite
detect JDK-8016304
too and throw an exception pointing at 8016304 if the thread ids
returned by findDeadlockedThread do not seem to indicate a deadlock.
-- daniel
Thanks
Mandy
[1]
http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010194.html
On 6/17/2013 6:21 AM, Daniel
On 6/19/13 11:00 AM, Daniel Fuchs wrote:
On 6/13/13 10:05 PM, Mandy Chung wrote:
Daniel,
I wonder what the list of logger names (loggers1 and loggers2) returned
by LoggingMXBean contains and that may include loggers in the running VM
other than the ones created and kept a strong reference
101 - 200 of 1534 matches
Mail list logo
