+1 on adding the described fields to the PolarisEvent. I don't think the PolarisEventListener is really the right place to add any default methods about context, though. I'm not sure if you meant adding those to the PolarisEvent interface so that existing records have a default value?
Mike On Wed, Oct 22, 2025 at 10:26 PM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Alex > > It makes sense to me. > > Are you also proposing to have default methods in the interface ? > > interface PolarisEventListener { > > default UUID id() { ... } > > default Instant timestamp() { ... } > > default PolarisPrincipal user() { ... } > > } > > Maybe we can have a default behavior that implementations can > "override" if needed. > > Regards > JB > > On Wed, Oct 22, 2025 at 5:08 PM Alexandre Dutra <[email protected]> wrote: > > > > Hi all, > > > > We have two (albeit incomplete) PolarisEventListener implementations > > today: one for JDBC and one for AWS CloudWatch. > > > > Both enhance event payloads internally by adding a timestamp and user > > data. These two attributes are indeed very common in event-oriented > > systems. > > > > The JDBC implementation also generates unique IDs internally. That's > > because the PolarisEvent interface lacks an id() method, despite the > > common need for event disambiguation. > > > > Therefore, I propose promoting these three attributes (ID, timestamp, > > user) to the PolarisEvent interface, by adding the following methods: > > > > UUID id(); > > Instant timestamp(); > > PolarisPrincipal user(); > > > > This information is readily available at event instantiation sites, > > and can be provided via CDI injection without hassle. > > > > Let me know your thoughts. > > > > Thanks, > > Alex >
