hi
Some other confusion points that I have:
- Since export/import is per workspace basis and access
correct, xml-import is on a per workspace basis and you can only
import content to the workspace your session is attached to.
control+security+system data is stored above/outside the work space level
[right?],
no... it depends.
- those access control provider implementations in JR that write the ac
content to the repository are working on a per workspace level.
- with user management it depends on the implementation. initially in
JR 1.6 user data were kept in a dedicated workspace once for the whole
repository. since we were struggling with this approach @Day we
decided to create an alternative implementation that stores user data
separately for each workspace (-> UserPerWorkspaceSecurityManager,
-> UserPerWorkspaceUserManager). obviously importing user-data can
only be processed if we can assure that the import is operating on
the same workspace.
if importing users fails in you case, i suggest to verify if the
UserImporter is really initialized upon Session.importXML... that is
reason i consider to be most likely for the failure.
if this isn't the problem source i would like to ask you to provide
a simple testcase including a repository configuration that allows
us to reproduce the problem. see UserImporterTest.java for the testcases
present in the code base.
then how exactly is the other information supposed to be exported/imported.
non-protected jcr items will be processed during the regular import and
so are protected properties defined by the built-in node types
(jcr:uuid, jcr:mixinTypes, jcr:baseVersion, jcr:versionHistory etc.)
any other protected items will be ignored during import UNLESS there is
a importhandler configured that is able to handle those protected items.
by default jackrabbit defines handlers for access control content as
created by jackrabbit's accesscontrolprovider implementations and
user/group items.
hope that helps
angela
