Where are tld files in CVS tree
Where in the CVS tree is the struts-html.tld file that needs to be modified when adding attributes to a tag. Thanks, Chris Gastin
RE: Where are tld files in CVS tree
hi, put the tld files under web-inf or create a directory for example 'tld' under web-inf. steps to do 1) Go to the corresponding directory and the select the file. 2) Select the file and select edit selection option. 3) The wincvs client will issue a cvs edit command and the file will be in edit mode. 4) Change the file as per your change request. 5) Go to the Modify Menu and select the option Update Selection 6) The file will be updated and select the option Commit Selection, the file will be commited . Regds, saravanan.v -Original Message- From: Chris Gastin [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 11:56 AM To: Struts Developers List Subject: Where are tld files in CVS tree Where in the CVS tree is the struts-html.tld file that needs to be modified when adding attributes to a tag. Thanks, Chris Gastin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are tld files in CVS tree
Chris Gastin wrote: Where in the CVS tree is the struts-html.tld file that needs to be modified when adding attributes to a tag. What we do is maintain the TLDs as XML documents and then use a style sheet to generate the TLD and the HTML documentation. So, they are hidden in the documentation portion of CVS. /doc/userGuide/struts-*.xml (bean, html, logic, nested tiles) The build will take care of generating the TLDs for you, as well as updating the Developers Guide documentation. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dependancies a wonderful thing
I'm not sure that it matters. We're pragmatic when it comes to Bugzilla, so whichever is less work for you, should work for the rest of us. Volunteer time is our most precious resource. The dependency feature is relatively new, and we haven't come to depend on it ourselves yet :) -Ted. Chris Gastin wrote: I want to fix Bug #14183 (html:img does not support forward attribute), but I want to use the enhancements I made to the TagUtils class (Bug# 23462) to do it. I could do one of the following: Option 1 - Make Bug #14183 depend on Bug #23462 Option 2 - Roll Bug #23462 Patch in with the enhancement with Bug #14183, and resolve Bug #23462 as INVALID Does it matter, which option I pick, and what do you guys prefer as a good practice for this type of mistake in the future. I apologize for any confusion. Please advise. Thanks, Chris Gastin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp
Yes, I'm seeing the same thing. I'll take a look at it later today as well. Are you able to run all the tests under 3.3? -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Robert Leland [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 12:16 AM Subject: Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp James Mitchell wrote: Well, I was in the middle of a reply on another thread (about this), so I'll just put it here instead. With the latest changes I just committed, the tests pass on Tomcat 3.3.x However, I still cannot get them to pass on 4.0.x or 4.1.x. It seems that the container (in both cases), while running on port 8080 in my configuration, thinks it is running on port 80, which is causing the bean:include tests to fail. I'm not sure where in the configuration of the tests that we need to make changes or if that's even the problem, so I'm still checking into it...just thought I would drop a quick note. Thats what I discovered when I filed the bug report originally. Since no one replied to teh reports I figured it was me. At first I suspected the token substitution that I had did so that none of the server.xml files would have to be hard coded. However looking at the generated files under target/test/tomcat41 they look ok. Look at the cactus logs do you see the serialization error message ? So I am glad to see we're both having the same problem :), but unhappy about that also :( -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Chris Gastin [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 10:49 PM Subject: Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp James: You committed the following file: * jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag1.j s p. * jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag2.j s p. Are these unit tests working for you. I am trying to find at least one taglib unit test that works,so I can determine if it my local environment or or the tests which are blowing up. I am not to familiar with Cactus, and its setup. Thanks, Chris Gastin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 29, 2003 7:49 PM Subject: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp jmitchell2003/09/29 17:49:11 Modified:web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp Log: Update taglib tests. I suspect that many of the failures are due to changes in whitespace output (or lack of it). Revision ChangesPath 1.4 +16 -64 jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag1.j s p Index: TestErrorsTag1.jsp === RCS file: /home/cvs/jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestEr r orsTag1.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- TestErrorsTag1.jsp 10 Mar 2003 17:29:52 - 1.3 +++ TestErrorsTag1.jsp 30 Sep 2003 00:49:11 - 1.4 @@ -34,10 +34,7 @@ My Errors go here:html:errors/ /bean:define bean:define id=TEST_RESULTS toScope=page - My Errors go here:default_errors_header -default_errors_prefixMy Errors Text -default_errors_suffixdefault_errors_prefixMy Errors Text 2 -default_errors_suffixdefault_errors_footer + My Errors go here:default_errors_headerdefault_errors_prefixMy Errors Textdefault_errors_suffixdefault_errors_prefixMy Errors Text 2default_errors_suffixdefault_errors_footer /bean:define /logic:equal @@ -68,10 +65,7 @@ My Errors go here:html:errors bundle=alternate/ /bean:define bean:define id=TEST_RESULTS toScope=page - My Errors go here:alternate_errors_header -alternate_errors_prefixMy Alternate Errors Text -alternate_errors_suffixalternate_errors_prefixMy Alternate Errors Text 2 -alternate_errors_suffixalternate_errors_footer + My Errors go here:alternate_errors_headeralternate_errors_prefixMy Alternate Errors Textalternate_errors_suffixalternate_errors_prefixMy Alternate Errors Text 2alternate_errors_suffixalternate_errors_footer /bean:define /logic:equal @@ -101,10 +95,7 @@ My Errors go here:html:errors/ /bean:define
Re: Reviving PageController (ViewController?) discussion?
Joe Germuska wrote: Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure. Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions. Personally, I like returning the ForwardConfig instead of a String since it's extensible. You can always call a method to get whichever String you want, the logical name or the system path. In terms of what a framework based on Commons Chain might be like, I've made some notes here: http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/WHITEBOARD.html But the cool thing about Chain is that it plays well with others. You can start using a Chain solution in your Actions at any time. The Action path could be a command name keyed to the business logic. Likewise, the ActionForward name could be another command keyed to the presentation side of the business logic. (What raw materials will be needed by the controls client specified for the target page.) But, there's also another aspect to the view controller use case -- better support for i18n. The message bundles are a great start, but many applications need to branch to different paths for different locales, or even different clients. So, aside from preparing the request, we could also use a View Action to munge the path (in a new instance of ForwardConfig). Of course, the nuts-and-bolts of this process could be encapsulated in a Chain. But once you take these two related cases together, I do believe an Action extension point for the ForwardConfig would be useful and justified. We've been taking about making the forward smarter for years. Now that we have a more flexible request processor, perhaps it's time to make it smarter in the usual way, by giving it an Action class. I agree that you could collapse the business Action and the presentation Action into a single Chain. But, as much as I like Chain, I don't know if I want to present it as the final solution to this problem. Even with Chain, I might want to separate the concern of calling the business command from the concern of calling the presentation command. I might even want to put them in different catalogs. One set of Actions could be calling a standard set of DAO commands. Another might be calling a set of commands geared for the presentation layer. One might be in a JAR handed down from another team. The second might be in my WEB-INF directory. Of course, you could combine these into the same runtime catalog, but then you have to micro-manage the namespaces and all that. TANSTAFL. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
Jing Zhou wrote: - A well designed framework should not have overlapped concepts, or terms that lead to overlapped concepts. We have the concept of action controllers, we should not have more *controllers* when a view is under preparations. IMHO, a well-designed framework should provide extension points where developers need extensions points. Right now, we have one extension point where a developer can cleanly interject an Action. In practice, many developers, including myself, have found that they need to interject a second Action to prepare the request for the page. We need two extension points, because there are two decisions being made. The first is who will handle the response. The second is what material they need to handle it. I believe we all like the idea of separation of concerns, but most of also do not like splitting responsibilities. Currently, Actions are responsible for doing all the same things we want a page controller to do. So, my current suggestion is to add an extension point to ForwardConfig, so that the RequestProcess can call an Action here as well. This approach lets developers continue using the Actions we all know and love, but saves the trouble of forwarding the request through container, just to complete the response. - The class is responsible for switching module-wide settings. A ModuleSwitch(Command) would be closer to what it really does. IMHO, a large part of the problem is the assumption that there can only be one front controller. Many of the module use cases could be solved if multiple instances of the Struts controller were available in an application. One could handle the *.mod1 URIs andother another could handle the *.mod2 URIs. This approach was contrary to the initial Struts architecture, and we decided to pursue the context-switching strategy. For Struts 2, I would suggest starting with the premise that multiple Struts controllers can be available in the application, and that an action can be specified anywhere that a page or forward can be specified now. If the configuration and server pages never need to know what server pattern is being used, since they can refer only to actions, then we can accomplish modules (and I imagine portlets) by registering each player under a different URI pattern. If we add metadata inheritence, multiple configuration files, and wildcard mappings to the mix, I believe teams would be able to define and use both hierarchical modules or switched modules in the same application. One element of the front controller pattern is consistency in how incoming requests are handled, which helped to justify the there can only be one strategy. Happily, the excellent work that's been done on the RequestProcessor now makes it possible for multiple controllers to share the same customized class. So, we could have our cake and eat it too :) This is a very *vague* area that should draw many experts from different view/logic technologies to work out a common solution for all. When I was at school, my supervisor always asked me what's the state-of-the-art in your proposals. I think there is a state-of-the-art somewhere, we need to find it. In the end, we should be able to let the users to drop a jar file in WEB-INF/lib and register some settings in web.xml for new modules, and then see it working with no codes or very little custom codes. To an extent, we already have this functionality. A user can drop a WAR file into a container's directory, and presto-bango, they have a web application. The portlet spec tries to do the same sort of thing one layer down, so that you can drop a PAR file in an application with the sort of result you describe. The state-of-the-art in for portlets is our own Jetspeed project here at Jarkara (which in fact bred the proposed portlet specification). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are tld files in CVS tree
Hi All I have a Problem with websphere where i had installed websphere 5.0. made JDBC connections for that. I have deployed one WAR application and one EJB Application but i am not able to get my simple jsp in RUN.. Pls guide abhijeet - Original Message - From: V, Saravanan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 3:36 PM Subject: RE: Where are tld files in CVS tree hi, put the tld files under web-inf or create a directory for example 'tld' under web-inf. steps to do 1) Go to the corresponding directory and the select the file. 2) Select the file and select edit selection option. 3) The wincvs client will issue a cvs edit command and the file will be in edit mode. 4) Change the file as per your change request. 5) Go to the Modify Menu and select the option Update Selection 6) The file will be updated and select the option Commit Selection, the file will be commited . Regds, saravanan.v -Original Message- From: Chris Gastin [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 11:56 AM To: Struts Developers List Subject: Where are tld files in CVS tree Where in the CVS tree is the struts-html.tld file that needs to be modified when adding attributes to a tag. Thanks, Chris Gastin - 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]
Multi modules, html:link and module support
Having had a quick browse through the bugs and archives I get the impression that the issue of module support has been fully addressed in some situations. The html:link tag, as it stands, is not module aware. If you want to switch to an alternative module you need to implement a context relative global forward. This is quite clumsy when there are many links to contend with. It also appears that the RequestUtils computeURL() methods are not multi-module aware, simply taking the current module as the default. Has anyone progressed multi-module support any further for 1.2, particularly addressing the problem in a consistant way? I'm converting a large site with 107 modules and I would like to assist with fixing module support to facilitate easier development. Regards Richard Tomlinson. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Validator] FieldChecks Serializable?
I asked this question on the user list yesterday and received no reply. So I figured this is the more appropriate place to ask. Why does org.apache.struts.validator.FieldChecks implement Serializable when it has nothing but static methods and static final instance variables? Just curious. Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] FieldChecks Serializable?
I don't believe there is any reason it needs to be serializable because objects of that class are never created and saved in other objects. We're just in the habit of making things Serializable in case they go into the session. David --- Brandon Goodin [EMAIL PROTECTED] wrote: I asked this question on the user list yesterday and received no reply. So I figured this is the more appropriate place to ask. Why does org.apache.struts.validator.FieldChecks implement Serializable when it has nothing but static methods and static final instance variables? Just curious. Brandon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven is Wicked!
I have been very busy unable to catch with Struts Dev list. Anyway I was fighting with Turbine/JCS trying to compile with Ant, I was literally beating myself up looking at these dependencies, then I read in a forum somewhere Use Maven. I used Maven. Oh my goodness. Whoop! There it is. Why does Struts not a build tool like Maven yet. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23522] New: - errenous trim in doAfterBody of org.apache.struts.taglib.html.MultiboxTag
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=23522.
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=23522
errenous trim in doAfterBody of org.apache.struts.taglib.html.MultiboxTag
Summary: errenous trim in doAfterBody of
org.apache.struts.taglib.html.MultiboxTag
Product: Struts
Version: 1.1 Final
Platform: All
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I have primary key values that contain spaces (perfectly valid for any
database), and the trim() in the doAfterBody method is removing the spaces,
rendering an invalid checkbox input value:
public int doAfterBody() throws JspException {
if (bodyContent != null)
this.constant = bodyContent.getString().trim();
if (.equals(this.constant))
this.constant = null;
return (SKIP_BODY);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven is Wicked!
--- PILGRIM, Peter, FM [EMAIL PROTECTED] wrote: I have been very busy unable to catch with Struts Dev list. Anyway I was fighting with Turbine/JCS trying to compile with Ant, I was literally beating myself up looking at these dependencies, then I read in a forum somewhere Use Maven. I used Maven. Oh my goodness. Whoop! There it is. Why does Struts not a build tool like Maven yet. Because you haven't supplied patches to change the build to use it :-). I agree with you, Maven is pretty neat. David -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23522] - Erroneous trim in doAfterBody of MultiboxTag
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=23522. 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=23522 Erroneous trim in doAfterBody of MultiboxTag [EMAIL PROTECTED] changed: What|Removed |Added Summary|errenous trim in doAfterBody|Erroneous trim in |of |doAfterBody of MultiboxTag |org.apache.struts.taglib.htm| |l.MultiboxTag | --- Additional Comments From [EMAIL PROTECTED] 2003-09-30 14:57 --- The MultiboxTag will be the least of your worries if you're using primary keys with leading/trailing whitespace. We should change the tag to only trim for the comparison to though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23523] New: - Improper use of release() method in custom tags (e.g. logic:messagesPresent)
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=23523.
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=23523
Improper use of release() method in custom tags (e.g. logic:messagesPresent)
Summary: Improper use of release() method in custom tags (e.g.
logic:messagesPresent)
Product: Struts
Version: 1.1 Final
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
There are many implementations of the release() method on the various custom
tags that are delivered with Struts. We have reason to believe that they are
meant to reset the state of a tag after it has been used.
However, the release() method can and should be used to release any long-term
resources [jakarta.apache.org/taglibs/guidelines.html] and is not guaranteed
to be called between invocations of the custom tag. See also http://nagoya.
apache.org/bugzilla/show_bug.cgi?id=16001 for a discussion on release() in the
JSP specification.
The following JSP reproduces the problem with the logic:messagesPresent tag
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
%@ page import=org.apache.struts.action.ActionErrors,
org.apache.struts.action.ActionError,
org.apache.struts.Globals %
% ActionErrors errors = new ActionErrors();
errors.add(password, new ActionError(error.password.required));
request.setAttribute(Globals.ERROR_KEY, errors); %
html
body
logic:messagesPresent message=false
1. invocation
/logic:messagesPresent
logic:messagesPresent message=true
2. invocation
/logic:messagesPresent
/body
/html
To test this you of course need to add the error.password.required key to the
ApplicationResources.properties file and make sure this resource bundle is
loaded before you call the above JSP.
First time this JSP is called (we've tested it with Tomcat 4.1.24 and 4.1.27) it
will correctly display 1. invocation. Second time however it won't display
anything!
The reason is that Tomcat is pooling custom tags (from what we could tell only
tag invocations that use the same attributes will share an instance) and the
release() method is not called between invocations.
This is the code where it fails:
protected boolean condition(boolean desired) throws JspException {
ActionMessages am = null;
if (message != null true.equalsIgnoreCase(message))
name = Globals.MESSAGE_KEY;
...
This would fix the problem (other than disabling pooling in Tomcat):
protected boolean condition(boolean desired) throws JspException {
ActionMessages am = null;
if (message != null) {
if (true.equalsIgnoreCase(message)) {
name = Globals.MESSAGE_KEY;
} else {
name = Globals.ERROR_KEY;
}
}
...
However, the member field 'name' is defined in the super class
ConditionalTagBase and thus the problem should be fixed there - the resetting
should probably happen in the doEnd() method.
As mentioned in the beginning this seems to be caused by a general
misunderstanding of when the release() method is called so there probably are
implications for many other tags as well.
The problem persits in the current nightly build.
Regards
Klaus Jan
www.aragost.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23523] - Improper use of release() method in logic:messagesPresent
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=23523. 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=23523 Improper use of release() method in logic:messagesPresent [EMAIL PROTECTED] changed: What|Removed |Added Summary|Improper use of release() |Improper use of release() |method in custom tags (e.g. |method in |logic:messagesPresent)|logic:messagesPresent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23522] - Erroneous trim in doAfterBody of MultiboxTag
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=23522. 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=23522 Erroneous trim in doAfterBody of MultiboxTag --- Additional Comments From [EMAIL PROTECTED] 2003-09-30 15:14 --- What's wrong with spaces in keys? A space is a character just like any other. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
At 7:28 -0400 9/30/03, Ted Husted wrote: Joe Germuska wrote: Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure. Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions. Personally, I like returning the ForwardConfig instead of a String since it's extensible. You can always call a method to get whichever String you want, the logical name or the system path. Well, the string would just look up a ForwardConfig or ViewController one level out, and I figured you'd still have extensibility and configurability there. My thinking (admittedly still in progress even now) is that I don't really love the implementation of processForwardConfig because it seems to focus on a limited area of how views are rendered. Shouldn't the responsibility for seeing that a response is rendered be encapsulated in the ForwardConfig or a a more active class like ViewController, instead of having the RequestProcessor assume that forwarding is the way to dispatch to a view? I'll acknowledge that this is fairly theoretical, and practically speaking, probably 99% of actions prefer to use RequestDispatcher.forward to pass off to the view. And arguably even when we now write to the response output stream and return a null ForwardConfig, that might be best implemented in another Servlet in the WebApp, to keep Struts more a pure Controller. One small itch about just going ahead and using Action as a ViewController -- should the framework make a more explicit mechanism for communication between the controller action and the view action? Certainly, they can just agree to use well-known request attributes, but is that good enough? But once you take these two related cases together, I do believe an Action extension point for the ForwardConfig would be useful and justified. We've been taking about making the forward smarter for years. Now that we have a more flexible request processor, perhaps it's time to make it smarter in the usual way, by giving it an Action class. OK... so let's go along this line. What ActionMapping gets passed to the view Action? The same that was passed to the control Action? What if I want per-forward configuration details in the struts-config.xml? Do we need to extend ForwardConfig to have all the same configuration properties that ActionConfig has? There are some overlaps, so that could be tricky. I do like the possibility that the ActionForm passed in to the view action could be the one which will be presented on the view page, instead of the one which was populated from request parameters -- this solves the very common problem of people needing to pre-fill a form. There's still the question of who instantiates and manages the view action instances; I guess it would be ActionMapping? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where are tld files in CVS tree
Chris Gastin wrote: Where in the CVS tree is the struts-html.tld file that needs to be modified when adding attributes to a tag. Thanks, Chris Gastin The actual TLD files for the tag libraries are generated (using XSLT transformations) from the same XML sources used to create the reference documentation in the User Guide. For the HTML library in particular, you would edit doc/userGuide/struts-html.xml to add new attributes. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23530] New: - StackOverflowError in 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=23530.
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=23530
StackOverflowError in Action
Summary: StackOverflowError in Action
Product: Struts
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Critical
Priority: Other
Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
There's an issue with the org/apache/struts/action/Action.java checked in on
2003/08/23:
protected void saveErrors(HttpServletRequest request, ActionErrors errors)
{
this.saveErrors(request, errors);
}
was supposed to call
protected void saveErrors(HttpServletRequest request, ActionMessages errors)
given the assumption that the errors parameter of the first Method is an
ActionMessages (as ActionErrors extends ActionMessages). But when it is an
ActionErrors (which can happen when you have old code instanciating ActionErrors
and not ActionMessages) it reqults in an infinite loop calling itself again and
again =).
A possible fix would be to make a cast:
this.saveErrors(request, (ErrorMessages)errors);
Regards,
Matz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23530] - StackOverflowError in 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=23530. 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=23530 StackOverflowError in Action --- Additional Comments From [EMAIL PROTECTED] 2003-09-30 19:41 --- The cast of course should be: this.saveErrors(request, (ActionMessages)errors); ... and delete that assumption thing I wrote - I think the code must have been tested only with ActionMessages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/action Action.java
rleland 2003/09/30 13:28:35
Modified:src/share/org/apache/struts/action Action.java
Log:
Bug# 23530 patch submitted by matthias.fraass at tricoder.net
Cast method call to avoid recursively calling itself 1
Thanks !
Revision ChangesPath
1.72 +12 -12jakarta-struts/src/share/org/apache/struts/action/Action.java
Index: Action.java
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/action/Action.java,v
retrieving revision 1.71
retrieving revision 1.72
diff -u -r1.71 -r1.72
--- Action.java 29 Sep 2003 04:26:23 - 1.71
+++ Action.java 30 Sep 2003 20:28:35 - 1.72
@@ -202,7 +202,7 @@
form,
(HttpServletRequest) request,
(HttpServletResponse) response);
-
+
} catch (ClassCastException e) {
return null;
}
@@ -421,9 +421,9 @@
* This will be removed after Struts 1.2.
*/
protected void saveErrors(HttpServletRequest request, ActionErrors errors) {
-this.saveErrors(request, errors);
+this.saveErrors(request,(ActionMessages)errors);
}
-
+
/**
* Save the specified error messages keys into the appropriate request
* attribute for use by the lt;html:errorsgt; tag, if any messages
@@ -454,9 +454,9 @@
* ensure that the request attribute is not created.
*
* @param request The servlet request we are processing.
- * @param messages The messages to save. codenull/code or empty
+ * @param messages The messages to save. codenull/code or empty
* messages removes any existing ActionMessages in the request.
- *
+ *
* @since Struts 1.1
*/
protected void saveMessages(
@@ -472,7 +472,7 @@
// Save the messages we need
request.setAttribute(Globals.MESSAGE_KEY, messages);
}
-
+
/**
* Save the specified messages keys into the appropriate session
* attribute for use by the lt;html:messagesgt; tag (if
@@ -480,9 +480,9 @@
* ensure that the session attribute is not created.
*
* @param session The session to save the messages in.
- * @param messages The messages to save. codenull/code or empty
+ * @param messages The messages to save. codenull/code or empty
* messages removes any existing ActionMessages in the session.
- *
+ *
* @since Struts 1.2
*/
protected void saveMessages(
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23522] - Erroneous trim in doAfterBody of MultiboxTag
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=23522.
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=23522
Erroneous trim in doAfterBody of MultiboxTag
--- Additional Comments From [EMAIL PROTECTED] 2003-09-30 20:32 ---
Wouldn't be it more appropiate to use:
public int doAfterBody() throws JspException {
if (bodyContent != null)
this.constant = bodyContent.getString();
if (StringUtils.isBlank(this.constant))
this.constant = null;
return (SKIP_BODY);
}
??
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23530] - StackOverflowError in 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=23530. 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=23530 StackOverflowError in Action [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-09-30 20:32 --- This will be fixed in tonights build, 2003 10 01 Thanks ! -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
Don Brown wrote: SNIP If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. SNIP AFAIK, that is 90%+ of O.S. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:24 --- Created an attachment (id=8404) TagUtils refactored - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:25 --- Created an attachment (id=8405) struts-html.xml added forward and action attributes for img - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:27 --- Created an attachment (id=8406) org.apache.struts.taglib.html.LocalStrings.properties modifed imgTag.src message - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:28 --- Created an attachment (id=8407) ImgTag -added forward and action attributes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:30 --- I did some user testing of the tag, and it seems to be working, but I will add unit test once the unit test issue is resolved. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23462] - Refactored TagUtils.computeURL() method
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=23462. 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=23462 Refactored TagUtils.computeURL() method [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:32 --- Resolving as INVALID because I rolled up the refactor TagUtils changes in the Bug #14183 since that Bug could use the changes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Forrest Option
I haven't used Forrest but Maven was pretty darn easy to get going. All I had to do was download it and run maven jar or maven site:generate. It handled all of the dependencies by itself. Assuming Forrest is as easy to use as Maven, I don't really care which we use. I do prefer to maintain a site LF that is fairly consistent with other Jakarta projects so the Avalon style linked below looks good. David --- Don Brown [EMAIL PROTECTED] wrote: I know the discussion on whether to use Forrest or Maven to generate the Struts website was a few weeks back, but unfortunately, at the time, I was too busy to participate. I'd like to lay out a case for Forrest, not to insist Struts uses it, but rather to make sure the decision is made with all the available information. In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) - Power and features of Cocoon including charting, web services integration, scripting support, etc. Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. Please note, this examples are not polished and only serve to demonstrate the skinability of Forrest. Krysalis style: http://www.twdata.org/dakine/site/ Avalon/Tigris style: http://www.twdata.org/dakine/site1/ Forrest/XML Apache style: http://www.twdata.org/dakine/site2/ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute
You can get around the unit test issue by either: - Comment out the sections of the tests that are failing or - Directly reference the ones you want tested Either way would only be a temporary solution, but it would help you move along until we iron out what's going on. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 8:30 PM Subject: DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:30 --- I did some user testing of the tag, and it seems to be working, but I will add unit test once the unit test issue is resolved. - 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: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute
James: All Taglib tests are failing on me right now. I am getting the following errors, and I don't know if it is because of the situation at hand or my local environment setup. That is why I was going to wait for everthing to get ironed out concerning the taglib unit tests. Unit tests for code other than taglib are working fine, and passing. I am going mess with it later tonight, and see what I can figure out. Chris Gastin - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 8:56 PM Subject: Re: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute You can get around the unit test issue by either: - Comment out the sections of the tests that are failing or - Directly reference the ones you want tested Either way would only be a temporary solution, but it would help you move along until we iron out what's going on. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 8:30 PM Subject: DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:30 --- I did some user testing of the tag, and it seems to be working, but I will add unit test once the unit test issue is resolved. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute
Chris Gastin wrote: James: All Taglib tests are failing on me right now. I am getting the following errors, and I don't know if it is because of the situation at hand or my local environment setup. That is why I was going to wait for everthing to get ironed out concerning the taglib unit tests. Unit tests for code other than taglib are working fine, and passing. I am going mess with it later tonight, and see what I can figure out. It's not your setup. About a month ago I tried the tests on 1.1 Final, RC-1, Beta 3, ... All those tests also failed. They didn't fail at one time. I tried upgrading to cactus 1.5beta1 and hit some other snags. You might be able to roll back to cactus 1.3. Again that isn't a real solution, but may be good enough for your needs. Chris Gastin - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 8:56 PM Subject: Re: DO NOT REPLY [Bug 14183] - html:img does not support forward attribute You can get around the unit test issue by either: - Comment out the sections of the tests that are failing or - Directly reference the ones you want tested Either way would only be a temporary solution, but it would help you move along until we iron out what's going on. -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 8:30 PM Subject: DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 00:30 --- I did some user testing of the tag, and it seems to be working, but I will add unit test once the unit test issue is resolved. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp
Sorry for the late response...beenwellbusy busy. This problem is definitely within cactus (or our mis-configuration of it) as the tags work fine in a normal application. I have tried 13-1.4 and 13-1.4.1, both fail with the same issue (wrong port) Just to make sure that I'm not going insane, I: - grabbed a new (not update) checkout from cvs - changed cactus.contextPort to run on 8082 - added a few System.out.println() statements to the TestIncludeTag.jsp that print out the server.getServerPort() to the console. I even went so far as to add a reference to the /examples app in the Host element of the /conf/test/tomcat41/server.xml, and as the tests were running I hit http://localhost:8082/examples directly from a browser and checked out the jsp snoop page...guess what..request.getServerPort() shows 8082. I vaguely remember this happening to me quite a ways back. IIRC, there were some incompatibilities between some of the jars in one or more of the cactus distributions. I believe that was one of the reasons that I added all of the different cactus configurations to the build.properties.sample file. So, as a last resort, I changed the tests to run on port 80 (cactus.contextPort = 80). With that the TestIncludeTag now passes, but then the test fails on TestBaseTag, which expects: http://localhost:80/test/blah/blah ...however, the test outputs (which is actually correct): http://localhost/blah/blah Jeez! I can't win any way I try!!! So, at this point, we need to figure out why or how the configuration is screwed. Well, I can't waste any more time on this, I hope someone with a better understanding of Cactus can figure this out...Bill...you out there? Peace! -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 6:59 AM Subject: Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp Yes, I'm seeing the same thing. I'll take a look at it later today as well. Are you able to run all the tests under 3.3? -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Robert Leland [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 12:16 AM Subject: Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp James Mitchell wrote: Well, I was in the middle of a reply on another thread (about this), so I'll just put it here instead. With the latest changes I just committed, the tests pass on Tomcat 3.3.x However, I still cannot get them to pass on 4.0.x or 4.1.x. It seems that the container (in both cases), while running on port 8080 in my configuration, thinks it is running on port 80, which is causing the bean:include tests to fail. I'm not sure where in the configuration of the tests that we need to make changes or if that's even the problem, so I'm still checking into it...just thought I would drop a quick note. Thats what I discovered when I filed the bug report originally. Since no one replied to teh reports I figured it was me. At first I suspected the token substitution that I had did so that none of the server.xml files would have to be hard coded. However looking at the generated files under target/test/tomcat41 they look ok. Look at the cactus logs do you see the serialization error message ? So I am glad to see we're both having the same problem :), but unhappy about that also :( -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 770.822.3359 AIM:jmitchtx - Original Message - From: Chris Gastin [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 10:49 PM Subject: Re: cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestErrorsTag1.jsp TestErrorsTag2.jsp James: You committed the following file: * jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag1.j s p. * jakarta-struts/web/test/test/org/apache/struts/taglib/html/TestErrorsTag2.j s p. Are these unit tests working for you. I am trying to find at least one taglib unit test that works,so I can determine if it my local environment or or the tests which are blowing up. I am not to familiar with Cactus, and its setup. Thanks, Chris Gastin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September
Re: The Forrest Option
Don Brown wrote: I know the discussion on whether to use Forrest or Maven to generate the Struts website was a few weeks back, but unfortunately, at the time, I was too busy to participate. I'd like to lay out a case for Forrest, not to insist Struts uses it, but rather to make sure the decision is made with all the available information. I prefer Maven because it provides builds, testing, QA tools, and site generation in one tool. The repository of binaries makes building a distribution or maven enabled site as easy as typeing, 'maven' for new users. Changing the look/skin is straight forward, though as I say below I wouldn't invest alot of time tweaking it. My main question to the items below is 'which of these features would we use for the struts site' In short, Forrest offers these benefits over Maven's website generation: - Multiple output formats including PDF and HTML Maven has been doing this for a while now.. - SVG to PNG rendering - Built for handling and aggregating multiple XML sources like RRS (soon wiki and Docbook) Maven currently handles RRS, Docbook, and a few other formats, including the ability to take a preexisting framed html like JavaDoc and take it apart and assemble it again with a .maven wrapper. What's the wiki thing, and why do you think that would be usefull ?. Could you give an example how multiple XML sources would be aggregated and used as a single source. How is this capability an advantage for the struts web site. - Power and features of Cocoon including charting, web services integration, scripting support, etc. Charting is nice. What types of charting do we get for free or almost free that would help with our site. I believe Maven can provide charts about bugs reports, which I don't EVEN want to see ;-). How does web services/scripting fit into our needs? Further, deciding between Forrest and Maven isn't an either/or situation. There exists a Forrest plugin for Maven and it would be easy to integrate Maven's reports into a Forrest site build. I am assuming this plugin uses the maven xml doc files and generates forrest docs ? To me, the key feature of Forrest is the first one listed, multiple outputs. This is especially useful for documentation as PDF is much better than HTML for printing for the many users that like hard copies. Maven does this. Finally, Forrest content is built to be presented in not only multiple output formats, but multiple skins. To demonstrate this, I've quickly redone the Struts site into Forrest format (which is very similiar to the current format thanks to the xhtml work of late). I've only converted the menu and the main page, which should be sufficient. We only need one look, though I don't like the default Maven look, but not enough bothering changing it. We may customize it but we won't be changing it dynamically. Please note, this examples are not polished and only serve to demonstrate the skinability of Forrest. Krysalis style: http://www.twdata.org/dakine/site/ Avalon/Tigris style: http://www.twdata.org/dakine/site1/ Forrest/XML Apache style: http://www.twdata.org/dakine/site2/ If we did decide to go with Forrest, I'm willing to convert the old site over and help handle any integration. I'm most definately not an expert at Forrest, but am familiar with Cocoon and thankfully, Forrest is pretty easy. Don -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14183] - html:img does not support forward 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=14183. 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=14183 html:img does not support forward attribute --- Additional Comments From [EMAIL PROTECTED] 2003-10-01 04:17 --- One of the files I modifed was a resource file org.apache.struts.taglib.html.LocalStrings.properties -imgTag.src=You must specify exactly one of src, srcKey, page, or pageKey +imgTag.src=You must specify exactly one of src, srcKey, page, pageKey, forward, or action There was a resource file named org.apache.struts.taglib.html.LocalStrings_ja.properties. I assume this is the japanese version. Unfortunatly I don't speak anything other than English, so could someone who is fluent in Japanese update this file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
