John Farrel

For anyone who cares;

I found a setting that can alter the amount of time allocated to allow threads to shutdown before they are killed off during the shutdown process.
I thread that is still running after the period set is still going to be killed off, but that's probably for the best.

  @Bean    public DefaultLifecycleProcessor lifecycleProcessor()    {        DefaultLifecycleProcessor processor = new DefaultLifecycleProcessor();        processor.setTimeoutPerShutdownPhase(lifecycleTimeoutSecs * 1000);        return processor;    }

How do I configure a Spring Boot app executing concurrent JMSListener processes so that it waits for all running processes to complete before it shuts down?

I am trying to find a way to log the messages being received via JMS inside a Spring Boot project using artemis, logging with log4j2.

Logging org.apache.activemq.artemis.jms at any level increases the amount of logging but doesn't put the message body to the log.

So I seem to have found a workaround to the problem.

After Spring has finished starting up, I call into log4j2 to reset configuration, including clearing out currently detected plugins.

import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.core.LoggerContext; import org.apache.logging.log4j.core.config.plugins.util.PluginRegistry; ... PluginRegistry.getInstance().clear(); PluginRegistry.getInstance().loadFromMainClassLoader(); ((LoggerContext) LogManager.getContext(false)).reconfigure();

This is continuing on with an issue I have been having.

I have an Eclipse/Jetty/Spring project.
I have written a custom Log4j2 appender for it.

The only way I can currently get the appender to be triggered is if I:
* remove packages="<package path>" from the log4j2 configuration xml tag.
* add a call to PluginRegistry.getInstance().loadFromPackage("<package path>") to be called after Spring has completed start up.
* add packages="<package path>" back to the log4j2 configuration XML, causing a refresh of configuration.

Looking into the Log4j2 code as the project starts up, it appears that at the time of the initial configuration of the PluginRegistry, it cannot see the annotated custom appender class, but after Spring startup, it can.
If the packages setting is set at startup, the plugin registry remembers the package and associated plugins and attempting to reload it later just returns the initial set of plugins (In this case, package with no plugins).
So the post-start-up call correctly finds the annotated plugin class in the package, because it wasn't looking for it at startup. But only forcing reconfiguration by altering the configuration xml allow it to start working.

I have a similar problem with Log4j2Plugins.dat. I have generated the file and added it to the resources with appropriate directory (META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat)
but on initial startup the classloader can't find it as a resource, and there is no way to force Log4j2 to reload the .dat files later.

So my working theory is that the resources I want Log4j2 to find aren't available initially because of how Jetty and/or Spring starts up, maybe?

I have created a custom appender as per https://www.baeldung.com/log4j2-custom-appender
which is working.

However, I would like to ensure the appender has as little impact on the system as possible, and would like it to be asynchronous.

How would I ensure this? The class extends AbstractAppender, and it doesn't appear you can extend an AsynchAppender.

For those that care, I still get an error on startup about not finding the appender, but the appender is getting called.

I've generated a Log4j2Plugins.dat file, and put it in a resources directory.
On startup, I still get the error messages, but later the appender does get called. Not ideal, but a step forward.

I upgraded to log4j2 2.13.0, same problem.

I am trying to write a custom appender for log4j2, but I can't get it detected at runtime.

The class is:
package test.transaction; import java.io.Serializable; import org.apache.logging.log4j.core.Filter; import org.apache.logging.log4j.core.Layout; import org.apache.logging.log4j.core.LogEvent; import org.apache.logging.log4j.core.appender.AbstractAppender; import org.apache.logging.log4j.core.config.plugins.Plugin; import org.apache.logging.log4j.core.config.plugins.PluginAttribute; import org.apache.logging.log4j.core.config.plugins.PluginElement; import org.apache.logging.log4j.core.config.plugins.PluginFactory; @Plugin(name = "TransactionTrackingAppender",        category = "Core",        elementType = "appender",        printObject = true) public class TransactionTrackingAppender extends AbstractAppender {        private static final TransactionTracker TRACKER = new TransactionTracker();      protected TransactionTrackingAppender(String name, Filter filter, final Layout<? extends Serializable> layout)    {        super(name, filter, layout);    }    @PluginFactory    public static TransactionTrackingAppender createAppender(      @PluginAttribute("name") String name,      @PluginElement("Layout") Layout layout,      @PluginElement("Filters") Filter filter)    {        return new TransactionTrackingAppender(name, filter, layout);    }    @Override    public void append(LogEvent event)    {        TRACKER.addTransactionEvent(new TransactionEvent(event));    } }

in my log4j.xml file I have


<?xml version="1.0" encoding="UTF-8"?> <Configuration monitorInterval="10" packages="test.transaction">    <Appenders>            <TransactionTrackingAppender name="TRANSACTION_TRACKER">             <PatternLayout pattern="%tid:%t:%m" />        </TransactionTrackingAppender>    </Appenders>         ....    <Loggers>            <Logger name="org.springframework.transaction.interceptor" level="trace">            <AppenderRef ref="TRANSACTION_TRACKER" />        </Logger>   </Loggers>

on startup, I get this:

020-02-21 08:10:25,861 main ERROR Error processing element TransactionTrackingAppender ([Appenders: null]): CLASS_NOT_FOUND 2020-02-21 08:10:26,072 main ERROR Unable to locate appender "TRANSACTION_TRACKER" for logger config "org.springframework.transaction.interceptor"

I am running log4j2 version 2.11.1

Any ideas? Most issues reported like this tell me to set the Configuration/packages setting, but I've done that and it makes no difference.

Solved it myself... I implemented a org.hibernate.resource.jdbc.spi.StatementInspector class, configured hibernate.session_factory.statement_inspector to point to the class, and wrote code:

public class AddContextStatementInspector implements StatementInspector {    @Override    public String inspect(String sql)    {        String fullStackTrace = ExceptionUtils.getStackTrace(new Throwable());        return "/* " + fullStackTrace + "*/\n"                + sql;    } }

I am wondering if there is any way to make Hibernate add comments to it's DB calls to include the code calling context, like an embedded stack trace.
We have locks on hibernate-generated code but it's difficult to map them back to the code.

bump

Has anyone created or used a Java OMAPI api? I have been attempting to get omapi-dhcp to work, and it appears to authenticate correctly but an operation I do in it returns an error code ("393227").
The dhcp server I am attempting to converse with works from a linux machine through omshell with no issues.

I have a design question...

Imagine you have an entry in a table and want to write a web method to update the entry.

The simplest version of this is supplying a web method with a parameter for each column, and updating each associated column in the row with the value received.

This is fine, assuming you also have a web method to return EVERY value in the row, and that you expect EVERY value to be sent in the update.

The question, how to create a request to update just some of the columns?

If your soap engine fills in a java object from the request, you could ensure all fields are objects and only update those columns in the row where the objects are not null.

The problems are that depending on the soap engine.
On receipt of the request,
a <param></param> tag may map to either an empty string or a null.
a <param></param> tag mapped to a Integer or similar may map to 0 and not null.

On the engine creating the request, similar mapping issues occur. Will a null object map to an empty tag or no tag?

Looking for a clean and elegant solution.