Closed oheger-bosch closed 4 years ago
hm, seems like I have problems with the URL:
sam$ curl https://search.maven.org/remotecontent?filepath=org/apache/logging/log4j/log4j-api/2.7/log4j-api-2.7.jar
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
</body>
</html>
it could be rather (which is the redirect location):
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.7/log4j-api-2.7.jar
while I am on it now, suggesting also the other links:
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.7/log4j-core-2.7.jar
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-1.2-api/2.7/log4j-1.2-api-2.7.jar
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-jcl/2.7/log4j-jcl-2.7.jar
https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-slf4j-impl/2.7/log4j-slf4j-impl-2.7.jar
and for this URL does not redirect but does not work at all:
https://search.maven.org/remotecontent?filepath=org/apache/logging/log4j/log4j-impl/2.7/log4j-impl-2.7.jar
-> 404
I am not sure an impl package exists as artefact:
not at https://repo1.maven.org/maven2/org/apache/logging/log4j/ nor athttps://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.7/pom
since the impl package is not there; I have uploaded the rest of the packages, INCLUDING the core package. However, at startup there is:
2020-07-02 20:55:36.810 ERROR [CM Event Dispatcher (Fire ConfigurationEvent: pid=org.eclipse.sw360.portal.portlets.homepage.MySubscriptionsPortlet)][MySubscriptionsPortlet:93] bundle sw360-portlet:1.0.0 (1080)[org.eclipse.sw360.portal.portlets.homepage.MySubscriptionsPortlet(5338)] : Error during instantiation of the implementation object
java.lang.NoClassDefFoundError: Could not initialize class org.apache.logging.log4j.core.LoggerContext
@mcjaeger, thank you for testing.
Regarding the URL to the impl package, you are right. This is wrong and is also not needed (I don't know any more how I came across this URL).
The redirects can be resolved by curl automatically using the -L switch. This is handled by the downloadModule function in the prepare.sh script. I used the same convention for the URLs as was done for the other modules. But using the redirect URL directly will be slightly more efficient.
However, the error you report is probably more problematic. I did some searches, and the result is that it does not seem to be trivial to get log4j2 run in an OSGi environment. There are some solutions like a rather easy one as proposed in this StackOverflow post or more complex ones based on Pax Logging (e.g. this one). If you want me, I can dig a bit deeper into these proposed solutions to make this constellation work.
As an alternative, we might again consider the solution to use Slf4j as facade for the concrete logging framework and have different frameworks for the frontend and backend.
In any case, this logging topic seems to require more effort than I thought originally. I guess, it should not block the upcoming release of SW360; or WDYT?
This PR is no longer needed. SW360 now generates a module with the required logging dependencies itself.
This PR is related to https://github.com/eclipse/sw360/pull/878 against SW360, which changes the logging framework to Apache Log4j 2. To make the new dependencies available to the Liferay OSGi container, they have to be added as modules. Therefore, the script to prepare Liferay was extendend to download the required jar dependencies.