Re: [PROPOSAL] Rename Struts Action as Struts
I am guessing the winner is going to be struts1/struts2 So if struts1 is: org.apache.struts If struts2: org.apache.struts2 ? Niall Pemberton <[EMAIL PROTECTED]> wrote: On 6/29/06, Don Brown wrote: > > I like struts1/struts2. +1 Niall > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/29/06, Don Brown <[EMAIL PROTECTED]> wrote: I like struts1/struts2. +1 Niall Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANNOUNCEMENT] Shale to Become Top-Level ASF Project
Hi Great news :) Hermod -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Martin Cooper Sent: Thursday, June 29, 2006 12:11 AM To: announcements@struts.apache.org; user@struts.apache.org; Struts Developers List Subject: [ANNOUNCEMENT] Shale to Become Top-Level ASF Project On behalf of the ASF Board and Struts PMC, we are pleased to announce that Shale has been accepted as a top-level project of the Apache Software Foundation. As a top-level project, Shale will have its own website, mailing lists, repository space, and Project Management Committee. Shale will be an automomous ASF project, rather than a subproject of Apache Struts. The Shale framework for JavaServer Faces is nearing its first stable release. As a top-level project, it will be easier for Shale to attract new developers and expand its growing community. The initial set of PMC members and committers for Shale is: * Craig McClanahan * James Mitchell * Greg Reddin * Sean Schofield * Wendy Smoak * Gary VanMatre * Matthias Wessendorf Apache Shale has strong ties to both the Struts and MyFaces projects. Most of the Shale PMC members are already involved in both projects, and plan on continuing to remain involved in them, along with Shale. Apache Shale is a modern web application framework, intended for developers adopting JavaServer Faces as a core technology. Shale began as a proposal for Struts 2.0, but instead became a subproject, so as to provide a JSF alternative for Struts developers. Recent developments for Struts Action 2 now make it easier for Struts developers to access JSF components from within an "action-based" application. The initial Shale codebase was donated by Craig McClanahan, who also donated the original Struts codebase. -- Martin Cooper PMC Chair, Apache Struts * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the anti virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Martin Cooper <[EMAIL PROTECTED]> wrote: On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > > Ted Husted wrote: > > Though, there's no reason why we couldn't use > > > >> repos/asf/struts/struts1 > >> repos/asf/struts/struts2 > > > > Or > > > >> repos/asf/struts/framework > >> repos/asf/struts/framework2 > > I like struts1/struts2. Yep, I do too. It's simple and straighforward - the best way to minimise confusion and make it obvious what goes where. +1. If we're not going to go with "codename" identifiers (although I'm personally partial to that ... all the Creator releases have had shark-themed names :-), then struts1/struts2 makes a lot of sense. The "generational" theme resonates, and encourages the correct amount of forethought before making substantively backwards incompatible changes. -- Martin Cooper Craig
Help in switching from http to https in struts
Hi , Iam developing application in struts which has login page and when username and password are given it should be authenticated and the page should be switched to https I had made necessary changes to include and login-config to include the user properties but the /display.jsp /error.jsp is forcing it to go to the pages which i give in form-login-page instead it should go to NameAction java file which extends Action and based on the logic there i should go to the required success or error page and iam not understanding the importance of like if i remove the lines /display.jsp /error.jsp i get the exceptions 18:59:15,687 WARN [FormAuthenticator] Unexpected error forwarding to login page java.lang.NullPointerException at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAut hen ticator.java:238) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticator Bas e.java:446) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.j ava :59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :12 6) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :10 5) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. jav a:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 48) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:85 6) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onn ection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint .ja va:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorker Thr ead.java:112) at java.lang.Thread.run(Thread.java:595) Could you please help me resolve this Note: The switching to https is happening the only thing is iam not getting the required result Regards Bhanu Thanks and Regards Bhanuprakash Singh Wipro Technologies Bangalore Contact#: ESN-6-877-5107 PBX: 28520408-Ext.83244 The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: Ted Husted wrote: > Though, there's no reason why we couldn't use > >> repos/asf/struts/struts1 >> repos/asf/struts/struts2 > > Or > >> repos/asf/struts/framework >> repos/asf/struts/framework2 I like struts1/struts2. Yep, I do too. It's simple and straighforward - the best way to minimise confusion and make it obvious what goes where. -- Martin Cooper Don > > > -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: Proposal for Struts 1.x: support for portlet-like components
Michael Jouravlev wrote: If this "not caring about any of that" is anything like ASP.NET coding, that this is not exactly true. Like, in ASP.NET there is a well-defined lifecycle. But if you (well, me) wants to get rid of POSTDATA situation, you need to call Response.redirect explicitly from event handler. And in this case you (ahem, me) cannot use default viewstate management. Of course, one could care less about that stuff as many do and think that the framework indeed allows you "not care about any of that". I think your right about the POSTDATA situation... although I'm not sure, WW might handle that too... I'm just learning, same as you :) Take a look at page 103... note that when you call ActionContext.getContext().getSession(), what you get back is a Map, not an HttpSession. That's really all I was referring to, the fact that your abstracted away from the servlet API. Also look at: http://www.opensymphony.com/webwork/api/com/opensymphony/xwork/ActionContext.html Note that the same is true of getParameters()... again, not tied to the servlet API. Expand your view though and the benefit becomes fairly obvious... a company that can change from a web-based application to a fat client, or vice versa, quickly and easily, without touching the "core" of the application, is highly agile, and more likely to succeed. > Come on, how many companies do that? Nothing is more eternal than temporary, or how do they say. In my friend's company they still use Dbase 3 for DOS applications just because stuff works. I think a lot more do than you realize. I know that I have some friends in larger organizations where it's very prevalent (even though it isn't yet in my company... although, we have been moving towards it over time). Bigger organizations tend to do it more, as you might logically expect. But, put that question aside for a moment... even if not many at all did it, most people these days agree it's better that way because you get people with certain domains of expertise working in the areas they are best at. I think you would agree that most coders aren't the best graphics artist, right? I know there's exceptions, and maybe your even one of them!, but I think its a fair generality. Why shouldn't it be true? We went to school to learn algorithms and data structures, not content flow, layout balance and color motifs! Let those folks do their jobs, and let us do ours. In that regard, the framework we use to build our applications should encourage that, no? Do you mean by building DispatchCommand or DialogCommand? And then slapping this command onto the chain... but I can replace Action as well. Oh I see, Action is not an interface, but Command is. Always keep forgetting this. I will think about it. Thanks! Pretty much, yes (although I don't know the precise details of how you'd implement your work in the chain, I just very much suspect it's almost trivial). It's less about a Command being an interface though and more about the fact that there is an infrastructure that allows you to add steps to the processing chain with ease. You used to have to do this by either subclassing the RP or Action, or maybe other things. Now, you just write a simple Command and modify the chain. It's one of those incredibly simple and obvious things that leads to great power :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for Struts 1.x: support for portlet-like components
On 6/28/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: Michael Jouravlev wrote: > From webapp > point of view, Command is as bad as Action. Meaning that HttpServlet > has doGet() and doPost() and therefore forces people to think what > kind of request they are processing and what method is better to use. I suggest taking a look at WW... note how you can code your Actions to not care about any of that. If this "not caring about any of that" is anything like ASP.NET coding, that this is not exactly true. Like, in ASP.NET there is a well-defined lifecycle. But if you (well, me) wants to get rid of POSTDATA situation, you need to call Response.redirect explicitly from event handler. And in this case you (ahem, me) cannot use default viewstate management. Of course, one could care less about that stuff as many do and think that the framework indeed allows you "not care about any of that". If you mean something different, maybe you can point to a particular place/feature of WW or chaper in the book? ;-) Expand your view though and the benefit becomes fairly obvious... a company that can change from a web-based application to a fat client, or vice versa, quickly and easily, without touching the "core" of the application, is highly agile, and more likely to succeed. Come on, how many companies do that? Nothing is more eternal than temporary, or how do they say. In my friend's company they still use Dbase 3 for DOS applications just because stuff works. > Um, I have to think on this paragraph, I have not got it yet, but > maybe I will get it later, after my head stop aching and I reread it > couple more times :) Yeah, definitely something to make sure you wrap your brain around... I could see you taking what your doing and making it just a different processing chain. That would probably be the best of both worlds. Do you mean by building DispatchCommand or DialogCommand? And then slapping this command onto the chain... but I can replace Action as well. Oh I see, Action is not an interface, but Command is. Always keep forgetting this. I will think about it. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Why does having the departure of Shale instigate nomenclature madness? :-) Struts Action Framework is actually a very professional title and I prefer we keep it as is. When Shale arrived, we tried various ways to differentiate the original framework from "Struts Shale" -- Struts Classic, Struts Core, and finally, Struts Action Framework. But to most people, Struts is just _Struts_. It always has been, and we never managed to convince them otherwise. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on 1.3.x
Paul Benedict wrote: I have two concerns on the 1.3.x line. What do you think? 1) Spring 2.0 has fabulous support for dependency injection for Struts. In particular, the great Autowiring(Tiles)RequestProcessor will automatically inject dependencies into the actions as they are created. This supports the "legacy" RequestProcessor and I have no personal plans to depart from its use. So my question today is: does the RP in 1.3 function just as it did in 1.2? If not, I may not want to upgrade to 1.3.x until it does. I would be willing to bet good money that in 1.3, you could integrate with Spring trivially easily without having to worry about an RP... just modify the chain to inject the dependencies after the Action is instantiated (I don't know the Commands in the chain off the top of my head, so I can't be any more specific than that). AFAIK, the "RP" in 1.3 does ultimately function the same as is 1.2, it just performs that set of functions in a wholly different way. It's a way that should make a lot of what you and Michael are talking about rather easy to implement without actually changing any core Struts code... that is in a nutshell the main reason for moving to the CoR-based RP (there's probably other reasons, but I suspect that's the most important one). 2) I learned the tough way that it is [a] impossible to write a stateless application in Struts and [b] use Struts' locality features at the same time. This is because Struts only stores the locale in the session, and there is no way (currently) to move that into a cookie, or into request scope. I found scattered code among RequestProcessor, RequestUtils and TaglibUtils which look only into the session for the current locale. I can't say for sure, but again, I'd bet on the power of the chain :) Incidentally, it's not so much the CoR pattern that's helpful here, it's the basic idea that small units of work are loosely coupled to form a larger processing cycle. That's where the true power comes from. You could implement that same thing without CoR (although arguably it'd still be CoR anyway). Paul Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on 1.3.x
Paul, not related to your issues (and I do not have answer/opinion on them), but more related to the message header: see more 1.3 issues/features/questions here: http://wiki.apache.org/struts/SAF1RoughSpots I don't know what is the best place to discuss all this stuff, here or in Wiki. I am ok with either. About sessions and pluggable implementations. I was thinking about borrowing FlashScope idea from Tapestry/Stripes. But you have generalized it, making it just pluggable storage. This is definetely something to think about! Stuff like FlashScope will help primarily implementing Redirect-After-Post (sure, what else can I think of) with greater ease. Also, ASP.NET has SQL database scope. Basically just MS SQL database configured for temp entries with automatic removal of orphaned/obsoleted entries. This is also something to consider. On 6/28/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I have two concerns on the 1.3.x line. What do you think? 1) Spring 2.0 has fabulous support for dependency injection for Struts. In particular, the great Autowiring(Tiles)RequestProcessor will automatically inject dependencies into the actions as they are created. This supports the "legacy" RequestProcessor and I have no personal plans to depart from its use. So my question today is: does the RP in 1.3 function just as it did in 1.2? If not, I may not want to upgrade to 1.3.x until it does. 2) I learned the tough way that it is [a] impossible to write a stateless application in Struts and [b] use Struts' locality features at the same time. This is because Struts only stores the locale in the session, and there is no way (currently) to move that into a cookie, or into request scope. I found scattered code among RequestProcessor, RequestUtils and TaglibUtils which look only into the session for the current locale. I propose (and I will write this) that we allow pluggable implementations into how to store the locale. It will be defaulted into the session, with other pluggable implementations provided. However (sorry fans of CoR) this implementation must be wrapped into a bean so that other libraries, like Tiles and Taglibs, can retrieve the locale and set it without knowing the pluggable strategy. So the solution itself cannot be limited to the RP chain, even though that is where it is initiated. Paul - Want to be your own boss? Learn how on Yahoo! Small Business. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
That's a good point Michael. My answer to it would be that it's just something we have to live with. Paul used the term "generation" to differentiate Struts 1.x from 2.x... to me though, "generation" has the same connotation as does "classic". I don't think there's any real contradiction though... you use the Win9x vs. WinNT comparison, and I think that's apt... they are both Windows in the end, just like both "generations", or whatever, would still be "Struts". Microsoft sometimes does back-port features... I don't think there's any difference between that and continuing to evolve 1.x and 2.x at the same time. The key I think is making it clear that 2.x really is something new, and I personally suspect largely incompatible in terms of migrating existing apps to it... if that winds up being true, then people are going to be very happy that 1.x continues to evolve, and I doubt it will be confusing if it's explained well. Frank Michael Jouravlev wrote: In this case we are returning to a half-year old situation, that is, Struts 2 is a new crown holder of a single unified project. Consider the announcements like this: "Struts team is proud to announce immediate availability of Struts 2.0 as a next version of popular Struts framework. New features include ... " and then: "Struts team releases Struts 1.4, the next version of popular Struts framework. New features include ... " Things have not got simpler after divorce :) I suppose that having Struts 2 as the next version works for you. But I afraid that it does not work well for those who think about releasing new versions of 1.x codebase. So, maybe Win9x vs. WinNT is not that bad idea after all? And look at them now, united. Now not only former NT users wait for Vista, but former 9x users too :-)) On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, etc... The whole point of this proposal is to unify Struts as a single project, getting away from this concept of separately versioned "subprojects". There will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps some day, Struts 3.x releases. Don Michael Jouravlev wrote: > You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts > 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version > 4.0 > > :-) > > 2.0 is a version number, while we are choosing project names (Are we?) > Do we treat Struts2 as the next version, or do we treat Struts and > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? > (Obviously I prefer the latter) > How version numbers correspond to project names? > Can Struts 2 subproject have version number higher than 2.x? (I think yes) > Can Struts [implied: 1] have version numbers higher than 1.x? > (theoretically yes, but that would be bizzare) > > On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote: >> +1 for Struts 2.0 >> >> Bob >> >> On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: >> > >> > With the departure of Struts Shale, I think it is time we return to the >> > idea of >> > Struts as a single, unified framework. While I had hoped we could >> do this >> > by >> > including Shale, everyone involved felt Shale deserved its own >> project and >> > so >> > I'm adjusting my original Struts 2.0 proposal to simply rename Struts >> > Action as >> > Struts. >> > >> > The ramifications of such a renaming up for discussion: >> > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes >> > Struts 2.0 >> > 2. We rename the >> https://svn.apache.org/repos/asf/struts/actionsubversion >> > directory as https://svn.apache.org/repos/asf/struts/framework, keep >> the >> > other >> > top level directories the same >> > 3. The org.apache.struts.action2 package becomes org.apache.struts2 >> > 4. action.* and struts-action.* configuration files become struts.* >> > 5. The SAF acronym in the documentation would return to Struts >> > >> > Given all the product naming changes in the last few years (much of >> which >> > was my >> > fault, I admit), I'd like to have these changes decided on soon, so >> we can >> > move >> > on to getting Struts 2.0 out the door. >> > >> > 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] -- Frank W. Zammetti Founder and Chief
Re: [PROPOSAL] Rename Struts Action as Struts
My two cents: I am okay with 1.x and 2.x numbering. It doesn't bother me. I look at them in terms of generations; different people who can live together in one family (webapp). Michael Jouravlev <[EMAIL PROTECTED]> wrote: In this case we are returning to a half-year old situation, that is, Struts 2 is a new crown holder of a single unified project. Consider the announcements like this: "Struts team is proud to announce immediate availability of Struts 2.0 as a next version of popular Struts framework. New features include ... " and then: "Struts team releases Struts 1.4, the next version of popular Struts framework. New features include ... " Things have not got simpler after divorce :) I suppose that having Struts 2 as the next version works for you. But I afraid that it does not work well for those who think about releasing new versions of 1.x codebase. So, maybe Win9x vs. WinNT is not that bad idea after all? And look at them now, united. Now not only former NT users wait for Vista, but former 9x users too :-)) On 6/28/06, Don Brown wrote: > I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, > etc... The whole point of this proposal is to unify Struts as a single > project, > getting away from this concept of separately versioned "subprojects". There > will be Struts 1.x releases, and there will be Struts 2.x releases, and > perhaps > some day, Struts 3.x releases. > > Don > > Michael Jouravlev wrote: > > You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts > > 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version > > 4.0 > > > > :-) > > > > 2.0 is a version number, while we are choosing project names (Are we?) > > Do we treat Struts2 as the next version, or do we treat Struts and > > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? > > (Obviously I prefer the latter) > > How version numbers correspond to project names? > > Can Struts 2 subproject have version number higher than 2.x? (I think yes) > > Can Struts [implied: 1] have version numbers higher than 1.x? > > (theoretically yes, but that would be bizzare) > > > > On 6/28/06, Bob Lee wrote: > >> +1 for Struts 2.0 > >> > >> Bob > >> > >> On 6/28/06, Don Brown wrote: > >> > > >> > With the departure of Struts Shale, I think it is time we return to the > >> > idea of > >> > Struts as a single, unified framework. While I had hoped we could > >> do this > >> > by > >> > including Shale, everyone involved felt Shale deserved its own > >> project and > >> > so > >> > I'm adjusting my original Struts 2.0 proposal to simply rename Struts > >> > Action as > >> > Struts. > >> > > >> > The ramifications of such a renaming up for discussion: > >> > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes > >> > Struts 2.0 > >> > 2. We rename the > >> https://svn.apache.org/repos/asf/struts/actionsubversion > >> > directory as https://svn.apache.org/repos/asf/struts/framework, keep > >> the > >> > other > >> > top level directories the same > >> > 3. The org.apache.struts.action2 package becomes org.apache.struts2 > >> > 4. action.* and struts-action.* configuration files become struts.* > >> > 5. The SAF acronym in the documentation would return to Struts > >> > > >> > Given all the product naming changes in the last few years (much of > >> which > >> > was my > >> > fault, I admit), I'd like to have these changes decided on soon, so > >> we can > >> > move > >> > on to getting Struts 2.0 out the door. > >> > > >> > 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] - Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
Re: [PROPOSAL] Rename Struts Action as Struts
In this case we are returning to a half-year old situation, that is, Struts 2 is a new crown holder of a single unified project. Consider the announcements like this: "Struts team is proud to announce immediate availability of Struts 2.0 as a next version of popular Struts framework. New features include ... " and then: "Struts team releases Struts 1.4, the next version of popular Struts framework. New features include ... " Things have not got simpler after divorce :) I suppose that having Struts 2 as the next version works for you. But I afraid that it does not work well for those who think about releasing new versions of 1.x codebase. So, maybe Win9x vs. WinNT is not that bad idea after all? And look at them now, united. Now not only former NT users wait for Vista, but former 9x users too :-)) On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, etc... The whole point of this proposal is to unify Struts as a single project, getting away from this concept of separately versioned "subprojects". There will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps some day, Struts 3.x releases. Don Michael Jouravlev wrote: > You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts > 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version > 4.0 > > :-) > > 2.0 is a version number, while we are choosing project names (Are we?) > Do we treat Struts2 as the next version, or do we treat Struts and > Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? > (Obviously I prefer the latter) > How version numbers correspond to project names? > Can Struts 2 subproject have version number higher than 2.x? (I think yes) > Can Struts [implied: 1] have version numbers higher than 1.x? > (theoretically yes, but that would be bizzare) > > On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote: >> +1 for Struts 2.0 >> >> Bob >> >> On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: >> > >> > With the departure of Struts Shale, I think it is time we return to the >> > idea of >> > Struts as a single, unified framework. While I had hoped we could >> do this >> > by >> > including Shale, everyone involved felt Shale deserved its own >> project and >> > so >> > I'm adjusting my original Struts 2.0 proposal to simply rename Struts >> > Action as >> > Struts. >> > >> > The ramifications of such a renaming up for discussion: >> > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes >> > Struts 2.0 >> > 2. We rename the >> https://svn.apache.org/repos/asf/struts/actionsubversion >> > directory as https://svn.apache.org/repos/asf/struts/framework, keep >> the >> > other >> > top level directories the same >> > 3. The org.apache.struts.action2 package becomes org.apache.struts2 >> > 4. action.* and struts-action.* configuration files become struts.* >> > 5. The SAF acronym in the documentation would return to Struts >> > >> > Given all the product naming changes in the last few years (much of >> which >> > was my >> > fault, I admit), I'd like to have these changes decided on soon, so >> we can >> > move >> > on to getting Struts 2.0 out the door. >> > >> > 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]
Thoughts on 1.3.x
I have two concerns on the 1.3.x line. What do you think? 1) Spring 2.0 has fabulous support for dependency injection for Struts. In particular, the great Autowiring(Tiles)RequestProcessor will automatically inject dependencies into the actions as they are created. This supports the "legacy" RequestProcessor and I have no personal plans to depart from its use. So my question today is: does the RP in 1.3 function just as it did in 1.2? If not, I may not want to upgrade to 1.3.x until it does. 2) I learned the tough way that it is [a] impossible to write a stateless application in Struts and [b] use Struts' locality features at the same time. This is because Struts only stores the locale in the session, and there is no way (currently) to move that into a cookie, or into request scope. I found scattered code among RequestProcessor, RequestUtils and TaglibUtils which look only into the session for the current locale. I propose (and I will write this) that we allow pluggable implementations into how to store the locale. It will be defaulted into the session, with other pluggable implementations provided. However (sorry fans of CoR) this implementation must be wrapped into a bean so that other libraries, like Tiles and Taglibs, can retrieve the locale and set it without knowing the pluggable strategy. So the solution itself cannot be limited to the RP chain, even though that is where it is initiated. Paul - Want to be your own boss? Learn how on Yahoo! Small Business.
Re: 1.x - DTD Attribute Proposal
I temporarly withdrawl the proposal. It cannot be well represented until there is a component like view of the action classes, which you are proposing. If your stuff gets accepted, then perhaps I can add onto it. But until then... Paul Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 6/27/06, Michael Jouravlev wrote: > On 6/23/06, Paul Benedict wrote: > > I find two uses of action mappings in my applications. One loads data for > > view, another writes data and then goes to a view. These views, I suppose, > > would logically be "pages" if Struts were a page-based controller. But I do > > find this kind of use-case always cropping into my apps, and one of my > > biggest problems is that when I do a save or cancel, I have no automated > > stack that tells me what my last logical view was. > > > > So I'd like to propose allowing developers to mark actions as a page or a > > view (and I have not finialized my nomenclature, so please help me word it > > better). Then Struts can keep a running stack, at some N depth (maybe just > > 1), that would allow me to always return to the previous view. > > > > > > > > In the Action class: > > Action.findPreviousPageForward(); > > > > Thoughts, O comrades? > > Paul, first about "view" attribute. I bunnied up it first ;-) It is mine :-)) > > Now about going to a previous view. I guess that in attempt to break > from stateless page-oriented paradigm of many Struts apps I might have > gotten into confines of object-oriented paradigm. So please correct me > if I will be wrong here. > > To me, Action or Action/ActionForm combination represents a logical > web resource, or a business object if you will. It is usually a > stateful object: even if I don't use session, I might save its state > in the database. So to me, navigating to Action means "Hey, object, > show yourself in the way that corresponds to your current state". This > is particularly true when pages are fronted with Action classes. When > I navigate to a web resource I don't really know what will be shown. I > think that Craig had this idea in mind when he explained why > ActionForward should represent a logical outcome of an Action, not a > menu choice [1]. > > So, to me going to "previous view" does not make a lot of sense. What > if the object that is rendered by this view has changed its state or > has gone out of scope? > > Umm... From another point of view, you want to mark a whole mapping as > "view", this is different than marking a particular page. So, you mean > that some of your actions/resources can render themselves and some > cannot, and you want to keep count only of these that can? In this > case my argument above does not make much sense but I will keep it > anyway ;-) > > On the other hand, if it is an interactive application, a user must > always be presented with something to look at, right? So if response > is not immediately followed by a redirected request, it represents a > view. These views can be accounted for without modifying action > mapping. > > I think I miss something here :-) Maybe you want to say, that an > action can have different query parameters and thus one action will be > considered as different resources. While browser differentiates > resources by full URL including parameters, you want to differentiate > just by base URL, right? I guess this makes sense... > > Michael. > > [1] http://wiki.apache.org/struts/ActionForward Ok, I think I got it :) Say, you have a.do with page="true" Then you call b.do with no page attribute, this action does not return a view and forwards directly to c.do Then you fool around c.do, producing c.do?param1, c.do?param2, c.do?param3 Then you want to cancel your c.do action as if it were a dialog window. You want to return to a.do. You cannot simply use last URL, because it would be c.do?param2 since browser treats URL as different if they have different params. Am I right? Whenever you call an action, controller would verify if it is a "current" action. If yes, it won't add it to the "unwind list". Same with actions that do not produce views. I think this makes sense. It will be useful. Of course, if you open a new window after, say, c.do?param3 and the go to a previous action, you will get a.do in your second window. Is this a bug? I guess not. After all, if a user opens a new window he knows what to expect ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta.
Re: Proposal for Struts 1.x: support for portlet-like components
Michael Jouravlev wrote: Command is only better because it does not throw HTTP stuff right in one's face. Precisely the point :) > Is it really better? Maybe just for testing. Not just for testing... wouldn't it be great if you could take that same controller code, the code that really forms an application by the way because the business facade is really just a collection of (hopefully) loosely-coupled services, the control layer is what ties those services together to form an application, and truly slap on a whole new presentation to it? We've seen questions around here about putting a Swing interface on top of Struts... that's difficult with Actions precisely because it's tied to the servlet API. Remove that and your ability to reuse code goes up. > From webapp point of view, Command is as bad as Action. Meaning that HttpServlet has doGet() and doPost() and therefore forces people to think what kind of request they are processing and what method is better to use. I suggest taking a look at WW... note how you can code your Actions to not care about any of that. Action's only execute() method blurries vision, makes everything a web service so to speak. Many do not think on what kind of request they are actually processing and in what other interactions this Action or a business/UI object represented by this action participates. Your right... but you've just defeated your own argument :) Your describing why Action isn't the best idea... Command removes those problems... well, I suppose you could argue that it's a single abstracted context object being passed to a Command that actually does away with the "problems" :) I'd have to agree! After all, until developers move on to GWT or move back to Swing, they will continue developing against 1995 protocol. It is important to consider features, quirks and requirements of this protocol despite popular opinion that protocol-agnostic application is better thing. It's a popular opinion because there is great validity to it :) It's easy to limit your thinking to a subset of use cases out there, and in that subset, something like Command has not much benefit. Expand your view though and the benefit becomes fairly obvious... a company that can change from a web-based application to a fat client, or vice versa, quickly and easily, without touching the "core" of the application, is highly agile, and more likely to succeed. Business drives technology, not the other way around, at least, it's supposed to. Otherwise we'd all just be theoretical computer scientists :) Um, I have to think on this paragraph, I have not got it yet, but maybe I will get it later, after my head stop aching and I reread it couple more times :) Yeah, definitely something to make sure you wrap your brain around... I could see you taking what your doing and making it just a different processing chain. That would probably be the best of both worlds. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
I am very much against naming 1.x "Classic" . I think it's a horrible name. I think of classical music, classic cars, and anything that smells of belonging in a museum (stationary, old, idle, doesn't move, better looked at than used). Why do we need it? I am totally fond of action and action2. Why does having the departure of Shale instigate nomenclature madness? :-) Struts Action Framework is actually a very professional title and I prefer we keep it as is. Ted Husted <[EMAIL PROTECTED]> wrote: On 6/28/06, Michael Jouravlev wrote: > Also, hoping not to hijaack this thread I would suggest coming up with > codenames for 1.x and 2.x codebases. If we were to do that, the obvious choices would be Classic for 1.x and Action for 2.x. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.
Re: [PROPOSAL] Rename Struts Action as Struts
I propose code names Velvet and Rubert. Any objections? Michael Jouravlev <[EMAIL PROTECTED]> wrote: Mua-ha-ha :-)) +1 on renaming back. Also, hoping not to hijaack this thread I would suggest coming up with codenames for 1.x and 2.x codebases. This had been suggested and discussed long ago but was rejected. Why codenames make sense: * Job search. SAF1 and SAF2... oh... I mean, Struts 1.x and Struts 2.x are different, required skills are different. Having codenames will seriously help to narrow the search to desired framework. * Perception. While SAF2 might be a leap forward indeed, it is a leap sideways as well. Maybe a little. It is different enough. Codenames will level the perception. Like Chicago and Cairo, for example. * It is just fun. See Ubuntu distros for example. Anyway, I liked Classic for 1.x, still like it :-) Or instead of typing 1.x and 2.x let's say Struts 1 and Struts 2, where Struts 2 can easily have 3.x or 4.x version numbers. Or just Struts Sucky and Struts Non-sucky. Or Struts and StrutsWork. On 6/28/06, Don Brown wrote: > With the departure of Struts Shale, I think it is time we return to the idea > of > Struts as a single, unified framework. While I had hoped we could do this by > including Shale, everyone involved felt Shale deserved its own project and so > I'm adjusting my original Struts 2.0 proposal to simply rename Struts Action > as > Struts. > > The ramifications of such a renaming up for discussion: > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes > Struts 2.0 > 2. We rename the https://svn.apache.org/repos/asf/struts/action subversion > directory as https://svn.apache.org/repos/asf/struts/framework, keep the other > top level directories the same > 3. The org.apache.struts.action2 package becomes org.apache.struts2 > 4. action.* and struts-action.* configuration files become struts.* > 5. The SAF acronym in the documentation would return to Struts > > Given all the product naming changes in the last few years (much of which was > my > fault, I admit), I'd like to have these changes decided on soon, so we can > move > on to getting Struts 2.0 out the door. > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta.
Re: Proposal for Struts 1.x: support for portlet-like components
Niall's response has softened my position on the built-in action dispatching. In my own projects, I went ahead and created a common BaseAction which all my other actions extend from. The BaseAction uses EventDispatcherAction with a pre-written execute method for the dispatching; subclasses just override execute() if they don't want it or provide a different dispatcher in the constructor. Because it was so easy to write, I am +0 with Michael's idea. It's a good idea, but because it's so easy to implement, I don't know if it belongs in the Action. I just don't know (honestly). It's a very good idea but we have to corporately decide if we want that bolted into the framework. Paul Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 6/28/06, Niall Pemberton wrote: > I haven't read Michaels latest write up, so I don't know if its > substantially different, but last time I looked the only reason for > integrating the "dispatch" style into Action was (IMO) to encourage > its use. > If thats still true then my opinion is unchanged: > > http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 * Having dispatch stuff in Action will encourage using this pattern, I have no doubt about that. * Events/hadnlers definition becomes first-class element of action mapping. * Events/hadnlers can be defined in a clean well-documented fashion. * And after all, It does not hurt anywone. Really. :-) http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > Personally I'm against this because IMO it just adds > confusion/complexity to the Action class that is unnecessary > for users who don't want to use the "dispatch" style. Those who do not want to use it will just skip a chapter in the manual. Nothing else will affect them. The only visible part is event/handler mapping and they won't see it if they do not use it. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > I also think that the > current provision for "dispatch" flavours isn't a real barrier for > people to adopt the style that you're promoting here. I think if this approach were more official people would be more inclined to use it. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > Simply making the code changes you suggest will not shift > people's mindset - you would need to document the choices > available. I will do my best to document it, that's for sure. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > documentation is more important than merging the dispatch > logic into the Action class and if Action and DispatchAction > flavours were better documented you could achieve the same > without changing the code at all. The code in action would be cleaner, the event mapping would be clean and visible. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > I don't use any of the DispatchAction/ActionDispatcher flavours > and am happy with "simple" Actions. Then you won't even notice the change. Really, it does not affect you or anyone else who does not use this style. I am preparing an updated documentation on actions in Wiki. It already saw like 40 updates and will see even more :) I want to build the solid base about how common use cases are handled. I will do my best not to promote one style over the other. > I also think that the concrete Action class tied to the servlet API is > legacy Then why do you care about me enhancing it?! ;-) > and that if you want to inovate then the effort is better spent > focusing on the support for CoR/CoC in Struts 1.3 and the Command > interface (Commons Chain 1.1 even has a DispatchCommand :-) I use Action as request endpoint. I don't need a lot of features from it. I doubt that I will be using commands anytime soon instead of actions. If I wanted to use them as interceptors, I will always be able to terminate the chain with Action (tenses?) Command is only better because it does not throw HTTP stuff right in one's face. Is it really better? Maybe just for testing. From webapp point of view, Command is as bad as Action. Meaning that HttpServlet has doGet() and doPost() and therefore forces people to think what kind of request they are processing and what method is better to use. Action's only execute() method blurries vision, makes everything a web service so to speak. Many do not think on what kind of request they are actually processing and in what other interactions this Action or a business/UI object represented by this action participates. After all, until developers move on to GWT or move back to Swing, they will continue developing against 1995 protocol. It is important to consider features, quirks and requirements of this protocol despite popular opinion that protocol-agnostic application is better thing. > http://jakarta.apache.org/commons/chain/changes-report.html > http://jakarta.apache.org/commons/chain/apidocs/index.html > > The great benefit of Chain means that having an alternative set of > "request proces
Re: [PROPOSAL] Rename Struts Action as Struts
Did I miss something? :-) Perhaps the deliberations went on in private, because it's news to me!!! Congrats on Shale blossoming into its own project. Don Brown <[EMAIL PROTECTED]> wrote: With the departure of Struts Shale, I think it is time we return to the idea of Struts as a single, unified framework. While I had hoped we could do this by including Shale, everyone involved felt Shale deserved its own project and so I'm adjusting my original Struts 2.0 proposal to simply rename Struts Action as Struts. The ramifications of such a renaming up for discussion: 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes Struts 2.0 2. We rename the https://svn.apache.org/repos/asf/struts/action subversion directory as https://svn.apache.org/repos/asf/struts/framework, keep the other top level directories the same 3. The org.apache.struts.action2 package becomes org.apache.struts2 4. action.* and struts-action.* configuration files become struts.* 5. The SAF acronym in the documentation would return to Struts Given all the product naming changes in the last few years (much of which was my fault, I admit), I'd like to have these changes decided on soon, so we can move on to getting Struts 2.0 out the door. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better.
Re: [PROPOSAL] Rename Struts Action as Struts
I think it is as simple as Struts 1.3, Struts 1.4, Struts 2.0, Struts 2.1, etc... The whole point of this proposal is to unify Struts as a single project, getting away from this concept of separately versioned "subprojects". There will be Struts 1.x releases, and there will be Struts 2.x releases, and perhaps some day, Struts 3.x releases. Don Michael Jouravlev wrote: You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version 4.0 :-) 2.0 is a version number, while we are choosing project names (Are we?) Do we treat Struts2 as the next version, or do we treat Struts and Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? (Obviously I prefer the latter) How version numbers correspond to project names? Can Struts 2 subproject have version number higher than 2.x? (I think yes) Can Struts [implied: 1] have version numbers higher than 1.x? (theoretically yes, but that would be bizzare) On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote: +1 for Struts 2.0 Bob On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > > With the departure of Struts Shale, I think it is time we return to the > idea of > Struts as a single, unified framework. While I had hoped we could do this > by > including Shale, everyone involved felt Shale deserved its own project and > so > I'm adjusting my original Struts 2.0 proposal to simply rename Struts > Action as > Struts. > > The ramifications of such a renaming up for discussion: > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes > Struts 2.0 > 2. We rename the https://svn.apache.org/repos/asf/struts/actionsubversion > directory as https://svn.apache.org/repos/asf/struts/framework, keep the > other > top level directories the same > 3. The org.apache.struts.action2 package becomes org.apache.struts2 > 4. action.* and struts-action.* configuration files become struts.* > 5. The SAF acronym in the documentation would return to Struts > > Given all the product naming changes in the last few years (much of which > was my > fault, I admit), I'd like to have these changes decided on soon, so we can > move > on to getting Struts 2.0 out the door. > > 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] Rename Struts Action as Struts
You mean, Struts 2.0 version 2.0, then Struts 2.0 version 2.1, Struts 2.0 version 2.2, ..., Struts 2.0 version 3.0, ..., Struts 2.0 version 4.0 :-) 2.0 is a version number, while we are choosing project names (Are we?) Do we treat Struts2 as the next version, or do we treat Struts and Struts2 as separate subprojects like Win9x/Me vs. WinNT/2K/XP ? (Obviously I prefer the latter) How version numbers correspond to project names? Can Struts 2 subproject have version number higher than 2.x? (I think yes) Can Struts [implied: 1] have version numbers higher than 1.x? (theoretically yes, but that would be bizzare) On 6/28/06, Bob Lee <[EMAIL PROTECTED]> wrote: +1 for Struts 2.0 Bob On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > > With the departure of Struts Shale, I think it is time we return to the > idea of > Struts as a single, unified framework. While I had hoped we could do this > by > including Shale, everyone involved felt Shale deserved its own project and > so > I'm adjusting my original Struts 2.0 proposal to simply rename Struts > Action as > Struts. > > The ramifications of such a renaming up for discussion: > 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes > Struts 2.0 > 2. We rename the https://svn.apache.org/repos/asf/struts/actionsubversion > directory as https://svn.apache.org/repos/asf/struts/framework, keep the > other > top level directories the same > 3. The org.apache.struts.action2 package becomes org.apache.struts2 > 4. action.* and struts-action.* configuration files become struts.* > 5. The SAF acronym in the documentation would return to Struts > > Given all the product naming changes in the last few years (much of which > was my > fault, I admit), I'd like to have these changes decided on soon, so we can > move > on to getting Struts 2.0 out the door. > > 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]
Re: [PROPOSAL] Rename Struts Action as Struts
Ted Husted wrote: Though, there's no reason why we couldn't use repos/asf/struts/struts1 repos/asf/struts/struts2 Or repos/asf/struts/framework repos/asf/struts/framework2 I like struts1/struts2. Don -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: [PROPOSAL] Rename Struts Action as Struts
Big +1. I just wish we could have done it months ago when I (and others) said exactly the same thing. Oh well, better late then never. Frank Don Brown wrote: With the departure of Struts Shale, I think it is time we return to the idea of Struts as a single, unified framework. While I had hoped we could do this by including Shale, everyone involved felt Shale deserved its own project and so I'm adjusting my original Struts 2.0 proposal to simply rename Struts Action as Struts. The ramifications of such a renaming up for discussion: 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes Struts 2.0 2. We rename the https://svn.apache.org/repos/asf/struts/action subversion directory as https://svn.apache.org/repos/asf/struts/framework, keep the other top level directories the same 3. The org.apache.struts.action2 package becomes org.apache.struts2 4. action.* and struts-action.* configuration files become struts.* 5. The SAF acronym in the documentation would return to Struts Given all the product naming changes in the last few years (much of which was my fault, I admit), I'd like to have these changes decided on soon, so we can move on to getting Struts 2.0 out the door. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: > What do you think of... > > repos/asf/struts/struts > repos/asf/struts/struts2 Very true, I forgot that we have different directories for SAF1 and SAF2. The struts/struts is redundant, but I could live with that. But ViewVC might not :) It parses the tree in a strange way, and, depending on how it is configured, this namig pattern might lock out the "lower" struts. Though, there's no reason why we couldn't use repos/asf/struts/struts1 repos/asf/struts/struts2 Or repos/asf/struts/framework repos/asf/struts/framework2 -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
+1 for Struts 2.0 Bob On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: With the departure of Struts Shale, I think it is time we return to the idea of Struts as a single, unified framework. While I had hoped we could do this by including Shale, everyone involved felt Shale deserved its own project and so I'm adjusting my original Struts 2.0 proposal to simply rename Struts Action as Struts. The ramifications of such a renaming up for discussion: 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes Struts 2.0 2. We rename the https://svn.apache.org/repos/asf/struts/actionsubversion directory as https://svn.apache.org/repos/asf/struts/framework, keep the other top level directories the same 3. The org.apache.struts.action2 package becomes org.apache.struts2 4. action.* and struts-action.* configuration files become struts.* 5. The SAF acronym in the documentation would return to Struts Given all the product naming changes in the last few years (much of which was my fault, I admit), I'd like to have these changes decided on soon, so we can move on to getting Struts 2.0 out the door. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
I'm against "official" code names. We have had enough confusion in Struts with different names meaning different things, and we shouldn't pile on more names. If folks want to off-hand use code names, that's fine, but to have them used in code or documentation is too far. Version 1 and 2 are simple enough. Don Ted Husted wrote: On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: Also, hoping not to hijaack this thread I would suggest coming up with codenames for 1.x and 2.x codebases. If we were to do that, the obvious choices would be Classic for 1.x and Action for 2.x. -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: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: Also, hoping not to hijaack this thread I would suggest coming up with codenames for 1.x and 2.x codebases. If we were to do that, the obvious choices would be Classic for 1.x and Action for 2.x. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
Wendy Smoak wrote: On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: 2. We rename the https://svn.apache.org/repos/asf/struts/action subversion directory as https://svn.apache.org/repos/asf/struts/framework, keep the other top level directories the same What do you think of... repos/asf/struts/struts repos/asf/struts/struts2 Very true, I forgot that we have different directories for SAF1 and SAF2. The struts/struts is redundant, but I could live with that. Don ? I know it first glance it may look odd, but the first 'struts' is the project, and the second one is which framework, Struts [implied 1] or Struts 2. For example, see: http://cargo.codehaus.org/SVN Maven has repos/asf/maven/maven-1 http://svn.apache.org/repos/asf/maven/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: 2. We rename the https://svn.apache.org/repos/asf/struts/action subversion directory as https://svn.apache.org/repos/asf/struts/framework, keep the other top level directories the same What do you think of... repos/asf/struts/struts repos/asf/struts/struts2 ? I know it first glance it may look odd, but the first 'struts' is the project, and the second one is which framework, Struts [implied 1] or Struts 2. For example, see: http://cargo.codehaus.org/SVN Maven has repos/asf/maven/maven-1 http://svn.apache.org/repos/asf/maven/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
Mua-ha-ha :-)) +1 on renaming back. Also, hoping not to hijaack this thread I would suggest coming up with codenames for 1.x and 2.x codebases. This had been suggested and discussed long ago but was rejected. Why codenames make sense: * Job search. SAF1 and SAF2... oh... I mean, Struts 1.x and Struts 2.x are different, required skills are different. Having codenames will seriously help to narrow the search to desired framework. * Perception. While SAF2 might be a leap forward indeed, it is a leap sideways as well. Maybe a little. It is different enough. Codenames will level the perception. Like Chicago and Cairo, for example. * It is just fun. See Ubuntu distros for example. Anyway, I liked Classic for 1.x, still like it :-) Or instead of typing 1.x and 2.x let's say Struts 1 and Struts 2, where Struts 2 can easily have 3.x or 4.x version numbers. Or just Struts Sucky and Struts Non-sucky. Or Struts and StrutsWork. On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: With the departure of Struts Shale, I think it is time we return to the idea of Struts as a single, unified framework. While I had hoped we could do this by including Shale, everyone involved felt Shale deserved its own project and so I'm adjusting my original Struts 2.0 proposal to simply rename Struts Action as Struts. The ramifications of such a renaming up for discussion: 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes Struts 2.0 2. We rename the https://svn.apache.org/repos/asf/struts/action subversion directory as https://svn.apache.org/repos/asf/struts/framework, keep the other top level directories the same 3. The org.apache.struts.action2 package becomes org.apache.struts2 4. action.* and struts-action.* configuration files become struts.* 5. The SAF acronym in the documentation would return to Struts Given all the product naming changes in the last few years (much of which was my fault, I admit), I'd like to have these changes decided on soon, so we can move on to getting Struts 2.0 out the door. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for Struts 1.x: support for portlet-like components
On 6/28/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: I haven't read Michaels latest write up, so I don't know if its substantially different, but last time I looked the only reason for integrating the "dispatch" style into Action was (IMO) to encourage its use. If thats still true then my opinion is unchanged: http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 * Having dispatch stuff in Action will encourage using this pattern, I have no doubt about that. * Events/hadnlers definition becomes first-class element of action mapping. * Events/hadnlers can be defined in a clean well-documented fashion. * And after all, It does not hurt anywone. Really. :-) http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 Personally I'm against this because IMO it just adds confusion/complexity to the Action class that is unnecessary for users who don't want to use the "dispatch" style. Those who do not want to use it will just skip a chapter in the manual. Nothing else will affect them. The only visible part is event/handler mapping and they won't see it if they do not use it. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 I also think that the current provision for "dispatch" flavours isn't a real barrier for people to adopt the style that you're promoting here. I think if this approach were more official people would be more inclined to use it. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 Simply making the code changes you suggest will not shift people's mindset - you would need to document the choices available. I will do my best to document it, that's for sure. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 documentation is more important than merging the dispatch logic into the Action class and if Action and DispatchAction flavours were better documented you could achieve the same without changing the code at all. The code in action would be cleaner, the event mapping would be clean and visible. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 I don't use any of the DispatchAction/ActionDispatcher flavours and am happy with "simple" Actions. Then you won't even notice the change. Really, it does not affect you or anyone else who does not use this style. I am preparing an updated documentation on actions in Wiki. It already saw like 40 updates and will see even more :) I want to build the solid base about how common use cases are handled. I will do my best not to promote one style over the other. I also think that the concrete Action class tied to the servlet API is legacy Then why do you care about me enhancing it?! ;-) and that if you want to inovate then the effort is better spent focusing on the support for CoR/CoC in Struts 1.3 and the Command interface (Commons Chain 1.1 even has a DispatchCommand :-) I use Action as request endpoint. I don't need a lot of features from it. I doubt that I will be using commands anytime soon instead of actions. If I wanted to use them as interceptors, I will always be able to terminate the chain with Action (tenses?) Command is only better because it does not throw HTTP stuff right in one's face. Is it really better? Maybe just for testing. From webapp point of view, Command is as bad as Action. Meaning that HttpServlet has doGet() and doPost() and therefore forces people to think what kind of request they are processing and what method is better to use. Action's only execute() method blurries vision, makes everything a web service so to speak. Many do not think on what kind of request they are actually processing and in what other interactions this Action or a business/UI object represented by this action participates. After all, until developers move on to GWT or move back to Swing, they will continue developing against 1995 protocol. It is important to consider features, quirks and requirements of this protocol despite popular opinion that protocol-agnostic application is better thing. http://jakarta.apache.org/commons/chain/changes-report.html http://jakarta.apache.org/commons/chain/apidocs/index.html The great benefit of Chain means that having an alternative set of "request processing" steps becomes much easier and you could develop something more elegant to support your event style which would probably mean that the user doesn't need to use either the DispatchAction or ActionDispatcher at all. Um, I have to think on this paragraph, I have not got it yet, but maybe I will get it later, after my head stop aching and I reread it couple more times :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Rename Struts Action as Struts
With the departure of Struts Shale, I think it is time we return to the idea of Struts as a single, unified framework. While I had hoped we could do this by including Shale, everyone involved felt Shale deserved its own project and so I'm adjusting my original Struts 2.0 proposal to simply rename Struts Action as Struts. The ramifications of such a renaming up for discussion: 1. Struts Action 1.3 becomes Struts 1.3 and Struts Action 2.0 becomes Struts 2.0 2. We rename the https://svn.apache.org/repos/asf/struts/action subversion directory as https://svn.apache.org/repos/asf/struts/framework, keep the other top level directories the same 3. The org.apache.struts.action2 package becomes org.apache.struts2 4. action.* and struts-action.* configuration files become struts.* 5. The SAF acronym in the documentation would return to Struts Given all the product naming changes in the last few years (much of which was my fault, I admit), I'd like to have these changes decided on soon, so we can move on to getting Struts 2.0 out the door. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] Shale to Become Top-Level ASF Project
Martin Cooper wrote: On behalf of the ASF Board and Struts PMC, we are pleased to announce that Shale has been accepted as a top-level project of the Apache Software Foundation. As a top-level project, Shale will have its own website, mailing lists, repository space, and Project Management Committee. Shale will be an automomous ASF project, rather than a subproject of Apache Struts. The Shale framework for JavaServer Faces is nearing its first stable release. As a top-level project, it will be easier for Shale to attract new developers and expand its growing community. The initial set of PMC members and committers for Shale is: * Craig McClanahan * James Mitchell * Greg Reddin * Sean Schofield * Wendy Smoak * Gary VanMatre * Matthias Wessendorf Apache Shale has strong ties to both the Struts and MyFaces projects. Most of the Shale PMC members are already involved in both projects, and plan on continuing to remain involved in them, along with Shale. Apache Shale is a modern web application framework, intended for developers adopting JavaServer Faces as a core technology. Shale began as a proposal for Struts 2.0, but instead became a subproject, so as to provide a JSF alternative for Struts developers. Recent developments for Struts Action 2 now make it easier for Struts developers to access JSF components from within an "action-based" application. The initial Shale codebase was donated by Craig McClanahan, who also donated the original Struts codebase. -- Martin Cooper PMC Chair, Apache Struts Hey! Congratulations to Craig and the Gang from myself and the JAVAWUG, UK!!! -- Peter Pilgrim ( Windows XP / Thunderbird 1.5 ) _ ___ + Expert Java __ /_ ___ ___ ____ /__ / + Enterprise ___ _ /_ __ `/_ | / / __ `/__ __/ __ __/ + Design / /_/ / / /_/ /__ |/ // /_/ / _ /___ _ /___ + Architecture \/ \__,_/ _/ \__,_/ /_/ /_/ + Web New Age On Line Resume || \\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT] Shale to Become Top-Level ASF Project
On behalf of the ASF Board and Struts PMC, we are pleased to announce that Shale has been accepted as a top-level project of the Apache Software Foundation. As a top-level project, Shale will have its own website, mailing lists, repository space, and Project Management Committee. Shale will be an automomous ASF project, rather than a subproject of Apache Struts. The Shale framework for JavaServer Faces is nearing its first stable release. As a top-level project, it will be easier for Shale to attract new developers and expand its growing community. The initial set of PMC members and committers for Shale is: * Craig McClanahan * James Mitchell * Greg Reddin * Sean Schofield * Wendy Smoak * Gary VanMatre * Matthias Wessendorf Apache Shale has strong ties to both the Struts and MyFaces projects. Most of the Shale PMC members are already involved in both projects, and plan on continuing to remain involved in them, along with Shale. Apache Shale is a modern web application framework, intended for developers adopting JavaServer Faces as a core technology. Shale began as a proposal for Struts 2.0, but instead became a subproject, so as to provide a JSF alternative for Struts developers. Recent developments for Struts Action 2 now make it easier for Struts developers to access JSF components from within an "action-based" application. The initial Shale codebase was donated by Craig McClanahan, who also donated the original Struts codebase. -- Martin Cooper PMC Chair, Apache Struts
Re: OGNL - Getter and setter types must match
The restriction comes from the Java relection API semantics, not OGNL. A property can only have one type, so it makes sense that the getter and setter for a JavaBean property must agree on that type. Changing this would break compatibility with the JavaBean specification, at the least... L. Ian Roughley wrote: I'd be up for lifting the restriction, but I also don't have access to the code. /Ian Bob Lee wrote: Thanks for the explanation. What a silly restriction. Anybody up for removing it? I don't have access to the OGNL source. Bob On 6/27/06, Ian Roughley <[EMAIL PROTECTED]> wrote: I've come across this also, and the way I explained it was that it had something to do with matching getters and setters to be well formed java beans. Although I never took the time to look into it further. /Ian Bob Lee wrote: > I've run into this problem with OGNL where I want it to invoke a > setter, but > if there's a getter method with the same property name but a different > type, > OGNL will just fail silently. Why does it even care about the getter? > Anyone > have an idea of what's going on here? > > I'm working against the OGNL version that went out w/ WW 2.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: Proposal for Struts 1.x: support for portlet-like components
I haven't read Michaels latest write up, so I don't know if its substantially different, but last time I looked the only reason for integrating the "dispatch" style into Action was (IMO) to encourage its use. If thats still true then my opinion is unchanged: http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 I also think that the concrete Action class tied to the servlet API is legacy and that if you want to inovate then the effort is better spent focusing on the support for CoR/CoC in Struts 1.3 and the Command interface (Commons Chain 1.1 even has a DispatchCommand :-) http://jakarta.apache.org/commons/chain/changes-report.html http://jakarta.apache.org/commons/chain/apidocs/index.html The great benefit of Chain means that having an alternative set of "request processing" steps becomes much easier and you could develop something more elegant to support your event style which would probably mean that the user doesn't need to use either the DispatchAction or ActionDispatcher at all. Niall On 6/28/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: I like the functionality that this provides. If I ever get to work on another Struts 1 project, I would certainly like to use this. That said, I'm -0 to integrating it, but I won't stand in the way if other committers accept it. I think though that it works well enough without being integrated into the core. With the Extras subproject, what we've done lately is extract things out instead of bundle them in the core. The same can apply to this feature. I think it'll make an excellent subproject that can be distributed along with the main download, like taglibs and tiles integration, and it'll still get the attention it deserves without negatively affecting its potential. Hubert On 6/26/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > I want to stress out that what I suggest is not a framework ;) I did > try to make the standalone library independent of Struts for various > reasons. Still, its concept is quite foriegn to a Struts user, in > comparison to the principle of having code in Action and view in JSP. > > Integrating this idea fully into Struts changes very little in current > Struts development cycle: there is Action that handles events, there > is JSP that displays a view. That is it. No new concepts to users if > they already know what a dispatch action is. Two or three tags that I > implemented are totally optional. Therefore accepting the component > model integrated into Struts core, and developing with it is much > easier than using a standalone library. > > Comparing my enhancement to Tiles, I believe that Tiles is quite rich > in functionality and has its own learning curve. On contrary, my > enhancement fits current Struts coding and configuration conventions > very neatly. Current and future users will not be affected, but for > those who would like to have components out of the box, this > functionality will be available. Why not? > > So, the reasons for including this enhancement into the core: > > * Struts can be called a component framework (or a hybrid > action/component framework). > * User's actions that manage components will be clean and tidy, no > need to instantiate dispatchers or to manually handle > component-related stuff, no plumbing code. > > On the other hand, I do not want to hamper 1.3.5 release plan, I don't > want to fork off /struts/action/trunk/core as well. So having this > enhancement as an extension project in /struts/action/trunk will work > for me. This way I will be able to make isolated updates to the code > without affecting 1.3.5 functionality (will I?). Maybe later we will > return to this duscussion considering including the extension into 1.4 > core :) > > Michael. > > On 6/26/06, Don Brown <[EMAIL PROTECTED]> wrote: > > Ok, I see your points of leveraging known code and frameworks, but according to > > your last article, what you developed isn't tied to Struts at all and can be > > used with pure JSP. If that is the case, perhaps it would be better for this > > component framework to have its own project and be treated similar to what we > > are planning for Tiles. I'm fine with the event dispatching part of your > > proposal, but I'm not convinced a new component framework should be added to > > Struts Action 1 core. > > > > Don > > > > Michael Jouravlev wrote: > > > Don, thanks for replying. See inline. > > > > > > On 6/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > > >> Interesting...I can see you have put a lot of time and thought into > > >> this. My first pass seems to find this a cross between the portlet api > > >> and JSF. What I saw missing from the articles and wiki pages is a > > >> higher level justification: > > >> - Why not just use portlets? > > > > > > Firstly, what I suggest IS portlets :) because the term "portlets" is > > > not copyrighted. Ok, ok, I know you mean JSR-168 portlets. Still, I > > > think it is not fair to consider only JSR-168 portlets to be re
Re: Proposal for Struts 1.x: support for portlet-like components
I'm on the same page as Hubert, as an outsider... I totally see this as being a worthy "extras", and probably something a lot of people would use, but integrated into the core, it just doesn't feel right to me. Frank Hubert Rabago wrote: I like the functionality that this provides. If I ever get to work on another Struts 1 project, I would certainly like to use this. That said, I'm -0 to integrating it, but I won't stand in the way if other committers accept it. I think though that it works well enough without being integrated into the core. With the Extras subproject, what we've done lately is extract things out instead of bundle them in the core. The same can apply to this feature. I think it'll make an excellent subproject that can be distributed along with the main download, like taglibs and tiles integration, and it'll still get the attention it deserves without negatively affecting its potential. Hubert On 6/26/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: I want to stress out that what I suggest is not a framework ;) I did try to make the standalone library independent of Struts for various reasons. Still, its concept is quite foriegn to a Struts user, in comparison to the principle of having code in Action and view in JSP. Integrating this idea fully into Struts changes very little in current Struts development cycle: there is Action that handles events, there is JSP that displays a view. That is it. No new concepts to users if they already know what a dispatch action is. Two or three tags that I implemented are totally optional. Therefore accepting the component model integrated into Struts core, and developing with it is much easier than using a standalone library. Comparing my enhancement to Tiles, I believe that Tiles is quite rich in functionality and has its own learning curve. On contrary, my enhancement fits current Struts coding and configuration conventions very neatly. Current and future users will not be affected, but for those who would like to have components out of the box, this functionality will be available. Why not? So, the reasons for including this enhancement into the core: * Struts can be called a component framework (or a hybrid action/component framework). * User's actions that manage components will be clean and tidy, no need to instantiate dispatchers or to manually handle component-related stuff, no plumbing code. On the other hand, I do not want to hamper 1.3.5 release plan, I don't want to fork off /struts/action/trunk/core as well. So having this enhancement as an extension project in /struts/action/trunk will work for me. This way I will be able to make isolated updates to the code without affecting 1.3.5 functionality (will I?). Maybe later we will return to this duscussion considering including the extension into 1.4 core :) Michael. On 6/26/06, Don Brown <[EMAIL PROTECTED]> wrote: > Ok, I see your points of leveraging known code and frameworks, but according to > your last article, what you developed isn't tied to Struts at all and can be > used with pure JSP. If that is the case, perhaps it would be better for this > component framework to have its own project and be treated similar to what we > are planning for Tiles. I'm fine with the event dispatching part of your > proposal, but I'm not convinced a new component framework should be added to > Struts Action 1 core. > > Don > > Michael Jouravlev wrote: > > Don, thanks for replying. See inline. > > > > On 6/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > >> Interesting...I can see you have put a lot of time and thought into > >> this. My first pass seems to find this a cross between the portlet api > >> and JSF. What I saw missing from the articles and wiki pages is a > >> higher level justification: > >> - Why not just use portlets? > > > > Firstly, what I suggest IS portlets :) because the term "portlets" is > > not copyrighted. Ok, ok, I know you mean JSR-168 portlets. Still, I > > think it is not fair to consider only JSR-168 portlets to be real > > portlets. > > > > JSR-168 requires to set up portal engine and it imposes porltet API. > > Nothing like this is imposed on Struts components. Java code is > > basically the same, JSP code contains couple of enhanced tags. > > tag is optional. Other tags that I created are > > optional too. > > > > On Java side, the same Struts action can control both page component > > as well as a normal web resource (dispatch-style). So, with very > > little change for a user he gets a whole new functionality and revival > > for old codebase. > > > >> - Why not just use JSF? > > > > Because I use Struts, meaning Struts Action Framework 1. Why should I > > switch my framework just to get something that I can have without > > switching? I don't think that JSF/ICEFaces can do more than improved > > Struts. If I will be switching I'd choose GWT. Or maybe even Laszlo. > > Something really different. > > > >> - Why should Struts the projec
Re: Proposal for Struts 1.x: support for portlet-like components
I like the functionality that this provides. If I ever get to work on another Struts 1 project, I would certainly like to use this. That said, I'm -0 to integrating it, but I won't stand in the way if other committers accept it. I think though that it works well enough without being integrated into the core. With the Extras subproject, what we've done lately is extract things out instead of bundle them in the core. The same can apply to this feature. I think it'll make an excellent subproject that can be distributed along with the main download, like taglibs and tiles integration, and it'll still get the attention it deserves without negatively affecting its potential. Hubert On 6/26/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: I want to stress out that what I suggest is not a framework ;) I did try to make the standalone library independent of Struts for various reasons. Still, its concept is quite foriegn to a Struts user, in comparison to the principle of having code in Action and view in JSP. Integrating this idea fully into Struts changes very little in current Struts development cycle: there is Action that handles events, there is JSP that displays a view. That is it. No new concepts to users if they already know what a dispatch action is. Two or three tags that I implemented are totally optional. Therefore accepting the component model integrated into Struts core, and developing with it is much easier than using a standalone library. Comparing my enhancement to Tiles, I believe that Tiles is quite rich in functionality and has its own learning curve. On contrary, my enhancement fits current Struts coding and configuration conventions very neatly. Current and future users will not be affected, but for those who would like to have components out of the box, this functionality will be available. Why not? So, the reasons for including this enhancement into the core: * Struts can be called a component framework (or a hybrid action/component framework). * User's actions that manage components will be clean and tidy, no need to instantiate dispatchers or to manually handle component-related stuff, no plumbing code. On the other hand, I do not want to hamper 1.3.5 release plan, I don't want to fork off /struts/action/trunk/core as well. So having this enhancement as an extension project in /struts/action/trunk will work for me. This way I will be able to make isolated updates to the code without affecting 1.3.5 functionality (will I?). Maybe later we will return to this duscussion considering including the extension into 1.4 core :) Michael. On 6/26/06, Don Brown <[EMAIL PROTECTED]> wrote: > Ok, I see your points of leveraging known code and frameworks, but according to > your last article, what you developed isn't tied to Struts at all and can be > used with pure JSP. If that is the case, perhaps it would be better for this > component framework to have its own project and be treated similar to what we > are planning for Tiles. I'm fine with the event dispatching part of your > proposal, but I'm not convinced a new component framework should be added to > Struts Action 1 core. > > Don > > Michael Jouravlev wrote: > > Don, thanks for replying. See inline. > > > > On 6/25/06, Don Brown <[EMAIL PROTECTED]> wrote: > >> Interesting...I can see you have put a lot of time and thought into > >> this. My first pass seems to find this a cross between the portlet api > >> and JSF. What I saw missing from the articles and wiki pages is a > >> higher level justification: > >> - Why not just use portlets? > > > > Firstly, what I suggest IS portlets :) because the term "portlets" is > > not copyrighted. Ok, ok, I know you mean JSR-168 portlets. Still, I > > think it is not fair to consider only JSR-168 portlets to be real > > portlets. > > > > JSR-168 requires to set up portal engine and it imposes porltet API. > > Nothing like this is imposed on Struts components. Java code is > > basically the same, JSP code contains couple of enhanced tags. > > tag is optional. Other tags that I created are > > optional too. > > > > On Java side, the same Struts action can control both page component > > as well as a normal web resource (dispatch-style). So, with very > > little change for a user he gets a whole new functionality and revival > > for old codebase. > > > >> - Why not just use JSF? > > > > Because I use Struts, meaning Struts Action Framework 1. Why should I > > switch my framework just to get something that I can have without > > switching? I don't think that JSF/ICEFaces can do more than improved > > Struts. If I will be switching I'd choose GWT. Or maybe even Laszlo. > > Something really different. > > > >> - Why should Struts the project include another non-standard component > >> framework? > > > > What do you mean by component framework? The tags? They are optional. > > The code? It is the same. The Javascript? Yes, it does not use more > > well-known libraries like Dojo or DWR or P
Re: Proposal for Struts 1.x: support for portlet-like components
On 6/28/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: Integrating html2 would be nice too. It uses Ajax as well, so the two engines can be combined into one. In relation to html2, I am curious about how important client-side validator is. I mean, comparing Ajax roundrip to amount of Javascript preloaded for client-side validation, does it really make sense? And if a form is filled out correctly, this validator code is not used at all. The thing about html2 is that it relies on Niall's validatorjs extension [1] which has not gone beyond being a JCV enhancement proposal [2]. I haven't followed the development of JCV closely but so far I haven't seen an indication that the enhancement will be implemented. The last time I asked, JCV needed more volunteers to make more things happen (like this enhancement). I almost volunteered, but my OSS time has shrunk to zero since that time. Them that do the work make the decisions as Ted always says, and this is a solid example of that. Anyway, html2 was an experiment on my part. I was curious about what we can have if we were given free reign over the Struts tags. The idea of a third-party Struts tag library had been floated around a couple of times on the list and this was my attempt at scratching that itch. One of the things we could do was support non-standard HTML tags which would help those developing applications that are IE-only (which would describe all the apps I've worked on in all the assignments I've had). So, being integrated into the existing Struts tags was never a goal. As for the Ajax-only validation support, I'm with Frank. If we can provide client-side support, let's do so. For those who aren't familiar with it, the html2 Ajax validation calls ActionForm.validate() if the form isn't using Validator. Hubert [1] http://niallp.pwp.blueyonder.co.uk/validatorjs.html [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=32343 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help in switching from http to https
On 6/28/06, bhanu_gulbarga <[EMAIL PROTECTED]> wrote: Iam developing application in struts ... Please post your question on the user list. See: http://struts.apache.org/mail.html Or, since your message footer indicates that you're using Nabble: http://www.nabble.com/Struts---User-f206.html -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help in switching from http to https
Hi , Iam developing application in struts which has login page and when username and password are given it should be authenticated and the page should be switched to https I had made necessary changes to include and login-config to include the user properties but the /display.jsp /error.jsp is forcing it to go to the pages which i give in form-login-page instead it should go to NameAction java file which extends Action and based on the logic there i should go to the required success or error page and iam not understanding the importance if like if i remove the lines /display.jsp /error.jsp i get the exceptions 18:59:15,687 WARN [FormAuthenticator] Unexpected error forwarding to login page java.lang.NullPointerException at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:238) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595) Could you please help me resolve this Note: The switching to https is happening the only thing is iam not getting the required result Regards Bhanu -- View this message in context: http://www.nabble.com/Help-in-switching-from-http-to-https-tf1861678.html#a5084772 Sent from the Struts - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for Struts 1.x: support for portlet-like components
Michael Jouravlev wrote: In relation to html2, I am curious about how important client-side validator is. I mean, comparing Ajax roundrip to amount of Javascript preloaded for client-side validation, does it really make sense? And if a form is filled out correctly, this validator code is not used at all. So, maybe switching to Ajax validation instead of client-side validation makes sense? Centralizing all features (and bugs) in one place. Like client-side validator does not handle European dates. Allowing the *capability* to use AJAX for client-side validation would be nice... I recently did a POC at work that demonstrates calling server-side validator via AJAX to do client-side validation... it also showed that when the form is ultimately submitted, the same validations can be used, it's all the same for the developer, which is nice. But, if you talk about *switching to* AJAX, i.e., replacing client-side validator, I would be against it. Clearly I am someone that likes and supports AJAX, but if that's the only option then I don't think it's a good thing... You have to be careful with AJAX in terms of scalability. If you have 5 users filling out a form with five fields, and that process results in 5 AJAX requests (one per field as they fill out the form), that's not such a big deal (25 requests over time T). But, scale that to 500 users, now your talking 2500 requests over time T... yes, small requests, and yes, you saved some time and processing by not having to download as much code initially (presumably... it might wind up being about on par with client-side validator anyway in terms of line count), but the request count over a given period of time is what is of greater concern when discussing scalability. I personally prefer as much validation occur strictly client-side as possible, and I don't see that changing in the future. Even if you have to duplicate every single validation on the server when the form is finally submitted, thereby increasing the processing needed on the server, the load profile of the application is still more appealing that way as far as I'm concerned. So, as an option, AJAX would be fine with me... as the only choice though, I'd say nea. Frank Michael. On 6/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I am +1 for Michael's idea. I empathize with anyone who believe it's a non-standard way of doing portlets, or that the idea is better as an independent plug-in, but consider that Struts does not have to be the bare-of-the-bare of frameworks. Struts 1.x is definitely legacy and has provided a consistent interface for programming, but let's not confuse legacy support with being too old to learn new tricks :-) What I find very promising in Michael's design is that he is helping promote a good practice. I have followed his articles and successfully implemented what he is recommending -- and I do believe this would make a great addition to have these best practices built into Struts. And since the proposal is nothing but an endorsed methodology, it [1] does not lock me into using it and [2] I don't have to use it. Those are a hallmark of a great framework: give me the generic cases, but don't dictate the corner cases. I also am +1 for embedding an action dispatcher straight into the Action. The base class can default to EventActionDispatcher, and must be overridden. If no execute() is provided, the dispatching is the default; otherwise you can program normal actions, as before. My addition here is that I should be able to pass in a dispatcher to the super class in the constructor, because, I DO use a customized version of EventActionDispatcher in my classes -- so I'd like the ability to customize what dispatching is used. The timing of Michael's suggestions is opportune for me. My "page" attribute/property idea is to facilitate something comparable. These things would be a worthy 1.4.0 release. Paul Michael Jouravlev <[EMAIL PROTECTED]> wrote: As most of you probably know, I have been quite obsessed with page components developed with JSP or with JSP/Struts [1],[2]. My first attempt used Struts/JSP, the second one is pure JSP-based [3]. It proved to be quite robust, simple and it works. So now in my newly acquired powers of Struts committer I want to build this technology into Struts 1.x. The code is not GA quality yet, but major stuff works. Nice thing is that the same code/markup works in both non-Javascript and Javascript-enabled browsers. With Javascript, simple Ajax is used to replace component markup in a composite page (make it AHAH since it returns XHTML, not XML). Without Javascript good old redirect-after-post is used, the reload target is calculated automatically. I believe that this is a really nice feature. And it is extensible. Compare it to, say, ICEFaces. I was experimenting and I implmented many of these features like Ajax tab component or partial submit. This technology will put the end
Login application and switching from http to https
Iam devloping sample login application in struts which should switch to https if the credential are correct i made the necessary modification in web.xml to contain the form-auth parameters and in the login-config.xml I have made necessary modifcations props/web-console-users.properties but the problem iam facing is what ever username and password i enter is getting acceppted i think it should be checked against the username and password of user.properties but its not doing but the switch is from http to https is going fine please tell me if iam doing something wrong - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=35755&messageID=69972#69972 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for Struts 1.x: support for portlet-like components
Paul, thanks for the warm support, I really appreciate it! Well, I cannot thank you more, my ears are all red :-) In any case, I think we can wait until 1.3.5 goes GA before making a final decision about where this code belongs. In the meantime I will continue working on it. Integrating html2 would be nice too. It uses Ajax as well, so the two engines can be combined into one. In relation to html2, I am curious about how important client-side validator is. I mean, comparing Ajax roundrip to amount of Javascript preloaded for client-side validation, does it really make sense? And if a form is filled out correctly, this validator code is not used at all. So, maybe switching to Ajax validation instead of client-side validation makes sense? Centralizing all features (and bugs) in one place. Like client-side validator does not handle European dates. Michael. On 6/26/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I am +1 for Michael's idea. I empathize with anyone who believe it's a non-standard way of doing portlets, or that the idea is better as an independent plug-in, but consider that Struts does not have to be the bare-of-the-bare of frameworks. Struts 1.x is definitely legacy and has provided a consistent interface for programming, but let's not confuse legacy support with being too old to learn new tricks :-) What I find very promising in Michael's design is that he is helping promote a good practice. I have followed his articles and successfully implemented what he is recommending -- and I do believe this would make a great addition to have these best practices built into Struts. And since the proposal is nothing but an endorsed methodology, it [1] does not lock me into using it and [2] I don't have to use it. Those are a hallmark of a great framework: give me the generic cases, but don't dictate the corner cases. I also am +1 for embedding an action dispatcher straight into the Action. The base class can default to EventActionDispatcher, and must be overridden. If no execute() is provided, the dispatching is the default; otherwise you can program normal actions, as before. My addition here is that I should be able to pass in a dispatcher to the super class in the constructor, because, I DO use a customized version of EventActionDispatcher in my classes -- so I'd like the ability to customize what dispatching is used. The timing of Michael's suggestions is opportune for me. My "page" attribute/property idea is to facilitate something comparable. These things would be a worthy 1.4.0 release. Paul Michael Jouravlev <[EMAIL PROTECTED]> wrote: As most of you probably know, I have been quite obsessed with page components developed with JSP or with JSP/Struts [1],[2]. My first attempt used Struts/JSP, the second one is pure JSP-based [3]. It proved to be quite robust, simple and it works. So now in my newly acquired powers of Struts committer I want to build this technology into Struts 1.x. The code is not GA quality yet, but major stuff works. Nice thing is that the same code/markup works in both non-Javascript and Javascript-enabled browsers. With Javascript, simple Ajax is used to replace component markup in a composite page (make it AHAH since it returns XHTML, not XML). Without Javascript good old redirect-after-post is used, the reload target is calculated automatically. I believe that this is a really nice feature. And it is extensible. Compare it to, say, ICEFaces. I was experimenting and I implmented many of these features like Ajax tab component or partial submit. This technology will put the end to "Struts has no components" claim. I do not suggest this for SAF2 since it already has Ajax and component features. You can read more in Wiki pages, that I envision as peice of future documentation [4] I will be able to finish coding myself so I do not need much help on this part. What I do need is approval for: * enhancing Struts 1.x with this technology * enhanching Action class with dispatching functionality So while I will be polishing the code, I want these ideas to get marinated for a while. I already raised the question about sticking dispatching stuff into Action [5], [6]. The replies were: Don -- OK Frank -- OK, if all current functionality is retained Dave N -- OK, if execute() will be made default dispatch method Niall - Nah... (but not N! so I hope to convince him) I would like to explain my position once again, largely for Niall and maybe for others too. * After series of experiments with oh so many flavors of dispatch actions we now have the best of the breed: EventDispathAction. It covers all the bases, it is highly unlikely that another dispatch action will be created for Struts 1.x. I want to implement EventDispathAction in base Action. * No one will be hurt: it will be possible to use Action just as an ordinary old-school Action. Older dispatch actions will work as well. * Having dispatching functionality at the core allows to promote the concep
