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

Reply via email to