Re: [Skunkworks] Spring DI and OOP inheritance:

Another solution: You don't have to make the setters and getters private (i.e. setCustomerDao, getCustomer because the references they return are also private). Therefore the s/getters would be either protected or public allowing you to do the spring wiring as follows: <bean id="customerServiceImpl" class="ke.co.x.x.CustomerServiceImpl"> <property name="customerDao" ref="customerDao"/> </bean> --- On Mon, 5/25/09, Duggan Kim <mdkimani@gmail.com> wrote: From: Duggan Kim <mdkimani@gmail.com> Subject: Re: [Skunkworks] Spring DI and OOP inheritance: To: "Skunkworks forum" <skunkworks@lists.my.co.ke> Date: Monday, May 25, 2009, 10:09 AM Found Solution: The problem with my code is that the subclasses did not have a constructor making a call to super(). Turns out this was necessary to init the superclass, although it is usually left out in spring applications: public subclass(){ super(); } On Mon, May 25, 2009 at 10:02 AM, Frankline Chitwa <frank.chitwa@gmail.com> wrote: Hi, did you test if setCustoHi gmerDAO() actually sets your customerDao first before trying to get it? On Mon, May 25, 2009 at 1:52 AM, Ashok Hariharan <ashok@parliaments.info> wrote: On Sun, May 24, 2009 at 3:17 PM, Duggan Kim <mdkimani@gmail.com> wrote:
Every other dependency is taken care of in Spring's applicationContext.xml config file in a similar manner.
When tested using JUnit or on the browser, a NullPointerException is thrown at (2). The DAO defined in the superclass is null in the subclass. This raises the question whether Spring's DI supports normal Java class inheritance and if it does, is there any special config required for this?
I am not so familiar with spring as such... but dependency injection frameworks require interfaces for both implementing classes *and* properties .... is the customerDAO object based on an interface ? ashok _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Skunkworks announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science - http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi - http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Skunkworks announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science - http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi - http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general -----Inline Attachment Follows----- _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks Other services @ http://my.co.ke Other lists ------------- Skunkworks announce: http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks-announce Science - http://lists.my.co.ke/cgi-bin/mailman/listinfo/science kazi - http://lists.my.co.ke/cgi-bin/mailman/admin/kazi/general

On Mon, May 25, 2009 at 11:24 AM, wesley kiriinya <kiriinya2000@yahoo.com> wrote:
Another solution:
You don't have to make the setters and getters private (i.e. setCustomerDao, getCustomer because the references they return are also private). Therefore the s/getters would be either protected or public allowing you to do the spring wiring as follows:
<bean id="customerServiceImpl" class="ke.co.x.x.CustomerServiceImpl"> <property name="customerDao" ref="customerDao"/> </bean>
You would think that is the logical way.... but with direct injection frameworks like Spring method encapsulation is ignored ... you can have a private setter method which is settable by an external object ! it uses the reflection api to call setter / getter methods irrespective of encapsulation rules
participants (2)
-
Ashok Hariharan
-
wesley kiriinya