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 > 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: 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 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.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 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
guys, can you start a different thread for this? :) On Thu, Dec 10, 2009 at 11:27 AM, 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.) > > Regards > Gabriel > > 2009/12/10 Andreas Joseph Krogh : >> 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 >> 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
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
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*) On Thu, Dec 10, 2009 at 11:27 AM, 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.) > > Regards > Gabriel > > 2009/12/10 Andreas Joseph Krogh : > > 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 > > 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
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 : > 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 > 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
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 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 > 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 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 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
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 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
On Tue, Dec 8, 2009 at 11:22 PM, Don Brown 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
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 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
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 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 >>> 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 > 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 >>> 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
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 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 h
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
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 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 >> 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 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 >> 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
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. Don On Wed, Dec 9, 2009 at 5:08 AM, Wes Wannemacher wrote: > 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 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 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 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 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 > 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 >>> 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:4
Re: struts 2.2 and guice
On Wed, Dec 9, 2009 at 11:34 AM, Paul Benedict 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 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 >>> 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 > 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 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 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 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
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 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 >>> 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 > 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
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 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 >> 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 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
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 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 >>> 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
Then what was the point of getting the IP for XWork? On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli 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 >> 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
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 > 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
what we are proposing/talking is to use only JSR 330, which is the spec. The actual implementation (default) would be guice. musachy On Tue, Dec 8, 2009 at 3: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 > 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
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 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
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
will this mean that struts 2.2 will support MVP or any idea to put GWT also :) F
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 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 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 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 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 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 >> 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 >>> 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 > wrote: >> I was actually talking about expandin
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 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 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 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 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 >> 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 >>> wrote: We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp >>>
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 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 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 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 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 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 >> 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 >>> 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 > 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 >> Str
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 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 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 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 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 > 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 >> 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 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 > w
Re: struts 2.2 and guice
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 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 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 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 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 > 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 >>> 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 > 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 w
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 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 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 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 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 >> 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 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 > 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 >> | >> | >> _ >> | | >>>
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 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 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 >>> 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 > 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 >>> 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 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
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 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 >> 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 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 >> 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 >>> 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 | | _ | | | | 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 Pon
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 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 > 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 >>> 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 > 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 >> 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 >>> 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 th
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 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 >> 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 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 > 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 >> 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 > > - >
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 > 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 >>> 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 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 >| >| > _ > | | > | | > 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 > 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...@
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 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 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 >>> 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 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
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 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 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 >>> 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 | | _ | | | | 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 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:
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 wrote: > On Tue, Dec 1, 2009 at 10: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. > > 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 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 >>> 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 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
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 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 >> 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 >>>| >>>| >>> _ >>> | | >>> | | >>> 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 >>> 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
On Tue, Dec 1, 2009 at 10: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. 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 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 >> 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 >>> 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 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 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 >> 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
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 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 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 >> 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 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 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 >| >| > _ > | | > | | > 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 > 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
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 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
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 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
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