Thanks Emmanuel! in the Studio JNDI removal branch I had one compile error, because there is still code that converts response controls to JNDI, I also have to remove that :)
Otherwise in SSL/StartTLS tests I see two kind of exceptions: 1. PROTOCOL_ERROR: The server will disconnect 2. java.lang.ClassCastException: org.apache.directory.api.ldap.model.message.extended.NoticeOfDisconnect cannot be cast to org.apache.directory.api.ldap.model.message.OpaqueExtendedResponse I'll investigate... Kind Regards, Stefan On 1/1/19 12:39 PM, Emmanuel Lécharny wrote: > Hi and happy new years ! > > 2019 starts quite well: I'm done with the refactoring :-) Everything has > been pushed this morning ( I wish I would have been able to do it > yesterday, but at 2AM, after a party I was attending was over, I was too > tired to figure oiut what was wrong, so I just added a comment in the > code saying 'This is here that you need to look at' ) > > So, it's a big refactoring, and it's not completely over. As a sum up, > here are the big changes: > > - we do encode operations in revert order. That means we don't > pre-compute the PDU size before feeding the buffer, we feed a > fixed-sized, expandable buffer from the bottom. The idea is to avoid > computing a value, and to use a buffer that will be stored in the > ThreadLocalStorage later one, avoiding an allocation for each operation > (less GC, less CPU) > > - The decorators are GONE ! We use factories instead, which make it > easier to add a new control or extended operation. Those factories are > used to create a new Control/ExtOp/IntermediateResp, encode and decode > their values. The code is smaller (around 8000 lines of code have been > removed, not counting tests), and hopefully better. > > - Many bugs were fixed in controls/extop. It's quite surprising to find > out that some of the controls were silply not properly encoded or decoded ! > > - The server wasn't properly managing exceptions, and the > NoticeOfDisconnect was never received by the client, simply because the > server was closing the connection *before* this extendedResponse was > sent. That made the server-integ last longer than expected, most of the > tests that expected such a disconnection were waiting until the default > timeout (5 seconds most of the time). As a result, tests are 2mins faster. > > > There are things I need to complete though (even if the API is usable as > is) > > - a few renaming has to be done (nothing biggy, and it has no impact on > the users) > > - ThreadLocalStorage has to be used to store the encoder buffer > > - Ideally speaking, I'd like to add a post-decoding action. It's a big > technical, but the thing is that for some operations, we can't really > differ the creation of an message/Control/ExtOp instance, because if we > do, we may not be able to have this instance created at all. This is > typically the case for Control/ExtOp without a name - yes, response may > not have an OID - and without a value. So we create what I called an > OpaqueControl/OpaqueExtendedResponse, then if we have a name, we create > the proper control/extOp instance. This is a kind of waste. With a > post-decoding action, we will be able to only create the proper instance > once and for all > > - I want to make the Asn1Decoder a statless class > > > I don't think those modifications are big, and more important, I can do > them incrementally. I expect to be done by the end of this week. > > > The JNDI code is still present, and will be removed later (maybe in a > next release). > > > So this is it, I think we will be able to cut a release this week-end or > earlier, in the mean time, feel free to test the current code ! > > > Thanks! >
