Build support for JDK-8044627
Hi, I can't build jdk9/dev repo after I introduced 4 'META-INF/service/javax.naming.spi.InitialContextFactory' files to support JNDI providers loading as a service [1]. My guess is that 'META-INF/service/javax.naming.spi.InitialContextFactory' files from different modules are being copied into the same jar. What I really need to have is a single concatenated 'META-INF/service/javax.naming.spi.InitialContextFactory' file with 4 lines. It will work fine for now. Could you please help me to resolve this? Thanks. - [1] http://cr.openjdk.java.net/~prappo/8044627/webrev.01/ -Pavel
Re: Build support for JDK-8044627
Hello Pavel, This will be a bit tricky. Give me a day or two and I will try to come up with something. /Erik On 2014-10-14 15:27, Pavel Rappo wrote: Hi, I can't build jdk9/dev repo after I introduced 4 'META-INF/service/javax.naming.spi.InitialContextFactory' files to support JNDI providers loading as a service [1]. My guess is that 'META-INF/service/javax.naming.spi.InitialContextFactory' files from different modules are being copied into the same jar. What I really need to have is a single concatenated 'META-INF/service/javax.naming.spi.InitialContextFactory' file with 4 lines. It will work fine for now. Could you please help me to resolve this? Thanks. - [1] http://cr.openjdk.java.net/~prappo/8044627/webrev.01/ -Pavel
Re: RFR JDK-8044627: Update JNDI to work with modules
On 14 Oct 2014, at 15:03, Pavel Rappo pavel.ra...@oracle.com wrote: OK, so what I will do for now is I exclude these 4 files and push without them. I'll create a new issue to add them later. That sounds like a fine plan. This issue has already gone on for long enough, and I don’t think that the crooks of the change should have to wait even longer. Consider this issue Reviewed, provided that the changes in the webrev minus the 4 services files compile and test ok. Then you can push the services files once build support is added. -Chris. -Pavel On 14 Oct 2014, at 14:44, Alan Bateman alan.bate...@oracle.com wrote: On 14/10/2014 14:34, Daniel Fuchs wrote: Hi Pavel, I saw your mail on build-dev. I guess the issue will resolve itself once we have the modular image. I wonder whether the way to go for now would be to add a single META-INF/services file - as you suggest - in java.naming, with the 4 lines inside, and log a bug/RFE to follow up on that once the modular image is there. best regards, -- daniel Once we move to modules then these service configuration files will go away. The resolver will build a service-use graph based on the provides/uses in the module descriptors and that will link the JNDI module to the providers. Pavel just needs a short term solution and having all the providers in one file is okay for that. A better short term solution is to just concatenate them in the build, we are already doing this in the jigsaw/m2 forest for the JDI connectors. -Alan
Re: RFR JDK-8044627: Update JNDI to work with modules
On 14/10/14 16:09, Chris Hegarty wrote: On 14 Oct 2014, at 15:03, Pavel Rappo pavel.ra...@oracle.com wrote: OK, so what I will do for now is I exclude these 4 files and push without them. I'll create a new issue to add them later. That sounds like a fine plan. This issue has already gone on for long enough, and I don’t think that the crooks of the change should have to wait even longer. Right. I see it now. If you have no providers - then the old 'helper.loadClass(className).newInstance();' code will be executed - which should still work for now. So not pushing the META-INF/services files sounds fine. best regards, -- daniel Consider this issue Reviewed, provided that the changes in the webrev minus the 4 services files compile and test ok. Then you can push the services files once build support is added. -Chris. -Pavel On 14 Oct 2014, at 14:44, Alan Bateman alan.bate...@oracle.com wrote: On 14/10/2014 14:34, Daniel Fuchs wrote: Hi Pavel, I saw your mail on build-dev. I guess the issue will resolve itself once we have the modular image. I wonder whether the way to go for now would be to add a single META-INF/services file - as you suggest - in java.naming, with the 4 lines inside, and log a bug/RFE to follow up on that once the modular image is there. best regards, -- daniel Once we move to modules then these service configuration files will go away. The resolver will build a service-use graph based on the provides/uses in the module descriptors and that will link the JNDI module to the providers. Pavel just needs a short term solution and having all the providers in one file is okay for that. A better short term solution is to just concatenate them in the build, we are already doing this in the jigsaw/m2 forest for the JDI connectors. -Alan
Re: RFR JDK-8044627: Update JNDI to work with modules
Thanks a lot! -Pavel On 14 Oct 2014, at 15:33, Chris Hegarty chris.hega...@oracle.com wrote: META-INF files in the webrev, two of which are in the wrong location. They are directly under 'META-INF’, where they should all be under ‘META-INF/services’. This is just a note for Pavel, when he follows up later with the addition of these service configuration files, and also to avoid confusion.
Re: RFR JDK-8044627: Update JNDI to work with modules
On 14 Oct 2014, at 15:15, Daniel Fuchs daniel.fu...@oracle.com wrote: On 14/10/14 16:09, Chris Hegarty wrote: On 14 Oct 2014, at 15:03, Pavel Rappo pavel.ra...@oracle.com wrote: OK, so what I will do for now is I exclude these 4 files and push without them. I'll create a new issue to add them later. That sounds like a fine plan. This issue has already gone on for long enough, and I don’t think that the crooks of the change should have to wait even longer. Right. I see it now. If you have no providers - then the old 'helper.loadClass(className).newInstance();' code will be executed - which should still work for now. Exactly. So not pushing the META-INF/services files sounds fine. Erik just pinged me in relation to the META-INF files in the webrev, two of which are in the wrong location. They are directly under 'META-INF’, where they should all be under ‘META-INF/services’. This is just a note for Pavel, when he follows up later with the addition of these service configuration files, and also to avoid confusion. -Chris. best regards, -- daniel Consider this issue Reviewed, provided that the changes in the webrev minus the 4 services files compile and test ok. Then you can push the services files once build support is added. -Chris. -Pavel On 14 Oct 2014, at 14:44, Alan Bateman alan.bate...@oracle.com wrote: On 14/10/2014 14:34, Daniel Fuchs wrote: Hi Pavel, I saw your mail on build-dev. I guess the issue will resolve itself once we have the modular image. I wonder whether the way to go for now would be to add a single META-INF/services file - as you suggest - in java.naming, with the 4 lines inside, and log a bug/RFE to follow up on that once the modular image is there. best regards, -- daniel Once we move to modules then these service configuration files will go away. The resolver will build a service-use graph based on the provides/uses in the module descriptors and that will link the JNDI module to the providers. Pavel just needs a short term solution and having all the providers in one file is okay for that. A better short term solution is to just concatenate them in the build, we are already doing this in the jigsaw/m2 forest for the JDI connectors. -Alan
