CGJ & JBoss.Net developers, After working with wsdl2Java, I have come to the conclusion that the wsdl being generated by org.jboss.net.jmx.server.MBeanProvider is not accurate. I have included both the WSDL and the interface generated by wsdl2Java. Any ideas? It seems to me that the method signatures of my MBean should show up in the wsdl. Is this an accurate assumption? If so, what might be preventing accurate wsdl generation in this case?
- Matt <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://localhost:8080/jboss-net/services/CustomTerminologyM anagementService" xmlns="http://schemas.xmlsoap.org/wsdl/"; xmlns:apachesoap="http://xml.apache.org/xml-soap"; xmlns:impl="http://localhost:8080/jboss-net/services/CustomTerminologyManage mentService" xmlns:intf="http://localhost:8080/jboss-net/services/CustomTerminologyManage mentService" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";> <wsdl:portType name="XMBean"> </wsdl:portType> <wsdl:binding name="CustomTerminologyManagementServiceSoapBinding" type="impl:XMBean"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> </wsdl:binding> <wsdl:service name="XMBeanService"> <wsdl:port binding="impl:CustomTerminologyManagementServiceSoapBinding" name="CustomTerminologyManagementService"> <wsdlsoap:address location="http://localhost:8080/jboss-net/services/CustomTerminologyManageme ntService"/> </wsdl:port> </wsdl:service> </wsdl:definitions> /** * XMBean.java * * This file was auto-generated from WSDL * by the Apache Axis WSDL2Java emitter. */ package localhost; public interface XMBean extends java.rmi.Remote { } -----Original Message----- From: Matt Munz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 10:49 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] writing a jboss.net (jmx.net?) client CGJ, Thanks for your response. > A) generate wsdl from the deployed web services. > B) generate stub classes from the wsdl using wsdl2java. This is the first thing that I tried and it did not work. I didn't take a lot of time to firgure out why this is the case, since the jboss.net testcase code was easy to understand, so I may have missed something simple... > This may work for simple cases, but once you declare additional > data structures and serializers, it becomes very hairy on the client side, > otherwise. Well, for my purposes, I don't intend on sending complex Object graphs "over the wire". I also think that the Bean Serializer should be sufficient for my purposes. By "may work", do you mean "will work without errors for simple cases", or "probably won't work for any case, so don't even try it"? Is there a test case that demonstrates the technique (A & B above) that you reccommend? I would find this quite useful. If I have time, I'll try to write one myself, if it doesn't already exist. On code generation in general, I must admit that I have a bit of healthy skepticism on the matter. In this example, the amount of client side code required to use the deprecated technique totals no more than a few lines, while the output of wsdl2java comprises multiple full-fledged classes. It seems to me that, auto-generated or not, this compromises a significant ramp-up in code maitennance costs. Based on your experience, what makes code generation the way to go in this case? Do you find the generated code reasonable, easy to maintain, scalable, reliable, etc.? - Matt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jung , Dr. Christoph Sent: Tuesday, September 24, 2002 10:06 AM To: '[EMAIL PROTECTED]' Subject: AW: [JBoss-dev] writing a jboss.net (jmx.net?) client Matt, For getting the client-side invocations and stub classes right, we recommend The following steps: A) generate wsdl from the deployed web services. B) generate stub classes from the wsdl using wsdl2java. Using Axis/MbeanInvocationHandler lacks a lot of deployment information (basically, The client-side of the web-service.xml) that we try to default from java reflection. This may work for simple cases, but once you declare additional data structures and serializers, it becomes very hairy on the client side, otherwise. CGJ -----Ursprüngliche Nachricht----- Von: Matt Munz [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 20. September 2002 17:41 An: JBoss Developers Group Betreff: [JBoss-dev] writing a jboss.net (jmx.net?) client CGJ & JBoss.Net Developers, First, let me say "Thank you". I now have MBeans in the server exposed as web services. Although it took a bit of research to figure out how to do this, the minimal amount of (xml) code required to expose MBeans as webservices (should I call this "JMX.Net"?) speaks for itself. I was again pleased to see that the client side is also straightforward, once I knew what to do. Basically, I emulated the code in the testsuite for JBoss.Net. This works with the following caveat. The org.jboss.net.axis.AxisInvocationHandler class is deprecated. MBeanInvocationHandler, the class I am using on the client side, extends AxisInvocationHandler. What should I do instead of using this class (which seems to work perfectly well)? I found the following in AxisInvocationHandler. Could anyone explain this further? Due to the inherent deficiencies in using pure reflection meat-data to access web services, we recommend using the axis "stub" way of creating web service references Thanks again. - Matt ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
