-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
x86_64
-
windows_7
A DESCRIPTION OF THE REQUEST :
I filed this under classes_lang as there doesnt' seem to be a classes_naming or whatever. This RFE is about long-overdue enhancements to JNDI.
1. Make javax.naming.Context implement Autocloseable. Can't think how this got missed in Java 7.
2. Ditto javax.naming.NamingEnumeration.
3. Implement more extended LDAP operations and request/response controls. Specifically:
3.1 DynamicObjectRefresh RFC 2589
3.2 The Password Policy request/response controls and extended operations. I know there is no RFC but http://tools.ietf.org/html/draft-behera-ldap-password-policy-10 is widely implemented, e.g. by OpenLDAP for a start.
3.3 WhoAmI extended request RFC 4532
3.4 PostRead request control RFC 4527
3.5 NotifyRequest control OID 1.2.840.113556.1.4.528
3.6 DirSync request control OID 1.2.840.113556.1.4.841
3.7 Deleted request control OID 1.2.840.113556.1.4.417
You should really implement a full set, as seen e.g. in the UnboundID LDAP API.
4. Provide a supported means of implementing extended requests and responses, i.e. provided a supported and documented BER codec interface. At present you are apparently expected to either use undocumented JDK internals, add a 3rd -party package, or roll your own.
JUSTIFICATION :
JNDI hasn't had a serious overhaul in over a decade apart from adding Generics in 1.5.
The missing features mentioned would bring it into line with Java 7 let alone Java 8.
Their absence limits its applicability in modern LDAP environments.
Please note that items 1 and 2 can be implemented at the stroke of a pen, plus test cases.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
This is an RFE. I expect to see all the features above supported.
CUSTOMER SUBMITTED WORKAROUND :
The 'workaround' to lack of AutoCloseable is to not use try-with-resources.
I've written my own extended operation/request/response package but I shouldn't have to do this. Due to the absence of documentation of the internal BER codec I have had to base it on a third party package so I am not dependent on JDK internals. I used the old Netscape LDAP API. I shouldn't have to do that either. It's just code bloat given there already is a functioning BER codec in the JRE.
I filed this under classes_lang as there doesnt' seem to be a classes_naming or whatever. This RFE is about long-overdue enhancements to JNDI.
1. Make javax.naming.Context implement Autocloseable. Can't think how this got missed in Java 7.
2. Ditto javax.naming.NamingEnumeration.
3. Implement more extended LDAP operations and request/response controls. Specifically:
3.1 DynamicObjectRefresh RFC 2589
3.2 The Password Policy request/response controls and extended operations. I know there is no RFC but http://tools.ietf.org/html/draft-behera-ldap-password-policy-10 is widely implemented, e.g. by OpenLDAP for a start.
3.3 WhoAmI extended request RFC 4532
3.4 PostRead request control RFC 4527
3.5 NotifyRequest control OID 1.2.840.113556.1.4.528
3.6 DirSync request control OID 1.2.840.113556.1.4.841
3.7 Deleted request control OID 1.2.840.113556.1.4.417
You should really implement a full set, as seen e.g. in the UnboundID LDAP API.
4. Provide a supported means of implementing extended requests and responses, i.e. provided a supported and documented BER codec interface. At present you are apparently expected to either use undocumented JDK internals, add a 3rd -party package, or roll your own.
JUSTIFICATION :
JNDI hasn't had a serious overhaul in over a decade apart from adding Generics in 1.5.
The missing features mentioned would bring it into line with Java 7 let alone Java 8.
Their absence limits its applicability in modern LDAP environments.
Please note that items 1 and 2 can be implemented at the stroke of a pen, plus test cases.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
This is an RFE. I expect to see all the features above supported.
CUSTOMER SUBMITTED WORKAROUND :
The 'workaround' to lack of AutoCloseable is to not use try-with-resources.
I've written my own extended operation/request/response package but I shouldn't have to do this. Due to the absence of documentation of the internal BER codec I have had to base it on a third party package so I am not dependent on JDK internals. I used the old Netscape LDAP API. I shouldn't have to do that either. It's just code bloat given there already is a functioning BER codec in the JRE.