You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Marc Boorshtein <mb...@gmail.com> on 2021/12/28 17:12:50 UTC
Geting extended request bytes
I'm migrating MyVirtualDirectory from 2.0.0-M20 to 2.0.0-M27. I'm hung up
on trying to handle Extended requests. In 2.0.0-M20 I was able to get the
generic request to ExtendedRequestDecorator and getting the request value.
That doesn't seem like an option in 2.0.0-M27. I'm struggling to backtrack
any of the prebuilt extended handlers back to binary. Where are bytes
buying translated into individual extended handler implementations? Any
pointers would be appreciated.
Thanks
Marc
Re: Geting extended request bytes
Posted by Emmanuel Lécharny <el...@gmail.com>.
Great !
Consider that to be my new year day present ;-)
Also it's an most needed improvment !
On 10/01/2022 17:50, Marc Boorshtein wrote:
> Thanks again Emmanuel, this did the trick!
>
> On Fri, Jan 7, 2022 at 11:19 AM Marc Boorshtein <mboorshtein@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> I just committed the hierarchy change.
>
>
> Fantastic! Thank you.
>
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Geting extended request bytes
Posted by Marc Boorshtein <mb...@gmail.com>.
Thanks again Emmanuel, this did the trick!
On Fri, Jan 7, 2022 at 11:19 AM Marc Boorshtein <mb...@gmail.com>
wrote:
>
>> I just committed the hierarchy change.
>>
>>
> Fantastic! Thank you.
>
Re: Geting extended request bytes
Posted by Marc Boorshtein <mb...@gmail.com>.
>
>
> I just committed the hierarchy change.
>
>
Fantastic! Thank you.
Re: Geting extended request bytes
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Marc,
I just committed the hierarchy change.
Now, for any extRequest you can grap the value as a byte[], you just
need to cast the instance to OpaqueExtendedRequest.
On 06/01/2022 23:09, Marc Boorshtein wrote:
>
>
>
> the PasswordModify extended request is natively supported by the LDAP
> API, there is no need to cast it. The class hierarchy is the following:
>
> [[AbstractRequest]]
> ^
> |
> +-- [[AbstractExtendedReques]]
> | ^
> | |
> | +-- [PasswordModifyRequestImpl]
> |
> +-- [OpaqueExtendedRequest]
>
> It's a bbit a pity we havn't made the OpaqueExtendedRequest class
> extending the AbstractExtendedReques class, but anyway.
>
>
> Right, I never want to cast an extended request to an existing class.
> We're a virtual directory so we'll pass it through directly downstream
> unless operated on by the user. Is there a way to disable casting to a
> specific implementation? Would excluding the existing implementations
> listed below force everything to OpaqueExtendedRequest?
>
> Thanks
> Marc
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Geting extended request bytes
Posted by Emmanuel Lécharny <el...@gmail.com>.
On 06/01/2022 23:09, Marc Boorshtein wrote:
>
>
>
> the PasswordModify extended request is natively supported by the LDAP
> API, there is no need to cast it. The class hierarchy is the following:
>
> [[AbstractRequest]]
> ^
> |
> +-- [[AbstractExtendedReques]]
> | ^
> | |
> | +-- [PasswordModifyRequestImpl]
> |
> +-- [OpaqueExtendedRequest]
>
> It's a bbit a pity we havn't made the OpaqueExtendedRequest class
> extending the AbstractExtendedReques class, but anyway.
>
>
> Right, I never want to cast an extended request to an existing class.
> We're a virtual directory so we'll pass it through directly downstream
> unless operated on by the user. Is there a way to disable casting to a
> specific implementation? Would excluding the existing implementations
> listed below force everything to OpaqueExtendedRequest?
As I said, the decision we made years ago to differentiate known
extended requests and unknown ones was wrongly implemented.
We end up with two incompatible classes, while what we would have liked
to have is a class that stores the value as a byte[], with inherited
classes that have dedicated semantic semantic.
The proper hierarchy should have been :
[[AbstractRequest]]
^
|
+-- [[AbstractExtendedReques]]
^
|
+-- [OpaqueExtendedRequest]
^
|
+-- [PasswordModifyRequestImpl]
This way, you would be able to either use the opaque impl, or the
specific impl, depending on your need.
The reason we have the API designed this way is that we use factories to
create extended requests instances, and the code looks like :
ExtendedOperationFactory factory = container.getLdapCodecService().
getExtendedRequestFactories().get(
extendedRequest.getRequestName() );
// We have to handle the special case of a 0 length matched
// value
try
{
if ( factory == null )
{
if ( tlv.getLength() == 0 )
{
( ( OpaqueExtendedRequest ) extendedRequest
).setRequestValue( Strings.EMPTY_BYTES );
}
else
{
( ( OpaqueExtendedRequest ) extendedRequest
).setRequestValue( tlv.getValue().getData() );
}
}
else
{
factory.decodeValue( extendedRequest,
tlv.getValue().getData() );
}
}
If the factory can't create the specific ExtendedRequest, then it
creates an OpaqueExtendedRequest instance...
I'm pretty sure we can safely change the hierarchy without breaking
things (ie from the existing code PoV), but then that would also break
the API compatibility. Another option would be to add the intermediary
class, name it DefaultExtendedRequest, made the OpaqueExtendedRequest
deprecated and move on, except that when we create the instance, we
can't create both the Opaque and Default at the same time...
Atm, withh the current API, I see no other way than checking if the
instance is an OpaqueExtendedRequest, or not...
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Geting extended request bytes
Posted by Marc Boorshtein <mb...@gmail.com>.
>
>
>
>
> the PasswordModify extended request is natively supported by the LDAP
> API, there is no need to cast it. The class hierarchy is the following:
>
> [[AbstractRequest]]
> ^
> |
> +-- [[AbstractExtendedReques]]
> | ^
> | |
> | +-- [PasswordModifyRequestImpl]
> |
> +-- [OpaqueExtendedRequest]
>
> It's a bbit a pity we havn't made the OpaqueExtendedRequest class
> extending the AbstractExtendedReques class, but anyway.
>
>
Right, I never want to cast an extended request to an existing class.
We're a virtual directory so we'll pass it through directly downstream
unless operated on by the user. Is there a way to disable casting to a
specific implementation? Would excluding the existing implementations
listed below force everything to OpaqueExtendedRequest?
Thanks
Marc
Re: Geting extended request bytes
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Marc,
the PasswordModify extended request is natively supported by the LDAP
API, there is no need to cast it. The class hierarchy is the following:
[[AbstractRequest]]
^
|
+-- [[AbstractExtendedReques]]
| ^
| |
| +-- [PasswordModifyRequestImpl]
|
+-- [OpaqueExtendedRequest]
It's a bbit a pity we havn't made the OpaqueExtendedRequest class
extending the AbstractExtendedReques class, but anyway.
You have to check if the decoded class is not an instance of an existing
class, before casting it to an OpaqueExtendedRequest. Here are the class
that inherit directly from AbstractExtendedReques:
CancelRequestImpl
CertGenerationRequestImpl
EndTransactionRequestImpl
GracefulShutdownRequestImpl
PasswordModifyRequestImpl
StartTlsRequestImpl
StartTransactionRequestImpl
StoredProcedureRequestImpl
WhoAmIRequestImpl
On 06/01/2022 21:02, Marc Boorshtein wrote:
>
> we have replaced the ExtendedRequest/responseDecorator with the
> OpaqueExtendedRequest/Response classes.
>
> They have the gatValue() method that returns the byte[]
> containing the
> value:
>
>
> This isn't working for me. When I try to cast ExtendedRequest req
> to OpaqueExtendedRequest I get:
>
> LDAPException: Other (80) Other
> LDAPException: Server Message: OTHER: Extended operation handler for the
> specified EXTENSION_OID (1.3.6.1.4.1.4203.1.11.1) has failed to process
> your request:
> java.lang.ClassCastException: class
> org.apache.directory.api.ldap.extras.extended.pwdModify.PasswordModifyRequestImpl
> cannot be cast to class
> org.apache.directory.api.ldap.model.message.OpaqueExtendedRequest
> (org.apache.directory.api.ldap.extras.extended.pwdModify.PasswordModifyRequestImpl
> and org.apache.directory.api.ldap.model.message.OpaqueExtendedRequest
> are in unnamed module of loader 'app')
> at
> org.apache.directory.server.ldap.handlers.request.ExtendedRequestHandler.handle(ExtendedRequestHandler.java:122)
>
> It doesn't look like PasswordModifyRequestImpl can be cast. How does
> apacheds know to use a particular class implementation for an extended
> request?
>
> Thanks
> Marc
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Geting extended request bytes
Posted by Marc Boorshtein <mb...@gmail.com>.
>
>
>> we have replaced the ExtendedRequest/responseDecorator with the
>> OpaqueExtendedRequest/Response classes.
>>
>> They have the gatValue() method that returns the byte[] containing the
>> value:
>>
>>
This isn't working for me. When I try to cast ExtendedRequest req
to OpaqueExtendedRequest I get:
LDAPException: Other (80) Other
LDAPException: Server Message: OTHER: Extended operation handler for the
specified EXTENSION_OID (1.3.6.1.4.1.4203.1.11.1) has failed to process
your request:
java.lang.ClassCastException: class
org.apache.directory.api.ldap.extras.extended.pwdModify.PasswordModifyRequestImpl
cannot be cast to class
org.apache.directory.api.ldap.model.message.OpaqueExtendedRequest
(org.apache.directory.api.ldap.extras.extended.pwdModify.PasswordModifyRequestImpl
and org.apache.directory.api.ldap.model.message.OpaqueExtendedRequest are
in unnamed module of loader 'app')
at
org.apache.directory.server.ldap.handlers.request.ExtendedRequestHandler.handle(ExtendedRequestHandler.java:122)
It doesn't look like PasswordModifyRequestImpl can be cast. How does
apacheds know to use a particular class implementation for an extended
request?
Thanks
Marc
Re: Geting extended request bytes
Posted by Marc Boorshtein <mb...@gmail.com>.
>
>
>
> we have replaced the ExtendedRequest/responseDecorator with the
> OpaqueExtendedRequest/Response classes.
>
> They have the gatValue() method that returns the byte[] containing the
> value:
>
>
Thanks Emmanuel, thats what I needed! Everything compiles, so now the fun
part of getting it working :-)
Re: Geting extended request bytes
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Marc,
we have replaced the ExtendedRequest/responseDecorator with the
OpaqueExtendedRequest/Response classes.
They have the gatValue() method that returns the byte[] containing the
value:
public byte[] getRequest/ResponseValue()
That may be where you should head.
Let me know if you ned more directions.
On 28/12/2021 18:12, Marc Boorshtein wrote:
> I'm migrating MyVirtualDirectory from 2.0.0-M20 to 2.0.0-M27. I'm hung
> up on trying to handle Extended requests. In 2.0.0-M20 I was able to
> get the generic request to ExtendedRequestDecorator and getting the
> request value. That doesn't seem like an option in 2.0.0-M27. I'm
> struggling to backtrack any of the prebuilt extended handlers back to
> binary. Where are bytes buying translated into individual extended
> handler implementations? Any pointers would be appreciated.
>
> Thanks
> Marc
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecharny@busit.com https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org
Re: Geting extended request bytes
Posted by Marc Boorshtein <mb...@gmail.com>.
That would be awesome, thanks!
On Tue, Dec 28, 2021 at 12:25 PM Emmanuel Lecharny <el...@apache.org>
wrote:
> Hi Marc,
>
> I can give you an answer in 4 days when I’ll be back in front of my
> computer…
>
> Din’t forget to ping me!
>
> Le mar. 28 déc. 2021 à 17:13, Marc Boorshtein <mb...@gmail.com> a
> écrit :
>
>> I'm migrating MyVirtualDirectory from 2.0.0-M20 to 2.0.0-M27. I'm hung
>> up on trying to handle Extended requests. In 2.0.0-M20 I was able to get
>> the generic request to ExtendedRequestDecorator and getting the request
>> value. That doesn't seem like an option in 2.0.0-M27. I'm struggling to
>> backtrack any of the prebuilt extended handlers back to binary. Where are
>> bytes buying translated into individual extended handler implementations?
>> Any pointers would be appreciated.
>>
>> Thanks
>> Marc
>>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Geting extended request bytes
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi Marc,
I can give you an answer in 4 days when I’ll be back in front of my
computer…
Din’t forget to ping me!
Le mar. 28 déc. 2021 à 17:13, Marc Boorshtein <mb...@gmail.com> a
écrit :
> I'm migrating MyVirtualDirectory from 2.0.0-M20 to 2.0.0-M27. I'm hung up
> on trying to handle Extended requests. In 2.0.0-M20 I was able to get the
> generic request to ExtendedRequestDecorator and getting the request value.
> That doesn't seem like an option in 2.0.0-M27. I'm struggling to backtrack
> any of the prebuilt extended handlers back to binary. Where are bytes
> buying translated into individual extended handler implementations? Any
> pointers would be appreciated.
>
> Thanks
> Marc
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com