Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
To: commons-dev@jakarta.apache.org
From: "Knut Wannheden" <knut.wannheden@paranor.ch>
Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods
Date: Wed, 1 Oct 2003 14:44:01 +0200
Lines: 111
Message-ID: <blei6i$un7$1@sea.gmane.org>
References: <bldpvi$jk0$1@sea.gmane.org> <oprwcwacuowo6mmv@mail.yahoo.de>
 <bleauc$g7o$1@sea.gmane.org> <oprwc4mku4wo6mmv@mail.yahoo.de>
 <oprwc6bzhn5c7tcy@localhost>
Sender: news <news@sea.gmane.org>

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