cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache CXF > Configuration Requirements
Date Fri, 14 Aug 2009 13:58:00 GMT
    <base href="">
            <link rel="stylesheet" href="/confluence/s/1519/1/11/_/styles/combined.css?spaceKey=CXF&amp;forWysiwyg=true"
<body style="background-color: white" bgcolor="white">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
     <h2><s>Configuration Requirements</s></h2>
     <h4>Page <b>removed</b> by             <a href="">Daniel
     <div class="notificationGreySide">
         <h2><a name="ConfigurationRequirements-ConfigurationRequirementsforCXF"></a>Configuration
Requirements for CXF</h2>

<h3><a name="ConfigurationRequirements-ZeroConfiguration"></a>Zero Configuration</h3>
<p>Everything <em>just works</em> out of the box. Users only need to supply
a configuration file when they want to achieve non-default behaviour.</p>

<h3><a name="ConfigurationRequirements-Extensibility%2FDiscovery"></a>Extensibility/Discovery</h3>
<p>The runtime must be extensible without any additional configuration except by the
extension component itself. Simply adding the jar implementing the extension to the classpath
should make the extended functionality available to the runtime. Typically, the extension
component typically would include configuration file fragments in the META-INF/services directory
of its jar.</p>

<h3><a name="ConfigurationRequirements-MinimalEfforttoAchievenonDefaultBehaviour"></a>Minimal
Effort to Achieve non-Default Behaviour</h3>
<p>In order to change the default behaviour of the runtime, users only need to supply
a minimal amount of information in their configuration files - pertaining to objects whose
behaviour they want changed.</p>

<h3><a name="ConfigurationRequirements-LateInstantiation"></a>Late Instantiation</h3>
<p>Runtime components should only be instantiated when needed.</p>

<h3><a name="ConfigurationRequirements-Documentation"></a>Documentation</h3>
<p>It should be possible to provide reference documentation on what behaviour users
can configure (incl. supported value ranges, default values etc) with minimal effort.</p>

<h3><a name="ConfigurationRequirements-Easilyembeddedandunittestable"></a>Easily
embedded and unit testable</h3>
<p>Users should not have to go out of their way to build up Configurations as holders
for the actual objects a component might need. </p>

<h3><a name="ConfigurationRequirements-BefriendlywithContainers"></a>Be
friendly with Containers</h3>
<p>Obviously we should support Spring users as they're slowly taking over the world.
Other containers include Plexus &amp; Pico.</p>

<h3><a name="ConfigurationRequirements-Benoninvasive"></a>Be non invasive</h3>
<p>Configuration should have minimal affect on APIs as our APIs should be focused on
being good APIs for those developers using them. Ideally the Configuration would use the APIs
instead of the other way around.</p>

<h3><a name="ConfigurationRequirements-Supportinformationfrommultiplesources"></a>Support
information from multiple sources</h3>
<p>We should support configuration from the command line, WSDL, Service, etc. The configurable
component (bean) should be unaware of the underlying source for its configuration data.</p>

<h3><a name="ConfigurationRequirements-DynamicUpdates"></a>Dynamic Updates</h3>
<p>Users should be able to tweak the configuration at runtime - programatically or through
the use of the CXF management interfaces (wrapping the use of JMX).</p>

View raw message