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.
see bug 81190. I think we should try to implement solution for this (RFE ... or bug). I am opening a Feature because I think this is more than a bug. It requires desisgn consideration and was not originally part of our design. Use case: BPEL process imports XSD and WSDL files. These are upstream artifacts. User modifies one or more of these upstream artifacts. User modifications to upstream artifacts affect the validity of BPEL artifact - this effect may be either positive or negative. We do not know until BPEL is revalidated. Scenario: Tody user must trigger validation in BPEL by either modifying BPEL (and triggering auatomatic validation) or explicitly invoking the Validate XML action on BPEL process or build/deploy of BPEL project. User complaint is that today, there is no information or automatiion to help them know that that validattion of BPEL must be initiated because of changes to upstream artifacts. So minimum requirement is that we provide some cue to user to let them know that validation should occur or alternatively, we revalidate BPEL upon detection of changes to upstream artifact. Degree of revalidation is subject to debate - revalidation of implicit validation system, or revalidaiton of explicit (slower) validation system? Issues and Concerns ---------------------------------------------------------------------- Our concern in the Coke timeframe was performance. We were hesitant to fix this because we were worried that it might become too eager. We were worried that reacting to every change in external files would be too noisy. I suggest we try doing something with a "external models dirty" flag. We can listen for changes in external models (either model or file level whichever is best) and set this flag for BPEL process. Then when BPEL process is given focus again, we can run the validation. (Or at very least we can indicate to users that they should run explicit validation because of changes to upstream models ). Ideally, we run our implicit validation automatically. However, I do not think we can run the explicit validation automatically as it is quite slow. We can either 1) Prompt user "WSDL or XSD Files used by this process have been modified. Run validation now? [YES] [NO] or 2) We can provide some new enhancement to the UI to visually cue the user that there is a dependency that needs to be re-validated. Perhaps badging the "Validate XML" icon is a good idea? or other ideas?
After discussion with Denis we decided on following - most changes to upstream artifacts that will affect BPEL will be picked up by the automatic BPEL validation (aka fast validation). So it is not really necessary to design a solution that will promote the the slow validation. (if we discover that we do need to promote the slow validation, then I suggest going with my idea of badging the Validate XML button, but at this point we think it is a low priority). - So, assuming we need to promote fast validation, then the issue is whether to perform the fast validation eagerly (i.e. in response to changes in upstream artifacts) or lazily (i.e. set dirty flag in response to changes in upstream artifacts, and then perform the fast validation only the next time the BPEL editor gets focus ). From a performance perspective the lazy approach is the safest. The only concern is that it will introduce a slight performance lag in the BPEL editor when the BPEL editor receives focus. However, this wll be no worse than the lag which occurs whenever the fast validation runs today. So I think it will be acceptable. - Current plan is to introduce the laze validation as it is easy and low performance risk. If QE determines that this is not responsive enought then we can evaluate more sophisticated solution based on eager validation and "interruptibility".
Note to docs and qe - the current plan "lazy automatic (fast) validation" will have no UI impact. Therefore, it should not require any special documentation. It is really just another instance of the same automatic validation that is already in the product. In this case, it is just happening when editor window gets focus. Previously, it was only happening when user made change to BPEL process.
BTW Denis - we might want to run the automatic validation on first opening of the BPEL editor, since changes to upstream artifacts may have occurred before editor was opened (and perhaps before listeners were registered). What do you think?
Validation will be triggered now if external artifact was changed before we switch to Design or editor mode for bpel file. Please note that this will not happen if we switch to Navigator panel. May be this is additional feature that should be implemented also. But this is another issue.
Verified the issue is fixed in Gavotte daily build 070125_12