Let me also explain the start/endTenantFlow API.
During an execution flow, sometimes you will need to switch from
supet-tenant mode to tenant mode, do some work as that tenant, and then get
back to super tenant mode. In such a scenario, you will do the following;
1. startTenantFlow
2. setTenantID & tenantDomain in the new CarbonContext data holder that
gets created when you start tenant flow
3. Do something
4. endTenantFlow
You need to ALWAYS follow the following template when you do that;
try{
PrivilegedCarbonContext.startTenantFlow();
PrivilegedCarbonContext privilegedCarbonContext =
PrivilegedCarbonContext.getCurrentContext()
privilegedCarbonContext.setTenantId(tenantId);
privilegedCarbonContext.setTenantDomain(tenantDomain);
// set other stuff like registry etc. if needed
doSomething();
} finally {
PrivilegedCarbonContext.endTenantFlow();
}
Inside the doSomething() method, now if you call
CarbonContext.getCurrentContext or
PrivilegedCarbonContext.getCurrentContext or threadLocalContext, you will
get the newly created data. The code that started the tenant flow is the
upstream code, and all the code that gets called after starting the
tenantFlow are the downstream code. One example where you may start a
tenant flow is when the super-tenant runs tasks on behalf of a tenant, then
it may have a loop, and within that loop, start a tenant flow for tenants,
run the task as that tenant, get back to super tenant mode (endTenantFlow),
switch back to another tenant(startTenantFlow), run the task of the 2nd
tenant, get back to super tenant mode, and so on.
Please note that in most situations you will not need to start a tenant
flow since you will not generally switch to tenant mode from ST mode.
Azeez
On Sat, Sep 22, 2012 at 9:02 AM, Supun Malinga <[email protected]> wrote:
> Hi,
>
> Below is the list of deployers using start/endTenantFlow.
>
> platform/branches/4.0.0/components$ fn *Deployer*.java | xargs grep -l
> "TenantFlow"
>
>
> ./data-services/org.wso2.carbon.dataservices.core/4.0.2/src/main/java/org/wso2/carbon/dataservices/core/DBDeployer.java
>
> ./data-services/org.wso2.carbon.dataservices.core/4.0.0/src/main/java/org/wso2/carbon/dataservices/core/DBDeployer.java
>
> ./data-services/org.wso2.carbon.dataservices.core/4.0.1/src/main/java/org/wso2/carbon/dataservices/core/DBDeployer.java
>
> ./jaggery/0.9.0.ALPHA2-wso2v1/jaggery-core/org.jaggeryjs.jaggery.app.mgt/src/main/java/org/jaggeryjs/jaggery/app/mgt/TomcatJaggeryWebappsDeployer.java
>
> ./jaggery/0.9.0.ALPHA2-wso2v2/jaggery-core/org.jaggeryjs.jaggery.app.mgt/src/main/java/org/jaggeryjs/jaggery/app/mgt/TomcatJaggeryWebappsDeployer.java
>
> ./jaggery/0.9.0-ALPHA1/jaggery-core/org.jaggeryjs.jaggery.app.mgt/0.9.0-ALPHA1/src/main/java/org/jaggeryjs/jaggery/app/mgt/TomcatJaggeryWebappsDeployer.java
>
> ./mashup/org.wso2.carbon.mashup.jsservices/4.0.2/src/main/java/org/wso2/carbon/mashup/jsservices/deployer/JSDeployer.java
>
> ./mashup/org.wso2.carbon.mashup.jsservices/4.0.0/src/main/java/org/wso2/carbon/mashup/jsservices/deployer/JSDeployer.java
>
> ./mashup/org.wso2.carbon.mashup.jsservices/4.0.1/src/main/java/org/wso2/carbon/mashup/jsservices/deployer/JSDeployer.java
>
> ./webapp-mgt/org.wso2.carbon.webapp.mgt/4.0.0/src/main/java/org/wso2/carbon/webapp/mgt/TomcatGenericWebappsDeployer.java
>
> ./webapp-mgt/org.wso2.carbon.webapp.mgt/4.0.1/src/main/java/org/wso2/carbon/webapp/mgt/TomcatGenericWebappsDeployer.java
>
> ./stratos/sample-installer/org.wso2.carbon.sample.installer/2.0.0/src/main/java/org/wso2/carbon/sample/installer/SampleDeployer.java
>
> ./stratos/sample-installer/org.wso2.carbon.sample.installer/2.0.2/src/main/java/org/wso2/carbon/sample/installer/SampleDeployer.java
>
> thanks,
>
> On Sat, Sep 22, 2012 at 8:17 AM, Anjana Fernando <[email protected]> wrote:
>
>> I see, the utility methods can be called from an arbitrary nested level
>> though, so parsing in the CarbonContext is not always possible .. for
>> example .. Deployer -> Initializing a Data Service -> Init. A Data Source
>> -> Lookup a Registry Resource -> Lookup Tenant Registry. It will be ugly in
>> that case to always parse a CarbonContext throughout all the
>> classes/methods being used. Anyways for data services use case it seems
>> I'll always get the requirement to get the tenant id etc.. in the
>> deployment, and not in any other places, so it wont be a problem. And yeah,
>> if I need it in any other message processing path in the future, I can use
>> the other approach.
>>
>> Cheers,
>> Anjana.
>>
>>
>> On Sat, Sep 22, 2012 at 12:24 AM, Afkham Azeez <[email protected]> wrote:
>>
>>> *PrivilegedCarbonContext.getThreadLocalCarbonContext() *performs
>>> better. This is because, PrivilegedCarbonContext.getContext() will first
>>> try to get the data from Axis2 MessageContext, failing which it will try
>>> ConfigurationContext & AxisConfiguration, and only finally try to get the
>>> data from the ThreadLocal variable. So, in cases like the deployers where
>>> you can be sure that the deployment scheduler thread would set the
>>> ThreadLocal data, you should directly call the getThreadLocalCarbonContext
>>> method.
>>>
>>> Generally, you should have an idea of what thread you are executing
>>> under. So in the case of util methods, it is better to resolve the
>>> CarbonContext outside that util method. In order to be able to properly
>>> retrieve a CC, anyway the relevant data should be available somewhere
>>> (ThreadLocal, AxisConfig, ConfigContext, MessageContext etc) so generally.
>>> If calling CarbonContext.getCurrentContext returns a CC with tenant ID = -1
>>> or tenant domain = null, that means, some up stream code had not populated
>>> the data needed for the CC, so you have to first look into fixing that
>>> issue.
>>>
>>> Azeez
>>>
>>> On Fri, Sep 21, 2012 at 10:43 PM, Anjana Fernando <[email protected]>wrote:
>>>
>>>> *PrivilegedCarbonContext.getThreadLocalCarbonContext()*
>>>
>>>
>>>
>>>
>>> --
>>> *Afkham Azeez*
>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> * <http://www.apache.org/>**
>>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919
>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
>>> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>>> *
>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>>> *
>>> *
>>> *Lean . Enterprise . Middleware*
>>>
>>>
>>
>>
>> --
>> *Anjana Fernando*
>> Associate Technical Lead
>> WSO2 Inc. | http://wso2.com
>> lean . enterprise . middleware
>>
>
>
>
> --
> Supun Malinga,
>
> Software Engineer,
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
> email - [email protected] <[email protected]>
> mobile - 071 56 91 321
>
>
--
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* <http://www.apache.org/>**
email: **[email protected]* <[email protected]>* cell: +94 77 3320919
blog: **http://blog.afkham.org* <http://blog.afkham.org>*
twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
