Strecks 1.0.1 released
Dear all, I've released Strecks 1.0.1 with some small updates to the 1.0 release. The main change in this release is it now much simpler to run the samples: simply download the source distrubution, then run ant download run.samples. Strecks contains a range of enhancements aimed to streamline the Struts 1.x programming model using Java 5 language features. These enhancements include annotations for validation, data binding, type conversion and dependency injection, as well as a range of other features including pure POJO actions, interceptors and Spring integration. For a more detailed feature list see http://strecks.sourceforge.net/features.php. Strecks can be downloaded from http://strecks.sourceforge.net/download.php. Regards, Phil Zoio http://www.realsolve.co.uk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts1.3.5 error
I saw this problem too - I think the package of the UseAttributeTei changed. I fixed it by using following prefix in your page: %@ taglib prefix=tiles uri=http://struts.apache.org/tags-tiles; % [EMAIL PROTECTED] wrote: Hi, I was using struts1.2.9 previously , every thing worked fine. When I migrated to struts1.3.5, I am getting below error message.I am not sure about this behaviour. Any particular reason for this behaviour? org.apache.jasper.JasperException: Failed to load or instantiate TagExtraInfo class: org.apache.struts.taglib.tiles.UseAttributeTei org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHand ler.java:50) org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java :407) org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java :279) org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryIn foImpl.java:422) org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImp l.java:248) org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl. java:162) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:418) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:483) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1543) org.apache.jasper.compiler.Parser.parse(Parser.java:126) org.apache.jasper.compiler.ParserController.doParse(ParserController.jav a:211) org.apache.jasper.compiler.ParserController.parse(ParserController.java: 100) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:146) org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja va:556) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:293) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte r.java:81) root cause java.lang.ClassNotFoundException: org.apache.struts.taglib.tiles.UseAttributeTei org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader .java:1332) org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader .java:1181) org.apache.jasper.compiler.TagLibraryInfoImpl.createTagInfo(TagLibraryIn foImpl.java:419) org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImp l.java:248) org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl. java:162) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:418) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:483) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1543) org.apache.jasper.compiler.Parser.parse(Parser.java:126) org.apache.jasper.compiler.ParserController.doParse(ParserController.jav a:211) org.apache.jasper.compiler.ParserController.parse(ParserController.java: 100) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:146) org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) org.apache.jasper.compiler.Compiler.compile(Compiler.java:267) org.apache.jasper.compiler.Compiler.compile(Compiler.java:255) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja va:556) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja va:293) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:810) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte r.java:81) Regards, Vinodh 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strecks (Struts extensions for Java 5) version 1.0 released
I'm pleased to announce the release of Strecks 1.0. Strecks is a set of Java 5-specific extensions to the original Struts framework. Making heavy use of Java 5 annotations, it adds a number of modern features to Struts-based applications, including POJO actions, dependency injection, declarative validation and data binding, interceptors, pluggable views, as well as seamless Spring integration. It is also highly extensible and amenable to test driven development. For more information, see http://strecks.sourceforge.net/features.php. The aim of Strecks has been to address the most widely perceived inadequacies of the original Struts programming model while still allowing full backward compatibility of applications. Strecks works with the most recent general availability Struts versions (1.2.8 and 1.3.5), but at the same time allows developers to work with advanced features expected from modern web frameworks. Strecks offers an enhanced programming model for actions and forms, while working with existing unchanged templating and configuration mechanisms. Strecks is aimed at developers who: - have a significant existing investment in the current version of Struts, either in terms of knowledge or existing code - are not currently ready or willing to take the pain of migrating to the forthcoming Struts 2.0 (based on WebWork) or another web framework - want to take advantage of advanced features not available in vanilla Struts but increasingly so in other frameworks Strecks can be downloaded from http://strecks.sourceforge.net/download.php. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Announcement: Strecks (Struts extensions for Java 5) version 1.0 beta 3 released
I'd like to announce the release of Strecks 1.0 beta 3. Strecks is a set of extensions to Struts aimed at Java 5 users aimed at streamlining development of Struts application with features such as POJO actions, interceptors, dependency injections, data binding, etc. For more details see http://strecks.sourceforge.net/ Strecks 1.0 beta 3 can be downloaded from http://strecks.sourceforge.net/download.php The main changes in this recent release involve some internal refactorings to easily support the Struts 1.3 when it becomes GA (General Availability). Users will be able to configure Strecks using the Struts 1.3 chain of responsibility request processor (as well as continue to use the Struts 1.2 request processor). However, the main targeted Struts version will continue to be 1.2 until Struts 1.3 becomes GA. Strecks 1.0 beta 3 involves the following changes: - refactored processor internals to allow for simpler support of 1.3.x and its chain of responsibility-based request processor - proper packaging of Strecks .tld file in jar. Changed tag URI to http://strecks.sourceforge.net/tags - changed interface of ActionContextFactory to use PropertyDescriptor rather than InputSetter Regards, Phil Zoio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extending Struts with Spring
I've added a lot of support for integrating Spring with Struts in Strecks: http://strecks.sourceforge.net/ - a Java 5-based Struts extension framework The main Spring-related things you'll find in there are: - you can inject any Spring bean into your actions using the @InjectSpringBean annotation - actions can *be* Spring beans, simply by annotating your action with @SpringBean - you can tap into Spring's view rendering in a pretty seamless way For more details, take a look at: http://strecks.sourceforge.net/doc-spring-int.php Regards, Phil Z Julian Tillmann wrote: Hello, I've read that you can use Spring to make your Struts Actions thread safe. Is someone using this or has experience with it? Are there other arguments for using Spring with Struts like, for example an easy implemented Interceptor that might improve the application and is not as easily achieved with a filter? I'm thinking about using this extension but I don't have any kind of practical experience with it. Could someone help me with this? ciao thx Julian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strecks Java 5 Extensions for Struts - version 1.0 beta 2 released
I'm pleased to announce the release of Strecks-1.0 beta 2 (see http://strecks.sourceforge.net/). Strecks is a set of extensions to Struts which leverage the power of Java 5 specific features to allow for more productive, streamlined Struts application development. Strecks is built on the Struts latest general availability code base (1.2.9), allowing for full backward compatibility with existing applications. The current release brings a number of feature enhancements, including action-specitic interceptors, additional built-in validators, and additional support for Spring in the form of seamless integration with Spring MVC's view rendering mechanism. The following features have been added in this release: - action-specific interceptors, parameterisable using Java 5 generics, using the @BeforeInterceptors and @AfterInterceptors - added URL, credit card, email and pattern validators, backed by Commons Validator implementations - added support for rendering Spring MVC views, either directly or through view resolvers, using the @SpringView annotation - implicit implicit controllers, allowing default controllers to be associated with known action bean interfaces - added MessageResourcesHelper dependency injector, making it easier to work programmatically with MessageResources in the action bean class Strecks-1.0 beta 2 can be downloaded from http://strecks.sourceforge.net/download.php. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: troubles using java 5
I've worked on Strecks with Java 5 and Struts 1.2.7 and 1.2.9 (I skipped 1.2.8), and Java 5 definitely isn't the problem. Your problem sounds rather strange. Try downloading and building one of the Strecks examples from source (using Jdk 1.5), and see if it causes the same problem. Phil mouna SAHIB wrote: Hello everybody, I'm not a specialist using struts, but I did some work with it in last months. Now, I'm working on project using the jdk1.4.2 and I'v moved to jdk 1.5 to have plenty use of aspectj 5 (an AOP tool). I don't know if there is a compatiblity problem using struts 1.2.8 with java 5: I converted a module of my application into an apsectj tool and use jdk 1.5. The module that causes problem is my GUI module which uses struts. When I build (using ant) I have the following error: [javac] error: error reading C:\projets\M_LIB\.classpath; error in opening zip file I see that there isa new tool to use java 5 with struts strecks but I'm not supposed to work on the struts module, and shouldn't(other people developped it) and I'm wondering how to get rid of that compiling error! Any ideas please? Thanks No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: 24/04/2006
Re: StrutsTestCases
You should be able to solve the problem by adding the WEB-INF directory
onto your classpath. I couldn't get it to work otherwise
Chaitanya Parkhi wrote:
hi guys i hav created a java file by using MockObjectStrutsTestCases which
tests for a simple login form which takes Login Name password as a
input.in this file i hav following method
public void testSuccessfulLogin() {
setConfigFile(/WEB-INF/struts-config.xml);
setRequestPathInfo(/login);
addRequestParameter(username,cdp);
addRequestParameter(password,[EMAIL PROTECTED]);
actionPerform();
String[] actionErrors = {username.required,password.required};
verifyActionErrors(actionErrors);
}
if i run the above test junit window shows that ther r no errors,but shows
a warning that WB-INF\web.xml not found does any1 knows why?
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/322 - Release Date: 22/04/2006
Announcement: Strecks (Java 5 Extensions for Struts) - 1.0-beta-1 released
I'm pleased to announce the release of Strecks 1.0-beta-1. Strecks (which stands for Struts Extensions), is built on the latest general availability Struts 1.2 code base, currently 1.2.9. Strecks contains a range of features aimed to streamline the Struts programming model. These include validation, data binding and type conversion annotations, dependency injection annotations, and interceptors. For a more detailed feature list see http://strecks.sourceforge.net/features.php. Changes since the previous release (1.0-alpha-1) include the following: - support for Tiles (through TilesControllerRequestProcessor) - added generic type validators for remaining basic data types: Boolean, Byte, Short, Float - added ViewAdapter as one of the return types recognised by NavigateForward tag handler - added custom tags to expose action bean and page beans to JSPs via arbitrarily named page context attributes - changed FieldLabelTag, including appending or renaming various tag attributes - added support for binding to page context attributes in BindTag Strecks is now moving into beta as only minor features and bug fixes are now anticipated prior to a final 1.0 release. Strecks 1.0-beta-1 is available for download from http://strecks.sourceforge.net/. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: friday ha ha
As we all know, Struts has evolved in recent times from being a just a framework to being a community supporting two separate but equal frameworks which have nothing to do with each other except a shared name, and perhaps a couple of shared committers. I think the message that is going out to the wider community is quite a confusing one. For users, it's not terribly helpful that the individual frameworks are on the same web site and on the same mailing list. 99% (or some number close to this) of users will be interested in one or the other frameworks - the rest of the documentation, messages, etc. is just noise. The situation is made even more confusing by the WebWork merger. Because 1.x is not going to disappear overnight, Struts is effectively hosting three separate frameworks - Struts, Action 1, and Action 2. My view is that this process needs to be formalized. Struts has already become an umbrella body for the three frameworks, but there needs to be a clearer separation between them in the way that they are managed, or at least, in the way information about the projects is made accessible to users. And now for my second point which I have not expressed before because it only occurred to me last night ... Since evolution of Struts from just a framework into an umbrella body is already underway, why limit it to hosting two separate but equal frameworks. Why should Struts not become **three* separate but equal* frameworks, namely 1) Struts Shale 2) Struts Action 2, that is, the outcome from the WebWork merger 3) Struts Classic (or whatever you want to call it), the original Struts that we all know and love Yes, instead of replacing the original Struts, why shouldn't Struts Classic be allowed to evolve properly in its own right, instead of in the cramped 1.x space as a relic of the past. For me, at least, Strecks (http://strecks.sourceforge.net/) proves that the assumption that Struts Classic cannot be evolved to support a more advanced, modern programming model is flawed. While mandating support for Java 5 is obviously no option for Struts 1.x, I don't see why it should not be an option, for example, for a Struts Classic 2. A Struts Classic 2 could also be a bit more adventurous in introducing changes, for example, to ease configuration, but would still need to be backwardly compatible, or at least allowing for a relatively trivial migration. I think this proposal is one in which everyone could win. Those who think that Struts Classic is too fundamentally flawed and should be just allowed to die, period, can move on to Struts Action 2 or Shale now. By adopting WebWork, the Struts community would be formally recognising the merits of this framework, and would make it more easily accessible for existing Struts users. However, it is not a move that users should be forced into prematurely. Many organisations which already have a significant investment in Struts Classic would surely much rather see from the Struts community a genuine effort to evolve the current framework in a way which is backwardly compatible, than to be forced into a switching to a new framework with all the associated costs of migration and retraining. I think that the leaders of the Struts community have a responsibility to the hundreds and thousands of existing users to give them as much choice as possible, and not to close the door prematurely on any options which could make sense to a lot of people. Ted Husted wrote: On 4/19/06, Alexandre Poitras [EMAIL PROTECTED] wrote: Second, all the comitters have answered your questions very nicely Yes, we have. Here's a handy summary for future reference: The Apache Struts project continues to move that the same pace we always have. We generally run 18 months to 24 months between release series. The Struts 1.3.x series has already begun, and a 1.3.0 build is available for testing. From the beginning, there were several teams that started after us and issued a 1.0 release before Struts 1.0 came out in June 2001. Other teams do move faster, but faster is not always better. We add committers on a regular basis. We use the same protocols as all other ASF projects. (Right now, there are about thirty active ASF projects with almost two thousand committers.) ASF projects look for people that we believe are devoted to the task and match the human attitudes required to work well with others, especially in disagreement. There are no lead developers on ASF projects. Every binding vote counts as much as every other. Voting aside, everyone is invited to donate patches and participate in the development discussions. Some ASF projects always post a patch before committing it. We aren't asking anyone to do something that we wouldn't do ourselves. We do *not* consider other projects competitors. We consider ourselves colleagues who are trying to solve the same problem in different ways, in search of better solutions. The Apache Struts
Re: friday ha ha
Niall Pemberton wrote: On 4/18/06, Jonathan Revusky [EMAIL PROTECTED] wrote: I would venture to guess, just as an outside observer, that if the author of Strecks is not given commit access to Struts itself, then he may run into limitations in the Struts codebase and end up making modifications to support things that Strecks needs, and end up with a forked version of the Struts 1.x code. I would hope not. Of course, logically, if this guy is interested in developing further on top of Struts 1.x, and existing Struts committers aren't, he probably should be let in and Strecks might as well become Struts 1.3.x. or Struts 1.4.x and so on. Strecks requires JDK 1.5 and I don't believe we're ready to make this a minimum requirement for Struts at this point in time. So at the moment I don't believe it could be anything other than an optional add on. If it was a separate Struts sub-module then obviously it would have more credibility - but starting out as a sourceforge project seems like a good plan IMO. Yes I agree Phil may correct me if I've got this wrong, but I believe it was his aim to provide this functionality to existing Struts 1.2.x users and has developed it based on the 1.2.x code, rather than 1.3.x. In fact I believe it would have been easier to develop it for 1.3 - but that wasn't his aim. If there are things we could change to make integrating Strecks easier then Phil is welcome to submit patches through bugzilla. We would prefer them for the current code base (1.3.x) - although theres no reason why 1.2.x changes can't be requested, except there may be no appetite for further 1.2.x releases. Niall, thanks for pointing this out. I went for 1.2.x because it is out there. I don't plan to submit any patches for 1.2 at this point, though. Correct me if I'm wrong, but I expect 1.3 will be backward compatible to 1.2, and if so, Strecks could still be used as is with 1.3. There are certain features which may be easier to accomodate through 1.3, especially if there is still an option to submit patches at a relatively early stage in its release cycle. I still need to look into all of this though. If there is interest in changing Struts to accomodate Strecks, then it would be more appropriate to continue discussion on the dev list though. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: friday ha ha
Please see my comments below: Jonathan Revusky wrote: Ted Husted wrote: On 4/18/06, Phil Zoio [EMAIL PROTECTED] wrote: I'd be happy to pass Strecks on to Struts itself if the community really wanted it, but I don't see that as essential to its existence in any way. What we look for is a community forming around the codebase. We don't just want code, we want people who are committed to maintaining the code over the long term. Yes, but if that is the case, doesn't that mean that you have failed utterly and abysmally? After all, we have a situation in which the Struts 1.x codebase is basically being abandoned and you are bringing in a codebase that was, heretofore, that of a competing project. You won't be surprised to hear that I also think that taking WebWork into Struts was a big mistake. Its hard to see how either existing Struts or WebWork users benefit from it: - Struts users stand to lose from the unnecessarily rapid demise of the existing framework and because it prevents the chances of projects which can move it forward, like Strecks and others, from gaining acceptance in the future - I can't see how it works for WebWork users, who invested in the framework when it was not so fashionable and are rewarded with the tedious job of having to update their applications for fit in with the Struts package names. A lot of the developer effort that could be going in to adding features, etc. instead needs to be going in to updating documentation and creating compatibility layers The only possible user benefit I could imagine being argued is that Struts users are introduced to a better framework without having to do the hard sell on their pro-Struts management. But this is a pretty weak argument at best, in my opinion. So what is this about your commitment to maintaining the code over the long term? Not just one person, but a community of likely suspects who will step and and volunteer if the creator of the code loses interest. Doesn't all this beg the question completely? If you and your collaborators are not interested in developing the Struts 1.x codebase any further, and Phil and maybe others are, why should you not just let them come in and do what they will? I mean, as regards Struts 1.x, you are not proposing to do anything with it really, right? If other people have a plan for modernizing it and making it better, why should you not just open the door and say: Okay, show us what you can do. What is there to lose? AFAICS, the only alternative you are proposing wrt Struts 1.x is simply to abandon it. I think it woud be way premature to talk about Strecks code being added to Struts proper. One thing which would help greatly would be one or two links from the Struts sites so that Struts 1.x users who haven't read the TSS article or these posts would still have a way of finding out about it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: friday ha ha
Jonathan Revusky wrote: Dave Newton wrote: Jonathan Revusky wrote: Well, there [are] all these issues, and yeah, I guess they could make you and other people shudder. If it _didn't_ make somebody shudder I'd seriously question their overall programming knowledge... at some point you have to start over. Well, that's one assessment. OTOH, it is problematic to think that if somebody disagrees with you on this or something else that it calls into question their professional competence. Again, I think my point stands: if there is no desire on the part of existing Struts committers to do anything with the Struts 1.x codebase, then there is really nothing to lose by letting other people who want to develop that come in and do something. But the real key point I am wondering about is this: if the existing Struts developers have no plans for developing the Struts 1.x codebase, what is the justification for not letting people who want to work on that (independently of whether this reflects good taste on their part or not) come in and work on it? Given the basic parameters of the situation, what would there possibly be to lose? We've already gone over this, we disagree about who should have commit rights. shrug If you say so... I am not quite sure what the basis of our disagreement on that was. And I have to point out that, okay, you can disagree with me, but it's hardly a symmetrical thing. I have actual experience running open source projects. You apparently do not. But anyway, to focus on the question of our disagreement on this, let's take a specific case in point. I am not acquainted personally with Phil Zoio, the author of Strecks. It's not like I have some agenda of championing his cause or something like that; it's just a case in point to focus discussion. Now, it seems self-evident that this is a guy who is able and willing to do some quality work. Now, my view of things is that there is really no legitimate reason not to immediately make somebody like that a committer on the Struts project, if he wanted to do work on 1.x. (Again, if he or others want to do something with it and the existing committers don't...) Even if it suddenly happened that I were to be suddenly granted commit access it would not make sense for me to use this. If there were real demand from a significant body of the Struts developers and a structured mechanism for taking in the code, then that would be very different. Thinking that this could ever happen now is a pipe dream, because it already happening with an altogether different framework - i.e. WebWork. With two major divergent strands of development now going on under a single umbrella, the space is already crowded and confusing enough. No, I think it from now on it will probably make more sense to keep any major Struts 1.1 development initiatives completely separate from the main project. It shouldn't be that way, but it is. Phil Zoio (Strecks - http://strecks.sourceforge.net/) Do you disagree with my view on this? If you do, what is the basis for your disagreement? There is still maintenance work being done on 1.x, sometimes more than that. That's an orthogonal issue. Even within 1.x, you can have a stable 1.3.x branch in which at most nth order bug fixes happen and a 1.4.x branch which is aggressively developed. Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: friday ha ha
Please allow me to shed a bit more light on a couple of your observations/speculations. Regards, Phil Zoio (Developer of Strecks) My sense of things is that Strecks is another person's third-party effort. It is not part of the Struts project. Any new development you can expect from the Struts developers is bifurcating between Action2 (Webwork) and Shale. I would venture to guess, just as an outside observer, that if the author of Strecks is not given commit access to Struts itself, then he may run into limitations in the Struts codebase and end up making modifications to support things that Strecks needs, and end up with a forked version of the Struts 1.x code. Yes, if I could have my way I'd probably would have made a couple of small changes to Struts to make my life a bit easier. On the whole, though, I've accepted the constraints as given, and worked around them. I have no intention of ending up with a forked version of Struts 1.x - that would be defeating the whole point. Of course, logically, if this guy is interested in developing further on top of Struts 1.x, and existing Struts committers aren't, he probably should be let in and Strecks might as well become Struts 1.3.x. or Struts 1.4.x and so on. I'd be happy to pass Strecks on to Struts itself if the community really wanted it, but I don't see that as essential to its existence in any way. Somehow, I don't think that's likely to happen though. *Probably* (note that I am speculating because I don't speak for others) the preference of the Struts people would be just to let the Struts 1.x codebase more or less rot and encourage people to move to Action2 or Shale. Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strecks vs Stripes
Perhaps the similarity in the names could cause confusion ... The similarity between Strecks and Stripes is that they both require Java 5. Otherwise they are completely different frameworks. Stripes is an independent framework in its own right with no Struts dependencies. Strecks is still Struts, but with added features, and a very different programming model for forms and especially actions. Phil Michael Jouravlev wrote: On 4/14/06, Vincent [EMAIL PROTECTED] wrote: I saw this on TSS today: http://www.theserverside.com/news/thread.tss?thread_id=39840 Strecks, a set of open source extensions to the Struts framework aimed at Java 5 users, has been released. Strecks (which stands for Struts Extensions) is built on the existing Struts 1.2.x code base. Basically Struts + a whole lot of @annotation candy? Thoughts? Stripes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Strecks 1.0-alpha-1 released
I'm pleased to announce the first public release of Strecks, a set of open source extensions to the Struts framework aimed at Java 5 users. Strecks (which stands for Struts Extensions) is built on the existing Struts 1.2 code base. Strecks contains a range of features aimed to streamline the Struts programming model. Some key features include: - pure POJO action beans with zero framework dependencies - action vs controller separation. Request processing logic is encapsulated into Action controllers, simplifying action implementations - annotation-based dependency injection (typed request parameters, session attributes, Spring beans, and many others) - annotation-based form validators (XML and code-free) - annotation-based data binding from form properties to domain model - annotations for additional per-field control over type conversion - simplified mechanisms to support navigation and redirecting after posts - pluggable navigation using annotations - pre and post action interceptors For a more complete list, see http://strecks.sourceforge.net/features.php The main design goals of Strecks are to: - introduce no compatibility issues apart from Java 5 - simplify the action/form programming model in line with recent software development best practices - offer or even improve on advanced features offered by competitive frameworks - keep easy to learn for existing Struts users Strecks 1.0-alpha-1 is available for download from http://strecks.sourceforge.net/. Phil Zoio web: http://www.realsolve.co.uk/ email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
