DO NOT REPLY [Bug 35956] - Updated CheckStyle rules file
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=35956. 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=35956 --- Additional Comments From [EMAIL PROTECTED] 2005-08-24 08:01 --- There was some discussion about the suggested new checks on the dev list... IIRC, the only ones that seemed to have any kind of support were... * ImportOrder - I don't think anyone objected, but no one thought it was important either. * CovariantEquals - I believe this one was seen as a good idea. * StringLiteralEquality - I believe the consensus was that only a beginner would make the mistake anyway, but it does no harm to check for it. * PackageDeclaration - Was seen as a basically worthless check since code wouldn't be compiling if such a mistake was made, but again, does no harm to activate it. As I recall, all the others resulted in some good points against activating them. I think the IllegalCatch check might be worth some further discussion, but the rest seem to be discardable from consideration at this point. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36327] - [Standalone Tiles] Test fails due to URL problems on different platforms.
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=36327. 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=36327 --- Additional Comments From [EMAIL PROTECTED] 2005-08-24 08:21 --- No problems here. The tests now pass under Windows XP Pro and Cygwin with either Ant and Maven. (JDK 1.4.2_03 and 1.5.0_01 both work.) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: ApacheCon 2005 SanDiego
Craig, My Shale talk got accepted as well. As long as you're scheduled on Monday or Tuesday (I have to fly out on Wednesday) I should be able to join you. Craig Will it be a *tandem* talk with David Geary? -Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
ah... were did you read it ?!? Rod Johnson and many others. But, that should be a start to think about, Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]: Project struts-core (in module struts) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-core has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 35 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - fulcrum-quartz : Services Framework - jakarta-turbine-jcs : Cache - quartz : Job Scheduler - struts-core : Model 2 Model-View-Controller framework for Servlets and JSP - struts-tiles : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://vmgump.apache.org/gump/public/struts/struts-core/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [struts.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property xerces.jar. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/struts/struts-core/gump_work/build_struts_struts-core.html Work Name: build_struts_struts-core (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar -Djakarta-oro.jar=/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-24082005.jar -Dcommons-chain.jar=/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-24082005.jar -Dantlr.jar=/usr/local/gump/packages/antlr-2.7.3/antlr.jar -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Dcommons-lang.jar=/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-24082005.jar -Dcommons-logging.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-24082005.jar -Djdk.version=1.4 -Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar -Dcommons-validator.jar=/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar -Dcommons-digester-rss.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/src/examples/rss/dist/commons-digester-rss.jar -Dxerces.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24082005.jar -Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-24082005.jar -Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar dist [Working Directory: /usr/local/gump/public/workspace/struts/core] CLASSPATH:
[EMAIL PROTECTED]: Project struts-core (in module struts) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-core has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 35 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - fulcrum-quartz : Services Framework - jakarta-turbine-jcs : Cache - quartz : Job Scheduler - struts-core : Model 2 Model-View-Controller framework for Servlets and JSP - struts-tiles : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://vmgump.apache.org/gump/public/struts/struts-core/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [struts.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property xerces.jar. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/struts/struts-core/gump_work/build_struts_struts-core.html Work Name: build_struts_struts-core (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar -Djakarta-oro.jar=/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-24082005.jar -Dcommons-chain.jar=/usr/local/gump/public/workspace/jakarta-commons/chain/target/commons-chain-24082005.jar -Dantlr.jar=/usr/local/gump/packages/antlr-2.7.3/antlr.jar -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Dcommons-lang.jar=/usr/local/gump/public/workspace/jakarta-commons/lang/dist/commons-lang-24082005.jar -Dcommons-logging.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-24082005.jar -Djdk.version=1.4 -Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar -Dcommons-validator.jar=/usr/local/gump/public/workspace/jakarta-commons/validator/dist/commons-validator.jar -Dcommons-digester-rss.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/src/examples/rss/dist/commons-digester-rss.jar -Dxerces.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-24082005.jar -Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-24082005.jar -Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar dist [Working Directory: /usr/local/gump/public/workspace/struts/core] CLASSPATH:
Re: Thoughts on Checkstyle stuff
I saw the tread, but I haven't followed that discussion. I would rather wait till after 1.3.0 is out there. If you can wait till things settle down, I'd be happy to apply your fixes then. After all, the activity may make your patches out of date and we would need to do it ourselves or ask for help again. Ping me again after 1.3.0 is out and remind me to get on this. Thanks man. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 24, 2005, at 12:43 AM, Frank W. Zammetti wrote: Anyone have a chance to look or think about this? I'd like to continue the work but I'd also like to know if folks are receptive to it or not. Maybe you were all just busier today than I was... I Unfortunately have a car that's getting ready to die any day now, so most of my time was spent leisurely comparing and running numbers all day :) Frank Frank W. Zammetti wrote: Hi all, I'm just trying to guage what the consensus is with regard to applying Checkstyle fixes (yes, it's a bit of a strange itch perhaps, but it's *my* itch! :) )... I just submitted a batch (ticket #36306), and would like to resolve as many more as possible, but I'd like to know what everyones' thinking is with regard to when they will/should be applied... would I be putting in a little too much effort if I'm trying to get them into the first 1.3 release? What I mean is, if everyone thinks they should be put off for a later release then there's no need for me to bust my butt as much, I can work a bit more leisurely on things :) If however, folks think it would be better to get them applied sooner than later, which is my belief frankly, any committer willing to do that in the short term? Just as a quick summary... I counted 4,760 Checkstyle complaints on the current TRUNK, and the batch I just submitted resolves 1,462. Virtually none of it alters actual code, in fact only 178 do and that was just to break up lines longer than 80 characters, so I'd say these are relatively benign fixes (and I'll state what should be assumed: everything compiled fine for me and all unit tests passed). There's still probably 2,000 more or so that would fall into that same relatively safe category (lots of javadocs fixes for example) before I even think about those that might require some actual thought/discussion :) Thanks all! - 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 14471] - [validator] validator-rules.xml JavaScript fails when field not present in jsp
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=14471. 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=14471 --- Additional Comments From [EMAIL PROTECTED] 2005-08-24 14:54 --- (In reply to comment #15) ...Except for the validateRequired method, which by its nature demands that absent required fields generate an error response. Paul, I disagree with this premise. You may have a field that is required only for certain users and is hidden or absent to other users. To me it seems, the absence of any field should ignore any validation. If the field is absolutely required and is not on the form, then that is the fault of the coder. The user will not be able to fix the required error if the field does not exist, so why give them a validation error for a field that does not exist? btw, thank you for fixing the other validation routines to ignore absent fields. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] RE: [ANNOUNCEMENT] New Struts Committer: Gary vanMatre
First, comparing Struts and JSF is like comparing C++ and Visual Basic. Struts is REQUEST-DRIVEN MVC and JSF (Shale) is PAGE CENTRIC RAD (rapid development with tools as in VB). Anyone that cannot see they don't go together, frankly, is not that insightful, in my opinion. The present idea that they go together is one of the more interesting marketing ploys in my recent experience. I have to admit that Craig is not only a superb coder but also a clever politician. I would have bet big money that no one could convince the Struts community to share a bedroom with JSF. I would have lost. I still am amazed. Second, Rod Johnson only has three books out that I know of. There is a whole section on web frameworks in Ch. 13 of Expert One-on-One J2EE Development without EJB. That is where I read it. You can read the same thing from numerous other folks in the Struts lists as well. Of course, if you don't want to see it, you won't. Third, I am amazed that people who consider themselves to be expert in this area, and who should be expert in this area given their status, people such as yourself, Matthias, even argue this point. A modicum of understanding of the two frameworks shows that they are like night and day. Indeed, Craig is constantly trumpeting that JSF is a new deal which should tell you that it is not what he now decries as the old deal, Struts. He says it is a huge architectural shift. He is right. You CANNOT combine the two. You CAN mix them into what is essentially a mush, a hodge-podge. But, you cannot combine them. You have to have a switch that chooses one over the other in the mix. That is what Rod Johnson says and that is what I agree with. Fourth, I am about to leave the debate arena on this one, however. This is all too nutty for me to stick with any longer. I don't mind a good spirited debate on architecture, but I am not intersted in a political community with its head in the sand. When a VB expert is voted into the C++ expert community, that is enough for me. And, when a JSF expert is voted into the Struts community, that is enough for me. I have to admit that I am completely enamored anyway with the Spring IoC and AOP approach and believe that a one can build something akin to the Struts package there. I will, of course, remain interested in Struts even though the interest will be more one of morbid fascination with the process that is happening here. Cheers! On 8/24/05, Matthias Wessendorf [EMAIL PROTECTED] wrote: ah... were did you read it ?!? Rod Johnson and many others. But, that should be a start to think about, Dave. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Shale Volunteers (was Re: [OT] RE: [ANNOUNCEMENT])
Since the ANNOUNCEMENT thread is veering off-topic On 8/24/05, Matthias Wessendorf [EMAIL PROTECTED] wrote: ah... were did you read it ?!? Rod Johnson and many others. But, that should be a start to think about, Dave. From the ASF's point of view, the only thing that matters is whether there are volunteers who are ready, willing, and able to create and maintain the software in the Apache Way. We're not a steering commitee trying to decide what's best for everyone. We're a bunch of engineers who want to share the software we're using with who other engineers who might want to use it. Since there are volunteers ready, willing, and able to create and maintain Shale in the Apache Way, the only question that remains is where to find more volunteers. The people actually working on Shale now seem to think that the Apache Struts project is a good place to find more volunteers. Since Shale is to JSF what Struts Classic is to JSP, the Struts PMC agreed the idea had merit, and we made Shale a subproject. Meanwhile, other volunteers continue to work on Struts Classic, unabated. Of course, at some point in time, the people actually working on Shale may decide that they could find more volunteers as a top-level project, or as subproject of another Apache TLP (like, say, Apache MyFaces), or somewhere else in cyberspace. The Shale volunteers might then choose to continue work in some other repository. Or they might decide to continue working here. But, the only people entitled to make that decision are the ones creating and maintaining the Shale codebase. The most the rest of can do is wish them godspeed. We're seeing a similar thing happening with Tiles today. Right now, volunteers are extracting Tiles into a separate subproject. Once that is done, the volunteers might decide to continue work under the Struts repository, or somewhere else. But, whatever they decide, the decision will be driven by the simple question: Where will we find other volunteers to help? -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
Thanks, Wendy, increasing the memory setting did the trick. It just finished building, and everything looks as expected. I can get cracking on the fnal round of website changes now, and then we can take a deep breath and roll this beast :) -Ted. On 8/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 8/23/05, Ted Husted [EMAIL PROTECTED] wrote: I tried building the whole enchalida on another machine with Maven 1.0.2 and JDK 1.4.2.9, and ran into the same out of memory issue. Ditto for running the multiproject build. Are we suppose to be using 1.0.2 for this or the 1.1 beta? I'm using Maven 1.0.2, but having run into the same problem with memory earlier, I do have MAVEN_OPTS=-Xmx1024m set. Reorganizing the website should be a matter of moving files and modifying the various navigation.xml files. (Well, and rewriting a bunch of pages.) Unfortunately, it seems that once you have user supplied documentation in xdocs that you need to add to the menu, you lose Maven's auto-generated menus (except for the last section titled Project Documentation.) Someone on maven-user suggested using XML entities to bring in the common sections of the menu (they could live in 'build') but I didn't get that far. -- Wendy -- HTH, Ted. http://www.husted.com/poe/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shale Volunteers (was Re: [OT] RE: [ANNOUNCEMENT])
This is one point of view, Ted, and one that needs to be considered of course. I think it is not accurate myself. Another point of view is that Struts needs to come up to snuff in the arena and is being left behind. Having half the community spend time on a completely incompatible framework like JSF will ensure that it won't recover. That is nother point of view. Having half of the other half chase the patch of a chain-based architecture launched off a template-method design won't help either. That also is another point of view. I suspect the result will be that Craig will get what he was aiming for, the Struts name for JSF. If so, my hats are off to him for a remarkable campaign. While, I am always willing to fight the good fight, I have to admit that this one looks lost and that, since I am not a JSF guy, my choices have been effectively narrowed to a non-Struts future in my coding. This does not mean, of course, that there is not a long period of weaning off Struts. Business moves slower than developing ideas. I am presently switching over to Spring, and will try to develop a Struts-like architecture there. (I know there is a Struts plugin, but I would like an up-to-date IoC, AOP, framework under a real Struts.) I probably will be better off there anyway, since I am philosophically much closer to what is going on there. As Ted keeps noting, this community is tied a great deal to the projects they are working on and really has no time to sit back and think things through before coding. Code is what is master here, not thought. That is understandable. I am sure, as people are always saying around here that there is a niche for JSF. People who need tools will love it. Heck, there was a niche for Windows, wasn't there? Maybe JSF will finally succeed. Maybe not. But, it sure doesn't do what I want done. This sort of solution works against what I think is the future, which is a smaller group of highly educated, well-trained and efficient coders as opposed to a large group of tool jockeys that really don't know what they are working with when coding. Good luck to you all. While my feet are going elsewhere, I certainly will remain interested in the progress of this community. Cheers, and I hope to have been of some assistance in clarifying something for someone. Sorry that so many got their knickers in a twist. On 8/24/05, Ted Husted [EMAIL PROTECTED] wrote: Since the ANNOUNCEMENT thread is veering off-topic On 8/24/05, Matthias Wessendorf [EMAIL PROTECTED] wrote: ah... were did you read it ?!? Rod Johnson and many others. But, that should be a start to think about, Dave. From the ASF's point of view, the only thing that matters is whether there are volunteers who are ready, willing, and able to create and maintain the software in the Apache Way. We're not a steering commitee trying to decide what's best for everyone. We're a bunch of engineers who want to share the software we're using with who other engineers who might want to use it. Since there are volunteers ready, willing, and able to create and maintain Shale in the Apache Way, the only question that remains is where to find more volunteers. The people actually working on Shale now seem to think that the Apache Struts project is a good place to find more volunteers. Since Shale is to JSF what Struts Classic is to JSP, the Struts PMC agreed the idea had merit, and we made Shale a subproject. Meanwhile, other volunteers continue to work on Struts Classic, unabated. Of course, at some point in time, the people actually working on Shale may decide that they could find more volunteers as a top-level project, or as subproject of another Apache TLP (like, say, Apache MyFaces), or somewhere else in cyberspace. The Shale volunteers might then choose to continue work in some other repository. Or they might decide to continue working here. But, the only people entitled to make that decision are the ones creating and maintaining the Shale codebase. The most the rest of can do is wish them godspeed. We're seeing a similar thing happening with Tiles today. Right now, volunteers are extracting Tiles into a separate subproject. Once that is done, the volunteers might decide to continue work under the Struts repository, or somewhere else. But, whatever they decide, the decision will be driven by the simple question: Where will we find other volunteers to help? -Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ApacheCon 2005 SanDiego
May I encourage you to make some form of that talk available on the Struts website? I think it would be very valuable. -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 6:21 PM To: Struts Developers List Subject: Re: ApacheCon 2005 SanDiego At the last minute, Don Brown and I put in for a Struts talk for ApacheCon, which was accepted by the planners: --- Struts 2006: An embarrassment of riches Apache Struts is a hotbed of activity. Struts Classic 1.3, Struts Shale, Struts Ti, Struts OverDrive. Why so many frameworks? How are they different? Why are they all called Struts? Which is the best choice for my next project? In this session, we step back and look at Struts through a wide-angle lense. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
From: Ted Husted [EMAIL PROTECTED] Thanks, Wendy, increasing the memory setting did the trick. It just finished building, and everything looks as expected. I can get cracking on the fnal round of website changes now, and then we can take a deep breath and roll this beast :) I'm not sure if this is necessary, but for Struts 1.2.7, the LICENSE and NOTICE files were in both the overall distribution and in the struts.jar files. Looking at the struts-core nightlies - LICENSE appears in the nightly .zip file - struts-core-1.3.0-dev.jar contains neither LICENSE nor NOTICE http://www.apache.org/dev/apply-license.html says they belong in the top level of the distribution which would at least point to adding NOTICE to the .zip and .tar.gz files. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SORRY]Re: Seeking IT professionals!
Hello, I'd like to excuse for sending my previous message to struts dev. list. I haven't noticed that address in To: field was struts dev list address and not that person's. Thank you, Andrew. Levin, Jennifer wrote: Hi All, The market is at its peak and we are currently looking to fill more then 100 of IT jobs. I am requesting your assistance looking for IT professionals, since I have top 10 financial clients seeking top IT talent for the following searches: 1) C++/ FIX/ Unix/ Sybase/ Equities - will be implementing new algorithmic trading strategies 2) C++/ MFC - in any of the business units such as Equities, Derivatives or Fixed Income 3) C++/ Unix/ Perl/ Python - will be sitting on the trading floor working along side of traders 4) C#/. Net / GUI development and either Sybase or SQL or Oracle with finance background 5) VC++/ MFC/ C++ - development of trading systems and some business knowledge 6) C#/. Net/ Winforms/ Multithreading/ OOD - will work in the front office with traders 7) C#/ .Net/ Java - will work on a front office application at major client on Wall Street 8) C#/. Net/ Project Manager - will manage group of developers within the front office 9) C#/. Net/ GUI design/ SOAP and other middleware technologies - Fixed Income 10) Java/ Perl/ SQL/ Unix/ Linux/ Multithreading/ C++ background - replacing legacy system 11) Java/ C++/ Perl/ Unix/ OOD - will work for Fixed Income group developing analytical models 12) Java/ C++/ Lead - will be a technical lead working on a critical project 13) Java/ J2EE/ JSP/ HTML/ SOAP/ XML / Sybase. Skills desired: C#, Perl, .Net 14) Business Analysts and Project Management - must have financial background 15) ETL/ Informatica Developer - business intelligence with financial background If you know of someone whose background does indeed match or you yourself are interested in hearing more about the following searches, then please call me at your earliest convenience to discuss these opportunities. Also, feel free to attach your resume. I would appreciate any referrals. Thanks in advance. Best Regards, Jennifer Levin Executive Recruiter @ Options Group (212) 982-3539 (work) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on Checkstyle stuff
Hi James, I see this as an ongoing task... the types of things that Checkstyle raises are the types of things that tend to creep in continually, for various reasons, even moreso with a community-driven project like Struts. That being said, I think there is value in getting what is there now taken care of sooner rather than later. Waiting will only result in more issues showing up in the reports down the road, and that will tend, I think, to dissuade anyone from resolving them. It would be easier for these things to never be addressed. Let's face it, it's not what I would consider glamorous work :) That too being said, I don't mind volunteering as the Checkstyle Police, so to speak, ongoing, and try and get it all taken care of. But the sooner they can start being applied, the better. I don't think this is the type of stuff that would impact a 1.3 release either way, but I do think getting as many of these issues resolved before a next release has more value than waiting. That's just my opinion. I don't want to speak for Don here, but his last comment on the ticket would seem to indicate he may agree with this (hope I'm not reading *too* much into it Don :) ). Frank On Wed, August 24, 2005 8:45 am, James Mitchell said: I saw the tread, but I haven't followed that discussion. I would rather wait till after 1.3.0 is out there. If you can wait till things settle down, I'd be happy to apply your fixes then. After all, the activity may make your patches out of date and we would need to do it ourselves or ask for help again. Ping me again after 1.3.0 is out and remind me to get on this. Thanks man. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 24, 2005, at 12:43 AM, Frank W. Zammetti wrote: Anyone have a chance to look or think about this? I'd like to continue the work but I'd also like to know if folks are receptive to it or not. Maybe you were all just busier today than I was... I Unfortunately have a car that's getting ready to die any day now, so most of my time was spent leisurely comparing and running numbers all day :) Frank Frank W. Zammetti wrote: Hi all, I'm just trying to guage what the consensus is with regard to applying Checkstyle fixes (yes, it's a bit of a strange itch perhaps, but it's *my* itch! :) )... I just submitted a batch (ticket #36306), and would like to resolve as many more as possible, but I'd like to know what everyones' thinking is with regard to when they will/should be applied... would I be putting in a little too much effort if I'm trying to get them into the first 1.3 release? What I mean is, if everyone thinks they should be put off for a later release then there's no need for me to bust my butt as much, I can work a bit more leisurely on things :) If however, folks think it would be better to get them applied sooner than later, which is my belief frankly, any committer willing to do that in the short term? Just as a quick summary... I counted 4,760 Checkstyle complaints on the current TRUNK, and the batch I just submitted resolves 1,462. Virtually none of it alters actual code, in fact only 178 do and that was just to break up lines longer than 80 characters, so I'd say these are relatively benign fixes (and I'll state what should be assumed: everything compiled fine for me and all unit tests passed). There's still probably 2,000 more or so that would fall into that same relatively safe category (lots of javadocs fixes for example) before I even think about those that might require some actual thought/discussion :) Thanks all! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thoughts on Checkstyle stuff
From the peanut gallery, I'd like to second Frank's statement in the spirit of fixing broken windows. - George Dinwiddie http://www.idiacomputing.com [EMAIL PROTECTED] -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 10:58 AM To: Struts Developers List Cc: Struts Developers List Subject: Re: Thoughts on Checkstyle stuff Hi James, I see this as an ongoing task... the types of things that Checkstyle raises are the types of things that tend to creep in continually, for various reasons, even moreso with a community-driven project like Struts. That being said, I think there is value in getting what is there now taken care of sooner rather than later. Waiting will only result in more issues showing up in the reports down the road, and that will tend, I think, to dissuade anyone from resolving them. It would be easier for these things to never be addressed. Let's face it, it's not what I would consider glamorous work :) That too being said, I don't mind volunteering as the Checkstyle Police, so to speak, ongoing, and try and get it all taken care of. But the sooner they can start being applied, the better. I don't think this is the type of stuff that would impact a 1.3 release either way, but I do think getting as many of these issues resolved before a next release has more value than waiting. That's just my opinion. I don't want to speak for Don here, but his last comment on the ticket would seem to indicate he may agree with this (hope I'm not reading *too* much into it Don :) ). Frank On Wed, August 24, 2005 8:45 am, James Mitchell said: I saw the tread, but I haven't followed that discussion. I would rather wait till after 1.3.0 is out there. If you can wait till things settle down, I'd be happy to apply your fixes then. After all, the activity may make your patches out of date and we would need to do it ourselves or ask for help again. Ping me again after 1.3.0 is out and remind me to get on this. Thanks man. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 24, 2005, at 12:43 AM, Frank W. Zammetti wrote: Anyone have a chance to look or think about this? I'd like to continue the work but I'd also like to know if folks are receptive to it or not. Maybe you were all just busier today than I was... I Unfortunately have a car that's getting ready to die any day now, so most of my time was spent leisurely comparing and running numbers all day :) Frank Frank W. Zammetti wrote: Hi all, I'm just trying to guage what the consensus is with regard to applying Checkstyle fixes (yes, it's a bit of a strange itch perhaps, but it's *my* itch! :) )... I just submitted a batch (ticket #36306), and would like to resolve as many more as possible, but I'd like to know what everyones' thinking is with regard to when they will/should be applied... would I be putting in a little too much effort if I'm trying to get them into the first 1.3 release? What I mean is, if everyone thinks they should be put off for a later release then there's no need for me to bust my butt as much, I can work a bit more leisurely on things :) If however, folks think it would be better to get them applied sooner than later, which is my belief frankly, any committer willing to do that in the short term? Just as a quick summary... I counted 4,760 Checkstyle complaints on the current TRUNK, and the batch I just submitted resolves 1,462. Virtually none of it alters actual code, in fact only 178 do and that was just to break up lines longer than 80 characters, so I'd say these are relatively benign fixes (and I'll state what should be assumed: everything compiled fine for me and all unit tests passed). There's still probably 2,000 more or so that would fall into that same relatively safe category (lots of javadocs fixes for example) before I even think about those that might require some actual thought/discussion :) Thanks all! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36327] - [Standalone Tiles] Test fails due to URL problems on different platforms.
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=36327. 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=36327 --- Additional Comments From [EMAIL PROTECTED] 2005-08-24 18:18 --- On Mandrake I'm getting the same failure as you. The problem is case-sensitive files. src/test/org/apache/tiles/config/defs1_FR.xml needs to be src/test/org/apache/tiles/config/defs1_fr.xml. It matters on Linux. It doesn't matter on Windows, and surprisingly, it doesn't seem to matter on Mac. That puzzles me. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.3.0 Release - Next Steps
On 8/24/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: Ted Husted [EMAIL PROTECTED] Thanks, Wendy, increasing the memory setting did the trick. It just finished building, and everything looks as expected. I can get cracking on the fnal round of website changes now, and then we can take a deep breath and roll this beast :) I'm not sure if this is necessary, but for Struts 1.2.7, the LICENSE and NOTICE files were in both the overall distribution and in the struts.jar files. Looking at the struts-core nightlies - LICENSE appears in the nightly .zip file - struts-core-1.3.0-dev.jar contains neither LICENSE nor NOTICE http://www.apache.org/dev/apply-license.html says they belong in the top level of the distribution which would at least point to adding NOTICE to the .zip and .tar.gz files. We definitely want these files in the top level of any distribution artifacts, to meet the requirements. I also suggest, however, that we ensure they are inside every JAR file we create as well ... that way, when a user downloads Struts and starts using it, and six months later their PHB asks what are the license terms for that arbitrary JAR file that you grabbed from someplace we don't remember? the question can easily be answered by looking inside. -- Wendy Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r239712 - in /struts/sandbox/trunk/tiles/src/test/org/apache/tiles/config: defs1_FR.xml defs1_fr.xml
Author: craigmcc Date: Wed Aug 24 09:59:29 2005 New Revision: 239712 URL: http://svn.apache.org/viewcvs?rev=239712view=rev Log: Correct a case-mismatch on a resource file that caused test failures on case sensitive operating systems (such as Linux). PR: Bugzilla #36327 Submitted By: Greg Reddin Greg.Reddin AT fnf.com Added: struts/sandbox/trunk/tiles/src/test/org/apache/tiles/config/defs1_fr.xml - copied unchanged from r239533, struts/sandbox/trunk/tiles/src/test/org/apache/tiles/config/defs1_FR.xml Removed: struts/sandbox/trunk/tiles/src/test/org/apache/tiles/config/defs1_FR.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36327] - [Standalone Tiles] Test fails due to URL problems on different platforms.
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=36327. 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=36327 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-24 19:00 --- That was it! Phew ... thanks for getting to the bottom of the problem. By the way, regarding Mac, Apple decided to follow Microsoft's lead and make their filesystem case insensitive -- I guess in the name of user friendliness. That's not a call I would have made, but they didn't ask :-). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on Checkstyle stuff
Perhaps I can make an offer here... At some point, I imagine, you guys (the committers) are all going to agree that the code is stable and ready for release. How about if at that point, whenever it is, someone drops me a line and says ok, have at it with the Checkstyle stuff, and give me maybe a week let's say. Then I can probably eliminate most or perhaps all of them in one shot, and that might be easier to verify nothing gets broken in the process too. Does that sound reasonable? Frank On Wed, August 24, 2005 1:02 pm, Don Brown said: Sorry James, I missed this email as apparently Thunderbird thought it was junk :) I'm willing to take the time to apply this patch if you have no objection. While I'd like to think 1.3.0 is days away, past experience has shown don't hold your breath. My first concern looking at the patch was converting from unix to dos style endlines, however, if some are one style and others another, it would at least be valuable to be consistent. The other concern is these changes might screw up existing patches that need to be applied, so perhaps we should save this patch until the last major bugs have been fixed. What do you think? Don James Mitchell wrote: I saw the tread, but I haven't followed that discussion. I would rather wait till after 1.3.0 is out there. If you can wait till things settle down, I'd be happy to apply your fixes then. After all, the activity may make your patches out of date and we would need to do it ourselves or ask for help again. Ping me again after 1.3.0 is out and remind me to get on this. Thanks man. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 24, 2005, at 12:43 AM, Frank W. Zammetti wrote: Anyone have a chance to look or think about this? I'd like to continue the work but I'd also like to know if folks are receptive to it or not. Maybe you were all just busier today than I was... I Unfortunately have a car that's getting ready to die any day now, so most of my time was spent leisurely comparing and running numbers all day :) Frank Frank W. Zammetti wrote: Hi all, I'm just trying to guage what the consensus is with regard to applying Checkstyle fixes (yes, it's a bit of a strange itch perhaps, but it's *my* itch! :) )... I just submitted a batch (ticket #36306), and would like to resolve as many more as possible, but I'd like to know what everyones' thinking is with regard to when they will/should be applied... would I be putting in a little too much effort if I'm trying to get them into the first 1.3 release? What I mean is, if everyone thinks they should be put off for a later release then there's no need for me to bust my butt as much, I can work a bit more leisurely on things :) If however, folks think it would be better to get them applied sooner than later, which is my belief frankly, any committer willing to do that in the short term? Just as a quick summary... I counted 4,760 Checkstyle complaints on the current TRUNK, and the batch I just submitted resolves 1,462. Virtually none of it alters actual code, in fact only 178 do and that was just to break up lines longer than 80 characters, so I'd say these are relatively benign fixes (and I'll state what should be assumed: everything compiled fine for me and all unit tests passed). There's still probably 2,000 more or so that would fall into that same relatively safe category (lots of javadocs fixes for example) before I even think about those that might require some actual thought/discussion :) Thanks all! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on Checkstyle stuff
Works for me. If you could, mark the ticket LATER until then. Thanks, Don Frank W. Zammetti wrote: Perhaps I can make an offer here... At some point, I imagine, you guys (the committers) are all going to agree that the code is stable and ready for release. How about if at that point, whenever it is, someone drops me a line and says ok, have at it with the Checkstyle stuff, and give me maybe a week let's say. Then I can probably eliminate most or perhaps all of them in one shot, and that might be easier to verify nothing gets broken in the process too. Does that sound reasonable? Frank On Wed, August 24, 2005 1:02 pm, Don Brown said: Sorry James, I missed this email as apparently Thunderbird thought it was junk :) I'm willing to take the time to apply this patch if you have no objection. While I'd like to think 1.3.0 is days away, past experience has shown don't hold your breath. My first concern looking at the patch was converting from unix to dos style endlines, however, if some are one style and others another, it would at least be valuable to be consistent. The other concern is these changes might screw up existing patches that need to be applied, so perhaps we should save this patch until the last major bugs have been fixed. What do you think? Don James Mitchell wrote: I saw the tread, but I haven't followed that discussion. I would rather wait till after 1.3.0 is out there. If you can wait till things settle down, I'd be happy to apply your fixes then. After all, the activity may make your patches out of date and we would need to do it ourselves or ask for help again. Ping me again after 1.3.0 is out and remind me to get on this. Thanks man. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 24, 2005, at 12:43 AM, Frank W. Zammetti wrote: Anyone have a chance to look or think about this? I'd like to continue the work but I'd also like to know if folks are receptive to it or not. Maybe you were all just busier today than I was... I Unfortunately have a car that's getting ready to die any day now, so most of my time was spent leisurely comparing and running numbers all day :) Frank Frank W. Zammetti wrote: Hi all, I'm just trying to guage what the consensus is with regard to applying Checkstyle fixes (yes, it's a bit of a strange itch perhaps, but it's *my* itch! :) )... I just submitted a batch (ticket #36306), and would like to resolve as many more as possible, but I'd like to know what everyones' thinking is with regard to when they will/should be applied... would I be putting in a little too much effort if I'm trying to get them into the first 1.3 release? What I mean is, if everyone thinks they should be put off for a later release then there's no need for me to bust my butt as much, I can work a bit more leisurely on things :) If however, folks think it would be better to get them applied sooner than later, which is my belief frankly, any committer willing to do that in the short term? Just as a quick summary... I counted 4,760 Checkstyle complaints on the current TRUNK, and the batch I just submitted resolves 1,462. Virtually none of it alters actual code, in fact only 178 do and that was just to break up lines longer than 80 characters, so I'd say these are relatively benign fixes (and I'll state what should be assumed: everything compiled fine for me and all unit tests passed). There's still probably 2,000 more or so that would fall into that same relatively safe category (lots of javadocs fixes for example) before I even think about those that might require some actual thought/discussion :) Thanks all! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Standalone Tiles - JSP version tld file
From: [EMAIL PROTECTED] (on struts-user) test.jsp has this: %@ taglib uri=http://jakarta.apache.org/tiles; prefix=tiles % Jakarta? That can't be right... there's a problem: The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri, which is coming from src/conf. I noticed that tld the other day when I was changing the Maven build files. The doc/userGuide/tiles-core.xml file does have the right uri. I think the one in src/conf needs to be deleted-- the tld is probably still supposed to be generated from the files under doc/userGuide and doc/stylesheets as part of the build. Eventually I'll generate a complete tld with all the documentation, so that Maven can create the taglibdoc and tag reference pages... the one in src/conf doesn't have any of that. And what JSP version is Standalone Tiles using? The build files declare a dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that going to be possible with the mismatch in dependencies? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36306] - Collection of fixes to address Checkstyle complaints
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=36306. 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=36306 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||LATER --- Additional Comments From [EMAIL PROTECTED] 2005-08-24 19:56 --- As per discussion on the dev list today, CheckStyle fixes will be done anew when the 1.3 code base is deemed stable. I (Frank) have offered to tackle them when that milestone is reached. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36306] - Collection of fixes to address Checkstyle complaints
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=36306. 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=36306 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #16142|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-08-24 19:57 --- (From update of attachment 16142) This patch can be ignored as a new one will be done when the 1.3 code base is deemed ready for release otherwise. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on Checkstyle stuff
Done. I also obsoleted the attachments and made a note that I will tackle all the Checkstyle complaints when the 1.3 code base is deemed stable and otherwise ready for release. By the way, I don't mind looking at PMD stuff as well, and Jlint and FindBugs too, at the same time... I think only PMD is also run by the build IIRC? The only issue is that the majority of the Checkstyle fixes will be relatively safe and benign, the things found by those other tools may be somewhat risky and certainly will require discussion in many cases. But, if anyone thinks its a good idea to use all four tools and address as much as possible (I do), then I'll take it on as well. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, August 24, 2005 1:44 pm, Don Brown said: Works for me. If you could, mark the ticket LATER until then. Thanks, Don Frank W. Zammetti wrote: Perhaps I can make an offer here... At some point, I imagine, you guys (the committers) are all going to agree that the code is stable and ready for release. How about if at that point, whenever it is, someone drops me a line and says ok, have at it with the Checkstyle stuff, and give me maybe a week let's say. Then I can probably eliminate most or perhaps all of them in one shot, and that might be easier to verify nothing gets broken in the process too. Does that sound reasonable? Frank On Wed, August 24, 2005 1:02 pm, Don Brown said: Sorry James, I missed this email as apparently Thunderbird thought it was junk :) I'm willing to take the time to apply this patch if you have no objection. While I'd like to think 1.3.0 is days away, past experience has shown don't hold your breath. My first concern looking at the patch was converting from unix to dos style endlines, however, if some are one style and others another, it would at least be valuable to be consistent. The other concern is these changes might screw up existing patches that need to be applied, so perhaps we should save this patch until the last major bugs have been fixed. What do you think? Don James Mitchell wrote: I saw the tread, but I haven't followed that discussion. I would rather wait till after 1.3.0 is out there. If you can wait till things settle down, I'd be happy to apply your fixes then. After all, the activity may make your patches out of date and we would need to do it ourselves or ask for help again. Ping me again after 1.3.0 is out and remind me to get on this. Thanks man. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 24, 2005, at 12:43 AM, Frank W. Zammetti wrote: Anyone have a chance to look or think about this? I'd like to continue the work but I'd also like to know if folks are receptive to it or not. Maybe you were all just busier today than I was... I Unfortunately have a car that's getting ready to die any day now, so most of my time was spent leisurely comparing and running numbers all day :) Frank Frank W. Zammetti wrote: Hi all, I'm just trying to guage what the consensus is with regard to applying Checkstyle fixes (yes, it's a bit of a strange itch perhaps, but it's *my* itch! :) )... I just submitted a batch (ticket #36306), and would like to resolve as many more as possible, but I'd like to know what everyones' thinking is with regard to when they will/should be applied... would I be putting in a little too much effort if I'm trying to get them into the first 1.3 release? What I mean is, if everyone thinks they should be put off for a later release then there's no need for me to bust my butt as much, I can work a bit more leisurely on things :) If however, folks think it would be better to get them applied sooner than later, which is my belief frankly, any committer willing to do that in the short term? Just as a quick summary... I counted 4,760 Checkstyle complaints on the current TRUNK, and the batch I just submitted resolves 1,462. Virtually none of it alters actual code, in fact only 178 do and that was just to break up lines longer than 80 characters, so I'd say these are relatively benign fixes (and I'll state what should be assumed: everything compiled fine for me and all unit tests passed). There's still probably 2,000 more or so that would fall into that same relatively safe category (lots of javadocs fixes for example) before I even think about those that might require some actual thought/discussion :) Thanks all! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: ApacheCon 2005 SanDiego
Matter of fact, the slides for all of my talks are available online. * http://wiki.apache.org/struts/StrutsUniversity And, these would be no different :) I'd also expect that we would make them available in advance. On 8/24/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: May I encourage you to make some form of that talk available on the Struts website? I think it would be very valuable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon 2005 SanDiego
On 8/23/05, Craig McClanahan [EMAIL PROTECTED] wrote: My Shale talk got accepted as well. As long as you're scheduled on Monday or Tuesday (I have to fly out on Wednesday) I should be able to join you. I ask if they can run them back to back. I expect that most folks interest in Struts 2006 would also want to attend Struts Shale, so we might as well try and make it easy for them. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r239956 - /struts/shale/trunk/core-library/build.xml
Author: craigmcc
Date: Wed Aug 24 15:40:29 2005
New Revision: 239956
URL: http://svn.apache.org/viewcvs?rev=239956view=rev
Log:
Make complication of the Spring Webflow classes conditional (on the PR4
release of Spring Webflow).
Modified:
struts/shale/trunk/core-library/build.xml
Modified: struts/shale/trunk/core-library/build.xml
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/core-library/build.xml?rev=239956r1=239955r2=239956view=diff
==
--- struts/shale/trunk/core-library/build.xml (original)
+++ struts/shale/trunk/core-library/build.xml Wed Aug 24 15:40:29 2005
@@ -71,6 +71,8 @@
value=${spring.home}/spring-context.jar/
property name=spring-core.jar value=${spring.home}/spring-core.jar/
property name=spring-web.jar value=${spring.home}/spring-web.jar/
+ property name=spring-webflow.jar
+value=${spring.home}/spring-webflow.jar/
property name=tiles.jar
value=${tiles.dir}/dist/lib/tiles-core.jar/
@@ -191,6 +193,9 @@
classpathref=compile.classpath/
/and
/condition
+ available property=webflow.present
+classname=org.springframework.webflow.Flow
+classpath=${spring-webflow.jar}/
!-- Maintenance Targets
--
@@ -219,10 +224,12 @@
echo message=jsp-api.jar =${jsp-api.jar}/
echo message=servlet-api.jar =${servlet-api.jar}/
echo message=shale-test.jar = ${shale-test.jar}/
+echo message=spring-webflow.jar = ${spring-webflow.jar}/
echo message=jsfri.present = ${jsfri.present}/
echo message=myfaces.present= ${myfaces.present}/
echo message=spring.present= ${spring.present}/
echo message=tiles.present= ${tiles.present}/
+echo message=webflow.present= ${webflow.present}/
/target
@@ -271,6 +278,8 @@
unless=spring.present/
excludename=org/apache/shale/tiles/**
unless=tiles.present/
+ excludename=org/apache/shale/spring/webflow/**
+unless=webflow.present/
/javac
!-- Copy non-Java Sources --
@@ -279,6 +288,10 @@
exclude name=**/*.java/
exclude name=org/apache/shale/spring/**
unless=spring.present/
+exclude name=org/apache/shale/tiles/**
+unless=tiles.present/
+exclude name=org/apache/shale/spring/webflow/**
+unless=webflow.present/
/fileset
/copy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project struts-core (in module struts) failed
Do we care about gump? I have 3 line fix for this. $svn mv build.xml build.legacy.xml $maven ant $svn add build.xml Then doing ... $ant dist ...(which is what gump is doing) takes me 1 min and 4 seconds if it has to download the dependencies. Craig, I believe your nightly build would be the only one (that I can think of) that might be adversely affected by this. Any chance you could try the above steps and see if it breaks? I can send you the proposed (resulting) build.xml if that helps. -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 24, 2005, at 7:20 AM, Stefan Bodewig wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-core has an issue affecting its community integration. This issue affects 5 projects, and has been outstanding for 35 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - fulcrum-quartz : Services Framework - jakarta-turbine-jcs : Cache - quartz : Job Scheduler - struts-core : Model 2 Model-View-Controller framework for Servlets and JSP - struts-tiles : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://vmgump.apache.org/gump/public/struts/struts-core/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [struts.jar] identifier set to project name -DEBUG- Dependency on xml-xerces exists, no need to add for property xerces.jar. -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/struts/struts-core/gump_work/ build_struts_struts-core.html Work Name: build_struts_struts-core (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/ local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/ usr/local/gump/public/workspace/xml-xalan/java/build/xalan- unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/ external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml- xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main - Dgump.merge=/x1/gump/public/gump/work/merge.xml - Dbuild.sysclasspath=only -Dcommons-beanutils.jar=/usr/local/gump/ public/workspace/jakarta-commons/beanutils/dist/commons-beanutils- core.jar -Djakarta-oro.jar=/usr/local/gump/public/workspace/jakarta- oro/jakarta-oro-24082005.jar -Dcommons-chain.jar=/usr/local/gump/ public/workspace/jakarta-commons/chain/target/commons- chain-24082005.jar -Dantlr.jar=/usr/local/gump/packages/antlr-2.7.3/ antlr.jar -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0- stdext.jar -Dcommons-lang.jar=/usr/local/gump/public/workspace/ jakarta-commons/lang/dist/commons-lang-24082005.jar -Dcommons- logging.jar=/usr/local/gump/public/workspace/jakarta-commons/ logging/dist/commons-logging-24082005.jar -Djdk.version=1.4 - Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/ lib/servlet.jar -Dcommons-validator.jar=/usr/local/gump/public/ workspace/jakarta-commons/validator/dist/commons-validator.jar - Dcommons-digester-rss.jar=/usr/local/gump/public/workspace/jakarta- commons/digester/src/examples/rss/dist/commons-digester-rss.jar - Dxerces.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/ xercesImpl.jar -Dcommons-collections.jar=/usr/local/gump/public/ workspace/jakarta-commons/collections/build/commons- collections-24082005.jar -Dcommons-fileupload.jar=/usr/local/gump/ public/workspace/jakarta-commons/fileupload/target/commons- fileupload-24082005.jar -Dcommons-digester.jar=/usr/local/gump/ public/workspace/jakarta-commons/digester/dist/commons-digester.jar dist [Working Directory: /usr/local/gump/public/workspace/struts/core] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/ workspace/struts/core/target/library/classes:/usr/local/gump/public/ workspace/struts/core/target/tiles/library/classes:/usr/local/gump/ public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/ workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/ workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/ public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/ workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/ workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/ workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/
svn commit: r239974 - /struts/core/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java
Author: jmitchell Date: Wed Aug 24 18:43:52 2005 New Revision: 239974 URL: http://svn.apache.org/viewcvs?rev=239974view=rev Log: remove unused local var Modified: struts/core/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java Modified: struts/core/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java URL: http://svn.apache.org/viewcvs/struts/core/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java?rev=239974r1=239973r2=239974view=diff == --- struts/core/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java (original) +++ struts/core/trunk/src/test/org/apache/struts/action/TestDynaActionFormClass.java Wed Aug 24 18:43:52 2005 @@ -24,7 +24,6 @@ import org.apache.commons.beanutils.DynaProperty; import org.apache.struts.config.FormBeanConfig; import org.apache.struts.config.FormPropertyConfig; -import org.apache.struts.config.impl.ModuleConfigImpl; /** @@ -125,9 +124,6 @@ beanConfig.addFormPropertyConfig(dynaProperties[i]); } -// Create a temporary ModuleConfig -ModuleConfigImpl moduleConfig = new ModuleConfigImpl(); - // Construct a corresponding DynaActionFormClass dynaClass = new DynaActionFormClass(beanConfig); - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles - JSP version tld file
On 8/24/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (on struts-user) test.jsp has this: %@ taglib uri=http://jakarta.apache.org/tiles; prefix=tiles % Jakarta? That can't be right... there's a problem: The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri, which is coming from src/conf. I noticed that tld the other day when I was changing the Maven build files. The doc/userGuide/tiles-core.xml file does have the right uri. I think the one in src/conf needs to be deleted-- the tld is probably still supposed to be generated from the files under doc/userGuide and doc/stylesheets as part of the build. Eventually I'll generate a complete tld with all the documentation, so that Maven can create the taglibdoc and tag reference pages... the one in src/conf doesn't have any of that. And what JSP version is Standalone Tiles using? The build files declare a dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that going to be possible with the mismatch in dependencies? I believe the intent was that Standalone Tiles should rely on Servlets 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the case, and that we just need to fix up Tiles to conform to that. -- Martin Cooper -- Wendy - 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 35212] - [shale] Clay doesn't process transient components correctly.
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=35212. 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=35212 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 06:32 --- *** Bug 35790 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r239990 - /struts/core/trunk/project.xml
Author: wsmoak Date: Wed Aug 24 21:32:39 2005 New Revision: 239990 URL: http://svn.apache.org/viewcvs?rev=239990view=rev Log: Changed build to include LICENSE and NOTICE in struts-core jar file Modified: struts/core/trunk/project.xml Modified: struts/core/trunk/project.xml URL: http://svn.apache.org/viewcvs/struts/core/trunk/project.xml?rev=239990r1=239989r2=239990view=diff == --- struts/core/trunk/project.xml (original) +++ struts/core/trunk/project.xml Wed Aug 24 21:32:39 2005 @@ -161,6 +161,13 @@ includechain-config.xml/include /includes /resource + resource +directorybuild/directory +includes + includeLICENSE.txt/include + includeNOTICE.txt/include +/includes + /resource /resources /build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35790] - [shale] application freezes if ids for clay components are duplicated
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=35790. 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=35790 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 06:32 --- This problem is fixed with the patch for Bug #35212 submitted by Manfred Klug. *** This bug has been marked as a duplicate of 35212 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r239992 - in /struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay: ./ component/ component/chain/ faces/ parser/builder/ utils/
Author: gvanmatre
Date: Wed Aug 24 21:44:52 2005
New Revision: 239992
URL: http://svn.apache.org/viewcvs?rev=239992view=rev
Log:
Bug#: 35212 - Clay doesn't process transient components correctly; patch
submitted by Manfred Klug
Bug#: 35764 - [shale] Clay View-Handler doesn't work correctly with client
side state saving.
Added:
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/utils/FalseLookupCommand.java
Modified:
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/Clay.java
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/AssignChildrenCommand.java
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/ClayContext.java
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/CreateComponentCommand.java
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/chain/shale-clay-config.xml
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/faces/ClayViewHandler.java
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/parser/builder/VerbatimBuilder.java
Modified:
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties?rev=239992r1=239991r2=239992view=diff
==
---
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties
(original)
+++
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/Bundle.properties
Wed Aug 24 21:44:52 2005
@@ -71,7 +71,9 @@
#org.apache.shale.clay.component.chain.CreateComponentCommand
create.component.error=Cannot create Component {0}
-create.component.exists=Child component {0} is already created.
+create.component=Child component id: {0}, jsfid: {1} child#: {2} created.
+create.facet.component=Facet component {0}, jsfid: {1} created.
+create.component.exists=Child component {0}, jsfid: {1} child#: {2} exists.
#org.apache.shale.clay.component.chain.CreateConverterCommand
create.converter.error=Cannot create Converter {0}
Modified:
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/Clay.java
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/Clay.java?rev=239992r1=239991r2=239992view=diff
==
---
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/Clay.java
(original)
+++
struts/shale/trunk/clay-plugin/src/java/org/apache/shale/clay/component/Clay.java
Wed Aug 24 21:44:52 2005
@@ -135,23 +135,6 @@
/**
* p
- * The output from UIViewRoot.createUniqueId() after the
- * component tree has been constructed.
- */
-private String lastUniqueId = null;
-
-public void setlastUniqueId(String newId)
-{
-lastUniqueId = newId;
-}
-
-public String getlastUniqueId()
-{
-return lastUniqueId;
-}
-
-/**
- * p
* Returns the unique identifier used to build the component subtree
* /p
*/
@@ -245,22 +228,12 @@
if (log.isTraceEnabled())
log.trace(encodeBegin(FacesContext));
-if (getDisplayElementRoot() != null) {
-// Call UIViewRoot.createUniqueId() until we have reproduced all
-// IDs used during construction.
-String currId = getFacesContext().getViewRoot().createUniqueId();
-String lastId = this.getlastUniqueId();
-while(!lastId.equals(currId)) {
-currId = getFacesContext().getViewRoot().createUniqueId();
-}
-}
-else {
+if (getDisplayElementRoot() == null) {
if (!getJsfid().equals(Globals.RUNTIME_ELEMENT_ID)) {
displayElementRoot = getRootElement();
} else {
displayElementRoot = new ComponentBean();
-displayElementRoot
-.setComponentType(javax.faces.HtmlOutputText);
+
displayElementRoot.setComponentType(javax.faces.HtmlOutputText);
displayElementRoot.setJsfid(getJsfid());
}
@@ -281,58 +254,55 @@
String expr = AbstractCommand.replaceMnemonic(clayContext);
Class[] methodSignature = {
-javax.faces.context.FacesContext.class,
-javax.faces.component.UIComponent.class,
-java.lang.Object.class };
-
-MethodBinding binding =
getFacesContext().getApplication()
-.createMethodBinding(expr,
svn commit: r239993 - /struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml
Author: gvanmatre
Date: Wed Aug 24 21:47:14 2005
New Revision: 239993
URL: http://svn.apache.org/viewcvs?rev=239993view=rev
Log:
Bug#: 36176 - [shale] HTML Rolodex example doesn't save the residential and
business address fields; submitted by Manfred Klug
Modified:
struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml
Modified: struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml?rev=239993r1=239992r2=239993view=diff
==
--- struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml (original)
+++ struts/shale/trunk/use-cases/src/web/WEB-INF/clay-config.xml Wed Aug 24
21:47:14 2005
@@ -550,7 +550,7 @@
/component
component jsfid=residentialStreet1 extends=inputText
id=residentialStreet1
attributes
- set name=value
value=#{managed-bean-name.selectedContact.residentialAddress.street1} /
+ set name=value useValueLateBinding=true
value=#{managed-bean-name.selectedContact.residentialAddress.street1} /
set name=required value=false /
/attributes
/component
@@ -568,7 +568,7 @@
/component
component jsfid=businessStreet1 extends=inputText
id=businessStreet1
attributes
- set name=value
value=#{managed-bean-name.selectedContact.businessAddress.street1} /
+ set name=value useValueLateBinding=true
value=#{managed-bean-name.selectedContact.businessAddress.street1} /
set name=required value=false /
/attributes
/component
@@ -587,7 +587,7 @@
/component
component jsfid=residentialStreet2 extends=inputText
id=residentialStreet2
attributes
- set name=value
value=#{managed-bean-name.selectedContact.residentialAddress.street2} /
+ set name=value useValueLateBinding=true
value=#{managed-bean-name.selectedContact.residentialAddress.street2} /
set name=required value=false /
/attributes
/component
@@ -605,7 +605,7 @@
/component
component jsfid=businessStreet2 extends=inputText
id=businessStreet2
attributes
- set name=value
value=#{managed-bean-name.selectedContact.businessAddress.street2} /
+ set name=value useValueLateBinding=true
value=#{managed-bean-name.selectedContact.businessAddress.street2} /
set name=required value=false /
/attributes
/component
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35212] - [shale] Clay doesn't process transient components correctly.
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=35212. 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=35212 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 06:55 --- Thanks for the patch and your patients. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35935] - [shale] loadBundle component for clay HTML templates
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=35935. 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=35935 Bug 35935 depends on bug 35212, which changed state. Bug 35212 Summary: [shale] Clay doesn't process transient components correctly. http://issues.apache.org/bugzilla/show_bug.cgi?id=35212 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36176] - [shale] HTML Rolodex example doesn't save the residential and business address fields.
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=36176. 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=36176 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 06:56 --- Thanks for the patch. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles - JSP version tld file
On 8/24/05, Martin Cooper [EMAIL PROTECTED] wrote: On 8/24/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (on struts-user) test.jsp has this: %@ taglib uri=http://jakarta.apache.org/tiles; prefix=tiles % Jakarta? That can't be right... there's a problem: The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri, which is coming from src/conf. I noticed that tld the other day when I was changing the Maven build files. The doc/userGuide/tiles-core.xml file does have the right uri. I think the one in src/conf needs to be deleted-- the tld is probably still supposed to be generated from the files under doc/userGuide and doc/stylesheets as part of the build. Eventually I'll generate a complete tld with all the documentation, so that Maven can create the taglibdoc and tag reference pages... the one in src/conf doesn't have any of that. And what JSP version is Standalone Tiles using? The build files declare a dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that going to be possible with the mismatch in dependencies? I believe the intent was that Standalone Tiles should rely on Servlets 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the case, and that we just need to fix up Tiles to conform to that. Yes, that was definitely the intent for Standalone Tiles. It probably got mixed up during the multiple iterations of cut-n-paste from the Struts-embedded sources, plus cut-n-paste changes to the build environment, plus ... Craig -- Martin Cooper -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35935] - [shale] loadBundle component for clay HTML templates
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=35935. 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=35935 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 07:34 --- I'd like very much to add German locale support to the rolodex example but the patch uses a custom loadBundle component that is not in the RI. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35935] - [shale] loadBundle component for clay HTML templates
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=35935. 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=35935 --- Additional Comments From [EMAIL PROTECTED] 2005-08-25 07:43 --- (In reply to comment #3) I'd like very much to add German locale support to the rolodex example but the patch uses a custom loadBundle component that is not in the RI. Gary ... check out f:loadBundle (not h:loadBundle), which is documented in Section 9.4.7 of the spec. There's also a few other component tags (plus some non-component support tags) there that might or might not be amenable to Clay's reshaping :-). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standalone Tiles - JSP version tld file
On 8/24/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/24/05, James Mitchell [EMAIL PROTECTED] wrote: Sorry if I'm piping up late on this. What's the plans for Tiles? Will we support embedded tiles or will we simply adapt standalone to work as we do for the commons stuff? That's definitely a call for the developers invested in 1.3.x, but it certainly makes the most sense to have one and only one implementation around, and just do bindings to it. Such bindings should be very easy in this case. My preference would definitely be to support only one version, with that version being the one we expect to support in future releases. So, +1 for supporting Standalone Tiles only. However, I've got a separate / semi-related question. Given that we're changing package names anyway, it would be really cool to abstract away the servlet API specific calling sequences, so that standalone Tiles could work equally comfortably in a portlet environment (without needing any portlet-servlet bridgework). The only API a typical Tiles user will be using is Controller, so this shouldn't be a huge deal. What do you think? I'd say go for it. I would be *very* surprised if any more than a tiny minority of Tiles users have any dependency on the Tiles API at all. In my experience, the vast majority of Tiles users know little more than they need to know to define their tiles in the tiles-defs.xml file. -- Martin Cooper If we're ever going to do this to standalone Tiles, pre-1.0 would seem like the right time. Craig -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. http://www.edgetechservices.net/ 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] Skype: jmitchtx On Aug 25, 2005, at 1:00 AM, Craig McClanahan wrote: On 8/24/05, Martin Cooper [EMAIL PROTECTED] wrote: On 8/24/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] (on struts-user) test.jsp has this: %@ taglib uri=http://jakarta.apache.org/tiles; prefix=tiles % Jakarta? That can't be right... there's a problem: The tld in last night's tiles-core.jar has a JSP 1.1 tld with that uri, which is coming from src/conf. I noticed that tld the other day when I was changing the Maven build files. The doc/userGuide/tiles-core.xml file does have the right uri. I think the one in src/conf needs to be deleted-- the tld is probably still supposed to be generated from the files under doc/userGuide and doc/ stylesheets as part of the build. Eventually I'll generate a complete tld with all the documentation, so that Maven can create the taglibdoc and tag reference pages... the one in src/conf doesn't have any of that. And what JSP version is Standalone Tiles using? The build files declare a dependency on Servlet 2.4 and JSP 2.0. I thought the intent was for Struts Classic (which is now at Servlet 2.3) to move to Standalone Tiles. Is that going to be possible with the mismatch in dependencies? I believe the intent was that Standalone Tiles should rely on Servlets 2.3 and JSP 1.2, as does Struts Classic. I hope that's still the case, and that we just need to fix up Tiles to conform to that. Yes, that was definitely the intent for Standalone Tiles. It probably got mixed up during the multiple iterations of cut-n-paste from the Struts-embedded sources, plus cut-n-paste changes to the build environment, plus ... Craig -- Martin Cooper -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35841] - [shale] Clay doesn't preserve the component hierarchy in HTML templates
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=35841. 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=35841 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35764] - [shale] Clay View-Handler doesn't work correctly with client side state saving.
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=35764. 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=35764 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
