Hi,
OK, so you need a local smtp server without having to configure postfix.
Yes, you can embed the needed james jars in your application.

http://wiki.apache.org/james/Embedded is for james 2.3 and builds a classpath with james, avalon and tomcat jars. I remember I put the james 2.3 jars in /WEB-INF/lib, put the config files at the right place (in classpath, or in / folder), and use the code below [1].

With james 3, the code you will also need some jars, the spring conf files, and launch via something like http://s.apache.org/ceS

if you want to go there and need more information, we can further document it on web site.
Tks,
Eric


[1]

import org.apache.avalon.phoenix.launcher.Main;

public class JamesServerLauncher {

public static final void main(final String[] args) throws Exception {
                System.setProperty("PHOENIX_HOME", "/opt/james/");
                System.setProperty("java.ext.dirs",
                                System.getProperty("PHOENIX_HOME") +
                                "/lib:" +
                                System.getProperty("PHOENIX_HOME") +
                                "/tools/lib");
System.setProperty("phoenix.home", System.getProperty("PHOENIX_HOME"));
                System.setProperty("java.security.policy", "jar:file:" +
                                System.getProperty("PHOENIX_HOME") +
"/bin/phoenix-loader.jar!/META-INF/java.policy");
                System.setProperty("java.security.manager","");
               Main.main(args);
        }


On 1/04/2011 13:30, Ludwig Magnusson wrote:
Thanks for the tip, but I'm not sure that is what we are looking for.
The optimal solution would be to include one (or several) libraries via
maven once, configure it locally, commit it to our repository and never
having to care about it again.

If I need to set environment variables and put files on every server I might
as well use postfix as I do today. Postfix works fine, it's only drawback is
that it needs to be setup on every machine that we run our webapp on. By
including james as a dependency in our webapp I was hoping that the email
functionality could be a part of it.
/Ludwig

-----Ursprungligt meddelande-----
Från: Eric Charles [mailto:[email protected]]
Skickat: den 1 april 2011 12:37
Till: James Users List
Ämne: Re: Is James for us?

Hi,

You can find information to embed 2.3 in tomcat on
http://wiki.apache.org/james/Embedded.
I successfully used that some time ago.

The 3.0 trunk (unstable) has a generated war that you can simply drop in
tomcat (easier).

Tks,
- Eric

Side note: I was fan to embed servers in web containers, but now I prefer to
have all servers separated. If any interaction is need between the container
and the mail server, I use JMX for that.


On 1/04/2011 10:36, Ludwig Magnusson wrote:
Hi!

We are considering using james in our project but after having looked
through the documentation I haven't really understood if what we want
to do is possible or how to do it.



This is our situation:

We have a webapp that is running on several different machines. A
production server, a staging server and all local servers that are
used during development. The problem is that sending mail through our
webapp does not always work because the smtp server at our production
server does not accept mail from certain locations. Sometimes we are
at the mercy of different ISPs that sometimes block mail going out.



We thougt a good solution would be to bundle the james-smtp server
with our webapp. When we start our webapp, we also start the james
smtp-server and send mail through that one. In that case, we would
always have a working mail server and the app would be less
platform-dependent.


I have searched the james documentation but I am having a hard time
finding information about this. I looked in the javadoc for version
2.3 and found a SMTPServer class but that one seems to be missing in
version 3. And version
2 does not seem to be available in the maven repository.



Could anyone point me in the right direction? =)

Thanks

/Ludwig



---------------------------------------------------------------------
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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to