[
https://issues.apache.org/jira/browse/HCATALOG-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531269#comment-13531269
]
Travis Crawford commented on HCATALOG-546:
------------------------------------------
A few comments (please post the trunk patch on RB too):
A few {{build.xml}} files update the classpaths to include {{<dirset
dir="${path.to.basedir}/core/build/classes"/>}}. What's the reason for this?
Subprojects should depend on hcatalog-core.jar to get the classes
(HCatConstants for example). If that's not Just Working for you it could be a
bug you've discovered and we can fix.
TestNotificationListener has an unused import - does {{ant clean test
-Dtestcase=Foo}} on the command-line work? I believe it will throw a checkstyle
error.
MessagingUtils is a utility class with only static methods, so it should have a
private constructor. I just filed HCATALOG-568 about updating our checkstyle
rules to catch this so we don't have to remember each time.
Overall I think this looks good. Let's figure out the compile issue & make the
couple minor updates and finish this up!
> Rework HCatalog's JMS Notifications
> ------------------------------------
>
> Key: HCATALOG-546
> URL: https://issues.apache.org/jira/browse/HCATALOG-546
> Project: HCatalog
> Issue Type: Bug
> Components: notification
> Affects Versions: 0.4.1
> Reporter: Mithun Radhakrishnan
> Assignee: Mithun Radhakrishnan
> Fix For: 0.4.1
>
> Attachments: HCATALOG-546.branch4.patch, HCATALOG-546.trunk.patch,
> sample.Add.Drop.Database.json, sample.Add.Drop.Partition.json,
> sample.Add.Drop.Table.json
>
>
> In 0.4.1, the NotificationListener listens for metastore operations and emits
> JMS notifications containing the entire metastore-objects
> (Database/Table/Partitions) in Java-serialized form. The assumption at the
> time was that consumers might need access to the whole object. This policy
> poses a couple of problems:
> 1. The notifications are verbose, since it conveys a bunch of information
> that's available from querying the metastore anyway.
> 2. Consumers of these JMS notifications (e.g. Oozie) would now be dependent
> on the Java class definitions of metastore-objects. If they change, Oozie
> would also need to be restarted (with updated libs), to consume the
> notifications.
> Ideally, the notifications should convey only the minimum information that
> identifies the metastore-change unambiguously. (Everything else can be
> queried for.) They should be backward compatible. If new fields are added,
> existing consumers shouldn't break (unless they intend to consume the new
> fields). Also, the notification-format ought to be pluggable.
> For the initial rework, we're proposing to use a JSON-string to represent the
> notification-content. We're also proposing a helper-class for the likes of
> Oozie to use, that converts the strings to POJOs, in a backward-compatible
> fashion.
> I'll attach sample notifications and a tentative patch shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
