Hello, I just completed the modifications I mentioned in "Mail Problems" earlier. Seems to work just fine. XWiki.sendMessage redirecting to MailSenderPlugin, mail authorization ( = works with any smtp server, local or not), and means to provide additional Java Mail properties in Admin Prefs. I just need to test it a bit more and make patches and demo package. Should be ready in about 12-18 hours tops. Three things though: 1) I still have no idea what about the subject - it just defaults to "XWiki Message" in this version. 2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties. 3) It still needs some sensible defaults and/or documenation for validation / confirmation content. Greetings, Lilianne E. Blaze
Hi Lilianne, Thanks, this is cool. See below. On Jun 13, 2008, at 10:40 AM, Lilianne E. Blaze wrote:
Hello, I just completed the modifications I mentioned in "Mail Problems" earlier. Seems to work just fine.
XWiki.sendMessage redirecting to MailSenderPlugin, mail authorization ( = works with any smtp server, local or not), and means to provide additional Java Mail properties in Admin Prefs.
I just need to test it a bit more and make patches and demo package. Should be ready in about 12-18 hours tops.
Three things though:
1) I still have no idea what about the subject - it just defaults to "XWiki Message" in this version.
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties.
We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components. One solution for now could be to set a dependency on the last released version of core with a provided scope. Thanks -Vincent
3) It still needs some sensible defaults and/or documenation for validation / confirmation content.
Greetings, Lilianne E. Blaze
Hello, Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties.
We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope.
I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working. The only other idea I have is to use reflection instead of direct use, which is not very pretty. Besides, isn't MailSender 'core enough' to be in Core? It's a pretty basic functionality. There are about two dozen different packages in Core / com.xpn.xwiki.plugin already. And what about the other two questions?
Thanks -Vincent
Greetings, Lilianne
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties.
We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope.
I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working.
xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1)
The only other idea I have is to use reflection instead of direct use, which is not very pretty.
Besides, isn't MailSender 'core enough' to be in Core? It's a pretty basic functionality. There are about two dozen different packages in Core / com.xpn.xwiki.plugin already.
Yes, some plugins are core plugins and should be moved to xwiki- platform-core/ directory. But what we don't want is moved them inside xwiki-platform-core/xwiki-core module. I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
And what about the other two questions?
I don't know the answers... Thanks -Vincent
Hi Lilianne, thanks for the great work ! Regarding your issues with setting the email's subject, I think the MailSenderPlugin API should give you an answer : http://code.xwiki.org/xwiki/bin/view/Plugins/MailSenderPlugin Hope this helps, Guillaume On Fri, Jun 13, 2008 at 11:22 AM, Vincent Massol <[email protected]> wrote:
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties.
We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope.
I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working.
xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1)
The only other idea I have is to use reflection instead of direct use, which is not very pretty.
Besides, isn't MailSender 'core enough' to be in Core? It's a pretty basic functionality. There are about two dozen different packages in Core / com.xpn.xwiki.plugin already.
Yes, some plugins are core plugins and should be moved to xwiki- platform-core/ directory. But what we don't want is moved them inside xwiki-platform-core/xwiki-core module.
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
And what about the other two questions?
I don't know the answers...
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Guillaume Lerouge wrote:
Hi Lilianne, thanks for the great work !
Regarding your issues with setting the email's subject, I think the MailSenderPlugin API should give you an answer : http://code.xwiki.org/xwiki/bin/view/Plugins/MailSenderPlugin
I know how to set it. The thing is, XWiki.sendMessage doesn't have 'subject' parameter, and in Admin Prefs there are text areas for mail content, but none for mail subject.
Hope this helps,
Guillaume
Greetings, Lilianne
Lilianne E. Blaze wrote:
Guillaume Lerouge wrote:
Hi Lilianne, thanks for the great work !
Regarding your issues with setting the email's subject, I think the MailSenderPlugin API should give you an answer : http://code.xwiki.org/xwiki/bin/view/Plugins/MailSenderPlugin
I know how to set it.
The thing is, XWiki.sendMessage doesn't have 'subject' parameter, and in Admin Prefs there are text areas for mail content, but none for mail subject.
The way it used to work before is that the first few lines of the message can be additional headers, so you would send a message like: Subject: this is the subject OtherHeaders: value Hi, this is the mail content. You could try to "parse" the message content and see if it starts with something that looks like headers, and if among those headers there's a Subject. Another solution is to augment the sendMessage API, but I'm against it, as it is already deprecated and should not be used anymore, so definitely not enhanced. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hello, Vincent Massol wrote:
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties. We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope. I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working.
xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1)
Make Core snapshot depend on Mailsender snapshot and Mailsender snapshot depend on Core latest? Isn't that... unhealthy?
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
I'm not sure either if it's possible, I only recently started using Maven. But even if it is possible, it _will_ create a circular, and with different versions it's even more nasty. Having to build a previous version to build current version? It sounds more hackish than Windows' leaked alpha version. It should be possible to just check out the current version source and then build it on- or offline.
Thanks -Vincent
Greetings, Lilianne
On Jun 13, 2008, at 12:55 PM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties. We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope. I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working.
xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1)
Make Core snapshot depend on Mailsender snapshot and Mailsender snapshot depend on Core latest? Isn't that... unhealthy?
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
I'm not sure either if it's possible, I only recently started using Maven.
But even if it is possible, it _will_ create a circular, and with different versions it's even more nasty. Having to build a previous version to build current version? It sounds more hackish than Windows' leaked alpha version. It should be possible to just check out the current version source and then build it on- or offline.
Yes but all this is interim while we're breaking the monolithic xwiki- core module. Right now the pb is that the XWikiContext and XWiki objects are mammoth objects that references everything else and thus the XWiki Model cannot be easily moved in its own build module. I haven't looked at the sendmail plugin so I don't know really the extent to which it depends on core apart from the need for the plugin API. I think I remember it has an api for using a document as a mail template. So the best solution is to create an interface for all the plugin needs on core and implement that interface in the core. That's what I did for the new rendering module. Thanks -Vincent
Right, I was thinking about the plugin, not XWiki.sendMessage... This code snippet might help you : ## Email #set ($objet = "Hello World") #set ($mail = "Content-type: text/plain; charset=iso-8859-1${xwiki.nl}To: ${emailtarget}${xwiki.nl}Subject: ${objet}${xwiki.nl}${xwiki.nl} Enter message text here ${xwiki.nl} ") $xwiki.sendMessage($[emailsrc], ${emailtarget}, $mail) where ${emailsrc} & ${emailtarget} are already defined mail addresses (such as "[email protected]" ) It works on a public website... Guillaume On Fri, Jun 13, 2008 at 12:55 PM, Lilianne E. Blaze < [email protected]> wrote:
Hello,
Vincent Massol wrote:
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties. We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope. I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working.
xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1)
Make Core snapshot depend on Mailsender snapshot and Mailsender snapshot depend on Core latest? Isn't that... unhealthy?
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
I'm not sure either if it's possible, I only recently started using Maven.
But even if it is possible, it _will_ create a circular, and with different versions it's even more nasty. Having to build a previous version to build current version? It sounds more hackish than Windows' leaked alpha version. It should be possible to just check out the current version source and then build it on- or offline.
Thanks -Vincent
Greetings, Lilianne
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties. We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope. I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working. xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1)
Make Core snapshot depend on Mailsender snapshot and Mailsender snapshot depend on Core latest? Isn't that... unhealthy?
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
I'm not sure either if it's possible, I only recently started using Maven.
But even if it is possible, it _will_ create a circular, and with different versions it's even more nasty. Having to build a previous version to build current version? It sounds more hackish than Windows' leaked alpha version. It should be possible to just check out the current version source and then build it on- or offline.
Not exactly, as you don't have to build a previous core. A released version is never built, it is taken from the repository. So like you depend on a released (final and public) commons-logging-1.1.1, you depend on a released (final and public) xwiki-core-1.4.1, which will not be used except when building, because it is declared as "provided", which means that a compatible version will be available where the plugin will be used. This "provided" scope is used to allow plugins to be reused with different core versions, as otherwise we would need to re-release each plugin whenever we release core. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
2) It needed mailsender plugin moved from plugins module to core module to avoid circulars and other nasties. We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope. I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working. xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1) Make Core snapshot depend on Mailsender snapshot and Mailsender snapshot depend on Core latest? Isn't that... unhealthy?
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it. I'm not sure either if it's possible, I only recently started using Maven.
But even if it is possible, it _will_ create a circular, and with different versions it's even more nasty. Having to build a previous version to build current version? It sounds more hackish than Windows' leaked alpha version. It should be possible to just check out the current version source and then build it on- or offline.
Not exactly, as you don't have to build a previous core. A released version is never built, it is taken from the repository. So like you depend on a released (final and public) commons-logging-1.1.1, you depend on a released (final and public) xwiki-core-1.4.1, which will not be used except when building, because it is declared as "provided", which means that a compatible version will be available where the plugin will be used. This "provided" scope is used to allow plugins to be reused with different core versions, as otherwise we would need to re-release each plugin whenever we release core.
Could you please tell me what exactly I need to change and where? I tried making core-core depend on mailsender: <dependency> <groupId>com.xpn.xwiki.platform.plugins</groupId> <artifactId>xwiki-plugin-mailsender</artifactId> <version>1.3</version> <scope>provided</scope> </dependency> Same: The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender'}' and 'Vertex{label='com.xpn.xwiki.platform:xwiki-core'}' introduces to cycle in the graph com.xpn.xwiki.platform:xwiki-core --> com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender --> com.xpn.xwiki.platform:xwiki-core Either I'm still doing something wrong, or circulars just aren't allowed at all no matter the versions. My only B-plan is making it work with reflection, and trust me, it won't be any prettier than monolithic code :/ Greetings, Lilianne
Lilianne E. Blaze wrote:
Sergiu Dumitriu wrote:
Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
On Jun 13, 2008, at 11:17 AM, Lilianne E. Blaze wrote:
Hello,
Vincent Massol wrote:
> 2) It needed mailsender plugin moved from plugins module to core > module > to avoid circulars and other nasties. We need to find a solution for this since we'd like to keep the modules separate. This is actually our current effort: modularize XWiki and move everything to components.
One solution for now could be to set a dependency on the last released version of core with a provided scope. I'm not sure I get it. MailSender depending on Core isn't the problem. The problem is Core depending on MailSender to get the glue code in XWiki.sendMessage working. xwiki-core SNAPSHOT --> mailsender plugin SNAPSHOT version mailsender --> xwiki-core LATEST (i.e. 1.5M1 or 1.4.1) Make Core snapshot depend on Mailsender snapshot and Mailsender snapshot depend on Core latest? Isn't that... unhealthy?
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it. I'm not sure either if it's possible, I only recently started using Maven.
But even if it is possible, it _will_ create a circular, and with different versions it's even more nasty. Having to build a previous version to build current version? It sounds more hackish than Windows' leaked alpha version. It should be possible to just check out the current version source and then build it on- or offline. Not exactly, as you don't have to build a previous core. A released version is never built, it is taken from the repository. So like you depend on a released (final and public) commons-logging-1.1.1, you depend on a released (final and public) xwiki-core-1.4.1, which will not be used except when building, because it is declared as "provided", which means that a compatible version will be available where the plugin will be used. This "provided" scope is used to allow plugins to be reused with different core versions, as otherwise we would need to re-release each plugin whenever we release core.
Could you please tell me what exactly I need to change and where?
I tried making core-core depend on mailsender:
<dependency> <groupId>com.xpn.xwiki.platform.plugins</groupId> <artifactId>xwiki-plugin-mailsender</artifactId> <version>1.3</version> <scope>provided</scope> </dependency>
Same:
The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender'}' and 'Vertex{label='com.xpn.xwiki.platform:xwiki-core'}' introduces to cycle in the graph com.xpn.xwiki.platform:xwiki-core --> com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender --> com.xpn.xwiki.platform:xwiki-core
Either I'm still doing something wrong, or circulars just aren't allowed at all no matter the versions.
In mailsender/pom.xml: <dependency> <groupId>com.xpn.xwiki.platform</groupId> <artifactId>xwiki-core</artifactId> <version>1.4.1</version> <scope>provided</scope> </dependency> in xwiki-core/pom.xml: <dependency> <groupId>com.xpn.xwiki.platform.plugins</groupId> <artifactId>xwiki-plugin-mailsender</artifactId> <version>1.4-SNAPSHOT</version> </dependency> This works for me.
My only B-plan is making it work with reflection, and trust me, it won't be any prettier than monolithic code :/
I know, using reflection is NOT the right approach. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
I tried making core-core depend on mailsender:
<dependency> <groupId>com.xpn.xwiki.platform.plugins</groupId> <artifactId>xwiki-plugin-mailsender</artifactId> <version>1.3</version> <scope>provided</scope> </dependency>
Same:
The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender'}' and 'Vertex{label='com.xpn.xwiki.platform:xwiki-core'}' introduces to cycle in the graph com.xpn.xwiki.platform:xwiki-core --> com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender --> com.xpn.xwiki.platform:xwiki-core
Either I'm still doing something wrong, or circulars just aren't allowed at all no matter the versions.
In mailsender/pom.xml:
<dependency> <groupId>com.xpn.xwiki.platform</groupId> <artifactId>xwiki-core</artifactId> <version>1.4.1</version> <scope>provided</scope> </dependency>
in xwiki-core/pom.xml:
<dependency> <groupId>com.xpn.xwiki.platform.plugins</groupId> <artifactId>xwiki-plugin-mailsender</artifactId> <version>1.4-SNAPSHOT</version> </dependency>
This works for me.
Yes and no. I can "install" core-core, mailsender, hsqldb demo, but when I try to "install" the top level pom it fails with: [ERROR]BUILD FAILURE ------------------------------------------------------------------------ The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender'}' and 'Vertex{label='com.xpn.xwiki.platform:xwiki-core'}' introduces to cycle in the graph com.xpn.xwiki.platform:xwiki-core --> com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender --> com.xpn.xwiki.platform:xwiki-core So it doesn't seem to be the right approach. Greetings, Lilianne
Lilianne E. Blaze wrote:
In mailsender/pom.xml:
<dependency> <groupId>com.xpn.xwiki.platform</groupId> <artifactId>xwiki-core</artifactId> <version>1.4.1</version> <scope>provided</scope> </dependency>
in xwiki-core/pom.xml:
<dependency> <groupId>com.xpn.xwiki.platform.plugins</groupId> <artifactId>xwiki-plugin-mailsender</artifactId> <version>1.4-SNAPSHOT</version> </dependency>
This works for me.
Yes and no.
I can "install" core-core, mailsender, hsqldb demo, but when I try to "install" the top level pom it fails with:
[ERROR]BUILD FAILURE ------------------------------------------------------------------------ The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender'}' and 'Vertex{label='com.xpn.xwiki.platform:xwiki-core'}' introduces to cycle in the graph com.xpn.xwiki.platform:xwiki-core --> com.xpn.xwiki.platform.plugins:xwiki-plugin-mailsender --> com.xpn.xwiki.platform:xwiki-core
So it doesn't seem to be the right approach.
Yes, you are right... I didn't try to build the whole trunks. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Vincent Massol wrote:
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
Yup, Maven says it's circular and refuses to cooperate. Either it just doesn't work and that's it, or my experience with Maven is insufficient to make it work. Anyway - couldn't we just move mailsender into core for now, make it work, and worry about separating it later? Pretty please. Greetings, Lilianne
On Jun 13, 2008, at 3:39 PM, Lilianne E. Blaze wrote:
Vincent Massol wrote:
I'm not sure my solution works with maven. It might still create a circular dep but it's worth verifying it.
Yup, Maven says it's circular and refuses to cooperate.
Either it just doesn't work and that's it, or my experience with Maven is insufficient to make it work.
Anyway - couldn't we just move mailsender into core for now, make it work, and worry about separating it later? Pretty please.
ok, after more thoughts, here's the solution I propose: 1) move code into a package in xwiki-core/ (and later create a component proper in a different module) 2) keep the mailsender plugin but make it use the code from xwiki- core/ (and later from the component proper) 3) make current core code use the new package ok with everyone? Thanks -Vincent PS: Note that the notion of plugins will disappear in the future when we'll implement the solution for making components available from velocity/groovy.
Lilianne E. Blaze wrote:
Besides, isn't MailSender 'core enough' to be in Core? It's a pretty basic functionality. There are about two dozen different packages in Core / com.xpn.xwiki.plugin already.
Those that are there are only because nobody had time to move them yet. Initially all plugins were there, as the entire XWiki code was monolithic. We don't want to move things inside the core, but always outside. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Attaching diff. Note it's not the whole thing, and probably not final. Greetings, Lilianne # This patch file was generated by NetBeans IDE # Following Index: paths are relative to: D:\Work\Java\Open_Source\xwiki-trunks\xwiki-platform-core\xwiki-core\src\main\java # This patch can be applied using context Tools: Patch action on respective folder. # It uses platform neutral UTF-8 encoding and \n newlines. # Above lines and this line are ignored by the patching process. Index: com/xpn/xwiki/plugin/mailsender/MailConfiguration.java --- com/xpn/xwiki/plugin/mailsender/MailConfiguration.java Base (BASE) +++ com/xpn/xwiki/plugin/mailsender/MailConfiguration.java Locally Modified (Based On LOCAL) @@ -19,7 +19,12 @@ */ package com.xpn.xwiki.plugin.mailsender; +import java.util.Properties; +import java.util.Enumeration; + import com.xpn.xwiki.api.XWiki; +import java.io.IOException; +import java.io.StringReader; /** * Represents a Mail Server configuration. @@ -29,7 +34,11 @@ private int port; private String host; private String from; + private String smtpUsername; + private String smtpPassword; + private Properties extraProperties; + public MailConfiguration() { setPort(25); @@ -49,8 +58,26 @@ if (from.length() > 0) { setFrom(from); } + + String smtpServerUsername = + xwiki.getXWikiPreference("smtp_server_username", ""); + String smtpServerPassword = + xwiki.getXWikiPreference("smtp_server_password", ""); + if ((smtpServerUsername.length() > 0) && + (smtpServerPassword.length() > 0)) + { + setSmtpUsername(smtpServerUsername); + setSmtpPassword(smtpServerPassword); } + String javaMailExtraProps = + xwiki.getXWikiPreference("javamail_extra_props", ""); + if (javaMailExtraProps.length() > 0) + { + setExtraPropertiesAsString(javaMailExtraProps); + } + } + public void setHost(String host) { this.host = host; @@ -81,6 +108,88 @@ return this.from; } + public void setSmtpUsername(String smtpUsername) + { + this.smtpUsername = smtpUsername; + } + + public String getSmtpUsername() + { + return smtpUsername; + } + + public void setSmtpPassword(String smtpPassword) + { + this.smtpPassword = smtpPassword; + } + + public String getSmtpPassword() + { + return smtpPassword; + } + + public boolean areSmtpUsernameAndPasswordSet() + { + return (getSmtpUsername() != null && getSmtpUsername().length() > 0) && + (getSmtpPassword() != null && getSmtpPassword().length() > 0); + } + + public void setExtraPropertiesAsString(String extraPropertiesString) + { + if (extraPropertiesString == null || + extraPropertiesString.trim().length() == 0) + { + extraProperties = null; + } + else + { + StringReader sr = new StringReader(extraPropertiesString); + extraProperties = new Properties(); + try + { + extraProperties.load(sr); + } + catch(IOException e) + { + throw new RuntimeException( + "WTF? IOException here shouldn't be possible."); + } + } + } + + /** + * Add extraProperties to an external Properties object + * + * @param externalProperties + * @param overwrite + */ + public void appendExtraPropertiesTo(Properties externalProperties, + boolean overwrite) + { + // sanity check + if( externalProperties == null ) + { + throw new IllegalArgumentException( + "externalProperties can't be null"); + } + + if (extraProperties != null && extraProperties.size() > 0) + { + Enumeration propNames = extraProperties.propertyNames(); + while (propNames.hasMoreElements()) + { + String propName = (String)propNames.nextElement(); + String propValue = extraProperties.getProperty(propName); + + if (overwrite || + externalProperties.getProperty(propName) == null) + { + externalProperties.setProperty(propName, propValue); + } + } + } + } + public String toString() { StringBuffer buffer = new StringBuffer(); @@ -95,6 +204,12 @@ buffer.append(", Port [" + getPort() + "]"); + if( areSmtpUsernameAndPasswordSet() ) + { + buffer.append(", Username [" + getSmtpUsername() + "]"); + buffer.append(", Password [*****]"); + } + return buffer.toString(); } } Index: com/xpn/xwiki/plugin/mailsender/MailSenderPlugin.java --- com/xpn/xwiki/plugin/mailsender/MailSenderPlugin.java Base (BASE) +++ com/xpn/xwiki/plugin/mailsender/MailSenderPlugin.java Locally Modified (Based On LOCAL) @@ -73,6 +73,8 @@ * @see MailSender * @version $Id: $ */ +// DEV NOTE: main JavaMail code is in sendMails method, near line 550. +// note that most settings are initialized in MailConfiguration constructor. public class MailSenderPlugin extends XWikiDefaultPlugin { /** @@ -108,6 +110,7 @@ */ public void init(XWikiContext context) { + LOG.debug("Entering init(...)..."); try { initMailClass(context); } catch (Exception e) { @@ -122,6 +125,7 @@ */ public void virtualInit(XWikiContext context) { + LOG.debug("Entering virtualInit(...)..."); try { initMailClass(context); } catch (Exception e) { @@ -428,6 +432,13 @@ properties.put("mail.smtp.from", mailConfiguration.getFrom()); } + if (mailConfiguration.areSmtpUsernameAndPasswordSet() ) + { + properties.put("mail.smtp.auth", "true"); + } + + mailConfiguration.appendExtraPropertiesTo(properties, true); + return properties; } @@ -552,12 +563,26 @@ LOG.info("Sending email: " + mail.toString()); if ((transport == null) || (session == null)) { + + // initialize JavaMail Session and Transport Properties props = initProperties(mailConfiguration); session = Session.getDefaultInstance(props, null); transport = session.getTransport("smtp"); + + if (!mailConfiguration.areSmtpUsernameAndPasswordSet() ) + { + // no auth info - typical 127.0.0.1 open relay scenario transport.connect(); } + else + { + // auth info present - typical with external smtp server + transport.connect(mailConfiguration.getSmtpUsername(), + mailConfiguration.getSmtpPassword()); + } + } + try { MimeMessage message = createMimeMessage(mail, session, context); Index: com/xpn/xwiki/XWiki.java --- com/xpn/xwiki/XWiki.java Base (BASE) +++ com/xpn/xwiki/XWiki.java Locally Modified (Based On LOCAL) @@ -118,6 +118,7 @@ import com.xpn.xwiki.objects.meta.MetaClass; import com.xpn.xwiki.plugin.XWikiPluginInterface; import com.xpn.xwiki.plugin.XWikiPluginManager; +import com.xpn.xwiki.plugin.mailsender.MailSenderPluginApi; import com.xpn.xwiki.plugin.query.QueryPlugin; import com.xpn.xwiki.plugin.query.XWikiCriteria; import com.xpn.xwiki.plugin.query.XWikiQuery; @@ -2711,10 +2712,9 @@ needsUpdate |= bclass.addTextAreaField("menu", "Menu", 60, 8); needsUpdate |= bclass.addTextAreaField("meta", "HTTP Meta Info", 60, 8); + // registration needsUpdate |= bclass.addBooleanField("use_email_verification", "Use eMail Verification", "yesno"); - needsUpdate |= bclass.addTextField("smtp_server", "SMTP Server", 30); - needsUpdate |= bclass.addTextField("admin_email", "Admin eMail", 30); needsUpdate |= bclass.addTextAreaField("validation_email_content", "Validation eMail Content", 72, 10); @@ -2725,6 +2725,13 @@ bclass.addTextAreaField("invitation_email_content", "Invitation eMail Content", 72, 10); + // mail + needsUpdate |= bclass.addTextField("admin_email", "Admin eMail", 30); + needsUpdate |= bclass.addTextField("smtp_server", "SMTP Server", 30); + needsUpdate |= bclass.addTextField("smtp_server_username", "SMTP Server username (optional)", 30); + needsUpdate |= bclass.addTextField("smtp_server_password", "SMTP Server password (optional)", 30); + needsUpdate |= bclass.addTextAreaField("javamail_extra_props", "Additional JavaMail properties", 60, 6); + needsUpdate |= bclass.addTextField("macros_languages", "Macros Languages", 60); needsUpdate |= bclass.addTextField("macros_velocity", "Macros for Velocity", 60); needsUpdate |= bclass.addTextField("macros_groovy", "Macros for Groovy", 60); @@ -3207,6 +3214,63 @@ public void sendMessage(String sender, String[] recipient, String message, XWikiContext context) throws XWikiException { + // TODO - provide some sensible default + String subject = "XWiki message"; + + sendMessage(sender, recipient, subject, message, context); + } + + /** + * @deprecated replaced by the <a + * href="http://code.xwiki.org/xwiki/bin/view/Plugins/MailSenderPlugin">Mail Sender + * Plugin</a> + */ + public void sendMessage(String sender, String[] recipient, String subject, + String message, XWikiContext context) throws XWikiException + { + LOG.debug("Entering sendMessage(...)..."); + + MailSenderPluginApi mailSenderApi = + (MailSenderPluginApi)getPluginApi("mailsender", context); + + LOG.debug("mailSenderApi = " + mailSenderApi); + + LOG.debug("sender = " + sender); + LOG.debug("recipient.length = " + recipient.length); + for(int i = 0; i < recipient.length; i++) + { + LOG.debug("recipient[" + i + "] = " + recipient[i]); + } + LOG.debug("subject = " + subject); + LOG.debug("message = " + message); + LOG.debug("context = " + context); + + String recipientsAsString = recipient[0]; + for(int i = 1; i < recipient.length; i++) + { + recipientsAsString = recipientsAsString + "," + recipient[i]; + } + + + int result = mailSenderApi.sendTextMessage(sender, recipientsAsString, + subject, message); + + // note: -1 is magic number for any error + if( result == -1 ) + { + String errorString = (String)context.get("error"); + XWikiException xwe = + new XWikiException(XWikiException.MODULE_XWIKI_EMAIL, + XWikiException.ERROR_XWIKI_EMAIL_ERROR_SENDING_EMAIL, + errorString); + LOG.error(xwe, xwe); + throw xwe; + } + + LOG.debug("Exiting sendMessage(...). It seems everything went ok."); + + + /* SMTPClient smtpc = null; try { String server = getXWikiPreference("smtp_server", context); @@ -3269,6 +3333,7 @@ } } } + */ } /**
Lilianne E. Blaze wrote:
3) It still needs some sensible defaults and/or documenation for validation / confirmation content.
There were some answers on the mailing list in the past, searching on the mailing lists could help. First result: http://xwiki.markmail.org/search/?q=validation%20confirmation#query:validati... -- Sergiu Dumitriu http://purl.org/net/sergiu/
Sergiu Dumitriu wrote:
Lilianne E. Blaze wrote:
3) It still needs some sensible defaults and/or documenation for validation / confirmation content.
There were some answers on the mailing list in the past, searching on the mailing lists could help.
First result: http://xwiki.markmail.org/search/?q=validation%20confirmation#query:validati...
There's just one problem - I can't find RegisterNewUserConfirmation anywhere. I tried searching it in filenames in xwiki-trunks, tried searching for "RegisterNewUserConfirmation" inside all files, nothing. Is it still present in the current version? Greetings, Lilianne
participants (4)
-
Guillaume Lerouge -
Lilianne E. Blaze -
Sergiu Dumitriu -
Vincent Massol