[Springframework-developer] Re: [Springframework-user] service locator via static accessors

[Keith D. <kd...@cs...>]

Colin,

Yea, I spent some time digesting that article yesterday.  I posted a summary
of what I learned on my blog at http://www.jroller.com/page/kdonald.  I
actually evaluated HiveMind before I got into the details of Eclipse plugin
model--now that I've done that, HiveMind makes a lot more sense. :-)

I too am interested in seeing how Spring and the Eclipse plugin model can be
integrated with rich-client apps built on the Eclipse platform as 3.0
matures.  I'm also interesting in seeing how this this OSGi standard
(Equinox stuff) is going to effect the current architecture

Keith


----- Original Message ----- 
From: "Colin Sampaleanu" <col...@ex...>
To: "Keith Donald" <kd...@cs...>
Cc: <spr...@li...>
Sent: Saturday, January 31, 2004 11:10 PM
Subject: Re: [Springframework-user] service locator via static accessors


> Keith,
>
> That's actually an excellent article about the Eclipse plugin model.
> I've always been impressed with the Eclipse model; I think (especially
> with the dynamic loading and unloading work they're doing for 3.0), that
> it's a well thought out and usable architecture. While there is some
> overlap between the Eclipse plugin model and Spring, they would also be
> complimentary to each other. I think the strength in the Eclipse model
> is it's strong lifecycle support, the isolation it can ensure for
> different code, and its suitability in general for component oriented
> programming, with things like the extension points. Where Spring is very
> strong is in its ease of use and simplicity (I do think Spring is simple
> to use, despite all its features, most of which are orthogonal in nature
> to the core container), and of course the incredibly rich support
> library built around the core, such as the tx and db related
> functionality. As the Eclipse 3.0 stream continues to develop I am going
> to spend more time trying to figure out how Spring fits in that
> environment. Another related project worth keeping an eye on is Howard
> Lewis Ship's HiveMind projects, which is essentially based on the
> Eclipse plugin model, but using some aspects (no pun intended) found in
> Spring, such as the use of interceptors and other bytecode modification.
>
> Regards,
> Colin
>
>
> Keith Donald wrote:
>
> >Colin,
> >
> >Have you seen this article on the Eclipse plugin model/architecture?
>
>http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_archite
cture.html
> >
> >It was a pretty good read.
> >
> >As you probably already know, some of the features provided are similiar
to
> >Spring's microkernel!  A plugin extension point is essentially a
definition
> >of a service interface, and each extension (implementation) is capable of
> >being parameterized (using a very xml-like approach.)  And then there is
a
> >controlling "host plugin" which manages plugging in the extensions,
> >lazy-loading by creating proxies, and invoking an extension's
implementation
> >using callback interfaces or observer-type notifications.  The
> >PluginRegistry is esponsible for loading the individual plugin
definitions
> >at runtime using their own classloader, and their is a mechanism for how
> >different plugins can use each other (though I'm not real clear on that.)
> >
> >What features in the Eclipse model do you think would be useful in
Spring?
> >A way to package a spring bean factory as some kind of plugin that can be
> >loaded on demand?
> >
> >I didn't post this to the list b/c it was a little off-topic, but if you
> >think it's relavent, feel free to post it or your response or whatever.
> >Keith
> >
> >----- Original Message ----- 
> >From: "Colin Sampaleanu" <col...@ex...>
> >To: <spr...@li...>
> >Sent: Friday, January 30, 2004 11:13 PM
> >Subject: Re: [Springframework-user] service locator via static accessors
> >
> >
> >
> >
> >>I'm a fan of maintaining inversion of control if at all possible, so on
> >>that basis, for your scenario, at least to some extent, using either
> >>your solution or the ContextLocator impl. I mentioned has a bit of a bad
> >>smell about it.
> >>
> >>Ultimately, it comes down to how well you can isolate your code from
> >>other code, and how well you can test it. For testing you can presumably
> >>still set up a test context (which creates the singleton instance of
> >>your locator with test objects), and then start using the objects in a
> >>test mode. You do have the limitation that there is that one instance
> >>which all the objects running during the test will have to share, so
> >>depending on the complexity of the test that may or may not be an issue.
> >>For a unit test it would probably not be an issue.
> >>
> >>In terms of coupling, the locator couples classes together to some
> >>extent if it has hard class/interface names in its method signatures,
> >>but adding one or moving one would not break binary compatibility of
> >>code not using those methods.
> >>
> >>At the end of the day, most of the time, I would personally do the extra
> >>work and go for real IOC, except for the small bits of non IOC glue code
> >>that is sometimes needed to kick off the rest of the code in an IOC
> >>fashion. I think if you're careful you can write pretty good code even
> >>using something like a 'global' locator like this, but temptation to do
> >>bad things (break the Law of Demeter and other assorted nasties) will be
> >>much greater.
> >>
> >>(Where this discussion gets more interesting is when you are running in
> >>an environment like the Eclipse plugin model, which through its multiple
> >>classloaders for plugins, extension-points, extensions, and plugin
> >>lifecycles, is essentially like a locator/registry which doesn't let you
> >>do some of the things you really shouldn't be doing. Unfortunately at
> >>this point, Spring doesn't offer much in that respect.)
> >>
> >>
> >>Keith Donald wrote:
> >>
> >>
> >>
> >>>Colin,
> >>>
> >>>I imagine you saw the simple BeanFactoryPostProcessor solution I
posted.
> >>>
> >>>
> >It
> >
> >
> >>>seems to work well and keeps me from being dependent on any Spring
> >>>
> >>>
> >APIs -- 
> >
> >
> >>>the locator and the services it provides access to are simply loaded by
a
> >>>"ServiceLocatorLoader" factory post-processor before any other beans
are
> >>>created in the factory.  I find this solution more attractive than
making
> >>>
> >>>
> >my
> >
> >
> >>>objects that require these services use the ApplicationContext as a
> >>>
> >>>
> >locator
> >
> >
> >>>(which is less typesafe and is a Spring class), or having to inject my
> >>>
> >>>
> >own
> >
> >
> >>>locator on each instance (where again, I have many instance, and not
all
> >>>
> >>>
> >are
> >
> >
> >>>instantiated by the container - some programatically..which for my less
> >>>experience developers I've found can lead to confusion and bugs
> >>>
> >>>
> >(especially
> >
> >
> >>>with setter-injection)....)
> >>>
> >>>So with that said, do you still not like what I'm doing?  The only
extra
> >>>dependency I have is on my service locator class itself because of the
> >>>
> >>>
> >one
> >
> >
> >>>static call.  The other dependencies (the located service interfaces) I
> >>>would have regardless of whether I used the ServiceLocator pattern or
> >>>Dependency Injection.  It seems like a very small price to pay, if any
> >>>(maybe I am missing something?)
> >>>
> >>>Keith
> >>>
> >>>----- Original Message ----- 
> >>>From: "Colin Sampaleanu" <col...@ex...>
> >>>To: <spr...@li...>
> >>>Sent: Wednesday, January 28, 2004 2:39 PM
> >>>Subject: Re: [Springframework-user] service locator via static
accessors
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Keith,
> >>>>
> >>>>Take a look at the BeanFactoryLocator interface I checked in a few
days
> >>>>ago (message describing it was in the dev mailing list), and the hard
> >>>>implementations, SimpleBeanFactoryLocator and
DefaultBeanFactoryLocator,
> >>>>which are keyed-singletons.
> >>>>
> >>>>Personally, in your situation I would do the grunt work for most of
the
> >>>>code to not use any sort of singleton, but the above classes would
> >>>>certainly allow you to do something like:
> >>>>
> >>>>BeanFactoryLocator bfl = LocatorFactory.getInstance();
> >>>>BeanFactory bf = bfl.useFactory("some key to a context, which can also
> >>>>be an alias").getFactory();
> >>>>// now use the BeanFactory as a service locator object
> >>>>MyService myService = (MyService) bf.getBean("myservice");
> >>>>
> >>>>Again, I would stay away from this type of code. These
> >>>>BeanFactoryLocator implementations were more meant for usage in
> >>>>scenarios when you have no other choice at all, e.g. third party code
> >>>>does a Class.forName() call, so you have no other way to get something
> >>>>out of a context. Another usage scenario is demand loading of context,
> >>>>as done by glue code between layers.
> >>>>
> >>>>In your example, you're doing it to save a bit of effort in organizing
> >>>>your classes so everything comes out of the context in IOC fashion,
but
> >>>>you're paying for it because you then have some unnecessary coupling
to
> >>>>Spring.
> >>>>
> >>>>At a minimum, if you were to use these classes in all your code, I
would
> >>>>try to make it easier to unit test stuff by providing a setter for the
> >>>>BeanFactory, and then only looking it up if it's not set. That way,
for
> >>>>a unit test, you would set the servicelocator beanfactory directly,
> >>>>instead of letting the code look it up through the singleton.
> >>>>
> >>>>Regards,
> >>>>Colin
> >>>>
> >>>>
> >>>>Keith Donald wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hey yall,
> >>>>>
> >>>>>I have a question about the use of statics within Spring, particulary
> >>>>>static access to a service locator configured by Spring.  (I know
> >>>>>statics are frowned upon :(, but in my case it makes sense.)
> >>>>>
> >>>>>What's the best way to ensure a statically-accessed service locator
> >>>>>and its dependencies are instantiated before the rest of the objects
> >>>>>in the system?  I thought about the "bean dependsOn" option, but I
> >>>>>have lots of beans, so that seems tedius & error prone.  I could
> >>>>>create a separate "startup" context and load my locator there first,
> >>>>>but I'd like all the beans reachable through one master context if
> >>>>>possible.  Is it possible to use a BeanFactoryPostProcessor
> >>>>>to instantiate the locator first?  Are there any other ways you guys
> >>>>>would recommend?
> >>>>>
> >>>>>Here's a little more background on what I'm doing: I have several
> >>>>>different services most all of my application objects require -- 
> >>>>>messages, iconLoading, actionRegistration, imageLoading/Caching, and
> >>>>>in my system there are lots of little objects running around that
need
> >>>>>these services -- hence having to inject these common dependencies on
> >>>>>every single object is tedius.  If I use setter-injection, I might
> >>>>>forget to configure a object (especially if I need to instantiate
> >>>>>programatically, which sometimes I do.)  If I use constructor
> >>>>>injection, I've got that ServiceLocator as a argument to almost every
> >>>>>constructor, which just seems unnatural.  So the simple compromise is
> >>>>>a static lookup mechanism to a ServiceLocator
> >>>>>instance that retrieves interfaces for each of my services.  The
> >>>>>locator itself is configured by Spring, as are the service instances,
> >>>>>so I don't lose any pluggability, the only trick is I've got to
ensure
> >>>>>the Locator is initialized/configured first.  I need to understand
the
> >>>>>best way to handle that case.
> >>>>>
> >>>>>Thanks!
> >>>>>Keith
> >>>>>
> >>>>>Keith Donald
> >>>>>Senior Software Engineer
> >>>>>*kd...@cs... <mailto:kd...@cs...>*
> >>>>>
> >>>>>
> >>>>>
> >>>>>
>