[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781413#comment-17781413
 ] 

Julian Reschke edited comment on OAK-10523 at 10/31/23 3:04 PM:


Well, Oak doesn't throw the exception on read.

The exception happens inside jackrabbit-spi-commons' name parser, and that does 
exactly what it's documented to do (note that unless I'm missing something, Oak 
doesn't use that parser; it's only used in Jackrabbit and Filevault).

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square brackets will always fail.

What we can do is improve the diagnostics in case these brackets made it into 
an Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, 
but only a little: export using FV would work, but then you'd end up with a 
package that can not be imported. Unless we add support in FV to rename these 
nodes (similar to what - IMHO - oak-upgrade does).




was (Author: reschke):
Well, Oak doesn't throw the exception on read.

The exception happens inside jackrabbit-spi-commons' name parser, and that does 
exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square brackets will always fail.

What we can do is improve the diagnostics in case these brackets made it into 
an Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, 
but only a little: export using FV would work, but then you'd end up with a 
package that can not be imported. Unless we add support in FV to rename these 
nodes (similar to what - IMHO - oak-upgrade does).



> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781413#comment-17781413
 ] 

Julian Reschke edited comment on OAK-10523 at 10/31/23 3:02 PM:


Well, Oak doesn't throw the exception on read.

The exception happens inside jackrabbit-spi-commons' name parser, and that does 
exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square brackets will always fail.

What we can do is improve the diagnostics in case these brackets made it into 
an Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, 
but only a little: export using FV would work, but then you'd end up with a 
package that can not be imported. Unless we add support in FV to rename these 
nodes (similar to what - IMHO - oak-upgrade does).




was (Author: reschke):
Well, Oak doesn't throw the exception on read.

The exception happens inside jackrabbit-spi-commons' name parser, and that does 
exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square braces will always fail.

What we can do is improve the diagnostics in case these braces made it into an 
Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, but 
only a little: export using FV would work, but then you'd end up with a package 
that can not be imported. Unless we add support in FV to rename these nodes 
(similar to what - IMHO - oak-upgrade does).



> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781413#comment-17781413
 ] 

Julian Reschke edited comment on OAK-10523 at 10/31/23 3:01 PM:


Well, Oak doesn't throw the exception on read.

The exception happens inside jackrabbit-spi-commons' name parser, and that does 
exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square braces will always fail.

What we can do is improve the diagnostics in case these braces made it into an 
Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, but 
only a little: export using FV would work, but then you'd end up with a package 
that can not be imported. Unless we add support in FV to rename these nodes 
(similar to what - IMHO - oak-upgrade does).




was (Author: reschke):
Well, Oak doesn't throw the exception on read.

jackrabbit-spi-commons' name parser does exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square braces will always fail.

What we can do is improve the diagnostics in case these braces made it into an 
Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, but 
only a little: export using FV would work, but then you'd end up with a package 
that can not be imported. Unless we add support in FV to rename these nodes 
(similar to what - IMHO - oak-upgrade does).



> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781413#comment-17781413
 ] 

Julian Reschke edited comment on OAK-10523 at 10/31/23 3:00 PM:


Well, Oak doesn't throw the exception on read.

jackrabbit-spi-commons' name parser does exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square braces will always fail.

What we can do is improve the diagnostics in case these braces made it into an 
Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, but 
only a little: export using FV would work, but then you'd end up with a package 
that can not be imported. Unless we add support in FV to rename these nodes 
(similar to what - IMHO - oak-upgrade does).




was (Author: reschke):
Well, Oak doesn't throw the exception.

jackrabbit-spi-commons' name parser does exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square braces will always fail.

What we can do is improve the diagnostics in case these braces made it into an 
Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, but 
only a little: export using FV would work, but then you'd end up with a package 
that can not be imported. Unless we add support in FV to rename these nodes 
(similar to what - IMHO - oak-upgrade does).



> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781413#comment-17781413
 ] 

Julian Reschke commented on OAK-10523:
--

Well, Oak doesn't throw the exception.

jackrabbit-spi-commons' name parser does exactly what it's documented to do.

Maybe we need to understand first what the goal is. Unless I'm missing 
something, we aren't planning to support SNS properly in Oak. Thus, creating a 
node with a name (not JCR name) including square braces will always fail.

What we can do is improve the diagnostics in case these braces made it into an 
Oak repo (see JCRVLT-724 and JCR-4983). Fixing OAK-10523 would also help, but 
only a little: export using FV would work, but then you'd end up with a package 
that can not be imported. Unless we add support in FV to rename these nodes 
(similar to what - IMHO - oak-upgrade does).



> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Konrad Windszus (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781411#comment-17781411
 ] 

Konrad Windszus commented on OAK-10523:
---

Right, Oak is SNS read only, but the exception should be thrown while trying to 
create the SNS not when trying to read it.

> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Konrad Windszus (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781411#comment-17781411
 ] 

Konrad Windszus edited comment on OAK-10523 at 10/31/23 2:52 PM:
-

Right, Oak is SNS read only, but the exception should be thrown while trying to 
create the SNS node not when trying to read it.


was (Author: kwin):
Right, Oak is SNS read only, but the exception should be thrown while trying to 
create the SNS not when trying to read it.

> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781409#comment-17781409
 ] 

Julian Reschke commented on OAK-10523:
--

Are you referring to https://issues.apache.org/jira/browse/JCR-4917? The 
difference here was that was a change that made the parser less picky, but the 
new behavior was still within the boundaries of the JCR spec. However, "[" and 
"]" are clearly illegal in JCR names, and even if that parser would accept 
them, this wouldn't make them work in Oak.

> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Comment Edited] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Konrad Windszus (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781402#comment-17781402
 ] 

Konrad Windszus edited comment on OAK-10523 at 10/31/23 2:44 PM:
-

Instead of modifying the behaviour of Node.getName() one could also fix/relax 
the handling of APIs called on top of Node.getName(). IIUC then this was faced 
with 
[{{NameResolver.getQName(String)}}|https://jackrabbit.apache.org/api/trunk/org/apache/jackrabbit/spi/commons/conversion/NameResolver.html#getQName-java.lang.String-]
 although the javadoc currently explicitly states that it throws 
{{IllegalNameException}} when an invalid JCR name is passed.


was (Author: kwin):
Instead of modifying the behaviour of Node.getName() one could also fix/relax 
the handling of APIs called on top of Node.getName(). IIUC then this was faced 
with 
[{{NameResolver.getQName(String)}}|https://jackrabbit.apache.org/api/trunk/org/apache/jackrabbit/spi/commons/conversion/NameResolver.html#getQName-java.lang.String-]

> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OAK-10523) Basic SNS support returns invalid node names

2023-10-31 Thread Konrad Windszus (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781402#comment-17781402
 ] 

Konrad Windszus commented on OAK-10523:
---

Instead of modifying the behaviour of Node.getName() one could also fix/relax 
the handling of APIs called on top of Node.getName(). IIUC then this was faced 
with 
[{{NameResolver.getQName(String)}}|https://jackrabbit.apache.org/api/trunk/org/apache/jackrabbit/spi/commons/conversion/NameResolver.html#getQName-java.lang.String-]

> Basic SNS support returns invalid node names
> 
>
> Key: OAK-10523
> URL: https://issues.apache.org/jira/browse/OAK-10523
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Julian Reschke
>Priority: Minor
>
> When encountering names using index notation in storage, oak-jcr treats the 
> index suffix as part of the name. This causes issues with other components 
> that assume that the result of {{Node.getName()}} is indeed a valid JCR name.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OAK-10464) Use Testcontainers instead of com.arakelian:docker-junit-rule

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781383#comment-17781383
 ] 

Julian Reschke commented on OAK-10464:
--

trunk: 
[ae576b4646|https://github.com/apache/jackrabbit-oak/commit/ae576b464625c48590108eeb8df9186b713aa234]

> Use Testcontainers instead of com.arakelian:docker-junit-rule
> -
>
> Key: OAK-10464
> URL: https://issues.apache.org/jira/browse/OAK-10464
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: test
>Reporter: Miroslav Smiljanic
>Priority: Major
> Fix For: 1.60.0
>
>
> com.arakelian:docker-junit-rule embeds Spotify docker client, and that one 
> has an issue running on Apple silicon
> [https://github.com/spotify/dockerfile-maven/issues/394]
> We should switch to Testcontainers.
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.56.0/oak-blob-cloud-azure/src/test/java/org/apache/jackrabbit/oak/blob/cloud/azure/blobstorage/AzuriteDockerRule.java]
>  
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.56.0/oak-store-document/src/test/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDockerRule.java]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (OAK-10464) Use Testcontainers instead of com.arakelian:docker-junit-rule

2023-10-31 Thread Julian Reschke (Jira)


[ 
https://issues.apache.org/jira/browse/OAK-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781380#comment-17781380
 ] 

Julian Reschke commented on OAK-10464:
--

Thanks, [~t-rana]!

> Use Testcontainers instead of com.arakelian:docker-junit-rule
> -
>
> Key: OAK-10464
> URL: https://issues.apache.org/jira/browse/OAK-10464
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: test
>Reporter: Miroslav Smiljanic
>Priority: Major
> Fix For: 1.60.0
>
>
> com.arakelian:docker-junit-rule embeds Spotify docker client, and that one 
> has an issue running on Apple silicon
> [https://github.com/spotify/dockerfile-maven/issues/394]
> We should switch to Testcontainers.
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.56.0/oak-blob-cloud-azure/src/test/java/org/apache/jackrabbit/oak/blob/cloud/azure/blobstorage/AzuriteDockerRule.java]
>  
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.56.0/oak-store-document/src/test/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDockerRule.java]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (OAK-10464) Use Testcontainers instead of com.arakelian:docker-junit-rule

2023-10-31 Thread Julian Reschke (Jira)


 [ 
https://issues.apache.org/jira/browse/OAK-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Reschke resolved OAK-10464.
--
Fix Version/s: 1.60.0
   Resolution: Fixed

> Use Testcontainers instead of com.arakelian:docker-junit-rule
> -
>
> Key: OAK-10464
> URL: https://issues.apache.org/jira/browse/OAK-10464
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: test
>Reporter: Miroslav Smiljanic
>Priority: Major
> Fix For: 1.60.0
>
>
> com.arakelian:docker-junit-rule embeds Spotify docker client, and that one 
> has an issue running on Apple silicon
> [https://github.com/spotify/dockerfile-maven/issues/394]
> We should switch to Testcontainers.
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.56.0/oak-blob-cloud-azure/src/test/java/org/apache/jackrabbit/oak/blob/cloud/azure/blobstorage/AzuriteDockerRule.java]
>  
> [https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.56.0/oak-store-document/src/test/java/org/apache/jackrabbit/oak/plugins/document/mongo/MongoDockerRule.java]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (OAK-10525) DefaultSyncContext.createValues : return value should be annotated with @NotNull

2023-10-31 Thread Angela Schreiber (Jira)
Angela Schreiber created OAK-10525:
--

 Summary: DefaultSyncContext.createValues : return value should be 
annotated with @NotNull
 Key: OAK-10525
 URL: https://issues.apache.org/jira/browse/OAK-10525
 Project: Jackrabbit Oak
  Issue Type: Bug
  Components: auth-external
Reporter: Angela Schreiber


the return value of {{DefaultSyncContext.createValues}} is currently annotated 
with {{@Nullable}} but neither the returned array nor it's values are ever null 
and thus annotation {{@NotNull}} would be more appropriate IMO.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)