Recently upgraded from Spring-Boot 1.5.6.RELEASE to 1.5.8.RELEASE
On doing so, we noticed the environment was being logged out as "DEBUG" and category "StandardServletEnvironment".
However, the application.properties file does not specify logging at DEBUG level. Even explicitly setting a level of warning or error for that class does not make a difference.
The code that is doing the logging is in the constructor of org.springframework.core.env.AbstractEnvironment:
public AbstractEnvironment() {
customizePropertySources(this.propertySources);
if (logger.isDebugEnabled()) {
logger.debug("Initialized " + getClass().getSimpleName() + " with PropertySources " + this.propertySources);
}
}
Debug is not enabled, yet it logs. It seems as if it is doing this before it reads the log levels from application.properties.
Is there any explanation for this, or a way around this?
The application.properties has:
logging.level.root=INFO
logging.level.com.mycompany=DEBUG
In the code, I see a comment about logging initialization being deferred.
I managed to suppress this error by creating my own WebApplicationInitializer class, in which I explicitly set the offending log-category to a log-level of INFO
class MyWebApplicationInitializer implements WebApplicationInitializer{
#Override
void onStartup(ServletContext servletContext) throws ServletException {
String category = 'org.springframework.web.context.support.StandardServletEnvironment'
ch.qos.logback.classic.Logger logbackLogger = (ch.qos.logback.classic.Logger) org.slf4j.LoggerFactory.getLogger(category)
logbackLogger.setLevel(ch.qos.logback.classic.Level.INFO)
logbackLogger.info("Setting log level in ${this.class.name}, for ${logbackLogger.name}, to ${logbackLogger.level}")
}
It feels like a hack. So, if someone has a better answer, please post.
Related
A short rant at the beginning, just because it has to be said:
I'm getting tired of reading the terrible documentation of Log4j2 for the umpteenth time and still not finding any solutions for my problems. The documentation is completely outdated, sample code is torn uselessly out of a context that is needed but not explained further and the explanations are consistently insufficient. It shouldn't be that only Log4j2 developers can use Log4j2 in-depth. Frameworks should make the work of other developers easier, which is definitely not the case here. Period and thanks.
Now to my actual problem:
I have a Spring Boot application that is primarily configured with yaml files. The DataSource however is set programmatically so that we have a handle to its bean. Log4j2 is initially set up using yaml configuration as well.
log4j2-spring.yaml:
Configuration:
name: Default
status: warn
Appenders:
Console:
name: Console
target: SYSTEM_OUT
PatternLayout:
pattern: "%d{yyyy-MM-dd HH:mm:ss} %-5level [%t] %c: %msg%n"
Loggers:
Root:
level: warn
AppenderRef:
- ref: Console
Logger:
- name: com.example
level: debug
additivity: false
AppenderRef:
- ref: Console
What I want to do now is to extend this initial configuration programmatically with a JDBC Appender using the already existing connection-pool. According to the documentation, the following should be done:
The recommended approach for customizing a configuration is to extend one of the standard Configuration classes, override the setup method to first do super.setup() and then add the custom Appenders, Filters and LoggerConfigs to the configuration before it is registered for use.
So here is my custom Log4j2Configuration which extends YamlConfiguration:
public class Log4j2Configuration extends YamlConfiguration {
/* private final Log4j2ConnectionSource connectionSource; */ // <-- needs to get somehow injected
public Log4j2Configuration(LoggerContext loggerContext, ConfigurationSource configSource) {
super(loggerContext, configSource);
}
#Override
public void setup() {
super.setup();
}
#Override
protected void doConfigure() {
super.doConfigure();
LoggerContext context = (LoggerContext) LogManager.getContext(false);
Configuration config = context.getConfiguration();
ColumnConfig[] columns = new ColumnConfig[]{
//...
};
Appender jdbcAppender = JdbcAppender.newBuilder()
.setName("DataBase")
.setTableName("application_log")
// .setConnectionSource(connectionSource)
.setColumnConfigs(columns)
.build();
jdbcAppender.start();
config.addAppender(jdbcAppender);
AppenderRef ref = AppenderRef.createAppenderRef("DataBase", null, null);
AppenderRef[] refs = new AppenderRef[]{ref};
/* Deprecated, but still in the Log4j2 documentation */
LoggerConfig loggerConfig = LoggerConfig.createLogger(
false,
Level.TRACE,
"com.example",
"true",
refs,
null,
config,
null);
loggerConfig.addAppender(jdbcAppender, null, null);
config.addLogger("com.example", loggerConfig);
context.updateLoggers();
}
}
The ConnectionSource exists as an implementation of AbstractConnectionSource in the Spring context and still needs to be injected into the Log4j2Configuration class. Once I know how the configuration process works I can try to find a solution for this.
Log4j2ConnectionSource:
#Configuration
public class Log4j2ConnectionSource extends AbstractConnectionSource {
private final DataSource dataSource;
public Log4j2ConnectionSource(#Autowired #NotNull DataSource dataSource) {
this.dataSource = dataSource;
}
#Override
public Connection getConnection() throws SQLException {
return dataSource.getConnection();
}
}
And finally the ConfigurationFactory as described here in the documentation (It is interesting that the method getConfiguration calls with new MyXMLConfiguration(source, configFile) a constructor that doesn't exist. Is witchcraft at play here?).
Log4j2ConfigurationFactory:
#Order(50)
#Plugin(name = "Log4j2ConfigurationFactory", category = ConfigurationFactory.CATEGORY)
public class Log4j2ConfigurationFactory extends YamlConfigurationFactory {
#Override
public Configuration getConfiguration(LoggerContext context, ConfigurationSource configSource) {
return new Log4j2Configuration(context, configSource);
}
#Override
public String[] getSupportedTypes() {
return new String[]{".yml", "*"};
}
}
Now that the set up is more or less done, the running Log4j2 configuration needs somehow to be updated. So somebody should call doConfigure() within Log4j2Configuration. Log4j2 doesn't seem to do anything here on its own. Spring Boot doesn't do anything either. And I unfortunately don't have any plan what do at all.
Therefore my request:
Can anyone please explain to me how to get Log4j2 to update its configuration?
Many thanks for any help.
I've got this simple bean for PerformanceMonitorInterceptor
#Configuration
#EnableAspectJAutoProxy
#Aspect
public class PerfMetricsConfiguration {
/**
* Monitoring pointcut.
*/
#Pointcut("execution(* com.lapots.breed.judge.repository.*Repository.*(..))")
public void monitor() {
}
/**
* Creates instance of performance monitor interceptor.
* #return performance monitor interceptor
*/
#Bean
public PerformanceMonitorInterceptor performanceMonitorInterceptor() {
return new PerformanceMonitorInterceptor(true);
}
/**
* Creates instance of performance monitor advisor.
* #return performance monitor advisor
*/
#Bean
public Advisor performanceMonitorAdvisor() {
AspectJExpressionPointcut pointcut = new AspectJExpressionPointcut();
pointcut.setExpression("com.lapots.breed.judge.repository.PerfMetricsConfiguration.monitor()");
return new DefaultPointcutAdvisor(pointcut, performanceMonitorInterceptor());
}
}
It supposed to trace any method invocation in the interfaces that ends with Repository in name.
I set logging level in application.properties
logging.level.org.springframework.aop.interceptor.PerformanceMonitorInterceptor=TRACE
But during execution it doesn't write anything in the console. What's the problem?
I was facing similar issue, after changing the useDynamicLogger to false the issue was fixed.
#Bean
public PerformanceMonitorInterceptor performanceMonitorInterceptor() {
return new PerformanceMonitorInterceptor(false);
}
Faced with the same issue. And as Manzoor suggested passing false to PerformanceMonitorInterceptor solves the problem.
Why? When you call new PerformanceMonitorInterceptor(true), the logger name used inside of PerformanceMonitorInterceptor will be: com.lapots.breed.judge.repository.SomeClass.
So in your particular case the following logging configuration is required:
logging.level.com.lapots.breed.judge.repository=TRACE, otherwise you do not see any logs, the breakpoint on PerformanceMonitorInterceptor.invokeUnderTrace() will not work and you spend lot's of time thinking you have wrong AOP configuration (while actually it's fine), but you did not set up logging level for proper class/package.
I am using spring logging (SLF4J logging). Instead of putting PerformanceMonitorInterceptor logger to TRACE , I added com.lapots.breed.judge.repository logger to TRACE.
This started printing logs for me.
I did this because the below method in AbstractTraceInterceptor is looking for TRACE enabled on the class(Repository) we executing but not on PerformanceMonitorInterceptor.
protected boolean isLogEnabled(Log logger) {
return logger.isTraceEnabled();
}
I just tried this, I simply added this to application.properties and it works:
logging.level.org.springframework.aop.interceptor.PerformanceMonitorInterceptor=trace
I am upgrading Spring 2.5 to 4.2.
The issue is with one bean which has property type org.springframework.core.io.ClassPathResource. The resource value is defined in xml as p:location="classpath:/<the resource path>"
This worked perfect and bean property was populated with the resource. But in 4.2 the value is not getting set.
So I debugged the code and found that the class org.springframework.beans.BeanWrapperImpl was manipulating the value and removing classpath: string from actual value in Spring 2.5.
However the same is not true in 4.2 and class org.springframework.beans.BeanWrapperImpl isn't modifying the value which results in spring not finding the resource.
Anyone faced similar situation? What solution did you apply?
Thanks,
Hanumant
EDIT 1: code sample
spring config file
<bean class="com.test.sample.TestBean" id="testBean"
p:schemaLocation="classpath:/com/test/sample/Excalibur_combined.xsd" />
TestBean.java
public class TestBean {
private ClassPathResource schemaLocation;
public ClassPathResource getSchemaLocation() {
return schemaLocation;
}
public void setSchemaLocation(ClassPathResource schemaLocation) {
this.schemaLocation = schemaLocation;
}
}
App.java
public class App {
public static void main(String[] args) {
ApplicationContext ap = new ClassPathXmlApplicationContext("classpath:/com/test/sample/spring-config.xml");
TestBean tb = (TestBean) ap.getBean("testBean");
try {
URL url = tb.getSchemaLocation().getURL();
System.out.println(url);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
Error Message
INFO: Loading XML bean definitions from class path resource
[com/test/sample/spring-config.xml] java.io.FileNotFoundException:
class path resource
[classpath:/com/test/sample/Excalibur_combined.xsd] cannot be resolved
to URL because it does not exist at
org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:187)> at com.test.sample.App.main(App.java:20)
However if I remove the classpath: from bean definition it works.
So is classpth: necessary in bean definition xml file?? And why it was working fine in Spring 2.5??
The main issue is that you aren't programming to interfaces. Instead of the concrete org.springframework.core.io.ClassPathResource use org.springframework.core.io.Resource. When doing to the org.springframework.core.io.ResourceEditor will kick in and convert the String into a Resource instance. The location you are providing classpath:/<the resource path> will be passed to the ResourceLoader which will get the resource or throw an error if it doesn't exist.
If, however, you are using the concrete type ClassPathResouce directly this mechanism doesn't kick in and the location is set to what you provide classpath:/<the resource path>. However this is actually not a valid location for the URL class and that will eventually fail with the message you see.
It worked in earlier versions due to a hack/workaround/patch in the BeanWrapperImpl to strip the prefix.
Basically it now fails because you where doing things you shouldn't have been doing in the first place.
While using Jasypt in Spring the logger level in the load properties method of the PropertiesLoaderSupport class is set to Info
protected void loadProperties(Properties props) throws IOException {
if (this.locations != null) {
for (Resource location : this.locations) {
if (logger.isInfoEnabled()) {
logger.info("Loading properties file from " + location);
}
The above code block returns true while using Jasypt whereas it returns false with Spring due to while I get lot of unwanted log message.
Can somebody suggest how can I make it to return false through configurations .
I am using log4j for my application as well .
Thanks
I was able to find out the result after a lot of search ... To resolve this issue we have to set the Logger properties for Jasypt in the Logger configuration being used for the application . For example
name="log4j.logger.org.jasypt">ERROR
That will resolve the issue .
I have JAX-WS container-less service (published via Endpoint.publish() right from main() method). I want my service to validate input messages. I have tried following annotation: #SchemaValidation(handler=MyErrorHandler.class) and implemented an appropriate class. When I start the service, I get the following:
Exception in thread "main" javax.xml.ws.WebServiceException:
Annotation #com.sun.xml.internal.ws.developer.SchemaValidation(outbound=true,
inbound=true, handler=class mypackage.MyErrorHandler) is not recognizable,
atleast one constructor of class
com.sun.xml.internal.ws.developer.SchemaValidationFeature
should be marked with #FeatureConstructor
I have found few solutions on the internet, all of them imply the use of WebLogic container. I can't use container in my case, I need embedded service. Can I still use schema validation?
The #SchemaValidation annotation is not defined in the JAX-WS spec, but validation is left open. This means you need something more than only the classes in the jdk.
As long as you are able to add some jars to your classpath, you can set this up pretty easily using metro (which is also included in WebLogic. This is why you find solutions that use WebLogic as container.). To be more precise, you need to add two jars to your classpath. I'd suggest to
download the most recent metro release.
Unzip it somewhere.
Add the jaxb-api.jar and jaxws-api.jar to your classpath. You can do this for example by putting them into the JAVA_HOME/lib/endorsed or by manually adding them to your project. This largely depends on the IDE or whatever you are using.
Once you have done this, your MyErrorHandler should work even if it is deployed via Endpoint.publish(). At least I have this setup locally and it compiles and works.
If you are not able to modify your classpath and need validation, you will have to validate the request manually using JAXB.
Old question, but I solved the problem using the correct package and minimal configuration, as well using only provided services from WebLogic. I was hitting the same problem as you.
Just make sure you use correct java type as I described here.
As I am planning to expand to a tracking mechanism I also implemented the custom error handler.
Web Service with custom validation handler
import com.sun.xml.ws.developer.SchemaValidation;
#Stateless
#WebService(portName="ValidatedService")
#SchemaValidation(handler=MyValidator.class)
public class ValidatedService {
public ValidatedResponse operation(#WebParam(name = "ValidatedRequest") ValidatedRequest request) {
/* do business logic */
return response;
}
}
Custom Handler to log and store error in database
public class MyValidator extends ValidationErrorHandler{
private static java.util.logging.Logger log = LoggingHelper.getServerLogger();
#Override
public void warning(SAXParseException exception) throws SAXException {
handleException(exception);
}
#Override
public void error(SAXParseException exception) throws SAXException {
handleException(exception);
}
#Override
public void fatalError(SAXParseException exception) throws SAXException {
handleException(exception);
}
private void handleException(SAXParseException e) throws SAXException {
log.log(Level.SEVERE, "Validation error", e);
// Record in database for tracking etc
throw e;
}
}