You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Knut Wannheden <kn...@gmail.com> on 2004/11/01 09:10:57 UTC
Re: Overriding services
For the particular case of testing the contributions you could of
course also use the Registry's getConfiguration() method and set the
returned List manually in the test.
But I see where you're getting at. This is an area where I think it
could be interesting if the Registry exposed an additional method to
"autowire" an object. E.g.
registry.injectServices(mockService);
But also a facility for overriding services as you describe it sounds
interesting.
--knut
On Sun, 31 Oct 2004 18:11:58 +0700, Jean-Francois Poilpret
<jf...@hcm.vnn.vn> wrote:
> Hello Knut,
>
> Yes of course I did that for my _true_ unit tests.
>
> But I wanted to go further with partial _integration_ tests within HiveMind
> (in particular I wanted to check that my contribution rules worked OK and I
> got the List of the right objects, for that, obviously, I need to integrate
> with HiveMind). However, I would like to avoid _full_ integration tests for
> the moment (I mean, let Hibernate aside in my partial integration tests).
>
> So the reason of my question.
>
> Cheers
>
>
>
>
> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Sunday, October 31, 2004 4:07 PM
> To: hivemind-user@jakarta.apache.org
> Subject: Re: Overriding services
>
> Jean-Francois,
>
> I'm not sure I quite understand your problem. But can't you just
> write your test for service B without using HiveMind? E.g.
>
> A mockA = new AMockImp();
> B b = new BImpl();
> b.setA(mockA);
>
> Also note the services hivemind.lib.DefaultImplementationFactory and
> hivemind.lib.PlaceholderFactory.
>
> --knut
>
> On Sun, 31 Oct 2004 13:45:24 +0700, Jean-Francois Poilpret
> <jf...@hcm.vnn.vn> wrote:
> > Hi,
> >
> > Yesterday I was stuck with the following problem:
> > - I have a service-point A that is used internally by some other
> > service-point B
> > - service-point A implementation depends on some "heavy" processing (it
> uses
> > Hibernate to create a SessionFactory based on a configuration file and
> some
> > additional properties)
> >
> > I had the need to do some "partial integration test" of service B inside
> > HiveMind, but I did not want to use real Hibernate stuff (this would make
> > the test too long and uselessly complicated).
> >
> > Originally, in the module where services A and B are defined, I put the
> > implementation declaration for A directly in service-point declaration.
> > But then I could not override A implementation for testing purposes (for
> > testing I needed to mock service A implementation).
> >
> > So I started to check how I could "override" service A implementation for
> my
> > tests.
> >
> > On Hibernate web site, there is a page on overriding services, this way is
> > probably a good way to follow for a service-point that is _intended_ to be
> > overridden by the application, but I found it a bit heavy just for testing
> > purposes.
> >
> > Finally, I could not come out with a _good_ solution to my problem and I
> > gave up to what I considered the best solution I had on-hand for the job
> > (best but not really good actually):
> > - in module descriptor for services A & B, I removed the "invoke-factory"
> > from service-point A, just keeping the service-point declaration.
> > - in my tests, I had a descriptor that includes the implementation for
> > service A (in this case the implementation points to a class that is
> > directly defined in my test case, and that delegates all method calls to a
> > Mock object)
> > - unfortunately (this is where the solution is not really good), in the
> > final application descriptor module, I (and other application developers
> > too) _have_ to include the implementation for service A, although it is
> > supposed to be always the same.
> >
> > I think that, probably (as suggested in the web page regarding override of
> > services), it would be interesting to have a HiveMind-defined way to do
> > that, ie:
> > - defining a default implementation for a service-point
> > - having the built-in possibility to override it in another module
> > In the situation of my test case, it would have the advantage of being
> > unobtrusive to the end-application developer.
> >
> > Should this be an enhancement request?
> > Or have other developers in the list faced the same problem and could come
> > out with a different solution?
> >
> > Cheers
> >
> > ---------------------------------------------------------------------
> > 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: Overriding services
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
On Mon, 1 Nov 2004 09:10:57 +0100, Knut Wannheden
<kn...@gmail.com> wrote:
> <...>
> But I see where you're getting at. This is an area where I think it
> could be interesting if the Registry exposed an additional method to
> "autowire" an object. E.g.
>
> registry.injectServices(mockService);
I can definately see the use of this - especially if it can also deal with
static methods as well ... Realise that this is probably not the best of
good code practises, but I am currently dealing with Xalan extensions and
haven't figured out how to provide it with a object factory for the
extension handlers just yet (don't think it is even possible) ...
So, have resorted to pre-initializing the service fields of the class
(using static methods) for now, but would be nice if Hivemind helped here
too ...
Johan
> But also a facility for overriding services as you describe it sounds
> interesting.
>
> --knut
>
> On Sun, 31 Oct 2004 18:11:58 +0700, Jean-Francois Poilpret
> <jf...@hcm.vnn.vn> wrote:
>> Hello Knut,
>>
>> Yes of course I did that for my _true_ unit tests.
>>
>> But I wanted to go further with partial _integration_ tests within
>> HiveMind
>> (in particular I wanted to check that my contribution rules worked OK
>> and I
>> got the List of the right objects, for that, obviously, I need to
>> integrate
>> with HiveMind). However, I would like to avoid _full_ integration tests
>> for
>> the moment (I mean, let Hibernate aside in my partial integration
>> tests).
>>
>> So the reason of my question.
>>
>> Cheers
>>
>>
>>
>>
>> -----Original Message-----
>> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
>> Sent: Sunday, October 31, 2004 4:07 PM
>> To: hivemind-user@jakarta.apache.org
>> Subject: Re: Overriding services
>>
>> Jean-Francois,
>>
>> I'm not sure I quite understand your problem. But can't you just
>> write your test for service B without using HiveMind? E.g.
>>
>> A mockA = new AMockImp();
>> B b = new BImpl();
>> b.setA(mockA);
>>
>> Also note the services hivemind.lib.DefaultImplementationFactory and
>> hivemind.lib.PlaceholderFactory.
>>
>> --knut
>>
>> On Sun, 31 Oct 2004 13:45:24 +0700, Jean-Francois Poilpret
>> <jf...@hcm.vnn.vn> wrote:
>> > Hi,
>> >
>> > Yesterday I was stuck with the following problem:
>> > - I have a service-point A that is used internally by some other
>> > service-point B
>> > - service-point A implementation depends on some "heavy" processing
>> (it
>> uses
>> > Hibernate to create a SessionFactory based on a configuration file and
>> some
>> > additional properties)
>> >
>> > I had the need to do some "partial integration test" of service B
>> inside
>> > HiveMind, but I did not want to use real Hibernate stuff (this would
>> make
>> > the test too long and uselessly complicated).
>> >
>> > Originally, in the module where services A and B are defined, I put
>> the
>> > implementation declaration for A directly in service-point
>> declaration.
>> > But then I could not override A implementation for testing purposes
>> (for
>> > testing I needed to mock service A implementation).
>> >
>> > So I started to check how I could "override" service A implementation
>> for
>> my
>> > tests.
>> >
>> > On Hibernate web site, there is a page on overriding services, this
>> way is
>> > probably a good way to follow for a service-point that is _intended_
>> to be
>> > overridden by the application, but I found it a bit heavy just for
>> testing
>> > purposes.
>> >
>> > Finally, I could not come out with a _good_ solution to my problem
>> and I
>> > gave up to what I considered the best solution I had on-hand for the
>> job
>> > (best but not really good actually):
>> > - in module descriptor for services A & B, I removed the
>> "invoke-factory"
>> > from service-point A, just keeping the service-point declaration.
>> > - in my tests, I had a descriptor that includes the implementation for
>> > service A (in this case the implementation points to a class that is
>> > directly defined in my test case, and that delegates all method calls
>> to a
>> > Mock object)
>> > - unfortunately (this is where the solution is not really good), in
>> the
>> > final application descriptor module, I (and other application
>> developers
>> > too) _have_ to include the implementation for service A, although it
>> is
>> > supposed to be always the same.
>> >
>> > I think that, probably (as suggested in the web page regarding
>> override of
>> > services), it would be interesting to have a HiveMind-defined way to
>> do
>> > that, ie:
>> > - defining a default implementation for a service-point
>> > - having the built-in possibility to override it in another module
>> > In the situation of my test case, it would have the advantage of being
>> > unobtrusive to the end-application developer.
>> >
>> > Should this be an enhancement request?
>> > Or have other developers in the list faced the same problem and could
>> come
>> > out with a different solution?
>> >
>> > Cheers
>> >
>> > ---------------------------------------------------------------------
>> > 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
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org