Hi Michele; I just check it and did not see that constructor is calling twice , btw any luck helping me to regenerate the problem.
Michele Mazzucco wrote: >Deepal, > >so maybe there's a problem, since two module instances are created. >I put a log print into the default module constructor (that I guess is >the same constructor called by Axis), and from the tomcat shell I can >see two logs. > >Michele > >Deepal Jayasinghe wrote: > > >>Hi Michele; >> >>Michele Mazzucco wrote: >> >> >> >>>Deepal, >>> >>>thanks very much for your clarifications. Just the last question ;): is >>>it possible (and necessary) to configure modules the same way or only >>>one module instance is created? >>> >>> >>> >>> >>There won't be two instance of same module , so you do not need to do >>any thing . At Axis2 start up time it create Module instance and keep >>that as long as server is running. >> >> >> >>>Thanks in advance, >>>Michele >>> >>>Deepal Jayasinghe wrote: >>> >>> >>> >>> >>>>Hi Michele; >>>>Yes , you can store states in service instance without having any >>>>problems . But if you store the state in service context external >>>>parties can access that good example could be a handler can change >>>>properties there in service context. >>>> >>>>Michele Mazzucco wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi Deepal, >>>>> >>>>>ok, if I've well understood from [1], if the scope is set to >>>>>"application" then only one instance of the service exists. So why >>>>>should I store the system state into the service context and not into an >>>>>instance variable (remember that there is only one service instance, and >>>>>thus the instance variable should be maintained across service >>>>>invocations). >>>>>Can you confirm my assumption, please? >>>>> >>>>>Thanks, >>>>>Michele >>>>> >>>>>[1] http://www.developer.com/open/article.php/10930_3589126_3 >>>>> >>>>>Deepal Jayasinghe wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Michele; >>>>>>First that depend on the scope that your service going to deploy , lets >>>>>>say your session scope is application then you can store state in >>>>>>service context coz there will be only one service context for that >>>>>>service. >>>>>> >>>>>>If the scope is SOAPSession then you can get into the same session by >>>>>>sending serviceGroupID , so as loan as clients send the service group >>>>>>id they can stay in one session, and you can keep state in either >>>>>>service group context or service context. >>>>>> >>>>>>Or else you can store your service state in configuration context , that >>>>>>is not the recommended way but you can still do that. >>>>>> >>>>>>Michele Mazzucco wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>how can I maintain the service state across different client invocations >>>>>>>(other than through static fields)? >>>>>>> >>>>>>> >>>>>>>Thanks in advance, >>>>>>>Michele >>>>>>> >>>>>>>--------------------------------------------------------------------- >>>>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>--------------------------------------------------------------------- >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >>> >>> >>> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- Thanks, Deepal ................................................................ ~Future is Open~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
