Don't drop the ball Ruben I'm counting on you =). Seriously notifications are critically missing from Matterhorn, IMHO for complex distributed systems it's a requirement not a feature. Rather than just for the workflows is there a way to generalize so it could be leveraged by Matterhorn as a whole? Maybe an email notifications service?
J. On Mar 27, 2012, at 10:37 AM, Rubén Pérez wrote: > Well, after turning my mind upside down, I haven't figured out how to make > this work. > > Basically I added the dependence geronimo-javamail_1.4_mail, which apparently > resolved the ClassLoader issue Chris and Josh once talked about, and modified > felix's system.properties to load that jar on startup. > > However, when I run the operation, I get the following error: > > ERROR (WorkflowOperationWorker:156) - Workflow operation 'send-email' failed > javax.mail.NoSuchProviderException: Unable to load class for provider: > protocol=smtp; type=javax.mail.Provider$Type@3fc4819b; > class=org.apache.geronimo.javamail.transport.smtp.SMTPTransport; > vendor=Apache Software Foundation;version=1.0 > at javax.mail.Session.getService(Session.java:494) > at javax.mail.Session.getTransport(Session.java:387) > at javax.mail.Session.getTransport(Session.java:347) > at javax.mail.Session.getTransport(Session.java:376) > at javax.mail.Transport.send(Transport.java:67) > at javax.mail.Transport.send(Transport.java:48) > at > org.opencastproject.workflow.handler.EmailWorkflowOperationHandler.start(EmailWorkflowOperationHandler.java:141) > at > org.opencastproject.workflow.impl.WorkflowOperationWorker.start(WorkflowOperationWorker.java:216) > at > org.opencastproject.workflow.impl.WorkflowOperationWorker.execute(WorkflowOperationWorker.java:138) > at > org.opencastproject.workflow.impl.WorkflowServiceImpl.runWorkflowOperation(WorkflowServiceImpl.java:704) > at > org.opencastproject.workflow.impl.WorkflowServiceImpl.process(WorkflowServiceImpl.java:1412) > at > org.opencastproject.workflow.impl.WorkflowServiceImpl$JobRunner.call(WorkflowServiceImpl.java:1717) > at > org.opencastproject.workflow.impl.WorkflowServiceImpl$JobRunner.call(WorkflowServiceImpl.java:1690) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.ClassNotFoundException: > org.apache.geronimo.javamail.transport.smtp.SMTPTransport not found by > org.apache.geronimo.specs.geronimo-javamail_1.4_spec [64] > at > org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:812) > at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72) > at > org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1801) > at java.lang.ClassLoader.loadClass(ClassLoader.java:247) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at > org.apache.geronimo.osgi.locator.ProviderLocator.loadClass(ProviderLocator.java:195) > at javax.mail.Session.getService(Session.java:492) > ... 17 more > > It seems to me that there are still issues with the Classloader, but I'm a > little lost with Felix configuration. Maybe somebody with a deeper knowledge > in the matter (Tobias?) could shed some light on this. > > Any help will be very much appreciated. > > Best regards > Rubén > > 2012/3/8 Christopher Brooks <[email protected]> > That's pretty dope Stephen. > > Ruben, you might want to check out the email workflow operation handler > I was working on way back: > > http://opencast.jira.com/svn/MH/contrib/workflow-operation-handlers/1.1.x/EmailWorkflowOperationHandler/ > > The issue with it was embedding smtp libs in osgi seems to be a huge > pain. This might well have been solved (Josh and I at one time had > talked about the geronimo libraries for this). > > We would happily use such a handler if you managed to finish it (or > create another), > > Chris > > On Thu, 08 Mar 2012 18:31:35 +0200 > Stephen Marquard <[email protected]> wrote: > > > We would also like such an operation handler. As an alternate > > approach, we have implemented some integration between our local JIRA > > instance and Matterhorn. > > > > For example this script creates a task in JIRA for each workflow in > > Failed state: > > > > http://source.cet.uct.ac.za/svn/sakai/scripts/trunk/jirasms/mhfailed.pl > > > > The referenced include files are here: > > > > http://source.cet.uct.ac.za/svn/matterhorn/scripts/ > > > > Happy to share more info if anyone else is interested in Matterhorn - > > JIRA integration. > > > > Cheers > > Stephen > > > > > > Stephen Marquard, Acting Director > > Centre for Educational Technology, University of Cape Town > > http://www.cet.uct.ac.za > > Email/IM/XMPP: [email protected] > > Phone: +27-21-650-5037 Cell: +27-83-500-5290 > > > > > > > > >>> Rubén Pérez<[email protected]> 3/8/2012 6:08 PM >>> > > Dear list, > > > > I know there was some discussion at some point as to create a "Send > > Mail" operation handler for informing about some thing gone wrong > > (i.e. a failed workflow). > > > > Even if we run the risk of overloading mail servers within hours > > (kidding...), has anyone developed something similar? If nobody have, > > I'll maybe write an operation handler for that, since email > > notifications are quite common around the Op. or Tech. guys here. > > > > Please share your input. > > > > Best regards > > Rubén > > > > > > > > > > > > ### > > > > UNIVERSITY OF CAPE TOWN > > > > This e-mail is subject to the UCT ICT policies and e-mail disclaimer > > published on our website at > > http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable > > from +27 21 650 9111. This e-mail is intended only for the person(s) > > to whom it is addressed. If the e-mail has reached you in error, > > please notify the author. If you are not the intended recipient of > > the e-mail you may not use, disclose, copy, redirect or print the > > content. If this e-mail is not related to the business of UCT it is > > sent by the sender in the sender's individual capacity. > > > > ### > > > > > > _______________________________________________ > > Matterhorn mailing list > > [email protected] > > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > > > > To unsubscribe please email > > [email protected] > > _______________________________________________ > > > > -- > Christopher Brooks, BSc, MSc > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
