Hi, Eran

I am quite interested in your 2nd reason.

However, it seems that you can only avoid using java reflection during
operation routing. Before it starts to invoke the specific operation, it has
to deserialize the XML document into corresponding operation parameter
objetcs, which will use Java reflection(If you use any binding frameworks,
such as ADB, JAXB, etc.), and is more performance critical. Of course, if
you decide to write your own data binding with RawXMLMR, you can still avoid
this with a lot of painful work.

Am I right?


On 1/14/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Angel,

MessageReceiver, MR, does couple of thinks. First it manages the MEP
that is being used for the operation.

For example, if the operation you are invoking is an IN-OUT one, MR is
the one who invokes the OUT pipe, having invoked the service
implementation.
If you want to implement a custom MEP, then you need to write your own MR.

If you ask, why we need custom MRs, then the another reason is to avoid
the use of java reflection and to have a tight binding.

For example, if you expose a java class which has three methods, how
will a generic message receiver works? Obviously it has to use
reflection. By generating a custom message receiver, during the code
generation, we avoid using reflection.

Seems we need to write down this some where. Will do it, when I get some
time.

- - Chinthaka



Angel Todorov wrote:
> Hi ,
>
> Well i was thinking that , assuming the RPC Message Receiver is
> inadequate for more complex input and output datatypes , we are only
> left with the RAW XML Message receivers, which assume that one has a
> compiled java class with a method parameter signature accepting
> OMElement and returning an OM Element, and a method name which should
> be *the same* as the name of the operation name. (at least that can be
> seen from the RawXML MessageReceiver implementations in Axis2, more
> specifically in the findOperation impl).
>
> So maybe if I don't want to restrict my java impl classes to have the
> same method names as the operation names , I should write a custom
> Message Receiver.
>
> Can anyone clarify this point? Thanks.
>
> Best Regards,
> Angel
>
> On 1/13/07, Comain Chen <[EMAIL PROTECTED]> wrote:
>> To give the user freedom to decide their own Databinding techniques?
>>
>> Also I have this doubt, why does the codegen module generate
>> MessageReceiver
>> for each Service, not let the binding framework write a general
>> messageReceiver for all services?
>>
>>
>>
>> On 1/13/07, Angel Todorov <[EMAIL PROTECTED]> wrote:
>> >
>> > Hi Axis2 developers,
>> >
>> > I am interested to know what is the motivation behind using custom
>> > message receivers? For example, if I want to invoke non-java
>> > operations, I can have a helper Java class which manages all this
>> > logic, and still be invoked by one of the existing message receivers,
>> > such as the raw XML message receivers.
>> >
>> > Thanks very much for your feedback in advance.
>> >
>> > Regards,
>> > Angel
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail:
>> [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>>
>> --
>> Best regrads,
>> Comain Chen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFqXOBjON2uBzUhh8RApU6AJ0bH7pEz/fm27BbfJHYyv8fguKAKQCfW0Lf
bLiUen4/SXrg9X5sBvNGwz0=
=Cr18
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Best regrads,
Comain Chen

Reply via email to