SMTPClient and NetNameResolver

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

SMTPClient and NetNameResolver

NorbertHartl
I had the impression these were also available in gemstone. If so can you point me to the package I need to load?

thanks,

Norbert
Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

Johan Brichau-2
Hi Norbert,

For SMTPClient:

Look for 'SendMail' class
If it's not in your repository, look at http://seaside.gemstone.com/ss/smtp

Hope that answers your search!

cheers
Johan

On 15 Jun 2011, at 20:34, Norbert Hartl wrote:

> I had the impression these were also available in gemstone. If so can you point me to the package I need to load?
>
> thanks,
>
> Norbert

Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl

Am 15.06.2011 um 21:16 schrieb Johan Brichau:

> Hi Norbert,
>
> For SMTPClient:
>
> Look for 'SendMail' class
> If it's not in your repository, look at http://seaside.gemstone.com/ss/smtp
>
> Hope that answers your search!
>
>
Thanks Johan.

I hoped there is a chance to do it cross-platform wise. As I'm trying to send from a rest handler grease is unfortunately not an option. Seems that I need to introduce platform packages.

Norbert

>
> On 15 Jun 2011, at 20:34, Norbert Hartl wrote:
>
>> I had the impression these were also available in gemstone. If so can you point me to the package I need to load?
>>
>> thanks,
>>
>> Norbert
>

Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

Johan Brichau-2

On 15 Jun 2011, at 21:23, Norbert Hartl wrote:

> I hoped there is a chance to do it cross-platform wise. As I'm trying to send from a rest handler grease is unfortunately not an option. Seems that I need to introduce platform packages.

aha, take a look at GRGemStonePlatform: the right methods are there.

We are using WAMailMessage in Seaside and the code works both in GemStone and Pharo.
It's using Grease.


Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl

Am 15.06.2011 um 21:28 schrieb Johan Brichau:


On 15 Jun 2011, at 21:23, Norbert Hartl wrote:

I hoped there is a chance to do it cross-platform wise. As I'm trying to send from a rest handler grease is unfortunately not an option. Seems that I need to introduce platform packages.

aha, take a look at GRGemStonePlatform: the right methods are there.

We are using WAMailMessage in Seaside and the code works both in GemStone and Pharo.
It's using Grease.

Inside a rest handler there is no WACurrentContext which grease uses to resolve the configuration. I don't think it is feasible to provide the context with all the application preference settings just to get the right values used.

Norbert
Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl

Am 15.06.2011 um 21:30 schrieb Norbert Hartl:


Am 15.06.2011 um 21:28 schrieb Johan Brichau:


On 15 Jun 2011, at 21:23, Norbert Hartl wrote:

I hoped there is a chance to do it cross-platform wise. As I'm trying to send from a rest handler grease is unfortunately not an option. Seems that I need to introduce platform packages.

aha, take a look at GRGemStonePlatform: the right methods are there.

We are using WAMailMessage in Seaside and the code works both in GemStone and Pharo.
It's using Grease.

Inside a rest handler there is no WACurrentContext which grease uses to resolve the configuration. I don't think it is feasible to provide the context with all the application preference settings just to get the right values used.

Ah, I see, there are fallback values I can use. Thanks for pointing me into the right direction (where I've been hours before :) )

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

Tobias Pape

Am 2011-06-15 um 21:36 schrieb Norbert Hartl:

>
> Am 15.06.2011 um 21:30 schrieb Norbert Hartl:
>
>>
>> Am 15.06.2011 um 21:28 schrieb Johan Brichau:
>>
>>>
>>> On 15 Jun 2011, at 21:23, Norbert Hartl wrote:
>>>
>>>> I hoped there is a chance to do it cross-platform wise. As I'm trying to send from a rest handler grease is unfortunately not an option. Seems that I need to introduce platform packages.
>>>
>>> aha, take a look at GRGemStonePlatform: the right methods are there.
>>>
>>> We are using WAMailMessage in Seaside and the code works both in GemStone and Pharo.
>>> It's using Grease.
>>
>> Inside a rest handler there is no WACurrentContext which grease uses to resolve the configuration. I don't think it is feasible to provide the context with all the application preference settings just to get the right values used.
>>
> Ah, I see, there are fallback values I can use. Thanks for pointing me into the right direction (where I've been hours before :) )

I introduced this CurrentContext-thing to make Mail-sending
application specific :) Sorry it bothers you :)

Best
        -tobias

Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl

Am 15.06.2011 um 22:12 schrieb Tobias Pape:

>
> Am 2011-06-15 um 21:36 schrieb Norbert Hartl:
>
>>
>> Am 15.06.2011 um 21:30 schrieb Norbert Hartl:
>>
>>>
>>> Am 15.06.2011 um 21:28 schrieb Johan Brichau:
>>>
>>>>
>>>> On 15 Jun 2011, at 21:23, Norbert Hartl wrote:
>>>>
>>>>> I hoped there is a chance to do it cross-platform wise. As I'm trying to send from a rest handler grease is unfortunately not an option. Seems that I need to introduce platform packages.
>>>>
>>>> aha, take a look at GRGemStonePlatform: the right methods are there.
>>>>
>>>> We are using WAMailMessage in Seaside and the code works both in GemStone and Pharo.
>>>> It's using Grease.
>>>
>>> Inside a rest handler there is no WACurrentContext which grease uses to resolve the configuration. I don't think it is feasible to provide the context with all the application preference settings just to get the right values used.
>>>
>> Ah, I see, there are fallback values I can use. Thanks for pointing me into the right direction (where I've been hours before :) )
>
> I introduced this CurrentContext-thing to make Mail-sending
> application specific :) Sorry it bothers you :)
>
Well, I think it is useful in a normal seaside context where you want to configure the mail settings in your application. I thought there is no current context in my rest handler and it could fall back. But this is wrong. My problem now is that current context is there but the application is nil. So it fails with DNU at preferenceAt: in seasideApplicationPreferenceAt:ifAbsent.

Need to dig deeper.

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

Nick
Hi Norbert,
 
Well, I think it is useful in a normal seaside context where you want to configure the mail settings in your application. I thought there is no current context in my rest handler and it could fall back. But this is wrong. My problem now is that current context is there but the application is nil. So it fails with DNU at preferenceAt: in seasideApplicationPreferenceAt:ifAbsent.

I'm using something like:

sendEmailSubject: aSubject body: aBody to: toEmailAddress
[
WACurrentRequestContext
use: IZMockCurrentRequestContext 
during: [ 
GRPlatform current
       seasideDeliverEmailMessage: ((WAEmailMessage
               from: (WAEmailAddress address: '[hidden email]')
                       to: (WAEmailAddress address:  toEmailAddress)
                       subject: aSubject)
               body: (WAStringEmailBody string: aBody)) ] ] serverBackgroundTask

where IZMockCurrentRequestContext

has methods:

application
^ WADispatcher default handlers at: 'testemail'

codec
^ GRNullCodec new

request
^ WARequest
method: 'GET' 


I'm using IZMockCurrentRequestContext in other contexts so perhaps not all the methods are necessary 
Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl
Nick,

thanks for the hint. I think using the fallback values is fine for me. I now use the following:

WACurrentRequestContext
use: COContextInvalidationContext 
during: [ GRPlatform current seasideDeliverEmailMessage: mail ]

COContextInvalidationContext class>>application
WARequestContextNotFound signal

Sort of cheap duck tape but it will do the trick until I come up with something smarter (which almost never happens)

Norbert

Am 15.06.2011 um 22:41 schrieb Nick Ager:

Hi Norbert,
 
Well, I think it is useful in a normal seaside context where you want to configure the mail settings in your application. I thought there is no current context in my rest handler and it could fall back. But this is wrong. My problem now is that current context is there but the application is nil. So it fails with DNU at preferenceAt: in seasideApplicationPreferenceAt:ifAbsent.

I'm using something like:

sendEmailSubject: aSubject body: aBody to: toEmailAddress
[
WACurrentRequestContext
use: IZMockCurrentRequestContext 
during: [ 
GRPlatform current
       seasideDeliverEmailMessage: ((WAEmailMessage
               from: (WAEmailAddress address: '[hidden email]')
                       to: (WAEmailAddress address:  toEmailAddress)
                       subject: aSubject)
               body: (WAStringEmailBody string: aBody)) ] ] serverBackgroundTask

where IZMockCurrentRequestContext

has methods:

application
^ WADispatcher default handlers at: 'testemail'

codec
^ GRNullCodec new

request
^ WARequest
method: 'GET' 


I'm using IZMockCurrentRequestContext in other contexts so perhaps not all the methods are necessary 

Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl
Arrg... it doesn't like me at all today. I'm using a plain 1.0-beta.8.6 glass. I do the same thing that Nick shows in his example below. That's

mail := WAEmailMessage 
from: (WAEmailAddress address: [hidden email]' username: 'robot')
to: (WAEmailAddress address: user authKey username: user fullName)
subject: template subject.
mail setStringBody: (template replaceLabels: replace) wrap: false.
GRPlatform current seasideDeliverEmailMessage: mail

It does not work. In to: there is a WAEmailAddress assigned. WAEmailAddress builds a collection of these addresses. 
In 

GRGemStonePlatform>>seasideDeliverEmailMessage: aWAEmailMessage
...
"deliver the mail"
client 
mailhostName: self seasideSmtpServer;
smtpPort: self seasideSmtpPort;
from: aWAEmailMessage from address greaseString;
to: aWAEmailMessage recipientsAddresses;
text: aWAEmailMessage plainMessage.
...

to: is assigned the recipientsAddresses of the message. That is an array, too. But 

SMTPClient>>sendRcptTo
| result |
result := true.
(self to subStrings: $;) , (self cc subStrings: $;)
...

expects quite a different format. Why does this work for everyone of you but me? :) If I quick fix it by only using the first element in the recipientsAddresses than I can send the mail. However another problem shows up. The headers show up in the mail body

Anyone?

Norbert
Am 15.06.2011 um 23:30 schrieb Norbert Hartl:

Nick,

thanks for the hint. I think using the fallback values is fine for me. I now use the following:

WACurrentRequestContext
use: COContextInvalidationContext 
during: [ GRPlatform current seasideDeliverEmailMessage: mail ]

COContextInvalidationContext class>>application
WARequestContextNotFound signal

Sort of cheap duck tape but it will do the trick until I come up with something smarter (which almost never happens)

Norbert

Am 15.06.2011 um 22:41 schrieb Nick Ager:

Hi Norbert,
 
Well, I think it is useful in a normal seaside context where you want to configure the mail settings in your application. I thought there is no current context in my rest handler and it could fall back. But this is wrong. My problem now is that current context is there but the application is nil. So it fails with DNU at preferenceAt: in seasideApplicationPreferenceAt:ifAbsent.

I'm using something like:

sendEmailSubject: aSubject body: aBody to: toEmailAddress
[
WACurrentRequestContext
use: IZMockCurrentRequestContext 
during: [ 
GRPlatform current
       seasideDeliverEmailMessage: ((WAEmailMessage
               from: (WAEmailAddress address: '[hidden email]')
                       to: (WAEmailAddress address:  toEmailAddress)
                       subject: aSubject)
               body: (WAStringEmailBody string: aBody)) ] ] serverBackgroundTask

where IZMockCurrentRequestContext

has methods:

application
^ WADispatcher default handlers at: 'testemail'

codec
^ GRNullCodec new

request
^ WARequest
method: 'GET' 


I'm using IZMockCurrentRequestContext in other contexts so perhaps not all the methods are necessary 


Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

Dale Henrichs
Norbert,

You might be hitting Issue 248[1]. The fix is in version 1.0.5 of Grease...

Dale

[1] http://code.google.com/p/glassdb/issues/detail?id=248

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, June 15, 2011 3:55:08 PM
| Subject: Re: [GS/SS Beta] SMTPClient and NetNameResolver
|
| Arrg... it doesn't like me at all today. I'm using a plain
| 1.0-beta.8.6 glass. I do the same thing that Nick shows in his
| example below. That's
|
|
|
| mail := WAEmailMessage
| from: (WAEmailAddress address: '[hidden email] ' username:
| 'robot')
| to: (WAEmailAddress address: user authKey username: user fullName)
| subject: template subject.
| mail setStringBody: (template replaceLabels: replace) wrap: false.
| GRPlatform current seasideDeliverEmailMessage: mail
|
|
| It does not work. In to: there is a WAEmailAddress assigned.
| WAEmailAddress builds a collection of these addresses.
| In
|
|
| GRGemStonePlatform>>seasideDeliverEmailMessage: aWAEmailMessage
| . ..
| "deliver the mail"
| client
| mailhostName: self seasideSmtpServer;
| smtpPort: self seasideSmtpPort;
| from: aWAEmailMessage from address greaseString;
| to: aWAEmailMessage recipientsAddresses;
| text: aWAEmailMessage plainMessage.
| ...
|
|
| to: is assigned the recipientsAddresses of the message. That is an
| array, too. But
|
|
| SMTPClient>>sendRcptTo
| | result |
| result := true.
| (self to subStrings: $;) , (self cc subStrings: $;)
| ...
|
|
| expects quite a different format. Why does this work for everyone of
| you but me? :) If I quick fix it by only using the first element in
| the recipientsAddresses than I can send the mail. However another
| problem shows up. The headers show up in the mail body
|
|
| Anyone?
|
|
| Norbert
|
| Am 15.06.2011 um 23:30 schrieb Norbert Hartl:
|
|
|
| Nick,
|
|
| thanks for the hint. I think using the fallback values is fine for
| me. I now use the following:
|
|
|
| WACurrentRequestContext
| use: COContextInvalidationContext
| during: [ GRPlatform current seasideDeliverEmailMessage: mail ]
|
|
| COContextInvalidationContext class>>application
| WARequestContextNotFound signal
|
|
| Sort of cheap duck tape but it will do the trick until I come up with
| something smarter (which almost never happens)
|
|
| Norbert
|
|
|
| Am 15.06.2011 um 22:41 schrieb Nick Ager:
|
|
|
|
| Hi Norbert,
|
|
|
|
| Well, I think it is useful in a normal seaside context where you want
| to configure the mail settings in your application. I thought there
| is no current context in my rest handler and it could fall back. But
| this is wrong. My problem now is that current context is there but
| the application is nil. So it fails with DNU at preferenceAt: in
| seasideApplicationPreferenceAt:ifAbsent.
|
|
| I'm using something like:
|
|
| sendEmailSubject: aSubject body: aBody to: toEmailAddress
| [
| WACurrentRequestContext
| use: IZMockCurrentRequestContext
| during: [
| GRPlatform current
| seasideDeliverEmailMessage: ((WAEmailMessage
| from: (WAEmailAddress address: ' [hidden email] ')
| to: (WAEmailAddress address: toEmailAddress)
| subject: aSubject)
| body: (WAStringEmailBody string: aBody)) ] ] serverBackgroundTask
|
|
| where IZMockCurrentRequestContext
|
|
| has methods:
|
|
| application
| ^ WADispatcher default handlers at: 'testemail'
|
|
|
| codec
| ^ GRNullCodec new
|
|
|
| request
| ^ WARequest
| method: 'GET'
| uri: ' http://www.getitmade.com/products/aproduct/ '
|
|
|
| I'm using IZMockCurrentRequestContext in other contexts so perhaps
| not all the methods are necessary
|
|
Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

Nick
Hi Norbert,
 
You might be hitting Issue 248[1]. The fix is in version 1.0.5 of Grease...

For the record I'm using the latest ConfigurationOfSeaside [1] with addition of:

NetNameResolver [2] from:

package: 'Network-Kernel'

SendMail from attachment (allows authentication):

latest GRGemStonePlatform>>#seasideDeliverEmailMessage: from [3]:

package: Seaside-GemStone-Email-dkh.11

and the latest Sport and HTTPSocket (though I'm not sure they are related to your mail problems):

Sport:
package: Sport3.010-NickAger.24

HTTPSocket:
package: Squeak-NickAger.264


Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl
Nick,

thanks for the details. The version I have does just not work. I fixed it on my side. I'll check all of the changes you mentioned and maybe I don't need to do a fixed version of SMTPMail.

Norbert

Am 16.06.2011 um 07:17 schrieb Nick Ager:

Hi Norbert,
 
You might be hitting Issue 248[1]. The fix is in version 1.0.5 of Grease...

For the record I'm using the latest ConfigurationOfSeaside [1] with addition of:

NetNameResolver [2] from:

package: 'Network-Kernel'

SendMail from attachment (allows authentication):

latest GRGemStonePlatform>>#seasideDeliverEmailMessage: from [3]:

package: Seaside-GemStone-Email-dkh.11

and the latest Sport and HTTPSocket (though I'm not sure they are related to your mail problems):

Sport:
package: Sport3.010-NickAger.24

HTTPSocket:
package: Squeak-NickAger.264



Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl
In reply to this post by Nick
Well,

it seems that I need to learn to look for latest versions before I try to fix things on my own. My fix is the same as Johan did in Seaside-GemStone-Email. Stupid me!

Btw. how do you "patch" your images. Are you adding newer versions of packages in your own ConfigurationOf or do load with Gofer afterwards or ...?

Norbert

Am 16.06.2011 um 07:17 schrieb Nick Ager:

Hi Norbert,
 
You might be hitting Issue 248[1]. The fix is in version 1.0.5 of Grease...

For the record I'm using the latest ConfigurationOfSeaside [1] with addition of:

NetNameResolver [2] from:

package: 'Network-Kernel'

SendMail from attachment (allows authentication):

latest GRGemStonePlatform>>#seasideDeliverEmailMessage: from [3]:

package: Seaside-GemStone-Email-dkh.11

and the latest Sport and HTTPSocket (though I'm not sure they are related to your mail problems):

Sport:
package: Sport3.010-NickAger.24

HTTPSocket:
package: Squeak-NickAger.264



Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl
In reply to this post by Nick

Am 15.06.2011 um 22:41 schrieb Nick Ager:

> I'm using IZMockCurrentRequestContext in other contexts so perhaps not all the methods are necessary


If you are using WAGemStoneProductionErrorHandler you need to implement also

forDebugging: aBoolean

otherwise you might experience problems with debug continuation. This is used in the error handler.

Norbert
Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

Philippe Marschall
In reply to this post by NorbertHartl
2011/6/15 Norbert Hartl <[hidden email]>:

>
> Am 15.06.2011 um 21:28 schrieb Johan Brichau:
>
> On 15 Jun 2011, at 21:23, Norbert Hartl wrote:
>
> I hoped there is a chance to do it cross-platform wise. As I'm trying to
> send from a rest handler grease is unfortunately not an option. Seems that I
> need to introduce platform packages.
>
> aha, take a look at GRGemStonePlatform: the right methods are there.
>
> We are using WAMailMessage in Seaside and the code works both in GemStone
> and Pharo.
> It's using Grease.
>
> Inside a rest handler there is no WACurrentContext which grease uses to
> resolve the configuration. …

That's not true (see code below). The only problem is that the code
wants an application for preference look up when any request handler
would do [1]. That's an easy fix.

index
        <GET>
        <Path: 'index.html'>
        self requestContext respond: [ :response |
                response
                        contentType: WAMimeType textPlain;
                        nextPutAll: self requestContext greaseString ]

 [1] http://code.google.com/p/seaside/issues/detail?id=658

Cheers
Philippe
Reply | Threaded
Open this post in threaded view
|

Re: SMTPClient and NetNameResolver

NorbertHartl

Am 17.06.2011 um 16:59 schrieb Philippe Marschall:

> 2011/6/15 Norbert Hartl <[hidden email]>:
>>
>> Am 15.06.2011 um 21:28 schrieb Johan Brichau:
>>
>> On 15 Jun 2011, at 21:23, Norbert Hartl wrote:
>>
>> I hoped there is a chance to do it cross-platform wise. As I'm trying to
>> send from a rest handler grease is unfortunately not an option. Seems that I
>> need to introduce platform packages.
>>
>> aha, take a look at GRGemStonePlatform: the right methods are there.
>>
>> We are using WAMailMessage in Seaside and the code works both in GemStone
>> and Pharo.
>> It's using Grease.
>>
>> Inside a rest handler there is no WACurrentContext which grease uses to
>> resolve the configuration. …
>
> That's not true (see code below). The only problem is that the code
> wants an application for preference look up when any request handler
> would do [1]. That's an easy fix.
>
I was mistaken on the context. If you read the whole thread you can see it. Thanks for opening a ticket.

Norbert

> index
> <GET>
> <Path: 'index.html'>
> self requestContext respond: [ :response |
> response
> contentType: WAMimeType textPlain;
> nextPutAll: self requestContext greaseString ]
>
> [1] http://code.google.com/p/seaside/issues/detail?id=658
>
> Cheers
> Philippe