My strange service with an error

[Kay*]

Hello,
first of all, I apologize for my bad English...
I have a problem but I don't know how I can resolve it.
This is a service example...

public String print(Object obj){
return (obj.getClass().getName()) ; //or something else with obj
}

....and this is respective part of services.xml

<operation name="print">
<messageReceiver
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
Then I use the WSDL2Java tool generate the client side stubs to
interact with the service and I write a Client.java ; here I create
the request with an MyCard object ...
MyServiceStub.Print request = new MyServiceStub.Print();
MyCard obj= new MyCard(...)
request.setParam0( (Object) obj);
but when I compile, I have an error beacuse setParam0 wants an
OMElement object .....

So .... how can I resolve my problem?
Please, it's very important!!!!!


Thanks!!

Kay

 

[Lew]

Then I use the WSDL2Java tool generate the client side stubs to
interact with the service and I write a Client.java ; here I create
the request with an MyCard object ...
MyServiceStub.Print request = new MyServiceStub.Print();
MyCard obj= new MyCard(...)
request.setParam0( (Object) obj);
but when I compile, I have an error beacuse setParam0 wants an
OMElement object .....

Apparently the MyServiceStub.Print.setParam0() method signature does not take
a mere Object as a parameter, but some subclass of Object (OMElement). Is
MyCard a subclass of OMElement?

Why did you upcast obj to "Object"? It is basically never needed to upcast an
object.

- Lew

 

[Kay*]

Apparently the MyServiceStub.Print.setParam0() method signature does not take
a mere Object as a parameter, but some subclass of Object (OMElement). Is
MyCard a subclass of OMElement?

The real aim of my service is to save a file .class passed with
parameter, so I was trying to pass an object different from String,
Integer etc... but I don't know how I can do ......
MyCard is a simple class with 3 String variable and 3 get-method...and
it's only a test-class...!

Why did you upcast obj to "Object"? It is basically never needed to upcast an
object.

- Lew

I know it, but it was only a test....

 

[Lew]

You should copy and paste the error message exactly. Paraphrases hide too much
information, and manual copies risk typos.

The real aim of my service is to save a file .class passed with
parameter, so I was trying to pass an object different from String,
Integer etc... but I don't know how I can do ......
MyCard is a simple class with 3 String variable and 3 get-method...and
it's only a test-class...!

The reason I asked if MyCard is a subclass of OMElement is that that is the
hint to your answer.

In order to compile, method calls must have the right variable types in their
actual arguments. That means each variable type must be either the same as or
a subclass of the corresponding formal parameter type. Clearly, Object is not
a subclass of OMElement, so you got the compiler error.

If MyCard is not a subclass of OMElement, then it cannot be passed to the
setParam0( OMElement ) method. There will be no cast that can rescue it.

The Sun tutorial provides more detail:
<http://java.sun.com/docs/books/tutorial/java/javaOO/arguments.html>

You also might want to read the section
<http://java.sun.com/docs/books/tutorial/java/concepts/index.html>

Just now, reviewing these sections to make this post helped me get the
terminology correct.

For the absolute truth, the Java Language Specification (JLS) is the law:
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4>

I know it, but it was only a test....

A test of what?

It is unnecessary to upcast an object because the object's runtime type is
already of any supertype; the upcast is redundant.

All objects are of type Object trivially, by the fundamental structure of the
Java language.

(I've read a definition that a language that enforces a single Object root
type is "object-oriented", whereas a language like C++ that allows root types
other than Object is "object-supporting".)

- Lew

 

[Kay*]

You should copy and paste the error message exactly. Paraphrases hide too much
information, and manual copies risk typos.



The reason I asked if MyCard is a subclass of OMElement is that that is the
hint to your answer.

In order to compile, method calls must have the right variable types in their
actual arguments. That means each variable type must be either the same as or
a subclass of the corresponding formal parameter type. Clearly, Object is not
a subclass of OMElement, so you got the compiler error.

If MyCard is not a subclass of OMElement, then it cannot be passed to the
setParam0( OMElement ) method. There will be no cast that can rescue it.

The Sun tutorial provides more detail:
<http://java.sun.com/docs/books/tutorial/java/javaOO/arguments.html>

You also might want to read the section
<http://java.sun.com/docs/books/tutorial/java/concepts/index.html>

Just now, reviewing these sections to make this post helped me get the
terminology correct.

For the absolute truth, the Java Language Specification (JLS) is the law:
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4>


A test of what?

It is unnecessary to upcast an object because the object's runtime type is
already of any supertype; the upcast is redundant.

All objects are of type Object trivially, by the fundamental structure of the
Java language.

(I've read a definition that a language that enforces a single Object root
type is "object-oriented", whereas a language like C++ that allows root types
other than Object is "object-supporting".)

- Lew

Thank you for your accurate answer!
I know all that you said, but my question is different.
I know that , if setParam0 wants an OMElement, I can't pass a not-
OMElement object!
My question is if RPCMessageReceiver is wrong for my purpose (save
a .class) , or if I can pass only OMElement (and so make my MyCard as
a subclass of OMElement )...
Infact setParam0 is a method of MyServiceStub.Print, generated
automatically with WSDL2JAVA.sh and I don't know if
setParam0(OMElement ) is thus because of RPCMessageReceiver !

My aim is to receive a .class, create an object of that class and
executes its method...
What do I have to do to pass a class (different from String, Integer,
Float etc etc ) to my service ?

I hope to have explained my problem well!

Thank you very much for your time!!!

Kay*

 

[Kay*]

I was reading some articles on web and I found this interesting piece
in http://wso2.org/library/259 :

<<
Note: Parameters [in services.xml] are designed to store primitive
data types (String , int double etc...) data and OM elements, NOT any
type of objects, but it is not invalid to store any types of objects
inside a parameter. As best practice always store serializable objects
inside a parameter.
Now I ask you ... MyCard has to implement Serializable.... but what
else ? Infact I found also this example (http://www.jugsardegna.org/
vqwiki/jsp/Wiki?
action=action_view_attachment&attachment=ArticoloAxis2PerJUG.pdf)
(it's in Italian but I think that code is comprehensible) but this web
service is for Axis, and not Axis2 and I don't know how to do !

Then I have better extend MyCard to OMElement or implements
Serializable or what ?

Thank you for your time and attention!!!

Kay*

 

[Chris Uppal]

(I've read a definition that a language that enforces a single Object root
type is "object-oriented", whereas a language like C++ that allows root
types other than Object is "object-supporting".)

You do seem to have a talent for finding the most astounding drivel ;-) Where
did you find that particular crock of moonshine ?

-- chris

(P.S. I don't at all dispute that C++ is better described as "supporting OO"
than as being an OO language -- but that's nothing at all to do with its lack
of a single root class.)

 

[Lew]

You do seem to have a talent for finding the most astounding drivel ;-) Where
did you find that particular crock of moonshine ?

-- chris

(P.S. I don't at all dispute that C++ is better described as "supporting OO"
than as being an OO language -- but that's nothing at all to do with its lack
of a single root class.)

Well, I do seem to have a talent for drivel, both borrowed and original.

And I likely misremember the argument; it's been a few years and I do not
remember the source or all the details. It might have been C++'s support for
global things that contributed to the assessment, but as I recall the argument
suggested that an "object-oriented" language is all about objects, and
typically is single-rooted, whereas an "object-supporting" language lets you
create structures not in the "normal" object hierarchy.

I am glad for your feedback on this - it makes me think about both the point
of that distant article and how I go about regurgitating the related ideas.

- Lew