cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Ideas for 2.2
Date Thu, 19 Jun 2008 13:44:25 GMT

Regarding JMS, the other thing that probably needs to be done is  
investigating the SOAP over JMS spec submitted at:
and seeing how well that can fit in.


On Jun 18, 2008, at 7:34 PM, Christian Schneider wrote:

> I would really like to see good osgi integration as we plan to rely  
> quite heavily on osgi in the future. But as I myself are only  
> starting on this I donĀ“t know much about the details. Basically I  
> would like to be able  to connect the osgi internal services with  
> cxf to communicate with the outside world. So a client should be  
> able to simply use an osgi service. The provider of the service  
> could then be simply a local bundle or a cxf based kind of binding  
> component that does the remoting. I hope somthing like this will  
> come from servicemix.
> For the short term the jms enhancements are my favourite.  
> Configuring the jms destination and jms conduit is really non  
> intuitive and it does not follow spring standard procedures.
> The most important thing for me is externalising the  
> ConnectionFactory. This should be defined in a separate bean and  
> only be referenced from conduit and destination. I think there are  
> two main
> use cases here.
> 1. You want to define the ConnectionFactory yourself. In a spearate  
> bean this will be easy
> 2. You want to fetch the factory from jndi. In this case I would  
> like to use the spring jee extensions or again a simple bean
> <jee:jndi-lookup id="myConnectionFactory" jndi- 
> name="my.connection.Factory"
>   <jee:environment>
> java 
> .naming.factory.initial=weblogic.jndi.WLInitialContextFactory       
> java.naming.provider.url=tcp://localhost:10001
>   </jee:environment>  </jee:jndi-lookup>
> The last thing about jms is that I would like to be able to select  
> the connection and configure the queue and other settings in the  
> address of the service. I really like the way camel handles
> jms. Perhaps this can be done like in camel. So perhaps it is  
> possible to not need the jms destination and jms conduit configs at  
> all.
> Best regards
> Christian
> Daniel Kulp schrieb:
>> Now that 2.1.1 is being voted on, I'd like to step back a bit and  
>> talk a little about ideas for the next versions.
>> First, most likely, we'll need to do a 2.1.2 release in about 6-8  
>> weeks (and maybe 2.0.8 as well).   We've done a very good job of  
>> getting fixes out to our users in a timely manner and I'd like to  
>> keep that up, but I also would like to think about 2.2 a bit as  
>> well.   I haven't created the 2.1.x fixes branch yet, but I  
>> probably will shortly if we start doing some new stuff toward 2.2.
>> That said, here is my list of stuff that is "missing" and could be  
>> considered for 2.2:
>> 5) OSGi stuff - I know there are some OSGi enhancements in the  
>> works that could be pulled in:
>>   a) osgi http transport - this currently lives in ServiceMix, but  
>> could be pulled into CXF to work with other OSGi runtimes
>>   b) Distributed OSGi (RFC 119) - there is work being done to  
>> implement RFC 119 with CXF.   There are some rules about releasing  
>> the IP for this though that is being investigated.
>> 6) JMS transport enhancements - I keep wanting to update this a bit  
>> to leverage spring jms stuff a bit better to make it much easier to  
>> configure.
>> Anyway, thoughts?   Other ideas?  Comments?

Daniel Kulp

View raw message