[
https://issues.apache.org/jira/browse/CXF-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099268#comment-17099268
]
Ranjit Vadakkan commented on CXF-5216:
--------------------------------------
Can this please be revisited? As was previously noted,
WSDLManager.getDefinition either gets a definition from its cache or loads it
from the URL. This means that for a new URL that isn't in the cache, it needs
to be loaded twice from the URL - once for removal (a waste), and then later
when it really needs to load.
bus.getExtension(WSDLManager.class).removeDefinition(bus.getExtension(WSDLManager.class).getDefinition(url));
> 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 Yue Fang
> Priority: Major
> Fix For: Invalid
>
> 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 was sent by Atlassian Jira
(v8.3.4#803005)
