On Thu, Oct 15, 2015 at 1:26 PM, Lucas Theisen <lucasthei...@pastdev.com> wrote:
> On Thu, Oct 15, 2015 at 1:01 PM, Lucas Theisen <lucasthei...@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 <elecha...@gmail.com> >> wrote: >> >>> Le 15/10/15 18:22, Lucas Theisen a écrit : >>> > On Wed, Oct 14, 2015 at 10:59 PM, Kiran Ayyagari <kayyag...@apache.org >>> > >>> > wrote: >>> > >>> >> >>> >> On Thu, Oct 15, 2015 at 4:36 AM, Lucas Theisen < >>> lucasthei...@pastdev.com> >>> >> wrote: >>> >> >>> >>> On Wed, Oct 14, 2015 at 1:36 PM, Emmanuel Lecharny < >>> elecha...@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 < >>> elecha...@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.
