+1 for "service metadata" abstraction
It will also resolve this concern
R J Scheuerle Jr wrote:
>So everything is fine if all services send arrays over with type
>="soapenc:Array". But if a service
>sends over a more specific type="ns:ArrayOfFoo", then the client
Rich,
Me and Chris are on the same team :). I have once suggested to reconcile Emitter and
SOAP pipeline as far as handling default bean mappings
(http://marc.theaimsgroup.com/?l=axis-dev&m=101320802717644&w=2) for making it simple
to deploy a set of well defined java classes (those not result
William,
You just derive your class loader from URLClassLoader and then substiture it when
making calls to Axis engine and also derive your servlet do do the same for
doPost/doGet relying the requests to AxisServlet.
It works.
It is probably not a business of Axis to provide custom classloader
Title: Default type mapping (another attempt)
I'm trying it again.
The WSDL2Java and Java2WSDL take care of properly mapping http://my.app.corp.etc namespaces back to and from etc.corp.app.my packages (see code fragments below). SOAP processing pipeline does not. It always assumes the typema
e do it right, with GLUE
and WASP and other java toolkits which use this pattern.
--Glen
-Original Message-From: Sedukhin, Igor
[mailto:[EMAIL PROTECTED]]Sent: Friday, February 22, 2002 9:37
AMTo: '[EMAIL PROTECTED]'Subject: Default type
mapping (anot
ukhin .. ([EMAIL PROTECTED]) --
(631) 342-4325 .. 1 CA Plaza, Islandia,
NY 11788
-Original Message-From: Sedukhin, Igor
Sent: Friday, February 22, 2002 10:32 AMTo:
[EMAIL PROTECTED]Subject: RE: Default type mapping (another
attempt)
Glen, so then if we change it to , then d
prefix doesn't need to actually be registered
as a protocol), I could see that being OK, but I think it's simpler just
having "http://xml.apache.org/soap/java" be
the namespace (or whatever interoperable java: namespace mapping we settle on
with GLUE + WASP).
-
Title: Deprecation warnings
Has anyone seen these deprecation warnings... Any reason for these?
I'm doing some small changes to the AxisServlet. Can take care of these too...
xml-axis/java/src/org/apache/axis/transport/http/AxisServlet.java [83] warning: javax.servlet.http.HttpUtils in javax
Dims,
Did it work before with the same WSDLs? These services use document/literal
encoding. I guess that is why it may not work good. It seems like some of
the recent changes were to support document/literal enc by the client.
-- Igor Sedukhin .. ([EMAIL PROTECTED])
-- (631) 342-4325 .. 1 CA Pla
Title: Strange warning in introp with .NET
I was getting this warning with .NET client builder trying to bind to a service exposed by Axis form a plain Java
Schema validation warning: Type 'http://www.w3.org/2001/XMLSchema:ArrayOfString' is not declared.
It didn't happen before, as far as
Glyn,
I would add
4. There should be only one Engine instance per client/server usage (i.e. NOT one
Engine instance per one 'snapshot'). There could be multiple 'snapshots' known to the
Engine though. One MessageContext would always refer to one 'snapshot'.
I would question 3. The Engine is t
+1
-- Igor Sedukhin .. ([EMAIL PROTECTED])
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
-Original Message-
From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 13, 2002 8:28 AM
To: Axis Development List
Subject: VOTE: committer status for C++ client stack
Ok, I've traced it back to Glyn's message a week ago. :)
-- Igor Sedukhin .. ([EMAIL PROTECTED])
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
-Original Message-----
From: Sedukhin, Igor
Sent: Thursday, January 31, 2002 5:36 PM
To: '[EMAIL PROTECTED]'
Glyn,
How exactly is notification in 5 should be done? Should it be done at all?
Engine builds the pipeline dynamically when request comes. It does not seem to cache
handlers in any way (unless I missed something). That is it'll ask EngineCongiguration
everytime, and so, if the information was
Guys, I've tried to hit the nightly build after two weeks and found some dreastic
changes in the deployment architecture. I've been using previous deployment facilities
to dynamically configure the axis pipeline at runtime.
It seems like we're getting away from DeploymentRegistry abstraction, a
What if I already have a WSDL as an XML document or in a file. Why would I want to
javax.wsdl it?
Current interfaces are flexible enough to accommodate all ways of generating or
receiving WSDL.
I'd suggest that current logic stays, but in addition it can take the new definition
and so the endp
Title: Axis and .NET inetrop failure due to WSDL4J!!
I was trying to consume some of the WSs exposed by latest Axis builds with an RTM VS.NET and wasn't able to do it because of:
http://www.w3.org/2001/06/soap-encoding
and
SOAP-ENC:string
These are the things generated by WSDL4J for the sake
2Java tests are testing SOAP 1.2
types (soap-enc:xxx) because mappings for them are defined in JAX-RPC, but I think
AXIS still sends SOAP 1.1 over the wire.
Perhaps we missed something. Could you tell us exactly what you couldn't do?
Russell Butek
[EMAIL PROTECTED]
"Sedukhin, Igor"
nt thinking. My
comment #5 below simply reflected that Glen and I had discussed this issue, not that
we had concluded what to do about it!
Glyn
Glyn,
That is right engine does not call getConfig, although it does config.getHandler() for
instance, so that can be easily replaced with getConfig(versionStamp).getHandler().
I was thinking to establish an EngineConfigurationProvider interface that would define
getConfig(), getConfig(version
Glyn,
Will EngineConfigurationFactory be a parameter to AxisEngine constructor? I'd say it
should (I'm just asking :), instead of the EngineConfiguration...
For example
Server application:
new AxisServer(MyEngineConfigFactory(...))
AxisEngine constructor:
AxisEngine(EngineConfigurationFactory
Glyn,
The interfaces will be defined in such a way that versioning is always assumed, it is
just that our default implementation of a config provider will basically ignore
versioning. In other words the config provider does not want to implement versioning
the default implementation (which sho
Glyn,
That's right we can discuss it after you make changes. Basically if we want to support
dynamic reconfig with versioning, passing factory as a parameter to the Engine
constructor may be a good architectural simplification. Yes, we'll have one config
factory instance per engine instance, b
Glyn,
>Handlers (including Chains) would then have to cope with being instantiated
>or modified during the processing of a request. For example, a Handler would
>have to cope with being driven for onFault() when it has not been driven for
>the corresponding invoke().
Handlers (et al) deal wit
Resending msg again. Didn't see it on the list for some reason...
-Original Message-
From: Sedukhin, Igor
Sent: Wednesday, February 06, 2002 10:23 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Subsystem responsibilities: WSDD
Glyn,
>Handlers (including Chains) would then
lly what
we're trying to achieve. In reality it will never be cloned, unless, of course it is
some very simplistic impl that does versioning by replicating the whole config.
-----Original Message-
From: Sedukhin, Igor
Sent: Wednesday, February 06, 2002 1:37 PM
To: '[EMAIL
Title: Message
Dave,
Are
you sure the class it is trying to load (for a _RecordType type specified in
WSDL) is available for a deployed Axis web app? That is, is it in
WEB-INF/classes or in WEB-INF/lib?
Axis
is inheriting the servlet classloader provided by the container. That's the guy
x27;Subject: RE:
classloader problems
Yes, the class is available in the WEB-INF/classes directory,
not in the system classpath.
Dave
-Original Message- From:
Sedukhin, Igor [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 7:00 AM To: [EMAIL PROTECTED] Subject: RE:
Glyn,
Great. I'll start looking deeper into this next week. It should not be very
difficult to implement.
I'll writeup something for the arch. too.
-Original Message-
From: Glyn Normington [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 11:20 AM
To: Sedukhi
May I ask why was it a problem? I just want to know... Thanks.
-Original Message-
From: Glen Daniels [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 07, 2002 3:18 PM
To: 'Axis-Dev (E-mail)'
Subject: Quick question!!
Is it OK to always stop emitting WSDL for Java classes that are i
Title: Default bean mappings
This bugs me for a while already. May be there is a reason it is happening this way, but please refresh me on it.
Here is what:
By default Emitter generates type namespaces and type declarations like this:
http://model.address.myapp" ...>
http://model.address.m
I think caching should be selectable by a parameter on the service.
I can have a dynamic classloader, similar to catalina's WebAppClassLoader that would
refresh JARs when they are updated on the file system. It may be very difficult for
Axis, or for anyone really, to check all type dependencies
Glen,
I also didn't think that AxisClassLodaer was doing what it should, but rather, I was
thinking to extend it a bit. I don't care about the class cache, but I have my own
classloader that does what I need. Currently I had to go crazy with Axis and do things
like this:
ClassLoader oldL
types, which indicates a "suggested" Java class to use. This would allow
our stubgen to be smart about this as well.
Neither of these options rely on having to deconstruct a particular
namespace generation scheme, which I think would be VERY
brittle.
Cheers,
--Glen
ognize array
qnames.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
"Sedukhin, Igor"
alizer instead of the bean deserializer.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
"Sedukhin, Igor"
"ns:ArrayOfFoo", then the client runtime needs to know that they are
arrays and not beans.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
"Sedukhin, Igor"
cc:
Glyn, Chen,
I think it's all good and we don't have to apply the change. Here is why and how to
take care of the original problem correctly.
You're deploying a transport like
Well, you are actually getting a transport with parameters, just that the pivot is not
getting them, because it is a s
, NY 11788
-Original Message-
From: CHEN,SHIH-CHANG (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 15, 2002 10:50 AM
To: Sedukhin, Igor; [EMAIL PROTECTED]
Cc: CHEN,SHIH-CHANG (HP-NewJersey,ex2)
Subject: RE: Modified WSDDTargetedChain.java
Igor, Glyn,
Thanks, it
Glyn,
What do you think is missing?
Actually I also thoought so, but then I took a closer look and figured it's
all good...
-- Igor Sedukhin .. ([EMAIL PROTECTED])
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
-Original Message-
From: Glyn Normington [mailto:[EMAIL PROTECTED]]
40 matches
Mail list logo
