Re: Just a few thoughts for the weekend!

["Liebig, Stefan " <St...@compeople.de>]

Knut,

I looked at this issue from the POJOs point of view and
what I think that is missing, is that configuration data
just go into POJOs as java.util.List instances. Whereas
services can be much richer.
I don´t want to drop the possibility of contributing data
from different modules to one configuration.
For that I created an experimental ServiceImplementationFactory,
the DataServiceBuilder. Its usage is, e.g.

<service-point id="Map" interface="java.util.Map">
	<invoke-factory service-id="DataServiceBuilder">
		<for-each source="Test" target="java.util.HashMap">
			<do method="put">
				<parameter property="key"/>
				<parameter property="value"/>
			</do>
		</for-each>
	</invoke-factory>
</service-point>		

<configuration-point id="Test" schema-id="Property"/>
	
<contribution configuration-id="Test">
	<item key="1" value="eins"/>
	<item key="2" value="zwei"/>
</contribution>

What it does is quite simple but effective. The data service builder iterates
(for-each) over a configuration (source), creates a ´target´ instance, calls
a method (do method) with the given paramters on it. The property values are
the properties of the configuration mapping instance. The result of the above  
is a HashMap with { "1" -> "eins", "2" -> "zwei" }.

You mentioned the scattered ´service concepts´. There is already some kind
of scattered service concept such that you can have a service declatration,
a service implementation and interceptors, and all of them come from
different modules.
One thing I am really missing is the possibility to override a default service
implementation.

Bye,
Stefan


> -----Original Message-----
> From: Knut Wannheden [mailto:knut.wannheden@gmail.com]
> Sent: Tue 30.11.2004 13:51
> To: hivemind-dev@jakarta.apache.org
> Subject: Re: Just a few thoughts for the weekend!
>  
> Stefan,
> 
> I did think about this for a while. IMO reducing everything to
> services would make HiveMind simpler than we'd like it to be.
> 
> The basic problem I see is that a service's implementation (including
> configuration) is specified in a single module whereas a
> configuration's contributions can be scattered across all loaded
> modules.  This scattering of contributions is definitely not something
> we'd want to give up.
> 
> Thus, to unite the service and configuration concepts we'd also have
> to allow for a fragmented service configuration.  I don't quite see
> what that would look like or how it would be an advantage...
> 
> Cheers,
> 
> --knut
> 
> On Fri, 26 Nov 2004 04:02:28 -0800, Liebig, Stefan
> <st...@compeople.de> wrote:
> > 
> > I was thinking about making HiveMind simpler and more generic.
> > My thoughts went into the direction of "dropping" the configurations as
> > they are today.
> > Why not viewing configuration/contributions as services implementing
> > some data interface, i.e. generalizing services and configurations.
> > From a Pojos point of view there is no difference, it has constructor
> > parameters or setter parameter being of some interface. List is also
> > an interface of a component that could have been implemented by a
> > service.
> > Maybe it is possible to write a nice ServiceImplementationFactory
> > that does things like converting a contribution into a Map!?
> > 
> > Just a few thoughts for the weekend to share with you!
> > 
> > Stefan
> > 
> > compeople AG
> > Untermainanlage 8
> > 60329 Frankfurt
> > 
> > fon: +49 (69) 272218 - 0
> > fax: +49 (69) 272218 - 22
> > email: stefan.liebig@compeople.de
> > home: www.compeople.de
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> 


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