You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2015/10/14 19:05:00 UTC
[VOTE] Apache LDAP API 1.0.0-M32 release
Hi,
This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
1.0.0-M32.
Another bug fix release, with some huge modifications in the way we
handle Values. The SchemaManager
is now propagated down to the Ava and Value classes, which causes many
tests to have been fixed.
We also have added a LdifAnonymizer that can swallow a Ldif File and
replace the values with a
random text.
We have also spent some time fixing many checkstyle violations.
A few other issues have been fixed.
Here is the list of fixed issues and added features :
Bugs :
------
DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
IllegalArgumentException: factory thrown when creating
LdapNetworkConnection inside OSGi
DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
Reconsider interfaces and base classes for Registries
DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
JUnit TemporaryFolder Rule
DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
DateUtils.toGeneralizedTime does not work with some Locales
DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
GeneralizedTime(String) fails for fraction close to one
DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
Error in parsing LDIF file
DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
Compiling warnings while api-all is in dependencies
DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
AVA class is not handling correctly the values wrt the SchemaManager
DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
Value<?> don't have a apply(AttributeType) method
DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
escaped space at the end of a RDN will not be kept due to a bug in the
ComplexDNParser
Task :
------
DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
violations of coding standards and enable checkstyle check
New Feature :
-------------
DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
a way to Anonymize a LDIF file
Question :
----------
DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
to get attributes list according to objectClass
The revision :
http://svn.apache.org/viewvc?view=revision&revision=1708634<http://svn.apache.org/r1676503>
The SVN tag:
http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
<http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
The source and binary distribution packages:
http://people.apache.org/~elecharny/
<http://people.apache.org/%7Eelecharny/>
The staging repository:
https://repository.apache.org/content/repositories/orgapachedirectory-1044
<https://repository.apache.org/content/repositories/orgapachedirectory-1031>
Please cast your votes:
[ ] +1 Release Shared/LDAP API 1.0.0-M32
[ ] 0 abstain
[ ] -1 Do not release Shared/LDAP API 1.0.0-M32
Emmanuel
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com <http://www.iktek.com>
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Radovan Semancik <ra...@evolveum.com>.
+1 for release
Build on OpenJDK 1.7.0_79 (linux) OK. My tests with OpenLDAP, OpenDJ and
389ds are passing.
--
Radovan Semancik
Software Architect
evolveum.com
On 10/14/2015 07:05 PM, Emmanuel Lécharny wrote:
> Hi,
>
> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M32.
>
>
> Another bug fix release, with some huge modifications in the way we
> handle Values. The SchemaManager
> is now propagated down to the Ava and Value classes, which causes many
> tests to have been fixed.
>
> We also have added a LdifAnonymizer that can swallow a Ldif File and
> replace the values with a
> random text.
>
> We have also spent some time fixing many checkstyle violations.
>
> A few other issues have been fixed.
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> ------
>
> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
> IllegalArgumentException: factory thrown when creating
> LdapNetworkConnection inside OSGi
> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
> Reconsider interfaces and base classes for Registries
> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
> JUnit TemporaryFolder Rule
> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
> DateUtils.toGeneralizedTime does not work with some Locales
> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
> GeneralizedTime(String) fails for fraction close to one
> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
> Error in parsing LDIF file
> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
> Compiling warnings while api-all is in dependencies
> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
> AVA class is not handling correctly the values wrt the SchemaManager
> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
> Value<?> don't have a apply(AttributeType) method
> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
> escaped space at the end of a RDN will not be kept due to a bug in the
> ComplexDNParser
>
>
> Task :
> ------
>
> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
> violations of coding standards and enable checkstyle check
>
>
> New Feature :
> -------------
>
> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
> a way to Anonymize a LDIF file
>
>
> Question :
> ----------
>
> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
> to get attributes list according to objectClass
>
>
> The revision :
>
> http://svn.apache.org/viewvc?view=revision&revision=1708634<http://svn.apache.org/r1676503>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>
> The source and binary distribution packages:
> http://people.apache.org/~elecharny/
> <http://people.apache.org/%7Eelecharny/>
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1044
> <https://repository.apache.org/content/repositories/orgapachedirectory-1031>
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-M32
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
>
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 10/15/2015 07:01 PM, Lucas Theisen wrote:
> Yeah, thats my guess. Though what addresses would these tests be using?
> Do we actually rely on a live external service in our unit test? I dont
> know anything about that osgi pax test suite (clearly).
>
The Pax framework is used to test OSGi. It spawns a new JVM process to
test class loading in a fresh environment outside the current
Maven/Surefire process. I think thatfor it uses RMI. But I have no idea
why it tries to connect to this IP. There should be no dependency on any
external service, I mean I can also run the tests when I'm offline. I'll
dig into the Pax sources.
Kind Regards,
Stefan
Antwort: Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Sven Linscheid <Sv...@minden.edeka.de>.
Great looking forward for the next release to check this against our LDAP
- Structure - great Stuff here !
Mit freundlichen Grüßen
Sven Linscheid
Systembetreuung ITSM / IDM
IT-Qualitätsmanagement
EDEKA Minden-Hannover IT-Service GmbH
Wittelsbacherallee 61, 32427 Minden
Tel.: +49 571 64660-3707
Fax: +49 571 64660-3829
E-Mail: Sven.Linscheid@minden.edeka.de
Web: www.edeka-minden.de
EDEKA - Wir ♥ Lebensmittel.
EDEKA Minden-Hannover IT-Service GmbH
Sitz der Gesellschaft: Minden
Amtsgericht Bad Oeynhausen HRB 4532
Geschäftsführer: Ines Parthum-Becker, Gerhard Riechmann, Dietmar Thake
Diese E-Mail enthält vertrauliche und / oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie den Absender und vernichten Sie
diese E-Mail. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser
E-Mail ist nicht gestattet.
Sparen Sie pro Seite ca. 200 ml Wasser, 2 g CO2 und 2 g Holz. EDEKA Minden
setzt sich für eine nachhaltige Wirtschaftsweise und den schonenden Umgang
mit Ressourcen ein. Bitte drucken Sie nur, wenn es wirklich notwendig ist.
Von: Lucas Theisen <lu...@pastdev.com>
An: Apache Directory Developers List <de...@directory.apache.org>,
Datum: 15.10.2015 20:58
Betreff: Re: [VOTE] Apache LDAP API 1.0.0-M32 release
On Thu, Oct 15, 2015 at 2:32 PM, Lucas Theisen <lu...@pastdev.com>
wrote:
On Thu, Oct 15, 2015 at 1:57 PM, Stefan Seelmann <ma...@stefan-seelmann.de>
wrote:
On 10/15/2015 07:44 PM, Stefan Seelmann wrote:
> On 10/15/2015 07:26 PM, Lucas Theisen wrote:
>>
>> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think
it
>> has to do with java version. I tried turning off firewalld, but no
dice.
>> Could be SELinux, i could try booting without...
>>
>
> Lucas,
>
> What is the output of `nslookup localhost`?
> And is locahost in your /etc/hosts?
>
So in [1] we see the code that starts the forked JVM. It also starts a
RMI LocateRegistry, I think on localhost.
Then the forked process should also try to connect to that registry,
Here [2] [3] are some other examples where connection to RMI registry
failed.
HTH,
Stefan
[1]
https://github.com/ops4j/org.ops4j.pax.exam2/blob/25d5181a00b2e433537e4b53dce50b8925236bc3/containers/pax-exam-container-forked/src/main/java/org/ops4j/pax/exam/forked/ForkedFrameworkFactory.java#L103
[2]
https://stackoverflow.com/questions/6180383/rmi-registry-connecting-to-wrong-adress
[3]
http://knowledgebase.progress.com/articles/Article/AdminServerattemptstobindtothewrongIPAddress
Soooooo. Thanks Stefan, the stackoverflow solution pointed out that the
RMI registry gets the the hostname as follows:
java.net.InetAddress.getLocalHost().getHostAddress();
And from the javadoc [1]:
Returns the address of the local host. This is achieved by retrieving
the name of the host from the system, then resolving that name into
an InetAddress.
The key part here is the "resolving that name". At the top of the javadoc
page for InetAddress in the general comments we see:
Host name-to-IP address resolution is accomplished through
the use of a combination of local machine configuration information
and network naming services such as the Domain Name System (DNS)
and Network Information Service(NIS).
This means that if you are using a machine whose "name of the host from
the system" is NOT registered by name in the "local machine configuration"
then it will attempt to look it up on a "network naming service". If,
like me, your name is not registered in your configured "network naming
service", then the behavior is undefined. In my case it was getting
redirected by my ISP (Verizon FIOS), who sends any name it cannot resolve
to the Non Existent Domain provider "barefruit" with IP address
92.242.140.21. This is then used as the IP address of localhost rather
than the loopback interface. This seems like a really dangerous way to
run unit tests... It seems like bad behavior all around. First, the DNS
server resolving that way is COMPLETELY wrong, but they love their
advertisement. Second, java's getLocalHost() method not confirming that
the IP resolution from the "network naming service" is an IP of a local
interface (after all, the method is NAMED getLocalHost). And, third,
using getLocalHost() with this being the behavior is inherently dangerous
(as request to connect to a service you think is on your localhost is
getting sent somewhere else).
Anyway, I can resolve this build issue by adding my hostname to
/etc/hosts, but we should probably consider switching away from using
InetAddress.getLocalHost().
Lucas
On a side note, i submitted a bug to the PAX folks [1] to avoid using
getLocalHost().
Also, I finished the build succesfully, so:
+1 for release.
[1]https://ops4j1.jira.com/browse/PAXEXAM-740
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Lucas Theisen <lu...@pastdev.com>.
On Thu, Oct 15, 2015 at 2:32 PM, Lucas Theisen <lu...@pastdev.com>
wrote:
> On Thu, Oct 15, 2015 at 1:57 PM, Stefan Seelmann <ma...@stefan-seelmann.de>
> wrote:
>
>> On 10/15/2015 07:44 PM, Stefan Seelmann wrote:
>> > On 10/15/2015 07:26 PM, Lucas Theisen wrote:
>> >>
>> >> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think
>> it
>> >> has to do with java version. I tried turning off firewalld, but no
>> dice.
>> >> Could be SELinux, i could try booting without...
>> >>
>> >
>> > Lucas,
>> >
>> > What is the output of `nslookup localhost`?
>> > And is locahost in your /etc/hosts?
>> >
>>
>> So in [1] we see the code that starts the forked JVM. It also starts a
>> RMI LocateRegistry, I think on localhost.
>>
>> Then the forked process should also try to connect to that registry,
>>
>> Here [2] [3] are some other examples where connection to RMI registry
>> failed.
>>
>> HTH,
>> Stefan
>>
>> [1]
>>
>> https://github.com/ops4j/org.ops4j.pax.exam2/blob/25d5181a00b2e433537e4b53dce50b8925236bc3/containers/pax-exam-container-forked/src/main/java/org/ops4j/pax/exam/forked/ForkedFrameworkFactory.java#L103
>> [2]
>> https://stackoverflow.com/questions/6180383/rmi-registry-connecting-to-wrong-adress
>> [3]
>> http://knowledgebase.progress.com/articles/Article/AdminServerattemptstobindtothewrongIPAddress
>>
>
> Soooooo. Thanks Stefan, the stackoverflow solution pointed out that the
> RMI registry gets the the hostname as follows:
>
> java.net.InetAddress.getLocalHost().getHostAddress();
>
> And from the javadoc [1]:
>
> Returns the address of the local host. This is achieved by retrieving
> the name of the host from the system, then resolving that name into
> an InetAddress.
>
> The key part here is the "resolving that name". At the top of the javadoc
> page for InetAddress in the general comments we see:
>
> Host name-to-IP address resolution is accomplished through
> the use of a combination of local machine configuration information
> and network naming services such as the Domain Name System (DNS)
> and Network Information Service(NIS).
>
> This means that if you are using a machine whose "name of the host from
> the system" is NOT registered by name in the "local machine configuration"
> then it will attempt to look it up on a "network naming service". If, like
> me, your name is not registered in your configured "network naming
> service", then the behavior is undefined. In my case it was getting
> redirected by my ISP (Verizon FIOS), who sends any name it cannot resolve
> to the Non Existent Domain provider "barefruit" with IP address
> 92.242.140.21. This is then used as the IP address of localhost rather
> than the loopback interface. This seems like a really dangerous way to run
> unit tests... It seems like bad behavior all around. First, the DNS
> server resolving that way is COMPLETELY wrong, but they love their
> advertisement. Second, java's getLocalHost() method not confirming that
> the IP resolution from the "network naming service" is an IP of a local
> interface (after all, the method is NAMED getLocalHost). And, third, using
> getLocalHost() with this being the behavior is inherently dangerous (as
> request to connect to a service you think is on your localhost is getting
> sent somewhere else).
>
> Anyway, I can resolve this build issue by adding my hostname to
> /etc/hosts, but we should probably consider switching away from using
> InetAddress.getLocalHost().
>
> Lucas
>
On a side note, i submitted a bug to the PAX folks [1] to avoid using
getLocalHost().
Also, I finished the build succesfully, so:
+1 for release.
[1]https://ops4j1.jira.com/browse/PAXEXAM-740
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Lucas Theisen <lu...@pastdev.com>.
On Thu, Oct 15, 2015 at 1:57 PM, Stefan Seelmann <ma...@stefan-seelmann.de>
wrote:
> On 10/15/2015 07:44 PM, Stefan Seelmann wrote:
> > On 10/15/2015 07:26 PM, Lucas Theisen wrote:
> >>
> >> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think
> it
> >> has to do with java version. I tried turning off firewalld, but no
> dice.
> >> Could be SELinux, i could try booting without...
> >>
> >
> > Lucas,
> >
> > What is the output of `nslookup localhost`?
> > And is locahost in your /etc/hosts?
> >
>
> So in [1] we see the code that starts the forked JVM. It also starts a
> RMI LocateRegistry, I think on localhost.
>
> Then the forked process should also try to connect to that registry,
>
> Here [2] [3] are some other examples where connection to RMI registry
> failed.
>
> HTH,
> Stefan
>
> [1]
>
> https://github.com/ops4j/org.ops4j.pax.exam2/blob/25d5181a00b2e433537e4b53dce50b8925236bc3/containers/pax-exam-container-forked/src/main/java/org/ops4j/pax/exam/forked/ForkedFrameworkFactory.java#L103
> [2]
> https://stackoverflow.com/questions/6180383/rmi-registry-connecting-to-wrong-adress
> [3]
> http://knowledgebase.progress.com/articles/Article/AdminServerattemptstobindtothewrongIPAddress
>
Soooooo. Thanks Stefan, the stackoverflow solution pointed out that the
RMI registry gets the the hostname as follows:
java.net.InetAddress.getLocalHost().getHostAddress();
And from the javadoc [1]:
Returns the address of the local host. This is achieved by retrieving
the name of the host from the system, then resolving that name into
an InetAddress.
The key part here is the "resolving that name". At the top of the javadoc
page for InetAddress in the general comments we see:
Host name-to-IP address resolution is accomplished through
the use of a combination of local machine configuration information
and network naming services such as the Domain Name System (DNS)
and Network Information Service(NIS).
This means that if you are using a machine whose "name of the host from the
system" is NOT registered by name in the "local machine configuration" then
it will attempt to look it up on a "network naming service". If, like me,
your name is not registered in your configured "network naming service",
then the behavior is undefined. In my case it was getting redirected by my
ISP (Verizon FIOS), who sends any name it cannot resolve to the Non
Existent Domain provider "barefruit" with IP address 92.242.140.21. This
is then used as the IP address of localhost rather than the loopback
interface. This seems like a really dangerous way to run unit tests... It
seems like bad behavior all around. First, the DNS server resolving that
way is COMPLETELY wrong, but they love their advertisement. Second, java's
getLocalHost() method not confirming that the IP resolution from the
"network naming service" is an IP of a local interface (after all, the
method is NAMED getLocalHost). And, third, using getLocalHost() with this
being the behavior is inherently dangerous (as request to connect to a
service you think is on your localhost is getting sent somewhere else).
Anyway, I can resolve this build issue by adding my hostname to /etc/hosts,
but we should probably consider switching away from using
InetAddress.getLocalHost().
Lucas
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 10/15/2015 07:44 PM, Stefan Seelmann wrote:
> On 10/15/2015 07:26 PM, Lucas Theisen wrote:
>>
>> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think it
>> has to do with java version. I tried turning off firewalld, but no dice.
>> Could be SELinux, i could try booting without...
>>
>
> Lucas,
>
> What is the output of `nslookup localhost`?
> And is locahost in your /etc/hosts?
>
So in [1] we see the code that starts the forked JVM. It also starts a
RMI LocateRegistry, I think on localhost.
Then the forked process should also try to connect to that registry,
Here [2] [3] are some other examples where connection to RMI registry
failed.
HTH,
Stefan
[1]
https://github.com/ops4j/org.ops4j.pax.exam2/blob/25d5181a00b2e433537e4b53dce50b8925236bc3/containers/pax-exam-container-forked/src/main/java/org/ops4j/pax/exam/forked/ForkedFrameworkFactory.java#L103
[2]https://stackoverflow.com/questions/6180383/rmi-registry-connecting-to-wrong-adress
[3]http://knowledgebase.progress.com/articles/Article/AdminServerattemptstobindtothewrongIPAddress
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 10/15/2015 07:26 PM, Lucas Theisen wrote:
>
> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think it
> has to do with java version. I tried turning off firewalld, but no dice.
> Could be SELinux, i could try booting without...
>
Lucas,
What is the output of `nslookup localhost`?
And is locahost in your /etc/hosts?
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Lucas Theisen <lu...@pastdev.com>.
On Thu, Oct 15, 2015 at 1:26 PM, Lucas Theisen <lu...@pastdev.com>
wrote:
> On Thu, Oct 15, 2015 at 1:01 PM, Lucas Theisen <lu...@pastdev.com>
> wrote:
>
>> Yeah, thats my guess. Though what addresses would these tests be using?
>> Do we actually rely on a live external service in our unit test? I dont
>> know anything about that osgi pax test suite (clearly).
>>
>>
>> On Thu, Oct 15, 2015 at 12:32 PM, Emmanuel Lécharny <el...@gmail.com>
>> wrote:
>>
>>> Le 15/10/15 18:22, Lucas Theisen a écrit :
>>> > On Wed, Oct 14, 2015 at 10:59 PM, Kiran Ayyagari <kayyagari@apache.org
>>> >
>>> > wrote:
>>> >
>>> >>
>>> >> On Thu, Oct 15, 2015 at 4:36 AM, Lucas Theisen <
>>> lucastheisen@pastdev.com>
>>> >> wrote:
>>> >>
>>> >>> On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny <
>>> elecharny@apache.org>
>>> >>> wrote:
>>> >>>
>>> >>>> Also note that the following issues have been fixed (some of them a
>>> long
>>> >>>> time ago) :
>>> >>>>
>>> >>>> DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-185>
>>> >>>> DIRAPI-171 - Entry.toString() shoud not add single quotes around
>>> binary
>>> >>>> values (1.0.0-M21) <
>>> https://issues.apache.org/jira/browse/DIRAPI-171>
>>> >>>> DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-146>
>>> >>>> DIRAPI-141 - pwdPolicySubentry AttributeType should be
>>> >>>> directoryOperation (1.0.0-M21)
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-141>
>>> >>>>
>>> >>>> DIRAPI-131 - Make the StartTLS an extended request/response
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
>>> >>>>
>>> >>>> DIRAPI-114 - Reconsider interfaces and base classes for Registries
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
>>> >>>>
>>> >>>> DIRAPI-113 - Distribution module should generate GPG/PGP signatures
>>> and
>>> >>>> MD5/SHA checksums (1.0.0-M21)
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-113>
>>> >>>>
>>> >>>> DIRAPI-101 - Allow the user to define the underlaying IO library to
>>> use
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>> >>>>
>>> >>>> DIRAPI-85 - Provide a class allowing 'parent-first' sorting of
>>> entries
>>> >>>> from a search result (1.0.0-M21)
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>> >>>>
>>> >>>> DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for
>>> >>>> Schema Objects does not support escaped strings in the description
>>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
>>> >>>>
>>> >>>>
>>> >>>> On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <
>>> elecharny@gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> Hi,
>>> >>>>>
>>> >>>>> This is a vote for the 32th milestone of the 1.0.0 LDAP
>>> API/Shared,
>>> >>>>> 1.0.0-M32.
>>> >>>>>
>>> >>>>>
>>> >>>>> Another bug fix release, with some huge modifications in the way we
>>> >>>>> handle Values. The SchemaManager
>>> >>>>> is now propagated down to the Ava and Value classes, which causes
>>> many
>>> >>>>> tests to have been fixed.
>>> >>>>>
>>> >>>>> We also have added a LdifAnonymizer that can swallow a Ldif File
>>> and
>>> >>>>> replace the values with a
>>> >>>>> random text.
>>> >>>>>
>>> >>>>> We have also spent some time fixing many checkstyle violations.
>>> >>>>>
>>> >>>>> A few other issues have been fixed.
>>> >>>>>
>>> >>>>> Here is the list of fixed issues and added features :
>>> >>>>>
>>> >>>>>
>>> >>>>> Bugs :
>>> >>>>> ------
>>> >>>>>
>>> >>>>> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
>>> >>>>> IllegalArgumentException: factory thrown when creating
>>> >>>>> LdapNetworkConnection inside OSGi
>>> >>>>> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114>
>>> -
>>> >>>>> Reconsider interfaces and base classes for Registries
>>> >>>>> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118>
>>> - Use
>>> >>>>> JUnit TemporaryFolder Rule
>>> >>>>> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219>
>>> -
>>> >>>>> DateUtils.toGeneralizedTime does not work with some Locales
>>> >>>>> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241>
>>> - new
>>> >>>>> GeneralizedTime(String) fails for fraction close to one
>>> >>>>> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246>
>>> -
>>> >>>>> Error in parsing LDIF file
>>> >>>>> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252>
>>> -
>>> >>>>> Compiling warnings while api-all is in dependencies
>>> >>>>> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253>
>>> - The
>>> >>>>> AVA class is not handling correctly the values wrt the
>>> SchemaManager
>>> >>>>> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254>
>>> -
>>> >>>>> Value<?> don't have a apply(AttributeType) method
>>> >>>>> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255>
>>> - An
>>> >>>>> escaped space at the end of a RDN will not be kept due to a bug in
>>> the
>>> >>>>> ComplexDNParser
>>> >>>>>
>>> >>>>>
>>> >>>>> Task :
>>> >>>>> ------
>>> >>>>>
>>> >>>>> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251>
>>> - Fix
>>> >>>>> violations of coding standards and enable checkstyle check
>>> >>>>>
>>> >>>>>
>>> >>>>> New Feature :
>>> >>>>> -------------
>>> >>>>>
>>> >>>>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250>
>>> - Add
>>> >>>>> a way to Anonymize a LDIF file
>>> >>>>>
>>> >>>>>
>>> >>>>> Question :
>>> >>>>> ----------
>>> >>>>>
>>> >>>>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191>
>>> - How
>>> >>>>> to get attributes list according to objectClass
>>> >>>>>
>>> >>>>>
>>> >>>>> The revision :
>>> >>>>>
>>> >>>>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
>>> >>>>> http://svn.apache.org/r1676503>
>>> >>>>>
>>> >>>>> The SVN tag:
>>> >>>>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
>>> >>>>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>>> >>>>>
>>> >>>>> The source and binary distribution packages:
>>> >>>>> http://people.apache.org/~elecharny/
>>> >>>>> <http://people.apache.org/%7Eelecharny/>
>>> >>>>>
>>> >>>>> The staging repository:
>>> >>>>>
>>> >>>>>
>>> https://repository.apache.org/content/repositories/orgapachedirectory-1044
>>> >>>>> <
>>> >>>>>
>>> https://repository.apache.org/content/repositories/orgapachedirectory-1031
>>> >>>>>
>>> >>>>> Please cast your votes:
>>> >>>>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
>>> >>>>> [ ] 0 abstain
>>> >>>>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>>> >>>>>
>>> >>>>>
>>> >>>>> Emmanuel
>>> >>>>>
>>> >>>>> --
>>> >>>>> Regards,
>>> >>>>> Cordialement,
>>> >>>>> Emmanuel Lécharny
>>> >>>>> www.iktek.com <http://www.iktek.com>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Regards,
>>> >>>> Cordialement,
>>> >>>> Emmanuel Lécharny
>>> >>>> www.iktek.com
>>> >>>>
>>> >>> I pulled the tag and attempted to "mvn clean install", but i get this
>>> >>> exception in the integ-osgi module:
>>> >>>
>>> >>> Running
>>> org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
>>> >>>
>>> >>> Exception in thread "main" java.rmi.ConnectException: Connection
>>> >>> refused to host: 92.242.140.21; nested exception is:
>>> >>> java.net.ConnectException: Connection refused
>>> >>> at
>>> >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>>> >>> at
>>> >>>
>>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>>> >>> at
>>> >>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>>> >>> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
>>> >>> at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown
>>> Source)
>>> >>> at
>>> >>>
>>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
>>> >>> at
>>> >>>
>>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.<init>(RemoteFrameworkImpl.java:77)
>>> >>> at
>>> >>>
>>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
>>> >>> Caused by: java.net.ConnectException: Connection refused
>>> >>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>> >>> at
>>> >>>
>>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>>> >>> at
>>> >>>
>>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>>> >>> at
>>> >>>
>>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>>> >>> at
>>> java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>> >>> at java.net.Socket.connect(Socket.java:579)
>>> >>> at java.net.Socket.connect(Socket.java:528)
>>> >>> at java.net.Socket.<init>(Socket.java:425)
>>> >>> at java.net.Socket.<init>(Socket.java:208)
>>> >>> at
>>> >>>
>>> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
>>> >>> at
>>> >>>
>>> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
>>> >>> at
>>> >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
>>> >>> ... 7 more
>>> >>>
>>> >>> This is a new build VM (CentOS 7) that i created just for builds
>>> because
>>> >>> they never work on windows. Could it be SELinux? Or maybe
>>> firewall? Is
>>> >>> there a reason its using external IP instead of loopback IP?
>>> >>>
>>> >> hmmmm, it didn't happen on my machine (mac OS X)
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Kiran Ayyagari
>>> >> http://keydap.com
>>> >>
>>> > Ok, so I tried again, still no dice. I am a little confused as to why
>>> this
>>> > integration test would be attempting to communicate with:
>>> >
>>> > [ltheisen@ltbuild integ-osgi]$ nslookup 92.242.140.21
>>> > Server: 192.168.1.1
>>> > Address: 192.168.1.1#53
>>> >
>>> > Non-authoritative answer:
>>> > 21.140.242.92.in-addr.arpa name = unallocated.barefruit.co.uk.
>>> >
>>> > A little research shows that barefruit is a Non Existent Domain
>>> provider
>>> > for Verizon FIOS (my internet provider), so basically it appears that
>>> > something in these unit tests must be hitting DNS for something that
>>> my DNS
>>> > providers are unable to find.
>>>
>>> This address is a site that injects some advertizement when you get an
>>> HTTP or DNS error... Fuckers...
>>>
>>> So I guess some adress used in the test does not resolve correctly and
>>> you then get this error message.
>>>
>>>
>>>
>>
>
> I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think it
> has to do with java version. I tried turning off firewalld, but no dice.
> Could be SELinux, i could try booting without...
>
Nope, not SELinux either... This is strange.
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Lucas Theisen <lu...@pastdev.com>.
On Thu, Oct 15, 2015 at 1:01 PM, Lucas Theisen <lu...@pastdev.com>
wrote:
> Yeah, thats my guess. Though what addresses would these tests be using?
> Do we actually rely on a live external service in our unit test? I dont
> know anything about that osgi pax test suite (clearly).
>
>
> On Thu, Oct 15, 2015 at 12:32 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
>> Le 15/10/15 18:22, Lucas Theisen a écrit :
>> > On Wed, Oct 14, 2015 at 10:59 PM, Kiran Ayyagari <ka...@apache.org>
>> > wrote:
>> >
>> >>
>> >> On Thu, Oct 15, 2015 at 4:36 AM, Lucas Theisen <
>> lucastheisen@pastdev.com>
>> >> wrote:
>> >>
>> >>> On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny <
>> elecharny@apache.org>
>> >>> wrote:
>> >>>
>> >>>> Also note that the following issues have been fixed (some of them a
>> long
>> >>>> time ago) :
>> >>>>
>> >>>> DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-185>
>> >>>> DIRAPI-171 - Entry.toString() shoud not add single quotes around
>> binary
>> >>>> values (1.0.0-M21) <
>> https://issues.apache.org/jira/browse/DIRAPI-171>
>> >>>> DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-146>
>> >>>> DIRAPI-141 - pwdPolicySubentry AttributeType should be
>> >>>> directoryOperation (1.0.0-M21)
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-141>
>> >>>>
>> >>>> DIRAPI-131 - Make the StartTLS an extended request/response
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
>> >>>>
>> >>>> DIRAPI-114 - Reconsider interfaces and base classes for Registries
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
>> >>>>
>> >>>> DIRAPI-113 - Distribution module should generate GPG/PGP signatures
>> and
>> >>>> MD5/SHA checksums (1.0.0-M21)
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-113>
>> >>>>
>> >>>> DIRAPI-101 - Allow the user to define the underlaying IO library to
>> use
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>> >>>>
>> >>>> DIRAPI-85 - Provide a class allowing 'parent-first' sorting of
>> entries
>> >>>> from a search result (1.0.0-M21)
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>> >>>>
>> >>>> DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for
>> >>>> Schema Objects does not support escaped strings in the description
>> >>>> <https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
>> >>>>
>> >>>>
>> >>>> On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <
>> elecharny@gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
>> >>>>> 1.0.0-M32.
>> >>>>>
>> >>>>>
>> >>>>> Another bug fix release, with some huge modifications in the way we
>> >>>>> handle Values. The SchemaManager
>> >>>>> is now propagated down to the Ava and Value classes, which causes
>> many
>> >>>>> tests to have been fixed.
>> >>>>>
>> >>>>> We also have added a LdifAnonymizer that can swallow a Ldif File and
>> >>>>> replace the values with a
>> >>>>> random text.
>> >>>>>
>> >>>>> We have also spent some time fixing many checkstyle violations.
>> >>>>>
>> >>>>> A few other issues have been fixed.
>> >>>>>
>> >>>>> Here is the list of fixed issues and added features :
>> >>>>>
>> >>>>>
>> >>>>> Bugs :
>> >>>>> ------
>> >>>>>
>> >>>>> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
>> >>>>> IllegalArgumentException: factory thrown when creating
>> >>>>> LdapNetworkConnection inside OSGi
>> >>>>> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
>> >>>>> Reconsider interfaces and base classes for Registries
>> >>>>> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118>
>> - Use
>> >>>>> JUnit TemporaryFolder Rule
>> >>>>> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
>> >>>>> DateUtils.toGeneralizedTime does not work with some Locales
>> >>>>> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241>
>> - new
>> >>>>> GeneralizedTime(String) fails for fraction close to one
>> >>>>> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
>> >>>>> Error in parsing LDIF file
>> >>>>> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
>> >>>>> Compiling warnings while api-all is in dependencies
>> >>>>> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253>
>> - The
>> >>>>> AVA class is not handling correctly the values wrt the SchemaManager
>> >>>>> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
>> >>>>> Value<?> don't have a apply(AttributeType) method
>> >>>>> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255>
>> - An
>> >>>>> escaped space at the end of a RDN will not be kept due to a bug in
>> the
>> >>>>> ComplexDNParser
>> >>>>>
>> >>>>>
>> >>>>> Task :
>> >>>>> ------
>> >>>>>
>> >>>>> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251>
>> - Fix
>> >>>>> violations of coding standards and enable checkstyle check
>> >>>>>
>> >>>>>
>> >>>>> New Feature :
>> >>>>> -------------
>> >>>>>
>> >>>>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250>
>> - Add
>> >>>>> a way to Anonymize a LDIF file
>> >>>>>
>> >>>>>
>> >>>>> Question :
>> >>>>> ----------
>> >>>>>
>> >>>>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191>
>> - How
>> >>>>> to get attributes list according to objectClass
>> >>>>>
>> >>>>>
>> >>>>> The revision :
>> >>>>>
>> >>>>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
>> >>>>> http://svn.apache.org/r1676503>
>> >>>>>
>> >>>>> The SVN tag:
>> >>>>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
>> >>>>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>> >>>>>
>> >>>>> The source and binary distribution packages:
>> >>>>> http://people.apache.org/~elecharny/
>> >>>>> <http://people.apache.org/%7Eelecharny/>
>> >>>>>
>> >>>>> The staging repository:
>> >>>>>
>> >>>>>
>> https://repository.apache.org/content/repositories/orgapachedirectory-1044
>> >>>>> <
>> >>>>>
>> https://repository.apache.org/content/repositories/orgapachedirectory-1031
>> >>>>>
>> >>>>> Please cast your votes:
>> >>>>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
>> >>>>> [ ] 0 abstain
>> >>>>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>> >>>>>
>> >>>>>
>> >>>>> Emmanuel
>> >>>>>
>> >>>>> --
>> >>>>> Regards,
>> >>>>> Cordialement,
>> >>>>> Emmanuel Lécharny
>> >>>>> www.iktek.com <http://www.iktek.com>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Regards,
>> >>>> Cordialement,
>> >>>> Emmanuel Lécharny
>> >>>> www.iktek.com
>> >>>>
>> >>> I pulled the tag and attempted to "mvn clean install", but i get this
>> >>> exception in the integ-osgi module:
>> >>>
>> >>> Running
>> org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
>> >>>
>> >>> Exception in thread "main" java.rmi.ConnectException: Connection
>> >>> refused to host: 92.242.140.21; nested exception is:
>> >>> java.net.ConnectException: Connection refused
>> >>> at
>> >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>> >>> at
>> >>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>> >>> at
>> >>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>> >>> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
>> >>> at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown
>> Source)
>> >>> at
>> >>>
>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
>> >>> at
>> >>>
>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.<init>(RemoteFrameworkImpl.java:77)
>> >>> at
>> >>>
>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
>> >>> Caused by: java.net.ConnectException: Connection refused
>> >>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>> >>> at
>> >>>
>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>> >>> at
>> >>>
>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>> >>> at
>> >>>
>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>> >>> at
>> java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>> >>> at java.net.Socket.connect(Socket.java:579)
>> >>> at java.net.Socket.connect(Socket.java:528)
>> >>> at java.net.Socket.<init>(Socket.java:425)
>> >>> at java.net.Socket.<init>(Socket.java:208)
>> >>> at
>> >>>
>> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
>> >>> at
>> >>>
>> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
>> >>> at
>> >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
>> >>> ... 7 more
>> >>>
>> >>> This is a new build VM (CentOS 7) that i created just for builds
>> because
>> >>> they never work on windows. Could it be SELinux? Or maybe
>> firewall? Is
>> >>> there a reason its using external IP instead of loopback IP?
>> >>>
>> >> hmmmm, it didn't happen on my machine (mac OS X)
>> >>
>> >>
>> >>
>> >> --
>> >> Kiran Ayyagari
>> >> http://keydap.com
>> >>
>> > Ok, so I tried again, still no dice. I am a little confused as to why
>> this
>> > integration test would be attempting to communicate with:
>> >
>> > [ltheisen@ltbuild integ-osgi]$ nslookup 92.242.140.21
>> > Server: 192.168.1.1
>> > Address: 192.168.1.1#53
>> >
>> > Non-authoritative answer:
>> > 21.140.242.92.in-addr.arpa name = unallocated.barefruit.co.uk.
>> >
>> > A little research shows that barefruit is a Non Existent Domain provider
>> > for Verizon FIOS (my internet provider), so basically it appears that
>> > something in these unit tests must be hitting DNS for something that my
>> DNS
>> > providers are unable to find.
>>
>> This address is a site that injects some advertizement when you get an
>> HTTP or DNS error... Fuckers...
>>
>> So I guess some adress used in the test does not resolve correctly and
>> you then get this error message.
>>
>>
>>
>
I tried both Oracle jdk1.8.0_60 and openjdk-1.7.0.71, so i don't think it
has to do with java version. I tried turning off firewalld, but no dice.
Could be SELinux, i could try booting without...
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Lucas Theisen <lu...@pastdev.com>.
Yeah, thats my guess. Though what addresses would these tests be using?
Do we actually rely on a live external service in our unit test? I dont
know anything about that osgi pax test suite (clearly).
On Thu, Oct 15, 2015 at 12:32 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 15/10/15 18:22, Lucas Theisen a écrit :
> > On Wed, Oct 14, 2015 at 10:59 PM, Kiran Ayyagari <ka...@apache.org>
> > wrote:
> >
> >>
> >> On Thu, Oct 15, 2015 at 4:36 AM, Lucas Theisen <
> lucastheisen@pastdev.com>
> >> wrote:
> >>
> >>> On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny <
> elecharny@apache.org>
> >>> wrote:
> >>>
> >>>> Also note that the following issues have been fixed (some of them a
> long
> >>>> time ago) :
> >>>>
> >>>> DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-185>
> >>>> DIRAPI-171 - Entry.toString() shoud not add single quotes around
> binary
> >>>> values (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-171
> >
> >>>> DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-146>
> >>>> DIRAPI-141 - pwdPolicySubentry AttributeType should be
> >>>> directoryOperation (1.0.0-M21)
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-141>
> >>>>
> >>>> DIRAPI-131 - Make the StartTLS an extended request/response
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
> >>>>
> >>>> DIRAPI-114 - Reconsider interfaces and base classes for Registries
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
> >>>>
> >>>> DIRAPI-113 - Distribution module should generate GPG/PGP signatures
> and
> >>>> MD5/SHA checksums (1.0.0-M21)
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-113>
> >>>>
> >>>> DIRAPI-101 - Allow the user to define the underlaying IO library to
> use
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
> >>>>
> >>>> DIRAPI-85 - Provide a class allowing 'parent-first' sorting of entries
> >>>> from a search result (1.0.0-M21)
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
> >>>>
> >>>> DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for
> >>>> Schema Objects does not support escaped strings in the description
> >>>> <https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
> >>>>
> >>>>
> >>>> On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <
> elecharny@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> >>>>> 1.0.0-M32.
> >>>>>
> >>>>>
> >>>>> Another bug fix release, with some huge modifications in the way we
> >>>>> handle Values. The SchemaManager
> >>>>> is now propagated down to the Ava and Value classes, which causes
> many
> >>>>> tests to have been fixed.
> >>>>>
> >>>>> We also have added a LdifAnonymizer that can swallow a Ldif File and
> >>>>> replace the values with a
> >>>>> random text.
> >>>>>
> >>>>> We have also spent some time fixing many checkstyle violations.
> >>>>>
> >>>>> A few other issues have been fixed.
> >>>>>
> >>>>> Here is the list of fixed issues and added features :
> >>>>>
> >>>>>
> >>>>> Bugs :
> >>>>> ------
> >>>>>
> >>>>> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
> >>>>> IllegalArgumentException: factory thrown when creating
> >>>>> LdapNetworkConnection inside OSGi
> >>>>> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
> >>>>> Reconsider interfaces and base classes for Registries
> >>>>> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> -
> Use
> >>>>> JUnit TemporaryFolder Rule
> >>>>> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
> >>>>> DateUtils.toGeneralizedTime does not work with some Locales
> >>>>> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> -
> new
> >>>>> GeneralizedTime(String) fails for fraction close to one
> >>>>> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
> >>>>> Error in parsing LDIF file
> >>>>> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
> >>>>> Compiling warnings while api-all is in dependencies
> >>>>> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> -
> The
> >>>>> AVA class is not handling correctly the values wrt the SchemaManager
> >>>>> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
> >>>>> Value<?> don't have a apply(AttributeType) method
> >>>>> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> -
> An
> >>>>> escaped space at the end of a RDN will not be kept due to a bug in
> the
> >>>>> ComplexDNParser
> >>>>>
> >>>>>
> >>>>> Task :
> >>>>> ------
> >>>>>
> >>>>> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> -
> Fix
> >>>>> violations of coding standards and enable checkstyle check
> >>>>>
> >>>>>
> >>>>> New Feature :
> >>>>> -------------
> >>>>>
> >>>>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> -
> Add
> >>>>> a way to Anonymize a LDIF file
> >>>>>
> >>>>>
> >>>>> Question :
> >>>>> ----------
> >>>>>
> >>>>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> -
> How
> >>>>> to get attributes list according to objectClass
> >>>>>
> >>>>>
> >>>>> The revision :
> >>>>>
> >>>>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
> >>>>> http://svn.apache.org/r1676503>
> >>>>>
> >>>>> The SVN tag:
> >>>>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
> >>>>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
> >>>>>
> >>>>> The source and binary distribution packages:
> >>>>> http://people.apache.org/~elecharny/
> >>>>> <http://people.apache.org/%7Eelecharny/>
> >>>>>
> >>>>> The staging repository:
> >>>>>
> >>>>>
> https://repository.apache.org/content/repositories/orgapachedirectory-1044
> >>>>> <
> >>>>>
> https://repository.apache.org/content/repositories/orgapachedirectory-1031
> >>>>>
> >>>>> Please cast your votes:
> >>>>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
> >>>>> [ ] 0 abstain
> >>>>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
> >>>>>
> >>>>>
> >>>>> Emmanuel
> >>>>>
> >>>>> --
> >>>>> Regards,
> >>>>> Cordialement,
> >>>>> Emmanuel Lécharny
> >>>>> www.iktek.com <http://www.iktek.com>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Cordialement,
> >>>> Emmanuel Lécharny
> >>>> www.iktek.com
> >>>>
> >>> I pulled the tag and attempted to "mvn clean install", but i get this
> >>> exception in the integ-osgi module:
> >>>
> >>> Running
> org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
> >>>
> >>> Exception in thread "main" java.rmi.ConnectException: Connection
> >>> refused to host: 92.242.140.21; nested exception is:
> >>> java.net.ConnectException: Connection refused
> >>> at
> >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
> >>> at
> >>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> >>> at
> >>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> >>> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
> >>> at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown
> Source)
> >>> at
> >>>
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
> >>> at
> >>>
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.<init>(RemoteFrameworkImpl.java:77)
> >>> at
> >>>
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
> >>> Caused by: java.net.ConnectException: Connection refused
> >>> at java.net.PlainSocketImpl.socketConnect(Native Method)
> >>> at
> >>>
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
> >>> at
> >>>
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
> >>> at
> >>>
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
> >>> at
> java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> >>> at java.net.Socket.connect(Socket.java:579)
> >>> at java.net.Socket.connect(Socket.java:528)
> >>> at java.net.Socket.<init>(Socket.java:425)
> >>> at java.net.Socket.<init>(Socket.java:208)
> >>> at
> >>>
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
> >>> at
> >>>
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
> >>> at
> >>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
> >>> ... 7 more
> >>>
> >>> This is a new build VM (CentOS 7) that i created just for builds
> because
> >>> they never work on windows. Could it be SELinux? Or maybe firewall?
> Is
> >>> there a reason its using external IP instead of loopback IP?
> >>>
> >> hmmmm, it didn't happen on my machine (mac OS X)
> >>
> >>
> >>
> >> --
> >> Kiran Ayyagari
> >> http://keydap.com
> >>
> > Ok, so I tried again, still no dice. I am a little confused as to why
> this
> > integration test would be attempting to communicate with:
> >
> > [ltheisen@ltbuild integ-osgi]$ nslookup 92.242.140.21
> > Server: 192.168.1.1
> > Address: 192.168.1.1#53
> >
> > Non-authoritative answer:
> > 21.140.242.92.in-addr.arpa name = unallocated.barefruit.co.uk.
> >
> > A little research shows that barefruit is a Non Existent Domain provider
> > for Verizon FIOS (my internet provider), so basically it appears that
> > something in these unit tests must be hitting DNS for something that my
> DNS
> > providers are unable to find.
>
> This address is a site that injects some advertizement when you get an
> HTTP or DNS error... Fuckers...
>
> So I guess some adress used in the test does not resolve correctly and
> you then get this error message.
>
>
>
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 15/10/15 18:22, Lucas Theisen a écrit :
> On Wed, Oct 14, 2015 at 10:59 PM, Kiran Ayyagari <ka...@apache.org>
> wrote:
>
>>
>> On Thu, Oct 15, 2015 at 4:36 AM, Lucas Theisen <lu...@pastdev.com>
>> wrote:
>>
>>> On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny <el...@apache.org>
>>> wrote:
>>>
>>>> Also note that the following issues have been fixed (some of them a long
>>>> time ago) :
>>>>
>>>> DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
>>>> <https://issues.apache.org/jira/browse/DIRAPI-185>
>>>> DIRAPI-171 - Entry.toString() shoud not add single quotes around binary
>>>> values (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-171>
>>>> DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
>>>> <https://issues.apache.org/jira/browse/DIRAPI-146>
>>>> DIRAPI-141 - pwdPolicySubentry AttributeType should be
>>>> directoryOperation (1.0.0-M21)
>>>> <https://issues.apache.org/jira/browse/DIRAPI-141>
>>>>
>>>> DIRAPI-131 - Make the StartTLS an extended request/response
>>>> <https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
>>>>
>>>> DIRAPI-114 - Reconsider interfaces and base classes for Registries
>>>> <https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
>>>>
>>>> DIRAPI-113 - Distribution module should generate GPG/PGP signatures and
>>>> MD5/SHA checksums (1.0.0-M21)
>>>> <https://issues.apache.org/jira/browse/DIRAPI-113>
>>>>
>>>> DIRAPI-101 - Allow the user to define the underlaying IO library to use
>>>> <https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
>>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>>>
>>>> DIRAPI-85 - Provide a class allowing 'parent-first' sorting of entries
>>>> from a search result (1.0.0-M21)
>>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>>>
>>>> DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for
>>>> Schema Objects does not support escaped strings in the description
>>>> <https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
>>>>
>>>>
>>>> On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <el...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
>>>>> 1.0.0-M32.
>>>>>
>>>>>
>>>>> Another bug fix release, with some huge modifications in the way we
>>>>> handle Values. The SchemaManager
>>>>> is now propagated down to the Ava and Value classes, which causes many
>>>>> tests to have been fixed.
>>>>>
>>>>> We also have added a LdifAnonymizer that can swallow a Ldif File and
>>>>> replace the values with a
>>>>> random text.
>>>>>
>>>>> We have also spent some time fixing many checkstyle violations.
>>>>>
>>>>> A few other issues have been fixed.
>>>>>
>>>>> Here is the list of fixed issues and added features :
>>>>>
>>>>>
>>>>> Bugs :
>>>>> ------
>>>>>
>>>>> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
>>>>> IllegalArgumentException: factory thrown when creating
>>>>> LdapNetworkConnection inside OSGi
>>>>> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
>>>>> Reconsider interfaces and base classes for Registries
>>>>> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
>>>>> JUnit TemporaryFolder Rule
>>>>> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
>>>>> DateUtils.toGeneralizedTime does not work with some Locales
>>>>> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
>>>>> GeneralizedTime(String) fails for fraction close to one
>>>>> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
>>>>> Error in parsing LDIF file
>>>>> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
>>>>> Compiling warnings while api-all is in dependencies
>>>>> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
>>>>> AVA class is not handling correctly the values wrt the SchemaManager
>>>>> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
>>>>> Value<?> don't have a apply(AttributeType) method
>>>>> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
>>>>> escaped space at the end of a RDN will not be kept due to a bug in the
>>>>> ComplexDNParser
>>>>>
>>>>>
>>>>> Task :
>>>>> ------
>>>>>
>>>>> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
>>>>> violations of coding standards and enable checkstyle check
>>>>>
>>>>>
>>>>> New Feature :
>>>>> -------------
>>>>>
>>>>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
>>>>> a way to Anonymize a LDIF file
>>>>>
>>>>>
>>>>> Question :
>>>>> ----------
>>>>>
>>>>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
>>>>> to get attributes list according to objectClass
>>>>>
>>>>>
>>>>> The revision :
>>>>>
>>>>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
>>>>> http://svn.apache.org/r1676503>
>>>>>
>>>>> The SVN tag:
>>>>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
>>>>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>>>>>
>>>>> The source and binary distribution packages:
>>>>> http://people.apache.org/~elecharny/
>>>>> <http://people.apache.org/%7Eelecharny/>
>>>>>
>>>>> The staging repository:
>>>>>
>>>>> https://repository.apache.org/content/repositories/orgapachedirectory-1044
>>>>> <
>>>>> https://repository.apache.org/content/repositories/orgapachedirectory-1031
>>>>>
>>>>> Please cast your votes:
>>>>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
>>>>> [ ] 0 abstain
>>>>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>>>>>
>>>>>
>>>>> Emmanuel
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Cordialement,
>>>>> Emmanuel Lécharny
>>>>> www.iktek.com <http://www.iktek.com>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Cordialement,
>>>> Emmanuel Lécharny
>>>> www.iktek.com
>>>>
>>> I pulled the tag and attempted to "mvn clean install", but i get this
>>> exception in the integ-osgi module:
>>>
>>> Running org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
>>>
>>> Exception in thread "main" java.rmi.ConnectException: Connection
>>> refused to host: 92.242.140.21; nested exception is:
>>> java.net.ConnectException: Connection refused
>>> at
>>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>>> at
>>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>>> at
>>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>>> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
>>> at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
>>> at
>>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
>>> at
>>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.<init>(RemoteFrameworkImpl.java:77)
>>> at
>>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
>>> Caused by: java.net.ConnectException: Connection refused
>>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>>> at
>>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>>> at
>>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>>> at
>>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>>> at java.net.Socket.connect(Socket.java:579)
>>> at java.net.Socket.connect(Socket.java:528)
>>> at java.net.Socket.<init>(Socket.java:425)
>>> at java.net.Socket.<init>(Socket.java:208)
>>> at
>>> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
>>> at
>>> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
>>> at
>>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
>>> ... 7 more
>>>
>>> This is a new build VM (CentOS 7) that i created just for builds because
>>> they never work on windows. Could it be SELinux? Or maybe firewall? Is
>>> there a reason its using external IP instead of loopback IP?
>>>
>> hmmmm, it didn't happen on my machine (mac OS X)
>>
>>
>>
>> --
>> Kiran Ayyagari
>> http://keydap.com
>>
> Ok, so I tried again, still no dice. I am a little confused as to why this
> integration test would be attempting to communicate with:
>
> [ltheisen@ltbuild integ-osgi]$ nslookup 92.242.140.21
> Server: 192.168.1.1
> Address: 192.168.1.1#53
>
> Non-authoritative answer:
> 21.140.242.92.in-addr.arpa name = unallocated.barefruit.co.uk.
>
> A little research shows that barefruit is a Non Existent Domain provider
> for Verizon FIOS (my internet provider), so basically it appears that
> something in these unit tests must be hitting DNS for something that my DNS
> providers are unable to find.
This address is a site that injects some advertizement when you get an
HTTP or DNS error... Fuckers...
So I guess some adress used in the test does not resolve correctly and
you then get this error message.
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Lucas Theisen <lu...@pastdev.com>.
On Wed, Oct 14, 2015 at 10:59 PM, Kiran Ayyagari <ka...@apache.org>
wrote:
>
>
> On Thu, Oct 15, 2015 at 4:36 AM, Lucas Theisen <lu...@pastdev.com>
> wrote:
>
>> On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny <el...@apache.org>
>> wrote:
>>
>>> Also note that the following issues have been fixed (some of them a long
>>> time ago) :
>>>
>>> DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
>>> <https://issues.apache.org/jira/browse/DIRAPI-185>
>>> DIRAPI-171 - Entry.toString() shoud not add single quotes around binary
>>> values (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-171>
>>> DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
>>> <https://issues.apache.org/jira/browse/DIRAPI-146>
>>> DIRAPI-141 - pwdPolicySubentry AttributeType should be
>>> directoryOperation (1.0.0-M21)
>>> <https://issues.apache.org/jira/browse/DIRAPI-141>
>>>
>>> DIRAPI-131 - Make the StartTLS an extended request/response
>>> <https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
>>>
>>> DIRAPI-114 - Reconsider interfaces and base classes for Registries
>>> <https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
>>>
>>> DIRAPI-113 - Distribution module should generate GPG/PGP signatures and
>>> MD5/SHA checksums (1.0.0-M21)
>>> <https://issues.apache.org/jira/browse/DIRAPI-113>
>>>
>>> DIRAPI-101 - Allow the user to define the underlaying IO library to use
>>> <https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>>
>>> DIRAPI-85 - Provide a class allowing 'parent-first' sorting of entries
>>> from a search result (1.0.0-M21)
>>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>>
>>> DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for
>>> Schema Objects does not support escaped strings in the description
>>> <https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
>>>
>>>
>>> On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <el...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
>>>> 1.0.0-M32.
>>>>
>>>>
>>>> Another bug fix release, with some huge modifications in the way we
>>>> handle Values. The SchemaManager
>>>> is now propagated down to the Ava and Value classes, which causes many
>>>> tests to have been fixed.
>>>>
>>>> We also have added a LdifAnonymizer that can swallow a Ldif File and
>>>> replace the values with a
>>>> random text.
>>>>
>>>> We have also spent some time fixing many checkstyle violations.
>>>>
>>>> A few other issues have been fixed.
>>>>
>>>> Here is the list of fixed issues and added features :
>>>>
>>>>
>>>> Bugs :
>>>> ------
>>>>
>>>> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
>>>> IllegalArgumentException: factory thrown when creating
>>>> LdapNetworkConnection inside OSGi
>>>> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
>>>> Reconsider interfaces and base classes for Registries
>>>> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
>>>> JUnit TemporaryFolder Rule
>>>> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
>>>> DateUtils.toGeneralizedTime does not work with some Locales
>>>> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
>>>> GeneralizedTime(String) fails for fraction close to one
>>>> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
>>>> Error in parsing LDIF file
>>>> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
>>>> Compiling warnings while api-all is in dependencies
>>>> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
>>>> AVA class is not handling correctly the values wrt the SchemaManager
>>>> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
>>>> Value<?> don't have a apply(AttributeType) method
>>>> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
>>>> escaped space at the end of a RDN will not be kept due to a bug in the
>>>> ComplexDNParser
>>>>
>>>>
>>>> Task :
>>>> ------
>>>>
>>>> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
>>>> violations of coding standards and enable checkstyle check
>>>>
>>>>
>>>> New Feature :
>>>> -------------
>>>>
>>>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
>>>> a way to Anonymize a LDIF file
>>>>
>>>>
>>>> Question :
>>>> ----------
>>>>
>>>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
>>>> to get attributes list according to objectClass
>>>>
>>>>
>>>> The revision :
>>>>
>>>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
>>>> http://svn.apache.org/r1676503>
>>>>
>>>> The SVN tag:
>>>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
>>>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>>>>
>>>> The source and binary distribution packages:
>>>> http://people.apache.org/~elecharny/
>>>> <http://people.apache.org/%7Eelecharny/>
>>>>
>>>> The staging repository:
>>>>
>>>> https://repository.apache.org/content/repositories/orgapachedirectory-1044
>>>> <
>>>> https://repository.apache.org/content/repositories/orgapachedirectory-1031
>>>> >
>>>>
>>>>
>>>> Please cast your votes:
>>>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
>>>> [ ] 0 abstain
>>>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>>>>
>>>>
>>>> Emmanuel
>>>>
>>>> --
>>>> Regards,
>>>> Cordialement,
>>>> Emmanuel Lécharny
>>>> www.iktek.com <http://www.iktek.com>
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>
>> I pulled the tag and attempted to "mvn clean install", but i get this
>> exception in the integ-osgi module:
>>
>> Running org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
>>
>> Exception in thread "main" java.rmi.ConnectException: Connection
>> refused to host: 92.242.140.21; nested exception is:
>> java.net.ConnectException: Connection refused
>> at
>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
>> at
>> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
>> at
>> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
>> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
>> at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
>> at
>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
>> at
>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.<init>(RemoteFrameworkImpl.java:77)
>> at
>> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
>> Caused by: java.net.ConnectException: Connection refused
>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>> at
>> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
>> at
>> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
>> at
>> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>> at java.net.Socket.connect(Socket.java:579)
>> at java.net.Socket.connect(Socket.java:528)
>> at java.net.Socket.<init>(Socket.java:425)
>> at java.net.Socket.<init>(Socket.java:208)
>> at
>> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
>> at
>> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
>> at
>> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
>> ... 7 more
>>
>> This is a new build VM (CentOS 7) that i created just for builds because
>> they never work on windows. Could it be SELinux? Or maybe firewall? Is
>> there a reason its using external IP instead of loopback IP?
>>
> hmmmm, it didn't happen on my machine (mac OS X)
>
>
>
> --
> Kiran Ayyagari
> http://keydap.com
>
Ok, so I tried again, still no dice. I am a little confused as to why this
integration test would be attempting to communicate with:
[ltheisen@ltbuild integ-osgi]$ nslookup 92.242.140.21
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
21.140.242.92.in-addr.arpa name = unallocated.barefruit.co.uk.
A little research shows that barefruit is a Non Existent Domain provider
for Verizon FIOS (my internet provider), so basically it appears that
something in these unit tests must be hitting DNS for something that my DNS
providers are unable to find. However, I am unable to find anything in the
unit test referring to any network communications (though the stack trace
shows RMI stuff). What RMI stuff is happening? What IP/hostname would it
be attempting to communicate with?
Anyway, here is a more complete stack trace in case anything jumps out at
you OSGI fellas...
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Running org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 128.695 sec
<<< FAILURE! - in
org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest Time elapsed:
128.694 sec <<< ERROR!
org.ops4j.pax.exam.TestContainerException: cannot find remote framework in
RMI registry
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.findRemoteFramework(ForkedFrameworkFactory.java:235)
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.fork(ForkedFrameworkFactory.java:124)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:162)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:447)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.rmi.ConnectException: Connection refused to host:
92.242.140.21; nested exception is:
java.net.ConnectException: Connection timed out
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.findRemoteFramework(ForkedFrameworkFactory.java:224)
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.fork(ForkedFrameworkFactory.java:124)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:162)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:447)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.<init>(Socket.java:425)
at java.net.Socket.<init>(Socket.java:208)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.findRemoteFramework(ForkedFrameworkFactory.java:224)
at
org.ops4j.pax.exam.forked.ForkedFrameworkFactory.fork(ForkedFrameworkFactory.java:124)
at
org.ops4j.pax.exam.forked.ForkedTestContainer.start(ForkedTestContainer.java:162)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.setUp(EagerSingleStagedReactor.java:86)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.beforeClass(EagerSingleStagedReactor.java:136)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.beforeClass(ReactorManager.java:447)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:97)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest Time elapsed:
128.695 sec <<< ERROR!
java.lang.NullPointerException: null
at
org.ops4j.pax.exam.forked.ForkedTestContainer.stop(ForkedTestContainer.java:176)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.tearDown(EagerSingleStagedReactor.java:118)
at
org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.afterClass(EagerSingleStagedReactor.java:132)
at
org.ops4j.pax.exam.spi.reactors.ReactorManager.afterClass(ReactorManager.java:431)
at
org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:107)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Oct 15, 2015 at 4:36 AM, Lucas Theisen <lu...@pastdev.com>
wrote:
> On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny <el...@apache.org>
> wrote:
>
>> Also note that the following issues have been fixed (some of them a long
>> time ago) :
>>
>> DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
>> <https://issues.apache.org/jira/browse/DIRAPI-185>
>> DIRAPI-171 - Entry.toString() shoud not add single quotes around binary
>> values (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-171>
>> DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
>> <https://issues.apache.org/jira/browse/DIRAPI-146>
>> DIRAPI-141 - pwdPolicySubentry AttributeType should be directoryOperation
>> (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-141>
>>
>> DIRAPI-131 - Make the StartTLS an extended request/response
>> <https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
>>
>> DIRAPI-114 - Reconsider interfaces and base classes for Registries
>> <https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
>>
>> DIRAPI-113 - Distribution module should generate GPG/PGP signatures and
>> MD5/SHA checksums (1.0.0-M21)
>> <https://issues.apache.org/jira/browse/DIRAPI-113>
>>
>> DIRAPI-101 - Allow the user to define the underlaying IO library to use
>> <https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>
>> DIRAPI-85 - Provide a class allowing 'parent-first' sorting of entries
>> from a search result (1.0.0-M21)
>> <https://issues.apache.org/jira/browse/DIRAPI-85>
>>
>> DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for Schema
>> Objects does not support escaped strings in the description
>> <https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
>>
>>
>> On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <el...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
>>> 1.0.0-M32.
>>>
>>>
>>> Another bug fix release, with some huge modifications in the way we
>>> handle Values. The SchemaManager
>>> is now propagated down to the Ava and Value classes, which causes many
>>> tests to have been fixed.
>>>
>>> We also have added a LdifAnonymizer that can swallow a Ldif File and
>>> replace the values with a
>>> random text.
>>>
>>> We have also spent some time fixing many checkstyle violations.
>>>
>>> A few other issues have been fixed.
>>>
>>> Here is the list of fixed issues and added features :
>>>
>>>
>>> Bugs :
>>> ------
>>>
>>> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
>>> IllegalArgumentException: factory thrown when creating
>>> LdapNetworkConnection inside OSGi
>>> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
>>> Reconsider interfaces and base classes for Registries
>>> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
>>> JUnit TemporaryFolder Rule
>>> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
>>> DateUtils.toGeneralizedTime does not work with some Locales
>>> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
>>> GeneralizedTime(String) fails for fraction close to one
>>> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
>>> Error in parsing LDIF file
>>> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
>>> Compiling warnings while api-all is in dependencies
>>> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
>>> AVA class is not handling correctly the values wrt the SchemaManager
>>> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
>>> Value<?> don't have a apply(AttributeType) method
>>> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
>>> escaped space at the end of a RDN will not be kept due to a bug in the
>>> ComplexDNParser
>>>
>>>
>>> Task :
>>> ------
>>>
>>> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
>>> violations of coding standards and enable checkstyle check
>>>
>>>
>>> New Feature :
>>> -------------
>>>
>>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
>>> a way to Anonymize a LDIF file
>>>
>>>
>>> Question :
>>> ----------
>>>
>>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
>>> to get attributes list according to objectClass
>>>
>>>
>>> The revision :
>>>
>>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
>>> http://svn.apache.org/r1676503>
>>>
>>> The SVN tag:
>>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
>>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>>>
>>> The source and binary distribution packages:
>>> http://people.apache.org/~elecharny/
>>> <http://people.apache.org/%7Eelecharny/>
>>>
>>> The staging repository:
>>>
>>> https://repository.apache.org/content/repositories/orgapachedirectory-1044
>>> <
>>> https://repository.apache.org/content/repositories/orgapachedirectory-1031
>>> >
>>>
>>>
>>> Please cast your votes:
>>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
>>> [ ] 0 abstain
>>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>>>
>>>
>>> Emmanuel
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com <http://www.iktek.com>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>
> I pulled the tag and attempted to "mvn clean install", but i get this
> exception in the integ-osgi module:
>
> Running org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
>
> Exception in thread "main" java.rmi.ConnectException: Connection
> refused to host: 92.242.140.21; nested exception is:
> java.net.ConnectException: Connection refused
> at
> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
> at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.<init>(RemoteFrameworkImpl.java:77)
> at
> org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:579)
> at java.net.Socket.connect(Socket.java:528)
> at java.net.Socket.<init>(Socket.java:425)
> at java.net.Socket.<init>(Socket.java:208)
> at
> sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
> at
> sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
> at
> sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
> ... 7 more
>
> This is a new build VM (CentOS 7) that i created just for builds because
> they never work on windows. Could it be SELinux? Or maybe firewall? Is
> there a reason its using external IP instead of loopback IP?
>
hmmmm, it didn't happen on my machine (mac OS X)
--
Kiran Ayyagari
http://keydap.com
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Lucas Theisen <lu...@pastdev.com>.
On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny <el...@apache.org>
wrote:
> Also note that the following issues have been fixed (some of them a long
> time ago) :
>
> DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
> <https://issues.apache.org/jira/browse/DIRAPI-185>
> DIRAPI-171 - Entry.toString() shoud not add single quotes around binary
> values (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-171>
> DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
> <https://issues.apache.org/jira/browse/DIRAPI-146>
> DIRAPI-141 - pwdPolicySubentry AttributeType should be directoryOperation
> (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-141>
>
> DIRAPI-131 - Make the StartTLS an extended request/response
> <https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
>
> DIRAPI-114 - Reconsider interfaces and base classes for Registries
> <https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
>
> DIRAPI-113 - Distribution module should generate GPG/PGP signatures and
> MD5/SHA checksums (1.0.0-M21)
> <https://issues.apache.org/jira/browse/DIRAPI-113>
>
> DIRAPI-101 - Allow the user to define the underlaying IO library to use
> <https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
> <https://issues.apache.org/jira/browse/DIRAPI-85>
>
> DIRAPI-85 - Provide a class allowing 'parent-first' sorting of entries
> from a search result (1.0.0-M21)
> <https://issues.apache.org/jira/browse/DIRAPI-85>
>
> DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for Schema
> Objects does not support escaped strings in the description
> <https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
>
>
> On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
>> Hi,
>>
>> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
>> 1.0.0-M32.
>>
>>
>> Another bug fix release, with some huge modifications in the way we
>> handle Values. The SchemaManager
>> is now propagated down to the Ava and Value classes, which causes many
>> tests to have been fixed.
>>
>> We also have added a LdifAnonymizer that can swallow a Ldif File and
>> replace the values with a
>> random text.
>>
>> We have also spent some time fixing many checkstyle violations.
>>
>> A few other issues have been fixed.
>>
>> Here is the list of fixed issues and added features :
>>
>>
>> Bugs :
>> ------
>>
>> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
>> IllegalArgumentException: factory thrown when creating
>> LdapNetworkConnection inside OSGi
>> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
>> Reconsider interfaces and base classes for Registries
>> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
>> JUnit TemporaryFolder Rule
>> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
>> DateUtils.toGeneralizedTime does not work with some Locales
>> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
>> GeneralizedTime(String) fails for fraction close to one
>> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
>> Error in parsing LDIF file
>> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
>> Compiling warnings while api-all is in dependencies
>> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
>> AVA class is not handling correctly the values wrt the SchemaManager
>> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
>> Value<?> don't have a apply(AttributeType) method
>> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
>> escaped space at the end of a RDN will not be kept due to a bug in the
>> ComplexDNParser
>>
>>
>> Task :
>> ------
>>
>> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
>> violations of coding standards and enable checkstyle check
>>
>>
>> New Feature :
>> -------------
>>
>> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
>> a way to Anonymize a LDIF file
>>
>>
>> Question :
>> ----------
>>
>> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
>> to get attributes list according to objectClass
>>
>>
>> The revision :
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1708634<
>> http://svn.apache.org/r1676503>
>>
>> The SVN tag:
>> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
>> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>>
>> The source and binary distribution packages:
>> http://people.apache.org/~elecharny/
>> <http://people.apache.org/%7Eelecharny/>
>>
>> The staging repository:
>> https://repository.apache.org/content/repositories/orgapachedirectory-1044
>> <
>> https://repository.apache.org/content/repositories/orgapachedirectory-1031
>> >
>>
>>
>> Please cast your votes:
>> [ ] +1 Release Shared/LDAP API 1.0.0-M32
>> [ ] 0 abstain
>> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>>
>>
>> Emmanuel
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com <http://www.iktek.com>
>>
>>
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
I pulled the tag and attempted to "mvn clean install", but i get this
exception in the integ-osgi module:
Running org.apache.directory.api.osgi.ApiLdapSchemaConverterOsgiTest
Exception in thread "main" java.rmi.ConnectException: Connection
refused to host: 92.242.140.21; nested exception is:
java.net.ConnectException: Connection refused
at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at
sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:341)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.export(RemoteFrameworkImpl.java:91)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.<init>(RemoteFrameworkImpl.java:77)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.main(RemoteFrameworkImpl.java:436)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at java.net.Socket.<init>(Socket.java:425)
at java.net.Socket.<init>(Socket.java:208)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:147)
at
sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
... 7 more
This is a new build VM (CentOS 7) that i created just for builds because
they never work on windows. Could it be SELinux? Or maybe firewall? Is
there a reason its using external IP instead of loopback IP?
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Emmanuel Lecharny <el...@apache.org>.
Also note that the following issues have been fixed (some of them a long
time ago) :
DIRAPI-185 - Support underscore in AttributeNames (1.0.0-M23)
<https://issues.apache.org/jira/browse/DIRAPI-185>
DIRAPI-171 - Entry.toString() shoud not add single quotes around binary
values (1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-171>
DIRAPI-146 - Add the ability to escape DN characters (1.0.0-M28)
<https://issues.apache.org/jira/browse/DIRAPI-146>
DIRAPI-141 - pwdPolicySubentry AttributeType should be directoryOperation
(1.0.0-M21) <https://issues.apache.org/jira/browse/DIRAPI-141>
DIRAPI-131 - Make the StartTLS an extended request/response
<https://issues.apache.org/jira/browse/DIRAPI-131> (1.0.0-M22)
DIRAPI-114 - Reconsider interfaces and base classes for Registries
<https://issues.apache.org/jira/browse/DIRAPI-114> (1.0.0-M32)
DIRAPI-113 - Distribution module should generate GPG/PGP signatures and
MD5/SHA checksums (1.0.0-M21)
<https://issues.apache.org/jira/browse/DIRAPI-113>
DIRAPI-101 - Allow the user to define the underlaying IO library to use
<https://issues.apache.org/jira/browse/DIRAPI-101> (1.0.0-M30)
<https://issues.apache.org/jira/browse/DIRAPI-85>
DIRAPI-85 - Provide a class allowing 'parent-first' sorting of entries from
a search result (1.0.0-M21)
<https://issues.apache.org/jira/browse/DIRAPI-85>
DIRAPI-67 - Parsers and generators of OpenLDAP code (RFC 4512) for Schema
Objects does not support escaped strings in the description
<https://issues.apache.org/jira/browse/DIRAPI-67> (1.0.0-M23)
On Wed, Oct 14, 2015 at 7:05 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Hi,
>
> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M32.
>
>
> Another bug fix release, with some huge modifications in the way we
> handle Values. The SchemaManager
> is now propagated down to the Ava and Value classes, which causes many
> tests to have been fixed.
>
> We also have added a LdifAnonymizer that can swallow a Ldif File and
> replace the values with a
> random text.
>
> We have also spent some time fixing many checkstyle violations.
>
> A few other issues have been fixed.
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> ------
>
> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
> IllegalArgumentException: factory thrown when creating
> LdapNetworkConnection inside OSGi
> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
> Reconsider interfaces and base classes for Registries
> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
> JUnit TemporaryFolder Rule
> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
> DateUtils.toGeneralizedTime does not work with some Locales
> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
> GeneralizedTime(String) fails for fraction close to one
> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
> Error in parsing LDIF file
> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
> Compiling warnings while api-all is in dependencies
> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
> AVA class is not handling correctly the values wrt the SchemaManager
> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
> Value<?> don't have a apply(AttributeType) method
> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
> escaped space at the end of a RDN will not be kept due to a bug in the
> ComplexDNParser
>
>
> Task :
> ------
>
> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
> violations of coding standards and enable checkstyle check
>
>
> New Feature :
> -------------
>
> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
> a way to Anonymize a LDIF file
>
>
> Question :
> ----------
>
> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
> to get attributes list according to objectClass
>
>
> The revision :
>
> http://svn.apache.org/viewvc?view=revision&revision=1708634<
> http://svn.apache.org/r1676503>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>
> The source and binary distribution packages:
> http://people.apache.org/~elecharny/
> <http://people.apache.org/%7Eelecharny/>
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1044
> <
> https://repository.apache.org/content/repositories/orgapachedirectory-1031
> >
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-M32
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Shawn McKinney <sm...@apache.org>.
+1, also built the tag using (oracle) java7 on Ubuntu 14.04. Ran this version with fortress core’s unit tests, along with apacheds-2.0.0-M20. All tests pass.
> On Oct 15, 2015, at 7:06 AM, Kiran Ayyagari <ka...@apache.org> wrote:
>
> +1, built the tag using java7 on OS X 10.10.3
>
> On Thu, Oct 15, 2015 at 1:05 AM, Emmanuel Lécharny <el...@gmail.com> wrote:
> Hi,
>
> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M32.
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Kiran Ayyagari <ka...@apache.org>.
+1, built the tag using java7 on OS X 10.10.3
On Thu, Oct 15, 2015 at 1:05 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Hi,
>
> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M32.
>
>
> Another bug fix release, with some huge modifications in the way we
> handle Values. The SchemaManager
> is now propagated down to the Ava and Value classes, which causes many
> tests to have been fixed.
>
> We also have added a LdifAnonymizer that can swallow a Ldif File and
> replace the values with a
> random text.
>
> We have also spent some time fixing many checkstyle violations.
>
> A few other issues have been fixed.
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> ------
>
> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
> IllegalArgumentException: factory thrown when creating
> LdapNetworkConnection inside OSGi
> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
> Reconsider interfaces and base classes for Registries
> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
> JUnit TemporaryFolder Rule
> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
> DateUtils.toGeneralizedTime does not work with some Locales
> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
> GeneralizedTime(String) fails for fraction close to one
> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
> Error in parsing LDIF file
> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
> Compiling warnings while api-all is in dependencies
> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
> AVA class is not handling correctly the values wrt the SchemaManager
> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
> Value<?> don't have a apply(AttributeType) method
> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
> escaped space at the end of a RDN will not be kept due to a bug in the
> ComplexDNParser
>
>
> Task :
> ------
>
> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
> violations of coding standards and enable checkstyle check
>
>
> New Feature :
> -------------
>
> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
> a way to Anonymize a LDIF file
>
>
> Question :
> ----------
>
> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
> to get attributes list according to objectClass
>
>
> The revision :
>
> http://svn.apache.org/viewvc?view=revision&revision=1708634<
> http://svn.apache.org/r1676503>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>
> The source and binary distribution packages:
> http://people.apache.org/~elecharny/
> <http://people.apache.org/%7Eelecharny/>
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1044
> <
> https://repository.apache.org/content/repositories/orgapachedirectory-1031
> >
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-M32
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
>
>
--
Kiran Ayyagari
http://keydap.com
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 20/10/15 19:10, Pierre Smits a écrit :
> Regarding managing user expectations with respect to API and DS working
> with AD is to register a JIRA issue for each of the not working controls.
> The advantages are that both users and community members would then now
> where the products stand.
>
> And if and when one gets fixed it'll turn up in the release notes.
I have found the best way to deal with that :
- I created a parent task : https://issues.apache.org/jira/browse/DIRAPI-259
- and I have created a first sub-task beneth it :
https://issues.apache.org/jira/browse/DIRAPI-258
All the other controls/extended operations will be sub-tasks associated
with the parent issue (the list of sub tasks is visible at teh bottom of
the parent task).
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Pierre Smits <pi...@gmail.com>.
Regarding managing user expectations with respect to API and DS working
with AD is to register a JIRA issue for each of the not working controls.
The advantages are that both users and community members would then now
where the products stand.
And if and when one gets fixed it'll turn up in the release notes.
Best regards,
Pierre Smits
*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/
On Mon, Oct 19, 2015 at 10:52 AM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 19/10/15 10:30, Radovan Semancik a écrit :
> > On 10/19/2015 02:23 AM, Emmanuel Lécharny wrote:
> >> I think we can wait for another release, that may come quite quickly
> >> (I have myself some additional fixes for the LdifAnonymizer).
> >
> > OK. No problem. Just let me know when the M32 release is done so I can
> > commit my code.
>
> I'll close the vote tonite, afte rmy day job ;-)
> >
> >> Regarding the missing controls/extOps, here is what I would suggest :
> >> we could spend some time implementing a batch of the missing AD
> >> elements, and cut a release as soon as it's done.
> >
> > Hmm, but there is a problem. It does not make much sense to implement
> > the controls "theoretically". They have to be tested with real AD
> > instances. We all know how AD "works", eh?
>
> Meh... So right. OTOH, there is nothing forbidden us to get the code
> added, with internal tests, for someone to test it against AD.
> >
> > So I would counter-propose to implement the controls gradually when
> > someone needs them and someone is able to test them. This is the case
> > for the "Deleted" control: I need it and I have a setup to test it
> > with real AD instance. Yes, this specific control is trivial. But
> > there are quite complex controls in the AD set ...
>
> I have yet checked teh syntax for all of them.
>
> What I would suggest here is to create either one JIRA for all the AD
> controls/extended, or one JIRA per control/extended. The second option
> might be a better solution, even if that mean 50 JIRA will be created
> (OTOH, closing them fast wikll improve our opened/closed ration in a
> nice way ;-)
> >
> >> For controls, it's not necessarily complex, it's just a bit time
> >> consuming (especially the tests).
> >
> > Well, yes, unit tests are a bit time consuming. But tests with real AD
> > are insanely time consuming as AD will not tell you what is the
> > problem. So, unless you already have a setup where you can test it
> > easily I see no point in implementing something that will not be tested.
> I don't have any AD close to me, so I have to trust you on that :-)
>
> >
> >> The only part I'm not sure of is which ones should we include and
> >> which ones should we ignore. I suspect we should go to the full
> >> extent and make the API as complete as possible...
> >
> > For me it is the "Deleted" control now. Maybe SD_FLAGS a bit later.
>
> Ok, let's go for the first one quickly then.
>
>
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 19/10/15 10:30, Radovan Semancik a écrit :
> On 10/19/2015 02:23 AM, Emmanuel Lécharny wrote:
>> I think we can wait for another release, that may come quite quickly
>> (I have myself some additional fixes for the LdifAnonymizer).
>
> OK. No problem. Just let me know when the M32 release is done so I can
> commit my code.
I'll close the vote tonite, afte rmy day job ;-)
>
>> Regarding the missing controls/extOps, here is what I would suggest :
>> we could spend some time implementing a batch of the missing AD
>> elements, and cut a release as soon as it's done.
>
> Hmm, but there is a problem. It does not make much sense to implement
> the controls "theoretically". They have to be tested with real AD
> instances. We all know how AD "works", eh?
Meh... So right. OTOH, there is nothing forbidden us to get the code
added, with internal tests, for someone to test it against AD.
>
> So I would counter-propose to implement the controls gradually when
> someone needs them and someone is able to test them. This is the case
> for the "Deleted" control: I need it and I have a setup to test it
> with real AD instance. Yes, this specific control is trivial. But
> there are quite complex controls in the AD set ...
I have yet checked teh syntax for all of them.
What I would suggest here is to create either one JIRA for all the AD
controls/extended, or one JIRA per control/extended. The second option
might be a better solution, even if that mean 50 JIRA will be created
(OTOH, closing them fast wikll improve our opened/closed ration in a
nice way ;-)
>
>> For controls, it's not necessarily complex, it's just a bit time
>> consuming (especially the tests).
>
> Well, yes, unit tests are a bit time consuming. But tests with real AD
> are insanely time consuming as AD will not tell you what is the
> problem. So, unless you already have a setup where you can test it
> easily I see no point in implementing something that will not be tested.
I don't have any AD close to me, so I have to trust you on that :-)
>
>> The only part I'm not sure of is which ones should we include and
>> which ones should we ignore. I suspect we should go to the full
>> extent and make the API as complete as possible...
>
> For me it is the "Deleted" control now. Maybe SD_FLAGS a bit later.
Ok, let's go for the first one quickly then.
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Radovan Semancik <ra...@evolveum.com>.
On 10/19/2015 02:23 AM, Emmanuel Lécharny wrote:
> I think we can wait for another release, that may come quite quickly
> (I have myself some additional fixes for the LdifAnonymizer).
OK. No problem. Just let me know when the M32 release is done so I can
commit my code.
> Regarding the missing controls/extOps, here is what I would suggest :
> we could spend some time implementing a batch of the missing AD
> elements, and cut a release as soon as it's done.
Hmm, but there is a problem. It does not make much sense to implement
the controls "theoretically". They have to be tested with real AD
instances. We all know how AD "works", eh?
So I would counter-propose to implement the controls gradually when
someone needs them and someone is able to test them. This is the case
for the "Deleted" control: I need it and I have a setup to test it with
real AD instance. Yes, this specific control is trivial. But there are
quite complex controls in the AD set ...
> For controls, it's not necessarily complex, it's just a bit time
> consuming (especially the tests).
Well, yes, unit tests are a bit time consuming. But tests with real AD
are insanely time consuming as AD will not tell you what is the problem.
So, unless you already have a setup where you can test it easily I see
no point in implementing something that will not be tested.
> The only part I'm not sure of is which ones should we include and
> which ones should we ignore. I suspect we should go to the full extent
> and make the API as complete as possible...
For me it is the "Deleted" control now. Maybe SD_FLAGS a bit later.
--
Radovan Semancik
Software Architect
evolveum.com
Result, was [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Emmanuel Lécharny <el...@gmail.com>.
I'm closing this vote, with a result of 6 +1 :
Kiran, Lucas, Radovan, Shawn, Stefan and me.
Some concerns have been raised (a bug in the Pax library, a problem with
Generalized Time, and the addition of some missing AD controls) and will
be addressed in the next release.
Many thanks !
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 18/10/15 19:18, Radovan Semancik a écrit :
> Hi,
>
> There is one more thing. I have just realized that API has Active
> Directory DirSync control, but we do not have "Deleted" control
> (1.2.840.113556.1.4.417). The AD sync is not very useful without this
> control.
There are many controls (and extended operations) that AD supports and
we don't :
Controls :
----------
LDAP_PAGED_RESULT_OID_STRING 1.2.840.113556.1.4.319 Supported
LDAP_SERVER_SHOW_DELETED_OID 1.2.840.113556.1.4.417 Not
supported
LDAP_SERVER_SORT_OID 1.2.840.113556.1.4.473 Supported
LDAP_SERVER_RESP_SORT_OID 1.2.840.113556.1.4.474 Supported
LDAP_SERVER_CROSSDOM_MOVE_TARGET_OID 1.2.840.113556.1.4.521 Not
supported
LDAP_SERVER_NOTIFICATION_OID 1.2.840.113556.1.4.528 Not
supported
LDAP_SERVER_EXTENDED_DN_OID 1.2.840.113556.1.4.529 Not
supported
LDAP_SERVER_LAZY_COMMIT_OID 1.2.840.113556.1.4.619 Not
supported
LDAP_SERVER_SD_FLAGS_OID 1.2.840.113556.1.4.801 Not
supported
LDAP_SERVER_RANGE_OPTION_OID 1.2.840.113556.1.4.802 Not
supported
LDAP_SERVER_TREE_DELETE_OID 1.2.840.113556.1.4.805 supported
LDAP_SERVER_DIRSYNC_OID 1.2.840.113556.1.4.841 Supported
LDAP_SERVER_GET_STATS_OID 1.2.840.113556.1.4.970 Not
supported
LDAP_SERVER_VERIFY_NAME_OID 1.2.840.113556.1.4.1338 Not
supported
LDAP_SERVER_DOMAIN_SCOPE_OID 1.2.840.113556.1.4.1339 Not
supported
LDAP_SERVER_SEARCH_OPTIONS_OID 1.2.840.113556.1.4.1340 Not
supported
LDAP_SERVER_RODC_DCPROMO_OID 1.2.840.113556.1.4.1341 Not
supported
LDAP_SERVER_PERMISSIVE_MODIFY_OID 1.2.840.113556.1.4.1413 Not
supported
LDAP_SERVER_ASQ_OID 1.2.840.113556.1.4.1504 Not
supported
LDAP_SERVER_QUOTA_CONTROL_OID 1.2.840.113556.1.4.1852 Not
supported
LDAP_SERVER_SHUTDOWN_NOTIFY_OID 1.2.840.113556.1.4.1907 Not
supported
LDAP_SERVER_RANGE_RETRIEVAL_NOERR_OID 1.2.840.113556.1.4.1948 Not
supported
LDAP_SERVER_FORCE_UPDATE_OID 1.2.840.113556.1.4.1974 Not
supported
LDAP_SERVER_DN_INPUT_OID 1.2.840.113556.1.4.2026 Not
supported
LDAP_SERVER_SHOW_RECYCLED_OID 1.2.840.113556.1.4.2064 Not
supported
LDAP_SERVER_SHOW_DEACTIVATED_LINK_OID 1.2.840.113556.1.4.2065 Not
supported
LDAP_SERVER_POLICY_HINTS_DEPRECATED_OID 1.2.840.113556.1.4.2066 Not
supported
LDAP_SERVER_DIRSYNC_EX_OID 1.2.840.113556.1.4.2090 Not
supported
LDAP_SERVER_TREE_DELETE_EX_OID 1.2.840.113556.1.4.2204 Not
supported
LDAP_SERVER_UPDATE_STATS_OID 1.2.840.113556.1.4.2205 Not
supported
LDAP_SERVER_SEARCH_HINTS_OID 1.2.840.113556.1.4.2206 Not
supported
LDAP_SERVER_EXPECTED_ENTRY_COUNT_OID 1.2.840.113556.1.4.2211 Not
supported
LDAP_SERVER_POLICY_HINTS_OID 1.2.840.113556.1.4.2239 Not
supported
LDAP_SERVER_SET_OWNER_OID 1.2.840.113556.1.4.2255 Not
supported
LDAP_SERVER_BYPASS_QUOTA_OID 1.2.840.113556.1.4.2256 Not
supported
LDAP_SERVER_LINK_TTL_OID 1.2.840.113556.1.4.2309 Not
supported
LDAP_CONTROL_VLVREQUEST 2.16.840.1.113730.3.4.9 Supported
LDAP_CONTROL_VLVRESPONSE 2.16.840.1.113730.3.4.10 Supported
Extended operations :
---------------------
LDAP_SERVER_FAST_BIND_OID 1.2.840.113556.1.4.1781 Not supported
LDAP_SERVER_BATCH_REQUEST_OID 1.2.840.113556.1.4.2212 Not supported
LDAP_TTL_REFRESH_OID 1.3.6.1.4.1.1466.101.119.1 Not supported
LDAP_SERVER_START_TLS_OID 1.3.6.1.4.1.1466.20037 Supported
LDAP_SERVER_WHO_AM_I_OID 1.3.6.1.4.1.4203.1.11.3 Supported
As you can see, we do support 7 out of 38 controls, and 2 out of 5
extended operations M$ AD supports.
> The implementation should be very easy and I can do that during
> Monday. Do you think it is OK to do that now (before 1.0.0-M32
> release)? Or should I wait after the release?
I think we can wait for another release, that may come quite quickly (I
have myself some additional fixes for the LdifAnonymizer). The rationnal
is that this release is quite critical due to the changes made in the
way we handle the schema, and I'd like to have it out as is.
Regarding the missing controls/extOps, here is what I would suggest : we
could spend some time implementing a batch of the missing AD elements,
and cut a release as soon as it's done. For controls, it's not
necessarily complex, it's just a bit time consuming (especially the
tests). The only part I'm not sure of is which ones should we include
and which ones should we ignore. I suspect we should go to the full
extent and make the API as complete as possible...
Thoughts ?
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Radovan Semancik <ra...@evolveum.com>.
Hi,
There is one more thing. I have just realized that API has Active
Directory DirSync control, but we do not have "Deleted" control
(1.2.840.113556.1.4.417). The AD sync is not very useful without this
control. The implementation should be very easy and I can do that during
Monday. Do you think it is OK to do that now (before 1.0.0-M32 release)?
Or should I wait after the release?
--
Radovan Semancik
Software Architect
evolveum.com
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 10/16/2015 07:08 AM, Felix Knecht wrote:
> Building by mvn clean install I get the following error using tag
> 1.0.0-M32 (using JDK 1.7 or 1.8):
>
> Running org.apache.directory.api.util.GeneralizedTimeTest
> Tests run: 48, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.114
> sec <<< FAILURE! - in org.apache.directory.api.util.GeneralizedTimeTest
> testRoundTrip(org.apache.directory.api.util.GeneralizedTimeTest) Time
> elapsed: 0.013 sec <<< FAILURE!
> java.lang.AssertionError:
> expected:<java.util.GregorianCalendar[time=123456789000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=1973,MONTH=10,WEEK_OF_YEAR=48,WEEK_OF_MONTH=5,DAY_OF_MONTH=29,DAY_OF_YEAR=333,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=9,HOUR_OF_DAY=21,MINUTE=33,SECOND=9,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]>
> but
> was:<java.util.GregorianCalendar[time=123456789000,areFieldsSet=true,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1973,MONTH=10,WEEK_OF_YEAR=48,WEEK_OF_MONTH=5,DAY_OF_MONTH=29,DAY_OF_YEAR=333,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=9,HOUR_OF_DAY=21,MINUTE=33,SECOND=9,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]>
>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at
> org.apache.directory.api.util.GeneralizedTimeTest.testRoundTrip(GeneralizedTimeTest.java:1098)
This has to do with change of DIRAPI-219, in production code the evil
Calendar.getInstance() was removed, but in the test we still use it.
This means the production code is ok, but the test code depends on the
default locale/lang setting. I created DIRAPI-257 to fix that.
Kind Regards,
Stefan
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Felix Knecht <fe...@apache.org>.
Building by mvn clean install I get the following error using tag
1.0.0-M32 (using JDK 1.7 or 1.8):
Running org.apache.directory.api.util.GeneralizedTimeTest
Tests run: 48, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.114
sec <<< FAILURE! - in org.apache.directory.api.util.GeneralizedTimeTest
testRoundTrip(org.apache.directory.api.util.GeneralizedTimeTest) Time
elapsed: 0.013 sec <<< FAILURE!
java.lang.AssertionError:
expected:<java.util.GregorianCalendar[time=123456789000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=1973,MONTH=10,WEEK_OF_YEAR=48,WEEK_OF_MONTH=5,DAY_OF_MONTH=29,DAY_OF_YEAR=333,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=9,HOUR_OF_DAY=21,MINUTE=33,SECOND=9,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]>
but
was:<java.util.GregorianCalendar[time=123456789000,areFieldsSet=true,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1973,MONTH=10,WEEK_OF_YEAR=48,WEEK_OF_MONTH=5,DAY_OF_MONTH=29,DAY_OF_YEAR=333,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=9,HOUR_OF_DAY=21,MINUTE=33,SECOND=9,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.directory.api.util.GeneralizedTimeTest.testRoundTrip(GeneralizedTimeTest.java:1098)
Running org.apache.directory.api.util.OsgiUtilsTest
I suppose, that I'm using a different setting concerning 'Which is the
first week in a year'.
I'm sorry to say that I'm not sure to find the time to do some more
analysis on this today.
Regards
Felix
Am 14.10.2015 um 19:05 schrieb Emmanuel Lécharny:
> Hi,
>
> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M32.
>
>
> Another bug fix release, with some huge modifications in the way we
> handle Values. The SchemaManager
> is now propagated down to the Ava and Value classes, which causes many
> tests to have been fixed.
>
> We also have added a LdifAnonymizer that can swallow a Ldif File and
> replace the values with a
> random text.
>
> We have also spent some time fixing many checkstyle violations.
>
> A few other issues have been fixed.
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> ------
>
> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
> IllegalArgumentException: factory thrown when creating
> LdapNetworkConnection inside OSGi
> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
> Reconsider interfaces and base classes for Registries
> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
> JUnit TemporaryFolder Rule
> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
> DateUtils.toGeneralizedTime does not work with some Locales
> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
> GeneralizedTime(String) fails for fraction close to one
> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
> Error in parsing LDIF file
> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
> Compiling warnings while api-all is in dependencies
> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
> AVA class is not handling correctly the values wrt the SchemaManager
> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
> Value<?> don't have a apply(AttributeType) method
> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
> escaped space at the end of a RDN will not be kept due to a bug in the
> ComplexDNParser
>
>
> Task :
> ------
>
> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
> violations of coding standards and enable checkstyle check
>
>
> New Feature :
> -------------
>
> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
> a way to Anonymize a LDIF file
>
>
> Question :
> ----------
>
> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
> to get attributes list according to objectClass
>
>
> The revision :
>
> http://svn.apache.org/viewvc?view=revision&revision=1708634<http://svn.apache.org/r1676503>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>
> The source and binary distribution packages:
> http://people.apache.org/~elecharny/
> <http://people.apache.org/%7Eelecharny/>
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1044
> <https://repository.apache.org/content/repositories/orgapachedirectory-1031>
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-M32
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
>
Re: [VOTE] Apache LDAP API 1.0.0-M32 release
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
+1
Verified checksums and signatures
Built source package with Java 1.8.0_60 on Linux
Kind Regards,
Stefan
On 10/14/2015 07:05 PM, Emmanuel Lécharny wrote:
> Hi,
>
> This is a vote for the 32th milestone of the 1.0.0 LDAP API/Shared,
> 1.0.0-M32.
>
>
> Another bug fix release, with some huge modifications in the way we
> handle Values. The SchemaManager
> is now propagated down to the Ava and Value classes, which causes many
> tests to have been fixed.
>
> We also have added a LdifAnonymizer that can swallow a Ldif File and
> replace the values with a
> random text.
>
> We have also spent some time fixing many checkstyle violations.
>
> A few other issues have been fixed.
>
> Here is the list of fixed issues and added features :
>
>
> Bugs :
> ------
>
> DIRAPI-90 <https://issues.apache.org/jira/browse/DIRAPI-90> -
> IllegalArgumentException: factory thrown when creating
> LdapNetworkConnection inside OSGi
> DIRAPI-114 <https://issues.apache.org/jira/browse/DIRAPI-114> -
> Reconsider interfaces and base classes for Registries
> DIRAPI-118 <https://issues.apache.org/jira/browse/DIRAPI-118> - Use
> JUnit TemporaryFolder Rule
> DIRAPI-219 <https://issues.apache.org/jira/browse/DIRAPI-219> -
> DateUtils.toGeneralizedTime does not work with some Locales
> DIRAPI-241 <https://issues.apache.org/jira/browse/DIRAPI-241> - new
> GeneralizedTime(String) fails for fraction close to one
> DIRAPI-246 <https://issues.apache.org/jira/browse/DIRAPI-246> -
> Error in parsing LDIF file
> DIRAPI-252 <https://issues.apache.org/jira/browse/DIRAPI-252> -
> Compiling warnings while api-all is in dependencies
> DIRAPI-253 <https://issues.apache.org/jira/browse/DIRAPI-253> - The
> AVA class is not handling correctly the values wrt the SchemaManager
> DIRAPI-254 <https://issues.apache.org/jira/browse/DIRAPI-254> -
> Value<?> don't have a apply(AttributeType) method
> DIRAPI-255 <https://issues.apache.org/jira/browse/DIRAPI-255> - An
> escaped space at the end of a RDN will not be kept due to a bug in the
> ComplexDNParser
>
>
> Task :
> ------
>
> DIRAPI-251 <https://issues.apache.org/jira/browse/DIRAPI-251> - Fix
> violations of coding standards and enable checkstyle check
>
>
> New Feature :
> -------------
>
> DIRAPI-250 <https://issues.apache.org/jira/browse/DIRAPI-250> - Add
> a way to Anonymize a LDIF file
>
>
> Question :
> ----------
>
> DIRAPI-191 <https://issues.apache.org/jira/browse/DIRAPI-191> - How
> to get attributes list according to objectClass
>
>
> The revision :
>
> http://svn.apache.org/viewvc?view=revision&revision=1708634<http://svn.apache.org/r1676503>
>
> The SVN tag:
> http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M32
> <http://svn.apache.org/repos/asf/directory/shared/tags/1.0.0-M29>
>
> The source and binary distribution packages:
> http://people.apache.org/~elecharny/
> <http://people.apache.org/%7Eelecharny/>
>
> The staging repository:
> https://repository.apache.org/content/repositories/orgapachedirectory-1044
> <https://repository.apache.org/content/repositories/orgapachedirectory-1031>
>
>
> Please cast your votes:
> [ ] +1 Release Shared/LDAP API 1.0.0-M32
> [ ] 0 abstain
> [ ] -1 Do not release Shared/LDAP API 1.0.0-M32
>
>
> Emmanuel
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com>
>