You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2005/03/01 18:47:30 UTC
[mina] SSL
Hi all,
Anyone looking into writing an SSL filter for mina?
If so, how is it going? Could you share or contribute this code back to
this project.
Thanks,
Alex
Re: [mina] An established connection was aborted by the software in your host machine
Posted by Trustin Lee <tr...@gmail.com>.
On Tue, 8 Mar 2005 10:24:37 +0100, Jan Andersson <ja...@minq.se> wrote:
>
> >> I can't see any way to set the socket timeout in Mina though?
> >> Is there a way or do I have to change the Mina source directly?
> >
> > You'll have to down-cast your SessionConfig to SocketSessionConfig.
>
> Still don't see any setSoTimeout() or similar in SocketSessionConfig?
> May be I'm blind? ;)
Oops, yes, you're right. I was thinking wrong. There is no SoTimeout
property there becaue MINA works in non-blocking mode. Does SoTimeout
affect the behavior even in non-blocking mode? I'm not sure, but it
worths a try. You'll have to modify the SocketIoProcessor.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] An established connection was aborted by the software in your host machine
Posted by Jan Andersson <ja...@minq.se>.
>> I can't see any way to set the socket timeout in Mina though?
>> Is there a way or do I have to change the Mina source directly?
>
> You'll have to down-cast your SessionConfig to SocketSessionConfig.
Still don't see any setSoTimeout() or similar in SocketSessionConfig?
May be I'm blind? ;)
/Janne
Re: [mina] An established connection was aborted by the software in your host machine
Posted by Trustin Lee <tr...@gmail.com>.
Hi,
On Tue, 8 Mar 2005 09:22:47 +0100, Jan Andersson <ja...@minq.se> wrote:
>
> Trustin,
>
> >> Has anyone seen the following exception being thrown by Mina:
> >>
> >> java.io.IOException: An established connection was aborted by the
> >> software in your host machine
> >
> > This error can occur when the local network system aborts a
> > connection, such as when WinSock closes an established connection
> > after data retransmission fails (receiver never acknowledges data
> > sent). Possibly due to a data transmission timeout or protocol error.
> >
> > It might be resolved by increasing socket timeout value, but I'm not
> > sure. Could you try it and tell us the result if you don't mind?
>
> Yes, I will try this.
> I can't see any way to set the socket timeout in Mina though?
> Is there a way or do I have to change the Mina source directly?
You'll have to down-cast your SessionConfig to SocketSessionConfig.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] An established connection was aborted by the software in your host machine
Posted by Jan Andersson <ja...@minq.se>.
Trustin,
>> Has anyone seen the following exception being thrown by Mina:
>>
>> java.io.IOException: An established connection was aborted by the
>> software in your host machine
>
> This error can occur when the local network system aborts a
> connection, such as when WinSock closes an established connection
> after data retransmission fails (receiver never acknowledges data
> sent). Possibly due to a data transmission timeout or protocol error.
>
> It might be resolved by increasing socket timeout value, but I'm not
> sure. Could you try it and tell us the result if you don't mind?
Yes, I will try this.
I can't see any way to set the socket timeout in Mina though?
Is there a way or do I have to change the Mina source directly?
/Janne
Re: [mina] An established connection was aborted by the software in your host machine
Posted by Trustin Lee <tr...@gmail.com>.
Hi Janne,
On Mon, 7 Mar 2005 10:33:00 +0100, Jan Andersson <ja...@minq.se> wrote:
> Has anyone seen the following exception being thrown by Mina:
>
> java.io.IOException: An established connection was aborted by the
> software in your host machine
This error can occur when the local network system aborts a
connection, such as when WinSock closes an established connection
after data retransmission fails (receiver never acknowledges data
sent). Possibly due to a data transmission timeout or protocol error.
It might be resolved by increasing socket timeout value, but I'm not
sure. Could you try it and tell us the result if you don't mind?
Thanks,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
[mina] An established connection was aborted by the software in your host machine
Posted by Jan Andersson <ja...@minq.se>.
Has anyone seen the following exception being thrown by Mina:
java.io.IOException: An established connection was aborted by the
software in your host machine
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:25)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233)
at sun.nio.ch.IOUtil.read(IOUtil.java:200)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207)
at
org.apache.mina.io.socket.SocketIoProcessor.read(SocketIoProcessor.java:
242)
at
org.apache.mina.io.socket.SocketIoProcessor.processSessions(SocketIoProc
essor.java:216)
at
org.apache.mina.io.socket.SocketIoProcessor.access$300(SocketIoProcessor
.java:41)
at
org.apache.mina.io.socket.SocketIoProcessor$Worker.run(SocketIoProcessor
.java:496)
I get this (occasionally) for a Mina based server when running quite a
lot of
clients (5-6000). The server is using Java 1.5 and running on a windows
box.
/Janne
Re: [mina] SSL
Posted by Enrique Rodriguez <er...@apache.org>.
Jan Andersson wrote:
> Hi,
>
>> Anyone looking into writing an SSL filter for mina?
>> If so, how is it going? Could you share or contribute this code back
>> to this project.
>
>
> I have implemented an SSL filer for Mina, based on SSLEngine,
> available with Java 1.5.
>
> I'm doing this for a customer, but I will check with them if I'm
> allowed to share it and if an 1.5 solution is of any interest?
I'm fine with 1.5. I would like to see it contributed.
-enrique
>
> My filter works fine, but some polishing is required before I
> want anyone else to see it ;)
>
> /Janne
Re: [mina] SSL
Posted by Alex Karasulu <ao...@bellsouth.net>.
Jan Andersson wrote:
> Hi,
>
> I would like to contribute my SSL filter code for Mina, but how?
> I could send it in an e-mail, post it on the web somewhere or
> whatever.
>
You can put it into a JIRA as an attachment. Like a diff that is an
attachment to an improvement or feature request would be great.
Thanks Jan!
Alex
> The code probably need som polishing etc, but it should be
> a start...
>
> /Janne
>
>
Re: [mina] SSL
Posted by Trustin Lee <tr...@gmail.com>.
On Mon, 7 Mar 2005 21:51:08 +0100, Jan Andersson <ja...@minq.se> wrote:
> Great. It's added in JIRA.
Thank you for your contribution! I'll look into it and add it to the
repository after some tests. :D
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: [mina] SSL
Posted by Jan Andersson <ja...@minq.se>.
> On 2005-03-07, at 21:21, Enrique Rodriguez wrote:
>
> Thanks. I'm volunteering to handle the integration into the codebase
> and help keep it maintained. As Alex mentioned, I'll pick it up off
> JIRA.
Great. It's added in JIRA.
/Janne
Re: [mina] SSL
Posted by Enrique Rodriguez <er...@apache.org>.
Jan Andersson wrote:
> Hi,
>
> I would like to contribute my SSL filter code for Mina, but how?
> I could send it in an e-mail, post it on the web somewhere or
> whatever.
Thanks. I'm volunteering to handle the integration into the codebase
and help keep it maintained. As Alex mentioned, I'll pick it up off JIRA.
> The code probably need som polishing etc, but it should be
> a start...
np, first the shoes, then the shine.
-enrique
>
> /Janne
[mina] SSL
Posted by Jan Andersson <ja...@minq.se>.
Hi,
I would like to contribute my SSL filter code for Mina, but how?
I could send it in an e-mail, post it on the web somewhere or
whatever.
The code probably need som polishing etc, but it should be
a start...
/Janne
Re: [mina] SSL
Posted by Alex Karasulu <ao...@bellsouth.net>.
There he is. Hi Jan.
Jan Andersson wrote:
> Hi,
>
>> Anyone looking into writing an SSL filter for mina?
>> If so, how is it going? Could you share or contribute this code back
>> to this project.
>
>
> I have implemented an SSL filer for Mina, based on SSLEngine,
> available with Java 1.5.
Very cool.
>
> I'm doing this for a customer, but I will check with them if I'm
> allowed to share it and if an 1.5 solution is of any interest?
Absolutely. We can move there on the 0.9 trunk in dev now. I'm up for
it if others are. Perhaps we can make it plugable too so for SSL users
can go to JDK 5.0 and use this feature.
>
> My filter works fine, but some polishing is required before I
> want anyone else to see it ;)
No worries its just nice to see someone has done it. We'd love the
contribution when you are ready.
Cheers,
Alex
Re: [mina] SSL
Posted by Jan Andersson <ja...@minq.se>.
Hi,
> Anyone looking into writing an SSL filter for mina?
> If so, how is it going? Could you share or contribute this code back
> to this project.
I have implemented an SSL filer for Mina, based on SSLEngine,
available with Java 1.5.
I'm doing this for a customer, but I will check with them if I'm
allowed to share it and if an 1.5 solution is of any interest?
My filter works fine, but some polishing is required before I
want anyone else to see it ;)
/Janne
Re: [mina] SSL
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
>> That's great David. I though one other person as well was working on
>> an SSL filter. Perhaps you can combine forces if need be. Just
>> trying to see if we can get a response from him as well.
>
>
> Sure, any help is appreciated. However we are aiming to have SSL done
> in a few days, so he'd need to re-surface quite quickly.
Looking forward to it David. Keep groking ... if he turns up he turns up.
Thanks
Re: [mina] SSL
Posted by David Boreham <da...@bozemanpass.com>.
> That's great David. I though one other person as well was working on an
> SSL filter. Perhaps you can combine forces if need be. Just trying to
> see if we can get a response from him as well.
Sure, any help is appreciated. However we are aiming to
have SSL done in a few days, so he'd need to re-surface
quite quickly.
Re: LDAP Controls
Posted by Enrique Rodriguez <er...@apache.org>.
David Boreham wrote:
<snip/>
>> to rewrite it. I hope we keep our focus and make sure for the sake of
>> easily adding controls we make the decoder encoder pair extensible for
>> the variable payloads of Controls.
>
> I think you're imagining this to be more than it needs to be.
> Instead just punt the encoding/decoding
> of controls to the code that uses them. If I add a whizbang-special control
> that is used in my whizbang-special custom back-end, then I need to write
> code to encode and decode that control. Just make the raw BER control
> payload available to my code and I'm happy. So in the request message
> parser, when you see controls, only parse them down to a collection of
> OIDs and payload BER. Similarly when encoding a response message,
> take a collection of OIDs and payload BER that may have already been
> placed in the controls collection during operation processing.
> Of course encoder/decoders
> for common controls can be supplied in canned form, that's fine too.
> I think where you're headed is a science project : much easier to just
> say that if you use a control, then you have responsibility for its
> encoding
> and leave it at that.
This sounds like the same problem Kerberos has, but instead of controls
Kerberos has encrypted data payload (a DER octet string) which needs to
be decrypted into raw DER and decoded again. The choice of the key used
in decryption needs to be made in the handler, so that's where the
crypto takes place and I have to maintain my own canned encoder/decoder
pairs. So, I don't expect the Apache ASN.1 library to handle this for
me; one-shot stateless codecs makes sense here.
-enrique
Re: LDAP Controls
Posted by David Boreham <da...@bozemanpass.com>.
> More so than this being a BER issue was the fact that the control can
> have any structure. We had no clue what would be a registered control so
> what could we do? I guess with the present decoder which will be ousted
> you could add rules for processing a specific control pretty easily.
> There's a rule based digester approach. Extensibility of the digester is
> high but its a tough thing to maintain, hence the desire to rewrite it. I
> hope we keep our focus and make sure for the sake of easily adding
> controls we make the decoder encoder pair extensible for the variable
> payloads of Controls.
I think you're imagining this to be more than it needs to be.
Instead just punt the encoding/decoding
of controls to the code that uses them. If I add a whizbang-special control
that is used in my whizbang-special custom back-end, then I need to write
code to encode and decode that control. Just make the raw BER control
payload available to my code and I'm happy. So in the request message
parser, when you see controls, only parse them down to a collection of
OIDs and payload BER. Similarly when encoding a response message,
take a collection of OIDs and payload BER that may have already been
placed in the controls collection during operation processing.
Of course encoder/decoders
for common controls can be supplied in canned form, that's fine too.
I think where you're headed is a science project : much easier to just
say that if you use a control, then you have responsibility for its encoding
and leave it at that.
> Hmmmm I don't like the passing around idea which changes interfaces and
> signatures (API/SPIs). The operation information can be stuffed into the
> JNDI Context as we spoke about within the Env or even within the
> LdapServerContext which implements LdapContext in the server side JNDI
> provider. Perhaps we even allow access to the session this way. I don't
> like the env sometime because I think these objects can be removed from
> it. Access via type safe methods might be better.
I think we're saying the same thing here. Perhaps an example will help:
Currently we have methods on the partition classes something like this:
delete (delete_this_dn)
If, inside the implementation of the delete operation, it turns out
that we need access to more information than the identity of the
entry to delete, we're out of luck.
I'm saying that we need interfaces like this:
delete (delete_this_dn, some_context_object)
So, when we need access to more information about the
session or the operation, we can get it
(directly or indirectly) from that context object.
I don't much care what type the context object has:
the JNDI context is fine, the LdapContext is fine.
All I care about is that it exists ;)
Re: LDAP Controls
Posted by David Boreham <da...@bozemanpass.com>.
Noel J. Bergman wrote:
>>We're talking major changes to the design. I'm fine with this though
>>however I'd like to make sure we have listed all our options.
>>
>>
>
>If we're going to look at design/interface changes, I see a generic issue
>here:
>
> public void handle( ProtocolSession session, Object request )
>
>In my view, there should be a request object that is the single point from
>which ALL necessary information required to service the request is exposed,
>including the session and any objects that components of the processing
>chain might wish to add as attributes of the request.
>
>
Agree.
RE: LDAP Controls
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We're talking major changes to the design. I'm fine with this though
> however I'd like to make sure we have listed all our options.
If we're going to look at design/interface changes, I see a generic issue
here:
public void handle( ProtocolSession session, Object request )
In my view, there should be a request object that is the single point from
which ALL necessary information required to service the request is exposed,
including the session and any objects that components of the processing
chain might wish to add as attributes of the request.
--- Noel
Re: LDAP Controls
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
>>> The current code doesn't seem to allow easy access
>>> to the LDAP controls from inside a back end (the
>>> JNDI controls class doesn't handle arbitrary
>>> controls, I believe).
>>
>>
>> I was wondering that myself. After looking at the javadocs I think
>> its actually only capable of handling arbitrary controls. Here's why
>> ...
>
>
> Hmm...I was looking at:
> http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/directory/SearchControls.html
>
>
>> First because it's an interface so it must be implemented. It only
>> contains the 3 general property accessor methods that apply to all
>> controls:
>>
>> String getID() ==> gets the control's OID
>> boolean isCritical() ==> the criticality
>> byte[] getEncodedValue() ==> the ASN.1 BER encoded representation of
>> the control
>
>
> You're looking somewhere else, but where... ?
> Ah, here:
> http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/Control.html
>
Yeah that's it.
> Ok, we may be talking at cross-purposes. What I'm saying is that
> I see generally good stuff relating to controls in the message/request
> code, e.g. here:
> http://svn.apache.org/viewcvs.cgi/incubator/directory/ldap/tags/internal-release-0.8/common/src/java/org/apache/ldap/common/message/Message.java?rev=125226&view=markup
>
>
Yeah we have it in the POJO's.
> However, these objects do not seem to be propagated back to the
> back-ends.
> E.g. they are lost by the time we get to here :
> http://svn.apache.org/viewcvs.cgi/incubator/directory/apacheds/trunk/protocol/src/main/java/org/apache/ldap/server/protocol/SearchHandler.java?rev=151811&view=markup
>
> This is the problem I was concerned about. I can see that a similar
> issue arose with __filter__, and it's added to the context envionment
> in SearchHandler.handle(). I'm proposing (for now , until a more
> elegant solution is found) to add the controls there too.
>
Sure we can do that. However if they are to go into the context
environment shouldn't we put them where they belong here in the LDAP
context?
http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/ldap/LdapContext.html
Here the LDAP specific context can carry the session, request, and
response controls. One can also set the response controls: there is a
setter unlike for the other controls. This is definately a good hook.
> I agree that the fact that the controls are not parsed nor sent is
> also a problem ;) However, that's just a bit of BER, no problem really.
More so than this being a BER issue was the fact that the control can
have any structure. We had no clue what would be a registered control
so what could we do? I guess with the present decoder which will be
ousted you could add rules for processing a specific control pretty
easily. There's a rule based digester approach. Extensibility of the
digester is high but its a tough thing to maintain, hence the desire to
rewrite it. I hope we keep our focus and make sure for the sake of
easily adding controls we make the decoder encoder pair extensible for
the variable payloads of Controls.
>> So this covers the full gambit of controls. We just need to
>> implement them and perhaps give implementations nice decoded
>> accessors. Let the control know how to (decode) handle access to its
>> elements. This may not be that easy to do. I think our approach in
>> the line protocol side that handles the decoding can help out. We
>> know that controls must be registered and cannot be adhoc: supported
>> controls must be present within the RootDSE.
>
>
> Yes, encoding and decoding controls is not a big problem.
>
>> We can easiler decode and populate registered controls that still
>> implement this JNDI Control interface. They simply have control
>
>
> Yes, yes, absolutely.
>
>> I think we can do that with the context through additions to the
>> environment and properties.
>
>
> Ok, that's the current approach we're taking (to get
> something that works quickly at least).
Yeah I take back my comment above after I remembered the LdapContext
interfaces for supporting Controls. You agree?
>
>>> I realize this isn't great 'object design perfection',
>>> but OTOH it's a real pain to be always finding that
>>> there's no way to get the @*@#^ thing that you
>>> need in your code 15 levels down the stack from
>>> where it was last seen...
>>>
>> I know what you mean. Perhaps we can use a ThreadLocal to hold a
>> reference to the context associated with the operation. What do you
>> think?
>
>
> I think : bad idea. TLS only to be used in dire emergencies, which
> this isn't. I think better to add a session (and also operation) context
> object that is widely passed around. All servers I've ever worked on
> had this design, and I still think it's a good one.
>
Hmmmm I don't like the passing around idea which changes interfaces and
signatures (API/SPIs). The operation information can be stuffed into
the JNDI Context as we spoke about within the Env or even within the
LdapServerContext which implements LdapContext in the server side JNDI
provider. Perhaps we even allow access to the session this way. I
don't like the env sometime because I think these objects can be removed
from it. Access via type safe methods might be better.
We're talking major changes to the design. I'm fine with this though
however I'd like to make sure we have listed all our options.
>>> The particular example at hand is a syncronization
>>> control that carries an update vector used in the
>>> back-end to determine the set of entries modified
>>> since that update vector was generated.
>>>
>> So this is list a control for batching updates? Is this a published
>> control or one you devised - just curious?
>
>
> Not for batching, more for sync. It has been published
> as an RFC, but is currently defunct:
> http://quimby.gnus.org/internet-drafts/draft-armijo-ldap-dirsync-00.txt
> There is at least one existing vendor imlpementation however (and soon
> a second ;)
> Note that I would not necessarily advocate using this control
> generally, we're implementing support for it for interoperability
> reasons. Some good lightweight client sync addition to LDAP
> would be useful however. This work was being done in the
> LCUP IETF working group. This is the latest state of
> that work: http://www.ietf.org/rfc/rfc3928.txt
> I'm not sure if any vendor has implemented the LCUP
> protocol though.
>
We may need to be the first with LCUP ;) first maybe we can get 2251
right though hehe.
>>> Another example would be indexed VLV searches, where
>>> the back-end needs access to the VLV control payload
>>> to drive its query execution engine.
>>
>>
>> Hmmm good point. So let me just ask directly once again so I
>> understand this correctly. You're saying the Controls are not
>> available to you because the context is not available within your
>> backend partition?
>
>
> Yes, spot on.
>
Ok we must change this - let's work out exactly how we're going to do it
in the right way. It might take only a tiny bit longer.
Regards,
Alex
Re: LDAP Controls
Posted by David Boreham <da...@bozemanpass.com>.
>> The current code doesn't seem to allow easy access
>> to the LDAP controls from inside a back end (the
>> JNDI controls class doesn't handle arbitrary
>> controls, I believe).
>
> I was wondering that myself. After looking at the javadocs I think its
> actually only capable of handling arbitrary controls. Here's why ...
Hmm...I was looking at:
http://java.sun.com/j2se/1.4.2/docs/api/javax/naming/directory/SearchControls.html
> First because it's an interface so it must be implemented. It only
> contains the 3 general property accessor methods that apply to all
> controls:
>
> String getID() ==> gets the control's OID
> boolean isCritical() ==> the criticality
> byte[] getEncodedValue() ==> the ASN.1 BER encoded representation of the
> control
You're looking somewhere else, but where... ?
Ah, here:
http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/Control.html
Ok, we may be talking at cross-purposes. What I'm saying is that
I see generally good stuff relating to controls in the message/request
code, e.g. here:
http://svn.apache.org/viewcvs.cgi/incubator/directory/ldap/tags/internal-release-0.8/common/src/java/org/apache/ldap/common/message/Message.java?rev=125226&view=markup
However, these objects do not seem to be propagated back to the back-ends.
E.g. they are lost by the time we get to here :
http://svn.apache.org/viewcvs.cgi/incubator/directory/apacheds/trunk/protocol/src/main/java/org/apache/ldap/server/protocol/SearchHandler.java?rev=151811&view=markup
This is the problem I was concerned about. I can see that a similar
issue arose with __filter__, and it's added to the context envionment
in SearchHandler.handle(). I'm proposing (for now , until a more
elegant solution is found) to add the controls there too.
I agree that the fact that the controls are not parsed nor sent is
also a problem ;) However, that's just a bit of BER, no problem really.
> So this covers the full gambit of controls. We just need to implement
> them and perhaps give implementations nice decoded accessors. Let the
> control know how to (decode) handle access to its elements. This may not
> be that easy to do. I think our approach in the line protocol side that
> handles the decoding can help out. We know that controls must be
> registered and cannot be adhoc: supported controls must be present within
> the RootDSE.
Yes, encoding and decoding controls is not a big problem.
> We can easiler decode and populate registered controls that still
> implement this JNDI Control interface. They simply have control
Yes, yes, absolutely.
> I think we can do that with the context through additions to the
> environment and properties.
Ok, that's the current approach we're taking (to get
something that works quickly at least).
>> I realize this isn't great 'object design perfection',
>> but OTOH it's a real pain to be always finding that
>> there's no way to get the @*@#^ thing that you
>> need in your code 15 levels down the stack from
>> where it was last seen...
>>
> I know what you mean. Perhaps we can use a ThreadLocal to hold a
> reference to the context associated with the operation. What do you
> think?
I think : bad idea. TLS only to be used in dire emergencies, which
this isn't. I think better to add a session (and also operation) context
object that is widely passed around. All servers I've ever worked on
had this design, and I still think it's a good one.
>> The particular example at hand is a syncronization
>> control that carries an update vector used in the
>> back-end to determine the set of entries modified
>> since that update vector was generated.
>>
> So this is list a control for batching updates? Is this a published
> control or one you devised - just curious?
Not for batching, more for sync. It has been published
as an RFC, but is currently defunct:
http://quimby.gnus.org/internet-drafts/draft-armijo-ldap-dirsync-00.txt
There is at least one existing vendor imlpementation however (and soon a
second ;)
Note that I would not necessarily advocate using this control
generally, we're implementing support for it for interoperability
reasons. Some good lightweight client sync addition to LDAP
would be useful however. This work was being done in the
LCUP IETF working group. This is the latest state of
that work: http://www.ietf.org/rfc/rfc3928.txt
I'm not sure if any vendor has implemented the LCUP
protocol though.
>> Another example would be indexed VLV searches, where
>> the back-end needs access to the VLV control payload
>> to drive its query execution engine.
>
> Hmmm good point. So let me just ask directly once again so I understand
> this correctly. You're saying the Controls are not available to you
> because the context is not available within your backend partition?
Yes, spot on.
Re: LDAP Controls
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
> Heads up on one thing we're working on here:
>
> We're writing a new Backend class.
> It needs to implement special behavior depending on the presence and
> value of an LDAP control
> attached to the operation request PDU.
Presently there is no support in the LDAP line protocol code. Meaning
the controls are not included in the Request/Response. Yeah
disappointing I know. We can get it in there quickly though.
>
> The current code doesn't seem to allow easy access
> to the LDAP controls from inside a back end (the
> JNDI controls class doesn't handle arbitrary
> controls, I believe).
I was wondering that myself. After looking at the javadocs I think its
actually only capable of handling arbitrary controls. Here's why ...
First because it's an interface so it must be implemented. It only
contains the 3 general property accessor methods that apply to all controls:
String getID() ==> gets the control's OID
boolean isCritical() ==> the criticality
byte[] getEncodedValue() ==> the ASN.1 BER encoded representation of the
control
So this covers the full gambit of controls. We just need to implement
them and perhaps give implementations nice decoded accessors. Let the
control know how to (decode) handle access to its elements. This may
not be that easy to do. I think our approach in the line protocol side
that handles the decoding can help out. We know that controls must be
registered and cannot be adhoc: supported controls must be present
within the RootDSE.
We can easiler decode and populate registered controls that still
implement this JNDI Control interface. They simply have control
specific accessors to the decoded elements of the control whatever they
may be. This way the control is pumped into the server side JNDI
context and eventually the methods on a backend to access the control.
Based on the OID the controls can be cast into the implementation type
to access control specific information.
>
> Anyway, at present we're hacking the controls
> object that comes with the Request into the env Map
> that's passed to the back end 's search method.
> That should work for what we need to do,
> but it's an evil hack.
>
> I was wondering what the plans are for things like this?
Well I thought controls would come up and I was looking for someone to
pick up the torch here. Lead us to an overall approach for them. I
have some ideas though. Above I mentioned some of them.
> Typically one sees a catch-all 'context' or 'session' object
> that's passed in every call, that allows code anywhere to
> get at things like the authId for the current operation,
> things like that, with accessor methods. Such an object could also be
> used
> to access controls (and also write response controls
> back onto the response).
I think we can do that with the context through additions to the
environment and properties.
>
> I realize this isn't great 'object design perfection',
> but OTOH it's a real pain to be always finding that
> there's no way to get the @*@#^ thing that you
> need in your code 15 levels down the stack from
> where it was last seen...
>
I know what you mean. Perhaps we can use a ThreadLocal to hold a
reference to the context associated with the operation. What do you think?
> The particular example at hand is a syncronization
> control that carries an update vector used in the
> back-end to determine the set of entries modified
> since that update vector was generated.
>
So this is list a control for batching updates? Is this a published
control or one you devised - just curious?
> Another example would be indexed VLV searches, where
> the back-end needs access to the VLV control payload
> to drive its query execution engine.
Hmmm good point. So let me just ask directly once again so I understand
this correctly. You're saying the Controls are not available to you
because the context is not available within your backend partition?
Alex
LDAP Controls
Posted by David Boreham <da...@bozemanpass.com>.
Heads up on one thing we're working on here:
We're writing a new Backend class.
It needs to implement special behavior depending
on the presence and value of an LDAP control
attached to the operation request PDU.
The current code doesn't seem to allow easy access
to the LDAP controls from inside a back end (the
JNDI controls class doesn't handle arbitrary
controls, I believe).
Anyway, at present we're hacking the controls
object that comes with the Request into the env Map
that's passed to the back end 's search method.
That should work for what we need to do,
but it's an evil hack.
I was wondering what the plans are for things like this?
Typically one sees a catch-all 'context' or 'session' object
that's passed in every call, that allows code anywhere to
get at things like the authId for the current operation,
things like that, with accessor methods.
Such an object could also be used
to access controls (and also write response controls
back onto the response).
I realize this isn't great 'object design perfection',
but OTOH it's a real pain to be always finding that
there's no way to get the @*@#^ thing that you
need in your code 15 levels down the stack from
where it was last seen...
The particular example at hand is a syncronization
control that carries an update vector used in the
back-end to determine the set of entries modified
since that update vector was generated.
Another example would be indexed VLV searches, where
the back-end needs access to the VLV control payload
to drive its query execution engine.
Re: [mina] SSL
Posted by Alex Karasulu <ao...@bellsouth.net>.
David Boreham wrote:
>> Anyone looking into writing an SSL filter for mina?
>
>
> Yes.
>
>> If so, how is it going?
>
>
> Started thinking about it yesterday (when I discovered no
> exisiting SSL support ;)
>
>> Could you share or contribute this code back to this project.
>
>
> Yes.
That's great David. I though one other person as well was working on an
SSL filter. Perhaps you can combine forces if need be. Just trying to
see if we can get a response from him as well.
Cheers,
Alex
Re: [mina] SSL
Posted by David Boreham <da...@bozemanpass.com>.
> Anyone looking into writing an SSL filter for mina?
Yes.
> If so, how is it going?
Started thinking about it yesterday (when I discovered no
exisiting SSL support ;)
> Could you share or contribute this code back to
> this project.
Yes.