You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Lou Amodeo <lo...@gmail.com> on 2008/01/31 18:04:31 UTC
WSDLLess Deployment Implementation Question
Hi, I have a question about the implementation of the "wsdlless" deployment
function.
The issues I see are occurring in a couple of places within the life-cycle.
Namely, deployment, binding start, and service definition. It occurs to me
that if the generation of the wsdl occurred early in the process, rather
than during the startup of the component, Tuscany could maintain a common
code path for contributions with wsdl and contributions w/o wsdl. Today for
instance WSDL is processed in the WSBindingProcessor when its present and
the Axis2ServiceBinding when its not. I am curious why this is so? Why
wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl definition
at that point and the subsuquent flow from there on would be the same?
Alternatively, when a contribution is deployed, why not detect a wsdl is
missing, generate one, and place it in the contribution. At this point a
wsdlElement could also be added and the subsequent startup process would not
know the difference? I am not sure if other bindings will adopt a wsdlless
approach but I would think a common non-binding specific process would be
beneficial.
Thanks for your help.
Re: WSDLLess Deployment Implementation Question
Posted by Scott Kurz <sc...@gmail.com>.
On Feb 3, 2008 5:01 PM, Mike Edwards <mi...@gmail.com> wrote:
> Folks,
> It is important to remember that when an interface is specified EITHER
> as some non-WSDL interface type (eg Java interface) OR where it is
> specified as WSDL, the FINAL WSDL that is necessary for a deployed (web)
> service may need generating from the original interface definition.
In addition to the case where we start with an interface.wsdl but
still need to add policy
to the final, logical WSDL defining the <binding.ws> port... I
believe, (if I'm understanding the code
correctly), that we have a simpler case here that we don't support today.
That's the case where the <interface.wsdl> defines a portType but not
a port, so we still need
to calculate a port when we see <binding.ws>, but we'd like to start
from the <interface.wsdl> WSDL
(I would assume) rather than starting from the Java.
I think the WS binding spec in at least one place implies if you use
<interface.wsdl> you do have a port, but
I don't see why that would be.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Scott Kurz wrote:
> OK, just wanted to make sure I hadn't missed a discussion on how to do
> this with dynamic SDOs.
>
> You know, one issue I noticed when looking at this with static SDOs is
> the way that SDO makes it hard for you
> to programmatically go from static SDO to XSD. Looking at the SDO
> source I think it was the code in
> org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema() which was responsible:
>
> throw new IllegalArgumentException("Cannot generate
> XSD since SDO Type '" +
> dataType.getName() + "' was orginally
> generated from XSD. Use original XSD");
[snip]
There may be issues with that method :) but there should be enough
metadata in the SDO type to generate a compatible XSD.
We could also grab the element/type qname from the SDO type, find its
declaration in the XSD files in the scope of the contribution, and
simply use it.
I'd prefer that as it'll be easier for the app developer to get WSDL
pointing back to his original XSD.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Scott,
There was a discussion around this with the SDO folks and their view point
was that, having generated the static SDO from an XSD, why would one want to
go and generate the XSD again. Ideally the original XSD should be used.
Its been a while since I've been thro this, but I do remember that the
discussion started after I had some trouble in getting back something
equivalent to the original XSD as part of this generation. It was then
decided that we would provide these XSD locations as input arguments these
would be imported during the WSDL generation.
- Venkat
On Feb 5, 2008 8:10 PM, Scott Kurz <sc...@gmail.com> wrote:
> OK, just wanted to make sure I hadn't missed a discussion on how to do
> this with dynamic SDOs.
>
> You know, one issue I noticed when looking at this with static SDOs is
> the way that SDO makes it hard for you
> to programmatically go from static SDO to XSD. Looking at the SDO
> source I think it was the code in
> org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema() which was
> responsible:
>
> throw new IllegalArgumentException("Cannot generate
> XSD since SDO Type '" +
> dataType.getName() + "' was orginally
> generated from XSD. Use original XSD");
>
>
>
>
>
> On Feb 5, 2008 3:55 AM, Jean-Sebastien Delfino <js...@apache.org>
> wrote:
> > Scott Kurz wrote:
> > > When you wrote:
> > >
> > > - The generator should use the databinding metadata (including any
> > > knowledge of handwritten XSD representing the business data and
> > > generation capabilities like the SDO XSDGenerator) to generate proper
> > > XSD in the WSDL.
> > >
> > > How were you thinking a particular XSD would be associated with a
> > > generic DataObject on a Java intf? What
> > > metadata would we be using as input here?
> > >
> > [snip]
> >
> > I was thinking about static SDOs.
> >
> > Java method updateCustomer(DataObject anObject) would translate to
> > WSDL operation updateCustomer [ XSD xsd:any ]
> >
> > but Java method updateCustomer(Customer customer) would translate to
> > WSDL operation updateCustomer [ XSD cust:Customer ]
> >
> >
> > --
> > Jean-Sebastien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: WSDLLess Deployment Implementation Question
Posted by Scott Kurz <sc...@gmail.com>.
OK, just wanted to make sure I hadn't missed a discussion on how to do
this with dynamic SDOs.
You know, one issue I noticed when looking at this with static SDOs is
the way that SDO makes it hard for you
to programmatically go from static SDO to XSD. Looking at the SDO
source I think it was the code in
org.apache.tuscany.sdo.helper.SchemaBuilder.buildSchema() which was responsible:
throw new IllegalArgumentException("Cannot generate
XSD since SDO Type '" +
dataType.getName() + "' was orginally
generated from XSD. Use original XSD");
On Feb 5, 2008 3:55 AM, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Scott Kurz wrote:
> > When you wrote:
> >
> > - The generator should use the databinding metadata (including any
> > knowledge of handwritten XSD representing the business data and
> > generation capabilities like the SDO XSDGenerator) to generate proper
> > XSD in the WSDL.
> >
> > How were you thinking a particular XSD would be associated with a
> > generic DataObject on a Java intf? What
> > metadata would we be using as input here?
> >
> [snip]
>
> I was thinking about static SDOs.
>
> Java method updateCustomer(DataObject anObject) would translate to
> WSDL operation updateCustomer [ XSD xsd:any ]
>
> but Java method updateCustomer(Customer customer) would translate to
> WSDL operation updateCustomer [ XSD cust:Customer ]
>
>
> --
> Jean-Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Scott Kurz wrote:
> When you wrote:
>
> - The generator should use the databinding metadata (including any
> knowledge of handwritten XSD representing the business data and
> generation capabilities like the SDO XSDGenerator) to generate proper
> XSD in the WSDL.
>
> How were you thinking a particular XSD would be associated with a
> generic DataObject on a Java intf? What
> metadata would we be using as input here?
>
[snip]
I was thinking about static SDOs.
Java method updateCustomer(DataObject anObject) would translate to
WSDL operation updateCustomer [ XSD xsd:any ]
but Java method updateCustomer(Customer customer) would translate to
WSDL operation updateCustomer [ XSD cust:Customer ]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by Scott Kurz <sc...@gmail.com>.
Sebastien,
When you wrote:
- The generator should use the databinding metadata (including any
knowledge of handwritten XSD representing the business data and
generation capabilities like the SDO XSDGenerator) to generate proper
XSD in the WSDL.
How were you thinking a particular XSD would be associated with a
generic DataObject on a Java intf? What
metadata would we be using as input here?
I know if we had generated SDOs and an XSD in the archive we could
write an algorithm to make a match,
but I was thinking along the lines that, in such a case, we have less
information in the Java than the WSDL
and so therefore the user would perhaps even be required to specify
<interface.wsdl> to narrow down the specific
schema type(s).
But I'm interested to hear your thoughts.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Mike Edwards wrote:
> Folks,
>
> ant elder wrote:
>> On Jan 31, 2008 5:04 PM, Lou Amodeo <lo...@gmail.com> wrote:
>>
>>> Hi, I have a question about the implementation of the "wsdlless"
>>> deployment
>>> function.
>>> The issues I see are occurring in a couple of places within the
>>> life-cycle.
>>> Namely, deployment, binding start, and service definition. It occurs
>>> to me
>>> that if the generation of the wsdl occurred early in the process, rather
>>> than during the startup of the component, Tuscany could maintain a
>>> common
>>> code path for contributions with wsdl and contributions w/o wsdl. Today
>>> for
>>> instance WSDL is processed in the WSBindingProcessor when its present
>>> and
>>> the Axis2ServiceBinding when its not. I am curious why this is so? Why
>>> wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
>>> definition
>>> at that point and the subsuquent flow from there on would be the same?
>>> Alternatively, when a contribution is deployed, why not detect a wsdl is
>>> missing, generate one, and place it in the contribution. At this point a
>>> wsdlElement could also be added and the subsequent startup process would
>>> not
>>> know the difference? I am not sure if other bindings will adopt a
>>> wsdlless
>>> approach but I would think a common non-binding specific process
>>> would be
>>> beneficial.
>>>
>>>
>>> Thanks for your help.
>>>
>>
>> I think the issue may be at what point the information required to
>> generate
>> the wsdl becomes available. When <binding.ws> is used without the
>> wsdlElement attribute then the wsdl comes from the service or reference
>> interface and if thats not <interface.wsdl> then this is when a wsdl
>> needs
>> to be generated. I'm not sure if the service or reference interface is
>> going
>> to be available anywhere when the WebServiceBindingProcessor resolve
>> method
>> is called.
>>
>> ...ant
>>
>
> It is important to remember that when an interface is specified EITHER
> as some non-WSDL interface type (eg Java interface) OR where it is
> specified as WSDL, the FINAL WSDL that is necessary for a deployed (web)
> service may need generating from the original interface definition.
>
> The SCA metadata can include Policy information that is likely missing
> from the original interface definition (eg need for encryption of the
> messages). This extra SCA metadata needs to be processed before the
> final WSDL can be generated and may involve things like reading policy
> sets to determine the correct layout and content of the final WSDL.
>
> The final processed version of the WSDL should not be placed back into
> the contribution in case of any updates to the Domain as a whole (eg
> someone decides on a change of policy set for the domain as a whole),
> since that would require recalculation of the generated WSDL (not
> something we do now, but useful to think ahead).
>
>
> Yours, Mike.
>
Mike, +1 to everything you said. I think it's in line with what I was
trying to describe earlier in this thread [1].
I had missed the impact of policies in [1], rephrasing it here to add
the policy aspect:
- The WSDL4J model should be produced earlier in the composite
processing cycle and passed to the binding that will need it, allowing
it to add binding specific info (e.g SOAP binding, the service
endpoint declaration ...
... and additional configuration determined by the policy sets applied
to the binding).
[1] http://marc.info/?l=tuscany-dev&m=120199391108418
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
ant elder wrote:
> On Jan 31, 2008 5:04 PM, Lou Amodeo <lo...@gmail.com> wrote:
>
>> Hi, I have a question about the implementation of the "wsdlless"
>> deployment
>> function.
>> The issues I see are occurring in a couple of places within the
>> life-cycle.
>> Namely, deployment, binding start, and service definition. It occurs to me
>> that if the generation of the wsdl occurred early in the process, rather
>> than during the startup of the component, Tuscany could maintain a common
>> code path for contributions with wsdl and contributions w/o wsdl. Today
>> for
>> instance WSDL is processed in the WSBindingProcessor when its present and
>> the Axis2ServiceBinding when its not. I am curious why this is so? Why
>> wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
>> definition
>> at that point and the subsuquent flow from there on would be the same?
>> Alternatively, when a contribution is deployed, why not detect a wsdl is
>> missing, generate one, and place it in the contribution. At this point a
>> wsdlElement could also be added and the subsequent startup process would
>> not
>> know the difference? I am not sure if other bindings will adopt a wsdlless
>> approach but I would think a common non-binding specific process would be
>> beneficial.
>>
>>
>> Thanks for your help.
>>
>
> I think the issue may be at what point the information required to generate
> the wsdl becomes available. When <binding.ws> is used without the
> wsdlElement attribute then the wsdl comes from the service or reference
> interface and if thats not <interface.wsdl> then this is when a wsdl needs
> to be generated. I'm not sure if the service or reference interface is going
> to be available anywhere when the WebServiceBindingProcessor resolve method
> is called.
>
> ...ant
>
It is important to remember that when an interface is specified EITHER
as some non-WSDL interface type (eg Java interface) OR where it is
specified as WSDL, the FINAL WSDL that is necessary for a deployed (web)
service may need generating from the original interface definition.
The SCA metadata can include Policy information that is likely missing
from the original interface definition (eg need for encryption of the
messages). This extra SCA metadata needs to be processed before the
final WSDL can be generated and may involve things like reading policy
sets to determine the correct layout and content of the final WSDL.
The final processed version of the WSDL should not be placed back into
the contribution in case of any updates to the Domain as a whole (eg
someone decides on a change of policy set for the domain as a whole),
since that would require recalculation of the generated WSDL (not
something we do now, but useful to think ahead).
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by ant elder <an...@gmail.com>.
On Jan 31, 2008 5:04 PM, Lou Amodeo <lo...@gmail.com> wrote:
> Hi, I have a question about the implementation of the "wsdlless"
> deployment
> function.
> The issues I see are occurring in a couple of places within the
> life-cycle.
> Namely, deployment, binding start, and service definition. It occurs to me
> that if the generation of the wsdl occurred early in the process, rather
> than during the startup of the component, Tuscany could maintain a common
> code path for contributions with wsdl and contributions w/o wsdl. Today
> for
> instance WSDL is processed in the WSBindingProcessor when its present and
> the Axis2ServiceBinding when its not. I am curious why this is so? Why
> wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
> definition
> at that point and the subsuquent flow from there on would be the same?
> Alternatively, when a contribution is deployed, why not detect a wsdl is
> missing, generate one, and place it in the contribution. At this point a
> wsdlElement could also be added and the subsequent startup process would
> not
> know the difference? I am not sure if other bindings will adopt a wsdlless
> approach but I would think a common non-binding specific process would be
> beneficial.
>
>
> Thanks for your help.
>
I think the issue may be at what point the information required to generate
the wsdl becomes available. When <binding.ws> is used without the
wsdlElement attribute then the wsdl comes from the service or reference
interface and if thats not <interface.wsdl> then this is when a wsdl needs
to be generated. I'm not sure if the service or reference interface is going
to be available anywhere when the WebServiceBindingProcessor resolve method
is called.
...ant
Re: WSDLLess Deployment Implementation Question
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Jan 31, 2008 5:04 PM, Lou Amodeo <lo...@gmail.com> wrote:
>
>> Hi, I have a question about the implementation of the "wsdlless"
>> deployment
>> function.
>> The issues I see are occurring in a couple of places within the
>> life-cycle.
>> Namely, deployment, binding start, and service definition. It occurs to me
>> that if the generation of the wsdl occurred early in the process, rather
>> than during the startup of the component, Tuscany could maintain a common
>> code path for contributions with wsdl and contributions w/o wsdl. Today
>> for
>> instance WSDL is processed in the WSBindingProcessor when its present and
>> the Axis2ServiceBinding when its not. I am curious why this is so? Why
>> wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
>> definition
>> at that point and the subsuquent flow from there on would be the same?
>> Alternatively, when a contribution is deployed, why not detect a wsdl is
>> missing, generate one, and place it in the contribution. At this point a
>> wsdlElement could also be added and the subsequent startup process would
>> not
>> know the difference? I am not sure if other bindings will adopt a wsdlless
>> approach but I would think a common non-binding specific process would be
>> beneficial.
>>
>>
>> Thanks for your help.
>>
> Hi Lou,
>
> Anything we can do to simplify our code path is a good thing IMO.
>
> More specifically I'm attracted by your idea of having the wsdl processing
> happen in one place and I think this could work well for the model generated
> in memory when a composite is processed. The WSDL interface contract could
> be built in the earlier phases of composite processing and the code at the
> top of Axis2ServiceBindingProvider
>
> InterfaceContract contract = wsBinding.getBindingInterfaceContract
> ();
> if (contract == null) {
> contract = service.getInterfaceContract
> ().makeUnidirectional(false);
> if ((contract instanceof JavaInterfaceContract)) {
> contract =
> Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
> requiresSOAP12(wsBinding));
> }
> wsBinding.setBindingInterfaceContract(contract);
> }
>
> Could be reworked or removed..
>
> Could you say a little more about the alternative you propose,
> "Alternatively, when a contribution is deployed, why not detect a wsdl is
> missing, generate one, and place it in the contribution. ". What you you
> mean by "deployed" here. I'm asking in relation to two other threads that
> are ongoing.
>
> In the discussion [1] about reference targets I've been floating the idea of
> having a contribution processing phase in the domain that fixes up
> contributions before they are deployed to nodes. I had been thinking about
> URIs but this WSDL point could be another one of the things that could be
> done ahead of time. In that way the Node would always be presented with a
> WSDL file in the deployed contribution.
>
> In the discussion [2] about the runtime Java2WSDL processing you suggest
> that you want to write the generated WSDL out as a file as an alternative to
> providing access to it via ?wsdl. Moving this processing forward would make
> this related fix easier. My question here is where should the WSDL file be
> written to? I'll ask that back over on the other thread.
>
> Regards
>
> Simon
>
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27294.html
> [2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27532.html
>
I agree with Lou and Simon on the overall approach.
I've expressed concerns with the current WSDL-less support design before
[3] and I think it's broken as it's not considering the SCA interface
and data binding metadata to generate the WSDL+XSD.
Here's what I think should happen:
- A clean interface-model-to-WSDL4J generator should be developed in the
interface-wsdl module.
- The generator should use the databinding metadata (including any
knowledge of handwritten XSD representing the business data and
generation capabilities like the SDO XSDGenerator) to generate proper
XSD in the WSDL.
- The WSDL4J model should be produced earlier in the composite
processing cycle and passed to the binding that will need it, allowing
it to add binding specific info (e.g SOAP binding and the service
endpoint declaration).
- The complete WSDL should be used to configure the underlying WS stack
(Axis2 or other), leading to a single and simpler binding code path.
I don't think it's wise to store the WSDL in the SCA contribution at
deployment time as it can be calculated and storing it is the best way
to get it out of sync with the other artifacts and cause confusion.
[3] https://issues.apache.org/jira/browse/TUSCANY-1556
Here are a few other related JIRAs. I think it's about time to redesign
that WSDL-less support and make it right.
https://issues.apache.org/jira/browse/TUSCANY-1713
https://issues.apache.org/jira/browse/TUSCANY-1648
https://issues.apache.org/jira/browse/TUSCANY-1544
https://issues.apache.org/jira/browse/TUSCANY-1557
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: WSDLLess Deployment Implementation Question
Posted by Simon Laws <si...@googlemail.com>.
On Jan 31, 2008 5:04 PM, Lou Amodeo <lo...@gmail.com> wrote:
> Hi, I have a question about the implementation of the "wsdlless"
> deployment
> function.
> The issues I see are occurring in a couple of places within the
> life-cycle.
> Namely, deployment, binding start, and service definition. It occurs to me
> that if the generation of the wsdl occurred early in the process, rather
> than during the startup of the component, Tuscany could maintain a common
> code path for contributions with wsdl and contributions w/o wsdl. Today
> for
> instance WSDL is processed in the WSBindingProcessor when its present and
> the Axis2ServiceBinding when its not. I am curious why this is so? Why
> wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
> definition
> at that point and the subsuquent flow from there on would be the same?
> Alternatively, when a contribution is deployed, why not detect a wsdl is
> missing, generate one, and place it in the contribution. At this point a
> wsdlElement could also be added and the subsequent startup process would
> not
> know the difference? I am not sure if other bindings will adopt a wsdlless
> approach but I would think a common non-binding specific process would be
> beneficial.
>
>
> Thanks for your help.
>
Hi Lou,
Anything we can do to simplify our code path is a good thing IMO.
More specifically I'm attracted by your idea of having the wsdl processing
happen in one place and I think this could work well for the model generated
in memory when a composite is processed. The WSDL interface contract could
be built in the earlier phases of composite processing and the code at the
top of Axis2ServiceBindingProvider
InterfaceContract contract = wsBinding.getBindingInterfaceContract
();
if (contract == null) {
contract = service.getInterfaceContract
().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
}
wsBinding.setBindingInterfaceContract(contract);
}
Could be reworked or removed..
Could you say a little more about the alternative you propose,
"Alternatively, when a contribution is deployed, why not detect a wsdl is
missing, generate one, and place it in the contribution. ". What you you
mean by "deployed" here. I'm asking in relation to two other threads that
are ongoing.
In the discussion [1] about reference targets I've been floating the idea of
having a contribution processing phase in the domain that fixes up
contributions before they are deployed to nodes. I had been thinking about
URIs but this WSDL point could be another one of the things that could be
done ahead of time. In that way the Node would always be presented with a
WSDL file in the deployed contribution.
In the discussion [2] about the runtime Java2WSDL processing you suggest
that you want to write the generated WSDL out as a file as an alternative to
providing access to it via ?wsdl. Moving this processing forward would make
this related fix easier. My question here is where should the WSDL file be
written to? I'll ask that back over on the other thread.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27294.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27532.html