It shouldn't be too hard to write some xslt to script the edit Dan suggests.
For the two errors you report, I think that the second requires -exsh (or
one one the other command-line args to the tool) and the other requires a
minimal import element that specifies the namespace but no system id.
A bit of googling got me nowhere here.
I want to publish a service on both a http: address and a local: address.
Two jaxws:endpoints? Can they point to the same #implementation bean?
yes they sure can - the only thing that you cannot do is have a parent jaxws
endpoint which the http/local/jms etc all inherit from which is a pity.
jaxws:endpoint name=LocalV1 address=local://LocalV1
implementor=#V1Impl wsdlLocation=META-INF/wsdl/Local_v1.wsdl
jaxws:endpoint
Server faults go into separate interceptor chains (second paragraph of
[1])--I have not done this before, but you should be able to reuse the
interceptors you have on your normal non-error chains for the error
situations.
HTH,
Glen
[1] http://cwiki.apache.org/CXF20DOC/interceptors.html
Am
Hey Glen,
Removing the s:schema from the WSDL seems to let wsdl2java work no
problem - i did some digging in the w3c schema and it appears that in
the s namespace, s:schema would point to the root node of the XSD -
which seems to be pretty bizarre. I was wondering if that was some
kind
hi all,
I'm writing a automated system for monitoring certain quality of service
properties (e.g., response time, etc) from a client-side perspective.
this works quite well as long as no fault occur on the service provider
that i'm trying to invoke. I use a couple of interceptors in the IN
Hey Daniel,
Thanks for your interesting reply.
Thus, to get it working for CXF, you would need to modify the schema
to
put the proper s:import in place to import the schema schema, then
include the binding file to deal with the duplicate classes.
Alternatively, use the workround on that
Am Mittwoch, den 09.04.2008, 10:21 +0100 schrieb Tim Perrett:
Hey Daniel,
Thanks for your interesting reply.
Thus, to get it working for CXF, you would need to modify the schema
to
put the proper s:import in place to import the schema schema, then
include the binding file to
hi glen,
Glen Mazza wrote:
Server faults go into separate interceptor chains (second paragraph of
[1])--I have not done this before, but you should be able to reuse the
interceptors you have on your normal non-error chains for the error
situations.
so you mean the FAULT chain? i've added my
Hello,
I see Celtix had EndpointRegistry in its 1.0 version. What is the
equivalent functionality in CXF? After seeing the CXF sources, I could
see ServerRegistry is looking similar to the Celtix interface.
Can ServerRegistry be used to register/unregister JAX-WS endpoints
dynamically? So
I was able to get the attachments to the client as per Dan's suggestion.
Howerver, I'm missing an image in the attachment. The attachment are of
type pdf.
When I use SoapUI to test the service, I was able to get the pdf without a
problem.
I have tried Xfire client and I see a missing image on
Yes the image inside the pdf is missing. I have not tried diffing. I will
try and see if I see any truncation in the two files.
I was able to open the PDF even though the image is missing.
--Vijay
On 4/9/08 1:06 PM, Benson Margulies [EMAIL PROTECTED] wrote:
An image from *inside* the PDF is
An image from *inside* the PDF is missing? That's hard to believe. Have you
just diffed the PDF to see the nature of the problem? Is it just truncated?
On Wednesday 09 April 2008, Benson Margulies wrote:
A bit of googling got me nowhere here.
I want to publish a service on both a http: address and a local:
address. Two jaxws:endpoints? Can they point to the same
#implementation bean?
Yep. It's the same as if you did:
MyThing thing = new
Daniel Kulp wrote:
On Wednesday 09 April 2008, Benson Margulies wrote:
A bit of googling got me nowhere here.
I want to publish a service on both a http: address and a local:
address. Two jaxws:endpoints? Can they point to the same
#implementation bean?
Yep. It's the same as if you
On Wednesday 09 April 2008, Florian Rosenberg wrote:
hi glen,
Glen Mazza wrote:
Server faults go into separate interceptor chains (second paragraph
of [1])--I have not done this before, but you should be able to
reuse the interceptors you have on your normal non-error chains for
the
Couple questions:
1) What version of CXF?
2) What are you using for the wsdlLocation? (WEB-INF/foo.wsdl, or
just foo.wsdl, or)
3) How are you configuring the wsdl location? (@WebService annotation,
in a xml config file, etc..)
Dan
On Tuesday 08 April 2008, bharath_t19 wrote:
We
Hmm... that looks like a bug of some sort in the wsdl query code. Most
likely due to the shared wsdl cache. Probably need a bug logged for
that. Most likely, if you remove the wsdlLocation and have it generate
one at runtime, it would be OK as the wsdl cache wouldn't be involved.
On Wednesday 09 April 2008, Arul Dhesiaseelan wrote:
Daniel Kulp wrote:
On Wednesday 09 April 2008, Benson Margulies wrote:
A bit of googling got me nowhere here.
I want to publish a service on both a http: address and a local:
address. Two jaxws:endpoints? Can they point to the same
Thanks Dan.
But when I implement as shown below.
MyThing implementor = new MyThingImpl();
String address = http://localhost:8080/MyThingInstance;
javax.xml.ws.Endpoint jaxwsEndpoint = Endpoint.publish(address,
implementor);
MyThing implementor2 = new
Yea, this looks like a jettison bug. Definitely log a bug with them:
http://jira.codehaus.org/browse/JETTISON
You might actually want to try an older version of jettison. I think
this might have been introduced in 1.0. (no promisses though)
Dan
On Monday 07 April 2008, rm-ramos wrote:
Hi Dan,
We could see the root cause for this issue.It happens only when the App
Server is installed in a folder path which has a space(in any of the
folder names).We tried it on JBoss which resulted in the same exception.
1) What version of CXF?
We are using CXF 2.0.3
wsdl location is
JBoss 4.2
Benson Margulies-4 wrote:
I think this has to do with the XML jars in your path. What container are
you in?
--
View this message in context:
http://www.nabble.com/I-have-the-TRaX%2C-can-you-help--tp16455965p16597149.html
Sent from the cxf-user mailing list archive at
We have found a way to reproduce it. We are using JBoss 4.2 and CXF 2.0.3.
When JBoss is starting, if a client {java or .net} attempts to connect to
the webservice before the JBoss server is completely up and servicing the
webservice, the exception will be thrown after JBoss displays it's
Any chance you can try with CXF 2.0.5? I know I fixed a BUNCH of issues
with URL's with spaces in them a little while ago. It MAY have been for
2.0.4, but definitely 2.0.5.
Meanwhile, I'll try testing some stuff here. I cannot even get tomcat to
start from a dir with a space in it to
Honestly, my first thought is to hope that Thomas from JBoss, who has been
posting a lot of traffic on the dev list, might be able to help you.
On Wed, Apr 9, 2008 at 5:42 PM, jm1468 [EMAIL PROTECTED] wrote:
We have found a way to reproduce it. We are using JBoss 4.2 and CXF
2.0.3.
When
I've followed the documentation pertaining to a customer binding for
wsdl2java. Specifically, replacing the XMLGregorianCalendar with
java.util.Date.
The command I'm using is as follows:
./wsdl2java.bat -d s:\\cxf-client\\src -compile -client -b
quoteBrokerBinding.ml
org.w3._2001.xmlschema.Adapter1 is generated by wsdl2java tool or wrote by
yourself ?
Jim
On Thu, Apr 10, 2008 at 6:24 AM, [EMAIL PROTECTED] wrote:
I've followed the documentation pertaining to a customer binding for
wsdl2java. Specifically, replacing the XMLGregorianCalendar with
Webapp #1 sets up a service, with an endpoint on the local transport.
[java] INFO: Creating Service {urn:basistech.com:rta}RosetteTextAnalyzer
from class com.basistech.rta.ws.RosetteTextAnalyzer
[java] Apr 9, 2008 9:10:55 PM org.apache.cxf.endpoint.ServerImpl
initDestination
29 matches
Mail list logo
