Hi Team,
Recently we're discussing on Servicemix Dev mailling list about
redesign ws-notification component, previously it was designed as JBI
ServiceEngine and need work together with BindingComponet(like
servicemix-cxf-bc or servicmeix-http) over JBI bus, we currently want
to make it wo
Hi Freeman,
It seems like WS-Notification really is just a web service application
that can run on CXF. Do you see a reason for it to be integrated into
the CXF codebase?
- Dennis
On 07/08/2011 09:36 PM, Freeman Fang wrote:
Hi Team,
Recently we're discussing on Servicemix Dev mailling l
I think the main reason is that WS-Notification is part of the WS-* area.
It's just that CXF may be a more intuitive place for such a codebase.
The current implementation rely on JBI, so ServiceMix was definitely a good
place. If we get rid of the JBI dependency to move to a pure JAX-WS
service,
Recently I always encounter a "Unexpected end of file from server" Exception at
CXF client side. it seems this exception is caused by the CXF Serverside has
unexcepted release the http connection ;
I tried some effort to to use a simple test case to regenerate such a
exception; Following is
I definitely support this and kind of thought about doing this last year
sometime to make it more usable outside of SMX.
Not sure where in the code though.
In reality, it's really not much different than an STS. For 2.4, we did put a
sample STS in the examples with most of the framework p
Hi CXF guys,
I would like to introduce a new CXF transport that we've developed and
that could be contributed back to the CXF community. It is called
"Reliable JMS transport"
When this transport has been designed, the goal was to have a reliable
transport that we could called "Enterprise
I'm confused. If you use AMQ configured for reliable storage on disk,
how do you lose things with the existing CXF transport?
On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT wrote:
> Hi CXF guys,
>
> I would like to introduce a new CXF transport that we've developed and that
> could be contribu
Hi,
One example about the "reliable" stuff is that we should include "recovery".
For example the correlation map used to match JMS replies is stored in
memory [1]
341 Exchange exchange = correlationMap.remove(correlationId);
342 if (exchange == null) {
343 LOG.log(Level.WARNING, "C
Hi,
I'm not sure of the exact requirements in ServiceMix, in any case I
suggest evaluating the WS-Eventing spec from WS-ResourceAccess
http://www.w3.org/2002/ws/ra/ which is at CR level atm and is being
finalized *really* soon.
Cheers
Alessio
On 07/08/2011 11:36 AM, Freeman Fang wrote:
> Hi Team,
We're not talking about implementing something new here. We have an
existing code base in ServiceMix that we may work on to remove the ties onto
JBI. We were just wondering if CXF would be a better place for it. I have
really no problems with keeping it in ServiceMix fwiw.
Now if someone wants
I've gone ahead and started the 2.5 migration guide:
https://cwiki.apache.org/confluence/display/CXF20DOC/2.5+Migration+Guide
don't forget to fill in things as you work on it. :-)
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
JMS would probably be the only real way to do this.
I think this is a very good idea to remove the JBI dependency in WSN. That
would make it much more usable.
Yes... I have had more than a couple of clients asking for a full WSN
implementation in CXF. So I would believe there is interest out
On Jul 8, 2011, at 7:47 AM, Guillaume Nodet wrote:
> We're not talking about implementing something new here. We have an
> existing code base in ServiceMix that we may work on to remove the ties onto
> JBI. We were just wondering if CXF would be a better place for it. I have
> really no probl
Yes request / response correlation is definately a place where we
currently loose message when the client goes down.
I think this is o big issue though as you typically only use request
response when you wait for the response. So normally you will even want
the responses to be lost when the cl
Hi Ryan
I'll try to reply asap. Please, make sure you can deploy a live CXF
JAXWS EJB endpoint and proceed further with your investigations re
JAXRS... Looks like you are getting real close...
thanks, Sergey
On Fri, Jul 8, 2011 at 3:56 AM, Ryan Zoerner wrote:
> There was a bit of a typo:
>
>
That's a bit harsh. It is functional and implements all the required bits
afaik. There are some missing stuff such as complex topics expressions
though.
Most of the problem come from WS-Addressing: it is heavily used in
WS-Notification, but given the component was designed to work inside the JB
Oh its not meant to be harsh... please don't take it personally... ;-) I am
well aware of its implementation since we dissected the heck out of it ;-) You
also seem to be aware of its issues too from your response below ;-)
We tried to leverage it on a project that needed to make extensive use
Then I think we are in agreement. All the code related to ws-addressing
support in WS-Notification would have to be rewritten when getting rid of
JBI.However, if you were talking about CXF interceptors, I'm not sure
that's the right way to go, as implementing a web service purely using
interce
I stated interceptors just because the CXF's architecture is wrapped around
that (no pun intended) ;-)
But plugability will be important or at least an API with hooks would work.
This way someone can use Camel or roll their own implementation, and we can let
CXF just care about the WSDL-Java w
Hi
I've helped to do this new transport, so let me add my 2 cents ;)
If the message exchange pattern is one way, there is no problem as no one
expects an answer.
But that new transport support the request-response pattern.
That means that we have to manage reliabiilty of the call end to end, fro
20 matches
Mail list logo
