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?
The user could potentially specify a property for a different location. But it would be nice to a have a default location that the container looks.

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

The WSDL->service model converter would parse out the extensors into jaxb objects and stick them in the service model. These could then be pulled out via a contextual lookup which searches the message, operation, endpoint, etc for the extensor. If an extensor isn't found, the injected one would be used. For instance, with an HTTPServerPolicy, it could be pulled out of the EndpointInfo and if there wasn't one found, the injected one would be used by default.

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




--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com

Reply via email to