] On Behalf Of Knut Wannheden
Sent: Wednesday, October 01, 2003 4:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
I have written a service implementing this strategy, with a minor
difference: I didn't add a nested
Sent: Wednesday, October 01, 2003 4:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
I have written a service implementing this strategy, with a minor
difference: I didn't add a nested properties as you proposed,
instead the set-... elements
: Thursday, October 02, 2003 10:04 AM
To: Jakarta Commons Developers List
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
Howard M. Lewis Ship wrote:
This looks pretty darn good. Just a few thoughts/observations:
1) Could we just merge ConstructorFactory
, October 02, 2003 10:04 AM
To: Jakarta Commons Developers List
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
Howard M. Lewis Ship wrote:
This looks pretty darn good. Just a few thoughts/observations:
1) Could we just merge ConstructorFactory into BuilderFactory
1) Could we just merge ConstructorFactory into BuilderFactory, to provide
both sets of options
(using constructors, then optionally setting properties).
Certainly. I made some sacrifices to make this eventual step as painless as
possible.
2) Could we use
Sent: Wednesday, October 01, 2003 6:56 PM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
Howard,
I found it was easiest to develop the service as part of the
HiveMind project itself. That way I have all the classpaths
set up
Same patch with a quite obvious small tweak (how could I miss that?), which
should also make it more readable...
--knut
Knut Wannheden [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Here's a patch adressing all your points, except 4 ;-). Also there is more
testing required. I'll try
That's certainly a good idea.
On Wed, 1 Oct 2003 07:50:42 +0200, Knut Wannheden
[EMAIL PROTECTED] 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
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
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
Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden
Sent: Wednesday, October 01, 2003 1:51 AM
To: [EMAIL PROTECTED]
Subject: [HiveMind] extend BuildFactory to use static fields/methods
Hi,
I was wondering whether it would make sense to extend the
BuildFactory
Christian,
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
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
: [HiveMind] extend BuildFactory to use static fields/methods
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
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 [EMAIL PROTECTED] wrote in message
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
[EMAIL PROTECTED] wrote:
In my case I was simply trying to wrap a hivemind service around an
existing
service
You are right HiveMind always returns the same instance, but I mean there
can be services which have no state or the state of which is just defined
at construction time and for these it makes in my opinion sense to declare
them as (default-variant) static fields. Further for those Services the
Wouldn't the configuration passed to the factory will make sure the
service is returned in a 'usable' state? The user doesn't do any
configuration at that level?
And the service interface shouldn't really allow configuration changes or?
And I am all for the pattern to ensure consistency in
Developers List
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
Wouldn't the configuration passed to the factory will make sure the
service is returned in a 'usable' state? The user doesn't do any
configuration at that level?
And the service interface shouldn't
Ok, I may have not tested this fully ... [Note to self: must make time to
test more configuration options] But if the service specified in the
builder factory setting and a valid service doesn't exists for that
particular setter, won't the builder factory complain?
Johan
On Wed, 01 Oct 2003
BuildFactory to use static
fields/methods
Ok, I may have not tested this fully ... [Note to self: must
make time to
test more configuration options] But if the service specified in the
builder factory setting and a valid service doesn't exists for that
particular setter, won't the builder
Then how about a new factory service which lets you specify the constructor
parameters? This is also a very common IoC pattern AFAIK.
--knut
Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Outside of Kurt's use case ... wrapping around machine-generated code, I
://javatapestry.blogspot.com
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden
Sent: Wednesday, October 01, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
Then how about a new factory service
PROTECTED]
Subject: Re: [HiveMind] extend BuildFactory to use static fields/methods
Then how about a new factory service which lets you specify the
constructor parameters? This is also a very common IoC pattern AFAIK.
--knut
Howard M. Lewis Ship [EMAIL PROTECTED] wrote in message
news:[EMAIL
://javatapestry.blogspot.com
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden
Sent: Wednesday, October 01, 2003 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
Then how about a new factory
PROTECTED]
Subject: Re: [HiveMind] extend BuildFactory to use static
fields/methods
I have written a service implementing this strategy, with a minor
difference: I didn't add a nested properties as you
proposed, instead the set-... elements are immedeate child
elements. This way
26 matches
Mail list logo
