Re: [shale] Genericizing Cargo-Based Integration Tests
On 6/29/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: The CargoTestSetup class that you added to the test framework (was this Wendy's first commit of Java code? :-) nicely leverages the fact that Cargo will figure out which container to use based on system properties (specifically "cargo.container.id"). However, the way that this class is being used in Tomcat5xWelcomeTestCase in the shale-blank application is definitely not container-agnostic, because it presumes to use Tomcat 5.x. (Cargo itself doesn't use the system properties. The CargoTestSetup class looks for that property and uses the value to construct Deployable and LocalConfiguration objects.) The end goal is to be able to run the same tests in multiple containers with a single execution of 'mvn test'. I think CargoTestSetup in shale-test will eventually be deprecated in favor of some 'test runner' code that has been contributed to Cargo by Atlassian, so I'm not inclined to do much else with it. It works for what I needed already, and if you've found a better way to configure it, that's fine. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: What does Clintoo do that standard ThreadLocal cannot? I am trying to understand the benefit here of this package. For one thing, it introduces funky syntax that I personally dislike. ;-) Using '$' and '_' as method names isn't my idea of clarity in programming. -- Martin Cooper Ted Husted <[EMAIL PROTECTED]> wrote: Yes, but we should let one framework go first, and prove something works in practices, before adopting something new in both On 6/30/06, Don Brown wrote: > If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to > adopt it as well, as it would make migration easier, and reduce the number of > differences between the two versions. I'd like to take that approach with other > areas like validation and annotations in the future. I might amend that to say if Struts 1 decides to go with Cllntoo, and we ship a stable release or two with Clintoo, and we decide we really like Cintoo, then, sure, we would want to consider it for Struts 2.x as well. But, there's no reason to rush both frameworks to judgment. Of course, we should try to stablize the feature set between s1 and s2. We added wildcards to s2, and I'm sure we will find some other things to add next month too. At the same time, we should look for things we can backport to s1. One thing Michael mentioned on the rough spots page was better POJO support for s1. * http://wiki.apache.org/struts/SAF1RoughSpots -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
On 6/30/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: I am not sure I understand this proposal. As far as I know this is already supported by WW and quite nicely. So, why would we want to add just another dependency? Well, Naill asked if Clintoo did anything that Struts 2 didn't already do well. Jason said "Nope, we're good." Then, the chat turned to whether we should use it with Struts 1, because s1 doesn't do everything s2 or Clintoo can do in terms of locale resolution. And, if we used it for s1 (the logic went) should we use it for s2? At which point, Ted and Alex said, "s2 ain't broke." My suggestion would be that if we want to do something different or better with the Struts 1 locale resolution, then we should look inhouse to s2 first, before (as Jason said) adopting someone else's 1.0 release. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts JIRA Roadmap
On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Would it be good practice to link to the JIRA version report on each release in the release notes? This has the best bug listing I've seen; bugzilla is not nearly as nice. With Confluence, you can embed a JIRA report in the web page as a live report (scroll down) * http://confluence.twdata.org/display/WW/Release+Notes And that export it as a snapshot into an HTML export. * http://struts.apache.org/struts-action2/docs/Release%20Notes.html -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
I am not sure I understand this proposal. As far as I know this is already supported by WW and quite nicely. So, why would we want to add just another dependency? ./alex -- .w( the_mindstorm )p. --- (http://themindstorms.blogspot.com) On 6/30/06, Don Brown <[EMAIL PROTECTED]> wrote: If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to adopt it as well, as it would make migration easier, and reduce the number of differences between the two versions. I'd like to take that approach with other areas like validation and annotations in the future. Don Niall Pemberton wrote: > On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: >> Joe Germuska <[EMAIL PROTECTED]> wrote:That said, I don't think you >> should not do the work you describe, >> just because you may have to leave the Localizer (or whatever you >> call it) in the ServletContext under a well known key. It's just >> that it feels so outdated! >> >> Here's my solution. Unless anyone feels strongly about it, I am going >> to open up a ticket and submit my patch. >> >> 1) I am going to retain the Globals.LOCAL_KEY as the constant for >> session-strategy localization. Previous applications will continue >> using this without a problem. >> >> 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an >> object that implements these methods: >> >> Locale resolveLocale(HttpServletRequest request); >> >> >> void setLocale(HttpServletRequest request, HttpServletResponse >> response, Locale locale); >> >> >> These methods will not be of any interface. The resolver object can be >> any class which implements those two methods, and I will use BeanUtils >> to retrieve them. The reason I am choosing this design over an >> interface is because I want to plug in implementations from any >> framework (like Struts2 or Spring) without requiring an adapter >> interface. At most, the adapter interface would be just a pass-through >> and so it has questionable value. >> >> 3) Modify RequestUtils.getUserLocale to lookup the stategy first and >> use it. RequestUtils will have a pre-built strategy for doing session >> look-up, to implement requirement #1 (see above). >> >> 4) Modify Action.get/setLocale to delegate to the locale strategy. The >> retrieval of the strategy will most likely be in RequestUtils. >> >> If this works right, I should be able to punch to bridge Struts 1, >> Struts 2, and Spring all behind the scenes. For those developing >> Struts 2, do you have any class which comes close to the above? I'd >> like to coordinate with you so that Struts1-Struts2 apps can bridge >> localization in the 2.0.0 release. > > I had a quick peek at Cintoo messages today (Apache 2 license) - > initial impression was its a nice implementation for i18n. They use > ThreadLocale to store the Locale which makes it available everywhere. > I believe that approach has been used by the ww guys and from memory I > think there are similar concepts for configuring resources > (packaging). It would interesting to hear one of the WW guys if they > had time to look at it. Perhaps we can use it to do the job Commons > Resources was intended for. > > Anyway I digress, this would be one way of making Locale available all > over the place (messages, validation, tiles) without necessarily > changing the API. > > http://messages.cintoo.org/ > http://www.theserverside.com/news/thread.tss?thread_id=41116 > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n > > Niall > > P.S. don't look at the cintoo site using IE - its a mess - OK in firefox > though. > >> I am targetting 1.3.6+ >> >> Paul > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
What does Clintoo do that standard ThreadLocal cannot? I am trying to understand the benefit here of this package. Ted Husted <[EMAIL PROTECTED]> wrote: Yes, but we should let one framework go first, and prove something works in practices, before adopting something new in both On 6/30/06, Don Brown wrote: > If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 > to > adopt it as well, as it would make migration easier, and reduce the number of > differences between the two versions. I'd like to take that approach with > other > areas like validation and annotations in the future. I might amend that to say if Struts 1 decides to go with Cllntoo, and we ship a stable release or two with Clintoo, and we decide we really like Cintoo, then, sure, we would want to consider it for Struts 2.x as well. But, there's no reason to rush both frameworks to judgment. Of course, we should try to stablize the feature set between s1 and s2. We added wildcards to s2, and I'm sure we will find some other things to add next month too. At the same time, we should look for things we can backport to s1. One thing Michael mentioned on the rough spots page was better POJO support for s1. * http://wiki.apache.org/struts/SAF1RoughSpots -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Yes, but we should let one framework go first, and prove something works in practices, before adopting something new in both On 6/30/06, Don Brown <[EMAIL PROTECTED]> wrote: If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to adopt it as well, as it would make migration easier, and reduce the number of differences between the two versions. I'd like to take that approach with other areas like validation and annotations in the future. I might amend that to say if Struts 1 decides to go with Cllntoo, and we ship a stable release or two with Clintoo, and we decide we really like Cintoo, then, sure, we would want to consider it for Struts 2.x as well. But, there's no reason to rush both frameworks to judgment. Of course, we should try to stablize the feature set between s1 and s2. We added wildcards to s2, and I'm sure we will find some other things to add next month too. At the same time, we should look for things we can backport to s1. One thing Michael mentioned on the rough spots page was better POJO support for s1. * http://wiki.apache.org/struts/SAF1RoughSpots -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The build seems to be broken...
That's a file I put in xwork, but it says it was checked in. I'll look into it more later when I get home. Don Bob Lee wrote: Missing AbstractInterceptor. Anybody have any clues? Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The build seems to be broken...
Missing AbstractInterceptor. Anybody have any clues? Bob
RE: Struts JIRA Roadmap
Would it be good practice to link to the JIRA version report on each release in the release notes? This has the best bug listing I've seen; bugzilla is not nearly as nice. Anders Steinlein <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Wendy Smoak [mailto:[EMAIL PROTECTED] > Sent: 30. juni 2006 22:31 > To: Struts Developers List > Subject: Re: Struts JIRA Roadmap > > On 6/30/06, Paul Benedict wrote: > > > I should have seen the next 3 versions thing. I guess my > question was because I was looking for the next 3 versions -- > hoping 1.3.5 would be there. Any idea why that's not within the 3? > > My guess is that it has something to do with Manage Versions > -> Release. Maybe we need to "release" all the old versions > to get them off the roadmap? Someone who has worked more > with JIRA can probably advise. Yes, that is the place to fix this. Releasing versions will remove them from the roadmap, but you should probably archive some of them as well (i.e. 0.5), which will make them unavailible for selections in versions drop-down lists. (0.5 should be irrelevant by now ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Want to be your own boss? Learn how on Yahoo! Small Business.
RE: Struts JIRA Roadmap
> -Original Message- > From: Wendy Smoak [mailto:[EMAIL PROTECTED] > Sent: 30. juni 2006 22:31 > To: Struts Developers List > Subject: Re: Struts JIRA Roadmap > > On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > > I should have seen the next 3 versions thing. I guess my > question was because I was looking for the next 3 versions -- > hoping 1.3.5 would be there. Any idea why that's not within the 3? > > My guess is that it has something to do with Manage Versions > -> Release. Maybe we need to "release" all the old versions > to get them off the roadmap? Someone who has worked more > with JIRA can probably advise. Yes, that is the place to fix this. Releasing versions will remove them from the roadmap, but you should probably archive some of them as well (i.e. 0.5), which will make them unavailible for selections in versions drop-down lists. (0.5 should be irrelevant by now ;) \Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locale resolver (Re: WW/SAF2 i18n & Cintoo Messages)
At 1:01 PM -0700 6/30/06, Paul Benedict wrote: Joe, First, thanks for pointing out cintoo. I looked at the source and it seems like it could be something s1/2 could share together. Are you interested in investigating this with me? Is anyone else? that wasn't me :) I don't have a ton of spare time for investigation right now, and I'm inclined to follow Jason's idea that if WW2 has a good solution for this, there's no compelling reason to gut two frameworks just to change the messaging system. Second, placing the logic in a SetLocale command is fine, but it would be nothing more than delegate to the real class which does the work. The getting/setting of the locale should be an independent class so that other implementations and adjunct frameworks and use it too. For instance, I ocassionaly consult with the user's Struts locale, if it exists, in non-struts tag libraries so that my code is not totally ignorant of frameworks. This is only possible because the retrieving of the locale is in a independent class: RequestUtils. I blew past some of the details of your description. I see what you're getting at now. Personally, I think using an interface is a cleaner design than depending upon reflection, but I wouldn't veto a reflection based solution. 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: Struts JIRA Roadmap
On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I should have seen the next 3 versions thing. I guess my question was because I was looking for the next 3 versions -- hoping 1.3.5 would be there. Any idea why that's not within the 3? My guess is that it has something to do with Manage Versions -> Release. Maybe we need to "release" all the old versions to get them off the roadmap? Someone who has worked more with JIRA can probably advise. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locale resolver (Re: WW/SAF2 i18n & Cintoo Messages)
Joe, First, thanks for pointing out cintoo. I looked at the source and it seems like it could be something s1/2 could share together. Are you interested in investigating this with me? Is anyone else? Second, placing the logic in a SetLocale command is fine, but it would be nothing more than delegate to the real class which does the work. The getting/setting of the locale should be an independent class so that other implementations and adjunct frameworks and use it too. For instance, I ocassionaly consult with the user's Struts locale, if it exists, in non-struts tag libraries so that my code is not totally ignorant of frameworks. This is only possible because the retrieving of the locale is in a independent class: RequestUtils. But I think the design should be more fine grained, so that getting and setting of the locale exist in a class specific to locale methods. For Struts 1, I am recommending a pluggable locale resolver like Spring to get/set the strategy if needed. The RP Chain of course *should* use the strategy to set the locale directly, but the strategy should never be totally hidden so those outside the chain cannot access it either. Paul Joe Germuska <[EMAIL PROTECTED]> wrote: At 11:36 AM -0700 6/30/06, Paul Benedict wrote: >Some further reflections: > >WW and SPR both use ThreadLocal to store the locale of the thread's >request. However, there still needs to be a shared object that can >set/retrieve the local across web frameworks. > >So I 100% agree with the ThreadLocal use, but it is not directly >relevant to my question. That would be an implementation of the >locale resolver, in which it would expose the locale in the thread >for a particular framework. On the other hand, perhaps using a thread local is a more elegant strategy than requiring a specific mechanism which looks for a specific object in the ApplicationContext and uses a specific reflection mechanism to find a locale. At 10:53 AM -0700 6/30/06, Paul Benedict wrote: >3) Modify RequestUtils.getUserLocale to lookup the stategy first and >use it. RequestUtils will have a pre-built strategy for doing >session look-up, to implement requirement #1 (see above). That is, there are lots of ways to make sure that Globals.LOCALE_KEY points to the right locale, and you could leave the details which you specify (to do with Globals.LOCALE_RESOLVER_KEY) more up to the implementor. I might just write a ServletFilter instead of putting in a LOCALE_RESOLVER, or I might write a custom chain command. It seems to me better to leave the things which need the Locale ignorant of how to find it. In fact, you could easily replace the "SetLocale" command with another that consulted cookies or request parameters. 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] - Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
Re: Struts JIRA Roadmap
Sorry for the question. I should have seen the next 3 versions thing. I guess my question was because I was looking for the next 3 versions -- hoping 1.3.5 would be there. Any idea why that's not within the 3? Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/30/06, Paul Benedict wrote: > Does anyone know how to setup the roadmap on JIRA so we can see all the > fixed/outstanding defects that are going into 1.3.5? Right now the roadmap > contains Struts 0.5 and the nightly build. Link? On the 1.3.5 release plan, there is a link to the issues outstanding for 1.3.5, plus one for the JIRA-generated release notes. Oh, I found it. The roadmap defaults to "next 3 versions". If you click 'all versions' then you'll see everything... from there it looks like you can define a personal roadmap. * http://issues.apache.org/struts/browse/STR?report=com.atlassian.jira.plugin.system.project:roadmap-panel What do you want changed? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta.
Re: Struts JIRA Roadmap
On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Does anyone know how to setup the roadmap on JIRA so we can see all the fixed/outstanding defects that are going into 1.3.5? Right now the roadmap contains Struts 0.5 and the nightly build. Link? On the 1.3.5 release plan, there is a link to the issues outstanding for 1.3.5, plus one for the JIRA-generated release notes. Oh, I found it. The roadmap defaults to "next 3 versions". If you click 'all versions' then you'll see everything... from there it looks like you can define a personal roadmap. * http://issues.apache.org/struts/browse/STR?report=com.atlassian.jira.plugin.system.project:roadmap-panel What do you want changed? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Locale resolver (Re: WW/SAF2 i18n & Cintoo Messages)
At 11:36 AM -0700 6/30/06, Paul Benedict wrote: Some further reflections: WW and SPR both use ThreadLocal to store the locale of the thread's request. However, there still needs to be a shared object that can set/retrieve the local across web frameworks. So I 100% agree with the ThreadLocal use, but it is not directly relevant to my question. That would be an implementation of the locale resolver, in which it would expose the locale in the thread for a particular framework. On the other hand, perhaps using a thread local is a more elegant strategy than requiring a specific mechanism which looks for a specific object in the ApplicationContext and uses a specific reflection mechanism to find a locale. At 10:53 AM -0700 6/30/06, Paul Benedict wrote: 3) Modify RequestUtils.getUserLocale to lookup the stategy first and use it. RequestUtils will have a pre-built strategy for doing session look-up, to implement requirement #1 (see above). That is, there are lots of ways to make sure that Globals.LOCALE_KEY points to the right locale, and you could leave the details which you specify (to do with Globals.LOCALE_RESOLVER_KEY) more up to the implementor. I might just write a ServletFilter instead of putting in a LOCALE_RESOLVER, or I might write a custom chain command. It seems to me better to leave the things which need the Locale ignorant of how to find it. In fact, you could easily replace the "SetLocale" command with another that consulted cookies or request parameters. 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: Struts JIRA Roadmap
You need to click on the "All Versions" link, as JIRA thinks those three are the next versions to be released. Don Paul Benedict wrote: Does anyone know how to setup the roadmap on JIRA so we can see all the fixed/outstanding defects that are going into 1.3.5? Right now the roadmap contains Struts 0.5 and the nightly build. Paul - How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts JIRA Roadmap
Does anyone know how to setup the roadmap on JIRA so we can see all the fixed/outstanding defects that are going into 1.3.5? Right now the roadmap contains Struts 0.5 and the nightly build. Paul - How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to adopt it as well, as it would make migration easier, and reduce the number of differences between the two versions. I'd like to take that approach with other areas like validation and annotations in the future. Don Niall Pemberton wrote: On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Joe Germuska <[EMAIL PROTECTED]> wrote:That said, I don't think you should not do the work you describe, just because you may have to leave the Localizer (or whatever you call it) in the ServletContext under a well known key. It's just that it feels so outdated! Here's my solution. Unless anyone feels strongly about it, I am going to open up a ticket and submit my patch. 1) I am going to retain the Globals.LOCAL_KEY as the constant for session-strategy localization. Previous applications will continue using this without a problem. 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an object that implements these methods: Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale); These methods will not be of any interface. The resolver object can be any class which implements those two methods, and I will use BeanUtils to retrieve them. The reason I am choosing this design over an interface is because I want to plug in implementations from any framework (like Struts2 or Spring) without requiring an adapter interface. At most, the adapter interface would be just a pass-through and so it has questionable value. 3) Modify RequestUtils.getUserLocale to lookup the stategy first and use it. RequestUtils will have a pre-built strategy for doing session look-up, to implement requirement #1 (see above). 4) Modify Action.get/setLocale to delegate to the locale strategy. The retrieval of the strategy will most likely be in RequestUtils. If this works right, I should be able to punch to bridge Struts 1, Struts 2, and Spring all behind the scenes. For those developing Struts 2, do you have any class which comes close to the above? I'd like to coordinate with you so that Struts1-Struts2 apps can bridge localization in the 2.0.0 release. I had a quick peek at Cintoo messages today (Apache 2 license) - initial impression was its a nice implementation for i18n. They use ThreadLocale to store the Locale which makes it available everywhere. I believe that approach has been used by the ww guys and from memory I think there are similar concepts for configuring resources (packaging). It would interesting to hear one of the WW guys if they had time to look at it. Perhaps we can use it to do the job Commons Resources was intended for. Anyway I digress, this would be one way of making Locale available all over the place (messages, validation, tiles) without necessarily changing the API. http://messages.cintoo.org/ http://www.theserverside.com/news/thread.tss?thread_id=41116 http://www.infoq.com/news/Cintoo-Messages-1.0-i18n Niall P.S. don't look at the cintoo site using IE - its a mess - OK in firefox though. I am targetting 1.3.6+ Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WW/SAF2 i18n & Cintoo Messages
> From memory (WW in Action) there seems to be similar > concepts in > Cintoo messages that WW/SAF2 has - but I was hoping > someone who knows > would comment. > > The license is Apache 2 and it looks good to me - is > this something > that SAF2 would benefit from or is that area already > well covered? > > http://messages.cintoo.org/ > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n > http://www.theserverside.com/news/thread.tss?thread_id > =41116 > > Niall > > -- > --- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > This is covered pretty flexibly (perhaps TOO flexibly) in WW/SAF2. I don't see the need to pull this out and use a 3rd party library that just got to a 1.0 release. Maybe if it catches on and becomes a defacto standard. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=36035&messageID=70657#70657 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WW/SAF2 i18n & Cintoo Messages
Ahh, ok. Thanks for clarifying that. I was not able to follow that discussion to the end. (Looks like I'm not the only one.) Hubert On 6/30/06, Ted Husted <[EMAIL PROTECTED]> wrote: On 6/30/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: > It looks like it requires Java 5. Has there been a decision to move > SAF2 to Java 5? * http://wiki.apache.org/struts/StrutsActionRelease200 "The platform for SAF 2.0.x is Java 1.5, with Java 1.4 compatibity provided by Retroweaver." -T. - 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: WW/SAF2 i18n & Cintoo Messages
On 6/30/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: It looks like it requires Java 5. Has there been a decision to move SAF2 to Java 5? * http://wiki.apache.org/struts/StrutsActionRelease200 "The platform for SAF 2.0.x is Java 1.5, with Java 1.4 compatibity provided by Retroweaver." -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WW/SAF2 i18n & Cintoo Messages
No, but there was talk of doing it and using retro-do-dah (translator/weaver) I think. Can't remember where that discussion went. Niall On 6/30/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: It looks like it requires Java 5. Has there been a decision to move SAF2 to Java 5? Hubert On 6/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > From memory (WW in Action) there seems to be similar concepts in > Cintoo messages that WW/SAF2 has - but I was hoping someone who knows > would comment. > > The license is Apache 2 and it looks good to me - is this something > that SAF2 would benefit from or is that area already well covered? > > http://messages.cintoo.org/ > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n > http://www.theserverside.com/news/thread.tss?thread_id=41116 > > Niall > > - > 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]
Locale resolver (Re: WW/SAF2 i18n & Cintoo Messages)
Some further reflections: WW and SPR both use ThreadLocal to store the locale of the thread's request. However, there still needs to be a shared object that can set/retrieve the local across web frameworks. So I 100% agree with the ThreadLocal use, but it is not directly relevant to my question. That would be an implementation of the locale resolver, in which it would expose the locale in the thread for a particular framework. So if I am running with a local resolver whose implementation sets both SAF/SAF2, it would set the appropriate values for each framework. Understand? This is kind of complex for me to describe, but I hope the point is clear. Paul Hubert Rabago <[EMAIL PROTECTED]> wrote: It looks like it requires Java 5. Has there been a decision to move SAF2 to Java 5? Hubert On 6/30/06, Niall Pemberton wrote: > From memory (WW in Action) there seems to be similar concepts in > Cintoo messages that WW/SAF2 has - but I was hoping someone who knows > would comment. > > The license is Apache 2 and it looks good to me - is this something > that SAF2 would benefit from or is that area already well covered? > > http://messages.cintoo.org/ > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n > http://www.theserverside.com/news/thread.tss?thread_id=41116 > > Niall > > - > 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] - How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates.
Re: WW/SAF2 i18n & Cintoo Messages
Actually, I take that back -- the sample code on their page uses Java 5. I don't know if the library itself requires it. Hubert On 6/30/06, Hubert Rabago <[EMAIL PROTECTED]> wrote: It looks like it requires Java 5. Has there been a decision to move SAF2 to Java 5? Hubert On 6/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > From memory (WW in Action) there seems to be similar concepts in > Cintoo messages that WW/SAF2 has - but I was hoping someone who knows > would comment. > > The license is Apache 2 and it looks good to me - is this something > that SAF2 would benefit from or is that area already well covered? > > http://messages.cintoo.org/ > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n > http://www.theserverside.com/news/thread.tss?thread_id=41116 > > Niall > > - > 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: WW/SAF2 i18n & Cintoo Messages
It looks like it requires Java 5. Has there been a decision to move SAF2 to Java 5? Hubert On 6/30/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: From memory (WW in Action) there seems to be similar concepts in Cintoo messages that WW/SAF2 has - but I was hoping someone who knows would comment. The license is Apache 2 and it looks good to me - is this something that SAF2 would benefit from or is that area already well covered? http://messages.cintoo.org/ http://www.infoq.com/news/Cintoo-Messages-1.0-i18n http://www.theserverside.com/news/thread.tss?thread_id=41116 Niall - 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]
WW/SAF2 i18n & Cintoo Messages
From memory (WW in Action) there seems to be similar concepts in Cintoo messages that WW/SAF2 has - but I was hoping someone who knows would comment. The license is Apache 2 and it looks good to me - is this something that SAF2 would benefit from or is that area already well covered? http://messages.cintoo.org/ http://www.infoq.com/news/Cintoo-Messages-1.0-i18n http://www.theserverside.com/news/thread.tss?thread_id=41116 Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
On 6/30/06, Paul Benedict <[EMAIL PROTECTED]> wrote: Joe Germuska <[EMAIL PROTECTED]> wrote:That said, I don't think you should not do the work you describe, just because you may have to leave the Localizer (or whatever you call it) in the ServletContext under a well known key. It's just that it feels so outdated! Here's my solution. Unless anyone feels strongly about it, I am going to open up a ticket and submit my patch. 1) I am going to retain the Globals.LOCAL_KEY as the constant for session-strategy localization. Previous applications will continue using this without a problem. 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an object that implements these methods: Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale); These methods will not be of any interface. The resolver object can be any class which implements those two methods, and I will use BeanUtils to retrieve them. The reason I am choosing this design over an interface is because I want to plug in implementations from any framework (like Struts2 or Spring) without requiring an adapter interface. At most, the adapter interface would be just a pass-through and so it has questionable value. 3) Modify RequestUtils.getUserLocale to lookup the stategy first and use it. RequestUtils will have a pre-built strategy for doing session look-up, to implement requirement #1 (see above). 4) Modify Action.get/setLocale to delegate to the locale strategy. The retrieval of the strategy will most likely be in RequestUtils. If this works right, I should be able to punch to bridge Struts 1, Struts 2, and Spring all behind the scenes. For those developing Struts 2, do you have any class which comes close to the above? I'd like to coordinate with you so that Struts1-Struts2 apps can bridge localization in the 2.0.0 release. I had a quick peek at Cintoo messages today (Apache 2 license) - initial impression was its a nice implementation for i18n. They use ThreadLocale to store the Locale which makes it available everywhere. I believe that approach has been used by the ww guys and from memory I think there are similar concepts for configuring resources (packaging). It would interesting to hear one of the WW guys if they had time to look at it. Perhaps we can use it to do the job Commons Resources was intended for. Anyway I digress, this would be one way of making Locale available all over the place (messages, validation, tiles) without necessarily changing the API. http://messages.cintoo.org/ http://www.theserverside.com/news/thread.tss?thread_id=41116 http://www.infoq.com/news/Cintoo-Messages-1.0-i18n Niall P.S. don't look at the cintoo site using IE - its a mess - OK in firefox though. I am targetting 1.3.6+ Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Localization Bridge (was Re: Thoughts on 1.3.x)
Joe Germuska <[EMAIL PROTECTED]> wrote:That said, I don't think you should not do the work you describe, just because you may have to leave the Localizer (or whatever you call it) in the ServletContext under a well known key. It's just that it feels so outdated! Here's my solution. Unless anyone feels strongly about it, I am going to open up a ticket and submit my patch. 1) I am going to retain the Globals.LOCAL_KEY as the constant for session-strategy localization. Previous applications will continue using this without a problem. 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an object that implements these methods: Locale resolveLocale(HttpServletRequest request); void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale); These methods will not be of any interface. The resolver object can be any class which implements those two methods, and I will use BeanUtils to retrieve them. The reason I am choosing this design over an interface is because I want to plug in implementations from any framework (like Struts2 or Spring) without requiring an adapter interface. At most, the adapter interface would be just a pass-through and so it has questionable value. 3) Modify RequestUtils.getUserLocale to lookup the stategy first and use it. RequestUtils will have a pre-built strategy for doing session look-up, to implement requirement #1 (see above). 4) Modify Action.get/setLocale to delegate to the locale strategy. The retrieval of the strategy will most likely be in RequestUtils. If this works right, I should be able to punch to bridge Struts 1, Struts 2, and Spring all behind the scenes. For those developing Struts 2, do you have any class which comes close to the above? I'd like to coordinate with you so that Struts1-Struts2 apps can bridge localization in the 2.0.0 release. I am targetting 1.3.6+ Paul - Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: [PROPOSAL] Rename Struts Action as Struts
I only have an inclination against s1/s2. Otherwise, struts/struts2 or struts1/struts2 or action1/action2 is fine by me. Ted Husted <[EMAIL PROTECTED]> wrote: On 6/30/06, Brett Porter wrote: > (from the peanut gallery) > > How about: > repos/asf/struts/branches/struts-1.3/... > repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here) Yep, and different teams have tried different approaches :) Maven has maven-1 under the root * http://svn.apache.org/viewvc/maven/ Tapestry has Tapestry# folders for each series * http://svn.apache.org/viewvc/tapestry/ And, as mentioned, HTTPD uses branches * http://svn.apache.org/viewvc/httpd/httpd/branches/ Given the infrastructure we already haven in place, the "Tapestry" approach would make the most sense, since that's what we are already using. Before just renaming the framework from "Action" to "Struts", without discussion, we opened this thread to be sure all the committers were good with that. And, it seems that we are. Now, in place of "Tapestry4" and "Tapestry5". we now have "struts-action" and "struts-action2" * http://svn.apache.org/viewvc/struts/ which we could just rename to "struts1" and "struts2". I was just asking if we wanted to make the reference "s1" and "s2". (The Maven team shortens their version references to m1 and m2, and I wondered if we wanted to reinforce that convention.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? Get on board. You're invited to try the new Yahoo! Mail Beta.
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/29/06, Paul Benedict <[EMAIL PROTECTED]> wrote: I am guessing the winner is going to be struts1/struts2 So if struts1 is: org.apache.struts If struts2: org.apache.struts2 ? Yes, the other piece of surgery would be moving http://svn.apache.org/viewvc/struts/action2/trunk/core/src/main/java/org/apache/struts/action2/ to http://svn.apache.org/viewvc/struts/action2/trunk/core/src/main/java/org/apache/struts2/ along with the relevant package renames. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Rename Struts Action as Struts
Greg Reddin sagely replied: > On Jun 30, 2006, at 9:58 AM, Ted Husted wrote: > > > Now, in place of "Tapestry4" and "Tapestry5". we now have > > "struts-action" and "struts-action2" > > > > * http://svn.apache.org/viewvc/struts/ > > > > which we could just rename to "struts1" and "struts2". > > That sounds good to me. > > > > > I was just asking if we wanted to make the reference "s1" and "s2". > > This works but I prefer the more explicit "struts1" and > "struts2". I > can live with it either way. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On Jun 30, 2006, at 9:58 AM, Ted Husted wrote: Now, in place of "Tapestry4" and "Tapestry5". we now have "struts-action" and "struts-action2" * http://svn.apache.org/viewvc/struts/ which we could just rename to "struts1" and "struts2". That sounds good to me. I was just asking if we wanted to make the reference "s1" and "s2". This works but I prefer the more explicit "struts1" and "struts2". I can live with it either way. Greg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts problem on reload...
Cool...I'll try that and see how it goes. Many thanks... If I might ask though, is there a specific opposition to having the standard ActionServlet clean up the RequestProcessor instances from the ServletContext as it does plugins and ModuleConfigs? Paul Benedict wrote: Andy: Use this as your action servlet instead: http://struts.apache.org/struts-doc-1.2.9/api/org/apache/struts/actions/RedeployableActionServlet.html Paul Andy Lewis <[EMAIL PROTECTED]> wrote: The team I work with has encountered an apparent problem with Struts when the servlet is reloaded by the container. We are using Weblogic 9.1, but the problem appear to happen on other versions, and possibly other containers. The spec does not appear to be clear regarding the ServletContext behavior across servlet instances, and in the case of Weblogic 9.1, it appears to fully preserve the ServletContext. The problem we are having is that the RequestProcessor instances stored in the ServletContext are destroyed when the ActionServlet is destroyed, but they are not removed from the ServletContext. As a result, when a new servlet is created with the same context, it finds the RequestProcessors already existing, but they have a null reference to the servlet (since their respective destroy method was called). As a result any attempt to get to the Servlet resources, such as the ServletContext, results in a NullPointerException in the RequestProcessor. Even the latest version appears to do this. Google searches on the problem reveal other users have had the problem, and even a patch/hack that resets the servlet variable in the RequestProcessor every time it is accessed. There is also an existing open issue () on JRun that may be the same problem. A simple one line addition to the Servlet destroy code to remove the destroyed RequestProcessor from the ServletContext fixes the problem. Is anyone familiar with this issue and can valid or correct my understanding? And If I am correct in my understanding, is this something I should submit the one line patch for? I've not had the opportunity to contribute to struts before, and little to any project as much as I'd like to. Any comments, feedback, corrections, validations, etc, would be appreciated. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Want to be your own boss? Learn how on Yahoo! Small Business. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/30/06, Brett Porter <[EMAIL PROTECTED]> wrote: (from the peanut gallery) How about: repos/asf/struts/branches/struts-1.3/... repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here) Yep, and different teams have tried different approaches :) Maven has maven-1 under the root * http://svn.apache.org/viewvc/maven/ Tapestry has Tapestry# folders for each series * http://svn.apache.org/viewvc/tapestry/ And, as mentioned, HTTPD uses branches * http://svn.apache.org/viewvc/httpd/httpd/branches/ Given the infrastructure we already haven in place, the "Tapestry" approach would make the most sense, since that's what we are already using. Before just renaming the framework from "Action" to "Struts", without discussion, we opened this thread to be sure all the committers were good with that. And, it seems that we are. Now, in place of "Tapestry4" and "Tapestry5". we now have "struts-action" and "struts-action2" * http://svn.apache.org/viewvc/struts/ which we could just rename to "struts1" and "struts2". I was just asking if we wanted to make the reference "s1" and "s2". (The Maven team shortens their version references to m1 and m2, and I wondered if we wanted to reinforce that convention.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
If we do not have different package names, we cannot run both Struts 1 and Struts 2 in the same web application. So it's very important to encode the version into the pacakge structure. Otherwise, the migration path to Struts 2 is all or none. This is not a unique idea; this has been espoused by other committers. Dakota Jack <[EMAIL PROTECTED]> wrote: Give it up! Lord! What nonsense. Do you hate versioning, Paul? On 6/28/06, Paul Benedict wrote: > > I am guessing the winner is going to be struts1/struts2 > > So if struts1 is: > org.apache.struts > > If struts2: > org.apache.struts2 > > ? > > Niall Pemberton wrote: On 6/29/06, Don > Brown wrote: > > > > I like struts1/struts2. > > +1 > > Niall > > > Don > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > Do you Yahoo!? > Next-gen email? Have it all with the all-new Yahoo! Mail Beta. > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ - Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better.
Re: [PROPOSAL] Rename Struts Action as Struts
(from the peanut gallery) How about: repos/asf/struts/branches/struts-1.3/... repos/asf/struts/trunk (2.0, 2.1, 3.0 goes here) It's not like you're the first project here to have had a 1.3 v 2.0 issue :) http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/ Cheers, Brett On 30/06/06, Ted Husted <[EMAIL PROTECTED]> wrote: Or, in the interest of brevity, even repos/asf/struts/s1 repos/asf/struts/s2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Rename Struts Action as Struts
On 6/28/06, Don Brown <[EMAIL PROTECTED]> wrote: Ted Husted wrote: > Though, there's no reason why we couldn't use > >> repos/asf/struts/struts1 >> repos/asf/struts/struts2 > > Or > >> repos/asf/struts/framework >> repos/asf/struts/framework2 I like struts1/struts2. Or, in the interest of brevity, even repos/asf/struts/s1 repos/asf/struts/s2 -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3.x: Using multiple chain configurations
At 9:07 AM +0100 6/30/06, Phil Zoio wrote: Joe, Could Struts 1.3 set up to have a separate chain per module? Phil: I thought we discussed this two weeks ago. In short, the answer is "yes". Looking back at what I wrote, perhaps I gave too much detail at the wrong time. Here is the core of it: >>> It is technically possible to change which command is looked up in the catalogs and executed to process the request as part of the >>> controller-config on per-module basis. For context, Struts uses commons-chain code to instantiate a universe of catalogs which contain commands. You'd use the to specify the name of a catalog and the name of a command within that catalog which is to be executed to process the request. Therefore, you could specify different "bootstrap" commands for each controller until you turn blue. 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: Struts 1.3.x: Using multiple chain configurations
That's exactly what Struts 2 does with interceptors, and S2 takes it a step farther by allowing each action to have its own sequence, if you like. An important question is whether we want to stick with Chain in the Struts 1.x series or consider moving to Interceptors for Struts 1.4. I didn't understand interceptors when we started the Commons Chain work, but now that I do, it looks like we reinvented the wheel. -Ted. On 6/30/06, Phil Zoio <[EMAIL PROTECTED]> wrote: Joe, Could Struts 1.3 set up to have a separate chain per module? Suppose you wanted to partition your app so that certain parts use one chain configuration and other parts use another. In 1.2 you'd use separate subclasses of RequestProcessor. With Struts 1.3, ideally you should be able to use separate chains. You could for example build a lightweight chain to handle parts of the application with specific performance requirements, and the standard chain for other parts. Bearing in mind that a chain is a pretty lightweight object - there will only be one instance of each command in memory per chain. Any module would by default get the basic pre-supplied chain configuration. However, you would be able to override this using a web.xml entry in the same way that you set up modules. Phil > Joe Germuska wrote: > >> At 9:09 PM +0100 6/14/06, Phil Zoio wrote: >> >>> I can't comment on how people are actually using it, but changing >>> the request processor workflow on a per module basis is quite easy >>> with Struts 1.2. Assuming that this is something which some people >>> are doing, then it would seem to make sense to support this for >>> Struts 1.3 as well, at least for the interests of consistency with >>> previous versions, especially if the 1.2 request processor has been >>> earmarked for deprecation. >> >> >> >> Phil: >> >> Have you looked at what is required to change the workflow in Struts >> 1.3 on a per-module basis? Can you point out where you think it's >> unnecessarily complicated? Do you have any ideas about how to do it >> differently? >> >> Joe >> >> >>> At 9:23 PM +0100 6/13/06, Phil Zoio wrote: >>> Is it possible to have multiple chain configurations for the same Struts 1.3 app. For example, can you configure one module to use tiles and another to not do so? >>> >>> >>> >>> >>> It is technically possible to change which command is looked up in >>> the catalogs and executed to process the request as part of the >>> controller-config on per-module basis. However, you'd need to go >>> to some greater lengths to define the necessary commands and >>> catalogs, because the distributed chain-config.xml in both >>> struts-core and struts-tiles use the same catalog name. The idea >>> was to minimize the places where a user would need to change >>> configurations to use Tiles. >> >> >> >>> >>> For the specific case you cite, there's really no need to do >>> anything special, since if you are using the Tiles request >>> processing chain, nothing prevents you from using ActionForwards >>> which do not point to tiles paths intermixed with those which do. >>> Just use the chain-config packaged in struts-tiles (as indicated at >>> http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d) >>> >>> >>> If people end up doing a lot of mixing and matching of chain >>> catalogs, we would want to make this easier than it is now, but so >>> far we just don't know enough about if or how people are likely to >>> want to do this, so it's hard to know how to make it easier. >>> >> >>> Joe >> >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > >> >> >> > > iO global limited, Registered in England No. 05269056 Reg. Offices: G10 B83 Columba House, Martlesham Heath, Ipswich, Suffolk. IP5 3RE This electronic message contains information from iO global limited which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. This email does not constitute a contract. E&OE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- HTH, Ted. * http://www.husted.com/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 1.3.x: Using multiple chain configurations
Joe, Could Struts 1.3 set up to have a separate chain per module? Suppose you wanted to partition your app so that certain parts use one chain configuration and other parts use another. In 1.2 you'd use separate subclasses of RequestProcessor. With Struts 1.3, ideally you should be able to use separate chains. You could for example build a lightweight chain to handle parts of the application with specific performance requirements, and the standard chain for other parts. Bearing in mind that a chain is a pretty lightweight object - there will only be one instance of each command in memory per chain. Any module would by default get the basic pre-supplied chain configuration. However, you would be able to override this using a web.xml entry in the same way that you set up modules. Phil Joe Germuska wrote: At 9:09 PM +0100 6/14/06, Phil Zoio wrote: I can't comment on how people are actually using it, but changing the request processor workflow on a per module basis is quite easy with Struts 1.2. Assuming that this is something which some people are doing, then it would seem to make sense to support this for Struts 1.3 as well, at least for the interests of consistency with previous versions, especially if the 1.2 request processor has been earmarked for deprecation. Phil: Have you looked at what is required to change the workflow in Struts 1.3 on a per-module basis? Can you point out where you think it's unnecessarily complicated? Do you have any ideas about how to do it differently? Joe At 9:23 PM +0100 6/13/06, Phil Zoio wrote: Is it possible to have multiple chain configurations for the same Struts 1.3 app. For example, can you configure one module to use tiles and another to not do so? It is technically possible to change which command is looked up in the catalogs and executed to process the request as part of the controller-config on per-module basis. However, you'd need to go to some greater lengths to define the necessary commands and catalogs, because the distributed chain-config.xml in both struts-core and struts-tiles use the same catalog name. The idea was to minimize the places where a user would need to change configurations to use Tiles. For the specific case you cite, there's really no need to do anything special, since if you are using the Tiles request processing chain, nothing prevents you from using ActionForwards which do not point to tiles paths intermixed with those which do. Just use the chain-config packaged in struts-tiles (as indicated at http://wiki.apache.org/struts/StrutsUpgradeNotes12to13#head-dfc970a4614f0305c8ac31f1d08fbdfcdd666b5d) If people end up doing a lot of mixing and matching of chain catalogs, we would want to make this easier than it is now, but so far we just don't know enough about if or how people are likely to want to do this, so it's hard to know how to make it easier. Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] iO global limited, Registered in England No. 05269056 Reg. Offices: G10 B83 Columba House, Martlesham Heath, Ipswich, Suffolk. IP5 3RE This electronic message contains information from iO global limited which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. This email does not constitute a contract. E&OE - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
