CXF on mobiles
Hi all, is there an implementation of CXF (or any plans for it) for mobile devices? Thanks
Re: Distributed OSGi
Great thanks Julien - I will go over the web site material which seems pretty informative. On 5/4/2011 5:08 AM, Julien Vey wrote: Hi Demetris The JASMINe Project<http://wiki.jasmine.ow2.org/xwiki/bin/view/Main/WebHome>from OW2 uses DOSGI. It is not yet integrated in the stable release but you can find some sources here http://websvn.ow2.org/listing.php?repname=jasmine&path=%2Fjasmine-agent%2F
Distributed OSGi
Hi all, are there any known real-life projects that utilize CXF's distributed OSGi platform? Or any use cases I can look over? I am primarily interested in service composition across distributed OSGi containers. I did see the code examples in the corresponding web site but I am looking for larger scale app examples that expose the capabilities of the design. Thanks very much in advance
Re: WADLs
Apologies for my late posting. I missed the later postings on this by a few of you. If it helps that's awesome otherwise you can just ignore it. Regards On 2/27/2011 10:48 PM, Demetris wrote: May be this can help - http://www.ibm.com/developerworks/library/specification/ws-wadlwsdl/index.html WSDL (pre-2.0) describes SOAP engpoints. WSDL 2.0 includes appropriate annotations for REST services. WADL is geared towards description of resources which is what REST/HTTP is based on. I agree with Glen a bit on the JMS/RESTful services but I need to do a bit more research on that. On 2/24/2011 9:24 AM, Glen Mazza wrote: You can at least view the WADL using ?_wadl at the end of the service string in a browser. Unsure, but JMS/REST would seem to be a contradiction, because REST is based on the HTTP transport. Glen On 2/24/2011 9:17 AM, robert wrote: The Web Application Description Language (WADL) is new to me. Does CXF support WADLs in any way, relative to the REST style? Also, what would be more applicable, WADLs or WSDLs in support of JMS/RESTful services? Thanks!
Re: WADLs
May be this can help - http://www.ibm.com/developerworks/library/specification/ws-wadlwsdl/index.html WSDL (pre-2.0) describes SOAP engpoints. WSDL 2.0 includes appropriate annotations for REST services. WADL is geared towards description of resources which is what REST/HTTP is based on. I agree with Glen a bit on the JMS/RESTful services but I need to do a bit more research on that. On 2/24/2011 9:24 AM, Glen Mazza wrote: You can at least view the WADL using ?_wadl at the end of the service string in a browser. Unsure, but JMS/REST would seem to be a contradiction, because REST is based on the HTTP transport. Glen On 2/24/2011 9:17 AM, robert wrote: The Web Application Description Language (WADL) is new to me. Does CXF support WADLs in any way, relative to the REST style? Also, what would be more applicable, WADLs or WSDLs in support of JMS/RESTful services? Thanks!
Re: Javascript generation
Thanks Dan and Benson --- even the tools/code for the SOAP client javascript would be pretty good to use/look at. I know REST requires WSDL 2.0 so I will need to deal with that on my own - the parsing and generation that is. I am sure it is not an easy task but I gotta look into it. I think Axis2 may have some of that functionality in place anyway. Quoting Daniel Kulp : > On Friday 19 March 2010 2:57:49 pm Demetris wrote: > > Nice - thanks Dan. Do you know of any plans for CXF to support WSDL 2.0 > > soon? > > > > So in the CXF design, the client requests a javascript script through a > > URL-based > > command and then that script is used for the invocation of the remote > > (REST) service. > > As Benson mentioned, it's just for the SOAP services right now. > > > Is the script on the server side generated at runtime based on the > > implementation of the > > service or is it pre-defined before the service is launched? > > It is generated at runtime based on our internal service model. However, > there is a command line tool that you can use to pre-generate it from the > WSDL > if you prefer to do that. > > Dan > > > > > > Daniel Kulp wrote: > > > On Thursday 18 March 2010 1:44:08 am Demetris wrote: > > >> Hi all, > > >> > > >> where would the server-side javascript code generotion be located in > > >> > > >> the baseline? > > > > > > Should be in: > > > http://svn.apache.org/repos/asf/cxf/trunk/rt/javascript > > > > > > and the command line tool that would wrapper it: > > > http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/frontend/javascrip > > > t/ > > > > > >> I don't seem to be able to locate it. Is there documentation as to who > > >> this generation > > >> works? Is it derived from the service's WSDL file or does the user > > >> navigate how this > > >> generation should work? > > > > > > It's based on the WSDL I believe. Or, more approriately, our service > > > model that would hold onto the wsdl information. > > > > > >> One of the responses I got from Benson as while ago read: > > >> "you can create a 'dynamic client' that can talk to moderately > > >> complex services. This requires the entire CXF stack on the client" > > >> > > >> Are there any examples I can look at of such a 'dynamic client'. And > > >> to what capacity is it 'dynamic'? > > >> > > >> I have http servers that return WSDL 2.0 files (either REST or SOAP > > >> sevices) and I would like to utilize them to generate javascript > > >> clients for those services. From what I gathered so far, CXF and > > >> WSO2 are the only mature projects doing this. If you do know of any > > >> other ones please let me know. It seems to me that CXF can offer > > >> such tools for me to build these clients so I wanted to find a bit > > >> more about them. I have already started going over the online info. > > > > > > Well, CXF doesn't support WSDL 2.0. Thus, that could be an issue. > > > > > > Dan > > > > > >> Thanks very much in advace > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: Javascript generation
Nice - thanks Dan. Do you know of any plans for CXF to support WSDL 2.0 soon? So in the CXF design, the client requests a javascript script through a URL-based command and then that script is used for the invocation of the remote (REST) service. Is the script on the server side generated at runtime based on the implementation of the service or is it pre-defined before the service is launched? Daniel Kulp wrote: On Thursday 18 March 2010 1:44:08 am Demetris wrote: Hi all, where would the server-side javascript code generotion be located in the baseline? Should be in: http://svn.apache.org/repos/asf/cxf/trunk/rt/javascript and the command line tool that would wrapper it: http://svn.apache.org/repos/asf/cxf/trunk/tools/wsdlto/frontend/javascript/ I don't seem to be able to locate it. Is there documentation as to who this generation works? Is it derived from the service's WSDL file or does the user navigate how this generation should work? It's based on the WSDL I believe. Or, more approriately, our service model that would hold onto the wsdl information. One of the responses I got from Benson as while ago read: "you can create a 'dynamic client' that can talk to moderately complex services. This requires the entire CXF stack on the client" Are there any examples I can look at of such a 'dynamic client'. And to what capacity is it 'dynamic'? I have http servers that return WSDL 2.0 files (either REST or SOAP sevices) and I would like to utilize them to generate javascript clients for those services. From what I gathered so far, CXF and WSO2 are the only mature projects doing this. If you do know of any other ones please let me know. It seems to me that CXF can offer such tools for me to build these clients so I wanted to find a bit more about them. I have already started going over the online info. Well, CXF doesn't support WSDL 2.0. Thus, that could be an issue. Dan Thanks very much in advace
Javascript generation
Hi all, where would the server-side javascript code generation be located in the baseline? I don't seem to be able to locate it. Is there documentation as to who this generation works? Is it derived from the service's WSDL file or does the user navigate how this generation should work? One of the responses I got from Benson as while ago read: "you can create a 'dynamic client' that can talk to moderately complex services. This requires the entire CXF stack on the client" Are there any examples I can look at of such a 'dynamic client'. And to what capacity is it 'dynamic'? I have http servers that return WSDL 2.0 files (either REST or SOAP sevices) and I would like to utilize them to generate javascript clients for those services. From what I gathered so far, CXF and WSO2 are the only mature projects doing this. If you do know of any other ones please let me know. It seems to me that CXF can offer such tools for me to build these clients so I wanted to find a bit more about them. I have already started going over the online info. Thanks very much in advace
Re: WSDL 2 SOAP
Thanks Craig - actually that's pretty good. I'd rather do programmatically so I will look into the SOAP UI src. I also saw a few examples of XMLHttpRequest being used in javascript modules so I will revisit that as well. Take care Craig Tataryn wrote: I don't think so, I usually use SoapUI to do that, you might even be able to do it programatically by looking at their source tree and seeing how they do it. http://www.soapui.org/architecture/index.html Not sure if they have a commandline/maven tool that does it. Craig. On Mon, Feb 8, 2010 at 2:22 PM, Demetris wrote: Hi all, is there a tool in CXF that can generate SOAP envelopes directly from WSDL without generating any stubs? Thanks
WSDL 2 SOAP
Hi all, is there a tool in CXF that can generate SOAP envelopes directly from WSDL without generating any stubs? Thanks
Re: D-OSGi and REST
Hi Sergey, did you ever try deploying servlets (to serve calls to RESTful services) on Felix or did you only work on the CXF JAX-RS implementation? I am curious as to whether the OSGi HTTP server can handle servlets for this purpose. I have a feeling that it may not support a web.xml. I want to compare some performance metrics between such different implementations - any ideas will be greatly welcomed. Many regards Demetris Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message----- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
Excellent - thanks Sergey. Sergey Beryozkin wrote: Yes. Some information about the annotation-free mode is here : http://cxf.apache.org/docs/jax-rs.html#JAX-RS-RESTfulserviceswithoutanno tations cheers, Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 21 October 2009 05:17 To: dev@cxf.apache.org Subject: Re: D-OSGi and REST I think this is what you meant here probably with 'no annotations' .. and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml Demetris wrote: Hi Sergey, it is possible to execute bundles as RESTful resources on Felix without the need for JAX-RS annotations or the CXF libs? Felix has a full-featured HTTP bundlified server? Thanks Sergey Beryozkin wrote: Hi no problems at all - your questions are welcome. I know DOSGi does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same lines. If you have any advice on this I would greatly appreciate it. Thanks and regards Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here :
Re: D-OSGi and REST
I think this is what you meant here probably with 'no annotations' .. and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml Demetris wrote: Hi Sergey, it is possible to execute bundles as RESTful resources on Felix without the need for JAX-RS annotations or the CXF libs? Felix has a full-featured HTTP bundlified server? Thanks Sergey Beryozkin wrote: Hi no problems at all - your questions are welcome. I know DOSGi does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same lines. If you have any advice on this I would greatly appreciate it. Thanks and regards Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
Hi Sergey, it is possible to execute bundles as RESTful resources on Felix without the need for JAX-RS annotations or the CXF libs? Felix has a full-featured HTTP bundlified server? Thanks Sergey Beryozkin wrote: Hi no problems at all - your questions are welcome. I know DOSGi does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same lines. If you have any advice on this I would greatly appreciate it. Thanks and regards Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
Exactly - thanks David for the response. I am looking at alternative solutions that are more geered towards mobility even though I do like a lot of the elements CXF showcases. David Bosschaert wrote: Even if you were able to solve the class file version, there's probably bigger problems with J2ME as AFAIK it doesn't support any of the Java 5 features yet (e.g. annotations) and is missing chunks of JSE 5 libraries that CXF uses. You can theoretically get CXF working on J2ME by retroweaving it (see http://www.osgi.org/wiki/uploads/CommunityEvent2007/OSGiCommunity-Roelofsen.pdf) but I'm not sure this is really suitable for an embedded device with constrained memory... Cheers, David 2009/9/28 Demetris Hi Sergey - no problem at all. Regarding the test I got the following exception once I started the single distribution on a J2ME-CDC device - equinox (as well as Knopflerfish_ run fine under J2ME but the dosgi throws java.lang.UnsupportedClassVersionError exceptions (showing only the small trace below) Thanks Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.5.0.v20090520 11 ACTIVE org.eclipse.osgi.services_3.2.0.v20090520-1800 12 RESOLVEDcxf-dosgi-ri-singlebundle-distribution_1.0.0 13 ACTIVE org.eclipse.osgi.util_3.2.0.v20090520-1800 osgi> start 12 org.osgi.framework.BundleException: The activator org.apache.cxf.dosgi.singlebundle.AggregatedActivator for bundle cxf-dosgi-ri-singlebundle-distribution is invalid at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(Unknown Source) at java.lang.Thread.run(Unknown Source) at java.lang.Thread.startup(Unknown Source) Caused by: java.lang.UnsupportedClassVersionError: org/apache/cxf/dosgi/singlebundle/AggregatedActivator (Unsupported major.minor version 49.0) Sergey Beryozkin wrote: Hi no problems at all - your questions are welcome. I know DOSGi does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same lines. If you have any advice on this I would greatly appreciate it. Thanks and regards Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things ar
Re: D-OSGi and REST
Hi Sergey - no problem at all. Regarding the test I got the following exception once I started the single distribution on a J2ME-CDC device - equinox (as well as Knopflerfish_ run fine under J2ME but the dosgi throws java.lang.UnsupportedClassVersionError exceptions (showing only the small trace below) Thanks Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.5.0.v20090520 11 ACTIVE org.eclipse.osgi.services_3.2.0.v20090520-1800 12 RESOLVEDcxf-dosgi-ri-singlebundle-distribution_1.0.0 13 ACTIVE org.eclipse.osgi.util_3.2.0.v20090520-1800 osgi> start 12 org.osgi.framework.BundleException: The activator org.apache.cxf.dosgi.singlebundle.AggregatedActivator for bundle cxf-dosgi-ri-singlebundle-distribution is invalid at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBundleActivator(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(Unknown Source) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(Unknown Source) at java.lang.Thread.run(Unknown Source) at java.lang.Thread.startup(Unknown Source) Caused by: java.lang.UnsupportedClassVersionError: org/apache/cxf/dosgi/singlebundle/AggregatedActivator (Unsupported major.minor version 49.0) Sergey Beryozkin wrote: Hi no problems at all - your questions are welcome. I know DOSGi does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same lines. If you have any advice on this I would greatly appreciate it. Thanks and regards Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference
Re: D-OSGi and REST
Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same lines. If you have any advice on this I would greatly appreciate it. Thanks and regards Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
Hi Sergey, sounds good - yes it is RFC 119 and you are right it is not implemented in KF as of now but I think it is in the works. For the rest I will follow up and see how far I get. Thanks again Sergey Beryozkin wrote: Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message----- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see you are using Felix and Equinox in your examples so I am assuming the answer is yes. What do you guys add to such a service with the cxf-dosgi-ri-singlebundle-distribution_1.0.0? The reason I am asking is because I want to connect the REST service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
Super - I will follow up on the links Sergey and let you know if I have any more questions. Much appreciated. Sergey Beryozkin wrote: Hi Have a look please at http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/ it is indeed virtually identical to a soap based greeter demo but the difference is here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
D-OSGi and REST
Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: WSDL2JS
Nothing like the good old 'giving it a shot' trick ;) My problem is indeed how to both run clients and servers on mobile devices and under J2ME-CDC. And it is a pretty damn limited field to manage to fit in it comprehensive stacks either from Axis or CXF. In any case, I will try to see if a rich CXF client can call a ksoap-server WS and let the list know. Thanks much Oisin Hurley wrote: How convoluted would it be for me at least to isolate tools like the wsdl2js and their classes (WSDLToJavascript etc.) and port it into J2ME-CDC or CLDC? Pretty damn convoluted, and many months of labor, if I recall the CDC, CLDC profile limitations correctly (file system issues, missing classes, potentially weird XML parser issues, resource constraints, missing java annotations, missing generics...) If you use standard WS interactions, then YES, you SHOULD be able to invoke services implemented using different technologies from a CXF client, although it is seldom trivial if your WSDL is complex. So, in theory you should be able to invoke a ksoap server from a CXF client. The best way to find out more is to just give it a shot. --oh
Re: WSDL2JS
I guess no replies to the previous email below means I am on my own ... At least one more Q: How convoluted would it be for me at least to isolate tools like the wsdl2js and their classes (WSDLToJavascript etc.) and port it into J2ME-CDC or CLDC? I guess primarily the tools cxf,common, cxf.tools.common and a few other classes would be involved but other than that I can find a clean separation between them and the main baseline. Any ideas? Thanks again Demetris wrote: Hi Benson et. al., I tried running the D-OSGi in Equinox under J2ME CDC on a Nokia N800 but it failed (I downloaded and activated the single-bungle distro). So I have a feeling I will have the same luck running the CXF stack on that mobile. But I will give the WSDL2JS tool a shot as standalone and run it on a WSDL file that I can generate off the mobile either on a CXF or Axis enabled servers on a hoping that would work. Before I do I am wondering the following - I will have the client mobile generate the javascript code that I can execute via its browser to generate SOAP calls to the remote server mobile running a ksoap2 web service. My questions are, has anyone tried to invoke Axis or any other SOAP-server-engine services from a CXF client (let's say the client is executing the javascript generated from the server's WSDL)? Or do the SOAP messages generated by CXF is annotated in such a way that only its server-side can understand? All this of course provided the client stack can run on the mobile- I am working on testing that now. Thanks Benson Margulies wrote: Demetris, Let me answer/clarify what I can. There are two ways of getting Javascript: 1: ask the server to generate it via the ?js URL. 2: run the generator yourself, either via the command-line driver or the API it calls. Both of this works either code-first or contract first. That is, you start from Java classes with @nnotations, you can directly generate javascript. You don't have to make a wsdl at any point. You could do #2 on the client. However, I am ignorant of the constraints of J2ME or CLDC, so I can't tell you if you can fit the necessary set of our code onto there. --benson On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote: Hi Benson. do you mind if I ask for some clarification? 1) you can ask the server to generate and deliver the javascript client. The server will actually generate and send a javascript client to the requesting remote class correct? But if need be, can the server also generate a WSDL file - which I am assuming can be used on the client side with the WSDL2js to generate the javascript client? 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. But still there is a reduced set of CXF classes that can be run under J2ME-CDC or CLDC? I am looking for the appropriate server/container that I can run under J2ME and which can host CXF web services and I am not having much luck. I think my only option would be to use OSGi (I think Equinox and Knopflerfish can run under J2ME) in which case I will need a bundle-fied version of CXF - I am going over the Distributed OSGi pages on the CXF site hoping that is what I am looking for. Thanks again
Re: WSDL2JS
Hi Benson et. al., I tried running the D-OSGi in Equinox under J2ME CDC on a Nokia N800 but it failed (I downloaded and activated the single-bungle distro). So I have a feeling I will have the same luck running the CXF stack on that mobile. But I will give the WSDL2JS tool a shot as standalone and run it on a WSDL file that I can generate off the mobile either on a CXF or Axis enabled servers on a hoping that would work. Before I do I am wondering the following - I will have the client mobile generate the javascript code that I can execute via its browser to generate SOAP calls to the remote server mobile running a ksoap2 web service. My questions are, has anyone tried to invoke Axis or any other SOAP-server-engine services from a CXF client (let's say the client is executing the javascript generated from the server's WSDL)? Or do the SOAP messages generated by CXF is annotated in such a way that only its server-side can understand? All this of course provided the client stack can run on the mobile- I am working on testing that now. Thanks Benson Margulies wrote: Demetris, Let me answer/clarify what I can. There are two ways of getting Javascript: 1: ask the server to generate it via the ?js URL. 2: run the generator yourself, either via the command-line driver or the API it calls. Both of this works either code-first or contract first. That is, you start from Java classes with @nnotations, you can directly generate javascript. You don't have to make a wsdl at any point. You could do #2 on the client. However, I am ignorant of the constraints of J2ME or CLDC, so I can't tell you if you can fit the necessary set of our code onto there. --benson On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote: Hi Benson. do you mind if I ask for some clarification? 1) you can ask the server to generate and deliver the javascript client. The server will actually generate and send a javascript client to the requesting remote class correct? But if need be, can the server also generate a WSDL file - which I am assuming can be used on the client side with the WSDL2js to generate the javascript client? 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. But still there is a reduced set of CXF classes that can be run under J2ME-CDC or CLDC? I am looking for the appropriate server/container that I can run under J2ME and which can host CXF web services and I am not having much luck. I think my only option would be to use OSGi (I think Equinox and Knopflerfish can run under J2ME) in which case I will need a bundle-fied version of CXF - I am going over the Distributed OSGi pages on the CXF site hoping that is what I am looking for. Thanks again
Re: Integrating JAX-RS runtime into DOSGi
Ok - for whoever will actually read this email - sorry it's late so my previous email may be a bit confusing. The project I mentioned (included the link) and the Apache CXF Distributed OSGi seem to share similarities but the person who is working on that MS thesis is not really making a strong case for his work to differentiate it from RFC 119 and its implementation. That's why I was asking whether these are two different projects and apparently they are. My other two questions were clear: Apache CXF DOSGi is the RFC 119 implementation. I remember reading about that RFC and its early draft release last August - can someone tell me when the implementation in CXF (release 1) began? Thanks - I need sleep. Demetris wrote: After looking at the project I mentioned - here is the article here on their web site: (http://www.dosgi.com/distributed-osgi-webservices-articles-list/39-distributed-osgi-webservices-articles-category/55-initial-idea-distributed-osgi-through-web-services.html) it seems that the similarities between that MS thesis and this project are a few. In the article they mention that "*Apache CFX .. *This is the closest one with this thesis project, yet some significant differences maybe found as we go through deep to compare" but they don't really mention these diffs. So these are two separate projects. Apache CXF DOSGi is the RFC 119 implementation. I remember reading about that RFC - can someone tell me when the implementation in CXF begun? Thanks Sergey Beryozkin wrote: Hi Have a look here please http://cxf.apache.org/distributed-osgi.html cheers, Sergey Demetris G wrote: Hey Sergei and Josh Is the DOSGi you are referring in the essay of an email below the Masters thesis I read once (and it became an open source branch of an apache project) or is this a separate design? We worked on a design calked p2pSOA the connected distributed OSGi containers over p2p technologies while exposing the endpt bundles as web services. So I am fairly interested in your discussion - I just want a quick clarification so I can position your work in my mind. Thanks On Aug 21, 2009, at 12:28 PM, "Sergey Beryozkin" wrote: Hi Josh Can you please let me know if JAXB is being used for your JAX-RS endpoints ? I've spotted that for HTTP Service based JAX-RS endpoints no AegisProvider is being set - I'would actually like JAXB being used by default for JAXRS endpoints which will be consistent with the expectations of JAX-RS users in general - but I'd like to confirm first that JAXB is working ok in your case... thanks, Sergey Sergey, Thanks again for the detailed documentation you've provided in this thread. I was able to easily convert from JAX-WS to JAX-RS, which (I think) will make our lives even easier. Once we've got the ability to expose a single service with both of these frontends, I'll make use of that as well. I agree that the jaxrs.resource property is no longer needed, as you can simply register jaxrs resources as a dosgi services. Josh On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin wrote: Hi, I've applied your patch and I've completed the initial integration of JAX-RS into DOSGi RI. As it often happens I underestimated a bit how long it would take me to do it :-) but I'm quite happy now with what has been done so far. I haven't got a chance to write JAX-WS system tests yet - I was a bit constrained in time but judging from the code you did JAXWS/ databindings should be working nicely now - please feel free to add a system test, or either of us will do it asap. Now, the property names have actually changed and differ from those you provided in the patch. As David noted, it was recommended that DOSGI providers would use reverse domain names as prefixes to their custom configuration types, such as 'pojo' in case of DOSGI RI. Furthermore, 'pojo' was a bit constraining in that it did not reflect the fact that say SOAP or RS services were supported. Additionally, the DOSGI way is
Re: Integrating JAX-RS runtime into DOSGi
After looking at the project I mentioned - here is the article here on their web site: (http://www.dosgi.com/distributed-osgi-webservices-articles-list/39-distributed-osgi-webservices-articles-category/55-initial-idea-distributed-osgi-through-web-services.html) it seems that the similarities between that MS thesis and this project are a few. In the article they mention that "*Apache CFX .. *This is the closest one with this thesis project, yet some significant differences maybe found as we go through deep to compare" but they don't really mention these diffs. So these are two separate projects. Apache CXF DOSGi is the RFC 119 implementation. I remember reading about that RFC - can someone tell me when the implementation in CXF begun? Thanks Sergey Beryozkin wrote: Hi Have a look here please http://cxf.apache.org/distributed-osgi.html cheers, Sergey Demetris G wrote: Hey Sergei and Josh Is the DOSGi you are referring in the essay of an email below the Masters thesis I read once (and it became an open source branch of an apache project) or is this a separate design? We worked on a design calked p2pSOA the connected distributed OSGi containers over p2p technologies while exposing the endpt bundles as web services. So I am fairly interested in your discussion - I just want a quick clarification so I can position your work in my mind. Thanks On Aug 21, 2009, at 12:28 PM, "Sergey Beryozkin" wrote: Hi Josh Can you please let me know if JAXB is being used for your JAX-RS endpoints ? I've spotted that for HTTP Service based JAX-RS endpoints no AegisProvider is being set - I'would actually like JAXB being used by default for JAXRS endpoints which will be consistent with the expectations of JAX-RS users in general - but I'd like to confirm first that JAXB is working ok in your case... thanks, Sergey Sergey, Thanks again for the detailed documentation you've provided in this thread. I was able to easily convert from JAX-WS to JAX-RS, which (I think) will make our lives even easier. Once we've got the ability to expose a single service with both of these frontends, I'll make use of that as well. I agree that the jaxrs.resource property is no longer needed, as you can simply register jaxrs resources as a dosgi services. Josh On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin wrote: Hi, I've applied your patch and I've completed the initial integration of JAX-RS into DOSGi RI. As it often happens I underestimated a bit how long it would take me to do it :-) but I'm quite happy now with what has been done so far. I haven't got a chance to write JAX-WS system tests yet - I was a bit constrained in time but judging from the code you did JAXWS/ databindings should be working nicely now - please feel free to add a system test, or either of us will do it asap. Now, the property names have actually changed and differ from those you provided in the patch. As David noted, it was recommended that DOSGI providers would use reverse domain names as prefixes to their custom configuration types, such as 'pojo' in case of DOSGI RI. Furthermore, 'pojo' was a bit constraining in that it did not reflect the fact that say SOAP or RS services were supported. Additionally, the DOSGI way is
Re: WSDL2JS
Hi Benson, 1: ask the server to generate it via the ?js URL. 2: run the generator yourself, either via the command-line driver or the API it calls. Both of this works either code-first or contract first. That is, you start from Java classes with @nnotations, you can directly generate javascript. You don't have to make a wsdl at any point. Ok. You could do #2 on the client. However, I am ignorant of the constraints of J2ME or CLDC, so I can't tell you if you can fit the necessary set of our code onto there. I guess there is only one way to find out - I will give it a shot and let the list know. I appreciate the response - thanks again On Wed, Aug 19, 2009 at 4:41 PM, Demetris wrote: Hi Benson. do you mind if I ask for some clarification? 1) you can ask the server to generate and deliver the javascript client. The server will actually generate and send a javascript client to the requesting remote class correct? But if need be, can the server also generate a WSDL file - which I am assuming can be used on the client side with the WSDL2js to generate the javascript client? 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. But still there is a reduced set of CXF classes that can be run under J2ME-CDC or CLDC? I am looking for the appropriate server/container that I can run under J2ME and which can host CXF web services and I am not having much luck. I think my only option would be to use OSGi (I think Equinox and Knopflerfish can run under J2ME) in which case I will need a bundle-fied version of CXF - I am going over the Distributed OSGi pages on the CXF site hoping that is what I am looking for. Thanks again
Re: WSDL2JS
Hi Benson. do you mind if I ask for some clarification? 1) you can ask the server to generate and deliver the javascript client. The server will actually generate and send a javascript client to the requesting remote class correct? But if need be, can the server also generate a WSDL file - which I am assuming can be used on the client side with the WSDL2js to generate the javascript client? 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. But still there is a reduced set of CXF classes that can be run under J2ME-CDC or CLDC? I am looking for the appropriate server/container that I can run under J2ME and which can host CXF web services and I am not having much luck. I think my only option would be to use OSGi (I think Equinox and Knopflerfish can run under J2ME) in which case I will need a bundle-fied version of CXF - I am going over the Distributed OSGi pages on the CXF site hoping that is what I am looking for. Thanks again
Re: WSDL2JS
Super - thanks.
Benson Margulies wrote:
The answer to your questions is "yes".
On Mon, Aug 17, 2009 at 12:51 AM, Demetris wrote:
Hi Benson,
I took a look into the rt folder and did go over the cxf-utils.js module -
so the generated
client javascript code makes use of this module to send its requests to the
service - correct?
I know that looking through the code is the best way to learn a lot of this
but this code
is fairly large so I am not sure I will have the time to go through it
before I need to make the
decision to go with CXF - the only Q I have here is, before I invest the
time going over the
documentation, is there enough material there to help me figure out CXF? It
seems that the
web site if fairly well organized so that's encouraging.
Thanks
Benson Margulies wrote:
I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.
There's really no substitute for reading some of this code.
On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:
So if I want to intercept the SOAP message that the client javascript
will
be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer
to
intercept that message without
disrupting/modifying the javascript?
Benson Margulies wrote:
When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.
To answer another question, no z/OS is not required.
On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:
One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am
assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does
it
write to - similar to
Axis, 8080?
Demetris wrote:
Hey guys,
the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
<http://tomcat.apache.org/> container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.
Thanks
Benson Margulies wrote:
CXF has two things going on here.
1) you can ask the server to generate and deliver the javascript
client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.
However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.
On Wed, Aug 12, 2009 at 4:47 PM, Demetris
wrote:
Does CXF support client-side programming for Web Services? What we
are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by
discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate
the
client code.
Not sure how realistic this is at this stage but I am not finding
much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult
task
so
we
are considering the off-the-
device mechanisms.
Daniel Kulp wrote:
On Tue August 11 2009 11:26:05 pm Demetris wrote:
Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.
I believe Axis1 can do doc/literal. JAX-RPC did require some
level
of
support for that so I'm pretty sure Axis1 implemented it. Not
sure
how to
go about configuring it to do so. I'm not an Axis1 user. :-)
Dan
Benson Margulies wrote:
Demetris,
If your place has a big investment in RPC/encoded, perhaps one of
you
would like to pick up the project that one of our committers
started
of adding RPC/encoded support to CXF. If you do it, you get to
ensure
that it works with your services :-). I'd be happy to mentor
someone
in figuring out where Dain left off.
--benson
On Tue, Aug 11, 2009 at 4:21 PM, Demetris
wrote:
Of course I do see infrastructures here in production still
using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc.
and
interoperability between the
two sides is impossible - and of course the rest of us will need
to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a
feeling
I
will be adapting it to my
work.
Cheers
Daniel Kulp wrote:
On Tue August 11 2009 12:15:40 pm Demetris wrote:
Re: WSDL2JS
Hi Benson,
I took a look into the rt folder and did go over the cxf-utils.js
module - so the generated
client javascript code makes use of this module to send its requests to
the service - correct?
I know that looking through the code is the best way to learn a lot of
this but this code
is fairly large so I am not sure I will have the time to go through it
before I need to make the
decision to go with CXF - the only Q I have here is, before I invest the
time going over the
documentation, is there enough material there to help me figure out CXF?
It seems that the
web site if fairly well organized so that's encouraging.
Thanks
Benson Margulies wrote:
I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.
There's really no substitute for reading some of this code.
On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:
So if I want to intercept the SOAP message that the client javascript will
be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer to
intercept that message without
disrupting/modifying the javascript?
Benson Margulies wrote:
When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.
To answer another question, no z/OS is not required.
On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:
One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am
assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does it
write to - similar to
Axis, 8080?
Demetris wrote:
Hey guys,
the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
<http://tomcat.apache.org/> container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.
Thanks
Benson Margulies wrote:
CXF has two things going on here.
1) you can ask the server to generate and deliver the javascript
client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.
However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.
On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
Does CXF support client-side programming for Web Services? What we are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate
the
client code.
Not sure how realistic this is at this stage but I am not finding much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task
so
we
are considering the off-the-
device mechanisms.
Daniel Kulp wrote:
On Tue August 11 2009 11:26:05 pm Demetris wrote:
Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.
I believe Axis1 can do doc/literal. JAX-RPC did require some level
of
support for that so I'm pretty sure Axis1 implemented it. Not sure
how to
go about configuring it to do so. I'm not an Axis1 user. :-)
Dan
Benson Margulies wrote:
Demetris,
If your place has a big investment in RPC/encoded, perhaps one of
you
would like to pick up the project that one of our committers
started
of adding RPC/encoded support to CXF. If you do it, you get to
ensure
that it works with your services :-). I'd be happy to mentor
someone
in figuring out where Dain left off.
--benson
On Tue, Aug 11, 2009 at 4:21 PM, Demetris
wrote:
Of course I do see infrastructures here in production still using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need
to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a
feeling
I
will be adapting it to my
work.
Cheers
Daniel Kulp wrote:
On Tue August 11 2009 12:15:40 pm Demetris wrote:
That's what I figured ;) Thanks for the info Benson.
Now regarding inteconnection of Web Services across
implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I
Re: WSDL2JS
You are absolutely right and I am already on it :) Thanks Benson
Benson Margulies wrote:
I would recommend wrapping/intercepting the object in cxf-utils.js
that sends the requests.
There's really no substitute for reading some of this code.
On Fri, Aug 14, 2009 at 12:07 PM, Demetris wrote:
So if I want to intercept the SOAP message that the client javascript will
be sending out I will need
to dig into the http layers? Is there anything I can do at the app layer to
intercept that message without
disrupting/modifying the javascript?
Benson Margulies wrote:
When the server provides the javascript, it provides the correct URL.
Which is often not port 8080.
To answer another question, no z/OS is not required.
On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote:
One more question for whoever has a few minutes to help out -
Let's say my client contacted the remote server using a URL in order to
obtain the javascript client.
When this script is loaded and ran on the client side browser, I am
assuming
that by default it uses
HTTP to send out the SOAP message to the server right? Which port does it
write to - similar to
Axis, 8080?
Demetris wrote:
Hey guys,
the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
<http://tomcat.apache.org/> container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.
Thanks
Benson Margulies wrote:
CXF has two things going on here.
1) you can ask the server to generate and deliver the javascript
client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.
However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.
On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
Does CXF support client-side programming for Web Services? What we are
after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering
and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate
the
client code.
Not sure how realistic this is at this stage but I am not finding much
on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task
so
we
are considering the off-the-
device mechanisms.
Daniel Kulp wrote:
On Tue August 11 2009 11:26:05 pm Demetris wrote:
Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.
I believe Axis1 can do doc/literal. JAX-RPC did require some level
of
support for that so I'm pretty sure Axis1 implemented it. Not sure
how to
go about configuring it to do so. I'm not an Axis1 user. :-)
Dan
Benson Margulies wrote:
Demetris,
If your place has a big investment in RPC/encoded, perhaps one of
you
would like to pick up the project that one of our committers
started
of adding RPC/encoded support to CXF. If you do it, you get to
ensure
that it works with your services :-). I'd be happy to mentor
someone
in figuring out where Dain left off.
--benson
On Tue, Aug 11, 2009 at 4:21 PM, Demetris
wrote:
Of course I do see infrastructures here in production still using
Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need
to
sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a
feeling
I
will be adapting it to my
work.
Cheers
Daniel Kulp wrote:
On Tue August 11 2009 12:15:40 pm Demetris wrote:
That's what I figured ;) Thanks for the info Benson.
Now regarding inteconnection of Web Services across
implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP calls across them or not? This is
something
I
never tried/looked into
while I worked exclusively with Axis so I was wondering.
Pretty much none of the modern SOAP toolkits support RPC/encoded.
Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc
Basically, rpc/encoded was such an interopability nightmare that
it
really fell into the bucket of "You REALLY REALLY don't want to
use
it."If you want interopability, you really need to migrate
Re: WSDL2JS
So if I want to intercept the SOAP message that the client javascript will be sending out I will need to dig into the http layers? Is there anything I can do at the app layer to intercept that message without disrupting/modifying the javascript? Benson Margulies wrote: When the server provides the javascript, it provides the correct URL. Which is often not port 8080. To answer another question, no z/OS is not required. On Thu, Aug 13, 2009 at 4:57 PM, Demetris wrote: One more question for whoever has a few minutes to help out - Let's say my client contacted the remote server using a URL in order to obtain the javascript client. When this script is loaded and ran on the client side browser, I am assuming that by default it uses HTTP to send out the SOAP message to the server right? Which port does it write to - similar to Axis, 8080? Demetris wrote: Hey guys, the documentation says: "It is relatively straightforward to run a CXF service in a Tomcat <http://tomcat.apache.org/> container on z/OS". But the IBM OS is not a requirement correct? I can run this service on any Tomcat container running on any OS right? I know this is an elementary Q but I wanted to make sure there are not OS-specific dependencies. Thanks Benson Margulies wrote: CXF has two things going on here. 1) you can ask the server to generate and deliver the javascript client. 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote: Does CXF support client-side programming for Web Services? What we are after in one of our projects is to: (1) host web services (or at least a Soap engine) on mobile devices (primarily running J2ME CDC) (2) build web service clients on mobile devices, either by discovering and utilizing WSDLs (to generate javascript stubs) or some other mechanism to allow them to generate the client code. Not sure how realistic this is at this stage but I am not finding much on (1) and a bit on (2). Many people have said that generating WSDLs on mobile devices is a difficult task so we are considering the off-the- device mechanisms. Daniel Kulp wrote: On Tue August 11 2009 11:26:05 pm Demetris wrote: Do you know if Axis 1.x can generate document/literal or only rpc/encoded? I am wondering if setting the OPERATION_STYLE_PROPERTY to document would do the trick. I believe Axis1 can do doc/literal. JAX-RPC did require some level of support for that so I'm pretty sure Axis1 implemented it. Not sure how to go about configuring it to do so. I'm not an Axis1 user. :-) Dan Benson Margulies wrote: Demetris, If your place has a big investment in RPC/encoded, perhaps one of you would like to pick up the project that one of our committers started of adding RPC/encoded support to CXF. If you do it, you get to ensure that it works with your services :-). I'd be happy to mentor someone in figuring out where Dain left off. --benson On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote: Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc Basically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF.
Re: WSDL2JS
One more question for whoever has a few minutes to help out - Let's say my client contacted the remote server using a URL in order to obtain the javascript client. When this script is loaded and ran on the client side browser, I am assuming that by default it uses HTTP to send out the SOAP message to the server right? Which port does it write to - similar to Axis, 8080? Demetris wrote: Hey guys, the documentation says: "It is relatively straightforward to run a CXF service in a Tomcat <http://tomcat.apache.org/> container on z/OS". But the IBM OS is not a requirement correct? I can run this service on any Tomcat container running on any OS right? I know this is an elementary Q but I wanted to make sure there are not OS-specific dependencies. Thanks Benson Margulies wrote: CXF has two things going on here. 1) you can ask the server to generate and deliver the javascript client. 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote: Does CXF support client-side programming for Web Services? What we are after in one of our projects is to: (1) host web services (or at least a Soap engine) on mobile devices (primarily running J2ME CDC) (2) build web service clients on mobile devices, either by discovering and utilizing WSDLs (to generate javascript stubs) or some other mechanism to allow them to generate the client code. Not sure how realistic this is at this stage but I am not finding much on (1) and a bit on (2). Many people have said that generating WSDLs on mobile devices is a difficult task so we are considering the off-the- device mechanisms. Daniel Kulp wrote: On Tue August 11 2009 11:26:05 pm Demetris wrote: Do you know if Axis 1.x can generate document/literal or only rpc/encoded? I am wondering if setting the OPERATION_STYLE_PROPERTY to document would do the trick. I believe Axis1 can do doc/literal. JAX-RPC did require some level of support for that so I'm pretty sure Axis1 implemented it. Not sure how to go about configuring it to do so. I'm not an Axis1 user. :-) Dan Benson Margulies wrote: Demetris, If your place has a big investment in RPC/encoded, perhaps one of you would like to pick up the project that one of our committers started of adding RPC/encoded support to CXF. If you do it, you get to ensure that it works with your services :-). I'd be happy to mentor someone in figuring out where Dain left off. --benson On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote: Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc Basically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS
Re: WSDL2JS
Hey guys,
the documentation says:
"It is relatively straightforward to run a CXF service in a Tomcat
<http://tomcat.apache.org/> container on z/OS". But the IBM OS
is not a requirement correct? I can run this service on any Tomcat
container running on any OS right?
I know this is an elementary Q but I wanted to make sure there are not
OS-specific dependencies.
Thanks
Benson Margulies wrote:
CXF has two things going on here.
1) you can ask the server to generate and deliver the javascript client.
2) you can create a 'dynamic client' that can talk to moderately
complex services.
However, option 2 requires the entire CXF stack on the client, and I
have no idea if J2ME has the necessary goodies.
On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote:
Does CXF support client-side programming for Web Services? What we are after
in one of our projects
is to:
(1) host web services (or at least a Soap engine) on mobile devices
(primarily running J2ME CDC)
(2) build web service clients on mobile devices, either by discovering and
utilizing WSDLs (to generate
javascript stubs) or some other mechanism to allow them to generate the
client code.
Not sure how realistic this is at this stage but I am not finding much on
(1) and a bit on (2). Many people
have said that generating WSDLs on mobile devices is a difficult task so we
are considering the off-the-
device mechanisms.
Daniel Kulp wrote:
On Tue August 11 2009 11:26:05 pm Demetris wrote:
Do you know if Axis 1.x can generate document/literal or only
rpc/encoded? I am wondering if setting
the OPERATION_STYLE_PROPERTY to document would do the trick.
I believe Axis1 can do doc/literal. JAX-RPC did require some level of
support for that so I'm pretty sure Axis1 implemented it. Not sure how to
go about configuring it to do so. I'm not an Axis1 user. :-)
Dan
Benson Margulies wrote:
Demetris,
If your place has a big investment in RPC/encoded, perhaps one of you
would like to pick up the project that one of our committers started
of adding RPC/encoded support to CXF. If you do it, you get to ensure
that it works with your services :-). I'd be happy to mentor someone
in figuring out where Dain left off.
--benson
On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote:
Of course I do see infrastructures here in production still using Axis
1.x without any plans on
migrating while other systems come into play with Axis 2 etc. and
interoperability between the
two sides is impossible - and of course the rest of us will need to sit
in between and needing to
do our own translations - not good.
In any case, CFX is a pretty impressive project so I have a feeling I
will be adapting it to my
work.
Cheers
Daniel Kulp wrote:
On Tue August 11 2009 12:15:40 pm Demetris wrote:
That's what I figured ;) Thanks for the info Benson.
Now regarding inteconnection of Web Services across implementations,
if there is no bridge
between the old RPC/encoded and CFX, at least I am assuming that
newer
versions would
be able to handle SOAP calls across them or not? This is something I
never tried/looked into
while I worked exclusively with Axis so I was wondering.
Pretty much none of the modern SOAP toolkits support RPC/encoded.
Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc
Basically, rpc/encoded was such an interopability nightmare that it
really fell into the bucket of "You REALLY REALLY don't want to use
it."If you want interopability, you really need to migrate to one
of the literal forms.
Dan
Benson Margulies wrote:
OK, that message is buried in the substrate somewhere. I'm not sure
that I agree with it :-) In practical terms, we just don't have the
code or RPC/encoded.
I'm unaware of anything you can use to interconnect an old Axis
RPC/encoded service with CXF.
On Mon, Aug 10, 2009 at 11:00 PM, Demetris
wrote:
Hi Benson,
the reason I mentioned JAX-WS is because a WSDL file that I passed
to WSDL2JS returned
"RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling
it
is "neither here nor
there" but I wanted to double-check - I think I know what the issue
is now after reading the
corresponding documentation but I will return and send more info if
I cannot resolve it.
A separate question - is there a "bridge" between Axis WS and its
tools and CFX? Can an Axis
WS client call a CFX-implemented WS and vice versa or not?
Thanks
Benson Margulies wrote:
Demetris,
CXF includes the ability to build Soap 1.1 Javascript clients for
doc/lit and rpc/lit services. JAX-WS is relatively neither here
nor
there.
The code can be run in two modes. You can run the tool as a
standalone, and you get Javascript that (with the utility file
suppl
Re: WSDL2JS
Hmm - good point on (2). Ok thanks Benson, I will work with (1) first and see how it fairs. It should be straight-forward. Benson Margulies wrote: CXF has two things going on here. 1) you can ask the server to generate and deliver the javascript client. 2) you can create a 'dynamic client' that can talk to moderately complex services. However, option 2 requires the entire CXF stack on the client, and I have no idea if J2ME has the necessary goodies. On Wed, Aug 12, 2009 at 4:47 PM, Demetris wrote: Does CXF support client-side programming for Web Services? What we are after in one of our projects is to: (1) host web services (or at least a Soap engine) on mobile devices (primarily running J2ME CDC) (2) build web service clients on mobile devices, either by discovering and utilizing WSDLs (to generate javascript stubs) or some other mechanism to allow them to generate the client code. Not sure how realistic this is at this stage but I am not finding much on (1) and a bit on (2). Many people have said that generating WSDLs on mobile devices is a difficult task so we are considering the off-the- device mechanisms. Daniel Kulp wrote: On Tue August 11 2009 11:26:05 pm Demetris wrote: Do you know if Axis 1.x can generate document/literal or only rpc/encoded? I am wondering if setting the OPERATION_STYLE_PROPERTY to document would do the trick. I believe Axis1 can do doc/literal. JAX-RPC did require some level of support for that so I'm pretty sure Axis1 implemented it. Not sure how to go about configuring it to do so. I'm not an Axis1 user. :-) Dan Benson Margulies wrote: Demetris, If your place has a big investment in RPC/encoded, perhaps one of you would like to pick up the project that one of our committers started of adding RPC/encoded support to CXF. If you do it, you get to ensure that it works with your services :-). I'd be happy to mentor someone in figuring out where Dain left off. --benson On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote: Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc Basically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009
Re: WSDL2JS
Does CXF support client-side programming for Web Services? What we are after in one of our projects is to: (1) host web services (or at least a Soap engine) on mobile devices (primarily running J2ME CDC) (2) build web service clients on mobile devices, either by discovering and utilizing WSDLs (to generate javascript stubs) or some other mechanism to allow them to generate the client code. Not sure how realistic this is at this stage but I am not finding much on (1) and a bit on (2). Many people have said that generating WSDLs on mobile devices is a difficult task so we are considering the off-the- device mechanisms. Daniel Kulp wrote: On Tue August 11 2009 11:26:05 pm Demetris wrote: Do you know if Axis 1.x can generate document/literal or only rpc/encoded? I am wondering if setting the OPERATION_STYLE_PROPERTY to document would do the trick. I believe Axis1 can do doc/literal. JAX-RPC did require some level of support for that so I'm pretty sure Axis1 implemented it. Not sure how to go about configuring it to do so. I'm not an Axis1 user. :-) Dan Benson Margulies wrote: Demetris, If your place has a big investment in RPC/encoded, perhaps one of you would like to pick up the project that one of our committers started of adding RPC/encoded support to CXF. If you do it, you get to ensure that it works with your services :-). I'd be happy to mentor someone in figuring out where Dain left off. --benson On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote: Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc Basically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote
Re: WSDL2JS
Nicely put - I wouldn't have been messing around with CXF if I didn't think it is worth it and the more I read about the more I am finding a number of fairly interesting directions I can take using it. So yes, I mentioned Axis2 cause I overhead some people talking about it but hey I have no problem advocating CXF here ;) Daniel Kulp wrote: On Tue August 11 2009 11:12:04 pm Demetris wrote: Hi Benson, that would a great opportunity to get to know CXF but I am sure I won't be given the time to work on it. I will certainly pass it on and see if we can get someone to work with you although I still have a feeling that the pressure to migrate to Axis2 is mounting. May I ask "why Axis2"? Axis2 is as similar to Axis1 as CXF is. :-) If you're going to migrate, I'd suggest migrating to a standards based API like JAX-WS and chose one of the really good JAX-WS implementations, like CXF. :-) Dan We (at least I) appreciate the offer Benson and I will make sure the word gets around here. I will let you know how it goes or at least if I have any more Qs on CXF in general. Thanks
Re: WSDL2JS
He he - didn't mean to put you on the spot Dan - but I think you are right so I will chase it in the Axis lists. Daniel Kulp wrote: On Tue August 11 2009 11:26:05 pm Demetris wrote: Do you know if Axis 1.x can generate document/literal or only rpc/encoded? I am wondering if setting the OPERATION_STYLE_PROPERTY to document would do the trick. I believe Axis1 can do doc/literal. JAX-RPC did require some level of support for that so I'm pretty sure Axis1 implemented it. Not sure how to go about configuring it to do so. I'm not an Axis1 user. :-) Dan Benson Margulies wrote: Demetris, If your place has a big investment in RPC/encoded, perhaps one of you would like to pick up the project that one of our committers started of adding RPC/encoded support to CXF. If you do it, you get to ensure that it works with your services :-). I'd be happy to mentor someone in figuring out where Dain left off. --benson On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote: Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. Etc Basically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I a
Re: WSDL2JS
Do you know if Axis 1.x can generate document/literal or only rpc/encoded? I am wondering if setting the OPERATION_STYLE_PROPERTY to document would do the trick. Benson Margulies wrote: Demetris, If your place has a big investment in RPC/encoded, perhaps one of you would like to pick up the project that one of our committers started of adding RPC/encoded support to CXF. If you do it, you get to ensure that it works with your services :-). I'd be happy to mentor someone in figuring out where Dain left off. --benson On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote: Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. EtcBasically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
Hi Benson, that would a great opportunity to get to know CXF but I am sure I won't be given the time to work on it. I will certainly pass it on and see if we can get someone to work with you although I still have a feeling that the pressure to migrate to Axis2 is mounting. We (at least I) appreciate the offer Benson and I will make sure the word gets around here. I will let you know how it goes or at least if I have any more Qs on CXF in general. Thanks Benson Margulies wrote: Demetris, If your place has a big investment in RPC/encoded, perhaps one of you would like to pick up the project that one of our committers started of adding RPC/encoded support to CXF. If you do it, you get to ensure that it works with your services :-). I'd be happy to mentor someone in figuring out where Dain left off. --benson On Tue, Aug 11, 2009 at 4:21 PM, Demetris wrote: Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. EtcBasically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of
Re: WSDL2JS
Of course I do see infrastructures here in production still using Axis 1.x without any plans on migrating while other systems come into play with Axis 2 etc. and interoperability between the two sides is impossible - and of course the rest of us will need to sit in between and needing to do our own translations - not good. In any case, CFX is a pretty impressive project so I have a feeling I will be adapting it to my work. Cheers Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. EtcBasically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
Well that's what I was after and I agree with you - Thanks much Dan Daniel Kulp wrote: On Tue August 11 2009 12:15:40 pm Demetris wrote: That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Pretty much none of the modern SOAP toolkits support RPC/encoded. Axis2 doesn't. CXF doesn't. Metro/JAX-WS RI doesn't. EtcBasically, rpc/encoded was such an interopability nightmare that it really fell into the bucket of "You REALLY REALLY don't want to use it."If you want interopability, you really need to migrate to one of the literal forms. Dan Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
That's what I figured ;) Thanks for the info Benson. Now regarding inteconnection of Web Services across implementations, if there is no bridge between the old RPC/encoded and CFX, at least I am assuming that newer versions would be able to handle SOAP calls across them or not? This is something I never tried/looked into while I worked exclusively with Axis so I was wondering. Benson Margulies wrote: OK, that message is buried in the substrate somewhere. I'm not sure that I agree with it :-) In practical terms, we just don't have the code or RPC/encoded. I'm unaware of anything you can use to interconnect an old Axis RPC/encoded service with CXF. On Mon, Aug 10, 2009 at 11:00 PM, Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
And excuse the typos - CXF I meant to say all along .. :) Demetris wrote: Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
Hi Benson, the reason I mentioned JAX-WS is because a WSDL file that I passed to WSDL2JS returned "RCP/encoded WSDLs are not supported in JAX-2.0". I had a feeling it is "neither here nor there" but I wanted to double-check - I think I know what the issue is now after reading the corresponding documentation but I will return and send more info if I cannot resolve it. A separate question - is there a "bridge" between Axis WS and its tools and CFX? Can an Axis WS client call a CFX-implemented WS and vice versa or not? Thanks Benson Margulies wrote: Demetris, CXF includes the ability to build Soap 1.1 Javascript clients for doc/lit and rpc/lit services. JAX-WS is relatively neither here nor there. The code can be run in two modes. You can run the tool as a standalone, and you get Javascript that (with the utility file supplied) will run anywhere that has a compatible request object. Or, you can ask any CXF-implemented web service to deliver a javascript client, and one will be returned. Have you read http://cwiki.apache.org/CXF20DOC/javascript-clients.html? --benson On Mon, Aug 10, 2009 at 5:40 PM, Demetris wrote: And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
And one more observation - because wsdl2js utilizes JAX-WS 2.0, RPC/Encoded documents are not supported. Is that correct? Thanks again Demetris wrote: Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
Ok now that I played a bit with wsdl2js I am beginning to understand what you said below. So one can use the wsdlurl in order to get the server to return the script - can you please clarify a few things since I am new to this - 1. what kind of server are we talking about in this case? 2. The only way to generate the Javascript is through a remote server + URL? If I have the WSDL in my possesion how can I use this tool to generate the script of me? Thanks again Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
Re: WSDL2JS
Hi Benson, thanks for the response - that was for cases where the mobile device is hosting a Web Service then that server would be running under J2ME (ex. mAS) but I need to think that through a bit more first. However, you did answer my question regarding the tool. Thanks Benson Margulies wrote: The tool is part of CXF, so it requires Java 1.5. Since its output is Javascript, I don't understand why you need to run it under J2ME. In fact, you can just use the ?js URL form from the server to get the server to generate it on the fly. On Mon, Aug 10, 2009 at 2:32 PM, Demetris wrote: Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
WSDL2JS
Hi all, I am interested in generating Javascript stubs from a WSDL file - I am assuming that the WSDL2js tool is the appropriate tool to use. Has anyone used this tool so that I can ask a couple of Qs? (1) Which Java version is the tool built on? (2) Can I used it under J2ME-CDC to generate stubs for mobile devices? Thanks in advanced
