|
Hi Mark,
I'm trying, without success, to reproduce the issues that I have reported during the last IRC developer chat (early access to configurationservice cause issues). Digging in our current code (not yet shared on github for the dspace-cris project :-( ) I see that we use with success the ConfigurationService. We inject it in a Factory that produce a datasource suitable for initialize an Hibernate session...so as far I can see... no issues in early use Looking to our internal svn history I see a note that say that a previous attempt done using ConfigurationManager fails because the ConfigurationManager was not fully initialized during the spring context startup. Sure the ConfigurationService and ConfigurationManager have different lifecycle and this is confusing. About this sentence We use it to configure the location of the spring configuration files for additional module (for example dspace-cris add it own org.dspace.kernel.config.SpringLoader to allow the override of default configuration in dspace/config/spring/cris/*.xml)The only reason why a ConfigurationService is created first seems to be that we want to be able to configure additional Spring configuration files to be loaded in some cases. Since this seems to be only for testing -- it only ever appears in a test Properties resource -- we should probably find some other way to provide this one String and not use the main configuration code to fetch it. Of course we can decide to remove the need of such configuration introducing the convention to read anything under dspace/config/spring/*/*.xml I'm not sure about the advantage vs complexity to wrap the Spring container in our custom infrastracture, at the moment I can only see complexity issues, the advantage (to be uncoupled with spring) that I can imagine is only theoretical and will require a lot of work to be real (we need to produce other servicemanager, we need to change a lot of configurations/documentations as we are going to configure everything as spring beans). Sure the 2.0 team that has produced the dspace-services infrastructure can talk more about advantages. Andrea Il 09/05/2013 17:46, Mark H. Wood ha scritto: Digging into the code, I find that there is no GuiceServiceManager. In fact the only extensions of ServiceManagerSystem are DSpaceServiceManager (the one we actually call), MockServiceManagerSystem, ExternalServiceManagerSystem (a subinterface), and SpringServiceManager.So DSpaceServiceManager is managing a list of one ServiceManagerSystem which is always SpringServiceManager. This can probably be simplified. If there were only one ServiceManager, it could create a ConfigurationService whenever it needs to. In the case of SpringServiceManager it could create the ApplicationContext before the ConfigurationService -- in fact the chosen ConfigurationService could be specified in the ApplicationContext's configuration if that were useful, and injected to key objects. The only reason why a ConfigurationService is created first seems to be that we want to be able to configure additional Spring configuration files to be loaded in some cases. Since this seems to be only for testing -- it only ever appears in a test Properties resource -- we should probably find some other way to provide this one String and not use the main configuration code to fetch it. Possibly it could be a system property or a Context parameter. Making that change removes the sequencing requirement for ConfigurationService and ApplicationContext. I have never been able to figure out why one would want more than one ServiceManager running in a given instance of DSpace. (Nor can I see why we would want more than one Kernel, which is also provided for.) Comments? --
|
------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
