WildFly bootable JAR - datasource (oracle, sqlserver, etc.)

[MarcG]

Hi !

I am migrating existing Thorntail applications to WildFly using the WF bootable JAR plugin.

Some application are connected to databases.

For Oracle datasource in the current Thorntail implementation, a module directory is defined in src/main/resources/

This directory contains 2 files:

-module.xml

-ojdbc8.jar

The same technic is used for other type of databases. Obviously it is working fine with Thorntail but I was wondering if the same kind of technic is possible with WF bootable JAR.

Thanks in advance for your advises!

BR,

Marc

[James Perkins]

Hi Marc,

Yes that is possible. You can use a configuration parameter [1]. So you'd just have a directory where you put those resources and they will be copied over during the build process.

[1]: https://github.com/wildfly-extras/wildfly-jar-maven-plugin/blob/3e185f657e9116085ba28d8515fdc491a651ec50/examples/authentication/pom.xml#L46-L48

[Marc Gabriel-Willem]

Hi James,

Thanks for the information!

I will use this configuration attribute 

One more question regarding data sources definition 

Is CLI the only way to define data sources or would it be possible to use Yaml file as we do usually with Thorntail ? I am asking because smallrye seems to support Yaml now but maybe not for such resources definition 

BR

Marc

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/43f9e39f-ee85-4078-86aa-9a7bfc118f71n%40googlegroups.com.

[Fred Welland]

FWIW:   I've been doing the same thing (thorntail port) for a while now (well since mid-Aug).     Also using oracle.  Not using a module; rather using one of the data sources provided by 'wildfly-datasources-galleon-pack'

Here is sample POM:  

NOTE HUGE gradle shop -- chose to minimize what I do in Maven/POM and use hollowed jars -- for this POC.   The results of this POM makes a hollowed/bootable jar, with JPA, JSF, and an oracle data source.   

<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>fhw</groupId>
    <artifactId>Blacktip</artifactId>
    <version>1.0</version>

    <name>WildFly Hollow bootable jar with JSF</name>
    <properties>
        <version.wildfly>21.0.0.Beta1</version.wildfly>
        <version.wildfly.uberjar.plugin>2.0.0.Beta7</version.wildfly.uberjar.plugin>
    </properties>

    <build>
        <finalName>${project.artifactId}</finalName>
        <plugins>
            <plugin>
                <groupId>org.wildfly.plugins</groupId>
                <artifactId>wildfly-jar-maven-plugin</artifactId>
                <version>${version.wildfly.uberjar.plugin}</version>
                <configuration>
                    <feature-packs>
                        <feature-pack>
                            <location>wildfly@maven(org.jboss.universe:community-universe)#${version.wildfly}</location>
                            <inherit-packages>false</inherit-packages>
                        </feature-pack>
                        <feature-pack>
                            <groupId>org.wildfly</groupId>
                            <artifactId>wildfly-datasources-galleon-pack</artifactId>
                            <version>1.0.8.Final</version>
                            <inherit-packages>false</inherit-packages>
                        </feature-pack>
                    </feature-packs>
                    <layers>
                        <layer>datasources</layer>
                        <layer>oracle-driver</layer>
                        <layer>jsf</layer>
                        <layer>jpa</layer>
                    </layers>
                    <excluded-layers>
                        <layer>deployment-scanner</layer>
                    </excluded-layers>

                    <cli-sessions>
                        <cli-session>
                            <script-files>
                                <script>src/main/resources/create-datasource.cli</script>
                            </script-files>
                        </cli-session>
                    </cli-sessions>
                    <hollow-jar>true</hollow-jar>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>package</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

FWIW:   here is sample CLI  (as you see I am using 'env' -- so gotta set the corresponding ENV VAR before I run the jar): 

data-source add --name=MakoDS --jndi-name=java:/jdbc/MakoDS --driver-name=oracle --connection-url=${env.MAKO_DB_URL} --user-name=${env.MAKO_DB_USER} --password=${env.MAKO_DB_PWD}

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/80a3e15a-1382-4338-968b-2ccd320d36acn%40googlegroups.com.

[James Perkins]

Yes CLI is likely the best way. Side note WildFly 21.0.0.Final and the plugin version 2.0.0.Final have been released.

[Fred Welland]

indeed....my currently cooking MDB based bootable WF POC is migrated to the '.Final' versions.   

Which ran into the "How to 'deploy' a RAR during the baking process of a hollowed/WFBootable?"

...got something that doesn't error...but don't know if it works, yet...

Oh I guess that would be better if I started another thread and not hi-jack. 

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/af5e8145-fecb-43e9-b59c-cffe272b98cdn%40googlegroups.com.

[James Perkins]

Not a problem at all. Deployments like this are helpful in case there are any issues that have not been found or possible holes in the migration :)

[MarcG]

Very nice ! I've update to WildFly 21 final too.

Now I am using "modules" (to provide the db driver) via the "extra-content" attribute and CLI scripts to add the driver and define datasources!

It works nicely.

I was wondering if keeping my existing YAML files was an option or not.

There is the smallrye-config-source-yaml project that works fine for injecting values via CDI but what about the WildFly configuration itself.

Would it be possible to use such YAML file to replace variable names in CLI command or not ? 

A typical example would be the database URL 

Thanks again !

[MarcG]

Hi Fred,

Thanks for your very helpful example.

Regarding CLI commands I would prefer to use something else than "env var". YAML file would fit perfectly for my use case but I am not sure it's a valid option even with smallrye-config-source-yaml. 

BR,

Marc

[Fred Welland]

Not sure about YML and how or if older TT yml files are recyclable & and don't know much about smallrye at all.

My work has a long history of JBOSS AS and EAP (back to v4) and we have a bit of an established practice using the cli config stuff.   The pivot towards the TT yml was a bit of monkey wrench for me/us -- but we survived.   Pivot back to CLI with WFBootable is pretty easy. 

That said, I chose environment variables for my POCs that I am doing.     One of the options I am evaluating was using the "--properties="  bootable WF command line switch  (https://docs.wildfly.org/21/Bootable_Guide.html#wildfly-bootable-jar-arguments).    

So what I am thinking how this will work is to have config (i.e. standalone.xml via CLI commands)   use syntax like "${such_and_such}"  in them (much like my sample 'above' but w/o  'env.' prefix).      And then just have a standard props file with NV pairs in them for RT substitution  of site specific parameters. 

It isn't yml; but workable and not using environment variables. 

HTH..

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/c965f270-857d-435d-a563-ff20a78e26cfn%40googlegroups.com.

[MarcG]

Hi Fred,

Yes it helps thanks :)

The --properties works perfectly for WF system attributes. It would be wonderful it was possible to override the --properties default processor in order to support custom format like YAML. 

I hope it's already possible to define WF system variables in such YAML files.

I continue to investigate and in the same time I hope to get more info from the redhat team :)

BR,

Marc

[James Perkins]

Hi Marc,

Unless something has come in that I'm not aware of there is no support for parsing YAML as a properties replacement for WildFly. You can always file a feature request on JIRA though :).

[MarcG]

I've created a JIRA for YAML files.

Regarding the WildFly bootable jar it is working fine! All Thorntail applications have been migrated to WildFly bootable jar :) Thanks for your help!

[James Perkins]

Hi Marc,

Do you have a link to the JIRA? I can't seem to find it :)