commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Lindquist <jo...@kawoo.co.uk>
Subject Re: [HiveMind] extend BuildFactory to use static fields/methods
Date Wed, 01 Oct 2003 12:57:19 GMT
I see - fair point ...  Trying to keep a (user defined) interface in synch 
with generated code is a usually a nightmare ...

Johan

On Wed, 1 Oct 2003 14:44:01 +0200, Knut Wannheden 
<knut.wannheden@paranor.ch> wrote:

> In my case I was simply trying to wrap a hivemind service around an 
> existing
> service (which is generated code), where accessing a static member is
> required. But I can of course also write a new interface and class to 
> wrap
> this.
>
> --knut
>
> "Johan Lindquist" <johan@kawoo.co.uk> wrote in message
> news:oprwc6bzhn5c7tcy@localhost...
>> I may have misunderstood this - but doesn't hivemind always return the
>> same instance when you ask for a service once it has created one (unless
>> it is a threaded service model, when you are worried about state anyway
>> and probably want different instances)?  If so, what is the need to 
>> have a
>> static instance?  I suppose I can see a use for it to share data between
>> threads, but the singleton service should suffice?
>>
>> Johan
>>
>> On Wed, 01 Oct 2003 13:52:58 +0200, Christian Essl
>> <christianessl@yahoo.de> wrote:
>>
>> > That's very good (and fast implemented). But do you realy have to do 
>> the
>> > double-check on the class. I mean the user sees anyway what class it 
>> is
>> > from the JavaDoc and HiveMind will always check that it fits the 
>> Service
>> > interface.
>> >
>> > Sure if the static field changes this ensures consistency, but on the
>> > other hand it would be also very convient to change all services
>> > referenced but just changing the static field without the need to go
>> > into the module.
>> >
>> >
>> > On Wed, 1 Oct 2003 12:40:12 +0200, Knut Wannheden
>> > <knut.wannheden@paranor.ch> wrote:
>> >
>> >> I have created a copy of the hivemind.BuilderFactory service which
>> >> allows me
>> >> to write:
>> >>
>> >> <invoke-factory service-id="my.BuilderFactory">
>> >> <construct class="foo.Bar" static-field="foo.Bar.INSTANCE"/>
>> >> </invoke-factory>
>> >>
>> >> given that I have something like:
>> >>
>> >> package foo;
>> >> public interface Bar {
>> >> static final INSTANCE = new BarImpl();
>> >> }
>> >>
>> >> The class attribute is used to check that the object specified by the
>> >> static-field is of a given type, which is an interface in this 
>> example.
>> >>
>> >> --knut
>> >>
>> >>> That's certainly a good idea.
>> >>>
>> >>> On Wed, 1 Oct 2003 07:50:42 +0200, Knut Wannheden
>> >>> <knut.wannheden@paranor.ch> wrote:
>> >>>
>> >>> > Hi,
>> >>> >
>> >>> > I was wondering whether it would make sense to extend the
>> >>> BuildFactory
>> >>> > service (or maybe add a new wervice) to also be able to construct
>> >> objects
>> >>> > by
>> >>> > returning the value of a classes static field or by calling a 
>> static
>> >>> > method
>> >>> > on a class. The former would obviously be simpler. E.g. (as a new
>> >>> > service):
>> >>> >
>> >>> > <invoke-factory service-id="hivemind.StaticBuilderFactory">
>> >>> > <construct class="foo.Bar" static-field="BAZ">
>> >>> > <set.../>
>> >>> > </construct>
>> >>> > </invoke-factory>
>> >>> >
>> >>> > --knut
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> >>> > For additional commands, e-mail: 
>> commons-dev-help@jakarta.apache.org
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> -- Using M2, Opera's revolutionary e-mail client:
>> >>> http://www.opera.com/m2/
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>> >>
>> >
>> >
>> >
>>
>>
>>
>> --
>> you too?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



-- 
you too?

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


Mime
View raw message