Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 803F010978 for ; Tue, 20 Aug 2013 07:14:40 +0000 (UTC) Received: (qmail 70371 invoked by uid 500); 20 Aug 2013 07:14:39 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 70323 invoked by uid 500); 20 Aug 2013 07:14:39 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 70310 invoked by uid 99); 20 Aug 2013 07:14:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Aug 2013 07:14:38 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of luckyzhubin@gmail.com designates 209.85.217.171 as permitted sender) Received: from [209.85.217.171] (HELO mail-lb0-f171.google.com) (209.85.217.171) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Aug 2013 07:14:34 +0000 Received: by mail-lb0-f171.google.com with SMTP id t13so210086lbd.2 for ; Tue, 20 Aug 2013 00:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=aEmJl2dsRMKV2i4OSeETHZS+c1mkHC0NIZeWUwiQ4xg=; b=k/59Nqz5yhQ/3g6YvzioV/HJ/F11ixOMocmxLFh/aga+g56/Dj27NfFmiw+puR0OXt +5VuLmy/1gd7PFsd/45xDgYdQIOpxX21PzRW3l3ARFTtc0Yfx9ZYdOF9AroygEBgGc6f Rp4KcPF0XtJFNIpE8RkgKAdtwJ2SaNUz0uJPbKAu2k9IaJ4wfIr9DkpY+4O/1riPa8Sm qlG+OSAeuDZzy5tBjHmbKY3HQKbTIKS3gq3cFCmb+5DV863OAidxcmey4gx9oQg+Ei6V BOzI2VDaB/7WF0Nk3dIry25Z+4P8dC+mH0kXEjk9yo2rHtHkr8GsSt4IKFdas0IDizyK vOIg== MIME-Version: 1.0 X-Received: by 10.112.26.106 with SMTP id k10mr1537859lbg.27.1376982852110; Tue, 20 Aug 2013 00:14:12 -0700 (PDT) Received: by 10.114.180.42 with HTTP; Tue, 20 Aug 2013 00:14:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Aug 2013 15:14:12 +0800 Message-ID: Subject: Re: [jira] [Commented] (CXF-5216) WSDL definition cache issue for web service client when WSDL in service war changed From: Bin Zhu To: dev@cxf.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org I should check if it's in cache by using getDefinitions(), if yes, then remove it. This will not increase any addition effort to get the correct definition for the WSDL. Thanks Freeman for all the help, it solved my problems. 2013/8/20, Freeman Fang (JIRA) : > > [ > https://issues.apache.org/jira/browse/CXF-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13744740#comment-13744740 > ] > > Freeman Fang commented on CXF-5216: > ----------------------------------- > > No, using code like > {code} > bus.getExtension(WSDLManager.class).removeDefinition(bus.getExtension(WSDLManager.class).getDefinition(url)); > {code} > > the wsdl would be loaded at most once, or zero if it's already in the cache. > And you actually can check if it's already in the cache, as the WSDLManager > has API like > {code} > public Map getDefinitions() > {code} > > Freeman > >> WSDL definition cache issue for web service client when WSDL in service >> war changed >> ----------------------------------------------------------------------------------- >> >> Key: CXF-5216 >> URL: https://issues.apache.org/jira/browse/CXF-5216 >> Project: CXF >> Issue Type: Bug >> Affects Versions: 2.6.2 >> Reporter: Bin Zhu >> Assignee: Freeman Fang >> Attachments: CXF-5216-2.patch, CXF-5216.patch >> >> >> In current design, the WSDL definition will be cached in case the the same >> wsdl will be queried later.(WSDLManagerImpl.getDefinition) >> e.g. >> public Definition getDefinition(String url) throws WSDLException { >> synchronized (definitionsMap) { >> if (definitionsMap.containsKey(url)) { >> return definitionsMap.get(url); >> } >> } >> return loadDefinition(url); >> } >> The cache mechanism indeed improves the performance in most scenarios. But >> if the WSDL file in service provider app changed, the client will not get >> the correct WSDL definition even using retrieves the wsdl from server >> dynamically (http://hostname:portname/xxx?wsdl),unless restarting the >> client app. >> It would be more reasonable to introduce a client property to allow user >> to disable the definition cache so that they can choose if they get WSDL >> definition from cache or the URL dynamically for their scenarios. Any >> thoughts? Thanks. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira >