Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Fri, 26 Mar 2004, Ted Husted wrote: On Thu, 25 Mar 2004 08:22:48 -0600, Joe Germuska wrote: As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. Another way to go would be to provide a API object in the request that the tags, or any other presentation technology, could use to access framework resources. In this way, no one else would need to the various special locations, only where to find the API object. This was the idea behind the ConfigHelper, which we put together when the Velocity/Struts tools was first being discussed. http://tinyurl.com/yshnp It's never been updated for modules, but if it were, the idea would be that it would return references to whatever resources were appropriate to a given module. From the perspective of a presentation technology, regardless of its nature, the ConfigHelper (or ActionContext) would be Struts, in the same sense that a JBDC driver appears to be the database. (Adapter/proxy patterns.) On Thu, 25 Mar 2004 20:09:08 -0800 (PST), David Graham wrote: Are we really still kidding ourselves that the taglibs are currently supported? No committer actively takes care of them. No one in the community responded to Ted's invitation to support them. We've all moved onto JSTL, JSF, Velocity, XSLT, etc. While the rest of the world migrates to newer/better technologies, we're stuck supporting tags that fewer and fewer people actually use. I don't use them myself, but I still know people who do. And some of those people help pay the bills :) I have and will support them by applying patches that people provide, as we just did by adding the module parameter. Moving the taglibs to their own subproject (at last!) will make a significant difference, since what does or does not happen with opt-taglibs won't directly affect core. If we moved to a context-based architecture (as above), it would help decouple the taglibs from the core, so the subprojects could be more independent, and level the playing field for other technologies. And, I'd do whatever it took to refactor the classic taglibs. IMO, it's almost irresponsible to distribute logic:iterate with a Struts minimum Servlet level of 2.4 where c:forEach is available. Things may change this year, but last summer I was still finding people at very large corporations who hadn't migrated to servlet 2.3. So, c:forEAch was not available to them. Hopefully that will change this year, and we'll find nearly everyone has finally found the budget to upgrade. Upgrading the container, though, is only half the story. That will allow the developers to use newer technologies in new parts of the application, but doesn't necessarily mean that the budget will be available to migrate existing large applications to a different set of JSP tags. That's where the real rub lies, IMHO. -- Martin Cooper Though, that's not going to get us off the compatibility train. The next thing will be whether they support servlet 2.4 for Struts 2.x :) Pity the world can't download Tomcat and be done it :( :) -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Wed, 24 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Tue, 23 Mar 2004, Martin Cooper wrote: On Tue, 23 Mar 2004, Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. Before anyone does dash off and write this, I'd like to have a brief discussion about this in relation to multi-module applications, and removing any need to modify web.xml when adding or removing modules. This is something I did in a project about a year ago, very successfully, so I think it's worth adding to the Struts core. So the earlier suggestion / idea was to automatically scan for a Struts config file in a jar's META-INF. This is a nice idea, but by itself, it doesn't work in a multi-module application. The problem is that each module has its own config file, and that config file does not include the name of the module (and neither should it, IMHO). The approach I have used in the past is to create the following structure within the web app: WEB-INF/ modules/ default/ config/ struts-config.xml ... other config files ... jsp/ ... moduleX/ ... moduleY/ ... ... I subclassed ActionServlet so that I could reimplement the config locating code, but it actually wasn't much work at all. The really cool thing about this approach is that adding or removing a module is as simple as adding or removing files and directories. Not one file needs to be edited. This is great for those of us who don't trust installers to do the right thing. ;-) In a similar vein, I'd like to talk about separating out the config reading somewhat, to allow for alternative mechanisms. The point here is that it should be possible to configure Struts in any of the following ways: * Just what we do today, reading the file names from web.xml. * Auto-locating the config file from META-INF (for 1-module apps). * The above-described mechanism for multi-module apps. * Not using Digester at all, possibly not even using XML files. What do people think? The only important con I can think of is that you'd need a Servlet 2.3 or later platform for this to actually work (in order to gain access to ServletContext.getResourcePaths()). Other than that, it's perfectly reasonable (and certainly reasonable for Struts 2.x). Doh! I'd forgotten about that. However, if we made config reading pluggable, people could implement any of the above options today, without the need to subclass ActionServlet. -- Martin Cooper -- Martin Cooper 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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Wed, 24 Mar 2004, Ted Husted wrote:
On Tue, 23 Mar 2004 20:52:03 -0800 (PST), Martin Cooper wrote:
So, there are pros and cons both ways, of course. Now we just need
to make a decision and move on it. ;-)
The consensus seems to be to use a single module with top-level-directories
representing each subproject, so lets move forward with that.
So I believe we're talking about something like this:
\core(including tiles and validator)
\apps
\site
\opt-dev (whiteboard or sandbox)
So 'dev', 'whiteboard' or 'sandbox'? ;-) I don't have a strong preference,
although 'sandbox' is used by at least 4 Jakarta sub-projects. (In those,
it's a separate repo, though. Do we want to do the same?)
\opt-taglib
I still like the idea of pushing this down under a generic presentation
directory, or at least under a JSP directory, so that we can move JSP
specific stuff out of core and into this.
\opt-el
Hmm. This is also a taglib...
\opt-faces
The example applications we will have to juggle a bit:
[apps]
/src/example - /mailreader/src/java
/src/examples - /examples/src/java
/src/tiles-documentation - /portal/src/java
And the same for /web
/web/{1} - {1}/src/webapp/
The other directory moving might go something like this:
[opt-el]
src/contrib/struts-el - opt-el
[opt-legacy]
/src/contrib/struts-legacy - opt-legacy
[opt-faces]
/src/contrib/struts-faces - opt-faces
[opt-dev]
/src/contrib/ - opt-dev
[opt-taglib]
src/share/o.a.s/taglib - opt-taglib/src/java/o.a.s/taglib
src/test/o.a.s/taglib- opt-taglib/src/test/o.a.s/taglib
doc/userGuide/dev_*.* - opt-taglib/xdocs
doc/userGuide/struts*.* - opt-taglib/xdocs
[site]
/doc/ - site/xdocs
[core]
/src/share - core/src/java
/src/test - core/src/test
/ - /
This is just a rough starting point. I'd want to try a dry-run offline first, and
post it where people could browse it :)
+1. I was thinking along the same lines.
One question is the packaging of Struts-el. Right now it's org.apache.strutsel. I'm
thinking we might want that to be org.apache.struts.el instead.
Maybe either:
org.apache.struts.taglib.el.${foo}
org.apache.struts.taglib.${foo}.el
The latter just extends the original package names with .el.
We might also want to shuffle some things around in opt-faces to make it more Maven
friendly. It's also sharing the UserDatabase package with the original example, and
so we might want to break the UserDatabase out as a deliverable that multiple
applications could share.
Next question. In making changes like this, at what point do we start breaking the
CVS history? I'd definitely want to keep it all for core and taglibs. The other
components might be less important.
We can arrange to keep CVS history indefinitely. However, we'd want to
stop moving things around as soon as possible, really, and certainly not
move anything after we've created labels or branches in the new tree.
** Last but not least: What else do we need to do for 1.2.1 ? -- Just the three
problem tickets on the bugzilla list now?
Actually, contrary to your comment in the Counting down thread, I don't
have anything up my sleeve (unless I forgot something myself). ;-) It
would be nice to resolve the issue with the Cactus tests not stopping
properly on Tomcat 5.0, but I can live without that if necessary.
--
Martin Cooper
-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: Counting down to the 1.2.1 release (was RE: Making Struts Build Easier)
On Thu, 25 Mar 2004, [EMAIL PROTECTED] wrote: -Original Message- Do we want to wait for a Validator 1.1.2, or roll it with 1.1.1? I just fixed a show stopper bug today in validator in CVS and made an accompaning change in Struts CVS. I won't be able to be RM to for Validator until Mid April, so we need a volunteer. Otherwise, we'll need to roll back the JavaScriptTag.java and validator-rules.xml in struts to use validator 1.1.1. I can probably do the RM thing for Validator if someone else (David?) can do the doc and release note updates. Just let me know when we're ready to roll and I can take it from there. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Tue, 23 Mar 2004, Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. Before anyone does dash off and write this, I'd like to have a brief discussion about this in relation to multi-module applications, and removing any need to modify web.xml when adding or removing modules. This is something I did in a project about a year ago, very successfully, so I think it's worth adding to the Struts core. In a similar vein, I'd like to talk about separating out the config reading somewhat, to allow for alternative mechanisms. Unfortunately, I'm about to go off to a 4-hour meeting ;-( so I can't expound further right now. More later... -- Martin Cooper -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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Tue, 23 Mar 2004, Ted Husted wrote: On Tue, 23 Mar 2004 18:16:53 +, Peter A. Pilgrim wrote: 1) I think you should keep the same elementary structure Moving forward, we have already decided to use Maven as our build environment, which addresses a number of consistency and structural issues. We had also decided to distribute non-core components, like the taglibs, independantly. Independant releases lead to the idea of independant modules. Modules also seem like a good way to handle bringing on some of the more popular extensions. As Joe mentioned, we would still need somewhere to put the shared files, such as Maven's project.xml, the LICENSE and NOTICE files, the KEYS file, etc. In a single-module world, those would live at the top level, just as they do now. In a multi-module world, those should be in another module solely for that purpose. (I certainly wouldn't want a build file that knows about all the individual modules living in core, or any other independently buildable module.) So, the site subproject would be an overview of the Struts project, and then link to the subprojects (including core) for more detail. A contributor mentioned wanting a single JAR. I don't think that's an itch any of Committers are desparate to scratch. And, if anyone did, it's been pointed out that Ant can be used to burst and combine JARs. Anyone could do that. I don't think anyone wants to build a single Struts WAR, especially since we already have multiple example applications in their own WARs. I don't want a single jar or a single war, but I do want to be able to run *one* build process to get all of the pieces to build. I also don't relish the thought of having to maintain multiple Gump descriptors, either. At this point, we're down to whether to organize the subprojects (units of release) into multiple modules or around top-level-directories in a single module. Yep, that's exactly where we are. ;-) Here's what I think are the pros and cons of each approach: One module, multiple directories: + One checkout grabs it all (but an alias can reference multiple modules). + Natural place (top level) for all cross-module files. (See above.) + Labelling and branching across modules is one CVS command. + Don't need CVS admin karma (i.e. Craig) to create new modules. - Harder (?) to check out only portions of the overall code base. Multiple modules: + Easier (?) to check out only portions of the overall code base. + May scale better as we accumulate extensions. - Need an extra module for cross-module files. - Clutters up the Apache CVS repository. The reason for the question marks is that this issue seems to have been implied, but it's not really true. The difference is literally a single character - 'cvs co struts-core' versus 'cvs co struts/core'. The labelling issue is an interesting one. Someone (hi Ted! ;) is going to argue that we'll want to label each module independently because we'll want to release them independently, and I agree with that. But I also think that there will be points in time that we'll want to label or branch the entire code base, which will be easier to do across a single module. So, there are pros and cons both ways, of course. Now we just need to make a decision and move on it. ;-) -- Martin Cooper My only feeling is that should we start inviting some of the popular extensions to join us, the module approach seems like it would scale better. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Splitting struts-config into multiple jar and read them as resource stream
On Tue, 23 Mar 2004, Martin Cooper wrote: On Tue, 23 Mar 2004, Craig R. McClanahan wrote: Quoting Ted Husted [EMAIL PROTECTED]: On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: Perfect! What you did in JSF is exatcly what we need: the controller servlet automatically recognize 'META-INF/struts- config.xml' resources in any JAR files that were included in the application. When in struts? Can I help? I think we do the same sort of thing in Commons Chain, n'est pas? This particular functionality was in relationship to automatically finding and loading struts-config.xml files (contributed by JAR files dropped in to the WAR) without having to explicitly note them in context init parameters. It doesn't really relate to per-request processing. I can't do this today, but anyone who wants to help on this need only submit an enhancement request (with a patch) to ActionServlet.init() to scan the configuration resources in addition to what it already does. The secret sauce is to use ClassLoader.findResources() to get the list of URLs to be processed. Before anyone does dash off and write this, I'd like to have a brief discussion about this in relation to multi-module applications, and removing any need to modify web.xml when adding or removing modules. This is something I did in a project about a year ago, very successfully, so I think it's worth adding to the Struts core. So the earlier suggestion / idea was to automatically scan for a Struts config file in a jar's META-INF. This is a nice idea, but by itself, it doesn't work in a multi-module application. The problem is that each module has its own config file, and that config file does not include the name of the module (and neither should it, IMHO). The approach I have used in the past is to create the following structure within the web app: WEB-INF/ modules/ default/ config/ struts-config.xml ... other config files ... jsp/ ... moduleX/ ... moduleY/ ... ... I subclassed ActionServlet so that I could reimplement the config locating code, but it actually wasn't much work at all. The really cool thing about this approach is that adding or removing a module is as simple as adding or removing files and directories. Not one file needs to be edited. This is great for those of us who don't trust installers to do the right thing. ;-) In a similar vein, I'd like to talk about separating out the config reading somewhat, to allow for alternative mechanisms. The point here is that it should be possible to configure Struts in any of the following ways: * Just what we do today, reading the file names from web.xml. * Auto-locating the config file from META-INF (for 1-module apps). * The above-described mechanism for multi-module apps. * Not using Digester at all, possibly not even using XML files. What do people think? -- Martin Cooper Unfortunately, I'm about to go off to a 4-hour meeting ;-( so I can't expound further right now. More later... -- Martin Cooper -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving Struts-Chain (was ... PageController ...)
On Sun, 14 Mar 2004, Ted Husted wrote: On Sun, 14 Mar 2004 11:34:10 -0600, Joe Germuska wrote: At 11:59 AM -0500 3/14/04, Ted Husted wrote: On Fri, 12 Mar 2004 15:07:18 -0600, Joe Germuska wrote: No one is more gung-ho about Struts Chain than I am, but people should be aware that we're still just into beta with functionality. Using it on my latest project, I've definitely found a few pieces that hadn't yet been implemented. I've put in what I found missing -- tiles and file upload -- but there are probably some other less mainstream pieces that will turn out to be buggy or not even implemented. We would probably want to make a branching CVS tag for this if we do it. I don't have a lot of experience working on branched codebases with a distributed team, so it should be an interesting ride, but I think Struts Chain is far enough from ready that we don't have a choice. I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). Plus, we need to push commons-chain to a full release. And what about commons-resources? That sounded like it was pretty close. Looking at http://jakarta.apache.org/struts/status.html , I think that roadmap may be still be a good strategy -- get the resources transition done for 1.3, then the new request processor for 1.4. Can anyone summarize what's standing between here and moving to commons-resources? I think Commons Chain can move up any time we wanted. It's just a matter of floating a vote. The Resources thing has been a longtime coming and should be stable. I wouldn't hesitate to do both Resources and Struts Chain in the HEAD now. I'm OK with Chain being promoted as is, but I'd prefer to see Resources migrate to a presence-based build (as opposed to a contrib basis) before promotion. And yes, I'm willing to make the change when I have the time to do it. ;-) -- Martin Cooper In general, I'm satisfied with targeting the page prep as a chain- dependent feature. If we introduce a StrutsContext as the chain implementation of o.a.c.chain.Context then we'll have to come up with a Context factory process so that the ComposableRequestProcessor can be given a Context instead of instantiating one itself. My first hunch is that it should be an early chain command which creates a sub-context of a specific type and uses it to do most of the chain processing. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cactus test status
Current status: 41: All tests run successfully. 40: I don't currently have a 4.0.x build handy to run against. 33: Container has problems as soon as tests start. 50: Tests run successfully, but container doesn't stop. I have a feeling that the 33 issue is a config problem, because the container starts having a fit as soon as the tests start, but I used to be able to run these. I'd appreciate another pair of eyes (or more!) taking a look at 33 and especially 50. The 50 support is very preliminary, and the server.xml is mostly just hacked from the 41 version. Let's get our tests back in gear! -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Making Struts Build Easier (Re: coming out for JSF + Struts , was: Struts JSR?)
On Mon, 22 Mar 2004 [EMAIL PROTECTED] wrote: Hi I think that the move to Maven is a giant leap forward. Now at least we can build with requisite jars that are already build. Earlier it ment that you would have to buil a bunch of projects before you could actually do the real build. Also you can have local repositories for when you are offline. Building the dependencies yourself has *never* been required for Struts. You can build against released versions of Commons components, or, when those are in flux and we've been depending on unreleased features, on the nightly builds of them. Note that with Maven, you actually have a stronger requirement than with the Ant build - that the versions of the Commons dependencies you need have been made available in a Maven repository. (Yes, that can be worked around, but we're talking here about the ease with which you can just type 'maven' and have everything happen.) -- Martin Cooper Hermod -Opprinnelig melding- Fra: Joe Germuska [mailto:[EMAIL PROTECTED] Sendt: 22. mars 2004 15:28 Til: Struts Developers List Emne: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?) For me, the main discouraging thing about contributing to the development of Struts has been the build process. In the past, you had to download all of jakarta-commons and spend a day or two figuring out how to get that to build. Recently, I tried to build Struts and was successful using the Maven stuff. Personally, I don't mind using Maven, but I don't know that it should be *required* to build a project from scratch. I'd love to be able to cvs co Struts, navigate to jakarta-struts and type ant jar. I realize this is no easy thing to accomplish with a build file - but it has been the most discouraging factor for me. ;-) The only way we could accomplish something like that with a build file would be by including JARs in CVS, and if you ask me, there are enough reasons why that's a bad idea that I prefer the way it is, even though I'd very much like to see people feel more comfortable getting in and working on Struts source code. When you say I don't know that [Maven] should be *required*... is your point that Ant is a widely accepted Java tool, while Maven has yet to cut a 1.0 release? That's fair -- just want to make sure I understand you. The build.xml file generated by 'maven ant' uses the ant 'get' task and the Maven iBiblio repository to download dependencies; we could perhaps look at copying some of that into our ant script to reduce build.properties to being more about configuration stuff and less about dependency stuff. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
of code, leading to the possibility of why not mine? kinds of things. For larger code bases, we'd also likely need to have some discussions with the incubator folks. But, as you say, let's get our own house in order first, and then come back and talk about this some more. -- Martin Cooper -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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: On Mon, 22 Mar 2004, Ted Husted wrote: On Mon, 22 Mar 2004 11:36:37 -0700, Matt Raible wrote: While it's great to break out things into separate modules - I'd love to be able to get struts.jar w/ everything in it - including EL and tags. I can live with all the commons-* JARs (even if it is annoying), but in general - the less JARs, the better. It just simplifies things for the developer. I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. If that were someone's itch, it could certainly be done. Ant doesn't know about the module partitions, and so someone could write a uber-build that did something like this. If we have all of the pieces in separate repositories, though, where would the files for such an uber-build be checked in? That's one of the problems I have with the multi-repository solution - there is no place for files that span those repositories. If we have one repository split into pieces, then we still have the top level for these things. On the multi-repository projects I've worked on, we had a special repository just for integration tasks like this. So we'd need yet another repo - say struts-integration - just for this. Why is that better than just doing what we need within the repo that we have already? But, the problem with thinking of Struts as one monothic build is that every aspect of the framework has to be perfect, all at the same time, before we can call it a general availability ready-for-prime-time release. One of the many reasons 1.1 took so long was that if there was any bug in any component anywhere in the framework, everything gridlocked. :( :( :( That doesn't need to be true if we don't want it to. Recall that for a time we had a separtely built, separately distributed component called struts-legacy to handle the data source situation. There is no need for a one-to-one correlation between repositories and distributable entities. What we want to do ... need to do ... is be able to release fixes to components like the taglibs independently of the core controller. Likewise, we need to release changes to Struts EL or Struts Faces (once it goes 1.0) without having to be sure every other component is ready to roll. We should also be able to release updates to the example applications without re-releasing the rest of the framework, if that's all we want to roll right now. Absolutely. And the number of repositories we have is entirely orthogonal to this. Ultimately true, although it's still somewhat easier to visualize if you have separate repositories. Some people may not like more JARs, but I know for certain that the single JAR approach is a momentum killer. It's made my life much more difficult, and I think it's chased away some Committers who became frustrated by having to everything right in order to one little feature into a formal release. For the people who want / need a single jar, it would be simple enough for us to provide an Ant target that explodes the desired individual jars and recombines them into a single jar. The only tricky part, I think, would be creating a manifest that identifies the versions of the individual pieces in that jar. That's assuming people want such a beast, of course. (I'm not in that camp myself, though, just as I'd never use the Commons Combo build.) If we can get more code into the hands of more developers in less time, then a few more JARs seems like a small price to pay. :) +1 Yep. Here's something else to mull over: Now that Struts is a TLP, we might want to talk about whether we want to ask the most popular open source Struts extensions -- like Struts Menu, Workflow, Stxx, SSL, and TestCase -- whether they would like to donate their code to the ASF and live as Struts opt subprojects. This would be a continuation of what we started with Tiles, Validator, and Nested, which are all favorites with our community. People working on such packages might be brought on as Struts Committers, since they have proved they have what it takes to run a project, and after an appropriate period, later invited to join the Struts PMC. IMHO, when people talk about JSF replacing Struts, they are unaware of the true breadth of the Struts platform. Perhaps it's time we made sure people know how much they are missing :) A sad truth: In working with various teams managing larger projects, I've found a surprising reluctance to use extensions that were not distributed by the Struts project itself. By giving these very fine extensions the nod, we can make them available to a greater number of Struts teams, to everyone's benefit. If we don't help make these extensions available to everyone, then we end up
Re: OT: Struts JSR?
On Sat, 20 Mar 2004, Nadeem Bitar wrote: On Sat, 2004-03-20 at 20:41 -0800, Craig R. McClanahan wrote: Quoting Thomas L Roche [EMAIL PROTECTED]: David Geary spoke on JSF at trijug.org M 15 Mar 04. My notes of his remarks include - Is JSF a replacement for Struts? Yes! - JSF is a standard. Struts will never be a standard. which I believe to be pretty-nearly-direct quotes. I'm assuming he really meant + JSF 1.0 can do pretty much everything Struts 1.1 can. There is definitely substantial overlap, especially in the HTML tags area, as well as things like outcome-based navigation handling and creating form beans. The design of JavaServer Faces benefited tremendously from the experience we've had with Struts, and the design in these areas exceeds the current functionality of Struts in many respects. Two particular features of Struts that are not present in JavaServer Faces 1.0 -- Tiles for layout management, and the Validator Framework for creating client side JavaScript to enforce the rules (in addition to enforcing them at the server). Fortunately, however, you can use these Struts features in conjunction with JavaServer Faces by using the Struts-Faces integration library. With JSP2.0 attributes and fragments you can do advanced layout and templates without tiles. I am sure the validation would also be addressed with time. There is a huge amount of momentum around Struts, and it's not going to go away any time soon. That being said, however, it's time for Struts to start doing some more innovation instead of incremental improvements, in order to remain as popular for new development. That is my point exactly and I am hoping that struts would innovate and implement some of the things other frameworks use. Such as? What kinds of innovations are you looking for, and specifically what kinds of things are you seeing other frameworks use that Struts could benefit from? -- Martin Cooper + JSF is a JSR, and Struts will never be a JSR. but I'm wondering about that last statement. What prevents Struts from undergoing the JCP? Are there circumstances under which you might consider this? For those not familiar with it, some brief background on the JCP would be useful here. More details are at the JCP web site http://jcp.org. Anyone who is a JCP member can propose a JSR. To be accepted, it would to be accepted by the 16 members of the Executive Committee for the J2SE/J2EE platform (note that Sun has one of these 16 votes -- people who believe that Sun could veto a JSR proposal for something like this, even if Sun wanted to, are misinformed; that veto ability only applies to language changes or uber JSRs like the ones for the entire J2SE and J2EE platforms). The person(s) or organization(s) proposing the JSR would need to plan on (if it's accepted) providing a specification documenting the Java API or technology to be standardized, a Technology Compatibility Kit (TCK) against which other company's implementations of the technology can be tested, and a Reference Implementation (RI) -- which must pass the TCK -- proving that the technology can actually be implemented. If by the you in your question you are referring to the Struts committers, we could indeed propose such a JSR (Apache is a JCP member, and is currently also a voting member of the Executive Committee). But it wouldn't really be a JSR to standardize Struts ... at most it could be a JSR to standardize the APIs supported by Struts. After all, the JCP is really a standards organization that creates specifications to be implemented by others. Struts (and many other open source projects) are often not implementations of some standard -- they can be seen as sort of a combination of spec and implementation rolled into one. If the long term goal is that everyone continues to use the one and only implementation, then the JCP is not really the right development approach. Beyond that, the Executive Committee members will tend to not desire multiple JSRs with large amounts of functional overlap -- which would definitely be the case if someone tried to propose the Struts APIs. After all, these are companies that would need to fund the development of their own versions of the hypothetical standard Struts, and the cost of integrating it into their own products. It is much more cost effective (as well as less confusing and costly for users) to support a single standard in each technology area, and add functionality in future versions as it makes sense to standardize. As such, it seems much more likely that the Executive Committee would accept a JSR for some future version of JavaServer Faces that built on top of of the 1.0 version than a JSR for a different way to solve many of the same problems. The planning for the next steps in this direction, in fact, is already
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004, Ted Husted wrote: On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote: Option 1 works for me. Simplest thing that could possibly work. As you've said, we can always change things around later. The problem is that is that we already have the simplest thing. And, if we want multiple Maven-based products with independent release cycles, then what we have won't work. :) We already have the simplest thing in terms of one repo, but we have far from the simplest thing when it comes to organising within that repo. The point I was trying to make with (1) is to distinguish between organising using multiple repos versus organising within one repo. For example, if we do what you suggest below, and have 7 separate CVS repos, we will face a number of problems, as I see it: a) We will not make friends with the infrastructure folks. Each time we add a new committer, they will have to add 7 separate avail entries with that account. b) People will need to do 7 separate 'cvs update' invocations to get all of the latest code. That just doesn't seem practical to me. c) It's not clear to me that the Maven reactor could be made to work across multiple repos. And even if it could, which repo would the Maven files live in? d) Any multi-repo build would have to make assumptions about the location of the other repos on the local disk. It would be reasonable to assume that they are peers within the same directory, but that is an assumption that we would have to make. e) Web site maintenance is going to be, um, challenging. We would actually need an 8th repo for site-wide documentation, and then we'd need to have some tools to avoid having to do 8 separate 'cvs update' invocations to update the entire site on www. f) Any time we want to add something new (e.g. opt-foo or core2), we would need to go back to infrastructure and ask for yet another repo. I see little advantage of all those separate repos over just one repo, since that one repo could be organised in exactly the same way. In other words, why use separate repos over something like this: struts/ core/ taglib/ app/ opt-legacy/ opt-el/ opt-faces/ opt-sandbox/ site/ or even this: struts/ core/ taglib/ app/ opt/ legacy/ el/ faces/ sandbox/ site/ Actually, I'm not sure that a sandbox should be under 'opt' at all. I could see us using a separate repo for that, since there is precedent in both Commons and Taglibs. I am now leaning towards 3 repos myself: struts-legacy This is our current repo, renamed. I don't really care for this name, but I can't think of anything better right now, and I hate sticking numbers in repo names, because they become invalid quite rapidly if they are associated with versions (unless we start a new repo for each major version, a la Tomcat, but I don't like that idea either, for CVS history reasons). struts This would be structured per one of the suggestions above. struts-sandbox A separate sandbox, a la Commons and Taglibs. The reason I've changed my mind since yesterday about 2 repos versus 1 (ignoring the sandbox for the moment) is that I realised that all of the CVS shuffling we want to do will make it very hard, if not impossible, to continue to work on older (pre-shuffle) versions of the product. One other minor comment: I'd prefer to use something like 'archive' over 'legacy', since the latter has a more negative connotation, in my mind at least. But I won't make a big deal of it if other people prefer 'legacy'. ;-) -- Martin Cooper We were already getting ready to change things around. And we *do* need to move things around if we are ever going to get away from a monolithic Struts to a modular Struts, were people can assemble the Struts platform they need for their application. If not now, then when? The resolution we submitted says we're suppose to rationalize Struts, so let's rationalize :) My preference would be to have a separate repository for each subproject. Each subproject represents a coherent software product or deliverable with its own release cycle. Another way of thinking of the subprojects/products is as Maven artifacts. As mentioned elsewhere, all Struts Committers can have access to all repositories, and all PMC Members have voting rights over all subprojects. I'd suggest that we setup a legacy jakarta repository that would be frozen. Directories could then be moved over to their new repositories, either from a second copy of the original repository or from a remote copy. The subprojects/repositories/artifacts/products I had in mind were: * core * taglib * app * opt-legacy * opt-el (or jstl) * opt-faces * opt-sandbox Here's some possible path-to-repository mappings. Later entries assume earlier entries were already moved. [taglib] /src/share/o.a.s/taglib - /src/o.a.s/taglib [app] /src/example,examples,tiles
RE: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sun, 21 Mar 2004, Martin Cooper wrote:
On Sun, 21 Mar 2004, Ted Husted wrote:
On Sun, 21 Mar 2004 00:07:28 -0800, Steve Raeburn wrote:
Option 1 works for me. Simplest thing that could possibly work. As
you've said, we can always change things around later.
The problem is that is that we already have the simplest thing. And, if we want
multiple Maven-based products with independent release cycles, then what we have
won't work. :)
We already have the simplest thing in terms of one repo, but we have far
from the simplest thing when it comes to organising within that repo. The
point I was trying to make with (1) is to distinguish between organising
using multiple repos versus organising within one repo.
For example, if we do what you suggest below, and have 7 separate CVS
repos, we will face a number of problems, as I see it:
a) We will not make friends with the infrastructure folks. Each time we
add a new committer, they will have to add 7 separate avail entries with
that account.
b) People will need to do 7 separate 'cvs update' invocations to get all
of the latest code. That just doesn't seem practical to me.
c) It's not clear to me that the Maven reactor could be made to work
across multiple repos. And even if it could, which repo would the Maven
files live in?
d) Any multi-repo build would have to make assumptions about the location
of the other repos on the local disk. It would be reasonable to assume
that they are peers within the same directory, but that is an assumption
that we would have to make.
e) Web site maintenance is going to be, um, challenging. We would actually
need an 8th repo for site-wide documentation, and then we'd need to have
some tools to avoid having to do 8 separate 'cvs update' invocations to
update the entire site on www.
f) Any time we want to add something new (e.g. opt-foo or core2), we would
need to go back to infrastructure and ask for yet another repo.
I see little advantage of all those separate repos over just one repo,
since that one repo could be organised in exactly the same way. In other
words, why use separate repos over something like this:
struts/
core/
taglib/
app/
opt-legacy/
opt-el/
opt-faces/
opt-sandbox/
site/
or even this:
struts/
core/
taglib/
app/
opt/
legacy/
el/
faces/
sandbox/
site/
Another thought on this. When we get to Struts 2, I'd like to see us
remove all of the JSP-ness of Struts from the core, and also add some
degree of support for other presentation technologies, such as XSLT and
Velocity. So, instead of having 'taglib' where it is in the above tree, we
might want to do something like:
struts/
...
presentation/ (or whatever name we want)
jsp/
taglib/
{others when we get to them}/
...
Incidentally, where would Tiles land in all of this? In theory, it's not
tied to JSP, but rather to Servlets, so it might be applicable to some
other presentation technologies, but clearly not all.
--
Martin Cooper
Actually, I'm not sure that a sandbox should be under 'opt' at all. I
could see us using a separate repo for that, since there is precedent in
both Commons and Taglibs.
I am now leaning towards 3 repos myself:
struts-legacy
This is our current repo, renamed. I don't really care for this
name, but I can't think of anything better right now, and I hate
sticking numbers in repo names, because they become invalid
quite rapidly if they are associated with versions (unless we
start a new repo for each major version, a la Tomcat, but I
don't like that idea either, for CVS history reasons).
struts
This would be structured per one of the suggestions above.
struts-sandbox
A separate sandbox, a la Commons and Taglibs.
The reason I've changed my mind since yesterday about 2 repos versus 1
(ignoring the sandbox for the moment) is that I realised that all of the
CVS shuffling we want to do will make it very hard, if not impossible, to
continue to work on older (pre-shuffle) versions of the product.
One other minor comment: I'd prefer to use something like 'archive' over
'legacy', since the latter has a more negative connotation, in my mind at
least. But I won't make a big deal of it if other people prefer 'legacy'.
;-)
--
Martin Cooper
We were already getting ready to change things around. And we *do* need to move
things around if we are ever going to get away from a monolithic Struts to a
modular Struts, were people can assemble the Struts platform they need for their
application. If not now, then when? The resolution we submitted says we're suppose
to rationalize Struts, so let's rationalize :)
My preference would be to have a separate repository for each subproject. Each
subproject represents a coherent software product or deliverable with its own
release cycle. Another
[PROPOSAL] Struts infrastructure changes
The following is a set of proposed changes to the Apache infrastructure to accommodate the Struts move to an Apache top level project. The idea is to come up with a single agreed-upon set of changes that we can submit to the infrastructure folks as a single request, rather than submitting each one piecemeal. Your feedback is appreciated. Mailing Lists New mail domain: struts.apache.org The following lists are standard for an Apache TLP: user@ dev@ cvs@ (usually forwarded to dev@) pmc@ Moderator: Ted Husted (same as today) Existing subscribers need to be migrated. Old list addresses should be forwarded for some period of time. Web Site New virtual host: struts.apache.org Redirect from jakarta.apache.org/struts for some period of time. Writeable by group: struts (see below) Wiki New wiki: wiki.apache.org/struts Migrate pages from: StrutsProjectPages on old wiki (nagoya) Unix Group New group: struts Members: (Struts PMC members) Source Control Old CVS repo: jakarta-struts New CVS repo: struts Optional: Move to Subversion (IMO, not now, but we can discuss.) Bug Database Optional: Move to Jira (IMO, now's as good a time as any.) One other thing is that we'll want to get external mail archivers to switch to the new mailing lists once those are set up. I'm not clear on whether the infrastructure folks arrange that or we need to do it ourselves, but I'll ask when I submit the above. Anything else I missed? (There are a lot of internal changes we'll want to make as well, but I'm not trying to address those here.) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts infrastructure changes: Jira
On Sat, 20 Mar 2004, Mike Kienenberger wrote: Martin Cooper [EMAIL PROTECTED] wrote: Optional: Move to Jira (IMO, now's as good a time as any.) One thing I've noticed about Jira is that attachments cannot be deleted general developers, only members of the Jira admin group. Not sure if that's an issue. I'm not aware of any way to delete an attachment with Buzilla, so I don't think it would be an issue in moving to Jira. ;-) -- Martin Cooper As a general user, I've found Jira far easier to use than Bugzilla. I haven't been using it as a developer long enough to comment. - 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]
Bylaws (was Re: [ANNOUNCE] Struts goes TLP with unanimous vote...)
This looks pretty good, Ted. Just a couple of things: * If we're going to introduce the idea of Struts sub-projects right up front, then I would prefer to consider these as purely organisational, at least initially. That is, I'm open to breaking up the code base / docs / etc. into multiple sub-projects, but I would prefer that all people related matters span the Struts project. Specifically, I wouldn't want to allow for sub-project X committers as distinct from Struts committers. (Basically, I want to be quite clear that this is not an umbrella project in any shape or form. ;) * In the Roles page, I'd prefer that the CLA submission be called out in the text, and not just left to the sample letter, as it is now. There has been confusion on this in Jakarta, so let's make it as clear as possible for Struts. ;-) * Should the release process (i.e. the Tomcat-like process we recently adopted) be part of the bylaws, or is that not necessary? That came to mind as I was reading the Release Testing section, since they're somewhat related. By the way, Stefan Bodewig put together a very nice wiki page to serve as a resource as the Gump team puts their own bylaws together: http://wiki.apache.org/gump/Drafts/ProjectBylaws It might be worth perusing for additional ideas. (I'm planning on doing some perusing of it myself when I have some time.) -- Martin Cooper On Thu, 18 Mar 2004, Ted Husted wrote: On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote: I'll be putting together a list, shortly, of what needs to happen next for us to fully graduate. Stay tuned... One thing the resolution mentions is that we are to draw up a set of bylaws. Heretofore, we've been operating under the Jakarta Guidelines, to good effect, IMHO. I recently created a proposed patch the guidelines to reflect that the PMC members are the decisions makers, and that Committers are essentially Contributors with write privileges. http://www.apache.org/~husted/jakarta-site2/site2-patch.txt copies of the affected pages as HTML: http://www.apache.org/~husted/jakarta-site2/guidelines.html http://www.apache.org/~husted/jakarta-site2/roles.html http://www.apache.org/~husted/jakarta-site2/communication.html http://www.apache.org/~husted/jakarta-site2/decisions.html http://www.apache.org/~husted/jakarta-site2/management.html Of course, the Bylaws or management page would have to be revised to reflect our project. I would propose an extension to the Subproject section that says something like: Subprojects are the project's unit of release. Each subproject should represent an implementation of the Struts core or a related component. Each subproject should focus on creating, maintaining, and releasing a single software product or deliverable. All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote. The intent being that as we rationalize Struts, we can move things like the taglibs and some of the contrib packages into their own subprojects, with their own release cycles. When a subproject is created, we could decide whether a subproject needs its own mailing list or not. I have no opinion as to USER lists, but would lean toward keeping a single DEV list, for the sake of cross-pollination. In any event, mailing list allocation is not part of the proposed, initial bylaws. If this sounds all right, I'll merge this with our existing documentation. Of course, we can always change any of this later. But at least we will have fulfilled that portion of the resolution. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Struts infrastructure changes
On Sat, 20 Mar 2004, Martin Cooper wrote: The following is a set of proposed changes to the Apache infrastructure to accommodate the Struts move to an Apache top level project. The idea is to come up with a single agreed-upon set of changes that we can submit to the infrastructure folks as a single request, rather than submitting each one piecemeal. Your feedback is appreciated. Mailing Lists New mail domain: struts.apache.org The following lists are standard for an Apache TLP: user@ dev@ cvs@ (usually forwarded to dev@) pmc@ Gee, I have a comment on my own proposal. ;-) Do we want our own announcements@ list? In the past, we've sent release announcements to the Jakarta announcements list, so I'm wondering if we want one of our own now, for people who don't want to subscribe to the Struts -user or -dev lists. -- Martin Cooper Moderator: Ted Husted (same as today) Existing subscribers need to be migrated. Old list addresses should be forwarded for some period of time. Web Site New virtual host: struts.apache.org Redirect from jakarta.apache.org/struts for some period of time. Writeable by group: struts (see below) Wiki New wiki: wiki.apache.org/struts Migrate pages from: StrutsProjectPages on old wiki (nagoya) Unix Group New group: struts Members: (Struts PMC members) Source Control Old CVS repo: jakarta-struts New CVS repo: struts Optional: Move to Subversion (IMO, not now, but we can discuss.) Bug Database Optional: Move to Jira (IMO, now's as good a time as any.) One other thing is that we'll want to get external mail archivers to switch to the new mailing lists once those are set up. I'm not clear on whether the infrastructure folks arrange that or we need to do it ourselves, but I'll ask when I submit the above. Anything else I missed? (There are a lot of internal changes we'll want to make as well, but I'm not trying to address those here.) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OT: Struts JSR?
On Sat, 20 Mar 2004, Nadeem Bitar wrote: On Sat, 2004-03-20 at 17:47 -0500, Ted Husted wrote: On Fri, 19 Mar 2004 18:53:58 -0800, Nadeem Bitar wrote: If for example JSF 2.0 is available, and Spring Framework is well integrated with JSF before Struts 2.0 is available, I strongly believe that struts won't have a place and would lose market shares. First let's be very clear. It's *not* about market share. I have to disagree with you on this one. Struts is the defacto standard because of its market share. It is well documented, it has a healthy community, and struts talent is available easily, because of its market share. I think what Ted is trying to say is that the Struts developers do not work on Struts to increase its market share, but because Struts works for us, and we care to put in the time and effort to maintain and further develop it. The fact that it has become sufficiently popular to turn into a de facto standard is nice, but that's secondary to (most of) us, and not why we're here. -- Martin Cooper Struts does not need market-share to survive. All we need is a community of developers who use the product and want to help support it. A community of developers would support a product only if they believe in it. Many hard core struts users and developers are migrating to other frameworks and this is a loss for the whole community. Struts 2.0 would have a chance to bridge the gap between struts and other frameworks. Since Struts 2.0 is still on the drawing board I am only advocating to do it right even if that means breaking backward compatibility and making major architecture changes. How many downloads we realize isn't important. Whether 90% or whether 10% of shipping applications use Struts isn't important. What's important is that Struts works well for the people who do want to use it, and that those people want to do the work to make it better. Of course, if we all find that JSF does most of what we all need, and we want to use it in our own applications, then Struts will quickly become whatever other JSF components we need to ship our own applications. But so long as products like JSF leave out components that real-life applications need, there will always be a Struts. From the beginning, it's always been about providing axles between the wheels that Java already has. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: branching 1.2 and 1.3 and CVS reorg for TLP status
On Sat, 20 Mar 2004, Craig R. McClanahan wrote: Quoting Joe Germuska [EMAIL PROTECTED]: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... I think there's a lot of merit in rationalizing the directory structures as part of the move to TLP-ness. Assuming we don't move to Subversion right now (see other thread), the move is effectively a CVS repo rename by the infrastructure folks, lock, stock and barrel. Any rationalisation is totally up to us. If we want to break up our existing repo, we have a couple of options: 1) One top-level 'struts' repo that we break down as we see fit. This option leaves everything in our control, since, as far as infrastructure@ is concerned, there is only one CVS repo. 2) Multiple top-level repos, one of which is a renamed version of our current repo, and the remainder of which are new empty repos. We would then migrate pieces of our current repo out to the new repos. 3) Same as (2) above, except that we don't ask for a repo rename, but just new repos, and we migrate everything ourselves to the appropriate new repo. While (3) is the cleanest insofar as we wouldn't have leftovers in the Attic of the renames repo, it's also a huge amount of work for us, and runs the risk of forgetting things. My preference is for (1). It is the simplest approach, and will allow us to move things around however we see fit, without having to decide up front which other repos we might want. If, at some point, we decide we do want other top-level repos, we can request them at that time. Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are ways to preserve history, but I suspect there will be difficulties if we decide to split up what has been a single repository (jakarta-struts) into per-subpackage repositories. A guru on CVS would definitely be useful here. A CVS repo rename will preserve all of our history, obviously. After that, I can take care of preserving history whatever we decide to do (as long as we stay with CVS ;). It's slightly easier if we have only one repo, but it can still be done across repos. -- Martin Cooper I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. I'm going to focus some energy as well on commons-chain and struts-chain now that JavaServer Faces is done. Joe 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: [PROPOSAL] Struts infrastructure changes
On Sat, 20 Mar 2004, Craig R. McClanahan wrote: Miscellaneous comments intermixed. Quoting Martin Cooper [EMAIL PROTECTED]: The following is a set of proposed changes to the Apache infrastructure to accommodate the Struts move to an Apache top level project. The idea is to come up with a single agreed-upon set of changes that we can submit to the infrastructure folks as a single request, rather than submitting each one piecemeal. Your feedback is appreciated. Mailing Lists New mail domain: struts.apache.org The following lists are standard for an Apache TLP: user@ dev@ cvs@ (usually forwarded to dev@) I would like to maintain our current practice that these are *always* forwarded to dev, instead of it being a separate mailing list. I think we agree. ;-) Currently, commit messages go to a separate list (jakarta-struts-cvs) which is forwarded to (or otherwise sent to the same people as on) struts-dev. My intent (poorly worded, I admit) was to retain that same mechanism. pmc@ As noted in other messages in this thread, we need an announcements list too. Moderator: Ted Husted (same as today) Existing subscribers need to be migrated. Old list addresses should be forwarded for some period of time. Web Site New virtual host: struts.apache.org Redirect from jakarta.apache.org/struts for some period of time. Writeable by group: struts (see below) Wiki New wiki: wiki.apache.org/struts Migrate pages from: StrutsProjectPages on old wiki (nagoya) This would be on the Apache infrastructure, right? Yes, wiki.apache.org is the MoinMoin wiki that Leo set up to replace the UseModWiki installation on nagoya. Unix Group New group: struts Members: (Struts PMC members) It would ultimately need to include all of the committers (not just PMC members), in order for CVS commits to actually work. Um, yes, you're right, of course. Source Control Old CVS repo: jakarta-struts New CVS repo: struts This can certainly be a starting point. We should consider whether it's worth separating subprojects into their own repositories for ease of management purposes (but I agree with your other comments that commit karma would still be to all subprojects, no matter how this decision comes out). Yes. See my message on a separate thread regarding our options, and my preference, here. (In short: start with one repo, and split when we really know what we want.) Optional: Move to Subversion (IMO, not now, but we can discuss.) Given the amount of work this would involve, and assuming we can import our CVS log history somehow, this would be OK with me; but seems like something we could also defer to later after the dust settles. My feeling on Subversion is that it's not quite ready for prime time yet. I've been watching other projects migrate, and I've seen problems crop up that have warranted new point versions of SVN. As David pointed out, client support is also somewhat lacking today, compared to CVS. Together with the fact that I can support just about any manipulation of CVS that we might decide to do, but I'm completely clueless about SVN, makes me want to stick with CVS for now. -- Martin Cooper Bug Database Optional: Move to Jira (IMO, now's as good a time as any.) I'm OK with either Jira or Bugzilla. Note that other projects migrating to Jira have been able to import their bug history, so we wouldn't lose that. One other thing is that we'll want to get external mail archivers to switch to the new mailing lists once those are set up. I'm not clear on whether the infrastructure folks arrange that or we need to do it ourselves, but I'll ask when I submit the above. Anything else I missed? (There are a lot of internal changes we'll want to make as well, but I'm not trying to address those here.) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: branching 1.2 and 1.3 and CVS reorg for TLP status
On Fri, 19 Mar 2004, Joe Germuska wrote: At 2:48 PM -0500 3/14/04, Ted Husted wrote: I'd say we could branch what we have as 1.2 and start thinking of the HEAD as 1.3. IMHO, the quickest way to sort out what we need to do with the Struts-Chain RequestProcessor is to get it out there as the nightly build. [Many hands make light work ;)] So, we could reserve the 1.2 for any desperate fixes (as we've done before), but do anything resembling new development against the HEAD (1.3). I might do something like this over the weekend, depending on my time (then again, I may not at all!) But if I did, I'd want to see if anyone had any strong feelings, or fixes they thought they'd like to get in before a branch, or... ? I'm all for creating a 1.2.x branch so that work can begin on 1.3.x on HEAD, but I'm firmly against creating that branch on HEAD right now. I see little justification for creating a branch at a random point in the development cycle. IMNSHO, branches should only be created from a release point, especially given our newly adopted Tomcat-style release model, which means that the time between releases should be short. A bunch of stuff has changed since 1.2.0, so it clearly doesn't make sense to create a branch from there. A few more things need to happen before we're ready for 1.2.1, but not too many, IMO, so I believe we should create the 1.3.x branch at the point at which we release 1.2.1. If people want to start on 1.3.x, then I'd suggest we all pitch in and try to get 1.2.1 in shape for release ASAP. [Note: Technically, we should vote on how to categorise 1.2.0. However, I have not send out a vote request, since it seems fairly obvious to me that there was breakage enough to classify it as a test build and no more. If anyone else feels otherwise, please speak up! ;)] Or should all of this wait until we get the move to struts.apache.org settled? I'm assuming we'll reorganize CVS as part of that, into struts-core, struts-taglib, etc... Speaking of that, can we/should we do anything to preserve CVS logs if we move files? Or will we start fresh? I think if we move the actual CVS files it will all be preserved, but I've never tried that. There are a number of things that will need to be taken care of as part of the move to TLP, but I don't think they should impact this too much. The CVS repo move, as Ted suggests, is really a rename. Any reorganisation of the code base we want to do is independent of that. I'm interested in getting the Struts Chain stuff mainstreamed, but like I said, this may very well not be the weekend I start on it. In any case, I figured a branch would be cause for a little bit of discussion amongst committers. Indeed. ;-) I'm looking forward to seeing Chain move forward too, but I have a big fat serious caveat before we do anything at all here to bring it into the mainstream. Commons Chain is still in the sandbox. I feel very strongly that we should not be relying on sandbox components in the mainstream of Struts. We've been through the pain of that several times before, and I don't want to have to deal with it again. So before we bring Struts Chain into the mainstream, Chain needs to be promoted out of the sandbox and into Commons Proper, preferably in good enough shape that it's not too far from being released. (Of course, the latter condition will affect a vote to promote it in the first place!) -- Martin Cooper Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
On Wed, 17 Mar 2004, Arron Bates wrote: Guys, Just got the summary email from the Apache board meeting, and the Struts proposal went through with flying colours. Congrats guys, really. So much never-ending quality work. I guess that with everyone else out driking Irish alcohol I was the first to see the email, and I got to be the whistle-blower. :) Nah, you just type a little faster than I do. ;-) I'll be putting together a list, shortly, of what needs to happen next for us to fully graduate. Stay tuned... -- Martin Cooper Cheers, Arron. - 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]
Jakarta Struts Proposal for Adoption as an Apache Top-Level Project
To the Board of the Apache Software Foundation: We, the committers of the Jakarta sub-project jakarta-struts have held a vote and agreed to apply to you for elevation of our sub-project to the status of a top-level Apache project. Struts is a mature, self-determining project that is able to govern itself under the auspices of the ASF Board in accordance with ASF bylaws and guidelines. We believe that normalizing our relationship with the ASF Board by reporting directly rather than through the Jakarta PMC, and taking full responsibility for our community and codebase will benefit all concerned. Please find attached our proposed board resolution. Submitted on behalf of the Struts community by: Craig R. McClanahan Ted Husted Rob Leland Cedric Dumoulin Martin Cooper Arron Bates James Holmes David M. Karr David Graham James Mitchell Steve Raeburn Don Brown Joe Germuska Vote thread on the [EMAIL PROTECTED] mailing list: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=666369 WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the Apache Struts framework, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Struts PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Struts PMC be and hereby is responsible for the creation and maintenance of software for Apache Struts and for related software components, based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Struts be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Struts PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Struts PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Struts PMC: Craig R. McClanahan Ted Husted Rob Leland Cedric Dumoulin Martin Cooper Arron Bates James Holmes David M. Karr David Graham James Mitchell Steve Raeburn Don Brown Joe Germuska NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig R. McClanahan be and hereby is appointed to the office of Vice President, Apache Struts, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Struts PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation of the Apache Struts Project, in the Java language as well as others, and be it further RESOLVED, that the initial Apache Struts PMC be and hereby is tasked with the migration and rationalization of the Jakarta PMC Struts subproject, and be it further RESOLVED, that all responsibility pertaining to the Jakarta Struts sub-project and encumbered upon the Jakarta PMC are hereafter discharged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Struts as an Apache Top Level Project
On Fri, 12 Mar 2004, Don Brown wrote: Sorry, I just moved from Hawaii to California so I haven't been following struts-dev like I should. Welcome to California! (Did you bring the weather with you? Is that why it's so nice right now? ;) About the TLP vote: +0 - no strong feelings one way or another Excellent. Now I don't have to modify the resolution at all. ;-) -- Martin Cooper Don - Original Message - From: Martin Cooper [EMAIL PROTECTED] Date: Thu, 11 Mar 2004 21:47:05 -0800 (PST) To: Struts Developers List [EMAIL PROTECTED] Subject: [RESULT][VOTE] Struts as an Apache Top Level Project The response to this vote has been unanimous, with all proposed PMC members responding except for two: Arron Bates and Don Brown. I have attempted to ping those two directly, but have not yet heard back. The next board meeting is March 17th, which is next Wednesday. I propose to submit our resolution this weekend, for consideration at that meeting. In the absence of responses from Arron and Don before then, I will remove their names from both lists. They will, of course, be welcome to join the PMC at a later time. If anyone has any objections to the above plan, please speak up now. -- Martin Cooper On Sat, 6 Mar 2004, Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] Struts as an Apache Top Level Project
The response to this vote has been unanimous, with all proposed PMC members responding except for two: Arron Bates and Don Brown. I have attempted to ping those two directly, but have not yet heard back. The next board meeting is March 17th, which is next Wednesday. I propose to submit our resolution this weekend, for consideration at that meeting. In the absence of responses from Arron and Don before then, I will remove their names from both lists. They will, of course, be welcome to join the PMC at a later time. If anyone has any objections to the above plan, please speak up now. -- Martin Cooper On Sat, 6 Mar 2004, Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Struts as an Apache Top Level Project
On Thu, 11 Mar 2004, Arron Bates wrote: Ooops, just missed it. :) Not at all. I won't be sending the proposal to the board until the weekend, so now that you've responded, you're in. :-) -- Martin Cooper No worries. Due to life, I've been conspicuous in my absence, and probably wouldn't be a ripple in the PMC decision making anyways. Just as long as I can maintain commit status to support nested tag coders I'm happy. :) If things change and I get more play time, then I'll knock on the PMC door as required. Cheers, Arron. The response to this vote has been unanimous, with all proposed PMC members responding except for two: Arron Bates and Don Brown. I have attempted to ping those two directly, but have not yet heard back. The next board meeting is March 17th, which is next Wednesday. I propose to submit our resolution this weekend, for consideration at that meeting. In the absence of responses from Arron and Don before then, I will remove their names from both lists. They will, of course, be welcome to join the PMC at a later time. If anyone has any objections to the above plan, please speak up now. -- Martin Cooper On Sat, 6 Mar 2004, Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [RESULT][VOTE] Struts as an Apache Top Level Project
On Fri, 12 Mar 2004, [EMAIL PROTECTED] wrote: Since Craig indicated his preference NOT to be VP, how does this impact this proposal ? I don't believe that's the case. Craig indicated that he *is* willing to be Vice President, but pointed out that his being VP isn't a necessary condition for Struts becoming a TLP. He voted +0, after all. -- Martin Cooper -Rob - 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: A proposal concerning the RequestUtils.populate()
On Wed, 10 Mar 2004 [EMAIL PROTECTED] wrote:
Hi,
First of all, sorry for my poor english, but please read carefully.
I am a developer who use Struts for building RDBMS-based applications.
I have to make so many tables that is linked by PK-FK relation.
So There's so many Beans that are shaped like this
(ParentBean and ChildBean is linked by PK-FK)
ParentBean.java
public class ParentBean {
private int id;
private String name;
private ChildBean[] childBeans = new ChildBean[0];
// get/set methods
// ...
}
ChildBean.java
public class ChildBean {
private String childName;
// get/set methods
// ...
}
ParentBean can have many, more than one ChildBeans,
And I cannot guess how many ChildBeans would be created at run-time.
So this page that is used for user-input cannot be worked properly.
ParentBeanInput.jsp
..
html:text property=parentBean.childBeans[0].childName/br/
html:text property=parentBean.childBeans[1].childName/br/
html:text property=parentBean.childBeans[2].childName/br/
html:text property=parentBean.childBeans[3].childName/
..
When request parameter is populated(when RequestUtils.populate() is
called.),
Array IndexOutofBoundary Exception is occured
Because Property Entities like parentBean.childBeans[3].childName does not
exist.
So I use modified beanutils library that can extends length of arraies at
run-time
and make a component of array to populate this kind of request parameter
that
is mapped to array property of bean.
I would like to Form-Bean processor that support array of variable length.
First of all, this type of question should be asked on struts-user, where
there are probably lots of people who have needed to do the same thing.
In any case, take a look at the LazyList class in Commons Collections. I
think this should do what you want.
http://jakarta.apache.org/commons/collections/apidocs/org/apache/commons/collections/list/LazyList.html
--
Martin Cooper
Thank you for reading,Jang
_
.. .. .. .. .. .. .. .. MSN
http://www.msn.co.kr/love/
-
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]
[VOTE] Struts as an Apache Top Level Project
Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts as an Apache Top Level Project
On Sat, 6 Mar 2004, Joe Germuska wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. +1 for Struts as a top level project +1 for Craig as VP Please feel free to add my name to the cover letter. Done. I have also added you to the proposed PMC. I apologise for missing your name off the list - it should have been on both from the start. -- Martin Cooper Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tree is open
It's probably obvious by now, but just wanted to confirm that the CVS tree is no longer frozen. Now we can get those pending commits dealt with. ;-) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Committers, please read
Per Geir's message, below, any committer without a CLA on file by March 1st will lose their commit privileges. There are several Struts committers who are listed as not having CLAs on file. Many of those people have not been active here for quite some time, but I wanted to be sure everyone has a chance to retain their commit privileges, should they so desire. If you're a committer, and you're not sure if you have a CLA on file, please read the message below, and follow up if necessary. -- Martin Cooper -- Forwarded message -- Date: Mon, 23 Feb 2004 18:25:27 -0500 From: Geir Magnusson Jr [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: CLAs : Deadline is March 1, 2004 to avoid suspension of commit privs Jakarta Committers, The March 1 CLA deadline for CLAs is approaching quickly. As you are aware, all committers working on Apache Software Foundation projects are required to have a CLA filed with the ASF. This document clearly defines the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. Every committer is responsible for ensuring a CLA is on file with the ASF by March 1, 2004. Any committer that does not have a CLA on file will have their committer privs suspended. To check to see if one is on file for you, please look here : http://www.apache.org/~jim/committers.html If your name is *not* in italics, there is no CLA on file. f you are not listed as having a CLA on file, read about it and get one : http://www.apache.org/licenses/#clas and follow the instructions. It's really easy. Please direct all questions and problems to [EMAIL PROTECTED] or the public list if you don't mind public discussion of your situation. We will do what we can to help resolve any issues that arise. Silence on this issue isn't an option. The ASF is working to tie up any IP-related loose-ends, and this is an important one - they will suspend commit privs. Thanks geir, writing on behalf of the Jakarta PMC -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tagging and freezing (was Re: Bug in JavascriptValidatorTag)
On Wed, 25 Feb 2004, Joe Germuska wrote: Perhaps this is understood, but I'm assuming that we also want to say that the RM owns the release tags for the release he or she is managing, and only the RM should *ever* move the tags? It's never been stated as such, but that's not a bad idea at all. I can't think of a good reason to move tags, other than to tweak things as part of the release process, and only the RM should be doing that. Now, where can we document this? ;-) -- Martin Cooper Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Struts 1.2.0 Test Build available
The Struts 1.2.0 Test Build is now available here: http://www.apache.org/~martinc/struts/v1.2.0/ This is the first Struts build being made available following the same test-and-release process that has been used successfully by the Tomcat team for some time. It is *not* an official Apache release. Once feedback has been collected on the stability and general quality of this build, a determination will be made as to whether it should be promoted to Alpha status. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.2.0 uploaded (Re: 1.2.0 is tagged and frozen)
On Sun, 22 Feb 2004, Martin Cooper wrote: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. The release is now, finally, on minotaur. You can find it here: http://www.apache.org/~martinc/struts/ Before I send out an announcement message, I would really appreciate it if someone could verify the integrity of the files (e.g. by checking the sigs against the files themselves), since I had so much trouble uploading them. random-spout As a result of this debacle, I have a new-found intense dislike of my ISP and a new-found respect for Linux. My ISP supports only Windows, and has been unable to resolve my problems in uploading large files using Windows, even though it is abundantly clear that the problem is on their end. Eventually, I solved the problem by transferring the files to a separate box that runs SuSE Linux (Thanks, Arron!), and uploading the files from there using scp. My ISP does not support Linux at all, yet scp on Linux recovered from the network stalls that caused Windows to lock up. So it seems that networking is more reliable, with my ISP, using unsupported operating systems than using supported operating systems... /random-spout -- Martin Cooper 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts-examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release. Once I get the build uploaded, I'll ask other folks to take it for a spin before sending out an announcement. Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? -- Martin Cooper On Sun, 22 Feb 2004, Martin Cooper wrote: Please hold off on all checkins until the release is done. Thanks. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen)
On Wed, 25 Feb 2004, Matt Raible wrote: The first thing I noticed is that struts-el is missing from the download. I used the one I had from a nightly build in December and it didn't seem to cause conflicts. Fooey. I don't know why that would have happened. I'll take a look when I get home tonight. And thanks for catching it! -- Martin Cooper I tried 1.2.0 in AppFuse and all tests pass! Nice work gents. I didn't even have to modify any files - my last Struts update was December 2, 2003. Matt -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 1:39 AM To: Struts Developers List Subject: 1.2.0 uploaded (Re: 1.2.0 is tagged and frozen) On Sun, 22 Feb 2004, Martin Cooper wrote: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. The release is now, finally, on minotaur. You can find it here: http://www.apache.org/~martinc/struts/ Before I send out an announcement message, I would really appreciate it if someone could verify the integrity of the files (e.g. by checking the sigs against the files themselves), since I had so much trouble uploading them. random-spout As a result of this debacle, I have a new-found intense dislike of my ISP and a new-found respect for Linux. My ISP supports only Windows, and has been unable to resolve my problems in uploading large files using Windows, even though it is abundantly clear that the problem is on their end. Eventually, I solved the problem by transferring the files to a separate box that runs SuSE Linux (Thanks, Arron!), and uploading the files from there using scp. My ISP does not support Linux at all, yet scp on Linux recovered from the network stalls that caused Windows to lock up. So it seems that networking is more reliable, with my ISP, using unsupported operating systems than using supported operating systems... /random-spout -- Martin Cooper 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts-examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release. Once I get the build uploaded, I'll ask other folks to take it for a spin before sending out an announcement. Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? -- Martin Cooper On Sun, 22 Feb 2004, Martin Cooper wrote: Please hold off on all checkins until the release is done. Thanks. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Tagging and freezing (was Re: Bug in JavascriptValidatorTag)
I almost didn't read this thread, based on the subject line, but I'm rather glad that I did, given how far the subject has strayed... There is still a need for a freeze after tagging. While it's not quite as essential as with our previous release process, it's still important. Here's why. The tag happens before the release build is made, and so obviously before that build is tested. It is quite common that some tweaks need to be made after the tag is initially applied, and before the release is made available. Examples are updating an incorrect version number, either in the build file or in the docs, fixing something that is trivially broken, whether it be functionality or a test, etc. Now, if someone had checked in a big change right after the release was tagged, but before the release was done, that somewhat limits the options of the RM for getting the release right. If the RM needs to fix a version number in the build file, but a whole new feature has been added that also involved changes to the build file, the choices become (a) proceed with a release that has the wrong version number (bad), (b) pick up the new feature that has not even been seen in a nightly build yet (bad), or (c) abandon the release (bad). So, at least as long as folks are happy with me as the RM, please allow me the leeway of a short freeze period between tagging and releasing the build, so that I can do the job as best I can. I don't think that should be too onerous. As for 1.2.0, I'd like to ask that people not change the build files until I get it rebuilt with Struts-EL included (hopefully this evening), in case I need to make changes there. However, you can consider the tree open for other changes, to be included in 1.2.1 (i.e. please don't move the tags). -- Martin Cooper On Tue, 24 Feb 2004, Ted Husted wrote: Yes, under the current process, there little reason to have a real freeze. It's more like a heads-up now. AFAIC, the codebase should not be considered frozen now, and people can start applying fixes to go into 1.2.1, including the license thing. The only reason we're not starting a vote on the quality of 1.2.0 is because of an ISP glitch. If 1.2.0 dies on the vine, then we can just roll 1.2.1 at any convenient juncture. -Ted. On Tue, 24 Feb 2004 15:13:38 -0600, Joe Germuska wrote: At 6:28 PM + 2/24/04, [EMAIL PROTECTED] wrote: Once a release is tagged that's it. We could retag and do 1.2.1, however there will probably be other things that need to be fixed. The point is to get 1.2.0 out the door and then see about making whatever fixes that need to happen. Well, if it's tagged, then I don't have to wait to commit the change; there's no need for a freeze, as you can always check out to the tag and use that to cut the release. No need to wait to apply the license patches either. (I will wait, however, until I'm sure other people see it the way I do.) Of course, it's possible to move CVS tags -- I assume you're just saying that you think that that's procedurally wrong? I'm not sure I agree, but I don't feel very strongly about it either. In fact, I'd much rather see 1.2.0 come out, with as few delays as possible. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.2.0 uploaded - Take 2
I've just finished uploading a new build that includes Struts-EL. (And none too soon, given the huge thunderstorm going on here right now...) It's in the same location as before, listed below. Again, I'd appreciate it if someone could verify the integrity of the files, and let me know if they're OK. Hopefully, this one will be OK and I can go ahead and announce it to both lists. -- Martin Cooper On Wed, 25 Feb 2004, Martin Cooper wrote: On Sun, 22 Feb 2004, Martin Cooper wrote: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. The release is now, finally, on minotaur. You can find it here: http://www.apache.org/~martinc/struts/ Before I send out an announcement message, I would really appreciate it if someone could verify the integrity of the files (e.g. by checking the sigs against the files themselves), since I had so much trouble uploading them. random-spout As a result of this debacle, I have a new-found intense dislike of my ISP and a new-found respect for Linux. My ISP supports only Windows, and has been unable to resolve my problems in uploading large files using Windows, even though it is abundantly clear that the problem is on their end. Eventually, I solved the problem by transferring the files to a separate box that runs SuSE Linux (Thanks, Arron!), and uploading the files from there using scp. My ISP does not support Linux at all, yet scp on Linux recovered from the network stalls that caused Windows to lock up. So it seems that networking is more reliable, with my ISP, using unsupported operating systems than using supported operating systems... /random-spout -- Martin Cooper 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts-examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release. Once I get the build uploaded, I'll ask other folks to take it for a spin before sending out an announcement. Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? -- Martin Cooper On Sun, 22 Feb 2004, Martin Cooper wrote: Please hold off on all checkins until the release is done. Thanks. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: 1.2.0 is tagged and frozen
On Mon, 23 Feb 2004, Ted Husted wrote: On Sun, 22 Feb 2004 22:38:24 -0800 (PST), Martin Cooper wrote: Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? Following Craig's description of the Tomcat release approach (copy below), I'd say we should make an announcement to the Struts DEV and USER lists, with an URL leading to one of our home directories (or wherever Tomcat and others have been posting such things), but not the Jakarta announcement list. I imagine we'd now reserve the latter for a General Availability release that's being mirrored. I'm fine with restricting the announcement as you describe. However, given the size of the struts-user list in particular, I'm not so sure about not taking advantage of mirroring for downloads. I'll take a look at what the Tomcat folks are doing in this regard, though, and just do what they do. ;-) Sorry if the taglib-exercise module is flaky. If it is, mea culpa. But once it's up there, we can still announce it, see if there is anything else we can fix, and then try again with 1.2.1. That would also give us a chance to apply that license patch. No biggie. As I said, I'm not overly concerned by the failures I saw, although I do want to verify that the problems with (2c) are also test app problems and not actual bugs in the core. I'll try to check that tonight, but I'd be happy if someone else beat me to it. ;-) Once I get the build uploaded (grr!), I'd like someone to try out the Cactus tests and make sure that most of them, at least, run OK before I send out an announcement. After 1.2.0 is out of the gate, we can apply Paul's license patches, as you suggest. Per Greg's board summary, we'll want to make sure we have the license on all applicable files. Also, since the board is now officially discouraging the use of @author tags, I'd like to see us remove those too. -- Martin Cooper -Ted. On Tue, 16 Dec 2003 11:27:45 -0800, Craig R. McClanahan wrote: The Tomcat folks do indeed vote on every release -- they just do things in a little different order: * Post what amounts to a release candidate and announce to a limited audience (dev and user lists) asking for testing. * Testing ensues ... * Call a vote on the release, with the options to call it alpha, beta, stable (that's fine with me), or withdraw (if there was some bad problem). * Announce to the world and do the usual process of distributing the bits. The same approach would work for us, and IMHO meets the Jakarta requirements with one additional wrinkle -- the Jakarta PMC needs the opportunity to vote on releases as well, to be consistent with the current ASF reqirements. On Sun, 22 Feb 2004 22:38:24 -0800 (PST), Martin Cooper wrote: The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts- examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release. Once I get the build uploaded, I'll ask other folks to take it for a spin before sending out an announcement. Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.2.0 is tagged and frozen
Please hold off on all checkins until the release is done. Thanks. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 is tagged and frozen
The release is built, but I have a couple of problems. 1) My ISP has gone flaky on me, and I haven't been able to upload it to minotaur. They claim the problems should be fixed tomorrow, so hopefully I'll be able to upload it then. 2) Some of the exercise-taglibs tests are failing: 2a) bean:include fails because it is trying to include welcome.html, but there is no such file. 2b) html:img fails because there are no images in the struts-examples web app at all. 2c) html:messages fails with a lot of nulls in the test table. It looks like all of these are probably issues with the test app itself, rather than the tags, so I'm not overly concerned, and suspect we probably should go ahead with 1.2.0 anyway, especially since we're not claiming it's a final release. Once I get the build uploaded, I'll ask other folks to take it for a spin before sending out an announcement. Actually, with this new release strategy, where should the announcement message go, since it's not a Final release? The same lists, or a subset? Thoughts? -- Martin Cooper On Sun, 22 Feb 2004, Martin Cooper wrote: Please hold off on all checkins until the release is done. Thanks. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 1.2.0 Release Plan
-Original Message- From: Paul Sundling [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 7:52 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan David Karr emailed me, so I'll take care of the licenses this weekend. I have a social engagement today, so I'll take care of it on sunday. Thanks for doing this, Paul. One caveat: The tag/freeze for 1.2.0 happens tonight at midnight my time. Since there are often a few tweaks that happen after the tag and before the release itself, you might want to hold off until the release is uploaded (or I send a Houston, we have lift-off message) before updating your source tree. (It turns out that I have a social engagement today also, so I can't take care of this before tag/freeze either.) -- Martin Cooper Paul Sundling David Graham wrote: --- Paul Sundling [EMAIL PROTECTED] wrote: One possible question is from the new boilerplate: Copyright [] [name of copyright owner] Is it just The Apache Software Foundation, like in the 1.1 license? That would be my guess. I think that's correct. The documentation uses that string in the examples. David The one reference to Struts in the previous license version was related to the section on use of the trademark name. I think that's dealt with in a more general way in the new license. Paul Sundling David Graham wrote: The exact license details can be found here: http://www.apache.org/dev/apply-license.html David --- Karr, David [EMAIL PROTECTED] wrote: Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:12 PM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan At 1:49 PM -0600 2/20/04, Joe Germuska wrote: Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? I should amend this: + 0 from me; I don't have time to do it now, and probably won't soon enough that I'd want to delay 1.2.0 until it gets done. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] 1.2.0 Release Plan
-Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 11:50 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? +1 from me too; wasn't someone offering to do it a few weeks ago? At this point I don't see any reason to ever build against commons nightlies unless we're using some unreleased feature. +1 on this as a baseline -- only depend on nightlies where necessary, not as a matter of course. Several of the Commons components we depend on have released since we last did, so we may want to update the versions in our dependency list. Collections is a particularly ugly situation. Do we upgrade to 3.0 and break existing Struts apps requiring 2.x? Or, do we stay at 2.x and break apps needing 3.0? I missed the details of this Collections change and its incompatibility, but I don't see why we'd upgrade to 3.0 unless we need it: same as with nightlies. Are there bugfixes rolled into 3 along with the incompatibilities? I'd say we either make a collections-2 branch that has bugfixes but maintains compatibility, or pull what we need back into Struts. Without knowing the details, it sounds like a serious mistake/judgment error was made in releasing 3.0, but we shouldn't subject all Struts users to the consequences. * The Cactus tests won't run for me, for some reason. When I start the tests, everything looks fine as it starts up, but then it just sits there doing nothing. They used to work, but I can't recall what I might have changed to break it. Anyone have any ideas? Obviously, I don't want to create a release and not be able to run the tests! I was able to run the ant/Tomcat 4.0 tests up to the point where they always fail for me: org.apache.struts.taglib.bean.TestCookieTag.testCookieTagNameMultiple -- I have to assume this is some kind of local configuration problem, but I'm not hanging. One day I hope to have time to figure out the problem, but I'm far from a Cactus expert. I don't get that far. The problem I have is not that the tests fail, but that they do not run at all. After I invoke the target, everything seems to start up OK, but then it just sits there doing nothing. I'd really like to get past that point, if anyone has any ideas... -- Martin Cooper (Has anyone tried running the Struts cactus tests with Maven? I had gotten it to the point where most of the tests passed, and the ones that didn't I suspected were similar to my Ant/Cactus failures -- something local, not something in the code.) Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - 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] 1.2.0 Release Plan
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 8:10 AM To: Struts Developers List Subject: Re: [VOTE] 1.2.0 Release Plan -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 12:46 AM To: 'Struts Developers List' Subject: RE: [VOTE] 1.2.0 Release Plan Does this involve changing the file header comment to replace the existing license with the new license? That's something that I can relatively easily script in elisp macros. If someone can confirm that's all this is, and show me exactly what needs to change, I can get that done this weekend. The committers project in CVS has python java versions that does this automatically. The Python version has undergone several versions to improve the copyright conversion. You might want to start there first. Yes, I would also suggest going with the Python version. It's seen considerably more usage, across Apache, than the Java one has at this point, so is more likely to have had the wrinkles ironed out. -- Martin Cooper -ROb - 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] 1.2.0 Release Plan
On Fri, 20 Feb 2004, Ted Husted wrote: Assuming it was all right with everyone, I'm setting the freeze date for 1.2.0 for tomorrow (Saturday) night. I'm updating the release plan. There are still a lot of enhancement patches that we haven't applied, but I think those can wait for later in the 1.2.x series. I do intend to start marching down that list and either accepting or declining whatever patches people have submitted. So, I'm commenting out that section for the purpose of this release. All the other criteria have been met, and I believe we are ready to go. Martin, would you be able to take it from there, or is there any thing else I can do? Just a few things: * What about the new Apache license? Technically, it doesn't need to change if we release before March 1st, but we're mighty close to that, so perhaps we should switch now? * There was a brief discussion not too long ago about whether we should be building this release against released versions of Commons components or the nighlies. Since, in theory at least, this release could be promoted to a Final release, I assume the former? Several of the Commons components we depend on have released since we last did, so we may want to update the versions in our dependency list. * The Cactus tests won't run for me, for some reason. When I start the tests, everything looks fine as it starts up, but then it just sits there doing nothing. They used to work, but I can't recall what I might have changed to break it. Anyone have any ideas? Obviously, I don't want to create a release and not be able to run the tests! -- Martin Cooper -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]
Status of struts-examples
What is the current status of the combined struts-examples web app? I see that the config file references a CustomActionForward class, but no such class exists in CVS. Did the file not get added, or does the config file need updating to not refer to it? Also, there still seem to be pieces of the old apps around, but not enough for them to build. What still needs to happen before this is all in place, and we can put a 1.2.0 release together? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: string concatenation
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, February 15, 2004 11:46 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: RE: string concatenation Quoting Andrew Hill [EMAIL PROTECTED]: It seems like utter madness to me. Mad! Mad! I tell you! Half of commons was split off from struts originally anyhow, and now to go and say we dont want to depend on it, lets redevelop it yet again internally... WTF? Will we then see another cycle where the internally redevloped code is again split off to form a sort of neo-commons??? shakes head and sighs/ snip My preference would be for leveraging code that is in a logical place (ala commons-lang) and documenting the dependencies. /snip +1 -1. The commons-collections folks screwed much of the world (although not us, because we only depend on a couple of classes that weren't moved to new packages without backwards compatible deprecations) with their recent backwards incompatible changes. I'm not interested in supporting that behavior by continuing to depend on them. Put yourself in the position of a sysadmin for a Tomcat 5 installation where some webapps need the old version of commons-collections.jar and some need the new version. What are *you* going to do? Um, now I'm very confused. Craig, you are always espousing the advantages of - and even the necessity of - including all dependent jars in the web app itself. With this comment, you seem to be not only endorsing but supporting the reliance of web apps on shared jars provided by the container. In answer to your question above, wouldn't the answer be don't rely on the jars provided by the container, include the ones you need in your web app, as you used to espouse? Like I said, I'm confused now... -- Martin Cooper 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: Develop against released commons versions [WAS: RE: string concatenation]
On Mon, 16 Feb 2004, Ted Husted wrote: Yes, there lies the rub: If we were to submit a patch to commons-lang today, we could not roll a (potentially) GA-quality release tomorrow. At least not without also rolling a release of commons-lang and waiting for it to go platinum first. My suggestion would be that we start using bridge packages to isolate classes that we intend to submit to the Commons. Once the code in our bridge package proves it worth, we can then offer to the corresponding Commons package. If our code is accepted and the updated Commons package hits a General Availability release, we can then move our dependency from the bridge package to the Commons package. So, if we do determine that a change to the string handling is a difference that makes a difference, we could create a package for methods specifically earmarked for lang, such as o.a.s.commons.lang. Once we release our code, and find that it works well in the field, then we can submit a patch to c-l and roll a release there. Once the c-l is GA with our addition, then we can move the dependency in our on code from o.a.s.commons.lang to o.a.c.lang. +1 I like the bridge packages idea, because it makes it clear where our potential dependencies are, as well as how extensive they are. -- Martin Cooper This would similar to the approach we are trying with commons-resources: Release the code, copy the code, release the code again, *then* move the dependency. -Ted. On Mon, 16 Feb 2004 12:41:05 +0800, Andrew Hill wrote: snip Maybe now thats been done there should be a policy of only developing against release versions of commons code. /snip +1 This seems pretty sensible to me. Id suggest the committers seriously consider this idea. -Original Message- From: Niall Pemberton [mailto:[EMAIL PROTECTED] Sent: Monday, 16 February 2004 08:58 To: Struts Developers List Subject: Re: string concatenation I agree. I seem to recall there were problems releasing Struts 1.1 because of a hold up getting a commons component released that struts was depending on. That was understandable as various bits of struts were being moved over to commons at the time. Maybe now thats been done there should be a policy of only developing against release versions of commons code. That way commons doesn't become something Struts has to wait on and its being developed against stable fully tested commons components. Niall - Original Message - From: Hablutzel, Robert [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Struts Developers List [EMAIL PROTECTED] Sent: Monday, February 16, 2004 12:32 AM Subject: RE: string concatenation So I'm a bit of a lurker here, but I wanted to put in my $.02. I'd rather see a dependency on efficiently implemented code in a single place than either replicating the code or using a less efficient algorithm. Replication just means that bugs in the code aren't fixed in all places, adds confusion to users as to which version to leverage, and makes it harder to introduce possible future code improvements. Trading memory for speed can be a meaningless tradeoff in high-volume applications where the number of GCs visibly impacts overall system performance. My preference would be for leveraging code that is in a logical place (ala commons-lang) and documenting the dependencies. hab -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Sun 2/15/2004 4:21 PM To: Struts Developers List Cc: Subject: RE: string concatenation -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Sunday, February 15, 2004 1:01 PM To: Struts Developers List Subject: RE: string concatenation Struts has many dependencies already and I'd like to avoid adding one with lang. Why not just size a large StringBuffer and trade memory for speed? We already have a dependency on Lang, albeit indirectly, so why not take advantage of it? Frankly, I disagree with the push I see from some folks (including Craig on commons-dev recently) to reduce dependencies between components by duplicating functionality. The whole point of Commons is to avoid duplication, so why are people pushing back against using the successful components that we helped create here in Struts? -- Martin Cooper David --- Martin Cooper [EMAIL PROTECTED] wrote: Rather than add a new string utility class to Struts, which isn't really where it should belong, I think we'd be better off just using this: http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang /St ringUti ls.html#join(java.lang.Object[]) Alternatively, you could suggest (on the commons-dev list) adding a variation of your StringHolder class, based on the join() method above, to Commons
RE: string concatenation
-Original Message-
From: nishant kumar [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 15, 2004 9:15 AM
To: Struts Developers List
Subject: RE: string concatenation
hi,
if you look at the source code of the join method then you will find
that it is doing exactly what struts is currently doing, ie using
StringBuffer for concatenation and finally returning a string.
Then I suggest you propose a patch to join() on the commons-dev list, along
with tests and preferably benchmarks to demonstrate that your method is
truly faster.
as far as the packaging of the StringHolder class is
concerned, it is
not great a concern. only thing i wished to point out was that all the
html tags need a change in this direction. this will make them much
faster and this is really needed as these tags are quite often used.
Do you have actual benchmarks to show that it would make a significant
difference, or are you going on basis that this is obvious?
--
Martin Cooper
thanks,
nishant.
On Sun, 2004-02-15 at 07:41, Martin Cooper wrote:
Rather than add a new string utility class to Struts, which isn't really
where it should belong, I think we'd be better off just using this:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang
/StringUti
ls.html#join(java.lang.Object[])
Alternatively, you could suggest (on the commons-dev list) adding a
variation of your StringHolder class, based on the join()
method above, to
Commons Lang.
--
Martin Cooper
-Original Message-
From: nishant kumar [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 14, 2004 5:46 PM
To: [EMAIL PROTECTED]
Subject: string concatenation
hi,
I have a performance tuning suggestion which i think will greatly
impact the performance of struts html tags.
String concatenation using StringBuffer is definitely much
better than
using the plus operator but there are scenarios where there are much
better ways than using StringBuffers. Actually struts html
tags fall in
those scenarios.
So let me give you an example. this is the code from
renderFormStartElement method of FormTag.
StringBuffer results = new StringBuffer();
results.append(form);
results.append( name=\);
results.append(beanName);
results.append(\);
results.append( method=\);
results.append(method == null ? post : method);
results.append(\ action=\);
str = results.toString();
pageContext.getOut().write(str);
Now lets list the issues with this.
1. first presizing this buffer is quite difficult (avoided in this
case). here the buffer starts with size 16 and doubles each time the
size is exceeded. This causes unnecessary creation of new char arrays
and redundant copy of data whenever resizing happens.
2. whenever append is called data is copied from the passed string to
the end of stringbuffer.
3. finally the whole concatenated data is again copied into another
string.
4. and then in the end this string is written to a writer,
another copy,
which is the only copy required.
so even if you had presized the stringbuffer correctly, you
have copied
the same data thrice instead of just once. And you also create two NOT
needed objects.
so here is the solution i propose. have a class holding an array of
Strings and keep appending strings to this array and finally
print this
array to the writer. something like this.
private String[] data = new String[256];
private int size = 0;
public StringHolder append(String str){
ensureCapacity(this.size + 1);
this.data[this.size++] = str;
return this;
}
public void writeTo(Writer out) throws IOException{
for (int i = 0; i this.size; i++){
if (this.data[i] != null){
out.write(this.data[i]);
}
}
}
this way only the last copy takes place and you also avoid creating so
much garbage.
i have attached StringHolder class which does the above task and also
the FormTag after making necessary modification to fit in this class.
From the code of FormTag you can see that you need to make quite few
changes to get great benefit.
i have also attached a better implementation of
ResponseUtils.filter(String) method. the logic is on the same lines as
above.
thanks,
nishant
--
nishant kumar [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
RE: string concatenation
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 15, 2004 1:01 PM
To: Struts Developers List
Subject: RE: string concatenation
Struts has many dependencies already and I'd like to avoid adding one with
lang. Why not just size a large StringBuffer and trade memory for speed?
We already have a dependency on Lang, albeit indirectly, so why not take
advantage of it?
Frankly, I disagree with the push I see from some folks (including Craig on
commons-dev recently) to reduce dependencies between components by
duplicating functionality. The whole point of Commons is to avoid
duplication, so why are people pushing back against using the successful
components that we helped create here in Struts?
--
Martin Cooper
David
--- Martin Cooper [EMAIL PROTECTED] wrote:
Rather than add a new string utility class to Struts, which isn't really
where it should belong, I think we'd be better off just using this:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang
/StringUti
ls.html#join(java.lang.Object[])
Alternatively, you could suggest (on the commons-dev list) adding a
variation of your StringHolder class, based on the join() method above,
to
Commons Lang.
--
Martin Cooper
-Original Message-
From: nishant kumar [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 14, 2004 5:46 PM
To: [EMAIL PROTECTED]
Subject: string concatenation
hi,
I have a performance tuning suggestion which i think will greatly
impact the performance of struts html tags.
String concatenation using StringBuffer is definitely much
better than
using the plus operator but there are scenarios where there are much
better ways than using StringBuffers. Actually struts html tags fall
in
those scenarios.
So let me give you an example. this is the code from
renderFormStartElement method of FormTag.
StringBuffer results = new StringBuffer();
results.append(form);
results.append( name=\);
results.append(beanName);
results.append(\);
results.append( method=\);
results.append(method == null ? post : method);
results.append(\ action=\);
str = results.toString();
pageContext.getOut().write(str);
Now lets list the issues with this.
1. first presizing this buffer is quite difficult (avoided in this
case). here the buffer starts with size 16 and doubles each time the
size is exceeded. This causes unnecessary creation of new char arrays
and redundant copy of data whenever resizing happens.
2. whenever append is called data is copied from the passed string to
the end of stringbuffer.
3. finally the whole concatenated data is again copied into another
string.
4. and then in the end this string is written to a writer, another
copy,
which is the only copy required.
so even if you had presized the stringbuffer correctly, you have
copied
the same data thrice instead of just once. And you also create two NOT
needed objects.
so here is the solution i propose. have a class holding an array of
Strings and keep appending strings to this array and finally print
this
array to the writer. something like this.
private String[] data = new String[256];
private int size = 0;
public StringHolder append(String str){
ensureCapacity(this.size + 1);
this.data[this.size++] = str;
return this;
}
public void writeTo(Writer out) throws IOException{
for (int i = 0; i this.size; i++){
if (this.data[i] != null){
out.write(this.data[i]);
}
}
}
this way only the last copy takes place and you also avoid creating so
much garbage.
i have attached StringHolder class which does the above task and also
the FormTag after making necessary modification to fit in this class.
From the code of FormTag you can see that you need to make quite few
changes to get great benefit.
i have also attached a better implementation of
ResponseUtils.filter(String) method. the logic is on the same lines as
above.
thanks,
nishant
--
nishant kumar [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
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: [GUMP@lsd]: jakarta-struts/jakarta-struts failed
-Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Sunday, February 15, 2004 4:03 PM To: Struts Developers List Subject: Re: [EMAIL PROTECTED]: jakarta-struts/jakarta-struts failed Why are we (and others, commons, etc) getting this from lsd.student.utwente.nl? There is no Apache hardware (yet) for Gump runs. The lsd machine is one that Leo Simons has set up to run Gump and send the nag messages. There are plans to dedicate a machine to Gump once we get the hardware in place (which should be fairly soon). -- Martin Cooper -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Stefan Bodewig [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 15, 2004 5:58 AM Subject: [EMAIL PROTECTED]: jakarta-struts/jakarta-struts failed To whom it may engage... This is an automated request, but not an unsolicited one. For help understanding the request please visit http://jakarta.apache.org/gump/nagged.html and/or contact [EMAIL PROTECTED] Project jakarta-struts has an issue affecting it's community integration. This issue affects 5 projects. The current state is 'Failed', for reason Missing Build Outputs' Full details are available at: http://lsd.student.utwente.nl/gump/jakarta-struts/jakarta-struts.html, however some snippets follow: - - - - - -- -- G U M P Gump provided these annotations: - Info - Sole jar [/data/gump/jakarta-struts/dist/lib/struts.jar] identifier set to project name - Error - Failed with reason missing build outputs - Error - Missing License Output: /data/gump/jakarta-struts/LICENSE - Error - See Directory Listing Work for Missing Outputs - - - - - -- -- G U M P Gump performed this work: Work Name: build_jakarta-struts_jakarta-struts (Type: Build) State: Success Elapsed: 0 hours, 5 minutes, 35 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/data/gump/xml-xalan/java/bu ild/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build /xml-apis. jar:/data/gump/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dbuild.clonevm=true -Dgump.merge=/data/gump/gump/ work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/data/gump/ jakarta-commons/beanutils/dist/commons-beanutils.jar -Djdbc20ext.jar=/data/g ump/opt/jdbc2_0/jdbc2_0-stdext.jar -Dantlr.jar=/data/gump/opt/antlr-2.7.2/an tlr.jar -Dcommons-lang.jar=/data/gump/jakarta-commons/lang/dist/commons-lang -20040215.jar -Djakarta-oro.jar=/data/gump/jakarta-oro/jakarta-oro-20040215. jar -Djdk.version=1.4 -Dcommons-fileupload.jar=/data/gump/jakarta-commons/fi leupload/target/commons-fileupload-20040215.jar -Dcommons-validator.jar=/dat a/gump/jakarta-commons/validator/dist/commons-validator.jar -Dcommons-loggin g.jar=/data/gump/jakarta-commons/logging/dist/commons-logging.jar -Dcommons- digester.jar=/data/gump/jakarta-commons/digester/dist/commons-dige ster.jar - Dxerces.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar -Dcommons-colle ctions.jar=/data/gump/jakarta-commons/collections/build/commons-co llections- 20040215.jar -Dservlet.jar=/data/gump/jakarta-servletapi-4/lib/servlet.jar dist [Working Directory: /data/gump/jakarta-struts] - struts: [echo] Processing webapp examples static: [echo] Processing webapp examples compile: [echo] Processing webapp examples dist: [echo] Processing webapp examples [jar] Building jar: /data/gump/jakarta-struts/dist/webapps/struts-examples.war init: [echo] Processing webapp tiles-documentation prepare: [echo] Processing webapp tiles-documentation source: [echo] Processing webapp tiles-documentation libs: struts: [echo] Processing webapp tiles-documentation static: [echo] Processing webapp tiles-documentation compile: [echo] Processing webapp tiles-documentation dist: [echo] Processing webapp tiles-documentation [jar] Building jar: /data/gump/jakarta-struts/dist/webapps/tiles-documentation.war dist: dist.source: [copy] Copying 1 file to /data/gump/jakarta-struts/dist [copy] Copying 1 file to /data/gump/jakarta-struts/dist [copy] Copying 1 file to /data/gump/jakarta-struts/dist dist.contrib: dist: BUILD SUCCESSFUL Total time: 5 minutes 30 seconds - Work Name: list_repo_jakarta-struts (Type: Document) State: Success Elapsed: 0 hours, 0 minutes, 7 seconds Command Line: ls -l /data/gump/log/jars/jakarta-struts/jars - total 502 -rw-rw-r--1 ajackgump 510811 Feb 15 05:07 struts.jar
RE: string concatenation
Rather than add a new string utility class to Struts, which isn't really
where it should belong, I think we'd be better off just using this:
http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/StringUti
ls.html#join(java.lang.Object[])
Alternatively, you could suggest (on the commons-dev list) adding a
variation of your StringHolder class, based on the join() method above, to
Commons Lang.
--
Martin Cooper
-Original Message-
From: nishant kumar [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 14, 2004 5:46 PM
To: [EMAIL PROTECTED]
Subject: string concatenation
hi,
I have a performance tuning suggestion which i think will greatly
impact the performance of struts html tags.
String concatenation using StringBuffer is definitely much
better than
using the plus operator but there are scenarios where there are much
better ways than using StringBuffers. Actually struts html tags fall in
those scenarios.
So let me give you an example. this is the code from
renderFormStartElement method of FormTag.
StringBuffer results = new StringBuffer();
results.append(form);
results.append( name=\);
results.append(beanName);
results.append(\);
results.append( method=\);
results.append(method == null ? post : method);
results.append(\ action=\);
str = results.toString();
pageContext.getOut().write(str);
Now lets list the issues with this.
1. first presizing this buffer is quite difficult (avoided in this
case). here the buffer starts with size 16 and doubles each time the
size is exceeded. This causes unnecessary creation of new char arrays
and redundant copy of data whenever resizing happens.
2. whenever append is called data is copied from the passed string to
the end of stringbuffer.
3. finally the whole concatenated data is again copied into another
string.
4. and then in the end this string is written to a writer, another copy,
which is the only copy required.
so even if you had presized the stringbuffer correctly, you have copied
the same data thrice instead of just once. And you also create two NOT
needed objects.
so here is the solution i propose. have a class holding an array of
Strings and keep appending strings to this array and finally print this
array to the writer. something like this.
private String[] data = new String[256];
private int size = 0;
public StringHolder append(String str){
ensureCapacity(this.size + 1);
this.data[this.size++] = str;
return this;
}
public void writeTo(Writer out) throws IOException{
for (int i = 0; i this.size; i++){
if (this.data[i] != null){
out.write(this.data[i]);
}
}
}
this way only the last copy takes place and you also avoid creating so
much garbage.
i have attached StringHolder class which does the above task and also
the FormTag after making necessary modification to fit in this class.
From the code of FormTag you can see that you need to make quite few
changes to get great benefit.
i have also attached a better implementation of
ResponseUtils.filter(String) method. the logic is on the same lines as
above.
thanks,
nishant
--
nishant kumar [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Browser-specific attrs for html tags (was: [Bug 26795])
On Mon, 9 Feb 2004, Hubert Rabago wrote: This probably won't be the last request for an attribute which turns out to be browser specific. Perhaps the html taglib can include some mechanism to allow developers to add other attributes. There *are* times when it makes sense to use browser-specific extensions. Some applications, for instance, are targetted to specific browsers (like intranet apps). Some apps require functionality which would dictate the use of such features. By requiring tag subclasses, Struts doesn't make it easy to take advantage of browser-specific features. While the html taglib shouldn't include every attribute of every tag of every browser on the face of the planet, perhaps some generic way of adding attributes might be acceptable. something like html:sometag custom=browserspecific1=value1 browserspecific2=\value 2\/ If you check the archives, you'll find that there has been considerable discussion on this in the past, and that I vetoed it in the past. I will continue to veto a change such as this, or the alternative below for the same reasons - we support HTML 4.01 attributes, no more, and no less. -- Martin Cooper ...or args= / attrs= / whatever that the html:tag can render as-is. Another option would be: html:sometag ... html:attr name=browserspecific1 value=value1/ html:attr name=browserspecific2 value=value 2/ /html:sometag ...though the code to implement this might require some considerable refactoring of the existing tag classes. - Hubert --- [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26795. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26795 adding href to html:button tag [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-02-09 16:41 --- By design, Struts tags only emit valid HTML 4.01. According to the spec, 'href' is not a valid attribute of BUTTON. http://www.w3.org/TR/REC-html40/interact/forms.html#edef-BUTTON Nothing stopping you from subclassing the tag and adding another property though! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - 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: Browser-specific attrs for html tags (was: [Bug 26795])
On Mon, 9 Feb 2004, David Graham wrote: --- Joe Germuska [EMAIL PROTECTED] wrote: At 9:28 AM -0800 2/9/04, Hubert Rabago wrote: This probably won't be the last request for an attribute which turns out to be browser specific. Perhaps the html taglib can include some mechanism to allow developers to add other attributes. You can always subclass the tag and change the TLD file. This seems like a much simpler solution to me. +1 And for the record I am a big -1 on changing Struts tags to support non-standard HTML. IMO, if you want to support just IE (which is invariably the cause for these type of requests), you shouldn't get any help from Struts. +1. Or is that -1. How does one support a -1? ;-) For once, I agree with you seems to be a somewhat more concise way of saying what I mean. :-) -- Martin Cooper David Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html - 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: Clean Up conf/share
On Wed, 4 Feb 2004, [EMAIL PROTECTED] wrote: Is there any reason we can't delete: struts-config_1_0.dtd -- Users should upgrade to at least Struts 1_1 dtd Yes, they should, but we still support config files with the 1.0 format. Are you suggesting we remove that support? I'm not so sure I'd agree with that, as it forces everyone to convert their config files, which may well be quite an onerous task for a large application that otherwise has no reason to change (but which wants to pick up bug fixes in later versions of Struts). tiles-config.dtd -- This is for pre struts tiles. OK. validation_1_1.dtd -- This moved to commons-validator pre struts 1.1 validator-rules_1_1.dtd -- This moved to commons-validator pre struts 1.1 Same comment as for the Struts config files, above. web-app_2_2.dtd -- Don't know why we carry around web-app dtd's web-app_2_3.dtd Struts parses these files, and wants to do a validating parse. We need local copies so that we're not forced to retrieve them across the net. -- Martin Cooper -Rob - 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: DO NOT REPLY [Bug 26647] New: - srcKey in html:img/ tag needs matching size keys.
On Tue, 3 Feb 2004, Paul Sundling wrote: Joe Germuska wrote: At 1:36 PM +1300 2/4/04, [EMAIL PROTECTED] wrote: Quoting Paul Sundling [EMAIL PROTECTED]: I originally thought it said html:image instead of html:img . I noticed that html:image does not have height and width. When I look at my HTML Pocket Reference, I see only align, src and name listed for input type=image..., but from testing I know that height and width work for that tag in both mozilla and IE. Would it be worth adding height and width to the html:image tag? Just as a matter of note, height and width should work with Netscape 4+ IE 4+ for input type=image. Looks like your pocket reference skimped on the details :) In terms of adding the two attributes to the html:image tag, I personally think it would make a useful addition... height and width are not valid attributes of the input tag: see http://www.w3.org/TR/html401/interact/forms.html#h-17.4 Joe I can't say I'm surprised to hear that since it wasn't in my little book. At the same time, if a given attribute is not part of the official W3C HTML spec, does that mean we shouldn't support the feature if there is browser support for it? This is more a philosophical issue on wether you're supporting the HTML standard, or the browser implementations of the standard. Is there a project stance on that? Yes, there is. We currently support what's in the HTML 4.01 standard, no more and no less. -- Martin Cooper Two main browsers since version 4 is pretty good support. If it's supported even in Safari and Opera or other, less common browsers, then I would say that's wide enough browser support to definitely consider. Of course, that's irrelevant if we're coding to spec and not implementation. Paul - 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: [18111] et al
Joe Germuska [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] At 11:37 PM -0500 1/19/04, Ted Husted wrote: In reference to http://issues.apache.org/bugzilla/show_bug.cgi?id=18111 which I also gathered under http://issues.apache.org/bugzilla/show_bug.cgi?id=25855. The suggestion is to add contextRelative to rewrite, as we just did for img. The usecase being the sharing of common resources between modules. Since rewrite extends link, I'm tempted to put the contextRelative code into link. This change would seem to allow direct links between modules. I don't remember if we discussed that before or not, so wanted to send up a flare before proceeding. The one other remaining task is a fixing the pagePattern for img http://issues.apache.org/bugzilla/show_bug.cgi?id=23127. If we decide to allow contextRelative links, as a refactoring, I may try a base PathTag to encapsulate the contextRelative and pagePattern code. Link, Rewrite, Img and so forth, can then extend PathTag. These two tasks (#18111 and #23127) could conceivably be wrapped up tomorrow, meaning we could roll 1.2.0 this weekend, if that sounds all right. :) I can't think of any reason to block direct links between modules; I can't speak for others, but our use cases for modules turn out to be much less strictly segregated than was apparently the intent of the original design, given how complicated certain things turn out to be. The original intent of the current module design was to provide an alternative way of handling multiple independent Struts apps in the same web app. No more, no less. It was intentionally limited, so that we could gain some experience with how people would want to use it, with the understanding that we could build on that in later releases. There are certainly many, many things that people might want to do with their apps that might be usefully handled by extensions to our current module concept. However, there are also many, many ways in which we could extend the module concept. Jumping around between modules arbitrarily *might* be useful to some people in extending what they can do with modules today, but at the same time, it might also allow ways of circumventing structure that other people want to impose on modules. In other words, I *can* think of reasons to block direct links between modules, and I wouldn't want to see that enabled as a standard feature. Making it optional / configurable might be a viable alternative, at least for now, if other people really feel a need for this feature in 1.2.0. -- Martin Cooper I can use context-relative html:rewrite as soon as you check it in -- I was just wrestling with its absence last night. Also, I would argue that the switch action is too much overhead for its own good -- and your proposed change would allow us to skip it also. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @author tags in Struts code
On Fri, 9 Jan 2004, Paul Sundling wrote: That means a lot coming from you Craig! I want to get some feedback on some other changes I'd like to suggest: on http://jakarta.apache.org/struts/volunteers.html (volunteer.xml) the current section order is: Source Code Contributers Documentation Contributers Active Committers Emeritus Committers how about reordering the sections to Active Committers Emeritus Committers Source Code Contributers Documentation Contributers I don't know if there's already some other convention on that, but developers are listed before contributers in project.xml, so it seems like a logical ordering. It also highlights those first who made very important contributions. I'm not sure how the list originally got into the order it is in today, but I have a theory. ;-) If we put non-committers first, it might give newcomers more visibility, encouraging them to keep contributing, and eventually, perhaps, become committers. Also, since emeritus committers are not really around Struts any more, it kinda makes sense for them to be at the bottom of the page. That said, however, I don't have a problem with changing the order as you describe. I noticed that a couple of active committers were not listed in the source code contributers! That will be fixed when I update the list. This includes James Mitchell, Joe Germuska and David M. Karr.*** I have a theory about how this happened as well. ;-) We have not always been prompt and religious about updating the lists, but I suspect we've always added new committers fairly promptly. Hence the names listed in the committers list who are not listed elsewhere. On the other hand, I'm not sure how important it is for committers to be also listed as source and/or documentation contributors, since it's sort of assumed. Those who are listed as both probably got there by being added to the contributors list prior to becoming committers, rather than the other way around. ;-) But again, I have no objection to ensuring that all of the committers are also listed as contributors. *I'm grabbing all the author tags under /src. Should the same be done under contrib as well? The scope of files involved in src is already several hundred, so If that's required I'll do that seperately as a seperate item. Ultimately, yes, I think authors of code under contrib should be recognised in the same way as authors in the rest of the code base. We have, after all, accepted the code into the Struts repo, even if not (yet) into the core itself. But, as we say here, it's your itch, so however you wish to scratch it - or not - is entirely up to you. (Which is just another way of saying feel free to do this however you want, or not at all.) I think it would be good to mention the new policy on @author tags and that we're including people on the volunteer page in the documentation on how to help. Anyone have some good wording for that? Not off the top of my head, but I agree it's a good idea. -- Martin Cooper Paul Sundling Craig R. McClanahan wrote: Quoting Paul Sundling [EMAIL PROTECTED]: If the group was interested in removing all author tags and consolidating all the names onto volunteer.html I would be willing to make a tar of patches or whatever format is most convenient. If you're interested, let me know if that would be useful and I'll try to give you 24 hour or less tournaround time. I'd probably have to ask for couple questions and then I'd submit it through bugzilla. It's in the realm of busy work, but I'm very detail oriented and pretty good with a CLI. :) +1 on such a patch, attached to a Bugzilla ticket in cvs diff -u format as David pointed out. Ironically, this would definitely count as enough work to get you added to the contributor list if you are not already :-). Paul Sundling Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/tiles-documentation/examples/tiles footer.jsp
Is there a reason for removing Cedric's copyright? As I understand it, based on the language in the CLA, Cedric is entitled to keep his own copyright there, if he so desires. -- Martin Cooper On Wed, 7 Jan 2004 [EMAIL PROTECTED] wrote: rleland 2004/01/07 13:14:40 Modified:web/tiles-documentation/common footer.jsp web/tiles-documentation/examples/tiles footer.jsp Log: remove Cerdics personal Copyright and leave only Apache Copyright Revision ChangesPath 1.3 +1 -3 jakarta-struts/web/tiles-documentation/common/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/common/footer.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- footer.jsp 29 Dec 2002 21:20:52 - 1.2 +++ footer.jsp 7 Jan 2004 21:14:40 - 1.3 @@ -2,9 +2,7 @@ div align=center font color=#023264 size=-1 -em Copyright copy; 2000-2003, Apache Software Foundation /em - br -emand Cedric Dumoulin/em +em Copyright copy; 2000-2004, Apache Software Foundation /em /font /div html:img page=/images/struts-power.gif align=right border=0/ 1.2 +0 -2 jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp Index: footer.jsp === RCS file: /home/cvs/jakarta-struts/web/tiles-documentation/examples/tiles/footer.jsp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- footer.jsp 6 Jul 2002 01:13:50 - 1.1 +++ footer.jsp 7 Jan 2004 21:14:40 - 1.2 @@ -2,8 +2,6 @@ div align=center font color=#023264 size=-1 em Copyright copy; 2001, Apache Software Foundation /em - br -emand Cedric Dumoulin/em /font /div img src=%=request.getContextPath()%/images/struts-power.gif align=right border=0 - 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: tinyurl.com [was: Re: cvs commit: jakarta-stru...]
On Thu, 1 Jan 2004, James Mitchell wrote: Maybe its just me or I'm missing something here, but do we have to use tinyurl.com? I'm not sure I like the idea of relying on a 3rd party for web resource address translation. If continue using this service and something happened and tinyurl.com was not available, we would lose many valuable references such as the one below. Perhaps we could utilize some other means of shortening long URLs, or at least something we have more control over. Your thoughts? I agree. I've been seeing a lot of these tinyurl links in mail messages recently (mostly from Ted, I think ;) and thinking about what we could do to remove the need for them. (They're very handy, there's no doubt about that.) In addition to what you mention above, one other thing that bothers me about them is that you have no indication of where you're going when you follow one. It could be on the Apache site, but it could be anywhere, and you don't know until you get there. So, I'm thinking about proposing to the infrastructure folks that we run a tinyurl work-alike at Apache. There are quite a lot of these around now - see http://notlong.com/links/ - but I don't know if any of them are open source. If not, I might have to write one, but it shouldn't be that hard. Comments? -- Martin Cooper On Thu, 1 Jan 2004 [EMAIL PROTECTED] wrote: husted 2004/01/01 14:39:59 Modified:src/share/org/apache/struts/taglib/bean WriteTag.java Log: Add notes regarding discovering localized notations, per research by Jason Lea. Revision ChangesPath 1.31 +12 -5 jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java Index: WriteTag.java === RCS file: /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- WriteTag.java 1 Jan 2004 19:27:19 - 1.30 +++ WriteTag.java 1 Jan 2004 22:39:59 - 1.31 @@ -316,7 +316,14 @@ /** * Format value according to specified format string (as tag attribute or * as string from message resources) or to current user locale. - * + * + * When a format string is retrieved from the message resources, + * codeapplyLocalizedPattern/code is used. For more about localized + * patterns, see http://tinyurl.com/33y54. (To obtain the correct + * value for some characters, you may need to view the file in a + * hex editor and then use the Unicode escape form in the + * property resources file.) + * * @param valueToFormat value to process and convert to String * @exception JspException if a JSP exception has occurred */ - 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: Unable to compile the source.
It looks to me like there's a problem with whatever JSP jar you're compiling against, given the complaints about JspException not being public. You might want to pick up a servlet/jsp jar from Tomcat or elsewhere and compile against that. (On the other hand, if you're compiling against your container now, you may have problems even after Struts compiles successfully.) -- Martin Cooper On Thu, 1 Jan 2004, Anand Stephen wrote: Greetings, Wish you all a very happy new year! I am trying to compile the latest source of struts I have attached the error log. Any help would be appreciated, -anand --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
Off the top of my head (meaning I haven't thought through all of the
possible ramifications yet ;), I like this idea. I know that when I added
factories to Commons FileUpload, it took the ability to customise things
to a level that just isn't possible with straight 'new' coding. I can see
how the same would be true for Actions as well.
I'm not sure about the specific API you suggest. I assume by default you
mean the non-dyna flavour? Something about the API doesn't feel right,
but I'll try to give it some thought later and see if I can come up with
anything better.
BTW, I assume you're proposing this as a post-1.2.0 change?
--
Martin Cooper
On Fri, 2 Jan 2004, Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms. The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.
Why would you want to plug in your own ActionFactory? My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts. By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need. Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime. Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.
Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.
Configuration: I'd recommend another attribute in the controller /
element in struts-config, possibily named actionFactoryClass, pointing
to the new ActionFactory implementation to use. If none specified, a
default factory which mimics current behavior would be used.
This is my proposed interface:
public interface ActionFactory {
public Action createAction(ActionServlet servlet);
public DynaActionForm createDynaActionForm(ActionServlet servlet,
FormBeanConfig config,
ActionConfig mapping);
public ActionForm createDefaultActionForm(ActionServlet,
FormBeanConfig config);
public ActionForm createActionForm(ActionServlet servlet,
FormBeanConfig config,
ActionConfig mapping);
}
Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.
Comments? Obviously, I'd perform the refactorings if this feature was
agreed upon. Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
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: Configuring tags from bean properties - Bugzilla 25671
The lack of response is probably a good indication that none of the
committers find this enhancement sufficiently compelling that they would
add it to the core of Struts. Certainly that is my own reaction.
For example, a couple of things that occured to me were: Why does this
need to be based on the Struts tags at all? Why use a bean instead of a
map?
For your purposes, it would seem that you would likely be better off with
a single tag that you would use like this:
input type=text tl:splatAttributes map=${foo}/
Again, though, this isn't something I would want to see as part of Struts.
(But other committers may feel differently, of course.)
--
Martin Cooper
On Wed, 31 Dec 2003, Hablutzel, Robert wrote:
I haven't heard any response to this enhancement request. To recap,. the
idea is to add the ability for the html tags to be configured via a
supplied bean - the properties on the bean corresponding to the
properties on the tag. For example, the html:base tag would be
extended to accept an attribute bean. That bean would be a Java Bean
that (potentially) contained the properties target and server just
as the html:base tag takes attributes target and server. If
available and supplied, the tag would take the values from the
corresponding properties on the beans. Generic get methods (e.g. get(
String name )) could also be supported - if get( server ) return
not-null in this example, then the value would be used.
I'm willing to look at making the changes - but I hadn't heard any
reaction to the proposal. If the changes were made, would they be
accepted?
hab
--
Bob Hablutzel Market Architect Liberty Mutual Group
EITS/Personal Markets
603 245-9485[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: add to CVS avail list?
On Wed, 24 Dec 2003, Joe Germuska wrote: So, just to dip my toe in, I tried to commit a change to volunteers.xml and got this message: % cvs commit -m add my name, test my CVS write access! xdocs/volunteers.xml cvs [server aborted]: commit requires write access to the repository Can someone with the power add me to the list? I just checked, and you do have karma to the jakarta-struts repo. Make sure you're using a tree checked out using your Apache account, and not using anonymous access. See the CVS guide for details: http://www.apache.org/dev/contributors.html#cvsbasics -- Martin Cooper Thanks Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 1.2.0 Release Plan
I haven't had a chance to catch up completely, but the outage this weekend suggests an after-Christmas 1.2.0 release, unfortunately - at least, if I need to be involved. (If not, great - go for it!) -- Martin Cooper On Sun, 21 Dec 2003, Ted Husted wrote: OK, here's what we have * Release notes updated * Issues w/o solutions marked LATER * Webapps tested on TC 4.1 (one issue) * JUnit tests run In the Validator example, we're suppose to be able to change selected validations for a county just by overriding a form in a formset. This doesn't work unless you respecify the entire formset. I fixed the example, but we should decide if this is suppose to be a supported feature or not. Here's what we don't have * Webapps tests on TC 3.3a (next) * Patches/fixes applied for 11 issues http://tinyurl.com/ysx3x * Cactus tests run (under Ant) I can't get Cactus running under Ant either, though Joe says they run under Maven. If the Cactus tests are truly broken under Ant: Do we want to call that a showstopper? If so, do we want to workaround that by taking the Cactus tests out of the buildfile for now, as we are moving to Maven anyway, and have Joe apply his Maven-Cactus patch. I could apply the patches sometime this week, but I'm leary of doing so when I can't get the Cactus tests to run on my own. If we resolve the Cactus thing quickly, do we want to release what we have as 1.2.0 (w/o the 11 patches), with the intention of rolling 1.2.1 in January, or wait and do this after Christmas? -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: Ideia
On Thu, 18 Dec 2003 [EMAIL PROTECTED] wrote: We could use those suggested action-forward parameters to configure the Tiles Framework. Instead of creating one definition for each page, the forward mappping parameter could be used to configure the definition parameters. Creating one definition of each target is hard work (this is true when using extension too), because most of pages of a module works on the same page layout. It's not hard work at all if you make use of 'extends'. ;-) -- Martin Cooper If this can't be done, we could use the last word of the definition name to denote the value of a 'special' parameter, such as body. For example: .common.client.showClient.jsp - could configure the 'body' property of the '.common.client' definition. Stutz - 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 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
On Wed, 17 Dec 2003, Don Brown wrote: Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x release work. :) I'll throw out some ideas here, then develop them later in the wiki: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. I'm a little hesitant to start depending on other frameworks. It's not that I think they don't have anything to offer us, it's just what it does to the newcomer to Struts. If someone has to learn Struts *and* Spring (for example) to get going, then we've set the bar much higher. If we do end up deciding to depend on something like this, I believe we'll need to put in the work to make it look like Struts. Taking Spring as an example again, the substantial difference in the character of the XML config files would easily confuse a newcomer trying to get his/her head around the syntax. If we could make those files look like Struts config files (or vice versa, for that matter), that would help, though. -- Martin Cooper - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. - Also, again totally agreeing with Ted, make everything interface based, have default implementations, and free apps of HTTP. Ideally, I'd like to see extra effort going into making it easy if not effortless to take a Struts 2.0 app and use the code in a portlet or web service environment. At least in my area, clients are wanting human and machine interfaces, with the human interface generally being behind a portal. Anyways, those are my brainstorming thoughts. If any look interesting, I'll write something up in the wiki. 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: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
On Thu, 18 Dec 2003, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: Just to add a few more off the top of my head: * Make the Struts core independent of the Servlets spec and the Portlets spec, so that it can be used for both, and more. * Separate view-technology-specific code into separate components, so that the core is view-technology agnostic. So, for example, all JSP specific code, including all of the taglibs, would move to a JSP component. * Rework Tiles into two facets, so that the core is independent of the Servlets spec and JSP, and the JSP component is part of the view specific component described above. * Split out file upload handling into a separate pluggable component, with its own configuration. I noticed that this is still in the initial Jericho DTD, but I think it should not be. The file upload implementation is pluggable, and so should be able to have its own config definition. I know I have more in notes at home, but just wanted to throw these out. A sort of meta-question: When is Struts no longer Struts? I mean, how much change can we introduce in Struts 2.0 before it becomes so different that it's really a different framework? Do we need to decide on what Struts is, and is not, before we go too far down the path of Struts 2.0? Or do we let whatever falls out just fall out and deal with it later? Product names are marketing, not technology. Struts 2.0 will be Struts if *we* call it Struts :-). More seriously, the amount of change between major product versions can be pretty enormous in some cases (ask classic ASP developers if they think ASP.NET is really the same environment or not). Innovation and revolution are perfectly fine things to do (applying all the lessons we've learned along the way), but we should also remember that there are thousands of apps based on a Struts 1.x architecture that need continuing support. We need to have the discipline to continue to work evolving a 1.2.x world while we're creating a new 2.x one. I think I need to elaborate on my thoughts some more, since I wasn't really clear the first time around... A great deal has happened in web application framework land since Struts came along 3-1/2 years ago. There is a boatload of frameworks out there now, and some of them have some great ideas. What I don't really want to end up with is a Struts 2.0 that is simply a reinvention of what other people have done, with a compatibility layer to make it accessible to Struts 1.x developers. So, what makes Struts Struts? What characteristics do we need to preserve in order to keep it Struts, and retain the greatness that has made it so amazingly popular? How far can we go before the decision to choose Struts 2.0, or not, is no different to a potential developer than the decision to chose any one of the other frameworks out there today? Obviously, compatibility is going to be very important, but I hope that's not all! Regarding 2.x, an important consideration will be base technology platforms -- I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e. Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the presentation technology, etc.). +1 to a J2EE baseline. -- Martin Cooper -- Martin Cooper Craig On Wed, 17 Dec 2003, Don Brown wrote: Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x release work. :) I'll throw out some ideas here, then develop them later in the wiki: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. - Also, again totally agreeing with Ted, make everything interface based, have default implementations, and free apps of HTTP. Ideally, I'd like to see extra effort going into making it easy if not effortless to take a Struts 2.0 app and use the code
Re: Struts 2.0 Discussion Forum
On Wed, 17 Dec 2003, Don Brown wrote:
Is there one? I have several ideas I'd like to toss into the discussion.
Yep. This is it.
--
Martin Cooper
Don
On 17 Dec 2003 [EMAIL PROTECTED] wrote:
husted 2003/12/17 12:49:28
Added: contrib/struts-jericho README.txt project.properties
project.xml
Log:
Create whiteboard directory for Struts-Jericho, a working proposal for Struts
2.x.
Revision ChangesPath
1.1 jakarta-struts/contrib/struts-jericho/README.txt
Index: README.txt
===
Jericho is a whiteboard proposal describing one possible implementation of
Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to assign a
codename to a proposal until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls within
the Struts architecture. Jericho proposes to open-up Struts by
* Declaring interfaces for all core components.
* Providing working base implementations for all core components.
* Encapsulating alll path references within Location objects (fka
ActionForwards)and referring only to Locations from all other objects.
* Providing additional extension points from core components so that the
Inversion of Control pattern is fully realized.
* Providing POJO signatures that encapsulate HTTP classes so that applications
can be freed of HTTP semantics, if so desired.
* Retain optional access to HTTP objects so that applications can be free to do
whatever they need to do.
-Backward Compatibility-
Jericho is a revolution and backward compatability with prior versions of Struts
is not the prime consideration. However, care is being taken to create a clear
migration path, where practible, so that Jericho is available to the widest
community possible.
_DTD._ The Jericho Configuration file (DTD) builds on the best aspects of the
Struts 1.2 DTD. The elements are different but still similar. Our goal is to allow
a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.
A second alternative to explore is to provide an alternate configuration loader
that would map the Struts 1.2 elements to Struts Jericho objects at initialization.
_Base Classes._ New base classes for Struts 1.2.x ActionForms and Actions are to
provided. These classes will provide the Struts 1.2.x behavior but also implement
the Struts Jericho interfaces, so that the framework can use them interchangeably.
These same techniques may be applied to provide adaptors for other frameworks,
so as to make Struts Jericho available to the widest community possible.
###
1.1 jakarta-struts/contrib/struts-jericho/project.properties
Index: project.properties
===
# ---
# P R O J E C T P R O P E R T I E S
# ---
compile.debug = on
compile.optimize = off
compile.deprecation = off
maven.linkcheck.enable=true
# documentation properties
maven.xdoc.date=left
maven.xdoc.version=${pom.currentVersion}
maven.xdoc.developmentProcessUrl=http://jakarta.apache.org/struts/status.html
1.1 jakarta-struts/contrib/struts-jericho/project.xml
Index: project.xml
===
?xml version=1.0 encoding=UTF-8?
project
extend../project.xml/extend
nameJericho/name
idstruts-jericho/id
currentVersion0.1-dev/currentVersion
inceptionYear2003/inceptionYear
shortDescriptionStruts Jericho 2.x Whiteboard/shortDescription
description
Jericho is a whiteboard proposal describing one possible implementation of
Struts 2.x.
Since Struts 2.x is slated as a revolution, the Apache practice is to
assign a codename to a proposal
until the Community comes to a consensus.
This proposal is called Jericho since it tries to tear-down the walls
within the Struts architecture.
/description
developers
developer
nameTed Husted/name
idhusted/id
email[EMAIL PROTECTED]/email
organization/organization
/developer
/developers
build
unitTest
includes
include**/*Test.java/include
/includes
/unitTest
/build
/project
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Just to add a few more off the top of my head: * Make the Struts core independent of the Servlets spec and the Portlets spec, so that it can be used for both, and more. * Separate view-technology-specific code into separate components, so that the core is view-technology agnostic. So, for example, all JSP specific code, including all of the taglibs, would move to a JSP component. * Rework Tiles into two facets, so that the core is independent of the Servlets spec and JSP, and the JSP component is part of the view specific component described above. * Split out file upload handling into a separate pluggable component, with its own configuration. I noticed that this is still in the initial Jericho DTD, but I think it should not be. The file upload implementation is pluggable, and so should be able to have its own config definition. I know I have more in notes at home, but just wanted to throw these out. A sort of meta-question: When is Struts no longer Struts? I mean, how much change can we introduce in Struts 2.0 before it becomes so different that it's really a different framework? Do we need to decide on what Struts is, and is not, before we go too far down the path of Struts 2.0? Or do we let whatever falls out just fall out and deal with it later? -- Martin Cooper On Wed, 17 Dec 2003, Don Brown wrote: Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x release work. :) I'll throw out some ideas here, then develop them later in the wiki: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. - Also, again totally agreeing with Ted, make everything interface based, have default implementations, and free apps of HTTP. Ideally, I'd like to see extra effort going into making it easy if not effortless to take a Struts 2.0 app and use the code in a portlet or web service environment. At least in my area, clients are wanting human and machine interfaces, with the human interface generally being behind a portal. Anyways, those are my brainstorming thoughts. If any look interesting, I'll write something up in the wiki. 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: [VOTE] 1.2.0 Release Plan
+1 I've added myself as an RM, since I'll be available to help. I can take on the tag, roll, sign and announce part, if you like. One thing I'd like to point out, because it came up in Commons, is that the HTTPD process and the Jakarta process are not 100% compatible. In particular, the Jakarta rules require a vote, while the HTTPD rules do not. I suspect that this vote may be sufficient, but I'll check when I get a chance. -- Martin Cooper On Tue, 16 Dec 2003, Ted Husted wrote: I've amended the date on the (now venerable) 1.2.0 release plan for this weekend. http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html I believe the release notes are in good shape now. I already marched through most of the stale 1.0/1.1 tickets, and can mop up the rest in short order. I imagine there will be a few patches that we can apply, but I've carved out some time to work on such. Note that I've left room in the release plan for the idea of multiple managers. If someone were up for sheparding the tests, especially the example application testing, I'd welcome the help. Someone else could also sign up for the final tag, roll, and announce part of the job. Of course, if everyone is busy, I'll be happy to muddle through on my own. :) Since this is a x.0 release, the plan calls for a majority vote. Here's my +1 -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: [VOTE] 1.2.0 Release Plan
The issue isn't so much with voting on the relesae plan, but voting on the release itself. As you say, the HTTPD rules say that anyone can create a release. We're not HTTPD, though, and the Jakarta rules are different. As long as we're part of Jakarta, we need to abide by the Jakarta rules. Under Decision Making, in the section on Release Testing, is the following statement: Majority approval is required before the release can be made. http://jakarta.apache.org/site/decisions.html So, we do need to vote on each and every release. -- Martin Cooper On Tue, 16 Dec 2003, Ted Husted wrote: With this proposal, I took a middle ground. The initial minor release (x.x.0) in a series called for a vote on a plan, but a plan would be optional for additional releases in the same series (1.2.1, 1.2.2, ...). So, we wouldn't have to vote on a plan again until we get to 1.3.0 or 2.0.0. The rationale is that starting a new series (1.2.0 versus 1.1.0) is a decision upon which we should have a formal consensus. After that, issuing additional point releases in the same series can be business as usual . Of course, this is just a vote on the plan. Once we roll the release, there would be another vote on whether to take that specific entity from Alpha to Beta and/or General Availability. (Though, personally, I prefer the more common stable designation to GA.) Of course, as the HTTPD guidelines point out, under the Apache License, anyone can distribute a release of our codebase. It's just a matter of whether it can be called Struts or not. :) -Ted, Martin Cooper wrote: +1 I've added myself as an RM, since I'll be available to help. I can take on the tag, roll, sign and announce part, if you like. One thing I'd like to point out, because it came up in Commons, is that the HTTPD process and the Jakarta process are not 100% compatible. In particular, the Jakarta rules require a vote, while the HTTPD rules do not. I suspect that this vote may be sufficient, but I'll check when I get a chance. -- Martin Cooper On Tue, 16 Dec 2003, Ted Husted wrote: I've amended the date on the (now venerable) 1.2.0 release plan for this weekend. http://jakarta.apache.org/struts/proposals/release-plan_1_2_0.html I believe the release notes are in good shape now. I already marched through most of the stale 1.0/1.1 tickets, and can mop up the rest in short order. I imagine there will be a few patches that we can apply, but I've carved out some time to work on such. Note that I've left room in the release plan for the idea of multiple managers. If someone were up for sheparding the tests, especially the example application testing, I'd welcome the help. Someone else could also sign up for the final tag, roll, and announce part of the job. Of course, if everyone is busy, I'll be happy to muddle through on my own. :) Since this is a x.0 release, the plan calls for a majority vote. Here's my +1 -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test Case Exception Throwing style (Re: Cactus tests)
On Thu, 11 Dec 2003, Ted Husted wrote: James Mitchell wrote: So, for now I just commented out those few lines and now the tests pass completely under tomcat 4.0, but under 4.1 it fails randomly with: Personally, I am in favor of dropping the tests for TC4.0 and only testing against Tomcat 3.3 and Tomcat 4.1, which are the reigning Reference Implementations for Servlet 2.2/2.3. Even Tomcat itself has relegated 4.0 to the archives. I'd be +0 on dropping Tomcat 4.0 testing. However, we might want to start testing against Tomcat 5.0, now that a stable release is available: http://jakarta.apache.org/site/news.html#20031203.1 -- Martin Cooper -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]
[RESULT][VOTE] Joe Germuska as a Struts Committer
The Struts team has voted in Joe Germuska as a new committer, with the following results: +1: Martin Cooper Don Brown David Graham James Mitchell Robert Leland Steve Raeburn Craig McClanahan Ted Husted -1: None The voting thread is here: http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Joe+Germuska+as+a+Struts+Committer%22defaultField=subjectSearch=Search Joe, please complete and submit (preferably by fax) a Contributor License Agreement (CLA) as described here: http://www.apache.org/dev/committers.html#general Let me know when that's done, and we'll get your account set up. Welcome, Joe! -- Martin Cooper On Sun, 7 Dec 2003, Martin Cooper wrote: Joe has been involved in the Struts community for some time now, and has been a great contributor on the -dev and -user lists, as well as in the bug database. I believe Joe would be a great asset to the team, and that it's time we invited him to join us as a Struts committer. Here's my +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Joe Germuska as a Struts Committer
Joe has been involved in the Struts community for some time now, and has been a great contributor on the -dev and -user lists, as well as in the bug database. I believe Joe would be a great asset to the team, and that it's time we invited him to join us as a Struts committer. Here's my +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven test run
On Wed, 3 Dec 2003, Steve Raeburn wrote: http://maven.apache.org/repository-upload.html Perhaps, if Maven is widely adopted by Apache projects, it would make sense to set up an Apache based repository. Then projects would be able to directly publish their own jars. This idea has been bandied about on infrastructure@ several times. Right now, they're in the process of procuring some serious new hardware for Apache. Once that's in place, I wouldn't be surprised to see an Apche repo for Maven (amongst other) builds. That would make a lot of folks happy. :-) -- Martin Cooper Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: December 3, 2003 6:33 AM To: Struts Developers List Subject: Re: Maven test run Joe Germuska wrote: Would it be a good idea to make an alternate JAR repository for Struts so that this step can be automated without depending on the iBiblio managers? It's trivial to do in Maven -- in fact, now that I look, I see that it's configured in the project.properties file, but that line is commented out: #maven.repo.remote=http://www.ibiblio.org/maven/,http:// jakarta.apache.org/struts/repo Any reason not to set that up so that it works? I'm still not clear on how the whole ibiblio thing works. But, yes, we should be making our nightly snapshot JAR available someplace and updating it every day as part of an automated process. Ditto for any of our Commons JAR dependencies. One question would be whether we should be distributing JARs from this server or not. Infrastructure is trying to limit the points of access for distributions. -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: Maven test run
On Wed, 3 Dec 2003, Tim Chen wrote: Using Maven on a few of my projects I've often felt the same way. It would be nice to not have to wait for someone to submit a request for a new jar to be put on ibiblio (that's how its done currently) before being able to use it in your own project. We've either set up a repository for or dropped in manually latest/greatest jars that we need just so that we dont have to wait for ibibilio. A jakarta wide maven like repository would be awesome to this respect. Since jakarta has a pretty easy to access repository already (http://apache.takiweb.com/jakarta/) it shouldnt be too difficult to add a few folders to make it maven friendly. There are plenty of Jakarta (and Apache) mirrors around. However, there's always the question of trust. People are always supposed to verify their downloads from a mirror against the signatures on the main Apache site. For an automated build process to be trustworthy, it would either have to do that same verification automatically (unlikely, IMHO) or obtain its dependencies from an Apache server. That means an Apache repo, as Steve suggested. -- Martin Cooper -Tim Steve Raeburn wrote: http://maven.apache.org/repository-upload.html Perhaps, if Maven is widely adopted by Apache projects, it would make sense to set up an Apache based repository. Then projects would be able to directly publish their own jars. Steve -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: December 3, 2003 6:33 AM To: Struts Developers List Subject: Re: Maven test run Joe Germuska wrote: Would it be a good idea to make an alternate JAR repository for Struts so that this step can be automated without depending on the iBiblio managers? It's trivial to do in Maven -- in fact, now that I look, I see that it's configured in the project.properties file, but that line is commented out: #maven.repo.remote=http://www.ibiblio.org/maven/,http:// jakarta.apache.org/struts/repo Any reason not to set that up so that it works? I'm still not clear on how the whole ibiblio thing works. But, yes, we should be making our nightly snapshot JAR available someplace and updating it every day as part of an automated process. Ditto for any of our Commons JAR dependencies. One question would be whether we should be distributing JARs from this server or not. Infrastructure is trying to limit the points of access for distributions. -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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven test run
Sorry, guys, my ISP decided to take some time off over the holiday as
well... ;-(
On Sat, 29 Nov 2003, Steve Raeburn wrote:
At the minute, I've just copied the docs over to see how it would work
out. My opinion is not bad, but more work required. As far as I'm
concerned, the Maven build is still experimental and not ready for
primetime.
It might be an option to build the website from Maven in the (very) near
future, but I think we'll need to do some restructuring before the
library build will work with Maven. (Separate out the taglibs, web apps,
contribs into separate sub-projects).
I've been thinking about this restructuring too (entirely outside the
Mavenisation discussion), and plan on writing up my thoughts on this
soon. My thinking is primarily in the context of Struts 2.x, but the
principles would largely apply to 1.2.x as well.
I don't think we should let the Mavenization process hold up the 1.2.0
release. There's a lot of changes waiting to get out and I think it best
not to combine those with a change in the build process. Hopefully, we
can integrate it into the build as we move forward through 1.2.x.
+1, +1, and +/-0, respectively. ;-)
I have to say that I'm losing faith in Maven. When I first dabbled in it,
I thought it was super-cool because of some of the things it can do, like
generating web sites. However, once I got past the honeymoon period, I
started to get more and more frustrated. The lack of documentation doesn't
help, but what bugs me most is that it seems to go from really easy, when
you set things up the way it likes, to really arcane, if you don't, very
quickly. And if we have to start writing Ant tasks, well... ;-{
In any case, more power to the folks working on Mavenising Struts, but, as
Steve says, let's not let that get in the way of a 1.2.0 release.
--
Martin Cooper
For maintenance purposes, the live documentation is still in docs. Don't
bother trying to maintain xdocs yet. I hope we'll be able to translate
the docs in place maintain the history.
I'm not sure the end is in sight yet, but I'm now more confident now
that the end is achievable with Maven :-)
Steve
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: November 29, 2003 12:31 PM
To: Struts Developers List
Subject: Re: Maven test run
David Graham wrote:
You're going to delete the old versions in /doc right? We
certainly don't
want to maintain 2 versions of our docs. It would be good
not to lose the
cvs history on all of these in the moves to xdocs so maybe
we can just
move the files in the filesystem on cvs.apache.org instead of just
checking in brand new versions in xdocs?
If we're ready to convert the documentation to Maven, then we
could just
point the xdoc plugin at our doc directory by setting the
maven.docs.src
property.
http://maven.apache.org/reference/plugins/xdoc/properties.html
I'm OK with doing this, but it should be a deliberate
decision, and we
should probably have an actual vote.
Of course, there is still some work to do, and I can help
with that over
the next week. But I think the end is in sight :)
-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: Maven test run
After copying my local Validator build to Maven's repo, I get the same as you do - no tests to run. Doing the Ant test.junit thing, I get the TestActionConfigMatcher failure, but it looks like Steve has tracked that one down. -- Martin Cooper On Thu, 27 Nov 2003, James Mitchell wrote: On Thu, 27 Nov 2003, Ted Husted wrote: When I run the maven jar target, the upload tests fail (MultipartTestSuite). On a fresh copy ofwelleverything (maven 1.0-rc1, jakarta-struts, etc, etc) I cannot do anything with maven. The attempt to download validator SNAPSHOT fails. When I change project.xml to use 1.0.1 or 1.0.2, it downloads, but the compile fails complaining about missing ValidatorUtils. I downloaded a nightly, moved it to ~/.maven/repository/commons-validator/jars/. Then changed SNAPSHOT to nightly in project.xml. Then this: [EMAIL PROTECTED] jakarta-struts]$ maven jar __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT java:prepare-filesystem: java:compile: [echo] Compiling to m-target/classes [javac] Compiling 266 source files to /home/jmitchell/cvs/jakarta-struts/m-target/classes /home/jmitchell/cvs/jakarta-struts/src/share/org/apache/struts/tiles/actions/DefinitionDispatcherAction.java:78: warning: org.apache.struts.tiles.DefinitionsUtil in org.apache.struts.tiles has been deprecated import org.apache.struts.tiles.DefinitionsUtil; ^ huge-snip/ /home/jmitchell/cvs/jakarta-struts/src/share/org/apache/struts/validator/ValidatorPlugIn.java:264: warning: org.apache.commons.validator.ValidatorResourcesInitializer in org.apache.commons.validator has been deprecated ValidatorResourcesInitializer.initialize(resources, bis, false); ^ 41 warnings java:jar-resources: Copying 15 files to /home/jmitchell/cvs/jakarta-struts/m-target/classes test:prepare-filesystem: [mkdir] Created dir: /home/jmitchell/cvs/jakarta-struts/m-target/test-classes [mkdir] Created dir: /home/jmitchell/cvs/jakarta-struts/m-target/test-reports test:test-resources: test:compile: [echo] No test source files to compile. test:test: [echo] No tests to run. jar:jar: [jar] Building jar: /home/jmitchell/cvs/jakarta-struts/m-target/struts-1.2.0.jar BUILD SUCCESSFUL Total time: 26 seconds Finished at: Fri Nov 28 01:40:35 EST 2003 No tests to runAm I missing something here? But, when I run the ant test.junit test, only the TestActionConfigMatcher test fails. Is it me, or do others share this experience? If so, any ideas as to why this would be? -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: Maven test run
On Thu, 27 Nov 2003 [EMAIL PROTECTED] wrote: Good point, thanks for solving the mystery. I've updated the test to not depend on the hashmap order. Cool. Works for me. :-) -- Martin Cooper Don I'm also getting a failure on TestActionConfigMatcher (using Ant build): Name isn't correct junit.framework.AssertionFailedError: Name isn't correct at org.apache.struts.config.TestActionConfigMatcher.testCheckSubstitutionsM atch(TestActionConfigMatcher.java:202) ... cfg.getName() is returning 'name2', but the test expects 'name' fConfigs contains: [0] = name2 [1] = name The problem seems to be that the test relies on the order of the array elements but ActionConfig stores the configs in a HashMap which does not return its values collection in a guaranteed order. I would have expected the failure to be intermittent, but it fails consistently for me. Maybe in practice the order is consistent for a platform, JDK, day of the week etc. etc. :-) As an experiment, I changed the HashMap to a TreeMap, and the tests pass. I don't know if this would have any knock on effects elsewhere though. Might be better to rethink the test so it doesn't rely on the ordering. Or even just drop that section since it's really only testing findForwardConfigs(), not the matcher. Steve -Original Message- From: Don Brown [mailto:[EMAIL PROTECTED] Sent: November 27, 2003 9:36 PM To: Struts Developers List Subject: Re: Maven test run Hmmm...I just updated, uncommented those two lines, and ran ant test.junit - all tests passed. Anyone else? Don On Thu, 27 Nov 2003, Ted Husted wrote: When I run the maven jar target, the upload tests fail (MultipartTestSuite). But, when I run the ant test.junit test, only the TestActionConfigMatcher test fails. Is it me, or do others share this experience? If so, any ideas as to why this would be? -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] - 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: [Fwd: Re: Maven test run]
On Fri, 28 Nov 2003, Ted Husted wrote: And, for extra credit, if anyone were interested in trying it, a Mavenized version of Martin's very cool release target would be very useful. It wraps up both the source and binary distributions in both .zip and .gz format, ready for upload. Something like this should probably be a Maven plugin, since its something all the Jakarta projects need to do. The maven-dist plugin does this for regular Maven projects. I don't know what it would take to get it to do the right thing for Struts, though, since I'm not much of a Maven maven myself. -- Martin Cooper -Ted. Original Message Subject: Re: Maven test run Date: Fri, 28 Nov 2003 13:55:44 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] Organization: Apache Software Foundation - Jakarta Project To: Struts Developers List [EMAIL PROTECTED] References: [EMAIL PROTECTED] We are interested in fixing the Maven build. The tests seem to run under the conventional build, which would imply that the issue may be in the Maven setup. Along with the core, we would also need a strategy for building the various example web applications. I'm thinking we may need a master webapps-projects.xml that each application artifact could extend. -Ted. Tim Chen wrote: I submitted a patch recently for the maven build. Sorry I didn't get a chance to (aka.. Just been lazy) attach it to a formal bugzilla report as Rob had suggested that I do. The maven test currently fail because the resources are not provided (look at my past post for reference). Unfortunately, even after including the source there are still test failures. I posted a sniplet of one of the errors before. I never bothered to find out if those test failures were due to the maven build or because of incorrectly written tests. Either way, I'll try to find some time to fix the maven build if anyone is interested. Tim Chen [EMAIL PROTECTED] -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, November 28, 2003 8:50 AM To: Struts Developers List Subject: Re: Maven test run Steve Raeburn wrote: There were no tests found because the test section was commented out! (and the example include pattern doesn't match our naming convention). I've enabled the JUnit tests. Using Cactus with Maven is beyond me, for now :-) Mea culpa on the comment block. I did that to see if I could get the rest of it to run, and then committed it accidentally. head-slap/ When Maven runs the tests, TestModuleConfig is throwing a NullPointerException that doesn't show up when running from Ant. I'm inclined to believe that the Maven configuration requires more work rather that it actually being a problem with ModuleConfig. The Maven build remains HIGHLY experimental!! I wonder if we could try a compromise? Could we have a Maven build that just downloaded the dependencies into the central repository, and a build.properties that got everything from there. This would save us from going back to a struts-library distribution. I also wonder if it be possible to wrap our existing Ant build as Maven goals? The user guide says that any Ant task can be used in the maven.xml. http://maven.apache.org/reference/user-guide.html#Sample%20maven.xml Another stepping-stone might be to provide Maven projects for the examples applications, especially the blank application. I'm thinking the cannonical approach here would be to have a master webapp-project.xml that we then extended for each application artifact. http://maven.apache.org/reference/user-guide.html#POM%20Inheritance I'm working on a changelog system now but will come back to this later, if no one beats me to it. [Please do, if you can :)] -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: cvs commit: jakarta-struts/src/share/org/apache/struts/util MessageResources.java
On Thu, 27 Nov 2003, David Graham wrote:
When changing Struts' messaging classes we also need to update
commons-resources with identical changes. Otherwise, we'll end up getting
frustrated users and duplicate bug reports when Struts starts using
commons-resources.
Sure. In this particular case, I don't believe the issue arises in Commons
Resources, because it's structured differently. (Feel free to let me know
if that's not the case, though.) The problem here was that one particular
method was bypassing the locale defaulting mechanism, while all the rest
were picking it up correctly.
--
Martin Cooper
David
--- [EMAIL PROTECTED] wrote:
martinc 2003/11/27 14:14:51
Modified:src/share/org/apache/struts/util MessageResources.java
Log:
Make sure getMessage(String) goes through the local implementation,
rather
than bypassing it and therefore skipping the default locale handling.
PR: 22252
Submitted by: msc at ivu.de
Revision ChangesPath
1.20 +5 -5
jakarta-struts/src/share/org/apache/struts/util/MessageResources.java
Index: MessageResources.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/util/MessageResources.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- MessageResources.java 9 Sep 2003 04:33:12 - 1.19
+++ MessageResources.java 27 Nov 2003 22:14:51 - 1.20
@@ -204,7 +204,7 @@
*/
public String getMessage(String key) {
-return this.getMessage((Locale) null, key);
+return this.getMessage((Locale) null, key, null);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.2.0 Resurrected
On Tue, 25 Nov 2003, Ted Husted wrote: With the long weekend coming up, I was thinking of rolling up my sleeves and doing whatever needs to be done to cut 1.2.0. Funny you should bring that up. I'm planning on spending a good chunk of this upcoming break in Apache land myself. Anyone one aware of any serious showstoppers? No, but then I have a lot of catching up to do. While under the current scheme, any release has the potential to make the General Availability grade, I would anticipate that 1.2.0 will end up being a simple milestone release, and we'll have to cut a few more before we get to GA. But, I'd like to start the ball rolling. +1 to all of that. -- Martin Cooper -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: 1.2.0 Resurrected
On Tue, 25 Nov 2003, Ted Husted wrote: Do you want to tag-team on the release again? Sure. As it happens, I'm out of town again next Tuesday-Friday, and it would be good if there were another RM ready to step in for any mopping up mopped up. I'll get my mop and bucket ready. ;-) -- Martin Cooper -T. Martin Cooper wrote: On Tue, 25 Nov 2003, Ted Husted wrote: With the long weekend coming up, I was thinking of rolling up my sleeves and doing whatever needs to be done to cut 1.2.0. Funny you should bring that up. I'm planning on spending a good chunk of this upcoming break in Apache land myself. Anyone one aware of any serious showstoppers? No, but then I have a lot of catching up to do. While under the current scheme, any release has the potential to make the General Availability grade, I would anticipate that 1.2.0 will end up being a simple milestone release, and we'll have to cut a few more before we get to GA. But, I'd like to start the ball rolling. +1 to all of that. -- Martin Cooper -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: Greets
It sounds like you might have re-invented (aspects of) Spring: http://www.springframework.org/ Perhaps without the explicit IoC part, though. ;-) -- Martin Cooper On Mon, 17 Nov 2003, n. alex rupp wrote: Hello, all. I've been meaning to drop in for quite a while. I've been following Struts for a couple of years and using it with few complaints or questions. Earlier this year I hit some roadblocks in an application design, downloaded and read the entirety of the source code and took some issues with the architecture. However, since Struts' feature offering is top-notch and since the servlet framework community is rife with division, I decided not to be an ass and complain about it unless I was willing to back it up with some CODE. Instead, I went shopping. I checked out webwork, read the entirety of Rickard's code, and even forked off a small branch for my purposes, but came to similar conclusions about the design. But again, I didn't think it would be productive or polite to force the issue to either of your two communities. It's been my experience that a lot of people will gripe and criticize other people's software--especially the most popular and used software, but they'll never add a lick of positive, constructive feedback in the form of living code, the ultimate contribution to our little society. Code speaks louder than words. So anyway, while working on clientware for the MX4J and Geronimo projects this autumn, I designed and wrote a servlet framework from scratch to handle my needs. It has an aspect-oriented workflow engine that can add crosscutting system logic (like form processing, L10N, security, logging, etc) dynamically at runtime (without having to mess around with the bytecode). It can trade actions across classloader boundaries, enabling web applications to span across multiple .WAR files. This allows users to drop in a new .WAR with new metadata and new actions, which updates the application workflow at runtime across all modules in the application namespace. It handles workflow versioning and version rollback (in case you make changes you come to regret). It does instance pooling of all components and sequences. Every aspect of the system can be managed with JMX at runtime. To my knowledge, it should work with every type of Presentation technology. The concerns of the underlying framework are separated from those of the feature platform. Almost every component in the core framework and the corresponding feature platform ultimately implement one of three interfaces: DataSource, Workflow or Action; I didn't even try to reconcile with the MVC antipattern because I don't think it reflects the needs of the technology. All end-user interaction with the framework is done through a simple client package. The configuration file is dirt-simple and is processed into metadata beans in the framework which are pooled and used to direct workflow. Basically, it's just really neat and I'm having a lot of fun working on it : ) The reason I'm telling you all this is because I designed it so you could implement your entire feature platform (form processing validation, i18n, resource bundles, whatever) on top of it, without much difficulty. Of course, I don't *expect* you guys to do this, but it's possible and probably wouldn't be that tough. Same goes for WW and other frameworks. So now (surprise) you have even *more* options. (I also noticed that you guys are working on a chaining implementation. Since my core framework performs this, I thought I should finally get in touch.) It's licensed under the Academic Free License (the ultimate business-friendly OS license), and I've got the beginnings of a web page up for it at http://shocks.sf.net. There are API docs and sample code available, although the framework is in alpha and I'm still refactoring the core components. (Oh yeah--the core is pluggable, too, in case we decide to hate it later on ; ) If this interests any of you, please drop me a line. I've got some test applications running successfully against it, and I'll be using it to build a management console for Geronimo. If there is any way I can help you guys out, please let me know. If not, good luck and Kind Regards, -- N. Alex Rupp ([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 commit: jakarta-struts/doc/resources archives.xml consultants.xml powered.xml sigs.xml
Vic, Just shut up. You've been whining on about this on general@, long after being told that it's the wrong place for that discussion. You've attacked Apache in general, the chairman specifically, and now Craig. All the while, you've been told that appropriate measures are being taken by the appropriate people, but still you whine on with your guilty until proven innocent attitude. If you feel dirty to be using Struts now, you are perfectly free to use something else instead. In fact, you don't have to use any ASF software at all. But if you're going to run around spouting the way you have been, I see absolutely no reason that you should expect free publicity from the ASF, nor do I see why you would even desire that. It could only make you feel more dirty still. I fully support Craig's action in updating the Struts site today. -- Martin Cooper On Tue, 11 Nov 2003, Vic Cekvenich wrote: This is what broke it: http://theserverside.com/home/thread.jsp?thread_id=22337 It was aleged that code was takem from someplace that was not allowing it and placing it into Apache code base! ASF seems to be saying we took the design and are re-implementing it. Whatever. Shame on you for ... aparently... supporting it. I guess it's good for comercial vendors such as Sun, but it is bad for Open Source. I think ASF and Sun are a bit to close. I guess another brick. .V Craig R. McClanahan wrote: Quoting Vic Cekvenich [EMAIL PROTECTED]: Was that called for Craig? Yep. - 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: Building the Struts /contrib code in the CVS
I'll work with Scott on this over on pluto-dev, since he's likely not subscribed to struts-dev (while I am subscribed to pluto-dev). -- Martin Cooper On Wed, 29 Oct 2003, Mete Kural wrote: Hello Struts developers, Scott Weaver from the Jetspeed and Pluto projects wrote that he tried to build the code in the /contrib folder of the Struts CVS and faced some problems. I think he wants to take a look at the struts-chain code in order to figure out how it's going to work in a portlet environment. I am copying his email below: -- Original Message -- From: Weaver, Scott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Wed, 29 Oct 2003 13:37:48 -0500 Maybe it's just me, but I tried to build the contrib stuff in the CVS for struts a while back as I wanted to start taking a look at. However, I could never get it built. There were deps I had never heard of, nor did I know were to get them. Can you assist him on this? Thank you.. Mete - 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 Chain... seams similar to HiveMind ?EOM
On Wed, 29 Oct 2003, Vic Cekvenich wrote: Struts Chain... seams similar to HiveMind ? If you mean in roughly the same way that apples are similar to oranges, then I'd agree with you. ;-) Otherwise, no, I don't see similarity. HiveMind is a services and configuration microkernel or a centralized registry of services and configuration points, depending on which part of the home page you read. (It also doesn't have any particular purpose. ;) Struts Chain is an attempt to refactor the request processor in terms of the GoF Chain of Responsibility pattern. It's certainly not a microkernel or a framework of any kind. The chain config itself (which is not part of Struts Chain per se) could be considered as a registry of sorts, but it's quite different to what HiveMind's registry is all about. -- Martin Cooper Am I wrong? .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]
Deprecating DiskMultipartReqwuestHandler and friends
Hi folks, Any objection to deprecating DiskMultipartRequestHandler and its associated classes? This was the default file upload handler in Struts 1.0, but was replaced by CommonsMultipartRequestHandler for 1.1 and beyond. It was, and is, buggy, and I'm sure nobody has any interest in maintaining it now that we're using Commons FileUpload to do the heavy lifting. Just asking up front so that I don't have to go back and remove a boatload of deprecations if it turns out that somebody wants to keep it. ;-) -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: request for feedback on proposed parameter tag
Joe Germuska [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Has anyone done anything about this:
Chris Bare wrote:
Is there any interest in a ParameterTag that would
allow parameters to be added to the URL generated by
LinkTag? Something that would allow you to do create
links like so:
My take is that a special parameter tag is not necessary. The html:link
tag allows you to pass a Map of parameters and values, so what I've done is
to create a couple of tags that allow me to create such a map and add
elements to it. The usage looks like this:
coll:mapCreate var=params/
coll:mapAdd map=${params} key=param1 value=value1/
coll:mapAdd map=${params} key=param2value2/coll:mapAdd
html:link action=/MyAction name=params
...
/html:link
The map tags could be added to Unstandard at Jakarta Taglibs, if there's
interest.
--
Martin Cooper
(from 2003-07-03, see
http://marc.theaimsgroup.com/?l=struts-devm=105726259312808w=2)
Craig indicated that he thought it made sense
http://marc.theaimsgroup.com/?l=struts-devm=105726389314243w=2
This issue has come up twice this morning with developers here. I'm
just wondering if anyone has actually written the code (Chris?)
Joe
--
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
If nature worked that way, the universe would crash all the time.
--Jaron Lanier
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tags more extensible (was: Suggestions for Calendar Popup tag lib?)
Robert Leland [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Replyied Inline.
Paananen, Tero wrote:
[this is in response to Robert Leland's reply to my
post on the struts-user list griping about the
(un)extensibility of custom tags]
My #1 pet peeve about custom taglibs are that almost
none of them have been designed with extensibility in
mind. This includes all the Struts tags that I've had
to tinker with.
Extending them basically means, more or less,
copy-and-pasteing all the existing code into your new
taglib, then customizing the behavior to meet your
needs.
Tero:
Your insight into how the Struts Tags can be made
more Modular so they can be extended easier would be very
valuable and welcome.I encourage you can bring the issue
up on the struts-dev list.
Robert,
From what I've seen most custom tags seem to have been
implemented as one big doStartTag() or doEndTag(). The
entire implementation of the tag is in that one method.
In order to modify the behavior, more often than not,
the only way to do this, is to completely rewrite that
method by copy-and-pasting the old implementation into
your new tag, modify it slightly and be done with it.
The only reuse comes with the getters and setters for
the tag's properties.
This approach to extending breaks the minute a new
release of your base tag changes significantly. You
either have to redo your extended tag based on the new
release or leave your extended tag as is, and potentially
leave bugs in that were fixed in the new release.
I've had some limited success with tags that implement
doStartTag() (and/or doEndTag() in more discreet steps:
// method names and (non-existing) return types
// purely illustrative
public int doStartTag() throws JspException {
doStart();
doStep1();
doStep2();
doEnd();
}
This way you can overload only the method that deals
with whatever you need to modify and leave everything
else as is.
If you also had pre- and post-processing methods for
every discreet step in the process, you'd have even
more flexibility:
// method names and (non-existing) return types
// purely illustrative
private String doStep1() {
preDoStep1();
// step 1 implementation here
postDoStep1();
}
Hopefully you see where I'm going with this. The pre-
and post-processing methods could be implemented to
skip, ignore, modify, etc. the implementation of the
real method.
I haven't done anything like this with custom tags
myself, but I've used a few products (ATG Dynamo comes
to mind first) that use this sort of architecture in
the entire application, and it's extremely flexible.
I realize that doing something like this would probably
have a performance impact and would most likely be overkill
for everyone but that one screwed up developer that needs
to modify every tag he gets his hands on, but as far as
extensibility goes, something like this would greatly
improve on how custom tags can be extended, IMHO.
I doubt there would many any notiable impact on performance.
I agree *iff* we're careful about the way it's done. Some of the method
calls will probably go away anyway if the code is automatically inlined, so
I don't believe method invocation would be the issue.
However, looking at FormTag right now, I see several methods that build up
strings in StringBuffer instances and convert those to String instances so
that they can then be appended to a StringBuffer. All that string processing
can mount up and cost you in the long run, where it would be much more
efficient to pass the original StringBuffer to those methods so that they
can append what they need, without requiring the creation, copying and
destruction of multiple StringBuffer and String instances in between.
--
Martin Cooper
I'm sure people on the list who have far more experience
than I do with writing taglibs, and application architectures
in general, will see lot of things wrong with this approach
and can come up with something better, but as someone who
has had to extend a somewhat large number of custom tags
(Struts and otherwise), I'm completely fed up with the
copy-and-paste codeing I'm forced to do right now.
I feel your pain as one ex-U.S. President once said.
What say ye, oh Struts gods (and goddesses)? :)
I agree totally, at the level were currenrly arguing, I dare anyone to
disagree !
A good way to tackle this is Use Case by Use Case, to avoid talking in
general terms.
1) What specific tags have you or do you want to modify the behaviour of.
2) What level of granularity makes sense.
3) Do we use simple overriding, or publish/subscribe or Decorator
Pattern, others.
I would start off by recommending the Decorator pattern. I believe
this is what
David Karr did when adding JSTL functionality to Struts.
-TPP
-Rob
-
To unsubscribe, e
Re: When is the next release?
David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] --- Ted Husted [EMAIL PROTECTED] wrote: There are 18 non-enhancement tickets in Bugzilla. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDbug_severity=Blockerbug_severity=Criticalbug_severity=Majorbug_severity=Normalbug_severity=Minoremail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitorder=Bug+Number Many of these are nested and Tiles related and I don't think those should block a release. I disagree. Tiles and Nested are first class citizens, and currently part of the Struts core. There is absolutely no reason to claim that bugs in these components are less important than bugs in any other part of the core. Perhaps you don't use them, but many others do, and they should not be slighted. I've said it before, and I'll say it again - more frequent releases does *not* mean lower quality releases. You can be sure I'll back that up. I'll take a look at these to see if there's anything that would block a release. If not, I could roll a release on Sunday and try to do it HTTPD-style, so that we can do it without a freeze. Would this be a 1.2 RC1 or final? I think it has to be Beta 1. I know we're supposed to be using this new Tomcat-style numbering scheme, but my understanding is that even numbers mean stable releases. That being the case, there has to be some stabilising mechanism before we can get to the first release, because 0 is an even number. (In other words, a 1.2.1 release would be the stabilising release before a stable 1.2.2, but how do you stabilise before a 1.2.0 release?) http://httpd.apache.org/dev/release.html I'll cut the candidate and post it for review and a vote. If it passes, it passes; if not, we re-tag and try again. I do think it would be a good idea to get a post 1.1 release out now so people will start updating their code to not use the 1.1 deprecations. +1 -0. Personally, I don't think that, by itself, is a good enough criterion for a release, but I don't feel strongly enough about that to block it if other people disagree. After 1.2.0, we could start with the 1.2.x releases, until we do something drastic like drop in a Composable RequestProcessor or move a dependence to another JAR (e.g. Commons Resources). I've always thought that point releases are bugfixes only with no enhancements. Also, point releases don't allow us to remove deprecated features. How would these change under a 1.2.x type of release scheme? Point releases (e.g. going from 1.2.0 to 1.2.2) are indeed bug fixes only and no new features. New features require a minor version increment (e.g. 1.2.0 to 1.3.0). When we do something drastic (to use Ted's words ;), we'll need to go to a1.3.x lineage. That will quite likely mean creating branches, if we want to work on both bug fix releases and new features simultaneously in the CVS tree. -- Martin Cooper David -Ted. David Graham wrote: I think we could release 1.2 now if there was a release manager. I don't have the time to learn and perform the release process right now. David --- Nick Lesincki [EMAIL PROTECTED] wrote: It has been at least 1 month since question was asked When is the next release? Last msg said 1 month after 1.1 and a release manager was required and some bug fixes would be out. Nicolas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Steve Raeburn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ParameterDispatchAction fulfils much the same function as LookupDispatchAction but its implementation is almost identical to DispatchAction. It would be redundant to go through getKeyMethodMap() to get the method name because it is supplied in the parameter. I may have misunderstood what you are suggesting but to me it would make more sense to add to DispatchAction than to Lookup DispatchAction. It *may* make some sense to combine all three resolution methods into DispatchAction and either have DispatchAction try to find a handler using all three methods or set the method via a configuration parameter. I worry that that would be more confusing to the user that having three distinct classes that you can explain quite simply: To dispatch to a method identified via a request parameter, use DispatchAction. To dispatch to a method based on which button was clicked, use LookupDispatchAction To dispatch to a method based on the action path, use ParameterDispatchAction I'm +1 on this, other than on naming. I think ParameterDispatchAction is definitely the wrong name for the last of these. People are *far* more likely to think of the Parameter in the name as meaning a request parameter than they are to think of the parameter action mapping attribute. Perhaps MappingDispatchAction instead? I am -0 on combining all of this into one action. -- Martin Cooper I would prefer to add ParameterDispatchAction now and defer a decision about merging the three actions. To me, that would be 'the simplest thing that could possibly work' :-) Steve -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 1, 2003 10:42 AM To: Struts Developers List; [EMAIL PROTECTED] Subject: RE: Addition of two new actions So, what you really want is LookupDispatchAction without requiring the developer to create the map-related methods? I think you already get the abililty to combine CRUD related actions and things like that. If so, then implementing a default getKeyMethodMap() in LookupDispatchAction might accomplish the same goal, without requiring another action. Such a default implementation could examine the current LookupDispatchAction subclass and create the mapping information automatically. Don't get me wrong ... I like the idea behind what you're proposing. I just think we might already have it (with the potential to improve ease of use by not forcing people to implement getKeyMethodMap() for a common use case). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Joe Germuska [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] At 19:29 -0400 8/3/03, Erik Hatcher wrote: Having a SuccessAction makes it much easier to do skeleton/storyboarded sites and fill in the details later. Switching from a SuccessAction to a real action when the time is right requires only changing the class name, not the structure of the action mapping XML too. In my Advanced Struts talks, I recommend a SuccessAction over ForwardAction as how I do it. Of course everyone's mileage may vary. Parallel to all of this, I've been cleaning up some docs and preparing for another small release of the JGSI tools for Struts (http://demo.jgsullivan.com/struts/). The only new class, actually, is an action that also fits into this skeleton/storyboarding phase, so I thought I'd mention it to folks. The class is called SmartForwardingAction, and the idea is that you don't even have to bother entering action mappings into struts-config for this common case where you want to hide an essentially static page behind an action (along the Struts Catalog strategy Use a forwarding Action for static pages. If you register SmartForwardingAction as your unknown (default) action, it will take what would have been the action path, append .jsp, and forward to that JSP. So if someone requests /HelloWorld.do, the action looks for /HelloWorld.jsp. If getRequestDispatcher() for that path returns null, an exception is thrown; otherwise, the execute method returns a ForwardingAction pointing to that path. That sounds rather dangerous to me, unless you have some additional control over which JSP pages can be accessed in this way. From your description, it sounds like this gives the client blanket access to all the JSP pages in your app, which I certainly wouldn't want. -- Martin Cooper Actually, I'd been meaning to raise a question related to this to the developers -- to achieve this, I copied the processPath method out of the default RequestProcessor class. I was wondering if we might agree on a request attribute under which that path could be passed (i.e. Globals.ACTION_PATH_KEY) so that this action or any other action mapped under unknown='true' would have access to it. It's nothing huge, but it seems pretty safe. See http://demo.jgsullivan.com/struts/SmartForwardingAction.html for a little more writeup. The class is in the 0.2-dev jar which can be downloaded from the above site in binary or source form. I'm working with Ted H. to get at least some of the JGSI struts tools into the Source Forge project -- I mostly just wanted to finish this documentation before putting it over there. The other change for this small release is the addition of a default set of digester rules for creating a list of LabelValueBeans so that you can configure select menus for your application in XML files -- see http://demo.jgsullivan.com/struts/DigestingPlugIn_Example.html Cheers, Joe -- -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com If nature worked that way, the universe would crash all the time. --Jaron Lanier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Steve Raeburn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] You're right action forward= is module relative (despite what it says in the Javadoc). However, I don't see how it can used with a context relative path. You might want to take a look at the 'forwardPattern' attribute, and the RequestUtils.forwardURL() method (especially the JavaDoc for the latter). -- Martin Cooper There is no contextRelative attribute on the action config so you don't get to choose (or change) how your forward works. Of the three ways of defining forwards that you identified only one, forward, works flexibly with modules and that's the one that we don't ship an action for with Struts. SuccessAction works flexibly with modules, it's tool friendly, it's simple to understand and its configuration is consistent with almost all other actions. Steve -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: August 4, 2003 7:03 AM To: Struts Developers List Subject: RE: Addition of two new actions Thanks for the link. I'll respond to that message here: I'm also throwing an exception if the success ActionForward is not found to make the configuration problem very clear. ForwardAction also throws an exception if the path is not found. ForwardAction and using 'forward= ' on the ActionMapping both require a context relative path. That's not accurate, forward and action forward= both default to module relative paths. forward contextRelative=true changes the default. ForwardAction itself always returns a context relative ActionForward but I'd rather see that changed than add a new class. In addition, tools vendors may be better able to validate a regular ActionFoward configuration than the ForwardAction where the path is specified via the all-purpose 'parameter'. In order to validate the path as a parameter, you require knowledge of the Action class whereas the path of an ActionForward definition can be more easily validated. (I'm basing this on my experience with WebSphere Studio). There are many ways of defining forwards: action path=/input.do forward=/jsp/input.jsp/ forward name=foo path=/jsp/input.jsp/ action type=o.a.s.actions.ForwardAction path=/input.do parameter=/jsp/input.jsp/ Some of these allow better path validation than others but I don't see why we need yet another Action class when we could just improve upon the existing options. David Steve --- Steve Raeburn [EMAIL PROTECTED] wrote: -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: August 3, 2003 3:02 PM To: Struts Developers List Subject: Re: Addition of two new actions ... I still don't see a need for a SuccessAction in the first place. Why is it any better than using a ForwardAction? I did expand on my reasons, but there's been a lot of traffic so maybe it scrolled by: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] arta.apach e.orgmsgNo=19706 Erik's message also adds to this. Steve David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Addition of two new actions
Steve Raeburn [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I'd like to add two new actions to org.apache.struts.actions that I find
particularly useful.
1. SuccessAction - A simple action that forwards control to an
ActionFoward
named success.
This already exists, in contrib:
org.apache.struts.scaffold.SuccessAction
or, as David pointed out, you could use ForwardAction instead.
--
Martin Cooper
This is a very simple action, but I find it exceptionally useful,
particularly in the early stages of development when it can act as a
placeholder for as-yet undeveloped actions.
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
ActionForward forward = mapping.findForward(success);
if (forward == null) {
String message =
messages.getMessage(success.required, mapping.getPath());
log.error(message);
throw new ServletException(message);
}
return forward;
}
2. ParameterDispatchAction - A DispatchAction that selects a handler
method
using the value of the ActionMapping parameter.
This is as per the suggestion by Anthony Kay via Bugzilla
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117, except I prefer
the name ParameterDispatchAction to his suggestion of ConfigDispatchAction
as I think it's more descriptive of what the class actually does. Other
than
the name change, I've just tidied up the Javadoc and changed the
'unspecified' method to throw an Exception (as in DispatchAction) rather
than return an Http error code.
If no one has any problems with adding these two, I'll put them in
tomorrow.
Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: I18N in struts
This is a question for the struts-user list. The struts-dev list is for discussion of the development of Struts itself. -- Martin Cooper RODRIGO CARVALHO DOS SANTOS [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi All, Does Struts have a standard way to deal with internationalization in the ActionForm Bean? If I need to format a string date in the FrontEnd and pass as date data type back and foward to the backend, how may I use the Localization info? Thanks in advance for advices or links, Rodrigo. * Internet E-mail Confidentiality Footer * Esta mensagem pode conter informações privilegiadas e/ou confidenciais de propriedades da BCP Telecomunicações. Caso voce não seja o destinatário ou pessoa autorizada a recebe-la não poderá utiliza-la de forma alguma. Cópia, revelação ou quaisquer outras ações baseadas nestas informações não são autorizadas. Se voce recebeu esta mensagem de forma equivocada, por favor informe o emissor imediatamente respondendo a este email e em seguida eliminando-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information belong to BCP Telecomunications. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21821] - taglibs requesting certain RequestUtil methods fail if page access not through ActionServlet
Steve, I don't have a problem with your patch. As I said in the bug report, I don't believe we should be fixing the reported problem, but your patch does fix a backwards compatibility issue with apps that don't use modules, which is probably a good thing. ;-) -- Martin Cooper [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21821. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21821 taglibs requesting certain RequestUtil methods fail if page access not through ActionServlet [EMAIL PROTECTED] changed: What|Removed |Added -- -- Keywords||PatchAvailable --- Additional Comments From [EMAIL PROTECTED] 2003-07-23 09:19 --- I have a patch that solves the immediate problem. There may be a better way that ensures that config is not null even for directly accessed JSPs but I haven't looked into it. If nobody objects or has a better solution, I'll check this in tomorrow. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
