Hi Tim,
Great idea I might (not quite sure yet) have some time over the weekend to
update the documentation a bit at least the part about the order in which
spring files are processed, the best practices in the issue in this email,
...
Although t.b.h. somebody will have to read over my documentation to ensure
that it is readable because writing documentation isn't one of my strongest
points I'm afraid.
Kind regards,
Kevin Van de Velde
@mire
Esperantolaan 4 - 3001 Heverlee - Belgium
2888 Loker Avenue East, Suite 305 - Carlsbad, CA 92010 - USA
atmire.com - Institutional Repository Solutions
On 24 August 2011 18:11, Tim Donohue <[email protected]> wrote:
> Just a request:
>
> Could we get these new Spring configs ([dspace]/config/spring/)
> documented somewhere? Along with all these "best practices" which have
> been started in Discovery?
>
> The current official documentation around the Service Manager is
> lacking. It doesn't even mention the new /config/spring/ directories,
> and is riddled with "TODO" statements. It'd really be helpful to get
> this stuff better documented (at least it'd help me) in time for 1.8.0.
>
> It's nice having these public discussions, but I fear we'll continue to
> have these same discussions over and over again until someone turns them
> into documentation.
>
> Here's the current Service Manager docs for 1.8.0. Would be nice to get
> rid of all the TODO statements, and get the new Spring config
> directories documented.
>
> https://wiki.duraspace.org/display/DSDOCDEV/DSpace+Service+Manager
>
> - Tim
>
> On 8/24/2011 10:45 AM, Kevin Van de Velde wrote:
> > On 24 August 2011 16:03, Mark H. Wood <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > On Wed, Aug 24, 2011 at 02:17:17PM +0200, Kevin Van de Velde wrote:
> > > Hi Mark,
> > >
> > > There are 2 ways to ensure that a spring file is loaded, these
> > are briefly
> > > described below.
> > >
> > > *As a Jar addon resource*
> > >
> > > In the resources directory of a certain module a spring can be
> > added if it
> > > matches the following pattern:
> > "spring/spring-dspace-addon-*-services.xml".
> > > An example of this can be found in the dspace-discovery-solr
> > block in the
> > > DSpace trunk. (spring-dspace-addon-*discovery*-services.xml)
> > > Wherever this jar is loaded (JSPUI module, XMLUI module, DSpace
> > command
> > > line, ...) the spring files will be processed into services.
> >
> > Yes. This is appropriate for features which should normally be
> > configured by a person who *packages* DSpace or an add-on. While a
> > site administrator can get at these files and alter them, they get
> > reset to the distributed version by the next upgrade.
> >
> > In my case: dspace-stats is not a add-on, and the new feature I'm
> > adding is to be configured by site admin.s, so this is probably not
> > the best place for those data.
> >
> > > *In the {dspace.dir}/config/spring directory*
> > >
> > > This directory has the following subdirectories in which spring
> > files can be
> > > placed:
> > >
> > > - *api*: when placed in this module the spring files will
> > always be
> > > processed into services (since the all the dspace modules are
> > dependent on
> > > the api)
> > > - *discovery: *when placed in this module the spring will only
> be
> > > processed when the discovery library is present (in the case
> > of discovery in
> > > the xmlui & in the command line interface).
> > > - *jspui:* only processed for the jspui
> > > - *xmlui:* only processed for the xmlui (example: the
> configurable
> > > workflow).
> > >
> > > The reason why there is a separate directory is that if a service
> > cannot be
> > > loaded, which would the case for the configurable workflow (the
> > jspui would
> > > not be able to retrieve the xmlui interface classes), the kernel
> > will crash
> > > and the UI will not started.
> >
> > Yes. So, when a module *in the base DSpace source kit* needs to be
> > configured by Spring, and it's not one of dspace-api,
> > dspace-discovery, dspace-jspui, and dspace-xmlui, then I need to
> > invent a new config/spring/name-of-module directory, mention it in
> > config/dspace.cfg, and add to that module all the plumbing (detailed
> > in my original posting) required to make it visible to the framework
> > and get the content injected into the additional module. Did I find
> > everything I need to do?
> >
> > This placement is appropriate for configuration data which are meant
> > to be adjusted by site administrators, because we make an effort to
> > support merging local changes with updates here. (See the recent
> > thread about whether updated config. files should become config/*.new
> > or old local versions should become config/*.old.)
> >
> >
> > So if you want to do this I would recommend looking at how this is done
> > for discovery. So you need to indeed create a new directory in
> > {dspace.dir}/config/spring. Next you need to create a class that
> > inherits from the *"org.dspace.kernel.config.SpringLoader"*. This class
> > only contains one method named getResourcePaths().
> > What we do now at the moment is implement this in the following manner:
> >
> > @Override
> > public String[] getResourcePaths(ConfigurationService
> > configurationService) {
> > StringBuffer filePath = new StringBuffer();
> >
> > filePath.append(configurationService.getProperty("dspace.dir"));
> > filePath.append(File.separator);
> > filePath.append("config");
> > filePath.append(File.separator);
> > filePath.append("spring");
> > filePath.append(File.separator);
> > filePath.append(*"{module.name <http://module.name>}"*);
> > //Fill in the module name in this string
> > filePath.append(File.separator);
> > try {
> >
> > //By adding the XML_SUFFIX here it doesn't matter if
> > there should be some kind of spring.xml.old file in there it will
> > only load in the active ones.
> >
> > return new String[]{new
> > File(filePath.toString()).toURI().toURL().toString() + *XML_SUFFIX*};
> > } catch (MalformedURLException e) {
> > return new String[0];
> > }
> > }
> >
> >
> > After the class has been created you will also need to it add to the
> > "*springloader.modules*" property located in the
> > {dspace.dir}/config/modules/spring.cfg.
> > The spring service manager will check this property to ensure that only
> > the interface implementations which it can find the class for are loaded
> in.
> >
> > By doing this way we add some flexibility to the developers so that
> > they can always create their own spring modules & then spring will not
> > crash when it can't find a certain class.
> >
> >
> > > *General remarks*
> > >
> > > A spring file can be located in a resource *and* in the config
> > file, when
> > > there are similar spring files the spring files in the
> > configuration will
> > > override these found in the resources (thus allowing users to
> > configure
> > > their own classes). It is indeed recommended to invent some kind
> > of unique
> > > name for your spring file as it is currently unknown to me what
> > the effect
> > > is of files with the same name.
> >
> > Well, there are several cases:
> >
> > o If two such files have the same name and the same final path
> within
> > the aggregated target config/, then the last one copied in
> > replaces all
> > previous contributions. The order, and thus the "winner", would
> be
> > difficult to determine. This doesn't currently happen but I think
> > it is how projects should contribute their Spring configuration
> > data, so if we should implement such a mechanism then we will need
> > to warn folk to be careful about ame collisions.
> >
> > o If two such files have the same name but a different final path
> > within the aggregated target config/, there is no collision and
> > Spring shouldn't care.
> >
> > o The case of a match between resource files and config/spring/*/*
> > files is as you note above: config/ wins.
> >
> > o The case of two resource files with the same name but different
> > path should be identical to the second case above: Spring should
> > consider them distinct and accept both. (Here "path" of course
> has
> > a prefix which is the classpath element which identifies the
> > directory or archive containing the resource.)
> >
> > I don't believe it's possible to express a case in which two resource
> > files have identical full paths.
> >
> > --
> > Mark H. Wood, Lead System Programmer [email protected]
> > Asking whether markets are efficient is like asking whether people
> > are smart.
> >
> >
> ------------------------------------------------------------------------------
> > EMC VNX: the world's simplest storage, starting under $10K
> > The only unified storage solution that offers unified management
> > Up to 160% more powerful than alternatives and 25% more efficient.
> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> > _______________________________________________
> > Dspace-devel mailing list
> > [email protected]
> > <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > EMC VNX: the world's simplest storage, starting under $10K
> > The only unified storage solution that offers unified management
> > Up to 160% more powerful than alternatives and 25% more efficient.
> > Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> >
> >
> >
> > _______________________________________________
> > Dspace-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
