0 
0 Ever since Microsoft introduced long filenames back in whenever, using spaces in file or directory names has always been tricky. As I found out recently, even with modern software like the BPEL Designer in JDeveloper, using spaces in your directory structure might come back to haunt you, in the most unlikely and roundabout ways.
I had created a default synchronous BPEL process “BPELProcess1” in directory “C:\My BPEL\BPELProcess1”.
Then, I needed to import an XML Schema into this process. The “Import Schema” dialog showed as follows:
As you can see, the “Import Into:” poplist showed empty. This poplist, which is new in JDeveloper 10.1.3, allows you to specify into which project WSDL this schema will be imported. This is an improvement over 10.1.2 where it was implicitely (and arbitrarily) added to one of the project WSDL files. But if this poplist is empty, well, what do you do? You click OK and continue on your business, right?
And that is where you would go wrong. Because this poplist should not be empty. The reason it _is_ empty, well, that’s because this BPEL project was created in the directory C:\My BPEL\. With a space. Ergo the empty poplist. Makes sense, right?
But what is worse is that nothing seems to be wrong at this time. The newly imported schema shows normally in the BPEL Structure:
The project even compiles without a problem. It doesn’t go wrong until you start using the Schema, for instance when you declare a Process Variable based on an element defined in the Schema:
Still, not a single sign of trouble, the Schema is present, it folds open to show the elements that it defines, you can select one and press OK, and still everything is fine. Only when you press the final OK in the “Create Variable” dialog will you hit an error:
As I’m sure you will agree, the message “In order to save imported wsdl/schema files, you must have a partner link located under the current project directory” is rather confusing. First, we’re not trying to save a schema but a Variable. Then, there definately is a partner link in the current project directory. To say the least, it sent me on a wild goose chase for a while.
Only in retrospect does it make some sense. It just arrived way to late: this message should have been shown at the end of the “Import Schema” dialog. And the part about needing a partner link, well, that’s because there is a bug in the algorithm that searches for these partnerlinks: it can’t deal with spaces in the directory name. The same algorithm was used to fill the poplist on the “Import Schema” dialog.
So the only thing we need to remedy this situation is to change the directory name to C:\MyBPEL without a space. Then, the “Import Schema” dialog looks like it should, and everything works just like it should again.
Related posts:
Oracle JDeveloper 10.1.3.1.0 has just been released on OTN 
Solving SOA Suite installation issues SOA Suite Build, Deployment and Test Automation – part 1 
Het Oracle OpenWorld Preview Evenement (5 september 2013) – 15 sprekers & sessies 
The AMIS Summary of Oracle OpenWorld 2013 is available for download – 60-page white paper
Thanks dude, I was figthing all morning till I found this site.!!
Â
😀
Thanks a loot for such a valuable post!
Thank god I googled on this error and found your site…many thanks for a nice diagnosis..saved my time
Thanks a lot Peter. That tip definitely helped.
Very Help full,
Thanks so much for sharing this information !!
Very helpful, was pulling my hair out!
Thanks
We made some headway in crunching several of bugs of this kind for the future JDeveloper 11g release (although I can’t say for sure whether this specific one is fixed).
One thing that made it easier to find them for a while was that we changed the default “mywork” folder to be in the standard, very space-loaded, place on Windows (C:\Documents and Settings\username\My Documents). For a brief period of about a month, it was really easy to find these problems, as the significant number of Oracle internal users with in-development builds were running into them frequently. Unfortunately, for various reasons, the decision was taken not to use the standard documents location for mywork after all in 11g, so some of these problems sadly continue to go unnoticed by internal development and QA.
Hopefully a future release will focus more testing on this issue.