svn commit: r178611 - /struts/core/trunk/doc/announce.xml
Author: niallp Date: Wed May 25 23:40:46 2005 New Revision: 178611 URL: http://svn.apache.org/viewcvs?rev=178611view=rev Log: Update announcement page for Struts 1.2.7 Modified: struts/core/trunk/doc/announce.xml Modified: struts/core/trunk/doc/announce.xml URL: http://svn.apache.org/viewcvs/struts/core/trunk/doc/announce.xml?rev=178611r1=178610r2=178611view=diff == --- struts/core/trunk/doc/announce.xml (original) +++ struts/core/trunk/doc/announce.xml Wed May 25 23:40:46 2005 @@ -9,6 +9,22 @@ section name=Announcements +h4 id=a2005052626 May 2005 - Struts 1.2.7 (General Availability)/h4 +p +The Struts team is pleased to announce the release of Struts 1.2.7 for +General Availability. This release includes new +functionality, as well as numerous fixes for bugs which were reported +against the previous release, and supersedes the earlier 1.2.4 version +as the latest official release of Struts from The Apache Software +Foundation. +/p +p +The binary, source and library distributions are available from the +a href=http://struts.apache.org/download.cgi;Struts download page/a. +The a href=http://struts.apache.org/userGuide/release-notes.html;Release Notes/a +are available on the Struts web site. +/p +hr/ h4 id=a2005033131 March 2005 - New Struts PMC Chair/h4 p a href=http://struts.apache.org/volunteers.html#martinc;Martin Cooper/a has been appointed - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34849] - Expression Language Field Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34849 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 11:18 --- Clarifying based on a question in a private email: the added dependencies Collections and Lang are from how this validator is written; JEXL has no external dependencies of its own. It was suggested that commons-el might be an alternative to JEXL, and it would be consistent with JSTL and Tomcat -- this is true; however, one of the nice features of JEXL is its ability to invoke methods in addition to referencing bean properties. This ability is why the code in this ticket has a commons-lang dependency: the implementation adds instances of StringUtils and ArrayUtils to the expression evaluation context so that you can write richer expressions. The Collections dependency is on IteratorEnumeration, and is just an implementation detail of the PageContextImpl class attached to this ticket. It would be annoying to have to essentially rewrite that functionality, but there may be reasons why it would be justified, especially given the version compatibility issues which were circulating around commons-collections. I originally copied the taglib EnumeratedMap abstract class into a private class file defined within the ExpressionValidator class (my preferred name for what Lukas submitted as ELValidator). We *could* do this for all of these nagging dependencies, and/or copy them to public classes in an o.a.s.validator.expression package. This strategy would return us to a single dependency on JEXL at the cost of adding three or four classes to Struts which are really only for supporting this one (complex but useful) function. I kind of like squirreling them all inside the one class, to avoid the risk of people casually using them as public classes, but it makes for a very big class file. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35087] New: - New DownloadAction adjusting buffer size
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35087.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35087
Summary: New DownloadAction adjusting buffer size
Product: Struts
Version: 1.2.6 Beta
Platform: All
OS/Version: other
Status: NEW
Severity: normal
Priority: P3
Component: Standard Actions
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]
A review of the new DownloadAction code seems to have the following problem:
The getBufferSize method is defined:
protected int getBufferSize() {
return DEFAULT_BUFFER_SIZE;
}
But it does not appear to be used:
byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
A search of the code does indicate the getBufferSize method is actually called
anywhere, so overriding the method does not seem useful.
(Minor nits aside, the DownloadAction is very helpful -- thanks!)
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] New: - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 Summary: DownloadAction needs to be able to specify the name of the file on the browser side Product: Struts Version: 1.2.6 Beta Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Standard Actions AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] As the code is currently written the name of the file downloaded to the client machine is named FileDownload.do (or whatever the URL is). I believe the code needs something like this: response.setHeader(Content-Disposition, attachment; filename= + fileName); The user might want to control the filename, but personally I have been using the server-side name. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tiles Doesn't Pickup definitions stored in diffrent directory.
I am working on a project using struts and tiles in a Liferay portlet environment. The layout is relatively complex, and to organize the layout more, I wish to move some of my files into an organized directory structure. But whenever I try to move a JSP file 2 directories deeper from where it resides now it no longer tiles:include's the page. Is there a limit to how deep the directory structure can be in tiles? Andrew J. Leer Software Engineer MobilVox, Inc. * (724) 349-3339 x315 [EMAIL PROTECTED]
Inserting I8N resource definition keys into tiles puts
Is there any way to place internationalization definition keys into tiles puts? Andrew J. Leer Software Engineer MobilVox, Inc. * (724) 349-3339 x315 [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 16:10 --- +1 from me. i asked about this before ... but there was no response imho, the best method would be to modify StreamInfo to include getFilename() method. the concrete StreamInfo classes can easily do this. also, a concrete StreamInfo class, that just takes an [Buffered]InputStream would be very useful. this would come in handy when large objects (binary, blob, clob) are streamed ( quite often for me :) ) direct from a database. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 16:30 --- Created an attachment (id=15178) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15178action=view) streaminfo modification changes :: 1) included new metthod ( public String getFilename(); ) in StreamInfo 2) included 1 more concrete implementation of StreamInfo called StreamStreamInfo as a (kindof) base implementation of StreamInfo 3) modified existing concrete StreamInfo classes to extend StreamStreamInfo and added new method in StreamInfo -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34849] - Expression Language Field Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34849.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34849
--- Additional Comments From [EMAIL PROTECTED] 2005-05-26 16:52 ---
About copying the ArrayUtils and StringUtils - I would prefer to avoid the
implementation freze I mean if we copy the implementation we would have to
keep it up to date whenever someone changes something in these classes in
commons.lang.
I would prefer conditional inclusion that would not create dependency on lang:
Instead of
jc.getVars().put(arrayUtils, new ArrayUtils());
we can replace it with the:
try {
Class arrayUtilsClass =
Class.forName(org.apache.commons.lang.ArrayUtils);
jc.getVars().put(arrayUtils, arrayUtilsClass.newInstance());
} catch (ClassNotFoundException e) {
log.warn(org.apache.commons.lang.ArrayUtils not found. The
'arrayUtils' object will not be available in ExpressionValidator context.);
} catch (InstantiationException e) {
log.warn(org.apache.commons.lang.ArrayUtils not found. The
'arrayUtils' object will not be available in ExpressionValidator context.);
} catch (IllegalAccessException e) {
log.warn(org.apache.commons.lang.ArrayUtils not found. The
'arrayUtils' object will not be available in ExpressionValidator context.);
}
Which means if user includes commons lang the arrayUtils will be available, if
not user will not have this object. The same can be done with the StringUtils,
although we need to copy two methods that are used in the code. It allows us to
avoid lang package but we will need to document it a little better since it will
be confusing for the users.
Another thing that should be done when we agree that the class discovery is the
correct approach - the object should be created/discovered during the startup,
not upon every call to validate method - the static block (that instantiates the
arrayUtils/stringUtils) and static variable should be the best approach.
Also to avoid collection dependency I would include EnumeratedMap as private
class of ExpressionValidator and IteratorEnumeration as private class in
PageContextImpl.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/25/05, Riyaz Mansoor [EMAIL PROTECTED] wrote:
just a thought.
ie, not expose the properties object (as it is) by the
getProperties,setProperties methods.
I'm not sure I want to forbid config subclasses from accessing
their properties directly. I've come across several libraries
and frameworks which used private all throughout and made it
difficult if not impossible for me to customize certain behavior.
(I'm still running into those issues with the app I inherited
here in my day job.)
The 'properties' field was initially declared as protected when
it was only in ActionConfig. The goal was to reduce the likelihood
that subclasses would be needed. Now that it's in a class that's
intended to be subclassed, I wonder why it became private. Joe?
by my last viewing of the Config
classes, only ActionConfig uses properties and needs to change for
this - not much.
We also need it in FormBeanConfig.
get/setProperties can be replaced by
void inheritProperties(childConfig) {
// for each xx property in (parent) class
// if childConfig.getProperty(xx) == null
// copy the arbitrary property
}
imho, i think this is a good way to do this, provides separation between
BaseConfig and its extending classes
BaseConfig already has an inheritProperties(BaseConfig) method, doing just
what you've outlined. This is used by subclasses when extending another
config object, not to be confused with the need to copy another config
object, which is when ActionConfig and FormBeanConfig needs access to the
properties field.
Hubert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
Hubert Rabago wrote: I'm not sure I want to forbid config subclasses from accessing their properties directly. I've come across several libraries and frameworks which used private all throughout and made it difficult if not impossible for me to customize certain behavior. (I'm still running into those issues with the app I inherited here in my day job.) The 'properties' field was initially declared as protected when it was only in ActionConfig. The goal was to reduce the likelihood that subclasses would be needed. Now that it's in a class that's intended to be subclassed, I wonder why it became private. Joe? there is a getProperties() method which retrieves the properties object my intention here was to have _all_ the accessor methods of properties in BaseConfig - i guess it can be a hinderance when the classes a changing rapidly as u've mentioned. i think of it as a 'cleaner' way :) classes, only ActionConfig uses properties and needs to change for this - not much. We also need it in FormBeanConfig. :) BaseConfig already has an inheritProperties(BaseConfig) method, doing just what you've outlined. This is used by subclasses when extending another config object, not to be confused with the need to copy another config object, which is when ActionConfig and FormBeanConfig needs access to the properties field. yes, very recently added :). again, what am trying to say is that instead of moving the properties object (using getProperties()) the properties can be inherited without retrieving the whole properties object. eg: pass the childConfig to the ParentConfig instead of the passing the parentConfig (baseConfig) to the childConfig. again, extending classes would have limited access to the properties object. it comes down to the first point u made. :) ie: I'm not sure I want to forbid config subclasses from accessing their properties directly. I've come across several libraries and frameworks which used private all throughout and made it difficult if not impossible for me to customize certain behavior. different ways of thinking ;) riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Could someone on the dev team add link to mailing list on Struts site
From: Niall Pemberton [EMAIL PROTECTED] Ted Husted made the change, I refreshed the site and Jack provided the FUD :-) Thanks... I don't suppose someone could be convinced to change the rest of the broken links to mail-archives.apache.org? It's somewhat unfair to chide people for not searching the archives when the links don't work. There's one here: http://struts.apache.org/using.html#Questions I started to make a patch last night, but I wanted to link directly to the list of archives on http://struts.apache.org/mail.html, and unfortunately there are no anchors on that page. There should be an anchor for every section, like there are in the user guide, but I don't know enough XSL to make that happen. :( Thanks, -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34849] - Expression Language Field Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34849 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 20:09 --- I think Lukas' suggestion is a decent one, with the caveat that we would check the thread for a context class loader rather than directly using Class.forName()... On the other hand, I wouldn't feel too bad about adding a commons-lang dependency just because it might be useful in many places. I think maybe for the IterationEnumerator, the private class approach is better, as Lukas suggested. Opinions on a compile time dependency on commons-lang? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 20:35 --- I wouldn't want to hard-code a content disposition, since sometimes you might want attachment while other times you might want inline, depending on the specific browser being used, and depending on the MIME type of the particular file being downloaded. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/26/05, Riyaz Mansoor [EMAIL PROTECTED] wrote: Hubert Rabago wrote: my intention here was to have _all_ the accessor methods of properties in BaseConfig - i guess it can be a hinderance when the classes a changing rapidly as u've mentioned. i think of it as a 'cleaner' way :) That's what we have now, accessors of properties in BaseConfig. In fact, that's the only way to access them, which goes against the convention set by most (if not all) other config objects. Other config objects declare their fields as protected, allowing custom subclasses to access those fields directly. I'll probably change properties in BaseConfig to follow this convention. eg: pass the childConfig to the ParentConfig instead of the passing the parentConfig (baseConfig) to the childConfig. It took me a while to understand what you were saying here, but I think I finally get it. I'm not opposed to the idea, but stepping back, I'm not entirely convinced that one is cleaner than the other. We've been discussing this only from the perspective of copying arbitrary properties of config objects held by an ActionConfig. The rest of the config objects have been doing child-inherits-from-parent as well. If parent-sets-child-values is truly that much better, I'd want to use that for the rest of the config objects. Not just when copying full config, but also when extending overridden configs. again, extending classes would have limited access to the properties object. This point is independent of parent-sets-child-values vs. child-inherits-from-parent. Whichever wins out there, doesn't convince me that superclasses should forbid subclasses from accessing fields. it comes down to the first point u made. :) ie: I'm not sure I want to forbid config subclasses from accessing their properties directly. I've come across several libraries and frameworks which used private all throughout and made it difficult if not impossible for me to customize certain behavior. different ways of thinking ;) Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? Hubert riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35087] - New DownloadAction adjusting buffer size
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35087. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35087 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 20:53 --- This has already been fixed in 1.2.7 (which is now a GA release) and in trunk. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r178669 - /struts/core/trunk/doc/mail.xml
Author: niallp Date: Thu May 26 12:23:02 2005 New Revision: 178669 URL: http://svn.apache.org/viewcvs?rev=178669view=rev Log: Change ASF Mail Archive Link, add anchors and add dev list to list of archives Modified: struts/core/trunk/doc/mail.xml Modified: struts/core/trunk/doc/mail.xml URL: http://svn.apache.org/viewcvs/struts/core/trunk/doc/mail.xml?rev=178669r1=178668r2=178669view=diff == --- struts/core/trunk/doc/mail.xml (original) +++ struts/core/trunk/doc/mail.xml Thu May 26 12:23:02 2005 @@ -21,7 +21,7 @@ body -section name=Mailing Lists - Guidelines +section name=Mailing Lists - Guidelines href=Guidelines pA mailing list is an electronic discussion forum that anyone can subscribe to. When someone sends an email message to the mailing list, @@ -142,17 +142,30 @@ /section -section name=Archives +section name=Archives href=Archives pArchives Carrying Struts Lists/p ul -lia href=http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=41;List Index on mail-archives.apache.org/a/li -lia href=http://www.mail-archive.com/user%40struts.apache.org/;Mail-Archive/a/li -lia href=http://marc.theaimsgroup.com/?l=struts-useramp;r=1amp;w=2;MARC: Mailing list ARChives/a/li +lia href=http://mail-archives.apache.org/;ASF Mail Archives/a/li +liMail-Archive/li + ul + lia href=http://www.mail-archive.com/user%40struts.apache.org/;User list/a/li + lia href=http://www.mail-archive.com/dev%40struts.apache.org/;Dev. list/a/li + /ul +liGmane/li + ul + lia href=http://news.gmane.org/gmane.comp.jakarta.struts.user/;User List/a/li + lia href=http://news.gmane.org/gmane.comp.jakarta.struts.devel/;Dev. List/a/li + /ul +liMailing list ARChives/li + ul + lia href=http://marc.theaimsgroup.com/?l=struts-useramp;r=1amp;w=2;User List/a/li + lia href=http://marc.theaimsgroup.com/?l=struts-devamp;r=1amp;w=2;Dev. List/a/li + /ul lia href=http://www.servlets.com/archive/servlet/SummarizeList?listName=struts-user;Servlets.com servlet and JSP list archives/a/li /ul /section -section name=Subscribing +section name=Subscribing href=Subscribing p Now that you've read the guidelines (you emhave/em read the rest of the page, haven't you?), please subscribe to whichever Struts lists are of interest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r178671 - /struts/core/trunk/doc/using.xml
Author: niallp Date: Thu May 26 12:36:09 2005 New Revision: 178671 URL: http://svn.apache.org/viewcvs?rev=178671view=rev Log: Update Mailing List links Modified: struts/core/trunk/doc/using.xml Modified: struts/core/trunk/doc/using.xml URL: http://svn.apache.org/viewcvs/struts/core/trunk/doc/using.xml?rev=178671r1=178670r2=178671view=diff == --- struts/core/trunk/doc/using.xml (original) +++ struts/core/trunk/doc/using.xml Thu May 26 12:36:09 2005 @@ -109,9 +109,9 @@ p Before joining any Apache mailing list, please be sure to read the -a href=mail.htmlMailing List Guidelines/a. +a href=mail.html#GuidelinesMailing List Guidelines/a. If you have read and understood these guidelines, you are welcome to -a href=mail.htmljoin the Struts mailing lists/a. +a href=mail.html#Subscribingjoin the Struts mailing lists/a. /p /section @@ -119,9 +119,9 @@ section name=Posting a Question to a Mailing List href=Questions p -Before posting a new question, be sure to consult the -a href=http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=41; -strongMAILING LIST ARCHIVE/strong/a and the very excellent +Before posting a new question, be sure to consult one of the +a href=mail.html#Archives +strongMailing List Archives/strong/a and the very excellent a href=http://www.catb.org/~esr/faqs/smart-questions.html; How To Ask Questions The Smart Way/a by Eric Raymond. /p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tiles] Subproject Questions
Ted Husted has convinced me that Tiles should, afterall, be a Struts subproject. But I have a couple of questions. First, should I put this in a directory called struts/tiles? There's already a Struts top- level directory named tiles, so reusing that name might cause confusion. Should I name it tiles-standalone, or something like that? Second, I'm not sure about packages. Right now, I've got org.apache.tiles instead of the original org.apache.struts.tiles, but of course, that will break existing code. OTOH, if I switch back to the original package names, then we run the risk of clashing with the Struts packages. Thoughts? david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
Hubert Rabago wrote: That's what we have now, accessors of properties in BaseConfig. In fact, that's the only way to access them, which goes against the convention set by most (if not all) other config objects. Other config objects declare their fields as protected, allowing custom subclasses to access those fields directly. I'll probably change properties in BaseConfig to follow this convention. at the moment the getProperties() returns the Map object. no necessity for the 2 accessor methods getProperty,setProperty Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? don't know about that :) but yes the officially (if it can be called that) seems to be to make fields private and provide accessor methods. riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/26/05, Riyaz Mansoor [EMAIL PROTECTED] wrote: at the moment the getProperties() returns the Map object. no necessity for the 2 accessor methods getProperty,setProperty The getProperties()/setProperties() accessors are protected and are for subclasses. The getProperty()/setProperty() accessors are public, for use by everyone else. Hubert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Tiles] Subproject Questions
Would it make sense to rename the current struts/tiles directory struts/struts-tiles and it would eventually serve as the glue between struts/core and struts/tiles? For the time being it would have a copy of tiles but eventually struts would use the stand-alone tiles jar. The struts-tiles bridge code could also move back into core since supporting tiles could be considered a core feature of struts at this point, the same way supporting validator is core. -Original Message- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Thursday, May 26, 2005 4:59 PM To: Struts Developers List Subject: [Tiles] Subproject Questions Ted Husted has convinced me that Tiles should, afterall, be a Struts subproject. But I have a couple of questions. First, should I put this in a directory called struts/tiles? There's already a Struts top- level directory named tiles, so reusing that name might cause confusion. Should I name it tiles-standalone, or something like that? Second, I'm not sure about packages. Right now, I've got org.apache.tiles instead of the original org.apache.struts.tiles, but of course, that will break existing code. OTOH, if I switch back to the original package names, then we run the risk of clashing with the Struts packages. Thoughts? 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]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 --- Additional Comments From [EMAIL PROTECTED] 2005-05-26 23:19 --- maybe other browsers don't support it (IE and Firefox gives no problems). but i would support inclusion of filename perhaps a compromise: an extra option which allows the setting of the filename or not (in InputStream)? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
Hubert Rabago wrote: Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? i suppose a middle ground would be to keep the properties object protected but provide and use only accessor methods within struts? :) riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Subproject Questions
At 2:59 PM -0600 5/26/05, David Geary wrote: Ted Husted has convinced me that Tiles should, afterall, be a Struts subproject. But I have a couple of questions. First, should I put this in a directory called struts/tiles? There's already a Struts top-level directory named tiles, so reusing that name might cause confusion. Should I name it tiles-standalone, or something like that? Second, I'm not sure about packages. Right now, I've got org.apache.tiles instead of the original org.apache.struts.tiles, but of course, that will break existing code. OTOH, if I switch back to the original package names, then we run the risk of clashing with the Struts packages. Thoughts? Perhaps tiles2, following precedent set by several other Apache projects? This would only be for the root directory name, and the code could use org.apache.struts.tiles freely, although I personally wouldn't object to it being org.apache.tiles even if it lives as a Struts subproject. I don't think I have a strong feeling as to which is better. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
If I understood what you're saying, then yes, that's how all other config fields are, and I'll probably change 'properties' to conform to that (unless someone else beats me to it). Hubert On 5/26/05, Riyaz Mansoor [EMAIL PROTECTED] wrote: Hubert Rabago wrote: Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? i suppose a middle ground would be to keep the properties object protected but provide and use only accessor methods within struts? :) riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Patch for org.apache.shale.remote.ResponseWrapper
Shane,
(Late response due to just returning from vacation).
It's certainly on topic to post about Shale here -- but the best way
to ensure that patches don't get lost is to file them in our issue
tracking system:
http://issues.apache.org/bugzilla/
The patch can either be listed directly in the bug report (if it's
simple like this one), or added as an attachment if it's larger.
Craig
On 5/23/05, Shane Bryzak [EMAIL PROTECTED] wrote:
I hope this is the right place to post patches... anyway, I found a
small bug in the ResponseWrapper class. Patch as follows.
Index: ResponseWrapper.java
===
--- ResponseWrapper.java(revision 177960)
+++ ResponseWrapper.java(working copy)
@@ -259,7 +259,7 @@
if (open) {
writer.write(/);
-writer.close();
+close();
} else {
writer.write(/);
writer.write(name);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34849] - Expression Language Field Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34849 --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 00:01 --- I have no problem with a compile-time dependency on Commons Lang, or on Commons Collections, for that matter. It really bugs me that we keep wanting to clone classes from Commons packages - that were originally part of Struts before we consciously extracted them - just to avoid a dependency on packages that are generally useful in the first place. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Subproject Questions
I would also vote for org.apache.tiles - my guess it would be more platable to other frameworks if there isn't a struts in the name. It might make people think there was a struts dependency with struts in the package name. Also, if the consensus is to move out as a TLP in the future, then there wouldn't be a need to change package names at that point. Excellent points. I agree with that reasoning. sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Subproject Questions
I agree as well. Hubert On 5/26/05, Sean Schofield [EMAIL PROTECTED] wrote: I would also vote for org.apache.tiles - my guess it would be more platable to other frameworks if there isn't a struts in the name. It might make people think there was a struts dependency with struts in the package name. Also, if the consensus is to move out as a TLP in the future, then there wouldn't be a need to change package names at that point. Excellent points. I agree with that reasoning. sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Tiles] Subproject Questions
On 5/26/05, Niall Pemberton [EMAIL PROTECTED] wrote: - Original Message - From: David Geary [EMAIL PROTECTED] Sent: Thursday, May 26, 2005 9:59 PM Ted Husted has convinced me that Tiles should, afterall, be a Struts subproject. But I have a couple of questions. First, should I put this in a directory called struts/tiles? There's already a Struts top- level directory named tiles, so reusing that name might cause confusion. Should I name it tiles-standalone, or something like that? My vote would be to use tiles - it makes the most sense, even if in the short term it creates confusion. I would suggest renaming the existing tiles sub-project to something like struts-tiles. The advantage of svn is that its easy to re-arrange in the future. You could stick all your stuff in the sandbox intially so that people can have a look at it. Once its ready for prime time, we could then re-organise the sub-project names. I don't like the idea of using a 'struts-' prefix, since it's not meaningful. I do think that tiles is the right prime-time name. In the meantime, I would suggest either using tiles inside the sandbox, or tiles-standalone outside the sandbox. (I don't recall what we decided about whether this is actually an accepted subproject already, or a good idea that we expect to become an accepted subproject soon. We should pick one of the above based on what we actually decided. ;) Second, I'm not sure about packages. Right now, I've got org.apache.tiles instead of the original org.apache.struts.tiles, but of course, that will break existing code. OTOH, if I switch back to the original package names, then we run the risk of clashing with the Struts packages. I would also vote for org.apache.tiles - my guess it would be more platable to other frameworks if there isn't a struts in the name. It might make people think there was a struts dependency with struts in the package name. Also, if the consensus is to move out as a TLP in the future, then there wouldn't be a need to change package names at that point. +1 for o.a.tiles. I'm not too terribly worried about breaking peoples' code, since I suspect that the vast majority of people use Tiles without coding to its API, in which case there is very little, if anything, that will need updating if/when the package name changes. -- Martin Cooper Thoughts? 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: copy properties for inheritance (Re: svn commit: r178550)
On 5/26/05, Hubert Rabago [EMAIL PROTECTED] wrote: On 5/26/05, Riyaz Mansoor [EMAIL PROTECTED] wrote: Hubert Rabago wrote: my intention here was to have _all_ the accessor methods of properties in BaseConfig - i guess it can be a hinderance when the classes a changing rapidly as u've mentioned. i think of it as a 'cleaner' way :) That's what we have now, accessors of properties in BaseConfig. In fact, that's the only way to access them, which goes against the convention set by most (if not all) other config objects. Other config objects declare their fields as protected, allowing custom subclasses to access those fields directly. I'll probably change properties in BaseConfig to follow this convention. eg: pass the childConfig to the ParentConfig instead of the passing the parentConfig (baseConfig) to the childConfig. It took me a while to understand what you were saying here, but I think I finally get it. I'm not opposed to the idea, but stepping back, I'm not entirely convinced that one is cleaner than the other. We've been discussing this only from the perspective of copying arbitrary properties of config objects held by an ActionConfig. The rest of the config objects have been doing child-inherits-from-parent as well. If parent-sets-child-values is truly that much better, I'd want to use that for the rest of the config objects. Not just when copying full config, but also when extending overridden configs. again, extending classes would have limited access to the properties object. This point is independent of parent-sets-child-values vs. child-inherits-from-parent. Whichever wins out there, doesn't convince me that superclasses should forbid subclasses from accessing fields. it comes down to the first point u made. :) ie: I'm not sure I want to forbid config subclasses from accessing their properties directly. I've come across several libraries and frameworks which used private all throughout and made it difficult if not impossible for me to customize certain behavior. different ways of thinking ;) Yes, but it doesn't mean I'm not open to other ideas. In this case, I started out reading from everywhere that fields should be private, and everything should go through accessors (even subclasses). But I've been burned by that restriction LOTs of times (in some cases, I had to rebuild entire libraries to get access to the fields I needed), so I'll need some convincing. If private fields are what's best, how come every other config field is protected? I'm not sure how you can be burned by not having direct access to a member while there are getters and setters available. On the other hand, making a member directly accessable severely curbs the ability to change the class implementation without breaking backwards compatibility. Suppose at some point that you decide you don't want to keep a reference to the member in the class, but retrieve it on the fly. Or perhaps you decide that you want to keep the reference in a cache of weak references. You're hosed, because any code that used that member is now broken. This is something that I really dislike in a lot of the Struts code. For much of it, it's no doubt too late to change. However, I'd very much prefer that we don't continue to exacerbate the problem. -- Martin Cooper Hubert riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34849] - Expression Language Field Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34849 --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 00:44 --- OK, then. Martin, I totally see your point -- I just can't recall the current state of affairs regarding the hubbub around incompatibilities in versions of Commons Collections; has that all been ironed out? Is it really a non-issue? If any other committers seriously object to adding these dependencies, please speak up now. I would still copy the one class out of the taglib package, as I think it's wrong for Struts to depend on that. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34849] - Expression Language Field Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34849 [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2.5 Milestone --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 00:59 --- I'm against adding a dependency on Commons Collections, because of the incompatibility problems they created between 2.1 and 3.0 and because IteratorEnumeration (http://tinyurl.com/98qgt) is such aminor piece of functionality. Also theres an existing alternative solution - we already have an IteratorAdapter in the utils package - changing the method [i.e. PageContextImpl.getAttributeNamesInScope()] to return an Iterator rather than an Enumeration would mean there would be no need to add/copy any additonal classes to struts. I haven't looked in detail, but I believe that switching to an Iterator also then removes the jstl dependency? On the dependency on Commons Lang - the two utility classes are just stored in the PageContext - all the validator does is instantiate them, so I am against creating a dependecny here and would prefer Lukasz's suggestion of just using reflection to instantiate these objects. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34849] - Expression Language Field Validator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34849. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34849 --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 01:15 --- (In reply to comment #8) Lukasz I agree with the points you made are probably true - that it will be far easier to use than validwhen and that most people will be able to use it without any real assistance. Having said that not every user is brilliant and able to work these things out themseleves or navigate over to the docs on the JEXL site and I believe we're still going to get a whole load of questions on the user list and I don't think your answer addressed the issues I raised: 1) Are you prepared to support this on the user list? 2) Are you willing to provide documentation for the validator user guide? 3) Are you willing to provide some examples in the struts-examples webapp? 4) Are you willing to provide unit tests for this validator? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Struts 1.2.7 (General Availabilty)
The Struts team is pleased to announce the release of Struts 1.2.7 for General Availability. This release includes new functionality, as well as numerous fixes for bugs which were reported against the previous release, and supersedes the earlier 1.2.4 version as the latest official release of Struts from The Apache Software Foundation. The binary, source and library distributions are available from the Struts download page: http://struts.apache.org/download.cgi The Release Notes are available on the Struts web site at: http://struts.apache.org/userGuide/release-notes.html -- Niall Pemberton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsRelease127 by NiallPemberton
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by NiallPemberton: http://wiki.apache.org/struts/StrutsRelease127 -- || '''#''' || '''Description''' || '''Completed''' || || B1. || Create Sums and Sign Distributions [2] || (./) || || B2. || Request new Bugzilla version level (1.2.7) || (./) || - || B3. || Update Acquiring page on website and Test Downloads || No || + || B3. || Update Acquiring page on website and Test Downloads || (./) || == Vote (B) == || PMC Member || Quality || + + '''N.B.''' Voted 'GA Quality in first vote (see Vote A above) Voting continues until a GA or withdraw vote passes, or there is a subsequent release. @@ -128, +130 @@ == General Availability Checklist (C) == || '''#''' || '''Description''' || '''Completed''' || - || C1. || Copy Distribution to Mirrored Directories [3] || No || + || C1. || Copy Distribution to Mirrored Directories [3] || (./) || - || C2. || Deploy JAR to Apache Java-Repository || No || + || C2. || Deploy JAR to Apache Java-Repository || (./) || - || C3. || After 24 hours, update Acquiring page on website || No || + || C3. || After 24 hours, update Acquiring page on website || (./) || - || C4. || Post an announcement to lists and website || No || + || C4. || Post an announcement to lists and website || (./) || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)
Hooray! Many thanks, Niall, for driving this one. -- Martin Cooper On 5/26/05, Niall Pemberton [EMAIL PROTECTED] wrote: The Struts team is pleased to announce the release of Struts 1.2.7 for General Availability. This release includes new functionality, as well as numerous fixes for bugs which were reported against the previous release, and supersedes the earlier 1.2.4 version as the latest official release of Struts from The Apache Software Foundation. The binary, source and library distributions are available from the Struts download page: http://struts.apache.org/download.cgi The Release Notes are available on the Struts web site at: http://struts.apache.org/userGuide/release-notes.html -- Niall Pemberton - 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]
svn commit: r178712 - /struts/core/trunk/doc/learning.xml
Author: niallp Date: Thu May 26 16:37:53 2005 New Revision: 178712 URL: http://svn.apache.org/viewcvs?rev=178712view=rev Log: Change reference to mailing list archive Modified: struts/core/trunk/doc/learning.xml Modified: struts/core/trunk/doc/learning.xml URL: http://svn.apache.org/viewcvs/struts/core/trunk/doc/learning.xml?rev=178712r1=178711r2=178712view=diff == --- struts/core/trunk/doc/learning.xml (original) +++ struts/core/trunk/doc/learning.xml Thu May 26 16:37:53 2005 @@ -194,9 +194,9 @@ p The Struts a href=using.html#ListsMailing Lists/a are a treasure trove of useful, interactive information. The user list tends to carry a high -volume, so always check the published documentation and the -a href=http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=42; -strongMAILING LIST ARCHIVE/strong/a before +volume, so always check the published documentation and one of the +a href=mail.html#Archives +strongMAILING LIST ARCHIVES/strong/a before a href=http://www.catb.org/~esr/faqs/smart-questions.html;posting a new question/a. Like as not, it's already been asked and answered. @@ -204,9 +204,9 @@ p If you really can't find the answer to your question in the -a href=#faqsFAQs/a or -a href=http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=42; -list archive/a, you can post your query to the Struts User list -- +a href=#faqsFAQs/a or one of the +a href=mail.html#Archives +list archives/a, you can post your query to the Struts User list -- strongBUT YOU MUST SUBSCRIBE TO THE a href=mailto:[EMAIL PROTECTED]USER LIST/a OR THE a href=mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Could someone on the dev team add link to mailing list on Struts site
Done. Apologies Wendy, normally we credit people in the commit message - I'm afraid I forgot, but thanks for raising/suggesting this. Niall - Original Message - From: Wendy Smoak [EMAIL PROTECTED] Sent: Thursday, May 26, 2005 5:55 PM Thanks... I don't suppose someone could be convinced to change the rest of the broken links to mail-archives.apache.org? It's somewhat unfair to chide people for not searching the archives when the links don't work. There's one here: http://struts.apache.org/using.html#Questions I started to make a patch last night, but I wanted to link directly to the list of archives on http://struts.apache.org/mail.html, and unfortunately there are no anchors on that page. There should be an anchor for every section, like there are in the user guide, but I don't know enough XSL to make that happen. :( Thanks, -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)
Should not the announcement read supersedes the earlier versions? This would include obsoleted 1.2.6, which is not available as beta version anymore. On 5/26/05, Niall Pemberton [EMAIL PROTECTED] wrote: The Struts team is pleased to announce the release of Struts 1.2.7 for General Availability. This release includes new functionality, as well as numerous fixes for bugs which were reported against the previous release, and supersedes the earlier 1.2.4 version as the latest official release of Struts from The Apache Software Foundation. The binary, source and library distributions are available from the Struts download page: http://struts.apache.org/download.cgi The Release Notes are available on the Struts web site at: http://struts.apache.org/userGuide/release-notes.html -- Niall Pemberton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Archive Re-organisation
I've done some re-organisation of http://archive.apache.org/dist/struts - mainly moving stuff from the jakarta lib (i.e. http://archive.apache.org/dist/jakarta/struts) so that old versions are all in one place (although I left a copy of the 1.1 version there for now). It appears that whatever is in http://www.apache.org/dist/struts is copied into the archive - so maybe, putting them in sepearte directories wasn't a good idea? Also I could only find one Struts 1.0.x version (i.e. 1.0.2) if anyone knows where version 1.0 lives (and wasn't there a 1.0.3?) it would be good to move that/them as well. Niall P.S. I also added a link to the archive on the download pages: http://struts.apache.org/download.cgi http://struts.apache.org/acquiring.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: copy properties for inheritance (Re: svn commit: r178550)
On 5/26/05, Martin Cooper [EMAIL PROTECTED] wrote: I'm not sure how you can be burned by not having direct access to a member while there are getters and setters available. My mistake. The cases that keep flashing in my head provided getters (if even that) but no setters. In those cases, I had problems because the superclass would use the instance without going through the getter, so even if I overrode the getter, I couldn't make the change the behavior of the superclass. Hubert On the other hand, making a member directly accessable severely curbs the ability to change the class implementation without breaking backwards compatibility. Suppose at some point that you decide you don't want to keep a reference to the member in the class, but retrieve it on the fly. Or perhaps you decide that you want to keep the reference in a cache of weak references. You're hosed, because any code that used that member is now broken. This is something that I really dislike in a lot of the Struts code. For much of it, it's no doubt too late to change. However, I'd very much prefer that we don't continue to exacerbate the problem. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)
Thanks, Niall ! Hubert On 5/26/05, Martin Cooper [EMAIL PROTECTED] wrote: Hooray! Many thanks, Niall, for driving this one. -- Martin Cooper On 5/26/05, Niall Pemberton [EMAIL PROTECTED] wrote: The Struts team is pleased to announce the release of Struts 1.2.7 for General Availability. This release includes new functionality, as well as numerous fixes for bugs which were reported against the previous release, and supersedes the earlier 1.2.4 version as the latest official release of Struts from The Apache Software Foundation. The binary, source and library distributions are available from the Struts download page: http://struts.apache.org/download.cgi The Release Notes are available on the Struts web site at: http://struts.apache.org/userGuide/release-notes.html -- Niall Pemberton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 03:01 --- Unless I as the consumer of the DownloadAction have the ability to control its destination (filename), I don't see how I can take advantage of the Action class. The end user does not want a file named MyDownloadAction.do. There may well be other use cases, but my present circumstance simply has the user requesting a particular file with the expectation of it arriving with the same name as the file the user requested. I had just completed writing my own DownloadAction when I discovered the 1.2.6/7 addition; as you might expect my code bears remarkable resemblance to the class being added to the standard offering. My version uses content-disposition (no surprise). I am arguing that the author of the DownloadAction subclass should have the option of specifying the content-disposition (or some other means of controlling the filename on receipt) within whatever limits the browsers pose. I believe that we are all headed in the same general direction... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsFileDownload by NiallPemberton
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by NiallPemberton:
http://wiki.apache.org/struts/StrutsFileDownload
--
== Content Disposition ==
=== Setting the Content Disposition ===
- DownloadAction doesn't cater for setting the content dispositon header. I
guess at the moment the best way to do that would be override the execute()
method and set it first, something like this...
+ DownloadAction doesn't cater for setting the content dispositon header. The
easiest way is set it in the getStreamInfo() method, for example...
{{{
public class ExampleFileDownload extends DownloadAction{
-
protected StreamInfo getStreamInfo(ActionMapping mapping,
@@ -204, +203 @@
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
+
+ // File Name
+ String fileName = mapping.getParameter();
+
+ // Set the content disposition
+ response.setHeader(Content-disposition,
+attachment; filename= + fileName);
// Download a pdf file - gets the file name from the
// Action Mapping's parameter
String contentType = application/pdf;
- File file = new File(mapping.getParameter());
+ File file = new File(fileName);
return new FileStreamInfo(contentType, file);
- }
-
- public ActionForward execute(ActionMapping mapping,
- ActionForm form,
- HttpServletRequest request,
- HttpServletResponse response)
- throws Exception {
-
- response.setHeader(Content-disposition,
-attachment; filename= + mapping.getParameter());
-
- return super.execute(mapping, form, request, response);
-
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 03:55 --- (In reply to comment #5) Unless I as the consumer of the DownloadAction have the ability to control its destination (filename), I don't see how I can take advantage of the Action class. You can do this by setting the content disposition in the getStreamInfo() method. See the bottom of this wiki page for an example: http://wiki.apache.org/struts/StrutsFileDownload Having said that, we could add a contentDispostion property to StreamInfo and, if the property is not null set it in the response. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)
Niall: First, let me join in the thanks and congratulations for helping push this out the door. It's great to have a solid GA of Struts 1.2 that wraps up the many changes that have been building up. Now, sorry to nitpick ;-) but for the C2 step on http://wiki.apache.org/struts/StrutsRelease127 (Deploy JAR to Apache Java-Repository), this is referring to the path /www/www.apache.org/dist/java-repository, which is automatically mirrored to ibiblio.org; GA releases should be deployed to there instead of (or at least in addition to) /www/cvs.apache.org/repository I suppose we could discuss whether beta grade releases should be deployed to ibiblio, although I think it would be OK; Apache doesn't want a bunch of people relying on the repository served from /www/cvs.apache.org/repository so that is more for limited use cases like alpha releases or possibly nightly/snapshot builds, in the case that a project has a temporary between-releases dependency on some other unreleased code. Assuming that you are the one who deployed it to the /www/cvs.apache.org/repository dir, do you want to do it again? Or do you want me to do it? I'm assuming you just did maven dist? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)Sorry about that, I thought the /www/cvs.apache.org/repository dir was the right place. I've moved it now. Thanks for pointing it out. Niall - Original Message - From: Joe Germuska Sent: Friday, May 27, 2005 3:19 AM Now, sorry to nitpick ;-) but for the C2 step on http://wiki.apache.org/struts/StrutsRelease127 (Deploy JAR to Apache Java-Repository), this is referring to the path /www/www.apache.org/dist/java-repository, which is automatically mirrored to ibiblio.org; GA releases should be deployed to there instead of (or at least in addition to) /www/cvs.apache.org/repository Assuming that you are the one who deployed it to the /www/cvs.apache.org/repository dir, do you want to do it again? Or do you want me to do it? I'm assuming you just did maven dist? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35089] - DownloadAction needs to be able to specify the name of the file on the browser side
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35089. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35089 --- Additional Comments From [EMAIL PROTECTED] 2005-05-27 04:45 --- The Wiki comment addresses my concern and was illuminating... Thanks! I do advocate adding a contentDispostion property to StreamInfo, as I think that this will be a very common bit of functionality, but it is clearly less important given a relatively easy to work-around -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts 1.2.7 (General Availabilty)
On 5/26/05, Joe Germuska [EMAIL PROTECTED] wrote: Niall: First, let me join in the thanks and congratulations for helping push this out the door. It's great to have a solid GA of Struts 1.2 that wraps up the many changes that have been building up. Now, sorry to nitpick ;-) but for the C2 step on http://wiki.apache.org/struts/StrutsRelease127 (Deploy JAR to Apache Java-Repository), this is referring to the path /www/www.apache.org/dist/java-repository, which is automatically mirrored to ibiblio.org; GA releases should be deployed to there instead of (or at least in addition to) /www/cvs.apache.org/repository That's my fault. Niall asked me where the repo was, and my aging brain came up with the wrong location. ;-( Sorry about that. -- Martin Cooper I suppose we could discuss whether beta grade releases should be deployed to ibiblio, although I think it would be OK; Apache doesn't want a bunch of people relying on the repository served from /www/cvs.apache.org/repository so that is more for limited use cases like alpha releases or possibly nightly/snapshot builds, in the case that a project has a temporary between-releases dependency on some other unreleased code. Assuming that you are the one who deployed it to the /www/cvs.apache.org/repository dir, do you want to do it again? Or do you want me to do it? I'm assuming you just did maven dist? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [shale] Dialog question
Catching back up after vacation -- only 873 Apache email threads to go :-). On 5/18/05, Sean Schofield [EMAIL PROTECTED] wrote: Actually I am thinking more along the lines of a filter. The probelm is that I need a way to let the NavigationHandler take over for an *original* request. Two use cases where this would apply: 1.) First page of the website needs to be a dialog One way to deal with this is along the following lines: * Map the welcome page to a filter that creates the appropriate FacesContext for the request (just like what FacesServlet normally does to initiate the JSF lifecycle). * Once the FacesContext has been created: String dialogName = ...; FacesContext context = FacesContext.getCurrentInstance(); NavigationHandler nh = context.getApplication().getNavigationHandler(); nh.handleNavigation(dialog: + dialogName); context.responseComplete(); return; // i.e. do not follow the rest of the filter chain This is likely to be a common enough use case that it should be supported with the presence of an init parameter defining the name of the initial dialog. 2.) You want to open the dialog in a popup window but you need to control dimensions, scrollbar, etc. (so a blank target won't work.) I could write my own filter but this strikes me as something others might want as well. That is, the ability to invoke a NavigationHandler based on a URL pattern so that you can initiate a Dialog (or any other custom process) without requiring the use of commandButton or commandLink. My thinking is that we could modify ShaleApplicationFilter (or perhaps the command chain used by it) so that if the URL contains 'launch:' it will strip 'launch:foo:xxx' from the String and then ask the NavigationHandler to handleNavigation using the String 'foo:xxx'. So if you wanted to launch a dialog (xxx) directly you could use 'launch:dialog:xxx'. The technique I described above should deal with this, without trying to get too fancy. In particular, it doesn't try to make any assumpations that a View ID is actually a URL (it's not, even in the standard JSF implementation). sean ps. Enjoy your vacation (and self-imposed break from your computer) It was quite nice ... the only disconcerting part was getting on the plane yesterday in Cabo (~85 degrees) and coming home to Portland (~95 degreees) :-) Craig On 5/17/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/17/05, Sean Schofield [EMAIL PROTECTED] wrote: One idea might be to have a filter. I could look for a special pattern like launch:dialog:xxx. If the requested URL contains that pattern the filter could ask the NavigationHandler to handleNavigation for dialog:xxx. I think that would work. That should work -- on most of the extension points JSF supports the decorator pattern of chaining implementations together, so you can define your custom NavigationHandler to handle your special case, and delegate everything else. sean Craig PS: By the way ... don't look for any mail from me for the next week or so ... off on vacation with no computer (gulp! err, i mean phew! :-). - 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: Jdbc2
On 5/25/05, jeff ort [EMAIL PROTECTED] wrote: I am noticing that the Ant build scripts reference an optional jdbc20ext.jar file, but the Maven build process does not. I was wondering if there was a reason why this was not used in the Maven build process? The most likely explanation is that this library was required back in Struts 1.1 days when (a) Struts included a JDBC DataSource implementation, and (b) the JDKs of the time didn't include this API, so you had to load it separately. Neither is true any longer, so there is no reason for the Maven build scripts to reference this JAR. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
