On Aug 22, 2006, at 1:39 PM, ant elder wrote:
I agree a registry would be good, we need some sort of cache or
registry
otherwise you need to specify the wsdlLocation on every
interface.wsdl and
binding.ws which is quite ugly. But we had a simple registry in M1
and that
caused problems with namespace reuse.
We definitely need to handle the reuse of namespaces across
applications,
and also maybe the reuse of namespaces within an application. To
handle
namespace reuse within an application you need the option to specify a
wsdlLocation everywhere interface.wsdl or binding.ws is used, to
handle
reuse across applications the registry needs to have some sort of
application scope.
I really like the suggestion that WSDL be automatically discovered
anywhere
within the application directory structure.
I pretty much have the same concerns as mentioned by Raymond on this.
So for now, to get the current code working without requiring
wsdlLocation
be used everywhere and until the spec group do something, could we
have a
simple registry that finds WSDL anywhere within applications and
its keyed
by application
If it is keyed by composite or anything that references a
classloader, we will have a memory leak. We also probably shouldn't
have the system service hold a key to anything that needs to be
dereferenced when a composite is removed. Thinking about this, we
probably want to use the property extensibility mechanism Jeremy was
putting in place which would scope things within a composite.
and the WSDL location. Then extensions could locate WSDL
objects based on the name, eg portType name, DeploymentContext and an
optional wsdlLocation?
...ant
On 8/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:
I like Raymond's and Yang's approach and perhaps someone is willing
to propose the standardized way to the spec group? Sebastien, since
you had a bunch of other issues raised against the spec group, do you
want to do that?
Jim
On Aug 22, 2006, at 10:36 AM, Raymond Feng wrote:
> I'm leaning the following:
>
> 1) Have a well-defined default scheme. I agree with Sebastien that
> the SCA spec should spell it out.
> 2) Allow extensibility to plug in new schemes (for example,
> "my:path") if the host platform desires.
>
> Thanks,
> Raymond
>
> ----- Original Message ----- From: "Jean-Sebastien Delfino"
> <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Tuesday, August 22, 2006 10:21 AM
> Subject: Re: Auto discovering WSDL
>
>
>> Raymond Feng wrote:
>>> Hi,
>>>
>>> I would suggest that we define a system service to provide the
>>> artifact resolving strategy. Then we can supply a default
>>> implementation, for example, resolve the wsdlLocation based on
>>> classpath. The embedded can choose to replace it with its own
>>> more sophisticated resolver (for exmaple, using META-INF/wsdl,
>>> scanning directory, or querying a WSDL repository).
>>>
>>> Thanks,
>>> Raymond
>>>
>>
>> Making things pluggable to support all kinds of different schemes
>> is interesting, but will that break application portability
>> between different runtimes?
>>
>> With my application developer hat on, I would expect the SCA
>> specification to tell me where I'm supposed to write my WSDL and
>> XSD files and how references from SCDL to WSDL get resolved.
>>
>> Any thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
