archiva-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak (JIRA)" <j...@codehaus.org>
Subject [jira] Reopened: (MRM-545) Documentation for configuring for Tomcat is invalid
Date Thu, 27 Dec 2007 14:33:57 GMT

     [ 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

        

Mime
View raw message