[9] RFR: 8149923 invalid javadoc in javax.xml.bind.JAXBContext (introduced by 8138699)

[Miroslav Kos]

Hi Lance,
could you review this minor patch? It is just minor overlook I didn't 
catch while doing 8138699.


Filed a new JBS issue: https://bugs.openjdk.java.net/browse/JDK-8149923
webrev: http://cr.openjdk.java.net/~mkos/8149923/jaxws.01/

Thanks
Miran

Re: RFR [9] 8148861: Remove sun.misc.ManagedLocalsThread from jaxws

[Miroslav Kos]

Looks ok to me, will take care of it in standalone project.

Thanks
Miran


On 08/02/16 17:20, Chris Hegarty wrote:

Receiving some feedback off list, this code needs to be able to run on
older releases, so the new Thread constructor, added in JDK 9, should
be accessed reflectively. Webrev updated in-place:

  http://cr.openjdk.java.net/~chegar/8148861/

-Chris.

On 8 Feb 2016, at 10:52, Chris Hegarty  wrote:


Miran,

JDK-8056152 added a new constructor to java.lang.Thread for constructing
Threads that do not inherit inheritable thread-local initial values. All usages
of sun.misc.ManagedLocalsThread in the base module were also replaced
with this new constructor. Given there is now a supported API for creating such
threads, other areas of the JDK should be updated to use it, where applicable.
If all usages are replaced, then sun.misc.ManagedLocalsThread can be removed.


The following patch, along with 'hg rm ThreadHelper.java', should be sufficient.
It will remove the dependency on an internal JDK API, but adds a new dependency
on Java SE 9. Is this OK, or does this code need to access the new Java SE 9
constructor using refection?

diff --git 
a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java 
b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java
--- a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java
+++ b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/pipe/Engine.java
@@ -108,7 +108,8 @@
 }

 public Thread newThread(Runnable r) {
-Thread t = ThreadHelper.createNewThread(r);
-t.setName(namePrefix + threadNumber.getAndIncrement());
+   Thread t = new Thread(null, r, namePrefix + 
threadNumber.getAndIncrement(), 0, false);
 t.setName(namePrefix + threadNumber.getAndIncrement());
 if (!t.isDaemon()) {
 t.setDaemon(true);

Complete webrev:
  http://cr.openjdk.java.net/~chegar/8148861/

Is is possible, when agreed, to get this small change pushed upstream ?

-Chris.

RFR [9]: 8138699 Iproving JAX-B javadoc

[Miroslav Kos]

Hi everybody,
please review following patch - those are changes to javadoc, previously 
consulted with sqe. The javadoc now is not always clear, which makes 
difficult to develop proper tests.


JIRA: https://bugs.openjdk.java.net/browse/JDK-8138699
webrev: http://cr.openjdk.java.net/~mkos/8138699/jaxws.01/

Thanks
Miran

Re: RFR [9]: 8145104: NPE is thrown when JAXBContextFactory implementation is specified in system property, 8145112: newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as

[Miroslav Kos]

Hi Lance,
this is the RFR Alan was mentioning.

Thanks a lot!
Miran


On 11/01/16 12:14, Miroslav Kos wrote:

Ping ... anybody?

On 22/12/15 14:44, Miroslav Kos wrote:

Hi everybody,
I'd like to ask for reviewing following patch. It fixes two issues:

JBS: https://bugs.openjdk.java.net/browse/JDK-8145104
NPE is thrown when JAXBContextFactory implementation is specified in 
system property


In short, it's a regression of recent changes in JAXB-AP. The old 
version of API is using static methods to create JAXBContext 
instance, where as the new configuration facility uses defined 
interface. The methods are called via core reflection, so when 
invoking non-static method of spi implemetation, instance of the spi 
must be created first. This fixes NPE which occured in certain 
scenarios.


JBS: https://bugs.openjdk.java.net/browse/JDK-8145112
newInstance(String, ClassLoader): java.lang.JAXBException should not 
be wrapped as expected according to spec


There are still some changes in javadoc being discussed, but anyway 
this double-wrapping exception into JAXBException doesn't make any 
sense. JAXBException thrown from JAXB spi provider is re-thrown as is.


Fix: http://cr.openjdk.java.net/~mkos/8145104/jaxws.01/
Tests: http://cr.openjdk.java.net/~mkos/8145104/jdk.02/

Added 2 new jtreg tests, the tests added also to standalone project.

Thanks
Miran

Re: RFR [9]: 8145104: NPE is thrown when JAXBContextFactory implementation is specified in system property, 8145112: newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as

[Miroslav Kos]

Ping again - would somebody find some time to review those, please?

Thanks
M.


On 11/01/16 12:14, Miroslav Kos wrote:

Ping ... anybody?

On 22/12/15 14:44, Miroslav Kos wrote:

Hi everybody,
I'd like to ask for reviewing following patch. It fixes two issues:

JBS: https://bugs.openjdk.java.net/browse/JDK-8145104
NPE is thrown when JAXBContextFactory implementation is specified in 
system property


In short, it's a regression of recent changes in JAXB-AP. The old 
version of API is using static methods to create JAXBContext 
instance, where as the new configuration facility uses defined 
interface. The methods are called via core reflection, so when 
invoking non-static method of spi implemetation, instance of the spi 
must be created first. This fixes NPE which occured in certain 
scenarios.


JBS: https://bugs.openjdk.java.net/browse/JDK-8145112
newInstance(String, ClassLoader): java.lang.JAXBException should not 
be wrapped as expected according to spec


There are still some changes in javadoc being discussed, but anyway 
this double-wrapping exception into JAXBException doesn't make any 
sense. JAXBException thrown from JAXB spi provider is re-thrown as is.


Fix: http://cr.openjdk.java.net/~mkos/8145104/jaxws.01/
Tests: http://cr.openjdk.java.net/~mkos/8145104/jdk.02/

Added 2 new jtreg tests, the tests added also to standalone project.

Thanks
Miran

Re: RFR [9]: 8146086 Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

[Miroslav Kos]

Hi Chris,
are you ok with the change?

Thanks
Miran


On 11/01/16 15:41, Miroslav Kos wrote:

Hi Chris,
good catch - thanks! Simple fix here: 
http://cr.openjdk.java.net/~mkos/8146086/jdk.01/


M.


On 11/01/16 12:20, Chris Hegarty wrote:

Miran,

On 11/01/16 11:12, Miroslav Kos wrote:

Ping ... anybody?

On 23/12/15 15:14, Miroslav Kos wrote:

Hi everybody,

I'd like to ask for review of . This simple patch allows
publishing more webeservices on same port. The fix has been submitted
by Kubota Yuji, it is already integrated in standalone JAX-WS repo,
regression test added.

JBS: https://bugs.openjdk.java.net/browse/JDK-8146086
jaxws patch: http://cr.openjdk.java.net/~mkos/8146086/jaxws.00/


The change ok.


test: http://cr.openjdk.java.net/~mkos/8146086/jdk.00/


The test uses a hardcoded port number. Is there a pattern in this
area for enable the test to start up on an ephemeral port, and use
that for the subsequent request?

-Chris.


Thanks
Miran

Re: RFR [9]: 8146086 Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

[Miroslav Kos]

Hi Chris,
good catch - thanks! Simple fix here: 
http://cr.openjdk.java.net/~mkos/8146086/jdk.01/


M.


On 11/01/16 12:20, Chris Hegarty wrote:

Miran,

On 11/01/16 11:12, Miroslav Kos wrote:

Ping ... anybody?

On 23/12/15 15:14, Miroslav Kos wrote:

Hi everybody,

I'd like to ask for review of . This simple patch allows
publishing more webeservices on same port. The fix has been submitted
by Kubota Yuji, it is already integrated in standalone JAX-WS repo,
regression test added.

JBS: https://bugs.openjdk.java.net/browse/JDK-8146086
jaxws patch: http://cr.openjdk.java.net/~mkos/8146086/jaxws.00/


The change ok.


test: http://cr.openjdk.java.net/~mkos/8146086/jdk.00/


The test uses a hardcoded port number. Is there a pattern in this
area for enable the test to start up on an ephemeral port, and use
that for the subsequent request?

-Chris.


Thanks
Miran

Re: RFR [9]: 8145104: NPE is thrown when JAXBContextFactory implementation is specified in system property, 8145112: newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as

[Miroslav Kos]

Ping ... anybody?

On 22/12/15 14:44, Miroslav Kos wrote:

Hi everybody,
I'd like to ask for reviewing following patch. It fixes two issues:

JBS: https://bugs.openjdk.java.net/browse/JDK-8145104
NPE is thrown when JAXBContextFactory implementation is specified in 
system property


In short, it's a regression of recent changes in JAXB-AP. The old 
version of API is using static methods to create JAXBContext instance, 
where as the new configuration facility uses defined interface. The 
methods are called via core reflection, so when invoking non-static 
method of spi implemetation, instance of the spi must be created 
first. This fixes NPE which occured in certain scenarios.


JBS: https://bugs.openjdk.java.net/browse/JDK-8145112
newInstance(String, ClassLoader): java.lang.JAXBException should not 
be wrapped as expected according to spec


There are still some changes in javadoc being discussed, but anyway 
this double-wrapping exception into JAXBException doesn't make any 
sense. JAXBException thrown from JAXB spi provider is re-thrown as is.


Fix: http://cr.openjdk.java.net/~mkos/8145104/jaxws.01/
Tests: http://cr.openjdk.java.net/~mkos/8145104/jdk.02/

Added 2 new jtreg tests, the tests added also to standalone project.

Thanks
Miran

Re: RFR [9]: 8146086 Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

[Miroslav Kos]

Ping ... anybody?

On 23/12/15 15:14, Miroslav Kos wrote:

Hi everybody,

I'd like to ask for review of . This simple patch allows 
publishing more webeservices on same port. The fix has been submitted 
by Kubota Yuji, it is already integrated in standalone JAX-WS repo, 
regression test added.


JBS: https://bugs.openjdk.java.net/browse/JDK-8146086
jaxws patch: http://cr.openjdk.java.net/~mkos/8146086/jaxws.00/
test: http://cr.openjdk.java.net/~mkos/8146086/jdk.00/

Thanks
Miran

RFR [9]: 8146086 Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

[Miroslav Kos]

Hi everybody,

I'd like to ask for review of . This simple patch allows 
publishing more webeservices on same port. The fix has been submitted by 
Kubota Yuji, it is already integrated in standalone JAX-WS repo, 
regression test added.


JBS: https://bugs.openjdk.java.net/browse/JDK-8146086
jaxws patch: http://cr.openjdk.java.net/~mkos/8146086/jaxws.00/
test: http://cr.openjdk.java.net/~mkos/8146086/jdk.00/

Thanks
Miran

RFR [9]: 8145104: NPE is thrown when JAXBContextFactory implementation is specified in system property, 8145112: newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as exp

[Miroslav Kos]

Hi everybody,
I'd like to ask for reviewing following patch. It fixes two issues:

JBS: https://bugs.openjdk.java.net/browse/JDK-8145104
NPE is thrown when JAXBContextFactory implementation is specified in 
system property


In short, it's a regression of recent changes in JAXB-AP. The old 
version of API is using static methods to create JAXBContext instance, 
where as the new configuration facility uses defined interface. The 
methods are called via core reflection, so when invoking non-static 
method of spi implemetation, instance of the spi must be created first. 
This fixes NPE which occured in certain scenarios.


JBS: https://bugs.openjdk.java.net/browse/JDK-8145112
newInstance(String, ClassLoader): java.lang.JAXBException should not be 
wrapped as expected according to spec


There are still some changes in javadoc being discussed, but anyway this 
double-wrapping exception into JAXBException doesn't make any sense. 
JAXBException thrown from JAXB spi provider is re-thrown as is.


Fix: http://cr.openjdk.java.net/~mkos/8145104/jaxws.01/
Tests: http://cr.openjdk.java.net/~mkos/8145104/jdk.02/

Added 2 new jtreg tests, the tests added also to standalone project.

Thanks
Miran

Re: Unexpected BindException in Endpoint.publish

[Miroslav Kos]

Hi Yuji,
thanks for the patch - it fixes the issue and looks ok to me. I'll 
integrate it to standalone JAX-WS repo and it will be integrated into 
openjdk during next syncup.


Thanks
Miran



On 01/12/15 11:11, KUBOTA Yuji wrote:

Hi Miroslav and all,

Could you please review the below issue and patch?

I got the advice by Alan at net-dev. So I want to ask you.
http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html


I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK
community. This's second times from JavaOne14. :)

We find an unexpected exception in JAX-WS, so I write a patch to fix it.
We think that this issue may block the migration to JDK9 from JDK7.

If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the
following test code, JDK9 (and JDK8) returns "java.net.BindException:
Address already in use.” as the below. But JDK7 does NOT return the
exception.

- Test code for reproduce
---
import javax.jws.*;
import javax.xml.ws.*;

public class WSTest{

   @WebService
   public static class Method1{
 @WebMethod
 public String getMethod1Value(){
   return "from Method1";
 }
   }

   @WebService
   public static class Method2{
 @WebMethod
 public String getMethod2Value(){
   return "from Method2";
 }
   }

   public static void main(String[] args) throws Exception{
 Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1";,
  new 
Method1());
 Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2";,
  new 
Method2());

 System.out.println("Sleep 3 secs...");

 Thread.sleep(3000);

 endPoint2.stop();
 endPoint1.stop();
   }

}
---

- StackTrace
---
Exception in thread "main"
com.sun.xml.internal.ws.server.ServerRtException: Server Runtime
Error: java.net.BindException: Address already in use
 at 
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117)
 at 
com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64)
 at 
com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232)
 at 
com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126)
 at javax.xml.ws.Endpoint.publish(Endpoint.java:240)
 at wstest.WSTest.main(WSTest.java:27)
Caused by: java.net.BindException: Address already in use
 at sun.nio.ch.Net.bind0(Native Method)
 at sun.nio.ch.Net.bind(Net.java:432)
 at sun.nio.ch.Net.bind(Net.java:424)
 at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
 at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
 at sun.net.httpserver.ServerImpl.(ServerImpl.java:102)
 at sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50)
 at 
sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35)
 at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130)
 at 
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86)
 ... 5 more
-

To publishes the Endpoint, JAX-WS checks whether the HttpContext has
been created by given address, then creates a HttpContext if do not
exist.
If we sets 0.0.0.0 as given address, JAX-WS checks by
ServerSocket#getLocalSocketAddress() (server local address), so
returns BindException when 0.0.0.0 has been blinded already.

Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think
about above situation. And JAX_WS-941 does not back port to JDK7.

So I write a patch which is based jdk9/dev/jaxws
(changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941.

Please review this patch :)

[1]: https://java.net/jira/browse/JAX_WS-941

- Patch
---
diff -r 2d84c6f4cbba
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
--- 
a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
Thu Oct 22 08:47:47 2015 -0700
+++ 
b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
Tue Oct 27 19:48:35 2015 +0900
@@ -38,6 +38,7 @@
  import java.util.concurrent.ExecutorService;
  import java.util.concurrent.Executors;
  import java.util.logging.Logger;
+import java.util.Optional;

  /**
   * Manages all the WebService HTTP servers created by JAXWS runtime.
@@ -81,24 +82,38 @@
  synchronized(servers) {
  state = servers.get(inetAddress);
  if (state == null) {
-logger.fine("Creating new HTTP Server at "+inetAddress);
-// Creates server with default socket backlog
-server = HttpServer.create(inetAddress, 0);
-server.setExecutor(Executors.ne

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 20/11/15 15:25, Daniel Fuchs wrote:

On 20/11/15 09:43, Miroslav Kos wrote:

Locally, it worked for me, but I understand that it's dengerous - global
state is evil ... I removed all the scenarios modifying JDK/conf/ dir -
I just commented out those parts so if necessary, it can be uncommented
and run locally.
http://cr.openjdk.java.net/~mkos/8131334/jdk.02/


Hi Miran,

It's good that you were able to test the jaxm.properties file
scenario locally.
Commenting it out of the jtreg test so that it's not run
automatically in random test env seems like the right thing
to do.

best regards,

-- daniel
Thanks! Lance, are you ok with that? May I push it together with jaxws 
patch?


Thanks
Miran






Thanks
Miran


On 19/11/15 21:45, Alan Bateman wrote:



On 19/11/2015 18:36, Daniel Fuchs wrote:


Hi Miran,

I would expect this to fail horribly - you may not have the
right to create anything under $JAVA_HOME/conf - it may even
be a read-only file system... And I would be very uneasy as this
may have side effects on tests executing later on if anything
is left over in the java home conf dir...


There may be tests executing concurrently in other agent VMs too so we
need to avoid changing the config like this.

-Alan

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Locally, it worked for me, but I understand that it's dengerous - global 
state is evil ... I removed all the scenarios modifying JDK/conf/ dir - 
I just commented out those parts so if necessary, it can be uncommented 
and run locally.

http://cr.openjdk.java.net/~mkos/8131334/jdk.02/

Thanks
Miran


On 19/11/15 21:45, Alan Bateman wrote:



On 19/11/2015 18:36, Daniel Fuchs wrote:


Hi Miran,

I would expect this to fail horribly - you may not have the
right to create anything under $JAVA_HOME/conf - it may even
be a read-only file system... And I would be very uneasy as this
may have side effects on tests executing later on if anything
is left over in the java home conf dir...

There may be tests executing concurrently in other agent VMs too so we 
need to avoid changing the config like this.


-Alan

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi Lance,

I added jtreg test(s) - 
http://cr.openjdk.java.net/~mkos/8131334/jdk.01/index.html

There are several scenarios being tested, all without/with SM.

The test preparation I am doing in java (based on test args), so the 
test creates/deletes $JAVA_HOME/conf/jaxm.properties.


Hopefully it's correct approach.

Thanks
Miran



On 12/11/15 15:07, Lance Andersen wrote:
Not sure exactly what you want to set, but you can set system 
properties or run tests from a script or from testNG


For running a script, see http://openjdk.java.net/jtreg/vmoptions.html

Best
Lance
On Nov 12, 2015, at 8:28 AM, Miroslav Kos <mailto:miroslav@oracle.com>> wrote:


I have a set of tests in standalone project (using bash scripts), but 
the problem is that to test the correct behavior, configuring of jdk 
is necessary (property file) - have no idea if something like this is 
possible with jtreg - are there any similat tests already?


Thanks
Miran

On 12/11/15 14:01, Lance @ Oracle wrote:

Hi,

Overall it looks ok,

I would however suggest adding a couple of tests to the jdk that run 
with/out a security manager as a sanity check.


Best
Lance


<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037 


Oracle Java Engineering
1 Network Drive 
Burlington, MA 01803 
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Sent from my iPad

On Nov 12, 2015, at 3:55 AM, Miroslav Kos  
wrote:



.. anyone?

On 10/11/15 15:31, Miroslav Kos wrote:

Ping ... Would somebody find time for this one?

Thanks
M.


On 26/10/15 13:59, Miroslav Kos wrote:

Hi everybody,

I'd like to ask you for a review for
8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

It is about changes in pluggability layer - there was a 
proprietary service loading implementation which was not fully 
compatible with to use java.util.ServiceLoader facility. There 
are similar changes in all JAX-* APIs specs - JAX-B,  JAX-WS and 
SAAJ.


JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/
specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.09/

Testing - there are tests in standalone project to ensure there 
that the old behavior is still supported.


Thanks
Miran









<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

I have a set of tests in standalone project (using bash scripts), but 
the problem is that to test the correct behavior, configuring of jdk is 
necessary (property file) - have no idea if something like this is 
possible with jtreg - are there any similat tests already?


Thanks
Miran

On 12/11/15 14:01, Lance @ Oracle wrote:

Hi,

Overall it looks ok,

I would however suggest adding a couple of tests to the jdk that run 
with/out a security manager as a sanity check.


Best
Lance


<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037 


Oracle Java Engineering
1 Network Drive 
Burlington, MA 01803 
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Sent from my iPad

On Nov 12, 2015, at 3:55 AM, Miroslav Kos <mailto:miroslav@oracle.com>> wrote:



.. anyone?

On 10/11/15 15:31, Miroslav Kos wrote:

Ping ... Would somebody find time for this one?

Thanks
M.


On 26/10/15 13:59, Miroslav Kos wrote:

Hi everybody,

I'd like to ask you for a review for
8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

It is about changes in pluggability layer - there was a proprietary 
service loading implementation which was not fully compatible with 
to use java.util.ServiceLoader facility. There are similar changes 
in all JAX-* APIs specs - JAX-B,  JAX-WS and SAAJ.


JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/ 
<http://cr.openjdk.java.net/%7Emkos/8131334/jaxws.01/>
specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.09/ 
<http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.09/>


Testing - there are tests in standalone project to ensure there 
that the old behavior is still supported.


Thanks
Miran

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

.. anyone?

On 10/11/15 15:31, Miroslav Kos wrote:

Ping ... Would somebody find time for this one?

Thanks
M.


On 26/10/15 13:59, Miroslav Kos wrote:

Hi everybody,

I'd like to ask you for a review for
8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

It is about changes in pluggability layer - there was a proprietary 
service loading implementation which was not fully compatible with to 
use java.util.ServiceLoader facility. There are similar changes in 
all JAX-* APIs specs - JAX-B,  JAX-WS and SAAJ.


JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/
specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.09/

Testing - there are tests in standalone project to ensure there that 
the old behavior is still supported.


Thanks
Miran

Re: [RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Ping ... Would somebody find time for this one?

Thanks
M.


On 26/10/15 13:59, Miroslav Kos wrote:

Hi everybody,

I'd like to ask you for a review for
8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

It is about changes in pluggability layer - there was a proprietary 
service loading implementation which was not fully compatible with to 
use java.util.ServiceLoader facility. There are similar changes in all 
JAX-* APIs specs - JAX-B,  JAX-WS and SAAJ.


JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/
specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.09/

Testing - there are tests in standalone project to ensure there that 
the old behavior is still supported.


Thanks
Miran

Re: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos

[Miroslav Kos]

Thanks, good catch - fixed:
http://cr.openjdk.java.net/~mkos/8139743/jaxws.04/index.html
http://cr.openjdk.java.net/~mkos/8139743/specdiff.04/index.html

Regarding PipeClonerImpl - yes, there is no change - originally there 
was probably some unintentional change (?)


Thanks
Miran



On 26/10/15 20:09, Lance Andersen wrote:

Hi Miran

Overall looks OK.  Couple quick points:


Does the picture look correct at 
http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/bind/v2/package-summary.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.03/com/sun/xml/internal/bind/v2/package-summary.html>? 
 Might be made more readable


http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.03/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html> is 
not in the specdiff  and not in the webrev.  Intentional?



Best
Lance


On Oct 23, 2015, at 11:07 AM, Miroslav Kos <mailto:miroslav@oracle.com>> wrote:



Hi Lance,
here is the new version - all the issues addressed, except for ones 
with extraspace - it looks it's only in specdiff, not in javadoc.


http://cr.openjdk.java.net/~mkos/8139743/jaxws.03/
http://cr.openjdk.java.net/~mkos/8139743/specdiff.03/


Thanks a lot for catching all these
Miran





On 21/10/15 21:55, Lance Andersen wrote:

Hi Miran

I just made a pass through the spec diff and have a few 
comments/questions:


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.html> 
 is the <, > correct in the new version?


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/generator/bean/PackageOutlineImpl.html> : 
 still a period in @see for getMostUsedNamespaceURI


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/model/CPropertyInfo.html>: 
 extra space before the period in getName


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/Const.html> : 
Extra space before the comma


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/package-summary.html>: 
The package summary changes seem wrong (extra and for example)


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/tools/internal/xjc/reader/relaxng/RELAXNGInternalizationLogic.ReferenceFinder.html>: 
 change seems wrong (extra and for example)


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/core/ElementInfo.html>: 
extra semi-colon after  I believe


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.html>  extra 
semi-colon after  I believe


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementInfoImpl.PropertyImpl.html> looks 
like @XmlElement was changed incorrectly?


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/ElementPropertyInfoImpl.html>  looks 
like @XmlElement was changed incorrectly?


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.html> extra 
semi-colon?


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/model/impl/RuntimeElementInfoImpl.RuntimePropertyImpl.html>  looks 
like

[RFR]: 8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi everybody,

I'd like to ask you for a review for
8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

It is about changes in pluggability layer - there was a proprietary 
service loading implementation which was not fully compatible with to 
use java.util.ServiceLoader facility. There are similar changes in all 
JAX-* APIs specs - JAX-B,  JAX-WS and SAAJ.


JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/
specdiff: http://cr.openjdk.java.net/~mkos/8131334/specdiff.09/

Testing - there are tests in standalone project to ensure there that the 
old behavior is still supported.


Thanks
Miran

Re: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos

[Miroslav Kos]

internal/bind/v2/runtime/output/ForkXmlOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/ForkXmlOutput.html> 



http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/IndentingUTF8XmlOutput.html> 



http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/MTOMXmlOutput.html> 



http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/SAXOutput.html>


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/StAXExStreamWriterOutput.html>


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/UTF8XmlOutput.html>


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLEventWriterOutput.html>


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XMLStreamWriterOutput.html>


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/bind/v2/runtime/output/XmlOutput.html>





http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/com/sun/xml/internal/ws/api/pipe/PipeClonerImpl.html> - 
looks like this was missing from the specdiff


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/javax/xml/bind/Marshaller.html> extra 
space before ')'


http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html 
<http://cr.openjdk.java.net/%7Emkos/8139743/specdiff.02/javax/xml/bind/helpers/AbstractMarshallerImpl.html> extra 
space before ')'


Best,
Lance

On Oct 21, 2015, at 12:42 PM, Miroslav Kos <mailto:miroslav@oracle.com>> wrote:



Hi Lance,
yes, it makes sense - after creating it and reviewing I fixed 
additional issues - please, check new version of a patch:

http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/
http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/

Thanks
Miran

On 16/10/15 18:12, Lance Andersen wrote:

Hi Miran

On Oct 16, 2015, at 11:49 AM, Miroslav Kos  
wrote:



Hi Lance,
the javadoc fixes are just about formal issues (... for 
{@code .. }, broken links etc.) - there are no other changes.


Understand, but the specdiff makes it easier to see that there are 
no untended changes especially with the size.


Best
Lance


Thanks
Miran


On 16/10/15 17:26, Lance Andersen wrote:

Hi Miran

Can you please provide a specdiff as that makes it easier for 
javadoc review


Best
Lance
On Oct 16, 2015, at 11:14 AM, Miroslav Kos 
 wrote:



Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ 
<http://cr.openjdk.java.net/%7Emkos/8139743/jaxws.01/>
more details in issue desc: 
https://bugs.openjdk.java.net/browse/JDK-8139743


Could I ask for a review?

It's quite big (2570  lines changed):
* many javadoc fixes
* some performance and other fixes for SAAJ
* findbugs issues

There are issue list in the JBS, many of listed bugs were fixed 
in JDK already (they are on the list because of backporting to 
standalone)


Thanks
Miran



 
<http://oracle.com/us/design/oracle-email-sig-198324.gif>

<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>







 
<http://oracle.com/us/design/oracle-email-sig

Re: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos

[Miroslav Kos]

Hi Lance,
yes, it makes sense - after creating it and reviewing I fixed additional 
issues - please, check new version of a patch:

http://cr.openjdk.java.net/~mkos/8139743/jaxws.02/
http://cr.openjdk.java.net/~mkos/8139743/specdiff.02/

Thanks
Miran

On 16/10/15 18:12, Lance Andersen wrote:

Hi Miran

On Oct 16, 2015, at 11:49 AM, Miroslav Kos <mailto:miroslav@oracle.com>> wrote:



Hi Lance,
the javadoc fixes are just about formal issues (... for 
{@code .. }, broken links etc.) - there are no other changes.


Understand, but the specdiff makes it easier to see that there are no 
untended changes especially with the size.


Best
Lance


Thanks
Miran


On 16/10/15 17:26, Lance Andersen wrote:

Hi Miran

Can you please provide a specdiff as that makes it easier for 
javadoc review


Best
Lance
On Oct 16, 2015, at 11:14 AM, Miroslav Kos  
wrote:



Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ 
<http://cr.openjdk.java.net/%7Emkos/8139743/jaxws.01/>
more details in issue desc: 
https://bugs.openjdk.java.net/browse/JDK-8139743


Could I ask for a review?

It's quite big (2570  lines changed):
* many javadoc fixes
* some performance and other fixes for SAAJ
* findbugs issues

There are issue list in the JBS, many of listed bugs were fixed in 
JDK already (they are on the list because of backporting to standalone)


Thanks
Miran



 
<http://oracle.com/us/design/oracle-email-sig-198324.gif>

<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>







<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>

Re: [9] RFR: 8139743 regular JAX-* sync-up from standalone repos

[Miroslav Kos]

Hi Lance,
the javadoc fixes are just about formal issues (... for {@code 
.. }, broken links etc.) - there are no other changes.


Thanks
Miran


On 16/10/15 17:26, Lance Andersen wrote:

Hi Miran

Can you please provide a specdiff as that makes it easier for javadoc 
review


Best
Lance
On Oct 16, 2015, at 11:14 AM, Miroslav Kos <mailto:miroslav@oracle.com>> wrote:



Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/ 
<http://cr.openjdk.java.net/%7Emkos/8139743/jaxws.01/>
more details in issue desc: 
https://bugs.openjdk.java.net/browse/JDK-8139743


Could I ask for a review?

It's quite big (2570  lines changed):
* many javadoc fixes
* some performance and other fixes for SAAJ
* findbugs issues

There are issue list in the JBS, many of listed bugs were fixed in 
JDK already (they are on the list because of backporting to standalone)


Thanks
Miran



<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>

[9] RFR: 8139743 regular JAX-* sync-up from standalone repos

[Miroslav Kos]

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8139743/jaxws.01/
more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8139743

Could I ask for a review?

It's quite big (2570  lines changed):
* many javadoc fixes
* some performance and other fixes for SAAJ
* findbugs issues

There are issue list in the JBS, many of listed bugs were fixed in JDK already 
(they are on the list because of backporting to standalone)

Thanks
Miran

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 02/10/15 19:36, Georgiy Rakov wrote:

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:
* 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.
Sorry, it was misunderstanding here - I thought you wanted me to specify 
the actual type of platform default implementations - specifying 
null/not null makes definitely sense.


I added not null statements to SAAJMetaFactory methods' javadoc:

Returns:
   a|SOAPFactory|
   
<http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.08/javax/xml/soap/SOAPFactory.html>,notnull

Hopefully it's enough?

Thanks
Miran




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.

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

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:
* 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.


Another point is that in the first review you sent there was a 
non-normative note you removed, maybe it's worth being restored(?)

restored.


Just a stylistic note - wouldn't be easier just to create a list of 
SAAJMetaFactory lookup steps like it's done in |javax.xml.soap?|

done.


Another point - is it worth mentioning how custom SAAJMetaFactory is 
instantiated by SAAJ API? I mean is it instantiated only once and then 
the reference is stored, or is it instantiated each time user requests 
|SOAPFactory| or |MessageFactory| creation and SAAJMetaFactory 
instance is needed?

I added a sentence about this to section "Discovery of SAAJ implementation":
Whenever|SAAJMetaFactory| 
isused,itslookupproceduretogetactualinstanceisperformed.


Thanks
Miran



Thank you,
Georgiy.||

2) SAAJMetaFactory supports only 2 of 3 SAAJ Factories
- this is current state, we are not changing that - I am afraid 
adding a new abstract method into existing Factory class is too 
incompatible change for MR

- just changed javadoc:
AlloftheThe|newInstance|methods defined on factories|SOAPFactory| 
and|MessageFactory| 
 
...



Ok, thanks.

Thanks
Miran

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi Georgiy,
would you be ok with this defensive solution?

Thanks
Miran


On 01/10/15 17:10, Miroslav Kos wrote:

Hi,

there is a new version of specdiff:
http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/index.html

To remind, there were two problems to be addressed, both related to 
SAAJMetaFactory:

http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/javax/xml/soap/SAAJMetaFactory.html

1) hidden feature of lookup mechanism for SAAJMetaFactory:
I added two new paragraphs into javadoc
- one references the service loader facility
- the second one mentions additional steps and references the 
algorithm in javax.xml.soap package desc


2) SAAJMetaFactory supports only 2 of 3 SAAJ Factories
- this is current state, we are not changing that - I am afraid adding 
a new abstract method into existing Factory class is too incompatible 
change for MR

- just changed javadoc:
AlloftheThe|newInstance|methods defined on factories|SOAPFactory| 
<http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/SOAPFactory.html>and|MessageFactory| 
<http://cr.openjdk.java.net/%7Emkos/8131334/specdiff.06/javax/xml/soap/MessageFactory.html> 
...


Thanks
Miran

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi,

there is a new version of specdiff:
http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/index.html

To remind, there were two problems to be addressed, both related to 
SAAJMetaFactory:

http://cr.openjdk.java.net/~mkos/8131334/specdiff.06/javax/xml/soap/SAAJMetaFactory.html

1) hidden feature of lookup mechanism for SAAJMetaFactory:
I added two new paragraphs into javadoc
- one references the service loader facility
- the second one mentions additional steps and references the algorithm 
in javax.xml.soap package desc


2) SAAJMetaFactory supports only 2 of 3 SAAJ Factories
- this is current state, we are not changing that - I am afraid adding a 
new abstract method into existing Factory class is too incompatible 
change for MR

- just changed javadoc:
AlloftheThe|newInstance|methods defined on factories|SOAPFactory| 
and|MessageFactory| 
 
...


Thanks
Miran

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 30/09/15 17:31, Miroslav Kos wrote:

On 30/09/15 16:50, Georgiy Rakov wrote:
2. This is not related to ServiceLoader feature, but anyway - 
SAAJMetaFactory.java:


   30 * SAAJ API./_*All *_//_*of the {@code newInstance} methods defined on 
factories*_/  in
   31 * SAAJ 1.3 defer to instances of this class to do the actual object 
creation.

Namely it says that /_*all*_/**the newInstance methods defined on 
factories delegate factory creation to SAAJMetaFactory instances, but 
this seems to be not exactly true because SOAPConnectionFactory is 
not created by SAAJMetaFactory instance.

Yes, good catch. To fix it, it would be good to add a new abstract method
public abstract SOAPConnectionFactory newSOAPConnectionFactory()
throws SOAPException, UnsupportedOperationException

Would you agree, Deva, Chen? There is a problem with backwards 
compatibility here ... More defensive would be to name the two 
factories instead of saying "all"?

Any opinion on this, anybody?

Thanks
Miran




Thanks
Miran

Btw. I sent this RFR initially to wrong mailing lists, would you check 
when answering that it's to  Core-Libs-Dev 
 ?




Thank you,
Georgiy.

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 30/09/15 16:50, Georgiy Rakov wrote:

Hello Miroslav,

could you please see some more comments below:

1. I believe it's better to say that exactly "fully qualified name" of 
the provider factory implementation class is assumed to be the value 
of the property:


  *  {@code javax.xml.soap.SOAPFactory}). If such property exists then its 
value is assumed to be/_*the provider*_/
  */_*factory class*_/. This phase of the look up enables per-JVM override 
of the SAAJ implementation.

This has been done in the next step of lookup procedure and this looks 
reasonable:


  *  {@code conf} directory of the Java installation. It contains 
the/_*fully qualified *_/  */_*name*_/  ...


Will fix, thanks.


2. This is not related to ServiceLoader feature, but anyway - 
SAAJMetaFactory.java:


   30 * SAAJ API./_*All *_//_*of the {@code newInstance} methods defined on 
factories*_/  in
   31 * SAAJ 1.3 defer to instances of this class to do the actual object 
creation.

Namely it says that /_*all*_/**the newInstance methods defined on 
factories delegate factory creation to SAAJMetaFactory instances, but 
this seems to be not exactly true because SOAPConnectionFactory is not 
created by SAAJMetaFactory instance.

Yes, good catch. To fix it, it would be good to add a new abstract method
public abstract SOAPConnectionFactory newSOAPConnectionFactory()
throws SOAPException, UnsupportedOperationException

Would you agree, Deva, Chen? There is a problem with backwards 
compatibility here ... More defensive would be to name the two factories 
instead of saying "all"?


Thanks
Miran

Btw. I sent this RFR initially to wrong mailing lists, would you check 
when answering that it's to  Core-Libs-Dev 
 ?




Thank you,
Georgiy.

On 25.09.2015 16:34, Miroslav Kos wrote:

Ping ...

On 11/09/15 17:57, Miroslav Kos wrote:

Hi again,
would somebody find a time to review?

Thanks
Miran

On 20/08/15 16:17, Miroslav Kos wrote:

Hi everybody,

I am sending changes for review for
JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part 
of service discovery was implemented previously "own" way. There 
are some changes in javadoc and implementation has been refactored 
in order to use same code as in JAX-WS and JAX-B.


Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 + 
new tests specificaly developed for testing service discovery in SAAJ.


Thanks
Miran

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 30/09/15 16:20, Deva Sagar wrote:

Hi Georgiy,

I think both Miran and I are referring to the mention of 
SAAJMetaFactory in the bullet list about the public newInstance() 
method. The Javadoc of the SAAJMetaFactory class still describes it as 
an SPI and it is accessible from package-info. This is no different 
from the current public Javadocs.


Thanks,
Deva


On Sep 30, 2015, at 9:16 AM, Georgiy Rakov <mailto:georgiy.ra...@oracle.com>> wrote:




On 29.09.2015 17:43, Deva Sagar wrote:

Hi Miran,

Sorry for the delay in responding to this - I was busy with WLS 
release close down, and now I have moved to a different job in the 
cloud organization outside of WLS and web services.


Regarding your question in #3 - I think Georgiy made a good 
observation about SAAJMetaFactory - making a public newInstance 
method as you suggest would make it agree with the package-info, but 
does not correspond to the API specification. The package-info in 
Java SE 8 API docs says "SAAJMetaFactory is a service provider 
interface. There are no public methods on this class.” If we put in 
a public newInstance() method, it does not agree with this statement 
in API Javadoc. It might be better in my opinion to 
remove SAAJMetaFactory mention from package-info.java unless there 
is a good reason to keep it.



Hello,

according to my understanding the idea of SAAJMetaFactory is for SPI 
developer to subclass it and thus to create a custom SAAJMetaFactory 
implementation.
Yes, it's current state - the only description of lookup/instantiation 
user SAAJMetaFactory is statement that it is service provider interaface 
(stays unchanged): 
https://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SAAJMetaFactory.html

Service loader is the only specification here.
Afterwards user should configure SAAJ API in order it could use that 
custom implementation.
User configuration controls discovery of implementation when used 
newInstance method on other factories (MessageFactory, SOAPFactory, 
SOAPConnectionFactory). If no implementation found, the fallback is user 
(or default) SAAJMetaFactory.newXXXFactory()
But if SAAJMetaFactory mention from package-info.java is removed 
there will be actually no spec defining how to configure SAAJ API for 
using custom SAAJMetaFactory, or do I miss spec defining it?

No, there is still statement about service provider interface.
BTW: from this perspective referring to SAAJMetaFactory newInstance 
method in spec is not relevant since it's SAAJ API implementation 
internal machinery.

Yes, it is internal.

Actually I thing SAAJ API is pretty complicated already, so not adding 
another spec for SAAJMetaFactory discovery is good idea ...


Thanks
Miran




So I believe if SAAJMetaFactory mention from package-info.java is 
removed the process of SAAJMetaFactory instantiation should be 
described somehow in another place and without mentioning newInstance 
method. Maybe it's worth rather modifying than removing this 
mentioning in package-info.java?


Thanks,
Georgiy.

The rest of your changes look ok to me. Also cc’ing Chen for any 
additional comments


Deva



On Sep 29, 2015, at 9:45 AM, Miroslav Kos  
wrote:


On 25/09/15 20:24, Georgiy Rakov wrote:

Hello Miroslav,

sorry for delay, was busy due to deadlines.

I think it's just spec I am to review. Some comments for the 
moment please see below:


1. package-info.java:

  *  Checks if a system property with the same name as the factory 
class is set (/_*i.e.*_/
  *  {@code javax.xml.soap.SOAPFactory}).

I guess "e.g." is meant, that is "for example"?

Sure, thanks.


2. SAAJMetaFactory.java:

Following is specified normatively:
   62  * Property {@code javax.xml.soap.MetaFactory} used in previous
   63  * specifications (up to 1.3) is still supported, but it is strongly 
recommended to migrate to new property
   64  * {@code javax.xml.soap.SAAJMetaFactory}.
while in package-info.java: the same idea is specified as API note 
that is non-normatively:

  * @apiNote
  * For {@link javax.xml.soap.SAAJMetaFactory}, property {@code 
javax.xml.soap.MetaFactory} used in previous
  * specifications (up to 1.3) is still supported, but it is strongly 
recommended to migrate to new property
  * {@code javax.xml.soap.SAAJMetaFactory}.
  */
I believe this idea should be specified everywhere the same way 
that is either normatively or non-normatively. If it's to be 
defined normatively more details should be specified I believe.

Made non-normative.


3. SAAJMetaFactory.getInstance method is package private. So:
- This method is not supposed to be used by users, is it?
- The javadoc of this method isn't actually a public 
specification. Thus Oracle claims nothing by it and external Java 
SE implementers are not required to follow this JavaDoc, that is 
this JavaDoc is intended to be used internally only, isn't it?
I understand that this was before, but It looks very stra

Re: [9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 29/09/15 16:43, Deva Sagar wrote:

Hi Miran,

Sorry for the delay in responding to this - I was busy with WLS 
release close down, and now I have moved to a different job in the 
cloud organization outside of WLS and web services.


Regarding your question in #3 - I think Georgiy made a good 
observation about SAAJMetaFactory - making a public newInstance method 
as you suggest would make it agree with the package-info, but does not 
correspond to the API specification. The package-info in Java SE 8 API 
docs says "SAAJMetaFactory is a service provider interface. There are 
no public methods on this class.” If we put in a public newInstance() 
method, it does not agree with this statement in API Javadoc. It might 
be better in my opinion to remove SAAJMetaFactory mention from 
package-info.java unless there is a good reason to keep it.

Agree, let's keep that simple. The updated specdiff is here:
http://cr.openjdk.java.net/~mkos/8131334/specdiff.05/

ApiNote removed, SAAJMetaFactory kept package private.

Thanks
Miran



The rest of your changes look ok to me. Also cc’ing Chen for any 
additional comments


Deva



On Sep 29, 2015, at 9:45 AM, Miroslav Kos <mailto:miroslav@oracle.com>> wrote:


On 25/09/15 20:24, Georgiy Rakov wrote:

Hello Miroslav,

sorry for delay, was busy due to deadlines.

I think it's just spec I am to review. Some comments for the moment 
please see below:


1. package-info.java:

  *  Checks if a system property with the same name as the factory 
class is set (/_*i.e.*_/
  *  {@code javax.xml.soap.SOAPFactory}).

I guess "e.g." is meant, that is "for example"?

Sure, thanks.


2. SAAJMetaFactory.java:

Following is specified normatively:
   62  * Property {@code javax.xml.soap.MetaFactory} used in previous
   63  * specifications (up to 1.3) is still supported, but it is strongly 
recommended to migrate to new property
   64  * {@code javax.xml.soap.SAAJMetaFactory}.
while in package-info.java: the same idea is specified as API note 
that is non-normatively:

  * @apiNote
  * For {@link javax.xml.soap.SAAJMetaFactory}, property {@code 
javax.xml.soap.MetaFactory} used in previous
  * specifications (up to 1.3) is still supported, but it is strongly 
recommended to migrate to new property
  * {@code javax.xml.soap.SAAJMetaFactory}.
  */
I believe this idea should be specified everywhere the same way that 
is either normatively or non-normatively. If it's to be defined 
normatively more details should be specified I believe.

Made non-normative.


3. SAAJMetaFactory.getInstance method is package private. So:
- This method is not supposed to be used by users, is it?
- The javadoc of this method isn't actually a public specification. 
Thus Oracle claims nothing by it and external Java SE implementers 
are not required to follow this JavaDoc, that is this JavaDoc is 
intended to be used internally only, isn't it?
I understand that this was before, but It looks very strange. Is 
this really not a mistake? BTW: this method and spec are not visible 
in API JavaDoc 
<https://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SAAJMetaFactory.html>.


It looks like a mistake moreover because public specification 
defined in package-info.java being reviewed refers to it:

  * There are several factories defined in the SAAJ API to discover and load 
specific implementation:
  *
  * 
  * {@link javax.xml.soap.SOAPFactory}
  * {@link javax.xml.soap.MessageFactory}
  * {@link javax.xml.soap.SOAPConnectionFactory}
  /_** {@link javax.xml.soap.SAAJMetaFactory}*_/
  * 
  *
  * These factories define {@code/_*newInstance()*_/} method which uses a 
common lookup procedure to determine
  * the implementation class:
It's good catch - it looks like error. An easy fix would be change 
the method to newInstance and make it public - Deva, would you agree?

http://cr.openjdk.java.net/~mkos/8131334/specdiff.04/index.html

Anyway those are changes to API - should I withdraw 
http://ccc.us.oracle.com/8131334 and create new one?


Thanks
Miran




Thank you,
Goergiy.

On 25.09.2015 16:34, Miroslav Kos wrote:

Ping ...

On 11/09/15 17:57, Miroslav Kos wrote:

Hi again,
would somebody find a time to review?

Thanks
Miran

On 20/08/15 16:17, Miroslav Kos wrote:

Hi everybody,

I am sending changes for review for
JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This 
part of service discovery was implemented previously "own" way. 
There are some changes in javadoc and implementation has been 
refactored in order to use same code as in JAX-WS and JAX-B.


Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 
+ new tests specificaly developed for testing service discovery 
in SAAJ.


Thanks
Miran

Re: [9] RFR: 8061466 - RELAX NG API visible but not accessible

[Miroslav Kos]

On 25/09/15 11:46, Alan Bateman wrote:


On 25/09/2015 10:36, Miroslav Kos wrote:

Hi,
I prepared the webrev again with hg move:
http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html

For sure, jprt built again and all tests rerun.

The move and re-packaging looks good to me.

However I see there is more to this as it drops the -relaxng and 
-relaxng-compat command options so we'll need to make sure that this 
is tracked (even though these command-line options seems to have 
always been reported as unsupported and experimental). 
If it is necessary, I can file a CCC. Is it? If it is, I suppose it 
should address just change in tool (xjc) options - the implementation is 
in jdk.xml.bind, not java.xml.bind


I see the localized versions of the properties have also been changed 
and re-formatted. At one point then the rule was to not touch 
localized files because they are generated/changed by translation 
tools. I don't know know if the master version of these files is in 
the jaxws repo or maintained somewhere upstream.
The localized properties are in standalone repo, so I suppose it is 
master(?)


Even if CCC required, it doesn't block us from pushing this, does it? If 
it was an issue, I can split the changeset into two (repackaging + 
removing options)


Thanks
Miran


-Alan

Re: [9] RFR: 8061466 - RELAX NG API visible but not accessible

[Miroslav Kos]

On 24/09/15 16:20, Alan Bateman wrote:

On 24/09/2015 14:57, Miroslav Kos wrote:

Hi everybody,

I'd like to ask for review of following fix:

RELAX NG API visible but not accessible
JBS: https://bugs.openjdk.java.net/browse/JDK-8061466
webrev: http://cr.openjdk.java.net/~mkos/8061466/jaxws.01/index.html

- org.relaxng.* classes in jdk.xml.bind module are not repackaged, 
but those are not exported so they are not usable outside of module 
(jdk) anyway
- processing RelaxNG schemas with JAX-B's declared as 
experimental/unsupported, but removing these classes is not easy 
since several other packages within JAX-B depend on those ...


This patch repackages these classes from org.relaxng.* to 
com.sun.xml.internal.org.relaxng.* + removes loading RelaxNG runtime 
in xjc (+ removing related messages).
Good to see these classes being renamed. I agree with Chris that this 
should be hg mv so that the history is preserved.


The proposed package name seems okay to me, if only because the 
internal classes in this area are already using com.sun.xml.internal. 
If this wasn't the case then the jdk or jdk.internal tree would have 
been appropriate.


-Alan.

Hi,
I prepared the webrev again with hg move:
http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html

For sure, jprt built again and all tests rerun.

Thanks
Miran

[9] RFR: 8061466 - RELAX NG API visible but not accessible

[Miroslav Kos]

Hi everybody,

I'd like to ask for review of following fix:

RELAX NG API visible but not accessible
JBS: https://bugs.openjdk.java.net/browse/JDK-8061466
webrev: http://cr.openjdk.java.net/~mkos/8061466/jaxws.01/index.html

- org.relaxng.* classes in jdk.xml.bind module are not repackaged, but 
those are not exported so they are not usable outside of module (jdk) anyway
- processing RelaxNG schemas with JAX-B's declared as 
experimental/unsupported, but removing these classes is not easy since 
several other packages within JAX-B depend on those ...


This patch repackages these classes from org.relaxng.* to 
com.sun.xml.internal.org.relaxng.* + removes loading RelaxNG runtime in 
xjc (+ removing related messages).


Testing: snadalone JAX-B/WS tests, JAX-WS JCK, jtreg, no regressions.

Thanks
Miran

Re: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 15/09/15 15:46, Alan Bateman wrote:



On 27/08/2015 19:26, Miroslav Kos wrote:

Hi Alan,
I added logging (at least for now) - would it work for you?
updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/

If you think the exception shouldn't be ignored I suggest to solve 
this in separate issue (and maybe revisit all similar cases in 
SAAJ/JAX-*)

The logging looks okay now.

A minor comment is that in fromJDKProperties then you can avoid 
toFile() and just use Files.exists(f) if you want.


-Alan

Fixed here: http://cr.openjdk.java.net/~mkos/8131667/jaxws.03/

Thanks
Miran

[9] Review request JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi everybody,

I am sending changes for review for
JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part of 
service discovery was implemented previously "own" way. There are some 
changes in javadoc and implementation has been refactored in order to 
use same code as in JAX-WS and JAX-B.


Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 + new 
tests specificaly developed for testing service discovery in SAAJ.


Thanks
Miran

Re: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 27/08/15 20:26, Miroslav Kos wrote:

On 20/08/15 19:18, Alan Bateman wrote:

On 19/08/2015 16:37, Miroslav Kos wrote:

Hi everybody,

I am sending changes for review.

CCC: http://ccc.us.oracle.com/8131667
JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part 
of service discovery was implemented previously "own" way. There are 
some changes in javadoc and implementation has been refactored in 
order to use same code as is in JAX-B and SAAJ.
I skimmed through this and it mostly looks okay. One thing that 
probably should be re-examined is the catch Exception in 
fromJDKProperties as an exception accessing or parsing 
jaxws.properties will be difficult to diagnose with the code as it is.


-Alan

Hi Alan,
I added logging (at least for now) - would it work for you?
updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/

If you think the exception shouldn't be ignored I suggest to solve 
this in separate issue (and maybe revisit all similar cases in 
SAAJ/JAX-*)


Thanks
Miran

Hi Alan,
would you have some time to check the changes?

Thanks
Miran

Re: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 20/08/15 19:18, Alan Bateman wrote:

On 19/08/2015 16:37, Miroslav Kos wrote:

Hi everybody,

I am sending changes for review.

CCC: http://ccc.us.oracle.com/8131667
JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part 
of service discovery was implemented previously "own" way. There are 
some changes in javadoc and implementation has been refactored in 
order to use same code as is in JAX-B and SAAJ.
I skimmed through this and it mostly looks okay. One thing that 
probably should be re-examined is the catch Exception in 
fromJDKProperties as an exception accessing or parsing 
jaxws.properties will be difficult to diagnose with the code as it is.


-Alan

Hi Alan,
I added logging (at least for now) - would it work for you?
updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/

If you think the exception shouldn't be ignored I suggest to solve this 
in separate issue (and maybe revisit all similar cases in SAAJ/JAX-*)


Thanks
Miran

Re: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi Alan,
yes, I know the error/exception handling is really bad here - it isn't 
anywhere defined properly. In addition, although the code in JAX-B / 
JAX-WS / SAAJ was most probably "developed" using cut&paste, it isn't 
very consistent.


I tried to improve it a little bit, but I am not sure how much may I 
change the behavior because of backwards compatibility. I would prefer 
fail fast if configuration is wrong, but may I? Maybe Georgiy (added) 
could advise on that?


Anyway even if we don't change it, there should be added some logging.

Thanks
Miran


On 20/08/15 19:18, Alan Bateman wrote:

On 19/08/2015 16:37, Miroslav Kos wrote:

Hi everybody,

I am sending changes for review.

CCC: http://ccc.us.oracle.com/8131667
JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part 
of service discovery was implemented previously "own" way. There are 
some changes in javadoc and implementation has been refactored in 
order to use same code as is in JAX-B and SAAJ.
I skimmed through this and it mostly looks okay. One thing that 
probably should be re-examined is the catch Exception in 
fromJDKProperties as an exception accessing or parsing 
jaxws.properties will be difficult to diagnose with the code as it is.


-Alan

[9] Review request JDK-8131667: JAX-WS Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi everybody,

I am sending changes for review.

CCC: http://ccc.us.oracle.com/8131667
JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part of 
service discovery was implemented previously "own" way. There are some 
changes in javadoc and implementation has been refactored in order to 
use same code as is in JAX-B and SAAJ.


Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 + new 
tests specificaly developed for testing service discovery in JAX-WS.


Thanks
Miran

Re: [9] RFR: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API

[Miroslav Kos]

Hi again,
thanks for valuable feedback - I missed those before. Second version of 
a patch:

http://cr.openjdk.java.net/~mkos/8130753/jaxws.02/

issues addressed:

 *:  not backporting correctly changes done in jdk repo, will
   fix in standalone repos
 *   / {@code : added  again, in two cases used 
 *   copyright years : fixed


Otherwise I don't use -Xdoclint but I generate javadoc so I see warnings -
before patch:
10 errors
78 warnings

after patch:
78 warnings

I also used specdiff to doblecheck that there are no differences in 
output javadoc - those are classes defined by JSRs, so no changes are 
wanted without MR. Only 2 changes found (typos). Additional issues 
(warnings) would be addressed during MRs.


Thanks
Miran


On 08/07/15 18:36, joe darcy wrote:

Hi Miroslav,

At least some of the changes in the patch are going in the wrong 
direction. There are many instances toward the start of the patch 
where {@code Foo} is listed as being replaced by Foo, but 
{@code Foo} is what we want to use now.


Are you running doclint over Java source or in a docs build to verify 
the changes?


Thanks,

-Joe

On 7/8/2015 5:29 AM, Miroslav Kos wrote:

Hi everybody,
I'd like to ask for review for following issue:

JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B 
API, JAX-WS API, SAAJ-API

webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/

It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and 
JAX-WS and it is also syncup with standalone repos. This clean-up had 
to be done in order to proceed with changes necessary for Jigsaw 
(specifically SAAJ API and possibly JAX-WS).


Thanks
Miran

[9] RFR: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B API, JAX-WS API, SAAJ-API

[Miroslav Kos]

Hi everybody,
I'd like to ask for review for following issue:

JBS: 8130753: Sync-up javadoc changes in jax-ws area - includes JAX-B 
API, JAX-WS API, SAAJ-API

webrev: http://cr.openjdk.java.net/~mkos/8130753/jaxws.01/

It addresses all the javadoc errors in all 3 JSRs: SAAJ, JAX-B and 
JAX-WS and it is also syncup with standalone repos. This clean-up had to 
be done in order to proceed with changes necessary for Jigsaw 
(specifically SAAJ API and possibly JAX-WS).


Thanks
Miran

Re: RFR [9] 8072839: JAX-B Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi Alan, Daniel,
would you have some time to check the changes in this one?

Thanks a lot
Miran



On 27/05/15 00:50, Miroslav Kos wrote:


On 20/05/15 15:30, Daniel Fuchs wrote:

Hi Miroslav,

I haven't looked in all details, but this text in JAXBContext.java looks
odd to me - it seems that the bullet is repeated twice (or if they
differ - the diff must be subtle):

lines 241-257 seem identical to lines 259-275

 241  * 
 242  * Look for resource 
/META-INF/services/javax.xml.bind.JAXBContext using provided 
class loader.
 243  * Methods without class loader parameter use {@code 
Thread.currentThread().getContextClassLoader()}.
 244  * If such a resource exists, its content is assumed to be the 
provider factory class and must supply
 245  * an implementation class containing the following method 
signatures:

 246  *
 247  * 
 248  *
 249  * public static JAXBContext createContext(
 250  *  String contextPath,
 251  *  ClassLoader classLoader,
 252  * Map<String,Object> properties throws JAXBException
 253  *
 254  * public static JAXBContext createContext(
 255  *  Class[] classes,
 256  * Map<String,Object> properties ) throws JAXBException
 257  * 
 258  *
 259  * 
 260  * Look for resource 
/META-INF/services/javax.xml.bind.JAXBContext using provided 
class loader.
 261  * Methods without class loader parameter use {@code 
Thread.currentThread().getContextClassLoader()}.
 262  * If such a resource exists, its content is assumed to be the 
provider factory class and must supply
 263  * an implementation class containing the following method 
signatures:

 264  *
 265  * 
 266  *
 267  * public static JAXBContext createContext(
 268  *  String contextPath,
 269  *  ClassLoader classLoader,
 270  * Map<String,Object> properties throws JAXBException
 271  *
 272  * public static JAXBContext createContext(
 273  *  Class[] classes,
 274  * Map<String,Object> properties ) throws JAXBException
 275  * 

Hi Daniel,
thanks for catching this - obviously incorrectly applied patch.


So if I understand well - this is somewhat similar to what
ServiceLoader does in terms of lookup, except that the
mechanism defined here does not use an instance of the
declared class, nor require that the class declared in
/META-INF/services/javax.xml.bind.JAXBContext
is a subclass of JAXBContext - but simply that it defines
the appropriate static factory methods...
Yes, exactly. It is "ServiceLoader like" implementation from times 
when ServiceLoader wasn't in jdk yet (jdk5).


Maybe the fact that this step is deprecated should be noted more
prominently in the bullet itself.

I added a note mentioning that the step is deprecated.

Corrected version: http://cr.openjdk.java.net/~mkos/8072839/jaxws.03/
I also came over the changed files and added new lines to make lines 
shorter.


Thanks
Miran



best regards,

-- daniel

On 15/05/15 17:13, Miroslav Kos wrote:

Hi everybody,

this is review request for: 8072839: JAX-B Plugability Layer: using
java.util.ServiceLoader
The JAX-B API changed a little bit - proprietary ServiceLoader-like 
code
has been replaced by java.util.ServiceLoader. This change is 
required by

Jigsaw, old configuration way still supported.

JBS:https://bugs.openjdk.java.net/browse/JDK-8072839
webrev: http://cr.openjdk.java.net/~mkos/8072839/jaxws.02/index.html
CCC: http://ccc.us.oracle.com/8072839

Testing: JAX-WS (standalone) unit tests, no, jtreg tests available now,
TCK/JCK tests will require new tests.

Thanks
Miran

Re: RFR [9] 8072839: JAX-B Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 20/05/15 15:30, Daniel Fuchs wrote:

Hi Miroslav,

I haven't looked in all details, but this text in JAXBContext.java looks
odd to me - it seems that the bullet is repeated twice (or if they
differ - the diff must be subtle):

lines 241-257 seem identical to lines 259-275

 241  * 
 242  * Look for resource 
/META-INF/services/javax.xml.bind.JAXBContext using provided 
class loader.
 243  * Methods without class loader parameter use {@code 
Thread.currentThread().getContextClassLoader()}.
 244  * If such a resource exists, its content is assumed to be the 
provider factory class and must supply
 245  * an implementation class containing the following method 
signatures:

 246  *
 247  * 
 248  *
 249  * public static JAXBContext createContext(
 250  *  String contextPath,
 251  *  ClassLoader classLoader,
 252  * Map<String,Object> properties throws JAXBException
 253  *
 254  * public static JAXBContext createContext(
 255  *  Class[] classes,
 256  * Map<String,Object> properties ) throws JAXBException
 257  * 
 258  *
 259  * 
 260  * Look for resource 
/META-INF/services/javax.xml.bind.JAXBContext using provided 
class loader.
 261  * Methods without class loader parameter use {@code 
Thread.currentThread().getContextClassLoader()}.
 262  * If such a resource exists, its content is assumed to be the 
provider factory class and must supply
 263  * an implementation class containing the following method 
signatures:

 264  *
 265  * 
 266  *
 267  * public static JAXBContext createContext(
 268  *  String contextPath,
 269  *  ClassLoader classLoader,
 270  * Map<String,Object> properties throws JAXBException
 271  *
 272  * public static JAXBContext createContext(
 273  *  Class[] classes,
 274  * Map<String,Object> properties ) throws JAXBException
 275  * 

Hi Daniel,
thanks for catching this - obviously incorrectly applied patch.


So if I understand well - this is somewhat similar to what
ServiceLoader does in terms of lookup, except that the
mechanism defined here does not use an instance of the
declared class, nor require that the class declared in
/META-INF/services/javax.xml.bind.JAXBContext
is a subclass of JAXBContext - but simply that it defines
the appropriate static factory methods...
Yes, exactly. It is "ServiceLoader like" implementation from times when 
ServiceLoader wasn't in jdk yet (jdk5).


Maybe the fact that this step is deprecated should be noted more
prominently in the bullet itself.

I added a note mentioning that the step is deprecated.

Corrected version: http://cr.openjdk.java.net/~mkos/8072839/jaxws.03/
I also came over the changed files and added new lines to make lines 
shorter.


Thanks
Miran



best regards,

-- daniel

On 15/05/15 17:13, Miroslav Kos wrote:

Hi everybody,

this is review request for: 8072839: JAX-B Plugability Layer: using
java.util.ServiceLoader
The JAX-B API changed a little bit - proprietary ServiceLoader-like code
has been replaced by java.util.ServiceLoader. This change is required by
Jigsaw, old configuration way still supported.

JBS:https://bugs.openjdk.java.net/browse/JDK-8072839
webrev: http://cr.openjdk.java.net/~mkos/8072839/jaxws.02/index.html
CCC: http://ccc.us.oracle.com/8072839

Testing: JAX-WS (standalone) unit tests, no, jtreg tests available now,
TCK/JCK tests will require new tests.

Thanks
Miran

Re: RFR [9] 8080502: Changing accessing module resources

[Miroslav Kos]

On 21/05/15 14:34, Alan Bateman wrote:

On 19/05/2015 10:38, Miroslav Kos wrote:

:

JBS: https://bugs.openjdk.java.net/browse/JDK-8080502
webrev: http://cr.openjdk.java.net/~mkos/8080502/jaxws.01/index.html
testing: JAX-WS unit test; basically it is fix for existing tests 
(JCK, ...)
One thing that isn't obvious in this code is where the input streams 
are closed? Are they closed by whoever is consuming the input stream? 
Otherwise I don't see any issues.


-Alan
Thanks, you are correct. Changed to try-catch with resources, the some 
code moved to SchemaCache. Refernced resources found by 
com.sun.tools.internal.xjc.SchemaCache.ResourceResolver added to 
collection and closed after parsing.


updated webrev: http://cr.openjdk.java.net/~mkos/8080502/jaxws.02/
tests: rerun standalone tests for bot standalone build and for JDK.

Thanks
Miran

Re: RFR [9] 8072839: JAX-B Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

On 19/05/15 22:44, Alan Bateman wrote:

On 15/05/2015 16:13, Miroslav Kos wrote:

Hi everybody,

this is review request for: 8072839: JAX-B Plugability Layer: using 
java.util.ServiceLoader
The JAX-B API changed a little bit - proprietary ServiceLoader-like 
code has been replaced by java.util.ServiceLoader. This change is 
required by Jigsaw, old configuration way still supported.


JBS:https://bugs.openjdk.java.net/browse/JDK-8072839
webrev: http://cr.openjdk.java.net/~mkos/8072839/jaxws.02/index.html
I skimmed through this and it mostly looks okay. Some really long 
(200+) lines but that seems to be normal in this area. At some point 
it would be good to do a wider pass over this code and replace the old 
style tags ( etc.) with newer forms.


In JAXBContext it looks likes a typo "loading facilities" when I 
assume it should be "loading facility".


Are there any new tests for this? Existing tests will exercise some of 
this but I don't see any tests that will exercise JAXBContextFactory.


-Alan.
Thanks for checking - would you be ok with addressing javadoc later? Of 
course, typo can be fixed easily right away ...


Regarding tests - I created new tests for many different setup 
combination, but they require environment setup (property files in jdk 
conf dir, java.util.ServiceLoader descriptors, System property). The 
tests are using bash scipting (testing different env combinations) and I 
don't have currently jtreg version of those. To test the glassfish part, 
I ran glassfish smoke tests.


Thanks
Miran

RFR [9] 8080502: Changing accessing module resources

[Miroslav Kos]

Hi everybody,

this is a review request for 8080502: Changing accessing module resources.

This change adapts to Jigsaw JDK runtime - it isn't possible to access 
module resource using Class::getResource() any more.


JBS: https://bugs.openjdk.java.net/browse/JDK-8080502
webrev: http://cr.openjdk.java.net/~mkos/8080502/jaxws.01/index.html
testing: JAX-WS unit test; basically it is fix for existing tests (JCK, ...)

Thanks
Miran

RFR [9] 8072839: JAX-B Plugability Layer: using java.util.ServiceLoader

[Miroslav Kos]

Hi everybody,

this is review request for: 8072839: JAX-B Plugability Layer: using 
java.util.ServiceLoader
The JAX-B API changed a little bit - proprietary ServiceLoader-like code 
has been replaced by java.util.ServiceLoader. This change is required by 
Jigsaw, old configuration way still supported.


JBS:https://bugs.openjdk.java.net/browse/JDK-8072839
webrev: http://cr.openjdk.java.net/~mkos/8072839/jaxws.02/index.html
CCC: http://ccc.us.oracle.com/8072839

Testing: JAX-WS (standalone) unit tests, no, jtreg tests available now, 
TCK/JCK tests will require new tests.


Thanks
Miran

Re: RFR: 8061293: Update javax/xml tests to remove references of jre dir

[Miroslav Kos]

Looks ok to me.

Thanks
Miran


On 05/03/15 08:30, Frank Yuan wrote:


Hi All

Would you like to review the code change for bug: 
https://bugs.openjdk.java.net/browse/JDK-8061293, this is a Jigsaw 
related bug, it's to clean up the reference to "jre" dir.


webrev: http://cr.openjdk.java.net/~fyuan/8061293/webrev/ 



Best Regards

Frank

Re: Review request 8057645: Deprivilege JAX-WS, JAXB, JAF to extension class loader

[Miroslav Kos]

On 26/01/15 21:55, Alan Bateman wrote:

On 26/01/2015 19:23, Mandy Chung wrote:

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8057645/webrev.00/

This patch proposes to move java.xml.ws, java.xml.bind, 
java.activation out of the boot loader and be loaded by the extension 
class loader.  We grant java.xml.ws and java.xml.bind the minimum set 
of permissions.  java.activation hasAllPermission for now and that 
can be revised in the future when JAF team identifies the permission 
set required java.activation.


Miroslav - can you confirm if the JAX-WS and JAXB standalone tests 
pass with this patch?

Yes, the tests are passing with our current configuration. Looks ok to me.

Thanks
Miran



Existing code that assumes the defining class loader of JAX-WS, JAXB, 
JAF classes may be impacted by this change (e.g. the class loader 
delegation to the bootstrap class loader skipping the extension class 
loader).  They are standalone technologies that used to be loaded by 
non-null class loader before they were included in Java SE.  It 
should be rare of such dependency. Callbacks may assume java.xml.ws 
and java.xml.bind classes to have AllPermissions so that when running 
with security manager, if the permission required for callback is not 
part of the permission set granted to java.xml.ws and java.xml.bind, 
SecurityException will be thrown.  We need customer testings to 
identify this callback permission case and revisit if they should be 
granted with AllPermission for JDK 9.
The changes looks good and will be interested to see if anyone is 
running JAX-WS and JAXB with a security manager willing to try out JDK 
9 builds.


-Alan.

Re: RFR: 8071585: Update JAX-WS RI integration to latest version (2.2.11-b150127.1410)

[Miroslav Kos]

On 29/01/15 16:06, Alan Bateman wrote:

On 29/01/2015 14:51, Aleksej Efimov wrote:

Hi,
Can I have a review for a bulk update of JAX-B/WS from upstream 
projects -

webrev: http://cr.openjdk.java.net/~aefimov/8071585/webrev/
more details in JBS: https://bugs.openjdk.java.net/browse/JDK-8071585

There is a lot of changes (947 lines) but almost all of them are 
minor (comments changes/(c) years)


Thank you,
Aleksej

I see several changes where ">"is replaced by ">" in pre-formatted 
text (looks like < was changed to < at some point in the past).
Hi Alan, thanks for catching this, we'll fix that. Is it ok to fix it in 
the next (in a month) bulk update?


Miran


This is probably a question for the upstream projects but I would 
think {@code ..} would make the source much easier to read.


-Alan.

Re: Review request 8057645: Deprivilege JAX-WS, JAXB, JAF to extension class loader

[Miroslav Kos]

On 26/01/15 20:23, Mandy Chung wrote:

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8057645/webrev.00/

This patch proposes to move java.xml.ws, java.xml.bind, 
java.activation out of the boot loader and be loaded by the extension 
class loader.  We grant java.xml.ws and java.xml.bind the minimum set 
of permissions.  java.activation hasAllPermission for now and that can 
be revised in the future when JAF team identifies the permission set 
required java.activation.


Miroslav - can you confirm if the JAX-WS and JAXB standalone tests 
pass with this patch?

Hi Mandy,

I just ran standalone JAX-WS tests and without SM results are ok, with 
SM enabled I will need some more time - our WS-harness (test framework) 
requires some permissions too so I'll need to investigate which ones are 
those. Up to now, we used single policy file which was union of 
permissions requred by WS-harness + JAX-WS runtime.


I'll ping you when have more results.
For JAX-B, we are currently unable to run standalone tests against JDK.

Thanks
Miran

Existing code that assumes the defining class loader of JAX-WS, JAXB, 
JAF classes may be impacted by this change (e.g. the class loader 
delegation to the bootstrap class loader skipping the extension class 
loader).  They are standalone technologies that used to be loaded by 
non-null class loader before they were included in Java SE.  It should 
be rare of such dependency. Callbacks may assume java.xml.ws and 
java.xml.bind classes to have AllPermissions so that when running with 
security manager, if the permission required for callback is not part 
of the permission set granted to java.xml.ws and java.xml.bind, 
SecurityException will be thrown. We need customer testings to 
identify this callback permission case and revisit if they should be 
granted with AllPermission for JDK 9.


Mandy

Re: RFR: 8065870 Update JAX-WS RI integration to latest version (2.2.11-b141124.1933)

[Miroslav Kos]

Hi Stuart,
minor stuff like invalid characters and copyright years I can fix before 
push, the rest will leave for next integration which should be soon.


Thanks!
Miran



On 01/12/14 20:35, Stuart Marks wrote:

Hi Miran,

I'm pretty distant from the JAX-WS code, but I looked through all of 
the files and most of the changes seem sensible. There are a few 
things that are questionable though.


** 
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java


The catch-and-ignore of Throwable at line 565 seems questionable. 
Wouldn't it be better to catch a few specific exception types that 
might be thrown from setProperty()?


** 
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties


The copyright year is changed from 2013 to 2012.

The unknown character replacement (line 277) is replaced with a '?', 
though I'm not sure what's really happening here since webrev might be 
mishandling non-ascii characters. If this is intended to be an ascii 
file, shouldn't the replacement be a plain single quote (') ?


** 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties


The version numbers in this file seem to be moved forward, but the 
copyright is updated from 2014 to 2012. The same appears to be true of 
the localized versions of this file.


** 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties


Copyright years 2014 => 2012 again. Also check localized versions of 
this file.


** 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties


Copyright years 2013 => 2012. Possibly incorrect replacement "???" for 
unknown character in original file.


** 
src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties


Copyright years 2014 => 2013.

==

Nothing earth-shattering here. If you want to push this changeset and 
fix up these issues later (if indeed they need to be fixed up), I'd be 
fine with that.


s'marks





On 11/27/14 3:27 AM, Miroslav Kos wrote:

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8065870/jaxws.00/
more details in issue desc: 
https://bugs.openjdk.java.net/browse/JDK-8065870


Could I ask for a review?

It seems quite big (1126 lines changed) but there are just minor 
changes/fixes.


Thanks
Miran

RFR: 8065870 Update JAX-WS RI integration to latest version (2.2.11-b141124.1933)

[Miroslav Kos]

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8065870/jaxws.00/
more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8065870

Could I ask for a review?

It seems quite big (1126 lines changed) but there are just minor 
changes/fixes.


Thanks
Miran

Re: RFR: 8046817: JDK 8 schemagen tool does not generate xsd files for enum types

[Miroslav Kos]

Hi Aleksej,

the change looks ok to me, but it would be good to integrate it into 
upstream (standalone JAX-B RI project) first to be on safe side - there 
are much more tests then in OpenJDK.


Copying Iaroslav who is JAX-B RI lead and can help you with integration 
and running tests.


Thanks
Miran


On 14/10/14 09:29, Aleksej Efimov wrote:

Hi XML experts,
Can I humbly ask  to review this simple fix.

Thank you,
Aleksej

On 08.10.2014 13:09, Aleksej Efimov wrote:

Hello,

Please, review the fix [1] for the 8046817 [2].
Problem: schemagen tool doesn't generate schema file for the enum 
types [3].
SchemaGenerator class gets a list of annotated elements and filters 
out only the class variables, but annotation parser 
(AnnotationParser.java) filters out the Class and Enum. The proposed 
fix solves the problem: SchemaGenerator filters like AnnotationParser.
Testing: JPRT build and test passes on platforms (with new regression 
test). JTREG tests: javax/xml - no failures.


Thanks,
Aleksej

[1] Webrev: http://cr.openjdk.java.net/~aefimov/8046817/9/webrev.00/
[2] Bug: https://bugs.openjdk.java.net/browse/JDK-8046817
[3] Enum type: 
http://cr.openjdk.java.net/~aefimov/8046817/9/webrev.00/jdk/test/javax/xml/ws/8046817/TestEnumType.java.html

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

[Miroslav Kos]

The problem was in line endings. The updated webrev for test:
http://cr.openjdk.java.net/~mkos/8038966/jdk.04/

Thanks
Miran


On 19/09/14 17:42, Seán Coffey wrote:

Miran,

thanks for the update. Seems like you're working from an old JDK 9 
forest. The webrev is
using the pre-modular path layout. I've converted them. I'm am seeing 
the new test fail

on windows though. Will share the details with you offline.

regards,
Sean.

On 18/09/14 16:22, Miroslav Kos wrote:

Ok then, the webrev updated:
http://cr.openjdk.java.net/~mkos/8038966/jdk.03/
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/

btw. I had to tweak the path - using simply Paths.get("org") we get
JTwork/scratch/org
but needed path is
JTwork/classes/javax/xml/ws/xsanymixed/org
(classes instead of scratch + test path as prefix), so I changed the 
code to
Path p = Paths.get("..", "classes", "javax", "xml", "ws", 
"xsanymixed", "org");


Thanks
Miran


On 18/09/14 14:01, Seán Coffey wrote:
jtreg should remove the work/scratch directory upon test completion 
but it's best practice to attempt to clean up generated files. No 
harm there I think. Also needed in cases where test might be run 
manually. I'd suggest keeping the clean up code in the testcase.


regards,
Sean.

On 18/09/2014 12:29, Miroslav Kos wrote:
Oops, I missed that, thanks. One question yet - does it make sense 
any more to clean generated files now, when the location was 
changed? I think clean up should be done automatically by jtreg 
now, shouldn't it? If you agree, I would delete the method instead.


Thanks
Miran

On 18/09/14 11:49, Seán Coffey wrote:


On 18/09/2014 10:12, Miroslav Kos wrote:

Thanks, Sean, good catch ...

I changed the destination for generated files:
http://cr.openjdk.java.net/~mkos/8038966/jdk.02/

Regarding usage ProcessBuilder instead of shell script - the 
problem is, that to compile test classes, wsdl must be compiled 
first - shell script is setup required before javac. The test 
would have to be run in two phases - first compiling+running java 
classes that compile wsdl (ProcessBuilder) and after that 
compiling other java classes using result of previous run.


I was solving this with jtreg some time ago already, but I 
haven't found other way than using shell script. If you know 
better solution, it would be great ...

Ah - I see the dependency now. Thanks for the information.

Just spotted one other issue. The deleteGeneratedFiles() method 
scans for files in the
test src path (for deletion) - No files should be created there 
now. You can change that
to scan the test classes path now. You could just use the current 
working directory I guess

since that's where jtreg will generate the new files.

Paths.get("org");

once that's fixed up, I can run this through JPRT and it should be 
good to push then.


regards,
Sean.



Thanks
Miran



On 17/09/14 16:16, Seán Coffey wrote:

Miran,

the src change looks ok but I think there's a problem with the 
testcase.


You've defined generated classes for wsimport to be output to 
the TESTSRC

directory. This is often read only and won't work.

TESTCLASSES is the variable you're probably looking for. In any 
case, I think
it's possible for you to avoid use of scripting. Can you invoke 
wsimport via

the ProcessBuilder API like that done for other wsimport tests ?

regards,
Sean.

On 17/09/14 14:00, Miroslav Kos wrote:

Hi everybody,

please review patch fixing following issue:

JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
webrev:
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
http://cr.openjdk.java.net/~mkos/8038966/jdk.01/

It is second part of fix ensuring that content of type 
xsd:any/content=mixed stays unchanged when processed with JAX-B 
RI. Regression test within webrev.


Sean, could you sponsor it for me?

Thanks
Miran

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

[Miroslav Kos]

Ok then, the webrev updated:
http://cr.openjdk.java.net/~mkos/8038966/jdk.03/
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/

btw. I had to tweak the path - using simply Paths.get("org") we get
JTwork/scratch/org
but needed path is
JTwork/classes/javax/xml/ws/xsanymixed/org
(classes instead of scratch + test path as prefix), so I changed the 
code to
Path p = Paths.get("..", "classes", "javax", "xml", "ws", 
"xsanymixed", "org");


Thanks
Miran


On 18/09/14 14:01, Seán Coffey wrote:
jtreg should remove the work/scratch directory upon test completion 
but it's best practice to attempt to clean up generated files. No harm 
there I think. Also needed in cases where test might be run manually. 
I'd suggest keeping the clean up code in the testcase.


regards,
Sean.

On 18/09/2014 12:29, Miroslav Kos wrote:
Oops, I missed that, thanks. One question yet - does it make sense 
any more to clean generated files now, when the location was changed? 
I think clean up should be done automatically by jtreg now, shouldn't 
it? If you agree, I would delete the method instead.


Thanks
Miran

On 18/09/14 11:49, Seán Coffey wrote:


On 18/09/2014 10:12, Miroslav Kos wrote:

Thanks, Sean, good catch ...

I changed the destination for generated files:
http://cr.openjdk.java.net/~mkos/8038966/jdk.02/

Regarding usage ProcessBuilder instead of shell script - the 
problem is, that to compile test classes, wsdl must be compiled 
first - shell script is setup required before javac. The test would 
have to be run in two phases - first compiling+running java classes 
that compile wsdl (ProcessBuilder) and after that compiling other 
java classes using result of previous run.


I was solving this with jtreg some time ago already, but I haven't 
found other way than using shell script. If you know better 
solution, it would be great ...

Ah - I see the dependency now. Thanks for the information.

Just spotted one other issue. The deleteGeneratedFiles() method 
scans for files in the
test src path (for deletion) - No files should be created there now. 
You can change that
to scan the test classes path now. You could just use the current 
working directory I guess

since that's where jtreg will generate the new files.

Paths.get("org");

once that's fixed up, I can run this through JPRT and it should be 
good to push then.


regards,
Sean.



Thanks
Miran



On 17/09/14 16:16, Seán Coffey wrote:

Miran,

the src change looks ok but I think there's a problem with the 
testcase.


You've defined generated classes for wsimport to be output to the 
TESTSRC

directory. This is often read only and won't work.

TESTCLASSES is the variable you're probably looking for. In any 
case, I think
it's possible for you to avoid use of scripting. Can you invoke 
wsimport via

the ProcessBuilder API like that done for other wsimport tests ?

regards,
Sean.

On 17/09/14 14:00, Miroslav Kos wrote:

Hi everybody,

please review patch fixing following issue:

JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
webrev:
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
http://cr.openjdk.java.net/~mkos/8038966/jdk.01/

It is second part of fix ensuring that content of type 
xsd:any/content=mixed stays unchanged when processed with JAX-B 
RI. Regression test within webrev.


Sean, could you sponsor it for me?

Thanks
Miran

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

[Miroslav Kos]

Oops, I missed that, thanks. One question yet - does it make sense any 
more to clean generated files now, when the location was changed? I 
think clean up should be done automatically by jtreg now, shouldn't it? 
If you agree, I would delete the method instead.


Thanks
Miran

On 18/09/14 11:49, Seán Coffey wrote:


On 18/09/2014 10:12, Miroslav Kos wrote:

Thanks, Sean, good catch ...

I changed the destination for generated files:
http://cr.openjdk.java.net/~mkos/8038966/jdk.02/

Regarding usage ProcessBuilder instead of shell script - the problem 
is, that to compile test classes, wsdl must be compiled first - shell 
script is setup required before javac. The test would have to be run 
in two phases - first compiling+running java classes that compile 
wsdl (ProcessBuilder) and after that compiling other java classes 
using result of previous run.


I was solving this with jtreg some time ago already, but I haven't 
found other way than using shell script. If you know better solution, 
it would be great ...

Ah - I see the dependency now. Thanks for the information.

Just spotted one other issue. The deleteGeneratedFiles() method scans 
for files in the
test src path (for deletion) - No files should be created there now. 
You can change that
to scan the test classes path now. You could just use the current 
working directory I guess

since that's where jtreg will generate the new files.

Paths.get("org");

once that's fixed up, I can run this through JPRT and it should be 
good to push then.


regards,
Sean.



Thanks
Miran



On 17/09/14 16:16, Seán Coffey wrote:

Miran,

the src change looks ok but I think there's a problem with the 
testcase.


You've defined generated classes for wsimport to be output to the 
TESTSRC

directory. This is often read only and won't work.

TESTCLASSES is the variable you're probably looking for. In any 
case, I think
it's possible for you to avoid use of scripting. Can you invoke 
wsimport via

the ProcessBuilder API like that done for other wsimport tests ?

regards,
Sean.

On 17/09/14 14:00, Miroslav Kos wrote:

Hi everybody,

please review patch fixing following issue:

JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
webrev:
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
http://cr.openjdk.java.net/~mkos/8038966/jdk.01/

It is second part of fix ensuring that content of type 
xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
Regression test within webrev.


Sean, could you sponsor it for me?

Thanks
Miran

Re: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

[Miroslav Kos]

Thanks, Sean, good catch ...

I changed the destination for generated files:
http://cr.openjdk.java.net/~mkos/8038966/jdk.02/

Regarding usage ProcessBuilder instead of shell script - the problem is, 
that to compile test classes, wsdl must be compiled first - shell script 
is setup required before javac. The test would have to be run in two 
phases - first compiling+running java classes that compile wsdl 
(ProcessBuilder) and after that compiling other java classes using 
result of previous run.


I was solving this with jtreg some time ago already, but I haven't found 
other way than using shell script. If you know better solution, it would 
be great ...


Thanks
Miran



On 17/09/14 16:16, Seán Coffey wrote:

Miran,

the src change looks ok but I think there's a problem with the testcase.

You've defined generated classes for wsimport to be output to the TESTSRC
directory. This is often read only and won't work.

TESTCLASSES is the variable you're probably looking for. In any case, 
I think
it's possible for you to avoid use of scripting. Can you invoke 
wsimport via

the ProcessBuilder API like that done for other wsimport tests ?

regards,
Sean.

On 17/09/14 14:00, Miroslav Kos wrote:

Hi everybody,

please review patch fixing following issue:

JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
webrev:
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
http://cr.openjdk.java.net/~mkos/8038966/jdk.01/

It is second part of fix ensuring that content of type 
xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
Regression test within webrev.


Sean, could you sponsor it for me?

Thanks
Miran

[9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web services

[Miroslav Kos]

Hi everybody,

please review patch fixing following issue:

JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
webrev:
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
http://cr.openjdk.java.net/~mkos/8038966/jdk.01/

It is second part of fix ensuring that content of type 
xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
Regression test within webrev.


Sean, could you sponsor it for me?

Thanks
Miran

Re: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with modular image

[Miroslav Kos]

On 12/09/14 11:51, Alan Bateman wrote:

On 12/09/2014 09:39, Miroslav Kos wrote:
I agree that the code looks scary, but it's because we have to 
support range of jdk (currently jdk6 to jdk9) and we want to avoid 
maintaining several branches. The standalone project must work even 
with jdk6. The magic here is to make the latest JAX-WS working with 
jdk6.
1.6 contain old JAX-B/WS API versions (2.1) and this tricky code 
allows to load newer (2.2) javax.xml.* classes from jars on classpath 
(without having to use java endorsed mechanism) when running 
standalone JAX-WS on the top of JDK6. Hope it is not too confusing.
Once we are further along with modules in the JDK 9 then I expect that 
-Xbootclasspath/p will go away (to be replaced by an alternative 
facility to override the classes in modules that are linked into the 
runtime image).  So is this wsgen and wsimport code only used with JDK 
6? Maybe that is okay but at the same time I would hope these APIs 
could leave JDK 6 behind some day, otherwise it makes it impossible to 
use language features and APIs.
This code is currently used for all the jdk versions, but works well 
with all of them (including modularized build) - it should create own 
modified class loader only when necessary. After dropping jdk6 support 
we would simplify the code. Unfortunately we can't simply use the newest 
language features, we may start using them with some delay (several 
steps behind the newest JDK) not to break the older (yet) supported jdks.




Anyway I found some more code to cleanup - one more class can be 
removed - see version 2:

http://cr.openjdk.java.net/~mkos/8054548/jaxws.01/

The update looks okay to me. I guess we'll have to see if other 
changes are required as we move forward. Also thanks for the 
explanation about JavacompilerMessages.java being auto-generated, 
there isn't anything in the header that makes this obvious (maybe the 
plugin that you mentioned could be updated to generate something into 
the header?).
Yes, you're right, some javadoc saying that would be helpful. I'll keep 
it in mind and will update the plugin. If you are ok with it, I would 
proceed with this change as it is for now and improved generated classes 
would go into jdk9 with next regular sync integration.


Thanks
Miran


-Alan.

Re: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with modular image

[Miroslav Kos]

On 11/09/14 14:39, Alan Bateman wrote:

On 11/09/2014 12:20, Miroslav Kos wrote:

Hello,
please review following change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8054548
webrev: http://cr.openjdk.java.net/~mkos/8054548/jaxws.00/

It is basically replacing obsolete code using core reflection by 
javax.tools API plus removing old unused code.

Thanks for doing this, it's good to get this cleaned up.

The changes looks reasonable but I wonder if they are complete. I ask 
because I assumed that JavaCompilerHelper.getJarFile would be removed. 
Also there appears to be a bit of skullduggery in both wsimport and 
wsgen involving -Xbootclasspath/p where it might be assuming that the 
JAXB or JAX-WS classes are being loaded from JAR files (I didn't did 
into ParallelWorldClassLoader.toJarUrl so perhaps it can deal with 
other URLs).
I agree that the code looks scary, but it's because we have to support 
range of jdk (currently jdk6 to jdk9) and we want to avoid maintaining 
several branches. The standalone project must work even with jdk6. The 
magic here is to make the latest JAX-WS working with jdk6.
1.6 contain old JAX-B/WS API versions (2.1) and this tricky code allows 
to load newer (2.2) javax.xml.* classes from jars on classpath (without 
having to use java endorsed mechanism) when running standalone JAX-WS on 
the top of JDK6. Hope it is not too confusing.


Anyway I found some more code to cleanup - one more class can be removed 
- see version 2:

http://cr.openjdk.java.net/~mkos/8054548/jaxws.01/

In passing, I assume the comments in Invoker should use "ClassLoader" 
or "class loader". 

fixed.

Also the comment in createClassLoader mentions JAXB/WS 2.1 and not 
clear how this relates to the method description where it talked about 
2.2


In JavacompilerMessages then noJavaCompilerError() and 
localizedNoJavaCompilerError() might be nicer names (in case you are 
looking for something better).
Those are generated methods from resource bundle using maven plugin. I 
think we own the plugin, but I would need to dive into it little bit, 
not sure if it is worth it.


M.



-Alan.

[9] RFR: JDK-8054548: JAX-WS tools need to updated to work with modular image

[Miroslav Kos]

Hello,
please review following change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8054548
webrev: http://cr.openjdk.java.net/~mkos/8054548/jaxws.00/

It is basically replacing obsolete code using core reflection by 
javax.tools API plus removing old unused code.


I ran the unit tests against both standalone JAX-WS and jdk, no 
regressions occurred.


Thanks
Miran

Re: RFR: 8047724: @since tag cleanup in jaxws

[Miroslav Kos]

Hi Henry,
sorry for no response, I missed this one.

Yes, this looks reasonable. You can proceed with the change, I'll 
integrate it into upstream projects.


Thanks
Miran




On 28/07/14 11:11, Henry Jen wrote:

Hi Micoslav,

What do you think about the webrev[1]? Does it make sense for upstream 
maintainers?


[1] http://cr.openjdk.java.net/~henryjen/jdk9/8047724/0/webrev/

Cheers,
Henry


On 06/30/2014 03:14 PM, Alan Bateman wrote:

On 30/06/2014 02:30, Henry Jen wrote:

Ping.

Cheers,
Henry

Henry - the code in the jaxws repository is maintained upstream. If you
change it in the jaxws repository then the changes will likely get
overridden at the next sync-up. I'd suggest working with Miroslav
(cc'ed) to get the changes pushed upstream first.

-Alan.

Re: [9] RFR 8038970: Deprivilege JAX-WS/JAF code

[Miroslav Kos]

Good catch Mandy, thanks!

updated webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.06/
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970

Added JAF files (overwritten during integration from upstream), removed 
throws/catch(es) in XMLStreamWriterFactory.


Thanks
Miran

On 17/07/14 18:02, Mandy Chung wrote:


On 7/17/2014 8:12 AM, Miroslav Kos wrote:

Hi everybody,
here is a request for review for

8038970: Deprivilege JAX-WS/JAF code
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970
webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/
 

FYI. The href at the above links were wrong.

com/sun/xml/internal/ws/api/streaming/XMLStreamWriterFactory.java
line 309: it's fine wrapping with NoSuchMethodError and
you can take out throws NoSuchMethodException from line 292

Did you miss JAF classes?

As a background, this patch is to prepare for granting minimal set
of permissions.

Mandy

This is first part of changes - after this also jdk build will have 
to be changed.
Changeset has been already discussed during testing phase with Sean 
Mullan and Mandy Chung.


Thanks
Miran 

[9] RFR 8038970: Deprivilege JAX-WS/JAF code

[Miroslav Kos]

Hi everybody,
here is a request for review for

8038970: Deprivilege JAX-WS/JAF code
JBS: https://bugs.openjdk.java.net/browse/JDK-8038970
webrev: http://cr.openjdk.java.net/~mkos/8038970/jaxws.04/

This is first part of changes - after this also jdk build will have to 
be changed.
Changeset has been already discussed during testing phase with Sean 
Mullan and Mandy Chung.


Thanks
Miran

Re: RFR: 8044656: Update JAX-WS RI integration to latest version

[Miroslav Kos]

Hi Joe,

thanks for comments - see inline:

On 08/07/14 01:02, huizhe wang wrote:

Hi Miran,

In class src/share/jaxws_classes/com/sun/tools/internal/xjc/Options.java:
+// hack to force initialization so catalog manager system 
properties take effect

+staticManager.getVerbosity();
According to Iaroslav (JAXB lead), the initilization is necessary. It 
looks like system property is used only if initialization performed via 
getter.


Is that necessary?  I thought the next call to getCatalog would 
initialize the properties from the CatalogManager property file.


Using ServiceLoader in class 
src/share/jaxws_classes/javax/xml/ws/spi/Provider.java:
Would you need to give the process privilege?  Or maybe the method is 
already called in a privileged block?
I think it doesn't - the previous version was exactly same, the only 
difference was that it was called via reflection.


M.



Thanks,
Joe

On 6/30/2014 9:22 AM, Miroslav Kos wrote:

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8044656/jaxws.00/
more details in issue desc: 
https://bugs.openjdk.java.net/browse/JDK-8044656


Could I ask for a review/approval?

Thanks
Miran

RFR: 8044656: Update JAX-WS RI integration to latest version

[Miroslav Kos]

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8044656/jaxws.00/
more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8044656

Could I ask for a review/approval?

Thanks
Miran

Re: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail

[Miroslav Kos]

Hi Hajo,
I agree with you, this issue means major loss of functionality. I 
already started processing backport to jdk8 and after that will continue 
with jdk7.


Thanks
Miran


On 26/05/14 18:50, i...@kliemeck.de wrote:

Hey Miroslav,

is this correct that the issue will be fixed on jdk9 only (as stated 
on https://bugs.openjdk.java.net/browse/JDK-8043129). Since this is a 
major loss of functionality which we encountered too, this should be 
fixed with the next jdk 7 release.


Regards
Hajo

Quoting miroslav@oracle.com:


Hi,
this is review request for:

8043129: JAF initialisation in SAAJ clashing with the one in javax.mail

JBS: https://bugs.openjdk.java.net/browse/JDK-8043129
WEBREV:
http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/
http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test)

This solves conflict between JAF handlers for JAX-WS and javax.mail. The
issue has been introduced in the latest CPU.

Thanks
Miran

RFR: 8043762: Remove unused files from jaxws repository

[Miroslav Kos]

Hi everybody,

here is the request for review for

8043762: Remove unused files from jaxws repository
JBS: https://bugs.openjdk.java.net/browse/JDK-8043762
webrev: http://cr.openjdk.java.net/~mkos/8043762/jaxws.01/

Simple fix removing unused files in jaxws repo, no tests necessary.

Thanks
Miran

Re: RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail

[Miroslav Kos]

Hi Chris,
thanks for pointing - I forgot to add copyright. Will fix.

Regarding jar attachment - this is a slightly modified version of test 
as received from customer. If there is any mechanism allowing to use 
maven artifact (I am not aware of it) with jprt, it would be definitelly 
better solution, but I didn't find it.


I could rewrite the test that it would test just not adding this 
handler, but it wouldn't explain much what the issue was about - I could 
write it to javadoc?


Let me know, what you think.

Thanks
Miran

On 19/05/14 19:27, Chris Hegarty wrote:

Miran,

The source change looks ok to me. Have you commented out the line 
adding the handler because it may be reinstated, or as a reminder that 
it was deliberately omitted?


The test, at the very minimum, will need a suitable copyright header. 
I also wonder if there is any other way of testing this issue without 
adding, what appears to be, a large jar file.


-Chris.

On 19/05/14 14:36, Miroslav Kos wrote:

Hi,
this is review request for:

8043129: JAF initialisation in SAAJ clashing with the one in javax.mail

JBS: https://bugs.openjdk.java.net/browse/JDK-8043129
WEBREV:
http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/
http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test)

This solves conflict between JAF handlers for JAX-WS and javax.mail. The
issue has been introduced in the latest CPU.

Thanks
Miran

RFR: 8043129: JAF initialisation in SAAJ clashing with the one in javax.mail

[Miroslav Kos]

Hi,
this is review request for:

8043129: JAF initialisation in SAAJ clashing with the one in javax.mail

JBS: https://bugs.openjdk.java.net/browse/JDK-8043129
WEBREV:
http://cr.openjdk.java.net/~mkos/8043129/jaxws.00/
http://cr.openjdk.java.net/~mkos/8043129/jdk.00/ (test)

This solves conflict between JAF handlers for JAX-WS and javax.mail. The 
issue has been introduced in the latest CPU.


Thanks
Miran

RFR: 8039210: Fix type error in DefaultResourceInjector

[Miroslav Kos]

Hi,
this is review request for:

8039210: Fix type error in DefaultResourceInjector

JBS: https://bugs.openjdk.java.net/browse/JDK-8039210
WEBREV: http://cr.openjdk.java.net/~mkos/8039210/jaxws.00/

It is simple one-line fix; it's blocker for another issue.

Thanks
Miran

RFR: 8040754: Break the circular dependency between SAAJ and JAXB

[Miroslav Kos]

Hi,

this is review request for: 8040754: Break the circular dependency 
between SAAJ and JAXB

JBS: https://bugs.openjdk.java.net/browse/JDK-8040754
WEBREV: http://cr.openjdk.java.net/~mkos/8040754/jaxws.01/

It is basically moving classes in order to fix dependency between SAAJ, 
JAX-B and JAX-WS.


Mandy, if it is approved, could I ask you for sponsoring the change?

Thanks
Miran

RFR: 8039899: Missing licence headers in test for JDK-8033113

[Miroslav Kos]

Hi,
please review the following change - this is just missing license 
headers fix -


8039899: Missing licence headers in test for JDK-8033113
JBS: https://bugs.openjdk.java.net/browse/JDK-8039899
WEBREV: http://cr.openjdk.java.net/~mkos/8039899/jdk.01/

Chris, may I ask you to push it to jdk9u-dev?

Thanks
Miran

RFR: 8033113: wsimport fails on WSDL:header parameter name customization

[Miroslav Kos]

Hi,
I'd like to ask for approval and sponsoring fix for following issue (escalation 
from customer):

  JBS: https://bugs.openjdk.java.net/browse/JDK-8033113
BugDB: https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=17348912

jaxws changeset: http://cr.openjdk.java.net/~mkos/8033113/jaxws.01/
  jdk reg tests: http://cr.openjdk.java.net/~mkos/8033113/jdk.01/

This fix addresses situation when there are conflicting parameter names 
(wsimport fails) and those need to be customized.


Thanks
Miran

Re: RFR: tests for JDK-8032884

[Miroslav Kos]

Hi Chris,
the test moved: http://cr.openjdk.java.net/~mkos/8032884/jdk.02/

Thanks
Miran



On 02/04/14 15:47, Chris Hegarty wrote:

On 02/04/14 14:32, Miroslav Kos wrote:

In the test, I need to do following steps:

1. compile schema file using xjc tool
2. compile generated sources
3. load generated class and via reflection API verify generated methods


In which case, what you have is fine then.


Although I know how to run tool directly from the test, it seems to me
not very elegant to run compiler directly from the test - or is there
other way how to compile generated sources from the test?

Regrading moving test - no problem, but I would suggest
javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you
agree?


Agreed.

-Chris.



Thanks
Miran



On 01/04/14 18:50, Chris Hegarty wrote:

The tests looks fine to me.

Trivially, you could eliminate the shell script and run xic from
ProcessBuilder?

Also, does it make sense to move the test to
jdk/test/javax/xml/ws/xjc? With the other jaxws tests, or is xjc
different.

-Chris,.

On 1 Apr 2014, at 16:21, Miroslav Kos  wrote:


Hi everybody,

I'd like to ask for review of following tests:
http://cr.openjdk.java.net/~mkos/8032884/jdk.01/

Original bug (already fixed): Bug:
https://bugs.openjdk.java.net/browse/JDK-8032884
Issue fixing the bug (bulk update):
https://bugs.openjdk.java.net/browse/JDK-8036030

The test verifies the source code generated by xjc tool.

Thanks
Miran

Re: RFR: tests for JDK-8032884

[Miroslav Kos]

In the test, I need to do following steps:

1. compile schema file using xjc tool
2. compile generated sources
3. load generated class and via reflection API verify generated methods

Although I know how to run tool directly from the test, it seems to me 
not very elegant to run compiler directly from the test - or is there 
other way how to compile generated sources from the test?


Regrading moving test - no problem, but I would suggest 
javax/xml/bind/xjc in this case - xjc is JAXB tool, not JAX-WS. Do you 
agree?


Thanks
Miran



On 01/04/14 18:50, Chris Hegarty wrote:

The tests looks fine to me.

Trivially, you could eliminate the shell script and run xic from ProcessBuilder?

Also, does it make sense to move the test to jdk/test/javax/xml/ws/xjc? With 
the other jaxws tests, or is xjc different.

-Chris,.

On 1 Apr 2014, at 16:21, Miroslav Kos  wrote:


Hi everybody,

I'd like to ask for review of following tests:
http://cr.openjdk.java.net/~mkos/8032884/jdk.01/

Original bug (already fixed): Bug: 
https://bugs.openjdk.java.net/browse/JDK-8032884
Issue fixing the bug (bulk update): 
https://bugs.openjdk.java.net/browse/JDK-8036030

The test verifies the source code generated by xjc tool.

Thanks
Miran

RFR: tests for JDK-8032884

[Miroslav Kos]

Hi everybody,

I'd like to ask for review of following tests:
http://cr.openjdk.java.net/~mkos/8032884/jdk.01/

Original bug (already fixed): Bug: 
https://bugs.openjdk.java.net/browse/JDK-8032884
Issue fixing the bug (bulk update): 
https://bugs.openjdk.java.net/browse/JDK-8036030


The test verifies the source code generated by xjc tool.

Thanks
Miran

Re: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode

[Miroslav Kos]

No problem, let's move it - should I prepare another webrev, or will you 
move it by yourself?


Thanks
Miran

On 31/03/14 18:38, Chris Hegarty wrote:

Miran,

If you agree, I would like to move the test ( before pushing ) to 
jdk/test/javax/xml/ws (/ebcdic). This is where other jaxws tests live, and will 
be picked up in the usual developer cycle by the jdk_other test group.

-Chris.

On 31 Mar 2014, at 15:33, Chris Hegarty  wrote:


On 31/03/14 15:05, Miroslav Kos wrote:

Thanks Chris, the code adjusted:
http://cr.openjdk.java.net/~mkos/8038307/jaxws.02/

Approved.


Glad, if you can sponsor it for me.

I'll push this later today.

-Chris.


Regards
Miran

On 31/03/14 15:34, Chris Hegarty wrote:

Looks ok to me Miran.

You can use String.getBytes(StandardCharsets.UTF_8) if you don't want
to handle UnsupportedEncodingException.

I can sponsor this for you, if you need a sponsor.

-Chris.

[1]
http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8


On 31/03/14 14:19, Miroslav Kos wrote:

Hi there,
please review folowing simple fix -
Bug: https://bugs.openjdk.java.net/browse/JDK-8038307
Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/
Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/

Issue related to EBCDIC encoding/WsImport tool.

Thanks
Miran

Re: RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode

[Miroslav Kos]

Thanks Chris, the code adjusted:
http://cr.openjdk.java.net/~mkos/8038307/jaxws.02/

Glad, if you can sponsor it for me.

Regards
Miran

On 31/03/14 15:34, Chris Hegarty wrote:

Looks ok to me Miran.

You can use String.getBytes(StandardCharsets.UTF_8) if you don't want 
to handle UnsupportedEncodingException.


I can sponsor this for you, if you need a sponsor.

-Chris.

[1] 
http://docs.oracle.com/javase/8/docs/api/java/nio/charset/StandardCharsets.html#UTF_8


On 31/03/14 14:19, Miroslav Kos wrote:

Hi there,
please review folowing simple fix -
Bug: https://bugs.openjdk.java.net/browse/JDK-8038307
Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/
Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/

Issue related to EBCDIC encoding/WsImport tool.

Thanks
Miran

RFR: 8038307: JAX-WS conformance tests fail when running JCK-devtools-8 suite against RI in EBCDIC emulation mode

[Miroslav Kos]

Hi there,
please review folowing simple fix -
Bug: https://bugs.openjdk.java.net/browse/JDK-8038307
Fix: http://cr.openjdk.java.net/~mkos/8038307/jaxws.01/
Test: http://cr.openjdk.java.net/~mkos/8038307/jdk.01/

Issue related to EBCDIC encoding/WsImport tool.

Thanks
Miran

Re: RFR: 8036030: Update JAX-WS RI integration to latest version

[Miroslav Kos]

Hi Chris,
I regenerated webrev against current hg tip - the copyright changes 
should be ok now.

patch file is attached, the new webrev is uploading just now:
http://cr.openjdk.java.net/~mkos/8036030/jaxws.01/
JBS: https://bugs.openjdk.java.net/browse/JDK-8036030

Let me know if it is ok now.

Thanks
Miran



On 28/03/14 10:14, Chris Hegarty wrote:

Hi Miran,

I have skimmed the webrev, and it looks ok to me.

You seem to have some files with changes for 8029237, which is already 
integrated into jdk9/dev. Can you remove this, then I will sponsor the 
change for you.


-Chris.

On 07/03/14 16:21, Miroslav Kos wrote:

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8036030/jaxws.00/
more details in issue desc:
https://bugs.openjdk.java.net/browse/JDK-8036030

Thanks
Miran

RFR: 8036030: Update JAX-WS RI integration to latest version

[Miroslav Kos]

Hi,
there is a bulk update of JAX-B/WS from upstream projects -
webrev: http://cr.openjdk.java.net/~mkos/8036030/jaxws.00/
more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8036030

Thanks
Miran

Re: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013

[Miroslav Kos]

Hi Chris,
I missed that, sorry. Yes please push it to jdk9, it will do the job 
there too...


Thanks
Miran

On 24/01/14 11:12, Chris Hegarty wrote:

Miran,

This bug has not been approved for JDK 8, in fact it was considered 
and rejected. The fix should be pushed to jdk9/dev, if applicable. If 
the patches apply cleanly I can push it for you. Do you want it in JDK 9?


-Chris.


On 24/01/14 09:41, Miroslav Kos wrote:

Hi Chris,
thanks for reviewing - I generated the patches today again so now it
should be ok:
http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012-v02.patch
http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013-v02.patch

Could you push it for me? I have no rights for jdk8.

I suppose the commit dates (must be in the past) would be imported
correctly:

copyrights-2012-v02.patch: -d "2012-12-30"
copyrights-2013-v02.patch: -d "2013-12-30"

Thanks
Miran



On 23/01/14 10:07, Chris Hegarty wrote:
On 23 Jan 2014, at 08:53, Martin Grebac  
wrote:



Hi Miran, did you get any response on this yet?
MartiNG

On 17/01/14 10:57, Miroslav Kos wrote:

Hi Steve and Alan,
I just reminding this issue - I have no response from anybody yet
and it would really simplify our integration if I could handle
copyright years inconsistencies this way - I see this issue in many
jdk branches and these "each-branch-different" changes make each
integration much more pain.

Thanks for any idea on this.

Miran


On 10/01/14 18:05, Miroslav Kos wrote:

Hi,
this is about fixing copyright years for jdk8 (!); the incorrect
years found for both 2012 and 2013, so not to confuse script
jdk8/make/scripts/update_copyright_year.sh
it is necessary to use option -d "" for commit. I tested that
and it seems to work perfect.
I used following:

[2012 modifications]
hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30"

[2013 modifications]
hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30"

When commits performed with past date, update_copyright_year.sh
script finds those in proper years. Since I am not familiar with
using webrev for pushing changes, I exported both revisions into
separate patches:

2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch

I skimmed the patch and it looks ok to me.

Trivially, it contains a 2013 update (which it should probably be in
the 2013 patch)

diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile
--- a/make/MakefileFri Jan 03 11:54:55 2014 -0800
+++ b/make/MakefileSun Dec 30 00:00:00 2012 +0100
@@ -1,5 +1,5 @@
  #
-# Copyright (c) 2012, Oracle and/or its affiliates. All rights 
reserved.

+# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights
reserved.
  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  #


2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch

Looks ok to me.

-Chris.


all changes webrev:
http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload
still in progress, I hope it doesn't take more than 30 mins)
bug: https://bugs.openjdk.java.net/browse/JDK-8029237

Regards
Miran




--
Martin Grebac, SW Engineering Manager
Oracle Czech, Prague

Re: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013

[Miroslav Kos]

Hi Chris,
thanks for reviewing - I generated the patches today again so now it 
should be ok:

http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012-v02.patch
http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013-v02.patch

Could you push it for me? I have no rights for jdk8.

I suppose the commit dates (must be in the past) would be imported 
correctly:


copyrights-2012-v02.patch: -d "2012-12-30"
copyrights-2013-v02.patch: -d "2013-12-30"

Thanks
Miran



On 23/01/14 10:07, Chris Hegarty wrote:

On 23 Jan 2014, at 08:53, Martin Grebac  wrote:


Hi Miran, did you get any response on this yet?
MartiNG

On 17/01/14 10:57, Miroslav Kos wrote:

Hi Steve and Alan,
I just reminding this issue - I have no response from anybody yet and it would really 
simplify our integration if I could handle copyright years inconsistencies this way - I 
see this issue in many jdk branches and these "each-branch-different" changes 
make each integration much more pain.

Thanks for any idea on this.

Miran


On 10/01/14 18:05, Miroslav Kos wrote:

Hi,
this is about fixing copyright years for jdk8 (!); the incorrect years found 
for both 2012 and 2013, so not to confuse script
jdk8/make/scripts/update_copyright_year.sh
it is necessary to use option -d "" for commit. I tested that and it 
seems to work perfect.
I used following:

[2012 modifications]
hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30"

[2013 modifications]
hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30"

When commits performed with past date, update_copyright_year.sh script finds 
those in proper years. Since I am not familiar with using webrev for pushing 
changes, I exported both revisions into separate patches:

2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch

I skimmed the patch and it looks ok to me.

Trivially, it contains a 2013 update (which it should probably be in the 2013 
patch)

diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile
--- a/make/Makefile Fri Jan 03 11:54:55 2014 -0800
+++ b/make/Makefile Sun Dec 30 00:00:00 2012 +0100
@@ -1,5 +1,5 @@
  #
-# Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  #


2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch

Looks ok to me.

-Chris.


all changes webrev: http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ 
(upload still in progress, I hope it doesn't take more than 30 mins)
bug: https://bugs.openjdk.java.net/browse/JDK-8029237

Regards
Miran




--
Martin Grebac, SW Engineering Manager
Oracle Czech, Prague

Re: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013

[Miroslav Kos]

Hi Steve and Alan,
I just reminding this issue - I have no response from anybody yet and it 
would really simplify our integration if I could handle copyright years 
inconsistencies this way - I see this issue in many jdk branches and 
these "each-branch-different" changes make each integration much more pain.


Thanks for any idea on this.

Miran


On 10/01/14 18:05, Miroslav Kos wrote:

Hi,
this is about fixing copyright years for jdk8 (!); the incorrect years 
found for both 2012 and 2013, so not to confuse script

jdk8/make/scripts/update_copyright_year.sh
it is necessary to use option -d "" for commit. I tested that 
and it seems to work perfect.

I used following:

[2012 modifications]
hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30"

[2013 modifications]
hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30"

When commits performed with past date, update_copyright_year.sh script 
finds those in proper years. Since I am not familiar with using webrev 
for pushing changes, I exported both revisions into separate patches:


2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch
2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch
all changes webrev: 
http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/   (upload 
still in progress, I hope it doesn't take more than 30 mins)

bug: https://bugs.openjdk.java.net/browse/JDK-8029237

Regards
Miran

JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013

[Miroslav Kos]

Hi,
this is about fixing copyright years for jdk8 (!); the incorrect years 
found for both 2012 and 2013, so not to confuse script

jdk8/make/scripts/update_copyright_year.sh
it is necessary to use option -d "" for commit. I tested that and 
it seems to work perfect.

I used following:

[2012 modifications]
hg commit -u mkos -l ../2012-msg.txt -d "2012-12-30"

[2013 modifications]
hg commit -u mkos -l ../2013-msg.txt -d "2013-12-30"

When commits performed with past date, update_copyright_year.sh script 
finds those in proper years. Since I am not familiar with using webrev 
for pushing changes, I exported both revisions into separate patches:


2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch
2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch
all changes webrev: 
http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/   (upload still 
in progress, I hope it doesn't take more than 30 mins)

bug: https://bugs.openjdk.java.net/browse/JDK-8029237

Regards
Miran

Re: Update JAX-WS RI integration to 2.2.9-b130918.1732 - JDK-8025054

[Miroslav Kos]

No problem, I just moved it: 
http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.01/


Let me know if I can do anything else to speed up pushing the changeset.

Thanks
Miran


On 10/1/13 11:41 AM, Seán Coffey wrote:


On 01/10/2013 10:29, Chris Hegarty wrote:

On 10/01/2013 10:09 AM, Seán Coffey wrote:

Miran,

I'm assuming that all these changes were reviewed when integrated to 
the

upstream JAX-WS project. I confirm that my changes from 8016271 are
present and look fine. I'm not an OpenJDK reviewer though so you'll 
need

someone else as reviewer.


From a quick skim, I don't see anything objectionable.

I see a new test has been added to the jdk repo. Since it defines a 
TestService, is it a bit of a land grab on javax/xml/ws? Or can other 
jaxws test be put in javax/xml/ws without interference?
Good point. Hopefully Miran can move them to a sub-directory before 
pushing. Maybe something like : test/javax/xml/ws/clientJarTest/


regards,
Sean.


-Chris.



regards,
Sean.

On 26/09/2013 17:14, Miroslav Kos wrote:

Hi Sean,
anything new about this?

I fixed the copyright/indentation problems (the only change), so the
updated jaxws-webrev is located here:
http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/

Since the timestamp (version number) changed too, I updated also the
JIRA issue:
https://bugs.openjdk.java.net/browse/JDK-8025054

It would be good to push it soon.

Thanks
Miran


On 9/23/13 5:38 PM, Alan Bateman wrote:

On 23/09/2013 02:19, Miroslav Kos wrote:

Hi everybody,

There is another update syncing JAX-WS sources in jdk8/tl/jaxws to
most recent development version.

As usually, it is quite big changeset (6k+ LOC changed) and includes
several bug fixes, for details see the issue description:
https://bugs.openjdk.java.net/browse/JDK-8025054

Please, see weberevs here:
jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00
jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/

Just a passing comment (not a code review) on the copyright headers
of the new source files. I assume they must have been copied from
another file as they say 1997.  You might want to also check for tabs
too (although jcheck will catch those) because it looks like some of
the javadoc comments and annotations have inconsistent indentation.

-Alan

Re: Update JAX-WS RI integration to 2.2.9-b130918.1732 - JDK-8025054

[Miroslav Kos]

Hi Sean,
yes, all the changes are going throuhg a review on our side before they 
are pushed into upstream projects.


When we integrated in the past into jdk, reviewers were Sean Mullan, 
Sami Koivu, Alan Bateman and Alexander Fomin. Could anybody from them 
look into it? If you had any hint who could we ask, let me know.


Thanks
Miran


On 10/1/13 11:09 AM, Seán Coffey wrote:

Miran,

I'm assuming that all these changes were reviewed when integrated to 
the upstream JAX-WS project. I confirm that my changes from 8016271 
are present and look fine. I'm not an OpenJDK reviewer though so 
you'll need someone else as reviewer.


regards,
Sean.

On 26/09/2013 17:14, Miroslav Kos wrote:

Hi Sean,
anything new about this?

I fixed the copyright/indentation problems (the only change), so the 
updated jaxws-webrev is located here:

http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/

Since the timestamp (version number) changed too, I updated also the 
JIRA issue:

https://bugs.openjdk.java.net/browse/JDK-8025054

It would be good to push it soon.

Thanks
Miran


On 9/23/13 5:38 PM, Alan Bateman wrote:

On 23/09/2013 02:19, Miroslav Kos wrote:

Hi everybody,

There is another update syncing JAX-WS sources in jdk8/tl/jaxws to 
most recent development version.


As usually, it is quite big changeset (6k+ LOC changed) and 
includes several bug fixes, for details see the issue description:

https://bugs.openjdk.java.net/browse/JDK-8025054

Please, see weberevs here:
jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00
jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/
Just a passing comment (not a code review) on the copyright headers 
of the new source files. I assume they must have been copied from 
another file as they say 1997.  You might want to also check for 
tabs too (although jcheck will catch those) because it looks like 
some of the javadoc comments and annotations have inconsistent 
indentation.


-Alan

Re: Update JAX-WS RI integration to 2.2.9-b130918.1732

[Miroslav Kos]

Hi Sean,
anything new about this?

I fixed the copyright/indentation problems (the only change), so the 
updated jaxws-webrev is located here:

http://cr.openjdk.java.net/~mkos/8025054/webrev-jaxws.01/

Since the timestamp (version number) changed too, I updated also the 
JIRA issue:

https://bugs.openjdk.java.net/browse/JDK-8025054

It would be good to push it soon.

Thanks
Miran


On 9/23/13 5:38 PM, Alan Bateman wrote:

On 23/09/2013 02:19, Miroslav Kos wrote:

Hi everybody,

There is another update syncing JAX-WS sources in jdk8/tl/jaxws to 
most recent development version.


As usually, it is quite big changeset (6k+ LOC changed) and includes 
several bug fixes, for details see the issue description:

https://bugs.openjdk.java.net/browse/JDK-8025054

Please, see weberevs here:
jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00
jdk/test: http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/
Just a passing comment (not a code review) on the copyright headers of 
the new source files. I assume they must have been copied from another 
file as they say 1997.  You might want to also check for tabs too 
(although jcheck will catch those) because it looks like some of the 
javadoc comments and annotations have inconsistent indentation.


-Alan

Update JAX-WS RI integration to 2.2.9-b130918.1732

[Miroslav Kos]

Hi everybody,

There is another update syncing JAX-WS sources in jdk8/tl/jaxws to most 
recent development version.


As usually, it is quite big changeset (6k+ LOC changed) and includes 
several bug fixes, for details see the issue description:

https://bugs.openjdk.java.net/browse/JDK-8025054

Please, see weberevs here:
jaxws: http://cr.openjdk.java.net/~mkos/8025054/webrev.00
jdk/test: 
http://cr.openjdk.java.net/~mkos/8025054/webrev-jdk.00/



Thanks
Miran

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

[Miroslav Kos]

Hi Sean,
up to now, integrations JAX-WS > JDK haven't been done on regular basis, 
just when bug fixes were required, for current JDK development version 
it was time to time - 2x or 3x during a year (?) ...


For future, we would like make it on regular basis for development 
version JAX-WS trunk/Jdk8 - let's say once or twice (?) a month, for 
other jdk version it would be same as now, only up on request ...


How to proceed with this issue depends on how critical is it - we can 
integrate that first on our side and later (one week delay) deliver jdk 
patch or, if it is something critical, we can push it simultaneously 
into both codebasis. We definitely prefer the first option.


Miran


On 09/03/2013 12:18 PM, Seán Coffey wrote:

Miran,

can you clarify how we get this fix in then. Will you patch into 
JAX-WS and port to the jdk/jaxws repo or do can we push it to both 
repos independently? How often does JAX-WS team sync with openJDK ?


I need to get this ported to jdk7u also.

regards,
Sean.

On 03/09/2013 11:11, Miroslav Kos wrote:

Hi Alan,
good catch! Yes, we need to apply the fix on our side too, otherwise 
it would be reverted with a new integration JAX-WS > JDK.


Miran



On 09/03/2013 12:03 PM, Alan Bateman wrote:

On 03/09/2013 10:49, Seán Coffey wrote:

Bug report not public at moment. (should appear shortly)

Issue with wsimport tool. Use of jar files created from wsimport on 
windows don't work on unix systems. Portability issue.

Simple fix. wsimport testcase to accompany it.

http://cr.openjdk.java.net/~coffeys/webrev.8016271/
Does this need to go into an upstream project first?  As I 
understand it, the JAX-WS folks have an industrial blender to mix 
the ingredients for the jaxws repository. At one point then I think 
there were about 10 upstream projects to pull code from. Maybe 
things have changed but I just wonder if changes/patches pushed to 
the jaxws repository will be wiped by a re-sync from upstream. I've 
cc'ed martin Grebac and Miroslav Kos to comment.


-Alan.

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

[Miroslav Kos]

Hi Alan,
good catch! Yes, we need to apply the fix on our side too, otherwise it 
would be reverted with a new integration JAX-WS > JDK.


Miran



On 09/03/2013 12:03 PM, Alan Bateman wrote:

On 03/09/2013 10:49, Seán Coffey wrote:

Bug report not public at moment. (should appear shortly)

Issue with wsimport tool. Use of jar files created from wsimport on 
windows don't work on unix systems. Portability issue.

Simple fix. wsimport testcase to accompany it.

http://cr.openjdk.java.net/~coffeys/webrev.8016271/
Does this need to go into an upstream project first?  As I understand 
it, the JAX-WS folks have an industrial blender to mix the ingredients 
for the jaxws repository. At one point then I think there were about 
10 upstream projects to pull code from. Maybe things have changed but 
I just wonder if changes/patches pushed to the jaxws repository will 
be wiped by a re-sync from upstream. I've cc'ed martin Grebac and 
Miroslav Kos to comment.


-Alan.

Re: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review

[Miroslav Kos]

Hi everybody,

I prepared a new changeset containing no copyright changes so we can get 
further: http://cr.openjdk.java.net/~mkos/8022885/webrev.01/


We will discuss rngom changes separately and if necessary, it will be 
updated with a new integration.


Miran



On 08/19/2013 05:33 PM, Alan Bateman wrote:

On 19/08/2013 13:56, Miroslav Kos wrote:

Hi Alan,
yes, this is true for rngom library - we downgraded it to the version 
which has been approved to be used as a 3rd party library. Licences 
are unchanged from the ones in the library; is there somebody who 
could approve these are ok?
IANAL and without some understanding or legal help then it's 
impossible to approve changes that remove copyright headers from what 
seems to be 3rd party code. All I can suggest is to get this checked.


-Alan.

Re: Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review

[Miroslav Kos]

Hi Alan,
yes, this is true for rngom library - we downgraded it to the version 
which has been approved to be used as a 3rd party library. Licences are 
unchanged from the ones in the library; is there somebody who could 
approve these are ok?


Thanks
Miran



On 08/16/2013 12:43 PM, Alan Bateman wrote:

On 16/08/2013 11:15, Miroslav Kos wrote:
There is an update syncing JAX-WS sources in jdk8/tl/jaxws to most 
recent development version.


It is quite big changeset (13k+ LOC changed) and includes several bug 
fixes:


http://java.net/jira/browse/JAX_WS-1114 problem sending XML primitive 
type gMonth (the request ends up null on server)
http://java.net/jira/browse/JAX_WS-723 Provide target 2.1 option to 
generate classes as per JAX-WS 2.1
http://java.net/jira/browse/JAX_WS-653 Erroneous Class-Path ref. in 
Manifest of several jar files


http://java.net/jira/browse/JAXB-937 Nested unmarshalling can lead to 
NullPointerException

http://java.net/jira/browse/JAXB-643 Cannot use gMonth on jdk/jre 6

Please, see weberev here: 
http://cr.openjdk.java.net/~mkos/8022885/webrev.00/


Thanks
Miran
I can't really comment on the changes as I don't know the JAX-WS code 
but you might need to double-check some of the copyrights. I see for 
example that the patch removes (rather than replaces) the copyright 
header on org/relaxng/datatype classes. I don't know if that is 
intended or not.


-Alan.

Update jdk8/tl/jaxws to v2.2.9-b14140 ready for review

[Miroslav Kos]

There is an update syncing JAX-WS sources in jdk8/tl/jaxws to most 
recent development version.


It is quite big changeset (13k+ LOC changed) and includes several bug fixes:

http://java.net/jira/browse/JAX_WS-1114 problem sending XML primitive 
type gMonth (the request ends up null on server)
http://java.net/jira/browse/JAX_WS-723 Provide target 2.1 option to 
generate classes as per JAX-WS 2.1
http://java.net/jira/browse/JAX_WS-653 Erroneous Class-Path ref. in 
Manifest of several jar files


http://java.net/jira/browse/JAXB-937 Nested unmarshalling can lead to 
NullPointerException

http://java.net/jira/browse/JAXB-643 Cannot use gMonth on jdk/jre 6

Please, see weberev here: 
http://cr.openjdk.java.net/~mkos/8022885/webrev.00/


Thanks
Miran

Re: JAX-WS update coming soon

[Miroslav Kos]

On 04/08/2013 05:05 PM, Alan Bateman wrote:

On 21/03/2013 11:27, Alan Bateman wrote:


Just a heads-up that there is a JAX-WS update coming for jdk8. 
Miroslav Kos will be sending a webrev soon with the changes that 
update what we have in jdk8 from 2.2.7-b09 to 2.2.9-b13922.

Miroslav has put a webrev with the changes here:

http://cr.openjdk.java.net/~mkos/8010393/webrev.01/

Miroslav - can you briefly summarize the changes so that folks know 
what is coming?


The change set contains all the changes between versions 2.2.7-b09 and 
the current development version, which is 2.2.9-b12941. There are no big 
changes, it contains just bug fixes required by upper stacks (metro, 
glassfish, weblogic) and minor refactorings. Attached is a list of fixed 
issues.


Thanks
Miran




One minor update is that I needed to modify a make file to ensure that 
a new .xml gets packaged into resources.jar.


-Alan


diff --git a/makefiles/BuildJaxws.gmk b/makefiles/BuildJaxws.gmk
--- a/makefiles/BuildJaxws.gmk
+++ b/makefiles/BuildJaxws.gmk
@@ -55,7 +55,8 @@
 BIN:=$(JAXWS_OUTPUTDIR)/jaxws_classes,\
 COPY:=.xsd,\
COPY_FILES:=$(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/JAXBContextFactory.java 
\
- 
$(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java,\
+ 
$(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/tools/internal/xjc/runtime/ZeroOneBooleanAdapter.java 
\
+ 
$(JAXWS_TOPDIR)/src/share/jaxws_classes/com/sun/xml/internal/ws/assembler/jaxws-tubes-default.xml,\

 ADD_JAVAC_FLAGS=-cp $(OUTPUT_ROOT)/jaxp/dist/lib/classes.jar))

 $(JAXWS_OUTPUTDIR)/jaxws_classes/META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin: 
\

@@ -98,7 +99,7 @@

 $(eval $(call SetupArchive,ARCHIVE_JAXWS,$(BUILD_JAXWS) $(BUILD_JAF) 
$(TARGET_PROP_FILES),\
 SRCS:=$(JAXWS_OUTPUTDIR)/jaxws_classes 
$(JAXWS_OUTPUTDIR)/jaf_classes,\

-SUFFIXES:=.class .properties .xsd .java \
+SUFFIXES:=.class .properties .xsd .xml .java \
   com.sun.mirror.apt.AnnotationProcessorFactory \
   com.sun.tools.internal.xjc.Plugin,\
 JAR:=$(JAXWS_OUTPUTDIR)/dist/lib/classes.jar))



Displaying issues *1* to *71* of *71* matching issues. as at: *08/Apr/1303:52 
PM*  

*Key*   *Summary*
<http://java.net/jira/browse/JAX_WS-1112>   Make JAX-WS run on J2SE 5.0 
<http://java.net/jira/browse/JAX_WS-1112>
<http://java.net/jira/browse/JAX_WS-1107>   httpproxy username and password 
not supported <http://java.net/jira/browse/JAX_WS-1107> 
<http://java.net/jira/browse/JAX_WS-1105>   wsgen fails to resolve all 
'service implementation bean' methods <http://java.net/jira/browse/JAX_WS-1105> 
<http://java.net/jira/browse/JAX_WS-1102>   jaxws should pass encoding 
option to jaxb <http://java.net/jira/browse/JAX_WS-1102> 
<http://java.net/jira/browse/JAX_WS-1101>   wsimport authFile URL 
containing passwords should support encoded/escaped characters... 
<http://java.net/jira/browse/JAX_WS-1101> 
<http://java.net/jira/browse/JAX_WS-1100>   Allow wild card matching to 
allow the same user:password for all urls with the same host name 
<http://java.net/jira/browse/JAX_WS-1100> 
<http://java.net/jira/browse/JAX_WS-1099> 
com.sun.xml.ws.api.model.wsdl.WSDLModel.WSDLParser.parse error in parsering 
wsdl:message/wsdl:part defines "type" (not "element") 
<http://java.net/jira/browse/JAX_WS-1099> 
<http://java.net/jira/browse/JAX_WS-1098> IllegalAnnotationsException: 2 counts 
of IllegalAnnotationExceptions: MemberSubmissionEndpointReference$Address and 
W3CEndpointReference$Address <http://java.net/jira/browse/JAX_WS-1098> 
<http://java.net/jira/browse/JAX_WS-1095>   Basic Authentication with 
wsimport does not allow @ in username <http://java.net/jira/browse/JAX_WS-1095> 
<http://java.net/jira/browse/JAX_WS-1094>   wsa:to header of ack message 
changed to annonymous when the request message has no replyTo 
<http://java.net/jira/browse/JAX_WS-1094> 
<http://java.net/jira/browse/JAX_WS-1092>   Back Compatible issue, for 
method: com.sun.xml.ws.server.EndpointFactory.verifyImplementorClass 
<http://java.net/jira/browse/JAX_WS-1092> 
<http://java.net/jira/browse/JAX_WS-1088>   HttpAdapter send empty response 
message even when the message is null given that the endpointAddress of Packet 
is not null <http://java.net/jira/browse/JAX_WS-1088> 
<http://java.net/jira/browse/JAX_WS-1087>   unable to delete .war file 
after wsimport completed <http://java.net/jira/browse/JAX_WS-1087> 
<http://java.net/jira/browse/JAX_WS-1083>   Error listenerStart Sep 27, 
2012 12:02:48 AM org.apache.catalina.core.StandardContext start 
<http://java.net/jira/browse/JAX_WS-1083> 
<http://java.net/jira/browse

Re: 7140918: Remove dependency on apt and com.sun.mirror API

[Miroslav Kos]

Hi Alan,
do you have any update about approving the changeset? The jaxws bundle 
is already in place, so there should be nothing blocking us from the 
final step(?)


We already have PIT Certificate from QA: 
https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=13491649


Regards
Miran


On 31.1.2012 9:08, Alan Bateman wrote:

On 31/01/2012 01:17, David Holmes wrote:

:
Okay. So as part of this will the new zip file be installed before 
the change gets pushed?

Yes, that's right.

-Alan