Home » Eclipse Projects » Papyrus for Real Time » log levels?
|
| Re: log levels? [message #1781010 is a reply to message #1780988] |
Wed, 31 January 2018 14:18   |
|
Hi Juergen,
Thank you for the suggestion.
What kind of log are you referring to? Toolset? Runtime? Application (i.e., as part of the log port capabilities?
What do you mean by "at code invocation time"? At the time the executable is launched (e.g., through command line parameters) or during the execution (e.g., through external communications)?
From a purely application point of view, I agree that it could be useful. I have seen and used custom tailored logging mechanisms in UML-RT-based tooling that would be used to automatically enhance the provided logging capability, including adding severity, system information, and enhanced encoding. Most of these were custom development using UML-RT's capabilities and not at the level of modifying the runtime. As those were proprietary implementations seen during consulting engagements, I do not have access to the models or code implementing them.
Note that, since a UML-RT based solution has access to the command line parameters of the executable, those could be used to control the output of the logging mechanism.
Would that satisfy your needs?
/Charles Rivet
|
|
|
| Re: log levels? [message #1781013 is a reply to message #1781010] |
Wed, 31 January 2018 15:01 |
 Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
I assume you are talking about the Log protocol, and logging in action code with log levels like "debug", "info", "warning", "error", "critical", "fatal", etc. Correct?
If so, unfortunately the RTS library doesn't support that. You can take a look at "umlrtlogprotocol.hh" in the RTS. There is only a "log" method that accepts different types of parameter, and a "show" method which is log, with no newline appended. There are other useful methods, like "redirect", to send the log to a file, rather than stdout, but unfortunately no support for logging levels.
Nevertheless it shouldn't be too difficult to add support for this. If this is what you are looking for, could you open an enhancement request in bugzilla?
|
|
|
| Re: log levels? [message #1781053 is a reply to message #1781013] |
Wed, 31 January 2018 20:53 |
Juergen Dingel
Messages: 42
Registered: January 2015 |
Member |
|
|
Yes, Ernesto, that is what I had in mind.
In the absence of built-in RTS support for this, it seems to me that it should also be possible to create support for this on the application level (i.e., in the model) via, e.g., a user defined operation 'myLog(s : string, logLevel : int, currentLogLevel : int)' that uses the built-in 'log' method, but only when the 'logLevel' parameter exceeds the 'currentLogLevel' parameter (which indicates the log level that the user wants the code to run at and is provided at code invocation time).
Unfortunately, it seems that this operation would have to replicated in every capsule that wants to use it, right? Also, the 'currentLogLevel' command line argument would have to be communicated to every capsule...
Am I missing something?
Juergen
|
|
|
| Re: log levels? [message #1781054 is a reply to message #1781053] |
Wed, 31 January 2018 21:03 |
|
Hi Juergen,
I do not think you are missing anything.
Note that since you create your own "myLog", you can have a protocol that allows you to set the "debug level" where the log messages are printed. This would typically happen in the Top capsule's initial transition. You would need to make sure that the capsule containing the MyLog SPP is initialized properly (i.e., wait for a "bound").
The enumeration of the levels can be specified in a utility class that is then imported in all capsules that need it.
/Charles Rivet
|
|
|
| Re: log levels? [message #1781055 is a reply to message #1781053] |
Wed, 31 January 2018 21:17 |
Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Well, there are some ways to achieve something close to a global definition (although as you know, UML-RT was design with strong encapsulation in mind, and therefore disallowing global definitions).
One, which I use often is to add a UML Artifact element, apply the ArtifactProperties stereotype and in the stereotype enter the contents, which can be any C++ definition. Then, in any capsule or class that needs these add a Dependency to the Artifact, or equivalently, add the CapsuleProperties stereotype and in the headerPreface add an #include statement to the artifact.
An alternative approach, and perhaps more in line with the UML-RT style of modelling, is to use SAPs and SPPs and define this new custom logging service. Define a capsule called, say "MyLogger" with an SPP called say "newLog" typed by a "NewLog" protocol that has a "log" message with the parameters you want, including say a string and an int level. Then, in your client capsules, instead of adding a standard Log port, you ass a NewLog SAP called "newLog" (to match the one in MyLogger). Let the default registration be automatic, and in action code you should be able to write something like this:
newLog.log("message", level).send();
So there is a bit of extra syntax in the action, but it should work. Then you don't have to manually add dependencies from each client, although you do have to add an SAP, but that is no different than adding a standard log port. Also, only NewLogger needs to be able to get command-line arguments.
Hope this helps.
|
|
|
| Re: log levels? [message #1781056 is a reply to message #1781055] |
Wed, 31 January 2018 21:37 |
|
I'm in agreement with Ernesto's solution. (and, by the way, my "utility class" are somewhat equivalent to Ernesto's UML Artifact element. In my case, I would limit its use to the definition of an enumeration that provide the desired log levels.
Note that using an operation calls can be problematic in multithreaded environments, which is another case for using the messaging mechanism that is pervasive in Papyrus-RT.
Also, the protocol that you define for MyLog can be enhanced to support support both a limit log level from either the command line (where either the Top Capsule could retrieve the command line and then sends a "setLimit" message to the MyLog SAP to set the log level, or the MyLog capsule coud retrieve the log level directly from the command line in its initial transition.
Having this "setLimit" protocol message also enables you to temporarily change the limit if needed (which could also be done through a "SingleSetLimit" protocol message that would only change the level for that log call.
/Charles Rivet
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 20:25:25 GMT 2024
Powered by FUDForum. Page generated in 0.03167 seconds |
] 
Search
Help
Register
Login
Home
