DO NOT REPLY [Bug 9473] - problem with the basic install of Axis on Web Server Resin 2.1.0

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

DO NOT REPLY [Bug 9473] - problem with the basic install of Axis on Web Server Resin 2.1.0

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/docs integration-guide.html

rsitze 2002/10/09 15:08:47 Modified:java/docs integration-guide.html Log: Moving toward portable JSSE solution.. Revision ChangesPath 1.16 +66 -0 xml-axis/java/docs/integration-guide.html Index: integration-guide.html

cvs commit: xml-axis/java/src/org/apache/axis/components/net JDK14FakeTrustSocketFactory.java JDK14JSSESocketFactory.java

rsitze 2002/10/09 15:08:27 Modified:java/src/org/apache/axis/components/net JDK14FakeTrustSocketFactory.java JDK14JSSESocketFactory.java Log: Moving toward portable JSSE solution.. Revision ChangesPath 1.2 +67 -66

RE: [VOTE] Again for explicitHeaderWork (Glen)

Sylvain, Please open a bugzilla enhancement request and post the latest cvs diff as attachment in bugzilla. Thanks, dims --- "St-Germain, Sylvain" <[EMAIL PROTECTED]> wrote: > > Feel good to see that you remember what was my point back then Glen. > > Although we should appreciate any con

RE: [VOTE] Again for explicitHeaderWork (Glen)

Feel good to see that you remember what was my point back then Glen. Although we should appreciate any contribution, implicit headers appears to be much more in demand than explicit ones and this, no mater what the spec says. IMNSHO, explicit headers should not prevent nor slow down the in

cvs commit: xml-axis/java/test/wsdl/header header.wsdl

butek 2002/10/09 13:51:31 Modified:java/src/org/apache/axis/wsdl/symbolTable SymbolTable.java Utils.java java/src/org/apache/axis/wsdl/toJava JavaDefinitionWriter.java JavaDeployWriter.java JavaFaul

DO NOT REPLY [Bug 13470] New: - reading list available in download is not available on web site

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/src/org/apache/axis/wsdl/toJava Utils.java

rubys 2002/10/09 13:10:17 Modified:java/src/org/apache/axis Constants.java java/src/org/apache/axis/encoding DefaultTypeMappingImpl.java java/src/org/apache/axis/wsdl/toJava Utils.java Log: Fixes so that WSDL2Java doesn't outri

DO NOT REPLY [Bug 13468] New: - Call properties not passed to MessageContext

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

JSSE Security - change direction...

I'd appreciate Dim's opinions on this: Problem: JSSE is/was bound to sun implementation, in code. JSSE can be configured by code (considered 'dynamic'), or configured during install/registration ('static') with the JDK (see http://java.sun.com/products/jsse/doc/guide/API_users_guide.h

DO NOT REPLY [Bug 13416] - Malformed WSDL file

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-wsif/java/src/org/apache/wsif/providers/java WSIFPort_Java.java WSIFOperation_Java.java

owenb 2002/10/09 09:07:17 Modified:java/src/org/apache/wsif/providers/ejb WSIFOperation_EJB.java java/src/org/apache/wsif/providers/java WSIFPort_Java.java WSIFOperation_Java.java Log: Added the following fixes: - F

RE: [VOTE] Again for explicitHeaderWork (Glen)

Hey guys, this is Glen writing from Mark's machine here at the interop (he has this frighteningly neat setup with a cellphone... but I digress.). After reading this, and taking a look at the details of the WSDL, I concur with Greg's analysis of the situation. The fundamental problem here is wit

Re: cvs commit: xml-axis/java/xmls targets.xml

It's a mess, we all agree. That something changed between Beta3 and RC1/2, no doubt. But the issue was NOT pluggability, the issue is about change of default implementation. I agree that you should NOT be required to make changes to axis to use it out-of-box. HOWEVER (that's a BIG HOWEVER),

DO NOT REPLY [Bug 13459] - section does not include all types in TypeMapping

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 13459] New: - section does not include all types in TypeMapping

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: [VOTE] Again for explicitHeaderWork (Glen)

I think that there are some subtle differences in much of what is being pointed to (which could be the cause of the confusion - IMHO). I'm going to try and take a pass at trying to explain what the problem is (as we see it) and why some of these other things aren't quite the same take. Imagi

Re: [WSIF] Improving performance of WSIF stub invocation

Nirmal Erm... This design point came from the JCA team. Michael B in particular was adamant we did it this way, and we (Sanjiva, Michael and I) went through a number of iterations on this. I don't believe we can change this without agreement from the JCA provider team. How about explicitly iden

AxisServlet's init() overloading

Hi All, There are some situations where one has to overload AxisServlet's init() method and sign somehow if there was a problem. This cannot be done because of the AxisServlet's init() doesn't define 'thorws' clause in its signature. Is there any reason to disallow throwing an exception in ini

Re: SOAPHeader and Call

Well, I think that the : "Axis 1.0 of October,7" will correct this problem; the Call object manages headers outside the if{} - Original Message - From: "BOURLON Agnès" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 09, 2002 2:53 PM Subject: SOAPHeader and Call > Hi

SOAPHeader and Call

Hi, Is it possible to add headers in a Soap enveloppe using the call.addHeader(...) in client code? It seems to have no effect on the envelope ... Indeed, in the org.apache.axis.client.Call.invoke(), the headers are added only if client service target is null and "portName" too : If we loo

RE: [VOTE] Again for explicitHeaderWork (Glen)

Hi Russell. A quick comment on your mail here before I take off. WSDL 1.1 says nothing about how to do language bindings. It supports the ability to say "this header with QName foo:bar is tied to this message part for this operation" - that's it. JAX-RPC has a chapter (11) which talks about

RE: [VOTE] Again for explicitHeaderWork (Glen)

But these are explicit headers. They are already in the functional signature. There is no choice here. Rich Scheuerle IBM WebSphere & Axis Web Services Development 512-838-5115 (IBM TL 678-5115)

RE: [VOTE] Again for explicitHeaderWork (Glen)

"Otherwise we cease to comply with various specs out there."   Not complying with bad specs... and that would be a bad thing? Rick Rineholt "The truth is out there...  All you need is a better search engine!" [EMAIL PROTECTED] Please respond to [EMAIL PROTECTED] To:        [EMAIL PROTECTED] c

cvs commit: xml-axis-wsif/java/src/org/apache/wsif/util WSIFUtils.java

owenb 2002/10/09 05:39:15 Modified:java/src/org/apache/wsif/util WSIFUtils.java Log: Changed getPackageNameFromXMLName method so that is preserves case in the same way as getPackageNameFromNamespaceURI Revision ChangesPath 1.20 +1 -1 xml-axis-wsif/java/src

RE: [VOTE] Again for explicitHeaderWork (Glen)

You guys just don't get it. While I agree that explicit headers - headers that are method parameters - are poor programming practice, WSDL 1.1 supports it, JAX-RPC defines how it works, and users (including interop folks if I understand dims correctly, and WS-I) use it. It is not our place t

cvs commit: xml-axis/java/test/wsdl/interop4/groupi round4XSD.wsdl Round4XSDTestSoapImpl.java Round4XSDTestTestCase.java

dims2002/10/09 05:24:27 Modified:java/test/wsdl/interop4/groupi round4XSD.wsdl Round4XSDTestSoapImpl.java Round4XSDTestTestCase.java Log: Updates to Round4 Impl and testcase. Revision ChangesPath 1.3 +23 -241 xm

cvs commit: xml-axis/java/src/org/apache/axis/i18n resource.properties

dims2002/10/09 05:15:45 Modified:java/src/org/apache/axis/client Call.java java/src/org/apache/axis/i18n resource.properties Log: Interop4 testing...Throw AxisFault if we don't find the specified return param Revision ChangesPath 1.182 +10 -2 x

cvs commit: xml-axis-wsif/java/src/org/apache/wsif/providers/jms JMSFormatter.java WSIFOperation_Jms.java

whitlock2002/10/09 04:52:11 Modified:java/test/org/apache/wsif/util/jms NativeJMSRequestListener.java java/test/jms JmsFault.wsdl JmsFaultTest.java java/src/org/apache/wsif/providers/jms JMSFormatter.java WSIF

RE: [VOTE] Again for explicitHeaderWork (Glen)

I don't use the stubbies but if people like the idea of a 1-1 relationship between a stub and a Call object why not just have the Stub extend Call and then everything available to the Call is available to the Stub user. -Dug Tom Jordahl <[EMAIL PROTECTED]> on 10/08/2002 11:50:52 PM Please