Re: [HiveMind] extend BuildFactory to use static fields/methods

Harish Krishnaswamy Thu, 02 Oct 2003 07:26:18 -0700

Ah, I see. Should we stick with our convention of passing values via attributes, may be? But if you are planning on allowing OGNL expressions, the other form may be convenient, but I am not sure if we need to allow expressions in the descriptor though.

-Harish

Howard M. Lewis Ship wrote:

I just didn't list out the other primitive types (boolean, long, double, etc.)
<service-id/> would be the constructed service's id, as a string, alternative to 
<construct
service-id-property="..."/>
<service service-id="..."/> would be a reference to some other service, analagous to 
<set-service
property="..." service-id="..."/>
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
-----Original Message----- From: Harish Krishnaswamy [mailto:[EMAIL PROTECTED] Sent: 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 into BuilderFactory, to provide both sets of options (using constructors, then optionally setting properties).

I really like the idea as long as we have both the options.

2) Could we use http://jakarta.apache.org/commons/beanutils/api/org/apache/co

mmons/bean

utils/ConstructorUtils.html to access the constructor (this applies to elsewhere in the

framework). Method public static

Object invokeConstructor(Class klass, Object[] args) seems

to do the trick, and I will be changing

other code to start using this. 3) The exception thrown on line 133 should be more

descriptive, come from HiveMind.properties, and

include the correct Location. 4) Need an update to framework/xdoc/BuilderFactory.xml to

describe new features (once merged into
BuilderFactory).
5) For the constructor arguments, would this look better:
<construct ...>
  <string>foo</string>
  <service>service-id</service>
  <configuration>config-id</configuration>
?? Maybe, maybe not.
Don't we need the primitives? I think we do.

6) What if the constructor expects the Log, Messages or

service id to

be a parameter? Need <log/> <messages/> <service-id/> elements.

How is <service> and <service-id> different? I think we will need a way to pass in everything that we can, so we may need <log> and <messages> too. Just my 2 cents.
-- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com
-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Knut Wannheden
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 and could reuse the test harness, etc. Therefore I now attach the additions and changes as a patch. If this isn't convenient for you I will try to separate the code and send it in a different form.

--knut

"Howard M. Lewis Ship" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]

I do like the idea of mixing the two models; write some tests and we'll

see about integrating it
with hivemind.BuilderFactory.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] 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 <properties> as you proposed, instead the <set-...> elements are immedeate child elements. This way the service can be used everywhere hivemind.BuilderFactory is used. E.g.
<construct class="...">
<set-service service-id="..."/>
<set-boolean .../>
<int value="42"/>
<set-int .../>
<string value="foo"/>
</construct>
The constructor parameter elements and property elements can be mixed freely, as long as the constructor parameter elements are given in the same order as in the actual constructor. In
this case:
int, String.
The service supports the following constructor parameter
elements: <string>, <int>, <long>, <boolean>, <service>,
<configuration>, and <resource>.
If anyone's interested I can supply the source. I just
thought I'd

write some more unit tests first...

--knut

"Christian Essl" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]

That would be realy helpful. Maybe we could add a

<properties> tag
which would include the current BuilderFactory tags and set the
properties after the service is constructed.
<contruct class="...">
<service service-id="..."/>
<configuration configuration-id="..."/>
<int value="..."/>
(etc.)
<properties>
<set-boolean .../>
(etc.)
</properties>
</construct>
On Wed, 1 Oct 2003 10:22:52 -0400, Howard M. Lewis Ship
<[EMAIL PROTECTED]> wrote:
Maybe "ConstructorFactory"? Something like:
<contruct class="...">
<service service-id="..."/>
<configuration configuration-id="..."/>
<int value="..."/>
(etc.)
</construct>
The elements inside the <construct> element are the
parameters
to the constructor.

I'll be setting up a HiveMind:Contrib subproject shortly. We can start putting stuff in there and then migrate it up to library or framework if it proves to be popular

and
essential.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://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 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 feel that this talk of accessing static

singletons is a step

backwards.

The point of HiveMind is to eliminate those static

variables and
static inits, do things thread-safe and just-in-time.

-- Howard M. Lewis Ship Creator, Tapestry: Java Web Components

http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
--------------------------------------------------------------------

- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:

[EMAIL PROTECTED]

--------------------------------------------------------------------

- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:

[EMAIL PROTECTED]

-- Using M2, Opera's revolutionary e-mail client:

http://www.opera.com/m2/

------------------------------------------------------------
---------

To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:

[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [HiveMind] extend BuildFactory to use static fields/methods

Reply via email to