Menu
▾
▴
springframework-developer
|
From: Colin S. <col...@ex...> - 2004-02-01 04:08:30
|
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_architecture.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...>* >>>>> >>>>> >>>>> >>>>> |
|
From: Keith D. <kd...@cs...> - 2004-02-01 15:00:15
|
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...>* > >>>>> > >>>>> > >>>>> > >>>>> > |
