Re[4]: xerces and xalan in WEB-INF/lib is not good and needs to be changed....

Hi Christian,

See comments below...

Friday, January 17, 2003, 12:58:18 PM, you wrote:

CC> Hi Jake,

>> I still don't think that the Barracuda webapp should exist in
>> an auto-deploy directory specified by Tomcat.  It should exist
>> elsewhere

CC> I agree with this...

Cool!

>> and the build should install/reload/start/stop/remove/deploy/
>> undeploy itself from wherever it exists.  Driving all this using
>> the build's own Ant manager tasks provides finer grained control
>> over the server and you never have to shut down the server itself.

CC> ...and I would like to get to this, too (using the ccf.xml file, right?)

CC> But I'd like to wait for Shawn to get back before we actually do something,
CC> since he knows the server setup better than I do. He'll be back on Tuesday.
CC> So I'm not sure if we want to dive into it now, or wait until then and let
CC> him play catch-up...

CC> So in the meantime, do you have any resources (links) I could look at to
CC> come up to speed on how the ccf.xml stuff works? Or would it be easier just
CC> to look at your examples?

You can read about Context Configuration Files here:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html#Automatic%20Application%20Deployment

There really is no magic to it.  All it is is an XML file with the
root element being a <Context ....> element just like you might add
directly to the server.xml.  Tomcat, as of 4.1.x, can read these files
as adjuncts to the server.xml.

Now, the magic happens when using the Catalina Ant Manager tasks.  The
build does a filter copy of sample.ccf.xml filling in tokens for the
<Context> attributes "path" and "docBase".  The path is just the
app.name variable prefixed with a "/".  The docBase is simply the
system path to the root of the webapp WAR structure.  In Barracuda's
case, that is the root.dir variable.  Then, we also create a log file
which will be written to CATALINA_HOME/logs.  It simply provides for
an easy place to view context logging.

Of course, there are lots of other things that can be done such using
nested <Parameter> elements to allow one to override defaults for
<context-param> elements in the web.xml or adding a <Resource> for,
say..., JDBC connection pooling, etc...  Like I said, anything that
can be added to a <Context> element can be used in the Context
Configuration File.

Now, we have to remember that using the "catalina-install" target only
sets up the context in-memory.  If you shut down Tomcat and restart, the app is no
longer there.  This can be solved by using the catalina-deploy target.
This target forces Tomcat to physically modify the server.xml at
runtime so that it actually will exist there after server restarts.
However, you can always use the "catalina-undeploy" target which will
physically remove the context entry from the server.xml.
catalina-start, catalina-stop, and catalina-reload (in addition to
catalina-install and catalina-remove) are targets which will not cause
the server.xml to by modified.

Now, I still need to enable the catalina-deploy task by filter copying
sample.ccf.xml to META-INF/context.xml and then create a .war file.
Then, the .war file will be deployed.  Tomcat knows to look for the
file named "context.xml" in META-INF.  If it finds it, it uses it.  I
will try to do that this weekend.  BTW, where should I write the .war
file?

Jake

CC> Christian
CC> ----------------------------------------------
CC> Christian Cryder [[email protected]]
CC> Internet Architect, ATMReports.com
CC> Barracuda - http://barracudamvc.org
CC> ----------------------------------------------
CC> "Coffee? I could quit anytime, just not today"

>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]]On Behalf Of Jacob Kjome
>> Sent: Friday, January 17, 2003 10:54 AM
>> To: Christian Cryder
>> Subject: Re[2]: [Barracuda] xerces and xalan in WEB-INF/lib is not good
>> and needs to be changed....
>>
>>
>> Hello Christian,
>>
>> Friday, January 17, 2003, 10:32:41 AM, you wrote:
>>
>> CC> Ok, so I've updated the build.xml to NOT put xerces and xalan
>> jars in the
>> CC> WEB-INF/lib dir when the 'install' target is run.
>>
>> nice :-)
>>
>> CC> Per your comments on cleaning up the jars in /lib, I've added
>> that to the
>> CC> clean target. Note however that if Tomcat is running Ant may
>> not be able to
>> CC> delete these jars because Tomcat locks jars in the /lib dir...
>>
>> This shouldn't be much of an issue.  That is always true in any
>> build where you do a clean.  I still don't think that the
>> Barracuda webapp should exist in
>> an auto-deploy directory specified by Tomcat.  It should exist
>> elsewhere and the build should
>> install/reload/start/stop/remove/deploy/undeploy itself from wherever it
>> exists.  Driving all this using the build's own Ant manager tasks
>> provides finer grained control over the server and you never have
>> to shut down
>> the server itself.
>>
>> Instead of bouncing Tomcat for every modification, we should just be
>> running the builds catalina targets appropriately.  Tomcat itself
>> can be up
>> 100% of the time.  Only if you want to modify libs in Tomcat's library
>> folders or other Tomcat internals should there be a need to shutdown
>> Tomcat itself.  This avoids interruption of other apps on the server.
>>
>> What do you think?
>>
>> Jake
>>
>> _______________________________________________
>> Barracuda mailing list
>> [email protected]
>> http://barracudamvc.org/lists/listinfo/barracuda

CC> _______________________________________________
CC> Barracuda mailing list
CC> [email protected]
CC> http://barracudamvc.org/lists/listinfo/barracuda



-- 
Best regards,
 Jacob                            mailto:[email protected]