Hi Dan (and Guillaume),
I think it makes more sense to include WS-N in CXF. As the current
implementation is tied to ActiveMQ, I think it would required some
enhancement to:
- use a pure JMS implementation, allowing us to use ActiveMQ and any
other JMS broker (WebSphere MQ Series for instance)
- use a fully OSGi compliant implementation
- be able to describe the WS-N endpoint (poll, etc) in Spring/Blueprint
CXF and in Camel
I'm ready to help on these topics ;)
My 0.02$
Regards
JB
On 10/05/2011 06:31 PM, Daniel Kulp wrote:
Just wanted to mention that Guillaume and I have been chatting a bit about the
code on the CXF IRC channel today. He ran into some differences with various
JAX-WS implementations:
http://irclogs.dankulp.com/logs/irclogger_log/cxf?date=2011-10-05,Wed&sel=128#l124
that required some "less clean" code. Nothing major. We also talked about
the JMS stuff currently being tied to ActiveMQ and options around that:
http://irclogs.dankulp.com/logs/irclogger_log/cxf?date=2011-10-05,Wed&sel=194#l190
That last stuff is definitely not critical (tied to ActiveMQ is perfectly fine
for now as long as we mention that).
Dan
On Wednesday, October 05, 2011 6:13:15 PM Guillaume Nodet wrote:
On Wed, Oct 5, 2011 at 18:01, Daniel Kulp<[email protected]> wrote:
On Wednesday, October 05, 2011 5:22:01 PM Guillaume Nodet wrote:
I've started to re-architect the WS-Notification implementation to
get
rid
of JBI and be pure JAX-WS based.
The results are available at https://github.com/gnodet/wsn .
I think there was a consensus to move the code base to CXF, but I
just
want
to make sure everyone agree.
I definitely agree. :-) Very excited about that prospect. :-)
How close to ready is it? Is it something that we can get into CXF
shortly
for inclusion with CXF 2.5?
The code is really the same than in ServiceMix, only the JBI bits have been
replaced by JAX-WS.
A few tests would definitely help, but the code base itself is mostly done.
I recall some users would have been interested in having more features like
complex topics or such, but not having those features does not mean the base
service is not usable.
Also, I'd like to keep the implementation lightweight and keep it
pure
JAXWS
based if possible.
I'm quite a bit less excited about this. I would say pure jaxws + cxf-
common-utilities is fine as it should likely use the CXF logging stuff,
CXF XML utilities (DOMUtils, etc...), etc... duplicating stuff from
common to just avoid a dep is silly to me.
Yeah, I meant I'd like to be independent of the jaxws provider.
The code is currently using slf4j for logging though.
Dan
On Fri, Jul 8, 2011 at 10:20, Guillaume Nodet<[email protected]> wrote:
Just want to start a discussion on WS-Notification because I've
had a
chat last week with a ServiceMix user about that.
That component is not heavily used, but we always have a few
users
reporting bugs and such. This component is really the only one
which is no replacement in Camel. Given WS-Notification is
really just an implementation of a WSDL, I wonder if it would
be easier to simply port it to a pure CXF web service so that
it would not be tied to JBI anymore, and would also solve a
bunch of problems related to the behavior of
WS-Addressing inside the JBI bus (which is not really what users
expect when using WS-Notification).
So I'd like to gauge the interest in re-architecting this
component to make it more easily consumable without JBI / NMR,
just as a JAX-WS web service (if possible even with no ties to
CXF). We could then maybe plan a few enhancements such as
the use of non simple topics definitions and such.
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
