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]
