Dan Diephouse wrote:
Andrea started on a configuration design page which summarizes the
discussions to make sure we're meeting our requirements:
http://cwiki.apache.org/confluence/display/CXF/Configuration+Design
I've added our out of the box scenario so that we can understand how
things would work for the various requirements.
Andrea: I have a couple questions about the things that need to be
done list that I was hoping you could answer:
Split the old configuration metadata files into a pure schema part
and an optional xml file containing default values (for complex
elements).
I'm not sure what this means. Can you elaborate?
The configuration metadata files are not schemas themselves but xml
(complying with the configuration metadata in
trunk/common/src/main/resources/schemas/configuration/metadata.xsd). The
metadata provides schema information and default values that cannot be
part of a schema into one, so that's why it has to be split. I believe
in most if not all cases a schema will actually do. So mainly this task
is about converting configuration metadata files into schemas.
Write xjc plugin to code generate base beans from schema. In the
future, other stuff could be generated also (such as aop.xml files
for load-time weaving in aspectJ).
Is this for something like combining HTTPDestination with its
HTTPServerPolicy object so the configuration bean and the component
are the same?
HTTPDestination according to its old metadata (see
trunk/api/src/main/resources/config-metadata/http-server-cfg.xml) should
have four configurable properties:
httpServer of type HTTPServerPolicy (defined in
trunk/api/src/main/resources/schemas/wsdl/http-conf.xsd)
authorization of type AuthorizationPolicy (defined in
trunk/api/src/main/resources/schemas/configuration/security.xsd)
sslServer of type SSLServerPolicy (also defined in
trunk/api/src/main/resources/schemas/configuration/security.xsd)
contextMatchStrategy of type xs:string
These would go into one schema:
<xs:schema ...>
<xs:element name="HTTPDestinationConfiguration">
<xs:complexType>
<xs:sequence>
<xs:element name="httpServer " type="http-conf:HTTPServerPolicy
" minOccurs="0"/>
<xs:element name="authorization" type="sec:AuthorizationPolicy"
minOccurs="0"/>
<xs:element name="sslServer" type="sec:SSLServerPolicy"
minOccurs="0"/>
<xs:element name="contextMatchStrategy " type="xs:string"
default="exact" minOccurs="0"/>
<xs:sequence>
<xs:complexType>
</xs:element>
</xs:schema>
Then you'd have JettyHTTPDestination extends
HTTPDestinationConfiguration - so it has the four getters and setters
and need to call onto configuration,getObject(...) any more.
This alone does not need a xjc plugin - plain xjc will do. But in order
to make the generated HTTPDestinationConfiguration more intelligent you
need an xjc plugin that e.g. causes
HTTPDestinationConfiguration extends AbstractConfigurableBaseBean and
the setters add a call to 'notifyListeners' (from
AbstractConfigurableBaseBean).
# In a first step (pre-aspectJ) complement the call to new XYZ() with
a configurer.configure(XYZ) and provide a Spring based implementation
of a configurer. This would set ApplicationContext,
BeanWiringInfoResolver, cause injection to be performed and invoke
init methods, BeanFactoryPostProcessors etc..
Can we put together a list of scenarios where we need to do this? The
big case seems to be when you're using the JAX-WS static apis and need
to customize transports/etc. I have a rough idea how this works in my
head, but I feel like its kind of nebulous yet.
So far I think we need it for http destination and conduit, jms
destination and conduit, client and server endpoints, service, bus and
rm handler (that's where now up to now Configuration apis have been used).
It does not mean that all these objects are candidates that are created
by the runtime and therefore explicitly (or implicitly via aspectJ) need
to request injection. But these are all classes that have configurable
properties that are not currently data members.
Does that explain things?
Andrea.
Cheers,
- Dan
