[jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637396#action_12637396 ] Boni Gopalan commented on JCR-1784: --- We seem to be going back and forth with this AbstractMapperImpl change I made. I had a problem with that throws clause and unfortunately I need to spend some time to recreate the test scenario that required me to change the implementation. If I remove the throws clause I know that a few of my application testcases will fail. I will work out a testcase that I hope will convince you the need to remove that throws. Till then I completely am with you on keeping AbstractMapperImpl as is. I came across a similar issue with update elsewhere. Consider same name sibling nodes with UUID specified. Though these are not part of a collection it very well act as those are collection elements. However since the code handles the mapping from directly within ObjectConverterImpl's update method we need to make that update as well intelligent enough to decipher uniqueness through UUID. I have a patch and I will add it to this discussion. OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5 Attachments: JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boni Gopalan updated JCR-1784: -- Attachment: JCR-1784.additional.bonigopalan I also did a bit of code cleanup to remove some repeating code. Basically I saw the approach to update a Node to be : Locate the node to update and then update it. So I introduce a method that takes in the session, Node to Update and the Object to Update to as parameters and does the updating. This methos is called from the other facade methods that already existed for doing the updates. Eliminated the code duplication. All the tests are passing. OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5 Attachments: JCR-1784.additional.bonigopalan, JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Landelle updated JCR-1788:
---
Attachment: maven-filtering-test.zip
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: Leopard, maven 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1788) Maven variable collision
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: Leopard, maven 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to change
the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637456#action_12637456
]
Thomas Mueller commented on JCR-1788:
-
Hi Stephane,
I couldn't find out where Maven 2.1.0-M1 uses the term 'wsp.name'. Do you have
a link?
Regards,
Thomas
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: Leopard, maven 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
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 release plan
Does anyone have any blocking concerns about the 1.5 release? JCR-1765 Config: make all elements in the security configuration optional it's done with that but i didn't commit it yet. JCR-1783 JCR2SPI: incomplete changelog... i am working on that right now. angela
[jira] Resolved: (JCR-1789) Provide access to cluster records
[ https://issues.apache.org/jira/browse/JCR-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved JCR-1789. Resolution: Fixed Fix Version/s: 1.5 Fixed in revision 702459. Provide access to cluster records - Key: JCR-1789 URL: https://issues.apache.org/jira/browse/JCR-1789 Project: Jackrabbit Issue Type: Improvement Components: clustering Affects Versions: core 1.4.5 Reporter: Dominique Pfister Assignee: Dominique Pfister Fix For: 1.5 Cluster records are read/written inside o.a.j.core.cluster.ClusterNode in private methods. In order to support tools such as a journal walker that would display human readable descriptions of cluster records, these inner workings should be made public. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1790) terminology: source uses protected property for something that only only indirectly has to do with that term
terminology: source uses protected property for something that only only indirectly has to do with that term --- Key: JCR-1790 URL: https://issues.apache.org/jira/browse/JCR-1790 Project: Jackrabbit Issue Type: Task Components: jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Documentation and method names (DavProperty) use protected as pseudonym for return upon PROPFIND/allprop. This isn't really accurate, because the live properties defined in RFC2518/4918 *are* protected, but are returned with PROPFIND/allprop nevertheless. Proposal: update documentation and method names to say something like visibleInAllprop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1791) New utility: Journal walker for journal files
New utility: Journal walker for journal files - Key: JCR-1791 URL: https://issues.apache.org/jira/browse/JCR-1791 Project: Jackrabbit Issue Type: New Feature Components: clustering Affects Versions: core 1.4.5 Reporter: Dominique Pfister Priority: Minor Given the cluster record access provided by JCR-1789, add a journal walker utiltity that provides descriptive information about the contents of journal records. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1791) New utility: Journal walker for journal files
[ https://issues.apache.org/jira/browse/JCR-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved JCR-1791. Resolution: Fixed Added jackrabbit-journalwalker to sandbox, in revision 702482. New utility: Journal walker for journal files - Key: JCR-1791 URL: https://issues.apache.org/jira/browse/JCR-1791 Project: Jackrabbit Issue Type: New Feature Components: clustering Affects Versions: core 1.4.5 Reporter: Dominique Pfister Assignee: Dominique Pfister Priority: Minor Given the cluster record access provided by JCR-1789, add a journal walker utiltity that provides descriptive information about the contents of journal records. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637493#action_12637493
]
Stephane Landelle commented on JCR-1788:
Possible an old bug in maven is back:
http://jira.codehaus.org/browse/MRESOURCES-20?focusedCommentId=74186
2008/10/7 Thomas Mueller (JIRA) [EMAIL PROTECTED]
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: maven 2.0.9, 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1790) terminology: source uses protected property for something that only only indirectly has to do with that term
[ https://issues.apache.org/jira/browse/JCR-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-1790. - Resolution: Fixed Done with revision 702481. terminology: source uses protected property for something that only only indirectly has to do with that term --- Key: JCR-1790 URL: https://issues.apache.org/jira/browse/JCR-1790 Project: Jackrabbit Issue Type: Task Components: jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Documentation and method names (DavProperty) use protected as pseudonym for return upon PROPFIND/allprop. This isn't really accurate, because the live properties defined in RFC2518/4918 *are* protected, but are returned with PROPFIND/allprop nevertheless. Proposal: update documentation and method names to say something like visibleInAllprop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1790) terminology: source uses protected property for something that only only indirectly has to do with that term
[ https://issues.apache.org/jira/browse/JCR-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1790: Fix Version/s: 1.5 Issue Type: Bug (was: Task) terminology: source uses protected property for something that only only indirectly has to do with that term --- Key: JCR-1790 URL: https://issues.apache.org/jira/browse/JCR-1790 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.5 Documentation and method names (DavProperty) use protected as pseudonym for return upon PROPFIND/allprop. This isn't really accurate, because the live properties defined in RFC2518/4918 *are* protected, but are returned with PROPFIND/allprop nevertheless. Proposal: update documentation and method names to say something like visibleInAllprop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1782) Destination header not containing URI scheme causes NPE
[ https://issues.apache.org/jira/browse/JCR-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1782: Fix Version/s: 1.5 Destination header not containing URI scheme causes NPE --- Key: JCR-1782 URL: https://issues.apache.org/jira/browse/JCR-1782 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.5 In WebDAVRequestImpl. getDestinationLocator assumes that URI.getAuthority is always non-null. In RFC2518, a full URI is indeed required, but the NPE causes a status of 500, instead of 400 as expected. In RFC4918, an absolute path is allowed. Proposal: delegate to gethrefLocator, which already does the right thing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to stable: Jackrabbit-t runk » Jackrabbit Object Content Mapping #216
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-ocm/216/changes
[jira] Updated: (JCR-1769) RFC4918 feature: PROPFIND/include
[ https://issues.apache.org/jira/browse/JCR-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1769: Fix Version/s: 1.5 RFC4918 feature: PROPFIND/include - Key: JCR-1769 URL: https://issues.apache.org/jira/browse/JCR-1769 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.5 Attachments: JCR-1769.diff RFC4918, Section 14.8 (http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.14.8) defines an extension to PROPFIND that allows clients to retrieve all RFC2518 properties, the dead properties, plus a set of additional live properties. This can help avoiding a second roundtrip to retrieve really all properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1733) WebDAV BIND support
[ https://issues.apache.org/jira/browse/JCR-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1733: Fix Version/s: 1.5 Issue Type: New Feature (was: Task) WebDAV BIND support --- Key: JCR-1733 URL: https://issues.apache.org/jira/browse/JCR-1733 Project: Jackrabbit Issue Type: New Feature Components: jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.5 Attachments: jcr1733-bindsupport.patch, patch-resourceid.txt I'm tempted to work on implementing the WebDAV BIND protocol, as currently defined in http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-20.html. This issue can be used to collect design proposals and track progress. 1) DAV:resource-id live property This can be implemented in terms of the JCR UUID. However, we need to turn this one into a URI for WebDAV. If the JCR UUID happens to *really* use UUID syntax, we *could* use urn:uuid. Otherwise, it would probably useful to mint an HTTP URI, served by the WebDAV servlet. (note that the latter has the disadvantage that moving a node to a different server will affect its resource-id, in case that other server allows importing UUIDs). 2) REBIND and UNBIND methods Same as MOVE and DELETE, with the excpetion of marshalling. 3) DAV:parent-set property Either trivial (when node isn't shared), or needs to use the JCR 2.0 shared set functionality. 4) BIND method Either trivial (when shareable nodes aren't supported), or needs to use the JCR 2.0 shared set functionality. 5) Cycle detection in depth:infinity requests TBD :-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller updated JCR-1788:
Environment: maven 2.0.9, 2.1.0-M1 (was: Leopard, maven 2.1.0-M1)
The same problem occurs with Maven 2.0.9 and Windows XP. The 'wsp' prefix
doesn't seem to be the problem:
Even ${abc.name} is replaced with the project name. However ${jr.wsp.name} is
not replaced.
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: maven 2.0.9, 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1789) Provide access to cluster records
Provide access to cluster records - Key: JCR-1789 URL: https://issues.apache.org/jira/browse/JCR-1789 Project: Jackrabbit Issue Type: Improvement Components: clustering Affects Versions: core 1.4.5 Reporter: Dominique Pfister Assignee: Dominique Pfister Cluster records are read/written inside o.a.j.core.cluster.ClusterNode in private methods. In order to support tools such as a journal walker that would display human readable descriptions of cluster records, these inner workings should be made public. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1790) terminology: source uses protected property for something that only only indirectly has to do with that term
[ https://issues.apache.org/jira/browse/JCR-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1790: Component/s: jackrabbit-jcr-server terminology: source uses protected property for something that only only indirectly has to do with that term --- Key: JCR-1790 URL: https://issues.apache.org/jira/browse/JCR-1790 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr-server, jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Fix For: 1.5 Documentation and method names (DavProperty) use protected as pseudonym for return upon PROPFIND/allprop. This isn't really accurate, because the live properties defined in RFC2518/4918 *are* protected, but are returned with PROPFIND/allprop nevertheless. Proposal: update documentation and method names to say something like visibleInAllprop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1783) JCR2SPI: incomplete changelog when combining move with removal of new destination parent
[ https://issues.apache.org/jira/browse/JCR-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1783: Fix Version/s: 1.5 JCR2SPI: incomplete changelog when combining move with removal of new destination parent Key: JCR-1783 URL: https://issues.apache.org/jira/browse/JCR-1783 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr2spi Reporter: angela Assignee: angela Fix For: 1.5 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637473#action_12637473
]
Thomas Mueller commented on JCR-1788:
-
I'm not a Maven 'specialist', and I can't find the documentation in Maven about
filtering.
Does somebody with better Maven knowledge have some insight why this happens,
if there is a workaround (maybe an escape sequence), or if this is a Maven bug?
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: maven 2.0.9, 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1769) RFC4918 feature: PROPFIND/include
[ https://issues.apache.org/jira/browse/JCR-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-1769. - Resolution: Fixed Patch applied with revision 702428. RFC4918 feature: PROPFIND/include - Key: JCR-1769 URL: https://issues.apache.org/jira/browse/JCR-1769 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1769.diff RFC4918, Section 14.8 (http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.14.8) defines an extension to PROPFIND that allows clients to retrieve all RFC2518 properties, the dead properties, plus a set of additional live properties. This can help avoiding a second roundtrip to retrieve really all properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build became unstable: Jackrabbit-tr unk » Jackrabbit Object Content Mapping #215
See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-ocm/215/changes
[jira] Commented: (JCR-1788) Maven variable collision
[
https://issues.apache.org/jira/browse/JCR-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637460#action_12637460
]
Stephane Landelle commented on JCR-1788:
Hi Thomas,
I haven't found anything in the official documentation yet, but that's no
surprise, it's not really up-to-date...
If you install the attached project, you'll see that ${wsp.name} has indeed
been replaced by Maven Filtering Test Project Name which is the name
declared in the pom.
I'll try to find a reference in the documentation or even the code, but I'm
quite pessimistic...
Sincererly,
Stephane
2008/10/7 Thomas Mueller (JIRA) [EMAIL PROTECTED]
Maven variable collision
Key: JCR-1788
URL: https://issues.apache.org/jira/browse/JCR-1788
Project: Jackrabbit
Issue Type: Bug
Components: config
Environment: Leopard, maven 2.1.0-M1
Reporter: Stephane Landelle
Attachments: maven-filtering-test.zip
Original Estimate: 0.08h
Remaining Estimate: 0.08h
The jackrabbit config file uses a variable ${wsp.name}.
This variable name is already used by maven during filtering and holds the
project name.
As a consequence, when trying to filter the file in order for example to
change the Cluster Node Id, the file gets corrupted.
Please find test project enclosed.
Patch is very simple : you can keep old variables for compatibility, just
duplicate variable with a jackrabbit specific name such as jr.wsp.name and
add in org.apache.jackrabbit.core.config.RepositoryConfigurationParser:
line 62:
/** Name of the repository name parser variable. */
public static final String MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE =
jr.wsp.name;
line 420:
// add a dupplicate that supports maven filtering
tmpVariables.put(MAVEN_SUPPORTING_WORKSPACE_NAME_VARIABLE, name);
This should even be done for other variables to avoid possible later
collisions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boni Gopalan reopened JCR-1784: --- OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5 Attachments: JCR-1784.additional.bonigopalan, JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- 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 release plan
Hi, On Wed, Apr 16, 2008 at 4:29 PM, Jukka Zitting [EMAIL PROTECTED] wrote: As discussed after the 1.4 release, there's still a lot we can and should do to improve the out of the box experience with Jackrabbit. I think this should be the primary goal for Jackrabbit 1.5, and thus I consider the issues JCR-1455 (content explorer) and JCR-1357 (quick start) to be the driving features of the 1.5 release. [...] I'd like to push for us to have the release out during this quarter, i.e. by the end of June. The long delay between 1.3 and 1.4 was IMHO a mistake, and I'd like to work towards a schedule where we'd have a new minor release roughly once per quarter. Where necessary I'd rather postpone features than releases. We couldn't keep the original schedule, and there's still not much progress on JCR-1455 (content explorer), so I'd like to drop that from the 1.5 roadmap. This way we can move forward with the release. Does anyone have any blocking concerns about the 1.5 release? BR, Jukka Zitting
[jira] Resolved: (JCR-1775) Transaction-safe versioning
[ https://issues.apache.org/jira/browse/JCR-1775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1775. Resolution: Fixed Fixed in trunk. I have streamlined a number of the versioning operations and made sure that all versioning changes are persisted strictly before they get referenced in normal workspace content. Transaction-safe versioning --- Key: JCR-1775 URL: https://issues.apache.org/jira/browse/JCR-1775 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, transactions, versioning Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 1.5 I've been working on a partial fix to JCR-630. Instead of implementing fully transactional versioning (i.e. a checkin will disappear when a transactin is rolled back), I'm ensuring that all versioning operations within a transaction will leave the version store in a consistent state even if the transaction otherwise fails at any point. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1792) jcr:frozenUuid does not contain jcr:content
jcr:frozenUuid does not contain jcr:content
---
Key: JCR-1792
URL: https://issues.apache.org/jira/browse/JCR-1792
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: core 1.4.5
Environment: tomcat, jackrabbit deployed inside webapp, xml
persistance, webdav enabled
Reporter: Nicholas DiPiazza
When I store versionable files, I get problems retrieving the jcr:data from a
custom node type.
I am storing a node type:
xrc:learningContent
pd: xrc:Keywords
pd: xrc:MimeType
pd: jcr:mixinTypes
pd: xrc:Description
pd: xrc:Language
pd: xrc:Creator
pd: jcr:created
pd: xrc:Title
pd: jcr:primaryType
Extends: nt:resource
pd: jcr:uuid
pd: jcr:mixinTypes
pd: jcr:data
pd: jcr:encoding
pd: jcr:mimeType
pd: jcr:lastModified
pd: jcr:primaryType
So I commit the changes, then later pull up the version and get it's frozenNode.
Node frozenNode = v.getNode(JcrConstants.JCR_FROZENNODE);
And then I return all of the properties contained within:
PropertyIterator pi = frozenNode.getProperties();
while (pi.hasNext()) {
System.out.println(pi.nextProperty().getName());
}
All that are returned are:
jcr:frozenUuid
jcr:uuid
jcr:frozenPrimaryType
jcr:frozenMixinTypes
jcr:primaryType
Here is the frozen node type:
nt:frozenNode
pd: *
pd: *
pd: jcr:frozenUuid
pd: jcr:uuid
pd: jcr:mixinTypes
pd: jcr:frozenPrimaryType
pd: jcr:frozenMixinTypes
pd: jcr:primaryType
So basically it would seem that the recursive copy inside the
InternalFrozenNodeImpl is not working. But it seems that is not the case from
the code trace I did. Add this to line 368 of InternalFrozenNodeImpl.java
System.out.println(New node created. Props: );
try {
PropertyState [] ps = node.getProperties();
for (PropertyState p : ps) {
System.out.println(p.getName());
System.out.println(p.toString());
}
NodeStateEx [] ns = node.getChildNodes();
for (NodeStateEx n : ns) {
System.out.println(n.getName());
System.out.println(n.toString());
}
} catch (ItemStateException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
And you will get the result:
New node created. Props:
{http://www.jcp.org/jcr/1.0}uuid
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}frozenPrimaryType
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}frozenMixinTypes
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}baseVersion
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}primaryType
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}isCheckedOut
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}frozenUuid
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}predecessors
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}data
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}versionHistory
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}encoding
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}mimeType
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}lastModified
[EMAIL PROTECTED]
New node created. Props:
{http://www.xerceo.com/learn/jcr-1.0}Keywords
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}uuid
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}frozenPrimaryType
[EMAIL PROTECTED]
{http://www.xerceo.com/learn/jcr-1.0}Creator
[EMAIL PROTECTED]
{http://www.xerceo.com/learn/jcr-1.0}Language
[EMAIL PROTECTED]
{http://www.xerceo.com/learn/jcr-1.0}Title
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}frozenMixinTypes
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}primaryType
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}frozenUuid
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}predecessors
[EMAIL PROTECTED]
{http://www.xerceo.com/learn/jcr-1.0}MimeType
[EMAIL PROTECTED]
{http://www.xerceo.com/learn/jcr-1.0}Description
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}versionHistory
[EMAIL PROTECTED]
{http://www.jcp.org/jcr/1.0}content
[EMAIL PROTECTED]
So the new Node definately has these new properties.
Do I have to somehow extend my frozenNode to work with this? Can anyone help me?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r702641 - /jackrabbit/sandbox/jackrabbit-journalwalker/README.txt
Hi, On Tue, Oct 7, 2008 at 11:19 PM, [EMAIL PROTECTED] wrote: very strange typo in year [...] -Collective work: Copyright 200 The Apache Software Foundation. +Collective work: Copyright 2008 The Apache Software Foundation. Eight times eight, looks like the numeric argument feature in Emacs. :-) BR, Jukka Zitting
