[jira] [Commented] (JCRVLT-198) Creating a package with specific path fails to import
[
https://issues.apache.org/jira/browse/JCRVLT-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126834#comment-16126834
]
Tobias Bocanegra commented on JCRVLT-198:
-
another problem is that filenames with the pattern: "_x1234_" are turned into
their unicode equivalent.
> Creating a package with specific path fails to import
> -
>
> Key: JCRVLT-198
> URL: https://issues.apache.org/jira/browse/JCRVLT-198
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.38
>Reporter: Will McGauley
>Assignee: Tobias Bocanegra
> Attachments: bad_content_package.zip
>
>
> creating a package containing a path such as
> /content/dam/chinook/Spr16_PR_T_001_x0009_VS_R1.tif fails to re-import,
> giving the following error: [0]
> It appears that a decoding tool is used to decode the filename and is
> treating the "_x0009_" portion as the ascii code 009 (tab)
> The decoding is happening on line 579 of DocViewSaxImporter.java:
> {code} String label = ISO9075.decode(qName);
> String name = label;
> {code}
> Please see the attached package for an example.
> [0]
> {noformat}
> org.apache.jackrabbit.vault.packaging.PackageException:
> javax.jcr.RepositoryException: OakName0003: Invalid name:
> Spr16_PR_T_001\tVS_R1.tif
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:239)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:396)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:356)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:350)
> .
> .
> .
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakName0003:
> Invalid name: Spr16_PR_T_001\tVS_R1.tif
> at
> org.apache.jackrabbit.oak.plugins.name.NameValidator.checkValidName(NameValidator.java:91)
> at
> org.apache.jackrabbit.oak.plugins.name.NameValidator.childNodeAdded(NameValidator.java:139)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (JCRVLT-198) Creating a package with specific path fails to import
[
https://issues.apache.org/jira/browse/JCRVLT-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCRVLT-198:
---
Assignee: Tobias Bocanegra
> Creating a package with specific path fails to import
> -
>
> Key: JCRVLT-198
> URL: https://issues.apache.org/jira/browse/JCRVLT-198
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.38
>Reporter: Will McGauley
>Assignee: Tobias Bocanegra
> Attachments: bad_content_package.zip
>
>
> creating a package containing a path such as
> /content/dam/chinook/Spr16_PR_T_001_x0009_VS_R1.tif fails to re-import,
> giving the following error: [0]
> It appears that a decoding tool is used to decode the filename and is
> treating the "_x0009_" portion as the ascii code 009 (tab)
> The decoding is happening on line 579 of DocViewSaxImporter.java:
> {code} String label = ISO9075.decode(qName);
> String name = label;
> {code}
> Please see the attached package for an example.
> [0]
> {noformat}
> org.apache.jackrabbit.vault.packaging.PackageException:
> javax.jcr.RepositoryException: OakName0003: Invalid name:
> Spr16_PR_T_001\tVS_R1.tif
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:239)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:396)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:356)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:350)
> .
> .
> .
> Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakName0003:
> Invalid name: Spr16_PR_T_001\tVS_R1.tif
> at
> org.apache.jackrabbit.oak.plugins.name.NameValidator.checkValidName(NameValidator.java:91)
> at
> org.apache.jackrabbit.oak.plugins.name.NameValidator.childNodeAdded(NameValidator.java:139)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-197) AggregateImpl.includesProperty fails with multiple filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126830#comment-16126830
]
Tobias Bocanegra commented on JCRVLT-197:
-
the problem is that the 2 filtersets are disconnected. updated (failing) tests
in:
https://github.com/tripodsan/jackrabbit-filevault/tree/JCRVLT-197/
> AggregateImpl.includesProperty fails with multiple filter roots
> ---
>
> Key: JCRVLT-197
> URL: https://issues.apache.org/jira/browse/JCRVLT-197
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Reporter: Jeremy Judeaux
>Assignee: Tobias Bocanegra
>
> If I set multiple filter roots in my configuration, properties will not be
> handled correctly.
> Tested with 3.1.28 and trunk (about 3.1.40)
> Example of failing configuration:
> {code:xml}
>
>
>
>
>
>
>
>
> {code}
> Reproducing tests:
> (I copied the algorithm for simplicity. It would be easier to test if the
> function is moved to {{WorkspaceFilter}})
> {code:java}
> package org.apache.jackrabbit.vault.fs.impl;
> import org.apache.jackrabbit.vault.fs.api.PathFilterSet;
> import org.apache.jackrabbit.vault.fs.api.WorkspaceFilter;
> import org.apache.jackrabbit.vault.fs.config.DefaultWorkspaceFilter;
> import org.apache.jackrabbit.vault.fs.filter.DefaultPathFilter;
> import org.junit.Assert;
> import org.junit.Test;
> public class AggregateImplTest {
> // Copied from AggregateImpl
> private boolean includesProperty(String propertyPath, WorkspaceFilter
> workspaceFilter) {
> for (PathFilterSet filterSet :
> workspaceFilter.getPropertyFilterSets()) {
> if (!filterSet.contains(propertyPath)) {
> return false;
> }
> }
> return true;
> }
> @Test
> public void testIncludesPropertyExpected() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set1 = new PathFilterSet("/foo");
> set1.seal();
> workspaceFilter.addPropertyFilterSet(set1);
> PathFilterSet set2 = new PathFilterSet("/bar");
> set2.addExclude(new DefaultPathFilter(".*/jcr:mixinTypes"));
> set2.seal();
> workspaceFilter.addPropertyFilterSet(set2);
> Assert.assertTrue(includesProperty("/foo/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertTrue(includesProperty("/foo/node/jcr:mixinTypes",
> workspaceFilter));
> Assert.assertTrue(includesProperty("/bar/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertFalse(includesProperty("/bar/node/jcr:mixinTypes",
> workspaceFilter));
> }
> @Test
> public void testIncludesPropertyCurrentlyWorking1() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set1 = new PathFilterSet("/foo");
> set1.seal();
> workspaceFilter.addPropertyFilterSet(set1);
> Assert.assertTrue(includesProperty("/foo/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertTrue(includesProperty("/foo/node/jcr:mixinTypes",
> workspaceFilter));
> }
> @Test
> public void testIncludesPropertyCurrentlyWorking2() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set2 = new PathFilterSet("/bar");
> set2.addExclude(new DefaultPathFilter(".*/jcr:mixinTypes"));
> set2.seal();
> workspaceFilter.addPropertyFilterSet(set2);
> Assert.assertTrue(includesProperty("/bar/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertFalse(includesProperty("/bar/node/jcr:mixinTypes",
> workspaceFilter));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (JCRVLT-197) AggregateImpl.includesProperty fails with multiple filter roots
[
https://issues.apache.org/jira/browse/JCRVLT-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCRVLT-197:
---
Assignee: Tobias Bocanegra
> AggregateImpl.includesProperty fails with multiple filter roots
> ---
>
> Key: JCRVLT-197
> URL: https://issues.apache.org/jira/browse/JCRVLT-197
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Reporter: Jeremy Judeaux
>Assignee: Tobias Bocanegra
>
> If I set multiple filter roots in my configuration, properties will not be
> handled correctly.
> Tested with 3.1.28 and trunk (about 3.1.40)
> Example of failing configuration:
> {code:xml}
>
>
>
>
>
>
>
>
> {code}
> Reproducing tests:
> (I copied the algorithm for simplicity. It would be easier to test if the
> function is moved to {{WorkspaceFilter}})
> {code:java}
> package org.apache.jackrabbit.vault.fs.impl;
> import org.apache.jackrabbit.vault.fs.api.PathFilterSet;
> import org.apache.jackrabbit.vault.fs.api.WorkspaceFilter;
> import org.apache.jackrabbit.vault.fs.config.DefaultWorkspaceFilter;
> import org.apache.jackrabbit.vault.fs.filter.DefaultPathFilter;
> import org.junit.Assert;
> import org.junit.Test;
> public class AggregateImplTest {
> // Copied from AggregateImpl
> private boolean includesProperty(String propertyPath, WorkspaceFilter
> workspaceFilter) {
> for (PathFilterSet filterSet :
> workspaceFilter.getPropertyFilterSets()) {
> if (!filterSet.contains(propertyPath)) {
> return false;
> }
> }
> return true;
> }
> @Test
> public void testIncludesPropertyExpected() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set1 = new PathFilterSet("/foo");
> set1.seal();
> workspaceFilter.addPropertyFilterSet(set1);
> PathFilterSet set2 = new PathFilterSet("/bar");
> set2.addExclude(new DefaultPathFilter(".*/jcr:mixinTypes"));
> set2.seal();
> workspaceFilter.addPropertyFilterSet(set2);
> Assert.assertTrue(includesProperty("/foo/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertTrue(includesProperty("/foo/node/jcr:mixinTypes",
> workspaceFilter));
> Assert.assertTrue(includesProperty("/bar/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertFalse(includesProperty("/bar/node/jcr:mixinTypes",
> workspaceFilter));
> }
> @Test
> public void testIncludesPropertyCurrentlyWorking1() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set1 = new PathFilterSet("/foo");
> set1.seal();
> workspaceFilter.addPropertyFilterSet(set1);
> Assert.assertTrue(includesProperty("/foo/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertTrue(includesProperty("/foo/node/jcr:mixinTypes",
> workspaceFilter));
> }
> @Test
> public void testIncludesPropertyCurrentlyWorking2() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set2 = new PathFilterSet("/bar");
> set2.addExclude(new DefaultPathFilter(".*/jcr:mixinTypes"));
> set2.seal();
> workspaceFilter.addPropertyFilterSet(set2);
> Assert.assertTrue(includesProperty("/bar/node/jcr:primaryType",
> workspaceFilter));
> Assert.assertFalse(includesProperty("/bar/node/jcr:mixinTypes",
> workspaceFilter));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (JCRVLT-196) Add remapping support for other than renames
[
https://issues.apache.org/jira/browse/JCRVLT-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-196.
-
Resolution: Fixed
added last changes in r1805053
> Add remapping support for other than renames
>
>
> Key: JCRVLT-196
> URL: https://issues.apache.org/jira/browse/JCRVLT-196
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Affects Versions: 3.1.40
>Reporter: Simone Tripodi
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
> Attachments: JCRVLT-196.patch
>
>
> In SLING-7017 we needed to add support to remap resources and thought VLT
> APIs would have taken care of this, unfortunately we stumbled in the warning
> message
> {noformat}
> remapping other than renames not supported yet
> {noformat}
> So the desired/expected action had no effect.
> Would it be possible to have it available? Is there any way to enable this
> behaviour already?
> TIA!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (JCR-4171) Conditions that are always true.
[
https://issues.apache.org/jira/browse/JCR-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved JCR-4171.
---
Resolution: Invalid
This is a non-final class and subclasses such as {{DerbyPersistenceManager}}
and {{PostgreSQLPersistenceManager}} override this method and return a
different value.
This works as designed.
> Conditions that are always true.
>
>
> Key: JCR-4171
> URL: https://issues.apache.org/jira/browse/JCR-4171
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: core
>Reporter: JC
>Priority: Trivial
>
> Hi
> In a recent Github mirror, I found conditions that are always true.
> Path:
> jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/pool/BundleDbPersistenceManager.java
> {code:java}
> 92 /** storage model modifier: binary keys */
> 93 public static final int SM_BINARY_KEYS = 1;
> 94
> ...
> 666 public int getStorageModel() {
> 667 return SM_BINARY_KEYS;
> 668 }
> ...
> 732 protected Object[] getKey(NodeId id) {
> 733 if (getStorageModel() == SM_BINARY_KEYS) {
> 734 return new Object[] { id.getRawBytes() };
> 735 } else {
> 736 return new Object[] {
> 737 id.getMostSignificantBits(),
> id.getLeastSignificantBits () };
> 738 }
> ...
> {code}
> The condition in Line 733 seems always return true. I've found similar lines
> in Line 754, 800, 852 and . These are just trivial things but there are
> else blocks. As I thought the conditions should do something more rather than
> being always true, I'm reporting them just in case.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JCR-4172) JCAManagedConnection only considers the most recent handle when getting session
Chris Poulsen created JCR-4172:
--
Summary: JCAManagedConnection only considers the most recent
handle when getting session
Key: JCR-4172
URL: https://issues.apache.org/jira/browse/JCR-4172
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jca
Affects Versions: 2.15.5
Environment: JTA/JCA enabled env.
Reporter: Chris Poulsen
The code for checking JCASessionHandle validity only considers the most recent
handle, even though there are several valid handles for the underlying session.
Steps to reproduce in a JCA environment:
Start TX
Session s1 = repository.login( credentials() );
Session s2 = repository.login( credentials() );
s1.getRootNode();
The exception thrown is:
java.lang.IllegalStateException: Inactive logical session handle called
at
org.apache.jackrabbit.jca.JCAManagedConnection.getSession(JCAManagedConnection.java:350)
at
org.apache.jackrabbit.jca.JCASessionHandle.getSession(JCASessionHandle.java:90)
at
org.apache.jackrabbit.jca.JCASessionHandle.getRootNode(JCASessionHandle.java:141)
at AppTest$3.doInTransactionWithoutResult(AppTest.java:121)
at
org.springframework.transaction.support.TransactionCallbackWithoutResult.doInTransaction(TransactionCallbackWithoutResult.java:34)
at
org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:139)
at AppTest.txSessionAffinity(AppTest.java:115)
The getSession looks like this:
/**
* Return the session.
*/
public Session getSession(JCASessionHandle handle) {
synchronized (handles) {
if ((handles.size() > 0) && (handles.get(0) == handle)) {
return session;
} else {
throw new java.lang.IllegalStateException("Inactive logical
session handle called");
}
}
}
I think the:
if ((handles.size() > 0) && (handles.get(0) == handle)) {
Should be:
if ( handles.contains( handle ) ) {
I've tried rolling my own JCA archive with this code and then things work like
expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCR-4172) JCAManagedConnection only considers the most recent handle when getting session
[
https://issues.apache.org/jira/browse/JCR-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Poulsen updated JCR-4172:
---
Attachment: jca-managed-connection-get-session-fix.patch
attach patch
> JCAManagedConnection only considers the most recent handle when getting
> session
> ---
>
> Key: JCR-4172
> URL: https://issues.apache.org/jira/browse/JCR-4172
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jca
>Affects Versions: 2.15.5
> Environment: JTA/JCA enabled env.
>Reporter: Chris Poulsen
> Attachments: jca-managed-connection-get-session-fix.patch
>
>
> The code for checking JCASessionHandle validity only considers the most
> recent handle, even though there are several valid handles for the underlying
> session.
> Steps to reproduce in a JCA environment:
> Start TX
> Session s1 = repository.login( credentials() );
> Session s2 = repository.login( credentials() );
> s1.getRootNode();
> The exception thrown is:
> java.lang.IllegalStateException: Inactive logical session handle called
> at
> org.apache.jackrabbit.jca.JCAManagedConnection.getSession(JCAManagedConnection.java:350)
> at
> org.apache.jackrabbit.jca.JCASessionHandle.getSession(JCASessionHandle.java:90)
> at
> org.apache.jackrabbit.jca.JCASessionHandle.getRootNode(JCASessionHandle.java:141)
> at AppTest$3.doInTransactionWithoutResult(AppTest.java:121)
> at
> org.springframework.transaction.support.TransactionCallbackWithoutResult.doInTransaction(TransactionCallbackWithoutResult.java:34)
> at
> org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:139)
> at AppTest.txSessionAffinity(AppTest.java:115)
> The getSession looks like this:
> /**
> * Return the session.
> */
> public Session getSession(JCASessionHandle handle) {
> synchronized (handles) {
> if ((handles.size() > 0) && (handles.get(0) == handle)) {
> return session;
> } else {
> throw new java.lang.IllegalStateException("Inactive logical
> session handle called");
> }
> }
> }
> I think the:
> if ((handles.size() > 0) && (handles.get(0) == handle)) {
> Should be:
> if ( handles.contains( handle ) ) {
> I've tried rolling my own JCA archive with this code and then things work
> like expected.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
