I don't know of any way to manage what you're describing in a useful manner. If you're desperate, the best suggestion I can make is to write something to unify the disparate formats under one umbrella and manage it there using your preferred logging format.
I don't think you can unify all of these easily, because you don't know what is being used by each framework.
If you identify which ones you are interested in then you can get each to output to log files in a central location /var/log/app (under linux for example). From here you could write a simple utility that parses each log file and massages the data into a single log file in the format that you want. The Awk utility is very good at doing this sort of thing.
Alternatively, you could leave them as they are - and use something like Splunk to index the files for future searching and analysis. It really depends on what you require from the log files at a later date. Hope that helps.
If and when they are using standard logging package, of course you can unify common parts ("INFO" prefix, timestamp, category name (usually class/package)). Just configure log4j / J.U.L / logback to your liking. I don't know why you would get different formats -- log formats are NOT configured by frameworks, but apps -- so maybe they are using different frameworks. But that may be accidental.
As to whether it matters; well, only if you process it automatically (trigger regex-based alarms).
The issue you have is that the applications are using different logging libraries. Jersey will use JUL, Spring will use commons-logging (which will in turn pick log4j if that's in your classpath), and Jetty uses its own logger. You can fix this by getting all your components to log through JUL.
First you need to get log4j off your classpath. Use exclusions or other mechanisms to ensure that log4j is not included. This will prevent commons-logging from picking log4j over JUL and get Spring to log in the same format as Jersey.
Next you'll need to configure Jetty to use commons-logging. You can find information about that on the Maven Jetty Plugin documentation page.
If your application code is using log4j directly, you'll need to switch to either commons-logging or JUL.
Maven I'm not so sure about, but it probably has a similar solution.
This is possible using the logback library and its bridges. It basically consists to remove any log4j commons or alike jars from the classpath, stick logback jar file and bridges jars for log4j and alike. Spring, jersey and maven will use the bridge factories to instantiate loggers which in turn will use logbak producing unified logging.
Check http://logback.qos.ch/ and http://www.slf4j.org/legacy.html
The key are the bridges which link other log utilities with a single global logger.
SLF4J allows you to consolidate logging by routing it into a single logging framework. You can redirect legacy logging calls made with commons-logging, java.util.logging and log4j as if they were made to SLF4J. See www.slf4j.org/legacy.html for details.
All logging will then be delegated to an underlying framework of your choice, for example logback, log4j, java.util.logging among others. If you run into trouble do contact the slf4j-user mailing list.
I think we will eventually need a "logging api" logging api that ties together all unified logging apis such as slf4j and whatever other ones they are. Who knows, you might need to change your logging framework that handles all types of logging one day...
Simply use http://logback.qos.ch/translator/ to convert the log4j.properties into xml format and paste that in logback.xml. This works as charm directing your log to appender configured.