Number format in log entries make log files harder to use

mhoffmann

Given the simple snippet:

Ivy.log().warn("The current case with id #{0} is awesome!", ivyCase.getId());

does produce an output like:

The current case with id #1.337 is awesome!

I am a bit in awe why that's the case, after going through the source code, I found out that the logger in the end is just calling MessageFormat.format(formatedMessage,args) (API)

Since the caseId is a primitive long, the following subformat is applied: NumberFormat.getIntegerInstance(getLocale()).

By default, this will always lead to the string having thousands separators for every locale possible.

This cannot be easily bypassed with the current API in Axon Ivy, only circumvented by passing the caseId as String like:

Ivy.log().warn("The current case with id #{0} is awesome!", ""+ivyCase.getId());

However, since the default behaviour requires the person searching for a case or task id to add these thousands separators by hand, I think it's a doing more harm than good. It also adds a certain inconsistency to the display of the ids since they are displayed without the separators throughout the Portal.

I also must admit that in the past, I forgot about this constraint and was like "oh no, why is there no log entry?" - but in the end, I was just searching for the wrong String in a 50 MB logfile.

Since I think that I am not the only one stumbling upon this thing, I'd kindly ask to think about a refactoring of the
AdvancedMessage class to not rely on the JVM's default formatting but rather to enforce the non-formatted output of numbers.

Reto Weiss

Hi @mhoffmann

You can use the placeholder {0,number,#} instead of {0} to format the number as raw integer without delimiters. The # is the pattern documented in the class java.text.DecimalFormat.

Regards

mhoffmann

Hi Reto Weiss;

in fact I wasn't aware that passing a format like that is possible (new knowledge is always good, so thanks!), however, I think this bloats up the log patterns to a certain degree and I would argue that if I always have to set a specific pattern, it's the wrong approach for me.

I can fully understand that this is an almost developer-religious enquiry, but from a UX point of view, I don't think that the default is great:

You usually need log files to either evaluate whether everything works as intended (monitoring) or to evaluate a bug. And for the latter, the usual approach with customers is that they give us the ID of the case or task they had an issue with.

So with the common debug workflow, you open up the ivy.log, look for the case or task id. And given the fact that Axon Ivy doesn't even apply the format for the context output in the ivy.log, I cannot really understand the reason why the format is applied that way in a logger.

Thousands separators make only sense, if a human has to identify the numbers when reading them, but I doubt that most of the people read or monitor the log files in real time, because the output on a small to medium sized system is already too much when used somewhat frequently.

Don't get me wrong, my intention is just to make working with Axon Ivy easier for everyone, and I see that this a small, but annoying topic, at least for me.

Christian Strebel

Just a side note:
With version 11.1 and above we have introduced a better string based UUID. You get it with ITask.uuid() and ICase.uuid().

mhoffmann

Christian Strebel
Interesting! I just downloaded the newest LE designer to check out how the API might change and saw that we still have the CASEID as long and the UUID as varchar. The docs just state that the UUID should be used preferably, but doesn't indicate the reason why.

Given that an UUID looks like 36aa2922-aca4-4573-8817-842eb79b03b9 (which is 'just' 36 chars) and that those are worse regarding performance from what I know, the only reasons I can think of are: Overflow and the desire to not have an auto incremented primary key. But imagine being on a phone: "Hey, can you check the case {UUID here} for me?"

I think for changes like these, it's always good to give the developers the reason why; so they understand why it was changed and if the reasons for the change apply for any workflow one might have under his care.

Btw. what's the proper way to give feedback for the new designers, if you guys are interested? Since I think that the removal of the pop-up when inscribing anything in the BPMN will again take some time to get used to. First of all because I have to get used to a different position for the dialog to appear and then something like the data classes:

Axon Ivy 10:

Axon Ivy 11.2.1:

Anyway, this is off-topic for here, at least if we want to have a chat about it; I think the ability to popup the inscription mask should not be removed. I don't know what your plans are and since LE are only preview versions which are subject to change I don't know if this feedback is useful.

Christian Strebel

mhoffmann

You are right, the UUID issue is important. That is why I wrote a blog post about why we did it:
UUID vs traditional number-based ID

Lukas Lieb

Hi @mhoffmann

We are always interested in feedback from our internal as well as external developers. This is the reason why we publish our current work directly here in the community in the blog section.

According to the missing popup for the process element inscriptions. I know that removing this feature has some consequences for used developers, but you gain also benefits from it. And in the end, I think it is more or less only a reacclimatise to this new UI.
❌ You can no longer open multiple inscriptions beside each other
✅ The opening of the new inscriptions is a lot faster
✅ A single click is enough to change the inscription
✅ One inscription can be open per Process Editor (Editor can be detached into a separate window)

Besides that, for our future goal of a web technology-based Designer, it was needed to replace the old SWT-based inscription masks with a new implementation. And also even if it would be possible to open inscriptions in a dialog, we could not provide a similar behavior of such a dialog as before in the old SWT world.