Hi Axel,
I checked the HTTPConduit code, your way to set the http basic
authentication is right.
Can you use tcpmon to check the authentication informantion has been set
into the http headers?
If not, I think it must be the CXF's bug.
Willem.
Axel Becker wrote:
Hi,
i generated the clie
Oh, then do start submitting patches so that situation can be rectified!
Glen
Am Mittwoch, den 25.07.2007, 11:04 -0700 schrieb Paul Brown:
> On 7/25/07, Glen Mazza <[EMAIL PROTECTED]> wrote:
> > FYI list, I don't know if it was posted earlier to this list (searching
> > Nabble didn't seem to turn
Daniel -
I notice that, we test the latest SVN code and we are very happy on
how it works.
Thanks again for all the help.
On Jul 25, 2007, at 4:15 PM, Daniel Kulp wrote:
Dan, (and Julio)
Actually, if you use the latest SVN code, and the service is set to
wrapped doc/lit, you may not get
Hi Brad,
I have encountered same problem before.
This error is caused by two version of wsdl4j (wsdl4j-1.5.1.jar and
wsdl4j-1.6.1.jar in my case) are in classpath.
Would you please cheack your classpath? Or tell me how you run cxf?
Best regards
Freeman
Brad Harper wrote:
seems similar to o
Dan, (and Julio)
Actually, if you use the latest SVN code, and the service is set to
wrapped doc/lit, you may not get the funky package named thing. For
the top level types in wrapped/doc lit, I now remove the arrays since
we'll handle those ourselves. Thus, they won't appear as schemas in
Chris, Daniel,
I don't suppose there's any chance of CXF introducing a configurable option
to use non-conforming (but more reasonable IMHO) default parameter names?
Am I the only one that sees the default parameter names as something akin to
obfuscation of the WSDL file? I've sent a comment to t
seems similar to other reports relating XmlSchema-1.2.jar...
Exception in thread "main" java.lang.IncompatibleClassChangeError
at org.apache.cxf.wsdl11.WSDLServiceBuilder.copyExtensionAttributes(
WSDLServiceBuilder.java:125)
at org.apache.cxf.wsdl11.WSDLServiceBuilder.buildServices(
WSDLSer
Thanks. That's it.
-bh
On 7/23/07, Willem Jiang <[EMAIL PROTECTED]> wrote:
You need to add the xml-resolver-1.2.jar into your class path.
Willem.
Brad Harper wrote:
> I'm attempting to integrate CXF with an existing Spring app and I'm bean
> getting instantiation errors on startup... The cul
Hi,
i generated the client code with the wsdl2java from an existing wsdl.
now i want to connect to this service (it is an axis 1 webservice). the
service ist protected with a http basic authentication. i use the following
code, but it doesnt work :-(
INFOServiceService ss = new INFOServiceServi
Hi Corey,
As you've probably seen in the reply from Dan K., the JAX-WS
specification states that the default should be "argN" where N is
replaced with the zero-based argument index. CXF is compliant with the
JAX-WS spec, so it looks like you've found a mistake in the CXF
documentation. Thanks fo
Chris,
Thanks for your response. The document you reference states: "The default
is to use the name of the parameter as it appears in the method's argument
list." which is exactly what I'm looking for as I don't really want to have
to annotate every single parameter on all my methods. Is this a
Just FYI: this is per JAX-WS spec.
Section 3.6.1 states:
♦ Conformance (Parameter naming): The javax.jws.WebParam annotation (see
7.11.4) MAY be used to specify the name of the wsdl:part or XML Schema
element declaration corresponding to a Java parameter. If both the name
and partName element
Hi Corey,
If you are doing a JAX-WS Java-first service, you can use the @WebParam
annotation to specify web parameter names. It's in the documentation
guide here:
http://cwiki.apache.org/CXF20DOC/developing-a-service.html#DevelopingaSe
[EMAIL PROTECTED]
(tiny url: http://tinyurl.com/yr2q2w)
-C
All...
I'm doing Java-first development on a service and the WSDL file being
generated (I'm using Tomcat v5.5 as my container with the CXFServlet) is
using arg0, arg1 etc. as the parameter names for my service methods rather
than using the actual parameter name specified in my Java code. Is this
Hi All,
I have an update on this issue. Apparently the problem is that glassfish
(sun appserv 9.0) requires that all resource-refs be found on the Thread
context classloader. which is a parent to the web application classloader
for the deployed CXF service. I believe that this translates to
On 7/25/07, Christopher Moesel <[EMAIL PROTECTED]> wrote:
I thought the article was good, but it seemed like the author kept using
"XFire" and "CXF" interchangeably. It could be confusing for those who
are not familiar with both frameworks-- some questions that *say* XFire
really *mean* CXF. A
On 7/25/07, Glen Mazza <[EMAIL PROTECTED]> wrote:
FYI list, I don't know if it was posted earlier to this list (searching
Nabble didn't seem to turn anything up) but there is a recent O'Reilly
OnJava.com interview with two of the Apache CXF founders here you might
find interesting/informative to
I have the following bug that where I cannnot figure out where the
problem is. I have a Web Service with the following definition:
=== INTERFACE
@WebService( name = "SubscriptionService" )
public interface ISubscriptionService extends IBackendService
{
@WebMethod( ope
Hi all:
I don't know if this mailing list will allow attachments, but I'm
attaching a tarball of the hello world sample I've been messing with.
It builds a simple 'say hello' app, then builds a client to test it, and
during the 'integration-test' phase it uses cargo to start a container,
deploy
Thanks Dan -
I have another problem with List as a parameter I get a type
mismatch, I'm still using JAXB binding. StringArray is the wrapper
created for List by wsdl2java. We debug CXF code and we found
that the actual parameter for the invocation is just a the string
"hola" instead of th
I thought the article was good, but it seemed like the author kept using
"XFire" and "CXF" interchangeably. It could be confusing for those who
are not familiar with both frameworks-- some questions that *say* XFire
really *mean* CXF. Although CXF can be considered "XFire 2.0", it
would have bee
FYI list, I don't know if it was posted earlier to this list (searching
Nabble didn't seem to turn anything up) but there is a recent O'Reilly
OnJava.com interview with two of the Apache CXF founders here you might
find interesting/informative to read:
http://www.oreillynet.com/onjava/blog/2007/07
Dan,
Thanks for the reply
I updated my beans.xml to be:
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframewo
Hi Willem,
Thanks for your help. After repackaging my WAR according to your
instructions (with a few minor modifications), I was able to get much
further and the service actually deploys on glassfish v1. My latest error
(which prevents my service from starting) is the following:
java.lang.
I submitted a JIRA for this, and I think that Dan fixed it.
> -Original Message-
> From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 25, 2007 10:20 AM
> To: cxf-user@incubator.apache.org
> Subject: Re: Aegis bindings
>
> I figured out the problem. Once again stupidity
thanks a lot my man! :-)
--
View this message in context:
http://www.nabble.com/beginner-q%3A-classnotfoundexception-using-DynamicClientFactory-tf4141887.html#a11783635
Sent from the cxf-user mailing list archive at Nabble.com.
Hi Sameh,
There are better ways to set the stax parser. If you're using the
*ServerFactoryBean you can do something like this:
ServerFactoryBean sf = new ServerFactoryBean();
...
Map properties = new HashMap()
properties.put(XMLInputFactory.class.getName(), "your.xml,input.factory");
properties
Thank you very much for your quick help! This fixed my problem. I
used the "wsdl2java" generated build.xml to build with Ant and
therefore didn't pay much attention to the compiler options specified
there. Changing the javac task invocation to
debug="true" encoding="utf8">"
fixed the pro
Hi Dave,
Thanks for the bug report. This has actually been fixed in SVN, so if you
download the latest snapshots things should work fine with a mix of lists
and arrays.
Cheers,
- Dan
On 7/25/07, Dave Kallstrom <[EMAIL PROTECTED]> wrote:
I figured out the problem. Once again stupidity on my pa
Much to all of our general disdain here, I believe this is a limitation of
JAXB. You in essence have two options:
1. Define a wrapper type. For instance, if you were going to return a
collection of customers you would create a Customers class with a List of
customers on it
2. Use Aegis - http://cw
I figured out the problem. Once again stupidity on my part.
I had one method that took SearchField [] fields and one method that
returned List aegis was trying to create two different complex
types both named ArrayOfSearchField.
On 7/24/07, Dave Kallstrom <[EMAIL PROTECTED]> wrote:
>
> I have enab
Hi,
I just went through the DynamicClientFactory code, and found your code got
class loader a little earlier.
When the DynamicClientFactory create the client , it will setup the classpath
to load the generated class.
You just need to use the thread's ContextClassLoader after the dcf.createClien
Are you specifying an encoding when you compile your Java classes? i.e.
javac -encoding utf8 MyClass.java?
Oliver Flasch wrote:
Hi,
I'm using a "wsdl2java"-generated CXF Client to talk to a .NET
Webservice. When sending a string containing some special characters
(german "umlaute" in my case
Hi,
I'm using a "wsdl2java"-generated CXF Client to talk to a .NET
Webservice. When sending a string containing some special characters
(german "umlaute" in my case), these characters seem to be "mangled
up" by some CXF component. For example, I have this "hardcoded"
string in my (UTF-8 e
Hi folks,
Having some diffs with the DynamicClientFactory.
On following the example like so:
[code]
ClassLoader classLoader =
Thread.currentThread().getContextClassLoader();
DynamicClientFactory dcf = DynamicClientFactory.newInstance();
Client client =
dcf.createClient("ht
On Wednesday 25 July 2007 07:16, Benson Margulies wrote:
> Could some kind person explain what's going on with the jar files
> here? This manifest jar business is a new one on me. If we put a jar
> in the classpath with a MANIFEST.MF with a classpath, are the
> pathnames in the MANIFEST.MF interpre
Could some kind person explain what's going on with the jar files here?
This manifest jar business is a new one on me. If we put a jar in the
classpath with a MANIFEST.MF with a classpath, are the pathnames in the
MANIFEST.MF interpreted relative to the path of the manifest jar? And
why does it mat
Wow. Good catch. I would have never thought about the bundle jar
being the issue.
James: can you log a Jira so I can track it in the release notes?
Dan
On Wednesday 25 July 2007 05:05, James Mao wrote:
> Sorry, you do have the stacktrace attached
>
> And i can reproduce your problem now,
Jeff,
This is great... Another idea along a similar path if you need
something to do would be to create a @Features annotation or something
to do the same thing as the features stuff in the spring config.
Dan
On Wednesday 25 July 2007 02:50, Jeff.Yu wrote:
> Hi,
>
> I've submitted a patch f
Hi
There are some differences between the
They are doing the configuration in different level
jaxws:endpoint working directly on the Jaxws API , it equals to call the
endpoint.publish()
jms:conduit only do some jms transport level configuration
If you had specified the jms transport informat
Thank you, the work-around works.
2007/7/25, James Mao <[EMAIL PROTECTED]>:
Sorry, you do have the stacktrace attached
And i can reproduce your problem now, it's caused by the bundle jar,
some schemas can not be accessed from the bundle jar.
And I'm sure, you're using the bundle jar
humm...
Thanks Ulhas,
Anyway, i think the JMS transport configuration with Spring is a little bit
tricky.
With http transport, It´s very easy for me to configure and start the server
with a few lines, like this:
I guess it´s the CXFServlet who starts the service, isn´t it?. But with JMS
configuration
Sorry, you do have the stacktrace attached
And i can reproduce your problem now, it's caused by the bundle jar,
some schemas can not be accessed from the bundle jar.
And I'm sure, you're using the bundle jar
humm... i'll try to fix this.
The work around solution is to use the manifest jar, i.
Here's the stack trace (or rather, the complete output):
wsdlvalidator -V
/Users/vest/workspace/Statistics2/src/main/resources/HelloWorld.wsdl
wsdlvalidator - 2.1-incubator-SNAPSHOT
WSDLValidator Error :
line 8 column 56 of
file:/Users/vest/workspace/Statistics2/src/main/resources/HelloWorld.wsd
Strange, i tried with the latest kit, the output is like this:
C:\src\java\apache\cxf\distribution\target\apache-cxf-2.1-incubator-SNAPSHOT\bin>wsdlvalidator
-V HelloWorld.wsdl
wsdlvalidator -V HelloWorld.wsdl
wsdlvalidator - 2.1-incubator-SNAPSHOT
Passed Validation : Valid WSDL
It's a valid
Thanks Jeff
I will take care of this patch
Freeman
Jeff.Yu wrote:
Hi, Freeman
Thanks, I've re-uploaded it.
Thanks
Jeff Yu
Freeman Fang wrote:
Hi Jeff,
Would you please re-upload this patch ensure that "Grant license to
ASF for inclusion in ASF works" is selected?
Thanks
Freeman
Jeff.Y
I upgraded to snapshot 20070724 and I'm still getting the same error.
I case it's some obscure incoding issue, I'm attaching the actual file
(hoping the mailing list won't eat it).
Also, I'm on a mac and java -version gives:
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Editio
No problem, the solution with the ServerRegistry worked perfectly. I am using
tapestry 4.1.2. and additionally tapestry-spring, so it was very easy for me to
inject the ServerRegistry into my Tapestry page and create a dynamic list of
the registered servers there.
-Ursprüngliche Nachricht-
Hi, Freeman
Thanks, I've re-uploaded it.
Thanks
Jeff Yu
Freeman Fang wrote:
Hi Jeff,
Would you please re-upload this patch ensure that "Grant license to
ASF for inclusion in ASF works" is selected?
Thanks
Freeman
Jeff.Yu wrote:
Hi,
I've submitted a patch for this JIRA, can someone help
49 matches
Mail list logo
