commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jstrac...@apache.org
Subject cvs commit: jakarta-commons/discovery/xdocs index.xml
Date Tue, 20 Aug 2002 17:20:20 GMT
jstrachan    2002/08/20 10:20:20

  Added:       discovery/xdocs index.xml
  Log:
  Added a simple index page used for the Maven-generated website
  
  Revision  Changes    Path
  1.1                  jakarta-commons/discovery/xdocs/index.xml
  
  Index: index.xml
  ===================================================================
  <?xml version="1.0"?>
  
  <document>
  
   <properties>
    <title>Discovery: Serivce Discovery component</title>
   </properties>
  
  <body>
  
  <section name="Discovery: Serivce Discovery component">
  
  <p>The Discovery Component is about discovering, or finding,
  implementations for pluggable interfaces.
  It provides facilities intantiating classes in general,
  and for lifecycle management of singleton (factory) classes.
  </p>
  <p>
  Fundamentally, Discovery locates classes that implement a given Java interface.
  The discovery pattern, though not necessarily this package,
  is used in many projects including JAXP (SaxParserFactory and others)
  and commons-logging (LogFactory).
  By extracting this pattern, other projects can (re)use it
  and take advantage of improvements to the pattern as Discovery evolves.
  </p>
  <p>
  Discovery improves over previous implementations
  by establishing facilities for working within managed environments.
  These allow configuration and property overrides without appealing
  to the global System properties (which are scoped across an entire JVM).
  </p>
  
  </section>
  <section name="Scope">
  <p>
  This is not indended to be a replacement to be used strictly by the user, but rather
  a replacement to be used directly by projects.  Use by the user is also reasonable,
  but limited due to 'keeping this simple'.  In particular, there is no configuration
  for this discovery service, it relies soley on usage patterns.
  </p>
  
  <p>
  Given a java.lang.Class parameter 'package.Class' that represents a
  fundamental service as either an interface, an abstract class
  (or even a regular class), find an implementation of that class:
  <ul>
  <li>Look for system property named 'package.Class', the value of which is the
      name of an implementation.</li>
  <li>Look for a 'local' property named 'package.Class'...</li>
  <li>Attempt JDK 1.3+ style discovery</li>
  <li>Attempt to load a default implementation</li>
  </ul>
  In all cases, verify that the discovered implementation <b>implements</b>
  'package.Class'.
  </p>
  
  <p>
  The package should :
  <ul>
  <li>Have an API which should be as simple to use as possible</li>
  <li>Be based on usage patterns, not specific configuration file</li>
  <li>Represent proper discovery &amp; class-loading principles</li>
  <li>Be reasonably portable across JDK levels (1.1.8+?)</li>
  </ul>
  </p>
  
  </section>
  
  </body>
  </document>
  
  
  
  

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