Copying in the list on a discussion between Mark Diggory and myself
since it may well be of interest to others.
Mark - thanks, that's a great explanation.
Cheers, Robin.
On 05/04/12 14:41, Mark Diggory wrote:
Ah... now we're talking.
Can we bring this thread into the list, because this is the topic of
how to implement your services correctly.
1.) For the database usecase, I don't see us wanting more than one DAO
in place a time, correct. In this case we need to have the
build/enduser choose which implemenetion should be in-force. I would
recommend this is done by having separate spring config files for each
and choosing between which is configured during the maven build, same
as the manner in which we choose our database driver via the maven build.
In the async release approach, these would have been completely
separate maven projects, choosing the to build and include the
dependency for the oracle one when -Ddb.name=/oracle/
/
/
2.) For the dspace.cfg plugins, multiple named implementations
requires us to use "autowiring" to complete. In this case we have two
approaches to choose from. Take a look over this example for
identifier services.
http://code.google.com/p/dryad/source/browse/trunk/dryad/dspace/modules/identifier-services/src/main/resources/spring/spring-dspace-core-services.xml?r=4766
http://code.google.com/p/dryad/source/browse/trunk/dryad/dspace/modules/api/src/main/resources/spring/spring-dspace-core-services.xml?r=4766
if these were combined into one we would have something like...
<beansxmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<beanclass="org.dspace.identifier.IdentifierServiceImpl"id="org.dspace.identifier.IdentifierServiceImpl"autowire="byType"/>
<beanclass="org.dspace.identifier.HandleIdentifierService"
autowire="byType"/>
<beanclass="org.dspace.identifier.DOIIdentifierService"autowire="byType"/>
</beans>
And you can see how efficient the coding of this can be in the
IdentifierServiceImpl
http://code.google.com/p/dryad/source/browse/trunk/dryad/dspace/modules/identifier-services/src/main/java/org/dspace/identifier/IdentifierServiceImpl.java?r=4766
Here we've done two things.
a.) We have a Bean property that is a list of IdentifierProviders
publicvoidsetProviders(List<DSpaceIdentifierService>providers)
b.) We've chosen to define one (HandleProvider) as default
publicvoidsetHandleService(HandleIdentifierServicehandleService)
Both these get autowired by spring and we write no code for
such activities. You can use the autowire attribute in the xml file,
or you can use annotations on the classes themselves to provide this
wiring.
Mark
On Thu, Apr 5, 2012 at 1:31 AM, Robin Taylor <robin.tay...@ed.ac.uk
<mailto:robin.tay...@ed.ac.uk>> wrote:
Hi Mark,
Sorry, I answered in a hurry last night without thinking properly.
I still have a wee problem. If I use the interface as the bean id
then presumably I can only have one class associated with that
id/interface in the spring config. That causes a problem for me as
I will want to have multiple classes implementing the same
interface ie...
PostgresCollectionDAO, OracleCollectionDAO, etc all implementing
CollectionDAO
In fact I think the same problem would arise for many of the
plugins listed in dspace.cfg ?
Cheers, Robin.
On 04/04/12 17:50, Mark Diggory wrote:
Robin, its interface centric. you will want to create an
interface for your DAO class, it is this interface that is cast
to and utilized by the code using your api.
CollectionDAO collectionDAO = new
DSpace().getSingletonService(CollectionDAO.class);
<bean id="org.dspace.content.dao.CollectionDAO"
class="org.dspace.content.dao.PostgresCollectionDAO" />
On Wed, Apr 4, 2012 at 2:21 AM, Robin Taylor
<robin.tay...@ed.ac.uk <mailto:robin.tay...@ed.ac.uk>> wrote:
Hi Mark,
Can I ask a daft Spring question ? Looking at
org.dspace.utils.DSpace I was surprised to find no method
that would be the equivalent of the Spring ApplicationContext
getBean(String) method. I had to code...
CollectionDAO collectionDAO = new
DSpace().getSingletonService(PostgresCollectionDAO.class);
with a Spring config of...
<bean id="org.dspace.content.dao.PostgresCollectionDAO"
class="org.dspace.content.dao.PostgresCollectionDAO" />
Which effectively hardwires a particular implementation of
CollectionDAO into the code. Was this a deliberate design
choice or did it just fulfil the needs at the time of the
DSpace 2.0 work ?
I am a bit of a Spring/Services novice so apologies if this
is a daft question.
Cheers, Robin.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
@mire Inc.
*Mark Diggory *(Schedule a Meeting
<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg>)
/2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
/Esperantolaan 4, Heverlee 3001, Belgium/
http://www.atmire.com <http://www.atmire.com/>
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
@mire Inc.
*Mark Diggory *(Schedule a Meeting
<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg>)
/2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
/Esperantolaan 4, Heverlee 3001, Belgium/
http://www.atmire.com <http://www.atmire.com/>
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel