Any Known Bugs?
I'm wondering with the issues that module users are having, if using modules or not, the 1.1bx releases require you to strictly bind the ActionServlet to *.do Many thanks to everyone, Jacob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any Known Bugs?
the 1.1bx releases require you to strictly bind the ActionServlet to *.do 1.1 requires you to use *extension* mapping not *.do mapping. You could probably map the servlet to *.aspx ;-) David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to send bugs/fixes (RequiredIf Equals Condition)
Where should I send bugs or fixes with common validator. Specifically the
EQUAL condition in RequiredIf doesnt seem to do anything.
if (dependTest.equals(FIELD_TEST_EQUAL)) {
this_required = dependTestValue.equalsIgnoreCase(dependVal);
}
Making it so, actually does the comparison
if (dependTest.equals(FIELD_TEST_EQUAL)) {
this_required = dependTestValue.equalsIgnoreCase(dependVal);
String dependPropValue =
ValidatorUtil.getValueAsString(bean, dependProp);
if ( ! dependTestValue.equals( dependPropValue ) ){
return false;
}
}
Thanks,
Jeremy Weber
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Where to send bugs/fixes (RequiredIf Equals Condition)
Open a bug report for the issue and attach a patch file to it.
David
From: Weber, Jeremy [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' (E-mail) [EMAIL PROTECTED]
Subject: Where to send bugs/fixes (RequiredIf Equals Condition)
Date: Mon, 27 Jan 2003 09:21:17 -0500
Where should I send bugs or fixes with common validator. Specifically the
EQUAL condition in RequiredIf doesnt seem to do anything.
if (dependTest.equals(FIELD_TEST_EQUAL)) {
this_required =
dependTestValue.equalsIgnoreCase(dependVal);
}
Making it so, actually does the comparison
if (dependTest.equals(FIELD_TEST_EQUAL)) {
this_required = dependTestValue.equalsIgnoreCase(dependVal);
String dependPropValue =
ValidatorUtil.getValueAsString(bean, dependProp);
if ( ! dependTestValue.equals( dependPropValue ) ){
return false;
}
}
Thanks,
Jeremy Weber
[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Confused about nightly builds and 1.1b2 bugs
Sorry for the dumb question and another thread on nightly builds Do the nighlty builds reflect the up comming release candidate for 1.1 (or 1.1b3) or are they a separate branch for a future release. I am hearing about new functionality in the nightly builds. I would consider trying a 'stable nighlty' knowing that 1.1 final would have that same functionality. Thanks. -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: Confused about nightly builds and 1.1b2 bugs
We don't have any fancy branching (at this point) like Tomcat etc do (that I am aware of). The nightly builds reflect the current status of what will (eventually) be 1.1 final. [EMAIL PROTECTED] wrote: Sorry for the dumb question and another thread on nightly builds Do the nighlty builds reflect the up comming release candidate for 1.1 (or 1.1b3) or are they a separate branch for a future release. I am hearing about new functionality in the nightly builds. I would consider trying a 'stable nighlty' knowing that 1.1 final would have that same functionality. Thanks. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: Confused about nightly builds and 1.1b2 bugs
On Wed, 23 Oct 2002 [EMAIL PROTECTED] wrote: Date: Wed, 23 Oct 2002 12:12:39 -0500 From: [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Confused about nightly builds and 1.1b2 bugs Sorry for the dumb question and another thread on nightly builds Do the nighlty builds reflect the up comming release candidate for 1.1 (or 1.1b3) or are they a separate branch for a future release. The nightly builds are run from the HEAD branch of the sources, which will ultimately be the source for the real 1.1 release. When bugs are closed as FIXED in Bugzilla, you'll often see comments like fixed in nightly build 20021024, which would mean that any nightly build from October 24 on would include the fix, as well as the upcoming release. I am hearing about new functionality in the nightly builds. I would consider trying a 'stable nighlty' knowing that 1.1 final would have that same functionality. There's not really such a thing as a stable nightly -- but nightlies, any future betas or release candidates, and the final 1.1 release are all built from the same branch (currently the HEAD). At some future point, the 1.1 code really will be branched, so that the HEAD can be used for 1.2/2.0/whatever stuff. Until then, the nightly builds reflect the latest and greatest 1.1 code. Thanks. Craig -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: Confused about nightly builds and 1.1b2 bugs
Thank you. That is what I wanted to hear. What would be the recommendation for the latest 'stable' build. I know this is based on the experience of those who tried the builds, but any opinions would be helpful. Thanks again Eddie Bush [EMAIL PROTECTED] on 10/23/2002 12:20:45 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:Struts Users Mailing List [EMAIL PROTECTED] cc: Subject:Re: Confused about nightly builds and 1.1b2 bugs We don't have any fancy branching (at this point) like Tomcat etc do (that I am aware of). The nightly builds reflect the current status of what will (eventually) be 1.1 final. [EMAIL PROTECTED] wrote: Sorry for the dumb question and another thread on nightly builds Do the nighlty builds reflect the up comming release candidate for 1.1 (or 1.1b3) or are they a separate branch for a future release. I am hearing about new functionality in the nightly builds. I would consider trying a 'stable nighlty' knowing that 1.1 final would have that same functionality. Thanks. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: Confused about nightly builds and 1.1b2 bugs
I haven't followed the issues being fixed too much. I just know that we updated to 20021022 and now I don't have billions(exaggeration) of tiles print statements in my log files. It's in production now and as far as I know functions the same as 1.1b2 did. -Dennis On Wed, 2002-10-23 at 11:23, [EMAIL PROTECTED] wrote: Thank you. That is what I wanted to hear. What would be the recommendation for the latest 'stable' build. I know this is based on the experience of those who tried the builds, but any opinions would be helpful. Thanks again Eddie Bush [EMAIL PROTECTED] on 10/23/2002 12:20:45 PM Please respond to Struts Users Mailing List [EMAIL PROTECTED] To:Struts Users Mailing List [EMAIL PROTECTED] cc: Subject:Re: Confused about nightly builds and 1.1b2 bugs We don't have any fancy branching (at this point) like Tomcat etc do (that I am aware of). The nightly builds reflect the current status of what will (eventually) be 1.1 final. [EMAIL PROTECTED] wrote: Sorry for the dumb question and another thread on nightly builds Do the nighlty builds reflect the up comming release candidate for 1.1 (or 1.1b3) or are they a separate branch for a future release. I am hearing about new functionality in the nightly builds. I would consider trying a 'stable nighlty' knowing that 1.1 final would have that same functionality. Thanks. -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
[BUGS] Is this list current?
http://jakarta.apache.org/struts/proposals/release-plan-1.1b2.html Just curious. I was browsing for something I might be able to fix. Seeing the one about the blank date (which I think has had a patch submitted) made me wonder which ones were outstanding. Does that list get updated often? What process should one go through to determine precisely what all the open issues are? I'm not terribly familiar with Bugzilla :-( Regards, Eddie -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Beta 1 bugs in struts-exercise-taglib examples
There are two possible bugs related to the exampe pages index.jsp and
html-link.jsp
in the struts-exercise-taglib in struts beta 1 release.
The first one appeard in 04/03 nightly build. When clicking the link in the
index.jsp
that is pointing to the html-link.jsp, an exception is thrown for a reason
message resources not found under key org.apache.struts.action.MESSAG.
A quick fix I think is to change the BaseHandlerTag.message(String literal,
String key).
When both literal and key are null, this method should return null. Right
now it will
go ahead to invoke RequestUtils method and throw exception there.
The second bug appeared since 03/19, the formal b1 release. When clicking
the
'Cancel' button on the html-link.jsp, an exception is thrown for 'array
element type mismatch'
in PropertyUtils.setIndexedProperty(...).
The exception is thrown because the TestBean has no indexed method for
stringArray
while the PropertyUtils is invoking setIndexedProperty when it sees the
stringArray[0]
as the property name. A quick fix I could think right now is to change the
BeanUtils.populate
method around the section '// Conver the parameter value as required for
this setter method'
Origianl section:
if(parameterTypes.length 1)
parameterType = parameterTypes[1]; // Indexed or mapped setter
Change to:
if(parameterTypes.length 1) {
parameterType = parameterTypes[1]; // Indexed or mapped setter
} else {
int nestedDel = name.lastIndexOf(PropertyUtils.NESTED_DELIM);
int indexedDel = name.lastIndexOf(PropertyUtils.INDEXED_DELIM);
if(indexedDel nestedDel) {
// PropertyUtils will invoke setIndexedProperty later, but
actually the method is not indexed
if(parameterType.isArray()) {
parameterType = parameterType.getComponentType();
}
}
}
The way of the fix is not optimized, it just fixes the problem shown in the
html-link.jsp.
I just started to look at the beta 1 codes and may overlooked other aspects
of the overall architecture.
Let me know if anyone finds the same exceptions or they are addressed
somehow in another way.
Thanks,
Jing
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Last Call for Struts 1.0 Bugs
I don't know if this qualifies as a bug or a feature proposal. I am using Structs as a framework to a sample application that generates a report. The application has two kinds of users (regular and superuser), who must set certain parameters before doing POST to /report.do The problem is that regular users go directly to /report.do (via GET) and "print" must be "=screen" for them, which is achieved by setting the property of the form bean to "screen" in form's reset() method. On the other hand, superusers go to report from a JSP page (via POST), where they select the parameter value like this: html:form name="reportForm" method="POST" action="/report.do" html:radio name="print" value="printer"/ Printer-friendly html:radio name="print" value="screen"/ Screen-friendly input type="submit" /html:form Since the form doesn't exist when JSP is called, it's created with print=screen, and superuser see the second radio-button checked, where is the business requirement is that the first is selected by default. Unfortunately, html:radio does not allow overriding form's default settings. It would be nice to do something like this: html:form name="reportForm" method="POST" action="/report.do" html:radio name="print" value="printer" checked="true"/ Printer-friendly html:radio name="print" value="screen"/ Screen-friendly input type="submit" /html:form which takes precedence over default values from reset() method if the form didn't exist in the first place. It seems like a simple thing to do, but I don't know if this can make its way to Struts 1.0 Also, it would be correct to have a method in the ActionForm inteface that indicates to the action class whether the form properties were populated from the request or they were set to default values by the form's reset() method (something like HttpSession.isNew() ). YS. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, February 12, 2001 5:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Last Call for Struts 1.0 Bugs The few remaining Struts bug reports are feeling kind of lonely. Do you have any more bugs that you would like to see fixed before Struts 1.0 is released? If so, please post them to the bug tracking system at: http://nagoya.apache.org/bugzilla/ under product "Struts". Even if the bug has been reported to a Struts mailing list, this is the best way to ensure that your bug does not get missed in the final rush towards release. Feature requests are welcome as well, of course, but the focus right at the moment is on identifying and squashing any remaining bugs so that 1.0 comes out of the box as an extremely solid platform for building web applications. Craig McClanahan
Last Call for Struts 1.0 Bugs
The few remaining Struts bug reports are feeling kind of lonely. Do you have any more bugs that you would like to see fixed before Struts 1.0 is released? If so, please post them to the bug tracking system at: http://nagoya.apache.org/bugzilla/ under product "Struts". Even if the bug has been reported to a Struts mailing list, this is the best way to ensure that your bug does not get missed in the final rush towards release. Feature requests are welcome as well, of course, but the focus right at the moment is on identifying and squashing any remaining bugs so that 1.0 comes out of the box as an extremely solid platform for building web applications. Craig McClanahan
Are this bugs ?
Hello, I've noticed the following behaviour: declaring an Action like: actionpath="/logon" type="action.LogonAction" name="logonForm" input="/Logon.html" scope="request" validate="true" forward name="success" path="/showShops.do" / /action I'm getting a servlet exception and as a result the Logon.html file is overwritten (the file itself is still there but the content is gone). If I specify (instead of the extension .html) "/Logon.jsp" it works as expected. Just wondering: In the code of ActionServlet I've noticed that the access to the actions member in the method processActionCreate (in the try - block) is not synchronized. FM
Re: Are this bugs ?
"Mueller, Franz" wrote: Hello, I've noticed the following behaviour: declaring an Action like: actionpath="/logon" type="action.LogonAction" name="logonForm" input="/Logon.html" scope="request" validate="true" forward name="success" path="/showShops.do" / /action I'm getting a servlet exception and as a result the Logon.html file is overwritten (the file itself is still there but the content is gone). If I specify (instead of the extension .html) "/Logon.jsp" it works as expected. What servlet container (aned version) are you using? It may be that there are problems doing a RequestDispatcher.forward() to a static resource. Could you also post the stack trace that you get? Just wondering: In the code of ActionServlet I've noticed that the access to the actions member in the method processActionCreate (in the try - block) is not synchronized. Currently, "actions" is implemented as a Hashtable, which guarantees thread safe behavior for you without having to synchronize at the application level. This would be safe even if a HashMap were used, as long as no thread was modifying the underlying collection while the ActionServlet was running. FM Craig
Re[2]: Are this bugs ?
Just wondering: In the code of ActionServlet I've noticed that the access to the actions member in the method processActionCreate (in the try - block) is not synchronized. Currently, "actions" is implemented as a Hashtable, which guarantees thread safe behavior for you without having to synchronize at the application level. Craig, this is not generally correct. I've posted some thoughts on actions, thread safety, and the map a few weeks ago to STRUTS_DEV. I had the impression that you did acknowledge in your answer, that there are (many) potential problems with the thread safety of ActionMappings, _even if_ a HashTable is used. So... This would be safe even if a HashMap were used, as long as no thread was modifying the underlying collection while the ActionServlet was running. ... you probably meant Actions are safe, as long as no two threads do concurrently modify the underlying collection while the ActionServlet is running. -- Matthias(mailto:[EMAIL PROTECTED])
RE: Are this bugs ?
Hello, I'm using tomcat4/milestone 4 (Struts nightly build from 06-Dec) the exception I'm getting: A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Servlet.service() for servlet default threw exception at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:537) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher .java:292) at org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:17 69) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1321) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:447) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:517) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher .java:292) at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.ja va:1468) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1334) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:447) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:180) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:255) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:165) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:1876) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:343) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 785) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:902) at java.lang.Thread.run(Thread.java:484) Root Cause: java.lang.NullPointerException at org.apache.catalina.resources.FileResources.setResource(FileResources.java:5 86) at org.apache.catalina.servlets.DefaultServlet.doPut(DefaultServlet.java:401) at org.apache.catalina.servlets.DefaultServlet.doPost(DefaultServlet.java:365) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:517) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher .java:292) at org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:17 69) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1321) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:447) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:517) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher .java:292) at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.ja va:1468) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1334) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:447) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:180) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:255) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:165) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:1876) at
