I wouldn't have a problem with it as long as I can still swap in my trusty
Spring IoC container, I can't see my team moving away from it any time soon,
but I still want to try to stay as current as possible on Struts.
  (*Chris*)

On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <br...@pontarelli.com>wrote:

> They'll be part of the Guice distribution and under ASLv2 since Guice uses
> that.
>
> The real question is how to setup the Injector's. I tend to think this
> layout would be best:
>
>        Base
>            |
>            |
>   _________
>   |                  |
>   |                  |
> Struts        App
>
>
> The Base injector will contain the JEE objects (request, response, etc.)
> and any Struts objects that can be used by the application. The Struts
> injector will contain all of the private objects that should not be
> accessible to the application. The App injector will contain all the
> application objects like Actions and such.
>
> -bp
>
>
> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote:
>
> > good point Brian, that has came up also. I have a couple of concerns
> > about it, like what is the status of the jsr and will the API
> > (annotations) will be under a decent (read ASF compatible license)
> > license and in maven central? which is usually a pain point when it
> > comes to Sun APIs.
> >
> > musachy
> >
> > On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <br...@pontarelli.com>
> wrote:
> >> I'd suggest using Guice trunk and the JSR annotations rather than the
> Guice annotations. I'd also make the injector pluggable so that people can
> plug in Spring/Guice/etc easily.
> >>
> >> -bp
> >>
> >>
> >> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote:
> >>
> >>> I have talked to a couple of people before and everyone seems to agree
> >>> that using guice instead of our internal IoC container (guice pre 1.0
> >>> I think), would be a good idea. I don't have any experience with guice
> >>> 2.0, but looking at the docs it seems like porting our stuff would not
> >>> be that hard. Less code to maintain, and we get more
> >>> features/improvements. If we go with this idea, guice would be shaded
> >>> into xwork to avoid classpath conflicts.
> >>>
> >>> what do you think?
> >>>
> >>> musachy
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> >>> For additional commands, e-mail: dev-h...@struts.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> >> For additional commands, e-mail: dev-h...@struts.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> > For additional commands, e-mail: dev-h...@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
>

Reply via email to