Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <44FF39AF.90306@envoisolutions.com>
Date: Wed, 06 Sep 2006 17:12:15 -0400
From: Dan Diephouse <dan@envoisolutions.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: Configuration Proposal
References: 
 <244F5835C09CB641AE1D928BB2B0B9D8025D3824@amereast-ems2.IONAGLOBAL.COM>
In-Reply-To: 
 <244F5835C09CB641AE1D928BB2B0B9D8025D3824@amereast-ems2.IONAGLOBAL.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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


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