Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > But we still need a way to grab all of the sources that match that > library. That was simple with 1.2 because we used the version tag. It should > be as simple for 1.3 using the ordinal for the library as the tag. $ svn co https://svn.apache.org/repos/asf/struts/action/tags/STRUTS_ACTION_LIBRARY_1_3_00 It turns out that we have eight dwarfs. :) The 'build' directory has to be treated like another sub-project in order to keep the tags straight with svn:externals. Otherwise, if you check out one of these tags a year from now, you'll get the HEAD revision of 'build' with it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
May I kindly recommend how unclear this version naming scheme appears to even the Struts committers? I cannot think of any other open source project that is trying to divide sub-projects into different versions, which is, not to be confusing, not the same as the version number of the packaged release. Take a look at the Spring framework. They release both the full spring.jar as well as spring-aop, spring-dao, spring-mvc, etc. The full and miniature libaries are released under ONE version number. There will be a Spring 1.2.7 coming out, which means updates to any of those libaries all together -- not 1.2.4 for this library, 1.2.3 for here, 1.2.7 for here and then together = 1.2.7. Honestly, I never thought the versioning scheme you guys are now attempting now is very intuitive. Please don't confuse my criticality with being mean. I want you guys to succeed, but this innovative versioning scheme is really a mental-draining loser in the long run, imo. I know you guys want to release as "1.3.0" first and then have the libary versions go the separate ways, but this is sure to muck you the moment you have to update libraries in tandem. If new feature X in the tag library requires new feature Y in the core, you guys have destroyed the whole independence you saught with separate releases. I say take the Spring model: same version number for ALL libraries, full or miniature, and release the full set each time as ONE version number. Just my 2 cents. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > * Struts Action Framework - The framework in general, including all relevant > subprojects We agreed to rename the subproject formally known as "Core" as "Action", which we also refer to as the Struts Action Framework. But, I never took that to mean that "Struts Action Framework" would also refer to EL, Extras, Tiles, Taglib, Flow, and Scripting. > * Struts Action Library - A numbered collection of ]versioned subprojects I think the library should be the set of the "best available" Struts subproject JARs that are know to work with the "best available" Struts Action 1 JAR, and other related dependencies. > * Struts Classic - In the trash can. We don't use this term, ever again. I think the "Classic" term is a useful shorthand for the original seven dwarfs. I agree that there probably won't be a reason to tag and build all seven together again under a single plan, as we did today. So I doubt there won't be a need for another "Classic" release plan. Each subproject (Action, EL, Extras, Taglib, Tiles) should now have it's own release plan, as we did with Scripting. > Right. But we still need a way to grab all of the sources that match that > library. Hmmm, I just don't see that as a regular need for that myself. A Release Manager wouldn't need to touch the sources, only test the JARs. In the event that someone does need to do that, I agree that there should be a cannonical place to put the tag, so that it doesn't need to be done twice. But I don't see why we would need to grab all the sources in the normal course. Each subproject is a separate release and should be treated as such. If it turns out that we do need to do such a thing, then we can start doing it. But I'm not going to spend any time doing it until there a demonstrated need. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/17/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > Is the Struts Action Library what the Struts Classic release page on the > > wiki is about? If not, I'm now quite confused about what Struts Action > > Framework, Struts Action Library and Struts Classic are. > > From the release plan: > > * Struts Classic 1.3.0 is a "bootstrap" initiative to extract seven > new Struts subprojects from Struts 1.2.8. > > * Each subproject will be available as an independant distribution > > * The set of JARs created or used by all seven subprojects will be > available in one convenient ZIP archive. > > * When a subproject has a new GA release, the library distribution > would be updated, and the version counter incremented. Right. That references "Struts Classic" and "the library distribution". But it doesn't indicate whether those are the same thing or not, and certainly doesn't answer my questions. It was in response to seeing "Classic" still in the wiki page that I initially brought this up as a reply to the wiki change message. So here are the terms I believe we should be using: * Struts Action Framework - The framework in general, including all relevant subprojects * Struts Action Library - A numbered collection of versioned subprojects * Struts Classic - In the trash can. We don't use this term, ever again. > IMO, such a tag is going to be the only reliable way to connect the > version > > number to its precise content. > > Per the release plan, the Library is not going to be "versioned". The > releases underlying the JARs already have releases. We decided to give > it a counter instead. That's fine. A tag doesn't have to relate to a version, it's just a tag. But tell me how you're going to check out the source that corresponds to Struts Action Library 1.3.1_04 without dredging through that bundle of jars and doing individual checkouts of all of the separate subprojects. The Library is *not* a a release. It's a set of compatible > dependencies. Many people don't need or want the full distribution. > All they want is the JARs, and so that's what the Library provides: > Just the JARs. It's really no different than the Library distribution > that we provide with 1.2 and prior. Right. But we still need a way to grab all of the sources that match that library. That was simple with 1.2 because we used the version tag. It should be as simple for 1.3 using the ordinal for the library as the tag. -- Martin Cooper If someone wants to setup such a tag, feel free. I don't see that it > would have any practical value. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > Is the Struts Action Library what the Struts Classic release page on the > wiki is about? If not, I'm now quite confused about what Struts Action > Framework, Struts Action Library and Struts Classic are. >From the release plan: * Struts Classic 1.3.0 is a "bootstrap" initiative to extract seven new Struts subprojects from Struts 1.2.8. * Each subproject will be available as an independant distribution * The set of JARs created or used by all seven subprojects will be available in one convenient ZIP archive. * When a subproject has a new GA release, the library distribution would be updated, and the version counter incremented. > IMO, such a tag is going to be the only reliable way to connect the version > number to its precise content. Per the release plan, the Library is not going to be "versioned". The releases underlying the JARs already have releases. We decided to give it a counter instead. The Library is *not* a a release. It's a set of compatible dependencies. Many people don't need or want the full distribution. All they want is the JARs, and so that's what the Library provides: Just the JARs. It's really no different than the Library distribution that we provide with 1.2 and prior. If someone wants to setup such a tag, feel free. I don't see that it would have any practical value. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/17/06, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Another way of looking at it is that such a tag would be capturing the > > same information as the Maven POM... The main value of a tag is to allow > > someone to check out all the code for a given release at once. Checking > > out just action and letting Maven pull the release jars for the other > > sub-projects gets you there anyway IMHO. > > The Action Library is not a release per se. It's a collection of JARs: > Commons JARs, Struts JARs, and whatever other dependant JARs we can > redistribute. Is the Struts Action Library what the Struts Classic release page on the wiki is about? If not, I'm now quite confused about what Struts Action Framework, Struts Action Library and Struts Classic are. I still believe we decided to not use the Struts Classic name, so I'm hoping we're down to just the other two. The idea is that Taglibs releases a new 1.3.1 JAR that we have already > tested to work with (say) Struts Action 1.3.4. We vote the Taglibs > 1.3.1 JAR GA, and decide to update the Struts Action Library by > replacing the Taglib 1.3.0 JAR with the Taglib 1.3.1 JAR. > > Now, if we're saying that in order to update the Struts Action library > with the new Taglib 1.3.1 JAR, I have to checkout a certain revision > of six other subprojects so that we can do a complex tag, I'm suddenly > going to find something else to do :) You don't have to have *anything* checked out to create a tag or branch in SVN. That so many things can be done without anything on your local disk is one of my favourite things about SVN. IMO, such a tag is going to be the only reliable way to connect the version number to its precise content. -- Martin Cooper Of course, if that sounds like fun to someone else, hey, go for it. > But to me, it sounds like too much work for too little utility. It's a > tag for the sake of having a tag. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Ted Husted <[EMAIL PROTECTED]> wrote: > Now, if we're saying that in order to update the Struts Action library > with the new Taglib 1.3.1 JAR, I have to checkout a certain revision > of six other subprojects so that we can do a complex tag, I'm suddenly > going to find something else to do :) I think it can be done just like 'current' -- a single directory with svn:externals. It's a matter of grabbing the "right" set of already-existing tags. However, I was just thinking out loud that it might be useful, and haven't had time to experiment with it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/17/06, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Another way of looking at it is that such a tag would be capturing the > > same information as the Maven POM... The main value of a tag is to allow > > someone to check out all the code for a given release at once. Checking > > out just action and letting Maven pull the release jars for the other > > sub-projects gets you there anyway IMHO. > > The Action Library is not a release per se. It's a collection of JARs: > Commons JARs, Struts JARs, and whatever other dependant JARs we can > redistribute. > > The idea is that Taglibs releases a new 1.3.1 JAR that we have already > tested to work with (say) Struts Action 1.3.4. We vote the Taglibs > 1.3.1 JAR GA, and decide to update the Struts Action Library by > replacing the Taglib 1.3.0 JAR with the Taglib 1.3.1 JAR. > > Now, if we're saying that in order to update the Struts Action library > with the new Taglib 1.3.1 JAR, I have to checkout a certain revision > of six other subprojects so that we can do a complex tag, I'm suddenly > going to find something else to do :) > > Of course, if that sounds like fun to someone else, hey, go for it. > But to me, it sounds like too much work for too little utility. It's a > tag for the sake of having a tag. Without this tag, can one reliably rebuild a particular "edition" of the Struts Action Library from source? If not, then it would seem to be pretty important, unless we didn't call the library itself a release, but made up some other sort of term like "distribution." -Ted. Craig - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Laurie Harper <[EMAIL PROTECTED]> wrote: > Another way of looking at it is that such a tag would be capturing the > same information as the Maven POM... The main value of a tag is to allow > someone to check out all the code for a given release at once. Checking > out just action and letting Maven pull the release jars for the other > sub-projects gets you there anyway IMHO. The Action Library is not a release per se. It's a collection of JARs: Commons JARs, Struts JARs, and whatever other dependant JARs we can redistribute. The idea is that Taglibs releases a new 1.3.1 JAR that we have already tested to work with (say) Struts Action 1.3.4. We vote the Taglibs 1.3.1 JAR GA, and decide to update the Struts Action Library by replacing the Taglib 1.3.0 JAR with the Taglib 1.3.1 JAR. Now, if we're saying that in order to update the Struts Action library with the new Taglib 1.3.1 JAR, I have to checkout a certain revision of six other subprojects so that we can do a complex tag, I'm suddenly going to find something else to do :) Of course, if that sounds like fun to someone else, hey, go for it. But to me, it sounds like too much work for too little utility. It's a tag for the sake of having a tag. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Another way of looking at it is that such a tag would be capturing the same information as the Maven POM... The main value of a tag is to allow someone to check out all the code for a given release at once. Checking out just action and letting Maven pull the release jars for the other sub-projects gets you there anyway IMHO. L. Ted Husted wrote: Did we tag current for the Struts-Shale_1.0.0 and Struts-Scripting_1.0.0 releases? For the Action Library, right now, I'm only planning to post the JARs (including external dependencies), which are all self-tagged for the appropriate release. Conceptually, I'm thinking of the Library as the set of Struts GA releases that are dependant on Action and work with a given Action GA. (So, technically, right now, that's a null set, since we have no GA releases, but we should at least prime the pump. ) In the future, if we wanted to a tag for that set, we might have to use a "working copy" tag, since it probably would not be a tag against the HEAD, but against some GA tag for each of the different subprojects. It would be a mix of revisions. * http://svnbook.red-bean.com/en/1.1/ch04s06.html#svn-ch-4-sect-6.2 Though, the Action Library release manager would not need to obtain the set of source file as a matter of course. No more than we need to obtain the source for a Commons JAR. The release manager for an Action Library would only need to test the JARs already decreed GA, the same as we do for Commons JARs. My question would be whether we are going to expect an Action Library release manager to go through the work of making a complex tag? If someone wants to check-out the Struts source for each of the JARs and create the tag, that's great, and it would be a good idea to have a cannonical place to put such a tag. But being a release manager is hard enough without making work. If someone needs the set, the set is obtainable. If we need it, then we can create it when we need it, and save it somewhere so someone doesn't need to create it again. But creating it up front seems like busy-work. -Ted. On 2/17/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 2/17/06, James Mitchell <[EMAIL PROTECTED]> wrote: Did we tag every subproject? Including 'current'? Maybe I just missed it. I didn't see a tag for current... but there is no trunk/branches/tags directory structure there, either. It seems to me that we need a tag for (something like) ACTION-LIB_1.3_00, so you can grab all the "right" versions of the sub-projects that go with a particular library distribution. These are the ones we've tested to make sure they work together. I'm just not sure where to put it. What about in struts/action/tags or just struts/tags ? Current doesn't seem like the right place, no one would go looking in "current" for an old release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Did we tag current for the Struts-Shale_1.0.0 and Struts-Scripting_1.0.0 releases? For the Action Library, right now, I'm only planning to post the JARs (including external dependencies), which are all self-tagged for the appropriate release. Conceptually, I'm thinking of the Library as the set of Struts GA releases that are dependant on Action and work with a given Action GA. (So, technically, right now, that's a null set, since we have no GA releases, but we should at least prime the pump. ) In the future, if we wanted to a tag for that set, we might have to use a "working copy" tag, since it probably would not be a tag against the HEAD, but against some GA tag for each of the different subprojects. It would be a mix of revisions. * http://svnbook.red-bean.com/en/1.1/ch04s06.html#svn-ch-4-sect-6.2 Though, the Action Library release manager would not need to obtain the set of source file as a matter of course. No more than we need to obtain the source for a Commons JAR. The release manager for an Action Library would only need to test the JARs already decreed GA, the same as we do for Commons JARs. My question would be whether we are going to expect an Action Library release manager to go through the work of making a complex tag? If someone wants to check-out the Struts source for each of the JARs and create the tag, that's great, and it would be a good idea to have a cannonical place to put such a tag. But being a release manager is hard enough without making work. If someone needs the set, the set is obtainable. If we need it, then we can create it when we need it, and save it somewhere so someone doesn't need to create it again. But creating it up front seems like busy-work. -Ted. On 2/17/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On 2/17/06, James Mitchell <[EMAIL PROTECTED]> wrote: > > > Did we tag every subproject? Including 'current'? Maybe I just > > missed it. > > I didn't see a tag for current... but there is no trunk/branches/tags > directory structure there, either. > > It seems to me that we need a tag for (something like) > ACTION-LIB_1.3_00, so you can grab all the "right" versions of the > sub-projects that go with a particular library distribution. These > are the ones we've tested to make sure they work together. I'm just > not sure where to put it. What about in struts/action/tags or just > struts/tags ? Current doesn't seem like the right place, no one would > go looking in "current" for an old release. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, James Mitchell <[EMAIL PROTECTED]> wrote: > Did we tag every subproject? Including 'current'? Maybe I just > missed it. I didn't see a tag for current... but there is no trunk/branches/tags directory structure there, either. It seems to me that we need a tag for (something like) ACTION-LIB_1.3_00, so you can grab all the "right" versions of the sub-projects that go with a particular library distribution. These are the ones we've tested to make sure they work together. I'm just not sure where to put it. What about in struts/action/tags or just struts/tags ? Current doesn't seem like the right place, no one would go looking in "current" for an old release. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Did we tag every subproject? Including 'current'? Maybe I just missed it. -- James Mitchell EdgeTech, Inc. http://edgetechservices.net/ 678.910.8017 Skype: jmitchtx On Feb 17, 2006, at 11:19 AM, Wendy Smoak wrote: On 2/17/06, Ted Husted <[EMAIL PROTECTED]> wrote: I still need to assemble the appropriate JARS into a Struts-Action distribution, but we're otherwise through Checklist A now. I'll try to mop that up tonight. But, at this point, the seven Classic subproject builds are tagged, rolled, and uploaded. Thanks, Ted! We need one more tag: STRUTS-BUILD_1.3.0, from r378515 for consistency. I can do it tonight unless someone beats me to it. Then the svn:externals on the tags need to be modified to point to the tagged build directory. I learned this from Sean during the MyFaces reorg. It makes sense that the externals definitions get copied to the tag, they're just properties on a directory. The problem is that all of those externals still point at the build/trunk directory, so you don't get the right contents if you check out a tag. There's more to this that I haven't thought through completely-- 'build' almost has to be treated like another sub-project and "released" when there are changes. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/17/06, Ted Husted <[EMAIL PROTECTED]> wrote: > I still need to assemble the appropriate JARS into a Struts-Action > distribution, but we're otherwise through Checklist A now. I'll try to > mop that up tonight. But, at this point, the seven Classic subproject > builds are tagged, rolled, and uploaded. Thanks, Ted! We need one more tag: STRUTS-BUILD_1.3.0, from r378515 for consistency. I can do it tonight unless someone beats me to it. Then the svn:externals on the tags need to be modified to point to the tagged build directory. I learned this from Sean during the MyFaces reorg. It makes sense that the externals definitions get copied to the tag, they're just properties on a directory. The problem is that all of those externals still point at the build/trunk directory, so you don't get the right contents if you check out a tag. There's more to this that I haven't thought through completely-- 'build' almost has to be treated like another sub-project and "released" when there are changes. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted <[EMAIL PROTECTED]> wrote: > OK, I'll tag and roll the test builds first thing in the morning then. I still need to assemble the appropriate JARS into a Struts-Action distribution, but we're otherwise through Checklist A now. I'll try to mop that up tonight. But, at this point, the seven Classic subproject builds are tagged, rolled, and uploaded. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > So where do we stand? Ted, are you saying you still have time to do > the seven 1.3.0 test builds as long as you don't have to re-do the > testing due to changes? If so, we have the votes, go for it. :) OK, I'll tag and roll the test builds first thing in the morning then. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 2/16/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > > If some people feel these patches are a problem, then we can always > > keep Action 1.3.0 as a test-build, until someone has time to apply > > them and roll an Action 1.3.1 (note that the other six subprojects > > would *not* have to tagged and rolled again, only the one we change). > > Good point and probably all the more reason for carrying on with > things as they stand. So where do we stand? Ted, are you saying you still have time to do the seven 1.3.0 test builds as long as you don't have to re-do the testing due to changes? If so, we have the votes, go for it. :) As soon as that happens and the version numbers are flipped to 1.3.1-SNAPSHOT, then the patches for the remaining issues can go in, and struts-action 1.3.1 can follow quickly. If Ted doesn't have time now, and no one else steps up to do it... my calendar says it will be no earlier than the 25th. And in that case, we might as well let Niall go ahead with the fix, (for RequestProcessor?) which I suspect he already has ready to go in, or close to it. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Laurie Harper wrote: Ted Husted wrote: On 2/16/06, Martin Cooper <[EMAIL PROTECTED]> wrote: If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is "hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix". All I'm saying is that I have no "extra" time. If someone else does, then please step up and lend a hand. That's part of my reason for +1'ing a 1.3.0 release, even if it's never promoted (as a whole) from test release; Ted's put a ton of work into getting to this point. If a 1.3.0 release happens now, it'll presumably take less time and effort to incrementally address remaining issues and release updates of just the action sub-project, compared to postponing the 1.3.0 release and having to repeat much of the testing and prep work that's just been done. Oops. Ted and others have put... Sorry, didn't mean to allocate the blame^H^H^H^H^H^H credit to just Ted. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/16/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > Its down to whether you're hoping 1.3.0 makes "GA" quality or not. If > > we want to give it a chance of "GA" then we should fix them now. If we > > just want to get a milestone out there then carry on. I don't mind > > either way. > > In six years, we've never had a new minor version make GA on the first > release. The 1.2 series came close, we made GA in three tries. The 1.1 > series took three betas and a release candidate. I don't expect that > 1.3 would be much different. Same even on 1.0 ... it took two point releases to get it right. -Ted. Craig
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 1:09 pm, Martin Cooper said: > As for the point of releasing 1.3 at all, which I think you are actually > asking rather than almost asking, ;-) it brings a new way of working with > the Struts 1 line, and a new way of customising it, that could be highly > beneficial to many developers. Hehe :) No, I'll stick with *almost* asking because I've been onboard with 1.3 for a long time, even though I'm not currently using it, the benefits of a CoR-based design is completely obvious IMO (enough so that I've done two projects now that used CoR without actually using 1.3). I wouldn't ask *now* if releasing it makes sense :) Almost... > I know that I'm not about to back off to > 1.2.8 on my current project, since I'm getting a lot out of 1.3, but I'm > also sufficiently invested in that that I'm not about to switch horses and > move to WebWork instead. Now, I could be alone, but I strongly suspect I'm > not. ;-) I doubt your alone either... likewise with me, I'm on 1.2.6 at the moment, and it completely suits my needs for the time being, so I'm not in any rush to upgrade to anything either (I probably could if I wanted, but I'd have some fighting to do, given the corporate environment I work in). I'm thinking more of progress... if everyone agrees WW is the future (and that *seems* to be the general concensus), 1.3 becomes less important IMO... those that want to use it anyway are probably already doing so, but I also know tons of people wait for a GA release, or *have* to wait for a GA release, and if 1.3 isn't going to make that milestone for some time, or arguably ever, and if the WW merger happens before 1.3.x goes GA, then what was the point to putting effort them all along instead of directly into the WW merger? Oops... I didn't ask that... I *almost* asked that ;) LOL OTOH, I would feel bad for Ted, Wendy and others who have put in good work on 1.3 lately, so if for that reason alone the release should happen. The reward for the effort is the release itself, and I appreciate that. Eh, I've taken this whole thing OT, sorry about that... you all realize by now I never say with less than 1,000 words something that only need 10 to begin with :) > -- > Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > On Thu, February 16, 2006 12:34 pm, Martin Cooper said: > > As for 1.1, personally, I _do_ see 1.2 as making 1.1 "obsolete", so I > > don't > > see a need to update that as well. And I would expect 1.3 to make > > 1.2"obsolete" in time, too. > > I don't disagree, but isn't it true that 1.3 won't make anything obsolete, > the WW merger will? I mean, one could almost at this point ask what's the > point of putting 1.3 out at all, given that the WW merger is the future of > Struts, right? You'll note that I put "obsolete" in quotes. What I mean is that I see no reason that anyone would want to start a new project using 1.1 when we have 1.2 GA releases. Similarly, once 1.3 goes GA, it doesn't make much sense to start a new project with 1.2. Beyond that, it's a matter of how many versions we want to (and have the energy to) support. The WW merger won't make anything obsolete by itself. It will provide a new choice for people to use on their projects, and we hope to encourage them to migrate to the new Struts 2. Yes, this will eventually make the Struts 1 line obsolete in a more real sense, but the Struts 1 line is not going to go away for a very long time. As for the point of releasing 1.3 at all, which I think you are actually asking rather than almost asking, ;-) it brings a new way of working with the Struts 1 line, and a new way of customising it, that could be highly beneficial to many developers. I know that I'm not about to back off to 1.2.8 on my current project, since I'm getting a lot out of 1.3, but I'm also sufficiently invested in that that I'm not about to switch horses and move to WebWork instead. Now, I could be alone, but I strongly suspect I'm not. ;-) -- Martin Cooper > -- > > Martin Cooper > > Frank > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted Husted wrote: On 2/16/06, Martin Cooper <[EMAIL PROTECTED]> wrote: If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is "hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix". All I'm saying is that I have no "extra" time. If someone else does, then please step up and lend a hand. That's part of my reason for +1'ing a 1.3.0 release, even if it's never promoted (as a whole) from test release; Ted's put a ton of work into getting to this point. If a 1.3.0 release happens now, it'll presumably take less time and effort to incrementally address remaining issues and release updates of just the action sub-project, compared to postponing the 1.3.0 release and having to repeat much of the testing and prep work that's just been done. Just my 2 cents... L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > If we think this is serious enough to warrant a 1.2.9 release, then it makes > little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is > "hurrah, we tagged the tree, but oh, you probably don't want to use this > because there's a serious problem we know about that we didn't feel like > taking the extra time to fix". All I'm saying is that I have no "extra" time. If someone else does, then please step up and lend a hand. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > Its down to whether you're hoping 1.3.0 makes "GA" quality or not. If > we want to give it a chance of "GA" then we should fix them now. If we > just want to get a milestone out there then carry on. I don't mind > either way. In six years, we've never had a new minor version make GA on the first release. The 1.2 series came close, we made GA in three tries. The 1.1 series took three betas and a release candidate. I don't expect that 1.3 would be much different. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
[Slightly OT] Has 1.3 proper docs explaining how CoR works? Has CoR changed since last autumn? Does CoR MailReader reflect all cool CoR features? I am sorry, I just seem to have crawled from under the rock, still using 1.2.x branch. Would be great if someone pointed out to the docs (on Apache site) about CoR usage. The old link to CoR MailReader shows 14 month-old sources. I presume that CoR is the major improvement in 1.3 and should be presented/advertised/documented in a manner that a caveman can understand. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 12:34 pm, Martin Cooper said: > As for 1.1, personally, I _do_ see 1.2 as making 1.1 "obsolete", so I > don't > see a need to update that as well. And I would expect 1.3 to make > 1.2"obsolete" in time, too. I don't disagree, but isn't it true that 1.3 won't make anything obsolete, the WW merger will? I mean, one could almost at this point ask what's the point of putting 1.3 out at all, given that the WW merger is the future of Struts, right? > -- > Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > If someone is going to manage a 1.2.9 release, then, yes, it would > make sense for someone to make the necessary changes to 1.3 before we > mark it GA. (It just isn't going to be me.) > > But, if we are doing this because it's a security hole (and I don't > agree it is), then we should also patch and re-release Struts 1.1, > which many more people are using. The behavior has existed from day > one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1 > obsolete, then perhaps we should focus on stablizing Struts 1.3 so as > to make 1.2 obsolete too. If we think this is serious enough to warrant a 1.2.9 release, then it makes little sense to me to tag 1.3.0 without it. Otherwise, all we're saying is "hurrah, we tagged the tree, but oh, you probably don't want to use this because there's a serious problem we know about that we didn't feel like taking the extra time to fix". As for 1.1, personally, I _do_ see 1.2 as making 1.1 "obsolete", so I don't see a need to update that as well. And I would expect 1.3 to make 1.2"obsolete" in time, too. -- Martin Cooper As to any other changes, if Wendy doesn't mind, and someone wants to > make those and also help finish up on the 1.3.0 release, I'm not going > to argue. But, I would have to remove my name as release co-manager, > since I just don't have any more time to spend on 1.3.0 right now. If > someone else can do it, that would be great, it's just that I can't. > > If some people feel these patches are a problem, then we can always > keep Action 1.3.0 as a test-build, until someone has time to apply > them and roll an Action 1.3.1 (note that the other six subprojects > would *not* have to tagged and rolled again, only the one we change). > > The important thing, I think, is to get past the point having to > release everything all at once. Then we can address any other issues > in an agile, release-often, way. Otherwise, it will always be > something, and a week will turn into a month, which turns into another > quarter. > > -Ted. > > On 2/16/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > My view is that this is "security hole" that we are fixing, not adding > > a new feature. I also think that the original RequestProcessor and > > TilesRequestProcessor offer people a way of upgrading to 1.3 and use > > tried and tested code - without having to adopt the CoR > > implementation. > > > > Since I have implemented the Cancellable behaviour in the 1.2.x > > branch, then either it needs also applying to the 1.3 branch or that > > change needs to be reversed. > > > > We probably should release a Struts 1.2.9 to fix this issue and the > > "DOS attack" issue and I am willing to do that - probably have time in > > a couple of weeks. > > > > > If this change prompts anyone to change their vote, please chime-in > > > now. A release plan is a majority vote, so we need three binding +1s > > > from PMC members and more binding +1s than -1s. A +1 here is on the > > > tagging the repository. A quality vote would follow once the test > > > builds are posted. > > > > I realize the plan vote and quality vote are separte issues, but IMO > > the DOS attack bug is v.serious - you can stop a whole web app from > > working using it - and I don't understand why were not fixing it in > > 1.3.0. IMO 1.3.0 is never going to be more than a beta with this "DOS > > attack" bug - or with the original request processor "cancellable" > > security hole. Both are really bad. > > > > Niall > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted Husted wrote: If some people feel these patches are a problem, then we can always keep Action 1.3.0 as a test-build, until someone has time to apply them and roll an Action 1.3.1 (note that the other six subprojects would *not* have to tagged and rolled again, only the one we change). The important thing, I think, is to get past the point having to release everything all at once. Then we can address any other issues in an agile, release-often, way. Otherwise, it will always be something, and a week will turn into a month, which turns into another quarter. +1 to this action plan. I'm in the camp of considering the two security bugs a requirement for a GA level release, but getting the 'seven dwarfs' out the door would at least clear some room in the workshop ;-) L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 10:34 am, Joe Germuska said: > If people agree with some of the recent concerns about the API, like > the naming and responsibility of the ActionContext class, then they > could vote to mark the release merely Alpha -- but that doesn't mean > there shouldn't be a release. The one problem I see with this is that many people are not going to take into consideration the release mechanism, they are simply going to see a new version of Struts and jump on it. Especially as long as it has been since the last version, I think people will be more inclined to do that. Thinking more about the security issues, regardless of what severity you ascribe to them, I think this potentially does a disservice to the user community. Joe makes a good point... I have no problem with a 1.3 release per se, indeed I was pushing for it some weeks ago, but properly labeling it is very important IMO. To me, a "beta" denotes a release that you believe is ready for GA, and you just want to get feedback to confirm that. "alpha" denotes that you believe there probably are problems yet to be resolved. In that light, what Joe said makes sense, the vote should be for "alpha". Does that make sense to anyone? The bottom line to me is there are some outstanding issues yet to be resolved one way or another, and I would want to be careful of giving people the wrong impression about the release, so an alpha mark becomes more important with that in mind. > Joe > -- > Joe Germuska > [EMAIL PROTECTED] * http://blog.germuska.com > > "You really can't burn anything out by trying something new, and > even if you can burn it out, it can be fixed. Try something new." > -- Robert Moog > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted <[EMAIL PROTECTED]> wrote: > If someone is going to manage a 1.2.9 release, then, yes, it would > make sense for someone to make the necessary changes to 1.3 before we > mark it GA. (It just isn't going to be me.) > > But, if we are doing this because it's a security hole (and I don't > agree it is), then we should also patch and re-release Struts 1.1, > which many more people are using. The behavior has existed from day > one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1 > obsolete, then perhaps we should focus on stablizing Struts 1.3 so as > to make 1.2 obsolete too. Yes we should patch and release 1.1 as well, but I don't have any interest in working on 1.1. > As to any other changes, if Wendy doesn't mind, and someone wants to > make those and also help finish up on the 1.3.0 release, I'm not going > to argue. But, I would have to remove my name as release co-manager, > since I just don't have any more time to spend on 1.3.0 right now. If > someone else can do it, that would be great, it's just that I can't. Its down to whether you're hoping 1.3.0 makes "GA" quality or not. If we want to give it a chance of "GA" then we should fix them now. If we just want to get a milestone out there then carry on. I don't mind either way. > If some people feel these patches are a problem, then we can always > keep Action 1.3.0 as a test-build, until someone has time to apply > them and roll an Action 1.3.1 (note that the other six subprojects > would *not* have to tagged and rolled again, only the one we change). Good point and probably all the more reason for carrying on with things as they stand. Niall > The important thing, I think, is to get past the point having to > release everything all at once. Then we can address any other issues > in an agile, release-often, way. Otherwise, it will always be > something, and a week will turn into a month, which turns into another > quarter. > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
If someone is going to manage a 1.2.9 release, then, yes, it would make sense for someone to make the necessary changes to 1.3 before we mark it GA. (It just isn't going to be me.) But, if we are doing this because it's a security hole (and I don't agree it is), then we should also patch and re-release Struts 1.1, which many more people are using. The behavior has existed from day one; it's not specific to 1.2. Or, if we are saying that 1.2 makes 1.1 obsolete, then perhaps we should focus on stablizing Struts 1.3 so as to make 1.2 obsolete too. As to any other changes, if Wendy doesn't mind, and someone wants to make those and also help finish up on the 1.3.0 release, I'm not going to argue. But, I would have to remove my name as release co-manager, since I just don't have any more time to spend on 1.3.0 right now. If someone else can do it, that would be great, it's just that I can't. If some people feel these patches are a problem, then we can always keep Action 1.3.0 as a test-build, until someone has time to apply them and roll an Action 1.3.1 (note that the other six subprojects would *not* have to tagged and rolled again, only the one we change). The important thing, I think, is to get past the point having to release everything all at once. Then we can address any other issues in an agile, release-often, way. Otherwise, it will always be something, and a week will turn into a month, which turns into another quarter. -Ted. On 2/16/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > My view is that this is "security hole" that we are fixing, not adding > a new feature. I also think that the original RequestProcessor and > TilesRequestProcessor offer people a way of upgrading to 1.3 and use > tried and tested code - without having to adopt the CoR > implementation. > > Since I have implemented the Cancellable behaviour in the 1.2.x > branch, then either it needs also applying to the 1.3 branch or that > change needs to be reversed. > > We probably should release a Struts 1.2.9 to fix this issue and the > "DOS attack" issue and I am willing to do that - probably have time in > a couple of weeks. > > > If this change prompts anyone to change their vote, please chime-in > > now. A release plan is a majority vote, so we need three binding +1s > > from PMC members and more binding +1s than -1s. A +1 here is on the > > tagging the repository. A quality vote would follow once the test > > builds are posted. > > I realize the plan vote and quality vote are separte issues, but IMO > the DOS attack bug is v.serious - you can stop a whole web app from > working using it - and I don't understand why were not fixing it in > 1.3.0. IMO 1.3.0 is never going to be more than a beta with this "DOS > attack" bug - or with the original request processor "cancellable" > security hole. Both are really bad. > > Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Ted Husted <[EMAIL PROTECTED]> wrote: > OK, we're back down to two patches that could be applied this weekend. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > After resolving these items, I'd like to tag and roll the 1.3.0 > release on Monday Feburary 13. > > There would be a 1.3.0 release for each of the seven dwarfs, and a > "Library" ZIP file with just the JARS utilized by all seven. (Except > the Servlet and JSTL JARs, unless we can redistribute these too.) > > Again, this is not a vote on the quality of the release, only whether > to tag the trunk with the marker STRUTS_1_3_0. My vote is +1 for the plan. However with the code as it stands at the moment (re Bug #38534 and Bug #38374) I will be voting "beta" for the quality. > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
A whole-hearted +1 and an AMEN to boot! Don Joe Germuska wrote: I think it's fine if Struts 1.3.0 is understood to not be expected to reach GA status. I think we should go ahead and cut the release, and expect that it will be "beta" at best. I don't think the issues Niall raised are things that are unheard of in a beta. We don't seem to have actually narrowed in on a process which lets us cut releases as frequently as we thought we would when we adopted the Apache numbering scheme, but by the ideal process, it's not a real big deal to put the tag on and push the thing out the door. If people agree with some of the recent concerns about the API, like the naming and responsibility of the ActionContext class, then they could vote to mark the release merely Alpha -- but that doesn't mean there shouldn't be a release. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > By the way, I didn't catch the DOS hole... can someone point me at the > appropriate ticket? http://issues.apache.org/bugzilla/show_bug.cgi?id=38534 If you drop the 1.2 Branch version of upload.jsp into the Struts 1.2.8 version of the examples webapp - you can see it in action: http://svn.apache.org/viewcvs.cgi/struts/action/branches/STRUTS_1_2_BRANCH/web/examples/upload/ I've patched the 1.2.x branch for this bug, but held off fixing it in 1.3 at Ted's request. Niall > > Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
At 10:06 AM -0500 2/16/06, Frank W. Zammetti wrote: On Thu, February 16, 2006 9:45 am, Niall Pemberton said: My view is that this is "security hole" that we are fixing, not adding a new feature. I also think that the original RequestProcessor and TilesRequestProcessor offer people a way of upgrading to 1.3 and use tried and tested code - without having to adopt the CoR implementation. Since I have implemented the Cancellable behaviour in the 1.2.x branch, then either it needs also applying to the 1.3 branch or that change needs to be reversed. We probably should release a Struts 1.2.9 to fix this issue and the "DOS attack" issue and I am willing to do that - probably have time in a couple of weeks. +1 to Niall's comments, and therefore a non-binding -1 to tagging the repository... I don't see the point in even simply tagging if there are two outstanding security issues. I think it's fine if Struts 1.3.0 is understood to not be expected to reach GA status. I think we should go ahead and cut the release, and expect that it will be "beta" at best. I don't think the issues Niall raised are things that are unheard of in a beta. We don't seem to have actually narrowed in on a process which lets us cut releases as frequently as we thought we would when we adopted the Apache numbering scheme, but by the ideal process, it's not a real big deal to put the tag on and push the thing out the door. If people agree with some of the recent concerns about the API, like the naming and responsibility of the ActionContext class, then they could vote to mark the release merely Alpha -- but that doesn't mean there shouldn't be a release. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Non-binding +1 to tagging the repository. Sorry for the late response. Greg On Feb 16, 2006, at 8:15 AM, Ted Husted wrote: A release plan is a majority vote, so we need three binding +1s from PMC members and more binding +1s than -1s. A +1 here is on the tagging the repository. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On Thu, February 16, 2006 9:45 am, Niall Pemberton said: > My view is that this is "security hole" that we are fixing, not adding > a new feature. I also think that the original RequestProcessor and > TilesRequestProcessor offer people a way of upgrading to 1.3 and use > tried and tested code - without having to adopt the CoR > implementation. > > Since I have implemented the Cancellable behaviour in the 1.2.x > branch, then either it needs also applying to the 1.3 branch or that > change needs to be reversed. > > We probably should release a Struts 1.2.9 to fix this issue and the > "DOS attack" issue and I am willing to do that - probably have time in > a couple of weeks. +1 to Niall's comments, and therefore a non-binding -1 to tagging the repository... I don't see the point in even simply tagging if there are two outstanding security issues. By the way, I didn't catch the DOS hole... can someone point me at the appropriate ticket? > Niall Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/16/06, Ted Husted <[EMAIL PROTECTED]> wrote: > I've now tested the applications with the legacy RP and updated the > Release Notes as to the new "Opt-In Cancel Handler". > > As this point, I'd rather not update the legacy RP to support Opt-In > Cancel Handling. If we make any further changes to this feature, or > any other new feature, we'd have to maintain the code in two places. > As long as the behavior gracefully degrades, it seems reasonable to me > to add new features to the new RequestProcessor and leaving the legacy > RP alone (unless the 1.2.x branch is also going to be released - but > no one has volunteered to do that). If people want access to features > new to 1.3, they can use the new RP. If the new CRP passes muster and > remains the default for 1.3.1, we should move the legacy RP to > "extras" and deprecate it. My view is that this is "security hole" that we are fixing, not adding a new feature. I also think that the original RequestProcessor and TilesRequestProcessor offer people a way of upgrading to 1.3 and use tried and tested code - without having to adopt the CoR implementation. Since I have implemented the Cancellable behaviour in the 1.2.x branch, then either it needs also applying to the 1.3 branch or that change needs to be reversed. We probably should release a Struts 1.2.9 to fix this issue and the "DOS attack" issue and I am willing to do that - probably have time in a couple of weeks. > If this change prompts anyone to change their vote, please chime-in > now. A release plan is a majority vote, so we need three binding +1s > from PMC members and more binding +1s than -1s. A +1 here is on the > tagging the repository. A quality vote would follow once the test > builds are posted. I realize the plan vote and quality vote are separte issues, but IMO the DOS attack bug is v.serious - you can stop a whole web app from working using it - and I don't understand why were not fixing it in 1.3.0. IMO 1.3.0 is never going to be more than a beta with this "DOS attack" bug - or with the original request processor "cancellable" security hole. Both are really bad. Niall > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I've now tested the applications with the legacy RP and updated the Release Notes as to the new "Opt-In Cancel Handler". As this point, I'd rather not update the legacy RP to support Opt-In Cancel Handling. If we make any further changes to this feature, or any other new feature, we'd have to maintain the code in two places. As long as the behavior gracefully degrades, it seems reasonable to me to add new features to the new RequestProcessor and leaving the legacy RP alone (unless the 1.2.x branch is also going to be released - but no one has volunteered to do that). If people want access to features new to 1.3, they can use the new RP. If the new CRP passes muster and remains the default for 1.3.1, we should move the legacy RP to "extras" and deprecate it. If this change prompts anyone to change their vote, please chime-in now. A release plan is a majority vote, so we need three binding +1s from PMC members and more binding +1s than -1s. A +1 here is on the tagging the repository. A quality vote would follow once the test builds are posted. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I think the fact that some committers are building code for their personal use and have already personally "committed" it is not a good reason to roll out a bad idea. On 2/15/06, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > > > On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > > Is it the intention of the Struts commiters to > > > make a Command something like a new Action that should be used > instead? > > > Or are you expecting commands to be created solely for the request > > processor chain? > > > > Some people have suggested that Command replace Action, and we are > > encouraging people to explore that avenue to see how well it works. > > Personally, I favor using Commands the way WebWork/Action2 uses > > Interceptors and leaving Action as a "place to stand" on the web > > layer. > > > > Our intent has been to make a numbered build available so that we can > > get more input from other Struts developers. > > > > > If it is the second, then I stand by my suggestion that ActionContext > > should be renamed > > > to reserve the name (ProcessorActionContext?) for the day when you > want > > actions to > > > receive an ActionContext like WebWork. > > > > :) There are any number of naming quirks in Struts Action 1.x, and I > > don't know if one more is going to make a difference. :) > > > > The 1.3.x series has been cooking for about 18 months now (since the > > summer of 2004), and some people are already using it in production. I > > think if we do not get something rolled this week, a few us might > > burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't > > mean that we can't make significant API changes before 1.3.x goes GA. > > But, it does mean more people will look at what we've done so far. > > > > If we did decide to rename a member for future use, we could copy it > > and deprecate the old one for a milestone, and then remove the old > > one. But, since the ActionContext has been in the nightly build for > > many, many months, we should not just change it willy-nilly. > > > I just checked SVN, and ActionContext has been in there for just over a > year. Some people have been developing with it in nightly builds since > then. > I, for one, am certainly not in favour of changing such a key class on the > eve of rolling the first "real" 1.3.x build, not least because I don't > want > to have to go change my code! ;-) > > Once we > > get a numbered build out there, I'm sure that there will be many more > > comments like this. If there is interest, we can regroup and make any > > desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we > > have deprecated and removed and released new members during a beta > > cycle, and I expect we wil do so again. > > > > The other important thing is that once we roll the seven 1.3.0 builds, > > we can make internal changes to Action without re-releasing the other > > six, if the external API doesn't change. > > > > I would tend to agree that we need two flavors of Context available > > during the request/response cycle. One for the Actions and Commands to > > use internally, and another for server pages (including Velocity > > templates) to read externally. Perhaps we could just adopt the > > Velocity Tools for that, and expect that tags to get everything they > > need from a "tool" passed through the request. > > > > * http://jakarta.apache.org/velocity/tools/ > > > > But, before getting into anything like that, we should roll the 1.3.0 > > builds, so that we can start making lighter releases. > > > +1 > > -- > Martin Cooper > > > I didn't have any discretionary time last night, but, hopefully, I can > > wrap up the review of the Release Notes tonight. We can then tag the > > repository for STRUTS_1_3_0 as well as for each of the subprojects > > (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. > > > > -- HTH, Ted. > > ** http://www.husted.com/ted/blog/ > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
For my part, I don't think haste because things are late is a good idea. Do it right and have a good product. On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Is it the intention of the Struts commiters to > > make a Command something like a new Action that should be used instead? > > Or are you expecting commands to be created solely for the request > processor chain? > > Some people have suggested that Command replace Action, and we are > encouraging people to explore that avenue to see how well it works. > Personally, I favor using Commands the way WebWork/Action2 uses > Interceptors and leaving Action as a "place to stand" on the web > layer. > > Our intent has been to make a numbered build available so that we can > get more input from other Struts developers. > > > If it is the second, then I stand by my suggestion that ActionContext > should be renamed > > to reserve the name (ProcessorActionContext?) for the day when you want > actions to > > receive an ActionContext like WebWork. > > :) There are any number of naming quirks in Struts Action 1.x, and I > don't know if one more is going to make a difference. :) > > The 1.3.x series has been cooking for about 18 months now (since the > summer of 2004), and some people are already using it in production. I > think if we do not get something rolled this week, a few us might > burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't > mean that we can't make significant API changes before 1.3.x goes GA. > But, it does mean more people will look at what we've done so far. > > If we did decide to rename a member for future use, we could copy it > and deprecate the old one for a milestone, and then remove the old > one. But, since the ActionContext has been in the nightly build for > many, many months, we should not just change it willy-nilly. Once we > get a numbered build out there, I'm sure that there will be many more > comments like this. If there is interest, we can regroup and make any > desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we > have deprecated and removed and released new members during a beta > cycle, and I expect we wil do so again. > > The other important thing is that once we roll the seven 1.3.0 builds, > we can make internal changes to Action without re-releasing the other > six, if the external API doesn't change. > > I would tend to agree that we need two flavors of Context available > during the request/response cycle. One for the Actions and Commands to > use internally, and another for server pages (including Velocity > templates) to read externally. Perhaps we could just adopt the > Velocity Tools for that, and expect that tags to get everything they > need from a "tool" passed through the request. > > * http://jakarta.apache.org/velocity/tools/ > > But, before getting into anything like that, we should roll the 1.3.0 > builds, so that we can start making lighter releases. > > I didn't have any discretionary time last night, but, hopefully, I can > wrap up the review of the Release Notes tonight. We can then tag the > repository for STRUTS_1_3_0 as well as for each of the subprojects > (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. > > -- HTH, Ted. > ** http://www.husted.com/ted/blog/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Is it the intention of the Struts commiters to > > make a Command something like a new Action that should be used instead? > > Or are you expecting commands to be created solely for the request > processor chain? > > Some people have suggested that Command replace Action, and we are > encouraging people to explore that avenue to see how well it works. > Personally, I favor using Commands the way WebWork/Action2 uses > Interceptors and leaving Action as a "place to stand" on the web > layer. > > Our intent has been to make a numbered build available so that we can > get more input from other Struts developers. > > > If it is the second, then I stand by my suggestion that ActionContext > should be renamed > > to reserve the name (ProcessorActionContext?) for the day when you want > actions to > > receive an ActionContext like WebWork. > > :) There are any number of naming quirks in Struts Action 1.x, and I > don't know if one more is going to make a difference. :) > > The 1.3.x series has been cooking for about 18 months now (since the > summer of 2004), and some people are already using it in production. I > think if we do not get something rolled this week, a few us might > burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't > mean that we can't make significant API changes before 1.3.x goes GA. > But, it does mean more people will look at what we've done so far. > > If we did decide to rename a member for future use, we could copy it > and deprecate the old one for a milestone, and then remove the old > one. But, since the ActionContext has been in the nightly build for > many, many months, we should not just change it willy-nilly. I just checked SVN, and ActionContext has been in there for just over a year. Some people have been developing with it in nightly builds since then. I, for one, am certainly not in favour of changing such a key class on the eve of rolling the first "real" 1.3.x build, not least because I don't want to have to go change my code! ;-) Once we > get a numbered build out there, I'm sure that there will be many more > comments like this. If there is interest, we can regroup and make any > desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we > have deprecated and removed and released new members during a beta > cycle, and I expect we wil do so again. > > The other important thing is that once we roll the seven 1.3.0 builds, > we can make internal changes to Action without re-releasing the other > six, if the external API doesn't change. > > I would tend to agree that we need two flavors of Context available > during the request/response cycle. One for the Actions and Commands to > use internally, and another for server pages (including Velocity > templates) to read externally. Perhaps we could just adopt the > Velocity Tools for that, and expect that tags to get everything they > need from a "tool" passed through the request. > > * http://jakarta.apache.org/velocity/tools/ > > But, before getting into anything like that, we should roll the 1.3.0 > builds, so that we can start making lighter releases. +1 -- Martin Cooper I didn't have any discretionary time last night, but, hopefully, I can > wrap up the review of the Release Notes tonight. We can then tag the > repository for STRUTS_1_3_0 as well as for each of the subprojects > (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. > > -- HTH, Ted. > ** http://www.husted.com/ted/blog/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > OK I did both of those - hopefully I didn't miss anything important. > Most were pretty trivial - except for highlighting the new > dependencies, especially Servlet 2.3 and JDK 1.4 and of course Wendy > joining the PMC :-) Thanks. We probably just need to add something about the new Cancel handling and maybe that we're using Jalopy to format the code now. I'll try to get back to this tonight or tomorrow morning, unless someone else wants to mop it up. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > On 2/15/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > Do you want any help with the release notes - or anything else? Let me know. > > If anyone wanted to pop-in and update the release notes from November > to now, that would be great. The only other thing I wanted to do was > fix the links from Site to the subprojects to be absolute, so they > don't break if you only checkout Site. Then, AFAIC, it's tag the > repository and roll the test builds (which is to say the nightly > builds with a version numbers instea of a date). OK I did both of those - hopefully I didn't miss anything important. Most were pretty trivial - except for highlighting the new dependencies, especially Servlet 2.3 and JDK 1.4 and of course Wendy joining the PMC :-) Niall > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted Husted wrote: Some people have suggested that Command replace Action ... . Personally, I favor using Commands the way WebWork/Action2 uses Interceptors ... (spin) Oh yeah. That one signature can do anything. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > Do you want any help with the release notes - or anything else? Let me know. If anyone wanted to pop-in and update the release notes from November to now, that would be great. The only other thing I wanted to do was fix the links from Site to the subprojects to be absolute, so they don't break if you only checkout Site. Then, AFAIC, it's tag the repository and roll the test builds (which is to say the nightly builds with a version numbers instea of a date). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Joe, thanks for the feedback. Since you could do all those controller related settings in 1.2 if you knew where to look, putting them all in the ActionContext kind-of raises the IQ of the command/action. It's an advertisement of internal features, so to speak, and I don't really believe, as I said, it's appropriate to expose those to the receiver (but I am OK within the RP). That's all - anything else and I'd be repeating :) Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted, please make sure you patch the original RP for InvalidCancelException in 1.3 before you tag. I included a patch already. Someone has to test it (good practice) but the change is identicial/trivial. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
At 8:13 PM -0800 2/14/06, Paul Benedict wrote: >> But I noticed the ActionContext is mainly for the request processor and looks like it contains TOO much data that would never be exposed to an action class to use. I may have misunderstood but I'd like for someone to clarify. I find it very strange that the ActionContext would allow a command to *set* the action, cancelled, exception, form valid, forward config, messages resources, and module config. As I said before, these are all controller related issues. Is it the intention of the Struts commiters to make a Command something like a new Action that should be used instead? Or are you expecting commands to be created solely for the request processor chain? As a matter of fact, yes. The ActionContext was designed specifically so that something in possession of one could do everything that a Struts Action class could do. There's nothing you can do with an ActionContext that you couldn't do in Struts 1.2.x without the chain if you knew where it was to be done. More generally, the Context in the chain pattern is the common space through which commands can interact. Without it, you can't effectively decompose behavior because no command can have any way of knowing what else has happened before. The ActionContext class just implements java methods in preferences to using keys in a map. This both makes the code more readable and makes it easier to actually put the values in request or session scope, maintaining backwards compatibility with things which look there for values instead of through the ActionContext. I find it very strange that the ActionContext would allow a command to *set* the action, cancelled, exception, form valid, forward config, messages resources, and module config. As I said before, these are all controller related issues. Why is this strange? The commands are controller related -- they are components of the controller. If it is the second, then I stand by my suggestion that ActionContext should be renamed to reserve the name (ProcessorActionContext?) for the day when you want actions to receive an ActionContext like WebWork. It just contains too many internal properties you don't want a client to be able to mess around with. I think lots of Struts 1.x will not make a direct transition to Struts 2.x. I don't think we necessarily have to worry that much about this potential overlap. That said, I wouldn't veto a change if other committers agree strongly with Paul. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Ted Husted <[EMAIL PROTECTED]> wrote: > I didn't have any discretionary time last night, but, hopefully, I can > wrap up the review of the Release Notes tonight. We can then tag the > repository for STRUTS_1_3_0 as well as for each of the subprojects > (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. Do you want any help with the release notes - or anything else? Let me know. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > Is it the intention of the Struts commiters to > make a Command something like a new Action that should be used instead? > Or are you expecting commands to be created solely for the request processor > chain? Some people have suggested that Command replace Action, and we are encouraging people to explore that avenue to see how well it works. Personally, I favor using Commands the way WebWork/Action2 uses Interceptors and leaving Action as a "place to stand" on the web layer. Our intent has been to make a numbered build available so that we can get more input from other Struts developers. > If it is the second, then I stand by my suggestion that ActionContext should > be renamed > to reserve the name (ProcessorActionContext?) for the day when you want > actions to > receive an ActionContext like WebWork. :) There are any number of naming quirks in Struts Action 1.x, and I don't know if one more is going to make a difference. :) The 1.3.x series has been cooking for about 18 months now (since the summer of 2004), and some people are already using it in production. I think if we do not get something rolled this week, a few us might burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't mean that we can't make significant API changes before 1.3.x goes GA. But, it does mean more people will look at what we've done so far. If we did decide to rename a member for future use, we could copy it and deprecate the old one for a milestone, and then remove the old one. But, since the ActionContext has been in the nightly build for many, many months, we should not just change it willy-nilly. Once we get a numbered build out there, I'm sure that there will be many more comments like this. If there is interest, we can regroup and make any desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we have deprecated and removed and released new members during a beta cycle, and I expect we wil do so again. The other important thing is that once we roll the seven 1.3.0 builds, we can make internal changes to Action without re-releasing the other six, if the external API doesn't change. I would tend to agree that we need two flavors of Context available during the request/response cycle. One for the Actions and Commands to use internally, and another for server pages (including Velocity templates) to read externally. Perhaps we could just adopt the Velocity Tools for that, and expect that tags to get everything they need from a "tool" passed through the request. * http://jakarta.apache.org/velocity/tools/ But, before getting into anything like that, we should roll the 1.3.0 builds, so that we can start making lighter releases. I didn't have any discretionary time last night, but, hopefully, I can wrap up the review of the Release Notes tonight. We can then tag the repository for STRUTS_1_3_0 as well as for each of the subprojects (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. -- HTH, Ted. ** http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
>> But I noticed the ActionContext is mainly for the request processor and >> looks like it contains TOO much data that would never be exposed to an action class to use. I may have misunderstood but I'd like for someone to clarify. I find it very strange that the ActionContext would allow a command to *set* the action, cancelled, exception, form valid, forward config, messages resources, and module config. As I said before, these are all controller related issues. Is it the intention of the Struts commiters to make a Command something like a new Action that should be used instead? Or are you expecting commands to be created solely for the request processor chain? If it is the second, then I stand by my suggestion that ActionContext should be renamed to reserve the name (ProcessorActionContext?) for the day when you want actions to receive an ActionContext like WebWork. It just contains too many internal properties you don't want a client to be able to mess around with. Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > First, I noticed the 1.3 API docs are built using Java 5. Is 1.3 Java 5 > compliant? > I didn't think this was the case so please make sure those are being built > with > the right compiler. > If you go to this link, you will notice the Map interface is using the Java > 5 templates: > http://struts.apache.org/struts-action/apidocs/org/apache/struts/chain/contexts/ActionContext.html Thanks for pointing this out. While the compiler is configured to target 1.4 regardless of what JDK is used to build, we're missing the 'maven.javadoc.source' property to do the same thing for the javadoc tool. I'll add it to project.properties and re-publish the site. * http://svn.apache.org/repos/asf/struts/build/trunk/project.properties -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
All, I have some concerns about the Struts 1.3 branch. First, I noticed the 1.3 API docs are built using Java 5. Is 1.3 Java 5 compliant? I didn't think this was the case so please make sure those are being built with the right compiler. If you go to this link, you will notice the Map interface is using the Java 5 templates: http://struts.apache.org/struts-action/apidocs/org/apache/struts/chain/contexts/ActionContext.html Second, please do some further thinking about the name ActionContext. I just got my WebWork book and am reading it, and I have some preliminary ideas how we can wrap the 1.x branch to use POJO Action classes that do not require an interface or subclass. But this would of course require the ActionContext to be passed in so all the necessary input and output data can be used. But I noticed the ActionContext is mainly for the request processor and looks like it contains TOO much data that would never be exposed to an action class to use. I understand this. But WebWork has an ActionContext class too and I think it would be very smart of us to rename the current ActionContext class to something like InternalActionContext so we do not use up this name. For once we release in 1.3, the name is pretty much stuck. I recommend we reserve "ActionContext" for the future, to contain the context we would actually want to expose to a future Action implementation. Paul - Relax. Yahoo! Mail virus scanning helps detect nasty viruses!
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
a bit late, but +1 -- James Mitchell EdgeTech, Inc. http://edgetechservices.net/ 678.910.8017 Skype: jmitchtx On Feb 14, 2006, at 8:17 AM, Ted Husted wrote: I'm through the applications, and so now it's just a final review of the release note, and then we can start down the Checklist A of the Plan. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I'm through the applications, and so now it's just a final review of the release note, and then we can start down the Checklist A of the Plan. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/14/06, Ted Husted <[EMAIL PROTECTED]> wrote: > On 2/13/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > If no one shouts in the next hour, I'm going to fix this. > > I'm in the middle of the final testing of the build as it stands now, > and I would prefer that there be no more changes. OK I'll leave it :-( Niall > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/13/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > If no one shouts in the next hour, I'm going to fix this. I'm in the middle of the final testing of the build as it stands now, and I would prefer that there be no more changes. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/14/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > Here's my take on it: > > I think fixing RequestUtils to bypass the multipart property is a patch. I > say that because it's a pointed solution to a specific problem. If we look > at this as a temporary fix, I am okay with that because it does provide a > solution and then it can be replaced with a broader solution. It is just a patch - the long term solution to this specific bug is to remove the getter method from ActionForm. > That of course assumes a broader solution :-) > > I really do want to investigate allowing the form to dictate which > properties are valid/invalid for population by the RP. Does anyone want to > investigate this with me? I still find a blacklist or whitelist map to be > the way to go. I am sensitive to what properties people can populate in my > form with a good guess; and you'd be surprised what can be inferred from a > logical group of property names. This is a different issue from this bug and I don't' think I agree that its even a problem. If you expose something in your ActionForm that you don't want populated then that is where the problem lies and you need to get them out of the ActionForm. Niall > Paul > > > - > Brings words and photos together (easily) with > PhotoMail - it's free and works with Yahoo! Mail. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Here's my take on it: I think fixing RequestUtils to bypass the multipart property is a patch. I say that because it's a pointed solution to a specific problem. If we look at this as a temporary fix, I am okay with that because it does provide a solution and then it can be replaced with a broader solution. That of course assumes a broader solution :-) I really do want to investigate allowing the form to dictate which properties are valid/invalid for population by the RP. Does anyone want to investigate this with me? I still find a blacklist or whitelist map to be the way to go. I am sensitive to what properties people can populate in my form with a good guess; and you'd be surprised what can be inferred from a logical group of property names. Paul - Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail.
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/14/06, Ted Husted <[EMAIL PROTECTED]> wrote: > OK, we're making some progress. The Cancellable code is in, and I'm > testing the example applications again, updating the configurations as > needed for the cancellable property. After that, it's a final pass on > the Relesae Notes (since November)., and we should be able to roll > each of the seven subprojects. I'd like to fix "DOS attack, application hack" by patching RequestUtils to ignore any parameter starting with "multipartRequestHandler.". http://issues.apache.org/bugzilla/show_bug.cgi?id=38534 I don't understand your comment about there being no agreement and moving it to 1.3.1 - no one seemed to object to this proposal. I think Paul just wanted a more complete solution in general. Its not elegant but it plugs the gap and I think this is the main bug left thats going to screw up 1.3.0's quality vote. If no one shouts in the next hour, I'm going to fix this. Niall > Hopefully, I can make some time in the evenings to finish this up, > but we're starting a new phase at work tomorrow, and I don't know how > much time I'll have. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
OK, we're making some progress. The Cancellable code is in, and I'm testing the example applications again, updating the configurations as needed for the cancellable property. After that, it's a final pass on the Relesae Notes (since November)., and we should be able to roll each of the seven subprojects. Hopefully, I can make some time in the evenings to finish this up, but we're starting a new phase at work tomorrow, and I don't know how much time I'll have. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
At 10:24 AM -0800 2/13/06, Don Brown wrote: +1 Lets just get something out the door already :) +1 and amen -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com "You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new." -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
>From: Ted Husted <[EMAIL PROTECTED]> > > OK, we're back down to two patches that could be applied this weekend. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > After resolving these items, I'd like to tag and roll the 1.3.0 > release on Monday Feburary 13. > > There would be a 1.3.0 release for each of the seven dwarfs, and a > "Library" ZIP file with just the JARS utilized by all seven. (Except > the Servlet and JSTL JARs, unless we can redistribute these too.) > > Again, this is not a vote on the quality of the release, only whether > to tag the trunk with the marker STRUTS_1_3_0. > +1 for consistency > -Ted. > > > On 11/21/05, Ted Husted wrote: > > There are two significant items left on the Struts Action Library > > 1.3.0 (aka Struts Classic) release plan before we would tag and roll > > it. One is renaming struts-action to struts-core, and the other are > > minor changes to the documentation. > > > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > > > At this time, I would ask the PMC, committers, and other interested > > parties to review the plan and the state of the repository. Please > > indicate your opinion on the plan in the usual style: +1, +0, or -1, > > along with any appropriate comments. > > > > Note this this is not a vote on the quality of the intended release, > > but on the release plan. > > > > Given a positive result, it would be our intention to roll the release > > on Thursday or Friday, assuming we rename the struts-core folder on > > Wednesday. > > > > As stated in the plan, this release is intended as a test of the new > > infrastructure, and other releases in the 1.3.x series are expected. > > > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
+1 Lets just get something out the door already :) Don On 11/21/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > There are two significant items left on the Struts Action Library > 1.3.0 (aka Struts Classic) release plan before we would tag and roll > it. One is renaming struts-action to struts-core, and the other are > minor changes to the documentation. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > At this time, I would ask the PMC, committers, and other interested > parties to review the plan and the state of the repository. Please > indicate your opinion on the plan in the usual style: +1, +0, or -1, > along with any appropriate comments. > > Note this this is not a vote on the quality of the intended release, > but on the release plan. > > Given a positive result, it would be our intention to roll the release > on Thursday or Friday, assuming we rename the struts-core folder on > Wednesday. > > As stated in the plan, this release is intended as a test of the new > infrastructure, and other releases in the 1.3.x series are expected. > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > OK, we're back down to two patches that could be applied this weekend. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > After resolving these items, I'd like to tag and roll the 1.3.0 > release on Monday Feburary 13. > > There would be a 1.3.0 release for each of the seven dwarfs, and a > "Library" ZIP file with just the JARS utilized by all seven. (Except > the Servlet and JSTL JARs, unless we can redistribute these too.) > > Again, this is not a vote on the quality of the release, only whether > to tag the trunk with the marker STRUTS_1_3_0. And produce and announce a 1.3.0 Test Build, I assume? +1 on that. You could wait until Tuesday and claim it's a Valentine's Day gift. ;-) -- Martin Cooper -Ted. > > > On 11/21/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > There are two significant items left on the Struts Action Library > > 1.3.0 (aka Struts Classic) release plan before we would tag and roll > > it. One is renaming struts-action to struts-core, and the other are > > minor changes to the documentation. > > > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > > > At this time, I would ask the PMC, committers, and other interested > > parties to review the plan and the state of the repository. Please > > indicate your opinion on the plan in the usual style: +1, +0, or -1, > > along with any appropriate comments. > > > > Note this this is not a vote on the quality of the intended release, > > but on the release plan. > > > > Given a positive result, it would be our intention to roll the release > > on Thursday or Friday, assuming we rename the struts-core folder on > > Wednesday. > > > > As stated in the plan, this release is intended as a test of the new > > infrastructure, and other releases in the 1.3.x series are expected. > > > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
RE: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
+1 -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Saturday, February 11, 2006 9:56 AM To: Struts Developers List Subject: Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan OK, we're back down to two patches that could be applied this weekend. * http://wiki.apache.org/struts/StrutsClassicRelease130 After resolving these items, I'd like to tag and roll the 1.3.0 release on Monday Feburary 13. There would be a 1.3.0 release for each of the seven dwarfs, and a "Library" ZIP file with just the JARS utilized by all seven. (Except the Servlet and JSTL JARs, unless we can redistribute these too.) Again, this is not a vote on the quality of the release, only whether to tag the trunk with the marker STRUTS_1_3_0. -Ted. On 11/21/05, Ted Husted <[EMAIL PROTECTED]> wrote: > There are two significant items left on the Struts Action Library > 1.3.0 (aka Struts Classic) release plan before we would tag and roll > it. One is renaming struts-action to struts-core, and the other are > minor changes to the documentation. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > At this time, I would ask the PMC, committers, and other interested > parties to review the plan and the state of the repository. Please > indicate your opinion on the plan in the usual style: +1, +0, or -1, > along with any appropriate comments. > > Note this this is not a vote on the quality of the intended release, > but on the release plan. > > Given a positive result, it would be our intention to roll the release > on Thursday or Friday, assuming we rename the struts-core folder on > Wednesday. > > As stated in the plan, this release is intended as a test of the new > infrastructure, and other releases in the 1.3.x series are expected. > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
If you were able to work something up today, that would be great. Otherwise, I'll cobble something up in the morning. On 2/11/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > Ted, are you working on the 1.3 cancel patch? I don't want to duplicate work > you're already doing. Please say if you're already in the middle. I can help > out with other things if you need them. -- Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I was confusing DOS Attack with "Multipart Command Implementation" #38613. I see from the updated notes that you'd prefer to leave that for 1.3.1. As for DOS Attack, since there is not a clear fix, we should also leave that for 1.3.1, or whenever we are ready to commit to a fix. -Ted. On 2/11/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 2/11/06, Ted Husted <[EMAIL PROTECTED]> wrote: > > On 2/11/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > I don't have a patch for #38534 - my proposed changes for #38613 > > > includes fixing #38534. Did you mean commit #38613? > > > > If you can commit the code to resolve "DOS attack, application hack", > > I'll make the necessary changes to resolve "Validation always skipped > > with Globals.CANCEL_KEY". > > OK as I said I don't have a patch for this - currently needs a change > to RequestProcessor - if I put in my "multipart command" changes, they > include preventing this - without those changes then the fix to > RequestProcessor does the job. > > > It looks like the changes would overlap, and since you've already done > > the work, it would be better to commit that first. > > I've just had a quick look - I can't see any overlap - if your > adopting Pauls patch for Struts 1.2 to the Commands then your going to > be changing AbstractValidateActionForm, which I have no changes for. > > Niall > > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I don't have a patch for #38534 - my proposed changes for #38613 > includes fixing #38534. Did you mean commit #38613? If you can commit the code to resolve "DOS attack, application hack", I'll make the necessary changes to resolve "Validation always skipped with Globals.CANCEL_KEY". It looks like the changes would overlap, and since you've already done the work, it would be better to commit that first. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Ted Husted <[EMAIL PROTECTED]> wrote: > On 2/11/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > I'm going to try and do a quick review of the bugs not on the release plan. > > Under the heading "first things first", could you commit the patch for > #38534, then I can address #38374, to clear the tickets that are > already on the release plan. I don't have a patch for #38534 - my proposed changes for #38613 includes fixing #38534. Did you mean commit #38613? Niall > If we can get a majority vote on the plan by Monday, I have time > available to tag and roll the release. > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > I'm going to try and do a quick review of the bugs not on the release plan. Under the heading "first things first", could you commit the patch for #38534, then I can address #38374, to clear the tickets that are already on the release plan. If we can get a majority vote on the plan by Monday, I have time available to tag and roll the release. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted, are you working on the 1.3 cancel patch? I don't want to duplicate work you're already doing. Please say if you're already in the middle. I can help out with other things if you need them. -- Paul - Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail.
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Ted Husted <[EMAIL PROTECTED]> wrote: > OK, we're back down to two patches that could be applied this weekend. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 When I run a report of open bugs (i.e. non-enhancements) for the components in 1.3 it produces a list of 44 bugs - which doesn't match up with the bug list on the release plan: http://tinyurl.com/bp8bw I'm going to try and do a quick review of the bugs not on the release plan. Niall > After resolving these items, I'd like to tag and roll the 1.3.0 > release on Monday Feburary 13. > > There would be a 1.3.0 release for each of the seven dwarfs, and a > "Library" ZIP file with just the JARS utilized by all seven. (Except > the Servlet and JSTL JARs, unless we can redistribute these too.) > > Again, this is not a vote on the quality of the release, only whether > to tag the trunk with the marker STRUTS_1_3_0. > > -Ted. > > > On 11/21/05, Ted Husted <[EMAIL PROTECTED]> wrote: > > There are two significant items left on the Struts Action Library > > 1.3.0 (aka Struts Classic) release plan before we would tag and roll > > it. One is renaming struts-action to struts-core, and the other are > > minor changes to the documentation. > > > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > > > At this time, I would ask the PMC, committers, and other interested > > parties to review the plan and the state of the repository. Please > > indicate your opinion on the plan in the usual style: +1, +0, or -1, > > along with any appropriate comments. > > > > Note this this is not a vote on the quality of the intended release, > > but on the release plan. > > > > Given a positive result, it would be our intention to roll the release > > on Thursday or Friday, assuming we rename the struts-core folder on > > Wednesday. > > > > As stated in the plan, this release is intended as a test of the new > > infrastructure, and other releases in the 1.3.x series are expected. > > > > -Ted. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/11/06, Ted Husted <[EMAIL PROTECTED]> wrote: > OK, we're back down to two patches that could be applied this weekend. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > After resolving these items, I'd like to tag and roll the 1.3.0 > release on Monday Feburary 13. > > There would be a 1.3.0 release for each of the seven dwarfs, and a > "Library" ZIP file with just the JARS utilized by all seven. (Except > the Servlet and JSTL JARs, unless we can redistribute these too.) What about the tld and dtd files? Looks like those were in the 1.2.8 library distribution, though struts-el was not. We should probably include validator-rules.xml as well, even though it is also packaged in one of the jars. > Again, this is not a vote on the quality of the release, only whether > to tag the trunk with the marker STRUTS_1_3_0. +1 And no objections to the two patches, in whichever order it makes sense to apply them. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
OK, we're back down to two patches that could be applied this weekend. * http://wiki.apache.org/struts/StrutsClassicRelease130 After resolving these items, I'd like to tag and roll the 1.3.0 release on Monday Feburary 13. There would be a 1.3.0 release for each of the seven dwarfs, and a "Library" ZIP file with just the JARS utilized by all seven. (Except the Servlet and JSTL JARs, unless we can redistribute these too.) Again, this is not a vote on the quality of the release, only whether to tag the trunk with the marker STRUTS_1_3_0. -Ted. On 11/21/05, Ted Husted <[EMAIL PROTECTED]> wrote: > There are two significant items left on the Struts Action Library > 1.3.0 (aka Struts Classic) release plan before we would tag and roll > it. One is renaming struts-action to struts-core, and the other are > minor changes to the documentation. > > * http://wiki.apache.org/struts/StrutsClassicRelease130 > > At this time, I would ask the PMC, committers, and other interested > parties to review the plan and the state of the repository. Please > indicate your opinion on the plan in the usual style: +1, +0, or -1, > along with any appropriate comments. > > Note this this is not a vote on the quality of the intended release, > but on the release plan. > > Given a positive result, it would be our intention to roll the release > on Thursday or Friday, assuming we rename the struts-core folder on > Wednesday. > > As stated in the plan, this release is intended as a test of the new > infrastructure, and other releases in the 1.3.x series are expected. > > -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGLib DynaActioForm problem (was [VOTE] Confirm the Struts Action Library 1.3.0 release plan)
On 11/30/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Niall Pemberton wrote: > > On 11/30/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > >> Niall Pemberton wrote: > >>> On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Niall Pemberton wrote: > >> Also looked like the property types were the wrong way round for > >> indexed methods, so I also switched them. > > Hmm, with that change, accessing a List property is broken. Without > the > > change, all my tests are working. You can deploy the exercises app > with > > the addition I just committed and see for yourself: > > > http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do > > > > I've rolled back your change and everything works fine again, > including > > indexed property access for arrays and lists. The unit test you > added > > passes either way. > I just refreshed and the JUnit test I wrote is now failing for me. > >>> Its failing in gump as well > >>> > http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html > >>> > >>> I've had problems with the maven build - when I've used build-all if a > >>> sub-project test fails maven just carries on ignoring it and it > >>> appears you get a successful build. Now I do the sub-projects > >>> separately. > >>> > >>> I'm wondering if thats what you used? > >> I was using 'maven test' without problem. It seems my checkout was > >> warped, though, because even though svn was telling me it was > >> up-to-date, after an 'svn update' I'm now seeing the failure. > > > > This doesn't make any sense to me, unless you commit first and test > after? > > > >> I'll look at it tomorrow and figure out what's wrong. > > > > OK heres my take on what the issue is. The java bean specification > > defines indexed properties in relation to arrays, so if you have > > methods like... > > > > public String[] getFoo() // simple read > > public void setFoo(String[] foo) // simple write > > public String getFoo(int idx) // indexed read > > public void setFoo(int idx, String foo) // indexed write > > > > ...it will create an IndexedPropertyDescriptor instead of a > > PropertyDescriptor for the Foo property. In previous JDK versions > > (i.e. pre JDK 1.4 I believe) Sun was lenient about the simple > > properties - it didn't care about the parameter/return type, so if you > > defined your simple read/write methods with a java.util.List, it still > > worked. However in JDK 1.4 they changed things, so that if the simple > > read/write didn't return an array then it would still create an > > IndexedPropertyDescriptor, but the getReadMethod/getWriteMethod return > > null, effectively masking the simple read/write methods. > > > > In DynaBeanInterceptor the indexed read/write methods it was creating > > were incorrectly defined and so it wasn't recognizing those as indexed > > properties (and your List worked). I believe my change fixed this > > issue, and effectively masked the simple read/write methods for the > > indexed property defined with a List, although I don't understand why > > your test page didn't work because of this, since JSTL should have > > been able to use the indexed read/write methods. > > > > It would be interesting to see what happens with your test page with a > > "regular" incorrectly defined indexed property, i.e. > > > > public List getFoo() > > public void setFoo(List foo) > > public String getFoo(int idx) > > public void setFoo(int idx, String foo) > > > > OK I guess the question that stands out is, if I'm right on this how > > come your test page worked with incorrectly defined indexed > > properties. My guess is that JSTL is smart enough to handle simple > > properties for arrays and Lists, but if thats true, the fact that your > > page didn't work after my change means that its also too dumb to use > > the indexed read/write methods. > > > > Course I could have this wrong as this is all theory and I haven't put > > any effort into actually proving it. > > > > Niall > > OK, so here's what's going on: JSTL always uses the simple read/write > methods, never the indexed methods. As you surmise, in this case > getReadMethod / getWriteMethod return null. Since JSTL (or at least the > Jakarta Taglibs impl ;-) depends on the simple getter, this causes > things to break. > > So it looks like the solution is to either (a) not generate the indexed > getter/setter at all, as was the case with the original code; or (b) > only do so for array-typed properties; or (c) dynamically convert > List-typed properties into array properties. > > (c) isn't attractive; if I define a bean property of type List, I expect > to be able to access it as such. It does seem worthwhile providing the > indexed getter/setter for array-typed properties, so I think (b) would > be the way to go. +1 for (b). -- Martin Coo
Re: CGLib DynaActioForm problem (was [VOTE] Confirm the Struts Action Library 1.3.0 release plan)
Niall Pemberton wrote: On 11/30/05, Laurie Harper <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: Also looked like the property types were the wrong way round for indexed methods, so I also switched them. Hmm, with that change, accessing a List property is broken. Without the change, all my tests are working. You can deploy the exercises app with the addition I just committed and see for yourself: http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do I've rolled back your change and everything works fine again, including indexed property access for arrays and lists. The unit test you added passes either way. I just refreshed and the JUnit test I wrote is now failing for me. Its failing in gump as well http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html I've had problems with the maven build - when I've used build-all if a sub-project test fails maven just carries on ignoring it and it appears you get a successful build. Now I do the sub-projects separately. I'm wondering if thats what you used? I was using 'maven test' without problem. It seems my checkout was warped, though, because even though svn was telling me it was up-to-date, after an 'svn update' I'm now seeing the failure. This doesn't make any sense to me, unless you commit first and test after? I'll look at it tomorrow and figure out what's wrong. OK heres my take on what the issue is. The java bean specification defines indexed properties in relation to arrays, so if you have methods like... public String[] getFoo() // simple read public void setFoo(String[] foo) // simple write public String getFoo(int idx) // indexed read public void setFoo(int idx, String foo) // indexed write ...it will create an IndexedPropertyDescriptor instead of a PropertyDescriptor for the Foo property. In previous JDK versions (i.e. pre JDK 1.4 I believe) Sun was lenient about the simple properties - it didn't care about the parameter/return type, so if you defined your simple read/write methods with a java.util.List, it still worked. However in JDK 1.4 they changed things, so that if the simple read/write didn't return an array then it would still create an IndexedPropertyDescriptor, but the getReadMethod/getWriteMethod return null, effectively masking the simple read/write methods. In DynaBeanInterceptor the indexed read/write methods it was creating were incorrectly defined and so it wasn't recognizing those as indexed properties (and your List worked). I believe my change fixed this issue, and effectively masked the simple read/write methods for the indexed property defined with a List, although I don't understand why your test page didn't work because of this, since JSTL should have been able to use the indexed read/write methods. It would be interesting to see what happens with your test page with a "regular" incorrectly defined indexed property, i.e. public List getFoo() public void setFoo(List foo) public String getFoo(int idx) public void setFoo(int idx, String foo) OK I guess the question that stands out is, if I'm right on this how come your test page worked with incorrectly defined indexed properties. My guess is that JSTL is smart enough to handle simple properties for arrays and Lists, but if thats true, the fact that your page didn't work after my change means that its also too dumb to use the indexed read/write methods. Course I could have this wrong as this is all theory and I haven't put any effort into actually proving it. Niall OK, so here's what's going on: JSTL always uses the simple read/write methods, never the indexed methods. As you surmise, in this case getReadMethod / getWriteMethod return null. Since JSTL (or at least the Jakarta Taglibs impl ;-) depends on the simple getter, this causes things to break. So it looks like the solution is to either (a) not generate the indexed getter/setter at all, as was the case with the original code; or (b) only do so for array-typed properties; or (c) dynamically convert List-typed properties into array properties. (c) isn't attractive; if I define a bean property of type List, I expect to be able to access it as such. It does seem worthwhile providing the indexed getter/setter for array-typed properties, so I think (b) would be the way to go. I'll give it a try now and see it that does the trick. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CGLib DynaActioForm problem (was [VOTE] Confirm the Struts Action Library 1.3.0 release plan)
Niall Pemberton wrote: On 11/30/05, Laurie Harper <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: Also looked like the property types were the wrong way round for indexed methods, so I also switched them. Hmm, with that change, accessing a List property is broken. Without the change, all my tests are working. You can deploy the exercises app with the addition I just committed and see for yourself: http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do I've rolled back your change and everything works fine again, including indexed property access for arrays and lists. The unit test you added passes either way. I just refreshed and the JUnit test I wrote is now failing for me. Its failing in gump as well http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html I've had problems with the maven build - when I've used build-all if a sub-project test fails maven just carries on ignoring it and it appears you get a successful build. Now I do the sub-projects separately. I'm wondering if thats what you used? I was using 'maven test' without problem. It seems my checkout was warped, though, because even though svn was telling me it was up-to-date, after an 'svn update' I'm now seeing the failure. This doesn't make any sense to me, unless you commit first and test after? Nope, I just somehow had a working copy that *looked* up to date but wasn't... Doesn't make any sense to me either, but I checked out a clean copy to make sure things were consistent so I should be fine now. I'll look at it tomorrow and figure out what's wrong. OK heres my take on what the issue is. The java bean specification defines indexed properties in relation to arrays, so if you have methods like... public String[] getFoo() // simple read public void setFoo(String[] foo) // simple write public String getFoo(int idx) // indexed read public void setFoo(int idx, String foo) // indexed write ...it will create an IndexedPropertyDescriptor instead of a PropertyDescriptor for the Foo property. In previous JDK versions (i.e. pre JDK 1.4 I believe) Sun was lenient about the simple properties - it didn't care about the parameter/return type, so if you defined your simple read/write methods with a java.util.List, it still worked. However in JDK 1.4 they changed things, so that if the simple read/write didn't return an array then it would still create an IndexedPropertyDescriptor, but the getReadMethod/getWriteMethod return null, effectively masking the simple read/write methods. In DynaBeanInterceptor the indexed read/write methods it was creating were incorrectly defined and so it wasn't recognizing those as indexed properties (and your List worked). I believe my change fixed this issue, and effectively masked the simple read/write methods for the indexed property defined with a List, although I don't understand why your test page didn't work because of this, since JSTL should have been able to use the indexed read/write methods. It would be interesting to see what happens with your test page with a "regular" incorrectly defined indexed property, i.e. public List getFoo() public void setFoo(List foo) public String getFoo(int idx) public void setFoo(int idx, String foo) OK I guess the question that stands out is, if I'm right on this how come your test page worked with incorrectly defined indexed properties. My guess is that JSTL is smart enough to handle simple properties for arrays and Lists, but if thats true, the fact that your page didn't work after my change means that its also too dumb to use the indexed read/write methods. Course I could have this wrong as this is all theory and I haven't put any effort into actually proving it. Niall Right, that all makes sense. I'll add some tracing to see what JSTL is actually trying to invoke in each case, and do some testing w/ a non-dynamic form bean for comparison. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CGLib DynaActioForm problem (was [VOTE] Confirm the Struts Action Library 1.3.0 release plan)
On 11/30/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Niall Pemberton wrote: > > On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > >> On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > >>> Niall Pemberton wrote: > Also looked like the property types were the wrong way round for > indexed methods, so I also switched them. > >>> Hmm, with that change, accessing a List property is broken. Without the > >>> change, all my tests are working. You can deploy the exercises app with > >>> the addition I just committed and see for yourself: > >>> http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do > >>> > >>> I've rolled back your change and everything works fine again, including > >>> indexed property access for arrays and lists. The unit test you added > >>> passes either way. > >> I just refreshed and the JUnit test I wrote is now failing for me. > > > > Its failing in gump as well > > http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html > > > > I've had problems with the maven build - when I've used build-all if a > > sub-project test fails maven just carries on ignoring it and it > > appears you get a successful build. Now I do the sub-projects > > separately. > > > > I'm wondering if thats what you used? > > I was using 'maven test' without problem. It seems my checkout was > warped, though, because even though svn was telling me it was > up-to-date, after an 'svn update' I'm now seeing the failure. This doesn't make any sense to me, unless you commit first and test after? > I'll look at it tomorrow and figure out what's wrong. OK heres my take on what the issue is. The java bean specification defines indexed properties in relation to arrays, so if you have methods like... public String[] getFoo() // simple read public void setFoo(String[] foo) // simple write public String getFoo(int idx) // indexed read public void setFoo(int idx, String foo) // indexed write ...it will create an IndexedPropertyDescriptor instead of a PropertyDescriptor for the Foo property. In previous JDK versions (i.e. pre JDK 1.4 I believe) Sun was lenient about the simple properties - it didn't care about the parameter/return type, so if you defined your simple read/write methods with a java.util.List, it still worked. However in JDK 1.4 they changed things, so that if the simple read/write didn't return an array then it would still create an IndexedPropertyDescriptor, but the getReadMethod/getWriteMethod return null, effectively masking the simple read/write methods. In DynaBeanInterceptor the indexed read/write methods it was creating were incorrectly defined and so it wasn't recognizing those as indexed properties (and your List worked). I believe my change fixed this issue, and effectively masked the simple read/write methods for the indexed property defined with a List, although I don't understand why your test page didn't work because of this, since JSTL should have been able to use the indexed read/write methods. It would be interesting to see what happens with your test page with a "regular" incorrectly defined indexed property, i.e. public List getFoo() public void setFoo(List foo) public String getFoo(int idx) public void setFoo(int idx, String foo) OK I guess the question that stands out is, if I'm right on this how come your test page worked with incorrectly defined indexed properties. My guess is that JSTL is smart enough to handle simple properties for arrays and Lists, but if thats true, the fact that your page didn't work after my change means that its also too dumb to use the indexed read/write methods. Course I could have this wrong as this is all theory and I haven't put any effort into actually proving it. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Niall Pemberton wrote: On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote: Niall Pemberton wrote: Also looked like the property types were the wrong way round for indexed methods, so I also switched them. Hmm, with that change, accessing a List property is broken. Without the change, all my tests are working. You can deploy the exercises app with the addition I just committed and see for yourself: http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do I've rolled back your change and everything works fine again, including indexed property access for arrays and lists. The unit test you added passes either way. I just refreshed and the JUnit test I wrote is now failing for me. Its failing in gump as well http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html I've had problems with the maven build - when I've used build-all if a sub-project test fails maven just carries on ignoring it and it appears you get a successful build. Now I do the sub-projects separately. I'm wondering if thats what you used? I was using 'maven test' without problem. It seems my checkout was warped, though, because even though svn was telling me it was up-to-date, after an 'svn update' I'm now seeing the failure. I'll look at it tomorrow and figure out what's wrong. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 11/29/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > Niall Pemberton wrote: > > > Also looked like the property types were the wrong way round for > > > indexed methods, so I also switched them. > > > > Hmm, with that change, accessing a List property is broken. Without the > > change, all my tests are working. You can deploy the exercises app with > > the addition I just committed and see for yourself: > > http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do > > > > I've rolled back your change and everything works fine again, including > > indexed property access for arrays and lists. The unit test you added > > passes either way. > > I just refreshed and the JUnit test I wrote is now failing for me. Its failing in gump as well http://vmgump.apache.org/gump/public/struts/struts-action/gump_work/build_struts_struts-action.html I've had problems with the maven build - when I've used build-all if a sub-project test fails maven just carries on ignoring it and it appears you get a successful build. Now I do the sub-projects separately. I'm wondering if thats what you used? Niall > Niall > > > If you think there's a scenario not covered by the exercises page that > > would be broken with the original code let me know and I'll look into it > > further. > > > > L. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 11/29/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Niall Pemberton wrote: > > Also looked like the property types were the wrong way round for > > indexed methods, so I also switched them. > > Hmm, with that change, accessing a List property is broken. Without the > change, all my tests are working. You can deploy the exercises app with > the addition I just committed and see for yourself: > http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do > > I've rolled back your change and everything works fine again, including > indexed property access for arrays and lists. The unit test you added > passes either way. I just refreshed and the JUnit test I wrote is now failing for me. Niall > If you think there's a scenario not covered by the exercises page that > would be broken with the original code let me know and I'll look into it > further. > > L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Niall Pemberton wrote: Also looked like the property types were the wrong way round for indexed methods, so I also switched them. Hmm, with that change, accessing a List property is broken. Without the change, all my tests are working. You can deploy the exercises app with the addition I just committed and see for yourself: http://localhost:8080/struts-examples/exercise/enhanced-dynabean.do I've rolled back your change and everything works fine again, including indexed property access for arrays and lists. The unit test you added passes either way. If you think there's a scenario not covered by the exercises page that would be broken with the original code let me know and I'll look into it further. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 11/27/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > Niall Pemberton wrote: > > project rather than core. At the moment I'm -0 on this feature because it > > doesn't have any JUnit tests - if tests are added I'd change that to a +0! > > Niall, are you comfortable with just a test page in the exercises app? I > have that almost ready to commit; I just have to figure out what I have > to do to have JSTL expressions evaluated correctly in all supported > levels of JSP release. > > I'll be happy to add JUnit tests as well if you (or anyone) really wants > them ;-) but it might take a little longer to get to. I've added a simple JUnit test for the CGLib enhanced DynaActionForm. Also looked like the property types were the wrong way round for indexed methods, so I also switched them. Niall > L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Niall Pemberton wrote: project rather than core. At the moment I'm -0 on this feature because it doesn't have any JUnit tests - if tests are added I'd change that to a +0! Niall, are you comfortable with just a test page in the exercises app? I have that almost ready to commit; I just have to figure out what I have to do to have JSTL expressions evaluated correctly in all supported levels of JSP release. I'll be happy to add JUnit tests as well if you (or anyone) really wants them ;-) but it might take a little longer to get to. L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I've had a look at Commons Resources and am prepared to put in some time to improve the Resources Site and clean up javadoc warnings so that its ready for a release. I may be able to find time to do the release, but not sure yet. Niall - Original Message - From: "Rahul Akolkar" <[EMAIL PROTECTED]> Sent: Tuesday, November 22, 2005 4:50 PM On 11/22/05, Ted Husted <[EMAIL PROTECTED]> wrote: > On 11/22/05, James Mitchell <[EMAIL PROTECTED]> wrote: > > > Can we not remove these for now and bring them back in if/when Commons > > > Resource gets released? > > Let's just release Commons Resources and be done with it. There are > three tickets, one is a feature request, one is a class diagram > (documentation), and the third looks like a user support issue. > > * http://tinyurl.com/7hhuu > > None of these should block a release. > > As a member of the Jakarta PMC, can I just call for a vote, or do I > still need to be on Commons Resources list? (Or does anyone else want > to volunteer to wrap this up?) AFAICT, you're on "the list" [1]. So unless I'm mistaken about that, you should be able to just roll an RC, if there are no pending issues. Actually, this looks like something I could use elsewhere too, especially the database and XML related resources so I'd like to help -- but I neither have karma nor a binding vote, so I'll keep the noise to a minimum ;-) -Rahul [1] http://svn.apache.org/repos/asf/jakarta/commons/proper/resources/trunk/STATUS.html > > -Ted. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 11/22/05, Ted Husted <[EMAIL PROTECTED]> wrote: > On 11/22/05, James Mitchell <[EMAIL PROTECTED]> wrote: > > > Can we not remove these for now and bring them back in if/when Commons > > > Resource gets released? > > Let's just release Commons Resources and be done with it. There are > three tickets, one is a feature request, one is a class diagram > (documentation), and the third looks like a user support issue. > > * http://tinyurl.com/7hhuu > > None of these should block a release. > > As a member of the Jakarta PMC, can I just call for a vote, or do I > still need to be on Commons Resources list? (Or does anyone else want > to volunteer to wrap this up?) AFAICT, you're on "the list" [1]. So unless I'm mistaken about that, you should be able to just roll an RC, if there are no pending issues. Actually, this looks like something I could use elsewhere too, especially the database and XML related resources so I'd like to help -- but I neither have karma nor a binding vote, so I'll keep the noise to a minimum ;-) -Rahul [1] http://svn.apache.org/repos/asf/jakarta/commons/proper/resources/trunk/STATUS.html > > -Ted. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I agree, and I wish I had the time to do this, however, I'm currently scrambling to replace my primary income. I have a side project, but my main gig ended last Friday. If things turn around soon, I'll jump on it. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> To: "Struts Developers List" Sent: Tuesday, November 22, 2005 8:01 AM Subject: Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan On 11/22/05, James Mitchell <[EMAIL PROTECTED]> wrote: > Can we not remove these for now and bring them back in if/when Commons > Resource gets released? Let's just release Commons Resources and be done with it. There are three tickets, one is a feature request, one is a class diagram (documentation), and the third looks like a user support issue. * http://tinyurl.com/7hhuu None of these should block a release. As a member of the Jakarta PMC, can I just call for a vote, or do I still need to be on Commons Resources list? (Or does anyone else want to volunteer to wrap this up?) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 11/22/05, James Mitchell <[EMAIL PROTECTED]> wrote: > > Can we not remove these for now and bring them back in if/when Commons > > Resource gets released? Let's just release Commons Resources and be done with it. There are three tickets, one is a feature request, one is a class diagram (documentation), and the third looks like a user support issue. * http://tinyurl.com/7hhuu None of these should block a release. As a member of the Jakarta PMC, can I just call for a vote, or do I still need to be on Commons Resources list? (Or does anyone else want to volunteer to wrap this up?) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Can we not remove these for now and bring them back in if/when Commons Resource gets released? I agree that we should not be releasing the resources piece of Extras at this point. We simply need to exclude it as part of the build. However, I am -1 for actually doing anything to those files in svn. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx - Original Message - From: "Niall Pemberton" <[EMAIL PROTECTED]> To: "Struts Developers List" Sent: Monday, November 21, 2005 10:42 PM Subject: Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan I'm -1 at this point because of the Commons Resource dependency - I don't think we should be rolling a build with unreleased software. From what I can see there are just three classes in the extras sub-project that need this. Can we not remove these for now and bring them back in if/when Commons Resource gets released? Also the CGLib dependency is missing from the plan. From memory Hubert has outstanding objections to the DynaActionForm enhancement using CGLib - doesn't that need resolving first? Personally I don't have any interest in the CGLib enhancement although I would have preferred it in the extras project rather than core. At the moment I'm -0 on this feature because it doesn't have any JUnit tests - if tests are added I'd change that to a +0! Niall - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> Sent: Tuesday, November 22, 2005 2:18 AM There are two significant items left on the Struts Action Library 1.3.0 (aka Struts Classic) release plan before we would tag and roll it. One is renaming struts-action to struts-core, and the other are minor changes to the documentation. * http://wiki.apache.org/struts/StrutsClassicRelease130 At this time, I would ask the PMC, committers, and other interested parties to review the plan and the state of the repository. Please indicate your opinion on the plan in the usual style: +1, +0, or -1, along with any appropriate comments. Note this this is not a vote on the quality of the intended release, but on the release plan. Given a positive result, it would be our intention to roll the release on Thursday or Friday, assuming we rename the struts-core folder on Wednesday. As stated in the plan, this release is intended as a test of the new infrastructure, and other releases in the 1.3.x series are expected. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I'm -1 at this point because of the Commons Resource dependency - I don't think we should be rolling a build with unreleased software. From what I can see there are just three classes in the extras sub-project that need this. Can we not remove these for now and bring them back in if/when Commons Resource gets released? Also the CGLib dependency is missing from the plan. From memory Hubert has outstanding objections to the DynaActionForm enhancement using CGLib - doesn't that need resolving first? Personally I don't have any interest in the CGLib enhancement although I would have preferred it in the extras project rather than core. At the moment I'm -0 on this feature because it doesn't have any JUnit tests - if tests are added I'd change that to a +0! Niall - Original Message - From: "Ted Husted" <[EMAIL PROTECTED]> Sent: Tuesday, November 22, 2005 2:18 AM There are two significant items left on the Struts Action Library 1.3.0 (aka Struts Classic) release plan before we would tag and roll it. One is renaming struts-action to struts-core, and the other are minor changes to the documentation. * http://wiki.apache.org/struts/StrutsClassicRelease130 At this time, I would ask the PMC, committers, and other interested parties to review the plan and the state of the repository. Please indicate your opinion on the plan in the usual style: +1, +0, or -1, along with any appropriate comments. Note this this is not a vote on the quality of the intended release, but on the release plan. Given a positive result, it would be our intention to roll the release on Thursday or Friday, assuming we rename the struts-core folder on Wednesday. As stated in the plan, this release is intended as a test of the new infrastructure, and other releases in the 1.3.x series are expected. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Confirm the Struts Action Library 1.3.0 release plan
There are two significant items left on the Struts Action Library 1.3.0 (aka Struts Classic) release plan before we would tag and roll it. One is renaming struts-action to struts-core, and the other are minor changes to the documentation. * http://wiki.apache.org/struts/StrutsClassicRelease130 At this time, I would ask the PMC, committers, and other interested parties to review the plan and the state of the repository. Please indicate your opinion on the plan in the usual style: +1, +0, or -1, along with any appropriate comments. Note this this is not a vote on the quality of the intended release, but on the release plan. Given a positive result, it would be our intention to roll the release on Thursday or Friday, assuming we rename the struts-core folder on Wednesday. As stated in the plan, this release is intended as a test of the new infrastructure, and other releases in the 1.3.x series are expected. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
