On Wed, 13 Jun 2001, Brugge, John wrote:
> Thanks, Steve, for the gentle pointer to a previously discussed topic ;-)
> Sorry, I must have been asleep when that thread was going past.
>
> Does anyone know why IBM and others would be so slow and/or reluctant to
> upgrade their tools with software that's freely available, and is improving
> their own product? I know that the answer is probably that it's much more
> complicated than any of us can imagine, if we only knew the internal
> structure of these servers, but it still doesn't make sense.
>
Having been involved in product release cycles for quite a while, I can
have some sympathy for what vendors go through :-). It's not just an
issue of fixing the bug in the CVS (or whatever) sources -- there is an
incredible amount of integration and testing needed to create a release
for something as large as Websphere.
Of course, the fundamental assumption in getting this fixed is that
someone has reported the problem to IBM, and that they have acknowledged
it. Without that, nothing's ever going to be changed.
> Thanks for the help, though.
> John
>
NOTE: The commonly proposed workaround for this (delete the two
removeAttribute lines from FormTag.doEndTag()) has a negative consequence,
which is the reason that I haven't changed the Struts code itself. The
problem is that the scope of the scripting variable corresponding to your
form bean is defined as NESTED -- in other words, it is visible only
within the body of the <html:form>.
The removal of the request attributes is to make those attributes have the
same scope -- otherwise, the request attributes remain defined for the
remainder of the page. This can lead to programming errors if you depend
on it, because with this patch things like <bean:write> will still be able
to see the form bean after the </html:form> tag, when they should not be
able to.
Therefore, I'm not planning on changing this code in Struts 1.0 final.
Craig
> > -----Original Message-----
> > From: Ritter, Steve [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 13, 2001 11:19 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: WebSphere, Jasper and Struts 1.0b3
> >
> > Hi John,
> >
> > This problem has been discussed many times in this mailgroup, you aren't
> > alone! I guess there are quite a few servlet engines that are using an
> > old version of Jasper. You might want to check the mailgroup archives,
> > here is a link to a thread that discusses alternatives -- and a link to
> > the bugzilla entry for this (within struts):
> >
> >
> > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08663.html
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=932
> >
> > I think severl people have been successfull in getting their containers to
> > use newer versions of Jasper without help from their vendor.
> >
> > --Steve
> >
> > > -----Original Message-----
> > > From: Brugge, John [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, June 13, 2001 9:00 AM
> > > To: '[EMAIL PROTECTED]'
> > > Subject: WebSphere, Jasper and Struts 1.0b3
> > >
> > >
> > > We're trying to deploy our Struts application to WebSphere
> > > 3.5.4, and are
> > > running into problems with what appears to be an outdated
> > > version of Jasper
> > > shipping with WebSphere. I'm wondering if others have seen
> > > similar problems.
> > >
> > > [Note: we've been doing development using Tomcat 3.2.1, with
> > > no problems.]
> > >
> > > The first problem came when we tried deploying the app on
> > > WebSphere 3.5.3
> > > (NT) with the Struts 1.0b2 release. We got the following stack trace
> > > (snippet included) that I traced to an old version of the
> > > PageContextImpl
> > > class
> > >
> > > java.lang.IllegalArgumentException: cant remove Attributes
> > > from request
> > > scope
> > > at java.lang.RuntimeException.(RuntimeException.java:49)
> > > at
> > > java.lang.IllegalArgumentException.IllegalArgumentException.java:45)
> > > at
> > > org.apache.jasper.runtime.PageContextImpl.removeAttribute(Page
> > > ContextImpl.ja
> > > va:236)
> > > at
> > > org.apache.struts.taglib.html.FormTag.doEndTag(FormTag.java:591)
> > >
> > > A change in the Struts FormTag that was just introduced with
> > > b2 makes the
> > > removeAttribute(Constants.BEAN_KEY,
> > > PageContext.REQUEST_SCOPE) call, a call
> > > which should be legal for Jasper. The Jakarta CVS log for
> > > org.apache.jasper.runtime.PageContextImpl shows that the bug
> > > above was fixed
> > > w/ v1.13.2.3 last November, and included in Tomcat 3.2.1 but
> > > apparently
> > > completely ignored by IBM. The only reasonable(?) short term
> > > remedy we see
> > > is to back off to Struts 1.0b1 until IBM gets its act
> > > together. We applied
> > > the WebSphere 3.5.4 patch and found it still has the bug.
> > >
> > > The second problem came once we'd recompiled with the Struts 1.0b1
> > > libraries, and redeployed to WebSphere. This time our home
> > > page came up
> > > successfully (a JSP, invoked through an Action and doing
> > > database I/O), but
> > > the next page threw another Jasper exception:
> > > org.apache.jasper.JasperException: Unable to compile class for JSP
> > > "/WEB-INF/jsp/searchShipments.jsp"
> > > C:\WebSphere\AppServer\temp\default_host\SHIPS_Web\WEB_2D_INF\
> > > jsp\_searchShi
> > > pments_jsp_0.java:21: Branch is too large, Internal
> > > restriction. public
> > > class _searchShipments_jsp_0 extends HttpJspBase { ^ 1 error
> > > at javax.servlet.ServletException.(ServletException.java:107)
> > > at org.apache.jasper.JasperException.(JasperException.java:73)
> > > at
> > > org.apache.jasper.compiler.Compiler.compile(Compiler.java:298)
> > > at
> > > org.apache.jasper.runtime.JspServlet.loadJSP(JspServlet.java:943)
> > >
> > >
> > > Once again, I don't know for sure which version of Jasper IBM
> > > is using, but
> > > from looking at the Jakarta CVS logs again, there's indirect
> > > evidence that
> > > the code is pretty old, since JspServlet (last line of the
> > > stack trace) was
> > > moved from the runtime package to a 'servlet' package back in
> > > June, 2000.
> > >
> > > This error is tougher to track, since WebSphere doesn't
> > > appear to be saving
> > > the java file for the JSP to disk, so I can't look at the
> > > actual generated
> > > code (if anyone knows a WebSphere setting that tells it to
> > > save these .java
> > > files, I'd appreciate it!)
> > >
> > > I can't see anything on the upcoming WebSphere 4.0 release
> > > that lists bugs
> > > fixed/changes incorporated, and our release date is going to
> > > come sooner
> > > than the internal operations group is going to be comfortable
> > > moving to 4.0.
> > > Any suggestions or insights into the problem appreciated!
> > > (except "Just run
> > > Tomcat!" We've tried that one, believe me...)
> > >
> > > Thanks,
> > > John
> > >
>
