I also find autowiring tough to debug. The error messages are line
precise but not very helpful.
On 6/9/05, Chris Conrad <[EMAIL PROTECTED]> wrote:
> So, it appears that my description of the problem from last night is
> no longer correct. Autowiring now seems to be not working correctly
> for multiple services in one of my modules. The module descriptor
> looks like this:
>
> <module id="security" version="0.0.1" package="xxx.security">
>
> <service-point id="AuthenticationService"
> interface="AuthenticationService">
> <invoke-factory>
> <construct class="impl.AuthenticationServiceImpl">
> <set property="sessionTimeout" value="$
> {sessionTimeout}"/>
> <set-service property="sessionRepository" service-
> id="SessionRepository"/>
> <set-service property="sessionManager" service-
> id="SessionManager"/>
> </construct>
> </invoke-factory>
> <interceptor service-id="xxx.TransactionInterceptor"/>
> </service-point>
>
> <service-point id="SessionCleanupTask"
> interface="java.lang.Runnable" visibility="private">
> <invoke-factory>
> <construct class="impl.SessionCleanupTask">
> <set property="sessionTimeout" value="$
> {sessionTimeout}"/>
> <set-service property="sessionRepository" service-
> id="SessionRepository"/>
> </construct>
> </invoke-factory>
> <interceptor service-id="xxx.TransactionInterceptor"/>
> </service-point>
>
> <service-point id="SessionManager"
> interface="impl.SessionManager" visibility="private">
> <invoke-factory model="threaded">
> <construct class="impl.SessionManagerImpl"/>
> </invoke-factory>
> </service-point>
>
> <service-point id="SessionRepository"
> interface="impl.SessionRepository" visibility="private">
> <invoke-factory>
> <construct class="impl.HibernateSessionRepository"/>
> </invoke-factory>
> </service-point>
> </module>
>
>
> If you notice, both the AuthenticationService and SessionCleanupTask
> have set-service elements. Those two services are not being
> autowired correctly, I need to use the set-service element to get the
> services they depend on injected. The Java code seems to meet the
> requirements for BuilderFactory to do the autowiring but you can
> check for yourself:
>
> public void setSessionManager(SessionManager sessionManager) {
> this.sessionManager = sessionManager;
> }
>
> public void setSessionRepository(SessionRepository
> sessionRepository) {
> this.sessionRepository = sessionRepository;
> }
>
> setSessionRepository is identical in both of the services that aren't
> getting autowired. I know this for a fact since I just cut and
> pasted the code from one to the other.
>
> Am I don't something wrong here? If not, how can I figure out why
> HiveMind isn't autowiring my services? My AuthenticationService also
> depends on two other services not defined in this module and those
> two services are being correctly autowired. And both of the two
> troublesome services are getting their Log properties autowired
> correctly as well. This is doubly bothersome to me since last night
> the AuthenticationService was being autowired correctly. The only
> difference between last night and tonight is I added the reference to
> the SessionManager service.
>
> Thanks,
> --Chris
>
> On Jun 8, 2005, at 2:13 AM, Chris Conrad wrote:
>
> > Hello,
> >
> > I have two services in the same module and both of them need to
> > have a third service (also in that same module) injected. Both of
> > the services are defined exactly the same and the setter is
> > identical in both (I cut and pasted the code to be sure of that).
> > But when I run my application, only one of the two services is
> > correctly autowired. I've been trying to debug this issue myself,
> > but have found the code which performs the autowiring to be
> > difficult to trace through and the debug logging doesn't really say
> > anything about what properties it found to be autowirable. Is
> > there a simple method for figuring out why HiveMind isn't
> > autowiring the one service correctly? I'm working around the issue
> > right now by using set-service in the construct tag for the service
> > being mis-wired, but I'd prefer to avoid the excess XML when it
> > shouldn't be necessary.
> >
> > Thanks,
> > --Chris
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
