[EMAIL PROTECTED]: Project struts-taglib (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-taglib has an issue affecting its community integration. This issue affects 9 projects, and has been outstanding for 22 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-velocity-tools : Velocity-Tools project - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-struts : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - smartfrog-tomcat : Smartfrog: Application Deployment from HP Laboratories - struts-el : Model 2 Model-View-Controller framework for Servlets and JSP - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - struts-taglib : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://vmgump.apache.org/gump/public/struts/struts-taglib/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [struts-taglib-15022006.jar] identifier set to project name -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-web-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-ejb-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-apache-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-xdoclet-module. -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property maven.jar.servlet-api. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-hibernate-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-jdo-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-jmx-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-portlet-module. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/struts/taglib/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/taglib/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/struts/taglib/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/struts/struts-taglib/gump_work/build_struts_struts-taglib.html Work Name: build_struts_struts-taglib (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/struts/taglib] CLASSPATH:
[EMAIL PROTECTED]: Project struts-taglib (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-taglib has an issue affecting its community integration. This issue affects 9 projects, and has been outstanding for 22 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - jakarta-tomcat-5 : Servlet 2.4 and JSP 2.0 Reference Implementation - jakarta-velocity-tools : Velocity-Tools project - portals-bridges-frameworks : Support for JSR168 compliant Portlet development - portals-bridges-struts : Support for JSR168 compliant Portlet development - portals-bridges-velocity : Support for JSR168 compliant Portlet development - smartfrog-tomcat : Smartfrog: Application Deployment from HP Laboratories - struts-el : Model 2 Model-View-Controller framework for Servlets and JSP - struts-sslext : The Struts SSL Extension for HTTP/HTTPS switching - struts-taglib : Model 2 Model-View-Controller framework for Servlets and JSP Full details are available at: http://vmgump.apache.org/gump/public/struts/struts-taglib/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [struts-taglib-15022006.jar] identifier set to project name -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-web-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-ejb-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-apache-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-xdoclet-module. -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property maven.jar.servlet-api. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-hibernate-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-jdo-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-jmx-module. -DEBUG- Dependency on xdoclet exists, no need to add for property maven.jar.xdoclet-portlet-module. -DEBUG- (Gump generated) Maven Properties in: /usr/local/gump/public/workspace/struts/taglib/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /usr/local/gump/public/workspace/struts/taglib/project.xml -DEBUG- Maven project properties in: /usr/local/gump/public/workspace/struts/taglib/project.properties -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/struts/struts-taglib/gump_work/build_struts_struts-taglib.html Work Name: build_struts_struts-taglib (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /usr/local/gump/public/workspace/struts/taglib] CLASSPATH:
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/14/06, Paul Benedict [EMAIL PROTECTED] wrote: Is it the intention of the Struts commiters to make a Command something like a new Action that should be used instead? Or are you expecting commands to be created solely for the request processor chain? Some people have suggested that Command replace Action, and we are encouraging people to explore that avenue to see how well it works. Personally, I favor using Commands the way WebWork/Action2 uses Interceptors and leaving Action as a place to stand on the web layer. Our intent has been to make a numbered build available so that we can get more input from other Struts developers. If it is the second, then I stand by my suggestion that ActionContext should be renamed to reserve the name (ProcessorActionContext?) for the day when you want actions to receive an ActionContext like WebWork. :) There are any number of naming quirks in Struts Action 1.x, and I don't know if one more is going to make a difference. :) The 1.3.x series has been cooking for about 18 months now (since the summer of 2004), and some people are already using it in production. I think if we do not get something rolled this week, a few us might burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't mean that we can't make significant API changes before 1.3.x goes GA. But, it does mean more people will look at what we've done so far. If we did decide to rename a member for future use, we could copy it and deprecate the old one for a milestone, and then remove the old one. But, since the ActionContext has been in the nightly build for many, many months, we should not just change it willy-nilly. Once we get a numbered build out there, I'm sure that there will be many more comments like this. If there is interest, we can regroup and make any desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we have deprecated and removed and released new members during a beta cycle, and I expect we wil do so again. The other important thing is that once we roll the seven 1.3.0 builds, we can make internal changes to Action without re-releasing the other six, if the external API doesn't change. I would tend to agree that we need two flavors of Context available during the request/response cycle. One for the Actions and Commands to use internally, and another for server pages (including Velocity templates) to read externally. Perhaps we could just adopt the Velocity Tools for that, and expect that tags to get everything they need from a tool passed through the request. * http://jakarta.apache.org/velocity/tools/ But, before getting into anything like that, we should roll the 1.3.0 builds, so that we can start making lighter releases. I didn't have any discretionary time last night, but, hopefully, I can wrap up the review of the Release Notes tonight. We can then tag the repository for STRUTS_1_3_0 as well as for each of the subprojects (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. -- HTH, Ted. ** http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Ted Husted [EMAIL PROTECTED] wrote: I didn't have any discretionary time last night, but, hopefully, I can wrap up the review of the Release Notes tonight. We can then tag the repository for STRUTS_1_3_0 as well as for each of the subprojects (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. Do you want any help with the release notes - or anything else? Let me know. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
At 8:13 PM -0800 2/14/06, Paul Benedict wrote: But I noticed the ActionContext is mainly for the request processor and looks like it contains TOO much data that would never be exposed to an action class to use. I may have misunderstood but I'd like for someone to clarify. I find it very strange that the ActionContext would allow a command to *set* the action, cancelled, exception, form valid, forward config, messages resources, and module config. As I said before, these are all controller related issues. Is it the intention of the Struts commiters to make a Command something like a new Action that should be used instead? Or are you expecting commands to be created solely for the request processor chain? As a matter of fact, yes. The ActionContext was designed specifically so that something in possession of one could do everything that a Struts Action class could do. There's nothing you can do with an ActionContext that you couldn't do in Struts 1.2.x without the chain if you knew where it was to be done. More generally, the Context in the chain pattern is the common space through which commands can interact. Without it, you can't effectively decompose behavior because no command can have any way of knowing what else has happened before. The ActionContext class just implements java methods in preferences to using keys in a map. This both makes the code more readable and makes it easier to actually put the values in request or session scope, maintaining backwards compatibility with things which look there for values instead of through the ActionContext. I find it very strange that the ActionContext would allow a command to *set* the action, cancelled, exception, form valid, forward config, messages resources, and module config. As I said before, these are all controller related issues. Why is this strange? The commands are controller related -- they are components of the controller. If it is the second, then I stand by my suggestion that ActionContext should be renamed to reserve the name (ProcessorActionContext?) for the day when you want actions to receive an ActionContext like WebWork. It just contains too many internal properties you don't want a client to be able to mess around with. I think lots of Struts 1.x will not make a direct transition to Struts 2.x. I don't think we necessarily have to worry that much about this potential overlap. That said, I wouldn't veto a change if other committers agree strongly with Paul. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted, please make sure you patch the original RP for InvalidCancelException in 1.3 before you tag. I included a patch already. Someone has to test it (good practice) but the change is identicial/trivial. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Joe, thanks for the feedback. Since you could do all those controller related settings in 1.2 if you knew where to look, putting them all in the ActionContext kind-of raises the IQ of the command/action. It's an advertisement of internal features, so to speak, and I don't really believe, as I said, it's appropriate to expose those to the receiver (but I am OK within the RP). That's all - anything else and I'd be repeating :) Paul __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Niall Pemberton [EMAIL PROTECTED] wrote: Do you want any help with the release notes - or anything else? Let me know. If anyone wanted to pop-in and update the release notes from November to now, that would be great. The only other thing I wanted to do was fix the links from Site to the subprojects to be absolute, so they don't break if you only checkout Site. Then, AFAIC, it's tag the repository and roll the test builds (which is to say the nightly builds with a version numbers instea of a date). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Shale] Dialog
Hi, a while back, there was a discussion regarding annotation based dialog stuff (started by David or Gary ?). I just found an interesting article about integration of Beehive's PageFlow into JavaServer Faces ([1]). Perhaps interesting for some of you as well. However, some stuff looks similar to Shale's ViewHandler stuff ... :) Regards, Matthias [1] - http://dev2dev.bea.com/pub/a/2005/12/integrating-jsf-beehive.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
Ted Husted wrote: Some people have suggested that Command replace Action ... snip . Personally, I favor using Commands the way WebWork/Action2 uses Interceptors ... (spin) Oh yeah. That one signature can do anything. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378034 - /struts/site/trunk/xdocs/navigation.xml
Author: niallp Date: Wed Feb 15 08:53:39 2006 New Revision: 378034 URL: http://svn.apache.org/viewcvs?rev=378034view=rev Log: Make the links to the sub-projects absolute so they don't break if only site is checked out - thanks to Ted Husted for the suggestion :-) Modified: struts/site/trunk/xdocs/navigation.xml Modified: struts/site/trunk/xdocs/navigation.xml URL: http://svn.apache.org/viewcvs/struts/site/trunk/xdocs/navigation.xml?rev=378034r1=378033r2=378034view=diff == --- struts/site/trunk/xdocs/navigation.xml (original) +++ struts/site/trunk/xdocs/navigation.xml Wed Feb 15 08:53:39 2006 @@ -56,25 +56,25 @@ /menu menu name=Frameworks -item name=Action Framework href=/struts-action/index.html/ -item name=Shale Framework href=/struts-shale/index.html/ +item name=Action Framework href=http://struts.apache.org/struts-action/index.html/ +item name=Shale Framework href=http://struts.apache.org/struts-shale/index.html/ /menu menu name=Extensions -item name=EL href=/struts-el/index.html/ -item name=Extras href=/struts-extras/index.html/ -item name=Flow href=/struts-flow/index.html/ -item name=JSF Integration href=/struts-faces/index.html/ -item name=JSP Taglib href=/struts-taglib/index.html/ -item name=Scripting href=/struts-scripting/index.html/ -item name=Tiles href=/struts-tiles/index.html/ +item name=EL href=http://struts.apache.org/struts-el/index.html/ +item name=Extras href=http://struts.apache.org/struts-extras/index.html/ +item name=Flow href=http://struts.apache.org/struts-flow/index.html/ +item name=JSF Integration href=http://struts.apache.org/struts-faces/index.html/ +item name=JSP Taglib href=http://struts.apache.org/struts-taglib/index.html/ +item name=Scripting href=http://struts.apache.org/struts-scripting/index.html/ +item name=Tiles href=http://struts.apache.org/struts-tiles/index.html/ item name=Other Extensions href=http://wiki.apache.org/struts/StrutsExtensions/ /menu menu name=Subprojects -item name=Applications href=/struts-apps/index.html/ -item name=Sandbox href=/struts-sandbox/index.html/ +item name=Applications href=http://struts.apache.org/struts-apps/index.html/ +item name=Sandbox href=http://struts.apache.org/struts-sandbox/index.html/ /menu menu name=Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Ted Husted [EMAIL PROTECTED] wrote: On 2/15/06, Niall Pemberton [EMAIL PROTECTED] wrote: Do you want any help with the release notes - or anything else? Let me know. If anyone wanted to pop-in and update the release notes from November to now, that would be great. The only other thing I wanted to do was fix the links from Site to the subprojects to be absolute, so they don't break if you only checkout Site. Then, AFAIC, it's tag the repository and roll the test builds (which is to say the nightly builds with a version numbers instea of a date). OK I did both of those - hopefully I didn't miss anything important. Most were pretty trivial - except for highlighting the new dependencies, especially Servlet 2.3 and JDK 1.4 and of course Wendy joining the PMC :-) Niall -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Niall Pemberton [EMAIL PROTECTED] wrote: OK I did both of those - hopefully I didn't miss anything important. Most were pretty trivial - except for highlighting the new dependencies, especially Servlet 2.3 and JDK 1.4 and of course Wendy joining the PMC :-) Thanks. We probably just need to add something about the new Cancel handling and maybe that we're using Jalopy to format the code now. I'll try to get back to this tonight or tomorrow morning, unless someone else wants to mop it up. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38374] - Validation always skipped with Globals.CANCEL_KEY
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=38374. 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=38374 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #17699|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-02-15 20:07 --- (From update of attachment 17699) Exception handling is not a special case in 1.3.x. -- 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: [Shale] Dialog
Definitely interesting. There are some overlaps with what Shale does, especially in the Shale Tiger Extensions[1] feature that lets you use annotations to register components/converters/validators, define view controllers, and declare managed beans. Right! That was what I was thinking first. But IMHO I like more the Shale way, since you don't need no interface or superclass. You will notice that annotated navigation is not on that list ... and Really ? I have to search my older struts dev email. I am thinking, I have seen something like that in this list. -Matthias philosophically I believe that navigation should *not* be configured that way. But it is certainly something that could be accomplished technically. Regards, Matthias [1] - http://dev2dev.bea.com/pub/a/2005/12/integrating-jsf-beehive.html Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.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: [Shale] Dialog
Really ? I have to search my older struts dev email. I am thinking, I have seen something like that in this list. Ok... I found, what I was searching for... http://www.mail-archive.com/dev@struts.apache.org/msg16633.html Making the dialog facility easier by convention over config. You got me :-) I guess I mixed some ideas, since you mentioned the tiger extension... Anyway, the emails are *old* December is long time ago ;-) Regards, Matthias -Matthias philosophically I believe that navigation should *not* be configured that way. But it is certainly something that could be accomplished technically. Regards, Matthias [1] - http://dev2dev.bea.com/pub/a/2005/12/integrating-jsf-beehive.html Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38374] - Validation always skipped with Globals.CANCEL_KEY
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=38374. 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=38374 --- Additional Comments From [EMAIL PROTECTED] 2006-02-15 20:23 --- (In reply to comment #21) (From update of attachment 17699 [edit]) Exception handling is not a special case in 1.3.x. Paul's patch looks good to me. The original RequestProcessor is just as constrained in 1.3 by the fact that the process() method only throws IOException and ServletException (unless we wanted to wrap the whole contents of process() in a try catch). To be honest I didn't really understand the comment - could you elaborate? -- 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: [Shale] Dialog
On 2/15/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Definitely interesting. There are some overlaps with what Shale does, especially in the Shale Tiger Extensions[1] feature that lets you use annotations to register components/converters/validators, define view controllers, and declare managed beans. Right! That was what I was thinking first. But IMHO I like more the Shale way, since you don't need no interface or superclass. You will notice that annotated navigation is not on that list ... and Really ? I have to search my older struts dev email. I am thinking, I have seen something like that in this list. You're undoubtedly correct in remembering that the idea of annotated navigation was proposed ... but you'll also find that my reply was I'm not a believer :-) -Matthias Craig philosophically I believe that navigation should *not* be configured that way. But it is certainly something that could be accomplished technically. Regards, Matthias [1] - http://dev2dev.bea.com/pub/a/2005/12/integrating-jsf-beehive.html Craig [1] http://struts.apache.org/struts-shale/features-tiger-extensions.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 38374] - Validation always skipped with Globals.CANCEL_KEY
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=38374. 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=38374 --- Additional Comments From [EMAIL PROTECTED] 2006-02-15 20:35 --- I apologize but I don't understand your comment either, Ted. Developers should still be able to configuire their actions to catch this exception declaratively and do something with it. Am I missing out on something? -- 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]
[Struts Wiki] Update of StrutsClassicRelease130 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsClassicRelease130 The comment on the change is: Updated Cactus test matrix -- === Cactus Tests === || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || - || 1. || J2SE 1.3.1_04 || Tomcat 4.1.30 || _ || - || 2. || J2SE 1.4.2_07 || Tomcat 4.1.30 || _ || + || 1. || J2SE 1.4.2_07 || Tomcat 4.1.31 || _ || - || 3. || J2SE 1.3.1_04 || Tomcat 5.0.28 || _ || + || 2. || J2SE 1.5.0_06 || Tomcat 4.1.31 || _ || - || 4. || J2SE 1.4.2_07 || Tomcat 5.0.28 || _ || + || 3. || J2SE 1.4.2_03 || Tomcat 5.0.30 || (./) || - + || 4. || J2SE 1.5.0_06 || Tomcat 5.0.30 || (./) || == Test Build Checklist (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38534] - DOS attack, application hack
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=38534. 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=38534 --- Additional Comments From [EMAIL PROTECTED] 2006-02-15 23:37 --- Created an attachment (id=17709) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17709action=view) Unit Test patch to test issue 38534 Attached is a patch containing a unit test for issue 38534. In particular it contains the unit test, a class for use in the unit test, a MockMultipartRequestHandler, improvements to the MockHttpServletRequest and the necessary additions to the build-tests.xml and project.xml to run the test. -- 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 38534] - DOS attack, application hack
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=38534. 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=38534 --- Additional Comments From [EMAIL PROTECTED] 2006-02-15 23:39 --- Patch created against the 1.2 branch - apologies for not mentioning that. -- 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: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
On 2/15/06, Ted Husted [EMAIL PROTECTED] wrote: On 2/14/06, Paul Benedict [EMAIL PROTECTED] wrote: Is it the intention of the Struts commiters to make a Command something like a new Action that should be used instead? Or are you expecting commands to be created solely for the request processor chain? Some people have suggested that Command replace Action, and we are encouraging people to explore that avenue to see how well it works. Personally, I favor using Commands the way WebWork/Action2 uses Interceptors and leaving Action as a place to stand on the web layer. Our intent has been to make a numbered build available so that we can get more input from other Struts developers. If it is the second, then I stand by my suggestion that ActionContext should be renamed to reserve the name (ProcessorActionContext?) for the day when you want actions to receive an ActionContext like WebWork. :) There are any number of naming quirks in Struts Action 1.x, and I don't know if one more is going to make a difference. :) The 1.3.x series has been cooking for about 18 months now (since the summer of 2004), and some people are already using it in production. I think if we do not get something rolled this week, a few us might burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't mean that we can't make significant API changes before 1.3.x goes GA. But, it does mean more people will look at what we've done so far. If we did decide to rename a member for future use, we could copy it and deprecate the old one for a milestone, and then remove the old one. But, since the ActionContext has been in the nightly build for many, many months, we should not just change it willy-nilly. I just checked SVN, and ActionContext has been in there for just over a year. Some people have been developing with it in nightly builds since then. I, for one, am certainly not in favour of changing such a key class on the eve of rolling the first real 1.3.x build, not least because I don't want to have to go change my code! ;-) Once we get a numbered build out there, I'm sure that there will be many more comments like this. If there is interest, we can regroup and make any desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we have deprecated and removed and released new members during a beta cycle, and I expect we wil do so again. The other important thing is that once we roll the seven 1.3.0 builds, we can make internal changes to Action without re-releasing the other six, if the external API doesn't change. I would tend to agree that we need two flavors of Context available during the request/response cycle. One for the Actions and Commands to use internally, and another for server pages (including Velocity templates) to read externally. Perhaps we could just adopt the Velocity Tools for that, and expect that tags to get everything they need from a tool passed through the request. * http://jakarta.apache.org/velocity/tools/ But, before getting into anything like that, we should roll the 1.3.0 builds, so that we can start making lighter releases. +1 -- Martin Cooper I didn't have any discretionary time last night, but, hopefully, I can wrap up the review of the Release Notes tonight. We can then tag the repository for STRUTS_1_3_0 as well as for each of the subprojects (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. -- HTH, Ted. ** http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r378130 - /struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java
Author: craigmcc
Date: Wed Feb 15 16:50:45 2006
New Revision: 378130
URL: http://svn.apache.org/viewcvs?rev=378130view=rev
Log:
Add a mock implementation of java.security.Principal to make working with
things like MockHttpServletRequest.setUserPrincipal() easier.
Added:
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java
(with props)
Added:
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java
URL:
http://svn.apache.org/viewcvs/struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java?rev=378130view=auto
==
---
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java
(added)
+++
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java
Wed Feb 15 16:50:45 2006
@@ -0,0 +1,63 @@
+/*
+ * Copyright 2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.shale.test.mock;
+
+import java.security.Principal;
+
+/**
+ * pMock implementation of codePrincipal/code./p
+ */
+public class MockPrincipal implements Principal {
+
+
+//
Constructors
+
+
+public MockPrincipal() {
+this(null);
+}
+
+
+public MockPrincipal(String name) {
+this.name = name;
+}
+
+
+// -- Instance
Variables
+
+
+private String name = null;
+
+
+// - Mock Object
Methods
+
+
+
+public void setName(String name) {
+this.name = name;
+}
+
+
+// --- Principal
Methods
+
+
+public String getName() {
+return this.name;
+}
+
+
+}
Propchange:
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java
--
svn:eol-style = native
Propchange:
struts/shale/trunk/test-framework/src/java/org/apache/shale/test/mock/MockPrincipal.java
--
svn:keywords = Date Author Id Revision HeadURL
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 38670] New: - [tiles-core] Standalone Tiles NullPointerException when debugging
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=38670.
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=38670
Summary: [tiles-core] Standalone Tiles NullPointerException when
debugging
Product: Struts
Version: Unknown
Platform: All
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: Tiles
AssignedTo: dev@struts.apache.org
ReportedBy: [EMAIL PROTECTED]
The toString() method of ComponentAttribute returns value.toString() and thus
will throw a null pointer exception when the value is null. This occurs most
frequently when digester/beanutil trace logging is enabled, due to the fact that
the setProperty method passes the bean (ComponentAttribute) to
StringBuffer.append():
public class BeanUtilBean {
. . .
public void setProperty(Object bean, String name, Object value)
. . .
if (log.isTraceEnabled()) {
StringBuffer sb = new StringBuffer( setProperty();
sb.append(bean);
. . .
The attached patch will check for null values and return null in value is null.
This bug was caught using shale-core and shale-tiles along with a recent nightly
build of tiles-core.
--
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 38670] - [tiles-core] Standalone Tiles NullPointerException when debugging
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=38670. 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=38670 --- Additional Comments From [EMAIL PROTECTED] 2006-02-16 03:27 --- Created an attachment (id=17711) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=17711action=view) 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]
DO NOT REPLY [Bug 38374] - Validation always skipped with Globals.CANCEL_KEY
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=38374. 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=38374 --- Additional Comments From [EMAIL PROTECTED] 2006-02-16 05:04 --- Ted writes: In Struts Action 1.3.0, the exception handling is done through a filter that always fires (like a finally clause), so the patch is not necessary. As part of adding the new cancel handling, we added a new html-cancel page to Exercises that tests and demonstrates the new behavior, including use of a custom ExceptionHandler. All the other bundled applications have been updated to set cancellable where needed, and I confirmed that cancellable did need to be set first. So, not to worry, the code is good to go! Paul writes: I'll take your word for it, except I am forced to disagree by looking at the code. Did you only test 1.3 with the ComposableRequestProcessor? The original RequestProcessor still has this loophole that needs to be closed. That's what this patch is for. I don't see any code for a filter in 1.3 RP unless you mistakened this path for the CRP. -- 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 25267] - Mavenise cactus tests
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=25267. 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=25267 --- Additional Comments From [EMAIL PROTECTED] 2006-02-16 05:41 --- The Cactus tests are currently failing on Tomcat 5.0.30: [cactus] Testcase: testBaseServerTarget took 0.266 sec [cactus]Caused an ERROR [cactus] expected:.. but was:... [cactus] ... [cactus] javax.servlet.ServletException: expected:.. but was:... [cactus] ... [cactus]at org.apache.jasper.runtime.PageContextImpl.doHandlePageExcepti on(PageContextImpl.java:846) and also on Tomcat 4.1.31: [cactus] Testcase: testDefineNamePropertyRequestScopeTestcase: testDefineVal ueRequestScope took 0.344 sec [cactus]Caused an ERROR [cactus] This absolute uri (http://struts.apache.org/tags-logic) cannot be r esolved in either web.xml or the jar files deployed with this application [cactus] org.apache.jasper.JasperException: This absolute uri (http://struts .apache.org/tags-logic) cannot be resolved in either web.xml or the jar files de ployed with this application [cactus]at org.apache.jasper.compiler.DefaultErrorHandler.jspError(Defau ltErrorHandler.java:60) -- 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]
[Struts Wiki] Update of StrutsClassicRelease130 by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsClassicRelease130 The comment on the change is: Tests may have been run against an old working copy, will re-check tomorrow. -- || '''#''' || '''J2SE Version''' || '''Tomcat Version''' || '''Status''' || || 1. || J2SE 1.4.2_07 || Tomcat 4.1.31 || _ || || 2. || J2SE 1.5.0_06 || Tomcat 4.1.31 || _ || - || 3. || J2SE 1.4.2_03 || Tomcat 5.0.30 || (./) || + || 3. || J2SE 1.4.2_03 || Tomcat 5.0.30 || _ || - || 4. || J2SE 1.5.0_06 || Tomcat 5.0.30 || (./) || + || 4. || J2SE 1.5.0_06 || Tomcat 5.0.30 || _ || == Test Build Checklist (A) == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
For my part, I don't think haste because things are late is a good idea. Do it right and have a good product. On 2/15/06, Ted Husted [EMAIL PROTECTED] wrote: On 2/14/06, Paul Benedict [EMAIL PROTECTED] wrote: Is it the intention of the Struts commiters to make a Command something like a new Action that should be used instead? Or are you expecting commands to be created solely for the request processor chain? Some people have suggested that Command replace Action, and we are encouraging people to explore that avenue to see how well it works. Personally, I favor using Commands the way WebWork/Action2 uses Interceptors and leaving Action as a place to stand on the web layer. Our intent has been to make a numbered build available so that we can get more input from other Struts developers. If it is the second, then I stand by my suggestion that ActionContext should be renamed to reserve the name (ProcessorActionContext?) for the day when you want actions to receive an ActionContext like WebWork. :) There are any number of naming quirks in Struts Action 1.x, and I don't know if one more is going to make a difference. :) The 1.3.x series has been cooking for about 18 months now (since the summer of 2004), and some people are already using it in production. I think if we do not get something rolled this week, a few us might burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't mean that we can't make significant API changes before 1.3.x goes GA. But, it does mean more people will look at what we've done so far. If we did decide to rename a member for future use, we could copy it and deprecate the old one for a milestone, and then remove the old one. But, since the ActionContext has been in the nightly build for many, many months, we should not just change it willy-nilly. Once we get a numbered build out there, I'm sure that there will be many more comments like this. If there is interest, we can regroup and make any desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we have deprecated and removed and released new members during a beta cycle, and I expect we wil do so again. The other important thing is that once we roll the seven 1.3.0 builds, we can make internal changes to Action without re-releasing the other six, if the external API doesn't change. I would tend to agree that we need two flavors of Context available during the request/response cycle. One for the Actions and Commands to use internally, and another for server pages (including Velocity templates) to read externally. Perhaps we could just adopt the Velocity Tools for that, and expect that tags to get everything they need from a tool passed through the request. * http://jakarta.apache.org/velocity/tools/ But, before getting into anything like that, we should roll the 1.3.0 builds, so that we can start making lighter releases. I didn't have any discretionary time last night, but, hopefully, I can wrap up the review of the Release Notes tonight. We can then tag the repository for STRUTS_1_3_0 as well as for each of the subprojects (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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~
Re: [VOTE] Confirm the Struts Action Library 1.3.0 release plan
I think the fact that some committers are building code for their personal use and have already personally committed it is not a good reason to roll out a bad idea. On 2/15/06, Martin Cooper [EMAIL PROTECTED] wrote: On 2/15/06, Ted Husted [EMAIL PROTECTED] wrote: On 2/14/06, Paul Benedict [EMAIL PROTECTED] wrote: Is it the intention of the Struts commiters to make a Command something like a new Action that should be used instead? Or are you expecting commands to be created solely for the request processor chain? Some people have suggested that Command replace Action, and we are encouraging people to explore that avenue to see how well it works. Personally, I favor using Commands the way WebWork/Action2 uses Interceptors and leaving Action as a place to stand on the web layer. Our intent has been to make a numbered build available so that we can get more input from other Struts developers. If it is the second, then I stand by my suggestion that ActionContext should be renamed to reserve the name (ProcessorActionContext?) for the day when you want actions to receive an ActionContext like WebWork. :) There are any number of naming quirks in Struts Action 1.x, and I don't know if one more is going to make a difference. :) The 1.3.x series has been cooking for about 18 months now (since the summer of 2004), and some people are already using it in production. I think if we do not get something rolled this week, a few us might burst into flames. That doesn't mean 1.3.0 will go GA, and it doesn't mean that we can't make significant API changes before 1.3.x goes GA. But, it does mean more people will look at what we've done so far. If we did decide to rename a member for future use, we could copy it and deprecate the old one for a milestone, and then remove the old one. But, since the ActionContext has been in the nightly build for many, many months, we should not just change it willy-nilly. I just checked SVN, and ActionContext has been in there for just over a year. Some people have been developing with it in nightly builds since then. I, for one, am certainly not in favour of changing such a key class on the eve of rolling the first real 1.3.x build, not least because I don't want to have to go change my code! ;-) Once we get a numbered build out there, I'm sure that there will be many more comments like this. If there is interest, we can regroup and make any desirable changes in 1.3.1 and 1.3.2 and so forth. In the past, we have deprecated and removed and released new members during a beta cycle, and I expect we wil do so again. The other important thing is that once we roll the seven 1.3.0 builds, we can make internal changes to Action without re-releasing the other six, if the external API doesn't change. I would tend to agree that we need two flavors of Context available during the request/response cycle. One for the Actions and Commands to use internally, and another for server pages (including Velocity templates) to read externally. Perhaps we could just adopt the Velocity Tools for that, and expect that tags to get everything they need from a tool passed through the request. * http://jakarta.apache.org/velocity/tools/ But, before getting into anything like that, we should roll the 1.3.0 builds, so that we can start making lighter releases. +1 -- Martin Cooper I didn't have any discretionary time last night, but, hopefully, I can wrap up the review of the Release Notes tonight. We can then tag the repository for STRUTS_1_3_0 as well as for each of the subprojects (STRUTS_ACTION_1_3_0 ... STRUTS_TILES_1_3_0), and take it from there. -- HTH, Ted. ** http://www.husted.com/ted/blog/ - 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~
