Re: Refactoring Struts Initialization (was RE: Splitting struts-config into multiple jar...)
Craig R. McClanahan wrote: snip / I personally believe that, even if we implemented dynamic reconfiguration support for the config files themselves, developers will be disappointed in how little this helps in a development cycle -- you're not going to pick up added or changed Java classes without a container-managed restart of the webapp (except on *some* containers where you haven't yet loaded the class in question), so typical development use cases like add the next Action are going to require restarts anyway. True, however that is only if your actions are Java classes. I've developed Struts apps using scripting languages, particularly BeanShell, to get a quick prototype of the application up and running. Later, I can easily change those scripts to Java classes if there is need. For Struts to detect a configuration file change and automatically reload the config, as Cocoon can do (can be turned off of course), would go a long way to make it possible to quickly develop/prototype Struts applications. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new Struts features/sub-projects (was [Bug 28609] - Scriptable Actions Support)
I think it goes without saying I'd be on the list, but just in case... :) So, in this scripting subproject, could this perhaps someday host a continuations-based scripting flow implementation? Dave Johnson has been doing some good work pulling Cocoon's flow out of Cocoon and I think a Struts port would be a great asset for developing complex wizard-style workflows. Normally, I'd get something working then add it to the Struts SF project, but with a whole scripting subproject, perhaps it might be more relevant there. BTW, I really like the guidelines Steve was working on and recommend we polish them up and post them on our site to make the distinctions clear to everyone. Specific mention of the SF site's role in Struts development would be very helpful as well. Don Joe Germuska wrote: I'd be happy to be one of the Committers named on a proposal to create a scripting subproject. You can add me to that list. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-docu
Thanks, good catch, but next time, please submit a bug ticket to make sure it gets tracked. Don Matthias Wessendorf wrote: Hello, i just saw on struts-homepage (wildcard-mapping-section), http://jakarta.apache.org/struts/userGuide/building_controller.html#acti on_mapping_wildcards that there is NO entry for 'name'-attribute for xml-element *action* but it is possible to use name for formBean-entries with wildcard-stuf. indeed, there is this: The action mapping attributes that will accept wildcard-matched strings are: * type * roles * parameter * attribute * forward * include * input * forward * forward cheers, Matthias Weßendorf Aechterhoek 18 D-48282 Emsdetten Email: mailto:[EMAIL PROTECTED] URL: http://www.wessendorf.net - 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]
Validator Design Questions
With the validator as a constant source of hangups, I'm working on becoming more familiar with how it works. I have some questions, perhaps rather basic and obvious: Why does Struts perform all its validation with o.a.s.v.CheckFields? It seems it duplicates a most of commons-validator's, well, validators. Why not process the ValidationResults after validator.validate() to create the necessary ActionMessages and use commons-validator's existing validators? This might more just validator specific, but why is there no facility to provide the validator an already existing instance of a Validator (or if there is, where is it)? It seems the only options are to create a Validator with static methods or a no arg constructor. I think it would be valuable to let Spring manage more complex validators that rely on business objects, and re-use those validators with Struts. Or, perhaps you want a method on one of your existing business objects to be called for validation. Thanks for the help, Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validator Design Questions
Ok, good, then there is nothing obvious I'm missing. I think it would be a good goal for Struts to use validator completely and not require its own validators, and I will look into that. As for the loading of validators, yes, I'll take that over to commons-dev. Don David Graham wrote: --- Don Brown [EMAIL PROTECTED] wrote: With the validator as a constant source of hangups, I'm working on becoming more familiar with how it works. I have some questions, perhaps rather basic and obvious: Why does Struts perform all its validation with o.a.s.v.CheckFields? It seems it duplicates a most of commons-validator's, well, validators. Why not process the ValidationResults after validator.validate() to create the necessary ActionMessages and use commons-validator's existing validators? This might more just validator specific, but why is there no facility to provide the validator an already existing instance of a Validator (or if there is, where is it)? It seems the only options are to create a Validator with static methods or a no arg constructor. I think it would be valuable to let Spring manage more complex validators that rely on business objects, and re-use those validators with Struts. Or, perhaps you want a method on one of your existing business objects to be called for validation. The original design was for all validations to be loaded from an xml file into a ValidatorResources object that Validator objects use against beans/forms. I don't think adding resources at run time was considered. The active validator team is really just Rob and me at this point so your input is much appreciated. We should probably continue the discussion on commons-dev though. David Thanks for the help, Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer - 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: Validator Design Questions
I'm not understanding your objection. I was suggesting that Struts need not duplicate validation implementation code also found in commons-validator, but instead retrieve validation errors from ValidatorResults. This recommendation changes implementation details, yes, but the user would not be affected, and if anything, their experience would be simplier for creating new Validators as they would be more re-useable outside Struts. Don Edgar P Dollin wrote: I for one would never use struts validator as it is currently constituted and to be required to use it would cause me to drop using struts. Please rethink this idea. Thanks Edgar -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Friday, May 21, 2004 12:46 PM To: Struts Developers List Subject: Re: Validator Design Questions Ok, good, then there is nothing obvious I'm missing. I think it would be a good goal for Struts to use validator completely and not require its own validators, and I will look into that. As for the loading of validators, yes, I'll take that over to commons-dev. Don --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.688 / Virus Database: 449 - Release Date: 5/18/2004 - 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: Struts Web Services Enablement Project
Frank Zammetti wrote: Don, I'd be lieing if I said I understood all of what you said. If I'm getting it at all though, I think the basic point, correct me if I'm wrong, is that since one of the limitations of my package is that the incoming request has to be flat in form, you are suggesting a way to allow for translation of a more complex XML form into a flat one that can then be parsed for parameters, is that correct? Yes, as already confirmed. One area where web services are used is standardizing how multiple applications can retrieve the same type of data from different servers. For example, if you have multiple servers that produce gridded weather data, all the data producers could get together and define a common XML schema for requesting data from their servers that they all implement. This way, clients can use different data providers interchangably. This XML schema standardization is a very fluid process that can be subject to many changes. It is easiest if your application is as isolated as possible from the actual XML schema. On the output side, I think your saying allow for much the same thing, all in a plugable fashion... but I think I do already allow for that which the release of .02 by allowing for mapping to a JSP that knows the specifics of a given ActionForm and can therefore render a more complex response if need be. Are you suggesting a more elegant way to do basically that? The problem with just using a JSP is you need to write a JSP for each action. If you use auto-generated XML, you can define a smaller number of XSL stylesheets to match common XML elements for transformation. Furthermore, the pipeline approach allows you to break up the transformation process to support transformation stages that may involve more complex processing. I'm not familiar with much of the technologies you names, XPath I think is the only one I know something about, so I'd have a lot of learning to do before I could implement your suggestions (which is not at all a bad thing!). I am going to look at the struts-chain this weekend though since a number of people have made the same suggestion. It doesn't sound like a huge change on the surface, so it seems like a good next task to tackle to me. One question: that facility is not avalable in 1.1, correct? Is it slated for 1.2 (I thought I saw someone else say 1.3?). I'm a little bid weary of changing this to something that will reduce how many people could possibly use it, but if it's not a major change like I suspect then supporting both probably isn't a problem either. While struts-chain won't be incorporated into Struts until probably 1.3 (but could be somewhere in 1.2), it is still available to be used with Struts 1.1. Since you are requiring a custom request processor anyways, just use the struts-chain request processor and refactor your capabilities into multiple commands instead of extended RequestProcessor methods. The burden on your users will be about the same and the transition to future Struts will simply require you to discontinue the specific use of the chain's legacy RequestProcessor. Your function code will already be in commands that are already compliant. Good job with what you've put together so far. I think this extension is a great addition to the toolbox available to Struts developers. Don Thanks! Frank From: Don Brown [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts Web Services Enablement Project Date: Fri, 04 Jun 2004 12:14:16 -0400 I think there can be considerable benefit from exposing Struts Actions. For one, how Struts is currently architected, all the validation happens in the Struts layer so putting the web service interface in front of that makes sense. Two, many times user authorization occurs in the Actions and so if this code hooked into the Servlets API, authorization is automatically taken care of. I'd recommend two feature additions to make this useable for document style SOAP messaging: 1) Put a configurable XML transformation pipeline before the SOAP message gets interpreted for parameters, and after the response is created. The pipeline for the response should start with auto-generated request XML (via something like XStream). 2) Improve the request parameter schema for the incoming XML document to include XPath paths as parameter names. This way, using something like JXPath, a complex XML element could be automatically created, to be then transformed by the pipeline. Send the resulting XML to the action via a wrapper action form or even just put it in the request. Better yet, have the resulting XML be processed by an XML binding framework like XStream to create arbitrary Java objects to be passed to the action. The key is to enable any XML schema to be used as input and output. The XML pipeline further isolates you from schema changes
Re: Struts Web Services Enablement Project
likely. But again, it your doing something like that, I suspect you'd have decided against my little package already! Again I think this is somethng that I can see where the benefit comes in, but probably baloons the complexity again. I can concieve of this project expanding as time goes on to more compete with the more developed packages out there now, but I feel like that's a much more long-term goal than what I'm trying to accomplish now. While struts-chain won't be incorporated into Struts until probably 1.3 (but could be somewhere in 1.2), it is still available to be used with Struts 1.1. Since you are requiring a custom request processor anyways, just use the struts-chain request processor and refactor your capabilities into multiple commands instead of extended RequestProcessor methods. The burden on your users will be about the same and the transition to future Struts will simply require you to discontinue the specific use of the chain's legacy RequestProcessor. Your function code will already be in commands that are already compliant. That sounds good, I will definitely look into doing it this weekend. Your comments above alay whatever fears I might have had, it sounds like the right thing to do overall, and not a massive change either. Good job with what you've put together so far. I think this extension is a great addition to the toolbox available to Struts developers. Thank you, I'm very glad to hear the positive feedback I've gotten, and just as happy that people are interested enough to at least make suggestions and question what I'm doing. Any comments, regardless of what side of the fence they are on or if/when I act on things is valuable. I was concerned that I was the only one that thought this might be something useful, but it sounds like I'm not alone, and that certainly motivates me to develop it further. Don Thanks! Frank From: Don Brown [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts Web Services Enablement Project Date: Fri, 04 Jun 2004 12:14:16 -0400 I think there can be considerable benefit from exposing Struts Actions. For one, how Struts is currently architected, all the validation happens in the Struts layer so putting the web service interface in front of that makes sense. Two, many times user authorization occurs in the Actions and so if this code hooked into the Servlets API, authorization is automatically taken care of. I'd recommend two feature additions to make this useable for document style SOAP messaging: 1) Put a configurable XML transformation pipeline before the SOAP message gets interpreted for parameters, and after the response is created. The pipeline for the response should start with auto-generated request XML (via something like XStream). 2) Improve the request parameter schema for the incoming XML document to include XPath paths as parameter names. This way, using something like JXPath, a complex XML element could be automatically created, to be then transformed by the pipeline. Send the resulting XML to the action via a wrapper action form or even just put it in the request. Better yet, have the resulting XML be processed by an XML binding framework like XStream to create arbitrary Java objects to be passed to the action. The key is to enable any XML schema to be used as input and output. The XML pipeline further isolates you from schema changes. Finally, I'd also recommend looking at using struts-chain rather than a RequestProcessor. If the above functionality was decomposed into different Commands, one could easily plug in, say, a different XML binding framework or get rid of the XPath processor altogether. Don Duncan Mills wrote: Didn't mean to be harsh - I was just presenting the alternative viewpoint that has to be answered. Personally I can see the benefit that this project could offer, but the counter stance is a one to raise is it not? Regards Duncan Mills Senior Principal Product Manager Oracle Application Development Tools Jung, Eric wrote: Wow, that's kind of harsh, Duncan. -Original Message- From: Duncan Mills [mailto:[EMAIL PROTECTED] Sent: Friday, June 04, 2004 3:38 AM To: Struts Developers List Subject: Re: Struts Web Services Enablement Project Frank forgive me here, but playing Devils Advocate, if you have clean MVC separation then surely the last thing you want to do is to expose Actions as Web Services. It is reasonable to want to expose Business Service Providers such as EJB, or TopLink beans as Web Services but that's up in the model layer, what's the point in pushing the access point down into the Controller code? Or do you see here a solution for all those folks who've not followed best practice and have intermingled Controller functionality with Business logic..? Regards Duncan Mills Senior Principal Product Manager Oracle Application Development Tools
Re: Struts Web Services Enablement Project
What about starting a sub-project on struts.sf.net? Let the features and stability mature, then if people are using it, talk about migrating it to be a sub-project for Struts. Don Frank Zammetti wrote: That's exactly what my approach is now Ted. But, I've been seeing a lot of suggestions that I think would move this thing to the next level of complexity, and I didn't want to seem like I was ignoring anyone by continuing what I'm doing. I'm definitely listening to what everyone has to say and considering it all, even those things that I don't immediately understand I'm trying to research to see if it really fits in with the goals I had when I started. But if there really is an underlying current of wanting to do a true Web Service component to Struts, I'm not so sure what I'm doing ever could be the foundation for that, so I wanted to raise the idea of starting a more official project now with that express goal. Frank From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts Web Services Enablement Project Date: Mon, 7 Jun 2004 12:25:00 -0400 I'd suggest sticking to your original vision, Frank, and first do the simplest thing that can possibly work. Try it for 1.2.x as well as for the Struts-Chain request processor that is slated for 1.3.x, to be sure the approach will be forwardly compatible, and get it out there where people can try it. It will probably be more useful with the Strut-Chain RP, since there will be conflicts with the other custom RPs that are popping up. If what you start works, and other people use it, then, sure, it could become the kernel of a Struts Web Services subproject. That's how Tiles, Validator, declarative exception handling, and declarative security all started. But, first things first, build something that suits the needs of your own application, and then we can see what patches people offer up. -Ted. On Sun, 06 Jun 2004 19:38:51 -0400, Frank Zammetti wrote: You raise some good points, as have a lot of people on the list. I keep coming back to the same bottom-line point though... Most of the suggestions get into something alot bigger than I started with, and that's a good thing, but I'm not sure I'm ready to tackle it myself yet. I think the one underlying point that is coming through is that there seems to be a desire, maybe even a need, for a real Web Service capability built in to Struts. There's been a lot of different ideas about what form it should take, what capabilities are important, and how it should ultimately be implemented. If for no other reason, I think bringing that point to light (if it wasn't already!) was a good result of my little project. But, when I examine where I am now, how I've personally chosen to do things, and I ask the question of whether I think it could really be the basis for a grander vision, I think I lean towards the answer being no. I think I've put forth a couple of decent ideas, maybe shown people a way to do things that is if not original than maybe not a common method, but I don't for a second think it's the be-all and end-all of Web Services in Struts, and I suspect it probably never could be. So, in the short-term, my little package can probably be useful to some folks, and that's cool. Over a relatively short period of time I can probably expand it and polish it so it's useful to even more people, and maybe even be useful enough and polished enough to be included in the Struts distro at some point. But to turn into a whole generally useful to everyone Web Service component of Struts? My gut says no, so I'm a bit hesitant to start down that road, especially considering how much I frankly have to learn myself to go down that road. What I do wonder though is if we're coming to a point where maybe we can get some people together and start a Struts sub-project (or whatever the proper terminology would be) to really do something more capable? I don't think I can pull off something like that alone, not short-term anyway, but I'd certainly be interested in being a part of such an effort. So, does anyone else see that as a viable thing to do, and if so, how do we go about actually doing it? Frank From: robert burrell donkin [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts Web Services Enablement Project Date: Sun, 6 Jun 2004 08:54:26 +0100 On 4 Jun 2004, at 22:56, Frank Zammetti wrote: snip After that, I'm thinking that a .04 release maybe a week later seems reasonable, and with that my main goal is implementing the pre- and post-transformations suggested here. I haven't thought this through yet entirely, but what I think this amounts to is not much more than adding an xslt-in and xslt-out attributes to the mappings in webservices-config.xml that, if present will
RE: Struts 1.2.1 release?
I vote we just roll it anyways. If we have switched to tomcat-style releases, we can just not label it as stable. I asked one of the tomcat guys last nite at the JakartaOne party if they close out all their bugs and he laughed :) Don So, if we can solve 29285, it looks like 1.2.1 would be ready to roll. On Fri, 25 Jun 2004 22:27:39 -0400, Ted Husted wrote: OK, we're down to 4 problem tickets. Two are against the validator, but patches are not available. Two are against Struts-Faces, and could actually be skipped since Struts-Faces would not be in the 1.2.1 release. The release notes are updated, so if we can swat #29285 and #29796, we could try rolling Struts 1.2.1. I'll be away through Thursday. I may have email, but don't know if the connection would be good enough to try and roll a release. If anyone want to jump in, please feel free. -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]
Simplifying Struts
With my extra day off today, I took a look at ways to simplify Struts. Having been impressed by the simplicity of NanoWeb, I particularly looked at ways to change the Struts concept of Actions and ActionForwards to support POJO's and configurations that allow new actions to be written without requiring any changes to struts-config.xml. I described my findings in my weblog: http://www.jroller.com/page/mrdon/20040706#zero_configuration_with_struts What does the Struts developer community think of providing direct support for regular JavaBeans as actions? One feature of JSF I liked was how actions were simply no-arg methods on a JavaBean, making them easy to write and test. Incidently, I built my extension off struts-chain, so it works side-by-side regular Struts actions, forwards, and forms. With commons-chain out of the sandbox and Struts 1.2.1 around the corner (thanks Ted), I think it is time to start integrating struts-chain into the core. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.2.1 Alpha, Beta, or GA? (was Re: Struts 1.2.1 release)
+1 on Struts 1.2.2 Ted Husted wrote: We've only had a very few, very light tickets since the release of Struts 1.2.1 Beta. I'd like to propose that we tag and release Struts 1.2.2 on Monday and post it for a quality vote. Please note that we can vote a release directly from Alpha to GA, if that's how we feel about 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]
Re: JIRA Conversion (was RE: patch to make sure streams get closed)
+1 for JIRA migration David H. DeWolf wrote: If I'm not mistaken, the process of migrating to JIRA is one that is completed by infrastructure. From my experience with other projects, infrastructure has been very timely in getting the conversions completed once they are requested through JIRA (see issues INFRA-74, INFRA-99, INFRA-104, etc. . .). If the Struts community is in favor of migrating to Jira, I would be happy to spearhead the process. While I will need a little cooperation from the committers (things like voting on whether or not to migrate!), I think the rest is simply interaction with the infrastructure team. Please let me know if you'd like me to move forward with this or if you assessment of what is required is different. I believe the following is the information I would need to submit to the Infrastructure team: JIRA Issue Name: Migrate Struts to JIRA Jira Issue Description: Please migrate the Struts from Bugzilla to JIRA. The Struts community would like to keep all history. We believe that we have listed all of the information you need to complete the migration below: Project Name: STRUTS Project Lead: Craig R. McClanahan, (craigmcc at apache.org) Project Abbreviation: STRUTS Project Administrators: (All Committers) Project Committers (jira id): * 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) * Niall Pemberton (niallp at apache.org) -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 25, 2004 12:07 PM To: Struts Developers List Subject: Re: patch to make sure streams get closed On Wed, 25 Aug 2004 11:33:47 -0400, [EMAIL PROTECTED] wrote: Sorry it was a tongue-in-cheek-somewhat-cranky-reaction to how completely overengineered bugzilla is for submitting patches. I found it more difficult than finding, fixing, diffing the patch. Unfortunately, unless someone volunteers to migrate our Bugzilla database to Jira, there's nothing to be done about it. We can't accept attachments because of the spammers, and patches pasted into emails are virtually impossible to apply. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Release quality for Struts 1.2.2
+1 David Graham wrote: +1 David --- James Mitchell [EMAIL PROTECTED] wrote: I have finished rolling the 1.2.2 release. The acquiring page has been updated with the 1.2.2 release. http://struts.apache.org/acquiring.html I am +1 for making this GA. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush - 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: [ANN] Struts 1.2.2 release is now available for download.
Has the home page's download links been updated yet? They still point to jakarta's download page which only has the 1.1 release. Congrats James, Ted, Martin, et al on the release. :) Don James Mitchell wrote: The Apache Struts team is extremely proud to announce the availability of Struts 1.2.2. This release represents the first official release available for General Availability since Struts 1.1. You can find all of the features, enhancements, and bug fixes in the release notes listed below. I would personally like to send a big _THANK YOU_ to all the users and developers who help make this community project possible and an even bigger _THANK YOU_ to the developers and committers who volunteer their time and talents to this (as well as other) Open Source project. Pat yourselves on the back, you are doing a stellar job Release notes: http://struts.apache.org/userGuide/release-notes.html You can access the binary, source, or library distributions from any of our mirrors http://struts.apache.org/download.cgi The Apache Struts Team -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - 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]
Subversion?
Last I heard, Ted setup a test subversion repository and everyone seemed happy with it. Is there anything stopping plans to go ahead and migrate our CVS repository? I've recently setup several subversion installations and am willing to do whatever it takes to get Struts migrated. Let me know if this is still desired and what I can do to help. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS - SVN / Roadmap
Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - 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: CVS - SVN / Roadmap
I don't mind making those CVS to SVN documentation updates today. One question though, are we assuming people checked Struts trunk out or the entire Struts repository? This affects whether we refer to a file as trunk/build.xml or just build.xml. Don Martin Cooper wrote: On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] wrote: Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? Yes, we should wait for Ted's updates. We do need to get the docs switched over to talk about SVN rather than CVS. -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability
Re: CVS - SVN / Roadmap
All that should remain is updating the roadmap, which I'll leave to folks more involved in the roadmap discussions. If there is anything else, let me know and I'll do it. Don Craig McClanahan wrote: If you just refer to build.xml the docs should apply to a branch as well as they apply to the trunk. But it's worth mentioning trunk in the context of what URL you use to check out the repository in the first place. Craig On Thu, 14 Oct 2004 12:23:42 -0700, Don Brown [EMAIL PROTECTED] wrote: I don't mind making those CVS to SVN documentation updates today. One question though, are we assuming people checked Struts trunk out or the entire Struts repository? This affects whether we refer to a file as trunk/build.xml or just build.xml. Don Martin Cooper wrote: On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] wrote: Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? Yes, we should wait for Ted's updates. We do need to get the docs switched over to talk about SVN rather than CVS. -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha
Re: Status: 1.2.5
+1 for $Id$ Joe Germuska wrote: At 10:13 PM -0400 10/15/04, James Mitchell wrote: What I need: --- Can someone put together a perl/python/shell/whatever script that can iterate over the entire repository and replace all of our cvs keywords with svn appropriate ones? I can do this, but a quick googling didn't turn up any specifics on what the change should be. I believe some recent discussion about replacing all keyword tags with just $Id$ had no strong opponents and a few in favor -- does SVN use the same syntax? I can do the search/replace/commit using BBEdit in ten or fifteen minutes, tops as soon as I get a few confirmations... Joe -- Joe Germuska[EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] CVS to Subversion Conversion Wednesday
If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
Sorry, I should have clarified, I'm giving the go-ahead on performing the actual conversion the exactly same way the test conversion was done - the full conversion. All branches and tags will be converted. After the conversion, we can delete/move as necessary. Don Craig McClanahan wrote: On Mon, 27 Sep 2004 21:40:45 -0700, Don Brown [EMAIL PROTECTED] wrote: If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) So, are we planning to keep all the existing tags and branches, or do selective pruning? Unless the SVN equivalent of cvs log maintains the entire history on all affected files, I'm -1 on pruning anything unless the infrastructure team says we're being too demanding on disk space. Don Craig - 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: [ANN] CVS to Subversion Conversion Wednesday
Martin Cooper wrote: On Mon, 27 Sep 2004 21:40:45 -0700, Don Brown [EMAIL PROTECTED] wrote: If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) My questions have been resolved to my satisfaction, so +1 from me. I assume you'll ask that the CVS repo be frozen at the same time. We should probably say that no CVS commits should happen after Tuesday, to make sure nothing gets lost. Yes, the freezing of CVS will occur before the conversion by the infrastructure team. They will ensure no commit gets lost. Don -- Martin Cooper Don - 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: [ANN] CVS to Subversion Conversion Wednesday
I'll also take this opportunity to remind everyone who hasn't set their subversion password to do so: http://www.apache.org/dev/cvs2svn.html (step 10). 10. Users who haven't used Subversion before need to log into minotaur.apache.org and run the svnpasswd utility to set their Subversion password. Don Craig McClanahan wrote: On Mon, 27 Sep 2004 22:10:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Sorry, I should have clarified, I'm giving the go-ahead on performing the actual conversion the exactly same way the test conversion was done - the full conversion. All branches and tags will be converted. After the conversion, we can delete/move as necessary. Ah, so ... in that case +1. As Martin suggests, I presume we'll want to freeze the CVS version of the repository at the start of the process. Don Craig (who is also updating all his local copies of the CVS repository :-) - 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: [ANN] CVS to Subversion Conversion Wednesday
I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don Sean Schofield wrote: I'm trying to download from the subversion (anonymously) and I keep getting a 501 Not Implemented error. I'm typing the URL correctly and this does not work for any of the projects (including Struts). Could this be something to do my firewall at work? Does subversion use something other than port 80 to communicate? sean - 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: [ANN] CVS to Subversion Conversion Wednesday
Port 80, just like any other web server. Committers will use 443 (SSL) for authentication. Don Greg Reddin wrote: CVS in pserver mode connects over port 2401. Does anyone know what port svn uses? Thanks, Greg Sean Schofield wrote: Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - 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: [ANN] CVS to Subversion Conversion Wednesday
Subversion can actually be exposed multiple ways. One such way is to use its built-in svnserve server which does listen over 3690. Subversion can also be exposed via WebDAV as an Apache 2.0 module. In the latter case, it can listen at any port Apache is configured to listen on, usually 80 and/or 443. Apache Software Foundation's Subversion server, svn.apache.org, does in fact use the Apache WebDAV module and listens at 80 for non-authenticated users, and 443 for authenticated users (usually committers). svnserve and port 3690 are not used at all. Don Salvador Trujillo Gonzalez wrote: On Tue, 28 Sep 2004, Greg Reddin wrote: CVS in pserver mode connects over port 2401. Does anyone know what port svn uses? It uses 3690, Salva Thanks, Greg Sean Schofield wrote: Yes. I think the problem must be my firewall at work. I have the same problem accessing CVS from work as well. The client must be requiring something over a port that is blocked. My guess is that the clien is interpreting a refused connection as the server not being available. Thanks, sean I just checked it out over http and everything worked correctly. Are you sure you are hitting http://svn.apache.org/repos/test/struts ? Don - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Conversion from CVS to Subversion Complete
It is my pleasure to announce the official migration of the Struts CVS repository into Apache Software Foundation's Subversion repository. The previous CVS module, jakarta-struts, has been frozen, and all new development will take place in the Subversion repository. The following links might be helpful: Struts public Subversion repository: http://svn.apache.org/repos/asf/struts Struts committers Subversion repository: https://svn.apache.org/repos/asf/struts Subversion: http://subversion.tigris.org Subversion Red Book: http://svnbook.red-bean.com/ Subversion for CVS Users section: http://svnbook.red-bean.com/svnbook-1.0/apa.html The repository is organized like this: struts/ /trunk - The current development branch (like CVS HEAD) /branches - All Struts branches /tags - All Struts tags If you want to checkout everything with the command-line client, type: svn co http://svn.apache.org/repos/asf/struts But most developers will only be interested in the trunk, so it would be better to type: svn co http://svn.apache.org/repos/asf/struts/trunk There are a number of Subversion client GUI's and IDE plugins linked to on the Subversion web site, for those perfer a GUI tool. Thanks again to the infrastructure team for their assistance! Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversion from CVS to Subversion Complete
http://svnbook.red-bean.com/svnbook-1.0/ch03s05.html#svn-ch-3-sect-4.3.2 So pretty much the same, but now you don't need the -u flag - it defaults to unified format. So: svn diff Main.java myPatchfile.txt Don On Fri, 1 Oct 2004 14:44:12 -0500, Hubert Rabago [EMAIL PROTECTED] wrote: Congratulations! Will this affect how patches are generated? I read from earlier messages that patches that have already been submitted can still be used, but what about generating new ones? I've always referenced http://jakarta.apache.org/site/source.html#Patches when generating patches. Will the Struts project site host a similar page to guide contributors? I could take a stab at such a page once I know what the recommended command is for the project. I haven't looked at svn's diff yet, but I'd imagine there'd be a bunch of switches, and I also imagine that the committers would have a recommended set for patches. Hubert On Fri, 01 Oct 2004 12:32:18 -0700, Don Brown [EMAIL PROTECTED] wrote: It is my pleasure to announce the official migration of the Struts CVS repository into Apache Software Foundation's Subversion repository. The previous CVS module, jakarta-struts, has been frozen, and all new development will take place in the Subversion repository. The following links might be helpful: Struts public Subversion repository: http://svn.apache.org/repos/asf/struts Struts committers Subversion repository: https://svn.apache.org/repos/asf/struts Subversion: http://subversion.tigris.org Subversion Red Book: http://svnbook.red-bean.com/ Subversion for CVS Users section: http://svnbook.red-bean.com/svnbook-1.0/apa.html The repository is organized like this: struts/ /trunk - The current development branch (like CVS HEAD) /branches - All Struts branches /tags - All Struts tags If you want to checkout everything with the command-line client, type: svn co http://svn.apache.org/repos/asf/struts But most developers will only be interested in the trunk, so it would be better to type: svn co http://svn.apache.org/repos/asf/struts/trunk There are a number of Subversion client GUI's and IDE plugins linked to on the Subversion web site, for those perfer a GUI tool. Thanks again to the infrastructure team for their assistance! Don - 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: Conversion from CVS to Subversion Complete
Fixed. Don On Fri, 1 Oct 2004 17:17:44 -0400, James Mitchell [EMAIL PROTECTED] wrote: I am not able to commit. I had previously logged into cvs.apache.org and did svnpassword, and I was able to commit on the test conversion. Am I missing something? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, October 01, 2004 3:32 PM Subject: Conversion from CVS to Subversion Complete It is my pleasure to announce the official migration of the Struts CVS repository into Apache Software Foundation's Subversion repository. The previous CVS module, jakarta-struts, has been frozen, and all new development will take place in the Subversion repository. The following links might be helpful: Struts public Subversion repository: http://svn.apache.org/repos/asf/struts Struts committers Subversion repository: https://svn.apache.org/repos/asf/struts Subversion: http://subversion.tigris.org Subversion Red Book: http://svnbook.red-bean.com/ Subversion for CVS Users section: http://svnbook.red-bean.com/svnbook-1.0/apa.html The repository is organized like this: struts/ /trunk - The current development branch (like CVS HEAD) /branches - All Struts branches /tags - All Struts tags If you want to checkout everything with the command-line client, type: svn co http://svn.apache.org/repos/asf/struts But most developers will only be interested in the trunk, so it would be better to type: svn co http://svn.apache.org/repos/asf/struts/trunk There are a number of Subversion client GUI's and IDE plugins linked to on the Subversion web site, for those perfer a GUI tool. Thanks again to the infrastructure team for their assistance! Don - 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]
ViewSVN (was Re: Conversion from CVS to Subversion Complete)
Yes, there is a version of viewcvs, viewsvn, for subversion: http://svn.apache.org/viewcvs.cgi/struts/?root=Apache-SVN Don Matt Bathje wrote: Hi all. Is there a viewcvs.cgi equivalent for the SVN Repository? I realize I can open the url in a browser and view the latest revision, but I liked that you could see the history on the CVS version. In case its not clear what I am talking about: http://svn.apache.org/repos/asf/struts/trunk/ (in a browser) vs. http://cvs.apache.org/viewcvs/jakarta-struts/ thanks, Matt Don Brown wrote: It is my pleasure to announce the official migration of the Struts CVS repository into Apache Software Foundation's Subversion repository. The previous CVS module, jakarta-struts, has been frozen, and all new development will take place in the Subversion repository. The following links might be helpful: Struts public Subversion repository: http://svn.apache.org/repos/asf/struts Struts committers Subversion repository: https://svn.apache.org/repos/asf/struts Subversion: http://subversion.tigris.org Subversion Red Book: http://svnbook.red-bean.com/ Subversion for CVS Users section: http://svnbook.red-bean.com/svnbook-1.0/apa.html The repository is organized like this: struts/ /trunk - The current development branch (like CVS HEAD) /branches - All Struts branches /tags - All Struts tags If you want to checkout everything with the command-line client, type: svn co http://svn.apache.org/repos/asf/struts But most developers will only be interested in the trunk, so it would be better to type: svn co http://svn.apache.org/repos/asf/struts/trunk There are a number of Subversion client GUI's and IDE plugins linked to on the Subversion web site, for those perfer a GUI tool. Thanks again to the infrastructure team for their assistance! Don - 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: Proposal: Javascript-to-Java object conversions
Actually, I just wrote a web application that uses Struts 1.2.4, Struts Flow - http://struts.sf.net/flow , iBATIS database layer, and a touch of Java. Struts Flow allows you to use a Javascript function to replace a Struts action. I use iBATIS to run SQL queries and return Lists of Maps (a Map keyed by column names in the result set), then feed those Maps to the JSP. Struts Flow provides a jsobjectToMap function that lets you convert a Javascript object to a Map, and likewise, a ScriptableMap which lets you access a Map as if it was a Javascript object. This technique let me write an entire application mostly in Javascript with very little code. The iBATIS sql map layer functioned as my DAO and the use of Maps as my data structure worked great. If you have any questions, I'd be happy to elaborate. The bottom line is it is very possible and in fact quite easy to write a Struts app using mostly Javascript, with a smattering of Java for things like application init and more complicated algorithms. Don Craig McClanahan wrote: Wouldn't a Map that had String-valued keys be a reasonable Java object representation of a JavaScript object? That way you can have an arbitrary set of properties, and deal with them by name instead of by index. In the JavaScript-Java direction, you'd probably make the values all Strings too (unless the serialization includes type information), but you'd have more flexibility going the other way. I don't see losing the methods as that big a loss, given a convenient way to transport data back and forth. On the other hand, I'll bet there's some way to use prototypes at the client end to resurrect the methods too. Craig On Fri, 29 Oct 2004 12:33:24 -0700 (PDT), [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Craig (and everyone else), based on what you mentioned on the User's list, I'd like to make the following proposal, get some feedback from everyone and go off and work on it... I prefer getting at least some level of buy-in from you guys before I spend any time on it... The basic idea is being able to convert a Javascript object to a Java object, and vice-versa. Let's deal with it in two steps... To convert from Javascript to Java, I propose we add a new form tag to the HTML taglib called 'html:jsObject'. This would act like an html:hidden element, but with some differences. The 'styleId' element would always render the HTML id attribute as 'jso' where is the name as specified in 'styleId' for an html:jsObject tag. This would be needed to avoid name conflicts with an object named the same thing as the form field. The html:form element would need to have a new attribute added, 'jsoAware'. When set to true, an added onSubmit handler would be rendered that grabs Javascript objects in page scope named according to the 'styleId' of the html:jsObject tags and sets the value of the corresponding html:jsObject tag for each one. So, a developer has to (a) set jsoAware true on html:form and (b) add an html:jsObject element for each object they wish to serialize. As I understand it, the browser will create a string out of the object (I need to verify this frankly, but I'm taking it on faith at this point), so that becomes the value of the jsObject field. That gets us serialization on the client-side integrated with the taglibs. Next, as Craig said, we create a new JSJavaConverter. Pass this the class to convert to (maybe an ActionForm? maybe something else?) and the string as submitted as the jsObject field... ...and here's the first problem I see... what about data types? Javascript is typeless, Java obviously isn't. My thought here is that we put a restraint on any Javascript class to be converted: you as a developer must provide a dataType field for each data field, where is the name of the field. These would be set to one of a set of known values (i.e., string, double, etc). I'm thinking we can add another tag, maybe html:jsObjectConstants, that will render Javascript defining the data type constants. A developer can throw this tag into their class (or at page-level, whichever) and use them in the class to define the data types. I think that gives us enough information to attempt conversions on the fields of the Javascript class. The converter I don't think would be terribly difficult to write, once I know the structure of the serialization the browser performs (hopefully it's name/value pairs and is delimited in some way, then it's almost cake). Now, moving on to converting a Java object to Javascript... That should be even easier... Just write a converter to call toString() on all class fields. I'm thinking I'd write a generic 'JavascriptObjectClass' for use in the converter as the target class. This would probably be as simple as a class with nothing but a HashMap in it that contains the field names and values. Heck, maybe just passing it a HashMap class is sufficient, I'll have to think about that a bit
Re: Proposal: Javascript-to-Java object conversions
I didn't see anything in that proposal that couldn't be satisfied by Struts Flow, but I could have missed something. If so, we could supplement Struts Flow to support it. Converting Javascript objects to Maps should be a sufficient way to handle compatibility with existing Struts capabilities. Struts Flow will be added to Struts soon as an official sub-project, as will Struts BSF, so hopefully folks wanting these features will join the project and contribute. Don Frank W. Zammetti wrote: That sounds pretty cool Don! I guess it leads to the question (for you Struts committe members, not me) whether what you describe suffices and just leave it at that for anyone that ever needs this capability, or whether this whole serialization idea makes sense included in Struts. I guess the argument can be made that it hasn't been asked about a whole lot on the users list (that I've seen anyway, in fact only once), and therefore including it in Struts probably doesn't make sense. On the other hand, is it a fundamental enough concept that including it does make sense? I think this is a question to answer because I don't see this being possible without changes to the existing taglibs, not in the way I'm thinking of it and have described it here anyway, and so it's not something I can really go off and do on my own as an add-on to Struts (I mean, certainly I could create a modified HTML taglib to include this functionality, but I don't like forking in general). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: Javascript-to-Java object conversions
Hmm...good question. :) Struts BSF is a very simple project that lets you write a Struts action using a BSF-supported scripting language. The advantage of this project is you can use any BSF-compatible language including Python, Ruby, Groovy, Javascript, Perl and even VBScript (on windows). The disadvantage is BSF tries to be support many languages and thus is stuck at lowest common denominator. As a result, it doesn't support compilation of scripts very well, so I was rather dismayed by the performance hit. I tried to cache at least the value of the script in memory, but it still had to be compiled each time. Personally, I'm much more interested in Struts Flow. Struts Flow has the goal of bringing Continuations-based capabilities to web applications in general, Struts specifically (see the website for an explanation of what Continuations are and what they mean to web programming). Currently, the only stable and free implementation of continuations is Rhino, the Java-based Javascript implementation, however, Cocoon is working on Java continuations support which would open the door up to, of course Java, but also any scripting language that can compile to byte code (Jython and Groovy come to mind). RIFE also has Java support for continuations, but I understand it is limited. Struts Flow makes really complicated processes like dynamic wizards very easy and almost trivial, without requiring any Javascript on the client side or Back button restrictions. Anyways, I give that history to show how perhaps on the surface the projects are similar, they really differ in focus. BSF just tries to bring scripting to Struts, but Struts Flow focuses on continuations, which currently happen to involve Rhino. I think Struts Flow has much more opportunity for revolutionizing web development and the problems BSF has of compilation, Flow doesn't have since it is pretty tied to Javascript and can take advantage of every optimization feature. So I wouldn't say I've dropped BSF, but I don't think it has the potential that Struts Flow has, however I don't mind maintaining it for those that just want to write Struts actions with scripting languages. Don Joe Germuska wrote: Struts Flow allows you to use a Javascript function to replace a Struts action. I use iBATIS to run SQL queries and return Lists of Maps (a Map keyed by column names in the result set), then feed those Maps to the JSP. Struts Flow provides a jsobjectToMap function that lets you convert a Javascript object to a Map, and likewise, a ScriptableMap which lets you access a Map as if it was a Javascript object. Don: I haven't been following too closely -- have you pretty much dropped struts-bsf in favor of struts-flow? struts-flow was the one which was kind of inspired by some Cocoon practices, right? If you have a few minutes to give us a state-of-the-art on it, I'd appreciate it. Joe -- Joe Germuska[EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - 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: Javascript-to-Java object conversions
Hey, I'll could do that this weekend, but I thought I was to wait until 1.2.5 was rolled, which has, well, stalled. Damn you and your dark, velvety carrot. :) Don Ted Husted wrote: On Fri, 29 Oct 2004 14:01:36 -0700, Don Brown wrote: Struts Flow will be added to Struts soon as an official sub- project, as will Struts BSF I was getting ready to mention that the Guiness clock is ticking, in case you still wanted to have these in place by ApacheCon :) And if Don wants to start setting up struts-flow and struts- scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Which, of course, might be offset by my doing something about the Chain documentation, so we can release that :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]
On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: Argh, posted to the wrong list! Well, in all honesty, this isn't something that was initiated by me, I've never had a thought of passing objects back and forth, so I'm not sure I can give you a real, concrete use case that would explain it. I certainly hear what your saying about XML. I myself have done that very thing in place of something like this. I think the point that makes this interesting is the idea of objects end-to-end. Think of it almost like RMI between a browser-based client and a Java-based back-end. As in RMI, an object gets flattened into some data representation, transmitted and reconstituted on the receiving end. But on both sides of the conversation you have an object. If what your asking is why not just pass XML representing the data instead of a representation of an object, then I'd say because then you have to know about some intermediary interpretation of an object, namely XML. It would kind of be like saying that instead of using RMI, why not just serialize an object's data as XML and transmit that, then parse it on the other end... Certainly that's done every day, but RMI is I think more elegant in that your always dealing in objects, and conversion for the sake of transport is done transparently. That is not necessarily true. If you use XML-RPC, specifically one of the several client-side Javascript libraries for XML-RPC, your application, both on the client and server side, never have to touch XML. The XML-RPC library automatically handles serialization/deserialization as does the server side XML-RPC library (Apache has a great one for this). I use XML-RPC in several applications for the specific reason that I never have to deal with XML, yet I get rich communication between my web application and server. Don I know what your saying about tying to Javascript, but I'm not sure there's too many client-side scripting languages to worry about. I mean, Javascript and VBScript are all I can think of, and although it's been a while since I worked with VBScript, I don't recall there being an object creation mechanism like in Javascript, so I'm not sure how big a concern it is. Certainly I think it's safe to say that Javascript is by far the most popular client-side scripting language, and therefore a solution that is going to cover 75% of applications is probably useful. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Martin Cooper wrote: Just curious, and I'm sure I'm missing something (which is why I'm asking!), but why would you want to do this when there are XML based solutions there for the using, free, and that don't tie you to JavaScript? Thanks. -- Martin Cooper On Fri, 29 Oct 2004 22:31:32 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: On the later idea, I intend to put together a proof-of-concept next week when I get back to the office. I have some family engagements this weekend that will keep me from getting started, and on Tuesday I take the first exam for my SCEA (not to mention the election!), but I have some spare cycles at work currently so I should pretty much have the rest of the week to play. I only mention this because while I obviously can't stop anyone else from beating me to the punch, I do intend to persue this, so if you have any other itches to scratch, go for them, leave this one for me if you would :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Craig McClanahan wrote: On Fri, 29 Oct 2004 21:28:52 -0400, Ted Husted [EMAIL PROTECTED] wrote: That sounds great to me, Don. :) We already have Struts-Faces and Struts-Examples on the trunk. We might as well add Struts-BSF and Struts-Flow to the mix. +1. Struts-BSF and Struts-Flow are not part of the core, so they would be not affected by a 1.2.x branch. -Ted. Note that there have been two overlapping discussions about scripting on the lists today ... Don's stuff in Struts Flow uses a modified Rhino (with continutations) to do scripting on the *server* side, while the earlier conversation about serializing a JavaScript object and converting it is about scripting on the *client* side, using a serialized form of JavaScript objects to pass data back and forth through a hidden field. Both ideas are quite cool. Craig - 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
Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]]
I'm personally fond of vcXMLRPC - http://www.vcdn.org/Public/XMLRPC/ - and have used it successfully in several projects, an ASP application and a Struts-based application. I've heard of others, but that one has been good to me as it works with IE 5.5+ and Mozilla 1.0+. This also seems to be a good list of non XML-RPC remote scripting for Javascript: http://www.ashleyit.com/rs/main.htm I've never understood why XML-RPC and remote scripting in general haven't been more prevelent in web applications. The main limitation is a semi-recent browser, but that shouldn't be an issue in most web applications, especially within intranets. The excellent performance and developmental simplicity make web applications viable for more complex tasks. Don On Sat, 30 Oct 2004 00:18:08 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: It sounds like what your saying is that such a beast already exists... I'm looking now at the XML-RPC site at http://ws.apache.org/xmlrpc/, specifically the link to Client Classes... Is this what your referring to? If so, I think this is dealing with writing a Java-based client, not Javascript objects. Assuming that's not it though, can you point me in the right direction? I'm most definitely interested! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Don Brown wrote: On Fri, 29 Oct 2004 23:52:49 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: Argh, posted to the wrong list! Well, in all honesty, this isn't something that was initiated by me, I've never had a thought of passing objects back and forth, so I'm not sure I can give you a real, concrete use case that would explain it. I certainly hear what your saying about XML. I myself have done that very thing in place of something like this. I think the point that makes this interesting is the idea of objects end-to-end. Think of it almost like RMI between a browser-based client and a Java-based back-end. As in RMI, an object gets flattened into some data representation, transmitted and reconstituted on the receiving end. But on both sides of the conversation you have an object. If what your asking is why not just pass XML representing the data instead of a representation of an object, then I'd say because then you have to know about some intermediary interpretation of an object, namely XML. It would kind of be like saying that instead of using RMI, why not just serialize an object's data as XML and transmit that, then parse it on the other end... Certainly that's done every day, but RMI is I think more elegant in that your always dealing in objects, and conversion for the sake of transport is done transparently. That is not necessarily true. If you use XML-RPC, specifically one of the several client-side Javascript libraries for XML-RPC, your application, both on the client and server side, never have to touch XML. The XML-RPC library automatically handles serialization/deserialization as does the server side XML-RPC library (Apache has a great one for this). I use XML-RPC in several applications for the specific reason that I never have to deal with XML, yet I get rich communication between my web application and server. Don I know what your saying about tying to Javascript, but I'm not sure there's too many client-side scripting languages to worry about. I mean, Javascript and VBScript are all I can think of, and although it's been a while since I worked with VBScript, I don't recall there being an object creation mechanism like in Javascript, so I'm not sure how big a concern it is. Certainly I think it's safe to say that Javascript is by far the most popular client-side scripting language, and therefore a solution that is going to cover 75% of applications is probably useful. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Martin Cooper wrote: Just curious, and I'm sure I'm missing something (which is why I'm asking!), but why would you want to do this when there are XML based solutions there for the using, free, and that don't tie you to JavaScript? Thanks. -- Martin Cooper On Fri, 29 Oct 2004 22:31:32 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: On the later idea, I intend to put together a proof-of-concept next week when I get back to the office. I have some family engagements this weekend that will keep me from getting started, and on Tuesday I take the first exam for my SCEA (not to mention the election!), but I have some spare cycles at work currently so I should pretty much have the rest of the week to play. I only mention this because while I obviously can't stop anyone else from beating me to the punch, I do intend to persue this, so if you have any other itches to scratch, go for them, leave this one for me if you would
Struts Sub-Projects
Perhaps this has already been discussed, but I couldn't find anything about it How will we organize Struts subprojects in the repository? As I understand it, Struts subprojects are projects that are intimately associated with Struts, yet have their own release cycle. The prime example being struts-faces. If so, why is struts-faces located in /trunk/ and therefore branched and tagged along with Struts core? Shouldn't it have its own trunk/branches/tags triad for its own release cycles? In a particular project in my day job, we have two main components that have their own release cycles. In subversion, we give them the following organization: server/ trunk/ branches/ tags/ client/ trunk/ branches/ tags/ This allows each component to branch and tag without affecting the other. I would think a similiar organization would be practical for Struts to allow sub-projects like struts-faces and struts-flow to manage themselves. I'd recommend (if it hasn't already been discussed and rejected) we adopt a similar pattern with core, struts-faces, struts-flow, and struts-bsf as root directories, each with their own branches/tags/trunk directories. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Sub-Projects
No, actually, it would be a simple matter of a couple of svn move commands. They are quick, and can be easily redone later if we change our minds. Don On Fri, 5 Nov 2004 07:42:44 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:52 PM -0800 11/4/04, Don Brown wrote: If so, why is struts-faces located in /trunk/ and therefore branched and tagged along with Struts core? Shouldn't it have its own trunk/branches/tags triad for its own release cycles? +1 Just curious, do we need to ask someone in [EMAIL PROTECTED] to do this? I don't seem to understand where the real SVN repository actually lives. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Sub-Projects
In a perfect world... svn.apache.org/asf/struts /core /trunk /branches /tags /faces /trunk /branches /tags /bsf /trunk /branches /tags /flow /trunk /branches /tags Therefore, we would then instruct folks that want to work on Struts core to use http://svn.apache.org/asf/struts/core/trunk Don Craig McClanahan wrote: On Fri, 5 Nov 2004 08:01:33 -0800, Don Brown [EMAIL PROTECTED] wrote: No, actually, it would be a simple matter of a couple of svn move commands. They are quick, and can be easily redone later if we change our minds. Agree that it's easy to move things around ... but I've got a question -- does this still all end up under our single canonical SVN URL (https://svn.apache.org/asf/struts)? If so, I'm fine with it ... once we figure out what to name the top level directories of course :-). Don Craig On Fri, 5 Nov 2004 07:42:44 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:52 PM -0800 11/4/04, Don Brown wrote: If so, why is struts-faces located in /trunk/ and therefore branched and tagged along with Struts core? Shouldn't it have its own trunk/branches/tags triad for its own release cycles? +1 Just curious, do we need to ask someone in [EMAIL PROTECTED] to do this? I don't seem to understand where the real SVN repository actually lives. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - 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: Struts Sub-Projects
Yes. :) Don On Mon, 8 Nov 2004 12:08:35 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Mon, 8 Nov 2004 11:50:43 -0800, Don Brown [EMAIL PROTECTED] wrote: I'm not sure what you mean and how refactoring is enhanced by using one trunk. I'm just suggesting giving each subproject its own structure, but they would all be in the same repository, and could be all checked out at one shot by checking out struts/ I'm not saying that it is enhanced - rather, I'm asking the question. ;-) What I'm getting at is this. Say I'm working on 'faces' and I come across a class that really should be part of 'core' instead. Can I still use the regular SVN move mechanism to move the class over, keeping history, etc., when 'core' and 'faces' have separate trunk / branches / tags? boolean martin_happy = (answer.equals(yes)); // ;-) -- Martin Cooper Don On Sun, 7 Nov 2004 10:03:27 -0800, Martin Cooper [EMAIL PROTECTED] wrote: One of the initial reasons for having one trunk / branches / tags group, rather than several, was the desire to be able to refactor across artifacts. If that is still retained with the proposal below, then I'm fine with it. Otherwise, I think we need to consider it a bit more. -- Martin Cooper On Fri, 05 Nov 2004 15:26:45 -0800, Don Brown [EMAIL PROTECTED] wrote: In a perfect world... svn.apache.org/asf/struts /core /trunk /branches /tags /faces /trunk /branches /tags /bsf /trunk /branches /tags /flow /trunk /branches /tags Therefore, we would then instruct folks that want to work on Struts core to use http://svn.apache.org/asf/struts/core/trunk Don Craig McClanahan wrote: On Fri, 5 Nov 2004 08:01:33 -0800, Don Brown [EMAIL PROTECTED] wrote: No, actually, it would be a simple matter of a couple of svn move commands. They are quick, and can be easily redone later if we change our minds. Agree that it's easy to move things around ... but I've got a question -- does this still all end up under our single canonical SVN URL (https://svn.apache.org/asf/struts)? If so, I'm fine with it ... once we figure out what to name the top level directories of course :-). Don Craig On Fri, 5 Nov 2004 07:42:44 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:52 PM -0800 11/4/04, Don Brown wrote: If so, why is struts-faces located in /trunk/ and therefore branched and tagged along with Struts core? Shouldn't it have its own trunk/branches/tags triad for its own release cycles? +1 Just curious, do we need to ask someone in [EMAIL PROTECTED] to do this? I don't seem to understand where the real SVN repository actually lives. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - 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] - 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]
Subversion repository reorganization
As you many have noticed, we've reorganized the Struts as discussed, moving core Struts code as its own subproject, then giving struts-faces and struts-el their own subproject. At the same time, due to core build requirements concerning struts-el, we moved struts-el to its own subproject. I write subproject in quotes as we should formalize what we call them. A subproject would be a defined project that has its own release cycle, and therefore trunk, branches, and tags directories. At this point, there are core, faces, el, and sandbox subprojects, and I'm planning on creating a bsf subproject. taglibs will follow for 1.3.0 We had to modify the build for Struts core and struts-el as the paths had changed, but should only affect the dist target. The documentation and website should contain the new Subversion url (https://svn.apache.org/repos/asf/struts/core/trunk) and Martin has updated the website. Please test the site and builds to ensure we didn't miss anything. Thanks. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Added capability to load config files from jars
I've developed a quite small patch that allows Struts, Validator, and Tiles configuration files to be loaded from the classloader if not found in the servlet context. This allows people to distribute Struts modules as self-contained jars (save jsp's of course if the module uses those). The previous behavior was to load config files from the servlet context, and if not found, throw an exception. I added a middle step that if the file can't be located on the servlet context, it tries to load the file from the classloader which can pull resources, from among other places, jars in WEB-INF/lib. Does anyone have any objections? If not, I'll apply it in a day or so. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experiences with MockObjects for Servlet testing?
Perhaps this might be a good time to bring up the idea of bringing StrutsTestCase as a Struts subproject? They have an implementation of the servlet api for testing. Don Joe Germuska wrote: I just found an annoying bug in struts-chain, where CreateAction was looking up the map of actions under one key, and if not found, creating a new map and storing it under another key. The net result being that every CreateAction request was resulting in the initialization of a new Action class (as well as a new HashMap). Anyway, I thought this would be a good time to start writing test cases for struts-chain stuff. I haven't used MockObjects much, but it seemed like the best way to set up the mock environment. However, when I got down to running the test, I found that the library appears to be hard-coded to throw an AssertionFailedError if you try to retrieve something from the MockServletContext which isn't there. http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObjectBag.html#getNextReturnObject(java.lang.Object) Does anyone more familiar with MockObjects know if there's a way to turn off this behavior or otherwise specify that it's not an error condition? Obviously in this case I can't write a test case for my fix if I can't simulate the condition where there is not yet any such object in the ServletContext. I went ahead and committed the fix anyway (rev. 106242) but it would be nice to be able to test it. I'm going to go ahead and commit the project.xml file that has mockobjects dependencies, since they may still be useful for other tests that we may want to write. This project.xml file also fixes the inheritance from the Struts project.xml file. (For the el libraries, I did this the other way, by copying the files that would otherwise be picked up by inheritance. I'm not sure which I think is more right but the inheritance precludes someone from building a source distribution, which is kind of a drag. In this case, it was just faster!) Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Configuration and IoC (Re: Proposed Roadmap for 1.3.x and beyond [long])
The bottom line is Struts now uses xml configuration as declarative configuration, rather than procedural. We define forms, actions, plugins, etc., without defining a process for using them. When you start looking at configuration for defining procedures, it can get messy quick - just look at Jelly. Many would argue XML is just not a good fit for procedural code/definitions. Even if you liked XML for procedural configuration, I'm not sure chain's dtd would be a good idea either. It only can only be used to define a linear process - no braches, loops, or iterations. Instead, you'd have to code that logic inside your commands, further complicating them and making it even harder to deduce flow. Personally, I like the approach of using XML to define items, then letting how those items are processed be defined with chain or whatever else. Even then, I like using chain and CoR for defining one pretty static process like how Struts handles requests, but leaving it up to Java or scripting languages for defining more dynamic, complex processes. Inversion of Control, however, is really a different beast as it seeks neither to define processes or conceptual elements, but rather configures actual classes which may be different. Don Joe Germuska wrote: Since there was so much coming out of the ApacheCon summit, I decided to split my responses up a bit. I think long-term, the way in which Struts is configured is one of the most important factors about its ease of use and maintenance. At 9:37 AM -0600 11/21/04, Vic wrote: So I say no combined DTD in favor of chain DTD, and no IoC, because CoR , similar in purpose, is better than IoC. If IoC always had same signature - you'd have CoR. I know IoC is fashionable, but CoR is better, I put both in production. There is definitely something to this. I don't think I would agree that the Chain DTD would subsume any other configuration, but it's possible to imagine, at least in many cases, scrapping the struts-config.xml and instead having each command configure itself with whatever it needs. The problem comes when multiple steps in the chain need to reference the same configuration information. For example, form beans need to be looked up to populate them from the request, but they also need to be looked up if you want to pre-populate a page with application data. You wouldn't really want to push the form-bean configuration into the CreateActionForm command; instead, you'd want both CreateActionForm and (some as yet non-existent) PrepareViewContext command each to look up something in the StrutsContext which had that expertise. The other problem (if it is a problem) comes with explaining just what Struts is, if there's no struts-config file! I wouldn't let that stop me, but it is interesting in a way. If we were to use some kind of IoC, what would be the collaborators? I have often thought it would be nice to replace all those config classes with some more intelligent classes that have config but also do things (especially form bean and action instantiation), thereby centralizing some of the logic. Furthermore, I do prefer, in general, the idea of initializing one (or very few) objects for each relevant scope (in this case, particularly, the application scope) and then populating properties on those objects, rather than trusting everyone to use the right attribute name for fishing those out of contexts. I'm still trying to go through actual Struts code looking at it with these ideas in mind to validate whether there are really places where Struts would benefit from this, or if it's really just a matter of taste that isn't worth trying to impose on Struts. Joe At 8:47 AM -0500 11/21/04, Ted Husted wrote: -1.4 considerations- One we get past 1.3.x, there are some other things that we might consider. Consider combining DTDs. Right now, using standard extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration. Consider adding catalog element. Depending on how the work goes with the experimental ActionCommand interface, we might identifiy a need to add a catalog element to the Struts configuration, to support using a Chain of ActionCommands. Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground. - To unsubscribe, e-mail:
Re: chain in trunk for builds?
Comments inline... Joe Germuska wrote: I think Martin said chain is in trunk. I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? Chain is not yet in the core, but getting it there is something I'm interested in working on. It may also be just as well to wait a few days until commons-chain 1.0 is formally released. Meanwhile, I am still looking for more feedback on some of my questions. I'm restating/clarifying them below. Items two and three seem the most controversial. [1] Chain initialization: Pending any objection, I would remove the need for the ChainConfiguratorPlugIn and instead have the ActionServlet receive an init parameter, chains which would be one or more (comma-separated) paths to XML files. I would follow Don's recent changes so that each path would be tested first as a servlet resource, and, if that failed, as a classpath resource. If a URL were found in either source, it would be passed to o.a.s.chain.config.ConfigParser.parse(URL) If a URL were found in neither source, a ServletUnavailableException would be thrown. Sounds good. I would take it a step further, and, if no init parameter, look for the chain config as /chain-config.xml, making it possible to provide an intelligent default. We could then, take your idea in #3, and bundle our own /chain-config.xml inside Struts. Since it would be on the classpath, it could still be easily overridden by creating a chain-config.xml in the servlet context w/o adding any configuration to web.xml. [2] RequestProcessor Configuration: In the current ChainConfiguratorPlugIn, the catalog name and initial command are settable with servlet init parameters. It seems to me that this should be a per-Module setting, and so I'd argue those should be properties on the RequestProcessor. This is not a high priority to me, but it seems more right. Works for me. To achieve this would require either adding yet more properties to ControllerConfig or, my preferred solution, allowing ControllerConfig to hold a reference to an actual RequestProcessor object which could be instantiated and configured by Digester. (Would this involve some ClassLoader issues? the Struts digester instance uses the contextClassLoader when it has been set, as does RequestUtils.applicationInstance(...) so perhaps not a great risk?) I guess the alternative would be a RequestProcessorConfig object that carried the properties -- but this is an example of where I would rather turn away from the config objects and towards something more IoC-like... The other question here is simply whether to change the behavior of the class named RequestProcessor (probably copying the current behavior to a LegacyRequestProcessor) or rather to change the default class used to point to a new class which implements the Chain-based processing. I like for former. We continue to use RequestProcessor, but deprecate it, and make LegacyRequestProcessor the default. This allows Struts extensions to make the transition easier. Don [3] Default Chain Do we import all the classes in struts-chain into core? Or do we pack them as a jar and use them by reference? Based on our stated interest in reducing core dependencies on the Servlet API, I would argue for the first. If we did the first, I think it would be interesting (but low priority) to consider a mechanism for including the chain-config.xml in the JAR and having it be auto-discovered. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain enhancement idea
Not you personally BaTien, I don't understand why some people seem to confuse Inversion of Control (IoC) and Chain of Responsibility (CoR), and worse, think they are somehow solving the same problem. IoC helps us create components by managing their lifecycle and providing their dependencies. CoR defines a process that let's us flexibly specify what code to execute in what order. Sure, commons-chain does provide the default capability to create commands and configure them with simple properties, but that isn't its purpose and would certainly be replaced in any moderately complex usage, most likely by some sort of IoC. It's like saying a HashMap conflicts with a SQL database as they both store data. They are two very different things with very different problems they are trying to solve. Don BaTien Duong wrote: Craig McClanahan wrote: On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska [EMAIL PROTECTED] wrote: I need to have a hook into processValidate() on validation failure. Currently that can only be done by copy-and-pasting the processValidate() method from RequestProcessor into a subclass and sticking a hook into the middle of the code. When I asked about this on the dev list long ago, it was confirmed that there was no other way to do this, but that chain would eventually provide this flexibility. If the chain isn't configured at a fine-grain level, then it's not all that much more functional than the existing RequestProcessor. The chain is configured at as fine-grained a level as you like, in XML. Hubert is talking about configuring the chain programatically as well, or at least in some way independent of the configuration of the primary processing chain. Programmatic configuration is certainly feasible ... there's no requirement in [chain] that you use the XML format at all. It's just one option. Greetings and request expert advice: Commons-chain invented by Craig proves to be very flexible and work in conjuction with other great technonologies. What i am trying to figure out is a proper and practical places for using CoR and IoC (such as Spring framework) in the construction and configuration of software objects. I put out some of my preliminary thinking and hope some experts care to add more arguments to enlighten us. 1) Both CoR and IoC (and also Jsf setter injection) enable the configuration and linking objects via XML metadata. But IoC allows the object configuration at a finer level of object attributes and take care of the objects declared as singleton. In this sense, IoC is finer grain than CoR in object creation, configuration and management. 2) CoR is very light weight and appropriate for programmatically created processes. It does not not have the complexity and the depth of plug-in features as Spring IoC. 3) CoR is finer grain than IoC in the construction and rounting of services within and between software layers, while IoC is aprropriate at the application level. 4) If we want to combine Jsf as view controller, Spring IoC and commons-chain CoR, a practical infrastructure may be something like followings: a) Jsf as a view controller takes care of objects directly related to User Interface (UI) b) Spring IoC takes the responsibility of object creation, especially singletons and fine grain configurations of objects not directly related to UI. This is a proper choice of configuration if other features of Spring framework such as application level event and aop are used. c) CoR is used to construct Front Controller a la pattern of Struts of each software module, the rounting of services among modules, and action commands (or chain) of specialized services in each service module. It programmatically links created components from IoC to a finer grain at each software module, which holds the module Catalog of commands. d) User session is a proper place for programmatically interactions of Jsf, IoC and CoR objects. For example user generated events from Jsf is linked through a CoR adapter to dispatch action command as a request to appropriate software module (such as authentication/authorization, portlet, service, etc) whose responses are rendered through Jsf view controller. BaTien DBGROUPS As long as you're willing to copy the base chain-config.xml file and make a few modifications, then you could simply add your own command which retrieves a value from the context under a well-known key and inspects the value to see if validation passed or not. This exact logic is the first thing executed in the CreateAction's execute method, which doesn't lookup or create an action unless the form validated. There's actually quite a few different ways to approach this, including the optionally invoke some other command at this point mentioned earlier in the thread, so you don't even *have* to cut-n-paste the standard version of the chain. You can start experimenting with commons-chain and struts-chain from CVS
Re: Chain enhancement idea
I look at technology as solutions to problems. IoC solves the problem of how can I define and configure a component external to the component and calling code, and CoR tackles the problem of a how can I define a process or sequence of processes in a pluggable manner. True, both patterns have a pluggable property, but both a HashMap and a SQL database have a lookup property. I think what you are getting at is, in Struts, we need a way to allow the framework to be easily customized by both framework extension projects and users. Both IoC and CoR help us meet that goal, but by solving two different problems that work against pluggability. In Struts, I see the need for allowing the user to have more control over the process of events, as well as what components are used by that process. So yes, one goal perhaps, but two different problems being solved in two different ways. Don Dakota Jack wrote: Without disagreeing with anything you have said, Don, I think the confusion is caused in part by the fact that CoR is anticipated in part for its pluggable nature. In this respect, there is a real connection in functionality between CoR and IoC that is not as attenuated as the one between HashMap and a SQL database but more like a properties file and a SQL database? You think? Jack On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown [EMAIL PROTECTED] wrote: Not you personally BaTien, I don't understand why some people seem to confuse Inversion of Control (IoC) and Chain of Responsibility (CoR), and worse, think they are somehow solving the same problem. IoC helps us create components by managing their lifecycle and providing their dependencies. CoR defines a process that let's us flexibly specify what code to execute in what order. Sure, commons-chain does provide the default capability to create commands and configure them with simple properties, but that isn't its purpose and would certainly be replaced in any moderately complex usage, most likely by some sort of IoC. It's like saying a HashMap conflicts with a SQL database as they both store data. They are two very different things with very different problems they are trying to solve. Don BaTien Duong wrote: Craig McClanahan wrote: On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska [EMAIL PROTECTED] wrote: I need to have a hook into processValidate() on validation failure. Currently that can only be done by copy-and-pasting the processValidate() method from RequestProcessor into a subclass and sticking a hook into the middle of the code. When I asked about this on the dev list long ago, it was confirmed that there was no other way to do this, but that chain would eventually provide this flexibility. If the chain isn't configured at a fine-grain level, then it's not all that much more functional than the existing RequestProcessor. The chain is configured at as fine-grained a level as you like, in XML. Hubert is talking about configuring the chain programatically as well, or at least in some way independent of the configuration of the primary processing chain. Programmatic configuration is certainly feasible ... there's no requirement in [chain] that you use the XML format at all. It's just one option. Greetings and request expert advice: Commons-chain invented by Craig proves to be very flexible and work in conjuction with other great technonologies. What i am trying to figure out is a proper and practical places for using CoR and IoC (such as Spring framework) in the construction and configuration of software objects. I put out some of my preliminary thinking and hope some experts care to add more arguments to enlighten us. 1) Both CoR and IoC (and also Jsf setter injection) enable the configuration and linking objects via XML metadata. But IoC allows the object configuration at a finer level of object attributes and take care of the objects declared as singleton. In this sense, IoC is finer grain than CoR in object creation, configuration and management. 2) CoR is very light weight and appropriate for programmatically created processes. It does not not have the complexity and the depth of plug-in features as Spring IoC. 3) CoR is finer grain than IoC in the construction and rounting of services within and between software layers, while IoC is aprropriate at the application level. 4) If we want to combine Jsf as view controller, Spring IoC and commons-chain CoR, a practical infrastructure may be something like followings: a) Jsf as a view controller takes care of objects directly related to User Interface (UI) b) Spring IoC takes the responsibility of object creation, especially singletons and fine grain configurations of objects not directly related to UI. This is a proper choice of configuration if other features of Spring framework such as application level event and aop are used. c) CoR is used to construct Front Controller a la pattern of Struts of each software
Re: Second call: add generic mapped property to ActionConfig (was Re: [chain] ChainAction and o.a.s.chain.legacy.DispatchAction)
How would this work with digester? As I understand it, digester is the
one that actually populates the action config, and then only at init time.
I sure like the idea, but don't know about the naming style. What about
foo.bar where foo corresponds to setFoo(Map m) and foo.bar calls
m.put(bar) The more we go down this road of more robust
configuration/initialization, the more I think we are going to realize
Spring already does this and does it better.
Don
Joe Germuska wrote:
This may have been lost in the (US) holiday shuffle, or because it was
tucked into a subject line which might not have indicated a suggestion
for a change to a relatively core part of Struts. So I just thought
I'd air it one more time before I make any changes to ActionConfig.
Note that the idea of this is simply to minimize the need to write
custom subclasses of ActionMapping. The existing configured
(frozen) semantics would continue to apply to this new property.
Joe
At 3:44 PM -0600 11/23/04, Joe Germuska wrote:
A month ago, Craig added two action classes to struts-chain. Looking
at them now, I see that they only work with the default or un-named
catalog. Is this a serious issue? Is anyone actually using them
yet? I'm just catching up with the named-catalog changes in
commons-chain, but it seems likely that this will be a limitation.
Unfortunately, ActionMapping only gives us one parameter slot to pass
something in, and that's used up with either the name of the command
or the name of the request parameter which has the command.
Now that I write this, this may be a good opportunity to propose
adding a simple mapped property to ActionConfig that would allow more
flexible per-mapping configuration. This came up on the list before
(can't remember if I brought it up or not) and I'm pretty sure at
least one other committer said he thought it was a good idea. This
is a pet enhancement request from one of the developers on my team,
but I think it's a good idea too. I just don't know if I like any
naming options, mostly just with the possible confusion between bean
properties and java.util.Properties.
action-mapping path=/foo
type=org.apache.struts.chain.legacy.ChainAction
set-property name=props(command-name) value=my-command /
set-property name=props(catalog-name) value=my-catalog /
...
/action
public class ActionConfig {
...
private java.util.Properties props = new java.util.Properties();
public void setProps(String key, String value) {
this.props.setProperty(key,value); }
public String getProps(String key) { return
this.props.getProperty(key); }
...
}
Any takers? Strong opinions about the name of the mapped property?
Preference for some alternative XML specification with corresponding
extensions to the struts-config DTD?
Joe
From: craigmcc at apache.org
Subject: svn commit: rev 55393 -
struts/trunk/contrib/struts-chain/src/java/org/apache/struts/chain/legacy
Newsgroups: gmane.comp.jakarta.struts.devel
Date: Sat, 23 Oct 2004 18:30:37 +
Author: craigmcc
Date: Sat Oct 23 11:30:37 2004
New Revision: 55393
Added:
struts/trunk/contrib/struts-chain/src/java/org/apache/struts/chain/legacy/ChainAction.java
struts/trunk/contrib/struts-chain/src/java/org/apache/struts/chain/legacy/DispatchAction.java
Log:
Add a couple of ways that an Action can delegate its business logic
processing to a Chain (or Command):
* ChainAction - Name of the chain is configured in the action element
* DispatchAction - Name of the chain is specified by a request
parameter
(analogous to the standard org.apache.struts.actions.DispatchAction)
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Spring dreaming (was Second call: add generic mapped property to ActionConfig)
struts-config.xml accomplishes the following tasks: 1. Defines form models 2. Defines and configures Actions 3. Defines and configures mappings of actions 4. Defines and configures plugins 5. Defines and configures message resources 6. Defines and configures request processor I see Spring vastly improving, if not completely replacing, #2, #4, #5, and #6. It could even be argued #1 should be moved into a form definition file that integrates validator field configuration. Therefore, I'd imagine a Springified Struts only needing struts-config.xml for #3, defining action mappings, with probably another configuration element to point to the Spring context/BeanFactory file for the module (loaded as a child of a global Spring context/BeanFactory) and the bean id's the request process, message resources, and plugins can be found under. Don Joe Germuska wrote: snip / The more we go down this road of more robust configuration/initialization, the more I think we are going to realize Spring already does this and does it better. I suspect you're right, as I have come to prefer Spring's BeanFactory to Digester for this kind of thing. Have you ever looked at configuring Struts completely using Spring? It might be an interesting exercise, along with possibly coming up with an XSLT process to make current Struts config files usable with Spring! Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Good point, however the use of intelligent defaults would simplify things. I'd see it this way: 1. struts-config.xml - Defines action mappings. Default config could use wildcards to cover 90% of mappings. Ted's extends idea would also help keep it small. 2. forms.xml - Combines dyna action forms and validator rules into one logical document. I suppose this could be combined into struts-config.xml. If so, it would follow Ted's idea of one config file DTD to rule them all. 3. spring.xml - Yes, it does define actions, plugins, etc separately from struts-config.xml, but this allows you to more easily hook application classes into your implementations. For example, you can write an Action that can automatically get reference(s) to your services layer or DAO layer. This is important as it not only makes things simpler for the user, but is yet another step that removes the user from ever having to work with the application scope. One feature I really like about Tapestry (probably JSF too) is they don't put all sorts of application and framework objects in shared scopes. Tiles could probably be woven into struts-config.xml, and I'm still not convinced there is much to be gained from a Struts and JSF combination (outside the usual migration arguments). Don David Graham wrote: --- Craig McClanahan [EMAIL PROTECTED] wrote: I agree with Don's assessment, but wanted to add an FYI note -- Shale does zero-config for #3 (because the mapping between a JSP page and the corresponding ViewController is implicit), and doesn't require #1 unless you need it for doing Commons Validator stuff. Simpler is definitely better. But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. David Craig On Mon, 29 Nov 2004 10:03:16 -0800, Don Brown [EMAIL PROTECTED] wrote: struts-config.xml accomplishes the following tasks: 1. Defines form models 2. Defines and configures Actions 3. Defines and configures mappings of actions 4. Defines and configures plugins 5. Defines and configures message resources 6. Defines and configures request processor I see Spring vastly improving, if not completely replacing, #2, #4, #5, and #6. It could even be argued #1 should be moved into a form definition file that integrates validator field configuration. Therefore, I'd imagine a Springified Struts only needing struts-config.xml for #3, defining action mappings, with probably another configuration element to point to the Spring context/BeanFactory file for the module (loaded as a child of a global Spring context/BeanFactory) and the bean id's the request process, message resources, and plugins can be found under. Don Joe Germuska wrote: snip / The more we go down this road of more robust configuration/initialization, the more I think we are going to realize Spring already does this and does it better. I suspect you're right, as I have come to prefer Spring's BeanFactory to Digester for this kind of thing. Have you ever looked at configuring Struts completely using Spring? It might be an interesting exercise, along with possibly coming up with an XSLT process to make current Struts config files usable with Spring! 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] __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com - 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: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Cause ours is better...duh... ;) Don David Graham wrote: Spring also provides a webapp framework. Why would a user bother using Struts with Spring when they could use Spring with Spring? David --- Ted Husted [EMAIL PROTECTED] wrote: Spring is designed to instantiate any given object graph, which should include the Struts configuration objects. It would seem to follow that we could configure everything in Struts from a Spring configuration file. If so, then we would not be adding another framework, but using Spring in lieu of the Digester and an assortment of custom factories. Is not Spring MVC (which is very much like Struts) configured from a Spring configuration file? Ideally, an application should be able to use as many, or as few, configuration files as it likes. -Ted. On Mon, 29 Nov 2004 10:47:07 -0800, Don Brown wrote: Good point, however the use of intelligent defaults would simplify things. I'd see it this way: 1. struts-config.xml - Defines action mappings. Default config could use wildcards to cover 90% of mappings. Ted's extends idea would also help keep it small. 2. forms.xml - Combines dyna action forms and validator rules into one logical document. I suppose this could be combined into struts- config.xml. If so, it would follow Ted's idea of one config file DTD to rule them all. 3. spring.xml - Yes, it does define actions, plugins, etc separately from struts-config.xml, but this allows you to more easily hook application classes into your implementations. For example, you can write an Action that can automatically get reference(s) to your services layer or DAO layer. This is important as it not only makes things simpler for the user, but is yet another step that removes the user from ever having to work with the application scope. One feature I really like about Tapestry (probably JSF too) is they don't put all sorts of application and framework objects in shared scopes. Tiles could probably be woven into struts-config.xml, and I'm still not convinced there is much to be gained from a Struts and JSF combination (outside the usual migration arguments). Don David Graham wrote: --- Craig McClanahan [EMAIL PROTECTED] wrote: I agree with Don's assessment, but wanted to add an FYI note -- Shale does zero-config for #3 (because the mapping between a JSP page and the corresponding ViewController is implicit), and doesn't require #1 unless you need it for doing Commons Validator stuff. Simpler is definitely better. But is adding yet another framework to Struts simplifying anything for the user or just for us developers? If we add Spring, we would need to know the following to write a Struts webapp: 1. struts-config.xml 2. validator-rules.xml 3. spring.xml (or whatever they call the config file) 4. possibly tiles-config.xml 5. possibly jsf config files How is learning and remembering up to 5 different configuration files better for the user? If I was put in this position, I would seriously consider other ways of writing Java webapps. David Craig On Mon, 29 Nov 2004 10:03:16 -0800, Don Brown [EMAIL PROTECTED] wrote: struts-config.xml accomplishes the following tasks: 1. Defines form models 2. Defines and configures Actions 3. Defines and configures mappings of actions 4. Defines and configures plugins 5. Defines and configures message resources 6. Defines and configures request processor I see Spring vastly improving, if not completely replacing, #2, #4, #5, and #6. It could even be argued #1 should be moved into a form definition file that integrates validator field configuration. Therefore, I'd imagine a Springified Struts only needing struts-config.xml for #3, defining action mappings, with probably another configuration element to point to the Spring context/BeanFactory file for the module (loaded as a child of a global Spring context/BeanFactory) and the bean id's the request process, message resources, and plugins can be found under. Don Joe Germuska wrote: snip / The more we go down this road of more robust configuration/initialization, the more I think we are going to realize Spring already does this and does it better. I suspect you're right, as I have come to prefer Spring's BeanFactory to Digester for this kind of thing. Have you ever looked at configuring Struts completely using Spring? It might be an interesting exercise, along with possibly coming up with an XSLT process to make current Struts config files usable with Spring! Joe -- --- To unsubscribe, e-mail: dev- [EMAIL PROTECTED] For additional commands, e- mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Spring dreaming (was Second call: add generic mapped property to ActionConfig)
Very applicable actually :) Let's look it this way - what types of information needs to go into configuration? I see the following types: 1. Action/Backing bean definitions. Perferably support for connecting with business objects. 2. Form/field definitions and validations. 3. ActionForwards/Navigation My understanding how these are handled by several major frameworks: Struts 1. Actions defined in struts-config.xml. No support for linking to business objects. 2. Forms defined in struts-config. Validations in validation-rules.xml 3. ActionForwards in struts-config.xml, no support for navigation JSF 1. Backing beans defined in faces-config.xml. Integration with Spring to connect to bus objects. 2. Forms and validations defined in the JSP's. No support for 1:M forms (save custom components) 3. No action forwards as page based. Navigation information stored in faces-config.xml Tapestry 1. Beans definied in each page's specification xml file. Support for bus object linking with hivemind. 2. Form fields defined in page spec file. No support for 1:M forms (save custom components). 3. No action forwards as page based. No explicit navigation configuration. One could argue Tapestry was the simplest, however it could also be argued the opposite since each page needs its own xml configuration file. The question is what and where do we want the user to be able to configure. On one extreme of configuration, NanoWeb/NanoWar require no configuration as the framework handles everything. On the other side, Struts seems to require configuration for everything. The better approach depends on your objectives and requirements, as well as personal taste. I'd argue Struts should continue to provide the maximum flexibility, but search for ways to provide intelligent defaults wherever possible to allow the new developer to be able to pick up Struts quickly, yet allow the advanced user the capability to customize the framework to their needs. I like Ted's one DTD idea to bring everything together, yet provide import-type capability to let those that perfer multiple files split out sections. I also like Spring's idea of separating the configuration from the code, to allow for alternate configuration schemes which may not even use XML. I think we should continue to strive for flexibility to allow innovative projects like Beehive to more easily explore new ideas and techniques. Don On Tue, 30 Nov 2004 10:47:23 -0600, Durham David R Jr Contr 805 CSPTS/SCE [EMAIL PROTECTED] wrote: Writing Java webapps should be easy. http://www.hacknot.info/hacknot/action/showEntry?eid=45 Kind of a lengthy read, but it seemed appropriate. - Dave - 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]
Struts API Bean (was Spring dreaming)
On the topic of a Struts API bean, I completely agree. We should have one bean, probably actually stored in the servlet context, which contains references to all the Struts-specific components like configuration elements and message resources. Now this, and the Spring topic, do overlap since this API bean could actually be a Spring BeanFactory which might be a more flexible approach actually. This would be separate from the ActionContext idea which would hold references to objects necessary for the execution of actions (chain context, http request/response, all current Action helper methods, etc). Ted, in fact, suggested an API bean previously as well, and I believe has even started sketching out what one might look like. Don Joe Germuska wrote: While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Second call: add generic mapped property to ActionConfig
Sure, works for me :) Don Joe Germuska wrote: snip / Now, then: This whole thread started as a different question and was motivated by an earlier question. Assuming that we continue to use Digester to instantiate and populate ActionConfig objects, I would like to add a generic mapped property to ActionConfig so that rather than writing trivial and boring subclasses of ActionConfig, one can simply set properties on it. I'd make it a Properties because I'd expect it to have strings, but I would accept arguments to make it a map instead with the idea that later other Objects might get in there. (Ugh, but all that casting!) Assuming no one objects in the next day or two, I'll assume it's ok, and I'll call it props, just because I would rather not screw around waiting for another name. The motivation for this was a perceived flaw in the ChainAction and chain DispatchAction classes which won't know in which catalog to look for the command either one is supposed to execute. A generic property map would allow the ChainAction to define the name of the properties it wants for its configuration, rather than requiring that its ActionConfig implement some specific interface just to get one more property in. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts API Bean (was Spring dreaming)
I agree with everything you wrote, however, what I was specifically talking about was some sort of storage bean that all the global Struts components could be stored in, so we don't have all these Struts objects littering the servlet context. Yes, for each request, a ViewContext instance would be created, initialized with this storage bean. Don Ted Husted wrote: The public API bean (where the rubber meets the road) could *not* be stored in application scope, since some of the Struts resources are request and session based. The original idea was the ViewContext (fka ConfigHelper) would be created on a per-request basis (like a Velocity tool). The ViewContext might hold references to members in request, session, or application scope, but the ViewContext client doesn't need to know that. All of the tags and tools can then refer to the ViewContext, rather than having to know where all the bodies are buried. The ViewContext interface could be based on the Velocity tools APIs (http://jakarta.apache.org/velocity/tools/struts/). I worked with these guys initially, and they are very tough about defining what you need, but no more. Internally, we might want to define an ActionContext that provides the same utility as the Action class and would also include the properties from the ActionForm. The idea being you could recode an Action class to use an ActionContext just by changing the references. Aside from the Action, we might also define a ResourceContext subset that could be shared with the business layer. The ResourceContext would include the messaging methods, so that the business layer could create Commons Resources messages (as part of a Command) and return them to Struts. This is an interface that we might define as part of the Commons Resources project, so that it is not tainted as a Struts import. Of course, the ActionContext would implement ResourceContext, so that we can exchange the same object with the business layer. All of these interfaces would implement Commons Chain Context (hence the suffix). The ActionContext could be called from an ActionCommand interface, a Chain Command-like interface with one method: void Execute(ActionContext context) Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API. I would suggest we implement these interfaces as experimental in 1.3.x, so that we can work with them ourselves for a while. In 1.4.x, we could do things like refactor for Spring, and then finalize the new interfaces in 1.5.x. I know I should reduce this to code, but I'm away this week, and trying to keep a few balls in the air until I get back. Eventually, we may to put a collection of Controller beans in application scope, open per module. This might be a place where a BeanFactory might be useful, but I think there are some other issues we need to iron out first. (Else start the revolution!) -Ted. On Tue, 30 Nov 2004 16:00:49 -0800, Don Brown wrote: On the topic of a Struts API bean, I completely agree. We should have one bean, probably actually stored in the servlet context, which contains references to all the Struts-specific components like configuration elements and message resources. Now this, and the Spring topic, do overlap since this API bean could actually be a Spring BeanFactory which might be a more flexible approach actually. This would be separate from the ActionContext idea which would hold references to objects necessary for the execution of actions (chain context, http request/response, all current Action helper methods, etc). Ted, in fact, suggested an API bean previously as well, and I believe has even started sketching out what one might look like. Don Joe Germuska wrote: While I'm one who has had good experiences with Spring's BeanFactory for managing my business objects, maybe we should focus first on defining what Struts is and what needs to be configured. This would allow us to move more flexibly to various configuration approaches, or conceivably support more than one. I've been thinking for a while that we should stop storing so many things directly in the ServletContext and instead, define a Struts object which would hold these things. I've mentioned this obliquely a few times and not gotten much response, so maybe no one else likes the idea. Or maybe it's been too oblique. Benefits of something like this would be reducing dependencies on the Servlet API and providing a better environment for testing. Is there any interest in this, or is it cracked? If it's not cracked, we might also take a longer-term look at abstracting the session, which seems tedious, but has some of the same issues. We may never need to truly abstract away the HttpServletRequest, since the Chain context will have the same lifecycle and serve about the same purpose. Now, then: This whole thread started as a different question and was motivated by an earlier question
Re: Call me crazy, but I want it all.
As I understand it, the key to improving the build, be it Maven or Ant,
is who will get the job done. There used to be quite a bit of interest
in a Maven build, and some progress was made toward a conversion,
however, the work was never completed. If someone stepped up and
completed the Maven conversion, it would probably be adopted. However,
if someone (Martin?) improved the Ant build to add jar retrieval tasks
and make it easier to use, it would be adopted instead.
Personally, from what I've seen, there isn't really something Maven can
do that Ant can't or vice versa, but rather a matter of how easy/elegant
the solution will be and more importantly, who will do it.
And whoever does it will earn my eternal gratitude. :)
Don
Ted Husted wrote:
It's definitely clean-up time, Jim.
The plan for 1.3.x is to separate the core, taglibs, and apps into separate projects.
The reason our current Maven build is ineffective is because project layout has grown in the telling.
The next step is to create standard Maven project layouts for each of the
subprojects, so that they are easy to build with Maven or Ant.
All someone has to do is make it so.
-Ted.
On Thu, 09 Dec 2004 11:36:10 -0500, James Mitchell wrote:
No, this is not spam.
Am I the only one frustrated with our current build situation?
This is my selfish desire for a clean build of all things under
struts/*
A friend and I were discussing some of the recent goings-on and
just for the hell of it I decided to try to build and deploy all of
the example applications: struts-mailreader struts-examples struts-
blank struts-documentation tiles-documentation mailreader-chain
strutsel-exercise-taglib.war struts-faces struts-faces2
Perhaps I'm missing something, but it took me quite a while to do
this from scratch. I chose to use a common build.properties in my
${user.home} directory. So I had to constantly go back and forth
adding/changing the jar references. It seems like almost all of
the build.props.sample files were out of date. And some builds
used one version of a jar, while others were using an older version.
And to this day, I still cannot deploy the mailreader-chain by
configuring a tomcat context to point to my local mailreader-
chain/target/mailreader. It keeps barfing, saying it can't find
/WEB-INF/struts-config/struts-config.xml, which, if I zip up the
directory and deploy it to webapps, it's fine. :(
What's even more confusing is how different the maven project jar
dependencies are vs the ant jar for the SAME PROJECT. Can you say
CLEAN UP TIME?
When you look at each piece of the puzzle individually, they look
fine. But when you try to put the entire puzzle together, it's
pretty nasty.
Anyway, sorry for venting.
Is there any interest in cleaning some of this up?
Can we remove all the maven build stuff? Since:
a) Our Maven build does nothing except build a source and binary
dist of struts.jar
b) Our ant build does everything that needs to be done (and then
some) c) Craig does the nightly builds and has no interest in
changing to maven
Note: Before anyone flames me, I actually prefer Maven over Ant for
all new projects, it's just not working for us here and now.
Also, why do we have so many copies of the mailreader example all
over the place? Why can't we just keep one copy and have a build
that can handle building for core or chain or shale or xyz?
--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx
- 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: commons-chain: joining with struts
The summary of our discussion, as I understand it, would be to create a ActionContext, which would not be a subclass of any commons-chain contexts, but would contain the commons-chain, probably WebContext instance available via a getter. This would allow us to have one ActionContext instance, and not have to subclass the different faces, portlet, and servlet instances. The Action class would be replaced by an Actionable (name not decided) interface which would have one method, execute(ActionContext ctx). This ActionContext would also have basically all the methods from Action like saveToken(), etc. Don Joe Germuska wrote: As one of the Struts developers who is very keen on moving chain-integration forward, I'll say a few brief words. I'm not on the commons-user list, but I will say that Sean's right that this discussion is best suited to struts-dev. (I'll leave commons-user on this message, but I'd encourage anyone else who responds to only reply to [EMAIL PROTECTED]) Anyway, we've talked about a StrutsWebContext, and in fact, we've talked about a few different subclasses of o.a.c.chain.Context for use in different phases of the request process. You may want to look through the mailing list archives, as this has been a pretty active topic of discussion in the last 2-3 months. Now that Chain has hit a full release, we are definitely planning on moving ahead with changing the default request processor in Struts to be based on commons-chain. The struts-chain project which is currently available from the subversion repository is a very healthy working implementation. The migration to the Struts core will mostly involve building in a mechanism for initializing any number of catalogs (obsoleting a Plugin class which does it in struts-chain). But I absolutely agree that it makes sense to make type-safe subclasses of Context which clarify the names and types of important participants in the Struts request processing chain. I would only argue that we'd probably like to keep Web from being too visible, as we feel in Struts that it would be good to decrease explicit dependencies on the Servlet API. Best, Joe At 1:18 PM -0500 12/15/04, Sean Schofield wrote: Pedro, A StrutsWebContext class might be an interesting idea. If adopted, it should go in the struts-chain project as opposed to commons-chain. (I am sending a copy of this response to the struts-dev mailing list which is probably the best place to propose this kind of enhancement). I'm not sure how useful it would be to have the ActionForm in your commands but I don't work a lot on struts-chain so maybe others have an opinion on that. If you decide to go ahead with submitting an official patch (or just using it in your own projects) the code should probably be modified to take advantage of recent changes to commons-chain. Specifically, you can now use CatalogFactory to get a copy of the catalog you're interested in. Just make sure to setup the o.a.c.c.w.ChainListener with the appropriate parameters, and it will configure the catalog when the webapp starts and it will automatically be available to any java class using the same class loader (including your proposed CommandAction). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-chain: joining with struts
ActionContext could certainly, and probably will be, a subclass of o.a.c.c.Context but my point is it will not be a subclass of the ServletWebContext, which struts-chain creates and passes through its commands. Don Vic wrote: Ah... can someone educate me as to why not just subclass chain context, would it not let you just do the same thing you said bellow? (and w/o servlet api). .V Don Brown wrote: The summary of our discussion, as I understand it, would be to create a ActionContext, which would not be a subclass of any commons-chain contexts, but would contain the commons-chain, probably WebContext instance available via a getter. This would allow us to have one ActionContext instance, and not have to subclass the different faces, portlet, and servlet instances. The Action class would be replaced by an Actionable (name not decided) interface which would have one method, execute(ActionContext ctx). This ActionContext would also have basically all the methods from Action like saveToken(), etc. Don - 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]
Subproject web pages
I added the struts-bsf as a Struts subproject, and am now looking to create a website for it to add to the Struts site. How should I go about this? Will it be built with Anakia? Should it be created as part of the Struts site build? Thanks for the help. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subproject web pages
Martin Cooper wrote: On Thu, 16 Dec 2004 21:18:16 -0800, Don Brown [EMAIL PROTECTED] wrote: I added the struts-bsf as a Struts subproject, Strange - the only commit message I've seen is the one to remove .cvsignore files. I would have expected to see an add message... The commit message was huge (100k) so the mail server rejected the message. I can forward it to you if you wish. :) and am now looking to create a website for it to add to the Struts site. How should I go about this? Will it be built with Anakia? Should it be created as part of the Struts site build? For now, I think the expedient thing to do is to add it to the regular site build. At some point, I'd like to see us have a separate 'site' subproject that each of the other subprojects contribute to, including 'core'. This will also force us to think about what is documentation (e.g. user guide) and what is web site (e.g. most of the stuff in the nav bar on the Struts site other than the Documentation section), get away (I hope) from a war file as our means of publishing documentation (and the site), and come up with a better way of updating the site reliably. But that's a future itch, for another day. ;-) Ok, I'll add the files to the main Struts site. Thanks. Don -- Martin Cooper Thanks for the help. Don - 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]
Struts chain integration
Who is working on bringing Struts chain into Struts core? If no one, I wouldn't mind doing the integration. I'm thinking about using the ComposableRequestProcessor to keep as much backwards compatibility as possible. The changes I'm proposing by layer: web.xml - A chainConfig parameter to override default catalog. If none specified, a default chain config will be loaded from the Struts jar. - A chainCommand parameter to specify the command to execute if none specified in modules (optional) struts-config.xml - The default request processor class would now be ComposableRequestProcessor, but the legacy ones would still be available (deprecated) - The controller would have additional optional attributes: - chainConfig - path of chain config to override default chain catalog. Cannot be used if catalog is specified. - catalog - name of servlet context attribute to locate catalog for this module. Cannot be used of chainConfig is used. - command - name of command to execute. Overrides default chain command name. - Remove the need for the chain plugin Of course, if someone is already doing the integration, ignore this. Otherwise, comments appreciated. I'll target the integration Sunday or Monday if I don't hear different. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Any objections to adding Ant get's to build.xml?
I'm setting up Struts to build from Ant (again), and have to go through the hassle of setting up build.properties. When I brought struts-bsf in, I changed its build.xml to, if a lib directory didn't exist, create one and use Ant's get task to pull the jars from ibiblio. It wouldn't be a long term solution to our building woes, but I figure if I have to go through the pain of setting up build.properties, I might as well make it easier for the next guy/gal. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts chain integration
Martin Cooper wrote: On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown [EMAIL PROTECTED] wrote: Who is working on bringing Struts chain into Struts core? If no one, I wouldn't mind doing the integration. I've been wondering the same thing. I have not done anything myself yet, so I'd be happy for you to take this on. ;-) I'm thinking about using the ComposableRequestProcessor to keep as much backwards compatibility as possible. The changes I'm proposing by layer: web.xml - A chainConfig parameter to override default catalog. If none specified, a default chain config will be loaded from the Struts jar. - A chainCommand parameter to specify the command to execute if none specified in modules (optional) I'm probably misunderstanding something, but ComposableRequestProcessor uses two context initialisation params for these already. Those names and default values seem fine to me. The idea of these in web.xml is the ability to specify a custom chainConfig that would be used as the default for all modules; same with the command name. My goal would be to make it possible to use an existing Struts 1.1/1.2 app without any changes. To meet this goal, all these configuration options are optional and defaults will be used if necessary. struts-config.xml - The default request processor class would now be ComposableRequestProcessor, but the legacy ones would still be available (deprecated) +1. One thing that I'm a little confused about, though, is that the new request processor is (currently) in a package that includes 'legacy'. Anyone know why that is? - The controller would have additional optional attributes: - chainConfig - path of chain config to override default chain catalog. Cannot be used if catalog is specified. Why would we need this, in addition to the catalog (below)? - catalog - name of servlet context attribute to locate catalog for this module. Cannot be used of chainConfig is used. Shouldn't this just be the catalog name, now that Chain has named catalogs? You could be right, I haven't looked into named catalogs so perhaps that would be the catalog name. The chainConfig optional would be to let the user specify a custom chain-config.xml file for that module (overriding the default chain catalog). - command - name of command to execute. Overrides default chain command name. Do the above controller config attributes override the web.xml ones, or, if not, how do they inter-relate? As mentioned above, these module-level configurations are all optional, and if specified, would override defaults possibly specified in web.xml. Don - Remove the need for the chain plugin Yup. If any of the above are stupid questions, my excuse is that I'm really tired, and probably shouldn't be replying tonight at all... ;-) Of course, if someone is already doing the integration, ignore this. Otherwise, comments appreciated. I'll target the integration Sunday or Monday if I don't hear different. Sounds great! -- Martin Cooper Don - 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: Any objections to adding Ant get's to build.xml?
Cool, I just remembered I can build the website w/o configuring build.properties so I'll just put that off. Good luck on that build cleanup *shudder* :) Don Martin Cooper wrote: I'm working on this right now. I have the 'get' stuff done locally, but there's some other build stuff I want to clean up before I commit that. (Last night's Cactus property clean-up was part of that.) -- Martin Cooper On Thu, 16 Dec 2004 22:10:50 -0800, Don Brown [EMAIL PROTECTED] wrote: I'm setting up Struts to build from Ant (again), and have to go through the hassle of setting up build.properties. When I brought struts-bsf in, I changed its build.xml to, if a lib directory didn't exist, create one and use Ant's get task to pull the jars from ibiblio. It wouldn't be a long term solution to our building woes, but I figure if I have to go through the pain of setting up build.properties, I might as well make it easier for the next guy/gal. Don - 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: Subproject web pages
Ted Husted wrote: I would say that new subprojects should start with a standard Maven build. Well, I used Ant for BSF for two reasons: 1) That's what I know, and I wouldn't know how to do the custom example webapp build procedures in Maven 2) Ant is the official build for Core I'm not against Maven per se so if a Mavenite wants to convert the build, I have no objection. Since the next step for 1.3 is creating subprojects for the core, taglibs, and such, I wouldn't worry about integrating it with the Struts build now, since the build is going to change for 1.3. It would just be wasted effort. I would suggest that we keep the subprojects as a separate builds and downloads for now, as we are doing with Struts-Faces. For now, we could just slip in a link to the subproject from the main site, until the other changes are made. Good, what's what I did for BSF Scripting. Is the website updated by some cron job, or does a committer have to refresh it? Don -Ted. On Thu, 16 Dec 2004 21:18:16 -0800, Don Brown wrote: I added the struts-bsf as a Struts subproject, and am now looking to create a website for it to add to the Struts site. How should I go about this? Will it be built with Anakia? Should it be created as part of the Struts site build? Thanks for the help. Don - 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]
[Fwd: svn commit: r122615 - in struts/bsf: . branches tags trunk trunk/src trunk/src/java trunk/src/java/org trunk/src/java/org/twdata trunk/src/java/org/twdata/struts trunk/src/struts-example trunk/src/struts-example/WEB-INF trunk/src/struts-example/WEB-INF/classes trunk/src/struts-example/WEB-INF/classes/org trunk/src/struts-example/WEB-INF/classes/org/apache trunk/src/struts-example/WEB-INF/classes/org/apache/struts trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory trunk/src/struts-example/WEB-INF/scripts trunk/xdocs]
Author: mrdon Date: Thu Dec 16 21:24:23 2004 New Revision: 122615 URL: http://svn.apache.org/viewcvs?view=revrev=122615 Log: Adding struts-bsf at version 0.5-dev with adjustments to remove need to store jars in repository Added: struts/bsf/ struts/bsf/.cvsignore struts/bsf/branches/ struts/bsf/tags/ struts/bsf/trunk/ struts/bsf/trunk/.cvsignore struts/bsf/trunk/build.xml (contents, props changed) struts/bsf/trunk/project.xml struts/bsf/trunk/src/ struts/bsf/trunk/src/java/ struts/bsf/trunk/src/java/org/ struts/bsf/trunk/src/java/org/twdata/ struts/bsf/trunk/src/java/org/twdata/struts/ struts/bsf/trunk/src/java/org/twdata/struts/BSFManagerFilter.java (contents, props changed) struts/bsf/trunk/src/java/org/twdata/struts/RequestToVariableFilter.java (contents, props changed) struts/bsf/trunk/src/java/org/twdata/struts/ScriptAction.java (contents, props changed) struts/bsf/trunk/src/java/org/twdata/struts/StrutsInfo.java (contents, props changed) struts/bsf/trunk/src/java/org/twdata/struts/TestFilter.java (contents, props changed) struts/bsf/trunk/src/struts-example/ struts/bsf/trunk/src/struts-example/WEB-INF/ struts/bsf/trunk/src/struts-example/WEB-INF/action.xml (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/app.tld (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/ struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/ struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/ struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/ struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/ struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/ struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/AlternateApplicationResources.properties struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/ApplicationMapping.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/ApplicationResources.properties struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/ApplicationResources_ja.properties struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/ApplicationResources_ru.properties struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/CheckLogonTag.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/Constants.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/ExpiredPasswordException.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/LinkSubscriptionTag.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/LinkUserTag.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/RegistrationForm.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/Subscription.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/SubscriptionForm.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/User.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/UserDatabase.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory/ struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory/MemoryDatabasePlugIn.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory/MemorySubscription.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory/MemorySubscriptionCreationFactory.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory/MemoryUser.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory/MemoryUserCreationFactory.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/classes/org/apache/struts/webapp/example/memory/MemoryUserDatabase.class (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/database.xml (contents, props changed) struts/bsf/trunk/src/struts-example/WEB-INF/scripts/
extends (was Struts chain integration)
Personally, I favor the approach Cocoon takes to modules. Cocoon is configured to use one sitemap (config file), but that sitemap can mount or include other sitemaps through the mount element. See http://cocoon.apache.org/2.1/userdocs/concepts/sitemap.html#Mounting+sitemaps Using wildcards, we could support a mount element which would basically mount a module config. mount could also be used as an include to include another struts config file full of definitions for the current module. Therefore, a module mount in Struts would look like this: action-mapping path=foo/* mount uri-prefix=foo src=/WEB-INF/struts-config-foo.xml / /action-mapping This simplifies the config and, IMO, makes the module design much more readable and straight-forward. Getting back to the extends idea, if we adopted an approach like described above, the main config file could have configuration elements that would automatically be inherited by modules, unless overridden. This would also let us break up config files for single modules, and even enable module hierarchies. Course the devil is in the implementation details :) Don Martin Cooper wrote: snip / I'm not keen on adding init params in general, and even less keen on adding such params that take lists of files. I do think we need to have a mechanism for specifying global stuff, but I think we can come up with a better way. For example, I don't like that I have to replicate the controller config in each module's struts-config.xml in a multi-module app. That's error prone. We've talked about allowing for extend for things like form bean definitions. What about having this concept right at the top of the config scheme? So I could define a global struts-config.xml file (which wouldn't be used directly by any module), and then extend that file to provide module-specific config files. If we added an optional section to struts-config, we could then specify a list of Chain config files in there. I would suggest skipping the chainConfig and chainCommand parameters in the web.xml in favor of explicitly setting them in each controller. Too many config options can be more trouble than they are worth. +1 The discussion of how to configure the Controller or the RequestProcessor touched off a lot of talk earlier on struts-dev, but I'd be happy to settle for two properties on ControllerConfig just to move forward. struts-config.xml - The default request processor class would now be ComposableRequestProcessor, but the legacy ones would still be available (deprecated) +1. One thing that I'm a little confused about, though, is that the new request processor is (currently) in a package that includes 'legacy'. Anyone know why that is? I don't know, but I think we should move it out to o.a.s.chain.ComposableRequestProcessor. Fine with me. - The controller would have additional optional attributes: I think the controller should simply have optional command and catalog attributes which would be used like this: CatalogFactory.getCatalog(catalog).getCommand(command) if no catalog is specified, the default catalog is retrieved with getCatalog(). If no command is specified, then these default values would be used: catalog = struts command = servlet-complete I believe that's what's in place now. If catalog were specified without a command, an exception would be thrown. I am still inclined to package most of what is now struts-chain separately from the core. I'm not so sure I agree here. Most, if not all, of the commands you list below are used by the chain that you suggest as a default above. I think if we want the ComposableRequestProcessor to be the default for 1.3, we really need to keep the commands in the core as well. However, I do think they should be pushed into a separate package. Just as we have o.a.s.actions, we could have o.a.s.chain.commands for these. -- Martin Cooper This may be part of why I haven't moved as quickly. Here are all the classes in struts-chain: org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn becomes obsolete org.apache.struts.chain.legacy.TilesPlugin can be made obsolete if we remove the check in the base TilesPlugin which insists on a specific request processor. I don't see any reason not to do that. org.apache.struts.chain.legacy.ComposableRequestProcessor org.apache.struts.chain.legacy.DispatchAction org.apache.struts.chain.legacy.ChainAction Move these three to core and up to o.a.s.chain org.apache.struts.chain.AbstractAuthorizeAction org.apache.struts.chain.AbstractExceptionHandler org.apache.struts.chain.AbstractExecuteAction org.apache.struts.chain.AbstractPerformForward org.apache.struts.chain.AbstractPerformInclude org.apache.struts.chain.AbstractPopulateActionForm org.apache.struts.chain.AbstractRequestNoCache org.apache.struts.chain.AbstractSelectAction org.apache.struts.chain.AbstractSelectForward org.apache.struts.chain.AbstractSelectInput
Re: Chain Integration Complete
ComposableRequestProcessor replaces RequestProcessor in Struts 1.3.x. RequestProcessor is still available and could be used by specifying the className in the controller config. Struts 1.2.6 is the latest development release and Struts 1.2.4 is the latest stable release, but all new development is taking place in struts/core/trunk containing Struts 1.3-dev. HTH, Don Sean Schofield wrote: I'm still a little fuzzy on the roadmap for struts. Now that struts-chain is in the core, does this mean we are moving towards using struts-chain over the current RequestProcessor? If so, what version is this anticipated to happen by? Finally, what is the branch being used for right now? TIA to anyone who can help clear this up for me. sean On Mon, 20 Dec 2004 23:30:31 -0800, Don Brown [EMAIL PROTECTED] wrote: As you may have noticed, I've completed the merge of struts-chain with Struts core (see the commit message for details). I would like to add this is meant as a step forward, not as my ultimate vision for how things should be, meaning if someone doesn't like a configuration property name or process, please feel free to discuss/change it. Next up: extracting the taglibs :) Don - 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: DispatchChainAction (Struts 1.3)
You raise a good point. Unfortunately, only one parameter can be passed through ActionMapping. DispatchChainAction really needs an allowedCommands parameter to specify what commands would be allowed. Perhaps we could use the new set/getProperty methods available in ActionConfig where allowedCommands could be specified. Don Benedict, Paul C wrote: I noticed in Struts 1.3 there is a DispatchChainAction, and the parameter attribute specifies the name of the chain to execute. Would somebody consider that a security hole? It seems like anyone could arbitrarily execute any chain command in the entire Struts app if they knew it -- unlike a normal DispatchAction whose parameter is only relevant for that Action class. Also, I hope there will be a MappingDispatchChainAction too. The MappingDispatchAction is, in my opinion, the absolute best feature of Struts 1.2 and secures the internals of the app better (i.e., not exposing method names to the world). However, it seems that it would be impossible to implement (currently) since the parameter attribute is already in use for the chain command. Thanks, Paul -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extracting taglibs
My basic assumption in approaching taglibs extraction into its own subproject is it can reference Struts classes, but Struts classes shouldn't reference it. If that is correct, here are the changes I see happening to extract taglibs: 1. Move o.a.s.taglib out into its own subproject src tree 2. Remove methods in RequestUtils that delegate to TagUtils. They are marked as deprecated anyways and explicitly say they will be removed after 1.2. 3. Move properties in o.a.s.taglib.html.Constants that are referred to in Struts core code into o.a.s.Globals. (cancel and token keys) 4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not sure about. Should/can tiles be used w/o its jsp taglibs? If not, then it should stay in core w/ tiles. Otherwise, it could be moved out too. That should be it, as far as I can tell. taglibs are already pretty well isolated from the rest of Struts which will make the extraction pretty straightforward. I'd like to get this done before Christmas (25th) if there are no objections. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extracting taglibs
It has been discussed, I believe, to separate Tiles from Struts, but no one seemed to know where it would go. jakarta-commons doesn't want taglibs, and for some reason I don't remember, the taglibs project wasn't accepted. It would be kinda funny, though, since Tiles used to be its own project that was assimilated into Struts when Struts was trying to divest iteself of code into commons. I mentioned the separation of Tiles from their taglibs as I thought I heard somewhere of Velocity being able to use Tiles. I could be wrong though. Don Eddie Bush wrote: Actually, I'd tend to agree with that. It makes more sense than separating Tiles and the Tiles taglibs - don't think you'd use the former without the latter. Maybe ... but I don't. On Tue, 21 Dec 2004 20:35:53 -0500, Deadman, Hal [EMAIL PROTECTED] wrote: Haven't look into this much but it would seem better to have a completely separate tiles sub-project that struts core would use. Don't JSF and Spring currently use tiles and have to include struts.jar when all they really want is tiles? -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 21, 2004 7:51 PM To: Struts Developers List Subject: Extracting taglibs My basic assumption in approaching taglibs extraction into its own subproject is it can reference Struts classes, but Struts classes shouldn't reference it. If that is correct, here are the changes I see happening to extract taglibs: 1. Move o.a.s.taglib out into its own subproject src tree 2. Remove methods in RequestUtils that delegate to TagUtils. They are marked as deprecated anyways and explicitly say they will be removed after 1.2. 3. Move properties in o.a.s.taglib.html.Constants that are referred to in Struts core code into o.a.s.Globals. (cancel and token keys) 4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not sure about. Should/can tiles be used w/o its jsp taglibs? If not, then it should stay in core w/ tiles. Otherwise, it could be moved out too. That should be it, as far as I can tell. taglibs are already pretty well isolated from the rest of Struts which will make the extraction pretty straightforward. I'd like to get this done before Christmas (25th) if there are no objections. Don - 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]
Request Bugzilla components
I'd like to request the following Bugzilla components be added: - bsf - sandbox If I do this myself, please point me in the right direction. Thanks. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extracting taglibs
Martin Cooper wrote: On Tue, 21 Dec 2004 20:25:55 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: I think a separate subproject for Tiles (including the code and the tags) probably makes the most sense. +1 If we don't mind the dependency back onto Struts, then this could also include the Struts PlugIn that is currently used to configure it -- although it would probably be better that this class stay part of Struts so that the Tiles library could be used stand alone. I'd prefer to see it the first way - Tiles has a (compile-time) dependency on Struts, and includes the plugin to be able to work with Struts. This is analogous to the way Commons Chain has compile-time dependencies on Servlets, Portlets and JSF, enabling it to work in those environments if desired. A Velocity adapter could then also live within Tiles, along with any others that people want to develop. Having the Struts adapter be a part of Tiles doesn't prevent the Tiles library from being used standalone any more than the Servlets, Portlets and JSF adapters for Chain prevent its use outside all of those environments. I agree as well. This lets us follow a consistent approach to subprojects, where they may (and probably should) link to Struts core, but Struts core should not depend on them. As for extracting Tiles, I don't mind doing the work along with the taglibs, but I'll let someone more experienced with Tiles do the work to make it more useful as a standalone component. Don In addition, there should be mechanisms to configure the Tiles definitions even if Struts is not present, via TilesServlet (which I believe already exists?) and/or a new ServletContextListener implementation since we're willing to use Servlet 2.3. +1 -- Martin Cooper Craig On Tue, 21 Dec 2004 18:29:43 -0800, Don Brown [EMAIL PROTECTED] wrote: It has been discussed, I believe, to separate Tiles from Struts, but no one seemed to know where it would go. jakarta-commons doesn't want taglibs, and for some reason I don't remember, the taglibs project wasn't accepted. It would be kinda funny, though, since Tiles used to be its own project that was assimilated into Struts when Struts was trying to divest iteself of code into commons. I mentioned the separation of Tiles from their taglibs as I thought I heard somewhere of Velocity being able to use Tiles. I could be wrong though. Don Eddie Bush wrote: Actually, I'd tend to agree with that. It makes more sense than separating Tiles and the Tiles taglibs - don't think you'd use the former without the latter. Maybe ... but I don't. On Tue, 21 Dec 2004 20:35:53 -0500, Deadman, Hal [EMAIL PROTECTED] wrote: Haven't look into this much but it would seem better to have a completely separate tiles sub-project that struts core would use. Don't JSF and Spring currently use tiles and have to include struts.jar when all they really want is tiles? -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 21, 2004 7:51 PM To: Struts Developers List Subject: Extracting taglibs My basic assumption in approaching taglibs extraction into its own subproject is it can reference Struts classes, but Struts classes shouldn't reference it. If that is correct, here are the changes I see happening to extract taglibs: 1. Move o.a.s.taglib out into its own subproject src tree 2. Remove methods in RequestUtils that delegate to TagUtils. They are marked as deprecated anyways and explicitly say they will be removed after 1.2. 3. Move properties in o.a.s.taglib.html.Constants that are referred to in Struts core code into o.a.s.Globals. (cancel and token keys) 4. Move o.a.s.taglib.tiles to o.a.s.tiles.taglib This one I'm not sure about. Should/can tiles be used w/o its jsp taglibs? If not, then it should stay in core w/ tiles. Otherwise, it could be moved out too. That should be it, as far as I can tell. taglibs are already pretty well isolated from the rest of Struts which will make the extraction pretty straightforward. I'd like to get this done before Christmas (25th) if there are no objections. Don - 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] - 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
Re: Extracting taglibs
FWIW, so far, I extracted tiles and taglib into their own projects, and got both core and taglib compiling (haven't tried tiles yet). It took the steps I described earlier as well as moving some methods from TagUtils back into ResponseUtils. Of course, if ResponseUtils has been dreprecated long enough, I could remove that and make things a lot easier. I have yet to migrate all the tests, but that should be straightforward. Don Craig McClanahan wrote: On Tue, 21 Dec 2004 20:45:03 -0800, Don Brown [EMAIL PROTECTED] wrote: I agree as well. This lets us follow a consistent approach to subprojects, where they may (and probably should) link to Struts core, but Struts core should not depend on them. I hope this can actually be accomplished ... but I recall playing around with this particular separation when we had our testbed Subversion installation, and the interdependencies were much more invasive than I would have originally expected ... to the point that I deferred actually finishing this particular separation (since I was mostly focused on whether SVN made sense). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extracting taglibs
:) Actually, in the extraction I performed so far, I did just that and moved TilesPreProcessor into the o.a.s.tiles.commands package. There was one other class, o.a.s.actions.RedeployableActionServlet that I moved into o.a.s.tiles since it was full of references to TilesRequestProcessor. Don Joe Germuska wrote: At 10:24 PM -0800 12/21/04, Don Brown wrote: FWIW, so far, I extracted tiles and taglib into their own projects, and got both core and taglib compiling (haven't tried tiles yet). It took the steps I described earlier as well as moving some methods from TagUtils back into ResponseUtils. Of course, if ResponseUtils has been dreprecated long enough, I could remove that and make things a lot easier. I have yet to migrate all the tests, but that should be straightforward. I too think making a separate tiles subproject is a good idea. It does mean, though that we may want to move the TilesPreProcessor command out of the core, which then a dependency on commons-chain to tiles... but I do think that Struts shouldn't depend on subprojects. Or maybe this is another reason to package the commands separately from the core? That is *not* intended as any kind of i told you so, please don't read any kind of nagging into it! Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ViewUtils and UtilityFactory (was Extracting taglibs)
coming soon? Is that an offer? :) I like the API bean aka ViewContext aka ConfigHelper and agree it is a better solution. Reading over the API bean thread, Ted has convinced me this bean would actually be created for each request probably somewhere early in the chain. While it could be passed around via the Context, I'd vote to also store it in ThreadLocal so we could call ViewContext.getCurrentInstance() at any point. Assuming we'd have a CreateViewContext chain command, would we pass in the class names to instantiate for RequestUtils and ViewUtils as command attributes in the config? This would allow the util implementation to not only be module scoped but request scoped if desired since the user can have complete control over the chains. Don Joe Germuska wrote: At 12:33 PM -0800 12/22/04, Don Brown wrote: What about having a UtilityFactory class that provides RequestUtils and ViewUtils? It goes without saying we'd deprecate the static methods and delegate to new, non-static methods on an instance pulled from this factory. Does Struts have a consistent approach to factories and allowing code to replace the factory implementation? I know this would be a good opportunity to put Spring into the mix, but perhaps an abstract factory would be a good first step in abstracting implementation from usage. My first reaction is that an abstract factory is wasted effort if a Struts API bean is coming soon. I'd be more inclined to have something in the ActionServlet's initialization create and populate a Struts with the understanding that how the Struts is populated is a moving target. Eventually, I think you and I would agree on a vision which has Spring instantiate the Struts and set its requestUtils and viewUtils properties with implementation classes. Or are these utils module-scoped? Unless you're talking about a factory for the Struts object itself -- I just wouldn't want to see a proliferation of different factories when the end goal would probably make them obsolete... Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ViewUtils and UtilityFactory (was Extracting taglibs)
The problem with putting code like that into a command, is what if someone wants to replace the populate command, but doesn't want to re-invent the multipart stuff? I think there is a place for service functions, call them utils or whatever, implement common routines that one or more commands take advantage of. I agree these routines should not be lumped into one or two huge util classes. Ideally, these functions would be grouped into logical service classes fronted by interfaces, allowing multiple implementations. To pull of something like that cleanly, however, I believe we'd have to fully adopt an IoC/DI container like Spring. Don Niall Pemberton wrote: If a user requires a request scoped behaviour then wouldn't it be better if this was implemened in a Command rather than Utils? In my mind Utils should be more of a Global thing thats overriden rarely. I think one of the problems with current Struts is that sometimes too much has been put into utils. Take the form population as an example - whats in the RequestUtils populate method is mainly a load of stuff to handle mutipart parameters - then it just calls BeanUtils. The multipart stuff IMO would have been better keeping it in the RequestProcessor and in 1.3 should be in a Command. In my mind thats the great thing about the 1.3 Chain stuff in that there is less need to factor out stuff into Utils since plugging in different behaviours, re-using and overriding becomes much simpler. I'd like to see whats in Utils become smaller and more tightly focused as small fragments of common code. Niall - Original Message - From: Don Brown [EMAIL PROTECTED] To: Joe Germuska [EMAIL PROTECTED] Cc: Struts Developers List dev@struts.apache.org Sent: Wednesday, December 22, 2004 9:17 PM Subject: Re: ViewUtils and UtilityFactory (was Extracting taglibs) coming soon? Is that an offer? :) I like the API bean aka ViewContext aka ConfigHelper and agree it is a better solution. Reading over the API bean thread, Ted has convinced me this bean would actually be created for each request probably somewhere early in the chain. While it could be passed around via the Context, I'd vote to also store it in ThreadLocal so we could call ViewContext.getCurrentInstance() at any point. Assuming we'd have a CreateViewContext chain command, would we pass in the class names to instantiate for RequestUtils and ViewUtils as command attributes in the config? This would allow the util implementation to not only be module scoped but request scoped if desired since the user can have complete control over the chains. Don Joe Germuska wrote: At 12:33 PM -0800 12/22/04, Don Brown wrote: What about having a UtilityFactory class that provides RequestUtils and ViewUtils? It goes without saying we'd deprecate the static methods and delegate to new, non-static methods on an instance pulled from this factory. Does Struts have a consistent approach to factories and allowing code to replace the factory implementation? I know this would be a good opportunity to put Spring into the mix, but perhaps an abstract factory would be a good first step in abstracting implementation from usage. My first reaction is that an abstract factory is wasted effort if a Struts API bean is coming soon. I'd be more inclined to have something in the ActionServlet's initialization create and populate a Struts with the understanding that how the Struts is populated is a moving target. Eventually, I think you and I would agree on a vision which has Spring instantiate the Struts and set its requestUtils and viewUtils properties with implementation classes. Or are these utils module-scoped? Unless you're talking about a factory for the Struts object itself -- I just wouldn't want to see a proliferation of different factories when the end goal would probably make them obsolete... Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [struts-faces] JSF integration into Struts
Craig McClanahan wrote:
On Thu, 23 Dec 2004 12:31:19 -0800, Don Brown [EMAIL PROTECTED] wrote:
snip /
If that is correct, would it be possible to implement JSF within Struts
chain? Could a JSF implementation be decomposed into chain commands,
and therefore allow the user to mix and match?
You'd have to replace the standard implementation of JSF's Lifecycle
API while still ensuring that the JSF based functioning happens in the
correct order. To my mind, it's easier to decompose what Struts does
and bolt it onto JSF (basically the direction Shale is taking) versus
the other way.
I guess what I have in mind is the JSF integration approach Cocoon
takes. Every request enters Cocoon, then certain pipelines can choose
to hand the request off to JSF. Conceptually, I think it is a better
fit with the advantages of the respective frameworks. Cocoon and Struts
excel at a request-based approach, so it is a natural fit for them to be
the controller for all requests, JSF or not. JSF, as an event-based
framework, is a fine solution for components or complex, event-based
pages.
The end game here would be to make Struts a universal controller
implementation that could front-end JSF, Cocoon (as it can do now with
the Struts Cocoon plugin), continuations-based frameworks, or any other
more specialized controller implementation. IMO, chain is great for a
universal controller backbone, but poor/too-generic for an
application-level controller framework. Not every request/workflow
might be appropriate for JSF, but by putting it behind Struts, the
developer has the option how best to handle it.
I guess where I'm going with this is one of the huge advantages of an
event-based view framework like JSF is the ability to have
self-contained, complex components. On the other hand, I think
event-based approaches are poor at handling complex workflows as code
has to be split up into different event methods. It seems like a
perfect marriage would be event-based framework for the components, but
continuations-based framework for application events and actions.
Stay tuned next week for a Shale checkin that addresses the complexity
of managing dialogs -- I've made some good progress fleshing that out.
Continuations are definitely a good way to deal with serial workflows
like a wizard dialog, and I'd like to see us continue to explore that
avenue -- it's just not (yet?) obvious to me that they are optimal for
workflows with lots of branches in them.
Consider, for example, a dialog for handling authentication at a
portal that also allows self-registration and remember me cookies.
The various paths through this logic are essentially the same as the
front parts of MailReader (up to where you get to the main menu), plus
a bypass branch if the user's cookie is still there. For extra fun,
assume that the process of collecting user profile info takes multiple
screens, and that the user might at any point cancel the whole thing
(meaning no updates should show up in any database).
Actually, I think continuations really excel at workflows that involve
branches, because the power of a full scripting language is more capable
of handling such complex logic, as opposed to say a workflow system
based on XML.
All continuations really do is help you script the sequence of pages and
connect them into a logical process. In your example, the logic for
pulling authentication information out of cookies or a form POST would
be extracted to a Java class or helper Javascript method for simpler
apps. Continuations would help with the multistep process of collecting
information. Probably, it would go something like this:
if (!loginThroughCookies()) {
while (true) {
showPageAndWait(login);
if (context.requestParams[register] != null) {
showPageAndWait(login1);
if (context.requestParams[cancel] != null) {
continue;
}
showPageAndWait(login2);
if (context.requestParams[cancel] != null) {
continue;
} else {
registerUser();
}
} else if (loginThroughForm()) {
break;
}
}
}
// This step could also call the mainMenu function to start that
// workflow
showPageAndWait(mainMenu);
Keep in mind, I'm very new at continuations, so I'm sure someone more
knowledgable could make something simplier. One improvement is if you
use the Wizard framework I created for struts-flow, it would be even
simpler because the wizard framework would automatically handle HTML
form button clicks that went to the previous step.
Don
By decomposing JSF into commands, JSF could handle events from its
components, but application processes would be handled on a request
basis with Action's, continuation-capable flows, or whatever. I suppose
this would not be a real JSF implementation since JSF concepts like
navigation wouldn't be used.
Yep ... in that respect it would be like the current integration
library, bypassing that feature of JSF. Or, you could plug
Taglibs and Tiles Extraction Issues
I've made further progress in extracting tiles and taglibs, and have run into several issues I'd like to get some feedback on. 1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has a link to taglib's TagUtils.getScope(). I could copy this method over (it is a whole 5 lines), but this raises a larger question of subproject dependencies and distribution. Will each subproject have its own ibiblio entries? Ted suggested, and I agree, that subprojects will be bundled with Struts releases ala Linux distributions, but how do we communicate intra-subproject dependencies? 2. Mock objects. Currently, Struts contains mocks for the servlet, but these classes would be useful for subprojects as well. I suggest we adopt StrutsTestCase, or another test package, as a subproject or dependency 3. Cactus. I admit, I never got this working, and now with taglibs and tiles unit tests requiring Cactus, I'm not sure how to migrate that build process over, especially as we await the Ant reorganization Martin is working on. I'm leaning to committing all my changes once I got all the code compiling and let someone more knowledgable setup cactus for these two subprojects. Thanks for the help, Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taglibs and Tiles Extraction Issues
Martin Cooper wrote: On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown [EMAIL PROTECTED] wrote: I've made further progress in extracting tiles and taglibs, and have run into several issues I'd like to get some feedback on. 1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has a link to taglib's TagUtils.getScope(). I could copy this method over (it is a whole 5 lines), but this raises a larger question of subproject dependencies and distribution. Will each subproject have its own ibiblio entries? Ted suggested, and I agree, that subprojects will be bundled with Struts releases ala Linux distributions, but how do we communicate intra-subproject dependencies? The method is short, but it relies on a map that is set up in a static initialiser... If we want to make Tiles usable in the absence of Struts, as some people do, I think we'd have to clone the code within Tiles. Well, technically, Tiles would be dependent on Struts-taglibs, not Struts core, but I agree, cloning the method is the easiest solution here. I mainly was using it as an opportunity to raise the larger issue of subprojects depending on other subprojects. With respect to ibiblio, I think it would make sense to consider Struts as a group and Struts subprojects as artifacts within that group (using Maven terminology here ;). I think you're asking about inter-subproject dependencies, right? This is one of the pieces of the build system I haven't yet found a solution for that I'm happy with. But I'm not sure if you're asking about that, or about communicating the information to users. 2. Mock objects. Currently, Struts contains mocks for the servlet, but these classes would be useful for subprojects as well. I suggest we adopt StrutsTestCase, or another test package, as a subproject or dependency I still haven't taken the time to look at StrutsTestCase. If we used that for our own testing, I assume, from what you say, that we could then ditch the mock objects we have today? (What does StrutsTestCase use for its own unit tests?) Dunno, but I'll look into it. Don 3. Cactus. I admit, I never got this working, and now with taglibs and tiles unit tests requiring Cactus, I'm not sure how to migrate that build process over, especially as we await the Ant reorganization Martin is working on. I'm leaning to committing all my changes once I got all the code compiling and let someone more knowledgable setup cactus for these two subprojects. It looks like EL solved this by copying the build files. Obviously, this is, um, less than optimal, but until the new build is ready, perhaps we should do the same thing. On the other hand, I don't think we want to put a lot of effort to making this all work when the build system is changing (hopefully next week). -- Martin Cooper Thanks for the help, Don - 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: Taglibs and Tiles Extraction Issues
I don't know about the other Struts folks, but I think this is would be a great addition to Tiles. Initially, the Struts Tiles subproject could host Tiles, but as more adapters get added, and perhaps the Tiles community enlarges, there would be enough interest in hosting the Tiles project somewhere outside of Struts. As for adapters, the Tiles build could follow the pattern commons-chain uses to optionally build adapters as jars are available. Let me get the Tiles subproject setup, then we can start working on integrating this code. Don David Geary wrote: I have extracted a standalone version of Tiles from Struts 1.1. I've implemented a TilesServlet for using Tiles outside of Struts and a JSF view handler that forwards to a tile instead of a JSP page. I also have some cool examples. I was on the verge of starting an open source project for standalone Tiles that would focus on integration with other presentation technologies besides Struts, such as JSF, Velocity, Tapestry, etc. I want a Tiles version that I can use with JSP only, or with the framework of my choice. And I want Tiles to be integrated as smoothly as possible with my framework. I don't want to have to drag Struts around to do that. So, I'm not sure what to do with my code. Do my goals for a standalone Tiles align with the goals for the Tiles subproject within Struts? david Le Dec 24, 2004, à 3:30 PM, Martin Cooper a écrit : On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown [EMAIL PROTECTED] wrote: I've made further progress in extracting tiles and taglibs, and have run into several issues I'd like to get some feedback on. 1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has a link to taglib's TagUtils.getScope(). I could copy this method over (it is a whole 5 lines), but this raises a larger question of subproject dependencies and distribution. Will each subproject have its own ibiblio entries? Ted suggested, and I agree, that subprojects will be bundled with Struts releases ala Linux distributions, but how do we communicate intra-subproject dependencies? The method is short, but it relies on a map that is set up in a static initialiser... If we want to make Tiles usable in the absence of Struts, as some people do, I think we'd have to clone the code within Tiles. With respect to ibiblio, I think it would make sense to consider Struts as a group and Struts subprojects as artifacts within that group (using Maven terminology here ;). I think you're asking about inter-subproject dependencies, right? This is one of the pieces of the build system I haven't yet found a solution for that I'm happy with. But I'm not sure if you're asking about that, or about communicating the information to users. 2. Mock objects. Currently, Struts contains mocks for the servlet, but these classes would be useful for subprojects as well. I suggest we adopt StrutsTestCase, or another test package, as a subproject or dependency I still haven't taken the time to look at StrutsTestCase. If we used that for our own testing, I assume, from what you say, that we could then ditch the mock objects we have today? (What does StrutsTestCase use for its own unit tests?) 3. Cactus. I admit, I never got this working, and now with taglibs and tiles unit tests requiring Cactus, I'm not sure how to migrate that build process over, especially as we await the Ant reorganization Martin is working on. I'm leaning to committing all my changes once I got all the code compiling and let someone more knowledgable setup cactus for these two subprojects. It looks like EL solved this by copying the build files. Obviously, this is, um, less than optimal, but until the new build is ready, perhaps we should do the same thing. On the other hand, I don't think we want to put a lot of effort to making this all work when the build system is changing (hopefully next week). -- Martin Cooper Thanks for the help, Don - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where should the build system live?
Martin Cooper wrote: The new build system will consist of a few shared build files, and a per-subproject build.xml file. This leads to the obvious question of where the shared build files should live. There are basically two options, as I see it: 1) In a 'build' subproject. This is the cleaner option, and the one I prefer. It does mean that an additional subproject has be to checked out, but that would be true for all but one subproject in any case, and an independent 'build' subproject is pretty much guaranteed to be a lot smaller than any other subproject. 2) In 'core'. The only advantage I see to putting the build system in 'core' is that a single checkout would be enough to build 'core' itself. However, to build any other subproject, 'core' would need to be checked out as well. The main disadvantage I see to this option is that if another subproject comes along that we need to build before 'core', it would be icky to have that subproject depend on 'core' when 'core' depends on it. (This might sound like an unlikely scenario, but I actually believe that's exactly what would happen if we bring StrutsTestCase into the fold, since we'd need to build that before 'core' could be built and tested.) Hmm..this raises an interesting issue. When you mention build dependencies, do you really mean build one project then another in the same process, or just that one project would depend on a jar from another? In the case of StrutsTestCase, 1) I don't like Core being dependent on a subproject, so perhaps another neutral mock library should be used, and 2) even if the Core build depended on StrutsTestCase, it would be the latter and use a jar. As for the build organization, I lean towards 1, but I don't really feel strongly one way or another. Don So what do people think? My preference, as I said, is (1). -- Martin Cooper - 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: [action2] Switching to Dojo widgets
Ian Roughley wrote: Ok, I'll be more specific :) The tags that you use in JSP are directly available to other view technologies (freemarker and velocity) due to a common underlying component model. To make this possible they have their own MVC design - using a freemarker template as the view. So you can use any ajax library that you want. But if you create a new UI theme via templates, I think you are better encapsulating the logic. SAF/WW is by no means dojo specific, but dojo was the first ajax theme implemented, and it looks like the default out of the box. Ok, that's the theory, but in practice, different toolkits have widgets that support different parameters. Currently, we have a Component class, which has getters/setters for its parameters. Should this class have accessors for every possible parameter? Take, for example, the date picker widget. I just switched Action 2 to Dojo's Date picker. Unfortunately, it has very few parameters and supports no localization, however, the component class has a bunch of parameters, all supported by the old jscalendar Javascript library. Do I remove all the unsupported component class parameters and someone let users know they won't work, or do I replace them with parameters supported by the new date picker? Don /Ian netsql wrote: Struts 1.x was view independent. Is SAF2 (pronounced SafeTy? ;-) ) be dojo specific? Like I could not use Tibet w/out fighting the tags? (or JDNC once they figure that out.) .V ps: very exciting to have Ajax built in Ian Roughley wrote: This is where my knowledge of dojo falls short, perhaps Martin can assist. - 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: [action2] Switching to Dojo widgets
Ian Roughley wrote: This is where my knowledge of dojo falls short, perhaps Martin can assist. What I was planning on doing was using a compressed JS profile of dojo, and removing the individual files from the saf src. If we are pulling in individual files via dojo.require() do we need to keep the dojo src in the saf src? Since we are using Dojo now for tooltips, we are importing a minimal dojo profile on every page (simple/head.ftl). Therefore, I think it is important to keep this minimal, leaving components to require other parts of dojo as they need. The power user will override simple/head.ftl and import the exact parts of dojo it needs so the later requires won't have a performance impact. Don If you like I can assist, but I won't have time till late next week at the earliest. /Ian Don Brown wrote: Ian, what about using the minimal profile, but each component that needs something more can do a dojo.require() to pull it in? A user's application, that knows they need more, can overwrite head.ftl to change the profile. This is the change I plan to do today. Don Ian Roughley wrote: Martin - which profile do you suggest? I had a quick look over the profiles awhile back, and the only ones from the kitchen sick that I thought could be removed were flash and storage - especially with the incorporation of more widgets. The other option would be to have different profiles to download which are dependent on which widgets you are using, but this seems like it would be much more trouble as well as more custom configuration (which we have been trying to avoid). What are your thoughts? My other plan (to which I owe Jason an apology as I ran out of time) was to upgrade to 0.2.2 and use the compressed version rather than the exploded version. BTW - the dojo editor is already incorporated as an ajax themed textarea, however as for 0.2.1 it is still seems a little buggy. /Ian Martin Cooper wrote: On 4/12/06, Don Brown [EMAIL PROTECTED] wrote: I'm starting to look into replacing the LGPL Javascript components with ones provided by Dojo, a toolkit we are already using. Dojo already has the following widgets: - date picker - http://archive.dojotoolkit.org/nightly/tests/widget/test_DatePicker.html - tooltip - http://archive.dojotoolkit.org/nightly/tests/widget/test_Tooltip.html - rich text editor - http://archive.dojotoolkit.org/nightly/tests/widget/test_Editor.html My question is how should we handle the Dojo imports? Currently Dojo is only imported in the header of the ajax theme. I propose we import dojo.js in the header of the simple theme (which is imported by the other themes), leaving each component to do the dojo.require() call to ensure their widget is available. This makes sense to me. However, I think we should change the current strategy on the Dojo profile that's bundled by default. It looks like the kitchen sink profile is what's bundled today. It would make more sense, IMHO, to bundle the minimal profile (or at least somewhat more minimal than kitchen sink) by default, and to provide the kitchen sink as an option and / or provide instructions on how to construct a custom profile (which is really easy). I'm certainly willing to help out here. -- Martin Cooper Don - 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] - 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: svn commit: r394308 - in /incubator/webwork2/action/src/test: java/org/apache/struts/action2/views/jsp/ui/ resources/org/apache/struts/action2/views/jsp/ui/
Thanks Toby for fixing these tests. I keep forgetting WebWork, even its
tags, are so well unit tested :)
Don
[EMAIL PROTECTED] wrote:
Author: tmjee
Date: Sat Apr 15 08:45:00 2006
New Revision: 394308
URL: http://svn.apache.org/viewcvs?rev=394308view=rev
Log:
- fix failing test case
Modified:
incubator/webwork2/action/src/test/java/org/apache/struts/action2/views/jsp/ui/FormTagTest.java
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-1.txt
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-2.txt
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-3.txt
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-4.txt
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-5.txt
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-6.txt
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-7.txt
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-8.txt
Modified:
incubator/webwork2/action/src/test/java/org/apache/struts/action2/views/jsp/ui/FormTagTest.java
URL:
http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/java/org/apache/struts/action2/views/jsp/ui/FormTagTest.java?rev=394308r1=394307r2=394308view=diff
==
---
incubator/webwork2/action/src/test/java/org/apache/struts/action2/views/jsp/ui/FormTagTest.java
(original)
+++
incubator/webwork2/action/src/test/java/org/apache/struts/action2/views/jsp/ui/FormTagTest.java
Sat Apr 15 08:45:00 2006
@@ -23,7 +23,9 @@
import org.apache.struts.action2.config.Configuration;
import org.apache.struts.action2.views.jsp.AbstractUITagTest;
import org.apache.struts.action2.views.jsp.ActionTag;
+
import com.opensymphony.xwork.ActionContext;
+import com.opensymphony.xwork.ObjectFactory;
import com.opensymphony.xwork.config.ConfigurationManager;
@@ -31,13 +33,15 @@
* FormTagTest
*
* @author Jason Carreira
- * Created Apr 3, 2003 10:28:58 AM
+ * @author tm_jee
*
* @version $Date$ $Id$
*/
public class FormTagTest extends AbstractUITagTest {
public void testForm() throws Exception {
+ ObjectFactory.setObjectFactory(new MyObjectFactory());
+
request.setupGetServletPath(/testAction);
TestAction testAction = (TestAction) action;
@@ -363,4 +367,8 @@
ConfigurationManager.addConfigurationProvider(new
TestConfigurationProvider());
ActionContext.getContext().setValueStack(stack);
}
+
+static class MyObjectFactory extends ObjectFactory {
+
+ }
}
Modified:
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-1.txt
URL:
http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-1.txt?rev=394308r1=394307r2=394308view=diff
==
---
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-1.txt
(original)
+++
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-1.txt
Sat Apr 15 08:45:00 2006
@@ -6,3 +6,6 @@
script
function customOnsubmit() {}
/script
+
+!-- javascript that is needed for tooltips --
+script language=JavaScript
type=text/javascriptdojo.require(dojo.widget.html.Tooltip);dojo.require(dojo.fx.html);/script
Modified:
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-2.txt
URL:
http://svn.apache.org/viewcvs/incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-2.txt?rev=394308r1=394307r2=394308view=diff
==
---
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-2.txt
(original)
+++
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-2.txt
Sat Apr 15 08:45:00 2006
@@ -28,6 +28,10 @@
selectUnselectMatchingOptions(updownselectObj, null, unselect,
false, key);
}
/script
+
+!-- javascript that is needed for tooltips --
+script language=JavaScript
type=text/javascriptdojo.require(dojo.widget.html.Tooltip);dojo.require(dojo.fx.html);/script
+
script
function validateForm_myAction() {
form = document.getElementById(myAction);
@@ -36,3 +40,4 @@
var errors = false;
return !errors; }
/script
+
Modified:
incubator/webwork2/action/src/test/resources/org/apache/struts/action2/views/jsp/ui/Formtag-3.txt
URL:
Re: XWork and Struts Action 2.0
Whether XWork is moved to Apache or not, I 100% agree the docs and API should be in a single location. WebWork has been doing this for a while, and I think we should continue the practice. The relationship between Action 2 and XWork could be like Action 1 and Commons Validator - the user doesn't have to go to the Commons Validator site for docs; they are well-integrated. Don Bob Lee wrote: What's the plan for XWork? I would recommend against keeping it as a third party dependency and for copying the necessary code over into the Struts repository and refactoring it (clean up exception handling, remove statics, better integrate APIs, etc.). We could keep the Java packages separate (if we really think it's worth it), but there's definitely no need for two separate projects. Looking in two places for the documentation and API is a huge pain, not to mention confusing for new users. Bob - 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: XWork and Struts Action 2.0
Bob Lee wrote: Also, how do the tags relate to JSTL? Are we just going to ignore JSTL? Or are we going to use JSTL for JSP with some WebWork-specific extensions and the WebWork tags for other template engines? I personally prefer the latter option. Struts has always tried to work well with standards, and JSTL should be no exception. I guess the question is whether the overlap tags will be deleted or just deprecated. I'm fine with deleted. Are we going to continue using OGNL, or are we going to use JSP EL? This is a good, yet complicated question that has seen much discussion lately. The bottom line is there are features in OGNL that we can't live without: type conversions, projection, and method calls to name a few. If we can somehow either a) extend the JSP EL to support these features or b) implement OGNL behind the JSP EL API's, I see a future in closer collaboration. From what I understand, both are possible, just waiting for someone to step up and do the work. Good to see you on the list, and congrats on the marriage. I admit I was a little jealous as to its location :) Don Bob On 4/17/06, Jason Carreira [EMAIL PROTECTED] wrote: -1 to moving it over. XWork is not just part of WebWork, it's used other places. You're more than welcome to help do the cleanup in XWork for a 2.0 release. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=51716#51716 - 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: ww:radio
This is a great feature suggestion, so could you please open up a ticket on it so it doesn't get forgotten? At the moment, we are focused on getting out of the Incubator, but soon, we hope to address issues such as this. http://issues.apache.org/struts Don Ricardo Lecheta wrote: Hi, In webwork the ww:radio tag evaluates a list using ognl... The ww:radio from webwork is amazing, but sometimes you don´t want put a getList() in your Action. The html:radio from Struts is very easy to use, and you don´t need a collection to fill the radios.. Is it possible in SAF2 both of ww:radio from WW2 and html:radio from Struts exists? thanks, Ricardo - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26152messageID=51516#51516 - 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: XWork and Struts Action 2.0
Ian Roughley wrote: Don Brown wrote: Bob Lee wrote: Also, how do the tags relate to JSTL? Are we just going to ignore JSTL? Or are we going to use JSTL for JSP with some WebWork-specific extensions and the WebWork tags for other template engines? I personally prefer the latter option. Struts has always tried to work well with standards, and JSTL should be no exception. I guess the question is whether the overlap tags will be deleted or just deprecated. I'm fine with deleted. One of the features I like the most about the WW tags is themes. If we move to JSTL tags, is there a corresponding feature? This is the basis for the ajax integration. I don't think this is an either/or decision, but one of eliminating the overlap. JSTL provides some formatting, conditionals, loops, and XML manipulation, while Action 2 tags provide visual and form tags. The only reason we might want to keep the Action 2 tags that overlap is if they provide value for other presentation technologies, since JSTL is only for JSP. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action2] Java 5 support (was XWork and Struts Action 2.0)
This has been a topic I've been wondering about for a while: would it be possible to move to Java 5, then use a tool such as Retroweaver [1] to provide Java 1.4 support? I'm not prepared to completely abandon Java 1.4 users, but Bob does make some good points regarding the concern for falling too far behind. Does anyone have any experience with such an approach? Don [1] http://retroweaver.sourceforge.net/ Bob Lee wrote: Without saying whether we should support 1.4 or not, realistically we're talking about Struts 2.0.0 in production some time after August depending how long it takes users to port their applications, not right now, at this moment, right? JDK 1.6 comes out in the fall at which point 1.4 will be two major releases behind. We must embrace 1.5. We should keep in mind that: - 1.4 support will add complexity and require more development time - 1.4 will become less relevant pretty quickly - 1.4 users have two other options: Struts 1.2 and WebWork 2.2 Bob - 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: XWork and Struts Action 2.0
This is a great list, thanks for taking the time to put it up. I may not agree with everything, but it is sure to spark conversation :) Don Bob Lee wrote: On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote: I'll set up the rough spots page. http://wiki.apache.org/struts/RoughSpots?action=show Bob - 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: XWork and Struts Action 2.0
Patrick Lightbody wrote: We can definitely start by reading struts.xml rather than xwork.xml. +1, works great with struts-default.xml Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
Bob Lee wrote: I vote for struts-action.xml. +1 Don Bob On 4/19/06, Ted Husted [EMAIL PROTECTED] wrote: We might want to keep a straight-line mapping in the naming conventions, where OpenSymphony - Apache Struts WebWork - Action A good reason to prefer action-default.xml to struts-default.xml is that we want people to be able to use Struts Action 1 and Struts Action 2 in the same application space. We already have a struts-config.xml. While these file names don't actually conflict, it might be clearer to name the new configurations action rather than struts to avoid confusion. So, I would suggest that we use action-default.xml, and any place where we've started to say struts, we might consider saying action, so as to avoid confusion and conflict with Struts Action 1. -Ted. On 4/19/06, Don Brown [EMAIL PROTECTED] wrote: Patrick Lightbody wrote: We can definitely start by reading struts.xml rather than xwork.xml. +1, works great with struts-default.xml Don - 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: Keeping STATUS Current (was Re: friday ha ha)
I like the httpd one, clearly organized into sections that would be very helpful for guiding development. I think this is a great idea and vote we should adopt it too. Will shale, action, and tiles each have one, or will there be one for the whole project? Don Ted Husted wrote: On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: The bottom line is, IMO, the Struts project hasn't been as good as it could be at sharing our roadmap and vision with the user community. It is a personal goal of mine to improve this, and to see the continued success of both projects. One habit that Apache HTTPD practices, that we never learned at Jakarta, is the care and feeding of a STATUS file. Here's a link to the current HTTPD status file, which they post to the dev@ on a regular basis. * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS We do have a starter STATUS file in the SVN, * http://svn.apache.org/repos/asf/struts/STATUS.txt but if we want to get back to roadmap and communcation basics, I'd suggest this is the place to start. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping STATUS Current (was Re: friday ha ha)
Looking at it further, this could all be done with JIRA how, which would probably be an easier interface to use and have the bonus of collecting comments and patches. Perhaps we could use the Priority value to signify the type of issue much like that status file does for httpd? The WebWork team goes so far as using JIRA tickets for simple task management (assigning tickets, notifying the start of work on a ticket, etc). Perhaps we should use that more, then have JIRA send a status summary to dev@ much like Bugzilla does today. They also are strict about assigning tickets to milestones, like we've started to do. This will help guide expectations on what will be in what release. Don Ted Husted wrote: On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: The bottom line is, IMO, the Struts project hasn't been as good as it could be at sharing our roadmap and vision with the user community. It is a personal goal of mine to improve this, and to see the continued success of both projects. One habit that Apache HTTPD practices, that we never learned at Jakarta, is the care and feeding of a STATUS file. Here's a link to the current HTTPD status file, which they post to the dev@ on a regular basis. * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS We do have a starter STATUS file in the SVN, * http://svn.apache.org/repos/asf/struts/STATUS.txt but if we want to get back to roadmap and communcation basics, I'd suggest this is the place to start. -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]
[action2] Confluence migration
The confluence migration is one of the remaining issues before Incubator graduation, and here is the plan: 1. Export the data from OpenSymphony 2. Lock the OS WW wiki down to only the dev team for minor changes 3. Stand up a confluence instance, probably on my personal server, with the exported data 4. Migrate the content over to the new Struts Action 2 name 5. Export the data and import into a new ASF confluence instance when it is available Patrick and I plan to start the plan this weekend. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
Can we require these snapshot plugins in our POM somehow? I'm fine with working with snapshots, but their download and use should be automatic. Don Wendy Smoak wrote: On 4/18/06, Don Brown [EMAIL PROTECTED] wrote: We definitely need an action/src/site directory to contain the root site.xml that others inherit, and if you can get over the aforementioned issue, then collecting all docs there would work for me. I moved action/core/src/site up to src/site, and here's the aggregated Javadoc: http://cvs.apache.org/builds/struts/maven/test-site/struts-action/apidocs/ I'm working with snapshots of the site and javadoc plugins, so if any of the configuration causes a problem with the latest released versions, just comment it out or let me know. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bugzilla to JIRA migration
With our JIRA instance stood up, it is time to revisit our earlier decision to migration our Struts Bugzilla tickets to JIRA. http://issues.apache.org/struts I believe most of this work can be done without bothering infrastructure, as the import can be done through JIRA's web admin interface. Most of the committers don't have accounts, so please create one and let me know so I can give you the proper access. I propose we do the migration this weekend. Any comments/objections? Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugzilla to JIRA migration
Jeff Turner, who set this up, wanted separate instances, and in fact, he wants, IIRC, that to be how JIRA is used at Apache from now on. The separate instance allows each of our subprojects to have their own JIRA project, and helps isolate problems so that one instance won't bring all projects down. It also made the migration of existing WebWork tickets much easier, if not even possible. Don Sean Schofield wrote: Don, I've been off the list for a while now but can you explain why this is a completely separate JIRA instance from the other ASF projects? Why not use the existing one at http://issues.apache.org/jira? +1 (as always) for migrating to JIRA. I find Bugzilla to be unbearable compared to JIRA. I just don't see why a separate instance is needed. Sean On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: With our JIRA instance stood up, it is time to revisit our earlier decision to migration our Struts Bugzilla tickets to JIRA. http://issues.apache.org/struts I believe most of this work can be done without bothering infrastructure, as the import can be done through JIRA's web admin interface. Most of the committers don't have accounts, so please create one and let me know so I can give you the proper access. I propose we do the migration this weekend. Any comments/objections? Don - 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]
