> -----Original Message-----
> From: Ed Nixon [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 02, 2001 10:06 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [Proposal] C2 + tomcat 4
> 
> 
> Comments below...
> 
> At 09:41 AM 02/10/2001 -0400, Vadim Gritsenko wrote:
> > > From: Alfredas Chmieliauskas [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, October 02, 2001 8:29 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [Proposal] C2 + tomcat 4
> > >
> > >
> > > Hello,
> > > It seems that c2 + tomcat4 is the most problematic issue for a couple 
> > of weeks already
> > > (while it is one of the most used configurations). I myself had a hard 
> > time installing
> > > it due to sitemap_xmap.java did not re-compile, well whatever.
> >
> >The funny thing that it's the most easiest combination, comparing to 
> >Tomcat 3.x,
> >Resin, etc. The only thing you need to do is:
> >  - do not use JDK1.4,
> >  - do not use CLASSPATH
> >  - do not use /ext/ libraries
> 
> Two points (or some might think quibbles) about your advice:
> 1. If true, this information is not well documented... anywhere. To my 
> knowledge at least.
> 2. I'm not exactly sure what you mean or imply by "do not use CLASSPATH" 

Ok, I meant here that if you do have in classpath some libraries during build time,
and Cocoon will not have access to them in run time (under Tomcat that's usual thing - 
it 
ignores system classpath). That leads to different compile-time and run-time 
configurations
and ClassNotFound exceptions.
The easiest solution is to use empty CLASSPATH variable, and if you need to use
some extra libraries, just put them into cocoon/lib before building the WAR file
(and ant will put them under WEB-INF/lib).
This problem was first described here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100142275118290&w=2

> but in general it seems like a totally unrealistic constraint to put on an 
> installation or operating process. CLASSPATH, whether system or user (in 
> the Win2K world) is a basic functionality of Java. Some systems explicitly 
> require certain flavors of CLASSPATH to permit functioning.

PS: Never used system- or user- wide classpath. Do set it as required by
certain server (or application).

Vadim


> 
> The only justification for the problems we've had that I can think of is 
> that Cocoon is not release level software yet. You're going to be a little 
> more forgiving of a problem under those conditions. However, we are now in 
> RC phase and I'd be more comfortable if I thought there was a definitive 
> explanation and solution to these chimerical problems. One of my concerns 
> has to do with subtle and not so subtle dependencies of Cocoon on the 
> Apache/Tomcat way of doing things. It doesn't take to much carelessness or 
> myopia to build Sun and/or Tomcat dependencies into Cocoon similar to those 
> being discovered in Velocity for example.
> 
> Your experience differs from a significant number of others.
> 
>                ...edN
> 
> 
> 
> 
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
> 

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Reply via email to