Following the instructions given in section "Generating a Schema using
the WsdlBuilder" found in "Web Services Developer's Guide, page 99, we use class WsdlBuilder to generate a WSDL from our domain model. Since we need to dynamically alter the WSDL based on settings in the product, customers generate their WSDL from a runtime image. This process works OK, the resulting WSDL is valid. Our problem is that the VisualWorks WSDL building process relies on looking at methods with pragmas in a specific protocol. The default protocol searched is "public api". Since we generate from a runtime image, we need to keep the organization of the code by using "removeOrganization: false" in the runtime packager. Without this, the WSDL generation fails. Unfortunately, including protocol information in the runtime image doubles the size of the image. Is there an easy way (without overriding Cincom's code) to do WSDL generation without relying on methods being in a specific protocol? One solution to this problem would be if Cincom changed PragmaHandler class>>defaultServiceProtocol to not default its value to 'public api' when the value is set to nil. Runar Jordahl _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Runar Jordahl wrote:
> Our problem is that the VisualWorks WSDL building process relies on > looking at methods with pragmas in a specific protocol. The default > protocol searched is "public api". Since we generate from a runtime > image, we need to keep the organization of the code by using > "removeOrganization: false" in the runtime packager. Without this, the > WSDL generation fails. Unfortunately, including protocol information > in the runtime image doubles the size of the image. There's no way that including protocols should double the size of the runtime image. Try saving with and without protocols, and compare the RTP report to see what else is being left in the image. Steve _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
Am 29.07.08 14:06 schrieb "Runar Jordahl" unter <[hidden email]>:
> Is there an easy way (without overriding Cincom's code) to do WSDL > generation without relying on methods being in a specific protocol? > > One solution to this problem would be if Cincom changed PragmaHandler > class>>defaultServiceProtocol to not default its value to 'public api' > when the value is set to nil. As protocols are usually not present in runtime images, nothing except development tools should rely on them. Also, if the relevant methods are tagged with pragmas and can easily be looked up, why is there an additional restriction that they must be in a specific protocol? That should be superfluous. When generating Smalltalk methods, it's okay to specify a default protocol, but also in this case, it must work in a runtime where the organization has been removed. Disclaimer: This is pure speculation, I have never looked at the code in question. ;-) The description of the problem just sounded odd to me. Cheers, Joachim _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
Created
54862: "Web Services WSDL Generation without Using Method Protocol" > Is there an easy way (without overriding Cincom's code) to do WSDL > generation without relying on methods being in a specific protocol? No way right now. Tamara Kogan Smalltalk development, Cincom Systems > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf > Of Runar Jordahl > Sent: Tuesday, July 29, 2008 8:07 AM > To: [hidden email] > Subject: [vwnc] Web Services WSDL Generation without Using Method Protocol > > Following the instructions given in section "Generating a Schema using > the WsdlBuilder" found in "Web Services Developer's Guide, page 99, we > use class WsdlBuilder to generate a WSDL from our domain model. Since > we need to dynamically alter the WSDL based on settings in the > product, customers generate their WSDL from a runtime image. This > process works OK, the resulting WSDL is valid. > > Our problem is that the VisualWorks WSDL building process relies on > looking at methods with pragmas in a specific protocol. The default > protocol searched is "public api". Since we generate from a runtime > image, we need to keep the organization of the code by using > "removeOrganization: false" in the runtime packager. Without this, the > WSDL generation fails. Unfortunately, including protocol information > in the runtime image doubles the size of the image. > > Is there an easy way (without overriding Cincom's code) to do WSDL > generation without relying on methods being in a specific protocol? > > One solution to this problem would be if Cincom changed PragmaHandler > class>>defaultServiceProtocol to not default its value to 'public api' > when the value is set to nil. > > Runar Jordahl > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |