Ok got it.. yeah I think this could make sense (somehow..) ;)
Some other thing I would like to change is the logging. At the moment
the user has no way to specify the log level to use when log via the
mailetcontext. So I propose todo this:
* mark the log(String) and log(String, Throwable) methods @deprecated
* Add two new methods like:
log(String, LogLevel);
log(String, Throwable, LogLevel);
enum LogLevel {
DEBUG,
INFO,
WARN,
ERROR
}
I twould also be nice to add some "identifier" to the log which could
be use to "follow" the whole route the "transaction" was going. We do
something similar in SMTPServer/POP3Server.
wdyt ?
2011/1/11 Stefano Bagnara <[email protected]>:
> 2011/1/11 Norman Maurer <[email protected]>:
>>> + simple persistence: I find that often a mailet needs some sort of
>>> simple persistence or some sort of "advanced/dynamic" configuration.
>>> a list of domains for a whitelist, a list of usernames (list<string>)
>>> a list of email addresses for a mailing list expansion (list<string>)
>>> map of aliases (map<string,string>)
>>> a properties like configuration (map<string,string>)
>>> They are simple list of strings or maps of strings to strings.
>>> Why don't we provide a way for mailets to declare they work with a
>>> "named map" or a "named list" and automatically provide
>>> persistence/lookup methods in a container agnostic way?
>>> This way a container could provide a simple file based (properties
>>> files works too!) a jdbc/jpa/jcr based implementation (configured in
>>> the container not in the mailet).
>>> I know this may sound "limited" but mailets could then encode/decode
>>> their data in simple strings to be added as values in the map and this
>>> would be a very little cost compared to writing the persistence backed
>>> (or being limited to a simple file or jdbc solution hardcoded in the
>>> mailet itself).
>>
>> So you think about some kind of key/value store.. right ?
>
> Well, the most basic implementation could simply store
> "${name}.properties" file in the configuration folder and read them as
> Property objects (Map<String, String>).
> So, it is a key value store, but not in the NoSQL version. It doesn't
> need to be fast or to be distributed or anything else and also doesn't
> need to scale to millions of values.
>
> From the container it looks like a multimap: a list of named maps, or
> simply a map of maps.
> This kind of structure is easy enough to be easily implemented for
> every backend.
>
> Stefano
>
