DO NOT REPLY [Bug 27831] New: - Struts runs on Trifork 3.3 with No additional steps required
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27831. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27831 Struts runs on Trifork 3.3 with No additional steps required Summary: Struts runs on Trifork 3.3 with No additional steps required Product: Struts Version: 1.1 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In the Struts documentation under installation http://jakarta.apache.org/struts/userGuide/installation.html In the section : Installing Struts on Various Containers Please add. Trifork Enterprise Application Server 3.3.x - No additional steps required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
coming out for JSF + Struts, was: Struts JSR?
Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM) summary: McClanahan should clearly state *in some major publication* * that JSF does/will not replace Struts * how JSF and Struts will likely tend to specialize, in future * how probable specializations will complement (and compete) in webapp development Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 But I think either of us would rather be developing Struts than evangelizing Struts. This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. Frankly, I'm perplexed why the propagation of the latter has gone unchecked for so long. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coming out for JSF + Struts, was: Struts JSR?
On Mon, 22 Mar 2004 08:00:00 -0500, Thomas L Roche wrote: Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 But I think either of us would rather be developing Struts than evangelizing Struts. This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. Frankly, I'm perplexed why the propagation of the latter has gone unchecked for so long. The absolute truth is that nobody knows. In practice, we might find that these perceptions are true. Or we may find that these perceptions are false. Or, more likely, we will find that they are sometimes true and sometimes false. David G doesn't know what will actually happen, neither do I, nor you, or even Craig. So, this would just be Craig's best guess against David's best guess. May the best guesser win :) My point is that this type of prognostication doesn't help Struts in any way that matters. What helps is people rolling up their sleeves and doing the work. Given the vast numbers of developers using Struts, I'm constantly astonished at how hard it is to find more people willing and able to do the work. (Except on the user list, where I'm constantly astonished at the willingness of users to help other users.) Sometimes I think market-share actually hurts a project like Struts, since everybody thinks somebody else is going to do it :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coming out for JSF + Struts, was: Struts JSR?
On Mar 22, 2004, at 6:13 AM, Ted Husted wrote: My point is that this type of prognostication doesn't help Struts in any way that matters. What helps is people rolling up their sleeves and doing the work. Given the vast numbers of developers using Struts, I'm constantly astonished at how hard it is to find more people willing and able to do the work. 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. ;-) Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Validator
Hi I have just started to use the latest builds, and I see that the html:javascript now has changed its implementation with respect to generating dynamic javascript. It now prefixes the required, maxlength etc. methods with the formname. Does this mean that I also have to generate the static parts again - meaning that all forms now will have there complete set of validation routines ? This will increase the static part dramtically as far as I can see. Hermod * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 -- 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]
SV: Making Struts Build Easier (Re: coming out for JSF + Struts , was: Struts JSR?)
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. 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 -- 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This email with attachments is solely for the use of the individual or entity to whom it is addressed. Please also be aware that DnB NOR cannot accept any payment orders or other legally binding correspondence with customers as a part of an email. This email message has been virus checked by the virus programs used in the DnB NOR Group. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - 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 Mar 22, 2004, at 7:28 AM, Joe Germuska wrote: 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. Right. I include my JARs in CVS and I've been doing it for quite some time with no issues. To be honest, there doesn't seem to be much difference in storing them in CVS vs. uploading them to a Maven repository. For me, it's often seemed easier to stick them in CVS. Of course, if I had managed to convert AppFuse to use Maven - maybe I wouldn't be so bitter. ;-) I do like to be able to checkout my CVS-based project and disconnect and compile later though. No internet dependency is a good thing. 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. That's part of it - as well as Ant is easier to understand IMO. I use Maven on a couple projects, but I definitely prefer Ant - mainly b/c I have an Ant build.xml file that I use on all my projects. 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. Whatever it takes to make Struts easier to build. I guarantee that if you can build Struts with an ANT_HOME (or MAVEN_HOME) and JAVA_HOME set - and that's it - you'll get a lot more contributions. My $.02. Matt - 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?)
Personally, I find the Struts build files to be complex and confusing. I've come to associate Maven with easy builds because building commons components (including the distro, website, tests, etc) is a snap compared to Struts. I agree that storing jars in cvs isn't a good idea which is why using Maven is so nice; it downloads the correct jars automatically. Anything we can do to make the build more straightforward, whether it's with Ant or Maven, is a good thing :-). David --- Joe Germuska [EMAIL PROTECTED] wrote: 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 -- 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 Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)
At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote: I think the presentation-tier-independent things about Tiles (like mapping forwards to definitions) should be built in to the core, so there isn't any such thing as a separate TilesRequestProcessor (or a separate chain or whatever). In turn, this probably means we might need an API abstraction that alternative presentation tier technologies can use to integrate themselves into the underlying support. I managed to make Tiles work with struts-chain with a single pre-processor Command. It basically looks up a tiles definition and replaces the ForwardConfig returned from an action with its own that has a path which RequestDispatcher to which can forward. But it still uses the TilesPlugIn... is that part of what you think should be moved up into the core? Or do you think even the single Command is not the best future implementation? 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]
struts-workflow (Re: OT: Struts JSR?)
1:There is no overlap as there does not seem to be any development going on about WorkFlow area in struts. I think you are correct; people seem to be gravitating to struts-workflow. 2:While brousing through struts-dev archive, I came aross many threads where the topic of a workflow like concept was discussed.But nobody seems to have taken this up any further,apart from a mail where in craig has mentioned that he would like to implement a workflow engine where the scriptign languages may be used to define the workflow.he has also mentioned using jelly for the same. But for me, the struts-workflow is more like a wizard implementation,not a real workflow processing engine.SO I am still not clear where jelly like packages may help.But may be I am just being naive. I think it's true that in a wizard scenario, scripting is less likely to be needed. Insofar as one would want to use scripting, I'd probably advocate for a BSF implementation rather than Jelly, so that people can script in any language they want. (Well, actually, I don't think there's a Jelly BSF engine, but I don't think that many people want to script in Jelly either.) 3:The mention of the commons chainning for integrating expernal packages like workflow so that the processing can be intercepted at perticular points and customised.This soundds very interesting concept and very suitable for the workflow requirement.I have not invested much time into this perticular aspect but plan to do so.And I also have a feeling that the future direction for the workflow extension shuld be to move towards the usage of the commons chainning package. I haven't come up to speed on struts-workflow, although I've been wanting to for a while. I remember that Matthias was one of the people who really wanted to see a composable request processing chain, since right now Struts-Workflow has to extend RequestProcessor. It seems likely that the fit will be pretty natural. So this leaves me where I started.Very unclear about the direction the struts is going to take in this regard.And very unclear about how to plan the next major enhancement for the extension. I'm not sure which of the above you'd like to resolve to make more planning. I think (1) is a non-issue; (2) should be deferred until someone has a use-case for it, and (3) -- well, we're going to work on moving the commons-chain based request processor into the Struts core shortly after we deal with migrating Struts to a TLP. But it works enough right now that you could probably begin exploring using it for Struts-Workflow. I'm interested in both chain and workflow, so you might be able to con me into helping out a little bit 8^) 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: coming out for JSF + Struts, was: Struts JSR?
I have to agree. I am somewhat accomplished at programming, but I have limited administrative talents. I would have contributed a lot, but I just have not been able to talk myself into spending my time learning how to get what I need to help. This is no excuse. I still feel guilty as hell. But, this is, I would guess, the major block to most people who do not contribute. Michael At 05:45 AM 3/22/2004, you wrote: On Mar 22, 2004, at 6:13 AM, Ted Husted wrote: My point is that this type of prognostication doesn't help Struts in any way that matters. What helps is people rolling up their sleeves and doing the work. Given the vast numbers of developers using Struts, I'm constantly astonished at how hard it is to find more people willing and able to do the work. 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. ;-) Matt - 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?)
I agree 100% with Matt and make the same prognostication. At 06:46 AM 3/22/2004, you wrote: On Mar 22, 2004, at 7:28 AM, Joe Germuska wrote: 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. Right. I include my JARs in CVS and I've been doing it for quite some time with no issues. To be honest, there doesn't seem to be much difference in storing them in CVS vs. uploading them to a Maven repository. For me, it's often seemed easier to stick them in CVS. Of course, if I had managed to convert AppFuse to use Maven - maybe I wouldn't be so bitter. ;-) I do like to be able to checkout my CVS-based project and disconnect and compile later though. No internet dependency is a good thing. 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. That's part of it - as well as Ant is easier to understand IMO. I use Maven on a couple projects, but I definitely prefer Ant - mainly b/c I have an Ant build.xml file that I use on all my projects. 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. Whatever it takes to make Struts easier to build. I guarantee that if you can build Struts with an ANT_HOME (or MAVEN_HOME) and JAVA_HOME set - and that's it - you'll get a lot more contributions. My $.02. Matt - 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?)
I have a somewhat nutty suggestion. I suggest that we have someone who is an administrative genius with a flair for teaching and simple statement be an available guide to assist new people in getting the proper builds to work on struts. Such a person would, I predict, be worth 100 times there weight in gold to this list. How this should work is, of course, up for discussion. Maybe, also, for some reason I don't know, this idea is a clunker. Michael At 06:28 AM 3/22/2004, you wrote: 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 -- 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]
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]
Validating Two Fields - how to do in 1.2?
My popular validate-two-fields howto seems to be broke with the Struts
nightly (20031202) build I'm using. The following (which works w/
Struts 1.1) throws a NPE at the first errors.add():
public static boolean validateTwoFields(Object bean, ValidatorAction
va,
Field field, ActionErrors
errors,
HttpServletRequest request)
{
String value =
ValidatorUtils.getValueAsString(bean, field.getProperty());
String sProperty2 = field.getVarValue(secondProperty);
String value2 = ValidatorUtils.getValueAsString(bean,
sProperty2);
if (!GenericValidator.isBlankOrNull(value)) {
try {
if (!value.equals(value2)) {
errors.add(field.getKey(), // NPE THROWN HERE
Resources.getActionError(request, va,
field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
Resources.getActionError(request, va,
field));
return false;
}
}
return true;
}
I tried adding if (errors == null) errors = new ActionErrors();, then
everything works fine, but getActionError is deprecated. So how do I
upgrade this to 1.2?
Looking at the example (code below) in the docs
(http://jakarta.apache.org/struts/userGuide/dev_validator.html), there
signature of this method has changed slightly, adding ServletContext
application. Also, the Resources.getActionError isn't valid and and
errors.add(String, ActionError) is deprecated.
Any ideas? I'll try upgrading to a newer build - but I wanted to get
this archived since folks will experience it migrating from 1.1 to 1.2.
Matt
public static boolean validateTwoFields(
Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest request,
ServletContext application) {
String value = ValidatorUtils.getValueAsString(
bean,
field.getProperty());
String sProperty2 = field.getVarValue(secondProperty);
String value2 = ValidatorUtils.getValueAsString(
bean,
sProperty2);
if (!GenericValidator.isBlankOrNull(value)) {
try {
if (!value.equals(value2)) {
errors.add(field.getKey(),
Resources.getActionError(
application,
request,
va,
field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
Resources.getActionError(
application,
request,
va,
field));
return false;
}
}
return true;
}
-
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?)
One more comment about the difficult of contribution to open source projects in general. I have used a great deal of open source code and modified it quite a bit, but have never been successful in making contributions, although I have made more than one attempt. The problem I have is that I don't use all the same tools as the typical open source project, i.e. Visual SourceSafe instead of CVS. Of course if you step into a project the size of struts without having experience if the background tools, sh.. quickly hits the fan and you have no hope of making a useful contribution. I have no good answers for this, just passing on my $.02... Edgar -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 9:47 AM To: Struts Developers List Subject: Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?) Personally, I find the Struts build files to be complex and confusing. I've come to associate Maven with easy builds because building commons components (including the distro, website, tests, etc) is a snap compared to Struts. I agree that storing jars in cvs isn't a good idea which is why using Maven is so nice; it downloads the correct jars automatically. Anything we can do to make the build more straightforward, whether it's with Ant or Maven, is a good thing :-). David --- Joe Germuska [EMAIL PROTECTED] wrote: 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 -- 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 Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.638 / Virus Database: 409 - Release Date: 3/21/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.638 / Virus Database: 409 - Release Date: 3/21/2004 - 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?)
David Graham [EMAIL PROTECTED] wrote: Personally, I find the Struts build files to be complex and confusing. Two weeks ago, I tried to build the struts 1.1 source package against commons-collections-3.0.jar in order to run the unit tests and insure struts still worked properly. After several hours of trying to set it up and make it work, I finally gave up. There is definitely room for improvement in the build/test process. Like those who posted before me, I don't care if it's ant or maven, only that it works. As a counter-example, on the Cayenne project we have 24 external jar files that are stored in otherlib on CVS, but at least the project builds and tests out of the box. -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coming out for JSF + Struts, was: Struts JSR?
Quoting Thomas L Roche [EMAIL PROTECTED]: Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM) summary: McClanahan should clearly state *in some major publication* * that JSF does/will not replace Struts * how JSF and Struts will likely tend to specialize, in future * how probable specializations will complement (and compete) in webapp development Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 But I think either of us would rather be developing Struts than evangelizing Struts. This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. Frankly, I'm perplexed why the propagation of the latter has gone unchecked for so long. That's actually easy to understand. People believe what they want to believe, no matter what I or anyone else says. I've said exactly the same thing about the relationship between Struts and JavaServer Faces for the last 18 months, and it's going to work out pretty much exactly as I've been saying all along. That doesn't mean anyone is listening, however. My personal plan is to speak more with code than with words, and ensure that Struts continues to include useful functionality that is not present in the J2EE platform and its associated standards. That way, the choice of whether or not to use Struts will be based on benefits you gain from using it, just like it always has been, and just like it was P.J. (pre-JavaServer Faces :-). Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles for alternative presentation technologies (RE: branching 1.2 and 1.3 and CVS reorg for TLP status)
Quoting Joe Germuska [EMAIL PROTECTED]: At 5:24 PM -0800 3/21/04, Craig R. McClanahan wrote: I think the presentation-tier-independent things about Tiles (like mapping forwards to definitions) should be built in to the core, so there isn't any such thing as a separate TilesRequestProcessor (or a separate chain or whatever). In turn, this probably means we might need an API abstraction that alternative presentation tier technologies can use to integrate themselves into the underlying support. I managed to make Tiles work with struts-chain with a single pre-processor Command. It basically looks up a tiles definition and replaces the ForwardConfig returned from an action with its own that has a path which RequestDispatcher to which can forward. But it still uses the TilesPlugIn... is that part of what you think should be moved up into the core? Or do you think even the single Command is not the best future implementation? I'll express my goals for this from a couple of perspectives: From the user's perspective, the fact that I'm using Tiles (or not) should not require anything extra in the config (other than adding the definitions of the tiles themselves, of course). This probably implies that the configuration data migrates into struts-config.xml as well. From the Struts developer perspective, I don't want to have to maintain two request processors (or really even two command chains) -- the standard chain should handle requests whether or not you reference a Tile. So, if your command that looks up the Tiles definition works on non-Tiles requests as well, we can just build it in to the standard chain and call it good. Joe Craig - 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?)
Quoting David Graham [EMAIL PROTECTED]: Personally, I find the Struts build files to be complex and confusing. I've come to associate Maven with easy builds because building commons components (including the distro, website, tests, etc) is a snap compared to Struts. I agree that storing jars in cvs isn't a good idea which is why using Maven is so nice; it downloads the correct jars automatically. It's also possible to set up Maven with a local repository so that offline builds still work, too. Anything we can do to make the build more straightforward, whether it's with Ant or Maven, is a good thing :-). Yep ... that's why we need to finish the how many repositories discussion so we can start migrating towards something that is simpler. David Craig --- Joe Germuska [EMAIL PROTECTED] wrote: 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 -- 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 Tax Center - File online. File on time. 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]
DO NOT REPLY [Bug 26684] - bean:write/ causes incorrect table rendering when writing an empty string property
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26684.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=26684
bean:write/ causes incorrect table rendering when writing an empty string property
--- Additional Comments From [EMAIL PROTECTED] 2004-03-22 18:09 ---
I reckon you are getting a nullpointerexception when you dereference
'personnel', or 'reservePersonnel'.
What you describe: getting no output from any of the html/jsp shown can happen
when the response has been committed (so the server can't send you an exception)
but an exception has occured in the execution of the jsp. We know its not a
compile-time error because you say you get output in some circumstances.
You can make these errors visible if they're not already being logged...
td align=right
% try { %
bean:write name=NonJrfcSummaryForm property='%
= personnel.reservePersonnel(+ posType.getPersonnelTypeId() +) %'/
nbsp;
% } catch (Throwable t) {
t.printStackTrace(new PrintWriter(out));
} %
/td
If you mean 'no output from any of the html/jsp shown but /everything after it
on the page is output/' then something else is wrong.
NB, some browsers show 'fixed' source when you ask for the source, eg adding
/tr/table/html, in your case. Open-tags or text, like ptest/p output
after the error would be proof that something odd is going on.
-
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?)
At 11:52 AM -0500 3/22/04, Mike Kienenberger wrote: Two weeks ago, I tried to build the struts 1.1 source package against commons-collections-3.0.jar in order to run the unit tests and insure struts still worked properly. After several hours of trying to set it up and make ... Like those who posted before me, I don't care if it's ant or maven, only that it works. Do you have the energy to try again with Maven? It should be as simple as adding a couple of lines to build.properties in your local Struts CVS sandbox: maven.jar.override=on maven.jar.commons-collections=3.0 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: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mon, 22 Mar 2004 09:53:02 -0800, Craig R. McClanahan wrote: Yep ... that's why we need to finish the how many repositories discussion so we can start migrating towards something that is simpler. I continue to think that the easiest thing in the long run will be a module for each product. Where a product is equivalent to a Maven artifact or a deliverable with its own release cycle. So, if infrastructure doesn't care, and we can centralize the permissions, I'd like to go back to something like * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please correct me if I m wrong
Execution of html:checkbox name=mailSent property=mailSent value=Sharad tag : name - Used to get value of the checkbox once the form is submitted. property - used to map the status, i.e. whether the checkbox shd be Yes or No, to the bean property. value - value of the checkbox. if I m right then is it necessary to specify the name and property with the literals ? Please explain as this is eating my head out. Please don't refer me to Jakarta site as I couldn't figure out anything from there.
Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
On Mar 22, 2004, at 11:28 AM, Ted Husted wrote: On Mon, 22 Mar 2004 09:53:02 -0800, Craig R. McClanahan wrote: Yep ... that's why we need to finish the how many repositories discussion so we can start migrating towards something that is simpler. I continue to think that the easiest thing in the long run will be a module for each product. Where a product is equivalent to a Maven artifact or a deliverable with its own release cycle. So, if infrastructure doesn't care, and we can centralize the permissions, I'd like to go back to something like * core (including tiles and validator) * examples * site * whiteboard (or sandbox) * opt-taglib * opt-el * opt-faces -Ted. 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. My $0.02. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27239] - bug in html:javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27239 bug in html:javascript [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-03-22 19:28 --- I just tried this with the latest nightly build (20040322) and it's still broken. If I have the following in validation.xml, my JSP renders fine: formset form name=uploadForm field property=name depends=required arg0 key=uploadForm.name/ /field !-- Client-side Javascript won't catch this, but server-side will -- field property=theFile depends=required arg0 key=uploadForm.file/ /field /form /formset If I remove it, I get: javax.servlet.jsp.JspException: No form found under 'uploadForm' in locale 'en_US' at org.apache.struts.taglib.html.JavascriptValidatorTag.renderJavascript(JavascriptValidatorTag.java:342) at org.apache.struts.taglib.html.JavascriptValidatorTag.doStartTag(JavascriptValidatorTag.java:313) at org.apache.jsp.uploadForm_jsp._jspx_meth_html_javascript_0(uploadForm_jsp.java:411) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validating Two Fields - how to do in 1.2?
Nevermind - changing everything to ActionMessages solved it. Should've
known. Below are the files I had to change - hopefully this helps folks
in the future. I'll update my site when 1.2 is released. When's that
going to happen - August? ;-)
http://tinyurl.com/3x4nw
http://tinyurl.com/2rm65
Matt
-Original Message-
From: Matt Raible [mailto:[EMAIL PROTECTED]
Sent: Monday, March 22, 2004 9:36 AM
To: [EMAIL PROTECTED]
Subject: Validating Two Fields - how to do in 1.2?
My popular validate-two-fields howto seems to be broke with
the Struts nightly (20031202) build I'm using. The following
(which works w/ Struts 1.1) throws a NPE at the first errors.add():
public static boolean validateTwoFields(Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest request) {
String value =
ValidatorUtils.getValueAsString(bean,
field.getProperty());
String sProperty2 = field.getVarValue(secondProperty);
String value2 = ValidatorUtils.getValueAsString(bean,
sProperty2);
if (!GenericValidator.isBlankOrNull(value)) {
try {
if (!value.equals(value2)) {
errors.add(field.getKey(), // NPE THROWN HERE
Resources.getActionError(request, va, field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
Resources.getActionError(request,
va, field));
return false;
}
}
return true;
}
I tried adding if (errors == null) errors = new
ActionErrors();, then everything works fine, but
getActionError is deprecated. So how do I upgrade this to 1.2?
Looking at the example (code below) in the docs
(http://jakarta.apache.org/struts/userGuide/dev_validator.html
), there signature of this method has changed slightly,
adding ServletContext application. Also, the
Resources.getActionError isn't valid and and
errors.add(String, ActionError) is deprecated.
Any ideas? I'll try upgrading to a newer build - but I
wanted to get this archived since folks will experience it
migrating from 1.1 to 1.2.
Matt
public static boolean validateTwoFields(
Object bean,
ValidatorAction va,
Field field,
ActionErrors errors,
HttpServletRequest request,
ServletContext application) {
String value = ValidatorUtils.getValueAsString(
bean,
field.getProperty());
String sProperty2 = field.getVarValue(secondProperty);
String value2 = ValidatorUtils.getValueAsString(
bean,
sProperty2);
if (!GenericValidator.isBlankOrNull(value)) {
try {
if (!value.equals(value2)) {
errors.add(field.getKey(),
Resources.getActionError(
application,
request,
va,
field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
Resources.getActionError(
application,
request,
va,
field));
return false;
}
}
return true;
}
-
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 NOT REPLY [Bug 27861] - Add better error reporting to bean:define tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27861. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27861 Add better error reporting to bean:define tag [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|taglibs-|struts- |[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-03-22 23:37 --- Reassign to struts-dev from taglibs-dev. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/userGuide release-notes.xml
husted 2004/03/22 17:02:30 Modified:doc/userGuide release-notes.xml Log: Update release notes. Revision ChangesPath 1.50 +28 -2 jakarta-struts/doc/userGuide/release-notes.xml Index: release-notes.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/release-notes.xml,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- release-notes.xml 20 Feb 2004 16:35:17 - 1.49 +++ release-notes.xml 23 Mar 2004 01:02:30 - 1.50 @@ -152,7 +152,10 @@ strongGeneral Changes/strong /p ul - liAdd inital STATUS LOG, as of 30-Dec-2003./li + li2003-03-14 - Move license on all source code files to ASL 2.0./li +/ul +ul + li2003-12-30 - Add inital STATUS LOG./li /ul p strongBuild Changes/strong @@ -188,6 +191,9 @@ strongAction Package Changes/strong [ codeorg.apache.struts.action/code]/p ul + li2004-03-16 - ActionForward - Add copy constructor./li +/ul +ul li2004-01-24 - Enhance DynaActionForm so that it can be initialized using a FormBeanConfig object. Add corresponding method to RequestUtils to create an ActionForm by passing only a FormBeanConfig and an ActionServlet object./li li2004-01-19 - Push findException from ActionMapping up to ActionConfig so that everyone can take advantage of the superclass search logic./li /ul @@ -254,10 +260,14 @@ strongContrib Packages/strong [ code/contrib/code]/p ul +li2004-02-29 - struts-chain: Fix problem with large uploads being deleted if validation failed./li +/ul +ul li2004-01-15 - struts-chain: Add Tiles support. Add null check for type, to support forward actions; also add commons loggging/li li2004-01-14 - struts-chain: Add support for 'unknown' actions./li /ul ul + li2004-03-08 - Struts-Faces updated for JSF 1.0 final release./li li2003-12-31 - struts-faces: Initial support for Tiles; partial Tilesization of example app; *not* ready for prime time but comments definately welcome./li li2003-12-29 - struts-faces: Various updates regarding the JSF Final Draft and to prepare for Tiles support./li li2003-12-17 - struts-jericho: Whiteboard directory for Struts-Jericho, a working proposal for Struts 2.x./li @@ -284,6 +294,9 @@ strongTaglib Package Changes/strong [ codeorg.apache.struts.taglib/code]/p ul +li2004-02-24 - Move test for null validator form inside createDynamicJavascript so that those who use the tag to generate static javascript don't get a JspException./li +/ul +ul li2003-09-09 - TagUtils: Log error message when keys or bundles are missing./li /ul ul @@ -313,6 +326,9 @@ strongHTML Taglib Package Changes/strong [ codeorg.apache.struts.taglib.html/code]:/p ul +li2003-03-08 - JavascriptValidatorTag - Allow multiple forms to be on the same page by generating a unique variable name based on form name. /li +/ul +ul li2004-02-14 - Substitute - for / in JavaScript function name when form is subclass of ValidatorActionForm./li li2004-02-07 - Add module attribute to IncludeTag, ImgTag, LinkTag, and RewriteTag, as well as to Forward. This permits a module to be referenced by name (or prefix) for direct cross-linking between modules./li @@ -326,7 +342,7 @@ li2004-01-01 - In link-related tags, allow LocalCharacterEncoding to be specified conditionally./li /ul ul - li2003-11-28 JavascriptValidatorTag - Removed getNextVar() and replaceChar() methods and use a simpler javascript identifier naming scheme. All variables with be named a0, a1, etc. to prevent using reserved words as variable names./li + li2003-11-28 - JavascriptValidatorTag - Removed getNextVar() and replaceChar() methods and use a simpler javascript identifier naming scheme. All variables with be named a0, a1, etc. to prevent using reserved words as variable names./li /ul ul li2003-08-19 - Remove request scope references from messages tag. The messages are searched for in all scopes./li @@ -353,6 +369,9 @@ strongNested Taglib Package Changes/strong [ codeorg.apache.struts.taglib.nested/code]:/p ul +li2004-03-22 - Add missing filter attribute to nested:options and nested:optionsCollection./li +/ul +ul li2004-01-01 - Correct operation of NestedMessage* tags by
Re: Please correct me if I m wrong
On Mon, 22 Mar 2004 12:30:11 -0600, Bhardwaj, Sharod wrote: Execution of tag : name - Used to get value of the checkbox once the form is submitted. property - used to map the status, i.e. whether the checkbox shd be Yes or No, to the bean property. value - value of the checkbox. if I m right then is it necessary to specify the name and property with the literals ? Please explain as this is eating my head out. Please don't refer me to Jakarta site as I couldn't figure out anything from there. The place to ask questions like this is the USER list. The thing with checkboxes is that the browsers do not submit them if they are not checked. If the checkbox input is there, it was checked. If the checkbox is not in the request, then it is not present. Typically people will represent checkboxes with a boolean that defaults to false. So if they are checked, then they are set to true. But do not post any follow questions here. Post to the USER list instead. -Ted. - 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 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. 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. :( :( :( 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. 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. 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. :) 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 hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things first!) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27239] - bug in html:javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27239 bug in html:javascript --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 01:16 --- If no one has the time or energy to refactor this logic so we can see what the problem is, we may have to roll back to 1.44. Another issue is that the multiple form enhancemement (version 1.48) has moved our dependency to the validation nightly build. We may want to cut 1.2.1 soon and would not want it's GA potential blocked. Perhaps we could work on these issues in the 1.3.x series, which will include other significant changes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts TLP Sub-projects (RE: Making Struts Build Easier)
+1 on this!! You hit the nail on the head. Many people (mostly managers) are reluctant to adopt Struts add-ons because they are not perceived as having the same tried and true stamp as the official Struts core. I think doing this would be a huge boon for Struts and would foster a lot of the development interest that's been talked about over the past couple of days. Also, +1 on having the creators of those projects become committers so long as they've shown a protracted history in maintaining their respective projects and have an interest to continue doing so. -James http://www.jamesholmes.com/struts/ - 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 hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things first!) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
James Holmes wrote: +1 on this!! You hit the nail on the head. Many people (mostly managers) are reluctant to adopt Struts add-ons because they are not perceived as having the same tried and true stamp as the official Struts core. I think doing this would be a huge boon for Struts and would foster a lot of the development interest that's been talked about over the past couple of days. Also, +1 on having the creators of those projects become committers so long as they've shown a protracted history in maintaining their respective projects and have an interest to continue doing so. -James http://www.jamesholmes.com/struts/ Would the same principle work with people who have taken Struts and integrated or embedded as another framework? Having spent some type integrating 1.1 into Expresso Framework in 2002, in our case can we be classified as Struts extenders? Also some repository will not want to become a sub project of Struts because of logical sense, politics or legal entity status? - 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. Kind regards -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts TLP Sub-projects (RE: Making Struts Build Easier)
Not exactly sure what you're referring to here, but am guessing you mean would there be an offer for integrators/embedders to become committers? I personally think this makes sense for cases like Expresso. My point was to show my support for Ted's proposal (of sorts) that projects like stxx and sslext become sub projects of the top-level Struts project. -James http://www.jamesholmes.com/struts/ -Original Message- From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 9:50 PM To: Struts Developers List Subject: Re: Struts TLP Sub-projects (RE: Making Struts Build Easier) James Holmes wrote: +1 on this!! You hit the nail on the head. Many people (mostly managers) are reluctant to adopt Struts add-ons because they are not perceived as having the same tried and true stamp as the official Struts core. I think doing this would be a huge boon for Struts and would foster a lot of the development interest that's been talked about over the past couple of days. Also, +1 on having the creators of those projects become committers so long as they've shown a protracted history in maintaining their respective projects and have an interest to continue doing so. -James http://www.jamesholmes.com/struts/ Would the same principle work with people who have taken Struts and integrated or embedded as another framework? Having spent some type integrating 1.1 into Expresso Framework in 2002, in our case can we be classified as Struts extenders? Also some repository will not want to become a sub project of Struts because of logical sense, politics or legal entity status? - 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. Kind regards -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: coming out for JSF + Struts, was: Struts JSR?
A simple google search provides a wealth of information: http://www.google.com/search?q=craig+struts+jsf PS Unless I'm missing the sub plot where the criminal mastermind/evil genius tricks us all into using the wrong framework, maybe I'm mistaken, but a simple 'Hey, Thanks Craig' for all the passion and hard work on Struts and JSF is better than the conspiracy theory innuendos. ;-) So, Thanks Craig, and by all means, let your code do the talking! (sorry, temptation to rant got me) -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 11:35 AM To: Struts Developers List Subject: Re: coming out for JSF + Struts, was: Struts JSR? Quoting Thomas L Roche [EMAIL PROTECTED]: Sun, 21 Mar 2004 13:49:45 -0500, Thomas L Roche (not speaking for IBM) summary: McClanahan should clearly state *in some major publication* * that JSF does/will not replace Struts * how JSF and Struts will likely tend to specialize, in future * how probable specializations will complement (and compete) in webapp development Ted Husted Sun, 21 Mar 2004 20:28:17 -0500 But I think either of us would rather be developing Struts than evangelizing Struts. This is not about evangelizing: it's about clarifying the relationship between 2 large parts of J2EE's future, and correcting some (apparently) false perceptions. Frankly, I'm perplexed why the propagation of the latter has gone unchecked for so long. That's actually easy to understand. People believe what they want to believe, no matter what I or anyone else says. I've said exactly the same thing about the relationship between Struts and JavaServer Faces for the last 18 months, and it's going to work out pretty much exactly as I've been saying all along. That doesn't mean anyone is listening, however. My personal plan is to speak more with code than with words, and ensure that Struts continues to include useful functionality that is not present in the J2EE platform and its associated standards. That way, the choice of whether or not to use Struts will be based on benefits you gain from using it, just like it always has been, and just like it was P.J. (pre-JavaServer Faces :-). 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?)
From: Matt Raible [mailto:[EMAIL PROTECTED] I don't care how things are partitioned in CVS, as long as everything builds with one checkout and one command. Along those lines, I'd like to suggest that a complete WAR and/or EAR of examples be included as one command to checkout. I'd even be happy to roll up my sleeves and see about writing the maven/ant stuff to do it. The idea behind this is to make it real simple for people to get the example working to learn Struts. By 1. Download .war file. 2. Place in Tomcat deploy directory. 3. See it work. 4. Look at source (bundled in war). The biggest complaint I get from my customers is they want a simple, plain example of Struts to learn the basics. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27239] - bug in html:javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27239 bug in html:javascript --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 03:16 --- Matt: What exactly is the error? It is supposed to be a feature that the html:javascript tag throws a JSP Exception when you specify dynamicJavascript=true with a form that is not in validation.xml -- if you take the form out of validation.xml, you will cause the exception to be thrown. Using the example webapp from Struts, I can see that the staticJavascript.jsp works without throwing an exception. On the other hand, the client-side validation isn't working, but it also doesn't work when I roll back to JavascriptValidatorTag 1.44. I'll double-check myself, but I wanted to ask Matt to clarify. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
James Holmes wrote: Not exactly sure what you're referring to here, but am guessing you mean would there be an offer for integrators/embedders to become committers? I personally think this makes sense for cases like Expresso. My point was to show my support for Ted's proposal (of sorts) that projects like stxx and sslext become sub projects of the top-level Struts project. I am not going to argue over the latter point. I could not agree more because projects like Stxx, Ssltext, and Workflow are ``true'' extensions of the Struts framework, because they could not logically exist without the Struts core itself. Whereas Expresso Framework existed long before Struts was a glint in Craig's eye. From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED] ==== James Holmes wrote: +1 on this!! You hit the nail on the head. Many people (mostly managers) are reluctant to adopt Struts add-ons because they are not perceived as having the same tried and true stamp as the official Struts core. I think doing this would be a huge boon for Struts and would foster a lot of the development interest that's been talked about over the past couple of days. ==/== Would the same principle work with people who have taken Struts and integrated or embedded as another framework? Having spent some type integrating 1.1 into Expresso Framework in 2002, in our case can we be classified as Struts extenders? Also some repository will not want to become a sub project of Struts because of logical sense, politics or legal entity status? ==== Regards -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27239] - bug in html:javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27239 bug in html:javascript --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 03:22 --- It's the exact same error I had before: http://issues.apache.org/bugzilla/show_bug.cgi?id=27316 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27239] - bug in html:javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27239. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27239 bug in html:javascript --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 03:49 --- I don't understand why you would specify dynamicJavascript='true' for a form that doesn't exist. The latest versions of the tag do support generating an external static JavaScript page using syntax as in http://cvs.apache.org/viewcvs.cgi/jakarta-struts/web/example/staticJavascript.jsp?view=markup I have just verified this by running the 'example' webapp from CVS head (ant compile.webapps followed by moving the example webapp into $CATALINA_HOME/webapps) A little logging code added to JavascriptValidatorTag shows that my problem with client side validation is at least partially related to my build of commons-validator, which may have been done hastily. - 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]
cvs commit: jakarta-struts/conf/test/tomcat33 server.xml
martinc 2004/03/22 20:28:27 Modified:conf/test/tomcat33 server.xml Log: Change the port number for the AJP-12 connector so that it doesn't conflict with the default one in the container. (This probably isn't needed at all, but I'll leave that for someone more familiar with Tomcat to decide.) Revision ChangesPath 1.4 +1 -1 jakarta-struts/conf/test/tomcat33/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-struts/conf/test/tomcat33/server.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- server.xml1 Aug 2003 04:58:08 - 1.3 +++ server.xml23 Mar 2004 04:28:27 - 1.4 @@ -150,7 +150,7 @@ tomcatAuthentication=false -- -Ajp12Connector port=8007 / +Ajp12Connector port=8008 / !-- Context definitions can be placed here ( not recommended ) or - 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, 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. 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. 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 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 hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things first!) I'd be open to it, but I think we have a lot of things we'd want to do to get our own house in order before we actually take action on this. I also think it might be a tricky issue in some respects. For example, we'll be faced with making subjective decisions on potentially substantial bodies
DO NOT REPLY [Bug 27777] - Temp files stay in work directory after upload
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=2. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=2 Temp files stay in work directory after upload [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 05:31 --- *** This bug has been marked as a duplicate of 27477 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27204] - HTTP 500 with not existing properties of a specific locale
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27204. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27204 HTTP 500 with not existing properties of a specific locale [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 06:10 --- I don't know what the problem is that you are having, but your analysis and solution are incorrect. The messageKey() method does not return a key that should match the resource key itself, but a key used to cache the locale specific version of that resource. See the Javadoc for messageKey(). As James suggested, you should bring this up on the struts-user list. You'll want to provide somewhat more information about the configuration of your web app as well as your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/config ActionConfigMatcher.java
martinc 2004/03/22 22:27:06
Modified:src/share/org/apache/struts/config ActionConfigMatcher.java
Log:
Make ActionConfigMatcher$Mapping serializable.
PR: 27376
Submitted by: Fabio Grassi
Revision ChangesPath
1.10 +4 -4
jakarta-struts/src/share/org/apache/struts/config/ActionConfigMatcher.java
Index: ActionConfigMatcher.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/config/ActionConfigMatcher.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ActionConfigMatcher.java 14 Mar 2004 06:23:47 - 1.9
+++ ActionConfigMatcher.java 23 Mar 2004 06:27:06 - 1.10
@@ -211,7 +211,7 @@
/**
* Stores a compiled wildcard pattern and the ActionConfig it came from.
*/
-private class Mapping {
+private class Mapping implements Serializable {
/** The compiled pattern. */
private int[] pattern;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27376] - ActionConfigMatcher$Mapping not serializable
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27376. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27376 ActionConfigMatcher$Mapping not serializable [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-03-23 06:27 --- Fixed in the 20040323 nightly build. - 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?)
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. 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 hiding our light under a bushel. Now, I haven't brought this idea up to any of the other Committers, and have no idea how any else will feel about it. But it is something that I would personally like to work towards -- once we have our existing code rationalized. (First things
Re: Struts TLP Sub-projects (RE: Making Struts Build Easier)
Quoting James Holmes [EMAIL PROTECTED]: +1 on this!! Agreed. You hit the nail on the head. Many people (mostly managers) are reluctant to adopt Struts add-ons because they are not perceived as having the same tried and true stamp as the official Struts core. I think doing this would be a huge boon for Struts and would foster a lot of the development interest that's been talked about over the past couple of days. Also, +1 on having the creators of those projects become committers so long as they've shown a protracted history in maintaining their respective projects and have an interest to continue doing so. There's yet another reason that is important -- the ASF board wants to ensure that everything packaged in an ASF software distribution has either the Apache License or something less restrictive. Currently, we're fine because all we ship is ASF code. Bringing add-ons under the Struts TLP umbrella means that they'd automatically be Apache licensed as well. -James http://www.jamesholmes.com/struts/ Craig - 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
