Not that I'd recommend it, but you can effectively remove specific log messages by editing the text file <FME HOME>\\messages\\fmemessages.fms

Do not delete the line, rather just remove everything after the first comma, e.g.

You'll still get the final warning about "Further instances of this message will be suppressed", however, unless you remove that one as well -- which I'd really recommend against, as it's used in many different situations.

If you want to remove all WARN messages regardless of the contents, you can disable them in the FME Options.

Hi @david_r​,

thank you for your answer and this interesting hint.

The single specific log messages in the form of

2023-03-23 14:17:38|  1.9| 0.1|INFORM|AutoCAD Reader: Features for feature type '0' will be skipped based on the feature types requested

are ok for me, though, no need to remove them.

I wouldn't even mind if they would not be skipped after the 10th message of the same kind. Is there a setting such that the number after which the final warning is written might be increased from 10 to e.g. 100 messages of the same kind? That might be feasible solution for me as well.

Generally, I want to achieve my superordinate goal of the translation log showing 0 warnings at the end of a successful translation in a "clean" way, not by artificially suppressing reasonable WARN messages.

I mean, since I configured in the FeatureReader that I am only interested in features of a specific layer/a specific feature type, in my opinion, there is no need for the FeatureReader to spam the log with information about that the features of all these other feature types are skipped and finally even create a WARN message because there are so many skipped feature types.

It is even totally unnecessary because I explicitly configured the FeatureReader this way and am fully aware of it, and it prevents me from designing a "clean" workspace with 0 warnings (which should be the goal for a workspace designer, right? I see it as analogous to writing code with 0 code smells.). At least, it should be made configurable if the FeatureReader should inform about skipped feature types (yes, it's certainly nitpicky).

I understand where you're coming from, but I'm not sure it's very helpful to compare log warnings with code smell: you have very limited ways to influence what is logged, and messages that are irrelevant to you may be critical to other use cases. Have you considered using the LogMessageStreamer to filter the contents to your own, custom log file?

I had a look around to see if it was possible to configure the number of repeated log entries before they're collapse into a single message, but couldn't find anything.

This seems a bit like a bug, it probably shouldn't be being logged as a warning given it's content. That being said, there are a tonne of reasons why FME would log warnings which can safely be ignored. Trying to write workspaces which avoid warnings can be pretty annoying and, in my opinion, is not really worth it. This is particularly common when trying to build dynamic workflows which may or may not do particular things depending on the data, or when a bad data feature that the workspace developer can't control gets into the workflow. FME can fix the bad data perhaps but may log a warning about it.

Depending on who you talk to as well there are ERRORS which some would prefer logged as warnings and warnings which they'd prefer to be ERRORS.

Right now, my use-case does not require creating a custom log file, it really just is focused on the manually running a translation via FME. However, in the future, there a plans for an automatic execution with FME server, and in this context, the LogMessageStreamer transformer looks like to could be really useful. So thank you very much for this hint!

The comparison with a code smell was a bit exaggerated, I agree. I was annoyed with this WARN message because in the given context, it does not make sense to me. To generally please everyone with the granularity of the log levels is certainly very difficult (as also @virtualcitymatt​ pointed out).

I think I'll leave it as it is for now and when used with FME Server, I'll have a deeper look at the LogMessageStreamer. Thanks again for your valuable answers @david_r​.

Thanks for your answer @virtualcitymatt​. Seems like it really is a bit too ambitious to resolve each and every occuring WARN message. I just found that often, the WARN messages are good indicators that a suboptimal/questionable way to solve the given task was chosen and therefore, fixing them actually improved my workspaces quite a bit.