Description of problem: Link to: JBIDE-11466 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Douglas Palmer <dpalmer> updated the status of jira JBIDE-11466 to Resolved
Douglas Palmer <dpalmer> made a comment on jira JBIDE-11466 Fixed in org.eclipse.bpel and incorporated into the CR1 build.
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-11466 Tested on JBDS 5 GA + SOA Tooling CR 1 with partial success. The editor is not blocked, but the wsdl file cannot be imported via 'import' wizard (only to copy as a file). This issue can be closed after resolving JBIDE-11965.
Hi Andrej, how are you testing this because it works for me using the bits from https://devstudio.jboss.com/updates/5.0/staging/soa-tooling/ If you are trying to import from a webserver (like http://localhost:8080/sample.wsdl maybe?) make sure the server is running and the file is available. Also, please check if the plugin version for org.eclipse.bpel.common.wsdl you are testing is 1.0.1.v20120619-something.
Robert (Bob) Brodt <bbrodt> made a comment on jira JBIDE-8531 Andrej, adding a WSDL that is not in the same project as the process is NOT supported - this error message is correct and is working as intended. Using WSDLs from another project creates dependency issues that the runtime may not be able to resolve.
Robert (Bob) Brodt <bbrodt> updated the status of jira JBIDE-8531 to Resolved
Robert (Bob) Brodt <bbrodt> made a comment on jira JBIDE-8531 Works as designed
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-8531 OK, but what does it mean "the ability of a BPEL project to reference WSDLs (and probably XSDs as well) in another project without having to make copies"?
Marek Baluch <mbaluch> made a comment on jira JBIDE-8531 Hi Bob, you are correct. The runtime cannot handle WSDLs imported this way (the path ../../pathToWsdl becomes invalid). My question is why do we allow to do the import in the first place? IMHO this Feature Request is not a valid use case. I myself don't see any advantages. Now you can import a WSDL from another project only to see an error in the problems tab which says exactly as mentioned in Andrej's comment (https://issues.jboss.org/secure/ViewProfile.jspa?name=apodhrad). And the problem is shown for a good reason! What would be the correct approach in this case? Copy the WSDL to a local folder? Any thoughts? Cheers! Marek
Marek Baluch <mbaluch> made a comment on jira JBIDE-8531 Hi Bob, you are correct. The runtime cannot handle WSDLs imported this way (the path ../../pathToWsdl becomes invalid). My question is why do we allow to do the import in the first place? IMHO this Feature Request is not a valid use case. I myself don't see any advantages. Now you can import a WSDL from another project only to see an error in the problems tab which says exactly as mentioned in Andrej's comment (https://issues.jboss.org/secure/ViewProfile.jspa?name=apodhrad). And the problem is shown for a good reason! What would be the correct approach in this case? Copy the WSDL do a local folder or do the import as an URL based on the SOAP address of the service? Any thoughts? Cheers! Marek
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-11965 Steps to reproduce: 1. Deploy helloworld.esb (in the attachment) 2. Create new BPEL project 3. File > Import... > WSDL > WSDL 4. As WSDL URI set http://localhost:8080/helloworld/ebws/FirstServiceESB/SimpleListener?wsdl Note that importing as a reference is working (open bpel file > Imports tab > Import a WSDL).
Robert (Bob) Brodt <bbrodt> made a comment on jira JBIDE-8531 The original idea was to have the deployer resolve those WSDLs that are not in the current project, add them to the deployment package, and then fix up the <import> locations in the BPEL process. This could potentially cause all kinds of resource synchronization problems that need to be carefully thought out before we jump into this. I'm thinking this BZ should be planned for a future release...any thoughts?
Robert (Bob) Brodt <bbrodt> made a comment on jira JBIDE-11965 Ah ha <light bulb>! Now I get it :) The WSDL URI has a "?" separator instead of a "." - sorry, I missed that one earlier.
Len DiMaggio <ldimaggi> made a comment on jira JBIDE-8531 I agree! The user is not blocked - it's an RFE/
Andrej Podhradsky <apodhrad> updated the status of jira JBIDE-11965 to Resolved
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-11965 Maybe Bob forgot to set this issue as resolved because it is fixed in JBTIS 4.1.2
Andrej Podhradsky <apodhrad> updated the status of jira JBIDE-11965 to Closed
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-11965 Verified with JBTIS 4.1.2.
Andrej Podhradsky <apodhrad> updated the status of jira JBIDE-8531 to Closed
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-8531 Verified with JBTIS 4.1.2
Andrej Podhradsky <apodhrad> updated the status of jira JBIDE-8531 to Reopened
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-8531 Closed by mistake :(
Andrej Podhradsky <apodhrad> updated the status of jira JBIDE-11466 to Closed
Andrej Podhradsky <apodhrad> made a comment on jira JBIDE-11466 Verified with JBTIS 4.1.2
Robert (Bob) Brodt <bbrodt> updated the status of jira JBIDE-8531 to Reopened
Robert (Bob) Brodt <bbrodt> updated the status of jira JBIDE-8531 to Closed
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.