Hi Ray,
I see what you mean now. I dug a little in the history and noticed that the
code that populated the logService had been removed some time ago (the
class used to have a LogServiceTracker).
Ah well, at least that is fixed now with your changes writing to JUL...
Thanks!
David
On Thu, 19
David, that's the logging side... But it does nothing because there are
never any log services.
- Ray
On Thu, Jul 19, 2018, 15:20 David Bosschaert,
wrote:
> Thanks Ray!
>
> Just for completeness, one file that uses this a few times is this one:
>
>
I've made a change as you've suggested.
- Ray
On Thu, Jul 19, 2018 at 12:58 PM, Raymond Auge
wrote:
> David, regarding the log change, I couldn't find any code that populated
> the log services anywhere, not through reflection, not through inheritance,
> nothing.
>
> Maybe you could show me
David, regarding the log change, I couldn't find any code that populated
the log services anywhere, not through reflection, not through inheritance,
nothing.
Maybe you could show me where that takes place.
- Ray
On Thu, Jul 19, 2018 at 9:35 AM, Raymond Auge
wrote:
>
>
> On Thu, Jul 19, 2018
On Thu, Jul 19, 2018 at 9:28 AM, David Bosschaert <
david.bosscha...@gmail.com> wrote:
> Thanks Ray!
>
> It looks good to me except for one thing. This commit
> https://svn.apache.org/r1836063 changes the log() method in the base
> activator to do nothing. I understand that this is to ensure that
Thanks Ray!
It looks good to me except for one thing. This commit
https://svn.apache.org/r1836063 changes the log() method in the base
activator to do nothing. I understand that this is to ensure that the
framework extension has no external dependencies but that log() method is
actually used
