Hi Folks,
The code has improved beyond comparison in 1.5 compared with 1.4 We now support far more xsd types than we did. We have an extremely large test-suite which is just continuing to grow. I think we can be more than happy that the code in 1.5 is way better than previously. We also have much more stability and better error handling than previously. More to the point - we also understand what we don't support better (which we didn't really didn't have a clear idea about before) and *why* we don't support them.
It is unfortunate that these WSDL's are not supported. It is also unfortunate that the server is not being kept upgraded as fast as the client but it too is improving too from 1.4 (as far as I can tell). The server will be worked on more in 1.6 and we can prioritise these WSDL's post 1.5 too - they can be used as new tests.
Overall 1.5. is almost ready to ship and we should find a lot less issues with it compared with previous versions. I believe that we have already noticed a slow-down in mailng list issues when people take the current code-base and the errors they are seeing are much more complex than the simplisitic ones we used to see i.e. an indication that we are getting rid of the "dumb stuff".
To discuss Google in particular - it's a big problem. Our estimation appears to be at least a month - I see no reason to stop 1.5 based on one WSDL. We can prioritise it for 1.6 and people who are soooo keen to get this function can take an early drop of 1.6 from the nightly builds. each build is verified by the regression suite and so we can tell them which one is a good build.
regards,
John.
| "Samisa Abeysinghe"
<[EMAIL PROTECTED]>
23/03/2005 05:34
|
|
Dims,
Some of the problems mentioned in some of the mails are already
solved, like generating the code. However, now only we know what the
exact problem is.
There were some instances where issues were raised against
complex WSDLs like uddi wsdl. We worked on them and managed to get it
working against public services.
It is only now we get this complaining about public API's which
is very valid, but needs time to attend to. However, I see this as only
one of many requirements pending attention. In the mean time, there have
been considerable improvements from 1.4 to 1.5 (the cvs code as of
to-date) that I believe would be worth packaging without asking the
users to get from CVS or from a nightly build. In other words, we have
reached several milestones as of today in CVS code. Considering the
release qualities of 1.0 through to 1.4 those are worth releasing as a
1.5.
Thanks,
Samisa...
-----Original Message-----
From: Davanum Srinivas [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 23, 2005 10:43 AM
To: Apache AXIS C Developers List; Samisa Abeysinghe
Subject: Re: 1.5 Release
Samisa,
What's the point in churning out a release with known bad code that
does not even work with well known public API's?. May be if we did a
full interop testing (ALL soap builder's Interop tests against
whitemesa server and others and NOT our server) we would have found
stuff earlier. Forget that, just look at the # of times people have
reported this problem with Google Search:
- 2004-05-08 :
http://marc.theaimsgroup.com/?l=axis-c-user&m=108402411031604&w=2
- 2004-05-24 :
http://marc.theaimsgroup.com/?l=axis-c-dev&m=108541463028145&w=2
- 2004-11-06 :
http://marc.theaimsgroup.com/?l=axis-c-user&m=109974124030322&w=2
- 2005-02-26 :
http://marc.theaimsgroup.com/?l=axis-c-user&m=110939108423825&w=2
I know we should "Release Early and Release Often", but this is
crossing the line :(
-- dims
On Wed, 23 Mar 2005 03:32:05 +0000, Samisa Abeysinghe
<[EMAIL PROTECTED]> wrote:
> Dims,
> I had a look into how the problem could be fixed for Goole API.
> As we discussed in the other thread, this is a problem with the
> "assumtion" on the XML element ordering. Now to fix this, we have to
> fix SoapDeSerializer class (earlier I thought it is the parser, but it
> happens to be SoapSeSerializer). We have to buffer the AnyElement
> returned by the parser at the SoapDeSerializer level if the
> m_pchNameOrValue not what is requested by the generated code and go on
> looking for next nodes. This obviously is a major change, looking at
> the number of methids using the parser next() methid in
> SoapDeSerializer. And ofcource, I *think* this would work, but we have
> to verify. It will take couple of days to update the code. However it
> will take much more time to test and fix for side effects.
> May be we could have looked into public APIs like these earlier.
> However, if we are to fix this and release, it will take another month
> or so for the code to stabilize. And those who want to use 1.5 for
> client engagements, would not like idea of changing a sensitive class
> as SoapDeSerializer at this moment.
> What if we do release 1.5 as it is and include this to 1.6?
> Thanks,
> Samisa...
>
> On Tue, 22 Mar 2005 15:33:01 -0500, Davanum Srinivas
<[EMAIL PROTECTED]> wrote:
> > John,
> >
> > I have been playing with the code...I was thinking what is the use
of
> > making a release if people can't use it to access public web
services
> > like Amazon, Google, TerraService and eBay? Can we spend some time
to
> > make our code robust and useful in the real world out-of-the-box? (I
> > can definitely confirm that the code genned out of the box does not
> > work with Google Search API for starters)
> >
> > Thanks,
> > dims
> >
> > On Tue, 22 Mar 2005 18:29:04 +0000, John Hawkins
<[EMAIL PROTECTED]> wrote:
> > >
> > > I think we should go for a 1.5 release which is client biased next
wk.
> > >
> > > The server will still work but may have issues.
> > >
> > > Thoughts?
> > >
> > >
> > >
> > >
> > > "Carsten Blecken" <[EMAIL PROTECTED]>
> > >
> > > 22/03/2005 18:15
> > >
> > > Please respond to
> > > "Apache AXIS C Developers List"
> > >
> > >
> > > To "Apache AXIS C Developers List" <[email protected]>
> > >
> > > cc
> > >
> > > Subject RE: 1.5 Release
> > >
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > sorry for the late reply. Maybe a beta could help to get the
> > > client side improvements out. Certainly worth considering,
> > > IMO.
> > >
> > > It is not that the server side is not important, but I do have
> > > some concerns about the current server side approach (There is an
> > > interesting writeup on
> > >
http://fremantle.org/paul/Web_Services_Server_options_for_Axis_C.html)
> > > and we might need to address the server side in a separate
> > > release.
> > >
> > > Carsten
> > >
> > >
> > > -----Original Message-----
> > > From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, March 18, 2005 10:14 AM
> > > To: Apache AXIS C Developers List
> > > Subject: Re: 1.5 Release
> > >
> > >
> > > Hi Sanjaya,
> > > We have not attended server side as such.
However, many
> > > fixes to
> > > serialization/de-serialization in general and code generation has
solved
> > > many problem which were generic to both sides.
> > >
> > > We have done some level of testing with C++
server against
> > > C++ clients
> > > and about 65% of the tests pass. Some of the failing ones are due
to
> > > Skeleton implementation errors. So I would rather say that the
code base
> > > is fairly stable.
> > > I have been able to fix the simple axis server
issue as
> > > well. Hence my
> > > feeling is that this is above beta quality (compared to 1.4 etc)
and we
> > > could do a 1.5 final.
> > >
> > > Thanks,
> > > Samisa...
> > >
> > > On Thu, 2005-03-17 at 10:27, sanjaya singharage wrote:
> > > > Hi all,
> > > >
> > > > Are we attending to the serverside issues?
> > > >
> > > > How about releasing a beta? but making sure that the client
side is
> > > > release quality. That way the beta will offer a snap shot of
the
> > > > stable client side for people who want the client features
quickly and
> > > > it will not be the final.(However originally in the release
plan a
> > > > beta was not talked about). But this does present a problem for
us
> > > > over here because we will only be able to test against the Axis
c++
> > > > server side.But we need to have the serverside operate
reasonably even
> > > > for a beta.
> > > >
> > > > I need some time to integrate the services to the ant services
> > > > framework (should be able to do it by tomorrow).and then we can
see
> > > > how the serverside is operating.
> > > >
> > > > what do you think folks? any other options available? Is it
possible
> > > > to go for a code freeze?
> > > >
> > > > sanjaya.
> > > --
> > > Samisa Abeysinghe <[EMAIL PROTECTED]>
> > > Virtusa Corporation
> > >
> > >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
