On Sun, Sep 19, 2010 at 1:51 PM, Supun Kamburugamuva <[email protected]> wrote:
> OK. Then the solution is to register listeners for tenant creation in > the components as well. > Yes. For example, we have already done this in the security-mgt component where we listen to ConfigurationContext creation event of tenants and act accordingly. Thanks, Thilina > > Supun.. > > On Sun, Sep 19, 2010 at 1:22 PM, Ruwan Linton <[email protected]> wrote: > > On 9/18/10 2:15 PM, Supun Kamburugamuva wrote: > >> > >> On Fri, Sep 17, 2010 at 4:58 PM, Ruwan Linton<[email protected]> wrote: > >>> > >>> Hmmm, I didn't get it. A component initialization, (which will happen > >>> most of the time inline with the system initialization) and a tenant > >>> initialization are 2 different things. > >>> > >>> A particular component would want to initialize itself at the system > >>> initialization while it might want to do certain task for each and > every > >>> tenant when it is initializing. Note that all tenants are using the > same > >>> instance of a given component. > >>> > >> Yes what you say is true but there is another side. There are things > >> that components should do when a tenant created as well. For example > >> proxy server admin registers a Axis Observer. This axis observer > >> should be registered for each and every tenant. At the moment > >> registration happens in the components activation method. But this > >> doesn't work across both multi tenant deployment and standalone > >> deployment. > >> > >> Another example is statistics collection. We have a singleton class to > >> collect the statistics. But ideally this component should get notified > >> when to create a instance of this statistics store rather than > >> creating at the start-up. > >> > >> Another example is registering synapse artifact deployers. Each and > >> every component should create the deployers when a tenant is created. > >> > >> We can create work arounds and get rid of these problems. For example > >> now proxy observer is created inside the stratos synapse management > >> component. But these are ugly and in the long term hard to maintain. > > > > I don't think we should unify these, which is because there could be > > components that needs to do separate things when carbon is getting > > initialized and a tenant is getting initialized. > > > > If we want to go for unified initialization, we need to design the API in > a > > manner it could differentiate the system and tenant initializations. One > > approach would be to pass-in the tenant id or something specific to that > > tenant and pass null for the system initialization. Then again that is a > bad > > API design :-) > > > > Ruwan > >> > >> Thanks, > >> Supun.. > >> > >> > >>> Ruwan > >>> > >>> On 9/17/10 2:22 PM, Srinath Perera wrote: > >>>> > >>>> +1 > >>>> > >>>> On Fri, Sep 17, 2010 at 2:16 PM, Supun Kamburugamuva<[email protected]> > >>>> wrote: > >>>>> > >>>>> I'm looking for way for a component to know when it has to initialize > >>>>> and when it has to destroy? > >>>>> > >>>>> At the moment we have two instances where a component should > >>>>> initialize. > >>>>> > >>>>> 1. Carbon initialization > >>>>> 2. Tenant initialization > >>>>> > >>>>> But these two are two different cases. From a component perspective > >>>>> they shouldn't know weather it is a system initialization or a tenant > >>>>> initialization. It would be great to have a unified mechanism across > >>>>> the platform for a component to decide when to initialize and when to > >>>>> destroy. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> -- > >>>>> 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 > >>>>> > >>>> > >>> > >>> -- > >>> 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 > >>> > >>> > >>> _______________________________________________ > >>> Carbon-dev mailing list > >>> [email protected] > >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-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 > > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > -- Thilina Mahesh Buddhika Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 77 44 88 727 blog : http://blog.thilinamb.com
_______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
