[wsif] 2.0 first alpha release

hi, i have put first ALPHA release (both source and binary) in http://cvs.apache.org/dist/axis/wsif/ the goal of this release is to use it to check what is still missing toward the first official release and this alpha release should quickly followed by beta and release candidate versions. we

DO NOT REPLY [Bug 15300] New: - WSDLException: faultCode=OTHER_ERROR: Can't find prefix for 'http://ejb.javax'. Namespace prefixes must be set on the Definition object using the addNamespace(...) method

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_bu

cvs commit: xml-axis-wsif/java/lib/jaf README.txt

aslom 2002/12/11 20:52:16 Removed: java/lib/jaf README.txt Log: duplicated with activation/ directory

cvs commit: xml-axis-wsif/java/samples/simplesoap/client/stub README.html

aslom 2002/12/11 20:39:55 Modified:java build.bat build.sh build.xml classpath.bat classpath.csh classpath.sh java/doc build.htm samples.html java/samples/simplesoap/client/dynamic README.html java/samples/simples

cvs commit: xml-axis-wsif/java/lib/xerces2 xercesImpl_2_2_1.jar xmlParserAPIs_2_2_1.jar

aslom 2002/12/11 20:36:09 Modified:java/lib/jaxrpc README.txt java/lib/saaj README.txt Added: java/lib/ant LICENSE.txt README.txt ant_1_5_1beta.jar optional_1_5_1beta.jar java/lib/apache_soap README.txt apache_soap_2_3_1.jar

cvs commit: xml-axis-wsif/java/src/org/apache/wsif/providers/jca WSIFResource_JCA.java WSIFMessage_JCA.java WSIFOperation_JCA.java WSIFMessage_JCAStreamable.java WSIFPort_JCA.java WSIFUtils_JCA.java

piotrp 2002/12/11 17:39:09 Modified:java/src/org/apache/wsif/providers/jca/toolplugin PortTypeSelection.java PortTypeArray.java ImportDefinition.java ImportResource.java OperationSelection.java ImportXSD.java Import

RE: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.j ava

I respectfully disagree on both counts. :) SerializationContextImpl has the desired behavior already with no changes. You can register mappings up until the point when you call startElement(), at which point we push() a new NSStack frame. We pop() on endElement()s. --G > -Original Mess

Re: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.j ava

Uhh, I think you'll also need to change SerializationContextImpl to use the same approach you implemented in DeserializationContextImpl. To be honest, I think just changing pop() to match the required usage is simpler and cleaner. :-) - Dennis Glen Daniels wrote: Oh, I see! That doesn't sou

RE: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.j ava

Oh, I see! That doesn't sound like an NSStack problem, but a usage problem. Check out my last commit and see if that makes things happier - we now push a frame when we see the first new mapping OR when we hit startElement if there aren't any mappings. This ensures that the pop() during endEl

cvs commit: xml-axis/java/src/org/apache/axis/encoding DeserializationContextImpl.java

gdaniels2002/12/11 15:25:15 Modified:java/src/org/apache/axis/encoding DeserializationContextImpl.java Log: Push a new NSStack frame when we see the first mapping, not on startElement(). However if there are no mappings, push() on startElement() so pop()

FW: WSDL2Java - How to configure the Stubclasses name ?

> -Original Message- > From: Tom Jordahl [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 09, 2002 5:57 PM > To: '[EMAIL PROTECTED]' > Subject: RE: WSDL2Java - How to configure the Stubclasses name ? > > The name of your wsdl:service and wsdl:PortType are the same. > WSDL2Java resolves

Re: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.java

As stated in the bug report, the problem here is that SAX requires namespaces to be reported *before* the start of the element: http://www.saxproject.org/apidoc/org/xml/sax/ContentHandler.html#startPrefixMapping(java.lang.String,%20java.lang.String) There's a good reason for this - the element a

cvs commit: xml-axis/java/tools/org/apache/axis/tools/ant/wsdl Java2WsdlAntTask.java MappingSet.java NamespaceMapping.java Wsdl2javaAntTask.java

gdaniels2002/12/11 14:42:53 Modified:java/tools/org/apache/axis/tools/ant/axis AdminClientTask.java java/tools/org/apache/axis/tools/ant/foreach ForeachTask.java java/tools/org/apache/axis/tools/ant/wsdl

cvs commit: xml-axis/java/samples/userguide/example5 Client.java

gdaniels2002/12/11 14:41:15 Modified:java/samples/addr AddressBookTestCase.java Main.java java/samples/attachments EchoAttachment.java EchoAttachmentsService.java TestRef.java java/samples/bidbuy TestClient.java rfq.java v3.java

RE: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.java

Hi Dennis: A quick scan of the logic in NSStack looks OK to me... When we get to a new element (while serializing or deserializing) the appropriate context will push() manually, to ensure a null on the stack. Then each time we add() a mapping, push() gets called simply as a convenience to mov

cvs commit: xml-axis-wsif/java/src/org/apache/wsif/providers/jca WSIFOperation_JCA.java WSIFUtils_JCA.java WSIFMessage_JCAStreamable.java WSIFMessage_JCA.java WSIFPort_JCA.java WSIFResource_JCA.java

piotrp 2002/12/11 14:26:00 Modified:java/src/org/apache/wsif/providers/jca/toolplugin Tag: pre1_2_0-patches PortTypeSelection.java Import.java ImportXSD.java ImportResource.java ImportDefinition.java OperationSelect

Re: cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.java

Hi Glen, Looks like you've put the namespace stack problem back in by restoring the original order of operations (call to clearFrame() before decrementing top). Am I missing something here? The problem I saw was that namespaces were pushed on the stack before the null value, so the null value

Re: VOTE : Jaime Meritt as committer

All, Just wanted to say thanks to all of you for the vote of confidence. I really appreciate it and I look forward to continuing to work with all of you. Thanks again, Jaime Meritt Sonic Software Corporation - Original Message - From: Chris Haddad <[EMAIL PROTECTED]> Date: Wednesday, D

cvs commit: xml-axis-wsif/java/lib/j2ee - New directory

aslom 2002/12/11 13:34:07 xml-axis-wsif/java/lib/j2ee - New directory

DO NOT REPLY [Bug 15288] New: - NPE in HTTPSender.getSocket() (when using "https" protocol)

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_bu

cvs commit: xml-axis-wsif/java/samples/localjava/client/stub README.html

nmukhi 2002/12/11 12:49:16 Modified:java/samples/localjava/client/stub README.html Log: Minor edits Revision ChangesPath 1.2 +6 -7 xml-axis-wsif/java/samples/localjava/client/stub/README.html Index: README.html ==

cvs commit: xml-axis-wsif/java/doc samples.html

nmukhi 2002/12/11 12:42:16 Modified:java/doc samples.html Log: Fixing broken links Revision ChangesPath 1.3 +16 -16xml-axis-wsif/java/doc/samples.html Index: samples.html === RCS file: /ho

cvs commit: xml-axis-wsif/java/samples/localjava/service AddressBookImpl.java

nmukhi 2002/12/11 12:38:40 Added: java/samples/localjava AddressBook.wsdl java/samples/localjava/client/dynamic README.html Run.java java/samples/localjava/client/stub README.html Run.java java/samples/localjava/client/stub/addressbook/wsif

cvs commit: xml-axis-wsif/java/samples/localjava/client/stub/addressbook/wsiftypes - New directory

nmukhi 2002/12/11 12:37:29 xml-axis-wsif/java/samples/localjava/client/stub/addressbook/wsiftypes - New directory

cvs commit: xml-axis-wsif/java/samples/localjava/client/stub/addressbook/wsifservice - New directory

nmukhi 2002/12/11 12:37:29 xml-axis-wsif/java/samples/localjava/client/stub/addressbook/wsifservice - New directory

cvs commit: xml-axis-wsif/java/samples/localjava/client/stub/addressbook - New directory

nmukhi 2002/12/11 12:37:19 xml-axis-wsif/java/samples/localjava/client/stub/addressbook - New directory

cvs commit: xml-axis-wsif/java/samples/localjava/client/stub - New directory

nmukhi 2002/12/11 12:36:57 xml-axis-wsif/java/samples/localjava/client/stub - New directory

cvs commit: xml-axis-wsif/java/samples/localjava/client/dynamic - New directory

nmukhi 2002/12/11 12:36:57 xml-axis-wsif/java/samples/localjava/client/dynamic - New directory

cvs commit: xml-axis-wsif/java/samples/localjava/service - New directory

nmukhi 2002/12/11 12:36:33 xml-axis-wsif/java/samples/localjava/service - New directory

cvs commit: xml-axis-wsif/java/samples/localjava/client - New directory

nmukhi 2002/12/11 12:36:33 xml-axis-wsif/java/samples/localjava/client - New directory

cvs commit: xml-axis-wsif/java/samples/simplesoap/client/stub README.html

nmukhi 2002/12/11 12:36:14 Modified:java/samples/complexsoap/client/dynamic README.html java/samples/complexsoap/client/stub README.html java/samples/localjava README.html java/samples/simplesoap/client/dynamic README.html java

RE: Web Services top-level project (was Re: [AXIS/WSIF] proposed new WSIF home page URL)

+1 > -Original Message- > From: Davanum Srinivas [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 11, 2002 2:42 PM > To: [EMAIL PROTECTED] > Subject: Re: Web Services top-level project (was Re: [AXIS/WSIF] > proposed new WSIF home page URL) > > > I agree. One community would be be

RE: Trying to get a build working ?

Paul: Just for future reference, you can look in java/test-reports under your Axis root dir, and you'll find the outputs from the various tests in there. If you sort them most-recent-first, you can open up the top one and see what went wrong. The current CVS source works fine for me too, I'd

RE: Trying to get a build working ?

Hi Paul Can u try with the latest source. The build works just fine for me Thanks Vidyanand -Original Message- From: Paul Campbell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 11:27 AM To: [EMAIL PROTECTED] Subject: Trying to get a build working ? >junit: >[juni

Re: Web Services top-level project (was Re: [AXIS/WSIF] proposed new WSIF home page URL)

I agree. One community would be better. -- dims --- Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > "Sam Ruby" <[EMAIL PROTECTED]> writes: > [snip] > > > > We *could* go down the path where the code is partitioned up very finely > > with individual access rights to each, but if history is any

Re: Web Services top-level project (was Re: [AXIS/WSIF] proposed new WSIF home page URL)

"Sam Ruby" <[EMAIL PROTECTED]> writes: [snip] > > We *could* go down the path where the code is partitioned up very finely > with individual access rights to each, but if history is any guide, the > likely result is duplication and invention of isolation layers. I agree; we're better off having

Trying to get a build working ?

>junit: >[junit] Running test.RPCDispatch.PackageTests >[junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 5.029 sec >[junit] Running test.badWSDL.PackageTests >[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 25.273 sec >[junit] Running test.chains.Package

RE: DO NOT REPLY [Bug 15284] New: - Proposed modification to Oper ationDesc

I don't disagree with having options - its just a matter of "easy of use". If solving an easy problem require people to understand advanced topics then I believe Axis' success will be limited. Let me give you a concrete example - more often than not when I run into a "user error" I end up havi

RE: DO NOT REPLY [Bug 15284] New: - Proposed modification to Oper ationDesc

I don't see any harm in giving the developers options. If they want to use advanced solutions, let them. -Original Message- From: Doug Davis [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 10:21 AM To: Norman, Eric; [EMAIL PROTECTED] Subject: RE: DO NOT REPLY [Bug 15284] New

RE: DO NOT REPLY [Bug 15284] New: - Proposed modification to Oper ationDesc

You could create wrapper classes for each one where those new classes add the extra param for you (heck you could even automate the process that creates them based on the list of classes/methods you want to expose). True that's annoying but to me changing Axis is more annoying since I believe

RE: DO NOT REPLY [Bug 15284] New: - Proposed modification to OperationDesc

The classes we are exposing as webservices are dual-use classes and we would rather not have to modify all our business logic classes to make axis happy. It seems to me that it is up to the provider to determine how to call the method. In our case, in the invokeMethod(..) method of our provider w

cvs commit: xml-axis-wsif/java/src/org/apache/wsif/providers/soap/apachesoap WSIFPort_ApacheSOAP.java

owenb 2002/12/11 10:17:36 Modified:java/src/org/apache/wsif/providers/soap/apachesoap WSIFPort_ApacheSOAP.java Log: Fixed serialization by making non-Serializable global variables transient and implementing readObject and writeObject methods Revision

cvs commit: xml-axis-wsif/java/test/serialization SerializationTest.java

owenb 2002/12/11 10:16:53 Modified:java/test/serialization SerializationTest.java Log: Added new tests for WSIFPorts, WSIFMessage and org.apache.wif.schema schema objects Revision ChangesPath 1.3 +259 -17 xml-axis-wsif/java/test/serialization/SerializationTest.j

cvs commit: xml-axis-wsif/java/test/serialization SerializationTest.java

owenb 2002/12/11 10:14:14 Modified:java/test/serialization Tag: pre1_2_0-patches SerializationTest.java Log: Added new tests for WSIFPorts, WSIFMessage and org.apache.wif.schema schema objects Revision ChangesPath No revision

cvs commit: xml-axis-wsif/java/src/org/apache/wsif/providers/soap/apachesoap WSIFPort_ApacheSOAP.java

owenb 2002/12/11 10:13:00 Modified:java/src/org/apache/wsif/providers/soap/apachesoap Tag: pre1_2_0-patches WSIFPort_ApacheSOAP.java Log: Fixed serialization by making non-Serializable global variables transient and implementing readObject and writeObject m

RE: Proposed changes to OperationDesc

Title: RE: Proposed changes to OperationDesc Just a suggestion...  Since you are extending a provider, you could override the generateWSDL method and process the Document created by the super class to remove the elements you don't want.  I do something similar to add elements to some operatio

Re: DO NOT REPLY [Bug 15284] New: - Proposed modification to OperationDesc

Wouldn't a cleaner solution be to do what we do for the messageContext, which is stick it in some ThreadLocal data. You have a solution for adding a 1st parameter, but what if someone wants to add it at the end, or in the middle. Placing it in ThreadLocal storage would not require any change

DO NOT REPLY [Bug 15284] New: - Proposed modification to OperationDesc

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_bu

RE: Proposed changes to OperationDesc

I honestly don't see how that would help. The main obstacle is getting the generated WSDL to omit the offending parameter. To get that to happen, you either have to change the description of the operation before generating the WSDL or do some heavy lifting in the WSDL Emitter. -Original Mess

DO NOT REPLY [Bug 14902] - elements without minOccurs="0" produce isnill="true" on the wire

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_bu

cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.java

gdaniels2002/12/11 09:17:45 Modified:java/test/functional TestMessageSample.java java/test/encoding TestDOM.java java/src/org/apache/axis/encoding SerializationContextImpl.java java/src/org/apache/axis/utils NSStack.jav

RE: [wsif] WSDL2Java and WSIF

Hi, From Tom's post on this subject: "WSDL2Java in Axis was designed to produce the correct JAX-RPC artifacts in the face of incomplete WSDL.". This tells me that WSDL2Java should be sufficient for our needs (with perhaps command line args or such that suppress Axis specific class generation). F

Re: Web Services top-level project (was Re: [AXIS/WSIF] proposed newWSIF home page URL)

+1 for for webservices.apache.org and ws.apache.org as the umbrella for all WS work in Apache. +1 for a single set of committers - I think we can all be responsible while at the same time promoting code sharing and interactions between related communities. Nirmal. Sam Ruby <[EMAIL PROTECTED

RE: [GUMP] Build Failure - Axis

I think I just fixed this with the NSStack update, but it looks like this test is still producing bad XML (even though it passes). Looking into it. --G > -Original Message- > From: Sam Ruby [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 11, 2002 8:28 AM > To: [EMAIL PROTECTED]

cvs commit: xml-axis/java/src/org/apache/axis/utils NSStack.java

gdaniels2002/12/11 08:12:30 Modified:java/src/org/apache/axis/providers/java RPCProvider.java java/src/org/apache/axis/utils NSStack.java Log: Tweak NSStack fix, and throw the unwrapped exception if deserializing from within RPCProvider. Revision ChangesPat

[wsif] IRC meeting tomorrow to discuss WSIF release plans

hi, we continue work on next WSIF release and we should be meeting on the WSIF IRC channel at 3pm GMT (10am EST) tomorrow, Thursday 12th December. the aim is to check our progress, look on current release plan and schedule (can we get Apache WSIF release out before Christmas?) the WSIF channel i

cvs commit: xml-axis-wsif/java/samples/multibinding README.html

nmukhi 2002/12/11 08:00:48 Added: java/samples/customfactory README.html java/samples/ejb README.html java/samples/jca README.html java/samples/jms README.html java/samples/multibinding README.html Log: README placeholder

cvs commit: xml-axis-wsif/java/samples/java README.html

nmukhi 2002/12/11 07:57:31 Added: java/samples/java README.html Log: README for local java invocation sample Revision ChangesPath 1.1 xml-axis-wsif/java/samples/java/README.html Index: README.html

[wsif] Renamed sample directories

Hi, I renamed the sample directories (made them all lowercase as we decided). So delete your java/samples directory and update from CVS so that you don't run into problems later. Nirmal.

Fwd: Re: FW: Unused imports

FYI.. Note: forwarded message attached. = Davanum Srinivas - http://xml.apache.org/~dims/ __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- Begin Message --- +1 -Original Message

Re: Web Services top-level project (was Re: [AXIS/WSIF] proposed new WSIF home page URL)

Tom Jordahl wrote: > I would think that each of the sub projects would have its own set of > committers. I don't think I should have the rights to muck with the > WSIF code just because I know what I am doing in Axis. > > Given that we expect the number of projects involving web services to > only

Re: [AXIS/WSIF] proposed new WSIF home page URL

Sanjiva Weerawarana wrote: "Sam Ruby" <[EMAIL PROTECTED]> wrote: My assessment of the timescales: http://xml.apache.org/axis/wsif now. Simply check in what you want here: http://cvs.apache.org/viewcvs.cgi/xml-site/targets/axis/. I have a cron job which updates the main site from thi

RE: Web Services top-level project (was Re: [AXIS/WSIF] proposed new WSIF home page URL)

I would think that each of the sub projects would have its own set of committers. I don't think I should have the rights to muck with the WSIF code just because I know what I am doing in Axis. Given that we expect the number of projects involving web services to only increase, I think it woul

Re: VOTE : Jaime Meritt as committer

+1 welcome aboard jaime. Chris On Tue, 10 Dec 2002, Glen Daniels wrote: > > I'd like to officially nominate Jaime Meritt from Sonic as an Axis committer. > > He's been doing great work on the async stuff (despite my not agreeing with all the >APIs :)), and has submitted good bug fixes. > > I

Re: Web Services top-level project (was Re: [AXIS/WSIF] proposednew WSIF home page URL)

Davanum Srinivas wrote: +1 for creating a new project called webservices.apache.org and migrating Apache Axis, Apache SOAP, WSIF, WSIL etc. under that as components. That means there would be one set of committers, one PMC, one set of rules/guidelines etc.. Let me expand upon that last statement

RE: FW: Unused imports

I think the idea of IDEA's ordering is to put the imports that are the most generic down at the bottom, i.e. the core java.* classes. That way the first thing you see is specific stuff that's from other codebases, then java extensions, and finally java core packages. I think I actually like t

Re: Proposed changes to OperationDesc

Sounds to me like you should be using a handler to add a header to the soap message, not mucking with the description of the operation. Russell Butek [EMAIL PROTECTED]

Re: FW: Unused imports

Consistency is more important than any particular pattern - I personally would prefer everything alphabetized - but I thought we discussed this a few months ago and decided on 2 groups: first the non-Java stuff, alphabetized, then the Java stuff, alphabetized. Since '.' is before 'x', this wo

cvs commit: xml-axis/java/src/org/apache/axis/providers/java EJBProvider.java

gdaniels2002/12/11 05:40:04 Modified:java/src/org/apache/axis/providers/java EJBProvider.java Log: Housecleaning Revision ChangesPath 1.35 +6 -7 xml-axis/java/src/org/apache/axis/providers/java/EJBProvider.java Index: EJBProvider.java ===

[GUMP] Build Failure - Axis

This email is autogenerated from the output from: Build results exceed maximum length. Please see URL above for details. Last 50 li

Web Services top-level project (was Re: [AXIS/WSIF] proposed new WSIF home page URL)

+1 for creating a new project called webservices.apache.org and migrating Apache Axis, Apache SOAP, WSIF, WSIL etc. under that as components. That means there would be one set of committers, one PMC, one set of rules/guidelines etc.. Thanks, dims --- Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote

RE: [wsif] WSDL2Java and WSIF

We did start talking about this a while ago (http://marc.theaimsgroup.com/?l=axis-dev&m=103349195218980&w=2) , but as AXIS 1.0 was just coming out it got left. Ideally WSIF needs two things: - A WSDL2Java like tool to generate the service interface and complex type classes from a WSDL file - An

Re: [AXIS/WSIF] proposed new WSIF home page URL

OK looks like this is decided for us, lets go with xml.apache.org/axis/wsif for this release, we already have enough votes to do this right now. ws.apache.org/wsif seems like a good prospect perhaps in time for a WSIF 2.1 release so how about we aim for that in the background. Sam, is there anyth