 |  |  |  | I keep changing my XSP pages to try and fix a bug, and it never seems
to recompile. What gives? |  |  |  |  |
If you use <?xml-stylesheet?>
to implement a logicsheet instead of the preferred mechanism,
the <?xml-logicsheet?> processing
instruction, then you need to "touch" the .xml file as well as the logicsheet
to trigger a recompile. This is a known bug (which can be avoided by only using
the preferred mechanism - see the next question) and should be fixed
soon.
If you use namespace-mapped logicsheets, see the next question.
If you change the actual .xml file itself and it still doesn't recompile,
this is usually due to bad clock synchronization. You need to ensure that the
system clock on the machine with your text editor on it, has exactly the same
date/time as the server, or failing that set it to a little bit faster. This is
needed because the XSPProcessor uses file modification dates to determine
whether a page needs to be recompiled.
The other main factor is external classes. If you modify a class
outside an XSP page, and the XSP page refers to the class, you need to
not only recompile the class, but also restart the servlet
runner. This is a problem which is planned to be fixed soon.
|
 |  |  |  |
How can I avoid restarting the servlet engine every time I change a logichsheet?
How can I specify the order of logicsheet transformation by XSL?
|  |  |  |  |
 |  |  |  | I get the exception Can't create store repository: ./repository.
Make sure it's there or you have writing permissions. How do I fix this?
|  |  |  |  |
 |  |  |  | Why doesn't xsl:output work? |  |  |  |  |
 |  |  |  | How can I get Cocoon to stop mangling my Javascript/JScript/ECMAScript?
|  |  |  |  |
 |  |  |  | How do I get images to appear using FOP (PDF formatter)? |  |  |  |  |
Make sure you have the SUN JNDI API
package installed in your classpath (named jndi.jar ). In fact,
you will need all of the following jars on your CLASSPATH, all of which can
be obtained from java.sun.com
(thanks to James Vanetten for this list):
jndi.jar
ldap1_2_2/lib/ldap.jar
ldap1_2_2/lib/providerutil.jar
ldap1_2_2/lib/jaas.jar
ldap1_2_2/lib/ldapbp.jar
 | If you built cocoon yourself, without the JNDI JAR on the classpath, you will
also need to rebuild it. Run build.sh clean and then
build.sh (or build.bat , as appropriate.) |
|
 |  |  |  | Is there an easy way to see which parts of the Cocoon pipeline
are consuming the most CPU time? |  |  |  |  |
Yes. First you need to enable profiling by uncommenting the line
in cocoon.properties (by removing the #).
(This is normally disabled because it may degrade performance, so ensure you
disable it when you don't need it, especially on production servers!)
Then restart your servlet engine
(this always needs to be done after changing cocoon.properties ).
Access the page(s) you want to profile (several times each, to smooth out
fluctuations). Then, to see the results, access samples/profiler.xml in your
browser.
You can edit this sample file or its stylesheet
to generate totals, averages, sort, filter etc. As with all the rest of the
cocoon codebase, contributions of improvements are welcome! Send them to
cocoon-dev@xml.apache.org.
 | You will notice that pages take longer to produce when first accessed, or accessed
after a change (especially XSP pages, which need to be recompiled when changed).
Also Cocoon itself, like any significant Java program, takes time to start up, but after
that it becomes faster.
This is perfectly normal, but it means that you should exclude "first hits"
from any performance analysis, because on a live site, the .xml files would
probably only be modified relatively infrequently, i.e. when you upload
new files.
|
For more detailed analysis you could either use a third-party profiling tool, or
manually insert hooks to org.apache.cocoon.Profiler
(look at src/org/apache/cocoon/Engine.java for examples of this).
Stylesheets can be CPU-intensive, so see the
XSL FAQ
for advice on optimizing stylesheets.
|
 |  |  |  |
I think that using Processing Instructions to "chain"
document layers somehow violates the context separation since I would like
to be able to place style-related information in sessions or request
parameters. What do you think about this?
|  |  |  |  |
You are right, PI reaction breaks the context separation and it is, in the
final analysis, the wrong approach. To follow a complete "model, view,
controller" design pattern, one should be able to associate a different
processing chain for each requested URI and for every possible request state
(with request parameters, session parameters and environment parameters).
The proposed solution (as you can read in the Cocoon2
outline) is to have a site map where site
managers decide what processing chain to apply to each possible request.
This somehow follows the mod_rewrite model in the Apache Web Server, but
rather than URL rewriting, the site map allows site designers to control the
behavior of their documents in one place without having to modify every
single reactive PI in each source file.
So, you've been warned: the PIs will go away, current functionality will
remain but the processing management will be abstracted one layer up.
|
 |  |  |  |
How do I call a servlet or CGI script, or include output
from another server? Or, how do I call Cocoon from another servlet?
|  |  |  |  |
In the case of servlets and CGIs on your own server, this is discouraged -
we recommend you read the page
about dynamic content to find out how to port your functionality
to XSP pages and/or Producers, for maximum efficiency and best integration
into the Cocoon framework.
However, if this is not an option, there are several ways to include content,
depending on whether it is XML or not and where it is located or generated.
For getting XML content, you can use the
<util:include-uri> tag in an XSP
page. Example:
 |  |  |  |
<?cocoon-process type="xsp"?>
<xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core"
xmlns:util="http://www.apache.org/1999/XSP/Util">
<page>
<util:include-uri href="http://myserver.com/servlets/foo"/>
</page>
</xsp:page>
|  |  |  |  |
(This assumes that the "foo" servlet is returning a well-formed XML
document, rather than the more usual HTML.) To build the URL
dynamically in the above example, just do something like this:
 |  |  |  |
<util:include-uri>
<util:href><xsp:expr>"http://myserver.com/servlets/foo?x=" + request.
getParameter ("foo")</xsp:expr></util:href>
</util:include-uri>
|  |  |  |  |
To get data from non-XML sources, just do like in any Java program:
 |  |  |  |
Object content = new URL ("http://myserver.com/foobar").getContent ();
|  |  |  |  |
or openStream(), or whatever is most appropriate
(inside a Producer or preferably an XSP page). Read the Javadocs for Java
to find out more.
To include static non-XML files which exist on your own server, it's
faster to just do as the first example above but replace
util:include-uri href= with
util:get-file-contents name= .
 | The current Servlet API does not include any explicit support for
servlet chaining. However, the Cocoon Project is in close contact with the
Servlet API Expert Group at
Sun (Stefano Mazzocchi being a member of that board) and will propose
post-processing hooks for inclusion in the next Servlet API specifications.
|
|
 |  |  |  | My processing instructions are ignored or disappear - what's wrong? |  |  |  |  |
(Cocoon's creator Stefano Mazzocchi answers): It's a pretty stupid reason and a funny
story: I spent my 1998 Xmas vacation with my girlfriend up on the Alps at her cottage. One
night I couldn't sleep, I went to watch some TV and finishing reading the XSL
documentation I brought with me. Being a science fiction afficionado, I found out
that Ron Howard's movie Cocoon was on and I started watching it. The idea of the XSL
rendering servlet stoke me like the alien "cocoons" in the pool stroke those old men in the
movie and, while watching, I started paper-coding it right away. After a while the movie
was over and the publishing framework designed. The name "Cocoon" seemed right
for the thing, meaning to be a way to bring new life to old ideas as well as to create cocoons
for such new ideas to become beautiful butterflies. :-)
|
|