Handling connection problems in WS-RM
When WS-RM is in use, some types of intermittent problems need to be handled by the WS-RM code without any impact on the application. These include all types of connection problems (after the initial WS-RM connection which establishes a Sequence), both where there's an actual I/O error in making a connection or getting a response, and where an incomplete message is received. One way of handling connection problems would be to use special handling in the transports, to catch and basically ignore exceptions when WS-RM is engaged. That's messy, with a lot of special case code. It seems like a simpler alternative would be to just always decouple the WS-RM send from the client request processing (or server response processing), basically treating everything as though it were a retransmission. That way the retransmit logic can just ignore any exceptions and continue on its way. Does that make sense? Handling incomplete receive messages looks more involved. There are many places in the code where XMLStreamException is caught and converted into a Fault. I suppose I'd need to intercept the Fault handling and look at whether the Fault was internally generated or received from the other endpoint, and only pass those received from the other endpoint on to the application. Is there any easy way I can tell? Thanks for any suggestions, - Dennis
Re: When do we drop Java 5 support?
Well, older versions of CXF--2.3.x and earlier--of course would perpetually support JRE 5.0. It's just a question of moving forward, it looks like right now 2.4 will still support 5.0 and maybe we'll switch to 6.0 minimum in CXF 2.5. I didn't know about royalty concerns (do you have a link for that--can't immediately find anything off Google), but I'm sure there would also be some fears of running on an unmaintained JRE. Although some wish/need to remain on JRE 5.0 (and hence CXF 2.3), there's also a counterargument, that for information security reasons, newer releases of CXF shouldn't allow itself to be run on unmaintained JRE's, similar to the way responsible builders will not put up homes on unsafe land/foundations even if business is lost as a result. Glen On 2/22/2011 9:27 PM, Fred Dushin wrote: Speaking from the field, you do not want to drop 1.5. There are organization out there that are not moving to 1.6 (or are moving very slowly) out of fear of Oracle's collecting royalties under the 1.6 redistribution terms. CXF is meant to be an embedded library. If you drop support for 1.5, you will find users who will not upgrade. At a minimum, CXF should support 1.5 on one of its branches. Not everyone out there has the luxury of being on the bleeding edge. -Fred On Feb 22, 2011, at 11:17 AM, Daniel Kulp wrote: On Tuesday 22 February 2011 3:45:44 AM Christian Schneider wrote: Hi all, now that camel dropped Java 5 I am asking myself when will we also drop support for Java 5 in CXF? As CXF 2.4.0 allows some bigger changes than a minor version we could do that in my opinion. Well, I guess the question is: what is the cost of supporting Java 5 compared to the cost of dropping it? For Camel, the cost was pretty high as they had some dependencies for various components that required Java6. Thus, you really couldn't do complete Camel builds with Java5 anyway. CXF is a bit different. RIGHT NOW, we don't have anything anyplace that requires Java 6. In generaly, the only "cost" we have is the occasional @Override annotation that Eclipse likes to stick on everything causing a Jenkins build break and some slight additional complexity in the poms. Thus, the cost of supporting Java5 for us is pretty low, right now. Dropping support for Java5 would cause issues with SOME people, especially those trying to use CXF in some of the older App servers.Also, to be honest, the new JAX-WS and JAXB 2.2 stuff in CXF works a TON better with Java5 than with Java6 due to the endorsed crap.Dropping support for Java5 would mean much of the JAXWS 2.2/JAXB 2.2 would not be tested on a day to day basis as that stuff is currently only tested when run on Java5.Thus, there is a big cost of dropping it just from a testing and support standpoint. Getting that stuff to run on Java6 properly would likely require a lot more configuration in the poms, updates to our plugins, likely updates to some of the Maven plugins, etc Basically, it's not easy. Thus, in my opinon, I don't think *right now* is the right time to drop support for Java 5. Maybe for 2.5, but likely not for 2.4. That said, I could potentially be convinced either way. :-) -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: Handling connection problems in WS-RM
On Wednesday 23 February 2011 5:11:27 AM Dennis Sosnoski wrote: > When WS-RM is in use, some types of intermittent problems need to be > handled by the WS-RM code without any impact on the application. These > include all types of connection problems (after the initial WS-RM > connection which establishes a Sequence), both where there's an actual > I/O error in making a connection or getting a response, and where an > incomplete message is received. > > One way of handling connection problems would be to use special handling > in the transports, to catch and basically ignore exceptions when WS-RM > is engaged. That's messy, with a lot of special case code. It seems like > a simpler alternative would be to just always decouple the WS-RM send > from the client request processing (or server response processing), > basically treating everything as though it were a retransmission. That > way the retransmit logic can just ignore any exceptions and continue on > its way. Does that make sense? Sure. > > Handling incomplete receive messages looks more involved. There are many > places in the code where XMLStreamException is caught and converted into > a Fault. I suppose I'd need to intercept the Fault handling and look at > whether the Fault was internally generated or received from the other > endpoint, and only pass those received from the other endpoint on to the > application. Is there any easy way I can tell? On the server side, when the fault is thrown, the "type" of the Fault is recorded on the message. See: org.apache.cxf.message.FaultMode That allows us to figure out the right way to handle things. We probably should do something similar on the Client side. If the exception is thrown from the ClientFaultConverter or Soap1?FaultInInterceptor's, it should probably set a FaultMode on the message that reflects that it came from the other side of the wire.That would keep it consistent on client and server side... Actually, looking at ClientFaultConverter, it seems to already be done. If the FaultMode is UNCHECKED_APPLICATION_FAULT or CHECKED_APPLICATION_FAULT, it would be from the other side (and would depend on if it's wsdl defined or not). If it's not one of those or is unset, it would be a local generated fault. Does that help? -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: LogBrowser project is on the trunk
Hi Tomasz - I've seen you doing a bunch of fixes - thanks a million. I'm going to start focusing on the browser too very soon - just finalizing the last few improvements for the transformation feature. Hope we'll get the shiny log browser ready in time for 2.4.0 :-) talk to you later Sergey On Thu, Feb 17, 2011 at 11:34 AM, Sergey Beryozkin wrote: > Hi Tomasz > > 1. LogBrowser has a showstopper bug which I'm sure is due to the fact we > just did not look at it for a while :-). Basically, when I go and generate > the logs, and then click 'refresh' on the endpoint, the browser reports an > exception. >> >> I can't reproduce this (however it doesn't mean that there isn't bug ;) ). >> >> To solidify my understanding, use case: >> >> 1) Run 'logbrowser' through sample; >> 2) Go to 'http://localhost:9002/log/browser/LogBrowser.html'; >> 3) Add new endpoint with URL 'http://localhost:9002/log/logs'; >> 4) Select newly created endpoint; >> 5) In new tab open 'http://localhost:9002/customer-service.html' and >> add few 'customers'; >> 6) Go back to 'logbrowser'; >> 6) Click 'refresh' link; >> >> Expected: >> List is refreshed and new items are shown. >> >> Environment: >> Firefox 3.6.x >> >> Is this use case correct? Thanks for your help. >> > > It is, I'll try again asap - definitely looks like a platform/browser > specific issue, it's Ubuntu 9 + FireFox 3.6.13 which I upgraded to > recently using the apt-get facility...So I'm not worried really then, > but I'll try again, and on Windows too... > >> Maybe try with force refresh (i.e. "Ctrl + R"). However I have to add >> revision number to static resources URL to avoid cache problems. >> >>> this is is the only main issue at the moment > > 2. Please move ManageEndpoints button either immediately above or below > the > Filter button You mean something similar to "original" layout - "Manage endpoint" is "attached" to the bottom of the page? >>> >>> I'm thinking that given we have a Filter button in the bottom of the >>> left-side pane, it would be ok to have both 'Manage Endpoints' and >>> 'Filters' co-located... >>> > 3. Remove the Tasks and Endpoints buttons/entries, lets have it the way > you > did it originally. We only need to see the list of endpoints which will > be > added via "ManageEndpoints", the explorer style is just too complex. > > 4. When I go to ManageEndpoints, "Sign Out" leaks into the new panel and > overlaps with the "Settings" entry, >> >> Fixed. > > Super > >> Looks like 2, 3, 4 are layout problems... I have to clean up this. At the moment we are using mix of CSS and "table layout". I'm not CSS expert so I will fix it by moving problematic parts to "table layout". >> >> I noticed that when you use latest Chrome or Safari, list of logs and >> detailed view isn't shown. I consider this as a blocker. I will >> prepare fix for this ASAP. > > May be it's somehow related to what I see with the application > exception above... > > What I will need to do is to provide an abstract utility > ReadableStorage implementation which can be easily overridden to have > the file-based logs viewable. I don't think we can make LogBrowser > perfect and feature-complete by the 2.4.0 is released, but hope users > will give it a try anyway... > > Few other "would be nice to fix" issues - definitely not show stoppers : > - LogBrowser has the 'embedded' providers, one for servicing the > gzipped file and another one for unqualified JSON, this would be nice > to move to the demo's Application (JSONProvider can be configured > directly to drop the namespaces) - I can look into it > - Authentication: I've noticed there's AuthenticationRequired > annotation attached to some of the BootstrapStorage methods - we > really need to remove this annotation and for now just pop-up a login > window on the browser start-up. > Users will be configuring the LogBrowser application as part of the > real deployments. So what would be good is to write the GWT client > code such that it only pops up a window when the initial GET returns > 401 - can you use CXF WebClient there and do 'Response r = > webClient.get()' and if r.getStatus() == 401 then pop-up a login > dialog ? We can deal with this issue later, when we have more time, > and then we'll also decide whether to support https in cases when the > authentication is needed or may be do the UT profile, we'll see... > > Thanks, Sergey. > >> >> -- >> Best regards, >> Tomasz Oponowicz >> >
Re: Handling connection problems in WS-RM
On 02/24/2011 04:47 AM, Daniel Kulp wrote: > On Wednesday 23 February 2011 5:11:27 AM Dennis Sosnoski wrote: > > >> Handling incomplete receive messages looks more involved. There are many >> places in the code where XMLStreamException is caught and converted into >> a Fault. I suppose I'd need to intercept the Fault handling and look at >> whether the Fault was internally generated or received from the other >> endpoint, and only pass those received from the other endpoint on to the >> application. Is there any easy way I can tell? >> > ... > Actually, looking at ClientFaultConverter, it seems to already be done. If > the FaultMode is UNCHECKED_APPLICATION_FAULT or CHECKED_APPLICATION_FAULT, it > would be from the other side (and would depend on if it's wsdl defined or > not). If it's not one of those or is unset, it would be a local generated > fault. > > > Does that help? > Sounds good. I'll give it a try and see how it works out. Thanks! - Dennis
[VOTE] Apache CXF 2.3.3
We've resolved over 50 issues since 2.3.2. Thus, we really should get 2.3.3 out, especially since 2.3.2 contained an issue preventing it from being used as a JAX-WS implementation for J2EE containers. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 The Maven staging areas are at: https://repository.apache.org/content/repositories/orgapachecxf-044/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 This vote is likely to be open until Monday as I'll be out of town. If any issues arise, please email me directly. Here is my +1. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com signature.asc Description: This is a digitally signed message part.
Re: [VOTE] Apache CXF 2.3.3
+1 thanks, Sergey On Wed, Feb 23, 2011 at 8:30 PM, Daniel Kulp wrote: > > > We've resolved over 50 issues since 2.3.2. Thus, we really should get 2.3.3 > out, especially since 2.3.2 contained an issue preventing it from being used > as a JAX-WS implementation for J2EE > containers. > > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 > > The Maven staging areas are at: > https://repository.apache.org/content/repositories/orgapachecxf-044/ > > The distributions are in: > https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 > > > This vote is likely to be open until Monday as I'll be out of town. If any > issues arise, please email me directly. > > > Here is my +1. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com >
Re: [VOTE] Apache CXF 2.3.3
+1 On Wed, Feb 23, 2011 at 6:04 PM, Sergey Beryozkin wrote: > +1 > > thanks, Sergey > > On Wed, Feb 23, 2011 at 8:30 PM, Daniel Kulp wrote: >> >> >> We've resolved over 50 issues since 2.3.2. Thus, we really should get >> 2.3.3 out, especially since 2.3.2 contained an issue preventing it from >> being used as a JAX-WS implementation for J2EE >> containers. >> >> >> List of issues: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 >> >> The Maven staging areas are at: >> https://repository.apache.org/content/repositories/orgapachecxf-044/ >> >> The distributions are in: >> https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ >> >> This release is tagged at: >> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 >> >> >> This vote is likely to be open until Monday as I'll be out of town. If any >> issues arise, please email me directly. >> >> >> Here is my +1. >> >> >> -- >> Daniel Kulp >> dk...@apache.org >> http://dankulp.com/blog >> Talend - http://www.talend.com >> > -- Principle Technical Writer Phone (781) 280-4174 Skype finnmccumial E-Mail emjohn...@fusesource.com Blog http://documentingit.blogspot.com/
Re: [VOTE] Apache CXF 2.3.3
+1, -- Ulhas Bhole On 23 Feb 2011, at 20:30, Daniel Kulp wrote: > > > We've resolved over 50 issues since 2.3.2. Thus, we really should get 2.3.3 > out, especially since 2.3.2 contained an issue preventing it from being used > as a JAX-WS implementation for J2EE > containers. > > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 > > The Maven staging areas are at: > https://repository.apache.org/content/repositories/orgapachecxf-044/ > > The distributions are in: > https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 > > > This vote is likely to be open until Monday as I'll be out of town. If any > issues arise, please email me directly. > > > Here is my +1. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog > Talend - http://www.talend.com
Re: [VOTE] Apache CXF 2.3.3
+1 On Thu, Feb 24, 2011 at 9:47 AM, UlhasBhole wrote: > +1, > > -- Ulhas Bhole > On 23 Feb 2011, at 20:30, Daniel Kulp wrote: > >> >> >> We've resolved over 50 issues since 2.3.2. Thus, we really should get >> 2.3.3 out, especially since 2.3.2 contained an issue preventing it from >> being used as a JAX-WS implementation for J2EE >> containers. >> >> >> List of issues: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 >> >> The Maven staging areas are at: >> https://repository.apache.org/content/repositories/orgapachecxf-044/ >> >> The distributions are in: >> https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ >> >> This release is tagged at: >> http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 >> >> >> This vote is likely to be open until Monday as I'll be out of town. If any >> issues arise, please email me directly. >> >> >> Here is my +1. >> >> >> -- >> Daniel Kulp >> dk...@apache.org >> http://dankulp.com/blog >> Talend - http://www.talend.com > >
AW: [VOTE] Apache CXF 2.3.3
+1 Christian -Ursprüngliche Nachricht- Von: Daniel Kulp [mailto:dk...@apache.org] Gesendet: Mittwoch, 23. Februar 2011 21:31 An: dev@cxf.apache.org Betreff: [VOTE] Apache CXF 2.3.3 We've resolved over 50 issues since 2.3.2. Thus, we really should get 2.3.3 out, especially since 2.3.2 contained an issue preventing it from being used as a JAX-WS implementation for J2EE containers. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 The Maven staging areas are at: https://repository.apache.org/content/repositories/orgapachecxf-044/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 This vote is likely to be open until Monday as I'll be out of town. If any issues arise, please email me directly. Here is my +1. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [VOTE] Apache CXF 2.3.3
+1 - Dennis On 02/24/2011 09:30 AM, Daniel Kulp wrote: > > We've resolved over 50 issues since 2.3.2. Thus, we really should get 2.3.3 > out, especially since 2.3.2 contained an issue preventing it from being used > as a JAX-WS implementation for J2EE > containers. > > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 > > The Maven staging areas are at: > https://repository.apache.org/content/repositories/orgapachecxf-044/ > > The distributions are in: > https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 > > > This vote is likely to be open until Monday as I'll be out of town. If any > issues arise, please email me directly. > > > Here is my +1. > > >
Re: [VOTE] Apache CXF 2.3.3
+1 Freeman On 2011-2-24, at 上午4:30, Daniel Kulp wrote: We've resolved over 50 issues since 2.3.2. Thus, we really should get 2.3.3 out, especially since 2.3.2 contained an issue preventing it from being used as a JAX-WS implementation for J2EE containers. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310511&version=12316073 The Maven staging areas are at: https://repository.apache.org/content/repositories/orgapachecxf-044/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-044/org/apache/cxf/apache-cxf/2.3.3/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.3.3 This vote is likely to be open until Monday as I'll be out of town. If any issues arise, please email me directly. Here is my +1. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Freeman Fang FuseSource: http://fusesource.com blog: http://freemanfang.blogspot.com twitter: http://twitter.com/freemanfang Apache Servicemix:http://servicemix.apache.org Apache Cxf: http://cxf.apache.org Apache Karaf: http://karaf.apache.org Apache Felix: http://felix.apache.org
