[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by tom.baeyens＠jboss.com
"bradsdavis" wrote : When you write something to intentionally limit the scope, some client will inevitably need the functionality that you are limiting. If you write something that is open and flexible, clients will find uses for it that you never even thought of.
|
| With that in mind, if both cost the same as far as time, I am just saying side with the flexible approach rather than the limiting approach.
i'm differentiating between MailSession and the jpdl features.
MailSession is an api that mainly should be used by our jpdl implementation intenally.
jpdl features documented in the userguide must be stable. so that's why i want to go slowly on that front. i am ok with adding lots of jpdl features and only documenting them in the developer guide. consider this kind of incubation system inside of jbpm. the ultimate target of jpdl is that it will have stable, flexible and lots of features documented in the userguide.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224088#4224088
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224088
17 years
[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by tom.baeyens＠jboss.com
"bradsdavis" wrote : I dont see the benefit of limiting the email producer to one email.
|
| To code that in jbpm 3 would mean creating a dynamic fork, and forking over the email node multiple times, or creating a loop in the process and looping over for each person.
|
| Not only is this inefficient [multiple forks or looping would produce a lot more records in logging, more records for tokens, etc] versus just allowing the email node to produce multiple emails, it is also messy looking in the process definition.
|
| If we get a generic service for sending email for free, why not? It is free, and it allows much more flexibility.
this MailSession does not limit the jpdl email language features that we want to build on top of it.
we could still have something like eg
<mail to-groups="sales-dept, #{claim.type.department}" send-individually="true">
| ...
| </mail>
and internally, the mail activity can translate that to first obtaining all users to which this email is to be sent. and then send a mail with the MailSession for each user that is supposed to receive a mail.
the main point i try to make is that the jpdl attributes and behaviour is decoupled from the MailSession interface.
buiding out the jpdl language attributes is the biggest challenge imo. we should not introduce attributes lightly. after we release GA, we cannot just remove, change or rename attributes.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224087#4224087
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224087
17 years
[Design of JBoss jBPM] - Re: jBPM 4 Emails Sync vs Async
by bradsdavis
The email object itself contains the destination properties.
An email itself depending on its type [simple, mime, html] has different content types. The base email object always has to, cc, bcc.
See: http://commons.apache.org/email/userguide.html
The sending of multiple emails is to add flexibility. Generally you will want to produce one email with multiple to/cc/bccs defined. However, there is a business case where the email producer could produce multiple emails with one to address. An example would be a customer facing email.
Let's say a healthcare company needs to produce an email to all of its patients. They could create a custom email producer that produces multiple emails, one for each patient, personallized to that patient. Each email containing one to address, the patients. Maybe the business process is as follows.
Office closed business process.
1) Send email to each patient telling them their appointment has been cancelled, and to call us.
2) Send email to all practitioners to tell them not to come in.
For the patient emails, the email maybe should read "Brad Davis, your appointment for 10:00 AM has been canceled due to inclement weather." But this should be per patient. So, yours reads "Tom Baeyens, your appointment for 11:00 AM has been canceled due to inclement weather." and so on and so forth.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224075#4224075
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224075
17 years
[Design of POJO Server] - Re: AS 5 not reliably picking up changes in exploded EAR
by jaikiran
"alesj" wrote :
| This is Wicket code, and it does what it does. :-)
| I don't think we can do anything about it.
|
Yep, that's correct. I meant the code could be changed in the wicket/seam :)
"alesj" wrote :
| 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.
|
So then the original question remains about 4.x:
anonymous wrote :
| How did we then handle resources lookup at undeploy (when the app was deleted)?
| I guess we didn't. :-)
I decided to give this a try with a simple WAR which has a ServletContextListener which on contextDestroyed, looks up a properties file within the WAR:
public class MyServletContextListener implements ServletContextListener {
|
| public void contextDestroyed(ServletContextEvent event) {
| System.out.println("Destroying " + event.getServletContext());
| ServletContext servletCtx = event.getServletContext();
| InputStream inputStream = servletCtx.getResourceAsStream("test.properties");
| System.out.println("Got stream while destroying " + inputStream);
| Properties props = new Properties();
| try {
| props.load(inputStream);
| System.out.println("Loaded props");
| } catch (Exception e)
| {
| System.out.println("Error loading props");
| e.printStackTrace();
| }
|
| }
|
Here are the results on AS-4.2.3 GA:
When the WAR is deployed in archived format, and i delete it from the deploy folder when the server is up, i see that the ServletContextListener is able to still lookup the test.properties file (since the archived deployments are temp'd):
19:48:57,038 INFO [STDOUT] Destroying org.apache.catalina.core.ApplicationContextFacade@6e056e
| 19:48:57,038 INFO [STDOUT] Got stream while destroying java.io.ByteArrayInputStream@a3bb2e
| 19:48:57,038 INFO [STDOUT] Loaded props
|
When the WAR is deployed in exploded format and i delete it from the deploy folder, the ServletContextListener is not able to lookup that test.properties file (since the exploded deployment are not temp'd and original file is gone):
| 19:47:26,638 INFO [STDOUT] Destroying org.apache.catalina.core.ApplicationContextFacade@b2771
| 19:47:26,639 INFO [STDOUT] Got stream while destroying null
| 19:47:26,639 INFO [STDOUT] Error loading props
| 19:47:26,639 ERROR [STDERR] java.lang.NullPointerException
| 19:47:26,641 ERROR [STDERR] at java.util.Properties$LineReader.readLine(Properties.java:365)
| 19:47:26,641 ERROR [STDERR] at java.util.Properties.load(Properties.java:293)
| 19:47:26,641 ERROR [STDERR] at org.myapp.servlet.MyServletContextListener.contextDestroyed(MyServletContextListener.java:26)
| 19:47:26,641 ERROR [STDERR] at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3895)
| 19:47:26,641 ERROR [STDERR] at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4527)
| 19:47:26,641 ERROR [STDERR] at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1163)
| 19:47:26,642 ERROR [STDERR] at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4617)
| 19:47:26,642 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| 19:47:26,642 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| 19:47:26,642 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 19:47:26,642 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 19:47:26,642 ERROR [STDERR] at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:296)
| 19:47:26,643 ERROR [STDERR] at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
| 19:47:26,643 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| 19:47:26,643 ERROR [STDERR] at org.jboss.web.tomcat.service.TomcatDeployer.performUndeployInternal(TomcatDeployer.java:461)
| 19:47:26,643 ERROR [STDERR] at org.jboss.web.tomcat.service.TomcatDeployer.performUndeploy(TomcatDeployer.java:432)
| 19:47:26,643 ERROR [STDERR] at org.jboss.web.AbstractWebDeployer.stop(AbstractWebDeployer.java:422)
| 19:47:26,643 ERROR [STDERR] at org.jboss.web.WebModule.stopModule(WebModule.java:100)
| 19:47:26,643 ERROR [STDERR] at org.jboss.web.WebModule.stopService(WebModule.java:66)
| 19:47:26,644 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
| 19:47:26,644 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
| 19:47:26,644 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
| 19:47:26,644 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 19:47:26,644 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 19:47:26,644 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| 19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| 19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| 19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| 19:47:26,645 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| 19:47:26,645 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
| 19:47:26,645 ERROR [STDERR] at $Proxy0.stop(Unknown Source)
| 19:47:26,645 ERROR [STDERR] at org.jboss.system.ServiceController.stop(ServiceController.java:508)
| 19:47:26,646 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| 19:47:26,646 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| 19:47:26,646 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 19:47:26,646 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 19:47:26,646 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| 19:47:26,646 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| 19:47:26,647 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
| 19:47:26,647 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| 19:47:26,647 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| 19:47:26,647 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| 19:47:26,647 ERROR [STDERR] at $Proxy44.stop(Unknown Source)
| 19:47:26,647 ERROR [STDERR] at org.jboss.web.AbstractWebContainer.stop(AbstractWebContainer.java:498)
| 19:47:26,647 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| 19:47:26,648 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| 19:47:26,648 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 19:47:26,648 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 19:47:26,648 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| 19:47:26,648 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| 19:47:26,648 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| 19:47:26,649 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| 19:47:26,649 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| 19:47:26,649 ERROR [STDERR] at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
| 19:47:26,649 ERROR [STDERR] at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
| 19:47:26,649 ERROR [STDERR] at org.jboss.wsf.container.jboss42.DeployerInterceptor.stop(DeployerInterceptor.java:98)
| 19:47:26,649 ERROR [STDERR] at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
| 19:47:26,649 ERROR [STDERR] at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
| 19:47:26,650 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| 19:47:26,650 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| 19:47:26,650 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| 19:47:26,650 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| 19:47:26,650 ERROR [STDERR] at $Proxy45.stop(Unknown Source)
| 19:47:26,650 ERROR [STDERR] at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
| 19:47:26,650 ERROR [STDERR] at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
| 19:47:26,651 ERROR [STDERR] at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:632)
| 19:47:26,651 ERROR [STDERR] at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:615)
| 19:47:26,651 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| 19:47:26,651 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| 19:47:26,651 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 19:47:26,651 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:585)
| 19:47:26,652 ERROR [STDERR] at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
| 19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| 19:47:26,652 ERROR [STDERR] at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
| 19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| 19:47:26,652 ERROR [STDERR] at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
| 19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| 19:47:26,652 ERROR [STDERR] at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| 19:47:26,653 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| 19:47:26,653 ERROR [STDERR] at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| 19:47:26,653 ERROR [STDERR] at $Proxy9.undeploy(Unknown Source)
| 19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.undeploy(URLDeploymentScanner.java:450)
| 19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:570)
| 19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
| 19:47:26,653 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
| 19:47:26,654 ERROR [STDERR] at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
|
So that answers the question - we did not support this even in 4.x with exploded deployments.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4224070#4224070
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4224070
17 years