[action2] Configuring interceptors (was Re: Combining JSF and SAF2)
On Sun, 21 May 2006 12:44:02 -0700, Don Brown wrote: You can inherit packages and their defined defaults. Therefore, in this case, you could define the default interceptor stack and result type for a root package then not have to specify it in any action configs of that package or child packages. I've always disliked this part of WebWork (forgive me if things are different now, my understanding is based on older versions of WebWork). Managing the order of the interceptors is important, and it usually ends up being much simpler and less fragile just to let every action use the full stack of interceptors rather than explicitly picking and choosing separate stacks for each action. This in turn can hurt performance by having to chain through unnecessary interceptors, or hurt app design by discouraging fine-grained interceptors. In another web framework I've worked on, the configuration defines exactly two stacks of interceptors--one for actions, and one for views. However, the common interface for the interceptors includes this method: boolean enable(Mapping mapping) At startup, the framework asks asks each interceptor in the chain whether it should be enabled for each mapping. For example, if the interceptor relies on copying information from the context to the Action, it can return false if it can see that the Action impl for a particular mapping does not have any setters. Other interceptors might only enable themselves if the mapping URL matches a particular pattern. The framework then uses this information to construct *mapping-specific* chains. The interceptors in these chains are in the same order as the full chain defined by the config, but some (or most) interceptors will be removed for any given mapping. Furthermore, there is a way to store interceptor-specific data in the Mapping object itself. This enables interceptors to pre-calculate data in the enable method which will speed request handling. For example, the interceptor which copies information to the Action setters could cache an array of Methods, or even generate some bytecode. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
Let's leave XW at OpenSymphony for now - as we know there is a lot of work to be focussed on when moving a project to Apache and I'd rather not let that distract us from the core work that needs to be done on Struts. I say in 6 months or so we see about moving it, once we have a SAF 2.0 release out. With that said, I would only branch if we think that we're likely to do another release. Considering that some changes have been happening on trunk, it sounds like we would. So let's do the branch for 2.0 in CVS and just make sure everyone has that branch checked out as ../xwork relative to our struts-action checkout. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61911#61911 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
For the 2.0 XWork branch, why not branch off 1.x so we can keep trunk for current development? This way, we don't have to change our current checked out code :) Don Patrick Lightbody wrote: Let's leave XW at OpenSymphony for now - as we know there is a lot of work to be focussed on when moving a project to Apache and I'd rather not let that distract us from the core work that needs to be done on Struts. I say in 6 months or so we see about moving it, once we have a SAF 2.0 release out. With that said, I would only branch if we think that we're likely to do another release. Considering that some changes have been happening on trunk, it sounds like we would. So let's do the branch for 2.0 in CVS and just make sure everyone has that branch checked out as ../xwork relative to our struts-action checkout. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61911#61911 - 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: XWork 2, JDK 1.5
As Don suggested, I would branch xwork 1.x series as it is required for the upcoming webwork 2.2.3 bugfix release. Trunk/Head will do fine for the 2.0 release then. What about the proposal of moving over xwork to OpenSymphony SVN repository? Rainer For the 2.0 XWork branch, why not branch off 1.x so we can keep trunk for current development? This way, we don't have to change our current checked out code :) Don Patrick Lightbody wrote: Let's leave XW at OpenSymphony for now - as we know there is a lot of work to be focussed on when moving a project to Apache and I'd rather not let that distract us from the core work that needs to be done on Struts. I say in 6 months or so we see about moving it, once we have a SAF 2.0 release out. With that said, I would only branch if we think that we're likely to do another release. Considering that some changes have been happening on trunk, it sounds like we would. So let's do the branch for 2.0 in CVS and just make sure everyone has that branch checked out as ../xwork relative to our struts-action checkout. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61911#61911 - 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: XWork 2, JDK 1.5
Sounds good to me. I can start the process of migrating to SVN. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61925#61925 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
Why move it to SVN? What does it gain? Just wondering how I'm going to reconcile all these changes I've got that will be harder to do if we switch repositories... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61939#61939 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
My experience is that it's quite a bit faster than CVS (especially over a WAN) but to be honest the biggest advantages I've seen are with file moves, renames, and branching. SVN seems to handle them all relatively painlessly which is a significant improvement over CVS. Also the SVN support in IntelliJ seems to be better than the CVS support. Of course, YMMV. XWork isn't particularly large so I don't know what the overall impact would be. Cheers, Eric On 5/23/06, Jason Carreira [EMAIL PROTECTED] wrote: Why move it to SVN? What does it gain? Just wondering how I'm going to reconcile all these changes I've got that will be harder to do if we switch repositories... - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61939#61939 - 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: XWork 2, JDK 1.5
My experience is that it's quite a bit faster than CVS (especially over a WAN) but to be honest the biggest advantages I've seen are with file moves, renames, and branching. SVN seems to handle them all relatively painlessly which is a significant improvement over CVS. That's my experience as well and I think it would make the upcoming refactorings more easy as they would be with CVS. Jason, here is the thread about the proposal to move XWork over to SVN (with your +1 if history is migrated as well :) ) http://forums.opensymphony.com/thread.jspa?threadID=23590tstart=50 Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
At 12:20 PM -0500 5/23/06, Eric Molitor wrote: My experience is that it's quite a bit faster than CVS (especially over a WAN) but to be honest the biggest advantages I've seen are with file moves, renames, and branching. SVN seems to handle them all relatively painlessly which is a significant improvement over CVS. Also the SVN support in IntelliJ seems to be better than the CVS support. Of course, YMMV. XWork isn't particularly large so I don't know what the overall impact would be. It also may be wasted work if there's an idea that the whole repository may be moving again (that is, to Apache) in 6 months. That said, I recall people generally saying that the SVN import-from-CVS tools work pretty well, and they also are able to preserve CVS history, addressing Rainer's question. I haven't actually done such an import myself. If Jason has a lot of uncommitted changes, it would probably make sense to let him commit them before migrating, if the migration is to go ahead. 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: XWork 2, JDK 1.5
I've imported a CVS repo into SVN and the history was preserved. Worked like a charm. /Ian -- From Down Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Joe Germuska wrote: At 12:20 PM -0500 5/23/06, Eric Molitor wrote: My experience is that it's quite a bit faster than CVS (especially over a WAN) but to be honest the biggest advantages I've seen are with file moves, renames, and branching. SVN seems to handle them all relatively painlessly which is a significant improvement over CVS. Also the SVN support in IntelliJ seems to be better than the CVS support. Of course, YMMV. XWork isn't particularly large so I don't know what the overall impact would be. It also may be wasted work if there's an idea that the whole repository may be moving again (that is, to Apache) in 6 months. That said, I recall people generally saying that the SVN import-from-CVS tools work pretty well, and they also are able to preserve CVS history, addressing Rainer's question. I haven't actually done such an import myself. If Jason has a lot of uncommitted changes, it would probably make sense to let him commit them before migrating, if the migration is to go ahead. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
It also may be wasted work if there's an idea that the whole repository may be moving again (that is, to Apache) in 6 months. Exactly, point #1. That said, I recall people generally saying that the SVN import-from-CVS tools work pretty well, and they also are able to preserve CVS history, addressing Rainer's question. I haven't ctually done such an import myself. If Jason has a lot of uncommitted changes, it would probably make sense to let him commit them before migrating, if the migration is to go ahead. Exactly, point #2. But the problem is... If we're going to branch the old stuff, do I want to check in my XWork 2.0 changes and then port to SVN, then have us try to branch from a spot before I checked those in for 1.x? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61969#61969 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
If Jason has a lot of uncommitted changes, it would probably make sense to let him commit them before migrating, if the migration is to go ahead. Exactly, point #2. But the problem is... If we're going to branch the old stuff, do I want to check in my XWork 2.0 changes and then port to SVN, then have us try to branch from a spot before I checked those in for 1.x? Yep, we should branch XWork before you commit your changes. Shall I create a branch of the current CVS as XWORK_1_2? So you could commit your changes later into HEAD and Patrick could start the migration to SVN after this commit. Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork 2, JDK 1.5
Staying on CVS is probably a smarter descision for now but... You could convert the repo to SVN, create a 1.xx branch and then you could import your local copy into the trunk. Never tried it but in theory it would work. Cheers, Eric On 5/23/06, Jason Carreira [EMAIL PROTECTED] wrote: It also may be wasted work if there's an idea that the whole repository may be moving again (that is, to Apache) in 6 months. Exactly, point #1. That said, I recall people generally saying that the SVN import-from-CVS tools work pretty well, and they also are able to preserve CVS history, addressing Rainer's question. I haven't ctually done such an import myself. If Jason has a lot of uncommitted changes, it would probably make sense to let him commit them before migrating, if the migration is to go ahead. Exactly, point #2. But the problem is... If we're going to branch the old stuff, do I want to check in my XWork 2.0 changes and then port to SVN, then have us try to branch from a spot before I checked those in for 1.x? - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61969#61969 - 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: XWork 2, JDK 1.5
Yep, we should branch XWork before you commit your changes. Shall I create a branch of the current CVS as XWORK_1_2? So you could commit your changes later into HEAD and Patrick could start the migration to SVN after this commit. Rainer +1 (if we're voting) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=31704messageID=61984#61984 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JavaOne Ajax Discussion
Hi everyone, Wanted to document the discussion we had at JavaOne regarding ajax support for Struts2. In attendance were Pat, myself and Martin from the committers group, as well as Joe (from DWR) and a couple of other people (my apologies for not writing down names). The discussion focused around a couple of main points, these were: 1. There have been several cases lately that the ajax support was not what users expected. 2. Dojo does not necessarily work the way that you would expect, making debugging and new user orientation more difficult than needed. 3. Struts2 should provide a benefit to the user and not just wrap pre-existing widgets/components What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). 2. Struts2 should limit the number of ajax libraries it uses. It was agreed to use DWR as the core library. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. Ajax integration via dojo would continue via an independent struts-dojo project. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote: What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). Argh, you guys beat me to the punch! Coincidentally, I had the very early beginnings of code to do exactly this starting to cooking over the weekend :) So I guess you can count me as supportive of the idea! I had taken the cop-out approach though... any field in the Action where a matching element is found anywhere in the XML, as long as the element only appears once, is populated. For elements that appear multiple times, it looks for a Collection or array with a matching name and populates it. This saves you from having to define the XML structure outright, and should work the same basic way for JSON as well. The obvious problem is that it's a little *too* flexible perhaps... I was thinking of providing a simple mapping file that could be read for any Action mapping, something like this: myAction firstName/ children firstName/ firstName/ /children /myAction My thinking was to create a DTD on-the-fly from this, validate the incoming request against it, and then pluck the values out and populate the Action, using the same basic logic as I outlined above. As I wrote this paragraph, it occurred to me that just providing a DTD straight away would probably be sufficient. I think it might be easier on developers those to actually write the XML they expect to receive and save them (as easy as it generally is) to write a DTD or schema. 2. Struts2 should limit the number of ajax libraries it uses. I would hope you mean limit what libraries it uses by default, not limit what libraries it *can* use ;) (I know you do) It was agreed to use DWR as the core library. Cool! I'm a big fan of DWR, I think that's a fantastic decision. Is the idea to have the DWR servlet running in the same context as the WW app, or somehow more directly integrate DWR into WW so the servlet isn't necessary? I would think a filter approach could work here, without thinking about it very much. It would also keep WW configuration as far as web.xml goes as simple as can be. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. So by default all the Actions would be exposed as, in essence, service endpoints, in this package? I'm not sure I like that, sounds like a potential security nightmare. Or would you still have to enable what can be accessed? If you have to still write config to enable things anyway, I'm not sure how much it would save. I'd like to hear more about how Joe envisions this working. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? I think anyone that makes an Ajax call to retrieve tooltip text is inherently evil :) LOL I kid, I kid. Seriously though, it's very easy to abuse Ajax and wind up with a server ground to its knees when the load gets high enough. Even though each Ajax request is generally smaller and easier to generate on the server resource-wise than a full page refresh, I think it is good to try and dissuade people from doing things like getting tooltip text from the server as a best practice, and therefor not providing things in the framework that makes it too easy. After all, if your going to use Javascript to retrieve a tooltip, why not just have it on the client and generate it there? It's script either way. Aside from that one quibble, this all sounds quite good to me. /Ian Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.j
Friends, Pls Help, URGENT I am gettting the following error when I invoke my Action class. HTTP Status 500 - type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Servlet execution threw an exception org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81) root cause java.lang.OutOfMemoryError: Java heap space note The full stack trace of the root cause is available in the Apache Tomcat/5.5 logs. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32084messageID=62079#62079 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JavaOne Ajax Discussion
Hi Ian, I think using DWR as the core library will come up with some problems. For example How do you get the return value for the javascript function you call? (if receiveMessages() returns something ) How do you switch between polling and Comet? Solution (From forum) Right now you return values are not handled automatically - there is a slightly manual solution where you arrange for your Javascript to call a remoted method with the reply. You can change the method currently using the following: DWREngine._pollComet = true; We'll have a better method for this in the next release. Any Comments? Regards, Animesh Saxena RR Donnelley Wipro Technologies I don't believe in fear, I don't believe in faith, I don't believe in anything that I can't break. -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:28 AM To: dev@struts.apache.org Subject: JavaOne Ajax Discussion Hi everyone, Wanted to document the discussion we had at JavaOne regarding ajax support for Struts2. In attendance were Pat, myself and Martin from the committers group, as well as Joe (from DWR) and a couple of other people (my apologies for not writing down names). The discussion focused around a couple of main points, these were: 1. There have been several cases lately that the ajax support was not what users expected. 2. Dojo does not necessarily work the way that you would expect, making debugging and new user orientation more difficult than needed. 3. Struts2 should provide a benefit to the user and not just wrap pre-existing widgets/components What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). 2. Struts2 should limit the number of ajax libraries it uses. It was agreed to use DWR as the core library. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. Ajax integration via dojo would continue via an independent struts-dojo project. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
