cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Smyth <andrea.sm...@iona.com>
Subject Re: Configuration Proposal
Date Wed, 06 Sep 2006 09:55:38 GMT
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:dan@envoisolutions.com]
>>Sent: Tuesday, September 05, 2006 5:57 PM
>>To: cxf-dev@incubator.apache.org
>>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
>>    
>>
>
>
>  
>


Mime
View raw message