Can anyone give an example of pom.xml dependencies configuration that will make OpenEJB to use slf4j logging, instead of JCL (this is what it uses now, as I understand).
see also How to configure OpenEJB logging?
We have support for:
Log4j
java.uti.logging
New implementations of LogStreamFactory can be plugged in by setting the class name as the value of openejb.log.factory system property.
Feel free to copy one of the existing impls and update for either JCL or SLF4J. The project is always accepting new committers if you get the urge to hack on other things as well!
Thanks to David's pointers, this is actually quite easy. You only need to implement two clases:
- Slf4jLogStreamFactory
- Slf4jLogStream
then set your factory :
System.setProperty("openejb.log.factory", "de.glauche.Slf4jLogStreamFactory");
package de.glauche;
import org.apache.openejb.util.LogCategory;
import org.apache.openejb.util.LogStream;
import org.apache.openejb.util.LogStreamFactory;
public class Slf4jLogStreamFactory implements LogStreamFactory {
#Override
public LogStream createLogStream(LogCategory logCategory) {
return new Slf4jLogStream(logCategory);
}
}
and the Slf4jLogStream:
package de.glauche;
import org.apache.openejb.util.LogCategory;
import org.apache.openejb.util.LogStream;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Slf4jLogStream implements LogStream {
private Logger log;
public Slf4jLogStream(LogCategory logCategory) {
log = LoggerFactory.getLogger(logCategory.getName());
}
#Override
public boolean isFatalEnabled() {
return log.isErrorEnabled();
}
#Override
public void fatal(String message) {
log.error(message);
}
#Override
public void fatal(String message, Throwable t) {
log.error(message,t);
}
... (overwrite the remaining methods like this)
With this i'm getting all output nicely formated in my logback logger via slf4j :)
This is how I made OpenEJB to use external logging:
[...]
#Before
public void before() throws Exception {
System.setProperty("openejb.logger.external", "true");
InitialContext ctx = new InitialContext();
}
[...]
Maybe it's possible to move this system property to some global resource, like pom.xml?
If you add the API and JCL dependencies then your logging using the SLF4J API will get directed to the default JCL logs.
Is that what you want? Or do you want to use some other back end for the logging?
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.1</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jcl</artifactId>
<version>1.6.1</version>
</dependency>
</dependencies>
Not a Maven expert, but from my understanding, you want this:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.6.1</version>
</dependency>
If OpenEJB doesn't support JCL, it would be pointless to add that dependency, so go with JUL or Log4j.
You can find more details at Maven repository.
Just in case you really want to use JCL bridge, use this:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.6.1</version>
</dependency>
If you are executing via Maven's exec plugin, try this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<configuration>
<mainClass>your Mainclass here</mainClass>
<systemProperties>
<systemProperty>
<key>openejb.log.factory</key>
<value>slf4j</value>
</systemProperty>
</systemProperties>
</configuration>
</plugin>
Related
I have existing project with very standart Logback implementation.
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
class SomeClass{
Logger log = LoggerFactory.getLogger(getClass());
void someMethod(){
log.info("some log message");
}
}
This is used in many places and in code I dont have sources. ch.qos.logback.classic.Logger is used as implementation.
I want to use my own implementation of Logger (I wanted to extend ch.qos.logback.classic.Logger but it's final) and use it applicatio wide without modifying the code (which I don't have anyway).
I would expect that configuration of LoggerFactory in logback.xml would be possible, but it doesn't seem so.
I'm using maven artifacts
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.30</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
</dependency>
I could not find straight way of doing it. I came over XLogger and logback-ext but it seems I would need to modify all factory usages.
I spent a whole day trying to find why this does not work so I think it might be useful if I share the question and the answer.
The Resilience4j library provides an elegant annotation-based solution from Spring Boot 2. All you need to do is just annotate a method (or a class) with one of the provided annotations, such as #CircuitBreaker, #Retry, #RateLimiter, #Bulkhead, #Thread and the appropriate resilience pattern is automagically added.
I added the expected dependency to the Maven pom.xml:
<dependency>
<groupId>io.github.resilience4j</groupId>
<artifactId>resilience4j-spring-boot2</artifactId>
<version>${resilience4j.version}</version>
</dependency>
Now the compiler is happy, so I can add the annotations:
...
import org.springframework.stereotype.Service;
import io.github.resilience4j.retry.annotation.Retry;
...
#Service
public class MyService {
...
#Retry(name = "get-response")
public MyResponse getResponse(MyRequest request) {
...
}
}
The program compiles, runs, however the annotations are completely ignored.
According to the resilience4j-spring-boot2 documentation:
The module expects that spring-boot-starter-actuator and spring-boot-starter-aop are already provided at runtime.
So the whole trick is to add also the missing dependencies to the Maven pom.xml:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-aop</artifactId>
</dependency>
My project builds successfully with groovy-eclipse-compiler, but fails without groovy-eclipse-compiler (using just javac). The build fails with an error message as given below (reported in a test class, while mocking an invocation)
java: reference to getFileResource is ambiguous
In order to debug the issue, I created a project with minimal files (given below). Though in project we have groovy source also, but I have not included them here to keep the code minimal.
The code is also pushed to git and is available at https://github.com/kaushalkumar/project-debug
My Doubt: The reported issue looks to be legitimate and I feel that groovy-eclipse-compiler must also fail, but it seems that the error is ignored. I am trying to understand what make groovy compiler to ignore it. Is it an issue in groovy compiler?
src/main/java/pkg1/IStrategy.java
package pkg1;
import java.util.Map;
public interface IStrategy {
Map<String, Object> getEnvMap();
}
src/main/java/pkg1/SharedResourceHelper.java
package pkg1;
import java.io.File;
import java.io.IOException;
import java.util.Map;
public class SharedResourceHelper {
public static File getFileResource(final String resourceName, final IStrategy strategy) throws IOException {
return getFileResource(resourceName, strategy.getEnvMap());
}
public static File getFileResource(final String resourceName, final Map<String, Object> envConfig) throws IOException {
return null;
}
}
src/test/java/pkg1/StrategyTest.java
package pkg1;
import pkg1.SharedResourceHelper;
import org.easymock.EasyMock;
import org.powermock.api.easymock.PowerMock;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.junit.Test;
import org.powermock.modules.junit4.PowerMockRunner;
import org.junit.runner.RunWith;
import java.io.File;
#PrepareForTest({SharedResourceHelper.class})
#RunWith(PowerMockRunner.class)
public class StrategyTest {
#Test
#PrepareForTest({SharedResourceHelper.class})
public void testGetFileResource() throws Exception {
PowerMock.mockStatic(SharedResourceHelper.class);
EasyMock.expect(SharedResourceHelper.getFileResource(EasyMock.anyString(), EasyMock.anyObject())).andReturn(File.createTempFile("tmp", "s"));
// EasyMock.expect(SharedResourceHelper.getFileResource("test", null)).andReturn(File.createTempFile("tmp", "s"));
}
}
/pom.xml
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>project.debug</groupId>
<artifactId>project</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-api-easymock</artifactId>
<version>2.0.7</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4</artifactId>
<version>2.0.7</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<source>1.8</source>
<target>1.8</target>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.9.2-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.4.3-01</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>
Java version - 1.8.0_231
Maven - 3.6.2
OS - Mac 10.15.6
groovy-eclipse-compiler - 2.9.2-01
groovy-eclipse-batch - 2.4.3-01
You reference "SharedResourceHelper.getFileResource(EasyMock.anyString(), EasyMock.anyObject())" is indeed ambiguous. If you add a typecast before "EasyMock.anyObject()" you could disambiguate. And EasyMock probably provides an "any" method that you can pass a type into as well.
groovy-eclipse-compiler is based upon ecj (eclipse compiler for java) and not javac, so there are bound to be differences. It may also be that ecj has a different default error/warning level for this particular case. If you feel this should be an error, you can file a JDT bug at bugs.eclipse.org.
eric-milles gave some direction to further explore this. His input is available at https://github.com/groovy/groovy-eclipse/issues/1157.
Based on his comment, we explored the history of https://github.com/groovy/groovy-eclipse/blob/master/extras/groovy-eclipse-batch-builder/build.properties and found that the compilation issue was between 2.4.12-01 (compilation works) and 2.4.12-02 (compilation breaks- as expected), which was part of release 2.9.2.
The change happened on Aug 10, 2017 (13c1c2a#diff-c8c111c3afb6080ae6b32148caaf6a0a), with comment as "Remove codehaus references". The jdt.patch.target was targeted for e44 which is Luna. This was same for both the files.
I invested some time in exploring https://github.com/eclipse/eclipse.jdt.core, to figure out how compiler behaviour could have altered, but could not get much. Though I am not very sure, but I feel that change in groovy-eclipse-batch (between 2.4.12-01 and 2.4.12-02) might be the cause of this.
Having invested this much time, I feel that it is not worth to further debug on this to figure out the root cause as the issue is already fixed in next version(s) [2.4.12-02 and beyond].
I am trying to test out some code that works with Java Doc, it is used under the maven-javadoc-plugin. I am trying to get it to work under jdk11. I am after an implementation of RootDoc which I can use when running tests.
Currently the tests use EasyDoclet which gives me a RootDoc like so:
EasyDoclet easyDoclet = new EasyDoclet(new File("dir"), "com.foo.bar");
RootDoc rootDoc = easyDoclet.getRootDoc()
However I could not get this to work under jdk11.
The first issue I had was tools.jar is missing so I changed my pom.xml to have:
<dependency>
<groupId>org.seamless</groupId>
<artifactId>seamless-javadoc</artifactId>
<version>1.1.1</version>
<exclusions>
<exclusion>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- maybe this will get what ever was in tools.jar -->
<dependency>
<groupId>com.github.olivergondza</groupId>
<artifactId>maven-jdk-tools-wrapper</artifactId>
<version>0.1</version>
</dependency>
This lead to many instances of:
java.lang.NoClassDefFoundError: com/sun/tools/javadoc/PublicMessager
The PublicMessager class seems to exist to make public some constructors, I am not sure why it exists under the com.sun.tools package. I tried to make a copy of this class:
public static class PublicMessager extends
com.sun.tools.javadoc.main.Messager {
public PublicMessager(Context context, String s) {
super(context, s);
}
public PublicMessager(Context context, String s, PrintWriter printWriter, PrintWriter printWriter1, PrintWriter printWriter2) {
super(context, s, printWriter, printWriter1, printWriter2);
}
}
And the error message changes to:
java.lang.IllegalAccessError: superclass access check failed: class com.fun.javadoc.FooBar$PublicMessager (in unnamed module #0x4abdb505) cannot access class com.sun.tools.javadoc.main.Messager (in module jdk.javadoc) because module jdk.javadoc does not export com.sun.tools.javadoc.main to unnamed module #0x4abdb50
I exposed jdk.javadoc to the unnamed module using:
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-Dfile.encoding=UTF-8</argLine>
<argLine>--add-opens=jdk.javadoc/com.sun.tools.javadoc.main=ALL-UNNAMED</argLine>
</configuration>
</plugin>
</plugins>
</build>
This meant that my custom version of PublicMessager would no longer have the errors shown however the version from seamless under com.sun.tools could not be found. I made my own version of EasyDoclet which used my PublicMessager however it turned out that the following two classes are missing:
import com.sun.tools.javadoc.JavadocTool;
import com.sun.tools.javadoc.ModifierFilter;
At this point I am not sure what to do. halp!
Perhaps an alternative would be to instead find the jdk11 equivalent of RootDoc which I think is DocletEnvironment and then some how get an implementation of that, I have no idea how to get an implementation of DocletEnvironment.
I am trying to change spring xml settings to pure code based setting.
So I read official documents and some posts from blogs.
e.g. http://docs.spring.io/spring-framework/docs/4.1.x/javadoc-api/org/springframework/web/WebApplicationInitializer.html
An I made a code like ...
public class TestInitializer implements WebApplicationInitializer {
#Override
public void onStartup(ServletContext container)
throws ServletException {
// TODO Auto-generated method stub
System.out.println("on Startup method has called.");
AnnotationConfigWebApplicationContext ctx = new AnnotationConfigWebApplicationContext();
ctx.register(RootConfig.class);
container.
//container.addListener(new ContextLoaderListener(ctx));
}
};
A problem here. In those pages, they use addListener(new ContextLoaderListener(ctx)) method to set context. However my eclipse can not find that method from container variable.
I do not know any clue why my container variable(javax.servlet.ServletContext instance) can not read this method.
Thanks for your answer:D
P.S.
My spring version is 4.1.6.RELEASE and I include servlet3.0, spring-context, spring-webmvc on pom.xml.
========================
Maybe I got some communication problem, So I summarize this :D
javax.servlet.ServletContext doc clearly state that it has method
addListener >>
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContext.html
have to use Spring WebApplicationInitializer.onStartup(ServletContext) to set basic setting via Java source code, not XML
Can not load addListener from ServletContext class.
=================================
Edit. This is not error on console. However it is the only message I got.
It is from eclipse toolkit.
The method addListener(ContextLoaderListener) is undefined for the type ServletContext
than recommendation is Add cast to 'container'
To follow up on what #JuneyoungOh has commented, turns out that the problem is because of conflicting dependency. And these are the ways to solve this problem :
* make version 3.0.1 and artifactId 'javax.servlet-api' or
* add tomcat(in my case 7.0) to project build path and remove servlet dependency.
In my case the problem was because of Spring-Support which is depended on "javax.servlet" and I just excluded it:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-support</artifactId>
<version>${spring-support.version}</version>
<exclusions>
<exclusion>
<artifactId>servlet-api</artifactId>
<groupId>javax.servlet</groupId>
</exclusion>
</exclusions>
</dependency>
In my case there was:
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
<scope>provided</scope>
</dependency>
notice, that artifactId is servlet-api, not javax.servlet-api.
I have created a legacy MVC project, that's why I had this package. When I tried to convert .xml configuration to Java, I came across this problem.
Certainly it's not the same as in the question, but it shows up as the first result in google search.
In my case I just had to comment out the javax.servlet:servlet-api dependency as depicted here:
<!-- dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency -->
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-core</artifactId>
<version>7.0.47</version>
</dependency>
This looks like the same idea presented here: https://stackoverflow.com/a/30231246/2597758