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 2013/05/19 09:35:16 UTC
ApacheDS and Java 6 build pb
Hi guys,
yesterday, I played with the pom.xml file to tell maven to build the
project using a Java 6 compatibility, instead of Java 5.
I get some error in SaslBindIT. I think we have some incompatiblity with
a Java 6 built server... Is it just me ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/19/13 3:49 PM, Stefan Seelmann a écrit :
> Hi Emmanuel,
>
> what did you change in the ApacheDS pom.xml? The maven-compiler-plugin
> seems already be configured for Java 6:
Not everywhere. The project/pom.xml file still refers to 1.5 :
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
<optimize>true</optimize>
<showDeprecations>true</showDeprecations>
<encoding>ISO-8859-1</encoding>
</configuration>
</plugin>
There are also references in shared/pom.xml on 1.5, for javadoc and pmd.
>
> 158 <plugin>
> 159 <groupId>org.apache.maven.plugins</groupId>
> 160 <artifactId>maven-compiler-plugin</artifactId>
> 161 <configuration>
> 162 <source>1.6</source>
> 163 <target>1.6</target>
> 164 <optimize>true</optimize>
> 165 <showDeprecations>true</showDeprecations>
> 166 <encoding>ISO-8859-1</encoding>
> 167 </configuration>
> 168 </plugin>
>
>
> I run the build using the following environment:
>
> $ mvn -v
> Apache Maven 3.0.5 (rNON-CANONICAL_2013-02-25_10-23_root; 2013-02-25
> 11:23:59+0100)
> Maven home: /opt/maven
> Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
> Java home: /opt/jdk1.6.0_45/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.9.2-1-arch", arch: "amd64", family: "unix"
>
>
> For me the SaslBindIT works, however another test fails:
> testModDn(org.apache.directory.server.replication.ClientServerReplicationIT) Time elapsed: 11.007 sec <<< FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.directory.server.replication.ClientServerReplicationIT.testModDn(ClientServerReplicationIT.java:297)
I do think I have fixed this issue last week. It's an error due to a
thread that starts too late, and the replication occurs before the
startup is done.
Are you sure you have checked out th last trunk ?
As Kiran said, I may have a specific Mac OSX issue. Damn Oracle...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Emmanuel,
what did you change in the ApacheDS pom.xml? The maven-compiler-plugin
seems already be configured for Java 6:
158 <plugin>
159 <groupId>org.apache.maven.plugins</groupId>
160 <artifactId>maven-compiler-plugin</artifactId>
161 <configuration>
162 <source>1.6</source>
163 <target>1.6</target>
164 <optimize>true</optimize>
165 <showDeprecations>true</showDeprecations>
166 <encoding>ISO-8859-1</encoding>
167 </configuration>
168 </plugin>
I run the build using the following environment:
$ mvn -v
Apache Maven 3.0.5 (rNON-CANONICAL_2013-02-25_10-23_root; 2013-02-25
11:23:59+0100)
Maven home: /opt/maven
Java version: 1.6.0_45, vendor: Sun Microsystems Inc.
Java home: /opt/jdk1.6.0_45/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.9.2-1-arch", arch: "amd64", family: "unix"
For me the SaslBindIT works, however another test fails:
testModDn(org.apache.directory.server.replication.ClientServerReplicationIT) Time elapsed: 11.007 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.directory.server.replication.ClientServerReplicationIT.testModDn(ClientServerReplicationIT.java:297)
Kind Regards,
Stefan
On 19.05.2013 15:16, Emmanuel Lécharny wrote:
> Le 5/19/13 2:15 PM, Emmanuel Lécharny a écrit :
>> Le 5/19/13 9:35 AM, Emmanuel Lécharny a écrit :
>>> Hi guys,
>>>
>>> yesterday, I played with the pom.xml file to tell maven to build the
>>> project using a Java 6 compatibility, instead of Java 5.
>>>
>>> I get some error in SaslBindIT. I think we have some incompatiblity with
>>> a Java 6 built server... Is it just me ?
>>>
>> I can confirm that if I switch to JDK 1.6 compatibility on the project's
>> pom, the build breaks...
>>
> Well, forget about this message. I was running the buld with -DskipTests.
>
> I have a failure on SaslBindIT test (server-integ) :
>
> Running org.apache.directory.server.operations.bind.SaslBindIT
> javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindSasl(LdapNetworkConnection.java:3807)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.access$200(LdapNetworkConnection.java:178)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection$2.run(LdapNetworkConnection.java:1529)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1525)
> at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1427)
> at
> org.apache.directory.server.operations.bind.SaslBindIT.testSaslGssApiBind(SaslBindIT.java:519)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.directory.junit.tools.MultiThreadedMultiInvoker$1$1.run(MultiThreadedMultiInvoker.java:160)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: GSSException: No valid credentials provided (Mechanism level:
> Server not found in Kerberos database (7) - Server not found in Kerberos
> database)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:710)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
> at
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
> ... 20 more
> Caused by: KrbException: Server not found in Kerberos database (7) -
> Server not found in Kerberos database
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:73)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:311)
> at
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:442)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> ... 23 more
> Caused by: KrbException: Identifier doesn't match expected value (906)
> at sun.security.krb5.internal.KDCRep.init(KDCRep.java:143)
> at sun.security.krb5.internal.TGSRep.init(TGSRep.java:66)
> at sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:61)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:55)
> ... 29 more
> Tests run: 17, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 15.545
> sec <<< FAILURE!
>
>
> Is anyone have the same failure, when running mvn clean install on trunk ?
>
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/20/13 8:35 AM, Emmanuel Lécharny a écrit :
> So the problem appears to be that we create an entry which
> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
> reason, we are looking for an entry which kerberos principal is
> ldap/localhost@EXAMPLE.COM.
>
> It looks like that there is some name resolution occuring somewhere on
> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
> have a conversion we don't asked for.
>
> I'm investigating...
>
Ok, it seems that we get the same error that on windows :
// On Windows 7 and Server 2008 the loopback address 127.0.0.1
// isn't resolved to localhost by default. In that case we need
// to use the IP address for the service principal.
String hostName;
try
{
InetAddress loopback = InetAddress.getByName( "127.0.0.1" );
hostName = loopback.getHostName();
}
catch ( UnknownHostException e )
{
System.err.println( "Can't find loopback address
'127.0.0.1', using hostname 'localhost'" );
hostName = "localhost";
}
String servicePrincipal = "ldap/" + hostName + "@EXAMPLE.COM";
getLdapServer().setSaslPrincipal( servicePrincipal );
So the stored KerberosPrincipal contains 127.0.0.1, but we do request
localhost later on...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/22/13 9:30 AM, Emmanuel Lécharny a écrit :
> Le 5/22/13 9:20 AM, Stefan Seelmann a écrit :
>> On 21.05.2013 01:31, Emmanuel Lécharny wrote:
>>> Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
>>>> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>>>>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>>>>> Hi Emmanuel,
>>>>>>
>>>>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>>>>> So the problem appears to be that we create an entry which
>>>>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>>>>>>> reason, we are looking for an entry which kerberos principal is
>>>>>>> ldap/localhost@EXAMPLE.COM.
>>>>>>>
>>>>>>> It looks like that there is some name resolution occuring somewhere on
>>>>>>> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
>>>>>>> have a conversion we don't asked for.
>>>>>>>
>>>>>>> I'm investigating...
>>>>>>>
>>>>>> Please check the constructor of SaslBindIT. I remember that I added some
>>>>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>>>>> 7 made some trouble.
>>>>> Yes, saw that.
>>>>>
>>>>> I just committed some code that fixes the issue on Mac OSX, it would be
>>>>> cool to check if it still works on windows and linux !
>>>>> See
>>>>>
>>>>> http://svn.apache.org/r1484387
>>>>>
>>>> On Windows two GSSAPI SASL bind tests fail:
>>>> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>>>>
>>>>
>>>> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
>>>> debug into TicketGrantingService,getRequestPrincipalEntry() the
>>>> tgsContext.getRequest().getKdcReqBody().getSName() contains
>>>> "localhost.localdomain". I checked my /etc/hosts and there I have the
>>>> following entry:
>>>>
>>>> 127.0.0.1 localhost.localdomain localhost
>>>>
>>>>
>>>> When I change that entry to the following the test works.
>>>>
>>>> 127.0.0.1 localhost
>>>>
>>>>
>>>> When I revert your commit the test also works as
>>>> InetAddress.getByName("127.0.0.1").getHostName() returns
>>>> "localhost.localdomain"
>>>>
>>>>
>>>> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
>>> Here is what I have :
>>>
>>> 127.0.0.1 localhost
>>>
>>>> More important: Somewhere in the production code the IP 127.0.0.1 is
>>>> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
>>>> Where does that happen? Does the KRB client does that and sends the
>>>> resolved name to the server? Or does the server resolve the name when a
>>>> connection is made? In the end the principal name contains
>>>> "localhost.localdomain". I think to have a stable test the test setup
>>>> needs to use the same mechanism to lookup the hostname as the production
>>>> code.
>>> The thing is that I think that the conversion to ldaphost is done
>>> internaly but some of the JDK code. It was working fine before I
>>> upgraded my JVM.
>> I found the place where the DNS lookup is done, it is in an JDK internal
>> class sun.security.krb5.PrincipalName. I changed the test again, now it
>> creates a KerberosPrincipal which internally calls the code and does the
>> DNS lookup. I started a Windows build on Jenkins, let's see if it works
>> there. Can you please also check if this works on your machine? If not
>> feel free to rollback.
> Running tests while I take my shower.
Works like a charm (except a failure in the middle on
CollectiveAttributeServiceIT tests :/)
I hate this issue. It's probably related to some pb with the cache we
use to manage Administrative model... It's really hard to investigate,
because it only happens randomly, and not frequently :/
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/22/13 9:20 AM, Stefan Seelmann a écrit :
> On 21.05.2013 01:31, Emmanuel Lécharny wrote:
>> Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
>>> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>>>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>>>> Hi Emmanuel,
>>>>>
>>>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>>>> So the problem appears to be that we create an entry which
>>>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>>>>>> reason, we are looking for an entry which kerberos principal is
>>>>>> ldap/localhost@EXAMPLE.COM.
>>>>>>
>>>>>> It looks like that there is some name resolution occuring somewhere on
>>>>>> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
>>>>>> have a conversion we don't asked for.
>>>>>>
>>>>>> I'm investigating...
>>>>>>
>>>>> Please check the constructor of SaslBindIT. I remember that I added some
>>>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>>>> 7 made some trouble.
>>>> Yes, saw that.
>>>>
>>>> I just committed some code that fixes the issue on Mac OSX, it would be
>>>> cool to check if it still works on windows and linux !
>>>> See
>>>>
>>>> http://svn.apache.org/r1484387
>>>>
>>> On Windows two GSSAPI SASL bind tests fail:
>>> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>>>
>>>
>>> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
>>> debug into TicketGrantingService,getRequestPrincipalEntry() the
>>> tgsContext.getRequest().getKdcReqBody().getSName() contains
>>> "localhost.localdomain". I checked my /etc/hosts and there I have the
>>> following entry:
>>>
>>> 127.0.0.1 localhost.localdomain localhost
>>>
>>>
>>> When I change that entry to the following the test works.
>>>
>>> 127.0.0.1 localhost
>>>
>>>
>>> When I revert your commit the test also works as
>>> InetAddress.getByName("127.0.0.1").getHostName() returns
>>> "localhost.localdomain"
>>>
>>>
>>> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
>> Here is what I have :
>>
>> 127.0.0.1 localhost
>>
>>> More important: Somewhere in the production code the IP 127.0.0.1 is
>>> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
>>> Where does that happen? Does the KRB client does that and sends the
>>> resolved name to the server? Or does the server resolve the name when a
>>> connection is made? In the end the principal name contains
>>> "localhost.localdomain". I think to have a stable test the test setup
>>> needs to use the same mechanism to lookup the hostname as the production
>>> code.
>> The thing is that I think that the conversion to ldaphost is done
>> internaly but some of the JDK code. It was working fine before I
>> upgraded my JVM.
> I found the place where the DNS lookup is done, it is in an JDK internal
> class sun.security.krb5.PrincipalName. I changed the test again, now it
> creates a KerberosPrincipal which internally calls the code and does the
> DNS lookup. I started a Windows build on Jenkins, let's see if it works
> there. Can you please also check if this works on your machine? If not
> feel free to rollback.
Running tests while I take my shower.
What you have found confirm that the Java update I did causes the test
to fail on Mac. This is worrysome though, because the KrbPrincipalName
stored in the entry is hard wired. OTOH, it's an extremely wrong thing
to have a kerberosPrincipal containing localhost (except for tests...)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 21.05.2013 01:31, Emmanuel Lécharny wrote:
> Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
>> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>>> Hi Emmanuel,
>>>>
>>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>>> So the problem appears to be that we create an entry which
>>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>>>>> reason, we are looking for an entry which kerberos principal is
>>>>> ldap/localhost@EXAMPLE.COM.
>>>>>
>>>>> It looks like that there is some name resolution occuring somewhere on
>>>>> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
>>>>> have a conversion we don't asked for.
>>>>>
>>>>> I'm investigating...
>>>>>
>>>> Please check the constructor of SaslBindIT. I remember that I added some
>>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>>> 7 made some trouble.
>>> Yes, saw that.
>>>
>>> I just committed some code that fixes the issue on Mac OSX, it would be
>>> cool to check if it still works on windows and linux !
>>> See
>>>
>>> http://svn.apache.org/r1484387
>>>
>> On Windows two GSSAPI SASL bind tests fail:
>> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>>
>>
>> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
>> debug into TicketGrantingService,getRequestPrincipalEntry() the
>> tgsContext.getRequest().getKdcReqBody().getSName() contains
>> "localhost.localdomain". I checked my /etc/hosts and there I have the
>> following entry:
>>
>> 127.0.0.1 localhost.localdomain localhost
>>
>>
>> When I change that entry to the following the test works.
>>
>> 127.0.0.1 localhost
>>
>>
>> When I revert your commit the test also works as
>> InetAddress.getByName("127.0.0.1").getHostName() returns
>> "localhost.localdomain"
>>
>>
>> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
>
> Here is what I have :
>
> 127.0.0.1 localhost
>
>>
>> More important: Somewhere in the production code the IP 127.0.0.1 is
>> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
>> Where does that happen? Does the KRB client does that and sends the
>> resolved name to the server? Or does the server resolve the name when a
>> connection is made? In the end the principal name contains
>> "localhost.localdomain". I think to have a stable test the test setup
>> needs to use the same mechanism to lookup the hostname as the production
>> code.
>
> The thing is that I think that the conversion to ldaphost is done
> internaly but some of the JDK code. It was working fine before I
> upgraded my JVM.
I found the place where the DNS lookup is done, it is in an JDK internal
class sun.security.krb5.PrincipalName. I changed the test again, now it
creates a KerberosPrincipal which internally calls the code and does the
DNS lookup. I started a Windows build on Jenkins, let's see if it works
there. Can you please also check if this works on your machine? If not
feel free to rollback.
Kind Regards,
Stefan
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/20/13 8:25 PM, Stefan Seelmann a écrit :
> On 20.05.2013 09:42, Emmanuel Lécharny wrote:
>> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>>> Hi Emmanuel,
>>>
>>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>>> So the problem appears to be that we create an entry which
>>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>>>> reason, we are looking for an entry which kerberos principal is
>>>> ldap/localhost@EXAMPLE.COM.
>>>>
>>>> It looks like that there is some name resolution occuring somewhere on
>>>> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
>>>> have a conversion we don't asked for.
>>>>
>>>> I'm investigating...
>>>>
>>> Please check the constructor of SaslBindIT. I remember that I added some
>>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>>> 7 made some trouble.
>> Yes, saw that.
>>
>> I just committed some code that fixes the issue on Mac OSX, it would be
>> cool to check if it still works on windows and linux !
>> See
>>
>> http://svn.apache.org/r1484387
>>
> On Windows two GSSAPI SASL bind tests fail:
> https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
>
>
> On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
> debug into TicketGrantingService,getRequestPrincipalEntry() the
> tgsContext.getRequest().getKdcReqBody().getSName() contains
> "localhost.localdomain". I checked my /etc/hosts and there I have the
> following entry:
>
> 127.0.0.1 localhost.localdomain localhost
>
>
> When I change that entry to the following the test works.
>
> 127.0.0.1 localhost
>
>
> When I revert your commit the test also works as
> InetAddress.getByName("127.0.0.1").getHostName() returns
> "localhost.localdomain"
>
>
> Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
Here is what I have :
127.0.0.1 localhost
>
> More important: Somewhere in the production code the IP 127.0.0.1 is
> resolved to "localhost.localdomain" or whatever /etc/hosts contains.
> Where does that happen? Does the KRB client does that and sends the
> resolved name to the server? Or does the server resolve the name when a
> connection is made? In the end the principal name contains
> "localhost.localdomain". I think to have a stable test the test setup
> needs to use the same mechanism to lookup the hostname as the production
> code.
The thing is that I think that the conversion to ldaphost is done
internaly but some of the JDK code. It was working fine before I
upgraded my JVM.
This is not cristal clear to me... I will investigate more deeply tomorrow.
Thanks for the feedback Stefan !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
On 20.05.2013 09:42, Emmanuel Lécharny wrote:
> Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
>> Hi Emmanuel,
>>
>> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>>> So the problem appears to be that we create an entry which
>>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>>> reason, we are looking for an entry which kerberos principal is
>>> ldap/localhost@EXAMPLE.COM.
>>>
>>> It looks like that there is some name resolution occuring somewhere on
>>> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
>>> have a conversion we don't asked for.
>>>
>>> I'm investigating...
>>>
>> Please check the constructor of SaslBindIT. I remember that I added some
>> magic code to detect how the machine resolves 127.0.0.1 because Windows
>> 7 made some trouble.
>
> Yes, saw that.
>
> I just committed some code that fixes the issue on Mac OSX, it would be
> cool to check if it still works on windows and linux !
> See
>
> http://svn.apache.org/r1484387
>
On Windows two GSSAPI SASL bind tests fail:
https://builds.apache.org/job/dir-apacheds-jdk16-win/399/
On my Linux machine the SaslBindIT.testSaslGssApiBind() fails also. If I
debug into TicketGrantingService,getRequestPrincipalEntry() the
tgsContext.getRequest().getKdcReqBody().getSName() contains
"localhost.localdomain". I checked my /etc/hosts and there I have the
following entry:
127.0.0.1 localhost.localdomain localhost
When I change that entry to the following the test works.
127.0.0.1 localhost
When I revert your commit the test also works as
InetAddress.getByName("127.0.0.1").getHostName() returns
"localhost.localdomain"
Can you please check your /etc/hosts if you have an entry for 127.0.0.1?
More important: Somewhere in the production code the IP 127.0.0.1 is
resolved to "localhost.localdomain" or whatever /etc/hosts contains.
Where does that happen? Does the KRB client does that and sends the
resolved name to the server? Or does the server resolve the name when a
connection is made? In the end the principal name contains
"localhost.localdomain". I think to have a stable test the test setup
needs to use the same mechanism to lookup the hostname as the production
code.
Kind Regards,
Stefan
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/20/13 8:54 AM, Stefan Seelmann a écrit :
> Hi Emmanuel,
>
> On 20.05.2013 08:35, Emmanuel Lécharny wrote:
>> So the problem appears to be that we create an entry which
>> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
>> reason, we are looking for an entry which kerberos principal is
>> ldap/localhost@EXAMPLE.COM.
>>
>> It looks like that there is some name resolution occuring somewhere on
>> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
>> have a conversion we don't asked for.
>>
>> I'm investigating...
>>
> Please check the constructor of SaslBindIT. I remember that I added some
> magic code to detect how the machine resolves 127.0.0.1 because Windows
> 7 made some trouble.
Yes, saw that.
I just committed some code that fixes the issue on Mac OSX, it would be
cool to check if it still works on windows and linux !
See
http://svn.apache.org/r1484387
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
Hi Emmanuel,
On 20.05.2013 08:35, Emmanuel Lécharny wrote:
> So the problem appears to be that we create an entry which
> KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
> reason, we are looking for an entry which kerberos principal is
> ldap/localhost@EXAMPLE.COM.
>
> It looks like that there is some name resolution occuring somewhere on
> Mac OSX... Either we don't store the correct KerberosPrincipal, or we
> have a conversion we don't asked for.
>
> I'm investigating...
>
Please check the constructor of SaslBindIT. I remember that I added some
magic code to detect how the machine resolves 127.0.0.1 because Windows
7 made some trouble.
Kind Regards,
Stefan
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
So the problem appears to be that we create an entry which
KerberosPrincipal is ldap/127.0.0.1@EXAMPLE.COM, but for some unknown
reason, we are looking for an entry which kerberos principal is
ldap/localhost@EXAMPLE.COM.
It looks like that there is some name resolution occuring somewhere on
Mac OSX... Either we don't store the correct KerberosPrincipal, or we
have a conversion we don't asked for.
I'm investigating...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/19/13 6:15 PM, Emmanuel Lécharny a écrit :
> Le 5/19/13 4:04 PM, Kiran Ayyagari a écrit :
>> On Sun, May 19, 2013 at 6:46 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
>>
>>> Is anyone have the same failure, when running mvn clean install on trunk ?
>>>
>>> maven-compiler-plugin in apacheds/pom.xml is already targeted to 1.6
>> but I have also changed the same plugin present in project/pom.xml to 1.6
>> and didn't encounter this error
>> otoh, I just ran this test alone using mvn test -Dtest=SaslBindIT
>> you error could be an 'on Apple only' thing?
> I have updated my JVM recently, and I suspect that it has some impact on
> MacOSX...
I confirm : I have the exact same failure when building the M12 revision
(SaslBindIT). It's definitively a problem with the last Java update I
did on my machine. Now to find why...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/19/13 4:04 PM, Kiran Ayyagari a écrit :
> On Sun, May 19, 2013 at 6:46 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Le 5/19/13 2:15 PM, Emmanuel Lécharny a écrit :
>>> Le 5/19/13 9:35 AM, Emmanuel Lécharny a écrit :
>>>> Hi guys,
>>>>
>>>> yesterday, I played with the pom.xml file to tell maven to build the
>>>> project using a Java 6 compatibility, instead of Java 5.
>>>>
>>>> I get some error in SaslBindIT. I think we have some incompatiblity with
>>>> a Java 6 built server... Is it just me ?
>>>>
>>> I can confirm that if I switch to JDK 1.6 compatibility on the project's
>>> pom, the build breaks...
>>>
>> Well, forget about this message. I was running the buld with -DskipTests.
>>
>> I have a failure on SaslBindIT test (server-integ) :
>>
>> Running org.apache.directory.server.operations.bind.SaslBindIT
>> javax.security.sasl.SaslException: GSS initiate failed [Caused by
>> GSSException: No valid credentials provided (Mechanism level: Server not
>> found in Kerberos database (7) - Server not found in Kerberos database)]
>> at
>>
>> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
>> at
>>
>> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindSasl(LdapNetworkConnection.java:3807)
>> at
>>
>> org.apache.directory.ldap.client.api.LdapNetworkConnection.access$200(LdapNetworkConnection.java:178)
>> at
>>
>> org.apache.directory.ldap.client.api.LdapNetworkConnection$2.run(LdapNetworkConnection.java:1529)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at javax.security.auth.Subject.doAs(Subject.java:415)
>> at
>>
>> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1525)
>> at
>>
>> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1427)
>> at
>>
>> org.apache.directory.server.operations.bind.SaslBindIT.testSaslGssApiBind(SaslBindIT.java:519)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>>
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at
>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:601)
>> at
>>
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>> at
>>
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>> at
>>
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>> at
>>
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>> at
>>
>> org.apache.directory.junit.tools.MultiThreadedMultiInvoker$1$1.run(MultiThreadedMultiInvoker.java:160)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at
>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:722)
>> Caused by: GSSException: No valid credentials provided (Mechanism level:
>> Server not found in Kerberos database (7) - Server not found in Kerberos
>> database)
>> at
>> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:710)
>> at
>> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
>> at
>> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
>> at
>>
>> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
>> ... 20 more
>> Caused by: KrbException: Server not found in Kerberos database (7) -
>> Server not found in Kerberos database
>> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:73)
>> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
>> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
>> at
>>
>> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:311)
>> at
>>
>> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
>> at
>> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:442)
>> at
>> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
>> ... 23 more
>> Caused by: KrbException: Identifier doesn't match expected value (906)
>> at sun.security.krb5.internal.KDCRep.init(KDCRep.java:143)
>> at sun.security.krb5.internal.TGSRep.init(TGSRep.java:66)
>> at sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:61)
>> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:55)
>> ... 29 more
>> Tests run: 17, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 15.545
>> sec <<< FAILURE!
>>
>>
>> Is anyone have the same failure, when running mvn clean install on trunk ?
>>
>> maven-compiler-plugin in apacheds/pom.xml is already targeted to 1.6
> but I have also changed the same plugin present in project/pom.xml to 1.6
> and didn't encounter this error
> otoh, I just ran this test alone using mvn test -Dtest=SaslBindIT
> you error could be an 'on Apple only' thing?
I have updated my JVM recently, and I suspect that it has some impact on
MacOSX...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Kiran Ayyagari <ka...@apache.org>.
On Sun, May 19, 2013 at 6:46 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 5/19/13 2:15 PM, Emmanuel Lécharny a écrit :
> > Le 5/19/13 9:35 AM, Emmanuel Lécharny a écrit :
> >> Hi guys,
> >>
> >> yesterday, I played with the pom.xml file to tell maven to build the
> >> project using a Java 6 compatibility, instead of Java 5.
> >>
> >> I get some error in SaslBindIT. I think we have some incompatiblity with
> >> a Java 6 built server... Is it just me ?
> >>
> > I can confirm that if I switch to JDK 1.6 compatibility on the project's
> > pom, the build breaks...
> >
> Well, forget about this message. I was running the buld with -DskipTests.
>
> I have a failure on SaslBindIT test (server-integ) :
>
> Running org.apache.directory.server.operations.bind.SaslBindIT
> javax.security.sasl.SaslException: GSS initiate failed [Caused by
> GSSException: No valid credentials provided (Mechanism level: Server not
> found in Kerberos database (7) - Server not found in Kerberos database)]
> at
>
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindSasl(LdapNetworkConnection.java:3807)
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.access$200(LdapNetworkConnection.java:178)
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection$2.run(LdapNetworkConnection.java:1529)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1525)
> at
>
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1427)
> at
>
> org.apache.directory.server.operations.bind.SaslBindIT.testSaslGssApiBind(SaslBindIT.java:519)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
>
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
>
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
>
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
>
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
>
> org.apache.directory.junit.tools.MultiThreadedMultiInvoker$1$1.run(MultiThreadedMultiInvoker.java:160)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: GSSException: No valid credentials provided (Mechanism level:
> Server not found in Kerberos database (7) - Server not found in Kerberos
> database)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:710)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
> at
> sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
> at
>
> com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
> ... 20 more
> Caused by: KrbException: Server not found in Kerberos database (7) -
> Server not found in Kerberos database
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:73)
> at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
> at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
> at
>
> sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:311)
> at
>
> sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
> at
> sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:442)
> at
> sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
> ... 23 more
> Caused by: KrbException: Identifier doesn't match expected value (906)
> at sun.security.krb5.internal.KDCRep.init(KDCRep.java:143)
> at sun.security.krb5.internal.TGSRep.init(TGSRep.java:66)
> at sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:61)
> at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:55)
> ... 29 more
> Tests run: 17, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 15.545
> sec <<< FAILURE!
>
>
> Is anyone have the same failure, when running mvn clean install on trunk ?
>
> maven-compiler-plugin in apacheds/pom.xml is already targeted to 1.6
but I have also changed the same plugin present in project/pom.xml to 1.6
and didn't encounter this error
otoh, I just ran this test alone using mvn test -Dtest=SaslBindIT
you error could be an 'on Apple only' thing?
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/19/13 2:15 PM, Emmanuel Lécharny a écrit :
> Le 5/19/13 9:35 AM, Emmanuel Lécharny a écrit :
>> Hi guys,
>>
>> yesterday, I played with the pom.xml file to tell maven to build the
>> project using a Java 6 compatibility, instead of Java 5.
>>
>> I get some error in SaslBindIT. I think we have some incompatiblity with
>> a Java 6 built server... Is it just me ?
>>
> I can confirm that if I switch to JDK 1.6 compatibility on the project's
> pom, the build breaks...
>
Well, forget about this message. I was running the buld with -DskipTests.
I have a failure on SaslBindIT test (server-integ) :
Running org.apache.directory.server.operations.bind.SaslBindIT
javax.security.sasl.SaslException: GSS initiate failed [Caused by
GSSException: No valid credentials provided (Mechanism level: Server not
found in Kerberos database (7) - Server not found in Kerberos database)]
at
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:212)
at
org.apache.directory.ldap.client.api.LdapNetworkConnection.bindSasl(LdapNetworkConnection.java:3807)
at
org.apache.directory.ldap.client.api.LdapNetworkConnection.access$200(LdapNetworkConnection.java:178)
at
org.apache.directory.ldap.client.api.LdapNetworkConnection$2.run(LdapNetworkConnection.java:1529)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at
org.apache.directory.ldap.client.api.LdapNetworkConnection.bindAsync(LdapNetworkConnection.java:1525)
at
org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1427)
at
org.apache.directory.server.operations.bind.SaslBindIT.testSaslGssApiBind(SaslBindIT.java:519)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.directory.junit.tools.MultiThreadedMultiInvoker$1$1.run(MultiThreadedMultiInvoker.java:160)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: GSSException: No valid credentials provided (Mechanism level:
Server not found in Kerberos database (7) - Server not found in Kerberos
database)
at
sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:710)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
at
sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at
com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:193)
... 20 more
Caused by: KrbException: Server not found in Kerberos database (7) -
Server not found in Kerberos database
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:73)
at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:192)
at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:203)
at
sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:311)
at
sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:115)
at
sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:442)
at
sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:641)
... 23 more
Caused by: KrbException: Identifier doesn't match expected value (906)
at sun.security.krb5.internal.KDCRep.init(KDCRep.java:143)
at sun.security.krb5.internal.TGSRep.init(TGSRep.java:66)
at sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:61)
at sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:55)
... 29 more
Tests run: 17, Failures: 0, Errors: 1, Skipped: 4, Time elapsed: 15.545
sec <<< FAILURE!
Is anyone have the same failure, when running mvn clean install on trunk ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: ApacheDS and Java 6 build pb
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 5/19/13 9:35 AM, Emmanuel Lécharny a écrit :
> Hi guys,
>
> yesterday, I played with the pom.xml file to tell maven to build the
> project using a Java 6 compatibility, instead of Java 5.
>
> I get some error in SaslBindIT. I think we have some incompatiblity with
> a Java 6 built server... Is it just me ?
>
I can confirm that if I switch to JDK 1.6 compatibility on the project's
pom, the build breaks...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com