Content Technology track at the ApacheCon US 2009
Hi, [Sorry again for cross-posting, perhaps we should set up a jcr-interest@ mailing list somewhere] The ApacheCon planners are asking for Apache projects to self-organize content for the upcoming ApacheCon US in November this year. It would be cool to have a track related to content repositories and content management. Jackrabbit and Sling would form a nice core for such a track, but we could also include sessions on things like Chemistry and other related projects. The planners would like an indication of interest ASAP, so I will contact them about this if people think it's a good idea. In previous ApacheCons we've typically had a few related presentations and a BoF session or a Meetup. Based on that I think we could well organize something like a half-day track of presentations and workshops followed by a more informal community meetup in the evening. BR, Jukka Zitting
Re: Content Technology track at the ApacheCon US 2009
Hi Jukka, Jukka Zitting schrieb: [Sorry again for cross-posting, perhaps we should set up a jcr-interest@ mailing list somewhere] Maybe that would be a good idea. In the OSGi world we have kind of the same problem. The ApacheCon planners are asking for Apache projects to self-organize content for the upcoming ApacheCon US in November this year. It would be cool to have a track related to content repositories and content management. Jackrabbit and Sling would form a nice core for such a track, but we could also include sessions on things like Chemistry and other related projects. The planners would like an indication of interest ASAP, so I will contact them about this if people think it's a good idea. In previous ApacheCons we've typically had a few related presentations and a BoF session or a Meetup. Based on that I think we could well organize something like a half-day track of presentations and workshops followed by a more informal community meetup in the evening. +1 Regards Felix
[jira] Commented: (JCR-2070) jcr-server should respect node type definition jcr:content
[ https://issues.apache.org/jira/browse/JCR-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701881#action_12701881 ] Jukka Zitting commented on JCR-2070: The problem with using addNode(jcr:content) without explicitly specifying a node type, is that by default the node would then end up with nt:base as it's node type if the parent is a standard nt:file node. jcr-server should respect node type definition jcr:content -- Key: JCR-2070 URL: https://issues.apache.org/jira/browse/JCR-2070 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Reporter: Michael Dürig Attachments: JCR-2070.patch When creating a new file, jcr:content defaults to nt:unstructured. This causes file creation to fail when the underlying persistent store (i.e. SPI implementation) does not support nt:unstructured for jcr:content. I suggest to check whether the underlying implementation provides its own node type for jcr:content and use that one. If not, default to nt:unstructured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Content Technology track at the ApacheCon US 2009
Hi, On Thu, Apr 23, 2009 at 11:37 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: It would be cool to have a track related to content repositories and content management I like your idea. This is based on the same idea of the 'Interoperability' one, that I mentioned some days ago. Jackrabbit and Sling would form a nice core for such a track, but we could also include sessions on things like Chemistry and other related projects. POI is often used in CM contexts and products; do you think that such a project could fall within such a track? Cheers, -- Paolo Mottadelli: http://www.paolomottadelli.com Sourcesense - making sense of Open Source: http://www.sourcesense.com
[jira] Commented: (JCR-2070) jcr-server should respect node type definition jcr:content
[ https://issues.apache.org/jira/browse/JCR-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701895#action_12701895 ] Alexander Klimetschek commented on JCR-2070: Just out of curiosity: your patch actually adds the addNode(jcr:content) call w/o an explicit node type to the jcr server code. This does not really fit with the description of this issue... What is the default value for getContentNodeType() and/or is it configurable? Puzzled ;-) jcr-server should respect node type definition jcr:content -- Key: JCR-2070 URL: https://issues.apache.org/jira/browse/JCR-2070 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Reporter: Michael Dürig Attachments: JCR-2070.patch When creating a new file, jcr:content defaults to nt:unstructured. This causes file creation to fail when the underlying persistent store (i.e. SPI implementation) does not support nt:unstructured for jcr:content. I suggest to check whether the underlying implementation provides its own node type for jcr:content and use that one. If not, default to nt:unstructured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2070) jcr-server should respect child node definition of jcr:content
[ https://issues.apache.org/jira/browse/JCR-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated JCR-2070: --- Summary: jcr-server should respect child node definition of jcr:content (was: jcr-server should respect node type definition jcr:content) jcr-server should respect child node definition of jcr:content -- Key: JCR-2070 URL: https://issues.apache.org/jira/browse/JCR-2070 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Reporter: Michael Dürig Attachments: JCR-2070.patch When creating a new file, jcr:content defaults to nt:unstructured. This causes file creation to fail when the underlying persistent store (i.e. SPI implementation) does not support nt:unstructured for jcr:content. I suggest to check whether the underlying implementation provides its own node type for jcr:content and use that one. If not, default to nt:unstructured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2070) jcr-server should respect node type definition jcr:content
[ https://issues.apache.org/jira/browse/JCR-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701900#action_12701900 ] Michael Dürig commented on JCR-2070: getContentNodeType() is hardcoded to nt:unstructured in DefaultHandler. So the current code always tries to create jcr:content with type nt:unstructured. This fails if the parent's child node definition does not allow nt:unstructured for jcr:content (i.e. requires nt:resource). As Jukka noted, the patch is flawed. jcr-server should respect node type definition jcr:content -- Key: JCR-2070 URL: https://issues.apache.org/jira/browse/JCR-2070 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Reporter: Michael Dürig Attachments: JCR-2070.patch When creating a new file, jcr:content defaults to nt:unstructured. This causes file creation to fail when the underlying persistent store (i.e. SPI implementation) does not support nt:unstructured for jcr:content. I suggest to check whether the underlying implementation provides its own node type for jcr:content and use that one. If not, default to nt:unstructured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Content Technology track at the ApacheCon US 2009
Hi, On Thu, Apr 23, 2009 at 11:37 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: ...I think we could well organize something like a half-day track of presentations and workshops followed by a more informal community meetup in the evening +1 I'm sure we can easily fill a half-day track with Jacrkabbit, Sling, Chemistry, and by inviting related projects like POI, Tika, etc. to contribute. -Bertrand
[jira] Updated: (JCR-2070) jcr-server should respect child node definition of jcr:content
[ https://issues.apache.org/jira/browse/JCR-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated JCR-2070: --- Attachment: JCR-2070-1.patch Corrected patch: Check whether jcr:content can be created with the note type returned by getContentNodeType(). If so create it. Otherwise try to create jcr:content without explicitly specifying a node type. jcr-server should respect child node definition of jcr:content -- Key: JCR-2070 URL: https://issues.apache.org/jira/browse/JCR-2070 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Reporter: Michael Dürig Attachments: JCR-2070-1.patch, JCR-2070.patch When creating a new file, jcr:content defaults to nt:unstructured. This causes file creation to fail when the underlying persistent store (i.e. SPI implementation) does not support nt:unstructured for jcr:content. I suggest to check whether the underlying implementation provides its own node type for jcr:content and use that one. If not, default to nt:unstructured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Content Technology track at the ApacheCon US 2009
On Thu, Apr 23, 2009 at 1:28 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: I'm sure we can easily fill a half-day track with Jacrkabbit, Sling, Chemistry, and by inviting related projects like POI, Tika, etc. to contribute. +1 I'm forwarding this message to the POI community, which is strongly willing to join some other project. I've also submitted a proposal about 'POI' (besides one about 'CMIS' and another about 'Apache in Open Source ECM') Hope this is going to help. Cheers, -- Paolo Mottadelli: http://www.paolomottadelli.com Sourcesense - making sense of Open Source: http://www.sourcesense.com
[jira] Resolved: (JCR-2036) Set_property permission not checked when saving a new node
[ https://issues.apache.org/jira/browse/JCR-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-2036. Resolution: Fixed Patch applied in revision 767907. Thanks! Set_property permission not checked when saving a new node -- Key: JCR-2036 URL: https://issues.apache.org/jira/browse/JCR-2036 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.3 Reporter: Bart van der Schans Assignee: Jukka Zitting Fix For: 1.5.5 Attachments: ItemImpl.patch When a new node is saved, the add_node permission is checked, but not the set_property permission on it's properties in ItemImpl.validateTransientItems(). This is already fixed in trunk where the implementation is slightly different. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1886) jcr2spi: Unprocessed ItemInfos call to RepositoryService#getItemInfos
[ https://issues.apache.org/jira/browse/JCR-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1886: --- Fix Version/s: (was: 1.6.0) jcr2spi: Unprocessed ItemInfos call to RepositoryService#getItemInfos - Key: JCR-1886 URL: https://issues.apache.org/jira/browse/JCR-1886 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr2spi Affects Versions: 1.5.0 Reporter: angela Assignee: Michael Dürig Fix For: 1.5.5 stefan reported the following problem: - batchread config reads with depths infinity - invalidate tree by calling Node.refresh(false) - force loading of the tree (e.g. Node.getPath()) afterwards, there may still be invalidated item states indicating that not all ItemInfos were processed. consequently, there are additional calls to getItemInfos that should have been covered by the loading of the tree. the problem occuring is not related to limitation of the item-cache size. problem analysis: there is a bug in WorkspaceItemStateFactory#createItemStates. there is a wrapper built around the ItemInfo-Iterator but later on the ItemInfo-Iterator is used instead of the wrapper, which pre-fetches items from the underlying iterator and process them upon hasNext()/next(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2014) Jcr2Spi: Warning upon reloading property values
[ https://issues.apache.org/jira/browse/JCR-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-2014: --- Fix Version/s: (was: 1.6.0) Jcr2Spi: Warning upon reloading property values --- Key: JCR-2014 URL: https://issues.apache.org/jira/browse/JCR-2014 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr2spi Affects Versions: 1.5.0 Reporter: angela Assignee: Michael Dürig Fix For: 1.5.5 Attachments: JCR-2014.patch tobi reported the following log-warning being written upon reloading property values: [WARN ] Property data has been discarded It seems to me that this has been introduced with JCR-1963. Taking a closer look at it, i get the impression that the 'discarded' flag should only be set if any values are notified accordingly. In addition it seems to me that the MergeResult should have a dispose() method (or something similar) in order to have the replaced (old) property values properly released... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2070) jcr-server should respect child node definition of jcr:content
[ https://issues.apache.org/jira/browse/JCR-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701927#action_12701927 ] Jukka Zitting commented on JCR-2070: Not sure if asking the primary node type is enough, we should probably check all the mixin types too. jcr-server should respect child node definition of jcr:content -- Key: JCR-2070 URL: https://issues.apache.org/jira/browse/JCR-2070 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Reporter: Michael Dürig Attachments: JCR-2070-1.patch, JCR-2070.patch When creating a new file, jcr:content defaults to nt:unstructured. This causes file creation to fail when the underlying persistent store (i.e. SPI implementation) does not support nt:unstructured for jcr:content. I suggest to check whether the underlying implementation provides its own node type for jcr:content and use that one. If not, default to nt:unstructured. -- 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 Tue, Apr 21, 2009 at 12:07 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: I'm just reviewing the last pending commits in trunk. Michael is still looking at some SPI fixes to be included in 1.5.5, and I plan to cut the release as soon as those issues are sorted out. Pretty much all the relevant fixes are now in the 1.5 branch. See below for the full list of bug fixes and improvements (for jcr2spi) to be included in the 1.5.5 release. JCR-2070 is still open, but I'm not sure if we should include it in 1.5.5. Michael's second patch looks nice, but perhaps it's better to schedule it for 1.5.6? Unless anyone objects, I'll cut the release in the evening today. jackrabbit-jcr-commons Bug fixes [JCR-1976] Text.unescape() should should preserve 'unicode' characters [JCR-1996] Handle date values in the far future or prevent these from ... [JCR-1997] Performance fix, when deserializing large jcr:binary in ... [JCR-2017] System view export truncates carriage return jackrabbit-core Bug fixes [JCR-1117] Bundle cache is not rolled back when the storage of a ... [JCR-1216] Unreferenced sessions should get garbage collected [JCR-1996] Handle date values in the far future or prevent these from ... [JCR-2007] Importing strings with special characters fails [JCR-2020] Overlapping index aggregates not updated [JCR-2035] IndexingQueue not checked on initial index creation [JCR-2048] Workspace is shut down while creating initial index [JCR-2036] Set_property permission not checked when saving a new node [JCR-2057] When creating multiple repository instances pointing to the ... [JCR-2063] FileDataStore: garbage collection can delete files that are ... [JCR-2071] IndexMerger throws null pointer exception without stacktrace [JCR-2080] DataStore: garbage collection can fail when using workspace ... jackrabbit-webdav Bug fixes [JCR-2009] Large file download over webdav causes exception jackrabbit-spi-commons Bug fixes [JCR-2052] XPath QueryFormat may produce malformed XPath statement jackrabbit-jcr2spi Bug fixes [JCR-1886] jcr2spi: Unprocessed ItemInfos call to RepositoryService#... [JCR-2014] Jcr2Spi: Warning upon reloading property values [JCR-2016] ChildNodeEntriesImpl.update logs incorrect errors Improvements [JCR-1870] jcr2spi: reloading of invalidated nodes doesn't benefit from ... [JCR-1871] jcr2spi: use jcr names and path for log and exception message [JCR-1891] jcr2spi: use Soft refs for hierarchy [JCR-1906] Make observation polling time configurable [JCR-1963] Determination of property state difference should skip binary ... [JCR-1966] [PATCH] Remove Stutter in NodeState [JCR-1967] Impossible comparison in NodeTypeImpl [JCR-2038] Lower log level in o.a.j.jcr2spi.query.NodeIteratorImpl [JCR-2039] Add log information when node/property type determination fails BR, Jukka Zitting
Re: Jackrabbit 1.5.5 release plan
Jukka Zitting wrote: JCR-2070 is still open, but I'm not sure if we should include it in 1.5.5. Michael's second patch looks nice, but perhaps it's better to schedule it for 1.5.6? That's fine with me. The fix is less urgent than I initially thought. Michael Unless anyone objects, I'll cut the release in the evening today. jackrabbit-jcr-commons Bug fixes [JCR-1976] Text.unescape() should should preserve 'unicode' characters [JCR-1996] Handle date values in the far future or prevent these from ... [JCR-1997] Performance fix, when deserializing large jcr:binary in ... [JCR-2017] System view export truncates carriage return jackrabbit-core Bug fixes [JCR-1117] Bundle cache is not rolled back when the storage of a ... [JCR-1216] Unreferenced sessions should get garbage collected [JCR-1996] Handle date values in the far future or prevent these from ... [JCR-2007] Importing strings with special characters fails [JCR-2020] Overlapping index aggregates not updated [JCR-2035] IndexingQueue not checked on initial index creation [JCR-2048] Workspace is shut down while creating initial index [JCR-2036] Set_property permission not checked when saving a new node [JCR-2057] When creating multiple repository instances pointing to the ... [JCR-2063] FileDataStore: garbage collection can delete files that are ... [JCR-2071] IndexMerger throws null pointer exception without stacktrace [JCR-2080] DataStore: garbage collection can fail when using workspace ... jackrabbit-webdav Bug fixes [JCR-2009] Large file download over webdav causes exception jackrabbit-spi-commons Bug fixes [JCR-2052] XPath QueryFormat may produce malformed XPath statement jackrabbit-jcr2spi Bug fixes [JCR-1886] jcr2spi: Unprocessed ItemInfos call to RepositoryService#... [JCR-2014] Jcr2Spi: Warning upon reloading property values [JCR-2016] ChildNodeEntriesImpl.update logs incorrect errors Improvements [JCR-1870] jcr2spi: reloading of invalidated nodes doesn't benefit from ... [JCR-1871] jcr2spi: use jcr names and path for log and exception message [JCR-1891] jcr2spi: use Soft refs for hierarchy [JCR-1906] Make observation polling time configurable [JCR-1963] Determination of property state difference should skip binary ... [JCR-1966] [PATCH] Remove Stutter in NodeState [JCR-1967] Impossible comparison in NodeTypeImpl [JCR-2038] Lower log level in o.a.j.jcr2spi.query.NodeIteratorImpl [JCR-2039] Add log information when node/property type determination fails BR, Jukka Zitting
[jira] Commented: (JCR-2070) jcr-server should respect child node definition of jcr:content
[ https://issues.apache.org/jira/browse/JCR-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12701945#action_12701945 ] Michael Dürig commented on JCR-2070: Yes you're right. I see two options: 1) Check whether any of getPrimaryNodeType() or getMixinNodeTypes() allows for adding the jcr:content node of the given type. If so create it. Otherwise try to create jcr:content without explicitly specifying a node type. 2) Try to create jcr:content with the given type. On RepositoryException retry without explicitly specifying a node type. For 1) the supertypes should theoretically also be considered. However for a compliant repository implementation they can be ignored I think. 2) is more general since it just retries regardless of why adding failed on the first try. WDYT? jcr-server should respect child node definition of jcr:content -- Key: JCR-2070 URL: https://issues.apache.org/jira/browse/JCR-2070 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-jcr-server Reporter: Michael Dürig Attachments: JCR-2070-1.patch, JCR-2070.patch When creating a new file, jcr:content defaults to nt:unstructured. This causes file creation to fail when the underlying persistent store (i.e. SPI implementation) does not support nt:unstructured for jcr:content. I suggest to check whether the underlying implementation provides its own node type for jcr:content and use that one. If not, default to nt:unstructured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Incubating Chemistry (Was: IP clearance for the Chemistry contribution)
Hi, On Tue, Apr 21, 2009 at 12:12 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Thanks to everyone who's been participating in writing up the proposal; I think it's soon ready to be voted on! See [1] for the current status. [1] http://wiki.apache.org/incubator/ChemistryProposal I just filled in the last TODO entries and I feel that the proposal is pretty much complete now. Are there any points that still should be clarified or changed? BR, Jukka Zitting
Re: Incubating Chemistry
On 23 Apr 2009, at 16:48, Jukka Zitting wrote: On Tue, Apr 21, 2009 at 12:12 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Thanks to everyone who's been participating in writing up the proposal; I think it's soon ready to be voted on! See [1] for the current status. [1] http://wiki.apache.org/incubator/ChemistryProposal I just filled in the last TODO entries and I feel that the proposal is pretty much complete now. Are there any points that still should be clarified or changed? Thanks Jukka. Looks good. Note that I'll need Metro bindings for WS as well, as we want to test interop with both CXF and Metro. But the core code should be generic in any case. Also I had envisionned the Jackrabbit-specific backend living in the Jackrabbit project, to simplify inter-projects dependency management (as Chemistry is an infrastructure project). I don't know what the Apache policy is for such things. I'll commit more code in our tree tomorrow or during the WE. In particular, for those who have looked at the existing APIs, I want to: - stop using enums where an implementation may potentially want extensibility (property types are the main use case), - commit the start of some SOAP bindings (that were used for the AIIM demo), - completely separate the SPI (that model the wire protocols) from the high-level API that users will manipulate (Document, Folder, etc.) - have a default implementation of the API on top of any implementor of the SPI. Bye, Florent -- Florent Guillaume, Head of RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Content Technology track at the ApacheCon US 2009
Hi, See below for the proposal that I sent to the conference planners. BR, Jukka Zitting The Jackrabbit and Sling projects would like to organize a Content Technology track at the ApacheCon US 2009. The track would be focused on content repositories and content management based on the JCR and CMIS standards. We estimate that we could do something like a half-day track followed by a more informal meetup in the evening. This would be a natural extension to the meetups and normal sessions we've had in previous ApacheCons. We could also enlarge the scope of the track to cover a wider range of projects like Cocoon, Lenya, Portals, POI, etc. in which case the track could cover even something like 1-2 days. However, such plans are mostly speculative at the moment. The target audience of this track would mostly consist of web developers and CMS (both web and enterprise) developers and integrators. We might also do a more business-oriented session on the current status of standardization in the content management industry.
Re: Incubating Chemistry
Hi, On Thu, Apr 23, 2009 at 5:07 PM, Florent Guillaume f...@nuxeo.com wrote: Note that I'll need Metro bindings for WS as well, as we want to test interop with both CXF and Metro. But the core code should be generic in any case. OK, cool. Metro looks like it could be a bit troublesome from a licensing perspective (didn't look too closely), but it should be fine as long as it's just an optional or test dependency. Also I had envisionned the Jackrabbit-specific backend living in the Jackrabbit project, to simplify inter-projects dependency management (as Chemistry is an infrastructure project). Sure, makes perfect sense. The way I see it, Chemistry would contain a generic CMIS-to-JCR bridge and Jackrabbit would use that bridge to CMIS-enable the repository. I updated the proposal accordingly. BR, Jukka Zitting
Re: [VOTE] Approve Chemistry for Incubation
Hi, [x] +1 Approve the Chemistry project for incubation BR, Jukka Zitting
Re: [VOTE] Approve Chemistry for Incubation
[x] +1 Approve the Chemistry project for incubation regards, toby
[jira] Created: (JCR-2081) NameSet does not propery implement equals(Object) method, causes ISM to fail merge check
NameSet does not propery implement equals(Object) method, causes ISM to fail
merge check
Key: JCR-2081
URL: https://issues.apache.org/jira/browse/JCR-2081
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.5.4
Environment:
org.apache.jackrabbit.core.state.SharedItemStateManager:begin()
org.apache.jackrabbit.core.state.NameSet:equals(Object)
org.apache.jackrabbit.core.state.NodeStateMerger:merge(NodeState,MergeContext)
Reporter: Damon A. Brown
Priority: Critical
The merge context uses the NameSet.equals(NameSet) method to compare two sets;
however, the NameSet class does not override the default Object.equals(Object)
method, and does not inherit from AbstractSetE. Therefore, the merge check
fails, even though the mixin sets are the same. Object instance equivalence is
being performed as opposed to set equivalence. Behavior is observed when more
than one thread is checking the ISM at a given time. Demonstration code
available upon request.
From NodeStateMerger, line 83:
// mixin types
if
(!state.getMixinTypeNames().equals(overlayedState.getMixinTypeNames())) {
// the mixins have been modified but by just looking at the
diff we
// can't determine where the change happened since the
diffs of either
// removing a mixin from the overlayed or adding a mixin to
the
// transient state would look identical...
return false;
}
Proposed solution:
- Implement NameSet.equals(...) method:
public boolean equals(Object obj) {
if (obj != null obj instanceof NameSet) {
NameSet oo = (NameSet) obj;
return oo.names.equals(this.names);
}
return false;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Approve Chemistry for Incubation
[x] +1 Approve the Chemistry project for incubation Regards, Thomas
Re: Incubating Chemistry
Hi, Jukka Zitting schrieb: Hi, On Thu, Apr 23, 2009 at 5:07 PM, Florent Guillaume f...@nuxeo.com wrote: Note that I'll need Metro bindings for WS as well, as we want to test interop with both CXF and Metro. But the core code should be generic in any case. OK, cool. Metro looks like it could be a bit troublesome from a licensing perspective (didn't look too closely), but it should be fine as long as it's just an optional or test dependency. Also I had envisionned the Jackrabbit-specific backend living in the Jackrabbit project, to simplify inter-projects dependency management (as Chemistry is an infrastructure project). Sure, makes perfect sense. The way I see it, Chemistry would contain a generic CMIS-to-JCR bridge and Jackrabbit would use that bridge to CMIS-enable the repository. I updated the proposal accordingly. That the Jackrabbit backend resides in Jackrabbit makes perfect sense to me. How about Chemistry starting off with a first implementation of that backend, which could then be migrated to the Jackrabbit project once the interfaces and implementation have stabilized a bit ? Regards Felix
Re: [VOTE] Approve Chemistry for Incubation
Hi, [X] +1 Approve the Chemistry project for incubation Thanks for driving this, Jukka. Regards Felix
