Re: [Dspace-devel] Configuring a new module via Spring
It was a bit later then the weekend but I finally got round to writing some documentation about the spring based configuration at the following location: https://wiki.duraspace.org/display/DSDOCDEV/DSpace+Service+Manager. Please be aware that I only added some documentation on the configuring spring addon section. 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 19:30, Mark H. Wood mw...@iupui.edu wrote: On Wed, Aug 24, 2011 at 06:34:07PM +0200, Kevin Van de Velde wrote: [concerning documentation of the Spring-based configuration feature] 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, I also would appreciate this. 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. I can proofread it. Just ask. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu 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 Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Configuring a new module via Spring
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.
*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.
*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.
If you have any further questions about the services feel free to email me.
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 23 August 2011 22:08, Mark H. Wood mw...@iupui.edu wrote:
Double-checking my understanding of DSRV-13 and DSRV-17 here: if I
want to have Spring configure a module that doesn't currently do that,
I need to:
o invent a unique module name (MODULE), such as stats for
dspace-stats;
o implement SpringLoader somewhere in the module, returning a path to
${dspace.dir}/config/spring/MODULE/;
o add that implementation's fully-qualified class name to dspace.cfg as
springloader.modules.N;
o make sure that the configuration file winds up in
[DSpace-source]/dspace/target/dspace-VERSION-build/config/spring/MODULE.
Correct?
It looks like, right now, all of these config.s need to be in
[DSpace-source]/dspace/config/spring/MODULE to be assembled into the
aggregated target, yes?
I could not find any mention of Spring in the DSDOC configuration page.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are
smart.
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
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
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] Configuring a new module via Spring
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 mw...@iupui.edu
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
Re: [Dspace-devel] Configuring a new module via Spring
The dspace config property is entirly optional so it is possible to just
have a configuration in the resources.
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 15:58, Mark Diggory mdigg...@atmire.com wrote:
is the dspace config property required in the second case? or is it
optional and the config is loaded into all configurations?
On Wednesday, August 24, 2011, Kevin Van de Velde ke...@mire.be 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.
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.
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.
If you have any further questions about the services feel free to email
me.
Kind regards,
Kevin Van de Velde
@mire
Esperantolaan 4 - 3001 Heverlee - Belgium
2888 Loker Avenue East, Suite 305 - Carlsbad, CA 92010 - USA
atmire.com http://atmire.com/ - Institutional Repository Solutions
On 23 August 2011 22:08, Mark H. Wood mw...@iupui.edu wrote:
Double-checking my understanding of DSRV-13 and DSRV-17 here: if I
want to have Spring configure a module that doesn't currently do that,
I need to:
o invent a unique module name (MODULE), such as stats for
dspace-stats;
o implement SpringLoader somewhere in the module, returning a path to
${dspace.dir}/config/spring/MODULE/;
o add that implementation's fully-qualified class name to dspace.cfg as
springloader.modules.N;
o make sure that the configuration file winds up in
[DSpace-source]/dspace/target/dspace-VERSION-build/config/spring/MODULE.
Correct?
It looks like, right now, all of these config.s need to be in
[DSpace-source]/dspace/config/spring/MODULE to be assembled into the
aggregated target, yes?
I could not find any mention of Spring in the DSDOC configuration page.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are
smart.
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
https://lists.sourceforge.net/lists/listinfo/dspace-devel
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
--
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
Dspace-devel@lists.sourceforge.net
Re: [Dspace-devel] Configuring a new module via Spring
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 mw...@iupui.edu
mailto:mw...@iupui.edu 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);
Re: [Dspace-devel] Configuring a new module via Spring
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 tdono...@duraspace.org 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 mw...@iupui.edu
mailto:mw...@iupui.edu 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
Re: [Dspace-devel] Configuring a new module via Spring
On Wed, Aug 24, 2011 at 06:34:07PM +0200, Kevin Van de Velde wrote: [concerning documentation of the Spring-based configuration feature] 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, I also would appreciate this. 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. I can proofread it. Just ask. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpwyFFFgoCAE.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 Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
[Dspace-devel] Configuring a new module via Spring
Double-checking my understanding of DSRV-13 and DSRV-17 here: if I
want to have Spring configure a module that doesn't currently do that,
I need to:
o invent a unique module name (MODULE), such as stats for dspace-stats;
o implement SpringLoader somewhere in the module, returning a path to
${dspace.dir}/config/spring/MODULE/;
o add that implementation's fully-qualified class name to dspace.cfg as
springloader.modules.N;
o make sure that the configuration file winds up in
[DSpace-source]/dspace/target/dspace-VERSION-build/config/spring/MODULE.
Correct?
It looks like, right now, all of these config.s need to be in
[DSpace-source]/dspace/config/spring/MODULE to be assembled into the
aggregated target, yes?
I could not find any mention of Spring in the DSDOC configuration page.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.
pgpNDOh0ha7vM.pgp
Description: PGP signature
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
