On 24 August 2011 16:03, Mark H. Wood <[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}"*); //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]
> 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
