On Aug 22, 2006, at 4:53 PM, Jean-Sebastien Delfino wrote:
ant elder wrote:
On 8/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:
<snip/>
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.
I'm confused by this thread, you're concerns are the same as
Raymonds,
Raymond says Sebastien points out the problems, but AFAICT
Sebastien likes
the auto discovery approach and I think this is how the C++ guys
are going
to implemented it. What alternative approaches do you like - must use
wsdlLocation on every interface.wsdl and binding.ws? Only auto
discover in a
specific folder such as META-INF/wsdl? Re-instate import.wsdl?
Something
else ? I'd just like to get something going, especially while Yang is
sounding so keen to help out.
...ant
Just to confirm what Ant is saying, I think that the application
developer should be free to place WSDLs and XSDs wherever it makes
sense for him under the structure where he installs his other
development artifacts. With my application developer hat on, I
don't like to have to write an extra config file or extra XML
elements in SCDL to list the WSDLs and or XSDs that I just put
there, my view is that in 2006 a modern runtime should be able to
find my WSDL files for me without any hand holding. Whether this is
the adopted scheme or not I think the SCA specification should
define the packaging structure and how references to WSDL from SCDL
get resolved (just using qnames or locations as well? per
composite? per packaging / installable unit? or per system...).
Yea I think this is important for the spec to do. I'd prefer to have
a default location where WSDLs are placed to avoid picking random
ones up from the classpath.
--
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]
