Folks,
I have only just finished the test cases for HTTP extensions today.
Guillaume, my apologies for the delay in addressing your
WSDLReader.readWSDL JIRA - it's been simply down to time available. The
existing readWSDL(URIstring) method was only intended as a starting point
to allow us to focus on developing the object model and parsing/validation
logic. Now that that has progressed a long way and people are actually
starting to use Woden, it's obvious that the WSDLReader interface is a high
priority item. I'll deal with this before finalizing the M5 release.
I have a concern about adding DOM dependencies directly to the WSDLReader
API via methods like readWSDL(uri, Element) or readWSDL(uri, Document).
Currently we have a DOM implementation of the parsing logic in
DOMWSDLReader, but we also have a requirement from Axis2 to use StAX
parsing in Woden (is this still an Axis2 requirement?). So I was hoping to
avoid introducing to the Woden API any dependencies on a particular XML
parser or XML object model if possible, or at least to capture any required
dependencies in some way that lets the API still reflect a choice of XML
parsing strategy. I'll give this more thought now and post any ideas, but
feel free to offer any suggestions if you have them.
regards,
John Kaputin
Lawrence Mandel
<[EMAIL PROTECTED]
om> To
[email protected]
05/06/2006 23:30 cc
Subject
Please respond to Re: Another readWSDL method
[EMAIL PROTECTED]
he.org
Guillaume,
>From John's comment and a recent discussion we had I think he still intends
on handling this in M5 (and this is likely one of the reasons M5 has been
postponed). We're a little short handed but doing out best to accomodate
requests. Please feel free to keep bugging/reminding us if your patches are
not being looked at in a timely manner.
Lawrence Mandel
Guillaume Nodet <[EMAIL PROTECTED]>
To
06/05/2006 05:53 PM [EMAIL PROTECTED]
g
cc
Please respond to
[email protected] Subject
Re: Another readWSDL
method
There is also a patch pending for more than two monthes now.
See http://issues.apache.org/jira/browse/WODEN-5
Cheers,
Guillaume Nodet
Lawrence Mandel wrote:
>
> Thanks for the patch Oshani. This type of method has come up in
> discussion before and seems like a good idea for the reasons you
> mentioned.
>
> As Jeremy said, the Apache method for accepting contributions is to
> attach them to a Jira report. Once attached to a report your patch
> will be reviewed and, if OK, committed.
>
> As you're working on WSDL 2.0 support in Axis2 you may be interested
> in joining the W3C WSDL working group's WSDL 2.0 implementers call [1]
> and, if travel allows, the interop event that will be held in Toronto
> in July [2].
>
> Lawrence Mandel
>
> [1] http://www.w3.org/2002/ws/desc/admin#phone (Developers call)
> [2] http://www.w3.org/2002/ws/desc/6/07/interop-logistic.html
>
>
>
> *"Jeremy Hughes" <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 06/05/2006 11:05 AM
> Please respond to
> [email protected]
>
>
>
> To
> [email protected], [EMAIL PROTECTED]
> cc
>
> Subject
> Re: Another readWSDL method
>
>
>
>
>
>
>
>
>
> Hi, this is great. I haven't read the patch yet though ... please
> would you open a JIRA as there is a mechanism there to say you "grant
> license to ASF for inclusion in ASF works".
>
> Many thanks,
> Jeremy
>
> On 6/5/06, Oshani Seneviratne <[EMAIL PROTECTED]> wrote:
> > Hi Devs,
> >
> > I am doing a Google Summer of Code project to provide WSDL2.0 support
> > for Axis2/Java. During the past few weeks I've been experimenting with
> > Woden and found it to be very much pluggable to Axis2 in providing
> > WSDL2.0 functionality as it has been discussed on this list before.
> >
> > However, I did come across a small bottleneck in my work so far. The
> > problem was the readWSDL method which only accepts the URI of the WSDL
> > document. Since service deployment in Axis2 is done as an AAR (Axis
> > ARchive) file, IMHO providing the URI is very inefficient. Since other
> > types of overloaded readWSDL methods are not currently provided in the
> > WSDLReader interface, the only solution which came to my mind was to
> > extract the WSDL from the archive and write it as a file to a
> > particular location on the local file system, and then give that
> > location as the argument to the readWSDL. I believe this involves a
> > lot of unnecessary overhead!
> >
> > Therefore, taking the WSDL4J API as an example, I implemented a method
> > which will take a DOM document element as an additional argument to
> > the readWSDL method and return the DescriptionElement.
> >
> > I have attached the patch, and would really appreciate if someone
> > could review it and apply it at
> > http://svn.apache.org/repos/asf/incubator/woden/java/
> > Also, if required please let me know whether I would need to open a
> > JIRA for this.
> >
> > After applying the patch you should be able to obtain a
> > DescriptionElement with the following code snippet:
> >
> > ----------
> > WSDLReader reader = WSDLFactory.newInstance().newWSDLReader();
> >
> > Document doc = org.apache.axis2.util.XMLUtils.newDocument(in); //here
> > 'in' is an InputStream
> >
> > Element element = doc.getDocumentElement();
> >
> > DescriptionElement desc = reader.readWSDL(null,element); //Note: the
> > WSDL Uri could be null
> > ----------
> >
> >
> > Thanks and Regards,
> >
> > Oshani.
> >
> >
> > ---------------------------------------------------------------------
> > 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]
