Hi guys, All done!
All installers are now working. :) However, I'm sometimes getting this error in the log (with the server running prefectly well...) [10:24:08] ERROR [org.apache.directory.server.Service] - Cannot start the server : reuseAddress can't be set while the acceptor is bound. Any idea what this could be ? Thanks, Pierre-Arnaud On 10 mars 2010, at 17:08, Pierre-Arnaud Marcelot wrote: > Hello guys, > > Good news! > > The following installers are fixed: > - Mac OS X > - Debian > - Windows > - Binary > - Archive > > I now need to test the two remaining ones: > - Solaris > - Fedora > > Regards, > Pierre-Arnaud > > > On 9 mars 2010, at 15:42, Pierre-Arnaud Marcelot wrote: > >> Hi again guys, >> >> Actually it seems the Tanuki issue is just a warning a we could let it like >> that (more testing needed). >> However, we won't be able to move to a newer version of Tanuki because its >> licensing have changed and it's now using GPLv2. >> The version we're currently using is the last one that shipped with a >> MIT-like license (compatible with our Apache License 2). >> It means that we won't be able to support natively 64 bit JVM on Mac OS X >> (but it might work well with the 32-bit version of the wrapper) >> >> So, the Tanuki wrapper is not cause of Apache DS failing to load correctly... >> Looking back at the wrapper logs, the last lines are the ones that matter: >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> STATUS | wrapper | 2010/03/09 11:24:38 | --> Wrapper Started as Console >>> [...] >>> INFO | jvm 1 | 2010/03/09 11:24:40 | Error in WrapperListener.start >>> callback. java.lang.NullPointerException >>> INFO | jvm 1 | 2010/03/09 11:24:40 | java.lang.NullPointerException >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> java.io.File.<init>(File.java:222) >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> org.apache.directory.daemon.Bootstrapper.setInstallationLayout(Bootstrapper.java:83) >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> org.apache.directory.daemon.TanukiBootstrapper.start(TanukiBootstrapper.java:52) >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788) >>> STATUS | wrapper | 2010/03/09 11:24:41 | <-- Wrapper Stopped >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> >> >> There's a NPE in the Bootstrapper class at line 83: >>> File instanceHome = new File( System.getProperty( "INSTANCE_HOME" ) ); >> >> >> It looks like the INSTANCE_HOME system property is null. >> This system property as been added and the code of the Bootstrapper class >> has been modified after the last release (1.5.5) in order to support the >> multiple instances Installation Layout. >> Now, we have problem with this because the same name is already used in >> various installers to represent the instances home directory (where >> instances reside). >> This property should be set by the wrapper (even if it's in a wrong context >> and with a wrong value) when launching the server with the following command >> line call: >>> "/usr/local/apacheds-1.5.6-SNAPSHOT/bin/apacheds" >>> "/usr/local/apacheds-1.5.6-SNAPSHOT/conf/apacheds.conf" >>> set.INSTANCE_HOME=/usr/local/apacheds-1.5.6-SNAPSHOT/instances >>> set.INSTANCE=default wrapper.syslog.ident=apacheds >>> wrapper.pidfile="/usr/local/apacheds-1.5.6-SNAPSHOT/instances/default/default.pid" >>> wrapper.daemonize=TRUE >> >> >> However, what we get in the Bootstrapper for this property is null and thus >> the NPE. >> >> I'm currently trying to understand why this value could be null... >> >> >> I'm afraid that most of our installers are broken due to this issue. >> At least those using the wrapper. >> Other installers directly launching the server from java like the archive >> installers seem fine... >> >> Until this issue is fixed, Apache DS can't be released... :( >> >> Regards, >> Pierre-Arnaud >> >> On 9 mars 2010, at 11:41, Pierre-Arnaud Marcelot wrote: >> >>> Hi Guys, >>> >>> I'm currently reviewing the installers before the release. >>> >>> I just found that our Mac OS X installer is broken on Snow Leopard systems. >>> On these systems, the JVM is 64-bit while the wrapper binary we use is >>> still a 32-bit one. >>> >>> Launching the server ends with an error: >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> STATUS | wrapper | 2010/03/09 11:24:38 | --> Wrapper Started as Console >>> STATUS | wrapper | 2010/03/09 11:24:39 | Launching a JVM... >>> INFO | jvm 1 | 2010/03/09 11:24:40 | Wrapper (Version 3.2.3) >>> http://wrapper.tanukisoftware.org >>> INFO | jvm 1 | 2010/03/09 11:24:40 | Copyright 1999-2006 Tanuki >>> Software, Inc. All Rights Reserved. >>> INFO | jvm 1 | 2010/03/09 11:24:40 | >>> INFO | jvm 1 | 2010/03/09 11:24:40 | >>> INFO | jvm 1 | 2010/03/09 11:24:40 | WARNING - Unable to load the >>> Wrapper's native library 'libwrapper.jnilib'. >>> INFO | jvm 1 | 2010/03/09 11:24:40 | The file is located on >>> the path at the following location but >>> INFO | jvm 1 | 2010/03/09 11:24:40 | could not be loaded: >>> INFO | jvm 1 | 2010/03/09 11:24:40 | >>> /usr/local/apacheds-1.5.6-SNAPSHOT/bin/../lib/libwrapper.jnilib >>> INFO | jvm 1 | 2010/03/09 11:24:40 | Please verify that the >>> file is readable by the current user >>> INFO | jvm 1 | 2010/03/09 11:24:40 | and that the file has >>> not been corrupted in any way. >>> INFO | jvm 1 | 2010/03/09 11:24:40 | One common cause of >>> this problem is running a 32-bit version >>> INFO | jvm 1 | 2010/03/09 11:24:40 | of the Wrapper with a >>> 64-bit version of Java, or vica versa. >>> INFO | jvm 1 | 2010/03/09 11:24:40 | This is a 64-bit JVM. >>> INFO | jvm 1 | 2010/03/09 11:24:40 | Reported cause: >>> INFO | jvm 1 | 2010/03/09 11:24:40 | >>> /usr/local/apacheds-1.5.6-SNAPSHOT/lib/libwrapper.jnilib: no suitable >>> image found. Did find: >>> /usr/local/apacheds-1.5.6-SNAPSHOT/lib/libwrapper.jnilib: no matching >>> architecture in universal wrapper >>> INFO | jvm 1 | 2010/03/09 11:24:40 | System signals will not >>> be handled correctly. >>> INFO | jvm 1 | 2010/03/09 11:24:40 | >>> INFO | jvm 1 | 2010/03/09 11:24:40 | Error in WrapperListener.start >>> callback. java.lang.NullPointerException >>> INFO | jvm 1 | 2010/03/09 11:24:40 | java.lang.NullPointerException >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> java.io.File.<init>(File.java:222) >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> org.apache.directory.daemon.Bootstrapper.setInstallationLayout(Bootstrapper.java:83) >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> org.apache.directory.daemon.TanukiBootstrapper.start(TanukiBootstrapper.java:52) >>> INFO | jvm 1 | 2010/03/09 11:24:40 | at >>> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788) >>> STATUS | wrapper | 2010/03/09 11:24:41 | <-- Wrapper Stopped >>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>> >>> This will require that we provide two types of installer for Mac OS X: >>> - one for 32-bit JVMs >>> - one for 64-bit JVMs >>> >>> And more importantly this will force us to move to a newer version of the >>> Tanuki Wrapper because a 64-bit version of the wrapper for Mac OS X does >>> not exist for the 3.2.3 version we're using. >>> Now, I remember there has been some problems with Tanuki's licensing when >>> they changed it a couple of years ago I think... >>> Does anyone know if their Community editor is compatible with the Apache >>> License ? >>> >>> Thanks, >>> Pierre-Arnaud >>> >>> >>> On 8 mars 2010, at 09:32, Alex Karasulu wrote: >>> >>>> Yeap this search performance issue will make this release useless. >>>> >>>> On Sun, Mar 7, 2010 at 9:37 PM, Emmanuel Lecharny <[email protected]> >>>> wrote: >>>>> On 3/7/10 8:21 PM, Stefan Seelmann wrote: >>>>>> >>>>>> Emmanuel Lecharny schrieb: >>>>>>> >>>>>>> On 3/7/10 12:33 PM, Stefan Seelmann wrote: >>>>>>>> >>>>>>>> I built the installers and tested the zip archive. When starting the >>>>>>>> server I get lot of warn logs [1]: >>>>>>>> - "setting the schema manager for partition...". I think those are only >>>>>>>> info messages so should be logged in info log level. >>>>>>>> - "Cannot normalize the value". Are that serious issues? If not we >>>>>>>> should change the logging. I'm sure some users will complain and ask >>>>>>>> on the >>>>>>>> mailing list what that output means. >>>>>>> >>>>>>> I will investigate thse two issues. At first sight, it seems tat the >>>>>>> first one is clearly DEBUG or INFO logs wrongly using WARN level. >>>>>>> >>>>>> I will hold the vote once again. Beside the mentioned issues there is >>>>>> also >>>>>> a serious search performance problem. >>>>> >>>>> I agree. I'm also fixing some logs issues we have. >>>>> >>>>> Sorry, Kiran, not your fault :/ >>>>> >>>>> -- >>>>> Regards, >>>>> Cordialement, >>>>> Emmanuel Lécharny >>>>> www.nextury.com >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Alex Karasulu >>>> My Blog :: http://www.jroller.com/akarasulu/ >>>> Apache Directory Server :: http://directory.apache.org >>>> Apache MINA :: http://mina.apache.org >>> >> >
