simpler logging filtering - on a per mailet
basis, got rid of the imperfect logging facade exposed in the
mailet API
(no placeholder for instance), and also killed some "debug"
configuration parameters.
I believe that your log4j configuration file inherited from beta5
needs
to be revisited
> "org.apache.james.transport.mailets" &
>>>> "org.apache.james.transport.matchers" packages...
>>>>
>>>>> Thx
>>>>>
>>>>>
>>>>> On 9/17/2019 10:23 PM, Tellier Benoit wrote:
>>>
killed some "debug"
configuration parameters.
I believe that your log4j configuration file inherited from beta5
needs
to be revisited to adapt these changes.
Hope it helps.
Benoit
On 18/09/2019 09:10, Jerry Malcolm wrote:
Not good news for me, however. My mailet flow that worked in
v3b5
ance), and also killed some "debug"
configuration parameters.
I believe that your log4j configuration file inherited from beta5
needs
to be revisited to adapt these changes.
Hope it helps.
Benoit
On 18/09/2019 09:10, Jerry Malcolm wrote:
Not good news for me, however. My mailet flow t
end, this enabled simpler logging filtering - on a per mailet
basis, got rid of the imperfect logging facade exposed in the mailet API
(no placeholder for instance), and also killed some "debug"
configuration parameters.
I believe that your log4j configuration file inherited from beta5
uot;debug"
configuration parameters.
I believe that your log4j configuration file inherited from beta5 needs
to be revisited to adapt these changes.
Hope it helps.
Benoit
On 18/09/2019 09:10, Jerry Malcolm wrote:
Not good news for me, however. My mailet flow that worked in v3b5 is
>>
>> Before 3.0.0 release we altered that behavior, and create one logger per
>> mailet class for bundled mailets.
>>
>> In the end, this enabled simpler logging filtering - on a per mailet
>> basis, got rid of the imperfect logging facade exposed in the mailet API
>&g
for instance), and also killed some "debug"
configuration parameters.
I believe that your log4j configuration file inherited from beta5 needs
to be revisited to adapt these changes.
Hope it helps.
Benoit
On 18/09/2019 09:10, Jerry Malcolm wrote:
Not good news for me, however. My m
for bundled mailets.
In the end, this enabled simpler logging filtering - on a per mailet
basis, got rid of the imperfect logging facade exposed in the mailet API
(no placeholder for instance), and also killed some "debug"
configuration parameters.
I believe that your log4j configuration file
Not good news for me, however. My mailet flow that worked in v3b5 is
crashing now, and none of the log output I'm writing from my mailets is
showing up anywhere. I've GOT to see that log info some place in order
to debug both my mailets as well as my mailet flow that is somehow no
longer
It’s not you. I have the same issue. I think those other log files are just
there for backwards compatibility to make users feel good, since they never
seem to be written to. “No news is good news” as the saying goes.
Sent from my iPhone
> On Sep 17, 2019, at 4:34 PM, Jerry Malcolm wrote:
>
For the problem du jour when I start JAMES, all of the expected log
files get created. The main log output goes to the console and to the
james-server.log file as expected. No problem there. But the remainder
of the log files never get touched. No matter what happens, every file
in
12 matches
Mail list logo
