hi Anne,
Thx for your answer.
But with your approach the problem remains the same: the proxies will still
get dynamically generated at-runtime. And that is what i want to avoid by
generating (and packaging) the proxy code at development time.
g
-wil-
Diefenbach Anne wrote:
Hi,
unless I
Hi,
Know you guys have been up to your neck with the release of 2.1.4 but anyone
get a chance to have a look into this?
Thanks,
Adrian
On Thu, Feb 5, 2009 at 10:10 AM, Adrian C adrian.corco...@gmail.com wrote:
actually what I am saying about a difference in behaviour between JMS
HTTP
may
Admittedly I'm more of a server-side guy, but when I had a go at
building a client following Glen's excellent tutorial here:
http://www.jroller.com/gmazza/entry/creating_a_wsdl_first_web1
I'm 99.99% sure all the proxy interfaces and classes were generated at
build time. Try following that guide
Hi wil,
I'm still pretty new to all of this too, so maybe I didn't quite understand
your problem. I assumed that your proxy code was the service interface, and
that you wanted to avoid calling wsdl2java every time. In this case, generating
everything once, putting it in a JAR and deleting the
Hi Anne,
thx for clearing that out.
Your answer was helpfull actually but i allready did that stuff and it works
fine.
As i said in my first email, i simply want to avoid at-runtime
proxy-implementation code generation.
g
Diefenbach Anne wrote:
Hi wil,
I'm still pretty new to all of
I'll check that one out. thx Andrew.
Andrew Clegg-2 wrote:
Admittedly I'm more of a server-side guy, but when I had a go at
building a client following Glen's excellent tutorial here:
http://www.jroller.com/gmazza/entry/creating_a_wsdl_first_web1
I'm 99.99% sure all the proxy
I have a service that returns a list of images. It seems to work, but when
the images are too big or there are several images I don't get all images,
just some of them.
From the server side I get this messages
Outbound Message
---
Encoding: UTF-8
Headers: {}
Messages:
How about using one single wsdl:fault with the specific fault string and
detail set?
This would mean the client always gets a fault in case of failure. At the
same time -
- Keeps the application simple - Not too many faults
- For a new error on the server, the wsdl still remains same, client
Hello
I use a single soap fault type, with integer code and string message. String
message is only meant for debugging, and usually contains exception message (or
class name), including messages of nested exceptions. Integer codes roughly
correspond to HTTP error codecs, and determine error
It should be unlimitted already.What you are seeing is the Logging
interceptor truncating what it logs to the logger to avoid the logger sucking
everything into memory and taking down the server with OOM type issues. That
shouldn't be affecting what gets sent back to the client.
Can
Basically, if you set all the conduit properties ONCE up front and also don't
use http sessions and all use either http or https, but not both, then you can
do this. Do:
((BindingProvider)proxy).getRequestContext().put(thread.local.request.context,
true);
as part of the setup. That will
OK, but what do you do if there is *no* error and the database action
occurred--return nothing, or return a string that just says OK?
I like the elegance of using a wsdl:fault for errors, but I was assuming I
should still return something on success, and given that I going to be
returning a
I'm not a fan of WSDL faults except for web-service specific problems.
Here's why. Often, I find that the code that I want to call via a web
service today I want to call directly tomorrow. Given that faults rarely map
quite precisely to exceptions, I'd build errors like this into the protocol
and
If no error occurred, then in java the web method returns void, which in WSDL
means it returns an empty complex type.
You should not throw faults for ok conditions.
Jaro
Glen Mazza schrieb:
OK, but what do you do if there is *no* error and the database action
occurred--return nothing, or
(Thanks Benson and Bharath for your suggestions.)
Jaro, just to clarify, when you say a single soap fault type do you mean
you throw a SOAPFaultException (which is not defined within the WSDL) or is
it a single wsdl:fault defined in the WSDL? I guess it really doesn't
matter, but just want to
Tried with both CXF 2.0.9 and 2.1.3:
I need to send payload that is XML. When I do, the content is encoded (i.e.
all '' are replaced with lt;, '' with gt; etc.), and the server throws
an exception because it doesn't expect payload to be encoded. I verified
that using soapui which sends the pure
16 matches
Mail list logo
