commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject Re: [discovery] code/design review [was Re: The exegesis]
Date Tue, 13 Aug 2002 21:21:52 GMT
Costin, we disagree... again :-(    But, and I mean this sincerly, I 
appreciate your points of view.

First, I repeat: this package is NOT just about JDK 1.3 style service 
discovery.  Never intended (in my mind) to be limited to that.  I agree 
that I made some assumptions about everyones understanding of 'discovery', 
but my intentions were clearly stated to be based on LogFactory....  I'm 
not yet ready to let go of that.

I've a use for all of the function I've put into the package, in multiple 
projects.  Given the amount of time & effort to establish a new 'commons' 
project, I'm not happy with the idea of going back to the drawing board - 
my runway is just too short for that now.  My requirements are to resolve 
the problems addressed by many of these concepts (ManagedProperties).  I 
can look at providing pluggable interfaces to allow me to remove some of 
these from the (published) code, but that raises other issues - 
particularly within a 'discovery' package.

I'm willing to accept a position that discovery *host* the ideas until 
such time as someone else evolves them into new projects.  That seems to 
me to be in line with open source software evolution.

So, let's see if we can find a middleground.

I'm willing to put the following on the sacrificial alter, and burn it - 
if you so desire:

A.  singleton, caching, anything related to life-cycle management.
B.  propogating/passing properties file on to instantiated classes.

Would you be satisfied (you don't have to be any happier than I am :-) to 
have a 'helper' or 'tool' package for some of the items you consider out 
of scope?  I'd break things down as follows:


1.  Discovery (main):
1.a.  find class name, including looking within a properties file (as per 
JAXP)
1.b.  load class/resource (finding/using class loaders in the correct 
manner is really central to the use pattern, and is one of the pieces that 
is difficult for a 'newbie' (like me) to get right)
1.c.  ManagedProperties  this addresses specific issues related to use of, 
rather alternatives to, system properties that I require (1a) to use.

2.  Discovery Tools/Helpers
2.a.  class instantiation - I give you an interface, you give me an object 
implementing same.



Finally, if you have time to spell out a specific example, I'd appreciate 
gaining an understanding of how YOU would propose that the LogFactory and 
Log classes (in commons-logging, as they are used today) work within an 
independent (open-source) life-cycle management framework, and how you 
would propose that they work inside a managed environment (J2EE servlet). 
Please help me understand WHY the principles used in LogFactory shouldn't 
be abstracted for more general use in other packages, how to fix 
LogFactory if it's broke... etc.

<ras>


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


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

> My intended purpose, however, was/is to allow you to go beyond that, if 
> you choose... therefore, IF you use the correct API then it looks in 
> properties files... IF you use the correct API it initializes, etc.  It 
> was never intended to be limited to JUST the JDK13 META-INF support.

I think that's out of scope for discovery, and even for commons.

You may consider moving this to sandbox ( for example in [paterns] :-),
or to a different component. I'm ( quite strongly) -1 on doing it
in discovery.

Craig - what's your opinion ?


> I don't suppose I have a single *spec* that I'm working with.

Then propose a different commons component for the other. 

> Discovery provides a few layers of 'service':
> 
> 1.  Discover class (returns Class, not string - you indicate that you 
> don't even want this to load the found class?  I'd be happy to add 
another 
> layer - return 'list' of discovered class 'names' in order...)

Not sure - Class is probably ok ( I slightly prefer String and let the
caller do whatever it wants, it may not want to initalize it imediately - 
for example in ant it may make sense to delay it until it's actually 
needed ).

> 2.  Discover class, instantiate new instance.

Intantiate should be done by the caller, when it wants to and how 
it wants to.
 
> 3.  Discover class, manage as a 'singleton' within a context (thread 
> context class loader).

That's another thing that should be done by the project calling that 
in the way it wants. 

> 4.  Finally, loading resources is as much a part of the classloader as 
> loading clases, so discovery supports this.. [HOW we use it internally 
can 
> be debated further, but I hope you aren't asking that I remove that 
> also...]

Finding resources may be fine - but not processing them, i.e. a feature
to find properties file in different loaders or something named 
META-INF/ant.tasks or META-INF/antlib.xml would be nice. As long as you 
don't try to interpret it.


> It does these with varying degrees of sophistication - at the one 
extreme 
> your input is ONLY a (interface) class.  At the other extreme, you 
> indicate the interface class, property name, parameters for constructor, 

> property file name, default implementation (and it's constructor 
> parameters)....  These are bread out of requirements, and are NOT 
intended 
> to be used in the general case, but ARE intended to provide that level 
of 
> service to code that repeats such patterns...

I'm -1 on this. Let's make it complex if we really need to.


> >From what I can tell, you are asking me to do (1) and only (1).  I'm 
not 
> in agreement with that.

No, I'm asking to do (1) as commons-discovery and the rest as a 
separate component ( commons-config ? commons-lifecycle ? ). If you
get the votes for that.

> One driving force is to be able to replace a lot of code that in other 
> projects without changing the behavior (both commons-logging and axis). 
At 
> one level I'd like to preserve the "pure" interfaces more in line with 
> what you are talking about, but at another level support more 
complicated 
> discovery patterns.

You don't need to replace 'a lot of code' - just the code that deals with
discovery. And doing it in the most correct way is more important than 
having tons of features or covering other areas.

I doubt there will be much adoption for this if you try to also get
into lifecycle/config.

Costin



--
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