I noticed that the localized message of a Level class from java.util.logging does not work on Java7. Looks like there is an issue with loading RessourceBundle for sun.util.logging.resources.logging
Let's consider following snippet
Locale.setDefault(Locale.GERMANY);
String msg = Level.SEVERE.getLocalizedName();
System.err.println(msg);
On java 6 it prints
SCHWERWIEGEND
On java 7 it prints
SEVERE
I read an article explaing that the Locale class was re-implemented in jdk7. Still, this seems to be werid. I also tried on Java 7 setting
Locale.setDefault(Category.DISPLAY, Locale.GERMANY);
then
Locale.setDefault(Category.FORMAT, Locale.GERMANY);
finally
System.setProperty("sun.locale.formatasdefault", "true");
but neither seem to work.
Is this a bug in the JVM or did I miss something?
This might be related to JDK-8028233. You can change the date format by specifying the a format string through the "java.util.logging.SimpleFormatter.format" system property or LogManager property.
Related
In our existing application we are using Esper Version 5.3.
We have added few addPlugInSingleRowFunction() to use it in EPL as below --
final Configuration cepConfiguration = new Configuration();
cepConfiguration.addPlugInSingleRowFunction("toNumber", Double.class.getName(), "parseDouble");
cepConfiguration.addPlugInSingleRowFunction("toBoolean", Boolean.class.getName(), "parseBoolean");
This was working fine in 5.3 version.
Post upgrading to 8.3 above code changed as per Esper documentation --
cepConfiguration.getCompiler().addPlugInSingleRowFunction("toNumber", Double.class.getName(), "parseDouble");
cepConfiguration.getCompiler().addPlugInSingleRowFunction("toBoolean", Boolean.class.getName(), "parseBoolean");
But once the sendEventBean() method is called to send a Event to runtime we are seeing below exception every time.
Surprisingly events are getting matched as per the statements present in runtime even if below exception are coming. Though we are not sure whether some events are not matching or not.
Can someone please help on this?
applog.cls=com.espertech.esper.common.internal.epl.expression.dot.core.ExprDotNodeForgeStaticMethodEval,applog.mthd=staticMethodEvalHandleInvocationException,applog.line=228,applog.msg=Invocation exception when invoking method 'parseDouble' of class 'java.lang.Double' passing parameters [null] for statement 'stmt-0': NullPointerException : null,exc.stack=java.lang.NullPointerException\n\tat sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1838)\n\tat sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)\n\tat java.lang.Double.parseDouble(Double.java:538)\n\tat generated.StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450.m8(StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450.java:161)\n\tat generated.StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450$2.get(ANONYMOUS.java:148)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterParamIndexEquals.matchEvent(FilterParamIndexEquals.java:32)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterHandleSetNode.matchEvent(FilterHandleSetNode.java:100)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.EventTypeIndex.matchType(EventTypeIndex.java:178)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.EventTypeIndex.matchEvent(EventTypeIndex.java:124)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterServiceBase.retryableMatchEvent(FilterServiceBase.java:179)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterServiceBase.evaluateInternal(FilterServiceBase.java:96)\n\tat com.espertech.esper.runtime.internal.filtersvcimpl.FilterServiceLockCoarse.evaluate(FilterServiceLockCoarse.java:52)\n\tat com.espertech.esper.runtime.internal.kernel.service.EPEventServiceImpl.processMatches(EPEventServiceImpl.java:610)\n\tat com.espertech.esper.runtime.internal.kernel.service.EPEventServiceImpl.processWrappedEvent(EPEventServiceImpl.java:450)\n\tat com.espertech.esper.runtime.internal.kernel.thread.InboundUnitSendEvent.run(InboundUnitSendEvent.java:43)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat java.lang.Thread.run(Thread.java:748)
You could turn on compiler logging (config.getCompiler().getLogging().setEnableCode(true);) and make sure you have INFO level logging. You can inspect "StatementAIFactoryProvider_a4bd241445010f45474e4598e34521ca1b2836db_stmt450.m8" at line 161 to see what the problem is. Sounds like a null value gets passed to Double.parseDouble. But since I don't have the complete code its hard to say.
I'm trying to fix errors which are reported by forbiddenapis. I had that line:
paramMap.put(Config.TITLEBOOST.toUpperCase(), titleBoost);
So, its been reported as error as usual. I've tried that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.getDefault()), titleBoost);
and that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.ROOT), titleBoost);
also that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.ENGLISH), titleBoost);
However none of them fixed the error:
[forbiddenapis] Forbidden method invocation:
java.lang.String#toUpperCase() [Uses default locale]
What I miss?
Double-check that the bytecode you are analyzing is actually your most recent build output, and that you're looking at the same line forbiddenapis is :) . This looks to me like your source/bytecode/analysis are falling out of sync — the relevant rule shouldn't flag an error on String.toUpperCase(Locale).
Disclaimer: I haven't used forbiddenapis myself --- I wrote this answer based on the repo and on a blog post I found.
I am using java logging in Groovy and I wanted to modify the format string so I only have one line instead of two, but the methods I tried didn't work - I looked at this question:
How do I get java logging output to appear on a single line?
I tried passing the property to groovy, but it didn't change the format.
I passed it like this:
groovy myScript.groovy -Djava.util.logging.SimpleFormatter.format=%1$tF %1$tT
but it doesn't look like it was picked up.
Here is what I did - I added this code to my groovy:
System.setProperty("java.util.logging.SimpleFormatter.format",
'%1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS %4$-6s %5$s%6$s%n');
Logger log = Logger.getLogger("")
FileHandler fh = new FileHandler("../log/replication.log")
log.addHandler(fh)
SimpleFormatter formatter = new SimpleFormatter()
fh.setFormatter(formatter)
which didn't require me to modify the java properties in command line (I didn't want to create additional script to start my groovy script).
You can use JAVA_OPTS for that. For example,
import java.util.logging.*
Logger log = Logger.getLogger('test')
log.setLevel(Level.INFO)
log.info('Test info log')
log.warning('Test warning')
log.config('Test config')
log.fine('Test fine')
and setting (i.e. below for windows):
set JAVA_OPTS="-Djava.util.logging.SimpleFormatter.format=%1$tF %1$tT [%4$s] %5$s %n"
Running the above sample script yields:
> groovy testLoggingJavaUtil.groovy
2015-03-27 17:35:48 [INFO] Test info log
2015-03-27 17:35:48 [WARNING] Test warning
Using Joda 2.1 in Java:
I have downloaded the latest timezone definitions 2013g, used ZoneInfoCompiler and have compiled those and moved them to my project's classpath.
I then call DateTimeZone.setProvider(new ZoneInfoProvider( "my-path-to-new-compiled-definitions" ) )
then when I try to instantiate new DateTime(DateTimeZone.forID("Asia/Jerusalem")) I get the time 1 hour backwards wrong.
It's as if compiling the new timezone definitions for joda and providing them has done nothing. However to test that it is actually using my new location, I tried executing DateTimeZone.forID("Asia/Khandyga") which did not exist in 2.1 and now retrieves and instantiates properly.
Ideas?
This question already has answers here:
How do I get java logging output to appear on a single line?
(10 answers)
java.util.logging: how to suppress date line
(3 answers)
Closed 4 years ago.
I'm using the Java default logger, and right now it's printing a lot of useless trash to the output, here is a example, this line of code:
log.info("Logging pointless information...")
Will output all of this:
Oct 26, 2011 9:37:57 PM java.util.logging.LogManager$RootLogger log
INFO: Logging pointless information...
I don't need to know anything except that second line. How can I remove this trash? All I want is simple text logging.
Maybe this was added later, but at least with Java 7, java.util.logging.SimpleFormatter supports getting its format from a system property. This JVM argument will print just the second line:
-Djava.util.logging.SimpleFormatter.format='%4$s: %5$s%6$s%n'
Personally, I like to keep all the date/source info, but get rid of the newline (and use a more compact, international date format):
-Djava.util.logging.SimpleFormatter.format='%1$tY-%1$tm-%1$td %1$tH:%1$tM:%1$tS %4$s %2$s %5$s%6$s%n'
You need to create a a different Formatter and use it instead.
public class BriefFormatter extends Formatter
{
public BriefFormatter() { super(); }
#Override
public String format(final LogRecord record)
{
return record.getMessage();
}
}
These are asking pretty much the same question:
How do I get java logging output to appear on a single line?
java.util.logging: how to suppress date line
Here's an example of how to implement Jarrod Roberson's suggestion: http://www.javalobby.org/java/forums/t18515.html
In general, to apply a formatter you create a file, usually called logging.properties. In it put a line like this:
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
or whatever your formatter class is. Then add a JVM arg like this:
-Djava.util.logging.config.file=logging.properties
Or use a more powerful logging system, like Logback or Log4j, which have prebuilt formatters to save you some coding.