Bug 80978

*** Issue 81025 has been marked as a duplicate of this issue. ***

Praveen can you investigate this as original author of this sample.

Here is my observation.

1) I think sample has not changed. Therefore, first mystery is why the new
validators are complaining when prior validation system did not complain.

There are 3 errors in the project reported by new  validation system.

New validation system finds 2 errors in AsynchronousSampleClient.wsdl
C:/Documents and
Settings/Mike/AsynchronousSampleMike/AsynchronousSampleMike/src/AsynchronousSampleClient.wsdl:71,4
Missing a valid portType in binding "CallbackSoapBinding".
"tns:MyCallbackPortType" is not a valid portType.Specify a valid portType in
this binding.

C:/Documents and
Settings/Mike/AsynchronousSampleMike/AsynchronousSampleMike/src/AsynchronousSampleClient.wsdl:105,4
propertyAlias messageType "partnerNS:responseMessage" is not available in this
wsdl document.Make sure there is a message defined with name
"partnerNS:responseMessage" in this wsdl document.

And new validation system also finds one additional error in the BPEL process. 

C:/Documents and
Settings/Mike/AsynchronousSampleMike/AsynchronousSampleMike/src/AsynchronousSampleClient.bpel:82,12
Not found propertyAlias for property
"{http://www.mycomp.org/AsynchronousSample}correlatorProp" usage for the
associated variables type are in any WSDL definitions directly imported by the
WS-BPEL process.

-------------------------------------------------------------------------------

Now, when I look at the AsynchronousSampleClient.wsdl and the
AsynchronousSample.wsdl the first thing I notice is that both files are defining
the same TargetNameSpace.

<wsdl:definitions name="AsynchronousSample"
             targetNamespace="http://www.mycomp.org/AsynchronousSample"

<wsdl:definitions name="AsynchronousSampleClient"
    targetNamespace="http://www.mycomp.org/AsynchronousSample"


And in the case of the AsynchronousSampleClient.wsdl it ALSO tries to refer to
some entities defined in AsynchronousSample.wsdl. And for this it defines yet
another alias for the same namespace.
    xmlns:tns="http://www.mycomp.org/AsynchronousSample"
    xmlns:partnerNS="http://www.mycomp.org/AsynchronousSample" 

It seems the system breaks down when the the definitions inside of
AsynchronousSampleClient.wsdl make reference to things defined in
AsynchronousSample.wsdl.  See Binding and PropertyAlias erorrs.

So the questions are:
1) Should this work as written? If so the validators have a problem and bug
should be filed against validators or models.

3) Can we avoid the problem (bug?) by using two distinct target name spaces for
each of the two wsdl files instead of trying to reuse the same name space? This
might be a possible workaround (assuming there is a bug preventing current
version from succeeding).

Additional finding while attempting workaround modifications to wsdl. These
observations may be irrelevent if there is bug in resolvers.

Even after locally modifying the AsynchronousSampleClient.wsdl to use a
different TargetNameSpace, I still encounter resolution problems.
I tried to modify the AsynchronousSampleClient.wsdl thus:

<wsdl:definitions name="AsynchronousSampleClient"
    targetNamespace="http://www.mycomp.org/AsynchronousSampleClient"

But even after adjusting local prefix usage, it seems current validation system
is still having problems resolving the operation name for a PortType declared in
imported file. 

This port type is defined in AsynchronousSample.wsdl

	<wsdl:portType name="MyCallbackPortType">
		<wsdl:operation name="onResult">
			<wsdl:input message="tns:responseMessage"/>
		</wsdl:operation>
	</wsdl:portType>


But you chose to  declare binding for this PortType in AsynchronousSampleClient.wsdl

    <binding name="CallbackSoapBinding" type="partnerNS:MyCallbackPortType">
        <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="onResult">
            <soap:operation/>
            <input>
                <soap:body use="literal"/>
            </input>
        </operation>           
    </binding>    

But this is still failing because the operation is not resolvable:

C:/Documents and
Settings/Mike/AsynchronousSampleMike/AsynchronousSampleMike/src/AsynchronousSampleClient.wsdl:73,8
Binding operation "onResult" in binding "CallbackSoapBinding" should match one
of operation name in portType "MyCallbackPortType". Specify binding operation
name which matches one of operation names in portType "MyCallbackPortType".

Question for Praveen. Why did you choose to define MyCallbackPortType in
AsynchronousSample.wsdl

Was this critical tactic or was this just arbitrary decision? It seems current
validation system is having problems resolving the operation name for a PortType
declared in imported file. 

Evaluation so far:


1) The two errors reported for WSDL are from the WSDL validator. The same errors
are reported when validation is invoked from the WSDL editor. 
   I also see warnings like below:  
C:/temp2/to_delete/asynchronous1b/AsynchronousSample/AsynchronousSample/src/AsynchronousSample.wsdl:3,0
   Model source provides no javax.xml.transform.Source in lookup, relative
resource resolving if needed will not be available.


   So maybe wsdl validator is not considering <imports> of other WSDL's.

   Ritesh/Kini should investigate this. 

--------------------------------------------
2) The one bpel related validation error seems to be in the bpel validators. I
will check this further.
   
-------------------------------------------------   
3) MyCallbackPortType is in AsynchronousSample.wsdl because this WSDL defines
all the operations and portTypes and is the primary service. Since this service
is asynchronous it also specifies the callback portType that has to be
implemented by callers of this service.
 The client has to implement the callback so he only needs to supply a <binding>
and <service> for the portType.

----------------------------------------

 Venkat please reassign this bug to someone on your team for the wsdl validator
related bug indicated in (1) above.

 Upon testing here I suspect that the bpel validator error (2) is also related
to the fact that imported wsdl's are not available. After fixing the wsdl
validator bug, if the bpel validator error still shows up, please reassign to me.

i have fixed the binding operation validation error.
I am still investigating the Source related validation error.

My observations are as follows:

1. Opening the wsdl file first and hitting validate doesnt get the Source
related error.
2. Either validating the BPEL first or using build project in the bpel project
causes the source missing error.
3. The bpel validator tries to get the wsdlmodel  using
org.netbeans.modules.bpel.model.impl.Utils.getWsdlModel

I am guessing from Chris's mail I recieved regarding the Source problem:
"The source object can be used as input for JAXP type validation. If the source
is not provided, then the validator cannot be a base URI / file for resolving
relative links. If you are within the IDE, a source should be created if you are
creating the model source with the Utilities class from the retriever module."

the wsdlmodel retrieved from the Utils.getWsdlModel doesnt seem to have the source.

The current defect has been fixed other than for the Source warning. I hope this
is no more a P1 bug.
It seems to be bug from the bpel project. Will reassign..

Fixed:

Model source provides no javax.xml.transform.Source in lookup, relative
resource resolving if needed will not be available

Project now compiles without any warning/errors.

 I am still seeing the original three error messages on project compile. I see
comments from kini that the binding operation validation error is fixed, but
that is also still seen.

Following are 3 errors reported:

C:\Documents and Settings\radval\AsynchronousSample2\AsynchronousSample2
\src\AsynchronousSampleClient.bpel:82: column:12 ERROR: Not found propertyAlias 
for property "{http://www.mycomp.org/AsynchronousSample}correlatorProp" usage 
for the associated variables type are in any WSDL definitions directly imported 
by the WS-BPEL process.
C:\Documents and Settings\radval\AsynchronousSample2\AsynchronousSample2
\src\AsynchronousSampleClient.wsdl:71: column:4 ERROR: Missing a valid portType 
in binding "CallbackSoapBinding". "tns:MyCallbackPortType" is not a valid 
portType.Specify a valid portType in this binding.
C:\Documents and Settings\radval\AsynchronousSample2\AsynchronousSample2
\src\AsynchronousSampleClient.wsdl:105: column:4 ERROR: propertyAlias 
messageType "partnerNS:responseMessage" is not available in this wsdl 
document.Make sure there is a message defined with 
name "partnerNS:responseMessage" in this wsdl document.


For 1 and 3 I have already filed a bug 
http://enterprise.netbeans.org/issues/show_bug.cgi?id=81289
. It is in bpel validation.
For 2 I am investigating.

For issue 2 there is a bug filed for wsdlmodel 81298.

So to summarize  there are 3 issues:
(1)bpel validation issue, filed bug 81289
(2)wsdl model does not handle wsdls with same targetNamespac, filed issue 81298
(3) After (2) issue is worked around we hit problem in wsdl validation on 
validating binding operation which kini already fixed in release55 branch in 
wsdlapi validator.

We need to make sure we get fixes for (2) and (3) propogated to coke netbeans.

If we can not do that then a workaround for this sample is to comment 
validation task in the bpel project. I tested it by commenting validation and
deploy/test works fine.

Issue (1) was closed as invalid.

For issue (2), used workaround by using different namespaces for both the wsdl's.
Also moved around <binding> and <service>, so that they are in the same file
which defines the <portType>

Did not run into issue (3) for this sample, although it may exist seperately.

Marking this as fixed as sample now runs successfully.

Build: continuous build 060728_24 + app server installed in nighly build 060728

Validated AsynchronousSample.bpel file got 2 warnings, but no error.
Compiled AsynchronousSampleApplication successfully.