Re: [VOTE] New Struts Committer: Eddie Bush
Craig R. McClanahan wrote: I'd like to propose Eddie Bush [EMAIL PROTECTED] as a committer on the Struts project. +1 [Vote/Patches/Granularity/Linux how do they do it/Alternate Release] [Vote] I believe this project can benefit from a more timely application of patches. (I am currently waiting for come commons patches to be applied and know how frustrating it is to wait.) Eddie is an individual that at this point in his life, has demonstrated a willingness to devote a --good-- chunk of his time to helping others, and creating patches. [Granularity and the Gauntlet] Building: There are bricks and mortar, each are needed to build a building. Struts: We need timely thoughtful patches and major contributions. [Linux how do they do it ?] Maybe this was already answered. Struts has a Monolithic distribution ruled by a Meritocracy(Small group who hae won right on Merit). Linux has a hierarchy ruled by Monarchy approach. The lead branch which is watched over by Linus Torvalds, he has the ultimate say so about what goes in. Then there are the Maintenance release 2.5, 2.4, 2.2 etc. Each has a release manager(Appointed by Linus) who is independent to make decisions about their branch. The recent case where the 2.5 Kernel people (Linus) went with an alternate VM system, and the 2.4 people didn't (Alan Cox of Red Hat) decided the new VM wasn't stable enough. http://www.byte.com/documents/s=1436/byt20011024s0002/1029_moshe.html Ultimately, each patch needs to prove it's merit. Then each branch like 2.4 has multiple branches 2.4.x-ac 2.4-dj etc... Each gets a chance to be tried out on a wide basis. And yes it is can be chaotic when merging branches. http://users.edpnet.be/moritz/gpl/gpl.html [Alternate Releases] Yes maybe there should be an experimental release branch of struts, on source forge or other web site. I am not volunteering. It would give a wide number of people a chance to experiment on a wide basis to see what works and what doesn't. There would be no guarantee that any or all changes would be incorportaed. Then users could lobby to have it included into Jakarta struts on merit. After all that is the original charter struts was founded on, as to why there should been another MVC engine besides Turbine at Jakarta. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13360] New: - Adding www.bug-track.com to the powered by Struts page
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=13360. 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=13360 Adding www.bug-track.com to the powered by Struts page Summary: Adding www.bug-track.com to the powered by Struts page Product: Struts Version: 1.0.2 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Can you please add www.bug-track.com has a site powered by Struts. Description: Web Bug Tracking system. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tiles UseAttributeTag.java
cedric 2002/10/07 08:43:56
Modified: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.
Revision ChangesPath
1.4 +5 -3
jakarta-struts/src/share/org/apache/struts/taglib/tiles/UseAttributeTag.java
Index: UseAttributeTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/tiles/UseAttributeTag.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- UseAttributeTag.java 26 Jul 2002 16:18:28 - 1.3
+++ UseAttributeTag.java 7 Oct 2002 15:43:55 - 1.4
@@ -213,6 +213,8 @@
*/
public int doStartTag() throws JspException
{
+ // Do a local copy of id
+String id=this.id;
if( id==null )
id=attributeName;
--
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
-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]
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: [VOTE] New Struts Committer: Eddie Bush
I've been out of town and haven't had time to consider this vote, but will cast one as soon as I can. In the meantime, I would like to point out that Eddie's been on the list since February (and so meets the old six-month guideline), and, technically, we've been in beta-feature-lock that whole time. Under those conditions, it's kinda hard to contribute code, outside of patches =:0) -T. Martin Cooper wrote: -0. Eddie has certainly become a valuable resource on the struts-user list, having demonstrated a willingness - even an eagerness - to help people out. He has also shown an interest in resolving certain issues with the current code base. However, to reach the bar for a committer, from my perspective, I would want to see more in the way of contributions to the code base and commitment to quality than I have seen to date. -- Martin Cooper -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 1:54 PM To: [EMAIL PROTECTED] Subject: [VOTE] New Struts Committer: Eddie Bush I'd like to propose Eddie Bush [EMAIL PROTECTED] as a committer on the Struts project. Eddie has demonstrated high quality patches, a willingness to dig in and get to work (including starting a very interesting mail thread about getting patches applied :-), and is already helping people out on the STRUTS-USER mailing list. Here's my +1. Craig McClanahan -- 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 US co-author, Java Web Development with Struts Order it today: http://husted.com/struts/book.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Selective diff?
Problem: I've got a pending patch on RequestUtils already for selectApplication. I also made another modification (added getApplicationPrefix to return the current module prefix) to RequestUtils while bringing the validator into 1.1-compliance. This means I have two different bugs I need to pick certain changes out for selectively. Question: Is there a way I can tell cvs diff -u to give me just a certain section as a patch - or is it possible for me to modify the patch to exclude the already posted patch for selectApplication? Not being 110% familiar with how the diff does it's thing (and noticing there is apparantly some config up top telling it where to apply the patch), I'm reluctant to believe it's a simple matter of editing the patch file. Should I then have a seperate CVS tree for each patch - which only contains changes relevant to a given bug? (Man - that's a nasty solution, but it's the best one I can come up with! That's certainly a lot of work just to keep changes seperate!) -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] New Struts Committer: Eddie Bush
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 11:00 AM To: Struts Developers List Subject: Re: [VOTE] New Struts Committer: Eddie Bush I've been out of town and haven't had time to consider this vote, but will cast one as soon as I can. In the meantime, I would like to point out that Eddie's been on the list since February (and so meets the old six-month guideline), and, technically, we've been in beta-feature-lock that whole time. Under those conditions, it's kinda hard to contribute code, outside of patches =:0) Patches qualify as contributions to the code base, and I encourage everyone to contribute those. At this time, looking at Bugzilla, I see a total of three hits for Eddie - one code patch, one resources patch, and one doc patch. For me personally, that does not provide a sufficient basis for a new committer. -- Martin Cooper -T. Martin Cooper wrote: -0. Eddie has certainly become a valuable resource on the struts-user list, having demonstrated a willingness - even an eagerness - to help people out. He has also shown an interest in resolving certain issues with the current code base. However, to reach the bar for a committer, from my perspective, I would want to see more in the way of contributions to the code base and commitment to quality than I have seen to date. -- Martin Cooper -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 1:54 PM To: [EMAIL PROTECTED] Subject: [VOTE] New Struts Committer: Eddie Bush I'd like to propose Eddie Bush [EMAIL PROTECTED] as a committer on the Struts project. Eddie has demonstrated high quality patches, a willingness to dig in and get to work (including starting a very interesting mail thread about getting patches applied :-), and is already helping people out on the STRUTS-USER mailing list. Here's my +1. Craig McClanahan -- 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 US co-author, Java Web Development with Struts Order it today: http://husted.com/struts/book.html -- 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: Selective diff?
-Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 12:32 PM To: Struts Developers List Subject: Selective diff? Problem: I've got a pending patch on RequestUtils already for selectApplication. I also made another modification (added getApplicationPrefix to return the current module prefix) to RequestUtils while bringing the validator into 1.1-compliance. This means I have two different bugs I need to pick certain changes out for selectively. Question: Is there a way I can tell cvs diff -u to give me just a certain section as a patch - or is it possible for me to modify the patch to exclude the already posted patch for selectApplication? I don't believe there's an option to 'cvs -diff' part of a file. It's possible that 'patch' has an option to only apply part of it, but I don't have cygwin installed here, so I can't check that. It's possible that you might be able to modify the patch file, but I've never tried it myself. You'd need to try it and verify that 'patch' does the right thing before you submit the patches. Not being 110% familiar with how the diff does it's thing (and noticing there is apparantly some config up top telling it where to apply the patch), I'm reluctant to believe it's a simple matter of editing the patch file. Should I then have a seperate CVS tree for each patch - which only contains changes relevant to a given bug? (Man - that's a nasty solution, but it's the best one I can come up with! That's certainly a lot of work just to keep changes seperate!) Yah, that might be the safest approach, ugly as it is. -- Martin Cooper -- Eddie Bush -- 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: Selective diff?
Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 3:32 PM To: Struts Developers List Subject: Selective diff? Problem: I've got a pending patch on RequestUtils already for selectApplication. I also made another modification (added getApplicationPrefix to return the current module prefix) to RequestUtils while bringing the validator into 1.1-compliance. This means I have two different bugs I need to pick certain changes out for selectively. Question: Is there a way I can tell cvs diff -u to give me just a certain section as a patch - or is it possible for me to modify the patch to exclude the already posted patch for selectApplication? Not being 110% familiar with how the diff does it's thing (and noticing there is apparantly some config up top telling it where to apply the patch), I'm reluctant to believe it's a simple matter of editing the patch file. Should I then have a seperate CVS tree for each patch - which only contains changes relevant to a given bug? (Man - that's a nasty solution, but it's the best one I can come up with! That's certainly a lot of work just to keep changes seperate!) -- Eddie Bush -- 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: Selective diff?
At 2:32 PM -0500 2002/10/07, Eddie Bush wrote:
Problem:
I've got a pending patch on RequestUtils already for
selectApplication. I also made another modification (added
getApplicationPrefix to return the current module prefix) to
RequestUtils while bringing the validator into 1.1-compliance. This
means I have two different bugs I need to pick certain changes out
for selectively.
Question:
Is there a way I can tell cvs diff -u to give me just a certain
section as a patch - or is it possible for me to modify the patch to
exclude the already posted patch for selectApplication?
Not being 110% familiar with how the diff does it's thing (and
noticing there is apparantly some config up top telling it where to
apply the patch), I'm reluctant to believe it's a simple matter of
editing the patch file. Should I then have a seperate CVS tree for
each patch - which only contains changes relevant to a given bug?
(Man - that's a nasty solution, but it's the best one I can come up
with! That's certainly a lot of work just to keep changes seperate!)
It's probably not a good idea to edit the patch file. I would
probably just use CVS to update your local repository to the latest
version. If you're lucky, CVS will merge the repository version with
yours, and then when you do diff, it'll really just give you diffs
between the repository and your version.
CVS auto-merging is kind of hit-or-miss, especially if your changes
overlap a region which someone else has changed. Still, ultimately
you're best off coming up with a local copy that adds/integrates your
changes with the head revision in CVS and then running diff against
that version...
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Selective diff?
Martin Cooper wrote: snip/ I don't believe there's an option to 'cvs -diff' part of a file. It's possible that 'patch' has an option to only apply part of it, but I don't have cygwin installed here, so I can't check that. It's possible that you might be able to modify the patch file, but I've never tried it myself. You'd need to try it and verify that 'patch' does the right thing before you submit the patches. Yeah - I think having seperate trees would be easier for me to manage. I could pull a virgin tree and copy it easily enough - and just treat that one as sacred (no modifications go into it whatsoever -- apart from an occassional update - so I have it to copy around) Not being 110% familiar with how the diff does it's thing (and noticing there is apparantly some config up top telling it where to apply the patch), I'm reluctant to believe it's a simple matter of editing the patch file. Should I then have a seperate CVS tree for each patch - which only contains changes relevant to a given bug? (Man - that's a nasty solution, but it's the best one I can come up with! That's certainly a lot of work just to keep changes seperate!) Yah, that might be the safest approach, ugly as it is. :-/ Ok, well, thanks for the confirmation. I suppose that, for now, that works. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Selective diff?
I had thought about that. I don't like the idea of having to maintain that though - it's much more straight-forward (to me) to maintain seperate trees (as gruesome as it may seem). I need to learn CVS better :-/ My current strategy is looking like: .../struts/bugs/ jakarta-struts/ (virgin code) by-bugid/ 12702/ jakarta-struts/ (includes changes for bugid 12702) 10348/ jakarta-struts/ (includes changes for bugid 12348) etc ... Nasty as it appears, I think it's probably the fastest/easiest solution. I'll dig into the cvs texinfo docs and see if I can familiarize myself enough with branching to use that alternative. I would want my diffs built with regard to the jakarta cvs tree though - not mine. Thanks! Daniel Honig wrote: Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? -Daniel -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Selective diff?
Well, I'm not sure its' the fastest/easiest solution. However it is the one we all seem to readily understand :) I think branching would probably work, but if your not comfortable with it, then I'd wait for an opportune time to try it out and crutch by in the manner your most comfortable... -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 4:28 PM To: Struts Developers List Subject: Re: Selective diff? I had thought about that. I don't like the idea of having to maintain that though - it's much more straight-forward (to me) to maintain seperate trees (as gruesome as it may seem). I need to learn CVS better :-/ My current strategy is looking like: .../struts/bugs/ jakarta-struts/ (virgin code) by-bugid/ 12702/ jakarta-struts/ (includes changes for bugid 12702) 10348/ jakarta-struts/ (includes changes for bugid 12348) etc ... Nasty as it appears, I think it's probably the fastest/easiest solution. I'll dig into the cvs texinfo docs and see if I can familiarize myself enough with branching to use that alternative. I would want my diffs built with regard to the jakarta cvs tree though - not mine. Thanks! Daniel Honig wrote: Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? -Daniel -- Eddie Bush -- 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: Selective diff?
-Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 12:44 PM To: Struts Developers List Subject: RE: Selective diff? Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? No, this is not what branching is for. Branching is used to maintain multiple versions of the code in the CVS repository. What Eddie is trying to do is create diffs for patches to the code. You wouldn't want to be making changes to the repository just to prepare patch files. -- Martin Cooper -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 3:32 PM To: Struts Developers List Subject: Selective diff? Problem: I've got a pending patch on RequestUtils already for selectApplication. I also made another modification (added getApplicationPrefix to return the current module prefix) to RequestUtils while bringing the validator into 1.1-compliance. This means I have two different bugs I need to pick certain changes out for selectively. Question: Is there a way I can tell cvs diff -u to give me just a certain section as a patch - or is it possible for me to modify the patch to exclude the already posted patch for selectApplication? Not being 110% familiar with how the diff does it's thing (and noticing there is apparantly some config up top telling it where to apply the patch), I'm reluctant to believe it's a simple matter of editing the patch file. Should I then have a seperate CVS tree for each patch - which only contains changes relevant to a given bug? (Man - that's a nasty solution, but it's the best one I can come up with! That's certainly a lot of work just to keep changes seperate!) -- Eddie Bush -- 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: Selective diff?
On Mon, 7 Oct 2002, Martin Cooper wrote: Date: Mon, 7 Oct 2002 12:44:01 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Selective diff? -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 12:32 PM To: Struts Developers List Subject: Selective diff? Problem: I've got a pending patch on RequestUtils already for selectApplication. I also made another modification (added getApplicationPrefix to return the current module prefix) to RequestUtils while bringing the validator into 1.1-compliance. This means I have two different bugs I need to pick certain changes out for selectively. Question: Is there a way I can tell cvs diff -u to give me just a certain section as a patch - or is it possible for me to modify the patch to exclude the already posted patch for selectApplication? I don't believe there's an option to 'cvs -diff' part of a file. It's possible that 'patch' has an option to only apply part of it, but I don't have cygwin installed here, so I can't check that. It's possible that you might be able to modify the patch file, but I've never tried it myself. You'd need to try it and verify that 'patch' does the right thing before you submit the patches. It might be easier to follow a different pattern (assuming that the two fixes are totally independent of each other): * For patch #1, use cvs diff -u to create the diff for just that patch. * For patch #2, create *two* versions of the patch: - Use cvs diff -u to create the diff from the current version of the source (i.e. assumpe patch #1 is never applied) - Use regular diff -u to create a diff starting from a local copy of the source *with* patch #1 applied. * If you want to be nice, go back and do the reverse for patch #1 (create a diff starting from source+patch2) That way, the patches can be applied in either order. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Selective diff?
Well, yeah, you actually might want to make a branch for just that reason: CVS gives you the ability to produce diffs between versions. Assuming Eddie was empowered create such a branch (OT!), then he could check in his changes to that branch. He, or others (since its a visible branch), could pull changes into the main line selectively, and could make CVS diffs for a specific change that was needed to add that to a bug report or whatever by using the diff between specific versions capability. Successive changes to the same branch work fine, and can be diffed either individually, or collectively. Now I realize that this is a little far fetched in some ways, because I think if he were able to create and write to a branch, he would be able to write to the mainline as well. So it's somewhat not sensible, UNLESS CVS provides a way to allow for differential access controls to branches versus the mainline (I have a vauge feeling that it does, but I haven't checked). If it did, this would be an interesting alternative to the current practice os attaching diffs to the bug report, as people could just create a branch and put their changes into it. Committers could pull the changes from that branch over into the mainline when desired. Since the branch is made with respect to a specific version of the file(s) in question, the bit rot that sets in when there's a long time between when a patch is created and when it's integrated can be avoided as the integrator can see exactly how the patch looked wrt the file at the time it was created, as well as how it might appear currently. Ok, so I'm probably smoking crack with this whole idea -- anyone know for sure if CVS specifically disallows this kind of commit on a branch only privilege? Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 1:48 PM To: 'Struts Developers List' Subject: RE: Selective diff? -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 12:44 PM To: Struts Developers List Subject: RE: Selective diff? Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? No, this is not what branching is for. Branching is used to maintain multiple versions of the code in the CVS repository. What Eddie is trying to do is create diffs for patches to the code. You wouldn't want to be making changes to the repository just to prepare patch files. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Selective diff?
Well this is exactly the manner that I used PVCS another SCS a commercial from merant that I'm sure many listees have encountered. Now the needs/challeneges of my teams are probably not as great as open source development. But I was thinking in concept you should be able to create a branch for each patch and track the patch as that branch. -Daniel -Original Message- From: Byrne, Steven [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 5:05 PM To: Struts Developers List Subject: RE: Selective diff? Well, yeah, you actually might want to make a branch for just that reason: CVS gives you the ability to produce diffs between versions. Assuming Eddie was empowered create such a branch (OT!), then he could check in his changes to that branch. He, or others (since its a visible branch), could pull changes into the main line selectively, and could make CVS diffs for a specific change that was needed to add that to a bug report or whatever by using the diff between specific versions capability. Successive changes to the same branch work fine, and can be diffed either individually, or collectively. Now I realize that this is a little far fetched in some ways, because I think if he were able to create and write to a branch, he would be able to write to the mainline as well. So it's somewhat not sensible, UNLESS CVS provides a way to allow for differential access controls to branches versus the mainline (I have a vauge feeling that it does, but I haven't checked). If it did, this would be an interesting alternative to the current practice os attaching diffs to the bug report, as people could just create a branch and put their changes into it. Committers could pull the changes from that branch over into the mainline when desired. Since the branch is made with respect to a specific version of the file(s) in question, the bit rot that sets in when there's a long time between when a patch is created and when it's integrated can be avoided as the integrator can see exactly how the patch looked wrt the file at the time it was created, as well as how it might appear currently. Ok, so I'm probably smoking crack with this whole idea -- anyone know for sure if CVS specifically disallows this kind of commit on a branch only privilege? Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 1:48 PM To: 'Struts Developers List' Subject: RE: Selective diff? -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 12:44 PM To: Struts Developers List Subject: RE: Selective diff? Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? No, this is not what branching is for. Branching is used to maintain multiple versions of the code in the CVS repository. What Eddie is trying to do is create diffs for patches to the code. You wouldn't want to be making changes to the repository just to prepare patch files. -- -- 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: Selective diff?
On Mon, 7 Oct 2002, Byrne, Steven wrote: Date: Mon, 7 Oct 2002 17:05:11 -0400 From: Byrne, Steven [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Selective diff? Well, yeah, you actually might want to make a branch for just that reason: CVS gives you the ability to produce diffs between versions. Assuming Eddie was empowered create such a branch (OT!), then he could check in his changes to that branch. He, or others (since its a visible branch), could pull changes into the main line selectively, and could make CVS diffs for a specific change that was needed to add that to a bug report or whatever by using the diff between specific versions capability. Successive changes to the same branch work fine, and can be diffed either individually, or collectively. Now I realize that this is a little far fetched in some ways, because I think if he were able to create and write to a branch, he would be able to write to the mainline as well. So it's somewhat not sensible, UNLESS CVS provides a way to allow for differential access controls to branches versus the mainline (I have a vauge feeling that it does, but I haven't checked). If it did, this would be an interesting alternative to the current practice os attaching diffs to the bug report, as people could just create a branch and put their changes into it. Committers could pull the changes from that branch over into the mainline when desired. Since the branch is made with respect to a specific version of the file(s) in question, the bit rot that sets in when there's a long time between when a patch is created and when it's integrated can be avoided as the integrator can see exactly how the patch looked wrt the file at the time it was created, as well as how it might appear currently. Ok, so I'm probably smoking crack with this whole idea -- anyone know for sure if CVS specifically disallows this kind of commit on a branch only privilege? CVS itself doesn't have much in the way of access control at all. In fact, the granting of karma at Apache is done by an external PERL script that checks the committer username against a configuration file (CVSROOT/avail) that lists users allowed to commit to a particular repository. So, our setup at Apache cannot (currently) distinguish to the within a repository level of granularity. I'm not as adamant as Martin is about not using branches for this sort of thing, because it can make sense within a development group that all has commit access. In fact, CVS has some commands specifically designed to merge two branches (that have perhaps been being developed independently) back together again -- although I shudder at the prospect of actually trusting this for my own use. This is not a practical solution, however, for a non-committer who wants to create a diff file. See my previous mail on this thread for a suggestion that seems to make more sense. Steve Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Selective diff?
... and the debate continues! All very interesting - that's for certain. For the time (and lack of!) I'm going to just use the structure I devised and manage it that way. Should I become more of a cvs power-user in the future (and still lack commit kudos), I may well examine other possibilities. For now, I need to get this done and move on with life (and work!). While what you all propose sounds very doable - if only by me locally (ie - checking the tree into my own CVS and branching that - I have full control over it) I think my knowledge is somewhat lacking to make it efficient. Thanks though ;-) Daniel Honig wrote: Well this is exactly the manner that I used PVCS another SCS a commercial from merant that I'm sure many listees have encountered. Now the needs/challeneges of my teams are probably not as great as open source development. But I was thinking in concept you should be able to create a branch for each patch and track the patch as that branch. -Daniel -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Selective diff?
FYI, there's a cool CVS QuickRef here: http://www.refcards.com/ Only the Cederqvist will give you the full scoop, but I find this 'card' handy when I can't remember the option I want. (Brain rot, you know :) -- Martin Cooper -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 2:39 PM To: Struts Developers List Subject: Re: Selective diff? ... and the debate continues! All very interesting - that's for certain. For the time (and lack of!) I'm going to just use the structure I devised and manage it that way. Should I become more of a cvs power-user in the future (and still lack commit kudos), I may well examine other possibilities. For now, I need to get this done and move on with life (and work!). While what you all propose sounds very doable - if only by me locally (ie - checking the tree into my own CVS and branching that - I have full control over it) I think my knowledge is somewhat lacking to make it efficient. Thanks though ;-) Daniel Honig wrote: Well this is exactly the manner that I used PVCS another SCS a commercial from merant that I'm sure many listees have encountered. Now the needs/challeneges of my teams are probably not as great as open source development. But I was thinking in concept you should be able to create a branch for each patch and track the patch as that branch. -Daniel -- Eddie Bush -- 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: Selective diff?
Handy - thanks :-) Martin Cooper wrote: FYI, there's a cool CVS QuickRef here: http://www.refcards.com/ Only the Cederqvist will give you the full scoop, but I find this 'card' handy when I can't remember the option I want. (Brain rot, you know :) -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Struts Committer: Eddie Bush
I told you I was going to rectify that ;-) Just out of curiosity, how many hits does it take? I've got some patches ready for validator ... but, in light of your hit count requirement I'm debating whether to make each an attachment by itself - or combine them. ... that was a joke ;-) Seriously though: If you have a patch that affects multiple files is it better to combine them (.tgz) or list each as an attachment, or ... ? The files are atomic by the way - it's an all or none type of thing as they all have to be there to acheive the correct behavior. Thanks! Martin Cooper wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 11:00 AM To: Struts Developers List Subject: Re: [VOTE] New Struts Committer: Eddie Bush I've been out of town and haven't had time to consider this vote, but will cast one as soon as I can. In the meantime, I would like to point out that Eddie's been on the list since February (and so meets the old six-month guideline), and, technically, we've been in beta-feature-lock that whole time. Under those conditions, it's kinda hard to contribute code, outside of patches =:0) Patches qualify as contributions to the code base, and I encourage everyone to contribute those. At this time, looking at Bugzilla, I see a total of three hits for Eddie - one code patch, one resources patch, and one doc patch. For me personally, that does not provide a sufficient basis for a new committer. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Selective diff?
On Mon, 7 Oct 2002, Martin Cooper wrote: Date: Mon, 7 Oct 2002 14:42:43 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Selective diff? FYI, there's a cool CVS QuickRef here: http://www.refcards.com/ Only the Cederqvist will give you the full scoop, but I find this 'card' handy when I can't remember the option I want. (Brain rot, you know :) For the Unix-ites among us (including CYGWIN users), there's still nothing like man cvs for a quick review of the available commands and options :-). -- Martin Cooper Craig -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 2:39 PM To: Struts Developers List Subject: Re: Selective diff? ... and the debate continues! All very interesting - that's for certain. For the time (and lack of!) I'm going to just use the structure I devised and manage it that way. Should I become more of a cvs power-user in the future (and still lack commit kudos), I may well examine other possibilities. For now, I need to get this done and move on with life (and work!). While what you all propose sounds very doable - if only by me locally (ie - checking the tree into my own CVS and branching that - I have full control over it) I think my knowledge is somewhat lacking to make it efficient. Thanks though ;-) Daniel Honig wrote: Well this is exactly the manner that I used PVCS another SCS a commercial from merant that I'm sure many listees have encountered. Now the needs/challeneges of my teams are probably not as great as open source development. But I was thinking in concept you should be able to create a branch for each patch and track the patch as that branch. -Daniel -- Eddie Bush -- 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]
[Proposal] Sub-application inheritence
Sub-applications in Struts 1.1 are one of the biggest advantages over 1.0. They let you break your configuration apart into multiple pieces - so that different people can work on their piece of the project without affecting others. This is good for those of us working in a team-oriented setting where different (groups of) people may be responsible for different function areas (ok, Bob and Henry - you guys get the account-maintenance stuff - Frank, Nancy, and Richardo - you guys get this 'store' module - etc). Still, sub-applications aren't as functional as they could be. Because of the structure imposed on sub-applications [1], I think several people believe it would be reasonable for sub-applications to be able to share information with one another[2]. I believe it is expected behavior, in fact. Currently, each module loads whatever resources it will need. As a result, there is unnecessary duplication of certain resources. Some of those particular resources result in wasting RAM, while others have a more significant impact. Of those that have a more significant impact, the most notable is undoubtably the data-source. Data-source is handy. It's a pool for JDBC connections. The fact that you can configure the pool to limit connections is undoubtably an important functionality to those who use it (though I can't say with full certainty, as I do not use the built-in data-source) - but now that we have sub-applications, determining how to setup the pool to properly manage connection limits could be quite ... difficult. Yes, there are many very good OS DBMSs out there - but we all have to sensibly ration out our connections - if only because of resource consumption. The proposal I would like to set forth is thus (this is a suggested order): 1 - refactor data-source instantiation/acquisition so that duplicates are not created -- *and* sub-apps would they chain the lookup from the current module to the default module. 2 - refactor message-resource instantiation/acquisition the same way 3 - refactor global-forward ~kind of~ the same way. Global forwards mentioned in sub-apps would be pushed up into the default module. Yes, I know there's a possibility for clashing. 4 - (optional) introduce module-level forwards that would replace our current global forwards - and have the exact same scope (visibility) as our current global forwards. Disclaimer: No, I haven't yet fully studied what would have to be done to acheive this proposal in it's entirety. I post this for open discussion so that ideas can be generated and bad ones pruned. So, if you take the view that *all* sub-apps are independent of one another - and should be - obviously this is a very stupid proposal. If, however, you take the view that all modules are going to be developed in support of the default module, this is a very logical following (I think), as it lets you leverage the effort you put into the default module in your sub-applications. My view on (3) above is this: I see modules as being like classes. All of the resources are instance-level declarations. Global, in this sense, would imply being available either apart from the heirarchy, or being available in the base class (which I suppose puts it back at the instance-level actually). We wouldn't break backward-compatability (that I can think of), since the changes would be primarily geared toward allowing non-default modules to access the default modules resources. Nothing (that crosses my mind!) would have to change for the default module (save for global-forwards being pushed up into the default sub-app -- this wouldn't impact a 1.0 app moving to 1.1 in the slightest). I suppose, since, as Ted observed, we're involved in feature lock, this is something that is viewed as an enhancement or a bug request. My view is that it is a bug, but I have to admit I'm unsure about what precise functionality you all expected to have in 1.1. I should probably go check the release plan :-), but I don't recall anything supporting this being there -- nor do I recall seeing anything that would inhibit this being there :-) Is this a post 1.1 thing? Is this even a desirable thing (I believe it is - what's your opinion)? (Would the changes necessary to implement 1 2 really be that significant? Those are the really important items as I see it.) --- [1] - Sub-app partitioning gives us something like: (default) /\ FooBar / \ Baz Bang [2] - At least non-default sub-apps to share information from the default sub-app. From [1], Foo would have access to the default sub-app's config, as would Bang. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10348] - Validator is not available under sub-application
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=10348. 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=10348 Validator is not available under sub-application --- Additional Comments From [EMAIL PROTECTED] 2002-10-07 23:40 --- Created an attachment (id=3386) Patch to bring struts-validator into 1.1 compliance. Resources are loaded into application scope with a key of VALIDATOR_KEY + prefix ... and retrieved using the same key. The attached patch file contains additions/modifications for 4 seperate classes: RequestUtils, ValidatorPlugIn, StrutsValidatorUtils, JavascriptValidatorTag. My tests inidcate the sum of all patches will fix validator to work as expected under sub-applications. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New Struts Committer: Eddie Bush
My other mail asking how to proceed hasn't hit the list yet so I just did a cat *.patch total_patch.patch. If that's inconvenient just let me know. Martin Cooper wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] I've been out of town and haven't had time to consider this vote, but will cast one as soon as I can. In the meantime, I would like to point out that Eddie's been on the list since February (and so meets the old six-month guideline), and, technically, we've been in beta-feature-lock that whole time. Under those conditions, it's kinda hard to contribute code, outside of patches =:0) Patches qualify as contributions to the code base, and I encourage everyone to contribute those. At this time, looking at Bugzilla, I see a total of three hits for Eddie - one code patch, one resources patch, and one doc patch. For me personally, that does not provide a sufficient basis for a new committer. -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Proposal] Sub-application inheritence
I agree that sub-applications are handicapped by not utilizing some form of inheritance from the default sub-app or parent sub-apps. Given that Struts is a Java-based framework, it makes sense that there would be some way to extend an application. I'm probably at the far end of the spectrum in favor of inherited resources and would like to see a fairly comprehensive set of features. That said, I think that Eddie's steps 1 and 2 (data source and property inheritance, respectively) are essential to any multi-app regime and the current behavior seems contrary to what people who use sub-apps (judging from the posts on the subject on the struts-user list) expect when they start using them. Thanks Eddie for pursuing this thread-- I for one think it's an important one. -JT -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 4:19 PM To: Struts Developers List Subject: [Proposal] Sub-application inheritence
Re: [Proposal] Sub-application inheritence
On Mon, 7 Oct 2002, Eddie Bush wrote: Date: Mon, 07 Oct 2002 18:19:08 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: [Proposal] Sub-application inheritence Sub-applications in Struts 1.1 are one of the biggest advantages over 1.0. They let you break your configuration apart into multiple pieces - so that different people can work on their piece of the project without affecting others. This is good for those of us working in a team-oriented setting where different (groups of) people may be responsible for different function areas (ok, Bob and Henry - you guys get the account-maintenance stuff - Frank, Nancy, and Richardo - you guys get this 'store' module - etc). Still, sub-applications aren't as functional as they could be. Because of the structure imposed on sub-applications [1], I think several people believe it would be reasonable for sub-applications to be able to share information with one another[2]. I believe it is expected behavior, in fact. There's sharing and then there's sharing :-). Sharing *data* in application scope and session scope is a reasonable thing to have - the fact that it's all in the same webapp is sort of a poor man's single sign on plus not having to copy your JAR files into things like $CATALINA_HOME/common/lib in Tomcat. Sharing *functionality* was not at all in the design goals I had originally. My view of the world was that sub-apps should be as self contained and independent as possible, in the same manner that webapps should be as self contained and independent as possible. The idea is that you can assemble individual subapps together, and also minimize the cross-sub-app dependencies that can complicate and slow down development. Not everyone agrees with this world view. Another, equally important to me, goal is that any existing Struts (1.0) app should be able to run in 1.1 by itself, or as a subapp, with zero changes to the struts-config.xml file. This is where life gets complicated with your proposal. Currently, each module loads whatever resources it will need. As a result, there is unnecessary duplication of certain resources. Some of those particular resources result in wasting RAM, while others have a more significant impact. Of those that have a more significant impact, the most notable is undoubtably the data-source. Data-source is handy. It's a pool for JDBC connections. The fact that you can configure the pool to limit connections is undoubtably an important functionality to those who use it (though I can't say with full certainty, as I do not use the built-in data-source) - but now that we have sub-applications, determining how to setup the pool to properly manage connection limits could be quite ... difficult. Yes, there are many very good OS DBMSs out there - but we all have to sensibly ration out our connections - if only because of resource consumption. The proposal I would like to set forth is thus (this is a suggested order): 1 - refactor data-source instantiation/acquisition so that duplicates are not created -- *and* sub-apps would they chain the lookup from the current module to the default module. 2 - refactor message-resource instantiation/acquisition the same way 3 - refactor global-forward ~kind of~ the same way. Global forwards mentioned in sub-apps would be pushed up into the default module. Yes, I know there's a possibility for clashing. 4 - (optional) introduce module-level forwards that would replace our current global forwards - and have the exact same scope (visibility) as our current global forwards. All of these are interesting ideas, but to me I think it's post-1.1 thinking. Because any of them will likely break backwards compatibility (and because changes this major will only delay 1.1 further), I'd rather not focus on implementing them now. OK? Disclaimer: No, I haven't yet fully studied what would have to be done to acheive this proposal in it's entirety. I post this for open discussion so that ideas can be generated and bad ones pruned. So, if you take the view that *all* sub-apps are independent of one another - and should be - obviously this is a very stupid proposal. If, however, you take the view that all modules are going to be developed in support of the default module, this is a very logical following (I think), as it lets you leverage the effort you put into the default module in your sub-applications. My view on (3) above is this: I see modules as being like classes. All of the resources are instance-level declarations. Global, in this sense, would imply being available either apart from the heirarchy, or being available in the base class (which I suppose puts it back at the instance-level actually). We wouldn't break backward-compatability (that I can think of), since the changes would be primarily geared
RE: [Proposal] Sub-application inheritence
This topic is of interest. To me. I started working out with Web Objects. In WebObjects everything you do is basically viewed as an instance of a component base class. So if you build a search application it can be subclassed and any portion of the model/view/controller can be changed. The java world has yet to catch up to this it seems as we're lost in our mesh of JSP's/MVC frameworks and template engines. If I understand JSF-Java Server Faces is intended to be. Then one could build components that can have inheritance of behaviour. This would lessen the need for sub-applications to support such subclassing. If sub applications are to support inheritance of behaviour there no doubt would be the introduction of a hierarchy which makes this happen and IMHO this is a component model. -Daniel -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 9:42 PM To: Struts Developers List Subject: Re: [Proposal] Sub-application inheritence On Mon, 7 Oct 2002, Eddie Bush wrote: Date: Mon, 07 Oct 2002 18:19:08 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: [Proposal] Sub-application inheritence Sub-applications in Struts 1.1 are one of the biggest advantages over 1.0. They let you break your configuration apart into multiple pieces - so that different people can work on their piece of the project without affecting others. This is good for those of us working in a team-oriented setting where different (groups of) people may be responsible for different function areas (ok, Bob and Henry - you guys get the account-maintenance stuff - Frank, Nancy, and Richardo - you guys get this 'store' module - etc). Still, sub-applications aren't as functional as they could be. Because of the structure imposed on sub-applications [1], I think several people believe it would be reasonable for sub-applications to be able to share information with one another[2]. I believe it is expected behavior, in fact. There's sharing and then there's sharing :-). Sharing *data* in application scope and session scope is a reasonable thing to have - the fact that it's all in the same webapp is sort of a poor man's single sign on plus not having to copy your JAR files into things like $CATALINA_HOME/common/lib in Tomcat. Sharing *functionality* was not at all in the design goals I had originally. My view of the world was that sub-apps should be as self contained and independent as possible, in the same manner that webapps should be as self contained and independent as possible. The idea is that you can assemble individual subapps together, and also minimize the cross-sub-app dependencies that can complicate and slow down development. Not everyone agrees with this world view. Another, equally important to me, goal is that any existing Struts (1.0) app should be able to run in 1.1 by itself, or as a subapp, with zero changes to the struts-config.xml file. This is where life gets complicated with your proposal. Currently, each module loads whatever resources it will need. As a result, there is unnecessary duplication of certain resources. Some of those particular resources result in wasting RAM, while others have a more significant impact. Of those that have a more significant impact, the most notable is undoubtably the data-source. Data-source is handy. It's a pool for JDBC connections. The fact that you can configure the pool to limit connections is undoubtably an important functionality to those who use it (though I can't say with full certainty, as I do not use the built-in data-source) - but now that we have sub-applications, determining how to setup the pool to properly manage connection limits could be quite ... difficult. Yes, there are many very good OS DBMSs out there - but we all have to sensibly ration out our connections - if only because of resource consumption. The proposal I would like to set forth is thus (this is a suggested order): 1 - refactor data-source instantiation/acquisition so that duplicates are not created -- *and* sub-apps would they chain the lookup from the current module to the default module. 2 - refactor message-resource instantiation/acquisition the same way 3 - refactor global-forward ~kind of~ the same way. Global forwards mentioned in sub-apps would be pushed up into the default module. Yes, I know there's a possibility for clashing. 4 - (optional) introduce module-level forwards that would replace our current global forwards - and have the exact same scope (visibility) as our current global forwards. All of these are interesting ideas, but to me I think it's post-1.1 thinking. Because any of them will likely break backwards compatibility (and because changes this major will only delay 1.1 further), I'd rather not focus on implementing them now. OK? Disclaimer:
Re: [Proposal] Sub-application inheritence
Craig R. McClanahan wrote: On Mon, 7 Oct 2002, Eddie Bush wrote: From: Eddie Bush [EMAIL PROTECTED] Subject: [Proposal] Sub-application inheritence Sub-applications in Struts 1.1 are one of the biggest advantages over 1.0. They let you break your configuration apart into multiple pieces - so that different people can work on their piece of the project without affecting others. This is good for those of us working in a team-oriented setting where different (groups of) people may be responsible for different function areas (ok, Bob and Henry - you guys get the account-maintenance stuff - Frank, Nancy, and Richardo - you guys get this 'store' module - etc). Still, sub-applications aren't as functional as they could be. Because of the structure imposed on sub-applications [1], I think several people believe it would be reasonable for sub-applications to be able to share information with one another[2]. I believe it is expected behavior, in fact. There's sharing and then there's sharing :-). Sharing *data* in application scope and session scope is a reasonable thing to have - the fact that it's all in the same webapp is sort of a poor man's single sign on plus not having to copy your JAR files into things like $CATALINA_HOME/common/lib in Tomcat. Sharing *functionality* was not at all in the design goals I had originally. My view of the world was that sub-apps should be as self contained and independent as possible, in the same manner that webapps should be as self contained and independent as possible. The idea is that you can assemble individual subapps together, and also minimize the cross-sub-app dependencies that can complicate and slow down development. Not everyone agrees with this world view. Ok - I see your point. Another, equally important to me, goal is that any existing Struts (1.0) app should be able to run in 1.1 by itself, or as a subapp, with zero changes to the struts-config.xml file. This is where life gets complicated with your proposal. Currently, each module loads whatever resources it will need. As a result, there is unnecessary duplication of certain resources. Some of those particular resources result in wasting RAM, while others have a more significant impact. Of those that have a more significant impact, the most notable is undoubtably the data-source. Data-source is handy. It's a pool for JDBC connections. The fact that you can configure the pool to limit connections is undoubtably an important functionality to those who use it (though I can't say with full certainty, as I do not use the built-in data-source) - but now that we have sub-applications, determining how to setup the pool to properly manage connection limits could be quite ... difficult. Yes, there are many very good OS DBMSs out there - but we all have to sensibly ration out our connections - if only because of resource consumption. The proposal I would like to set forth is thus (this is a suggested order): 1 - refactor data-source instantiation/acquisition so that duplicates are not created -- *and* sub-apps would they chain the lookup from the current module to the default module. 2 - refactor message-resource instantiation/acquisition the same way 3 - refactor global-forward ~kind of~ the same way. Global forwards mentioned in sub-apps would be pushed up into the default module. Yes, I know there's a possibility for clashing. 4 - (optional) introduce module-level forwards that would replace our current global forwards - and have the exact same scope (visibility) as our current global forwards. All of these are interesting ideas, but to me I think it's post-1.1 thinking. Because any of them will likely break backwards compatibility (and because changes this major will only delay 1.1 further), I'd rather not focus on implementing them now. OK? LOL, Craig, you're too cool: ... I'd rather not focus on implementing them now. OK? ... as though I could obligate you to such a thing :-) The reason I posted the proposal was mostly for feedback and to see what folks' views were. I personally would like to see them dealt with prior to 1.1 Final - but I am not you. I realize there has to be a systematic way of introducing things such as this and that the timing may not be appropriate just now. Disclaimer: No, I haven't yet fully studied what would have to be done to acheive this proposal in it's entirety. I post this for open discussion so that ideas can be generated and bad ones pruned. So, if you take the view that *all* sub-apps are independent of one another - and should be - obviously this is a very stupid proposal. If, however, you take the view that all modules are going to be developed in support of the default module, this is a very logical following (I think), as it lets you leverage the effort you put into the default module in your sub-applications. My view on (3) above is this: I see modules as being like classes. All of the resources are
Re: [Proposal] Sub-application inheritence
Craig R. McClanahan wrote: There's sharing and then there's sharing :-). Sharing *data* in application scope and session scope is a reasonable thing to have - the fact that it's all in the same webapp is sort of a poor man's single sign on plus not having to copy your JAR files into things like $CATALINA_HOME/common/lib in Tomcat. I honestly hadn't looked at it that way. You're being quite literal with your interpretation of sub-apps being another context. I wasn't aware that it was meant to be taken quite so literally. mega-snip/ All of these are interesting ideas, but to me I think it's post-1.1 thinking. Because any of them will likely break backwards compatibility (and because changes this major will only delay 1.1 further), I'd rather not focus on implementing them now. OK? I'll just plod along patching what I can then - and see if I can help hurry 1.1. Then perhaps we can sit down and examine this a bit more seriously. I honestly have no desire to delay a release. I know there is useful functionality in 1.1 as it stands - and there are some folks that can't (won't) use it til it's out of beta. I'm sure these are the folks you have in mind (and rightfully so). Fundamentally, your proposals change an individual struts-config.xml from being a self contained description of a module to a *partial* description of a module that cannot be installed and run by itself. Personally, I'd rather spend a couple of hundred extra bucks for a few more megabytes of memory than to suffer the complexity costs of this. Actually - they would only be unable to be run on their own if they were designed to be dependent. I imagine Martin will like this a lot :-). That still bugs me :-) Have I commited a terrible sin? Peace :-) I may have a mind to poke a stick in things and stir them up, but I only do so in hopes something constructive will result. -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Sub-application inheritence
On Mon, 7 Oct 2002, Eddie Bush wrote: I imagine Martin will like this a lot :-). That still bugs me :-) Have I commited a terrible sin? No, not at all ... but the hierarchical approach sounds a lot like what Martin has described of his designs. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-el/web/exercise-taglib html-link.jsp
dmkarr 2002/10/07 20:37:38
Modified:contrib/struts-el/web/exercise-taglib html-link.jsp
Log:
Adding tests of title, accesskey, tabindex, styleId, and on* for
html-el:text and html-el:link.
Revision ChangesPath
1.2 +50 -10
jakarta-struts/contrib/struts-el/web/exercise-taglib/html-link.jsp
Index: html-link.jsp
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-el/web/exercise-taglib/html-link.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- html-link.jsp 26 Sep 2002 04:54:41 - 1.1
+++ html-link.jsp 8 Oct 2002 03:37:38 - 1.2
@@ -43,7 +43,22 @@
/td
th align=rightintProperty/th
td align=left
- html-el:text property=intProperty size=16/
+ html-el:text property=intProperty size=16 title=intProperty
+accesskey=i tabindex=27 styleId=abc
+onblur=showevent(event)
+onchange=showevent(event)
+onclick=showevent(event)
+ondblclick=showevent(event)
+onfocus=showevent(event)
+onkeydown=showevent(event)
+onkeypress=showevent(event)
+onkeyup=showevent(event)
+onmousedown=showevent(event)
+onmousemove=showevent(event)
+onmouseout=showevent(event)
+onmouseover=showevent(event)
+onmouseup=showevent(event)
+ /
/td
/tr
@@ -85,7 +100,8 @@
tr
td colspan=4 align=center
- html-el:link page=/html-link.do
+ html-el:link page=/html-link.do accesskey=1 tabindex=5
+title=No modifications at all styleId=def
No modifications at all
/html-el:link
/td
@@ -93,7 +109,9 @@
tr
td colspan=4 align=center
- html-el:link
page=/html-link.do?doubleProperty=321.321amp;longProperty=321321
+ html-el:link
page=/html-link.do?doubleProperty=321.321amp;longProperty=321321
+accesskey=2 tabindex=4
+title=Double and long via hard coded changes
Double and long via hard coded changes
/html-el:link
/td
@@ -101,8 +119,9 @@
tr
td colspan=4 align=center
- html-el:link page=/html-link.do
- paramId=stringProperty paramName=newValue
+ html-el:link page=/html-link.do accesskey=3 tabindex=3
+paramId=stringProperty paramName=newValue
+title=String via paramId and paramName
String via paramId and paramName
/html-el:link
/td
@@ -110,9 +129,10 @@
tr
td colspan=4 align=center
- html-el:link page=/html-link.do
- paramId=booleanProperty
-paramName=testbean paramProperty=nested.booleanProperty
+ html-el:link page=/html-link.do accesskey=4 tabindex=2
+paramId=booleanProperty
+paramName=testbean paramProperty=nested.booleanProperty
+title=Boolean via paramId, paramName, and paramValue
Boolean via paramId, paramName, and paramValue
/html-el:link
/td
@@ -120,8 +140,22 @@
tr
td colspan=4 align=center
- html-el:link page=/html-link.do
- name=newValues
+ html-el:link page=/html-link.do accesskey=5 tabindex=1
+name=newValues
+title=Float, int, and stringArray via name (Map)
+onblur=showevent(event)
+onclick=showevent(event)
+ondblclick=showevent(event)
+onfocus=showevent(event)
+onkeydown=showevent(event)
+onkeypress=showevent(event)
+onkeyup=showevent(event)
+onmousedown=showevent(event)
+onmousemove=showevent(event)
+onmouseout=showevent(event)
+onmouseover=showevent(event)
+onmouseup=showevent(event)
+
Float, int, and stringArray via name (Map)
/html-el:link
/td
@@ -142,5 +176,11 @@
/html-el:form
+ script
+ !--
+function showevent(evt) { window.status = evt.type; }
+// --
+ /script
+/body
/html-el:html
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13337] - html:select has an accesskey attribute, but select has no accesskey in HTML 4.01
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=13337. 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=13337 html:select has an accesskey attribute, but select has no accesskey in HTML 4.01 --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 04:08 --- I propose that we remove this. It's conceivable that this would break existing applications, if someone has actually used this attribute, but the risk seems very low (and the problem is trivially fixed). If someone feels otherwise, please speak now or forever hold your peace. ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13336] - The TLD for html:img tag has an accesskey attribute, but not supported in HTML 4.01
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=13336. 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=13336 The TLD for html:img tag has an accesskey attribute, but not supported in HTML 4.01 --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 04:10 --- I propose that we remove this. It's conceivable that this would break existing applications, if someone has actually used this attribute, but the risk seems very low (and the problem is trivially fixed). If someone feels otherwise, please speak now or forever hold your peace. ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13326] - WebLogic 6.1 SP2 fails to start theStruts 1.1 beta examples war
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=13326. 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=13326 WebLogic 6.1 SP2 fails to start theStruts 1.1 beta examples war --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 04:18 --- Can you give us any more information on the problem? Do you have a stack trace? If not, could you try turning up the logging level as much as possible, so that we can see where, in the loading process, the error is occurring? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Proposal] Sub-application inheritence
I actually think there are a number of rather independent ideas here, which should probably be treated as such. 1) Resource sharing. In some application scenarios, it is desirable to share (some) data sources, message resources, etc., across all of the modules in the application. This relates more to application-wide (as opposed to module-wide) configuration than it does to module inheritance. 2) Inter-module communication. On the surface, sharing truly global global forwards seems similar to (1) above. The difference, however, is that there is now explicit interaction between modules, and in particular, a shared resource which knows about the modules which are part of the application. 3) Hierarchical applications. This *might* be a scenario in which the default module becomes a framework that other modules plug into, but it might be something else entirely. For example, there is no real reason to treat the default module as the root of the hierarchy. As you know, I happen to have implemented a hierarchical app that way (actually, it turned out to be a directed graph, but I'm not about to explain that :), and I fear that my spouting about that may have unduly influenced others' thinking about how hierarchical applications should be built. Just because I made it work doesn't mean it's the right/best way to do it! Note that while a hierarchical application may take advantage of (1) and (2), it may also achieve its goals in an entirely different way. That's why I think these ideas are largely independent. In any case, I agree with Craig that this is a post-1.1 topic. As I've said before, we really need to get the modular application concept out there and see what people do with it. Then we can have a more general discussion of how Struts in general, and the module concept in particular, can be expanded to address peoples' needs. -- Martin Cooper -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 4:19 PM To: Struts Developers List Subject: [Proposal] Sub-application inheritence Sub-applications in Struts 1.1 are one of the biggest advantages over 1.0. They let you break your configuration apart into multiple pieces - so that different people can work on their piece of the project without affecting others. This is good for those of us working in a team-oriented setting where different (groups of) people may be responsible for different function areas (ok, Bob and Henry - you guys get the account-maintenance stuff - Frank, Nancy, and Richardo - you guys get this 'store' module - etc). Still, sub-applications aren't as functional as they could be. Because of the structure imposed on sub-applications [1], I think several people believe it would be reasonable for sub-applications to be able to share information with one another[2]. I believe it is expected behavior, in fact. Currently, each module loads whatever resources it will need. As a result, there is unnecessary duplication of certain resources. Some of those particular resources result in wasting RAM, while others have a more significant impact. Of those that have a more significant impact, the most notable is undoubtably the data-source. Data-source is handy. It's a pool for JDBC connections. The fact that you can configure the pool to limit connections is undoubtably an important functionality to those who use it (though I can't say with full certainty, as I do not use the built-in data-source) - but now that we have sub-applications, determining how to setup the pool to properly manage connection limits could be quite ... difficult. Yes, there are many very good OS DBMSs out there - but we all have to sensibly ration out our connections - if only because of resource consumption. The proposal I would like to set forth is thus (this is a suggested order): 1 - refactor data-source instantiation/acquisition so that duplicates are not created -- *and* sub-apps would they chain the lookup from the current module to the default module. 2 - refactor message-resource instantiation/acquisition the same way 3 - refactor global-forward ~kind of~ the same way. Global forwards mentioned in sub-apps would be pushed up into the default module. Yes, I know there's a possibility for clashing. 4 - (optional) introduce module-level forwards that would replace our current global forwards - and have the exact same scope (visibility) as our current global forwards. Disclaimer: No, I haven't yet fully studied what would have to be done to acheive this proposal in it's entirety. I post this for open discussion so that ideas can be generated and bad ones pruned. So, if you take the view that *all* sub-apps are independent of one another - and should be - obviously this is a very stupid proposal. If, however, you take the view that all modules are going to
DO NOT REPLY [Bug 13326] - WebLogic 6.1 SP2 fails to start theStruts 1.1 beta examples war
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=13326. 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=13326 WebLogic 6.1 SP2 fails to start theStruts 1.1 beta examples war --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 04:53 --- The MANIFEST.MF in 1.0.2 contained no Classpath entries. The MANIFEST.MF for jakarta-struts-1.1-b2 does. WebLogic (as I recall Craig having stated) was having problems with the way the classpath was formatted in the 1.1-b2 release (all on a single line), and the format was changed (one per line). Try CVS HEAD if you can at all and let us know what happens. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Proposal] Sub-application inheritence
Martin Cooper wrote: I actually think there are a number of rather independent ideas here, which should probably be treated as such. 1) Resource sharing. In some application scenarios, it is desirable to share (some) data sources, message resources, etc., across all of the modules in the application. This relates more to application-wide (as opposed to module-wide) configuration than it does to module inheritance. Yes - possibly, but not necessarily. 2) Inter-module communication. On the surface, sharing truly global global forwards seems similar to (1) above. The difference, however, is that there is now explicit interaction between modules, and in particular, a shared resource which knows about the modules which are part of the application. ... but why would it have to be a shared resource? ... or are you calling the default sub-app a shared resource? 3) Hierarchical applications. This *might* be a scenario in which the default module becomes a framework that other modules plug into, but it might be something else entirely. For example, there is no real reason to treat the default module as the root of the hierarchy. It just seemed a natural fit - but, ok. My reasoning was in the way we key things: Same key in request (for current module) and application (for default) makes it easy to chain this way. As you know, I happen to have implemented a hierarchical app that way (actually, it turned out to be a directed graph, but I'm not about to explain that :), and I fear that my spouting about that may have unduly influenced others' thinking about how hierarchical applications should be built. Just because I made it work doesn't mean it's the right/best way to do it! Don't take all the blame upon yourself :-) I'd been feeling that way every since I really started experimenting with what sub-apps really meant. You did, I suppose, reaffirm that those were good feelings - but they didn't originate with you ;-) Note that while a hierarchical application may take advantage of (1) and (2), it may also achieve its goals in an entirely different way. That's why I think these ideas are largely independent. Yes, but I think this is a natural fit. Of course, the way you say that makes me think you have a card you're holding til the last hand is dealt ;-) In any case, I agree with Craig that this is a post-1.1 topic. As I've said before, we really need to get the modular application concept out there and see what people do with it. Then we can have a more general discussion of how Struts in general, and the module concept in particular, can be expanded to address peoples' needs. Right. As I said, I was looking to get feedback. I really hoped there would be some meaningful discussion. It's now obvious to me though (blatantly) that such discussion is counter-productive to what our actual goal should be: getting 1.1 out the door. I do look forward to that event though :-) ... because then there will necessarily be speculation on how the next release should be dealt with - which features should (not) be included... and I look forward to being involved in those discussions ;-) -- Martin Cooper -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13267] - java.lang.IllegalArgumentException: cant remove Attributes from request scope
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=13267. 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=13267 java.lang.IllegalArgumentException: cant remove Attributes from request scope [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 05:13 --- This looks like a container bug. The attributes are being set using pageContext.setAttribute(), and removed using pageContext.removeAttribute(). If that sequence does not work, there is a bug in your container, and you need to take the issue up with your container vendor. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13075] - select tag doesn't work with multiple selects
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=13075. 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=13075 select tag doesn't work with multiple selects [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 05:38 --- The problem is that you have multiple getter/setter pairs, in your form bean, for the 'selectedFolders' property. That is, you have the same method name but different signatures. This is not permitted, per the JavaBeans spec. Removing the indexed versions will solve the problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/util RequestUtils.java
martinc 2002/10/07 23:16:42
Modified:src/share/org/apache/struts/util RequestUtils.java
Log:
Remove obsolete unused code.
PR: 13281
Submitted by: Nicola Guidotto
Revision ChangesPath
1.54 +4 -5
jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java
Index: RequestUtils.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/RequestUtils.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- RequestUtils.java 23 Aug 2002 02:37:12 - 1.53
+++ RequestUtils.java 8 Oct 2002 06:16:41 - 1.54
@@ -953,7 +953,6 @@
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
String stripped = name;
-int subscript = stripped.lastIndexOf([);
if (prefix != null) {
if (!stripped.startsWith(prefix))
continue;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13281] - old useless code?
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=13281. 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=13281 old useless code? [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 06:18 --- Fixed in the 20021008 nightly build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html FrameTag.java
martinc 2002/10/07 23:22:41
Modified:src/share/org/apache/struts/taglib/html FrameTag.java
Log:
Output the correct text for the 'longdesc' attribute.
PR: 12988
Submitted by: John Yu
Revision ChangesPath
1.4 +5 -5
jakarta-struts/src/share/org/apache/struts/taglib/html/FrameTag.java
Index: FrameTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/FrameTag.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- FrameTag.java 23 Sep 2002 05:13:43 - 1.3
+++ FrameTag.java 8 Oct 2002 06:22:41 - 1.4
@@ -239,7 +239,7 @@
}
if (longdesc != null) {
results.append( longdesc=\);
-results.append(frameborder);
+results.append(longdesc);
results.append(\);
}
results.append(prepareStyles());
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 12988] - [PATCH] FrameTag incorrectly render the 'longdesc' attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12988. 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=12988 [PATCH] FrameTag incorrectly render the 'longdesc' attribute [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-10-08 06:24 --- Fixed in 20021008 nightly build. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
