[jira] Updated: (JCR-1117) Bundle cache is not rolled back when the storage of a ChangeLog fails
[ https://issues.apache.org/jira/browse/JCR-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1117: --- Affects Version/s: 1.5.4 1.5.3 Fix Version/s: 1.5.5 Merged to the 1.5 branch in revision 760810. > Bundle cache is not rolled back when the storage of a ChangeLog fails > - > > Key: JCR-1117 > URL: https://issues.apache.org/jira/browse/JCR-1117 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.3, 1.4, 1.5.0, 1.5.2, 1.5.3, 1.5.4 >Reporter: Martijn Hendriks > Fix For: 1.5.5 > > Attachments: JCR-1117-v2.patch, JCR-1117-v3.patch, JCR-1117.patch, > stacktrace.txt > > > The bundle cache in the bundle persistence managers is not restored to its > old state when the AbstractBundlePersistenceManager.store(ChangeLog > changeLog) method throws an exception. If, for instance, the storage of > references fails then the > AbstractBundlePersistenceManager.putBundle(NodePropBundle bundle) method has > already been called for all modified bundles. Because of the connection > rollback, the bundle cache will be out-of-sync with the persistent state. As > a result, the SharedItemStateManager will have an incorrect view of the > persistent state. > Furthermore, if the blockOnConnectionLoss property is set to true, then the > BundleDbPersistenceManager can be caught in an infinite loop because of > invalid SQL inserts because of an incorrect bundle cache; see attached > stacktrace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Jackrabbit 1.5.5 release plan
Hi, On Thu, Mar 12, 2009 at 3:27 PM, Martijn Hendriks wrote: > It would be nice if JCR-1117 could be part of 1.5.5. Agreed. I merged the fix to the 1.5 branch. More generally, with the 1.5.4 release candidate tagged and out for review, I'm moving forward with the 1.5.5 release. A release candidate can be expected within a week or two. BR, Jukka Zitting
[jira] Updated: (JCR-1605) RepositoryLock does not work on NFS sometimes
[ https://issues.apache.org/jira/browse/JCR-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1605: --- Issue Type: New Feature (was: Bug) Classifying this as a new feature. > RepositoryLock does not work on NFS sometimes > - > > Key: JCR-1605 > URL: https://issues.apache.org/jira/browse/JCR-1605 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Fix For: 1.6.0 > > Attachments: repositoryLockMechanism.patch > > > The RepositoryLock mechanism currently used in Jackrabbit uses FileLock. This > doesn't work on some NFS file system. It looks like only NFS version 4 and > newer supports locking. Older implementations may throw a IOException "No > locks available", which means the NFS does not support byte-range locking. > I propose to add a second locking mechanism, and add a configuration option > to use it. For example: . This second locking > mechanism is a cooperative locking protocol that uses a background (watchdog) > thread and only uses regular file operations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2024) Bundle cache is not cleared when *BundlePersistenceManager is closed
[ https://issues.apache.org/jira/browse/JCR-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-2024: --- Fix Version/s: (was: 1.6.0) > Bundle cache is not cleared when *BundlePersistenceManager is closed > > > Key: JCR-2024 > URL: https://issues.apache.org/jira/browse/JCR-2024 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.5.3 >Reporter: Przemo Pakulski >Assignee: Przemo Pakulski >Priority: Minor > Fix For: 1.5.4 > > Attachments: JCR-2024.txt > > > Close method of persistence managers is responsible for releasing all > acquired resources. In case of BundlePersistenceManager it should also free > memory by clearing the bundle cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2023) WorkspaceInfo.dispose() does not deregister SharedItemStateManager from virtual item state providers
[ https://issues.apache.org/jira/browse/JCR-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-2023: --- Fix Version/s: (was: 1.6.0) > WorkspaceInfo.dispose() does not deregister SharedItemStateManager from > virtual item state providers > > > Key: JCR-2023 > URL: https://issues.apache.org/jira/browse/JCR-2023 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.5.3 >Reporter: Przemo Pakulski >Assignee: Przemo Pakulski > Fix For: 1.5.4 > > Attachments: JCR-2023.txt > > > Automatic disposal of idle workspaces frees unused workspaces but > corresponding SharedItemStateManager (and releated PersistenceManager) is > still kept in memory referenced by virtual item state providers, this can > lead to memory leaks. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-2012) BufferedStringValue corrupts non ISO-8859-1 characters on large Strings
[ https://issues.apache.org/jira/browse/JCR-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting reopened JCR-2012: Reopening to resolve as Duplicate of JCR-2007 instead of Fixed. > BufferedStringValue corrupts non ISO-8859-1 characters on large Strings > --- > > Key: JCR-2012 > URL: https://issues.apache.org/jira/browse/JCR-2012 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: core 1.4.5 > Environment: Sun JDK 1.6, Win 2000 >Reporter: Henryk Paluch >Assignee: Thomas Mueller >Priority: Critical > Fix For: 1.6.0 > > Attachments: BufferedStringValue.java.encFix.diff, > BufferedStringValueTest.java > > > When storing,retrieving large String values (for example large "sv:property" > named "content" - which contains text of paragraphs) then non-ISO-8859-1 > characters are lost. > This is caused becaus of improper handling of Temporary files in > BufferedStringValue - they use Readers/Writers without specifying encoding - > so national characters could be lost if system wide encoding does not support > them. > Pending attachments: > - JUnit test Case > - Proposed fix -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2012) BufferedStringValue corrupts non ISO-8859-1 characters on large Strings
[ https://issues.apache.org/jira/browse/JCR-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-2012. Resolution: Duplicate > BufferedStringValue corrupts non ISO-8859-1 characters on large Strings > --- > > Key: JCR-2012 > URL: https://issues.apache.org/jira/browse/JCR-2012 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: core 1.4.5 > Environment: Sun JDK 1.6, Win 2000 >Reporter: Henryk Paluch >Assignee: Thomas Mueller >Priority: Critical > Fix For: 1.6.0 > > Attachments: BufferedStringValue.java.encFix.diff, > BufferedStringValueTest.java > > > When storing,retrieving large String values (for example large "sv:property" > named "content" - which contains text of paragraphs) then non-ISO-8859-1 > characters are lost. > This is caused becaus of improper handling of Temporary files in > BufferedStringValue - they use Readers/Writers without specifying encoding - > so national characters could be lost if system wide encoding does not support > them. > Pending attachments: > - JUnit test Case > - Proposed fix -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-517) Reserved status of namespace jcr not enforced.
[
https://issues.apache.org/jira/browse/JCR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved JCR-517.
---
Resolution: Won't Fix
Assignee: Jukka Zitting
Resolving as Won't Fix. Properties like jcr:title are already in wide use.
Users should just be aware of the problems of reusing property names like
jcr:frozenMixinTypes.
> Reserved status of namespace jcr not enforced.
> --
>
> Key: JCR-517
> URL: https://issues.apache.org/jira/browse/JCR-517
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core, versioning
>Affects Versions: 0.9, 1.0, 1.0.1
>Reporter: Peeter Piegaze
>Assignee: Jukka Zitting
>Priority: Minor
>
> The failure to enforce the reserved status of the jcr namespace leads to at
> least one problem.
> A versionable node can be created with properties jcr:frozenPrimaryType,
> jcr:frozenMixinTypes or jcr:frozenUuid. These clash with the meta-data
> properties used in the nt:frozenNode.
> When the versionable is checked-in and then later restored, the corrupt
> frozen node can cause an exception. The following code demonstrates the
> problem:
>
>
> Repository repository = new TransientRepository();
> Session session = repository.login(new SimpleCredentials("username",
> "password".toCharArray()));
> try {
> Node root = session.getRootNode();
> Node a = root.addNode("a", "nt:unstructured");
> a.addMixin("mix:versionable");
> a.setProperty("jcr:frozenMixinTypes", new String[]{"x"});
> session.save();
> Version v = a.checkin();
> a.checkout();
> a.remove();
> session.save();
> root.restore(v, "a", true);
> } finally {
> session.logout();
> }
>
> The solution is to enforce the reserved status of jcr (and nt, mix and xml,
> while we are at it). The rules should be:
> 1) A client cannot register a node type that uses reserved namespaces in
> either the name of the node type or in the name of any off its child item
> definitions.
> 2) A client cannot create a residual child item with a name that uses a
> reserved namespace. Clients can, of course, create an item with a reserved
> namespace if the item is defined in a built-in JCR node type.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[JCR 2.0] Proposed final draft of JSR-283 released
Hello JCR community, if you haven't noticed it yet, the proposed final draft of JSR-283, the successor of JSR-170, ie. Java Content Repository version 2.0, is out. You'll find it here: http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html Please note that the download button link is currently broken, the correct one is here: https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_JCP-Site/en_US/-/USD/viewproductdetail-start?productref=content_repository-2.0-pfd-oth-js...@cds-cds_jcp There are quite a few changes since the public review, so it's a good read :-) And as far as I know, the final version of the spec will most likely be identical to the final draft. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
[jira] Commented: (JCR-2049) A tool to support large or long running transactions
[
https://issues.apache.org/jira/browse/JCR-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694485#action_12694485
]
Marcel Reutegger commented on JCR-2049:
---
While I certainly see the need to support large and long running transactions,
I don't think this is a viable solution, but rather a workaround.
I think there is no way around a transient space in jackrabbit-core that is
able to swap out item states. I'll create another issue for that.
> A tool to support large or long running transactions
>
>
> Key: JCR-2049
> URL: https://issues.apache.org/jira/browse/JCR-2049
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-jcr-commons
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> I propose to write a tool for large or long running transactions. Instead of
> keeping the changes in the transient space until a transaction is completed,
> a backup of the current state is stored in a backup area. This allows to save
> intermediate steps.
> I propose to create add a tool (probably just one class) in the
> jackrabbit-jcr-commons project, package org.apache.jackrabbit.commons.tools:
> class LargeTransactionTool {
> LargeTransactionTool getInstance(Session session, String backupPath);
> beginTransaction();
> deleteRecursive(Node n);
> Node addNode(Node parent, String name);
> backup(Node n);
> backupRecursive(Node n);
> commit();
> rollback();
> }
> An application could then use the tool as follows:
> LargeTransactionTool tool = LargeTransactionTool.getInstance(session,
> "/backupArea");
> tool.backup(n1);
> n1.setProperty(...);
> session.save();
> tool.deleteRecursive(n2);
> session.save();
> n4 = tool.addNode(n3, "x");
> session.save();
> tool.commit();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2051) Disk based transient space
Disk based transient space -- Key: JCR-2051 URL: https://issues.apache.org/jira/browse/JCR-2051 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Currently the transient space in jackrabbit-core is held completely in memory. This limits the number of items that can be part of a save call. The memory usage for the transient space should be lowered significantly, e.g. by writing item states to a swap file on a disk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2051) Disk based transient space
[ https://issues.apache.org/jira/browse/JCR-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694495#action_12694495 ] Marcel Reutegger commented on JCR-2051: --- Here's my proposal for an implementation: - have a map that references (hard or weak) all transient item states - keep hard references to N most recently used item states - if item state drops out of most recently used map turn its reference into a weak one and swap out the item state - on request of an item state, either return the hard referenced item state or resolve the weak reference into an item state read from disk > Disk based transient space > -- > > Key: JCR-2051 > URL: https://issues.apache.org/jira/browse/JCR-2051 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Marcel Reutegger >Priority: Minor > > Currently the transient space in jackrabbit-core is held completely in > memory. This limits the number of items that can be part of a save call. The > memory usage for the transient space should be lowered significantly, e.g. by > writing item states to a swap file on a disk. -- 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] Proposed final draft of JSR-283 released
Is there a document somewhere detailing the enhancements relative to JSR-170? 2009/4/1 Alexander Klimetschek > Hello JCR community, > > if you haven't noticed it yet, the proposed final draft of JSR-283, > the successor of JSR-170, ie. Java Content Repository version 2.0, is > out. You'll find it here: > > http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html > > Please note that the download button link is currently broken, the > correct one is here: > > > https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_JCP-Site/en_US/-/USD/viewproductdetail-start?productref=content_repository-2.0-pfd-oth-js...@cds-cds_jcp > > There are quite a few changes since the public review, so it's a good > read :-) And as far as I know, the final version of the spec will most > likely be identical to the final draft. > > Regards, > Alex > > -- > Alexander Klimetschek > alexander.klimetsc...@day.com >
[jira] Commented: (JCR-2049) A tool to support large or long running transactions
[
https://issues.apache.org/jira/browse/JCR-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694503#action_12694503
]
Thomas Mueller commented on JCR-2049:
-
Yes it's a workaround. In theory the tool could implement the regular JCR
interfaces but that would be quite a lot of work as well.
> swap out item states
This would be the preferred solution. When deleting many rows this is slower
however.
> A tool to support large or long running transactions
>
>
> Key: JCR-2049
> URL: https://issues.apache.org/jira/browse/JCR-2049
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-jcr-commons
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Minor
>
> I propose to write a tool for large or long running transactions. Instead of
> keeping the changes in the transient space until a transaction is completed,
> a backup of the current state is stored in a backup area. This allows to save
> intermediate steps.
> I propose to create add a tool (probably just one class) in the
> jackrabbit-jcr-commons project, package org.apache.jackrabbit.commons.tools:
> class LargeTransactionTool {
> LargeTransactionTool getInstance(Session session, String backupPath);
> beginTransaction();
> deleteRecursive(Node n);
> Node addNode(Node parent, String name);
> backup(Node n);
> backupRecursive(Node n);
> commit();
> rollback();
> }
> An application could then use the tool as follows:
> LargeTransactionTool tool = LargeTransactionTool.getInstance(session,
> "/backupArea");
> tool.backup(n1);
> n1.setProperty(...);
> session.save();
> tool.deleteRecursive(n2);
> session.save();
> n4 = tool.addNode(n3, "x");
> session.save();
> tool.commit();
--
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] Proposed final draft of JSR-283 released
On Wed, Apr 1, 2009 at 2:16 PM, Torgeir Veimo wrote: > Is there a document somewhere detailing the enhancements relative to > JSR-170? Unfortunately a change list seems to be missing in the spec package, but here are two articles explaining the new features: http://dev.day.com/microsling/content/blogs/main/jsr283proposedfinaldraft.html http://www.infoq.com/news/2007/07/java-content-repository-2 Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
[jira] Created: (JCR-2052) XPath QueryFormat may produce malformed XPath statement
XPath QueryFormat may produce malformed XPath statement --- Key: JCR-2052 URL: https://issues.apache.org/jira/browse/JCR-2052 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-spi-commons Reporter: Marcel Reutegger Priority: Minor When the query tree contains select properties *and* an order by clause, then the XPath QueryFormat will produce a malformed XPath statement. E.g.: //element(*, foo)/(@a|@b) order by @bar round trips to: //element(*, foo) order by @bar/(@a|@b) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2052) XPath QueryFormat may produce malformed XPath statement
[ https://issues.apache.org/jira/browse/JCR-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2052. --- Resolution: Fixed Fix Version/s: 1.6.0 Fixed in revision: 760876 > XPath QueryFormat may produce malformed XPath statement > --- > > Key: JCR-2052 > URL: https://issues.apache.org/jira/browse/JCR-2052 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-spi-commons >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.6.0 > > > When the query tree contains select properties *and* an order by clause, then > the XPath QueryFormat will produce a malformed XPath statement. > E.g.: > //element(*, foo)/(@a|@b) order by @bar > round trips to: > //element(*, foo) order by @bar/(@a|@b) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2050) Optimize refresh operations
[ https://issues.apache.org/jira/browse/JCR-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated JCR-2050: --- Attachment: JCR-2050-2.patch Updated patch. This patch incorporates suggestions from Angela (thanks!) > Optimize refresh operations > > > Key: JCR-2050 > URL: https://issues.apache.org/jira/browse/JCR-2050 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-jcr-benchmark, jackrabbit-jcr2spi >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Minor > Attachments: JCR-2050-2.patch, JCR-2050.patch, jcr.log.excerpt.txt > > > With the current implementation (recursive) refresh operations cause a full > traversal of the sub-tree rooted at the item causing the refresh. This is > potentially expensive. > Instead of invalidating each item in the respective sub-tree I propose to > mark the root of the sub-tree as invalidated. Such a mark would include a > time stamp. Also individual items would be time stamped with their resolution > time. When an item is accessed, it would check if its resolution time stamp > is older than the latest invalidation time stamp. If so, it checks whether > the invalidation applies to it at all (by traversing up the path) and if so > it would re-resolve itself. In any case its resolution time stamp will be > updated. > This approach would make invalidation much cheaper without putting much > additional load to simple item access. Moreover most of the additional load > (traversing up the path) only applies when an invalidation is pending. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2051) Disk based transient space
[ https://issues.apache.org/jira/browse/JCR-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694520#action_12694520 ] Stefan Guggisberg commented on JCR-2051: i absolutely agree about this feature/improvement in general. i started implementing a disk-backed item store about 2 years ago. i tried to keep the changes locally to TransientItemStateManager by implementing a DiskBackedItemStateStore using ehcache (very similar to your proposal). eventually i had to give up since i came to the conclusion that it's not possible to accomplish without major changes in jackrabbit's internal state-handling design. FWIW, here are my findings: let's assume an ItemState got evicted to disk and its reference turned into a weak one. that ItemState might still be referenced by an ItemImpl instance and hence modified. if the ItemState is gc'ed because it is no longer externally referenced), the changes will be lost since the serialized copy on disk does not reflect the changes made after it was created. in order to avoid this, the ItemState should only be evicted to disk when the object is no longer referenced, ... which is AFAIK technically impossible. > Disk based transient space > -- > > Key: JCR-2051 > URL: https://issues.apache.org/jira/browse/JCR-2051 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Marcel Reutegger >Priority: Minor > > Currently the transient space in jackrabbit-core is held completely in > memory. This limits the number of items that can be part of a save call. The > memory usage for the transient space should be lowered significantly, e.g. by > writing item states to a swap file on a disk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2051) Disk based transient space
[ https://issues.apache.org/jira/browse/JCR-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694536#action_12694536 ] Marcel Reutegger commented on JCR-2051: --- > if the ItemState is gc'ed because it is no longer externally referenced), the > changes will > be lost since the serialized copy on disk does not reflect the changes made > after it was > created. right. that part is missing in my proposal. but it can be solved by registering an item state listener that gets callbacks when an item state changes. If the callback is for a weakly referenced item state, then the serialized copy needs to be updated. > Disk based transient space > -- > > Key: JCR-2051 > URL: https://issues.apache.org/jira/browse/JCR-2051 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Marcel Reutegger >Priority: Minor > > Currently the transient space in jackrabbit-core is held completely in > memory. This limits the number of items that can be part of a save call. The > memory usage for the transient space should be lowered significantly, e.g. by > writing item states to a swap file on a disk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCRRMI-8) Remove SNAPSHOT dependencies to -core and -api
Remove SNAPSHOT dependencies to -core and -api -- Key: JCRRMI-8 URL: https://issues.apache.org/jira/browse/JCRRMI-8 Project: Jackrabbit JCR-RMI Issue Type: Improvement Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 2.0 Currently the JCR-RMI component has dependencies to 1.6-SNAPSHOT versions of jackrabbit-core and jackrabbit-api. The reason for such recent dependencies is the new RepositoryFactory interface that's being introduced in JCR-1834. Unfortunately this dependency prevents us from releasing JCR-RMI as a separate component before we release Jackrabbit 1.6.0. To fix this I'm going to revert the dependencies to the earlier 1.5.0 release and remove the RMI-based RepositoryFactory implementation for now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2048) Workspace is shut down while creating initial index
[ https://issues.apache.org/jira/browse/JCR-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-2048: -- Attachment: JCR-2048.patch Proposed patch. > Workspace is shut down while creating initial index > --- > > Key: JCR-2048 > URL: https://issues.apache.org/jira/browse/JCR-2048 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.4, 1.5.0 >Reporter: Marcel Reutegger >Priority: Minor > Attachments: JCR-2048.patch > > > This only happens when a maxIdleTime is configured for the workspaces in the > repository.xml and the workspace to index is not the default workspace. > The idle check considers a workspace as idle when there only a system session > is open and the configured idle time elapsed. This is also the case when the > workspace is initializing. > The repository should either check if a workspace is still initializing or we > need to move the search manager initialization into the > WorkspaceInfo.doInitialize() method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCRRMI-9) jackrabbit-api dependency is not optional
jackrabbit-api dependency is not optional - Key: JCRRMI-9 URL: https://issues.apache.org/jira/browse/JCRRMI-9 Project: Jackrabbit JCR-RMI Issue Type: Bug Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 2.0 The original idea for implementing the jackrabbit-api extensions in JCR-RMI was to only require the jackrabbit-api dependency when both the client *and* the server used those extensions. However, in practice the way we implemented the extensions requires the client (and rmiregistry, if used) of a Jackrabbit server to include the jackrabbit-api regardless of whether those extensions are used or not. This is a bit unfortunate, but as there is no easy way to work around this issue, I'm going to make the jackrabbit-api dependency non-optional in JCR-RMI. This should help avoid some common classpath configuration errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1879) "Directory was previously created with a different LockFactory" when open, close, delete a repository in a loop
[
https://issues.apache.org/jira/browse/JCR-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694555#action_12694555
]
Marcel Reutegger commented on JCR-1879:
---
> So, this issue also affect the 1.5 branch and a new merge :) will be greatly
> appreciated...
I'm not able to reproduce this issue on the 1.5 branch. Can you please create a
new issue and provide a test? Thanks.
> "Directory was previously created with a different LockFactory" when open,
> close, delete a repository in a loop
> ---
>
> Key: JCR-1879
> URL: https://issues.apache.org/jira/browse/JCR-1879
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.6.0
> Environment: Mac OS X
>Reporter: Thomas Mueller
>Priority: Minor
> Fix For: 1.6.0
>
>
> Opening a TransientRepository in a loop throws the exception "Directory was
> previously created with a different LockFactory instance".
> Test case:
> for (int i = 0; i < 3; i++) {
> FileUtils.deleteDirectory(new File("repository"));
> Repository rep = new TransientRepository();
> Session session = rep.login(new SimpleCredentials("", new char[0]));
> session.logout();
> }
> The problem seems to be that org.apache.lucene.store.FSDirectory.DIRECTORIES
> is not cleared (FSDirectory.close() is not called?).
> Stack trace:
> Exception in thread "main" javax.jcr.RepositoryException: Directory was
> previously created with a different LockFactory instance; please pass null as
> the lockFactory instance and use setLockFactory to change it: Directory was
> previously created with a different LockFactory instance; please pass null as
> the lockFactory instance and use setLockFactory to change it: Directory was
> previously created with a different LockFactory instance; please pass null as
> the lockFactory instance and use setLockFactory to change it
> at
> org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:555)
> at
> org.apache.jackrabbit.core.SearchManager.(SearchManager.java:239)
> at
> org.apache.jackrabbit.core.RepositoryImpl.getSystemSearchManager(RepositoryImpl.java:688)
> at
> org.apache.jackrabbit.core.RepositoryImpl.access$3(RepositoryImpl.java:681)
> at
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1780)
> at
> org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:667)
> at
> org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:480)
> at
> org.apache.jackrabbit.core.RepositoryImpl.(RepositoryImpl.java:321)
> at
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:618)
> at
> org.apache.jackrabbit.core.TransientRepository$2.getRepository(TransientRepository.java:241)
> at
> org.apache.jackrabbit.core.TransientRepository.startRepository(TransientRepository.java:261)
> Caused by: java.io.IOException: Directory was previously created with a
> different LockFactory instance; please pass null as the lockFactory instance
> and use setLockFactory to change it
> at
> org.apache.lucene.store.FSDirectory.getDirectory(FSDirectory.java:192)
> at
> org.apache.jackrabbit.core.query.lucene.directory.FSDirectoryManager.getDirectory(FSDirectoryManager.java:64)
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.(MultiIndex.java:227)
> at
> org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:477)
> at
> org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:59)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCRRMI-8) Remove SNAPSHOT dependencies to -core and -api
[ https://issues.apache.org/jira/browse/JCRRMI-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCRRMI-8. Resolution: Fixed Fixed in revision 760904. Note that this change *removed* the RepositoryFactory implementation in JCR-RMI. Once JCR 2.0 is out we can restore the code by reverting this change. > Remove SNAPSHOT dependencies to -core and -api > -- > > Key: JCRRMI-8 > URL: https://issues.apache.org/jira/browse/JCRRMI-8 > Project: Jackrabbit JCR-RMI > Issue Type: Improvement >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 2.0 > > > Currently the JCR-RMI component has dependencies to 1.6-SNAPSHOT versions of > jackrabbit-core and jackrabbit-api. The reason for such recent dependencies > is the new RepositoryFactory interface that's being introduced in JCR-1834. > Unfortunately this dependency prevents us from releasing JCR-RMI as a > separate component before we release Jackrabbit 1.6.0. > To fix this I'm going to revert the dependencies to the earlier 1.5.0 release > and remove the RMI-based RepositoryFactory implementation for now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCRRMI-10) Implement RepositoryFactory
Implement RepositoryFactory --- Key: JCRRMI-10 URL: https://issues.apache.org/jira/browse/JCRRMI-10 Project: Jackrabbit JCR-RMI Issue Type: New Feature Reporter: Jukka Zitting Once JCR 2.0 is out and we want to upgrade JCR-RMI to use it, we can restore the RepositoryFactory implementation removed in JCRRMI-8 simply by reverting revision 760904. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2035) IndexingQueue not checked on initial index creation
[ https://issues.apache.org/jira/browse/JCR-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2035. --- Resolution: Fixed Fix Version/s: 1.6.0 Applied patch in revision: 760906 > IndexingQueue not checked on initial index creation > --- > > Key: JCR-2035 > URL: https://issues.apache.org/jira/browse/JCR-2035 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.3, 1.4, 1.5.0 >Reporter: Marcel Reutegger >Priority: Minor > Fix For: 1.6.0 > > Attachments: JCR-2035.patch > > > With a default value of 100 for extractorBackLogSize and lots of text > extractions that time out, the temp folder gets filled with extractor*.tmp > files. This is because the IndexingQueue.getFinishedDocuments() is not called > during the initial index creation. This is not an issue during regular > operation because the method is called periodically from a timer thread. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCRRMI-9) jackrabbit-api dependency is not optional
[ https://issues.apache.org/jira/browse/JCRRMI-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCRRMI-9. Resolution: Fixed Fixed in revision 760905. > jackrabbit-api dependency is not optional > - > > Key: JCRRMI-9 > URL: https://issues.apache.org/jira/browse/JCRRMI-9 > Project: Jackrabbit JCR-RMI > Issue Type: Bug >Reporter: Jukka Zitting >Assignee: Jukka Zitting > Fix For: 2.0 > > > The original idea for implementing the jackrabbit-api extensions in JCR-RMI > was to only require the jackrabbit-api dependency when both the client *and* > the server used those extensions. However, in practice the way we implemented > the extensions requires the client (and rmiregistry, if used) of a Jackrabbit > server to include the jackrabbit-api regardless of whether those extensions > are used or not. > This is a bit unfortunate, but as there is no easy way to work around this > issue, I'm going to make the jackrabbit-api dependency non-optional in > JCR-RMI. This should help avoid some common classpath configuration errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCRRMI-1) Copy the JCR-RMI component to the new JCR Commons subproject
[ https://issues.apache.org/jira/browse/JCRRMI-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCRRMI-1. Resolution: Fixed JCR-RMI is now in jackrabbit/commons. We can remove the jackrabbit-jcr-rmi component from jackrabbit/trunk once we've released JCR-RMI 2.0.0. > Copy the JCR-RMI component to the new JCR Commons subproject > > > Key: JCRRMI-1 > URL: https://issues.apache.org/jira/browse/JCRRMI-1 > Project: Jackrabbit JCR-RMI > Issue Type: Task >Reporter: Jukka Zitting >Assignee: Jukka Zitting > > JCR-RMI is one of the components to be included in the new JCR Commons > subproject. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCRRMI-11) LICENSE and NOTICE files in JCR-RMI
LICENSE and NOTICE files in JCR-RMI --- Key: JCRRMI-11 URL: https://issues.apache.org/jira/browse/JCRRMI-11 Project: Jackrabbit JCR-RMI Issue Type: Improvement Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Blocker Fix For: 2.0 The JCR-RMI trunk should contain LICENSE and NOTICE files as required by Apache policy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[rmi] JCR-RMI 2.0.0 release plan
Hi, I'd like to start releasing individual JCR Commons components so we can simplify the Jackrabbit core before the 1.6 release. JCR-RMI is the component I've been using for setting up things in JCR Commons. I think the component is getting close to being released by itself, so I'd like anyone interested to give jackrabbit/commons/jcr-rmi/trunk a quick look to check if everything is OK. Note that (like the earlier versions), the component is a proper OSGi bundle. I'll still be making some build tweaks (enable the Maven GPG plugin, etc.), but once I'm happy with all the details I plan to cut a candidate for the JCR-RMI 2.0.0 release. BR, Jukka Zitting
[jira] Resolved: (JCRRMI-11) LICENSE and NOTICE files in JCR-RMI
[ https://issues.apache.org/jira/browse/JCRRMI-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCRRMI-11. - Resolution: Fixed Fixed in revisions 760922 and 760923. > LICENSE and NOTICE files in JCR-RMI > --- > > Key: JCRRMI-11 > URL: https://issues.apache.org/jira/browse/JCRRMI-11 > Project: Jackrabbit JCR-RMI > Issue Type: Improvement >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Blocker > Fix For: 2.0 > > > The JCR-RMI trunk should contain LICENSE and NOTICE files as required by > Apache policy. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2031) Improved log message: include path
[ https://issues.apache.org/jira/browse/JCR-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-2031. - Resolution: Fixed > Improved log message: include path > -- > > Key: JCR-2031 > URL: https://issues.apache.org/jira/browse/JCR-2031 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Attachments: improvedLogMessage.patch > > > The cluster logs a message for each appended operation. The log message is > currently the revision number. A more interesting log message would be the > user name, and the path of the change (the most specific path if the change > contains multiple nodes). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2031) Improved log message: include path
[ https://issues.apache.org/jira/browse/JCR-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694585#action_12694585 ] Thomas Mueller commented on JCR-2031: - Committed in revision 760900 (trunk) Please note the log level for this path is 'debug' so you will not see the message by default. > Improved log message: include path > -- > > Key: JCR-2031 > URL: https://issues.apache.org/jira/browse/JCR-2031 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: clustering >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > Attachments: improvedLogMessage.patch > > > The cluster logs a message for each appended operation. The log message is > currently the revision number. A more interesting log message would be the > user name, and the path of the change (the most specific path if the change > contains multiple nodes). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JSR-283 Proposed Final Draft posted, waiting for download fix.
Dear Jackrabbit-Devs & Sling-Devs, as you may have seen JSR-283 has been posted for proposed final draft. http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html Unfortunately, there seems to be an error in the posting since the download link on the page results in a "Not Found Error". I alerted the PMO of the JCP at Sun this morning CET. The PMO (Project Management Office) is administrating all JSRs and is responsible for posting the proposed final draft. I will keep you posted on the progress. regards, david
Re: JSR-283 Proposed Final Draft posted, waiting for download fix.
Good news ;) I am happy announce on behalf of the JSR-283 Expert Group that JSR-283 is out for Proposed Final Draft review. http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html There are a lot new and exciting features in the specification and changed the structure of the specification to make a big section Java Language since a lot of you ported JCR outside of the Java Language. For a little more information, visit: http://dev.day.com/microsling/content/blogs/main/jsr283proposedfinaldraft.html Feedback is very welcome jsr-283-comme...@jcp.org regards, david On Wed, Apr 1, 2009 at 8:44 PM, David Nuescheler wrote: > Dear Jackrabbit-Devs & Sling-Devs, > > as you may have seen JSR-283 has been posted for proposed final draft. > http://jcp.org/aboutJava/communityprocess/pfd/jsr283/index.html > > Unfortunately, there seems to be an error in the posting since the > download link on the page results in a "Not Found Error". > I alerted the PMO of the JCP at Sun this morning CET. > The PMO (Project Management Office) is administrating all JSRs and is > responsible for posting the proposed final draft. > > I will keep you posted on the progress. > > regards, > david > -- Visit: http://dev.day.com/
