You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Nabeel Yoosuf <na...@gmail.com> on 2006/06/05 07:08:38 UTC
[Axis2] Message Receiver - Suggestions
>From the point of view of writing custom message receivers, I see the
following modifications to msg_recv would be appropriate.
1. axis2_xml_in_out_msg_recv.h can be (and should be) made private.
This file has only one function - creating the the msg_recv struct. This is
used only by the axis2_get_instance function which is in the same file where
the create function is implemented. Hence, the header should be made
private.
2. svc_skeleton struct related functions can be moved out of msg_recv. The
msg_recv does not need to know anything about svc_skeleton.
The following functions in msg_recv are used only by
raw_xml_in_out_msg_recv.
/* These two functions are not required to be in the msg_recv ops */
axis2_svc_skeleton_t * AXIS2_CALL
axis2_msg_recv_make_new_svc_obj(axis2_msg_recv_t *msg_recv,
const axis2_env_t *env,
struct axis2_msg_ctx *msg_ctx);
axis2_svc_skeleton_t * AXIS2_CALL
axis2_msg_recv_get_impl_obj(axis2_msg_recv_t *msg_recv,
const axis2_env_t *env,
struct axis2_msg_ctx *msg_ctx);
3.For the following function, the function pointer can be defined in
msg_recv ops and the impl lives
inside the extended msg receiver code (default impl does nothing).
axis2_status_t AXIS2_CALL
axis2_msg_recv_delete_svc_obj(axis2_msg_recv_t *msg_recv,
const axis2_env_t *env,
axis2_msg_ctx_t *msg_ctx);
With the above changes, anyone who extends the msg_recv needs to override
only the following in their create function.
msg_recv->ops->invoke_in_out_business_logic_sync
msg_recv->ops->delete_svc_obj (default impl does nothing)
msg_recv->ops->receive (default impl points to msg_recv->ops->receive_sync)
thanks
-Nabeel
Re: [Axis2] Message Receiver - Suggestions
Posted by Nabeel Yoosuf <na...@gmail.com>.
On 6/5/06, Damitha Kumarage <da...@gmail.com> wrote:
>
> Nabeel,
> Ideally what we should have is
> _______php_recv
> |
> _________raw_xml_msg_recv
> | |
> msg_recv|______default_recv _|________some other default recv
> | |
> | |________some other
> default recv
> |
> |______some other recv
>
> Because then we can have skeleton creation methods in default_recv so
> that they need
> not be reimplemented in default message receivers. I think your current
> concern is that you
> implement your php receiver based on message receiver, yet you don't
> want those
> svc skeleton create methods because you have your own php creation
> methods to implement.
> I think above design include your suggestions for message receiver.
> I will implement this ASAP
Damitha,
+1 ; You have infact thought about this one more step ahead!
-Nabeel
thanks
> Damitha
>
>
>
> Nabeel Yoosuf wrote:
>
> > >From the point of view of writing custom message receivers, I see the
> > following modifications to msg_recv would be appropriate.
> >
> > 1. axis2_xml_in_out_msg_recv.h can be (and should be) made private.
> > This file has only one function - creating the the msg_recv struct.
> > This is used only by the axis2_get_instance function which is in the
> > same file where the create function is implemented. Hence, the header
> > should be made private.
> >
> > 2. svc_skeleton struct related functions can be moved out of msg_recv.
> > The msg_recv does not need to know anything about svc_skeleton.
> > The following functions in msg_recv are used only by
> > raw_xml_in_out_msg_recv.
> >
> > /* These two functions are not required to be in the msg_recv ops */
> > axis2_svc_skeleton_t * AXIS2_CALL
> > axis2_msg_recv_make_new_svc_obj(axis2_msg_recv_t *msg_recv,
> > const axis2_env_t *env,
> > struct axis2_msg_ctx *msg_ctx);
> >
> > axis2_svc_skeleton_t * AXIS2_CALL
> > axis2_msg_recv_get_impl_obj(axis2_msg_recv_t *msg_recv,
> > const axis2_env_t *env,
> > struct axis2_msg_ctx *msg_ctx);
> >
> >
> > 3.For the following function, the function pointer can be defined in
> > msg_recv ops and the impl lives
> > inside the extended msg receiver code (default impl does nothing).
> > axis2_status_t AXIS2_CALL
> > axis2_msg_recv_delete_svc_obj(axis2_msg_recv_t *msg_recv,
> > const axis2_env_t *env,
> > axis2_msg_ctx_t *msg_ctx);
> >
> > With the above changes, anyone who extends the msg_recv needs to
> > override only the following in their create function.
> >
> > msg_recv->ops->invoke_in_out_business_logic_sync
> > msg_recv->ops->delete_svc_obj (default impl does nothing)
> > msg_recv->ops->receive (default impl points to
> > msg_recv->ops->receive_sync)
> >
> > thanks
> > -Nabeel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
Re: [Axis2] Message Receiver - Suggestions
Posted by Damitha Kumarage <da...@gmail.com>.
Nabeel,
Ideally what we should have is
_______php_recv
| _________raw_xml_msg_recv
| |
msg_recv|______default_recv _|________some other default recv
| |
| |________some other
default recv
|
|______some other recv
Because then we can have skeleton creation methods in default_recv so
that they need
not be reimplemented in default message receivers. I think your current
concern is that you
implement your php receiver based on message receiver, yet you don't
want those
svc skeleton create methods because you have your own php creation
methods to implement.
I think above design include your suggestions for message receiver.
I will implement this ASAP
thanks
Damitha
Nabeel Yoosuf wrote:
> >From the point of view of writing custom message receivers, I see the
> following modifications to msg_recv would be appropriate.
>
> 1. axis2_xml_in_out_msg_recv.h can be (and should be) made private.
> This file has only one function - creating the the msg_recv struct.
> This is used only by the axis2_get_instance function which is in the
> same file where the create function is implemented. Hence, the header
> should be made private.
>
> 2. svc_skeleton struct related functions can be moved out of msg_recv.
> The msg_recv does not need to know anything about svc_skeleton.
> The following functions in msg_recv are used only by
> raw_xml_in_out_msg_recv.
>
> /* These two functions are not required to be in the msg_recv ops */
> axis2_svc_skeleton_t * AXIS2_CALL
> axis2_msg_recv_make_new_svc_obj(axis2_msg_recv_t *msg_recv,
> const axis2_env_t *env,
> struct axis2_msg_ctx *msg_ctx);
>
> axis2_svc_skeleton_t * AXIS2_CALL
> axis2_msg_recv_get_impl_obj(axis2_msg_recv_t *msg_recv,
> const axis2_env_t *env,
> struct axis2_msg_ctx *msg_ctx);
>
>
> 3.For the following function, the function pointer can be defined in
> msg_recv ops and the impl lives
> inside the extended msg receiver code (default impl does nothing).
> axis2_status_t AXIS2_CALL
> axis2_msg_recv_delete_svc_obj(axis2_msg_recv_t *msg_recv,
> const axis2_env_t *env,
> axis2_msg_ctx_t *msg_ctx);
>
> With the above changes, anyone who extends the msg_recv needs to
> override only the following in their create function.
>
> msg_recv->ops->invoke_in_out_business_logic_sync
> msg_recv->ops->delete_svc_obj (default impl does nothing)
> msg_recv->ops->receive (default impl points to
> msg_recv->ops->receive_sync)
>
> thanks
> -Nabeel
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org