Regarding JMS, the other thing that probably needs to be done is
investigating the SOAP over JMS spec submitted at:
http://www.w3.org/Submission/SOAPJMS/
and seeing how well that can fit in.
Dan
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
[EMAIL PROTECTED]
http://www.dankulp.com/blog
