Return-Path: 
 <users-return-58087-apmail-cocoon-users-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-users-archive@www.apache.org
Received: (qmail 29825 invoked from network); 7 Nov 2003 01:39:45 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 7 Nov 2003 01:39:45 -0000
Received: (qmail 64735 invoked by uid 500); 7 Nov 2003 01:39:21 -0000
Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org
Received: (qmail 64517 invoked by uid 500); 7 Nov 2003 01:39:20 -0000
Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:users-help@cocoon.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@cocoon.apache.org>
list-post: <mailto:users@cocoon.apache.org>
Reply-To: users@cocoon.apache.org
Delivered-To: mailing list users@cocoon.apache.org
Received: (qmail 64504 invoked from network); 7 Nov 2003 01:39:19 -0000
Received: from unknown (HELO email02.aon.at) (195.3.96.94)
  by daedalus.apache.org with SMTP; 7 Nov 2003 01:39:19 -0000
Received: (qmail 415972 invoked from network); 7 Nov 2003 01:39:26 -0000
Received: from n608p018.dipool.highway.telekom.at (HELO gmx.at)
 ([212.183.85.242]) (envelope-sender <alasan@gmx.at>)
          by qmail2rs.highway.telekom.at (qmail-ldap-1.03) with SMTP
          for <users@cocoon.apache.org>; 7 Nov 2003 01:39:26 -0000
Message-ID: <3FAAF7CD.3080208@gmx.at>
Date: Fri, 07 Nov 2003 02:39:25 +0100
From: Alexander Schatten <alasan@gmx.at>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: de-at, en-gb, en-us, en
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Impossible CLI??
References: <009c01c3a40b$fd5ef480$0100007f@dallas.sil.org>
 <3FA9F7EC.20402@upaya.co.uk>
In-Reply-To: <3FA9F7EC.20402@upaya.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Again thank you for answers, I have still not advanced for one 
millimeter, though again trying for some long time...

the details:


Upayavira wrote:

>>
> I believe this (<uri>) is now fixed in CVS. <uris> is a new feature 
> that allows you to process groups of uris, having independant options 
> with each group, e.g. one that follows links, and one that doesn't. 
> You can also describe a link with name="xxx" and then do cocoon cli 
> -xconf cli.xconf -n xxx (I think it's -n) which will only process URIs 
> in your <uris name="xxx"> set.
>
> I think I've updated the docs in CVS, so if you're using CVS cocoon, 
> but looking at the online docs, you'll not see these doc changes.

all right; so I thought I start from scratch:

(1) I got the most recent cvs version from cocoon: 2.1.3-dev;

(2) installed it with jetty and added my webapp "cocoon-day"

(3) it works in "normal" cocoon mode fine as ever.

(4) I tried to fix the things you mentioned, see below:

>
>>> (2) I also tried to use only command line options, however; I hardly 
>>> understand what the uri concept and parameters...?!
>>>   
>>
> Can you say more about what you don't understand? If you don't 
> understand it, maybe others don't and thus we need to improve the docs.

there are so many confusing things; I just know wget for example: I use 
an URL there, and it gets the files; recursively or not; I assume 
similar functionality from cocoon: but there is:

   <!--+
       |  Specifies a user agent string to the sitemap when
       |  generating the site.
       +-->
   <!--
   <user-agent>xxx</user-agent>
   -->

   <!--+
       |  Specifies an accept string to the sitemap when generating
       |  the site.
       +-->
   <accept>*/*</accept>


what is an "user agent"???

why would I want to send an "accept" string to the sitemap?? what should 
this mean? I provide an URL later on, so what is this for??

   <include pattern="**"/>
   <exclude pattern="docs/apidocs/**"/>

whats this again? the three things I copied from the cli.xconf simply 
make no sense for me. again: I provide an URL or more then one URL later 
on; so what should these "filters" be good for? no idea

then:

<uri type="replace" 
        src-prefix="samples/" 
        src="hello-world/hello.html"
        dest="build/dest/hello-world.html"/>


o.k. this is lets say 50% clear to me: but why the separation to 
src-prefix and src? what does the type really mean 
(append/insert/replace)? no idea yet.

maybe it would become clearer, when I could try my example which is 
unfortunately still not running.



>
>>> (3) I came so far with e.g. the code below the line (and the same 
>>> result with commanline options), that cocoon cli starts, but with 
>>> the exceptions:
>>>
>>> "Cannot find CatalogManager.properties"
>>>   
>>
> Fixed in CVS I believe.

yes, but other problems occur, see below

>>>
>>> "Opening database: 
>>> /usr/java/jakarta-tomcat-5.0.9/webapps/cocoon/WEB-INF/db/cocoondb
>>> HSQLDB server 1.7.1 is running
>>> Use SHUTDOWN to close normally. Use [Ctrl]+[C] to abort abruptly"
>>>   
>>
> That's because your Cocoon has the HSQLDB block compiled in. I use the 
> CLI with only minimal blocks compiled, which is advisable.

o.k. I tried to compile cocoon with "minimal" blocks. the problem here 
again: no idea which blocks I could leave away. I played around for some 
time; dependency problems occured... finally after some hours I gave up, 
because compilation always takes between 5 and 20 minutes (aaaarrg, why 
is there no binary distribution, how came to this idea???)

finally I decided to simply exclude the hsqldb, and at least this hsqldb 
matter is not occuring again.

>>>   
>>
> What version of Cocoon are you running?
>
> Are you able to rebuild with less blocks?

see above.

>


o.k. to the last unsuccessful steps now:

(5) I use the cli.xconf in the cocoon distribution, I only added my url 
to the file and leave everything else the same

<uri type="replace"
        src-prefix="cocoon-day/"
        src="index.html"
        dest="build/dest/index.html"/>

{ (5b) btw. I also tried it with some other config file I used recently, 
both times the same result: }

(6) ./cocoon.sh cli -x cli.xconf

(7) result is:

Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at Loader.invokeMain(Unknown Source)
        at Loader.run(Unknown Source)
        at Loader.main(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: 
javax/servlet/http/HttpSessionBindingListener
... and so on


I find nothing like a "Binding Listener" in the build.properties, at 
least *I* did not find it.

So again no more ideas on my side.

What I do not understand is, why not even the cli delivered with cocoon 
works with the cocoon samples in the default installation (I only 
removed hsqldb); I believe, that this is really not "optimal". I think 
the cli is really complex enough and it would be advantageous if at 
least the delivered example would work...


thank you for further comments...


best regards


alex


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org