Currently, the cactus ant task runs Tomcat (confirmed using a browser) with
custom server.xml and merged web.xml, but the cactus client side operation
cannot find the servlet it needs in order to confirm the container is up,
and reports that it is down.
I'm fairly certain that the following duff config is responsible, but am not
sure what the best way to fix it is:
<Context
className="org.apache.catalina.core.StandardContext"
cachingAllowed="true"
charsetMapperClass="org.apache.catalina.util.CharsetMapper"
cookies="true"
crossContext="false"
debug="0"
displayName="Reporting Application"
docBase="C:\Program Files\Apache Group\Tomcat
4.1\webapps\reportingapp"
mapperClass="org.apache.catalina.core.StandardContextMapper"
path="/reportingapp"
privileged="false"
reloadable="false"
swallowOutput="false"
useNaming="true"
wrapperClass="org.apache.catalina.core.StandardWrapper" >
This is adapted from the Tomcat default options (when set up as an NT
Service), and continues to set up the JNDI resources I wish to reference in
my tests. As you can see it also references the development server set up on
my PC, the dev server of course doesn't have the cactified WAR built by Ant.
I see that I need to point docbase to cactus' self-installing tomcat
instance, or live without the Context and find a better method of setting up
my JNDI resources. Alternatively I could unit test on the dev server, but I
understand this is a Bad Thing.
What I'm missing is a detailed way to acheive something acceptable in terms
of best practice and which can reference my database via JNDI.
Suggestions and examples appreciated.
Simon Gibbs
Project Support
* 07866 741 461 * x5849
* [EMAIL PROTECTED]
* http://www.simongibbs.co.uk/
--
IMPORTANT
The contents of this email (and any attachment):
(1) are confidential and may be legally privileged - if it is not meant for
you, please tell the sender, do not forward or copy the contents
and delete it from your system immediately;
(2) come from its author and may not necessarily reflect the opinions
of Virgin Mobile.
While emails and attachments are virus checked,
we cannot accept any liability in respect of any viruses.
We may monitor emails sent to Virgin Mobile.
Want to know more about Virgin Mobile?
Visit our website for the latest info, phones and special offers
http://www.virgin.com/mobile
Virgin Mobile Telecoms Ltd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
