Re: New continuum instance for directory
On 16 août 2010, at 20:58, Stefan Seelmann wrote: First, you need to create a new account because all previous accounts are gone. I can assign permissions for the Directory group then. (LDAP integration would be cool btw, let me file a Jira) I create a new account for myself. id=pamarcelot Done, you are admin. Thanks Stefan! Regards, Pierre-Arnaud
Re: New continuum instance for directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could you test the following patch [1]? It's just a blind guess but sets explicit encoding when reading and writing the schema files. Thanks Stefan Patch doesn't resolves the problem. I could elaborate a bit more. Following change will throw a more specific error: In fact the error also occurs for other test classes but doesn't forces a failure. Index: ldap/src/main/java/org/apache/directory/shared/ldap/schema/AttributeType.java === - --- ldap/src/main/java/org/apache/directory/shared/ldap/schema/AttributeType.java (revision 985989) +++ ldap/src/main/java/org/apache/directory/shared/ldap/schema/AttributeType.java (working copy) @@ -226,6 +226,9 @@ String msg = I18n.err( I18n.ERR_04303, superiorOid, getName() ); Throwable error = new LdapProtocolErrorException( msg ); + +e.printStackTrace(); + errors.add( error ); LOG.info( msg ); Running org.apache.directory.shared.ldap.schema.loader.ldif.SchemaManagerLoadTest org.apache.directory.shared.ldap.exception.LdapNoSuchAttributeException: ERR_04269 ATTRIBUTE_TYPE for OID name does not exist! at org.apache.directory.shared.ldap.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:316) at org.apache.directory.shared.ldap.schema.registries.DefaultAttributeTypeRegistry.lookup(DefaultAttributeTypeRegistry.java:46) at org.apache.directory.shared.ldap.schema.AttributeType.buildSuperior(AttributeType.java:221) at org.apache.directory.shared.ldap.schema.AttributeType.addToRegistries(AttributeType.java:622) at org.apache.directory.shared.ldap.schema.registries.Registries.buildReference(Registries.java:727) at org.apache.directory.shared.ldap.schema.registries.Registries.add(Registries.java:1358) at org.apache.directory.shared.ldap.schema.manager.impl.DefaultSchemaManager.addSchemaObject(DefaultSchemaManager.java:896) at org.apache.directory.shared.ldap.schema.manager.impl.DefaultSchemaManager.addAttributeTypes(DefaultSchemaManager.java:731) at org.apache.directory.shared.ldap.schema.manager.impl.DefaultSchemaManager.addSchemaObjects(DefaultSchemaManager.java:236) at org.apache.directory.shared.ldap.schema.manager.impl.DefaultSchemaManager.load(DefaultSchemaManager.java:682) at org.apache.directory.shared.ldap.schema.manager.impl.DefaultSchemaManager.load(DefaultSchemaManager.java:546) at org.apache.directory.shared.ldap.schema.manager.impl.DefaultSchemaManager.load(DefaultSchemaManager.java:623) at org.apache.directory.shared.ldap.schema.loader.ldif.SchemaManagerLoadTest.testLoadCoreInetOrgPersonAndNis(SchemaManagerLoadTest.java:219) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:21) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:194) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:53) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:185) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:29) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:117) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102) at org.apache.maven.surefire.Surefire.run(Surefire.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
Re: New continuum instance for directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I finally got it running ... But I'm not sure if the 'solution' shows up an issue. I don't know if the order of given schemas to load matters. If it shouldn't it's a problem. Maybe schemas are loaded line by line into a e.g.Map and then processed. IIRC in this case we can garantee the order an iterator fetches the elements. Patch which solved the problem on my machine (note the nis schema which is now loaded last). I didn't apply the patch, because if it's an issue we should be reminded ...: Index: ldap-schema-manager-tests/src/test/java/org/apache/directory/shared/ldap/schema/loader/ldif/SchemaManagerLoadTest.java === - --- ldap-schema-manager-tests/src/test/java/org/apache/directory/shared/ldap/schema/loader/ldif/SchemaManagerLoadTest.java (revision 986263) +++ ldap-schema-manager-tests/src/test/java/org/apache/directory/shared/ldap/schema/loader/ldif/SchemaManagerLoadTest.java (working copy) @@ -668,7 +668,7 @@ // Try to load a disabled schema when the registries does // ot allow disabled schema to be loaded - -assertFalse( schemaManager.load( core, nis, cosine, InetOrgPerson ) ); +assertFalse( schemaManager.load( core, cosine, InetOrgPerson, nis ) ); assertFalse( schemaManager.getErrors().isEmpty() ); assertEquals( 38, schemaManager.getAttributeTypeRegistry().size() ); Hope anybody has an idea about this. Regards Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqfYIACgkQ2lZVCB08qHFSZACgz9x1ez/YVzB3VOP2ktPMbXFr sAQAnRv1F0qjOUr6eU4zmZzNsVE170Ec =Uf3N -END PGP SIGNATURE-
Re: New continuum instance for directory
On 8/17/10 2:16 PM, Felix Knecht wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I finally got it running ... But I'm not sure if the 'solution' shows up an issue. I don't know if the order of given schemas to load matters. If it shouldn't it's a problem. Maybe schemas are loaded line by line into a e.g.Map and then processed. IIRC in this case we can garantee the order an iterator fetches the elements. Patch which solved the problem on my machine (note the nis schema which is now loaded last). I didn't apply the patch, because if it's an issue we should be reminded ...: It's not simple ... The way the SchemaManager loads the schema is the following : - first, relax the system (ie, accept errors) - load everything - when done, check for cross references (ie, AT depending on other ATs, etc) - if there is no error, then discard the created registries (the internal storage), and set the SM to a strict mode - load again - check again This should not result in an error, unless the order the data are loaded is incorrect. We may have to check this part, I think that Kiran is already reviewing this part of the code. I may give him a hand as soon as I'm done with the message merge, as I wrote the initial code. Thanks Felix for the analysis. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: New continuum instance for directory
Can someone give me admin permissions as well. Tried to go in and I cannot do anything through the UI (meaning trigger builds). Thanks, Alex On Mon, Aug 16, 2010 at 9:58 PM, Stefan Seelmann seelm...@apache.orgwrote: First, you need to create a new account because all previous accounts are gone. I can assign permissions for the Directory group then. (LDAP integration would be cool btw, let me file a Jira) I create a new account for myself. id=pamarcelot Done, you are admin. Unfortunately the ApacheDS build fails at the moment, a first notification was already sent to the dev list. Indeed, one failing test in 'testLoadCoreInetOrgPersonAndNis(org.apache.directory.shared.ldap.schema.loader.ldif.SchemaManagerLoadTest)'. :( I really don't understand why that happens. I built the server on serveral other machines where the build is sucessful. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: New continuum instance for directory
On Tue, Aug 17, 2010 at 2:32 PM, Alex Karasulu akaras...@apache.org wrote: Can someone give me admin permissions as well. Tried to go in and I cannot do anything through the UI (meaning trigger builds). Thanks, Alex Done, you and Emmanuel have admin permission.
Re: New continuum instance for directory
Hi Stefan, On 11 août 2010, at 22:26, Stefan Seelmann wrote: Hi dev, Brett Porter set up a new Continuum server, thanks Brett! First, you need to create a new account because all previous accounts are gone. I can assign permissions for the Directory group then. (LDAP integration would be cool btw, let me file a Jira) I create a new account for myself. id=pamarcelot The directory group can be found at [1]. I also set up notifiers for ApacheDS and Studio build. Maybe it would also make sense to add another one for the Studio Plugin? Unfortunately the ApacheDS build fails at the moment, a first notification was already sent to the dev list. Indeed, one failing test in 'testLoadCoreInetOrgPersonAndNis(org.apache.directory.shared.ldap.schema.loader.ldif.SchemaManagerLoadTest)'. :( Regards, Pierre-Arnaud
Re: New continuum instance for directory
First, you need to create a new account because all previous accounts are gone. I can assign permissions for the Directory group then. (LDAP integration would be cool btw, let me file a Jira) I create a new account for myself. id=pamarcelot Done, you are admin. Unfortunately the ApacheDS build fails at the moment, a first notification was already sent to the dev list. Indeed, one failing test in 'testLoadCoreInetOrgPersonAndNis(org.apache.directory.shared.ldap.schema.loader.ldif.SchemaManagerLoadTest)'. :( I really don't understand why that happens. I built the server on serveral other machines where the build is sucessful.
Re: New continuum instance for directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Indeed, one failing test in 'testLoadCoreInetOrgPersonAndNis(org.apache.directory.shared.ldap.schema.loader.ldif.SchemaManagerLoadTest)'. :( I really don't understand why that happens. I built the server on serveral other machines where the build is sucessful. I've two machines, on one of them I can reproduce the error Working: $ mvn -v [WARN ][jrockit] MaxPermSize=512m ignored: Not a valid option for JRockit Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/jrmc-4.0.0-1.6.0/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.35-gentoo-r1 arch: amd64 Family: unix failing: $ mvn -v [WARN ][jrockit] MaxPermSize=512m ignored: Not a valid option for JRockit Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/jrmc-4.0.0-1.6.0/jre Default locale: de_CH, platform encoding: UTF-8 OS name: linux version: 2.6.35-gentoo-r1 arch: amd64 Family: unix Maybe is a problem of the set locale? If I can help to test something, please let me know. Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxpkngACgkQ2lZVCB08qHGbHACgvJ0wvzgcrEt0Sor7nA3QDf2v ae4AnjwLFU3+xhextc7RxNJigs/L+tvj =on7J -END PGP SIGNATURE-
Re: New continuum instance for directory
Hi Felix, Working: $ mvn -v [WARN ][jrockit] MaxPermSize=512m ignored: Not a valid option for JRockit Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/jrmc-4.0.0-1.6.0/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.35-gentoo-r1 arch: amd64 Family: unix failing: $ mvn -v [WARN ][jrockit] MaxPermSize=512m ignored: Not a valid option for JRockit Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/jrmc-4.0.0-1.6.0/jre Default locale: de_CH, platform encoding: UTF-8 OS name: linux version: 2.6.35-gentoo-r1 arch: amd64 Family: unix Maybe is a problem of the set locale? Interesting, the locale on the Continuum server is: Default locale: en_US, platform encoding: ANSI_X3.4-1968 see [1] for more details. [1] http://vmbuild.apache.org/continuum/buildResult.action?projectId=10projectName=buildId=137projectGroupId=6
Re: New continuum instance for directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/16/10 22:09, Stefan Seelmann wrote: Hi Felix, Working: $ mvn -v [WARN ][jrockit] MaxPermSize=512m ignored: Not a valid option for JRockit Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/jrmc-4.0.0-1.6.0/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux version: 2.6.35-gentoo-r1 arch: amd64 Family: unix failing: $ mvn -v [WARN ][jrockit] MaxPermSize=512m ignored: Not a valid option for JRockit Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /opt/jrmc-4.0.0-1.6.0/jre Default locale: de_CH, platform encoding: UTF-8 OS name: linux version: 2.6.35-gentoo-r1 arch: amd64 Family: unix Maybe is a problem of the set locale? Interesting, the locale on the Continuum server is: Default locale: en_US, platform encoding: ANSI_X3.4-1968 see [1] for more details. Yep. Changing the locale didn't solved the issue at my machine. [1] http://vmbuild.apache.org/continuum/buildResult.action?projectId=10projectName=buildId=137projectGroupId=6 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxpnVEACgkQ2lZVCB08qHG47ACfdG50ic9ZII5t2kNumN/eZ+V2 x8IAoOsXZCtdhuqb9p27SHh87yMAllyT =+Mlk -END PGP SIGNATURE-
Re: New continuum instance for directory
Hi guys, I wonder if the issues mentionned in https://issues.apache.org/jira/browse/DIRSERVER-1541 can cause the issues we have ... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: New continuum instance for directory
On Tue, Aug 17, 2010 at 3:06 AM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi guys, I wonder if the issues mentionned in https://issues.apache.org/jira/browse/DIRSERVER-1541 can cause the issues we have ... don't think continuum runs on windows, in any case the server build is consistently failing on CI server, so far no clue why it is happening -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com Kiran Ayyagari
Re: New continuum instance for directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As I can reproduce the failure I'll try to elaborate this a bit. Felix On 08/16/10 23:39, Kiran Ayyagari wrote: On Tue, Aug 17, 2010 at 3:06 AM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi guys, I wonder if the issues mentionned in https://issues.apache.org/jira/browse/DIRSERVER-1541 can cause the issues we have ... don't think continuum runs on windows, in any case the server build is consistently failing on CI server, so far no clue why it is happening -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com Kiran Ayyagari -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqCkoACgkQ2lZVCB08qHGS/wCffkARfvZ+qt3z0Xlqd1C6tctP r08An2T1IBV8l/8VA6Ulp6T8EqirPucw =MgZ0 -END PGP SIGNATURE-
Re: New continuum instance for directory
On Tue, Aug 17, 2010 at 6:04 AM, Felix Knecht fel...@apache.org wrote: As I can reproduce the failure I'll try to elaborate this a bit. Thanks Felix. Could you test the following patch [1]? It's just a blind guess but sets explicit encoding when reading and writing the schema files. Kind Regards, Stefan [1] http://pastebin.com/V254LbR7
