A little of topic - Global e-mail sending facility inside of tomcat?

[Ryan Cornia <RC...@utah.gov>]

This is a little of topic, but I'm sure someone on this list has
implemented something similar with tomcat.
-->
I have several applications running on Tomcat 4.1.12 that I need to add
the capability to send e-mail via a SMTP server. There are two problems
-

1.) Are there any products or open source projects available that will
que the mail in case the SMTP server is down and re-send it later,
including the possibility of a tomcat re-start before the SMTP server
comes back up? Basically I want a way to insure an automated e-mail is
sent when a person registers, and is not "lost" when the e-mail server
is down.

2.) Is there a way to configure this service as a global JNDI resource
available to all applications running inside of tomcat?

Thanks,
Ryan


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: JkMount question

[David Brown <dw...@webitplanet.com>]

Rafael Angarita writes: 

>    Hi, 
> 
>    Does anybody knows if it's important the order of JkMount directives?, 
> for example: 
> 
>    I have two tomcat instances T1 and T2,     - The loadbalancer should 
> handle all the requests to the entire site (and do a load balance between  
> T1 and T2) except for /app1 context
>    - T2 should handle all the requests to /app1 context 
> 
>    What's the right order of JkMount directives in my .conf file? does it 
> matters? 
> 
>    Thanks in advance, 
> 
> --  
> 
> Rafael Angarita 
> 
>  
> 
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org> 
> 
 

Hello Rafael, i don't think the order matters. i don't have 2 loadbalanced 
servers but i have few domains and it seems the JkMount order in httpd.conf 
does not matter. httpd.conf is a name/value/properties type of file and not 
an xml file so the order should not matter. hope this helps ,david 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

JkMount question

[Rafael Angarita <ra...@telcel.net.ve>]

    Hi,

    Does anybody knows if it's important the order of JkMount 
directives?, for example:

    I have two tomcat instances T1 and T2,  
    - The loadbalancer should handle all the requests to the entire site 
(and do a load balance between  T1 and T2) except for /app1 context
    - T2 should handle all the requests to /app1 context

    What's the right order of JkMount directives in my .conf file? does 
it matters?

    Thanks in advance,

-- 

Rafael Angarita



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: A little of topic - Global e-mail sending facility inside of tomcat?

[Cees van de Griend <cv...@pobox.com>]

On Friday 22 November 2002 18:58, Ryan Cornia wrote:
> 1.) Are there any products or open source projects available that will
> que the mail in case the SMTP server is down and re-send it later,
> including the possibility of a tomcat re-start before the SMTP server
> comes back up? Basically I want a way to insure an automated e-mail is
> sent when a person registers, and is not "lost" when the e-mail server
> is down.

When a SMTP server accepts an email, it  should never loose it. If yours does, 
replace it . There are a lot of good quality Open Source SMTP servers.

Your program should not duplicate a SMTP server. If the SMTP server is down, 
you should get an exception (I don't know the JavaMail API) and maybe try to 
connect to a backup mailer.

You can never garantee that an email will reach its destination. Maybe the 
SMTP server of the receipient stores all email in /dev/null, you have no way 
of knowing and can't do anything about it.
If there is an error, the destination SMTP server will normally report an 
error back to you - for example: the user is unknown - and maybe your 
application should handle these bounce messages.

Welcome to the internet. Sometimes it's a disadvantage that nobody controls 
it, mostly it's a blessing.

Regards,
Cees.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>