+1 On Tue, Sep 25, 2012 at 10:35 PM, Shammi Jayasinghe <[email protected]> wrote:
> > > On Mon, Sep 24, 2012 at 11:21 AM, Srinath Perera <[email protected]> wrote: > >> Does super tenant case works like before? (that means standalone user >> will not see the difference) >> >> How we were doing this with MB1? >> > > In MB1 we were storing queue names in the registry. In that we have used > the registry specific to the tenant. We have handled the permissions for > queue operations also. I think we can re use the same thing rather than > trying to implement the procedure again. We have the previous > implementation in messagebox component. > > Thanks > Shammi > > >> >> --Srinath >> >> >> >> On Sat, Sep 22, 2012 at 9:51 PM, Hasitha Hiranya <[email protected]>wrote: >> >>> Hi, >>> >>> In order to limit the visibility of Andes queues to only the tenant that >>> create that queue, following simple solution can be used in my opinion. >>> >>> 1. When creating a queue, just allow user to enter a name for the queue >>> (eg: *myQueue*). >>> 2. Check the domain of the user (eg:* a.com*) >>> 3. Append the domain in front of the queue name user enters seperating >>> with "/" (eg: *a.com/myQueue*) >>> 4. When showing queue list to the user just filter out the queues >>> belonging to his domain (using Java String operations) and show it with >>> only the name user had entered (*myQueue*). >>> 5. In that way, many tenants can share same physical broker. Everybody >>> will see they have their own queue (myQueue). >>> >>> But when subscribing for queues using *external JMS clients* etc. they >>> will have to use the real name (<domain_name>/<queue_name>). >>> Again if some person create a queue using an *external JMS client*, he >>> can create it with any name he want, which will end up with the result that >>> nobody will see the queue. >>> If we document it, knowing name of some tenant domain, anybody would be >>> able to create a queue in that domain space. >>> >>> I have implemented the above and despite above mentioned argument, it >>> is working fine. A similar way has been used for topics as well (written a >>> while ago). Will this be a good solution? Or is there any better ideas? >>> >>> Also, we have clustering support with andes implemented via Apache >>> Zookeeper messaging. This means, each tenant would like to have its own >>> Andes cluster in stratos? >>> >>> Thanks. >>> >>> -- >>> *Hasitha Abeykoon* >>> Software Engineer; WSO2, Inc.; http://wso2.com >>> *cell:* *+94 719363063* >>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>* * >>> * >>> * >>> >>> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> Senior Software Architect, WSO2 Inc. >> Visiting Faculty, University of Moratuwa >> Member, Apache Software Foundation >> Research Scientist, Lanka Software Foundation >> Blog: http://srinathsview.blogspot.com/ >> Photos: http://www.flickr.com/photos/hemapani/ >> Phone: 0772360902 >> > > > > -- > Best Regards,* > > Shammi Jayasinghe* > Senior Software Engineer; WSO2, Inc.; http://wso2.com, > mobile: +94 71 4493085 > > > -- ============================ Srinath Perera, Ph.D. Senior Software Architect, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
