adobe / aio-lib-java

Adobe I/O - Java SDK
https://opensource.adobe.com/aio-lib-java/
Apache License 2.0
5 stars 18 forks source link

`aem` `aio-aem-events-osgi-mapping` : Cannot make custom Event Handler Type #123

Open radoslaw-czarnecki-wttech opened 2 years ago

radoslaw-czarnecki-wttech commented 2 years ago

Question

How to make a custom Event Handler that will be registered and has an additional custom field in the event's request payload?

Expected Behaviour

We want a custom Page Publish event which has custom fields in the event's request payload.

  1. Create com.adobe.aio.aem.event.osgimapping.internal.OsgiEventMappingSupplierImpl-custom.cfg.json file in config.author directory containing the following:

    { "aio.event.code": "custom_published", "aio.event.label": "Custom Page Published", "aio.event.description": "Custom Page Published Event", "aio.xdm.event.type": "com.adobe.xdm.event.AemPagePublishedEvent", "osgi.event.handler.type": "com.proj.core.eventhandler.CustomHandler", "osgi.topic": "com/day/cq/replication", "osgi.filter": "(&(type=ACTIVATE)(!(event.application=*)))", "osgi.jcr.path.filter": "/content/" }

  2. CustomHandler inherits from one of the abstract classes like ReplicationEventHandler (and puts CustomPage inheriting from Page) or something else which will give access to add custom fields to the event's request payload.

  3. Handler is registered and the event's request payload has defined by CustomHandler additional fields.

Actual Behaviour

1) When tried to inherit from ReplicationEventHandler\<CustomPage> (where CustomPage inherits from com.adobe.xdm.content.Page) and AdobeIoEventHandler\<CustomPage>, there was a problem, because List<Triple<Asset, String, Date>> getXdmObjectActorDateTriples(Event event, ResourceResolverWrapper resourceResolverWrapper) is package-private and there cannot be a class created outside this package and implements this method. 2) When inheriting eg. from PageReplicationEventHandler custom handler does not work and logs say:

    com.adobe.aio.aem.event.osgimapping.internal.OsgiEventMappingRegistrationServiceImpl Adobe I/O Events' OSGI Handler Registration failed: `Unreferenced/unimplemented OSGI event Handler value: com.proj.core.eventhandler.CustomHandler
    com.adobe.aio.exception.AIOException: Unreferenced/unimplemented OSGI event Handler value: com.proj.core.eventhandler.CustomHandler
francoisledroff commented 2 years ago

Thanks for filing this issue so clearly.

radoslaw-czarnecki-wttech commented 2 years ago

Thanks for your response. Ad. 2: Maybe I missing something, but it looks like the error message from the logs comes from the AdobeIOEventHandlerFactory.java. Looking in this class I see if/else statements and there is no place for the custom handler. In our case when we are using a custom handler, we are ending in the last else statement with ends which the following exception LINK

Are you sure, in the current implementation, we are able to add our custom handler in our project, which will be visible for this framework?

mikehstrauss commented 2 years ago

Would it be possible to create a registration mechanism for adding new event handlers. The factory can use a map of factories to instantiate the handler of need.

mikehstrauss commented 2 years ago

Wondering if another way to deal with the OP's concern, is to allow for configuring additional asset metadata fields to be included in the event payload. This would probably satisfy 95% of the customization needs that would call for a custom event handler. May be the event mapping config could enhanced to provide an optional list of metadata fields to be included in the payload for asset based events. The same would be nice for page properties of a page based event.

francoisledroff commented 2 years ago

oh my bad, I now see the root cause of point 2 Technically it could be as simple as doing dynamic class loading based on the handler class name, but Adobe Cloud Manager code scan does not allow this... if you have an idea on how to load these using map of factories, your PR is welcome.

another approach indeed would be to accept a modification of our code to allow users to configure an optional list of metadata fields to be included in the payload, I like the idea a lot see https://github.com/adobe/aio-lib-java/issues/90