Hi Deepal,
I think it's very optimistic to assume users are going to be able to use
code generated with Axis2 1.0 with future release. My experience with
Axis(1) releases was that I usually needed to regenerate the code each
time a new release came out. Unless we explicitly add a bunch of unit
tests to help maintain backward compatibility it's unlikely to happen
automatically.
In this case, though, I don't see where just changing the message
receiver over to a delegation approach would necessarily break current
generated code. You can add methods to the underlying
AbstractMessageReceiver class without these needing to be overridden by
the generated subclasses, so it'd be possible to add a
setServiceObjectFactory() method, for instance, without any impact on
current users. Am I missing something on this?
- Dennis
Dennis M. Sosnoski
SOA, Web Services, and XML
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
Deepal Jayasinghe wrote:
Hi Robert;
Pls correct me I am wrong , cant we solve this problem by just writing
your own message receiver for your service. Then you can initialize the
service class the way you want. Once we found message receiver for
incoming message Axis2 hands over the message to that guy , then its up
to the message receiver to do whatever he wants.
I understand your situation and I think it is so specific and not a
generic use case , so changing Message Receiver API for this is not good
idea to me. In the meantime if we make any API changes to message
receiver API , any one who use Axis2 1.0 distribution they can not just
update to next version unless he code gen again. The problem is we are
going to add one more method to API and that will give compile errors
for older message receivers.
comments ?
robert lazarski wrote:
While we're asking for comments on refactoring Message Receivers and
inheritance...
The issue I have is AbstractMessageReceiver.makeNewServiceObject() .
All message receivers - even the RPC ones - extend
AbstractMessageReceiver or a subclass that extends
AbstractMessageReceiver. There is no way AFAICT in axis2's present
form to not duplicate code to support all the MEPS, when only needing
an alternative way to load the service class.
Since no one has commented yet on that, and so far I really don't have
a better idea...
The simple idea I have - which may have implications as simple answers
often do - is to just support an _optional_ element in services.xml
such as ...
<service><newtag>org.MyServiceObjectHandler</newtag></service> that
allows AbstractMessageReceiver.makeNewServiceObject() to hand off its
responsibities to another class as sort of a delegate.
AxisService.getParameter already automatically supports that, all that
I think we would need is a change to the services.xml schema and two
lines of code or so in AbstractMessageReceiver.makeNewServiceObject() .
Comments? Or better ideas ;-) .
Robert
http://www.braziloutsource.com/
On 5/30/06, *Rajith Attapattu* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Sanjiva,
I think I totaly missed the design issue here with the
MessageReceiver interface.
Yes I overlooked the fact that the engine should be unware of the MEP.
However if we use inheritance too much we will end up with bloated
class heirachies that are not flexible and difficult to maintain.
How do u propose to delegate the concerns?
What do u propose for the problem I described? or am i looking at
the right place?
Regards,
Rajith
On 5/26/06, *Sanjiva Weerawarana* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
(Added missing [axis2] prefix.)
On Thu, 2006-05-25 at 17:45 -0400, Rajith Attapattu wrote:
> Hi All,
>
> Robert I totally agree with you here. Can we refactor the
> MessageReceiver interface to add more methods.
> The makeNewServiceObject() seems to be a bit more broad.
Maybe we
> should break it down to isolate the class loading part to
avoid the
> code duplication Robert pointed out.
>
> However here is my request. I would love to see
invokeBusinessLogic
> method in the MessageReceiver interface !!!
No way! That will totally break the design point of the engine
being
unaware of the details of the MEP and simply delivering the
message to
the message receiver and saying "here you go, got a message
for you".
There's no concept of "invoke biz logic" out of the engine.
> Bcos then I can write a general decorator that wraps around the
> invocation wether the Message receiver is RawXML, RPC or Spring
> based.
> Now I have to duplicate code all over which is very ugly.
I don't get it - why can't you share code thru inheritance and
delegation?
> Btw the invokeBusinessLogic has both the inMsgContext and the
> outMsgContext, so u can write a decorater that could pass some
> reference from the inMsgCtx to the outMsgCtx, which could be
very
> handy.
Again you're assuming that the MEP has both of those and
doesn't have a
2nd in msg context for example. That's not correct.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
