DO NOT REPLY [Bug 26822] New: - Html tags do not support autocomplete attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26822. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26822 Html tags do not support autocomplete attribute Summary: Html tags do not support autocomplete attribute Product: Struts Version: 1.1 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] There is a autocomplete attribute in html form and other controls to allow the browser to use autocomplete feature. The normal way to turn this feature on and off is through the autocomplete attibute in the form tags (and other form controls). However, the HTML taglib does not provide this functionality. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26822] - Html tags do not support autocomplete attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26822. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26822 Html tags do not support autocomplete attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-10 10:46 --- See discussions on dev related to this topic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788 HTML-EL Frame tag does not process marginheight and marginwidth correctly --- Additional Comments From [EMAIL PROTECTED] 2004-02-10 11:13 --- Hello again Joe, Seems my last comments were not entirely true because the html:frame DOES omit the MARGINHEIGHT and MARGINWIDTH arguments from the rendered HTML in the same way that html-el:frame does. Anyway, I've done as you've requested and extracted the source (JSP) and resultant code (HTML) from the original and working version of my particular tasks and then the source and resultant code of the failing situation that makes use of the html:frame tag. These scriptlets are shown below. I can experiment using the c:url as I am using JSTL quite heavily... but I would still prefer to use the html:frame tag which I think is more suited to my application (unless you can confirm for me that all html:frame does it to rewrite the URL for the purpose of retaining session state). Thanks for your help anyway Joe. Much appreciated. Regards, Andrew. JSP source (frameset using regular HTML frame tags): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 frame name=leftFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 frame name=headerFrame src=header.jsp marginwidth=0 marginheight=0 scrolling=no frame name=mainFrame src=controller.jsp?action=setup_main marginwidth=0 marginheight=0 scrolling=no frame name=bottomFrame src=border.jsp?border=bottom marginwidth=0 marginheight=0 scrolling=no /frameset frame name=rightFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no noframesYour browser does not support frames./noframes /frameset Results in (with MARGINWIDTH and MARGINHEIGHT attributes being rendered): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 frame name=leftFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 frame name=headerFrame src=header.jsp marginwidth=0 marginheight=0 scrolling=no frame name=mainFrame src=controller.jsp?action=setup_main marginwidth=0 marginheight=0 scrolling=no frame name=bottomFrame src=border.jsp?border=bottom marginwidth=0 marginheight=0 scrolling=no /frameset frame name=rightFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no noframesYour browser does not support frames./noframes /frameset JSP source (frameset now using Struts html:frame tags): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 html:frame frameName=leftFrame href=border.jsp marginwidth=0 marginheight= 0 scrolling=no/ frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 html:frame frameName=headerFrame href=header.jsp marginwidth=0 marginheight=0 scrolling=no/ html:frame frameName=mainFrame href=controller.jsp?action=setup_main marginwidth=0 marginheight=0 scrolling=no/ html:frame frameName=bottomFrame href=border.jsp?border=bottom marginwidth=0 marginheight=0 scrolling=no/ /frameset html:frame frameName=rightFrame href=border.jsp marginwidth=0 marginheight=0 scrolling=no/ noframesYour browser does not support frames./noframes /frameset Results in (with MARGINWIDTH and MARGINHEIGHT attributes being omitted): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 frame src=border.jsp name=leftFrame scrolling=no frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 frame src=header.jsp name=headerFrame scrolling=no frame src=controller.jsp?action=setup_main name=mainFrame scrolling=no frame src=border.jsp?border=bottom name=bottomFrame scrolling=no /frameset frame src=border.jsp name=rightFrame scrolling=no noframesYour browser does not support frames./noframes /frameset - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 26788] - HTML-EL Frame tag does not process marginheight and marginwidth correctly
A quick scan of the source shows, that marginwidth and marginheight are only rendered if they are 0, so in your case they are not rendered. I don't know if this is the correct behaviour, maybe the 0 should read = 0. Björn DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26788 HTML-EL Frame tag does not process marginheight and marginwidth correctly --- Additional Comments From [EMAIL PROTECTED] 2004-02-10 11:13 --- Hello again Joe, Seems my last comments were not entirely true because the html:frame DOES omit the MARGINHEIGHT and MARGINWIDTH arguments from the rendered HTML in the same way that html-el:frame does. Anyway, I've done as you've requested and extracted the source (JSP) and resultant code (HTML) from the original and working version of my particular tasks and then the source and resultant code of the failing situation that makes use of the html:frame tag. These scriptlets are shown below. I can experiment using the c:url as I am using JSTL quite heavily... but I would still prefer to use the html:frame tag which I think is more suited to my application (unless you can confirm for me that all html:frame does it to rewrite the URL for the purpose of retaining session state). Thanks for your help anyway Joe. Much appreciated. Regards, Andrew. JSP source (frameset using regular HTML frame tags): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 frame name=leftFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 frame name=headerFrame src=header.jsp marginwidth=0 marginheight=0 scrolling=no frame name=mainFrame src=controller.jsp?action=setup_main marginwidth=0 marginheight=0 scrolling=no frame name=bottomFrame src=border.jsp?border=bottom marginwidth=0 marginheight=0 scrolling=no /frameset frame name=rightFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no noframesYour browser does not support frames./noframes /frameset Results in (with MARGINWIDTH and MARGINHEIGHT attributes being rendered): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 frame name=leftFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 frame name=headerFrame src=header.jsp marginwidth=0 marginheight=0 scrolling=no frame name=mainFrame src=controller.jsp?action=setup_main marginwidth=0 marginheight=0 scrolling=no frame name=bottomFrame src=border.jsp?border=bottom marginwidth=0 marginheight=0 scrolling=no /frameset frame name=rightFrame src=border.jsp marginwidth=0 marginheight=0 scrolling=no noframesYour browser does not support frames./noframes /frameset JSP source (frameset now using Struts html:frame tags): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 html:frame frameName=leftFrame href=border.jsp marginwidth=0 marginheight= 0 scrolling=no/ frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 html:frame frameName=headerFrame href=header.jsp marginwidth=0 marginheight=0 scrolling=no/ html:frame frameName=mainFrame href=controller.jsp?action=setup_main marginwidth=0 marginheight=0 scrolling=no/ html:frame frameName=bottomFrame href=border.jsp?border=bottom marginwidth=0 marginheight=0 scrolling=no/ /frameset html:frame frameName=rightFrame href=border.jsp marginwidth=0 marginheight=0 scrolling=no/ noframesYour browser does not support frames./noframes /frameset Results in (with MARGINWIDTH and MARGINHEIGHT attributes being omitted): frameset class=default cols=18,*,18 framespacing=0 frameborder=0 border=0 frame src=border.jsp name=leftFrame scrolling=no frameset class=default rows=74,*,18 framespacing=0 frameborder=0 border= 0 frame src=header.jsp name=headerFrame scrolling=no frame src=controller.jsp?action=setup_main name=mainFrame scrolling=no frame src=border.jsp?border=bottom name=bottomFrame scrolling=no /frameset frame src=border.jsp name=rightFrame scrolling=no noframesYour browser does not support frames./noframes /frameset - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++
Mavenising struts-el
OK, so in order to fix bug # 26788, I had to go ahead and commit the changes I brought up earlier for struts-el regarding removing invalid imports. There are still several test classes that have all their test methods commented out -- if anyone has some spare time, it might be worth looking at those and trying to fix them up. Since I had done that, I went ahead and also committed the Maven POM file. I accidentally had a '-m' on my cvs commit so I wasn't able to specify this in the commit message: I set the version number at 1.2.0-dev with the intent that it be correlated with Struts version numbers. If anyone has stronger feelings or better experience than I do with assigning version numbers, feel free to advise, but part of me likes the idea of keeping the contrib version numbers tracking Struts version numbers. Not all of the tests pass when maven test is run, but I suspect that may be related to the apparently incomplete state of the tests -- when I run 'ant test.junit', there are apparently no tests. Are there only cactus tests in there? I haven't looked at maven/cactus for struts-el and don't know when I'll be able to. Just wanted to update folks, mostly because I biffed the commit message... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
deprecate org.apache.struts.taglib.html.ErrorsTag?
There's been quite a bit of confusion on the struts-user list this week about the relationships between ActionErrors, ActionMessages, html:errors, and html:messages. Is there any reason not to deprecate org.apache.struts.taglib.html.ErrorsTag and slate it for future removal, to remove one more piece from the puzzle? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser-specific attrs for html tags (was: [Bug 26795])
-Original Message- From: Karr, David [mailto:[EMAIL PROTECTED] I've always been sympathetic to the goal of enforcing the HTML standard, particularly for internet applications, as opposed to intranet applications. However, when it comes to supporting intranet applications, a more effective approach might be the pragmatic one. I always felt there should be a html-ex tag library at the sourcefourge struts site. It would be argument compatable with the struts html except that it would offer the additional attributes needed. -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deprecate org.apache.struts.taglib.html.ErrorsTag?
Is there any reason not to deprecate org.apache.struts.taglib.html.ErrorsTag and slate it for future removal, to remove one more piece from the puzzle? Joe +1 Once Message Resources is out of the sandbox I believe we can complete the moving over to Messages, by changing method signatures from to ActionMessages as opposed to ActionErrors. We'll need to create new methhods of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24235] - Secure html:link tag, plus module support.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235 Secure html:link tag, plus module support. --- Additional Comments From [EMAIL PROTECTED] 2004-02-10 18:06 --- Created an attachment (id=10299) Patch to examples that uses html:link with module= in the welcome.jsp. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: deprecate org.apache.struts.taglib.html.ErrorsTag?
--- Joe Germuska [EMAIL PROTECTED] wrote: There's been quite a bit of confusion on the struts-user list this week about the relationships between ActionErrors, ActionMessages, html:errors, and html:messages. Is there any reason not to deprecate org.apache.struts.taglib.html.ErrorsTag and slate it for future removal, to remove one more piece from the puzzle? The errors tag provides a way to display a message in one line instead of the 3 or more required by the messages tag. So, I'm -1 on deprecating errors but I do think we should come up with a way to get the best of both into one tag. David Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24235] - Secure html:link tag, plus module support.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235 Secure html:link tag, plus module support. --- Additional Comments From [EMAIL PROTECTED] 2004-02-10 18:29 --- I created a patch, which I just uploaded, that changes the index and welcome pages into jsps. I changed welcome.html to welcome.jsp and made the first 3 links into html:link tags with module= attributes. Using the latest head the welcome.jsp does create the correct links. I'd love to help more, but I need to do some digging to see where this examples app is headed, and I want to look into the MailReader app. Ted or others, let me know if there is any particular items that would help get 1.2 out the door. I have some time avaibable through this weekend. Otherwise I'll just poke around and see what I may be able to contribute. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mavenising struts-el
The cactus test cases I had written for struts-el are probably out of date, and were written before the attempt to clean up and enhance the existing cactus tests with new strategies. I haven't dedicated time to rework them yet, partially because I didn't see a huge need for it. I believe I had no pure Junit tests. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 10, 2004 8:50 AM To: Struts Developers List Subject: Mavenising struts-el OK, so in order to fix bug # 26788, I had to go ahead and commit the changes I brought up earlier for struts-el regarding removing invalid imports. There are still several test classes that have all their test methods commented out -- if anyone has some spare time, it might be worth looking at those and trying to fix them up. Since I had done that, I went ahead and also committed the Maven POM file. I accidentally had a '-m' on my cvs commit so I wasn't able to specify this in the commit message: I set the version number at 1.2.0-dev with the intent that it be correlated with Struts version numbers. If anyone has stronger feelings or better experience than I do with assigning version numbers, feel free to advise, but part of me likes the idea of keeping the contrib version numbers tracking Struts version numbers. Not all of the tests pass when maven test is run, but I suspect that may be related to the apparently incomplete state of the tests -- when I run 'ant test.junit', there are apparently no tests. Are there only cactus tests in there? I haven't looked at maven/cactus for struts-el and don't know when I'll be able to. Just wanted to update folks, mostly because I biffed the commit message... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24235] - Secure html:link tag, plus module support.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24235 Secure html:link tag, plus module support. --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:21 --- The additional patch was helpful. I had omitted the slash from the module names. For completeness, we would need to also support the page form of html:link, but it seems to be ignoring the module attribute. (See the examples/exercises html-link page.) In the hope that you have a chance to look at the page form, Gary, I'll start locking down the nightly build so that we can roll a 1.20 release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26845] New: - bean:define within a conditional scriplet produces Unable to compile class for JSP Error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26845.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26845
bean:define within a conditional scriplet produces Unable to compile class for JSP
Error
Summary: bean:define within a conditional scriplet produces
Unable to compile class for JSP Error
Product: Struts
Version: 1.1 Final
Platform: PC
OS/Version: Windows NT/2K
Status: UNCONFIRMED
Severity: Minor
Priority: Other
Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The development team I work with (most members are relatively new to JSP and
STRUTS) produced a JSP which contained a structure like the following:
% String PropertyName=request.getParameter(popup); %
% String popupType=request.getParameter(popupType); %
bean:define id=collectionCollection name=%=IWebConstants.MODEL_HANDLER%
property=collectionCollection scope=session toScope=page/
%if (popupType.equals(multi)) { %
bean:define id=collection name=collectionCollection
property=%=PropertyName% scope=page toScope=page/
html:select property=pageProperty name=pageForm multiple=true
size=10 onchange=FillBuffer()
html:options collection=collection property=value
labelProperty=key/
/html:select
%} else {%
bean:define id=collection name=collectionCollection
property=%=PropertyName% scope=page toScope=page/
html:select property=pageProperty name=pageForm size=10
onchange=FillBuffer() onclick=SubmitToForm()
html:options collection=collection property=value
labelProperty=key/
/html:select
%}%
The above is not very efficient, but was validated as syntactically correct
within the IDE. The JSP containing the above, when deployed in a WARfile, is
compiled correctly in Tomcat 4.0.x and BEA Weblogic 7.0SP2. However, when
deployed to Tomcat 4.1.27, 4.1.29 and 5.0.18 the JSP fails with the error
(paraphrased):
Unable to compile class for JSP.
test.jsp_jsp.java:xx: cannot resolve symbol
symbol: variable collection
etc.
Examing the test.jsp_jsp.java (generated by Tomcat in the work directory) showed
the if..else block constructed improperly. The if block contains a variable
declaration: java.lang.Object collection = null (from the bean:define) which is
used within it. The else block contains code that just tries to reference a
variable collection but does not declare it (which is where the cannot resolve
symbol arises).
The test was performed on Windows 2000 Professional, JDK 1.4.2_01 and 1.3.1_09
using Struts 1.1 Final (using Tomcat 4.0,4.1.27,4.1.29,5.0.18 and BEA Weblogic
7.0SP2). It was also independently executed on JDk 1.4.2_01 on another Windows
2000 device using Tomcat 4.1.27.
We are hoping to see if we can reproduce the error with a stripped-down version
of the JSP (since it contains more than the snippet where the error appears to
arise). It has been confirmed if the bean:define(s) within the if..else
scriplet block are replaced by a single instance outside of the scriplet the
page compiles correctly on all of the above containers. We are unsure if this
is a STRUTS tag issue or Tomcat issue at this point (or something else).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26322 WebLogic hot-deploy breaks Tiles; TilesRequestProcessor is not serializable [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:46 --- One resolution would be to add this as a ActionServlet subclass in the actions package as a RedeployableActionServlet. Teams experiencing this problem could then load this subclass instead. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26336] - Empty multipart form from Opera browser results in ServletException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26336. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26336 Empty multipart form from Opera browser results in ServletException [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:48 --- Marking RESOLVE LATER pending a course of action. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26403] - double UTF-8 encoding of HTTP request parameters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26403. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26403 double UTF-8 encoding of HTTP request parameters [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:50 --- Marking as RESOLVE LATER pending a course of action. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26413] - Indexed Field Date Validation Allows Invalid Dates
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26413. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26413 Indexed Field Date Validation Allows Invalid Dates [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:51 --- Marking as INVALID pending confirmation that the issue persists. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26447] - NoClassDefFoundError while using Custom Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26447. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26447 NoClassDefFoundError while using Custom Validator [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:51 --- Marking INVALID pending confirmation that the issue is not container- specific. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26592] - NullPointerException in RequestUtils in certain scenarios
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26592. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26592 NullPointerException in RequestUtils in certain scenarios [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:55 --- I'm attaching this to #25855, which is the open ticket regarding modules now, but I'm not convinced the report is valid. Applications that choose to use modules should not also be using direct links between pages. *** This bug has been marked as a duplicate of 25855 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25855] - ContextRelative/PagePattern issues
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25855. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25855 ContextRelative/PagePattern issues [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 03:55 --- *** Bug 26592 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26639] - Multipart request parameters lost after validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639 Multipart request parameters lost after validation failure [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Keywords||PatchAvailable Target Milestone|--- |1.2.1 Milestone --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:00 --- Marking this as an enhancement for 1.2.1. We should be switching to the command-based RequestProcessor soon, and we can consider this change in that context. We've been seeing a lot of issues specific to file uploading. Perhaps we need a specialized request processor catalog for applications that utilize file uploading. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26675] - [struts-chain] uploads greater than memory threshold don't get written to disk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26675. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26675 [struts-chain] uploads greater than memory threshold don't get written to disk [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Target Milestone|--- |1.2.1 Milestone Version|1.0 Final |Nightly Build --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:02 --- See also #26639. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26639] - Multipart request parameters lost after validation failure
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26639 Multipart request parameters lost after validation failure --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:03 --- See also #26675. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26736] - Hash # in HTML when taglibs are used causes double post to action
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26736. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26736 Hash # in HTML when taglibs are used causes double post to action [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID Summary|Hash # in HTML when |Hash # in HTML when |taglibs are used causes |taglibs are used causes |double post to action |double post to action --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:18 --- If a double submit is occuring, it would have to be a client issue. This does not seem like something that Struts could control or affect. Apparently, when some browsers try to retrieve the source for an image from an invalid local reference, a form submit elsewhere on the page may occur. But the browser has no idea that Struts or an Action is involved, so I imagine any form would be submitted. (Not just one involved with a Struts Action.) The page itself is rendered outside of Struts by the JSP engine, and form submits are the domain of the browser. I don't see that there is anything that Struts could do about this happenstance. I wasn't able to pull up the relevant RFCs, but I'd question whether # is even a valid URI and consequently an illegal value for a src attribute. If it were me, I'd use some type of Image not available image instance so that the src attribute has a valid reference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26761] - bean:define / issue.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26761. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26761 bean:define / issue. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:22 --- A better place to bring up issues for discussion is the Struts USER or DEV list. But, Struts does not compile pages. I believe the restriction cited might be enforced at runtime rather than at compile time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26803] - NullPointerException in RequestProcessor
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26803. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26803 NullPointerException in RequestProcessor [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Target Milestone|--- |1.2.2 Milestone --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:32 --- We can look at this in the context of redeploying the request processor as a Commons Chain implementation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26845] - bean:define within a conditional scriplet produces Unable to compile class for JSP Error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26845. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26845 bean:define within a conditional scriplet produces Unable to compile class for JSP Error [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 04:37 --- You might try to move the bean:define / outside of the scriplet code, so that there is no controversary over where the collection should be defined. The statement seems to be indentical in either case. A better place to bring up general questions like this is the Struts USER or DEV list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5739] - Struts fails silently in too many places
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5739.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5739
Struts fails silently in too many places
--- Additional Comments From [EMAIL PROTECTED] 2004-02-11 07:45 ---
Attached are the changed ActionServlet.java and XercesParser.java files. Below
is the diff that shows what was added to activate the schema validation:
--- ActionServlet.java.old 2004-01-10 13:03:38.0 -0800
+++ ActionServlet.java 2004-01-24 14:01:50.0 -0800
@@ -221,6 +221,11 @@
*/
protected String config = /WEB-INF/struts-config.xml;
+ /**
+ * pLocation of schema validation file for all struts-config.xml related
files/p
+*
+ */
+ protected String schemaLocation = /WEB-INF/struts-config-schema.xsd;
/**
* pThe Digester used to produce ModuleConfig objects from a
@@ -961,6 +966,13 @@
this.addRuleSets();
+ try {
+ URL schemaUrl = getServletContext().getResource
(schemaLocation);
+ configDigester.setSchema(schemaUrl.toExternalForm());
+ } catch (MalformedURLException mue) {
+handleConfigException(schemaLocation, mue);
+ }
+
// Return the completely configured Digester instance
return (configDigester);
}
The change to XercesParser.java which is in the nightly Commons Digester
packages is needed if you are using Xerces 2.2 or greater:
--- XercesParser.java.old 2004-02-09 03:39:14.0 -0800
+++ XercesParser.java 2004-01-24 15:40:47.0 -0800
@@ -172,12 +172,15 @@
versionNumber = getXercesVersion();
version = new Float( versionNumber ).floatValue();
}
-
// Note: 2.2 is completely broken (with XML Schema).
-if (version 2.1) {
+// Tested with Xerces 2.6. Looks ok
+if (version 2.2) {
configureXerces(factory);
-return factory.newSAXParser();
+ SAXParser newParser = factory.newSAXParser();
+ // Test 2.6 with schema validation
+ configureOldXerces(newParser, properties);
+return newParser;
} else {
SAXParser parser = factory.newSAXParser();
configureOldXerces(parser,properties);
Build and replace both the struts.jar and commons-digester.jar files in your
application, and add struts-config-schema.xsd to the WEB-INF folder. I used the
struts-example to test this by adding two form beans with the same name, two
Actions with the same path, not defining a name for an ActionForm in struts-
config.xml. When Tomcat is started, there will be error messages in the startup
window. I've also tested this with my own struts app and it seems to be ok
too.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 5739] - Struts fails silently in too many places
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5739 Struts fails silently in too many places --- Additional Comments From [EMAIL PROTECTED] 2004-02-11 07:47 --- Created an attachment (id=10308) Zip containing ActionServlet and XercesParser - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
