SOAPService thread-safe?

HI! Are SOAPService objects thread-safe? Thanks! Regards, Thomas

[WSIF] + Axis serialization problem

I have a version of the WSIF DynamicInvoker client which handles complex types in input and output. I try exactly the same WS invocation (of Amazon's service) with the WSIFDynamicProvider flavors _ApacheAxis and _ApacheSOAP. Things work fine with the Soap Provider against the 2002/10/14 nightly

RE: dotnet local tests

While it's certainly a great thing to be able to set up local .NET tests, I added a "playback" handler today which can fill the role of the server for simple "one-roundtrip" tests, simulating whatever response we desire. I'd like to filter the tests into "simple" and "complex" ones, where the

dotnet local tests

I'm putting together the tests for axis client against a local .net server; expect the commits to come in this week. If you want to run these, install IIS and then .NET framework 1.0. you wont need vs.net; just the framework installed *after* you install IIS. Oh, and dont forget the security patc

Re: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsdl Java2WsdlAntTask.java

- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 10, 2002 10:22 AM Subject: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsdl Java2WsdlAntTask.java >java/tools/org/apache/axis/tools/ant/wsdl >

RE: sync

Syncing the Session DOESN'T necessarily work. That's the point. When you have HTTP sessions, the AxisServlet creates a new AxisHttpSession object to wrap the HttpSession on every request. Locking on those objects is useless, because you really want to lock on the HttpSession. And in fact,

DO NOT REPLY [Bug 13618] - Implicit header support

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

DO NOT REPLY [Bug 13618] - Implicit header support

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

RE: sync

I don't get it, the 1st sync will sync on the session - which I believe should be ok since that's will be the same session object each time (based on what scope you have - either serlvet session or appSession). The 2nd sync will sync on something that is local (or specific) to the service it

DO NOT REPLY [Bug 13618] - Implicit header support

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

DO NOT REPLY [Bug 13618] New: - Implicit header support

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

cvs commit: xml-axis/java/test/wsdl/interop4/groupi client-config.wsdd

tomj2002/10/14 14:59:31 Modified:java build.xml java/test/wsdl/interop3 endpoints endpoints-local run.sh java/test/wsdl/interop3/compound1 build.xml java/test/wsdl/interop3/compound2 build.xml Compound2TestCase

RE: sync

> Locking the String or Object that is placed in the hashtable > will do it > since that is presistent across all threads - and it doesn't > really matter > which kind of Object it is - we just need something/anything > to sync on. The problem is that you want only one thread to be the one th

RE: sync

Locking the String or Object that is placed in the hashtable will do it since that is presistent across all threads - and it doesn't really matter which kind of Object it is - we just need something/anything to sync on. There really isn't much to say about what's happening - we have one threa

RE: sync

Could you describe exactly what's happening when you have problems? I'm assuming it's a deadlock situation, but I'm not sure I understand it - and in fact I think I see a bug in the current code. The lock is on the Session object (i.e. the AxisHttpSession for HTTP). It looks to me like ther

sync

One other thing I should point out - the scenario I was worried about (a c'tor calling another service) isn't the only problem with the current design. If a c'tor is slow (or worse hangs) the current code will not allow *any* other services (in the scope) to run. The approach below at least

sync

Glen - got kicked off of irc but I think the problem would be solved by something like this: String lockObject = null ; Object service = null ; sync (session) { Hashtable locks = session.get("AxisLocks"); if ( locks == null ) session.set("AxisLocks", locks = new Hashtable() ); if ( (l

RE: sync in JavaProvider

> It looks like (according to cvs) you added the sync blocks in > JavaProvider and its cause use some problems. > I'm trying to understand why those sync blocks were added. > From what I can > tell they don't prevent multiple threads from clobbering each others > service object that's stored

cvs commit: xml-axis/java/src/org/apache/axis/wsdl/symbolTable FaultInfo.java

tomj2002/10/14 13:02:22 Modified:java/src/org/apache/axis/deployment/wsdd WSDDFault.java java/src/org/apache/axis/message SOAPFaultDetailsBuilder.java java/src/org/apache/axis/description ServiceDesc.java

cvs commit: xml-axis/java/src/org/apache/axis/wsdl/fromJava Emitter.java

tomj2002/10/14 13:01:36 Modified:java/src/org/apache/axis/wsdl/fromJava Emitter.java Log: Some improvements on generating WSDL from Java for faults. Now we actually generate reasonable fault information for the Group H fault interop services. Of particular note, I added

Re: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsdl Java2WsdlAntTask.java

- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 10, 2002 10:22 AM Subject: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsdl Java2WsdlAntTask.java > scheu 2002/10/10 10:22:55 > > Modified:java/src/org/apache/axis/i1

Re: AxisServlet's init() overloading

AxisServlet.init() is an implementation of HttpServlet.init(), and so you cant change what gets thrown without changing the servlet spec and every implementation thereof. So, come up with a better solution. Either wrap your exception into a ServletException, or a RuntimeException() - Origina

cvs commit: xml-axis/java/src/org/apache/axis/wsdl/fromJava Emitter.java

scheu 2002/10/14 10:36:19 Modified:java/src/org/apache/axis/wsdl/fromJava Emitter.java Log: Add deprecated apis to emitter Revision ChangesPath 1.72 +77 -0 xml-axis/java/src/org/apache/axis/wsdl/fromJava/Emitter.java Index: Emitter.java

DO NOT REPLY [Bug 13611] - Conversion from AttachmentPart to DataHandler doesn't work

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

Re: Async in Axis [Scanned for known viruses]

I'd propose that a test harness that used the JBossMQ JMS implementation as an open source option would add a lot of value. "James M Snell" <[EMAIL PROTECTED]> on 10/14/2002 01:00:09 PM Please respond to [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO

DO NOT REPLY [Bug 13611] New: - Conversion from AttachmentPart to DataHandler doesn't work

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

RE: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsd l Java2WsdlAntTask.java

Thanks Rich. -- Tom Jordahl Macromedia Server Development -Original Message- From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] Sent: Monday, October 14, 2002 12:43 PM To: [EMAIL PROTECTED] Subject: RE: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsd l Java2WsdlAntTask.jav

[wsif] update for 1.2.0RC1 - making WSIF easier to use and build

hi, as seen from recent emails building WSIF (and resolving all dependencies like JMS) it is not that easy task ... therefore i have worked on making WSIF experience for developers more pleasant. i am still not there but i think to do this we need ot have two related matters improved: documentat

Async in Axis

Now that Axis 1.0 has been released, I and a number of other IBMers have started talking with David Chappell and the other Sonic folks about what we would like to in the way of support for async operations and JMS within Axis. There are a number of things that we're currently looking at: 1. C

cvs commit: xml-axis/java/src/org/apache/axis/client Call.java

gdaniels2002/10/14 09:51:04 Modified:java/src/org/apache/axis/client Call.java Log: Deprecate "scoped" property methods. All properties use the same bag in the Call now, and these properties all propagate down into the runtime (the way it used to work until a few months ago).

RE: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsd lJava2WsdlAntTask.java

Thanks for the comments. I'll add the deprecated apis and add comments to the MODE_* constants. Should be in early this afternoon. Rich Scheuerle IBM WebSphere & Axis Web Services Development 512-838-5115 (IBM TL 678-5115)

cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestServiceTestCase.java

scheu 2002/10/14 09:44:16 Modified:java/src/org/apache/axis/wsdl/toJava JavaSkelWriter.java java/test/wsdl/roundtrip RoundtripTestServiceTestCase.java Log: Added code to the skeleton writer to generate correct FaultDesc info. Revision ChangesPath 1.51

RE: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsd l Java2WsdlAntTask.java

I don't think you can have setMode() without the constants that its takes as argument... You would still get a NoDefFound error from existing code. I see your point about not being able to deprecate the constants, but you can note in the JavaDoc for them that people shouldn't use them. /** DE

RE: WSDL/Attachments issues/questions

Since I don't think anyone responded to Sam on this. 1. WSDL2Java clearly has a bug here. It should be fixed, but I don't know where 2. Adding a MIME_OCTETSTREAM return value from that utility function sounds right 3. This is just missing from WSDL2Java since the person who did DIME work on t

RE: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsd lJava2WsdlAntTask.java

Normally I would agree, but most of the time the emitter is called via command-line. So this is a developer's api only. I guess I could add getMode() and setMode() back in as deprecated and indicate that the developer should use the Style/Use methods. I don't like adding the MODE_RPC, etc. con

Re: [WSIF] Need JMS-free Axis Provider

hi, it would be nice to include jar with JMS API in repository to simplify compilation. (i think that WSIF should allow compiling SOAP providers without jms. ..) does anybody know hat is the license for JMS API and can binary jar be included? thanks, alek Jaime Meritt wrote: > Anthony, > >

cvs commit: xml-axis/java/test playback-deploy.wsdd PlaybackService.java

gdaniels2002/10/14 09:07:23 Added: java/test playback-deploy.wsdd PlaybackService.java Log: Add a very simple "playback" service which is meant to be used for testing purposes. With this we can capture problematic / useful wire traces from other servers and provide the abilit

RE: cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsdl Java2WsdlAntTask.java

Rich, +1 to this change! BUT... Is there any way we can make this change and still be backwards compatible? Can we keep the MODE_* in Emitter and the API that uses it (deprecated) so folks who are calling the emitter via API don't get broken by Axis 1.1 (or whatever)? I think this is *very*

RE: cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestSe rviceTestCase.java RoundtripTestSoapBindingImpl.java

Yes, this makes a lot of sense and is what I expected. That's why I was confused when I saw the response message generated for the roundtrip test. I should have the skeleton stuff working this morning. Rich Scheuerle IBM WebSphere & Axis Web Services Development 512-838-5115 (IBM TL 678-5115)

RE: cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestSe rviceTestCase.java RoundtripTestSoapBindingImpl.java

Rich, The details element of a fault contains an element who's QName matches: a) the part name of the fault, namespace of the fault from the binding for RPC/enc b) the element QName of the fault part for doc/lit This QName of the fault messages are registered on a per-operation basis, along wi

Faults and SOAPBuilders interop

Those darn skeletons! :-) Thanks for looking in to this - I am still playing catch up. By the way - I still have some Java2WSDL changes on my laptop that I need to check in to support WSDL generation for the fault group H services. I have a test failure with roundtrip, which is why I held of

(SOLVED) RE: cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestServiceTestCase.java RoundtripTestSoapBindingImpl.java

The FaultDesc information was not added to the Skeleten code! Roundtrip uses the skeleton. I will do that right now. BTW, good work on the fault stuff. Did you confirm at the soapbuilders meeting that this is the most interoperable form to use ? Rich Scheuerle IBM WebSphere & Axis Web Servic

RE: cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestServiceTestCase.java RoundtripTestSoapBindingImpl.java

Now I am looking at wsdl/faults. Hmm, big difference in what is flowed back in the response! So now I am thinking that this is a serialization problem. In wsdl/faults, the properties are flowed back in the details section. For roundtrip I have the following in the details section: So I wil

RE: cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestServiceTestCase.java RoundtripTestSoapBindingImpl.java

Looking at tcpmon and RoundtripTestServiceTestCase for throwInvalidTickerException. The Response message in tcpmon does contain the ticker symbol name "ABC". However, the exception that is caught in RoundtripTestServiceTestCase has a tickerSymbol of null. So apparently there is a problem in the

RE: cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestServiceTestCase.java RoundtripTestSoapBindingImpl.java

I'll run it under tcpmon and see what happens. Rich Scheuerle IBM WebSphere & Axis Web Services Development 512-838-5115 (IBM TL 678-5115)

AXIS support CORBA Object?

hi,     Axis has many providers such as javaprovider, ejbprovider   Should AXIS need a CORBAprovider to support CORBA object as web service implementation?     thanks.     Best Regards, Luozhen=

RE: cvs commit: xml-axis/java/test/wsdl/roundtrip RoundtripTestServiceTestCase.java RoundtripTestSoapBindingImpl.java

Rich, The wsdl/faults tests are working, why isn't this one? -- Tom Jordahl Macromedia Server Development -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 6:04 PM To: [EMAIL PROTECTED] Subject: cvs commit: xml-axis/java/test/wsdl

RE: cvs commit: xml-axis/java/src/org/apache/axis/wsdl/symbolTable SymbolTable.java

I was wondering why we were seeing that warning message from WSDL2Java. Good catch Russell! -- Tom Jordahl Macromedia Server Development -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 4:59 PM To: [EMAIL PROTECTED] Subject: cvs co

RE: Call setProperty/setScopedProperty

Definitely. The key would be to make setProperty() work as expected - I'd deprecate setScopedProperty() but leave it functional for now. I'll see about doing this later today barring negative feedback. --Glen > -Original Message- > From: Doug Davis [mailto:[EMAIL PROTECTED]] > Sent:

Re: Call setProperty/setScopedProperty

Make sure if you remove one of 'em that you deprecate it since we can't actually remove it right away. -Dug

Re: Call setProperty/setScopedProperty

+1. Sure Glen... Thanks, dims --- Glen Daniels <[EMAIL PROTECTED]> wrote: > > Can we merge these two back together? I think the reason they were split out was >something to > do with TCK compliance, but I can't see how that would be affected by whether or not >Call > properties are available

DO NOT REPLY [Bug 13602] New: - array bug in response XML document

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_b

Call setProperty/setScopedProperty

Can we merge these two back together? I think the reason they were split out was something to do with TCK compliance, but I can't see how that would be affected by whether or not Call properties are available via the MessageContext. Call.setProperty() should do what it used to, namely make pr

cvs commit: xml-axis/java/src/org/apache/axis/transport/http HTTPSender.java

gdaniels2002/10/14 06:11:17 Modified:java/src/org/apache/axis/client Call.java java/src/org/apache/axis/soap SOAP12Constants.java java/src/org/apache/axis/transport/http HTTPSender.java Log: Enable SOAP 1.2 webmethod feature. Use it like this:

RE: [WSIF] Need JMS-free Axis Provider

Anthony, The Axis JMS transport should have the functionality you need for use in WSIF. It is possible however that WSIF adds requirements that were not included in our initial implementation of the transport. I would really appreciate if you or any of the other WSIF folks can help me to figure

Re: [WSIF] Need JMS-free Axis Provider

Ant, Yes, you should not have to duplicate the JMS code in WSIF's axis-providerYes, Please take a look at the JMS Transport checked into Axis. Thanks, dims --- Anthony Elder <[EMAIL PROTECTED]> wrote: > > The axis provider works fine without any JMS classes at run time so I guess > you wa

Re: [WSIF] Need JMS-free Axis Provider

The axis provider works fine without any JMS classes at run time so I guess you want one that can be built without JMS? It would be reasonably straight forward to create a new axis provider with all the JMS code stripped out, but then there would be a lot of code duplicated between the JMS and n