Robin,
Think of Spring as operating in two phases (1) initialization and (2)
runtime.
In the initialization phase, all configuration of the desired Beans
happens. Until this configuration (either through direct wiring or
autowiring occurs, the beans that are referenced may or may not exist yet
due to the order of instantiation. We may be able to enhance this in the
future so that we have separate levels of initialization (core system and
addon) that would allow us to not have to wait for instantiation of the
whole application context to happen in one phase.
The solution in this case is to wait until the initialization phase is
complete. There are annotations and/or interfaces you may use to create
"initialization behavior" after all the properties have been set (either by
setters or constructors).
Heres a good thread on the options available:
http://stackoverflow.com/questions/1088550/spring-how-to-call-a-method-after-bean-initialization-is-complete
1.) @PostConstruct javax annotation on a method that should be executed
after the initialization is complete.
2.) init-method attribute on bean in configuration xml file
<bean id="myBean" class="..." init-method="init"/>
3.) Use Spring InitializingBean interface to implement activities that
should happen after all the setters are complete.
http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/beans/factory/InitializingBean.html
Cheers,
Mark
On Fri, Jun 1, 2012 at 6:08 AM, Robin Taylor <[email protected]> wrote:
> Hi Mark,
>
> Thanks for the guidance, that's a neat solution. I'm just having one wee
> problem at the moment. When I try and select the appropriate DAO (point 4
> below) I am getting an Exception. If you have a wee minute could you take a
> look at
> https://github.com/robintaylor/DSpace/commit/6d3dbd24c3e2f3b632d59cf36ec2f71b52864c34#diff-5,
> I think the problem occurs when I try and access the
> ConfigurationService. If I comment out that line and just use a hardcoded
> value of 'postgres' it works fine. Would you expect the
> ConfigurationService to be available at that point ? Don't worry if you
> don't have time to look at this, I'll investigate myself but I just thought
> I would ask in case you knew the answer off the top of your head.
>
> Cheers, Robin.
>
> PS. What I posted to GitHub is very much a work in progress so please turn
> a blind eye to the numerous "rough edges" :)
>
>
>
>
>
>
> On 23/05/12 06:52, Mark Diggory wrote:
>
> Robin, I've been meaning to spend some time getting back to you on this
> topic.
>
> If we were to just use spring and abandon the dspace configuration
> approach, we could implement the selection of the appropriate DAO as a
> choice between spring xml files placed into dspace/config/spring/... Since
> we want to keep both dao around and choose the appropriate one, we could
> use the property placeholder config to lookup the appropriate classname of
> the bean to wire into the manager or we can load them both into the manager
> using autowiring using something like the following...
>
> 1. Create a CollectionService bean that will provide a generic
> non-vendor specific interface to interact with your storage (to hold common
> CRUD). Use it's classname as the identifier to look it up via the service
> manager by static methods in Collection.
>
> 2. Add a setDAOProviders(List<CollectionDAO>) method to the above
> service.
>
> 3. In the spring config, use autowire="byType" to set collection the
> various CollectionDAO Implementations in the Service.
>
> 4. Create an id property with getter on each of the vendor dao that
> designates the capitalizedDbname associated with the appropriate vendor
> dao. Add some code to (2) to pick the appropriate DAO out of the set and
> set it as the selected DAO to be used in the service.
>
> The actual selection will be a few lines of code, and then the dao can
> have any package name, com.blaa, org.foo. Do not make the same mistake as
> in the curator tools, you only need to implement CollectionDAO and provide
> some id in the bean to map to the db.name config in the service manager.
>
> Mark
>
> On Friday, May 18, 2012, Robin Taylor wrote:
>
>> Hi Mark (and anyone else that may be interested),
>>
>> I've posted an alternative DAO demo implementation at
>> https://github.com/robintaylor/DSpace/tree/DS-1172 that only requires
>> one Spring config file and keeps everything within dspace-api. Its a bit
>> messy as I've hardcoded a package name into the code...
>>
>> String classname = "org.dspace.content.dao." + capitalisedDbname +
>> "CollectionDAO";
>>
>> I would be grateful for any criticism. The problem I generally run up
>> against is that there is no method...
>>
>> DSpace().getSingletonService(String id);
>>
>> ...that would wrap the Spring method...
>>
>> getBean(String id)
>>
>> Cheers, Robin.
>>
>>
>>
>>
>> On 11/05/12 16:34, Mark Diggory wrote:
>>
>> Robin can you post a link to the two classes you have referenced below, I
>> want to really understand what the significant differences are that
>> require completely different code.
>>
>> Even in your example, the the oracle vs Postgres DAO can exist in the
>> spring config together and be lazy loaded. If you want to have the runtime
>> code select between them in the manner your showing, put them in a set or a
>> map and pick them out of that inside a parent DAO "container".
>>
>> I say this because in JPA, an EntityManager is responsible for
>> marshalling/unmarshalling the object from the rdbms, so it encapsulates the
>> differences between the vendors not at the level of your model classes, but
>> lower down in the JPA implementation itself. And in Spring JDBCTemplates
>> the SQL differences are externalized into the templates.
>>
>> The providers are then for separate persistence frameworks (Hibernate,
>> Spring Templates, JDO, JPA) not specifically JDBC vendor.
>>
>> In our case, if we were to use spring JDBC templates, we could probibly
>> still encapsulate the oracle/Postgres differences in the template class,
>> but the JDBC driver swapping could still be controlled in the manner
>> currently defined.
>>
>>
>> http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html
>>
>> I think it's important to first move the code inside DSpace-API and
>> manually configure in config/spring, we can come around after showing the
>> separation functionally works to discuss using addons or not for selection
>> of the provider.
>>
>> Mark
>>
>> On Friday, May 11, 2012, Robin Taylor wrote:
>>
>>> Hi Sands,
>>>
>>> My initial plan was just to have the DAOs within dspace-api, possibly in
>>> separate packages, but I was unable to accomplish it with our Spring based
>>> ServiceManager (very probably due to a lack of understanding on my part).
>>> In classic Spring you might have a configuration of ...
>>>
>>> <bean id="postgresCollectionDAO"
>>> class="org.dspace.content.dao.PostgresCollectionDAO" />
>>> <bean id="oracleCollectionDAO"
>>> class="org.dspace.content.dao.OracleCollectionDAO" />
>>>
>>> So you would form your id by something like...
>>>
>>> String id = dbname + "CollectionDAO"
>>>
>>> and use Spring to instantiate the appropriate class for you. But our
>>> ServiceManager doesn't appear to allow that. It seemed to me that the only
>>> thing available to me was...
>>>
>>> DSpace.getSingletonService(java.lang.Class<T> type)
>>>
>>> Which would have meant having to have Spring config that looked like...
>>>
>>> <bean id="org.dspace.content.dao.CollectionDAO"
>>> class="org.dspace.content.dao.PostgresCollectionDAO" />
>>> <bean id="org.dspace.content.dao.CollectionDAO"
>>> class="org.dspace.content.dao.OracleCollectionDAO" />
>>>
>>> But that is not permitted and wouldn't work anyway. To get round this
>>> you need to create separate modules for Oracle and Postgres each with its
>>> own Spring config file, that way you can reuse the same 'id's in each file,
>>> assuming you only include one of the files in the final build.
>>>
>>> At first this seemed an unnecessary hassle to me to have to create
>>> separate modules when my aim was just to get some DAOs in, but I can see
>>> some merit. It would allow someone to come along and give us a separate
>>> module for Mysql, or even just give us a jar, and it could be plugged in
>>> without any need for a committer to apply the changes to dspace-api. Taking
>>> this argument further, suppose we want to build in support for non-JDBC
>>> database access, or even other forms of storage, would we push everything
>>> into dspace-api ? Or should the storage related code be hived off into its
>>> own module(s) ?
>>>
>>> As I say my knowledge of our ServiceManager is rudimentary so I am happy
>>> to be corrected.
>>>
>>> Cheers, Robin.
>>>
>>>
>>>
>>>
>>> On 11/05/12 04:54, Sands Alden Fish wrote:
>>>
>>> Hi Robin,
>>>
>>> I see no reason not to move forward with the work in general. (I am
>>> of course just one committer, and could quite possibly be looking over a
>>> concern here.)
>>>
>>> As far as creating separate Maven modules though, this *feels* kind of
>>> heavy-handed and complex for the benefit of building separate DAO packages
>>> separately. Is it really worth the additional complexity, instead of just
>>> building all db support into the final build by default? Happy to hear an
>>> argument for it. This is just my gut reaction.
>>>
>>>
>>> Cheers,
>>>
>>> -Sands
>>>
>>>
>>>
>>> On May 10, 2012, at 9:24 AM, Robin Taylor wrote:
>>>
>>> Hi all,
>>>
>>> I just wanted to run something by you to check that I am not misbehaving.
>>>
>>> I have in my mind to try and implement some form of DAO's for 3.0, but
>>> its very much a hobby project for me at this stage so I haven't made too
>>> much noise about it other than seeking guidance from Mark D. As work
>>> progresses the aim would be to create separate maven modules for the
>>> DAOs and for the org.dspace.storage.rdbms package on which they would
>>> depend. The reason for having separate modules for the various DAO
>>> implementation (Oracle, Postgres, etc) would be to make use of the
>>> existing Maven profiles activated by the choice of database in order
>>> that the Maven build would add the appropriate dependency. As I write I
>>> realise I need to write this up in more detail on the wiki.
>>>
>>> As preparatory work I need to remove dependencies on dspace-api from
>>> some of the classes in org.dspace.storage.rdbms. Its just refactoring
>>> work with no new functionality eg. replacing references to
>>> ConfigurationManager with ConfigurationService, so I've just been
>>> raising Jira records for each piece of work with an associated pull
>>> request and leaving them for a week to allow comment (see DS-1156 and
>>> DS-1160). Assuming there are no objections I've just been merging the
>>> changes into master (I'm getting the hang of this Git lingo). If/when I
>>> reach the point of doing something more contentious, such as moving the
>>> org.dspace.storage.rdbms package into its own module, I would certainly
>>> be seeking approval from the committers/developers in the normal
>>> fashion. If approval wasn't forthcoming nothing would be lost since the
>>> refactorings I'm doing at the moment would probably be considered good
>>> things to do in their own right.
>>>
>>> Any objections if I continue in this fashion ?
>>>
>>> Thanks, Robin.
>>>
>>>
>>> --
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions
>>> will include endpoint security, mobile security and the latest in
>>> malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Dspace-commit mailing list
>>> [email protected]
>>>
>>>
>>
>> --
>> [image: @mire Inc.]
>> *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
>> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
>> *Esperantolaan 4, Heverlee 3001, Belgium*
>> http://www.atmire.com
>>
>>
>>
>>
>
> --
> [image: @mire Inc.]
> *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
>
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
