jboss50 excludes
by Heiko Braun
I see a bunch of jboss50 excludes that go back to really old issues.
What's the status of this? Shouldn't the JIRA's be re-opened for them?
org/jboss/test/ws/jaxrpc/jbws124/JBWS124TestCase.*
org/jboss/test/ws/jaxrpc/jbws128/JBWS128TestCase.*
org/jboss/test/ws/jaxrpc/jbws153/JBWS153TestCase.*
/Heiko
16 years, 7 months
Re: Amberpoint patch
by Thomas Diesler
Hi Darran,
please use
https://svn.jboss.org/repos/jbossws/stack/native/branches/jbossws-native-...
this is the branch that will contain commulative patches to the
jbossws-2.0.1 code base. Currently (-r 4653) this is identical to the
taged jbossws-2.0.1.SP1
cheers
-thomas
On Fri, 2007-09-28 at 16:06 +0100, Darran Lofthouse wrote:
> What is the reason we have gone the SP route? My understanding of SP
> releases is they are still primarily community releases - in this case
> the releases are only for the platform so should be CP releases.
>
> I should have some time to look into this, I will just need to run it
> past Francois first.
>
> Do you have hardware that I will be able to access to run the Hudson
> builds? Using my own laptop would tie it up for quite a while.
>
> Is it also time to bring up the discussion of the productisation team
> handling the QA and release / tagging of JBossWS again for platform
> builds - last time I brought up this discussion it was confirmed to me
> that all of this would be handled by R+D but it doesn't look like this
> is the case at the moment.
>
> --
>
> Regards,
> Darran Lofthouse.
>
> Senior Software Maintenance Engineer
> JBoss, a division of Red Hat
>
>
>
> On Fri, 2007-09-28 at 13:54 +0200, Thomas Diesler wrote:
> > In that case we need to do a SP2.
> >
> > Darran could you take care of that?
> >
> > cheers
> > -thomas
> >
> > On Fri, 2007-09-28 at 12:42 +0100, Mark Little wrote:
> > > Unfortunately not. We're need to release WS 2.0.1SPX GA into the
> > > platform asap; we need something that addresses the Amberpoint patch
> > > and the backward compatibility issues between 2.0.0GA and 2.0.1GA
> > > within the next two weeks. Isn't that possible?
> > >
> > >
> > > Mark.
> > >
> > >
> > >
> > > On 28 Sep 2007, at 12:34, Thomas Diesler wrote:
> > >
> > > > jbossws-2.0.1.SP1 has been release already
> > > >
> > > >
> > > > jbossws-2.0.2.GA will come out 1-Nov-2007. Is this soon enough?
> > > >
> > > >
> > > > -thomas
> > > >
> > > >
> > > > On Fri, 2007-09-28 at 10:37 +0100, Mark Little wrote:
> > > > > We're going to have to go with JBossWS 2.0.1GA with a new service
> > > > > pack
> > > > > from Thomas/Heiko to fix some backward compatibility issues. So
> > > > > can we
> > > > > back port into that once Thomas makes it available to you?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Mark.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 28 Sep 2007, at 10:17, Darran Lofthouse wrote:
> > > > >
> > > > >
> > > > > > Yes I did get this, however I was still on holiday yesterday.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > As I said to the 'jboss-esip-pm-list(a)redhat.com' list on the
> > > > > > 13th
> > > > > > September there is one issue
> > > > > > http://jira.jboss.com/jira/browse/JBWS-1792
> > > > > > that is not included until 2.0.2 which has not yet been released
> > > > > > -
> > > > > > Amberpoint require this fix.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Before the 2.0.2 release at the very least the same fix for
> > > > > > JAX-WS
> > > > > > should be made http://jira.jboss.com/jira/browse/JBWS-1794.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > If we go with 2.0.1 we will just need to back port one fix and
> > > > > > have
> > > > > > a CP
> > > > > > version of JBossWS.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Darran Lofthouse.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Senior Software Maintenance Engineer
> > > > > > JBoss, a division of Red Hat
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, 2007-09-27 at 13:47 +0200, Thomas Diesler wrote:
> > > > > > > Hi Darran,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > did you get this?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 2007-09-27 at 10:28 +0200, Thomas Diesler wrote:
> > > > > > > > No, lets ask again.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Darran, do you know if the Amberpoint patch is included in
> > > > > > > > 2.0.1.GA?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > cheers
> > > > > > > > -thomas
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, 2007-09-26 at 10:11 +0100, Mark Little wrote:
> > > > > > > > > Thomas, did you get anything back from support about this
> > > > > > > > > and
> > > > > > > > > JBossWS
> > > > > > > > > 2.0.1?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Mark.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ----
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Mark Little
> > > > > > > > > mlittle(a)redhat.com
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > JBoss, a Division of Red Hat
> > > > > > > > > Registered Address: Red Hat UK Ltd, Amberley Place,
> > > > > > > > > 107-111
> > > > > > > > > Peascod
> > > > > > > > > Street, Windsor, Berkshire,
> > > > > > > > > SI4 1TE, United Kingdom.
> > > > > > > > > Registered in UK and Wales under Company Registration No.
> > > > > > > > > 3798903
> > > > > > > > > Directors: Michael Cunningham (USA), Charlie Peters (USA)
> > > > > > > > > and
> > > > > > > > > David
> > > > > > > > > Owens (Ireland)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > ----
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Mark Little
> > > > > mlittle(a)redhat.com
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > JBoss, a Division of Red Hat
> > > > > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111
> > > > > Peascod
> > > > > Street, Windsor, Berkshire,
> > > > > SI4 1TE, United Kingdom.
> > > > > Registered in UK and Wales under Company Registration No. 3798903
> > > > > Directors: Michael Cunningham (USA), Charlie Peters (USA) and
> > > > > David
> > > > > Owens (Ireland)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > --
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > > Thomas Diesler
> > > > Web Service Lead
> > > > JBoss, a division of Red Hat
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > ----
> > >
> > >
> > > Mark Little
> > > mlittle(a)redhat.com
> > >
> > >
> > > JBoss, a Division of Red Hat
> > > Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> > > Street, Windsor, Berkshire,
> > > SI4 1TE, United Kingdom.
> > > Registered in UK and Wales under Company Registration No. 3798903
> > > Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
> > > Owens (Ireland)
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 7 months
Documentation
by Alessio Soldano
Hi,
I noticed that some users on the forum still don't get the advantages of
using jax-ws instead of jax-rpc, so I tried to summarize them a bit and
wrote them in the wiki. In case someone would like to fix something or
contribute, the url is
http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_vs_JAX-RPC (you
can reach this also from the FAQ).
While writing that page, I found a performance analysis that compares
jax-ws and jax-rpc using the Sun's WSTest project on Glassfish:
http://java.sun.com/developer/technicalArticles/WebServices/high_performa...
Do you think this also could be useful and might be linked in the
comparison page?
Actually I saw a page on the wiki about performance analysis, but as far
as I see it's related to jbossws 1.2 only...
Cheers
Alessio
16 years, 7 months
Re: Fault handling for XTS over JaxWS
by Thomas Diesler
Hi Andrew,
sorry for being so strict - private email is not a valid communication
channel. It does not reach all people who might have valuable input, it
does not scale and it is no good for building up our knowledge base.
Please post your questions to the dev or user forum.
http://www.jboss.org/index.html?module=bb&op=viewforum&f=174
If it is a bug, we need a jira issue that we can schedule and fix
appropriately.
cheers
-thomas
On Sat, 2007-09-22 at 20:28 +0100, Andrew Dinn wrote:
> Hi Thomas,
>
> I am aware of the existence of the JaxWS sample programs and how they
> behave. I emailed you in order to elicit i) your interpretation of the
> JaxWS 2.0 spec and ii) an explanation of why your latest JaxWS
> implementation is behaving the way it does with *my* test program. Your
> unit tests do indeed exercise the code which handles client and
> server-side exceptions. However, they do not correspond to the case I am
> faced with and do not resolve the question I am asking. Perhaps you
> would allow me to explain once again what is at stake.
>
> I am currently trying to make the JBossTS XTS implementation operate
> over your JBossWS native soap stack rather than employ Kevin Connor's
> home-grown soap stack. I am hoping to be able to use JaxWS for this
> purpose, generating the server and client code from the WSDL. I face an
> interesting challenge because, for example, the WSCOOR 1.0 WSDL employs
> several pairs of related *one-way* methods with no fault handling
> defined i.e. the pairs of WSDL operations specify an <input/> message
> but no <output/> and no <fault/> message. In order to interoperate with
> other implementations I must conform to the WSDL defined by the WSCOOR
> protocol. I am not at liberty to add my own fault messages to the WSDL.
> Nor am I at liberty to add extra operations in order to notify faults.
>
> When I generate the interface and server stub code the corresponding web
> methods are tagged with an @OneWay annotation. My question regarding the
> spec is very simple: what is meant to happen if the implementation of
> such a one way method throws a SoapFaultException, a ProtocolException
> or some other Exception? Is the JaxWS implementation supposed to throw a
> corresponding exception in the client context? The sections of the spec
> I cited in my original post do not make the answer clear.
>
> I note that your tests are not tagged with the @OneWay annotation so
> they do not exercise this particular case (your code handles these cases
> differently as I explain below).
>
> I also note that when I ran a test to identify your current
> implementation it did not generate a client side exception for this
> case. However, having looked at the code I did not think that indicated
> a clear decision not to throw an error.
>
> On the server side i) the connection is maintained while the service
> method is executing ii) any exception thrown by the implementing method
> is caught and wrapped up into a soap fault and iii) the fault is
> serialized into the return stream for the connection.
>
> The current client side implementation does read this returned data
> although, due to a rather weird implementation of the read method in the
> remoting layer, the data gets truncated. I assumed this was an error and
> patched it so that the full message was read but it makes no difference
> to the outcome. When setting up the one way call your code always
> installs an http unmarshaller on the stream rather than a soap message
> unmarshaller. Clearly, whether this is correct or not depends upon the
> interpretation of the spec.
>
> So, I would be grateful if you could let me know what you think the spec
> intends should happen in this case. If an exception is supposed to be
> propagated back to the client, I will be glad to file JIRAs detailing
> the failure to do so.
>
> regards,
>
>
> Andrew Dinn
> -----------
>
>
> Thomas Diesler wrote:
> > Hi Andrew,
> >
> > you can start with the working exception samples that we ship with the
> > distribution. Additionally, our test suite contains test cases that deal
> > with exceptions.
> >
> > You can send questions regarding WS support to: support-ws(a)jboss.com
> >
> > cheers
> > -thomas
> >
> > On Fri, 2007-09-21 at 10:51 +0100, Andrew Dinn wrote:
> >> Hi Jonathan,
> >>
> >> I'm copying this to Thomas for his advice regarding how JaxWS should
> >> handle exceptions thrown by service endpoint implementation code. If he
> >> thinks the problems I am encountering with the current implementation
> >> are bugs I will be happy to raise JIRAs for them.
> >>
> >> Thomas, in case you are puzzled as to the context for this request for
> >> advice it relates to my current attempts to implement the XTS wscoord
> >> services and related wsat and wsba transaction management services over
> >> JaxWS. My previous correspondence with Jonathan is included at the
> >> bottom of this note for reference.
> >>
> >> I went through the JaxWS 2.0 spec in detail yesterday and I think the
> >> implementation is supposed to notify server-side faults to the client
> >> (specifically, SOAPFaultExceptions thrown by the service end point
> >> implementation) *even with one way messages*. The statements on
> >> exception handling are not explicit but they appear to include by
> >> default the case where there are no output messages and no specific
> >> fault messages defined for the operation in the WSDL. It also appears to
> >> be irrespective of whether a faultto endpoint address is supplied in the
> >> ws addressing props for the call.
> >>
> >> The specific points in the spec I am interpreting this way are section
> >> 4.4.4 (Remote Exceptions) and 6.4.1/6.4.2. It is not clear that this
> >> interpretation applies for one-way messages (the example in 6.4.1 is a
> >> message with response; 6.4.2 is rather cryptic). Section 5.1.1.1 appears
> >> to require that *all* protocol exceptions generated by Providers are
> >> transported back to the client and throw; it does not distinguish
> >> whether the MEP is one-way or request-response. Strangely, the following
> >> section detailing service endpoint implementations is silent on the
> >> question of exceptions. Perhaps Thomas could clarify this?
> >>
> >> I spent quite a few hours yesterday pinning down what the current
> >> (2.0.1) JaxWS implementation is doing in my test cases and it appears
> >> that there are several things stopping an exception being returned from
> >> a one way invocation. The problem is not as I feared that the connection
> >> is dropped before message processing completes. It is maintained beyond
> >> the point where the invocation completes/throws an error and a response
> >> is actually supplied after the return/throw. However, subsequent
> >> processing does not result in a client exception. Thomas might
> >> appreciate the following details.
> >>
> >> Firstly, the soap fault is encoded into the response stream without a
> >> content-length. The process of saving and marshalling the fault into the
> >> response stream is *very* convoluted -- employing three different
> >> message contexts and generating a series of (unnecessary?) soap
> >> messages, including multiple versions of the soap fault. However,
> >> eventually the appropriate fault content (a soap envelope) does get
> >> fully serialized.
> >>
> >> Secondly, the remoting code (in HTTPUnMarshaller.read) fails to read the
> >> full reply from the stream. When a content-length property is not
> >> provided it takes one bite of the apple then decides there can be no
> >> more data even though there are more available bytes on the input
> >> stream. For some reason the read operation only returns the first 28
> >> bytes of just over 200 that are available. I patched this method so that
> >> in the absence of a content-length it reads until available() indicates
> >> no more data is present. With this fixed it does obtain a complete SOAP
> >> envelope -- as a string, not as a soap fault instance.
> >>
> >> Thirdly, the response data is not processed as a fault -- this contrasts
> >> with the request-response case where the reply *is* processed and a
> >> fault is generated. This appears to relate to the fact that the
> >> receiving message context has property NoThrowOnFault set. This property
> >> is added to the context at request dispatch for both one-way and
> >> request-response MEPs and I don't know why it gets ignored in the one
> >> way case but not in the other case. Maybe because the attempt to
> >> deserialise an object from the message data goes ahead anyway when there
> >> is a response to return?
> >>
> >>
> >> regards,
> >>
> >>
> >> Andrew Dinn
> >> -----------
> >>
> >> Jonathan Halliday wrote:
> >>> This seems like a generic problem with JAX-WS: if you choke whilst
> >>> processing a one-way message, how do you send a fault back, since the
> >>> source is expecting only a response message.
> >>>
> >>> I guess you could dispatch the fault totally dynamically and just assume
> >>> the other end will know how to handle it, even though the generated code
> >>> implies otherwise.
> >>>
> >>> Or there is a faultto header I think, with the addressing rules causing
> >>> faultto to take priority over the replyto header if it's present. I
> >>> don't know how JaxWS handles that though.
> >>>
> >>> I'd probably write this up as a generic problem and put it on the
> >>> JBossWS forum, maybe someone with a good knowledge of JAX-WS has a
> >>> general solution to the issue.
> >>>
> >>> Failing that, just have the server fail silent, since it can't send a
> >>> fault notification. The existing retry-timeout approach should
> >>> eventually cause the client to report the abscence of a response as an
> >>> exception to its caller. This is not terribly friendly in terms of
> >>> interop with other implementations, but they should have handling in
> >>> place for stray messages too so I don't think it's that big a problem.
> >>>
> >>> Jonathan.
> >>>
> >>> Andrew Dinn wrote:
> >>>> Hi Jonathan,
> >>>>
> >>>> I am progressing on implementing the XTS 1.1 wscoor and wsat/ba
> >>>> services using JaXWs but I'm currently puzzling over notification of
> >>>> faults. There does not appear to be a problem with request-response
> >>>> style MEPs, rather with using one way invocations. The problem is
> >>>> really associated with 1.0 wscoor not 1.1 since the former is
> >>>> explicitly based on MEPS which employ related pairs of one way
> >>>> messages while the latter uses request-response. However, I am
> >>>> concerned that there may be issues to do with the 1.1 wsat and wsba
> >>>> since they also use one way invocations. I thought if I explained the
> >>>> problem you might be able to provide some guidance.
> >>>>
> >>>> An example of something which might cause problems would be the
> >>>> wscoor1.0 ActivationCoordinatorPortType and
> >>>> ActivationRequesterPortType exchange used to create and return the
> >>>> coordination context. Implementing this using JaxWS clients/services
> >>>> generated from the wsdl would require two services, an
> >>>> ActivationCoordinator service and an ActivationRequester service each
> >>>> of which provides an endpoint with a single invocable web method,
> >>>> CreateCoordinationContextOperation (CreateCCO) and
> >>>> CreateCoordinationContextResponseOperation (CreateCCRO), respectively.
> >>>>
> >>>> So, first off here is what *would* work in this scenario. Under
> >>>> UserTransaction.begin() the (local) client of ActivationCoordinator
> >>>> obtains a JaxWS proxy and invokes CreateCCO. Before invoking the
> >>>> service it sets the ws addressing messageid and replyto for the call
> >>>> to a unqiue id and the endpoint address of the local
> >>>> RegistrationCoordinator, respectively.
> >>>>
> >>>> When the ActivationCoordinator service receives the request it handles
> >>>> it by obtaining a JaxWS proxy for the RegistrationCoordinator service
> >>>> and invoking CreateCCRO. The service implementation method can detect
> >>>> the supplied addressing properties and use them to direct the
> >>>> CreateCCRO operation to the correct registration coordinator endpoint
> >>>> and to supply a relatesto header identifying the source messageid.
> >>>>
> >>>> This means that the client of ActivationCoordinator can sit in a wait
> >>>> queue (keyed by message id) pending wake up when the response is
> >>>> received by the RegistrationCoordinator service. All of this is
> >>>> feasible using generated service and client stubs and the generic ws
> >>>> addressing support in JaxWS. Note that JaxWS does not provide a way of
> >>>> associating these two calls other than enabling the messageid and
> >>>> relatesto to be set and retrieved. So, the wait and wake up has to be
> >>>> implemented outside of JaxWS.
> >>>>
> >>>> The problem is what to do if a fault happens during delivery or
> >>>> processing of the request. Note that this only arises when we are
> >>>> using one way messages. When processing messages which require a
> >>>> response JaxWS automatically detects and translates delivery errors or
> >>>> exceptions thrown by the service endpoint implementation into soap
> >>>> faults thrown in the original client context.
> >>>>
> >>>> With a one-way request if an error happens i) on the client side
> >>>> during initial processing of the message or ii) on the server side
> >>>> while while the incoming http connection is still open then a fault is
> >>>> also automatically thrown in the client. However, by the time SOAP
> >>>> handlers and/or the server endpoint call is reached the connection
> >>>> will have been closed and there is no way to propagate a fault
> >>>> directly back to the client.
> >>>>
> >>>> Unfortunately, using JaxWS there is no way to send a fault to the
> >>>> endpoint identified by the replyto header either. The
> >>>> RegistrationCoordinator service only implements a single operation,
> >>>> CreateCCRO, which delivers a coordination context response. This
> >>>> cannot be used to dispatch a soap fault. We could add an extra
> >>>> operation to the WSDL with a corresponding service implementation
> >>>> method but that would not be standard and so, would not inter-operate
> >>>> with other wscoor implementations
> >>>>
> >>>> By way of comparison, when Kev's code detects an error on the server
> >>>> side (for either a one-way or two-way message) it sends a fault back
> >>>> to the soap stack of the caller or, if address processing has
> >>>> progressed far enough, to the replyto soap stack. It can do this
> >>>> because it is managing the soap stack itself rather than calling via a
> >>>> proxy. It also gets away with this because the soap stack at the other
> >>>> end recognises the relatesto tag attached to the fault message and
> >>>> automatically wakes up the client and delivers the fault -- client
> >>>> suspension and wake-up for this type of MEP is implemented within
> >>>> Kev's soap stack.
> >>>>
> >>>> I am not yet sure what the implications of this are for the wsat and
> >>>> wsba exchanges. Some of the operations in the WSDLs are specified as
> >>>> one way messages although these mostly seem to operate as related
> >>>> pairs. Do you have any idea what the implications for fault handling
> >>>> are in these cases?
> >>>>
> >>>> regards
> >>>>
> >>>>
> >>>> Andrew Dinn
> >>>> -----------
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
16 years, 7 months
