RE: PLEASE REPLY..response wrapping problem
David,
As you suspected, this is related to having a flush in your applet.
The simple solution is to extend your ServletOutputStream with a flush()
method that does nothing.
In the future, please ask usage questions on the struts-user list. This
list is intended for issues related to developing Struts itself.
Have fun,
Shai.
-Original Message-
From: David Anderson [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2003 08:36
To: [EMAIL PROTECTED]
Subject: PLEASE REPLY..response wrapping problem
as by Sun servlet 2.3 specs, I'm using httpServletResponseWrapper to
wrapp
response object, the technique didn't work and I didn't yet figured out
the
cause, I'm deploying my web app to JRUN (I don't know if JRUN4 container
is
related to the problem)
my question is :
is there something wrong in the following code in order to wrap response
object with struts/tiles ? , is this has to do with flush=true in
tiles:insert ? or is there any limitations for wrapping response in
Struts
framework? or is it a Tiles limitation ?
in my WEB.XML I wrote :
filter
filter-nameMy Response Wrapper/filter-name
filter-classfilters.WrapperFilter/filter-class
/filter
filter-mapping
filter-nameMy Response Wrapper/filter-name
url-pattern*.do/url-pattern
/filter-mapping
the code in my filter is :
WrapperFilter.java
-
package filters;
import java.io.IOException;
import javax.servlet.Filter;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
public class WrapperFilter implements javax.servlet.Filter {
public void doFilter( javax.servlet.ServletRequest request,
javax.servlet.ServletResponse response,
javax.servlet.FilterChain chain )
throws IOException, ServletException {
ServletContext context = filterConfig.getServletContext();
HttpServletRequest req = (HttpServletRequest) request;
OutputStream out = response.getOutputStream();
out.write(HRPREHR.getBytes());
GenericResponseWrapper wrapper = new
GenericResponseWrapper((HttpServletResponse) response);
chain.doFilter(request, wrapper);
out.write(wrapper.getData());
context.log(wrapper.getData().toString());
out.write(HRPOSTHR.getBytes());
out.close();
}
}
//--
//
GenericResponseWrapper.java :
---
package filters;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;
import java.io.ByteArrayOutputStream;
import java.io.PrintWriter;
public class GenericResponseWrapper extends HttpServletResponseWrapper {
private ByteArrayOutputStream output;
private int contentLength;
private String contentType;
public GenericResponseWrapper(HttpServletResponse response) {
super(response);
output = new ByteArrayOutputStream();
}
public byte[] getData() {
return output.toByteArray();
}
public ServletOutputStream getOutputStream() {
return new FilterServletOutputStream(output);
}
public void setContentLength(int length) {
this.contentLength = length;
super.setContentLength(length);
}
public int getContentLength() {
return contentLength;
}
public void setContentType(String type) {
this.contentType = type;
super.setContentType(type);
}
public String getContentType() {
return contentType;
}
public PrintWriter getWriter() {
return new PrintWriter(getOutputStream(), true);
}
}
so when an action URL (http://localhost:8100/emgr/login.do) is called in
browser,the page shows NOTHING (empty page) , that login.do action is
doing
a simple process and than forwarding to tile defininition :
main.home.page ,
the logged error is :
jrun.servlet.io.ClosedIOException: Response has been closed
at
jrun.servlet.io.ClosedOutputStream.write(ClosedOutputStream.java:23)
at
java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
at
jrun.servlet.http.WebOutputStream.write(WebOutputStream.java:64)
at java.io.OutputStream.write(OutputStream.java:58)
at filters.WrapperFilter.doFilter(WrapperFilter.java:176)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.FilterChain.service(FilterChain.java:101)
.
Also I noticed that the same filter is working fine if my action is
forwarding to a JSP instead of a tiles definition name
so instead of mapping the filter to *.do I mapped it to *.jsp :
filter-mapping
filter-nameMy Response Wrapper/filter-name
url-pattern*.jsp/url-pattern
/filter-mapping
that time the page shows correctly with the pre/post text embedded.
I'm
RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
Perhaps this belongs on the user list, but I think it is relevant for
the discussion at hand. You all seem to regard all of the Struts taglibs
as one item, for which JSTL is an alternative. While this is certainly
true for the logic: and bean: tags, I have not seen a replacement for
the
html: form tags (that is, html:form and all the controls) in JSTL.
The user guide
(http://jakarta.apache.org/struts/userGuide/building_view.html#form_bean
s)
suggests we replace
input type=text name=username
value=%= loginBean.getUsername() /
with
html:text property=username/
Does the use JSTL camp prefer this,
input type=text name=username
value=c:out value=${loginBean.username}/
or am I missing some basic JSTL?
Shai.
PS: There is a documentation error there; the original JSP should be
input type=text name=username
value=%= loginBean.getUsername() %/
--^
Shai.
---
Confidentiality Notice: This email transmission may contain confidential or legally
privileged information that is intended only for the individual or entity named in the
e-mail address. If you are not the intended recipient, you are hereby notified that
any disclosure, copying, distribution, or reliance upon the contents of this e-mail is
strictly prohibited. If you have received this e-mail transmission in error, please
reply to the sender, so that arrangements can be made for proper delivery, and then
please delete the message from your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag)
For what my non-contributor opinion's worth, I totally agree with David. So far as I know, while JSTL is not _required_ by the standard for JSP 1.2, it does not _require_ 1.2 -- and can be used with 1.1 containers; so saying use JSTL does not translate to upgrade to Servlet 2.3. Shai. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2003 07:41 To: Struts Developers List Subject: Re: Support for non-JSTL tags (was RE: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag) --- Steve Raeburn [EMAIL PROTECTED] wrote: I'm not singling Vic out for this (honest) but... The standard advice we are now giving everyone is use JSTL, which I wholeheartedly agree with and have said myself. However, I think we need to make sure that we still adequately support non-JSTL solutions and continue to consider bug fixes/enhancements to Struts tags EVEN where it would duplicate JSTL functionality because Struts still supports JSP 1.1/Servlet2.2. I strongly disagree with that. Duplicating standard functionality is a complete waste of time. If someone wants something available in the JSTL they should just use the JSTL. Struts goal in life isn't to duplicate standards. We should absolutely fix bugs in the existing tags and provide tags that aren't available elsewhere. Having said that, I won't stop you or any other committer from donating time to developing tags that duplicate JSTL functionality. However, I can't justify spending my own time maintaining or fixing bugs in such tags. I haven't considered whether this particular enhancement would fall into the category of something we should do, it just prompted me to raise the issue. If we've reached the stage where the recommendations we are making *require* JSTL, then I think it's time to be honest about the required platform for Struts and up it to 1.1/2.3 I don't see how the Servlet version required for JSTL is relevant to Struts. We're making the reasonable recommendation that people use standard technologies instead of the propriety Struts counterparts. The Struts tags have served us well for a long time but IMO its time to let most of them fade away gracefully. David Thoughts? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: August 27, 2003 8:28 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 21465] - Enhancement of the html:link tag DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21465. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21465 Enhancement of the html:link tag [EMAIL PROTECTED] changed: What|Removed |Added -- -- Status|ASSIGNED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-08-28 03:27 --- You can/should use JSTL instead. .V - 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] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Confidentiality Notice: This email transmission may contain confidential or legally privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that arrangements can be made for proper delivery, and then please delete the message from your inbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
Like this http://issues.apache.org/bugzilla/show_bug.cgi?id=21603 ? While this is not an attempt to define general extensibility mechanisms, it does seem to address some of Edgar's and Tero's concerns... I think it is a good example of the kind of extensibility needed. The bug asks for a specific solution to a specific problem, but a general treatment of extensibility might make it very easy. Have fun, Shai. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 01:00 To: Struts Developers List Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) --- Edgar Dollin [EMAIL PROTECTED] wrote: Exactly some of the problems I have been having with the tags as they currently exist. The best thing to do is to open a bugzilla enhancement request with *specific* tags and methods you need improved. Make sure the suggestions are relevant to the current state of the tags. David Edgar -Original Message- From: Paananen, Tero [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2003 5:42 PM To: 'Struts Developers List' Subject: RE: Tags more extensible (was: Suggestions for Calendar Popup tag lib?) Well, this is the thing...how would I know in advance? :) Seriously. I have no idea what kind of requirements are coming up next month. An example of something we've done in the past is extending Struts HTML tags to incorporate access control features (read-only, write, mask sensitive info, etc.) While I wasn't involved with that effort, I'm looking at the source code, and it's done with copy-and-pasteing the old code and sprinkling in the access control checks and changes to rendering the value property. 90% of the code remains unchanged, but we had to copy-and-paste the entire thing. There is no other way to plug-in the access control enhancements in the tags without doing that. And we didn't feel like littering JSP code with logic tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Confidentiality Notice: This email transmission may contain confidential or legally privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that arrangements can be made for proper delivery, and then please delete the message from your inbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 22231] New: - the logic:present and bean:write will not display all of the HttpServletRequest attributes.
Bill,
It appears that you are confusing request attributes with query
parameters. The latter are what is picked up by parameter= For
request attributes, my guess is you need logic:present name= I
am also guessing that the form triggering this action has a field named
invNum on it.
I am not a committer, just trying to help them save some time; if all my
guesses are true, please close the bug. If I am wrong, please accept my
apologies.
Have fun,
Shai.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 00:42
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 22231] New: - the logic:present and
bean:write will not display all of the HttpServletRequest attributes.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22231.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22231
the logic:present and bean:write will not display all of the
HttpServletRequest attributes.
Summary: the logic:present and bean:write will not
display
all of the HttpServletRequest attributes.
Product: Struts
Version: 1.1RC2
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Greetings:
I have an Action that contains the following code snippet:
request.setAttribute(message,this is where the eNotify Message will
display);
request.setAttribute(invNum,this is the invoice num);
I forward the Action to a jsp page that contains the following code:
%
Enumeration enum = request.getAttributeNames();
for (; enum.hasMoreElements() ;) {
out.println((String)enum.nextElement()+br /);
}
out.println(request.getAttribute(message)+br /);
out.println(request.getAttribute(invNum)+br /);
%
logic:present parameter=message
bean:write name=message /
/logic:present
logic:present parameter=invNum
bean:write name=invNum /
/logic:present
The output in the web browser shows both the 'message' and 'invNum' on
the list
of attribute names. However, the 'invNum' value is the only string that
gets
displayed on the browser screen. The same behavior is true when setting
a
'session' attribute.
Thank you.
Bill Brown
colorfulsoftware.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Confidentiality Notice: This email transmission may contain confidential or legally
privileged information that is intended only for the individual or entity named in the
e-mail address. If you are not the intended recipient, you are hereby notified that
any disclosure, copying, distribution, or reliance upon the contents of this e-mail is
strictly prohibited. If you have received this e-mail transmission in error, please
reply to the sender, so that arrangements can be made for proper delivery, and then
please delete the message from your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Refactoring RequestUtils
Ask in the user list. Struts users may be relying on these methods, even if Struts itself doesn't. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 31, 2003 03:57 To: [EMAIL PROTECTED] Subject: Refactoring RequestUtils The movement of JSP specific methods to TagUtils is nearly completed except for moving the externalized messages. I'd like to refactor RequestUtils even more to reduce its hefty size. There are 2 distinct groups of methods: URL related and Module related. 1. I suggest we move the module methods into a new ModuleUtils class. 2. I would suggest that there also be a UrlUtils class except that 4 of the URL methods aren't used in Struts and 2 of them should be moved into TagUtils. serverURL(), absoluteURL(), actionURL(), and printableURL() are not used. encodeURL() and pageURL() should go to TagUtils. What do we do with the 4 unused methods? Thoughts? David __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.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: Help Please with usage of nested tags
Katie,
You are doing only one thing wrong -- this is the developer's list, and
usage questions should be addressed to the users list. For your
question, the problem is not with the tags, but rather with your bean:
In your scenario, the populate() method does the equivalent of
mainForm.getItemList(index).setItemName(name)
Notice that it is getItemList(), _not_ setItemList().
To solve this, instead of
private ArrayList _itemList = new ArrayList();
in the MainForm class, use
import org.apache.commons.collections.ListUtils;
import org.apache.commons.collections.Factory;
class ItemBeanFactory implements Factory {
// Make new BeanItem's
}
private ArrayList _itemList = ListUtils.getLazyList(new ArrayList(), new
ItemBeanFactory()) ;
And things might look better.
Have fun,
Shai.
-Original Message-
From: Katie Wright [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 20:41
To: '[EMAIL PROTECTED]'
Subject: Help Please with usage of nested tags
Hi,
I am new to this mailing list (i.e. I am sorry if I do something wrong,
please don't flame me). I am not new to struts but I am new to the more
advanced tags. I have run into this problem. I think that I am close but
just not understanding a key concept.
I am trying to create an HTML form like so:
Item1Label Item1Textbox
Item2Label Item2Textbox
Item3Label Item3Textbox
What is new to me is the fact that in this case, the number of items
vary
and the item labels vary.
I can display the page fine with the populated values for edit but when
I
try to do a save, I get the following struts exception:
javax.servlet.ServletException:BeanUtils.populate at
org.apache.struts.util.RequestUtils.populate RequestUtils.java:1254) at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcess
or.j
ava:821) at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:
254)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
It seems to be having trouble activating my setter in my form but not
sure
why. I think because I have setup something improperly but don't know
what.
I have done some research on the Internet and by following by example I
have
developed the following:
html:form action=MainFormSave.do
nested:iterate property=itemList
nested:hidden property=itemName /
nested:write property=itemName /
nested:text property=itemDescription /
/nested:iterate
/html:form
I have a MainForm class which includes the following:
private ArrayList _itemList = new ArrayList();
public void setItemList(int index, ItemBean item) {
if (index this._itemList.size()) {
this._itemList.set(index, item);
} else {
this._itemList.add(item);
}
}
public ArrayList getItemList() {
return (this._itemList) ;
}
And I have an ItemBean which includes the following:
private String _itemName = null;
private String _itemDescription = null;
public void setItemName(String name) {
this._itemName=name;
}
public String getItemName() {
return (this._itemName) ;
}
public void setItemDescription(String desc) {
this._itemDescription=desc;
}
public String getItemDescription() {
return (this._itemDescription) ;
}
Thanks in advance,
Katie Wright (who is hoping that it is not something completely obvious)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
Confidentiality Notice: This email transmission may contain confidential or legally
privileged information that is intended only for the individual or entity named in the
e-mail address. If you are not the intended recipient, you are hereby notified that
any disclosure, copying, distribution, or reliance upon the contents of this e-mail is
strictly prohibited. If you have received this e-mail transmission in error, please
reply to the sender, so that arrangements can be made for proper delivery, and then
please delete the message from your inbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Cryptic error message for null bean property
Hi all, I ran into the same problem as mentioned in http://www.mail-archive.com/[EMAIL PROTECTED]/msg72240.html and I was able to track it down. In summary, the user has a control in his JSP page: html:text property=apache.org / And while presenting an existing bean works fine, trying to populate a new bean with the form data fails with a very cryptic error: java.lang.IllegalArgumentException: No bean specified at org.apache.commons.beanutils.PropertyUtils.getPropertyDescriptor(Propert yUtils.java:837) at org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:934) at org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) ... The cause is that in the form bean, before population, getApache() returns null, and so setProperty is called as setProperty(null,org,value) (because the tag wants to execute the equivalent of bean.getApache().setOrg()) -- which throws the exception above. Now, I wonder if this can -- or should -- be fixed by Struts, Commons, or whoever. At any rate, since (I think) with Struts the effect is more surprising, a word about this should be dropped in the user's guide where nested attributes are mentioned. So -- should I submit a bug report? If so, where? Thanks, Shai. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Automatic readonly/disabled settings in struts-html
Hi guys, We are developing a web application with a number of complex pages and dozens of controls. These controls' readonly status should be set, individually, at runtime. With the current (1.1) struts-html, out pages should come out as a repetition of html:text property=someName readonly='%= formBean.isReadonly(someName) %' styleClass='%= formBean.isReadonly(someName)? ReadOnlyClass : ReadWriteClass %' / With someName being replaced each time with the relevant property. Since the application is big, but not huge, this is borderline acceptable to us. Now, of course, we could extend html:text -- and any other specific tag we use -- to deal with it (or we could buy the tags from http://struts.application-servers.com/), but I think the correct place for the fix is BaseHandlerTag.java. What I have in mind is an additional attribute to html:form that would define a generic mechanism for setting the control properties, something along the lines of html:form ... readonlyIndicator=isReadonly / Which would then do the equivalent of planting the above code in all the form controls. Note: With CSS2, setting a specific style class for readonly controls should not be necessary, because the selectors can handle it, and in general, I understand that setting styles automagically goes close to UI issues which struts-html may not want to deal with. However, setting the readonly attribute is pure semantics, and even if you don't want to include the styleClass feature, I would like you to consider this. And of course, disabled, although we don't specifically need it, would be a natural candidate for the same treatment. Do you think there's any chance of seeing something like this supported in Struts? Thanks, Shai. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
