[jira] [Resolved] (DIRSERVER-2401) Handle leak
[ https://issues.apache.org/jira/browse/DIRSERVER-2401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny resolved DIRSERVER-2401. -- Resolution: Invalid This is a shutdown handler: it's set up once, and released when the server is shut down, which happens only once. > Handle leak > --- > > Key: DIRSERVER-2401 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2401 > Project: Directory ApacheDS > Issue Type: Bug >Reporter: Artemii Voronin >Priority: Major > > The handle _socket_ is created by calling function in line №254 and lost > after the function is executed. > [Link|https://github.com/apache/directory-server/blob/c347daec5cc1b14d98de01395c8be892b3db0c04/service/src/main/java/org/apache/directory/server/UberjarMain.java#L236] > to this function. I consider it could be a handle leak. > > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author A. Voronin (a.voro...@fobos-nt.ru). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2400) Comparison of String objects
[ https://issues.apache.org/jira/browse/DIRSERVER-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852325#comment-17852325 ] Emmanuel Lécharny commented on DIRSERVER-2400: -- This is something that remained from a time we were using long instead of String for LDAP entry IDs. I suspect we may have a few more of those guys in the code base. Thanks for the report! > Comparison of String objects > > > Key: DIRSERVER-2400 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2400 > Project: Directory ApacheDS > Issue Type: Bug >Reporter: Artemii Voronin >Priority: Major > Fix For: 2.0.0.AM28 > > > Comparison of String objects using == or != in function > *computeSubLevelScope* in line №509. > [Link|https://github.com/apache/directory-server/blob/c347daec5cc1b14d98de01395c8be892b3db0c04/xdbm-partition/src/main/java/org/apache/directory/server/xdbm/search/impl/CursorBuilder.java#L503] > to this function. I consider it necessary to clarify with the developers if > they expect a comparison of string literals or pointers. > > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author A. Voronin (a.voro...@fobos-nt.ru). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-2400) Comparison of String objects
[ https://issues.apache.org/jira/browse/DIRSERVER-2400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny resolved DIRSERVER-2400. -- Fix Version/s: 2.0.0.AM28 Resolution: Fixed Fixed in Master. > Comparison of String objects > > > Key: DIRSERVER-2400 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2400 > Project: Directory ApacheDS > Issue Type: Bug >Reporter: Artemii Voronin >Priority: Major > Fix For: 2.0.0.AM28 > > > Comparison of String objects using == or != in function > *computeSubLevelScope* in line №509. > [Link|https://github.com/apache/directory-server/blob/c347daec5cc1b14d98de01395c8be892b3db0c04/xdbm-partition/src/main/java/org/apache/directory/server/xdbm/search/impl/CursorBuilder.java#L503] > to this function. I consider it necessary to clarify with the developers if > they expect a comparison of string literals or pointers. > > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author A. Voronin (a.voro...@fobos-nt.ru). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2401) Handle leak
Artemii created DIRSERVER-2401: -- Summary: Handle leak Key: DIRSERVER-2401 URL: https://issues.apache.org/jira/browse/DIRSERVER-2401 Project: Directory ApacheDS Issue Type: Bug Reporter: Artemii The handle _socket_ is created by calling function in line №254 and lost after the function is executed. [Link|https://github.com/apache/directory-server/blob/c347daec5cc1b14d98de01395c8be892b3db0c04/service/src/main/java/org/apache/directory/server/UberjarMain.java#L236] to this function. I consider it could be a handle leak. Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. Author A. Voronin (a.voro...@fobos-nt.ru). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2400) Comparison of String objects
Artemii created DIRSERVER-2400: -- Summary: Comparison of String objects Key: DIRSERVER-2400 URL: https://issues.apache.org/jira/browse/DIRSERVER-2400 Project: Directory ApacheDS Issue Type: Bug Reporter: Artemii Comparison of String objects using == or != in function *computeSubLevelScope* in line №509. [Link|https://github.com/apache/directory-server/blob/c347daec5cc1b14d98de01395c8be892b3db0c04/xdbm-partition/src/main/java/org/apache/directory/server/xdbm/search/impl/CursorBuilder.java#L503] to this function. I consider it necessary to clarify with the developers if they expect a comparison of string literals or pointers. Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. Author A. Voronin (a.voro...@fobos-nt.ru). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-403) OutOfMemory error in Asn1Decoder for LDAP messages
[
https://issues.apache.org/jira/browse/DIRAPI-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRAPI-403.
--
Fix Version/s: 2.1.7
Resolution: Fixed
Fixed
> OutOfMemory error in Asn1Decoder for LDAP messages
> --
>
> Key: DIRAPI-403
> URL: https://issues.apache.org/jira/browse/DIRAPI-403
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Fix For: 2.1.7
>
> Attachments: OutOfMemoryReproducer.java
>
>
> Hi, we have found Out Of Memory error while fuzzing Asn1Decoder for LDAP
> messages.
> Steps to reproduce:
> 1. Download Apache Directory LDAP API v2.1.6:
> {code:java}
> wget wget
> https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz
> tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz{code}
> 2. Compile the project (we used jdk-11 and mvn-3.9.6):
> {code:java}
> cd directory-ldap-api-2.1.6
> mvn clean package{code}
> 3. Get the reproducer:
> {code:java}
> mkdir fuzz && cd fuzz
> mv /OutOfMemoryReproducer.java .{code}
> 4. Compile the reproducer
> {code:java}
> javac -cp
> ../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/
> ./OutOfMemoryReproducer.java{code}
> 5. Reproduce the error:
> {code:java}
> java -Xmx2000m -cp
> .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/:../util/target/classes/:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/mina-core-2.2.3.jar
> OutOfMemoryReproducer{code}
> We think that 2000 MB is a reasonable limit and the program should not take
> more.
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-403) OutOfMemory error in Asn1Decoder for LDAP messages
[
https://issues.apache.org/jira/browse/DIRAPI-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851487#comment-17851487
]
Emmanuel Lécharny commented on DIRAPI-403:
--
The maxPDUsize parameter was not used to check if the value size is to be
greater that the configured value, leading ot huge byte[] to be allocated.
The fix now checks this limit and throw an exception if exceeded.
A test was added with a maxPDUSize set to 1024 bytes.
> OutOfMemory error in Asn1Decoder for LDAP messages
> --
>
> Key: DIRAPI-403
> URL: https://issues.apache.org/jira/browse/DIRAPI-403
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Attachments: OutOfMemoryReproducer.java
>
>
> Hi, we have found Out Of Memory error while fuzzing Asn1Decoder for LDAP
> messages.
> Steps to reproduce:
> 1. Download Apache Directory LDAP API v2.1.6:
> {code:java}
> wget wget
> https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz
> tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz{code}
> 2. Compile the project (we used jdk-11 and mvn-3.9.6):
> {code:java}
> cd directory-ldap-api-2.1.6
> mvn clean package{code}
> 3. Get the reproducer:
> {code:java}
> mkdir fuzz && cd fuzz
> mv /OutOfMemoryReproducer.java .{code}
> 4. Compile the reproducer
> {code:java}
> javac -cp
> ../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/
> ./OutOfMemoryReproducer.java{code}
> 5. Reproduce the error:
> {code:java}
> java -Xmx2000m -cp
> .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/:../util/target/classes/:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/mina-core-2.2.3.jar
> OutOfMemoryReproducer{code}
> We think that 2000 MB is a reasonable limit and the program should not take
> more.
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-403) OutOfMemory error in Asn1Decoder for LDAP messages
Andrey Slepykh created DIRAPI-403:
-
Summary: OutOfMemory error in Asn1Decoder for LDAP messages
Key: DIRAPI-403
URL: https://issues.apache.org/jira/browse/DIRAPI-403
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.1.6
Reporter: Andrey Slepykh
Attachments: OutOfMemoryReproducer.java
Hi, we have found Out Of Memory error while fuzzing Asn1Decoder for LDAP
messages.
Steps to reproduce:
1. Download Apache Directory LDAP API v2.1.6:
{code:java}
wget wget
https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz
tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz{code}
2. Compile the project (we used jdk-11 and mvn-3.9.6):
{code:java}
cd directory-ldap-api-2.1.6
mvn clean package{code}
3. Get the reproducer:
{code:java}
mkdir fuzz && cd fuzz
mv /OutOfMemoryReproducer.java .{code}
4. Compile the reproducer
{code:java}
javac -cp
../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/
./OutOfMemoryReproducer.java{code}
5. Reproduce the error:
{code:java}
java -Xmx2000m -cp
.:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/:../util/target/classes/:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/mina-core-2.2.3.jar
OutOfMemoryReproducer{code}
We think that 2000 MB is a reasonable limit and the program should not take
more.
Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-402) unhandled exception (ArrayIndexOutOfBoundsException) in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRAPI-402.
--
Resolution: Fixed
Patch pushed.
> unhandled exception (ArrayIndexOutOfBoundsException) in LDAP URL parser
> ---
>
> Key: DIRAPI-402
> URL: https://issues.apache.org/jira/browse/DIRAPI-402
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Fix For: 2.1.7
>
> Attachments: ReproducerIndexOutOfRange.java
>
>
> Hi, we have found another unhandled exception
> (ArrayIndexOutOfBoundsException) in LDAP URL parser version 2.1.6.
> Steps to reproduce:
> 1. Download Apache Directory LDAP API v2.1.6:
> {code:java}
> wget wget
> https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz
> tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz{code}
> 2. Compile the project (we used jdk-11 and mvn-3.9.6):
> {code:java}
> cd directory-ldap-api-2.1.6
> mvn clean package{code}
> 3. Get the reproducer:
> {code:java}
> mkdir fuzz && cd fuzz
> mv /ReproducerIndexOutOfRange.java .{code}
> 4. Compile the reproducer
> {code:java}
> javac -cp ../ldap/model/target/classes/ ./ReproducerIndexOutOfRange.java{code}
> 5. Reproduce the exception:
> {code:java}
> java -cp
> ../ldap/model/target/classes/:../../jazzer/jazzer_standalone.jar:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/org.apache.servicemix.bundles.antlr-2.7.7_5.jar
> ReproducerIndexOutOfRange{code}
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-402) unhandled exception (ArrayIndexOutOfBoundsException) in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850043#comment-17850043
]
Emmanuel Lécharny commented on DIRAPI-402:
--
Yes, another missing boundary check before parsing the optional host :/
Fixing it right away.
> unhandled exception (ArrayIndexOutOfBoundsException) in LDAP URL parser
> ---
>
> Key: DIRAPI-402
> URL: https://issues.apache.org/jira/browse/DIRAPI-402
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Attachments: ReproducerIndexOutOfRange.java
>
>
> Hi, we have found another unhandled exception
> (ArrayIndexOutOfBoundsException) in LDAP URL parser version 2.1.6.
> Steps to reproduce:
> 1. Download Apache Directory LDAP API v2.1.6:
> {code:java}
> wget wget
> https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz
> tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz{code}
> 2. Compile the project (we used jdk-11 and mvn-3.9.6):
> {code:java}
> cd directory-ldap-api-2.1.6
> mvn clean package{code}
> 3. Get the reproducer:
> {code:java}
> mkdir fuzz && cd fuzz
> mv /ReproducerIndexOutOfRange.java .{code}
> 4. Compile the reproducer
> {code:java}
> javac -cp ../ldap/model/target/classes/ ./ReproducerIndexOutOfRange.java{code}
> 5. Reproduce the exception:
> {code:java}
> java -cp
> ../ldap/model/target/classes/:../../jazzer/jazzer_standalone.jar:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/org.apache.servicemix.bundles.antlr-2.7.7_5.jar
> ReproducerIndexOutOfRange{code}
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRAPI-402) unhandled exception (ArrayIndexOutOfBoundsException) in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny updated DIRAPI-402:
-
Fix Version/s: 2.1.7
> unhandled exception (ArrayIndexOutOfBoundsException) in LDAP URL parser
> ---
>
> Key: DIRAPI-402
> URL: https://issues.apache.org/jira/browse/DIRAPI-402
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Fix For: 2.1.7
>
> Attachments: ReproducerIndexOutOfRange.java
>
>
> Hi, we have found another unhandled exception
> (ArrayIndexOutOfBoundsException) in LDAP URL parser version 2.1.6.
> Steps to reproduce:
> 1. Download Apache Directory LDAP API v2.1.6:
> {code:java}
> wget wget
> https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz
> tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz{code}
> 2. Compile the project (we used jdk-11 and mvn-3.9.6):
> {code:java}
> cd directory-ldap-api-2.1.6
> mvn clean package{code}
> 3. Get the reproducer:
> {code:java}
> mkdir fuzz && cd fuzz
> mv /ReproducerIndexOutOfRange.java .{code}
> 4. Compile the reproducer
> {code:java}
> javac -cp ../ldap/model/target/classes/ ./ReproducerIndexOutOfRange.java{code}
> 5. Reproduce the exception:
> {code:java}
> java -cp
> ../ldap/model/target/classes/:../../jazzer/jazzer_standalone.jar:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/org.apache.servicemix.bundles.antlr-2.7.7_5.jar
> ReproducerIndexOutOfRange{code}
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-402) unhandled exception (ArrayIndexOutOfBoundsException) in LDAP URL parser
Andrey Slepykh created DIRAPI-402:
-
Summary: unhandled exception (ArrayIndexOutOfBoundsException) in
LDAP URL parser
Key: DIRAPI-402
URL: https://issues.apache.org/jira/browse/DIRAPI-402
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.1.6
Reporter: Andrey Slepykh
Attachments: ReproducerIndexOutOfRange.java
Hi, we have found another unhandled exception (ArrayIndexOutOfBoundsException)
in LDAP URL parser version 2.1.6.
Steps to reproduce:
1. Download Apache Directory LDAP API v2.1.6:
{code:java}
wget wget
https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz
tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz{code}
2. Compile the project (we used jdk-11 and mvn-3.9.6):
{code:java}
cd directory-ldap-api-2.1.6
mvn clean package{code}
3. Get the reproducer:
{code:java}
mkdir fuzz && cd fuzz
mv /ReproducerIndexOutOfRange.java .{code}
4. Compile the reproducer
{code:java}
javac -cp ../ldap/model/target/classes/ ./ReproducerIndexOutOfRange.java{code}
5. Reproduce the exception:
{code:java}
java -cp
../ldap/model/target/classes/:../../jazzer/jazzer_standalone.jar:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/org.apache.servicemix.bundles.antlr-2.7.7_5.jar
ReproducerIndexOutOfRange{code}
Found by Linux Verification Center (portal.linuxtesting.ru) with jazzer.
Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-400) Hang in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRAPI-400.
--
Fix Version/s: 2.1.7
Resolution: Fixed
Fixed and test added.
Thanks for the report!
> Hang in LDAP URL parser
> ---
>
> Key: DIRAPI-400
> URL: https://issues.apache.org/jira/browse/DIRAPI-400
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Fix For: 2.1.7
>
> Attachments: Reproducer.java
>
>
> Hello, we have found a problem in LDAP URL parser in version 2.1.6 while
> fuzzing. The problem is that LDAP parser can not properly handle specially
> crafted inputs and just hangs.
> {{Steps to reproduce:}}
> ~1. Download Apache Directory LDAP API v2.1.6:~
> ^wget wget
> [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz]^
> ^tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz^
> {{2. Compile the project (we used jdk-11 and mvn-3.9.6):}}
> {{^cd directory-ldap-api-2.1.6^}}
> {{^mvn clean package^}}
> {{3. Get the reproducer:}}
> {{^mkdir fuzz && cd fuzz^}}
> {{^mv /Reproducer.java .^}}
> {{4. Compile the reproducer:}}
> {{^javac -cp ../ldap/model/target/classes/ ./Reproducer.java^}}
> {{5. Reproduce the hang:}}
> {{^java -cp
> ../ldap/model/target/classes/:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.26.jar:../i18n/target/classes/
> Reproducer^}}
> We decided to fuzz this function, because it is used in Apache Directory
> Server
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-400) Hang in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849937#comment-17849937
]
Emmanuel Lécharny commented on DIRAPI-400:
--
Ok, got an infinite loop because a boundary check is missing in many parts of
the code...
Just added them, running the tests.
Good catch!
> Hang in LDAP URL parser
> ---
>
> Key: DIRAPI-400
> URL: https://issues.apache.org/jira/browse/DIRAPI-400
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Attachments: Reproducer.java
>
>
> Hello, we have found a problem in LDAP URL parser in version 2.1.6 while
> fuzzing. The problem is that LDAP parser can not properly handle specially
> crafted inputs and just hangs.
> {{Steps to reproduce:}}
> ~1. Download Apache Directory LDAP API v2.1.6:~
> ^wget wget
> [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz]^
> ^tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz^
> {{2. Compile the project (we used jdk-11 and mvn-3.9.6):}}
> {{^cd directory-ldap-api-2.1.6^}}
> {{^mvn clean package^}}
> {{3. Get the reproducer:}}
> {{^mkdir fuzz && cd fuzz^}}
> {{^mv /Reproducer.java .^}}
> {{4. Compile the reproducer:}}
> {{^javac -cp ../ldap/model/target/classes/ ./Reproducer.java^}}
> {{5. Reproduce the hang:}}
> {{^java -cp
> ../ldap/model/target/classes/:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.26.jar:../i18n/target/classes/
> Reproducer^}}
> We decided to fuzz this function, because it is used in Apache Directory
> Server
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-400) Hang in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849934#comment-17849934
]
Andrey Slepykh commented on DIRAPI-400:
---
My bad
I accidentally sent you a normal version of the testcase. Please replace input
string in Reproducer.java with this: "ldap://[1:2:ldap:///o; and try again.
That should result in a hang.
> Hang in LDAP URL parser
> ---
>
> Key: DIRAPI-400
> URL: https://issues.apache.org/jira/browse/DIRAPI-400
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Attachments: Reproducer.java
>
>
> Hello, we have found a problem in LDAP URL parser in version 2.1.6 while
> fuzzing. The problem is that LDAP parser can not properly handle specially
> crafted inputs and just hangs.
> {{Steps to reproduce:}}
> ~1. Download Apache Directory LDAP API v2.1.6:~
> ^wget wget
> [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz]^
> ^tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz^
> {{2. Compile the project (we used jdk-11 and mvn-3.9.6):}}
> {{^cd directory-ldap-api-2.1.6^}}
> {{^mvn clean package^}}
> {{3. Get the reproducer:}}
> {{^mkdir fuzz && cd fuzz^}}
> {{^mv /Reproducer.java .^}}
> {{4. Compile the reproducer:}}
> {{^javac -cp ../ldap/model/target/classes/ ./Reproducer.java^}}
> {{5. Reproduce the hang:}}
> {{^java -cp
> ../ldap/model/target/classes/:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.26.jar:../i18n/target/classes/
> Reproducer^}}
> We decided to fuzz this function, because it is used in Apache Directory
> Server
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-401) Unhandled Exception (NegativeArraySizeException) in Asn1Decoder
[ https://issues.apache.org/jira/browse/DIRAPI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny resolved DIRAPI-401. -- Fix Version/s: 2.1.7 Resolution: Fixed Just pushed the fix, with the associated test. > Unhandled Exception (NegativeArraySizeException) in Asn1Decoder > --- > > Key: DIRAPI-401 > URL: https://issues.apache.org/jira/browse/DIRAPI-401 > Project: Directory Client API > Issue Type: Bug >Affects Versions: 2.1.6 >Reporter: Andrey Slepykh >Priority: Major > Fix For: 2.1.7 > > Attachments: NegativeSizeReproducer.java > > > Hello, we think we have found a problem in Asn1Decoder implementation for > LDAP messages while fuzzing in version 2.1.6. This problem is unhandled > exception (NegativeArraySizeException). > Steps to reproduce: > 1. Download Apache Directory LDAP API v2.1.6: > ``` > wget wget > [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz] > tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz > ``` > 2. Compile the project (we used jdk-11 and mvn-3.9.6): > ``` > cd directory-ldap-api-2.1.6 > mvn clean package > ``` > 3. Get the reproducer: > ``` > mkdir fuzz && cd fuzz > mv /NegativeSizeReproducer.java . > ``` > 4. Compile the reproducer > ``` > javac -cp > .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/ > ./NegativeSizeReproducer.java > ``` > 5. Reproduce the exception: > ``` > java -cp > .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/:../util/target/classes/:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/mina-core-2.2.3.jar > NegativeSizeReproducer > ``` > Found by Linux Verification Center (portal.linuxtesting.ru) with jazzer. > Author L.Reviakin (l.revia...@fobos-nt.ru) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-401) Unhandled Exception (NegativeArraySizeException) in Asn1Decoder
[ https://issues.apache.org/jira/browse/DIRAPI-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849833#comment-17849833 ] Emmanuel Lécharny commented on DIRAPI-401: -- I confirm the current code is not checking for negative values... A fix is being brewed. Thanks! > Unhandled Exception (NegativeArraySizeException) in Asn1Decoder > --- > > Key: DIRAPI-401 > URL: https://issues.apache.org/jira/browse/DIRAPI-401 > Project: Directory Client API > Issue Type: Bug >Affects Versions: 2.1.6 >Reporter: Andrey Slepykh >Priority: Major > Attachments: NegativeSizeReproducer.java > > > Hello, we think we have found a problem in Asn1Decoder implementation for > LDAP messages while fuzzing in version 2.1.6. This problem is unhandled > exception (NegativeArraySizeException). > Steps to reproduce: > 1. Download Apache Directory LDAP API v2.1.6: > ``` > wget wget > [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz] > tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz > ``` > 2. Compile the project (we used jdk-11 and mvn-3.9.6): > ``` > cd directory-ldap-api-2.1.6 > mvn clean package > ``` > 3. Get the reproducer: > ``` > mkdir fuzz && cd fuzz > mv /NegativeSizeReproducer.java . > ``` > 4. Compile the reproducer > ``` > javac -cp > .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/ > ./NegativeSizeReproducer.java > ``` > 5. Reproduce the exception: > ``` > java -cp > .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/:../util/target/classes/:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/mina-core-2.2.3.jar > NegativeSizeReproducer > ``` > Found by Linux Verification Center (portal.linuxtesting.ru) with jazzer. > Author L.Reviakin (l.revia...@fobos-nt.ru) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRAPI-400) Hang in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849829#comment-17849829
]
Emmanuel Lécharny edited comment on DIRAPI-400 at 5/27/24 8:53 PM:
---
The LDAP URl you use is perfectly valid, why would you expect it to throw a
{{LdapURLEncodingException}}?
RFC 4516 grammar for LDAP URL is pretty clear:
{code:java}
ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
[SLASH dn [QUESTION [attributes]
[QUESTION [scope] [QUESTION [filter]
[QUESTION extensions]
; and are defined
; in Sections 3.2.2 and 3.2.3
; of [RFC3986].
; is from Section 3 of
; [RFC4515], subject to the
; provisions of the
; "Percent-Encoding" section
; below.
scheme = "ldap"
{code}
Everything after {{ldap://}} and the (optionnal) host - {{lenix}} in your case
- is also optional.
was (Author: elecharny):
The LDAP URl you use is perfectly valid, why would you expect it to throw a
{{LdapURLEncodingException}}?
> Hang in LDAP URL parser
> ---
>
> Key: DIRAPI-400
> URL: https://issues.apache.org/jira/browse/DIRAPI-400
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Attachments: Reproducer.java
>
>
> Hello, we have found a problem in LDAP URL parser in version 2.1.6 while
> fuzzing. The problem is that LDAP parser can not properly handle specially
> crafted inputs and just hangs.
> {{Steps to reproduce:}}
> ~1. Download Apache Directory LDAP API v2.1.6:~
> ^wget wget
> [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz]^
> ^tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz^
> {{2. Compile the project (we used jdk-11 and mvn-3.9.6):}}
> {{^cd directory-ldap-api-2.1.6^}}
> {{^mvn clean package^}}
> {{3. Get the reproducer:}}
> {{^mkdir fuzz && cd fuzz^}}
> {{^mv /Reproducer.java .^}}
> {{4. Compile the reproducer:}}
> {{^javac -cp ../ldap/model/target/classes/ ./Reproducer.java^}}
> {{5. Reproduce the hang:}}
> {{^java -cp
> ../ldap/model/target/classes/:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.26.jar:../i18n/target/classes/
> Reproducer^}}
> We decided to fuzz this function, because it is used in Apache Directory
> Server
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRAPI-400) Hang in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849829#comment-17849829
]
Emmanuel Lécharny edited comment on DIRAPI-400 at 5/27/24 8:51 PM:
---
The LDAP URl you use is perfectly valid, why would you expect it to throw a
{{LdapURLEncodingException}}?
was (Author: elecharny):
The LDAP URUl you use is perfectly valid, why would you expect it to throw a
{{LdapURLEncodingException}}?
> Hang in LDAP URL parser
> ---
>
> Key: DIRAPI-400
> URL: https://issues.apache.org/jira/browse/DIRAPI-400
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Attachments: Reproducer.java
>
>
> Hello, we have found a problem in LDAP URL parser in version 2.1.6 while
> fuzzing. The problem is that LDAP parser can not properly handle specially
> crafted inputs and just hangs.
> {{Steps to reproduce:}}
> ~1. Download Apache Directory LDAP API v2.1.6:~
> ^wget wget
> [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz]^
> ^tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz^
> {{2. Compile the project (we used jdk-11 and mvn-3.9.6):}}
> {{^cd directory-ldap-api-2.1.6^}}
> {{^mvn clean package^}}
> {{3. Get the reproducer:}}
> {{^mkdir fuzz && cd fuzz^}}
> {{^mv /Reproducer.java .^}}
> {{4. Compile the reproducer:}}
> {{^javac -cp ../ldap/model/target/classes/ ./Reproducer.java^}}
> {{5. Reproduce the hang:}}
> {{^java -cp
> ../ldap/model/target/classes/:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.26.jar:../i18n/target/classes/
> Reproducer^}}
> We decided to fuzz this function, because it is used in Apache Directory
> Server
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-400) Hang in LDAP URL parser
[
https://issues.apache.org/jira/browse/DIRAPI-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849829#comment-17849829
]
Emmanuel Lécharny commented on DIRAPI-400:
--
The LDAP URUl you use is perfectly valid, why would you expect it to throw a
{{LdapURLEncodingException}}?
> Hang in LDAP URL parser
> ---
>
> Key: DIRAPI-400
> URL: https://issues.apache.org/jira/browse/DIRAPI-400
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Andrey Slepykh
>Priority: Major
> Attachments: Reproducer.java
>
>
> Hello, we have found a problem in LDAP URL parser in version 2.1.6 while
> fuzzing. The problem is that LDAP parser can not properly handle specially
> crafted inputs and just hangs.
> {{Steps to reproduce:}}
> ~1. Download Apache Directory LDAP API v2.1.6:~
> ^wget wget
> [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz]^
> ^tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz^
> {{2. Compile the project (we used jdk-11 and mvn-3.9.6):}}
> {{^cd directory-ldap-api-2.1.6^}}
> {{^mvn clean package^}}
> {{3. Get the reproducer:}}
> {{^mkdir fuzz && cd fuzz^}}
> {{^mv /Reproducer.java .^}}
> {{4. Compile the reproducer:}}
> {{^javac -cp ../ldap/model/target/classes/ ./Reproducer.java^}}
> {{5. Reproduce the hang:}}
> {{^java -cp
> ../ldap/model/target/classes/:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.26.jar:../i18n/target/classes/
> Reproducer^}}
> We decided to fuzz this function, because it is used in Apache Directory
> Server
> Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
> Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-401) Unhandled Exception (NegativeArraySizeException) in Asn1Decoder
Andrey Slepykh created DIRAPI-401: - Summary: Unhandled Exception (NegativeArraySizeException) in Asn1Decoder Key: DIRAPI-401 URL: https://issues.apache.org/jira/browse/DIRAPI-401 Project: Directory Client API Issue Type: Bug Affects Versions: 2.1.6 Reporter: Andrey Slepykh Attachments: NegativeSizeReproducer.java Hello, we think we have found a problem in Asn1Decoder implementation for LDAP messages while fuzzing in version 2.1.6. This problem is unhandled exception (NegativeArraySizeException). Steps to reproduce: 1. Download Apache Directory LDAP API v2.1.6: ``` wget wget [https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz] tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz ``` 2. Compile the project (we used jdk-11 and mvn-3.9.6): ``` cd directory-ldap-api-2.1.6 mvn clean package ``` 3. Get the reproducer: ``` mkdir fuzz && cd fuzz mv /NegativeSizeReproducer.java . ``` 4. Compile the reproducer ``` javac -cp .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/ ./NegativeSizeReproducer.java ``` 5. Reproduce the exception: ``` java -cp .:../asn1/ber/target/classes/:../asn1/api/target/classes/:../ldap/codec/core/target/classes/:../ldap/model/target/classes/:../ldap/codec/core/target/classes/:../util/target/classes/:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.36.jar:../i18n/target/classes/:../integ-osgi/target/dependency/mina-core-2.2.3.jar NegativeSizeReproducer ``` Found by Linux Verification Center (portal.linuxtesting.ru) with jazzer. Author L.Reviakin (l.revia...@fobos-nt.ru) -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-400) Hang in LDAP URL parser
Andrey Slepykh created DIRAPI-400:
-
Summary: Hang in LDAP URL parser
Key: DIRAPI-400
URL: https://issues.apache.org/jira/browse/DIRAPI-400
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.1.6
Reporter: Andrey Slepykh
Attachments: Reproducer.java
Hello, we have found a problem in LDAP URL parser in version 2.1.6 while
fuzzing. The problem is that LDAP parser can not properly handle specially
crafted inputs and just hangs.
{{Steps to reproduce:}}
~1. Download Apache Directory LDAP API v2.1.6:~
^wget wget
[https://github.com/apache/directory-ldap-api/archive/refs/tags/2.1.6.tar.gz]^
^tar xf 2.1.6.tar.gz && rm 2.1.6.tar.gz^
{{2. Compile the project (we used jdk-11 and mvn-3.9.6):}}
{{^cd directory-ldap-api-2.1.6^}}
{{^mvn clean package^}}
{{3. Get the reproducer:}}
{{^mkdir fuzz && cd fuzz^}}
{{^mv /Reproducer.java .^}}
{{4. Compile the reproducer:}}
{{^javac -cp ../ldap/model/target/classes/ ./Reproducer.java^}}
{{5. Reproduce the hang:}}
{{^java -cp
../ldap/model/target/classes/:.:../util/target/classes/:../integ-osgi/target/dependency/slf4j-api-1.7.26.jar:../i18n/target/classes/
Reproducer^}}
We decided to fuzz this function, because it is used in Apache Directory Server
Found by Linux Verification Center (portal.linuxtesting.ru) with Jazzer.
Author L.Reviakin (l.revia...@fobos-nt.ru)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2390) Index 0 out of bounds for length 0
[ https://issues.apache.org/jira/browse/DIRSERVER-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848756#comment-17848756 ] Emmanuel Lécharny commented on DIRSERVER-2390: -- There is no M28 yet. the only way to get it to work is to use M26. > Index 0 out of bounds for length 0 > -- > > Key: DIRSERVER-2390 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2390 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0.AM27 >Reporter: Jürgen Weber >Priority: Major > > On opening a connection from Directory Studio there is a error message > An error has occurred. See error log for more details. > Index 0 out of bounds for length 0 > eclipse.buildId=unknown > java.version=11.0.21 > java.vendor=Eclipse Adoptium > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_DE > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm > org.eclipse.ui.workbench > Error > Wed Jan 31 11:24:49 CET 2024 > Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". > java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 > at > org.apache.directory.studio.apacheds.configuration.editor.OverviewPage.refreshUI(OverviewPage.java:713) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.pageChanged(ServerConfigurationEditor.java:124) > at > org.eclipse.ui.part.MultiPageEditorPart$5.run(MultiPageEditorPart.java:1231) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) > at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) > at > org.eclipse.ui.part.MultiPageEditorPart.firePageChanged(MultiPageEditorPart.java:1228) > at > org.eclipse.ui.part.MultiPageEditorPart.pageChange(MultiPageEditorPart.java:834) > at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor.java:501) > at > org.eclipse.ui.part.MultiPageEditorPart.setActivePage(MultiPageEditorPart.java:1032) > at > org.eclipse.ui.forms.editor.FormEditor.setActivePage(FormEditor.java:612) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.hideLoadingPageAndDisplayConfigPages(ServerConfigurationEditor.java:421) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.configurationLoaded(ServerConfigurationEditor.java:370) > at > org.apache.directory.studio.apacheds.configuration.jobs.LoadConfigurationRunnable$1.run(LoadConfigurationRunnable.java:144) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) > at > org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4001) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3629) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1157) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) > at > org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) > at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) > at org.apache.directory.studio.Application.start(Application.java:51) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
[jira] [Commented] (DIRSERVER-2390) Index 0 out of bounds for length 0
[ https://issues.apache.org/jira/browse/DIRSERVER-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844755#comment-17844755 ] David Paulsen commented on DIRSERVER-2390: -- OK thanks for the explanation! The apacheds-2.0.0.AM27.zip version is where I'm having the problem opening the connection in Studio. Since that's not really M28 that should be working, correct? > Index 0 out of bounds for length 0 > -- > > Key: DIRSERVER-2390 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2390 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0.AM27 >Reporter: Jürgen Weber >Priority: Major > > On opening a connection from Directory Studio there is a error message > An error has occurred. See error log for more details. > Index 0 out of bounds for length 0 > eclipse.buildId=unknown > java.version=11.0.21 > java.vendor=Eclipse Adoptium > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_DE > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm > org.eclipse.ui.workbench > Error > Wed Jan 31 11:24:49 CET 2024 > Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". > java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 > at > org.apache.directory.studio.apacheds.configuration.editor.OverviewPage.refreshUI(OverviewPage.java:713) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.pageChanged(ServerConfigurationEditor.java:124) > at > org.eclipse.ui.part.MultiPageEditorPart$5.run(MultiPageEditorPart.java:1231) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) > at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) > at > org.eclipse.ui.part.MultiPageEditorPart.firePageChanged(MultiPageEditorPart.java:1228) > at > org.eclipse.ui.part.MultiPageEditorPart.pageChange(MultiPageEditorPart.java:834) > at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor.java:501) > at > org.eclipse.ui.part.MultiPageEditorPart.setActivePage(MultiPageEditorPart.java:1032) > at > org.eclipse.ui.forms.editor.FormEditor.setActivePage(FormEditor.java:612) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.hideLoadingPageAndDisplayConfigPages(ServerConfigurationEditor.java:421) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.configurationLoaded(ServerConfigurationEditor.java:370) > at > org.apache.directory.studio.apacheds.configuration.jobs.LoadConfigurationRunnable$1.run(LoadConfigurationRunnable.java:144) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) > at > org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4001) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3629) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1157) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) > at > org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) > at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) > at org.apache.directory.studio.Application.start(Application.java:51) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
[jira] [Commented] (DIRSERVER-2390) Index 0 out of bounds for length 0
[ https://issues.apache.org/jira/browse/DIRSERVER-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844738#comment-17844738 ] Emmanuel Lécharny commented on DIRSERVER-2390: -- Hi David, this is a mistake I made when I cut the release. The version M27 is improperly tagged M28, but it's actually a M27. > Index 0 out of bounds for length 0 > -- > > Key: DIRSERVER-2390 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2390 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0.AM27 >Reporter: Jürgen Weber >Priority: Major > > On opening a connection from Directory Studio there is a error message > An error has occurred. See error log for more details. > Index 0 out of bounds for length 0 > eclipse.buildId=unknown > java.version=11.0.21 > java.vendor=Eclipse Adoptium > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_DE > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm > org.eclipse.ui.workbench > Error > Wed Jan 31 11:24:49 CET 2024 > Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". > java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 > at > org.apache.directory.studio.apacheds.configuration.editor.OverviewPage.refreshUI(OverviewPage.java:713) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.pageChanged(ServerConfigurationEditor.java:124) > at > org.eclipse.ui.part.MultiPageEditorPart$5.run(MultiPageEditorPart.java:1231) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) > at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) > at > org.eclipse.ui.part.MultiPageEditorPart.firePageChanged(MultiPageEditorPart.java:1228) > at > org.eclipse.ui.part.MultiPageEditorPart.pageChange(MultiPageEditorPart.java:834) > at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor.java:501) > at > org.eclipse.ui.part.MultiPageEditorPart.setActivePage(MultiPageEditorPart.java:1032) > at > org.eclipse.ui.forms.editor.FormEditor.setActivePage(FormEditor.java:612) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.hideLoadingPageAndDisplayConfigPages(ServerConfigurationEditor.java:421) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.configurationLoaded(ServerConfigurationEditor.java:370) > at > org.apache.directory.studio.apacheds.configuration.jobs.LoadConfigurationRunnable$1.run(LoadConfigurationRunnable.java:144) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) > at > org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4001) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3629) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1157) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) > at > org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) > at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) > at org.apache.directory.studio.Application.start(Application.java:51) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.De
[jira] [Commented] (DIRSERVER-2390) Index 0 out of bounds for length 0
[ https://issues.apache.org/jira/browse/DIRSERVER-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844304#comment-17844304 ] David Paulsen commented on DIRSERVER-2390: -- What I really wanted is the AM27 version since it is released, but when I attempt to download apacheds-2.0.0.AM27.zip from from the link below it appears to contain the AM28 version. Is there a way to download the AM27 version? The AM27 version should work with Studio for configuration, correct? [https://directory.apache.org/apacheds/downloads.html] > Index 0 out of bounds for length 0 > -- > > Key: DIRSERVER-2390 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2390 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0.AM27 >Reporter: Jürgen Weber >Priority: Major > > On opening a connection from Directory Studio there is a error message > An error has occurred. See error log for more details. > Index 0 out of bounds for length 0 > eclipse.buildId=unknown > java.version=11.0.21 > java.vendor=Eclipse Adoptium > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_DE > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm > org.eclipse.ui.workbench > Error > Wed Jan 31 11:24:49 CET 2024 > Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". > java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 > at > org.apache.directory.studio.apacheds.configuration.editor.OverviewPage.refreshUI(OverviewPage.java:713) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.pageChanged(ServerConfigurationEditor.java:124) > at > org.eclipse.ui.part.MultiPageEditorPart$5.run(MultiPageEditorPart.java:1231) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) > at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) > at > org.eclipse.ui.part.MultiPageEditorPart.firePageChanged(MultiPageEditorPart.java:1228) > at > org.eclipse.ui.part.MultiPageEditorPart.pageChange(MultiPageEditorPart.java:834) > at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor.java:501) > at > org.eclipse.ui.part.MultiPageEditorPart.setActivePage(MultiPageEditorPart.java:1032) > at > org.eclipse.ui.forms.editor.FormEditor.setActivePage(FormEditor.java:612) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.hideLoadingPageAndDisplayConfigPages(ServerConfigurationEditor.java:421) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.configurationLoaded(ServerConfigurationEditor.java:370) > at > org.apache.directory.studio.apacheds.configuration.jobs.LoadConfigurationRunnable$1.run(LoadConfigurationRunnable.java:144) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) > at > org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4001) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3629) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1157) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) > at > org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) > at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) > at org.apache.directory.studio.Application.start(Application.java:51) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) > at java.base/jdk.inter
[jira] [Closed] (DIRKRB-773) jvm core when call EncryptionUtil.decrypt(mKey, cipherText, KeyUsage.NONE);
[
https://issues.apache.org/jira/browse/DIRKRB-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed DIRKRB-773.
--
Resolution: Incomplete
> jvm core when call EncryptionUtil.decrypt(mKey, cipherText, KeyUsage.NONE);
> ---
>
> Key: DIRKRB-773
> URL: https://issues.apache.org/jira/browse/DIRKRB-773
> Project: Directory Kerberos
> Issue Type: Bug
>Reporter: scott.zhai
>Priority: Major
>
> {code}
> java version "1.8.0_171"
> Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2390) Index 0 out of bounds for length 0
[ https://issues.apache.org/jira/browse/DIRSERVER-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842425#comment-17842425 ] Emmanuel Lécharny commented on DIRSERVER-2390: -- The Kerberos configuration has been removed from apacheds-2.0.0.AM28, and Studio has not been updated accordingly, leading to the error you get, because lines like this one: ``` setText( kerberosPortText, Integer.toString( kdcServerBean.getTransports()[0].getSystemPort() ) ); ``` will fail as ```kdcServerBean.getTransports()``` will be null. Note that apacheds-server-AM28 ha snot yet been released... > Index 0 out of bounds for length 0 > -- > > Key: DIRSERVER-2390 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2390 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0.AM27 >Reporter: Jürgen Weber >Priority: Major > > On opening a connection from Directory Studio there is a error message > An error has occurred. See error log for more details. > Index 0 out of bounds for length 0 > eclipse.buildId=unknown > java.version=11.0.21 > java.vendor=Eclipse Adoptium > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_DE > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm > org.eclipse.ui.workbench > Error > Wed Jan 31 11:24:49 CET 2024 > Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". > java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 > at > org.apache.directory.studio.apacheds.configuration.editor.OverviewPage.refreshUI(OverviewPage.java:713) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.pageChanged(ServerConfigurationEditor.java:124) > at > org.eclipse.ui.part.MultiPageEditorPart$5.run(MultiPageEditorPart.java:1231) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) > at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) > at > org.eclipse.ui.part.MultiPageEditorPart.firePageChanged(MultiPageEditorPart.java:1228) > at > org.eclipse.ui.part.MultiPageEditorPart.pageChange(MultiPageEditorPart.java:834) > at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor.java:501) > at > org.eclipse.ui.part.MultiPageEditorPart.setActivePage(MultiPageEditorPart.java:1032) > at > org.eclipse.ui.forms.editor.FormEditor.setActivePage(FormEditor.java:612) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.hideLoadingPageAndDisplayConfigPages(ServerConfigurationEditor.java:421) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.configurationLoaded(ServerConfigurationEditor.java:370) > at > org.apache.directory.studio.apacheds.configuration.jobs.LoadConfigurationRunnable$1.run(LoadConfigurationRunnable.java:144) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) > at > org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4001) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3629) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1157) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) > at > org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) > at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) > at org.apache.directory.studio.Application.start(Application.java:51) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) > at > org.eclipse.core.runtime.ada
[jira] [Commented] (DIRSERVER-2390) Index 0 out of bounds for length 0
[ https://issues.apache.org/jira/browse/DIRSERVER-2390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842392#comment-17842392 ] David Paulsen commented on DIRSERVER-2390: -- Can this be fixed? This is preventing us from using this release since we cannot open a configuration to configure partitions, etc. > Index 0 out of bounds for length 0 > -- > > Key: DIRSERVER-2390 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2390 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0.AM27 >Reporter: Jürgen Weber >Priority: Major > > On opening a connection from Directory Studio there is a error message > An error has occurred. See error log for more details. > Index 0 out of bounds for length 0 > eclipse.buildId=unknown > java.version=11.0.21 > java.vendor=Eclipse Adoptium > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_DE > Framework arguments: /studio-rcp/resources/icons/linux/studio.xpm > Command-line arguments: -os win32 -ws win32 -arch x86_64 > /studio-rcp/resources/icons/linux/studio.xpm > org.eclipse.ui.workbench > Error > Wed Jan 31 11:24:49 CET 2024 > Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". > java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 > at > org.apache.directory.studio.apacheds.configuration.editor.OverviewPage.refreshUI(OverviewPage.java:713) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.pageChanged(ServerConfigurationEditor.java:124) > at > org.eclipse.ui.part.MultiPageEditorPart$5.run(MultiPageEditorPart.java:1231) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) > at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:174) > at > org.eclipse.ui.part.MultiPageEditorPart.firePageChanged(MultiPageEditorPart.java:1228) > at > org.eclipse.ui.part.MultiPageEditorPart.pageChange(MultiPageEditorPart.java:834) > at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor.java:501) > at > org.eclipse.ui.part.MultiPageEditorPart.setActivePage(MultiPageEditorPart.java:1032) > at > org.eclipse.ui.forms.editor.FormEditor.setActivePage(FormEditor.java:612) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.hideLoadingPageAndDisplayConfigPages(ServerConfigurationEditor.java:421) > at > org.apache.directory.studio.apacheds.configuration.editor.ServerConfigurationEditor.configurationLoaded(ServerConfigurationEditor.java:370) > at > org.apache.directory.studio.apacheds.configuration.jobs.LoadConfigurationRunnable$1.run(LoadConfigurationRunnable.java:144) > at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40) > at > org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185) > at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4001) > at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3629) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1157) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046) > at > org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155) > at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:644) > at > org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338) > at > org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:551) > at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:156) > at org.apache.directory.studio.Application.start(Application.java:51) > at > org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) > at > org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.De
[jira] [Commented] (DIRSERVER-2394) org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
[
https://issues.apache.org/jira/browse/DIRSERVER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833073#comment-17833073
]
Oleksandr Andreiev commented on DIRSERVER-2394:
---
Got it, thanks!
> org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
>
>
> Key: DIRSERVER-2394
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2394
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.0.AM27
>Reporter: Oleksandr Andreiev
>Priority: Major
>
> I see such an exception after moving from 2.0.0.AM26 to 2.0.0.AM27.
> {{WARN [org.apache.directory.server.ldap.LdapProtocolHandler] - Unexpected
> exception forcing session to close: sending disconnect notice to client.
> org.apache.mina.core.write.WriteToClosedSessionException
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.clearWriteRequestQueue(AbstractPollingIoProcessor.java:1192)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeNow(AbstractPollingIoProcessor.java:1153)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeSessions(AbstractPollingIoProcessor.java:864)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:694)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2394) org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
[
https://issues.apache.org/jira/browse/DIRSERVER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832966#comment-17832966
]
Emmanuel Lécharny commented on DIRSERVER-2394:
--
This is complicated.
The MINA Iohandler exceptionCaught() method which is called here when a write
to a closed session is attempted could be called for many other reasons (all
MINA related).
In any case, there is little we can do in this very case, exception flushing
the exception in the log.
> org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
>
>
> Key: DIRSERVER-2394
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2394
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.0.AM27
>Reporter: Oleksandr Andreiev
>Priority: Major
>
> I see such an exception after moving from 2.0.0.AM26 to 2.0.0.AM27.
> {{WARN [org.apache.directory.server.ldap.LdapProtocolHandler] - Unexpected
> exception forcing session to close: sending disconnect notice to client.
> org.apache.mina.core.write.WriteToClosedSessionException
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.clearWriteRequestQueue(AbstractPollingIoProcessor.java:1192)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeNow(AbstractPollingIoProcessor.java:1153)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeSessions(AbstractPollingIoProcessor.java:864)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:694)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2394) org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
[
https://issues.apache.org/jira/browse/DIRSERVER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832922#comment-17832922
]
Oleksandr Andreiev commented on DIRSERVER-2394:
---
Thank you, I understand. However, I believe it would be better to handle it
more effectively. When you encounter an exception in the log, it raises doubts
about the system's stability and potential impacts on the server.
> org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
>
>
> Key: DIRSERVER-2394
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2394
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.0.AM27
>Reporter: Oleksandr Andreiev
>Priority: Major
>
> I see such an exception after moving from 2.0.0.AM26 to 2.0.0.AM27.
> {{WARN [org.apache.directory.server.ldap.LdapProtocolHandler] - Unexpected
> exception forcing session to close: sending disconnect notice to client.
> org.apache.mina.core.write.WriteToClosedSessionException
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.clearWriteRequestQueue(AbstractPollingIoProcessor.java:1192)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeNow(AbstractPollingIoProcessor.java:1153)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeSessions(AbstractPollingIoProcessor.java:864)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:694)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-2399) Unused variable in OperationalAttributeInterceptor.java
[ https://issues.apache.org/jira/browse/DIRSERVER-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny resolved DIRSERVER-2399. -- Fix Version/s: 2.0.0.AM28 Resolution: Fixed Fixed in master. Thanks! > Unused variable in OperationalAttributeInterceptor.java > > > Key: DIRSERVER-2399 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2399 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0.AM27 >Reporter: Galkin Alexey >Priority: Minor > Fix For: 2.0.0.AM28 > > > PR: > [https://github.com/apache/directory-server/pull/161/commits/5130e4364998907ec845f460e5398723ecb738ed] > > The variable "topStructural", declared on page 759, is not used anywhere > > Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. > Author A. Galkin. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-2398) FB.ES_COMPARING_STRINGS_WITH_EQ in ../server/core/authz/GroupCache.java
[
https://issues.apache.org/jira/browse/DIRSERVER-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRSERVER-2398.
--
Fix Version/s: 2.0.0.AM28
Resolution: Fixed
Thanks, good catch again!
Fixed in master.
> FB.ES_COMPARING_STRINGS_WITH_EQ in ../server/core/authz/GroupCache.java
> ---
>
> Key: DIRSERVER-2398
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2398
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: e.bykhanova
>Priority: Major
> Fix For: 2.0.0.AM28
>
> Attachments: image-2024-03-08-10-35-42-632.png
>
>
> The static analyzer has detected FB.ES_COMPARING_STRINGS_WITH_EQ: Comparison
> of String objects using == or != in [groupModified(Dn, List, Entry,
> SchemaManager)|[https://github.com/apache/directory-server/blob/8c9b56bdcc0703b04b8e2dbdc4f045ed5d83a064/interceptors/authz/src/main/java/org/apache/directory/server/core/authz/GroupCache.java#L394-L438].]
>
> !image-2024-03-08-10-35-42-632.png!
>
> _memberAttr.getOid()_ and _modification.getAttribute().getId()_ are _two
> different instances_ of the class, so operator '{*}=='{*} will get
> '{*}false'{*} at GroupCache.java:420 even if the string literals are
> identical. Operator '{*}=='{*} {_}compares two pointers{_}, but for
> _character-by-character comparison_ of strings, it is necessary to use method
> {*}equals(){*}.
> _To confirm_ or {_}refute the verdict{_}, we consider it necessary to clarify
> with the developers if they expect _a comparison of string literals or
> pointers_ at GroupCache.java:420.
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-2396) SIMILAR_BRANCHES in ../codec/types/PaDataType.java
[
https://issues.apache.org/jira/browse/DIRSERVER-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRSERVER-2396.
--
Fix Version/s: 2.0.0.AM28
Resolution: Fixed
Not any more part of the next release, Kerberos has been removed.
> SIMILAR_BRANCHES in ../codec/types/PaDataType.java
> --
>
> Key: DIRSERVER-2396
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2396
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: e.bykhanova
>Priority: Trivial
> Fix For: 2.0.0.AM28
>
> Attachments: image-2024-03-06-10-53-02-886.png,
> image-2024-03-06-10-53-41-922.png
>
>
> The static analyzer has detected {*}SIMILAR_BRANCHES{*}: here we have
> identical branches in switch node.
> The values for all cases are defined in '{_}public enum PaDataType'{_} **
> (PaDataType.java:28-121). There are comments from the developer: _Constant
> for the "encryption info"_ for {*}PA_ENCTYPE_INFO{*}(11) and _Constant for
> the "encryption info2"_ for \{*}PA_ENCTYPE_INFO2{*}(19) - it seems that
> something like "{_}Encryption info2{_}." would be more logical to use in
> print-function at {_}PaDataType.java:249{_}.
>
> !image-2024-03-06-10-53-02-886.png!
>
> !image-2024-03-06-10-53-41-922.png!
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-2395) SIMILAR_BRANCHES in ../codec/types/PaDataType.java
[
https://issues.apache.org/jira/browse/DIRSERVER-2395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRSERVER-2395.
--
Fix Version/s: 2.0.0.AM28
Resolution: Fixed
The Kerberos related code has been removed from the server.
> SIMILAR_BRANCHES in ../codec/types/PaDataType.java
> --
>
> Key: DIRSERVER-2395
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2395
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: e.bykhanova
>Priority: Trivial
> Fix For: 2.0.0.AM28
>
> Attachments: image-2024-03-05-18-48-50-123.png,
> image-2024-03-05-18-49-32-439.png
>
>
> The static analyzer has detected {*}SIMILAR_BRANCHES{*}: here we have
> identical branches in switch node.
> All branches in this *switch* (function '{_}public static PaDataType
> getTypeByValue(int type){_}') correspond to the values of '{_}public enum
> Datatype{_}' (PaDataType.java:28-121). In this *enum*
> {*}PA_PK_AS_REQ{*}-value corresponds to the order *14* and
> \{*}PA_PK_AS_REP{*}-value corresponds to the order \{*}15{*}. It seems that
> the developer just overlooked that _the last letter_ in the values at
> PaDataType.java:184 and PaDataType.java:186 _should be different_ - the
> parameters PA_PK_AS_REQ and PA_PK_AS_REP look quite similar :)
>
> !image-2024-03-05-18-48-50-123.png!
>
> !image-2024-03-05-18-49-32-439.png!
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2394) org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
[
https://issues.apache.org/jira/browse/DIRSERVER-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832669#comment-17832669
]
Emmanuel Lécharny commented on DIRSERVER-2394:
--
Not a bug.
It's a client session that has been shutdown and the server reacts to this fact
bu closing the TCP session on its side.
> org.apache.mina.core.write.WriteToClosedSessionException every 40-60 seconds
>
>
> Key: DIRSERVER-2394
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2394
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: core
>Affects Versions: 2.0.0.AM27
>Reporter: Oleksandr Andreiev
>Priority: Major
>
> I see such an exception after moving from 2.0.0.AM26 to 2.0.0.AM27.
> {{WARN [org.apache.directory.server.ldap.LdapProtocolHandler] - Unexpected
> exception forcing session to close: sending disconnect notice to client.
> org.apache.mina.core.write.WriteToClosedSessionException
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.clearWriteRequestQueue(AbstractPollingIoProcessor.java:1192)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeNow(AbstractPollingIoProcessor.java:1153)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.removeSessions(AbstractPollingIoProcessor.java:864)
> at
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:694)
> at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRAPI-398) Release Pooled LDAP Connections when closed
[ https://issues.apache.org/jira/browse/DIRAPI-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lécharny resolved DIRAPI-398. -- Fix Version/s: 2.1.7 Resolution: Fixed Thanks Brian! I committed the second proposal. > Release Pooled LDAP Connections when closed > --- > > Key: DIRAPI-398 > URL: https://issues.apache.org/jira/browse/DIRAPI-398 > Project: Directory Client API > Issue Type: Improvement >Reporter: Brian Demers >Priority: Major > Fix For: 2.1.7 > > > Connections returned from a connection pool should be "released" instead of > closed. > Ultimately the usage of a Pooled connection should be similar to a _regular_ > connection. > It can be used in a try-with-resource block, then auto closed. In the case > of a pooled connection, that `close()` call should return the connection to > the pool. > Related mailing list thread: > https://lists.apache.org/thread/jpsg6g3sfspsgfpgn30kx4orspksnzm7 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSERVER-2397) FB.ES_COMPARING_STRINGS_WITH_EQ in ../server/xdbm/search/impl/DefaultOptimizer.java
[
https://issues.apache.org/jira/browse/DIRSERVER-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lécharny resolved DIRSERVER-2397.
--
Fix Version/s: 2.0.0.AM28
Resolution: Fixed
Thanks and good catch!
Fixed with commit 004437a5a35c36cc128a3a2e4e5b392a8df83102
> FB.ES_COMPARING_STRINGS_WITH_EQ in
> ../server/xdbm/search/impl/DefaultOptimizer.java
> ---
>
> Key: DIRSERVER-2397
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2397
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: e.bykhanova
>Priority: Major
> Fix For: 2.0.0.AM28
>
> Attachments: image-2024-03-06-21-46-08-238.png,
> image-2024-03-06-21-47-20-926.png
>
>
> The static analyzer has detected FB.ES_COMPARING_STRINGS_WITH_EQ: comparison
> of String objects using == or != in [{_}getScopeScan(PartitionTxn,
> ScopeNode)](https://github.com/apache/directory-server/blob/8c9b56bdcc0703b04b8e2dbdc4f045ed5d83a064/xdbm-partition/src/main/java/org/apache/directory/server/xdbm/search/impl/DefaultOptimizer.java#L497C2-L523C2).{_}
> !image-2024-03-06-21-47-20-926.png!
> The ES_COMPARING_STRINGS_WITH_EQ detector worked because in Java the ==
> operator compares objects for reference equality, but not string literals
> contained in these objects.
> According to
> [one](https://github.com/apache/directory-server/commit/cfa2152efaa693368634e5d278890f7f5d2c9914#diff-90992891001769bbc1422416e6c9fe2e0ff73afbc5660f877244f2545b95f58fL353)
> of the previous commits, here we have the following logic: we excpected to
> get the comparison of string literals contained in these objects.
>
> !image-2024-03-06-21-46-08-238.png!
> Using the _equals(Object)_ method here seems to be a better practice.
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2399) Unused variable in OperationalAttributeInterceptor.java
Galkin Alexey created DIRSERVER-2399: Summary: Unused variable in OperationalAttributeInterceptor.java Key: DIRSERVER-2399 URL: https://issues.apache.org/jira/browse/DIRSERVER-2399 Project: Directory ApacheDS Issue Type: Bug Affects Versions: 2.0.0.AM27 Reporter: Galkin Alexey PR: [https://github.com/apache/directory-server/pull/161/commits/5130e4364998907ec845f460e5398723ecb738ed] The variable "topStructural", declared on page 759, is not used anywhere Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. Author A. Galkin. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
[
https://issues.apache.org/jira/browse/DIRAPI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824984#comment-17824984
]
Thomas Jodes commented on DIRAPI-399:
-
Yes I can provide a unit test for both cases but I cannot ship a (Microsoft
Active) Directory Server to proof our case here one-to-one. Would be that ok?
> Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s)
> picked up
> --
>
> Key: DIRAPI-399
> URL: https://issues.apache.org/jira/browse/DIRAPI-399
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Thomas Jodes
>Priority: Major
> Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
> 2024-03-01 15-48-52.png
>
>
> As a ldap-api user, I want to search my DIT paginated from a base where also
> referrals /
> [SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
> are.
> Following paged search code:
>
> {code:java}
> int pageSize = 100;
> LdapConnection connection = null;
> try {
> connection = ldapConnectionPool.getConnection();
> int page = 0; // the current page
> PagedResults pagedSearchControl = new PagedResultsImpl();
> pagedSearchControl.setSize(pageSize);
> // Loop using the paged search control extension
> while(true) {
> SearchRequest searchRequest = new SearchRequestImpl()
> .ignoreReferrals()
> .setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
> .setBase(new Dn(searchBase))
> .setFilter(filter)
> .setScope(SearchScope.SUBTREE)
> .addAttributes(attributes)
> .setTimeLimit(120)
> .addControl(pagedSearchControl);
> SearchCursorImpl searchCursor = (SearchCursorImpl)
> connection.search(searchRequest);
> try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
> while (cursor.next()) {
> Entry e = cursor.get();
> log.info("element: {}", e.get("sAMAccountName"));
> results.add(e);
> }
> SearchResultDone searchResult = cursor.getSearchResultDone();
> pagedSearchControl =
> (PagedResults)searchResult.getControl(PagedResults.OID);
> if (searchResult.getLdapResult().getResultCode() ==
> ResultCodeEnum.UNWILLING_TO_PERFORM) {
> throw new LdapException("Directory cannot handle
> pagination!");
> }
> } catch (CursorException e) {
> log.error("Unexpected cursor exception occurred!", e);
> }
> // Check if pagination is exhausted (all eligible entries have been
> read)
> if (Strings.isEmpty(pagedSearchControl.getCookie())) {
> log.info("Exiting paged search at page: " + ++page);
> break;
> }
> // Prepare the next iteration
> pagedSearchControl.setSize(pageSize);
> }
> // here we want to do s.th. with our 'results' reference;
> } catch (LdapException e) {
> log.error("Unexpected ldap exception occurred!", e);
> } catch (IOException e) {
> log.error("Unexpected I/O exception occurred!", e);
> } finally {
> if (connection != null) {
> ldapConnectionPool.releaseConnection(connection); // put the
> session/connection back to its pool
> }
> } {code}
>
> *Expected behaviour:*
> all elements in the base are picked up in the 'results' list, all paginated
> and added up by x times a bunch of 100 until everything has been read in the
> directory. In the searchFuture at LdapNetworkConnection.searchAsync should be
> 101 elements: 100 SearchResultEntryImpl's and one SearchResultDoneImpl.
>
> *Actual behaviour:*
> in the first page there are 100 entries, i.e. 100x SearchResultEntryImpl
> elements PLUS (in my case/active directory) 3x SearchResultReferenceImpl
> elements plus 1x SerachResultDoneImpl element as the last one in the array of
> the searchFuture here:[
> LdapNetworkConnection#searchAsync()|https://github.com/apache/
[jira] [Commented] (DIRSERVER-2398) FB.ES_COMPARING_STRINGS_WITH_EQ in ../server/core/authz/GroupCache.java
[
https://issues.apache.org/jira/browse/DIRSERVER-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824647#comment-17824647
]
e.bykhanova commented on DIRSERVER-2398:
Link to the source code of the function groupModified(Dn, List, Entry,
SchemaManager):
https://github.com/apache/directory-server/blob/8c9b56bdcc0703b04b8e2dbdc4f045ed5d83a064/interceptors/authz/src/main/java/org/apache/directory/server/core/authz/GroupCache.java#L394-L438
> FB.ES_COMPARING_STRINGS_WITH_EQ in ../server/core/authz/GroupCache.java
> ---
>
> Key: DIRSERVER-2398
> URL: https://issues.apache.org/jira/browse/DIRSERVER-2398
> Project: Directory ApacheDS
> Issue Type: Bug
>Affects Versions: 2.0.0.AM26
>Reporter: e.bykhanova
>Priority: Major
> Attachments: image-2024-03-08-10-35-42-632.png
>
>
> The static analyzer has detected FB.ES_COMPARING_STRINGS_WITH_EQ: Comparison
> of String objects using == or != in [groupModified(Dn, List, Entry,
> SchemaManager)|[https://github.com/apache/directory-server/blob/8c9b56bdcc0703b04b8e2dbdc4f045ed5d83a064/interceptors/authz/src/main/java/org/apache/directory/server/core/authz/GroupCache.java#L394-L438].]
>
> !image-2024-03-08-10-35-42-632.png!
>
> _memberAttr.getOid()_ and _modification.getAttribute().getId()_ are _two
> different instances_ of the class, so operator '{*}=='{*} will get
> '{*}false'{*} at GroupCache.java:420 even if the string literals are
> identical. Operator '{*}=='{*} {_}compares two pointers{_}, but for
> _character-by-character comparison_ of strings, it is necessary to use method
> {*}equals(){*}.
> _To confirm_ or {_}refute the verdict{_}, we consider it necessary to clarify
> with the developers if they expect _a comparison of string literals or
> pointers_ at GroupCache.java:420.
>
> Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
> Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2398) FB.ES_COMPARING_STRINGS_WITH_EQ in ../server/core/authz/GroupCache.java
e.bykhanova created DIRSERVER-2398:
--
Summary: FB.ES_COMPARING_STRINGS_WITH_EQ in
../server/core/authz/GroupCache.java
Key: DIRSERVER-2398
URL: https://issues.apache.org/jira/browse/DIRSERVER-2398
Project: Directory ApacheDS
Issue Type: Bug
Affects Versions: 2.0.0.AM26
Reporter: e.bykhanova
Attachments: image-2024-03-08-10-35-42-632.png
The static analyzer has detected FB.ES_COMPARING_STRINGS_WITH_EQ: Comparison of
String objects using == or != in [groupModified(Dn, List, Entry,
SchemaManager)|[https://github.com/apache/directory-server/blob/8c9b56bdcc0703b04b8e2dbdc4f045ed5d83a064/interceptors/authz/src/main/java/org/apache/directory/server/core/authz/GroupCache.java#L394-L438].]
!image-2024-03-08-10-35-42-632.png!
_memberAttr.getOid()_ and _modification.getAttribute().getId()_ are _two
different instances_ of the class, so operator '{*}=='{*} will get
'{*}false'{*} at GroupCache.java:420 even if the string literals are identical.
Operator '{*}=='{*} {_}compares two pointers{_}, but for
_character-by-character comparison_ of strings, it is necessary to use method
{*}equals(){*}.
_To confirm_ or {_}refute the verdict{_}, we consider it necessary to clarify
with the developers if they expect _a comparison of string literals or
pointers_ at GroupCache.java:420.
Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2397) FB.ES_COMPARING_STRINGS_WITH_EQ in ../server/xdbm/search/impl/DefaultOptimizer.java
e.bykhanova created DIRSERVER-2397:
--
Summary: FB.ES_COMPARING_STRINGS_WITH_EQ in
../server/xdbm/search/impl/DefaultOptimizer.java
Key: DIRSERVER-2397
URL: https://issues.apache.org/jira/browse/DIRSERVER-2397
Project: Directory ApacheDS
Issue Type: Bug
Affects Versions: 2.0.0.AM26
Reporter: e.bykhanova
Attachments: image-2024-03-06-21-46-08-238.png,
image-2024-03-06-21-47-20-926.png
The static analyzer has detected FB.ES_COMPARING_STRINGS_WITH_EQ: comparison of
String objects using == or != in [{_}getScopeScan(PartitionTxn,
ScopeNode)](https://github.com/apache/directory-server/blob/8c9b56bdcc0703b04b8e2dbdc4f045ed5d83a064/xdbm-partition/src/main/java/org/apache/directory/server/xdbm/search/impl/DefaultOptimizer.java#L497C2-L523C2).{_}
!image-2024-03-06-21-47-20-926.png!
The ES_COMPARING_STRINGS_WITH_EQ detector worked because in Java the ==
operator compares objects for reference equality, but not string literals
contained in these objects.
According to
[one](https://github.com/apache/directory-server/commit/cfa2152efaa693368634e5d278890f7f5d2c9914#diff-90992891001769bbc1422416e6c9fe2e0ff73afbc5660f877244f2545b95f58fL353)
of the previous commits, here we have the following logic: we excpected to get
the comparison of string literals contained in these objects.
!image-2024-03-06-21-46-08-238.png!
Using the _equals(Object)_ method here seems to be a better practice.
Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1337) Remove gthe Kerberos part as the Directory Server does not anymore contains the lib
Emmanuel Lécharny created DIRSTUDIO-1337: Summary: Remove gthe Kerberos part as the Directory Server does not anymore contains the lib Key: DIRSTUDIO-1337 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1337 Project: Directory Studio Issue Type: Task Components: studio-apacheds Affects Versions: 2.0.0-M17 Reporter: Emmanuel Lécharny Fix For: 2.0.0-M18 ApacheDS does not anymore contain the Kerberos server. All the associated configuration should be removed from Studio. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2396) SIMILAR_BRANCHES in ../codec/types/PaDataType.java
e.bykhanova created DIRSERVER-2396:
--
Summary: SIMILAR_BRANCHES in ../codec/types/PaDataType.java
Key: DIRSERVER-2396
URL: https://issues.apache.org/jira/browse/DIRSERVER-2396
Project: Directory ApacheDS
Issue Type: Bug
Affects Versions: 2.0.0.AM26
Reporter: e.bykhanova
Attachments: image-2024-03-06-10-53-02-886.png,
image-2024-03-06-10-53-41-922.png
The static analyzer has detected {*}SIMILAR_BRANCHES{*}: here we have identical
branches in switch node.
The values for all cases are defined in '{_}public enum PaDataType'{_} **
(PaDataType.java:28-121). There are comments from the developer: _Constant for
the "encryption info"_ for {*}PA_ENCTYPE_INFO{*}(11) and _Constant for the
"encryption info2"_ for \{*}PA_ENCTYPE_INFO2{*}(19) - it seems that something
like "{_}Encryption info2{_}." would be more logical to use in print-function
at {_}PaDataType.java:249{_}.
!image-2024-03-06-10-53-02-886.png!
!image-2024-03-06-10-53-41-922.png!
Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSERVER-2395) SIMILAR_BRANCHES in ../codec/types/PaDataType.java
e.bykhanova created DIRSERVER-2395:
--
Summary: SIMILAR_BRANCHES in ../codec/types/PaDataType.java
Key: DIRSERVER-2395
URL: https://issues.apache.org/jira/browse/DIRSERVER-2395
Project: Directory ApacheDS
Issue Type: Bug
Affects Versions: 2.0.0.AM26
Reporter: e.bykhanova
Attachments: image-2024-03-05-18-48-50-123.png,
image-2024-03-05-18-49-32-439.png
The static analyzer has detected {*}SIMILAR_BRANCHES{*}: here we have identical
branches in switch node.
All branches in this *switch* (function '{_}public static PaDataType
getTypeByValue(int type){_}') correspond to the values of '{_}public enum
Datatype{_}' (PaDataType.java:28-121). In this *enum* {*}PA_PK_AS_REQ{*}-value
corresponds to the order *14* and \{*}PA_PK_AS_REP{*}-value corresponds to the
order \{*}15{*}. It seems that the developer just overlooked that _the last
letter_ in the values at PaDataType.java:184 and PaDataType.java:186 _should be
different_ - the parameters PA_PK_AS_REQ and PA_PK_AS_REP look quite similar :)
!image-2024-03-05-18-48-50-123.png!
!image-2024-03-05-18-49-32-439.png!
Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author E. Bykhanova (e.bykhan...@fobos-nt.ru).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRAPI-397) Update Copyright year
[
https://issues.apache.org/jira/browse/DIRAPI-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823626#comment-17823626
]
Emmanuel Lécharny edited comment on DIRAPI-397 at 3/5/24 1:52 PM:
--
The proposal to set the upper bound to 'present' should be fine.
Legally speaking (afaik), the upper range is useless. The idea is to 'stamp'
the original release, and optionally all the other releases.
What is important is the date from which the copyright applies. So we could
perfectly only set the first date (like 2003):
{code:java}
"The copyright notice should include the year in which you finished preparing
the release (so if you finished it in 1998 but didn't post it until 1999, use
1998). You should add the proper year for each past release; for example,
“Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and
some were finished in 1999. If several people helped write the code, use all
their names.
For software with several releases over multiple years, it's okay to use a
range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if
and only if every year in the range, inclusive, really is a “copyrightable”
year that would be listed individually; and you make an explicit statement in
your documentation about this usage."
{code}
(see [The GNU copyright Notice|https://www.gnu.org/licenses/gpl-howto.en.html])
But for clarity, 'present' as an upper bound makes sense.
was (Author: elecharny):
The proposal to set the upper bound to 'present' should be fine.
Legally speaking (afaik), the upper range is useless. The idea is to 'stamp'
the original release, and optionally all the other releases.
What is important is the date from which the copyright applies. So we could
perfectly only set the first date (like 2003):
{code:java}
"The copyright notice should include the year in which you finished preparing
the release (so if you finished it in 1998 but didn't post it until 1999, use
1998). You should add the proper year for each past release; for example,
“Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and
some were finished in 1999. If several people helped write the code, use all
their names.
For software with several releases over multiple years, it's okay to use a
range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if
and only if every year in the range, inclusive, really is a “copyrightable”
year that would be listed individually; and you make an explicit statement in
your documentation about this usage."
{code}
(see [The GNU copyright Notice|https//www.gnu.org/licenses/gpl-howto.en.html])
But for clarity, 'present' as an upper bound makes sense.
> Update Copyright year
> --
>
> Key: DIRAPI-397
> URL: https://issues.apache.org/jira/browse/DIRAPI-397
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>
> Set to 2024
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRAPI-397) Update Copyright year
[
https://issues.apache.org/jira/browse/DIRAPI-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823626#comment-17823626
]
Emmanuel Lécharny edited comment on DIRAPI-397 at 3/5/24 1:51 PM:
--
The proposal to set the upper bound to 'present' should be fine.
Legally speaking (afaik), the upper range is useless. The idea is to 'stamp'
the original release, and optionally all the other releases.
What is important is the date from which the copyright applies. So we could
perfectly only set the first date (like 2003):
{code:java}
"The copyright notice should include the year in which you finished preparing
the release (so if you finished it in 1998 but didn't post it until 1999, use
1998). You should add the proper year for each past release; for example,
“Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and
some were finished in 1999. If several people helped write the code, use all
their names.
For software with several releases over multiple years, it's okay to use a
range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if
and only if every year in the range, inclusive, really is a “copyrightable”
year that would be listed individually; and you make an explicit statement in
your documentation about this usage."
{code}
(see [The GNU copyright Notice|https//www.gnu.org/licenses/gpl-howto.en.html])
But for clarity, 'present' as an upper bound makes sense.
was (Author: elecharny):
The proposal to set the upper bound to 'present' should be fine.
Legally speaking (afaik), the upper range is useless. The idea is to 'stamp'
the original release, and optionally all the other releases.
What is important is the date from which the copyright applies. So we could
perfectly only set the first date (like 2003):
{code:java}
"The copyright notice should include the year in which you finished preparing
the release (so if you finished it in 1998 but didn't post it until 1999, use
1998). You should add the proper year for each past release; for example,
“Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and
some were finished in 1999. If several people helped write the code, use all
their names.
For software with several releases over multiple years, it's okay to use a
range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if
and only if every year in the range, inclusive, really is a “copyrightable”
year that would be listed individually; and you make an explicit statement in
your documentation about this usage."
{code}
(see [The GNU copyright Notice|https//www.gnu.org/licenses/gpl-howto.en.html])
But for clarity, 'present' as an upper bound makes sense.
> Update Copyright year
> --
>
> Key: DIRAPI-397
> URL: https://issues.apache.org/jira/browse/DIRAPI-397
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>
> Set to 2024
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRAPI-397) Update Copyright year
[
https://issues.apache.org/jira/browse/DIRAPI-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823626#comment-17823626
]
Emmanuel Lécharny edited comment on DIRAPI-397 at 3/5/24 1:50 PM:
--
The proposal to set the upper bound to 'present' should be fine.
Legally speaking (afaik), the upper range is useless. The idea is to 'stamp'
the original release, and optionally all the other releases.
What is important is the date from which the copyright applies. So we could
perfectly only set the first date (like 2003):
{code:java}
"The copyright notice should include the year in which you finished preparing
the release (so if you finished it in 1998 but didn't post it until 1999, use
1998). You should add the proper year for each past release; for example,
“Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and
some were finished in 1999. If several people helped write the code, use all
their names.
For software with several releases over multiple years, it's okay to use a
range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if
and only if every year in the range, inclusive, really is a “copyrightable”
year that would be listed individually; and you make an explicit statement in
your documentation about this usage."
{code}
(see [The GNU copyright Notice|https//www.gnu.org/licenses/gpl-howto.en.html])
But for clarity, 'present' as an upper bound makes sense.
was (Author: elecharny):
The proposal to set the upper bound to 'present' should be fine.
Legally speaking (afaik), the upper range is useless. The idea is to 'stamp'
the original release, and optionally all the other releases.
What is important is the date from which the copyright applies. So we could
perfectly only set the first date (like 2003):
{code:java}
"The copyright notice should include the year in which you finished preparing
the release (so if you finished it in 1998 but didn't post it until 1999, use
1998). You should add the proper year for each past release; for example,
“Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and
some were finished in 1999. If several people helped write the code, use all
their names.
For software with several releases over multiple years, it's okay to use a
range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if
and only if every year in the range, inclusive, really is a “copyrightable”
year that would be listed individually; and you make an explicit statement in
your documentation about this usage."
{code}
(see [The GNU copyright Notice|//www.gnu.org/licenses/gpl-howto.en.html])
But for clarity, 'present' as an upper bound makes sense.
> Update Copyright year
> --
>
> Key: DIRAPI-397
> URL: https://issues.apache.org/jira/browse/DIRAPI-397
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>
> Set to 2024
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRAPI-397) Update Copyright year
[
https://issues.apache.org/jira/browse/DIRAPI-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823626#comment-17823626
]
Emmanuel Lécharny commented on DIRAPI-397:
--
The proposal to set the upper bound to 'present' should be fine.
Legally speaking (afaik), the upper range is useless. The idea is to 'stamp'
the original release, and optionally all the other releases.
What is important is the date from which the copyright applies. So we could
perfectly only set the first date (like 2003):
{code:java}
"The copyright notice should include the year in which you finished preparing
the release (so if you finished it in 1998 but didn't post it until 1999, use
1998). You should add the proper year for each past release; for example,
“Copyright 1998, 1999 Terry Jones” if some releases were finished in 1998 and
some were finished in 1999. If several people helped write the code, use all
their names.
For software with several releases over multiple years, it's okay to use a
range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if
and only if every year in the range, inclusive, really is a “copyrightable”
year that would be listed individually; and you make an explicit statement in
your documentation about this usage."
{code}
(see [The GNU copyright Notice|//www.gnu.org/licenses/gpl-howto.en.html])
But for clarity, 'present' as an upper bound makes sense.
> Update Copyright year
> --
>
> Key: DIRAPI-397
> URL: https://issues.apache.org/jira/browse/DIRAPI-397
> Project: Directory Client API
> Issue Type: Improvement
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>
> Set to 2024
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Comment Edited] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
[
https://issues.apache.org/jira/browse/DIRAPI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823128#comment-17823128
]
Thomas Jodes edited comment on DIRAPI-399 at 3/4/24 1:22 PM:
-
Edit: I switched paged search as seen above not to use the EntryCursorImpl, but
to use [SearchCursor like
here|https://directory.apache.org/api/user-guide/2.3-searching.html]. Just to
work with the SearchCursor and to use the cast to SearchResultEntry.
Interestingly, not a single SearchResultReference comes up, so referals absent
here. When wrapping the searchResult in the EntryCursorImpl (EntryCursor cursor
= new EntryCursorImpl(searchCursor)), the references are in the first page
results.
was (Author: JIRAUSER286693):
Edit: I switched paged search as seen above not to use the EntryCursorImpl, but
to use [SearchCursor like
here|[http://example.com|https://directory.apache.org/api/user-guide/2.3-searching.html]].
Just to work with the SearchCursor and to use the cast to SearchResultEntry.
Interestingly, not a single SearchResultReference comes up, so referals absent
here. When wrapping the searchResult in the EntryCursorImpl (EntryCursor cursor
= new EntryCursorImpl(searchCursor)), the references are in the first page
results.
> Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s)
> picked up
> --
>
> Key: DIRAPI-399
> URL: https://issues.apache.org/jira/browse/DIRAPI-399
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Thomas Jodes
>Priority: Major
> Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
> 2024-03-01 15-48-52.png
>
>
> As a ldap-api user, I want to search my DIT paginated from a base where also
> referrals /
> [SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
> are.
> Following paged search code:
>
> {code:java}
> int pageSize = 100;
> LdapConnection connection = null;
> try {
> connection = ldapConnectionPool.getConnection();
> int page = 0; // the current page
> PagedResults pagedSearchControl = new PagedResultsImpl();
> pagedSearchControl.setSize(pageSize);
> // Loop using the paged search control extension
> while(true) {
> SearchRequest searchRequest = new SearchRequestImpl()
> .ignoreReferrals()
> .setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
> .setBase(new Dn(searchBase))
> .setFilter(filter)
> .setScope(SearchScope.SUBTREE)
> .addAttributes(attributes)
> .setTimeLimit(120)
> .addControl(pagedSearchControl);
> SearchCursorImpl searchCursor = (SearchCursorImpl)
> connection.search(searchRequest);
> try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
> while (cursor.next()) {
> Entry e = cursor.get();
> log.info("element: {}", e.get("sAMAccountName"));
> results.add(e);
> }
> SearchResultDone searchResult = cursor.getSearchResultDone();
> pagedSearchControl =
> (PagedResults)searchResult.getControl(PagedResults.OID);
> if (searchResult.getLdapResult().getResultCode() ==
> ResultCodeEnum.UNWILLING_TO_PERFORM) {
> throw new LdapException("Directory cannot handle
> pagination!");
> }
> } catch (CursorException e) {
> log.error("Unexpected cursor exception occurred!", e);
> }
> // Check if pagination is exhausted (all eligible entries have been
> read)
> if (Strings.isEmpty(pagedSearchControl.getCookie())) {
> log.info("Exiting paged search at page: " + ++page);
> break;
> }
> // Prepare the next iteration
> pagedSearchControl.setSize(pageSize);
> }
> // here we want to do s.th. with our 'results' reference;
> } catch (LdapException e) {
> log.error("Unexpected ldap exception occurred!", e);
> } catch (IOException e) {
> log.error("Unexpected I/O exception occurred!", e);
>
[jira] [Commented] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
[
https://issues.apache.org/jira/browse/DIRAPI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823161#comment-17823161
]
Emmanuel Lécharny commented on DIRAPI-399:
--
Thanks for the clarification.
Could you be kind enough to build a unit test, or a standalone test with some
data for me to debug the code and see if there is some issue in the LDAP API?
Many thanks!
> Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s)
> picked up
> --
>
> Key: DIRAPI-399
> URL: https://issues.apache.org/jira/browse/DIRAPI-399
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Thomas Jodes
>Priority: Major
> Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
> 2024-03-01 15-48-52.png
>
>
> As a ldap-api user, I want to search my DIT paginated from a base where also
> referrals /
> [SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
> are.
> Following paged search code:
>
> {code:java}
> int pageSize = 100;
> LdapConnection connection = null;
> try {
> connection = ldapConnectionPool.getConnection();
> int page = 0; // the current page
> PagedResults pagedSearchControl = new PagedResultsImpl();
> pagedSearchControl.setSize(pageSize);
> // Loop using the paged search control extension
> while(true) {
> SearchRequest searchRequest = new SearchRequestImpl()
> .ignoreReferrals()
> .setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
> .setBase(new Dn(searchBase))
> .setFilter(filter)
> .setScope(SearchScope.SUBTREE)
> .addAttributes(attributes)
> .setTimeLimit(120)
> .addControl(pagedSearchControl);
> SearchCursorImpl searchCursor = (SearchCursorImpl)
> connection.search(searchRequest);
> try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
> while (cursor.next()) {
> Entry e = cursor.get();
> log.info("element: {}", e.get("sAMAccountName"));
> results.add(e);
> }
> SearchResultDone searchResult = cursor.getSearchResultDone();
> pagedSearchControl =
> (PagedResults)searchResult.getControl(PagedResults.OID);
> if (searchResult.getLdapResult().getResultCode() ==
> ResultCodeEnum.UNWILLING_TO_PERFORM) {
> throw new LdapException("Directory cannot handle
> pagination!");
> }
> } catch (CursorException e) {
> log.error("Unexpected cursor exception occurred!", e);
> }
> // Check if pagination is exhausted (all eligible entries have been
> read)
> if (Strings.isEmpty(pagedSearchControl.getCookie())) {
> log.info("Exiting paged search at page: " + ++page);
> break;
> }
> // Prepare the next iteration
> pagedSearchControl.setSize(pageSize);
> }
> // here we want to do s.th. with our 'results' reference;
> } catch (LdapException e) {
> log.error("Unexpected ldap exception occurred!", e);
> } catch (IOException e) {
> log.error("Unexpected I/O exception occurred!", e);
> } finally {
> if (connection != null) {
> ldapConnectionPool.releaseConnection(connection); // put the
> session/connection back to its pool
> }
> } {code}
>
> *Expected behaviour:*
> all elements in the base are picked up in the 'results' list, all paginated
> and added up by x times a bunch of 100 until everything has been read in the
> directory. In the searchFuture at LdapNetworkConnection.searchAsync should be
> 101 elements: 100 SearchResultEntryImpl's and one SearchResultDoneImpl.
>
> *Actual behaviour:*
> in the first page there are 100 entries, i.e. 100x SearchResultEntryImpl
> elements PLUS (in my case/active directory) 3x SearchResultReferenceImpl
> elements plus 1x SerachResultDoneImpl element as the last one in the array of
> the searchFuture here:[
> LdapNetworkConnection#searchAsy
[jira] [Commented] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
[
https://issues.apache.org/jira/browse/DIRAPI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823128#comment-17823128
]
Thomas Jodes commented on DIRAPI-399:
-
Edit: I switched paged search as seen above not to use the EntryCursorImpl, but
to use [SearchCursor like
here|[http://example.com|https://directory.apache.org/api/user-guide/2.3-searching.html]].
Just to work with the SearchCursor and to use the cast to SearchResultEntry.
Interestingly, not a single SearchResultReference comes up, so referals absent
here. When wrapping the searchResult in the EntryCursorImpl (EntryCursor cursor
= new EntryCursorImpl(searchCursor)), the references are in the first page
results.
> Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s)
> picked up
> --
>
> Key: DIRAPI-399
> URL: https://issues.apache.org/jira/browse/DIRAPI-399
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Thomas Jodes
>Priority: Major
> Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
> 2024-03-01 15-48-52.png
>
>
> As a ldap-api user, I want to search my DIT paginated from a base where also
> referrals /
> [SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
> are.
> Following paged search code:
>
> {code:java}
> int pageSize = 100;
> LdapConnection connection = null;
> try {
> connection = ldapConnectionPool.getConnection();
> int page = 0; // the current page
> PagedResults pagedSearchControl = new PagedResultsImpl();
> pagedSearchControl.setSize(pageSize);
> // Loop using the paged search control extension
> while(true) {
> SearchRequest searchRequest = new SearchRequestImpl()
> .ignoreReferrals()
> .setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
> .setBase(new Dn(searchBase))
> .setFilter(filter)
> .setScope(SearchScope.SUBTREE)
> .addAttributes(attributes)
> .setTimeLimit(120)
> .addControl(pagedSearchControl);
> SearchCursorImpl searchCursor = (SearchCursorImpl)
> connection.search(searchRequest);
> try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
> while (cursor.next()) {
> Entry e = cursor.get();
> log.info("element: {}", e.get("sAMAccountName"));
> results.add(e);
> }
> SearchResultDone searchResult = cursor.getSearchResultDone();
> pagedSearchControl =
> (PagedResults)searchResult.getControl(PagedResults.OID);
> if (searchResult.getLdapResult().getResultCode() ==
> ResultCodeEnum.UNWILLING_TO_PERFORM) {
> throw new LdapException("Directory cannot handle
> pagination!");
> }
> } catch (CursorException e) {
> log.error("Unexpected cursor exception occurred!", e);
> }
> // Check if pagination is exhausted (all eligible entries have been
> read)
> if (Strings.isEmpty(pagedSearchControl.getCookie())) {
> log.info("Exiting paged search at page: " + ++page);
> break;
> }
> // Prepare the next iteration
> pagedSearchControl.setSize(pageSize);
> }
> // here we want to do s.th. with our 'results' reference;
> } catch (LdapException e) {
> log.error("Unexpected ldap exception occurred!", e);
> } catch (IOException e) {
> log.error("Unexpected I/O exception occurred!", e);
> } finally {
> if (connection != null) {
> ldapConnectionPool.releaseConnection(connection); // put the
> session/connection back to its pool
> }
> } {code}
>
> *Expected behaviour:*
> all elements in the base are picked up in the 'results' list, all paginated
> and added up by x times a bunch of 100 until everything has been read in the
> directory. In the searchFuture at LdapNetworkConnection.searchAsync should be
> 101 elements: 100 SearchResultEntryImpl's and one SearchResultDoneImpl.
>
> *Actual beha
[jira] [Commented] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
[
https://issues.apache.org/jira/browse/DIRAPI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823119#comment-17823119
]
Thomas Jodes commented on DIRAPI-399:
-
Hi,
that's a clue if that Active Directory server does not seem to respect the
IgnoreReferals flag - however using the search in the ApacheDirectory Studio,
the three referal nodes will vanish in the DIT...
That is, up to this the question at stake is, if the ignore referals flag is
ignored using the DIRAPI as seen above (bug? because Apache Studio filters them
away when saying per radio button "ignore refereals"+ checkbox "paged search")
- or is it as simple as that that the code shown above is simply used wrong?
(unfortunately there aren't resources in the ldap-api website regading paged
seach+ignore referals).
Yours sincerly,
Thomas
> Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s)
> picked up
> --
>
> Key: DIRAPI-399
> URL: https://issues.apache.org/jira/browse/DIRAPI-399
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Thomas Jodes
>Priority: Major
> Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
> 2024-03-01 15-48-52.png
>
>
> As a ldap-api user, I want to search my DIT paginated from a base where also
> referrals /
> [SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
> are.
> Following paged search code:
>
> {code:java}
> int pageSize = 100;
> LdapConnection connection = null;
> try {
> connection = ldapConnectionPool.getConnection();
> int page = 0; // the current page
> PagedResults pagedSearchControl = new PagedResultsImpl();
> pagedSearchControl.setSize(pageSize);
> // Loop using the paged search control extension
> while(true) {
> SearchRequest searchRequest = new SearchRequestImpl()
> .ignoreReferrals()
> .setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
> .setBase(new Dn(searchBase))
> .setFilter(filter)
> .setScope(SearchScope.SUBTREE)
> .addAttributes(attributes)
> .setTimeLimit(120)
> .addControl(pagedSearchControl);
> SearchCursorImpl searchCursor = (SearchCursorImpl)
> connection.search(searchRequest);
> try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
> while (cursor.next()) {
> Entry e = cursor.get();
> log.info("element: {}", e.get("sAMAccountName"));
> results.add(e);
> }
> SearchResultDone searchResult = cursor.getSearchResultDone();
> pagedSearchControl =
> (PagedResults)searchResult.getControl(PagedResults.OID);
> if (searchResult.getLdapResult().getResultCode() ==
> ResultCodeEnum.UNWILLING_TO_PERFORM) {
> throw new LdapException("Directory cannot handle
> pagination!");
> }
> } catch (CursorException e) {
> log.error("Unexpected cursor exception occurred!", e);
> }
> // Check if pagination is exhausted (all eligible entries have been
> read)
> if (Strings.isEmpty(pagedSearchControl.getCookie())) {
> log.info("Exiting paged search at page: " + ++page);
> break;
> }
> // Prepare the next iteration
> pagedSearchControl.setSize(pageSize);
> }
> // here we want to do s.th. with our 'results' reference;
> } catch (LdapException e) {
> log.error("Unexpected ldap exception occurred!", e);
> } catch (IOException e) {
> log.error("Unexpected I/O exception occurred!", e);
> } finally {
> if (connection != null) {
> ldapConnectionPool.releaseConnection(connection); // put the
> session/connection back to its pool
> }
> } {code}
>
> *Expected behaviour:*
> all elements in the base are picked up in the 'results' list, all paginated
> and added up by x times a bunch of 100 until everything has been read in the
> directory. In the searchFutur
[jira] [Comment Edited] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
[
https://issues.apache.org/jira/browse/DIRAPI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822743#comment-17822743
]
Emmanuel Lécharny edited comment on DIRAPI-399 at 3/2/24 3:01 AM:
--
Hi,
just to clarify, you are sending this request to an Active Directory server
that does not seems to respect the IgnoreReferals flag, thus returning some
referals, how is it a LDAP API issue?
I'm missing something?
was (Author: elecharny):
Hi,
just to clarify, you are sending this request to an Active Directory server
that does not seems to respect the IgnoreReferals flag, thus returning some
referals, how is it a LDAP API issue?
> Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s)
> picked up
> --
>
> Key: DIRAPI-399
> URL: https://issues.apache.org/jira/browse/DIRAPI-399
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Thomas Jodes
>Priority: Major
> Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
> 2024-03-01 15-48-52.png
>
>
> As a ldap-api user, I want to search my DIT paginated from a base where also
> referrals /
> [SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
> are.
> Following paged search code:
>
> {code:java}
> int pageSize = 100;
> LdapConnection connection = null;
> try {
> connection = ldapConnectionPool.getConnection();
> int page = 0; // the current page
> PagedResults pagedSearchControl = new PagedResultsImpl();
> pagedSearchControl.setSize(pageSize);
> // Loop using the paged search control extension
> while(true) {
> SearchRequest searchRequest = new SearchRequestImpl()
> .ignoreReferrals()
> .setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
> .setBase(new Dn(searchBase))
> .setFilter(filter)
> .setScope(SearchScope.SUBTREE)
> .addAttributes(attributes)
> .setTimeLimit(120)
> .addControl(pagedSearchControl);
> SearchCursorImpl searchCursor = (SearchCursorImpl)
> connection.search(searchRequest);
> try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
> while (cursor.next()) {
> Entry e = cursor.get();
> log.info("element: {}", e.get("sAMAccountName"));
> results.add(e);
> }
> SearchResultDone searchResult = cursor.getSearchResultDone();
> pagedSearchControl =
> (PagedResults)searchResult.getControl(PagedResults.OID);
> if (searchResult.getLdapResult().getResultCode() ==
> ResultCodeEnum.UNWILLING_TO_PERFORM) {
> throw new LdapException("Directory cannot handle
> pagination!");
> }
> } catch (CursorException e) {
> log.error("Unexpected cursor exception occurred!", e);
> }
> // Check if pagination is exhausted (all eligible entries have been
> read)
> if (Strings.isEmpty(pagedSearchControl.getCookie())) {
> log.info("Exiting paged search at page: " + ++page);
> break;
> }
> // Prepare the next iteration
> pagedSearchControl.setSize(pageSize);
> }
> // here we want to do s.th. with our 'results' reference;
> } catch (LdapException e) {
> log.error("Unexpected ldap exception occurred!", e);
> } catch (IOException e) {
> log.error("Unexpected I/O exception occurred!", e);
> } finally {
> if (connection != null) {
> ldapConnectionPool.releaseConnection(connection); // put the
> session/connection back to its pool
> }
> } {code}
>
> *Expected behaviour:*
> all elements in the base are picked up in the 'results' list, all paginated
> and added up by x times a bunch of 100 until everything has been read in the
> directory. In the searchFuture at LdapNetworkConnection.searchAsync should be
> 101 elements: 100 SearchResultEntryImpl's and one SearchResultDoneImpl.
>
> *Actual behaviour:*
> in the firs
[jira] [Commented] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
[
https://issues.apache.org/jira/browse/DIRAPI-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822743#comment-17822743
]
Emmanuel Lécharny commented on DIRAPI-399:
--
Hi,
just to clarify, you are sending this request to an Active Directory server
that does not seems to respect the IgnoreReferals flag, thus returning some
referals, how is it a LDAP API issue?
> Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s)
> picked up
> --
>
> Key: DIRAPI-399
> URL: https://issues.apache.org/jira/browse/DIRAPI-399
> Project: Directory Client API
> Issue Type: Bug
>Affects Versions: 2.1.6
>Reporter: Thomas Jodes
>Priority: Major
> Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
> 2024-03-01 15-48-52.png
>
>
> As a ldap-api user, I want to search my DIT paginated from a base where also
> referrals /
> [SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
> are.
> Following paged search code:
>
> {code:java}
> int pageSize = 100;
> LdapConnection connection = null;
> try {
> connection = ldapConnectionPool.getConnection();
> int page = 0; // the current page
> PagedResults pagedSearchControl = new PagedResultsImpl();
> pagedSearchControl.setSize(pageSize);
> // Loop using the paged search control extension
> while(true) {
> SearchRequest searchRequest = new SearchRequestImpl()
> .ignoreReferrals()
> .setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
> .setBase(new Dn(searchBase))
> .setFilter(filter)
> .setScope(SearchScope.SUBTREE)
> .addAttributes(attributes)
> .setTimeLimit(120)
> .addControl(pagedSearchControl);
> SearchCursorImpl searchCursor = (SearchCursorImpl)
> connection.search(searchRequest);
> try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
> while (cursor.next()) {
> Entry e = cursor.get();
> log.info("element: {}", e.get("sAMAccountName"));
> results.add(e);
> }
> SearchResultDone searchResult = cursor.getSearchResultDone();
> pagedSearchControl =
> (PagedResults)searchResult.getControl(PagedResults.OID);
> if (searchResult.getLdapResult().getResultCode() ==
> ResultCodeEnum.UNWILLING_TO_PERFORM) {
> throw new LdapException("Directory cannot handle
> pagination!");
> }
> } catch (CursorException e) {
> log.error("Unexpected cursor exception occurred!", e);
> }
> // Check if pagination is exhausted (all eligible entries have been
> read)
> if (Strings.isEmpty(pagedSearchControl.getCookie())) {
> log.info("Exiting paged search at page: " + ++page);
> break;
> }
> // Prepare the next iteration
> pagedSearchControl.setSize(pageSize);
> }
> // here we want to do s.th. with our 'results' reference;
> } catch (LdapException e) {
> log.error("Unexpected ldap exception occurred!", e);
> } catch (IOException e) {
> log.error("Unexpected I/O exception occurred!", e);
> } finally {
> if (connection != null) {
> ldapConnectionPool.releaseConnection(connection); // put the
> session/connection back to its pool
> }
> } {code}
>
> *Expected behaviour:*
> all elements in the base are picked up in the 'results' list, all paginated
> and added up by x times a bunch of 100 until everything has been read in the
> directory. In the searchFuture at LdapNetworkConnection.searchAsync should be
> 101 elements: 100 SearchResultEntryImpl's and one SearchResultDoneImpl.
>
> *Actual behaviour:*
> in the first page there are 100 entries, i.e. 100x SearchResultEntryImpl
> elements PLUS (in my case/active directory) 3x SearchResultReferenceImpl
> elements plus 1x SerachResultDoneImpl element as the last one in the array of
> the searchFuture here:[
> LdapNetworkConnection#searchAsync()|ht
[jira] [Created] (DIRAPI-399) Cannot paginate SearchCursor via SearchRequest when SearchResultReference(s) picked up
Thomas Jodes created DIRAPI-399:
---
Summary: Cannot paginate SearchCursor via SearchRequest when
SearchResultReference(s) picked up
Key: DIRAPI-399
URL: https://issues.apache.org/jira/browse/DIRAPI-399
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.1.6
Reporter: Thomas Jodes
Attachments: Screenshot from 2024-03-01 15-47-26.png, Screenshot from
2024-03-01 15-48-52.png
As a ldap-api user, I want to search my DIT paginated from a base where also
referrals /
[SearchResultReference|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/model/src/main/java/org/apache/directory/api/ldap/model/message/SearchResultReferenceImpl.java#L28]s
are.
Following paged search code:
{code:java}
int pageSize = 100;
LdapConnection connection = null;
try {
connection = ldapConnectionPool.getConnection();
int page = 0; // the current page
PagedResults pagedSearchControl = new PagedResultsImpl();
pagedSearchControl.setSize(pageSize);
// Loop using the paged search control extension
while(true) {
SearchRequest searchRequest = new SearchRequestImpl()
.ignoreReferrals()
.setDerefAliases(AliasDerefMode.NEVER_DEREF_ALIASES)
.setBase(new Dn(searchBase))
.setFilter(filter)
.setScope(SearchScope.SUBTREE)
.addAttributes(attributes)
.setTimeLimit(120)
.addControl(pagedSearchControl);
SearchCursorImpl searchCursor = (SearchCursorImpl)
connection.search(searchRequest);
try (EntryCursor cursor = new EntryCursorImpl(searchCursor)) {
while (cursor.next()) {
Entry e = cursor.get();
log.info("element: {}", e.get("sAMAccountName"));
results.add(e);
}
SearchResultDone searchResult = cursor.getSearchResultDone();
pagedSearchControl =
(PagedResults)searchResult.getControl(PagedResults.OID);
if (searchResult.getLdapResult().getResultCode() ==
ResultCodeEnum.UNWILLING_TO_PERFORM) {
throw new LdapException("Directory cannot handle pagination!");
}
} catch (CursorException e) {
log.error("Unexpected cursor exception occurred!", e);
}
// Check if pagination is exhausted (all eligible entries have been
read)
if (Strings.isEmpty(pagedSearchControl.getCookie())) {
log.info("Exiting paged search at page: " + ++page);
break;
}
// Prepare the next iteration
pagedSearchControl.setSize(pageSize);
}
// here we want to do s.th. with our 'results' reference;
} catch (LdapException e) {
log.error("Unexpected ldap exception occurred!", e);
} catch (IOException e) {
log.error("Unexpected I/O exception occurred!", e);
} finally {
if (connection != null) {
ldapConnectionPool.releaseConnection(connection); // put the
session/connection back to its pool
}
} {code}
*Expected behaviour:*
all elements in the base are picked up in the 'results' list, all paginated and
added up by x times a bunch of 100 until everything has been read in the
directory. In the searchFuture at LdapNetworkConnection.searchAsync should be
101 elements: 100 SearchResultEntryImpl's and one SearchResultDoneImpl.
*Actual behaviour:*
in the first page there are 100 entries, i.e. 100x SearchResultEntryImpl
elements PLUS (in my case/active directory) 3x SearchResultReferenceImpl
elements plus 1x SerachResultDoneImpl element as the last one in the array of
the searchFuture here:[
LdapNetworkConnection#searchAsync()|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/client/api/src/main/java/org/apache/directory/ldap/client/api/LdapNetworkConnection.java#L2391]
.
ldap-api code runs into exception at EntryCursorImpl.get() when the response
instanceof [SearchResultReference is
hit|https://github.com/apache/directory-ldap-api/blob/c4fcf46f72601c1729d6d5321e2cdc7126f94b14/ldap/client/api/src/main/java/org/apache/directory/ldap/client/api/EntryCursorImpl.java#L164]
-> LdapReferralException.
"ignoreReferrals()" has been set building the SearchRequestImpl
The three additional SearchResultReferenceImpl elements in the entries read
shouldn't be picked up.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1336) split GitHub workflow builds of pull requests
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits resolved DIRSTUDIO-1336. - Fix Version/s: 2.0.0-M18 Resolution: Implemented > split GitHub workflow builds of pull requests > - > > Key: DIRSTUDIO-1336 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1336 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > Splitting GitHub workflows for building Directory Studio. > Having build workflows for: > * openjdk 11 > * openjdk 17 > * openjdk 21 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1336) split GitHub workflow builds of pull requests
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1336. --- > split GitHub workflow builds of pull requests > - > > Key: DIRSTUDIO-1336 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1336 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > Splitting GitHub workflows for building Directory Studio. > Having build workflows for: > * openjdk 11 > * openjdk 17 > * openjdk 21 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1336) split GitHub workflow builds of pull requests
Pierre Smits created DIRSTUDIO-1336: --- Summary: split GitHub workflow builds of pull requests Key: DIRSTUDIO-1336 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1336 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits Splitting GitHub workflows for building Directory Studio. Having build workflows for: * openjdk 11 * openjdk 17 * openjdk 21 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1335) Bump tycho.version from 2.3.0 to 4.0.0
Pierre Smits created DIRSTUDIO-1335: --- Summary: Bump tycho.version from 2.3.0 to 4.0.0 Key: DIRSTUDIO-1335 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1335 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits Fix For: 2.0.0-M18 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1334) Bump org.codehaus.mojo:exec-maven-plugin from 3.1.1 to 3.2.0
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1334. --- > Bump org.codehaus.mojo:exec-maven-plugin from 3.1.1 to 3.2.0 > > > Key: DIRSTUDIO-1334 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1334 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1304) vulnerability for poi-3.9.jar
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1304. --- > vulnerability for poi-3.9.jar > - > > Key: DIRSTUDIO-1304 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1304 > Project: Directory Studio > Issue Type: Task >Affects Versions: 2.0.0-M17 >Reporter: Krystian Tokarz >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > Our vulnerability system (Nessus) discovers that poi-3.9.jar file is > vulnerable (medium risk). This file is created when Apache Directory Studio > is started on our Windows 2016 Server OS. > Folders: > C:\Documents and > Settings\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > and > C:\Users\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > > Plugin ID: 106717 > Plugin description: The version of Apache POI installed on the remote host is > a version prior to 3.17. It is, therefore, affected by multiple DoS > vulnerabilities. Note that Nessus has not tested for these issues but has > instead relied only on the application's self-reported version number. > Apache POI < 3.17 Multiple DoS Vulnerabilities > > Could you provide any information about this issue? Can we patch this somehow? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1304) vulnerability for poi-3.9.jar
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits resolved DIRSTUDIO-1304. - Resolution: Done > vulnerability for poi-3.9.jar > - > > Key: DIRSTUDIO-1304 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1304 > Project: Directory Studio > Issue Type: Task >Affects Versions: 2.0.0-M17 >Reporter: Krystian Tokarz >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > Our vulnerability system (Nessus) discovers that poi-3.9.jar file is > vulnerable (medium risk). This file is created when Apache Directory Studio > is started on our Windows 2016 Server OS. > Folders: > C:\Documents and > Settings\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > and > C:\Users\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > > Plugin ID: 106717 > Plugin description: The version of Apache POI installed on the remote host is > a version prior to 3.17. It is, therefore, affected by multiple DoS > vulnerabilities. Note that Nessus has not tested for these issues but has > instead relied only on the application's self-reported version number. > Apache POI < 3.17 Multiple DoS Vulnerabilities > > Could you provide any information about this issue? Can we patch this somehow? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1304) vulnerability for poi-3.9.jar
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820865#comment-17820865 ] Pierre Smits commented on DIRSTUDIO-1304: - [~elecharny] I will address this soon. > vulnerability for poi-3.9.jar > - > > Key: DIRSTUDIO-1304 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1304 > Project: Directory Studio > Issue Type: Task >Affects Versions: 2.0.0-M17 >Reporter: Krystian Tokarz >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > Our vulnerability system (Nessus) discovers that poi-3.9.jar file is > vulnerable (medium risk). This file is created when Apache Directory Studio > is started on our Windows 2016 Server OS. > Folders: > C:\Documents and > Settings\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > and > C:\Users\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > > Plugin ID: 106717 > Plugin description: The version of Apache POI installed on the remote host is > a version prior to 3.17. It is, therefore, affected by multiple DoS > vulnerabilities. Note that Nessus has not tested for these issues but has > instead relied only on the application's self-reported version number. > Apache POI < 3.17 Multiple DoS Vulnerabilities > > Could you provide any information about this issue? Can we patch this somehow? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1317) Improve CI processes
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820863#comment-17820863 ] Pierre Smits commented on DIRSTUDIO-1317: - Hi [~elecharny] OFBIZ-1331 is a sub-task of this ticket, should therefore stay open till done. IMO, sub-task 1 is about the GitHub actions, which should be light-weight and catered primarily to vetting Pull Requests. Sub-task 2m on the other hand, is about the more heavy-weight CI processes on CI-builds.a.o, running on the Jenkins variants. These should be about vetting the code base against various JDKs, packaging for the various platforms, etc. And it looks like that our CI process(es) on CI-builds.a.o. haven't run successfully for about 10 months now. So there is something definitely wrong in the params and/or code. > Improve CI processes > > > Key: DIRSTUDIO-1317 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1317 > Project: Directory Studio > Issue Type: Improvement > Components: studio-build >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > > While working DIRSTUDIO-1316 I noticed that > * tools/run-ui-tests.sh > could do with some improvements, like > * the use of the referenced container > * running an individual test > We should also look at aligning the Studio CI processes with other Directory > sub-projects: > * > h4. [directory-server|https://github.com/apache/directory-server] > * > h4. [directory-ldap-api|https://github.com/apache/directory-ldap-api] > * and potentially others -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1304) vulnerability for poi-3.9.jar
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820851#comment-17820851 ] Emmanuel Lécharny commented on DIRSTUDIO-1304: -- Pierre, if it works on your machine, could you commit the change? Thanks! > vulnerability for poi-3.9.jar > - > > Key: DIRSTUDIO-1304 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1304 > Project: Directory Studio > Issue Type: Task >Affects Versions: 2.0.0-M17 >Reporter: Krystian Tokarz >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > Our vulnerability system (Nessus) discovers that poi-3.9.jar file is > vulnerable (medium risk). This file is created when Apache Directory Studio > is started on our Windows 2016 Server OS. > Folders: > C:\Documents and > Settings\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > and > C:\Users\%username%\.eclipse\1407070357_win32_win32_x86_64\configuration\org.eclipse.osgi\65\0\.cp\lib\poi-3.9.jar > > Plugin ID: 106717 > Plugin description: The version of Apache POI installed on the remote host is > a version prior to 3.17. It is, therefore, affected by multiple DoS > vulnerabilities. Note that Nessus has not tested for these issues but has > instead relied only on the application's self-reported version number. > Apache POI < 3.17 Multiple DoS Vulnerabilities > > Could you provide any information about this issue? Can we patch this somehow? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1317) Improve CI processes
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820847#comment-17820847 ] Emmanuel Lécharny commented on DIRSTUDIO-1317: -- A question: is DIRSTUDIO-1331 relevant, or should we consider closing it, as this JIRA is quite deescriptive about what need to be done? > Improve CI processes > > > Key: DIRSTUDIO-1317 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1317 > Project: Directory Studio > Issue Type: Improvement > Components: studio-build >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > > While working DIRSTUDIO-1316 I noticed that > * tools/run-ui-tests.sh > could do with some improvements, like > * the use of the referenced container > * running an individual test > We should also look at aligning the Studio CI processes with other Directory > sub-projects: > * > h4. [directory-server|https://github.com/apache/directory-server] > * > h4. [directory-ldap-api|https://github.com/apache/directory-ldap-api] > * and potentially others -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1333) Typo correction oorg.apache
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Smits closed DIRSTUDIO-1333.
---
> Typo correction oorg.apache
> ---
>
> Key: DIRSTUDIO-1333
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1333
> Project: Directory Studio
> Issue Type: Improvement
> Components: studio-ldapbrowser
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> The valueEditor reference in valueEditors.exsd contains a typo in the class
> name:
> {code:java}
> oorg.apache.directory.studio.valueeditors.TextValueEditor {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1333) Typo correction oorg.apache
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Smits resolved DIRSTUDIO-1333.
-
Fix Version/s: 2.0.0-M18
Resolution: Implemented
> Typo correction oorg.apache
> ---
>
> Key: DIRSTUDIO-1333
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1333
> Project: Directory Studio
> Issue Type: Improvement
> Components: studio-ldapbrowser
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> The valueEditor reference in valueEditors.exsd contains a typo in the class
> name:
> {code:java}
> oorg.apache.directory.studio.valueeditors.TextValueEditor {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Assigned] (DIRSTUDIO-1333) Typo correction oorg.apache
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Smits reassigned DIRSTUDIO-1333:
---
Assignee: Pierre Smits
> Typo correction oorg.apache
> ---
>
> Key: DIRSTUDIO-1333
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1333
> Project: Directory Studio
> Issue Type: Improvement
> Components: studio-ldapbrowser
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
>
> The valueEditor reference in valueEditors.exsd contains a typo in the class
> name:
> {code:java}
> oorg.apache.directory.studio.valueeditors.TextValueEditor {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1333) Typo correction oorg.apache
Pierre Smits created DIRSTUDIO-1333:
---
Summary: Typo correction oorg.apache
Key: DIRSTUDIO-1333
URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1333
Project: Directory Studio
Issue Type: Improvement
Components: studio-ldapbrowser
Reporter: Pierre Smits
The valueEditor reference in valueEditors.exsd contains a typo in the class
name:
{code:java}
oorg.apache.directory.studio.valueeditors.TextValueEditor {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRAPI-398) Release Pooled LDAP Connections when closed
Brian Demers created DIRAPI-398: --- Summary: Release Pooled LDAP Connections when closed Key: DIRAPI-398 URL: https://issues.apache.org/jira/browse/DIRAPI-398 Project: Directory Client API Issue Type: Improvement Reporter: Brian Demers Connections returned from a connection pool should be "released" instead of closed. Ultimately the usage of a Pooled connection should be similar to a _regular_ connection. It can be used in a try-with-resource block, then auto closed. In the case of a pooled connection, that `close()` call should return the connection to the pool. Related mailing list thread: https://lists.apache.org/thread/jpsg6g3sfspsgfpgn30kx4orspksnzm7 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1309) Update to use a contemporary version of Eclipse
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818309#comment-17818309 ] Fredrik Roubert commented on DIRSTUDIO-1309: With PR #43 now merged, Directory Studio is now using Eclipse 4.24 which is the last version possible to use with Java 11. The project now needs to be updated to use Java 17 to make it possible to upgrade to a current version of Eclipse. > Update to use a contemporary version of Eclipse > --- > > Key: DIRSTUDIO-1309 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1309 > Project: Directory Studio > Issue Type: Dependency upgrade >Reporter: Fredrik Roubert >Priority: Minor > Fix For: 2.0.0-M18 > > > After [PR #36|https://github.com/apache/directory-studio/pull/36] was merged, > the platform currently used is Eclipse 4.22 (2021-12) which soon is going to > be 2 years old. > It would be good to update to use a contemporary version ahead of time, > before some important bugfix or feature makes it necessary (and stressful) to > do. > Directory Studio currently has JDK 11 as a stated prerequisite, so an update > to Eclipse 4.24 (2022-06) can be done immedately, without having to change > anything else: > https://wiki.eclipse.org/Eclipse/Installation > The already pending [PR > #43|https://github.com/apache/directory-studio/pull/43] will do that. > After that, the minimum JDK version will have to be updated to 17 before > updating the platform further. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1323) Dependabot: Bump tycho.version from 2.3.0 to 4.0.5
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated DIRSTUDIO-1323: Summary: Dependabot: Bump tycho.version from 2.3.0 to 4.0.5 (was: Dependably: Bump tycho.version from 2.3.0 to 4.0.5) > Dependabot: Bump tycho.version from 2.3.0 to 4.0.5 > -- > > Key: DIRSTUDIO-1323 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1323 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > > see: [https://github.com/apache/directory-studio/pull/58] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Assigned] (DIRSTUDIO-1323) Dependably: Bump tycho.version from 2.3.0 to 4.0.5
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reassigned DIRSTUDIO-1323: --- Assignee: Pierre Smits > Dependably: Bump tycho.version from 2.3.0 to 4.0.5 > -- > > Key: DIRSTUDIO-1323 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1323 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > > see: [https://github.com/apache/directory-studio/pull/58] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1329) Bump org.apache.xmlgraphics:xmlgraphics-commons from 2.6 to 2.9
Pierre Smits created DIRSTUDIO-1329: --- Summary: Bump org.apache.xmlgraphics:xmlgraphics-commons from 2.6 to 2.9 Key: DIRSTUDIO-1329 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1329 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1293) Fails to start on MacOS Monterey
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817740#comment-17817740
]
Fredrik Roubert commented on DIRSTUDIO-1293:
Yes, this is still an issue. You downloaded and installed the x86_64 build. As
of PR #36 there's also an aarch64 build, required for anyone who can't or won't
set up an environment in which it's possible to run x86_64 on their aarch64
system, which eventually will need to be included in the release
(DIRSTUDIO-1319).
> Fails to start on MacOS Monterey
>
>
> Key: DIRSTUDIO-1293
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1293
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: Model Name:MacBook Pro
> Model Identifier: MacBookPro18,2
> Chip: Apple M1 Max
> Total Number of Cores: 10 (8 performance and 2 efficiency)
> Memory: 32 GB
> System Firmware Version:7429.41.5
> OS Loader Version: 7429.41.5
>Reporter: Philip Peake
>Priority: Major
> Fix For: 2.0.0-M18
>
> Attachments: alert.png
>
>
> Launching Directory Studio fails with an error (see attached image),
> basically saying that the JNI_CreateJavaVM symbol is not found in
> libjvm.dylib.
> The symbol is actually there:
>
> {code:java}
> bin philip$ nm ../lib/server/libjvm.dylib | grep -i jni_create
> 004e3190 T _JNI_CreateJavaVM
> {code}
>
> Tried two different java versions:
> * zulu-11.jdk
> * zulu-17.jdk
> Tried adding the path to the java version explicitly in the Info.plist file:
>
> {code:java}
>
>
>
>
> -vm/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/bin/java
> -keyring
> ~/.eclipse_keyring
>
>
> {code}
>
> This appears to be a problem in Eclipse/Directory Studio.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1319) Have an installer for Apple Mac on Apple Silicon
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817741#comment-17817741 ] Fredrik Roubert commented on DIRSTUDIO-1319: See this comment for some information about what still needs to be done: https://issues.apache.org/jira/browse/DIRSTUDIO-1293?focusedCommentId=17743451=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17743451 > Have an installer for Apple Mac on Apple Silicon > > > Key: DIRSTUDIO-1319 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1319 > Project: Directory Studio > Issue Type: Improvement > Components: studio-installer >Reporter: Pierre Smits >Priority: Major > > Have an installer for running Directory Studio on Apple Mac machines having > Apple Silicon -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1326) Dependabot: Bump org.apache.directory.project:project from 45 to 48
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1326. --- > Dependabot: Bump org.apache.directory.project:project from 45 to 48 > --- > > Key: DIRSTUDIO-1326 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1326 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > [https://github.com/apache/directory-studio/pull/59] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1326) Dependabot: Bump org.apache.directory.project:project from 45 to 48
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits resolved DIRSTUDIO-1326. - Fix Version/s: 2.0.0-M18 Assignee: Pierre Smits Resolution: Implemented > Dependabot: Bump org.apache.directory.project:project from 45 to 48 > --- > > Key: DIRSTUDIO-1326 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1326 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > [https://github.com/apache/directory-studio/pull/59] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1326) Dependabot: Bump org.apache.directory.project:project from 45 to 48
Pierre Smits created DIRSTUDIO-1326: --- Summary: Dependabot: Bump org.apache.directory.project:project from 45 to 48 Key: DIRSTUDIO-1326 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1326 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits [https://github.com/apache/directory-studio/pull/59] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Assigned] (DIRSTUDIO-1325) Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reassigned DIRSTUDIO-1325: --- Assignee: Pierre Smits > Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2 > --- > > Key: DIRSTUDIO-1325 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1325 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > > see [https://github.com/apache/directory-studio/pull/57] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1325) Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1325. --- > Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2 > --- > > Key: DIRSTUDIO-1325 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1325 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > see [https://github.com/apache/directory-studio/pull/57] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1325) Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits resolved DIRSTUDIO-1325. - Fix Version/s: 2.0.0-M18 Resolution: Implemented > Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2 > --- > > Key: DIRSTUDIO-1325 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1325 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > see [https://github.com/apache/directory-studio/pull/57] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1325) Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2
Pierre Smits created DIRSTUDIO-1325: --- Summary: Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2 Key: DIRSTUDIO-1325 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1325 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1325) Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated DIRSTUDIO-1325: Description: see [https://github.com/apache/directory-studio/pull/57] > Dependably: Bump junit.jupiter.version from 5.7.1 to 5.10.2 > --- > > Key: DIRSTUDIO-1325 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1325 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Priority: Major > > see [https://github.com/apache/directory-studio/pull/57] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1324) Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1324. --- > Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14 > --- > > Key: DIRSTUDIO-1324 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1324 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > See: [https://github.com/apache/directory-studio/pull/56] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Assigned] (DIRSTUDIO-1324) Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reassigned DIRSTUDIO-1324: --- Assignee: Pierre Smits > Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14 > --- > > Key: DIRSTUDIO-1324 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1324 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > > See: [https://github.com/apache/directory-studio/pull/56] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1324) Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits resolved DIRSTUDIO-1324. - Fix Version/s: 2.0.0-M18 Resolution: Implemented > Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14 > --- > > Key: DIRSTUDIO-1324 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1324 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > See: [https://github.com/apache/directory-studio/pull/56] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1324) Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14
Pierre Smits created DIRSTUDIO-1324: --- Summary: Dependabot: Bump org.apache.ant:ant-apache-regexp from 1.7.1 to 1.10.14 Key: DIRSTUDIO-1324 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1324 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits See: [https://github.com/apache/directory-studio/pull/56] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1323) Dependably: Bump tycho.version from 2.3.0 to 4.0.5
Pierre Smits created DIRSTUDIO-1323: --- Summary: Dependably: Bump tycho.version from 2.3.0 to 4.0.5 Key: DIRSTUDIO-1323 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1323 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits see: [https://github.com/apache/directory-studio/pull/58] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1322) Dependabot: Bump org.codehaus.mojo:exec-maven-plugin from 1.5.0 to 3.1.1
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1322. --- > Dependabot: Bump org.codehaus.mojo:exec-maven-plugin from 1.5.0 to 3.1.1 > > > Key: DIRSTUDIO-1322 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1322 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > see [https://github.com/apache/directory-studio/pull/55] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1322) Dependabot: Bump org.codehaus.mojo:exec-maven-plugin from 1.5.0 to 3.1.1
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits resolved DIRSTUDIO-1322. - Fix Version/s: 2.0.0-M18 Resolution: Implemented > Dependabot: Bump org.codehaus.mojo:exec-maven-plugin from 1.5.0 to 3.1.1 > > > Key: DIRSTUDIO-1322 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1322 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > see [https://github.com/apache/directory-studio/pull/55] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Created] (DIRSTUDIO-1322) Dependabot: Bump org.codehaus.mojo:exec-maven-plugin from 1.5.0 to 3.1.1
Pierre Smits created DIRSTUDIO-1322: --- Summary: Dependabot: Bump org.codehaus.mojo:exec-maven-plugin from 1.5.0 to 3.1.1 Key: DIRSTUDIO-1322 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1322 Project: Directory Studio Issue Type: Improvement Reporter: Pierre Smits Assignee: Pierre Smits see [https://github.com/apache/directory-studio/pull/55] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Updated] (DIRSTUDIO-1321) Dependably: Bump github/codeql-action from 2 to 3
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated DIRSTUDIO-1321: Description: see [https://github.com/apache/directory-studio/pull/54] > Dependably: Bump github/codeql-action from 2 to 3 > - > > Key: DIRSTUDIO-1321 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1321 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Priority: Major > > see [https://github.com/apache/directory-studio/pull/54] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Closed] (DIRSTUDIO-1320) Dependabot issue: Bump actions/checkout from 2 to 4
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits closed DIRSTUDIO-1320. --- > Dependabot issue: Bump actions/checkout from 2 to 4 > --- > > Key: DIRSTUDIO-1320 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1320 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > See [https://github.com/apache/directory-studio/pull/53] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Resolved] (DIRSTUDIO-1320) Dependabot issue: Bump actions/checkout from 2 to 4
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits resolved DIRSTUDIO-1320. - Resolution: Implemented > Dependabot issue: Bump actions/checkout from 2 to 4 > --- > > Key: DIRSTUDIO-1320 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1320 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > See [https://github.com/apache/directory-studio/pull/53] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Reopened] (DIRSTUDIO-1320) Dependabot issue: Bump actions/checkout from 2 to 4
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits reopened DIRSTUDIO-1320: - set correct resolution > Dependabot issue: Bump actions/checkout from 2 to 4 > --- > > Key: DIRSTUDIO-1320 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1320 > Project: Directory Studio > Issue Type: Improvement >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.0.0-M18 > > > See [https://github.com/apache/directory-studio/pull/53] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
