Easy-WSDL

The SOAP component caches the imports of WSDL

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.3
  • Fix Version/s: 2.3
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    WSDL can use external imports (through url). If we install a provide service unit using such WSDL, it works fine...but things get a bit wrong when we choose to uninstall this provide service unit, modify the imports and re-install the same service unit we have a problem. The component gives us the old XSD !

    Reproduction :

    • Install & configure a new Apache server (on localhost, which allows you to use the given SA directly)
    • copy the content of the svn.zip in /var/www
    • launch Petals ESB
    • Modify the SE-XSLT to use the given conf.xml
    • Modify the SE-KPI to use the given petalsview.properties
    • Deploy the shared library
    • Deploy all the components
    • Deploy the given service assembly
    • Get the WSDL exposed by the SOAP-BC
    • take a look at the imported XSD (by following their url)
    • Undeploy the service assembly
    • Change the content of the XSD
    • Redeploy the service assembly
    • Get the WSDL exposed by the SOAP-BC
    • take a look at the imported XSD ==> woops
    Show
    WSDL can use external imports (through url). If we install a provide service unit using such WSDL, it works fine...but things get a bit wrong when we choose to uninstall this provide service unit, modify the imports and re-install the same service unit we have a problem. The component gives us the old XSD ! Reproduction :
    • Install & configure a new Apache server (on localhost, which allows you to use the given SA directly)
    • copy the content of the svn.zip in /var/www
    • launch Petals ESB
    • Modify the SE-XSLT to use the given conf.xml
    • Modify the SE-KPI to use the given petalsview.properties
    • Deploy the shared library
    • Deploy all the components
    • Deploy the given service assembly
    • Get the WSDL exposed by the SOAP-BC
    • take a look at the imported XSD (by following their url)
    • Undeploy the service assembly
    • Change the content of the XSD
    • Redeploy the service assembly
    • Get the WSDL exposed by the SOAP-BC
    • take a look at the imported XSD ==> woops
  • Environment:
    PetalsESB 3.1 / petals-se-notification / petals-se-kpi 1.0.4 / petals-bc-soap / petals-se-xslt (mod veolia) / petals-se-eip

Attachments

  1. XML File
    conf.xml
    (0.5 kB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:34:34 +0200
  2. Zip Archive
    petals-bc-soap-4.0.3-20100704.073518-7.zip
    (16.83 MB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:59:35 +0200
  3. Zip Archive
    petals-se-eip-2.5-20100610.103318-7.zip
    (4.54 MB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:51:57 +0200
  4. Zip Archive
    petals-se-kpi-1.0.4-SNAPSHOT.zip
    (17.77 MB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:45:42 +0200
  5. Zip Archive
    petals-se-notification-1.0.2.zip
    (4.55 MB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:40:26 +0200
  6. Zip Archive
    petals-se-xslt-2.3.3-SNAPSHOT.zip
    (6.12 MB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:54:10 +0200
  7. File
    petals-view.properties
    (2 kB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:34:34 +0200
  8. Zip Archive
    sa-AD004-RecupMissionSigma-1.0.0-SNAPSHOT.zip
    (92 kB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:35:07 +0200
  9. Zip Archive
    sl-oracle-driver-10.2.0.2.zip
    (1.40 MB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:35:07 +0200
  10. File
    svn.zip.1
    (18 kB)
    Charles Casadei
    Tue, 3 Aug 2010 - 09:34:34 +0200

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Casadei added a comment - Thu, 5 Aug 2010 - 12:33:21 +0200

It seems like the svn.zip does not contain all the required XSDs. I have put them in the blocked issue

Show
Charles Casadei added a comment - Thu, 5 Aug 2010 - 12:33:21 +0200 It seems like the svn.zip does not contain all the required XSDs. I have put them in the blocked issue
Hide
Permalink
mjambert added a comment - Fri, 6 Aug 2010 - 11:31:24 +0200

The problem comes from a shared static instance of SchemaReader.
when readExternalPart is called, a boolean (deleteImports) determines if reader must use cached imported schemas or flush its cache before.

I do not understand how such a cache could be reliable. From a performance point of view, I cannot see any point either since imports should be resolved once at SA deployment time...

Otherly said, does anybody know why this cache was originally introduced ??

If no proper reason is given, a possible fix is to never use the cache.

Show
mjambert added a comment - Fri, 6 Aug 2010 - 11:31:24 +0200 The problem comes from a shared static instance of SchemaReader. when readExternalPart is called, a boolean (deleteImports) determines if reader must use cached imported schemas or flush its cache before. I do not understand how such a cache could be reliable. From a performance point of view, I cannot see any point either since imports should be resolved once at SA deployment time... Otherly said, does anybody know why this cache was originally introduced ?? If no proper reason is given, a possible fix is to never use the cache.
Hide
Permalink
Charles Casadei added a comment - Fri, 20 Aug 2010 - 12:02:05 +0200

The fix works just fine thanks

Show
Charles Casadei added a comment - Fri, 20 Aug 2010 - 12:02:05 +0200 The fix works just fine thanks

People

Dates

  • Created:
    Tue, 3 Aug 2010 - 09:20:55 +0200
    Updated:
    Fri, 20 Aug 2010 - 12:02:05 +0200
    Resolved:
    Tue, 10 Aug 2010 - 08:54:29 +0200

Time Tracking

Estimated:
Not Specified
Original Estimate - Not Specified
Remaining:
0m
Remaining Estimate - 0 minutes
Logged:
1d 2h
Time Spent - 1 day, 2 hours
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.