Re: [VOTE] Struts as an Apache Top Level Project
+1 to submit the draft TLP resolution. +1 to nominate Craig as VP. Cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/tiles-documentation/examples/tiles footer.jsp
Hi all, I don't mind with this copyright. I agree to remove it if, as Ted says, we decide to remove all this kind of copyrights in future Struts versions. I am not very active in the Struts community these weeks, but I hope to come back soon :-) Cedric Martin Cooper wrote: Is there a reason for removing Cedric's copyright? As I understand it, based on the language in the CLA, Cedric is entitled to keep his own copyright there, if he so desires. -- Martin Cooper On Wed, 7 Jan 2004 [EMAIL PROTECTED] wrote: rleland 2004/01/07 13:14:40 Modified:web/tiles-documentation/common footer.jsp web/tiles-documentation/examples/tiles footer.jsp Log: remove Cerdics personal Copyright and leave only Apache Copyright Revision ChangesPath 1.3 +1 -3 jakarta-struts/web/tiles-documentation/common/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/common/footer.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- footer.jsp 29 Dec 2002 21:20:52 - 1.2 +++ footer.jsp 7 Jan 2004 21:14:40 - 1.3 @@ -2,9 +2,7 @@ div align=center font color=#023264 size=-1 -em Copyright copy; 2000-2003, Apache Software Foundation /em - br -emand Cedric Dumoulin/em +em Copyright copy; 2000-2004, Apache Software Foundation /em /font /div html:img page=/images/struts-power.gif align=right border=0/ 1.2 +0 -2 jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- footer.jsp 6 Jul 2002 01:13:50 - 1.1 +++ footer.jsp 7 Jan 2004 21:14:40 - 1.2 @@ -2,8 +2,6 @@ div align=center font color=#023264 size=-1 em Copyright copy; 2001, Apache Software Foundation /em - br -emand Cedric Dumoulin/em /font /div img src=%=request.getContextPath()%/images/struts-power.gif align=right border=0 - 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: Tiles Advanced Features by Cedric Dumoulin
Hi, The url http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf still working. There is sometime some trouble with the web server. Cedric Sean Gunn wrote: Anyone know of a mirror for tilesAdvancedFeatures.pdf? It is referenced in the tiles guide: http://jakarta.apache.org/struts/userGuide/dev_tiles.html as being at http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf but I constantly get no connection. Or, if you could send me a copy to sean(at)downplay(dot)org I would really appreciate it. PS Are there any other good forums for struts and/or tiles development? THANKS!!! - 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: [Vote] Don Brown as committer
+1 Cedric James Mitchell wrote: Don has been involved with Struts for quite some time and has submitted numerous patches and enhancements. I believe that as we move forward with development, having Don on our team would be a tremendous asset. I would like to nominate Don Brown as a Committer. Here's my +1!!! [ ] +1 - I agree. [ ] +0 - I agree, but think we should wait until he can recite the servlet spec verbatim. [ ] -0 - I disagree, but not enough to stop the train. [ ] -1 - I disagree and my reason(s) are/is .. -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 678-910-8017 AIM:jmitchtx - 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: [VOTE] Struts 1.1 Final Release
+1 Cedric Ted Husted wrote: Since no significant issues have arisen in response to Struts 1.1 RC2, I propose that we release the tip of the main trunk in CVS as the Struts 1.1 Final release. I have checked in a proposed release plan, which is available for review on the Struts web site: http://jakarta.apache.org/struts/proposals/release-plan-1.1.html Release plans must pass by a majority vote of committers on the project, but all other interested parties are welcome to cast their votes (and/or make comments or suggestions on the plan) as well. -- Vote: Struts 1.1 Final Release Plan [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). - I am +1 on the Struts 1.1 Final release plan. -Ted. - 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: Using Struts tab layout
Hi, This kind of question should be asked in the struts user list. I forward the thread to struts-user. Cedric [EMAIL PROTECTED] wrote: Hi, I'm a Struts newbie and this question may have been already addressed, but I can't seem to find anything relevant in the mail archives. I'm trying to use the generic Struts tab layout to my web content and have various page definitions built on top of my tile modules. In the tabs application demo, each tab directly references a link to a JSP url. However, all of my pages are defined via the tiles XML definition file, it would be nice if I can reference these definitions in the tab list rather than the URL link (would mean a reworking of my design). Is there a way to do this or can someone recommend a solution? Any help would be appreciated. Here's a scaled-down version of my definition file. definition name=.aFGenericReportPage path=/tiles/layout/aFReportLayout.jsp put name=title value=SOME TITLE HERE/ put name=header value=SOME HEADER HERE/ put name=body value=SOME BODY HERE/ /definition definition name=.aFOTDRMeasReportPageOverview extends=.aFGenericReportPage put name=title value=OTDR Measurement Report/ put name=header value=OTDRMeasReportHeader.def type=definition/ put name=body value=aFOTDRMeasBody.def type=definition/ /definition ... !-- Page Definitions ends here -- !-- tabs page -- definition name=aFOTDRTabbedMeasBody.def path=/tiles/layouts/aFTabsLayout.jsp put name=selectedIndex value=0/ put name=parameterName value=selected/ putList name=tabList !-- would like to do something like this, but not sure on how and syntax -- add value=Overview link=.aFOTDRMeasReportPageOverview/ add value=Detailed link=.aFOTDRMeasReportPageDetailed/ /putList /definition definition name=.aFOTDRMeasReportPage put name=title value=OTDR MeasurementReport/ put name=body value=aFOTDRTabbedMeasBody.def/ /definition Regards, Trang - 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: Question on struts, tiles and jsf
Hi, I know someone who have made some works, and apparently have succeed, to let Tiles, Struts and JSF work all together. Unfortunately, our mails are in French, and I have no more news since some weeks. Cedric Ives Landrieu wrote: Hi, I was experimenting with struts and tiles (not very experienced in using them yet) and wanted to explore whether these could be combined with Java Server Faces (using struts-faces). This does not seem to be possible, as both the struts-faces integration library as tiles depend on using their own request processor class. As far as I can tell from a quick look at the struts sources (I don't think the source code for struts-faces is available?), the main reasons why this is done is to initialize (reading their config files etc.) and intercept some forwards/requests. I think this functionality should all be done in the plugin class (or some kind of listener interface should be created to intercept forwards). If I understand correctly, plugins are exactly meant for initializing other application components. I think that the interception of forwards should also be delegated to plugins (or refactored out of the request processor). I understand that the way things are is for historical reasons because tiles was integrated with struts relatively recently, but it seems that in order to achieve maximum flexibility for struts, the plugin interface should become more advanced, so that special purpose request processors become unnecessary. So, to end with a question, am I correct in my analysis? Or is there another way to combine tiles with java server faces? Can I file this somewhere as a RFE? Ives - 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: Tiles beans package?
David Graham wrote: The reason I asked is because a package with 2 classes isn't too useful unless there are plans to add more beans. There were plans to add more kind of beans related to the definitions. For now, there is only one kind of interface and its implementation ;-(. Cedric Thanks for the info on the item tag. David From: Cedric Dumoulin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Tiles beans package? Date: Mon, 24 Mar 2003 09:51:38 +0100 Hi, This two classes are part of the Tiles API, so they should NOT be moved. The MenuItem interface is used in association with the item ... tag in the tiles config file. The SimpleMenuItem is its default implementation. Cedric David Graham wrote: There is a o.a.s.tiles.beans package with 2 classes in it: MenuItem and SimpleMenuItem. The only references to these classes is in the Tiles example webapp. Should this package be moved to the webapp instead of in the Tiles public interface? Dave _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - 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: Tiles insert tag was Re: cvs commit: jakarta-struts/src/share/org/apache/...
David Graham wrote: No. The parent definition only declare the attributes relevant to the parent. A child (extending a parent) can add some new attributes. If an attribute is not used in a parent, you don't need to declare it. In your case, the attribute is used by the associated layout, but you want the layout to ignore it (to show nothing). Ok, I'll try the ignore attribute. The change to insert tag has been removed. It's strange that the error only occurs in WAS 5 and not Tomcat. Yes, this is strange. I have already seen this problem with a server replacing the empty string with a null reference. In fact, the generated jsp code doesn't set the attribute at all if the string is empty, so the attribute is set to null ;-(. It is a kind of optimization that have a side effect. Maybe the same happen with WAS 5. For me, this is a bug. Also, maybe there is an option in WAS 5 to avoid such thing ... Cedric Cedric David _ - 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: Tiles TextTag?
I think we can even remove it because there is no associated tld, so no possibility to use it in a page. This tag is very old and was developed to provide a better integration between tiles and struts when tiles wasn't even in the contrib area. This tag has no reason to be left now, unless someone use it in a special way, but this seem to be hard. So I propose to remove the class unless there is objections. Cedric David Graham wrote: There is a o.a.s.taglib.tiles.ext.TextTag class that doesn't appear to have much use. It's not documented in the tiles taglib api and there are no references to it in Struts. Can we deprecate this tag and remove it in 1.2? David _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail - 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/src/share/org/apache/struts/taglib/tilesInsertTag.java
[EMAIL PROTECTED] wrote: dgraham 2003/03/17 18:42:59 Modified:src/share/org/apache/struts/taglib/tiles InsertTag.java Log: Formatting changes only (in preparation of bug fix). May I recall that the consensus is actually to not reformating classes ? Check http://jakarta.apache.org/struts/status.html under the Coding Convention Guidelines, it is written: Observe the style of the original. Resist the temptation to make stylistic changes for their own sake. Reformating a classes is painful: it introduce useless noise in CVS, confuse original authors, and don't bring useful things. So please avoid it. I know that you don't like my format style. But this is not a valid reason to reformat it ;-) Cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tilesInsertTag.java
[EMAIL PROTECTED] wrote:
dgraham 2003/03/17 18:46:02
Modified:src/share/org/apache/struts/taglib/tiles InsertTag.java
Log:
Only include page if it's != null.
Revision ChangesPath
1.14 +13 -5 jakarta-struts/src/share/org/apache/struts/taglib/tiles/InsertTag.java
Index: InsertTag.java
===
RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/tiles/InsertTag.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- InsertTag.java 18 Mar 2003 02:42:59 - 1.13
+++ InsertTag.java 18 Mar 2003 02:46:01 - 1.14
@@ -871,11 +871,16 @@
if (flush) {
pageContext.getOut().flush();
}
-doInclude(page);
+
+if ((page != null) (page.length() 0)) {
+doInclude(page);
+}
+
This introduce an important change in the behavior: until now, a null
page was considered as an error, and so an exception was thrown.
Doing this modification let consider a null page as a valid page
value, with no error report !
Personally, I thing that having a null page is an error. Let consider
the following declarations:
tiles:insert page=aPage / OK
tiles:insert / ERROR !! (but this one is also reported by the tld)
definition name=aDef path=aPage / OK
definition name=aDef / ERROR ! (no report, no exception ;-) )
Checking the struts user list, I suppose you have try to correct a bug
encountered with WS 5 where you have something like the following and
got a null exception:
definition name=tiles.leftnav path=/layout/leftnav.jsp
!-- this is the optional secure part of the navigation --
put name=secureLeftNav value=/
/definition
For me the problem comes from WS 5 that replace the empty string by
a null reference ;-(.
A solution is to put a blank in the string, and set the flag
ignore=true when inserting the attribute value.
Cedric
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tilesInsertTag.java
Ted Husted wrote: Personally, I would say that volunteering to actively maintain a piece of code and creating a bug fix is not reformatting for the sake of reformatting. It is apply the established code conventions to help with fixing an implementation issue. The code should have observed the style of Craig's original codebase when it was first donated. If we all always observed the style of [our own] original, there would be no conventions at all. In this case, the code was donated by me :-). I have first developed it following a standard coding. Unfortunately, it is not the Jakarta coding, neither the Craig's one. It is to not that I am not the only one that think that the Jakarta proposed coding is not the best adapted. Will all agree on the basis, and this is the essential. We mainly disagree on the place of brackets, and line size. It would not be useful to change the style to make a very simple correction, or to apply someone else's patch, but if a person needs to analyze the code to resolve a problem, then that is a different matter. Ok, but this rule also apply when I have to maintain the code. The applied formatting make me crazy to recognize what I have developed myself ! It is why I ask to not change yet the code I have developed , and which I mainly maintain. When I have to maintain code from the struts core, I don't change the formatting, I simply follow what exist. It's important to note that David posted the stylistic changes first, so that it would be easier to see what changed on the next commit. Since I'm sure the style changes were applied by his IDE, the likelihood introducing a bug this way is negligible. This is a good way to do when we will agree on a format style and decide to reformat everything. For now, I think this is not necessary, and just a waste of time (reformating, discussing about reformating, re-understanding the new formated code, ...). I have to correct a bug today, but I have waste all my time on this reformating problem. The codebase belongs to the community, and one of our obligations to the community is to provide a reasonably consistent code style. I also agree, but the grain of this consistency can be the roots package (struts core, tiles, ...), at least until when we agree/discuss on a format and decide to reformat everything ;-) . Cedric -T. Cedric Dumoulin wrote: [EMAIL PROTECTED] wrote: dgraham 2003/03/17 18:42:59 Modified:src/share/org/apache/struts/taglib/tiles InsertTag.java Log: Formatting changes only (in preparation of bug fix). May I recall that the consensus is actually to not reformating classes ? Check http://jakarta.apache.org/struts/status.html under the Coding Convention Guidelines, it is written: Observe the style of the original. Resist the temptation to make stylistic changes for their own sake. Reformating a classes is painful: it introduce useless noise in CVS, confuse original authors, and don't bring useful things. So please avoid it. I know that you don't like my format style. But this is not a valid reason to reformat it ;-) Cedric - 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: [STP] RC1 Release Plan
Ted Husted wrote: OK, we're back down to two. =:0) http://issues.apache.org/bugzilla/show_bug.cgi?id=17562 Cedric, I can't quite follow the thread on this one myself. Does it look like Redding's patch would help (at least for now). Lavy seems to say it doesn't work for him. I have to do some few tests to know if this a solution, at least with Tomcat. I will do it asap (these days). I was hoping to do it today, but haven't find time yet. Cedric http://issues.apache.org/bugzilla/show_bug.cgi?id=18066 Arron (or Antoni). Does it seem like there would be an easy patch here? Would specifying the type be a reasonable workaround? -- at least until we can fix it properly in the next iteration. If we can swat these two, we might be able to roll out RC2. -T. Ted Husted wrote: I'll update the plan and website later, but for now, the outstanding RC1-RC2 list stands at five tickets [NOT RESOLVED, NOT CLOSED, STRUTS, NOT UNKNOWN]. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=0.5+Finalversion=1.0+Beta+1version=1.0+Beta+2version=1.0+Beta+3version=1.0+Finalversion=1.0.1+Finalversion=1.0.2+Finalversion=1.1+Beta+1version=1.1+Beta+2version=1.1+Beta+3version=1.1+RC1version=Nightly+Buildshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Bug+Number -T. Ted Husted wrote: I'm going to make run at the bug list and update the Release Plan, as we did for b3. -T. - 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: Code Formatting was Re: cvs commit: jakarta-struts/src/share/org/apache/...
I disagree with you, we don't have a standard. Just take a look to the code (not mine, Craig's one ;-) and you will see that we originally don't follow completely the Sun standard. We follow it for several important things like naming convention and javadoc. We don't follow it for the formating part like indentations and bracket places. I think that the Sun Java coding conventions has some good things, but it also has some bads or deprecated things. The code format is always a problem and subject to discussions and holly wars. Imagine what will happen if each commiter change the code format each time he touch a file ? It is why I ask to refrain reformating the code just because you don't like its format. Cedric David Graham wrote: The bottom line on this issue is that we already have a standard, the Sun Java coding conventions documented here: http://java.sun.com/docs/codeconv/ When modifying code it is our responsibility to ensure that it meets these standards. David Personally, I would say that volunteering to actively maintain a piece of code and creating a bug fix is not reformatting for the sake of reformatting. It is apply the established code conventions to help with fixing an implementation issue. The code should have observed the style of Craig's original codebase when it was first donated. If we all always observed the style of [our own] original, there would be no conventions at all. It would not be useful to change the style to make a very simple correction, or to apply someone else's patch, but if a person needs to analyze the code to resolve a problem, then that is a different matter. It's important to note that David posted the stylistic changes first, so that it would be easier to see what changed on the next commit. Since I'm sure the style changes were applied by his IDE, the likelihood introducing a bug this way is negligible. The codebase belongs to the community, and one of our obligations to the community is to provide a reasonably consistent code style. -T. Cedric Dumoulin wrote: [EMAIL PROTECTED] wrote: dgraham 2003/03/17 18:42:59 Modified:src/share/org/apache/struts/taglib/tiles InsertTag.java Log: Formatting changes only (in preparation of bug fix). May I recall that the consensus is actually to not reformating classes ? Check http://jakarta.apache.org/struts/status.html under the Coding Convention Guidelines, it is written: Observe the style of the original. Resist the temptation to make stylistic changes for their own sake. Reformating a classes is painful: it introduce useless noise in CVS, confuse original authors, and don't bring useful things. So please avoid it. I know that you don't like my format style. But this is not a valid reason to reformat it ;-) Cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - 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: Tiles insert tag was Re: cvs commit: jakarta-struts/src/share/org/apache/...
David Graham wrote: Cedric, Here's the problem as I understand it: To extend a definition you must declare all the attributes in the parent definition even if they're set to , right? No. The parent definition only declare the attributes relevant to the parent. A child (extending a parent) can add some new attributes. If an attribute is not used in a parent, you don't need to declare it. In your case, the attribute is used by the associated layout, but you want the layout to ignore it (to show nothing). Cedric So, only in WAS 5 when I try tile:insert I get an error. The attribute is defined, it's just set to . So, it's burdensome to use ignore=true when this is the only way of inserting an extended tile that sets the attribute to (AFAIK). David This introduce an important change in the behavior: until now, a null page was considered as an error, and so an exception was thrown. Doing this modification let consider a null page as a valid page value, with no error report ! Personally, I thing that having a null page is an error. Let consider the following declarations: tiles:insert page=aPage / OK tiles:insert / ERROR !! (but this one is also reported by the tld) definition name=aDef path=aPage / OK definition name=aDef / ERROR ! (no report, no exception ;-) ) Checking the struts user list, I suppose you have try to correct a bug encountered with WS 5 where you have something like the following and got a null exception: definition name=tiles.leftnav path=/layout/leftnav.jsp !-- this is the optional secure part of the navigation -- put name=secureLeftNav value=/ /definition For me the problem comes from WS 5 that replace the empty string by a null reference ;-(. A solution is to put a blank in the string, and set the flag ignore=true when inserting the attribute value. Cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail - 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: [STP] RC1 Release Plan
Whaoou ... 3 tickets for tiles on 5 left ;-). I have mark one as duplicate, change a second as an enhancement, and still need to solve the 3rd. I will do it asap. Now, there is only 3 tickets remaining. Cedric Ted Husted wrote: I'll update the plan and website later, but for now, the outstanding RC1-RC2 list stands at five tickets [NOT RESOLVED, NOT CLOSED, STRUTS, NOT UNKNOWN]. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=0.5+Finalversion=1.0+Beta+1version=1.0+Beta+2version=1.0+Beta+3version=1.0+Finalversion=1.0.1+Finalversion=1.0.2+Finalversion=1.1+Beta+1version=1.1+Beta+2version=1.1+Beta+3version=1.1+RC1version=Nightly+Buildshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Bug+Number -T. Ted Husted wrote: I'm going to make run at the bug list and update the Release Plan, as we did for b3. -T. - 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: Tiles excessive memory usage
Hi, Christophe Warland wrote: [...] With regards to the methodology used, simply start your JVM with java -Xrunhprof:heap=sites ... and look at the self-explanatory results in java.hprof.txt. I can also send you, Cedric, our detailed analysis under private email if you agree not to distribute it. What I am also interested in is the huge tile-config.xml files containing the 668 definitions and there attributes ;-). This could save me a lot of times . Of course all the documents that you can send me will fit under the NDA. Alternatively, you can also follow me through this enlightening theorical discussion. (The stats gurus amongst you are welcome to step in and correct me; from here on, I am only trying to show off and look smart :) As our example showed, just for one attribute, we ended up with 668 entries instead of one. For all the attributes in our system, we can use the following model: if 'n' is the number of Component Definitions, 'K' is the total number of all the attributes, and 'd' the average depth of inheritance, let's further call 'm' the average number of inherited attributes per Component Definition, with m being conceptually equivallent to (K/n)*d, then we end up with instantiating (n*m)^d HashMap$Entry objects instead of only 'K'. That is (n*m)^d instead of n*m/d. Exponential square instead of linear! To put that in perspective, our production app yields the following values: n = 668 K = 7037 d = 1.57 m = 16.5 And we get (668*16.5)^1.57 = 2,219,978 HashMap entries instead of the more intuitive 7,037 (= K). Since, one HashMap entry takes 24 bytes in memory, this represents my loss of 50 MB (see previous email). *Had* we developped an application with the same amount of Component Definitions and attributes but with a higher average depth of inheritance, for example d=2 instead of d=1.57, this model shows that we would have needed 4.5 GB of RAM just to load Tiles. This number looks ridiculously high, so my mathematical model is probably wrong. However, keep in mind that our app does need an extra 50 MB of RAM just to load 7037 attributes, which is ridiculously high too. So this exponential equation might not be too far from the truth. Ok, you convince me that in case of very large application like yours, the actual inheritance implementation can be improved in order to reduce the amount of memory used. The bottom line is, Tiles does not scale for us. YMMV. We found a fix that works for us and we wanted you to be aware of it. Feel free to use it or drop it. And again, keep in mind that our analysis is based on Tiles 2001-09-10, so this misbehavior might not be present in the latest Struts 1.1 RC#. The inheritance mechanism hasn't change in this way, so your analyze still actual. Back to your email, Cedric, it is also very much possible that we misuse Tiles. You say that we could avoid the map creation in the contexts when no locale attributes are set. Could you elaborate a little? Thanks. I say that we can easily modify the actual implementation to avoid systematic creation of a hashmap in each new context. We can create the hashmap only if needed (i.e. when an attribute is added to the context by the way of insert ...put ..//insert). Otherwise, we store the definition hashmap reference, and use it to retrieve existing attributes (but not to store new ones). This will not solve the problem of the inheritance mechanism. Here we need to implement a mechanism like the one you propose: Don't systematically copy parent attribute entries in the child definitions, but use the parent attribute maps instead. Cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles still in the contrib directory
Tiles can be removed from the contrib area. I think we have put everything in the main trunk yet. Cedric Craig R. McClanahan wrote: On Fri, 28 Feb 2003, David Graham wrote: Date: Fri, 28 Feb 2003 19:35:36 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Tiles still in the contrib directory I just noticed that Tiles code is duplicated under the contrib directory. Shouldn't this be removed now that Tiles is integrated into Struts? Makes sense to me. Cedric, is there anything left in the contrib area that we need to keep? David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should this be called a bug ?
This is a known behavior ;-). It is not a bug, it is an implementation choice (for efficiency, this reduce the number of objects created ). In the normal usage, you should only consult, add or remove attributes from ComponentContext. You should not modify the attributes obtained from the ComponentContext ! A componentContext is created for each inserted tile. This componentContext is populated from the corresponding definition: the attributes are initialized. Instead of creating a new value for each attribute, we reference the value stored in the definition. If you get it and modify it, the modification will be reflected by all subsequent calls. An attribute value can be any kind of object, even a user defined one. So, it is hard to enforce a read-only API on the attribute value. The only solution is to copy the attribute value each time we use it. This will lead to several object creations. More than 99.9% of the application doesn't need to modify the attributes. So, I don't want to let them pay the price for the 0.01% remaining. These remaining applications can do the attribute copy themselves when needed ;-). An improvement can be done by changing the current attribute definition objects and let them disallow modifications. This can be an improvement request in bugzilla. Cedric Pankaj Dhoolia wrote: Hi, Current implementation of ComponentContext is such that you can make changes to it in such a manner that the base definition cached with the DefinitionFactory will reflect those changes. In effect it is possible to cause global changes for all subsequent requests thru the ComponentContext API. Was this intended or is it a bug, because for the List type attributes ComponentContext lands up having a reference point right in the definition cached in the DefinitionFactory? cheers, pdhoolia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test suites fail on localized computer
Thanks for the fix, it works fine for me now. Cedric James Mitchell wrote: LOLnow this is interesting, supposing I had picked a different localewho knows how long this might have gone undetected. I just changed my regional settings to France and my tests failed as well. I already see the problem and will commit the fix tonight. I forced the locale for the MessageTag tests, but forgot to do the same for WriteTag. -- James Mitchell Software Engineer/Struts Evangelist -Original Message- From: Cedric Dumoulin [mailto:[EMAIL PROTECTED] Sent: mercredi 26 février 2003 11:09 To: Struts Developers List Subject: Test suites fail on localized computer Hi all, Today I have run the test suite test.tomcat.41, but it fail on my computer: [junit] junit.framework.AssertionFailedError: expected:1,234 but was:1Â 234 [junit] at org.apache.struts.taglib.bean.TestWriteTag.formatAndTest(TestW riteTag.java:122) [junit] at org.apache.struts.taglib.bean.TestWriteTag.endWriteTagNameForm at(TestWriteTag.java:153) Checking the code, it appear that we compare a localized string returned by the server with a static string not localized ;-). This should work well when the server is US_en, but doesn't work with FR_fr, and other locales. Note that the shown returned string (1Â 234) is not necessarily the real returned string, because the text file used to catch the output doesn't support well localization. There is other comparisons of this kind in the TestWriteTag file, and maybe in other files. I have try to run ant with other locale parameters, with no success: Tomcat is always launched with the locale of my computer, which I can't change. As a result, I can't run the test suites. Is there someone who have a simple solution, or should we change the TestWriteTag file (how?). cedric - 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]
Test suites fail on localized computer
Hi all, Today I have run the test suite test.tomcat.41, but it fail on my computer: [junit] junit.framework.AssertionFailedError: expected:1,234 but was:1Â 234 [junit] at org.apache.struts.taglib.bean.TestWriteTag.formatAndTest(TestWriteTag.java:122) [junit] at org.apache.struts.taglib.bean.TestWriteTag.endWriteTagNameFormat(TestWriteTag.java:153) Checking the code, it appear that we compare a localized string returned by the server with a static string not localized ;-). This should work well when the server is US_en, but doesn't work with FR_fr, and other locales. Note that the shown returned string (1Â 234) is not necessarily the real returned string, because the text file used to catch the output doesn't support well localization. There is other comparisons of this kind in the TestWriteTag file, and maybe in other files. I have try to run ant with other locale parameters, with no success: Tomcat is always launched with the locale of my computer, which I can't change. As a result, I can't run the test suites. Is there someone who have a simple solution, or should we change the TestWriteTag file (how?). cedric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: David Graham, 1.1 RC1 MVC
+1 Robert S. Sfeir wrote: +1 On Tuesday, Feb 25, 2003, at 09:02 US/Eastern, Ted Husted wrote: While *we all* put a lot of time and effort into getting 1.1 ready for its first release candidate, it seems to me that David Graham really came through for us over the last few weeks (months, even). As a token of our appreciation, I'd like to nominate David for a Most Valuable Committer award in regard to 1.1 RC1. When the going got tough, David got going =:0) +1 -Ted. (I wouldn't do this with every release, since the contribution of every Apache Committer is valuable, but 1.1 has been such a hard road, a special one-time consideration seemed due.) - 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: [VOTE] Struts 1.1 Release Candidate 1 Release Plan
+1 Martin Cooper wrote: All outstanding bugs against Struts 1.1 have either been fixed or been categorized for fixing in a release subsequent to Struts 1.1 Final. Therefore, I propose that we release the tip of the main trunk in CVS as Release Candidate 1 for a Struts 1.1 release. I have checked in a proposed release plan, which is available for review on the Struts web site: http://jakarta.apache.org/struts/proposals/release-plan-1.1rc1.html Release plans must pass by a majority vote of committers on the project, but all other interested parties are welcome to cast their votes (and/or make comments or suggestions on the plan) as well. -- Vote: Struts 1.1-rc1 Release Plan [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- I am +1 on the Struts 1.1-rc1 release plan. -- Martin Cooper - 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: Forcing or replacing a request processor version 1.1 beta3
Hi,
The TilesPlugin set the RequestProcessor to TilesRequestProcessor. It
does it to simplify the way Tiles should be initialized: a user just
need to declare the plugin. Then, the plugin check if the current
RequestProcessor must be changed, or if it is already set by the user.
Cedric
Peter A. Pilgrim wrote:
David Graham wrote:
After a quick glance at the code, I think your solution will work
because it looks like TilesPlugin does the same thing.
David
Ah ha! I will have to look at TilesPlugin as well
to see why it is doing the same thing?
From: Peter A. Pilgrim [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Forcing or replacing a request processor version 1.1 beta3
Date: Wed, 12 Feb 2003 00:52:51 +
David Graham wrote:
Why you don't want to set the RequestProcessor in the
struts-config.xml file?
David
Because I want to distribute Expresso Framework with the custom
request processor as standard. Does that answer the question?
Of course XML config works.
From: Peter A. Pilgrim [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Dev [EMAIL PROTECTED]
Subject: Forcing or replacing a request processor version 1.1 beta3
Date: Wed, 12 Feb 2003 00:02:59 +
Hi
I am looking at the Struts source code. I want to find
out the ActionServlet that is responsible for loading
and setting the RequestProcessor.
I see a ControllerConfig in the utility with the default
org.apache.struts.action.RequestProcessor. Is there
a way of overriding this hard setting programmatical?
I want to create an ActionServlet subclass that will
default to a CustomRequestProcessor without having
to set it in XML config.
Also in the `ActionServlet.initModuleConfig' which
I think is responsible for initialisation all
the module configuration from the XML I was thinking
I could do something like this:
// Parse the configuration for this module
ModuleConfig config = null;
InputStream input = null;
String mapping = null;
try {
//@todo FIXME replace with a FactoryMethod
ModuleConfigFactory factoryObject =
ModuleConfigFactory.createFactory();
config = factoryObject.createModuleConfig(prefix);
ControllerConfig cc =
moduleConfig.getControllerConfig();
if ( cc.getProcessorClass().equals(
org.apache.struts.action.RequestProcessor ) )
cc.setProcessorClass(com.xenonsoft.fire.MyCustomProcessor);
Is this a good idea?
Tia
--
Peter Pilgrim
__ _ _ _
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___/////// + Intrinsic Motivation
On Line Resume
||
\\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Peter Pilgrim
__ _ _ _
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___/////// + Intrinsic Motivation
On Line Resume
||
\\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
-
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: RequestProcessor methods scope
These methods are used by the Tiles subclasses, which are part of Struts ;-) The doc says that methods are not part of the API to prevent regular users to use them. Normally, users only need to overload doInclude() or doForward(). Cedric David Graham wrote: The internalModuleRelativeInclude and internalModuleRelativeForward methods are both protected but their javadoc states, This method is used internally and is not part of the public API. It is advice to not use it in subclasses.. If they aren't part of the subclassing API, then I'll make these methods private because they're part of the Struts implementation only. Dave _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - 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: Tiles XmlParser - cut paste error?
You are right, this is probably a cutpaste error. I have corrected it. Cedric Martin Cooper wrote: Running PMD over the latest code, I think I've found a bug in the Tiles XmlParser class. Lines 255 - 256 of this class look like this: String menuItemDefaultClass = org.apache.struts.tiles.beans.SimpleMenuItem; digester.addObjectCreate( ADD_WILDCARD, menuItemDefaultClass, classtype); But then lines 262 - 263 look like this: String beanDefaultClass = org.apache.struts.tiles.beans.SimpleMenuItem; digester.addObjectCreate( BEAN_TAG, menuItemDefaultClass, classtype); Note that in the first case, menuItemDefaultClass is defined, and then used on the next line. In the second case, beanDefaultClass is defined, but on the next line, menuItemDefaultClass is used again. My guess is that this is a cut paste error, and that line 263 should be using beanDefaultClass instead of menuItemDefaultClass. However, this is a guess, since I don't use this functionality. Hence this message instead of just changing the code base. If someone who knows this area could take a look and confirm/deny, that would be great. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tiles:put and put tag
Hi, But where do you declare objects in the config file ? If we enable someting like beanName=someBean in the config file, where does the bean should come from ? Cedric Frank Kim wrote: I have a quick question regarding the difference in terms of functionality between put tag and tiles:put tag, with tiles:put tag, you can pass objects through beanName attribute example: foo.jsp jsp:useBean .. name=someBean/ tiles:insert definition=bar tiles:put name=list beanName=somebean/ However with the put tag, you can only pass string, page, template or definitions. Is there a good reason for this difference? The only way to pass objects in separate XML file is through the putList tag, which baffles me since there might be instances where I want to define a simle attribute to contain an Object, is there a plan to create something like: definition name=foo.bar putObject name=topMenuItem type=org.apache.struts.tiles.beans.SimpleMenuItem value=Click me link=foo.bar/ .. Thanks in advance. Frank -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TilesRequestProcessor in non-Tiles applications
Can you post this as an enhancement request in bugzilla ? Goal: be able to use the TilesRequestProcessor even if it not initialized from the TilesPlugin. Cedric Heydtmann, Dirk [PCS] wrote: Hello: We would like to propose making the TilesRequestProcessor tolerant to where it does not choke on a regular (non-Tiles) application. Actually, the TilesRequestProcessor already sort of supports this, but not entirely. Background: In our company we have a legacy MVC framework that now wraps around Struts 1.1, and this legacy framework has its own request processor that needs to extend either the TilesRequestProcessor or the standard Struts RequestProcessor. Since we would like to keep things simple and do not want to duplicate our code, we want to extend just one request processor class, not both. That is why we decided to extend the TilesRequestProcessor and have our request processor be used for both Tiles and non-Tiles apps. Below are the two issues we ran into using this approach with Struts 1.1 beta 3, and how we worked around them. Issue 1: TilesRequestProcessor expects the TilesUtil implementation of type TilesUtilStrutsImpl. But unless there is a TilesPlugin configured, nobody sets this implementation. Workaround: we extended the ActionServlet and in its init() we are explicitly setting the implementation with TilesUtil.setTilesUtil(new TilesUtilStrutsImpl()); Issue 2: TilesRequestProcessor's initDefinitionsMapping() logs an error, if a DefinitionsFactory has not been set, i.e. if the TilesPlugin has not been configured. Workaround: non needed, this is just a nuisance. The TilesRequestProcessor still works OK. Thoughts? Dirk Heydtmann Sprint PCS - CAM Architecture (913) 794-4671 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Proposed New Committer: James Turner
+1 Cedric Craig R. McClanahan wrote: James Turner has been a long-time contributor of patches to Struts, took over commons-validator when it was languishing (he's a committer there), and is the author of Struts Kick Start. I'd like to propose him as a committer on Struts as well. Here's my +1. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Switching Modules - isn't working for me...
Does someone have a simple example war file reproducing the problem ? If yes, could you send it to me ? Cedric Matt Raible wrote: I tried switching to last night's build, but that appears to be even worse - I can't even use the default module. I get the following error the first time (and all other times) I hit an action: - Root Cause - java.lang.AbstractMethodError at org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.j ava:1096) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:470) at javax.servlet.GenericServlet.init(GenericServlet.java:256) My log file never shows any modules getting initialized (save ''). The last build I had, from 11-24, the default app worked, just the switching didn't. Are there any sample applications I can prove this works against? Thanks, Matt -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Friday, December 27, 2002 1:37 AM To: '[EMAIL PROTECTED]' Subject: Switching Modules - isn't working for me... It's late, so it's possible my problem is something small and I just need a second set of eyes on it. I am trying to configure my application have an upload module. I'm following the instructions at http://jakarta.apache.org/struts/userGuide/configuration.html# module_config-switching. In my global-forwards, I have the following forward: !-- Switch to upload sub-application -- forward name=uploadResume contextRelative=true path=/upload/index.do redirect=true / I have my ActionServlet configured as follows: init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-nameconfig/upload/param-name param-value/WEB-INF/struts-upload.xml/param-value /init-param And struts-upload.xml has the following action-mappings: !-- Router to upload tiles definition -- action path=/index type=org.apache.struts.actions.ForwardAction parameter=upload/ !-- Upload Action -- actionpath=/uploadFile type=org.appfuse.webapp.actions.UploadAction name=uploadForm scope=request input=upload forward name=success path=display / /action Where upload and display are tiles definitions. When I try to access this forward (either via link or direct URL), I get: Tomcat 404: The requested resource (/appfuse/upload) is not available. And in the log file: INFO [Thread-4] [org.apache.struts.util.PropertyMessageResources] PropertyMessageResources.init(127) | Initializing, c onfig='com.fgm.web.menu.displayer.DisplayerStrings', returnNull=true INFO [Thread-4] [org.apache.struts.tiles.TilesRequestProcessor] TilesRequestProcessor.initDefinitionsMapping(154) | Tile s definition factory found for request processor '/upload'. INFO [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.process(225) | Processing a 'GET' for path '/index' DEBUG [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.processActionCreate(305) | Looking for Ac tion instance for class org.apache.struts.actions.ForwardAction DEBUG [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.processActionCreate(321) | Creating new Action instance DEBUG [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.processForwardConfig(428) | processForward Config(ForwardConfig[name=null,path=upload,redirect=false,cont extRelative=true]) Any ideas? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Switching Modules - isn't working for me...
Hi, For me it sound like a binary version problem. Maybe one of your plugin has been compiled with an older and incompatible jar file. The tiles-documentation.war file use modules and tiles (module default, example, test). It works on my configuration. Hope this help, Cedric Matt Raible wrote: I tried switching to last night's build, but that appears to be even worse - I can't even use the default module. I get the following error the first time (and all other times) I hit an action: - Root Cause - java.lang.AbstractMethodError at org.apache.struts.action.ActionServlet.initModulePlugIns(ActionServlet.j ava:1096) at org.apache.struts.action.ActionServlet.init(ActionServlet.java:470) at javax.servlet.GenericServlet.init(GenericServlet.java:256) My log file never shows any modules getting initialized (save ''). The last build I had, from 11-24, the default app worked, just the switching didn't. Are there any sample applications I can prove this works against? Thanks, Matt -Original Message- From: Matt Raible [mailto:[EMAIL PROTECTED]] Sent: Friday, December 27, 2002 1:37 AM To: '[EMAIL PROTECTED]' Subject: Switching Modules - isn't working for me... It's late, so it's possible my problem is something small and I just need a second set of eyes on it. I am trying to configure my application have an upload module. I'm following the instructions at http://jakarta.apache.org/struts/userGuide/configuration.html# module_config-switching. In my global-forwards, I have the following forward: !-- Switch to upload sub-application -- forward name=uploadResume contextRelative=true path=/upload/index.do redirect=true / I have my ActionServlet configured as follows: init-param param-nameconfig/param-name param-value/WEB-INF/struts-config.xml/param-value /init-param init-param param-nameconfig/upload/param-name param-value/WEB-INF/struts-upload.xml/param-value /init-param And struts-upload.xml has the following action-mappings: !-- Router to upload tiles definition -- action path=/index type=org.apache.struts.actions.ForwardAction parameter=upload/ !-- Upload Action -- actionpath=/uploadFile type=org.appfuse.webapp.actions.UploadAction name=uploadForm scope=request input=upload forward name=success path=display / /action Where upload and display are tiles definitions. When I try to access this forward (either via link or direct URL), I get: Tomcat 404: The requested resource (/appfuse/upload) is not available. And in the log file: INFO [Thread-4] [org.apache.struts.util.PropertyMessageResources] PropertyMessageResources.init(127) | Initializing, c onfig='com.fgm.web.menu.displayer.DisplayerStrings', returnNull=true INFO [Thread-4] [org.apache.struts.tiles.TilesRequestProcessor] TilesRequestProcessor.initDefinitionsMapping(154) | Tile s definition factory found for request processor '/upload'. INFO [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.process(225) | Processing a 'GET' for path '/index' DEBUG [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.processActionCreate(305) | Looking for Ac tion instance for class org.apache.struts.actions.ForwardAction DEBUG [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.processActionCreate(321) | Creating new Action instance DEBUG [Thread-4] [org.apache.struts.action.RequestProcessor] RequestProcessor.processForwardConfig(428) | processForward Config(ForwardConfig[name=null,path=upload,redirect=false,cont extRelative=true]) Any ideas? Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
+1 Cedric Martin Cooper wrote: A number of new features have been added to Struts since the 1.1 Beta 2 release, and many bugs have been fixed. Therefore, I propose that we release the tip of the main trunk in CVS as Beta 3 for a Struts 1.1 release. I have checked in a proposed release plan, revised from the previous version, which is available for review on the Struts web site: http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html Release plans must pass by a majority vote of committers on the project, but all other interested parties are welcome to cast their votes (and/or make comments or suggestions on the plan) as well. -- Vote: Struts 1.1b3 Release Plan [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable tohelp support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- I am +1 on the Struts 1.1b3 release plan. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Avoid code reformating !
Hi everybody, Code formating is an ever ending debate. We, as experienced developers, all have our preferences. When there is several users as in Struts, there is a polite rule: do not reformate code of others just because they don't follow your criteria. I have discover such reformating in code that I have written. The problem is that I don't recognize the code anymore, it takes me more time to do something, and comparisons tools can't work anymore ;-( I don't want to debate about the right or the best code formating. I just ask for the respect of each others. So, for those having an automatic code formatter, please disable it when playing with struts code, and resist to the tentation ;-) Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Avoid code reformating !
I said that I don't want to debate on this. I know the reformated code doesn't follow the recomanded Jakarta rules code standard. But another rule is to respect any other well formated standard ;-). For me, the reformated code is really unreadable: I can't detect the classes and methods structures at a glance, and so it requires me some times to try to figure it out. I thing it is a waste of time ... Cedric David Graham wrote: With all due respect Cedric, that code did not follow the java standard coding guidelines so it was a candidate for reformatting. Under the Jakarta rules code must meet those guidelines unless specified differently for the project. AFAIK Struts has no specific rules so it defaults to the java standard. Following the java standard helps all developers work on the project faster and easier. Dave From: Cedric Dumoulin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Avoid code reformating ! Date: Mon, 16 Dec 2002 22:09:22 +0100 Hi everybody, Code formating is an ever ending debate. We, as experienced developers, all have our preferences. When there is several users as in Struts, there is a polite rule: do not reformate code of others just because they don't follow your criteria. I have discover such reformating in code that I have written. The problem is that I don't recognize the code anymore, it takes me more time to do something, and comparisons tools can't work anymore ;-( I don't want to debate about the right or the best code formating. I just ask for the respect of each others. So, for those having an automatic code formatter, please disable it when playing with struts code, and resist to the tentation ;-) Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan
I am in favor of this release plan, except for the date ;-). I prefer a date after this week-end. This will allow me to do some works. Cedric Martin Cooper wrote: A number of new features have been added to Struts since the 1.1 Beta 2 release, and many bugs have been fixed. Therefore, I propose that we release the tip of the main trunk in CVS as Beta 3 for a Struts 1.1 release. I have checked in a proposed release plan, which is available for review on the Struts web site: http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html Release plans must pass by a majority vote of committers on the project, but all other interested parties are welcome to cast their votes (and/or make comments or suggestions on the plan) as well. -- Vote: Struts 1.1b3 Release Plan [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- I am +1 on the Struts 1.1b3 release plan. -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: question about tiles:useAttribute bugfix
Hi,
You are right, it should be reopened.
Cedric
Anand Joshi wrote:
hi Cedric,
I can open defect against this bug. But I feel since this bug was reported
earlier, wouldn't it be nice to reopen earlier bug fix report?
As this bug was already reported and happened to be fixed under 2002/10/7
build.
Thanks
Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]
Cedric Dumoulin
[EMAIL PROTECTED]To: Struts Developers List [EMAIL PROTECTED]
g cc:
Subject: Re: question about tiles:useAttribute
11/04/2002 04:24
AM
Please respond to
Struts
Developers List
Can you open a ticket in bugzilla reporting this bug. Don't forget to
specify the faulty configuration (web server(s), struts release(s), ...)
Thanks,
Cedric
Anand Joshi wrote:
hi Cedric,
I took nightly build 1031 and extracted struts.jar from it But
unfortunately it did not solve problem.
Thanks for your prompt attention!
Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]
Cedric Dumoulin
[EMAIL PROTECTED]To: Struts Developers
List [EMAIL PROTECTED]
g cc:
Subject: Re: question
about tiles:useAttribute
10/29/2002 04:32
AM
Please respond to
Struts
Developers List
Hi,
This is a bug in struts1.1b2 when used with web server doing reuse of
tags. The required behavior of tiles:useAttribute name=aName is to
use the name as id when id is not provided. This bug has been corrected
in nightly build since 2002/10/7 .
Can you try with the nightly build to check if it solve your problem ?
Cedric
Anand Joshi wrote:
hi All,
I had used tiles:useAttribute in struts 1.0.2 where tiles was separate.
It
used to work even without attribute id.
Now in struts 1.1b2 release,I have to give id attribute otherwise tag
does
not work. specifcally it gives nullPointerException.
ie: this line tiles:useAttribute name=idColumn
classname=java.lang.String / : cause exception.
while tiles:useAttribute id=idColumn name=idColumn
classname=java.lang.String / works fine.
Taglib reference does not list id as required attribute. So I am confused
for its usage. I am simply adding id={same value as name}
for all occurances of tiles:useAttribute for porting my webApp to
struts1.1b2.
Can you explain rationale behind making id as required attribute?
Any help will be greatly appreciated.
Thanks
Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help
Tiles and modules
I have committed changes to allow tiles factory to be module aware. For now, each module have its own definition factory, and tags should be able to found the appropriate factory. It is possible to specify the same config file for different factories. Actually the tiles config files should contain paths relative to the main context. I will add the ability to specify paths relative to the module context asap. There is already hooks for that, but more should be provided. I will do it asap (but I won't be able to do anything before the 18th nov.). Cedric -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: question about tiles:useAttribute
Can you open a ticket in bugzilla reporting this bug. Don't forget to
specify the faulty configuration (web server(s), struts release(s), ...)
Thanks,
Cedric
Anand Joshi wrote:
hi Cedric,
I took nightly build 1031 and extracted struts.jar from it But
unfortunately it did not solve problem.
Thanks for your prompt attention!
Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]
Cedric Dumoulin
[EMAIL PROTECTED]To: Struts Developers List [EMAIL PROTECTED]
g cc:
Subject: Re: question about tiles:useAttribute
10/29/2002 04:32
AM
Please respond to
Struts
Developers List
Hi,
This is a bug in struts1.1b2 when used with web server doing reuse of
tags. The required behavior of tiles:useAttribute name=aName is to
use the name as id when id is not provided. This bug has been corrected
in nightly build since 2002/10/7 .
Can you try with the nightly build to check if it solve your problem ?
Cedric
Anand Joshi wrote:
hi All,
I had used tiles:useAttribute in struts 1.0.2 where tiles was separate. It
used to work even without attribute id.
Now in struts 1.1b2 release,I have to give id attribute otherwise tag does
not work. specifcally it gives nullPointerException.
ie: this line tiles:useAttribute name=idColumn
classname=java.lang.String / : cause exception.
while tiles:useAttribute id=idColumn name=idColumn
classname=java.lang.String / works fine.
Taglib reference does not list id as required attribute. So I am confused
for its usage. I am simply adding id={same value as name}
for all occurances of tiles:useAttribute for porting my webApp to
struts1.1b2.
Can you explain rationale behind making id as required attribute?
Any help will be greatly appreciated.
Thanks
Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: question about tiles:useAttribute
Hi,
This is a bug in struts1.1b2 when used with web server doing reuse of
tags. The required behavior of tiles:useAttribute name=aName is to
use the name as id when id is not provided. This bug has been corrected
in nightly build since 2002/10/7 .
Can you try with the nightly build to check if it solve your problem ?
Cedric
Anand Joshi wrote:
hi All,
I had used tiles:useAttribute in struts 1.0.2 where tiles was separate. It
used to work even without attribute id.
Now in struts 1.1b2 release,I have to give id attribute otherwise tag does
not work. specifcally it gives nullPointerException.
ie: this line tiles:useAttribute name=idColumn
classname=java.lang.String / : cause exception.
while tiles:useAttribute id=idColumn name=idColumn
classname=java.lang.String / works fine.
Taglib reference does not list id as required attribute. So I am confused
for its usage. I am simply adding id={same value as name}
for all occurances of tiles:useAttribute for porting my webApp to
struts1.1b2.
Can you explain rationale behind making id as required attribute?
Any help will be greatly appreciated.
Thanks
Anand Joshi
Websphere Development Team
Ph: 919-254-4331 (Tie 444-4331)
mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] James Mitchell as Struts Committer
+1 Ted Husted wrote: James Mitchell has been a long-time contributor of good ideas as well as patches on the developer list. He is also generous with his help on the user list. I believe it's time that we nominated James as a Committer. After all, we can always use another Evangelist. Here's my +1 -Ted. -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: Tiles Refactorings for 1.1 compatability
It will be a proposal for a common tiles/templates taglib intended to be included in JSTL. But this can't happen before a JSTL2.x release. So, you can continue to use your favorite Tiles framework, we will continue to support it for a long time ;-). Cedric Byrne, Steven wrote: What I meant was essentially tiles-el, which is what I thought this message from Cedric was referring to: Martin Cooper wrote: Meanwhile, David Geary, who was the original author of the template library, went on to develop the Regions library, which he describes in his book, Advanced JavaServer Pages. At one point, there was some discussion of David and Cedric working together to combine the best of Regions and Tiles, but as far as I'm aware, nothing came of that. We, David and me, are in contact. We should soon start working on a common proposal for a next major version of JSTL. -Original Message- From: Karr, David [mailto:david.karr;attws.com] Sent: Thursday, October 17, 2002 11:50 AM To: 'Struts Developers List' Subject: RE: Tiles Refactorings for 1.1 compatability -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Thursday, October 17, 2002 11:29 AM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Byrne, Steven wrote: Here's the draft roadmap that I wrote up. Struts 1.2 January 2003 [duration: 2 months? ] * tiles JSTL aware ? What is the problem with Tiles' JSTL awareness? At the least, I would assume this refers to the fact that there is no tiles-el library yet. If that's all that means, I don't expect any problem with building a tiles-el sublibrary by the January timeframe (not to mention nested-el, or any other existing sub-libraries). -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: template status
Martin Cooper wrote: Meanwhile, David Geary, who was the original author of the template library, went on to develop the Regions library, which he describes in his book, Advanced JavaServer Pages. At one point, there was some discussion of David and Cedric working together to combine the best of Regions and Tiles, but as far as I'm aware, nothing came of that. We, David and me, are in contact. We should soon start working on a common proposal for a next major version of JSTL. At this point, the template library is really only meaningful for backwards compatibility. Tiles is the focus, going forward. My understanding is that the degree of compatibility between the two is such that simply changing the taglib directive at the top of a JSP page to reference Tiles instead of template is all that is needed to switch over to Tiles. Right, you can use Tiles in place of Templates by simply changing the taglib directive. Cedric -- Martin Cooper -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Wednesday, October 16, 2002 8:09 PM To: [EMAIL PROTECTED] Subject: template status What's the deal with the struts template library? I haven't used it but it seems to have many features that Tiles has. Tiles seems more developed however. Are there any plans for template? Dave _ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Hi Eddie, Eddie Bush wrote: Cedric, I wasn't trying to step on toes :-) I can't say how much more I'd prefer you refactor Tiles than me. You (obviously) are a *lot* more familiar with it's inner workings! The point to keep in mind though is that 1.1 *is* about seperatism. If you have a strong separation between modules with Tiles, you go against the Tiles philosophy (share to reuse, to reduce maintenance, ...). If you do strong separation, you will be consistent with the module philosophy, but you will be inconsistent with the Tiles one. So, peoples using Tiles will not use modules because they will loose one of its main advantage. So, we need a way to conciliate both philosophy. My idea was to have one Tiles factory per module, and to have a syntax allowing cross references between module namespaces (for URL). Also, a same tiles config file could be used by several factories, allowing some commons basic definitions. This later requirement bring some problems: the shared config file namespace is not the same depending on the loading module. In this case, how to specify URLs in a way consistent to module philosophy ? Should we mark all as contextRelative=false ? If yes, what will happen if the module name change ? This is such little things that need to be solved in order to propose a consistent behavior. After that, it will be more easy to implement something ! Would it, in your opinion, require undoing changes made in 1.1 to enforce seperatism to achieve a better affect in 1.2? I like your intent, I believe, very much. 1.2 is really the target for making modules work together though - that should be it's primary focus. The Tiles goal of sharing common pages should be maintained in 1.1. The module goal is to let separate teams work independently on different modules. In this context, Tiles should combine both goals. If you're working on resolving this I'll just bow out and let you have it :-) Please let me know. I'm still reviewing the code to make absolutely sure I know what I'm doing before I go to changing anything, and I'd hate to be throwing wasted time into the effort - especially when a much more competent person is at hand. Your help is welcome. Also, someone else than me with a very well understanding of the Tiles philosophy and its current implementation is more than welcome. But, please, don't forget to expose your intention to other commiters before making heavy changes. The best is to describe your goals, your expected behavior, and maybe a simple example of use. Only after that you can propose an implementation. Cedric -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Eddie Bush wrote: Hi again, Cedric :-) We need to hurry 1.1, and the only way I see to do that is for each of us to agree to seperatism in 1.1 - understanding and *expecting* that 1.2 will be our chance to solve the problems we wanted to solve in 1.1 but couldn't (because of time). I am sorry, but I still disagree on the separatism point ;-). Or maybe we don't understand the same thing by separatism. Tiles is a framework to share common piece of work. You can't say now: Tiles allow to share work, but you still have to duplicate when you use module ! The Ted's proposal is a good starting point. We need now to check if it fulfill simple needs, and if there is no incompatibility with complex cases. I will check that with existing applications. Implementing it doesn't seem too complicated. Cedric -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [VOTE] How should Tiles be refactored?How
Eddie Bush wrote: Cast your vote. [ -1] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ -1 ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. Here are some key benefits of Tiles: * Allows consistent look and feel across all your pages * Allows modification of this look and feel in one single central point * Avoids duplication of common files (common layout, headers, footers, menu, ...) If there one independent configuration for each module, you loose all these functionalities. This would be a regression. [ 0] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ 1] I want tiles to have a different configuration (Elaborate). In fact, I have already think about how to make Tiles more modules/sub-apps compliant. I haven't solved this question, because there is some opposite views: modules are intended to clearly separate works (the Ted's chinese wall), and Tiles are intended to avoid duplications by allowing sharing of common jsp. Of course, we can conciliate both, but this require some thinking: * A tiles configuration file requires some references to common URLs and to common definitions. o How to distinguish between an URL from the module namespace and an URL from another namespace (common, root or other module), without overloading too much the configuration file ? o The same for definitions * We can think of a module containing all commons files (tiles, layouts, definitions). How to reference these entities from other modules ? * Each modules will certainly share a set of common tiles configurations. How to do that without replications ? So what we need now is to specify what could be the Tiles syntax and how it will be used in the context of modules. After that it will be possible to make tiles modules compliant. Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
No reason, I think we (you ;-) ) can close this bug with the proposed solution. For the NoOpAction, we can deprecate it and maybe let it extends the ForwardAction. Cedric Eddie Bush wrote: Yes, I've seen that bug. I'll take a look at it. Does anyone have a valid reason why this shouldn't be done? David Graham wrote: Eddie, Can you take a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12309 It relates to tiles and 1.1. I'd like to get your thoughts on it. Sorry, this didn't really answer your question. Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles Refactorings for 1.1 compatability
There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. What are you thoughts to make Tiles more module aware ? Actually there is one common factory for all modules. It is possible to propose a solution with one factory for each modules, but users often want to have a way to define definitions common to all modules, like the definition defining the site main layout. So we surely need to propose a way to achieve this (common definitions + module definitions). I am open to any suggestion. Cedric Eddie Bush wrote: I've been looking over Tiles - specifically at how to make it be 1.1-compliant wrt modules and not trampling on itself cringe/. After doing some greps here and there to try to figure things out, it occurred to me someone might have a diagram of how things are done. I can read UML fairly well, so that would be ideal. Any UML diagrams of Tiles? Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Build has 2 tiles dtds
The tiles-config.dtd file is the old dtd, with no comments. The tiles-config_1_1.dtd file is the new improved dtd with comments. They both describe exactly the same syntax for Tiles config files. My primary goal was to remove the old version, but I have forget to do it in the CVS repository. Normally, the Tiles digester is configured to use the new dtd even if you specify the old one. Another thing: the new dtd is not yet visible on the following URL: http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd I think that someone should make it available (Craig ?) Cedric Martin Cooper wrote: I assume you're referring to tiles-config.dtd and tiles-config_1_1.dtd. My understanding is that they are *supposed* to be the same. The suggestion was to rename tiles-config.dtd so that it contained the version number in the file name, as with struts-config_1_1.dtd. However, a separate file was created for backwards compatibility with the old file name. Apparently, though, the two files are *not* the same. The newer one is tiles-config_1_1.dtd. Hopefully Cedric can fill us in on the differences. -- Martin Cooper -Original Message- From: V. Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 9:27 AM To: [EMAIL PROTECTED] Subject: Build has 2 tiles dtds (I know I shouuld put in bugzila ) but it's a build. There is tiles.dtd and tiles1.1.dtd in nighly build. I assume tiles.dtd. is the older one. .V -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tiles UseAttributeTag.java
The jsp spec said that a jsp tag handler should not change tag
attribute values. This is to allow tag reuse without setting again the
tag attributes.
Previous versions of Tomcat was not reuse tags, but latest version do !
In the previous implementation of UseAttributeTag, the id attribute
was set by the handler if it was not defined. Next call (reuse) to the
handler only set name, and found the id set to a wrong value.
The new implementation doesn't touch any tag attribute values.
I don't know if id should be reseted in base class release(). The
fact that it is not was causing trouble to some container doing reuse.
I haven't found any comment about that in spec when I had corrected this
old bug. Maybe someone has more info ?
Cedric
Karr, David wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 8:44 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-struts/src/share/org/apache/struts/taglib/tiles
UseAttributeTag.java
Log:
Correct a bug where the property id is not set properly
when the tag is reused.
public int doStartTag() throws JspException
{
+ // Do a local copy of id
+String id=this.id;
if( id==null )
id=attributeName;
Would you mind elaborating on this a bit, Cedric? Why do you need to to do
this?
I also noticed that the release() method is resetting the id field,
apparently due to a bug in TagSupport? Is this really a bug in the base JSP
api?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles PlugIn - invalid use of set-property
Hi, Tiles plug-in accept both syntaxes: the one following bean convention (debugLevel), and the one with dash separation (definitions-debug). The dash separated syntax is left for backward compatibility. The bean convention syntax is not documented ;-(. Here is the correspondence: * definitions-parser-details parserDebugLevel * definitions-parser-validate parserValidate * definitions-factory-classfactoryClassname * definitions-config definitionConfigFiles * definitions-debugdebugLevel You can fill a bug report for the missing documentation if you wish, or better, join an attachment with appropriate documentation ;-) Cedric Bill Willis wrote: Mornin' In the tiles-documentation example (version 1.3, dated 19 July 2002 -- http://cvs.apache.org/viewcvs/jakarta-struts/web/tiles-documentation/WEB -INF/struts-config.xml) the Tiles plug-in appears as follows: plug-in className=org.apache.struts.tiles.TilesPlugin set-property property=definitions-config value=/WEB-INF/tiles-defs.xml, /WEB-INF/tiles-tests-defs.xml,/WEB-INF/tiles-tutorial-defs.xml, /WEB-INF/tiles-examples-defs.xml / set-property property=definitions-debug value=1 / set-property property=definitions-parser-details value=0 / set-property property=definitions-parser-validate value=true / /plug-in You will note that the property attribute of each set-property contains a dash (-), disqualifying it as a PropName, which ... is the name of a JavaBeans property, and must begin with a lower case letter and contain only characters that are legal in a Java identifier. Thus the set-property naming convention for the tiles plug-in appears to violate the terms of the Struts DTD. Should I file a bug report for Tiles or the Struts DTD on this one? Regards, Bill -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The state of 1.1 Beta 2
For the tiles-documentation, it will be an issue for the 1.1 final release. I am not sure it is for a b2 release. I will correct it asap, but I don't know when I will find enough time to do it. As again, any help and patches are welcomes ;-). Cedric Martin Cooper wrote: The CVS tree was tagged on Saturday night, per the release plan, and I have a build from that code base ready to be uploaded to the web site. (The CVS tree for corresponding Commons and Commons Sandbox components was also tagged.) However, in my testing, I uncovered some issues that I wanted to mention before making the build available, in case any of the committers think we should hold Beta 2 until they are resolved. So, here's what I found. Unit Tests == The JUnit tests, and tests against Tomcat 4.0.4, passed. However, tests against Tomcat 3.2.4 failed. The reason appears to be a class loader bug in that version of Tomcat. Note that the release plan does not call for working with Tomcat 3.2.4, although we have unit tests for that environment. Sample Webapps == I tested with the following containers: * Tomcat versions 3.2.4, 3.3.1, 3.3.2-dev, 4.0.4 * Resin versions 1.2.10, 2.1.2, 2.1.4 Because of the apparent class loader bug noted above, I did little testing with Tomcat 3.2.4 beyond confirming that the example webapp fails in the same way as the unit tests. In addition, test results for Tomcat 3.3.1 and 3.3.2-dev appeared identical, as did the results from Resin 2.1.2 and 2.1.4. Here are the issues I found. All containers -- * The struts-blank webapp does not work in any of the tested containers. The issue is related to message resources not being found. Apparently, this webapp has two separate resource files, although only one is configured in the Struts config file. This just needs someone to expend a little TLC to put it back into working order. * The tiles-documentation webapp has several broken links in the main navigation bar. The includes are failing because they are referencing non-existent files. (Only Resin provided the information about which files it was looking for and failing to find.) The four links I found that were broken were to the tutorial, installation, user guide and Javadocs. Tomcat 3.3.1 and 3.3.2-dev -- * The html:cookie test throws an exception because a method being accessed is not public. Given that all other containers pass this test, I suspect that this is a bug in these versions of Tomcat, but I have not investigated this further. * The Comparison Tags test fails rather dramatically, with a JVM error shutting down the container, and complaining about a problematic thread. This happened both with JDK 1.4.0_01 and with JDK 1.3.1_01. I don't know whether this is a JVM bug exposed only by Tomcat 3.3.x, or a Tomcat 3.3.x bug, or something else. It seems unlikely to be a Struts bug. All versions of Resin - * The html:cookie test shows null in the Correct Value column, while the Test Result column shows a missing table cell. In contrast, all versions of Tomcat show a missing table cell in the Correct Value column. I have not investigated this further. Resin 2.1.2 and 2.1.4 - * The struts-example webapp seems to keep losing the session id, so that any time you try to edit your registration data, you are taken to the logon page again, even if you just finished logging on. I suspect that this is a Resin bug, given some of the recent comments on the Resin mailing list, but it's possible that this is a tag handler reuse issue with the example webapp. I have not investigated this further. Conclusion == Although there are some nasty problems described above, many of them appear to be container specific. Those that are not, such as the bugs in struts-blank and tiles-documentation, are not, in my opinion, sufficiently severe to warrant holding up a Beta 2 release, although they certainly need to be fixed before a 1.1 Final release. My recommendation, therefore, is to proceed with the Beta 2 release, based on the current tagged code base, and to resolve the Struts related issues described above shortly thereafter. Comments? -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Tiles] DTD IDs
Hi, +1 for both: submitting the patch and opening a bug report. I will do the rest ;-) Cedric Martin Cooper wrote: Sounds like a good idea to me. However, rather than submitting an updated copy of the DTD, what I would suggest is that you open a bug report at Bugzilla, and add a patch as an attachment. The process is described here: http://jakarta.apache.org/site/bugs.html Thanks! -- Martin Cooper -Original Message- From: Bill Willis [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 6:37 AM To: [EMAIL PROTECTED] Subject: [Tiles] DTD IDs Hello all, It would be nice to have ID attributes added to at least some of the Tiles elements. This would be similar to the Struts DTD. ID fields are very helpful to tools. Any plans to add these? If I add them myself and submit a revised DTD, is there a good chance of getting it committed? The same may be true for the Validator DTD (such that it is), but I will leave that for a separate post. Regards, Bill -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [BUG] html:link forward does not add servlet context correctly
Hello, This bug should be solved again. Check the o.a.s.until.RequestUtils class if you can't wait untill next nightly build. Cedric Matt Raible wrote: Any hints for fixing this in the nightly build? I'd like to fix it myself, rather than waiting for tonight's build. http://issues.apache.org/bugzilla/show_bug.cgi?id=10534 Thanks, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/actionActionServlet.java
I am also in favor of using namespaces. Struts tags can use the default namespace (no prefix), and custom tags use their own namespace. Checking the Digester documentation, it appears it support namespaces, and you can associate a RuleSet to a namespace. Normally, namespaces should also work with DTD, ensuring proper validation (or did I miss something ?) In fact, I think of using namespaces in struts-config to allow inline declaration of a Tiles definitions inside a forward. Regarding some previous mails I think it is a similar requirement than for the transform tag. So, we should certainly propose a common and general solution for this kind of extension. I will try to play a little bit more with namespaces, digester and user configurable files ;-). Cedric [EMAIL PROTECTED] wrote: An alternative may be to define a namespace for the struts tags and provide others an opportunity to mix tags in the files. For example - it may be possible to have something like: --- struts:form-beans struts:form-bean name=testbean type=org.apache.struts.webapp.exercise.TestBean/ /struts:form-beans struts:AppTag myapp:myTag myAttrib=myValue / /struts:AppTag -- or something similar. The idea I'm attempting to demonstrate would be allowing the struts tags to still be validated as they are namespace qualified. The struts:AppTag idea is the creation of a special struts-config.xml tag that allows application specific tags (qualified by their own namespaces) to be embedded in a predictible place. In reality it may be possible to accomplish mixing tags and retaining validation even without the use of a special struts:AppTag tag. It should be a requirement, though, that struts-config.xml files not contain the namespace qualifiers to ensure backward compatibility. Craig R. McClanahan [EMAIL PROTECTED] on 07/23/2002 09:21:59 PM Please respond to Struts Developers List [EMAIL PROTECTED] To:Struts Developers List [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java On Tue, 23 Jul 2002, Martin Cooper wrote: Date: Tue, 23 Jul 2002 17:46:20 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionServlet.java Well that's kinda interesting. ;-) Since the use of custom additions to the config file will cause validation against the DTD to fail, should we deliberately turn off validation if this option is being used (i.e. ignore the value of the 'validating' init param and always treat it as false)? I'm having conversations with the Stxx guys about exactly this issue. They really really really want to be able to run on top of a stock 1.1 release, and I'd like to see if we can accomodate that. Right now, turning off validation has been disabled because we rely on some of the default values (so that we can avoid references to Action.X constants in the config classes, to help keep them serializable yadda yadda). There are alternatives to this that I'm looking into -- like copying all the manifest constants into an org.apache.struts.Constants file and having Action.X refer to those for backwards compatibility. Even if we have to keep validation, there are some (unpleasant but usable) options, like maintaining a separate DTD that was a superset of the standard one. What I'd really like to find is a way that an existing DTD can be extended (say, add the transform element nested inside a forward that the Stxx guys want) without having to start from scratch. Any ideas? -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles as a Plug-In
It is true. I have updated the documentation in cvs, but jakarta site doesn't reflect it ;-(. I think that Jakarta site is not automatically updated. However, the documentation from struts-documentation.war should shows the new syntax: In each struts-config.xml: plug-in className=org.apache.struts.tiles.TilesPlugin set-property property=definitions-config value=/WEB-INF/tiles-defs.xml, /WEB-INF/tiles-tests-defs.xml,/WEB-INF/tiles-tutorial-defs.xml, /WEB-INF/tiles-examples-defs.xml / set-property property=definitions-debug value=1 / set-property property=definitions-parser-details value=0 / set-property property=definitions-parser-validate value=true / /plug-in You can remove the ActionComponentServlet and the TilesRequestProcessor declaration. The old methods to enable Tiles still working for backward compatibilities. Another modification is renaming tiles.tld to struts-tiles.tld. You will need to change the file name in all your files, or specify a mapping in the web.xml file: taglib taglib-uri/WEB-INF/tiles.tld/taglib-uri taglib-location/WEB-INF/struts-tiles.tld/taglib-location /taglib Cedric Matt Raible wrote: I'm trying to upgrade to last night's nightly build. In tiles-documentation.war (the only tiles webapp I saw) the following is no longer applicable: controller processorClass=org.apache.struts.tiles.TilesRequestProcessor / Is this true? Please confirm. Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tiles and modules (sub-apps)
Hi all, There is now a TilesPlugin for struts1.1. This plugin takes in charge the TilesRequestProcessor initialization. It is not anymore mandatory to specify the TilesRequestProcessor. Also, it is not needed anymore to use the ComponentActionServlet as servlet. You can just use the Struts servlet. The new plugin and TilesRequestProcessor work with struts multi modules (sub-applications). The tiles documentation uses one module called examples. Check the tiles-documentation.war file for how to. Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Factorize request dispatch processing (in one single processActionForward(...))
Hi,
In order to solve some problems encountered with Tiles and multi
modules, I have tried to formalize what is the workflow of an incoming
request sent to an action.
Ideally, it should be (from a very high level point of view):
http://action.do
|
V
request preprocessing (populate formbean, validate, ...)
|
V
struts action call
|
V
request dispatch (usually to a view rendering page)
In Struts, the request dispatch block usually takes an ActionForward
as parameter and forward to requested URI. This is done in the
RequestProcessor.processActionForward(...) method.
Formalizing this workflow help to explain how Tiles fit in it. Tiles
are mainly rendering views. A tiles can be inserted by using its logical
names (the definition name) as URI in an actionForward, or anywhere a
path URI could takes place. Tiles insertion is done in the request
dispatch block: if the URI correspond to a Tiles, this Tiles is
inserted. Otherwise, normal Struts mechanism is used (forward to the URI).
Struts always follows this workflow, except in some cases ;-(. This
is where problems arise. Checking the struts-config.dtd file, I have
listed where a path URI could takes place, and then I have check the
associated workflow:
* action ... ... forward path=URI
o This is the general mechanism. It end by calling
RequestProcessor.processActionForward(...)
* exception path=URI
o This also end by calling
RequestProcessor.processActionForward(...)
* action forward=URI ...
o Dispatching is embedded in processForward(...),
o code: String uri = appConfig.getPrefix() + uri; doForward();
* action include=URI
o Dispatching is embedded in processInclude(...),
o code: String uri = appConfig.getPrefix() + uri; doInclude();
* action input=URI or forwardName ...
o Dispatching is embedded in processValidate(...)
o code: String uri = null;
if (appConfig.getControllerConfig().getInputForward()) {
ForwardConfig forward = mapping.findForward(input);
uri = RequestUtils.forwardURL(request, forward);
} else {
uri = appConfig.getPrefix() + input;
}
doForward(uri, request, response);
The point to note is that all paths are not process in the same way !
Paths in forward ... can be flagged as contextRelative, while path
from attribute input/forward/include can't (they are always module
relatives). Also, a forward used in attribute input doesn't take into
account the sendRedirect flag.
The attributes forward and include can only take URI, while input
can also takes an actionForward name.
Question: Do these different behaviors are voluntary, or just a
consequence of the growing code ?
What I would like to do is to factorize the way paths are processed in
one request dispatch block. This will help the integration of Tiles,
but also the integration of others framework providing rendering views.
Tiles, and others tools will subclass the RequestProcessor and override
the methods doing the request dispatch.
Typically, Tiles interception should happen before the URI is modified
by concatenation of the module prefix. I can put some code everywhere,
but it will not be so nice, and not maintainable.
Ideally, factorization should be done in one single method (or two:
one forward, one include). For example, this can happen by calling
processActionForward(..., ActionForward ). This imply that the URI
string (from attributes include, forward, input) should be wrapped in an
ActionForward object. The advantage is that such URI can in a future
release be associated with the same properties than an actionForward,
and also that processing is the same for all.
An intermediate solution is to have 3 kinds of request dispatch blocks :
* processActionForward(..., ActionForward ):
o Same method as today. Called when we want to forward the
request according to actionForward content.
* doContextRelativeForward(String uri, request, response)
o Called when we want to do a forward to a context relative
uri. Method add module prefix to uri and do the forward.
* doContextRelativeInclude(...)
o Called when we want to do an include to a context relative
uri. Method add module prefix to uri and do the include
In this solution, the action's attribute input will end with a call to
processActionForward(...) or a call to doContextRelativeForward(...).
This solution avoid the extra creations of actionForward objects.
Please send me your comments asap, I experiment the second solution
and will be ready to commit it soon.
Cedric
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
Re: remove tiles from Contrib?
+1 for me. The contrib version is not more compiled and distributed as binary in the nightly build. Maybe we can left a README file saying that Tiles are now in the main distribution. Cedric James Holmes wrote: I closed out bug 7347 tonight, which was for removing Validator from the contrib directory. I think it makes sense to do this for Tiles as well. It can be confusing for anyone new to the project to see what appears to be a duplication of code. I know we're still working the kinks out of the Tiles integration so I'll defer to the others as to what the timing should be for this. I'm happy to take care of it when the time is right. -james [EMAIL PROTECTED] http://www.jamesholmes.com/struts/ __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles DTD
I agree with this. Furthermore, we can also remove all deprecated/old attributes in this 1_1 version. For backward compatibilities, user should use old version. For new projects, user should better use 1_1 version. I will commit the Tiles plugin today, after cactus test suite installation ;-). After that I can handle the new DTD and documentation. Cedric Craig R. McClanahan wrote: On Wed, 10 Jul 2002, James Holmes wrote: Date: Wed, 10 Jul 2002 10:49:35 -0700 (PDT) From: James Holmes [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Tiles DTD While we're on the subject of DTDs I wanted to propose that we rename the Tiles DTD from tiles-config.dtd to tiles-config_1_1.dtd to be consistent. Now that Tiles is in the core I think there should be a distinction between versions of the DTDs. Already the Tiles DTD has more than one *deprecated* elements and/or attributes. Thoughts? +1. We should leave the existing one there, though, for backwards compatibility. -james [EMAIL PROTECTED] http://www.jamesholmes.com/struts/ Craig __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Running Unit Tests Before Commits
Sorry for the inconvenience. I install the test process and will run it before any further commit. Do you recommend to do testing for any tomcat version (3 and 4), or is the latest one enough ? Cedric Craig R. McClanahan wrote: Doing the fix for 7751, I ran into a case where the undo of the / adding change caused the unit tests to fail, because I'd added some tests for the new behavior. I've commented those tests out until we figure out what to do about that particular situation. I'd like to ask all Struts committers to follow these practices: * When fixing a bug, build a unit test to verify the corrected behavior if this is at all reasonable to do. There are some mock objects in the src/test hierarchy now, so you should be able to write JUnit tests for pretty much any class other than the tag implementations. * Always run ant test.junit and ant test.tomcat.all before checking in your changes, to ensure that we don't introduce any regressions on stuff that is already tested. Thanks! Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Running Unit Tests Before Commits
Craig R. McClanahan wrote: I have try to run ant test.junit and ant test.tomcat.all on the nightly build, and they report some errors. As I have just installed cactus, I don't really know if it is my configuration or the nightly build ! So, does someone have run successfully the test suites on the nightly build ? Cedric Doing the fix for 7751, I ran into a case where the undo of the / adding change caused the unit tests to fail, because I'd added some tests for the new behavior. I've commented those tests out until we figure out what to do about that particular situation. I'd like to ask all Struts committers to follow these practices: * When fixing a bug, build a unit test to verify the corrected behavior if this is at all reasonable to do. There are some mock objects in the src/test hierarchy now, so you should be able to write JUnit tests for pretty much any class other than the tag implementations. * Always run ant test.junit and ant test.tomcat.all before checking in your changes, to ensure that we don't introduce any regressions on stuff that is already tested. Thanks! Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Running Unit Tests Before Commits
Using the latest commons-beanutils jar solves the problem ! Now all test suites run without any errors. So, I can finish up my commits. Thanks Craig for your help. Cedric Craig R. McClanahan wrote: Have you downloaded the latest and greatest commons-beanutils nightly? The current Struts code depends on some recent bugfixes and enhancements that were added there. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Initial Checkin of tiles-documentation webapp
I am currently working on the plugin for Tiles. I had left the documentation part for later, in order to incorporate new changes. I will complete the changes as work progresses. Cedric Craig R. McClanahan wrote: I just completed the initial check-in of the tiles-documentation webapp as a part of the standard Struts directory structure, instead of being built from contrib/tiles. Not surprisingly, the size of the CVS report exceeded the limits set for the mailing list -- here's the initial part of the message so you can see what I did. Craig -- Forwarded message -- Modified:.build-webapps.xml Added: src/tiles-documentation/org/apache/struts/example/tiles InitServlet.java src/tiles-documentation/org/apache/struts/example/tiles/channel ChannelFactorySet.java SelectChannelAction.java src/tiles-documentation/org/apache/struts/example/tiles/dev1-1 ApplicationResources.properties src/tiles-documentation/org/apache/struts/example/tiles/dynPortal PortalPrefsForm.java PortalSettings.java RetrievePortalAction.java SetPortalPrefsAction.java src/tiles-documentation/org/apache/struts/example/tiles/invoice Address.java EditInvoiceAction.java Invoice.java InvoiceForm.java src/tiles-documentation/org/apache/struts/example/tiles/lang SelectLocaleAction.java src/tiles-documentation/org/apache/struts/example/tiles/portal MenuSettings.java MenuSettingsForm.java PortalCatalog.java PortalSettings.java PortalSettingsForm.java UserMenuAction.java UserMenuSettingsAction.java UserPortalAction.java UserPortalSettingsAction.java src/tiles-documentation/org/apache/struts/example/tiles/rssChannel Channels.java RssChannelsAction.java src/tiles-documentation/org/apache/struts/example/tiles/skin DefinitionCatalog.java LayoutSettingsAction.java LayoutSettingsForm.java LayoutSwitchAction.java SimpleSwitchLayoutAction.java src/tiles-documentation/org/apache/struts/example/tiles/template DynTemplateAction.java src/tiles-documentation/org/apache/struts/example/tiles/test TestActionTileAction.java TestTileController.java src/tiles-documentation/org/apache/struts/example/tiles/tutorial ForwardExampleAction.java web/tiles-documentation index.jsp web/tiles-documentation/WEB-INF struts-config.xml tiles-defs.xml tiles-examples-defs.xml tiles-tests-defs.xml tiles-tutorial-defs.xml tiles-tutorial-defs_de.xml tiles-tutorial-defs_fr.xml web.xml web/tiles-documentation/common footer.jsp header.jsp menuViewSrc.jsp submenu.jsp viewSrc.jsp viewSrcBody.jsp viewSrcBodyError.jsp web/tiles-documentation/doc compatibilityChanges.html comps2Tiles.html download.jsp extensionsTags.jsp installation.jsp overview.jsp quickOverview.jsp tilesTags.jsp tutorial.jsp tutorialStaticIndex.jsp userGuide.jsp web/tiles-documentation/doc/portal comments.jsp documentation.jsp download.jsp features.jsp news.jsp nextFeatures.jsp revisions.jsp revisionsCont.html strutsIntegration.jsp tilesCompsTemplates.jsp todo.jsp welcome.jsp web/tiles-documentation/doc/portal/images portalOverview.gif web/tiles-documentation/examples index.jsp myMenuSettings.jsp myPortal.jsp myPortalSettings.jsp portal.jsp rssChannels.jsp skinSettings.jsp summariesTabs.jsp tabs.jsp web/tiles-documentation/examples/rssFeed apacheweek-headlines.xml rss-example.xml web/tiles-documentation/examples/tiles adminSummary.jsp body.jsp componentsSummary.jsp footer.jsp header.jsp i18nSummary.jsp menuSummary.jsp multiChannelsSummary.jsp myLayoutSummary.jsp myMenuSettings.jsp myMenuSummary.jsp myPortalPrefs.jsp myPortalSettings.jsp myPortalSummary.jsp mySkinSettings.jsp portalSummary.jsp rssChannelErrors.jsp
Re: New Struts project on SourceForge-portal: Scope:
This is an interesting project. What is the exact URL on SourceForge ? Cedric Struts-dev Newsgroup (@Basebeans.com) wrote: Subject: New Struts project on SourceForge-portal: Scope: From: Vic C. [EMAIL PROTECTED] === (fyc:) The basicPortal uses JSTL, Struts to make it a better at web content manager than Apache. It's goals are KISS minimalist with samples for training. (as opposed to best design, it is a design easiest to learn). It is the lowest common denominator of portlet engines, a Struts equivalent to JetSpeed and based mainly on Tiles. 20% of code used 80% of time. It is open source and free. It can run on any J2EE server and any SQL DB. An administrator can create select content categories and modules. They can also approve individual line items. The can select XSL and CSS and Look and Feel. Any user can upload content and images. Anyone can register themselves to portal JAAS table. (Admin can change your role) A developer can use Dream Weaver to create portlets with JSTL. A portal module actions and bean is also exposed via SOAP to non JSP, such as .NET. Screens include: List of content items based on a category A zoomed content A way to add content and upload BOBs, etc. A list of content that needs to be approved and prioritized (Admin role only) A way to edit content (Admin role only). A way for a user to add themselves A way for an admin to modify user Samples of portlet modules include: · TheServerSide.com · Loveme.com · Issue / bug tracking · Mail.yahoo. · Group Calendar · RSS · Ad/Banner · Add a user module The portlet module is a Struts tile with it's own action controller. ( http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf 5.2 , 7.2 , 7.4, 8.1 - we will call 5.2 a portlet module) The basic Portal is Struts based and provides JAAS, DAO, object caching service and inter tile communication services for portlet modules. Each portlet (tile w/controller) know is meta content and user role. BasicPortal has no user customizations, rather they are role/group based (JAAS) It is asynchronous, all content is displayed from DB; any module or fee is to DB, not web side. Content table: id, title, contnet, category, source, display order (num), image, bigImage, postedbyemailID, storyHTTPLinkMore, storyStatus(approved), storyDateTime, StoryDate, Price, displayNum, clickNum, displayOnPage -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles And Struts
I am working in that direction : eliminating the servlet for Tiles with Struts1.1, and have a request processor doing the job. Tiles require a special RequestProcessor and an initialization in a plugin. To avoid extra declaration in struts-config file, I would like to let the plugin set the RequestProcessor class. This is actually not possible because configurations are frozen before plugins are called. I propose to froze configurations after plugins initialization. This will let a chance to plugin to set some configurations parameters. Is there some objections ? If not, I will do the required modification, and provide requested plugin. What are you goals about the Tiles documentation, example, jar and war ? Do you thing to separate them from main struts one as today, integrate them more deeply or remove them ? If I know where we want to go I can help doing it ;-) Cedric Craig R. McClanahan wrote: On Wed, 26 Jun 2002, Ted Husted wrote: Date: Wed, 26 Jun 2002 11:48:55 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Tiles And Struts Note that Struts1.1 also require the TilesRequestProcessor to enable Tiles. In practice, I find that if you only use a * single * Tiles definition file (no comma-delimited list), then the stock 1.1 ActionServlet seems to work just as well. This works with the Tiles example application as well as my own. Most of the code in the 1.1 ActionComponentServlet and TilesRequestServlet seem to overlap. Perhaps there's a way we could just use the processor in 1.1 and eliminate the servlet subclass? I want to go that way, once the basic integration is done. Ideally, the standard RequestProcessor can be used, and any one-time initialization can be done in a PlugIn. But I haven't looked deeply into how TilesRequestProcessor differs from the standard one yet. Cedric, any comments? -T. Craig Cedric Dumoulin wrote: By using tiles ActionComponentServlet , no Struts functionalities are lost. You gain one : the ability to use Tiles definitions names as Struts forward. Note that Struts1.1 also require the TilesRequestProcessor to enable Tiles. Cedric Vincent Stoessel wrote: Just out of curiosity, what functionality is lost by using tiles' ActionComponentServlet ? Thanks Ricardo de Souza Moura wrote: Can I use a plugIn to Tiles ? I am not wanting to use the ActionComponentServlet, but I am wanting to use the definitions-config param. There are some way ? Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
+1 for me Craig R. McClanahan wrote: I'd like to continue swatting the remaining bugs in 1.1, and improve the existing documentation, with a goal to release a beta 2 of Strust 1.1 in the near future (ideally by July 8 or so). Part of my motivation for the timing is that Sun is shutting down next week, so I will have some quality time hours available when I'm actually awake :-). Are the other committers interested in working towards such a goal? One thing I'd like to add to the TODO list is a review of all our custom tag implementations versus the JSP spec requirements -- particularly in the area of tag pooling and when the bodyContent can be accessed. The recent work on Jasper2 (in Tomcat 4.1.x), which will support tag pooling, has indicated we probably have some tags that don't completely conform to the contracts -- and we need to fix that before any final release. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles And Struts
Craig R. McClanahan wrote: Would it be possible to take the static portions of the Tiles documentation and merge them into struts-documentation, and keep all the dynamic stuff that requires execution in a tiles-tutorial or tiles-example webapp? Yes it is. Actually, I used to build a static version by extracting static portion and documentation with an ant script doing some calls on requested pages. This is done in an ant script building the website, distribution and so on. I like to maintain the documentation in a dynamic website using Tiles and Struts, because I found it more easy, and it helps maintaining consistency. I will check if I can continue in this way: extracting static portion and inserting it in the struts part automatically. Otherwise, I will follow actual struts way. The goal is to have a consistent documentation all over struts site. Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 7289] - Using Tiles, html:base/ resolves to location of layout JSP
It is not a bug, as the tag behaves as its documentation says. But maybe we can improve / enhance the tag to be able to use it in the context of included pages (like tiles). An idea is to add an optional attribute path. If this attribute is specified, base output the root URL of current web application context, concatenated with the specified path. If path is set to or /, the base output the root URL of current web application. This behavior is interesting when using template, tiles or include. It allows to specify in a layout the base URL to be used by browsers, independently of tiles jsp (or layout) locations. Any comments ? Cedric [EMAIL PROTECTED] wrote: 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=7289. 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=7289 Using Tiles, html:base/ resolves to location of layout JSP --- Additional Comments From [EMAIL PROTECTED] 2002-06-24 00:36 --- Cedric: Is this a bug or can we close this? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: bug in tiles controllerClass option?
Normally, you can use a Struts action as a tiles controller with no modification. You should specify only one attribute controllerClass OR controllerURL. If problem persists, it should be a bug ;-) Here is an abstract of the (not officially released) documentation : (http://www.lifl.fr/~dumoulin/tiles/tilesAdvancedFeatures.pdf chapter 5.2) . If you use a class name as controller, it should extends one of the following base class or interface : * org.apache.struts.tiles.Controller o This is the Controller interface defining the controller method. This method receives as arguments the current Tile's context, and usual servlet parameters request, response and servletContext. * org.apache.struts.tiles.ControllerSupport o This is a basic implementation with an empty method. * org.apache.struts.action.Action (wrapper org.apache.struts.action.StrutsActionControllerWrapper is used) o If you provide a Struts Action subclass, it will be wrapped with appropriate class, and Struts' perform method will be called, but mapping and form attribute will be null. Example of a controller inserted as a class : tiles:insert page=layout.jsp controllerClass=org.apache.struts.example.tiles.test.TestTileController tiles:put name=title value=Test controller set in insert / tiles:put name=header value=header.jsp / tiles:put name=body value=body.jsp / /tiles:insert .. Hope this help, Cedric Klaasjan Brand wrote: Hi there, I'm trying to assign a Struts action to a tile. I've tried controllerUrl to a struts action and setting controllerClass to the same Action, but the response I get is that I have to extend Action or implement Controller. When I changed the Action to implement Controller it works, but now I'm wondering how to pass request parameters to the class... greets, Klaasjan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles/use of parameter in the components composition
Hello, See my reply in struts-user list. This kind of question must be asked in struts user list. Please, avoid crosspost across lists. Cedric Struts-dev Newsgroup (@Basebeans.com) wrote: Subject: Tiles/use of parameter in the components composition From: PitBull [EMAIL PROTECTED] === Hi all, I have the following situation: %@ taglib uri=/WEB-INF/conf/tiles.tld prefix=tiles % tiles:insert page=/Layout.jsp flush=true tiles:put name=title value=My page / tiles:putList name=jsList /tiles:putList tiles:put name=object value=/object.jsp/ ?? tiles:put name=MODE value=OBJECTSELECT /?? tiles:put name=objectSrc value=/objectSrc.jsp/ /tiles:insert I put tiles:put name=c value=OBJECTSELECT / because i need OBJECTSELECT and CHOICE as parameters to manage two different contexts inside the jsp objectSrc.jsp. e.g.: In the file objectSrc.jsp I have to do something like that: logic:equal name=MODE value=OBJECTSELECT do A /logic:equal logic:equal name=MODE value=CHOICE do B /logic:equal That not run. Can anyone help me to solve this problem plz? Thanx Pit -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: TILES : Dealing with Channel and contentType
Hello, Look like your contentType directive is not taken into account ! Playing a little bit with the directive, it appear that it is taken into account only if set in the first jsp page encountered. In your example, you have put it in the layout.jsp, which I suppose is inserted from another page (like index.jsp). So, layout.jsp is your second page encountered ;-( . Maybe you can try to use struts action as entry point. Your Struts actions forward to a definition inserting appropriate layout.jsp. Hope this help, Cedric P.S. : Such question may better be asked in struts-user list Manuel Vilar wrote: Hello all of you ! I am new user with struts tiles ! My question is quite basic : I want to use tiles channels mechanism to handle two clients medias. html and vdxml ( vdxml is a french specific media language, but in this example we could have spoke about wml instead ) My fisrt web application called page is index.jsp : %@ taglib uri=/WEB-INF/tiles.tld prefix=comp % comp:insert definition=mainLayout flush=false / I touched the Tiles ChannelFactorySet.java (which extends FactorySet.java) to select the good channel when getDefinitionsFactoryKey() is involved. In the function, if the key is not defined (channel key) I analyse the request header user-agent to tell the function which user-agent respective key to use and to set. I defined the two component definitions files : ComponentDefinitions_html.xml ComponentDefinitions_vdxml.xml Each definition file contains a mainLayout definition with the path setted to the media oriented respective Layout.jsp : In ComponentDefinitions_html.xml : definition name=mainLayout path=/html/Layout.jsp /definition where /html/Layout.jsp contains : HTML ...some html code here... /HTML In ComponentDefinitions_vdxml.xml : definition name=mainLayout path=/vdxml/Layout.jsp /definition where /html/Layout.jsp contains : ?xml version=1.0 encoding=ISO-8859-1 ?%@ page contentType=text/vdxml % !DOCTYPE VDXML SYSTEM C:\J2EE\FlirtDev\vdxml.dtd VDXML ... some vdxml code here ... /VDXML It works fine with html media. ( Internet Explorer ) But with vdxml, the media browser ( vdxml Browser ) indicates that it received a wrong contentType (text/html ). Of course it would have received the text/vdxml contentType defined in the /vdxml/Layout.jsp. I certainly missed something. Can any one help me ? Thanks in advance, Manuel ( A new french developper in J2EE world but an old one in C++ ) P.S. If you read this, I appologize because of borrowing you with quite novice question ! You certainly guess that I am not used to English, sorry about that, but I promise I will practice more ! Manuel Vilar Service developpement 01 45 15 03 32 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Default content for template:get tag
Have you check Tiles capabilities ? Tiles are considered as extended template
framework.
Tiles provide an extension mechanism allowing default values specification.
Cedric
Adam P. Jenkins wrote:
I added the ability to specifiy default content for the template:get tag.
This content is output by the get tag only if there is no corresponding
template:put tag in the inserting page. I did this by making it so
template:get accepts a content attribute and direct attribute, and can
also have a body. These have the same meaning as for the template:put tag,
except that they are only evaluated if there is no content with the given
name on the ContentMapStack. Here is an example of the usage:
!-- template.jsp --
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-template.tld prefix=template %
template:get name=title content=Default Title direct=true/
template:get name=body
This is the default page body
/template:get
!-- page.jsp --
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-template.tld prefix=template %
template:insert template=template.jsp
template:put name=title content=Page Title direct=true/
!-- I don't specify a body, so default will be used. --
/template:insert
In the above example, page.jsp inserts template.jsp, and only specifiies a
title. So in template.jsp, template:get name=title will output the title
given in page.jsp, but template:get name=body will use the default body
specified in template.jsp.
My motivation for adding this is that often when I write templates, I want to
make them very configurable. But often there are sensible defaults for most
of the parameters. It makes the templates much more useful if when I insert
them, I only need to specify values where I want to override the defaults.
I had to modify two files to add this:
src/share/org/apache/struts/taglib/template/GetTag.java
doc/userGuide/struts-template.xml
Here are the patches.
Index: struts-template.xml
===
RCS file: /home/cvspublic/jakarta-struts/doc/userGuide/struts-template.xml,v
retrieving revision 1.1
diff -u -r1.1 struts-template.xml
--- struts-template.xml 20 Feb 2002 00:41:14 - 1.1
+++ struts-template.xml 6 Apr 2002 16:51:01 -
@@ -117,7 +117,7 @@
put tag.
/summary
tagclassorg.apache.struts.taglib.template.GetTag/tagclass
-bodycontentempty/bodycontent
+bodycontentJSP/bodycontent
info
Retrieve content from request scope and include it.
/info
@@ -154,6 +154,26 @@
/info
/attribute
+attribute
+ namecontent/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ info
+ Content that's put into request scope if there is no
+ corresponding put element.
+ /info
+/attribute
+
+attribute
+ namedirect/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ info
+ Determines how content is handled: true means content is
+ printed idirect/ily; false, the default, means content
+ is included.
+ /info
+/attribute
/tag
Index: GetTag.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/template/GetTag.java,v
retrieving revision 1.12
diff -u -r1.12 GetTag.java
--- GetTag.java 12 Mar 2002 05:55:08 - 1.12
+++ GetTag.java 6 Apr 2002 16:52:19 -
@@ -67,6 +67,7 @@
import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.PageContext;
+import javax.servlet.jsp.tagext.BodyTagSupport;
import javax.servlet.jsp.tagext.TagSupport;
import org.apache.struts.action.Action;
import org.apache.struts.taglib.template.util.*;
@@ -79,7 +80,7 @@
* @author David Geary
* @version $Revision: 1.12 $ $Date: 2002/03/12 05:55:08 $
*/
-public class GetTag extends TagSupport {
+public class GetTag extends BodyTagSupport {
// - Instance Variables
@@ -101,6 +102,18 @@
private String role;
/**
+ * The default content's URI (or text).
+ */
+ private String content = null;
+
+
+ /**
+ * Determines whether content is included (false) or printed (true).
+ * Content is included (false) by default.
+ */
+ private String direct = null;
+
+ /**
* Set the flush-before-include property
* @param flush The new flush property
*/
@@ -131,6 +144,27 @@
}
/**
+ * Set the content's URI (if it's to be included) or text (if it's to
+ * be printed).
+ */
+ public void setContent(String content) {
+
+ this.content = content;
+
+ }
+
+
+ /**
+ * Set direct to true, and content will be printed directly, instead
+ * of included (direct == false).
+ */
+ public void
Re: TR: Multi Device application with STRUTS
Hy, First, I move this thread to struts-user. You can check Tiles capabilities to have different channels. In your case, a channel correspond to a targeted device. This Tiles capability is an attempt to provide an answer to the multi-device problem. You use the same actions for all channels, and different views implementation for each. The struts-config file contains action declarations declaring forwards to logical views. Tiles select appropriate views according to your own criteria (here the device type). The tiles mechanism works in the same way that Java i18n properties work : you have one declaration file for each device, each one declaring tiles definitions for the device. Check the i18n Tiles capabilities, and the multi-channel example coming with Tiles. It should be easy to adapt it to device switching. Hope this help, Cedric Manuel Vilar wrote: Hello, First : I am a French developper, so I apologize for my poor English ! Our society decided to use STRUTS because of its MVC approach ! Our applications have to be accessed by differents customers devices. Each customer device supports different languages ( html, vdxml, WML, etc...) Whats on ? STRUTS having not intrisinc customer device notion, we are thinking about two ways for making STRUTS have a customer device notion. Method 1 : Upgrading ourself STRUTS to implement a device detection ( This info could be retrieved in the fisrt customer header request ). This approach would mean that all the specific device code ( Views, Forms,... ) should be selected automaticly by forwards functions, and generally by all the STRUTS functions expecting a parameter like path=example.jsp or any page indication parameter input=MyForm in the case of an input action). Example : The first application page is index.jsp In struts-config.xml we define this action : !-- Display the welcome page -- actionpath=/welcome forward=/welcome.jsp /action There is no welcome.jsp but two pages named respectivly welcome_A.jsp and contains html code, and welcome_B.jsp which contains WML code. A Customer Device accept html ( Netscape browser ) B Customer Device accept wml ( WAP ) The index.jsp which is the common page could detect customer device and sets the Device Value to A or B. index.jsp contains a link wich page=welcome.do So we start ! When the customer selects the link welcome.do, STRUTS action called forward could return welcome_A.jsp, assuming current device is A. We are here speaking of suffixed pages with A and B. We could use the same pages names but in different directories like that : A/welcome.jsp for A Device ( html ) B/welcome.jsp for B Device.( WML ) Method 2 : Making two applications, the fisrt for A Customer Devices and the second for B Customer Devices, and force them to share ( if we can do so ! ) the ressources that are not Device specific. Questions : Am I Wrong ? ( because none of these methods should be applied or there is a simple way ) Best way ? Thank you all for your answers, Manuel Vilar, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Caching tiles
Hello, I haven't hear of such functionality yet. You're welcome to contribute and provide code and examples for it . Cedric Pieter Coucke wrote: Hi, In order to improve the performance of our project, I'd like to use a form of caching. I was thinking of something in the tiles-defs.xml as the following: definition name=menu path=/menu.jsp time-to-live=360 ... /definition This would cache the menu-tile for one hour. Another example: definition name=item path=/itembody.jsp time-to-live=360 key=id ... /definition This would cache the item-tile for one hour, depending on the id of the item. So, for every item, a separate cache would be made. The parameter for the key must come from the session or the request. The key can also be a comma-separated list of values. I've searched for something similar, but could not find it. If this already exists, sorry for disturbing you. If it doesn't, I would be happy to contribute code for it. I was thinking of using the code from jakarta-commons-cache as a basis. Sincerely, Pieter Coucke eXpanded Media Belgium http://www.expandedmedia.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Deprecations and Struts
I can deal / try to clean deprecations from Tiles ;-) But what versions of servlet, ant, jdk, xml parser should we officially use ? Cedric Martin Cooper wrote: I've cleaned up a bunch of deprecations in the web apps that are part of Struts. The remaining deprecation warnings fall into three groups: 1) Deprecations related to the differences between the Servlets 2.2 and Servlets 2.3 APIs. We cannot do anything about these, since we have to remain compatible with Servlets 2.2, at least until Servlets 2.3 has taken over. 2) Deprecations in Tiles. I did not attempt to deal with these, since Tiles has a life of its own, independent of Struts. Cedric is in the best position to know if any changes are appropriate here. 3) Digester related deprecations. I know how to fix the Digester.log() problem, but I wasn't sure what to do with the Digester.setDebug() calls. The current implementation does nothing, but it wasn't clear to me what we should be calling instead, given that the deprecation comment indicates that it is logging-implementation-dependent. Suggestions appreciated. ;-) -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Source Archive
Find after what I got in my archives. I can make them available through my website for a while, or send them as attached file if you wish. Cedric 01/08/2001 13:041ÿ065ÿ466 jakarta-struts-1.0-src.zip 01/02/2002 15:491ÿ098ÿ983 jakarta-struts-1.0.1-src.zip 01/02/2002 15:493ÿ515ÿ774 jakarta-struts-1.0.1.zip 11/02/2002 10:101ÿ092ÿ166 jakarta-struts-1.0.2-src.zip 11/02/2002 10:103ÿ518ÿ838 jakarta-struts-1.0.2.zip 01/08/2001 13:043ÿ448ÿ666 jakarta-struts-1.0.zip 11/07/2001 17:202ÿ750ÿ013 jakarta-struts-20010711.zip 16/07/2001 13:292ÿ793ÿ167 jakarta-struts-20010716.zip 20/07/2001 09:423ÿ196ÿ714 jakarta-struts-20010719.zip 23/07/2001 09:483ÿ196ÿ220 jakarta-struts-20010721.zip 28/08/2001 11:153ÿ220ÿ988 jakarta-struts-20010828.zip 11/09/2001 08:513ÿ222ÿ934 jakarta-struts-20010910.zip 12/09/2001 14:074ÿ026ÿ391 jakarta-struts-20010911.zip 27/09/2001 14:444ÿ777ÿ244 jakarta-struts-20010927.zip 28/09/2001 15:404ÿ776ÿ540 jakarta-struts-20010928.zip 15/10/2001 15:584ÿ912ÿ024 jakarta-struts-20011015.zip 24/10/2001 11:124ÿ932ÿ593 jakarta-struts-20011023.zip 15/11/2001 18:064ÿ942ÿ302 jakarta-struts-2005.zip 17/12/2001 16:072ÿ065ÿ174 jakarta-struts-20011217.zip 26/12/2001 17:445ÿ231ÿ979 jakarta-struts-20011226.zip 01/02/2002 15:506ÿ941ÿ075 jakarta-struts-20020201.zip 12/02/2002 10:236ÿ942ÿ442 jakarta-struts-20020210.zip 12/02/2002 10:22 466 jakarta-struts-20020211.zip 21/02/2002 18:536ÿ358ÿ758 jakarta-struts-20020221.zip 22/02/2002 17:436ÿ424ÿ469 jakarta-struts-20020222.zip 11/07/2001 17:201ÿ246ÿ243 jakarta-struts-src-20010711.zip 16/07/2001 13:291ÿ256ÿ838 jakarta-struts-src-20010716.zip 23/07/2001 10:431ÿ152ÿ538 jakarta-struts-src-20010721.zip 28/08/2001 11:151ÿ707ÿ752 jakarta-struts-src-20010828.zip 27/09/2001 14:432ÿ342ÿ997 jakarta-struts-src-20010927.zip 15/10/2001 15:532ÿ483ÿ833 jakarta-struts-src-20011015.zip 24/10/2001 11:092ÿ493ÿ408 jakarta-struts-src-20011023.zip 06/11/2001 18:382ÿ500ÿ210 jakarta-struts-src-20011106.zip 15/11/2001 18:062ÿ701ÿ865 jakarta-struts-src-2005.zip 18/12/2001 10:142ÿ723ÿ648 jakarta-struts-src-20011217.zip 26/12/2001 17:442ÿ724ÿ557 jakarta-struts-src-20011226.zip 01/02/2002 15:502ÿ835ÿ285 jakarta-struts-src-20020201.zip 12/02/2002 10:222ÿ835ÿ683 jakarta-struts-src-20020211.zip 22/02/2002 17:432ÿ915ÿ153 jakarta-struts-src-20020222.zip Ted Husted wrote: Jakarta has the nightly builds on a fairly short leash now. While I know the sysadm's make backups, and CVS never forgets, I thought I would start tucking away a snapshot of the weekly source download on CD for safekeeping. If anyone happened to have any old Struts source downloads hanging around that they would like to contribute, please let me know. Unfortunately, I did my annual diskkeeping before I thought if this, and really don't have any old ones myself. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles and Struts 1.0.1 release : ActionForm problem
I have compile and check Tiles with rc1.0.2 branch, and all seems to work perfectly again. The proposed change is ok for me. Cedric Ted Husted wrote: Yes, that's it AFAIK. Did someone apply the patch already? I went to do it but it seems to be done. I don't see the CVS event. If it isn't there, maybe I need a fresh checkout. Unless there's something else, I don't think we need a formal release candidate, but we could confirm that the current 1_0 BRANCH now works with Cedric, [EMAIL PROTECTED], and [EMAIL PROTECTED] who have reported the problem. Maybe we could post it in the release candidate directory long enough for these three to confirm, and then just move it over. -T. Martin Cooper wrote: I can do it - I still have the 1.0.1 release tree set up on my machine. So, to confirm what we're doing, the only changes are: 1) Make ActionForm.getMultipartRequestHandler() public instead of protected. 2) Update the version number to 1.0.2. As soon as I hear back on this, I'll check in the changes and upload a build. Question: Do we want a Release Candidate build? Here's my proposal for how we handle this, given the very limited scope of the release: a) I check in the changes noted above. b) I upload a build into the 1.0.2 release location. c) Someone (Cedric? Ted?) verifies that Tiles works with that build. d) I announce the release. Another question: What do we do about release notes for this one? -- Martin Cooper - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, February 05, 2002 10:00 AM Subject: Re: Tiles and Struts 1.0.1 release : ActionForm problem It's a bug. Mea culpa. I think we'll need to change that and pop-out a 1.0.2 release. Sorry about that. Martin, did you want to do this one too, or should I? -T. Cedric Dumoulin wrote: Some user have reported that Tiles don't compile with Struts 1.0.1. The problem come from the fact that method getMultipartRequestHandler() in ActionForm is protected in 1.0.1. Checking the log, it appear that it is for bug #4997. The same patch has been applied in head branch, but method still public. So, we are facing an inconsistency : do we need it protected or public ? If protected, Tiles servlet doesn't work anymore with 1.0.1, because it has a copy of ActionServlet.processValidate() method, which do a call to the protected method getMultipartRequestHandler() ;-(. For now there is two solutions : * Change back protected to public if we don't need getMultipartRequestHandler() to be protected. This still problematic because 1.0.1 is an official release * Move Tiles servlet into the same package as ActionForm and ActionServlet. But in this case full tiles servlet name change, and backward compatibility is broken for Tiles ;-( Does someone have another idea ? Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[proposal] Multi-app sources modifications
In order to ease integration of Struts and Tiles (and others
frameworks as well), while keeping Struts free from any Tiles stuff, I
propose following modification in code :
* in action.RequestProcessor.java :
o add method public ActionServlet getServlet(){};
+ to allow subclasses to access the servlet. Personally I
need to retrieve servlet configuration to initialize
Tiles.
o Let method init(...) throws a ServletException, like its
Servlet counterpart.
+ This will allow subclasses to throw an error if init()
fail.
o Factorize calls to RequestDispatcher.include() and
RequestDispatcher.forward().
+ To allow a subclass to overload these methods, in order
to catch forwards.
If there is no objections, I will commit these changes.
Cedric
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tiles and Struts 1.0.1 release : ActionForm problem
Some user have reported that Tiles don't compile with Struts 1.0.1. The problem come from the fact that method getMultipartRequestHandler() in ActionForm is protected in 1.0.1. Checking the log, it appear that it is for bug #4997. The same patch has been applied in head branch, but method still public. So, we are facing an inconsistency : do we need it protected or public ? If protected, Tiles servlet doesn't work anymore with 1.0.1, because it has a copy of ActionServlet.processValidate() method, which do a call to the protected method getMultipartRequestHandler() ;-(. For now there is two solutions : * Change back protected to public if we don't need getMultipartRequestHandler() to be protected. This still problematic because 1.0.1 is an official release * Move Tiles servlet into the same package as ActionForm and ActionServlet. But in this case full tiles servlet name change, and backward compatibility is broken for Tiles ;-( Does someone have another idea ? Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: template tag question
You can't call a Struts action once you have already written something in the output stream. This is because jsp spec forbid call to forward() when you have written something. Using a Struts action do a forward ... You can try to use Tiles instead of Struts template, it should work with actions in templates. Cedric Vaillancourt, Richard wrote: I have a template tag where I want to exec a .do... Below is the template.jsp, the .jsp it ulitmately wants to include, config file specifying action, and stack dump... It hits the action perform as expected and returns the correct .jsp string on success. I receive a // the template %@ taglib uri='/WEB-INF/struts-template.tld' prefix='template' % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % %@ taglib uri=/WEB-INF/struts-menu.tld prefix=menu % template:insert template='/workflowTemplate.jsp' template:put name='title' content='Templates - Test' direct='true'/ template:put name='sidebar' content='/setSecurityCode.do' / template:put name='header' content='/workflowHeader.jsp' / template:put name='content' content='/workflowwelcome.jsp'/ /template:insert the workflowSideba.jsp %@ page language=java % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % %@ taglib uri=/WEB-INF/struts-menu.tld prefix=menu % table cellpadding=0 cellspacing=0 tr valign=top td menu:useMenuDisplayer name=Simple bundle=org.apache.struts.action.MESSAGE table cellpadding=0 cellspacing=0 tr td logic:equal name=addWorkgroupForm property=userAdmin scope=request value=FALSE menu:displayMenu name=WorkflowAdmin2/ /logic:equal logic:equal name=addWorkgroupForm property=userAdmin scope=request value=TRUE menu:displayMenu name=WorkflowAdmin/ /logic:equal /td /tr /table /menu:useMenuDisplayer /td /tr /table // struts config file actionpath=/addWorkgroup type=workflowadminstruts.AddWorkgroupAction name=addWorkgroupForm scope=request validate=false forward name=success path=/workflowwelcome.jsp/ /action A recursive error was detected. The server cannot use specified error page. Please check the application error-path. Original Error: Error Message: ERROR: Cannot forward. Writer or Stream already obtained. Error Code: 500 Target Servlet: null Error Stack: Root Error-1: ERROR: Cannot forward. Writer or Stream already obtained. java.lang.IllegalStateException: ERROR: Cannot forward. Writer or Stream already obtained. java.lang.Throwable(java.lang.String) java.lang.Exceptio(java.lang.String) java.lang.RuntimeException(java.lang.String) java.lang.IllegalStateException(java.lang.String) void com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward(javax.servlet. ServletRequest, javax.servlet.ServletResponse) void org.apache.struts.action.ActionServlet.processActionForward(org.apache.strut s.action.ActionForward, org.apache.struts.action.ActionMapping, org.apache.struts.action.ActionForm, javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) void org.apache.struts.action.ActionServlet.process(javax.servlet.http.HttpServle tRequest, javax.servlet.http.HttpServletResponse) void org.apache.struts.action.ActionServlet.doGet(javax.servlet.http.HttpServletR equest, javax.servlet.http.HttpServletResponse) void javax.servlet.http.HttpServlet.service(javax.servlet.http.HttpServletRequest , javax.servlet.http.HttpServletResponse) void javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse) void com.ibm.servlet.engine.webapp.StrictServletInstance.doService(javax.servlet. ServletRequest, javax.servlet.ServletResponse) void com.ibm.servlet.engine.webapp.StrictLifecycleServlet._service(javax.servlet. ServletRequest, javax.servlet.ServletResponse) void com.ibm.servlet.engine.webapp.IdleServletState.service(com.ibm.servlet.engin e.webapp.StrictLifecycleServlet, javax.servlet.ServletRequest, javax.servlet.ServletResponse) void com.ibm.servlet.engine.webapp.StrictLifecycleServlet.service(javax.servlet.S ervletRequest, javax.servlet.ServletResponse) void com.ibm.servlet.engine.webapp.ServletInstance.service(javax.servlet.ServletR equest, javax.servlet.ServletResponse, com.ibm.servlet.engine.webapp.WebAppServletInvocationEvent) void
Re: [VOTE] Proposed Committer Arron Bates
+1 for me Cedric Ted Husted wrote: Arron has developed an interesting and popular extension to the Struts taglibs. He has been distributing the extension in a very complete and accessible package, and has offered to donate it to Struts. Arron has also been helping out on the lists, and posting elsewhere on Jakarta. I believe he would be a good addition to the team, and I hereby propose him as a Struts Committer. He has my +1. Votes please? -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Building Nightly Build
Looks like commons-digester.jar, commons-collections.jar and
commons-beanutils.jar are not accessible or found when you compile.
If you build only tiles from the contrib/tiles folder, add following lines to
your build.properties file (and change commons home ;-) :
# The JAR file containing version 1.0 (or later) of the Beanutils package
# from the Jakarta Commons project.
commons-lib.home=???
commons-beanutils.jar=${commons-lib.home}/commons-beanutils.jar
# The JAR file containing version 1.0 (or later) of the Collections package
# from the Jakarta Commons project.
commons-collections.jar=${commons-lib.home}/commons-collections.jar
# The JAR file containing version 1.0 (or later) of the Digester package
# from the Jakarta Commons project.
commons-digester.jar=${commons-lib.home}/commons-digester.jar
When compiling from struts, this properties are set by struts build file.
Cedric
Matt Raible wrote:
I can compile Tiles just fine from the contrib/tiles directory, but when I
try to do ant dist, I get the following error - only one Tiles. Any
ideas? Everything else compiles and builds just fine.
Thanks,
Matt
init:
[echo] - Tiles 1.1-dev -
[echo]
[echo] java.class.path =
d:\Tools\jakarta-ant-1.4.1\lib\xerces.jar;d:\Tools\jakarta-a
nt-1.4.1\lib\xalanj1compat.jar;d:\Tools\jakarta-ant-1.4.1\lib\xalan.jar;d:\T
ools\jakarta-a
nt-1.4.1\lib\velocity-tools-view-0.3.jar;d:\Tools\jakarta-ant-1.4.1\lib\velo
city-1.3-dev.j
ar;d:\Tools\jakarta-ant-1.4.1\lib\junit.jar;d:\Tools\jakarta-ant-1.4.1\lib\j
dom.jar;d:\Too
ls\jakarta-ant-1.4.1\lib\jaxp.jar;d:\Tools\jakarta-ant-1.4.1\lib\jakarta-ant
-1.4.1-optiona
l.jar;d:\Tools\jakarta-ant-1.4.1\lib\crimson.jar;d:\Tools\jakarta-ant-1.4.1\
lib\ant.jar;d:
\SDKs\j2sdkee1.3\lib\j2ee.jar;d:\SDKs\jdk1.3.1\lib\tools.jar
[echo] java.home = d:\SDKs\jdk1.3.1\jre
[echo] user.home = C:\Documents and Settings\mraible
[echo] struts.home = target/library
[echo] struts.libs = ../../target/library
[echo] dist.home = ../../dist
[echo] build.home = ../../target/tiles
[echo] basedir = D:\Source\jakarta-struts\contrib\tiles
prepare.library:
compile.library:
[javac] Compiling 55 source files to
D:\Source\jakarta-struts\target\tiles\library\cla
sses
[javac]
D:\Source\jakarta-struts\contrib\tiles\src\share\org\apache\struts\taglib\ti
le
s\util\TagUtils.java:11: cannot resolve symbol
[javac] symbol : class PropertyUtils
[javac] location: package beanutils
[javac] import org.apache.commons.beanutils.PropertyUtils;
[javac] ^
[javac]
D:\Source\jakarta-struts\contrib\tiles\src\share\org\apache\struts\tiles\xml
De
finition\XmlParser.java:16: cannot resolve symbol
[javac] symbol : class Digester
[javac] location: package digester
[javac] import org.apache.commons.digester.Digester;
[javac]^
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Release Struts 1.0.1-rc1 as Struts 1.0.1
Martin Cooper wrote: [ x] +0 I am in favor of the release, but am unable to help support it Sorry to have not enough time to help for this. Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Future Struts releases
Ted Husted wrote: So, now that 1.0.1 is in the queue, we may want to make some decisions regarding 1.1. ... [Tiles,Validator] The next question is whether David and Cedric are interested in proposing their components to Taglibs or the Commons, or would prefer to leave them here. Your call, guys. I believe that you have both indicated an interest in broadening the audience for this components, so I say go for it. Of course, we would add both to the Users Guide, and may even end up requiring the JARs as we do for the Commons components. I will propose Tiles to taglibs, but, as already said, I would like to let in Struts an example combining Struts and Tiles. This example will replace actual example/distribution. I am in the process of finalizing a new version, with the example. [JARs] How do people feel about making the rest of the Struts JARs more granular? Maybe we should be breaking this up so each package or taglib gets its own JAR, so we could have struts-action.jar struts-actions.jar struts-html.jar struts-logic.jar struts-bean.jar struts-template.jar struts-upload.jar struts-util.jar I think the general trend is toward finely-grained JARs. Down the road, I could envision people using the struts-action.jar, but not needing any (or all of) the taglibs. We should find the right boundary between too big or too small jar files ... If there is too much jar files, people won't remind from where a functionality comes, or what are jar dependencies. As a result, they will use systematically all jar files ... Cedric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tiles broken
Hi Jeff, Strange error. I also use the provided ant file to compile Tiles and test them, and all seem to work fine for me. Nightly bin distribution also use this build file. Which page cause this error ? Is there a difference between the jar you are producing and the original one (size, content ?). Checking the build log file, I have discover a bug in a tiles tag constructor. This one is now corrected. But I don't think it is related to the error you encountered. Cedric Jeff Turner wrote: Hi, The Tiles from Struts CVS seems to be broken. I can compile it, but when I run the jar under Tomcat 4.0 rc2, it breaks with the error: javax.servlet.jsp.JspException: Error - Tag Insert : Can't get component definition 'doc.mainLayout'. Check if this name exist in component definitions. at org.apache.struts.taglib.tiles.InsertTag.processDefinitionName(InsertTag.java) at org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java) at org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java) at org.apache.jsp.index$jsp._jspService(index$jsp.java:69) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) The tiles war from the binary distribution works though. Here's the build log from an out-of-CVS compile: http://newgate.socialchange.net.au/~jeff/apache/jakarta/jakarta-struts/tiles-buildlog.txt Is anyone else playing with this stuff? thanks, --Jeff
Re: Tiles and Components Framework
I plan to have a stable version of Tiles, integrated into Struts, for middle september. You can consider that actual jsp tags name and attributes are stable. Implementation will slightly change in september, but not the behavior. I also plan a stable version of Tiles running with Struts 1.0 (but not integrated in Struts1.0) Actually, I'm not at my office, and haven't full access to network, just modem access. I read mails from time to time, and try to respond asap. I will be back home for end of august. For Struts integration, I would like to use Oleg's ServiceManager to initialize and serve Tiles, rather than extending ActionServlet, as actually done. But, this later option will certainly remain. I haven't hear about any issues on performance degradation. Cedric Sean wrote: I am working on writing a rather large real-time web application with Struts and was wondering what the timeframe was for either the 1.1 release or a stable integration of the Tiles Component Framework into the mainline. I see it in the nightlies but I was wondering if any advanced integration or other changes were going to be made to this framework to integrate it more? Any idea on the changes? Also ... has anyone noticed any performance degredation of the Component Framework on responce time for pages? Any guidance the developers can give to ease the migration of our development bed to this 1.1 release with maybe some insight into the timelines for this release I would appreciate it. Sean
Re: Insufficient Karma
I have explicitly do login, and also setup tunnel. Still have insufficient karma, and can't commit anything ;-( Cedric David Winterfeldt wrote: I was able to add directories too even though I couldn't check in a file. Did you explicitly login (if you're on windows)? cvs -d :pserver:dwinterfeldt@localhost:/home/cvs login http://jakarta.apache.org/site/cvsonwin32.html http://jakarta.apache.org/site/cvsonunix.html David --- Cedric Dumoulin [EMAIL PROTECTED] wrote: I have checkout project on my local pc. I have do checkout again in a clean place, but error remain ;-( What is strange is that module import has worked without error. Cedric David Winterfeldt wrote: Where do you have the project checked out from cvs? I was getting this error message when I was trying to work from the server. Craig said it sounded like the cvs checkout was anonymous when I had this problem. Once I did a checkout to my local pc, I could check things in. David P.S. - If you are trying to work from the server and you get this resovled, let me know. I'm having some problems with cvs on my local computer. --- Cedric Dumoulin [EMAIL PROTECTED] wrote: I have imported Tiles to Struts contrib. All work fine, except when I have tried to modify and commit the build.xml file. I've got an error Insufficient Karma (cedric|jakarta-struts). I 've got the same error when I try to commit files in tiles directory. What is the problem ? Cedric __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Insufficient Karma
I have imported Tiles to Struts contrib. All work fine, except when I have tried to modify and commit the build.xml file. I've got an error Insufficient Karma (cedric|jakarta-struts). I 've got the same error when I try to commit files in tiles directory. What is the problem ? Cedric
Re: Insufficient Karma
I have checkout project on my local pc. I have do checkout again in a clean place, but error remain ;-( What is strange is that module import has worked without error. Cedric David Winterfeldt wrote: Where do you have the project checked out from cvs? I was getting this error message when I was trying to work from the server. Craig said it sounded like the cvs checkout was anonymous when I had this problem. Once I did a checkout to my local pc, I could check things in. David P.S. - If you are trying to work from the server and you get this resovled, let me know. I'm having some problems with cvs on my local computer. --- Cedric Dumoulin [EMAIL PROTECTED] wrote: I have imported Tiles to Struts contrib. All work fine, except when I have tried to modify and commit the build.xml file. I've got an error Insufficient Karma (cedric|jakarta-struts). I 've got the same error when I try to commit files in tiles directory. What is the problem ? Cedric __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: Components -- Tiles
Ted Husted wrote: I think a key question is whether Tiles will still be easy to use outside of Struts. Tiles are not tightly couple with Struts. They should work without. But combining both bring new and powerful features to Struts and to Tiles. Furthermore, using tiles with Struts doesn't imply modification in Struts : actually, you just extends ActionServlet to initialize Tiles, and catch request forward. I know David would like his Validator to be useful outside the framework, and it should be easy for people to get the Validator, or Tiles, regardless of whether they use Struts. That's the way I go. I would like to still have Struts.jar and Tiles.jar separated. I wonder if we want to turn the contrib area into something more like the Commons or Taglibs areas, where the packages would be built seperately and available for individual download. Maybe this should be an optional area instead. Personally, I would like the main struts.jar to be as compact as possible, since this needs to be replicated for every Web application on a server. If convenient, we could call the optional packages struts-validator.jar and struts-tiles.jar, to link them all together, but let those that use them (me! me!), include them. I agree for individual packages. We certainly need to define more precisely how we will do. Having a contrib area with individual download and built will help to maintain Struts and contribs cleanly separated. However, it is often boring to download each needed library, so may be we will also need a way to download all in one. Cedric, I've lost track of the changes you needed to make to enable Struts integration with Tiles. Is this anything that could be done with Oleg's ServiceManager? Actually, integration is done by subclassing ActionServlet in order to : * initialize Tiles * Catch request forward. For that, I introduce a new method, called by those performing request.forward() In the future I will try to use Oleg's ServiceManager. No problem with initialization, but I have no idea yet for the second point. -Ted. Cedric Dumoulin wrote: Components framework will be renamed Tiles framework. Integration in Struts is a work in progress. I have already rename packages and updated webapps. I still need to update documentation and tutorial. Checkin will come very soon. Question is : how do we distribute it with Struts ? I can put it in the contrib section, but what about the Struts build process ? Tiles framework originally comes with 4 apps.war. I think to reduce it to 2 apps.war (doc and tutorial). My idea is to integrate build process of these apps.war in the Struts build process (by calling appropriate build.xml in Tiles), and have two new apps.war in the struts dist. Does this sound ok ? Is there any other ideas ? Cedric Tiles sites : http://www.lifl.fr/~dumoulin/tiles/ (mirror) : http://www.geocities.com/cedricdumoulin/tiles/
Components -- Tiles
Components framework will be renamed Tiles framework. Integration in Struts is a work in progress. I have already rename packages and updated webapps. I still need to update documentation and tutorial. Checkin will come very soon. Question is : how do we distribute it with Struts ? I can put it in the contrib section, but what about the Struts build process ? Tiles framework originally comes with 4 apps.war. I think to reduce it to 2 apps.war (doc and tutorial). My idea is to integrate build process of these apps.war in the Struts build process (by calling appropriate build.xml in Tiles), and have two new apps.war in the struts dist. Does this sound ok ? Is there any other ideas ? Cedric Tiles sites : http://www.lifl.fr/~dumoulin/tiles/ (mirror) : http://www.geocities.com/cedricdumoulin/tiles/
Struts doesn't compile under jdk1.4 beta
Trying to compile Struts with JDK1.4 beta doesn't work for me : the java.sql.Connection interface has change. As a result, class org/apache/struts/util/GenericConnection.java is missing some methods, and can't be compiled ;-(. I don't know if there is others issues with JDK1.4. Cedric
Re: [VOTE] Changing Struts 1.1 to depend on Commons Packages
+1 Cedric Craig R. McClanahan wrote: As I cc'd to this list, the 1.0 versions of the beanutils, collections, and digester packages have been released under the Commons project. Now that these are official 1.0 releases, I propose to modify the Struts 1.1 environment to depend on these packages, instead of the internal Struts versions (which have generally been deprecated). This will involve the following steps: * Modify the build environment to depend on these three packages * Modify internal Struts classes that rely on these packages to use the commons packages instead (normally just a change to the import statement). * Remove the internal versions of these classes. * Include these three packages in the Struts distribution (including inside the WAR files for each of the Struts web apps. * Modifying the appropriate documentation to mention the fact that these JARs, along with struts.jar, must be included in the /WEB-INF/lib directory of Struts-based web applications. Making these changes will allow Struts itself to remain focused on the framework and custom tag libraries, while also benefitting from improvements in these three packages made by other projects that utilize them. (In the future, we'll probably do the same thing with the generic connection pool). Is everybody OK with doing this? Craig
Re: New name for Components / Extended Templates?
As Components can be used to build views of the MVC framework, it could be interesting to have the term view in the new name. I have thought about viewlet, but this is already used ;-). Maybe viewparts or viewpieces ? This sound nice and can reflect the fact that framework is for building views by assembling parts/pieces of view. Comments ? Cedric Cedric Dumoulin wrote: Components / Extended Templates framework will be added to Struts shortly. It is now the last chance to rename this framework if necessary. Primary idea of the framework was to allow building of JSP pages by assembling reusable pieces of code, called blocks or components. One of the aims is to provide a library of easily reusable components (like standard layouts, but also reusable menus, common login form, shopping card, ...). Templating mechanism is naturally done with the framework, but framework can also provide a starting point for reusable components. So what's wrong with name components ? Component is a broad term in English, and it may be confusing when people talk about Struts components in general. So maybe we should change actual Components framework name. Why not renaming Components to templates ? Framework allow more than templating, If we call it templates, I am afraid that people identify framework with only the template mechanism, missing the ability to define reusable piece of pages. Also, this would break the actual templates implementation. After discussions with Ted Husted, we propose following alternatives : Framework name package name JSP pieces / Extended Templates (as a play on Java Faces ;-) jsp-pieces or pieces JSP Blocks jsp-blocks or blocks Dynamic Templates templates My preference goes to (JSP pieces / Extended Templates), jsp-pieces. I need your opinion on this renaming : * Do we really need to do it ? (A lot of peoples already use components. This could lead to troubles) * Which name do you prefer / propose ? Cedric
Re: Extensions to Struts
Components extension use some Struts utility classes (BeanUtils, ...), and extends ActionServlet in order to override the call to requestDispatcher.forward(). Unfortunately, in the actual ActionServlet implementation, we can't override directly this call, so I have introduce a method processForward(...) which is called by processActionForward(...) and processValidate(...). I will commit this change in Struts. Like that, I will provide an ComponentActionServlet(...) just overriding the appropriate method. So, to be short, Components just need to be able to override the call to forward() in ActionServlet(). Cedric Leland, Rob wrote: It would be nice if struts could be extended without having to place new code under the org.apache.struts.action classes, but just by dropping a separate jar file under some directory that would self-register. So what is the best way to extend struts so that it stays lean ? When I brought up the notion of 'Events' last November that was what I seeking to understand. Now that there are several extensions to struts that will soon be integrated, what approach makes the most sense ? if we start a discussion on this I would be willing to capture this knowledge/process on a web page. I am not suggesting that 'components' or 'validation' not be an integral part of struts. For those that have extended struts, What level of access did you need to the Action classes/methods to extend it? Did you need package level access ? I am looking at different patterns besides 'Events' such as decorator, strategy, etc trying to understand which if any of these would be useful.
Re: Templates and struts-config.xml parameters
Check the Components / Extended Templates proposal. It allows to : * Define template definition (url+attributes) in a central file (xml) * Define definition by inheritance * Use a template definition name as struts-config forward parameter * And much more ... Ideas that you propose are in Components, maybe in a slightly different way. Cedric Components sites : http://www.lifl.fr/~dumoulin/components/ (mirror) : http://www.geocities.com/cedricdumoulin/components/ Chris Miller wrote: First off, I've been off this mailing list for quite a while, so please excuse me if this has already been discussed (how can I search the mailing list easily?). I'm trying to set up a website using Struts' templating functionality, however I've run into a 'problem'. Looking at the Struts template example app, it seems to me that the way the templating engine works negates the point of using Struts in the first place! For every page on the site, there is a template JSP page, eg introduction.jsp, which contains something like: %@ taglib uri='/WEB-INF/struts-template.tld' prefix='template' % template:insert template='/chapterTemplate.jsp' template:put name='title' content='Templates' direct='true'/ template:put name='header' content='/header.html' / template:put name='sidebar' content='/sidebar.jsp' / template:put name='content' content='/introduction.html'/ template:put name='footer' content='/footer.html' / /template:insert And in struts-config.xml there's no 'introduction.do' action, rather the introduction.jsp page is referenced directly. Sure it's easy to change the header, sidebar, footer, but by using this approach I think we lose a lot of the benefits of Struts. As it stands, struts-config.xml no longer holds all of my JSP references, so restructuring the site is very difficult. It would be very nice to be able to completely eliminate the introduction.jsp page, and instead transfer the header/content etc definition into struts-config.xml. Is there a way to do this already that I've overlooked? If not, what I would like to see is the ability to assign parameters in struts-config.xml, so we could do something like this: global-forwards forward name=chapterTemplate path=/chapterTemplate.jsp /global-forwards global-params param name=header value=/header.html/ param name=sidebar value=/sidebar.jsp/ param name=footer value=/footer.html/ /global-params action path=/introduction type=ChapterTemplateAction param name=title value=Introduction/ param name=content value=/introduction.html/ /action ChapterTemplateAction would perform whatever setup was required, and then return the global chapterTemplate forward. chapterTemplate.jsp would be similar to the existing page in the template example app. It may be that we need parameters like I've specified above (which would be quite generic and useful for lots of things besides templating I suspect), and also say a template name=content value=/introduction.html/ tag to handle the templating side of things. I've glossed over a few details (such as how the parameters get put into request scope and passed through to chapterTemplate.jsp), but in principal at least, what do people think about this? Regards, Chris Miller
Re: PROPOSAL: Enhancement of templates
What you would like to do is to be able to use template parameters in logic tags. I have another solution to this problem : add a tag importing template parameter/attribute in jsp scope (page, request, ...), as a bean. Like this, you can use logic tag with the imported bean (which in reality is a simple String). !-- import template attribute in the specified scope -- template:importAttribute name=chapter scope=page / !-- Do what you want with the bean -- logic:present name=chapter ... /logic:present Advantages of this approach : * No need to modify existing logic tags * No template stuff in struts core library : Struts and templates still well separated * Imported bean value can be used in any others tags accepting a bean This proposed solution already exist in Components / Extended Templates. So, you can test it immediately ... Cedric Components sites : http://www.lifl.fr/~dumoulin/components/ (mirror) : http://www.geocities.com/cedricdumoulin/components/ Oleg V Alexeev wrote: Hello struts-dev, Now I use next scheme to pass parameters to the template page - --- page template:insert template=layout/main.jsp?chapter=news /template:insert - and check parameter 'chapter' in template. -- template - logic:present parameter=chapter ... /logic:present - But I think that this approach is not so flexible because of direct query string editing. For my mind constructions listed below is more preferable - --- page template:insert template=layout/main.jsp template:put name=chapter content=news direct=true/ /template:insert - -- template - logic:present template=chapter bean:define id=chapter template=chapter/ /logic:present - How about it? -- Best regards, Oleg mailto:[EMAIL PROTECTED]
Re: content map population
Incze Lajos wrote: On Tue, Mar 13, 2001 at 09:57:36AM +0100, Cedric Dumoulin wrote: Not yet, but in a few days I will provide such facilities for Templates. If you want to know how it will work, I have put an extract of a previous mail at the end of this mail. Cedric Will be this facility part of the 1.0 struts release or it is for the 1.1 (not-yet-existent) source tree? incze I see this facility as a starting point for "extended templates". It is certainly better to keep actual Templates for 1.0, and put new features, like this one, in 1.1. So, maybe the delay will be a little bit longer, but I hope not too much. Cedric
Re: JSP Components
Hi Francois, I have been confronted to a similar problem while building a portal page including several components containing different form. I have written an Action associated to the portal page, and one action for each form. The main Action calls each component's action, and forwards to the portal page (throw Struts mapping). Individual actions can still be used with their associated components. Another approach is to say that individual form don't forward to the portal action, but to their own action which after that forward to the portal page, or to another page. It could be interesting to be able to associate an action (or something similar) to a component. But we have to take care to stay compliant with Struts philosophy, and to not overload what already exist. I have no elegant solution yet, but I keep the idea in mind. Any thought is welcome ! In the meantime, don't forget that you can use the same Action class in different mapping, and that a mapping can forward to another Action ! Also, you can put a scriplet calling your "action" at the beginning of a component (JSP page). It is also possible to create and use a bean in the component using standard jsp tag. This bean performs what you want in it constructor ... Cedric P.S.: Sorry for this late answer, I have miss your previous post. Rey Francois wrote: I am reposting this item below because I haven't got any feedback since I posted it on 8 March. Just briefly, this is about the ability to perform an Action specific to a JSP component being reused. Right now it is not possible to make an action being automatically performed when including a JSP component. I'm sure some people would be able to comment (Craig and Cedric notably), because I think the topic of reusing JSP components is (IMHO) an interesting and essential one. Thanks in advance. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ -Original Message- From: Rey Francois [mailto:[EMAIL PROTECTED]] Sent: 08 March 2001 14:40 To: '[EMAIL PROTECTED]' Subject: JSP Components In the context of building reusable JSP components, I have been confronted with the following limitation that both the Struts templating and the Components from Cedric Dumoulin currently have. In a word, this limitation is actually due to the fact that none of them provide a way to perform an action specific to the included JSP. For example, an application home page may be composed of a body that actually corresponds to another page in the web application. In this case, the body is already modeled with a mapping and an action that performs the necessary logic to retrieve the dynamic content. When servicing the home page, one would logically like to reuse that action in order to avoid the duplication of its logic in the action servicing the home page. One way to do this would be to directly call the action to reuse within the perform() of the action servicing the home page. However this is not very flexible because it requires manual intervention. My short research in past postings actually seems to indicate that this problem has been mentioned before under various forms. A proposal for a portal framework was discussed before, and such framework would require such feature. In one instance the Jetspeed framework was considered for integration with Struts. In another case one talked about allowing the ActionServlet to do both forwards and includes. My questions then are: - has anybody else been confronted to this limitation, and if so, did you avoid the problem (for example by using frames) or did you find a solution? - would such a feature be considered for inclusion in either Struts or the Components framework from Cedric Dumoulin? - anybody having further thoughts on this issue? Thanks for your feedback on this topic. Franois Rey Financial WebSuite The Capital Markets Company http://www.capco.com/ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of The Capital Markets Company. http://www.capco.com *** The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, you must not read, use or disseminate the information contained in the email. Any views expressed in this message are those of the individ
