Re: Debugging autowiring (Solved)

[Chris Conrad <cc...@vasoftware.com>]

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 <cc...@vasoftware.com> 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- 
>>>> unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: hivemind-user- 
>>>> help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: hivemind-user- 
>>> help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-user- 
>> help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org

Re: Debugging autowiring (Solved)

[Nick Stuart <ba...@gmail.com>]

Glad you figured it out. And I think I've been bitten by this one as well.

-Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org