Re: How to substitute the placeholders in the config files ?
Hi Alex ,
Here is an example for your replace the ${} palceholders in the spring
configuration file.
Code :
[1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/http_jetty/EngineLifecycleTest.java
Configuration file :
[2]https://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/http_jetty/jetty-engine.xml
Willem.
Alex Shneyderman wrote:
I have a cxf.xml that contains a section like this :
sec:trustManagers
sec:keyStore type=${securitystore.type}
password=${securitystore.password}
file=${securitystore.file} /
/sec:trustManagers
how do I substitute all those ${} placeholders ?
I tried to use PropertyPlaceholderConfigurer that of course did not work.
Any ideas ?
How to substitute the placeholders in the config files ?
I have a cxf.xml that contains a section like this :
sec:trustManagers
sec:keyStore type=${securitystore.type}
password=${securitystore.password}
file=${securitystore.file} /
/sec:trustManagers
how do I substitute all those ${} placeholders ?
I tried to use PropertyPlaceholderConfigurer that of course did not work.
Any ideas ?
--
Thanks,
Alex.
Re: How to substitute the placeholders in the config files ?
You seem to have leapt from 'spring in cxf' to 'no spring at all'? Why not take Glen's suggestion and use an app context with a property configurator? Sorry, but the links do not help to see the solution to my particular problem. I can see how to do it with APIs but not with bunch of XML (maybe my vision is also blurred by the distaste to XML configuration). Alex.
Re: Refactoring a WSDL with CXF and Eclipse...
I have followed your steps. But I still have the same problem when trying to regenerate wsdl file. I don't have Generate WSDL option in the popup menu when right click the Project . Jonathan Huang wrote: Hi Tophebboy, Please follow the steps to try again :) () 1. Download the eclipse sdk 3.3 from: http://www.eclipse.org/downloads 2. Download the all-in-one STP package from: http://www.eclipse.org/downloads/download.php?file=/stp/downloads/drops/R-R200710161054-200710161054/stp-all-in-one-incubation-R-R200710161054-200710161054.zip 3. Un-pack these two packages to one folder. 4. Download the CXF 2.0.3 runtime from: http://incubator.apache.org/cxf/download.html 5. Un-pack the cxf package to some folder. 6. Start eclipse from the location where you just un-pack the eclipse sdk and stp packages. 7. Click [Window]--[Preferences...]--[SOA Tools]--[Installed Runtimes] to add a Apache CXF 2.0 runtime. 8. Start the java first project wizard and chose the runtime you just create in the runtime page. 9. Then do what you want do... Tophebboy wrote: ==Hi! Jonathan Huang wrote: Hi, Tophebboy Have you try to build your project after refactoring your SEI?? ==Yes Have you add Jax-ws related annotaions to the modified SEI?? == Yes When you right click the Project, does the operation Generate WSDL appear in the popup menu?? == No. I only have Create Jax-WS handler, Enable Jax-WS and Disable Jax-WS Tophebboy wrote: Hi! I'm using Eclipse 3.3.0 and STP 0.7. Anyway, I don't have the option generate wsdl. On top of that, once I generate the code, the SEI is changed to use new classes created in the service package and and cannot rebuild the wsdl then... Jonathan Huang wrote: Hi Tophebboy, I am not sure which version of eclipse you use. If you use the old one, you could set Build Automatically for your project. Then if you refactor SEI, the related wsdl will be updated automatically. If the Build Automatically is not set, you should build your project manually after refactoring your SEI and the wsdl will also be updated. If you use the eclipse with the latest STP, you could use the Generate WSDL operation to update the wsdl file after you refactor your SEI. Hope useful for you! Tophebboy wrote: Hi! I have to create Web Services with CXF and Eclipse. When I follow the tutorial Java fisrt, everything is OK. But, when I have to refactor my SEI, I lose everything: the wsdl is not updated...Anyway, I tried to Create a new Java First project to create a new SEI, a new WSDL, and I updated the WSDL of my former project with the new one, hoping that I could regenerate the code this way. But no! The operation generate code does nothing!!! Please help me! I really don't know how to do to be able to refactor my web services when I have to because re-doing everything from the beginning is very VERY long! Thanks in advance!!! -- View this message in context: http://www.nabble.com/Refactoring-a-WSDL-with-CXF-and-Eclipse...-tp13899015p14503449.html Sent from the cxf-user mailing list archive at Nabble.com.
Wsdl2java package usage
When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) Nathan
how to handle exception in CXF
I am trying to add in BusinessLogicException in the spring HelloWorld example. But I just can't get it work!! Below are the server/client stack-trace and my files. Please help me! -- *server side Dec 26, 2007 1:48:25 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: here BusinessLogicException_Exception... at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractIn voker.java:107) at org.apache.cxf.jaxws.JAXWSMethodInvoker.createFault(JAXWSMethodInvoke r.java:76) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker .java:95) at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.jav a:100) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker .java:68) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInv okerInterceptor.java:56) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecu tor.java:37) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(Se rviceInvokerInterceptor.java:92) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept orChain.java:207) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainIniti ationObserver.java:73) at org.apache.cxf.transport.servlet.ServletDestination.doMessage(Servlet Destination.java:79) at org.apache.cxf.transport.servlet.ServletController.invokeDestination( ServletController.java:256) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletCont roller.java:160) at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCX FServlet.java:170) at org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCX FServlet.java:148) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:263) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce ss(Http11Protocol.java:584) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44 7) at java.lang.Thread.run(Thread.java:595) Caused by: demo.spring.BusinessLogicException_Exception: here BusinessLogicExcep tion_Exception... at demo.spring.HelloWorldImpl.sayHi(HelloWorldImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(Abst ractInvoker.java:124) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker .java:82) ... 26 more Dec 26, 2007 1:48:25 PM org.apache.cxf.binding.soap.interceptor.Soap12FaultOutIn terceptor handleMessage INFO: class org.apache.cxf.binding.soap.interceptor.Soap12FaultOutInterceptorapp lication/soap+xml *client side INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.binding.soap.SoapFault: Could not parse message. at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:65) at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207) at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:90) at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:179) at org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:56) at
Re: java2wsdl question
It is warning message not error . You do not need to provide them .
Java2wsdl can generate wsdl and the wrapper bean
for this class.
Regards
Jim
yulinxp wrote:
Here is the SEI. I use cxf 2.0.3 when I run java2wsdl, why it always asks for
RequestWrapper ResponseWrapper. Do I need to provide RequestWrapper and
ResponseWrapper?
package demo.spring;
import javax.jws.WebService;
@WebService
public interface HelloWorld {
public void sayHi(
java.lang.String text
);
}
binjava2wsdl demo.spring.HelloWorld
Dec 26, 2007 3:30:23 PM
org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
getWrapperClass
WARNING: Can not load wrapper class demo.spring.jaxws.SayHi, please check
the @RequestWrapper or @ResponseWrapper and also check the class is in your
classpath
Dec 26, 2007 3:30:23 PM
org.apache.cxf.tools.java2wsdl.processor.internal.jaxws.Wrapper
getWrapperClass
WARNING: Can not load wrapper class demo.spring.jaxws.SayHiResponse, please
check the @RequestWrapper or @ResponseWrapper and also check the class is in
your classpath
Re: Wsdl2java package usage
Hi Nathan, Wsdl2java can not merge the ObjectFactory to the previously generated class. We need to provide a warning message or an option before overwrite the generated code. I think you can use wsdl2java -pnamespce=package to map the different namespace to different package . for example: wsdl2java -porg.apache.cxf.schema1=com.foo.bar1 -porg.apache.cxf.schema2=com.cxf.foo.bar1 Hope this can help you . Regards Jim Silberman, Nathan wrote: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) Nathan
Re: Wsdl2java package usage
Am Mittwoch, den 26.12.2007, 14:48 -0500 schrieb Silberman, Nathan: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) ObjectFactory has always struck me as just a training wheel-type helper class for newbies. (IIRC GlassFish Metro's wsimport doesn't even generate it.) I would argue to keep your code JAX-WS portable and avoid using it in your work. Glen Nathan
RE: Wsdl2java package usage
I apologize, I stand corrected. Metro (JAXB apparently) *does* create this class. I did not realize it was a required object--still, I don't see it being referenced by other classes. Perhaps running wsdl2java twice, flipping the order of FooService and BarService, and then merging all the methods into *one* ObjectFactory would work. That's all I can think of. Glen Am Mittwoch, den 26.12.2007, 23:48 -0500 schrieb Silberman, Nathan: I actually had not been using ObjectFactory in my code at all. The reason why this came up is that I have 2 services, lets call them FooService and BarService, both of which have abstract and extended types. When I execute wsdl2java on FooService, and then BarService, ObjectFactory has only BarService create helper methods. No problem so far. Still not referencing these methods in my codebase. At this point, when I deploy my two services, only BarService works correctly, in that FooService's extended types are marshalled WITHOUT derived type information (thus rendering them impossible to unmarshall). If I instead execute wsdl2java on BarService and then FooService, thus ensuring that FooService's methods appear in ObjectFactory, then FooService works fine and BarService's derived/extended types no longer work. I hadn't though that ObjectFactory was used at from CXF but this is literally the only file I observed as being altered (aside from several file's whose' autogened timestamps were changed) when I switch the ordering of which I execute with wsdl2java first or second. Any thoughts? I can produce some sample code if this is unclear or if a real example is needed for any diagnosis. -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 11:34 PM To: cxf-user@incubator.apache.org Subject: Re: Wsdl2java package usage Am Mittwoch, den 26.12.2007, 14:48 -0500 schrieb Silberman, Nathan: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) ObjectFactory has always struck me as just a training wheel-type helper class for newbies. (IIRC GlassFish Metro's wsimport doesn't even generate it.) I would argue to keep your code JAX-WS portable and avoid using it in your work. Glen Nathan
RE: Wsdl2java package usage
We had 8 services like this. We ran wsdl2java separately for each of them. Then, copied everything into one folder-tree (overwriting along the way) and as Glen said, finally merged the ObjectFactory code manually. Regards Mayank -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Thursday, December 27, 2007 10:48 To: cxf-user@incubator.apache.org Subject: RE: Wsdl2java package usage I apologize, I stand corrected. Metro (JAXB apparently) *does* create this class. I did not realize it was a required object--still, I don't see it being referenced by other classes. Perhaps running wsdl2java twice, flipping the order of FooService and BarService, and then merging all the methods into *one* ObjectFactory would work. That's all I can think of. Glen Am Mittwoch, den 26.12.2007, 23:48 -0500 schrieb Silberman, Nathan: I actually had not been using ObjectFactory in my code at all. The reason why this came up is that I have 2 services, lets call them FooService and BarService, both of which have abstract and extended types. When I execute wsdl2java on FooService, and then BarService, ObjectFactory has only BarService create helper methods. No problem so far. Still not referencing these methods in my codebase. At this point, when I deploy my two services, only BarService works correctly, in that FooService's extended types are marshalled WITHOUT derived type information (thus rendering them impossible to unmarshall). If I instead execute wsdl2java on BarService and then FooService, thus ensuring that FooService's methods appear in ObjectFactory, then FooService works fine and BarService's derived/extended types no longer work. I hadn't though that ObjectFactory was used at from CXF but this is literally the only file I observed as being altered (aside from several file's whose' autogened timestamps were changed) when I switch the ordering of which I execute with wsdl2java first or second. Any thoughts? I can produce some sample code if this is unclear or if a real example is needed for any diagnosis. -Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 26, 2007 11:34 PM To: cxf-user@incubator.apache.org Subject: Re: Wsdl2java package usage Am Mittwoch, den 26.12.2007, 14:48 -0500 schrieb Silberman, Nathan: When using wsdl2java, I had been specifying the destination packages for several services to be the same package: com.foobar lets say. This is not problematic for all classes except one: ObjectFactory. The methods in objectFactory are only those of the last wsdl to be generated to java code. The consequence of this is that objectFactory is missing most of the element helper methods. Has anybody else run into this issue? If so, is there another solution other than having each wsdl2java output be sent to a different package? (The consequence of multiple output packages is that you end up with duplicate classes for wsdls that share types) ObjectFactory has always struck me as just a training wheel-type helper class for newbies. (IIRC GlassFish Metro's wsimport doesn't even generate it.) I would argue to keep your code JAX-WS portable and avoid using it in your work. Glen Nathan
