Re: Conversations (continued from struts 2.2 and guice)
On Saturday 12 December 2009 00:24:41 Dale Newfield wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? Dumb question, but why not have a seperate set of wizard tags and avoid having to guess the context? Or maybe even just an additional wizard='true' attribute? Regards - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
Who would implement all of these features? So many work and potential bugs... Maybe it's the way easier to update SWF plugin to version 2? Gabriel Belingueres-2 wrote: I also agree that implementing something similar to SWF2 is not very compelling. However having implemented conversations build it in the framework have its advantages, mostly because I'm not sure if it can be implemented/integrated very cleanly/easily writing a third party plugin. I was thinking on which features would need to have an implementation of conversations for S2: * Automatic propagation of the conversationId parameter using S2 tags (s:url, s:form, s:action, s:include) unless some no propagation attribute is specified? (implies modify the simple template) * The s:token tag would put the token in conversation scope (need a new token interceptor?) * Add new objects to access from pages: - add a #conversation inside the context map (just like #session, #application, etc.) - modify #attr object to search the current conversation before session * API: - Add interfaces resembling session scope: ConversationAware that injects a MapString, Object. - Add interface to access low level functionality, like getting the conversationId, begin/end conversation, get the conversation map, etc. - Add conversation control with annotations? @Begin, @End? - Add additional control flags to action methods? (I did this in an implementation) Something similar to transaction demarcation: Required, RequiresNew, NotSupported, etc. * Bijection with annotations: Not fundamentally necessary but a neat feature: @In, @Out * Nested conversations support? Similar to Seam (but maybe we can find a way of storing conversation values in a ValueStack, instead of a Map) * Natural conversation ids support: Implies the user supply the conversation id (not hard to implement). I don't know if those features can be obtained by hooking of the plugin extension points. Also all this modifications make me think that perhaps the least intrusive thing to do would be to add a new defaultStack (supporting conversations) instead of modify the current one? Gabriel 2009/12/11 Musachy Barroso musa...@gmail.com: It would be a lot easier to fix the struts plugin to work with SWF 2. Reinventing the wheel is evil. musachy On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26795875.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail:
Re: Conversations (continued from struts 2.2 and guice)
That's what I said. I honestly don't see the point in reinventing the wheel :) On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman aleksandr.si...@gmail.com wrote: Who would implement all of these features? So many work and potential bugs... Maybe it's the way easier to update SWF plugin to version 2? Gabriel Belingueres-2 wrote: I also agree that implementing something similar to SWF2 is not very compelling. However having implemented conversations build it in the framework have its advantages, mostly because I'm not sure if it can be implemented/integrated very cleanly/easily writing a third party plugin. I was thinking on which features would need to have an implementation of conversations for S2: * Automatic propagation of the conversationId parameter using S2 tags (s:url, s:form, s:action, s:include) unless some no propagation attribute is specified? (implies modify the simple template) * The s:token tag would put the token in conversation scope (need a new token interceptor?) * Add new objects to access from pages: - add a #conversation inside the context map (just like #session, #application, etc.) - modify #attr object to search the current conversation before session * API: - Add interfaces resembling session scope: ConversationAware that injects a MapString, Object. - Add interface to access low level functionality, like getting the conversationId, begin/end conversation, get the conversation map, etc. - Add conversation control with annotations? @Begin, @End? - Add additional control flags to action methods? (I did this in an implementation) Something similar to transaction demarcation: Required, RequiresNew, NotSupported, etc. * Bijection with annotations: Not fundamentally necessary but a neat feature: @In, @Out * Nested conversations support? Similar to Seam (but maybe we can find a way of storing conversation values in a ValueStack, instead of a Map) * Natural conversation ids support: Implies the user supply the conversation id (not hard to implement). I don't know if those features can be obtained by hooking of the plugin extension points. Also all this modifications make me think that perhaps the least intrusive thing to do would be to add a new defaultStack (supporting conversations) instead of modify the current one? Gabriel 2009/12/11 Musachy Barroso musa...@gmail.com: It would be a lot easier to fix the struts plugin to work with SWF 2. Reinventing the wheel is evil. musachy On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26795875.html Sent from the Struts - Dev mailing list
Re: Conversations (continued from struts 2.2 and guice)
I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/) and it seems like that development stopped: http://code.google.com/p/struts2webflow/issues/detail?id=19 Musachy, I see you in the Project owners. Do you have any plans on that plugin? Gabriel, do you have a will to fix that plugin? Musachy Barroso wrote: That's what I said. I honestly don't see the point in reinventing the wheel :) On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman aleksandr.si...@gmail.com wrote: Who would implement all of these features? So many work and potential bugs... Maybe it's the way easier to update SWF plugin to version 2? Gabriel Belingueres-2 wrote: I also agree that implementing something similar to SWF2 is not very compelling. However having implemented conversations build it in the framework have its advantages, mostly because I'm not sure if it can be implemented/integrated very cleanly/easily writing a third party plugin. I was thinking on which features would need to have an implementation of conversations for S2: * Automatic propagation of the conversationId parameter using S2 tags (s:url, s:form, s:action, s:include) unless some no propagation attribute is specified? (implies modify the simple template) * The s:token tag would put the token in conversation scope (need a new token interceptor?) * Add new objects to access from pages: - add a #conversation inside the context map (just like #session, #application, etc.) - modify #attr object to search the current conversation before session * API: - Add interfaces resembling session scope: ConversationAware that injects a MapString, Object. - Add interface to access low level functionality, like getting the conversationId, begin/end conversation, get the conversation map, etc. - Add conversation control with annotations? @Begin, @End? - Add additional control flags to action methods? (I did this in an implementation) Something similar to transaction demarcation: Required, RequiresNew, NotSupported, etc. * Bijection with annotations: Not fundamentally necessary but a neat feature: @In, @Out * Nested conversations support? Similar to Seam (but maybe we can find a way of storing conversation values in a ValueStack, instead of a Map) * Natural conversation ids support: Implies the user supply the conversation id (not hard to implement). I don't know if those features can be obtained by hooking of the plugin extension points. Also all this modifications make me think that perhaps the least intrusive thing to do would be to add a new defaultStack (supporting conversations) instead of modify the current one? Gabriel 2009/12/11 Musachy Barroso musa...@gmail.com: It would be a lot easier to fix the struts plugin to work with SWF 2. Reinventing the wheel is evil. musachy On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
Tom is the owner, he wrote it and gave me access. I was going to fix it up for SWF 2, but after my struts project got shot down I never touched it. If anyone wants to help with it let me know, I don't have any plans to update it myself, but I could help. musachy On Tue, Dec 15, 2009 at 9:57 AM, Alex Siman aleksandr.si...@gmail.com wrote: I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/) and it seems like that development stopped: http://code.google.com/p/struts2webflow/issues/detail?id=19 Musachy, I see you in the Project owners. Do you have any plans on that plugin? Gabriel, do you have a will to fix that plugin? Musachy Barroso wrote: That's what I said. I honestly don't see the point in reinventing the wheel :) On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman aleksandr.si...@gmail.com wrote: Who would implement all of these features? So many work and potential bugs... Maybe it's the way easier to update SWF plugin to version 2? Gabriel Belingueres-2 wrote: I also agree that implementing something similar to SWF2 is not very compelling. However having implemented conversations build it in the framework have its advantages, mostly because I'm not sure if it can be implemented/integrated very cleanly/easily writing a third party plugin. I was thinking on which features would need to have an implementation of conversations for S2: * Automatic propagation of the conversationId parameter using S2 tags (s:url, s:form, s:action, s:include) unless some no propagation attribute is specified? (implies modify the simple template) * The s:token tag would put the token in conversation scope (need a new token interceptor?) * Add new objects to access from pages: - add a #conversation inside the context map (just like #session, #application, etc.) - modify #attr object to search the current conversation before session * API: - Add interfaces resembling session scope: ConversationAware that injects a MapString, Object. - Add interface to access low level functionality, like getting the conversationId, begin/end conversation, get the conversation map, etc. - Add conversation control with annotations? @Begin, @End? - Add additional control flags to action methods? (I did this in an implementation) Something similar to transaction demarcation: Required, RequiresNew, NotSupported, etc. * Bijection with annotations: Not fundamentally necessary but a neat feature: @In, @Out * Nested conversations support? Similar to Seam (but maybe we can find a way of storing conversation values in a ValueStack, instead of a Map) * Natural conversation ids support: Implies the user supply the conversation id (not hard to implement). I don't know if those features can be obtained by hooking of the plugin extension points. Also all this modifications make me think that perhaps the least intrusive thing to do would be to add a new defaultStack (supporting conversations) instead of modify the current one? Gabriel 2009/12/11 Musachy Barroso musa...@gmail.com: It would be a lot easier to fix the struts plugin to work with SWF 2. Reinventing the wheel is evil. musachy On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale -
Re: Conversations (continued from struts 2.2 and guice)
Alex: Actually I've chosen the conversations in web applications subject for my thesis, and I intended to demonstrate a working conversation implementation using S2 as the code base (nice candidate framework since it doesn't support them and I have some much experience with it from my daily work.) I took the opportunity to talk about some of my ideas because the subject came up in the mailing list, and perhaps find some useful comments for improvements, but please I'm not trying to sell anything here, and what I finally implement may or may not end up in the S2 code base (so I will probably implement it anyway.) As such, working on the SWF plugin is not my top priority right now. BTW, SWF is a fine framework but is not free of bugs either: I was astonished to find that if you run an app on a Tomcat server which is installed in a directory with spaces in it, it will not work! (SWF 2.0.8). So if you have Tomcat installed in for ex. C:\program files\apache software foundation not even the demo .war files you download from the Springsource's web site will work. See http://www.icefaces.org/JForum/posts/list/6791.page Gabriel 2009/12/15 Musachy Barroso musa...@gmail.com: Tom is the owner, he wrote it and gave me access. I was going to fix it up for SWF 2, but after my struts project got shot down I never touched it. If anyone wants to help with it let me know, I don't have any plans to update it myself, but I could help. musachy On Tue, Dec 15, 2009 at 9:57 AM, Alex Siman aleksandr.si...@gmail.com wrote: I have take a look at SWF plugin (http://code.google.com/p/struts2webflow/) and it seems like that development stopped: http://code.google.com/p/struts2webflow/issues/detail?id=19 Musachy, I see you in the Project owners. Do you have any plans on that plugin? Gabriel, do you have a will to fix that plugin? Musachy Barroso wrote: That's what I said. I honestly don't see the point in reinventing the wheel :) On Tue, Dec 15, 2009 at 7:52 AM, Alex Siman aleksandr.si...@gmail.com wrote: Who would implement all of these features? So many work and potential bugs... Maybe it's the way easier to update SWF plugin to version 2? Gabriel Belingueres-2 wrote: I also agree that implementing something similar to SWF2 is not very compelling. However having implemented conversations build it in the framework have its advantages, mostly because I'm not sure if it can be implemented/integrated very cleanly/easily writing a third party plugin. I was thinking on which features would need to have an implementation of conversations for S2: * Automatic propagation of the conversationId parameter using S2 tags (s:url, s:form, s:action, s:include) unless some no propagation attribute is specified? (implies modify the simple template) * The s:token tag would put the token in conversation scope (need a new token interceptor?) * Add new objects to access from pages: - add a #conversation inside the context map (just like #session, #application, etc.) - modify #attr object to search the current conversation before session * API: - Add interfaces resembling session scope: ConversationAware that injects a MapString, Object. - Add interface to access low level functionality, like getting the conversationId, begin/end conversation, get the conversation map, etc. - Add conversation control with annotations? @Begin, @End? - Add additional control flags to action methods? (I did this in an implementation) Something similar to transaction demarcation: Required, RequiresNew, NotSupported, etc. * Bijection with annotations: Not fundamentally necessary but a neat feature: @In, @Out * Nested conversations support? Similar to Seam (but maybe we can find a way of storing conversation values in a ValueStack, instead of a Map) * Natural conversation ids support: Implies the user supply the conversation id (not hard to implement). I don't know if those features can be obtained by hooking of the plugin extension points. Also all this modifications make me think that perhaps the least intrusive thing to do would be to add a new defaultStack (supporting conversations) instead of modify the current one? Gabriel 2009/12/11 Musachy Barroso musa...@gmail.com: It would be a lot easier to fix the struts plugin to work with SWF 2. Reinventing the wheel is evil. musachy On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor,
Re: struts 2.2 and guice
I thought I'd add my 2 cents. I'm trying to port a plugin to Struts and have been totally stumped on how to get an instance of the object I need because Struts uses a proprietary framework. If we were using Guice, I'd have no problem because of the plethora of docs and other users. So I'd strongly vote in favor of using Guice rather than the current implementation. Also, some of that code is like magic, so I wouldn't ever want to have to make a change to it. Guice on the otherhand is well-supported, so if there's a bug I have more confidence in it getting resolved quickly. To me whether we should support the JSR is a non-issue. Guice almost certainly will end up supporting any standard. Maybe we will have to upgrade Guice versions to add that support in the future, but the upgrade path will be much easier and clearer if we are already using Guice. I don't understand the size argument. Even my cell phone has 4 GB of disk space. andreak wrote: On Thursday 10. December 2009 20.28.48 Musachy Barroso wrote: guys, can you start a different thread for this? :) You have a point there, talk about hijacking a thread:-) -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS| The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment.| | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- View this message in context: http://old.nabble.com/struts-2.2-and-guice-tp26594350p26803368.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
I also agree that implementing something similar to SWF2 is not very compelling. However having implemented conversations build it in the framework have its advantages, mostly because I'm not sure if it can be implemented/integrated very cleanly/easily writing a third party plugin. I was thinking on which features would need to have an implementation of conversations for S2: * Automatic propagation of the conversationId parameter using S2 tags (s:url, s:form, s:action, s:include) unless some no propagation attribute is specified? (implies modify the simple template) * The s:token tag would put the token in conversation scope (need a new token interceptor?) * Add new objects to access from pages: - add a #conversation inside the context map (just like #session, #application, etc.) - modify #attr object to search the current conversation before session * API: - Add interfaces resembling session scope: ConversationAware that injects a MapString, Object. - Add interface to access low level functionality, like getting the conversationId, begin/end conversation, get the conversation map, etc. - Add conversation control with annotations? @Begin, @End? - Add additional control flags to action methods? (I did this in an implementation) Something similar to transaction demarcation: Required, RequiresNew, NotSupported, etc. * Bijection with annotations: Not fundamentally necessary but a neat feature: @In, @Out * Nested conversations support? Similar to Seam (but maybe we can find a way of storing conversation values in a ValueStack, instead of a Map) * Natural conversation ids support: Implies the user supply the conversation id (not hard to implement). I don't know if those features can be obtained by hooking of the plugin extension points. Also all this modifications make me think that perhaps the least intrusive thing to do would be to add a new defaultStack (supporting conversations) instead of modify the current one? Gabriel 2009/12/11 Musachy Barroso musa...@gmail.com: It would be a lot easier to fix the struts plugin to work with SWF 2. Reinventing the wheel is evil. musachy On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
I have created such wizard: - simple LRU cache based on HashMap with fixed capacity, say for 5 elems; - each cache elem collects wizard data; - this cache stored in user session; - each request in wizard flow pass the ID - the key of element (wizard data) in cache; - when wizard get finished - the elem get removed from cache by ID; What do you think about this approach? Gabriel Belingueres-2 wrote: I think this case is correctly handled in SWF: Each time a request fires a state transition, SWF saves a continuation of the current data (think the Memento pattern) Serialized for later use. When the user right-click the next link opening a new window, the state transition put the flow in a new state and as such a new continuation is saved (keeping the last one too.) From now on, the 2 windows execute on different data sets and no interference is possible. SWF only delete all continuations when the flow reaches an end state: if a new request is received on that deleted flow an exception is raised (then protecting from multiple submits, back buttons or as in this case, submits from different windows.) This works because it saves multiple (potentially costly?) copies of the data. As you say, I think JBoss Seam which does support conversations but has no support for continuations can not detect this case. Gabriel That seems like a very imperfect fix for an almost impossible problem. Having an extra parameter on the link won't stop a user from right clicking on the link and saying open in another window and having 2 conversations with the same conversation key. To my knowledge there's just no way to accomplish it cleanly and completely, so you might as well embrace the way the web works and go with it rather than trying to swim upstream. But that's just one man's opinion. (*Chris*) - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26742058.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
This is how most frameworks do it, with continuations. This is essentially trying to do client side storage on the server. The reason it stores information like that is because of the Back/Forward buttons and multiple windows. All of which are client side interactions without a server-side notification (one of the pains of HTTP). You can handle most wizards using client side storage as well and reduce the complexity of server-side state management. This also allows more transparent scaling as the server could be stateless (sometimes). The tricky part is security becomes an issue unless you encrypt all the data and the store it using Base64 or something. With HTML5 and the client side databases (yeah I know they are a ways off) I would expect to see less requirements for continuations and web-flows. -bp On Dec 10, 2009, at 6:22 PM, Gabriel Belingueres wrote: I think this case is correctly handled in SWF: Each time a request fires a state transition, SWF saves a continuation of the current data (think the Memento pattern) Serialized for later use. When the user right-click the next link opening a new window, the state transition put the flow in a new state and as such a new continuation is saved (keeping the last one too.) From now on, the 2 windows execute on different data sets and no interference is possible. SWF only delete all continuations when the flow reaches an end state: if a new request is received on that deleted flow an exception is raised (then protecting from multiple submits, back buttons or as in this case, submits from different windows.) This works because it saves multiple (potentially costly?) copies of the data. As you say, I think JBoss Seam which does support conversations but has no support for continuations can not detect this case. Gabriel That seems like a very imperfect fix for an almost impossible problem. Having an extra parameter on the link won't stop a user from right clicking on the link and saying open in another window and having 2 conversations with the same conversation key. To my knowledge there's just no way to accomplish it cleanly and completely, so you might as well embrace the way the web works and go with it rather than trying to swim upstream. But that's just one man's opinion. (*Chris*) - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
Seems like you are implementing continuations to me. But the point I'm trying to make is that if it is already built-in the web framework, you don't need to do it yourself, and there are actually production ready frameworks with this kind of functionality. Gabriel 2009/12/11 Alex Siman aleksandr.si...@gmail.com: I have created such wizard: - simple LRU cache based on HashMap with fixed capacity, say for 5 elems; - each cache elem collects wizard data; - this cache stored in user session; - each request in wizard flow pass the ID - the key of element (wizard data) in cache; - when wizard get finished - the elem get removed from cache by ID; What do you think about this approach? Gabriel Belingueres-2 wrote: I think this case is correctly handled in SWF: Each time a request fires a state transition, SWF saves a continuation of the current data (think the Memento pattern) Serialized for later use. When the user right-click the next link opening a new window, the state transition put the flow in a new state and as such a new continuation is saved (keeping the last one too.) From now on, the 2 windows execute on different data sets and no interference is possible. SWF only delete all continuations when the flow reaches an end state: if a new request is received on that deleted flow an exception is raised (then protecting from multiple submits, back buttons or as in this case, submits from different windows.) This works because it saves multiple (potentially costly?) copies of the data. As you say, I think JBoss Seam which does support conversations but has no support for continuations can not detect this case. Gabriel That seems like a very imperfect fix for an almost impossible problem. Having an extra parameter on the link won't stop a user from right clicking on the link and saying open in another window and having 2 conversations with the same conversation key. To my knowledge there's just no way to accomplish it cleanly and completely, so you might as well embrace the way the web works and go with it rather than trying to swim upstream. But that's just one man's opinion. (*Chris*) - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- View this message in context: http://old.nabble.com/Conversations-%28continued-from-%22struts-2.2-and-guice%22%29-tp26737327p26742058.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: Conversations (continued from struts 2.2 and guice)
It would be a lot easier to fix the struts plugin to work with SWF 2. Reinventing the wheel is evil. musachy On Fri, Dec 11, 2009 at 2:24 PM, Dale Newfield d...@newfield.org wrote: Gabriel Belingueres wrote: built-in the web framework In order to do this we'd need to add in some information in the form and in every link leading from one page of the form to another so that it's constantly submitted to the server to keep the user associated with the right conversation. The former could be done by adding a hidden element in the s:form freemarker templates, and adding an interceptor that notices that value and does the right thing (sortof like the checkbox interceptor, but instead of modifying the request parameters it has to swap in the target object -- I guess this only makes sense when used in combination with the modelDriven framework (which I've always avoided)). The latter is non-trivial (well, the same interceptor would work). It would mean context-sensitive changes to the output of the URL tag. It wouldn't be too tough for the url tag to look and see if it's inside a s:form tag, but what about other links on the page outside the bounds of the form? What about ones generated before the form open tag? I guess what I'm trying to say is that to get something like this working there are a bunch of moving parts that effect a number of pieces of the framework, and cause the framework to have to inject much more magic into the rendered pages. If it were built in as part of the framework I'd still want it to need to be explicitly specified wherever it's desired (extra attributes on the form, url, and every input tag) so that we don't have users getting freaked out about all the extra stuff in their pages that they didn't ask for. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Wes Wannemacher wrote: Everything is tied to either the request or the session, I can't build wizard-style views Yeah, we need wizards sometimes. -- View this message in context: http://old.nabble.com/struts-2.2-and-guice-tp26594350p26728156.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
On Thursday 10. December 2009 15.31.15 Alex Siman wrote: Wes Wannemacher wrote: Everything is tied to either the request or the session, I can't build wizard-style views Yeah, we need wizards sometimes. I would argue that it would be nice to have, but not a must. Most implementations I've seen of conversation-scope are rather messy and don't provide anything beyond what you can achieve with ScopedModelDriver(scope=session) and some custom-code. I've built several, robust, wizard-like UIs using Struts2 without any problems. -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS| The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment.| | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
What if application needs expirable and parallel (say 5 instances at a time) wizard? andreak wrote: On Thursday 10. December 2009 15.31.15 Alex Siman wrote: Wes Wannemacher wrote: Everything is tied to either the request or the session, I can't build wizard-style views Yeah, we need wizards sometimes. I would argue that it would be nice to have, but not a must. Most implementations I've seen of conversation-scope are rather messy and don't provide anything beyond what you can achieve with ScopedModelDriver(scope=session) and some custom-code. I've built several, robust, wizard-like UIs using Struts2 without any problems. -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS| The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment.| | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org -- View this message in context: http://old.nabble.com/struts-2.2-and-guice-tp26594350p26730390.html Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
On Thursday 10. December 2009 17.37.04 Alex Siman wrote: What if application needs expirable and parallel (say 5 instances at a time) wizard? The point is that you have to save the state using the session (or DB or other persistent storage, but I assume that's more trouble than it's worth) some way or another. Then you can generate a unique key to scope the requested wizards in a map in the session-scoped-model for the specific action and make a mechanism so that this key (unique for each instance of the wizard) is passed for every request. Having instances of a wizard expire requires more work, but should not be magic either. You can f.ex. schedule a Quartz-job using Spring to run every x minute and reap expired wizard-instances which then must register themselves, a static in-memory map should be sufficient, when created. -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS| The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment.| | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Granted, most people implement wizards this way, but the most compelling use of storing state in conversation scope (IMO) is to allow correct behavior when a user clones a browser window, and then allow better support for the back button. Even with conversation support the pages still need to pass along at least one request parameter: the conversation id, so in general terms you end up writing the same thing only that instead of passing actual data as request parameters you pass only a key to some other abstraction. Some conversation implementations are not compelling at all. See the struts2scopeplugin for example, it stores only one conversation per user session which is of course useless for multi-window apps. I've been researching the conversation features in JBoss Seam and Spring Web Flow, which I think are the 2 more important frameworks supporting it. The most sophisticated one is SFW which pretty much abstract the whole page and actions interactions (the flow) into one file, that is an XML file describing a FSM of the states the app is in a given time. For that thing to work, the request parameter that the app pass along in the pages is a composite between the conversation id and the continuation id (a fancy name for naming the current state in the flow FSM the app is in.) Also the conversation scope is the basis for other features like supporting the handy session-per-conversation pattern in ORMs. What I finally mean is that I seriously consider conversation scope support something important (at least for the kind of apps I work in.) Regards Gabriel 2009/12/10 Andreas Joseph Krogh andr...@officenet.no: On Thursday 10. December 2009 15.31.15 Alex Siman wrote: Wes Wannemacher wrote: Everything is tied to either the request or the session, I can't build wizard-style views Yeah, we need wizards sometimes. I would argue that it would be nice to have, but not a must. Most implementations I've seen of conversation-scope are rather messy and don't provide anything beyond what you can achieve with ScopedModelDriver(scope=session) and some custom-code. I've built several, robust, wizard-like UIs using Struts2 without any problems. -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS | The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment. | | | Tlf: +47 24 15 38 90 | | Fax: +47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Chris Pratt wrote: That seems like a very imperfect fix for an almost impossible problem. Having an extra parameter on the link won't stop a user from right clicking on the link and saying open in another window and having 2 conversations with the same conversation key. If the link followed in such a way is from one page of the wizard to another, you're right. If the link followed in such a way is to the start wizard page, presumably that (or even in the submission of the first form of a wizard) is where a new conversation is created, so the two windows could be part of two parallel wizards. -Dale - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
guys, can you start a different thread for this? :) On Thu, Dec 10, 2009 at 11:27 AM, Gabriel Belingueres belingue...@gmail.com wrote: Granted, most people implement wizards this way, but the most compelling use of storing state in conversation scope (IMO) is to allow correct behavior when a user clones a browser window, and then allow better support for the back button. Even with conversation support the pages still need to pass along at least one request parameter: the conversation id, so in general terms you end up writing the same thing only that instead of passing actual data as request parameters you pass only a key to some other abstraction. Some conversation implementations are not compelling at all. See the struts2scopeplugin for example, it stores only one conversation per user session which is of course useless for multi-window apps. I've been researching the conversation features in JBoss Seam and Spring Web Flow, which I think are the 2 more important frameworks supporting it. The most sophisticated one is SFW which pretty much abstract the whole page and actions interactions (the flow) into one file, that is an XML file describing a FSM of the states the app is in a given time. For that thing to work, the request parameter that the app pass along in the pages is a composite between the conversation id and the continuation id (a fancy name for naming the current state in the flow FSM the app is in.) Also the conversation scope is the basis for other features like supporting the handy session-per-conversation pattern in ORMs. What I finally mean is that I seriously consider conversation scope support something important (at least for the kind of apps I work in.) Regards Gabriel 2009/12/10 Andreas Joseph Krogh andr...@officenet.no: On Thursday 10. December 2009 15.31.15 Alex Siman wrote: Wes Wannemacher wrote: Everything is tied to either the request or the session, I can't build wizard-style views Yeah, we need wizards sometimes. I would argue that it would be nice to have, but not a must. Most implementations I've seen of conversation-scope are rather messy and don't provide anything beyond what you can achieve with ScopedModelDriver(scope=session) and some custom-code. I've built several, robust, wizard-like UIs using Struts2 without any problems. -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS | The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment. | | | Tlf: +47 24 15 38 90 | | Fax: +47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
On Thursday 10. December 2009 20.27.32 Gabriel Belingueres wrote: Granted, most people implement wizards this way, but the most compelling use of storing state in conversation scope (IMO) is to allow correct behavior when a user clones a browser window, and then allow better support for the back button. Even with conversation support the pages still need to pass along at least one request parameter: the conversation id, so in general terms you end up writing the same thing only that instead of passing actual data as request parameters you pass only a key to some other abstraction. Some conversation implementations are not compelling at all. See the struts2scopeplugin for example, it stores only one conversation per user session which is of course useless for multi-window apps. I've been researching the conversation features in JBoss Seam and Spring Web Flow, which I think are the 2 more important frameworks supporting it. The most sophisticated one is SFW which pretty much abstract the whole page and actions interactions (the flow) into one file, that is an XML file describing a FSM of the states the app is in a given time. For that thing to work, the request parameter that the app pass along in the pages is a composite between the conversation id and the continuation id (a fancy name for naming the current state in the flow FSM the app is in.) Also the conversation scope is the basis for other features like supporting the handy session-per-conversation pattern in ORMs. What I finally mean is that I seriously consider conversation scope support something important (at least for the kind of apps I work in.) All the wizards I've made the last years are AJAX-based and each step in the wizard knows its index (position) and the next/prev step so it can render nice next/previous buttons and handle reload page nicely. My response to What if the user hits the back-button or ctrl+clicks a link is Doctor it hurts when I do this (bangs fist against head), which means; Dont do that. So the bottom line is - yes I agree that the functionality of conversation-scope is important, but it's not necessarily that hard to implement. I especially do not like having to configure a lot of XML for my wizards to work (like SWF). -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS| The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment.| | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
On Thursday 10. December 2009 20.28.48 Musachy Barroso wrote: guys, can you start a different thread for this? :) You have a point there, talk about hijacking a thread:-) -- Andreas Joseph Krogh andr...@officenet.no Senior Software Developer / CTO +-+ OfficeNet AS| The most difficult thing in the world is to | Rosenholmveien 25 | know how to do a thing and to watch | 1414 Trollåsen | somebody else doing it wrong, without | NORWAY | comment.| | | Tlf:+47 24 15 38 90 | | Fax:+47 24 15 38 91 | | Mobile: +47 909 56 963 | | +-+ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Conversations (continued from struts 2.2 and guice)
I think this case is correctly handled in SWF: Each time a request fires a state transition, SWF saves a continuation of the current data (think the Memento pattern) Serialized for later use. When the user right-click the next link opening a new window, the state transition put the flow in a new state and as such a new continuation is saved (keeping the last one too.) From now on, the 2 windows execute on different data sets and no interference is possible. SWF only delete all continuations when the flow reaches an end state: if a new request is received on that deleted flow an exception is raised (then protecting from multiple submits, back buttons or as in this case, submits from different windows.) This works because it saves multiple (potentially costly?) copies of the data. As you say, I think JBoss Seam which does support conversations but has no support for continuations can not detect this case. Gabriel That seems like a very imperfect fix for an almost impossible problem. Having an extra parameter on the link won't stop a user from right clicking on the link and saying open in another window and having 2 conversations with the same conversation key. To my knowledge there's just no way to accomplish it cleanly and completely, so you might as well embrace the way the web works and go with it rather than trying to swim upstream. But that's just one man's opinion. (*Chris*) - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Without too long of a reply, here are a few thoughts: - Solid, unchanging public APIs are possible - Refactoring and using the latest technologies is the only way to survive - This would not break separation or dictate it for that matter - It would force necessary clean up The benefit is that as Java 7 and JEE6 roll out and JSR 330 possibly gains momentum (which I believe is guaranteed), people will look to the frameworks to support them. Here's a few others that Struts should be using: 303 - Bean validation 315/316 - Async support I'm sure there are others as well. -bp On Dec 8, 2009, at 9:13 PM, Don Brown wrote: Ok, here is how it works at Atlassian and most every software project I've been involved in - changing core dependencies is hard. It is especially hard if you needed to fork said dependencies, which we've had to do quite often at Atlassian. If a green-field Struts 2 application decided, hey, let's just use Guice 2 just like Struts, then what happens down the line when Struts 2 goes to Guice 2.1, which is incompatible? What if that app needed to customize Guice 2.0 or build specific functionality deep into the library? Now, if they wanted to upgrade Struts 2? They'd be stuck until they could upgrade their version of Guice 2? This is not a hypothetical situation. At Atlassian, we have apps like JIRA that are 7 or 8 years old. JIRA, for example, uses a forked version of PicoContainer 1.0 they had to customize for various reasons. Why would they spend a month or two upgrading PicoContainer without gain when they could be building kick-ass features? For this reason, Confluence is running Spring 2.0, Hibernate 2, and WebWork 2.1.7-atlassian-2. It isn't that these products can never change dependencies, just the cost is really high for little to no gain, and if one major upgrade requires another, it is all the more reason not to do the upgrade at all. JSR 330 is not the magic bullet here. Yes, services would then not be tied to a specific DI container, but all the configuration and direct DI container usage sure would be, and in Struts 2, we have heaps. Furthermore, this gives breaks the abstraction between the framework and the host app. We already have enough problems in Struts 2 because we lack an proper API. Externalizing our DI only exasperates this problem. We might as well encourage devs to copy/paste Struts 2 into their project because upgrading sure will be a pain. Again, there are significant costs to this proposal, and I have yet to hear a substantial, real-world benefit. Earlier, we went so far as to define our own logging API because we wanted to keep that boundary between the app and the framework. Sometimes, strict boundaries are a very good thing. Don On Wed, Dec 9, 2009 at 4:38 AM, Brian Pontarelli br...@pontarelli.com wrote: Why do you say that and do you have specific examples? JCatapult uses a single container and it is actually effective and very helpful. This allows you to easily get access to the public API of JCatapult and also to override anything you want. It also makes things faster and lighter weight. There are many applications and developers using it without major issues. I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will. I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the owner. The webapp would declare its primary DI provider and then Struts would just wire up using that. The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this. -bp On Dec 7, 2009, at 4:33 PM, Don Brown wrote: Well, two things: sharing an IoC container with the app is almost always a bad idea in the long run, and two, maybe it is just me in a resource-constrained environment, but 651kb is definitely a big deal, especially if it brings in other dependencies like google collections. The fact that Struts 2 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8,
Re: struts 2.2 and guice
First, injecting the Container (or Injector as it is called) is allowed in the JSR and the API is abstracted well enough that it shouldn't cause major concerns. On the flip-side, I contend that those instances are broken and can be fixed. I also don't agree that 330 is too narrow. It should support everything that XWork does and more, considering XWork is Guice 0.0. I'm not sure what Gavin's objections are, but perhaps someone should shoot Bob, Kevin or Rod an email and get their thoughts on this. -bp On Dec 8, 2009, at 9:24 PM, Don Brown wrote: Remember, there are quite a few places that have the Container instance injected, as they need to query it directly. JSR 330 is too narrowly scoped to fully abstract DI, as folks like Gavin have been quick to point out. Don On Wed, Dec 9, 2009 at 2:47 PM, Brian Pontarelli br...@pontarelli.com wrote: I believe that the simplest route would be to collapse everything into a single core JAR, which includes the workflow and other core APIs. This JAR would would use the JSR 330 annotations and a provide a couple of Module implementations. I would then have the Struts servlet filter wire everything up as needed using a JSR 330 compliant implementation. -bp On Dec 8, 2009, at 5:34 PM, Paul Benedict wrote: Since the XWork code is now owned by Apache (right?), you could split it into two jars (workflow and DI). Then deprecate the DI artifact unless someone here as aspirations to continue such support. Split in two, this would hopefully also address Don's concern of the code base being too big. Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote: XWork is more than DI. If drives the workflow under the hoods of Struts. We would need all of that code in addition to the DI. The idea is to drop the DI part of XWork and replace it with Guice 2.1 (which should support JSR 330) and just pull in the rest of it. -bp On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com wrote: JSR 299 is EE while 330 is SE. -bp On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Don, I started another thread to talk about the API issue, but for this I want to give you my take. The Managed Beans JSR I started reading the other day does offer a few useful features that we don't have. One is the conversation scope, which I think Struts 2 could really benefit from. That's usually the first thing I have to hear from WebWork / Struts 2 users - Everything is tied to either the request or the session, I can't build wizard-style views Another benefit is that our current DI is limiting... In every case that I've used the Container directly, it was because I wanted to pick one instance out of a few possible implementation candidates. It's sort of silly that you have to grab the Container to say - give me the implementation of interface X called 'foo' -Wes On Mon, Dec 7, 2009 at 5:55 PM, Don Brown mr...@twdata.org wrote: Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty significantly sized library for no apparent reason. I tried to use Struts 2 on a project here, and was a bit shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains. Don -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
On Tue, Dec 8, 2009 at 11:22 PM, Don Brown mr...@twdata.org wrote: It isn't about needing a struts-light, it is adding unnecessary bulk. When I was more active, I spent a lot of time trying to kick out dependencies, tighten up our weak API's, and overall simplify interactions with the framework. If you look at the framework space right now, your best bet for a server-side framework is either Grails or possibly Wicket. GWT is increasingly taking over as well. Let's be honest - Struts 2 can't compete with Grails for features and the UI component power of Wicket or GWT. Where it is good, however, is being a small, flexible framework that can integration with just about anything. If we lose this, I'm not sure when I would recommend it. [snip] I am a bit behind here, but we aren't talking about getting rid of the ObjectFactory abstraction and adopting JSR 330 solely for that purpose? If you ask me, I would think that if the Java community is standardizing DI, we should follow suit, internally, as well as making DI available as a pluggable feature the same way we have done in the past. I think one of the biggest barriers of entry is the Container currently. Working on Struts 2 / XWork is hard and the learning curve is steep, and I think a big part of that is our Container. Unless you play around with it and see how it's used everywhere, it is intimidating and part of the reason (I think) why we don't see more patches in JIRA. As far as GWT and Wicket, I don't think we should even compare. The flexibility of our tag library is beyond what I've seen from either of those. I'm not saying they aren't good, but the value stack abstraction and ability to bind data to form fields non-invasively makes it much easier to implement Ajax in some places and server-side manipulation in others. I find struts to be advanced enough for my liking, while still being easy enough that I can be productive. As for Grails, I can't really say, I haven't gotten too much into it yet. -- Wes Wannemacher Head Engineer, WanTii, Inc. Need Training? Struts, Spring, Maven, Tomcat... Ask me for a quote! - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
On Dec 9, 2009, at 2:47 PM, Wes Wannemacher wrote: Don, I started another thread to talk about the API issue, but for this I want to give you my take. The Managed Beans JSR I started reading the other day does offer a few useful features that we don't have. One is the conversation scope, which I think Struts 2 could really benefit from. That's usually the first thing I have to hear from WebWork / Struts 2 users - Everything is tied to either the request or the session, I can't build wizard-style views I've always wondered about these things. I tend to use the request and page storage just because it seems simple and provides we with back button protections cheaply. I've wondered how complex they are to implement server side and the benefits of doing it on the server. The obvious one is security. Are there any others? Another benefit is that our current DI is limiting... In every case that I've used the Container directly, it was because I wanted to pick one instance out of a few possible implementation candidates. It's sort of silly that you have to grab the Container to say - give me the implementation of interface X called 'foo' Guice and the JSR have a number of things to help with this now. -bp - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Why do you say that and do you have specific examples? JCatapult uses a single container and it is actually effective and very helpful. This allows you to easily get access to the public API of JCatapult and also to override anything you want. It also makes things faster and lighter weight. There are many applications and developers using it without major issues. I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will. I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the owner. The webapp would declare its primary DI provider and then Struts would just wire up using that. The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this. -bp On Dec 7, 2009, at 4:33 PM, Don Brown wrote: Well, two things: sharing an IoC container with the app is almost always a bad idea in the long run, and two, maybe it is just me in a resource-constrained environment, but 651kb is definitely a big deal, especially if it brings in other dependencies like google collections. The fact that Struts 2 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso musa...@gmail.com wrote: We could have just one container (no double object factory), and probably the same one could be used for s2 and the app (still to be seen if feasible or not), get any new features that get added or are in jsr 330, and we don't have maintain our own implementation when there is a lib that already does it, like we usually do. Also, guice 2 main jar is 651 kbs, so I don't see much of a problem there. musachy On Mon, Dec 7, 2009 at 2:55 PM, Don Brown mr...@twdata.org wrote: Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty significantly sized library for no apparent reason. I tried to use Struts 2 on a project here, and was a bit shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains. Don On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso musa...@gmail.com wrote: I don't know about dropping Object factory, in this case it would just delegate to the jsr 330 implementation. But getting rid of the double object factory problem would be very nice. On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote: I'm a huge fan of moving to Guice 2 internally, although I'm not sure if we would want to drop the ObjectFactory abstraction for plain pluggable JSR330 DI - as this would imply that Struts 2.2 would not integrate any more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do we really expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the
Re: struts 2.2 and guice
Don, I would argue the opposite... I understand that you are going to have trouble in a resource-constrained environment, and as Musachy mentions later in the thread, there are things we could dump to regain space... But! Most of our users aren't resource-constrained... At least, if they are, they aren't complaining about it. If we moved infrequently used interceptors, results and all their supporting classes into plugins (which would be pretty easy, mostly due to your hard work), then that would just make it more difficult for the vast majority of users. If you want to start a struts2-lite project, I'd be happy to jump in and help out, but I think that resource-constrained environments are the exception, not a rule to live by. -Wes On Mon, Dec 7, 2009 at 6:33 PM, Don Brown mr...@twdata.org wrote: Well, two things: sharing an IoC container with the app is almost always a bad idea in the long run, and two, maybe it is just me in a resource-constrained environment, but 651kb is definitely a big deal, especially if it brings in other dependencies like google collections. The fact that Struts 2 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso musa...@gmail.com wrote: We could have just one container (no double object factory), and probably the same one could be used for s2 and the app (still to be seen if feasible or not), get any new features that get added or are in jsr 330, and we don't have maintain our own implementation when there is a lib that already does it, like we usually do. Also, guice 2 main jar is 651 kbs, so I don't see much of a problem there. musachy On Mon, Dec 7, 2009 at 2:55 PM, Don Brown mr...@twdata.org wrote: Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty significantly sized library for no apparent reason. I tried to use Struts 2 on a project here, and was a bit shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains. Don On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso musa...@gmail.com wrote: I don't know about dropping Object factory, in this case it would just delegate to the jsr 330 implementation. But getting rid of the double object factory problem would be very nice. On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote: I'm a huge fan of moving to Guice 2 internally, although I'm not sure if we would want to drop the ObjectFactory abstraction for plain pluggable JSR330 DI - as this would imply that Struts 2.2 would not integrate any more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do we really expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same
Re: struts 2.2 and guice
In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/
Re: struts 2.2 and guice
I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
JSR 299 is EE while 330 is SE. -bp On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
XWork is more than DI. If drives the workflow under the hoods of Struts. We would need all of that code in addition to the DI. The idea is to drop the DI part of XWork and replace it with Guice 2.1 (which should support JSR 330) and just pull in the rest of it. -bp On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com wrote: JSR 299 is EE while 330 is SE. -bp On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Since the XWork code is now owned by Apache (right?), you could split it into two jars (workflow and DI). Then deprecate the DI artifact unless someone here as aspirations to continue such support. Split in two, this would hopefully also address Don's concern of the code base being too big. Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote: XWork is more than DI. If drives the workflow under the hoods of Struts. We would need all of that code in addition to the DI. The idea is to drop the DI part of XWork and replace it with Guice 2.1 (which should support JSR 330) and just pull in the rest of it. -bp On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com wrote: JSR 299 is EE while 330 is SE. -bp On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I believe that the simplest route would be to collapse everything into a single core JAR, which includes the workflow and other core APIs. This JAR would would use the JSR 330 annotations and a provide a couple of Module implementations. I would then have the Struts servlet filter wire everything up as needed using a JSR 330 compliant implementation. -bp On Dec 8, 2009, at 5:34 PM, Paul Benedict wrote: Since the XWork code is now owned by Apache (right?), you could split it into two jars (workflow and DI). Then deprecate the DI artifact unless someone here as aspirations to continue such support. Split in two, this would hopefully also address Don's concern of the code base being too big. Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote: XWork is more than DI. If drives the workflow under the hoods of Struts. We would need all of that code in addition to the DI. The idea is to drop the DI part of XWork and replace it with Guice 2.1 (which should support JSR 330) and just pull in the rest of it. -bp On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com wrote: JSR 299 is EE while 330 is SE. -bp On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Ok, here is how it works at Atlassian and most every software project I've been involved in - changing core dependencies is hard. It is especially hard if you needed to fork said dependencies, which we've had to do quite often at Atlassian. If a green-field Struts 2 application decided, hey, let's just use Guice 2 just like Struts, then what happens down the line when Struts 2 goes to Guice 2.1, which is incompatible? What if that app needed to customize Guice 2.0 or build specific functionality deep into the library? Now, if they wanted to upgrade Struts 2? They'd be stuck until they could upgrade their version of Guice 2? This is not a hypothetical situation. At Atlassian, we have apps like JIRA that are 7 or 8 years old. JIRA, for example, uses a forked version of PicoContainer 1.0 they had to customize for various reasons. Why would they spend a month or two upgrading PicoContainer without gain when they could be building kick-ass features? For this reason, Confluence is running Spring 2.0, Hibernate 2, and WebWork 2.1.7-atlassian-2. It isn't that these products can never change dependencies, just the cost is really high for little to no gain, and if one major upgrade requires another, it is all the more reason not to do the upgrade at all. JSR 330 is not the magic bullet here. Yes, services would then not be tied to a specific DI container, but all the configuration and direct DI container usage sure would be, and in Struts 2, we have heaps. Furthermore, this gives breaks the abstraction between the framework and the host app. We already have enough problems in Struts 2 because we lack an proper API. Externalizing our DI only exasperates this problem. We might as well encourage devs to copy/paste Struts 2 into their project because upgrading sure will be a pain. Again, there are significant costs to this proposal, and I have yet to hear a substantial, real-world benefit. Earlier, we went so far as to define our own logging API because we wanted to keep that boundary between the app and the framework. Sometimes, strict boundaries are a very good thing. Don On Wed, Dec 9, 2009 at 4:38 AM, Brian Pontarelli br...@pontarelli.com wrote: Why do you say that and do you have specific examples? JCatapult uses a single container and it is actually effective and very helpful. This allows you to easily get access to the public API of JCatapult and also to override anything you want. It also makes things faster and lighter weight. There are many applications and developers using it without major issues. I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will. I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the owner. The webapp would declare its primary DI provider and then Struts would just wire up using that. The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this. -bp On Dec 7, 2009, at 4:33 PM, Don Brown wrote: Well, two things: sharing an IoC container with the app is almost always a bad idea in the long run, and two, maybe it is just me in a resource-constrained environment, but 651kb is definitely a big deal, especially if it brings in other dependencies like google collections. The fact that Struts 2 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso musa...@gmail.com wrote: We could have just one container (no double object factory), and probably the same one could be used for s2 and the app (still to be seen if feasible or not), get any new features that get added or are in jsr 330, and we don't have maintain our own implementation when there is a lib that already does it, like we usually do. Also, guice 2 main jar is 651 kbs, so I don't see much of a problem there. musachy On Mon, Dec 7, 2009 at 2:55 PM, Don Brown mr...@twdata.org wrote: Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty
Re: struts 2.2 and guice
On Wed, Dec 9, 2009 at 11:34 AM, Paul Benedict pbened...@apache.org wrote: Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Don't count on it. Bob has moved on from Struts 2, so I would count on anything beyond moral support. :) Don Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote: XWork is more than DI. If drives the workflow under the hoods of Struts. We would need all of that code in addition to the DI. The idea is to drop the DI part of XWork and replace it with Guice 2.1 (which should support JSR 330) and just pull in the rest of it. -bp On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com wrote: JSR 299 is EE while 330 is SE. -bp On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Remember, there are quite a few places that have the Container instance injected, as they need to query it directly. JSR 330 is too narrowly scoped to fully abstract DI, as folks like Gavin have been quick to point out. Don On Wed, Dec 9, 2009 at 2:47 PM, Brian Pontarelli br...@pontarelli.com wrote: I believe that the simplest route would be to collapse everything into a single core JAR, which includes the workflow and other core APIs. This JAR would would use the JSR 330 annotations and a provide a couple of Module implementations. I would then have the Struts servlet filter wire everything up as needed using a JSR 330 compliant implementation. -bp On Dec 8, 2009, at 5:34 PM, Paul Benedict wrote: Since the XWork code is now owned by Apache (right?), you could split it into two jars (workflow and DI). Then deprecate the DI artifact unless someone here as aspirations to continue such support. Split in two, this would hopefully also address Don's concern of the code base being too big. Lastly, because Bob Lee is a Struts committer, you should get pretty good support from him on. Paul On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli br...@pontarelli.com wrote: XWork is more than DI. If drives the workflow under the hoods of Struts. We would need all of that code in addition to the DI. The idea is to drop the DI part of XWork and replace it with Guice 2.1 (which should support JSR 330) and just pull in the rest of it. -bp On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli br...@pontarelli.com wrote: JSR 299 is EE while 330 is SE. -bp On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: I've been loosely following the thread. It sounds like three DI projects are being/will be supported: * XWork * Guice * JSR-299/JSR-330 Why three? I can understand the last because it's EE, but the other two are proprietary. Paul On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart lukasz.len...@googlemail.com wrote: In my opinion, current DI support is sufficient (it can be made more readable, but that's it ;-), I really don't get it what's the problem with double ObjectFactory issue??? Regards -- Lukasz http://www.lenart.org.pl/ - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Don, JSR 330 is not the magic bullet here. Agreed, but I would have to say it would be foolish not to support it. As companies perform internal tech evaluations, people will eventually realize standard DI injection is not supported: Oh, our company has to learn XWork DI? What the heck is XWork? Well, that could be seen as a negative and affect adoption. A FUTURE scenario, but one likely to occur one day. I don't care what DI container runs JSR-330, but it should be the job of Struts 2 to allow *swappable* implementations through a Bridge adapter. Will our users have the choice of Apache's Open Web Beans [1]? I hope so. Likewise, Commons Validator 2.0 will be a JSR-303 Bean Validation implementation. Same lesson to be learned here. [1] http://incubator.apache.org/openwebbeans/ Paul - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I'm a huge fan of moving to Guice 2 internally, although I'm not sure if we would want to drop the ObjectFactory abstraction for plain pluggable JSR330 DI - as this would imply that Struts 2.2 would not integrate any more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do we really expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | StrutsApp The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the
Re: struts 2.2 and guice
I don't know about dropping Object factory, in this case it would just delegate to the jsr 330 implementation. But getting rid of the double object factory problem would be very nice. On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote: I'm a huge fan of moving to Guice 2 internally, although I'm not sure if we would want to drop the ObjectFactory abstraction for plain pluggable JSR330 DI - as this would imply that Struts 2.2 would not integrate any more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do we really expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM,
Re: struts 2.2 and guice
Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty significantly sized library for no apparent reason. I tried to use Struts 2 on a project here, and was a bit shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains. Don On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso musa...@gmail.com wrote: I don't know about dropping Object factory, in this case it would just delegate to the jsr 330 implementation. But getting rid of the double object factory problem would be very nice. On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote: I'm a huge fan of moving to Guice 2 internally, although I'm not sure if we would want to drop the ObjectFactory abstraction for plain pluggable JSR330 DI - as this would imply that Struts 2.2 would not integrate any more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do we really expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of
Re: struts 2.2 and guice
Well, two things: sharing an IoC container with the app is almost always a bad idea in the long run, and two, maybe it is just me in a resource-constrained environment, but 651kb is definitely a big deal, especially if it brings in other dependencies like google collections. The fact that Struts 2 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso musa...@gmail.com wrote: We could have just one container (no double object factory), and probably the same one could be used for s2 and the app (still to be seen if feasible or not), get any new features that get added or are in jsr 330, and we don't have maintain our own implementation when there is a lib that already does it, like we usually do. Also, guice 2 main jar is 651 kbs, so I don't see much of a problem there. musachy On Mon, Dec 7, 2009 at 2:55 PM, Don Brown mr...@twdata.org wrote: Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty significantly sized library for no apparent reason. I tried to use Struts 2 on a project here, and was a bit shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains. Don On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso musa...@gmail.com wrote: I don't know about dropping Object factory, in this case it would just delegate to the jsr 330 implementation. But getting rid of the double object factory problem would be very nice. On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote: I'm a huge fan of moving to Guice 2 internally, although I'm not sure if we would want to drop the ObjectFactory abstraction for plain pluggable JSR330 DI - as this would imply that Struts 2.2 would not integrate any more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do we really expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork.
Re: struts 2.2 and guice
I can't think of any bug, and I hope there isn't any because that code looks like voodoo to me. Using the same container for both is arguable, as I said before I am not sold either way.If you have a resource constrained environment there are other things that we can do to reduce the size, which I have had in mind but never had any motivation to do, like remove all deprecated code, and extract the non simple tags into a plugin (these are the low hanging fruits). IMO, do we have a *lot* to gain from it? probably not, but I am always in favor of eliminating any code that we have and is well done by other libraries On Mon, Dec 7, 2009 at 3:33 PM, Don Brown mr...@twdata.org wrote: Well, two things: sharing an IoC container with the app is almost always a bad idea in the long run, and two, maybe it is just me in a resource-constrained environment, but 651kb is definitely a big deal, especially if it brings in other dependencies like google collections. The fact that Struts 2 is almost 5 megs means it is a no-go for me to use in our embedded OSGi container. I was hoping to get it back down under 2 megs, but with Guice 2, that would be quite unlikely. What features exactly do we need or how many bugs have cropped up in our DI container that we would be avoiding? Don On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso musa...@gmail.com wrote: We could have just one container (no double object factory), and probably the same one could be used for s2 and the app (still to be seen if feasible or not), get any new features that get added or are in jsr 330, and we don't have maintain our own implementation when there is a lib that already does it, like we usually do. Also, guice 2 main jar is 651 kbs, so I don't see much of a problem there. musachy On Mon, Dec 7, 2009 at 2:55 PM, Don Brown mr...@twdata.org wrote: Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty significantly sized library for no apparent reason. I tried to use Struts 2 on a project here, and was a bit shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains. Don On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso musa...@gmail.com wrote: I don't know about dropping Object factory, in this case it would just delegate to the jsr 330 implementation. But getting rid of the double object factory problem would be very nice. On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen gie...@it-neering.net wrote: I'm a huge fan of moving to Guice 2 internally, although I'm not sure if we would want to drop the ObjectFactory abstraction for plain pluggable JSR330 DI - as this would imply that Struts 2.2 would not integrate any more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do we really expect every Struts2 user and his company will be able to move to JSR330 compliant DI within the next months? I doubt that, and I'd rather not sacrifice our DI abstraction for that reason... - Rene Musachy Barroso wrote: I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable).
struts 2.2 and guice
I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | StrutsApp The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | StrutsApp The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I don't see a clear distinction between the Struts injector and the App injector. One thing to keep in mind is that user often request how to access struts internal stuff, like action mapping etc, which in theory should not happen, but it does. musachy On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.com wrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso musa...@gmail.com wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. If it's internal use only, so to speak, then why do we care about whether it's JSR annotations versus Guice annotations, and why would we want to make it pluggable? Those are things that app authors might care about, but not something we need to complicate the internal implementation with. -- Martin Cooper On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | StrutsApp The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
I have mixed feelings about it. making it pluggeable is not a priority I would say. But if there are standard annotations for it now, then there is no reason why we shouldn't use them. If the day comes when guice is no longer supported (I don't really mean it crazybob :)), it would be easier to find alternatives. On Tue, Dec 1, 2009 at 10:34 AM, Martin Cooper mart...@apache.org wrote: On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso musa...@gmail.com wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. If it's internal use only, so to speak, then why do we care about whether it's JSR annotations versus Guice annotations, and why would we want to make it pluggable? Those are things that app authors might care about, but not something we need to complicate the internal implementation with. -- Martin Cooper On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
Because you don't want to use separate containers. In Guice you can have child-parent injector relationships. My thought is to just have a single DI container that builds everything. Struts no longer has any concept of an ObjectFactory and doesn't create actions or anything like that. It would just invoke actions created by the DI container. Plus, if folks are asking for access to internals, this makes it simpler. You could also take the JCatapult approach and just have a single injector for everything. I personally like that approach the best, but Struts has had issues with public API breakage in the past and that would no longer be allowed if you have a single Injector. That is unless you roll a major version and follow a strict runtime compatibility methodology for a single major version's lineage. -bp On Dec 1, 2009, at 11:34 AM, Martin Cooper wrote: On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso musa...@gmail.com wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. If it's internal use only, so to speak, then why do we care about whether it's JSR annotations versus Guice annotations, and why would we want to make it pluggable? Those are things that app authors might care about, but not something we need to complicate the internal implementation with. -- Martin Cooper On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | StrutsApp The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe,
Re: struts 2.2 and guice
ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: struts 2.2 and guice
We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | StrutsApp The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail:
Re: struts 2.2 and guice
It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail:
Re: struts 2.2 and guice
I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso musa...@gmail.com wrote: It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli br...@pontarelli.com wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli br...@pontarelli.com wrote: I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt thechrispr...@gmail.com wrote: I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli br...@pontarelli.comwrote: They'll be part of the Guice distribution and under ASLv2 since Guice uses that. The real question is how to setup the Injector's. I tend to think this layout would be best: Base | | _ | | | | Struts App The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. -bp On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli br...@pontarelli.com wrote: I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. -bp On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: I have talked to a couple of people before and everyone seems to agree that using guice instead of our internal IoC container (guice pre 1.0 I think), would be a good idea. I don't have any experience with guice 2.0, but looking at the docs it seems like porting our stuff would not be that hard. Less code to maintain, and we get more features/improvements. If we go with this idea, guice would be shaded into xwork to avoid classpath conflicts. what do you think? musachy - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe,
