Even if we have separate SynapseEnvrionmentServices for each tenant there is another problem.
Components should have access to the SynapseEnvironment +ConfigurationContext. First it can receive the ConfigurationContext from the tenant observers. But then it gets the SynapseEnvironmentService later. Component has to store the ConfigurationContext until SynapseEnvironmentService is available. For me this is not a good approach. Any ideas? Thanks, Supun.. On Thu, Sep 30, 2010 at 4:49 PM, Supun Kamburugamuva <[email protected]> wrote: > On Thu, Sep 30, 2010 at 12:34 PM, Ruwan Linton <[email protected]> wrote: >> On 9/30/10 12:10 PM, Sameera Jayasoma wrote: >> >> On Thu, Sep 30, 2010 at 12:00 PM, Supun Kamburugamuva <[email protected]> >> wrote: >>> >>> I guess the problem is not clear. Here is the problem. >>> >>> We have two observers listening on tenant creation. One is responsible >>> for creating a tenant specific synapse environment. Other one is >>> responsible for creating the mediation statistics. >>> >>> But the second case where we create the mediation statistics require >>> the synapse environment to be created. So you can see this is a order >>> problem. If the second observer gets called rfirst it doesn't have >>> access to the synapse environment. >>> >>> One solution would be to populate another SynapseEnvironmentService >>> for each tenant creation and remove the observer from the mediation >>> statistics. >> >> +1 for creating SynapseEnvironmentService server to notify the creation of >> SynapseEnvironment for a tenant. But I am wondering how can you remove it >> from the mediation stat component. >> >> Wait, when we have different SynapseEnvironmentServices, isn't it a risk, >> where other tenants can access my SynapseEnvironment Service. >> >> But in general, technically if we have a synapse env service, we need to >> have one for each and every tenant. :-( > > Yes, anyway a component author has full access to the system. So > having multiple SynapseEnv services is logical I think. With multiple > SynapseEnv services we can solve the ordering problem as well. > > Thanks, > Supun.. > >> >> Thanks, >> Ruwan >> >> Sameera >>> >>> Thanks, >>> Supun.. >>> >>> On Wed, Sep 29, 2010 at 4:58 PM, Afkham Azeez <[email protected]> wrote: >>> > First of all there is a spelling mistake; it should be Tenant >>> > not Tenent. >>> > You have to have a service component which depends >>> > on SynapseEnvironmentService. In the activate method of that SC, you can >>> > register the TenantStatisticsInitializer service/ >>> > Azeez >>> > >>> > >>> > >>> > On Wed, Sep 29, 2010 at 2:51 PM, Heshan Suriyaarachchi <[email protected]> >>> > wrote: >>> >> >>> >> Hi, >>> >> >>> >> I came across an issue while $subject. TenentStatisticsInitializer is >>> >> an >>> >> Axis2ConfigurationContextObserver. In the TenentStatisticsInitializer >>> >> class; >>> >> when we are creating a StatisticsReporterThread, we need to pass a >>> >> SynapseEnvironmentService. >>> >> >>> >> Synapse Environment is also created via an Observer. Therefore this >>> >> SynapseEnvironmentService may or may not be available at the time of >>> >> creating the StatisticsReporterThread. >>> >> >>> >> How should we address this? >>> >> >>> >> -- >>> >> Regards, >>> >> Heshan Suriyaarachchi >>> >> Software Engineer >>> >> WSO2 Inc.; http://wso2.com/ >>> >> >>> >> Blog: http://heshans.blogspot.com/ >>> >> >>> >> _______________________________________________ >>> >> Stratos-dev mailing list >>> >> [email protected] >>> >> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev >>> >> >>> > >>> > >>> > >>> > -- >>> > Afkham Azeez >>> > Senior Software Architect & Senior Manager; WSO2, Inc.; http://wso2.com, >>> > >>> > Member; Apache Software Foundation; http://www.apache.org/ >>> > email: [email protected] cell: +94 77 3320919 >>> > blog: http://blog.afkham.org >>> > twitter: http://twitter.com/afkham_azeez >>> > linked-in: http://lk.linkedin.com/in/afkhamazeez >>> > >>> > Lean . Enterprise . Middleware >>> > >>> > _______________________________________________ >>> > Stratos-dev mailing list >>> > [email protected] >>> > https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev >>> > >>> > >>> >>> >>> >>> -- >>> Supun Kamburugamuva >>> Technical Lead >>> WSO2 Inc.; http://wso2.org >>> E-mail: [email protected]; Mobile: +94 77 431 3585 >>> Blog: http://supunk.blogspot.com >>> >>> _______________________________________________ >>> Stratos-dev mailing list >>> [email protected] >>> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev >> >> >> >> -- >> Sameera Jayasoma >> Technical Lead and Product Manager, WSO2 Carbon >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> blog: http://tech.jayasoma.org >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Stratos-dev mailing list >> [email protected] >> https://wso2.org/cgi-bin/mailman/listinfo/stratos-dev >> >> >> -- >> Ruwan Linton >> Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb >> WSO2 Inc.; http://wso2.com >> >> Lean . Enterprise . Middleware >> >> phone: +1 408 754 7388 ext 51789 >> email: [email protected]; cell: +94 77 341 3097 >> blog: http://blog.ruwan.org >> linkedin: http://www.linkedin.com/in/ruwanlinton >> tweet: http://twitter.com/ruwanlinton >> > > > > -- > Supun Kamburugamuva > Technical Lead > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 431 3585 > Blog: http://supunk.blogspot.com > -- Supun Kamburugamuva Technical Lead WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 431 3585 Blog: http://supunk.blogspot.com _______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
