[jira] Commented: (DIRAPI-40) LdapNetworkConnection should throw an exception when startTls() method is called and the LdapConnectionConfig has the 'useSsl' flag set to true
[ https://issues.apache.org/jira/browse/DIRAPI-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994222#comment-12994222 ] Pierre-Arnaud Marcelot commented on DIRAPI-40: -- > More specifically, the use of LDAPS should be marked as deprecated. StartTLS > is the way to go. Yep, I agree. Maybe we should tweak the Javadocs to indicate this. > The way to get it working is probably to replace the useSSL flag when we > create the connection, to instead use the startTLS extedned request to > establish a secure connection. > > I'm quite sure that every server support StartTLS those days, so there is no > reason to not use that in any case. i'm even wondering if we should not use > StartTLS even when the user requires 'ldaps'... There would be a big problem here because the port specified for the connection would be the LDAPS port (if the user specifically selected it) and we don't have any idea of the port for the LDAP (non-SSL) connection. Furthermore, as an API, I think we should behave the way the user wants. If he asks for LDAPS and even if it's deprecated and StartTLS is better and supported by his server, we should do LDAPS... > LdapNetworkConnection should throw an exception when startTls() method is > called and the LdapConnectionConfig has the 'useSsl' flag set to true > --- > > Key: DIRAPI-40 > URL: https://issues.apache.org/jira/browse/DIRAPI-40 > Project: Directory Client API > Issue Type: Improvement >Affects Versions: 1.0-M1 >Reporter: Pierre-Arnaud Marcelot > Fix For: 1.0-M2 > > > LdapNetworkConnection should throw an exception when startTls() method is > called and the LdapConnectionConfig has the 'useSsl' flag set to true. > I got an error when using the LDAP API inside Studio where I had set the > 'useSsl' flag set to true and was then trying to use the Start TLS extended > operation. > Sure, it was a mistake on my side and the server was not receiving the > expected bits of information, but it would be nice if the connection could > warn the user about his wrong configuration. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
Hi Dev, These last days, I've been reviewing Authentication in Studio using the LDAP API. I'm happy to say that all the Authentication methods that were supported in Studio with JNDI are also working (not yet with the same options, though) with the LDAP API integrated in Studio. This includes: - All encryption methods - No encryption - SSL encryption (LDAPS) - StartTLS via exended operation - All authentication methods - No authentication (anonymous) - Simple authentication - DIGEST-MD5 (SASL) - CRAM-MD5 (SASL) - GSSAPI (Kerberos) That said, there are still some options which are not (yet) available in the LDAP API for some authentication methods (specifically SASL and GSSAPI) like: - For SASL - Quality of Protection - Protection Strength - Mutual Authentication - For Kerberos - Use native TGT for Kerberos Credential Configuration - Use native system configuration - Use a specific configuration file All these new settings will increase the, already long, list of parameters for the SASL and GSSAPI methods. To resolve that, I'd like to add new classes that will hold all these informations and can be passed to the SASL and GSSAPI methods. We could keep one or two general methods for each type of authentication with the most commonly used parameters and a more generic approach with the use of these new "configuration holder" classes. Thoughts? One more question. Should we push this into Shared-1.0.0-M1 or wait for the next iteration? Regards Pierre-Arnaud Marcelot
Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
On lundi 14 février 2011 at 09:05, Pierre-Arnaud Marcelot wrote: > One more question. > Should we push this into Shared-1.0.0-M1 or wait for the next iteration? > > > > > > > > > > > I didn't look at last night the commits. Looks like Shared-1.0.0-M1 has already been prepared, héhé... It will be in the next iteration then. Regards Pierre-Arnaud Marcelot
[VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
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: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
On Mon, Feb 14, 2011 at 9:05 AM, Pierre-Arnaud Marcelot wrote: > Hi Dev, > These last days, I've been reviewing Authentication in Studio using the LDAP > API. > I'm happy to say that all the Authentication methods that were supported in > Studio with JNDI are also working (not yet with the same options, though) > with the LDAP API integrated in Studio. > This includes: > - All encryption methods > - No encryption > - SSL encryption (LDAPS) > - StartTLS via exended operation > - All authentication methods > - No authentication (anonymous) > - Simple authentication > - DIGEST-MD5 (SASL) > - CRAM-MD5 (SASL) > - GSSAPI (Kerberos) > That said, there are still some options which are not (yet) available in the > LDAP API for some authentication methods (specifically SASL and GSSAPI) > like: > - For SASL > - Quality of Protection > - Protection Strength > - Mutual Authentication > - For Kerberos > - Use native TGT for Kerberos Credential Configuration > - Use native system configuration > - Use a specific configuration file > All these new settings will increase the, already long, list > of parameters for the SASL and GSSAPI methods. > To resolve that, I'd like to add new classes that will hold all these > informations and can be passed to the SASL and GSSAPI methods. > We could keep one or two general methods for each type of authentication > with the most commonly used parameters and a more generic approach with the > use of these new "configuration holder" classes. > Thoughts? +1 to use a parameter object > One more question. > Should we push this into Shared-1.0.0-M1 or wait for the next iteration? Too late, vote already started. But maybe we need to rollback ;-) Kind Regards, Stefan
Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
On 2/14/11 11:05 AM, Stefan Seelmann wrote: On Mon, Feb 14, 2011 at 9:05 AM, Pierre-Arnaud Marcelot wrote: Hi Dev, These last days, I've been reviewing Authentication in Studio using the LDAP API. I'm happy to say that all the Authentication methods that were supported in Studio with JNDI are also working (not yet with the same options, though) with the LDAP API integrated in Studio. This includes: - All encryption methods - No encryption - SSL encryption (LDAPS) - StartTLS via exended operation - All authentication methods - No authentication (anonymous) - Simple authentication - DIGEST-MD5 (SASL) - CRAM-MD5 (SASL) - GSSAPI (Kerberos) That said, there are still some options which are not (yet) available in the LDAP API for some authentication methods (specifically SASL and GSSAPI) like: - For SASL - Quality of Protection - Protection Strength - Mutual Authentication - For Kerberos - Use native TGT for Kerberos Credential Configuration - Use native system configuration - Use a specific configuration file All these new settings will increase the, already long, list of parameters for the SASL and GSSAPI methods. To resolve that, I'd like to add new classes that will hold all these informations and can be passed to the SASL and GSSAPI methods. We could keep one or two general methods for each type of authentication with the most commonly used parameters and a more generic approach with the use of these new "configuration holder" classes. Thoughts? +1 to use a parameter object One more question. Should we push this into Shared-1.0.0-M1 or wait for the next iteration? Too late, vote already started. But maybe we need to rollback ;-) No, let's push all the move to the M2 branch (which has to be renamed, btw, it's M1 atm) We will have lots of modifications in the API in M2 anyway, so don't worry too much. M1 != API freeze ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On 2/14/11 10:22 AM, Stefan Seelmann wrote: Hi, Hi Stefan, 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/ I'll review the release today. One sight remark : when checking the generated site, we can see the LICENSE page (http://directory.apache.org/shared/gen-docs/1.0.0-M1/license.html) which is containing only the ASL 2.0. I have no idea how this page is generated, and I'm wondering if we should not have a page listing the 3rd party licenses either. In any case, it won't be a blocker for me, as it's just a 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 Many thanks Stefan ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On Mon, Feb 14, 2011 at 11:19 AM, Emmanuel Lecharny wrote: > On 2/14/11 10:22 AM, Stefan Seelmann wrote: >> >> Hi, > > Hi Stefan, >> >> 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/ > > I'll review the release today. One sight remark : when checking the > generated site, we can see the LICENSE page > (http://directory.apache.org/shared/gen-docs/1.0.0-M1/license.html) which is > containing only the ASL 2.0. I have no idea how this page is generated, and > I'm wondering if we should not have a page listing the 3rd party licenses > either. It's inherited from the Apache POM 8, see the section: http://repo2.maven.org/maven2/org/apache/apache/8/apache-8.pom > In any case, it won't be a blocker for me, as it's just a 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 > > Many thanks Stefan ! > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
[jira] Created: (DIRSHARED-97) Review Package Names
Review Package Names Key: DIRSHARED-97 URL: https://issues.apache.org/jira/browse/DIRSHARED-97 Project: Directory Shared Issue Type: Task Reporter: Stefan Seelmann Fix For: 1.0.0-RC1 The package names should be reviewed. Package names are not consistent and IMHO too long. So here I just put some questions and ideas. Example from ldap-model: org.apache.directory.shared.ldap.model.name.Dn - Do we need the *shared* in package names? I think we can remove it, everything that doesn't start with o.a.d.studio or o.a.d.server in the name is implicitly a 'shared' package. - Should we keep the *model* in package names? While I understand that during refactoring it's easier to see the model packages, it isn't common in other APIs. The result could be: org.apache.directory.ldap.name.Dn Example from ldap-client-api: org.apache.directory.ldap.client.api.LdapConnection - Do we need the 'client.api' in package names? I think we can remove it, everything with o.a.d.ldap in the name is implicitly the LDAP API. The result could be: org.apache.directory.ldap.LdapConnection -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DIRSHARED-97) Review Package Names
[ https://issues.apache.org/jira/browse/DIRSHARED-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994271#comment-12994271 ] Emmanuel Lecharny commented on DIRSHARED-97: org.apache.directory.ldap.name.Dn sounds good. No need to repeat the 'shared' part as this package is already in a jars with this name. Btw, we should now switch to ldap-api instead of shared. Shared does not mean anything... > Review Package Names > > > Key: DIRSHARED-97 > URL: https://issues.apache.org/jira/browse/DIRSHARED-97 > Project: Directory Shared > Issue Type: Task >Reporter: Stefan Seelmann > Fix For: 1.0.0-RC1 > > > The package names should be reviewed. Package names are not consistent and > IMHO too long. So here I just put some questions and ideas. > Example from ldap-model: > org.apache.directory.shared.ldap.model.name.Dn > - Do we need the *shared* in package names? I think we can remove it, > everything that doesn't start with o.a.d.studio or o.a.d.server in the name > is implicitly a 'shared' package. > - Should we keep the *model* in package names? While I understand that during > refactoring it's easier to see the model packages, it isn't common in other > APIs. > The result could be: org.apache.directory.ldap.name.Dn > Example from ldap-client-api: > org.apache.directory.ldap.client.api.LdapConnection > - Do we need the 'client.api' in package names? I think we can remove it, > everything with o.a.d.ldap in the name is implicitly the LDAP API. > The result could be: org.apache.directory.ldap.LdapConnection -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On 2/14/11 10:22 AM, Stefan Seelmann wrote: Please cast your votes: [X] +1 Release Shared 1.0.0-M1 and JUnit Add-ons 0.1 I have checked the bins and the src. I was able to build the jars from the src. Licenses and Notices are ok from my POV. Good job... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
[X] +1 Release Shared 1.0.0-M1 and JUnit Add-ons 0.1 I checked the source and binary distribution packages. The sources package looks good and built successfully via Maven. I was able to connect to ApacheDS via the libraries included in the binary distribution package and small hand-written class (written in less than a minute :) ). Now, a few points that need discussion and can probably be improved in the next milestone release: - I'm not sure the NOTICE file is completely OK and probably needs to contain a small text entry for each third party library. - It may be interesting to use the Felix Bundle Maven plugin to make the 'shared-all' a real OSGI-ready bundle (It's a simple jar ATM). - It would be also interesting to bundle with the distribution the log4j dependency, just like we do for ApacheDS. I had to download this aside and add it to the build path to be able to work with the LDAP API. I understand that we're using a logging "façade" (SLF4J) to allow the user to choose the implementation he prefers, but I think most users of the API won't know and don't care about it. If we bundle log4j in the final distribution, the LDAP API can be used in one simple step and people willing to use their logger implementation of choice can easily remove the bundle log4j and add their own jar. Beside these three small remarks, the release looks really good. Congrats and thanks for handling this, Stefan! Regards Pierre-Arnaud On lundi 14 février 2011 at 10:22, Stefan Seelmann 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) > * [DIRSHAR
Re: svn commit: r1070415 - in /directory/shared/branches/m1/ldap-extras: aci/pom.xml sp/pom.xml trigger/pom.xml util/pom.xml
Thanks Pierre for catching all these. Was late and rushed last night.
Regards,
Alex
On Mon, Feb 14, 2011 at 11:23 AM, wrote:
> Author: pamarcelot
> Date: Mon Feb 14 09:23:09 2011
> New Revision: 1070415
>
> URL: http://svn.apache.org/viewvc?rev=1070415&view=rev
> Log:
> Fixed build failure on Shared. Fixed build hierarchy under
> 'shared-ldap-extras-parent'. Fixed naming for OSGI bundles.
>
> Modified:
>directory/shared/branches/m1/ldap-extras/aci/pom.xml
>directory/shared/branches/m1/ldap-extras/sp/pom.xml
>directory/shared/branches/m1/ldap-extras/trigger/pom.xml
>directory/shared/branches/m1/ldap-extras/util/pom.xml
>
> Modified: directory/shared/branches/m1/ldap-extras/aci/pom.xml
> URL:
> http://svn.apache.org/viewvc/directory/shared/branches/m1/ldap-extras/aci/pom.xml?rev=1070415&r1=1070414&r2=1070415&view=diff
>
> ==
> --- directory/shared/branches/m1/ldap-extras/aci/pom.xml (original)
> +++ directory/shared/branches/m1/ldap-extras/aci/pom.xml Mon Feb 14
> 09:23:09 2011
> @@ -21,7 +21,7 @@
> 4.0.0
>
> org.apache.directory.shared
> -shared-parent
> +shared-ldap-extras-parent
> 0.9.20-SNAPSHOT
>
>
>
> Modified: directory/shared/branches/m1/ldap-extras/sp/pom.xml
> URL:
> http://svn.apache.org/viewvc/directory/shared/branches/m1/ldap-extras/sp/pom.xml?rev=1070415&r1=1070414&r2=1070415&view=diff
>
> ==
> --- directory/shared/branches/m1/ldap-extras/sp/pom.xml (original)
> +++ directory/shared/branches/m1/ldap-extras/sp/pom.xml Mon Feb 14 09:23:09
> 2011
> @@ -21,7 +21,7 @@
> 4.0.0
>
> org.apache.directory.shared
> -shared-parent
> +shared-ldap-extras-parent
> 0.9.20-SNAPSHOT
>
>
> @@ -84,7 +84,7 @@
>
> META-INF
>
> -
> ${project.groupId}.ldap
> +
> ${project.groupId}.ldap.extras.sp
>
> org.apache.directory.shared.ldap.sp
>
>
> Modified: directory/shared/branches/m1/ldap-extras/trigger/pom.xml
> URL:
> http://svn.apache.org/viewvc/directory/shared/branches/m1/ldap-extras/trigger/pom.xml?rev=1070415&r1=1070414&r2=1070415&view=diff
>
> ==
> --- directory/shared/branches/m1/ldap-extras/trigger/pom.xml (original)
> +++ directory/shared/branches/m1/ldap-extras/trigger/pom.xml Mon Feb 14
> 09:23:09 2011
> @@ -21,7 +21,7 @@
> 4.0.0
>
> org.apache.directory.shared
> -shared-parent
> +shared-ldap-extras-parent
> 0.9.20-SNAPSHOT
>
>
> @@ -90,7 +90,7 @@
>
> META-INF
>
> -
> ${project.groupId}.ldap
> +
>
> ${project.groupId}.ldap.extras.trigger
>
> org.apache.directory.shared.ldap.trigger
>
>
> Modified: directory/shared/branches/m1/ldap-extras/util/pom.xml
> URL:
> http://svn.apache.org/viewvc/directory/shared/branches/m1/ldap-extras/util/pom.xml?rev=1070415&r1=1070414&r2=1070415&view=diff
>
> ==
> --- directory/shared/branches/m1/ldap-extras/util/pom.xml (original)
> +++ directory/shared/branches/m1/ldap-extras/util/pom.xml Mon Feb 14
> 09:23:09 2011
> @@ -21,7 +21,7 @@
> 4.0.0
>
> org.apache.directory.shared
> -shared-parent
> +shared-ldap-extras-parent
> 0.9.20-SNAPSHOT
>
>
> @@ -79,7 +79,7 @@
>
> META-INF
>
> -
> ${project.groupId}.ldap
> +
>
> ${project.groupId}.ldap.extras.util
>
> org.apache.directory.shared.ldap.util*
>
>
>
>
Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
On Mon, Feb 14, 2011 at 12:15 PM, Emmanuel Lecharny wrote: > On 2/14/11 11:05 AM, Stefan Seelmann wrote: > >> On Mon, Feb 14, 2011 at 9:05 AM, Pierre-Arnaud Marcelot >> wrote: >> >>> Hi Dev, >>> These last days, I've been reviewing Authentication in Studio using the >>> LDAP >>> API. >>> I'm happy to say that all the Authentication methods that were supported >>> in >>> Studio with JNDI are also working (not yet with the same options, though) >>> with the LDAP API integrated in Studio. >>> This includes: >>> - All encryption methods >>> - No encryption >>> - SSL encryption (LDAPS) >>> - StartTLS via exended operation >>> - All authentication methods >>> - No authentication (anonymous) >>> - Simple authentication >>> - DIGEST-MD5 (SASL) >>> - CRAM-MD5 (SASL) >>> - GSSAPI (Kerberos) >>> That said, there are still some options which are not (yet) available in >>> the >>> LDAP API for some authentication methods (specifically SASL and GSSAPI) >>> like: >>> - For SASL >>> - Quality of Protection >>> - Protection Strength >>> - Mutual Authentication >>> - For Kerberos >>> - Use native TGT for Kerberos Credential Configuration >>> - Use native system configuration >>> - Use a specific configuration file >>> All these new settings will increase the, already long, list >>> of parameters for the SASL and GSSAPI methods. >>> To resolve that, I'd like to add new classes that will hold all these >>> informations and can be passed to the SASL and GSSAPI methods. >>> We could keep one or two general methods for each type of authentication >>> with the most commonly used parameters and a more generic approach with >>> the >>> use of these new "configuration holder" classes. >>> Thoughts? >>> >> +1 to use a parameter object >> >> One more question. >>> Should we push this into Shared-1.0.0-M1 or wait for the next iteration? >>> >> Too late, vote already started. But maybe we need to rollback ;-) >> > > No, let's push all the move to the M2 branch (which has to be renamed, btw, > it's M1 atm) > > We will have lots of modifications in the API in M2 anyway, so don't worry > too much. M1 != API freeze ! How about naming this branch 1.0 and that way we don't have to keep changing the name with every RC or milestone release we have? Regards, Alex
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
Thanks for big work, Stefan! The NOTICE file in the distribution packages says: "Additional copyright notices and license terms applicable are present in the distribution/src/main/release/licenses or licenses directory." This is not right, I can't find any licences under the mentioned path. Licenses in the distributions can be found at "licences". I think this can also be fix in next release. +1 Felix On 02/14/2011 10:22 AM, Stefan Seelmann 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: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On Mon, Feb 14, 2011 at 11:22 AM, Stefan Seelmann 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'. Why are they prefixed with apache-ldap-api? Regards, Alex
Added ROOT_DSE in Dn class
Hi, we already have a EMPTY_DN static field in Dn, I also have added ROOT_DSE. They are the same thing, except that their semantic is different. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
On lundi 14 février 2011 at 17:29, Alex Karasulu wrote: > On Mon, Feb 14, 2011 at 12:15 PM, Emmanuel Lecharny > wrote: > > On 2/14/11 11:05 AM, Stefan Seelmann wrote: > > > On Mon, Feb 14, 2011 at 9:05 AM, Pierre-Arnaud > > > Marcelot wrote: > > > > One more question. > > > > Should we push this into Shared-1.0.0-M1 or wait for the next > > > > iteration? > > > > Too late, vote already started. But maybe we need to rollback ;-) > > > > > No, let's push all the move to the M2 branch (which has to be renamed, > > btw, it's M1 atm) > > > > We will have lots of modifications in the API in M2 anyway, so don't worry > > too much. M1 != API freeze ! > > How about naming this branch 1.0 and that way we don't have to keep changing > the name with every RC or milestone release we have? Yeah, that sounds a good "stable" naming for this branch. +1 Regards, Pierre-Arnaud
Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
On 2/14/11 6:44 PM, Pierre-Arnaud Marcelot wrote: On lundi 14 février 2011 at 17:29, Alex Karasulu wrote: On Mon, Feb 14, 2011 at 12:15 PM, Emmanuel Lecharny wrote: On 2/14/11 11:05 AM, Stefan Seelmann wrote: On Mon, Feb 14, 2011 at 9:05 AM, Pierre-Arnaud Marcelot wrote: One more question. Should we push this into Shared-1.0.0-M1 or wait for the next iteration? Too late, vote already started. But maybe we need to rollback ;-) No, let's push all the move to the M2 branch (which has to be renamed, btw, it's M1 atm) We will have lots of modifications in the API in M2 anyway, so don't worry too much. M1 != API freeze ! How about naming this branch 1.0 and that way we don't have to keep changing the name with every RC or milestone release we have? Yeah, that sounds a good "stable" naming for this branch. +1 +1 too. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Constructors and Exceptions
Hi guys, this is not the first time this question hits the mailing list, but I don't think we have stated something definitive in this area. Is having a constructor throwing a checked exception a code smell ? Something like : public Dn(String) throws LdapInvalidDnException is acceptable, or should it throw an unchecked exception ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Constructors and Exceptions
Hi Emmanuel, I think it makes perfectly sense in the particular case of a DN. Regards, Pierre-Arnaud On lundi 14 février 2011 at 18:51, Emmanuel Lecharny wrote: > Hi guys, > > this is not the first time this question hits the mailing list, but I > don't think we have stated something definitive in this area. > > Is having a constructor throwing a checked exception a code smell ? > > Something like : > public Dn(String) throws LdapInvalidDnException > > is acceptable, or should it throw an unchecked exception ? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
Re: [Shared] [LDAP API] Additional classes and method arguments for GSSAPI binds
On Mon, Feb 14, 2011 at 5:29 PM, Alex Karasulu wrote: > How about naming this branch 1.0 and that way we don't have to keep changing > the name with every RC or milestone release we have? +1
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On Mon, Feb 14, 2011 at 3:20 PM, Pierre-Arnaud Marcelot wrote: > [X] +1 Release Shared 1.0.0-M1 and JUnit Add-ons 0.1 > I checked the source and binary distribution packages. > The sources package looks good and built successfully via Maven. > I was able to connect to ApacheDS via the libraries included in the binary > distribution package and small hand-written class (written in less than a > minute :) ). > Now, a few points that need discussion and can probably be improved in the > next milestone release: > - I'm not sure the NOTICE file is completely OK and probably needs to > contain a small text entry for each third party library. Yes, that would probably be safer. The reason I only added the reference to the 'licenses' directory was that we don't need to maintain the NOTICE file entries twice. I'll think about a better solution and 'll change that. > - It may be interesting to use the Felix Bundle Maven plugin to make the > 'shared-all' a real OSGI-ready bundle (It's a simple jar ATM). +1 > - It would be also interesting to bundle with the distribution the log4j > dependency, just like we do for ApacheDS. I had to download this aside and > add it to the build path to be able to work with the LDAP API. > I understand that we're using a logging "façade" (SLF4J) to allow the user > to choose the implementation he prefers, but I think most users of the API > won't know and don't care about it. > If we bundle log4j in the final distribution, the LDAP API can be used in > one simple step and people willing to use their logger implementation of > choice can easily remove the bundle log4j and add their own jar. Damn. I added slf4j-log4j12 to the configuration of the maven-dependency-plugin, however there transitive dependencies are not resolved. I'll fix that. Thanks for the heads up. Kind Regards, Stefan
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On Mon, Feb 14, 2011 at 5:37 PM, Felix Knecht wrote: > The NOTICE file in the distribution packages says: > "Additional copyright notices and license terms applicable are > present in the distribution/src/main/release/licenses or > licenses directory." > This is not right, I can't find any licences under the mentioned path. > Licenses in the distributions can be found at "licences". > > I think this can also be fix in next release. For the "bin" packages the "licenses" directory is directly next to the "NOTICE" file. For the "src" packages the "licenses" directory is below "distribution/src/main/release". I added both paths into the NOTICE file. But I agree that's confusing. But for sure it's better to put the "licenses" directory always next to the "NOTICE" file. I'll change that. Kind Regards, Stefan
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On Mon, Feb 14, 2011 at 5:38 PM, Alex Karasulu wrote: > On Mon, Feb 14, 2011 at 11:22 AM, Stefan Seelmann > 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'. > > Why are they prefixed with apache-ldap-api? Hm, because logically those packages contain the LDAP API classes, right? I think at some point we also need to rename "shared" to "ldap-api" or something similar. But you are right, at the moment the naming is not consistent. I can change it to 'shared-distribution' or something similar if you prefer. Kind Regards, Stefan
Re: [VOTE] Release Shared 1.0.0-M1 and JUnit Add-ons 0.1
On Mon, Feb 14, 2011 at 9:44 PM, Stefan Seelmann wrote: > On Mon, Feb 14, 2011 at 5:38 PM, Alex Karasulu > wrote: > > On Mon, Feb 14, 2011 at 11:22 AM, Stefan Seelmann > > 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'. > > > > Why are they prefixed with apache-ldap-api? > > Hm, because logically those packages contain the LDAP API classes, > right? I think at some point we also need to rename "shared" to > "ldap-api" or something similar. I thought shared will hold anything that is shared across our projects like for example Kerberos APIs as well as LDAP and others. For now this name is fitting since that's all we got. Perhaps we need to break up shared into functional areas like LDAP and Kerberos. Let's find out later when things do change. > But you are right, at the moment the > naming is not consistent. I can change it to 'shared-distribution' or > something similar if you prefer. > > No this is OK for now I just wanted to know the reasoning behind the decision. Thanks, Alex
Re: Looking for embedded 1.5.7 sample
Hi Steven, I moved the samples some days ago, here is the one that should work with 1.5.7: http://svn.apache.org/repos/asf/directory/documentation/samples/trunk/embedded-sample/ The trunk sample http://svn.apache.org/repos/asf/directory/documentation/samples/trunk/embedded-sample-trunk/ doesn't compile because too many things changed in trunk. Today I had the idea to add the samples to the /trunks aggregator so that changes in the main code are reflected in the samples. Of course more samples are needed. Kind Regards, Stefan On Mon, Feb 14, 2011 at 11:26 PM, Hammond, Steven wrote: > The link here > http://directory.apache.org/apacheds/1.5/41-embedding-apacheds-into-an-application.html > is dead that was supposed to show a 1.5.7 sample. The one I found on the > trunk doc branch seems to be for trunk and not working in 1.5.7. Any > suggestions? > > > > Thanx.
SchemaManager usage
Hi guys, today, I continued to document the Dn class. I did it on the confluence wiki, as I have a tool to export a confluence docuemnt to a docBook format, which is way more convenient than typing text in XML... Here is the current doco about Dn : https://cwiki.apache.org/confluence/display/DIRAPI/DN+API Feel free to review, and fix it. Ok, that being said, this is a very interesting exercise, as it forces you to use the API and to think like a user. And what we have is not really perfect :/ I'm currently trying to leverage the SchemaManager in Dn, which somehow forced me to create a DefaultSchemaManager INSTANCE static field, which loads the default schemas (those that are enabled by default). Now, creating a schema aware DN is just a matter of calling : Dn dn = new Dn( DefaultSchemaManager.INSTANCE, "dc=example, dc=com"); Works great. Sadly, I had to move the Dn tests out of the shared-ldap-model otherwise there would be no way to use the SchemaManager instance, as it's declared in another module. So I moved it to shared-integ (all in all, I think it's the right place for tests anyway). I'm now going a step further and move some other tests that requires a SchemaManager to shared-integ. I'll keep you in the loop, but feel free to comment. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: SchemaManager usage
On Tue, Feb 15, 2011 at 12:10 AM, Emmanuel Lecharny wrote: > Hi guys, > > today, I continued to document the Dn class. I did it on the confluence > wiki, as I have a tool to export a confluence docuemnt to a docBook format, > which is way more convenient than typing text in XML... Which tool? > Here is the current doco about Dn : > https://cwiki.apache.org/confluence/display/DIRAPI/DN+API > > Feel free to review, and fix it. Great, thanks. One first comment wrt to the code samples. Today I had the idea to create some code samples on how to use the API in the documentation/samples directory (I didn't start yet). One idea I had that it would be cool if the samples project could be added to the "trunks" aggregator so that changes in trunk are directly reflected in the samples. The 2nd idea was that it would be cooler if the examples in the doco could be directly extracted from the samples code. The big problem with code snippets in doco is that it isn't updated when refactorings in the main code are done. Maybe Xinclude (http://www.w3.org/TR/xinclude/) helps here. > Ok, that being said, this is a very interesting exercise, as it forces you > to use the API and to think like a user. And what we have is not really > perfect :/ > > I'm currently trying to leverage the SchemaManager in Dn, which somehow > forced me to create a DefaultSchemaManager INSTANCE static field, which > loads the default schemas (those that are enabled by default). Now, creating > a schema aware DN is just a matter of calling : > > Dn dn = new Dn( DefaultSchemaManager.INSTANCE, "dc=example, dc=com"); > > Works great. Sadly, I had to move the Dn tests out of the shared-ldap-model > otherwise there would be no way to use the SchemaManager instance, as it's > declared in another module. So I moved it to shared-integ (all in all, I > think it's the right place for tests anyway). > > I'm now going a step further and move some other tests that requires a > SchemaManager to shared-integ. I agree that if classes from different modules are used in test then the right location is the shared-integ module. Otherwise, if the test should be kept in the model module a SchemaManager mock is the way to go. Kind Regards, Stefan
Re: SchemaManager usage
On 2/15/11 12:41 AM, Stefan Seelmann wrote: On Tue, Feb 15, 2011 at 12:10 AM, Emmanuel Lecharny wrote: Hi guys, today, I continued to document the Dn class. I did it on the confluence wiki, as I have a tool to export a confluence docuemnt to a docBook format, which is way more convenient than typing text in XML... Which tool? Wikbook. It takes a wiki format and generates docbook formt. Still have to test it, but I know the guy working on it. http://code.google.com/p/wikbook/ Here is the current doco about Dn : https://cwiki.apache.org/confluence/display/DIRAPI/DN+API Feel free to review, and fix it. Great, thanks. One first comment wrt to the code samples. Today I had the idea to create some code samples on how to use the API in the documentation/samples directory (I didn't start yet). One idea I had that it would be cool if the samples project could be added to the "trunks" aggregator so that changes in trunk are directly reflected in the samples. The 2nd idea was that it would be cooler if the examples in the doco could be directly extracted from the samples code. The big problem with code snippets in doco is that it isn't updated when refactorings in the main code are done. Maybe Xinclude (http://www.w3.org/TR/xinclude/) helps here. I have created a project where I put all the code samples I have added in the wiki (just to be sure they are not wrong). I think we can add the code in the apacheds-manual project. So, yes, good idea ! Ok, that being said, this is a very interesting exercise, as it forces you to use the API and to think like a user. And what we have is not really perfect :/ I'm currently trying to leverage the SchemaManager in Dn, which somehow forced me to create a DefaultSchemaManager INSTANCE static field, which loads the default schemas (those that are enabled by default). Now, creating a schema aware DN is just a matter of calling : Dn dn = new Dn( DefaultSchemaManager.INSTANCE, "dc=example, dc=com"); Works great. Sadly, I had to move the Dn tests out of the shared-ldap-model otherwise there would be no way to use the SchemaManager instance, as it's declared in another module. So I moved it to shared-integ (all in all, I think it's the right place for tests anyway). I'm now going a step further and move some other tests that requires a SchemaManager to shared-integ. I agree that if classes from different modules are used in test then the right location is the shared-integ module. Otherwise, if the test should be kept in the model module a SchemaManager mock is the way to go. We can discuss that. Frankly, right now, I'm more into checking the Dn API and writing the doco than thinking about the right place for tests, so I took the path of least resistance. But, basically, you are 100% right : we may have to define a MockSchemaManager. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Looking for embedded 1.5.7 sample
On Tue, Feb 15, 2011 at 1:04 AM, Stefan Seelmann wrote: > Today I had the idea to add the samples to the /trunks aggregator so > that changes in the main code are reflected in the samples. Of course > more samples are needed. That's a good idea. We should definitely do that to prevent the samples from being outdated. Regards, Alex
[jira] Created: (DIRSHARED-98) Make the SchemaManager and SchemaLoaders into an OSGi Service
Make the SchemaManager and SchemaLoaders into an OSGi Service - Key: DIRSHARED-98 URL: https://issues.apache.org/jira/browse/DIRSHARED-98 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 We need to look into making the SchemaManager and SchemaLoaders into an OSGi Service. We may not need the loaders if we can make schemas into bundles themselves. The activators then can load these schemas. Perhaps they'll need a loader and the manager to do the job. Let's see how this works out with a bit of experimentation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12994596#comment-12994596 ] Alex Karasulu commented on DIRSHARED-91: Update: o the DefaultLdapCodecService is working and integrated into the Studio code base o the StandaloneLdapCodecService is also setup and working in the ApacheDS code base Problem: Studio's RCP environment is still going to have issues because ApacheDS modules use the standalone version of the codec. We need to enable studio to setup ApacheDS without having to use the StandaloneLdapCodecService. So we need to expose a means for it to set this on the DirectoryService so Studio can use a DirectoryService without the StandaloneLdapCodecService. > 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
