commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [HiveMind] Services and extensions ...
Date Thu, 18 Sep 2003 14:56:01 GMT
Yes one module == one jar == one deployment descriptor.

To allow overriding of the service, you either don't provide an implementation, or follow
the
guidelines on the web site about overridable services (adding
a level of indirection using substitution symbols).

--
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: Johan Lindquist [mailto:johan@kawoo.co.uk] 
> Sent: Thursday, September 18, 2003 8:40 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] Services and extensions ...
> 
> 
> When you say 'single location' is that in a single jar?
> 
> Cause won't packaging the service together with the 
> implementation prevent 
> people from choosing a different implementation at deploy 
> time?  And to 
> only allow them to add interceptors?  Or have I 
> mis-understood something?
> 
> Johan
> 
> On Thu, 18 Sep 2003 07:27:38 -0400, Howard M. Lewis Ship 
> <hlship@comcast.net> wrote:
> 
> > No, that separation is desirable in a small number of cases. Your
> > examples will be identical at
> > runtime.
> >
> > The typical usage is to define the service interface, 
> implementation 
> > and
> > interceptors in a single
> > location.
> > Here's a common scenario; you define a DAO (data access 
> object) service 
> > in module A with no impl.
> >
> > When your app runs against oracle, you deploy module A with 
> module B,
> > which supplies Oracle
> > implementations.
> >
> > When your app runs against sql server, you deploy module A 
> with module
> > C, which supplies sqlserver
> > implementations.
> >
> > In this way, you can use HiveMind as the uber-factory.
> >
> > --
> > 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: Johan Lindquist [mailto:johan@kawoo.co.uk]
> >> Sent: Thursday, September 18, 2003 6:44 AM
> >> To: Jakarta Commons Developers List
> >> Subject: [HiveMind] Services and extensions ...
> >>
> >>
> >> Is it desirable to have services defined in a single 
> module and the 
> >> extensions to those services defined in a separate module?
> >>
> >> Is there a difference between the following hivemodule xml?
> >>
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples" version="1.0.0">
> >>    <service id="Adder" interface="hivemind.examples.Adder"
> >> model="singleton"/>
> >> 	<invoke-factory service-id="hivemind.BuilderFactory">
> >> 		<construct
> >> 			class="hivemind.examples.impl.AdderImpl">
> >> 		</construct>
> >> 	</invoke-factory>
> >>    </service>
> >> </module>
> >>
> >> and
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples" version="1.0.0">
> >>    <service id="Adder" interface="hivemind.examples.Adder"
> >> model="singleton"/>
> >> </module>
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples.impl" version="1.0.0">
> >>    <extend-service service-id="hivemind.examples.Adder">
> >> 	<invoke-factory service-id="hivemind.BuilderFactory">
> >> 		<construct
> >> 			class="hivemind.examples.impl.AdderImpl">
> >> 		</construct>
> >> 	</invoke-factory>
> >>    </extend-service>
> >> </module>
> >>
> >> 
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: 
> commons-dev-help@jakarta.apache.org
> >>
> >
> >
> > 
> ---------------------------------------------------------------------
> > 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