You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Lang, Cliff" <cl...@proxicom.com> on 2002/03/01 14:13:37 UTC

RE: Repost: -- no responses yet: Turbine screens (*.java) files not being processed Turbine.handleException - "Requested Screen not found"

I found the issue -
A call in the Default.vm layout template to: $page.setStyleSheet().  The
reference was incorrect.  (Template creator used full URL-relative path,
instead of the shorter application relative path:
$page.setStyleSheet("/myapp/servlet/myapp/style.css") vs.
$page.setStyleSheet("/myapp/style.css")).  

This action of blowing up with "Class not found" seems rather severe
when a class wasn't missing.  Nothing was noted in the velocity.log upon
template generation, and the templates were being created properly
generated (minus the style sheet).


I had tried digging into ScreenLoader, but gathered no information,
because it was a null call to ScreenLoader - then it would fail over as
it is supposed to, to the VelocityErrorTemplate.


Thanks for the help,  Cliff

-----Original Message-----
From: Eric Dobbs [mailto:eric@dobbse.net] 
Sent: Thursday, February 28, 2002 1:16 PM
To: Turbine Users List
Subject: Re: Repost: -- no responses yet: Turbine screens (*.java) files
not being processed Turbine.handleException - "Requested Screen not
found"

On Tuesday, February 26, 2002, at 03:43  PM, Lang, Cliff wrote:

> Not exactly, put I didn't think it mattered for PullTools as long as
> your reference is correct in the TR.props file.

I think you are correct about PullTools.

The problems you are describing are pretty
weird, and pretty uncommon.

I think the most likely culprits are typos in
the config file, or in the file names, or files
not being located in the correct directories.

If you are *completely* convinced you have all
those things correct then I suggest you start
hacking the ScreenLoader and logging the files
it's trying to find, as a place to continue
with your debugging efforts.

Sorry I can't help more.
-Eric

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Repost: -- no responses yet: Turbine screens (*.java) files not being processed Turbine.handleException - "Requested Screen not found"

Posted by Eric Dobbs <er...@dobbse.net>.
On Friday, March 1, 2002, at 06:13  AM, Lang, Cliff wrote:

> I found the issue -
> A call in the Default.vm layout template to: $page.setStyleSheet().  The
> reference was incorrect.  (Template creator used full URL-relative path,
> instead of the shorter application relative path:
> $page.setStyleSheet("/myapp/servlet/myapp/style.css") vs.
> $page.setStyleSheet("/myapp/style.css")).
>
> This action of blowing up with "Class not found" seems rather severe
> when a class wasn't missing.  Nothing was noted in the velocity.log upon
> template generation, and the templates were being created properly
> generated (minus the style sheet).

Now it makes sense.

The style sheet tag in the page causes the browser to
initiate a separate request to the server.  That
requested URL was like this:

http://<server>/myapp/servlet/myapp/style.css

So Turbine was being incorrectly invoked to process
the style sheet.  The ParameterParser could not find
a value for 'screen' nor for 'template', which is
probably why you were seeing nulls when debugging
ScreenLoader.

I would expect your templates to be generated
correctly.  The problems are happening in a separate
request to the server.

I'm not sure what else Turbine could do to report a
different error.  From the servlet's point of view it
was just handling a malformed URL and reporting the
problems as it would normally.  I agree that the error
doesn't help you locate the problem very well, but I
don't know what should be done differently.  Those
errors are appropriate in most circumstances.

-Eric


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>