I agree with Azeez, component = middleware!, and component authors have to be aware about multi-tenancy. Note that components and deployable artifacts like aar, mar, ESB scripts are different. Authors of those do not need to be aware of multi-tenancy. --Srinath
On Sun, Sep 19, 2010 at 12:29 PM, Afkham Azeez <[email protected]> wrote: > > > > > On Sat, Sep 18, 2010 at 6:58 PM, Supun Kamburugamuva <[email protected]> wrote: >> >> On Sat, Sep 18, 2010 at 3:42 PM, Senaka Fernando <[email protected]> wrote: >> > Hi Supun, >> > >> > I believe that we already have the necessary infrastructure in place. >> > You >> > can register listeners (OSGi) to be called during tenant loading and >> > unloading. The initialization that needs to be done at the start-up can >> > be >> > done through SCR annotations. Isn't this sufficient? >> > >> The idea is that normal component authors shouldn't >> care about weather this component is used in a multi-tenant env or >> standalone env. > > What do you mean normal components authors? Do we have multiple levels of > component authors? A component is part of the middleware. The middleware is > the layer which abstracts the tenancy. Someone has to deal with the problem > at the end of the day, and that someone is the middleware author. We have > proper OSGi services in place to do this. Unless the underlying OSGi > framework itself becomes multitenanted, I don't see how your requirement can > be satisfied. > >> >> Thanks, >> Supun.. >> >> > Thanks, >> > Senaka. >> > >> > On Sat, Sep 18, 2010 at 2:15 PM, Supun Kamburugamuva <[email protected]> >> > 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. >> >> >> >> 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 >> >> > >> >> >> >> >> >> >> >> -- >> >> 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 >> > >> > >> > >> > -- >> > Senaka Fernando >> > Associate Technical Lead >> > WSO2 Inc. >> > E-mail: senaka AT wso2.com; Mobile: +94 77 322 1818 >> > >> > http://www.wso2.com/ - "Lean . Enterprise . Middleware" >> > >> > _______________________________________________ >> > Carbon-dev mailing list >> > [email protected] >> > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >> > >> >> >> >> -- >> 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 > > > > -- > 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 > > _______________________________________________ > Carbon-dev mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- ============================ Srinath Perera, Ph.D. WSO2 Inc. http://wso2.com Blog: http://srinathsview.blogspot.com/ _______________________________________________ Carbon-dev mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
