[discovery] code/design review [was Re: The exegesis]

[rs...@us.ibm.com]

Ahh, now someone is looking deeper... Thanks!

Let talk through the issues.  I'm going to break them down slightly 
differently than you had presented them, so work with me through these:

1.a.  RE: lifecycle  Keep in mind that an implementation-to-be found is 
NOT required to implement the Service interface - it is simply that if it 
DOES, then it is notified on init/release.  It's OPTIONAL.  A 
publish/subscribe mechanism still requires an (common) interface...

1.b.  Eliminate the DiscoverSingleton (caching) and ServiceSingleton.. I'd 
like to think about it, but I think that I agree with you... it's to much, 
it isn't right for all cases/uses, etc...  especially in light of the 
conversation(s) regarding life-cycle managment.

2.  Removing Service interface.  Again, it's use is optional - it's only 
called if the found class implements the interface.  In this case, it's 
purpose is to pass through Properties.  This seems to be a central theme 
in the pattern... identify & load a config file, [optionally] use to find 
impl, identify & load impl class, pass properties to impl class.
2.a.  Are you suggesting that we remove support for property files?  The 
future is bright, but that's a lot to ask!
2.b.  We COULD turn this around: ... identify & load impl class [may 
involve use of 'a' config file], impl class uses discovery to locate & 
load config file... discovery may 'cache' the config to hand right back to 
impl...  thoughts?

3.  ManagedProperties.  This was introduced to resolve a seemingly 
inherint problem I keep running into regarding use of System properties to 
configure middleware in managed environs.  That's just plain *wrong*, but 
in at least one case It's not easy to refactor the code to go another 
way... this was a poor-mans solution that *is* interesting in it's own 
right (it's a model for setting 'global' properties that are scoped by 
(thread context) class loader hierarchies).  Granted that it's use in 
discovery is questionable.  That's how many other component/patterns get 
their start, right?

<ras>

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [javadoc-PATCH][beanutils] ResultSetDynaClass

[robert burrell donkin <ro...@blueyonder.co.uk>]

patch committed.

thanks.

- robert


On Monday, August 12, 2002, at 11:05 PM, Danny Mui wrote:

> Ok just a documentation patch...
>
> danny
> 119,120c119,120
> <  *   while (rsdc.hasNext()) {
> <  *     DynaBean oldRow = (DynaBean) rows.iterator();
> ---
>>  *   while (rows.hasNext()) {
>>  *     DynaBean oldRow = (DynaBean) rows.next();
>
> --
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[javadoc-PATCH][beanutils] ResultSetDynaClass

[Danny Mui <da...@muibros.com>]

Ok just a documentation patch...

danny

Re: [discovery] code/design review [was Re: The exegesis]

[co...@covalent.net]

On Mon, 12 Aug 2002 rsitze@us.ibm.com wrote:

> 1.a.  RE: lifecycle  Keep in mind that an implementation-to-be found is 
> NOT required to implement the Service interface - it is simply that if it 
> DOES, then it is notified on init/release.  It's OPTIONAL.  A 
> publish/subscribe mechanism still requires an (common) interface...

Optional or not - it is bad. Let projects initialize the components 
the way they want. Ant or tomcat will first set properties, then call
init. 
Release is completely out of the control of discovery. 

Discovery should only use META-INF/ and discover the components.

If you want, add Event/Listener to let projects using discovery to
be notified when a component is found and initialize it. But that's 
useless IMO - the project will call discovery to get a list of 
components, and then configure/initialize acording to it's one 
design and lifecycle contracts. 

Just keep discovery simple and focused to what it must solve.


> 2.  Removing Service interface.  Again, it's use is optional - it's only 
> called if the found class implements the interface.  In this case, it's 
> purpose is to pass through Properties.  This seems to be a central theme 
> in the pattern... identify & load a config file, [optionally] use to find 
> impl, identify & load impl class, pass properties to impl class.

The goal is to discover using META-INF/services. Not to init, load or
config. Not to define ( even optional ) interfaces for components. The
spec is clear - you have a file named after the interface it implements,
and containing the name(s) of the classess implementing the interface.
 

> 2.a.  Are you suggesting that we remove support for property files?  The 
> future is bright, but that's a lot to ask!

Sorry for not finding this earlier, all I remember is discussion on 
a commons component to implement the things duplicated in jaxp, etc. 
Configuration in general is out of scope ( so a -1/veto on adding
it to discovery), and configuration via Properties ( even if optional )
is pretty bad ( I would -1 it on any project ). 


> 2.b.  We COULD turn this around: ... identify & load impl class [may 
> involve use of 'a' config file], impl class uses discovery to locate & 
> load config file... discovery may 'cache' the config to hand right back to 
> impl...  thoughts?

Don't turn this around - we just find the name of the classes, don't load
or instantiate or configure them. There is no requirement for the service
impl. to have a public no-arg constructor AFAIK, and the project knows 
better what to do. 


> 3.  ManagedProperties.  This was introduced to resolve a seemingly 
> inherint problem I keep running into regarding use of System properties to 
> configure middleware in managed environs.  That's just plain *wrong*, but 
> in at least one case It's not easy to refactor the code to go another 
> way... this was a poor-mans solution that *is* interesting in it's own 
> right (it's a model for setting 'global' properties that are scoped by 
> (thread context) class loader hierarchies).  Granted that it's use in 
> discovery is questionable.  That's how many other component/patterns get 
> their start, right?

It may be a nice util, but not for discovery. Move it to sandbox or 
propose a commons-config ( or commons-propertyConfig ). 

Having a JDK1.2 implementation and wrapper of JDK1.4 java.util.prefs
would be quite usefull ( i.e. use 1.4 prefs if 1.4 is detected, emulate it 
if not ), and that's where you class may fit ( and provide added value ).

Costin


> 
> <ras>
> 
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
> 
> 
> 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>