Re: service ok, client not...
hi, Would you please check cxf-rt-transports-http-2.1-incubator-SNAPSHOT.jar and cxf-rt-transports-http-jetty-2.1-incubator-SNAPSHOT.jar is on your client side classpath? And Would you please provide the client side classpath ? client and server are within the same jvm, i.e. the servlet is contacted from another servlet for testing purpose. i have the following libs in the WEB-INF/lib: XmlSchema-1.2.jar acegi-security-1.0.4.jar aopalliance-1.0.jar aspectjrt.jar cglib-nodep-2.1_3.jar commons-collections-3.2.jar compass.jar cxf-2.0-incubator-RC.jar cxf-manifest-incubator.jar cxf-rt-bindings-http-2.0-incubator-RC.jar cxf-rt-bindings-object-2.0-incubator-RC.jar cxf-rt-frontend-jaxws-2.0-incubator-RC.jar cxf-rt-transports-http-2.0-incubator-RC.jar cxf-rt-transports-http-jetty-2.0-incubator-RC.jar dom4j-1.6.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-javamail_1.4_spec-1.0-M1.jar guice-snapshot.jar jaxb-api-2.0.jar jaxb-impl-2.0.5.jar jaxen-1.1.1.jar jcl104-over-slf4j-1.4.0.jar jdom-1.0.jar jra-1.0-alpha-3.jar log4j-bridge-0.9.7.jar logback-classic-0.9.7.jar logback-core-0.9.7.jar lucene-analyzers-2.1.0.jar lucene-core-2.1.0.jar neethi-2.0.jar oscache-2.4.jar quartz-1.6.0.jar rome-0.9.jar serializer.jar slf4j-api-1.4.0.jar slf4j-jdk14-1.3.1.jar spring-beans.jar spring-context.jar spring-core.jar spring-dao.jar spring-web.jar stax-api-1.0.1.jar stax-utils-20060502.jar wicket-1.3.0-incubating-SNAPSHOT.jar wicket-auth-roles-1.3.0-incubating-SNAPSHOT.jar wicket-extensions-1.3.0-incubating-SNAPSHOT.jar wicket-guice-1.3.0-incubating-SNAPSHOT.jar wicket-ioc-1.3.0-incubating-SNAPSHOT.jar wsdl4j-1.6.1.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xbean-2.2.0.jar xercesImpl-2.9.0.jar xml-resolver-1.2.jar --- jan.
Re: service ok, client not...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi freeman, I notice you still use 2.0-incubator-RC, we fix several bugs since that version. i switched between both, it doesn't make any difference. i used the latest trunk from yesterday. regards, --- jan. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGf3VILcYXCUxYsy4RArRmAJ9I/u9WoBUubxpubPKHcBLEgKmTgwCgyuYb r2wlhh7dla/Vk4AcJvlUw5U= =BjsH -END PGP SIGNATURE-
Re: service ok, client not...
Hi Jan, Would you please fill a jira for us to track this issue and append your test code? Thanks very much Freeman Jan Kriesten wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi freeman, I notice you still use 2.0-incubator-RC, we fix several bugs since that version. i switched between both, it doesn't make any difference. i used the latest trunk from yesterday. regards, --- jan. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGf3VILcYXCUxYsy4RArRmAJ9I/u9WoBUubxpubPKHcBLEgKmTgwCgyuYb r2wlhh7dla/Vk4AcJvlUw5U= =BjsH -END PGP SIGNATURE-
Re: service ok, client not...
It looks like a char set exception, that came from
com.caucho.xml.stream.XMLInputFactoryImpl.createXMLStreamReader(XMLInputFactoryImpl.java:149)
I just went through current CXF trunk's lib, and not found any thing
about com.caucho.xml.stream.XMLInputFactoryImpl
After I google it, I found it relates to resin.
In CXF, we use Woodstox (wstx-asl-3.2.1.jar) as the stax
implementation, and we have a good test with it.
So please make sure the servlet can load Woodstox first.
Cheers,
Willem.
Jan Kriesten wrote:
hi willem,
Bus bus = new SpringBusFactory().createBus();
using the bus i got one step further, but now i'm in the game with the following
exception:
[10:40:23.211] Creating Service
{http://config.services.silberlicht.de/}IConfigService from class
de.silberlicht.services.config.ICo
nfigService
10:40:24.062 DEBUG [de.silberlicht.services.config.ConfigService ] - Requested
Key: testkey
[10:40:24.082] Interceptor has thrown exception, unwinding now
[10:40:24.082] java.lang.NullPointerException: charsetName
[10:40:24.082] at java.io.InputStreamReader.init(InputStreamReader.java:82)
[10:40:24.082] at
com.caucho.xml.stream.XMLInputFactoryImpl.createXMLStreamReader(XMLInputFactoryImpl.java:149)
[10:40:24.082] at
org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:67)
[10:40:24.082] at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:206)
[10:40:24.082] at
org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:399)
[10:40:24.082] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1830)
[10:40:24.082] at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1698)
as you can see, the server side receives at least the 'testkey'-string. any more
hints?
best regards, --- jan.
--
sign of renitence gmbH co. kg
Büro Hamburg
Kelterstr. 23
D-22391 Hamburg
Germany
fon +49-40-27805130
fax +49-40-27805131
www.renitence.de
www.webnix.de
www.projektnix.de
Geschäftsleitung
Jörg Schmidt-Stein
Susanne Stein
Jan Kriesten
Gerichtsstand Nürnberg
hr a 12518
USt.-IdNr.: DE194293429
St.-Nr. 238 174 01201
Re: service ok, client not...
Hi Jan, CXF_Servlet will try to replace all the DestinationFactory with ServletTransportFactory form the DestinationFactoryManager. And the DestinationFactoryManager is per Bus. If you want to use the client within a servlet, My suggestion is you can create a new bus which is initiated as a normal bus (which does not include the cxf-servlet.xml) and set the bus to client creation code. Here is the sample code for starting the client : Bus bus = new SpringBusFactory().createBus(); JaxWsClientFactoryBean factory = new JaxWsClientFactoryBean(); factory.setBus(bus); factory.setServiceClass(Hello.class); factory.setAddress(http://localhost:8080/Hello;); Hello client = (Hello) factory.create(); If you only want to use the client only for test purpose, you can have a look at CXF's servlet systest :). Cheers, Willem. Jan Kriesten wrote: hi, Would you please check cxf-rt-transports-http-2.1-incubator-SNAPSHOT.jar and cxf-rt-transports-http-jetty-2.1-incubator-SNAPSHOT.jar is on your client side classpath? And Would you please provide the client side classpath ? client and server are within the same jvm, i.e. the servlet is contacted from another servlet for testing purpose. i have the following libs in the WEB-INF/lib: XmlSchema-1.2.jar acegi-security-1.0.4.jar aopalliance-1.0.jar aspectjrt.jar cglib-nodep-2.1_3.jar commons-collections-3.2.jar compass.jar cxf-2.0-incubator-RC.jar cxf-manifest-incubator.jar cxf-rt-bindings-http-2.0-incubator-RC.jar cxf-rt-bindings-object-2.0-incubator-RC.jar cxf-rt-frontend-jaxws-2.0-incubator-RC.jar cxf-rt-transports-http-2.0-incubator-RC.jar cxf-rt-transports-http-jetty-2.0-incubator-RC.jar dom4j-1.6.1.jar geronimo-activation_1.1_spec-1.0-M1.jar geronimo-javamail_1.4_spec-1.0-M1.jar guice-snapshot.jar jaxb-api-2.0.jar jaxb-impl-2.0.5.jar jaxen-1.1.1.jar jcl104-over-slf4j-1.4.0.jar jdom-1.0.jar jra-1.0-alpha-3.jar log4j-bridge-0.9.7.jar logback-classic-0.9.7.jar logback-core-0.9.7.jar lucene-analyzers-2.1.0.jar lucene-core-2.1.0.jar neethi-2.0.jar oscache-2.4.jar quartz-1.6.0.jar rome-0.9.jar serializer.jar slf4j-api-1.4.0.jar slf4j-jdk14-1.3.1.jar spring-beans.jar spring-context.jar spring-core.jar spring-dao.jar spring-web.jar stax-api-1.0.1.jar stax-utils-20060502.jar wicket-1.3.0-incubating-SNAPSHOT.jar wicket-auth-roles-1.3.0-incubating-SNAPSHOT.jar wicket-extensions-1.3.0-incubating-SNAPSHOT.jar wicket-guice-1.3.0-incubating-SNAPSHOT.jar wicket-ioc-1.3.0-incubating-SNAPSHOT.jar wsdl4j-1.6.1.jar wstx-asl-3.2.1.jar xalan-2.7.0.jar xbean-2.2.0.jar xercesImpl-2.9.0.jar xml-resolver-1.2.jar --- jan.
Re: going from incubator
On Monday 25 June 2007 11:01, Alexey Zavizionov wrote: I'm new to the CXF. I want to know why the CXF in the incubator? When it will within asf real projects? And what does it mean incubator (http://incubator.apache.org/), is it bad or not so? The Apache Incubator is the entity designed to get projects up to speed with the Apache way of doing things. A project being in the incubator in no way reflects the quality of the code. There is some VERY good code in the incubator projects. It just means that the incubator people (or the project itself) doesn't feel the project is quite ready to be a full Apache project.There can be a variety of reasons: 1) Legal issues - all code has to be Apache licensed and downloadable packages need to meet very strict Apache guidelines and such. 2) Community issues - Is the project acting like an apache community? Are they voting in new commiters? Are decisions and discussions done on the mailing lists? Are releases made per Apache guidelines? etc... Are new people encouraged to contribute to discussions and code? 3) Community Diversity - Apache wants projects to have a diverse community with contributors coming from a wide variety of backgrounds, companies, etc... Thus, if a company withdraws it's support, the project will live on. (This is one of CXF's main issues. The CXF committer list is very heavily IONA weighted.) 4) many more Basically, being in the incubator is not really a bad thing. If the project is active, they are most likely trying to graduate out of the incubator and are working on it. It just takes time. I think the average project spends about 1.5 years in the incubator, maybe longer. The project just needs to perform in such a way that the Apache Incubator PMC/mentors feel that the project is operating in the appropriate Apache way, has learned and demonstrated the proper Apache processes, etc... That said, a project in the incubator isn't guaranteed to graduate. There have been several projects that have died in the incubator. They were a good idea when they were started, but couldn't really generate a community around the code or the main company starting it withdrew the support, etc... I guess the question for you is: do you feel comfortable with the level of support from the current CXF community? Do you feel we will still be here in 6 months? 1 year? etc... PS: FYI: I seeking for soap implementation for my serious project. I have just looked on xfire and axis2, but they have some bugs. Now I trying to work with CXF.. and it looks a bit friedly to me. Thanks. Thanks for looking at CXF! If you have issues, we'd be happy to hear about them. -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: soap callbacks
Hi Jan, Yes, you can register client side EPR(endpoint reference) to server for callback. Actually, we have a sample callback in the kit to show how typical callback works. You can get concrete idea from this sample. Thanks very much Freeman Jan Kriesten wrote: hi, i'm not yet that familiar with soap co. and what is doable. is it somehow possible to have an instance on the service side and a client can register a callback to itself (e.g. to be notified if a cache should be cleared)? or would i have to go another way in that matter and have the client pull this information? best regards, --- jan.
Re:
Also, hope this helps http://cwiki.apache.org/confluence/display/CXF20DOC/CXF+tools+in+Eclipse STP team is updating their document, i'll update the page to add their links after they finished their instructions. James You can search the results here http://www.nabble.com/cxf-user-f16914.html Basically this is the thread i got http://www.nabble.com/CXF-Eclipse-Plugin-tf3573170.html#a10006587 I'll put those instruction links into the http://cwiki.apache.org/confluence/display/CXF20DOC/Tools soon. James Hello, Do you have up-to-date instructions on how to install the CXF plug-in into Eclipse 3.2? Cheers, Torsten Mielke IONA Technologies GmbH (registriert in Deutschland, AG Darmstadt) Registernummer: HRB 7939 Geschäftsadresse: Im Leuschnerpark 4, D- 64347 Griesheim, Deutschland
