[8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider
Joe Darcy
joe.darcy at oracle.com
Mon Aug 10 21:22:08 UTC 2020
Hello,
The practices of CSR and multiple releases have evolved slightly as the
system has been in use for a few years now.
The CSR FAQ https://wiki.openjdk.java.net/display/csr/CSR+FAQs covers
some of the conditions as quoted below [1].
In cases where
1) the exact same change is being made in multiple release trains
and
2) the decision to but the change in multiple releases is being
made at the same time
then a single CSR can be shared by putting multiple releases (or release
families) in the fixVesion field.
In this case, it sounds like there are some minor differences so two CSR
should be filed.
Criteria 2) means that if, say, there is a CSR to put a change in 11u
and that change is pushed and three months later there is a desire to
put the change into 8u, a separate CSR would be needed. I treat the CSRs
as updatable until the underlying bug is pushed to a repo. After that
point, it should generally not be further modified or reused.
HTH,
-Joe
[1] Q: How should I get CSR review for multiple release trains?
A: Say you want to get an interface change into JDK N and later decide
the change is also desirable and appropriate for the JDK (N-1) update
release and that update release is using the CSR process. First a CSR
should be created from the main bug targeted at JDK N. Afterward, if a
backport of the main bug covering JDK (N-1) does not already exist, a
backport of the main bug covering JDK (N-1) should be created. Then, a
CSR can be created from that backport. The CSR for the backport should
explicitly state how the interface change for the backport relates to
the interface change for the main release: either the interface change
is the same or, if it differs, what the difference is.
On 8/10/2020 12:00 PM, Langer, Christoph wrote:
> Hi Paul,
>
> well, I've seen Oracle doing such Multi-Release CSRs. E.g. https://bugs.openjdk.java.net/browse/JDK-8235540. Copying Joe for clarification. @Joe: Was this an accident or a correct way to use the CSR process? Generally I would welcome this as I believe it could reduce some process overhead...
>
> Nevertheless, in this case, while the backport service implementation classes are the same, there are minor differences in the implementation (e.g. addition of module jdk.naming.ldap in 11u and different package for LdapDnsProviderService) that would speak for two separate CSRs. I don't know...
>
> Cheers
> Christoph
>
>> -----Original Message-----
>> From: Hohensee, Paul <hohensee at amazon.com>
>> Sent: Montag, 10. August 2020 16:45
>> To: Langer, Christoph <christoph.langer at sap.com>; Zhengyu Gu
>> <zgu at redhat.com>; Severin Gehwolf <sgehwolf at redhat.com>; jdk8u-dev
>> <jdk8u-dev at openjdk.java.net>; Andrew Hughes
>> <gnu.andrew at redhat.com>; jdk-updates-dev at openjdk.java.net
>> Subject: RE: [8u] RFR 8160768: Add capability to custom resolve host/domain
>> names within the default JNDI LDAP provider
>>
>> I don't think you can have the same CSR for both releases because it messes
>> up the accounting. I.e., there's a backport issues for 8u and another one for
>> 11u, and each of these needs its own CSR. The two CSRs will have identical
>> content in this case. :)
>>
>> Paul
>>
>> On 8/10/20, 5:25 AM, "Langer, Christoph" <christoph.langer at sap.com>
>> wrote:
>>
>> Hi,
>>
>> as I'm in parallel working on an 11u backport and have the same
>> requirement for a CSR, I added release 11-pool to the CSR item (JDK-
>> 8251270). I think we can have one CSR for both releases. The user-visible
>> change that we want to do, that is, the introduction of com.sun.jndi.ldap.spi.
>> LdapDnsProvider and com.sun.jndi.ldap.spi. LdapDnsProviderResult is the
>> same, so I guess it is most convenient.
>>
>> Hope you're all ok with that? (I'll take no answer as a yes ��)
>>
>> I'll also go ahead and rephrase the CSR to use com.sun.jndi.ldap.spi instead
>> of javax.naming.ldap.spi.
>>
>> Best regards
>> Christoph
>>
>> > -----Original Message-----
>> > From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of
>> > Hohensee, Paul
>> > Sent: Freitag, 7. August 2020 18:15
>> > To: Zhengyu Gu <zgu at redhat.com>; Severin Gehwolf
>> > <sgehwolf at redhat.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>;
>> > Andrew Hughes <gnu.andrew at redhat.com>
>> > Subject: RE: [8u] RFR 8160768: Add capability to custom resolve
>> host/domain
>> > names within the default JNDI LDAP provider
>> >
>> > We do, because any behavioral/API change needs one, even to platform
>> > dependent classes.
>> >
>> > On 8/7/20, 7:44 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
>> >
>> > On 8/7/20 9:55 AM, Hohensee, Paul wrote:
>> > > You can backport this to 8u. As Michael Osipov wrote (and Alan as a
>> > comment on the 8u CSR), you just need to change the 8u CSR and patch
>> to
>> > move the new functionality to com.sun.jndi.ldap and
>> com.sun.jndi.ldap.spi.
>> >
>> > Right. But we don't need CSR for that, correct?
>> >
>> > Thanks,
>> >
>> > -Zhengyu
>> >
>> > >
>> > > Thanks,
>> > > Paul
>> > >
>> > > On 8/7/20, 5:48 AM, "Zhengyu Gu" <zgu at redhat.com> wrote:
>> > >
>> > > CAUTION: This email originated from outside of the organization.
>> Do
>> > not click links or open attachments unless you can confirm the sender
>> and
>> > know the content is safe.
>> > >
>> > >
>> > >
>> > > Hi Paul,
>> > >
>> > > Based on Alan Bateman's comment, we can not backport public API
>> to
>> > 8u. I
>> > > guess LdapDnsProvider.java and LdapDnsProviderResult.java have
>> to
>> > be
>> > > moved to com.sun.jndi.ldap and com.sun.jndi.ldap.spi packages.
>> > >
>> > > I will withdraw this CSR, ok?
>> > >
>> > > Thanks,
>> > >
>> > > -Zhengyu
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On 8/6/20 5:32 PM, Hohensee, Paul wrote:
>> > > > I filed a backport issue
>> > > >
>> > > > https://bugs.openjdk.java.net/browse/JDK-8251270
>> > > >
>> > > > and corresponding CSR
>> > > >
>> > > > https://bugs.openjdk.java.net/browse/JDK-8251270
>> > > >
>> > > > and assigned them to Zhengyu.
>> > > >
>> > > > On 8/6/20, 1:50 PM, "jdk8u-dev on behalf of Hohensee, Paul"
>> > <jdk8u-dev-retn at openjdk.java.net on behalf of
>> hohensee at amazon.com>
>> > wrote:
>> > > >
>> > > > +1 on needing a CSR for the backport. I'd missed the CSR link
>> > because it was buried under "Show 5 more links".
>> > > >
>> > > > I posted an RFO (Request for Opinion) on the same topic of
>> > approving strictly additive CSRs for backport.
>> > > >
>> > > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-
>> > August/012319.html
>> > > >
>> > > > Thanks,
>> > > > Paul
>> > > >
>> > > > On 8/6/20, 8:02 AM, "jdk8u-dev on behalf of Severin Gehwolf"
>> > <jdk8u-dev-retn at openjdk.java.net on behalf of sgehwolf at redhat.com>
>> > wrote:
>> > > >
>> > > > On Thu, 2020-08-06 at 10:13 -0400, Zhengyu Gu wrote:
>> > > > > > The original patch required a CSR[1], so we should file
>> one
>> > for JDK 8u
>> > > > > > too. I wonder where the CSR is for Oracle JDK 8, though.
>> > > > >
>> > > > > It does not seem to have a CSR for 11u backport(?) Do 8u
>> need
>> > one?
>> > > >
>> > > > Right. I don't know about what happened there for Oracle
>> JDK.
>> > You could
>> > > > try to ask.
>> > > >
>> > > > I believe we need one since this is changing the 8 SE API by
>> > adding:
>> > > >
>> > > > javax/naming/ldap/spi/LdapDnsProvider.java
>> > > > javax/naming/ldap/spi/LdapDnsProviderResult.java
>> > > >
>> > > > Thanks,
>> > > > Severin
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>>
More information about the jdk8u-dev
mailing list