Replying to myself again because I solved my auto-wiring problem. No big surprise for me, it was my fault. I spent some time this weekend going over the BuilderFactory and how it instantiates services. It's not as complicated as it looked when I first went through it. I noticed that the service interfaces for the services which weren't getting auto-wired were listed as impl.SessionManager and impl.SessionRepository. Of course, that can't be correct, so I took a look at the documentation and there it was ... the interface attribute of the service-point element is prefixed with the module's package if and only if it does not contain a period. That makes sense to me because, unlike the implementations, the interface is likely to be from some completely unrelated package (like java.lang.Runnable).

So, idea for a small change to that is, how about BuilderFactory prefixes the module's package if there is no period within the interface attribute *or* if the interface attribute starts with a period. That way I could say interface=".impl.SessionMananger". Packages can't start with a period (to the best of my knowledge at least), so this might be a good compromise.

Thoughts,
--Chris

On Jun 10, 2005, at 8:35 PM, Chris Conrad 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: hivemind-user- [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: 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]

Reply via email to