This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Invalid editing *.wsdl in compapp -> IllegalStateException in CASA | ||
---|---|---|---|
Product: | soa | Reporter: | jlautz <jlautz> |
Component: | Composite Application | Assignee: | Jun Qian <jqian> |
Status: | NEW --- | ||
Severity: | blocker | CC: | tli |
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 114174 | ||
Bug Blocks: | |||
Attachments: |
BPEL module used in scenario.
ui gestures NB log file "port1_inCompApp" is a WSDL Port defined in CompApp (but not in <compapp>.wsdl) |
Description
jlautz
2007-08-29 22:59:21 UTC
Created attachment 47755 [details]
BPEL module used in scenario.
Created attachment 47756 [details]
ui gestures
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 for now. > 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 . . . > > Jen 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. Jen, 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 modification): 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. *** |