Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
+1 On Mon, Feb 14, 2011 at 10:22 AM, Stefan Seelmann seelm...@apache.org wrote: Hi, This is a vote for the first milestone release on our way to a Shared and LDAP API 1.0. Lot of cleanup and decoupling has already be done. Also bug fixes and improvements have been done. Please see the release notes below. The SVN tag: http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M1/ The source and binary distribution packages: http://people.apache.org/~seelmann/shared-1.0.0-M1/ The file names are prefixed with 'apache-ldap-api'. The bin packages contain the shaded shared-all and all required dependencies to use the LDAP API. The staging repository: https://repository.apache.org/content/repositories/orgapachedirectory-062/ The generated site: http://directory.apache.org/shared/gen-docs/1.0.0-M1/ This is also a vote for JUnit Add-ons 0.1. This artifact is used by Shared (and ApacheDS) for concurrency tests. Unfortunately the artifacts are already published to the Maven repositories, so this vote is to legitimate this after the fact. The SVN tag: http://svn.apache.org/repos/asf/directory/buildtools/junit-addons/tags/0.1/ The artifacts in Maven repository: http://repo1.maven.org/maven2/org/apache/directory/junit/junit-addons/0.1/ Please cast your votes: [ ] +1 Release Shared 1.0.0-M1 and JUnit Add-ons 0.1 [ ] 0 abstain [ ] -1 Do not release Shared 1.0.0-M1 and JUnit Add-ons 0.1 Kind Regards, Stefan -- Release Notes - Directory Shared - Version 1.0-M1 ** Sub-task * [DIRSHARED-81] - Move classes and tests to appropriate area * [DIRSHARED-82] - Adhere to package and class naming conventions * [DIRSHARED-83] - Add documentation and test coverage ** Bug * [DIRSHARED-4] - RDN length and start fields are not set * [DIRSHARED-36] - Attribute type description schema parser uses integer for syntax length, should be BigInteger * [DIRSHARED-40] - DN parser, LdapDN, Rdn, Atav issues * [DIRSHARED-58] - Interface org.apache.directory.shared.ldap.cursor.Cursor isn't complete * [DIRSHARED-60] - Equality matching rule is not required for an attribute type description * [DIRSHARED-63] - LDIFEntry does not handle controls * [DIRSHARED-68] - schema extensions are not correctly parsed * [DIRSHARED-69] - To string on a Filter throws NPE on toString() * [DIRSHARED-71] - SearchResultEntryDsml does not use the provided name of the attribute type * [DIRSHARED-72] - DnNode does not handle move and rename operations * [DIRSHARED-75] - AbstractSchemaLoader fails to add schema objects if the schema name is given in capital letters ** Improvement * [DIRSHARED-11] - Relax the ACI grammar parser * [DIRSHARED-34] - LdifEntry.toString() should print LDIF rather than diagnostic information * [DIRSHARED-61] - Cleaning LdapMessage classes * [DIRSHARED-64] - IStates and inherited interfaces/implementing classes shpuld be enums * [DIRSHARED-65] - Enabling a disabled schema should also enable any disabled schemas the current schema depends on ** New Feature * [DIRSHARED-28] - Need a feature like toString but different ** Task * [DIRSHARED-46] - The LdapDN.toString() method should use the UP name, not the normNane * [DIRSHARED-50] - Rename DN methods to reflect the Client API decisions * [DIRSHARED-54] - Replace all the JNDI exceptions with our own exceptions (API) * [DIRSHARED-59] - Replace public static finals by enums * [DIRSHARED-79] - Control factories must be minimalistic - presently they have too many needless methods. * [DIRSHARED-80] - M1-STAGE-1: General cleanup master task
Re: Some more thoughts about the Dn class : Headsup
Hi, just to inform you that the following modifications has been done yesterday : Removed methods : Dn(String) Dn(SchemaManager, String) add(int, Rdn) add(int, String) Renamed methods : isChildOf(Dn) - isDescendantOf(Dn) isChildOf(String) - isDescendantOf(String) isParentOf(Dn) - isAncestorOf(Dn) isParentOf(String) - isAncestorOf(String) (we can sill discuss the final name to use) Added method : getSchemaManager() I will continue with the suggested modifications, assuming that those were the low hanging fruits... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[jira] Created: (DIRSTUDIO-726) Added a binary attributes in preference is not stored correctly
Added a binary attributes in preference is not stored correctly --- Key: DIRSTUDIO-726 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-726 Project: Directory Studio Issue Type: Bug Affects Versions: 1.5.3 Reporter: Emmanuel Lecharny Priority: Minor When adding a new binary attribute (preferencs -Studio - LDAP browser - Attributes - Binary), the added attributes is exposed with the OID in the alias column and the alias in the Attribute column. The Attribute column should also be renamed to 'attribute's OID' -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRSTUDIO-726) Added a binary attributes in preference is not stored correctly
[ https://issues.apache.org/jira/browse/DIRSTUDIO-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot updated DIRSTUDIO-726: - Attachment: screenshot-1.jpg Here's a screenshot. Added a binary attributes in preference is not stored correctly --- Key: DIRSTUDIO-726 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-726 Project: Directory Studio Issue Type: Bug Affects Versions: 1.5.3 Reporter: Emmanuel Lecharny Priority: Minor Attachments: screenshot-1.jpg When adding a new binary attribute (preferencs -Studio - LDAP browser - Attributes - Binary), the added attributes is exposed with the OID in the alias column and the alias in the Attribute column. The Attribute column should also be renamed to 'attribute's OID' -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DIRSTUDIO-727) It is possible to add empty Binary Attributes and Binary Syntax Definitions in the preferences
It is possible to add empty Binary Attributes and Binary Syntax Definitions in the preferences -- Key: DIRSTUDIO-727 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-727 Project: Directory Studio Issue Type: Bug Components: studio-ldapbrowser Affects Versions: 1.5.3 Reporter: Pierre-Arnaud Marcelot Priority: Minor Fix For: 1.5.4, 2.0.0 Attachments: screenshot-1.jpg It is possible to add empty Binary Attributes and Binary Syntax Definitions in the preferences -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRSTUDIO-727) It is possible to add empty Binary Attributes and Binary Syntax Definitions in the preferences
[ https://issues.apache.org/jira/browse/DIRSTUDIO-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot updated DIRSTUDIO-727: - Attachment: screenshot-1.jpg Here's a screenshot It is possible to add empty Binary Attributes and Binary Syntax Definitions in the preferences -- Key: DIRSTUDIO-727 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-727 Project: Directory Studio Issue Type: Bug Components: studio-ldapbrowser Affects Versions: 1.5.3 Reporter: Pierre-Arnaud Marcelot Priority: Minor Fix For: 1.5.4, 2.0.0 Attachments: screenshot-1.jpg It is possible to add empty Binary Attributes and Binary Syntax Definitions in the preferences -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Some more thoughts about the Dn class : Headsup
Thanks Emmanuel. This is going to be a very clean API. :) Regards, Pierre-Arnaud On vendredi 18 février 2011 at 09:52, Emmanuel Lecharny wrote: Hi, just to inform you that the following modifications has been done yesterday : Removed methods : Dn(String) Dn(SchemaManager, String) add(int, Rdn) add(int, String) Renamed methods : isChildOf(Dn) - isDescendantOf(Dn) isChildOf(String) - isDescendantOf(String) isParentOf(Dn) - isAncestorOf(Dn) isParentOf(String) - isAncestorOf(String) (we can sill discuss the final name to use) Added method : getSchemaManager() I will continue with the suggested modifications, assuming that those were the low hanging fruits... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE][RESULT] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On Fri, Feb 18, 2011 at 9:49 AM, Stefan Seelmann seelm...@apache.org wrote: I count five +1 votes from Emmanuel Lecharny Pierre-Arnaud Marcelot Felix Knecht Kiran Ayyagari Stefan Seelmann And one +0 vote from Alex Karasulu No -1 vote. So the vote passed, I'll publish the Maven artifacts, source and binary distribution. As this is only a first milestone and shared/LDAP API is still under heavy refactoring I won't send an announcement mail. Interested users can still use the released artifacts and feedback is highly welcomed. I wonder where to put the source and bin distribution packages. If no objection I'll put them below http://www.apache.org/dist/directory/api/unstable/ instead of creating a new shared folder. Kind Regards Stefan
Re: [VOTE][RESULT] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On 2/18/11 10:34 AM, Stefan Seelmann wrote: On Fri, Feb 18, 2011 at 9:49 AM, Stefan Seelmannseelm...@apache.org wrote: I count five +1 votes from Emmanuel Lecharny Pierre-Arnaud Marcelot Felix Knecht Kiran Ayyagari Stefan Seelmann And one +0 vote from Alex Karasulu No -1 vote. So the vote passed, I'll publish the Maven artifacts, source and binary distribution. As this is only a first milestone and shared/LDAP API is still under heavy refactoring I won't send an announcement mail. Interested users can still use the released artifacts and feedback is highly welcomed. I wonder where to put the source and bin distribution packages. If no objection I'll put them below http://www.apache.org/dist/directory/api/unstable/ instead of creating a new shared folder. Put it into the api directory. No need to add an 'unstable' sub-directory. It's confusing, and probably was a mistake when we decided to go for 'unstable' versions. Time to get rid of that :) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
One Felix test is failing in eclipse, not when run on the CL
Hi Alex,
the following test :
public class StandaloneLdapCodecServiceTest
{
/**
* Test method for {@link
org.apache.directory.shared.ldap.codec.standalone.StandaloneLdapCodecService#StandaloneLdapCodecService()}.
*/
@Test
public void testLoadingExtras()
{
StandaloneLdapCodecService codec = new
StandaloneLdapCodecService();
assertTrue( codec.isControlRegistered( PasswordPolicy.OID ) );
CodecControl? extends Control control = codec.newControl(
PasswordPolicy.OID );
assertNotNull( control );
System.out.println( control );
assertNotNull( codec );
codec.shutdown();
}
}
is failing when run alone in eclipse, while it passes when we run the
full tests.
After some debugging in eclipse, it appears that the PasswordPolicy
control is not registered in Felix.
One possible reason for the test passing in CL is that the felix cache
might have been updated by another test.
This has to be fixed so that the test also passes in eclipse.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
[jira] Updated: (DIRAPI-36) Provide a SaslBindRequest extending BindRequest that can be used in LdapConnection.bind(...) method
[ https://issues.apache.org/jira/browse/DIRAPI-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot updated DIRAPI-36: - Fix Version/s: (was: 1.0-M1) 1.0-M2 Remaining Estimate: 0h Original Estimate: 0h Provide a SaslBindRequest extending BindRequest that can be used in LdapConnection.bind(...) method --- Key: DIRAPI-36 URL: https://issues.apache.org/jira/browse/DIRAPI-36 Project: Directory Client API Issue Type: Improvement Reporter: Pierre-Arnaud Marcelot Fix For: 1.0-M2 Original Estimate: 0h Remaining Estimate: 0h It would be a good idea to provide a SaslBindRequest extending BindRequest in which we could set all required properties for SASL binds. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DIRAPI-36) Provide a SaslBindRequest extending BindRequest that can be used in LdapConnection.bind(...) method
[ https://issues.apache.org/jira/browse/DIRAPI-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot closed DIRAPI-36. Resolution: Fixed Provide a SaslBindRequest extending BindRequest that can be used in LdapConnection.bind(...) method --- Key: DIRAPI-36 URL: https://issues.apache.org/jira/browse/DIRAPI-36 Project: Directory Client API Issue Type: Improvement Reporter: Pierre-Arnaud Marcelot Fix For: 1.0-M2 Original Estimate: 0h Remaining Estimate: 0h It would be a good idea to provide a SaslBindRequest extending BindRequest in which we could set all required properties for SASL binds. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRAPI-36) Provide a SaslBindRequest extending BindRequest that can be used in LdapConnection.bind(...) method
[ https://issues.apache.org/jira/browse/DIRAPI-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996495#comment-12996495 ] Pierre-Arnaud Marcelot commented on DIRAPI-36: -- Three new classes extending SaslRequest (without extending BindRequest) have been created (see DIRAPI-42 [Provide a SaslBindRequest extending BindRequest that can be used in LdapConnection.bind(...) method]) for CRAM-MD5, DIGEST-MD5 and GSS-API. These classes are to be used with the LdapConnection.bind(...) methods. Provide a SaslBindRequest extending BindRequest that can be used in LdapConnection.bind(...) method --- Key: DIRAPI-36 URL: https://issues.apache.org/jira/browse/DIRAPI-36 Project: Directory Client API Issue Type: Improvement Reporter: Pierre-Arnaud Marcelot Fix For: 1.0-M2 Original Estimate: 0h Remaining Estimate: 0h It would be a good idea to provide a SaslBindRequest extending BindRequest in which we could set all required properties for SASL binds. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DIRAPI-42) Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API)
[ https://issues.apache.org/jira/browse/DIRAPI-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot closed DIRAPI-42. Resolution: Fixed Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) Key: DIRAPI-42 URL: https://issues.apache.org/jira/browse/DIRAPI-42 Project: Directory Client API Issue Type: Improvement Reporter: Pierre-Arnaud Marcelot Assignee: Pierre-Arnaud Marcelot Fix For: 1.0-M2 Original Estimate: 0h Remaining Estimate: 0h Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) There's a discussion for this on the dev mailing list: http://directory.markmail.org/thread/yjmnnvqfayg72kas -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DIRAPI-42) Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API)
[ https://issues.apache.org/jira/browse/DIRAPI-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot updated DIRAPI-42: - Remaining Estimate: 0h Original Estimate: 0h Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) Key: DIRAPI-42 URL: https://issues.apache.org/jira/browse/DIRAPI-42 Project: Directory Client API Issue Type: Improvement Reporter: Pierre-Arnaud Marcelot Assignee: Pierre-Arnaud Marcelot Fix For: 1.0-M2 Original Estimate: 0h Remaining Estimate: 0h Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) There's a discussion for this on the dev mailing list: http://directory.markmail.org/thread/yjmnnvqfayg72kas -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRAPI-42) Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API)
[ https://issues.apache.org/jira/browse/DIRAPI-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996498#comment-12996498 ] Pierre-Arnaud Marcelot commented on DIRAPI-42: -- Fixed. Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) Key: DIRAPI-42 URL: https://issues.apache.org/jira/browse/DIRAPI-42 Project: Directory Client API Issue Type: Improvement Reporter: Pierre-Arnaud Marcelot Assignee: Pierre-Arnaud Marcelot Fix For: 1.0-M2 Original Estimate: 0h Remaining Estimate: 0h Add additional classes and clean method arguments for SASL binds (CRAM-MD5, DIGEST-MD5, GSS-API) There's a discussion for this on the dev mailing list: http://directory.markmail.org/thread/yjmnnvqfayg72kas -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Develop a LDAP proxy GUI
Hi Haritha, I'm sorry but this project has already been chosen at last year's GSoC (2010). Regards, Pierre-Arnaud On mercredi 16 février 2011 at 07:55, Haritha Bharatha Tennakoon wrote: hi developers, I'm Hairtha Tennakoon and a final year student of Computer Science Engineering, University of Moratuwa, Sri Lanka. I'm interested in the project idea titled as Develop a LDAP proxy GUI (ID: directory-proxy) which was in GSoC 2009 ideas list. I would like to implement it in this year GSoC if it is available. As I know, this project idea has not been attempted by a student yet. Please be kind enough to tell me if there is special reason for that. Thank you, Haritha
Re: DN serialization issues
On Fri, Feb 18, 2011 at 8:17 PM, Emmanuel Lecharny elecha...@gmail.comwrote: Hi guys, once upon a time, in order to improve the server permformance, the DN was serialized with its normalized value. This was to avoid a costly normalization when we pull back the DN from the backend. But now that we don't store anymore the DN into the entry, it does not make any sense to store the normalized DN. We should get rid of that. +1 Another problem is that the LogManager also serialize entries with a full DN on the disk, and when it reads them back, it should be able to inject the schemaManager into the DN, which is not done. All in all, the DnSerializer has nothing to do in the Ldap-API. It's a Server thingy, as is the EntrySerializer. Moreover, the DefaultEntry implements the Externalizable interface, but does also provides serialize()/deserialize() methods, which export the RDN, not the DN, simply because it's used only by the server. This is a mess... Separating out the implementations might help decouple these server side ONLY concerns. But I don't know how I feel about having to have a ServerDn verses a regular Dn. WDYT? Alex
[jira] Closed: (DIRSHARED-91) Solve the issue with an embedded Felix running in codec while being embedded in eclipse RCP
[ https://issues.apache.org/jira/browse/DIRSHARED-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Karasulu closed DIRSHARED-91. -- Resolution: Fixed Solve the issue with an embedded Felix running in codec while being embedded in eclipse RCP --- Key: DIRSHARED-91 URL: https://issues.apache.org/jira/browse/DIRSHARED-91 Project: Directory Shared Issue Type: Sub-task Affects Versions: 1.0-M1 Environment: All Reporter: Alex Karasulu Fix For: 1.0-M2 Original Estimate: 48h Remaining Estimate: 48h Pierre is having issues and they may not go away. We might have to find an alternative. Some alternatives were posted here: http://goo.gl/OP6de -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: DN serialization issues
On 2/19/11 12:24 AM, Alex Karasulu wrote: On Fri, Feb 18, 2011 at 8:17 PM, Emmanuel Lecharnyelecha...@gmail.comwrote: Hi guys, once upon a time, in order to improve the server permformance, the DN was serialized with its normalized value. This was to avoid a costly normalization when we pull back the DN from the backend. But now that we don't store anymore the DN into the entry, it does not make any sense to store the normalized DN. We should get rid of that. +1 Another problem is that the LogManager also serialize entries with a full DN on the disk, and when it reads them back, it should be able to inject the schemaManager into the DN, which is not done. All in all, the DnSerializer has nothing to do in the Ldap-API. It's a Server thingy, as is the EntrySerializer. Moreover, the DefaultEntry implements the Externalizable interface, but does also provides serialize()/deserialize() methods, which export the RDN, not the DN, simply because it's used only by the server. This is a mess... Separating out the implementations might help decouple these server side ONLY concerns. But I don't know how I feel about having to have a ServerDn verses a regular Dn. This is what we had once upon a time, and it was, well, awful. What I'm trying to do right now is to make all the components schema aware (ie, DN RDN, AVA) and just store the minimum information when serializing them (ie, just serialize the UP types and values), assuming that the normalized values can be deduced using the SM, if it's injected. That should help on the server side, because the SM will always be available on the server. Also the burden (and cost) of normalizing a serialized value on the server (something we have to deal with in three places only : the backend, the session and the ChangeLog) will not be that high, assuming that we will have an entry cache later, that the changeLog can be desactivated and that we anyway have to do the job on the session side. This should work, but it's quite painful as it implies a *lot* of modifications in the AVA and Rdn classes. We also have to deal with the different serializer we have, the static ones we use in the server, which must take a SM as a parameter. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
[jira] Commented: (DIRSHARED-86) Make Extended Operations Plugin Extensions to Codec like Controls
[ https://issues.apache.org/jira/browse/DIRSHARED-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996691#comment-12996691 ] Alex Karasulu commented on DIRSHARED-86: Almost done. Just need to sift through the code using these extras extended operations and make them use the codec instead of manually access private implementation classes to do the work of encoding and decoding these requests and responses. Make Extended Operations Plugin Extensions to Codec like Controls - Key: DIRSHARED-86 URL: https://issues.apache.org/jira/browse/DIRSHARED-86 Project: Directory Shared Issue Type: Sub-task Affects Versions: 1.0-M1 Environment: All Reporter: Alex Karasulu Fix For: 1.0-M2 Original Estimate: 48h Remaining Estimate: 48h This was done for controls. Has to also happen for Extended Operations. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Shared] [LDAP] [Codec] Anyone remember why we have two LDAP ProtocolDecoder implementations?
I found these two classes here [0] and here [1]. Both implement ProtocolDecoder and seem to be almost identical in capability. One seems to have been written for the client and one for the server but I don't think it makes a difference. Perhaps these two can be consolidated into single implementation. Incidentally the LdapProtocolEncoder is shared by both LdapProtocolCodecFactory implementations in shared and in apacheds. This means if we consolidate these two classes, [0] and [1], then we can easily consolidate the two codec factories. Thoughts? Regards, Alex [0] http://goo.gl/tYopN - org.apache.directory.shared.ldap.codec.LdapDecoder [1] http://goo.gl/xa9sX - org.apache.directory.shared.ldap.codec.protocol.mina.LdapProtocolDecoder
[jira] Closed: (DIRSHARED-86) Make Extended Operations Plugin Extensions to Codec like Controls
[ https://issues.apache.org/jira/browse/DIRSHARED-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Karasulu closed DIRSHARED-86. -- Resolution: Fixed Make Extended Operations Plugin Extensions to Codec like Controls - Key: DIRSHARED-86 URL: https://issues.apache.org/jira/browse/DIRSHARED-86 Project: Directory Shared Issue Type: Sub-task Affects Versions: 1.0-M1 Environment: All Reporter: Alex Karasulu Fix For: 1.0-M2 Original Estimate: 48h Remaining Estimate: 48h This was done for controls. Has to also happen for Extended Operations. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DIRSHARED-101) Remove usage of internal private codec packages.
Remove usage of internal private codec packages. Key: DIRSHARED-101 URL: https://issues.apache.org/jira/browse/DIRSHARED-101 Project: Directory Shared Issue Type: Sub-task Affects Versions: 1.0-M1 Environment: All Reporter: Alex Karasulu Assignee: Alex Karasulu Fix For: 1.0-M2 Make sure that no codec internal packages are being access anywhere in the code outside of the codec. We must make sure ApacheDS and Studio are using only the codec API interfaces to manipulate controls and extended operations. We still seem to have several references in the code mainly in ApacheDS. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSHARED-92) See if we can make the protocol codec pluggable as well.
[ https://issues.apache.org/jira/browse/DIRSHARED-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996700#comment-12996700 ] Alex Karasulu commented on DIRSHARED-92: Once we can determine whether or not we can use the same protocol codec factory for both the server and the client we know just how to make this piece pluggable. We will need to separate this out into it's own ldap-protocol-codec module. It will not be an API. The server and studio will access this component's interface which is a MINA interface (ProtocolCodecFactory) via the LdapCodecService. See if we can make the protocol codec pluggable as well. Key: DIRSHARED-92 URL: https://issues.apache.org/jira/browse/DIRSHARED-92 Project: Directory Shared Issue Type: Sub-task Affects Versions: 1.0-M1 Environment: All Reporter: Alex Karasulu Fix For: 1.0-M2 Original Estimate: 48h Remaining Estimate: 48h The codec can offer different protocol codec factories since it is a factory of protocol codecs. This might allow us to leverage other network libraries like Grizzly, and Netty 3.0 in addition to Apache MINA, which helps compare differences. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Shared] [LDAP] [Codec] Anyone remember why we have two LDAP ProtocolDecoder implementations?
On 2/19/11 5:21 AM, Alex Karasulu wrote: I found these two classes here [0] and here [1]. Both implement ProtocolDecoder and seem to be almost identical in capability. One seems to have been written for the client and one for the server but I don't think it makes a difference. Perhaps these two can be consolidated into single implementation. Definitively, yes. Incidentally the LdapProtocolEncoder is shared by both LdapProtocolCodecFactory implementations in shared and in apacheds. This means if we consolidate these two classes, [0] and [1], then we can easily consolidate the two codec factories. Ok, let me explain why we have 2 classes. The older one was the server one, which was using a complex pattern with a callback, a blocking and not blocking decode methods, etc. The newer one was developed for the client, and is what we should have had from day one in the server. Both implementations should have been merged a while back, but it was not simple and some convergence started last september, not finished of course. So, yes, we should have one single implementation. The client implementation is probably the correct base to start with. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
