Re: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
On Wed, 24 Mar 2004 22:33:50 -0800 (PST), Martin Cooper wrote: I can probably do the RM thing for Validator if someone else (David?) can do the doc and release note updates. Just let me know when we're ready to roll and I can take it from there. How about if we shoot for the Validator this weekend and then Strus 1.2.1 next weekend. That would give us a chance to update the site for some of the new TLP changes and give Martin a chance to do his taxes :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. Another way to go would be to provide a API object in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the ConfigHelper, which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. From the perspective of a presentation technology, regardless of its nature, the ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver appears to be the database. (Adapter/proxy patterns.) On Thu, 25 Mar 2004 20:09:08 -0800 (PST), David Graham wrote: Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. I don't use them myself, but I still know people who do. And some of those people help pay the bills :) I have and will support them by applying patches that people provide, as we just did by adding the module parameter. Moving the taglibs to their own subproject (at last!) will make a significant difference, since what does or does not happen with opt-taglibs won't directly affect core. If we moved to a context-based architecture (as above), it would help decouple the taglibs from the core, so the subprojects could be more independent, and level the playing field for other technologies. And, I'd do whatever it took to refactor the classic taglibs. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. Things may change this year, but last summer I was still finding people at very large corporations who hadn't migrated to servlet 2.3. So, c:forEAch was not available to them. Hopefully that will change this year, and we'll find nearly everyone has finally found the budget to upgrade. Though, that's not going to get us off the compatibility train. The next thing will be whether they support servlet 2.4 for Struts 2.x :) Pity the world can't download Tomcat and be done it :( :) -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
On Fri, 26 Mar 2004 07:56:11 -0600, Joe Germuska wrote: I love this. I actually hadn't seen it before. We had talked briefly a few days ago about a StrutsContext as the argument to Action.execute() and Renderer.render() -- but it looks to me like this class is everything I would expect that one to be... Unless it was assumed that StrutsContext would implement o.a.c.chain.Context, which may be a good idea -- haven't thought about it that much. Where is this actually being used now? Just in the Velocity tools? I think the struts-chain stuff might be clearer if they all passed a ConfigHelper instance along instead of each needing to know the context key under which various items would be found. I'm assuming from the design of the struts-chain commands that someone may have thought there was a good reason to keep that more flexible -- perhaps for interaction with unforeseen commands -- but sometimes I think that makes it more complicated than it needs to be. Joe The ConfigHelper was never actually used by Velocity Tools, except to show where all the bodies were buried. I very much doubt that anyone is actually using it right now. Like a lot of things, it's just continuation of many things that we've done all along. We already put the ActionMapping in the request. This puts Struts in the request :) I've renewed development of this class over to Commons Chain, where work has begun on a Struts MailReader for Commons Chain example application. http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/chain/apps/mailreader/ I think in the 1.3 era, where Commons Chain is part of the core, we could in fact base an ActionContextBase on a.o.c.chain.ContextBase. There could also be a clean-room interface that exposed things like Messages and Mappings and Validators (oh my!), to a business Command, but not the http interface or contexts. -Ted. On Fri, 26 Mar 2004 07:00:57 -0500, Ted Husted wrote: On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. Another way to go would be to provide a API object in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the ConfigHelper, which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. From the perspective of a presentation technology, regardless of its nature, the ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver appears to be the database. (Adapter/proxy patterns.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StrutsContext/ConfigHelper (was Re: Making Struts Build Easier)
On Fri, 26 Mar 2004 11:32:20 -0800, Craig R. McClanahan wrote: Quoting Joe Germuska [EMAIL PROTECTED]: Wouldn't the context object used by struts-chain contain everything you might need in Velocity-land? It would be a shame to invent a second context object if we're going that direction anyway and it can meet your needs. I'm not sure that Joe's a Velocity Tools user himself. I believe he was just picking up on my reference. Right now, the Velocity Tools expose several different objects that roughly equate to the Struts taglibs. So you can expose the tool you need, in the same way you can import the taglib you need. Taken together, these tools have most of the functionality that we might find in a full-featured ActionContext. Another term for such tools would be view helpers. Nothing fancy. Just a JavaBean, really. There's a nifty loading mechanism though, so you load up whatever tools of your own that might be needed. (Say, a database access tool.) If an ActionContext were exposed in the request, it's true that something like the Velocity Tools for Struts probably wouldn't be needed. A surprising amount of functionality would also be exposed to JSLT, JSF, and any other view technology out there. (Say, Jelly for example.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote: So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;- If all the deliverables are in a single module, is there a way that we can generate a separate changelog for each one? http://maven.apache.org/reference/project-descriptor.html#repository -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004 07:45:29 -0700, Matt Raible wrote: ** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three problem tickets on the bugzilla list now? Personally, I'd like to see a 1.2 release before any CVS changes are made. I think the user community would agree. Well, did-ja have anything to add to the list, Matt? :) http://tinyurl.com/yqxyk If we can clear the outstanding problem tickets, along with any burning issues people haven't reported yet, we can roll 1.2.1. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
On Wed, 24 Mar 2004 09:03:46 -0700, Matt Raible wrote: -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Well, did-ja have anything to add to the list, Matt? :) Nope - release, release!! The ones we have are resolvable, but, I'm thinking Martin has something up his sleeve yet ... Meanwhile, there's still the issue of our dependency on the Validator nightly http://tinyurl.com/394ht and how far we are from another Validator release ... -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004 11:03:58 -0800 (PST), Martin Cooper wrote: \opt-dev (whiteboard or sandbox) So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong preference, although 'sandbox' is used by at least 4 Jakarta sub- projects. (In those, it's a separate repo, though. Do we want to do the same?) Let's go for the brevity and consistency of opt-dev. If we're keeping everything in one module, then let's keep it all on one module :) \opt-taglib I still like the idea of pushing this down under a generic presentation directory, or at least under a JSP directory, so that we can move JSP specific stuff out of core and into this. I would strongly prefer that we should tie the TLDs to specific deliverables and avoid taxonomies, The JSP specific stuff should live with the taglibs or be refactored so that it's not JSP-specific :) Obviously, I'm good with alternate presentation technologies, but they should be available as their own deliverables, and rooted in their own TLDs. \opt-el Hmm. This is also a taglib... But with different platform requirements. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
On Wed, 24 Mar 2004 11:03:58 -0800 (PST), Martin Cooper wrote: Actually, contrary to your comment in the Counting down thread, I don't have anything up my sleeve (unless I forgot something myself). ;-) It would be nice to resolve the issue with the Cactus tests not stopping properly on Tomcat 5.0, but I can live without that if necessary. Well, if we get the problem tickets down to zero, and I update the release notes again, would we be up for rolling 1.2.1 this weekend? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
On Wed, 24 Mar 2004 12:11:01 -0800 (PST), Martin Cooper wrote: Do we want to wait for a Validator 1.1.2, or roll it with 1.1.1? Well, we can't roll it with 1.1.1, since the report says the client validations won't work without the nightly build. It would be cool if we could roll Validator 1.1.2, and then roll Strut 1.2.1, and see if they both make the grade. We mostly expected 1.2.0 to wash-out, but 1.2.1 might actually be OK. Meanwhile, we could branch 1.2.x and bring the Struts-Chain RP down from contrib. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004 20:35:41 +, Peter A. Pilgrim wrote: Are keeping the basic `src' and `web' main sub directory under each top level directory? I'd prefer we followed the Maven project layout recommendations for each deliverable. This will be the easiest for everyone to grok in the longrun. http://maven.apache.org/reference/dirlayout.html So, under each top-level directory, we would find a layout like /src - java - test - webapp /xdocs /target (generated) - *.jar - distributions - docs - site - ... May be it is worth putting `opt-legacy' and `opt-el' under a `view' directory especially if they are all to do rendering the web user interface You might have meant opt-taglib and opt-el. Legacy is the old datasource implementation. I'd strongly prefer keeping a close relationship between top-level-directories and deliverables, and that we avoid taxonomies. Joe suggested combining opt-el with opt-taglibs, though we'd have to be careful which dependencies are used to build what. (Which makes me think they are not the same deliverable. el might just have a dependency on taglib.) I don't actually use either one much myself, so I have no preferences myself. The example applications tree might be a tad different. Here I'd favor a master apps directory, with a directory for each application beneath that. This makes it easy for the apps to extend a common Maven project.xml. We could still offer a single zip/tarball with all the applications WARs within. /apps - examples - mailreader - tilesPortal - userdb Now that I say it, the same approach might conceivably be used for el, taglibs, and faces. /taglibs - classic - el - faces But, the problem with binding the taglib packages too closely is that they would all have to be distribution-ready before we did a new roll of any. So, an ongoing refactoring in the classic taglibs could block a quick release of the faces taglib. I really want to try and avoid the hydraulic dependencies of the 1.1 era, where we had to have everything ready to release all at once :( -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 10:07:55 +, Peter A. Pilgrim wrote: In my experienc multiple CVS repositories can make a project much harder to manage. But are we singing from the same hymn sheet? Is a multiple repository equal ( or not equal) to a CVS module? We mean multiple CVS modules. The original idea being each module would generate a jar. Product==JAR==Module==unit-of-release. One list of potential products -- each with its own JAR, module, and release cycle -- would be: * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces aka the seven dwarfs :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 23:49:31 -0800 (PST), Martin Cooper wrote: On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? Well, as you mentioned, another way to go would be for some one to write a tool that could burst and rejar an arbitrary set of jars. (If one doesn't already exist.) The source for such a tool could live in the core since it's just something a volunteer would run offline and the upload. It wouldn't be a true deliverable. And, I'm not convinced that we even need to do such a thing. Even without a few extra JARs of our own, there are still all the Commons JARs. (Though I suppose we could roll together those too.) I'd tend to leave this for a end-user to do, say if there were distributing a particular Struts distribution to several teams in an enterprise. But it would be nice to provide a tool for this (if someone had the itch to write it.) It really sounds like a job for Sun :) On Mon, 22 Mar 2004 20:50:24 -0800 (PST), Martin Cooper wrote: I'd be open to it, but I think we have a lot of things we'd want to do to get our own house in order before we actually take action on this. I also think it might be a tricky issue in some respects. For example, we'll be faced with making subjective decisions on potentially substantial bodies of code, leading to the possibility of why not mine? kinds of things. For larger code bases, we'd also likely need to have some discussions with the incubator folks. But, as you say, let's get our own house in order first, and then come back and talk about this some more. And in deciding how to renovate our house, let's keep in mind that we may be having more children :) How about if we split the difference: core module: /core /site /apps opt-modules: * opt-taglib * opt-el * opt-faces * opt-dev (sandbox) So, we'd go from seven to five. Then, later on, if we invite some of our friends to join us, and they move in, we just add more opt modules. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
On Tue, 23 Mar 2004 02:49:44 +, Peter A. Pilgrim wrote: Would the same principle work with people who have taken Struts and integrated or embedded as another framework? Having spent some type integrating 1.1 into Expresso Framework in 2002, in our case can we be classified as Struts extenders? Also some repository will not want to become a sub project of Struts because of logical sense, politics or legal entity status? Something like Expresso is large enough to be a framework in its own right. If the Expresso Community ever wanted to apply to Apache for incubation as an ASF project, I'd certainly support the idea. Or, if there were a coherent subset of Expresso that could be used by Struts developers as an extension, independently of Expresso, that might be something that could live as a Struts opt-* modules. Personally, I'd love to see a proposal from Expresso of some helpful code that they would like to grant to the ASF -- especially if it gave us an excuse to nominate you as a committer, Peter. :) Of course, it is very true that not every open source project is suited for Apache. There is a specific Apache culture and management style that doesn't work for everyone. We would never simply annex a codebase and then redistribute it under the ASL. We consider the community behind a codebase to be more important than the code itself. It's the extension's community that we would pursue, more than the code itself. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc bylaws.xml
husted 2004/03/23 03:49:34 Added: doc bylaws.xml Log: Initial draft of bylaws page. Not linked in. Other pages to follow, as discussed. Revision ChangesPath 1.1 jakarta-struts/doc/bylaws.xml Index: bylaws.xml === ?xml version=1.0? document url=./bylaws.xml properties titleProject Management Committee Bylaws/title /properties body section name=Project Management Committee Bylaws p Struts is a Project of the a href=http://apache.org/foundation; Apache Software Foundation/a (ASF), formed by a resolution of the a href=http://apache.org/foundation/board/;ASF Board of Directors/a. As an ASF Project, Struts is subject to the a href=http://apache.org/foundation/bylaws.html;ASF Bylaws/a and the direction of the ASF Board. /p p The Project is administered by the Vice President of Struts. The Vice President is appointed by the ASF Board. The Vice President is assisted by the Project Management Committee (PMC) and also serves as the PMC chair. The PMC may nominate new members. Nominees may then be approved with a 3/4 majority vote of the PMC. Membership can be revoked by a unanimous vote of all the active PMC members other than the member in question. The list of active PMC members can be found on our a href=volunteers.htmlVolunteers page/a. /p p bDuties/bbr /The PMC is responsible for the day-to-day management of the Struts Project. The PMC oversees all changes made to the codebase. The PMC must ensure that all code under a Apache Struts CVS is the lawful property of the Foundation and that it may be distributed under the a href=http://apache.org/licenses/; Apache Software License/a. All releases of a Struts subproject must be sanctioned by the Project Management Committee. /p p bSubprojects/bbr / Subprojects are the Project's unit of release. Each subproject should represent an implementation of the Struts core or a releated component. Each subproject should focus on creating, maintaining, and releasing a single softare product or deliverable. /p p All PMC Members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote. All Committers have write access to all subprojects. Subprojects are units of release, not units of work. /p p bCreation of subprojects/bbr / PMC members may propose the creation of new subprojects. Proposals are to contain the scope of the project, identify the initial source from which the project is to be populated, identify the mailing list(s) if any which are to be created, and identify the initial set of committers. Creation of a new subproject requires approval by a 3/4 majority vote of the PMC. /p /section /body /document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
On Tue, 23 Mar 2004 06:31:51 -0500, Ted Husted wrote: Something like Expresso is large enough to be a framework s/framework/Apache project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote: 1) I think you should keep the same elementary structure Moving forward, we have already decided to use Maven as our build environment, which addresses a number of consistency and structural issues. We had also decided to distribute non-core components, like the taglibs, independantly. Independant releases lead to the idea of independant modules. Modules also seem like a good way to handle bringing on some of the more popular extensions. So, the site subproject would be an overview of the Struts project, and then link to the subprojects (including core) for more detail. A contributor mentioned wanting a single JAR. I don't think that's an itch any of Committers are desparate to scratch. And, if anyone did, it's been pointed out that Ant can be used to burst and combine JARs. Anyone could do that. I don't think anyone wants to build a single Struts WAR, especially since we already have multiple example applications in their own WARs. At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Separate Tiles From Struts?
At first, there was talk of bringing it to Taglibs. Cedric and David Geary chatted about that for a bit, but the conversation trailed off, and we just plunged ahead with 1.1. It could certainly be abstracted and brought to the Commons, like the Validator, if someone had the itch. :) Are you volunteering? -Ted. On Tue, 23 Mar 2004 16:02:28 -0700, Matt Raible wrote: Anyone care to educate me on why Tiles is part of Struts (and not commons-tiles?). I'd like to respond to the following post (contents pasted below) with an educated reply. https://sourceforge.net/forum/message.php?msg_id=2488961 snip On the occasion: Do you happen to know why Tiles was integrated into the Struts codebase as of Struts 1.1, rather than kept as separate component with Struts integration? I've been wondering about this for quite a while... Tiles isn't really tied to Struts in a technical manner, as we see in our usage with Spring. So why is every other piece of reusable logic a Commons component but not Tiles? I'd really like to see Tiles being factored out of the Struts codebase again, possibly before the Struts 2.0 timeframe. /snip Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coming out for JSF + Struts, was: Struts JSR?
On Mon, 22 Mar 2004 08:00:00 -0500, Thomas L Roche wrote: Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 But I think either of us would rather be developing Struts than evangelizing Struts. This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. Frankly, I'm perplexed why the propagation of the latter has gone unchecked for so long. The absolute truth is that nobody knows. In practice, we might find that these perceptions are true. Or we may find that these perceptions are false. Or, more likely, we will find that they are sometimes true and sometimes false. David G doesn't know what will actually happen, neither do I, nor you, or even Craig. So, this would just be Craig's best guess against David's best guess. May the best guesser win :) My point is that this type of prognostication doesn't help Struts in any way that matters. What helps is people rolling up their sleeves and doing the work. Given the vast numbers of developers using Struts, I'm constantly astonished at how hard it is to find more people willing and able to do the work. (Except on the user list, where I'm constantly astonished at the willingness of users to help other users.) Sometimes I think market-share actually hurts a project like Struts, since everybody thinks somebody else is going to do it :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 09:53:02 -0800, Craig R. McClanahan wrote: Yep ... that's why we need to finish the how many repositories discussion so we can start migrating towards something that is simpler. I continue to think that the easiest thing in the long run will be a module for each product. Where a product is equivalent to a Maven artifact or a deliverable with its own release cycle. So, if infrastructure doesn't care, and we can centralize the permissions, I'd like to go back to something like * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide release-notes.xml
husted 2004/03/22 17:02:30 Modified:doc/userGuide release-notes.xml Log: Update release notes. Revision ChangesPath 1.50 +28 -2 jakarta-struts/doc/userGuide/release-notes.xml Index: release-notes.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes.xml,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- release-notes.xml 20 Feb 2004 16:35:17 - 1.49 +++ release-notes.xml 23 Mar 2004 01:02:30 - 1.50 @@ -152,7 +152,10 @@ strongGeneral Changes/strong /p ul - liAdd inital STATUS LOG, as of 30-Dec-2003./li + li2003-03-14 - Move license on all source code files to ASL 2.0./li +/ul +ul + li2003-12-30 - Add inital STATUS LOG./li /ul p strongBuild Changes/strong @@ -188,6 +191,9 @@ strongAction Package Changes/strong [ codeorg.apache.struts.action/code]/p ul + li2004-03-16 - ActionForward - Add copy constructor./li +/ul +ul li2004-01-24 - Enhance DynaActionForm so that it can be initialized using a FormBeanConfig object. Add corresponding method to RequestUtils to create an ActionForm by passing only a FormBeanConfig and an ActionServlet object./li li2004-01-19 - Push findException from ActionMapping up to ActionConfig so that everyone can take advantage of the superclass search logic./li /ul @@ -254,10 +260,14 @@ strongContrib Packages/strong [ code/contrib/code]/p ul +li2004-02-29 - struts-chain: Fix problem with large uploads being deleted if validation failed./li +/ul +ul li2004-01-15 - struts-chain: Add Tiles support. Add null check for type, to support forward actions; also add commons loggging/li li2004-01-14 - struts-chain: Add support for 'unknown' actions./li /ul ul + li2004-03-08 - Struts-Faces updated for JSF 1.0 final release./li li2003-12-31 - struts-faces: Initial support for Tiles; partial Tilesization of example app; *not* ready for prime time but comments definately welcome./li li2003-12-29 - struts-faces: Various updates regarding the JSF Final Draft and to prepare for Tiles support./li li2003-12-17 - struts-jericho: Whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x./li @@ -284,6 +294,9 @@ strongTaglib Package Changes/strong [ codeorg.apache.struts.taglib/code]/p ul +li2004-02-24 - Move test for null validator form inside createDynamicJavascript so that those who use the tag to generate static javascript don't get a JspException./li +/ul +ul li2003-09-09 - TagUtils: Log error message when keys or bundles are missing./li /ul ul @@ -313,6 +326,9 @@ strongHTML Taglib Package Changes/strong [ codeorg.apache.struts.taglib.html/code]:/p ul +li2003-03-08 - JavascriptValidatorTag - Allow multiple forms to be on the same page by generating a unique variable name based on form name. /li +/ul +ul li2004-02-14 - Substitute - for / in JavaScript function name when form is subclass of ValidatorActionForm./li li2004-02-07 - Add module attribute to IncludeTag, ImgTag, LinkTag, and RewriteTag, as well as to Forward. This permits a module to be referenced by name (or prefix) for direct cross-linking between modules./li @@ -326,7 +342,7 @@ li2004-01-01 - In link-related tags, allow LocalCharacterEncoding to be specified conditionally./li /ul ul - li2003-11-28 JavascriptValidatorTag - Removed getNextVar() and replaceChar() methods and use a simpler javascript identifier naming scheme. All variables with be named a0, a1, etc. to prevent using reserved words as variable names./li + li2003-11-28 - JavascriptValidatorTag - Removed getNextVar() and replaceChar() methods and use a simpler javascript identifier naming scheme. All variables with be named a0, a1, etc. to prevent using reserved words as variable names./li /ul ul li2003-08-19 - Remove request scope references from messages tag. The messages are searched for in all scopes./li @@ -353,6 +369,9 @@ strongNested Taglib Package Changes/strong [ codeorg.apache.struts.taglib.nested/code]:/p ul +li2004-03-22 - Add missing filter attribute to nested:options and nested:optionsCollection./li +/ul +ul li2004-01-01 - Correct operation of NestedMessage* tags
Re: Please correct me if I m wrong
On Mon, 22 Mar 2004 12:30:11 -0600, Bhardwaj, Sharod wrote: Execution of tag : name - Used to get value of the checkbox once the form is submitted. property - used to map the status, i.e. whether the checkbox shd be Yes or No, to the bean property. value - value of the checkbox. if I m right then is it necessary to specify the name and property with the literals ? Please explain as this is eating my head out. Please don't refer me to Jakarta site as I couldn't figure out anything from there. The place to ask questions like this is the USER list. The thing with checkboxes is that the browsers do not submit them if they are not checked. If the checkbox input is there, it was checked. If the checkbox is not in the request, then it is not present. Typically people will represent checkboxes with a boolean that defaults to false. So if they are checked, then they are set to true. But do not post any follow questions here. Post to the USER list instead. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to everyone, then we end up hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things first!) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Struts JSR?
I think all of these things are already on the Struts Jericho list. The exception being workflow integration. The Struts Workflow is OK, but I personally don't like to use multiple action paths for workflows. Of course, the really cool thing about the Struts Chain is that it makes it very easy to integrate packages like this into Struts. Struts becomes less of a framework and more a framework for writing frameworks. The other minor exception would be Chained actions . I doubt that any of us will ever recommend forwarding from one action to another to form a chain of responsibility. But, again, that's something that the Commons Chain can do much better than conventional Struts Actions ever could. Here's my question to you: If you were a member of a development team, and someone handed you a list like this, what would you do first? And, having answered the question, go ahead and do it, and post it here. The thing about open source is this: You don't have to wish -- *you* can make it so. -Ted. On Sun, 21 Mar 2004 00:22:25 -0800, Nadeem Bitar wrote: Such as? What kinds of innovations are you looking for, and specifically what kinds of things are you seeing other frameworks use that Struts could benefit from? I posted this before but here is my struts 2.0 wish list again: * Leverage JSF and JSTL remove struts tags that have similar functionality. * Support for IoC. * Cleaner interfaces. * Workflow integration. * Chained actions * Support for portlet(JSR-168) nadeem bitar - 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: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We were already getting ready to change things around. And we *do* need to move things around if we are ever going to get away from a monolithic Struts to a modular Struts, were people can assemble the Struts platform they need for their application. If not now, then when? The resolution we submitted says we're suppose to rationalize Struts, so let's rationalize :) My preference would be to have a separate repository for each subproject. Each subproject represents a coherent software product or deliverable with its own release cycle. Another way of thinking of the subprojects/products is as Maven artifacts. As mentioned elsewhere, all Struts Committers can have access to all repositories, and all PMC Members have voting rights over all subprojects. I'd suggest that we setup a legacy jakarta repository that would be frozen. Directories could then be moved over to their new repositories, either from a second copy of the original repository or from a remote copy. The subprojects/repositories/artifacts/products I had in mind were: * core * taglib * app * opt-legacy * opt-el (or jstl) * opt-faces * opt-sandbox Here's some possible path-to-repository mappings. Later entries assume earlier entries were already moved. [taglib] /src/share/o.a.s/taglib - /src/o.a.s/taglib [app] /src/example,examples,tiles-docmentation - /src/ /web/ - /webapp/ [opt-el] /src/contrib/struts-el - / [opt-legacy] /src/contrib/struts-legacy - / [opt-faces] /src/contrib/struts-faces - / [opt-sandbox] /src/contrib/ - / [core] /src/share - core repository /src / - / Something like Struts 2.0 development might start out in the opt-sandbox and then move its own repository (like core2) once we had consensus. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide struts-nested.xml
husted 2004/03/21 16:37:05 Modified:doc/userGuide struts-nested.xml Log: Apply #27662 Add filter attribute to nested:options and nested:optionsCollection submitted by Firepica and John Cavacas. Revision ChangesPath 1.26 +12 -0 jakarta-struts/doc/userGuide/struts-nested.xml Index: struts-nested.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-nested.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- struts-nested.xml 16 Jan 2004 04:12:06 - 1.25 +++ struts-nested.xml 22 Mar 2004 00:37:05 - 1.26 @@ -1993,6 +1993,12 @@ /attribute attribute + namefilter/name + requiredfalse/required + rtexprvaluetrue/rtexprvalue +/attribute + + attribute namelabelName/name requiredfalse/required rtexprvaluetrue/rtexprvalue @@ -2045,6 +2051,12 @@ and usage details. /p /info + +attribute + namefilter/name + requiredfalse/required + rtexprvaluetrue/rtexprvalue +/attribute attribute namelabel/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/upload CommonsMultipartRequestHandler.java
husted 2004/03/21 16:41:34
Modified:src/share/org/apache/struts/upload
CommonsMultipartRequestHandler.java
Log:
Apply #27702 MultipartPost values cannot contain latin1 characters when server is
running on linux reported by Raimo Ihle.
Revision ChangesPath
1.16 +9 -5
jakarta-struts/src/share/org/apache/struts/upload/CommonsMultipartRequestHandler.java
Index: CommonsMultipartRequestHandler.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/upload/CommonsMultipartRequestHandler.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- CommonsMultipartRequestHandler.java 14 Mar 2004 06:23:48 - 1.15
+++ CommonsMultipartRequestHandler.java 22 Mar 2004 00:41:34 - 1.16
@@ -409,7 +409,11 @@
try {
value = item.getString(request.getCharacterEncoding());
} catch (Exception e) {
-value = item.getString();
+try {
+ value = item.getString(ISO-8859-1);
+} catch (java.io.UnsupportedEncodingException uee) {
+ value = item.getString();
+}
}
if (request instanceof MultipartRequestWrapper) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 12:05:44 -0800, Nathan Bubna wrote:
Martin Cooper said:
..
Another thought on this. When we get to Struts 2, I'd like to see
us remove all of the JSP-ness of Struts from the core, and also
add some degree of support for other presentation technologies,
such as XSLT and Velocity. So, instead of having 'taglib' where
it is in the above tree, we might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
interesting. i've wondered before if the VelocityStruts code (but
not all of Velocity Tools, of course) might be better off in Struts
land. something to keep in mind i suppose.
At this point, I'd be in favor of that. :)
I originally encouraged setting up VelocityStruts under Velocity, since the had a
broader base than Struts. (And projects like Maverick proved that to be so.)
Developing the Struts Toolset under Apache Struts might be a good idea now, especially
as we move into a 2.0 timeframe. I think exposure to the Velocity notion of Tools
would be a good thing for Struts developers.
Personally, I think it would be great if Velocity went TLP and brought N-Velocity in
under Apache. Especially now that HTTPD is moving toward adding .NET support.
But, that's just me.
Incidentally, where would Tiles land in all of this? In theory,
it's not tied to JSP, but rather to Servlets, so it might be
applicable to some other presentation technologies, but clearly
not all.
Tiles works great for us, and we are able to use it in such a way
that we can mix and match JSP and Velocity tiles. i definitely
think Tiles can and should avoid dependence on any particular
presentation technology.
Agreed. It might be a good idea of thinking of Tiles as a subproject, especially since
people may want to use it with JSF.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 10:55:00 -0800 (PST), Martin Cooper wrote: I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. This would be fine with me. Checkout granularity cuts both ways. If you are actually working in all aspects of a project, then it's more checkouts. If you are not, then you spend more time checking out code that you don't care about. (Commons is getting to be a chore these days.) My experience with multi-project Maven builds is that its not difficult so long as the JARs are placed in a local repository where other Maven builds can find them. But either way works, it's all good. My suggestions were colored by experience in environments like SourceForge where these sort of things are automated and easy to do. But, if a minimum number of repositories will make it easier for infrastructure, then, absolutely, I'm all for that. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004 11:50:27 -0800 (PST), Martin Cooper wrote: Incidentally, where would Tiles land in all of this? In theory, it's not tied to JSP, but rather to Servlets, so it might be applicable to some other presentation technologies, but clearly not all. Yes, it might be a good idea to bring Tiles and Validator up as top-level directories. We might want to think about ways that other frameworks, like JSF, could use these without have to buy into the whole 900lb Struts gorilla. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coming out for JSF + Struts, was: Struts JSR?
On Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM) wrote: summary: McClanahan should clearly state *in some major publication* IMHO, either people like us will be able use JSF without Struts, or we won't. If we can, great. Less is more. If we can't, we'll create whatever components we need to make it so. Darwin will decide. As long as any of us need Struts, we'll keep developing Struts. Period. What other people say doesn't matter. If that want to use what we use, great. If not, also great. It will still work the same for us either way. :) And, of course, Struts isn't just about JSP tags. A lot of people use Struts with Velocity and XLST templates. JSF support for these technologies is a ways off yet. My real feeling is that struts-dev doesn't need to get swept up in the discussions of what-might-be. Market share isn't important. What is important is that we develop what we need to use today so that we can be using it tomorrow. Not the figurative tomorrow, but the literal one :) If anyone is *really* interested in showing what a significant Struts+JSF application looks like, then someone should roll up their own sleeves and just do it. I'd recommend the JPetstore as a likely starting point :) http://www.ibatis.com/jpetstore/jpetstore.html Craig's often said that he'd rather be coding than writing about code. Me, I'm happy doing either :) -- But I think either of us would rather be developing Struts than evangelizing Struts. The proof of the pudding is in the taste. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts infrastructure changes
I'm good with any of this, or with any product changes others want, or do not want, to make. :) On Sat, 20 Mar 2004 09:05:02 -0800 (PST), Martin Cooper wrote: The following is a set of proposed changes to the Apache infrastructure to accommodate the Struts move to an Apache top level project. The idea is to come up with a single agreed-upon set of changes that we can submit to the infrastructure folks as a single request, rather than submitting each one piecemeal. Your feedback is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bean:define
On Sat, 20 Mar 2004 14:23:26 -0600, Bhardwaj, Sharod wrote: can anybody tell me what is the use of bean:define tag..its really bugging me up http://jakarta.apache.org/struts/api/org/apache/struts/taglib/bean/package-summary.html#doc.Creation sums it up. If you need further assistance, please post to the Struts USER list. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Struts JSR?
On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote: If for example JSF 2.0 is available, and Spring Framework is well integrated with JSF before Struts 2.0 is available, I strongly believe that struts won't have a place and would lose market shares. First let's be very clear. It's *not* about market share. Struts does not need market-share to survive. All we need is a community of developers who use the product and want to help support it. How many downloads we realize isn't important. Whether 90% or whether 10% of shipping applications use Struts isn't important. What's important is that Struts works well for the people who do want to use it, and that those people want to do the work to make it better. Of course, if we all find that JSF does most of what we all need, and we want to use it in our own applications, then Struts will quickly become whatever other JSF components we need to ship our own applications. But so long as products like JSF leave out components that real-life applications need, there will always be a Struts. From the beginning, it's always been about providing axles between the wheels that Java already has. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bylaws (was Re: [ANNOUNCE] Struts goes TLP with unanimous vote...)
On Sat, 20 Mar 2004 14:27:34 -0800 (PST), Martin Cooper wrote: This looks pretty good, Ted. Just a couple of things: * If we're going to introduce the idea of Struts sub-projects right up front, then I would prefer to consider these as purely organisational, at least initially. That is, I'm open to breaking up the code base / docs / etc. into multiple sub-projects, but I would prefer that all people related matters span the Struts project. Specifically, I wouldn't want to allow for sub-project X committers as distinct from Struts committers. (Basically, I want to be quite clear that this is not an umbrella project in any shape or form. ;) Yes, All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote. So, this is not Jakarta, nor the Commons, but more like the fabled Agora. :) There should only be one list of committers, with equal access to all Struts repositories. And I would say that there should be a single DEV list, for the same reasons. As you say, the subprojects would be organisation units of release. Nothing more. No subcommittees, no subcommitters. We could also think about the term product rather than subproject. Subproject just seemed to flow better. * In the Roles page, I'd prefer that the CLA submission be called out in the text, and not just left to the sample letter, as it is now. There has been confusion on this in Jakarta, so let's make it as clear as possible for Struts. ;-) Sure. * Should the release process (i.e. the Tomcat-like process we recently adopted) be part of the bylaws, or is that not necessary? That came to mind as I was reading the Release Testing section, since they're somewhat related. We already have that in our release guidelines, which would remain. We'd probably have to resolve some overlap, as you point out. By the way, Stefan Bodewig put together a very nice wiki page to serve as a resource as the Gump team puts their own bylaws together: http://wiki.apache.org/gump/Drafts/ProjectBylaws It might be worth perusing for additional ideas. (I'm planning on doing some perusing of it myself when I have some time.) -- Martin Cooper On Thu, 18 Mar 2004, Ted Husted wrote: On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote: I'll be putting together a list, shortly, of what needs to happen next for us to fully graduate. Stay tuned... One thing the resolution mentions is that we are to draw up a set of bylaws. Heretofore, we've been operating under the Jakarta Guidelines, to good effect, IMHO. I recently created a proposed patch the guidelines to reflect that the PMC members are the decisions makers, and that Committers are essentially Contributors with write privileges. http://www.apache.org/~husted/jakarta-site2/site2-patch.txt copies of the affected pages as HTML: http://www.apache.org/~husted/jakarta-site2/guidelines.html http://www.apache.org/~husted/jakarta-site2/roles.html http://www.apache.org/~husted/jakarta-site2/communication.html http://www.apache.org/~husted/jakarta-site2/decisions.html http://www.apache.org/~husted/jakarta-site2/management.html Of course, the Bylaws or management page would have to be revised to reflect our project. I would propose an extension to the Subproject section that says something like: Subprojects are the project's unit of release. Each subproject should represent an implementation of the Struts core or a related component. Each subproject should focus on creating, maintaining, and releasing a single software product or deliverable. All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote. The intent being that as we rationalize Struts, we can move things like the taglibs and some of the contrib packages into their own subprojects, with their own release cycles. When a subproject is created, we could decide whether a subproject needs its own mailing list or not. I have no opinion as to USER lists, but would lean toward keeping a single DEV list, for the sake of cross-pollination. In any event, mailing list allocation is not part of the proposed, initial bylaws. If this sounds all right, I'll merge this with our existing documentation. Of course, we can always change any of this later. But at least we will have fulfilled that portion of the resolution. -Ted. -- --- To unsubscribe, e-mail: struts-dev- [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
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Fri, 19 Mar 2004 19:32:40 -0800 (PST), Martin Cooper wrote: If people want to start on 1.3.x, then I'd suggest we all pitch in and try to get 1.2.1 in shape for release ASAP. Works for me. There are a couple of tickets with patches that I can try tonight. If there's anything else on your list not represented by a problem ticket, please post one so that we know what's left to do. Then, when the problem count hits zero again, we can roll 1.2.1, and call it a branch :) Meanwhile, I would have no problem with calling for a VOTE on Commons Dev tonight to promote Commons Chain from the sandbox and roll the 1.0 release. I used it to good effect in an application based on Maverick, and it's certainly proved its worth in the Struts-Chain development. As mentioned elsewhere, I'm now taking a crack at a Commons-Chain-based MailReader. -Ted. On Fri, 19 Mar 2004, Joe Germuska wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? I'm all for creating a 1.2.x branch so that work can begin on 1.3.x on HEAD, but I'm firmly against creating that branch on HEAD right now. I see little justification for creating a branch at a random point in the development cycle. IMNSHO, branches should only be created from a release point, especially given our newly adopted Tomcat- style release model, which means that the time between releases should be short. A bunch of stuff has changed since 1.2.0, so it clearly doesn't make sense to create a branch from there. A few more things need to happen before we're ready for 1.2.1, but not too many, IMO, so I believe we should create the 1.3.x branch at the point at which we release 1.2.1. If people want to start on 1.3.x, then I'd suggest we all pitch in and try to get 1.2.1 in shape for release ASAP. [Note: Technically, we should vote on how to categorise 1.2.0. However, I have not send out a vote request, since it seems fairly obvious to me that there was breakage enough to classify it as a test build and no more. If anyone else feels otherwise, please speak up! ;)] Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are a number of things that will need to be taken care of as part of the move to TLP, but I don't think they should impact this too much. The CVS repo move, as Ted suggests, is really a rename. Any reorganisation of the code base we want to do is independent of that. I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. Indeed. ;-) I'm looking forward to seeing Chain move forward too, but I have a big fat serious caveat before we do anything at all here to bring it into the mainstream. Commons Chain is still in the sandbox. I feel very strongly that we should not be relying on sandbox components in the mainstream of Struts. We've been through the pain of that several times before, and I don't want to have to deal with it again. So before we bring Struts Chain into the mainstream, Chain needs to be promoted out of the sandbox and into Commons Proper, preferably in good enough shape that it's not too far from being released. (Of course, the latter condition will affect a vote to promote it in the first place!) -- Martin Cooper 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: [PROPOSAL] Struts infrastructure changes
On Sat, 20 Mar 2004 15:59:15 -0800 (PST), Martin Cooper wrote: Do we want our own announcements@ list? In the past, we've sent release announcements to the Jakarta announcements list, so I'm wondering if we want one of our own now, for people who don't want to subscribe to the Struts -user or -dev lists. Absolutely! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Splitting struts-config into multiple jar and read them as resource stream
On Fri, 19 Mar 2004 14:04:26 -0300, Diego Fernandez wrote: Hi, Since my last mail to the list (a mail about Struts config design), I have started to do some changes in the ActionServlet to support other configuration methods. I don't have too much time, but if I could do something useful, I would like to submit some patches. What is the correct way to submit patches? You can create a ticket in bugzilla, and then go back and attach a DIFF. http://jakarta.apache.org/struts/using.html#Patches This is also quite good: http://www.netbeans.org/community/contribute/patches.html -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
I don't think there will be much actual moving involved. It's all the same machine. I believe it's just a matter of someone with sysadmin karma renaming things. If you check the Ant CVS, you'll see they have everything since the dawn of time. http://cvs.apache.org/viewcvs.cgi/ant/ There are questions about what the best way to reorganize (or rationalize) our now-rambling Struts project into several subprojects. But, I think we were going to do that regardless. And no one is going to want to sacrifice the CVS logs :) I do think we should start a 1.2 branch, in any event, and perhaps think about rolling 1.2.1 as soon as the name change is complete. And then use the HEAD for 1.3 development, including Struts Chain. I'm actually about to start work on a version of the MailReader that uses Commons Chain as a business facade. So, everything would goes through a CommandAction, which in turn calls a Command from the Catalog to do the deed. (Anyone else tried that yet?) -Ted. On Fri, 19 Mar 2004 15:02:49 -0600, Joe Germuska wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote: I'll be putting together a list, shortly, of what needs to happen next for us to fully graduate. Stay tuned... One thing the resolution mentions is that we are to draw up a set of bylaws. Heretofore, we've been operating under the Jakarta Guidelines, to good effect, IMHO. I recently created a proposed patch the guidelines to reflect that the PMC members are the decisions makers, and that Committers are essentially Contributors with write privileges. http://www.apache.org/~husted/jakarta-site2/site2-patch.txt copies of the affected pages as HTML: http://www.apache.org/~husted/jakarta-site2/guidelines.html http://www.apache.org/~husted/jakarta-site2/roles.html http://www.apache.org/~husted/jakarta-site2/communication.html http://www.apache.org/~husted/jakarta-site2/decisions.html http://www.apache.org/~husted/jakarta-site2/management.html Of course, the Bylaws or management page would have to be revised to reflect our project. I would propose an extension to the Subproject section that says something like: Subprojects are the project's unit of release. Each subproject should represent an implementation of the Struts core or a related component. Each subproject should focus on creating, maintaining, and releasing a single software product or deliverable. All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote. The intent being that as we rationalize Struts, we can move things like the taglibs and some of the contrib packages into their own subprojects, with their own release cycles. When a subproject is created, we could decide whether a subproject needs its own mailing list or not. I have no opinion as to USER lists, but would lean toward keeping a single DEV list, for the sake of cross-pollination. In any event, mailing list allocation is not part of the proposed, initial bylaws. If this sounds all right, I'll merge this with our existing documentation. Of course, we can always change any of this later. But at least we will have fulfilled that portion of the resolution. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
On Thu, 18 Mar 2004 08:01:35 -0600, Joe Germuska wrote: Actually, now that I read the generated HTML, I can see how this isn't actually a conflict -- the roles.xml blurb isn't actually saying that committers get to cast binding votes... I'm not coming up with better verbiage, but one clarification would be to add some text later in the document under the PMC section specifically mentioning voting. Not a huge deal really, but clarity is a good thing. Agreed. The point is that only the PMC Members have binding votes, and we should be sure the posted text relects that. I think in our case, like HTTPD, any active Committers will end up as PMC Members anyway. But, given our experience, I think the now-conventional two-step process will help reduce the number of inactive PMC Members. It's not been uncommon for a new Struts Committer to fall away after a few months. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts STATUS.txt
husted 2004/03/16 07:52:41 Modified:.STATUS.txt Log: + Routine update Revision ChangesPath 1.2 +25 -22jakarta-struts/STATUS.txt Index: STATUS.txt === RCS file: /home/cvs/jakarta-struts/STATUS.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- STATUS.txt8 Jan 2004 16:55:56 - 1.1 +++ STATUS.txt16 Mar 2004 15:52:41 - 1.2 @@ -1,4 +1,4 @@ --[STATUS LOG] 30-Dec-2003 Jakarta Struts- +-[STATUS LOG] 15-Mar-2003 Jakarta Struts- * Releases * Showstappers @@ -18,34 +18,34 @@ * Next anticipated release: 1.2.0 -* Anticipated time-frame (if any): Next thirty days, if pending issues can be resolved. +* Anticipated time-frame (if any): 1.2.0 tagged and rolled on 26/Feb/2004, undergoing testing prior to a committer vote as to quality. -Showstoppers- -* The 1.2.0 candidate should resolve Bugzilla [#233255, #23292, #25134, #28524, #25855, #25861] before release. +* None. -Recent Changes- -* 2003-12-30 - struts-nested: Added write attribute, and styleClass for completeness. +* Licenses updated to ASL 2.0 -* 2003-12-29 - struts-faces: Various updates regarding the JSF Final Draft and to prepare for Tiles support. +* Nightly build requires Commons Validation 1.1.2 -* 2003-12-22 - DispatchAction: Add detection of recursive calls. +* Support for generating unique form names within a page -* 2003-12-21 - Change to use typical welcome.do - welcome.jsp approach; Use name rather than attribute in configuration, per documented and common practice; Use action form of html:link +* Struts-Faces updated for JSF 1.0 final release -* 2003-12-21 - Add rest of form to fr.CA formset to correct operation. +* MailReader example application refactoring -* 2003-12-17 - struts-jericho: Whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x. +* Updated Japanese resources for MailReader example * See also: http://jakarta.apache.org/struts/userGuide/release-notes.html -Roadmap- -* Struts 1.x will remain based on Servlet 1.2/JSP 1.1 (evolution). +* Struts 1.x will remain based on Servlet 1.2/JSP 1.1 (evolution). * Struts 2.x will be based on Servlet / JSP 2.0 (revolution). @@ -54,30 +54,34 @@ -Bugzilla- -* Open problem reports: Â Â Â 6 [#23255 .. #25861] -* Open enhancement reports: 210 [# Â 866 .. #25860] -* Open LATER reports: Â Â Â Â 17 [#17977 .. #25759] +* Open problem reports: Â Â Â 10 [#26130 .. #27702] +* Open enhancement reports: 238 [# Â 866 .. #27545] (28 with patch) +* Open LATER reports: Â Â Â Â 23 [#17977 .. #26895] -Mailing list subscriptions- -* User 1955 +* User 1990 +* User digest: 954 +* Dev: 738 -* user digest: 923 -* Dev: 719 +-Significant threads- +* Work to migrate to Maven build continues. --Significant threads- +* Additional support to compartmentalize modules added just prior to 1.2.0 proposed release. -* Dev list discussions of whether and when to apply to the ASF for top-level project status http://tinyurl.com/2kkcq. +* Struts to apply for Apache top-level project status -* Several threads regarding Struts 2.0 feature set. A preliminary whiteboard has been posted http://cvs.apache.org/viewcvs.cgi/jakarta-struts/contrib/struts-jericho/. +* May move nightly build to the struts-chain request processor, now under contrib -CVS Activity- -* Total Commits: 89 Total Number of Files Changed: 401 +* Total Commits (14-15 Mar 2003, to change license): 5 Total Number of Files Changes: 678 + +* Total Commits (31 Dec 2003 thru 13 Mar 2003, 75 days): 222 Total Number of Files Changed: 1796 -Active Committers- @@ -92,7 +96,6 @@ Â Â * David M. Karr (dmkarr at apache.org) Â Â * David Graham (dgraham at apache.org) Â Â * James Mitchell (jmitchell at apache.org) -Â Â * James Turner (turner at blackbear.com) Â Â * Steve Raeburn (sraeburn at apache.org) Â Â * Don Brown (mrdon at apache.org) Â Â * Joe Germuska (germuska at apache.org) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts STATUS.txt
husted 2004/03/16 07:53:27 Modified:.STATUS.txt Log: + Routine update Revision ChangesPath 1.3 +2 -2 jakarta-struts/STATUS.txt Index: STATUS.txt === RCS file: /home/cvs/jakarta-struts/STATUS.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- STATUS.txt16 Mar 2004 15:52:41 - 1.2 +++ STATUS.txt16 Mar 2004 15:53:27 - 1.3 @@ -1,4 +1,4 @@ --[STATUS LOG] 15-Mar-2003 Jakarta Struts- +-[STATUS LOG] 15-Mar-2004 Jakarta Struts- * Releases * Showstappers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STATUS LOG] 15 Mar 2004 - Jakarta-Struts
-[STATUS LOG] 15-Mar-2004 Jakarta Struts- * Releases * Showstappers * Recent Changes * Roadmap * Bugzilla * Subscriptions * Threads * CVS Activity * Committers -Releases- * Stable release: 1.1 (29 June 2003). * Next anticipated release: 1.2.0 * Anticipated time-frame (if any): 1.2.0 tagged and rolled on 26/Feb/2004, undergoing testing prior to a committer vote as to quality. -Showstoppers- * None. -Recent Changes- * Licenses updated to ASL 2.0 * Nightly build requires Commons Validation 1.1.2 * Support for generating unique form names within a page * Struts-Faces updated for JSF 1.0 final release * MailReader example application refactoring * Updated Japanese resources for MailReader example * See also: http://jakarta.apache.org/struts/userGuide/release-notes.html -Roadmap- * Struts 1.x will remain based on Servlet 1.2/JSP 1.1 (evolution). * Struts 2.x will be based on Servlet / JSP 2.0 (revolution). * For more see http://jakarta.apache.org/struts/status.html. -Bugzilla- * Open problem reports: Â Â Â 10 [#26130 .. #27702] * Open enhancement reports: 238 [# Â 866 .. #27545] (28 with patch) * Open LATER reports: Â Â Â Â 23 [#17977 .. #26895] -Mailing list subscriptions- * User 1990 * User digest: 954 * Dev: 738 -Significant threads- * Work to migrate to Maven build continues. * Additional support to compartmentalize modules added just prior to 1.2.0 proposed release. * Struts to apply for Apache top-level project status * May move nightly build to the struts-chain request processor, now under contrib -CVS Activity- * Total Commits (14-15 Mar 2003, to change license): 5 Total Number of Files Changes: 678 * Total Commits (31 Dec 2003 thru 13 Mar 2003, 75 days): 222 Total Number of Files Changed: 1796 -Active Committers- Â Â * Craig R. McClanahan (craigmcc at apache.org) Â Â * Ted Husted (husted at apache.org) Â Â * Rob Leland (rleland at apache.org) Â Â * Cedric Dumoulin (cedric.dumoulin at lifl.fr) Â Â * Martin Cooper (martinc at apache.org) Â Â * Arron Bates (arron at apache.org) Â Â * James Holmes (jholmes at apache.org) Â Â * David M. Karr (dmkarr at apache.org) Â Â * David Graham (dgraham at apache.org) Â Â * James Mitchell (jmitchell at apache.org) Â Â * Steve Raeburn (sraeburn at apache.org) Â Â * Don Brown (mrdon at apache.org) Â Â * Joe Germuska (germuska at apache.org) $Id: STATUS.txt,v 1.2 2004/03/16 15:52:41 husted Exp $ ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/action ActionForward.java
husted 2004/03/16 13:06:03
Modified:src/share/org/apache/struts/action ActionForward.java
Log:
Add copy constructor per suggestion by Jay Glanville on Struts-User
Revision ChangesPath
1.15 +14 -4
jakarta-struts/src/share/org/apache/struts/action/ActionForward.java
Index: ActionForward.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/action/ActionForward.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- ActionForward.java14 Mar 2004 06:23:42 - 1.14
+++ ActionForward.java16 Mar 2004 21:06:03 - 1.15
@@ -143,4 +143,14 @@
}
+/**
+ * pConstruct a new instance based on the values of another ActionForward./p
+ *
+ * @param copyMe An ActionForward instance to copy
+ * @since Struts 1.2.1
+ */
+public ActionForward(ActionForward copyMe) {
+
this(copyMe.getName(),copyMe.getPath(),copyMe.getRedirect(),copyMe.getContextRelative());
+}
+
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache License 2.0
On Sat, 13 Mar 2004 23:51:52 -0800, Steve Raeburn wrote: 3. Scaffold additional copyright notices: There are some additional copyright notices in some of the Scaffold files. I don't know if this is acceptable any longer under the new license. -- o.a.s.scaffold.Base Action -- Copyright (c) 2002 Synthis Corporation. 430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A. All rights reserved. This software is licensed to you free of charge under the Apache Software License, so long as this copyright statement, list of conditions, and comments, remains in the source code. See bottom of file for more license information. This software was written to support code generation for the Apache Struts J2EE architecture by Synthis' visual application modeling tool Adalon. For more information on Adalon and Struts code generation please visit http://www.synthis.com -- o.a.s.scaffold.SnoopServlet Action -- Derived from the Jetty SnoopServlet http://www.thecortex.net/clover/eg/jetty/report/default- pkg/SnoopServle t.html and distributed under its open source license http://jetty.mortbay.org/jetty/LICENSE.html. I have added the licenses to the Scaffold notice file, which I think is where attributions should go. For now, I've also left them in the source files as well. What should we do with these? Brian did say they don't want us redistributing other's people's distributions. However, this is a situation where our unique software product is derived from a compatible license or outright donation. This is code created and/or maintained by the ASF, which we can distribute under our own license and joint copyright. In other words, we are doing with others, what we expect others to do with us :) The Notices file seems sufficient. 4. I've only updated the Java source files. What other files need to have an ASL 2.0 license? XML docs? Struts DTD? These could be done, but I don't know if we need to do it proactively or just as we touch things. I don't think it's the board's intention to turn this into a make-work project. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold BaseAction.java BaseForm.java BaseHelperAction.java BaseMapForm.java BizAction.java ProcessAction.java ProcessDispatchAction.java ProcessFormAction.java
husted 2004/03/14 06:32:20 Modified:contrib/scaffold NOTICE.txt contrib/scaffold/src/java/org/apache/struts/scaffold BaseAction.java BaseForm.java BaseHelperAction.java BaseMapForm.java BizAction.java ProcessAction.java ProcessDispatchAction.java ProcessFormAction.java Log: Move copyrights to NOTICE.txt to conform with new format. Revision ChangesPath 1.2 +5 -3 jakarta-struts/contrib/scaffold/NOTICE.txt Index: NOTICE.txt === RCS file: /home/cvs/jakarta-struts/contrib/scaffold/NOTICE.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- NOTICE.txt14 Mar 2004 07:15:06 - 1.1 +++ NOTICE.txt14 Mar 2004 14:32:19 - 1.2 @@ -3,6 +3,9 @@ +Regarding: BaseAction, BaseForm, BaseHelperAction, BaseMapForm, BizAction, +ProcessAction, ProdcessDispatchAction and ProcessFormAction + Copyright (c) 2002 Synthis Corporation. 430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A. All rights reserved. @@ -10,8 +13,7 @@ This software is licensed to you free of charge under the Apache Software License, so long as this copyright statement, list of conditions, and comments, remains -in the source code. See bottom of file for more -license information. +in the source code. This software was written to support code generation for the Apache Struts J2EE architecture by Synthis' @@ -22,7 +24,7 @@ -Contains code derived from the Jetty SnoopServlet +SnoopAction.java contains code derived from the Jetty SnoopServlet http://www.thecortex.net/clover/eg/jetty/report/default-pkg/SnoopServlet.html and distributed under its open source license http://jetty.mortbay.org/jetty/LICENSE.html. 1.11 +4 -23 jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseAction.java Index: BaseAction.java === RCS file: /home/cvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseAction.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- BaseAction.java 14 Mar 2004 07:15:03 - 1.10 +++ BaseAction.java 14 Mar 2004 14:32:19 - 1.11 @@ -17,25 +17,6 @@ * See the License for the specific language governing permissions and * limitations under the License. */ - - -//Copyright (c) 2002 Synthis Corporation. -//430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A. -//All rights reserved. -// -//This software is licensed to you free of charge under -//the Apache Software License, so long as this copyright -//statement, list of conditions, and comments, remains -//in the source code. See bottom of file for more -//license information. -// -//This software was written to support code generation -//for the Apache Struts J2EE architecture by Synthis' -//visual application modeling tool Adalon. -// -//For more information on Adalon and Struts code -//generation please visit http://www.synthis.com - package org.apache.struts.scaffold; 1.15 +4 -27 jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseForm.java Index: BaseForm.java === RCS file: /home/cvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/BaseForm.java,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- BaseForm.java 14 Mar 2004 07:15:03 - 1.14 +++ BaseForm.java 14 Mar 2004 14:32:19 - 1.15 @@ -17,29 +17,6 @@ * See the License for the specific language governing permissions and * limitations under the License. */ - -/* - * - *Copyright (c) 2002 Synthis Corporation. - *430 10th Street NW, Suite S-108, Atlanta GA 30318, U.S.A. - *All rights reserved. - * - *This software is licensed to you free of charge under - *the Apache Software License, so long as this copyright - *statement, list of conditions, and comments, remains - *in the source code. See bottom of file for more - *license information. - * - *This software was written to support code generation - *for the Apache Struts J2EE architecture by Synthis' - *visual application modeling tool Adalon. - * - *For more information on Adalon and Struts code - *generation please visit http://www.synthis.com - * - */ - - package
Re: Reviving Struts-Chain (was ... PageController ...)
On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote: Is now a good time to coin a StrutsContext class that encapsulates the various arguments to execute? I've always kind of wanted this for Action too. I've frequently thought it would be a nice thing. This seems to get a little blurry when looking forward to a more chain-oriented Struts, where there's already a Context object floating through, but it seems worth discussing if we're making a new interface. I'd say that this is a good time to introduce a StrutsContext -AND- make Struts Chain the default request processor. My guess is that these components would affect how a PageController is realized, so let's go ahead and do that now. I believe it's been hovering over the airport longer than PageController anyway. :) As for the PageController, based on the need I've seen for it in my own applications, I'm starting to think of it as a Page Initialization block: A place where we can fold, spindle, or mutilate the data we need to use with the controls on a page. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving Struts-Chain (was ... PageController ...)
On Sun, 14 Mar 2004 11:34:10 -0600, Joe Germuska wrote: At 11:59 AM -0500 3/14/04, Ted Husted wrote: On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote: No one is more gung-ho about Struts Chain than I am, but people should be aware that we're still just into beta with functionality. Using it on my latest project, I've definitely found a few pieces that hadn't yet been implemented. I've put in what I found missing -- tiles and file upload -- but there are probably some other less mainstream pieces that will turn out to be buggy or not even implemented. We would probably want to make a branching CVS tag for this if we do it. I don't have a lot of experience working on branched codebases with a distributed team, so it should be an interesting ride, but I think Struts Chain is far enough from ready that we don't have a choice. I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). Plus, we need to push commons-chain to a full release. And what about commons-resources? That sounded like it was pretty close. Looking at http://jakarta.apache.org/struts/status.html , I think that roadmap may be still be a good strategy -- get the resources transition done for 1.3, then the new request processor for 1.4. Can anyone summarize what's standing between here and moving to commons-resources? I think Commons Chain can move up any time we wanted. It's just a matter of floating a vote. The Resources thing has been a longtime coming and should be stable. I wouldn't hesitate to do both Resources and Struts Chain in the HEAD now. In general, I'm satisfied with targeting the page prep as a chain- dependent feature. If we introduce a StrutsContext as the chain implementation of o.a.c.chain.Context then we'll have to come up with a Context factory process so that the ComposableRequestProcessor can be given a Context instead of instantiating one itself. My first hunch is that it should be an early chain command which creates a sub-context of a specific type and uses it to do most of the chain processing. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Jericho DTD
On Fri, 12 Mar 2004 10:30:08 -0600, Hookom, Jacob wrote:
mapping uri=/*
action execute=#{applicationController.validateLogin} / catch
exception=com.mckesson.smo.AuthorizationException / form id=C
/ /mapping
This reminds me of the Maverick approach, which is both simple and effective.
Just some ideas... I've been working on developing a mock version
of this between projects at work.
What I would like to do is develop Struts 2.0 test-first. The idea being we cold start
with a simple application and write just enough of 2.0 to develop the first page (or
story). Then just enough to develop the second page, and so forth. Each component
developed would have to be fully testable outside of a servlet/portlet/soap
environment.
Of course, no one application can represent all of the use cases a framework like
Struts must support, so after an initial sample application,we could start on the
Struts Cookbook application Steve Raeburn suggested. A very important point being that
no feature would be added without conventional unit tests and a working example use
case.
In doing this, I wouldn't feel constrained to anything we put on the whiteboard, so we
could try this or that in the context of working examples.
Right now, I'm refactoring the MailReader application in hope of using it as the
test-first foundation for Struts 2.0, and also exploring how other frameworks are
solving similar problems.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example LogonAction.java
husted 2004/03/12 15:49:29
Modified:src/example/org/apache/struts/webapp/example
LogonAction.java
Log:
Change methods from protected to private (it's a final class)
Revision ChangesPath
1.24 +8 -8
jakarta-struts/src/example/org/apache/struts/webapp/example/LogonAction.java
Index: LogonAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/LogonAction.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- LogonAction.java 12 Mar 2004 02:43:29 - 1.23
+++ LogonAction.java 12 Mar 2004 23:49:29 - 1.24
@@ -40,12 +40,12 @@
/**
* Name of username field [username].
*/
-private static String USERNAME = username;
+static String USERNAME = username;
/**
* Name of password field [password].
*/
-private static String PASSWORD = password;
+static String PASSWORD = password;
// -- Protected Methods
@@ -62,7 +62,7 @@
* @throws ExpiredPasswordException to be handled by Struts exception
* processor via the action-mapping
*/
-protected User getUser(UserDatabase database, String username,
+User getUser(UserDatabase database, String username,
String password, ActionMessages errors) throws
ExpiredPasswordException {
User user = null;
@@ -95,7 +95,7 @@
* @param request The request we are processing
* @param user The user object returned from the database
*/
-protected void SaveUser(HttpServletRequest request, User user) {
+void SaveUser(HttpServletRequest request, User user) {
HttpSession session = request.getSession();
session.setAttribute(Constants.USER_KEY, user);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example tour.html
husted 2004/03/12 15:50:09
Modified:web/example tour.html
Log:
Change methods from protected to private (it's a final class)
Revision ChangesPath
1.9 +4 -4 jakarta-struts/web/example/tour.html
Index: tour.html
===
RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- tour.html 12 Mar 2004 05:19:45 - 1.8
+++ tour.html 12 Mar 2004 23:50:09 - 1.9
@@ -461,9 +461,9 @@
private static String USERNAME = username;
private static String PASSWORD = password;
-protected User getUser(UserDatabase database, String username,
- String password, ActionMessages errors)
- throws ExpiredPasswordException {
+User getUser(UserDatabase database, String username,
+ String password, ActionMessages errors)
+ throws ExpiredPasswordException {
User user = null;
if (database == null){
@@ -487,7 +487,7 @@
}
-protected void SaveUser(HttpServletRequest request, User user) {
+void SaveUser(HttpServletRequest request, User user) {
HttpSession session = request.getSession();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example mainMenu.jsp tour.html
husted 2004/03/12 21:22:51 Modified:web/example mainMenu.jsp tour.html Log: Refine MainMenu and CheckLogon Revision ChangesPath 1.18 +4 -10 jakarta-struts/web/example/mainMenu.jsp Index: mainMenu.jsp === RCS file: /home/cvs/jakarta-struts/web/example/mainMenu.jsp,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- mainMenu.jsp 12 Mar 2004 05:19:45 - 1.17 +++ mainMenu.jsp 13 Mar 2004 05:22:51 - 1.18 @@ -3,21 +3,15 @@ %@ taglib uri=/tags/struts-bean prefix=bean % %@ taglib uri=/tags/struts-html prefix=html % app:checkLogon/ -jsp:useBean id=user scope=session type=org.apache.struts.webapp.example.User/ - -html:html +html head titlebean:message key=mainMenu.title//title -html:base/ +link rel=stylesheet type=text/css href=base.css / /head -body bgcolor=white - -h3bean:message key=mainMenu.heading/ -jsp:getProperty name=user property=username//h3 +h3bean:message key=mainMenu.heading/ bean:write name=user property=fullName //h3 ul lihtml:link action=/EditRegistration?action=Editbean:message key=mainMenu.registration//html:link/li lihtml:link forward=logoffbean:message key=mainMenu.logoff//html:link/li /ul - /body -/html:html +/html 1.10 +118 -46 jakarta-struts/web/example/tour.html Index: tour.html === RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- tour.html 12 Mar 2004 23:50:09 - 1.9 +++ tour.html 13 Mar 2004 05:22:51 - 1.10 @@ -110,33 +110,33 @@ pUnfortunately, actions cannot be specified as a welcome page. Since there can be a list of pages, the web server looks for each page on the list before selecting one. The web server doesn't see actions as pages and will never select one as a welcome page. So, in the case of a welcome page, how do we follow the Struts best practice of navigating through actions rather than pages?/p -pOne solution is to use a server page to bootstrap a Struts action. A Java web application recognizes the idea of forwarding from one page to another page (or action). We can register the usual index.jsp as the welcome page and have it forward to a welcome action. Here's the MailReader's index.jsp:/p +pOne solution is to use a server page to bootstrap a Struts action. A Java web application recognizes the idea of forwarding from one page to another page (or action). We can register the usual index.jsp as the welcome page and have it forward to a Welcome action. Here's the MailReader's index.jsp:/p hr / pre codelt;%@ taglib uri=/tags/struts-logic prefix=logic %gt; -lt;logic:redirect action=/welcome/gt;/code +lt;logic:redirect action=/Welcome/gt;/code /pre hr / -pAt the top of the page, we import the struts-logic JSP tag library. (Again, see the a href=http://jakarta.apache.org/struts/userGuide/preface.html;Preface to the Struts User Guide/a for more about the technologies underlying Struts.) The page itself consists of a single tag that redirects to the welcome action. The tag inserts the actual web address for the redirect when the page is rendered. But, where does the tag find the actual address to insert?/p +pAt the top of the page, we import the struts-logic JSP tag library. (Again, see the a href=http://jakarta.apache.org/struts/userGuide/preface.html;Preface to the Struts User Guide/a for more about the technologies underlying Struts.) The page itself consists of a single tag that redirects to the Welcome action. The tag inserts the actual web address for the redirect when the page is rendered. But, where does the tag find the actual address to insert?/p pThe list of actions, along with other Struts components, are registered through one or more Struts configuration files. The configuration files are written as XML documents and processed when the application starts. If we just wanted to forward to the welcome page, we could use a configuration element like this:/p hr / pre codelt;!-- Display welcome page --gt; -lt;action path=/welcome forward=/welcome.jsp /gt;/code +lt;action path=/Welcome forward=/welcome.jsp /gt;/code /pre hr / -pIf someone asked for the welcome action (/Welcome.do), the welcome.jsp page would be displayed in return./p +pIf someone asked for the Welcome action (/Welcome.do), the welcome.jsp page would be displayed in return./p h4a name=WelcomeAction.java id=WelcomeAction.javaWelcomeAction.java/a/h4 -pBut if we peek at the configuration file for the MailReader, we find a slightly more complicated XML element for the welcome action:/p +pBut
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example CheckLogonTag.java
husted 2004/03/12 21:23:39
Modified:src/example/org/apache/struts/webapp/example
CheckLogonTag.java
Log:
Refine MainMenu and CheckLogon
Revision ChangesPath
1.11 +23 -109
jakarta-struts/src/example/org/apache/struts/webapp/example/CheckLogonTag.java
Index: CheckLogonTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/CheckLogonTag.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- CheckLogonTag.java13 Jan 2004 12:48:44 - 1.10
+++ CheckLogonTag.java13 Mar 2004 05:23:39 - 1.11
@@ -3,63 +3,20 @@
* $Revision$
* $Date$
*
- *
- *
- * The Apache Software License, Version 1.1
- *
- * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
- * reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in
- *the documentation and/or other materials provided with the
- *distribution.
- *
- * 3. The end-user documentation included with the redistribution, if
- *any, must include the following acknowledgement:
- * This product includes software developed by the
- *Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowlegement may appear in the software itself,
- *if and wherever such third-party acknowlegements normally appear.
- *
- * 4. The names The Jakarta Project, Struts, and Apache Software
- *Foundation must not be used to endorse or promote products derived
- *from this software without prior written permission. For written
- *permission, please contact [EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache
- *nor may Apache appear in their name, without prior written
- *permission of the Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
- * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- *
- * This software consists of voluntary contributions made by many
- * individuals on behalf of the Apache Software Foundation. For more
- * information on the Apache Software Foundation, please see
- * http://www.apache.org/.
+ * Copyright 2000-2004 Apache Software Foundation
*
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
*/
-
-
package org.apache.struts.webapp.example;
@@ -78,7 +35,6 @@
*
* @version $Revision$ $Date$
*/
-
public final class CheckLogonTag extends TagSupport {
@@ -92,56 +48,15 @@
/**
- * The page to which we should forward for the user to log on.
- */
-private String page = /logon.jsp;
-
-
-// --- Properties
-
-
-/**
- * Return the bean name.
- */
-public String getName() {
-
-return (this.name);
-
-}
-
-
-/**
- * Set the bean name.
- *
- * @param name The new bean name
+ * Path to use if a login is needed
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example/memory MemoryUserDatabase.java
husted 2004/03/11 18:32:41
Modified:src/example/org/apache/struts/webapp/example
ApplicationResources.properties
ApplicationResources_ja.properties
ApplicationResources_ru.properties
LocaleAction.java LogonAction.java MODEL.txt
UserDatabase.java
src/example/org/apache/struts/webapp/example/memory
MemoryUserDatabase.java
Log:
Refactor login.jsp and LogonAction
Revision ChangesPath
1.12 +19 -17
jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources.properties
Index: ApplicationResources.properties
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources.properties,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ApplicationResources.properties 9 Mar 2004 04:36:49 - 1.11
+++ ApplicationResources.properties 12 Mar 2004 02:32:41 - 1.12
@@ -6,25 +6,27 @@
change.try=Try Again
change.title=Password Has Expired
database.load=Cannot load database from {0}
-error.database.missing=liUser database is missing, cannot validate logon
credentials/li
-error.fromAddress.format=liInvalid format for From Address/li
-error.fromAddress.required=liFrom Address is required/li
-error.fullName.required=liFull Name is required/li
-error.host.required=liMail Server is required/li
-error.noSubscription=liNo Subscription bean in user session/li
+error.database.missing=User database is missing, cannot validate logon credentials
+error.fromAddress.format=Invalid format for From Address
+error.fromAddress.required=From Address is required
+error.fullName.required=Full Name is required
+error.host.required=Mail Server is required
+error.noSubscription=No Subscription bean in user session
error.password.expired=Your password has expired for username {0}
-error.password.required=liPassword is required/li
-error.password2.required=liConfirmation password is required/li
-error.password.match=liPassword and confirmation password must match/li
-error.password.mismatch=liInvalid username and/or password, please try again/li
-error.replyToAddress.format=liInvalid format for Reply To Address/li
-error.transaction.token=liCannot submit this form out of order/li
-error.type.invalid=liServer Type must be 'imap' or 'pop3'/li
-error.type.required=liServer Type is required/li
-error.username.required=liUsername is required/li
-error.username.unique=liThat username is already in use - please select
another/li
+error.password.required=Password is required
+error.password2.required=Confirmation password is required
+error.password.match=Password and confirmation password must match
+error.password.mismatch=Invalid username and/or password, please try again
+error.replyToAddress.format=Invalid format for Reply To Address
+error.transaction.token=Cannot submit this form out of order
+error.type.invalid=Server Type must be 'imap' or 'pop3'
+error.type.required=Server Type is required
+error.username.required=Username is required
+error.username.unique=That username is already in use - please select another
errors.footer=/ulhr
-errors.header=h3font color=redValidation Error/font/h3You must correct
the following error(s) before proceeding:ul
+errors.header=h3font color=redValidation Error/font/h3pYou must correct
the following error(s) before proceeding:/pul
+errors.prefix=li
+errors.suffix=/li
errors.ioException=I/O exception rendering error messages: {0}
expired.password=User Password has expired for {0}
heading.autoConnect=Auto
1.6 +19 -17
jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources_ja.properties
Index: ApplicationResources_ja.properties
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources_ja.properties,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ApplicationResources_ja.properties27 Feb 2004 00:33:24 - 1.5
+++ ApplicationResources_ja.properties12 Mar 2004 02:32:41 - 1.6
@@ -6,25 +6,27 @@
change.try=\u518D\u8A66\u884C
change.title=\u30d1\u30b9\u30ef\u30fc\u30c9\u671f\u9650\u5207\u308c
database.load= {0}
\u304B\u3089\u30C7\u30FC\u30BF\u30D9\u30FC\u30B9\u3092\u30ED\u30FC\u30C9\u3067\u304D\u307E\u305B\u3093
-error.database.missing=li\u30E6\u30FC\u30B6\u30C7\u30FC\u30BF\u30D9\u30FC\u30B9\u304C\u898B\u3064\u304B\u308A\u307E\u305B\u3093\u3002\u30ED\u30B0\u30AA\u30F3\u306E\u8A8D\u8A3C\u304C\u51FA\u6765\u307E\u305B\u3093/li
-error.fromAddress.format=liFrom\u30A2\u30C9\u30EC\u30B9\u306E\u66F8\u5F0F
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example/memory MemoryUserDatabase.java
husted 2004/03/11 18:35:58 Modified:src/example/org/apache/struts/webapp/example/memory MemoryUserDatabase.java Log: Refactor login.jsp and LogonAction Revision ChangesPath 1.9 +0 -0 jakarta-struts/src/example/org/apache/struts/webapp/example/memory/MemoryUserDatabase.java Index: MemoryUserDatabase.java === RCS file: /home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/memory/MemoryUserDatabase.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example/memory TestUserDatabase.java
husted 2004/03/11 18:43:30
Modified:src/example/org/apache/struts/webapp/example
LocaleAction.java LogonAction.java
UserDatabase.java
Added: src/example/org/apache/struts/webapp/example/memory
TestUserDatabase.java
Log:
Refactor login.jsp and LogonAction
Revision ChangesPath
1.3 +0 -0
jakarta-struts/src/example/org/apache/struts/webapp/example/LocaleAction.java
Index: LocaleAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/LocaleAction.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
1.23 +0 -0
jakarta-struts/src/example/org/apache/struts/webapp/example/LogonAction.java
Index: LogonAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/LogonAction.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
1.6 +0 -0
jakarta-struts/src/example/org/apache/struts/webapp/example/UserDatabase.java
Index: UserDatabase.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/UserDatabase.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
1.1
jakarta-struts/src/example/org/apache/struts/webapp/example/memory/TestUserDatabase.java
Index: TestUserDatabase.java
===
/*
* Copyright 1999-2002,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.struts.webapp.example.memory;
import org.apache.struts.webapp.example.User;
import org.apache.struts.webapp.example.ExpiredPasswordException;
/**
* pHelp test exception handling by throwing exceptions when magic user names
are requested./p
*/
public final class TestUserDatabase extends MemoryUserDatabase {
/**
* If the username is expired throw an ExpiredPasswordException
* to simulate a business exception.
* If the username is arithmetic throw an Aritmetic exception to
* simulate a system exception.
* Otherwise, delegate to MemoryDatabase.
* @param username
* @return
*/
public User findUser(String username) throws ExpiredPasswordException {
if (expired.equals(username)) throw new ExpiredPasswordException(Testing
ExpiredPasswordException ...);
if (arithmetic.equals(username)) throw new ArithmeticException();
return super.findUser(username);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example/WEB-INF struts-config.xml validation.xml webtest.xml
husted 2004/03/11 18:44:34 Modified:web/example logon.jsp tour.html web/example/WEB-INF struts-config.xml validation.xml webtest.xml Log: Refactor login.jsp and LogonAction Revision ChangesPath 1.26 +4 -5 jakarta-struts/web/example/logon.jsp Index: logon.jsp === RCS file: /home/cvs/jakarta-struts/web/example/logon.jsp,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- logon.jsp 9 Mar 2004 04:35:01 - 1.25 +++ logon.jsp 12 Mar 2004 02:44:34 - 1.26 @@ -2,12 +2,11 @@ %@ taglib uri=/tags/struts-bean prefix=bean % %@ taglib uri=/tags/struts-html prefix=html % -html:html locale=true +html:xhtml/ +html head titlebean:message key=logon.title//title -html:base/ /head -body bgcolor=white html:errors/ @@ -36,7 +35,7 @@ tr td align=right - html:submit value=Submit/ + html:submit property=Submit value=Submit/ /td td align=left html:reset/ @@ -54,4 +53,4 @@ jsp:include page=footer.jsp / /body -/html:html +/html 1.7 +405 -255 jakarta-struts/web/example/tour.html Index: tour.html === RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- tour.html 10 Mar 2004 03:14:31 - 1.6 +++ tour.html 12 Mar 2004 02:44:34 - 1.7 @@ -103,35 +103,38 @@ pUnfortunately, actions cannot be specified as a welcome page. Since there can be a list of pages, the web server looks for each page on the list before selecting one. The web server doesn't see actions as pages and will never select one as a welcome page. So, in the case of a welcome page, how do we follow the Struts best practice of navigating through actions rather than pages?/p pOne solution is to use a server page to bootstrap a Struts action. A Java web application recognizes the idea of forwarding from one page to another page (or action). We can register the usual index.jsp as the welcome page and have it forward to a welcome action. Here's the MailReader's index.jsp:/p - -blockquote - pcodelt;%@ taglib uri=/tags/struts-logic prefix=logic %br / - lt;logic:redirect action=/welcome//code/p -/blockquote +hr / +pre +codelt;%@ taglib uri=/tags/struts-logic prefix=logic %gt; +lt;logic:redirect action=/welcome/gt;/code +/pre +hr / pAt the top of the page, we import the struts-logic JSP tag library. (Again, see the a href=http://jakarta.apache.org/struts/userGuide/preface.html;Preface to the Struts User Guide/a for more about the technologies underlying Struts.) The page itself consists of a single tag that redirects to the welcome action. The tag inserts the actual web address for the redirect when the page is rendered. But, where does the tag find the actual address to insert?/p pThe list of actions, along with other Struts components, are registered through one or more Struts configuration files. The configuration files are written as XML documents and processed when the application starts. If we just wanted to forward to the welcome page, we could use a configuration element like this:/p - -blockquote - pcodelt;!-- Display welcome page --br / - lt;action path=/welcome forward=/welcome.jsp //code/p -/blockquote +hr / +pre +codelt;!-- Display welcome page --gt; +lt;action path=/welcome forward=/welcome.jsp /gt;/code +/pre +hr / pIf someone asked for the welcome action (/welcome.do), the welcome.jsp page would be displayed in return./p -h4WelcomeAction/h4 +h4a name=WelcomeAction.java id=WelcomeAction.javaWelcomeAction.java/a/h4 pBut if we peek at the configuration file for the MailReader, we find a slightly more complicated XML element for the welcome action:/p - -blockquote - pcodelt;!-- Display welcome page --br / - lt;action path=/welcomebr / - nbsp;nbsp;type=org.apache.struts.webapp.example.WelcomeActionbr / - nbsp;nbsp;lt;forward name=failure path=/Error.jsp / br / - nbsp;nbsp;lt;forward name=success path=/welcome.jsp / br / - lt;/action/code/p -/blockquote +hr / +pre +codelt;!-- Display welcome page --gt; +lt;action path=/welcome + type=org.apache.struts.webapp.example.WelcomeActiongt; + lt;forward name=failure path=/Error.jsp /gt; + lt;forward name=success path=/welcome.jsp /gt; +lt;/actiongt;/code +/pre +hr / pHere, the WelcomeAction Java class executes whenever someone asks for the welcome action. As it completes, the Action class can select which page is displayed. Two pages
cvs commit: jakarta-struts/web/example/WEB-INF struts-config-registration.xml struts-config.xml validation.xml
husted 2004/03/11 21:19:46 Modified:web/example Registration.jsp changePassword.jsp footer.jsp index.jsp logon.jsp mainMenu.jsp subscription.jsp tour.html welcome.jsp web/example/WEB-INF struts-config-registration.xml struts-config.xml validation.xml Log: Conform case. Revision ChangesPath 1.5 +4 -4 jakarta-struts/web/example/Registration.jsp Index: Registration.jsp === RCS file: /home/cvs/jakarta-struts/web/example/Registration.jsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- Registration.jsp 9 Mar 2004 04:35:01 - 1.4 +++ Registration.jsp 12 Mar 2004 05:19:45 - 1.5 @@ -24,7 +24,7 @@ html:errors/ -html:form action=/saveRegistration focus=username +html:form action=/SaveRegistration focus=username onsubmit=return validateRegistrationForm(this); html:hidden property=action/ table border=0 width=100% @@ -156,10 +156,10 @@ bean:write name=subscription property=autoConnect/ /td td align=center - app:linkSubscription page=/editSubscription.do?action=Delete + app:linkSubscription page=/EditSubscription.do?action=Delete bean:message key=registration.deleteSubscription/ /app:linkSubscription - app:linkSubscription page=/editSubscription.do?action=Edit + app:linkSubscription page=/EditSubscription.do?action=Edit bean:message key=registration.editSubscription/ /app:linkSubscription /td @@ -168,7 +168,7 @@ /table -html:link action=/editSubscription?action=Create paramId=username +html:link action=/EditSubscription?action=Create paramId=username paramName=RegistrationForm paramProperty=username bean:message key=registration.addSubscription/ /html:link 1.4 +1 -1 jakarta-struts/web/example/changePassword.jsp Index: changePassword.jsp === RCS file: /home/cvs/jakarta-struts/web/example/changePassword.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- changePassword.jsp7 Mar 2004 20:29:31 - 1.3 +++ changePassword.jsp12 Mar 2004 05:19:45 - 1.4 @@ -10,7 +10,7 @@ body bgcolor=white bean:message key=change.message/ -html:link action=/logon +html:link action=/Logon bean:message key=change.try/ /html:link 1.2 +1 -1 jakarta-struts/web/example/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/example/footer.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- footer.jsp9 Mar 2004 04:35:01 - 1.1 +++ footer.jsp12 Mar 2004 05:19:45 - 1.2 @@ -1,4 +1,4 @@ %@ taglib uri=/tags/struts-bean prefix=bean % %@ taglib uri=/tags/struts-html prefix=html % hr / -phtml:link action=welcomebean:message key=index.title//html:link/p +phtml:link action=/Welcomebean:message key=index.title//html:link/p 1.22 +4 -4 jakarta-struts/web/example/index.jsp Index: index.jsp === RCS file: /home/cvs/jakarta-struts/web/example/index.jsp,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- index.jsp 9 Mar 2004 04:35:01 - 1.21 +++ index.jsp 12 Mar 2004 05:19:45 - 1.22 @@ -1,5 +1,5 @@ %@ taglib uri=/tags/struts-logic prefix=logic % -logic:redirect action=/welcome/ +logic:redirect action=/Welcome/ %-- Redirect default requests to Welcome action. By using a redirect, the user-agent will change address to match the path of our Welcome action. 1.27 +2 -2 jakarta-struts/web/example/logon.jsp Index: logon.jsp === RCS file: /home/cvs/jakarta-struts/web/example/logon.jsp,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- logon.jsp 12 Mar 2004 02:44:34 - 1.26 +++ logon.jsp 12 Mar 2004 05:19:45 - 1.27 @@ -10,7 +10,7 @@ html:errors/ -html:form action=/submitLogon focus=username +html:form action=/SubmitLogon focus=username onsubmit=return validateLogonForm(this); table border=0 width=100% @@ -46,7 +46,7 @@ /html:form -html:javascript formName=logonForm +html:javascript formName=LogonForm dynamicJavascript=true staticJavascript=false/ script language=Javascript1.1 src=staticJavascript.jsp/script 1.17 +1 -1 jakarta-struts/web/example/mainMenu.jsp Index
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example/memory MemoryUserDatabase.java MemoryDatabasePlugIn.java
husted 2004/03/10 19:26:02
Modified:src/example/org/apache/struts/webapp/example/memory
MemoryUserDatabase.java MemoryDatabasePlugIn.java
Log:
Remove unused members; update license.
Revision ChangesPath
1.7 +19 -68
jakarta-struts/src/example/org/apache/struts/webapp/example/memory/MemoryUserDatabase.java
Index: MemoryUserDatabase.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/memory/MemoryUserDatabase.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- MemoryUserDatabase.java 13 Jan 2004 12:48:44 - 1.6
+++ MemoryUserDatabase.java 11 Mar 2004 03:26:02 - 1.7
@@ -3,63 +3,20 @@
* $Revision$
* $Date$
*
- *
- *
- * The Apache Software License, Version 1.1
- *
- * Copyright (c) 1999-2002 The Apache Software Foundation. All rights
- * reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in
- *the documentation and/or other materials provided with the
- *distribution.
- *
- * 3. The end-user documentation included with the redistribution, if
- *any, must include the following acknowledgement:
- * This product includes software developed by the
- *Apache Software Foundation (http://www.apache.org/).
- *Alternately, this acknowlegement may appear in the software itself,
- *if and wherever such third-party acknowlegements normally appear.
- *
- * 4. The names The Jakarta Project, Struts, and Apache Software
- *Foundation must not be used to endorse or promote products derived
- *from this software without prior written permission. For written
- *permission, please contact [EMAIL PROTECTED]
- *
- * 5. Products derived from this software may not be called Apache
- *nor may Apache appear in their name, without prior written
- *permission of the Apache Software Foundation.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
- * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
- * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
- * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- *
- *
- * This software consists of voluntary contributions made by many
- * individuals on behalf of the Apache Software Foundation. For more
- * information on the Apache Software Foundation, please see
- * http://www.apache.org/.
+ * Copyright 2000-2004 Apache Software Foundation
*
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
*/
-
-
package org.apache.struts.webapp.example.memory;
@@ -234,7 +191,7 @@
new MemoryUserCreationFactory(this));
digester.addFactoryCreate
(database/user/subscription,
- new MemorySubscriptionCreationFactory(this));
+ new MemorySubscriptionCreationFactory());
// Parse the input stream to initialize our database
digester.parse(bis);
@@ -382,12 +339,6 @@
* Digester object creation factory for subscription instances.
*/
class MemorySubscriptionCreationFactory implements ObjectCreationFactory {
-
-public
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example MODEL.txt
husted 2004/03/10 19:30:01 Added: src/example/org/apache/struts/webapp/example MODEL.txt Log: Add text file with diagrams of model classes. Revision ChangesPath 1.1 jakarta-struts/src/example/org/apache/struts/webapp/example/MODEL.txt Index: MODEL.txt === -MailReader Object Model- [(Associations)] [UserDatabase] owns [User]s [User] owns [Subscription]s === [Subscription (interface)] + AutoConnect: Boolean + Host: String (readonly) + Type: String + Username: String + Password: String + User: User (readonly) [User (interface)] + Username: String (readonly) + Password: String + FullName: String + FromAddress: String + ReplyToAddress: String + DataBase: UserDatabase + Subscription: Subscription[] + ErrorMessage: String !NEW! + CreateSubscription(Host:String): Subscription + FindSubscription(Host:String):Subscription + RemoveSubscription(Subscription:Subcription) [UserDatabase (interface)] + Open() + Save() + Close() + CreateUser(username:String): User + FindUser(username:String): User + FindUsers(): User[] + RemoveUser(user:User) + UpdateUser(User) !NEW! [MemorySubscription:Subscription] - autoConnect:Boolean - host:String - type:String - username:String - password - user:User + MemorySubscription(user:MemoryUser host:String) * :Subscription members * ToString:String [MemoryUser:User] - username:String - password:String - fullname:String - fromAddress:String - replyToAddress:String - database:MemoryDataBAse - subscriptions:HashMap - errorMessage:String; !NEW! + MemoryUser(database:MemoryUserDatabase:* :User members database username:String) * ToString:String [MemoryUserDatabase:UserDatabase] - log:Log - users:HashMap - pathnameOld:String - pathnameNew:String + pathname:String * :UserDatabase [PlugIn (interface)] + Init(servlet:ActionServlet servlet config:ModuleConfig) + Destroy() [MemoryDataBasePlugIn:PlugIn] - database:MemoryUserDatabase - log:Log - servlet:ActionServlet + Pathname * :PlugIn - CalculatePath() [ObjectCreationFactory (interface)] Digester:Digester createObject(attributes:Attributes):Object [MemorySubscriptionCreationFactory:ObjectCreationFactory] + Digester:Digester * :ObjectCreationFactory [MemoryUserCreationFactory:ObjectCreationFactory] + Digester:Digester * :ObjectCreationFactory + MemoryUserCreationFactory(database:MemoryUserDatabase) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example/WEB-INF struts-config.xml
husted 2004/03/09 19:14:31
Modified:contrib/struts-faces/src/example/org/apache/struts/webapp/example
Constants.java
web/example tour.html welcome.jsp
web/example/WEB-INF struts-config.xml
Added: src/example/org/apache/struts/webapp/example
LocaleAction.java
Log:
Add change locale feature.
Revision ChangesPath
1.3 +1 -2
jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-faces/src/example/org/apache/struts/webapp/example/Constants.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Constants.java8 Mar 2004 02:49:52 - 1.2
+++ Constants.java10 Mar 2004 03:14:31 - 1.3
@@ -54,5 +54,4 @@
*/
public static final String USER_KEY = user;
-
}
1.1
jakarta-struts/src/example/org/apache/struts/webapp/example/LocaleAction.java
Index: LocaleAction.java
===
/*
* $Header:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/LocaleAction.java,v
1.1 2004/03/10 03:14:31 husted Exp $
* $Revision: 1.1 $
* $Date: 2004/03/10 03:14:31 $
*
* Copyright 2000-2004 Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.struts.webapp.example;
import java.util.Locale;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.struts.Globals;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
/**
* Change user's Struts @link(java.util.Locale.
*/
public final class LocaleAction extends BaseAction {
/**
* pReturn true if parameter is null or trims to empty./p
* @param string The string to text; may be null
* @return true if parameter is null or empty
*/
private boolean isBlank(String string) {
return ((string==null) || (string.trim().length()==0));
}
/**
* Parameter for @link(java.util.Locale) language property.
*/
private static final String LANGUAGE = language ;
/**
* Parameter for @link(java.util.Locale) country property.
*/
private static final String COUNTRY = country;
/**
* Parameter for response page URI.
*/
private static final String PAGE = page;
/**
* Parameter for response forward name.
*/
private static final String FORWARD = forward;
/**
* Logging message if LocaleAction is missing a target parameter.
*/
private static final String LOCALE_LOG = LocaleAction: Missing page or forward
parameter;
/**
* p
* Change the user's Struts @link(java.util.Locale) based on request
* parameters for language, country.
* After setting the Locale, control is forwarded to an URI path
* indicated by a page parameter, or a forward indicated by a
* forward parameter, or to a forward given as the mappings
* parameter property.
* The response location must be specified one of these ways.
* /p
* @param mapping The ActionMapping used to select this instance
* @param form The optional ActionForm bean for this request (if any)
* @param request The HTTP request we are processing
* @param response The HTTP response we are creating
*
* @return An ActionForward indicate the resources that will render the response
* @exception Exception if an input/output error or servlet exception occurs
*/
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
String language = request.getParameter(LANGUAGE);
String country = request.getParameter(COUNTRY);
Locale locale = getLocale(request);
if ((!isBlank(language
cvs commit: jakarta-struts/web/example footer.jsp welcome.jsp tour.html Registration.jsp logon.jsp index.jsp
husted 2004/03/08 20:35:01 Modified:web/example welcome.jsp tour.html Registration.jsp logon.jsp index.jsp Added: web/example footer.jsp Log: Add footer, move resource-test code to action, update tour page. Revision ChangesPath 1.3 +5 -26 jakarta-struts/web/example/welcome.jsp Index: welcome.jsp === RCS file: /home/cvs/jakarta-struts/web/example/welcome.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- welcome.jsp 7 Mar 2004 20:29:31 - 1.2 +++ welcome.jsp 9 Mar 2004 04:35:01 - 1.3 @@ -1,29 +1,12 @@ %@ page contentType=text/html;charset=UTF-8 language=java % %@ taglib uri=/tags/struts-bean prefix=bean % %@ taglib uri=/tags/struts-html prefix=html % -%@ taglib uri=/tags/struts-logic prefix=logic % -html:html locale=true +html head titlebean:message key=index.title//title -html:base/ +link rel=stylesheet type=text/css href=base.css / /head -body bgcolor=white - -logic:notPresent name=database scope=application - font color=red -ERROR: User database not loaded -- check servlet container logs -for error messages. - /font - hr -/logic:notPresent - -logic:notPresent name=org.apache.struts.action.MESSAGE scope=application - font color=red -ERROR: Application resources not loaded -- check servlet container -logs for error messages. - /font -/logic:notPresent h3bean:message key=index.heading//h3 ul @@ -31,13 +14,9 @@ lihtml:link action=/logonbean:message key=index.logon//html:link/li /ul -pnbsp;/p -html:link action=/tour -font size=-1bean:message key=index.tour//font -/html:link -pnbsp;/p +phtml:link action=/tourbean:message key=index.tour//html:link/p -html:img page=/struts-power.gif alt=Powered by Struts/ +phtml:img bundle=alternate pageKey=struts.logo.path altKey=struts.logo.alt//p /body -/html:html +/html 1.5 +194 -123 jakarta-struts/web/example/tour.html Index: tour.html === RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- tour.html 7 Mar 2004 20:22:52 - 1.4 +++ tour.html 9 Mar 2004 04:35:01 - 1.5 @@ -16,7 +16,7 @@ piThis article is meant to introduce a new user to Struts by walking through an application. See the a href=http://jakarta.apache.org/struts/;Struts Users Guide and Strut's API/a for more documentation./i/p -piThe MailReader application is based on the 1.2.0 build of Struts. To follow along, you should install the Mailreader application on your own development workstation (e.g. localhost)./i/p +piThe MailReader application is based on the 1.2.0 build of Struts. To follow along, you should install the MailReader application on your own development workstation (e.g. localhost)./i/p piThe article assumes the reader has a basic understanding of the Java language, JavaBeans, web applications, and JavaServer Pages. For background on these technologies, see the a href=http://jakarta.apache.org/struts/userGuide/preface.html;Preface to the Struts User Guide/a./i/p hr / @@ -92,92 +92,163 @@ h3a name=index.jsp id=index.jspindex.jsp/a/h3 +pA web application, like any other web site, can specify a list of welcome pages. When you open a web application without specifying a particular page, a welcome page is used by default./p + pStruts allows developers to manage an application through virtual pages called iactions/i. An accepted practice in Struts is to never link directly to server pages, but only to these actions. The actions are listed in a configuration file. By linking to actions, developers can rewire an application without editing the server pages./p blockquote pfont class=hintLink actions not pages./font/p /blockquote -pA web application, like any other web site, can specify a list of welcome pages. Unfortunately, actions cannot be specified as a welcome page. Since there can be a list of pages, the web server looks for each page on the list before selecting one. Unfortunately, the web server doesn't see actions as pages and will never select one as a welcome page. So, how do we follow the Struts best practice of navigating through actions rather than pages?/p +pUnfortunately, actions cannot be specified as a welcome page. Since there can be a list of pages, the web server looks for each page on the list before selecting one. The web server doesn't see actions as pages and will never select one as a welcome page. So, in the case of a welcome page, how do we follow the Struts best practice of navigating through
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example LICENSE.txt
husted 2004/03/08 20:37:26 Added: src/example/org/apache/struts/webapp/example LICENSE.txt Log: Add ASL 2.0 license file. Revision ChangesPath 1.1 jakarta-struts/src/example/org/apache/struts/webapp/example/LICENSE.txt Index: LICENSE.txt === Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. License shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. Licensor shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. Legal Entity shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, control means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. You (or Your) shall mean an individual or Legal Entity exercising permissions granted by this License. Source form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. Object form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. Work shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). Derivative Works shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. Contribution shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, submitted means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as Not a Contribution. Contributor shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s
cvs commit: jakarta-struts/web/example Error.jsp
husted 2004/03/08 20:38:05 Added: web/example Error.jsp Log: Add generic Error page. Revision ChangesPath 1.1 jakarta-struts/web/example/Error.jsp Index: Error.jsp === %-- Errors.jsp - Display unexpected errors, such as a JSP exception or missing resources --% %-- $Header: /home/cvs/jakarta-struts/web/example/Error.jsp,v 1.1 2004/03/09 04:38:05 husted Exp $ $Revision: 1.1 $ $Date: 2004/03/09 04:38:05 $ Copyright 2000-2004 Apache Software Foundation Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --% %@ page contentType=text/html;charset=UTF-8 language=java % %@ page import=org.apache.struts.Globals % %@ page import=org.apache.struts.webapp.example.Constants % %@ taglib uri=/tags/struts-bean prefix=bean % %@ taglib uri=/tags/struts-html prefix=html % %@ taglib uri=/tags/struts-logic prefix=logic % html:html head titleUnexpected Error/title html:base/ /head h3An unexpected error has occured/h3 logic:present name=%=Constants.ERROR_KEY% ul logic:iterate id=error name=%=Constants.ERROR_KEY% libean:write name=error //li /logic:iterate /ul /logic:present logic:present name=%=Globals.EXCEPTION_KEY% pbean:write name=%=Globals.EXCEPTION_KEY% property=message //p /logic:present /body /html:html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example/WEB-INF web.xml struts-config.xml struts-config-registration.xml
husted 2004/03/08 20:40:53 Modified:web/example/WEB-INF web.xml struts-config.xml struts-config-registration.xml Log: Add generic Error page, license references. Revision ChangesPath 1.20 +6 -0 jakarta-struts/web/example/WEB-INF/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/web.xml,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- web.xml 7 Mar 2004 20:29:31 - 1.19 +++ web.xml 9 Mar 2004 04:40:53 - 1.20 @@ -31,6 +31,12 @@ welcome-fileindex.jsp/welcome-file /welcome-file-list + !-- The default error page -- + error-page + exception-typejava.lang.Exception/exception-type + location\Error.jsp/location + /error-page + !-- Application Tag Library Descriptor -- taglib taglib-uri/tags/app/taglib-uri 1.39 +25 -7 jakarta-struts/web/example/WEB-INF/struts-config.xml Index: struts-config.xml === RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/struts-config.xml,v retrieving revision 1.38 retrieving revision 1.39 diff -u -r1.38 -r1.39 --- struts-config.xml 7 Mar 2004 20:22:52 - 1.38 +++ struts-config.xml 9 Mar 2004 04:40:53 - 1.39 @@ -1,10 +1,26 @@ ?xml version=1.0 encoding=ISO-8859-1 ? - !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.2//EN http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd; - - +!-- + $Header$ + $Revision$ + $Date$ + + Copyright 2000-2004 Apache Software Foundation + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- struts-config display-name![CDATA[ account maintenance @@ -45,11 +61,14 @@ !-- Display welcome page -- actionpath=/welcome - forward=/welcome.jsp/ + type=org.apache.struts.webapp.example.WelcomeAction + forward name=failure path=/Error.jsp / + forward name=success path=/welcome.jsp / + /action !-- Display registration page -- actionpath=/registration - forward=/registration.jsp/ + forward=/Registration.jsp/ !-- Display logon page -- actionpath=/mainMenu @@ -120,8 +139,7 @@ message-resources parameter=org.apache.struts.webapp.example.AlternateApplicationResources -key=alternate - /message-resources +key=alternate/ !-- == Plug Ins Configuration == -- 1.6 +20 -3 jakarta-struts/web/example/WEB-INF/struts-config-registration.xml Index: struts-config-registration.xml === RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/struts-config-registration.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- struts-config-registration.xml21 Dec 2003 22:43:52 - 1.5 +++ struts-config-registration.xml9 Mar 2004 04:40:53 - 1.6 @@ -1,9 +1,26 @@ ?xml version=1.0 encoding=ISO-8859-1 ? - !DOCTYPE struts-config PUBLIC -//Apache Software Foundation//DTD Struts Configuration 1.2//EN http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd; - +!-- + $Header$ + $Revision$ + $Date$ + + Copyright 2000-2004 Apache Software Foundation + + Licensed under the Apache License, Version 2.0 (the License); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + +http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an AS IS BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +-- struts-config display-name![CDATA[ registration @@ -26,7 +43,7 @@ !-- == Global Forward Definitions == -- global-forwards -forward name
cvs commit: jakarta-struts/web/example/WEB-INF database.xml
husted 2004/03/08 20:41:21 Modified:web/example/WEB-INF database.xml Log: Conform format with Digester output Revision ChangesPath 1.4 +6 -12 jakarta-struts/web/example/WEB-INF/database.xml Index: database.xml === RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/database.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- database.xml 15 Oct 2000 03:35:58 - 1.3 +++ database.xml 9 Mar 2004 04:41:21 - 1.4 @@ -1,15 +1,9 @@ +?xml version='1.0'? database - - user username=user -password=pass -fullName=John Q. User - fromAddress=[EMAIL PROTECTED] - - subscription host=mail.yahoo.com type=imap - username=jquser password=foo/ - subscription host=mail.hotmail.com type=pop3 - username=user1234 password=bar/ - + user username=user fromAddress=[EMAIL PROTECTED] fullName=John Q. User password=pass +subscription host=mail.hotmail.com autoConnect=false password=bar type=pop3 username=user1234 +/subscription +subscription host=mail.yahoo.com autoConnect=false password=foo type=imap username=jquser +/subscription /user - /database - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example/WEB-INF webtest.xml webtest.properties.sample WebTest.dtd
husted 2004/03/08 20:43:12 Added: web/example/WEB-INF webtest.xml webtest.properties.sample WebTest.dtd Log: Add Canoo WebTest files. Revision ChangesPath 1.1 jakarta-struts/web/example/WEB-INF/webtest.xml http://cvs.apache.org/viewcvs/jakarta-struts/web/example/WEB-INF/webtest.xml?rev=1.1 1.1 jakarta-struts/web/example/WEB-INF/webtest.properties.sample http://cvs.apache.org/viewcvs/jakarta-struts/web/example/WEB-INF/webtest.properties.sample?rev=1.1 1.1 jakarta-struts/web/example/WEB-INF/WebTest.dtd http://cvs.apache.org/viewcvs/jakarta-struts/web/example/WEB-INF/WebTest.dtd?rev=1.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example/WEB-INF/entities - New directory
husted 2004/03/08 20:43:46 jakarta-struts/web/example/WEB-INF/entities - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example/WEB-INF/entities config-debug.xml config-tidy.xml config.xml
husted 2004/03/08 20:44:07 Added: web/example/WEB-INF/entities config-debug.xml config-tidy.xml config.xml Log: Add Canoo WebTest files. Revision ChangesPath 1.1 jakarta-struts/web/example/WEB-INF/entities/config-debug.xml Index: config-debug.xml === config host=localhost port=8080 protocol=http basepath=example summary=true saveresponse=true resultpath=results resultfile=result.txt showhtmlparseroutput=true verbose=true/ 1.1 jakarta-struts/web/example/WEB-INF/entities/config-tidy.xml Index: config-tidy.xml === config host=localhost port=8080 protocol=http basepath=example summary=false saveresponse=false resultpath=results resultfile=result.txt showhtmlparseroutput=true verbose=false/ 1.1 jakarta-struts/web/example/WEB-INF/entities/config.xml Index: config.xml === config host=localhost port=8080 protocol=http basepath=example / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Logo
This might be the link Steve meant to post: http://www.ninsky.com/struts/logo/entries.do On Sun, 07 Mar 2004 01:04:28 -0800, Steve Raeburn wrote: As a sideshow to the Struts TLP proposal, I'd like to resurrect a discussion from a few months ago regarding a new logo for the Struts project. At the time, I put together a site (http://www.ninsky.com/struts/logo/logo.do) to allow submission and voting for a new logo, should we decide we want one. Please take a look, and if there's interest from the committers and community, then we could launch a competition for a shiny new logo to go with the (possible) shiny new TLP status. Steve - 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]
cvs commit: jakarta-struts/web/example/WEB-INF struts-config.xml
husted 2004/03/07 12:22:52
Modified:web/example base.css index.jsp tour.html
web/example/WEB-INF struts-config.xml
Log:
Update for index/welcome page.
Revision ChangesPath
1.2 +9 -1 jakarta-struts/web/example/base.css
Index: base.css
===
RCS file: /home/cvs/jakarta-struts/web/example/base.css,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- base.css 7 Mar 2004 02:20:37 - 1.1
+++ base.css 7 Mar 2004 20:22:52 - 1.2
@@ -19,3 +19,11 @@
h4 { font-family: Arial,Helvetica,sans-serif; }
h5 { font-family: Arial,Helvetica,sans-serif; }
h6 { font-family: Arial,Helvetica,sans-serif; }
+
+font.hint {
+ font-style:italic;
+ font-size:80%;
+ font-family:Arial,Helvetica,sans-serif;
+ font-weight:bold;
+ text-align:left;
+}
\ No newline at end of file
1.19 +3 -3 jakarta-struts/web/example/index.jsp
Index: index.jsp
===
RCS file: /home/cvs/jakarta-struts/web/example/index.jsp,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- index.jsp 21 Dec 2003 22:45:41 - 1.18
+++ index.jsp 7 Mar 2004 20:22:52 - 1.19
@@ -1,9 +1,9 @@
%@ taglib uri=WEB-INF/struts-logic.tld prefix=logic %
-logic:redirect forward=welcome/
+logic:redirect action=welcome/
%--
-Redirect default requests to Welcome global ActionForward.
-By using a redirect, the user-agent will change address to match the path of our
Welcome ActionForward.
+Redirect default requests to Welcome action.
+By using a redirect, the user-agent will change address to match the path of our
Welcome action.
--%
1.4 +91 -72jakarta-struts/web/example/tour.html
Index: tour.html
===
RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- tour.html 7 Mar 2004 02:20:37 - 1.3
+++ tour.html 7 Mar 2004 20:22:52 - 1.4
@@ -14,11 +14,11 @@
blockquote
h2A Walking Tour of the Struts MailReader Demonstration Application/h2
-piThis article is meant to introduce a new user to Struts by walking
through the example application. See the a
href=http://jakarta.apache.org/struts/;Struts Users Guide and Strut's API/a for
more documentation./i/p
+piThis article is meant to introduce a new user to Struts by walking
through an application. See the a href=http://jakarta.apache.org/struts/;Struts
Users Guide and Strut's API/a for more documentation./i/p
-piThis article is based on the working 1.0 builds of Struts. It is assumed
that the reader has already installed a developer's copy of Struts and the example
application (following the instructions in the Struts readme), and is ready to explore
the example on their own development workstation (e.g. localhost)./i/p
+piThe MailReader application is based on the 1.2.0 build of Struts. To
follow along, you should install the Mailreader application on your own development
workstation (e.g. localhost)./i/p
-piThis article also assumes the reader has a basic understanding of the
Java language, JavaBeans, Web applications and JavaServer Pages. For background on
these topics, see the various Sun Javasoft product sites./i/p
+piThe article assumes the reader has a basic understanding of the Java
language, JavaBeans, web applications, and JavaServer Pages. For background on these
technologies, see the a
href=http://jakarta.apache.org/struts/userGuide/preface.html;Preface to the Struts
User Guide/a./i/p
hr /
ul
@@ -86,19 +86,42 @@
/ul
hr /
-pThe standard Struts package comes with six applications: struts-test,
struts-documentation, tiles-documentation, struts-validator, struts-upload, and
struts-example. Regarding struts-example, the readme tells us that:/p
+pThe Struts distribution bundles four applications: struts-documentation,
tiles-documentation, struts-example, and struts-examples. This document walks through
the struts-example, also known as the MailReader Demonstration Application./p
+
+pThe premise of the MailReader is that it is the first iteration of a portal
application. This version allows users to register themselves and maintain a set of
accounts with various mail servers. When completed, the application would let users
read mail from their accounts./p
+
+h3a name=index.jsp id=index.jspindex.jsp/a/h3
+
+pStruts allows developers to manage an application through virtual pages
called iactions/i. An accepted practice in Struts is to never link directly to
server pages, but only to these actions. The actions
cvs commit: jakarta-struts/web/example/WEB-INF web.xml
husted 2004/03/07 12:29:31 Modified:web/example Registration.jsp changePassword.jsp index.jsp logon.jsp mainMenu.jsp staticJavascript.jsp subscription.jsp welcome.jsp web/example/WEB-INF web.xml Log: Conform tag imports to examples and blank applications. Revision ChangesPath 1.3 +4 -4 jakarta-struts/web/example/Registration.jsp Index: Registration.jsp === RCS file: /home/cvs/jakarta-struts/web/example/Registration.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Registration.jsp 21 Dec 2003 22:46:09 - 1.2 +++ Registration.jsp 7 Mar 2004 20:29:31 - 1.3 @@ -1,8 +1,8 @@ %@ page contentType=text/html;charset=UTF-8 language=java % -%@ taglib uri=/WEB-INF/app.tldprefix=app % -%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % -%@ taglib uri=/WEB-INF/struts-html.tld prefix=html % -%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % +%@ taglib uri=/tags/appprefix=app % +%@ taglib uri=/tags/struts-bean prefix=bean % +%@ taglib uri=/tags/struts-html prefix=html % +%@ taglib uri=/tags/struts-logic prefix=logic % logic:equal name=RegistrationForm property=action scope=request value=Edit app:checkLogon/ 1.3 +2 -2 jakarta-struts/web/example/changePassword.jsp Index: changePassword.jsp === RCS file: /home/cvs/jakarta-struts/web/example/changePassword.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- changePassword.jsp21 Dec 2003 22:46:09 - 1.2 +++ changePassword.jsp7 Mar 2004 20:29:31 - 1.3 @@ -1,6 +1,6 @@ %@ page contentType=text/html;charset=UTF-8 language=java % -%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % -%@ taglib uri=/WEB-INF/struts-html.tld prefix=html % +%@ taglib uri=/tags/struts-bean prefix=bean % +%@ taglib uri=/tags/struts-html prefix=html % html:html locale=true head 1.20 +1 -1 jakarta-struts/web/example/index.jsp Index: index.jsp === RCS file: /home/cvs/jakarta-struts/web/example/index.jsp,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- index.jsp 7 Mar 2004 20:22:52 - 1.19 +++ index.jsp 7 Mar 2004 20:29:31 - 1.20 @@ -1,4 +1,4 @@ -%@ taglib uri=WEB-INF/struts-logic.tld prefix=logic % +%@ taglib uri=/tags/struts-logic prefix=logic % logic:redirect action=welcome/ %-- 1.24 +2 -2 jakarta-struts/web/example/logon.jsp Index: logon.jsp === RCS file: /home/cvs/jakarta-struts/web/example/logon.jsp,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- logon.jsp 21 Dec 2003 22:46:09 - 1.23 +++ logon.jsp 7 Mar 2004 20:29:31 - 1.24 @@ -1,6 +1,6 @@ %@ page contentType=text/html;charset=UTF-8 language=java % -%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % -%@ taglib uri=/WEB-INF/struts-html.tld prefix=html % +%@ taglib uri=/tags/struts-bean prefix=bean % +%@ taglib uri=/tags/struts-html prefix=html % html:html locale=true head 1.16 +3 -3 jakarta-struts/web/example/mainMenu.jsp Index: mainMenu.jsp === RCS file: /home/cvs/jakarta-struts/web/example/mainMenu.jsp,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- mainMenu.jsp 21 Dec 2003 22:46:09 - 1.15 +++ mainMenu.jsp 7 Mar 2004 20:29:31 - 1.16 @@ -1,7 +1,7 @@ %@ page contentType=text/html;charset=UTF-8 language=java % -%@ taglib uri=/WEB-INF/app.tld prefix=app % -%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % -%@ taglib uri=/WEB-INF/struts-html.tld prefix=html % +%@ taglib uri=/tags/app prefix=app % +%@ taglib uri=/tags/struts-bean prefix=bean % +%@ taglib uri=/tags/struts-html prefix=html % app:checkLogon/ jsp:useBean id=user scope=session type=org.apache.struts.webapp.example.User/ 1.2 +1 -1 jakarta-struts/web/example/staticJavascript.jsp Index: staticJavascript.jsp === RCS file: /home/cvs/jakarta-struts/web/example/staticJavascript.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- staticJavascript.jsp 14 Jul 2002 01:35:18 - 1.1 +++ staticJavascript.jsp 7 Mar 2004 20:29:31 - 1.2 @@ -2,6 +2,6 @@ %-- set document type to Javascript (addresses a bug in Netscape according to a web resource
ASL 2.0
Would anyone have a chance to apply Paul's patch this afternoon? http://issues.apache.org/bugzilla/show_bug.cgi?id=27137 I'm out of town and this might be a bear for me to commit over a 28.8 modem connection :) Otherwise, I'll try to do it later tonight. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASL 2.0
Anything anyone wants to do would be fine with me. :) I'll start using ASL 2.0 for any files I touch. -T. On Sun, 07 Mar 2004 16:47:12 -0800, Craig R. McClanahan wrote: Quoting [EMAIL PROTECTED] [EMAIL PROTECTED]: An alternative is to directly run the python scripts, it's probably easier than applying the patch. I could do that. In the committers module (relicense directory) there is also a Java version of the relicensing tool that works quite well. I used it with great success converting some of the commons packages. Also, be aware that I just committed a pretty massive update to the contrib/struts-faces subdirectory, so any previous patch against those files will likely fail on mismatches. Craig -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Sunday, March 7, 2004 10:08 PM To: 'Struts Developers List' Subject: Re: ASL 2.0 I attempted to apply the patches but Eclipse wouldn't cooperate. I don't have any other cvs tools on my windows box, which is the only one with Struts development setup at the moment. David --- Ted Husted [EMAIL PROTECTED] wrote: Would anyone have a chance to apply Paul's patch this afternoon? http://issues.apache.org/bugzilla/show_bug.cgi?id=27137 I'm out of town and this might be a bear for me to commit over a 28.8 modem connection :) Otherwise, I'll try to do it later tonight. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts as an Apache Top Level Project
+1 to submit the draft TLP resolution. +1 to nominate Craig as VP. -Ted. On Sat, 06 Mar 2004 11:20:01 -0800 (PST), Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=listName=struts- [EMAIL PROTECTED]searchText=%22Why+you+*want* +to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - 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]
cvs commit: jakarta-struts/web/example/WEB-INF struts-config.xml
husted 2004/03/06 17:07:11 Modified:web/example/WEB-INF struts-config.xml Added: web/example tour.html Removed: web/example tour.htm Log: Use HTML Tidy to reformat tour (no content changes yet). Conform extension to .html. Revision ChangesPath 1.1 jakarta-struts/web/example/tour.html Index: tour.html === !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; head meta name=generator content=HTML Tidy for Windows (vers 1st July 2003), see www.w3.org / meta http-equiv=Content-Type content=text/html; charset=us-ascii / titleA Walking Tour of the Struts Example Application/title /head body blockquote h2font face=ArialA Walking Tour of the Struts Example Application/font/h2 piThis article is meant to introduce a new user to Struts by walking through the example application. See the a href=http://jakarta.apache.org/struts/;Struts Users Guide and Strut's API/a for more documentation.nbsp;nbsp;/i/p piThis article is based on the working 1.0 builds of Struts.nbsp; It is assumed that the reader has already installed a developer's copy of Struts and the example application (following the instructions in the Struts readme), and is ready to explore the example on their own development workstation (e.g. localhost).nbsp;/i/p piThis article also assumes the reader has a basic understanding of the Java language, JavaBeans, Web applications and JavaServer Pages. For background on these topics, see the various Sun Javasoft product sites./i/p hr / ul li a href=#index.jspindex.jsp/a ul lia href=#web.xmlweb.xmlnbsp;and ApplicationResources.properties/a/li lia href=#DatabaseServlet.javaDatabaseServlet.java/a/li /ul /li li a href=#logon.jsplogon.jsp/a ul lia href=#struts-config.xmlstruts-config.xml/a/li lia href=#struts-config.xmlLogonForm.java/a/li lia href=#LogonAction.javaLogonAction.java/a/li lia href=#struts-config.xml/2struts-config.xml 2/a/li /ul /li li a href=#mainMenu.jspmainMenu.jsp/a ul lia href=#CheckLoginTag.javaCheckLoginTag.java/a/li lia href=#editRegistrationAction.javaeditRegistrationAction.java/a/li /ul /li li a href=#subscription.jspregistration.jsp/a ul lia href=#registrationForm.javaRegistrationForm.java/a/li lia href=#editRegistrationAction.javaEditRegistrationAction.java/a/li lia href=#LinkSubscriptionTag.javaLinkSubscriptionTag.java/a/li lia href=#LinkUserTag.javaLinkUserTag.java/a/li lia href=#EditSubscriptionAction.javaEditSubscriptionAction.java/a/li /ul /li li a href=#subcription.jspsubscription.jsp/a ul lia href=#SubscriptionForm.javaSubscriptionForm.javanbsp;/a/li lia href=#SaveSubscriptionAction.javaSaveSubscriptionAction.java/a/li /ul /li lia href=#SummarySummary/a/li /ul hr / pThe standard Struts package comes with six applications: struts-test, struts-documentation, tiles-documentation, struts-validator, struts-upload, and struts-example. Regarding struts-example, the readme tells us that:/p blockquote pThis example is the beginnings of a portal application that would allow users to register themselves, and maintain a set of subscriptions they own to mail servers elsewhere on the Internet. When completed, this application will provide the ability to read mail from various mail servers, through the application./p /blockquote pThe example is still incomplete, but still a very useful introduction to Struts. For more about installing Struts and the example application, see the Struts readme./p h3a name=index.jsp id=index.jspfont face=Arialindex.jsp/font/a/h3 pOnce installed, the example application is entered through a standard welcome page, index.jsp. This page offers two links, one to register with the application and one to login in (if you have already registered)./p pBehind the scenes, index.jsp also checks for the existence of a database servlet and message resource. Both of these objects are referenced in the application's web.xml, and should be loaded before the index.jsp displays. If they are absent for any reason, index.jsp displays an error message./p blockquote piNote that the error messages are hardcoded into the welcome page; this way they can be displayed even if the message
cvs commit: jakarta-struts/web/example tour.html
husted 2004/03/06 17:54:55
Modified:src/example/org/apache/struts/webapp/example
ApplicationResources.properties
web/example tour.html
Log:
Conform formatting; typographical errors; no content changes.
Revision ChangesPath
1.10 +2 -2
jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources.properties
Index: ApplicationResources.properties
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/ApplicationResources.properties,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ApplicationResources.properties 26 Sep 2002 22:07:29 - 1.9
+++ ApplicationResources.properties 7 Mar 2004 01:54:55 - 1.10
@@ -37,7 +37,7 @@
index.logon=Log on to the MailReader Demonstration Application
index.registration=Register with the MailReader Demonstration Application
index.title=MailReader Demonstration Application (Struts 1.1-dev)
-index.tour=A Walking Tour of the Example Application
+index.tour=A Walking Tour of the MailReader Demonstration Application
linkSubscription.io=I/O Error: {0}
linkSubscription.noSubscription=No subscription under attribute {0}
linkUser.io=I/O Error: {0}
@@ -63,7 +63,7 @@
registration.addSubscription=Add
registration.deleteSubscription=Delete
registration.editSubscription=Edit
-registration.title.create=Register for the MailReader Demostration Application
+registration.title.create=Register for the MailReader Demonstration Application
registration.title.edit=Edit Registration for the MailReader Demonstration
Application
subscription.title.create=Create New Mail Subscription
subscription.title.delete=Delete Existing Mail Subscription
1.2 +111 -112 jakarta-struts/web/example/tour.html
Index: tour.html
===
RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- tour.html 7 Mar 2004 01:07:11 - 1.1
+++ tour.html 7 Mar 2004 01:54:55 - 1.2
@@ -6,16 +6,16 @@
meta name=generator content=HTML Tidy for Windows (vers 1st July 2003), see
www.w3.org /
meta http-equiv=Content-Type content=text/html; charset=us-ascii /
- titleA Walking Tour of the Struts Example Application/title
+ titleA Walking Tour of the Struts MailReader Demonstration Application/title
/head
body
blockquote
-h2font face=ArialA Walking Tour of the Struts Example
Application/font/h2
+h2font face=ArialA Walking Tour of the Struts MailReader Demonstration
Application/font/h2
-piThis article is meant to introduce a new user to Struts by walking
through the example application. See the a
href=http://jakarta.apache.org/struts/;Struts Users Guide and Strut's API/a for
more documentation.nbsp;nbsp;/i/p
+piThis article is meant to introduce a new user to Struts by walking
through the example application. See the a
href=http://jakarta.apache.org/struts/;Struts Users Guide and Strut's API/a for
more documentation./i/p
-piThis article is based on the working 1.0 builds of Struts.nbsp; It is
assumed that the reader has already installed a developer's copy of Struts and the
example application (following the instructions in the Struts readme), and is ready to
explore the example on their own development workstation (e.g.
localhost).nbsp;/i/p
+piThis article is based on the working 1.0 builds of Struts. It is assumed
that the reader has already installed a developer's copy of Struts and the example
application (following the instructions in the Struts readme), and is ready to explore
the example on their own development workstation (e.g. localhost)./i/p
piThis article also assumes the reader has a basic understanding of the
Java language, JavaBeans, Web applications and JavaServer Pages. For background on
these topics, see the various Sun Javasoft product sites./i/p
hr /
@@ -25,7 +25,7 @@
a href=#index.jspindex.jsp/a
ul
- lia href=#web.xmlweb.xmlnbsp;and
ApplicationResources.properties/a/li
+ lia href=#web.xmlweb.xml and
ApplicationResources.properties/a/li
lia href=#DatabaseServlet.javaDatabaseServlet.java/a/li
/ul
@@ -75,7 +75,7 @@
a href=#subcription.jspsubscription.jsp/a
ul
- lia href=#SubscriptionForm.javaSubscriptionForm.javanbsp;/a/li
+ lia href=#SubscriptionForm.javaSubscriptionForm.java/a/li
lia
href=#SaveSubscriptionAction.javaSaveSubscriptionAction.java/a/li
/ul
@@ -100,15 +100,15 @@
pBehind the scenes, index.jsp also checks for the existence of a database
servlet
cvs commit: jakarta-struts/web/example base.css tour.html
husted 2004/03/06 18:20:37 Modified:web/example tour.html Added: web/example base.css Log: Migrate tour.html to CSS. Revision ChangesPath 1.3 +23 -22jakarta-struts/web/example/tour.html Index: tour.html === RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- tour.html 7 Mar 2004 01:54:55 - 1.2 +++ tour.html 7 Mar 2004 02:20:37 - 1.3 @@ -5,13 +5,14 @@ head meta name=generator content=HTML Tidy for Windows (vers 1st July 2003), see www.w3.org / meta http-equiv=Content-Type content=text/html; charset=us-ascii / + link rel=stylesheet type=text/css href=base.css / titleA Walking Tour of the Struts MailReader Demonstration Application/title /head body blockquote -h2font face=ArialA Walking Tour of the Struts MailReader Demonstration Application/font/h2 +h2A Walking Tour of the Struts MailReader Demonstration Application/h2 piThis article is meant to introduce a new user to Struts by walking through the example application. See the a href=http://jakarta.apache.org/struts/;Struts Users Guide and Strut's API/a for more documentation./i/p @@ -93,7 +94,7 @@ pThe example is still incomplete, but still a very useful introduction to Struts. For more about installing Struts and the example application, see the Struts readme./p -h3a name=index.jsp id=index.jspfont face=Arialindex.jsp/font/a/h3 +h3a name=index.jsp id=index.jspindex.jsp/a/h3 pOnce installed, the example application is entered through a standard welcome page, index.jsp. This page offers two links, one to register with the application and one to login in (if you have already registered)./p @@ -103,7 +104,7 @@ piNote that the error messages are hardcoded into the welcome page; this way they can be displayed even if the message resource is missing. In other pages, a message resource is used to lookup and display messages, based on the user's locale./i/p /blockquote -h4font face=Ariala name=web.xml id=web.xmlweb.xml/a and a name=ApplicationResources.properties id=ApplicationResources.propertiesApplicationResources.properties/a/font/h4 +h4a name=web.xml id=web.xmlweb.xml/a and a name=ApplicationResources.properties id=ApplicationResources.propertiesApplicationResources.properties/a/h4 pIf you check the application's web.xml, you will see how these objects are loaded. The message resource is loaded by the application parameter to the ActionServlet. When the ActionServlet initializes, it parses the ApplicationResources.properties in the package folder into the default message resource. If you change a message in the resource, and then reload the application, it will appear throughout the application./p @@ -111,7 +112,7 @@ piYou can even reload the configuration and message resources without restarting the container. See the end of the web.xml file for details./i/p /blockquote -h4a name=DatabaseServlet.java id=DatabaseServlet.javafont face=ArialDatabaseServlet.java/font/a/h4 +h4a name=DatabaseServlet.java id=DatabaseServlet.javaDatabaseServlet.java/a/h4 pThe database object has it's own initialization block. The database servlet stores the database contents as a XML file, which is parsed by the Struts digester and loaded as a set of nested hashtables. The outer table is the list of user objects, each of which has its own inner hashtable of subscriptions. When you register, a user object is stored in this hashtable ... and when you login, the user object is stored within the session context./p @@ -133,7 +134,7 @@ piIn the source to the database servlet, you should notice that the attribute name for the servlet is read from the package's constant file. This is a good way to be sure a name or other string value is uniform between source files./i/p /blockquote -h4a name=index.jsp_2 id=index.jsp_2font face=Arialindex.jsp 2/font/a/h4 +h4a name=index.jsp_2 id=index.jsp_2index.jsp 2/a/h4 pBack in the index.jsp, we can find several good uses of Struts custom tags. Two worth noting now are the base and the link tags. The base tag returns the current URL to the page, to be sure other relative hyperlinks on the page work properly. The link tag renders another important service. Besides being a quick way to write a hyperlink, it will also URL encode the hyperlink to maintain the client's session -- if the current client can't store the session as a cookie./p @@ -155,7 +156,7 @@ pAt the top of the index.jsp page, you may also note several directives that load the tag libraries. These are just the usual red tape that goes with any Java source file
Re: Struts Change Tracking (Re: [ANNOUNCE] Struts 1.2.0 Test Build available)
Right now, I'm using the Maven changelog as a cut-and-paste guide to the release notes. I think the change plugin could be a replacement for this, especially if we start release more than one product, each of which could have their own change file. (struts-core, struts-opt-taglibs, struts-opt-el, struts-opt-apps, and so forth.) I do agree that that we need to summarize the changelog to turn data into information, and the changes plugin might be a help with that. Though, since part of that is categorizing the changes, I think we need to divy up the distribution before changing what we now do for release note changes. Personally, I'd like to prioritize moving the build over to Maven, and dividing the distribution into multiple artifacts with their own release cycles, so that we start taking advantage of features like this. -Ted. On Fri, 27 Feb 2004 08:10:53 -0600, Joe Germuska wrote: At 9:05 AM +0100 2/27/04, nicolas De Loof wrote: Can you please post a what's new about this release to help me make my boss agree to use Struts 1.2.0 for new projects ? Are committers familiar with the Maven changes.xml file/plugin? If it exists, it can be used to generate something that looks like this: http://maven.apache.org/changes-report.html Even though Maven isn't our primary build mechanism, using changes.xml might be a good way to track what we're doing. I hope I'm not embarassing myself, but there isn't any basic change log already is there? If so, I sure haven't been tracking it. I guess putting every single commit into the changes.xml file isn't appropriate, or the thing would get huge. Also, Maven can generate a separate report for that (http://maven.apache.org/changelog- report.html) Since changes.xml is structured, we could probably come up with a transform to use it in the current Ant-built documentation until we are using Maven, and if nothing else, it provides a single place to log things. Of course, if people don't think it's worth the energy, I'd rather leave it out than have it there but inaccurate. Joe PS an example of the XML syntax is here: http://maven.apache.org/reference/plugins/changes/ It's about as much doc as I've ever seen for it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.x and beyond (was Tagging and Freezing)
I had been putting all my Struts hours into 1.2.0, but now that we're past that, I can take a look at this again. To an extent, I believe it not only represents a 2.x product we might want to build, but also a direction in which we might want to steer 1.x. -Ted. On Sun, 29 Feb 2004 15:14:20 +, Niall Pemberton wrote: Ted, Whats happening with your Jericho proposal - I looked in the cvs/contrib and just saw the overview - is there anything more concrete anywhere else and are you still looking at pursuing this 'struts revolution'? Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Sunday, February 29, 2004 2:12 PM Subject: Re: 1.2.x and beyond (was Tagging and Freezing) On Fri, 27 Feb 2004 23:27:35 -0800, Craig R. McClanahan wrote: * Create a CVS branch for this release, which starts as a snapshot of the development tree when the release candidate is initially created, and allows the RM to incorporate whatever subsequent HEAD branch commits make sense (by either doing a CVS join or manually interpoLating the fixes). I'd be in favor of creating a branch for 1.2.x, so that we could finishing mavenising the HEAD, and be able to fixes to 1.2.x in the meantime. I believe that, as a result of the Maven initiative, we will also have multiple products/artifacts to distribute (struts-core, struts- opt-taglib, et cetera). If so, we could start each of these out at version 1.3.0, and then proceed from there with more aggressive enhancements (like Struts-Chain). So, the 1.2.x series (out there) is mainly about removing deprecations and refactoring existing features (like modules). Release 1.3.0 could be about repackaging the build for Maven and also doing the release subdividing that we've been talking about for some time now. Releases 1.3.1+ could then get back to the business of creating Struts [rather than just maintaining it] :) -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: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)
On Thu, 26 Feb 2004 10:54:49 -0800 (PST), Martin Cooper wrote: On Wed, 25 Feb 2004, Joe Germuska wrote: Perhaps this is understood, but I'm assuming that we also want to say that the RM owns the release tags for the release he or she is managing, and only the RM should *ever* move the tags? It's never been stated as such, but that's not a bad idea at all. I can't think of a good reason to move tags, other than to tweak things as part of the release process, and only the RM should be doing that. Now, where can we document this? ;-) http://jakarta.apache.org/struts/releases.html :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 is tagged and frozen
On Mon, 23 Feb 2004 11:23:08 -0800, Paul Sundling wrote: I should probably still remove author tags from the docs and consolidate those into the volunteers page also. I'm afraid that our volunteers page is subject to the same considerations as the author tags. :( * Low hanging suit. In the unlikely event of a law suit, this is a (very) convenient list of parties to join to the action. We may think it's silly, but it is what an attorney would do. Each of these people would then be responsible for having themselves severed from the suit. (Guilty until proven innocent, I'm afraid.) The ASF would do what they could, but resources are limited; we shouldn't tempt fate. * No strings attached. An important ASF principle is that all the code and documentation belong to the Foundation and its Community. Tags and other credits tend to imply some people own more of the resources than others. When a resource is donated to the foundation, we need to emphasize that it belongs to the Foundation, free and clear. * Duty now for the future. ASF projects are meant to live for decades. The current list is already lengthy. What will it look like ten years from now? How much of the contributions of those we list today will really be part of the product then? Tags and lists like these cannot be sustained for the full life of an Apache product. Sadly, we should probably trim the Who We Are page down to the list of Struts Committers who are members of the Jakarta PMC, since these individuals are the legal representatives of the Foundation. In this context, the Struts Committee Members would be presented as the decision-makers rather than the authors. (Technically, what we do is a work for hire, even though we are all unpaid volunteers.) Of course, we'd still give credit where credit is due via the CVS commits, if for no other reason than to retain an audit trail. Of course, a very ambitious attorney could still try to join everyone cited in the CVS log, but the CVS events are shielded by the Committers being the actors, and so it's a horse of a different color. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug in JavascriptValidatorTag
Yes, under the current process, there little reason to have a real freeze. It's more like a heads-up now. AFAIC, the codebase should not be considered frozen now, and people can start applying fixes to go into 1.2.1, including the license thing. The only reason we're not starting a vote on the quality of 1.2.0 is because of an ISP glitch. If 1.2.0 dies on the vine, then we can just roll 1.2.1 at any convenient juncture. -Ted. On Tue, 24 Feb 2004 15:13:38 -0600, Joe Germuska wrote: At 6:28 PM + 2/24/04, [EMAIL PROTECTED] wrote: Once a release is tagged that's it. We could retag and do 1.2.1, however there will probably be other things that need to be fixed. The point is to get 1.2.0 out the door and then see about making whatever fixes that need to happen. Well, if it's tagged, then I don't have to wait to commit the change; there's no need for a freeze, as you can always check out to the tag and use that to cut the release. No need to wait to apply the license patches either. (I will wait, however, until I'm sure other people see it the way I do.) Of course, it's possible to move CVS tags -- I assume you're just saying that you think that that's procedurally wrong? I'm not sure I agree, but I don't feel very strongly about it either. In fact, I'd much rather see 1.2.0 come out, with as few delays as possible. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 is tagged and frozen
On Tue, 24 Feb 2004 06:26:47 -0800, Paul Sundling wrote: Taking a step back, here is how some other projects are dealing with this issue: The example I'd be most willing to follow would be the one set by the httpd project: http://httpd.apache.org/contributors/ IMHO, these are the true giants around here :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 is tagged and frozen
On Sun, 22 Feb 2004 22:38:24 -0800 (PST), Martin Cooper wrote: Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? Following Craig's description of the Tomcat release approach (copy below), I'd say we should make an announcement to the Struts DEV and USER lists, with an URL leading to one of our home directories (or wherever Tomcat and others have been posting such things), but not the Jakarta announcement list. I imagine we'd now reserve the latter for a General Availability release that's being mirrored. Sorry if the taglib-exercise module is flaky. If it is, mea culpa. But once it's up there, we can still announce it, see if there is anything else we can fix, and then try again with 1.2.1. That would also give us a chance to apply that license patch. -Ted. On Tue, 16 Dec 2003 11:27:45 -0800, Craig R. McClanahan wrote: The Tomcat folks do indeed vote on every release -- they just do things in a little different order: * Post what amounts to a release candidate and announce to a limited audience (dev and user lists) asking for testing. * Testing ensues ... * Call a vote on the release, with the options to call it alpha, beta, stable (that's fine with me), or withdraw (if there was some bad problem). * Announce to the world and do the usual process of distributing the bits. The same approach would work for us, and IMHO meets the Jakarta requirements with one additional wrinkle -- the Jakarta PMC needs the opportunity to vote on releases as well, to be consistent with the current ASF reqirements. On Sun, 22 Feb 2004 22:38:24 -0800 (PST), Martin Cooper wrote: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts- examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release. Once I get the build uploaded, I'll ask other folks to take it for a spin before sending out an announcement. Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
Assuming it was all right with everyone, I'm setting the freeze date for 1.2.0 for tomorrow (Saturday) night. I'm updating the release plan. There are still a lot of enhancement patches that we haven't applied, but I think those can wait for later in the 1.2.x series. I do intend to start marching down that list and either accepting or declining whatever patches people have submitted. So, I'm commenting out that section for the purpose of this release. All the other criteria have been met, and I believe we are ready to go. Martin, would you be able to take it from there, or is there any thing else I can do? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/proposals release-plan_1_2_0.xml
husted 2004/02/20 06:41:23 Modified:doc/proposals release-plan_1_2_0.xml Log: Revise date, postpone remaining patches. Revision ChangesPath 1.8 +5 -7 jakarta-struts/doc/proposals/release-plan_1_2_0.xml Index: release-plan_1_2_0.xml === RCS file: /home/cvs/jakarta-struts/doc/proposals/release-plan_1_2_0.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- release-plan_1_2_0.xml16 Dec 2003 17:13:57 - 1.7 +++ release-plan_1_2_0.xml20 Feb 2004 14:41:23 - 1.8 @@ -15,10 +15,6 @@ /p p - THIS IS AN UNRATIFIED DRAFT DOCUMENT PROVIDED FOR DISCUSSION PURPOSES ONLY! - /p - - p The objective of the strongStruts 1.2.0/strong release is to provide an official version of all the changes that have been made to the main trunk of the jakarta-struts CVS since the release of Struts 1.1 Final. @@ -28,7 +24,7 @@ section name=The Plan href=plan p Since the release of version Struts 1.1 Final, we have removed many of the elements deprecated between - Struts 1.0 and Struts 1.1 and made several bug fixes and minor enhancements. + Struts 1.0 and Struts 1.1 and made several bug fixes and nominal enhancements. /p p @@ -37,7 +33,7 @@ ul li - emTag Date/em - Saturday, December 20, 2003, 23:59:59 + emTag Date/em - Saturday, February 21, 2004, 23:59:59 /li li emRelease Manager(s)/em - Ted Husted, Martin Cooper @@ -102,6 +98,7 @@ Bugzilla tickets/a verified by a Struts Committer to have the Severity BLOCKER, CRITICAL, or MAJOR must be Resolved with one of these Bugzilla resolutions: FIXED, INVALID, WONTFIX, WORKSFORME. /li + !-- li strongApply patches./strong Relevant @@ -115,6 +112,7 @@ /li /ul /li + -- li strongTest example applications./strong All example applications included with the release shall operate successfully under the - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc status.xml
husted 2004/02/20 06:47:01 Modified:doc status.xml Log: Routine update. Revision ChangesPath 1.59 +3 -3 jakarta-struts/doc/status.xml Index: status.xml === RCS file: /home/cvs/jakarta-struts/doc/status.xml,v retrieving revision 1.58 retrieving revision 1.59 diff -u -r1.58 -r1.59 --- status.xml14 Feb 2004 11:14:15 - 1.58 +++ status.xml20 Feb 2004 14:47:01 - 1.59 @@ -490,8 +490,8 @@ /section section -p class=versionWebsite updated from CVS: 2004 FEB 14 by husted./p -p class=versionJavadocs updated from CVS: 2004 FEB 14 by husted./p +p class=versionWebsite updated from CVS: 2004 FEB 20 by husted./p +p class=versionJavadocs updated from CVS: 2004 FEB 20 by husted./p /section /body/document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/validator FieldChecks.java
husted 2004/02/20 08:16:05
Modified:src/share/org/apache/struts/validator FieldChecks.java
Log:
Apply #26413 Indexed Field Date Validation Allows Invalid Dates submitted by Niall
Pemberton.
Revision ChangesPath
1.17 +93 -76
jakarta-struts/src/share/org/apache/struts/validator/FieldChecks.java
Index: FieldChecks.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/validator/FieldChecks.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- FieldChecks.java 10 Jan 2004 21:03:38 - 1.16
+++ FieldChecks.java 20 Feb 2004 16:16:05 - 1.17
@@ -296,9 +296,9 @@
[EMAIL PROTECTED] errors The codeActionMessages/code object to add errors
to if
*any validation errors occur.
[EMAIL PROTECTED] request Current request object.
- [EMAIL PROTECTED] A Byte if valid, null otherwise.
+ [EMAIL PROTECTED] true if valid, false otherwise.
*/
-public static Byte validateByte(Object bean,
+public static boolean validateByte(Object bean,
ValidatorAction va, Field field,
ActionMessages errors,
HttpServletRequest request) {
@@ -311,15 +311,17 @@
value = ValidatorUtils.getValueAsString(bean, field.getProperty());
}
-if (!GenericValidator.isBlankOrNull(value)) {
-result = GenericTypeValidator.formatByte(value);
+if (GenericValidator.isBlankOrNull(value)) {
+return true;
+}
-if (result == null) {
-errors.add(field.getKey(), Resources.getActionMessage(request, va,
field));
-}
+result = GenericTypeValidator.formatByte(value);
+
+if (result == null) {
+errors.add(field.getKey(), Resources.getActionMessage(request, va,
field));
}
-return result;
+return result == null ? false : true;
}
@@ -333,9 +335,9 @@
* @param errors The codeActionMessages/code object to add errors to if
* any validation errors occur.
* @param request Current request object.
- * @return A Short if valid, otherwise null.
+ * @return true if valid, false otherwise.
*/
-public static Short validateShort(Object bean,
+public static boolean validateShort(Object bean,
ValidatorAction va, Field field,
ActionMessages errors,
HttpServletRequest request) {
@@ -347,15 +349,17 @@
value = ValidatorUtils.getValueAsString(bean, field.getProperty());
}
-if (!GenericValidator.isBlankOrNull(value)) {
-result = GenericTypeValidator.formatShort(value);
+if (GenericValidator.isBlankOrNull(value)) {
+return true;
+}
-if (result == null) {
-errors.add(field.getKey(), Resources.getActionMessage(request, va,
field));
-}
+result = GenericTypeValidator.formatShort(value);
+
+if (result == null) {
+errors.add(field.getKey(), Resources.getActionMessage(request, va,
field));
}
-return result;
+return result == null ? false : true;
}
@@ -369,9 +373,9 @@
* @param errors The codeActionMessages/code object to add errors to if
any
* validation errors occur.
* @param request Current request object.
- * @return An Integer if valid, a null otherwise.
+ * @return true if valid, false otherwise.
*/
-public static Integer validateInteger(Object bean,
+public static boolean validateInteger(Object bean,
ValidatorAction va, Field field,
ActionMessages errors,
HttpServletRequest request) {
@@ -383,15 +387,17 @@
value = ValidatorUtils.getValueAsString(bean, field.getProperty());
}
-if (!GenericValidator.isBlankOrNull(value)) {
-result = GenericTypeValidator.formatInt(value);
+if (GenericValidator.isBlankOrNull(value)) {
+return true;
+}
-if (result == null) {
-errors.add(field.getKey(), Resources.getActionMessage(request, va,
field));
-}
+result = GenericTypeValidator.formatInt(value);
+
+if (result == null) {
+errors.add(field.getKey(), Resources.getActionMessage(request, va,
field));
}
-return result;
+return result
cvs commit: jakarta-struts/doc/userGuide release-notes.xml
husted 2004/02/20 08:35:17 Modified:doc/userGuide release-notes.xml Log: Update release notes. Revision ChangesPath 1.49 +3 -0 jakarta-struts/doc/userGuide/release-notes.xml Index: release-notes.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes.xml,v retrieving revision 1.48 retrieving revision 1.49 diff -u -r1.48 -r1.49 --- release-notes.xml 19 Feb 2004 21:09:45 - 1.48 +++ release-notes.xml 20 Feb 2004 16:35:17 - 1.49 @@ -434,6 +434,9 @@ strongValidator Package Changes/strong [ codeorg.apache.struts.validator/code]/p ul +li2004-02-20 - Changed FieldCheck so that it examines all indexed fields and does not stop on the first failure./li +/ul +ul li2004-01-17 - Changed initValidator() to accept an ActionMessages object instead of ActionErrors; changed ACTION_ERRORS_PARAM name to ACTION_MESSAGES_PARAM./li li2004-01-17 - Add section to Validator User Guide listing standard validations./li /ul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/proposals release-plan_1_2_0.xml
husted 2004/02/20 09:03:20 Modified:doc project.xml releases.xml status.xml doc/proposals release-plan_1_2_0.xml Log: Correct hyperlinks. Revision ChangesPath 1.47 +4 -4 jakarta-struts/doc/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-struts/doc/project.xml,v retrieving revision 1.46 retrieving revision 1.47 diff -u -r1.46 -r1.47 --- project.xml 6 Jan 2004 05:49:41 - 1.46 +++ project.xml 20 Feb 2004 17:03:19 - 1.47 @@ -86,16 +86,16 @@ menu name=Development item -name=CVS Repository -href=http://cvs.apache.org/viewcvs/jakarta-struts/; +name=Roadmap +href=status.html / item name=Release Guidelines href=releases.html / item -name=Roadmap -href=status.html +name=CVS Repository +href=http://cvs.apache.org/viewcvs/jakarta-struts/; / /menu 1.7 +6 -6 jakarta-struts/doc/releases.xml Index: releases.xml === RCS file: /home/cvs/jakarta-struts/doc/releases.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- releases.xml 13 Jan 2004 13:19:48 - 1.6 +++ releases.xml 20 Feb 2004 17:03:19 - 1.7 @@ -10,13 +10,13 @@ body section href=status name=Release Guidelines pThis document describes the Struts - a href=#Releasesrelease process/aand our + a href=#Releasesrelease process/a and our a href=#Codingcoding conventions/a. Both stable and development releases are a href=acquiring.htmlavailable for download/a./p /section section href=Releases name=Release Guidelines pA - a href=http://jakarta.apache.org/commons/versioning.html;point release/ashould be made before and after any product change that is not a fully-compatible change (see link). This includes moving a dependency from an internal package to an external product, including products distributed through the Jakarta Commons. We should place any fully-compatible changes in the hands of the community before starting on a change that is only interface or external-interface compatible./p + a href=http://jakarta.apache.org/commons/versioning.html;point release/a should be made before and after any product change that is not a fully-compatible change (see link). This includes moving a dependency from an internal package to an external product, including products distributed through the Jakarta Commons. We should place any fully-compatible changes in the hands of the community before starting on a change that is only interface or external-interface compatible./p pA fully-compatible point release does not always need a preview beta or milestone release. If appropriate, a Release Candidate can be cut, uploaded to the Release Manager's home directory on cvs.apache.org (~/public_html), and voted to be released to the general public from there./p pAny release should follow the same general process used by the Jakarta Commons and the Apache HTTP Server project./p ul @@ -52,7 +52,7 @@ liThere is a release target in the buildfile that will zip and tar the releases. Before uploading the release, extract the sample web applications and deploy the WARs under each of the supported containers. Play test each application under each container to be sure they operate nominally./li liBe sure to copy the [EMAIL PROTECTED] list on any release announcement./li liRemember to update the -a href=status.htmlStatus section of the Roadmap page/aonce a release is available./li +a href=status.htmlStatus section of the Roadmap page/a once a release is available./li liBy the way, the nightly builds are being created on a machine of Craig McClanahan's. If there are problems with a nightly build that seem infrastructure related, Craig is the one to contact./li /ul /section @@ -90,14 +90,14 @@ small// 78/small/li liPlease do your best to provide high-quality Javadocs for all source code elements. Package overviews (aka Developer Guides) are also encouraged./li liWhen working on a bugfix, please first write a -a href=http://www.junit.org;JUnit/atest that proves the bug exists, and then use the test to prove the bug is fixed. =:0)/li +a href=http://www.junit.org;JUnit/a test that proves the bug exists, and then use the test to prove the bug is fixed. =:0)/li liWhen
Re: [VOTE] 1.2.0 Release Plan
contrib Personally, I've been defining what is released by what is generated by the release target. :) For Struts 1.1, Struts-El was released coincident with the Struts 1.1 release, but they were separate events. If someone wants to also roll a struts-el release, or struts-jsf release, please proceed. But I wouldn't feel qualified to do that myself (since I'm not a user of those packages). Moving past 1.2.0, we might want to create a opt or optional products with their own release cycles, such as struts-opt-el, struts-opt-jsf, and struts-opt-taglib (for the rest). These could be their own Maven artifacts, each dependant on the struts-core project (being what is under share now). Likewise, we might want to setup a struts-apps product and distribute the bundled applications as artifacts of that. dependencies If there are new releases of some of our dependencies, then we should move to those. AFIAC, this should happen as soon as anyone is aware of a new final release. ASL 2.0 If someone wants to switch the licenses now, please feel free. But it's not something I would have time to do myself right now. Cactus I've never gotten the Cactus tests to run, so I don't even try anymore. If they aren't running, and no one can fix them, then we should take them out. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUMP@lsd]: jakarta-struts/jakarta-struts failed
In regard to http://lsd.student.utwente.nl/gump/jakarta-struts/jakarta-struts.html we are currently using LICENSE.txt rather than LICENSE. Is that a problem? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/conf/share struts-config_1_2.dtd
husted 2004/02/19 10:19:56 Modified:conf/share struts-config_1_2.dtd Log: Add module attribute to forward; deprecate contextRelative; remove deprecated dynamic attribute. Revision ChangesPath 1.7 +6 -12 jakarta-struts/conf/share/struts-config_1_2.dtd Index: struts-config_1_2.dtd === RCS file: /home/cvs/jakarta-struts/conf/share/struts-config_1_2.dtd,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- struts-config_1_2.dtd 1 Feb 2004 16:14:07 - 1.6 +++ struts-config_1_2.dtd 19 Feb 2004 18:19:55 - 1.7 @@ -135,7 +135,6 @@ typeFully qualified Java class to use when instantiating ActionFormBean objects. If specified, the object must be a subclass of the default class type. - DEPRECATED. WARNING: For Struts 1.0, this value is ignored. You can set the default implementation class name with the @@ -161,15 +160,6 @@ configuration bean. [org.apache.struts.config.FormBeanConfig] - dynamic If the form bean type is a DynaActionForm subclass (that you - created), then (and only then) set this attribute to true. - If the type is set to the default DynaActionForm or any - conventional ActionForm subclass, then this attribute can be - omitted. - [true] if type is org.apache.struts.action.DynaActionForm - [false] otherwise DEPRECATED - THIS IS NOW DETERMINED - DYNAMICALLY BASED ON THE SPECIFIED IMPLEMENTATION CLASS. - nameThe unique identifier for this form bean. Referenced by the action element to specify which form bean to use with its request. @@ -282,7 +272,6 @@ typeFully qualified Java class to use when instantiating ActionForward objects. If specified, the object must be a subclass of the default class type. - DEPRECATED. WARNING: For Struts 1.0, this value is ignored. You can set the default implementation class name with the @@ -310,8 +299,12 @@ attribute starts with a slash / and should be considered relative to the entire web application rather than the module. Since Struts 1.1. + DEPRECATED. [false] + module The module prefix to use with this path. This value should + begin with a slash (/). + nameThe unique identifier for this forward. Referenced by the Action object at runtime to select - by its logical name - the resource that should complete the request/response. @@ -333,6 +326,7 @@ !ATTLIST forwardid ID #IMPLIED !ATTLIST forwardclassName %ClassName; #IMPLIED !ATTLIST forwardcontextRelative %Boolean; #IMPLIED +!ATTLIST forwardmodule %RequestPath; #IMPLIED !ATTLIST forwardname CDATA #REQUIRED !ATTLIST forwardpath %RequestPath; #REQUIRED !ATTLIST forwardredirect %Boolean; #IMPLIED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/config ForwardConfig.java
husted 2004/02/19 10:45:05
Modified:src/share/org/apache/struts/config ForwardConfig.java
Log:
Deprecate contextRelative in favor of module.
Revision ChangesPath
1.13 +33 -4
jakarta-struts/src/share/org/apache/struts/config/ForwardConfig.java
Index: ForwardConfig.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/config/ForwardConfig.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ForwardConfig.java13 Feb 2004 11:07:54 - 1.12
+++ ForwardConfig.java19 Feb 2004 18:45:05 - 1.13
@@ -115,6 +115,7 @@
* @param path Path to which control should be forwarded or redirected
* @param redirect Should we do a redirect?
* @param contextRelative Is this path context relative?
+ * @deprecated Use module rather than contextRelative
*/
public ForwardConfig(String name, String path, boolean redirect,
boolean contextRelative) {
@@ -127,6 +128,25 @@
}
+/**
+ * Construct a new instance with the specified values.
+ *
+ * @param name Name of this forward
+ * @param path Path to which control should be forwarded or redirected
+ * @param redirect Should we do a redirect?
+ * @param module Module prefix, if any
+ */
+public ForwardConfig(String name, String path, boolean redirect,
+ String module) {
+
+super();
+setName(name);
+setPath(path);
+setRedirect(redirect);
+setModule(module);
+
+}
+
// - Instance Variables
@@ -144,13 +164,20 @@
* Should the value of the codepath/code property be considered
* context-relative if it starts with a slash (and therefore not
* prefixed with the module prefix?
+ * @deprecated Use module property instead; will be removed in a release
following 1.2.0.
*/
protected boolean contextRelative = false;
+/**
+ * @deprecated Use module property instead; will be removed in a release
following 1.2.0.
+ */
public boolean getContextRelative() {
return (this.contextRelative);
}
+/**
+ * @deprecated Use module property instead; will be removed in a release
following 1.2.0.
+ */
public void setContextRelative(boolean contextRelative) {
if (configured) {
throw new IllegalStateException(Configuration is frozen);
@@ -273,6 +300,8 @@
sb.append(this.redirect);
sb.append(,contextRelative=);
sb.append(this.contextRelative);
+sb.append(,module=);
+sb.append(this.module);
sb.append(]);
return (sb.toString());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/examples/exercise html-img.jsp html-link.jsp
husted 2004/02/19 10:45:43 Modified:web/examples/WEB-INF/exercise struts-config.xml web/examples/exercise html-img.jsp html-link.jsp Log: Expand module/contextRelative tests/examples. Revision ChangesPath 1.9 +2 -3 jakarta-struts/web/examples/WEB-INF/exercise/struts-config.xml Index: struts-config.xml === RCS file: /home/cvs/jakarta-struts/web/examples/WEB-INF/exercise/struts-config.xml,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- struts-config.xml 19 Feb 2004 00:09:37 - 1.8 +++ struts-config.xml 19 Feb 2004 18:45:42 - 1.9 @@ -13,12 +13,11 @@ global-forwards forward name=absolute path=http://jakarta.apache.org/struts; / forward name=context-relative path=/welcome.do contextRelative=true / +forward name=module-root path=/welcome.do module= / +forward name=module-validator path=/welcome.do module=/validator / forward name=relative path=/welcome.do / forward name=redirect-default path=/ redirect=true / forward name=logic-forward path=/logic-forward.do / - !-- -forward name=cross-module module= path=/welcome.do / - -- /global-forwards action-mappings action path=/welcome forward=/index.html / 1.4 +8 -0 jakarta-struts/web/examples/exercise/html-img.jsp Index: html-img.jsp === RCS file: /home/cvs/jakarta-struts/web/examples/exercise/html-img.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- html-img.jsp 19 Jan 2004 04:43:10 - 1.3 +++ html-img.jsp 19 Feb 2004 18:45:43 - 1.4 @@ -40,5 +40,13 @@ html:img page=/exercise/struts-power.gif contextRelative=true/ /td /tr +tr +td +Struts img tag via page attribute, default module +/td +td +html:img page=/exercise/struts-power.gif module=// +/td +/tr /body /html 1.4 +7 -1 jakarta-struts/web/examples/exercise/html-link.jsp Index: html-link.jsp === RCS file: /home/cvs/jakarta-struts/web/examples/exercise/html-link.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- html-link.jsp 13 Feb 2004 11:07:55 - 1.3 +++ html-link.jsp 19 Feb 2004 18:45:43 - 1.4 @@ -162,7 +162,13 @@ html:link forward=relativemodule welcome page/html:link /li li -html:link forward=context-relativeapplication welcome page/html:link +html:link forward=context-relativeapplication welcome page (context relative attribute)/html:link + /li + li +html:link forward=module-rootapplication welcome page (module attribute)/html:link + /li + li +html:link forward=module-validatorvalidator welcome page/html:link /li li html:link forward=absoluteStruts website/html:link - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/conf/share validator-rules_1_1.dtd validation_1_1.dtd
husted 2004/02/19 12:37:55 Removed: conf/share validator-rules_1_1.dtd validation_1_1.dtd Log: Remove deprecated resources. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide release-notes.xml
husted 2004/02/19 12:38:37 Modified:doc/userGuide release-notes.xml Log: Add module blurb; grammar/markup. Revision ChangesPath 1.47 +83 -80jakarta-struts/doc/userGuide/release-notes.xml Index: release-notes.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes.xml,v retrieving revision 1.46 retrieving revision 1.47 diff -u -r1.46 -r1.47 --- release-notes.xml 16 Jan 2004 05:34:50 - 1.46 +++ release-notes.xml 19 Feb 2004 20:38:37 - 1.47 @@ -5,93 +5,92 @@ authorRobert Leland/author authorTed Husted/author authorMartin Cooper/author -titleStruts Release Notes (Nightly Build)/title +titleStruts Release Notes (since 1.1)/title /properties body section name=Introduction href=Introduction -pThis section contains release notes for -strongnightly build/strongof the Struts Framework, for changes that have taken place since -a href=release-notes-1.1.htmlVersion 1.1/awas released./p +pThis section contains release notes for changes that have taken place since +a href=release-notes-1.1.htmlVersion 1.1/a was released./p /section section name=What's Included? href=Included pThe binary distribution of this release includes the following files relevant to Struts:/p ul li - codeINSTALL.txt/code- Brief installation instructions. For more detail, see the + codeINSTALL.txt/code - Brief installation instructions. For more detail, see the codeStruts User Guide/code, either through the Struts Documentation application or online at a href=http://jakarta.apache.org/struts/;http://jakarta.apache.org/struts//a./li li - codeLICENSE.txt/code- The Apache Software Foundation license that defines the terms under which you can use Struts (and other software licensed by Apache)./li + codeLICENSE.txt/code - The Apache Software Foundation license that defines the terms under which you can use Struts (and other software licensed by Apache)./li li - codeREADME.txt/code- A brief introduction to Struts./li + codeREADME.txt/code - A brief introduction to Struts./li li - codecontrib//code- Additional libraries developed by the Struts team which are not yet part of the core distribution./li + codecontrib//code - Additional libraries developed by the Struts team which are not yet part of the core distribution./li li - codelib//code- Directory containing files you will need in your own applications. The individual files of interest are: + codelib//code - Directory containing files you will need in your own applications. The individual files of interest are: ul li -codeantlr-#.#.jar/code- ANTLR, ANother Tool for Language Recognition, a public domain library made available by +codeantlr-#.#.jar/code - ANTLR, ANother Tool for Language Recognition, a public domain library made available by a href=http://www.antlr.org/;antlr.org/a./li li -codecommons-*-#.#.jar/code- Various packages from the -a href=http://jakarta.apache.org/commons/;Jakarta Commons Project/athat Struts relies on. You are welcome to use these classes in your own applications. These JAR files should be copied into the -code/WEB-INF/lib/codedirectory of your web application./li +codecommons-*-#.#.jar/code - Various packages from the +a href=http://jakarta.apache.org/commons/;Jakarta Commons Project/a that Struts relies on. You are welcome to use these classes in your own applications. These JAR files should be copied into the +code/WEB-INF/lib/code directory of your web application./li li -codejakarta-oro-#.#.jar/code- JAR file containing the Jakarta ORO package, utilitied by the Struts Valdiator. You must place this file in the -code/WEB-INF/lib/codedirectory of your web application to use the Struts Validator package./li +codejakarta-oro-#.#.jar/code - JAR file containing the Jakarta ORO package, utilitied by the Struts Valdiator. You must place this file in the +code/WEB-INF/lib/code directory of your web application to use the Struts Validator package./li li -codestruts-#.#.jar/code- JAR file that contains the compiled Java classes of Struts. You must place this file in the -code/WEB-INF/lib/codedirectory of your web application./li +codestruts-#.#.jar/code - JAR file that contains the compiled Java classes of Struts. You must place this file in the +code/WEB-INF
