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.
Validate the queries that are defined on the property alias. When the part is defined of an element, there are two variations of the query. There is only one variant possible. Please look at the following. Also related bug http://www.netbeans.org/issues/show_bug.cgi?id=83335. <xsd:element type="tns:Invoke1parentType" name="Invoke1parentElement"></xsd:element> <xsd:complexType name="Invoke1parentType"> <xsd:sequence> <xsd:element type="xsd:string" name="string"></xsd:element> </xsd:sequence> </xsd:complexType> <xsd:complexType name="correlationType"> <xsd:sequence> <xsd:element type="xsd:string" name="string"></xsd:element> </xsd:sequence> </xsd:complexType> part as element, <message name="Invoke1parentMessage1"> <part name="Invoke1parentPart" element="tns:Invoke1parentElement"></part> </message> <bpws:property name="property1" type="xsd:string"/> .... <bpws:propertyAlias propertyName="tns:property1" messageType="tns:Invoke1parentMessage1" part="Invoke1parentPart"> <bpws:query>/Invoke1parentElement/string</bpws:query> </bpws:propertyAlias> (or) <bpws:propertyAlias propertyName="tns:property1" messageType="tns:Invoke1parentMessage1" part="Invoke1parentPart"> <bpws:query>string</bpws:query> </bpws:propertyAlias> and part as type, <message name="correlationMessage"> <part name="correlationPart" type="tns:correlationType"></part> </message> <bpws:property type="xsd:string" name="propertyName1"></bpws:property> .... <bpws:propertyAlias part="correlationPart" propertyName="tns:propertyName1" messageType="tns:correlationMessage"> <bpws:query>string</bpws:query> </bpws:propertyAlias>
Just a note, We shouldn't assume that all the queries that will be created would be from the UI provided and avoid having this kind of validation.
Are you sure that this is very important issue with P2 priority ? We have number of not implemented validation rules and this is just only one in this list. I don't see big importance of this issue. I believe we have other high priority issues that should be done at first place. We even don't have all static analysis rules implemented.
I would say this is important, since anyone who uses correlations will do use the query. And inadvertently runs into this issue. It requires a good amount of studying and understanding the correlations, BPEL spec and XML representation of the data in terms of understand what went wrong with this query. My experience has shown that relatively knowledgable developers ran into this pitfall of making the mistake. I can say that this is more important and useful than some of the static analysis, lets say the validation doesn't point out that the operation selected and the variable type didn't match up in receive. It will waste time, but the developer will find it relatively easy to debug and fix it. Where as this query of property alias is not that easy. He may have to debug the java code in which the engine is written. This deserves the priority it is assigned.
Kiran, could you please provide to me additional details on this. I cannot understand the essence of this issue from your original description . I just understand that there can be BPEL file ( that could be created not in our IDE ) with incorrect property alias. So we need to determine such incorrect property alias declarations. I don't understand exactly wrong situation in this issue. Could you please point to me incorrect example ( previously mentioned by you ) and pointer to incorrect place in this example. And as opposite: correct example and difference between incorrect example. This will help to me to write correct validation rule. Thank you.
This is all WSDL. No BPEL file is involved here. Property aliases are in WSDL file. What i am asking is to validate the query that is written for a property alias. 1) WSDL message part can be defined as Element, in that case the query can be written in one of the two styles. The two different ways the query can be written in shown earlier in the description. 2) WSDL message part can be defined as type. In this case there is only one way a query can be written. This is also described earlier in the bug description. We need to make sure the wsdls(property aliases) that are written will be conformant to these styles of query based on part's definition. We should point out if the query for type is written in a style that would match the element's query style and vice versa. We should point out if the query's first node doesn't match the correct node name. Correct node name would be inferred from the schema definition of the part. If you still have issue please call me. 626-471-6025
Kiran, we are in different timezones. So I cannot call to you in time that is appropriate for you and me. It seems I'm absolutely stupid idiot, but I didn't find in your last description requested information : >Could you please point to me incorrect example ( previously mentioned by you ) >and pointer to incorrect place in this example. >And as opposite: correct example and difference between incorrect example. Could you please write it one more time with some markers where is correct and where is incorrect examples ? Please note that I'm not expert neither in BPEL nor in WSDL ( possibly you are ). But I'm responsible person for validation ( I don't know why , but it is true ). So I need to understand exactly algorithm that I should write for handle this situation. From your description I cannot understand exactly what you suggest: 1) Handle ONLY situation when "type" or "element" attribute is used in message definition and check that there is no leading "/Invoke1parentElement/". 2) Handle situation for checking query attribute with its correctness. I mean here checking existence and conformance Xpath expression in query to XSD defined element or type. This is two different cases. The second case is like other existed issue in BPEL category about checking any Xpath expressions to conformance to XSD. And they should be done together. This is high usability impact BUT it is not VERY important thing and we can postpone it to next release.
Created attachment 38262 [details] validation explanantion
Added a document explaining, pls let me know if you have more questions
Thank you. This is a good explanation. But still I don't understand your concern here exactly. Please look at this example: <bpws:propertyAlias propertyName="tns:property1" messageType="tns:Invoke1parentMessage1" part="Invoke1parentPart"> <bpws:query>/Invoke1parentElement/string</bpws:query> </bpws:propertyAlias> Do you thing that examples below are incorrect FROM POINT OF VIEW this issue : <bpws:propertyAlias propertyName="tns:property1" messageType="tns:Invoke1parentMessage1" part="Invoke1parentPart"> <bpws:query>/SomethingWrong/string</bpws:query> </bpws:propertyAlias> <bpws:propertyAlias propertyName="tns:property1" messageType="tns:Invoke1parentMessage1" part="Invoke1parentPart"> <bpws:query>/Invoke1parentElement/somethingWrong/bpws:query> </bpws:propertyAlias> They are obviously incorrect. BUT I WANT TO UNDERSTAND EITHER WE NEED TO FIX IN THIS ISSUE correctness of Xpath expression as a whole or we need concern about leading "/" only ? Because there are already issues about XPath correctness ( this is other case but the same essence ): http://www.netbeans.org/issues/show_bug.cgi?id=84077, http://www.netbeans.org/issues/show_bug.cgi?id=85437 Now this is only thing that I want to know.
Changed version to 5.5.1
The fix for this issue should be part of general changes in validation. Probably it will not be fixed in Gavotte. Should discuss it with Kiran.
No objections in 48 hours. Waived.
sorry for the long time it took to get back. There are so many things at hand and it slips through my mind every day. Even though i wanted to update this bug ever since we missed the phone conversation, i finally remembered to do it today. To answer your question, the issue i am pointing here is not the correction of the xpath as a whole. I understand that is a bigger undertaking and is filed as a different bug too. while correctness of '/' is part of the thing, the other part is the first step in the xpath. Meaning, what i am asking here is the correctness of '/<firstStepNode>' combination. I hope that it is not too late and the bug will be considered for kenai and not waived.
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
New validation is added. It applies the described rule and also check the query XPath by steps. It also checks is there a difference between the type of query and the type of correlation propery.