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