Don't Use Spaces in Directories: Problem importing XML Schema in BPEL Process

7

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".

 Creating a simple BPEL process

Then, I needed to import an XML Schema into this process. The "Import Schema" dialog showed as follows:

The "Import Schema" dialog

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:

BPEL Structure showing imported Schema

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:

 Creating Variable based on Schema element

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:

Error when finishing the Create Variable dialog

 

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.

Correct Import Schema dialog

 

Share.

About Author

7 Comments

  1. Thanks dude, I was figthing all morning till I found this site.!!
     
    :D

  2. Thank god I googled on this error and found your site…many thanks for a nice diagnosis..saved my time

  3. 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.