Community
Participate
Working Groups
We found a problem in the Web Services Explorer when handling certain WSDL file (see bug 175842). Debugging that problem indicated that this is a WSDL4J problem and is deemed to have been fixed in the latest version. Please upgrade wsdl4j in the next release of WTP.
Moving to wst.wsdl component
Please consider this for WTP 3.0.
*** Bug 185198 has been marked as a duplicate of this bug. ***
This bug 103504 is asking for an upgrade to WSDL4J 1.6.2.
This upgrade cannot be contained in the 3.0 timeframe. We will try in the next major WTP release.
Let's investigate what we can do in the WSDL EMF model to facilitate WTP moving to a new version of WSDL4J (initially 1.5.1). We should consider working in a branch to evaluate the impact and we'll make a final decision once the facts are in.
Given the sensitivity of this upgrade we will take an incremental approach. We will first upgrade the components that depend only on javax.wsdl. These are the WSDL and WS-I validators. See bug 252257 and bug 252258. Then we will try to update the WSDL EMF model, regenerate the code and get it to compile, while perhaps leaving some of the new APIs not implemented. We will then fill in the blanks. Once all this is done we can re-assess and see how much time there is left to perhaps move all the way to javax.wsdl_1.6.
Just want to make a note that before releasing the code into WTP 3.1, we would like to request to have a test build (say a HEAD build or patched JARs) so that we could test the changes with the Web services wizards and WSE to make sure that they are not adversely impacted by the changes.
Created attachment 121913 [details] Rough patch Here is the first rough patch with WSDL EMF model changes. The changes include (roughly aligned with the changes in JWSDL 1.1): - ExtensibleElement now extends the new JWSDL interface ElementExtensible instead of modelling the methods itself. All extensibility element method implementations are unchanged in ExtensibleElementImpl. - ExtensibleElement now extends the new JWSDL interface AttributeExtensible. JWSDL only requires certain objects to have this functionality but I decided to have all objects implement it now because we will eventually have to do it when we move to JWSDL 1.2. This also allows the implementation of the four methods of this interface to live nicely into one class instead of being coded in more than one. This potential implementation redundancy could have been avoided by introducing some other intermediary class but I figured I don't want to add it just to remove it later on. - I have changed XSDSchemaExtensibilityElement to extend the new javax.wsdl.extensions.schema.Schema interface. The implementation contains only method stubs for the new methods for now, except for get/setElement which were already there. - I have modelled two new objects SchemaReference and SchemaImport to mirror the similar new interfaces from javax.wsdl.extensions.schema. I have modelled their features. - I have updated the org.eclipse.wst.wsdl, org.eclipse.wst.wsdl.tests and org.eclipse.wst.wsdl.ui plug-ins to make sure they pick up javax.wsdl [1.5.0, 1.6.0) The code compiles, all existing WSDL model JUnit tests pass and the WSDL editor seems to function OK superficially. Some things to ponder: - MIMEPart seems to be special: it currently models the extensibility element related methods. It could / should probably extend ElementExtensible to align it with JWSDL - PartImpl still contains the old attribute extensibility methods. These will have to be removed later on. - How should we bump the WSDL model version: minor or major? In general, the changes appear to be API additions or compatible changes, except perhaps for the Part related interface changes (getExtensibilityAttribute returning Object instead of QName). - We'll need new JUnit tests for the new features (extensibility attributes and lightweight schema support). Amy, please give this patch a try and if it seems OK let's use it, together with the WSDL and WS-I validator patches to do some testing with the Java WS tools. You'll need wst.wsdl, wst.wsdl.tests and wst.wsdl.ui in your workspace.
Created attachment 122487 [details] wsdlemf.txt Here is an updated patch. (In reply to comment #9) > - I have modelled two new objects SchemaReference and SchemaImport to mirror > the similar new interfaces from javax.wsdl.extensions.schema. I have modelled > their features. I backed out of this specific change since we're currently doing nothing different between our model and the wsdl4j model, so we should not have our own implementation. This also means that in WSDLAdapterFactory & WSDLSwitch, SchemaReference & SchemaImport will not be supported. > Some things to ponder: > - How should we bump the WSDL model version: minor or major? In general, the > changes appear to be API additions or compatible changes, except perhaps for > the Part related interface changes (getExtensibilityAttribute returning Object > instead of QName). I also increased the minor version number in org.eclipse.wst.wsdl to 1.2.0. I also noticed org.eclipse.wst.wsdl.ui.tests was not updated to pick up javax.wsdl 1.5, so I went ahead and updated its manifest.mf as well. I also saw a compile error in WSDLParser about a try/catch block where the catch was unreachable code, so I removed that as well.
Created attachment 122589 [details] wsdlemf2.txt This patch is the same as the previous one except I added back the try/catch clause that I had taken out (turns out there was just something funny with my dev env)
fix released to this week's wtp 3.1 m5
This bug has been in resolved state for a while. Please verify this defect with the latest WTP 3.0.4 or WTP 3.5 build from: http://download.eclipse.org/webtools/downloads/ If this is not verified within 2 weeks, we'll be verifying the bug on your behalf. Thanks!
Verified and closing.
