Re: How to be added to Struts Consultants firms on Wiki pages
Sergio Ramazzina wrote: Hi to everybody, I would kindly know how my company can be listed between the companies that has Struts Knowledge, as a consultancy firm in Italy tah gives consultancy services and bases its application on this wolderful platform. Thanks a lot for the information Sergio Like most wiki's, the one for Struts is open for anyone to edit. Simply navigate to the page you want to update (probably http://wiki.apache.org/struts/StrutsConsultants), and click the EditText of this page link down at the bottom. Note that login is not required, but we do prefer that you log on so we can maintain an audit trail of individuals that contribute to Struts. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form posts are logged
Adam Hardy wrote: Hermod, it totally depends on what logging package you are using. Whichever you have, you should make sure that the logger class for org.apache is set to warn or error or similar. In addition, Tomcat also has a nifty debugging tool that dumps out all the request and response data, which sounds suspiciously like what you are describing. Check your server.xml file for occurrences of a Valve with a classname like RequestDumperValve. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding mobile tags to Struts Faces
Michael Rasmussen wrote: Sorry if this comes thru as an HTML post. This is my first post to the list. Let me know if it is a problem. I have been using struts for a while now and really like it. I have also used asp.net and really like some of the features in the ms framework. I am excited at the prospect of JSF bringing these features to JSP/Java. One thing I really think is missing is support for mobile profiles. (Cell phones/wap/pda's) I think struts faces would be a great place to try to put some of that together. I am interested in doing this and wondering how to go about getting set up and if there are others interested. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Michael, This response is very late (I've been too busy for words lately). But I would recommend that mobile profiles as you describe would make a good candidate for a stand-alone library of pure JavaServer Faces components and renderers ... they need not be tied to Struts, as they would be if included in struts-faces directly. The only thing that should be in struts-faces (IMHO) is bindings to tie the two frameworks together, plus a few tags to make the transition easier for existing Struts based apps -- and one could easily argue that even those should be separated from the core integration library. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Craig: struts-faces why the use of base tag??
James Holmes wrote: Craig, If you're listening, I'm curious why you created a base tag for struts-faces? Is there any need for it? It is breaking the example applications because it is rendering an invalid value. Thanks for any info. -James (Getting back to Apache stuff after a long couple of 7x24 months getting Sun Java Studio Creator out the door. Also, 400 messages to go on struts-dev yet, so this might have been answered already ...) The motivation for s:base (in the struts-faces library) is the same as the motivation for html:base (in the struts tag libraries). If you are using path mapping to match the controller servlet (typically /faces/* in the case of JSF), then relative links within the page will not resolve as expected, due to the extra level of directory nesting). That being said, it might well have a bug in the implementation. Once I catch up on email, and can build struts 1.2, I'll be focusing on getting struts-faces up to release quality. And, yes, being able to run struts-faces with Struts 1.1 is an absolute requirement, in my opinion. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-faces
Ted Husted wrote: I imagine Craig has Struts-Faces compiling against 2.4 to make sure it stays in synch with Tomcat 5. It is indeed, but that's actually a mistake. It needs to compile against the 2.3 version, since that's what JSF specifies as a minimum platform. I'll fix that in tonight's run. But, the question is whether we want to mandate that Struts-Faces can only compile against 2.3 (and not 2.4)? Or vice-versa. Or is there a way to write the class so it compiles under either? I'll take a look at the changes once I catch up a little bit more, and might be able to come up with something clever that makes this possible (still recovering from JavaOne and ~11k backlogged mail messages :-). I know this is a pain. We went through the same problem with DataSources between 2.2 and 2.3. I'm not sure what the issue here is, but for DataSources, the interface changed and we had to stub the new members so that they threw exceptions if called. Of course, the problem with that approach is it may obviate new functionality or rely on deprecated methods. -Ted. Craig On Mon, 05 Jul 2004 14:14:02 +0200, Matthias Wessendorf wrote: James, i also guess it is the result of the commitment. i submitted (first) a wrapper, that builds against 2.4 reason is, the build-porperties had *default* to 2.4 okay ted asks for a 2.3-wrapper, so i created that candidate. i think the wrapper should compile against 2.3 since jsf is able to run in j2ee1.3-containers So i am wondering, why struts-faces uses 2.4 for compiling. btw. the 2.3 wrapper runs on servlet2.4-containers (like tomcat5.0) Matthias I think it is happening because of the changes I committed for your fix for MyFaces. If you look at when the builds stopped, it's right after I made the commits on 6/29. It must be an issue of what version of servlet.jar that the HttpServletRequestWrapper class is being compiled against. Is it not possible to make that class compilable against both 2.3 and 2.4? -James -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] wessendorf.de] Sent: Monday, July 05, 2004 6:29 AM To: [EMAIL PROTECTED] Subject: Struts-faces see http://cvs.apache.org/builds/jakarta-struts/nightly/struts- faces/ the nightly build is empty again, so is there a logfile, where i can check, why it is not build successful? Cheers, -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-faces
Michael Rassmussen wrote: I looked and maven is pulling servlet 2.2. I would assume that faces is using that same servlet.jar. I just rebuilt faces against 2.3 and the problems seem to have gone away. I haven't tried 2.4, but it seems that it should work fine there. It is my guess after trying to build struts-faces in eclipse using servlet 2.2 that the problem is with 2.2 not being supported. (And it shouldn't be right?) Michael That's correct ... JSF requires Servlet 2.3. Note: my nightly build scripts use Ant, not Maven ... and I'm in the process of cleaning that up. Shortly I'll be posting a list of the actual dependencies I'm using for the Struts nightly build, which should correspond to what we actually include in 1.2.1. Craig On Mon, 05 Jul 2004 18:56:41 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Ted Husted wrote: I imagine Craig has Struts-Faces compiling against 2.4 to make sure it stays in synch with Tomcat 5. It is indeed, but that's actually a mistake. It needs to compile against the 2.3 version, since that's what JSF specifies as a minimum platform. I'll fix that in tonight's run. But, the question is whether we want to mandate that Struts-Faces can only compile against 2.3 (and not 2.4)? Or vice-versa. Or is there a way to write the class so it compiles under either? I'll take a look at the changes once I catch up a little bit more, and might be able to come up with something clever that makes this possible (still recovering from JavaOne and ~11k backlogged mail messages :-). I know this is a pain. We went through the same problem with DataSources between 2.2 and 2.3. I'm not sure what the issue here is, but for DataSources, the interface changed and we had to stub the new members so that they threw exceptions if called. Of course, the problem with that approach is it may obviate new functionality or rely on deprecated methods. -Ted. Craig On Mon, 05 Jul 2004 14:14:02 +0200, Matthias Wessendorf wrote: James, i also guess it is the result of the commitment. i submitted (first) a wrapper, that builds against 2.4 reason is, the build-porperties had *default* to 2.4 okay ted asks for a 2.3-wrapper, so i created that candidate. i think the wrapper should compile against 2.3 since jsf is able to run in j2ee1.3-containers So i am wondering, why struts-faces uses 2.4 for compiling. btw. the 2.3 wrapper runs on servlet2.4-containers (like tomcat5.0) Matthias I think it is happening because of the changes I committed for your fix for MyFaces. If you look at when the builds stopped, it's right after I made the commits on 6/29. It must be an issue of what version of servlet.jar that the HttpServletRequestWrapper class is being compiled against. Is it not possible to make that class compilable against both 2.3 and 2.4? -James -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] wessendorf.de] Sent: Monday, July 05, 2004 6:29 AM To: [EMAIL PROTECTED] Subject: Struts-faces see http://cvs.apache.org/builds/jakarta-struts/nightly/struts- faces/ the nightly build is empty again, so is there a logfile, where i can check, why it is not build successful? Cheers, -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-faces
Craig McClanahan wrote: Note: my nightly build scripts use Ant, not Maven ... and I'm in the process of cleaning that up. I should clarify what I really meant to say :-). I'm cleaning up my Ant-based build scripts to be more explicit about which versions of dependent projects I use in the nightly Struts build, so that it's easy to extract such a list. I have no intention of switching the Struts nightly build (or the nightly builds for the commons packages, which I also create) to be Maven based anytime in the near future -- *definitely* not until there is a real Maven 1.0 release, but probably not even then (my professional world is all Ant based, and Maven doesn't buy me enough personally right now to invest in learning its quirks) . Anyone who wants to do that (ideally, it should be on Apache managed hardware to improve reliability) is welcome to take a crack at it. Uploading to the nightly builds distribution directory is arrangeable for committers. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Startup Hang Running Unit Tests?
This is probably old news to the other developers, but hey ... just catching back up :-). I've got the HEAD of jakarta-struts compiling fine now, but watned to run the unit tests. For either Tomcat 4.1 or 5.0, the start.tomcat.xx target seems to hang at the end of the startup, rather than proceeding on to execute the tests. Is that the currently expected behavior? Is there a workaround? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-faces
Matthias Wessendorf wrote: Michael, I looked and maven is pulling servlet 2.2. I would assume that faces is using that same servlet.jar. I just rebuilt faces against 2.3 and the problems seem to have gone away. I haven't tried 2.4, but it seems that it should work fine there. It is my guess after trying to build struts-faces in eclipse using servlet 2.2 that the problem is with 2.2 not being supported. (And it shouldn't be right?) Michael yes in 2.4 the interface for httpServletRequest has new methods. so i thinks it is better to compile this lib against 2.3 and struts against 2.2 ? That sounds right. I'll be setting up my nightly build to do that. jsf requires 2.3 however, after building struts-faces successful whats against using myfaces directly in struts-faces? now the user must load all jars form sun for using struts-faces integration-lib In principle, this makes perfect sense. It'll be easy if you've split the MyFaces jars into api and impl classes (like the RI does), because then it's just a matter of setting up your own build.properties file and defining jsf-api.jar and jsf-impl.jar appropriately. I'll look into seeing if that actually works, once I've caught up and made sure that struts-faces works with the current version of the RI (the code I'm most familiar with). But that has to wait until I do penance for being offline for a couple of months, by taking a whack at our failing cookie-related Cactus tests :-). cheers, matthias Craig On Mon, 05 Jul 2004 18:56:41 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: Ted Husted wrote: I imagine Craig has Struts-Faces compiling against 2.4 to make sure it stays in synch with Tomcat 5. It is indeed, but that's actually a mistake. It needs to compile against the 2.3 version, since that's what JSF specifies as a minimum platform. I'll fix that in tonight's run. But, the question is whether we want to mandate that Struts-Faces can only compile against 2.3 (and not 2.4)? Or vice-versa. Or is there a way to write the class so it compiles under either? I'll take a look at the changes once I catch up a little bit more, and might be able to come up with something clever that makes this possible (still recovering from JavaOne and ~11k backlogged mail messages :-). I know this is a pain. We went through the same problem with DataSources between 2.2 and 2.3. I'm not sure what the issue here is, but for DataSources, the interface changed and we had to stub the new members so that they threw exceptions if called. Of course, the problem with that approach is it may obviate new functionality or rely on deprecated methods. -Ted. Craig On Mon, 05 Jul 2004 14:14:02 +0200, Matthias Wessendorf wrote: James, i also guess it is the result of the commitment. i submitted (first) a wrapper, that builds against 2.4 reason is, the build-porperties had *default* to 2.4 okay ted asks for a 2.3-wrapper, so i created that candidate. i think the wrapper should compile against 2.3 since jsf is able to run in j2ee1.3-containers So i am wondering, why struts-faces uses 2.4 for compiling. btw. the 2.3 wrapper runs on servlet2.4-containers (like tomcat5.0) Matthias I think it is happening because of the changes I committed for your fix for MyFaces. If you look at when the builds stopped, it's right after I made the commits on 6/29. It must be an issue of what version of servlet.jar that the HttpServletRequestWrapper class is being compiled against. Is it not possible to make that class compilable against both 2.3 and 2.4? -James -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] wessendorf.de] Sent: Monday, July 05, 2004 6:29 AM To: [EMAIL PROTECTED] Subject: Struts-faces see http://cvs.apache.org/builds/jakarta-struts/nightly/struts- faces/ the nightly build is empty again, so is there a logfile, where i can check, why it is not build successful? Cheers, -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [OT] Re: Opening Salvo 'n CVS: step two: build time
Michael McGrady wrote: I have successfully, and without too much difficulty, now uploaded the struts src code into the wincvs as follows: 1. Downloaded and installed Python 2.3.4 from http://www.python.org/. 2. Downloaded and installed WinCVS13b18 from http://www.wincvs.org/. 3. Rooted around in http://sourceforge.net/docman/display_doc.php?docid=14033group_id=1 4. Got a reference to a WinCVS manual at http://cvsgui.sourceforge.net/howto/index.html. 5. Downloaded PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html. 6. Jettisoned PuTTY and went to SecureCRT at http://www.vandyke.com/products/securecrt/. 7. Got the jakarta cvs info source from Ted Husted: http://jakarta.apache.org/site/cvsindex.html. 8. Uploaded jakarta-struts with: Module name and path on the server = jakarta-struts Local folder to checkout to = C:\Program Files\GNU\WinCvs 1.3\ CVSROOT = :pwerver:[EMAIL PROTECTED]:/home/cvspublic I presume that I will want to do this all over and to find a more suitable place to put the code, once I decide how to go about building the code. I know there is a split of preferences between Maven and Ant going on. Could the adherents of each train of thought please give me what they would do to build? All the gory details are encouraged. Thanks. Who knows? Maybe in a week or so I might become useful. ?? Michael I'm only familiar with the command line compilation environments (once you've got the source code checked out). In either the Ant or Maven case, you'll want to install CYGWIN (http://www.cygwin.com) to give yourself a set of command line tools that is like those available on Unix and Linux systems. Then: For either type of build: - I recommend using J2SE 1.4.2 (the latest production JDK) from (http://java.sun.com/j2se). That's what the nightly builds are created with, and in general it has better performance than 1.3 (or earlier) JDKs. For an Ant-based build: - Download and install Ant (http://ant.apache.org) 1.5.4 or later per website instructions. - Examine the documentation on the Struts website for all the dependent libraries you'll need (basically all available from http://jakarta.apache.org). - Configure a build.properties file in the top-level directory of your jakarta-struts source tree to point at where you have downloaded all the dependencies. The simplest way to create this is to copy build.properties.sample to build.properties and edit the paths. - Open a command line window and navigate to the top-level jakarta-struts directory. - Execute ant clean dist. For a Maven-based build: - Download and install Maven (http://maven.apache.org) 1.0-rc4 or later per website instructions. - Open a command line window and navigate to the top-level jakarta-struts directory. - Execute maven clean dist. - (I'm sure that there's a Maven option that does enough to create just the JAR files needed to test, instead of all the extra reports that Maven likes; I don't use Maven regularly, so you'll need to ask someone else about that.) Note that, while easier to set up, the Maven build is still experimental. The Ant build is the official one. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-faces
Matthias Wessendorf wrote: In principle, this makes perfect sense. It'll be easy if you've split the MyFaces jars into api and impl classes (like the RI does), because then it's just a matter of setting up your own build.properties file and defining jsf-api.jar and jsf-impl.jar appropriately. no, not now. but i mean also the use of myfaces in the examples. so it would be much easier for users, since JSF (myfaces) is delivered directly for running the WAR-files. I'm perfectly happy to make using MyFaces configurable easily in our build scripts. But I'm -1 on including MyFaces in any Struts distribution until it has passed the TCK tests to certify that it is a compatible implementation of JavaServer Faces. Assistance in making that happen is one of the benefits you'll get by becoming an Apache project (once MyFaces passes through the incubation process), because Apache already has access to all the relevant TCK tests without having to apply for the scholarship that is available for non-profit orgs. But, until it does, it would be a disservice to Struts users to package something that represents itself as being JSF when it hasn't been proven to be so. Regarding the split of JARs, I would recommend you do that (javax.faces.* versus everything else) if you have not done so yet. The primary benefit is that users of MyFaces will only need the API jar in their compile time classpath, and will therefore not be tempted to program directly to the implementation classes and therefore lock themselves in to MyFaces (instead of being portable to anyone's JSF implementation). You'll need to include both the API and IMPL jars in a webapp, of course, but that's already taken care of by the build scripts for the struts-faces examples (assuming you configure the properties correctly). matthias Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tonight's Nightly Build Dependencies
Joe Germuska wrote: This is a Chicken and an an Egg situation. Not enough people use Validator standalone for it to be promoted. Validator 1.1.3 only works with a nightly build of Struts. So to get the required number of users Validator will need in a released version of Struts to get the testing it needs to be promoted. Isn't this one of the benefits of the new release scheme that both projects use?. It's a two-edged sword. If we always build nightlies from CVS-HEAD of the dependencies (which is essentially what Gump does), nobody ever has the chance to test the particular combination of JARs that we're actually going to include in the release. Now, we can at least say please treat nightly build MMDD as a release candidate for Struts 1.2.1, and test it, with some assurance that the bits being tested actually represent what we'll actually ship. I would be -1 on voting to call Struts 1.2.1 General Availability if we couldn't call Validator 1.1.3 General Availability -- but that isn't the same as being -1 on *releasing* Struts 1.2.1 The post-release vote on quality of a Struts release is just that ... a vote on its quality. But we wouldn't have the option to call 1.2.1 suitable for GA if Validator (or any other component) wasn't final yet, even if the quality was sufficient -- so I don't think we should even release it that way. At any rate, I've seen lots of assurances in my catching up on mail that Validator 1.1.3 will-be/has-been released, so it should just be a short matter of time. Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying Struts
Don Brown wrote: With my extra day off today, I took a look at ways to simplify Struts. Having been impressed by the simplicity of NanoWeb, I particularly looked at ways to change the Struts concept of Actions and ActionForwards to support POJO's and configurations that allow new actions to be written without requiring any changes to struts-config.xml. I described my findings in my weblog: http://www.jroller.com/page/mrdon/20040706#zero_configuration_with_struts What does the Struts developer community think of providing direct support for regular JavaBeans as actions? One feature of JSF I liked was how actions were simply no-arg methods on a JavaBean, making them easy to write and test. It's one of my favorite features too :-). Indeed, one possible avenue for further development would be to start with the infrastructure that JSF provides (managed beans, method and value bindings, perhaps navigation) and glue on the controller piece for higher level management of business logic and transactions. JSF components can be view-technology independent fairly easily (Hans Bergsten's book shows two different approaches to writing your own ViewHandler, for example). And, doing this would let you architect things the way WebWork does if you like that (an action in their world is essentially our Action + ActionForm in one class, instantitated per request). Incidently, I built my extension off struts-chain, so it works side-by-side regular Struts actions, forwards, and forms. With commons-chain out of the sandbox and Struts 1.2.1 around the corner (thanks Ted), I think it is time to start integrating struts-chain into the core. +1. We need that for first-class portlet support as well. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tonight's Nightly Build Dependencies
Ted Husted wrote: On Tue, 06 Jul 2004 00:41:13 -0700, Craig McClanahan wrote: Can whoever is going to be release manager for this confirm the version numbers? Did you want to go ahead and do it, Craig? There are other things I really should be doing right now, but no one else was available. Of course, if you are still recovering, I can finish up. I'm down to under 6000 messages to catch up on (primarily commons-dev and struts-user) -- it would sure be nice if you could finish up, while I keep reading -- and, along the way, do some testing on struts-faces. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-faces
Matthias Weßendorf wrote: see http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ the nightly build is empty again, so is there a logfile, where i can check, why it is not build successful? The 20040706 build was successful. http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ The nightly build job starts running at 3am (Pacific Daylight Time, GMT-7) every day, and gets around to the Struts part of the build around 7am. Cheers, -- Matthias Weßendorf Aechterhoek 18 DE-48282 Emsdetten Germany Email: matthias AT wessendorf DOT net URL: http://www.wessendorf.net Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts-Faces] wrapping a HttpServletRequest
Matthias Wessendorf wrote:
Hi, i tried the faces-struts-lib with RI.
It works.
Matthias,
Could you please explain in more detail exactly what appears to you to
be a bug in the struts-faces library that requires this wrapper, and
also what unspecified behavior in the RI is being relied on? This is
not at all obvious to me -- and I intend to pull the wrapper back out
unless you can show me why it's needed. The explanation below, and all
the mail threads and messages on bug 29809, still haven't made it clear
to me what the problems you are trying to solve really are.
Craig
But not with Open-Source-Implementation *MyFaces*.
i notices, that in struts-faces the servletPath is
a *.do (or that for struts).
But it must be an faces-mapping for servlet-Path
(*.faces e.g.)
the FacesRequestProcessor know if request is for
ActionSerclet or not.
If not, it delegates it to JSF-Impl.
Base of checking is a URI, that is configed
in forward name=success path=/test.faces/ (e.g.)
so i wrote a simple HttpServletRequestWrapper
which wrappes the uri as new ServletPath.
now everything is fine.
like this (in FacesRequesProcessor)
code
FacesContextFactory fcf = (FacesContextFactory)
FactoryFinder.getFactory(FactoryFinder.FACES_CONTEXT_FACTORY);
HttpServletRequestWrapper wrapper = new
HttpServletRequestWrapper(request,uri);
context = fcf.getFacesContext(servlet.getServletContext(),
wrapper,
response, lifecycle);
/code
it is not an error in myfaces-impl.
it is an bug in the RI.
please see the email of Ted Husted (on myfaces-list)
ted
On Wed, 23 Jun 2004 20:21:49 -0700,
[EMAIL PROTECTED] wrote:
the MyFaces implementation is correct in this aspect and I don't think
we should clone the bugs of the RI just because struts relies on them.
I hope spec-compliant does not mean we have to have the same bugs the
RI has ;-)? By the way, if the RI is fixed, struts will not work there
any longer, too.
The RI and Struts-Faces were created in tandem, so it's not surprising
the same assumptions crop up in each. But, no, specification-compliant
does not mean that we should rely on bugs in any implementation,
including the RI. In fact, the Struts tradition has been to expose bugs
in implementations so that vendors are compelled to fix them.
If you develop any patches you would like applied, please bring them to
my attention. Once we can get 1.2.1 out-the-door (could be this week),
we will be setting up several subprojects, including Struts-Faces, that
can be released separately.
So the clean solution from my point of view is to fix the issue in
struts. For example it would be possible to wrap the servlet request
before the FacesContext is created. The wrapper takes the uri of the
view to be displayed to simulate a valid jsf servlet path for the view
manager. What do you think?
Oliver
/ted
and here is the simple wrapper-class:
i can apply a patch, but on that i will
do a bit better documentation of that
wrapper-class
Cheers,
Matthias
/*
* Copyright 2002,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.struts.faces.util;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.UnsupportedEncodingException;
import java.security.Principal;
import java.util.Enumeration;
import java.util.Locale;
import java.util.Map;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletInputStream;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
/**
* pConcrete implementation of codeHttpServletRequest/code that
* that wrapps the codeServletPath/code with an URI, that was
detected
* by codeActionServlet/code to forward to a standard
codeFacesServlet/code.
*
*/
public class HttpServletRequestWrapper implements HttpServletRequest {
// --
Instance Variables
protected HttpServletRequest original = null;
protected String servletPath = null;
//
Constructors
/**
* pConstruct a new codeHttpServletRequest/code instance
* and an URI, which is used by codeFacesServlet/code./p
*
* @param request Original default
codeHttpServletRequest/code
*
* @param servletPat the new ServletPath for
Re: cvs commit: jakarta-struts/contrib/struts-faces/src/java/org/apache/struts/faces/taglib AbstractFacesTag.java BaseTag.java ErrorsTag.java HtmlTag.java MessageTag.java StylesheetTag.java WriteTag.java
James Holmes wrote: Just curious if these changes fix the problem with the broken s:base tag? Basically the tag was outputting and invalid href attribute on the generated base tag. This is a problem almost everyone was experiencing. Myself included. Sorry to be dense, but *what* broken output? What's wrong with it? Is there a bugzilla report on this? Both example apps work for me on Tomcat 4.1.29 and 5.0.25. But that was true before today's changes too; and I didn't change anything that should affect the URL being created. -James Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts-Faces] wrapping a HttpServletRequest
Matthias Wessendorf wrote: Craig, i tried the struts-faces-example with myfaces and RI (worked out of the box) this happens with myfaces: i clicked LINK editRegistration.do?action=Create and become IllegalArgumentException: could not find pathMapping for servletPath = /editRegistration.do requestPathInfo = null net.sourceforge.myfaces.application.jsp.JspViewHandlerImpl.getServletMap ping(JspViewHandlerImpl.java:407) net.sourceforge.myfaces.application.jsp.JspViewHandlerImpl.renderView(Js pViewHandlerImpl.java:185) org.apache.struts.faces.application.ViewHandlerImpl.renderView(ViewHandl erImpl.java:134) net.sourceforge.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.jav a:282) org.apache.struts.faces.application.FacesRequestProcessor.doForward(Face sRequestProcessor.java:148) okay, after that i looked in myfaces JspViewHandlerImpl.java and noticed we only react on FacesServlet-Mappings (eg *.faces, /faces/*,...) i changed it, now it works but as a result of following discussion on myfaces-mailinglist (see the three forwards) i decided to create that wrapper, that sets requestPath from struts (*do) to faces (*.faces) now it works again with myfaces and of course RI so perhaps you have other hints on that? Matthias Matthias, Thanks for the forwards ... I'm going to get out my trusty debugger and walk through this in detail. At first glance, it appears more likely that the problem is in Struts, calculating the view id in the created component tree (the processing should convert /registration.faces to /registration.jsp in the particular example webapp, before calling ViewHandler.renderView()). If that were to be done, a ViewHandler implementation that relied solely on the view id *should* work, with no wrapper -- we'll see if that prediction comes true or not. This chunk of code is bringing back bad memories :-) of the work it took to get this to run at all. I see that it needs some more work :-) :-). The change in servletPath is part of what a RequestDispatcher.forward() call normally does (that's what happens on a normal Struts request). I ran into quite a few difficulties making an RD.forward() to the Faces servlet do the right thing here -- but if using a wrapper ends up being the right solution, there's some other things we'll need to change as well so that it works with a prefix mapped FacesServlet (/faces/*) too. More news as I debug this further. Craig PS: There was an implication in the mail and bug report comments that the RI is violating the spec in its view handler implementation. If it is, I'd like to fix that, and my commit privileges there still work :-). Can you point to any specific place where that might be true? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-faces/src/java/org/apache/struts/faces/taglib AbstractFacesTag.java BaseTag.java ErrorsTag.java HtmlTag.java MessageTag.java StylesheetTag.java WriteTag.java
James Holmes wrote: The problem is/was that the s:base tag was rendering invalid base element: The JSPs in the struts-faces war (i.e. logon.jsp) have an s:base id=base/ that generates the following: base href=/struts-faces/logon.faces / The href should have a fully qualified url (i.e. http://...) right? This causes the browser to not be able to find the stylesheet for the page. Not only should it be absolute (although the browser I tried it with actually still worked right with a server relative path), it needs to be the path of the JSP page itself. That isn't critical if you use extension mapping for FacesServlet, but it really matters if you use prefix mapping, where the generated HREF would have been /struts-faces/faces/logon.jsp and therefore added a directory level. I presume you have fixed after seeing your last commit? Yep, it should be fixed now ... can you give it a try? -James Craig -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 07, 2004 8:33 PM To: Struts Developers List Subject: Re: cvs commit: jakarta-struts/contrib/struts-faces/src/java/org/apache/struts/faces/taglib AbstractFacesTag.java BaseTag.java ErrorsTag.java HtmlTag.java MessageTag.java StylesheetTag.java WriteTag.java James Holmes wrote: Just curious if these changes fix the problem with the broken s:base tag? Basically the tag was outputting and invalid href attribute on the generated base tag. This is a problem almost everyone was experiencing. Myself included. Sorry to be dense, but *what* broken output? What's wrong with it? Is there a bugzilla report on this? Both example apps work for me on Tomcat 4.1.29 and 5.0.25. But that was true before today's changes too; and I didn't change anything that should affect the URL being created. -James Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version of Jakarta-ORO (Re: Tonight's Nightly Build Dependencies)
Joe Germuska wrote: At 12:41 AM -0700 7/6/04, Craig McClanahan wrote: I've updated my nightly build script (effective with the 20040706 build) to use the following dependnet libraries, which I'm assuming corresponds to what we'll actually use in a Struts 1.2.1 release. Can whoever is going to be release manager for this confirm the version numbers? jakarta-oro 2.0.7 I just happened to be looking this over to check the versions in the Struts 1.2.1 distribution and I noticed that we're using Oro 2.0.7 but the current release is 2.0.8. Is our general plan always to use the newest release of all libraries? If so, we should update the Oro dependency. Small, I'm sure, but still... Joe Has anyone tested with 2.0.8? If so, I don't have any problem with picking this up in a subsequent 1.2.x release. I'll update the nightly build dependencies for tonight's run. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] - Bill Siggelkow for committer
James Mitchell wrote: I have known Bill for a few years and he is definitely committer material. He has contributed in numerous ways to this community and others. I owe him a great deal for his help with our local Struts Users group, founded in Atlanta (ASUG) http://www.struts-atlanta.org. He has given presentations, mentored junior members, and is responsible for persuading the powers that be into letting us meet at his (former) employer. I can't say enough about his generosity. If anyone is wondering about his skillset, don't. He is writing the next O'Reilly book on Struts. Here is my +1 +1. Craig -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Interim Build Location
In catching up on back email, I noticed a piece of advice about where to put interim builds that should be made available to the public for review, but are not official signed releases (which would go to http://www.apache.org/dist). The suggestion from infrastructure was to use: http://cvs.apache.org/dist/ which has the dual advantages (over someone's arbitrary home directory) of implying that this is likely to become a release unless there are fatal problems with it, and it doesn't go out to the mirror networks. I suggest we use this approach for release candidates (and alpha/beta voted releases) until they are voted GA. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.1 to which Maven repo? (RE: [ANN] Struts 1.2.1 (Beta) Released)
My thoughts below. Joe Germuska wrote: I'm bringing this thread over to the dev list because it's fairly technical and boring to the average user. I went ahead and set up the nightly builds Maven repository with Struts 1.2.1 -- see http://cvs.apache.org/repository/struts/ I tried to flesh out the directories along the idealized Maven repository, by including 'licenses', 'distributions','poms', and 'tlds' directories as well as 'jars' Not sure if that's right or not, since it doesn't seem to be thoroughly documented; we'll just see. Anyway, so the two pertinent questions are 1) should this go on iBiblio yet? I'm leaning towards no until it reaches GA status. For general reference, the Apache directory /www/www.apache.org/dist/java-repository is mirrored to iBiblio, so that when we decide that a Struts release is GA, we can set up that directory and have the release maven-published automatically. I don't think we should go into /www/www.apache.org/dist/java-repository without a GA build, because that directory also gets mirrorred around the world ... and *that* should only contain GAs. That being said, a private alpha/beta Maven repository on Apache someplace seems reasonable. 2) what version number should struts-el have? 1.2.1 ? I'm not sure we've bothered with formally labelling it with a release in the past, but Maven really likes things to have versions. If we ship it with the standard Struts release, it should have the same version number. If it's shipped separately, then it should have it's own version number series. (That's what I plan to do when struts-faces is ready to be released). On minor administrative issues, I also changed the project.xml file version to 1.2.1 (from 1.2.1-dev) and moved the release tag for that one file so that if someone checks out to the tag, the JAR artifact will have the correct version number. Joe Craig PS: Per my comments last night, we also need to set up our own download page for GA distributions that leverages the mirror network, the way that Ant and Maven etc. do it, rather than continuing to rely on the Jakarta page (which is getting increasingly hard to use because of the number of releases found there. Does anyone have time to work on that? At 5:41 PM +0200 7/12/04, Carlos Sanchez wrote: Hi Joe, I agree that users should use iBiblio, just said apache repository because it's mirrored. About the use of the private repo http://cvs.apache.org/builds/java-repository/ seems a good idea to me, but it hasn't been already created, nobody has upload nothing until now? Many apache projects still upload their snapshots to the release repository, ending at iBiblio. Should this be told to the projects that had uploaded snapshots to ibiblio? I am also sure that 1.2.1 should definitely be put at http://cvs.apache.org/builds/java-repository/ Regards. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, July 12, 2004 4:08 PM To: Struts Users Mailing List Subject: 1.2.1 to which Maven repo? (RE: [ANN] Struts 1.2.1 (Beta) Released) At 11:34 AM +0200 7/12/04, Carlos Sanchez wrote: Hi, Will you deploy it and the struts-el on the apache maven repository? http://www.apache.org/dist/java-repository/struts/jars/ I would argue that it doesn't belong in that location until it is voted a full GA release. Then again, reviewing what seems to be the official word on using the Apache repositories (http://article.gmane.org/gmane.comp.jakarta.commons.devel/39469), it simply says that location is for versioned releases as opposed to nightly builds. For what it's worth, I think that the intention is not that Maven users would have http://www.apache.org/dist/java-repository/ as a repository, but rather than they'd use iBiblio, which is mirrored from that. I don't know if anyone feels strongly about it, but that's how I read the previously cited email. If we don't put Struts 1.2.1 on iBiblio, we should definitely put it at http://cvs.apache.org/builds/java-repository/ I'll do either one, but I'll wait to see if a few opinions roll in before taking action. Joe I have built it from cvs sources with maven and the size is not the same. Regards Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, July 11, 2004 9:11 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [ANN] Struts 1.2.1 (Beta) Released The Struts team announces the release of Struts 1.2.1, currently ranked at Beta quality. This release removes many features deprecated in prior releases (Struts 1.1 and Struts 1.0.2) and also provides several new features. Fixes to known problems have been applied. More detail is available at * http://struts.apache.org/userGuide/release-notes.html The binary, source, and library distributions are available at *
Re: CVS reorg: jakarta-struts - struts
Joe Germuska wrote: Apropos of the earlier discussion about Maven repositories and such, I'm going to try to spend at least a couple of hours staking out a new CVS repository for struts-as-TLP. I'm going to try to set up a local repository on my machine with a copy of /home/cvs/jakarta-struts and see what I can do with just moving files around. Assuming that I get anywhere at all, are people OK with setting it up in CVS under the module struts and letting people use the Apache CVS server to test it? If not, I might be able to find a place to host it. Joe +1 on having a repository available somewhere to play with, if what you come up with looks useful. -0 on having it on Apache hardware, until we adopt it officially. I think it would be confusing to people in the interim period between when it was installed and when it was adopted/abandoned. Regarding a couple of other issues that are fuzzy in my mind: * Did we end up agreeing with one repository (versus multiple) in the new world repository? If so, struts is a good name for it. Otherwise, we might want to call it struts-experimental or something during the trial and testing phase. * Did we end up deciding to stick with CVS versus Subversion? I know the infrastructure team would be happier if we switched to svn ... I haven't played with it enough to form an opinion on that yet. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CVS reorg: jakarta-struts - struts
Martin Cooper wrote: 3) Given the factoring into sub-projects that we want to do, we'll no doubt be making extensive use of Maven's multi-project capabilities. It would be nice to know what that actually means, especially in terms of constraints. (I'm afraid I don't have much of a clue, so I'm hoping someone else does. ;) Looking at what the Geronimo crowd is doing (extensive use of this Maven facility) should provide some fruitful material for study. I'm sure that those guys would also provide pointers about what works (and, more importantly, what doesn't work) when managing a large, complex, code base with lots of cross dependencies. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: First Build via CVS and getting a LogFactory error.
Michael McGrady wrote: I am trying to build Struts via CVS in order to get my hands dirty with a bit of assistance in documentation. I am having one difficulty (error) with the build. The error is: [javac] ^ [javac] C:\src\apache\jakarta-struts\src\share\org\apache\struts\action\ActionServlet.java:296: release() in org.apache.commons.logging.LogFactory cannot be applied to (java.lang.ClassLoader) [javac] LogFactory.release(classLoader); Anyone know what this is about so that I don't have to reinvent the wheel to get a build to work with? Thanks. Michael I'd guess you're building against a commons-logging.jar file that came with Struts 1.1, which didn't have the particular method referenced in this error message above. You'll want to grab the versions of each commons JAR file that are listed in the release notes in order to compile the most recent Struts code. All of these packages are available at the Jakarta download page: http://jakarta.apache.org/site/binindex.cgi Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [wiki] Requiring users to register
Martin Cooper wrote: In the wake (or perhaps midst?) of the recent spam on the Struts wiki, and numerous other wikis at Apache, I plan to ask infra@ to restrict changes to the Struts wiki to registered users only. +1 Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: cvs commit: jakarta-commons/chain/src/test/org/apache/commons/chain/config ConfigParser2TestCase.java test-config-2.xml]
Folks who are planning to work with struts-chain (both for use inside
Struts and for your own command chains) will enjoy a usability
improvement that I just added to commons-chain. It'll be available in
tonight's nightly commons-chain build, or you can get it now in CVS.
Craig
---BeginMessage---
craigmcc2004/07/16 12:06:01
Modified:chain/src/java/org/apache/commons/chain/config
ConfigRuleSet.java
Added: chain/src/java/org/apache/commons/chain/config
ConfigDefineRule.java
chain/src/test/org/apache/commons/chain/config
ConfigParser2TestCase.java test-config-2.xml
Log:
Enhance the readability/writeability of configuration files for command
chains, by supporting a new define element that dynamically adds new
Digester rules to the running instance, allowing use of elements without
having to specify the command or chain implementation class every time.
For example, assume you wanted to use two different instances of a
particular command in two different chains:
chains
...
chain ...
...
command className=com.mycompany.mycommands.FooCommand/
...
/chain
chain ...
...
command clasName=com.mycompany.mycommands.FooCommand/
...
/chain
...
/chains
Now, you can define an alias for this command and reuse it:
chains
...
define name=foo className=com.mycompany.mycommands.FooCommand/
...
chain ...
...
foo
...
/chain
chain ...
...
foo
...
/chain
...
/chains
The dynamically generated rules include a Set Properties rule, so that you
can configure properties on aliased commands just like you can with the
chain or command elements directly.
See the unit test input file (test-config-2.xml) below for more examples.
Revision ChangesPath
1.7 +29 -1
jakarta-commons/chain/src/java/org/apache/commons/chain/config/ConfigRuleSet.java
Index: ConfigRuleSet.java
===
RCS file:
/home/cvs/jakarta-commons/chain/src/java/org/apache/commons/chain/config/ConfigRuleSet.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ConfigRuleSet.java9 Jul 2004 00:03:25 - 1.6
+++ ConfigRuleSet.java16 Jul 2004 19:06:01 - 1.7
@@ -47,6 +47,10 @@
* representing the addition of a [EMAIL PROTECTED] Command}. An implementation
* class name must be provided on the attribute named by the
* codeclassAttribute/code property. [command]/li
+ * listrongdefineElement/strong -- Name of the XML element
+ * that associates the element specified by the codenameAttribute/code
+ * attributes with a [EMAIL PROTECTED] Command} or [EMAIL PROTECTED] Chain}
implementation class
+ * named by the codeclassAttribute/code attribute. [define]/li
* listrongnameAttribute/strong -- Attribute on an outermost chain or
* command element that will be used to register this command with the
* associated [EMAIL PROTECTED] Catalog} instance on the stack. [name]/li
@@ -69,6 +73,7 @@
private String chainElement = chain;
private String classAttribute = className;
private String commandElement = command;
+private String defineElement = define;
private String nameAttribute = name;
@@ -148,6 +153,24 @@
/**
+ * pReturn the element name of a define element./p
+ */
+public String getDefineElement() {
+return (this.defineElement);
+}
+
+
+/**
+ * pSet the element name of a define element./p
+ *
+ * @param defineElement The new element name
+ */
+public void setDefineElement(String defineElement) {
+this.defineElement = defineElement;
+}
+
+
+/**
* pReturn the attribute name of a name attribute./p
*/
public String getNameAttribute() {
@@ -194,6 +217,11 @@
digester.addSetProperties(*/ + getCommandElement());
digester.addRule(*/ + getCommandElement(),
new ConfigRegisterRule(nameAttribute));
+
+// Add rules for a define element
+digester.addRule(*/ + getDefineElement(),
+ new ConfigDefineRule(getNameAttribute(),
+ getClassAttribute()));
}
1.1
jakarta-commons/chain/src/java/org/apache/commons/chain/config/ConfigDefineRule.java
Index: ConfigDefineRule.java
===
/*
* Copyright 1999-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may
Repository Reorg (Once More With Feeling)
Here's another crack at trying to get us moving forwards on the repository reorg. Given the feedback of our most recent discussions, I'd like to focus on the following motivations for a particular decision on the organization of the repository, followed by what seems to make sense based on those motivations: * Use Subversion for the new repository (I've played enough to be sold). * Use Maven 1.0 for the build tool (we need to deal with persistent user complaints about complexity of our build process, plus enable independent module releases gracefully). * In general, follow Maven's recommendations for directory layout on multi-module builds. * Continue to build 1.2.x releases off the old (jakarta-struts) repository (taking the time pressure off on getting the new architecture perfect the first time). * Focus the new repository on supporting 1.3.x development (generally backwards compatibile, but using chain-based request processor, adding support for portlet), in prep for later migration to 2.x.x development (which might end up in either separate modules or a separate repository -- too early to tell at this point). * Separate modules for independently releaseable artifacts. * Modules can depend on each other (i.e. pretty much all will depend on core), but we should exercise caution if the dependency tree gets deep ... complexity lurks here. * The core module should have no view tier dependencies. * There is no need for a separate JSP-specific module for TagUtils. That class is tightly coupled to the legacy tag libraries, so it should go in the same module. * We'll need to do some minor refactoring to optimize things after the rearrangement, but that shouldn't delay getting started. * Each module (of course) includes its appropriate complement of unit tests. Given the above, here's my suggestion for the top-level modules in the initial repository, and the packages and classes that should be included there: (1) core -- Core Framework Dependencies: commons-beanutils commons-chain commons-digester commons-fileupload commons-logging commons-resources (once graduated) commons-validator jakarta-oro (inherited from commons-validator) Packages and Classes: org.apache.struts.Globals org.apache.struts.action.* org.apache.struts.chain.* org.apache.struts.chain.legacy.* org.apache.struts.chain.portlet.* (to be created) org.apache.struts.chain.servlet.* org.apache.struts.chain.util.* org.apache.struts.config.* org.apache.struts.config.impl.* org.apache.struts.tiles.* org.apache.struts.tiles.actions.* org.apache.struts.tiles.beans.* org.apache.struts.tiles.definition.* org.apache.struts.tiles.xmlDefinition.* org.apache.struts.util.* org.apache.struts.validator.* org.apache.struts.validator.validwhen.* NOTE: Plan on migrating to commons-resources in 1.3 time frame. NOTE: Should end up with a single integrated request processor chain for tiles/nontiles. NOTE: Should end up with request processor chain that works in portlet environment, providing adapters to call 1.x compatible Action methods. (2) addons -- Standard generic add-in functionality Dependencies: core Packages and Classes: org.apache.struts.actions.* org.apache.struts.plugins.* org.apache.struts.upload.* (3) taglib -- Legacy non-EL based tag libraries Dependencies: core Packages and Classes: org.apache.struts.taglib.* (i.e. the TagUtils class) org.apache.struts.taglib.bean.* org.apache.struts.taglib.html.* org.apache.struts.taglib.logic.* org.apache.struts.taglib.nested.* org.apache.struts.taglib.nested.bean.* org.apache.struts.taglib.nested.html.* org.apache.struts.taglib.nested.logic.* NOTE: Generation process for TLDs and associated docs should live here, but the resulting docs will probably need to be imported into site somehow. (4) taglib-el -- Legacy EL-based tag libraries Dependencies: core, taglib Packages and Classes: org.apache.strutsel.taglib.bean.* org.apache.strutsel.taglib.html.* org.apache.strutsel.taglib.logic.* org.apache.strutsel.taglib.tiles.* org.apache.strutsel.taglib.utils.* (5) faces -- Struts-JSF integration Dependencies: core Packages and Classes: org.apache.struts.faces.* org.apache.struts.faces.application.* org.apache.struts.faces.component.* org.apache.struts.faces.renderer.* org.apache.struts.faces.tagib.* org.apache.struts.faces.util.* NOTE: The only components that should be included are those that have direct analogs to legacy Struts tags (to easy conversion). General purpose JSF components (if any) should go elsewhere. (6) examples -- Example Struts-based web applicatons All the existing example applications from core, tiles, struts-el, struts-chain, struts-faces, ... *except* documentation, which gets subsumed into the site module. May need to make sub-modules here; remains to be seen. (7) site -- Struts web site source Dependencies: None. All the usual xdocs stuff to create our website and the associated documentation. WDYT? I'd like to take advantage of the fact that I've got a modicum of
Re: Repository Reorg (Once More With Feeling)
[snip] We might want to start by getting the struts-core and struts-site building first. Site would have a number of under-construction links at first, which would go away as each subproject came online. What's in the other subprojects then defined by what is not in the core. (And for now, when in doubt, let's leave something out. We can always put it back later.) I'm playing in an experimental Subversion repository (to get used to svn's approach to branches, plus play with Maven some), and so far have gotten a core module that compiles clean. I had to leave out Tiles (should make Martin happy :-) as there are too many cross-imports. Other than that, the only changes needed were: * Migrate a few constants from o.a.s.taglib.Constants to o.a.s.Globals. * Remove the deprecated methods in RequestUtils and ResponseUtils that delegated to TagUtils (which, I believe, should stay in whatever module the tag classes themselves go in). I haven't migrated any tests yet ... that'll be next. Of course, we don't have very many tests that focus just on the core part, so it should be fairly easy. Personally, I want to stay focused on the code part first, and would prefer someone more familiar with Maven and xml-html transformations would focus on the site module. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository Reorg (Once More With Feeling)
On Tue, 20 Jul 2004 06:53:04 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 19 Jul 2004 21:21:52 -0700, Martin Cooper wrote: (BTW, that's something I think we should develop a policy on, so that we're not seen as making arbitrary decisions in this area, but that's another topic entirely.) I think the decision would have to depend on who is going to maintain the glue. A case in point is the VelTools. There's some Struts glue that is currently being maintained there. I encouraged that since the people interested in the glue were members of the Velocity community. A volunteer shouldn't have to follow a DEV list to maintain code, they should maintain code because they are following a DEV list. :) Of course, that's changed a bit now, and we have VelStrutsTools people who hang out here now, so today it could go either way. We have precedents for dealing with this that seem to work fine: * File upload -- generic code in separate (Commons) package; glue in Struts * Chain integration -- same thing If the Tiles folks want to create a Struts-free distribution, two separate modules (generic and glue) are certainly possible. And, as far as I'm concerned, the generic one is welcome to stay here. In a volunteer organization, some decisions may seem arbitrary, since the volunteers can be arbitrary, and decisions without volunteers don't exist. :) -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF vs Struts
On Wed, 21 Jul 2004 10:27:29 -0500, Hookom, Jacob [EMAIL PROTECTED] wrote: Would there be any interest in starting an Apache JSF implementation with a component repository for the open source community? I have about 80% of an implementation written... That sounds a lot like the MyFaces project http://sourceforge.net/projects/myfaces, which just got accepted in to the Apache incubator. Regards, Jacob Craig -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 12:13 PM To: Struts Users Mailing List Subject: Re: JSF vs Struts On Mon, 19 Jul 2004 10:25:13 -0400, Rick Reumann [EMAIL PROTECTED] wrote: We're thinking about using Flash forms for some things. Will they plugin nicely to JSF? Hooking up the output side of that should be a piece of cake ... write some components that render the necessary markup to embed the Flash stuff in the generated page. I'm not familiar with the input side of using Flash for this, but in principle it should still just be a matter of having your component (or renderer) decode() method parse the appropriate request parameters and store the values, just as the standard HTML components do. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: r3990 - trunk/src/share/org/apache/struts/taglib/html
On Thu, 22 Jul 2004 15:34:52 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: niallp Date: 2004-07-22 15:34:51 -0500 (Thu, 22 Jul 2004) New Revision: 3990 Modified: trunk/src/share/org/apache/struts/taglib/html/FormTag.java Log: Modified: trunk/src/share/org/apache/struts/taglib/html/FormTag.java Niall, The diff for this commit looks like it replaced the entire file (probably a line ending difference or something, which we need to figure out), and there's no comment in the log about what actually changed. So, what actually changed? :-) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 30364] - org.apache.struts.validator.DynaValidatorActionForm.validate(DynaValidatorActionForm.java:115)
On Wed, 28 Jul 2004 11:16:51 -0500, Matt Bathje [EMAIL PROTECTED] wrote: --- Additional Comments From [EMAIL PROTECTED] 2004-07-28 15:57 --- P.S. Rather than raising a *bug* report against Struts could you please post problems like this to the user list first. Raising *Bugs* is not the best way to get help - asking questions on the user list is. Thanks This is going to sound bad maybe - but from some peoples perspective, filing a bug report IS the best way to get help. Some questions to the users mailing list go unanswered (even something simple like this may get ignored.) When somebody files a (non)bug report like this though, it always seems to gets closed out very quickly with an answer and a reprimand to use the users list. The bug reporter gets exactly what they want - a quick answer. They can completley ignore the reprimand if they want. Now maybe this isn't a problem to anybody and it certainly doesn't bother me, I just thought I would bring it up based on what I've seen in the few months I've been part of the struts community. Of course, if this does bother people (especially if those people are committers) we need a solution. The only one I can think of is to stop rewarding the behavior - when somebody posts a question to bugzilla, it gets shut down quickly, but with no answer, just a pointer to the mailing list. (Whoever closed it down can also be sure to watch for the question on the user list and answer it so as not to piss people off...) Again, sorry if I am raising a non-issue, I just thought I would mention it. Matt, there are several big picture reasons that questions (as opposed to bug reports) should be raised on the user mailing list. * Issue tracking systems do not make it particularly easy to have a conversation and explore possibilities, particularly compared to how you can interleave conversational elements in responses to mailing list messages. * The audience of people available to answer your question is much larger than the audience of people who read bug reports. * The audience of people on the user mailing list probably has more experience *using* Struts than the developers do; they are much more likely to have run into something similar and figured out what to do. * When an answer is given on the mailing list, it is archived in many locations that provide powerful searching capabilities. The number of people who search mailing list archives before asking the same question again (while not as large as user list subscribers might prefer :-) is orders of magnitude larger than the number of people who would ever search the bug tracking system's archives. If you expect to actually get your questions answered, then, the user mailing list is the best place. However, if you expect to *always* get an answer, in a timely manner, then I'm afraid your expectations are never going to be met (no matter what approach you take for asking them) -- the people who answer questions (as well as create Struts) are all volunteers. Matt Bathje Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 30364] - org.apache.struts.validator.DynaValidatorActionForm.validate(DynaValidatorActionForm.java:115)
On Thu, 29 Jul 2004 03:49:38 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: I don't see this as a big issue and my intention was more of polite request rather than reprimand - although it may not have come accross that way. Seems to me that in a large and (hopefully) expanding community there are always going to be new people that don't know the conventions that this community operates under. My impression is that once people have been asked to use the user list rather than bugzilla they do (and querying INVALID tickets in bugzilla seems to back this up). Niall P.S. I'm -1 on Robert Michel's suggestion to give me a good flogging for including an answer when closing the bugzilla ticket :-) Niall, You're absolutely corect ... that's why I (politely) ranted at people who post questions in bug reports instead of at you for answering the question there. Of course, getting flogged for being too helpful has gotta mean you are doing *something* right :-). The friendliness and helpfulness of the Struts community in general is something I am very proud of, and I brag about it every chance I get. I've seen way too many open source projects where the developers sneer at their users. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Tue, 31 Aug 2004 18:31:27 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 30 Aug 2004 10:14:15 -0700, Craig McClanahan wrote: I also suspect, given our track record :-), that re-engineering Struts from scratch based on the latest platform APIs wouldn't take more time than a gradual refactoring from the current code. I sometimes wonder if not getting a clean start is why things keep taking so long. :) This is definitely a factor. The codebase was not designed to be easily tested. People are skittish about making significant changes, and so we tread softly and slowly. To mangle an old chestnut: I've been test-first, and I've been test-last. Test-first is better (and faster!). Given when (in the evolution of Java best practices) Struts was developed, I've been delighted at how long it has remained viable. Given where technology has proceeded since then, I'm personally going to be focused on the revolution approach rather than evolution. That's not to say that we (as a project) can't do both in parallel. But I probably won't be involved with new development myself, and them that do the work can make the decisions :) To the extent that this (you not being involved in the new development) turns out to be true, I'll be sad for not getting to continue to appreciate the immense number of high quality contributions you've made to Struts (in code, documentation, process, and community building) -- and glad to see that you haven't given up on open source projects at Apache :-). Good luck with your future endeavors! But we won't have any problem keeping your committer access readily usable either :-). Anyway, it does sound like the consensus is to create STRUTS_1_2_BRANCH at the 1.2.2 tag, dub the HEAD 1.3.0, and document the minimum for the HEAD as Servlet 2.3. +1 -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
On 1 Sep 2004 11:34:00 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: niallp 2004/09/01 04:34:00 Modified:contrib/struts-faces/web/example logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/example2 footer.jsp header.jsp layout.jsp layout1.jsp loggedoff.jsp loggedon.jsp logon.jsp mainMenu.jsp registration.jsp subscription.jsp contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp Log: Change jsp taglib URIs to struts.apache.org - thanks to Matthias Wessendorf for spotting this Doesn't this mean that the apps would not run in a Struts 1.1 environment? If so, that's not acceptable, and I'm -1 on this change. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Wed, 01 Sep 2004 09:56:41 -0500, David Durham [EMAIL PROTECTED] wrote: James Mitchell wrote: That would be a bad mistake. How many products do you know that have a 1.5 minimum requirement? If we're talking about Struts 2.0, it's not actually a product yet, so it's purely speculation. The beehive folks did exactly this (base their code on JDK 5.0) so that they could take advantage of annotations, generics, and all that in their API designs. Looking at their code sure makes me jealous :-). And, they did it based on the same reasoning I proposed -- by the time we're *done*, JDK 5.0 will be widely deployed. And, in the mean time, a branch continuing the development of Struts 1.2.x (or perhaps 1.3.x) is certainly appropriate, since it is the mature version of the product that is better off being stable and backlwards compatible. (This parallel universes split is exactly what happened with the Apache HTTPD project, using exactly the 1.3 and 2.0 version number sequences :-). I'm not saying move the 1.x branch to 1.5. I'm not even saying that you *should* move the 2.0 branch to 1.5. I just thought I would put it out there as a thought. It's more than a thought ... I was about three keystrokes from including this in my proposal to be forward looking on servlet 2.4 and JSP 2.0 :-). - Dave Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-faces/web/systest context.jsp context1.jsp logon.jsp logon1.jsp simple.jsp
On Wed, 1 Sep 2004 18:45:22 -0400, Deadman, Hal [EMAIL PROTECTED] wrote: Maybe Craig's point was that you could put two copies of the tld in the jar's META-INF, one with the old URI and one with the new. The tlds would be otherwise identical but auto-discovery would work no matter what URI the application was using. Not sure how else you would acheive this: That was exactly my point. (Struts 1.2.x should recognize both the old and new tag library URIs, but shouldn't require applications to switch.) Otherwise, a Struts 1.1 application that relies on the implicit TLD registration done by the container (i.e. *not* listing the TLDs explicitly in web.xml) will go down in flames when run against Struts 1.2.x, unless you go fix the taglib directives in every single page. Basically, it's the same reason that Struts 1.2.x accepts and processes 1.0 and 1.1 versions of struts-config.xml files ... so that older apps can run with minimal changes when you upgrade Struts. It turns out that this doesn't matter for the particular commit message I replied on (which only changed the URI for the struts-faces TLD), but it's an important backwards compatibility principle in general. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts 1.2.3 release
On Thu, 2 Sep 2004 13:50:30 -0700, Martin Cooper [EMAIL PROTECTED] wrote: On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote: * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). Following discussion on the list, did we want to make that the CVS freeze/tag/branch date? Of course, we could always branch on the tag later too. I'd been thinking that we'd create the branch, based on the tag, when we decide we need / want it. Once this release ships, I'd like to update the roadmap and other documents to reflect Servlet 2.3 as the minimum platform for Struts 1.3.x. Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree of revolution will happen in this next (2.3-based) version, as well as some logical evolution. I haven't yet seen any proposed advantages *to Struts future* listed for Servlets 2.4, and my own focus is on getting away from JSP dependencies in the core, so I'm not sure how much the 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0. But that's really another thread... I gathered that the conclusion for the evolution branch (which, IMHO, should be called 1.3 if it's going to focus on things like the chain version of RequestProcessor but remain fundamentally backwards compatible). FWIW, here are some specific technical benefits (for the framework architecture, for applications based on it, or both) if we were to choose Servlet 2.4 over Servlet 2.3: * HttpServletRequest.setCharacterEncoding() allows applications to resolve nearly all the ambiguities of parsing request parameters in the right encoding (which is a smaller number of problems than it used to be in 2.4 generally, because the rules have been tightened, and because of the next feature). * You can define (in web.xml) your own mapping table from locale to character encoding, rather than relying on the container's undocumented (and likely non-portable) defaults. * Filters can be declared to run on RequestDispatcher.forward() calls as well as on the original request. Without this, it's basically impossible to write use-case-specific Filters in an MVC framework that uses RD.forward() the way Struts does today. * ServletRequestListener fleshes out the lifecycle model, so you can do things like adding some resource to the request attributes, and knowing that it will get cleaned up (after the response has been rendered by the JSP page or whatever) by your listener. * ServletRequestAttributeListener can listen to changes on your request attributes, similar to how HttpSessionAttributeListener and ServletContextAttributeListener work in 2.3. * On an HttpSessionBindingListener, the listener is invoked when you actually expect it to be at session end (*before* the session is invalidated, rather than after). * Welcome Files can now be servlets, so you can use index.do instead of having an index.jsp that forwards to an action that does your setup. * Deployment descriptors (web.xml) that conform to the 2.4 schema can have their elements listed in any order, instead of the pretty arbitrary sequence required by 2.3. The benefits of JSP 2.0 over 1.2 are even more compelling, but have been discussed before. My favorite three favorite features are EL everywhere, tag files (a way to create simple UI components with just JSP code), and the simple tag API. Counterbalancing all of this, of course, is the question of installed base. And, of course, that is a question that has a different answer at different times. If we want to work towards a GA quality 1.3 release in 3-6 months (possible if the set of changes is limited), than staying with 2.3/1.2 makes a lot of sense. But if it takes us the more typical 12-18 months, where do *you* think the world is going to be by then? NOTE: None of this is to suggest that maintenance activities on 1.2.x should not continue. However, it should, IMHO, be focused on bug fixes rather than feature enhancements, and should (of course) remain based on Servlet 2.2 / JSP 1.1. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Thu, 02 Sep 2004 19:06:44 -0400, Frank Zammetti [EMAIL PROTECTED] wrote: Ironic as it seems to myself to be saying it, I don't think I like the idea of Struts moving to newer spec/JDK versions just yet. Here at work, most of our development is now Struts-based, and much of it is moving to IBM Portal Server. Unfortunately, because of some issues between that product and WebSphere itself (and probably some other components), we are currently very sensitive to versioning, more so than we might otherwise be. Ironically, people wanting to run Struts in a portlet (JSR-168 compatible) environment should be the ones most interested in a Struts revolution :-). The current method signatures for all the important methods are very much dependent on the servlet APIs, and the various portal server vendors have all done their own (non-interoperable) modifications to Struts to make it kind-of sort-of work. We should be doing that. We can't do that based on Servlet 2.2 / JSP 1.1. Craig For instance, I have a production app that is based on Struts 1.1, and I have it running on a rogue Tomcat server with JDK 1.3.1 because IBM is not yet supporting a higher JDK version, believe it or not! If the newest Struts has a bunch of cool features, but it requires a higher JDK or higher servlet specs than Tomcat or Websphere (when we finally figure out how to get the app up on it), I'm going to be in a bind with this app because I'm sure to want to use those features (and being able to make some good business cases for doing so even) but not be able to. If nothing else, that's going to be depressing :) The flip-side of the argument of course is that eventually everyone is going to want, and be able, to move to all the newest specs, JDK levels, etc., me along with them. And of course the difficult decision is when to make that move. My point in the end I think is that if you can scratch the itches without *requiring* newer versions of anything, I think that would be ideal. For those things that absolutely can't be done without newer versions, I'd like to see those new features optional or swappable in some way. I don't believe it is possible to scratch the itches without *requiring* newer versions of anything. Choosing a newer version of servlet or JSP apis is buying in to the ability to do the fundamental architecture of Struts in a new and different way. That's not the kind of thing you do with optional add on packages that have extra requirements. Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies www.omnytex.com Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Fri, 3 Sep 2004 01:10:43 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: I agree with what Vic said in this thread on the Servlet Spec issue - if we can take the Servlet version out of the equation so that any version can be plugged in to the core controller than that would be really good. We have that already, right? Struts runs on Servlet 2.2 / 2.3 / 2.4 platforms today. What you can't do is a fundamental redesign of a controller architecture that depends on 2.4 features and craft it in such a way that it's an optional add-on feature that can be plugged in on top of 2.2 or 2.3. Adding something like filters that work on a RequestDispatcher call cannot be added at the application level -- they have to be done by the container. Unless, of course, you plan on re-inventing what RequestDispatcher and Filter do ... but that seems like a monumental waste of time. The JDK thing is a different issue though - it could be developed with compatibility to existing JDK versions and keep everyone happy. I have no technical reasons, but I would like to go to JDK 1.5 simply for the reason that it scratches my itch to play with the latest stuff and hopefully produce simpler, cleaner code with the new features it provides. Standard JDK 5.0 annotations cannot be used (inside of Struts) if you want to work on prior JDKs. Neither can generics. Or autoboxing. Or (insert-your-favorite-new-feature-here) ... Without all of that, what's the point again? :-) Niall Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 31021] - *old* URI for the *.tlds (including for contrib/ (faces el))
On 3 Sep 2004 01:38:30 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31021. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31021 *old* URI for the *.tlds (including for contrib/ (faces el)) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-03 01:38 --- Hal, Thanks for the patch - I've applied it with a slight modification and I've also changed the struts-el build script to do the same. Awesome job Hal! Craig indicated on the dev list that this wasn't required for the struts faces tld (probably because it hasn't been *released*) so I'm closing this bug. I'll add a note to the README.txt for struts-faces though. Niall Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Move minimum to 2.3 (was Re: Changing how CommonsMultipartRequestHandler handles text parameters?)
On Fri, 3 Sep 2004 06:29:59 -0700 (PDT), David Graham [EMAIL PROTECTED] wrote: snip Either it could be developed with compatibility to existing JDK versions and keep everyone happy. or go with JDK 1.5 and my preferernce would be to go to JDK 1.5 and use all those favorite-new-features. In the past we have required the Java version that the Servlet spec required. Why would we want to require 1.5 when Servlet 2.4 requires 1.4? IMO, it's simpler and more consistent to follow the Servlet spec with regards to Java version. It would be easier to be consistent with the specs if *they* were consistent :-). Servlet 2.4 and JSP 2.0 require JDK 1.4 if you're in a J2EE 1.4 container (indirectly, because it's the J2EE spec that says this). For standalone web containers, the minimum platform is JDK 1.3. It's not just open source projects that have spirited discussions about when to switch :-). David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion?
On Fri, 03 Sep 2004 15:31:04 -0400, Don Brown [EMAIL PROTECTED] wrote: Last I heard, Ted setup a test subversion repository and everyone seemed happy with it. Is there anything stopping plans to go ahead and migrate our CVS repository? That's a MME (merely a matter of effort :-) task. I've played with the SVN repository, and it is very nice ... especially how easy it is to move subdirectory trees around. I've recently setup several subversion installations and am willing to do whatever it takes to get Struts migrated. Let me know if this is still desired and what I can do to help. That would be great. The next step would be a vote here on formally moving (which you could easily initiate), followed by communication with the infrastructure team ([EMAIL PROTECTED]) to actually get the conversion done. They will typically: * Mark the CVS repository as read-only * Migrate the data, including the CVS history * Ask us to confirm that it works * Archive the CVS stuff And we'd need to then update all our web site stuff (and nightly build scripts, and so on). The only reason we might want to wait is to talk more about what the new repository structure should be ... but I think that it's so easy to reorganize an SVN repository after the fact that we should not wait. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Migrate Struts to Subversion
On Fri, 03 Sep 2004 16:23:57 -0400, Don Brown [EMAIL PROTECTED] wrote: I propose we migrate our current CVS repository to Subversion as soon as the infrastructure team is available to assist, giving at least a week to ensure all outstanding CVS commits are made. A test Subversion migration has already been created and tested with positive feedback. This proposal does not necessarily require a decision on the future directory organization of the Struts source code as it is very easy to move/add/delete directories with Subversion. The tool cvs2svn - http://cvs2svn.tigris.org/ - will be used to preserve all CVS history, tag, and branch information. +1 Craig I am willing to be the POC for the migration and handle all communications with the infrastructure team. Subversion: http://subversion.tigris.org Subversion guide for CVS users: http://svnbook.red-bean.com/svnbook/apa.html 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: RFC: BLOBAction and Struts Bloat
Thanks for your comments, Michael. If you've been following the dev list lately, you've seen some beginning discussions on a Struts 2.0 rearchitecting that would indeed leverage everything we've all learned in the four years since Struts was first created. I have some specific proposals to make in this regard, which I'll be sharing when I return from an extended trip next week. That being said, one of the factors that has made Struts so popular is a commitment to take care of existing users. It would be somewhat irresponsible for us to completely stopping development of the Struts 1.x architecture, or just doing bug fixes. Therefore, we need to do a 1.3 release in the interim time period, focused on a small number of changes, such as: * Changing base API platform to Servlet 2.3 and JSP 1.2, so Struts apps can count on things like filters and event listeners. * Refactoring the RequestProcessor class to use Commons Chain (based on the code in the contrib/struts-chain) that supports the 1.2 request processing lifecycle semantics, but is more easily customized than the current architecture. You'll also be able to use the Chain paradigm for your own business logic if you like. * Provide a second request processor implementation chain that operates in a portlet (JSR-168) environment. * Split the Struts monolithic release into separate releases of the core framework, the tag libraries, the examples, and so on. This will help us accelerate the turnaround of releases. In the near future, you'll also see the initial release candidate of the Struts-Faces integration library (packaged separately from the rest of Struts) that allows JavaServer Faces to be used with Struts 1.1 or 1.2 based applications, including the use of the Tiles Framework and the Validator Framework. Note that I do *not* see any of the developers interested in continuing the development of the Struts HTML tag libraries, as other view tier choices (like JSF) are becoming available. Craig PS: With regards to migrating to SVN (commented on in one of the replies), doing both 1.3 and 2.0 together on SVN will be vastly more productive than using CVS for 1.3 and SVN for 2.0. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Questions about contributing a CVS patch
It is certainly feasible to do either, but I think you're making the right call on adding explanation about your patches in the bug report. Assume that committer who reviews a bug report will certainly read the entire set of comments on that particular report; but it's less likely that they will also scan the mailing lists for comments on that bug. Writing to the developer list, on the other hand, is perfect for nagging us into paying attention to your bug report :-). Craig On Wed, 22 Sep 2004 18:08:52 -0400, Sean Schofield [EMAIL PROTECTED] wrote: I have submitted two patches for a bug (#31230). Should I limit my conversations about the patch to the bugzilla commentary (which also makes it to the dev mailing list) or is appropriate to email the list as well? Also, how will I know if and when the patch was accepted and run? I'm going to update the bug entry with an explanation of what my patch is doing because I feel this is probably the most appropriate place. Also, please note that the two patches I submitted address only 2 of the 3 classes using deprecated code, so the bug should remain open. Thanks, sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Wiki Etiquette: Niall's Help
On Fri, 24 Sep 2004 11:37:00 -0700, Martin Cooper [EMAIL PROTECTED] wrote: You should realise that no wiki page is owned by any one person more than any other, regardless of who creates it. Once created, it is community owned, and any member of the community is free to add their changes in whatever form they feel appropriate. If you want to control the content and format of the page, as it appears that you do, then the wiki is the wrong place for that. Instead, you should put your content up on a web site that is under your control. Of course, you are free, then, to add a link to that web site from the wiki. -- Martin Cooper +1. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why not extend struts to support access control?
On Sun, 26 Sep 2004 05:07:32 +, liu ji [EMAIL PROTECTED] wrote: Thank you. I know filter can do this very well.But filter have some drawbacks.I don't know how to express this,because of my poor English. Without struts,I can use a single filter to delegate the request to my access control framework.I have already done this. But when using struts,there will be some redundancies. And I think struts should provide this. May a access control framework which doesn't denpend on struts is more attractive. I want this kind framework. Do you know where can I find one? My personal preference is to use container managed security where possible with Struts based applications, for which purpose Struts aready provides some levels of integration: * The role attribute on action, which limits who can execute an action * The role attribute on logic:present so you can conditionally display nested content based on the user having the correct role. When container managed security is insufficient, I like SecurityFilter (http://sourceforge.net/projects/securityfilter/). One particular reason I like this is that the implementation *simulates* container managed security, so the Struts based support for role checking still works. This will also be true for any other filter-based solution that does the same thing (providing a wrapped servlet request object such that getRemoteName, getUserPrincipal, and isUserInRole provide the required data). You don't need anything extra in Struts for this purpose. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion Refactoring Frenzy and Maven Questions
On Sun, 10 Oct 2004 08:29:20 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Sat, 09 Oct 2004 21:06:44 -0700, Craig McClanahan wrote: ... Interestingly, this subproject has four subsubprojects ... Are you counting the MailReader database as a separate artifact? I hadn't been, and that actually makes sense ... it's used by two of the artifacts that I *did* count (both the non-Tiles and Tiles versions of mailreader). We also use it for the conventional Struts example, and it might be best if it were a separate entity that could shared by the various examples. Yep ... even the form beans and actions of mailreader are likely to be abstractable into something separate if we wanted to. For the sake of continuity, I had also started to use the MailReader as an example for using Commons Chain as an web application platform. One of my comrades on Team iBATIS, Larry Meadors, has also done a iBATIS version of MailReader. If there were a MailReaderDatabase subproject, we might be able to get him to donate the code, so there would be both XML and JDBC implementations of the MailReader DAOs. Splitting out the database part of mailreader seems like an obvious first step. How about a top level examples directory with a mailreader-database subdirectory to contain this artifact? If the business logic turns out to be reusable too, that could go in a parallel mailreader-actions subdirectory. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon
Unfortunately, I had scheduling conflicts so I'm going to miss this one :-(. Craig On Wed, 13 Oct 2004 13:20:56 -0700, Don Brown [EMAIL PROTECTED] wrote: Any Struts committers planning on attending ApacheCon? If so, how about the Hackathon? I'll be there and am anxious to have lively discussions over these roadmap ideas being brought up. 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: CVS - SVN
On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want to work on), and less on whether there are parallel development efforts going on. The reason I ask is because I would love releases much, much more often, but as have been pointed out, incompatibilities/quirks between minor versions could be a disaster. Historically, I'd say our 1.0 - 1.1 transition was, in terms of interoperability and upgrade, a bit on the edge of what most users liked, while the 1.1 - 1.2 transition was much easier to do. We haven't actually gotten around to many x.y.z releases on 1.0 or 1.1, so having them happen at all in 1.2 should be a refreshing change :-). But I agree with you that compatibility is especially important within an x.y release cycle. \Anders Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon
The hackathon is typically a conference room at the hotel where ApacheCon will be held, and offers an opportunity for committers on the various Apache projects to get together and hack on code face to face, or otherwise get to know each other better. Historically it's been held on the Saturday and Sunday before the conference (which starts on a Monday). Craig On Wed, 13 Oct 2004 21:08:40 -0700, Martin Cooper [EMAIL PROTECTED] wrote: I'm hoping to be at ApacheCon for the first time this year, and still trying to figure out what the Hackathon is all about. ;-) -- Martin Cooper On Wed, 13 Oct 2004 13:20:56 -0700, Don Brown [EMAIL PROTECTED] wrote: Any Struts committers planning on attending ApacheCon? If so, how about the Hackathon? I'll be there and am anxious to have lively discussions over these roadmap ideas being brought up. 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: CVS - SVN / Roadmap
If you just refer to build.xml the docs should apply to a branch as well as they apply to the trunk. But it's worth mentioning trunk in the context of what URL you use to check out the repository in the first place. Craig On Thu, 14 Oct 2004 12:23:42 -0700, Don Brown [EMAIL PROTECTED] wrote: I don't mind making those CVS to SVN documentation updates today. One question though, are we assuming people checked Struts trunk out or the entire Struts repository? This affects whether we refer to a file as trunk/build.xml or just build.xml. Don Martin Cooper wrote: On Thu, 14 Oct 2004 14:46:43 -0400, James Mitchell [EMAIL PROTECTED] wrote: Are we not waiting for Ted's update? I haven't seen any commits come across and I assumed he would do it this weekendis this still true Ted? Yes, we should wait for Ted's updates. We do need to get the docs switched over to talk about SVN rather than CVS. -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Don Brown [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 14, 2004 1:49 PM Subject: Re: CVS - SVN / Roadmap Deal. Roll it James :) I'll integrate struts-chain and bring over struts-flow and struts-bsf as soon James cuts the release and creates the 1.2.x branch. Don Martin Cooper wrote: On Thu, 14 Oct 2004 08:30:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Ted Husted wrote: +1 Let's stick to the roadmap we laid out in July. http://struts.apache.org/roadmap.html I'll update the site to reflect the CVS/SVN changes this weekend and bring the roadmap page up to date. If James is up for rolling a 1.2.5 release, that's fine with me. Either way, it may be time to call 1.2.x a branch and dub the head 1.3.x, and bring down that-there Struts Chain gizmo. :) +1 I vote we (or perhaps I specifically) integrate struts-chain this weekend. It is stable, and I've been using it in production for some time without problems. Course that also means we (again, perhaps I specifically) should release commons-chain 1.0. Ted, there are a few Guinnesses in it if you help me with the documentation :) How about we roll 1.2.5 first, to capture the latest stuff in a 1.2.x build, then create a 1.2.x branch at that tag, and then roll in the chain stuff as the first step on the 1.3.x ladder? -- Martin Cooper And if Don wants to start setting up struts-flow and struts-scripting along the same lines as struts-faces, I'll buy him a Guiness (or three) at ApacheCon :) Ah, Guinness - the ultimate currency. You got yourself a deal. Don -Ted. On Wed, 13 Oct 2004 13:45:58 -0700, Craig McClanahan wrote: On Wed, 13 Oct 2004 22:23:32 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: Forgive my possible ignorance, but what is the policy on new releases? I've understood that we can release whenever we want, that version numbers are cheap and that you vote whether to make a release alpha/beta/GA. But, what goes into a release? Does new features/enhancements go into a 1.2.x release, or is it strictly bug fixes? What we've talked about before is along these lines: Within the 1.2.x series, it's fine to fix bugs and add new stuff, but not fine to make any backwards-incompatible changes. For a 1.3.x series, we could be more liberal about adding new stuff, and possibly have some deprecations in 1.2.x that get removed -- but it shoujld in general be based on similar enough architectural principles that there be a clear upgrade path. The challenge, of course, is when do you make that split for the evolutionary path? I'd say that something as fundamental as using Struts Chain instead of the monolithic RequestProcessor, and the other changes we could make as a result of having that, would be good grounds for a 1.3.x series. If that were to start in the short term, then thinking of 1.2.x as being in maintenance mode seems likely (although if there's willingness to port features back and forth, it need not go that way immediately ... for example, Tomcat 4.1.x continued to develop for a little while at the beginning of 5.0.x, including some features ported back and forth, but this pretty much stopped as soon as there was a solid 5.0.x release for people to use). For a 2.x chain, we could have the freedom to be somewhat more aggressive at rearchitecting (if we'd known then what we know now, what would Struts have looked like?), and could in theory have a series of alpha releases in parallel with stable releases on 1.2 or 1.3. As others have pointed out, how much simultanaeity there is, and how often releases happen, is more based on the directed energy of the committers (and what they want
Re: struts-faces maven build
Just starting to play with the proposed patch now, but to answer your question ... On Fri, 15 Oct 2004 07:17:35 -0700, Ben Anderson [EMAIL PROTECTED] wrote: One other thing - I finally got example1 working, but I had to add validator-rules.xml, which was absent. This needs to be there, correct? I don't see it in svn. It doesn't need to be in svn for the example app itself, because it's copied from the lib directory of your Struts distribution, along with all the TLD files, in the static target of build.xml. The myfaces-specific variants are going to have more of the same sort of thing, because it requires some additional libraries not required by the JSF RI. Thanks, Ben Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.2.5 Release
On Sun, 17 Oct 2004 04:15:02 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: I realise that people are keen to get on with a release, but it would be my preference if we could delay to include the above. The other way to think about it is to aim these changes and new features at a 1.2.6 release ... in particular, picking up the fileupload patches will require a new release of [fileupload] if we ever wanted to vote a 1.2.5 that included it as GA quality; that process takes (as we've seen) days and not hours to complete. LazyDynaBeans are definitely cool, though. Niall Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
On Mon, 27 Sep 2004 21:40:45 -0700, Don Brown [EMAIL PROTECTED] wrote: If there aren't any objections, I will ask infrastructure to perform the actual conversion of Struts from CVS to Subversion. The test conversion has been up for over a week, and there haven't been any problems. Again, if I don't hear different, I'll ask around Wednesday afternoon for our repository to be converted at infrastructure's earliest convenience. Speak now or forever hold your peace :) So, are we planning to keep all the existing tags and branches, or do selective pruning? Unless the SVN equivalent of cvs log maintains the entire history on all affected files, I'm -1 on pruning anything unless the infrastructure team says we're being too demanding on disk space. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] CVS to Subversion Conversion Wednesday
On Mon, 27 Sep 2004 22:10:38 -0700, Don Brown [EMAIL PROTECTED] wrote: Sorry, I should have clarified, I'm giving the go-ahead on performing the actual conversion the exactly same way the test conversion was done - the full conversion. All branches and tags will be converted. After the conversion, we can delete/move as necessary. Ah, so ... in that case +1. As Martin suggests, I presume we'll want to freeze the CVS version of the repository at the start of the process. Don Craig (who is also updating all his local copies of the CVS repository :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coming out for JSF + Struts
You cannot *imagine* how many people have asked me to clarify this relationship :-). I hope this blog entry helps, but (as I noted) the future of Struts is decided here, not by anything I, or anyone else, might opine elsewhere. Craig On Tue, 28 Sep 2004 22:15:57 -0400, Thomas L Roche [EMAIL PROTECTED] wrote: Tom Roche Sun, 21 Mar 2004 13:49:45 -0500 summary: McClanahan should clearly state *in some major publication* OK, mebbe it'll get cited in some major publication :-) * that JSF does/will not replace Struts * how JSF and Struts will likely tend to specialize, in future * how probable specializations will complement (and compete) in webapp development Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 I think either of us would rather be developing Struts than evangelizing Struts. Tom Roche Mon, 22 Mar 2004 08:00:00 -0500 This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. So I am pleased to note: http://blogs.sun.com/roller/page/craigmcc/20040927#struts_or_jsf_struts_and It should be clear by now that there is overlap between Struts and JSF, particularly in the view tier. Over time, JSF will continue to evolve in the view tier area, and I'm going to be encouraging the Struts community to focus on value adds in the controller and model tiers. Now I can whack the locals who say Struts? Isn't that what Faces replaces? :-) Thanks, Tom hoping to tool for Tiles this rev, at last Roche - 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: Downloading Applications and Struts
On Wed, 29 Sep 2004 00:07:06 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: You are referring to Martin's DownloadAction I believe... Note that he didn't place it in the action package, he placed it in the actions package. It's a subtle difference, but an important one. As I understand it, the action package are the core classes and interfaces of Struts, while the actions package are specific subclasses of those core elements. The distinction you are drawing is indeed correct, and significant. However ... I don't think downloading a file is quite as complex as uploading one, unless you want to grab a BLOB field from a database or something along those lines, but that's the beauty IMHO of Martin's contribution... It's a very easy matter to make use of the underlying concept in any which way you want, as my contributed sample app does. The proposed example is a good first step, but the hard part of building a framework, as opposed to an application, is figuring out where to define the extension points. An example issue relevant to the current proposal -- what if I want to load my data from somewhere other than a database? If's fine to generalize the names of the tables and columns, but an extensible framework for building download-some-recorded-data portions of an application will probably need to define some interface that includes ways to abstract where the data comes from, what the output content type should be, how to determine the content length, whether (and how) to create a Content-Disposition header, and a myriad of other details. The debate about what constitutes bloat in any framework is a difficult one, as is the debate about what makes sense as part of the framework and what is just a clever usage of it. In my mind, a framework should be as lightweight as possible BUT should provide as much common functionality out-of-the-box as possible. Where you draw the lines demarking all these different concerns is difficult to be sure. In simplest terms, if it doesn't add required work for a developer and doesn't impact performance or server load if a particular piece of the framework is not utilized, I don't really consider it bloat, assuming the functionality in question does fulfill a commonly-needed function. Certainly we can agree that downloading files is a common enough activity? I would suggest that downloading *static* content (from a file on the server) is something that a web server, or a servlet container, already takes care of -- it doesn't need any extra support from a framework like Struts. The window of opportunity is around static data that is stored in a fashion not supported by the default functionality of the server on which the application is running. Of course, one could also argue that serving static content doesn't need an app framework at all -- it can be implemented (for example) by a standalone servlet that is totally unaware of Struts. That is also a reasonable position; one would have to articulate why this functionality needs to be incorporated into the controller for the user interactions. Such arguments can be made, but I don't think they are going to be universally applicatabe. Look at it this way... If someone adds something to Struts that fulfills a need that comes up commonly, you could rightly call that addition a pattern. We don't consider pattern-based development bloat anywhere else, why would we here? Having common implementations of patterns included in Struts makes it easier for a developer, makes it more of a one-stop shopping proposition. I would agree you have to be careful in what you add because it IS easy to add things that probably shouldn't be, but that decision is never an easy one I suspect. I agree with you that the o.a.s.actions package is built *on top of* the framework, instead of *being* the framework. However, the proposed code doesn't strike me as sufficiently general, yet, for inclusion -- perhaps we could look more at defining the general problem of how can we create an abstraction for a response that might be acquired from some resource, instead of being dynamically created by the execution of a JSP page. In the purest sense, the fact that you can return null from an Action (indicating that the response has already been created) means that Struts itself doesn't need anything extra. That being said, a design pattern standard action, equally at home with data extracted from a database, a directory server, an XSLT transformation, static files, web services calls, a return from an EJB, or execution of some method on a JavaBean, ... would be more appropriate for inclusion in Struts itself. Such an approach (defining a Provider interface of some sort) would also enable the use of any of the currently popular IoC frameworks to provide an appropriate implementation, instead of burying all the functionality for JDBC access directly in the proposed Action itself. Is it feasibe to
Re: Opening it up for debate...
On Thu, 30 Sep 2004 20:08:36 -0400, Frank W. Zammetti [EMAIL PROTECTED] wrote: Ah, I didn't know about the saveErrors method. That completely invalidates my entire concern. Thank you! I figured I was either on to something or was about to learn something, and I kinda figured it would be the later :) BTW, this is also the approach that the standard Struts example application (struts-example) uses to deal with this scenario. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN keywords (was Re: svn commit: rev 51787 - struts/trunk/conf/share)
I'm +1 for $Id$. Craig On Sat, 2 Oct 2004 11:21:59 -0700, Martin Cooper [EMAIL PROTECTED] wrote: It looks like we'll need to change the keywords, since SVN uses a different set. ;-( The SVN keywords are documented here: http://svnbook.red-bean.com/svnbook-1.1/ch07s02.html#svn-ch-7-sect-2.3.4 I would suggest that we drop all of what we are using now (Header, Revision and Date) and simply use Id, which is a compressed combination of the other keywords. As fas as I can tell, it's essentially the same as Id on CVS, which is what I tend to use when the choice is up to me. But let's make sure we agree before making sweeping changes! ;-) -- Martin Cooper On Sat, 2 Oct 2004 08:34:50 -0400, James Mitchell [EMAIL PROTECTED] wrote: So, what's up with key word expansion? My change to that file, was to add a space, remove it, then save it. On commit I see that $Date$ was changed, and locally it was expanded correctly, but 'Header' and 'Revision' were not. Is there some svn configuration change we are missing or do we need to change the key words? -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 01, 2004 11:17 PM Subject: svn commit: rev 51787 - struts/trunk/conf/share Author: jmitchell Date: Fri Oct 1 20:17:23 2004 New Revision: 51787 Modified: struts/trunk/conf/share/validator-rules.xml Log: no changes, just testing Modified: struts/trunk/conf/share/validator-rules.xml == --- struts/trunk/conf/share/validator-rules.xml (original) +++ struts/trunk/conf/share/validator-rules.xml Fri Oct 1 20:17:23 2004 @@ -4,7 +4,7 @@ !-- $Header: /home/cvs/jakarta-struts/conf/share/validator-rules.xml,v 1.52 2004/07/25 12:00:20 niallp Exp $ $Revision: 1.52 $ - $Date: 2004/07/25 12:00:20 $ + $Date$ This file contains the default Struts Validator pluggable validator definitions. It should be placed somewhere under /WEB-INF and - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion Refactoring Frenzy and Maven Questions
I've taken advantage of the new capabilities that Subversion provides for refactoring, to set up struts-faces as a top-level subproject with the ability to create its own release artifact. Interestingly, this subproject has four subsubprojects that provide its content as well, so the top-level build.xml is set up to delegate as needed to assemble the entire thing. The directory structure is: $STRUTS_HOME/ struts-faces/ build.xml-- top level build script core-library/ -- subsubproject for the library itself example1-webapp/ -- first sample webapp (non-Tiles) example2-webapp/ -- second sample webapp (Tiles) sysclient-app/ -- system integration test ... client side systest1-webapp/-- system integration test ... server side Each of the subsubprojects has its own build.xml to manage the details. So far, this is all still Ant based. While contemplating how we might use Maven for it, I've got some questions I hope the Maven gurus can address: * My understanding is that Maven is easiest to use on projects that create a single artifact ... but I need to assemble that artifact from several subordinate artifacts. So, I guess we'll need some sort of multi-target support? * The Ant scripts still use build.properties files for an important reason: I need to be able to substitute alternative solutions for the dependencies: - Struts itself (1.1, 1.2, or trunk) - JSF implementation (RI or MyFaces) How can I do that with Maven? * The build scripts utilize Ant's filtering tasks to modify the web.xml files based on which JSF implementation is used (as well as conditionally include some extra libraries that MyFaces needs but the JSF RI doesn't). How can I do that with Maven? * As the scripts work now, they include the source code in the same distribution as the binaries, so there's only one file for the user to download. I'm OK with doing them separately, but it would be nice if Maven supported this style as well. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: building struts question
The Maven-based build scripts are still under development. The official method to build struts is still Ant. You'll need to configure a build.properties file that points at where you've downloaded and installed the dependencies -- see build.properties.sample for a sample of what will be needed. Craig On Mon, 18 Oct 2004 17:21:25 +0800, Christopher Lim [EMAIL PROTECTED] wrote: Just checked out struts source code from subversion and issued maven got the following errors: BUILD FAILED File.. C:\Projects\OpenSource\struts\maven.xml Element... ant:style Line.. 29 Column 28 Provider org.apache.xalan.processor.TransformerFactoryImpl not found Total time: 3 seconds Finished at: Mon Oct 18 17:19:58 CST 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
+1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community if the developers / PMC haven't sanctioned it by a vote. I think ultimately we agree even more than I realized, since, looking back at how you describe these events, I realize that my main concern - version number confusion - is not at issue. I simply think of anything with a version number as a release. I'm happy to change that and to describe the first output of the release process as a test build instead of an alpha release. In fact, I'd be +1 to that, given that we have two cases in recent memory where the artifact was not really even usable as an alpha release. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
Semantics and terms aside, there is a key difference between the approaches being discussed: (a) In the HTTPD way, the release manager can post a release (prejudged to be alpha quality) with a formal version number, with no vote from the rest of the PMC. (b) In the Tomcat way, the release manager can post a test build (essentially a release *candidate*) that still needs to be voted on to be actually released. Approach (a) seems to be what bothers Martin, and I'm uncomfortable with it as well. It works as long as you don't have any RMs with delusions of grandeur, trying to be dictatorial about where a project heads -- we haven't had that problem, but why make it possible? Approach (b) requires a positive action on the part of the PMC to do anything more than a test build, and gives the community of users a sense that we're all behind this release. Terminology isn't the important part to me -- voting is. That's why I prefer approach (b). Craig On Tue, 19 Oct 2004 04:32:30 -0400, Ted Husted [EMAIL PROTECTED] wrote: A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. The Apache HTTPD team prejudges their builds as Alpha. http://httpd.apache.org/dev/release.html Each of us vote when a commit is made, even if it is a lazy vote. AFAIK, the ASF Board has never, ever defined what does and does not require a vote. They've delegated that decision to the Struts Vice President and PMC. Something requires a vote if we say it requires a vote. Likewise for not requiring a vote. IMHO, people are applying shades of meaning to the words release, build, and distribution, that are unintended by the Foundation and elude our users. The operative words are automated or nightly and Alpha, Beta, and General Release. There is no point in reinventing terminology that other teams -- well experienced in the art and science of creating releases -- have already clearly defined. Again, here's my +1 for adopting the HTTPD release protocol, with the one modification of using the term Alpha build in lieu of Alpha release. -Ted. On Mon, 18 Oct 2004 22:59:48 -0700, Martin Cooper wrote: On Mon, 18 Oct 2004 18:39:43 -0500, Eddie Bush [EMAIL PROTECTED] wrote: When you say test build, do you mean alpha release? The two terms are synonymous in my mind, so voting on an alpha isn't something I'd ever think of as that's what I view the nightly builds to be. A release requires a vote, whereas a build does not. Also, referring to a test build as alpha is prejudging the quality of the build; it could be better than that, or it could be worse, and IMNSHO it reflects badly on us if we first claim it's alpha and later are seen to change our minds about that, whichever way the change goes. I do believe we should be voting on Beta and up though. Beta should (hopefully) be bug-free -- a build we anticipate to be the major release. Perhaps my thinking is flawed :-) Have you ever experienced bug-free beta software? For that matter, have you ever experienced bug-free software at all? ;-) -- Martin Cooper - Original Message - From: Craig McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, October 18, 2004 2:25 PM Subject: Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta)) +1 on the test build then vote to rank approach that Tomcat uses. As an additional clarification, I presume that we will want the same release process for any subproject releases? This is becoming timely as the opportunity for a 1.0.1 release of struts-faces draws nigh. It might be worth mentioning this in the release guidelines as well, including the explicit requirement that any release vote involve the entire committer community (with PMC votes binding, as usual) -- not just the developers who might happen to be working on that subproject. After all, the subprojects will still say Struts on them, and we're all going to care about that reputation. Craig On Mon, 18 Oct 2004 14:06:25 -0500, Joe Germuska [EMAIL PROTECTED] wrote: At 10:55 AM -0700 10/18/04, Martin Cooper wrote: The 1.2.1 and 1.2.2 test builds didn't make it to releases. That is as it should be - we want releases to be quality builds. What I feel very strongly about is that nothing should be called a Release until we vote on it, especially since I believe this is an ASF requirement. We have said that anyone can build a Test Build (e.g. 1.2.x) at any time, and that's fine. But I don't want to see such a build viewed as a Release by the community
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 22:39:44 -0700, Martin Cooper [EMAIL PROTECTED] wrote: On Wed, 20 Oct 2004 01:28:29 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 19 Oct 2004 20:47:56 -0700, Martin Cooper wrote: When we first started discussing changes to the way we build and release Struts, the model that was proposed was the Tomcat model, and that is still the model I would like to see us follow, terminology and all. I believe the initial suggestion, way back when, was to use the HTTPD protocol, which people then mentioned was like the Tomcat protocol. I don't believe that's correct. Craig brought up the topic, from his experience with Tomcat, and specifically suggested that we do things the way Tomcat was doing them. I did indeed propose the Tomcat model, or at least the Tomcat model that I understood to be working at the time. More recently, it looks like there's an informal step of tacit agreement on the dev list that a new release should be created, with an implicit alpha quality rating. I don't care if we go with implicit alpha ratings versus no rating at all -- indeed that probably makes more sense. I do care if, for example, I can go create a Struts-Faces Integration Library 1.0.1 release (even if it's labelled as alpha quality) with zero input from the other committers. That doesn't seem like something we want to encourage. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt HTTP Release Guidelines (was Re: [Announce] Release of Struts 1.2.5 (beta))
On Tue, 19 Oct 2004 22:38:15 -0700, Martin Cooper [EMAIL PROTECTED] wrote: (BTW, I'm more than a little surprised at the amount of energy you're putting into this, Ted, given that you've told us all you're going Emeritus anyway, so that those of us remaining will be the folks rolling the releases. ;) Shh!!! Don't let him think that's still an option!!! :-) Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF and Tiles Solution
I'd definitely like to see the code. Craig On Thu, 21 Oct 2004 10:07:25 -0400, Sean Schofield [EMAIL PROTECTED] wrote: [follow-up to a discussion from the user list] I think I have a potential solution to a problem I've been having trying to integrate JSF and Tiles. At first I tried integrating JSF and Tiles without the struts-faces package (since I wasn't concerned with having Actions talk to faces, etc.) If you are just relying on Tiles for layout and using faces for everything else, you are left with a single problem. The problem is that the form generated by JSF will try to post to the layout page instead of whatever the original URL was that triggered Tiles. I came up with something that will fix this and depends on using only one (modified) class from struts-faces. The catch is that it requires struts-chain. Actually, it can probably be done without struts-chain, but struts-chain makes it easier to plug-in whatever functionality is needed. In the end, I envision it to be possible to integrate struts and faces to varying degrees depending on what functionality you need. What I did was to add a new command, TilesFacesPreProcessor (TFPP), just before the TilesPreProcessor command. TFPP checks to see if a certain attribute is present in the request. If that attribute is null, it adds that attribute to the request with a value of the URI of the request (minus the leading / char). This way we have a record of the original URI. It only does this if the attribute is null in case one of your Tiles inserts is itself a struts request. The other part of the solution is to modify the ViewHandlerImpl in the struts-faces package. I overrode the getActionURL method and had it check for the value in the request. If there was a value there, I return that as the actionURL, otherwise, I pass the request on to the decorated ViewHandler. I can submit some code for people to look at, but first I wanted to get a sense of what people thought about this idea. It's the best I could come up with. Let me know what you think, sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XHTML Form Tag
On Sun, 24 Oct 2004 21:57:20 -0500, Eddie Bush [EMAIL PROTECTED] wrote:
Hola Amigos!
AFAICT this is an issue only in the html:form tag. If we were to introduce
something to trigger XHTML 1.1, couldn't we just lie to validator about the name
by telling it the ID instead of the name? Would the resulting syntax emitted by
validator still be ok?
If you look at the static Javascript methods produced by Commons
Validator, you'll note the following code in each of the validation
methods (using just one of them for an example):
function validateFloatRange(form) {
...
var formName = form.getAttributeNode(name);
...
}
In other words, the validators all assume that they can acquire the
name of the form (which is then used to look up the appropriate
validation rules) based on the name attribute of the form element
that is passed in as an argument. This value is used to dynamically
calculate the name of a dynamic JavaScript function that implements
the specific tests for this particular form (which is part of the code
generated when you say html:javascript dynamic=true/).
Without a change to the validator code itself, then, the only way to
lie to it would be to have some sort of JavaScript that dynamically
added the expected form name as the name attribute of the form
element at runtime, perhaps in an onload handler on the body
element. That would be such an egregious hack that I would not
support it.
If we want the validator to work with XHTML 1 1, instead of XHTML 1.0
Transitional, we've got a bit of work to do. I suspect there is more
to it than just the name attribute on a form element (although
IMHO the XHTML spec did the world no favors when they dumped name on
the form element but kept it on the input elements -- that's just
grounds for confusion).
Perhaps we should force XHTML 1.1 if html:html xhtml=true ... or html:xhtml/?
That seems kind of pushy to me though. Maybe in 2.0. For now, perhaps enable some
sort of flag (html:xhtml version=1.1/) to allow XHTML 1.1? We could poke it in
pre-deprecated with note that it's going away in 2.0.
As far as I'm concerned, the HTML tags as a whole aren't going to be
part of 2.0 -- there are substantially better options (my proposal on
that topic is coming very soon). But that die has yet to be cast by
the consensus of the developers.
In the mean time, we should explore a solution to this on the 1.x path
that does the right thing, instead of a hack. I think it's reasonable
to aim for XHTML/1.1 (or XHTML/1.0 Strict) output being a viable
option.
Anyhoo ... the Form tag could then check to see if it should emit XHTML (which it
already does) and which version. If it's being asked to be 1.1 compliant, it could
lie and render 'name=name' as 'id=name'.
That's the *easy* part of the problem :-). But yes, one could
certainly make the form tag smarter about what it emits based on which
version of XHTML you want.
What do you all think? I'm listening ...
If the validator would require a change, I think I might be up for fixing that as
well. It's pretty well written, so I don't see modification being too large an
issue. Yes, I'm aware it probably needs to stay backward-compatible, but I think I
might can strategize a way to accomplish that. I'd love to hear potential hurdles
you all see to accomplishing that though!
I think there'd be a different way to do this, but it's likely to
require a fair bit of surgery. In particular, I do not believe it's
reasonable to require the rendered id attribute of a form element
to contain Struts's notion of a form name -- yet it seems that a lot
of code does depend on being able to use this value to look up the
correct set of validation rules. If it is necessary to communicate
that to the client side, a new strategy is going to be necessary to
provide it (since we can't just add an arbitrary attribute without
violating the DTD).
If I sound a little irked about this, it's because I am ... it turns
out that the generted JavaScript function names for Commons Validator
1.1.3 (included with Struts 1.2.x) are different than the generated
names in the version of Validator that was included in Struts 1.1, and
it cost me more hours than I want to admit to figure out how to make
Struts-Faces support client side validation with both versions.
Eddie
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
Just time for a couple of notes this morning. I'm +0 on JDK 5.0 (nee 1.5) depending on how long we really think this is going to take. The struts core part of this isn't really huge or complicated, but asking a Struts developer for a timeline is probably a silly thing to do :-). Other comments inline. On Tue, 26 Oct 2004 09:42:27 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Mon, 25 Oct 2004 04:56:45 +, [EMAIL PROTECTED] wrote: URL: http://wiki.apache.org/struts/StrutsShale A few more more notes. 2.4 View Controller 3.3 View (Presentation) Tier APIs Proposal:: JavaServer Faces 1.1 Does the View Controller need to be tied to JSF? Could the interface be agnostic and a FacesViewController be provided that is specific to JSF? Or, could there be a [org.apache.shale.faces] package, allowing room for, say, a [org.apache.shale.xlst] package or a [org.apache.shale.jstl] package or a [org.apache.shale.velocity] ? I'm not saying that we would have to provide all of these packages for Shale to be complete. I'd just like to position Struts 2.x so it could be everyone's controller :) -- if there are volunteers ready, willing, and able to make it so. The interface as currently defined is not dependent on JSF, nor need it be for its own purposes. Applications that implement a ViewController can stay *mostly* agnostic of the view tier technology, but you still have to decide at some point: * How do I bind my model data to my user interface components? (With JSF, you use value bindings on the components to properties in your view controller, and/or binding attributes to bind the actual component instances.) * How do I send error messages back to the user interface? (With JSF, you call FacesContext.addMessage().) * How do I initiate page navigation? (With JSF, the string outcome returned by an action method is fed through the page navigation rules you've configured to choose the next page, or null return means stay on the same page). All of those sorts of decisions have predefined answers in JSF, and abstracting them would require building infrastructure (into Struts Core) to bridge that gap into any other view tier technology you want, and/or reinventing a lot of what JSF (the managed beans, page navigation, and so on) already has. That's not an effort I'm interested in actually doing, and IMHO it would needlessly complicate the overall architecture -- but it's technically feasible. 2.5 Functionality Not Included In Struts 2.0 Core Would any view packages be bundled with the 2.x core, or would the core be the Application controller and interfaces for the Dialog and View controllers (and any implementation-independent utilities). My current view is that no view *components* would be included in the core -- although, if we accept the proposal to base the core on JSF for its infrastructure capabilities, we'd need to have a JSF implementation available (even if an alternative view technology was used for the actual presentation). The core would also include preregistration of JSF plugins like a custom ViewHandler that would actually implement the ViewHandler calling-in contracts (but that's invisible to people using it; JSF recognizes META-INF/faces-config.xml files inside a JAR at startup time to add stuff like this). It's clearly reasonable to distribute separate view tier packages, including things like useful components (the way MyFaces does) and/or extra goodies for things like validation. 2.5 Functionality Not Included In Struts 2.0 Core Since client-side validation is mentioned, are we leaving the door open for server-side validation? My current view is that UI validation (as opposed to business rules that might require database lookups, like authenticating a user in a login screen) should be defined in the view tier. Whether it's implemented client side or server side (or both) is an implementation detail. Here's some options (again presuming a choice of JSF): * Standard JSF per-component validators (server side only for the standard components, but smarter components could do client side as well) * Special form tag component that hooks into an externally defined set of rules that enforce the rules both client and server side (this is what struts-faces does to hook into Commons Validator) * Special JSF ActionListener plugin (the part of JSF that receives submit buttons and decides what view controller to load, and what action method to call) that would hook in to the validator framework (this would work with the standard form component too) In none of the cases would the view controller's action method be called if there were validation errors (exactly analogous to how we don't call an Action if errors existed). Perhaps as an abstract link in the request processing chain? The third option above is probably the most elegant, and would certainly lend itself to inserting an arbitrary request processing
Re: Release/Version Notes
I think we want to reward people who are helping us test the non-GA releases as well, by delinieating the dot-dot changes separately. That still gives people who want the whole picture what they need: Changes in version 1.2.6: * ... * ... Changes in version 1.2.5: * ... * ... Changes in version 1.2.4: * ... * ... and so on (the embedded lists can be links if there's too many bullets for one big page). Craig On Tue, 26 Oct 2004 17:30:29 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: This raises another question. Do we want the release notes to be all the changes since the last GA quality release or the changes in this version? I'd prefer all the changes since the last GA quality release as I think thats what users really want to know. If a build doesn't make GA release status then we can just copy it over to the next version of the release notes and delete it. If people agree with that and were just going to push straight on to 1.2.6, then we can skip the 1.2.5 release notes and just set up 1.2.6 ones Niall - Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 4:35 PM Subject: Re: Release/Version Notes On Tue, 26 Oct 2004 11:12:51 -0400, James Mitchell wrote: It was my impression that Ted would update the release notes and I was simply putting some of the other pieces together. I am still a newbie to the release process so please be kind. I did mean to, James, but I just didn't get to it in time :( If I had, I would have just restarted the release-notes.xml page, since 1.2.4 was a GA release. But I like Nial's suggestion better :) I would be happy to do the notes for 1.2.5, in the manner Nial described. Then maybe the best thing would be to move onto 1.2.6, since there have been some patches applied, and there might be a few more yet this week. I'd also be happy to document whatever problem tickets we don't resolve, if that would help. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Tue, 26 Oct 2004 11:48:33 -0700, Michael McGrady [EMAIL PROTECTED] wrote: Niall Pemberton wrote: OK Craig didn't say it was JSF only - but that was my interpretation of the likely direction. He said The interface as currently defined is not dependent on JSF but then went on to say that JSF already solves a whole load of the view tier issues and re-inventing them outside JSF is ...not an effort I'm interested in actually doing, and IMHO it would needlessly complicate the overall architecture -- but it's technically feasible. Niall My understanding is that the interfaces will be optimized to a JSF emphasis but amenable to and sensitive to any other options nuts like myself might want to code. Is that right, Craig? Let's look at this from a variety of perspectives: * The proposed Struts Core doesn't contain or use any JSF components -- it presumes the use of the infrastructure stuff (managed beans, expressions, navigation mapping, as well as the basic request processing lifecycle) that is darned useful, and would have to be reinvented by any non-JSF-based implementation anyway. * JSF itself is bound to JSP substantially less than Struts is, even though a JSF implementation is required to support JSP. For example, if you like Tapestry's approach of a separate HTML file containing markup with id attributes that correspond to a component tree, that's a very straightforward thing to implement -- indeed, Hans Bergsten's book gets you about 80% of the way there. Or, if you want to output WML or SVG instead of HTML ... that's nothing the controller need concern itself with -- just pick the correct JSF renderers. * The same thing could be done for any other templating technology that has some way to establish the data bindings (Velocity macros, for example) and is accessible via RequestDispatcher.forward() or a programmatic interface to actually do the rendering. I'd be OK with having a subproject lying around that implemented one or more of these adapters for view tier technologies; I can provide design assistance but not much in the way of development help due to time constraints. * That being said, JSF goes far beyond just using templates, because it provides a sophisticated component model (so you can build things like tree controls and scrollable tables) and an event model optimized for component oriented development. Choosing a templating technology which forces you to give that up seems to me a sub-optimal choice. But it could be done, if we're willing to simulate the controller-level parts of JSF. * Even if the core controller part of Struts was JSF-agnostic (except for an implementation of the APIs based on it), you still can't write an application on top of this without committing to a choice in view tier technology. The more stuff like how validation errors are propogated that we have to abstract in order to be JSF-agnostic, the more complicated we make the architecture; and the more code we have to wrte and fix and document and test. * JSF is going to be part of J2EE 5.0 anyway, so rumors of its imminent demise are not credible :-). * Indeed, Apache is currently incubating an open source implementation (http://incubator.apache.org/projects/myfaces.html) that will, naturally enough, be Apache licensed and suitable for distribution (once it passes the compatibility tests). * Finally, there's a marketing viewpoint :-). The world has changed since Struts was first developed, and there's so many frameworks out there that people get laughed at on TheServerSide etc. for creating YAWAF (yet another web application framework). Without some distinguishing characteristic, what (besides the Struts name) would we bring to the table that all the other non-JSF-specific frameworks already do? My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Michael McGrady Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale and struts-chain
On Wed, 27 Oct 2004 00:20:13 -0400, Thomas L Roche [EMAIL PROTECTED] wrote: Just wondering: how does Shale relate to struts-chain? E.g. * Would Shale subsume struts-chain? It would likely subsume *struts*-chain, but not *commons*-chain (see below). * Is struts-chain for 1.x and Shale for 2.x? Struts-chain is primarily for Struts 1.x, giving us an alternative way to compose the request processor. Shale is a proposal for an overall architecture of Struts 2.x. However, the underlying commons chain functionality makes a reasonable way to express composable chains of behavior -- and can be used at a number of different levels. And, given a well defined configuration file format, chains should be able to support a pretty nice design time experience. * In either architecture, a chain could be used to compose the application logic used to process, say, a form submit. You could compose a chain, for example, that allocated a data source, then did some business logic level validation, then performed the actual transaction. Or, it could go invoke a remote web service, or interact with a BPEL workflow. This kind of chain would be built from small reusable parts that are easily unit tested in isolation. * In Shale, there's likely to be one or more servlet filters involved in providing the functionality slated for the application controller layer. It would be easier to configure (especially if you're creating your web.xml file by hand) to have only one filter for all of Struts, and then use composition to define the steps that take place at the beginning and end of each requst innovation. * In Shale, the same thing could be architected in the implementation of pretty much any event handler where you might want to do more than one thing, allowing applications to add speciaized processing before or after the standard steps. That being said, nothing in Shale's proposed architecture *requires* the use of a chain for this type of thing. It might also be that the required functionality is composed though some IoC container, or a workflow engine, or whatever else you want to use. We're planning the next rev of tooling, so I'm wondering which (moving) target(s) to try to hit, and when ... You're not the only one trying to make that determination :-). However, it's definitely too early to make very many plans around Shale, which still has to make its case with the rest of the Struts developers before it's anything other than a brainstorm. Over the next while, I'll be filling in some of the details with prototype code that should help us make that determination. TIA, Tom Roche, IBM Rational Developer Model2 Tooling Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: rev 55700 - struts/trunk/contrib/struts-shale
FWIW, the Geronimo repository has a snapshot of Servlet 2.4: http://svn.apache.org/repository/geronimo-spec/jars/geronimo-spec-servlet-2.4-SNAPSHOT.jar Craig On 27 Oct 2004 14:43:03 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: germuska Date: Wed Oct 27 07:43:03 2004 New Revision: 55700 Modified: struts/trunk/contrib/struts-shale/project.properties Log: fix expression of value for 'maven.repo.remote' -- why don't any of the repos have servlet-2.4? Modified: struts/trunk/contrib/struts-shale/project.properties == --- struts/trunk/contrib/struts-shale/project.properties(original) +++ struts/trunk/contrib/struts-shale/project.propertiesWed Oct 27 07:43:03 2004 @@ -7,4 +7,4 @@ maven.repo.central.directory=/www/svn.apache.org/repository/ # nightly builds maven.repo.central.directory=/www/www.apache.org/dist/java-repository -maven.repo.remote http://cvs.apache.org/repository/ http://www.ibiblio.org/maven/ http://dist.codehaus.org/ http://www.bluesunrise.com/maven/ +maven.repo.remote=http://cvs.apache.org/repository/,http://www.ibiblio.org/maven/,http://dist.codehaus.org/,http://www.bluesunrise.com/maven/ - 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: [Shale] Day Two
On Wed, 27 Oct 2004 08:07:09 -0400, Ted Husted [EMAIL PROTECTED] wrote: Yesterday, as advertised, the Shale API built without any external dependencies (whatsoever). Today, the new implementations require dependencies on Servlet 2.4, JSF, and Commons Logging. But, I can't get it to build because org.apache.shale.impl.ImplApplicationFilter is not abstract and does not override abstract method isLoggable(java.util.logging.LogRecord) in java.util.logging.Filter public class ImplApplicationFilter implements java.util.logging.Filter As you've probably figured out by now, this class actually implements javax.servlet.Filter, not java.util.logging.Filter ... so you need Servlet 2.4 API classes available. Craig I'm using j2sdk1.4.2_01 (but am about to update to _06). Is there something else that needs to be on the classpath? Meanwhile, I started a projects.xml for Maven, to make it easier for others to jump in and join the fun :) -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: [OT] servlet-api-2.4 on Maven repositories?
Apache does indeed have Apache-licensed versions of the servet 2.4 (and JSP 2.0) API classes. The ones that are shipped with Tomcat 5.x are in cvs repository jakarta-servletapi-5. I would imagine we could just get the Tomcat folks to post those JARs to ibiblio or something. Isn't that just a matter of uploading to some special directory on an Apache server that gets mirrored over (the same way we do the Struts JARs)? You could get the JARs from Sun (by downloading the app server, for example), but they'll come with a redistribution license says you can't piecemeal out the parts -- you can only ship what you downloaded if its unmodified and just a part of your product or package. That won't do us any good for this purpose. Craig On Wed, 27 Oct 2004 12:24:57 -0500, Joe Germuska [EMAIL PROTECTED] wrote: (I sent this before Craig and Ted's notes came back, but it seems to have gone into a black hole, so sending again, since i still have these questions...) This is a bit of a puzzle for me and after a bit of digging, I don't have a great place to pose this question -- so I'll keep it close to home, especially since Craig's past involvement in Tomcat (and employment by Sun) might help me understand. The iBiblio repository doesn't have a Servlet 2.4 final API jar. I thought that the Tomcat project used to distribute binaries of the Servlet APIs, although I didn't see them just now. Is Sun the official place to get the API jars? Are those jars under the more restrictive redistribution licenses, which might explain why they are not on the Apache binary download sites now? Or am I just confused? I'm not sure who I would ask to get the thing uploaded to iBiblio, especially since the Maven project has tried to make the process there much more formalized -- only someone with authority is supposed to make the upload request JIRA ticket, and they are supposed to provide the material which is to be uploaded. Then again, if the Tomcat folks still shepherd the API, then they could just build it to the Apache directory which is mirrored to iBiblio. Craig, or anyone: can you clarify? Joe At 2:43 PM + 10/27/04, [EMAIL PROTECTED] wrote: Author: germuska Date: Wed Oct 27 07:43:03 2004 New Revision: 55700 Modified: struts/trunk/contrib/struts-shale/project.properties Log: fix expression of value for 'maven.repo.remote' -- why don't any of the repos have servlet-2.4? Modified: struts/trunk/contrib/struts-shale/project.properties == --- struts/trunk/contrib/struts-shale/project.properties (original) +++ struts/trunk/contrib/struts-shale/project.properties Wed Oct 27 07:43:03 2004 @@ -7,4 +7,4 @@ maven.repo.central.directory=/www/svn.apache.org/repository/ # nightly builds maven.repo.central.directory=/www/www.apache.org/dist/java-repository -maven.repo.remote http://cvs.apache.org/repository/ http://www.ibiblio.org/maven/ http://dist.codehaus.org/ http://www.bluesunrise.com/maven/ +maven.repo.remote=http://cvs.apache.org/repository/,http://www.ibiblio.org/maven/,http://dist.codehaus.org/,http://www.bluesunrise.com/maven/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale - Itch Proposal
On Wed, 27 Oct 2004 12:01:39 -0700 (PDT), Scott Anderson [EMAIL PROTECTED] wrote: [snip] With this in mind, my proposal for a useful and demonstrative application would be the result of porting/supporting NetBeans' web application development APIs and relevant visual components to a JSR 168 portlet suite built on Struts components and JSF extensions. This suite would form the basis for a hosted IDE and project manager and could also leverage the Web Services for Remote Portlets (WSRP) OASIS standard to provide for project aggregation. I can see this authoring tool/portal being used to generate more focused tools and applications, a WAR factory, that in turn gets used by higher level developers and applied to more specific problem domains. I think this group can pull off something like this. I suspect you're probably correct about capabilities (building an IDE is my day job :-), but building an IDE seems a little aggressive to be a reasonable scope for a demonstration of the use of an application framework. That being said, I wholeheartedly endorse the idea of sample apps (more than one) -- that's the only way to validate whether the theoretical promises of easier development really come true or not. There are a bunch of different scenarios (webapp versus portlet, or database versus web service consumer, for example) that need to be examined, and deserve focused attention. I'd be happy to see such demos either in the Struts repository (for demos involving existing Struts committers) and at the Struts SourceForge project for those who just want to try things out and play. Personally, I'm going to start with our old friend MailReader -- not so much because it's a sophisticated demo, but as a simple entry point for people already familiar with the existing Struts implementation to see how the programming model might change, and also because I'm going to front end it with a system integration test to validate the functionality of the framework as it evolves. More complex scenarios, of course, are also needed -- volunteers are welcome. Scott Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Struts Shale
Oops ... meant to reply to both Jack and the list. Craig -- Forwarded message -- From: Craig McClanahan [EMAIL PROTECTED] Date: Thu, 28 Oct 2004 10:19:48 -0700 Subject: Re: Struts Shale To: Dakota Jack [EMAIL PROTECTED] On Thu, 28 Oct 2004 06:51:32 -0700, Dakota Jack [EMAIL PROTECTED] wrote: How could there be a reason not to do this? (This is not a rhetorical question.) Ted can correct my understanding of his position if I'm wrong, but basically he wants Struts to be view tier agnostic. I'll agree with that on the actual technology used to implement the dynamic rendering (JSF lets you do that already), but not on abstracting the entire request processing lifecycle. JSF already provides a solid foundation on which to build application level controller facilities, and I see no point in re-inventing that part. Jack Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies. Just as one example out of my list from the previous email ... how does a ViewController say I want to switch to a new view? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack [EMAIL PROTECTED] wrote: Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question. Jack On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: My personal itch is to not have to build everything from scratch -- its to build on the JSF request processing lifecycle, without committing you to any particular view tier templating approach. Doing more work than that is ... more work. Granted that Shale will be painful to implement without the support of another framework, like JavaServer Faces, could we still position JSF as one possible implementation of Shale. For example, instead of an impl folder, could we have a faces folder? I don't see the point in doing this now -- if a reasonable non-JSF approach is shown to be viable and accepted by the community we can always do it later. I haven't seen enough yet to make me think this is viable without compromising the simplicity of the current approach. And would it be all right if I reorganized the API JavaDoc for ViewController to distinguish between the abstract responsibilities of the interface and what happens when an ViewController implementation is wired to JSF? Abstracting when the init/prepare/destroy methods are called and what they do would not be that hard, although you're going to need a bunch of things to make ViewController actually usable without presuming JSF: * The notion of a view identifier that maps to both the view tier presentation (typically a JSP page) and the corresponding ViewController class. * A mechanism for performing validations and handling validation error messages. * Some method that gets invoked when, say, a submit button is pressed that triggers your business logic. * A mechanism for a ViewController to request that its own view get redisplayed, or to navigate to a different view id. All of the above are already provided by JSF, but necessary in a non-JSF world. Basically, I'm really curious how you propose to abstract out the Standard JSF processing and event handling is performed part without essentially re-inventing a JSF-like lifecycle. If you try to impose those abstractions onto the basic ViewController API then I would likely be -1 because they are redundant to using the framework *with* JSF. You could create a NonFacesViewController abstraction on top of ViewController if you wanted, but by that point we might as well create two separate frameworks instead of one. -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Struts Shale
On Thu, 28 Oct 2004 14:30:33 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote: ... that we rename the package called impl as faces. As to the impl package: I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes. To me, impl says we're implementing the interfaces for the Shale layer (rather than the Faces layer). Naming this package faces clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API. What I would suggest is that we call the package faces, and the member classes: * ShaleApplicationFilter * ShaleConstants * ShalePhaseListener * ShaleViewHandler I'm thinking that in an import statement * org.apache.shale.ViewController * org.apache.shale.faces.ShaleApplicationFilter would clearly say who's riding whom. Yah, I can buy that argument. Feel free to refactor. By the way, I'm about 50% done with making mailreader work just on top of ViewController (i'll refactor my imports as needed when you make those changes). That will give us a starting point for seeing what applications built on this thing could look like - even without all the dialog and application level stuff. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Thu, 28 Oct 2004 15:27:49 -0700, Dakota Jack [EMAIL PROTECTED] wrote: I admit to a huge amount of ignorance about JSF. I have partly been stymied by an inability to decide on a text to read. I have always liked Hans work, and may go that direction. I cannot know, of course, how that ignorance impacts my part in this discussion. I do think that in any event it is wise for shale to accommodate but not be tied to a particular implementation, if there is no penalty for that, and I cannot see one. I have always found that allowing options in the long run. A particular implementation of JSF, or a particular view technology in general? You don't have to worry about the former ... we'd be coding solely to JSF standard APIs, so you can use the JSF RI, MyFaces (once they fix a few outstanding bugs that mess up struts-faces too :-), or anyone else's conforming implementation. Choosing to rely or not rely on JSF's request processing lifecycle has huge impact on the design of Shale ... basically for everything that JSF already does that we want to keep, we'd have to define our own abstraction and then enforce that contract on any other technology. The simplest example is navigating from one page to another -- if you can't assume JSF underneath, then ViewController (or something) needs some additional API to do that. Regarding JSF information, I have read and can vouch for Hans Bergsten's and David Geary's JSF books. I haven't had time to read some of the others, but I've met some of the authors and it seems likely that they'll be high quality as well. A good starting bookmark for your browsing pleasure is http://jsfcentral.com, which has links to lots and lots of resources about JSF. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Shale
On Fri, 29 Oct 2004 01:22:09 +0200, Anders Steinlein [EMAIL PROTECTED] wrote: 3.1 Java2 Standard Edition APIs I'd be +1 for J2SE 5.0 Although I have no real saying in this, I am +1 on J2SE 5.0 as well. As I would anticipate 1-2 years in development on Struts 2.x, J2SE 5.0 should be widely deployed by then. If not, then our endorsement of it could encourage people to make the switch. ;) Plus, it could stand as a marketing bonus - in support of our revolutionary path. I sure hope it doesn't take us 1-2 years, but with our track record I'd be pretty foolish to make any promises at this point :-). Quick questions regarding Commons Logging proposal: Letting people choose their logging implementation is not a bad idea, but I've been hearing negative things about Commons Logging in its ability to detect the correct implementation to use. Something about classpath problems, if I remember correctly? Are these issues solved? 99.9% of the issue is configuration -- getting the right JARs and configuration files in the right place. In that sense its not really different than any other JAR that might be included in the webapp or installed in the container. You just need to get all the moving parts where they belong. And use C-L 1.0.4 or later, of course, because there were some critical bugfixes. Struts 1.x has used C-L from the very beginning of its existence, and we've been satisfied with it. Again, this is just little me's two cents, but I am in favor of minimizing third party dependencies as much as possible, and I don't see very much reason not to use the JDK 1.4 implementation. Anyone? There are a lot of potential customers that have existing environments based on things like Log4J, and those folks would be really (and justifiably) irritated to be required to configure two logging systems. Regards, \Anders Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BeanUtils/Collections dependency
Shouldn't commons-collections.jar be removed from all our build.xml files as well? That's what my nightly build executes. Craig On Sat, 30 Oct 2004 05:20:11 +0100, Niall Pemberton [EMAIL PROTECTED] wrote: Craig, I've updated the docs, can you change the nightly build to include beanutils 1.7.0 and remove Collections please. Thanks Niall - Original Message - From: James Mitchell [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 4:16 PM Subject: Re: BeanUtils/Collections dependency (mostly for Craig) I have also removed the test dependency on commons-lang a week or so ago, so you can drop in on your nightlies. Thx -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Niall Pemberton [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:04 AM Subject: BeanUtils/Collections dependency Now that 1.2.5 has been built and uploaded, can we now move Struts dependancy on to BeanUtils 1.7.0 and remove the dependancy on Commons Collections? If the answer is yes and there are no objections to doing this, then looks to me like the following needs doing: 1) Update the dependancies listed in the user guide: http://struts.apache.org/userGuide/installation.html 2) Update project.xml: http://svn.apache.org/viewcvs.cgi/struts/trunk/project.xml?rev=54906view=auto 3) Get Craig to update the nightly build on his machine 4) Remove the Collections dependancy from Gump http://cvs.apache.org/viewcvs.cgi/gump/project/struts.xml Is there anything I missed? Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
On Sun, 31 Oct 2004 21:30:22 -0600, Eddie Bush [EMAIL PROTECTED] wrote: Unless Martin is incorrect about the way JSF handles requests, I'm inclined to believe (despite the fact JSF will be a part of the next specification) we might want to consider using something else under the covers in our next major era of Struts. I love the idea of adherance to specifications, don't get me wrong ... so long as it is pragmatic to do so. Repeat after me ... the parts of JSF that Shale proposes to depend on have NOTHING to do with visual components Thus, any arguments over whether JSF adequately helps you build rich web interfaces (it doesn't yet -- that was out of scope for 1.0) are not relevant to the Shale decision. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF and highly dynamic apps (was Re: Struts-BSF, Struts-Scripting [was Re: Proposal: Javascript-to-Java object conversions]]])
On Tue, 2 Nov 2004 21:43:41 -0800, Martin Cooper [EMAIL PROTECTED] wrote: This is a really interesting statement. Perhaps I'm wrong, but I've always thought the whole point of JSF was visual components. Yet the statement above clearly indicates that JSF goes well beyond that charter, and clearly suggests that there are facets of JSF that should not be a part of that JSR. FWIW, here is IBM's take on how to build rich web applications using JSF components plus a framework for sending data back and forth: http://www-106.ibm.com/developerworks/websphere/library/techarticles/0411_hasson/0411_hasson.html?ca=dnp-344 Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Sub-Projects
On Fri, 05 Nov 2004 15:26:45 -0800, Don Brown [EMAIL PROTECTED] wrote: In a perfect world... svn.apache.org/asf/struts /core /trunk /branches /tags /faces /trunk /branches /tags /bsf /trunk /branches /tags /flow /trunk /branches /tags Therefore, we would then instruct folks that want to work on Struts core to use http://svn.apache.org/asf/struts/core/trunk I like that ... the basic principle would be that each separately releasable artifact would have it's own top-level structure with trunk, branches, and tags underneath. We'll likely factor core into separately releasable artifacts later, but this makes a great start. Only one minor question ... do we care about distinguishing proposals (like shale or jericho) versus things that are accepted parts of Struts, or is that just an issue of whether we ever actually release something or not? I'm ok either way. Don Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nightly Builds
I've adjusted the nightly build scripts to account for the reorganization of our Subversion repository that was recently done, and caused last night's build (20041114) to break. Tonight's should be fine. Nightly builds of the core Struts distribution are at: Struts Core Distribution: Binaries: http://cvs.apache.org/builds/jakarta-struts/ Source: http://cvs.apache.org/builds/jakarta-struts/src/ In addition, I've started building two of the sandbox packages on a nightly basis to make progress on their development more accessible. The distributions for these packages are combined sources and binaries, so you only need one download. Struts-Chain: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/ Struts-Shale: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/ In addition, nightly builds of the Struts-Faces integration library (also combined binary and source) continue to be available: Struts-Faces: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces/ Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale vs. Struts-Chain
Miscellaneous comments inline. On Thu, 18 Nov 2004 13:48:39 +0100, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi all, I read the docs on subversion about Shale. Well, a very interessting point. However, I asked myself how it is related to Struts/Commons - Chain. (The Proposal aka Jericho) Has Struts Shale no relationship to (Struts/Commons)-Chain? There is no particular relationship between Shale and *Struts*-Chain, which is designed to decompose the Struts 1.x request processor into little pieces. However, there is no reason you couldn't use *Commons* Chain inside a Shale environment in several different ways: * When using a Filter as the application controller, compose all the pre-request and post-request processing to be performed into chains, so that you only need to configure a single filter in your web.xml file. * Have your action event handlers (for things like submit buttons) delegate to business logic that is expressed in a chain, rather than executing it directly. that is composed in a chain Seams that Chain is only for Struts 1.2 ? or 1.3, which is based on Servlet2.2 That's correct. And Shale, that will be on top of Servlet2.4, will use Filter for CoR, isn't it? That is the proposal, yes -- although, as I remarked above, you can implement CoR inside a filter, in addition to the ability to use more than one Filter. It remains to be seen which model is easier to program to, and for users to configure. Last but not least, the IoC (or dependency injection) from Spring or Hivemind will be *included* into Struts / Shale? I believe that developers using a modern framework will expect an IoC solution to be included. Interestingly, the managed beans APIs in JSF provide setter injection IoC support already -- however, that may not be sufficient for everyone's needs. If the Shale core code itself was limited to just managed beans, then we could support incorporation of pretty much any IoC architecture by leveraging JSF's pluggability APIs. For example, the Spring folks have already built a JSF VariableResolver that allows the managed beans facility to instantiate Spring beans transparently. That's pretty cool. Applications, of course, could integrate directly with the IoC framework if they wanted to. Thanks for helping to clear my picture ;-) Greetings, Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[shale] Nightly build atifacts available
To help the folks who want to explore the Shale proposal, but haven't
had a chance to get hooked up with the SVN repository source code,
nightly builds of the following artifacts are being generated into
http://cvs.apache.org/builds/jakarta-struts/nightly/struts-shale/:
* struts-shale-MMDD.{tar.gz,zip} -- Core framework
* struts-shale-mailreader-MMDD.{tar.gz,zip} -- Mailreader example app
converted to use Shale APIs
* struts-shale-test-MMDD.{tar.gz,zip} -- Mock objects and initial couple of
unit tests. This library is separated because it can be used for both testing
the core framework and for building unit tests for application components
In all cases, the artifacts contain both binary and source. Also, the
database APIs for the mailreader example, which are used by the
example listed above, are uploaded nightly into
http://cvs.apache.org/builds/jakarta-struts/nightly/struts-examples/.
Requires Servlet 2.4 / JSP 2.0 or later to run, JSF RI 1.1_01 as well
to compile.
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale and Chain
On Fri, 19 Nov 2004 13:44:47 -0700, BaTien Duong [EMAIL PROTECTED] wrote: Greetings: I want to prototype commons-chain in shale. I saw 2 apps: agility and mailreader. I was able to build commons-chain.jar using ant. I modify maven project.xml of the 2 apps and run maven default successfully. But there is no war file of the above apps. Look like it has not done anything. I didn't build that part of the commons-chain repository, so I'll have to take a look ... it'll probably be over the weekend. Could someone show me how to build the 2 apps using commons-chain? Craig, do you have any preliminary instruction on the commons-chain in Shale? Let's assume that you have defined the business logic for a particular form submit as a chain named foo in the default catalog. JSF will call the action method for your submit button after validations have been successful, and after all the model values have been updated into your ViewController bean. So, what you need to do for chain is build up a Context object, and either include the ViewController bean itself (so your business logic can pull stuff out, but that makes it dependent on the ViewController APIs), or pass the data on in some other fashion like a Map. So, this is only one way to do it: (1) Create a context to use: Context context = new FacesWebContext(FacesContext.getCurrentInstance()); (2) Pass in the input field values from your ViewController (this is sorta cheating): context.put(viewController, this); (3) Get an instance of the command and execute it: Command command = CatalogFactory.getInstance().getCommand(foo); command.execute(context); (4) Pull out the logical outcome to be used for navigation and return it: (Assumes your business logic stored something under this attribute) String outcome = (String) context.get(outcome); return outcome; For your business logic, you'll want to model it as either a single Command, or as a Chain -- if you want to make the business logic independent of web tier APIs you'd take the input context argument as a Context and treat it like a Map to get and put stuff. Alternatively, you can cast it to FacesWebContext if you wanted typesafe access to all the extra attributes that defines. To configure your catalog of available commands and chains, you can use the org.apache.commons.chain.web.ChainListener class (a ServletContextListener) to set everything up from XML descriptions, although this is not required. That's what my examples (and the one in struts-chain) use. Thanks BaTien DBGROUPS Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release planning (was Re: Shale vs. Struts-Chain)
On Tue, 1 Jun 2004 19:52:51 -0400, Ted Husted [EMAIL PROTECTED] wrote: [snip] I would be in favor of immediately branching at 1.2.6, regardless, so we can start on 1.3.x. If there are any straggling issues with the 1.2.x build, I'd be happy to cross-commit between the 1.2.x and 1.3.x branches. We've let 1.2.x block 1.3.x long enough, and it's time to move on to bigger and better things. +1 -Ted. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can JSF Navigation be Reasonably Rewritten?
The page navigation *mechanism* in JSF is pluggable -- you need to provide an implementation of javax.faces.application.NavigationHandler, which could then do things like look at Struts action mappings to figure out where to go next, instead of (or in addition to) the JSF navigation-rule stuff. You configure a replacement implementation in a faces-config.xml file, in the navigation-handler element inside the application element. In the JSF spec, see Section 7.4 for the responsibilities of a NavigationHandler, plus the requirements for the default implementation. See Section 10.3 for configuration information, and in particular Section 10.3.5 for how you can use the Decorator Pattern to customize some aspects of the behavior of NavigationHandler (and all the other pluggability points in JSF) while delegating to the original implementation for other aspects. To get the spec, start at http://java.sun.com/j2ee/javaserverfaces. Craig On Mon, 22 Nov 2004 04:49:36 -0800, Dakota Jack [EMAIL PROTECTED] wrote: Is there a potential useful and reasonable rewrite of JSF so that the sort of navigation (controller) system in Struts can be employed instead of the page based navigation in JSF consistent with the rest of JSF, or is the page based navigation too tied to the rest of JSF? Thanks for any insights Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - 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: Build with SVN
Double check that you've got the latest BeanUtils code (1.7.0) in your build properties -- this has the lazy stuff plus FashHashMap, which was added to [beanutils] specifically so we could undo the linkage to [collections]. Craig On Mon, 22 Nov 2004 17:11:30 -0800, Dakota Jack [EMAIL PROTECTED] wrote: I suppose I am cracked, but I am getting an error in my build for Struts 1_2_6 because it does not find commons-collections.jar for org.apache.commons.collections.FastHashMap as well as, LazyDynaBean, LazyDynaMap, WrapDynaBean.getInstance(), and FastHashMap,. What's up? Thanks, Jack On Mon, 22 Nov 2004 12:04:02 -0800, Martin Cooper [EMAIL PROTECTED] wrote: On Mon, 22 Nov 2004 03:26:50 -0800, Dakota Jack [EMAIL PROTECTED] wrote: The ARChives are down -- search errors -- so I have to ask a question which has probably been covered well there. There are at least 4 sets of archives: http://mail-archives.apache.org/eyebrowse/SummarizeList?listId=240 http://www.mail-archive.com/dev%40struts.apache.org/ http://marc.theaimsgroup.com/?l=struts-devr=1w=2 http://dir.gmane.org/gmane.comp.jakarta.struts.devel How do you build from SVN. It's no different than when we were is CVS, other than that we've restructured so that you now want to build from the 'core' directly. The remainder of the instructions are here: http://struts.apache.org/userGuide/installation.html#Building The Struts SVN download, by the way, was 1.68 gigs on the disk. Woo hoo! You might want to just get struts/*/trunk instead of the whole enchilada. ;-) -- Martin Cooper Jack -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can't wake a person who is pretending to be asleep. ~Native Proverb~ Each man is good in His sight. It is not necessary for eagles to be crows. ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ - 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: chain in trunk for builds?
The Struts nightly build contains whatever the result of running ant clean dist in the struts/core/trunk directory produces. Until now, that hasn't included Struts Chain, but that's easy to fix. In the mean time, there is a nightly build of Struts Chain being produced separately: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/ that you can grab the code from. It is created by running ant clean dist in the struts/sandbox/trunk/struts-chain directory. Craig On Tue, 23 Nov 2004 09:07:02 -0600, Vic Cekvenich [EMAIL PROTECTED] wrote: Vic wrote: I think Martin said chain is in trunk. I would assume that the nighly bulids would then have chain in there, and that it not be a separate download? .V - 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: chain in trunk for builds?
On Tue, 23 Nov 2004 09:58:11 -0800, Don Brown [EMAIL PROTECTED] wrote: Sounds good. I would take it a step further, and, if no init parameter, look for the chain config as /chain-config.xml, making it possible to provide an intelligent default. We could then, take your idea in #3, and bundle our own /chain-config.xml inside Struts. Since it would be on the classpath, it could still be easily overridden by creating a chain-config.xml in the servlet context w/o adding any configuration to web.xml. Maybe default to /WEB-INF/chain-config.xml instead? That way the developer can easily provide overrides by dropping a chain-config.xml file into /WEB-INF, without making the chain configuration a publicly available static file that can be retrieved by a browser (which would be the case if it was in the top-level directory of the WAR). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain enhancement idea
On Tue, 23 Nov 2004 11:26:16 -0600, Hubert Rabago [EMAIL PROTECTED] wrote: How would plugins work with the chain configuration? I've written ActionServlet/RequestProcessor extensions and plugins in the past. Often, the reason is to inject custom pre-, actual, or post-processing at specific steps. An example would Tiles, which IIRC intercepts the forward processing to see if the destination is a configured tile, otherwise lets the default forward processing continue. It would be nice if plugins can inject chain elements at specific points in the chain at startup, programatically. This way, plugins can be programmed to modify specific portions of the chain that it is concerned with, without affecting other portions of the chain or modifications of other plugins. You can actually accomplish this kind of thing today (and an example of it is in the chain-config.xml file for Struts-Chain), but it's a little indirect. In your standard processing chain, do something like this: command className=org.apache.commons.chain.generic.LookupCommand catalogName=foo name=bar optional=true/ What this does, in English, is: * Look up a command named bar in a catalog named foo. * If such a command exists, delegate control to it (and do all the right stuff about filters if this is a chain) * If such a command does not exist, silently continue Therefore, it's very easy for your standard chain to provide extension points. If you want to require that the named command exist, set optional to false instead. Hubert Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain enhancement idea
On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska [EMAIL PROTECTED] wrote: I need to have a hook into processValidate() on validation failure. Currently that can only be done by copy-and-pasting the processValidate() method from RequestProcessor into a subclass and sticking a hook into the middle of the code. When I asked about this on the dev list long ago, it was confirmed that there was no other way to do this, but that chain would eventually provide this flexibility. If the chain isn't configured at a fine-grain level, then it's not all that much more functional than the existing RequestProcessor. The chain is configured at as fine-grained a level as you like, in XML. Hubert is talking about configuring the chain programatically as well, or at least in some way independent of the configuration of the primary processing chain. Programmatic configuration is certainly feasible ... there's no requirement in [chain] that you use the XML format at all. It's just one option. As long as you're willing to copy the base chain-config.xml file and make a few modifications, then you could simply add your own command which retrieves a value from the context under a well-known key and inspects the value to see if validation passed or not. This exact logic is the first thing executed in the CreateAction's execute method, which doesn't lookup or create an action unless the form validated. There's actually quite a few different ways to approach this, including the optionally invoke some other command at this point mentioned earlier in the thread, so you don't even *have* to cut-n-paste the standard version of the chain. You can start experimenting with commons-chain and struts-chain from CVS Head if you want to see what's going on. You don't have to wait for Struts 1.3. Indeed, Struts-Chain directly illustrates the fine-grained approach to defining the standard request processing chain that Joe describes. Nightly builds are available at: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/ Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
