Chris, you should not need to set the service explictily. If you
simlpy have a setSomeSerivce(SomeServiceInterface object) method
Hivemind will take care of the rest, thats why its call 'auto'wiring.
You dont have to do anything. Try taking out the set-service
attributes and see what happens.
Like I said, just make sure you have a set method with each service
interface that you want it to use. The name of the method doesn't
matter.
-Nick
On 6/10/05, Chris Conrad <[EMAIL PROTECTED]> wrote:
> The problem I'm having is I don't even get a "line precise" error
> message. HiveMind just acts as though those methods don't exist, no
> errors, no warnings. But then I get a NullPointerException at
> runtime because the sessionManager and sessionRepository are never set.
>
> If anyone has any ideas of what might be wrong or pointers on how to
> debug the problem on my own, I'd be extremely grateful.
>
> Thanks,
> --Chris
>
> On Jun 9, 2005, at 5:25 AM, Glen Stampoultzis wrote:
>
> > 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: hivemind-user-
> >>> [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: hivemind-user-
> >> [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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
