Hi Chuck, I'm happy to see that you guys are doing a good deal of patches (even on 0.94) but I'm slightly uncomfortable to state that 0.95 will be solving all your problems. I mean we have done a number of changes that improves the functionality but It seems that some things are yet to be done, say the choice support (Since I changed the deser mechanism we've not been able to implement the support for choice and all yet). My guess is the best option would be to wait until 0.95 comes out and see whether it has everything you need. I'll try to fix the issues , specially the choice support and hopefully we'll be able to include it in 0.95.
Ajith On 3/20/06, Chuck Williams <[EMAIL PROTECTED]> wrote: > Hi Ajith, > > Thanks for your response. That explains things. We need to decide whether > to try to use the current code base, or try to replicate your fixes for this > issue in our current code base and wait for 0.95. In order to use the > current code base, we would need for it to be as stable as 0.94 and to have > addressed all the issues I've submitted patches for: support for choice > particles, support for recursive data types, support for minOccurs=0 in both > array and optional scalar cases, support for subelements with same name but > different type as parent element, fix to OMStAXWrapper.getElementText() to > conform to contract of getElementText(). > > Do you have some advice regarding whether we should upgrade now or wait > until 0.95? If we should wait until 0.95, then could we grab your new > Options class and use it with our existing code base? Making the service > not be static would seem to require changes to Stub and the stub xsl > template for both _service and _operations. > > Upgrading to your latest code and jettisoning all of our patches would be > best if possible! > > Thanks for any advice, > > Chuck > > > > "Ajith Ranabahu" <[EMAIL PROTECTED]> wrote on 03/18/2006 07:11:37 > PM: > > > > Hi Chuck, > We discovered this as a bug in our options class and fixed it sometime > back. The issue was that the parent-child hierarchy of the options > objects were not getting treated properly in the getter methods. > Stubs are meant to be used for multiple operations and you should be > able to use one instance for multiple invocations of the > same/different services! We also had a problem with the Axisservice > being static inside the stub and now that is changed too. > So all your issues should be solved in the latest code base :) > > Ajith > > > > On 3/18/06, Chuck Williams <[EMAIL PROTECTED]> wrote: > > > Resending with proper subject header: > > > Hi All, > > We have been creating a new Stub instance for every operation initiated > by our client, because if we don't, subsequent operations always get > confused and think they are instances of the first operation performed. > I.e., if we do operation A and then operation B on the same Stub, then > the operation for B sends the correct message payload to the server, but > the server thinks it is another A operation; the implementation of A of > course then dies because the message is of the wrong type. > > In looking at the code, it seems this must be a bug as the Stub is > designed to be reused across operations. Is this a known problem? We > are using the http client transport. Or perhaps, the bug is on the > server side not accepting a message for a different operation on the > same connection? We are using the built-in http client on the server > side. There is this interesting comment at the top of Stub.java: > > > > /** > * If _maintainSession is set to true, all the calls can use the same > * ServiceContext. The user can share information through this > * ServiceContext across operations. > */ > > However, grep _maintainSession shows no other references in the axis2 > code base. I'm wonder if this is somehow related to our issue. E.g., > if the operation is somehow sticky in the ServiceContext. I don't see > any other shared state than the ServiceContext (and Options) across > client operations on a single Stub instance. > > I'm looking into this problem again because we are getting a large > number of hanging TimerThreads in our client on Windows. The same > behavior does not happen running on linux. Anyone seen this issue? > > Thanks for any help, > > Chuck > > > > > -- > > Chuck Williams > Manawiz > Principal > V: (808)885-8688 > C: (415)846-9018 > [EMAIL PROTECTED] > Skype: manawiz > AIM: hawimanawiz > Yahoo: jcwxx > > > > -- > Ajith Ranabahu > > > -- Ajith Ranabahu
