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
