Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 90323 - property alias
property alias
Product: soa
Classification: Unclassified
Component: BPEL Validation
PC Windows XP
: P2 (vote)
Assigned To: Nikita Krjukov
Depends on:
  Show dependency treegraph
Reported: 2006-11-30 03:22 UTC by kiran_bhumana
Modified: 2007-06-01 21:01 UTC (History)
1 user (show)

See Also:

validation explanantion (10.96 KB, application/octet-stream)
2007-02-08 20:52 UTC, kiran_bhumana

Note You need to log in before you can comment on or make changes to this bug.
Description kiran_bhumana 2006-11-30 03:22:01 UTC
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

    <xsd:element type="tns:Invoke1parentType"
    <xsd:complexType name="Invoke1parentType">
            <xsd:element type="xsd:string"
    <xsd:complexType name="correlationType">
            <xsd:element type="xsd:string"
part as element,
    <message name="Invoke1parentMessage1">
        <part name="Invoke1parentPart"
    <bpws:property name="property1"
    <bpws:propertyAlias propertyName="tns:property1"
    <bpws:propertyAlias propertyName="tns:property1"
and part as type,
    <message name="correlationMessage">
        <part name="correlationPart"
    <bpws:property type="xsd:string"

    <bpws:propertyAlias part="correlationPart"
Comment 1 kiran_bhumana 2006-11-30 03:24:42 UTC
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.
Comment 2 Denis Anisimov 2007-01-30 14:21:26 UTC
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.
Comment 3 kiran_bhumana 2007-01-30 19:32:41 UTC
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.
Comment 4 Denis Anisimov 2007-02-05 10:38:51 UTC
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.
Comment 5 kiran_bhumana 2007-02-05 19:13:40 UTC
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

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.
Comment 6 Denis Anisimov 2007-02-06 10:22:55 UTC
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.
Comment 7 kiran_bhumana 2007-02-08 20:52:12 UTC
Created attachment 38262 [details]
validation explanantion
Comment 8 kiran_bhumana 2007-02-08 20:53:09 UTC
Added a document explaining, pls let me know if you have more questions
Comment 9 Denis Anisimov 2007-02-09 11:57:01 UTC
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"

Do you thing that examples below are incorrect FROM POINT OF VIEW this issue :
    <bpws:propertyAlias propertyName="tns:property1"

    <bpws:propertyAlias propertyName="tns:property1"

They are obviously incorrect.
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 ):,

Now this is only thing that I want to know.
Comment 10 Alexei Mokeev 2007-02-16 15:16:37 UTC
Changed version to 5.5.1
Comment 11 Sergey Lunegov 2007-02-19 06:55:42 UTC
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.
Comment 12 Alexei Mokeev 2007-02-21 08:46:47 UTC
No objections in 48 hours. Waived.
Comment 13 kiran_bhumana 2007-02-28 03:32:45 UTC
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
Comment 14 Alexei Mokeev 2007-03-05 17:22:47 UTC
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
Comment 15 Nikita Krjukov 2007-06-01 21:01:26 UTC
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.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo