Hi Aaron, I like your description of the mailet config. I've only tried to work on 2 mailets so far, but the restriction of a name-value pair combo has come up in both of them. I would love to have arbitrary XML parsed into a dom, or have the values pulled into a bean, etc.
Kenny > -----Original Message----- > From: Aaron Knauf [mailto:[EMAIL PROTECTED]] > Sent: Saturday, December 21, 2002 10:26 PM > To: James Developers List > Subject: Re: Stream prob in SMTP handler > > > > > Noel J. Bergman wrote: > > > Serge, I propose an alternative. We can use internal mail > attributes, and > > use a mailet to take specified mail attributes and generate X-headers as > > configured. That is a nice open solution to not just THIS > instance, but to > > others. > > Absolutely. I was contemplating this when I suggested the mail property > idea. > > A structured mailet config would allow multiple header/property mappings > to be configured for a single mailet instance, too. > > On the subject of mailet config, it would be good to allow arbitrary XML > to be added to the mailet tag for configuration. > > I envisage it working like this: > * Configuration for mailets is placed inside a <config> child tag. > * The <config> tag can contain arbitrary XML. > * If a namespace is specified for the config body, then that > is used as > a key to a pluggable parser implementation. (Parser-to-namespace > mappings being specified elsewhere in the JAMES config.) > * A well-known namespace mapping exists by default to support > the named > property setup that is currently used. > * If no namespace is specified, then the body is parsed into > a DOM tree. > * Parsers return implementations of a Config interface, which > the Mailet > is expected to be aware. (A cast would be necessary.) > * Two Config implementations are supplied - a properties config and a > DOM tree config. > * The <config> tag could also support a 'location' attribute that > specified an separate configuration file. > * Direct children of the <mailet> tag are reserved for use by JAMES. > * Alternatively, backwards compatibility could be 99% maintained by > using the current scheme to interpret mailet child tags other > than <config>. > > This scheme would allow mailets to get their config in one of 3 ways - > 1) As named properties > 2) As a DOM tree > 3) As a custom Config object > > On the same note, is there a reason not to use a DTD/XSD for JAMES > config? DTD/XSD files have always struck me as free validation. > Especially when netbeans will /generate/ a basic DTD for you! DTDdoc can > be easily used for config documentation, too. Sure, the parsing takes a > couple of milliseconds longer, but how often does JAMES parse its config? > > Ok, burst of enthusiasm over. Any comments? If the rest of you like > the idea, I volunteer to write it. > > ADK > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
