[jira] [Commented] (MRM-2021) Rest API + searchService/artifact + No Content
[ https://issues.apache.org/jira/browse/MRM-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462108#comment-17462108 ] Martin Stockhammer commented on MRM-2021: - Hi, if I see it correctly, you are trying to search for the substring LATEST ? This API method is a bit different to the other search methods: * It returns a redirect to a Artifact Download URL, not a JSON response * It will succeed, if exactly one artifact was found. If there are multiple results for the search, it will return a error response, but there is one exception: * v=LATEST is treated special, this returns the latest element in the list, if more than one was found I added an additonal (optional) parameter: literalVersion, Default value is 'false' If you set literalVersion=true, LATEST is not treated as special keyword, but used as search term. This change is targeted for version 2.2.7 > Rest API + searchService/artifact + No Content > -- > > Key: MRM-2021 > URL: https://issues.apache.org/jira/browse/MRM-2021 > Project: Archiva > Issue Type: Bug > Components: rest services >Affects Versions: 2.2.5 > Environment: Ubuntu 20.04 / StandAlone / NGINX / HTTPS >Reporter: Macgayver Armini >Assignee: Martin Stockhammer >Priority: Minor > Fix For: 2.2.7 > > Attachments: Anex.png, Anex2.png > > > Dear, first of all, I am using a translator, so I apologize for any mistakes > made. > > I'm having trouble returning the latest version with the REST api, my RAW > HTTP is as follows: > > GET > /restServices/archivaServices/searchService/artifact?g=blah=blah=LATEST > HTTP/1.1 > > Host: archiva.blah.com > > User-Agent: insomnia / 7.1.1 > > Cookie: JSESSIONID = blahblah > > Accept: * / * > > > In fact, other calls are working well, including > "restServices / archivaServices / browseService / versionsList / blah / blah" > Returning in order (I take the opportunity to ask if it is in order that > this command works). > > Regarding our use, we are not going to use it for Java, but to upload binary > releases in the format "EXE", and we added in "Repository Scanning" in the > artifacts section the option "** / *. Exe" everything is working very well. > Our "maven-metada.xml" file is correct, and identifying which version is > "" correctly, in addition to the history being also correct. > > So I will answer some questions that you asked in 2018 on the same topic. > > Is anonymous access allowed to your repository? > No, but I'm testing it as an administrator. (using cookies > /restServices/redbackServices/loginService/logIn) > > > How many repositories do you have? Is it the same, if you set the repository > ID with the 'r'-Parameter? > > id = manager > directory = / var / opt / archiva-data / repositories / updates > releases = true > snapshots = true (I tried false and the same thing happens) > Skip Packed Index Creation = false > > > Can you find the artifact on the web UI with the given entries? > Yes, it works perfectly and in order in the listing. > > > Is there any info in the log file? If not, could you please change it to > debug level, and send it to me? > > I don't know how to put it into debug mode, but logs are generated, but if I > delete them all, and ask for the artifacts command for rest, it doesn't > generate a log. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRM-2021) Rest API + searchService/artifact + No Content
[ https://issues.apache.org/jira/browse/MRM-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2021. - Resolution: Fixed Implemented workaround for LATEST version search. See comment before. > Rest API + searchService/artifact + No Content > -- > > Key: MRM-2021 > URL: https://issues.apache.org/jira/browse/MRM-2021 > Project: Archiva > Issue Type: Bug > Components: rest services >Affects Versions: 2.2.5 > Environment: Ubuntu 20.04 / StandAlone / NGINX / HTTPS >Reporter: Macgayver Armini >Assignee: Martin Stockhammer >Priority: Minor > Fix For: 2.2.7 > > Attachments: Anex.png, Anex2.png > > > Dear, first of all, I am using a translator, so I apologize for any mistakes > made. > > I'm having trouble returning the latest version with the REST api, my RAW > HTTP is as follows: > > GET > /restServices/archivaServices/searchService/artifact?g=blah=blah=LATEST > HTTP/1.1 > > Host: archiva.blah.com > > User-Agent: insomnia / 7.1.1 > > Cookie: JSESSIONID = blahblah > > Accept: * / * > > > In fact, other calls are working well, including > "restServices / archivaServices / browseService / versionsList / blah / blah" > Returning in order (I take the opportunity to ask if it is in order that > this command works). > > Regarding our use, we are not going to use it for Java, but to upload binary > releases in the format "EXE", and we added in "Repository Scanning" in the > artifacts section the option "** / *. Exe" everything is working very well. > Our "maven-metada.xml" file is correct, and identifying which version is > "" correctly, in addition to the history being also correct. > > So I will answer some questions that you asked in 2018 on the same topic. > > Is anonymous access allowed to your repository? > No, but I'm testing it as an administrator. (using cookies > /restServices/redbackServices/loginService/logIn) > > > How many repositories do you have? Is it the same, if you set the repository > ID with the 'r'-Parameter? > > id = manager > directory = / var / opt / archiva-data / repositories / updates > releases = true > snapshots = true (I tried false and the same thing happens) > Skip Packed Index Creation = false > > > Can you find the artifact on the web UI with the given entries? > Yes, it works perfectly and in order in the listing. > > > Is there any info in the log file? If not, could you please change it to > debug level, and send it to me? > > I don't know how to put it into debug mode, but logs are generated, but if I > delete them all, and ask for the artifacts command for rest, it doesn't > generate a log. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MRM-2027) Update log4j2 to 2.17.0
[ https://issues.apache.org/jira/browse/MRM-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2027: --- Assignee: Martin Stockhammer > Update log4j2 to 2.17.0 > --- > > Key: MRM-2027 > URL: https://issues.apache.org/jira/browse/MRM-2027 > Project: Archiva > Issue Type: Improvement >Affects Versions: 2.2.6 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 2.2.7 > > > There is another vulnerability for log4j2 > [CVE-2021-45105|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105] > It is considered as low risk for archiva, should work only when users change > the log configuration. But we add this update for the next release. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MRM-2027) Update log4j2 to 2.17.0
Martin Stockhammer created MRM-2027: --- Summary: Update log4j2 to 2.17.0 Key: MRM-2027 URL: https://issues.apache.org/jira/browse/MRM-2027 Project: Archiva Issue Type: Improvement Affects Versions: 2.2.6 Reporter: Martin Stockhammer Fix For: 2.2.7 There is another vulnerability for log4j2 [CVE-2021-45105|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105] It is considered as low risk for archiva, should work only when users change the log configuration. But we add this update for the next release. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRM-2027) Update log4j2 to 2.17.0
[ https://issues.apache.org/jira/browse/MRM-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2027. - Resolution: Fixed Added to pom.xml > Update log4j2 to 2.17.0 > --- > > Key: MRM-2027 > URL: https://issues.apache.org/jira/browse/MRM-2027 > Project: Archiva > Issue Type: Improvement >Affects Versions: 2.2.6 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 2.2.7 > > > There is another vulnerability for log4j2 > [CVE-2021-45105|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105] > It is considered as low risk for archiva, should work only when users change > the log configuration. But we add this update for the next release. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRM-2020) 'archiva' shell script for linux generated by appassembler plugin does not honor the ARCHIVA_BASE environment variable
[
https://issues.apache.org/jira/browse/MRM-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer resolved MRM-2020.
-
Resolution: Fixed
Is fixed now. Targeted for 2.2.7
> 'archiva' shell script for linux generated by appassembler plugin does not
> honor the ARCHIVA_BASE environment variable
> --
>
> Key: MRM-2020
> URL: https://issues.apache.org/jira/browse/MRM-2020
> Project: Archiva
> Issue Type: Bug
> Components: Build, Documentation
>Affects Versions: 2.2.5
>Reporter: Bernd Kauling
>Assignee: Martin Stockhammer
>Priority: Trivial
> Fix For: 2.2.7
>
>
> I followed the installation guide for the standalone installation:
> [https://archiva.apache.org/docs/2.2.5/adminguide/standalone.html]
> I also decided to separate the base from the installation and followed the
> steps mentioned accordingly. I've split my installation into /opt/archiva and
> /var/archiva.
> Step 4 indicates, that the ARCHIVA_BASE environment variable has to be set to
> the new location of archiva, which i have done.
> As i tried to start archiva with
> {code:java}
> $ ./archiva start
> {code}
> i received the following error message:
> {noformat}
> Starting Apache Archiva...
> FATAL | wrapper | Unable to resolve the full path of the configuration
> file, /opt/archiva/conf/wrapper.conf: No such file or directory{noformat}
> After some digging around in the shell script, i noticed this part starting
> on line 44.
> {code:java}
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
>BASEDIR=`dirname "$_REALFILE"`/..
>BASEDIR=`(cd "$BASEDIR"; pwd)`
>cd "$_PWD"
> fi
> {code}
> which determines the BASEDIR environment variable which is used to point to
> the 'wrapper.conf' configuration file which i expected to be now in
> /var/archiva/conf/wrapper.conf.
> After changing the script to the following:
> {code:java}
> if [ -z "$ARCHIVA_BASE" ]; then
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
> BASEDIR=`dirname "$_REALFILE"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> cd "$_PWD"
> fi
> else
> BASEDIR=$ARCHIVA_BASE
> fi
> {code}
> Archiva starts up correctly.
> Step 2 of the installation guide instructs the reader to copy the files
> instead of moving them, because the "move will fail". I can only imagine what
> that means, but after what i've learned now it may indicate that the "failing
> part" may not be the move operation itself, but the successful start of
> archiva, if the 'wrapper.conf' is moved too.
> What i did was to copy the files, delete the old configuration files and to
> create a readme to remind myself where the config files are now. Including
> the 'wrapper.conf'.
> That leaves me with two options:
> Either this is a "bug" in the documentation or a bug in the generated shell
> script.
> h3. Proposal:
>
> So either
> 1) The documentation needs to be adjusted to state in step 2 that the
> wrapper.conf should stay in the base directory if that is what step 2 of the
> documentation really means.
> or
> 2) The generated shell script should include the above mentioned check.
>
> If option 1 is the correct one, i'd volunteer to provide a better
> documentation for that section.
> If option 2 is the correct one, i am afraid that i don't know how to fix
> that. I've poked around the source code and i've read the appassembler
> documentation, but i am not sure if that is even possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRM-2020) 'archiva' shell script for linux generated by appassembler plugin does not honor the ARCHIVA_BASE environment variable
[
https://issues.apache.org/jira/browse/MRM-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461660#comment-17461660
]
Martin Stockhammer commented on MRM-2020:
-
You are right. Thank you for the detailed explanation. I will try to add the
changes.
> 'archiva' shell script for linux generated by appassembler plugin does not
> honor the ARCHIVA_BASE environment variable
> --
>
> Key: MRM-2020
> URL: https://issues.apache.org/jira/browse/MRM-2020
> Project: Archiva
> Issue Type: Bug
> Components: Build, Documentation
>Affects Versions: 2.2.5
>Reporter: Bernd Kauling
>Assignee: Martin Stockhammer
>Priority: Trivial
> Fix For: 2.2.7
>
>
> I followed the installation guide for the standalone installation:
> [https://archiva.apache.org/docs/2.2.5/adminguide/standalone.html]
> I also decided to separate the base from the installation and followed the
> steps mentioned accordingly. I've split my installation into /opt/archiva and
> /var/archiva.
> Step 4 indicates, that the ARCHIVA_BASE environment variable has to be set to
> the new location of archiva, which i have done.
> As i tried to start archiva with
> {code:java}
> $ ./archiva start
> {code}
> i received the following error message:
> {noformat}
> Starting Apache Archiva...
> FATAL | wrapper | Unable to resolve the full path of the configuration
> file, /opt/archiva/conf/wrapper.conf: No such file or directory{noformat}
> After some digging around in the shell script, i noticed this part starting
> on line 44.
> {code:java}
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
>BASEDIR=`dirname "$_REALFILE"`/..
>BASEDIR=`(cd "$BASEDIR"; pwd)`
>cd "$_PWD"
> fi
> {code}
> which determines the BASEDIR environment variable which is used to point to
> the 'wrapper.conf' configuration file which i expected to be now in
> /var/archiva/conf/wrapper.conf.
> After changing the script to the following:
> {code:java}
> if [ -z "$ARCHIVA_BASE" ]; then
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
> BASEDIR=`dirname "$_REALFILE"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> cd "$_PWD"
> fi
> else
> BASEDIR=$ARCHIVA_BASE
> fi
> {code}
> Archiva starts up correctly.
> Step 2 of the installation guide instructs the reader to copy the files
> instead of moving them, because the "move will fail". I can only imagine what
> that means, but after what i've learned now it may indicate that the "failing
> part" may not be the move operation itself, but the successful start of
> archiva, if the 'wrapper.conf' is moved too.
> What i did was to copy the files, delete the old configuration files and to
> create a readme to remind myself where the config files are now. Including
> the 'wrapper.conf'.
> That leaves me with two options:
> Either this is a "bug" in the documentation or a bug in the generated shell
> script.
> h3. Proposal:
>
> So either
> 1) The documentation needs to be adjusted to state in step 2 that the
> wrapper.conf should stay in the base directory if that is what step 2 of the
> documentation really means.
> or
> 2) The generated shell script should include the above mentioned check.
>
> If option 1 is the correct one, i'd volunteer to provide a better
> documentation for that section.
> If option 2 is the correct one, i am afraid that i don't know how to fix
> that. I've poked around the source code and i've read the appassembler
> documentation, but i am not sure if that is even possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (MRM-2022) beforeSend overwrite prevents repository scan trigger
[ https://issues.apache.org/jira/browse/MRM-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2022. - Resolution: Fixed Added the change. > beforeSend overwrite prevents repository scan trigger > - > > Key: MRM-2022 > URL: https://issues.apache.org/jira/browse/MRM-2022 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.5 >Reporter: Cristian Onet >Assignee: Martin Stockhammer >Priority: Trivial > Fix For: 2.2.7 > > Attachments: archiva.patch > > > This is caused by the fact that X-XSRF-TOKEN is set by a handler setup using > ajaxSetup that is overwritten by beforeSend I worked around it using the > attached [^archiva.patch] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRM-2021) Rest API + searchService/artifact + No Content
[ https://issues.apache.org/jira/browse/MRM-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-2021: Fix Version/s: 2.2.7 > Rest API + searchService/artifact + No Content > -- > > Key: MRM-2021 > URL: https://issues.apache.org/jira/browse/MRM-2021 > Project: Archiva > Issue Type: Bug > Components: rest services >Affects Versions: 2.2.5 > Environment: Ubuntu 20.04 / StandAlone / NGINX / HTTPS >Reporter: Macgayver Armini >Assignee: Martin Stockhammer >Priority: Minor > Fix For: 2.2.7 > > Attachments: Anex.png, Anex2.png > > > Dear, first of all, I am using a translator, so I apologize for any mistakes > made. > > I'm having trouble returning the latest version with the REST api, my RAW > HTTP is as follows: > > GET > /restServices/archivaServices/searchService/artifact?g=blah=blah=LATEST > HTTP/1.1 > > Host: archiva.blah.com > > User-Agent: insomnia / 7.1.1 > > Cookie: JSESSIONID = blahblah > > Accept: * / * > > > In fact, other calls are working well, including > "restServices / archivaServices / browseService / versionsList / blah / blah" > Returning in order (I take the opportunity to ask if it is in order that > this command works). > > Regarding our use, we are not going to use it for Java, but to upload binary > releases in the format "EXE", and we added in "Repository Scanning" in the > artifacts section the option "** / *. Exe" everything is working very well. > Our "maven-metada.xml" file is correct, and identifying which version is > "" correctly, in addition to the history being also correct. > > So I will answer some questions that you asked in 2018 on the same topic. > > Is anonymous access allowed to your repository? > No, but I'm testing it as an administrator. (using cookies > /restServices/redbackServices/loginService/logIn) > > > How many repositories do you have? Is it the same, if you set the repository > ID with the 'r'-Parameter? > > id = manager > directory = / var / opt / archiva-data / repositories / updates > releases = true > snapshots = true (I tried false and the same thing happens) > Skip Packed Index Creation = false > > > Can you find the artifact on the web UI with the given entries? > Yes, it works perfectly and in order in the listing. > > > Is there any info in the log file? If not, could you please change it to > debug level, and send it to me? > > I don't know how to put it into debug mode, but logs are generated, but if I > delete them all, and ask for the artifacts command for rest, it doesn't > generate a log. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MRM-2021) Rest API + searchService/artifact + No Content
[ https://issues.apache.org/jira/browse/MRM-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2021: --- Assignee: Martin Stockhammer > Rest API + searchService/artifact + No Content > -- > > Key: MRM-2021 > URL: https://issues.apache.org/jira/browse/MRM-2021 > Project: Archiva > Issue Type: Bug > Components: rest services >Affects Versions: 2.2.5 > Environment: Ubuntu 20.04 / StandAlone / NGINX / HTTPS >Reporter: Macgayver Armini >Assignee: Martin Stockhammer >Priority: Minor > Attachments: Anex.png, Anex2.png > > > Dear, first of all, I am using a translator, so I apologize for any mistakes > made. > > I'm having trouble returning the latest version with the REST api, my RAW > HTTP is as follows: > > GET > /restServices/archivaServices/searchService/artifact?g=blah=blah=LATEST > HTTP/1.1 > > Host: archiva.blah.com > > User-Agent: insomnia / 7.1.1 > > Cookie: JSESSIONID = blahblah > > Accept: * / * > > > In fact, other calls are working well, including > "restServices / archivaServices / browseService / versionsList / blah / blah" > Returning in order (I take the opportunity to ask if it is in order that > this command works). > > Regarding our use, we are not going to use it for Java, but to upload binary > releases in the format "EXE", and we added in "Repository Scanning" in the > artifacts section the option "** / *. Exe" everything is working very well. > Our "maven-metada.xml" file is correct, and identifying which version is > "" correctly, in addition to the history being also correct. > > So I will answer some questions that you asked in 2018 on the same topic. > > Is anonymous access allowed to your repository? > No, but I'm testing it as an administrator. (using cookies > /restServices/redbackServices/loginService/logIn) > > > How many repositories do you have? Is it the same, if you set the repository > ID with the 'r'-Parameter? > > id = manager > directory = / var / opt / archiva-data / repositories / updates > releases = true > snapshots = true (I tried false and the same thing happens) > Skip Packed Index Creation = false > > > Can you find the artifact on the web UI with the given entries? > Yes, it works perfectly and in order in the listing. > > > Is there any info in the log file? If not, could you please change it to > debug level, and send it to me? > > I don't know how to put it into debug mode, but logs are generated, but if I > delete them all, and ask for the artifacts command for rest, it doesn't > generate a log. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRM-2020) 'archiva' shell script for linux generated by appassembler plugin does not honor the ARCHIVA_BASE environment variable
[
https://issues.apache.org/jira/browse/MRM-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer updated MRM-2020:
Fix Version/s: 2.2.7
> 'archiva' shell script for linux generated by appassembler plugin does not
> honor the ARCHIVA_BASE environment variable
> --
>
> Key: MRM-2020
> URL: https://issues.apache.org/jira/browse/MRM-2020
> Project: Archiva
> Issue Type: Bug
> Components: Build, Documentation
>Affects Versions: 2.2.5
>Reporter: Bernd Kauling
>Assignee: Martin Stockhammer
>Priority: Trivial
> Fix For: 2.2.7
>
>
> I followed the installation guide for the standalone installation:
> [https://archiva.apache.org/docs/2.2.5/adminguide/standalone.html]
> I also decided to separate the base from the installation and followed the
> steps mentioned accordingly. I've split my installation into /opt/archiva and
> /var/archiva.
> Step 4 indicates, that the ARCHIVA_BASE environment variable has to be set to
> the new location of archiva, which i have done.
> As i tried to start archiva with
> {code:java}
> $ ./archiva start
> {code}
> i received the following error message:
> {noformat}
> Starting Apache Archiva...
> FATAL | wrapper | Unable to resolve the full path of the configuration
> file, /opt/archiva/conf/wrapper.conf: No such file or directory{noformat}
> After some digging around in the shell script, i noticed this part starting
> on line 44.
> {code:java}
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
>BASEDIR=`dirname "$_REALFILE"`/..
>BASEDIR=`(cd "$BASEDIR"; pwd)`
>cd "$_PWD"
> fi
> {code}
> which determines the BASEDIR environment variable which is used to point to
> the 'wrapper.conf' configuration file which i expected to be now in
> /var/archiva/conf/wrapper.conf.
> After changing the script to the following:
> {code:java}
> if [ -z "$ARCHIVA_BASE" ]; then
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
> BASEDIR=`dirname "$_REALFILE"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> cd "$_PWD"
> fi
> else
> BASEDIR=$ARCHIVA_BASE
> fi
> {code}
> Archiva starts up correctly.
> Step 2 of the installation guide instructs the reader to copy the files
> instead of moving them, because the "move will fail". I can only imagine what
> that means, but after what i've learned now it may indicate that the "failing
> part" may not be the move operation itself, but the successful start of
> archiva, if the 'wrapper.conf' is moved too.
> What i did was to copy the files, delete the old configuration files and to
> create a readme to remind myself where the config files are now. Including
> the 'wrapper.conf'.
> That leaves me with two options:
> Either this is a "bug" in the documentation or a bug in the generated shell
> script.
> h3. Proposal:
>
> So either
> 1) The documentation needs to be adjusted to state in step 2 that the
> wrapper.conf should stay in the base directory if that is what step 2 of the
> documentation really means.
> or
> 2) The generated shell script should include the above mentioned check.
>
> If option 1 is the correct one, i'd volunteer to provide a better
> documentation for that section.
> If option 2 is the correct one, i am afraid that i don't know how to fix
> that. I've poked around the source code and i've read the appassembler
> documentation, but i am not sure if that is even possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MRM-2020) 'archiva' shell script for linux generated by appassembler plugin does not honor the ARCHIVA_BASE environment variable
[
https://issues.apache.org/jira/browse/MRM-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer reassigned MRM-2020:
---
Assignee: Martin Stockhammer
> 'archiva' shell script for linux generated by appassembler plugin does not
> honor the ARCHIVA_BASE environment variable
> --
>
> Key: MRM-2020
> URL: https://issues.apache.org/jira/browse/MRM-2020
> Project: Archiva
> Issue Type: Bug
> Components: Build, Documentation
>Affects Versions: 2.2.5
>Reporter: Bernd Kauling
>Assignee: Martin Stockhammer
>Priority: Trivial
>
> I followed the installation guide for the standalone installation:
> [https://archiva.apache.org/docs/2.2.5/adminguide/standalone.html]
> I also decided to separate the base from the installation and followed the
> steps mentioned accordingly. I've split my installation into /opt/archiva and
> /var/archiva.
> Step 4 indicates, that the ARCHIVA_BASE environment variable has to be set to
> the new location of archiva, which i have done.
> As i tried to start archiva with
> {code:java}
> $ ./archiva start
> {code}
> i received the following error message:
> {noformat}
> Starting Apache Archiva...
> FATAL | wrapper | Unable to resolve the full path of the configuration
> file, /opt/archiva/conf/wrapper.conf: No such file or directory{noformat}
> After some digging around in the shell script, i noticed this part starting
> on line 44.
> {code:java}
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
>BASEDIR=`dirname "$_REALFILE"`/..
>BASEDIR=`(cd "$BASEDIR"; pwd)`
>cd "$_PWD"
> fi
> {code}
> which determines the BASEDIR environment variable which is used to point to
> the 'wrapper.conf' configuration file which i expected to be now in
> /var/archiva/conf/wrapper.conf.
> After changing the script to the following:
> {code:java}
> if [ -z "$ARCHIVA_BASE" ]; then
> BASEDIR=`dirname "$0"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> ls -l "$0" | grep -e '->' > /dev/null 2>&1
> if [ $? = 0 ]; then
> #this is softlink
> _PWD=`pwd`
> _EXEDIR=`dirname "$0"`
> cd "$_EXEDIR"
> _BASENAME=`basename "$0"`
> _REALFILE=`ls -l "$_BASENAME" | sed 's/.*->\ //g'`
> BASEDIR=`dirname "$_REALFILE"`/..
> BASEDIR=`(cd "$BASEDIR"; pwd)`
> cd "$_PWD"
> fi
> else
> BASEDIR=$ARCHIVA_BASE
> fi
> {code}
> Archiva starts up correctly.
> Step 2 of the installation guide instructs the reader to copy the files
> instead of moving them, because the "move will fail". I can only imagine what
> that means, but after what i've learned now it may indicate that the "failing
> part" may not be the move operation itself, but the successful start of
> archiva, if the 'wrapper.conf' is moved too.
> What i did was to copy the files, delete the old configuration files and to
> create a readme to remind myself where the config files are now. Including
> the 'wrapper.conf'.
> That leaves me with two options:
> Either this is a "bug" in the documentation or a bug in the generated shell
> script.
> h3. Proposal:
>
> So either
> 1) The documentation needs to be adjusted to state in step 2 that the
> wrapper.conf should stay in the base directory if that is what step 2 of the
> documentation really means.
> or
> 2) The generated shell script should include the above mentioned check.
>
> If option 1 is the correct one, i'd volunteer to provide a better
> documentation for that section.
> If option 2 is the correct one, i am afraid that i don't know how to fix
> that. I've poked around the source code and i've read the appassembler
> documentation, but i am not sure if that is even possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MRM-2022) beforeSend overwrite prevents repository scan trigger
[ https://issues.apache.org/jira/browse/MRM-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2022: --- Assignee: Martin Stockhammer > beforeSend overwrite prevents repository scan trigger > - > > Key: MRM-2022 > URL: https://issues.apache.org/jira/browse/MRM-2022 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.5 >Reporter: Cristian Onet >Assignee: Martin Stockhammer >Priority: Trivial > Attachments: archiva.patch > > > This is caused by the fact that X-XSRF-TOKEN is set by a handler setup using > ajaxSetup that is overwritten by beforeSend I worked around it using the > attached [^archiva.patch] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRM-2022) beforeSend overwrite prevents repository scan trigger
[ https://issues.apache.org/jira/browse/MRM-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-2022: Fix Version/s: 2.2.7 > beforeSend overwrite prevents repository scan trigger > - > > Key: MRM-2022 > URL: https://issues.apache.org/jira/browse/MRM-2022 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.5 >Reporter: Cristian Onet >Assignee: Martin Stockhammer >Priority: Trivial > Fix For: 2.2.7 > > Attachments: archiva.patch > > > This is caused by the fact that X-XSRF-TOKEN is set by a handler setup using > ajaxSetup that is overwritten by beforeSend I worked around it using the > attached [^archiva.patch] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRM-2026) Update Audit Log
[ https://issues.apache.org/jira/browse/MRM-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2026. - Resolution: Fixed > Update Audit Log > > > Key: MRM-2026 > URL: https://issues.apache.org/jira/browse/MRM-2026 > Project: Archiva > Issue Type: Improvement >Affects Versions: 2.2.6 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 2.2.7 > > > The log4j2.xml contains reference to redback audit log which is not used > anymore. Currently logins are not logged in the audit log. > * Remove the redbackAudit log append from config > * Add login audit log to the archiva-audit.log > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MRM-2026) Update Audit Log
Martin Stockhammer created MRM-2026: --- Summary: Update Audit Log Key: MRM-2026 URL: https://issues.apache.org/jira/browse/MRM-2026 Project: Archiva Issue Type: Improvement Affects Versions: 2.2.6 Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 2.2.7 The log4j2.xml contains reference to redback audit log which is not used anymore. Currently logins are not logged in the audit log. * Remove the redbackAudit log append from config * Add login audit log to the archiva-audit.log -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRM-2025) Update to log4j 2.16.0 (CVE-2021-45046)
[ https://issues.apache.org/jira/browse/MRM-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2025. - Resolution: Duplicate > Update to log4j 2.16.0 (CVE-2021-45046) > --- > > Key: MRM-2025 > URL: https://issues.apache.org/jira/browse/MRM-2025 > Project: Archiva > Issue Type: Dependency upgrade > Components: Audit Logging >Affects Versions: 2.2.6 >Reporter: Robert Velter >Priority: Major > > log4j 2.15.0 is not enough to fully mitigate CVE-2021-44228. > See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 > Best regards, Robert -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRM-2025) Update to log4j 2.16.0 (CVE-2021-45046)
[ https://issues.apache.org/jira/browse/MRM-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461005#comment-17461005 ] Martin Stockhammer commented on MRM-2025: - I consider the risk low here. As the vulnerability can only be exploited, if the configuration uses certain configuration patterns, and the code must be placed in the MDC. We will already changed the log4j version to 2.16.0 for the next release, which will be available not too far in the future, but we are not releasing immediately. > Update to log4j 2.16.0 (CVE-2021-45046) > --- > > Key: MRM-2025 > URL: https://issues.apache.org/jira/browse/MRM-2025 > Project: Archiva > Issue Type: Dependency upgrade > Components: Audit Logging >Affects Versions: 2.2.6 >Reporter: Robert Velter >Priority: Major > > log4j 2.15.0 is not enough to fully mitigate CVE-2021-44228. > See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 > Best regards, Robert -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRM-2024) Switch to log4j2 2.16.0
[ https://issues.apache.org/jira/browse/MRM-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2024. - Resolution: Fixed Dependencies updated for 2.x branch > Switch to log4j2 2.16.0 > --- > > Key: MRM-2024 > URL: https://issues.apache.org/jira/browse/MRM-2024 > Project: Archiva > Issue Type: Outage >Affects Versions: 2.2.6 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 2.2.7 > > > Switch to log4j2 2.16.0 as this is the recommended new version without > message expansion -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MRM-2024) Switch to log4j2 2.16.0
Martin Stockhammer created MRM-2024: --- Summary: Switch to log4j2 2.16.0 Key: MRM-2024 URL: https://issues.apache.org/jira/browse/MRM-2024 Project: Archiva Issue Type: Outage Affects Versions: 2.2.6 Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 2.2.7 Switch to log4j2 2.16.0 as this is the recommended new version without message expansion -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MRM-2023) Critical Log4j RCE bug (CVE-2021-44228)
[ https://issues.apache.org/jira/browse/MRM-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2023. - Resolution: Fixed log4j dependency updated and 2.2.6 is released > Critical Log4j RCE bug (CVE-2021-44228) > --- > > Key: MRM-2023 > URL: https://issues.apache.org/jira/browse/MRM-2023 > Project: Archiva > Issue Type: Dependency upgrade > Components: Audit Logging >Affects Versions: 2.2.5 >Reporter: Robert Velter >Assignee: Martin Stockhammer >Priority: Critical > Fix For: 2.2.6 > > > The log4j version in archiva 2.2.5 is 2.8.2. This version is affected by > CVE-2021-44228 (RCE). > Upgrading dependency to log4j version 2.15.0 (if easy possible) would solve > this issue. > Best regards, Robert -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRM-2023) Critical Log4j RCE bug (CVE-2021-44228)
[ https://issues.apache.org/jira/browse/MRM-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-2023: Fix Version/s: 2.2.6 > Critical Log4j RCE bug (CVE-2021-44228) > --- > > Key: MRM-2023 > URL: https://issues.apache.org/jira/browse/MRM-2023 > Project: Archiva > Issue Type: Dependency upgrade > Components: Audit Logging >Affects Versions: 2.2.5 >Reporter: Robert Velter >Assignee: Martin Stockhammer >Priority: Critical > Fix For: 2.2.6 > > > The log4j version in archiva 2.2.5 is 2.8.2. This version is affected by > CVE-2021-44228 (RCE). > Upgrading dependency to log4j version 2.15.0 (if easy possible) would solve > this issue. > Best regards, Robert -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRM-2023) Critical Log4j RCE bug (CVE-2021-44228)
[ https://issues.apache.org/jira/browse/MRM-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458700#comment-17458700 ] Martin Stockhammer commented on MRM-2023: - Hi, we are working on a new release. Until this then you can replace the log4j-*-2.8.2.jar in WEB-INF/lib by the 2.15.0 versions. And restart after that. > Critical Log4j RCE bug (CVE-2021-44228) > --- > > Key: MRM-2023 > URL: https://issues.apache.org/jira/browse/MRM-2023 > Project: Archiva > Issue Type: Dependency upgrade > Components: Audit Logging >Affects Versions: 2.2.5 >Reporter: Robert Velter >Assignee: Martin Stockhammer >Priority: Critical > > The log4j version in archiva 2.2.5 is 2.8.2. This version is affected by > CVE-2021-44228 (RCE). > Upgrading dependency to log4j version 2.15.0 (if easy possible) would solve > this issue. > Best regards, Robert -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MRM-2023) Critical Log4j RCE bug (CVE-2021-44228)
[ https://issues.apache.org/jira/browse/MRM-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2023: --- Assignee: Martin Stockhammer > Critical Log4j RCE bug (CVE-2021-44228) > --- > > Key: MRM-2023 > URL: https://issues.apache.org/jira/browse/MRM-2023 > Project: Archiva > Issue Type: Dependency upgrade > Components: Audit Logging >Affects Versions: 2.2.5 >Reporter: Robert Velter >Assignee: Martin Stockhammer >Priority: Critical > > The log4j version in archiva 2.2.5 is 2.8.2. This version is affected by > CVE-2021-44228 (RCE). > Upgrading dependency to log4j version 2.15.0 (if easy possible) would solve > this issue. > Best regards, Robert -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MRM-2015) Improve content validation for login
[ https://issues.apache.org/jira/browse/MRM-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-2015: Fix Version/s: 3.0.0 > Improve content validation for login > > > Key: MRM-2015 > URL: https://issues.apache.org/jira/browse/MRM-2015 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0, 2.2.5 > > > Improve the checks of the input form parameters before creating the LDAP > search filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MRM-2014) not purging old versions higher than retention count
[ https://issues.apache.org/jira/browse/MRM-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2014. - Resolution: Not A Problem Works as designed. New feature request added. > not purging old versions higher than retention count > > > Key: MRM-2014 > URL: https://issues.apache.org/jira/browse/MRM-2014 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.4 > Environment: archiva 2.2.4 > ubuntu 16.04.6 LTS >Reporter: Jason Grammenos >Assignee: Martin Stockhammer >Priority: Minor > Attachments: archiva-02-redacted.png, archiva-redacted.xml, > archiva_issue.png, archiva_issue1.png > > > I have archiva configured with a retention count of 15. > And days older of 0 > But archiva is not purging out old versions from some folders inside the > repository. > This appears to be a bug or there is something about how archiva is > configured that would prevent it from removing those artifacts/versions. > > the repository purge consumer is enabled > checking the logs, show that some purges where performed, but none have been > performed in a log time. > > images attached of current config, and part of the a artifact showing more > than 15 versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2014) not purging old versions higher than retention count
[ https://issues.apache.org/jira/browse/MRM-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136155#comment-17136155 ] Martin Stockhammer commented on MRM-2014: - Yes, the software works as it is. Sorry, that this does not match your expectations: * The repository purge consumer is only deleting artifacts for snapshot versions ( I dont't think its a good idea to remove released versions) * If you use retention count, you may have the retention count number of artifacts per snapshot directory forever If you want to get rid of all snapshot versions after some time, you have to use the artifact age as criteria. You can add a feature request for your use case via JIRA, if you like. And we welcome pull requests via github, if you like to provide an implementation. > not purging old versions higher than retention count > > > Key: MRM-2014 > URL: https://issues.apache.org/jira/browse/MRM-2014 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.4 > Environment: archiva 2.2.4 > ubuntu 16.04.6 LTS >Reporter: Jason Grammenos >Assignee: Martin Stockhammer >Priority: Minor > Attachments: archiva-02-redacted.png, archiva-redacted.xml, > archiva_issue.png, archiva_issue1.png > > > I have archiva configured with a retention count of 15. > And days older of 0 > But archiva is not purging out old versions from some folders inside the > repository. > This appears to be a bug or there is something about how archiva is > configured that would prevent it from removing those artifacts/versions. > > the repository purge consumer is enabled > checking the logs, show that some purges where performed, but none have been > performed in a log time. > > images attached of current config, and part of the a artifact showing more > than 15 versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2014) not purging old versions higher than retention count
[ https://issues.apache.org/jira/browse/MRM-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136097#comment-17136097 ] Martin Stockhammer commented on MRM-2014: - Do you have some examples of artifacts that are not deleted?The example image shows only version folders but not artifacts. For clarification, about how the repository purge consumer works: * it is deleting only snapshot artifacts who''s filenames match the maven snapshot format * it is counting the *unique snapshot versions per version directory* if there are more unique snapshot versions than the retention count values it selects the oldest snapshot versions for deletion all artifacts and related files, that have the selected snapshot version in its name, are deleted * it does not delete version directories A unique snapshot version looks like this: axis2-1.3-20070725.210059-1.pom > not purging old versions higher than retention count > > > Key: MRM-2014 > URL: https://issues.apache.org/jira/browse/MRM-2014 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.4 > Environment: archiva 2.2.4 > ubuntu 16.04.6 LTS >Reporter: Jason Grammenos >Assignee: Martin Stockhammer >Priority: Minor > Attachments: archiva-redacted.xml, archiva_issue.png, > archiva_issue1.png > > > I have archiva configured with a retention count of 15. > And days older of 0 > But archiva is not purging out old versions from some folders inside the > repository. > This appears to be a bug or there is something about how archiva is > configured that would prevent it from removing those artifacts/versions. > > the repository purge consumer is enabled > checking the logs, show that some purges where performed, but none have been > performed in a log time. > > images attached of current config, and part of the a artifact showing more > than 15 versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MRM-2010) More informative error message for LDAP errors
[
https://issues.apache.org/jira/browse/MRM-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer resolved MRM-2010.
-
Resolution: Won't Fix
I need more information for fixing this. As there is no feedback for some time
I close this issue.
You may reopen the issue and provide more information, if you like.
> More informative error message for LDAP errors
> --
>
> Key: MRM-2010
> URL: https://issues.apache.org/jira/browse/MRM-2010
> Project: Archiva
> Issue Type: Improvement
> Components: Users/Security
>Affects Versions: 2.2.4
> Environment: Archiva version 2.2.4, Linux, Kubernetes/Rancher
>Reporter: Dmitry Vavaev
>Assignee: Martin Stockhammer
>Priority: Major
>
> Hello dears,
> I'm trying to configure LDAP auth in Archiva. As a LDAP server we have Active
> Directory. All verification buttons shows green "OK" message, but when I save
> the configuration it shows an error like this in archiva.log:
> 2020-02-11 12:10:16,150 [qtp1190035432-21] INFO
> org.apache.archiva.webdav.RepositoryServlet [] - initServers done in 0 ms
> 2020-02-11 12:10:16,303 [qtp1190035432-16] WARN
> org.apache.cxf.phase.PhaseInterceptorChain [] - Application
> \{http://services.rest.redback.archiva.apache.org/}
> DefaultUserService has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: null
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:163)
> ~[cxf-core-3.0.3.jar:3.0.3]
>
> Can somebody make this more readable so it would be easier to recognize what
> exactly is wrong with the configuration? Please tell if any other information
> needed. Thanks!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRM-2013) Unable to install WAR in GlassFish 5.1.0
[
https://issues.apache.org/jira/browse/MRM-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17135559#comment-17135559
]
Martin Stockhammer commented on MRM-2013:
-
Hi, we are not able to support the many different application server versions
and flavours that exist in the field.
I can only tell, that archiva is not using CDI, so you should deactivate CDI in
glassfish, if possible.
> Unable to install WAR in GlassFish 5.1.0
>
>
> Key: MRM-2013
> URL: https://issues.apache.org/jira/browse/MRM-2013
> Project: Archiva
> Issue Type: Bug
> Components: system
>Affects Versions: 2.2.4
> Environment: FreeBSD 11.3
>Reporter: Marcelo Ruiz
>Priority: Major
> Labels: glassfish, war
>
> Failed to deploy archiva's war file in GlassFish 5.0.1, even after following
> the configuration instructions located in
> [https://cwiki.apache.org/confluence/display/ARCHIVA/Archiva+on+GlassFish+with+mySQL]
> GlassFish log shows:
> {quote}[2020-04-23T14:15:43.647-0400] [glassfish 5.1] [SEVERE]
> [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=61
> _ThreadName=AutoDeployer] [timeMillis: 1587665743647] [levelValue: 1000] [[
> Exception during lifecycle processing
> org.glassfish.deployment.common.DeploymentException: CDI deployment
> failure:Exception List with 2 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
> dependencies for type Injector with qualifiers @Default
> at injection point [BackedAnnotatedParameter] Parameter 1 of
> [BackedAnnotatedMethod] @Inject
> org.eclipse.sisu.locators.DefaultBeanLocator.autoPublish(Injector)
> at
> org.eclipse.sisu.locators.DefaultBeanLocator.autoPublish(DefaultBeanLocator.java:194)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:375)
> at
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:287)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:140)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:161)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:504)
> at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:479)
> at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:481)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
> at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:206)
> at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:107)
> at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:304)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:472)
> at
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:195)
> at
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:467)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:516)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:512)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:511)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:542)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:534)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:533)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1441)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:86)
> at
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1823)
> at
> org.glassfish.deployment.autodeploy.AutoOperation.run(AutoOperation.java:140)
> at
> org.glassfish.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:573)
> at
> org.glassfish.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:460)
> at
> org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:388)
> at
> org.glassfish.deployment.autodeploy.AutoDeployer.run(AutoDeployer.java:379)
> at
> org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:209)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> Exception 1 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
>
[jira] [Commented] (MRM-2014) not purging old versions higher than retention count
[ https://issues.apache.org/jira/browse/MRM-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17135554#comment-17135554 ] Martin Stockhammer commented on MRM-2014: - Hi, can you send me a copy of the configuration file archiva.xml (you should remove confidential information before)? > not purging old versions higher than retention count > > > Key: MRM-2014 > URL: https://issues.apache.org/jira/browse/MRM-2014 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.4 > Environment: archiva 2.2.4 > ubuntu 16.04.6 LTS >Reporter: Jason Grammenos >Assignee: Martin Stockhammer >Priority: Minor > Attachments: archiva_issue.png, archiva_issue1.png > > > I have archiva configured with a retention count of 15. > And days older of 0 > But archiva is not purging out old versions from some folders inside the > repository. > This appears to be a bug or there is something about how archiva is > configured that would prevent it from removing those artifacts/versions. > > the repository purge consumer is enabled > checking the logs, show that some purges where performed, but none have been > performed in a log time. > > images attached of current config, and part of the a artifact showing more > than 15 versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRM-2014) not purging old versions higher than retention count
[ https://issues.apache.org/jira/browse/MRM-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2014: --- Assignee: Martin Stockhammer > not purging old versions higher than retention count > > > Key: MRM-2014 > URL: https://issues.apache.org/jira/browse/MRM-2014 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 2.2.4 > Environment: archiva 2.2.4 > ubuntu 16.04.6 LTS >Reporter: Jason Grammenos >Assignee: Martin Stockhammer >Priority: Minor > Attachments: archiva_issue.png, archiva_issue1.png > > > I have archiva configured with a retention count of 15. > And days older of 0 > But archiva is not purging out old versions from some folders inside the > repository. > This appears to be a bug or there is something about how archiva is > configured that would prevent it from removing those artifacts/versions. > > the repository purge consumer is enabled > checking the logs, show that some purges where performed, but none have been > performed in a log time. > > images attached of current config, and part of the a artifact showing more > than 15 versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MRM-2015) Improve content validation for login
[ https://issues.apache.org/jira/browse/MRM-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2015. - Resolution: Fixed > Improve content validation for login > > > Key: MRM-2015 > URL: https://issues.apache.org/jira/browse/MRM-2015 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 2.2.5 > > > Improve the checks of the input form parameters before creating the LDAP > search filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRM-2015) Improve content validation for login
Martin Stockhammer created MRM-2015: --- Summary: Improve content validation for login Key: MRM-2015 URL: https://issues.apache.org/jira/browse/MRM-2015 Project: Archiva Issue Type: Bug Components: redback Affects Versions: 2.2.4 Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 2.2.5 Improve the checks of the input form parameters before creating the LDAP search filter. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MRM-2012) Link to mailling list subscription do not work
[ https://issues.apache.org/jira/browse/MRM-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2012. - Resolution: Fixed Had to change the version of project-info-reports-plugin to fix the links. Currently using snapshot version as the fix is not released yet. > Link to mailling list subscription do not work > -- > > Key: MRM-2012 > URL: https://issues.apache.org/jira/browse/MRM-2012 > Project: Archiva > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2.4 >Reporter: Karl Heinz Marbaise >Assignee: Martin Stockhammer >Priority: Minor > > Currently all the links to subscribe on the mailing list do not work on this > page > https://archiva.apache.org/mailing-lists.html result in 404 page not found. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRM-2012) Link to mailling list subscription do not work
[ https://issues.apache.org/jira/browse/MRM-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2012: --- Assignee: Martin Stockhammer > Link to mailling list subscription do not work > -- > > Key: MRM-2012 > URL: https://issues.apache.org/jira/browse/MRM-2012 > Project: Archiva > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2.4 >Reporter: Karl Heinz Marbaise >Assignee: Martin Stockhammer >Priority: Minor > > Currently all the links to subscribe on the mailing list do not work on this > page > https://archiva.apache.org/mailing-lists.html result in 404 page not found. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2010) More informative error message for LDAP errors
[
https://issues.apache.org/jira/browse/MRM-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036512#comment-17036512
]
Martin Stockhammer commented on MRM-2010:
-
Hi,
sorry, this error message is really not very helpful. Is there no stacktrace
after or before this error message in the log?
Could you please increase the logging level for archiva to debug
(WEB-INF/classes/log4j2.xml) and try again?
Thx
Martin
> More informative error message for LDAP errors
> --
>
> Key: MRM-2010
> URL: https://issues.apache.org/jira/browse/MRM-2010
> Project: Archiva
> Issue Type: Improvement
> Components: Users/Security
>Affects Versions: 2.2.4
> Environment: Archiva version 2.2.4, Linux, Kubernetes/Rancher
>Reporter: Dmitry Vavaev
>Assignee: Martin Stockhammer
>Priority: Major
>
> Hello dears,
> I'm trying to configure LDAP auth in Archiva. As a LDAP server we have Active
> Directory. All verification buttons shows green "OK" message, but when I save
> the configuration it shows an error like this in archiva.log:
> 2020-02-11 12:10:16,150 [qtp1190035432-21] INFO
> org.apache.archiva.webdav.RepositoryServlet [] - initServers done in 0 ms
> 2020-02-11 12:10:16,303 [qtp1190035432-16] WARN
> org.apache.cxf.phase.PhaseInterceptorChain [] - Application
> \{http://services.rest.redback.archiva.apache.org/}
> DefaultUserService has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: null
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:163)
> ~[cxf-core-3.0.3.jar:3.0.3]
>
> Can somebody make this more readable so it would be easier to recognize what
> exactly is wrong with the configuration? Please tell if any other information
> needed. Thanks!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRM-2010) More informative error message for LDAP errors
[
https://issues.apache.org/jira/browse/MRM-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer reassigned MRM-2010:
---
Assignee: Martin Stockhammer
> More informative error message for LDAP errors
> --
>
> Key: MRM-2010
> URL: https://issues.apache.org/jira/browse/MRM-2010
> Project: Archiva
> Issue Type: Improvement
> Components: Users/Security
>Affects Versions: 2.2.4
> Environment: Archiva version 2.2.4, Linux, Kubernetes/Rancher
>Reporter: Dmitry Vavaev
>Assignee: Martin Stockhammer
>Priority: Major
>
> Hello dears,
> I'm trying to configure LDAP auth in Archiva. As a LDAP server we have Active
> Directory. All verification buttons shows green "OK" message, but when I save
> the configuration it shows an error like this in archiva.log:
> 2020-02-11 12:10:16,150 [qtp1190035432-21] INFO
> org.apache.archiva.webdav.RepositoryServlet [] - initServers done in 0 ms
> 2020-02-11 12:10:16,303 [qtp1190035432-16] WARN
> org.apache.cxf.phase.PhaseInterceptorChain [] - Application
> \{http://services.rest.redback.archiva.apache.org/}
> DefaultUserService has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: null
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:163)
> ~[cxf-core-3.0.3.jar:3.0.3]
>
> Can somebody make this more readable so it would be easier to recognize what
> exactly is wrong with the configuration? Please tell if any other information
> needed. Thanks!
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MRM-2008) LDAP/Roles Mapping LDAP Group names ending with a double quote
[ https://issues.apache.org/jira/browse/MRM-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2008. - Resolution: Fixed Great to hear. Thank you for reporting this. Regards Martin > LDAP/Roles Mapping LDAP Group names ending with a double quote > -- > > Key: MRM-2008 > URL: https://issues.apache.org/jira/browse/MRM-2008 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: AIX 7.1 on Power with war file deployed to WebSphere > Liberty 19.0.0.9 >Reporter: Frederick Asselin >Assignee: Martin Stockhammer >Priority: Minor > Fix For: 3.0.0, redback-2.6.1, 2.2.5, redback-3.0.0 > > Attachments: archiva_ldap_groups.jpg > > > We're trying to setup LDAP in our Archiva installation. We're using the war > file deployed to a WebSphere Liberty 19.0.0.9 server running on AIX 7.1. > LDAP server is Security Directory Server 6.4 running also on AIX 7.1. > I'm able to configure the LDAP server and properties in Archiva and the > "Verify LDAP changes" and "Verify LDAP configuration on server side" checks > are successfull. > I can see the user list when I edit a role and I can also see the groups in > the LDAP/Roles mapping tab. However, the groups are listed with an ending > double quote, which is not present in the LDAP server. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > I don't know if it is the cause of our other problem, but Archiva doesn't > seem to see the LDAP group membership so when I assign roles to LDAP groups, > they are not taken into account when a user logs in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRM-2008) LDAP/Roles Mapping LDAP Group names ending with a double quote
[ https://issues.apache.org/jira/browse/MRM-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-2008: Fix Version/s: redback-3.0.0 > LDAP/Roles Mapping LDAP Group names ending with a double quote > -- > > Key: MRM-2008 > URL: https://issues.apache.org/jira/browse/MRM-2008 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: AIX 7.1 on Power with war file deployed to WebSphere > Liberty 19.0.0.9 >Reporter: Frederick Asselin >Assignee: Martin Stockhammer >Priority: Minor > Fix For: 3.0.0, redback-2.6.1, 2.2.5, redback-3.0.0 > > Attachments: archiva_ldap_groups.jpg > > > We're trying to setup LDAP in our Archiva installation. We're using the war > file deployed to a WebSphere Liberty 19.0.0.9 server running on AIX 7.1. > LDAP server is Security Directory Server 6.4 running also on AIX 7.1. > I'm able to configure the LDAP server and properties in Archiva and the > "Verify LDAP changes" and "Verify LDAP configuration on server side" checks > are successfull. > I can see the user list when I edit a role and I can also see the groups in > the LDAP/Roles mapping tab. However, the groups are listed with an ending > double quote, which is not present in the LDAP server. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > I don't know if it is the cause of our other problem, but Archiva doesn't > seem to see the LDAP group membership so when I assign roles to LDAP groups, > they are not taken into account when a user logs in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRM-2008) LDAP/Roles Mapping LDAP Group names ending with a double quote
[ https://issues.apache.org/jira/browse/MRM-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-2008: Fix Version/s: 2.2.5 redback-2.6.1 3.0.0 > LDAP/Roles Mapping LDAP Group names ending with a double quote > -- > > Key: MRM-2008 > URL: https://issues.apache.org/jira/browse/MRM-2008 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: AIX 7.1 on Power with war file deployed to WebSphere > Liberty 19.0.0.9 >Reporter: Frederick Asselin >Assignee: Martin Stockhammer >Priority: Minor > Fix For: 3.0.0, redback-2.6.1, 2.2.5 > > Attachments: archiva_ldap_groups.jpg > > > We're trying to setup LDAP in our Archiva installation. We're using the war > file deployed to a WebSphere Liberty 19.0.0.9 server running on AIX 7.1. > LDAP server is Security Directory Server 6.4 running also on AIX 7.1. > I'm able to configure the LDAP server and properties in Archiva and the > "Verify LDAP changes" and "Verify LDAP configuration on server side" checks > are successfull. > I can see the user list when I edit a role and I can also see the groups in > the LDAP/Roles mapping tab. However, the groups are listed with an ending > double quote, which is not present in the LDAP server. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > I don't know if it is the cause of our other problem, but Archiva doesn't > seem to see the LDAP group membership so when I assign roles to LDAP groups, > they are not taken into account when a user logs in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2008) LDAP/Roles Mapping LDAP Group names ending with a double quote
[ https://issues.apache.org/jira/browse/MRM-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023637#comment-17023637 ] Martin Stockhammer commented on MRM-2008: - Indeed, the Java LDAP API does some escaping for names that contain slashes. I think, I could fix it. Commit 0aa82c13efa16ff9a58d32951ea15a10863bd809 on archiva-redback-core for the 2.x branch Commit 2ec73e9ed5331e89e8e2306586b32cba2488c228 on archiva-redback-core for the master. We are not going to release a fix version for the archiva 2.2 version in the near time. If you like to test it, you have to use the snapshot files and replace them in your local archiva installation. You have to replace the jar file: apps/archiva/WEB-INF/lib/redback-common-ldap-2.6.jar in the archiva installation by the version from [https://archiva-repository.apache.org/archiva/repository/snapshots/org/apache/archiva/redback/redback-common-ldap/2.6.1-SNAPSHOT/redback-common-ldap-2.6.1-20200125.195446-1.jar] Please tell me, if you encounter any problems with this fix. Regards Martin > LDAP/Roles Mapping LDAP Group names ending with a double quote > -- > > Key: MRM-2008 > URL: https://issues.apache.org/jira/browse/MRM-2008 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: AIX 7.1 on Power with war file deployed to WebSphere > Liberty 19.0.0.9 >Reporter: Frederick Asselin >Assignee: Martin Stockhammer >Priority: Minor > Attachments: archiva_ldap_groups.jpg > > > We're trying to setup LDAP in our Archiva installation. We're using the war > file deployed to a WebSphere Liberty 19.0.0.9 server running on AIX 7.1. > LDAP server is Security Directory Server 6.4 running also on AIX 7.1. > I'm able to configure the LDAP server and properties in Archiva and the > "Verify LDAP changes" and "Verify LDAP configuration on server side" checks > are successfull. > I can see the user list when I edit a role and I can also see the groups in > the LDAP/Roles mapping tab. However, the groups are listed with an ending > double quote, which is not present in the LDAP server. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > I don't know if it is the cause of our other problem, but Archiva doesn't > seem to see the LDAP group membership so when I assign roles to LDAP groups, > they are not taken into account when a user logs in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRM-2008) LDAP/Roles Mapping LDAP Group names ending with a double quote
[ https://issues.apache.org/jira/browse/MRM-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2008: --- Assignee: Martin Stockhammer > LDAP/Roles Mapping LDAP Group names ending with a double quote > -- > > Key: MRM-2008 > URL: https://issues.apache.org/jira/browse/MRM-2008 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: AIX 7.1 on Power with war file deployed to WebSphere > Liberty 19.0.0.9 >Reporter: Frederick Asselin >Assignee: Martin Stockhammer >Priority: Minor > Attachments: archiva_ldap_groups.jpg > > > We're trying to setup LDAP in our Archiva installation. We're using the war > file deployed to a WebSphere Liberty 19.0.0.9 server running on AIX 7.1. > LDAP server is Security Directory Server 6.4 running also on AIX 7.1. > I'm able to configure the LDAP server and properties in Archiva and the > "Verify LDAP changes" and "Verify LDAP configuration on server side" checks > are successfull. > I can see the user list when I edit a role and I can also see the groups in > the LDAP/Roles mapping tab. However, the groups are listed with an ending > double quote, which is not present in the LDAP server. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > I don't know if it is the cause of our other problem, but Archiva doesn't > seem to see the LDAP group membership so when I assign roles to LDAP groups, > they are not taken into account when a user logs in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2008) LDAP/Roles Mapping LDAP Group names ending with a double quote
[ https://issues.apache.org/jira/browse/MRM-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17020930#comment-17020930 ] Martin Stockhammer commented on MRM-2008: - Hi Frederick, I will try to reproduce this. Can you please give a sample of the archiva.xml section where the double quote occurs? Thank you and Regards Martin > LDAP/Roles Mapping LDAP Group names ending with a double quote > -- > > Key: MRM-2008 > URL: https://issues.apache.org/jira/browse/MRM-2008 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: AIX 7.1 on Power with war file deployed to WebSphere > Liberty 19.0.0.9 >Reporter: Frederick Asselin >Priority: Minor > Attachments: archiva_ldap_groups.jpg > > > We're trying to setup LDAP in our Archiva installation. We're using the war > file deployed to a WebSphere Liberty 19.0.0.9 server running on AIX 7.1. > LDAP server is Security Directory Server 6.4 running also on AIX 7.1. > I'm able to configure the LDAP server and properties in Archiva and the > "Verify LDAP changes" and "Verify LDAP configuration on server side" checks > are successfull. > I can see the user list when I edit a role and I can also see the groups in > the LDAP/Roles mapping tab. However, the groups are listed with an ending > double quote, which is not present in the LDAP server. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > I don't know if it is the cause of our other problem, but Archiva doesn't > seem to see the LDAP group membership so when I assign roles to LDAP groups, > they are not taken into account when a user logs in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRM-2009) LDAP/Roles Mapping not working
[ https://issues.apache.org/jira/browse/MRM-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer closed MRM-2009. --- > LDAP/Roles Mapping not working > -- > > Key: MRM-2009 > URL: https://issues.apache.org/jira/browse/MRM-2009 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: war file deployed on WebSphere Liberty 19.0.0.9 on AIX > 7.1 with Security Directory Server 6.4 running on AIX 7.1 >Reporter: Frederick Asselin >Priority: Major > > We're trying to setup Archiva to use our LDAP server, but the LDAP/Roles > group mapping is not working. When LDAP users are logging in, they don't get > access to the functions they should have access to. > The LDAP setup seems to be good, as we can use the LDAP/Roles mapping tab to > add roles to LDAP groups and we also give users access to roles directly in > the role editor page. > So it looks like Archiva is not correctly seeing the user/group membership > from our LDAP server, even if I set up the properties for LDAP user/group > object class names, group membership and other attributes. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > Also, when I try to setup debug logging by modifiying the log4j2.xml file, I > still get nothing more in the different archiva log files. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2009) LDAP/Roles Mapping not working
[ https://issues.apache.org/jira/browse/MRM-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018145#comment-17018145 ] Martin Stockhammer commented on MRM-2009: - Hi Frederick, what ldap server do you use? Is it active directory or any other type? How are the members stored in the group? Is it using 'member' attribute on the group object? Are the member entries the full DN of the members? Do you see errors in the logs? Regards Martin -- This message was sent from mobile phone. > LDAP/Roles Mapping not working > -- > > Key: MRM-2009 > URL: https://issues.apache.org/jira/browse/MRM-2009 > Project: Archiva > Issue Type: Bug > Components: redback >Affects Versions: 2.2.4 > Environment: war file deployed on WebSphere Liberty 19.0.0.9 on AIX > 7.1 with Security Directory Server 6.4 running on AIX 7.1 >Reporter: Frederick Asselin >Priority: Major > > We're trying to setup Archiva to use our LDAP server, but the LDAP/Roles > group mapping is not working. When LDAP users are logging in, they don't get > access to the functions they should have access to. > The LDAP setup seems to be good, as we can use the LDAP/Roles mapping tab to > add roles to LDAP groups and we also give users access to roles directly in > the role editor page. > So it looks like Archiva is not correctly seeing the user/group membership > from our LDAP server, even if I set up the properties for LDAP user/group > object class names, group membership and other attributes. > The issue also occurs when I run Archiva using the default Jetty server > running on my Windows 10 laptop connecting to the same LDAP server. > Also, when I try to setup debug logging by modifiying the log4j2.xml file, I > still get nothing more in the different archiva log files. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MRM-2007) Add staging branch to site repository
[ https://issues.apache.org/jira/browse/MRM-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2007. - Resolution: Fixed The asf-staging is used by all site generation processes now The publish process is documented at the archiva site. > Add staging branch to site repository > - > > Key: MRM-2007 > URL: https://issues.apache.org/jira/browse/MRM-2007 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > With the new .asf.yaml we can create a staging branch in the site repository. > We should use this to test site updates. > Releasing the updates would be a simple merge of the staging branch to the > master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MRM-2007) Add staging branch to site repository
[ https://issues.apache.org/jira/browse/MRM-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984664#comment-16984664 ] Martin Stockhammer edited comment on MRM-2007 at 11/28/19 10:30 PM: archiva-site is migrated to the new asf-staging branch and published already. Todo: * Switch redback-site publish to the staging branch * Switch archiva-docs * Switch archiva-modules Documentation of new site release process: * Run scripts to publish to asf-staging * Check site on archiva.staged.apache.org * Merge the changes to master in archiva-web-content.git was (Author: effrafax): archiva-site is migrated to the new asf-staging branch and published already. Todo: * Switch redback-site publish to the staging branch * Switch archiva-docs * Switch archiva-modules Documentation new site release process: * Run scripts to publish to asf-staging * Check site on archiva.staged.apache.org * Merge the changes to master in archiva-web-content.git > Add staging branch to site repository > - > > Key: MRM-2007 > URL: https://issues.apache.org/jira/browse/MRM-2007 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > With the new .asf.yaml we can create a staging branch in the site repository. > We should use this to test site updates. > Releasing the updates would be a simple merge of the staging branch to the > master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2007) Add staging branch to site repository
[ https://issues.apache.org/jira/browse/MRM-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984664#comment-16984664 ] Martin Stockhammer commented on MRM-2007: - archiva-site is migrated to the new asf-staging branch and published already. Todo: * Switch redback-site publish to the staging branch * Switch archiva-docs * Switch archiva-modules Documentation new site release process: * Run scripts to publish to asf-staging * Check site on archiva.staged.apache.org * Merge the changes to master in archiva-web-content.git > Add staging branch to site repository > - > > Key: MRM-2007 > URL: https://issues.apache.org/jira/browse/MRM-2007 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > With the new .asf.yaml we can create a staging branch in the site repository. > We should use this to test site updates. > Releasing the updates would be a simple merge of the staging branch to the > master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MRM-2006) Consolidate Components
[ https://issues.apache.org/jira/browse/MRM-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer resolved MRM-2006. - Resolution: Fixed Finished > Consolidate Components > -- > > Key: MRM-2006 > URL: https://issues.apache.org/jira/browse/MRM-2006 > Project: Archiva > Issue Type: Improvement > Components: Archiva Components >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > Consolidate the Redback Components modules. > * Rename to Archiva Components > * Deprecate unused components > * Move components, that are still used, to the new combined repository > archiva-components.git > * Change Maven coordinates to org.apache.archiva.components prefix > * Change package names of java code to org.apache.archiva.components prefix > * Cleanup dependencies > * Update third party dependencies > * Change dependencies in archiva and redback to the new coordinates > * Update site generation > * Remove Jenkinsfile from former component repositories and add information > to README -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2006) Consolidate Components
[ https://issues.apache.org/jira/browse/MRM-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984662#comment-16984662 ] Martin Stockhammer commented on MRM-2006: - Its finished. site generation is updated and using the new asf-staging branch. Apache site is updated and points to the new documentation at /components Archiva and Redback use all new components. > Consolidate Components > -- > > Key: MRM-2006 > URL: https://issues.apache.org/jira/browse/MRM-2006 > Project: Archiva > Issue Type: Improvement > Components: Archiva Components >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > Consolidate the Redback Components modules. > * Rename to Archiva Components > * Deprecate unused components > * Move components, that are still used, to the new combined repository > archiva-components.git > * Change Maven coordinates to org.apache.archiva.components prefix > * Change package names of java code to org.apache.archiva.components prefix > * Cleanup dependencies > * Update third party dependencies > * Change dependencies in archiva and redback to the new coordinates > * Update site generation > * Remove Jenkinsfile from former component repositories and add information > to README -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2007) Add staging branch to site repository
[ https://issues.apache.org/jira/browse/MRM-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984659#comment-16984659 ] Martin Stockhammer commented on MRM-2007: - .asf.yaml may contain no more than one staging and one publish entry. Which means, we cannot use the same .asf.yaml on all branches. We will use one yaml for master and asf-staging and asf-staging-3.0 will get its own. > Add staging branch to site repository > - > > Key: MRM-2007 > URL: https://issues.apache.org/jira/browse/MRM-2007 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > With the new .asf.yaml we can create a staging branch in the site repository. > We should use this to test site updates. > Releasing the updates would be a simple merge of the staging branch to the > master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2007) Add staging branch to site repository
[ https://issues.apache.org/jira/browse/MRM-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981055#comment-16981055 ] Martin Stockhammer commented on MRM-2007: - Branch names for staging should be start with asf-staging, because this pattern is checked, if the publish is done by jenkins. Creating these staging branches: asf-staging -> Standard Staging profile asf-staging-3.0 -> Profile 3-0 for testing the complete site generation from the master branch > Add staging branch to site repository > - > > Key: MRM-2007 > URL: https://issues.apache.org/jira/browse/MRM-2007 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > With the new .asf.yaml we can create a staging branch in the site repository. > We should use this to test site updates. > Releasing the updates would be a simple merge of the staging branch to the > master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRM-2007) Add staging branch to site repository
Martin Stockhammer created MRM-2007: --- Summary: Add staging branch to site repository Key: MRM-2007 URL: https://issues.apache.org/jira/browse/MRM-2007 Project: Archiva Issue Type: Task Reporter: Martin Stockhammer Assignee: Martin Stockhammer With the new .asf.yaml we can create a staging branch in the site repository. We should use this to test site updates. Releasing the updates would be a simple merge of the staging branch to the master. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2006) Consolidate Components
[ https://issues.apache.org/jira/browse/MRM-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981045#comment-16981045 ] Martin Stockhammer commented on MRM-2006: - This is mostly done. Components have been moved. Former repositories are still available but with info in README and without jenkins build. Still have to update the site generation: - New path will be http://archiva.apache.org/components/ > Consolidate Components > -- > > Key: MRM-2006 > URL: https://issues.apache.org/jira/browse/MRM-2006 > Project: Archiva > Issue Type: Improvement > Components: Archiva Components >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > Consolidate the Redback Components modules. > * Rename to Archiva Components > * Deprecate unused components > * Move components, that are still used, to the new combined repository > archiva-components.git > * Change Maven coordinates to org.apache.archiva.components prefix > * Change package names of java code to org.apache.archiva.components prefix > * Cleanup dependencies > * Update third party dependencies > * Change dependencies in archiva and redback to the new coordinates > * Update site generation > * Remove Jenkinsfile from former component repositories and add information > to README -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRM-2006) Consolidate Components
Martin Stockhammer created MRM-2006: --- Summary: Consolidate Components Key: MRM-2006 URL: https://issues.apache.org/jira/browse/MRM-2006 Project: Archiva Issue Type: Improvement Components: Archiva Components Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 3.0.0 Consolidate the Redback Components modules. * Rename to Archiva Components * Deprecate unused components * Move components, that are still used, to the new combined repository archiva-components.git * Change Maven coordinates to org.apache.archiva.components prefix * Change package names of java code to org.apache.archiva.components prefix * Cleanup dependencies * Update third party dependencies * Change dependencies in archiva and redback to the new coordinates * Update site generation * Remove Jenkinsfile from former component repositories and add information to README -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRM-2005) Rest service copyArtifact should fix metadata after copy
Martin Stockhammer created MRM-2005: --- Summary: Rest service copyArtifact should fix metadata after copy Key: MRM-2005 URL: https://issues.apache.org/jira/browse/MRM-2005 Project: Archiva Issue Type: Bug Components: rest services Affects Versions: 2.2.4 Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 3.0.0 >From the mailing list: The next problem, and weird behavior is that the rest service copyArtifact is not fixing the metadata for the new files. Something I expected it to do. I guess this is a bug. So to fix the metadata you actually have to run scanRepositoryDirectoriesNow ... before you can use the artifact with for example mvn versions:use-latest-versions. If your repository is large, like for example 200gig then scanRepositoryDirectoriesNow takes more than 60mins. This leads to not being able to use the artifact until the directory have been scanned. Really bad. Suggestions to fix this is to either fix a rest request where its possible to scan a specific artifact and fix for example the metadata, checksum or whatever stuff you want to fix with the consumers. Would be really handy. Another solution is if the copyArtifact does this, something I expected it to do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2004) Rest call for copyArtifact throws NullpointerException if destination exists
[ https://issues.apache.org/jira/browse/MRM-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975318#comment-16975318 ] Martin Stockhammer commented on MRM-2004: - Workaround: Finally got the request to work. For others reading this, it's important to not copy an artifact that already exist in the repository you are trying to copy the artifact to. The response code is not giving any clues that this is the actual problem. Would be good if there was a better response code for this. > Rest call for copyArtifact throws NullpointerException if destination exists > > > Key: MRM-2004 > URL: https://issues.apache.org/jira/browse/MRM-2004 > Project: Archiva > Issue Type: Bug > Components: rest services >Affects Versions: 2.2.4 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > The rest service copyArtifact throws NullpointerException, if the destination > artifact exists already. > Should either overwrite, or return a proper error response. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2004) Rest call for copyArtifact throws NullpointerException if destination exists
[
https://issues.apache.org/jira/browse/MRM-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975316#comment-16975316
]
Martin Stockhammer commented on MRM-2004:
-
>From the mailing list:
Hi,
I am trying to use the rest service copyArtifact, but I can't get it to
work. Feels like I have tried everything. I am trying to do this with
groovy and this is how my code looks at the moment. The info in
artifactTransferRequest is from the response of searchArtifacts
def copyArtifact() {
def baseUrl = "..."
def request = new RESTClient(baseUrl + "
_/restServices/archivaServices/_
")
request.headers['Authorization'] = "Basic " +
("username:pass".bytes.encodeBase64().toString())
request.handler.failure = \{ response ->
println "Unexpected failure: ${response.status}"
}
def copyArtifactResponse = request.post(
path: "repositoriesService/copyArtifact",
contentType: JSON,
requestContentType: XML,
body: \{
artifactTransferRequest {
targetRepositoryId "tagged-releases"
packaging "dll"
fileExtension "dll"
type"dll"
artifactId "bla4"
groupId "se..."
version "2020.1"
repositoryId"release"
context "release"
url "..."
}
}
)
println "Status: " + copyArtifactResponse.status
if (copyArtifactResponse.data) \{
println("Content Type: " + copyArtifactResponse.contentType)
println("Headers: " + copyArtifactResponse.getAllHeaders())
println("Body:\n" +
JsonOutput.prettyPrint(JsonOutput.toJson(copyArtifactResponse.data)))
}
}
Here is the response I get:
Unexpected failure: 500
Caught: java.lang.NullPointerException: Cannot get property 'status' on
null object
java.lang.NullPointerException: Cannot get property 'status' on null
object
> Rest call for copyArtifact throws NullpointerException if destination exists
>
>
> Key: MRM-2004
> URL: https://issues.apache.org/jira/browse/MRM-2004
> Project: Archiva
> Issue Type: Bug
> Components: rest services
>Affects Versions: 2.2.4
>Reporter: Martin Stockhammer
>Assignee: Martin Stockhammer
>Priority: Major
> Fix For: 3.0.0
>
>
> The rest service copyArtifact throws NullpointerException, if the destination
> artifact exists already.
> Should either overwrite, or return a proper error response.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MRM-2004) Rest call for copyArtifact throws NullpointerException if destination exists
Martin Stockhammer created MRM-2004: --- Summary: Rest call for copyArtifact throws NullpointerException if destination exists Key: MRM-2004 URL: https://issues.apache.org/jira/browse/MRM-2004 Project: Archiva Issue Type: Bug Components: rest services Affects Versions: 2.2.4 Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 3.0.0 The rest service copyArtifact throws NullpointerException, if the destination artifact exists already. Should either overwrite, or return a proper error response. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2003) The owner of this website (www.terracotta.org) has banned your access based on your browser's signature (521f0006ab85c286-ua21).
[
https://issues.apache.org/jira/browse/MRM-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946167#comment-16946167
]
Martin Stockhammer commented on MRM-2003:
-
Hi Christian,
Archiva 2.2.4 runs only with JDK 7 or 8. It is not able to start with JDK 12.
About the terracotta error. Seems to be a update check, that is active. I don't
know, if this is really the cause of the download problem, but you may
deactivate it with the line:
wrapper.java.additional.9=-Dnet.sf.ehcache.skipUpdateCheck=true
in conf/wrapper.conf
Is the requested archive
org.apache.maven.plugins:maven-failsafe-plugin:jar:2.18.1 really in your
archiva repository? Did you check by using the web console? Is your repository
a mirror or only a local repository?
Regards
Martin
> The owner of this website (www.terracotta.org) has banned your access based
> on your browser's signature (521f0006ab85c286-ua21).
>
>
> Key: MRM-2003
> URL: https://issues.apache.org/jira/browse/MRM-2003
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Christian
>Assignee: Martin Stockhammer
>Priority: Blocker
>
> I set up a new Archiva 2.2.4 (the standalone version:
> [apache-archiva-2.2.4-bin.tar.gz)|http://mirror.dkd.de/apache/archiva/2.2.4/binaries/apache-archiva-2.2.4-bin.tar.gz)]
> and get then from my local maven (after switching to the new Archiva via
> settings.xml):
> {code:java}
> [ERROR] Plugin org.apache.maven.plugins:maven-failsafe-plugin:2.18.1 or one
> of its dependencies could not be resolved: Could not find artifact
> org.apache.maven.plugins:maven-failsafe-plugin:jar:2.18.1 in internal
> (http://archiva.FOO.intern:8080/archiva/repository/internal/)
> {code}
> ... Investigate ...
> It seems so, that the indexer works together with _www.terracotta.org_ (from
> my Wireshark).
> {code:java}
> GET
> /kit/reflector?pageID=update.properties=UNKNOWN=ehcache-core+2.7.5=2.7.5=11=ehcache.default=12.0.2=Linux=-1408104395=ehcache-core=OpenJDK+64-Bit+Server+VM=amd64
> Host: www.terracotta.org
> User-Agent: Java/1.8.0_222
> {code}
> But from that side my archiva virtual machine gets only the subjected message.
> {code:java}
> The owner of this website (www.terracotta.org) has banned your access based
> on your browser's signature (521f0006ab85c286-ua21).
> {code}
> My first thought was, that this message would be generated, because Java8 is
> EOL. Also switched I my linux VM (opensuse tumbleweed) to java12, but get
> only a lot of Exceptions after restarting Archiva. That would not better
> after asking the big brother, downloading the following jars and adding the
> lines in the wrapper,conf.
> {code:java}
> wrapper.java.classpath.27=/home/archiva/jaxb-api-2.3.0.jar
> wrapper.java.classpath.28=/home/archiva/jaxb-core-2.3.0.jar
> wrapper.java.classpath.29=/home/archiva/jaxb-impl-2.3.0.jar
> {code}
> But nevertheless I get another user agent:
> {code:java}
> User-Agent: Java/12.0.2
> {code}
> and another bann message:
> {code:java}
> You don't have permission to access /kit/reflector on this server.
> {code}
> Exists a quick solution that my local Archiva could run (again), maybe
> without using _www.terracotta.org_?
> Thanks, cu.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRM-2003) The owner of this website (www.terracotta.org) has banned your access based on your browser's signature (521f0006ab85c286-ua21).
[
https://issues.apache.org/jira/browse/MRM-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer reassigned MRM-2003:
---
Assignee: Martin Stockhammer
> The owner of this website (www.terracotta.org) has banned your access based
> on your browser's signature (521f0006ab85c286-ua21).
>
>
> Key: MRM-2003
> URL: https://issues.apache.org/jira/browse/MRM-2003
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Christian
>Assignee: Martin Stockhammer
>Priority: Blocker
>
> I set up a new Archiva 2.2.4 (the standalone version:
> [apache-archiva-2.2.4-bin.tar.gz)|http://mirror.dkd.de/apache/archiva/2.2.4/binaries/apache-archiva-2.2.4-bin.tar.gz)]
> and get then from my local maven (after switching to the new Archiva via
> settings.xml):
> {code:java}
> [ERROR] Plugin org.apache.maven.plugins:maven-failsafe-plugin:2.18.1 or one
> of its dependencies could not be resolved: Could not find artifact
> org.apache.maven.plugins:maven-failsafe-plugin:jar:2.18.1 in internal
> (http://archiva.FOO.intern:8080/archiva/repository/internal/)
> {code}
> ... Investigate ...
> It seems so, that the indexer works together with _www.terracotta.org_ (from
> my Wireshark).
> {code:java}
> GET
> /kit/reflector?pageID=update.properties=UNKNOWN=ehcache-core+2.7.5=2.7.5=11=ehcache.default=12.0.2=Linux=-1408104395=ehcache-core=OpenJDK+64-Bit+Server+VM=amd64
> Host: www.terracotta.org
> User-Agent: Java/1.8.0_222
> {code}
> But from that side my archiva virtual machine gets only the subjected message.
> {code:java}
> The owner of this website (www.terracotta.org) has banned your access based
> on your browser's signature (521f0006ab85c286-ua21).
> {code}
> My first thought was, that this message would be generated, because Java8 is
> EOL. Also switched I my linux VM (opensuse tumbleweed) to java12, but get
> only a lot of Exceptions after restarting Archiva. That would not better
> after asking the big brother, downloading the following jars and adding the
> lines in the wrapper,conf.
> {code:java}
> wrapper.java.classpath.27=/home/archiva/jaxb-api-2.3.0.jar
> wrapper.java.classpath.28=/home/archiva/jaxb-core-2.3.0.jar
> wrapper.java.classpath.29=/home/archiva/jaxb-impl-2.3.0.jar
> {code}
> But nevertheless I get another user agent:
> {code:java}
> User-Agent: Java/12.0.2
> {code}
> and another bann message:
> {code:java}
> You don't have permission to access /kit/reflector on this server.
> {code}
> Exists a quick solution that my local Archiva could run (again), maybe
> without using _www.terracotta.org_?
> Thanks, cu.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MRM-2000) Missing/invalid NOTICE file
[ https://issues.apache.org/jira/browse/MRM-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer closed MRM-2000. --- After reading [http://www.apache.org/dev/licensing-howto.html] and [https://www.apache.org/legal/resolved.html], I think, the Apache NOTICE is sufficient. > Missing/invalid NOTICE file > --- > > Key: MRM-2000 > URL: https://issues.apache.org/jira/browse/MRM-2000 > Project: Archiva > Issue Type: Bug >Reporter: Sebb >Assignee: Martin Stockhammer >Priority: Critical > > There does not appear to be a NOTICE file alongside the LICENSE in the source > repo. > Since the source repos are public, they must have a NOTICE file. > The NOTICE file included in the Archiva 2.2.4 source release is not a > standard NOTICE file. > Please see > http://www.apache.org/dev/licensing-howto.html#simple > Likewise the NOTICE files in the binary and war downloads are non-compliant. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2000) Missing/invalid NOTICE file
[ https://issues.apache.org/jira/browse/MRM-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943838#comment-16943838 ] Martin Stockhammer commented on MRM-2000: - We do not have to change the released files, correct? > Missing/invalid NOTICE file > --- > > Key: MRM-2000 > URL: https://issues.apache.org/jira/browse/MRM-2000 > Project: Archiva > Issue Type: Bug >Reporter: Sebb >Assignee: Martin Stockhammer >Priority: Critical > > There does not appear to be a NOTICE file alongside the LICENSE in the source > repo. > Since the source repos are public, they must have a NOTICE file. > The NOTICE file included in the Archiva 2.2.4 source release is not a > standard NOTICE file. > Please see > http://www.apache.org/dev/licensing-howto.html#simple > Likewise the NOTICE files in the binary and war downloads are non-compliant. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-2000) Missing/invalid NOTICE file
[ https://issues.apache.org/jira/browse/MRM-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943836#comment-16943836 ] Martin Stockhammer commented on MRM-2000: - Added the simple NOTICE file with Apache license information. Trying to use the maven license plugin to find out, if there is other information that has to be added. > Missing/invalid NOTICE file > --- > > Key: MRM-2000 > URL: https://issues.apache.org/jira/browse/MRM-2000 > Project: Archiva > Issue Type: Bug >Reporter: Sebb >Assignee: Martin Stockhammer >Priority: Critical > > There does not appear to be a NOTICE file alongside the LICENSE in the source > repo. > Since the source repos are public, they must have a NOTICE file. > The NOTICE file included in the Archiva 2.2.4 source release is not a > standard NOTICE file. > Please see > http://www.apache.org/dev/licensing-howto.html#simple > Likewise the NOTICE files in the binary and war downloads are non-compliant. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRM-2002) Make Java Modules from archiva maven modules
Martin Stockhammer created MRM-2002: --- Summary: Make Java Modules from archiva maven modules Key: MRM-2002 URL: https://issues.apache.org/jira/browse/MRM-2002 Project: Archiva Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 3.0.0 We want to have proper Java Modules (Jigsaw) for each maven module that is created. * Find split packages * add module-info.java to each package * Try to separate public and internal APIs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRM-2001) Separate split packages into distinct ones
[ https://issues.apache.org/jira/browse/MRM-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2001: --- Assignee: Martin Stockhammer > Separate split packages into distinct ones > -- > > Key: MRM-2001 > URL: https://issues.apache.org/jira/browse/MRM-2001 > Project: Archiva > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > To prepare all archiva maven modules to be ready for Java module system > (Jigsaw), find all split packages and move them to distinct packages or > combine the modules. > Java module system does not allow the same package name in different modules. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRM-2001) Separate split packages into distinct ones
Martin Stockhammer created MRM-2001: --- Summary: Separate split packages into distinct ones Key: MRM-2001 URL: https://issues.apache.org/jira/browse/MRM-2001 Project: Archiva Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Martin Stockhammer Fix For: 3.0.0 To prepare all archiva maven modules to be ready for Java module system (Jigsaw), find all split packages and move them to distinct packages or combine the modules. Java module system does not allow the same package name in different modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRM-976) introduce an event API
[ https://issues.apache.org/jira/browse/MRM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943829#comment-16943829 ] Martin Stockhammer commented on MRM-976: There is now a event API in archiva-repository-api. Still some migration tasks to do: * Tests for EventManager * Currently AuditEvents are not part of the event API, they should be migrated * Build archiva specific configuration events and maybe remove dependency from commons configuration and spring-registry > introduce an event API > -- > > Key: MRM-976 > URL: https://issues.apache.org/jira/browse/MRM-976 > Project: Archiva > Issue Type: New Feature >Reporter: Brett Porter >Assignee: Martin Stockhammer >Priority: Major > Fix For: Backlog > > > it would be better for the current consumer api to migrate towards an event > api that can handle more than just database scan processing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRM-976) introduce an event API
[ https://issues.apache.org/jira/browse/MRM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-976: -- Assignee: Martin Stockhammer > introduce an event API > -- > > Key: MRM-976 > URL: https://issues.apache.org/jira/browse/MRM-976 > Project: Archiva > Issue Type: New Feature >Reporter: Brett Porter >Assignee: Martin Stockhammer >Priority: Major > Fix For: Backlog > > > it would be better for the current consumer api to migrate towards an event > api that can handle more than just database scan processing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRM-1951) Upgrade Apache Lucene to new version
[ https://issues.apache.org/jira/browse/MRM-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer closed MRM-1951. --- Resolution: Fixed We are using lucene version 4.10.4 now > Upgrade Apache Lucene to new version > > > Key: MRM-1951 > URL: https://issues.apache.org/jira/browse/MRM-1951 > Project: Archiva > Issue Type: Improvement >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > The used version 3.6.2 is far behind the current lucene version. > As far as I know the lucene API has changed with each major version, so code > must be adapted. > But I'm not sure what an upgrade means for compatibility of existing > repositories and indexes. Need some more investigation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRM-1959) Switch to JCR Oak to allow upgrade of lucene version
[ https://issues.apache.org/jira/browse/MRM-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer closed MRM-1959. --- Resolution: Fixed I think this is finished now. Tests are using retries and OAK is working fine. > Switch to JCR Oak to allow upgrade of lucene version > > > Key: MRM-1959 > URL: https://issues.apache.org/jira/browse/MRM-1959 > Project: Archiva > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > We are switching to JCR Oak that uses a higher lucene version. > But switching to Oak has some drawbacks: > - The repository format changed and we must provide a way to migrate (either > migrate the existing repository or create a new one by reindexing) > - The JCR oak is asynchronous. So there may be some timing issues that are > only visible at high load. > - Configuration changed significantly and not all is well documented > The incompatibility problem with the maven indexer that uses lucene in > another version is solved with the maven indexer 6 snapshot version that uses > now a shadowed lucene version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MRM-1975) Move archiva site (and redback) to gitbox
[ https://issues.apache.org/jira/browse/MRM-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer closed MRM-1975. --- Resolution: Fixed This is finished already > Move archiva site (and redback) to gitbox > - > > Key: MRM-1975 > URL: https://issues.apache.org/jira/browse/MRM-1975 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > Maybe too much effort, but we should check, what it means to move from the > svnpubsub to gitpubsub with gitbox. > Would be good, if we can publish in a separate directory without disturbing > the current archiva site. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRM-2000) Missing/invalid NOTICE file
[ https://issues.apache.org/jira/browse/MRM-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-2000: --- Assignee: Martin Stockhammer > Missing/invalid NOTICE file > --- > > Key: MRM-2000 > URL: https://issues.apache.org/jira/browse/MRM-2000 > Project: Archiva > Issue Type: Bug >Reporter: Sebb >Assignee: Martin Stockhammer >Priority: Critical > > There does not appear to be a NOTICE file alongside the LICENSE in the source > repo. > Since the source repos are public, they must have a NOTICE file. > The NOTICE file included in the Archiva 2.2.4 source release is not a > standard NOTICE file. > Please see > http://www.apache.org/dev/licensing-howto.html#simple > Likewise the NOTICE files in the binary and war downloads are non-compliant. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MRM-1998) Update dependencies in all modules
Martin Stockhammer created MRM-1998: --- Summary: Update dependencies in all modules Key: MRM-1998 URL: https://issues.apache.org/jira/browse/MRM-1998 Project: Archiva Issue Type: Improvement Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 3.0.0 After refactoring we have to clean up the dependencies in the pom.xml of each module. * maven-specific dependencies in compile scope should only be in maven-specific (groupID=org.apache.archiva.maven) modules. On all other modules these dependencies have to be removed. * Move transitive dependencies to explicit declaration, if there is code in the module that uses them. mvn dependency:analyze shows the transitive dependencies that are used by code. Don't do too much changes at the same time, which makes it difficult to track the cause for errors. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (MRM-1704) Refactor to remove maven specific part from various repository/metadata apis
[ https://issues.apache.org/jira/browse/MRM-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-1704: Fix Version/s: (was: 3.1.0) 3.0.0 > Refactor to remove maven specific part from various repository/metadata apis > > > Key: MRM-1704 > URL: https://issues.apache.org/jira/browse/MRM-1704 > Project: Archiva > Issue Type: Bug > Components: WebDAV Interface >Affects Versions: 1.4-M3 >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.0.0 > > > The goal is to able to create new repostories type. > The specific part will be moved to > org.apache.archiva.metadata.repository.storage.RepositoryStorage > Some part contains maven specific which need to be moved on maven2 modules. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (MRM-1704) Refactor to remove maven specific part from various repository/metadata apis
[ https://issues.apache.org/jira/browse/MRM-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer updated MRM-1704: Component/s: rest services repository scanning repository interface > Refactor to remove maven specific part from various repository/metadata apis > > > Key: MRM-1704 > URL: https://issues.apache.org/jira/browse/MRM-1704 > Project: Archiva > Issue Type: Bug > Components: repository interface, repository scanning, rest > services, WebDAV Interface >Affects Versions: 1.4-M3 >Reporter: Olivier Lamy (*$^¨%`£) >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Major > Fix For: 3.0.0 > > > The goal is to able to create new repostories type. > The specific part will be moved to > org.apache.archiva.metadata.repository.storage.RepositoryStorage > Some part contains maven specific which need to be moved on maven2 modules. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (MRM-1997) Create Swagger and OpenAPI Documentation for REST Interface and rework enunciate configuration.
Martin Stockhammer created MRM-1997: --- Summary: Create Swagger and OpenAPI Documentation for REST Interface and rework enunciate configuration. Key: MRM-1997 URL: https://issues.apache.org/jira/browse/MRM-1997 Project: Archiva Issue Type: Task Reporter: Martin Stockhammer Assignee: Martin Stockhammer Fix For: 3.0.0 Swagger/OpenAPI is currently the de facto standard for documenting REST interfaces. We should add it to our REST API documentation and maybe get rid of all the different languages and examples for the different languages in our REST documentation. enunciate seems to support swagger output so maybe this can be implemented without too much effort. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (MRM-1989) Compatibility with Java 11 and WildFly 16
[
https://issues.apache.org/jira/browse/MRM-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer closed MRM-1989.
---
Resolution: Fixed
Archiva uses JPA in the current master branch for 3.0.0. Build with JDK 11 is
part of our integration tests.
> Compatibility with Java 11 and WildFly 16
> -
>
> Key: MRM-1989
> URL: https://issues.apache.org/jira/browse/MRM-1989
> Project: Archiva
> Issue Type: Task
>Affects Versions: 2.2.4
>Reporter: Noël Vaes
>Priority: Major
> Fix For: 3.0.0
>
>
> Deployment of Archiva 2.2.4 (WAR) works on WildFly 16 and JDK 8
> It fails on WildFly 16 and JDK11.
> This is the error from the WildFly log with JDK11:
> {{ERROR [JPOX.RDBMS.Schema] (ServerService Thread Pool -- 80) Failed
> initialising database. Exception : The java type int (jdbc-type="",
> sql-type="") cant be mapped for this datastore. No mapping is available.}}
> {{javax.jdo.JDOFatalException: The java type int (jdbc-type="", sql-type="")
> cant be mapped for this datastore. No mapping is available.}}
>
> Since Java 11 is an LTS-release it might be a good idea to provide
> compatibility with Java 11 in the next major release.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MRM-1996) metadata.xml on maven central does not list version 2.2.4
[
https://issues.apache.org/jira/browse/MRM-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920352#comment-16920352
]
Martin Stockhammer commented on MRM-1996:
-
[~olamy] Thank you. Would have taken me some time to find out, that this is the
origin of the problem.
Just one question: I'm not sure, but shouldn't they have been uploaded by the
maven build? Or are the checksums created on the server only?
> metadata.xml on maven central does not list version 2.2.4
> -
>
> Key: MRM-1996
> URL: https://issues.apache.org/jira/browse/MRM-1996
> Project: Archiva
> Issue Type: Bug
> Components: Build
>Affects Versions: 2.2.4
>Reporter: Bruno Bossola
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
>
> On Maven Central repo (and mirrors) the
> [medatata.xml|http://repo1.maven.org/maven2/org/apache/archiva/archiva/maven-metadata.xml]
> does not list version 2.2.4 and marks 2.2.3 as "latest":
> {{}}
> {{ org.apache.archiva}}
> {{ archiva}}
> {{ }}
> {{ 2.2.3}}
> {{ 2.2.3}}
> {{ }}
> {{ 2.2.0}}
> {{ 2.2.1}}
> {{ 2.2.3}}
> {{ }}
> {{ 20150224110004}}
> {{ }}
> {{}}
> As you can see it appears to be last updated in 2015.
> Can this be fixed, please?
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MRM-1995) Verify Tests and build job with JDK11 in archiva version 3.0.0
[ https://issues.apache.org/jira/browse/MRM-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920351#comment-16920351 ] Martin Stockhammer commented on MRM-1995: - Opened question for AdoptOpenJDK installations on the build servers to have a proper reference version. > Verify Tests and build job with JDK11 in archiva version 3.0.0 > -- > > Key: MRM-1995 > URL: https://issues.apache.org/jira/browse/MRM-1995 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > Verify that 3.0.0 is running with JDK 11, which is a LTS version. > See MRM-1989 also as reference what is failing in 2.x. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MRM-1995) Verify Tests and build job with JDK11 in archiva version 3.0.0
[
https://issues.apache.org/jira/browse/MRM-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920350#comment-16920350
]
Martin Stockhammer commented on MRM-1995:
-
Cassandra 3.11 is currently not officially JDK11 ready. But tests are working.
Cassandra clean up process is throwing exceptions:
{{[CompactionExecutor:2] ERROR
org.apache.cassandra.io.util.MmappedSegmentedFile - Error while unmapping
segments}}
{{[INFO] java.lang.RuntimeException: java.lang.IllegalAccessException: class
org.apache.cassandra.io.util.FileUtils cannot access class
jdk.internal.ref.Cleaner (in module java.base) because module java.base does
not export jdk.internal.ref to unnamed module @25fa516f}}
{{[INFO] at org.apache.cassandra.io.util.FileUtils.clean(FileUtils.java:281)}}
{{[INFO] at
org.apache.cassandra.io.util.MmappedSegmentedFile.cleanup(MmappedSegmentedFile.java:102)}}
{{[INFO] at
org.apache.cassandra.io.sstable.SSTableReader.close(SSTableReader.java:385)}}
{{[INFO] at
org.apache.cassandra.io.util.FileUtils.closeQuietly(FileUtils.java:210)}}
{{[INFO] at
org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1104)}}
{{[INFO] at
org.apache.cassandra.db.DataTracker.removeOldSSTablesSize(DataTracker.java:388)}}
{{[INFO] at
org.apache.cassandra.db.DataTracker.postReplace(DataTracker.java:353)}}
{{[INFO] at org.apache.cassandra.db.DataTracker.replace(DataTracker.java:347)}}
{{[INFO] at
org.apache.cassandra.db.DataTracker.replaceCompactedSSTables(DataTracker.java:252)}}
{{[INFO] at
org.apache.cassandra.db.ColumnFamilyStore.replaceCompactedSSTables(ColumnFamilyStore.java:1078)}}
{{[INFO] at
org.apache.cassandra.db.compaction.CompactionTask.replaceCompactedSSTables(CompactionTask.java:296)}}
{{[INFO] at
org.apache.cassandra.db.compaction.CompactionTask.runWith(CompactionTask.java:242)}}
{{[INFO] at
org.apache.cassandra.io.util.DiskAwareRunnable.runMayThrow(DiskAwareRunnable.java:48)}}
{{[INFO] at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)}}
{{[INFO] at
org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)}}
{{[INFO] at
org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)}}
{{[INFO] at
org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:197)}}
{{[INFO] at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)}}
{{[INFO] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)}}
{{[INFO] at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
{{[INFO] at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
{{[INFO] at java.base/java.lang.Thread.run(Thread.java:834)}}
> Verify Tests and build job with JDK11 in archiva version 3.0.0
> --
>
> Key: MRM-1995
> URL: https://issues.apache.org/jira/browse/MRM-1995
> Project: Archiva
> Issue Type: Task
>Reporter: Martin Stockhammer
>Assignee: Martin Stockhammer
>Priority: Major
>
> Verify that 3.0.0 is running with JDK 11, which is a LTS version.
> See MRM-1989 also as reference what is failing in 2.x.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MRM-1995) Verify Tests and build job with JDK11 in archiva version 3.0.0
[ https://issues.apache.org/jira/browse/MRM-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920347#comment-16920347 ] Martin Stockhammer commented on MRM-1995: - Time precision changes. For metadata storage we are truncating to milliseconds because this is precision that the backends support. > Verify Tests and build job with JDK11 in archiva version 3.0.0 > -- > > Key: MRM-1995 > URL: https://issues.apache.org/jira/browse/MRM-1995 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > > Verify that 3.0.0 is running with JDK 11, which is a LTS version. > See MRM-1989 also as reference what is failing in 2.x. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (MRM-1995) Verify Tests and build job with JDK11 in archiva version 3.0.0
Martin Stockhammer created MRM-1995: --- Summary: Verify Tests and build job with JDK11 in archiva version 3.0.0 Key: MRM-1995 URL: https://issues.apache.org/jira/browse/MRM-1995 Project: Archiva Issue Type: Task Reporter: Martin Stockhammer Assignee: Martin Stockhammer Verify that 3.0.0 is running with JDK 11, which is a LTS version. See MRM-1989 also as reference what is failing in 2.x. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Closed] (MRM-1978) Compatibility with JDK 9
[ https://issues.apache.org/jira/browse/MRM-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer closed MRM-1978. --- Resolution: Won't Fix No JDK 9 testing, will focus on JDK 11 for 3.0.0. The 2.x branch will stick to JDK8 > Compatibility with JDK 9 > > > Key: MRM-1978 > URL: https://issues.apache.org/jira/browse/MRM-1978 > Project: Archiva > Issue Type: Task >Reporter: Martin Stockhammer >Assignee: Martin Stockhammer >Priority: Major > Fix For: 3.0.0 > > > Archiva, Redback and Redback components should be buildable and runnable with > JDK 9. > * Changes in maven config and dependencies neccessary? > * JDK 8 is still our main version for build and source, so after applying > changes we always have to test with JDK 8 > * Create additional tests in the pipeline for JDK 9 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (MRM-1990) Archiva deployment error
[
https://issues.apache.org/jira/browse/MRM-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer resolved MRM-1990.
-
Resolution: Cannot Reproduce
Cannot provide payara support. No matching environment to test this in detail.
> Archiva deployment error
>
>
> Key: MRM-1990
> URL: https://issues.apache.org/jira/browse/MRM-1990
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: Debian 9
> Payara 4.1.2
> Apache archiva 2.2.4
>Reporter: Vojtěch Dušátko
>Assignee: Martin Stockhammer
>Priority: Critical
> Labels: build, newbie
> Attachments: archiva.log
>
>
> Hello, I have a problem with deploying Archiva 2.2.\{3,4} into Payara server
> 4.1.2. It seems to be a CDI error.
> {code:java}
> remote failure: Error occurred during deployment: Exception while loading the
> app : java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'repositorySearch#maven' defined in URL
> [jar:file:/opt/payara/payara41/glassfish/domains/domain1/applications/apache-archiva-2.2.4/WEB-INF/lib/archiva-indexer-2.2.4.jar!/org/apache/archiva/indexer/search/MavenRepositorySearch.class]:
> Unsatisfied dependency expressed through constructor argument with index 0
> of type [org.apache.archiva.common.plexusbridge.PlexusSisuBridge]: : Error
> creating bean with name 'plexusSisuBridge': Invocation of init method failed;
> nested exception is java.lang.IncompatibleClassChangeError: Implementing
> class; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'plexusSisuBridge': Invocation of init method failed; nested
> exception is java.lang.IncompatibleClassChangeError: Implementing class.
> Please see server.log for more details.
> Command deploy failed.
> {code}
> Can anyone tell me where is the problem?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (MRM-1868) UI shows some artifacts as folders and can't see the artifact page
[ https://issues.apache.org/jira/browse/MRM-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915313#comment-16915313 ] Martin Stockhammer commented on MRM-1868: - What do you mean by 'inexistent versions'. Versions that were removed from the repository? How were they removed? I'm not sure, if I understand your problem. Do you want that non existent versions are still available? Are you sure, the artifacts you would like to see, do still exist on your repository? In your screenshot the folders are listed with both icons, so I really don't get what's the problem here. So please try to explain in more detail. Thank You Martin > UI shows some artifacts as folders and can't see the artifact page > -- > > Key: MRM-1868 > URL: https://issues.apache.org/jira/browse/MRM-1868 > Project: Archiva > Issue Type: Bug > Components: Web Interface >Affects Versions: 2.1.1 >Reporter: Carlos Sanchez >Assignee: Martin Stockhammer >Priority: Major > Attachments: Screenshot 2014-11-05 17.15.32.png > > > If you go to > https://archiva-repository.apache.org/archiva/index.html?request_lang=en#browse/org.apache.archiva > you'll see that there are some entries with the artifact icon (folder with > loupe) and some with the folder icon, when they are all artifacts. > Clicking on the folder one causes the UI to keep navigating through > inexistent versions, e.g. > https://archiva-repository.apache.org/archiva/index.html?request_lang=en#browse/org.apache.archiva.archiva-applet.1.3.10-SNAPSHOT > In this case the artifacts are duplicated, listed both as a folder and as an > artifact, but I have an Archiva instance where they only show as folders, so > I can't see the browse artifact page for those anymore -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (MRM-1868) UI shows some artifacts as folders and can't see the artifact page
[ https://issues.apache.org/jira/browse/MRM-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer reassigned MRM-1868: --- Assignee: Martin Stockhammer > UI shows some artifacts as folders and can't see the artifact page > -- > > Key: MRM-1868 > URL: https://issues.apache.org/jira/browse/MRM-1868 > Project: Archiva > Issue Type: Bug > Components: Web Interface >Affects Versions: 2.1.1 >Reporter: Carlos Sanchez >Assignee: Martin Stockhammer >Priority: Major > Attachments: Screenshot 2014-11-05 17.15.32.png > > > If you go to > https://archiva-repository.apache.org/archiva/index.html?request_lang=en#browse/org.apache.archiva > you'll see that there are some entries with the artifact icon (folder with > loupe) and some with the folder icon, when they are all artifacts. > Clicking on the folder one causes the UI to keep navigating through > inexistent versions, e.g. > https://archiva-repository.apache.org/archiva/index.html?request_lang=en#browse/org.apache.archiva.archiva-applet.1.3.10-SNAPSHOT > In this case the artifacts are duplicated, listed both as a folder and as an > artifact, but I have an Archiva instance where they only show as folders, so > I can't see the browse artifact page for those anymore -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MRM-1994) Connection to ldap (freeipa) not working on archiva 2.2.4
[
https://issues.apache.org/jira/browse/MRM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915310#comment-16915310
]
Martin Stockhammer commented on MRM-1994:
-
Hi Ravi,
the exception indicates that your basedn is not set properly. I think there
must be an exception in the log before the mentioned ldap error.
Please look for the string *{{LdapConnectionConfiguration}}* in your
archiva.log and maybe you can send me the LDAP part of your archiva.xml
(passwords removed).
Regards
Martin
> Connection to ldap (freeipa) not working on archiva 2.2.4
> -
>
> Key: MRM-1994
> URL: https://issues.apache.org/jira/browse/MRM-1994
> Project: Archiva
> Issue Type: Bug
> Components: Users/Security
>Affects Versions: 2.2.4
> Environment: OS:
> Description: Ubuntu 16.04.5 LTS
> Release: 16.04
> Codename: xenial
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
>Reporter: ravi
>Assignee: Martin Stockhammer
>Priority: Major
> Attachments: archiva_ldap_error.txt
>
>
> Specified the ldap properties on the users/ldap page in the following format
> (real names masked). When click "Verify Ldap Changes" it comes back saying
> "ldap connection verified". But when I click the "Verify LDAP configuration
> on server side", it throws a bunch of errors in the log and gives the error:
> "An error has happened you must contact the administrator to check the logs."
> Host: ldaphost.company.net
> port: 389
> Base dn: dc=company,dc=net
> Base dn for groups: cn=groups,cn=accounts,dc=company,dc=net
> bindDn: uid=user1,cn=users,cn=accounts,dc=company,dc=net
>
> I'm able to do an ldapsearch on the same host:
> ldapsearch -W -H ldap://ldaphost.company.net -b
> "cn=groups,cn=accounts,dc=company,dc=net" -D
> "uid=user1,cn=users,cn=accounts,dc=company,dc=net"
> (using the same password as put in the archiva ldap page)
>
> Some of the errors in the log: (complete error is attached).
> --
> 2019-08-22 17:21:17,411 [qtp1792496309-24] WARN
> org.apache.cxf.phase.PhaseInterceptorChain [] - Application
> {[http://services.rest.archiva.apache.org/]}DefaultPingService has thrown
> exception, unwinding now
> org.apache.cxf.interceptor.Fault: null
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:163)
> ~[cxf-core-3.0.3.jar:3.0.3]
> ...
> ...
> Caused by: java.lang.NullPointerException
> at
> org.apache.archiva.redback.common.ldap.connection.DefaultLdapConnection.(DefaultLdapConnection.java:59)
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (MRM-1994) Connection to ldap (freeipa) not working on archiva 2.2.4
[
https://issues.apache.org/jira/browse/MRM-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer reassigned MRM-1994:
---
Assignee: Martin Stockhammer
> Connection to ldap (freeipa) not working on archiva 2.2.4
> -
>
> Key: MRM-1994
> URL: https://issues.apache.org/jira/browse/MRM-1994
> Project: Archiva
> Issue Type: Bug
> Components: Users/Security
>Affects Versions: 2.2.4
> Environment: OS:
> Description: Ubuntu 16.04.5 LTS
> Release: 16.04
> Codename: xenial
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
>Reporter: ravi
>Assignee: Martin Stockhammer
>Priority: Major
> Attachments: archiva_ldap_error.txt
>
>
> Specified the ldap properties on the users/ldap page in the following format
> (real names masked). When click "Verify Ldap Changes" it comes back saying
> "ldap connection verified". But when I click the "Verify LDAP configuration
> on server side", it throws a bunch of errors in the log and gives the error:
> "An error has happened you must contact the administrator to check the logs."
> Host: ldaphost.company.net
> port: 389
> Base dn: dc=company,dc=net
> Base dn for groups: cn=groups,cn=accounts,dc=company,dc=net
> bindDn: uid=user1,cn=users,cn=accounts,dc=company,dc=net
>
> I'm able to do an ldapsearch on the same host:
> ldapsearch -W -H ldap://ldaphost.company.net -b
> "cn=groups,cn=accounts,dc=company,dc=net" -D
> "uid=user1,cn=users,cn=accounts,dc=company,dc=net"
> (using the same password as put in the archiva ldap page)
>
> Some of the errors in the log: (complete error is attached).
> --
> 2019-08-22 17:21:17,411 [qtp1792496309-24] WARN
> org.apache.cxf.phase.PhaseInterceptorChain [] - Application
> {[http://services.rest.archiva.apache.org/]}DefaultPingService has thrown
> exception, unwinding now
> org.apache.cxf.interceptor.Fault: null
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:163)
> ~[cxf-core-3.0.3.jar:3.0.3]
> ...
> ...
> Caused by: java.lang.NullPointerException
> at
> org.apache.archiva.redback.common.ldap.connection.DefaultLdapConnection.(DefaultLdapConnection.java:59)
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (MRM-1971) Problem to autenticate on LDAP
[ https://issues.apache.org/jira/browse/MRM-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911632#comment-16911632 ] Martin Stockhammer edited comment on MRM-1971 at 8/20/19 6:26 PM: -- Hi, there is no difference between the standalone and the WAR version regarding the LDAP access (if you use the same archiva version). Archiva uses the standard LDAP API from the JDK. There is either a difference in your configuration, or you have different JDKs. If this is the case, it would be helpful, if you can tell the exact versions of your JDKs used for standalone and WAR deployments. "user not found" is normally a issue from wrong LDAP configuration (wrong attributes for search, or base DN not correct, there are many parts in the configuration that have to match to your LDAP server) You can increase the log level to debug or trace and attach the relevant part for the login to this issue here. was (Author: effrafax): Hi, there is no difference between the standalone and the WAR version regarding the LDAP access (if you use the same archiva version). Archiva uses the standard LDAP API from the JDK. There is either a difference in your configuration you have different JDKs. If this is the case, it would be helpful, if you can tell the exact versions of your JDKs used for standalone and WAR deployments. "user not found" is normally a issue from wrong LDAP configuration (wrong attributes for search, or base DN not correct, there are many parts in the configuration that have to match to your LDAP server) You can increase the log level to debug or trace and attach the relevant part for the login to this issue here. > Problem to autenticate on LDAP > -- > > Key: MRM-1971 > URL: https://issues.apache.org/jira/browse/MRM-1971 > Project: Archiva > Issue Type: Question >Affects Versions: 2.2.3 > Environment: Ubuntu 16.04 >Reporter: Breiner Henrique >Assignee: Martin Stockhammer >Priority: Major > Attachments: archiva-general.png, archiva-ldap.png, > archiva-prop1.png, archiva-prop2.png > > > Hi, > I need to instalate some Apache Archiva Server and autenticate it on a LDAP > Server. > I made the instalation but i don't get to do the autenticate the server. > I'm using the web interface to configure, on > http://192.168.0.43:8070/#redbackruntimeconfig, on LDAP configuration, I put > the settings and I use the "Verify LDAP changes" and "Verify LDAP > configuration on the server side" and all it's ok. I saved the configuration > normaly but don't works. > On the tab LDAP/Roles Mapping, I cannot to see the groups from LDAP and the > login using any user don't works. > Can somebody help me? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MRM-1971) Problem to autenticate on LDAP
[ https://issues.apache.org/jira/browse/MRM-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911632#comment-16911632 ] Martin Stockhammer commented on MRM-1971: - Hi, there is no difference between the standalone and the WAR version regarding the LDAP access (if you use the same archiva version). Archiva uses the standard LDAP API from the JDK. There is either a difference in your configuration you have different JDKs. If this is the case, it would be helpful, if you can tell the exact versions of your JDKs used for standalone and WAR deployments. "user not found" is normally a issue from wrong LDAP configuration (wrong attributes for search, or base DN not correct, there are many parts in the configuration that have to match to your LDAP server) You can increase the log level to debug or trace and attach the relevant part for the login to this issue here. > Problem to autenticate on LDAP > -- > > Key: MRM-1971 > URL: https://issues.apache.org/jira/browse/MRM-1971 > Project: Archiva > Issue Type: Question >Affects Versions: 2.2.3 > Environment: Ubuntu 16.04 >Reporter: Breiner Henrique >Assignee: Martin Stockhammer >Priority: Major > Attachments: archiva-general.png, archiva-ldap.png, > archiva-prop1.png, archiva-prop2.png > > > Hi, > I need to instalate some Apache Archiva Server and autenticate it on a LDAP > Server. > I made the instalation but i don't get to do the autenticate the server. > I'm using the web interface to configure, on > http://192.168.0.43:8070/#redbackruntimeconfig, on LDAP configuration, I put > the settings and I use the "Verify LDAP changes" and "Verify LDAP > configuration on the server side" and all it's ok. I saved the configuration > normaly but don't works. > On the tab LDAP/Roles Mapping, I cannot to see the groups from LDAP and the > login using any user don't works. > Can somebody help me? -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MRM-1993) Invalid Namespace Handler
[ https://issues.apache.org/jira/browse/MRM-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894361#comment-16894361 ] Martin Stockhammer commented on MRM-1993: - Hi, thank you for this report, but we do not support JDK 11 for Archiva 2.2.x. You have to use JDK 8. Regards Martin > Invalid Namespace Handler > - > > Key: MRM-1993 > URL: https://issues.apache.org/jira/browse/MRM-1993 > Project: Archiva > Issue Type: Bug > Components: system >Affects Versions: 2.2.3, 2.2.4 > Environment: Ubuntu 18.04 LTS, Java OpenJDK 11.0.3 amd64 >Reporter: Christian H. Kuhn >Priority: Major > > Archiva installed in /usr/local/bin. Java Environment updated from Oracle 8 > to OpenJDK 11. > 2.2.3 worked before. After java update both former running 2.2.3 and a fresh > install of 2.2.4 do NOT work. Jetty starts and is listening on port 8081 as > configured in conf/jetty.xml but throws a 503 Problem accessing /. Reason: > Service Unavailable > In conf/jetty.xml, conf/wrapper.conf, bin/archiva, and > apps/archiva/WEB-INF/classes/log4j2.xml, the log path is set to > /var/log/archiva. In bin/archiva, RUN_AS_USER=archiva. No further changes. > First error in log: > [WrapperSimpleAppMain] ERROR org.springframework.web.context.ContextLoader [] > - Context initialization failed > org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected > exception parsing XML document from URL > [jar:file:/usr/local/bin/apache-archiva-2.2.4/apps/archiva/WEB-INF/lib/archiva-web-common-2.2.4.jar!/META-INF/spring-context.xml]; > nested exception is org.springframework.beans.FatalBeanException: Invalid > NamespaceHandler class [org.apache.cxf.jaxrs.spring.NamespaceHandler] for > namespace [http://cxf.apache.org/jaxrs]: problem with handler class file or > dependent class; nested exception is java.lang.NoClassDefFoundError: > javax/xml/bind/JAXBException at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414) > ~[spring-beans-4.2.1.RELEASE.jar:4.2.1.RELEASE] > [Complete log|http://www.qno.de/archiva.txt] > Looks as if something is not in the classpath. Java classpaths are set in > conf/wrapper.conf, but i don't enough about the needed classes; the > documentation tells nothing. How can i run archiva with Java 11? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (MRM-1993) Invalid Namespace Handler
[ https://issues.apache.org/jira/browse/MRM-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Stockhammer closed MRM-1993. --- Resolution: Won't Fix > Invalid Namespace Handler > - > > Key: MRM-1993 > URL: https://issues.apache.org/jira/browse/MRM-1993 > Project: Archiva > Issue Type: Bug > Components: system >Affects Versions: 2.2.3, 2.2.4 > Environment: Ubuntu 18.04 LTS, Java OpenJDK 11.0.3 amd64 >Reporter: Christian H. Kuhn >Priority: Major > > Archiva installed in /usr/local/bin. Java Environment updated from Oracle 8 > to OpenJDK 11. > 2.2.3 worked before. After java update both former running 2.2.3 and a fresh > install of 2.2.4 do NOT work. Jetty starts and is listening on port 8081 as > configured in conf/jetty.xml but throws a 503 Problem accessing /. Reason: > Service Unavailable > In conf/jetty.xml, conf/wrapper.conf, bin/archiva, and > apps/archiva/WEB-INF/classes/log4j2.xml, the log path is set to > /var/log/archiva. In bin/archiva, RUN_AS_USER=archiva. No further changes. > First error in log: > [WrapperSimpleAppMain] ERROR org.springframework.web.context.ContextLoader [] > - Context initialization failed > org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected > exception parsing XML document from URL > [jar:file:/usr/local/bin/apache-archiva-2.2.4/apps/archiva/WEB-INF/lib/archiva-web-common-2.2.4.jar!/META-INF/spring-context.xml]; > nested exception is org.springframework.beans.FatalBeanException: Invalid > NamespaceHandler class [org.apache.cxf.jaxrs.spring.NamespaceHandler] for > namespace [http://cxf.apache.org/jaxrs]: problem with handler class file or > dependent class; nested exception is java.lang.NoClassDefFoundError: > javax/xml/bind/JAXBException at > org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:414) > ~[spring-beans-4.2.1.RELEASE.jar:4.2.1.RELEASE] > [Complete log|http://www.qno.de/archiva.txt] > Looks as if something is not in the classpath. Java classpaths are set in > conf/wrapper.conf, but i don't enough about the needed classes; the > documentation tells nothing. How can i run archiva with Java 11? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (MRM-1990) Archiva deployment error
[
https://issues.apache.org/jira/browse/MRM-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864262#comment-16864262
]
Martin Stockhammer commented on MRM-1990:
-
Hi,
I cannot provide payara support here, I haven't used this application server
before. Just a hint here:
[https://stackoverflow.com/questions/38570837/how-to-activate-payara-class-loading-parameter-fish-payara-classloading-delegate]
[https://github.com/payara/Payara/issues/1249]
Looks like you have to add a glassfish deployment descriptor to the WAR file.
Greetings
Martin
> Archiva deployment error
>
>
> Key: MRM-1990
> URL: https://issues.apache.org/jira/browse/MRM-1990
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: Debian 9
> Payara 4.1.2
> Apache archiva 2.2.4
>Reporter: Vojtěch Dušátko
>Assignee: Martin Stockhammer
>Priority: Critical
> Labels: build, newbie
> Attachments: archiva.log
>
>
> Hello, I have a problem with deploying Archiva 2.2.\{3,4} into Payara server
> 4.1.2. It seems to be a CDI error.
> {code:java}
> remote failure: Error occurred during deployment: Exception while loading the
> app : java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'repositorySearch#maven' defined in URL
> [jar:file:/opt/payara/payara41/glassfish/domains/domain1/applications/apache-archiva-2.2.4/WEB-INF/lib/archiva-indexer-2.2.4.jar!/org/apache/archiva/indexer/search/MavenRepositorySearch.class]:
> Unsatisfied dependency expressed through constructor argument with index 0
> of type [org.apache.archiva.common.plexusbridge.PlexusSisuBridge]: : Error
> creating bean with name 'plexusSisuBridge': Invocation of init method failed;
> nested exception is java.lang.IncompatibleClassChangeError: Implementing
> class; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'plexusSisuBridge': Invocation of init method failed; nested
> exception is java.lang.IncompatibleClassChangeError: Implementing class.
> Please see server.log for more details.
> Command deploy failed.
> {code}
> Can anyone tell me where is the problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRM-1990) Archiva deployment error
[
https://issues.apache.org/jira/browse/MRM-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16862398#comment-16862398
]
Martin Stockhammer commented on MRM-1990:
-
Please try to disable classloading delegation (see the URL in my last comment):
To disable class loading delegation globally, you can set the system property
{{fish.payara.classloading.delegate}} to {{false}}
> Archiva deployment error
>
>
> Key: MRM-1990
> URL: https://issues.apache.org/jira/browse/MRM-1990
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: Debian 9
> Payara 4.1.2
> Apache archiva 2.2.4
>Reporter: Vojtěch Dušátko
>Assignee: Martin Stockhammer
>Priority: Critical
> Labels: build, newbie
> Attachments: archiva.log
>
>
> Hello, I have a problem with deploying Archiva 2.2.\{3,4} into Payara server
> 4.1.2. It seems to be a CDI error.
> {code:java}
> remote failure: Error occurred during deployment: Exception while loading the
> app : java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'repositorySearch#maven' defined in URL
> [jar:file:/opt/payara/payara41/glassfish/domains/domain1/applications/apache-archiva-2.2.4/WEB-INF/lib/archiva-indexer-2.2.4.jar!/org/apache/archiva/indexer/search/MavenRepositorySearch.class]:
> Unsatisfied dependency expressed through constructor argument with index 0
> of type [org.apache.archiva.common.plexusbridge.PlexusSisuBridge]: : Error
> creating bean with name 'plexusSisuBridge': Invocation of init method failed;
> nested exception is java.lang.IncompatibleClassChangeError: Implementing
> class; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'plexusSisuBridge': Invocation of init method failed; nested
> exception is java.lang.IncompatibleClassChangeError: Implementing class.
> Please see server.log for more details.
> Command deploy failed.
> {code}
> Can anyone tell me where is the problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRM-1990) Archiva deployment error
[
https://issues.apache.org/jira/browse/MRM-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861367#comment-16861367
]
Martin Stockhammer commented on MRM-1990:
-
Hi, I don't have a payara server here, but looking at the logfile it seems
there are incompatibilities with libraries that are used by archiva and are
provided by the payara server in a different version (either Google Guice or
ASM, not sure what exactly).
Would it be possible to disable classloading delegation on the payara server
either for archiva alone or globally?
https://docs.payara.fish/documentation/payara-server/classloading.html
> Archiva deployment error
>
>
> Key: MRM-1990
> URL: https://issues.apache.org/jira/browse/MRM-1990
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: Debian 9
> Payara 4.1.2
> Apache archiva 2.2.4
>Reporter: Vojtěch Dušátko
>Assignee: Martin Stockhammer
>Priority: Critical
> Labels: build, newbie
> Attachments: archiva.log
>
>
> Hello, I have a problem with deploying Archiva 2.2.\{3,4} into Payara server
> 4.1.2. It seems to be a CDI error.
> {code:java}
> remote failure: Error occurred during deployment: Exception while loading the
> app : java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'repositorySearch#maven' defined in URL
> [jar:file:/opt/payara/payara41/glassfish/domains/domain1/applications/apache-archiva-2.2.4/WEB-INF/lib/archiva-indexer-2.2.4.jar!/org/apache/archiva/indexer/search/MavenRepositorySearch.class]:
> Unsatisfied dependency expressed through constructor argument with index 0
> of type [org.apache.archiva.common.plexusbridge.PlexusSisuBridge]: : Error
> creating bean with name 'plexusSisuBridge': Invocation of init method failed;
> nested exception is java.lang.IncompatibleClassChangeError: Implementing
> class; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'plexusSisuBridge': Invocation of init method failed; nested
> exception is java.lang.IncompatibleClassChangeError: Implementing class.
> Please see server.log for more details.
> Command deploy failed.
> {code}
> Can anyone tell me where is the problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MRM-1990) Archiva deployment error
[
https://issues.apache.org/jira/browse/MRM-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Stockhammer reassigned MRM-1990:
---
Assignee: Martin Stockhammer
> Archiva deployment error
>
>
> Key: MRM-1990
> URL: https://issues.apache.org/jira/browse/MRM-1990
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: Debian 9
> Payara 4.1.2
> Apache archiva 2.2.4
>Reporter: Vojtěch Dušátko
>Assignee: Martin Stockhammer
>Priority: Critical
> Labels: build, newbie
>
> Hello, I have a problem with deploying Archiva 2.2.\{3,4} into Payara server
> 4.1.2. It seems to be a CDI error.
> {code:java}
> remote failure: Error occurred during deployment: Exception while loading the
> app : java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'repositorySearch#maven' defined in URL
> [jar:file:/opt/payara/payara41/glassfish/domains/domain1/applications/apache-archiva-2.2.4/WEB-INF/lib/archiva-indexer-2.2.4.jar!/org/apache/archiva/indexer/search/MavenRepositorySearch.class]:
> Unsatisfied dependency expressed through constructor argument with index 0
> of type [org.apache.archiva.common.plexusbridge.PlexusSisuBridge]: : Error
> creating bean with name 'plexusSisuBridge': Invocation of init method failed;
> nested exception is java.lang.IncompatibleClassChangeError: Implementing
> class; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'plexusSisuBridge': Invocation of init method failed; nested
> exception is java.lang.IncompatibleClassChangeError: Implementing class.
> Please see server.log for more details.
> Command deploy failed.
> {code}
> Can anyone tell me where is the problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRM-1990) Archiva deployment error
[
https://issues.apache.org/jira/browse/MRM-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861314#comment-16861314
]
Martin Stockhammer commented on MRM-1990:
-
Archiva standalone works with this JDK, so I think it has to do with the Payara
server. Is it possible for you to attach the archiva.log file?
Are there other applications running in the same payara server, or is archiva
the only one?
> Archiva deployment error
>
>
> Key: MRM-1990
> URL: https://issues.apache.org/jira/browse/MRM-1990
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: Debian 9
> Payara 4.1.2
> Apache archiva 2.2.4
>Reporter: Vojtěch Dušátko
>Priority: Critical
> Labels: build, newbie
>
> Hello, I have a problem with deploying Archiva 2.2.\{3,4} into Payara server
> 4.1.2. It seems to be a CDI error.
> {code:java}
> remote failure: Error occurred during deployment: Exception while loading the
> app : java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'repositorySearch#maven' defined in URL
> [jar:file:/opt/payara/payara41/glassfish/domains/domain1/applications/apache-archiva-2.2.4/WEB-INF/lib/archiva-indexer-2.2.4.jar!/org/apache/archiva/indexer/search/MavenRepositorySearch.class]:
> Unsatisfied dependency expressed through constructor argument with index 0
> of type [org.apache.archiva.common.plexusbridge.PlexusSisuBridge]: : Error
> creating bean with name 'plexusSisuBridge': Invocation of init method failed;
> nested exception is java.lang.IncompatibleClassChangeError: Implementing
> class; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'plexusSisuBridge': Invocation of init method failed; nested
> exception is java.lang.IncompatibleClassChangeError: Implementing class.
> Please see server.log for more details.
> Command deploy failed.
> {code}
> Can anyone tell me where is the problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRM-1990) Archiva deployment error
[
https://issues.apache.org/jira/browse/MRM-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861286#comment-16861286
]
Martin Stockhammer commented on MRM-1990:
-
Hi Vojtech, what JDK (version) do you use and which payara server version? I'm
not sure, if archiva was ever tested with Payara server.
> Archiva deployment error
>
>
> Key: MRM-1990
> URL: https://issues.apache.org/jira/browse/MRM-1990
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.4
> Environment: Debian 9
> Payara 4.1.2
> Apache archiva 2.2.4
>Reporter: Vojtěch Dušátko
>Priority: Critical
> Labels: build, newbie
>
> Hello, I have a problem with deploying Archiva 2.2.\{3,4} into Payara server
> 4.1.2. It seems to be a CDI error.
> {code:java}
> remote failure: Error occurred during deployment: Exception while loading the
> app : java.lang.IllegalStateException: ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'repositorySearch#maven' defined in URL
> [jar:file:/opt/payara/payara41/glassfish/domains/domain1/applications/apache-archiva-2.2.4/WEB-INF/lib/archiva-indexer-2.2.4.jar!/org/apache/archiva/indexer/search/MavenRepositorySearch.class]:
> Unsatisfied dependency expressed through constructor argument with index 0
> of type [org.apache.archiva.common.plexusbridge.PlexusSisuBridge]: : Error
> creating bean with name 'plexusSisuBridge': Invocation of init method failed;
> nested exception is java.lang.IncompatibleClassChangeError: Implementing
> class; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'plexusSisuBridge': Invocation of init method failed; nested
> exception is java.lang.IncompatibleClassChangeError: Implementing class.
> Please see server.log for more details.
> Command deploy failed.
> {code}
> Can anyone tell me where is the problem?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
