Extending WildFly core feature pack

[gytis]

Hello,

I need a trimmed version of WildFly with the following subsystems: logging, naming, remoting, iiop-openjdk, io, transactions. I've played a little with both core and full feature packs. The issue with the full one is that, once the jars are pulled in, archive becomes too big for our use case. And the core pack does not have the required subsystems and I couldn't find the way to pull the modules in (other that copying module.xml files).

I wanted to ask, if there is a way to pull the modules into core feature pack, or trim them out of the full feature pack?

Thanks,

Gytis

[ctomc]

Hey,

just create new feature pack for your own needs.

for example take a look at web-feature-pack module we have in wildfly codebase

https://github.com/wildfly/wildfly/tree/master/web-feature-pack

this feature pack takes core distro and adds few extra subsystems.

see this config file to see which wildfly/subsystems.xml at master · wildfly/wildfly · GitHub

and also take a look at feature pack definition file wildfly/feature-pack-build.xml at master · wildfly/wildfly · GitHub

[gytis]

I saw the web feature pack. However, it also has newly modules in here: wildfly/web-feature-pack/src/main/resources/modules at master · wildfly/wildfly · GitHub. So if I would take core feature pack and add my required subsystems such as iiop-jdkorb and naming, I would have to add their module definitions and update them after every WF release. Is there a way to require those modules for feature pack without copying module.xml files and their directory structure manually?

[tomjenkinson]

Hi Tomaz,

As you say, its possible to layer on top of core feature pack and that is what Gytis initially did but we soon realised that in order to build something that composes a server out of a subset of existing services in WildFly EE you appear to need to either extend the wildfly-full feature pack (and therefore end up with all the modules included there, even if you don't activate them) or go with extending wildlfy-core but need to duplicate the required module.xml files from wildfly/feature-pack/src/main/resources/modules/system/layers/base at master · wildfly/wildfly · GitHub.

Extending wildfly-core and duplicating those files is not ideal as we would need to maintain them. Extending WildFly EE is not ideal as it makes the zip file 140MB even if we only need to activate a couple of the subsystems.

Do you know if there is any intention to include a modules module.xml in its maven artifact in the future? That way when building a server you can compose it of existing services without having to duplicate its module.xml from the src/main/resources/modules/system/layers/base folder of an existing server.

We also wondered if there was some kind of tool to "minify" a zip. i.e. inspect the "standalone.xml" and remove those modules that are not activated.

Thanks,

Tom

[jamezp]

I was looking at this the other day myself. I came to the conclusion that if you're building a feature pack you should know what you dependencies you need. The trouble comes when you want to just bring in transitive dependencies. It's rather simple to bring those in, but then you need to define a module.xml for each of those. I couldn't find anyway around that and in fact I couldn't really prove to myself that having to define those is a bad thing. A PITA, yes, but it's not really a bad thing. For the most part you should really only have to do it once.

One way I had thought of was to depend on org.wildfly:wildfly-feature-pack and then just exclude things I didn't need. I didn't finish testing this, but it seemed like it would have worked. I was attempting to just create a JAX-RS servlet container with CDI is all. Again though I didn't finish so I could have been going about it wrong .

The only easy way to do this would be each subsystem has it's own feature pack, but that seems a bit messy. I'm not sure we want to go there.

Just a note though, if you didn't know, the feature-pack is only one part of building a dist. You also need to use the provisioning plugin which is how the configurations are determined. I didn't play with that much so I don't know a lot of details about it. Have a look at either wildfly-web-build or wildfly-build to see how that works.

AFAIK there's no way to delete modules you're not using based on your configuration. I don't personally think it would be a good idea either as you users could no longer dynamically add features.

Keeping the dist small can be accomplished in your provisioning by setting the copy-module-artifact attribute to false. What this does is use a maven GAV to reference the dependency. In a clean environment this could slow down initial boot time dependencies will need to be downloaded. It just depends on what your target is I guess.

--

James R. Perkins

[tomjenkinson]

Thanks for the response James.

Lets say I want to compose a server containing everything but not HornetQ, how would you suggest I do that? Would it be to duplicate all of wildfly/feature-pack/src/main/resources/modules/system/layers/base at master · wildfly/wildfly · GitHub into my own project except for wildfly/feature-pack/src/main/resources/modules/system/layers/base/org/hornetq at master · wildfly/wildfly · GitHub.

The issue with that is that I then have to maintain all the files in that structure in my own project. What I was proposing is that somehow the module.xml should be in an artifact somewhere that the hornetq subsystem could depend upon. In that way when I composed my server to include the hornetq subsystem the correct module.xml would also be included and I would not need to duplicate the server.

[emmartins]

At this point you can only filter feature packs on server provisioning, here is an example of high level filtering, and here is an example of low level.

[tomjenkinson]

Thanks Eduardo, Gytis will take a look at that feature pack example you sent through.

[emmartins]

That's server provisioning, not feature pack build ;-)

[tomjenkinson]

My apologies. Server provisioning is (I think) the bit we need in order to create a streamlined .zip. From looking at your example we just need to create a maven project which uses filtering on the main WFLY feature pack to restrict it down to IIOP and transactions and hopefully end up with a small zip.

[jamezp]

It looks like simply adding the subsystems you want doesn't produce a usable server. Only the modules are copied over. None of the configurations or startup scripts are created. It's possible I'm doing something wrong though.

<server-provisioning xmlns="urn:wildfly:server-provisioning:1.0">
    <feature-packs>
        <feature-pack groupId="org.wildfly" artifactId="wildfly-feature-pack" version="${version.org.wildfly}">
            <subsystems>
                <subsystem name="jaxrs"/>
                <subsystem name="weld"/>
            </subsystems>
        </feature-pack>
    </feature-packs>
</server-provisioning>

--

James R. Perkins

[emmartins]

You need to add the web feature pack, your xml adds only these 2 subsystems (and modules these depend).

[jamezp]

Feature packs aren't inherited? The org.wildfly:wildfly-feature-pack depends on org.wildfly:wildfly-web-feature-pack.

I'm also not sure how that would bring in the bin and configuration directories as they're not modules. Maybe I'm missing something though.

--

James R. Perkins

[emmartins]

Feature packs aren't inherited? The org.wildfly:wildfly-feature-pack depends on org.wildfly:wildfly-web-feature-pack.

Yes feature packs are inherited, but your high level filtering indicates that only the referenced subsystems (and dependencies) should be included.

I'm also not sure how that would bring in the bin and configuration directories as they're not modules. Maybe I'm missing something though.

Bin directory is just raw content, and that is not included, by default, when you filter a feature pack. As for configurations, these are generated at provisioning time, by merging subsystem configs for each config file.

[jamezp]

Here's a mostly working example of a JAX-RS container. I say mostly because the web console doesn't work. I was able to get it to work, but it brought over all of WildFly.

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <parent>
        <artifactId>javaee-example</artifactId>
        <groupId>org.jboss.examples.javaee</groupId>
        <version>1.0.0-SNAPSHOT</version>
    </parent>
    <modelVersion>4.0.0</modelVersion>


    <artifactId>rest-container-build</artifactId>
    <packaging>pom</packaging>


    <properties>
        <server.output.dir>wildfly-rest</server.output.dir>
        <version.org.wildfly>9.0.0.Alpha2-SNAPSHOT</version.org.wildfly>
    </properties>


    <dependencies>
        <dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>wildfly-feature-pack</artifactId>
            <version>${version.org.wildfly}</version>
            <type>zip</type>
            <exclusions>
                <exclusion>
                    <groupId>*</groupId>
                    <artifactId>*</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
    </dependencies>


    <build>
        <finalName>${server.output.dir}</finalName>
        <plugins>
            <plugin>
                <groupId>org.wildfly.build</groupId>
                <artifactId>wildfly-server-provisioning-maven-plugin</artifactId>
                <version>1.0.0.Alpha8</version>
                <executions>
                    <execution>
                        <id>server-provisioning</id>
                        <goals>
                            <goal>build</goal>
                        </goals>
                        <phase>compile</phase>
                        <configuration>
                            <config-file>server-provisioning.xml</config-file>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-assembly-plugin</artifactId>
                <executions>
                    <execution>
                        <id>assemble</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                        <configuration>
                            <descriptors>
                                <descriptor>assembly.xml</descriptor>
                            </descriptors>
                            <recompressZippedFiles>true</recompressZippedFiles>
                            <finalName>${server.output.dir}</finalName>
                            <appendAssemblyId>false</appendAssemblyId>
                            <outputDirectory>${project.build.directory}</outputDirectory>
                            <workDirectory>${project.build.directory}/assembly/work</workDirectory>
                            <tarLongFileMode>gnu</tarLongFileMode>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>




</project>

assembly.xml

<?xml version="1.0" encoding="UTF-8"?>


<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">
    <id>thin-server</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>target</directory>
            <outputDirectory/>
            <includes>
                <include>${server.output.dir}/**</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

server-provisioning.xml

<server-provisioning xmlns="urn:wildfly:server-provisioning:1.0">
    <feature-packs>
        <!-- Include the web feature-pack to bring in configurations, bin directory, etc -->
        <feature-pack groupId="org.wildfly" artifactId="wildfly-web-feature-pack" version="${version.org.wildfly}"/>


        <!-- The default feature pack for full WildFly -->
        <feature-pack groupId="org.wildfly" artifactId="wildfly-feature-pack" version="${version.org.wildfly}">
            <!-- Include subsystems for JAX-RS and CDI -->
            <subsystems>
                <subsystem name="jaxrs"/>
                <subsystem name="transactions"/>
                <subsystem name="undertow"/>
                <subsystem name="weld"/>
            </subsystems>
        </feature-pack>
    </feature-packs>
</server-provisioning>

The follow XML snippet made the web console work, but brought in all WildFly modules. It just needs to be added to the feature-pack for the wildfly-feature-pack. Essentially the org.jboss.as.product configuration just needs to be in the wildfly-full slot. There might be another way to override it, but I didn't look that deep.

            <modules>
                <filter pattern="org\.jboss\.as\.product" include="true"/>
            </modules>

Hope this helps.

--

James R. Perkins