You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-user@tomcat.apache.org by Er...@swissinfo.ch on 2002/06/25 15:32:51 UTC

JSTL crashes when templates become too complex?

Hi all

Has anyone had a problem with JSTL becoming too complex?
Here's the story: We are a news site that's migrating to JSTL for complex
news stories. Now, you can imagine that a story contains a number of
paragraphs which in return contain images, which themselves contain files,
which...
It all gets pretty complex, with objects containing ArrayLists of other
objects which contain ArrayLists of objects etc. etc.

Anyway, I'm trying to build all this with a complex test story, but if my
JSP template gets too complex, this is what happens:
javax.servlet.ServletException: (class: org/apache/jsp/storytest$jsp,
method: _jspService signature:
(Ljavax/servlet/http/HttpServletRequest;Ljavax/se
rvlet/http/HttpServletResponse;)V) Illegal target of jump or branch
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:485)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.
java:683)
        at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatch
er.java:574)
        at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher
.java:497)
        at
ch.xobix.layouttool.module.common.X2Modul_Story.generateContent(X2Modul_Stor
y.java:300)
        at
ch.xobix.layouttool.module.common.X2Modul_Base.generateOnlineContentAndPrint
(X2Modul_Base.java:48)
        at
ch.xobix.databean.layout.X2PageScript.renderAndWrite(X2PageScript.java:159)
        at ch.xobix.layouttool.X2PageViewer.view(X2PageViewer.java:30)
        at ch.xobix.basement.X2Dispatcher.doGet(X2Dispatcher.java:244)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
        at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
        at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        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.ja
va:190)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        at
org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:2
46)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
        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:2347)
        at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
        at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
        at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
        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
:174)
        at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
        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:
1017)
        at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1115
)
        at java.lang.Thread.run(Thread.java:536)

When I have a working template, I can copy a <c:forEach> loop that works,
and then the whole thing crashes. If I take it out again, it works. So, from
my (perhaps naive) point of view, JSTL can only handle templates up to a
certain complexity... is that true? I would hate to hear a "yes"...

If anyone is interested, I'll gladly send source code, but my template is
around 35K...

Thanks & best regards,
Eric


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

Re: JSTL crashes when templates become too complex?

Posted by peter lin <pe...@labs.gte.com>.
Although Jasper2 hasn't been officially released, you can grab 4.1.5
beta and drop in jasper-compiler.jar, jasper-runtime.jar and ant.jar. 

Give that a try. It should fix your problem. If you're project is 2-4
months from being deployed, you may want to consider using jasper2. It's
getting pretty close to release.


peter

Shawn Bayern wrote:
> 
> On Tue, 25 Jun 2002 Eric.Lewis@swissinfo.ch wrote:
> 
> > Hi all
> >
> > Has anyone had a problem with JSTL becoming too complex?
> > Here's the story: We are a news site that's migrating to JSTL for complex
> > news stories. Now, you can imagine that a story contains a number of
> > paragraphs which in return contain images, which themselves contain files,
> > which...
> > It all gets pretty complex, with objects containing ArrayLists of other
> > objects which contain ArrayLists of objects etc. etc.
> >
> > Anyway, I'm trying to build all this with a complex test story, but if my
> > JSP template gets too complex, this is what happens:
> > javax.servlet.ServletException: (class: org/apache/jsp/storytest$jsp,
> > method: _jspService signature:
> > (Ljavax/servlet/http/HttpServletRequest;Ljavax/se
> > rvlet/http/HttpServletResponse;)V) Illegal target of jump or branch
> 
> This is a general problem with JSP, not a specific problem with JSTL.
> When any JSP page gets too large, the corresponding method in its compiled
> servlet also becomes too large, and you get the error shown.  The best
> workaround is to break up your page into a few smaller pages, connected
> with <c:import> or <jsp:include>, if possible.  Note that when you use
> scoped variables (versus scripting variables), it's much easier to do
> this, so JSTL should help in that regard.
> 
> --
> Shawn Bayern
> "JSTL in Action"   http://www.jstlbook.com
> (coming in July 2002 from Manning Publications)
> 
> --
> 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: JSTL varStatus

Posted by Steve Slatcher <st...@scientia.com>.
> I'll try to isolate the problem more tommorrow, but I'm off home now
> :-) 

It's OK now.  And I'm too embarrassed to admit what the problem was.  
Amazing what a night's sleep can do!

Steve Slatcher


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

Re: JSTL varStatus

Posted by Steve Slatcher <st...@scientia.com>.
Shawn Bayern wrote:
> On Tue, 25 Jun 2002, Steve Slatcher wrote:
> 
>> If table blah had 3 records, wouldn't you expect
>> 
>> <sql:query var="query">select * from blah</sql:query>
>> <c:forEach var="row" items="${query.rows}" varStatus="status">
>>     <p><c:out value="${status.count}"/></p>
>> </c:forEach>
>> 
>> to produce something like
>> 
>> <p>1</p>
>> <p>2</p>
>> <p>3</p>
> 
> Yes.
> 
>> With RC1 I'm getting
>> 
>> <p>1</p>
>> <p>1</p>
>> <p>1</p>
> 
> I can't replicate this on Tomcat 4.0.4.  What container are you
> using?  If you're using Resin, are you sure you're using Standard
> Taglib 1.0 RC1 as opposed to Resin's own implementation?

Tomcat 4.0.3.

I'll try to isolate the problem more tommorrow, but I'm off home now :-)

Could you suggest a workaround?  I was trying to workaround it with 
<c:set value="${count + 1}" var="count"/> with much the same result.
I was half expecting that though (after having used XSLT).

Guess I could use a scriptlet variable.

Cheers

Steve Slatcher



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

Re: JSTL varStatus

Posted by Shawn Bayern <ba...@essentially.net>.
On Tue, 25 Jun 2002, Steve Slatcher wrote:

> If table blah had 3 records, wouldn't you expect 
>  
> <sql:query var="query">select * from blah</sql:query>
> <c:forEach var="row" items="${query.rows}" varStatus="status">
>     <p><c:out value="${status.count}"/></p>
> </c:forEach>
> 
> to produce something like
> 
> <p>1</p>
> <p>2</p>
> <p>3</p>

Yes.

> With RC1 I'm getting
> 
> <p>1</p> 
> <p>1</p> 
> <p>1</p>

I can't replicate this on Tomcat 4.0.4.  What container are you using?  If
you're using Resin, are you sure you're using Standard Taglib 1.0 RC1 as
opposed to Resin's own implementation?

(By the way, RC1 has been replaced with a final 1.0 release, but the
iteration tags were not changed between the two, so I don't suspect that's
the problem.)

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com
(coming in July 2002 from Manning Publications)


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

JSTL varStatus

Posted by Steve Slatcher <st...@scientia.com>.
If table blah had 3 records, wouldn't you expect 
 
<sql:query var="query">select * from blah</sql:query>
<c:forEach var="row" items="${query.rows}" varStatus="status">
    <p><c:out value="${status.count}"/></p>
</c:forEach>

to produce something like

<p>1</p>
<p>2</p>
<p>3</p>

With RC1 I'm getting

<p>1</p> 
<p>1</p> 
<p>1</p>

Steve Slatcher



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

Re: JSTL crashes when templates become too complex?

Posted by Shawn Bayern <ba...@essentially.net>.
On Tue, 25 Jun 2002 Eric.Lewis@swissinfo.ch wrote:

> Hi all
> 
> Has anyone had a problem with JSTL becoming too complex?
> Here's the story: We are a news site that's migrating to JSTL for complex
> news stories. Now, you can imagine that a story contains a number of
> paragraphs which in return contain images, which themselves contain files,
> which...
> It all gets pretty complex, with objects containing ArrayLists of other
> objects which contain ArrayLists of objects etc. etc.
> 
> Anyway, I'm trying to build all this with a complex test story, but if my
> JSP template gets too complex, this is what happens:
> javax.servlet.ServletException: (class: org/apache/jsp/storytest$jsp,
> method: _jspService signature:
> (Ljavax/servlet/http/HttpServletRequest;Ljavax/se
> rvlet/http/HttpServletResponse;)V) Illegal target of jump or branch

This is a general problem with JSP, not a specific problem with JSTL.  
When any JSP page gets too large, the corresponding method in its compiled
servlet also becomes too large, and you get the error shown.  The best
workaround is to break up your page into a few smaller pages, connected
with <c:import> or <jsp:include>, if possible.  Note that when you use
scoped variables (versus scripting variables), it's much easier to do
this, so JSTL should help in that regard.

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com
(coming in July 2002 from Manning Publications)


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