ly (in tcpmon.java). Fixed it.
Thanks,
dims
--- Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> Dug,
>
> I have not switched to 1.4, so i use jdk1.3.1 everyday with no
problems...
>
> Thanks,
> dims
>
> --- Doug Davis <[EMAIL PROTECTED]> wrote:
> >
> >
I can no longer compile axis with JDK 1.3.1 - does Axis no longer support
1.3.1?
-Dug
You've got to be kidding! :-)
What if you don't have WSDL - say you're handed a Call object and just want
to query it?
-Dug
Davanum Srinivas <[EMAIL PROTECTED]> on 01/15/2003 03:25:58 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:Re: Call Parameter detail
le connections.
So for becoming a committer I believe this will happen once you've offered
up enough patches.
-Dug
Chris Knight <[EMAIL PROTECTED]> on 01/07/2003 01:25:23 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:Re: [Bug 15741] - TCP Monitor doe
Huge +1 - that's what I do too.
-Dug
Tom Jordahl <[EMAIL PROTECTED]> on 01/06/2003 05:32:48 PM
Please respond to [EMAIL PROTECTED]
To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject:RE: DO NOT REPLY [Bug 15741] - TCP Monitor does not handle
WebD AV methods in proxy m
[EMAIL PROTECTED]
cc:
Subject: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 PROT
roblem you've
described isn't. IMO.
-Dug
"Norman, Eric" <[EMAIL PROTECTED]> on 12/11/2002 01:08:45 PM
To:Doug Davis/Raleigh/IBM@IBMUS
cc:
Subject:RE: DO NOT REPLY [Bug 15284] New: - Proposed modification to
Oper ationDesc
The classes we are exposing as web
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
ssary jars in the war).
Thanks,
dims
--- Doug Davis <[EMAIL PROTECTED]> wrote:
>
> Dims,
> Why not just create a war file instead? Wouldn't that be easier for
> people to use?
> -Dug
>
>
> [EMAIL PROTECTED] on 12/06/2002 08:38:46 AM
>
> To:Doug Davis
Dims,
Why not just create a war file instead? Wouldn't that be easier for
people to use?
-Dug
[EMAIL PROTECTED] on 12/06/2002 08:38:46 AM
To: Doug Davis/Raleigh/IBM@IBMUS
cc:
Subject:DO NOT REPLY [Bug 15073] - No war file in install
DO NOT REPLY TO THIS EMAIL, BUT P
Oh thank god someone else _finally_ thinks this is odd!
:-)
-Dug
Glen Daniels <[EMAIL PROTECTED]> on 12/03/2002 05:02:06 PM
Please respond to [EMAIL PROTECTED]
To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject:RE: annoying hypen in AdminClient list
That begs the question.
Re: WSIF - Is it dead?
Actually that's what I started off with, till I realised it's limitations.
I wouldn't mind seeing some of the WSIF stuff integrated into the axis
code base
WH
Doug Davis wrote:
>
>
>
>
>WH wrote:
>
>
>>The current axis implementat
WH wrote:
> The current axis implementation is limited to working with hard coded
> web services at the source code level (unless you do some
> awesome code gymnastics), wsif provides a way to generically invoke web
> services at runtime.
You obviously haven't used the DII interfaces in Axi
02:01:19 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:Re: www.xmltoday.com
Hi Dug,
Tony has a stock quote service running at XMethods. Try this out -
http://services.xmethods.net/axis/getQuote?s=IBM
Dave
Doug Davis wrote:
>
> This is great! Is he going
#x27;ll let everyone know when he has
it ready.
Dave
David Chappell wrote:
>
> I asked Tony and he is happy to host it on XMethods. What exactly is
> "it"? Does anyone know the details of what that service does to get the
> quote information?
> Dave
>
> Doug Davis wrote
again. The JMS sample uses StockQuote also. We (Sonic) have an
external server that we use for demos and such that we could host this
on, if you like. Also I can speak to Tony Hong and ask him if he would
like to host it at XMethods. I'm sure he would be happy to.
Dave
Doug Davis wrote:
This is serious. :-)
www.xmltoday.com is apparently gone. I haven't been able to hit it for
days.
This of course means that the "Hello World" of Web Services won't work,
and more importantly the "stock" sample is broken unless you use XXX.
Anyone know of another site we can point to?
-Dug
Make sure you enable the SOAPMonitor handlers in the global chains in the
server-config.wsdd.
-Dug
"Raju Gottumukkala" <[EMAIL PROTECTED]> on 10/26/2002 02:57:12 AM
Please respond to [EMAIL PROTECTED]
To:<[EMAIL PROTECTED]>
cc:
Subject:SOAPMonitor doesnt display SOAP messages
I h
Do not be terrified, do not be discouraged, for the Lord your
God will be with you whereever you go.- Joshua 1:9
Doug Davis/Raleigh/IBM@IBMUS wrote on 10/25/2002 08:51:03 AM:
> Again - AxisEngine will be called by Axis users ("users" in the broader
> sense of the term meaning
ed, do not be discouraged, for the Lord your
God will be with you whereever you go.- Joshua 1:9
Doug Davis/Raleigh/IBM@IBMUS
10/25/2002 05:23 AM
Please respond to axis-dev
To
[EMAIL PROTECTED]
cc
bcc
Subject
Re: [IMPORTANT!] Proposed Axis Async Development Plan
In some of you
In some of your notes you've stated that the new messaging pattern you want
to do is strictly internal and yet this note would seem to imply otherwise.
Now that 1.0 has shipped we all know that we must be very careful with what
APIs we change but that isn't limited to just the client-side, tha
Personally, I'd like there to be just one type of message logged by Axis
- serious, earth shattering, system errors. Basically things that an Admin
guy would need to know about. Those should be placed in whatever logging
mechanism has been defined (default to axis.log or something like tha
Not sure what that means but if it means changing the default logging
level, I doubt that is the right solution since that will inevitably hide
current (expected) output.
-Dug
Richard Sitze/Austin/IBM@IBMUS on 10/22/2002 07:11:26 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECT
Glen,
Sorry about the delay - tested it and everything seems to work well.
thanks!
-Dug
Glen Daniels <[EMAIL PROTECTED]> on 10/16/2002 01:15:55 PM
Please respond to [EMAIL PROTECTED]
To:"Axis-Dev (E-mail)" <[EMAIL PROTECTED]>
cc:
Subject:Attn Doug : check out latest commit
Dou
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
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
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
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
Make sure if you remove one of 'em that you deprecate it since we can't
actually remove it right away.
-Dug
Glen,
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 in
Richard (or perhaps its Dims),
Can I ask you to do me a favor and really dumb down this discussion for a
moment because I'm still not clear on the entire need for this
"architecture" - it feels like its a solution looking for a problem. Let's
start with a very basic question - looking at B
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
Richard,
I'm still confused by the direction you and Dims are going with all of
this - perhaps I just don't understand what's involved with j2ee but why do
we need to have Sun, IBM and JDK14 versions of these files? Continuing
down this path we'll be force to add code to Axis for each and
Dims,
If I understand what you've done here, you made it so that it will allow us
to fix the immediate problem because we use the IBM impl. But this means
that if someone else wants to use a non-IBM and non-SUN impl they would
need to do the same thing you did, right? I'm a bit confused. B
+1
-Dug
Sam Ruby <[EMAIL PROTECTED]> on 10/07/2002 08:33:07 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:[VOTE] axis 1.0 release
This should just be a formallity at this point.
We've been executing under the approved release plan that can be found
at:
Just as a sanity check - it might be nice to have people download, install
and test with this version just to make sure something that isn't part of
the normal tests isn't broken before people vote +1.
-Dug
Glen Daniels <[EMAIL PROTECTED]> on 10/07/2002 09:13:06 AM
Please respond to [EMAIL
Yup - we're using it for demos.
-Dug
Sam Ruby <[EMAIL PROTECTED]> on 10/03/2002 10:10:42 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:Re: cvs commit:
xml-axis/java/src/org/apache/axis/transport/http
SimpleAxisServer.java
Can you do me a f
I'd like to have this one merged into the 1.0 base because without this
change its a regression/change in behavior and the user has no way of
changing it back. This fix is very low risk since its pretty much just
added a getter/setter and restoring SimpleAxisServer to its Beta3 behavior.
My
09:18:11 PM
To:[EMAIL PROTECTED]
cc:Doug Davis/Raleigh/IBM@IBMUS
Subject:Re: TCPMon Audio Feedback Mod ("RPC-Synth") RFC
OK, I've turned my audio feedback mods into a plugin for TCPMon, and in the
process have blessed TCPMon with plugin support! I was very careful
Glyn wrote:
> Doug: is that the last of the current defects you would like to include?
Don't know - we're still in the process of upgrading (but it is winding
down).
-Dug
"Glyn Normington" <[EMAIL PROTECTED]> on 10/02/2002 04:12:18 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROT
I'd like to have the fix for bug 13167 merged into 1.0 - w/o this people
who use Data will *not* be able to use the BeanSerializer anymore - which
is a pretty serious regression.
My vote: +1
-Dug
I'd like to see this fix go into the v1.0 branch, w/o clients need
servlet.jar which is (IMO) very bad.
My +1.
-Dug
+1
-Dug
Rick Rineholt/Raleigh/IBM@IBMUS on 10/01/2002 11:12:48 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:VOTE: submission to 1.0 branch: cvs commit:
xml-axis/java/src/org/apache/axis/encoding/ser ArraySerializer.java
This seems to be a fairly
Dims/Richard,
I messed up in my previous build of axis, this time and I tried to grab
the latest EngineConfigFactoryFinder and build it on top of our copy of
axis1.0 it doesn't compile. It appears it needs some Discovery constants
which isn't in 1.0 - I need a 1.0 solution for this. Or am
Dims/Richard,
Which file(s) do I need to pick up? I grabbed
EngineConfigurationFactoryFinder but it still fails.
-Dug
[EMAIL PROTECTED] on 09/30/2002 02:40:11 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:DO NOT REPLY [Bug 13149] - Client requires
in Axis anywhere, or even
on
Google. What is it, and where can I get it one of them thar thangs? I was
only using TCPMon because that's all I was aware of.
--
Dan Kamins
Original Message Follows
From: Doug Davis <[EMAIL PROTECTED]>
Subject: Re: TCPMon Audio Feedbac
o external (non Java core) dependencies. Is this
agreed upon as a good structure? I didn't want to break this in adding my
functionality (hence my inclusion into tcpmon's core), but perhaps now
might
be the time to open it up a bit, at least plugin-wise?
--
Dan Kamins
[EMAIL PROTEC
One of the things I like about TCPMon is all of the things it doesn't
try to be. To me its just a simple tool for watching TCP/IP traffic.
It doesn't even know anything about SOAP.
I can't say whether the audio feedback would be a nice feature
or not - I'm sure it will vary depending on who y
+1 to this and the change in the test that went along with it.
-Dug
Rick Rineholt/Raleigh/IBM@IBMUS on 09/26/2002 05:05:12 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:SUBMIT REQUEST FOR INCLUSION TO R 1.0: cvs commit:
xml-axis/java/src/org/apache
It seems to me that you'll still need to call the handler with the
message since the determination might need the message.
So, doing:
loop over chain
call each handler to see if it wants to be invoked
loop over chain again
call each handler that wants to be called
doesn't seem
Actually I think it matches the RPC style very nicely. In RPC if you
specify "*" you'll get all public methods. In MSG is you specify "*"
you'll get all public methods that *can* be MSG services. RPC allows more
because it doesn't have any restrictions on the signatures - MSG isn't have
th
We use the method(Doc) interface as well but switching it to
method(Element[]) isn't a huge hit - just an annoyance. ;-)
I wish more people would speak-up like you did - without feedback
like this its hard for the Axis developers to know which interfaces
are being used. While its easier fo
We use the method(Doc) interface as well but switching it to
method(Element[]) isn't a huge hit - just an annoyance. ;-)
I wish more people would speak-up like you did - without feedback
like this its hard for the Axis developers to know which interfaces
are being used. While its easier fo
Just to be clear, if the Body _does_ have a namespace but the WSDD does
_not_ have the element will it work (like it used to)? If so,
then I think I'm ok with this. I don't think its possible to generate a
Body w/o a namespace right now. I think when I tried Axis complained.
-Dug
Glen D
:-) Of course not - the change that's at issue should not have been made
in the first place (w/o consulting the group at large) so this is just
fixing it (IMO).
-Dug
Tom Jordahl <[EMAIL PROTECTED]> on 09/23/2002 12:37:52 PM
Please respond to [EMAIL PROTECTED]
To:"'[EMAIL PROTECTED]'"
to [EMAIL PROTECTED]
>
> To:"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> cc:
> Subject:RE: Only one operation if Msg style?
>
>
>
>
> It was just changed to make the ServiceDesc-based introspection code
easier
> to deal with, and
ople.
I'm fine with a QName->operation map, and it would be nice if we could
embed or import schemas into the WSDD for the various operations, too, so
we could generate useful WSDL
--Glen
> -Original Message-
> From: Doug Davis [mailto:[EMAIL PROTECTED]]
> Sent: Monda
I'm wondering though why we changed it. In the old version of the code if
someone entered just a single method name in the WSDD/allowedMethods field
then they got what your suggesting (current behavior). If they entered in
multiple names then they get what Rick is looking for. It seems to
Given a.jws:
--
public class a {
public int i = 5 ;
public void setI(int j) { i = j ;}
public int getI() { return i ; }
public a getQuote(String symbol) throws Exception {
return new a();
}
}
-
When I run: java samples.stock.GetQuote -s/axis/a.jws IBM
I see:
htt
I don't mean this as a comment on this commit (or on Rich of course) but
I'm
very curious...the async support was -1'd because people didn't want
such any new APIs so late in the 1.0 cycle and yet we're allowing redesigns
of the build/test structure, the message structure... (any others?)
Dims - that fixed it - thanks!!
-Dug
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: Doug Davis/Raleigh/IBM@IBMUS
Subject: Re: cvs commit: xml-axis/java/src/org/apache/axis/client Call.java
Dug,
This should fix the problem that you had this morning
Thanks - I'll give it a shot.
-Dug
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: Doug Davis/Raleigh/IBM@IBMUS
Subject: Re: cvs commit: xml-axis/java/src/org/apache/axis/client Call.java
Dug,
This should fix the problem that you had this morning.
Thanks,
dims
--- [
Done - give it a shot.
-Dug
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: cvs commit: xml-axis/java/src/org/apache/axis/utils tcpmon.ja va
Hey Dug,
While you are working on tcpmon, could you put back in the changes I made (and you backed
can call non-xml systems) and it isnt really a sub-project
of Axis as it is today. In a way I'd rather see a number of web services
components that work together, but on the other hand I'd also like to get
the CVS tree set up this month :-)
Paul
- Original Message -
From: "Do
If the package name is org.apache.wsif (not org.apache.axis.wsif) why would
the tree be named xml-axis-wsif instead of just xml-wsif?
-Dug
"Paul Fremantle" <[EMAIL PROTECTED]> on 05/15/2002 10:30:04 AM
Please respond to [EMAIL PROTECTED]
To:<[EMAIL PROTECTED]>
cc:
Subject:WSIF proposal
Contact the cvs admin - its a lower-vs-upper case naming problem. The file
should just be removed from the cvs tree.
-Dug
Sam Ruby/Raleigh/IBM@IBMUS on 05/02/2002 06:23:43 PM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:TestElement.java?
Is anybody else seeing
The SOAP processing rules in v1.2 are pretty clear that
all headers *and body* that are targeted for this Node
must be understood before *any* processing can begin
(we'll leave out the notion of 'undo' for the moment).
In a typical Axis deployment where something like the
URL mapper is used, A
#1 - Pull the band-aid off quickly!
:-)
Russell Butek/Austin/IBM@IBMUS on 03/27/2002 08:56:13 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:Changing JAX-RPC interfaces - philosophical question
There are some changes in the JAX-RPC spec that will affect users
Changing it to a ServiceDesc is fine as long as that new stuff has ALL of
the same data as the WSDL - including the ports, bindings, messaging... not
being used right now - because they might be used in a later call.
-Dug
Glen Daniels <[EMAIL PROTECTED]> on 03/26/2002 11:59:58 AM
Please respond
Like I said in my commit - there are plenty of other tweaks that can be
made to this and adding something to fix the problem you're talking
about would be one of them. More immediate, yes, if a person's WSDL
changes that much then they should not use the caching - but in a real
world scenario it
[EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:Re: client.Service getCall()
Dug,
I think i mentioned it. I want WSDL2Java to generate code and i want to use
JUST the generated
code!!!
Thanks,
dims
--- Doug Davis <[EMAIL PROTECTED]> wrote:
> I'm confused - if yo
I'm confused - if you need access to the response XML, why not just ask the
Call object (or its message context) for the response message. Why does
the Service object need to be involved at all?
-Dug
Davanum Srinivas <[EMAIL PROTECTED]> on 03/26/2002 07:36:06 AM
Please respond to [EMAIL PROTECT
Just tested it and I believe that you are correct - which is a shame I
believe it used to work.
-Dug
"Mark Volkmann" <[EMAIL PROTECTED]> on 03/23/2002 04:18:43 PM
Please respond to [EMAIL PROTECTED]
To:<[EMAIL PROTECTED]>
cc:Doug Davis/Raleigh/IBM@IBMUS
Subjec
; syntax, but it didn't quite seem worth it for this.
--Glen
> -Original Message-
> From: Doug Davis [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 11:17 AM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: xml-axis/java/src/org/apache/axis
> Version
Glen - if you use the Options class it will default the to the proper URL.
Plus then changing it will match the other samples' cmd line options.
-Dug
[EMAIL PROTECTED] on 03/20/2002 11:14:30 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:cvs commit: xml-axis/ja
Does anyone know why commons-logging.jar includes source code?
-Dug
I have a one-liner that I'd like to see fixed for the new beta.
For some reason I'm only running into this problem on
tomcat 4.0.3.
Anyway, in HTTPSender I like to change line 464:
464c464
< } else if (contentType!=null && !contentType.equals
("text/html") &
&
---
> } else
When a group wants to tell their customers that they're shipping with a
"fixed" level of Axis and that "fixed" level is changing as much as the
nightly build then its no longer "fixed". Any release whether its an
alpha, beta or any other kind should have a period in which people bang
away at it a
Make sure the jws file is in a dir tree that matches your package name.
-Dug
"Chris Haddad" <[EMAIL PROTECTED]> on 03/15/2002 11:14:05 AM
Please respond to [EMAIL PROTECTED]
To:<[EMAIL PROTECTED]>
cc:
Subject:JWS and package name spaces
Axis-dev ?
I am attempting to deploy a cl
You betcha!!
-Dug
Russell Butek/Austin/IBM@IBMUS on 03/14/2002 10:09:33 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:cvs commit: xml-axis/java/src/org/apache/axis/encoding/ser
JAFDataHandlerDeserializerFactory.java
Does this mean Doug's issue #1 is
the current beta effort)? Should we have an
axis-tools.jar?
***
Richard A. Sitze[EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
Doug
Davis/Raleigh/IB To:
[EM
Richard,
As Glen said there are plenty of places (like internal to axis) where
logging makes the most sense. But I would claim that in things like
the samples and AdminClient when we're in the "main" method people
are 99% of the time going to be running it from the command line.
So, running som
I'd like to raise this as an issue - not sure whether or not its worth
stopping the beta or not (probably not) but I do think that if this
is not fixed a lot of newbies will be very very confused.
Right now we seem to log almost everything. This change is
an example of how something that should
One thing you might want to consider is combining any such helper
class with a BeanInfo class that users might have already created
for their beans. Having 2 classes that contain metadata about a
bean isn't as clean as 1.
-Dug
R J Scheuerle Jr/Austin/IBM@IBMUS on 03/11/2002 05:14:50 PM
Please r
run your stuff through tcpmon - whenever I've seen the client complain
about a bad namespace more often than not its because the server is
returning an error and the Axis client tries to parse it as xml. tcpmon
will show you the error the server is returning and then you'll know what's
wrong.
-Du
Don't have time to look into this now but thought I'd
pass along what I have... given:
bug.java:
-
import org.apache.axis.client.* ;
import java.util.* ;
import java.net.* ;
public class bug {
static public void main(String[] args) throws Exc
86 matches
Mail list logo
