| Bastiaan Bakker (JIRA) 2006-09-29, 7:11 am |
| [ http://issues.apache.org/jira/brows...action_12438683 ]
Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------
I see there are some issues, both in the patch itself and in combination with 1.0 trunk:
* spec file misses "Requires: java-devel" (needed for tools.jar)
* log4j.properies defines a rolling file appender that tries to write in installbasedir instead of installbasedir/var/log. But preferably I'd modify log4j.properties to log to syslog.
If java-devel is installed the issues above don't prevent starting the service with the RPM I created from a patched 1.0-RC4 release.
With 1.0 trunk however I get a NoClassDefFoundException:
java.lang.reflect.InvocationTargetException
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:585)
at org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:160)
Caused by: java.lang.NoClassDefFoundError: edu/emory/mathcs/backport/java/util/concurrent/BlockingQueue
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at org.apache.directory.server.Service.class$(Service.java:51)
at org.apache.directory.server.Service.init(Service.java:88)
at org.apache.directory.daemon.Bootstrapper.callInit(Bootstrapper.java:151)
at org.apache.directory.daemon.JsvcBootstrapper.init(JsvcBootstrapper.java:56)
... 5 more
29/09/2006 12:05:22 5807 jsvc.exec error: Cannot load daemon
29/09/2006 12:05:22 5806 jsvc.exec error: Service exit with a return value of 3
Is this the problem you're refering to? Also could you please describe your test platform and output. OS release, JDK version and package RPM (jpackage or SUN, etc)?
I'll see if I can fix the NoClassDefFound issue. It appears to be a regression from RC4 though and not something introduced by the RPM patch, so it could have affected some of the other install methods as well.
Another mostly harmless issue is the incorrect installation check in BootStrapper:
[12:05:21] ERROR [org.apache.directory.daemon.Bootstrapper] - Installation verification failure!
java.lang.IllegalStateException: /opt/apacheds is write protected from the current user: apacheds
Doesn't prevent apacheds from running but is confusing to end users.
> fix issues with apacheds RPM to get it working out of the box
> -------------------------------------------------------------
>
> Key: DIRSERVER-749
> URL: http://issues.apache.org/jira/browse/DIRSERVER-749
> Project: Directory ApacheDS
> Issue Type: Improvement
> Components: installer-plugin
> Affects Versions: 1.0-RC4
> Environment: linux
> Reporter: Bastiaan Bakker
> Assigned To: Alex Karasulu
> Fix For: 1.1.0, 1.0
>
> Attachments: apacheds-branch-1.0-server-installers-rpmfix.patch, apacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of the box:
> * the init script fails to run because APACHEDS_USER is set to $USER, which is not defined at boot time
> * the init script fails to run bevause JAVA_HOME is not defined
> * the init script it is not registered to the init subsystem with chkconfig or similar
> * the config files are not marked as such, causing them to be silently overwritten when one upgrades the RPM
> * the RPM filename is not conform conventions: ${name}-${version}-${release}.${arch}.rpm
> * the location of the files (/usr/local/apacheds-1.0_RC4) is version dependent, making upgrades cumbsome. The admin has to relocate the partitions and config files on every updgrade.
> * the sources and docs are included in the rpm, even though they are not necessary for operation.
> The RPM build mechanism for apacheds also has some issues:
> * runs rpmbuild as root, which is frowned upon by RPM gurus for security and safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbuild --rebuild' with it.
> * the sudo mechanism is totally unnecessary
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|