cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cassandra Bonner <>
Subject Re: Cocoon2 and logicsheets
Date Mon, 03 Sep 2001 23:35:06 GMT
> The resource:// protocol will look into your classpath to locate
> the logicsheet.  
> This means you have to put your logicsheet into a jar and deploy it
> into 
> WEB-INF/lib.
> Another way is to use the context:// protocol which starts looking
> at the 
> servlet app context path for it.
> Giacomo

thanks for that.  I actually had the logicsheet in my classpath, but
I didn't have it jar'd up and in the WEB-INF/lib, but rather with
other java code I've written, which was in my classpath env variable
upon starting tomcat.  Note that the example i provided wasn't the
best as I had the full path to the logicsheet vs. the CLASSPATH, but
i had tried that as well.

So - I jar'd up the java classes and logicsheet (print.xsl in my test
example) and put in WEB-INF/lib, and did get a different result, but
not all that much different. :-)  

As I mentioned, this is just a test logicsheet.  Here's a quick
summary of what I'm planning to do, in case anyone has any comments
about this (e.g. performance issues, not good design, won't work :-),
etc.) I plan to have logic sheet(s) for any of our common "external"
java code.  By external, I mean "backend" processing that needs to
occur such as our login, which is rather complex.  

Therefore, each xsp page will call a simple library such as
<usermgr:getuser/>, (implementation defined in a logicsheet) and
return a full instantiated, polulated user object.  The logic sheet
will simply call managers that we've written in java to do all the
"backend logic" of testing whether or not they're a valid user,
populating the user accordingly with access level, etc. and
redirecting the request to an error page if necessary. I feel using
managers and "external" java code is cleaner, allows for better
design, and allows us to generate javadocs (a key since we refuse to
document otherwise) :-)

Anyways - here's the examples:

My test Logicsheet 
(print stmt will actually be calls to managers, passing on a handle
to a connection pull via the mananger class variable for db conn

<?xml version="1.0" encoding="ISO-8859-1"?>


<xsl:template match="print:junk">
    System.out.println("CASS:: within print juink");



My test XSP page using this logicsheet:

<?xml version="1.0" encoding="ISO-8859-1"?>



    <mytag>Content of my tag</mytag>

      System.out.println("INDEX.XML:: my name is george");



(I have a stylesheet for presentation but not providing it here as
it's not relevant).

My setup in cocoon.xconf
          <parameter name="prefix" value="print"/>
          <parameter name="uri" value=""/>
          <parameter name="href"

As I mentioned, I've jarred up the print.xsl along with my other java
code and placed this in my WEB-INF/lib.  I no longer get the original
error message about "ComponentSelector could not access the Component
for hint: xsp", but now I get the following error message as soon as
I include the print namespace in my xsp file:

New Error Message
"Could not load class for program
'org/apache/cocoon/www/nextgen/cass/index_xml' due to a

***Which - as you can guess :-), my is no longer being
generated (actually it's just an empty file now).  

So - perhaps there's something wrong with my test logicsheet or
setup.  If anyone has any ideas about what is wrong, or our design
plan, it will be greatly appreciated.

thanks in advance,


Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger

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

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message