[Deploying Sakai] overriding sakai smtp property with null value

Bill Niebel wdn5e at virginia.edu
Fri Feb 12 12:48:15 PST 2010

At the University of Virginia, we keep the same content in all sakai.properties
files across all environments (dev, test, prod).  Any property value
differences by server type (dev, test, prod) are positioned instead in the
local.properties files, as are machine-specific properties.  We copy our prod
db to non-prod environments (dev, test), so it's important to be able to turn
smtp off in non-prod testing to avoid sending mail inadvertently to end users.

1. I could position smtp at org.sakaiproject.email.api.EmailService=localhost in 
prod local.properties and omit it from non-prod local.properties (and also from
sakai.properties).  This works and I could do it this way.

2. But I would prefer to position that property in the general file
sakai.properties and then to provide a null overriding value only in the
non-prod local.properties file (with no need to override in prod 
local.properties).  Temporarily commenting out the overrides would allow
mail-related testing.

The following attempts in local.properties each fail to do this:
smtp at org.sakaiproject.email.api.EmailService=
# the last character on the previous line is "="
smtp at org.sakaiproject.email.api.EmailService= 
# the last character on the previous line is " "

The problem is that, unlike smtp.enabled=true|false, there's no alternate
"value" which serves to cancel a value previously and successfully given in a
more general properties file (here, sakai.properties).  Sakai simply ignores
the attempts above in local.properties, and the value given in
sakai.properties is used.  Another way of looking at this is that
smtp at org.sakaiproject.email.api.EmailService has overloaded functions in that it
both enables smtp and provides the smtp server address to use.

I tried using a dummy value in non-prod local.properties, e.g.,
smtp at org.sakaiproject.email.api.EmailService=x  This works as far as user
expectations go, but also unfortunately results in several log
messages per occurrence (per user or system attempt to use sakai mail service).
So it's not a practical workaround.

(Existing property smtp.enabled works as it's commented, but not as
its name implies.  It's more like "smtp.incoming.enabled".  Instead, smtp as a
general service (both directions) is turned on and off by
smtp at org.sakaiproject.email.api.EmailService.  It would be better to rename
this existing property instead to "smtp.incoming.enabled" (how it works and is
documented), and to provide a new property, accurately-named as "smtp.enabled"
and with values true|false.  This would take over one of the existing functions
of smtp at org.sakaiproject.email.api.EmailService (smtp on/off) and allow value
overrides in downstream .properties files.)

Am I missing a way to accomplish the preferred positioning?  (i.e., 2, above)
I'd appreciate any correction to how I'm seeing this.

More information about the production mailing list