I may have found the cause of this error. There have been
discussions of this in the lists and fora, but they pointed at
messages themselves as the cause.
I found out that some users, when they get initiallized, have
no setting for the user preference of "msgprocessor".
But, when the user changes anything in the preferences,
then the value of cleanmessage is set for the
msgprocessor.
I have the default null in the site_template. Perhaps that
needs to be set to cleanmessage in the distribution, but
then why does it get set right in the second place?
==Leonard
Logged In: YES
user_id=620875
I should update this, that the distribution I'm using is NOT
the latest in CVS (that has jpim removed), as I'm using
Dieter's previous development distribution. So, I don't know if
this is a problem in the latest release.
==Leonard
Logged In: YES
user_id=36782
Leonard,
Seems like this is a bit complicated to trace down. I am just trying to figure out what happens here.
If you mention initialize, probably it is the cloning of the template object that gives us troubles. I will investigate and probably clean it up, so that the process is more straight forward (and does not fail any longer).
Regards,
Dieter
Logged In: YES
user_id=36782
Leonard,
The default processor comes from the settings/configuration, and is loaded in the Kernel (prepareProcessing()). It cannot be null, otherwise it would throw an exception during kernel bootstrap (Failed to load default message processing pipe.)
The CastorPreferences constructor calls
//ensure default processor to be set
setMessageProcessorName("");
which in turn will call
JwmaKernel.getReference().getMessageProcessor(name);
which in turn will return
1. the default for "" and null as name,
2. an encountered processor or pipe, or if none is encountered with the given name, the default.
All this is evidence that the cloning gives us troubles, although I wonder that it can pass the plain constructor (no params).
Could you add the line:
pref.setMessageProcessorName(pref.getMessageProcessorName());
before the return statement
return pref;
to the CastorPreferences.getClone(); and see if it resolves the problem?
Regards,
Dieter
Logged In: YES
user_id=620875
Dieter, I've tested your fix, and yes, it does resolve the problem.
The database (I'm using the SQL persistence) now gets
cleanmessage in it without having to go into the preferences
page and save it.
Thanks!
==Leonard
Logged In: YES
user_id=36782
Leonard,
looks like it is really the cloning process. I have added and committed the fix.
Regards,
Dieter