Community
Participate
Working Groups
It would be nice having a trace output from the OMTracer (and OMLogger) which print outs the related class as well as the line number from where the comes. This could be formatted in a way that the console interprets this output as a link and allows the developer to jump to the related line.
Created attachment 175459 [details] Patch v1 Hi Eike, attached an idea how the change could look like. I think the result looks fine. Maybe the implementation could be improved. If you have ideas on this...let us discuss them :)
Eike, how about this bug? I am not sure whether we should uses the things I provided with patch1 or better llok for somethinf different. May a Log4j integration into our logging framework? Or don't you see any necessity for enchancing the current implementation?
(In reply to comment #2) > Eike, how about this bug? I am not sure whether we should uses the things I > provided with patch1 or better llok for somethinf different. I haven't seen a review? flag :P > May a Log4j integration into our logging framework? That sentence does not parse.
(In reply to comment #3) > (In reply to comment #2) > > Eike, how about this bug? I am not sure whether we should uses the things I > > provided with patch1 or better llok for somethinf different. > > I haven't seen a review? flag :P Here it comes ;) > > > May a Log4j integration into our logging framework? > > That sentence does not parse. Understandable ;) Do not even know what is missing. :) But what I meant was something like: Shall we try to integrate log4J our any other logging framework to make our traces mor flexible?
(In reply to comment #4) > > I haven't seen a review? flag :P > Here it comes ;) Can't review it right now, my workspace is dirty. > Shall we try to integrate log4J our any other logging framework to make our > traces mor flexible? What would be the difference? What are you missing? A bridge should be easy to create but I'm reluctant to create new bundles for that. New non-optional external dependencies are not acceptable.
> What would be the difference? What are you missing? > It is long ago, but as far as I remember the patch relies on the call hierarchy so I am not sure whether this is the best approach. I am also not sure whether the patch is still valid. But If you try it and it works we could use it ;) > A bridge should be easy to create but I'm reluctant to create new bundles for > that. New non-optional external dependencies are not acceptable. Agreed. Then let's take this one ;)
I'm concerned about the performance implications. Maybe a system property should be used to make this configurable? And I don't like the simple string concatenation of the prefix and the msg. OMTraceHandlerEvent should be enhanced instead so that the OMTraceHandler can decide whether to show it or not. The prefix() methods should be static and somewhere central, maybe in ReflectUtil. And it seems as if some of the pos values are not correct. The test should be un net4j.tests.util
Created attachment 188695 [details] Patch v2
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
No activity here for almost 2 years and the performance implications haven't been clarified.
