You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Alexander Schatten <al...@gmx.at> on 2003/11/05 19:33:47 UTC
Impossible CLI??
So, I am playing around for hours now, to get the CLI running to produce
an example for a demonstration... seems to be, that I am far too stupid
to understand the documentation:
(1) I tried using a config file; then I detected, that there seem to be
various modifications of the syntax: the example on the cocoon 2.1
website does not work with my Cocoon 2.1 version, e.g. <uris> is not
known... on the wiki there is an older documentation, which "works"
without exception about not knowing certain elements.
(2) I also tried to use only command line options, however; I hardly
understand what the uri concept and parameters...?!
(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"
??? and
"server.properties not found, using command line or default properties"
then comes:
"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"
and thats it; it does nothing but create two files in the work directory
and waits until I terminate hsqldb with Ctrl C.
to be honest, I have no more ideas what to do?
thank you for help!
Alex
_____________________________________________________________________________________
./cocoon.sh cli -x /home/aschatt/test/cocoonday/cli2.conf
the cli2.conf file looks like this (comments removed):
<?xml version="1.0"?>
<cocoon verbose="true"
follow-links="true"
precompile-only="false"
confirm-extensions="false">
<broken-links type="xml"
file="brokenlinks.xml"
generate="false"
extension=".error"/>
<logging
log-kit="/home/aschatt/tomcat5/webapps/cocoon/WEB-INF/logkit.xconf"
logger="cli" level="ERROR" />
<context-dir>/home/aschatt/tomcat5/webapps/cocoon</context-dir>
<config-file>/home/aschatt/tomcat5/webapps/cocoon/WEB-INF/cocoon.xconf</config-file>
<work-dir>/home/aschatt/test/cocoonday/work</work-dir>
<dest-dir>/home/aschatt/test/cocoonday/dest</dest-dir>
<default-filename>index.html</default-filename>
<accept>*/*</accept>
<uri type="append"
src-prefix="cocoon-day/"
src="index.html"
dest="cocoon-day"/>
</cocoon>
p.s.: I tried various combinations in the <uri> element, no one working.
the website is on:
http://localhost:8080/cocoon/cocoon-day/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Alexander Schatten <al...@gmx.at>.
Upayavira wrote:
> Okay, you're getting somewhere. Can you update to the latest CVS? I
> fixed this default-encoding problem today.
>
> The /styles/main.css is showing because you got an error. At some
> point I'll fix it so that links don't get followed on error pages. So
> many things to do :-(
>
> Update to latest CVS and retry and I think you could be there.
>
thank you; but no chance today; I have only ISDN here; so I have to wait
until monday; then I will start the next try...
have a good weekend
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Upayavira <uv...@upaya.co.uk>.
Okay, you're getting somewhere. Can you update to the latest CVS? I
fixed this default-encoding problem today.
The /styles/main.css is showing because you got an error. At some point
I'll fix it so that links don't get followed on error pages. So many
things to do :-(
Update to latest CVS and retry and I think you could be there.
Regards, Upayavira
Alexander Schatten wrote:
> Upayavira wrote:
>
>> You have included a block that needs the servlet.jar. Copy
>> servletX_X.jar into WEB-INF/lib and you'll get past that one.
>>
>> Thanks also for the doc suggestion. It looks good. I'll include it
>> within the default cli.xconf.
>
>
>
> I am glad if it is helpful
>
>
> so then again; I really have a guilty conscience, but the next error
> occured:
>
> at least, it looks as if cocoon is now working, but the result is:
>
> ^ /styles/main.css
> ^ /scripts/main.js
> X [0] cocoon-day/index.html
> BROKEN: Unable to resolve context key: default-encoding
> ^ /styles/main.css
> X [0]
> samples/hello-world/hello.html BROKEN: Unable to resolve
> context key: default-encoding
> Total time: 0 minutes 13 seconds, Site size: 0 Site pages: 0
>
>
> Could this be an encoding problem? I use btw. iso-8859-1
>
>
> the cli.xconf uri entry is the following:
>
> <uri type="replace"
> src-prefix="cocoon-day/"
> src="index.html"
> dest="build/dest/index.html"/>
>
>
> and in the servlet mode it is working with:
>
> localhost.../cocoon/cocoon-day/index.html
>
>
> I am again grateful for suggestions!
>
>
> alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Alexander Schatten <al...@gmx.at>.
Upayavira wrote:
> You have included a block that needs the servlet.jar. Copy
> servletX_X.jar into WEB-INF/lib and you'll get past that one.
>
> Thanks also for the doc suggestion. It looks good. I'll include it
> within the default cli.xconf.
I am glad if it is helpful
so then again; I really have a guilty conscience, but the next error
occured:
at least, it looks as if cocoon is now working, but the result is:
^ /styles/main.css
^ /scripts/main.js
X [0] cocoon-day/index.html BROKEN:
Unable to resolve context key: default-encoding
^ /styles/main.css
X [0]
samples/hello-world/hello.html BROKEN: Unable to resolve context
key: default-encoding
Total time: 0 minutes 13 seconds, Site size: 0 Site pages: 0
Could this be an encoding problem? I use btw. iso-8859-1
the cli.xconf uri entry is the following:
<uri type="replace"
src-prefix="cocoon-day/"
src="index.html"
dest="build/dest/index.html"/>
and in the servlet mode it is working with:
localhost.../cocoon/cocoon-day/index.html
I am again grateful for suggestions!
alex
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Upayavira <uv...@upaya.co.uk>.
You have included a block that needs the servlet.jar. Copy
servletX_X.jar into WEB-INF/lib and you'll get past that one.
Thanks also for the doc suggestion. It looks good. I'll include it
within the default cli.xconf.
Regards, Upayavira
Alexander Schatten wrote:
> So next iteration,
>
> again a new exception...
>
>
> Upayavira wrote:
>
>>> (3) it works in "normal" cocoon mode fine as ever.
>>
>>
>>
>> As a servlet, you mean?
>
>
> yes, precisely.
>
>>
>> t's hope so, or maybe the docs could be extended. - the person who
>> knows something best isn't always the best person to write user docs!
>
>
> so, as a naive user, I tried to add some clarifications to the
> documentation; please be so kind and look at the file in the
> attachment, hopefully this is useful for you (it contains a part of
> the cli.xconf).
>
>
>>
>>
>> Just remove all blocks, and add them back as you need them.
>
>
> I removed the authentication now, and all "unstable blocks". (If it is
> helpful, I could also send my build.properties)
>
>
> so, now I can provide again a new exception:
>
> 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/ServletConfig
>
>
>
> (to be honest, I would have given up already since yesterday; but we
> have the cocoon-day in austria, with one complete day of cocoon
> tutorials, and I really would want to present the resulta of the
> "offline-cocoon"... but Cocoon currently tries to do everything to
> avoid my presentation *g*)
>
>
> Alex
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Alexander Schatten <al...@gmx.at>.
So next iteration,
again a new exception...
Upayavira wrote:
>> (3) it works in "normal" cocoon mode fine as ever.
>
>
> As a servlet, you mean?
yes, precisely.
>
> t's hope so, or maybe the docs could be extended. - the person who
> knows something best isn't always the best person to write user docs!
so, as a naive user, I tried to add some clarifications to the
documentation; please be so kind and look at the file in the attachment,
hopefully this is useful for you (it contains a part of the cli.xconf).
>
>
> Just remove all blocks, and add them back as you need them.
I removed the authentication now, and all "unstable blocks". (If it is
helpful, I could also send my build.properties)
so, now I can provide again a new exception:
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/ServletConfig
(to be honest, I would have given up already since yesterday; but we
have the cocoon-day in austria, with one complete day of cocoon
tutorials, and I really would want to present the resulta of the
"offline-cocoon"... but Cocoon currently tries to do everything to avoid
my presentation *g*)
Alex
Re: Impossible CLI??
Posted by Upayavira <uv...@upaya.co.uk>.
Alexander Schatten wrote:
> 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.
As a servlet, you mean?
> (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"???
These options will almost certainly be there in wget too, and they're
optional. A browser is a User agent, and browsers tell the server what
browser they are using a 'user agent' string. This is what is referred
to here.
Accepts tells the server (Cocoon here) what the user agent can accept,
e.g. your Cocoon site could serve jpg by default, but if an accept
string includes image/png, then it serves png instead, all transparent
to the user. Again, you can just accept the default.
> 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??
Because you might have configured your sitemap to select or match upon
the accept string. But most people don't.
> <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
Because, if you follow links, you might not want all links to be
followed. This allows you to specify exactly when they are followed and
when not.
> 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.
The src-prefix isn't included in the URI of the file that is written to
disk, whereas the src is. Actually, in the example above, because the
type is replace, the src-prefix isn't needed. This could equally be
achieved with src-prefix="" src="samples/hello-world/hello.html"
> maybe it would become clearer, when I could try my example which is
> unfortunately still not running.
Let's hope so, or maybe the docs could be extended. - the person who
knows something best isn't always the best person to write user docs!
>>>> (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???)
Just remove all blocks, and add them back as you need them.
> finally I decided to simply exclude the hsqldb, and at least this
> hsqldb matter is not occuring again.
Good.
>> 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
Hmm. I've just updated to the current CVS, and now I'm getting the same.
Don't know what that is. I'll look into it.
>
>
> 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...
I agree - see my reply to your other email. Unfortunately, it seems that
some changes to other parts of Cocoon have broken the CLI, which is not
good.
Regards, Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Alexander Schatten <al...@gmx.at>.
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
Re: Impossible CLI??
Posted by Geoff Howard <co...@leverageweb.com>.
Upayavira wrote:
> Lars Huttar wrote:
>
>>> "Cannot find CatalogManager.properties"
>>>
>>> ??? and
>>>
>>> "server.properties not found, using command line or default properties"
>>
Isn't this the message Jetty spits out when you don't specify startup
properties? At the
least, it's spit out in the console when doing cocoon.sh servlet. I
guess it could be coming
from a block.
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Impossible CLI??
Posted by Lars Huttar <la...@sil.org>.
>
> Lars, this list is really useful. Would you be willing to add
> it to the
> CommandLine wiki page? Really, I think the web site docs
> should be the
> formal "this is what the <uris> node means" docs, but there
> is a really
> big place for this kind of "this works for me" docs too, on the Wiki.
Sure. I'll do that soon.
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Upayavira <uv...@upaya.co.uk>.
Lars Huttar wrote:
>>From: Alexander Schatten
>>Sent: Wednesday, November 05, 2003 12:34 PM
>>To: users@cocoon.apache.org
>>Subject: Impossible CLI??
>>
>>
>>So, I am playing around for hours now, to get the CLI running
>>to produce
>>an example for a demonstration... seems to be, that I am far
>>too stupid
>>to understand the documentation:
>>
>>(1) I tried using a config file; then I detected, that there
>>seem to be
>>various modifications of the syntax: the example on the cocoon 2.1
>>website does not work with my Cocoon 2.1 version, e.g. <uris> is not
>>known... on the wiki there is an older documentation, which "works"
>>without exception about not knowing certain elements.
>>
>>
>
>I also had problems with <uri>foo.html</uri>.
>Instead I found that <uri attributes ... /> worked
>(i.e. no text content in the <uri> element).
>
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.
>>(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.
>>(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.
>>??? and
>>
>>"server.properties not found, using command line or default
>>properties"
>>
>>
Not sure about that one. It isn't a problem though.
>>then comes:
>>
>>
>>"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.
>>and thats it; it does nothing but create two files in the
>>work directory
>>and waits until I terminate hsqldb with Ctrl C.
>>
>>
>>to be honest, I have no more ideas what to do?
>>
>>
What version of Cocoon are you running?
Are you able to rebuild with less blocks?
If not, are you able to run Cocoon in an IDE (just a Java application)
and step through the code in CocoonBean to see what happens?
>>thank you for help!
>>
>>
>>
You're welcome.
>Sorry, I don't know much more than you do, but I can tell you
>that your errors
>
>
>
>>"Cannot find CatalogManager.properties"
>>
>>??? and
>>
>>"server.properties not found, using command line or default
>>properties"
>>
>>
>
>are typical, perhaps we could say "normal", and don't indicate
>a problem.
>
>
>Below are some notes I wrote up while trying to get CLI to
>work on my machine. I did get it to work at least rudimentarily.
>I hope these are of help to you.
>
>
Lars, this list is really useful. Would you be willing to add it to the
CommandLine wiki page? Really, I think the web site docs should be the
formal "this is what the <uris> node means" docs, but there is a really
big place for this kind of "this works for me" docs too, on the Wiki.
Regards, Upayavira
>Lars
>
>
>- Follow directions at http://wiki.cocoondev.org/Wiki.jsp?page=CommandLine
> on getting CLI working. My details:
>- I'm using cli.xconf to specify cli configuration, rather than the command line.
> In the supplied cli.xconf, I changed context-dir to:
> <context-dir>C:\Program Files\Apache Group\Tomcat 4.1\webapps\cocoon</context-dir>
> and added a uri element:
> <uri src="test/1"/>
>- In the Tomcat 4.1\webapps\cocoon directory, I up test\sitemap.xmap with the
> following matcher:
> <map:match pattern="1">
> <map:read src="test1.html" mime-type="text/html" />
> </map:match>
> And added the file test\test1.html with some simple HTML in it.
>- Run the CLI as follows:
> ./cocoon.bat cli -x cli.xconf
>- You can apparently disregard the following errors:
> - Cannot find CatalogManager.properties
> - server.properties not found, using command line or default properties
> - java.sql.SQLException: The database is already in use by another process
> at org.hsqldb.Trace.getError(Unknown Source) ...
>- If there's an error with missing class ServletConfig, (in my case the process
> would seem to become a server and start waiting for connections), the fix is
> to copy lib/optional/servlet_2_2.jar to build/webapp/WEB-INF/lib/
>- You can tell it worked if it reports a "Total time" and creates files
> in build/dest.
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Impossible CLI??
Posted by Alexander Schatten <al...@gmx.at>.
First of all, thank you for your comments, unfortunately I do not come
one step ahead; always new problems are arising...
I will (for sake of simplicity) answer your email and Upayaviras seperately:
Lars Huttar wrote:
>- Follow directions at http://wiki.cocoondev.org/Wiki.jsp?page=CommandLine
> on getting CLI working. My details:
>
--> next mail
>- I'm using cli.xconf to specify cli configuration, rather than the command line.
> In the supplied cli.xconf, I changed context-dir to:
> <context-dir>C:\Program Files\Apache Group\Tomcat 4.1\webapps\cocoon</context-dir>
> and added a uri element:
> <uri src="test/1"/>
>
I am also trying to use the config file; but I really do not know what
you mean to do with this test/1...
>- In the Tomcat 4.1\webapps\cocoon directory, I up test\sitemap.xmap with the
> following matcher:
> <map:match pattern="1">
> <map:read src="test1.html" mime-type="text/html" />
> </map:match>
> And added the file test\test1.html with some simple HTML in it.
>
why this?? It should be possible to simply point to an existing URL? why
create a new one?
>- Run the CLI as follows:
> ./cocoon.bat cli -x cli.xconf
>
tryed this...
>- You can apparently disregard the following errors:
> - Cannot find CatalogManager.properties
> - server.properties not found, using command line or default properties
> - java.sql.SQLException: The database is already in use by another process
> at org.hsqldb.Trace.getError(Unknown Source) ...
>
there are not occuring any longer, but others... --> next email
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Impossible CLI??
Posted by Lars Huttar <la...@sil.org>.
> From: Alexander Schatten
> Sent: Wednesday, November 05, 2003 12:34 PM
> To: users@cocoon.apache.org
> Subject: Impossible CLI??
>
>
> So, I am playing around for hours now, to get the CLI running
> to produce
> an example for a demonstration... seems to be, that I am far
> too stupid
> to understand the documentation:
>
> (1) I tried using a config file; then I detected, that there
> seem to be
> various modifications of the syntax: the example on the cocoon 2.1
> website does not work with my Cocoon 2.1 version, e.g. <uris> is not
> known... on the wiki there is an older documentation, which "works"
> without exception about not knowing certain elements.
I also had problems with <uri>foo.html</uri>.
Instead I found that <uri attributes ... /> worked
(i.e. no text content in the <uri> element).
> (2) I also tried to use only command line options, however; I hardly
> understand what the uri concept and parameters...?!
>
> (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"
>
> ??? and
>
> "server.properties not found, using command line or default
> properties"
>
>
> then comes:
>
>
> "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"
>
>
> and thats it; it does nothing but create two files in the
> work directory
> and waits until I terminate hsqldb with Ctrl C.
>
>
> to be honest, I have no more ideas what to do?
>
>
> thank you for help!
>
>
> Alex
>
Sorry, I don't know much more than you do, but I can tell you
that your errors
> "Cannot find CatalogManager.properties"
>
> ??? and
>
> "server.properties not found, using command line or default
> properties"
are typical, perhaps we could say "normal", and don't indicate
a problem.
Below are some notes I wrote up while trying to get CLI to
work on my machine. I did get it to work at least rudimentarily.
I hope these are of help to you.
Lars
- Follow directions at http://wiki.cocoondev.org/Wiki.jsp?page=CommandLine
on getting CLI working. My details:
- I'm using cli.xconf to specify cli configuration, rather than the command line.
In the supplied cli.xconf, I changed context-dir to:
<context-dir>C:\Program Files\Apache Group\Tomcat 4.1\webapps\cocoon</context-dir>
and added a uri element:
<uri src="test/1"/>
- In the Tomcat 4.1\webapps\cocoon directory, I up test\sitemap.xmap with the
following matcher:
<map:match pattern="1">
<map:read src="test1.html" mime-type="text/html" />
</map:match>
And added the file test\test1.html with some simple HTML in it.
- Run the CLI as follows:
./cocoon.bat cli -x cli.xconf
- You can apparently disregard the following errors:
- Cannot find CatalogManager.properties
- server.properties not found, using command line or default properties
- java.sql.SQLException: The database is already in use by another process
at org.hsqldb.Trace.getError(Unknown Source) ...
- If there's an error with missing class ServletConfig, (in my case the process
would seem to become a server and start waiting for connections), the fix is
to copy lib/optional/servlet_2_2.jar to build/webapp/WEB-INF/lib/
- You can tell it worked if it reports a "Total time" and creates files
in build/dest.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org