[JUDDI-591] Add support for email alerts for Subscription API

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.1.5
• Assignee: Kurt Stam
• Reporter: Alex O'Ree
• Created: 14/Apr/13 23:52
• Updated: 04/May/13 23:37
• Resolved: 04/May/13 23:37

Description

Referencing 5.5.8 save_subscription of the subscription API, (pist... Kurt said this part wasn't written)

bindingKey: This optional argument of type anyURI specifies the bindingTemplate which the node is to use to deliver notifications to subscription listeners. It is only required when asynchronous notifications are used. This bindingTemplate MUST define either a Web service that implements notify_subscriptionListener (see below), or an email address to receive the notifications. If a notify_subscriptionListener Web service is identified, the node invokes it to deliver notifications. If an email address is identified, the node delivers notifications via email to the address supplied. When notifications are delivered via email, the body of the email contains the body of the SOAP message, which would have been sent to the notify_subscriptionListener service if that option had been chosen. The publisher making the subscription request MUST own the bindingTemplate. If this argument is not supplied, no notifications are sent, although subscribers may still use the get_subscriptionResults API to obtain subscription results. See Section 5.5.11 get_subscriptionResults for details. If email delivery to the specified address fails, nodes MAY attempt re-delivery, but are not obligated to do so. Depending upon node policy, excessive delivery failures MAY result in cancellation of the corresponding subscription.

Service side changes, standard java mail api properties, plus delivery retry counts, reply email, maybe a pointer to a templated html stylized email

Issue Links

• is blocked by: JUDDI-496 The tModel is not loaded in the SubscriptionNotifier
• is related to: JUDDI-602 Support encrypted values in our config