You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Ruwan Linton <ru...@gmail.com> on 2009/08/27 06:36:04 UTC
[PROPOSAL] Axis2 Deployer behaviour on hot update
Hi devs,
I am trying to implement the Hot deployment and Hot update of the synapse
artifacts, and realized that there are some issues; I first thought of
writing our own deployment behaviour because we wanted some conditions to be
checked on the hot update case undeployment of the artifacts.
Let me first describe how Hot update works in axis2, correct me if I am
wrong but from what I have figured out so far, axis2 repository listener
task calls unDeploy method of the deployer implementation first and then
calls the deploy method again to deploy the artifact with the changes.
So this approach has two issues,
1. There is a considerable downtime of the artifact which is being hot
updated
2. There is no means of knowing the case where the undeploy method being
called, for example synapse needs to have a main sequence for it to operate
properly, so synapse has to force the user to not to undeploy the main
sequence while it should allow the user to hot update it.
I propose adding a update method to the Deployer interface or passing the
state as an argument, we could use the DeploymentFileData class to provide
the operation, but that doesn't resolve the issue because the undeploy
method has a String file name as its argument, so this canot be fixed
without an API change in the deployer implementation.
Being said the above I can implement this in Synapse, but since we had huge
debates earlier on writing stuff on synapse replacing axis2 stuff just
because they do not fit into synapse without letting the axis2 community
know about those, I thought of proposing this to the axis2 as well.
WDYT?
Or may be I am missign something which can resolve the above 2 issues, in
which case please be kind enough to point me to the behaviour that I should
be using.. :-)
Thanks,
Ruwan
--
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Aug 27, 2009 at 10:06 AM, Ruwan Linton <ru...@gmail.com>wrote:
> Hi devs,
>
> I am trying to implement the Hot deployment and Hot update of the synapse
> artifacts, and realized that there are some issues; I first thought of
> writing our own deployment behaviour because we wanted some conditions to be
> checked on the hot update case undeployment of the artifacts.
>
> Let me first describe how Hot update works in axis2, correct me if I am
> wrong but from what I have figured out so far, axis2 repository listener
> task calls unDeploy method of the deployer implementation first and then
> calls the deploy method again to deploy the artifact with the changes.
>
> So this approach has two issues,
>
> 1. There is a considerable downtime of the artifact which is being hot
> updated
> 2. There is no means of knowing the case where the undeploy method
> being called, for example synapse needs to have a main sequence for it to
> operate properly, so synapse has to force the user to not to undeploy the
> main sequence while it should allow the user to hot update it.
>
> I propose adding a update method to the Deployer interface or passing the
> state as an argument, we could use the DeploymentFileData class to provide
> the operation, but that doesn't resolve the issue because the undeploy
> method has a String file name as its argument, so this canot be fixed
> without an API change in the deployer implementation.
>
> Being said the above I can implement this in Synapse, but since we had huge
> debates earlier on writing stuff on synapse replacing axis2 stuff just
> because they do not fit into synapse without letting the axis2 community
> know about those, I thought of proposing this to the axis2 as well.
>
> WDYT?
>
> Or may be I am missign something which can resolve the above 2 issues, in
> which case please be kind enough to point me to the behaviour that I should
> be using.. :-)
I went through the deployment engine code and it seems bit complicated and
can not solve without changing Deployer interface.
Let me put this suggestion if it works for you :).
At the undeploy method you get the file name. Then you can check whether
this file exists.
if not exist this is only an undeployment so you do the undeployment
if exists then this is a update, you keep this entry in your deployer. Now
at the deploy method if there is an entry you do an update and if not do a
fresh deployments.
Anyway I think, writing a synapse deployer would be a correct long term
solution since you can customise it purely for synapse needs.
thanks,
Amila.
>
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Deepal jayasinghe <de...@gmail.com>.
Afkham Azeez wrote:
> Simply deactivating-redeploying-activating is not the ideal solution.
> It should be;
>
> maintenace-mode(service_foo)->redeploy(service_foo)->normal-mode(service_foo)
>
> In maintenance mode, a service will not accept new requests, but will
> complete servicing existing requests. So, there is a difference
> between deactivating a service & putting it into maintenance-mode,
> unless deactivated services will complete the requests being processed.
I may be wrong, anyway FYI this is what activate, de-activate does. In
my case what I did was
servicefoo.setActive(false)->redeploy(foo)-->servicefoo.setActive(true).
"In AxisService you have a method called activate/inactivate, when you
inactive a service system does not take any more request to that service
(will throw an exception saying service not found) and will process all
the current messages."
Again, I did a very simple day to day approach, where I tried to fulfill
my goal with the resource I have, so that might not be the ideal approach.
Thanks,
Deepa
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Sun, Aug 30, 2009 at 5:18 PM, Deepal jayasinghe <de...@gmail.com>wrote:
> Yes a few bugs, first if the service create any connection like DB or
> file and put into ConFigCTX then those will not be removed when we do
> the undeployment since service does not know that. Second, if they add
> any properties to ConFigCtx then the same thing happens. Third it is
Any state that's put into the contexts are runtime state. I was referring
only to the static data that's in AxisService/AxisConfiguration etc. - that
stuff can just fall off right?
Even today, if you call undeploy I don't see how that can tell a service to
remove things like DB connections. Those need to be tied to runtime state
and somehow associated to messages.
hard to detect when to finish the current message processing, because
> request follows different invocation depending on the MEP. Forth if the
> service uses something like RM, then we are not going to inform RM about
> that, so those state will remain there. Fifth based on where we have
> lib, we load classes various class loaders, so at the deployment time we
> can not 100% guarantee that we are going to unload all the classes.
> There may be some other, which did not come into my mind.....
Well if we load new version of a service its just another AxisService and
all the classes loaded by a different class loader. The only issue where
there's overlap is when that object is given a name and stuffed into hashmap
in AxisConfig (via ServiceGroup but let's ignore that complication for now).
I agree its hard/impossible to know when the messages in the system are
"done". I think what's done in Synapse is they "wait for a while" .. and
after that kill off whatever you can and say done.
Anyway, I like the idea and its worth looking into. I'm sure there will be
lots of little gotchas that come up :).
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Deepal jayasinghe <de...@gmail.com>.
Sanjiva Weerawarana wrote:
> If we do it the way Deepal had worked on a while ago, the downtime is
> VERY low. Basically, what we need to do is to mark the AxisService as
> "old" (or inactive) and then that immediately stops new messages from
> being delivered to it. Any already dispatched service is not at all
> affected - as the handler chain etc. is already computed and in any
> case we're not changing that AxisService instance. The new AxisService
> object representing the updated service can then be deployed by making
> that be what's found by service lookup. In other words, if we do this
> by locking AxisConfig then the downtime is basically time of object
> lock + copying a few pointers. Once all messages that are running
> "finish", the old AxisService will just get GC'ed.
>
> Hmmm clearly there must be some bug in that logic; its too simple.
:), You must be kidding right :)
Yes a few bugs, first if the service create any connection like DB or
file and put into ConFigCTX then those will not be removed when we do
the undeployment since service does not know that. Second, if they add
any properties to ConFigCtx then the same thing happens. Third it is
hard to detect when to finish the current message processing, because
request follows different invocation depending on the MEP. Forth if the
service uses something like RM, then we are not going to inform RM about
that, so those state will remain there. Fifth based on where we have
lib, we load classes various class loaders, so at the deployment time we
can not 100% guarantee that we are going to unload all the classes.
There may be some other, which did not come into my mind.....
Thanks,
Deepal
>
> Sanjiva.
>
> On Sun, Aug 30, 2009 at 1:16 PM, Afkham Azeez <afkham@gmail.com
> <ma...@gmail.com>> wrote:
>
> Simply deactivating-redeploying-activating is not the ideal
> solution. It should be;
>
> maintenace-mode(service_foo)->redeploy(service_foo)->normal-mode(service_foo)
>
> In maintenance mode, a service will not accept new requests, but
> will complete servicing existing requests. So, there is a
> difference between deactivating a service & putting it into
> maintenance-mode, unless deactivated services will complete the
> requests being processed.
>
> However, there will be a small downtime for this service.
>
> Azeez
>
>
> On Sun, Aug 30, 2009 at 4:02 AM, Deepal jayasinghe
> <deepalk@gmail.com <ma...@gmail.com>> wrote:
>
>
> >
> >
> > Then there's the question of how to do the update - ideal is
> to let
> > messages that are already being processed be processed by
> the still
> > active version and to direct new messages to the new
> version. I'm not
> > sure that's implementable though .. or it would require one
> to bring
> > that concept into dispatchers etc. to do the right thing.
> Ideal is for
> > it to be burnt into the AxisConfig but that's a *huge* change.
> It is doable, and in fact I have done that, but did not commit my
> changes, since it was just for fun :).
> In AxisService you have a method called activate/inactivate,
> when you
> inactive a service system does not take any more request to
> that service
> (will throw an exception saying service not found) and will
> process all
> the current messages. Then, you need call the deployment engine to
> update the new service (Deployment engine has a method to load a
> particular services). Then you back in business.
>
> Thanks,
> Deepal
>
>
>
>
> --
> Thanks
> Afkham Azeez
>
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
--
Thank you!
http://blogs.deepal.org
http://deepal.org
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
If we do it the way Deepal had worked on a while ago, the downtime is VERY
low. Basically, what we need to do is to mark the AxisService as "old" (or
inactive) and then that immediately stops new messages from being delivered
to it. Any already dispatched service is not at all affected - as the
handler chain etc. is already computed and in any case we're not changing
that AxisService instance. The new AxisService object representing the
updated service can then be deployed by making that be what's found by
service lookup. In other words, if we do this by locking AxisConfig then the
downtime is basically time of object lock + copying a few pointers. Once all
messages that are running "finish", the old AxisService will just get GC'ed.
Hmmm clearly there must be some bug in that logic; its too simple.
Sanjiva.
On Sun, Aug 30, 2009 at 1:16 PM, Afkham Azeez <af...@gmail.com> wrote:
> Simply deactivating-redeploying-activating is not the ideal solution. It
> should be;
>
> maintenace-mode(service_foo)->redeploy(service_foo)->normal-mode(service_foo)
>
> In maintenance mode, a service will not accept new requests, but will
> complete servicing existing requests. So, there is a difference between
> deactivating a service & putting it into maintenance-mode, unless
> deactivated services will complete the requests being processed.
>
> However, there will be a small downtime for this service.
>
> Azeez
>
>
> On Sun, Aug 30, 2009 at 4:02 AM, Deepal jayasinghe <de...@gmail.com>wrote:
>
>>
>> >
>> >
>> > Then there's the question of how to do the update - ideal is to let
>> > messages that are already being processed be processed by the still
>> > active version and to direct new messages to the new version. I'm not
>> > sure that's implementable though .. or it would require one to bring
>> > that concept into dispatchers etc. to do the right thing. Ideal is for
>> > it to be burnt into the AxisConfig but that's a *huge* change.
>> It is doable, and in fact I have done that, but did not commit my
>> changes, since it was just for fun :).
>> In AxisService you have a method called activate/inactivate, when you
>> inactive a service system does not take any more request to that service
>> (will throw an exception saying service not found) and will process all
>> the current messages. Then, you need call the deployment engine to
>> update the new service (Deployment engine has a method to load a
>> particular services). Then you back in business.
>>
>> Thanks,
>> Deepal
>>
>
>
>
> --
> Thanks
> Afkham Azeez
>
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Afkham Azeez <af...@gmail.com>.
Simply deactivating-redeploying-activating is not the ideal solution. It
should be;
maintenace-mode(service_foo)->redeploy(service_foo)->normal-mode(service_foo)
In maintenance mode, a service will not accept new requests, but will
complete servicing existing requests. So, there is a difference between
deactivating a service & putting it into maintenance-mode, unless
deactivated services will complete the requests being processed.
However, there will be a small downtime for this service.
Azeez
On Sun, Aug 30, 2009 at 4:02 AM, Deepal jayasinghe <de...@gmail.com>wrote:
>
> >
> >
> > Then there's the question of how to do the update - ideal is to let
> > messages that are already being processed be processed by the still
> > active version and to direct new messages to the new version. I'm not
> > sure that's implementable though .. or it would require one to bring
> > that concept into dispatchers etc. to do the right thing. Ideal is for
> > it to be burnt into the AxisConfig but that's a *huge* change.
> It is doable, and in fact I have done that, but did not commit my
> changes, since it was just for fun :).
> In AxisService you have a method called activate/inactivate, when you
> inactive a service system does not take any more request to that service
> (will throw an exception saying service not found) and will process all
> the current messages. Then, you need call the deployment engine to
> update the new service (Deployment engine has a method to load a
> particular services). Then you back in business.
>
> Thanks,
> Deepal
>
--
Thanks
Afkham Azeez
Blog: http://afkham.org
Developer Portal: http://www.wso2.org
WSAS Blog: http://wso2wsas.blogspot.com
Company: http://wso2.com
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Deepal jayasinghe <de...@gmail.com>.
>
>
> Then there's the question of how to do the update - ideal is to let
> messages that are already being processed be processed by the still
> active version and to direct new messages to the new version. I'm not
> sure that's implementable though .. or it would require one to bring
> that concept into dispatchers etc. to do the right thing. Ideal is for
> it to be burnt into the AxisConfig but that's a *huge* change.
It is doable, and in fact I have done that, but did not commit my
changes, since it was just for fun :).
In AxisService you have a method called activate/inactivate, when you
inactive a service system does not take any more request to that service
(will throw an exception saying service not found) and will process all
the current messages. Then, you need call the deployment engine to
update the new service (Deployment engine has a method to load a
particular services). Then you back in business.
Thanks,
Deepal
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I forgot to mention another point I've been thinking of - even with hot
deployment turned off, what we have by default is a "scan and deploy at
startup" type model. For example, if someone makes a mistake with file
permissions a particular service may not (silently) get deployed.
IMO we also need to support a more locked-down model similar to what was
done for the URL repo code with services.list. Basically to manually write
down the list of services to be deployed (in the order that's listed even)
instead of discovering what's around and deploying them once. I'm not at all
suggesting losing any functionality we have but rather to maybe support
services.list in all cases. IIRC that only works (out of necessity) for URL
repos as there was no way to get a list then. Now of course we'd just make
it an atom feed instead of inventing our own silly little format ...
Sanjiva.
On Sun, Aug 30, 2009 at 8:15 AM, Sanjiva Weerawarana
<sa...@opensource.lk>wrote:
> On Thu, Aug 27, 2009 at 8:47 PM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> >>
>> > In Axis2, specially in production hot deployment is not something people
>> > are going to use regularly. So downtown or hot-update is not an big
>> > issues (rather they will turn off both hot-deployment and hot-update)
>>
>> Does the Axis2 deployment mechanism lack this kind of features because
>> people don't use it regularly, or do people not use it regularly
>> because it lacks these features?
>
>
> In my experience so far, people do use / leave hot deployment around but
> the deployment processes effectively disable it. That is, in no production
> setting is the developer allowed to update the config of a running server by
> logging into it :). In one case I know of someone who's updating the
> (Synapse) system config multiple times a day but does it by putting their
> servers into "service mode" in a round-robin fashion but that's the type of
> care someone must take to "hot update" a production system. In service mode
> the server doesn't accept any more messages but processes the messages that
> were in flight before doing system updates. So effectively he brings a node
> in a cluster down without affecting service response. However, it does
> result in a period of time where the servers have different versions of
> stuff deployed (I think).
>
> However, for developers this is very useful ... its like being able to edit
> a JSP and just refresh the page. Imagine if you had to redeploy the war file
> to get that to work?!
>
> IMO the deployer interface needs an update() method which the deployment
> logic calls after it determines (somehow) that the service needs to be
> updated. If we're changing the signature then we might as well do ti right
> rather than hacking it in (by passing a filename).
>
> Then there's the question of how to do the update - ideal is to let
> messages that are already being processed be processed by the still active
> version and to direct new messages to the new version. I'm not sure that's
> implementable though .. or it would require one to bring that concept into
> dispatchers etc. to do the right thing. Ideal is for it to be burnt into the
> AxisConfig but that's a *huge* change. If its considered a developer level
> feature then the current style is ok - just yank the old one and put the new
> one in.
>
> So to answer your question - IMO its because its VERY hard to hot update a
> system and not have weird/inconsistent behavior. If you absolutely need 24x7
> operation with zero (scheduled) downtime then of course you need to do
> something like what I explained above and then clearly understand the issues
> related to different nodes having different versions of the service around.
> Its much easier to have a scheduled downtime.
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Thu, Aug 27, 2009 at 8:47 PM, Andreas Veithen
<an...@gmail.com>wrote:
> >>
> > In Axis2, specially in production hot deployment is not something people
> > are going to use regularly. So downtown or hot-update is not an big
> > issues (rather they will turn off both hot-deployment and hot-update)
>
> Does the Axis2 deployment mechanism lack this kind of features because
> people don't use it regularly, or do people not use it regularly
> because it lacks these features?
In my experience so far, people do use / leave hot deployment around but the
deployment processes effectively disable it. That is, in no production
setting is the developer allowed to update the config of a running server by
logging into it :). In one case I know of someone who's updating the
(Synapse) system config multiple times a day but does it by putting their
servers into "service mode" in a round-robin fashion but that's the type of
care someone must take to "hot update" a production system. In service mode
the server doesn't accept any more messages but processes the messages that
were in flight before doing system updates. So effectively he brings a node
in a cluster down without affecting service response. However, it does
result in a period of time where the servers have different versions of
stuff deployed (I think).
However, for developers this is very useful ... its like being able to edit
a JSP and just refresh the page. Imagine if you had to redeploy the war file
to get that to work?!
IMO the deployer interface needs an update() method which the deployment
logic calls after it determines (somehow) that the service needs to be
updated. If we're changing the signature then we might as well do ti right
rather than hacking it in (by passing a filename).
Then there's the question of how to do the update - ideal is to let messages
that are already being processed be processed by the still active version
and to direct new messages to the new version. I'm not sure that's
implementable though .. or it would require one to bring that concept into
dispatchers etc. to do the right thing. Ideal is for it to be burnt into the
AxisConfig but that's a *huge* change. If its considered a developer level
feature then the current style is ok - just yank the old one and put the new
one in.
So to answer your question - IMO its because its VERY hard to hot update a
system and not have weird/inconsistent behavior. If you absolutely need 24x7
operation with zero (scheduled) downtime then of course you need to do
something like what I explained above and then clearly understand the issues
related to different nodes having different versions of the service around.
Its much easier to have a scheduled downtime.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Andreas Veithen <an...@gmail.com>.
On Thu, Aug 27, 2009 at 17:02, Deepal jayasinghe<de...@gmail.com> wrote:
>>
>> Let me first describe how Hot update works in axis2, correct me if I
>> am wrong but from what I have figured out so far, axis2 repository
>> listener task calls unDeploy method of the deployer implementation
>> first and then calls the deploy method again to deploy the artifact
>> with the changes.
> Yes that is correct.
>>
>> So this approach has two issues,
>>
>> 1. There is a considerable downtime of the artifact which is being
>> hot updated
>>
> In Axis2, specially in production hot deployment is not something people
> are going to use regularly. So downtown or hot-update is not an big
> issues (rather they will turn off both hot-deployment and hot-update)
Does the Axis2 deployment mechanism lack this kind of features because
people don't use it regularly, or do people not use it regularly
because it lacks these features?
>>
>> 1. There is no means of knowing the case where the undeploy method
>> being called, for example synapse needs to have a main sequence
>> for it to operate properly, so synapse has to force the user to
>> not to undeploy the main sequence while it should allow the user
>> to hot update it.
>>
> You can do this with your deployer.
>>
>> I propose adding a update method to the Deployer interface or passing
>> the state as an argument,
> I would consider undeploy as the update method you can do whatever you
> want there, and you can just ignore at when it call deploy method.
> (I know in undeploy method you only get the filename, but since your
> deployer is domain specific you know what to do with the file name)
>> we could use the DeploymentFileData class to provide the operation,
> Thanks,
> Deepal
>
Re: SOAP message structure
Posted by Demetris <de...@ece.neu.edu>.
Hi Wolfgang,
first off, thanks for both responses to my postings - very informative
and I appreciate it.
Regarding your response below, my original posting said "the Axis
project implements a standard", which
is in a agreement of what you are also saying below - implementation
engines do not and SHOULD NOT
create standards - of course ;). And since we both agree on that then if
you are right that
theoritically the SOAP message structure does not get changed across
versions of Axis then that;s what
I needed to know. Now I wouldn't have needed to bother with SOAP at all,
but there was a reason
I asked the Q - in a design I am working on we intercept, inspect and
modify the outgoing and incoming
SOAP messages to offer a configurable addressing scheme. I am sure there
are a few other ways to do this but
I am following requirements. So if my legacy design needs to be changed
once I upgrade to Axis because
of the SOAP message it would be good to know beforehand - I will follow
up in practice with this
and let you know what I find.
Thanks much
WJ Krpelan wrote:
> Hi,
> Webservice Engines dont create Standards but try to implement them - as good as it gets anyhow -
> I'd say developers of Web Services should not need to bother with SOAP at all - apart from extreme cases of interoperability problems.
> Using a WSDL first approach you should have no problems exchanging your Web Service Engine on one ore both sides - that is, theoretically
> To answer your question literally - no, I dont think so!
> Cheers, Wolfgang
>
> --- On Thu, 8/27/09, Demetris <de...@ece.neu.edu> wrote:
>
>
>> From: Demetris <de...@ece.neu.edu>
>> Subject: SOAP message structure
>> To: axis-dev@ws.apache.org
>> Date: Thursday, August 27, 2009, 10:17 PM
>>
>> In our migration from the Axis 1.x to Axis2 and beyond, one
>> question that came up was how the SOAP
>> message structure emitted by the client stubs generated by
>> Axis2 is exactly the same as the one that would
>> have been created for the same Web Service from an Axis 1.x
>> stub (considering the same encoding styles).
>> I know the Axis project implements a standard so I am
>> expecting that it still follows that standard across
>> versions - if it offers async invocations or all the other
>> goodies that is a separate layer, but the emitted
>> SOAP messages I am not expecting to change. Is that a
>> correct assumption?
>>
>> Thanks
>>
>>
>>
>
>
>
>
>
Re: SOAP message structure
Posted by WJ Krpelan <kr...@yahoo.com>.
Hi,
Webservice Engines dont create Standards but try to implement them - as good as it gets anyhow -
I'd say developers of Web Services should not need to bother with SOAP at all - apart from extreme cases of interoperability problems.
Using a WSDL first approach you should have no problems exchanging your Web Service Engine on one ore both sides - that is, theoretically
To answer your question literally - no, I dont think so!
Cheers, Wolfgang
--- On Thu, 8/27/09, Demetris <de...@ece.neu.edu> wrote:
> From: Demetris <de...@ece.neu.edu>
> Subject: SOAP message structure
> To: axis-dev@ws.apache.org
> Date: Thursday, August 27, 2009, 10:17 PM
>
> In our migration from the Axis 1.x to Axis2 and beyond, one
> question that came up was how the SOAP
> message structure emitted by the client stubs generated by
> Axis2 is exactly the same as the one that would
> have been created for the same Web Service from an Axis 1.x
> stub (considering the same encoding styles).
> I know the Axis project implements a standard so I am
> expecting that it still follows that standard across
> versions - if it offers async invocations or all the other
> goodies that is a separate layer, but the emitted
> SOAP messages I am not expecting to change. Is that a
> correct assumption?
>
> Thanks
>
>
SOAP message structure
Posted by Demetris <de...@ece.neu.edu>.
In our migration from the Axis 1.x to Axis2 and beyond, one question
that came up was how the SOAP
message structure emitted by the client stubs generated by Axis2 is
exactly the same as the one that would
have been created for the same Web Service from an Axis 1.x stub
(considering the same encoding styles).
I know the Axis project implements a standard so I am expecting that it
still follows that standard across
versions - if it offers async invocations or all the other goodies that
is a separate layer, but the emitted
SOAP messages I am not expecting to change. Is that a correct assumption?
Thanks
kSOAP2 to Axis
Posted by Demetris <de...@ece.neu.edu>.
Has anyone used the kSOAP API to access an Axis WS? If you have I am
wondering if you ever
ran into this exception - I think I have the client setup correctly and
yet the XmlPullParser is complaining.
Any ideas on this would be greatly appreciated. Thanks
request: <?xml version="1.0" encoding="UTF-8"
standalone="no"?><v:Envelope
xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
xmlns:d="http://www.w3.org/2001/XMLSchema"
xmlns:c="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:v="http://schemas.xmlsoap.org/soap/envelope/"><v:Header
/><v:Body><n0:getBooks id="o0" c:root="1" xmlns:n0="http://myBooks"
/></v:Body></v:Envelope>
response: <html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
</body>
</html>
org.xmlpull.v1.XmlPullParserException: expected: START_TAG
{http://schemas.xmlsoap.org/soap/envelope/}Envelope (position:START_TAG
<html>@1:6 in java.io.InputStreamReader@1d32ad89)
at org.kxml2.io.KXmlParser.exception(Unknown Source)
at org.kxml2.io.KXmlParser.require(Unknown Source)
at org.ksoap2.SoapEnvelope.parse(Unknown Source)
at org.ksoap2.transport.Transport.parseResponse(Unknown Source)
at org.ksoap2.transport.HttpTransport.call(Unknown Source)
at Utils.TestAxis.sendkSOAPOSGiPost(Unknown Source)
at Utils.TestAxis.main(Unknown Source)
at java.lang.reflect.Method.invoke(Compiled Method)(Unknown Source)
at sun.misc.CVM.runMain(Unknown Source)
Re: SOAP styles
Posted by Demetris <de...@ece.neu.edu>.
Hi Wolfgang,
I think I lost the original thread contents so all I have is this below
- I asked originally if I can get the
Axis 1.x to generate/work with doc/lit instead of rpc/lit style and you
sent me some good pointers.
Is it possible I can get your take on this again (or if anyone else has
any more info on the list please
do not hesitate to send me your suggestions)?
Thanks much
WJ Krpelan wrote:
> Hi,
> small wonder.
> One possibility is of course given by the saying "every IT-Problem can be solved by another indirection"
> create new webservices out of the description of the old ones and let the new ones call the old ones - performance-issues to the side
> kind of usual IT-madness, dont cite me
> Cheers, Wolfgang
>
> --- On Mon, 8/31/09, Demetris <de...@ece.neu.edu> wrote:
>
>
>
Re: SOAP styles
Posted by Demetris <de...@ece.neu.edu>.
He he - I hear ya - indirections indirections ..
Not a bad idea and that's something we looked into it Wolfgang as a last
resort. Thanks for the pointers and I will keep the
list informed on the outcome.
WJ Krpelan wrote:
> Hi,
> small wonder.
> One possibility is of course given by the saying "every IT-Problem can be solved by another indirection"
> create new webservices out of the description of the old ones and let the new ones call the old ones - performance-issues to the side
> kind of usual IT-madness, dont cite me
> Cheers, Wolfgang
>
> --- On Mon, 8/31/09, Demetris <de...@ece.neu.edu> wrote:
>
>
>> From: Demetris <de...@ece.neu.edu>
>> Subject: Re: SOAP styles
>> To: axis-dev@ws.apache.org
>> Date: Monday, August 31, 2009, 6:48 PM
>>
>> Hi Wolfgang,
>>
>> thanks for the good info - I did see some
>> of these links and I will go over them.
>>
>> We have an underlying p2p infrastructure
>> that intercepts the SOAP messages from
>> clients to servers without distrupting the operation of the
>> upper layers ( so the soap
>> enginers and the WS implementations remain as is) and
>> routes them across peers.
>> Now that we are adding mobile peers in the mix, including
>> CXF-based ones, Axis2
>> ones etc. we are seeing some incompatability issues - for
>> ex. CXF does not handle
>> rcp/encoded styles. So how do you suggest we avoid the
>> migration and manage to
>> handle these issues?
>>
>> Thanks again
>>
>> WJ Krpelan wrote:
>>
>>> Hi
>>> http://ws.apache.org/axis/java/reference.html
>>> hopefully answers your last question, dont expect
>>>
>> bugfixes any more ;-)
>>
>>> there is a migration guide for axis1 to axis2
>>>
>> webservices,
>>
>>> http://ws.apache.org/axis2/1_5/migration.html
>>> dont think there is any special attention to
>>>
>> preserving soap-styles however. its really not in the spirit
>> nowadays, see
>>
>>> http://ws-i.org/
>>> you didnt mention why you would want to migrate
>>> good luck,
>>> Wolfgang
>>>
>>> --- On Fri, 8/28/09, Demetris <de...@ece.neu.edu>
>>>
>> wrote:
>>
>>>
>>>
>>>> From: Demetris <de...@ece.neu.edu>
>>>> Subject: Re: SOAP styles
>>>> To: axis-dev@ws.apache.org
>>>> Date: Friday, August 28, 2009, 7:41 PM
>>>>
>>>> Well I will certainly push the notion of upgrading
>>>>
>> the
>>
>>>> target servers but there are cases where the
>>>>
>> customer does
>>
>>>> not
>>>> want to do that. So we NEED to deal with
>>>>
>> deprecated styles
>>
>>>> - so the question will remain if Axis 1.4 can
>>>>
>> generate
>>
>>>> one and only or multiple (even if deprecated)
>>>>
>> styles
>>
>>>> programmatically?
>>>>
>>>> Cheers
>>>>
>>>> WJ Krpelan wrote:
>>>>
>>>>
>>>>> Hi,
>>>>> all SOAP styles except doc/lit are kind of
>>>>>
>> deprecated
>>
>>>>>
>>>>>
>>>> by now and are no longer fully supported by most
>>>>
>> frameworks,
>>
>>>> if at all.
>>>>
>>>>
>>>>> You better migrate everything to doc/lit,
>>>>>
>> resp.
>>
>>>>>
>>>>>
>>>> doc/lit "wrapped" I suppose
>>>>
>>>>
>>>>> Cheers, Wolfgang
>>>>>
>>>>>
>>>>> --- On Thu, 8/27/09, Demetris <de...@ece.neu.edu>
>>>>>
>>>>>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>>> From: Demetris <de...@ece.neu.edu>
>>>>>> Subject: SOAP styles
>>>>>> To: axis-dev@ws.apache.org
>>>>>> Date: Thursday, August 27, 2009, 10:10 PM
>>>>>> Hi all,
>>>>>>
>>>>>> we have some legacy systems still using
>>>>>>
>> Axis 1.4
>>
>>>>>>
>>>>>>
>>>> and we
>>>>
>>>>
>>>>>> need clients from them to generate SOAP
>>>>>> rpc/lit or doc/lit instead of rpc/enc -
>>>>>>
>> does
>>
>>>>>>
>>>>>>
>>>> anyone know if
>>>>
>>>>
>>>>>> the latter is the default for Axis 1.4
>>>>>> and how it can be manipulated
>>>>>>
>> programmatically?
>>
>>>>>> Thanks
>>>>>>
>>>>>> Ruwan Linton wrote:
>>>>>>
>>>>>>
>>
>>
>>>>>>> On Thu, Aug 27, 2009 at 11:21 PM,
>>>>>>>
>> Deepal
>>
>>>>>>>
>>>>>>>
>>
>>
>>>> jayasinghe
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> <deepalk@gmail.com
>>>>>> <ma...@gmail.com>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>
>>
>>>>>>> >
>>>>>>> > No
>>>>>>>
>> I can't, I guess
>>
>>>>>>>
>>>>>>>
>>
>>
>>>> I
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> have explained why I can't use it as
>>>>>>
>> well,
>>
>>>>>>
>>>>>>
>>
>>
>>>>>>> >
>>>>>>>
>> because I cannot
>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> differentiate the undeployment call for
>>>>>>
>> the hot
>>
>>>>>>
>>>>>>
>>
>>
>>>>>>> >
>>>>>>>
>> update and real
>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> undeployment. Well, what Amila suggested
>>>>>>
>> will
>>
>>>>>>
>>>>>>
>>>> work
>>>>
>>>>
>>>>>>
>>>>>>
>>
>>
>>>>>>> >
>>>>>>>
>> though :-)
>>
>>>>>>> Of
>>>>>>>
>> course you can if the
>>
>>>>>>>
>>>>>>>
>>
>>
>>>> file
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> is there then that is hot-update else it
>>>>>>
>>>>>>
>>
>>
>>>>>>> is un
>>>>>>>
>> deployment.
>>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>>
>>>>
>>>>>> >
>>>>>>
>>>>>>
>>
>>
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>>
>>>>
>>>>>> > I propose
>>>>>>
>> adding a update method
>>
>>>>>>
>>>>>>
>>>> to
>>>>
>>>>
>>>>>> the Deployer interface or
>>>>>>
>>>>>>
>>
>>
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>>
>>>>
>>>>>> passing
>>>>>>
>>>>>>
>>
>>
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>>
>>>>
>>>>>> > the state as
>>>>>>
>> an argument,
>>
>>>>>>
>>>>>>
>>
>>
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>> I
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> would consider undeploy as the update
>>>>>>
>> method you
>>
>>>>>>
>>>>>>
>>>> can do
>>>>
>>>>
>>>>>>
>>>>>>
>>
>>
>>>>>>>
>>>>>>>
>> whatever you
>>
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>>
>>>>
>>>>>> want there, and
>>>>>>
>> you can just ignore
>>
>>>>>>
>>>>>>
>>>> at
>>>>
>>>>
>>>>>> when it call deploy
>>>>>>
>>>>>>
>>
>>
>>>>>>>
>>>>>>>
>> method.
>>
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>>
>>>>
>>>>>> (I know in
>>>>>>
>> undeploy method you only
>>
>>>>>>
>>>>>>
>>>> get
>>>>
>>>>
>>>>>> the filename, but
>>>>>>
>>>>>>
>>
>>
>>>>>>> since
>>>>>>>
>> your
>>
>>>>>>>
>>>>>>>
>> >
>>
>>
>>>>
>>>>
>>>>>> deployer is domain
>>>>>>
>> specific you know
>>
>>>>>>
>>>>>>
>>>> what
>>>>
>>>>
>>>>>> to do with the
>>>>>>
>>>>>>
>>
>>
>>>>>>> file
>>>>>>>
>> name)
>>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>> No, the issue is we
>>
>>>>>>>
>>>>>>>
>>
>>
>>>> need
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> to invoke a different code in the case
>>>>>>
>>>>>>
>>
>>
>>>>>>> of hot
>>>>>>> >
>>>>>>>
>> update.
>>
>>>>>>> Yes, as
>>>>>>>
>> I mentioned
>>
>>>>>>>
>>>>>>>
>>
>>
>>>> earlier if
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> the file is there then that is
>>>>>>
>>>>>>
>>
>>
>>>>>>>
>>>>>>>
>> hot-update, else
>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> un-deployment. So it should not be a big
>>>>>>
>> issues.
>>
>>>>>>
>>>>>>
>>
>>
>>>>>>> >
>>>>>>> >
>>>>>>>
>> Anyway I feel I
>>
>>>>>>>
>>>>>>>
>>
>>
>>>> should go
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> for a synapse deployer :-)
>>>>>>
>>>>>>
>>
>>
>>>>>>> I
>>>>>>>
>> though you already have
>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> deployer for synapse.
>>>>>>
>>>>>>
>>
>>
>>>>>>> I mean a new deployer framework
>>>>>>>
>>>>>>>
>>
>>
>>>> implementation, not an
>>>>
>>>>
>>>>>>>
>>>>>>>
>>
>>
>>>>>> deployer.. anyway synapse doesn't have a
>>>>>>
>> deployer
>>
>>>>>>
>>>>>>
>>>> yet.
>>>>
>>>>
>>>>>>
>>>>>>
>>
>>
>>>>>>> Thanks,
>>>>>>> Ruwan
>>>>>>>
>>>>>>> -- Ruwan Linton
>>>>>>> Technical Lead & Product Manager;
>>>>>>>
>> WSO2
>>
>>>>>>>
>>>>>>>
>>
>>
>>>> ESB; http://wso2.org/esb
>>>>
>>>>
>>>>>>> WSO2 Inc.; http://wso2.org
>>>>>>> email: ruwan@wso2.com
>>>>>>>
>>>>>>>
>>
>>
>>>>>> <ma...@wso2.com>;
>>>>>> cell: +94 77 341 3097
>>>>>>
>>>>>>
>>
>>
>>>>>>> blog: http://ruwansblog.blogspot.com
>>>>>>>
>>>>>>>
>>
>>
>>>>>>
>>>>>>
>>
>>
>>>>>
>>>>>
>>
>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
>
Re: SOAP styles
Posted by WJ Krpelan <kr...@yahoo.com>.
Hi,
small wonder.
One possibility is of course given by the saying "every IT-Problem can be solved by another indirection"
create new webservices out of the description of the old ones and let the new ones call the old ones - performance-issues to the side
kind of usual IT-madness, dont cite me
Cheers, Wolfgang
--- On Mon, 8/31/09, Demetris <de...@ece.neu.edu> wrote:
> From: Demetris <de...@ece.neu.edu>
> Subject: Re: SOAP styles
> To: axis-dev@ws.apache.org
> Date: Monday, August 31, 2009, 6:48 PM
>
> Hi Wolfgang,
>
> thanks for the good info - I did see some
> of these links and I will go over them.
>
> We have an underlying p2p infrastructure
> that intercepts the SOAP messages from
> clients to servers without distrupting the operation of the
> upper layers ( so the soap
> enginers and the WS implementations remain as is) and
> routes them across peers.
> Now that we are adding mobile peers in the mix, including
> CXF-based ones, Axis2
> ones etc. we are seeing some incompatability issues - for
> ex. CXF does not handle
> rcp/encoded styles. So how do you suggest we avoid the
> migration and manage to
> handle these issues?
>
> Thanks again
>
> WJ Krpelan wrote:
> > Hi
> > http://ws.apache.org/axis/java/reference.html
> > hopefully answers your last question, dont expect
> bugfixes any more ;-)
> > there is a migration guide for axis1 to axis2
> webservices,
> > http://ws.apache.org/axis2/1_5/migration.html
> > dont think there is any special attention to
> preserving soap-styles however. its really not in the spirit
> nowadays, see
> > http://ws-i.org/
> > you didnt mention why you would want to migrate
> > good luck,
> > Wolfgang
> >
> > --- On Fri, 8/28/09, Demetris <de...@ece.neu.edu>
> wrote:
> >
> >
> >> From: Demetris <de...@ece.neu.edu>
> >> Subject: Re: SOAP styles
> >> To: axis-dev@ws.apache.org
> >> Date: Friday, August 28, 2009, 7:41 PM
> >>
> >> Well I will certainly push the notion of upgrading
> the
> >> target servers but there are cases where the
> customer does
> >> not
> >> want to do that. So we NEED to deal with
> deprecated styles
> >> - so the question will remain if Axis 1.4 can
> generate
> >> one and only or multiple (even if deprecated)
> styles
> >> programmatically?
> >>
> >> Cheers
> >>
> >> WJ Krpelan wrote:
> >>
> >>> Hi,
> >>> all SOAP styles except doc/lit are kind of
> deprecated
> >>>
> >> by now and are no longer fully supported by most
> frameworks,
> >> if at all.
> >>
> >>> You better migrate everything to doc/lit,
> resp.
> >>>
> >> doc/lit "wrapped" I suppose
> >>
> >>> Cheers, Wolfgang
> >>>
> >>>
> >>> --- On Thu, 8/27/09, Demetris <de...@ece.neu.edu>
> >>>
> >> wrote:
> >>
> >>>
> >>>> From: Demetris <de...@ece.neu.edu>
> >>>> Subject: SOAP styles
> >>>> To: axis-dev@ws.apache.org
> >>>> Date: Thursday, August 27, 2009, 10:10 PM
> >>>> Hi all,
> >>>>
> >>>> we have some legacy systems still using
> Axis 1.4
> >>>>
> >> and we
> >>
> >>>> need clients from them to generate SOAP
> >>>> rpc/lit or doc/lit instead of rpc/enc -
> does
> >>>>
> >> anyone know if
> >>
> >>>> the latter is the default for Axis 1.4
> >>>> and how it can be manipulated
> programmatically?
> >>>>
> >>>> Thanks
> >>>>
> >>>> Ruwan Linton wrote:
> >>>>
>
> >>>>> On Thu, Aug 27, 2009 at 11:21 PM,
> Deepal
> >>>>>
>
> >> jayasinghe
> >>
> >>>>>
>
> >>>> <deepalk@gmail.com
> >>>> <ma...@gmail.com>>
> >>>> wrote:
> >>>>
>
> >>>>> >
> >>>>> > No
> I can't, I guess
> >>>>>
>
> >> I
> >>
> >>>>>
>
> >>>> have explained why I can't use it as
> well,
> >>>>
>
> >>>>> >
> because I cannot
> >>>>>
>
> >>>> differentiate the undeployment call for
> the hot
> >>>>
>
> >>>>> >
> update and real
> >>>>>
>
> >>>> undeployment. Well, what Amila suggested
> will
> >>>>
> >> work
> >>
> >>>>
>
> >>>>> >
> though :-)
> >>>>> Of
> course you can if the
> >>>>>
>
> >> file
> >>
> >>>>>
>
> >>>> is there then that is hot-update else it
> >>>>
>
> >>>>> is un
> deployment.
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>>
> >
>
> >>
> >>>> >
> >>>>
>
> >>>>>
> >
>
> >>
> >>>> > I propose
> adding a update method
> >>>>
> >> to
> >>
> >>>> the Deployer interface or
> >>>>
>
> >>>>>
> >
>
> >>
> >>>> passing
> >>>>
>
> >>>>>
> >
>
> >>
> >>>> > the state as
> an argument,
> >>>>
>
> >>>>>
> >
>
> >> I
> >>
> >>>>>
>
> >>>> would consider undeploy as the update
> method you
> >>>>
> >> can do
> >>
> >>>>
>
> >>>>>
> whatever you
> >>>>>
> >
>
> >>
> >>>> want there, and
> you can just ignore
> >>>>
> >> at
> >>
> >>>> when it call deploy
> >>>>
>
> >>>>>
> method.
> >>>>>
> >
>
> >>
> >>>> (I know in
> undeploy method you only
> >>>>
> >> get
> >>
> >>>> the filename, but
> >>>>
>
> >>>>> since
> your
> >>>>>
> >
>
> >>
> >>>> deployer is domain
> specific you know
> >>>>
> >> what
> >>
> >>>> to do with the
> >>>>
>
> >>>>> file
> name)
> >>>>> >
> >>>>> >
> >>>>> >
> No, the issue is we
> >>>>>
>
> >> need
> >>
> >>>>>
>
> >>>> to invoke a different code in the case
> >>>>
>
> >>>>> of hot
> >>>>> >
> update.
> >>>>> Yes, as
> I mentioned
> >>>>>
>
> >> earlier if
> >>
> >>>>>
>
> >>>> the file is there then that is
> >>>>
>
> >>>>>
> hot-update, else
> >>>>>
>
> >>>> un-deployment. So it should not be a big
> issues.
> >>>>
>
> >>>>> >
> >>>>> >
> Anyway I feel I
> >>>>>
>
> >> should go
> >>
> >>>>>
>
> >>>> for a synapse deployer :-)
> >>>>
>
> >>>>> I
> though you already have
> >>>>>
>
> >>>> deployer for synapse.
> >>>>
>
> >>>>> I mean a new deployer framework
> >>>>>
>
> >> implementation, not an
> >>
> >>>>>
>
> >>>> deployer.. anyway synapse doesn't have a
> deployer
> >>>>
> >> yet.
> >>
> >>>>
>
> >>>>> Thanks,
> >>>>> Ruwan
> >>>>>
> >>>>> -- Ruwan Linton
> >>>>> Technical Lead & Product Manager;
> WSO2
> >>>>>
>
> >> ESB; http://wso2.org/esb
> >>
> >>>>> WSO2 Inc.; http://wso2.org
> >>>>> email: ruwan@wso2.com
> >>>>>
>
> >>>> <ma...@wso2.com>;
> >>>> cell: +94 77 341 3097
> >>>>
>
> >>>>> blog: http://ruwansblog.blogspot.com
> >>>>>
>
> >>>>
>
> >>>
>
> >>
> >
> >
> >
> >
>
>
Re: SOAP styles
Posted by Demetris <de...@ece.neu.edu>.
Hi Wolfgang,
thanks for the good info - I did see some of these links and I will
go over them.
We have an underlying p2p infrastructure that intercepts the SOAP
messages from
clients to servers without distrupting the operation of the upper layers
( so the soap
enginers and the WS implementations remain as is) and routes them across
peers.
Now that we are adding mobile peers in the mix, including CXF-based
ones, Axis2
ones etc. we are seeing some incompatability issues - for ex. CXF does
not handle
rcp/encoded styles. So how do you suggest we avoid the migration and
manage to
handle these issues?
Thanks again
WJ Krpelan wrote:
> Hi
> http://ws.apache.org/axis/java/reference.html
> hopefully answers your last question, dont expect bugfixes any more ;-)
> there is a migration guide for axis1 to axis2 webservices,
> http://ws.apache.org/axis2/1_5/migration.html
> dont think there is any special attention to preserving soap-styles however. its really not in the spirit nowadays, see
> http://ws-i.org/
> you didnt mention why you would want to migrate
> good luck,
> Wolfgang
>
> --- On Fri, 8/28/09, Demetris <de...@ece.neu.edu> wrote:
>
>
>> From: Demetris <de...@ece.neu.edu>
>> Subject: Re: SOAP styles
>> To: axis-dev@ws.apache.org
>> Date: Friday, August 28, 2009, 7:41 PM
>>
>> Well I will certainly push the notion of upgrading the
>> target servers but there are cases where the customer does
>> not
>> want to do that. So we NEED to deal with deprecated styles
>> - so the question will remain if Axis 1.4 can generate
>> one and only or multiple (even if deprecated) styles
>> programmatically?
>>
>> Cheers
>>
>> WJ Krpelan wrote:
>>
>>> Hi,
>>> all SOAP styles except doc/lit are kind of deprecated
>>>
>> by now and are no longer fully supported by most frameworks,
>> if at all.
>>
>>> You better migrate everything to doc/lit, resp.
>>>
>> doc/lit "wrapped" I suppose
>>
>>> Cheers, Wolfgang
>>>
>>>
>>> --- On Thu, 8/27/09, Demetris <de...@ece.neu.edu>
>>>
>> wrote:
>>
>>>
>>>
>>>> From: Demetris <de...@ece.neu.edu>
>>>> Subject: SOAP styles
>>>> To: axis-dev@ws.apache.org
>>>> Date: Thursday, August 27, 2009, 10:10 PM
>>>> Hi all,
>>>>
>>>> we have some legacy systems still using Axis 1.4
>>>>
>> and we
>>
>>>> need clients from them to generate SOAP
>>>> rpc/lit or doc/lit instead of rpc/enc - does
>>>>
>> anyone know if
>>
>>>> the latter is the default for Axis 1.4
>>>> and how it can be manipulated programmatically?
>>>>
>>>> Thanks
>>>>
>>>> Ruwan Linton wrote:
>>>>
>>>>
>>>>> On Thu, Aug 27, 2009 at 11:21 PM, Deepal
>>>>>
>> jayasinghe
>>
>>>>>
>>>>>
>>>> <deepalk@gmail.com
>>>> <ma...@gmail.com>>
>>>> wrote:
>>>>
>>>>
>>>>> >
>>>>> > No I can't, I guess
>>>>>
>> I
>>
>>>>>
>>>>>
>>>> have explained why I can't use it as well,
>>>>
>>>>
>>>>> > because I cannot
>>>>>
>>>>>
>>>> differentiate the undeployment call for the hot
>>>>
>>>>
>>>>> > update and real
>>>>>
>>>>>
>>>> undeployment. Well, what Amila suggested will
>>>>
>> work
>>
>>>>
>>>>
>>>>> > though :-)
>>>>> Of course you can if the
>>>>>
>> file
>>
>>>>>
>>>>>
>>>> is there then that is hot-update else it
>>>>
>>>>
>>>>> is un deployment.
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>
>>
>>>> >
>>>>
>>>>
>>>>> >
>>>>>
>>
>>
>>>> > I propose adding a update method
>>>>
>> to
>>
>>>> the Deployer interface or
>>>>
>>>>
>>>>> >
>>>>>
>>
>>
>>>> passing
>>>>
>>>>
>>>>> >
>>>>>
>>
>>
>>>> > the state as an argument,
>>>>
>>>>
>>>>> >
>>>>>
>> I
>>
>>>>>
>>>>>
>>>> would consider undeploy as the update method you
>>>>
>> can do
>>
>>>>
>>>>
>>>>> whatever you
>>>>> >
>>>>>
>>
>>
>>>> want there, and you can just ignore
>>>>
>> at
>>
>>>> when it call deploy
>>>>
>>>>
>>>>> method.
>>>>> >
>>>>>
>>
>>
>>>> (I know in undeploy method you only
>>>>
>> get
>>
>>>> the filename, but
>>>>
>>>>
>>>>> since your
>>>>> >
>>>>>
>>
>>
>>>> deployer is domain specific you know
>>>>
>> what
>>
>>>> to do with the
>>>>
>>>>
>>>>> file name)
>>>>> >
>>>>> >
>>>>> > No, the issue is we
>>>>>
>> need
>>
>>>>>
>>>>>
>>>> to invoke a different code in the case
>>>>
>>>>
>>>>> of hot
>>>>> > update.
>>>>> Yes, as I mentioned
>>>>>
>> earlier if
>>
>>>>>
>>>>>
>>>> the file is there then that is
>>>>
>>>>
>>>>> hot-update, else
>>>>>
>>>>>
>>>> un-deployment. So it should not be a big issues.
>>>>
>>>>
>>>>> >
>>>>> > Anyway I feel I
>>>>>
>> should go
>>
>>>>>
>>>>>
>>>> for a synapse deployer :-)
>>>>
>>>>
>>>>> I though you already have
>>>>>
>>>>>
>>>> deployer for synapse.
>>>>
>>>>
>>>>> I mean a new deployer framework
>>>>>
>> implementation, not an
>>
>>>>>
>>>>>
>>>> deployer.. anyway synapse doesn't have a deployer
>>>>
>> yet.
>>
>>>>
>>>>
>>>>> Thanks,
>>>>> Ruwan
>>>>>
>>>>> -- Ruwan Linton
>>>>> Technical Lead & Product Manager; WSO2
>>>>>
>> ESB; http://wso2.org/esb
>>
>>>>> WSO2 Inc.; http://wso2.org
>>>>> email: ruwan@wso2.com
>>>>>
>>>>>
>>>> <ma...@wso2.com>;
>>>> cell: +94 77 341 3097
>>>>
>>>>
>>>>> blog: http://ruwansblog.blogspot.com
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
>
Re: SOAP styles
Posted by WJ Krpelan <kr...@yahoo.com>.
Hi
http://ws.apache.org/axis/java/reference.html
hopefully answers your last question, dont expect bugfixes any more ;-)
there is a migration guide for axis1 to axis2 webservices,
http://ws.apache.org/axis2/1_5/migration.html
dont think there is any special attention to preserving soap-styles however. its really not in the spirit nowadays, see
http://ws-i.org/
you didnt mention why you would want to migrate
good luck,
Wolfgang
--- On Fri, 8/28/09, Demetris <de...@ece.neu.edu> wrote:
> From: Demetris <de...@ece.neu.edu>
> Subject: Re: SOAP styles
> To: axis-dev@ws.apache.org
> Date: Friday, August 28, 2009, 7:41 PM
>
> Well I will certainly push the notion of upgrading the
> target servers but there are cases where the customer does
> not
> want to do that. So we NEED to deal with deprecated styles
> - so the question will remain if Axis 1.4 can generate
> one and only or multiple (even if deprecated) styles
> programmatically?
>
> Cheers
>
> WJ Krpelan wrote:
> > Hi,
> > all SOAP styles except doc/lit are kind of deprecated
> by now and are no longer fully supported by most frameworks,
> if at all.
> > You better migrate everything to doc/lit, resp.
> doc/lit "wrapped" I suppose
> > Cheers, Wolfgang
> >
> >
> > --- On Thu, 8/27/09, Demetris <de...@ece.neu.edu>
> wrote:
> >
> >
> >> From: Demetris <de...@ece.neu.edu>
> >> Subject: SOAP styles
> >> To: axis-dev@ws.apache.org
> >> Date: Thursday, August 27, 2009, 10:10 PM
> >> Hi all,
> >>
> >> we have some legacy systems still using Axis 1.4
> and we
> >> need clients from them to generate SOAP
> >> rpc/lit or doc/lit instead of rpc/enc - does
> anyone know if
> >> the latter is the default for Axis 1.4
> >> and how it can be manipulated programmatically?
> >>
> >> Thanks
> >>
> >> Ruwan Linton wrote:
> >>
> >>> On Thu, Aug 27, 2009 at 11:21 PM, Deepal
> jayasinghe
> >>>
> >> <deepalk@gmail.com
> >> <ma...@gmail.com>>
> >> wrote:
> >>
> >>> >
> >>> > No I can't, I guess
> I
> >>>
> >> have explained why I can't use it as well,
> >>
> >>> > because I cannot
> >>>
> >> differentiate the undeployment call for the hot
> >>
> >>> > update and real
> >>>
> >> undeployment. Well, what Amila suggested will
> work
> >>
> >>> > though :-)
> >>> Of course you can if the
> file
> >>>
> >> is there then that is hot-update else it
> >>
> >>> is un deployment.
> >>> >
> >>> >
> >>> >
> >>> >
>
> >> >
> >>
> >>> >
>
> >> > I propose adding a update method
> to
> >> the Deployer interface or
> >>
> >>> >
>
> >> passing
> >>
> >>> >
>
> >> > the state as an argument,
> >>
> >>> >
> I
> >>>
> >> would consider undeploy as the update method you
> can do
> >>
> >>> whatever you
> >>> >
>
> >> want there, and you can just ignore
> at
> >> when it call deploy
> >>
> >>> method.
> >>> >
>
> >> (I know in undeploy method you only
> get
> >> the filename, but
> >>
> >>> since your
> >>> >
>
> >> deployer is domain specific you know
> what
> >> to do with the
> >>
> >>> file name)
> >>> >
> >>> >
> >>> > No, the issue is we
> need
> >>>
> >> to invoke a different code in the case
> >>
> >>> of hot
> >>> > update.
> >>> Yes, as I mentioned
> earlier if
> >>>
> >> the file is there then that is
> >>
> >>> hot-update, else
> >>>
> >> un-deployment. So it should not be a big issues.
> >>
> >>> >
> >>> > Anyway I feel I
> should go
> >>>
> >> for a synapse deployer :-)
> >>
> >>> I though you already have
> >>>
> >> deployer for synapse.
> >>
> >>> I mean a new deployer framework
> implementation, not an
> >>>
> >> deployer.. anyway synapse doesn't have a deployer
> yet.
> >>
> >>> Thanks,
> >>> Ruwan
> >>>
> >>> -- Ruwan Linton
> >>> Technical Lead & Product Manager; WSO2
> ESB; http://wso2.org/esb
> >>> WSO2 Inc.; http://wso2.org
> >>> email: ruwan@wso2.com
> >>>
> >> <ma...@wso2.com>;
> >> cell: +94 77 341 3097
> >>
> >>> blog: http://ruwansblog.blogspot.com
> >>>
> >>
> >
> >
> >
> >
>
>
Re: SOAP styles
Posted by Demetris <de...@ece.neu.edu>.
Well I will certainly push the notion of upgrading the target servers
but there are cases where the customer does not
want to do that. So we NEED to deal with deprecated styles - so the
question will remain if Axis 1.4 can generate
one and only or multiple (even if deprecated) styles programmatically?
Cheers
WJ Krpelan wrote:
> Hi,
> all SOAP styles except doc/lit are kind of deprecated by now and are no longer fully supported by most frameworks, if at all.
> You better migrate everything to doc/lit, resp. doc/lit "wrapped" I suppose
> Cheers, Wolfgang
>
>
> --- On Thu, 8/27/09, Demetris <de...@ece.neu.edu> wrote:
>
>
>> From: Demetris <de...@ece.neu.edu>
>> Subject: SOAP styles
>> To: axis-dev@ws.apache.org
>> Date: Thursday, August 27, 2009, 10:10 PM
>> Hi all,
>>
>> we have some legacy systems still using Axis 1.4 and we
>> need clients from them to generate SOAP
>> rpc/lit or doc/lit instead of rpc/enc - does anyone know if
>> the latter is the default for Axis 1.4
>> and how it can be manipulated programmatically?
>>
>> Thanks
>>
>> Ruwan Linton wrote:
>>
>>> On Thu, Aug 27, 2009 at 11:21 PM, Deepal jayasinghe
>>>
>> <deepalk@gmail.com
>> <ma...@gmail.com>>
>> wrote:
>>
>>> >
>>> > No I can't, I guess I
>>>
>> have explained why I can't use it as well,
>>
>>> > because I cannot
>>>
>> differentiate the undeployment call for the hot
>>
>>> > update and real
>>>
>> undeployment. Well, what Amila suggested will work
>>
>>> > though :-)
>>> Of course you can if the file
>>>
>> is there then that is hot-update else it
>>
>>> is un deployment.
>>> >
>>> >
>>> >
>>> >
>>>
>> >
>>
>>> >
>>>
>> > I propose adding a update method to
>> the Deployer interface or
>>
>>> >
>>>
>> passing
>>
>>> >
>>>
>> > the state as an argument,
>>
>>> > I
>>>
>> would consider undeploy as the update method you can do
>>
>>> whatever you
>>> >
>>>
>> want there, and you can just ignore at
>> when it call deploy
>>
>>> method.
>>> >
>>>
>> (I know in undeploy method you only get
>> the filename, but
>>
>>> since your
>>> >
>>>
>> deployer is domain specific you know what
>> to do with the
>>
>>> file name)
>>> >
>>> >
>>> > No, the issue is we need
>>>
>> to invoke a different code in the case
>>
>>> of hot
>>> > update.
>>> Yes, as I mentioned earlier if
>>>
>> the file is there then that is
>>
>>> hot-update, else
>>>
>> un-deployment. So it should not be a big issues.
>>
>>> >
>>> > Anyway I feel I should go
>>>
>> for a synapse deployer :-)
>>
>>> I though you already have
>>>
>> deployer for synapse.
>>
>>> I mean a new deployer framework implementation, not an
>>>
>> deployer.. anyway synapse doesn't have a deployer yet.
>>
>>> Thanks,
>>> Ruwan
>>>
>>> -- Ruwan Linton
>>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>>> WSO2 Inc.; http://wso2.org
>>> email: ruwan@wso2.com
>>>
>> <ma...@wso2.com>;
>> cell: +94 77 341 3097
>>
>>> blog: http://ruwansblog.blogspot.com
>>>
>>
>
>
>
>
>
Re: SOAP styles
Posted by WJ Krpelan <kr...@yahoo.com>.
Hi,
all SOAP styles except doc/lit are kind of deprecated by now and are no longer fully supported by most frameworks, if at all.
You better migrate everything to doc/lit, resp. doc/lit "wrapped" I suppose
Cheers, Wolfgang
--- On Thu, 8/27/09, Demetris <de...@ece.neu.edu> wrote:
> From: Demetris <de...@ece.neu.edu>
> Subject: SOAP styles
> To: axis-dev@ws.apache.org
> Date: Thursday, August 27, 2009, 10:10 PM
> Hi all,
>
> we have some legacy systems still using Axis 1.4 and we
> need clients from them to generate SOAP
> rpc/lit or doc/lit instead of rpc/enc - does anyone know if
> the latter is the default for Axis 1.4
> and how it can be manipulated programmatically?
>
> Thanks
>
> Ruwan Linton wrote:
> >
> >
> > On Thu, Aug 27, 2009 at 11:21 PM, Deepal jayasinghe
> <deepalk@gmail.com
> <ma...@gmail.com>>
> wrote:
> >
> >
> > >
> > > No I can't, I guess I
> have explained why I can't use it as well,
> > > because I cannot
> differentiate the undeployment call for the hot
> > > update and real
> undeployment. Well, what Amila suggested will work
> > > though :-)
> > Of course you can if the file
> is there then that is hot-update else it
> > is un deployment.
> > >
> > >
> > >
> > >
> >
> > >
> > I propose adding a update method to
> the Deployer interface or
> > >
> passing
> > >
> > the state as an argument,
> > > I
> would consider undeploy as the update method you can do
> > whatever you
> > >
> want there, and you can just ignore at
> when it call deploy
> > method.
> > >
> (I know in undeploy method you only get
> the filename, but
> > since your
> > >
> deployer is domain specific you know what
> to do with the
> > file name)
> > >
> > >
> > > No, the issue is we need
> to invoke a different code in the case
> > of hot
> > > update.
> > Yes, as I mentioned earlier if
> the file is there then that is
> > hot-update, else
> un-deployment. So it should not be a big issues.
> > >
> > > Anyway I feel I should go
> for a synapse deployer :-)
> > I though you already have
> deployer for synapse.
> >
> >
> > I mean a new deployer framework implementation, not an
> deployer.. anyway synapse doesn't have a deployer yet.
> >
> >
> > Thanks,
> > Ruwan
> >
> > -- Ruwan Linton
> > Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> > WSO2 Inc.; http://wso2.org
> > email: ruwan@wso2.com
> <ma...@wso2.com>;
> cell: +94 77 341 3097
> > blog: http://ruwansblog.blogspot.com
>
>
SOAP styles
Posted by Demetris <de...@ece.neu.edu>.
Hi all,
we have some legacy systems still using Axis 1.4 and we need clients
from them to generate SOAP
rpc/lit or doc/lit instead of rpc/enc - does anyone know if the latter
is the default for Axis 1.4
and how it can be manipulated programmatically?
Thanks
Ruwan Linton wrote:
>
>
> On Thu, Aug 27, 2009 at 11:21 PM, Deepal jayasinghe <deepalk@gmail.com
> <ma...@gmail.com>> wrote:
>
>
> >
> > No I can't, I guess I have explained why I can't use it as well,
> > because I cannot differentiate the undeployment call for the hot
> > update and real undeployment. Well, what Amila suggested will work
> > though :-)
> Of course you can if the file is there then that is hot-update else it
> is un deployment.
> >
> >
> >
> > >
> > > I propose adding a update method to the Deployer interface or
> > passing
> > > the state as an argument,
> > I would consider undeploy as the update method you can do
> whatever you
> > want there, and you can just ignore at when it call deploy
> method.
> > (I know in undeploy method you only get the filename, but
> since your
> > deployer is domain specific you know what to do with the
> file name)
> >
> >
> > No, the issue is we need to invoke a different code in the case
> of hot
> > update.
> Yes, as I mentioned earlier if the file is there then that is
> hot-update, else un-deployment. So it should not be a big issues.
> >
> > Anyway I feel I should go for a synapse deployer :-)
> I though you already have deployer for synapse.
>
>
> I mean a new deployer framework implementation, not an deployer..
> anyway synapse doesn't have a deployer yet.
>
>
> Thanks,
> Ruwan
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ruwan@wso2.com <ma...@wso2.com>; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Ruwan Linton <ru...@gmail.com>.
On Thu, Aug 27, 2009 at 11:21 PM, Deepal jayasinghe <de...@gmail.com>wrote:
>
> >
> > No I can't, I guess I have explained why I can't use it as well,
> > because I cannot differentiate the undeployment call for the hot
> > update and real undeployment. Well, what Amila suggested will work
> > though :-)
> Of course you can if the file is there then that is hot-update else it
> is un deployment.
> >
> >
> >
> > >
> > > I propose adding a update method to the Deployer interface or
> > passing
> > > the state as an argument,
> > I would consider undeploy as the update method you can do whatever
> you
> > want there, and you can just ignore at when it call deploy method.
> > (I know in undeploy method you only get the filename, but since your
> > deployer is domain specific you know what to do with the file name)
> >
> >
> > No, the issue is we need to invoke a different code in the case of hot
> > update.
> Yes, as I mentioned earlier if the file is there then that is
> hot-update, else un-deployment. So it should not be a big issues.
> >
> > Anyway I feel I should go for a synapse deployer :-)
> I though you already have deployer for synapse.
I mean a new deployer framework implementation, not an deployer.. anyway
synapse doesn't have a deployer yet.
Thanks,
Ruwan
--
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Deepal jayasinghe <de...@gmail.com>.
>
> No I can't, I guess I have explained why I can't use it as well,
> because I cannot differentiate the undeployment call for the hot
> update and real undeployment. Well, what Amila suggested will work
> though :-)
Of course you can if the file is there then that is hot-update else it
is un deployment.
>
>
>
> >
> > I propose adding a update method to the Deployer interface or
> passing
> > the state as an argument,
> I would consider undeploy as the update method you can do whatever you
> want there, and you can just ignore at when it call deploy method.
> (I know in undeploy method you only get the filename, but since your
> deployer is domain specific you know what to do with the file name)
>
>
> No, the issue is we need to invoke a different code in the case of hot
> update.
Yes, as I mentioned earlier if the file is there then that is
hot-update, else un-deployment. So it should not be a big issues.
>
> Anyway I feel I should go for a synapse deployer :-)
I though you already have deployer for synapse.
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Ruwan Linton <ru...@gmail.com>.
On Thu, Aug 27, 2009 at 8:32 PM, Deepal jayasinghe <de...@gmail.com>wrote:
> >
> > Let me first describe how Hot update works in axis2, correct me if I
> > am wrong but from what I have figured out so far, axis2 repository
> > listener task calls unDeploy method of the deployer implementation
> > first and then calls the deploy method again to deploy the artifact
> > with the changes.
> Yes that is correct.
> >
> > So this approach has two issues,
> >
> > 1. There is a considerable downtime of the artifact which is being
> > hot updated
> >
> In Axis2, specially in production hot deployment is not something people
> are going to use regularly. So downtown or hot-update is not an big
> issues (rather they will turn off both hot-deployment and hot-update)
> >
> > 1. There is no means of knowing the case where the undeploy method
> > being called, for example synapse needs to have a main sequence
> > for it to operate properly, so synapse has to force the user to
> > not to undeploy the main sequence while it should allow the user
> > to hot update it.
> >
> You can do this with your deployer.
No I can't, I guess I have explained why I can't use it as well, because I
cannot differentiate the undeployment call for the hot update and real
undeployment. Well, what Amila suggested will work though :-)
>
> >
> > I propose adding a update method to the Deployer interface or passing
> > the state as an argument,
> I would consider undeploy as the update method you can do whatever you
> want there, and you can just ignore at when it call deploy method.
> (I know in undeploy method you only get the filename, but since your
> deployer is domain specific you know what to do with the file name)
No, the issue is we need to invoke a different code in the case of hot
update.
Anyway I feel I should go for a synapse deployer :-)
Thanks,
Ruwan
>
> > we could use the DeploymentFileData class to provide the operation,
> Thanks,
> Deepal
>
--
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: [PROPOSAL] Axis2 Deployer behaviour on hot update
Posted by Deepal jayasinghe <de...@gmail.com>.
>
> Let me first describe how Hot update works in axis2, correct me if I
> am wrong but from what I have figured out so far, axis2 repository
> listener task calls unDeploy method of the deployer implementation
> first and then calls the deploy method again to deploy the artifact
> with the changes.
Yes that is correct.
>
> So this approach has two issues,
>
> 1. There is a considerable downtime of the artifact which is being
> hot updated
>
In Axis2, specially in production hot deployment is not something people
are going to use regularly. So downtown or hot-update is not an big
issues (rather they will turn off both hot-deployment and hot-update)
>
> 1. There is no means of knowing the case where the undeploy method
> being called, for example synapse needs to have a main sequence
> for it to operate properly, so synapse has to force the user to
> not to undeploy the main sequence while it should allow the user
> to hot update it.
>
You can do this with your deployer.
>
> I propose adding a update method to the Deployer interface or passing
> the state as an argument,
I would consider undeploy as the update method you can do whatever you
want there, and you can just ignore at when it call deploy method.
(I know in undeploy method you only get the filename, but since your
deployer is domain specific you know what to do with the file name)
> we could use the DeploymentFileData class to provide the operation,
Thanks,
Deepal