Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 86197 invoked by uid 500); 8 Feb 2002 14:03:10 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 86188 invoked from network); 8 Feb 2002 14:03:10 -0000 Message-ID: <849C1D32E4C7924F854D8A0356C72A9E017164F4@usilms08.ca.com> From: "Sedukhin, Igor" To: axis-dev@xml.apache.org Subject: RE: Caching generated WSDL Date: Fri, 8 Feb 2002 09:01:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I think caching should be selectable by a parameter on the service. I can have a dynamic classloader, similar to catalina's WebAppClassLoader that would refresh JARs when they are updated on the file system. It may be very difficult for Axis, or for anyone really, to check all type dependencies to find out that something has been changed in the class hierarchy that relates to the exposed svc. WSDL requests are not that frequent anyway, so I may choose to generate (refresh) WSDL for every such request. -- Igor Sedukhin .. (Igor.Sedukhin@ca.com) -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788 -----Original Message----- From: Glen Daniels [mailto:gdaniels@macromedia.com] Sent: Friday, February 08, 2002 12:43 AM To: 'axis-dev@xml.apache.org' Subject: Caching generated WSDL Let's say we wanted to cache the WSDL generated by the ?WSDL URLs, and also perhaps provide a way for a service to specify its own WSDL. The simple way to do this might be to specify a WSDL output directory property. Then each time a given service's WSDL is requested, we first check for a ServiceName.wsdl file in that directory and simply send that if it exists instead of running the emitter. We don't want the cached WSDL to get out of sync with the class definitions, so we need a way to say "if the file is older than the last class reload, regen it". For non-JWS files, it's probably good enough to mark when the AxisServer starts up, and then generate each service once after that. For JWS classes, we have the time available and so can be a bit more dynamic. If you want to specify a static file which should always be used rather than autogen, perhaps we could simply put that as a parameter of the deployment: What do folks think about this direction? Should we add it to the to-do list? --G