Hello,
I've started to define the layer on this branch[1] if you want to take a look.
Currently I'm wondering if the layers to connect to a broker (embedded or remote)
should depend on messaging-activemq.
Cheers,
Emmanuel
[1]:
On Tue, Jan 18, 2022 at 2:35 PM Emmanuel Hugonnet <ehugonne(a)redhat.com> wrote:
Hello,
Currently there is no way to use layers to provision an embedded broker and I've
been thinking about to provide such a layer.
+1. We need to be able to generate our standalone/configuration configs purely from
layers, so this is necessary. In WildFly Preview we've
been experimenting with not having an embedded broker in the configs in
standalone/configuration, but rather only in docs/examples. I
don't think layers for things in docs/examples is a must have in 2022, but whether or
not the standard WF configs end up with an embedded
broker I think we need the layer.
The embedded broker configuration is done using the "messaging-activemq"
feature group [1]. This feature group configure the embedded
broker
itself, the ee default connection factory and the mdb part in the ejb3 subsystem.
Introducing an embedded broker layer requires several changes in the current layers:
- it should not be the responsibility of the embedded broker layer to configure mbd
in the ejb3 subsystem, thus i propose to
introduce a
new ejb-mdb layer that would depend on the ejb layer [2] and have an optional
dependency on the embedded-broker layer.
I don't think ejb3-mdb *on top* of ejb is a good fit. The ejb layer already provides
MDB support. It's meant to be the top level layer
for EJB.
Intuitively it seems more like ejb depends on an ejb-mdb layer (instead of including the
features/feature-groups directly) and then
ejb-mdb has an optional dependency on a messaging layer. It's optional so it can be
excluded and replaced by a different messaging layer
(embedded vs not vs nothing and the user integrates a different RAR.)
Hmm, maybe an ejb-mdb layer is not needed. The reason to have one would be for
'ejb' to make it an optional dependency so users could
exclude it but still have the other features specific to 'ejb' (EJB remoting.)
- the embedded-broker layer would depend on the current messaging-activemq layer
[3] and configure the ee default connection factory
and
broker according to wht is already defined in the "messaging-activemq"
feature group [1].
What do you think about this plan ?
Cheers,
Emmanuel
[1]:
https://github.com/wildfly/wildfly/blob/main/ee-feature-pack/galleon-comm...
[2]:
https://github.com/wildfly/wildfly/tree/main/ee-feature-pack/galleon-comm...
[3]:
https://github.com/wildfly/wildfly/tree/main/ee-feature-pack/galleon-comm...
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His