Re: Giving up! Cocoon too big, slow and confusing

[Liam Morley]

To be fair, the documentation has greatly improved since I started with 
Cocoon (almost a year ago). I sent out an email earlier with specific 
comments (thank you Nicola for noticing:)), both the good and the bad.. 
and while I was looking through the existing documentation, I noticed a 
few things I hadn't noticed before.

Here are the best answers for the specific questions that I've been able 
to come up with, hopefully they're helpful.

Ricardo Trindade wrote:

>Ok. Where is the documentation for Pipeline Components ?
>
>Where is an in-depth description of each type of G enerator ?
>
By pipeline components, do you mean sitemap components? You can find 
that (as well as in-depth descriptions of most Generators) at 
. From the front page, 
you can just click on "User Guide" on the left and you'll get there. You 
might want to take a look at the Internal Pipeline snippet 
 
from the "Snippets" section, or the Sitemap documentation 
 located in 
the "Concepts" section of the User's guide. (I think because the sitemap 
is so central, you might want to think about taking it outside of the 
concepts section and moving it into the main User Docs section? I don't 
intuitively look in the "Concepts" section for the sitemap 
documentation, that might just be me, though.)

>There is no depth to the documentation. One doesn't have to go very far
>to run out of documentation.
>
In my mind, that's what this process is for; to find out the trouble 
areas and fix them. And as you've pointed out, depth is one of those 
trouble areas. One of my problems was the consistency; some docs really 
explained both the problem and the solution extremely well, while others 
just gave me a fully qualified classname, a one-sentence description, 
and whether or not it's cacheable (sometimes with a number of ?'s 
instead). But in the near future, if I can fully wrap my mind around 
some of these concepts enough to consider myself worthy of doc writing, 
I'll do so.

>The Tutorial. How do I write a simple data-base backed application ?
>
One of the problems in the doc that I just noticed now is how hard it 
can be find something that you're looking for. I was just 12 hours ago 
that I had looked over the entire site, and I saw a really nice 
cocoon-specific database article. But now I can't remember if it was a 
how-to, a faq, or a tutorial. I think that's a problem... and my only 
suggestion on how to fix that is to either change the wording or make it 
really clear what goes in each, as well as edit gray areas. Taking a 
quick look through the site, however, I found the following:

Dev Guide - Using Databases in Apache Cocoon
(I thought the Dev Guide was for those who were developing Cocoon, not 
developing with Cocoon? the line seems blurry to me.. I find the javadoc 
from the Dev Guide useful, however I find the docs in the Users Guide 
useful as well.. I don't see the need for a seperation, and I find the 
seperation both confusing and time-consuming to repeatedly move from one 
section to the other.)


Users Guide - Concepts - Database Access
(This one's a bit hard to find, I think; I ended up looking three times 
in the How-To, FAQ, Tutorial or Performance section. The concepts 
section doesn't stick out so well in my mind.)


I can't promise that these are what you're looking for, but hopefully 
it's a start. And hopefully, if they're not what you're looking for, the 
questions that get raised will become questions posed to the list.

all the best,
Liam Morley


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Elephants and Mavericks (Re: Giving up! Cocoon too big, slow and confusing)

[Jeff Turner]

Thanks for the honest words, instead of silence.

I am reminded of the following definition:

"
second-system effect n. 

  When one is designing the successor to a relatively small, elegant,
  and successful system, there is a tendency to become grandiose in
  one's success and design an elephantine feature-laden monstrosity. The
  term was first used by Fred Brooks in his classic "The Mythical
  Man-Month: Essays on Software Engineering". It described the jump from
  a set of nice, simple operating systems on the IBM 70xx series to
  OS/360 on the 360 series. A similar effect can also happen in an
  evolving system; see Brooks's Law, creeping elegance, creeping
  featurism."

  http://www.tuxedo.org/~esr/jargon/html/entry/second-system-effect.html

The choice is to stick around and help fix things (if indeed they are
broken), or jump to a lighter alternative like Maverick:

  "Maverick is a minimalist web publishing framework which combines the
  best features of Struts and Cocoon and yet is far simpler than
  either."
  http://marc.theaimsgroup.com/?l=velocity-user&m=102387923624439&w=2


--Jeff


On Wed, Jun 26, 2002 at 10:41:14PM -0400, John Austin wrote:
> I'm back from a short vacation in beautiful Chicago (it really is much 
> nicer than Toronto or Montreal) and have waded back in to Cocoon for a 
> couple of days.
> 
> After just a few hours of poking around I have decided that it will be 
> much simpler for me to simply hand-code a whole hat-full of servlets 
> than to try and pull any meaning out of Cocoon and it's documentation.
> Fifteen hours on the Interstate wasn't as challenging as trying to 
> figure out how one should check a Web Form this month but I didn't have 
> that feeling of travelling backwards half of the time. I was also able 
> to predict and achieve forward progress (for a change).
> 
> Thanks guys, but no thanks. 
> 
> Maybe I'm getting old, but I really don't understand the need for all 
> of the complexity and the lack of documentation in this product.
> 
> On the other hand, I used to feel the same way about the mind-numbing 
> complexity of a certain thirty-year-old mainframe operating system 
> (MVS) produced by IBM back in the sixties and it's patching system 
> (SMP4). So it can't just be my age. 
> 
> Anyway, Cocoon has cost me far morte (a typo that's better than the 
> original word) time than it was worth. The chief problems appear to 
> have been endlessly re-invented terminology for an overwhelming number 
> of 'new concepts' and a complete lack of consistency between different 
> components (i.e. functional code, non-functional examples, unbuildable 
> documentation and a website that doesn't match up with any single 
> released version of the project).
> 
> I have a lot of respect for the ability of the people who have built 
> this project, but I want them to know that their project appears to be 
> out-of-control and could become very difficult to manage. If 
> experienced developers (like myself) can't figure out how to use enough 
> features in the product to make it worth using, then penetration will 
> be limited and all of your efforts will be wasted. There is more to 
> this business than stuffing in features at the expense of documentation 
> and testing. You have a lot of very good ideas, but the execution of 
> the project as a whole seems to be suffering.
> 
> I know that I will often look at my JSP and servlet code and think 'XSP 
> and Cocoon were sooo much better!' until I remember that I wasn't ever 
> able to use enough of Cocoon to make a profit.
> 
> Oh, well, at least all of my test systems have bags of memory now!
> 

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Samples as tools for learning and development (Was: Giving up!Cocoon too big, slow and confusing)

[David Crossley]

Argyn Kuketayev wrote:
> I don't think that Cocoon is complex. I blame the very
> poor documentation. When you know how it works, it's
> simple. So, you have to get very familiar with the source
> codes to use Cocoon. I don't like it. I'd rather look
> under the hood only when I have non-trivial problems. 
> 
> Unfortunately, with Cocoon you have to do it all the time.
> E.g., Cocoon's samples are just to say "hey, we have samples!".

Not so. They are there as a learning tool for you.
Yet they more than that. They provide the basis for you to
create your own applications (copy-and-extend).

Please read the following snippet from
http://xml.apache.org/cocoon/overview.html#samples

It will greatly assist your understanding of Cocoon to investigate
behind-the-scenes, to find out how each sample is processed. Do this by
looking at the actual XML documents provided in the distribution at
webapp/docs/samples/ and by consulting the sitemap to see the
processing steps that are defined.


Please contribute other new samples as you see fit.

I am interested to know how you propose to build a
reliable finely-tuned publishing system using Cocoon
without "looking under the hood". I did not realise that
we had reached that stage of automation yet.

We certainly are aiming for that. In HEAD branch, the
Samples are being re-organised into a set of clean,
reliable, informative, individually-packaged samples.
This makes it easy to use them as template apps.

Eventually, high-level tools can utilise them. I hear
that sitemap editing tools are starting to emerge too.

For the moment you must look under the hood. Anyway, i find
that getting my hands dirty is the best way to learn. Please
follow the samples that others have tried to provide.

You say that you need to "get familiar with the source code"
in order to understand. Well, i do not touch any java code.
I just copy and tweak the samples' xml/xsl files and sitemaps.

--David






-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

RE: Giving up! Cocoon too big, slow and confusing

[Vadim Gritsenko]

> From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> 
> >   o The entry "How do I hide "cocoon" in the URL's once I
> > integrate using mod_jk as shown above?" could be
improved,
> > as I did not find it helpful. I could make specific
> > suggestions, but I think that would be outside the
context
> > of this list.
> 
> Ok, ok, I've just improved it, and it'll be posted very soon by Diana.
> 
> BTW, does anyone know whether setting "/cocoon" as default Docbase
works for
> servlets containers other than Tomcat ?

Yes. Only sometimes it is called not "default Docbase" but "webapp to
URI mapping" :)


For resin, this will be:

  ...



For WebLogic (IIRC):
  


Etc.


PS: 143 emails to go :(

Vadim


> Best regards,
> 
> -
>Luca Morandini
>GIS Consultant
>   [EMAIL PROTECTED]
> http://utenti.tripod.it/lmorandini/index.html
> -


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

RE: Xindice and Cocoon

[Cenk Uysal]

Here is the error:

SAXException JspGenerator.generate()

org.apache.cocoon.ProcessingException: SAXException
JspGenerator.generate()

org.apache.cocoon.ProcessingException: SAXException
JspGenerator.generate()
at
org.apache.cocoon.generation.JspGenerator.generate(JspGenerator.java:132)
at
org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:251)
at
org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:399)
at
org.apache.cocoon.www.erhan.sitemap_xmap.matchN1002E(/usr/local/jakarta-tomcat/work/localhost/cocoon/cocoon-files/org/apache/cocoon/www/erhan/sitemap_xmap.java:482)
at
org.apache.cocoon.www.erhan.sitemap_xmap.process(/usr/local/jakarta-tomcat/work/localhost/cocoon/cocoon-files/org/apache/cocoon/www/erhan/sitemap_xmap.java:390)
at
org.apache.cocoon.www.erhan.sitemap_xmap.process(/usr/local/jakarta-tomcat/work/localhost/cocoon/cocoon-files/org/apache/cocoon/www/erhan/sitemap_xmap.java:334)
at org.apache.cocoon.sitemap.Handler.process(Handler.java:222)
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:179)
at
org.apache.cocoon.www.sitemap_xmap.matchN1038F(/usr/local/jakarta-tomcat/work/localhost/cocoon/cocoon-files/org/apache/cocoon/www/sitemap_xmap.java:4230)
at
org.apache.cocoon.www.sitemap_xmap.process(/usr/local/jakarta-tomcat/work/localhost/cocoon/cocoon-files/org/apache/cocoon/www/sitemap_xmap.java:3254)
at
org.apache.cocoon.www.sitemap_xmap.process(/usr/local/jakarta-tomcat/work/localhost/cocoon/cocoon-files/org/apache/cocoon/www/sitemap_xmap.java:3121)
at org.apache.cocoon.sitemap.Handler.process(Handler.java:222)
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:179)
at
org.apache.cocoon.sitemap.SitemapManager.process(SitemapManager.java:154)
at org.apache.cocoon.Cocoon.process(Cocoon.java:575)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:998)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:1011)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:536)


Usually Cocoon gives this error when JSP can not generate valid XML.
So I think Xindice is unreachable. Also how can I try if XSP can
reach Xindice? Has Cocoon samples this kind of example? 

_

Redirection of output

[Omar Alos]

 Hello 
Sorry for sending again this issue, but I really need your help.
I want to send my cocoon output  to a different output that the entry, for example, printing the ps in a net printer, or saving the pdf in a file, etc.
How can I do this? 
Thanks in advance. 
  Copa del Mundo de la FIFA 2002El único lugar de Internet con vídeos de los 64 partidos ¡Apúntante ya!.

Re: Giving up! Cocoon too big, slow and confusing

[Anthony Aldridge]

Absolutely! BUT, the point isn't that everyone's dissing Cocoon, it's that
a weakness has been identified, and is being discussed. No need to be
defensive about it - that's what will drive people to amend the situation.

Regards

Anthony Aldridge
Application Development
Managed Intranet Hosting
JPMorganChase




David Crossley <[EMAIL PROTECTED]> on 06/28/2002 10:12:54 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:
Subject:  Re: Giving up! Cocoon too big, slow and confusing


Everyone stop, take a breathe, get a cup of coffee
and go read "The Cathedral and the Bazaar"
http://tuxedo.org/~esr/writings/cathedral-bazaar/
or similar writings about how Open Source Software operates.
It seems that many people here are missing the point.

It amazes me that people have the time to compose email
to the mailing list to tell us that they are too busy, and
then have the hide to tell us that documentation is poor.

If each of us add one FAQ to the document collection,
then the lack will be addressed very quickly. That is OSS.
If you see an issue, the onus is on you to help remedy that.
Everyone benefits from the work of each one.

There is no such separate thing as "they, the developers".
Rather it is "we the community". Anyone who contributes
a patch (code or doc) is instantly transformed from being
a "user" into a "developer".

Users use, contributers build projects.

Thanks for raising this topic. I do sympathise with you
about the complexities and inadequacies. We have all been
though that and still do. None of us know all of Cocoon
capabilities and would all benefit from doc contributions.
Please help.
--David


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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. 

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

RE: Xindice and Cocoon

[Piroumian Konstantin]

> From: Cenk Uysal [mailto:[EMAIL PROTECTED]] 
> 
> Hi,
> 
> I try to use Xindice as my XML source database. I know that Cocoon
> has special generators for this purpose. But I try to do this by the
> help of JSP(don't ask why :)). So we prepared a library which allows
> us to connect Xindice from JSP and get XML content by Xpath function
> that we enter.
> Here is a sample JSP:
> 
> <%@ page language='java'%>
> <%@ taglib uri="deu-taglib.tld" prefix="deu"%>
> 
>   
>   
>   
> 
> 
> Here  and  tags are defined by us. They
> make a connection to Xindice and get the XML with restrictions given
> in  tag. 
> 
> Normally, this code runs in ROOT directory of Tomcat. But I want to
> run this JSP code by the help of JSP generator. But I get
> JSPGenerator problem from Cocoon.
> 
> I think I can't reach Xindice because this time JSP must be under
> Cocoon directory. I know normally JspGenerator runs without problem.

What is the exact problem you get? Have you looked at the log? Is Xindice
reachable from other places in Cocoon, e.g. from XSP?

(The question is not hard to answer, but almost impossible if you don't
provide enough details. And also, please, have patience to wait until the
earth will turn arround a little, so the people from the other time zones
could get your question in the morning ;))

> 
> What can be the problem?

Error messages, log snippets, other relevant details...

Konstantin

> 
> __
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
> 
> 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. 

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

RE: Giving up! Cocoon too big, slow and confusing

[Manos Batsis]

Well said indeed. I guess that's the reason I've never complained about
Cocoon documentation; I don't feel I have the right to ;-)

> -Original Message-
> From: David Crossley [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, June 28, 2002 12:13 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Giving up! Cocoon too big, slow and confusing
> 
> 
> Everyone stop, take a breathe, get a cup of coffee
> and go read "The Cathedral and the Bazaar"
> http://tuxedo.org/~esr/writings/cathedral-bazaar/
> or similar writings about how Open Source Software operates.
> It seems that many people here are missing the point.
> 
> It amazes me that people have the time to compose email
> to the mailing list to tell us that they are too busy, and
> then have the hide to tell us that documentation is poor.
> 
> If each of us add one FAQ to the document collection,
> then the lack will be addressed very quickly. That is OSS.
> If you see an issue, the onus is on you to help remedy that.
> Everyone benefits from the work of each one.
> 
> There is no such separate thing as "they, the developers".
> Rather it is "we the community". Anyone who contributes
> a patch (code or doc) is instantly transformed from being
> a "user" into a "developer".
> 
> Users use, contributers build projects.
> 
> Thanks for raising this topic. I do sympathise with you
> about the complexities and inadequacies. We have all been
> though that and still do. None of us know all of Cocoon
> capabilities and would all benefit from doc contributions.
> Please help.
> --David
> 
> 
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
> 
> 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. 

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

Re: Giving up! Cocoon too big, slow and confusing

[David Crossley]

Everyone stop, take a breathe, get a cup of coffee
and go read "The Cathedral and the Bazaar"
http://tuxedo.org/~esr/writings/cathedral-bazaar/
or similar writings about how Open Source Software operates.
It seems that many people here are missing the point.

It amazes me that people have the time to compose email
to the mailing list to tell us that they are too busy, and
then have the hide to tell us that documentation is poor.

If each of us add one FAQ to the document collection,
then the lack will be addressed very quickly. That is OSS.
If you see an issue, the onus is on you to help remedy that.
Everyone benefits from the work of each one.

There is no such separate thing as "they, the developers".
Rather it is "we the community". Anyone who contributes
a patch (code or doc) is instantly transformed from being
a "user" into a "developer".

Users use, contributers build projects.

Thanks for raising this topic. I do sympathise with you
about the complexities and inadequacies. We have all been
though that and still do. None of us know all of Cocoon
capabilities and would all benefit from doc contributions.
Please help.
--David


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Cache broken in Cocoon 2.1-dev?

[Albertsen, Juergen]

Hi,

since switching to Cocoon 2.1-dev I noticed a considerable loss in
performance. My website (http://www.juergenalbertsen.com) currently consits
mainly of static XML files piped through a number of XSL files. There's only
one XSP generated section, the rest is merely static. 

I looked into the cache directories that were filled with pre-generaed HTML
files when using Cocoon 2.0.2. Now they are empty. I searched the mailing
lists - both dev and user - but could not find any hint that people are
working on the cache system. Additionally, when trying the "plain"
cocoon.war I cannot find any genared HTML files neither (so doesn't seem to
be misconfiguration). 

All this applies to a number of platforms (Windows, Linux, FreeBSD) and
Servlet containers (Resin, Tomcat). 

Thanks in adavance for your help.

Regards,

Jürgen

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

RE: build fails in 2.0.3-dev

[Carsten Ziegeler]

Thanks for reporting!
It's fixed now.

Carsten 

Carsten Ziegeler Chief Architect Open Source Group, S&N AG
--
 Cocoon Consulting, Training and Projects
--
mailto:[EMAIL PROTECTED]  http://www.s-und-n.de
http://ziegeler.bei.t-online.de


> -Original Message-
> From: leo leonid [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 28, 2002 4:53 PM
> To: [EMAIL PROTECTED]
> Subject: build fails in 2.0.3-dev
> 
> 
> 
> 
> compile:
> Copying 28 files to /usr/jakarta/xml-cocoon203/build/cocoon/classes
> Compiling with Java 1.3, debug on, optimize off, deprecation off
> Compiling 607 source files to
> /usr/jakarta/xml-cocoon203/build/cocoon/classes
> /usr/jakarta/xml-cocoon203/build/cocoon/src/org/apache/cocoon/comp
onents/language/generator/GeneratorSelector.java:165:
> reference to ComponentException is ambiguous, both method
> ComponentException(java.lang.String,java.lang.Throwable) in
> org.apache.avalon.framework.component.ComponentException and method
> ComponentException(java.lang.String,java.lang.String) in
> org.apache.avalon.framework.component.ComponentException match
> throw new ComponentException("Could not access component for
> hint: " + hint, null);
>   ^
> 1 error
> 
> BUILD FAILED
> 
> :-(
> 
> /Leo
> 
> 
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
> 
> 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. 

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

RE: Giving up! Cocoon too big,slow and confusing (Blocks will he lp for sure)

[ROSSEL Olivier]

> I think the core developers are fully aware of this fact, and 
> the Cocoon Blocks [1] concept will make a big difference here. 
> 
> Trimming down the core and making most or all components 
> pluggable will help 
> a lot in differentiating between "stable/well-known" and 
> "experimental/mysterious" components.
> 
> -Bertrand

With dependencies management, administration/upgrading interface, 
rights management and debugging facilities? And docs?
Wow :-)

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

RE: Giving up! Cocoon too big, slow and confusing

[ROSSEL Olivier]

The documentation should follow the learning curve.
May be each doc should have a requirement section, which
lists all the notions that must be well known to understand
the current topic.
And docs should be rated under a system of "Beginner", "Intermediate" and
"Advanced"
topics.

In fact, i think everybody should use wikiLand :
http://www.anyware-tech.com/wikiland
I promise that if someone else than me posts something on wikiLand,
I code the XSLT to export to xdocs :-)
That's a deal, dudes!


The second thing that makes Cocoon obscure is the lack of intuitive 
debugging system.
An intuitive debugging system allows the user to _see_ the behaviour 
of the program.
I think that a Cocoon app which could display on the client how the 
sitemap resolved for a given URI, which could allow to browse between a 
sitemap resolving report and XML/XSL files involved in the resulting 
pipeline, all that would make newbies get into Cocoon more easily.
The first step should be an easy step.

And last thing, error management should be heavily handled
in Cocoon. No more strange messages on the client side.

My humble 2 cents.

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

build fails in 2.0.3-dev

[leo leonid]

compile:
Copying 28 files to /usr/jakarta/xml-cocoon203/build/cocoon/classes
Compiling with Java 1.3, debug on, optimize off, deprecation off
Compiling 607 source files to
/usr/jakarta/xml-cocoon203/build/cocoon/classes
/usr/jakarta/xml-cocoon203/build/cocoon/src/org/apache/cocoon/components/language/generator/GeneratorSelector.java:165:
reference to ComponentException is ambiguous, both method
ComponentException(java.lang.String,java.lang.Throwable) in
org.apache.avalon.framework.component.ComponentException and method
ComponentException(java.lang.String,java.lang.String) in
org.apache.avalon.framework.component.ComponentException match
throw new ComponentException("Could not access component for
hint: " + hint, null);
  ^
1 error

BUILD FAILED

:-(

/Leo


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Re: Giving up! Cocoon too big, slow and confusing (Blocks will help for sure)

[Bertrand Delacretaz]

On Friday 28 June 2002 10:22, Anthony Aldridge wrote:
>. . .
> You know how much most people on this list love and respect cocoon, but
> sometimes it does seem over complex and dense - even to those who have been
> around the project for some time.
>. . .

I think the core developers are fully aware of this fact, and the Cocoon 
Blocks [1] concept will make a big difference here. 

Trimming down the core and making most or all components pluggable will help 
a lot in differentiating between "stable/well-known" and 
"experimental/mysterious" components.

-Bertrand

[1] (rather technical and probably not final):
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101862084628687&w=2

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

RE: Giving up! Cocoon too big, slow and confusing

[Anthony Aldridge]

This is both a serious problem in terms of documantation/tools etc.. But
also in terms of cocoon itself. Some of the points are valid, not just in
terms of whether it's documented or not, but in terms of the actual system.

You know how much most people on this list love and respect cocoon, but
sometimes it does seem over complex and dense - even to those who have been
around the project for some time.

I know I started a thread talking about developing a front end content
management app (really a cocoon management app) and didn't have the
time/resources to properly follow up - but without serious consideration to
how end-users sre going to use the product, it's almost inevitable that
Cocoon will end up being a specialist product mainly for the people who
have been involved increating it.

I reckon either:

1/ Cocoon config (sitemap etc) is radically simplified
2/ Tools are created to create the config

Otherwise the great potential of the project may end up unfulfilled.

Re: a previous mail on this subject:

Genius level people  not understanding other's inability to memorise
aspects of the project! RUBBISH, people who have inside knowledge often
appear to be geniuses and magicians, it's a mirage! True genius
communicates - which is precisely the problem highlighted on this thread -
the relatively poor documentation/tools regarding Cocoon against the
fabulous technology.

Once someone said: UNIX is not NOT user-friendly, it's just choosy about
its friends!
I reckon the time has past when we can be choosy - otherwise .NET rubbish
will start becoming another cross we all have to bear (as developers), when
properly presented, Cocoon could provide a real way forwards to the web-app
community!

Regards

Anthony Aldridge
Application Development
Managed Intranet Hosting
JPMorganChase

PS I've developed an alternative way to use cocoon, based on what I call
'JBXSP' (JavaBeanExtensibleServerPages). ALL the logic, and the xml is
generated via introspection from pure java (no embedding java logic in
xml-style files). All that's required then is the xslt stylesheets to
translate, and a single xml file to call the basic java system. Ultimtely I
want to keep the xslt files as fragments in a database to be called by the
JBXSP system as required.

For me (as a java programmer) this is perfect - it may not suit everyone's
needs but I'll be happy to share the ideas with the community, if anyone's
interested.




Matthew Langham <[EMAIL PROTECTED]> on 06/28/2002 07:45:14 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:
Subject:  RE: Giving up! Cocoon too big, slow and confusing


A few comments on various raised points:

> 3) Serious problems (hours lost) upgrading from 2.0 to 2.0.2 - looking
> at the change logs for potential hints at what was necessary was a
> non-starter.

Changes between releases must be documented so that the migration is a
painless as _possible_. But if 2.0 provides what is needed then perhaps
upgrading is not always the best idea. We don't upgrade all our production
installations of Cocoon each time there is a new release. We have Cocoon
based sites that are happily running a pre-2.0 version of Cocoon.

> this will be since there have been significant changes (forms and
> authentication system to just name a few at the feature level) since
> those books have gone to publishing.
>

Unfortunately this is _always_ the case. We finished our book in March (!)
and the printing process is such that it just takes that long before the
book hits the shelves. There is nothing we (as the authors) can do about it
(apart from preventing new Cocoon releases :-)). On the other hand we
decided to include a CD containing a defined version of Cocoon so that the
details in the book match the software. The concepts have not changed
between 2.0 and 2.0.x - but things have been added.

Matthew

--
Open Source Group   Cocoon { Consulting, Training, Projects }
=
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
  http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=



-
Please check that your question  has not already been answered in the
FAQ before posting. 

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. 

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

Re: null pointer passed as base exception

[KOZLOV Roman]

Hello Leona,

Where do you define {1}, {3} and {4} in your pipeline?
IMO it should be like this:


  
  
  
  
  
  
  
  


Here you say to transformer to use request parameters by setting
"use-request-parameters" to true.
Then in your xsl you can get parameters' values by means of the following
top-level elements:

default_value
...
and then you can use them as variables, like "$dealID".

PS: It seems that in this case you need not lines with extra "pagename" and
"playerID" definition in your sitemap.

Best regards,
Roman

Leona Slepetis wrote:

> Hi All,
>
> I have part of  a pipeline that looks like this:
>
> 
>   
>   
> 
> 
> 
> 
> 
>   
>   
>   
> 
>
> In gs.xml I have:
>
> 
>   
> 
> 
>
> In gs.xsl I have:
>
>   
> 
>   
> 
> 
>   
> 
>   
>
> And default-html.xsl has:
>
>   
> 
>   
> title
>   
>   
> 
>   
> 
>   
>
> I get to it by calling
> http://localhost:8080/GS/matrix?dealID=1001&playerID=&matrixfile=file:///D:/
> matrix.xml&projectname=new
>
> When I run it, the following error occurs:
> Could not read resource file:/D:/tomcat/webapps/GS/gs.xml
>
> org.apache.cocoon.ProcessingException: Could not read resource
> file:/D:/tomcat/webapps/GorillaStation/gs.xml: java.lang.RuntimeException:
> java.lang.IllegalArgumentException: Null pointer passed as base
>
> One thing I notice is that playerID is not set to the value '123'. Why is
> this?
> The other thing is that if I take out value="matrix"/>  from the pipeline it works
> according to the default logic in .
>
> There doesn't appear to be anything wrong with gs.xml; it was working under
> C1.
> Other pipeline segments using the parameter "pagename" work just fine, such
> as:
>
> 
>   
>   
> 
>   
>   
>   
> 
>
> Can anyone give me a clue as to what is wrong?
>
> Thanks very much,
> Leona
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> 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. 

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

RE: sent map parameters into another sitemap

[zze-STIENNE Nicolas FTRD/DMI/CAE]

> > 
> > ok...
> > and with 2.0.2, there is absolutely no solution to sent a 
> > parameter to a sub-sitemap ?
> 
> There can't be "absolutely no solution" in open source: you 
> can add the
> needed functionality yourself, 
... I think I will try another solution...

> but if you describe why do you 
> need then
> maybe somebody will propose another quicker solution.
> 
> > and is that normal, I get no error message ?
> 
> When specifing parameters to mount? Yes. Most of the sitemap 
> elements are
> parametrizable, but in map:mount they simply ignored.
> 
> Konstantin
> 

ok, thanks for this informations...



> > 
> > > De : Piroumian Konstantin [mailto:[EMAIL PROTECTED]]
> > 
> > > > From: zze-STIENNE Nicolas FTRD/DMI/CAE 
> > > > 
> > > > I tried the solution you give but it don't seams to 
> work (for me).
> > > > No error message comes, I just don't obtain the values of the 
> > > > parameters.
> > > > 
> > > > Note: Tomcat4.0.4, W2000, JDK1.3.1_3, Cocoon2.0.2-scr ( I 
> > > > know you said "only in 2.1-dev version" but my Cocoon 
> > > > start-page indicates "version 2.1-dev" )
> > > > 
> > > > Otherwise, did I well understand ? 
> > > 
> > > To be exact: only in 2.1-dev version from CVS HEAD branch and 
> > > only with
> > > TreeProcessor as the sitemap engine.
> > > 
> > > Don't know why do you have 2.1-dev in the start-page, in 
> > 2.0.3 version
> > > everything's correct.
> > > 
> > > Konstantin
> > > 
> > > > 
> > > > In my parent sitemap : 
> > > > 
> > > >   
> > > > 
> > > > 
> > > > 
> > > > 
> > > >> > > uri-prefix="{1}/{2}/soussite" reload-method="synchron">
> > > > 
> > > > 
> > > >   
> > > > 
> > > > [..]
> > > > 
> > > >   
> > > > 
> > > > and in soussite/sitemap.xmap:
> > > > 
> > > >  
> > > > 
> > > >   
> > > > 
> > > >   
> > > >  value="presentationgenerale" />
> > > > 
> > > >   
> > > > 
> > > >   
> > > > [..]
> > > > 
> > > >   
> > > > 
> > > > thanks...
> > > > Nicolas !!
> > > > 
> > > > > > 
> > > > > > Hi all!
> > > > > > 
> > > > > > Does is possible sent sitemap parameters into 
> mounted sitenap 
> > > > > > like this:
> > > > > > 
> > > > > >  > > > > > reload-method="synchron">
> > > > > > 
> > > > > > 
> > > > > 
> > > > > Yes!!!
> > > > > 
> > > > > ...but only in 2.1-dev version.
> > > > > Use this in your subsitemap:
> > > > > 
> > > > > 
> > > > >   
> > > > >> > > > value="some-default-value" />
> > > > >   ...
> > > > > 
> > > > > KP
> > > > > 
> > > > > > 
> > > > > > Thanx.
> > > > > > Yury.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> -
> > > > > > Please check that your question  has not already been 
> > > > > answered in the
> > > > > > FAQ before posting. 
> > > > 
> > > > > 
> > > > > 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. 
> > 
> > > 
> > > 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. 
> > 
> > > 
> > > 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. 
> 
> > 
> > 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. 
> 
> > 
> > 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. 
> 
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail:   <[EMAIL PROTECTED]>
> 
> 

-

Réf. : Re: Réf. : RE: using cocoon pipelines without servlet

[Othman Haddad]

  thanks a lot that helps much
   
  ---Message original---
   
  
  De : [EMAIL PROTECTED]
  Date : jeudi 27 juin 
  2002 19:05:07
  A : [EMAIL PROTECTED]
  Sujet : Re: Réf. : RE: 
  using cocoon pipelines without servlet
   Hello,One example of a project using Cocoon with 
  Turbine is the Jetspeed project at http://jakarta.apache.org/ . They 
  have some architecture details here: http://jakarta.apache.org/jetspeed/site/application-development.htmlI 
  also remember in my reading of the Turbine documentation that Turbine 
  is designed for use with different "templating" components which could 
  include Velocity or Cocoon.Ryan HoeggISIS 
  NetworksOthman Haddad wrote:> 1) so you mean that if i 
  have turbine i can't call cocoon?>> 2)i mean something like: 
  wrapping castor for instance as a transformer!>> 
  >> thank you>> >> ---Message 
  original--->> >> De : [EMAIL PROTECTED] 
  >> 
  Date : jeudi 27 juin 2002 17:11:31>> A : '[EMAIL PROTECTED]' 
  >> 
  Sujet : RE: using cocoon pipelines without servlet>> 
  >> [Please, don't use HTML mails]>> 1) you 
  can't use only the pipeline from cocoon (at least, you can't do it> 
  easily), but you can use cocoon itself from an application and not 
  a> servlet. You can use the command line environment for that or 
  create your> own one.>> 2) What do you 
  mean?>> Konstantin>> -Original 
  Message-> From: Othman Haddad [mailto:[EMAIL PROTECTED] 
  ]> Sent: Thursday, June 27, 2002 7:08 PM> To: cocoon user 
  list> Subject: using cocoon pipelines without 
  servlet>>> hi everybody,> i've got 2 questions 
  that could help me a lot:> 1) can i extract the cocoon pipeling 
  mecanism from cocoon without > using as a> servlet? (i'm 
  already using turbine and have a lot of code, and what > just 
  to> use the interesting pipelining of cocoon)!>> 2) 
  can i use a java object in the cocoon pipeline?>> 
  thanks>>> 
  > 
  IncrediMail - La messagerie électronique a enfin évolué - Cliquer 
  ici>> 
  -> 
  Please check that your question has not already been answered in 
  the> FAQ before posting. < http://xml.apache.org/cocoon/faq/index.html 
  >>> To unsubscribe, e-mail: < [EMAIL PROTECTED] 
  >  
  >> For additional commands, e-mail: < [EMAIL PROTECTED] 
  >  
   . 
  > 
   
  IncrediMail > - La messagerie électronique a enfin évolué - Cliquer 
  ici >  
  





	
	
	
	
	
	
	




  IncrediMail - 
La messagerie électronique a enfin évolué - Cliquer 
ici