[wildfly-dev] Deliver 3rd party subsystem to customers?
brian.stansberry at redhat.com
Mon Sep 29 12:42:35 EDT 2014
Agreed. I see feature-packs as the best solution to this kind of thing.
CLI archives are another possibility, with the archive bundling the
module and then the script executes to install it and make needed mods,
but my instinct is the feature-pack stuff will end up being a better
On 9/29/14, 11:30 AM, Heiko Braun wrote:
> I think the recently added feature packs work that way. Stuart wrote about that last week: http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html
>> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" <hrupp at redhat.com>:
>> suppose I am writing a subsystem for WildFly, that I can or want not add to the generic WildFly codebase (e.g. because it is not open source or because WildFly team would consider it too special for general consumption).
>> Is there a way to package that up in a .zip or any other format (in the good 'ol days we used .shar files :-)
>> to deliver such a subsystem with its module but also the xsl to modify standalone.xml (or similar)?
>> If not (yet), would it make sense for WildFly to reconsider allowing to provide e.g.
>> * ext.xml
>> * subsystem.xml
>> * ports.xml
>> that will get merged / added to standalone.xml when the module is loaded for the very first time
>> (like when the module.jar is also indexed for the first time).
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev