Johnson, Eric wrote:
Questions:
* When you say "User would supply a /META-INF/cxf/cxf.xml file which
would override the default beans in cxf-*.xml." Does this mean the user
*must* put the config files there? Or can the configuration file be
placed in some other location?
I think to achieve non-default behavior users would not typically place
their cfg file into a META-INF directory - rather they'd supply the name
of this cfg file (which should be on the classpath) to the bus factory
so that the application context is created with this cfg file AND the
default ones.
new ClassPathXmlApplicationContext( new String[] { "user.xml",
"/META-INF/cxf/cxf.xml", "/META-INF/cxf/cxf-*.xml" });
or
new ClassPathXmlApplicationContext("user.xml");
depending on whether or not they want to include the default extensions.
BTW not sure if in the first case the use supplied cfg file should
appear first or last.
If they supplied their own extension, then of course they'd put
instructions for how to wire that extension into the existing
infrastructure into the extension's META-INF services directory in the
form of a cxf-*.xml file.
Andrea.
* How would this work with policies that are specified in the WSDL? For
example, in Celtix there are a number of WSDL extensors that allow for
configuration of JMS endpoint behavior.
-----Original Message-----
From: Dan Diephouse [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 05, 2006 5:57 PM
To: [email protected]
Subject: Configuration Proposal
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?
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?
# 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.
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
