Hi Dan
You were right .. I was getting an old version of DynamicClientFactory from one
of the jars GroovyWS-all.jar
I removed it from the class path and it worked.
Thanks very much for your help.
Also do I need to have the same version of CXF (2.1.4) at the cleint side coz
the team which
Hi,
After doing some investigation and prototyping, I have been thinking that
if there is not an annotation based way of doing this, then writing an
interceptor for the pre marshal phase and modifying the values of the
object to be marshalled there. This requires I have all the fields in the
I agree it does seem pointless, unfortunately my infrastructure demands that I
do just this, that is, NTLM over HTTPS.
I _might_ be able to get away with just using NTLM over HTTP so long as it does
over the wire encryption. I'm not an NTLM expert; can someone confirm if
JCIFS/NTLM does
On 03.12.2009 11:32, users-h...@cxf.apache.org wrote:
Hi! This is the ezmlm program. I'm managing the
users@cxf.apache.org mailing list.
I'm working for my owner, who can be reached
at users-ow...@cxf.apache.org.
To confirm that you would like
li...@peterschen.de
removed from
I filed JIRA https://issues.apache.org/jira/browse/CXF-2571 and attached
test-projects.
I'm using CXF 2.1.8. Also tried 2.2.5 which fails with another stacktrace as
below.
Thanks,
/håkan
CXF 2.2.5 stacktrace:
Caused by: org.apache.maven.plugin.MojoExecutionException:
Hello,
I would like to include files within a web service. The only method I have
come upon was sending data using MTOM. It seems nice, but I have questions
about interoperability, especially dotnet etc.
If MTOM is not so interoperable, then I need an alternative to accept
attachments. What is
You have correctly parsed me.
Option 1: a cheat. Create a fake web service that includes your schema
in the wsdl. Run wsdl2js, and then get busy with a text editor cutting
out the part you want.
Option 2: what we really need here is xsd2js, like the tool provided
in jaxb. The pattern of
Perhaps you can use a CXF client api instead ?
try
MyObject object =
WebClient.create(address).accept(application/xml,application/json).get(MyObject.class)
cheers, Sergey
David or Sergey,
I guess back to my original questionexcept this should be a bit more
clear.
I'm using
Yeah, I just tried this with the 1.1 distro
(http://cxf.apache.org/dosgi-releases.html) and the greeter demo
(http://cxf.apache.org/distributed-osgi-greeter-demo-walkthrough.html).
Just changed the line in the service impl:
props.put(org.apache.cxf.ws.address, http://localhost:9090/greeter;);
Hi David, Sergey,
Thanks for helping me out with that (and testing it). I also went ahead and
imported the new bundles. I see the new URL popping up as (one of the many
INFO) messages in the console but the wsdl is not actually published. The
error that is printed last is:
INFO: Did not
Normally, for the XMLElement, you would add the nillable=true attribute to
@XmlElement. That would write out the element with a xsi:nil=true attribute.
Dan
On Wed December 2 2009 10:50:12 pm Mustafa Sezgin wrote:
Hi all,
I have some beans in a rest service which marshalled and sent
Hi Bernd,
This warning is non-fatal in many cases (although I agree its ugly and
should be fixed). In many cases it just applies to validation of the
XML.
Could you simply try the greeter demo and see if you can get that to
work changing the port etc. Just to eliminate a number of basic
potential
Yepp, I can get the a greeter-like demo to work on a complete fresh
workspace. I think I will take it from there and import my bundles into that
workspace until I hit the problem.
Thanks again for all your support!
Bernd
--
View this message in context:
On Thu December 3 2009 6:16:03 am Pink, Simon (AGCS) wrote:
I agree it does seem pointless, unfortunately my infrastructure demands
that I do just this, that is, NTLM over HTTPS.
I _might_ be able to get away with just using NTLM over HTTP so long as it
does over the wire encryption. I'm
We are using Services Framework 2.2.2.2-fuse and have an endpoint setup
correctly through our beans.xml
Our endpoint uses a spring defined service bean as a dependency
See below :
bean id=webServiceImpl class=gov.faa.nasr.saa.api.WebServicesImpl
scope=prototype
property name=saaService
On Thu December 3 2009 6:59:26 am Alp Timurhan Çevik wrote:
Hello,
I would like to include files within a web service. The only method I have
come upon was sending data using MTOM. It seems nice, but I have questions
about interoperability, especially dotnet etc.
If MTOM is not so
Alas, Being operable with the recent versions of .net is not adequate for
me.
I also have to support .net 2005 etc, wcf and other stuff is not enough. Do
you have any information regarding operability for 2005 ?
Also, I have been examining cxf's support, and without using MTOM,
everything is
Daniel,
I also posted on the JCIFs mailing list before going down the custom
implementation route. I received some crucial information:
JCIFS' HTTP client is simply a wrapper for the builtin client so it is now
obsolete because Sun's builtin client has NTLM capability including NTLMv2 (not
Hi Daniel
I too would go down the route of using WSS to send the client's id. Using 2 way
SSL mutual authentication, while possible, will prove to be a headache to
maintain. Client certificate management/distribution is a real pain, and I know
they say it's a temporary solution but from
Is there any good strategies out there to do versioning of web services?
Does CXF recommends/supports any such versioning strategies? Is there
any difference in versioning between REST versus SOAP services? Also, if
I am doing a *dual* publishing (publishing SOAP and REST from same
interface
On Thu December 3 2009 11:18:01 am Alp Timurhan Çevik wrote:
Alas, Being operable with the recent versions of .net is not adequate for
me.
I also have to support .net 2005 etc, wcf and other stuff is not enough. Do
you have any information regarding operability for 2005 ?
Doing a couple of
On Wed December 2 2009 8:35:57 pm Saiful Haqqi wrote:
hi all,
many article say how to create client side like this with spring,
bean id=client class=demo.order.OrderProcess
factory-bean=clientFactory factory-method=create/
bean id=clientFactory
You can PROBABLY achieve this by creating a subclass of DataHandler and
overriding the writeTo method. Something like:
final DeferredDocumentImpl signedDoc
= new XmlSign().createSignedDocument(new FileInputStream(a_file.xml));
DataHandler dh = new DataHandler(signedDoc, text/xml)
On Wed December 2 2009 11:41:45 pm Craig Tataryn wrote:
Anyone have an inkling as to whether CXF is interpreting the spec
correctly on this? Essentially we have an explicit wsaw:Action
specified on a response message, yet because there is a soapAction set
in the binding the wsaw:Action is
Actually, the OTHER problem is that we're even setting a SOAPAction on the
response message. That's really not needed. Thus, that MAY be the real
bug. If that wasn't set, then it wouldn't find it and thus it would use the
Action header.
Dan
On Thu December 3 2009 2:58:04 pm Daniel
On Wed December 2 2009 6:36:11 pm Cole Ferrier wrote:
I've done some basic testing and setup with x509 certificates, but i have a
few requirements that i'm trying to figure out how i could implement.
1) I want to be able to accept an signed (not encrypted) message without
having the public
That's definitely a potential way of working around the issue, but I'm
slightly concerned as to why the message would have no content. Is there any
way to create a small sample app (maybe take the provider example and add your
policies and such) that would show this?The list really
CXF maintains a cache of JAXBContexts based on the set of classes used by the
each service. If two services use the EXACT same set of classes, then they
will share the same context.If they differ, we have to create a new
context.
Dan
On Mon November 23 2009 2:57:40 am Basavaraja U T
You don't mention what version of CXF you are using. Make sure you are using
2.2.5 as there was some work on MTOM streaming put in there.
We've definitely done some testing with large (but not 5G) files to make sure
they work. If you are using 2.2.5, I'd love to see a testcase of it not
This error sounds like a classloader thing. Check the classpath and such for
and activation jars. If you are on Java6, try removing the activation jar we
ship and such and using the stuff built into the jdk.
Dan
On Sat November 28 2009 3:50:59 pm baeschtu baeschtu wrote:
I was getting a
On Wed November 25 2009 2:06:08 pm vickatvuuch wrote:
Hi All,
We have deployed CXF services on WS 10 and while everything is working (I
can get individual port WSDL and call methods) but the
http://localhost:7002/services page is not showing up like something is
blocking it. The same setup,
I think your comments might only refer to a request message.. so just to be
clear, we are only referring to the response message. The SOAPAction and
Action field for the input message are the same in our wsdl, and are being
sent and handled correctly.
However, on our output message, CXF is
Data is definitely missing from your question
What version of CXF?
Can you provide the full stack trace?
What annotations are on the Service and Interface?
The applicationContext.xml content wasn't in the message either.
Dan
On Wed November 25 2009 6:30:48 am Ralf Heydenreich wrote:
On Tue November 24 2009 5:21:31 am Oliver Wulff wrote:
Hi there
I have to create a W3CEndpointReference within my impl class because one
element within the custom soap fault is of this type. I've found the
following method within the ProviderImpl:
The NORMAL way for this is to have all that defined in the schema and then
turn on the schema validation.At parse time, the xml parser will validate
the XML based on the schema and fail if invalid.
Only really works well for the xsd first cases though as JAXB doesn't provide
enough
Can you create a small test case and attach to a JIRA? This does sound like
a bug.
Thanks!
Dan
On Tue November 24 2009 2:43:09 pm sassjh wrote:
I've configured a CXF simple front end server in Spring like so:
simple:server id=depotServiceWS serviceClass=com.sas...DepotService
This indicates that a fault is being sent back from the server. You would
need to see the server side logs to figure out what is happening there as to
why a fault is being sent back.
Dan
On Tue November 24 2009 9:50:32 am Kanthan wrote:
Hi :working:,
I just created chatting program
This is probably because the XML document is broken, you output multiple
fragments but the resulting doc has no root element.
So in your custom provider just write directly into the stream something
like
out.write(files)
// write individual files here
out.write(/files)
Alternatively rather
This might work, only remember that versioning is a problem as the moment
that your domain class chages that will get exposed to the world and
ultimately can break many clients..
What I did in this case was making WS layer wrapper classes which provide a
JAXB compliant facade while shuttling
Nasty Weblogic.. Not forwarding to the /root/services page. If I go there
directly its all there looking good..
JBoss and Tomcat same war - no problem.
dkulp wrote:
On Wed November 25 2009 2:06:08 pm vickatvuuch wrote:
Hi All,
We have deployed CXF services on WS 10 and while everything
Dan,
I see you are back, could you tell how to properly propagate Runtime
execption to the client?
I think I have tried most everything and no matter if my port declater my
WSAuthFault if the interceptor throws it, the client get genertic SoapFault.
Something is there with WSDL generator not
Yup, I did say that.. Thanks!
I may actually switch to use a list of beans instead as to simplify things,
anyway.
Sergey Beryozkin-2 wrote:
Hi,
Sergey,
I just wonder if you had a chance to implement this in 2.2.5?
No, you said there was no rush :-). I actually did look at it briefly
It should just be automatic if the client code is generated from the WSDL (and
the fault actually matches the description in the wsdl). Any chance of
creating a small test case and attaching to a JIRA?
Dan
On Thu December 3 2009 4:54:42 pm vickatvuuch wrote:
Dan,
I see you are back,
dkulp wrote:
One you have a handle to your client object, you can always reset the
address
it uses on a per invoke basis:
((BindingProvider)client).getRequestContext()
.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
http://blah/blah/blah;);
--
Daniel Kulp
Ok, Option 1:
I made a fake web service and it includes my (actually its a third party
schema that references a bunch of other third party schemas) schema in the
wsdl. Sadly when I run wsdl2js on it I get the following:
org.apache.cxf.common.xmlschema.XmlSchemaUtils unsupportedConstruct
...
de
virus 4659 (20091203) __
ESET NOD32 Antivirus ha comprobado este mensaje.
http://www.eset.com
Hi Dan,
XFire has provided a mechanism to re-use the JAXBContext across different
web service publishing.
The Bug Id - XFIRE-669. (http://jira.codehaus.org/browse/XFIRE-669)
Seems it lets us to pass an existing JAXBContext to a JaxbServiceFactory.
The context is then used by all layers from
Hi Dan,
I solved this problem. I used different threads in client side to ping with
server for sending and receiving messages. Just by delaying the threads
further solved my problem.
Anyhow thanks for your reply Dan.
- Kant
dkulp wrote:
This indicates that a fault is being sent back
Hi Dan,
I solved this problem. I used different threads in client side to ping with
server for sending and receiving messages. Just by delaying the threads
further solved my problem.
Anyhow thanks for your reply Dan.
- Kant
dkulp wrote:
This indicates that a fault is being sent back
49 matches
Mail list logo