RE: cvs commit: veto
If Craig doesn't want to associate with a project if certain individuals are involved, I think his wishes as a committer should be respected. The policy for posting links should be to allow all links that committers are willing to add and exclude links that any committer finds repugnant in any way. -Original Message- From: Craig R. McClanahan To: Struts Developers List Sent: 11/13/2003 10:56 PM Subject: Re: cvs commit: veto Quoting Ted Husted [EMAIL PROTECTED]: -1 The community can make up its own mind on issues regarding an individual's behavior. Like any commit to change software, other committers can -1 them for valid reasons. I formally ask that any product changes made for the sole purpose of censoring an individual be reversed, with the exception of consultants and powered, which pages can be removed completely as they are obsolete. My view of Vic's technical judgement and capabilities is probably pretty clear from prior message threads. His behavior in other forums recently, and this time in particular (presuming that an allegation is true without a determination of the actual facts, and then presenting it as reality instead of perception) is ethically repugnant to me, and calls his professional judgement into question. This is so to the degree that I cannot in good conscience participate in a project willing to publish links to companies whose principals behave in such a manner. To address Ted's (legitimate) concern, I would prefer that we adopt a more stringent (but one that can be administered based on reasonably objective criteria) policy on Struts website content -- no advertisements of *any* commercial resources related to Struts. Google does a far better job than we could ever do in making such resources available, and this would avoid the need for any judgement calls or unfair advantage to some commercial entities over others. Announcements about nonprofit activities (user group meetings), freely available presentations/demos/slides about Struts, or other open source software that works with Struts, would still be reasonable candidates for inclusion. Note that I'm suggesting this approach just for the website (and therefore the snapshots that get included in the product by virtue of the way we create struts-documentation.war). The current policy towards postings on the mailing lists can remain the same -- the distinction is that it is clear who is speaking (presuming it's not an email virus forging the from address :-), and there is no opportunity for mistakenly assuming endorsement. Implementing this policy would require a few more excisions to the Struts web site (and save Ted some work in the long run, since he does most of the routine update work), but not horrendously large amounts. The most visible change would probably be the list of books on the front page and the associated books.html page, since they are all commercial activities. I agree with Ted on the consultants and powered pages. Ted, would this deal with the criteria of your -1? -Ted. Craig - 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: Wildcard-matched actions (again)
Doesn't the last email from Don imply there is no penalty (if the person isn't using wildcards)? -- extract from Don's last email You still wouldn't see any performance hit as since you aren't using any action mappings with wildcards, there would be no pattern matching. It can only match a URI against a compiled pattern if one or more action mappings use wildcards. If there are no compiled patterns, the method will simply exit and your default action will be matched. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 3:39 PM To: Struts Developers List Subject: Re: Wildcard-matched actions (again) --- Robert Leland [EMAIL PROTECTED] wrote: Matthias Bauer wrote: I would like to be able to turn off this pattern matching feature, as performance is a very critical issue for a CMS. +1 So far I haven't heard any definitive answer to the performance question. If there isn't any performance penalty then we don't need the ability to turn off pattern matching. I'm starting to think this enhancement should wait for 1.2.1 instead of trying to squeeze it in for 1.2.0. David --- Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert Leland [EMAIL PROTECTED] -- Java, J2EE, Struts, Web Application Development 804 N. Kenmore Street +01-703-525-3580 Arlington VA 22201 - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: multipart/form-data (bug?) or intended behavior?
Can't this multi-part request forward problem be fixed by unwrapping the request
before doing RequestDispatcher.forward/include? All the methods in RequestProcessor
get the real request object from within the MultipartRequestWrapper before calling
doForward() or doInclude() except for processActionForward() which gets called after
action.execute().
I think the
if (request instanceof MultipartRequestWrapper) {
request = ((MultipartRequestWrapper) request).getRequest();
}
code should be moved to doForward() and doInclude() and removed everywhere else within
RequestProcessor. I will try this fix today. Probably won't work because it seems too
easy.
Hal
-Original Message-
From: Adam P. Jenkins [mailto:[EMAIL PROTECTED]]
Sent: Thu 4/18/2002 7:56 PM
To: Struts Developers List
Cc:
Subject: Re: multipart/form-data (bug?) or intended behavior?
Well, in your example scenario, you said that ActionOne first saves the
multipart data to a file, and then forwards to ActionTwo, so there's no
problem. When happens when a redirect forward is returned from an Action is
as follows:
- Struts sees that the redirect property of the ActionForward is true, so
instead of just calling the next action in the same request, it sends a
response back to the browser. The response contains a Redirect: header which
contains the URL for ActionTwo. The browser sees the Redirect header and so
makes a request for ActionTwo, this time with no multipart/form-data. The
new request gets passed by struts directly to ActionTwo.
Where the above would be a problem is if ActionOne did NOT handle the
multipart data, but instead forwarded to ActionTwo expecting ActionTwo to
handle the multipart data. Since a redirect causes a new request to be made,
any data in the current request is lost by the time ActionTwo gets called.
But since in this case ActionOne already handled the request, there's no real
problem.
Another example of where using a redirect forward is a problem is if your
action saves some ActionMessages or ActionErrors in the request and then
forwards, expecting the page being forwarded to to display the messages.
Since ActionMessages are stored in the request object, if you returned a
redirect forward from your action, the messages will be lost by the time the
next page gets the request.
Adam
On Thursday 18 April 2002 01:14 pm, you wrote:
Thats a pretty dirty workaround if your multipart request contained a
5MB file being uploaded. Or what occurs in that case (when the browser
makes the new request)?
Rob
Adam P. Jenkins wrote:
I believe another workaround is to set the redirect attribute on the
forward to true. E.g. the action config for ActionOne would have a local
forward like this:
forward name=nextaction path=/action2.do redirect=true/
Then in ActionOne, when you return mapping.findForward(nextaction),
this will cause the struts to send a redirect header to the browser
telling it to make a new request for action2. This works fine unless you
really wanted ActionTwo to have access to the same request attributes and
parameters as ActionOne.
Adam
On Thursday 18 April 2002 08:47 am, rob wrote:
It's been this way since struts 1.0 (and likely prior to) but http
requests carrying multipart/form-data posts result in an exception being
thrown if forwarded through more than one action.
(e.g request flow)
1 - submit multipart/form-data request (with at least one file input)
request is forwarded to ActionOne.
2 - ActionOne handles multipart data, writes a file to disk does
something with other parameters etc. then forwards to ActionTwo.
3 - Exception is thrown.
This occurs in the following versions I've tested 1.0.x, 1.1-b1. Copies
of the exceptions follow this post.
Workaround, never forward to a second action, always forward to a .jsp
which must be the end point for the request after the first action.
(This kind of sucks).
If this is a bug then consider it submitted, if it's designed this way
then how about changing it? (pretty please?)
Thanks
Rob
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
Re: use of pluggable converters in ConvertUtils changes Struts behavior for primitive wrapper properties
Personally I like using the wrapper classes because of their ability to
represent null and I think the automatic conversion of invalid numbers to a
zero is somewhat dangerous although unavoidable since exceptions aren't an
option. Unless I am the only person that uses wrapper classes for property
values I think the change in behavior is going to break too many people's
applications.
Zero might be an OK default for commons release but I think Struts 1.1
should register it's own Converters with the defaults set with compatibility
in mind.
Hal
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]; Deadman, Hal
[EMAIL PROTECTED]
Sent: Saturday, April 06, 2002 8:08 PM
Subject: Re: use of pluggable converters in ConvertUtils changes Struts
behavior for primitive wrapper properties
Grumble grumble ...
I would sure argue that the Struts 1.0 behavior is a bug. The biggest
problem is the inconsistency between the native types and the wrapper
classes. In Struts 1.0:
ConvertUtils.convert(1a3, Integer.TYPE) -- 0 (the default value)
ConvertUtils.convert(1a3, Integer.class) -- null
I think that the current behavior of commons-beanutils is more
sensible, even though it is different:
ConvertUtils.convert(1a3, Integer.TYPE) -- 0 (the default value)
ConvertUtils.convert(1a3, Integer.class) -- 0 (the default value)
What do you guys think? (Note that this only affects people who use the
wrapper classes like java.lang.Integer for your property values -- if you
have been using the Java primitive types, you will have been receiving a
zero all along.)
The second part of Hal's bug report on this (#7784) points out that there
is no way to define null as the default value to be returned on conversion
errors. I'm going to address that by making it possible to declare this
is what you want.
Craig
On Tue, 26 Mar 2002, Deadman, Hal wrote:
Date: Tue, 26 Mar 2002 21:18:03 -0500
From: Deadman, Hal [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED],
Deadman, Hal [EMAIL PROTECTED]
To: 'Struts Dev List' [EMAIL PROTECTED]
Subject: use of pluggable converters in ConvertUtils changes Struts
behavior for primitive wrapper properties
I think the addition of pluggable converters in ConvertUtils on 3/18 has
changed the way Struts handles empty form fields that map to primitive
Wrapper bean properties. The default IntegerConverter uses a default
value
of Integer(0) instead of null.
This is a fairly significant problem because it's not backwards
compatible
with Struts 1.0. I often store id#s in hidden form fields that map to a
Long
or Integer property on the serverside bean. If the hidden field is empty
in the html then Struts used to populate the setBlah(Integer) method
with a
null, now it passes a zero. That causes me to try an update of entity 0
instead of adding a new entity, for example.
I modified the struts-exercise-taglib to add a test to demonstrate this
problem. Below are the patches to the two files that would need to be
changed.
-- add to struts-exercise-taglib html-setters.jsp
tr
th align=rightintegerProperty/th
td align=left
html:text property=integerProperty size=32/
/td
th align=rightnested.integerProperty/th
td align=left
html:text property=nested.integerProperty size=32/
/td
/tr
-- add to TestBean in .../webapp/exercise
/**
* An integer property.
*/
private Integer integerProperty = new Integer(123);
public Integer getIntegerProperty() {
return (this.integerProperty);
}
public void setIntegerProperty(Integer integerProperty) {
this.integerProperty = integerProperty;
}
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Branch Restriction error due to struts..
I think it has to do with the size of the method in the JSP's servlet exceeding some JVM/java limit. You can try breaking the JSP up using jsp:include or using fewer tags. Could you generate the form fields inside an iterate tag? That would reduce the size of the generated java code. -Original Message- From: Sachin [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 10:54 AM To: [EMAIL PROTECTED] Subject: Branch Restriction error due to struts.. Hi, Could anyone explain solution to Branch restiction problem which occurs due to struts rags. If my webpage contains lots of fileds(for eg., 30 text fields, 10 combo boxes, 40 check boxes) then i am not able to load the page. it will throw me an error which states some branching problems. if i use struts tags for all the fields then it will throw the above error. Thanks Regards Sachin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
re-post: use of pluggable converters in ConvertUtils changes Struts behavior for primitive wrapper properties
Is the change I describe below to way beanutils does primitive wrapper conversions going to be permanent? The addition of pluggable converters in ConvertUtils on 3/18 has changed the way Struts handles empty form fields that map to primitive Wrapper bean properties. For example, the default IntegerConverter uses a default value of Integer(0) instead of null. This is a fairly significant problem because it's not backwards compatible with Struts 1.0. I often store id number in hidden form fields that map to a Long or Integer property on the serverside bean. If the hidden field is empty in the html then Struts used to populate the setBlah(Integer) method with a null, now it passes a zero. That causes me to try an update of entity 0 instead of adding a new entity, for example. The problem also occurs with drop downs that use numeric key values. In those cases I normally submit a if nothing is selected and now that becomes 0 in the form bean. The current set of converters doesn't even accept null as a legal default value. If the default is set to null then an exception is thrown when the conversion fails. In order to fix my applications I used an older common-beanutils with the 1.1 beta but if this isn't going to be fixed then I will have to write my own set of converters for Integer and Long. Let me know if I am confused or confusing. Thanks, Hal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
use of pluggable converters in ConvertUtils changes Struts behavior for primitive wrapper properties
I think the addition of pluggable converters in ConvertUtils on 3/18 has
changed the way Struts handles empty form fields that map to primitive
Wrapper bean properties. The default IntegerConverter uses a default value
of Integer(0) instead of null.
This is a fairly significant problem because it's not backwards compatible
with Struts 1.0. I often store id#s in hidden form fields that map to a Long
or Integer property on the serverside bean. If the hidden field is empty
in the html then Struts used to populate the setBlah(Integer) method with a
null, now it passes a zero. That causes me to try an update of entity 0
instead of adding a new entity, for example.
I modified the struts-exercise-taglib to add a test to demonstrate this
problem. Below are the patches to the two files that would need to be
changed.
-- add to struts-exercise-taglib html-setters.jsp
tr
th align=rightintegerProperty/th
td align=left
html:text property=integerProperty size=32/
/td
th align=rightnested.integerProperty/th
td align=left
html:text property=nested.integerProperty size=32/
/td
/tr
-- add to TestBean in .../webapp/exercise
/**
* An integer property.
*/
private Integer integerProperty = new Integer(123);
public Integer getIntegerProperty() {
return (this.integerProperty);
}
public void setIntegerProperty(Integer integerProperty) {
this.integerProperty = integerProperty;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Build errors - templates library
The JSPException with a constructor that takes a throwable is a JSP 1.2 feature. -Original Message- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: Monday, March 11, 2002 6:27 AM To: Struts Developers List Subject: Build errors - templates library Hello Struts, Now I have compile-time errors in last CVS version - compile.library: [javac] Compiling 9 source files to E:\projects\jakarta-struts\target\library\classes [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\GetTag.java:184: cannot resolve symbol [javac] symbol : constructor JspException (java.io.IOException) [javac] location: class javax.servlet.jsp.JspException [javac]throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\GetTag.java:194: cannot resolve symbol [javac] symbol : constructor JspException (java.io.IOException) [javac] location: class javax.servlet.jsp.JspException [javac] throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\GetTag.java:197: cannot resolve symbol [javac] symbol : constructor JspException (javax.servlet.ServletException) [javac] location: class javax.servlet.jsp.JspException [javac]throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\InsertTag.java:15 8: cannot resolve symbol [javac] symbol : constructor JspException (java.io.IOException) [javac] location: class javax.servlet.jsp.JspException [javac] throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\InsertTag.java:16 1: cannot resolve symbol [javac] symbol : constructor JspException (javax.servlet.ServletException) [javac] location: class javax.servlet.jsp.JspException [javac] throw new JspException(ex); [javac]^ [javac] Note: E:\projects\jakarta-struts\src\share\org\apache\struts\util\Re questUtils.java uses or overrides a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 5 errors BUILD FAILED -- Best regards, Oleg mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re[2]: Build errors - templates library
I think the plan is too keep Struts 1.1 compatable with Servlet 2.2/JSP 1.1 so the change Martin made recently will probably have to rolled back until after 1.1 is released. I used to miss the nested exceptions when I first started using Struts but it hasn't been an issue for me recently. I think that's because I am not using templates right now so my tag errors aren't as deeply nested and less likely to get trampled on by outer tags. -Original Message- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: Monday, March 11, 2002 9:27 AM To: Struts Developers List; Deadman, Hal Subject: Re[2]: Build errors - templates library Hello Hal, So, we take a path to the JSP 1.2 only? Monday, March 11, 2002, 5:20:04 PM, you wrote: DH The JSPException with a constructor that takes a throwable is a JSP 1.2 DH feature. -Original Message- From: Oleg V Alexeev [mailto:[EMAIL PROTECTED]] Sent: Monday, March 11, 2002 6:27 AM To: Struts Developers List Subject: Build errors - templates library Hello Struts, Now I have compile-time errors in last CVS version - compile.library: [javac] Compiling 9 source files to E:\projects\jakarta-struts\target\library\classes [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\GetTag.java:184: cannot resolve symbol [javac] symbol : constructor JspException (java.io.IOException) [javac] location: class javax.servlet.jsp.JspException [javac]throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\GetTag.java:194: cannot resolve symbol [javac] symbol : constructor JspException (java.io.IOException) [javac] location: class javax.servlet.jsp.JspException [javac] throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\GetTag.java:197: cannot resolve symbol [javac] symbol : constructor JspException (javax.servlet.ServletException) [javac] location: class javax.servlet.jsp.JspException [javac]throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\InsertTag.java:15 8: cannot resolve symbol [javac] symbol : constructor JspException (java.io.IOException) [javac] location: class javax.servlet.jsp.JspException [javac] throw new JspException(ex); [javac] ^ [javac] E:\projects\jakarta-struts\src\share\org\apache\struts\taglib\ template\InsertTag.java:16 1: cannot resolve symbol [javac] symbol : constructor JspException (javax.servlet.ServletException) [javac] location: class javax.servlet.jsp.JspException [javac] throw new JspException(ex); [javac]^ [javac] Note: E:\projects\jakarta-struts\src\share\org\apache\struts\util\Re questUtils.java uses or overrides a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 5 errors BUILD FAILED -- Best regards, Oleg mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] DH -- DH To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] DH For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Best regards, Olegmailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PROPOSAL] Modular Applications (the BIG checkin) [LONG]
I assume there will be at least one beta release of Struts 1.1 and a release candidate after that. That will provide ample time to identify any specific incompatibilities and address them. At least we will be able to identify the exact cause of the incompatibility and then we can discuss a specific problem rather than unidentified issues. It's too early to give up on the ideal solution which is not adding a second package. A second package will cause grief similar to the struts-form.tld. The periodic bug reports of people trying to use that taglib are annoying but imagine the time the bug reporters wasted trying to use that taglib. It probably would have saved the world some time if it had been removed prior to 1.0. People using pre-1.0 Struts or pre-1.1 nightly builds should expect to make some minor changes if they upgrade. Especially when the changes will save them time in the long run. People moving from 1.0 to 1.1 are already in for some global search and replace due to the commons stuff. They are also going to have to do some extensive testing because a great deal of changes have been made, aside from the Big check-in. Nobody needs to upgrade an application that is well underway with a particular version of Struts. If they do upgrade then they need to examine the migration issues and weigh the migration cost against benefits of the new features. Hopefully there won't be any known migration issues that aren't resolved during a beta release. Hal -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, February 18, 2002 7:47 AM To: Struts Developers List Subject: Re: [PROPOSAL] Modular Applications (the BIG checkin) [LONG] Martin Cooper wrote: If there are incompatibilities that cannot be remedied, yes. But that is true of any change we might make from one version to the next. If people don't want to use new functionality, they don't have to upgrade. I haven't been able to trace everything back, but I have run into issues with the new controller looking for an ActionConfig object if I get my pre-BIG and post-BIG 1.1 JARs get confused. This may be a Tiles-related issue (which would also apply to any ad-hoc Tiles-like enhancements people have made). My core issue is that we really had enough for 1.1 release before the new servlet. Now if for any reason they cannot use the new servlet, then we have effectively locked them out of the reset of the 1.1 codebase, with falling back all the way back to 1.0 being the only ready alternative. If people are as eager as they appear to be to use the other new functionality being introduced in Struts 1.1 (indexed and nested tag extensions, declaratoive exception handling, etc), then I would think that the beta and RC cycles should flush out anything else. Again, this is my point. I'm concerned that we are linking a rather big, extremely cool change with all these very useful, but somewhat boring incremental changes, and not providing developers with enough granularity. I'm not sure what you're referring to here. What import statements need to be changed to deploy Struts 1.1 today? I have not had to change any except where I'm actually extending the new functionality. Here I refer to the the switch from 1.0 to 1.1, where we changed over to the Commons packages. 8. The existing package is not broken. The likelihood that it will require maintenance is negligible. If we declare that the original ActionServlet is feature-locked, we are not obligated to change it in any way. All new functionality can be bundled with the new controller. There are currently almost 100 open issues in Bugzilla, so to some extent it is broken. Of course, we'll be fixing some number of those prior to releasing Struts 1.1 anyway. However, if we have separate packages for the multi-app stuff, then maintenance becomes harder, because each bug potentially needs to be fixed in two places. I don't believe the broken issues relate to the ActionServlet package. If they did, then they should also be part of a 1.0.3 release. 13. Giving the new package a new name will reduce the maintenance cost of dependent components by allowing a single distribution that works with either controller. I guess I don't understand this point. The point is that if distributing both servlets did not create a lot of duplicate code, why can't we have both? People who can't use the new one for some reason, say they extended the ActionServlet in unseemly ways, can continue to use the original servlet, and still be able to use the other new features. Some of these features have been in place since right after 1.0 was released. If distributing both servlets does create a lot of duplicate code, then I would anticipate that once this gets out of the laboratory, we will find a lot of people with compatibility issues. In my day job, my team is already starting to
RE: Bad classloading, why does Struts continue to use Class.forName()?
I filed a bug report for this same problem. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5774 -Original Message- From: Colin Sampaleanu [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 15, 2002 1:47 PM To: [EMAIL PROTECTED] Subject: Bad classloading, why does Struts continue to use Class.forName()? About a year ago we were using the Digester in a non-struts related project, and had some pretty bad problems with classloading in an environment using 'containers' for various modules, since it used the old-style Class.forName(xxx) mechanism to load classes, instead of the recommended Thread.currentThread().getContextClassLoader().loadClass(xxx); I had a bit of discussion about this with Craig, and in the the meantime, the Digester in commons got updated to allow it to use the context classloader (although not by default). The problem however, is that Struts, both 1.0.x and lower, and the CVS version, continue to use Class.forName() all over the place, and continue to use the Digester (either the internal one in 1.0.x with Class.forName() or the external commons version with the context flag off) in a bad fashion. In some deployment scenarios, generally when running in an app-server like environment, with multiple 'containers', it is extremely problematic to use code that does classloading via Class.forName() (since the proper versions of classes are not loaded), to the point that in many cases the code is not usable. There is generally no argument for using Class.forName over the current context classloader, except when JDK 1.1 compatibility is required. We are currently using Struts in a deployment scenario where it is used by code in the App Server's main classpath, and it is also used by one of the Web Apps running in a container's clasloader lower down in the classloader hierarchy. We were not able to get this going until we went through the Struts code and changed all the uses of Class.forName to use the context classloader isntead, and properly initialized the Digester to do so as well. Once this was done there were no problems. I am willing and able to supply diffs to patch the current CVS version in this fashion, but before I do so I would like to knw if they would be checked in, or the arguments against it. The alternative approach is to make all the code able to work both ways, based on a flag, similar to how the commons Digester works right now. The only reason I can see to do so is if Struts still needs to run under JDK 1.1 (which I believe it can't any longer anyways). Regards, Colin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
using digester and struts in an EAR file
I have a web app and ejb jar files combined in an ear file. If I want to use struts in the war file and the digester in some of the ejbs, I have a problem because the war classloader is a child of the ejb classloader (at least in Weblogic 6.1) which means classes loaded by the ejb class loader can't see the webapp's classes including the classes in struts.jar. If I put the commons-digester.jar in the ejb classpath (via the Manifest.mf Classpath:) then when the struts-config.xml is parsed the digester won't be able to find struts classes. If I leave commons-digester.jar in the webapp lib directory then the ejbs that want to use it can't see the digester classes. Am I missing something? Is there any way that the Digester could be told which class loader to use when it instantiates objects that it's looking for? Maybe then the ActionServlet could tell the Digester to use the ActionServlet classloader which should allow the Digester to find all the classes in the webapp? Then I could include common-digester.jar in both the ejb classpath and the webapp classpath. Has anyone else run into this problem? Thanks, Hal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: using digester and struts in an EAR file
Shouldn't the struts ActionServlet be calling setClassLoader() or setUseContextClassLoader()? When I move commons-digester.jar and commons-collections.jar to the ejb classpath where they are available to both EJBs and struts, the the digester can't find ActionFormBean and all of the other struts classes that it looks for (because they are in the child classloader of the ejb classloader). Moving struts.jar to the ejb classpath would not help because the classes that extend the struts classes would not be visable to the ActionServlet. Maybe there should be an initparam option that tells the ActionServlet to call setUseContextClassLoader? Hal -Original Message- From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig R. McClanahan Sent: Tuesday, December 11, 2001 3:05 PM To: Struts Developers List; Deadman, Hal Subject: Re: using digester and struts in an EAR file On Tue, 11 Dec 2001, Deadman, Hal wrote: Date: Tue, 11 Dec 2001 14:43:21 -0500 From: Deadman, Hal [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], Deadman, Hal [EMAIL PROTECTED] To: 'Struts Dev List' [EMAIL PROTECTED] Subject: using digester and struts in an EAR file I have a web app and ejb jar files combined in an ear file. If I want to use struts in the war file and the digester in some of the ejbs, I have a problem because the war classloader is a child of the ejb classloader (at least in Weblogic 6.1) which means classes loaded by the ejb class loader can't see the webapp's classes including the classes in struts.jar. If I put the commons-digester.jar in the ejb classpath (via the Manifest.mf Classpath:) then when the struts-config.xml is parsed the digester won't be able to find struts classes. If I leave commons-digester.jar in the webapp lib directory then the ejbs that want to use it can't see the digester classes. Am I missing something? Is there any way that the Digester could be told which class loader to use when it instantiates objects that it's looking for? Maybe then the ActionServlet could tell the Digester to use the ActionServlet classloader which should allow the Digester to find all the classes in the webapp? Then I could include common-digester.jar in both the ejb classpath and the webapp classpath. Has anyone else run into this problem? I take it you are using nightly builds of Struts for this (and therefore a current build of Digester from commons)? If so, you have two options (assuming that commons-digester.jar is in a shared repository in your server): * Call digester.setClassLoader() to set the class loader you want Digester to use for loading application classes. Normally, this would be the class loader for your web application, which can be more easily accessed by the second option -- but you can set any class loader you need. * Call digester.setUseContextClassLoader(true) before calling parse(). This tells Digester to use the thread context class loader (which will be the class loader for your web app) to load classes from, even if Digester itself is loaded from a shared class loader. Thanks, Hal Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: bean:write format attribute changes bean:write default behavior
This is from an off-list email between Oleg and I: From Oleg to me: Hello Hal, Default format strings can be written as - org.apache.struts.taglib.bean.format.int=## org.apache.struts.taglib.bean.format.float=##, org.apache.struts.taglib.bean.format.timestamp=hh 'o''clock' a, org.apache.struts.taglib.bean.format.date=EEE, MMM d, ''yy org.apache.struts.taglib.bean.format.time=h:mm a values for resource file entries are standart Java format strings for date, time and number values. From me to Oleg: That makes more sense. For some reason the bean:write documentation didn't make that clear to me. I think the doc should definately contain those examples. Couldn't you make the behaviour so that if the format task isn't used, and the key is not found in the resource file, no formating will take place? That would acheive backwards compatability. If someone wants automatic formating without using the format attribute of the bean:write tag then they just have to add the entries to the resource file. I often used bean:write to print out things that aren't meant to be seen such as when I print out a number for the body of a multi-box tag. That will break something if the default is to format the number with commas or periods depending on your locale. -Original Message- From: Will Jaynes [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 9:43 AM To: Struts Developers List; Oleg V Alexeev Subject: Re: bean:write format attribute changes bean:write default behavior Oleg, I'm sorry, but I'm not at all clear as to what you are saying here. Could you please restate it? Will - Original Message - From: Oleg V Alexeev [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED]; Deadman, Hal [EMAIL PROTECTED] Sent: Wednesday, December 05, 2001 8:50 AM Subject: Re: bean:write format attribute changes bean:write default behavior Hello Hal, You can add to application resources strings with default format strings for such types as (first string - key for resources, nested strings is list of datatypes) - org.apache.struts.taglib.bean.format.int java.lang.Byte, java.lang.Short, java.lang.Integer, java.lang.Long, java.math.BigInteger org.apache.struts.taglib.bean.format.float java.lang.Float, java.lang.Double, java.math.BigDecimal org.apache.struts.taglib.bean.format.timestamp java.sql.Timestamp org.apache.struts.taglib.bean.format.date java.sql.Date org.apache.struts.taglib.bean.format.time java.sql.Time Tuesday, December 04, 2001, 5:07:56 AM, you wrote: DH I have some code that uses bean:write and the datetime:format tag from DH taglibs project. I use it like this: DH datetime:format pattern=MM/dd/bean:write name=contractinfo DH property=beginDate.time//datetime:format DH The bean:write used to print out the number of milliseconds returned by DH getBeginDate().getTime(). DH I got a nightly build and now the bean:write prints the number of DH milliseconds with commas which is breaking the datetime:format tag. DH Shouldn't the default behavior for bean:write stay the same if I am not DH using the format attribute? I just want to let everyone know that the format DH attribute as added will break some existing code that is out there. At the DH very least it should be added as a potential gotcha to the release notes for DH Struts 1.1. DH I think the format attribute is a good thing and I wouldn't mind not using DH datetime:format because my current technique is painful when the date is DH null. DH Thanks, Hal DH -- DH To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] DH For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Best regards, Olegmailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
bean:write format attribute changes bean:write default behavior
I have some code that uses bean:write and the datetime:format tag from taglibs project. I use it like this: datetime:format pattern=MM/dd/bean:write name=contractinfo property=beginDate.time//datetime:format The bean:write used to print out the number of milliseconds returned by getBeginDate().getTime(). I got a nightly build and now the bean:write prints the number of milliseconds with commas which is breaking the datetime:format tag. Shouldn't the default behavior for bean:write stay the same if I am not using the format attribute? I just want to let everyone know that the format attribute as added will break some existing code that is out there. At the very least it should be added as a potential gotcha to the release notes for Struts 1.1. I think the format attribute is a good thing and I wouldn't mind not using datetime:format because my current technique is painful when the date is null. Thanks, Hal -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Converting struts-html tags to be XHTML-compliant
I would think request scope would be better than pageContext so the
attribute will be available inside jsp:include or template/component
includes.
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 12, 2001 12:01 AM
To: [EMAIL PROTECTED]
Subject: Converting struts-html tags to be XHTML-compliant
I am taking on the project of converting (with backwards compatibility) all
the struts-html tags to be XHTML-compliant.
I'd like to use this e-mail to tell you my approach, ask you for advice, and
get your feedback.
1. Approach:
In HtmlTag.java, add
if (xhtml)
pageContext.setAttribute(xhtml, true);
In all other html-producing tags (i.e. img, input), do a check when closing
the tag:
// check if this is an XHTML document
String xhtml = (String) pageContext.getAttribute(xhtml);
if (xhtml != null xhtml.equals(true)) {
results.append(\ /); // extra space before close
will allow XHTML to work in older browsers
} else {
results.append(\);
}
2. Advice:
Should I be setting the xhtml variable in the pageContext, request, or
session. Page seems to make the most sense since that is what this variable
relates to. However, to do this (to my understanding), I have to create
HtmlTei.java and add the teiclass declaration to the struts-html.tld:
public class HtmlTei extends TagExtraInfo {
/**
* Return information about the scripting variables to be created.
*/
public VariableInfo[] getVariableInfo(TagData data) {
return new VariableInfo[] {
new VariableInfo(data.getAttributeString(xhtml),
java.lang.String,
true,
VariableInfo.NESTED)
};
}
}
However, this does not work as I'd expect it to. What I'm expecting is that
I am exposing the xhtml variable simply by adding the HtmlTei class - but
it's not working at all.
3. Feedback:
Please let me know what you think of this approach. By doing this, and
adding a check if the user wants the doc to be XHTML, we should achieve full
backwards compatibility, and be able to convert the struts-html tags to be
XHTML-compliant.
Thanks,
Matt
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Declarative exception handling for Action classes
I think this is a good idea. I also have similar repetative exception
handling in all of my action classes. Having global exceptions to handle
general system errors would be helpful. I might prefer to handle some
expected exceptions in my action class just to make the code easier to
read but I could do without having to trap Exception in every action class
and forwarding to a system error page.
Wouldn't Joe Faith's example have to support a forward or path attribute so
the action servlet would know where to forward to?
action
exception error=some.error.key type=package.Exception
forward=failure /
/action
or
action
exception error=some.error.key type=package.Exception
path=/error.jsp /
/action
-Original Message-
From: faith [mailto:faith]On Behalf Of Joe Faith
Sent: Thursday, November 01, 2001 5:44 AM
To: Struts Developers List
Subject: Re: Declarative exception handling for Action classes
This looks useful, but would be even more so if you could include the
following type
of exception mapping:
action
exception error=some.error.key
type=package.Exception /
/action
The action servlet would then generate an ActionError and add it to the
request.
This would save a lot of code of the following type:
} catch (package.Exception e) {
errors.add(ActionErrors.GLOBAL_ERROR, new
ActionError(some.error.key));
saveErrors(request, errors);
return (mapping.findForward(failure));
}
which seems to take up half of my actions at the moment.
Laine Donlan wrote:
Each action mapping can define any number of exceptions that may occur
and how they should be handled. The handling of the exceptions
consists
of the definition of a key value (error message, etc) , and a path
(optional - input of the action would be the default). When an
exception occurs that can be handled the ActionException (consisting
of
key, and path) is placed into the user's session under a key constant
-
org.apache.struts.action.ACTION_EXCEPTION. It can then be handled
however is necessary by an app.
The following would be an example of an action mapping:
action path=/handleSomething
name=someForm
validate=false
input=/someUri.
forward ...just like always/
exception key=some.key
type=some.package.business.logic.Exception/
exception key=some.other.key
type=some.package.business.logic.Exception2
path=/someotherUri.../
exception key=general
type=java.lang.Exception/
exception key=ejb
type=javax.ejb.EjbException
hierarchachal=false/
/action
The following outlines how each of the exceptions would be handled:
1) If an some.package.business.logic.Exception is throw from the
Action
perform method, the client will be dispatched to the input of the form
with an ActionException placed into the session under a specific key.
2) If an some.package.business.logic.Exception2 is thrown, the client
will be dispatched to the path specified in that mapping with the
ActionException placed in the session.
3) If anything other than the previous 2 exception or an EjbException
is
thrown, the client would be re-directed to the input of the form,
again
with the ActionException placed into the session.
4) If an EjbException is thrown (it's children would not be handled by
this) then the client would be dispatched with that ActionException in
the session under a defined constant value.
The changes to the code base consisted of:
1) Addition of ActionException and ActionExceptions classes. Very
much
like the existing mapping classes.
2) Change of the perform() method signature to throw Exception rather
than IOException and ServletException
3) Update the processActionPerform() method of the ActionServlet
perform
the try{}cactch{} and to map resultant exceptions.
4) Add the digesting into the ActionServlet init()
5) Add the ActionExceptions reference into the ActionMapping.
I have attached the code:
changes.zip
As well as diffs of the changes to the ActionServlet and Action
classes
Action-diff.txt ActionServlet-diff.txt
A couple of major @todo's in the code would be the implementation of
global-exceptions, and a currently hard-coded exception message in any
unhandled exception that is wrapped into a ServletException. I wanted
to see if there was interest for this type of feature, if so I can
easily put the rest of it together and submit it.
Thanks, any comments or feedback would be appreciated.
Name: changes.zip
Type: Zip Compressed Data
(application/x-zip-compressed)
changes.zip Encoding: base64
Description: changes.zip
Download Status: Not
RE: Role-Based Actions
If this is added, I'm willing to modify the struts-example to use roles and form-based authentication. I figured out a trick last week (using javascript and cookies) to show the user loginForm again on the form-error page and allow them to login from there. I can add this to the sample that I'll create. Why do you need javascript and cookies to redisplay the login page on the form-error-page? I just call the same action for both form-login-page and form-error-page. The action forwards to a login jsp and uses a url parameter to determine whether or not to display an error message to the user. Maybe I don't understand what you are doing? login-config auth-methodFORM/auth-method realm-namerdbmsRealm/realm-name form-login-config form-login-page/login.do?type=attempt/form-login-page form-error-page/login.do?type=failed/form-error-page /form-login-config /login-config
RE: Type Date is a problem.
Make a get/set that accepts a String for each of your form date fields.
Parse the string into a Date in your validate method. If it doesn't parse
correctly then use report an error to the user.
Use a method like this to parse your Dates. A null return value indicates an
invalid date.
protected java.util.Date parseDate(String dateString, String format)
{
if (dateString == null)
{
return null;
}
try
{
DateFormat df = new SimpleDateFormat(format);
// setLenient avoids allowing dates like 9/32/2001 which would
otherwise
parse to 10/2/2001
df.setLenient(false);
return df.parse(dateString);
}
catch(ParseException pe)
{
return null;
}
}
-Original Message-
From: Rubens Gama [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 24, 2001 9:02 AM
To: [EMAIL PROTECTED]
Subject: Type Date is a problem.
Importance: High
how i can solve the problem DATE type of a FormBean's property?
the ActionServlet cannot set a property DATE.
I need help.
Thanks.
RE: Arrrg...
I was getting similar errors trying to use struts post 1.0 on Weblogic 6.0 which uses jaxp 1.0. Struts 1.1 requires a server with a jaxp 1.1 xml parser. Maybe that's the problem? -Original Message- From: Craig Tataryn [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 17, 2001 4:13 PM To: Struts Dev Group Subject: Arrrg... I tried resubscribing to the struts-user group to post this, but the mail list isn't getting back to me as to whether or not it subscribed me. Thus I am posting this here: I keep getting this error when starting tomcat 3.2.1 on Unix: 2001-10-17 04:03:25 - ContextManager: Adding context Ctx(/struts-example ) Exception in thread main java.lang.NoSuchMethodError at org.apache.commons.digester.Digester.getReader(Digester.java:527) at org.apache.commons.digester.Digester.parse(Digester.java:1206) at org.apache.struts.webapp.example.DatabaseServlet.load(DatabaseServlet.java:2 52) at org.apache.struts.webapp.example.DatabaseServlet.init(DatabaseServlet.java:1 75) at javax.servlet.GenericServlet.init(GenericServlet.java:258) at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317) at org.apache.tomcat.core.Handler.init(Handler.java:215) at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:296) at org.apache.tomcat.context.LoadOnStartupInterceptor.contextInit(LoadOnStartup Interceptor.java:130) at org.apache.tomcat.core.ContextManager.initContext(ContextManager.java:491) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:453) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:195) at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235) Any clue? Thanks, tataryn:craig/
RE: Enhanced errors tag
I think a new tag that allows you to not put HTML in your resource file already exists in post 1.0 Struts in the form of the html:messsage(s) tag. It can be used in place of html:errors. The errors class is now a subclass of a message class. -Original Message- From: Martin D Bayly [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 15, 2001 10:00 AM To: [EMAIL PROTECTED] Subject: Enhanced errors tag A useful enhancement to the html:errors/ tag would be to have a single message header/footer as well as an error block header and footer. This enables you to keep your message strings free of html markup such as the li shown in the examples. eg. errors.header=h3font color=redValidation Error/font/h3You must correct the following error(s) before proceeding:ul errors.footer=/ulhr with the extension of: error.header=li error.footer=/li The attached is a version of our ErrorsTag (copied from the struts errorstag) incorporating this change (See attached file: ErrorsTag.java) Martin
RE: findForward and Errors
You can put an entry in the property files like this:
error.message=Error {0}
or
error.message={0}
and then you can do something like this:
...new ActionError(error.message, e.getMessage())...
or whatever it is that allows you to pass substitution arguments to a
message.
-Original Message-
From: Shawn Sohl [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 5:02 PM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: RE: findForward and Errors
Craig,
Thanks for your reply. I have tested the code in the logonAction
class it does work. However, it only works when you use a key in the
properties file. If I have this code in a catch statement, how can I use
the actual error message with the getMessage() method of the exception
class? Any ideas on how to get around this?
Thanks
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 14, 2001 1:20 PM
To: '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'
Subject: Re: findForward and Errors
On Tue, 14 Aug 2001, Shawn Sohl wrote:
In my Action class I catch errors if they occur. What I want to know is
can
I create an ActionErrors object within my Action class and add an error
to
it like I do in a Form class. Basically what I want to do is shown in the
code below. My .jsp page that failure points to has the
html:errors/
tag within it but it isnt picking up the error. I know I can create and
set
an attribute within the response object and pass the error that way but I
thought I could use something like I'm trying to do below.
catch(Exception e)
{
ActionErrors errors = new ActionErrors();
errors.add(error,new ActionError(e.getMessage());
return mapping.findForward(failure);
}
Thanks
The Struts example application does something very similar to this in
LogonAction -- since that is where an invalid username/pasword combination
is detected. I think this is a reasonable design approach.
Craig
RE: Hot to get the iterated objects ?
I am looking forward to the seeing indexed tags in the nightly build. Has a
commiter signed up to incorporate the indexed tag changes?
As for feedback on the code, I don't think it's appropriate to blow off the
whole tag without comment if the tag with indexed=true is not nested in an
iterate tag. I think an exception should be thrown instead. If an exception
isn't thrown then something needs to be written to the log file.
change:
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;
}
to:
IterateTag iterateTag = (IterateTag) findAncestorWithClass(this,
IterateTag.class);
if (iterateTag == null)
{
// this tag must only be nested in an IterateTag when indexed
attribute is true
throw new JspException(messages.getMessage(some.messagekey);
}
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 19, 2001 3:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Hot to get the iterated objects ?
Hi Prashanth,
Just posted an example of how to do this, using the indexed tags (see
http://husted.com/about/struts/indexed-tags.htm).
Note: these should be in the nightly build fairly soon!!
Cheers,
Dave
Prashanth_Thm [EMAIL PROTECTED] on 07/19/2001
10:38:57 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:(bcc: David Hay/Lex/Lexmark)
Subject: Hot to get the iterated objects ?
Hi,
I am new to struts.
I have a summary of rows(contains text boxes also) to be
displayed...which i am able
to display using the logic:iterate tag like this:
logic:iterate id=entry name=abcdForm property=abcdRates
But now i have to get the values entered in the rowswhen submit
is clicked.
how do i do that?
Your help is appreciated !
Thanks,
Prashanth.
RE: Client/Server Side Validation for Struts 1.1
Forcing a phone number or zip code to match some regular expression doesn't really make it valid. The only way to validate that kind of thing is to interface with an address verification system and that is only available in relatively few countries. It's in a users best interest to enter a valid address if they expect you to send them something. If you aren't sending them something, what do you want the information for? My solution to a form meant to be used by users in multiple countries would be to make it as general and accepting as possible. Maybe I would have a drop-down for US states and then have a province field that is only required if the state is not selected. Users will figure out how to get their address into the form and the mailman will figure out to deliver it. If a user wants to enter crap, they can still do it with regular expression validation. The purpose of validation should be to catch careless errors. If it's not worth it to the user to enter valid data, don't expect it to be valid. I think it overly complicates things to deal with forms based on a user's selected locale. I do think formating for display should take into account the locale. Hal -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, June 04, 2001 12:13 PM To: [EMAIL PROTECTED] Subject: Re: Client/Server Side Validation for Struts 1.1 We're not only talking just about language now, we're talking about validating things like telephone numbers and postal codes based where the user is located, regardless of what language they prefer. Michael's example was a Spanish-speaking resident in the US, who might be in the ES locale as to language, but would be in the US location as to telephone and postal code. I run into this myself, since we are on the Canadian border. We share the same telephone format but different postal codes. So, during validation we need more granularity than what is usually associated with locales. Perhaps some applications need two locale settings, one for language preference and another for location, and our validation routines may need to be written to recognize that. Jonathan wrote: I am still confused as to why this is all an issue if the user can select the languange of their choice. If it is an automatic thing, like if the server is reading the preferred language strings in the header, then maybe you have an issue becuase the Local is not selected by the user. It boils down to what language the user wants to see the pages displayed in. Check out the following sites: www.terra.com www.starmedia.com http://www.dgolpe.com In each case the user SELECTS the language of choice.
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
Does this change mean that there will be a link generated that looks like
this:
some.jsp?test=1amp;test=2
instead of
some.jsp?test=1test=2
If so, I don't think that will work. It doesn't work on Weblogic 6.0.
Calling getParameterValues() only sees the first value.
Hal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 01, 2001 4:22 PM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/src/share/org/apache/struts/util
RequestUtils.java
craigmcc01/06/01 13:21:41
Modified:src/share/org/apache/struts/util Tag: STRUTS_1_0_BRANCH
RequestUtils.java
Log:
Generate amp; instead of in request URIs so that the
output is still
legal XML syntax in the value returned by computeURL().
PR: Bugzilla #1938
Submitted by : Alessandro Vernet [EMAIL PROTECTED] (also supplied
the patch - thanks!)
Revision ChangesPath
No revision
No revision
1.14.2.2 +7 -7
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Requ
estUtils.java,v
retrieving revision 1.14.2.1
retrieving revision 1.14.2.2
diff -u -r1.14.2.1 -r1.14.2.2
--- RequestUtils.java 2001/06/01 18:45:03 1.14.2.1
+++ RequestUtils.java 2001/06/01 20:21:40 1.14.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Requ
estUtils.java,v 1.14.2.1 2001/06/01 18:45:03 craigmcc Exp $
- * $Revision: 1.14.2.1 $
- * $Date: 2001/06/01 18:45:03 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Requ
estUtils.java,v 1.14.2.2 2001/06/01 20:21:40 craigmcc Exp $
+ * $Revision: 1.14.2.2 $
+ * $Date: 2001/06/01 20:21:40 $
*
*
*
@@ -95,7 +95,7 @@
* in the Struts controller framework.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.14.2.1 $ $Date: 2001/06/01 18:45:03 $
+ * @version $Revision: 1.14.2.2 $ $Date: 2001/06/01 20:21:40 $
*/
public class RequestUtils {
@@ -364,7 +364,7 @@
url.append('?');
question = true;
} else
-url.append('');
+url.append(amp;);
url.append(URLEncoder.encode(key));
url.append('='); // Interpret null as
no value
} else if (value instanceof String) {
@@ -372,7 +372,7 @@
url.append('?');
question = true;
} else
-url.append('');
+url.append(amp;);
url.append(URLEncoder.encode(key));
url.append('=');
url.append(URLEncoder.encode((String) value));
@@ -383,7 +383,7 @@
url.append('?');
question = true;
} else
-url.append('');
+url.append(amp;);
url.append(URLEncoder.encode(key));
url.append('=');
url.append(URLEncoder.encode(values[i]));
RE: Bugzilla #1879 (Connection Pool handling of Stale Connections)
I agree, isClosed() won't work. An option for a testing a connection with a do-nothing SQL statement is needed. This is pretty standard for most connection pools that I have seen. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, June 01, 2001 5:41 PM To: [EMAIL PROTECTED] Subject: Bugzilla #1879 (Connection Pool handling of Stale Connections) For the details of this bug report, see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1879 As the report points out, GenericConnectionPool does not do anything about stale connections (i.e. those that the database has timed out, or what will happen to all of them if the database is rebooted). The proposal is to add a call to connection.getConnection().isClosed() in an attempt to assess the current state of the connection. I don't think this is the correct approach, because it depends on the JDBC driver doing something active to test for this (as opposed to just checking to see if the application has called close() on it). Doing this would also contradict the JDBC 2.1 Core API spec, section 11.1: The Connection.isClosed() method is only guaranteed to return true after Connection.close() has been called. Connection.isClosed() cannot be called, in general, to determine if a database connection is valid or invalid. A typical client can determine that a connection is invalid by catching the exception that is thrown when an operation is attempted. Therefore, it seems to me that allowing the configuration of an optional do nothing SQL command that GenericConnectionPool can use to test the validity of the connection would be a better approach. Does that make sense to folks? Craig
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
Sounds good. I don't have access to other browsers but they probably work
too.
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 01, 2001 5:31 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/util
RequestUtils.java
On Fri, 1 Jun 2001, Deadman, Hal wrote:
Does this change mean that there will be a link generated
that looks like
this:
some.jsp?test=1amp;test=2
instead of
some.jsp?test=1test=2
Yes, in the generated HTML code of the page (i.e. when you do a view
source).
If so, I don't think that will work. It doesn't work on
Weblogic 6.0.
Calling getParameterValues() only sees the first value.
In my tests, both Netscape and IE would both send this
hyperlink back in
with a '' instead, so multiple parameter values would still
be recognized
in the usual way. Are there clients that don't do this?
Hal
Craig
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 01, 2001 4:22 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/util
RequestUtils.java
craigmcc01/06/01 13:21:41
Modified:src/share/org/apache/struts/util Tag:
STRUTS_1_0_BRANCH
RequestUtils.java
Log:
Generate amp; instead of in request URIs so that the
output is still
legal XML syntax in the value returned by computeURL().
PR: Bugzilla #1938
Submitted by : Alessandro Vernet [EMAIL PROTECTED]
(also supplied
the patch - thanks!)
Revision ChangesPath
No revision
No revision
1.14.2.2 +7 -7
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Requ
estUtils.java,v
retrieving revision 1.14.2.1
retrieving revision 1.14.2.2
diff -u -r1.14.2.1 -r1.14.2.2
--- RequestUtils.java 2001/06/01 18:45:03 1.14.2.1
+++ RequestUtils.java 2001/06/01 20:21:40 1.14.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Requ
estUtils.java,v 1.14.2.1 2001/06/01 18:45:03 craigmcc Exp $
- * $Revision: 1.14.2.1 $
- * $Date: 2001/06/01 18:45:03 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/Requ
estUtils.java,v 1.14.2.2 2001/06/01 20:21:40 craigmcc Exp $
+ * $Revision: 1.14.2.2 $
+ * $Date: 2001/06/01 20:21:40 $
*
*
*
@@ -95,7 +95,7 @@
* in the Struts controller framework.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.14.2.1 $ $Date: 2001/06/01 18:45:03 $
+ * @version $Revision: 1.14.2.2 $ $Date: 2001/06/01 20:21:40 $
*/
public class RequestUtils {
@@ -364,7 +364,7 @@
url.append('?');
question = true;
} else
-url.append('');
+url.append(amp;);
url.append(URLEncoder.encode(key));
url.append('='); // Interpret null as
no value
} else if (value instanceof String) {
@@ -372,7 +372,7 @@
url.append('?');
question = true;
} else
-url.append('');
+url.append(amp;);
url.append(URLEncoder.encode(key));
url.append('=');
url.append(URLEncoder.encode((String) value));
@@ -383,7 +383,7 @@
url.append('?');
question = true;
} else
-url.append('');
+url.append(amp;);
url.append(URLEncoder.encode(key));
url.append('=');
url.append(URLEncoder.encode(values[i]));
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util R equestUtils.java
You are unwrapping the request from the MultipartRequestWrapper object
before calling processActionForward() but don't you need to unwrap it before
calling processValidate(), processForward(), and processInclude()? All of
these may forward the wrapped request object, which won't work. Am I missing
something?
protected void process(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
String contentType = request.getContentType();
String method = request.getMethod();
//if this is a multipart request, wrap the HttpServletRequest object
//with a MultipartRequestWrapper to keep the process sub-methods
//from failing when checking for certain request parameters
//for command tokens and cancel button detection
if ((contentType != null)
(contentType.startsWith(multipart/form-data))
(method.equals(POST))) {
request = new MultipartRequestWrapper(request);
}
// Identify the path component we will use to select a mapping
String path = processPath(request);
if (path == null) {
if (debug = 1)
log( No path available for request URI +
request.getRequestURI());
response.sendError(HttpServletResponse.SC_BAD_REQUEST,
internal.getMessage(processPath));
return;
}
if (debug = 1)
log(Processing a + request.getMethod() + for + path);
// Automatically select a locale for this user if requested
processLocale(request);
// Set the content type and no-caching headers if requested
processContent(response);
processNoCache(response);
// General purpose preprocessing hook
if (!processPreprocess(request, response))
return;
// Look up the corresponding mapping
ActionMapping mapping = processMapping(path, request);
if (mapping == null) {
if (debug = 1)
log( No mapping available for path + path);
response.sendError(HttpServletResponse.SC_BAD_REQUEST,
internal.getMessage(processInvalid, path));
return;
}
// Process any ActionForm bean related to this request
ActionForm formInstance = processActionForm(mapping, request);
processPopulate(formInstance, mapping, request);
if (!processValidate(mapping, formInstance, request, response))
return;
// Execute a forward if specified by this mapping
if (!processForward(mapping, request, response))
return;
// Execute an include if specified by this mapping
if (!processInclude(mapping, request, response))
return;
// Acquire the Action instance to process this request
Action actionInstance = processActionCreate(mapping, request);
if (actionInstance == null) {
response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
internal.getMessage(actionCreate,
mapping.getPath()));
return;
}
// Call the Action instance itself
ActionForward forward =
processActionPerform(actionInstance, mapping, formInstance,
request, response);
//set the request back to it's normal state if it's currently
wrapped,
//to avoid ClassCastExceptions from ServletContainers if forwarding
if (request instanceof MultipartRequestWrapper) {
request = ((MultipartRequestWrapper) request).getRequest();
}
// Process the returned ActionForward (if any)
processActionForward(forward, mapping, formInstance,
request, response);
}
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 16, 2001 1:46 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/util
R equestUtils.java
Hal,
I'm a little confused, being as I've never seen the components code.
First,
the request is only wrapped for multipart forms. Second, by the time
processForward() is called, it is passed the original request, and not
the
wrapped one. What am I missing?
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 15, 2001 5:21 PM
To: [EMAIL PROTECTED]
Cc: 'Cedric Dumoulin'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/util
RequestUtils.java
What's the plan regarding forwarding the orignal request
instead of the
wrapped request? Form submissions don't work in the current Struts
build, at
least not on Weblogic 6.0. If ActionServlet is changed to unwrap the
request
before
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
What's the plan regarding forwarding the orignal request instead of the wrapped request? Form submissions don't work in the current Struts build, at least not on Weblogic 6.0. If ActionServlet is changed to unwrap the request before fowarding, Cedric Dumoulin will need to change his Components code because he has to copy the processForward() method in his class that inherits from ActionServlet. But then his components framework will only work with the latest struts builds Error from weblogic when it tries to dispatch to target using wrapped request: java.lang.ClassCastException: org.apache.struts.upload.MultipartRequestWrapper at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImp l.java:112) at s1.struts.component.ActionComponentServlet.processForward(ActionComponentSer vlet.java:198) at s1.struts.component.ActionComponentServlet.processValidate(ActionComponentSe rvlet.java:158) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1553) at com.tallan.odtos.web.servlet.AppActionServlet.process Hal -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 7:28 PM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java On Fri, 11 May 2001, Martin Cooper wrote: At 03:44 PM 5/11/01, Craig R. McClanahan wrote: On 11 May 2001 [EMAIL PROTECTED] wrote: mschachter01/05/11 15:33:38 Modified:src/share/org/apache/struts/action Action.java ActionServlet.java src/share/org/apache/struts/upload DiskMultipartRequestHandler.java src/share/org/apache/struts/util RequestUtils.java Added: src/share/org/apache/struts/upload MultipartRequestWrapper.java Log: - Added the MultipartRequestWrapper class, which is a class that implements HttpServletRequest and wraps a normal request. All normal HttpServletRequest methods will be called to the underlying request, except for methods involving parameters, which were over-ridden to provide a transparent way of accessing multipart elements. The version of the HttpServletRequest is Servlet 2.2, however the new methods from Servlet 2.3 are also included in this class with empty implementations so that Struts will build against the servlet 2.2 and 2.3 jars One thing to remember in 2.2 is that you cannot pass your wrapped request object to a RequestDispatcher.forward() or RequestDispatcher.include() call. In Tomcat 3.x, for example, you'd get a ClassCastException error if you tried to use this in an RD call. You mean if I have an Action that is invoked via POST with a file upload, and I try to forward from there using mapping.findForward(nextAction), where the forward has redirect=false, this will fail? This would be very bad - in every case where we have a file upload, we subsequently forward to another action. As long as you forward the *original* request object (and not the wrapper), you're fine. I'm fighting some security fires on Tomcat so I haven't had time to look deeply into what Michael is changing, but wanted to raise the flag in case some assumptions about this were being made incorrectly. Craig -- Martin Cooper Craig
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java ActionForm.java
The developer should call isCancelled() but the check for the cancel tag in
the request also exists in ActionServlet:
protected boolean processValidate(ActionMapping mapping,
ActionForm formInstance, HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// Was this submit cancelled?
if ((request.getParameter(Constants.CANCEL_PROPERTY) != null) ||
(request.getParameter(Constants.CANCEL_PROPERTY_X) != null)) {
if (debug = 1)
log( Cancelled transaction, no validation);
return (true);
}
That check is done in order to avoid calling the validate function on the
form if the cancel button was pressed. The action class perform method is
then called and it is up to the developer to call isCancelled and return the
appropriate forward.
Hal
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:29 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Hal,
It was my understanding that since isCancelled is a protected
method in the
Action class,
that it was the Action developer's job to call the method.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Doesn't the Struts framework need to call this new method
somewhere? The
application code can't call the isCancelled method because
the Action class
code will never be called. If Struts ActionServlet calls the
form validate
when a user clicked cancel, the validation will likely fail
and the user
will be presented with the input form again. Clicking cancel
needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/action
Action.java ActionForm.java
mschachter01/05/11 10:11:06
Modified:doc todo-1.1.xml
src/share/org/apache/struts/action Action.java
ActionForm.java
Log:
- Add an isCancelled() method to the Action class that takes a
MultipartRequestHandler as an argument. This should address
issues with the html:cancel tag, as long as the new isCancelled
method is called on for multipart forms.
- Add myself to the EJB Design Pattern TODO
Revision ChangesPath
1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
Index: todo-1.1.xml
===
RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- todo-1.1.xml 2001/04/12 16:00:42 1.2
+++ todo-1.1.xml 2001/05/11 17:10:47 1.3
@@ -159,6 +159,9 @@
assigned
a href=mailto:[EMAIL PROTECTED];Nic Hobbs/a
/assigned
+ assigned
+a href=mailto:[EMAIL PROTECTED];Mike Schachter/a
+ /assigned
/task
task name=HTML No-Cache Support
1.20 +27 -4
jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- Action.java 2001/02/23 21:13:09 1.19
+++ Action.java 2001/05/11 17:10:55 1.20
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v 1.19 2001/02/23 21:13:09 craigmcc Exp $
- * $Revision: 1.19 $
- * $Date: 2001/02/23 21:13:09 $
+ * $Header:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/Ac
tion.java,v 1.20 2001/05/11 17:10:55 mschachter Exp $
+ * $Revision: 1.20 $
+ * $Date: 2001/05/11 17:10:55 $
*
*
*
@@ -67,6 +67,7 @@
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Locale;
+import java.util.Hashtable;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
@@ -75,6 +76,7 @@
import javax.servlet.http.HttpSession;
import org.apache.struts.taglib.html.Constants;
import
RE: RE-2: cvs commit: jakarta-struts/src/share/org/apache/struts/acti on Action.java ActionForm.java
I thought of that too but I don't know how to add parameters to the request.
Maybe you could use request.setAttribute and store the multi-part request
String parameters as attributes in the requet object. Then code that looks
for parameters could be changed to a method that looks for parameters or
attributes. I don't know if that would help matters much.
I use something similar in my application so that I can have an action that
is accessed from a link or from another action. In one case the paramters
are passed on the url and in the other case parameters are passed as request
attributes. The receiving action calls a method that checks for one and then
the other, using the first one it finds.
protected String findStringParameter(HttpServletRequest request, String
key)
{
String value = request.getParameter(key);
if (value == null)
{
value = (String) request.getAttribute(key);
}
return value;
}
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 2:19 PM
To: '[EMAIL PROTECTED]'
Subject: RE-2: cvs commit:
jakarta-struts/src/share/org/apache/struts/acti on Action.java
ActionForm.java
On second thought, I'm going to toy around with putting the request
parameters
directly into the request from MultipartRequestHandler
instead of using
MultipartRequestHandler itself to store attributes. If I can
get it to work
this will solve all
the problems without adding any new methods to anything, or changing
anything.
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2)
Sent: Friday, May 11, 2001 2:08 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Is this an acceptable resolution to this problem for
everybody? If so, I'll
go ahead and fix the token problem in the Action class, be
creating new
isTokenValid() method that takes an HttpServletRequest and a
MultipartRequestHandler
as arguments, when using it for multipart forms. The other
token methods
don't
need to be changed, as they only deal with retrieiving
session information.
-Original Message-
From: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:29 PM
To: '[EMAIL PROTECTED]'
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Hal,
It was my understanding that since isCancelled is a protected
method in the
Action class,
that it was the Action developer's job to call the method.
-Original Message-
From: Deadman, Hal [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:24 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action Action.java
ActionForm.java
Doesn't the Struts framework need to call this new method
somewhere? The
application code can't call the isCancelled method because
the Action class
code will never be called. If Struts ActionServlet calls the
form validate
when a user clicked cancel, the validation will likely fail
and the user
will be presented with the input form again. Clicking cancel
needs to bypass
the call to the form validate method. If that is done then the new
isCancelled method may be used in the perform method.
Hal
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 11, 2001 1:11 PM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/action
Action.java ActionForm.java
mschachter01/05/11 10:11:06
Modified:doc todo-1.1.xml
src/share/org/apache/struts/action Action.java
ActionForm.java
Log:
- Add an isCancelled() method to the Action class that takes a
MultipartRequestHandler as an argument. This should address
issues with the html:cancel tag, as long as the new isCancelled
method is called on for multipart forms.
- Add myself to the EJB Design Pattern TODO
Revision ChangesPath
1.3 +3 -0 jakarta-struts/doc/todo-1.1.xml
Index: todo-1.1.xml
===
RCS file: /home/cvs/jakarta-struts/doc/todo-1.1.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- todo-1.1.xml 2001/04/12 16:00:42 1.2
+++ todo-1.1.xml 2001/05/11 17:10:47 1.3
@@ -159,6 +159,9 @@
assigned
a href=mailto:[EMAIL PROTECTED];Nic Hobbs/a
/assigned
+ assigned
+a href=mailto:[EMAIL PROTECTED];Mike Schachter/a
+ /assigned
/task
task name=HTML No-Cache Support
1.20 +27 -4
jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
RE: PropertyUtils.java
I would recommend submitting your fix as a bug report on bugzilla.
http://nagoya.apache.org/bugzilla/
It's much more likely to get dealt with if you submit it there.
Hal
-Original Message-
From: Rashid Desai [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 03, 2001 3:05 PM
To: [EMAIL PROTECTED]
Subject: PropertyUtils.java
I have found out that the method getAccessibleMethod(Method
method) in
PropertyUtils.java does not return the method as acessible
public method of
the class if the class implements an interface which inherits
from other
interfaces.
e.g. com.sun.xml.CommentNode implements org.w3c.dom.Comment
Interface which
implements org.w3c.dom.Node and org.w3c.dom.CharacterData Interfaces.
The method getNodeName is a get (Read) Property of the Node
Interface.
Looking for that property/method returns null in the current
implementation.
I have modified the getAccessibleMethod() which uses the
added new private
method called getAccessibleMethodFromInterfaceNest(..) which
recursively
searches for the method through the interface heirarchy.
I Would appreciate any feedback and hope that this change can be
incorporated into the core.
Rashid Desai
/**
* Return an accessible method (that is, one that can be invoked via
* reflection) that implements the specified Method. If no such method
* can be found, return null.
*
* @param method The method that we wish to call
*/
private static Method getAccessibleMethod(Method method) {
// Make sure we have a method to check
if (method == null) {
return (null);
}
// If the requested method is not public we cannot call it
if (!Modifier.isPublic(method.getModifiers())) {
return (null);
}
// If the declaring class is public, we are done
Class clazz = method.getDeclaringClass();
if (Modifier.isPublic(clazz.getModifiers())) {
return (method);
}
// Check the implemented interfaces
String methodName = method.getName();
Class[] parameterTypes = method.getParameterTypes();
//nest through interface heirarchy looking for the method
method =
getAccessibleMethodFromInterfaceNest(clazz,methodName,parameterTypes);
return (method);
}
/**
* Return an accessible method (that is, one that can be invoked via
* reflection) by nesting from parent interface through
Inherited interfaces
* to look for the interface that implements the specific Method.
* If no such method can be found, return null.
*
*@param parentInterfaceClass The parent Interface from which
we nest through
looking for accessible method
*@param method The method that we wish to call
*/
private static Method getAccessibleMethodFromInterfaceNest(Class
parentInterfaceClass, String methodName, Class[] parameterTypes)
{
Method method=null;
// Check the implemented interfaces
Class[] interfaces = parentInterfaceClass.getInterfaces();
for (int i = 0; i interfaces.length; i++) {
// Is this interface public?
if (!Modifier.isPublic(interfaces[i].getModifiers())) {
continue;
}
// Does the method exist on this interface?
try {
method = interfaces[i].getDeclaredMethod(methodName,
parameterTypes);
} catch (NoSuchMethodException e) {
//try recursively looking for the method
method =
getAccessibleMethodFromInterfaceNest(interfaces[i],methodName,
parameterTypes);
}
}
// Return whatever we have null or a good method
return (method);
}
_
Get your FREE download of MSN Explorer at http://explorer.msn.com
RE: struts-config_1_0.dtd location when not connected to internet
It's important the public identifier part of the DOCTYPE matches the one used when registering the local dtd. The part in quotes after PUBLIC and before the URL is used when registering the local DTD. !DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd" -Original Message- From: Cook, Levi [mailto:[EMAIL PROTECTED]] Sent: Friday, March 30, 2001 12:23 PM To: '[EMAIL PROTECTED]' Subject: RE: struts-config_1_0.dtd location when not connected to internet Does using the local DTD require the DOCTYPE declaration to be modified?? Thanks in advance, Levi Cook -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, March 30, 2001 11:19 AM To: Struts-Dev@Jakarta. Apache. Org (E-mail) Subject: Re: struts-config_1_0.dtd location when not connected to internet On Fri, 30 Mar 2001, Young, Wayne wrote: I'm trying to run my struts application disconnected from the internet. When I try to start Tomcat 3.2 in JBuilder4, it is unable to find the struts-config_1_0.dtd in the location below and won't load the action servlet. (as expected) !DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd" Struts registers a local copy of the DTD for this (and for the web.xml DTDs as well) at a path that should be in the struts.jar file: /org/apache/struts/resources/struts-config_1_0.dtd which is then accessed via this.getClass().getResource(). If there is something wierd about the classloader inside JBuilder4, it might have problems with this -- I've successfully run Struts in detached mode on Tomcat 3.2 stand alone. Craig
digester parse error handling
I was surprised to see that the Digester ignores parsing errors by
overriding fatalError(), error() and warning() and just logging the parse
exception without re-throwing it. The default behavior for the HandlerBase
fatalError() method is to re-throw the exception so it seems like Digester
should re-throw it after it logs it. At first I thought extending Digester
would allow me to work around this problem but Digester is declared to be
final. Is there any way to know that a parsing error occurred after calling
Digester.parse()? I think the Digester should re-throw exceptions in at
least fatalError() and it should not be a final class. Let me know if I am
missing something.
public void fatalError(SAXParseException exception) throws SAXException
{
log("Parse Fatal Error at line " + exception.getLineNumber() +
" column " + exception.getColumnNumber() + ": " +
exception.getMessage(), exception);
}
Thanks,
Hal
