HI!
Maybe this is a bit pedantic, but wouldn't it be faster if SOAPPart.getAsString()
wouldn't deliver a pretty XML, but an unformatted one (no spaces)?
Regards,
Thomas
But the AG doesn't use the term targeted chain anywhere, either.
The term got lost from the old UG overview to the new AG. We have
to add it back to the AG.
Not so! The AG [1] has a description of Targeted Chains. Follow the
Handlers and Chains link from the table of contents and then scroll
Im now working with the beta rc and have ported my app from alpha3 without
too much difficulty.
However, since I am deploying to weblogic6.1, I encountered a slight problem
with configuration initialisation.
If I dont define the axis.attachments.Directory init param in web.xml for
the
Seems the axis is not supporting completely the sun rpc interface..
I am trying the soap using the sun rpc interface and using the axis
implementation??.
Some of the functions in the axis Call interface was not defined in the sun
rpc Call interface
and also the axis is not using the
gdaniels02/03/11 05:45:42
Modified:java/src/org/apache/axis/deployment/wsdd WSDDDocument.java
WSDDDeployment.java
Log:
Fix undeployment bug - remove namespace-service mappings when
undeploying a service.
Remove unused undeploy() method of
50 lines of build output follows.
[junit] property name=env.jakarta_avalon_ftpserver value=1/property
[junit] property name=DSTAMP value=20020311/property
[junit] property name=env.checkstyle value=1/property
[junit] property name=os.arch value=i386/property
Glen brought up a good point to me this morning. I'm going to code it up.
If anyone has serious doubts about it, please let me know ASAP.
Right now --skeletonDeploy requires --server-side. If you don't specify
--server-side with --skeletonDeploy, WSDL2Java fails. But Glen suggested
that
So it does! My apologies. (I THOUGHT I searched for targeted chain in
the document and didn't find it. Clearly operator error!)
Russell Butek
[EMAIL PROTECTED]
Glyn Normington/UK/IBM@IBMGB on 03/11/2002 03:17:26 AM
Please respond to [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
cc:
Subject:
rubys 02/03/11 07:38:24
Modified:java build.xml
Log:
Split the jaxrpc interfaces out into a separate jar
Revision ChangesPath
1.121 +7 -1 xml-axis/java/build.xml
Index: build.xml
===
OK, folks, what do y'all think? Since the session info ultimately resides
in HTTPTransport, even though there are multiple services/stubs/Call
objects, the cookie info is preserved. So if you turn on sessions, turn
them off, and turn them back on again, you're still in the original
session. Is
scheu 02/03/11 09:18:33
Modified:java/src/org/apache/axis/wsdl/toJava
JavaComplexTypeWriter.java
Log:
The generated code for the equals method should check for nulls.
Revision ChangesPath
1.19 +5 -2
You've lost me. The way it USED to work, you had 3 options (2 really the
same):
- --server-side: generate deploy.wsdd (refers to Skeleton), undeploy.wsdd,
Skeleton, Impl
- --server-side, --skeletonDeploy true: generate same as above
- --server-side, --skeletonDeploy false: generate
In most cases I believe people generating server-side implementation frameworks are
going to want the convenience of the generated deploy/undeploy files as well.
Therefore, I think --server-side should continue to default to emitting them. This is
great.
So now it seems like the only
+1 Sounds more flexible.
Han Ming
On Friday, March 8, 2002, at 02:26 , Thomas Börkel wrote:
HI!
I have made a few minor changes (only extract code from
processMessage() to seperate methods) in RPCProvider.java (please find
attached) that allow us much more easily to do our own
Sounds to me like your suggestion is something in addition to the
--skeletonDeploy flag, right? Have we had anyone complain about generating
the wsdd files? I vote not to add anything more before beta.
Russell Butek
[EMAIL PROTECTED]
Glen Daniels [EMAIL PROTECTED] on 03/11/2002 12:35:00 PM
It's not a new thing, it's a replacement of the --skeletonDeploy flag with something
simpler.
--skeletonDeploy has a true/false option to it, and whenever you specify it either
way you're now also getting the --server-side option implied, which is, IMHO,
confusing.
We're good in the common
dims02/03/11 11:41:25
Modified:java/src/org/apache/axis/providers/java RPCProvider.java
Log:
Updated version of fix for Proposed change for RPCProvider.java for Beta 1 from
Thomas [EMAIL PROTECTED].
- added MessageContext parameter to getMethod()
- added method
That's not simpler, it's different. From the user's guide:
-S, --skeletonDeploy argument
Deploy either the skeleton (true) or the implementation (false) in
deploy.wsdd. In other words, for true the service clause in the
deploy.wsdd
file will look something like:
service
rsitze 02/03/11 14:07:18
Modified:java/samples/addr readme
Log:
reformatted
Revision ChangesPath
1.7 +15 -6 xml-axis/java/samples/addr/readme
Index: readme
===
RCS file:
rsitze 02/03/11 14:15:55
Modified:java/src/org/apache/axis/server AxisServer.java
Log:
minor corrects to comments/trace
Revision ChangesPath
1.64 +5 -3 xml-axis/java/src/org/apache/axis/server/AxisServer.java
Index: AxisServer.java
How about we just prevent two different services with the same name from getting
deployed?
Humm.. But how can we detect this error case as different from a re-deploy of the same
service.
--
Tom Jordahl
Macromedia
-Original Message-
From: Russell Butek [mailto:[EMAIL PROTECTED]]
Just FYI, the TypeDesc stuff also allows us to arbitrarily map Java fields to full XML
QNames and vice-versa, which is a feature that doc/lit services often require.
I think the general idea of being able to tease the TypeDesc out from the bean class
is a great one, and that's precisely why
+1 to stepping back and designing (ie. cease code-checking on current
direction)
It's critical that we isolate JAX-RPC implementation details (Meta-data)
from the classes exposed to the user. We need a design that reflects this
in place ASAP, and we need to be writing to the design to minimize
-1 on moving the meta data out of the bean class and in to some other place.
I find this mechanism simple and easy to understand and use (hey, what do you know, I
coded it). I do not think a helper class would be as straightforward, nor would it be
as easy for users to grasp quickly. I don't
Well, on the one hand I agree it should be possible to do this, but let me play
devil's advocate for a minute.
If we're generating a class from an XML template, the assumption is that we're going
to, at some point, be serializing/deserializing that class to/from XML. If that's the
case,
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
Russell Butek schrieb:
OK, folks, what do y'all think? Since the session info ultimately resides
in HTTPTransport, even though there are multiple services/stubs/Call
objects, the cookie info is preserved. So if you turn on sessions, turn
them off, and turn them back on again, you're still
I'm new to SOAP and Axis, and I'm trying to write a single server-side
SOAP application class with a single method which can be used to invoke
arbitrary methods on arbitrary EJBs. I've succeeded in coding the
application with reflection, and I can get a request up to the
application and have it
Tom Jordahl wrote:
How about we just prevent two different services with the same name from getting
deployed?
Humm.. But how can we detect this error case as different from a re-deploy of the
same service.
-1
The names we choose to key off of may not have any real meaning, and in
fact be
Glen,
I think we all feel that having the metadata to the runtime is a good idea
(and in some sense, required). I also agree that to make the metadata
available for an XML-aware piece is goodness (but I would add to that
statement an XML-aware piece of runtime code). I believe some of the
Whoa! A -1 on moving the meta data out of the bean class!?!?! I hate to
be nasty, but I'm moving closer and closer (not QUITE there, yet) to saying
-1 on keeping it IN! It puts non-bean stuff on beans (bad bad bad). It
locks out the possibility of using beans that come from somewhere else in
Hi Russell!
See the note I just sent to Greg. I do see the need for, and want to see, a good
out-of-band solution for this, but that doesn't mean the in-band one we have now is
bad or should go away.
I don't think there's a real impasse here, I suspect Tom was just having a bout of
Out of curiosity, was that CDATA problem I posted a couple of weeks ago
ever looked at?
Also, currently the ServletEngineConfigurationFactory only looks in
/WEB-INF for the server-config.wsdd file. This is cool if you only have
one instance of Axis deployed to a server. However, there may
Hi.
I try to run the attachment sample
"samples.attachments.EchoAttachment" with thebeta-rc1 of Axis. It always
fails with a server-side exception which indicates that there is a parameter
mismatch to call "EchoAttachmentService.echo(javax.activation.DataHandler)" with
a
34 matches
Mail list logo
