Seen with Product Version: NetBeans IDE Dev (Build 200708270201) Java: 1.6.0_01; Java HotSpot(TM) Client VM
1.6.0_01-b06 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and
1. Open the attached BPEL module as a project.
2. Define a new comp app and open it in the CASA editor.
3. Dnd The BPEL module into the CASA editor.
4. Click the Build Project button.
5. Add a new SOAP WSDL port.
6. Delete the connection between the original SOAP WSDL port and the BPEL project.
7. Add a connection between the new SOAP WSDL port and the BPEL project.
8. Click the CASA Build Project button again.
9. In the Projects pane, find and open the generated *.wsdl file in the comp app in the WSDL source editor.
10. Make an error in the WSDL file and save.
11. In the CASA editor, try to open the properties for the editable SOAP port.
==> IllegalStateException. Stack trace and uigestures file attached.
Created attachment 47755 [details]
BPEL module used in scenario.
Created attachment 47756 [details]
Created attachment 47757 [details]
NB log file
1. Hiding the <compapp>.wsdl in project tab probably won't solve all the problems, because we could also have
user-defined WSDL files (like the BC-2-BC case) defined in CompApp that we don't want to hide.
2. For the same reason, making the WSDL file read-only doesn't work for user-defined WSDL files.
3. Warning message in WSDL file? If the user doesn't go to the source view of the WSDL file, she will not see it. Also,
user-defined WSDL files should be editable.
I think the IllegalStateException here is the correct behavior because the user corrupted the underlying model. If the
user reverts back her changes in the WSDL file, then everything should go back to normal. The ideal fix would probably
be a better error message w/o stacktrace. However, that means we need to fix all over the place.
There are a lot of things that could go wrong if you go behind CASA and change the underlying model. For example, you
change something in CASA which modifies the underlying <compapp>.wsdl. You then open and close <compapp>.wsdl file w/o
saving. At this point, CASA and <compapp>.wsdl are out of sync and you could run into all kinds of errors.
We need to think about how to prevent the user from doing this. Maybe this is a documentation issue? Downgrading to P3
> So, are we officially supporting letting users edit the generated WSDL by hand? If so, then there's a whole bunch of
testing I didn't know I needed to do . . .
> This could be easily remedied by any of the following (at least for Beta):
> -- make the WSDL not appear in the Projects pane
> -- make the WSDL read/only from the Projects pane
> -- put up a warning that the WSDL was generated by the CASA editor, and shouldn't be modified by hand.
> I noticed that the "good" WSDL changes I tried (soap:address) were picked up by the CASA editor, so it looked like we
might support editing the WSDL. Until I did something bad . . .
From the user's point-of-view, there is no indication that the file visible in the Projects pane was generated by CASA
and shouldn't be edited. The original application assembler might realize that the file is generated by CASA, but a
subsequent editor of the application would have no idea. To contrast with how we handle the other CASA-generated file:
the *.casa file itself is only visible in the Files pane.
Fixing this kind of problem in the docs never works, because noone reads the docs until AFTER they've done something bad.
Could we provide a new icon for generated files that shouldn't be user-edited, if we can't make them read-only?
I'm OK having it as a P3, because it's a negative test case. The error messaging needs improvement.
We should not try to hide or prevent user from editing source and data files in a project. NB, for example, allows
important project files like project.xml, build.xml, and project.properties be edited creating potential problems. I
made the same argument before for the CASA file too. IMHO, the problem here is with the error handling. We need a
better infrastructure within the XAM model to handle/notify model errors.
In this case, we can use the release note to explain that manual editing of the project wsdl is not supported and may
cause problems with the operation of CASA/CompApp.
I was not aware that we were supporting this use case for NB 6.0, so this use case will not be tested for NB 6.0 Beta.
Again, testing all the ways users can mess up the source files will greatly increase the testing resources required, if
we plan to permit this use case for NB 6.0 FCS.
We don't have any use case for this. I propose that we add a comment in all generated casa and wsdl files to warn the
user not to modify them manually.
<!-- This file is auto-generated by CompApp/CASA/(or whatever).
Edit its content manually may cause unrecoverable errors -->
So long as the user has a fighting chance of not messing themselves up, that all I care about. The message would be
better than nothing, and if we can make it obvious in the docs and error messages also that the user shouldn't be doing
that, that might cover it adequately for NB 6.0.
I agree with Jun that having the message in the WSDL source might not be obvious enough in the non-source views of the
WSDL editor (WSDL view or Partner view), though. Unfortunately, by the time they find out that they've confused the
internal CASA model, they're going to have to start over with their configuration to fix their mistake. We don't have
any means of recovering at this time.
Warning message added in CASA and <CompApp>.wsdl.
release note added beta 1
To clarify the problem we have with user-defined WSDL files in CompApp project, here is an example:
1. Create SynchronousSample
2. Add a user-defined WSDL into the CompApp project: (I will simply reuse the WSDL file in SynchronousSample with slight
2.1. Invoke "New -> External WSDL Documents..." from SynchronousSampleApplication project node
2.2. Select "From Local File System" and browse to "...SynchrousSample/SynchronousSample/src", click Finish
2.3. (A new SynchronousSample.wsdl file will appear under SynchronousSampleApplication/Process Files)
2.4. Open the new SynchronousSample.wsdl file under SynchronousSampleApplication/Process Files
2.5. Rename Service "service1" to "service1_inCompApp"
2.6. Rename Port "port1" to "port1_inCompApp"
2.7. Save the chagnes
3. Open CASA
4. Build CompApp
=> see attached snapshot
Now you will see a WSDL port ("port1_inCompApp") which is defined inside the CompApp project
(SynchronousSampleApplication/src/jbiasa/SynchronousSample.wsdl) but not in the auto-generated <compapp>.wsdl
(SynchronousSampleApplication/src/conf/SynchronousSampleApplication.wsdl). Note the difference between "defined inside
CompApp Project" and "defined in <compapp>.wsdl".
Currently, this WSDL port is editable (as indicated by the editable icon) because it is defined in the CompApp project.
If you modify this port (say, the port name, or SOAP address), the backing WSDL file
(SynchronousSampleApplication/src/jbiasa/SynchronousSample.wsdl) will be modified too. The same "mistake" that Jen made
on <compapp.wsdl> could also happen to this WSDL. Therefore, the same protection scheme we apply to <compapp>.wsdl
(hiding the WSDL from the Project view, making the WSDL read-only, adding do-not-edit-me warning message, etc.) need to
apply to all WSDL files in the CompApp project.
A possible "fix" to this problem is that we do not allow user-defined WSDL files in CompApp project to be editable from
within CASA (that is, to remove the editable icon from the "port1_inCompApp" port). That way, we only have to protect
one WSDL file - the auto-generated <compapp>.wsdl. If so, I think it makes perfect sense to hide it in the Project View,
as Jen suggested.
The downside of this "fix" is that the user will have to modify such WSDL files outside of CASA (just like modifying a
WSDL defined in a JBI Module Project) and do a CompApp rebuild to see the changes in CASA.
What do you guys think?
Created attachment 48871 [details]
"port1_inCompApp" is a WSDL Port defined in CompApp (but not in <compapp>.wsdl)
*** Issue 114174 has been marked as a duplicate of this issue. ***