[jira] [Comment Edited] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784768#comment-17784768
]
Manfred Baedke edited comment on JCR-4954 at 11/10/23 10:51 AM:
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but it might also be both of us :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
was (Author: baedke):
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but I'm not sure :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
> Problem with WebDav Client and Repository Server Deployment Model
> -
>
> Key: JCR-4954
> URL: https://issues.apache.org/jira/browse/JCR-4954
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Reporter: Claus Köll
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 2.22
>
> Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt,
> JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt,
> config.xml, jcr-4954-diagnose.patch
>
>
> We have one WebApp where we have deployed the SimpleWebDavServlet
> (WebDav-WebApp). From there we connect to a other WebApp where we have
> exposed a Repository through DavEx
> (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet)
> and also the RMI-Layer by the RMI Registry (Repository-WebApp)
> Until now we connected over RMI but now we tried to switch to DavEx. The
> Problem is, that we are now unable to unlock a opened WebDav Document.
> The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the
> DavSession so a future Requests can obtain the same DavSession to perform the
> unlock.
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700
> The Reference (Locktoken) looks like
> opaquelocktoken:dccce564-412e-11e1-b
[jira] [Commented] (JCR-4954) Problem with WebDav Client and Repository Server Deployment Model
[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784768#comment-17784768
]
Manfred Baedke commented on JCR-4954:
-
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but I'm not sure :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
> Problem with WebDav Client and Repository Server Deployment Model
> -
>
> Key: JCR-4954
> URL: https://issues.apache.org/jira/browse/JCR-4954
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
>Reporter: Claus Köll
>Assignee: Manfred Baedke
>Priority: Major
> Fix For: 2.22
>
> Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt,
> JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt,
> config.xml, jcr-4954-diagnose.patch
>
>
> We have one WebApp where we have deployed the SimpleWebDavServlet
> (WebDav-WebApp). From there we connect to a other WebApp where we have
> exposed a Repository through DavEx
> (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet)
> and also the RMI-Layer by the RMI Registry (Repository-WebApp)
> Until now we connected over RMI but now we tried to switch to DavEx. The
> Problem is, that we are now unable to unlock a opened WebDav Document.
> The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the
> DavSession so a future Requests can obtain the same DavSession to perform the
> unlock.
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700
> The Reference (Locktoken) looks like
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> It will be generated by the LockTokenMapper
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53
> In the WebDav-WebApp the HeaderLockToken will be stored in this format
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4
> As you can see it will be double wrapped. That's not really a Problem because
> on unlock the WebDav-WebApp removes the prefix
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:
> Finally this locktoken will be send from the WebDav-App to the
> Repository-WebApp
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> On the Repository-WebApp the JCRWebdavServer will look for a DavSession in
> the Cache based on the lockToken
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210
> So the problem is that the DavSession whitch have created the Lock, is stored
> with a lockToken that do not match with the incoming lockToken
> Cache-Key-Token:
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> Incoming-Token:
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is
> present)
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/ja
[jira] [Commented] (JCRVLT-731) Filevault validation parent node type defaults to nt:folder, but could in reality be another node type
[ https://issues.apache.org/jira/browse/JCRVLT-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784765#comment-17784765 ] Konrad Windszus commented on JCRVLT-731: I think this idea kind of duplicates JCRVLT-619, isn't it? > Filevault validation parent node type defaults to nt:folder, but could in > reality be another node type > -- > > Key: JCRVLT-731 > URL: https://issues.apache.org/jira/browse/JCRVLT-731 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin, Packaging, validation >Affects Versions: package-maven-plugin-1.3.4, 3.7.2 >Reporter: Henry Kuijpers >Priority: Major > > When creating a filter.xml and using its nodetype-validator, a default > nodetype can be configured in case it cannot be found. The default for this > is `nt:folder`, but it's possible to provide another default nodetype. > Setting that to `sling:Folder` does not necessarily solve all problems, since > many parent nodes could actually be something else, maybe even nt:folder, > which is very restrictive. > In other words: It would be nice to be able to feed the nodetypes-validation > a set of paths with their respective jcr:primaryType, so that they can be > considered by the filevault validation. > It can be a simple maven-property, which can have key/value-pairs. > But maybe we would like to go a few steps further and create the possibility > of having those paths and types defined in an external dependency, much like > the "tccl"-statements allow to do. > Then, it would be possible to create these files per product version (i.e. > AEM service pack versions or similar). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-731) Filevault validation parent node type defaults to nt:folder, but could in reality be another node type
Henry Kuijpers created JCRVLT-731: - Summary: Filevault validation parent node type defaults to nt:folder, but could in reality be another node type Key: JCRVLT-731 URL: https://issues.apache.org/jira/browse/JCRVLT-731 Project: Jackrabbit FileVault Issue Type: Bug Components: package maven plugin, Packaging, validation Affects Versions: 3.7.2, package-maven-plugin-1.3.4 Reporter: Henry Kuijpers When creating a filter.xml and using its nodetype-validator, a default nodetype can be configured in case it cannot be found. The default for this is `nt:folder`, but it's possible to provide another default nodetype. Setting that to `sling:Folder` does not necessarily solve all problems, since many parent nodes could actually be something else, maybe even nt:folder, which is very restrictive. In other words: It would be nice to be able to feed the nodetypes-validation a set of paths with their respective jcr:primaryType, so that they can be considered by the filevault validation. It can be a simple maven-property, which can have key/value-pairs. But maybe we would like to go a few steps further and create the possibility of having those paths and types defined in an external dependency, much like the "tccl"-statements allow to do. Then, it would be possible to create these files per product version (i.e. AEM service pack versions or similar). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] OAK-10539: oak-search-elastic: migrate ingestion from Rest High Level Client to the new Java API Client [jackrabbit-oak]
fabriziofortino commented on code in PR #1193:
URL: https://github.com/apache/jackrabbit-oak/pull/1193#discussion_r1389223165
##
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticIndexWriter.java:
##
@@ -134,21 +123,24 @@ class ElasticIndexWriter implements
FulltextIndexWriter {
@Override
public void updateDocument(String path, ElasticDocument doc) throws
IOException {
-IndexRequest request = new IndexRequest(indexName)
-.id(ElasticIndexUtils.idFromPath(path))
-.source(doc.build(), XContentType.JSON);
-bulkProcessorHandler.add(request);
+bulkProcessorHandler.update(ElasticIndexUtils.idFromPath(path), doc);
}
@Override
public void deleteDocuments(String path) throws IOException {
-DeleteRequest request = new
DeleteRequest(indexName).id(ElasticIndexUtils.idFromPath(path));
-bulkProcessorHandler.add(request);
+bulkProcessorHandler.delete(ElasticIndexUtils.idFromPath(path));
}
@Override
public boolean close(long timestamp) throws IOException {
-boolean updateStatus = bulkProcessorHandler.close();
+boolean updateStatus;
+try {
+updateStatus = bulkProcessorHandler.close();
+} catch (InterruptedException e) {
+LOG.warn("Interrupted while waiting for bulk processor to close",
e);
+Thread.currentThread().interrupt(); // restore interrupt status
+return false;
Review Comment:
Right. I have moved the InterruptedException handling in the
BulkProcessorHandler so we can return the correct status.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] OAK-10539: oak-search-elastic: migrate ingestion from Rest High Level Client to the new Java API Client [jackrabbit-oak]
fabriziofortino commented on code in PR #1193:
URL: https://github.com/apache/jackrabbit-oak/pull/1193#discussion_r1389209167
##
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticDocument.java:
##
@@ -67,24 +70,40 @@ void addFulltextRelative(String path, String value) {
}
void addSuggest(String value) {
-suggest.add(value);
+suggest.add(Map.of("value", value));
Review Comment:
With the migration to the new Java Client, the document serialization has
changed completely. With RHLC we had to build the document ourselves. This was
done in the `build` method which has been removed. The new client serializes
the object using jackson. If you look at the old code
(https://github.com/apache/jackrabbit-oak/pull/1193/files#diff-9b0c34d36fa2c370c06bffcdb5bf0f9660ebe075599db13cf61ff94d4af2482bL134-L139),
the suggestions were serialized as separate objects with a single field
`value`. The final serialization has not changed then. If we would have done
that, tests around suggestions would have failed.
I have introduced constants for these hardcoded strings that are used both
in document and mapping creation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] OAK-10539: oak-search-elastic: migrate ingestion from Rest High Level Client to the new Java API Client [jackrabbit-oak]
fabriziofortino commented on code in PR #1193:
URL: https://github.com/apache/jackrabbit-oak/pull/1193#discussion_r1389181756
##
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java:
##
@@ -142,44 +134,58 @@ public static ElasticBulkProcessorHandler
getBulkProcessorHandler(@NotNull Elast
return new ElasticBulkProcessorHandler(elasticConnection, indexName,
indexDefinition, definitionBuilder, waitForESAcknowledgement);
}
-private BulkProcessor initBulkProcessor() {
-return BulkProcessor.builder(requestConsumer(),
-new OakBulkProcessorListener(), this.indexName +
"-bulk-processor")
-.setBulkActions(indexDefinition.bulkActions)
-.setConcurrentRequests(BULK_PROCESSOR_CONCURRENCY)
-.setBulkSize(new ByteSizeValue(indexDefinition.bulkSizeBytes))
-
.setFlushInterval(TimeValue.timeValueMillis(indexDefinition.bulkFlushIntervalMs))
-.setBackoffPolicy(BackoffPolicy.exponentialBackoff(
-
TimeValue.timeValueMillis(indexDefinition.bulkRetriesBackoff),
indexDefinition.bulkRetries)
-)
-.build();
+private BulkIngester initBulkIngester() {
+// BulkIngester does not support retry policies. Some retries though
are already implemented in the transport layer.
Review Comment:
Makes sense. I have removed them. I think bulk retries should be made
configurable at ElasticConnection level. This will be addressed in a separate
PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] OAK-10539: oak-search-elastic: migrate ingestion from Rest High Level Client to the new Java API Client [jackrabbit-oak]
fabriziofortino commented on code in PR #1193:
URL: https://github.com/apache/jackrabbit-oak/pull/1193#discussion_r1389160373
##
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java:
##
@@ -286,23 +280,31 @@ public void afterBulk(long executionId, BulkRequest
bulkRequest, BulkResponse bu
}
@Override
-public void afterBulk(long executionId, BulkRequest bulkRequest,
Throwable throwable) {
-LOG.error("ElasticIndex Update Bulk Failure : Bulk with id {}
threw an error", executionId, throwable);
-suppressedExceptions.add(throwable);
+public void afterBulk(long executionId, BulkRequest request,
List contexts, Throwable failure) {
Review Comment:
when the bulk processor gets closed if there are suppressed exceptions,
they are grouped in a IOException that gets thrown. We have some tests around
this (see `ElasticPropertyIndexTest#indexFailuresWithFailOnErrorOn`).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] OAK-10539: oak-search-elastic: migrate ingestion from Rest High Level Client to the new Java API Client [jackrabbit-oak]
fabriziofortino commented on code in PR #1193:
URL: https://github.com/apache/jackrabbit-oak/pull/1193#discussion_r1389132225
##
oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/index/ElasticBulkProcessorHandler.java:
##
@@ -205,39 +205,33 @@ public boolean close() throws IOException {
return updatesMap.containsValue(Boolean.TRUE);
}
-private class OakBulkProcessorListener implements BulkProcessor.Listener {
+private class OAKBulkListener implements BulkListener {
@Override
-public void beforeBulk(long executionId, BulkRequest bulkRequest) {
+public void beforeBulk(long executionId, BulkRequest request,
List contexts) {
// register new bulk party
phaser.register();
// init update status
updatesMap.put(executionId, Boolean.FALSE);
-bulkRequest.timeout(TimeValue.timeValueMinutes(2));
-
-LOG.debug("Sending bulk with id {} -> {}", executionId,
bulkRequest.getDescription());
+LOG.debug("Sending bulk with id {} -> {}", executionId, contexts);
if (LOG.isTraceEnabled()) {
-LOG.trace("Bulk Requests: \n{}", bulkRequest.requests()
+LOG.trace("Bulk Requests: \n{}", request.operations()
.stream()
-.map(DocWriteRequest::toString)
+.map(BulkOperation::toString)
.collect(Collectors.joining("\n"))
);
}
}
@Override
-public void afterBulk(long executionId, BulkRequest bulkRequest,
BulkResponse bulkResponse) {
-LOG.debug("Bulk with id {} processed with status {} in {}",
executionId, bulkResponse.status(), bulkResponse.getTook());
+public void afterBulk(long executionId, BulkRequest request,
List contexts, co.elastic.clients.elasticsearch.core.BulkResponse
response) {
Review Comment:
leftover from the migration since both clients contain a `BulkResponse`
class.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] OAK-10544: oak-jcr: remapping a namespace prefix leaves namespace resolver in broken state [jackrabbit-oak]
sonarcloud[bot] commented on PR #1199: URL: https://github.com/apache/jackrabbit-oak/pull/1199#issuecomment-1805325236 SonarCloud Quality Gate failed. [](https://sonarcloud.io/dashboard?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199) [](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=BUG) [0 Bugs](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=BUG) [](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=VULNERABILITY) [0 Vulnerabilities](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=VULNERABILITY) [](https://sonarcloud.io/project/security_hotspots?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/security_hotspots?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=SECURITY_HOTSPOT) [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=SECURITY_HOTSPOT) [](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=CODE_SMELL) [1 Code Smell](https://sonarcloud.io/project/issues?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&resolved=false&types=CODE_SMELL) [](https://sonarcloud.io/component_measures?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&metric=new_coverage&view=list) [0.0% Coverage](https://sonarcloud.io/component_measures?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&metric=new_coverage&view=list) [](https://sonarcloud.io/component_measures?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&metric=new_duplicated_lines_density&view=list) [0.0% Duplication](https://sonarcloud.io/component_measures?id=org.apache.jackrabbit%3Ajackrabbit-oak&pullRequest=1199&metric=new_duplicated_lines_density&view=list)  The version of Java (11.0.21) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17. Read more [here](https://docs.sonarcloud.io/appendices/scanner-environment/)  Catch issues before they fail your Quality Gate with our IDE extension  [SonarLint](https://www.sonarsource.com/products/sonarlint/features/connected-mode/?referrer=sonarcloud-welcome) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contac
[jira] [Created] (JCR-4990) add test for observing effect of remapping a namespace prefix to a different namespace name
Julian Reschke created JCR-4990: --- Summary: add test for observing effect of remapping a namespace prefix to a different namespace name Key: JCR-4990 URL: https://issues.apache.org/jira/browse/JCR-4990 Project: Jackrabbit Content Repository Issue Type: Test Components: test Reporter: Julian Reschke Assignee: Julian Reschke Equivalent to https://issues.apache.org/jira/browse/OAK-10545 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] OAK-10538 - Pipeline strategy: eliminate unnecessary intermediate copy of entries in transform stage [jackrabbit-oak]
fabriziofortino merged PR #1194: URL: https://github.com/apache/jackrabbit-oak/pull/1194 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
