cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <...@envoisolutions.com>
Subject Re: Configuration APIs
Date Fri, 01 Sep 2006 14:58:51 GMT
Andrea Smyth wrote:

> *snip*

>
> Yes, but beans in the jms file are only instantiated (and then use 
> beans in the cxf file)  if a) they are referenced from beans in the 
> cxf or the users file or b) the code explicitly requests a bean in the 
> jms file.

Not true. You can tell spring to instantiate beans on startup. (I think 
thats the default actually - see 
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-lazy-init)

>>> *snip*
>>
>> I'm kind of confused now. In one case you're saying we need to 
>> support setting policies in the wsdl for the endpoint. In which case 
>> the EndpointInfo would've been a logical place to store it.
>
>
> The policy belongs to the destination - and that is defaulted or 
> replaced by something injected into the destination. What I mean to 
> say is that we need multiple sources to participate in performing the 
> injection: the container on the one hand and wsdl/the service model on 
> the other.
>
Yes, and I think the solution I outlined will do that. You can inject 
into the Destination via constructor/setter. Or you can pull it out of 
the EndpointInfo property map, which will be filled in by a classwhich 
reads in the JAXB extensions to the service model

*snip*

>>>
>>> What do you mean by that? The capability that anywhere in the code 
>>> we could request a bean from the XmlBeanFactory/ApplicationContext 
>>> (or a abstraction of that to not depend on Spring exclusively)? I 
>>> would very much be in favor of that -and it would not take away the 
>>> option that developers can wire everything together in whatever way 
>>> they want if they wish to do so. They just would not be forced to 
>>> do  any wiring when it does not yield a benefit (as in the above 
>>> example of the EndpointBean, JaxWsServiceFactoryBean, and 
>>> JettyHTTPDestination beans).
>>>
>> I meant I think it would be good to have the extension manager as a 
>> simple ioc container to manage things for people not using spring.
>
>
> or rather: not using top down dependency injection performed by any 
> container like Spring. These users would use the bus factory that we 
> have now - using the extension manager.

Yes, they could use the extension manager. However, I'm still of the 
opinion that we should have a bus which doesn't use the extension 
manager and have a bus which does extend that bus (this takes like 5 
minutes to separate out).

>
>> I really don't like requesting beans from the ApplicationContext. I 
>> think containers should do the injection as I outlined in my first 
>> email.
>
>
> If you used a bus factory that is based on Spring or another container 
> then you would not have to (request beans from the ApplicationContext).
> So why not support both approaches?
>
I mean I don't like CXF requesting beans from the ApplicationContext. I 
don't like the Configuration approach because its invasive. It changes 
the APIs to make them oriented around the container scenarios, and there 
is no need to do that IMO. We can arrange it instead so injection is used.

I know it is possible to make this work and make it be easy for the 
user. We might have to do a little work on our end debating about the 
best way to do things, but I think the payoff will be there in terms of 
a better API, better maintainability, and better reuse.

I am happy to try to work out a prototype which shows this all working 
later next week.

Cheers,

- Dan

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


Mime
View raw message