Hi Jason,
I was thinking along the lines of number 2. I'll drop a line (ok join the
commons list) and see what they think. But if I understand it correctly the
goal is to get rid of the Criteria methods (which is already deprecated) and
have an independant package not connected to Turbine?
/Colin
> On 7/6/01 4:43 AM, "Colin Chalmers" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I've been using the Email utilities successfully for some time, sending
> > multipart mails, but am now running into a small problem.
> >
> > The mail server that is used is set in the TurbineResources. Would it
not be
> > handy to have the ability to change this setting with a setMethod,
keeping
> > the TurbineResources setting as default ? I see that the MailSession is
set
> > in the constructor and then init() of Email class so would it be an idea
to
> > have a second constructor in the extended classes of Email accepting a
> > hostname of a mailserver to accomodate this? If so I could write a patch
and
> > post it to the group.
>
> One of the notes in one of the proposals is cleaning up the email
> classes and making them a general tool. They are coupled to Turbine
> right now. Criteria should be removed, and there should be a general
> way to set properties.
>
> I was thinking there could be two ways to do this:
>
> 1) You might want to provide explicit setX() methods, but
> this has the disadvantage of requiring a designer to know what
> the mail server is, but some people might want this. More tech
> savvy people.
>
> 2) Have a standard set of properties that could be set by turbine
> when it starts up. So, for example, a system property like 'mail.server'
> could be set. When the email component goes to send mail and discovers
> that the 'mail.server' property hasn't been set it can look to the
> system for the property: System.getProperty('mail.server').
>
> Something like this might be going on in the commons, but I haven't
> looked recently. There has to be an easy way to configure components
> like the email tool without binding it to one particular application.
> You might want to ask on the commons list. I remember Craig talking
> about dynamic bean properties in relation to this problem. At least
> I think that's what he was talking about. My 2c.
>
> >
> > /Colin
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
