If poller-configuration.xml contains a <monitor> element that references any of the monitor classes that are separately packaged in 1.10, then the remote poller will die on startup because it cannot unmarshal a poller configuration that includes classes not present in its classpath. There need not be any <service> elements in the poller configuration that reference these classes, and there need not be any ifservices in the DB that would reference them either. The mere presence of the <monitor> elements is enough to hose the remote poller.
The monitor classes that will cause this breakage include:
org.opennms.protocols.dhcp.monitor.DhcpMonitor (typically associated with service "DHCP")
org.opennms.protocols.nsclient.monitor.NsclientMonitor (typically associated with the "NSClient" and "NSClientpp" services)
org.opennms.protocols.radius.monitor.RadiusAuthMonitor (typically assocaited with the "RadiusAuth" service)
org.opennms.protocols.xmp.monitor.XmpMonitor (typically associated with the "XMP" service)
This ticket maps to the following support tickets:
Moving the remote poller to OSGi will of course make it trivial to have it download any bits it's missing, but for the time being, are we able somehow to recognize that the config could not be unmarshaled and ignore the missing classes?