[jira] Reopened: (MRM-545) Documentation for configuring for Tomcat is invalid

["Wendy Smoak (JIRA)" <ji...@codehaus.org>]

     [ http://jira.codehaus.org/browse/MRM-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wendy Smoak reopened MRM-545:
-----------------------------

      Assignee:     (was: Brett Porter)

> Documentation for configuring for Tomcat is invalid
> ---------------------------------------------------
>
>                 Key: MRM-545
>                 URL: http://jira.codehaus.org/browse/MRM-545
>             Project: Archiva
>          Issue Type: Bug
>          Components: documentation
>    Affects Versions: 1.0-beta-2
>         Environment: Windows XP, Tomcat-5.5.17/Tomcat-5.5.20, JDK-1.5.0_06
>            Reporter: William Ferguson
>            Priority: Critical
>             Fix For: 1.0
>
>         Attachments: bad-log-filename.log, mail-auth-class-not-found.log
>
>
> Following http://maven.apache.org/archiva/guides/getting-started.html for Tomcat didn't get me started.
> I'll go through it point by point
> # Create a directory in tomcat called archiva, at the same level as bin, conf, logs and the others.
> # Copy the war file from apps/archiva/lib into the new directory
> There is not apps/archiva/lib in the 1.0-beta-2 distribution. 
> apps contains a single file : archiva-plexus-application-1.0-beta-2.jar which does itself contain a war file, so I extracted that file and copied it to the TOMCAT_HOME/archiva folder.
> NB IMHO modifying TOMCAT in this manner smells all wrong.
> # Create a conf/Catalina/localhost/archiva.xml file with the following data: yadda, yadda
> The docBase attribute refers to archiva-webapp-1.0-SNAPSHOT.war instead of archiva-webapp-1.0-beta-2.war
> No idea why a javax.mail.Session needs to be configured here, haven't seen any documentation in Archiva that suggests it send, receives email. But this was a slight pain when configuring for Tomcat-5.5.20 as I needed to follow the extra steps for the missing classes. If the MailSession is not required it would be better to avoid this pain by simplifying the config.
> Again modifying TOMCAT like this does not feel right. Surely this config could be contained within the webapp.
> # Copy $HOME/.m2/org/apache/derby/derby/10.1.3.1/derby-10.1.3.1.jar (or from the remote repository) into the Tomcat common/lib
> I am *really* against  this as I have now introduced Derby-10.1.3.1 into the classpath of 8all* my other applications running on that Tomcat instance. Surely this library could be packaged up into the webapp. 
> # To deal with a current bug, you'll also need to add the following to your $catalina.home/conf/web.xml in the relevant section (search for jspx):
> Again, surely this could be included in the config for the Archiva webapp instead of introduced into Tomcat generally. This heavy handed approach makes maintenance difficult, eg upgrading to a new version of Tomcat is now extremely onerous.
> OK,  so having followed the instructions above, when I try to startup Tomcat the first thin I get is a failure with the logging sub system. see attached bad-log-filename.log. I believe this is due to the fact that ${appserver.base} in log4j.xml has never been set:
> {code}
>     <param name="file" value="${appserver.base}/logs/archiva.log" />
> {code}
> Next, it fails as it can't find javax.mail.Authenticator (this is Tomcat-5.5.17).
> NB I never saw any indication that "schema SA does not exist" as the final note suggests. But perhaps this was because Archiva never got that far. Certainly no application is available at http://localhost:8080/archiva/
> Anyway, by this stage I became discouraged enough that I gave up.
> Its a shame really as I would have liked to be able to compare Archiva against Proximity and Artifactory, both of which I managed to get setup in under 10 mins including vastly restructuring the default repository config that they ship with.
> Brett, hope that helps.
> Further notes:
> I really don't like modifying the contents of TOMCAT_HOME other than to deploy a WAR to TOMCAT_HOME/webapps.
> And the infrastructure team weren't impressed either and its makes maintenance high cost.
> Better to keep all config solely within the confines of the webapp or use a environment variable to declare a separate proxy_home where all the config is contained (like Artifactory does).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira