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.)
> *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.
pgp6g1m2OQd6W.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
