I just reviewed some of the Knopflerfish code in svn. I am wondering what the intent was with the UserAdmin service with regard to persisting data. For example, the Prefs Service has file persistence but nothing like that is there for UserAdmin. Is the idea that you write your own store and then in the UserAdmin Activator you populate the UserAdmin calling createRole with everything with your Roles, Users, and Groups? Or, should I write my own UserAdmin impl that is backed by my store? What's the best practice for getting a populated role db?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The story is simply that the KF UserAdmin currently lacks persistance. This is because the UA is more or less ripped from older code that relied on an entire management system to populate the UA db.
But that mgmt system is not included in KF (nor is it likely to appear since it's way too big and depends on too much other infrastructure as messaging and databases).
The bottom line is that some work is needed to implement persistance into the UA, either by modifying the current impl, or write it as a separate bundle. In a way I'd prefer a separate bundle.
/E
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem, I'll go ahead and do this. I have a similar service written already, that I was planning to turn into a bundle. At the same time, I wanted to make it use the UserAdmin interfaces and be an actual OSGi UserAdmin service.
If you could please expand a bit on your last statement regarding the 'separate bundle,' I would do my best to make it said way. Are you picturing a new UserAdminStore interface, that is implemented in a new bundle with whatever persistence, that is then retrieved and constructor injected by the UserAdmin Activator into the UserAdminImpl?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My orginal idea was to make the storage part for the UA exacly as you descibed, but I forgot that any UserAdminStore interface does not yet exists, nor is it possile to listen for "new user" events etc etc. So some kind of extra functionality must really be added to the existing UA impl.
If you start on this, I'll be happy to provide feedback and help.
/E
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just reviewed some of the Knopflerfish code in svn. I am wondering what the intent was with the UserAdmin service with regard to persisting data. For example, the Prefs Service has file persistence but nothing like that is there for UserAdmin. Is the idea that you write your own store and then in the UserAdmin Activator you populate the UserAdmin calling createRole with everything with your Roles, Users, and Groups? Or, should I write my own UserAdmin impl that is backed by my store? What's the best practice for getting a populated role db?
The story is simply that the KF UserAdmin currently lacks persistance. This is because the UA is more or less ripped from older code that relied on an entire management system to populate the UA db.
But that mgmt system is not included in KF (nor is it likely to appear since it's way too big and depends on too much other infrastructure as messaging and databases).
The bottom line is that some work is needed to implement persistance into the UA, either by modifying the current impl, or write it as a separate bundle. In a way I'd prefer a separate bundle.
/E
No problem, I'll go ahead and do this. I have a similar service written already, that I was planning to turn into a bundle. At the same time, I wanted to make it use the UserAdmin interfaces and be an actual OSGi UserAdmin service.
If you could please expand a bit on your last statement regarding the 'separate bundle,' I would do my best to make it said way. Are you picturing a new UserAdminStore interface, that is implemented in a new bundle with whatever persistence, that is then retrieved and constructor injected by the UserAdmin Activator into the UserAdminImpl?
Sorry for the delay.
My orginal idea was to make the storage part for the UA exacly as you descibed, but I forgot that any UserAdminStore interface does not yet exists, nor is it possile to listen for "new user" events etc etc. So some kind of extra functionality must really be added to the existing UA impl.
If you start on this, I'll be happy to provide feedback and help.
/E