tiles tags exception handling
Hi,
I've been having trouble getting exceptions handled usefully when they
occur within jsps called via tiles:insert tags.
I've tracked the code down to:
org.apache.struts.taglib.tiles.InsertTag
where this exception handling code is called:
protected void processException(Throwable ex, String msg) throws
JspException {
try {
if (msg == null)
msg = ex.getMessage();
if (log.isDebugEnabled()) { // show full trace
log.debug(msg, ex);
pageContext.getOut().println(msg);
ex.printStackTrace(new PrintWriter(pageContext.getOut(), true));
} else { // show only message
pageContext.getOut().println(msg);
} // end if
} catch (IOException ioex) { // problems. Propagate original exception
pageContext.setAttribute(
ComponentConstants.EXCEPTION_KEY,
ex,
PageContext.REQUEST_SCOPE);
throw new JspException(msg);
}
}
my understanding of this code is that no exception will be passed to the
enclosing jsp page. If an excption occurs, a simple error message will
appear in the enclosing page. If debug is enabled for the Logger
org.apache.struts.taglib.tiles.InsertTag then the stack is filled in
too. Am I right?
If so, would it be better to enable excptions to be cascaded up,
enabling exception management in a more application specific manner?
e.g. making use of the error-page elements in the web.xml
I'd like to be able to log the error centrally and display to the user a
meaningful error page.
thanks
Nathan
p.s. thanks to all the development team. Struts seriously reduces
devlopment time and increases the quality of applications built with it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tiles tags exception handling
excellent, thanks
David Graham wrote:
This was a known problem that I've fixed for Struts 1.2. You could also
use a recent nightly build to pick up this fix.
David
--- Nathan Coast [EMAIL PROTECTED] wrote:
Hi,
I've been having trouble getting exceptions handled usefully when they
occur within jsps called via tiles:insert tags.
I've tracked the code down to:
org.apache.struts.taglib.tiles.InsertTag
where this exception handling code is called:
protected void processException(Throwable ex, String msg) throws
JspException {
try {
if (msg == null)
msg = ex.getMessage();
if (log.isDebugEnabled()) { // show full trace
log.debug(msg, ex);
pageContext.getOut().println(msg);
ex.printStackTrace(new PrintWriter(pageContext.getOut(), true));
} else { // show only message
pageContext.getOut().println(msg);
} // end if
} catch (IOException ioex) { // problems. Propagate original
exception
pageContext.setAttribute(
ComponentConstants.EXCEPTION_KEY,
ex,
PageContext.REQUEST_SCOPE);
throw new JspException(msg);
}
}
my understanding of this code is that no exception will be passed to the
enclosing jsp page. If an excption occurs, a simple error message will
appear in the enclosing page. If debug is enabled for the Logger
org.apache.struts.taglib.tiles.InsertTag then the stack is filled in
too. Am I right?
If so, would it be better to enable excptions to be cascaded up,
enabling exception management in a more application specific manner?
e.g. making use of the error-page elements in the web.xml
I'd like to be able to log the error centrally and display to the user a
meaningful error page.
thanks
Nathan
p.s. thanks to all the development team. Struts seriously reduces
devlopment time and increases the quality of applications built with it.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Commons BeanUtils with Struts 1.0 (was RE: PropertyUtils.getIndex edProperty() with Obect key as parameter)
Hi all, I agree with the idea of an interim release, we have a production site running on 1.0 + indexed tags + various patches. The powers that be have decreed that we shouldn't use a non-release build (although that's what we effectively have with all the patches :) If it's going to be a while till 1.1 it'd be useful for us to have a release quality build in the interim. I appreciate there is extra effort / time involved in doing a formal release so I wont hold my breath. BTW thanks to the struts team, struts has saved us a huge amount of time. It does exactly what a decent framework should do - handles all the generic technology problems and leaves us to get on with solving our business problems. Cheers Nathan -Original Message- From: Rey Francois [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 02, 2001 11:13 AM To: '[EMAIL PROTECTED]' Subject: Commons BeanUtils with Struts 1.0 (was RE: PropertyUtils.getIndex edProperty() with Obect key as parameter) Dimitri, I'm not sure what would be the best way to use the common BeanUtils with Struts 1.0. I suppose your suggestion will work, but you'll have to change many java file in order to change the imports. If your project is not going into production until later, it may be easier to take the struts nightly build which already uses the commons stuff. By the time you need to get into production, struts 1.1 may be out. I have no idea when this will be though. The real issue here is that 1.1 has a large scope, meaning that unfortunately new and simpler features implemented in the commons beanutils will not be available until much later. It would be nice to have an intermediate release that just integrates with the commons stuff (beanutils + digester). Can anybody else here make suggestions - Ted, Craig ? Fr. -Original Message- From: Dimitri Valdin [mailto:[EMAIL PROTECTED]] Sent: 01 October 2001 19:21 To: [EMAIL PROTECTED] Subject: Antwort: RE: PropertyUtils.getIndexedProperty() with Obect key as paramete r Thanks Francois, I have expected smth like that. Can you give me a hint. What would be the best way to use this feature within struts 1.0 Should I just modify struts imports and rebuild the library ? What about release 1.1 ? Dmitri Valdin -- Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *** ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper at LevelSeas for the presence of computer viruses. www.mimesweeper.com **
properties other than basic wrappers
Hi, I guess this is directed at the commons-beanutils developers but I get the impression that the struts / commmons developers are one and the same. Is there any work in progress to provide functionality for form-bean properties with data types beyond the basic types / object wrappers? having looked at the code I guess the logical place for such code would be org.apache.commons.beanutils.ConvertUtils. I saw the following in the struts 1.1 to-do list and wasn't sure if this was referring to the same thing: PropertyEditor Support. Add support for JavaBeans that include a PropertyEditor class for conversion to and from the string representation used in an HTML input field. This support should operate in a manner consistent with the way that standard JSP tags do in JSP 1.2. If there's a need for someone to work on this then how do I go about getting involved? Cheers Nathan ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper at LevelSeas for the presence of computer viruses. www.mimesweeper.com **
portals, jetspeed, tiles etc
Hi, I'm interested in portal / personalisation within struts. I followed a thread in struts-user which ended up with this response from Ted Husted: http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg15156.html Has there been any progress with this? We need to get bare-bones portal functionality out the door asap. I'm definitely interested in contributing towards any ongoing work. I guess I'm asking whether there is any part-done work that I can hack / add to / merge back later. I was also a bit confused (to say the least) about the mechanism for generating the presentation for each component. Assuming some components take xml data - from a feed or personalisation data. Is the suggestion to use xsl to generate the presentation or convert xml (using digester??) to objects which would be used by a struts jsp? Cheers Nathan
RE: Forwarding Actions onto other Actions
Hi, I think Bob's point is that if an action form has been populated once during a request, it would be useful if the reset wasn't called again. i.e. if the request was forwarded to other actions which use an action form of the same name, it'd be useful if form properties could be set during the first action and not reset before arriving at the second action. I've coded around this by setting request attributes in the first action and reading them in the second (ugly). I don't think anyone disagrees that it's essential the action forms are reset between requests. Cheers Nathan -Original Message- From: Ted Husted [mailto:archive@jab.org] Sent: Sunday, September 16, 2001 1:14 PM To: [EMAIL PROTECTED] Subject: Re: Forwarding Actions onto other Actions Unfortunately, calling reset is necessary. A primary reason is that that if a checkbox is unchecked then it will be ommitted from the request. This can give inconsistent results when a ActionForm is being returned for editing. The reset method gives the developer the opportunity to set the checkbox to a known state (to make up for the vagrancies of HTML). The abstract implementation of reset is empty. If a developer is going to reuse beans between requests, it is the developer's responsiblity to see that reset performs correctly. All the population also takes places through mutators that the developer defines. If there are circumstances where a ActionForm should not populate itself through the request, the developer can design the mutators accordingly. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/ Bob Rullo wrote: Ted, I did see that check in the processActionForm method, but if you notice, in the processPopulate which is called right after the processActionForm call you'll see that the bean, no matter where it came from, gets reset and then populated with the request parameters via the RequestUtil.populate method. Am I missing something here? Sure seems like it'll reset the form bean no matter what which to me, isn't desirable. -Bob - Original Message - From: Ted Husted archive@jab.org To: [EMAIL PROTECTED] Sent: Sunday, September 16, 2001 6:04 AM Subject: Re: Forwarding Actions onto other Actions There is actually just such a check, though this would be a very good suggestion if there weren't ;-) See processActionForm in ActionServlet. Please let us know if you see anything else. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/ Bob Rullo wrote: This is my first posting to the dev board so bare with me. From what I've seen in looking in the ActionServlet code it appears that everytime a action is called the form instance for that action is placed into the mapping.getScope( ). Shouldn't there be a check before to see if the ActionForm is already in the scope? Reason being that one action could make some modifications to a form instance and then forward it to another action that will make more changes to the form instance. Basically my problem is that if two actions having the same form instance are called in the same request the form instance stored in the request will always be overridden by the last action. I propose that we should do a check before each action to determine if the form already exists in the desired scope. If so, use the scoped instance, if not, build the form instance off of the request parameters as it is now. If this was by design, could someone shed some light to why? Thank you for your help, -Bob ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper at LevelSeas for the presence of computer viruses. www.mimesweeper.com **
RE: Indexed Tags (TextArea)
check this message http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg02891.html not sure if the change has been included in current dev but heres a patch for 1.0 Nathan -Original Message- From: Henry Mugasha [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 4:59 PM To: [EMAIL PROTECTED] Subject: Indexed Tags (TextArea) Hi, The struts-html taglib allows for indexed tags on almost all form tags apart form the textarea form tag. Why is this so? Can this be easily fixed? Henry Get 250 color business cards for FREE! http://businesscards.lycos.com/vp/fastpath/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper at LevelSeas for the presence of computer viruses. www.mimesweeper.com ** TextareaTag.java
dave hayes indexed properties / text area
Hi,
Sorry if this is a bit of a cross post with user but I figured dev is a
better place for this. Is there any reason why the text area tag wasn't
included in the indexed tag patch?
We've just implemented this (copied from BaseFieldTag) in the TextAreaTag as
a workaround.
Good idea? bad idea? already done and I don't know where to find up to date
code?
public int doStartTag() throws JspException {
// Create an appropriate input element based on our parameters
StringBuffer results = new StringBuffer(textarea);
results.append( name=\);
if (true.equals(indexed))
public int doStartTag() throws JspException {
// Create an appropriate input element based on our parameters
StringBuffer results = new StringBuffer(textarea);
results.append( name=\);
if (true.equals(indexed))
{
// look for outer iterate tag
IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
if (iterateTag == null)
{
// this tag should only be nested in iteratetag, if it's not,
don't do anything
return EVAL_PAGE;
}
results.append(getName());
results.append([);
results.append(iterateTag.getIndex());
results.append(].);
}
results.append(property);
results.append(\);
as before
Cheers
Nathan
**
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**
