Re: [Carbon-dev] [Stratos-dev] Custom Realm Configurations in DB was Re: registry.core test failure
Hi, I added database column to store user-mgt.xml as blob and changed the relevant user.core and registry.core code, and fixed failing tests. On the trunk, user-mgt.xml is read from the database. Thanks, Dimuthu On Tue, Jan 4, 2011 at 10:09 AM, Senaka Fernando sen...@wso2.com wrote: On Tue, Jan 4, 2011 at 10:06 AM, Sumedha Rubasinghe sume...@wso2.comwrote: On Tue, Jan 4, 2011 at 9:58 AM, Senaka Fernando sen...@wso2.com wrote: On Tue, Jan 4, 2011 at 9:13 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: Hi, Currently the user.core stores realm configurations for each tenant in the registry. This creates dependency to the registry. We can remove this and still keep custom realm configurations by storing the non-bootstrap user-mgt.xml as a blob in the UM database. WDYT? Sounds Good. But, better to use SQLXML instead of BLOB. We are planning to take advantage of JDBC 4.0 with the upcoming releases. WDYT? There is a slight catch in using SQLXML when it comes to backward compatibility. OK, but this is totally new isn't it? It is why I suggested that we try this out, before attempting to make changes to the rest of the schema on a later date. Thanks, Senaka. /sumedha Thanks, Senaka. Thanks, Dimuthu On Tue, Jan 4, 2011 at 8:54 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: On Tue, Jan 4, 2011 at 8:40 AM, Dimuthu Leelarathne dimut...@wso2.com wrote: On Mon, Jan 3, 2011 at 4:54 PM, Afkham Azeez az...@wso2.com wrote: Asela, can we work on this and move the user management concerns to the UM, and get the trunk stabilized ASAP? Dimuthu, we also have to get rid of that hack where the user.core code reflectively calls registry.core. As you mentioned, the proper solution is to add a column to some user.core DB. Can we get that fixed as well. Yes. But this solution will remove the ability of having separate custom Realm configurations to different tenants. If this is not a requirement any longer we can go ahead. And the other option is to store the user-mgt.xml in the file system. Thanks, Dimuthu Thank you, Dimuthu Azeez On Mon, Jan 3, 2011 at 4:45 PM, Senaka Fernando sen...@wso2.comwrote: Hi Asela, IIRC we discussed this issue during the Stratos release. The issue here IIRC, is that the UM Kernel caches the tenant's user realm, but does not invalidate it when the realm configuration is updated. Can you have a look and get this sorted? Also, long term, we need to move the UM concerns out of the Registry Kernel. There are still a few hanging around (mostly the ones that have MT involved). Thanks, Senaka. On Mon, Jan 3, 2011 at 4:09 PM, Afkham Azeez az...@wso2.comwrote: --- Test set: org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 4.067 sec FAILURE! testCustomRealmConfiguration(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.103 sec FAILURE! junit.framework.AssertionFailedError: No exception in authorizing in tenant 1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testCustomRealmConfiguration(MultiTenantTest.java:346) testAddTenant(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.003 sec FAILURE! junit.framework.AssertionFailedError: tenants length should be 2 expected:3 but was:2 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testAddTenant(MultiTenantTest.java:411) -- *Afkham Azeez* Senior Software Architect Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation; **http://www.apache.org/*http://www.apache.org/ * email: **az...@wso2.com* az...@wso2.com* 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* ___ Carbon-dev mailing list Carbon-dev@wso2.org https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Senaka Fernando* Associate Technical Lead Product Manager - WSO2 G-Reg; WSO2, Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://www.linkedin.com/in/senakafernando *Lean . Enterprise .
Re: [Carbon-dev] [Stratos-dev] Custom Realm Configurations in DB was Re: registry.core test failure
On Tue, Jan 4, 2011 at 9:13 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: Hi, Currently the user.core stores realm configurations for each tenant in the registry. This creates dependency to the registry. We can remove this and still keep custom realm configurations by storing the non-bootstrap user-mgt.xml as a blob in the UM database. WDYT? Sounds Good. But, better to use SQLXML instead of BLOB. We are planning to take advantage of JDBC 4.0 with the upcoming releases. WDYT? Thanks, Senaka. Thanks, Dimuthu On Tue, Jan 4, 2011 at 8:54 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: On Tue, Jan 4, 2011 at 8:40 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: On Mon, Jan 3, 2011 at 4:54 PM, Afkham Azeez az...@wso2.com wrote: Asela, can we work on this and move the user management concerns to the UM, and get the trunk stabilized ASAP? Dimuthu, we also have to get rid of that hack where the user.core code reflectively calls registry.core. As you mentioned, the proper solution is to add a column to some user.core DB. Can we get that fixed as well. Yes. But this solution will remove the ability of having separate custom Realm configurations to different tenants. If this is not a requirement any longer we can go ahead. And the other option is to store the user-mgt.xml in the file system. Thanks, Dimuthu Thank you, Dimuthu Azeez On Mon, Jan 3, 2011 at 4:45 PM, Senaka Fernando sen...@wso2.comwrote: Hi Asela, IIRC we discussed this issue during the Stratos release. The issue here IIRC, is that the UM Kernel caches the tenant's user realm, but does not invalidate it when the realm configuration is updated. Can you have a look and get this sorted? Also, long term, we need to move the UM concerns out of the Registry Kernel. There are still a few hanging around (mostly the ones that have MT involved). Thanks, Senaka. On Mon, Jan 3, 2011 at 4:09 PM, Afkham Azeez az...@wso2.com wrote: --- Test set: org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 4.067 sec FAILURE! testCustomRealmConfiguration(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.103 sec FAILURE! junit.framework.AssertionFailedError: No exception in authorizing in tenant 1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testCustomRealmConfiguration(MultiTenantTest.java:346) testAddTenant(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.003 sec FAILURE! junit.framework.AssertionFailedError: tenants length should be 2 expected:3 but was:2 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testAddTenant(MultiTenantTest.java:411) -- *Afkham Azeez* Senior Software Architect Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation; **http://www.apache.org/*http://www.apache.org/ * email: **az...@wso2.com* az...@wso2.com* 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* ___ Carbon-dev mailing list Carbon-dev@wso2.org https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Senaka Fernando* Associate Technical Lead Product Manager - WSO2 G-Reg; WSO2, Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://www.linkedin.com/in/senakafernando *Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org https://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/*http://www.apache.org/ * email: **az...@wso2.com* az...@wso2.com* 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* ___ Carbon-dev mailing list Carbon-dev@wso2.org
Re: [Carbon-dev] [Stratos-dev] Custom Realm Configurations in DB was Re: registry.core test failure
On Tue, Jan 4, 2011 at 9:58 AM, Senaka Fernando sen...@wso2.com wrote: On Tue, Jan 4, 2011 at 9:13 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: Hi, Currently the user.core stores realm configurations for each tenant in the registry. This creates dependency to the registry. We can remove this and still keep custom realm configurations by storing the non-bootstrap user-mgt.xml as a blob in the UM database. WDYT? Sounds Good. But, better to use SQLXML instead of BLOB. We are planning to take advantage of JDBC 4.0 with the upcoming releases. WDYT? There is a slight catch in using SQLXML when it comes to backward compatibility. /sumedha Thanks, Senaka. Thanks, Dimuthu On Tue, Jan 4, 2011 at 8:54 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: On Tue, Jan 4, 2011 at 8:40 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: On Mon, Jan 3, 2011 at 4:54 PM, Afkham Azeez az...@wso2.com wrote: Asela, can we work on this and move the user management concerns to the UM, and get the trunk stabilized ASAP? Dimuthu, we also have to get rid of that hack where the user.core code reflectively calls registry.core. As you mentioned, the proper solution is to add a column to some user.core DB. Can we get that fixed as well. Yes. But this solution will remove the ability of having separate custom Realm configurations to different tenants. If this is not a requirement any longer we can go ahead. And the other option is to store the user-mgt.xml in the file system. Thanks, Dimuthu Thank you, Dimuthu Azeez On Mon, Jan 3, 2011 at 4:45 PM, Senaka Fernando sen...@wso2.comwrote: Hi Asela, IIRC we discussed this issue during the Stratos release. The issue here IIRC, is that the UM Kernel caches the tenant's user realm, but does not invalidate it when the realm configuration is updated. Can you have a look and get this sorted? Also, long term, we need to move the UM concerns out of the Registry Kernel. There are still a few hanging around (mostly the ones that have MT involved). Thanks, Senaka. On Mon, Jan 3, 2011 at 4:09 PM, Afkham Azeez az...@wso2.com wrote: --- Test set: org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 4.067 sec FAILURE! testCustomRealmConfiguration(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.103 sec FAILURE! junit.framework.AssertionFailedError: No exception in authorizing in tenant 1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testCustomRealmConfiguration(MultiTenantTest.java:346) testAddTenant(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.003 sec FAILURE! junit.framework.AssertionFailedError: tenants length should be 2 expected:3 but was:2 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testAddTenant(MultiTenantTest.java:411) -- *Afkham Azeez* Senior Software Architect Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation; **http://www.apache.org/*http://www.apache.org/ * email: **az...@wso2.com* az...@wso2.com* 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* ___ Carbon-dev mailing list Carbon-dev@wso2.org https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Senaka Fernando* Associate Technical Lead Product Manager - WSO2 G-Reg; WSO2, Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://www.linkedin.com/in/senakafernando *Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org https://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/*http://www.apache.org/ * email: **az...@wso2.com* az...@wso2.com* 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:
Re: [Carbon-dev] [Stratos-dev] Custom Realm Configurations in DB was Re: registry.core test failure
On Tue, Jan 4, 2011 at 10:06 AM, Sumedha Rubasinghe sume...@wso2.comwrote: On Tue, Jan 4, 2011 at 9:58 AM, Senaka Fernando sen...@wso2.com wrote: On Tue, Jan 4, 2011 at 9:13 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: Hi, Currently the user.core stores realm configurations for each tenant in the registry. This creates dependency to the registry. We can remove this and still keep custom realm configurations by storing the non-bootstrap user-mgt.xml as a blob in the UM database. WDYT? Sounds Good. But, better to use SQLXML instead of BLOB. We are planning to take advantage of JDBC 4.0 with the upcoming releases. WDYT? There is a slight catch in using SQLXML when it comes to backward compatibility. OK, but this is totally new isn't it? It is why I suggested that we try this out, before attempting to make changes to the rest of the schema on a later date. Thanks, Senaka. /sumedha Thanks, Senaka. Thanks, Dimuthu On Tue, Jan 4, 2011 at 8:54 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: On Tue, Jan 4, 2011 at 8:40 AM, Dimuthu Leelarathne dimut...@wso2.comwrote: On Mon, Jan 3, 2011 at 4:54 PM, Afkham Azeez az...@wso2.com wrote: Asela, can we work on this and move the user management concerns to the UM, and get the trunk stabilized ASAP? Dimuthu, we also have to get rid of that hack where the user.core code reflectively calls registry.core. As you mentioned, the proper solution is to add a column to some user.core DB. Can we get that fixed as well. Yes. But this solution will remove the ability of having separate custom Realm configurations to different tenants. If this is not a requirement any longer we can go ahead. And the other option is to store the user-mgt.xml in the file system. Thanks, Dimuthu Thank you, Dimuthu Azeez On Mon, Jan 3, 2011 at 4:45 PM, Senaka Fernando sen...@wso2.comwrote: Hi Asela, IIRC we discussed this issue during the Stratos release. The issue here IIRC, is that the UM Kernel caches the tenant's user realm, but does not invalidate it when the realm configuration is updated. Can you have a look and get this sorted? Also, long term, we need to move the UM concerns out of the Registry Kernel. There are still a few hanging around (mostly the ones that have MT involved). Thanks, Senaka. On Mon, Jan 3, 2011 at 4:09 PM, Afkham Azeez az...@wso2.com wrote: --- Test set: org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 4.067 sec FAILURE! testCustomRealmConfiguration(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.103 sec FAILURE! junit.framework.AssertionFailedError: No exception in authorizing in tenant 1 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testCustomRealmConfiguration(MultiTenantTest.java:346) testAddTenant(org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest) Time elapsed: 0.003 sec FAILURE! junit.framework.AssertionFailedError: tenants length should be 2 expected:3 but was:2 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:280) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:198) at org.wso2.carbon.registry.core.test.multitenant.MultiTenantTest.testAddTenant(MultiTenantTest.java:411) -- *Afkham Azeez* Senior Software Architect Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation; **http://www.apache.org/*http://www.apache.org/ * email: **az...@wso2.com* az...@wso2.com* 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* ___ Carbon-dev mailing list Carbon-dev@wso2.org https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Senaka Fernando* Associate Technical Lead Product Manager - WSO2 G-Reg; WSO2, Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org E-mail: senaka AT wso2.com **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://www.linkedin.com/in/senakafernando *Lean . Enterprise . Middleware ___ Carbon-dev mailing list Carbon-dev@wso2.org https://wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- *Afkham Azeez* Senior Software Architect Senior Manager; WSO2, Inc.; http://wso2.com, * * *Member; Apache Software Foundation;
