AbstractMessageGroupStore.persistentMessageGroupFactory is not overridable while AbstractMessageGroupStore.messageGroupFactory is

[bratwurzt]

Expected Behavior

When implementing custom PERSISTENT MessageGroupFactory, I'd like to override persistentMessageGroupFactory the same way as I can override messageGroupFactory

Current Behavior

AbstractMessageGroupStore.persistentMessageGroupFactory is final and fixed to type of SimpleMessageGroupFactory and can't be overridden

Context

How has this issue affected you? A lot of custom development.

What are you trying to accomplish? I'm trying to implement custom persistent message group store.

What other alternatives have you considered? Coding everything myself.

Are you aware of any workarounds? Yes. I'd like to avoid them.

[artembilan]

There is no need need in overriding that property. The logic is like this:

	protected MessageGroupFactory getMessageGroupFactory() {
		if (this.lazyLoadMessageGroups) {
			return this.persistentMessageGroupFactory;
		}
		else {
			return super.getMessageGroupFactory();
		}
	}

So, if you set lazyLoadMessageGroups to false, the MessageGroupFactory provided in the setMessageGroupFactory() is going to be returned. And that's where you can implement whatever logic you needed.

The pattern is like this:

myMessageGroupStore.setLazyLoadMessageGroups(false);
myMessageGroupStore.setMessageGroupFactory(myMessageGroupFactory);

Well, you still can extend that MessageGroupStore and override its getMessageGroupFactory() to do some extra logic to chose whatever factory you need at the moment.

I would like to know more about your use-case and what drive you into such a low-level logic to deal with.

[bratwurzt]

Hello @artembilan, I wanted to provide custom persistent and non-persistent message group.

[artembilan]

Then I suggest to look into two separate instances of MessageGroupStore: one is configured for persistent factory and another for non-persistent one. They both can look into the same database. I'm not sure what could be a logic when you'd like to determine a target factory at runtime: it is configured only once and same is used everywhere. So, having two different instances for different use-cases should be enough.

Please, elaborate otherwise.

[artembilan]

Closed as Works as Designed.