I added the transport line as you suggested and sent a test email
inbound. The console showed it coming in, as does james-server.log.
But still, the only log file in the logs directory that is not empty is
james-server. Nothing is going to any of these files.
On 9/17/2019 10:49 PM, Tellier
I'll try that shortly. But that doesn't explain why all of the logger
output files are empty, no matter what the log4j settings are. This was
after 30 minutes of running with every log level throughout
log4j.properties set to DEBUG. Shouldn't at least some of these have
some sort of log
I inlined my answers...
Regards,
On 18/09/2019 10:32, Jerry Malcolm wrote:
> Thanks for the reply. But I did not use my old log4j.properties. I
> copied the one from the downloaded 3.3.0 zip file. Although, it looks
> almost identical to the beta5 one. Any chance the wrong one is included
>
Thanks for the reply. But I did not use my old log4j.properties. I
copied the one from the downloaded 3.3.0 zip file. Although, it looks
almost identical to the beta5 one. Any chance the wrong one is included
in the package?
I'm fine with logger-per-mailet. However, I'm hoping there's a
Maybe I could help on that one:
The mailet logging had been migrated to a standard SLF4J approach.
Before that, all mailet logs went though a single logger, exposed as
part of the MailetContext object.
Before 3.0.0 release we altered that behavior, and create one logger per
mailet class for
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
Well this one wasn't as difficult as I expected. Turns out during all
of the transition and merging I ended up with the conf/META-INF folder
from b5. Since that folder contains all of the JPA stuff, 3.3.0 was not
at all happy with v3b5 JPA files.
Just a note for continuing to document my
Jerry,
I have had moderate success with creating a separate properties file with your
database info in it. You can use a simple properties file with key-value pairs
and then use a class with a name like MailetProperties to read the file into
your application. I recommend this approach so that
Hi Jerry,
To explain it shortly:
1. In OpenJPA NamedQuery are directly attached to the POJO being
persited, here AbstractJPAMailboxMessage
2. Using these annotations (named query) openjpa plugin enhance code
upon compilation
3. Then the magic happens
Here because openjpa do not load
If I were you, I'd use only mailet configuration properties for this.
On 17/09/2019 10:18, Jerry Malcolm wrote:
> No the main mailet in question is 100% custom. It is a mailet that
> decides what folder to put the mail item in. I access a completely
> separate client database and determine if
12 matches
Mail list logo
