commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: The exegesis
Date Mon, 12 Aug 2002 21:31:13 GMT
On Mon, 12 Aug 2002 rsitze@us.ibm.com wrote:

> Let me say up front:  I'm OK with your ideas in principle, BUT there is 
> another side.. help me to clarify the correct course of action
> 
> DiscoverySingleton is an abstraction of what LogFactory was doing: find 
> LogFactory implementations, cache (by thread context class loader), and 
> provide a 'release' mech.  The creation of the factory and the release are 
> communicated to the LogFactory impl (init/release).
> 
> This made sense, and it makes sense... it's managing a cache of objects 
> and should inherit responsibility for them (lifecycle).  While I can agree 
> to remove that from Discovery, i'd like to have a way to plug something 
> else in (if not now, then later is fine :-).  I think its clear that 
> Discovery has a place in a framework, so how can we propogate component 
> management from an outer framework down through Discovery & it's cache?
> 
> The original purpose of the caching in LogFactory was to facilitate 
> object-management in a managed environment (cleanup objects created by a 
> servlet when app comes down, but not necessarily the appserver).  I still 
> need this.... so I think discovery needs some level of lifecycle 
> management.

First, I don't think discovery is the right place to cache - but the 
caller.

If you really need, you can define a DiscoveryEvent/Listener and 
provide callbacks to the caller, so it can manage its cache.

In any case the Service interface should go - it is not 
Discovery role to initialize the component. And no component should
depend on Service. Configuration of components is not an 
issue for discovery. 

ManagedProperties is also completely out of scope for discovery. 
Again - that's configuration.

There are many projects using the 'ant' patterns ( == java beans
setters ) for configuration ( which maps to JMX very well ). Using
a Properties-based config is a very bad match for this kind of 
projects ( and IMO a very bad way to configure - even if it works
in some simple cases ).

Costin




> 
> <ras>
> 
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> 
> On Mon, 12 Aug 2002 rsitze@us.ibm.com wrote:
> 
> > More fuel for the fire:
> > 
> > 1.  discovery is a (functional) pattern...
> > 2.  discovery provides component life-cycle support 
> (SingletonService)...
> 
> I didn't noticed it. That should be removed - there is no need
> for it. 
> 
> I'll change my vote on the release of discovery to -1 until this gets
> fixed. It should implement the 'services' spec but 
> shouldn't define any API for the services to implement. 
> 
> 
> > which, of course, raises the obvious question:  should it?  How many 
> > life-cycle interface does a component have to implement??
> 
> It shouldn't. Various applications that use discovery may define 
> lifecycle - for example JAXP defines how a parser is created ( factory, 
> etc ), ant defines the lifecycle of a project helper, etc. That's between
> the application and the components, discovery must only find the classes. 
> 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message