Re: VOTE: Migrate from Subversion to Git
[X] +1, migrate Jackrabbit to Git Regards Julian On Thu, Oct 12, 2023 at 6:57 AM Julian Reschke wrote: > > On 12.10.2023 06:55, Julian Reschke wrote: > > On 11.10.2023 19:58, Konrad Windszus wrote: > >> ... > > > > [X] +1, migrate Jackrabbit to Git > > > > Best regards, Julian > > ...and when we get to it, please be consistent with Oak (in naming the > dev branch "trunk"). > > Best regards, Julian
Re: [VOTE] Release Apache Jackrabbit 2.16.10
[X] +1 Release this package as Apache Jackrabbit 2.16.10 ...where... [INFO] Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) [INFO] OS name: "mac os x", version: "12.4", arch: "x86_64", family: "mac" [INFO] Java version: 11.0.14, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.14.jdk/Contents/Home [INFO] MAVEN_OPTS: Regards Julian On Wed, Sep 7, 2022 at 7:41 AM Julian Reschke wrote: > > Am 07.09.2022 um 07:38 schrieb Julian Reschke: > > ... > > [X] +1 Release this package as Apache Jackrabbit 2.16.10 > > ...where... > > > [INFO] Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > > [INFO] OS name: "windows 10", version: "10.0", arch: "amd64", family: > > "windows" > > [INFO] Java version: 11.0.15, vendor: Oracle Corporation, runtime: > > C:\usr\local\jdk-11.0.15 > > [INFO] MAVEN_OPTS: -Xmx2g > > Best regards, Julian
Re: Adjustments of check-release.sh for multi module releases
Hi Combining the empty local repo with a fallback to the "full" local repo can speed things up a lot. I have used this strategy in the past to "fill" minimal customer-specific local repos to enable offline work. That requires a profile and thus a settings.xml, but that should all be scriptable I suppose. The only difficulty could be if someone doesn't have their local repo in the default location. An alternative to providing a settings.xml could be to set a profile name for the "check"-build and provide documentation on how to configure a profile that uses the local repository as a remote repository for the build. That would allow everyone to op-in to having a fast build while keeping local repositories clean (the temporary local repo would obviously need to be removed after the build). WDYT? Regards Julian On Mon, Aug 3, 2020 at 12:19 PM Robert Munteanu wrote: > > On Mon, 2020-08-03 at 12:15 +0200, Konrad Windszus wrote: > > We can even leverage a custom (empty) local repo via "- > > Dmaven.repo.local" which can be thrown away after release > > verification. > > That way one would notice references which are no longer available > > publically (for whatever reason). > > That would delay the release check though, as you would need to > > redownload all necessary plugins/dependencies > > Hm, that sounds interesting. The question is what is the relative > increaase of the check time. I run the validation in a console and then > switch away since it takes too long to wait for it. > > If it's 10-20% longer I think that's fine. If it's 5x longer it's > probably a no-go. > > Thanks, > Robert >
Re: New Jackrabbit Committer: Mohit Kataria
Welcome Mohit! Regards Julian On Wed, Aug 14, 2019 at 3:25 PM Woonsan Ko wrote: > > Welcome, Mohit! > > Cheers, > > Woonsan > > On Wed, Aug 14, 2019 at 2:31 AM Tommaso Teofili > wrote: > > > > Welcome to the team Mohit! > > > > Regards, > > Tommaso > > > > On Thu, 8 Aug 2019 at 08:33, Marcel Reutegger wrote: > >> > >> Hi, > >> > >> Please welcome Mohit Kataria as a new committer and PMC member of > >> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to > >> offer Mohit committership based on his contributions. I'm happy to > >> announce that he accepted the offer and that all the related > >> administrative work has now been taken care of. > >> > >> Welcome to the team, Mohit! > >> > >> Regards > >> Marcel > >>
Re: New Jackrabbit Committer: Nitin Gupta
Welcome Nitin! Regards Julian On Wed, Aug 14, 2019 at 3:24 PM Woonsan Ko wrote: > > Welcome, Nitin! > > Cheers, > > Woonsan > > On Wed, Aug 14, 2019 at 2:30 AM Tommaso Teofili > wrote: > > > > Welcome to the team Nitin! > > > > Regards, > > Tommaso > > > > On Thu, 8 Aug 2019 at 08:31, Marcel Reutegger wrote: > >> > >> Hi, > >> > >> Please welcome Nitin Gupta as a new committer and PMC member of > >> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to > >> offer Nitin committership based on his contributions. I'm happy to > >> announce that he accepted the offer and that all the related > >> administrative work has now been taken care of. > >> > >> Welcome to the team, Nitin! > >> > >> Regards > >> Marcel > >>
Re: New Jackrabbit Committer: Dominik Süß
Welcome, Dominik! Regards Julian On Thu, Jul 25, 2019 at 5:17 PM Dominik Süß wrote: > > Hello everyone, > > Like Konrad I wanted to thank a lot for the invitation. > > > Here a short version about my own background. I started working as Integrator > for AEM/CQ and that way getting in touch with Jackrabbit in 2007 and became > an active member mostly of the Sling Community soon after. In 2015 I joined > AEM engineering and by that rather worked more on the details of the stack > and began to contribute once in a while. > > Since a few years my focus is mostly around deployment aspects as content > that links directly to application that may change over time or the > installation and necessary transformation of content over time without having > negative impact on the availability of a system. > > > I share Konrads interest in filevault but also correlated topics such as > composite node-store, oak-upgrade and any other mechanism that link to > automation of changes in Jackrabbit. > > > Cheers > > Dominik > > > On Thu, Jul 25, 2019 at 4:02 PM Woonsan Ko wrote: >> >> Welcome, Dominik! >> >> Cheers, >> >> Woonsan >> >> On Thu, Jul 25, 2019 at 9:54 AM Marcel Reutegger wrote: >> > >> > Hi, >> > >> > Please welcome Dominik Süß as a new committer and PMC member of >> > the Apache Jackrabbit project. The Jackrabbit PMC recently decided to >> > offer Dominik committership based on his contributions. I'm happy to >> > announce that he accepted the offer and that all the related >> > administrative work has now been taken care of. >> > >> > Welcome to the team, Dominik! >> > >> > Regards >> > Marcel
Re: Naming convention for unstable releases
+1 for any qualifier indicating "unstable" releases. Regards Julian On Tue, Oct 17, 2017 at 7:28 AM, Julian Reschke wrote: > Hi there, > > everybody over here knows that odd-numbered releases are unstable, taken > from trunk. > > However, apparently not all of our users know that. > > Should we consider to label them accordingly in the future? Such as > > 1.9.0-EXPERIMENTAL > > instead of > > 1.9.0 > > ? > > Best regards, Julian > > (cc'ing jackrabbit-dev because we'd want to be consistent)
Re: New Jackrabbit Committer: Robert Munteanu
Welcome Robert! Keep up the good work! Regards Julian On Tue, May 23, 2017 at 1:08 PM, Robert Munteanu wrote: > Hi, > > On Mon, 2017-05-22 at 13:53 +0200, Michael Dürig wrote: >> Hi, >> >> Please welcome Robert as a new committer and PMC member of the >> Apache >> Jackrabbit project. The Jackrabbit PMC recently decided to offer >> Robert >> committership based on his contributions. I'm happy to announce that >> he >> accepted the offer and that all the related administrative work has >> now >> been taken care of. >> >> Welcome to the team, Robert! > > Thank you for the invitation and for the welcome. > > I'm looking forward to continuing my contributions with a new hat on :- > ) > > Robert
Re: Slowness while multiple uploads
If I read the code correctly, you only logout the session in a catch
block. Assuming the code is otherwise sane, that would indicate a
session leak, because most sessions are not logged out. That could
also explain the gradual slowdown over two days.
You have to always logout JCR sessions that you create via
repository.login(...). As Clay mentioned, you should use a
try..finally construct with logout in the finally block.
Regards
Julian
On Tue, Jan 10, 2017 at 6:18 AM, Clay Ferguson wrote:
> * First determine if the time is being spent in the streaming, or the JCR
> saving, so you know what problem to solve
>
> * Use System.currentMillis() or whatever to capture the begin+end times of
> different sections, and subtract them to get the time. Then keep
> a running total of those times. Then at end log out the total times, to see
> what part is slow (low tech profiler!)
>
> * Close your stream in a finally block.
>
> * User Buffered stream (input stream)
>
> * Don't save 1000s of times into the same session if you can avoid it.
> Create new sessions every 100th time or so and close out the previous
> session to be sure
> it isn't draining resources.
>
> * Print amount of free memory after calling GC(), like every 100th file, to
> see if it's leaking, running low. (again low-tech profiler!)
>
>
> Best regards,
> Clay Ferguson
> wcl...@gmail.com
>
>
> On Mon, Jan 9, 2017 at 12:03 PM, ravindar.singh
> wrote:
>>
>> Please check the below code. correct me if any thing wrong.
>>
>> After restarting the server it is quit normal then 1 day later it is
>> taking
>> 2 min to upload the file.
>>
>> private void contentStroe(UploadParameters repContent, List
>> configParams,
>> String workspace, String table) throws Exception{
>> Session repSession = null;
>> Repository repository = null;
>> try{
>> String path = repContent.getModule();
>> Map nodeProps = repContent.getParams();
>> for(ProjectProp prop: configParams){
>> if("1".equals(prop.getMppFolderYn())){
>> Object value =
>> nodeProps.get(prop.getMppParameterName());
>> if(value!=null)
>> path += "/" + value.toString();
>> }
>> }
>> logger.info("Path => "+path);
>> Calendar cal = Calendar.getInstance();
>> DateFormat dateFormat = new SimpleDateFormat("/MM/dd
>> HH:mm:ss");
>> repository = getRepository();
>> repSession = repository.login(new SimpleCredentials("admin",
>> "admin".toCharArray()), workspace);
>> Node folderNode = repSession.getRootNode();
>> String[] docPath = path.split("/");
>> long docSize = 0;
>> String docExtn = "", docVersion = "";
>> for(String nodes : docPath){
>> if (folderNode.hasNode(nodes)) {
>> folderNode = folderNode.getNode(nodes);
>> } else {
>> boolean versioned = isVersioned(folderNode);
>> if(versioned)
>> folderNode.checkout();
>> Node subFolderNode = folderNode.addNode(nodes);
>> subFolderNode.addMixin("mix:referenceable");
>> subFolderNode.addMixin("mix:versionable");
>> subFolderNode.setProperty("Created",
>> dateFormat.format(cal.getTime()));
>> subFolderNode.setProperty("CreatedBy",
>> repContent.getUpdUser());
>> repSession.save();
>> if(versioned)
>> folderNode.checkin();
>> subFolderNode.checkin();
>> folderNode = folderNode.getNode(nodes);
>> }
>> }
>>
>> if(repContent.getUpdFile()!=null){
>> String name = repContent.getUpdFileName();
>> docExtn = name.substring(name.lastIndexOf(".")+1);
>> }
>> repContent.setDocName(repContent.getDocName()+"."+docExtn);
>> logger.info("File Store
>> Path=>"+path+"/"+repContent.getDocName());
>> if (folderNode.hasNode(repContent.getDocName())) {
>> boolean versioned = isVersioned(folderNode);
>> if(versioned)
>> folderNode.checkout();
>> Node fileNode =
>> folderNode.getNode(repContent.getDocName());
>> boolean fileversioned = isVersioned(fileNode);
>> if(fileversioned)
>> fileNode.checkout();
>> fileNode.setProperty("lastModified",
>> dateFormat.format(cal.getTime()));
>> fileNode.setProperty("UpdateBy", repContent.getUpdUser());
>> docSize = addRepoContents(repSession, fileNode,
>> repContent,
>> configParams);
>> repSession.save();
>> if(versioned)
>>
Re: New Jackrabbit Committer: Andrei Dulceanu
Congratulations Andrei & welcome to the team! Regards Julian On Mon, Dec 19, 2016 at 9:35 AM, Michael Dürig wrote: > Hi, > > Please welcome Andrei as a new committer and PMC member of the Apache > Jackrabbit project. The Jackrabbit PMC recently decided to offer Andrei > committership based on his contributions. I'm happy to announce that he > accepted the offer and that all the related administrative work has now been > taken care of. > > Welcome to the team, Andrei! > > Michael
[jira] [Commented] (JCRVLT-138) Unzip test-packages for easier maintenance
[ https://issues.apache.org/jira/browse/JCRVLT-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15621925#comment-15621925 ] Julian Sedding commented on JCRVLT-138: --- Thanks for the quick fix! Looks good to me and should make tests much more accessible. > Unzip test-packages for easier maintenance > -- > > Key: JCRVLT-138 > URL: https://issues.apache.org/jira/browse/JCRVLT-138 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: vlt >Affects Versions: 3.1.30 > Reporter: Julian Sedding >Priority: Minor > Fix For: 3.1.32 > > > As discussed in JCRVLT-111 it would be easier for maintenance of tests, and > more accessible, if the content-packages used in tests were exploaded. > This can be done relatively easily, as shown in an [example > project|https://github.com/code-distillery/filevault-oak-reindex-hook/blob/master/src/test/java/net/distilledcode/tools/InstallHookTestUtils.java#L39]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: svn commit: r1767213 [1/4] - in /jackrabbit/commons/filevault/trunk: parent/ vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ vault-core/src/test/java/org/apache/jackrabbit/vau
Hi Tobi Thanks for the change. Note: some of the files from the extracted packages have Adobe headers and other are missing the Apache license headers. Regards Julian On Mon, Oct 31, 2016 at 2:55 AM, wrote: > Author: tripod > Date: Mon Oct 31 01:55:37 2016 > New Revision: 1767213 > > URL: http://svn.apache.org/viewvc?rev=1767213&view=rev > Log: > JCRVLT-138 Unzip test-packages for easier maintenance > > Added: > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/config.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/definition/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/definition/.content.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/filter.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/nodetypes.cnd > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/META-INF/vault/properties.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/.content.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/node_a/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/node_a/.content.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/secured/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/secured/.content.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_a.zip/jcr_root/testroot/secured/_rep_policy.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/config.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/definition/ > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/definition/.content.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/filter.xml > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org/apache/jackrabbit/vault/packaging/integration/testpackages/mode_ac_test_b.zip/META-INF/vault/nodetypes.cnd > > jackrabbit/commons/filevault/trunk/vault-core/src/test/resources/org
[jira] [Comment Edited] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
[
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617748#comment-15617748
]
Julian Sedding edited comment on JCRVLT-111 at 10/29/16 8:56 AM:
-
[~tripod] if you look at the implementation of TestVaultPackage it's
exceedingly simple: it exposes a protected constructor accepting an {{Archive}}
that is already present in ZipVaultPackage. Zipping the package on the fly
probably requires more code and makes the tests slower. We could even consider
providing a public constructor or utility to make testing in downstream
projects easier.
I created JCRVLT-138 to track this improvement. Let's discuss over there in
order not to further side-track the discussion in this ticket.
was (Author: jsedding):
[~tripod] if you look at the implementation of TestVaultPackage it's
exceedingly simple: it exposes a protected constructor accepting an {{Archive}}
that is already present in ZipVaultPackage. Zipping the package on the fly
probably requires more code and makes the tests slower. We could even consider
providing a public constructor or utility to make testing in downstream
projects easier.
> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
> Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Fix For: 3.1.30
>
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control
> policy, which isn't an ACL. fvault should be adjusted to be able to properly
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be
> implemented the same way and just add extra principal names that are not yet
> present in the set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (JCRVLT-138) Unzip test-packages for easier maintenance
Julian Sedding created JCRVLT-138: - Summary: Unzip test-packages for easier maintenance Key: JCRVLT-138 URL: https://issues.apache.org/jira/browse/JCRVLT-138 Project: Jackrabbit FileVault Issue Type: Improvement Components: vlt Affects Versions: 3.1.30 Reporter: Julian Sedding Priority: Minor As discussed in JCRVLT-111 it would be easier for maintenance of tests, and more accessible, if the content-packages used in tests were exploaded. This can be done relatively easily, as shown in an [example project|https://github.com/code-distillery/filevault-oak-reindex-hook/blob/master/src/test/java/net/distilledcode/tools/InstallHookTestUtils.java#L39]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
[
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15617748#comment-15617748
]
Julian Sedding commented on JCRVLT-111:
---
[~tripod] if you look at the implementation of TestVaultPackage it's
exceedingly simple: it exposes a protected constructor accepting an {{Archive}}
that is already present in ZipVaultPackage. Zipping the package on the fly
probably requires more code and makes the tests slower. We could even consider
providing a public constructor or utility to make testing in downstream
projects easier.
> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
> Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Fix For: 3.1.30
>
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control
> policy, which isn't an ACL. fvault should be adjusted to be able to properly
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be
> implemented the same way and just add extra principal names that are not yet
> present in the set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCRVLT-111) Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
[
https://issues.apache.org/jira/browse/JCRVLT-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15615793#comment-15615793
]
Julian Sedding commented on JCRVLT-111:
---
[~tripod] on a side note: would it not make sense to check in the exploded
packages instead? I have done this successfully for a custom [commit-hook
implementation|https://github.com/code-distillery/filevault-oak-reindex-hook/blob/master/src/test/java/net/distilledcode/tools/InstallHookTestUtils.java#L43].
It's simple and works fine, vlt already provides all that's needed except a
{{VaultPackage}} implementation that allows plugging in an arbitrary
{{Archive}} implementation.
> Add support for o.a.j.api.security.authorization.PrincipalSetPolicy
> ---
>
> Key: JCRVLT-111
> URL: https://issues.apache.org/jira/browse/JCRVLT-111
> Project: Jackrabbit FileVault
> Issue Type: New Feature
>Reporter: angela
>Assignee: Tobias Bocanegra
> Fix For: 3.1.30
>
> Attachments: JCRVLT-111.patch
>
>
> jackrabbit API has been extended by an additional type of access control
> policy, which isn't an ACL. fvault should be adjusted to be able to properly
> import that type of access control policy.
> as discussed: ac-handling {{MERGE}} and {{MERGE_PRESERVE}} should be
> implemented the same way and just add extra principal names that are not yet
> present in the set.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release Apache Jackrabbit 2.10.3
[X] +1 Release this package as Apache Jackrabbit 2.10.3 Regards Julian On Mon, May 9, 2016 at 10:06 AM, Amit Jain wrote: > A candidate for the Jackrabbit 2.10.3 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/2.10.3/ > > The release candidate is a zip archive of the sources in: > > https://svn.apache.org/repos/asf/jackrabbit/tags/2.10.3/ > > The SHA1 checksum of the archive is > c253cd03e2e39010f28d7d66eaeabc5ffe2c1975. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > $ sh check-release.sh 2.10.3 c253cd03e2e39010f28d7d66eaeabc5ffe2c1975 > > Please vote on releasing this package as Apache Jackrabbit 2.10.3. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit 2.10.3 > [ ] -1 Do not release this package because... > > Thanks > Amit
[jira] [Commented] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
[
https://issues.apache.org/jira/browse/JCR-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262151#comment-15262151
]
Julian Sedding commented on JCR-3971:
-
The following system property is supported:
{noformat}
org.apache.jackrabbit.core.security.authorization.acl.CompiledPermissionsImpl.cacheSize
(default: 5000)
{noformat}
> Make read-permission cache-size in CompiledPermissionsImpl configurable
> ---
>
> Key: JCR-3971
> URL: https://issues.apache.org/jira/browse/JCR-3971
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: core
>Affects Versions: 2.8.1, 2.10.2, 2.12.1
> Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: 2.8.2, 2.10.3, 2.12.2
>
>
> Some use-cases require a larger read-permission cache size than the
> hard-coded 5000. This should be made configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
[
https://issues.apache.org/jira/browse/JCR-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15262148#comment-15262148
]
Julian Sedding commented on JCR-3972:
-
The following two system properties are supported:
{noformat}
org.apache.jackrabbit.core.CachingHierarchyManager.cacheSize (default: 1)
org.apache.jackrabbit.core.CachingHierarchyManager.logInterval (default: 6)
{noformat}
> Make size of ID-cache in CachingHierarchyManager configurable
> -
>
> Key: JCR-3972
> URL: https://issues.apache.org/jira/browse/JCR-3972
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: core
>Affects Versions: 2.8.1, 2.10.2, 2.12.1
> Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: 2.8.2, 2.10.3, 2.12.2
>
>
> Some use-cases require a larger ID cache to perform well than the hard-coded
> 1. This should be made configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
[ https://issues.apache.org/jira/browse/JCR-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated JCR-3971: Fix Version/s: 2.10.3 2.8.2 > Make read-permission cache-size in CompiledPermissionsImpl configurable > --- > > Key: JCR-3971 > URL: https://issues.apache.org/jira/browse/JCR-3971 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.8.2, 2.10.3, 2.12.2 > > > Some use-cases require a larger read-permission cache size than the > hard-coded 5000. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
[ https://issues.apache.org/jira/browse/JCR-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved JCR-3971. - Resolution: Fixed > Make read-permission cache-size in CompiledPermissionsImpl configurable > --- > > Key: JCR-3971 > URL: https://issues.apache.org/jira/browse/JCR-3971 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.8.2, 2.10.3, 2.12.2 > > > Some use-cases require a larger read-permission cache size than the > hard-coded 5000. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
[ https://issues.apache.org/jira/browse/JCR-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding resolved JCR-3972. - Resolution: Fixed > Make size of ID-cache in CachingHierarchyManager configurable > - > > Key: JCR-3972 > URL: https://issues.apache.org/jira/browse/JCR-3972 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.8.2, 2.10.3, 2.12.2 > > > Some use-cases require a larger ID cache to perform well than the hard-coded > 1. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
[ https://issues.apache.org/jira/browse/JCR-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256235#comment-15256235 ] Julian Sedding edited comment on JCR-3971 at 4/25/16 12:23 PM: --- Fixed in trunk [r1740814|https://svn.apach.org/r1740814]. Original patch from [~baedke]. Merged to branches/2.10 in [r1740826|https://svn.apache.org/r1740826]. Merged to branches/2.8 in [r1740829|https://svn.apache.org/r1740829]. was (Author: jsedding): Fixed in trunk [r1740814|https://svn.apach.org/r1740814]. Original patch from [~baedke]. > Make read-permission cache-size in CompiledPermissionsImpl configurable > --- > > Key: JCR-3971 > URL: https://issues.apache.org/jira/browse/JCR-3971 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: 2.12.2 > > > Some use-cases require a larger read-permission cache size than the > hard-coded 5000. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
[ https://issues.apache.org/jira/browse/JCR-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated JCR-3972: Fix Version/s: 2.10.3 2.8.2 > Make size of ID-cache in CachingHierarchyManager configurable > - > > Key: JCR-3972 > URL: https://issues.apache.org/jira/browse/JCR-3972 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.8.2, 2.10.3, 2.12.2 > > > Some use-cases require a larger ID cache to perform well than the hard-coded > 1. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
[ https://issues.apache.org/jira/browse/JCR-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256236#comment-15256236 ] Julian Sedding edited comment on JCR-3972 at 4/25/16 12:23 PM: --- Fixed in trunk [r1740815|https://svn.apach.org/r1740815]. Original patch from [~baedke]. Merged to branches/2.10 in [r1740828|https://svn.apache.org/r1740828]. Merged to branches/2.8 in [r1740831|https://svn.apache.org/r1740831]. was (Author: jsedding): Fixed in trunk [r1740815|https://svn.apach.org/r1740815]. Original patch from [~baedke]. > Make size of ID-cache in CachingHierarchyManager configurable > - > > Key: JCR-3972 > URL: https://issues.apache.org/jira/browse/JCR-3972 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > Fix For: 2.12.2 > > > Some use-cases require a larger ID cache to perform well than the hard-coded > 1. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
[ https://issues.apache.org/jira/browse/JCR-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated JCR-3971: Fix Version/s: 2.12.2 > Make read-permission cache-size in CompiledPermissionsImpl configurable > --- > > Key: JCR-3971 > URL: https://issues.apache.org/jira/browse/JCR-3971 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.12.2 > > > Some use-cases require a larger read-permission cache size than the > hard-coded 5000. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
[ https://issues.apache.org/jira/browse/JCR-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated JCR-3971: Affects Version/s: 2.8.1 2.10.2 > Make read-permission cache-size in CompiledPermissionsImpl configurable > --- > > Key: JCR-3971 > URL: https://issues.apache.org/jira/browse/JCR-3971 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.12.2 > > > Some use-cases require a larger read-permission cache size than the > hard-coded 5000. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
[ https://issues.apache.org/jira/browse/JCR-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated JCR-3972: Fix Version/s: 2.12.2 > Make size of ID-cache in CachingHierarchyManager configurable > - > > Key: JCR-3972 > URL: https://issues.apache.org/jira/browse/JCR-3972 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.12.2 > > > Some use-cases require a larger ID cache to perform well than the hard-coded > 1. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
[ https://issues.apache.org/jira/browse/JCR-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated JCR-3972: Affects Version/s: 2.8.1 2.10.2 > Make size of ID-cache in CachingHierarchyManager configurable > - > > Key: JCR-3972 > URL: https://issues.apache.org/jira/browse/JCR-3972 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.8.1, 2.10.2, 2.12.1 > Reporter: Julian Sedding > Assignee: Julian Sedding >Priority: Minor > Fix For: 2.12.2 > > > Some use-cases require a larger ID cache to perform well than the hard-coded > 1. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
[ https://issues.apache.org/jira/browse/JCR-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256235#comment-15256235 ] Julian Sedding commented on JCR-3971: - Fixed in trunk [r1740814|https://svn.apach.org/r1740814]. Original patch from [~baedke]. > Make read-permission cache-size in CompiledPermissionsImpl configurable > --- > > Key: JCR-3971 > URL: https://issues.apache.org/jira/browse/JCR-3971 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.12.1 > Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > > Some use-cases require a larger read-permission cache size than the > hard-coded 5000. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
[ https://issues.apache.org/jira/browse/JCR-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15256236#comment-15256236 ] Julian Sedding commented on JCR-3972: - Fixed in trunk [r1740815|https://svn.apach.org/r1740815]. Original patch from [~baedke]. > Make size of ID-cache in CachingHierarchyManager configurable > - > > Key: JCR-3972 > URL: https://issues.apache.org/jira/browse/JCR-3972 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Affects Versions: 2.12.1 > Reporter: Julian Sedding >Assignee: Julian Sedding >Priority: Minor > > Some use-cases require a larger ID cache to perform well than the hard-coded > 1. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCR-3972) Make size of ID-cache in CachingHierarchyManager configurable
Julian Sedding created JCR-3972: --- Summary: Make size of ID-cache in CachingHierarchyManager configurable Key: JCR-3972 URL: https://issues.apache.org/jira/browse/JCR-3972 Project: Jackrabbit Content Repository Issue Type: Improvement Components: core Affects Versions: 2.12.1 Reporter: Julian Sedding Assignee: Julian Sedding Priority: Minor Some use-cases require a larger ID cache to perform well than the hard-coded 1. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JCR-3971) Make read-permission cache-size in CompiledPermissionsImpl configurable
Julian Sedding created JCR-3971: --- Summary: Make read-permission cache-size in CompiledPermissionsImpl configurable Key: JCR-3971 URL: https://issues.apache.org/jira/browse/JCR-3971 Project: Jackrabbit Content Repository Issue Type: Improvement Components: core Affects Versions: 2.12.1 Reporter: Julian Sedding Assignee: Julian Sedding Priority: Minor Some use-cases require a larger read-permission cache size than the hard-coded 5000. This should be made configurable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Cannot create JIRA issue for JCR project
Thanks a lot Jukka, that did the trick! Regards Julian On Fri, Apr 22, 2016 at 9:33 PM, Jukka Zitting wrote: > I added Julian's account to the PMC role of the JCR project in Jira. > > Best, > > Jukka > > On Fri, Apr 22, 2016 at 2:24 PM Robert Munteanu wrote: >> >> On Fri, 2016-04-22 at 15:27 +0200, Julian Sedding wrote: >> > Hi all >> > >> > I can currently not log a JIRA issue for the JCR project. It is not >> > listed in the Create dialog's project dropdown. Other projects, e.g. >> > Jackrabbit Oak, Sling etc. are listed. >> > >> > Any ideas? Could it be related to the recent infra changes on JIRA? >> > Should I contact infra? >> > >> > Thanks >> > Julian >> >> The timing is certainly suspicious. An admin of the JCR Jira project >> should check that you have the right role. Any of 'Administrator, PMC, >> Committer, Contributor and Developer' should work. >> >> Robert
Cannot create JIRA issue for JCR project
Hi all I can currently not log a JIRA issue for the JCR project. It is not listed in the Create dialog's project dropdown. Other projects, e.g. Jackrabbit Oak, Sling etc. are listed. Any ideas? Could it be related to the recent infra changes on JIRA? Should I contact infra? Thanks Julian
Re: Deprecation of 2.2.x plan
+1 Regards Julian On Wed, Apr 20, 2016 at 7:01 AM, KÖLL Claus wrote: > +1 > > greets > claus > > -Ursprüngliche Nachricht- > Von: Davide Giannella [mailto:dav...@apache.org] > Gesendet: Dienstag, 19. April 2016 15:57 > An: dev > Betreff: Deprecation of 2.2.x plan > > Good afternoon team, > > we've not been touching our 2.2.x branch of Jackrabbit since 2012 and I > feel it's now safe to drop the support. > > What it means in actual actions: > > - link will be removed from the download page > - news will be posted on the homepage > - [announce] will be sent to jr-user, jr-dev, oak-dev > - branch and tags WILL stay there > > I will act on this somewhere next week. > > Any concern speak out. > > Regards > Davide > >
Re: New Jackrabbit committer: Tomek Rękawek
Congratulations Tomek! Regards Julian On Tue, Mar 22, 2016 at 12:05 PM, Manfred Baedke wrote: > Welcome, Tomek! > > Manfred > > > On 3/21/2016 6:21 PM, Michael Dürig wrote: >> >> Hi, >> >> Please welcome Tomek as a new committer and PMC member of the Apache >> Jackrabbit project. The Jackrabbit PMC recently decided to offer Tomek >> committership based on his contributions. I'm happy to announce that he >> accepted the offer and that all the related administrative work has now been >> taken care of. >> >> Welcome to the team, Tomek! >> >> Michael > >
[jira] [Commented] (JCR-3937) jackrabbit-jcr-commons bundle incorrectly has google dependency in Export-Package uses clause
[
https://issues.apache.org/jira/browse/JCR-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15055990#comment-15055990
]
Julian Sedding commented on JCR-3937:
-
I suggest to update to maven-bundle-plugin version 3.0.1 due to FELIX-5062. See
also OAK-3706.
> jackrabbit-jcr-commons bundle incorrectly has google dependency in
> Export-Package uses clause
> -
>
> Key: JCR-3937
> URL: https://issues.apache.org/jira/browse/JCR-3937
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-commons
>Affects Versions: 2.11.3
>Reporter: David Bosschaert
> Attachments: JCR-3937-2.patch, JCR-3937.patch
>
>
> jackrabbit-jcr-commons 2.11.3 has the following Export-Package line:
> {code}org.apache.jackrabbit.value;uses:="javax.jcr,org.apache.jackrabbit.util,com.google.common.collect";version="2.2.1"{code}
> The google uses is actually unnecessary and generated by a bug in the
> maven-bundle-plugin. Using the latest version of that makes the google
> transitive dependency go away.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: New Jackrabbit committer: Vikas Saurabh
Congratulations Vikas! Regards Julian On Mon, Nov 9, 2015 at 9:08 AM, Marcel Reutegger wrote: > Welcome to the team, Vikas! > > Regards > Marcel > > On 06/11/15 14:08, "Michael Dürig" wrote: > >>Hi, >> >>Please welcome Vikas as a new committer and PMC member of the Apache >>Jackrabbit project. The Jackrabbit PMC recently decided to offer Vikas >>committership based on his contributions. I'm happy to announce that he >>accepted the offer and that all the related administrative work has now >>been taken care of. >> >>Welcome to the team, Vikas! >> >>Michael >
Re: [VOTE] Release Apache Jackrabbit 2.11.1
[X] +1 Release this package as Apache Jackrabbit 2.11.1 Regards Julian On Fri, Oct 2, 2015 at 5:45 PM, Davide Giannella wrote: > A candidate for the Jackrabbit 2.11.1 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/2.11.1/ > > The release candidate is a zip archive of the sources in: > > https://svn.apache.org/repos/asf/jackrabbit/tags/2.11.1/ > > The SHA1 checksum of the archive is > 0b532d3ce728d84bc09db801c580180ec9d4b266. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > $ sh check-release.sh 2.11.1 0b532d3ce728d84bc09db801c580180ec9d4b266 > > Please vote on releasing this package as Apache Jackrabbit 2.11.1. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit 2.11.1 > [ ] -1 Do not release this package because... > > Davide >
Re: builder must be a org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder
Glad to be of help! Regards Julian On Tuesday, May 5, 2015, Torgeir Veimo wrote: > Excellent, this was just what I needed! > > I had to add a null check condition on .withBlobStore(blobStore) and > builder.setBlobStore(blobStore) so that it didn't fail on NPE when no > blob store was configured, but otherwise it worked flawlessly on > converting my 800MB test repository. > > > On 5 May 2015 at 19:56, Julian Sedding > > wrote: > > Hi Torgeir > > > > Take a look at OAK-2643[0], that may help. You can copy the repository > > on the NodeStore level, similar to the upgrade scenario. > > > > Regards > > Julian > > > > [0] https://issues.apache.org/jira/browse/OAK-2643 > > > > On Tue, May 5, 2015 at 2:20 AM, Torgeir Veimo > wrote: > >> Had a look in the source, and it appears this is due to the merge() > >> method only being available in the DocumentRootBuilder, not in the > >> NodeBuilder interface? > >> > >> Is there any other way to move a repository from tar storage to > >> mongodb without regenerating UUID / identifier values? > >> > >> On 4 May 2015 at 23:26, Torgeir Veimo > wrote: > >>> I didn't have much luck on the users list with this problem. Is there > >>> any work towards upgrading from tarmk to documentmk easier? > >>> > >>> I'm trying to move a repository from tarmk to mongodb, and am using > >>> the oak-run restore command, but am getting an exception; > >>> > >>> spazzo:oak-run torgeir$ java -jar ./target/oak-run-1.2.1.jar restore > >>> mongodb://localhost/oak ~/oak-repository-backup-20150427a > >>> > >>> Apache Jackrabbit Oak 1.2.1 > >>> Exception in thread "main" java.lang.IllegalArgumentException: builder > >>> must be a > org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder > >>> at > org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.asDocumentRootBuilder(DocumentNodeStore.java:2232) > >>> at > org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1490) > >>> [...] > >>> > >>> Looking at the mailing list it might be due to OAK-2049. I've tried > >>> running the node count script in oak console to find the offending > >>> node, but it detects no errors. > >>> > >>> > http://oak-dev.jackrabbit.apache.narkive.com/KVUViR6K/cannot-backup-and-restore-aem-tar-repository > >>> > >>> Are there any other things I need to fix in the repository? I've run > >>> the check, compact and then backup commands on the repository prior to > >>> trying to restore it to mongodb. > >>> > >>> -- > >>> -Tor > >> > >> > >> > >> -- > >> -Tor > > > > -- > -Tor >
Re: builder must be a org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder
Hi Torgeir Take a look at OAK-2643[0], that may help. You can copy the repository on the NodeStore level, similar to the upgrade scenario. Regards Julian [0] https://issues.apache.org/jira/browse/OAK-2643 On Tue, May 5, 2015 at 2:20 AM, Torgeir Veimo wrote: > Had a look in the source, and it appears this is due to the merge() > method only being available in the DocumentRootBuilder, not in the > NodeBuilder interface? > > Is there any other way to move a repository from tar storage to > mongodb without regenerating UUID / identifier values? > > On 4 May 2015 at 23:26, Torgeir Veimo wrote: >> I didn't have much luck on the users list with this problem. Is there >> any work towards upgrading from tarmk to documentmk easier? >> >> I'm trying to move a repository from tarmk to mongodb, and am using >> the oak-run restore command, but am getting an exception; >> >> spazzo:oak-run torgeir$ java -jar ./target/oak-run-1.2.1.jar restore >> mongodb://localhost/oak ~/oak-repository-backup-20150427a >> >> Apache Jackrabbit Oak 1.2.1 >> Exception in thread "main" java.lang.IllegalArgumentException: builder >> must be a org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder >> at >> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.asDocumentRootBuilder(DocumentNodeStore.java:2232) >> at >> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1490) >> [...] >> >> Looking at the mailing list it might be due to OAK-2049. I've tried >> running the node count script in oak console to find the offending >> node, but it detects no errors. >> >> http://oak-dev.jackrabbit.apache.narkive.com/KVUViR6K/cannot-backup-and-restore-aem-tar-repository >> >> Are there any other things I need to fix in the repository? I've run >> the check, compact and then backup commands on the repository prior to >> trying to restore it to mongodb. >> >> -- >> -Tor > > > > -- > -Tor
[jira] [Commented] (OAK-168) Basic JCR VersionManager support
[
https://issues.apache.org/jira/browse/OAK-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407121#comment-13407121
]
Julian Sedding commented on OAK-168:
An alternative approach to implement versioning could be to "tag" a revision in
the MicroKernel (like a Git tag). A tagged revision may not be garbage
collected.
In order to expose the {{/jcr:system/jcr:versionStorage}} only the tag, and
information about which node is being versioned, need to be persisted. Based on
this information, it should then be possible to construct a suitable
{{/jcr:system/jcr:versionStorage}} view in oak-jcr.
Having support for tagging in oak/mk, i.e. providing the possibility for taking
snapshots of the entire content tree at a relatively low cost, opens up a range
of possibilities. E.g. viewing the entire content tree as it was on 5th July
2012, but also e.g. hot-backups, which could discard any information that was
written after s tagged state, and thus guarantee consistency.
In my ideal world, a versioning mechanism that versions the entire repository,
would even find its way into the JCR spec.
> Basic JCR VersionManager support
>
>
> Key: OAK-168
> URL: https://issues.apache.org/jira/browse/OAK-168
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Reporter: Jukka Zitting
>
> Versioning is a highly useful feature for many applications, so we definitely
> should support that in Oak.
> We could start by adding a basic JCR VersionManager implementation that
> simply implements checkin operations by copying content from a node to the
> respective version history under {{/jcr:system/jcr:versionStorage}}.
> The next step would then be figuring out whether we want to expose such an
> operation directly in the Oak API, or if a separate versioning plugin and an
> associated validator for changes in the {{/jcr:system/jcr:versionStorage}}
> subtree works better.
> Based on that we can then proceed to implement more of the JCR versioning
> features.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3116) Cluster Node ID should be trimmed
[
https://issues.apache.org/jira/browse/JCR-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated JCR-3116:
Attachment: JCR-3116.patch
Trivial patch. Note that a null check is not needed since
FileUtils.readFileToString() is documented to never return null.
> Cluster Node ID should be trimmed
> -
>
> Key: JCR-3116
> URL: https://issues.apache.org/jira/browse/JCR-3116
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: clustering, config, jackrabbit-core
>Affects Versions: 2.2.9, 2.3.1
> Reporter: Julian Sedding
>Priority: Trivial
> Attachments: JCR-3116.patch
>
>
> If the cluster node ID is not configured in repository.xml, it is read from
> the file cluster_node.id instead. In case this file is edited by hand, some
> editors (e.g. vi) insert a trailing newline character ("\n"). This leads to
> the cluster node ID to contain a blank character. While I don't expect this
> to cause any issues, it is inconvenient for debugging and also introduces
> line-breaks in log files. I suggest to trim the cluster node ID, so only
> non-blank characters are used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JCR-3116) Cluster Node ID should be trimmed
Cluster Node ID should be trimmed
-
Key: JCR-3116
URL: https://issues.apache.org/jira/browse/JCR-3116
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: clustering, config, jackrabbit-core
Affects Versions: 2.3.1, 2.2.9
Reporter: Julian Sedding
Priority: Trivial
If the cluster node ID is not configured in repository.xml, it is read from the
file cluster_node.id instead. In case this file is edited by hand, some editors
(e.g. vi) insert a trailing newline character ("\n"). This leads to the cluster
node ID to contain a blank character. While I don't expect this to cause any
issues, it is inconvenient for debugging and also introduces line-breaks in log
files. I suggest to trim the cluster node ID, so only non-blank characters are
used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2768) Finalize method on SessionImpl
[ https://issues.apache.org/jira/browse/JCR-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918819#action_12918819 ] Julian Sedding commented on JCR-2768: - You may want to have a look at the GhostReference described in an old javaspecialist.eu newsletter issue[0]. It's been a while since I read it, so I don't recall the details, but I think it might be helpful. The approach would be similar to your second point. [0] http://www.javaspecialists.eu/archive/Issue098.html > Finalize method on SessionImpl > -- > > Key: JCR-2768 > URL: https://issues.apache.org/jira/browse/JCR-2768 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 2.1.0 >Reporter: Douglas Britsch > > Doing some profiling on our application which uses Jackrabbit-2.1.0 I noticed > that there were an awful lot of java.lang.ref.Finalizer objects hanging > around. Digging around I found the culprit was a finalize method on > SessionImpl. While I can see what it is trying to do (close the session if > you have not called logout) , I have found in the past that on application > servers, finalize should be avoided for objects that are created and deleted > frequently, as the GC behavior and object allocation is severely impacted, > and because of the number of references held by the session this seems like > it could keep a lot more in memory than needed a lot longer. (for more info > see http://www.fasterj.com/articles/finalizer1.shtml ). > Per Jukka's suggestion on the mailing list " > The automatic closing of a discarded session and related the warning > message are pretty useful in practice, as there are quite a few > session leaks in many client applications. So I'd rather keep that > functionality. > If the finalizer causes problems, we could investigate using weak (or > perhaps phantom) references and a reference queue for this purpose. > The RepositoryImpl class already keeps weak references to all sessions > in the activeSessions map, so this shouldn't even be too difficult to > implement." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2576) DbInputStream does not support mark()/reset() when exhausted.
[ https://issues.apache.org/jira/browse/JCR-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Sedding updated JCR-2576: Attachment: DbInputStream.patch I have started working on a patch, which is not fully functional yet. Unfortunately I currently don't have time to finish it off. It should illustrate a possible approach to solve the problem though. > DbInputStream does not support mark()/reset() when exhausted. > - > > Key: JCR-2576 > URL: https://issues.apache.org/jira/browse/JCR-2576 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 2.0.0 > Reporter: Julian Sedding >Assignee: Thomas Mueller > Attachments: DbInputStream.patch > > > The DbDataStore implementation uses a DbInputStream to read binary properties > from the database. When a new binary property is created, Jackrabbit attempts > to index it. Tika's CharsetDetector is used in the process, which marks the > input stream, reads the first 8000 bytes and then resets the stream. > This results in the stacktrace shown at the end of the issue, if the > following two conditions hold true: > * the property is larger than the minRecordLength configuration of the > Datastore and > * the property is smaller than 8000 bytes > The DbInputStream needs to have the following properties: > 1. lazy instantiation of the underlying stream > 2. auto-close underlying stream when EOF is reached > 3. fully support mark()/reset() even if the underlying stream is auto-closed > due to 2. > 12.03.2010 15:53:28 *WARN * LazyTextExtractorField: Failed to extract text > from a binary property (LazyTextExtractorField.java, line 165) > java.io.EOFException > at > org.apache.jackrabbit.core.data.db.DbInputStream.reset(DbInputStream.java:180) > at > org.apache.tika.io.ProxyInputStream.reset(ProxyInputStream.java:156) > at > org.apache.tika.io.ProxyInputStream.reset(ProxyInputStream.java:156) > at > org.apache.tika.parser.txt.CharsetDetector.setText(CharsetDetector.java:131) > at org.apache.tika.parser.txt.TXTParser.parse(TXTParser.java:77) > at > org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:120) > at > org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:101) > at > org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:114) > at > org.apache.jackrabbit.core.query.lucene.LazyTextExtractorField$ParsingTask.run(LazyTextExtractorField.java:160) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2576) DbInputStream does not support mark()/reset() when exhausted.
DbInputStream does not support mark()/reset() when exhausted. - Key: JCR-2576 URL: https://issues.apache.org/jira/browse/JCR-2576 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.0.0 Reporter: Julian Sedding The DbDataStore implementation uses a DbInputStream to read binary properties from the database. When a new binary property is created, Jackrabbit attempts to index it. Tika's CharsetDetector is used in the process, which marks the input stream, reads the first 8000 bytes and then resets the stream. This results in the stacktrace shown at the end of the issue, if the following two conditions hold true: * the property is larger than the minRecordLength configuration of the Datastore and * the property is smaller than 8000 bytes The DbInputStream needs to have the following properties: 1. lazy instantiation of the underlying stream 2. auto-close underlying stream when EOF is reached 3. fully support mark()/reset() even if the underlying stream is auto-closed due to 2. 12.03.2010 15:53:28 *WARN * LazyTextExtractorField: Failed to extract text from a binary property (LazyTextExtractorField.java, line 165) java.io.EOFException at org.apache.jackrabbit.core.data.db.DbInputStream.reset(DbInputStream.java:180) at org.apache.tika.io.ProxyInputStream.reset(ProxyInputStream.java:156) at org.apache.tika.io.ProxyInputStream.reset(ProxyInputStream.java:156) at org.apache.tika.parser.txt.CharsetDetector.setText(CharsetDetector.java:131) at org.apache.tika.parser.txt.TXTParser.parse(TXTParser.java:77) at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:120) at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:101) at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:114) at org.apache.jackrabbit.core.query.lucene.LazyTextExtractorField$ParsingTask.run(LazyTextExtractorField.java:160) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JCR 2.0 draft html version
Hi David Looks pretty good to me. Some minor issues/suggestions: * The footer is rendered at the top on the start page (intentionally?) * It would be nice if all references (e.g. see §3.7.1.2 Supertypes) were links. * In section "8.6.1.3 Root Declaring Node Type" some method signatures are linked to the API docs. This is good, but links point to the jsr-170 API. * In the right hand navigation element, "JCR v2.0: TOC" should be a link to the start page. * The lists in section "1.6 Acknowledgements" could do with some formatting (2-3 cols?) Regards Julian On Fri, Oct 2, 2009 at 6:07 PM, David Nuescheler wrote: > hi guys, > > i tried to update the document sizes to be more meaningful... > > http://www.day.com/specs/jcr/2.0/ > (possibly hit reload in your browser in case you may still have stuff > in your cache) > > feedback still very welcome ;) > > regards, > david > > On Mon, Sep 28, 2009 at 3:13 PM, Bertrand Delacretaz > wrote: >> Hi David, >> >> On Mon, Sep 28, 2009 at 2:59 PM, David Nuescheler wrote: >>> please find a draft of the JSR 283 html version online. >>> >>> http://www.day.com/specs/jcr/2.0/ >> >> Cool >> >>> ...After looking into the split-up I am tempted to created fewer >>> bigger documents instead >> >> Yes...pages like http://www.day.com/specs/jcr/2.0/3.6.1.5_DOUBLE.html >> makes me thing that a single big HTML document would be fine. >> >> -Bertrand >> > > > > -- > David Nuescheler > Chief Technology Officer > mailto: david.nuesche...@day.com > > web: http://www.day.com/ http://dev.day.com > twitter: @daysoftware >
Re: Per-repository thread pool in Jackrabbit
Hello Since Java 5 there is java.util.concurrent, which provides a ScheduledThreadPoolExecutor[1]. Maybe this suits the requirements. And it does not introduce another dependency. Regards Julian [1] http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html On Mon, Jul 13, 2009 at 2:57 PM, Felix Meschberger wrote: > Hi, > > Marcel Reutegger schrieb: >> Hi, >> >> 2009/7/12 Jukka Zitting : >>> Hi, >>> >>> 2009/7/8 Marcel Reutegger : - paralleled execution of some work. this is primarily to make use of multi-core processors. execution should be distributed over and executed by N threads which is a factor of the available processors. >>> If I recall correctly we debated this already earlier. My point was >>> that limiting the number of tasks to the number of available >>> processors may not be a good approach as the tasks may be IO-bound or >>> block for other reasons, in which case having more task threads would >>> give you better throughput. But I recall being proven wrong, did we >>> have some benchmark for that? Do you remember where this discussion >>> was? >> >> I don't remember either... But let's just start a new one. >> >> I think this very much depends on the work that needs to be distributed. >> there >> is no prove that one way is better than the other. for CPU intensive work >> we'd >> probably want to limit the number of concurrent tasks. for I/O intensive work >> the concurrency should be higher. >> >> my above point was rather related to CPU intensive work. e.g. creating a >> posting >> list while content is indexed. but of course there might be other work that >> may >> be parallelized more aggressively. >> >> I guess the actual pool shouldn't care about that. some utility on top >> of the pool >> should provide that functionality. i.e. execute a number of tasks with a >> given >> level of concurrency. the utility would then dispatch the tasks to the pool >> accordingly. >> - Timers used in TransactionContext and MultiIndex. This could be turned into a scheduling mechanism that could also be used by the ClusterNode sync. Other classes that use periodic checks in a background thread: DatabaseJournal (ClusterRevisionJanitor), CooperativeFileLock (watch dog). >>> Yep. Perhaps we could also reuse some of the scheduling functionality in >>> Sling. >> >> I'm not sure this is needed. the java rt library already comes with >> Timer and Task >> classes. our needs are very simple and I'm not sure that justifies a >> new dependency. > > Yes, AFAICT Java also has ThreadPool implementations. If not, I urge to > still _not_ reinvent the wheel and take something existing even if it > would a single dependency. > > Regards > Felix > >> the more I think about it, the more I like your idea. but we should be careful with a maximum size for a repository wide pool. extensive use of the pool by a module should not lock up another module just because there are no more idle threads. maybe that global pool shouldn't have a maximum size... >>> That might make sense. Perhaps we should have some concept of >>> sub-pools (that borrow from the main pool) with fixed limits for tasks >>> that need them (see above). >> >> hmm, that doesn't sound flexible and generic. I just thought again how cool >> it was if we could deploy jackrabbit into a google app-engine. that however >> requires that all background threads are removed. if we have that generic >> pool and client code adjusted accordingly it could be as easy as turning >> the pool into a direct executor variant ;) well, that's very optimistic but >> sounds promising to me... >> >> regards >> marcel >> >
[jira] Created: (JCR-2015) CachingIndexReader: NullPointerException initializing parents cache
CachingIndexReader: NullPointerException initializing parents cache --- Key: JCR-2015 URL: https://issues.apache.org/jira/browse/JCR-2015 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.9 Reporter: Julian Sedding Priority: Minor Using the jackrabbit-core-1.4.9 (after upgrading from jackrabbot-core-1.4.6), the following exception is logged. The code where the exception happens was introduced in JCR-1884 and is first included in the 1.4.9 core release. 10.03.2009 18:56:25 *WARN * CachingIndexReader: Error initializing parents cache. (CachingIndexReader.java, line 310) java.lang.NullPointerException at org.apache.jackrabbit.core.query.lucene.CachingIndexReader$CacheInitializer$2.collect(CachingIndexReader.java:362) at org.apache.jackrabbit.core.query.lucene.CachingIndexReader$CacheInitializer.collectTermDocs(CachingIndexReader.java:426) at org.apache.jackrabbit.core.query.lucene.CachingIndexReader$CacheInitializer.initializeParents(CachingIndexReader.java:356) at org.apache.jackrabbit.core.query.lucene.CachingIndexReader$CacheInitializer.run(CachingIndexReader.java:306) at org.apache.jackrabbit.core.query.lucene.CachingIndexReader.(CachingIndexReader.java:109) at org.apache.jackrabbit.core.query.lucene.AbstractIndex.getReadOnlyIndexReader(AbstractIndex.java:276) at org.apache.jackrabbit.core.query.lucene.MultiIndex.getIndexReader(MultiIndex.java:731) at org.apache.jackrabbit.core.query.lucene.MultiIndex.(MultiIndex.java:303) at org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:454) at com.day.crx.query.lucene.LuceneHandler.doInit(LuceneHandler.java:93) at org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:53) at org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:583) at org.apache.jackrabbit.core.SearchManager.(SearchManager.java:265) at org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1600) at org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:606) at org.apache.jackrabbit.core.RepositoryImpl.getWorkspaceInfo(RepositoryImpl.java:718) at com.day.crx.core.CRXRepositoryImpl.login(CRXRepositoryImpl.java:964) at org.apache.sling.jcr.base.internal.SessionPool.acquireSession(SessionPool.java:268) at org.apache.sling.jcr.base.internal.SessionPoolManager.login(SessionPoolManager.java:99) at org.apache.sling.jcr.base.AbstractSlingRepository.login(AbstractSlingRepository.java:240) at org.apache.sling.jcr.base.AbstractSlingRepository.loginAdministrative(AbstractSlingRepository.java:206) at org.apache.sling.jcr.base.AbstractSlingRepository.pingAndCheck(AbstractSlingRepository.java:506) at org.apache.sling.jcr.base.AbstractSlingRepository.startRepository(AbstractSlingRepository.java:810) at org.apache.sling.jcr.base.AbstractSlingRepository.activate(AbstractSlingRepository.java:629) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.felix.scr.impl.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226) at org.apache.felix.scr.impl.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:133) at org.apache.felix.scr.impl.AbstractComponentManager.activateInternal(AbstractComponentManager.java:476) at org.apache.felix.scr.impl.AbstractComponentManager.enableInternal(AbstractComponentManager.java:398) at org.apache.felix.scr.impl.AbstractComponentManager.access$000(AbstractComponentManager.java:36) at org.apache.felix.scr.impl.AbstractComponentManager$1.run(AbstractComponentManager.java:99) at org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:85) 10.03.2009 18:56:31 *INFO * SearchIndex: Index initialized: /u01/media/u01/crxlocal/workspaces/dailymail-prod/index Version: 2 (SearchIndex.java, line 492) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
