On 7/6/01 9:23 AM, "Colin Chalmers" <[EMAIL PROTECTED]> wrote:
> 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?
Yes, it would be nice if this could be a general tool that could go
into the commons sandbox package of webtools.
> /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]
--
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]
