RE: Line of Code Counter?
Check out JavaNCSS (NCSS = non-commenting source statements). In addition to simple lines of code in your application, it counts lines per method, methods per class, and classes per package, to name just a few metrics. The output is in a nice tabular format, easy to read and easy to analyze. http://www.kclee.com/clemens/java/javancss/ It only counts Java code, though, not C++. John -Original Message- From: Lou Farho [SMTP:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 10:11 AM To: Struts user Subject: Line of Code Counter? Can anyone point me to a good utility for performing line of code counter for Java and C++? The counter needs to count statements. Thanks! Lou
RE: AW: Struts vs. JADE (from IBM) - feature and usability comparison - need help!
Two points to consider: 1. The WAS 4.0 admin tool is based on Struts 0.5, which is quite antiquated. That's not a hearty endorsement for Struts 1.0. 2. IBM is a *big* organization. The fact that the consulting group may be pushing something besides Struts while the WAS group is using Struts is not that odd. I don't know that either recommendation would be considered an endorsement of the whole company, but simply the current favorite of that group. I'm also curious to hear of other JADE experiences, since it seems to be cropping up in a number of companies all of a sudden. John -Original Message- From: Doug Smith [SMTP:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 10:16 AM To: [EMAIL PROTECTED] Subject: Re: AW: Struts vs. JADE (from IBM) - feature and usability comparison - need help! Also, Struts is bundled with WAS 4.0 and used to build their web-based admin tools. I'd say that's quite an endorsement from Big Blue. Doug D. Veniseleas venisele@uni-duess To: '[EMAIL PROTECTED]' eldorf.de [EMAIL PROTECTED] cc: 09/07/2001 01:05 AM Subject: AW: Struts vs. JADE (from IBM) - Please respond to feature and usability comparison -need help! struts-user Hi, in their Redbook for the Websphere Appl-Server they describe struts in detail. I had the impression, they liked struts. Dimitris -Ursprüngliche Nachricht- Von: Esterkin, Alex [SMTP:[EMAIL PROTECTED]] Gesendet am: Donnerstag, 6. September 2001 19:49 An: [EMAIL PROTECTED] Betreff: Struts vs. JADE (from IBM) - feature and usability comparison - need help! Wichtigkeit: Hoch Hello, There has emerged a new proprietary MVC framework called JADE and developed and promoted by IBM Consulting National Practice people. I sense it is inferior in comparison to Struts, but I don't have enough information about JADE, and IBM is liked very much at my firm. I need to quickly prepare a detailed feature for feature technical comparison. I wonder whether there are people on this discussion board, who are familiar with JADE, and who could share their opinions or insights in this regards. Thanks!!! Best regards, Alex Esterkin Fidelity Investments E-mail: [EMAIL PROTECTED] =
Security question - how to provide faithful redirect?
This is a question that's only partially related to Struts, but on the topic of application security. The crux of it is trying to understand how to faithfully redirect a request, including the HTTP method. For a number of reasons, we've chosen to implement a lightweight authentication and authorization framework for our application that hangs off of ActionServlet (in short, we needed something in place until a higher-level decision on 3rd-party access control could be made by others outside our group.) We check on each request that we have a user logged in (by the presence of a user object in the session), and then that they have permission to request the given resource. Our definition of resource is a combination of HTTP method (GET, POST) and URL, similar to what the servlet 2.2 spec defines. The general flow is to (a) check whether the user is authenticated (b) if not, we save the URI they requested and forward them to our logon page (c) after logon, we check their credentials, and if they pass we redirect to the saved URI. The problem we're having is that it appears that the redirect done in (c) is always turned into a GET request, even if the original request was a POST. If we have a valid permission for the original POST request, we may well not have one defined for the GET method, and we'll get an authorization failure. Now, I've come to realize that this may just be an academic question, since on a POST, we will have lost our form data from the original request by the time the user has gone to a logon page and submitted that (unless we go to more extraordinary measures to save it), so that I'm starting to believe that our safer strategy in (c) is to simply redirect to our home page after authentication, in all circumstances, since everyone has rights to that URL via GET or POST. However, it's been gnawing at me that others have had to deal with something like this, but I don't know how. I've tried looking through the Tomcat 3.2.1 source to understand how it does form-based logon, and I'm still stymied. I can see where the AccessIntercepter stores the URI before a logon attempt, and then sends it back with a 302 response after logon, but that technique would also seem to lose the original HTTP method, and fail the same way in this situation (although I haven't taken the time to setup a secured Tomcat webapp to test the theory.) I've even gone so far as to check out the HTTP 1.1 spec to understand the redirect directive, but even that doesn't come right out and say the HTTP method is lost (or preserved) on redirect. The closest thing of interest is a note in section 10.3.3, describing the 302 (temporarily moved) request: Note: When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request. So perhaps its a browser bug, but we're using IE 5, which I would hope would be a little more current. Thanks for any clues, insights, or tales of similar woe. John
RE: Struts on IBM WAS 4.0 - Error removing attributes from reques t sc ope!
Pardon my skepticism, but from all appearances, the WAS 4.0 GA release is
out (nothing on the IBM WebSphere site says that the 4.0 you can now
download is beta), and this particular issue is *not* resolved. The
antiquated version of Jasper is still included. And from the response to my
question about this on this list a month ago or so, just dropping in a new
Jasper is not something that's likely to happen quickly. If this issue was
just brought to their attention a couple of weeks ago (meaning that they
didn't know about it), I wouldn't hold my breath on a quick resolution.
I'd love to see the fix appear in a fixpack (and soon) but we tried out 4.0
as soon as it was released the end of June, primarily to see if this issue
was resolved, and were disappointed.
John
-Original Message-
From: Pravin George [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, July 24, 2001 9:26 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Struts on IBM WAS 4.0 - Error removing attributes from
reques t sc ope!
Hi everyone,
I wanted to clarify the status of Struts and Websphere 4
compatability. As a business partner to IBM, we are on the beta testing
program for Websphere 4.0 . This particular issue was brought to their
attention a couple of weeks ago. Last week we received word that it has
been fixed in the latest beta build and will not be an issue in the
final GA release.
Pravin George,
Software Engineer,
eBuilt Inc. ,
Irvine, CA 92614.
RE: Struts on IBM WAS 4.0 - Error removing attributes from
reques t sc ope!
Date:
Tue, 24 Jul 2001 13:16:48 -0700
From:
Calabrese, Jason [EMAIL PROTECTED]
Reply-To:
[EMAIL PROTECTED]
To:
'[EMAIL PROTECTED]'
[EMAIL PROTECTED]
I'm running struts on Websphere 3.5.4 and had similar problems.
This is the response I got.
Check this out..
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg10964.html
And..
Sure thing - I already sent it but the list refused it due to its file
size.
As an alternative, I'll put it up on my personal FTP space and anyone
who
wants it can download it from there! :)
Struts.jar with Form tag modifications:
http://www.enfused.com/struts.jar
-Original Message-
From: Mark Wilson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 24, 2001 1:07 PM
To: '[EMAIL PROTECTED]'
Subject: Struts on IBM WAS 4.0 - Error removing attributes from request
sc ope!
Hello, thanks for you're attention.
I am deploying the struts-example app on IBM Websphere App Server 4.0
and
receive an IllegalArgumentException - Can't remove attribute from
request
scope.
the situation:
I have drilled into the problem and discovered that IBM is using a
significantly different implementation of the class,
org.apache.jasper.runtime.PageContextImpl. Their class alters the logic
of
removing attributes using the methods removeAttribute(String s, int i)
and
removeAttribute(String s).
I have included the code in the next section of the e-mail. In summary,
using WAS 4.0, attributes are not removed from request scope.
This conflicts most directly with the struts framework class,
org.apache.struts.taglib.html.FormTag. FormTag calls
pageContext.removeAttribute(Constants.BEAN_KEY,
PageContext.REQUEST_SCOPE)
and pageContext.removeAttribute(Constants.FORM_KEY,
PageContext.REQUEST_SCOPE) within the doEndTag() method.
Either of these method calls will generate an IllegalArgumentException
on
WAS 4.0.
the code (more or less):
org.apache.jasper.runtime.PageContextImpl (note: not the same code as
used
in tomcat's implementation...)
public void removeAttribute(String s, int i)
{
switch (i)
{
case PAGE_SCOPE:
pageScopeAttributes.remove(s);
break;
case REQUEST_SCOPE:
throw new IllegalArgumentException(Can't remove Attributes
from
request scope);
case SESSION_SCOPE:
if (session == null)
throw new IllegalArgumentException(Can't access
SESSION_SCOPE without an HttpSession);
theSession.removeAttribute(s);
break;
case APPLICATION_SCOPE:
theContext.removeAttribute(s);
break;
}
}
// and ...
public void removeAttribute(String s)
{
pageScopeAttributes.remove(s);
}
// (pageScopeAttributes is a Hashtable of objects stored at Page
scope
only!)
a partial solution:
Replacing the removeAttribute(String s, int i) method calls with
removeAttribute(String s) within the struts class, FormTag.doEndTag()
relieves the exception, but on WAS 4.0, it will not remove the
attribute!
(in fact, only attributes found in page scope will be removed when the
method, removeAttribute(String s) is called.)
testing results:
Even though the
RE: Struts on IBM WAS 4.0 - Error removing attributes from reques t sc ope!
Yes, WAS 4.0 is a big step forward in usability. However, if you look closely at the struts.jar file that is ships with, it's Struts 0.5. That notwithstanding, the console looks like a pretty sophisticated app. Probably not trivial for them to move it to Struts 1.0. John -Original Message- From: Assenza, Chris [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, July 25, 2001 11:22 AM To: '[EMAIL PROTECTED]' Subject: RE: Struts on IBM WAS 4.0 - Error removing attributes from reques t sc ope! I had no problems with our test run with WAS 4.0 using the modified struts.jar I posted - heck the console is built with Struts. :-P Frankly, I feel like WAS 4.0 is a dream-come true as far as usability and administration. Yeah, Java isn't up to spec, but what else is new. At least it is easier to maintain. Our struts app deployed flawlessly from the EAR file without any extra manipulation from me outside of using their Application Assembly tool (ie. no moving WEB-INF, no pulling out DTD's, nadda). :D Be that as it may, our app didn't work 100%, but I am pretty sure that was an unrelated issue (IIS wasn't configured properly). Chris -Original Message- From: Pravin George [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 25, 2001 5:13 AM To: [EMAIL PROTECTED] Subject: Re: Struts on IBM WAS 4.0 - Error removing attributes from request sc ope! you're right Websphere 4.0 is a pain to work with. I did get a struts application running on 3.5.3 but not on any later version. Calabrese, Jason wrote: Why can't IBM keep up. I don't think I'd ever recommended Websphere or any other IBM java application. -Original Message- From: Boulatian, Misak [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 25, 2001 8:07 AM To: [EMAIL PROTECTED] Subject: RE: Struts on IBM WAS 4.0 - Error removing attributes from reques t sc ope! It seems like you have the same problem as I was having with Powertier app server. The solution was that the powertier current release was coming with an older jasper libraries (jsp engine) but struts is using the newer ones. I hope this helps. Thanks Misak -Original Message- From: Pravin George [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 24, 2001 7:26 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Struts on IBM WAS 4.0 - Error removing attributes from reques t sc ope! Hi everyone, I wanted to clarify the status of Struts and Websphere 4 compatability. As a business partner to IBM, we are on the beta testing program for Websphere 4.0 . This particular issue was brought to their attention a couple of weeks ago. Last week we received word that it has been fixed in the latest beta build and will not be an issue in the final GA release. Pravin George, Software Engineer, eBuilt Inc. , Irvine, CA 92614. RE: Struts on IBM WAS 4.0 - Error removing attributes from reques t sc ope! Date: Tue, 24 Jul 2001 13:16:48 -0700 From: Calabrese, Jason [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] I'm running struts on Websphere 3.5.4 and had similar problems. This is the response I got. Check this out.. http://www.mail-archive.com/struts-user@jakarta.apache.org/msg10964.html And.. Sure thing - I already sent it but the list refused it due to its file size. As an alternative, I'll put it up on my personal FTP space and anyone who wants it can download it from there! :) Struts.jar with Form tag modifications: http://www.enfused.com/struts.jar -Original Message- From: Mark Wilson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 24, 2001 1:07 PM To: '[EMAIL PROTECTED]' Subject: Struts on IBM WAS 4.0 - Error removing attributes from request sc ope! Hello, thanks for you're attention. I am deploying the struts-example app on IBM Websphere App Server 4.0 and receive an IllegalArgumentException - Can't remove attribute from request scope. the situation: I have drilled into the problem and discovered that IBM is using a significantly different implementation of the class, org.apache.jasper.runtime.PageContextImpl. Their class alters the logic of removing attributes using the methods removeAttribute(String s, int i) and removeAttribute(String s). I have included the code in the next section of the e-mail. In summary, using WAS 4.0, attributes are not removed from request scope. This conflicts most directly with the struts framework class, org.apache.struts.taglib.html.FormTag. FormTag calls pageContext.removeAttribute(Constants.BEAN_KEY, PageContext.REQUEST_SCOPE) and pageContext.removeAttribute(Constants.FORM_KEY, PageContext.REQUEST_SCOPE) within the doEndTag() method. Either of these method
RE: Struts 1.0 on WebSphere 3.5.4?? (and on WAS 4.0)
Sadly, it looks like WAS 4.0 is still using a buggy Jasper library, as the Struts 1.0 Final sample app still complains with the same error. IBM Marketing apparently doesn't understand what it means to support open standards (http://www7b.boulder.ibm.com/wsdd/products/supportstds.html). Just saying so doesn't make it so. And if they have passed Sun's J2EE certification test for their Jasper implementation, then I'd have to also say that Sun's test suite needs to be improved. John -Original Message- From: Assenza, Chris [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, July 03, 2001 7:54 AM To: '[EMAIL PROTECTED]' Subject: RE: Struts 1.0 on WebSphere 3.5.4?? The problem I reported to the list the other day (that error) in JBoss 2 w/ Tomcat 3.2b7 is actually the same issue as this. Granted, I haven't actually tested this in WebSphere, but it is the same issue and others have tried it with success IIRC. Anyway, the problem is (as others have previously reported), the JASPER version used by the WebSphere servlet engine is not up to the latest spec and as such does not support the way the Form tag is currently written. If you like, I can attach an updated Struts.jar that has the fix compiled and ready to go. If you want to change it yourself, here's the code: (This fix was suggested by David Janovy) In doEndTag on the Form tag, change: pageContext.removeAttribute(Constants.BEAN_KEY, PageContext.REQUEST_SCOPE); pageContext.removeAttribute(Constants.FORM_KEY, PageContext.REQUEST_SCOPE); To: pageContext.getRequest().removeAttribute(Constants.BEAN_KEY); pageContext.getRequest().removeAttribute(Constants.FORM_KEY); pageContext.removeAttribute(Constants.BEAN_KEY); pageContext.removeAttribute(Constants.FORM_KEY); Chris -Original Message- From: Christine Eckstein [mailto:[EMAIL PROTECTED]] Sent: Monday, July 02, 2001 6:03 PM To: [EMAIL PROTECTED] Subject: Struts 1.0 on WebSphere 3.5.4?? Has anyone been able to get Struts 1.0 to work on WebSphere 3.5.4 (yes, that's with the new patch 4)? I can get index.jsp to run, but I'm not getting farther than that. I've made the recommended DTD changes, but that didn't help (no ActionMapping, or similar, errors have shown up in the log.) What I'm looking to find out is if I need to go through the additional process of modifying the Struts code as was declared necessary for 3.5.2 and below. Any ideas? Thanks for your help The following is the reported error: - Error 500 An error has occured while processing request:http://hca320872k/strutsexample/logon.jsp Message: Server caught unhandled exception from servlet [jsp11]: cant remove Attributes from request scope Target Servlet: jsp11 StackTrace: -- -- Root Error-1: cant remove Attributes from request scope java.lang.IllegalArgumentException: cant remove Attributes from request scope at java.lang.RuntimeException. init (RuntimeException.java:49) at java.lang.IllegalArgumentException. init (IllegalArgumentException.java:45) at org.apache.jasper.runtime.PageContextImpl.removeAttribute(PageContextImpl. ja va:23 6) at org.apache.struts.taglib.html.FormTag.doEndTag(FormTag.java:591) at _logon_jsp_1._jspService(_logon_jsp_1.java:357) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:127) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.runtime.JspServlet$JspServletWrapper.service(JspServlet. ja va:39 6) at org.apache.jasper.runtime.JspServlet.serviceJspFile(JspServlet.java:718) at org.apache.jasper.runtime.JspServlet.service(JspServlet.java:872) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.ibm.servlet.engine.webapp.StrictServletInstance.doService(ServletManag er .java :626) at com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service(StrictLifecy cl eServ let.java:160) at com.ibm.servlet.engine.webapp.IdleServletState.service(StrictLifecycleServ le t.jav a:287) at com.ibm.servlet.engine.webapp.StrictLifecycleServlet.service(StrictLifecyc le Servl et.java:105) at com.ibm.servlet.engine.webapp.ServletInstance.service(ServletManager.java: 36 0) at com.ibm.servlet.engine.webapp.ValidServletReferenceState.dispatch(ServletM an ager. java:775) at com.ibm.servlet.engine.webapp.ServletInstanceReference.dispatch(ServletMan ag er.ja va:701) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.handleWebAppDispatch (W ebApp RequestDispatcher.java:478) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.dispatch(WebAppReque st Dispa tcher.java:234) at com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward(WebAppReques tD ispat cher.java:138)
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(PageContextImpl.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
RE: WebSphere, Jasper and Struts 1.0b3
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.
Thanks for the help, though.
John
-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
RE: WebSphere, Jasper and Struts 1.0b3
Thanks for the context setting, Kyle. I'm sure that the WebSphere code base is mind-boggling big, compared to what most of us work on. It might be easier to swallow, though, if WebSphere's J2EE compliance weren't so loudly trumpeted. Plainly, they're not fully compliant with JSP 1.1. And it's fine that you and I and other developers know (wink wink) that hardly any vendors are fully compliant with specs, but it makes it that much harder to convince managers that the reason that your app isn't ready to ship is because it can't run in a particular environment - What do you mean? Are you sure? They said they were compliant - look at their web site, and all of their literature! It can't be wrong if everybody else is using it. Are you sure it's not a problem with our code? It's a frustrating waste of energy. Again, I do appreciate the difficulty of managing a gargantuan project. I'm more disappointed in IBM's marketing department than in their technical team. John -Original Message- From: Kyle Brown [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 1:28 PM To: [EMAIL PROTECTED] Subject: RE: WebSphere, Jasper and Struts 1.0b3 I can't speak officially for IBM on this, but the short answer is testing. Building an application server is an enormous undertaking. The application servers themselves are some of the biggest Java applications on the planet. We're easily talking about close to a million lines of code. As such they have enormous test suites and enormous testing requirements -- especially since everyone wants the application servers to work just right for THEIR apps. All this testing entails manpower requirements, and even a company as big as IBM can only afford to spend so much on testing... Every change to a core feature (like the JSP compiler) has ramifications all the way up and down the product. For instance, suppose that this particular build of Jasper requires a particular build of Xerces -- well, multiple other parts of the system depended on the LAST build of Xerces, and the new build just changes one or two minor things... you get the picture. This is the reason why these decisions aren't made lightly, and only come at fixed intervals. Kyle Brugge, John [EMAIL PROTECTED] on 06/13/2001 01:55:00 PM Please respond to [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] cc: Subject: RE: WebSphere, Jasper and Struts 1.0b3 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. Thanks for the help, though. John -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
RE: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough
How you feel about type safety and having a/the compiler help you out will also play into your choice here. For all of the pain that creating JavaBean classes causes, they do create a well-defined interface that developers of JSPs can use to rely on to know what data is available. If all you're passing back is a Hashmap, then there needs to be an agreement between the JSP develper and the Action developer as to what that Hashmap will contain. If those developers happen to be the same person, that's usually not a problem (unless you tend to forget what you tell yourself ;-) If they are different people, then you might want the agreement to be more than just a verbal agreement during a hallway meeting. Which leads to documenting what the Hashmap will contain, which leads to having to maintain the documentation... Having JavaBeans as the format of your data also means that the JSP compiler can tell you when you try to refer to a property that isn't there, or is misspelled. The compiler can be your friend here. However, if your JSP refers to an entry in a Hashmap and gets it wrong, it's harder to track down the problem. Is the field on the form blank because there isn't any data there, or because you asked for the wrong entry name? There's definite flexibility advantages to using dynamic collections of data, but realize that it comes at a certain cost. John -Original Message- From: Stephen Schaub [SMTP:[EMAIL PROTECTED]] Sent: Thursday, April 26, 2001 6:52 AM To: [EMAIL PROTECTED] Subject: Re: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough I have been pondering this very issue myself recently. For example, I would like to be able to display the results of a query in an HTML table. I don't want to have to create a Javabean to hold the attributes for the result set, because every time I want to tweak the result set, I have to 1. Add/remove/change getters and setters for the JavaBean to conform to the new result set 2. Change the code that takes the data from the result set and puts it in the JavaBean 3. Update the jsp to reflect the changes In your dynamic Javabean = hashmap approach, I could easily write a generic routine that takes a result set and converts it into a collection of dynamic Javabeans. Then, when I tweak the result set, the only thing I have to do is #3. I think I've read somewhere on the list about an effort to improve the scenario I just described, but there are a lot of other scenarios where dynamic JavaBeans would come in handy, and I hope it is officially addressed. Stephen Schaub - Original Message - From: Iraklis Kourtidis [EMAIL PROTECTED] Sent: Wednesday, April 25, 2001 12:27 PM Subject: (architectural issue/feature request) JavaBeans in Struts aren't flexible enough Hi all, I was wondering what your views on the following are: JavaBeans seem to only allow fixed properties (say foo and bar), and the tags that operate on them (e.g. bean:write) essentially call getters getFoo() and getBar(). However, this means that any time we're in the action class and we want to package some information to send to the JSP, we need to write a Java class with the appropriate properties and getters. This quickly becomes tiresome and causes code bloating; if I want to avoid scriptlets in my JSP, I have to use Javabeans, so for pretty much every Action class I need to add such a new Java class. A better way would be for Javabeans to be (essentially) some sort of subclass of java.util.Map, so that I can add properties at runtime. Here's some sample code: GenericJavabean jb = new GenericJavabean(); jb.addProperty(foo, value of foo); jb.addProperty(bar, value of bar); Then, there could be some other tag, say bean:write2 whose property attribute will not correspond to a getter function, but will instead call (internally) bean.getProperty(foo). In short, Javabeans, the current mechanism of passing information to the JSP for display purposes, are limiting because they have to be defined at *compile* time. It is not practical (in terms of efficiency and complexity) to add getter functions to a class at runtime (we've considered that), so we need to essentially create new Javabean classes. Am I the only one who gets bothered by this? I was wondering what the rest of you do. Do you just resign to creating new Java classes every time you want to put something on the request and send it to the JSP? thanks for your input, Iraklis
RE: How can a Struts Action developer best document the system for a JSP developer?
Title: RE: How can a Struts Action developer best document the system for a JSP developer? Bryan, You might check out a recent article on JavaWorld called Doclet your Servlet (http://www.javaworld.com/javaworld/jw-03-2001/jw-0302-doclets.html) that describes a custom doclet that understands some custom doc tags. It would probably take some customization to work with Struts Actions, since it looks like it uses introspection to look for instances of true servlets. I've been thinking of the same problem, and think that you could get pretty good mileage out of a simple XSL template that transformed the struts-config.xml into a clearer HTML description of the actions, their navigation and form expectations. It could handle #2 and #3 below easily; #4 and #5 would be harder. You could even tie this into the JavaDoc of the ActionForms by creating links from the form names to the area where your JavaDoc lives. I'm not an XSL expert, but I've done some transforms before and figure this wouldn't take very long to create - the key for me is just finding the time now ;-). If I come up with something, I'll forward it to the group, unless someone beats me to it. John -Original Message- From: Bryan Field-Elliot [SMTP:[EMAIL PROTECTED]] Sent: Saturday, March 17, 2001 6:12 PM To: [EMAIL PROTECTED] Subject: How can a Struts Action developer best document the system for a JSP developer? I am struggling right now with how to properly and efficently document my Struts application for my JSP developer (who is by no means a Java expert). Specifically, I want to document each Action as well as each ActionForm that I code, including things like: 1. the pages I expect the user to have come from 2. the pages to which I might forward, or redirect, the user after completing the action 3. The beans I expect to be in place prior to submitting to my action 4. The beans I will set up with values for the resulting JSP page to work with 5. The errors (html:errors) I may set up And anything else that might be appropriate. I'd like to do so in a way that lets me rely on Javadoc, so that I can keep my documentation inside my code. Javadoc when used correctly will also let me do things like see also the Bean documentation (from the Action documentation). I am curious if anyone has developed a template action or bean, which makes best use of Javadoc and which I can cut-and-paste at the head of every one of my Action classes, etc? Thanks, Bryan
RE: How can a Struts Action developer best document the system fo r a JSP developer?
Title: RE: How can a Struts Action developer best document the system fo r a JSP developer? Thanks Derek, I'd appreciate seeing your work. You're right, that struts-config.xml doesn't have enough to be completely useful, but I figure its a start. John -Original Message- From: Derek Longmuir [SMTP:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 2:43 PM To: '[EMAIL PROTECTED]' Subject: RE: How can a Struts Action developer best document the system fo r a JSP developer? Hi Bryan and John, I have created something like this with XSL that converts the (old) action.xml and (new) struts-config.xml files and produces a graph showing the various forwards, forms, actions, etc. I then use dot to convert the graph into a gif. It isn't quite as enlightening as I thought it would be, but certainly produces interesting pictures. :-) This is primarily due to the fact that the struts-config.xml doesn't hold all the information - I think to produce a better overview you would have to also parse the corresponding JSPs for their tags, and maybe even the action classes themselves. I was planning on refining it a little more before releasing it to the list, but I'll work on getting it up on a web page in the next couple of days for you. John, maybe you can take it and add what you think is missing. :-) Thanks, Derek. -Original Message- From: Brugge, John [ mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 9:56 AM To: '[EMAIL PROTECTED]' Subject: RE: How can a Struts Action developer best document the system fo r a JSP developer? Bryan, You might check out a recent article on JavaWorld called Doclet your Servlet ( http://www.javaworld.com/javaworld/jw-03-2001/jw-0302-doclets.html) that describes a custom doclet that understands some custom doc tags. It would probably take some customization to work with Struts Actions, since it looks like it uses introspection to look for instances of true servlets. I've been thinking of the same problem, and think that you could get pretty good mileage out of a simple XSL template that transformed the struts-config.xml into a clearer HTML description of the actions, their navigation and form expectations. It could handle #2 and #3 below easily; #4 and #5 would be harder. You could even tie this into the JavaDoc of the ActionForms by creating links from the form names to the area where your JavaDoc lives. I'm not an XSL expert, but I've done some transforms before and figure this wouldn't take very long to create - the key for me is just finding the time now ;-). If I come up with something, I'll forward it to the group, unless someone beats me to it. John -Original Message- From: Bryan Field-Elliot [SMTP:[EMAIL PROTECTED]] Sent: Saturday, March 17, 2001 6:12 PM To: [EMAIL PROTECTED] Subject: How can a Struts Action developer best document the system for a JSP developer? I am struggling right now with how to properly and efficently document my Struts application for my JSP developer (who is by no means a Java expert). Specifically, I want to document each Action as well as each ActionForm that I code, including things like: 1. the pages I expect the user to have come from 2. the pages to which I might forward, or redirect, the user after completing the action 3. The beans I expect to be in place prior to submitting to my action 4. The beans I will set up with values for the resulting JSP page to work with 5. The errors (html:errors) I may set up And anything else that might be appropriate. I'd like to do so in a way that lets me rely on Javadoc, so that I can keep my documentation inside my code. Javadoc when used correctly will also let me do things like see also the Bean documentation (from the Action documentation). I am curious if anyone has developed a template action or bean, which makes best use of Javadoc and which I can cut-and-paste at the head of every one of my Action classes, etc? Thanks, Bryan
