Hi All
i have an error when running axis client
org.apache.axis2.AxisFault
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:123)
at
Hi All
i have an error when running axis client
org.apache.axis2.AxisFault
at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
at
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:123)
at
Greetings all,
I've got some code generated via wsdl2java, but modified,
subclassed, monkeyed with, etc. I'm trying to debug a problem where it
*looks* like the returntype and returnclass are set correctly, but
Axis is constructing the soap request envelope with a different return
type.
The reply is generated by the program using jaxb and no namespace.
After installing 1.4 the client receives tags with namespaces
eg
Reply is changed to ns1:Reply? .
is there a way of turning this off
thanks in advance
sl
Anyone??Would appreciate valuable suggestions..
On Sat, Jan 23, 2010 at 12:35 PM, Nirav Shah snirav.s...@gmail.com wrote:
Hi,
I have been reading some different sides of this defect. Based on the
Release Email sent out, it said the Connections are released automatically
and should not
Hi All
I am still running into problems with this. I previously moved all the jars I
needed into the WEB-INF/lib directory and was able to continue working. But as
I add more services (more .aar files) I am now running into strange
unpredictable differences that I do not understand.
For
Try adding the following parameter on the service:
parameter name=ServiceTCCL locked=falsecomposite/parameter
Andreas
On Mon, Jan 25, 2010 at 18:22, Charles Galpin cgal...@lhsw.com wrote:
Hi All
I am still running into problems with this. I previously moved all the jars
I needed into the
Thanks Andreas
I added this to both services being loaded, rebuilt and ran, but no change.
The composite class loader was one of the options described in Amil's blog and
as I understand it, it is supposed to use both the TCCL and the service class
loader. But I guess I still don't understand
Charles,
According to the stack trace you posted, the error occurs inside a
thread that is neither managed by the servlet container, nor by Axis2:
13:38:58 DEBUG- Stack trace: org.omg.CORBA.INITIALIZE: can't
instantiate default ORB implementation org.jacorb.orb.ORB vmcid: 0x0
minor code: 0
It's just a thread spawned from the lifecycle init method using new Thread()…
The general idea is we have an existing code base that used to be launched as
commandline apps. I am now launching them in a thread from my web services, and
web enabling them. Admittedly there were not designed or
Charles,
That might actually explain the issue. Here is some additional info:
* ORB.init looks up classes from the thread context class loader (I
checked that in the JRE sources).
* ServiceTCCL=composite means that Axis2 sets the TCCL to the service
class loader when entering a service method
Hi Andreas
I tried setting the TCCL to both the class loader of the service context as
well as the service group context before starting the threaD, but still no
change. I guess this leaves me with a couple of questions.
1. Do subsequent threads spawned inherit the same TCCL? I'm pretty sure
On Mon, Jan 25, 2010 at 22:15, Charles Galpin cgal...@lhsw.com wrote:
Hi Andreas
I tried setting the TCCL to both the class loader of the service context as
well as the service group context before starting the threaD, but still no
change. I guess this leaves me with a couple of questions.
13 matches
Mail list logo