Re: Shale vs. Struts-Chain
On Thu, 18 Nov 2004 13:48:39 +0100, Matthias Wessendorf wrote: Has Struts Shale no relationship to (Struts/Commons)-Chain? Technically, there only relationship between Struts and Shale is that they are both standards-based web application frameworks originated by Craig McClanahan :) I saw your post to the MyFaces list regarding Shale, Matthais, and it will be interesting to see how the MyFaces community responds. Given that Apache MyFaces now hosts generic JSF components, like JSF Tiles, an obvious question is whether Shale would be a better fit as a MyFaces subproject. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release planning (was Re: Shale vs. Struts-Chain)
The issue is that Validator was missed out when message bundles was implemented in Struts - I'd prefer we wait for Validator 1.1.4 and fix #18169 and #21760 and that hole will then be plugged in the 1.2.x series. If we were carrying on in the 1.2.x series, then releasing 1.2.6 and leaving them till next time would be fine by me - but since we're moving on to a 1.3 branch IMO it would be a good idea to include this in the last 1.2 release. Theres been no -ve feedback from anyone on Validator 1.1.4 so hopefully it will be voted GA in the next couple of days - can we really not delay a week for the 1.2.6 version and include this stuff? Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, June 01, 2004 11:52 PM Subject: Re: Release planning (was Re: Shale vs. Struts-Chain) If everything else is resolved, I don't think we need to wait on Validator 1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like a showstopper issue to me, and we can finish implementing the feature in the 1.3.x series. I'm trying to resolve the issues not listed as outstanding on the release plan, which should put us in a position to roll 1.2.6. I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to move on to bigger and better things. We did tag and roll 1.2.5, it just didn't go anyplace, which is going to happen now and again. -Ted. On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote: Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 I believe that we reached consensus that it would be ok to move Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked on the release of a GA 1.2.x Struts so as to minimize any need to apply patches across both branches. Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true that we are just waiting for commons-validator 1.1.4 to be marked GA? The other bugs all seem to be marked for 1.3 except one which is underspecified. Should we somehow annotate this page: http://wiki.apache.org/struts/StrutsRelease125 to indicate that there isn't going to be a 1.2.5 release? Or should we have a vote on it even though 1.2.6 is brewing? Joe - 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: Release planning (was Re: Shale vs. Struts-Chain)
Niall Pemberton wrote: to include this in the last 1.2 release. It does not have to be last 1.2, still could have 1.27 :-). (and maybeee 1.3 should be called 1.4, just in case, it is a big change). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release planning (was Re: Shale vs. Struts-Chain)
As mentioned, we can always tag and roll additional releases from the 1.2.x branch. It's just a question of how much we want to cross-commit between 1.3.x and 1.2.x. Right now, I'd say cross-committing this patch is the lesser of the two evils. When validator 1.1.4 goes GA, I'd personally commit to rolling 1.2.7, especially if we also get a patch for #23127 too. -Ted. On Sat, 20 Nov 2004 11:54:35 +, Niall Pemberton wrote: The issue is that Validator was missed out when message bundles was implemented in Struts - I'd prefer we wait for Validator 1.1.4 and fix #18169 and #21760 and that hole will then be plugged in the 1.2.x series. If we were carrying on in the 1.2.x series, then releasing 1.2.6 and leaving them till next time would be fine by me - but since we're moving on to a 1.3 branch IMO it would be a good idea to include this in the last 1.2 release. Theres been no -ve feedback from anyone on Validator 1.1.4 so hopefully it will be voted GA in the next couple of days - can we really not delay a week for the 1.2.6 version and include this stuff? Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, June 01, 2004 11:52 PM Subject: Re: Release planning (was Re: Shale vs. Struts-Chain) If everything else is resolved, I don't think we need to wait on Validator 1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like a showstopper issue to me, and we can finish implementing the feature in the 1.3.x series. I'm trying to resolve the issues not listed as outstanding on the release plan, which should put us in a position to roll 1.2.6. I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to move on to bigger and better things. We did tag and roll 1.2.5, it just didn't go anyplace, which is going to happen now and again. -Ted. On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote: Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 I believe that we reached consensus that it would be ok to move Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked on the release of a GA 1.2.x Struts so as to minimize any need to apply patches across both branches. Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true that we are just waiting for commons-validator 1.1.4 to be marked GA? The other bugs all seem to be marked for 1.3 except one which is underspecified. Should we somehow annotate this page: http://wiki.apache.org/struts/StrutsRelease125 to indicate that there isn't going to be a 1.2.5 release? Or should we have a vote on it even though 1.2.6 is brewing? Joe - 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: Release planning (was Re: Shale vs. Struts-Chain)
On Tue, 1 Jun 2004 19:52:51 -0400, Ted Husted [EMAIL PROTECTED] wrote: [snip] I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to move on to bigger and better things. +1 -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release planning (was Re: Shale vs. Struts-Chain)
On Tue, 1 Jun 2004 19:52:51 -0400, Ted Husted [EMAIL PROTECTED] wrote: If everything else is resolved, I don't think we need to wait on Validator 1.1.4. If it's ready when we are, fine. If not, #18169 does not seem like a showstopper issue to me, and we can finish implementing the feature in the 1.3.x series. I'm trying to resolve the issues not listed as outstanding on the release plan, which should put us in a position to roll 1.2.6. I have to admit I'm a bit puzzled about what's on the wiki page versus what comes up when I run my standard query against Bugzilla. There are six bugs listed on the wiki page, but there appear to be 15 open issues in Bugzilla. Here's the list of bug numbers that show up in Bugzilla but are not listed on the wiki page: 23127 - Page attribute of img and image tags doesn't use pagePattern setting 31642 - bean:include always include Session id (if any) even for external Urls (href attribute) 32014 - HttpServletRequestWrapper in struts-faces broken for servlet 2.4 32165 - FacesRequestProcessor bug when using prefix mapped Struts servlet extension mapped Faces servlet 32265 - add a warning to reset FormFile 32283 - Two slashes created by TagUtils.getActionMappingURL for webapps in root context 32294 - html:text tag is not closed properly 32309 - Nonsense error messages from html:select/ options tags. 32310 - html:select/ options tags undocumented Of these, 32014 and 32165 are struts-faces bugs, which I assume we're not worrying about for 1.2.6. Should I simply be adding the remainder to the wiki page, so that we're tracking them all there, or is there a reason that they (at least the ones created before today ;) are not already there? I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to move on to bigger and better things. +1 to branching at 1.2.6. Assuming there are no objections, I'll create a 1.2.x branch at the same time as I do the 1.2.6 label. -- Martin Cooper We did tag and roll 1.2.5, it just didn't go anyplace, which is going to happen now and again. -Ted. On Thu, 18 Nov 2004 08:21:30 -0600, Joe Germuska wrote: Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 I believe that we reached consensus that it would be ok to move Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked on the release of a GA 1.2.x Struts so as to minimize any need to apply patches across both branches. Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true that we are just waiting for commons-validator 1.1.4 to be marked GA? The other bugs all seem to be marked for 1.3 except one which is underspecified. Should we somehow annotate this page: http://wiki.apache.org/struts/StrutsRelease125 to indicate that there isn't going to be a 1.2.5 release? Or should we have a vote on it even though 1.2.6 is brewing? Joe - 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]
Shale vs. Struts-Chain
Hi all, I read the docs on subversion about Shale. Well, a very interessting point. However, I asked myself how it is related to Struts/Commons - Chain. (The Proposal aka Jericho) Has Struts Shale no relationship to (Struts/Commons)-Chain? Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 And Shale, that will be on top of Servlet2.4, will use Filter for CoR, isn't it? Last but not least, the IoC (or dependency injection) from Spring or Hivemind will be *included* into Struts / Shale? Thanks for helping to clear my picture ;-) Greetings, Matthias -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany URL: http://www.wessendorf.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release planning (was Re: Shale vs. Struts-Chain)
Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 I believe that we reached consensus that it would be ok to move Struts 1.3 to depend on Servlet 2.3. Work on Struts 1.3 is blocked on the release of a GA 1.2.x Struts so as to minimize any need to apply patches across both branches. Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true that we are just waiting for commons-validator 1.1.4 to be marked GA? The other bugs all seem to be marked for 1.3 except one which is underspecified. Should we somehow annotate this page: http://wiki.apache.org/struts/StrutsRelease125 to indicate that there isn't going to be a 1.2.5 release? Or should we have a vote on it even though 1.2.6 is brewing? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release planning (was Re: Shale vs. Struts-Chain)
Looking at http://wiki.apache.org/struts/StrutsRelease126, is it true that we are just waiting for commons-validator 1.1.4 to be marked GA? read in commons-dev that 1.1.4 is now alpha and available for Testing -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale vs. Struts-Chain
Miscellaneous comments inline. On Thu, 18 Nov 2004 13:48:39 +0100, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi all, I read the docs on subversion about Shale. Well, a very interessting point. However, I asked myself how it is related to Struts/Commons - Chain. (The Proposal aka Jericho) Has Struts Shale no relationship to (Struts/Commons)-Chain? There is no particular relationship between Shale and *Struts*-Chain, which is designed to decompose the Struts 1.x request processor into little pieces. However, there is no reason you couldn't use *Commons* Chain inside a Shale environment in several different ways: * When using a Filter as the application controller, compose all the pre-request and post-request processing to be performed into chains, so that you only need to configure a single filter in your web.xml file. * Have your action event handlers (for things like submit buttons) delegate to business logic that is expressed in a chain, rather than executing it directly. that is composed in a chain Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 That's correct. And Shale, that will be on top of Servlet2.4, will use Filter for CoR, isn't it? That is the proposal, yes -- although, as I remarked above, you can implement CoR inside a filter, in addition to the ability to use more than one Filter. It remains to be seen which model is easier to program to, and for users to configure. Last but not least, the IoC (or dependency injection) from Spring or Hivemind will be *included* into Struts / Shale? I believe that developers using a modern framework will expect an IoC solution to be included. Interestingly, the managed beans APIs in JSF provide setter injection IoC support already -- however, that may not be sufficient for everyone's needs. If the Shale core code itself was limited to just managed beans, then we could support incorporation of pretty much any IoC architecture by leveraging JSF's pluggability APIs. For example, the Spring folks have already built a JSF VariableResolver that allows the managed beans facility to instantiate Spring beans transparently. That's pretty cool. Applications, of course, could integrate directly with the IoC framework if they wanted to. Thanks for helping to clear my picture ;-) Greetings, Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shale and struts-chain
Just wondering: how does Shale relate to struts-chain? E.g. * Would Shale subsume struts-chain? * Is struts-chain for 1.x and Shale for 2.x? We're planning the next rev of tooling, so I'm wondering which (moving) target(s) to try to hit, and when ... TIA, Tom Roche, IBM Rational Developer Model2 Tooling - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale and struts-chain
On Wed, 27 Oct 2004 00:20:13 -0400, Thomas L Roche [EMAIL PROTECTED] wrote: Just wondering: how does Shale relate to struts-chain? E.g. * Would Shale subsume struts-chain? It would likely subsume *struts*-chain, but not *commons*-chain (see below). * Is struts-chain for 1.x and Shale for 2.x? Struts-chain is primarily for Struts 1.x, giving us an alternative way to compose the request processor. Shale is a proposal for an overall architecture of Struts 2.x. However, the underlying commons chain functionality makes a reasonable way to express composable chains of behavior -- and can be used at a number of different levels. And, given a well defined configuration file format, chains should be able to support a pretty nice design time experience. * In either architecture, a chain could be used to compose the application logic used to process, say, a form submit. You could compose a chain, for example, that allocated a data source, then did some business logic level validation, then performed the actual transaction. Or, it could go invoke a remote web service, or interact with a BPEL workflow. This kind of chain would be built from small reusable parts that are easily unit tested in isolation. * In Shale, there's likely to be one or more servlet filters involved in providing the functionality slated for the application controller layer. It would be easier to configure (especially if you're creating your web.xml file by hand) to have only one filter for all of Struts, and then use composition to define the steps that take place at the beginning and end of each requst innovation. * In Shale, the same thing could be architected in the implementation of pretty much any event handler where you might want to do more than one thing, allowing applications to add speciaized processing before or after the standard steps. That being said, nothing in Shale's proposed architecture *requires* the use of a chain for this type of thing. It might also be that the required functionality is composed though some IoC container, or a workflow engine, or whatever else you want to use. We're planning the next rev of tooling, so I'm wondering which (moving) target(s) to try to hit, and when ... You're not the only one trying to make that determination :-). However, it's definitely too early to make very many plans around Shale, which still has to make its case with the rest of the Struts developers before it's anything other than a brainstorm. Over the next while, I'll be filling in some of the details with prototype code that should help us make that determination. TIA, Tom Roche, IBM Rational Developer Model2 Tooling Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
