[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by tom.baeyens＠jboss.com
"bradsdavis" wrote : I personally think that in an enterprise environment, the majority of emails won't be synchronous. I think we should make it asynchronous by default and only send synchronously when defined as such.
|
i agree.
but in development we need to go step by step.
let's first develop the synchronous mail functionality. and in a subsequent iteration, add the ability to send them asynchronously.
and then let's work on the configuration options in the global jbpm.cfg.xml and in the jpdl process files.
"bradsdavis" wrote : Also, I think that the content [subject, body, attachments] should be separate from the recipients. The actual produced content may change per a client's need.
| ...
| By making it plugable, anyone can create a producer that extends our base type and adds attachments as needed.
|
such a framework is good and should be build before this interface. the base class should use this MailSession to send emails. Users should be able to configure their customized SendMail activity. The basic SendMail should be designed for inheritence and customization.
but again. let's go step by step. let's first get the basics working and then add the advanced features like this in subsequent iterations.
"bradsdavis" wrote : I think an activity should produce one or more emails and send them to the mail service, which I think you are calling MailSession.
|
| So, I think the interface should look more like:
|
|
| | package org.jbpm.pvm.internal.email.service;
| |
| | import java.util.Collection;
| |
| | import org.apache.commons.mail.Email;
| |
| | public interface MailService {
| | public void send(Collection<Email> emails);
| | }
| |
|
| Because the emails at this point already have their email addresses [to, cc, bcc], body, and attachments defined at the point they are sent to the mail service, there is no need for the mail service to care about:
|
|
| | Mail setTo(String to);
| | Mail setCC(String cc);
| | Mail setBCC(String bcc);
| | Mail setSubject(String subject);
| | Mail setBody(String subject);
| | Mail addAttachment(String name, InputStream attachment, String mimeType);
| |
|
| It would literally just be for servicing the sending of the base class Email.
i don't see why you want to send multiple emails and get rid of the destination properties. can you elaborate on that ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224066#4224066
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224066
17 years
[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by bradsdavis
I personally think that in an enterprise environment, the majority of emails won't be synchronous. I think we should make it asynchronous by default and only send synchronously when defined as such.
Also, I think that the content [subject, body, attachments] should be separate from the recipients. The actual produced content may change per a client's need.
The implementation I was working towards allowed email producers to produce one or more base email type, which internally would be either:
1) Simple emails [think text]
2) Mime emails [think text with attachments]
3) Html emails [templated emails with images, etc]
By making it plugable, anyone can create a producer that extends our base type and adds attachments as needed.
I think an activity should produce one or more emails and send them to the mail service, which I think you are calling MailSession.
So, I think the interface should look more like:
| package org.jbpm.pvm.internal.email.service;
|
| import java.util.Collection;
|
| import org.apache.commons.mail.Email;
|
| public interface MailService {
| public void send(Collection<Email> emails);
| }
|
Because the emails at this point already have their email addresses [to, cc, bcc], body, and attachments defined at the point they are sent to the mail service, there is no need for the mail service to care about:
| Mail setTo(String to);
| Mail setCC(String cc);
| Mail setBCC(String bcc);
| Mail setSubject(String subject);
| Mail setBody(String subject);
| Mail addAttachment(String name, InputStream attachment, String mimeType);
|
It would literally just be for servicing the sending of the base class Email.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224061#4224061
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224061
17 years
[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by tom.baeyens＠jboss.com
"bradsdavis" wrote : OK. I think I have a solution to this.
|
| Both the synchronous and asynchronous emailer will implement the same interface, so they will be interchangeable. The asynchronous will use the synchronous emailler under the hood, it will just be called by the job executor.
Close. I discussed with Alejandro yesterday:
we need a MailSession interface for that. mail session would look something like this
interface MailSession {
| Mail createMail();
| }
|
| interface Mail {
| Mail setTo(String to);
| Mail setCC(String cc);
| Mail setBCC(String bcc);
| Mail setSubject(String subject);
| Mail setBody(String subject);
| Mail addAttachment(String name, InputStream attachment, String mimeType);
|
| void send(boolean sendAsync);
| }
we thought it was easiest to develop something like the interface shown above.
Activies can get a MailSession from the current environment. But we don't need 2 different implementations.
Clients of this code (Activities) would need to determine if sending needs to be done asynchronous or not. this should eventually be based on a global process engine configuration that specifies the default and jpdl attributes that allow to overwrite this default.
Does this match with your expectations, Brad ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224054#4224054
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224054
17 years
[Design of POJO Server] - Re: AS 5 not reliably picking up changes in exploded EAR
by alesj
"jaikiran" wrote :
| Can't something similar be done in ModificationWatcher?
|
This is Wicket code, and it does what it does. :-)
I don't think we can do anything about it.
But that's not the point.
Any other code could do something at undeploy.
And since most of the app servers do temping by default it would work ootb.
e.g. one of our first tests, for minimal config, tests exactly that =
spins off a new thread at undeploy, and tries to load some inner class
Moving Remy's email to this forum thread.
"remy" wrote :
| JBW has a VFS-like abstraction too, so one could write one that monitors
| an "original" folder, compare with what is in the "real" folder, and sync
| them.
|
| ...
|
| JBoss should probably have something to keep the temped stuff in sync
| with the original stuff when it does temping. JBW will pick up changes
| if you update the temp copy.
|
Both ideas sound OK.
But I guess the 2nd one is more general, not limited just to JBW.
I'll probably try to impl something on top of that. ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224053#4224053
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224053
17 years
[Design of POJO Server] - Re: AS 5 not reliably picking up changes in exploded EAR
by jaikiran
Looking at the JIRA which started this Seam specific change https://jira.jboss.org/jira/browse/JBSEAM-3702 , there were 3 logs attached, out of which 2 issues are being addressed separately (https://jira.jboss.org/jira/browse/JBSEAM-4012) and there's no role of VFS in those issues.
The third exception in those logs relates to:
"alesj" wrote :
| Some apps, in this case it was Seam Wicket example app,
| still want to do some resources lookup at undeploy.
| An undeploy which was triggered by the app's dir/archive deletion from deploy/.
| But since the app was deleted there is nowhere to do the lookup from.
The exception stacktrace shows:
2008-11-14 14:14:03,874 INFO [org.jboss.seam.navigation.Pages] (http-127.0.0.1-8080-21) no pages.xml file found: /WEB-INF/pages.xml
| 2008-11-14 14:14:05,245 ERROR [org.apache.wicket.util.thread.Task] (ModificationWatcher Task) Unhandled exception thrown by user code in task ModificationWatcher
| java.lang.RuntimeException: java.io.IOException: Child not found jboss-seam-wicket-booking.ear/jboss-seam-wicket-booking.war/WEB-INF/classes/org/jboss/seam/example/wicket/Home.html for FileHandler@6861787[...]]
| at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getLastModified(VirtualFileURLConnection.java:87)
| at org.apache.wicket.util.resource.UrlResourceStream.lastModifiedTime(UrlResourceStream.java:256)
| at org.apache.wicket.markup.MarkupResourceStream.lastModifiedTime(MarkupResourceStream.java:144)
| at org.apache.wicket.util.watch.ModificationWatcher$1.run(ModificationWatcher.java:176)
| at org.apache.wicket.util.thread.Task$1.run(Task.java:115)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: java.io.IOException: Child not found jboss-seam-wicket-booking.ear/jboss-seam-wicket-booking.war/WEB-INF/classes/org/jboss/seam/example/wicket/Home.html for FileHandler@6861787[...]]
| at org.jboss.virtual.VirtualFile.findChild(VirtualFile.java:431)
| at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.resolveVirtualFile(VirtualFileURLConnection.java:106)
| at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getVirtualFile(VirtualFileURLConnection.java:118)
| at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getLastModified(VirtualFileURLConnection.java:83)
| ... 5 more
| 2008-11-14 14:14:06,248 ERROR [org.apache.wicket.util.thread.Task] (ModificationWatcher Task) Unhandled exception thrown by user code in task ModificationWatcher
| java.lang.RuntimeException: java.io.IOException: Child not found jboss-seam-wicket-booking.ear/jboss-seam-wicket-booking.war/WEB-INF/classes/org/jboss/seam/example/wicket/Home.html for FileHandler@6861787[path= ...]]
| at org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getLastModified(VirtualFileURLConnection.java:87)
|
So there is some ModificationWatcher Task which is polling for any changes to some file, maybe to refresh some cache? If the entire application is deleted, does the ModificationWatcher Task even have to bother about the file change? Maybe we can just log this at DEBUG level instead of ERROR?
>From what i see in the logs, the ModificationWatcher does the same as HDScanner in the AS does? So how does the HDScanner handle similar (deleted) app?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224037#4224037
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224037
17 years