On Tue, Apr 12, 2011 at 2:55 PM, Simon Laws <[email protected]> wrote:
> On Tue, Apr 12, 2011 at 2:06 PM, ant elder <[email protected]> wrote:
>> On Tue, Apr 12, 2011 at 12:36 PM, Simon Laws <[email protected]> 
>> wrote:
>>> On Tue, Apr 12, 2011 at 12:19 PM, ant elder <[email protected]> wrote:
>>>> Presently the endpoint registry doesn't hold any information on the
>>>> interfaces of an endpoint. In the past we have talked about adding
>>>> something and I wondered about starting to look at that now.
>>>>
>>>> As an example of one thing I'd like to work: if you start the
>>>> helloworld sample in the distribution domain by doing "mvn tuscany:run
>>>> -o -DdomainURI=uri:default" in the helloworld sample and then start
>>>> another shell, eg in another command prompt do "mvn
>>>> org.apache.tuscany.maven.plugins:maven-tuscany-plugin:2.0-SNAPSHOT:shell
>>>> -o -DdomainURI=uri:default" you can see the helloworld service in both
>>>> shells (use the "services" shell command) but if you try to invoke the
>>>> service with "invoke HelloworldComponent/Helloworld sayHello lkjlk" it
>>>> fails in the 2nd shell with an NPE because it doesn't know the
>>>> interface of the service.
>>>>
>>>> One relatively easy option would be to put a wsdl for the service in
>>>> the endpoint registry and then have wsdl2java type utility API to
>>>> create Java interfaces from the wsdl as required. or we could try to
>>>> serialize the Tuscany interface model into the registry instead of a
>>>> wsdl. Before i do any of those has anyone given this any thought in
>>>> the past?
>>>>
>>>>   ...ant
>>>>
>>>
>>> Good idea.
>>>
>>> We put a normalized WSDL representation in place for all interfaces.
>>> It would seem appropriate to add this to the registry.
>>
>> Are you saying that the wsdl is already always being generated in the
>> code somewhere? I didn't realize, where is the code that does that?
>>
>
>
> IIRC whether they get generated or not depends on whether contracts of
> different styles have to be compared. Regardless this operation on
> Enpoint(Reference)Impl is how they do get generated.
>
>    public InterfaceContract
> getGeneratedWSDLContract(InterfaceContract interfaceContract) {
>
>        if ( interfaceContract.getNormalizedWSDLContract() == null){
>            if (getComponentServiceInterfaceContract() instanceof
> JavaInterfaceContract){
>                if (contractBuilder == null){
>                    throw new ServiceRuntimeException("Contract
> builder not found while calculating WSDL contract for " +
> this.toString());
>                }
>                contractBuilder.build(interfaceContract, null);
>            }
>        }
>
>        return interfaceContract.getNormalizedWSDLContract();
>    }
>
> So the generated/normalized contract is easily available. Once
> generated it's carried in the interface contract itself.
>

Ok thanks, i shall go look at that.

>>> I don't think
>>> there is a requirement to generate Java from this WSDL as it can be
>>> used directly for interface comparison.
>>>
>>
>> The main use for that right now would be the Shell which needs it for
>> the invoke command to work. If thats the only place it can just be
>> code in the shell. I did think we still had the odd place that needed
>> a Java interface and presently just casts the Interface to a
>> JavaInterface and so fails if its not a Java interface,
>
> If that is the case I didn't realize it. Be interested to know where
> that is required.
>

Doing a search for a cast to a java interface - "(JavaInterface)" -
shows quite a lot of hits probably most of which are fine but one
example of where it isn't is line 134 of
JSONRPCServiceBindingProvider.

   ...ant

Reply via email to