[jira] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895685#comment-16895685
]
Woonsan Ko edited comment on JCR-4458 at 7/30/19 1:08 AM:
--
Hi [~reschke],
I've submitted a new PR: https://github.com/apache/jackrabbit/pull/85
This PR solves the problem case described above with jackrabbit-boot, and it
also makes all the integrationTesting scenarios* passed. The PR includes the
servlet_path_prefix.patch in JCR-4460.
Basically, in the same way how
{{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
boolean)}} normalizes the _input_ href value by removing the contextPath prefix
if found when creating a {{DavResourceLocator}}, the PR ensures every Report or
Resource handling class to normalize the _input_ href value from the input
element when a {{DavResourceLocator}} needs to be created.
As Report handlers do not have an access to {{WebdavRequest}}, I ended up
introducing {{WebdavRequestContext}} and {{WebdavRequestContextHolder}}, which
are set and removed in {{AbstractWebdavServlet#service()}}, in order to get the
contextPath.
Please review the PR.
Thanks,
Woonsan
-
\* {{mvn clean install -PintegrationTesting}},
{{mvn clean install -PintegrationTesting -DWebDAVServletPrefix=}},
{{mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"}}
was (Author: woon_san):
Hi [~reschke],
I've submitted a new PR: https://github.com/apache/jackrabbit/pull/85
This PR solves the problem case described above with jackrabbit-boot, and it
also makes all the integrationTesting scenarios* passed. The PR includes the
servlet_path_prefix.patch in JCR-4460.
Basically, in the same way how
{{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
boolean)}} normalizes the _input_ href value by removing the contextPath prefix
if found when creating a {{DavResourceLocator}}, the PR ensures every Report or
Resource handling classes to normalize the _input_ href value from the input
element when a {{DavResourceLocator}} needs to be created.
As Report handlers do not have an access to {{WebdavRequest}}, I ended up
introducing {{WebdavRequestContext}} and {{WebdavRequestContextHolder}}, which
are set and removed in {{AbstractWebdavServlet#service()}}, in order to get the
contextPath.
Please review the PR.
Thanks,
Woonsan
-
\* {{mvn clean install -PintegrationTesting}},
{{mvn clean install -PintegrationTesting -DWebDAVServletPrefix=}},
{{mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"}}
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server";;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895685#comment-16895685
]
Woonsan Ko edited comment on JCR-4458 at 7/30/19 1:07 AM:
--
Hi [~reschke],
I've submitted a new PR: https://github.com/apache/jackrabbit/pull/85
This PR solves the problem case described above with jackrabbit-boot, and it
also makes all the integrationTesting scenarios* passed. The PR includes the
servlet_path_prefix.patch in JCR-4460.
Basically, in the same way how
{{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
boolean)}} normalizes the _input_ href value by removing the contextPath prefix
if found when creating a {{DavResourceLocator}}, the PR ensures every Report or
Resource handling classes to normalize the _input_ href value from the input
element when a {{DavResourceLocator}} needs to be created.
As Report handlers do not have an access to {{WebdavRequest}}, I ended up
introducing {{WebdavRequestContext}} and {{WebdavRequestContextHolder}}, which
are set and removed in {{AbstractWebdavServlet#service()}}, in order to get the
contextPath.
Please review the PR.
Thanks,
Woonsan
-
\* {{mvn clean install -PintegrationTesting}},
{{mvn clean install -PintegrationTesting -DWebDAVServletPrefix=}},
{{mvn clean install -PintegrationTesting -DWebDAVServletContext="/foo"}}
was (Author: woon_san):
Hi [~reschke],
I've submitted a new PR: https://github.com/apache/jackrabbit/pull/85
This PR solves the problem case described above with jackrabbit-boot, and it
also makes all the integrationTesting scenarios* passed. The PR includes the
servlet_path_prefix.patch in JCR-4460.
Basically, in the same way how
{{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
boolean)}} normalizes the _input_ href value by removing the contextPath prefix
if found when creating a {{DavResourceLocator}}, the PR ensures every Report or
Resource handling classes to normalize the _input_ href value from the input
element when a {{DavResourceLocator}} needs to be created.
As Report handlers do not have an access to {{WebdavRequest}}, I ended up
introducing {{WebdavRequestContext}} and {{WebdavRequestContextHolder}}, which
are set and removed in {{AbstractWebdavServlet#service()}}, in order to get the
contextPath.
Please review the PR.
Thanks,
Woonsan
-
\* {{mvn clean install -PintegrationTesting}}, {{mvn clean install
-PintegrationTesting -DWebDAVServletPrefix=}}, and {{mvn clean install
-PintegrationTesting -DWebDAVServletContext="/foo"}}
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server";;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895685#comment-16895685
]
Woonsan Ko commented on JCR-4458:
-
Hi [~reschke],
I've submitted a new PR: https://github.com/apache/jackrabbit/pull/85
This PR solves the problem case described above with jackrabbit-boot, and it
also makes all the integrationTesting scenarios* passed. The PR includes the
servlet_path_prefix.patch in JCR-4460.
Basically, in the same way how
{{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
boolean)}} normalizes the _input_ href value by removing the contextPath prefix
if found when creating a {{DavResourceLocator}}, the PR ensures every Report or
Resource handling classes to normalize the _input_ href value from the input
element when a {{DavResourceLocator}} needs to be created.
As Report handlers do not have an access to {{WebdavRequest}}, I ended up
introducing {{WebdavRequestContext}} and {{WebdavRequestContextHolder}}, which
are set and removed in {{AbstractWebdavServlet#service()}}, in order to get the
contextPath.
Please review the PR.
Thanks,
Woonsan
-
\* {{mvn clean install -PintegrationTesting}}, {{mvn clean install
-PintegrationTesting -DWebDAVServletPrefix=}}, and {{mvn clean install
-PintegrationTesting -DWebDAVServletContext="/foo"}}
> When JcrRemotingServlet deployed on non-root context, AclResource Webdav
> request fails
> --
>
> Key: JCR-4458
> URL: https://issues.apache.org/jira/browse/JCR-4458
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Affects Versions: 2.18.2
>Reporter: Woonsan Ko
>Assignee: Julian Reschke
>Priority: Major
>
> If {{org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet}} is
> configured in a non-root web application, the contextPath of which is "/cms"
> for example with the servletPath, "/server", then
> {{javax.jcr.Session#importXML(...)}} fails from a JCR client based on
> JCR/WebDAV. In other words, {{#importXML(...)}} fails from a JCR {{Session}}
> using a repository which can be created like the following for JCR over
> WebDAV:
> {code}
> String repositoryAddress = "http://localhost:8080/cms/server";;
> Jcr2davRepositoryFactory factory = new Jcr2davRepositoryFactory();
> Map params = new HashMap();
> params.put(JcrUtils.REPOSITORY_URI, repositoryAddress);
> Repository repository = factory.getRepository(params);
> // ...
> {code}
> It seems like that {{Session#importXML(...)}} call invokes an AclResource
> Webdav request first on the specific resource path, but
> {{org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport#init(DavResource,
> ReportInfo)}} does not remove the contextPath, "/cms" for example, when
> determining the resoucrePath.
> Unlike the {{JcrPrivilegeReport}},
> {{org.apache.jackrabbit.webdav.WebdavRequestImpl#getHrefLocator(String,
> boolean)}} seems to remove the contextPath properly.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (JCR-4458) When JcrRemotingServlet deployed on non-root context, AclResource Webdav request fails
[
https://issues.apache.org/jira/browse/JCR-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878190#comment-16878190
]
Woonsan Ko edited comment on JCR-4458 at 7/30/19 12:49 AM:
---
If you want, you can reproduce the problem easily with the two tools [1,2] to
reproduce the problem.
h2. A problem case
- Start Jackrabbit server with a servlet context path ("/cms") using [1]:
{noformat}
$ export SERVER_SERVLET_CONTEXT_PATH=/cms
$ java \
-Drepository.home=target/jackrabbit-repository \
-Drepository.config=conf/simple-repository.xml \
-Dloader.path=lib/ \
-jar target/jackrabbit-boot-0.0.1-SNAPSHOT.jar
...
{noformat}
- Start JCR Shell [2] as a JCR/WebDAV client, list nodes in the root and try to
import an XML:
{noformat}
$ cat hello.xml
http://www.jcp.org/jcr/sv/1.0";>
Hello, World!
2009-11-17T12:00:00.000Z
$ java -jar target/jcrshell-2.0.4-SNAPSHOT.jar \
--server="http://localhost:8080/cms/server"; \
--user="admin:admin"
...
exit or quit leaves program.
help lists commands.
jcr-shell:> ls
done.
---
NameType
---
jcr:system rep:system
rep:policy rep:ACL
---
Command completed in 981 msecs.
admin:/> nodeimport hello.xml
UnsupportedRepositoryOperationException while executing nodeimport: Missing
implementation
admin:/>
{noformat}
- It fails with an {{UnsupportedRepositoryOperationException}}. The server [1]
prints the following stack traces:
{noformat}
2019-07-03 17:59:52.794 ERROR 9604 --- [nio-8080-exec-1]
o.a.c.c.C.[.[.[.[jcrRemotingServlet] : Servlet.service() for servlet
[jcrRemotingServlet] in context with path [/cms] threw exception
java.lang.IllegalArgumentException: Unexpected format of resource path:
/cms/server/default/jcr:root (workspace: /cms)
at
org.apache.jackrabbit.webdav.jcr.DavLocatorFactoryImpl.getRepositoryPath(DavLocatorFactoryImpl.java:65)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.AbstractLocatorFactory$DavResourceLocatorImpl.getRepositoryPath(AbstractLocatorFactory.java:366)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.addResponses(JcrPrivilegeReport.java:130)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.version.report.JcrPrivilegeReport.init(JcrPrivilegeReport.java:114)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.version.report.ReportType.createReport(ReportType.java:72)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.AbstractResource.getReport(AbstractResource.java:513)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.jcr.WorkspaceResourceImpl.getReport(WorkspaceResourceImpl.java:88)
~[jackrabbit-jcr-server-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.doReport(AbstractWebdavServlet.java:1117)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.execute(AbstractWebdavServlet.java:416)
~[jackrabbit-webdav-2.18.2.jar!/:na]
at
org.apache.jackrabbit.webdav.server.AbstractWebdavServlet.service(AbstractWebdavServlet.java:305)
~[jackrabbit-webdav-2.18.2.jar!/:na]
...
{noformat}
-
[1] Jackrabbit-boot, https://github.com/woonsan/jackrabbit-boot
(A simple, minimalistic Jackrabbit 2 standalone application example using
Spring-boot like Jackrabbit Standalone.)
[2] https://bloomreach-forge.github.io/jcr-shell/
(An open source shell project to access remote JCR using JCR over WebDAV
protocol.)
was (Author: woon_san):
If you want, you can reproduce the problem easily with the two tools [1,2] to
reproduce the problem.
h2. A problem case
- Start Jackrabbit server with a servlet context path ("/cms") using [1]:
{noformat}
$ export SERVER_SERVLET_CONTEXT_PATH=/cms
$ java \
> -Drepository.home=target/jackrabbit-repository \
> -Drepository.config=conf/simple-repository.xml \
> -Dloader.path=lib/ \
> -jar target/jackrabbit-boot-0.0.1-SNAPSHOT.jar
...
{noformat}
- Start JCR Shell [2] as a JCR/WebDAV client, list nodes in the root and try to
import an XML:
{noformat}
$ cat hello.xml
http://www.jcp.org/jcr/sv/1.0";>
Hello, World!
2009-11-17T12:00:00.000Z
$ java -jar target/jcrshell-2.0.4-SNAPSHOT.jar \
>.--server="http://localhost:8080/cms/server"; \
>.--user="admin:admin"
...
exit or quit leaves program.
help l
[jira] [Commented] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
[
https://issues.apache.org/jira/browse/JCRVLT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895328#comment-16895328
]
angela commented on JCRVLT-340:
---
proposed patch attached
[~stillalex], fyi
> Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
> ---
>
> Key: JCRVLT-340
> URL: https://issues.apache.org/jira/browse/JCRVLT-340
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: JCRVLT-340.patch
>
>
> Request to adjust {{JackrabbitACLImporter}} and {{JcrACLManagement}} to
> handle the policies defined by the optional authorization model provided by
> OAK-8190.
>
> I will try to provide a patch and tests.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (JCRVLT-340) Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
[
https://issues.apache.org/jira/browse/JCRVLT-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCRVLT-340:
--
Attachment: JCRVLT-340.patch
> Adjust JackrabbitACLImporter to handle extensions provided by OAK-8190
> ---
>
> Key: JCRVLT-340
> URL: https://issues.apache.org/jira/browse/JCRVLT-340
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: JCRVLT-340.patch
>
>
> Request to adjust {{JackrabbitACLImporter}} and {{JcrACLManagement}} to
> handle the policies defined by the optional authorization model provided by
> OAK-8190.
>
> I will try to provide a patch and tests.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (JCRVLT-346) IntegrationTestBase: allow for custom security setup
[
https://issues.apache.org/jira/browse/JCRVLT-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved JCRVLT-346.
---
Resolution: Fixed
Fix Version/s: 3.2.10
Committed revision 1863939.
> IntegrationTestBase: allow for custom security setup
>
>
> Key: JCRVLT-346
> URL: https://issues.apache.org/jira/browse/JCRVLT-346
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 3.2.10
>
>
> today all test extending from {{IntegrationTestBase}} have the same Oak
> security setup, which makes it impossible to write tests for a different set
> of options or for additional security modules.
> while addressing this issue, we should also replace usage of the deprecate
> {{SecurityProviderImpl}} by {{SecurityProviderBuilder}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCRVLT-328) vlt rcp fails with https PathNotFoundException
[
https://issues.apache.org/jira/browse/JCRVLT-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895143#comment-16895143
]
Konrad Windszus commented on JCRVLT-328:
I think this duplicates JCRVLT-341.
> vlt rcp fails with https PathNotFoundException
> --
>
> Key: JCRVLT-328
> URL: https://issues.apache.org/jira/browse/JCRVLT-328
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Reporter: joseph jobbings
>Priority: Major
>
> vlt rcp (vault-cli-3.2.4) - used with AEM 6.4
> Trying to vault rcp between remote and local AEM instances works over http
> but not https.
> This command (with complex password replaced with 'password') results in
> correct copying of content nodes, suggesting the specified content path
> exists :
>
> {code:java}
> vlt rcp --recursive --batchSize 50 --update --newer
> http://admin:passw...@some-host.westeurope.cloudapp.azure.com:4502/crx/-/jcr:root/content/foo/
> http://admin:admin@localhost:4502/crx/-/jcr:root/content/foo
> 01 U /content/foo
> 02 - /content/foo/jcr:content
> 03 U /content/foo/errors
> 04 - /content/foo/errors/jcr:content
> 05 U /content/foo/errors/404
> 06 - /content/foo/errors/404/jcr:content
> 07 U /content/foo/errors/500
> 08 - /content/foo/errors/500/jcr:content
> [WARN ] Error while adding node /content/foo/rep:policy (ignored):
> javax.jcr.PathNotFoundException: rep:policy
> // ...etc{code}
>
> Configuring options for the JVM to use SSL and running the following command
> - although /content/foo already exists on both source and destination - fails
> with error "[ERROR] Error while retrieving src node /content/foo:
> javax.jcr.PathNotFoundException: /content/foo"
>
> {code:java}
> export
> VLT_OPTS="-Djavax.net.ssl.trustStore=/Users/john/server-keystore.pkcs12
> -Djavax.net.ssl.trustStorePassword=changeit
> -Djavax.net.ssl.trustStoreType=pkcs12"
> vlt rcp --recursive --batchSize 50 --update --newer
> https://admin:passw...@some-host.westeurope.cloudapp.azure.com/crx/-/jcr:root/content/foo
> http://admin:admin@localhost:4502/crx/-/jcr:root/content/foo
> [ERROR] Error while retrieving src node /content/foo:
> javax.jcr.PathNotFoundException: /content/foo
> {code}
>
> -Can vlt rcp log more verbose output for inspection/ diagnosis?- Ok, bad
> question - the logging directive is clear in the documentation *--log-level
> trace* etc. But I'm still puzzled as to why the command works over http but
> not over https (SSL considered and allowed for)?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCRVLT-344: -- Component/s: vlt > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc, vlt >Reporter: angela >Assignee: angela >Priority: Major > Fix For: 3.2.10 > > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (JCRVLT-344) update version of jackrabbit and oak dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCRVLT-344. --- Resolution: Fixed Fix Version/s: 3.2.10 > update version of jackrabbit and oak dependencies > -- > > Key: JCRVLT-344 > URL: https://issues.apache.org/jira/browse/JCRVLT-344 > Project: Jackrabbit FileVault > Issue Type: Task > Components: Misc >Reporter: angela >Assignee: angela >Priority: Major > Fix For: 3.2.10 > > Attachments: JCRVLT-344.patch > > > in order to address JCRVLT-340 the version properties of jackrabbit and oak > need to be adjusted to use the most recent releases: > 2.18.2 > 1.16.0 > since there some significant moves made in the code base the following > additional changes need to follow: > * adjust dependency _oak-segment_ to _oak-segment-tar_ (the former no longer > exist) > - subsequently adjust the changed package names > (o.a.jackrabbit.oak.plugins.segment to o.a.jackrabbit.segment) > - adjust dependency _jackrabbit-api_ to use _oak-jackrabbit-api_ as > jackrabbit-api will no longer be maintained -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (JCRVLT-345) Support pluggable node/file/filter validators
[
https://issues.apache.org/jira/browse/JCRVLT-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895085#comment-16895085
]
Konrad Windszus commented on JCRVLT-345:
For me there is a fundamental difference between oakpal and the already
existing validators within f-p-m-p. The latter is a static analysis while
oakpal requires a (lightweight) repository to do an actual installation. That
obviously takes a lot more time. For me both approaches are valid, but some
validations should happen as soon/as quick as possible (in the best case even
with m2e incremental build support). I am talking only about static validations
in the context of this issue. I am thinking about leveraging JSR330 annotations
(with the built-in Sisu/Guice Container in Maven3) to allow to dynamically bind
validators.
> Support pluggable node/file/filter validators
> -
>
> Key: JCRVLT-345
> URL: https://issues.apache.org/jira/browse/JCRVLT-345
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> IMHO it would be good to support pluggable node, file and filter.xml
> validators for custom validations:
> The filevault-package-m-p should ship/ships with these ones out of the box
> # check for index definition nodes
> # check for bundles, OSGi configuration and subpackages (in the context of
> JCRVLT-249)
> # check for adherence to the FileVault DocView for .content.xml files
> # check for filter.xml coverage of all nodes/files
> The following ones are just ideas for custom validations:
> # check for usage of deprecated resource types
> # check for content classification
> (https://helpx.adobe.com/experience-manager/6-5/sites/deploying/using/sustainable-upgrades.html)
> An SPI should be defined and allow everyone to come up with validator
> extensions which are automatically executed during the {{package}} goal on
> all files/nodes being included in the package
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (JCRVLT-345) Support pluggable node/file/filter validators
[
https://issues.apache.org/jira/browse/JCRVLT-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned JCRVLT-345:
--
Assignee: Konrad Windszus
> Support pluggable node/file/filter validators
> -
>
> Key: JCRVLT-345
> URL: https://issues.apache.org/jira/browse/JCRVLT-345
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> IMHO it would be good to support pluggable node, file and filter.xml
> validators for custom validations:
> The filevault-package-m-p should ship/ships with these ones out of the box
> # check for index definition nodes
> # check for bundles, OSGi configuration and subpackages (in the context of
> JCRVLT-249)
> # check for adherence to the FileVault DocView for .content.xml files
> # check for filter.xml coverage of all nodes/files
> The following ones are just ideas for custom validations:
> # check for usage of deprecated resource types
> # check for content classification
> (https://helpx.adobe.com/experience-manager/6-5/sites/deploying/using/sustainable-upgrades.html)
> An SPI should be defined and allow everyone to come up with validator
> extensions which are automatically executed during the {{package}} goal on
> all files/nodes being included in the package
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (JCR-4449) remove jackrabbit-api and use oak-jackrabbit-api instead
[ https://issues.apache.org/jira/browse/JCR-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895065#comment-16895065 ] Julian Reschke commented on JCR-4449: - trunk: [r1863920|http://svn.apache.org/r1863920] > remove jackrabbit-api and use oak-jackrabbit-api instead > > > Key: JCR-4449 > URL: https://issues.apache.org/jira/browse/JCR-4449 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-api >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 2.20, 2.19.4 > > > The subproject "jackrabbit-api" has been moved to Oak as per OAK-8339. After > the next stable release of Oak (1.16.0), we'll > a) remove the jackrabbit-api project from Jackrabbit, and > b) reference oak-jackrabbit-api instead. > Note that this applies to trunk only; the first stable Jackrabbit release > affected will be 2.20.0 - maintenance branches will not change. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (JCR-4449) remove jackrabbit-api and use oak-jackrabbit-api instead
[ https://issues.apache.org/jira/browse/JCR-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-4449: Fix Version/s: 2.19.4 > remove jackrabbit-api and use oak-jackrabbit-api instead > > > Key: JCR-4449 > URL: https://issues.apache.org/jira/browse/JCR-4449 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-api >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 2.20, 2.19.4 > > > The subproject "jackrabbit-api" has been moved to Oak as per OAK-8339. After > the next stable release of Oak (1.16.0), we'll > a) remove the jackrabbit-api project from Jackrabbit, and > b) reference oak-jackrabbit-api instead. > Note that this applies to trunk only; the first stable Jackrabbit release > affected will be 2.20.0 - maintenance branches will not change. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (JCR-4449) remove jackrabbit-api and use oak-jackrabbit-api instead
[ https://issues.apache.org/jira/browse/JCR-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved JCR-4449. - Resolution: Fixed > remove jackrabbit-api and use oak-jackrabbit-api instead > > > Key: JCR-4449 > URL: https://issues.apache.org/jira/browse/JCR-4449 > Project: Jackrabbit Content Repository > Issue Type: Task > Components: jackrabbit-api >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 2.20 > > > The subproject "jackrabbit-api" has been moved to Oak as per OAK-8339. After > the next stable release of Oak (1.16.0), we'll > a) remove the jackrabbit-api project from Jackrabbit, and > b) reference oak-jackrabbit-api instead. > Note that this applies to trunk only; the first stable Jackrabbit release > affected will be 2.20.0 - maintenance branches will not change. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
