Re: Dynamically create and register OSGi services from configurations
Ok, great, thanks Chetan for clarifying, then it seems ConfigurationFactory is
the right fit for my use case :)
Regards,
Tommaso
On 12/set/2013, at 06:16, Chetan Mehrotra wrote:
Hi Tommaso,
In general you should always use the ConfigurationFactory approach as
it is lot more simpler and easy to use.
ManagedServiceFactory is useful in few cases when you do not want your
bundle to depend on any other service runtime apart from core OSGi
framework. So suitable for infrastructure bundles like Logging ,
WebConsole or other OSGi spec implementations etc
Chetan Mehrotra
On Wed, Sep 11, 2013 at 7:06 PM, Tommaso Teofili teof...@adobe.com wrote:
Thanks a lot Chetan, that helps a lot!
In the mentioned link it seems both ConfigurationFactory and
ManagedServiceFactory could be used for that purpose, do you know if there
is any difference / advantage / disadvantage of using one instead of the
other?
Regards,
Tommaso
On 11/set/2013, at 11:53, Chetan Mehrotra wrote:
You can use Component based on ConfigurationFactory. Have a look at
[1] for one such example
[1] http://stackoverflow.com/a/15872131/1035417
Chetan Mehrotra
On Wed, Sep 11, 2013 at 3:05 PM, Tommaso Teofili teof...@adobe.com wrote:
Hi all,
that's probably a trivial question but I'm looking for the best practice
to create and register OSGi Services from configurations.
Here's an example scenario:
- I have an interface FooBar
- I have an implementation DefaultFooBarImpl
- I want to be able to specify a node like:
{
jcr:primaryType : sling:OsgiConfig,
name : foo
property-one : some-value,
property-two : another-value,
}
- and consequently I'd like a new instance of DefaultFooBarImpl to be
created and registered as a Service (of course implementing FooBar)
- then if a new configuration node is added:
{
jcr:primaryType : sling:OsgiConfig,
name : bar
property-one : some-other-value,
property-two : yet-another-value,
}
- another instance of DefaultFooBarImpl is created and registered as a
Service.
From my basic understanding (which may be obviously completely wrong) it
seems to me that the best fit for my use case would be using
ManagedServices [1] but I'm not too sure I should do that to handle
multiple instances.
Thanks in advance and have a nice day,
Tommaso
[1] :
http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedService.html
Re: Dynamically create and register OSGi services from configurations
Hi
Am 11.09.2013 um 15:36 schrieb Tommaso Teofili:
Thanks a lot Chetan, that helps a lot!
In the mentioned link it seems both ConfigurationFactory and
ManagedServiceFactory could be used for that purpose, do you know if there is
any difference / advantage / disadvantage of using one instead of the other?
I think you are mixing concepts ;-)
The configurationFactory attribute to the @Component annotation is
information to the Apache Felix SCR plugin on how to generate the Metatype
descriptor (to use the component name as the factoryPID instead of the service
PID) -- as such this has nothing to do with the core problem but is used to be
able to describe configuration for tools such as the Web Console.
The mechanism actually used is so-called factory configuration. This is
achieved in conjunction with the OSGi Installer when your configuration nodes
have specific names of the form factoryPid-alias, e.g.
com.adobe.granite.monitoring.impl.ScriptConfigImpl-cpu.
This creates factory configurations and Declarative services will create an
instance for each configuration instance.
Regards
Felix
Regards,
Tommaso
On 11/set/2013, at 11:53, Chetan Mehrotra wrote:
You can use Component based on ConfigurationFactory. Have a look at
[1] for one such example
[1] http://stackoverflow.com/a/15872131/1035417
Chetan Mehrotra
On Wed, Sep 11, 2013 at 3:05 PM, Tommaso Teofili teof...@adobe.com wrote:
Hi all,
that's probably a trivial question but I'm looking for the best practice to
create and register OSGi Services from configurations.
Here's an example scenario:
- I have an interface FooBar
- I have an implementation DefaultFooBarImpl
- I want to be able to specify a node like:
{
jcr:primaryType : sling:OsgiConfig,
name : foo
property-one : some-value,
property-two : another-value,
}
- and consequently I'd like a new instance of DefaultFooBarImpl to be
created and registered as a Service (of course implementing FooBar)
- then if a new configuration node is added:
{
jcr:primaryType : sling:OsgiConfig,
name : bar
property-one : some-other-value,
property-two : yet-another-value,
}
- another instance of DefaultFooBarImpl is created and registered as a
Service.
From my basic understanding (which may be obviously completely wrong) it
seems to me that the best fit for my use case would be using
ManagedServices [1] but I'm not too sure I should do that to handle
multiple instances.
Thanks in advance and have a nice day,
Tommaso
[1] :
http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedService.html
smime.p7s
Description: S/MIME cryptographic signature
Re: [Cassandra Resource] Create Update Sling Resource
Hi, From the results published at [1]. Reversing the order shows up that the create time is quite variable and probably not a function of the number of nodes within a collection, but probably a function the activity and buffering within the Cassandra layer. Reverse the order and the first 200 items written will have the lowest latency. Delete shows no difference in latency between 1K and 100M child nodes. That result is very encouraging, it means that performance is related the IO speed of the disks underneath Cassandra and not a function of the volume of data within Cassandra or the number of items within a collection. I think we have enough information, next is to implement access control. I'll start a new thread for that. Create Add 1 child node to a collection of 100M child nodes takes 26ms Add 1 child node to a collection of 10M child nodes takes 135ms Add 1 child node to a collection of 1M child nodes takes 109ms Add 1 child node to a collection of 100K child nodes takes 259ms Add 1 child node to a collection of 10K child nodes takes 225ms Add 1 child node to a collection of 1K child nodes takes 101ms Update Update 1 child node to a collection of 100M child nodes takes 44ms Update 1 child node to a collection of 10M child nodes takes 84ms Update 1 child node to a collection of 1M child nodes takes 258ms Update 1 child node to a collection of 100K child nodes takes 116ms Update 1 child node to a collection of 10K child nodes takes 231ms Update 1 child node to a collection of 1K child nodes takes 113ms Delete Delete 1 child node to a collection of 100M child nodes takes 17ms Delete 1 child node to a collection of 10M child nodes takes 11ms Delete 1 child node to a collection of 1M child nodes takes 7ms Delete 1 child node to a collection of 100K child nodes takes 7ms Delete 1 child node to a collection of 10K child nodes takes 6ms Delete 1 child node to a collection of 1K child nodes takes 7ms On 12 September 2013 05:06, Dishara Wijewardana ddwijeward...@gmail.com wrote: Hi Ian, Once you look at the results, let me know whether you want new tests run results. Also please advice how to proceed further. On Wed, Sep 11, 2013 at 7:59 PM, Dishara Wijewardana ddwijeward...@gmail.com wrote: Hi Ian, I attached the results.zip file to the JIRA which has the latest results as your expectation. I added new set of nodes in reverse order F, E ..A. But here I came across in a issue (which I didn't came up last time, may be due to my heap size), that hector fails to execute batches around 300-500.. So in my case batch size is 600. I googled for the issue (me.prettyprint.hector.api.exceptions.HectorException: All host pools marked down. Retry burden pushed out to client) and the solution was reduce the batch size. Hence I ran the test for each node separately. Hence In new results zip file each node has its own report file. I categorized them in two 3 main folders so that you can easily locate the results. i.,e folders _create, _update , _delete .. On Wed, Sep 11, 2013 at 1:58 PM, Ian Boston i...@tfd.co.uk wrote: Hi, Could you re-run the tests for create in the reverse order, largest collection first. The reason for this is in the detail of the tests adding resources to collection E (10M child nodes) is flat until half way through and then starts to rise which makes me thing there might be something else going on on the machine of the create mechanism. I would like to rule out that Cassandra is caching writes and the speed of update bears no correlation to collection size, but is a function of sustained load. I would also like to rule out any possibility that another OS level process started to hog resources in the latter part of your tests. The results do look comparatively flat all the way up 100M items in a collection. Once we have done this we can move on to providing access control, on items. Best Regards Ian On 11 September 2013 03:37, Dishara Wijewardana ddwijeward...@gmail.com wrote: Hi Ian, Sorry the delay, I found my self some battery problems with my laptop. I believe this is what you asked for. Here I added new 100 collections i.e 1a,3a,5a etc in each old collections and did CUD. Please advice what I should do next. CREATE [RESULT] Average Latency Under Node A(1K) = 11 (ms) [RESULT] Average Latency Under Node B(10K) = 9 (ms) [RESULT] Average Latency Under Node C(100K) = 13 (ms) [RESULT] Average Latency Under Node D(1M) = 23 (ms) [RESULT] Average Latency Under Node E(10M) = 110 (ms) [RESULT] Average Latency Under Node F(100M) = 306 (ms) [FIRST RUN] #TOTAL CALLS = 600 Total Average Latency = 79 (ms) UPDATE [RESULT] Average Latency Under Node A(1K) = 9 (ms) [RESULT] Average Latency Under Node B(10K) = 8 (ms) [RESULT] Average Latency Under Node C(100K) = 9 (ms) [RESULT] Average Latency Under Node D(1M) = 17 (ms) [RESULT] Average Latency Under Node E(10M) = 20 (ms) [RESULT] Average Latency
[GSoC2013] Access Control for Cassandra ResourceProvider
Hi Dishara, To make the Cassandra Resource Provider really useful I think we need to add access control. I think the best way of doing this is to borrow some concepts from Jackrabbit access control. Take a deep breath, and you will see why I left this till last. I think we should provide path base access control, which inherits from parent resources in the path. At every level there is a an ordered list of access control entries each access control entry (ACE) being either an allow entry or a deny entry. What is allowed or denied is defined in a 32bit bitmap with each bit representing 1 permission, so we can have upto 32 permissions. Each ACE specifies a single principal. So an ACL consists of a ordered list of ACE's each one bound to a principal. A user has a set of principals, so to resolve the ACL at any one path for a user the global ACL is filtered to contain only the ACE's with principals that the user has. Computing a final access control bitmap for a user at a location requires ordered processing of all the ACEs relevant to the user at the current path and then all ancestors. The pseudo algorithm to calculate the a grant bitmap and a deny bitmap at any level is: function getCurrentLevelBitmaps(currentPath): int grants = 0; int denies = 0; for all ACEs in the ACL at the currentPath: if the user has the principal of the current ACE: int toGrant = 0; int toDeny = 0; if the ACE is a grant: toGrant = the ACE bitmap; else: toDeny = the ACE bitmap; toGrant = toGrant ~denies; toDeny = toDeny ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denies); To combine what is granted at the child level with what is granted at a parent level we need to mask the parent level with the deny at the child level. eg toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; The simplest way of achieving this is to use recursion again in pseudo code: function buildAtLevel(): if not root level: (grantedAtParent, deniedAtParent) = buildAtLevel(getParentLevel(currentLevel)); (grants, denies) = getCurrentLevelBitmaps(currentLevel); toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denied); There are some optimisations you can apply here, and there are plenty of opportunities to cache intermediate bitmaps in memory. Just caching the ACL reduces resolution to bitwise operations. Principals Initially keep it simple. read = 0x01 write = 0x02 delete = 0x04 Storage of ACLs. - I suggest you store ACLs in their own Column Family, where the rowID is base64(sha1(path)) or whatever path - rowid encoding you have currently. IIRC Cassandra columns come out in the natural order of Strings order_principal_allow|deny and the value is the bitmap of permissions. Where order is 000 to 999 ( I really doubt that a single ACL will have 1000 ACEs ever) Once you have this working, we can wire it into the ResourceProvider or another Sling API. Does that make sense ? Ian
Re: Dynamically create and register OSGi services from configurations
On 12/set/2013, at 08:35, Felix Meschberger wrote:
Hi
Am 11.09.2013 um 15:36 schrieb Tommaso Teofili:
Thanks a lot Chetan, that helps a lot!
In the mentioned link it seems both ConfigurationFactory and
ManagedServiceFactory could be used for that purpose, do you know if there
is any difference / advantage / disadvantage of using one instead of the
other?
I think you are mixing concepts ;-)
The configurationFactory attribute to the @Component annotation is
information to the Apache Felix SCR plugin on how to generate the Metatype
descriptor (to use the component name as the factoryPID instead of the
service PID) -- as such this has nothing to do with the core problem but is
used to be able to describe configuration for tools such as the Web Console.
The mechanism actually used is so-called factory configuration. This is
achieved in conjunction with the OSGi Installer when your configuration nodes
have specific names of the form factoryPid-alias, e.g.
com.adobe.granite.monitoring.impl.ScriptConfigImpl-cpu.
This creates factory configurations and Declarative services will create an
instance for each configuration instance.
thanks Felix for clarifying, I'll let you know how it goes.
Regards,
Tommaso
Regards
Felix
Regards,
Tommaso
On 11/set/2013, at 11:53, Chetan Mehrotra wrote:
You can use Component based on ConfigurationFactory. Have a look at
[1] for one such example
[1] http://stackoverflow.com/a/15872131/1035417
Chetan Mehrotra
On Wed, Sep 11, 2013 at 3:05 PM, Tommaso Teofili teof...@adobe.com wrote:
Hi all,
that's probably a trivial question but I'm looking for the best practice
to create and register OSGi Services from configurations.
Here's an example scenario:
- I have an interface FooBar
- I have an implementation DefaultFooBarImpl
- I want to be able to specify a node like:
{
jcr:primaryType : sling:OsgiConfig,
name : foo
property-one : some-value,
property-two : another-value,
}
- and consequently I'd like a new instance of DefaultFooBarImpl to be
created and registered as a Service (of course implementing FooBar)
- then if a new configuration node is added:
{
jcr:primaryType : sling:OsgiConfig,
name : bar
property-one : some-other-value,
property-two : yet-another-value,
}
- another instance of DefaultFooBarImpl is created and registered as a
Service.
From my basic understanding (which may be obviously completely wrong) it
seems to me that the best fit for my use case would be using
ManagedServices [1] but I'm not too sure I should do that to handle
multiple instances.
Thanks in advance and have a nice day,
Tommaso
[1] :
http://www.osgi.org/javadoc/r4v42/org/osgi/service/cm/ManagedService.html
Re: [GSoC2013] Access Control for Cassandra ResourceProvider
Hi Ian On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston i...@tfd.co.uk wrote: Hi Dishara, To make the Cassandra Resource Provider really useful I think we need to add access control. I think the best way of doing this is to borrow some concepts from Jackrabbit access control. The following algorithms, and etc does sling already have any implementation of it. If so I can reuse them. Since sling has few providers I believe they probably have some common interface. Take a deep breath, and you will see why I left this till last. I think we should provide path base access control, which inherits from parent resources in the path. At every level there is a an ordered list of access control entries each access control entry (ACE) being either an allow entry or a deny entry. What is allowed or denied is defined in a 32bit bitmap with each bit representing 1 permission, so we can have upto 32 permissions. Each ACE specifies a single principal. So an ACL consists of a ordered list of ACE's each one bound to a principal. A user has a set of principals, so to resolve the ACL at any one path for a user the global ACL is filtered to contain only the ACE's with principals that the user has. Computing a final access control bitmap for a user at a location requires ordered processing of all the ACEs relevant to the user at the current path and then all ancestors. The pseudo algorithm to calculate the a grant bitmap and a deny bitmap at any level is: function getCurrentLevelBitmaps(currentPath): int grants = 0; int denies = 0; for all ACEs in the ACL at the currentPath: if the user has the principal of the current ACE: int toGrant = 0; int toDeny = 0; if the ACE is a grant: toGrant = the ACE bitmap; else: toDeny = the ACE bitmap; toGrant = toGrant ~denies; toDeny = toDeny ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denies); - Can you please tell me how to calculate the ACE bitmap ? - Also I will be more clear if you can provide a sample value for the input and output of this function ? i.e When currentPath= /content/cassandra/foo/bar it returns grants=? denies=? some actual values just for my understanding. To combine what is granted at the child level with what is granted at a parent level we need to mask the parent level with the deny at the child level. eg toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; The simplest way of achieving this is to use recursion again in pseudo code: function buildAtLevel(): if not root level: (grantedAtParent, deniedAtParent) = buildAtLevel(getParentLevel(currentLevel)); (grants, denies) = getCurrentLevelBitmaps(currentLevel); toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denied); There are some optimisations you can apply here, and there are plenty of opportunities to cache intermediate bitmaps in memory. Just caching the ACL reduces resolution to bitwise operations. Principals Initially keep it simple. read = 0x01 write = 0x02 delete = 0x04 Storage of ACLs. - I suggest you store ACLs in their own Column Family, where the rowID is base64(sha1(path)) or whatever path - rowid encoding you have currently. IIRC Cassandra columns come out in the natural order of Strings order_principal_allow|deny and the value is the bitmap of permissions. - If I understand you correctly is order_principal_allow|deny is one ACE ? If per row there can be a ACL, there should be one additional column by default called ACL and it will have a comma separated string which are set of ACEs. Correct me if I am wrong. - Who stores these ACEs ? any API? - i.e order is a auto increment number we have to do a additional read before storing ACE to check what is the last number for order. Where order is 000 to 999 ( I really doubt that a single ACL will have 1000 ACEs ever) Once you have this working, we can wire it into the ResourceProvider or another Sling API. Does that make sense ? Ian -- Thanks /Dishara
RE: [GSoC2013] Access Control for Cassandra ResourceProvider
Hi The common way to solve such an access control for a provider like the Cassandra resource provider is the new ResourceAccessSecurity service. This is implemented in the bundle resourceaccesssecurity (at this time only read rights will be checked). All you have to do is to implement the SPI ResourceAccessGate for the Cassandra provider and set the provider.useResourceAccessSecurity property to true for your ResourceProvider. By time resourceaccesssecurity will also implement create, modify And delete rights. Best regards mike -Original Message- From: Dishara Wijewardana [mailto:ddwijeward...@gmail.com] Sent: Thursday, September 12, 2013 2:25 PM To: dev@sling.apache.org Subject: Re: [GSoC2013] Access Control for Cassandra ResourceProvider Hi Ian On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston i...@tfd.co.uk wrote: Hi Dishara, To make the Cassandra Resource Provider really useful I think we need to add access control. I think the best way of doing this is to borrow some concepts from Jackrabbit access control. The following algorithms, and etc does sling already have any implementation of it. If so I can reuse them. Since sling has few providers I believe they probably have some common interface. Take a deep breath, and you will see why I left this till last. I think we should provide path base access control, which inherits from parent resources in the path. At every level there is a an ordered list of access control entries each access control entry (ACE) being either an allow entry or a deny entry. What is allowed or denied is defined in a 32bit bitmap with each bit representing 1 permission, so we can have upto 32 permissions. Each ACE specifies a single principal. So an ACL consists of a ordered list of ACE's each one bound to a principal. A user has a set of principals, so to resolve the ACL at any one path for a user the global ACL is filtered to contain only the ACE's with principals that the user has. Computing a final access control bitmap for a user at a location requires ordered processing of all the ACEs relevant to the user at the current path and then all ancestors. The pseudo algorithm to calculate the a grant bitmap and a deny bitmap at any level is: function getCurrentLevelBitmaps(currentPath): int grants = 0; int denies = 0; for all ACEs in the ACL at the currentPath: if the user has the principal of the current ACE: int toGrant = 0; int toDeny = 0; if the ACE is a grant: toGrant = the ACE bitmap; else: toDeny = the ACE bitmap; toGrant = toGrant ~denies; toDeny = toDeny ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denies); - Can you please tell me how to calculate the ACE bitmap ? - Also I will be more clear if you can provide a sample value for the input and output of this function ? i.e When currentPath= /content/cassandra/foo/bar it returns grants=? denies=? some actual values just for my understanding. To combine what is granted at the child level with what is granted at a parent level we need to mask the parent level with the deny at the child level. eg toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; The simplest way of achieving this is to use recursion again in pseudo code: function buildAtLevel(): if not root level: (grantedAtParent, deniedAtParent) = buildAtLevel(getParentLevel(currentLevel)); (grants, denies) = getCurrentLevelBitmaps(currentLevel); toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denied); There are some optimisations you can apply here, and there are plenty of opportunities to cache intermediate bitmaps in memory. Just caching the ACL reduces resolution to bitwise operations. Principals Initially keep it simple. read = 0x01 write = 0x02 delete = 0x04 Storage of ACLs. - I suggest you store ACLs in their own Column Family, where the rowID is base64(sha1(path)) or whatever path - rowid encoding you have currently. IIRC Cassandra columns come out in the natural order of Strings order_principal_allow|deny and the value is the bitmap of permissions. - If I understand you correctly is order_principal_allow|deny is one ACE ? If per row there can be a ACL, there should be one additional column by default called ACL and it will have a comma
[jira] [Created] (SLING-3056) [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse
Stefan Egli created SLING-3056: -- Summary: [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse Key: SLING-3056 URL: https://issues.apache.org/jira/browse/SLING-3056 Project: Sling Issue Type: Improvement Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli At the moment slingclipse contains extensions which require m2eclipse plugin to be installed as a hard-dependency from slingclipse. These extensions should, as a minimum, be separated from the remaining extensions, such that the user can choose to install them or not. Technically, the separation will be bundled into a separate feature -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-3056) [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse
Stefan Egli created SLING-3056: -- Summary: [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse Key: SLING-3056 URL: https://issues.apache.org/jira/browse/SLING-3056 Project: Sling Issue Type: Improvement Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli At the moment slingclipse contains extensions which require m2eclipse plugin to be installed as a hard-dependency from slingclipse. These extensions should, as a minimum, be separated from the remaining extensions, such that the user can choose to install them or not. Technically, the separation will be bundled into a separate feature -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [GSoC2013] Access Control for Cassandra ResourceProvider
From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston Hi Mike, Thanks for the pointer. On 12 September 2013 14:58, Mike Müller mike...@mysign.ch wrote: Hi The common way to solve such an access control for a provider like the Cassandra resource provider is the new ResourceAccessSecurity service. This is implemented in the bundle resourceaccesssecurity (at this time only read rights will be checked). Incidentally, how will other rights be enforced ? the update pattern is resource.adaptTo(ModifiableValueMap.class) would the adapter factory check that the current user has write access to the resource before they can get their hands on a ModifiableValueMap ? Yes, the resource will be wrapped to enforce the rights and the ModifiableValueMap as well... But as I said by now only read rights are enforced. The Cassandra resource provider is a very good example of a use case for this service. Best regards mike
[jira] [Resolved] (SLING-3056) [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse
[ https://issues.apache.org/jira/browse/SLING-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Egli resolved SLING-3056. Resolution: Fixed m2e-feature and eclipse-m2e-ui plugin added as a separation for this [Tooling] Separate m2eclipse dependent extensions from others, in slingclipse - Key: SLING-3056 URL: https://issues.apache.org/jira/browse/SLING-3056 Project: Sling Issue Type: Improvement Components: IDE Affects Versions: Sling Eclipse IDE 1.0.0 Reporter: Stefan Egli Assignee: Stefan Egli At the moment slingclipse contains extensions which require m2eclipse plugin to be installed as a hard-dependency from slingclipse. These extensions should, as a minimum, be separated from the remaining extensions, such that the user can choose to install them or not. Technically, the separation will be bundled into a separate feature -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Jenkins build became unstable: sling-trunk-1.6 #1887
See https://builds.apache.org/job/sling-trunk-1.6/1887/changes
Jenkins build became unstable: sling-trunk-1.6 » Apache Sling Resource-Based Discovery Service #1887
See https://builds.apache.org/job/sling-trunk-1.6/org.apache.sling$org.apache.sling.discovery.impl/1887/
[jira] [Updated] (SLING-2998) SlingAuthenticator fails because of pathInfo being null
[ https://issues.apache.org/jira/browse/SLING-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Lietz updated SLING-2998: Attachment: SLING-2998.2013-09-12.patch improved patch - concatenate servlet path and path info as their values are configuration/container dependent - remove LoginServlet.SERVLET_PATH.equals(pathInfo) check as paths of LoginServlet and LogoutServlet are added to PathBasedHolderCache SlingAuthenticator fails because of pathInfo being null --- Key: SLING-2998 URL: https://issues.apache.org/jira/browse/SLING-2998 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.1.2 Environment: Sling, CQ Reporter: Oliver Lietz Labels: security Attachments: SLING-2998.2013-09-12.patch, SLING-2998.patch - HttpServletRequest#getPathInfo():String returns null, use HttpServletRequest#getServletPath():String instead - path should never be changed to /, instead return anonymous credentials/false http://mail-archives.apache.org/mod_mbox/sling-users/201308.mbox/%3c201308021338.32243.apa...@oliverlietz.de%3e -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Jenkins build became unstable: sling-trunk-1.7 #263
See https://builds.apache.org/job/sling-trunk-1.7/263/changes
Jenkins build became unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #263
See https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.launchpad.testing/263/
Re: [GSoC2013] Access Control for Cassandra ResourceProvider
Hi On 12 September 2013 13:24, Dishara Wijewardana ddwijeward...@gmail.com wrote: Hi Ian On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston i...@tfd.co.uk wrote: Hi Dishara, To make the Cassandra Resource Provider really useful I think we need to add access control. I think the best way of doing this is to borrow some concepts from Jackrabbit access control. The following algorithms, and etc does sling already have any implementation of it. If so I can reuse them. Since sling has few providers I believe they probably have some common interface. There is not, or at least, not in a way that is exposed. There is an implementation inside Jackrabbit, but it is tightly coupled to Jackrabbit and more complex than the simple system below. Once implemented, this access control system may be exposed as a ResourceAccessGate, but since (IIRC) imposing anything other than read access control has not been done, the CassandraResourceProvider may use the implementation directly to impose write and delete. Take a deep breath, and you will see why I left this till last. I think we should provide path base access control, which inherits from parent resources in the path. At every level there is a an ordered list of access control entries each access control entry (ACE) being either an allow entry or a deny entry. What is allowed or denied is defined in a 32bit bitmap with each bit representing 1 permission, so we can have upto 32 permissions. Each ACE specifies a single principal. So an ACL consists of a ordered list of ACE's each one bound to a principal. A user has a set of principals, so to resolve the ACL at any one path for a user the global ACL is filtered to contain only the ACE's with principals that the user has. Computing a final access control bitmap for a user at a location requires ordered processing of all the ACEs relevant to the user at the current path and then all ancestors. The pseudo algorithm to calculate the a grant bitmap and a deny bitmap at any level is: function getCurrentLevelBitmaps(currentPath): int grants = 0; int denies = 0; for all ACEs in the ACL at the currentPath: if the user has the principal of the current ACE: int toGrant = 0; int toDeny = 0; if the ACE is a grant: toGrant = the ACE bitmap; else: toDeny = the ACE bitmap; toGrant = toGrant ~denies; toDeny = toDeny ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denies); - Can you please tell me how to calculate the ACE bitmap ? That is just the 32bit integer stored in the cassandra column representing the grant or deny for the principal eg Cassandra rowID : base64(sha1(/content/cassandra/foo/bar )) Columns: 0_everyone_allow : 0x01, 1_admin_allow : 0x07 Allows everyone read and admin everything at the path /cassandra - Also I will be more clear if you can provide a sample value for the input and output of this function ? i.e When currentPath= /content/cassandra/foo/bar it returns grants=? denies=? some actual values just for my understanding. Using the above for a random user (ie has the everyone principal): grants = 0x01 denies - 0x0 For the following values Cassandra rowID : base64(sha1(/content/cassandra/foo/bar )) Columns: 0_everyone_allow : 0x01, 1_admin_allow : 0x07, 2_ieb_deny : 0x01 results in dishara : grants = 0x01, denies = 0x00 ieb : grants = 0x00, denies = 0x01 admin: grants = 0x07, denies = 0x00 To combine what is granted at the child level with what is granted at a parent level we need to mask the parent level with the deny at the child level. eg toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; The simplest way of achieving this is to use recursion again in pseudo code: function buildAtLevel(): if not root level: (grantedAtParent, deniedAtParent) = buildAtLevel(getParentLevel(currentLevel)); (grants, denies) = getCurrentLevelBitmaps(currentLevel); toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denied); There are some optimisations you can apply here, and there are plenty of opportunities to cache intermediate bitmaps in memory. Just caching the ACL reduces resolution to bitwise operations. Principals Initially keep it simple. read = 0x01 write = 0x02 delete = 0x04 Storage of ACLs. - I suggest you store ACLs in their own Column Family, where the rowID is base64(sha1(path)) or whatever path - rowid encoding you have
Re: [GSoC2013] Access Control for Cassandra ResourceProvider
Hi Mike, Thanks for the pointer. On 12 September 2013 14:58, Mike Müller mike...@mysign.ch wrote: Hi The common way to solve such an access control for a provider like the Cassandra resource provider is the new ResourceAccessSecurity service. This is implemented in the bundle resourceaccesssecurity (at this time only read rights will be checked). Incidentally, how will other rights be enforced ? the update pattern is resource.adaptTo(ModifiableValueMap.class) would the adapter factory check that the current user has write access to the resource before they can get their hands on a ModifiableValueMap ? Best Regards Ian All you have to do is to implement the SPI ResourceAccessGate for the Cassandra provider and set the provider.useResourceAccessSecurity property to true for your ResourceProvider. By time resourceaccesssecurity will also implement create, modify And delete rights. Best regards mike -Original Message- From: Dishara Wijewardana [mailto:ddwijeward...@gmail.com] Sent: Thursday, September 12, 2013 2:25 PM To: dev@sling.apache.org Subject: Re: [GSoC2013] Access Control for Cassandra ResourceProvider Hi Ian On Thu, Sep 12, 2013 at 1:50 PM, Ian Boston i...@tfd.co.uk wrote: Hi Dishara, To make the Cassandra Resource Provider really useful I think we need to add access control. I think the best way of doing this is to borrow some concepts from Jackrabbit access control. The following algorithms, and etc does sling already have any implementation of it. If so I can reuse them. Since sling has few providers I believe they probably have some common interface. Take a deep breath, and you will see why I left this till last. I think we should provide path base access control, which inherits from parent resources in the path. At every level there is a an ordered list of access control entries each access control entry (ACE) being either an allow entry or a deny entry. What is allowed or denied is defined in a 32bit bitmap with each bit representing 1 permission, so we can have upto 32 permissions. Each ACE specifies a single principal. So an ACL consists of a ordered list of ACE's each one bound to a principal. A user has a set of principals, so to resolve the ACL at any one path for a user the global ACL is filtered to contain only the ACE's with principals that the user has. Computing a final access control bitmap for a user at a location requires ordered processing of all the ACEs relevant to the user at the current path and then all ancestors. The pseudo algorithm to calculate the a grant bitmap and a deny bitmap at any level is: function getCurrentLevelBitmaps(currentPath): int grants = 0; int denies = 0; for all ACEs in the ACL at the currentPath: if the user has the principal of the current ACE: int toGrant = 0; int toDeny = 0; if the ACE is a grant: toGrant = the ACE bitmap; else: toDeny = the ACE bitmap; toGrant = toGrant ~denies; toDeny = toDeny ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denies); - Can you please tell me how to calculate the ACE bitmap ? - Also I will be more clear if you can provide a sample value for the input and output of this function ? i.e When currentPath= /content/cassandra/foo/bar it returns grants=? denies=? some actual values just for my understanding. To combine what is granted at the child level with what is granted at a parent level we need to mask the parent level with the deny at the child level. eg toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; The simplest way of achieving this is to use recursion again in pseudo code: function buildAtLevel(): if not root level: (grantedAtParent, deniedAtParent) = buildAtLevel(getParentLevel(currentLevel)); (grants, denies) = getCurrentLevelBitmaps(currentLevel); toGrant = grantedAtParent ~denies; toDeny = deniedAtParent ~grants; grants = grants | toGrant; denied = denies | toDenies; return (grants, denied); There are some optimisations you can apply here, and there are plenty of opportunities to cache intermediate bitmaps in memory. Just caching the ACL reduces resolution to bitwise operations. Principals Initially keep it simple. read = 0x01 write = 0x02 delete = 0x04 Storage of ACLs. - I suggest you store ACLs in their own Column Family, where the rowID is base64(sha1(path)) or whatever path
[jira] [Created] (SLING-3057) Ghosted reference to dependent bundle after .java script compilation prevents complete uninstallation
Mark Adamcin created SLING-3057: --- Summary: Ghosted reference to dependent bundle after .java script compilation prevents complete uninstallation Key: SLING-3057 URL: https://issues.apache.org/jira/browse/SLING-3057 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting Java 2.0.6 Reporter: Mark Adamcin It appears that a lock is established on the cache directory of any bundle which is imported by a compiled .java script that prevents complete uninstallation of the dependent bundle, even after reinstallation of the bundle. The reinstalled bundle creates a new distinct cache folder under launchpad/felix, while the uninstalled cache folder remains write protected. Subsequent recompilation of the .java script after reinstallation of the bundle fails due to missing .class files, with the message: some class resolves to a package.. Restarting the Dynamic ClassLoader Support bundle or the Scripting Java bundle fails to force a recompilation using the newly reinstalled bundle, however a complete application restart will force the old cache folder to be garbage collected, and the .java script will compile correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
