You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Kevin Brown <et...@google.com> on 2008/03/23 07:28:40 UTC
[Java] Guice
Hi everyone,
If you're not working with or interested in development of the Java
implementation, you can ignore this.
After discussing this on several separate occasions, I've decided to go
ahead and give using Guice a shot. So far it's coming along pretty nicely,
though it does require a few small changes to some of the current behavior
(mostly cleanup of stuff that was known to be crufty and didn't really get
revisited in the last refactoring changes). For the most part, our code was
pretty DI friendly to start with, so the changes are minimal. Probably the
biggest change is that most configuration will be moving to an external
properties file, and some new classes will need to be introduced to handle
various url generation pieces of CrossServletState.
When I get closer to something complete, I'll be doing the usual JIRA /
patch submission.
If anyone has strong objections to Guice, feel free to speak up -- I've
personally never used it myself, but I've heard good things from other
people about it, and it seems to me to be a bit easier than Spring.
For reference:
http://code.google.com/p/google-guice/source/browse
One minor annoyance -- I have had some trouble finding an up to date maven
repository, so I'm only using the initial 1.0 release that's available on
http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/ -- this
doesn't include some of the servlet integration work, so I still had to wire
up pieces by hand.
--
~Kevin
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
Many apologies for the delay here -- I didn't get it finished on Friday, and
yesterday was my anniversary so I was far away from anything resembling a
computer :)
I'm working on this now. It's a little more complicated than I originally
anticipated.
On Fri, Mar 28, 2008 at 6:00 PM, Kevin Brown <et...@google.com> wrote:
> Scratch 6pm!
>
> I'll be doing this later tonight though -- promise.
>
>
> On Fri, Mar 28, 2008 at 2:41 PM, Kevin Brown <et...@google.com> wrote:
>
> > I'll be including Brian's patch with the final Guice commit to make
> > things go smoother. I'm hoping to have this committed by 6PM PST. Please let
> > me know if anyone has issues!
> >
> >
> > On Thu, Mar 27, 2008 at 1:49 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > Ok -- any other comments or concerns on this, or have they all been
> > > addressed?
> > >
> > > I'm not going to commit this patch until Brian Eaton's new OAuth stuff
> > > is committed, because this patch doesn't properly deal with any token or
> > > signing related code, and I don't want to break anyone depending on it.
> > >
> > > Brian has told me he'll have something soon -- so hopefully this patch
> > > can go in by this weekend (or early next week).
> > >
> > > Any objections to that schedule?
> > >
> > >
> > > On Thu, Mar 27, 2008 at 12:15 PM, Kevin Brown <et...@google.com> wrote:
> > >
> > > > On Thu, Mar 27, 2008 at 6:39 AM, Michael Mahemoff <
> > > > listr@mahemoff.com> wrote:
> > > >
> > > > > It's encouraging to see DI incorporated into Shindig's
> > > > > architecture in
> > > > > an explicit manner such as this.
> > > > >
> > > > > To accommodate the diverse needs of Shindig consumers, I'm hopeful
> > > > > Shindig will, over time, become flexible and plugin-based.
> > > > > Adoption of
> > > > > Guice would be a major step in that direction.
> > > > >
> > > > > Slightly OT, but I expect the Javascript code will also need a
> > > > > means for
> > > > > consumers to switch between different implementations, in order to
> > > > > make
> > > > > browser behaviour more flexible. It would probably work simply by
> > > > > redefining certain variables, but would need a clean separation of
> > > > > concerns in order to work. (Similar to JQuery's plugin
> > > > > architecture.)
> > > >
> > > >
> > > > You can already drop in a custom implementation of any js feature.
> > > > As long as the new code conforms to spec it's fine to replace it in your own
> > > > deployment. In fact, it's actually a requirement for supporting
> > > > opensocial-0.7 today.
> > > >
> > > > The other js (stuff in the javascript/) directory isn't nearly as
> > > > robust, but I wouldn't really endorse using that code on a production site
> > > > anyway unless you feel like doing a lot of work. Paul, Zhen, and Cassie have
> > > > all been doing some work to make it more useful, but I feel that it should
> > > > be scrapped and started from scratch to actually try to meet the needs of
> > > > real sites. The original version was only created as a stopgap solution
> > > > anticipating the creation of the gadget server.
> > > >
> > > >
> > > >
> > > > >
> > > > > Kevin Brown wrote:
> > > > > > Hi everyone,
> > > > > >
> > > > > > If you're not working with or interested in development of the
> > > > > Java
> > > > > > implementation, you can ignore this.
> > > > > >
> > > > > > After discussing this on several separate occasions, I've
> > > > > decided to go
> > > > > > ahead and give using Guice a shot. So far it's coming along
> > > > > pretty nicely,
> > > > > > though it does require a few small changes to some of the
> > > > > current behavior
> > > > > > (mostly cleanup of stuff that was known to be crufty and didn't
> > > > > really get
> > > > > > revisited in the last refactoring changes). For the most part,
> > > > > our code was
> > > > > > pretty DI friendly to start with, so the changes are minimal.
> > > > > Probably the
> > > > > > biggest change is that most configuration will be moving to an
> > > > > external
> > > > > > properties file, and some new classes will need to be introduced
> > > > > to handle
> > > > > > various url generation pieces of CrossServletState.
> > > > > >
> > > > > > When I get closer to something complete, I'll be doing the usual
> > > > > JIRA /
> > > > > > patch submission.
> > > > > >
> > > > > > If anyone has strong objections to Guice, feel free to speak up
> > > > > -- I've
> > > > > > personally never used it myself, but I've heard good things from
> > > > > other
> > > > > > people about it, and it seems to me to be a bit easier than
> > > > > Spring.
> > > > > >
> > > > > > For reference:
> > > > > >
> > > > > > http://code.google.com/p/google-guice/source/browse
> > > > > >
> > > > > > One minor annoyance -- I have had some trouble finding an up to
> > > > > date maven
> > > > > > repository, so I'm only using the initial 1.0 release that's
> > > > > available on
> > > > > > http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/-- this
> > > > > > doesn't include some of the servlet integration work, so I still
> > > > > had to wire
> > > > > > up pieces by hand.
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ~Kevin
> > >
> > >
> > >
> > >
> > > --
> > > ~Kevin
> >
> >
> >
> >
> > --
> > ~Kevin
>
>
>
>
> --
> ~Kevin
--
~Kevin
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
Scratch 6pm!
I'll be doing this later tonight though -- promise.
On Fri, Mar 28, 2008 at 2:41 PM, Kevin Brown <et...@google.com> wrote:
> I'll be including Brian's patch with the final Guice commit to make things
> go smoother. I'm hoping to have this committed by 6PM PST. Please let me
> know if anyone has issues!
>
>
> On Thu, Mar 27, 2008 at 1:49 PM, Kevin Brown <et...@google.com> wrote:
>
> > Ok -- any other comments or concerns on this, or have they all been
> > addressed?
> >
> > I'm not going to commit this patch until Brian Eaton's new OAuth stuff
> > is committed, because this patch doesn't properly deal with any token or
> > signing related code, and I don't want to break anyone depending on it.
> >
> > Brian has told me he'll have something soon -- so hopefully this patch
> > can go in by this weekend (or early next week).
> >
> > Any objections to that schedule?
> >
> >
> > On Thu, Mar 27, 2008 at 12:15 PM, Kevin Brown <et...@google.com> wrote:
> >
> > > On Thu, Mar 27, 2008 at 6:39 AM, Michael Mahemoff <li...@mahemoff.com>
> > > wrote:
> > >
> > > > It's encouraging to see DI incorporated into Shindig's architecture
> > > > in
> > > > an explicit manner such as this.
> > > >
> > > > To accommodate the diverse needs of Shindig consumers, I'm hopeful
> > > > Shindig will, over time, become flexible and plugin-based. Adoption
> > > > of
> > > > Guice would be a major step in that direction.
> > > >
> > > > Slightly OT, but I expect the Javascript code will also need a means
> > > > for
> > > > consumers to switch between different implementations, in order to
> > > > make
> > > > browser behaviour more flexible. It would probably work simply by
> > > > redefining certain variables, but would need a clean separation of
> > > > concerns in order to work. (Similar to JQuery's plugin
> > > > architecture.)
> > >
> > >
> > > You can already drop in a custom implementation of any js feature. As
> > > long as the new code conforms to spec it's fine to replace it in your own
> > > deployment. In fact, it's actually a requirement for supporting
> > > opensocial-0.7 today.
> > >
> > > The other js (stuff in the javascript/) directory isn't nearly as
> > > robust, but I wouldn't really endorse using that code on a production site
> > > anyway unless you feel like doing a lot of work. Paul, Zhen, and Cassie have
> > > all been doing some work to make it more useful, but I feel that it should
> > > be scrapped and started from scratch to actually try to meet the needs of
> > > real sites. The original version was only created as a stopgap solution
> > > anticipating the creation of the gadget server.
> > >
> > >
> > >
> > > >
> > > > Kevin Brown wrote:
> > > > > Hi everyone,
> > > > >
> > > > > If you're not working with or interested in development of the
> > > > Java
> > > > > implementation, you can ignore this.
> > > > >
> > > > > After discussing this on several separate occasions, I've decided
> > > > to go
> > > > > ahead and give using Guice a shot. So far it's coming along pretty
> > > > nicely,
> > > > > though it does require a few small changes to some of the current
> > > > behavior
> > > > > (mostly cleanup of stuff that was known to be crufty and didn't
> > > > really get
> > > > > revisited in the last refactoring changes). For the most part, our
> > > > code was
> > > > > pretty DI friendly to start with, so the changes are minimal.
> > > > Probably the
> > > > > biggest change is that most configuration will be moving to an
> > > > external
> > > > > properties file, and some new classes will need to be introduced
> > > > to handle
> > > > > various url generation pieces of CrossServletState.
> > > > >
> > > > > When I get closer to something complete, I'll be doing the usual
> > > > JIRA /
> > > > > patch submission.
> > > > >
> > > > > If anyone has strong objections to Guice, feel free to speak up --
> > > > I've
> > > > > personally never used it myself, but I've heard good things from
> > > > other
> > > > > people about it, and it seems to me to be a bit easier than
> > > > Spring.
> > > > >
> > > > > For reference:
> > > > >
> > > > > http://code.google.com/p/google-guice/source/browse
> > > > >
> > > > > One minor annoyance -- I have had some trouble finding an up to
> > > > date maven
> > > > > repository, so I'm only using the initial 1.0 release that's
> > > > available on
> > > > > http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/ --
> > > > this
> > > > > doesn't include some of the servlet integration work, so I still
> > > > had to wire
> > > > > up pieces by hand.
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > ~Kevin
> >
> >
> >
> >
> > --
> > ~Kevin
>
>
>
>
> --
> ~Kevin
--
~Kevin
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
I'll be including Brian's patch with the final Guice commit to make things
go smoother. I'm hoping to have this committed by 6PM PST. Please let me
know if anyone has issues!
On Thu, Mar 27, 2008 at 1:49 PM, Kevin Brown <et...@google.com> wrote:
> Ok -- any other comments or concerns on this, or have they all been
> addressed?
>
> I'm not going to commit this patch until Brian Eaton's new OAuth stuff is
> committed, because this patch doesn't properly deal with any token or
> signing related code, and I don't want to break anyone depending on it.
>
> Brian has told me he'll have something soon -- so hopefully this patch can
> go in by this weekend (or early next week).
>
> Any objections to that schedule?
>
>
> On Thu, Mar 27, 2008 at 12:15 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Thu, Mar 27, 2008 at 6:39 AM, Michael Mahemoff <li...@mahemoff.com>
> > wrote:
> >
> > > It's encouraging to see DI incorporated into Shindig's architecture in
> > > an explicit manner such as this.
> > >
> > > To accommodate the diverse needs of Shindig consumers, I'm hopeful
> > > Shindig will, over time, become flexible and plugin-based. Adoption of
> > > Guice would be a major step in that direction.
> > >
> > > Slightly OT, but I expect the Javascript code will also need a means
> > > for
> > > consumers to switch between different implementations, in order to
> > > make
> > > browser behaviour more flexible. It would probably work simply by
> > > redefining certain variables, but would need a clean separation of
> > > concerns in order to work. (Similar to JQuery's plugin architecture.)
> >
> >
> > You can already drop in a custom implementation of any js feature. As
> > long as the new code conforms to spec it's fine to replace it in your own
> > deployment. In fact, it's actually a requirement for supporting
> > opensocial-0.7 today.
> >
> > The other js (stuff in the javascript/) directory isn't nearly as
> > robust, but I wouldn't really endorse using that code on a production site
> > anyway unless you feel like doing a lot of work. Paul, Zhen, and Cassie have
> > all been doing some work to make it more useful, but I feel that it should
> > be scrapped and started from scratch to actually try to meet the needs of
> > real sites. The original version was only created as a stopgap solution
> > anticipating the creation of the gadget server.
> >
> >
> >
> > >
> > > Kevin Brown wrote:
> > > > Hi everyone,
> > > >
> > > > If you're not working with or interested in development of the Java
> > > > implementation, you can ignore this.
> > > >
> > > > After discussing this on several separate occasions, I've decided to
> > > go
> > > > ahead and give using Guice a shot. So far it's coming along pretty
> > > nicely,
> > > > though it does require a few small changes to some of the current
> > > behavior
> > > > (mostly cleanup of stuff that was known to be crufty and didn't
> > > really get
> > > > revisited in the last refactoring changes). For the most part, our
> > > code was
> > > > pretty DI friendly to start with, so the changes are minimal.
> > > Probably the
> > > > biggest change is that most configuration will be moving to an
> > > external
> > > > properties file, and some new classes will need to be introduced to
> > > handle
> > > > various url generation pieces of CrossServletState.
> > > >
> > > > When I get closer to something complete, I'll be doing the usual
> > > JIRA /
> > > > patch submission.
> > > >
> > > > If anyone has strong objections to Guice, feel free to speak up --
> > > I've
> > > > personally never used it myself, but I've heard good things from
> > > other
> > > > people about it, and it seems to me to be a bit easier than Spring.
> > > >
> > > > For reference:
> > > >
> > > > http://code.google.com/p/google-guice/source/browse
> > > >
> > > > One minor annoyance -- I have had some trouble finding an up to date
> > > maven
> > > > repository, so I'm only using the initial 1.0 release that's
> > > available on
> > > > http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/ --
> > > this
> > > > doesn't include some of the servlet integration work, so I still had
> > > to wire
> > > > up pieces by hand.
> > > >
> > >
> > >
> >
> >
> > --
> > ~Kevin
>
>
>
>
> --
> ~Kevin
--
~Kevin
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
Ok -- any other comments or concerns on this, or have they all been
addressed?
I'm not going to commit this patch until Brian Eaton's new OAuth stuff is
committed, because this patch doesn't properly deal with any token or
signing related code, and I don't want to break anyone depending on it.
Brian has told me he'll have something soon -- so hopefully this patch can
go in by this weekend (or early next week).
Any objections to that schedule?
On Thu, Mar 27, 2008 at 12:15 PM, Kevin Brown <et...@google.com> wrote:
> On Thu, Mar 27, 2008 at 6:39 AM, Michael Mahemoff <li...@mahemoff.com>
> wrote:
>
> > It's encouraging to see DI incorporated into Shindig's architecture in
> > an explicit manner such as this.
> >
> > To accommodate the diverse needs of Shindig consumers, I'm hopeful
> > Shindig will, over time, become flexible and plugin-based. Adoption of
> > Guice would be a major step in that direction.
> >
> > Slightly OT, but I expect the Javascript code will also need a means for
> > consumers to switch between different implementations, in order to make
> > browser behaviour more flexible. It would probably work simply by
> > redefining certain variables, but would need a clean separation of
> > concerns in order to work. (Similar to JQuery's plugin architecture.)
>
>
> You can already drop in a custom implementation of any js feature. As long
> as the new code conforms to spec it's fine to replace it in your own
> deployment. In fact, it's actually a requirement for supporting
> opensocial-0.7 today.
>
> The other js (stuff in the javascript/) directory isn't nearly as robust,
> but I wouldn't really endorse using that code on a production site anyway
> unless you feel like doing a lot of work. Paul, Zhen, and Cassie have all
> been doing some work to make it more useful, but I feel that it should be
> scrapped and started from scratch to actually try to meet the needs of real
> sites. The original version was only created as a stopgap solution
> anticipating the creation of the gadget server.
>
>
>
> >
> > Kevin Brown wrote:
> > > Hi everyone,
> > >
> > > If you're not working with or interested in development of the Java
> > > implementation, you can ignore this.
> > >
> > > After discussing this on several separate occasions, I've decided to
> > go
> > > ahead and give using Guice a shot. So far it's coming along pretty
> > nicely,
> > > though it does require a few small changes to some of the current
> > behavior
> > > (mostly cleanup of stuff that was known to be crufty and didn't really
> > get
> > > revisited in the last refactoring changes). For the most part, our
> > code was
> > > pretty DI friendly to start with, so the changes are minimal. Probably
> > the
> > > biggest change is that most configuration will be moving to an
> > external
> > > properties file, and some new classes will need to be introduced to
> > handle
> > > various url generation pieces of CrossServletState.
> > >
> > > When I get closer to something complete, I'll be doing the usual JIRA
> > /
> > > patch submission.
> > >
> > > If anyone has strong objections to Guice, feel free to speak up --
> > I've
> > > personally never used it myself, but I've heard good things from other
> > > people about it, and it seems to me to be a bit easier than Spring.
> > >
> > > For reference:
> > >
> > > http://code.google.com/p/google-guice/source/browse
> > >
> > > One minor annoyance -- I have had some trouble finding an up to date
> > maven
> > > repository, so I'm only using the initial 1.0 release that's available
> > on
> > > http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/ -- this
> > > doesn't include some of the servlet integration work, so I still had
> > to wire
> > > up pieces by hand.
> > >
> >
> >
>
>
> --
> ~Kevin
--
~Kevin
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Thu, Mar 27, 2008 at 6:39 AM, Michael Mahemoff <li...@mahemoff.com>
wrote:
> It's encouraging to see DI incorporated into Shindig's architecture in
> an explicit manner such as this.
>
> To accommodate the diverse needs of Shindig consumers, I'm hopeful
> Shindig will, over time, become flexible and plugin-based. Adoption of
> Guice would be a major step in that direction.
>
> Slightly OT, but I expect the Javascript code will also need a means for
> consumers to switch between different implementations, in order to make
> browser behaviour more flexible. It would probably work simply by
> redefining certain variables, but would need a clean separation of
> concerns in order to work. (Similar to JQuery's plugin architecture.)
You can already drop in a custom implementation of any js feature. As long
as the new code conforms to spec it's fine to replace it in your own
deployment. In fact, it's actually a requirement for supporting
opensocial-0.7 today.
The other js (stuff in the javascript/) directory isn't nearly as robust,
but I wouldn't really endorse using that code on a production site anyway
unless you feel like doing a lot of work. Paul, Zhen, and Cassie have all
been doing some work to make it more useful, but I feel that it should be
scrapped and started from scratch to actually try to meet the needs of real
sites. The original version was only created as a stopgap solution
anticipating the creation of the gadget server.
>
> Kevin Brown wrote:
> > Hi everyone,
> >
> > If you're not working with or interested in development of the Java
> > implementation, you can ignore this.
> >
> > After discussing this on several separate occasions, I've decided to go
> > ahead and give using Guice a shot. So far it's coming along pretty
> nicely,
> > though it does require a few small changes to some of the current
> behavior
> > (mostly cleanup of stuff that was known to be crufty and didn't really
> get
> > revisited in the last refactoring changes). For the most part, our code
> was
> > pretty DI friendly to start with, so the changes are minimal. Probably
> the
> > biggest change is that most configuration will be moving to an external
> > properties file, and some new classes will need to be introduced to
> handle
> > various url generation pieces of CrossServletState.
> >
> > When I get closer to something complete, I'll be doing the usual JIRA /
> > patch submission.
> >
> > If anyone has strong objections to Guice, feel free to speak up -- I've
> > personally never used it myself, but I've heard good things from other
> > people about it, and it seems to me to be a bit easier than Spring.
> >
> > For reference:
> >
> > http://code.google.com/p/google-guice/source/browse
> >
> > One minor annoyance -- I have had some trouble finding an up to date
> maven
> > repository, so I'm only using the initial 1.0 release that's available
> on
> > http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/ -- this
> > doesn't include some of the servlet integration work, so I still had to
> wire
> > up pieces by hand.
> >
>
>
--
~Kevin
Re: [Java] Guice
Posted by Michael Mahemoff <li...@mahemoff.com>.
It's encouraging to see DI incorporated into Shindig's architecture in
an explicit manner such as this.
To accommodate the diverse needs of Shindig consumers, I'm hopeful
Shindig will, over time, become flexible and plugin-based. Adoption of
Guice would be a major step in that direction.
Slightly OT, but I expect the Javascript code will also need a means for
consumers to switch between different implementations, in order to make
browser behaviour more flexible. It would probably work simply by
redefining certain variables, but would need a clean separation of
concerns in order to work. (Similar to JQuery's plugin architecture.)
Kevin Brown wrote:
> Hi everyone,
>
> If you're not working with or interested in development of the Java
> implementation, you can ignore this.
>
> After discussing this on several separate occasions, I've decided to go
> ahead and give using Guice a shot. So far it's coming along pretty nicely,
> though it does require a few small changes to some of the current behavior
> (mostly cleanup of stuff that was known to be crufty and didn't really get
> revisited in the last refactoring changes). For the most part, our code was
> pretty DI friendly to start with, so the changes are minimal. Probably the
> biggest change is that most configuration will be moving to an external
> properties file, and some new classes will need to be introduced to handle
> various url generation pieces of CrossServletState.
>
> When I get closer to something complete, I'll be doing the usual JIRA /
> patch submission.
>
> If anyone has strong objections to Guice, feel free to speak up -- I've
> personally never used it myself, but I've heard good things from other
> people about it, and it seems to me to be a bit easier than Spring.
>
> For reference:
>
> http://code.google.com/p/google-guice/source/browse
>
> One minor annoyance -- I have had some trouble finding an up to date maven
> repository, so I'm only using the initial 1.0 release that's available on
> http://repo1.maven.org/maven2/com/google/code/guice/guice/1.0/ -- this
> doesn't include some of the servlet integration work, so I still had to wire
> up pieces by hand.
>
Re: [Java] Guice
Posted by Evan Gilbert <ui...@google.com>.
+1 on using Guice.
It's a really lightweight way to get most of the benefits of DI.
On Tue, Mar 25, 2008 at 10:50 PM, Kevin Brown <et...@google.com> wrote:
> On Tue, Mar 25, 2008 at 10:43 PM, Brian Eaton <be...@google.com> wrote:
>
> > On Tue, Mar 25, 2008 at 10:09 PM, Kevin Brown <et...@google.com> wrote:
> > > Might I pester some of you guys for feedback on this?
> >
> > Looks OK to me, maybe slightly more obscure than CrossServletState. I
> > had to look up ServletContextListener, but it doesn't look like most
> > people will need to touch that code.
>
>
> Even fewer when Guice 2.0 is released, since this is already implemented
> there. I'm sticking with what's in 1.0 for now though for compatibility's
> sake. I wanted to make it so that you'd just have to implement a Guice
> module (or modules) to modify the server.
>
> There isn't much change from the current state of affairs.
> > Refactoring a few classes so they implement RemoteContentFetcher took
> > around an hour this morning, and I think the code is cleaner for it.
> >
> > I still need the factory methods in CrossServletState. If anything
> > they are getting more complex because of OAuth dependencies on a
> > backend data store. I'm not sure how best to map this to Guice.
> > Maybe inject a factory class? Would that defeat the purpose? If you
> > can get a suitable replacement for GadgetSigner and
> > makeSignedFetchRequestSigner working with Guice I'll probably have an
> > easy merge.
>
>
> A factory would be the way to go here, as far as I can tell. Someone with
> more experience with Guice might know of some way to handle this without
> boilerplate factory code. I should probably start reading guice-users
> archives.
>
> --
> ~Kevin
>
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Tue, Mar 25, 2008 at 10:43 PM, Brian Eaton <be...@google.com> wrote:
> On Tue, Mar 25, 2008 at 10:09 PM, Kevin Brown <et...@google.com> wrote:
> > Might I pester some of you guys for feedback on this?
>
> Looks OK to me, maybe slightly more obscure than CrossServletState. I
> had to look up ServletContextListener, but it doesn't look like most
> people will need to touch that code.
Even fewer when Guice 2.0 is released, since this is already implemented
there. I'm sticking with what's in 1.0 for now though for compatibility's
sake. I wanted to make it so that you'd just have to implement a Guice
module (or modules) to modify the server.
There isn't much change from the current state of affairs.
> Refactoring a few classes so they implement RemoteContentFetcher took
> around an hour this morning, and I think the code is cleaner for it.
>
> I still need the factory methods in CrossServletState. If anything
> they are getting more complex because of OAuth dependencies on a
> backend data store. I'm not sure how best to map this to Guice.
> Maybe inject a factory class? Would that defeat the purpose? If you
> can get a suitable replacement for GadgetSigner and
> makeSignedFetchRequestSigner working with Guice I'll probably have an
> easy merge.
A factory would be the way to go here, as far as I can tell. Someone with
more experience with Guice might know of some way to handle this without
boilerplate factory code. I should probably start reading guice-users
archives.
--
~Kevin
Re: [Java] Guice
Posted by Brian Eaton <be...@google.com>.
On Tue, Mar 25, 2008 at 10:09 PM, Kevin Brown <et...@google.com> wrote:
> Might I pester some of you guys for feedback on this?
Looks OK to me, maybe slightly more obscure than CrossServletState. I
had to look up ServletContextListener, but it doesn't look like most
people will need to touch that code.
> I'm working on an updated patch that addresses some remaining clunkiness in
> RPC. Still unsure how to address Brian Eaton's security stuff since he
> hasn't sent us a patch with it yet.
There isn't much change from the current state of affairs.
Refactoring a few classes so they implement RemoteContentFetcher took
around an hour this morning, and I think the code is cleaner for it.
I still need the factory methods in CrossServletState. If anything
they are getting more complex because of OAuth dependencies on a
backend data store. I'm not sure how best to map this to Guice.
Maybe inject a factory class? Would that defeat the purpose? If you
can get a suitable replacement for GadgetSigner and
makeSignedFetchRequestSigner working with Guice I'll probably have an
easy merge.
Cheers,
Brian
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Wed, Mar 26, 2008 at 2:17 AM, Cassie <do...@apache.org> wrote:
> Also, in your pom.xml I think you may have some tab characters, or the
> indents are just off.
Arg, you're right. Eclipse is dumb.
>
>
> - Cassie
>
>
> On Wed, Mar 26, 2008 at 10:14 AM, Cassie <do...@apache.org> wrote:
>
> > I think guice is a great idea, but I just wanted to mention that your
> > patch seemed a little messy. I think there are some unrelated changes in
> > there which made it a little harder to figure out what the guice change
> was
> > actually doing. If the patch was cleaned up a bit it might make for
> simpler
> > evaluation.
> >
> > That said, +1 for checking it in.
> >
> > - Cassie
> >
> >
> >
> > On Wed, Mar 26, 2008 at 9:15 AM, Martin Webb <ma...@gmail.com>
> > wrote:
> >
> > > Very happy to go down the DI path. I have no experience in Guice, but
> > > plenty in Spring. We (BT.com) will require consumption of existing
> > > components built with Spring - so as long as we can inject Spring
> based
> > > components within Guice based components failry easily then I have no
> > > complaints about using Guice.
> > >
> > > I'm not sure how we would swap out a Guice based component with a
> Spring
> > > based component without wrappering the Spring based one within the
> Guice
> > > based one?
> > >
> > > We also use Spring for JDNI datasouces, Hiberate and iBatis
> integration,
> > > xn
> > > semantics - does Guice provide any of this?
> > >
> > > ps It may sound like it :) but I'm not religious about the use of
> Spring
> > > - I
> > > just need to know what we do/don't get with Guice, and then how easy
> it
> > > is
> > > to use Spring on a needs-by-needs basis.
> > >
> > > Martin
> > >
> > > --
> > > Internet Related Technologies - http://www.irt.org
> > >
> >
> >
>
--
~Kevin
Re: [Java] Guice
Posted by Cassie <do...@apache.org>.
Also, in your pom.xml I think you may have some tab characters, or the
indents are just off.
- Cassie
On Wed, Mar 26, 2008 at 10:14 AM, Cassie <do...@apache.org> wrote:
> I think guice is a great idea, but I just wanted to mention that your
> patch seemed a little messy. I think there are some unrelated changes in
> there which made it a little harder to figure out what the guice change was
> actually doing. If the patch was cleaned up a bit it might make for simpler
> evaluation.
>
> That said, +1 for checking it in.
>
> - Cassie
>
>
>
> On Wed, Mar 26, 2008 at 9:15 AM, Martin Webb <ma...@gmail.com>
> wrote:
>
> > Very happy to go down the DI path. I have no experience in Guice, but
> > plenty in Spring. We (BT.com) will require consumption of existing
> > components built with Spring - so as long as we can inject Spring based
> > components within Guice based components failry easily then I have no
> > complaints about using Guice.
> >
> > I'm not sure how we would swap out a Guice based component with a Spring
> > based component without wrappering the Spring based one within the Guice
> > based one?
> >
> > We also use Spring for JDNI datasouces, Hiberate and iBatis integration,
> > xn
> > semantics - does Guice provide any of this?
> >
> > ps It may sound like it :) but I'm not religious about the use of Spring
> > - I
> > just need to know what we do/don't get with Guice, and then how easy it
> > is
> > to use Spring on a needs-by-needs basis.
> >
> > Martin
> >
> > --
> > Internet Related Technologies - http://www.irt.org
> >
>
>
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Wed, Mar 26, 2008 at 10:41 AM, Cassie <do...@google.com> wrote:
> On Wed, Mar 26, 2008 at 6:35 PM, Kevin Brown <et...@google.com> wrote:
>
> > On Wed, Mar 26, 2008 at 2:14 AM, Cassie <do...@apache.org> wrote:
> >
> > > I think guice is a great idea, but I just wanted to mention that your
> > > patch
> > > seemed a little messy. I think there are some unrelated changes in
> there
> > > which made it a little harder to figure out what the guice change was
> > > actually doing. If the patch was cleaned up a bit it might make for
> > > simpler
> > > evaluation.
> >
> >
> > Could you elaborate? There shouldn't have been any unrelated changes in
> > there. I wound up moving some code around to make the Guice integration
> > cleaner, but I don't think there is anything in there not directly
> related
> > to Guice support refactoring.
>
>
> It may have been just all of the moving then. I would suggest a two part
> change for future large refactorings. One which focuses on actual code
> changes and another that focuses on file renames/moves. svn diffs just
> dont
> really handle moves well which makes the change seem huge and unwieldy,
> when
> it probably really isn't.
Indeed -- more than two thirds of the diff is moving things around. I
probably wrote less than 200 lines of actual new code.
>
> Just my two cents.
>
> - Cassie
>
>
>
> >
> >
> >
> > >
> > > That said, +1 for checking it in.
> > >
> > > - Cassie
> > >
> > >
> > > On Wed, Mar 26, 2008 at 9:15 AM, Martin Webb <ma...@gmail.com>
> > > wrote:
> > >
> > > > Very happy to go down the DI path. I have no experience in Guice,
> but
> > > > plenty in Spring. We (BT.com) will require consumption of existing
> > > > components built with Spring - so as long as we can inject Spring
> > based
> > > > components within Guice based components failry easily then I have
> no
> > > > complaints about using Guice.
> > > >
> > > > I'm not sure how we would swap out a Guice based component with a
> > Spring
> > > > based component without wrappering the Spring based one within the
> > Guice
> > > > based one?
> > > >
> > > > We also use Spring for JDNI datasouces, Hiberate and iBatis
> > integration,
> > > > xn
> > > > semantics - does Guice provide any of this?
> > > >
> > > > ps It may sound like it :) but I'm not religious about the use of
> > Spring
> > > -
> > > > I
> > > > just need to know what we do/don't get with Guice, and then how easy
> > it
> > > is
> > > > to use Spring on a needs-by-needs basis.
> > > >
> > > > Martin
> > > >
> > > > --
> > > > Internet Related Technologies - http://www.irt.org
> > > >
> > >
> >
> >
> >
> > --
> > ~Kevin
> >
>
--
~Kevin
Re: [Java] Guice
Posted by Cassie <do...@google.com>.
On Wed, Mar 26, 2008 at 6:35 PM, Kevin Brown <et...@google.com> wrote:
> On Wed, Mar 26, 2008 at 2:14 AM, Cassie <do...@apache.org> wrote:
>
> > I think guice is a great idea, but I just wanted to mention that your
> > patch
> > seemed a little messy. I think there are some unrelated changes in there
> > which made it a little harder to figure out what the guice change was
> > actually doing. If the patch was cleaned up a bit it might make for
> > simpler
> > evaluation.
>
>
> Could you elaborate? There shouldn't have been any unrelated changes in
> there. I wound up moving some code around to make the Guice integration
> cleaner, but I don't think there is anything in there not directly related
> to Guice support refactoring.
It may have been just all of the moving then. I would suggest a two part
change for future large refactorings. One which focuses on actual code
changes and another that focuses on file renames/moves. svn diffs just dont
really handle moves well which makes the change seem huge and unwieldy, when
it probably really isn't.
Just my two cents.
- Cassie
>
>
>
> >
> > That said, +1 for checking it in.
> >
> > - Cassie
> >
> >
> > On Wed, Mar 26, 2008 at 9:15 AM, Martin Webb <ma...@gmail.com>
> > wrote:
> >
> > > Very happy to go down the DI path. I have no experience in Guice, but
> > > plenty in Spring. We (BT.com) will require consumption of existing
> > > components built with Spring - so as long as we can inject Spring
> based
> > > components within Guice based components failry easily then I have no
> > > complaints about using Guice.
> > >
> > > I'm not sure how we would swap out a Guice based component with a
> Spring
> > > based component without wrappering the Spring based one within the
> Guice
> > > based one?
> > >
> > > We also use Spring for JDNI datasouces, Hiberate and iBatis
> integration,
> > > xn
> > > semantics - does Guice provide any of this?
> > >
> > > ps It may sound like it :) but I'm not religious about the use of
> Spring
> > -
> > > I
> > > just need to know what we do/don't get with Guice, and then how easy
> it
> > is
> > > to use Spring on a needs-by-needs basis.
> > >
> > > Martin
> > >
> > > --
> > > Internet Related Technologies - http://www.irt.org
> > >
> >
>
>
>
> --
> ~Kevin
>
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Wed, Mar 26, 2008 at 2:14 AM, Cassie <do...@apache.org> wrote:
> I think guice is a great idea, but I just wanted to mention that your
> patch
> seemed a little messy. I think there are some unrelated changes in there
> which made it a little harder to figure out what the guice change was
> actually doing. If the patch was cleaned up a bit it might make for
> simpler
> evaluation.
Could you elaborate? There shouldn't have been any unrelated changes in
there. I wound up moving some code around to make the Guice integration
cleaner, but I don't think there is anything in there not directly related
to Guice support refactoring.
>
> That said, +1 for checking it in.
>
> - Cassie
>
>
> On Wed, Mar 26, 2008 at 9:15 AM, Martin Webb <ma...@gmail.com>
> wrote:
>
> > Very happy to go down the DI path. I have no experience in Guice, but
> > plenty in Spring. We (BT.com) will require consumption of existing
> > components built with Spring - so as long as we can inject Spring based
> > components within Guice based components failry easily then I have no
> > complaints about using Guice.
> >
> > I'm not sure how we would swap out a Guice based component with a Spring
> > based component without wrappering the Spring based one within the Guice
> > based one?
> >
> > We also use Spring for JDNI datasouces, Hiberate and iBatis integration,
> > xn
> > semantics - does Guice provide any of this?
> >
> > ps It may sound like it :) but I'm not religious about the use of Spring
> -
> > I
> > just need to know what we do/don't get with Guice, and then how easy it
> is
> > to use Spring on a needs-by-needs basis.
> >
> > Martin
> >
> > --
> > Internet Related Technologies - http://www.irt.org
> >
>
--
~Kevin
Re: [Java] Guice
Posted by Cassie <do...@apache.org>.
I think guice is a great idea, but I just wanted to mention that your patch
seemed a little messy. I think there are some unrelated changes in there
which made it a little harder to figure out what the guice change was
actually doing. If the patch was cleaned up a bit it might make for simpler
evaluation.
That said, +1 for checking it in.
- Cassie
On Wed, Mar 26, 2008 at 9:15 AM, Martin Webb <ma...@gmail.com>
wrote:
> Very happy to go down the DI path. I have no experience in Guice, but
> plenty in Spring. We (BT.com) will require consumption of existing
> components built with Spring - so as long as we can inject Spring based
> components within Guice based components failry easily then I have no
> complaints about using Guice.
>
> I'm not sure how we would swap out a Guice based component with a Spring
> based component without wrappering the Spring based one within the Guice
> based one?
>
> We also use Spring for JDNI datasouces, Hiberate and iBatis integration,
> xn
> semantics - does Guice provide any of this?
>
> ps It may sound like it :) but I'm not religious about the use of Spring -
> I
> just need to know what we do/don't get with Guice, and then how easy it is
> to use Spring on a needs-by-needs basis.
>
> Martin
>
> --
> Internet Related Technologies - http://www.irt.org
>
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Wed, Mar 26, 2008 at 1:15 AM, Martin Webb <ma...@gmail.com>
wrote:
> Very happy to go down the DI path. I have no experience in Guice, but
> plenty in Spring. We (BT.com) will require consumption of existing
> components built with Spring - so as long as we can inject Spring based
> components within Guice based components failry easily then I have no
> complaints about using Guice.
Guice has a spring integration module just for this sort of thing. You can
see it here:
http://code.google.com/p/google-guice/source/browse/trunk/spring/
Of course, you may not need to do anything at all, depending on how you
deploy Shindig. If you're using it as a back end blackbox server (ala
mysql), you probably don't need to think about it much anyway.
>
> I'm not sure how we would swap out a Guice based component with a Spring
> based component without wrappering the Spring based one within the Guice
> based one?
>
> We also use Spring for JDNI datasouces, Hiberate and iBatis integration,
> xn
> semantics - does Guice provide any of this?
No -- Guice focuses on IoC. Specific component integration is generally
handled with provider wrappers. That said, you shouldn't need to change any
of your existing spring stuff to use Shindig if we go with Guice.
>
> ps It may sound like it :) but I'm not religious about the use of Spring -
> I
> just need to know what we do/don't get with Guice, and then how easy it is
> to use Spring on a needs-by-needs basis.
>
> Martin
>
> --
> Internet Related Technologies - http://www.irt.org
>
--
~Kevin
Re: [Java] Guice
Posted by Martin Webb <ma...@gmail.com>.
Very happy to go down the DI path. I have no experience in Guice, but
plenty in Spring. We (BT.com) will require consumption of existing
components built with Spring - so as long as we can inject Spring based
components within Guice based components failry easily then I have no
complaints about using Guice.
I'm not sure how we would swap out a Guice based component with a Spring
based component without wrappering the Spring based one within the Guice
based one?
We also use Spring for JDNI datasouces, Hiberate and iBatis integration, xn
semantics - does Guice provide any of this?
ps It may sound like it :) but I'm not religious about the use of Spring - I
just need to know what we do/don't get with Guice, and then how easy it is
to use Spring on a needs-by-needs basis.
Martin
--
Internet Related Technologies - http://www.irt.org
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Wed, Mar 26, 2008 at 12:33 PM, Alejandro Rivero <al...@gmail.com>
wrote:
> 2008/3/26, Kevin Brown <et...@google.com>:
> > Might I pester some of you guys for feedback on this? I'm looking for a
> few
> > things:
> >
> > Non-committers (and "ordinary" users):
> > 1. Do you think that writing a Guice module is easier than writing your
> own
> > custom CrossServletState? (If you've done neither, then you probably
> don't
> > care about the change anyway).
>
> Do we ordinary users need to write our own CrossServletState?
I'd hope not, but some people may have.
My assumption is that an Ordinary user must at some point to branch,
> in order to provide the particulars of an application: this should be
> (besides some javascript and raw html for our own webserver)
> basically an implementation of the login/ID process and an
> implementation of the opensocial database. In fact the actual
> CrossServletState does not worry a lot about the injection of database
> things into the social objects, so the only points an end-user would
> like to modify are the default paths and this question of
> identification of an user (and, then, storage of gadget defaults)
Right, and these are just configuration variables in the properties file.
--
~Kevin
Re: [Java] Guice
Posted by Alejandro Rivero <al...@gmail.com>.
2008/3/26, Kevin Brown <et...@google.com>:
> Might I pester some of you guys for feedback on this? I'm looking for a few
> things:
>
> Non-committers (and "ordinary" users):
> 1. Do you think that writing a Guice module is easier than writing your own
> custom CrossServletState? (If you've done neither, then you probably don't
> care about the change anyway).
Do we ordinary users need to write our own CrossServletState?
My assumption is that an Ordinary user must at some point to branch,
in order to provide the particulars of an application: this should be
(besides some javascript and raw html for our own webserver)
basically an implementation of the login/ID process and an
implementation of the opensocial database. In fact the actual
CrossServletState does not worry a lot about the injection of database
things into the social objects, so the only points an end-user would
like to modify are the default paths and this question of
identification of an user (and, then, storage of gadget defaults)
What I would thank is an arrangement allowing for this branching (and
the one of the opensocial database handlers) in separate folders
respect to the main development, so that I can keep doing svn update
of the rest of the shindig as it evolves, and keep the development of
my databases at their own speed. The less svn update conflicts I must
to solve, the best.
Alejandro
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
Might I pester some of you guys for feedback on this? I'm looking for a few
things:
Non-committers (and "ordinary" users):
1. Do you think that writing a Guice module is easier than writing your own
custom CrossServletState? (If you've done neither, then you probably don't
care about the change anyway).
2. Is the new propreties-based configuration easier for you to understand,
harder, or about the same?
Committers (and anyone doing heavy integration work):
1. Do you feel that this is a better DI model than what we have at present?
2. Do you think it's a good idea for the project as a whole?
3. Do you have any better suggestions?
I'm working on an updated patch that addresses some remaining clunkiness in
RPC. Still unsure how to address Brian Eaton's security stuff since he
hasn't sent us a patch with it yet.
On Mon, Mar 24, 2008 at 7:09 PM, Kevin Brown <et...@google.com> wrote:
> I'm going to send this patch around in an incomplete form now (doesn't
> handle request signing correctly) so that people can review it. I'm leaving
> off the request signing because of efforts underway to refactor that code
> anyway.
>
> I'll open up a JIRA issue with the patch.
>
>
> On Mon, Mar 24, 2008 at 6:13 AM, Dave <sn...@gmail.com> wrote:
>
> > On Sun, Mar 23, 2008 at 11:45 PM, Kevin Brown <et...@google.com> wrote:
> > > On Sun, Mar 23, 2008 at 8:30 PM, Brian Eaton <be...@google.com>
> > wrote:
> > > I share your concerns as well, having been burned all too often by
> > > heavyweight "frameworks" that just make writing code more difficult
> > than it
> > > needs to be, and I was initially opposed to Guice, but having tried
> > it first
> > > hand I feel that it's a very elegant way to solve the problem, and it
> > looks
> > > like a variant of the same technique is going to wind up in JSR-299,
> > so it's
> > > a pretty sound decision going forward. I'm sure other people who've
> > worked
> > > with Guice directly (I believe both John H and Cassie have) will have
> > more
> > > insight. Initial impressions from my standpoint are pretty high.
> >
> > FWIW, we use Guice on Apache Roller, it's good stuff. it's definitely
> > elegant and it's
> > pretty lightweight both from a conceptual point of view and in physical
> > size.
> >
> > - Dave
> >
>
>
>
> --
> ~Kevin
--
~Kevin
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
I'm going to send this patch around in an incomplete form now (doesn't
handle request signing correctly) so that people can review it. I'm leaving
off the request signing because of efforts underway to refactor that code
anyway.
I'll open up a JIRA issue with the patch.
On Mon, Mar 24, 2008 at 6:13 AM, Dave <sn...@gmail.com> wrote:
> On Sun, Mar 23, 2008 at 11:45 PM, Kevin Brown <et...@google.com> wrote:
> > On Sun, Mar 23, 2008 at 8:30 PM, Brian Eaton <be...@google.com> wrote:
> > I share your concerns as well, having been burned all too often by
> > heavyweight "frameworks" that just make writing code more difficult
> than it
> > needs to be, and I was initially opposed to Guice, but having tried it
> first
> > hand I feel that it's a very elegant way to solve the problem, and it
> looks
> > like a variant of the same technique is going to wind up in JSR-299, so
> it's
> > a pretty sound decision going forward. I'm sure other people who've
> worked
> > with Guice directly (I believe both John H and Cassie have) will have
> more
> > insight. Initial impressions from my standpoint are pretty high.
>
> FWIW, we use Guice on Apache Roller, it's good stuff. it's definitely
> elegant and it's
> pretty lightweight both from a conceptual point of view and in physical
> size.
>
> - Dave
>
--
~Kevin
Re: [Java] Guice
Posted by Dave <sn...@gmail.com>.
On Sun, Mar 23, 2008 at 11:45 PM, Kevin Brown <et...@google.com> wrote:
> On Sun, Mar 23, 2008 at 8:30 PM, Brian Eaton <be...@google.com> wrote:
> I share your concerns as well, having been burned all too often by
> heavyweight "frameworks" that just make writing code more difficult than it
> needs to be, and I was initially opposed to Guice, but having tried it first
> hand I feel that it's a very elegant way to solve the problem, and it looks
> like a variant of the same technique is going to wind up in JSR-299, so it's
> a pretty sound decision going forward. I'm sure other people who've worked
> with Guice directly (I believe both John H and Cassie have) will have more
> insight. Initial impressions from my standpoint are pretty high.
FWIW, we use Guice on Apache Roller, it's good stuff. it's definitely
elegant and it's
pretty lightweight both from a conceptual point of view and in physical size.
- Dave
Re: [Java] Guice
Posted by Kevin Brown <et...@google.com>.
On Sun, Mar 23, 2008 at 8:30 PM, Brian Eaton <be...@google.com> wrote:
> On Sat, Mar 22, 2008 at 11:28 PM, Kevin Brown <et...@google.com> wrote:
> > If anyone has strong objections to Guice, feel free to speak up -- I've
> > personally never used it myself, but I've heard good things from other
> > people about it, and it seems to me to be a bit easier than Spring.
>
> What problem is Guice going to solve?
The only real problem that Guice can solve -- inversion of control
(including dependency injection). CrossServletState does this now, but Guice
normalizes it and makes it quite a bit simpler. Adding support for it has so
far overall definitely improved the cleanliness of the code. I'll be sending
a patch around tomorrow to let everyone else judge for themselves whether
they prefer what we're doing with CrossServletState now to what we can do
with Guice.
What will the process for adding a new external dependency look like
> once we are using Guice?
Not much different at all. Mostly we'll just have to add the appropriate
binding to the Guice module. In most cases this will be as simple as a
single line (in addition to the actual code changes necessary to support the
new feature):
bind(SomeInterface.class).to(SomeImplementation.class)
I don't have strong objections to Guice, never having used it. But
> I'm slightly suspicious of plans to replace a single java class with
> an entire framework. CrossServletState is an ugly hack, but it's a
> *simple* ugly hack.
>
The bright side is that Guice isn't really much of a "framework" (at least
not in the Spring / Struts / Tapestry sense of the term). The total amount
of Guice specific code consists of:
- Two new classes (one of which will disappear when Guice 2.0 becomes
available) -- these replace 3 existing classes in shindig, so that's a net
win.
- Adding a single annotation to constructors
- Adding a new method to the servlets -- we also get to remove one method,
so this is a net win as well.
I share your concerns as well, having been burned all too often by
heavyweight "frameworks" that just make writing code more difficult than it
needs to be, and I was initially opposed to Guice, but having tried it first
hand I feel that it's a very elegant way to solve the problem, and it looks
like a variant of the same technique is going to wind up in JSR-299, so it's
a pretty sound decision going forward. I'm sure other people who've worked
with Guice directly (I believe both John H and Cassie have) will have more
insight. Initial impressions from my standpoint are pretty high.
--
~Kevin
Re: [Java] Guice
Posted by Brian Eaton <be...@google.com>.
On Sat, Mar 22, 2008 at 11:28 PM, Kevin Brown <et...@google.com> wrote:
> If anyone has strong objections to Guice, feel free to speak up -- I've
> personally never used it myself, but I've heard good things from other
> people about it, and it seems to me to be a bit easier than Spring.
What problem is Guice going to solve?
What will the process for adding a new external dependency look like
once we are using Guice?
I don't have strong objections to Guice, never having used it. But
I'm slightly suspicious of plans to replace a single java class with
an entire framework. CrossServletState is an ugly hack, but it's a
*simple* ugly hack.