[ http://issues.apache.org/jira/brows...243
8683 ]

Bastiaan Bakker commented on DIRSERVER-749:
-------------------------------------------

I see there are some issues, both in the patch itself and in combination wit
h 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 ins
tallbasedir instead of installbasedir/var/log. But preferably I'd modify log
4j.properties to log to syslog.

If java-devel is installed the issues above don't prevent starting the servi
ce 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(DelegatingMethodAccessorI
mpl.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/ut
il/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:5
6)
.. 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 o
f 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 regressi
on from RC4 though and not something introduced by the RPM patch, so it coul
d have affected some of the other install methods as well.

Another mostly harmless issue is the incorrect installation check in BootStr
apper:
[12:05:21] ERROR [org.apache.directory.daemon.Bootstrapper] - Instal
lation verification failure!
java.lang.IllegalStateException: /opt/apacheds is write protected from the c
urrent 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, a
pacheds-daemon-trunk-rpmfix.patch
>
>
> The apacheds RPM has several issues that prevent it from running out of th
e box:
> * the init script fails to run because APACHEDS_USER is set to $USER, whic
h 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 chkconfi
g or similar
> * the config files are not marked as such, causing them to be silently ove
rwritten 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 depen
dent, 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 n
ecessary 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 a
nd safety reasons.
> * the generated src.rpm is not self contained, ie. one cannot do a 'rpmbui
ld --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://iss
ues.apache.org/ji...nistrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]