[jira] [Created] (JCR-3766) Sync new IndexInfos file
Marcel Reutegger created JCR-3766: - Summary: Sync new IndexInfos file Key: JCR-3766 URL: https://issues.apache.org/jira/browse/JCR-3766 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor A new index infos file should be synced to disk to make sure it is written to stable store. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3766) Sync new IndexInfos file
[ https://issues.apache.org/jira/browse/JCR-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-3766: -- Attachment: JCR-3766.patch Proposed changes. We still have the 2.8 release pending and I'd rather not include this change that late. Sync new IndexInfos file Key: JCR-3766 URL: https://issues.apache.org/jira/browse/JCR-3766 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Attachments: JCR-3766.patch A new index infos file should be synced to disk to make sure it is written to stable store. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCR-3754) [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload
[ https://issues.apache.org/jira/browse/JCR-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated JCR-3754: - Resolution: Fixed Status: Resolved (was: Patch Available) Applied the patch in # http://svn.apache.org/r1585459 # http://svn.apache.org/r1585460 # http://svn.apache.org/r1585461 [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload - Key: JCR-3754 URL: https://issues.apache.org/jira/browse/JCR-3754 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-data Affects Versions: 2.7.5 Reporter: Shashank Gupta Assignee: Chetan Mehrotra Fix For: 2.7.6 Attachments: JCR-3754.patch, JCR-3754V2.patch Currently s3 asynchronous uploads are not retried after failure. since failed upload file is served from local cache it doesn't hamper datastore functionality. During next restart all accumulated failed upload files are uploaded to s3 in synchronized manner. There should be retry logic for failed s3 asynchronous upload so that failed uploads are not accumulated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCR-3754) [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload
[ https://issues.apache.org/jira/browse/JCR-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13961843#comment-13961843 ] Shashank Gupta commented on JCR-3754: - Thanks [~chetanm]. [jackrabbit-aws-ext] Add retry logic to S3 asynchronous failed upload - Key: JCR-3754 URL: https://issues.apache.org/jira/browse/JCR-3754 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-data Affects Versions: 2.7.5 Reporter: Shashank Gupta Assignee: Chetan Mehrotra Fix For: 2.7.6 Attachments: JCR-3754.patch, JCR-3754V2.patch Currently s3 asynchronous uploads are not retried after failure. since failed upload file is served from local cache it doesn't hamper datastore functionality. During next restart all accumulated failed upload files are uploaded to s3 in synchronized manner. There should be retry logic for failed s3 asynchronous upload so that failed uploads are not accumulated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCRVLT-45) Uninstallation of package fails if snapshot of sub-package is missing
[ https://issues.apache.org/jira/browse/JCRVLT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated JCRVLT-45: --- Summary: Uninstallation of package fails if snapshot of sub-package is missing (was: Uninstallation of package fails if older version contains same sub-package) Uninstallation of package fails if snapshot of sub-package is missing - Key: JCRVLT-45 URL: https://issues.apache.org/jira/browse/JCRVLT-45 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Tobias Bocanegra This problem occurs if there are two different versions of a top-level package both containing a sub-package with the same version. E.g. A: Root: V 1.2 Sub: V 1.0 B: Root: V 1.4 Sub: V 1.0 If we install A, then update B over it, then uninstall B, looks like sub-package 1.0 gets deleted in the repository as a result of this uninstall, which then trips up uninstallation of A because it again looks for sub-package 1.0 in the repo which can no longer be found. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (JCRVLT-45) Uninstallation of package fails if snapshot of sub-package is missing
[ https://issues.apache.org/jira/browse/JCRVLT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13962166#comment-13962166 ] Tobias Bocanegra commented on JCRVLT-45: it is even easier to reproduce, just uninstall the sub-package before uninstalling the package. Uninstallation of package fails if snapshot of sub-package is missing - Key: JCRVLT-45 URL: https://issues.apache.org/jira/browse/JCRVLT-45 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Tobias Bocanegra This problem occurs if there are two different versions of a top-level package both containing a sub-package with the same version. E.g. A: Root: V 1.2 Sub: V 1.0 B: Root: V 1.4 Sub: V 1.0 If we install A, then update B over it, then uninstall B, looks like sub-package 1.0 gets deleted in the repository as a result of this uninstall, which then trips up uninstallation of A because it again looks for sub-package 1.0 in the repo which can no longer be found. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCRVLT-47) Downgrading a package should also install previous versions of sub packages
Tobias Bocanegra created JCRVLT-47: -- Summary: Downgrading a package should also install previous versions of sub packages Key: JCRVLT-47 URL: https://issues.apache.org/jira/browse/JCRVLT-47 Project: Jackrabbit FileVault Issue Type: Bug Affects Versions: 3.1.2 Reporter: Tobias Bocanegra install: * main-1.0 ** sub-a-1.0 ** sub-b-1.0 then install: * main-1.1 ** sub-a-1.0 ** sub-b-1.1 then uninstall main-1.1 (recursive) should result in installed: main-1.0 sub-a-1.0 sub-b-1.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (JCRVLT-47) Downgrading a package should also install previous versions of sub packages
[ https://issues.apache.org/jira/browse/JCRVLT-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra updated JCRVLT-47: --- Description: install: * main-1.0 ** sub-a-1.0 ** sub-b-1.0 then install: * main-1.1 ** sub-a-1.0 ** sub-b-1.1 then uninstall main-1.1 (recursive) should result in installed: * main-1.0 * sub-a-1.0 * sub-b-1.0 was: install: * main-1.0 ** sub-a-1.0 ** sub-b-1.0 then install: * main-1.1 ** sub-a-1.0 ** sub-b-1.1 then uninstall main-1.1 (recursive) should result in installed: main-1.0 sub-a-1.0 sub-b-1.0 Downgrading a package should also install previous versions of sub packages --- Key: JCRVLT-47 URL: https://issues.apache.org/jira/browse/JCRVLT-47 Project: Jackrabbit FileVault Issue Type: Bug Affects Versions: 3.1.2 Reporter: Tobias Bocanegra install: * main-1.0 ** sub-a-1.0 ** sub-b-1.0 then install: * main-1.1 ** sub-a-1.0 ** sub-b-1.1 then uninstall main-1.1 (recursive) should result in installed: * main-1.0 * sub-a-1.0 * sub-b-1.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCRVLT-45) Uninstallation of package fails if snapshot of sub-package is missing
[ https://issues.apache.org/jira/browse/JCRVLT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra resolved JCRVLT-45. Resolution: Fixed Fix Version/s: 3.2 fixed by issuing a warning. Uninstallation of package fails if snapshot of sub-package is missing - Key: JCRVLT-45 URL: https://issues.apache.org/jira/browse/JCRVLT-45 Project: Jackrabbit FileVault Issue Type: Bug Reporter: Tobias Bocanegra Fix For: 3.2 This problem occurs if there are two different versions of a top-level package both containing a sub-package with the same version. E.g. A: Root: V 1.2 Sub: V 1.0 B: Root: V 1.4 Sub: V 1.0 If we install A, then update B over it, then uninstall B, looks like sub-package 1.0 gets deleted in the repository as a result of this uninstall, which then trips up uninstallation of A because it again looks for sub-package 1.0 in the repo which can no longer be found. -- This message was sent by Atlassian JIRA (v6.2#6252)
RE: [VOTE] Release Apache Jackrabbit Oak 0.20.0
Please vote on releasing this package as Apache Jackrabbit Oak 0.20.0. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. All checks OK. +1 Release this package as Apache Jackrabbit Oak 0.20.0 Regards Marcel
Re: Oak Training: MikroKernels/NodeStores
Hi, Since a CQ developer/architect must know the options for Oak architectures, I think the concepts of MikroKernel, NodeStore and DataStore must be part of the training. The actual APIs are not described in the training. Well, at the moment, the MicroKernel and the NodeStore are purely internal APIs. We might change (rename, whatever) those APIs without affecting the users. That's why I would not document those. What is important and needs to be documented is the Mongo storage, and the Tar storage. But I would not use purely internal names, and specially I would not use the names MikroKernel and NodeStore, because that already caused confusion in the past. The DataStore API is less internal, I think it's OK to document it. Even thought, it's also problematic. I would just document that there are multiple way to store binaries: store them in the file system as separate files, store them in the file system inside the Tar file (for the Tar storage), store them in S3, store them in MongoDB. The DataStore API is only used for two of those cases: separate files, and S3. The term MongoDataStore doesn't exist in Oak (not even internally), so please don't use it. Regards, Thomas On 03/04/14 16:27, Ben Zahler ben.zah...@inside-solutions.ch wrote: Hi Thomas, This is a AEM6 training that I am writing, so it¹s not exactly Oak documentation, and the delivery format is a word file. Of course if you feel that the documentation is helpful to the Oak project, it may make sense to add it to the oak-doc project. About your comments: Since a CQ developer/architect must know the options for Oak architectures, I think the concepts of MikroKernel, NodeStore and DataStore must be part of the training. The actual APIs are not described in the training. We describe MongoDB and the MongoDataStore in other sections of the training (complete training: http://oak.inside-apps.com/AEM6_OAK_Training_StudentWorkbook_v0-9-1.docx , review/oak4502). RDBMS was not described in deatil because afaik it is not yet officially supported as a storage in CQ (please correct me if I¹m wrong). Does that make sense for you? Regards, Ben Zahler Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43 http://www.inside-solutions.ch http://www.inside-solutions.ch/ Am 03.04.14 11:45 schrieb Thomas Mueller unter muel...@adobe.com: Hi, This is user documentation, right? We have a documentation project, oak-doc, could you provide patches for that instead of writing documentation in a Word file? I think that would be much more helpful. Otherwise, your documentation will very quickly get ouf of date, unless you spend a lot of time updating it. It's kind of the same as with copy paste of source code: it's problematic because it increases mainteance, as well as the probability of bugs. As for documentation that is product specific, I would keep that separate and link to the relevant sections of the Oak documentation. So far, both the NodeStore and the MicroKernel APIs are internal APIs, and they don't affect the users of Oak. So I wouldn't mention them in user documentation. If they are documented, that should be in internal architecture and design documentation, meant for Oak developers, and not Oak users. What I would document is MongoDB storage, RDBMS storage, Tar file storage. The advantages / disadvantages, features and limitations, how to configure them, and so on. I would keep the documentation about the Document format, in the MongoDB storage section, because that's useful to analyze existing repositories (to find problems, to get statistics, and so on). The details of that data model may change, but not that often, so I think it makes sense to document it. Regards, Thomas On 03/04/14 07:45, Ben Zahler ben.zah...@inside-solutions.ch wrote: Hi all, after the last review feedback, I have revised the section on MicroKernels and NodeStores. I would appreciate any feedback if this new version is both technically correct and also using the right terms. The revised section is available here (User : review/Pwd: oak4502): http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx Thanks in advance for any comments! Regards, Ben Zahler Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43 http://www.inside-solutions.chhttp://www.inside-solutions.ch/
Login with userid that contains windows domain
Hi, I have an issue where the user tries to login using credentials that include a windows domain in the userid attribute. for example: MYDOMAIN\toby. I'm not sure which layer should handle the domain part correctly, and I think it really depends on the setup. also, I'm not an AD expert and I don't know how the domain part would be used (selecting a forest in the AD server? or selecting a different AD server?). the problem especially comes up in SSO situations, where the LOGON_USER is passed over to a web application (e.g. sling) that then uses the repository. I can imagine the following scenarios: a) domain is constant/does not apply/or is a leftover from the SSO. so the repository does not (and never will) know about domains. b) domain is part of the userid, i.e. effectively selects a different user, but the same AD is used for all external accounts c) domain is part of the userid, but the domain also selects different ADs. Right now, the external login module does not handle the domain specifier specifically, so would behave like (b) - although I think that the user would not be found on the AD via LDAP the way it is currently built. Also, for a simple SSO setup, where the authentication module of the web app retrieves the LOGON_USER, I think the domain should be stripped there and not being included in the jcr credentials. so this basically boils down to the question: 1) should we implement special handling for windows domain specifiers in the login modules? 2) should we ignore windows domain and delegate this work to the JCR client? (e.g. the sling authentication handler should strip off the domain when building the jcr credentials) I think as long as the domain is not part of the user selection/authentication, we should do 2). WDYT? Regards, Toby
