[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 marti...@gx.nl 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: FileLocking class=acme /. 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:
code
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();
}
/code
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-tabpanelfocusedCommentId=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.
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 aklim...@day.com 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-tabpanelfocusedCommentId=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 torg...@pobox.com 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] 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-tabpanelfocusedCommentId=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] 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] 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-tabpanelfocusedCommentId=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
