Hi,
just wanted you to know that I have managed to solve the problem now.
It was all about other files, which were on our classpath and which
were not supposed to be there (our product jars). That caused
classloader to load classes where they were not supposed to be loaded.
The problem doesn't
Radim Kolarik wrote:
Hi,
just wanted you to know that I have managed to solve the problem now.
It was all about other files, which were on our classpath and which
were not supposed to be there (our product jars). That caused
classloader to load classes where they were not supposed to be loaded.
Hi Sebastien,
You are right, I mean the change classloader properties of your Webapp
to parent-last / single update.
I am calling the AdminService.getAttribute() from the web app, server
itself starts without problems.
Here is the complete stack trace:
java.lang.ClassCastException:
Radim Kolarik wrote:
Hi,
We are experiencing a problem on Websphere 6.1.0.11 with Tuscany 1.0.
When we set all classloader properties, as mentioned before,
I'm assuming that you mean: change classloader properties of your Webapp
to parent-last / single, correct?
we are
getting the
Hi Sebastien,
thanks for your help! It was the the custom Web container property as
described in the WebSphere fixpack.
I can also confirm now that it works with 6.1.0.11 fixpack as well, if
the property is set.
In the log file, however, we are getting something I am not sure we
were getting
On 9/20/07, Radim Kolarik [EMAIL PROTECTED] wrote:
Hi Sebastien,
thanks for your help! It was the the custom Web container property as
described in the WebSphere fixpack.
I can also confirm now that it works with 6.1.0.11 fixpack as well, if
the property is set.
In the log file, however,
Hi Sebastien,
I can confirm that you are right, that was the problem. I would swear
I saw many examples that had the implementation element as last one in
the composite file ;-).
Thanks again,
Radim
On 9/20/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Laws wrote:
On 9/20/07,
According to the SCDL schema, the implementation.* element must come
first in a service or reference. This is what the
element ref=sca:implementation minOccurs=0 maxOccurs=1 /
line in the schema is saying.
The message is telling you that the SCDL has elements appearing in a
different order.
Radim Kolarik wrote:
Hi Sebastien,
I can confirm that you are right, that was the problem. I would swear
I saw many examples that had the implementation element as last one in
the composite file ;-).
Thanks again,
Radim
Yeah I had to fix them all for the 1.0 release :) I guess it shows
Hi Sebastien,
I am having problems making the app work on Websphere 6.1.0.11. Did
you try that particular fixpack, or did you try 6.1.0.9?
In the 6.1.0.11 WAS the service is not being picked up at all, nothing
at all is logged to the log file if I try to access the service URL. I
tried it with
Hi Simon,
unfortunatelly I am seeing the same problem on WAS 6.1.0.9.
Sebastien, do you still have the WAS environment? Could you try to
deploy RC3 based example web service on it?
Thanks a lot,
Radim
On 9/19/07, Radim Kolarik [EMAIL PROTECTED] wrote:
Hi Simon,
thanks for your reply. We
Radim Kolarik wrote:
Hi Simon,
unfortunatelly I am seeing the same problem on WAS 6.1.0.9.
Sebastien, do you still have the WAS environment? Could you try to
deploy RC3 based example web service on it?
Thanks a lot,
Radim
It works for me.
I need more precise information to be able to
Hi Yang,
unfortunatelly, that didn't help either.
Thanks,
Radim
On 9/14/07, Yang Lei [EMAIL PROTECTED] wrote:
Try remove the contextRoot and see if you can get the values.
Yang
On 9/13/07, Radim Kolarik [EMAIL PROTECTED] wrote:
Hi Simon,
please ignore the --, it was just added to
Jean-Sebastien Delfino wrote:
Radim Kolarik wrote:
Hi Sebastian,
I received the latest code from ant and I can confirm that the service
generates the WSDL file now. The binding.ws/ element doesn't even
need uri attribute, it works without any attributes!
However, there is still some problem,
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
Radim Kolarik wrote:
Hi Sebastian,
I received the latest code from ant and I can confirm that the service
generates the WSDL file now. The binding.ws/ element doesn't even
need uri attribute, it works
Hi Yang,
thank you for your suggestions.
I am sure I use the correct root context, because I can access a JSP
within the application successfully. It seems to me that the axis
service is not being recognized at
http://localhost:9201/contextRoot/componentName/serviceName.
It is very strange,
See inline.
Simon
Radim Kolarik wrote:
Oh, sorry about the stack trace, it only occurs with older version of
Tuscany when TuscanyServlet is used instead of filters.
I am now using Tuscany snapshot from the Maven repository dated 4th
September, with filters set up in web.xml, but still no
Hi Simon and Ant,
We have tried to put a port to ws.binding to reference an existing
WSDL, which had the correct port in, but without success. Also, we did
another test and tried to specify the uri attribute to binding.ws, but
it didn't work either.
I will now try to reconfigure websphere to
Hi Ant,
see my answers inline.
Thanks,
Radim
On 9/13/07, ant elder [EMAIL PROTECTED] wrote:
Hard to say, could you answer these questions:
Do you see anything in the log or console saying addServletMapping:
/ExampleComponent/ExampleService to show the web service
is getting registered?
Hi Simon,
please ignore the --, it was just added to thread by accident. The
file I work with is a valid XML file.
The URI even gets picked up from the .composite file during
inicialization, I get the addServletMapping:
/contextroot/ExampleComponent/ExampleService in the log file.
But I do not
20 matches
Mail list logo
