Hi Mark,

I've not got an original thought in my head. I was just intending to start implementing bits of the work outlined by yourself, James Rutherford, and others. My intention is to do it in a piecemeal fashion seeking approval along the way so that if I get run over by a bus at least something will have been committed. I'm not planning on having lots of local uncommitted code so if others are interested it should be easy for them to join in.

For a start I wanted to establish a mechanism for handling the DAO config. I agree entirely that ideally the DAOs and other related code would be best placed in their own Maven projects, however it looks like the org.dspace.storage.rdbms package depends on dspace-api so I would end up with a circular dependency. I still think it would be a good aim for 3.0 to unpick these dependencies, but so as not to get bogged down I have stuck a cheap and nasty workaround here...

https://github.com/robintaylor/DSpace/commit/e94623acff02ff2f4b5ad586865ee3de10dd120d

Could you have a quick look and tell me if its daft ? Basically I have just stuck separate DAO config files in a directory in dspace-api and selected one depending on which database has been chosen.

The next thing would be to refactor the existing ItemDAO classes to be Springified, and add skeletal DAO classes for the other Model objects. There is some obvious code that could be simply moved from the Model objects into the DAO's but I'm aware that I'll run into complications quite quickly. At that point I will be looking for guidance as I would be moving into more pure design territory - Repository Pattern, SOA etc.

Things to do along the way - Implement the LegacyContextService as specified by yourself elsewhere, replace ConfigurationManager with ConfigurationService to remove one of the dependencies on dspace-api, etc etc

Unfortunately I'm on holiday next week but would hope to bash on when I return. I'm very happy to be guided with the one caveat that I would very much like to break the work down into small committable pieces.

Cheers, Robin.








On 06/04/12 22:16, Mark Diggory wrote:
Thanks Robin,

Any chance you could show us a little bit concerning your plan for the DAO work that you are doing? It might be good to get the feedback at the design phase of your work

Regards,
Mark

On Thu, Apr 5, 2012 at 7:18 AM, Robin Taylor <robin.tay...@ed.ac.uk <mailto:robin.tay...@ed.ac.uk>> wrote:

    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.




--
@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.
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to