Hey Jason,
This sounds great. Just a few questions:
Will there be some sort of process for updating the references? For example, a new
version of the SwitchYard extension is released, how do I communicate that the reference
needs to be updated to point to the latest version? Would creating a JIRA and submitting
a patch suffice? How would I know when a new version of the console is available,
specifically the one that references the updated SwitchYard extension?
Best,
Rob
----- Original Message -----
In order to support multiple derived products based on EAP, we need
a
solution that allows the console to "emulate" plug-ability. By
"emulate", I mean that until we have a dynamic rendering engine
(AS8/EAP7), we still have to deal with the fact that GWT requires
static compilation.
The first component of the proposal is that the console have a serial
version stream which includes *all* plugins. Every derivative
product will need to contribute a plugin which is pulled into the
serial version stream via reference. This means that every console
release will need to verify compatibility with old and new versions
of all products. This should not be too big of a deal because the
management policies require that we maintain compatibility anyway.
The second component is that every product (and its patch updates if
features are added) will bundle a version of the console which
includes support for the product. At runtime the server will then
simply pick the most recent version available. This will allow for
every copy to maintain a clear ownership. So for example, if you
install a patch which brings in console version 1.7, that version
can be removed and the other available versions can be used.
An example is:
/consoles/1.1 (Installed by EAP)
/consoles/1.2 (Installed by Portal)
/consoles/1.3 (Installed by BRMS)
/consoles/1.4 (installed by a Portal patch)
So in this case the server would start with 1.4. If BRMS was removed,
1.4 would be picked. If the portal patch was then rolled back, 1.2
would be picked.
Alternatively we could always just leave all versions, and always
pick the most recent console version, however rollbacks would be an
issue. We would need some way for the user to manually revert if
there was a bug (perhaps just having them delete the bad version).
-Jason
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev