Hi all,
I'm a little busy at the moment, sorry :).
I'm also in favor of going 100% Spring, however i'm not confortable with
the hard coded load sequence (it makes code maintenance harder due to
Spring version upgrades).
If you could help me here, I would like to clarify. I think the key here is
to centralize the configuration (that's why we need to override the default
load sequence) because, by default, Spring will turn configuration values
like a legos game. Am i correct?
If I'm reasoning it well, i might introduce a new discussion point, that
is, instead of "ConfigurationServices" we could have an Unified Property
Management like Chris Beams posted here (
http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/
).
On 14 May 2013 19:23, Tim Donohue <[email protected]> wrote:
> Hi Mark,
>
> On 5/9/2013 8:11 AM, Mark H. Wood wrote:
> > I think we could get rid of the chicken/egg problems by doing
> > something radical here: abandon the IMHO unused ability to choose DI
> > frameworks, go with Spring (which would take some work to remove, as
> > things have evolved), and gut the DSpace proprietary services
> > framework in favor of (nearly) equivalent Spring facilities. The
> > services themselves would continue, but the rather amazingly
> > complicated way in which they get found and started would be
> > simplified and reoriented toward knowledge and skills that are more
> > widely used.
>
> I'd personally be fine with going with Spring entirely. You may want to
> loop in Mark Diggory on this, to be sure there's no major concerns.
>
> Mark Diggory actually mentions some of the reasoning/tradeoffs of this
> Service Manager approach on the wiki here:
>
>
> https://wiki.duraspace.org/display/DSPACE/DSpace+Spring+Services+Tutorial#DSpaceSpringServicesTutorial-DSpaceConfigurationService
>
> But, as he implies there...Spring is becoming the "dominant" way of
> doing this sort of thing (and DSpace uses Spring elsewhere).
>
> So, all that being said, it seems entirely reasonable (to me) to remove
> this unnecessary abstraction, and migrate to using Spring entirely. As
> you noted, no one has even implemented a Guice Service Manager, so this
> shouldn't "break" anything.
>
> - Tim
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
--
Thanks, João Melo (My Portfolio <http://www.lyncode.com/m/jmelo/>)
DSpace Department
*Lyncode*: Official
website<http://www.google.com/url?q=http%3A%2F%2Fwww.lyncode.com%2F&sa=D&sntz=1&usg=AFrqEzdV8iS6rMxflxnn138XReuRfUG3OQ>
[image: Follow us on
Facebook]<http://www.google.com/url?q=http%3A%2F%2Ftwitter.com%2Flyncode&sa=D&sntz=1&usg=AFrqEzeDuT3ZqMW5uVIA8AoxtTtAeiCX3Q>
<http://www.google.com/url?q=http%3A%2F%2Fwww.facebook.com%2Flyncode&sa=D&sntz=1&usg=AFrqEzcWXjHa3gKBGLsNVxktapxkiWDnww>
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
