RE: Handling session timeouts
unsubscribe
Please Unsubscribe-tanver.afzal@nationallife.ca
Please [EMAIL PROTECTED]
Re: Multipart request handling
On Sun, Jun 10, 2001 at 07:09:06PM -0700, Martin Cooper wrote: Incze, The fix for this - unwrapping the request - has been made on the main trunk (Struts 1.1) in CVS, but has not been applied to the Struts 1.0 branch. If you can, you might want to try using the latest nightly build until the change gets into 1.0. There is a bug in Bugzilla (#2039) for this, so hopefully it will be fixed before 1.0 ships. -- Martin Cooper My fault that haven't checked the bugzilla. Just searched the mail lists at www.mail-archive.com. Haven't seen the sign of this patch but very recent messages on the user list on the topic. Thanks for the pointer I'll go for the nightly build. incze
OptionsTag and SelectTag proposed changes
Hi,
I wanted to fill in a Select with Options that are filled out of a Collection.
where i could specify a value and label property of the objects that are in that
connection.
Then i saw that this was already implemented bug only for Collection that are in the
request.
But that was not the case at my place. Because the collection did came from the Form
(where else??)
So in the OptionsTag.doEndTag() there is this line:
Iterator collIterator = getIterator(collection, null);
And that getIterator does this with that name (collection string)
Object bean = pageContext.findAttribute(beanName);
So it wants the collection in the page/request/session scope directy. But that is not
what i want
it want this:
collIterator = getIterator(name, collection);
Where the name is null (then the Constants.BEAN_KEY is used which is the form) or what
every i want
So i changed it so that the current behaviour is excactly the same because it does if
first as it was now
But if it can't find it it tries it my way.
I replaced the Iterator collIterator = getIterator(collection, null); line with these
onces:
Iterator collIterator = null;
Object colBean = pageContext.findAttribute(collection);
if (colBean == null)
{
collIterator = getIterator(name, collection);
}
else
{
collIterator = getIterator(collection, null);
}
Now another problem arised. How do i get the right onces selected if i use a
Collection?
Because how does the current selecttag know which where it must get the the right
selected
values with which it should compare it with the value of the options (that is get from
the collection)
Because the current behaviour is this:
That i calls the BeanUtils.getArrayProperty() for that and does a normal toString on
that object
if it is not a collection and a toString of the values inside t he collection or array
if it is such a thing.
But this is not what i want because it could just be an object (directly or inside a
collection if multi select)
where it must call getPrimaryKey() to get the right value for example. (could be the
same valueProperty
that the OptionsTag uses)
For now this doesn't have to be completely generic. I thought what must i change if i
just extend the SelectTag
of struts it self. Then i only want to change the matching values.
At this time those are generated inside the doStartTag() so i must implement that
complete doStartTag()
This is not very handy. Can the SelectTag be refactored so that the code for
generating the match values
is in there own public/protected method so that i can only replace that one with my
own?
Then the generation of the HMTL select is always the same.
i added a generateMatched() method in the SelectTag and where i put the code that is
between the else:
if (value != null)
{
match = new String[1];
match[0] = value;
}
else
{
// ALL THIS CODE IS in this method:
generateMatched();
}
Can these 2 be added?
It doesn't change any current behaviour as far as i can see, so it shouldn't be to
hard.
I attached my code with the changes.
Johan Compagner
SelectTag.java
OptionsTag.java
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html package.html
craigmcc01/06/11 09:02:52 Modified:src/share/org/apache/struts/taglib/html package.html Log: Port fix to internal hyperlink from 1.0. Revision ChangesPath 1.6 +1 -1 jakarta-struts/src/share/org/apache/struts/taglib/html/package.html Index: package.html === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/package.html,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- package.html 2001/03/31 22:19:24 1.5 +++ package.html 2001/06/11 16:02:51 1.6 @@ -8,7 +8,7 @@ forms./p div align=center p a href=#doc.Intro[Introduction]/a a href=#doc.Form[HTML Form Tags]/a -a href=#doc.Form[Other HTML Tags]/a /p +a href=#doc.Other[Other HTML Tags]/a /p /div hr
Re: [VOTE] NEW COMMITTER - Martin Cooper
Definitely +1. Craig On Mon, 4 Jun 2001, Ted Husted wrote: Martin Cooper has submitted several useful patches to Struts, has been very active on the Mailing List for as long as many of us can remember, and has shown a deep understanding of using Struts in a production environment. Martin has also volunteered to help clean up the remaining issues for beta 3, and giving him write access will help us get 1.0 out the door. I hereby propose him as a Committer; he has my +1. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html LinkTag.java
craigmcc01/06/11 10:05:04
Modified:src/share/org/apache/struts/taglib/html Tag:
STRUTS_1_0_BRANCH LinkTag.java
Log:
Correctly render an a name=my name/a element when you use
html:link linkName=my name/.
PR: Bugzilla #2109
Submitted by: Howard Moore [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.14.2.1 +5 -4
jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java
Index: LinkTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v
retrieving revision 1.14
retrieving revision 1.14.2.1
diff -u -r1.14 -r1.14.2.1
--- LinkTag.java 2001/05/12 20:34:01 1.14
+++ LinkTag.java 2001/06/11 17:05:04 1.14.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v 1.14
2001/05/12 20:34:01 craigmcc Exp $
- * $Revision: 1.14 $
- * $Date: 2001/05/12 20:34:01 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v
1.14.2.1 2001/06/11 17:05:04 craigmcc Exp $
+ * $Revision: 1.14.2.1 $
+ * $Date: 2001/06/11 17:05:04 $
*
*
*
@@ -89,7 +89,7 @@
* Generate a URL-encoded hyperlink to the specified URI.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.14 $ $Date: 2001/05/12 20:34:01 $
+ * @version $Revision: 1.14.2.1 $ $Date: 2001/06/11 17:05:04 $
*/
public class LinkTag extends BaseHandlerTag {
@@ -326,6 +326,7 @@
StringBuffer results = new StringBuffer(a name=\);
results.append(linkName);
results.append(\);
+ResponseUtils.write(pageContext, results.toString());
return (EVAL_BODY_TAG);
}
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html LinkTag.java
craigmcc01/06/11 10:39:53
Modified:src/share/org/apache/struts/taglib/html Tag:
STRUTS_1_0_BRANCH LinkTag.java
Log:
Cosmetic fix - remove a bunch of old refactored code that was commented
out.
Revision ChangesPath
No revision
No revision
1.14.2.2 +4 -132
jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java
Index: LinkTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v
retrieving revision 1.14.2.1
retrieving revision 1.14.2.2
diff -u -r1.14.2.1 -r1.14.2.2
--- LinkTag.java 2001/06/11 17:05:04 1.14.2.1
+++ LinkTag.java 2001/06/11 17:39:52 1.14.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v
1.14.2.1 2001/06/11 17:05:04 craigmcc Exp $
- * $Revision: 1.14.2.1 $
- * $Date: 2001/06/11 17:05:04 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/LinkTag.java,v
1.14.2.2 2001/06/11 17:39:52 craigmcc Exp $
+ * $Revision: 1.14.2.2 $
+ * $Date: 2001/06/11 17:39:52 $
*
*
*
@@ -89,7 +89,7 @@
* Generate a URL-encoded hyperlink to the specified URI.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.14.2.1 $ $Date: 2001/06/11 17:05:04 $
+ * @version $Revision: 1.14.2.2 $ $Date: 2001/06/11 17:39:52 $
*/
public class LinkTag extends BaseHandlerTag {
@@ -430,133 +430,5 @@
transaction = false;
}
-
-
-/*
-
-// Save any currently specified anchor string
-String anchor = this.anchor;
-int hash = href.indexOf('#');
-if (hash = 0) {
-if (anchor == null)
-anchor = href.substring(hash + 1);
-href = href.substring(0, hash);
-}
-
-// Append the transaction token, if requested and it exists
-if (transaction) {
-HttpSession session = pageContext.getSession();
-String token = null;
-if (session != null)
-token =
- (String) session.getAttribute(Action.TRANSACTION_TOKEN_KEY);
-if (token != null) {
-StringBuffer sb = new StringBuffer(href);
-if (href.indexOf('?') 0)
-sb.append('?');
-else
-sb.append('');
-sb.append(Constants.TOKEN_KEY);
-sb.append('=');
-sb.append(token);
-href = sb.toString();
-}
-}
-
-// Append a single-parameter name and value, if requested
-StringBuffer sb = new StringBuffer(href);
-if ((paramId != null) (paramName != null)) {
-if (href.indexOf('?') 0)
-sb.append('?');
-else
-sb.append('');
-sb.append(paramId);
-sb.append('=');
-Object value = RequestUtils.lookup(pageContext, paramName,
- paramProperty, paramScope);
-if (value != null)
-sb.append(value.toString());
-}
-
- // Just return the href attribute if there is no bean to look up
- if ((property != null) (name == null)) {
- JspException e = new JspException
- (messages.getMessage(getter.name));
-RequestUtils.saveException(pageContext, e);
-throw e;
-}
- if (name == null) {
-if (anchor != null) {
-sb.append('#');
-sb.append(anchor);
-}
- return (sb.toString());
-}
-
- // Look up the map we will be using
-Map map = null;
-try {
-map = (Map) RequestUtils.lookup(pageContext, name,
-property, scope);
-} catch (ClassCastException e) {
-RequestUtils.saveException(pageContext, e);
-throw new JspException
-(messages.getMessage(linkTag.type));
-}
-
- // Append the required query parameters
-href = sb.toString();
- boolean question = (href.indexOf(?) = 0);
- Iterator keys = map.keySet().iterator();
- while (keys.hasNext()) {
- String key = (String) keys.next();
- Object value = map.get(key);
-if (value == null) {
-if (question)
-sb.append('');
-else {
-sb.append('?');
-question = true;
-}
-
cvs commit: jakarta-struts/web/example/WEB-INF app.tld
craigmcc01/06/11 11:16:25 Modified:web/example/WEB-INF Tag: STRUTS_1_0_BRANCH app.tld Log: Make the name and page attributes of app:checkLogon able to accept runtime expressions. Revision ChangesPath No revision No revision 1.5.2.1 +2 -2 jakarta-struts/web/example/WEB-INF/app.tld Index: app.tld === RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/app.tld,v retrieving revision 1.5 retrieving revision 1.5.2.1 diff -u -r1.5 -r1.5.2.1 --- app.tld 2001/04/11 02:08:20 1.5 +++ app.tld 2001/06/11 18:16:24 1.5.2.1 @@ -66,7 +66,7 @@ requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue /attribute @@ -76,7 +76,7 @@ requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue /attribute
cvs commit: jakarta-struts/web/example/WEB-INF app.tld
craigmcc01/06/11 11:17:14 Modified:web/example/WEB-INF app.tld Log: Port the changes to app:checkLogon to accept runtime expressions. Revision ChangesPath 1.6 +2 -2 jakarta-struts/web/example/WEB-INF/app.tld Index: app.tld === RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/app.tld,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- app.tld 2001/04/11 02:08:20 1.5 +++ app.tld 2001/06/11 18:17:14 1.6 @@ -66,7 +66,7 @@ requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue /attribute @@ -76,7 +76,7 @@ requiredfalse/required - rtexprvaluefalse/rtexprvalue + rtexprvaluetrue/rtexprvalue /attribute
Re: Proposal
I haven't heard much in the way of a reponse on
this proposal so I guess I'll be on my own In either case, I would
like to make one more addendum to what I'm proposing in case anyone is
interested.
There are times I've found when the presentation
(input mapping) is not cut and dry. For instance, consider these
URLS:
http://demo.paytrust.com/NASApp/Pt2/DemoLogin
http://billcenterdemo.americanexpress.com/NASApp/Pt2/DemoLogin
http://billmanagerdemo.accountonline.com/NASApp/Pt2/BillCenter
http://gebillmanagerdemo.gefn.com/NASApp/Pt2/DemoLogin
http://billcenterdemo.smartmoney.com/NASApp/Pt2/DemoLogin
http://billmanagerdemo.etrade.com/NASApp/Pt2/DemoLogin
Besides all being bill payment sites, the
commonality between them is that they are all run on the same servers at
Paytrust and all use the same underlying business logic (servlets)! I
architected the presentation (JSP) to vary depending on the partner we are
currently serving up in the request. I would like to see this type of
metaphore extended to the action servlet. So, during the pre_rendering
notification, I can for instance, tell the action servlet specifically what JSP
file to use. The mappings are not fine-grain enough. In the case
above, they all are mapped to DemoLogin. The real / physical JSP that gets
loaded is determined by the request.
The hierarchy of the JSPs look like
this:
baseJSPdir { contains all of the default
JSPs that have templates to define simple variation such as color, headers, etc.
}
|
-paytrust
{ contains a set of overriding JSPs going
by the same name which are unique to the site }
-cobrandX
{ ditto (see above)
}
Any takers? Its been quite successful for me
up to now and would require minimal changes to struts...
Thanks,
Jeff
- Original Message -
From:
Jeff
Trent
To: [EMAIL PROTECTED]
Cc: Ted Husted
Sent: Wednesday, June 06, 2001 10:21
AM
Subject: Proposal
New here ... so bare with me.
I'd like to propose the following enhancement to
ActionForm:
public void
addListener(ActionFormListener);
public void
removeListener(ActionFormListener);
Here is the basics of ActionFormListener
I'm interested in to start out with:
public abstract class
ActionFormListener
{
public
static final int ACTION_TYPE_PAGE_PRE_RENDERED =
1; public static final
int ACTION_TYPE_PAGE_POST_RENDERED = 2;
public
abstract void actionFormNotify(int actionType, String context /* reserved for
future use*/);
}
---
These messages would be sent before and after the
RequestDispatcher includedor forwarded to the JSP page.
The primary reason I'm propsing this
featureis to allocate / free (respectfully) scarce resources that I
would like to be made available on the page that I do not want to serialize to
transient members of my form.
thank you,
jeffrey trent
Re: erros not displaying
Hi all, I am not getting erros when i am using html:errors/ tag, is any body knows what would be the reason? thanks regards raj
RE: erros not displaying
Please make sure that you have initialized ActionErrors with approtiate error key defined in Application Properties file. Only error messages from properties file will be displayed throught this tag. Following is the code snippet --- ActionErrors act = new ActionErrors(); ActionError err = new ActionError(partyinfoForm.payment); // partyinfoForm.payment is the key in application.properties act.add(numberpayments, err); saveErrors(request, act); return mapping.findForward(failure); Thanks, Ravi -Original Message- From: Rajasekhar Bodduluri [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 2:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: erros not displaying Hi all, I am not getting erros when i am using html:errors/ tag, is any body knows what would be the reason? thanks regards raj
Re: erros not displaying
%@ taglib uri=/WEB-INF/struts-html.tld prefix=html % Make sure to include this in your JSP - Original Message - From: Ravindran Ramaiah [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 11, 2001 11:38 AM Subject: RE: erros not displaying Please make sure that you have initialized ActionErrors with approtiate error key defined in Application Properties file. Only error messages from properties file will be displayed throught this tag. Following is the code snippet --- ActionErrors act = new ActionErrors(); ActionError err = new ActionError(partyinfoForm.payment); // partyinfoForm.payment is the key in application.properties act.add(numberpayments, err); saveErrors(request, act); return mapping.findForward(failure); Thanks, Ravi -Original Message- From: Rajasekhar Bodduluri [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 2:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: erros not displaying Hi all, I am not getting erros when i am using html:errors/ tag, is any body knows what would be the reason? thanks regards raj
RE: erros not displaying
Hi Rajasekhar, What key are you storing the errors under? --Abraham -Original Message- From: Rajasekhar Bodduluri [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 11:32 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: erros not displaying Hi all, I am not getting erros when i am using html:errors/ tag, is any body knows what would be the reason? thanks regards raj
Re: Proposal
In the environment you mentioned, each client could have it's own set of action mappings (that might all use the same servlets), with their own set of input properties and local forwardings. The way to tell an Action Servlet which JSP to use is with the local forwards. The way to get the same servlet to use a different set of forward is to map a different path. Right now you can map any URI to the ActionServlet of your choice, and have as many alternate mappings to a servlet as you need. There's a built-in input property for validation errors, and a built-in parameter property that you could use to pass arbitrary information to the servlet outside of the request. Each mapping can have any number of local forwards to response URIs, which can be chosen by the servlet using logical names. If that's not enough, extending the ActionMappings to suit your particular needs is both permitted and encouraged. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: Proposal
Ok. I guess I'm not familiar enough with struts yet to see how to apply this type of logic dynamically to the action mapping. I certainly *don't* want to assign these mappings in the .XML file if that is what you are suggesting. I do see some sense in extending the ActionMapping class to do this for me, though. thanks for the quick response, jeff - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 11, 2001 2:48 PM Subject: Re: Proposal In the environment you mentioned, each client could have it's own set of action mappings (that might all use the same servlets), with their own set of input properties and local forwardings. The way to tell an Action Servlet which JSP to use is with the local forwards. The way to get the same servlet to use a different set of forward is to map a different path. Right now you can map any URI to the ActionServlet of your choice, and have as many alternate mappings to a servlet as you need. There's a built-in input property for validation errors, and a built-in parameter property that you could use to pass arbitrary information to the servlet outside of the request. Each mapping can have any number of local forwards to response URIs, which can be chosen by the servlet using logical names. If that's not enough, extending the ActionMappings to suit your particular needs is both permitted and encouraged. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: Proposal
I think this is a very good proposal. I would
not use the action identifiers. They should just be methods of the
listener interface:
public void beforePagerRendered(...)
public void afterPageRendered(...)
This seems to be similar to filters, but 2.3
filters don't solve this problem for a struts app.
Taylor
- Original Message -
From:
Jeff
Trent
To: [EMAIL PROTECTED]
Cc: Ted Husted
Sent: Wednesday, June 06, 2001 10:21
AM
Subject: Proposal
New here ... so bare with me.
I'd like to propose the following enhancement
to ActionForm:
public void
addListener(ActionFormListener);
public void
removeListener(ActionFormListener);
Here is the basics of ActionFormListener
I'm interested in to start out with:
public abstract class
ActionFormListener
{
public
static final int ACTION_TYPE_PAGE_PRE_RENDERED =
1; public static
final int ACTION_TYPE_PAGE_POST_RENDERED = 2;
public
abstract void actionFormNotify(int actionType, String context /* reserved
for future use*/);
}
---
These messages would be sent before and after
the RequestDispatcher includedor forwarded to the JSP
page.
The primary reason I'm propsing this
featureis to allocate / free (respectfully) scarce resources that I
would like to be made available on the page that I do not want to serialize
to transient members of my form.
thank you,
jeffrey trent
Re: Proposal
You can also create and return Action Forwards on the fly return (new ActionForward( uri )); if that helps. Jeff Trent wrote: Ok. I guess I'm not familiar enough with struts yet to see how to apply this type of logic dynamically to the action mapping. I certainly *don't* want to assign these mappings in the .XML file if that is what you are suggesting. I do see some sense in extending the ActionMapping class to do this for me, though.
cvs commit: jakarta-struts/src/share/org/apache/struts/digester Digester.java
craigmcc01/06/11 12:54:51
Modified:src/share/org/apache/struts/digester Tag: STRUTS_1_0_BRANCH
Digester.java
Log:
Trim leading and trailing whitespace from the values passed to
Rule.body().
Submitted by: Nick Afshartous [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.19.2.1 +5 -5
jakarta-struts/src/share/org/apache/struts/digester/Digester.java
Index: Digester.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/digester/Digester.java,v
retrieving revision 1.19
retrieving revision 1.19.2.1
diff -u -r1.19 -r1.19.2.1
--- Digester.java 2001/04/15 22:21:18 1.19
+++ Digester.java 2001/06/11 19:54:48 1.19.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/digester/Digester.java,v 1.19
2001/04/15 22:21:18 craigmcc Exp $
- * $Revision: 1.19 $
- * $Date: 2001/04/15 22:21:18 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/digester/Digester.java,v 1.19.2.1
2001/06/11 19:54:48 craigmcc Exp $
+ * $Revision: 1.19.2.1 $
+ * $Date: 2001/06/11 19:54:48 $
*
*
*
@@ -103,7 +103,7 @@
* even from the same thread./p
*
* @author Craig McClanahan
- * @version $Revision: 1.19 $ $Date: 2001/04/15 22:21:18 $
+ * @version $Revision: 1.19.2.1 $ $Date: 2001/06/11 19:54:48 $
*/
public class Digester extends HandlerBase {
@@ -385,7 +385,7 @@
if (rules != null) {
// if (debug = 3)
// log( Firing 'body' events for + rules.size() + rules);
- String bodyText = this.bodyText.toString();
+ String bodyText = this.bodyText.toString().trim();
for (int i = 0; i rules.size(); i++) {
try {
((Rule) rules.get(i)).body(bodyText);
cvs commit: jakarta-struts/src/share/org/apache/struts/digester Digester.java
craigmcc01/06/11 12:55:44
Modified:src/share/org/apache/struts/digester Digester.java
Log:
Trim leading and trailing whitespace from the value that is passed to
Rule.body().
Revision ChangesPath
1.20 +5 -5
jakarta-struts/src/share/org/apache/struts/digester/Digester.java
Index: Digester.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/digester/Digester.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Digester.java 2001/04/15 22:21:18 1.19
+++ Digester.java 2001/06/11 19:55:40 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/digester/Digester.java,v 1.19
2001/04/15 22:21:18 craigmcc Exp $
- * $Revision: 1.19 $
- * $Date: 2001/04/15 22:21:18 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/digester/Digester.java,v 1.20
2001/06/11 19:55:40 craigmcc Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/06/11 19:55:40 $
*
*
*
@@ -103,7 +103,7 @@
* even from the same thread./p
*
* @author Craig McClanahan
- * @version $Revision: 1.19 $ $Date: 2001/04/15 22:21:18 $
+ * @version $Revision: 1.20 $ $Date: 2001/06/11 19:55:40 $
*/
public class Digester extends HandlerBase {
@@ -385,7 +385,7 @@
if (rules != null) {
// if (debug = 3)
// log( Firing 'body' events for + rules.size() + rules);
- String bodyText = this.bodyText.toString();
+ String bodyText = this.bodyText.toString().trim();
for (int i = 0; i rules.size(); i++) {
try {
((Rule) rules.get(i)).body(bodyText);
Re: digester and whitespace in XML text body
On Thu, 31 May 2001, Nick Afshartous wrote:
Adding a call to String.trim below in the Digester.endElement
method below makes surrounding white space in text elements
insignificant and consistent with the Digester documentation.
Any chance this change could get into the final 1.0 release ?
--
I just committed this fix for both 1.0 and 1.1.
Nick
Craig
public void endElement(String name) throws SAXException {
// if (debug = 3)
// log(endElement( + match + ));
List rules = getRules(match);
// Fire body events for all relevant rules
if (rules != null) {
// if (debug = 3)
// log( Firing 'body' events for + rules.size() + rules);
String bodyText = this.bodyText.toString().trim();
...
Nick Afshartous writes:
I'd like to follow up on my original post. It looks like the
digester.CallMethodRule.body method doesn't remove whitespace
from both ends of the XML body text. However, other rules
like digester.CallParamRule.body actually do by calling method
String.trim.
Maybe the call to String.trim should be in a central place
(i.e. digester.Digester) so that the individual rules don't
have to worry about removing the whitespace ?
I'd be happy to work on a patch.
--
Nick
From: Nick Afshartous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: digester and whitespace in XML text body
Date: Wed, 23 May 2001 17:11:27 -0400 (EDT)
Hi,
I'm using the digester to process the nested content in
XML tags and am noticing that the leading/trailing whitespace
doesn't seem to be removed as advertised in the doc.
For instance, the rule
digester.addCallMethod(gateway/application/app-name,
setAppName, 0);
results in the method setAppName being called with the surrounding
whitespace in
app-namefoo /app-name
If anyone has any idea how to tell the digester to ignore
the leading/trailing whitespace please let me now, thanks.
--
Nick
Re[2]: [PROPOSAL] Struts Extensions
Hello Martin, But how about such situation as follows. I can store bean-factory object in application scope. I can use it in any action to perform bean producing. But main idea of bean-factory is to perform _automatic_ bean generation by name of the action. For example - in struts-config or in external config file I define mapping between action and some kind of bean. All beans from mappings must be created to be ready to use it in appropriate actio at request processing phase before Action.perfom method call. How can I do it without extending ActionServlet? I think there is one way to implement this with current struts API - extend ActionServlet and redefine processPreprocess method to perform all 'before Action.perfom' stuff. So struts control-gear can be extended to to register external classes or servlets to perform some activity at key points of request processing - ActionForm processing, Action processing, etc. Now it can be implemented only via ActionServlet extending - is not scalable solution for my mind. Sunday, June 10, 2001, 11:20:22 PM, you wrote: MC I like this idea. I think David is right - a lot of people do extend MC ActionServlet just to initialize resources. While this idea wouldn't remove MC all of the reasons to build a custom servlet, it would provide a MC systematic - and potentially simpler - way to solve a common problem. MC -- MC Martin Cooper MC - Original Message - MC From: David Winterfeldt [EMAIL PROTECTED] MC To: [EMAIL PROTECTED] MC Sent: Sunday, June 10, 2001 11:37 AM MC Subject: Re: [PROPOSAL] Struts Extensions It might be nice if there was a way to register an interface with the ActionServlet in the config file for it to initialize a service. All the ValidatorServlet I made does is parse the xml file with the Digester and put an object into application scope. If a class could be registered, then a servlet wouldn't hang around for no reason and it wouldn't need to be defined in the web.xml. And it sounds like a lot of people extend the ActionServlet just to initialize resources on startup. David --- Ted Husted [EMAIL PROTECTED] wrote: I agree that most extensions would be best written as independant servlets that plug into the application alongside the Struts ActionServlet. Though, I'm not sure they would need to register with the ActionServlet to access other parts of the framework. I haven't worked with the Digester directly, but most of the other Struts services are already exposed through the application context. Custom tags, for example, already access the Action Mappings this way. So any other servlet in the application (since that's all JSP's are) should be able to do the same. Another example is the Generic Connection Pool. The datasource is exposed through the application context and other services, like the TagLibs JDBC tags, can use the pool without knowing anything about Struts (or Struts knowing anything about them). So I would suggest that if there are other services that an extension needs to share that we expose them through the Application context. Oleg V Alexeev wrote: To support flexible extensions mechanism for struts there are can be made some additions to the core structure of the framework - 1. Add ability to register components or external servlets (at application level) via struts-config file. 2. Give such external components or servlets ability to use action mappings database from ActionServlet. 3. Extend core API of struts to support pluggable extensions - for example use event model or direct calls via registrations in action mappiongs database. The best way for my mind is to write external servlets, register it in struts ActionServlet and use it as external services. This approach can be useful in case of mutliple ActionServlet instances in one application - every ActionServlet subscribe to use and uses some amount of external services. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ -- Best regards, Olegmailto:[EMAIL PROTECTED]
RE: Proposal
Really? Why
not write a filter that invokes "beforePagerRendered()" before invoking
"chain.doFilter()", then invoking "afterPageRendered()" after invoking
"chain.doFilter()"?
It seems to me
that filters do *exactly* then thing that you claim they do not. Could you
please elaborate why you believe filters wouldn't implement these
behaviours?
-dan
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Taylor CowanSent: Monday, June 11, 2001 8:04
PMTo: [EMAIL PROTECTED]Subject: Re:
Proposal
I think this is a very good proposal. I
would not use the action identifiers. They should just be methods of the
listener interface:
public void beforePagerRendered(...)
public void afterPageRendered(...)
This seems to be similar to filters, but 2.3
filters don't solve this problem for a struts app.
Taylor
- Original Message -
From:
Jeff
Trent
To: [EMAIL PROTECTED]
Cc: Ted Husted
Sent: Wednesday, June 06, 2001 10:21
AM
Subject: Proposal
New here ... so bare with me.
I'd like to propose the following enhancement
to ActionForm:
public void
addListener(ActionFormListener);
public void
removeListener(ActionFormListener);
Here is the basics of
ActionFormListener I'm interested in to start out with:
public abstract class
ActionFormListener
{
public
static final int ACTION_TYPE_PAGE_PRE_RENDERED =
1; public static
final int ACTION_TYPE_PAGE_POST_RENDERED = 2;
public
abstract void actionFormNotify(int actionType, String context /* reserved
for future use*/);
}
---
These messages would be sent before and after
the RequestDispatcher includedor forwarded to the JSP
page.
The primary reason I'm propsing this
featureis to allocate / free (respectfully) scarce resources that I
would like to be made available on the page that I do not want to
serialize to transient members of my form.
thank you,
jeffrey trent
Re: Proposal
It's a matter of granularity. My struts apps
only have one servlet. I think the idea is to have these events at the
action level, per ActionForm. A filter is at the servlet
level.As I understand it, I can have a filter associated with a
servlet or a group of servlets. So in my struts app, my filter will be
invoked every single time a *.do request comes in.
I suppose struts could do something with filters
like has been done with the struts action servlet, but even in that case we
would not be creating filters, we'd be implementing some struts interface, as we
do with Actions.
So to summarize, assuming the struts framework as
it is today, filters do not help us get an eventwhen a particular
ActionForm is used. Filters might be part of the solution in a new struts
architecture, but by themselves they don't provide the functionality suggested
in Jeff's proposal.
Taylor
- Original Message -
From:
Dan
- Blue Lotus Software
To: [EMAIL PROTECTED]
; Taylor Cowan
Sent: Monday, June 11, 2001 4:23 PM
Subject: RE: Proposal
Really?
Why not write a filter that invokes "beforePagerRendered()" before invoking
"chain.doFilter()", then invoking "afterPageRendered()" after invoking
"chain.doFilter()"?
It seems to me
that filters do *exactly* then thing that you claim they do not. Could
you please elaborate why you believe filters wouldn't implement these
behaviours?
-dan
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Taylor CowanSent: Monday, June 11, 2001 8:04
PMTo: [EMAIL PROTECTED]Subject: Re:
Proposal
I think this is a very good proposal. I
would not use the action identifiers. They should just be methods of
the listener interface:
public void
beforePagerRendered(...)
public void afterPageRendered(...)
This seems to be similar to filters, but 2.3
filters don't solve this problem for a struts app.
Taylor
- Original Message -
From:
Jeff
Trent
To: [EMAIL PROTECTED]
Cc: Ted Husted
Sent: Wednesday, June 06, 2001
10:21 AM
Subject: Proposal
New here ... so bare with me.
I'd like to propose the following
enhancement to ActionForm:
public void
addListener(ActionFormListener);
public void
removeListener(ActionFormListener);
Here is the basics of
ActionFormListener I'm interested in to start out with:
public abstract class
ActionFormListener
{
public static final int ACTION_TYPE_PAGE_PRE_RENDERED =
1; public static
final int ACTION_TYPE_PAGE_POST_RENDERED = 2;
public abstract void actionFormNotify(int actionType, String context /*
reserved for future use*/);
}
---
These messages would be sent before and
after the RequestDispatcher includedor forwarded to the JSP
page.
The primary reason I'm propsing this
featureis to allocate / free (respectfully) scarce resources that
I would like to be made available on the page that I do not want to
serialize to transient members of my form.
thank you,
jeffrey trent
Re: Client/Server Side Validation for Struts 1.1
On Tue, 5 Jun 2001, Michael Westbay wrote:
But what kind of compexity are you looking at? Let's take a small example of
languages and countries to cover:
Languages: English, Spainish, Japanese
Locales: U.S., England, Spain, Japan
Now you need resources:
en, en_US, en_UK, en_ES, en_JP
es, es_US, es_UK, es_ES, es_JP
ja, ja_US, ja_UK, ja_ES, ja_JP
Add a language, multiply by 5.
Add a country, multipy the result by 4.
And most of the strings will be repeated over and over ad. nasuim.
I'm not totally caught up on this thread, so someone else might have noted
this already -- but the resource bundle classes do not (and our
validator mechanism should not, if based on locales) require repeating the
message strings in every single case. For example, if the current user
has selected locale xx_YY, the message will be looked up in
* xx_YY (if it exists), else
* xx (if it exists), else
* the default Locale for the server.
Thus, for messages and formats that are common to all English speakers
independent of location, should be placed only in the resources for the
en Locale.
It seems to me that the target locale (meaning place) should be separate with
some sort of formatted strings like (###)###-.
Units of measure (dollars, yet, pesos) etc. can be localized in the language
file, as well as display order. For example:
Language_en.properties:
usdollar_value=US$ {0}
yen_value={0} yen
peso_value={0} pesos
Language_ja.properties:
usdollar_value={0}ドル
yen_value={0}円
peso_value={0}ペソ
This way, the formatting/format checking 0.00 or #.## can be written
once, and used by all of the languagues.
This still doesn't cover the problem with providing a choice of two
currencies (as in the EC). Any suggestions?
It's also more complicated than that in another direction. If I've
selected the en_US Locale for myself, but I'm entering an address in
France, wouldn't I want to use the French postal code format strings? In
other words, validation formats for one field might depend on the data
content of another field.
Michael Westbay
Craig McClanahan
question
Inside of the logic:iterate tag, I am passing a string to an xsl tranformer, using pageContext.out as the writer the tranformer will write its results to. When I do so, there is a complaint that says: Illegal to flush within a custom tag I tried to do the same thing (use an xsl tranformer) inside of some custom tags I have written and I get no such error -- I only get the erro inside of the login:iterate tag. Does anyone know if there is soem reason this might be happening inside the iterate tag? I have been banging my head against the wall on this one. I cant find what code is complaining and I thought you struts guys may have an idea since I can only reproduce in the iterate tag. thanks much in advance -will
Re: Client/Server Side Validation for Struts 1.1
On Tue, 5 Jun 2001, William Jaynes wrote: Remember... separation of view from model. The act of displaying an amount in a particular currency format is separate from determining what that amount is. So the code used to implement the display of the amount should not be mixed up with the code used to determine the amount. When I was building multi-currency apps in Europe, the rule was you needed to keep the amount, the currency, and the date -- conversion rates between currencies are not static. Then, you need some mechanism to perform conversions for you that is date sensitive. The Euro made life simpler (because it fixed the conversion rates within the EC), but the problem did not completely go away. Craig
Re: Work flow RFC
On Wed, 6 Jun 2001, Incze Lajos wrote: On Tue, Jun 05, 2001 at 11:46:58AM -0700, Frye, Dave wrote: Keep in mind that Microsoft uses there own version of DTDs and XML Schemas that are not W3C conformant. You would then have to use their XSL tools, which, of course, would be Wintel-based. This would not make for a very platform independent solution... I know of two Workflow DTD's. The one seems to be emerging beeing a strategic element for the IBM web services effort (altough the DTD is open). It is the WSFL (Web Services Flow Language - http://www-4.ibm.com/software/solutions/webservices/resources.html) which is pretty general, and an even more general one from the W3C submissions, XTND (XML Transition Network Definition http://www.w3.org/TR/xtnd/ ). There was an official workflow standard initiative some years ago, but it became really big (see www.wfmc.org for the Workflow Management Coalition). Don't think these would give the solution, but (mainly the IBM spec) provide a good vocabulary. incze I'm currently about half way through the WSFL spec, and so far it looks like a useful model. Being oriented towards web services (i.e. batch RPC interactions), I want to think carefully about how you would script interactions with humans in a web app. Craig
Re: Work flow RFC
On Wed, 6 Jun 2001, Craig Tataryn wrote: Ted, as for enforcing the workflow, I hadn't even considered it. The goal of the TODO is just to make a graphical tool that allows you to define a workflow and automate the process of setting up your config files to support the workflow. Atleast that's how I read it. That's one worthy goal. I've actually been thinking that it would be nice to have a workflow runtime environment that Struts interacted with, keeping track of where in the flow the user was, and therefore managing the overall navigation. Just as a trivially simple example, this would make doing wizard-type interactions very simple. tataryn:craig/ Craig McClanahan
Re: Handling session timeouts
On Wed, 6 Jun 2001, Andreas Prohaska wrote: This was originally posted to the struts-user list, but Ted Husted pointed out that I should better discuss this on the development list. For the guys that are not listening to the user list, the background: We have written a wizard for a larger input process that requires some steps. We use one ActionForm bean for this wizard that keeps the data in the session context (everything done by struts). When I wanted to go to the next step I recognized that all my data from the previous steps was lost and instead I had the default values. Obviously a session timeout occured and the original ActionForm was removed. Then a new session was automatically created and a new ActionForm bean was automatically added to the session context. Normally this is nice, but there was no way for my Action class or JSP to see that in fact the session was lost and the data was wrong. Now I would recommend to place a method like processSession() at the start of the process() method in the ActionServlet. This could be changed by subclasses of the ActionServlet in order to intercept session creation and deprecation. OR it should call some more specialized class for this (say SessionManager). The advantage of this approach would be that we could also introduce a new page:init tag that calls the same class in order to intercept session creation in JSP pages (that might be called directly). If the list decides that this could be nice, I would make the changes but then I need to know how I can submit them :-) What do you think? In servlet 2.2, there is *no* general event handling mechanism that can catch a session creation no matter where it happened. In order to make something like this work in Struts, we would have to place restrictions like this: * The action cannot call request.getSession() -- it must call some Struts-provided method that will detect the creation. * The user cannot *ever* call a JSP page directly, because the session will be created (or recreated) as necessary. Most people work around this by a strategy like this: * At logon time, place an attribute into the session under a well-known key. The Struts example app uses the User object for this purpose. * At the beginning of each action (or page), check for the existence of the well-known attribute. If it is missing, this is a new session (possibly a replacement for a timed-out one). In the example app, there's an app:checkLogon custom tag that can do this. * If a session times out (or is invalidated), all of the attributes will be removed. If you want to know when either of these things happens, simply make your attribute implement HttpSessionBindingListener and it will be notified at timeout or invalidate time. The servlet 2.3 specification includes new application event listeners for session created, session destroyed, and add/change/delete of session attributes. Then you'll be able to build apps that react to such events without having to involve specific attributes -- but until then we are kind of stuck. Andreas Craig McClanahan
RE: Proposal
On Wed, 6 Jun 2001, Dan - Blue Lotus Software wrote: Of course, the Servlet 2.3 spec hasn't been finalized yet. But Tomcat Catalina (in it's 5th beta release) implements Filters. They're really cool, and they might make the ActionServlet concept a bit redundant. That is, the controller in an MVC/Model 2 architecture can be implemented as a Filter. Since I'm in the expert group for Servlet 2.3 (and wrote all the Tomcat 4 code that supports filters), I've thought about this one a lot. And, truth be told, I'd probably still do the controller as a servlet, even if I was starting from a 2.3 baseline. The primary reason for this thinking is that filters cannot redirect the flow of control to different servlets (i.e. different actions in Struts terminology). The servlet that is going to be executed has already been selected by the container, based on the original request URI. Given that you're going to end up executing *some* servlet anyway, you're still faced with the choice of a single dispatching servlet (which the Struts controller already does) or implementing each action as a separate servlet (which, among other things, is quite a lot harder to set up). Just my 2p worth. -dan Craig McClanahan
Re: Proposal
On Mon, 11 Jun 2001, Taylor Cowan wrote:
I think this is a very good proposal. I would not use the action
identifiers. They should just be methods of the listener interface:
public void beforePagerRendered(...)
public void afterPageRendered(...)
How is Struts supposed to know what component is actually rendering the
page? It could be the Action, a component included by the action, or a
component that is forwarded to. In addition, a component can *start*
creating the response, then erase it with response.resetBuffer(), then
start again.
This seems to be similar to filters, but 2.3 filters don't solve this
problem for a struts app.
Taylor
Craig
- Original Message -
From: Jeff mailto:[EMAIL PROTECTED] Trent
To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Cc: Ted Husted mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 06, 2001 10:21 AM
Subject: Proposal
New here ... so bare with me.
I'd like to propose the following enhancement to ActionForm:
public void addListener(ActionFormListener);
public void removeListener(ActionFormListener);
Here is the basics of ActionFormListener I'm interested in to start out
with:
public abstract class ActionFormListener
{
public static final int ACTION_TYPE_PAGE_PRE_RENDERED = 1;
public static final int ACTION_TYPE_PAGE_POST_RENDERED = 2;
public abstract void actionFormNotify(int actionType, String
context /* reserved for future use*/);
}
---
These messages would be sent before and after the RequestDispatcher
included or forwarded to the JSP page.
The primary reason I'm propsing this feature is to allocate / free
(respectfully) scarce resources that I would like to be made available
on the page that I do not want to serialize to transient members of my
form.
thank you,
jeffrey trent
Re: Proposal
One thing this approach would seem to need is a way to specify that you're
forwarding to a path that is relative to cobrandX, rather than
baseJSPdir, right?
Craig McClanahan
On Mon, 11 Jun 2001, Jeff Trent wrote:
I haven't heard much in the way of a reponse on this proposal so I guess I'll be on
my own In either case, I would like to make one more addendum to what I'm
proposing in case anyone is interested.
There are times I've found when the presentation (input mapping) is not cut and dry.
For instance, consider these URLS:
http://demo.paytrust.com/NASApp/Pt2/DemoLogin
http://billcenterdemo.americanexpress.com/NASApp/Pt2/DemoLogin
http://billmanagerdemo.accountonline.com/NASApp/Pt2/BillCenter
http://gebillmanagerdemo.gefn.com/NASApp/Pt2/DemoLogin
http://billcenterdemo.smartmoney.com/NASApp/Pt2/DemoLogin
http://billmanagerdemo.etrade.com/NASApp/Pt2/DemoLogin
Besides all being bill payment sites, the commonality between them is that they are
all run on the same servers at Paytrust and all use the same underlying business
logic (servlets)! I architected the presentation (JSP) to vary depending on the
partner we are currently serving up in the request. I would like to see this type of
metaphore extended to the action servlet. So, during the pre_rendering notification,
I can for instance, tell the action servlet specifically what JSP file to use. The
mappings are not fine-grain enough. In the case above, they all are mapped to
DemoLogin. The real / physical JSP that gets loaded is determined by the request.
The hierarchy of the JSPs look like this:
baseJSPdir{ contains all of the default JSPs that have templates to
define simple variation such as color, headers, etc. }
|
-paytrust{ contains a set of overriding JSPs going by
the same name which are unique to the site }
-cobrandX{ ditto (see above) }
Any takers? Its been quite successful for me up to now and would require minimal
changes to struts...
Thanks,
Jeff
- Original Message -
From: Jeff Trent
To: [EMAIL PROTECTED]
Cc: Ted Husted
Sent: Wednesday, June 06, 2001 10:21 AM
Subject: Proposal
New here ... so bare with me.
I'd like to propose the following enhancement to ActionForm:
public void addListener(ActionFormListener);
public void removeListener(ActionFormListener);
Here is the basics of ActionFormListener I'm interested in to start out with:
public abstract class ActionFormListener
{
public static final int ACTION_TYPE_PAGE_PRE_RENDERED = 1;
public static final int ACTION_TYPE_PAGE_POST_RENDERED = 2;
public abstract void actionFormNotify(int actionType, String context /*
reserved for future use*/);
}
---
These messages would be sent before and after the RequestDispatcher included or
forwarded to the JSP page.
The primary reason I'm propsing this feature is to allocate / free (respectfully)
scarce resources that I would like to be made available on the page that I do not
want to serialize to transient members of my form.
thank you,
jeffrey trent
Re: Handling session timeouts
On Mon, 11 Jun 2001, Jonathan Asbell wrote: Craig, I thoght the token mechanism could have helped here. Am I wrong? Tokens will definitely help avoid the problem of pressing Reload, or pressing Back Arrow and then submitting again, but they don't do anything particularly useful in regards to detecting timeouts. Craig
Re: Main Branch/1.0 Branch and CVS
If you checked out your tree using: cvs co jakarta-struts then you checked out the main trunk, which is currently Struts 1.1 (or at least post-1.0). When you do a checkin in that tree, it will go back into the main trunk. You can check out a branch using: cvs co -rSTRUTS_1_0_BRANCH jakarta-struts and then checkins from that tree will go into the branch. You can check to see if you checked out a file in a branch by using: cvs status filename and looking at the Sticky Tag line. It will either say (none), which means you are on the main trunk, or something like STRUTS_1_0_BRANCH if you are on a branch. You can see what branches are available by using: cvs status -v filename which will list all of the existing tags (for that file, but they will usually be per-project anyway). If you are using Windows, and use WinCVS, you can also use the Graph command, which will show you a graphical version of the log, with labels attached at branch and label points. -- Martin Cooper - Original Message - From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 11, 2001 7:33 PM Subject: Main Branch/1.0 Branch and CVS Hi, Could someone clear this up for me? I'm not totally sure exactly what I'm doing at this point when I do a cvs commit. I'll assume that when I just do a normal commit to the jakarta-struts repository, that's the main branch. How do I send commits to and checkout the 1.0 branch? How do I know that a 1.0 branch exists, or a 1.1 for that matter?
Re: Handling session timeouts
No Craig. If his session times out, it will loose the token in the session. Thus the page will not submit because the token in the session will not match the one in the hidden field. - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan Asbell [EMAIL PROTECTED] Sent: Monday, June 11, 2001 11:07 PM Subject: Re: Handling session timeouts On Mon, 11 Jun 2001, Jonathan Asbell wrote: Craig, I thoght the token mechanism could have helped here. Am I wrong? Tokens will definitely help avoid the problem of pressing Reload, or pressing Back Arrow and then submitting again, but they don't do anything particularly useful in regards to detecting timeouts. Craig
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/logic PresentTag.java
-Original Message-
From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent: Monday, June 11, 2001 7:35 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/taglib/logic PresentTag.java
craigmcc01/06/11 10:34:41
Modified:src/share/org/apache/struts/taglib/logic Tag:
STRUTS_1_0_BRANCH PresentTag.java
Log:
Update processing of the logic:present and logic:notPresent tags to
reflect the fact that the four-argument version of RequestUtils.lookup()
will now throw an exception if the bean named by the name parameter is
not found. It is my belief that all other tags that call this lookup()
method are correctly dealing with the exception.
PR: Bugzilla #2112
Submitted by: Johan Compagner [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.7.2.1 +11 -6
jakarta-struts/src/share/org/apache/struts/taglib/logic/PresentTag.java
Index: PresentTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/PresentT
ag.java,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- PresentTag.java 2001/02/12 21:49:58 1.7
+++ PresentTag.java 2001/06/11 17:34:40 1.7.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/PresentT
ag.java,v 1.7 2001/02/12 21:49:58 craigmcc Exp $
- * $Revision: 1.7 $
- * $Date: 2001/02/12 21:49:58 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/PresentT
ag.java,v 1.7.2.1 2001/06/11 17:34:40 craigmcc Exp $
+ * $Revision: 1.7.2.1 $
+ * $Date: 2001/06/11 17:34:40 $
*
*
*
@@ -77,7 +77,7 @@
* is present for this request.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2001/02/12 21:49:58 $
+ * @version $Revision: 1.7.2.1 $ $Date: 2001/06/11 17:34:40 $
*/
public class PresentTag extends ConditionalTagBase {
@@ -133,8 +133,13 @@
getHeader(header);
present = (value != null);
} else if (name != null) {
-Object value =
-RequestUtils.lookup(pageContext, name, property,
scope);
+Object value = null;
+try {
+value =
+RequestUtils.lookup(pageContext, name, property,
scope);
+} catch (JspException e) {
+value = null;
+}
present = (value != null);
} else if (parameter != null) {
String value =
