Create WildFly Swarm applications from existing war files [part 2]

Post to Twitter

My first steps with WildFly swarm were very successful but I didn't solve my problem completely:

I tried to create a self-contained jar (fat jar) file from an existing war file, with minimal effort. The idea was that our product VisionX could create such jar files with some mouse clicks.

This wasn't possible because the project is in a very early phase, ANT wasn't supported and it wasn't planned.

I solved the problem for my use-case and published the result at github.

The project contains an Eclipse project with an ant task and a fully functional ANT build. It has a dependency to ivy, because ivy was used for dependency resolution. Ivy is not needed if you want to work with a copy of all dependencies, e.g. our VisionX will do this.

The code isn't production ready but it works like a charm. The test war file has 56MB and the created jar is around 78MB.

Just play around with the code :)

Create WildFly Swarm applications from existing war files

Post to Twitter

Have you heard about WildFly Swarm?

It's a new sidecar project to WildFly which helps you create self-contained Java microservices based upon the normal WildFly application-server.

Sounds interesting?

We had different use-cases for such a product. Our VisionX creates war files and desktop applications. It would be nice to have a microservice option. Our idea was to create a WildFly Swarm application based on our pre-created war files. Could be useful.

We made some experience with bundeling an embedded Tomcat with our applications because we use this variant for our desktop applications to add browser based help systems. We thought that a replacement of embedded Tomcat could reduce complexity...

The documentation was simple and maven based. The info:

We do aim to add support for other build-systems in the near future.

was nice but the relevant information wasn't available for ANT. We found some gradle tasks, but nothing for ANT - because ANT isn't supported.
What's the problem with maven? We don't like downloading the Internet for simple dependency management. This happened during our first tests with WildFly Swarm. Before we built our first "fat" jar, the "whole JBoss repository" was downloaded.

Test: Phase 1

We tried to follow the documentation and started with a new Maven "war" project. Our application was a simple JVx application with vaadin UI. The application code:

@Widgetset(value = "com.sibvisions.rad.ui.vaadin.ext.ui.Widgetset")
@Configuration({@Parameter(name = "main", value = "com.sibvisions.demos.swarm.EmbeddedApplication$MyApplication")})
public class EmbeddedApplication extends VaadinUI
    @WebServlet(value = {"/minimal/*", "/VAADIN/*"}, asyncSupported = true)
    @VaadinServletConfiguration(productionMode = false, ui = EmbeddedApplication.class)
    public static class Servlet extends VaadinServlet
    }   // Servlet

    public static class MyApplication extends Application
        public MyApplication(UILauncher pLauncher)
            setName("Simple application");

            setLayout(new UIBorderLayout());
            UILabel lblHello = new UILabel("Hello JVx' vaadinUI");
            lblHello.setFont(UIFont.getDefaultFont().deriveFont(UIFont.BOLD, 16));
            //example CSS without custom css file
            ((VaadinLabel)lblHello.getUIResource()).getCssExtension().addAttribute("margin-top", "100px");
            add(lblHello, UIBorderLayout.CENTER);

We found an intro from vaadin about their tests with WildFly Swarm. The last link contains redirects to a github project with many examples and a ready-to-use maven configuration.

But, we had bad luck because no example was working with our setup. The build wasn't a problem, but we got some Exceptions at runtime. We tried to find documentation in the Internet, but we didn't find a solution because the project is in Alpha status and documentation is not yet ready... So we tried to build WildFly Swarm on our own to be able to add debug messages.

After a long maven fight (once again) everything was working. We had some problems with JDK 8 and Eclipse Kepler because Kepler didn't support JDK8 without a Patch and bundled maven was too old. Latest maven didn't work with Eclipse but 3.2.1 was working...
WildFly Swarm test artifacts didn't work without problems and we had to fix some autoboxing errors (because of our custom compiler settings). Horrible but we won the fight!

The problem with our "fat" jar was that two dependencies were missing or weren't resolved correctly. After we manually set two more dependencies:


our "fat" jar was working without problems.

BUT... the jar had about 100 MB! Our war file had about 40MB. The overhead was about 60MB - WTF?
Our applications with embedded Tomcat had an overhead of 4MB.

The problem was/is that all maven dependencies were added to the war and the jar file. It was handled by the swarm-plugin and the issue #107 explains the problem.

After one day! we had a working Hello world example as Maven project. Sure, we built our own WildFly Swarm version too.

Test: Phase 2

The Maven project was working and maven built a war for our sources and bundled all dependencies for us, but what about existing war files? Our initial plan was the creation of WildFly Swarm applications for existing war files. This wasn't possible without hacking because it wasn't implemented... for us.

I told you that we built our own WildFly Swarm version and also the swarm-plugin. The plugin had a PackageMojo class. This mojo had enough documentation (= source code) for us, to create a simple test case for our use-case.

The test class is about 100 LoC with minimal logic but it's tricky. The relevant calls:

BuildTool tool = new BuildTool();

for (File jar : findMinimalDependencies())
  //read groupid, artifactid, version from jar

  tool.dependency("compile", sGroupId, sArtifactId, sVersion, "jar", null, jar);

tool.artifactResolvingHelper(new Resolver(tool));
tool.projectArtifact("com.sibvisions.demos", "swarm", "0.2-SNAPSHOT", "war", war);"swarm-0.2-SNAPSHOT", target);

The Resolver was a simply code copy of BuildTool findArtifact method:

public class Resolver implements ArtifactResolvingHelper
    private BuildTool tool;
    public Resolver(BuildTool pTool)
        tool = pTool;

    public ArtifactSpec resolve(ArtifactSpec pSpec) throws Exception
        for (ArtifactSpec each : tool.dependencies())
            if (each.file == null) {
            if (pSpec.artifactId != null && !pSpec.artifactId.equals(each.artifactId)) {

            if (pSpec.version != null && !pSpec.version.equals(each.version)) {

            if (pSpec.packaging != null && !pSpec.packaging.equals(each.packaging)) {

            if (pSpec.classifier != null && !pSpec.classifier.equals(each.classifier)) {

            return each;

        return null;

(Sure, not the best solution - but it was good enough for our tests)

With our test class, it was possible to create a WildFly Swarm application for an existing war file, without problems and without maven. And the best: The "fat" jar file had about 83MB and the original war file was about 60MB. The overhead was 23MB, but awesome for a basic WildFly installation.

The example project of Phase 1 is available on github.


WildFly Swarm is a nice product but it's not ready-to-use. If you have time to play around with it, just do it because it creates a back to the roots feeling - back to hacking. The "fat" jars are a nice idea, but microservice is just a buzzword.

WildFly is not comparable to embedded Tomcat, but if you need a simple application server for your servlets, an embedded Tomcat or Jetty are good enough. We won't replace our embedded Tomcat with WildFly Swarm because we misunderstood the concept and both products are for different use-cases.... but a new export Option for VisionX should be possible!

JVx' Vaadin UI 1.3 is available

Post to Twitter

The next release of our JVx' vaadin UI is available. It's not a big update but an important one because vaadin was updated to 7.5.0 and we support CORS out-of-the-box. We also have some annotations for easier application deployment.

The best thing for most of you is that starting with 1.3 our vaadin UI can be found on maven central.

Simply add the dependency:


We also upload snaphsots of vaadin UI, starting with current 1.4 branch
Simply configure the repository:

    <name>Sonatype Snapshots</name>  

and use following dependency:


The release files are also available on SourceForge.

The complete Changelog.

VaadinUI without web.xml

Post to Twitter

We've added some annotations to our vaadin UI to support UI configuration without web.xml (deployment descriptor).

Check this:

@Widgetset(value = "com.sibvisions.rad.ui.vaadin.ext.ui.Widgetset")
@Configuration({@Parameter(name = "main", value = "MinimalApplication$MyApplication")})
public class MinimalApplication extends VaadinUI
    @WebServlet(value = {"/minimal/*", "/VAADIN/*"}, asyncSupported = true)
    @VaadinServletConfiguration(productionMode = false, ui = MinimalApplication.class)
    public static class Servlet extends VaadinServlet

    public static class MyApplication extends Application
        public MyApplication(UILauncher pLauncher)
            setName("JVx application");
            setLayout(new UIBorderLayout());
            add(new UILabel("Hello JVx' vaadinUI"), UIBorderLayout.CENTER);

The example demonstrates a minimalistic JVx application with vaadin UI. It's like a standard vaadin application with one additional annotation:

@Configuration({@Parameter(name = "main", value = "MinimalApplication$MyApplication")})

The main parameter defines the JVx application class. It's the inner class MyApplication, in our example.

It's that easy!

VisionX 2.2 is out

Post to Twitter

What a day!
Our final release of VisionX 2.2 is out and it's the best piece Software we've ever released.

We worked very hard during the last 5 months to reach our goals and to make it happen. The new version brings many new productivity features and contains many bugfixes. The focus was and is still on end-users. But in VisionX 2.2, we have many new features for Software developers and Oracle Forms users as well. It depends on your license if you see more or less options.

So what's new? First, VisionX is compatible to Java 8 and can handle Lambda expressions without problems. This isn't relevant for end-users but for all developers. VisionX 2.2 still runs with Java 7 but it's no problem to switch the Java version to 8.

VisionX 2.2 has our brand new JavaFX UI integrated. If you have Java8, it'll be possible to start your applications as JavaFX applications or to export JavaFX standalone applications.

The new release is based on JVx 2.3.

So let's talk about Features

  • Java 8 support

    VisionX reads Java 8 syntax and if your project was set to target version 1.8, VisionX will create action listeners with lambda syntax. VisionX got new global configuration options:


    It's also possible to configure single applications via Eclipse settings, for Java 8. The configuration will be read from VisionX automatically.

  • Vaadin 7.5.0

    VisionX 2.2.403 includes our current vaadin UI and it's based on vaadin 7.5.0.

  • OpenShift

    VisionX supports application creation for OpenShift. You'll need a special license for this feature. The integration contains a new wizard and is available as new option in new application wizard.



    OpenShift - New application

    OpenShift - New application

  • Multi-IDE support

    VisionX 2.2.403 creates project files for Eclipse, NetBeans and IntelliJ. Simply open existing projects and start coding.

  • Config file encryption

    It's now possible to encrypt configuration files.

    Config encryption

    Config encryption

  • Corporation style

    VisionX applications have a new UI style for web mode. It's the corporation style for applications with many screens and big menus. Simply switch the style via VisionX.

    Corporation style

    Corporation style

  • Edit JDBC Url

    VisionX supports custom JDBC Urls (Developer feature). This feature could be relevant if you have an Oracle RAC or complex JDBC parameter.

    Edit JDBC Url

    Edit JDBC Url

  • JavaFX UI

    VisionX got support for JavaFX applications. Simply start the live preview or create a desktop JavaFX application in three clicks.

    JavaFX Live Preview

    JavaFX Live Preview

    JavaFX desktop application

    JavaFX desktop application

  • New deployment modes

    VisionX supports WildFly 9, IoT applications and latest Tomcat versions.

    Deployment modes

    Deployment modes

  • Edit panel (aka Morph panel)

    The Edit panel is a brand new component. It's also called Morph panel because it changes the style.

    Inline mode

    Inline mode

    Popup mode

    Popup mode

    Split mode

    Split mode

    Tabset mode

    Tabset mode

    You can use this panel to show e.g. a table of records and open detailed information as popup, as replacement of the table or show the details as split or tabset. Don't change the screen to show different modes.

  • More features

    Use custom css files for your web application,
    Use mobile preview applications available for Android and iOS,
    Spreadsheet reports will be created as XLSX instead of XLS,
    Full CORS support for your web application,
    Full CORS support for application logic called via REST, ...

Simply try out our new VisionX.

If you're already customer, please check your download area!

Have fun with our new VisionX release - it's really powerful.

EPlug 1.2.1 is out

Post to Twitter

A new version of EPlug is available. It's a smaller bugfix release.


  • Fixed that all dialogs (including trial) would not be displayed
  • Resource detection for Maven projects should now work correctly
  • Fixed NullPointerException, if "check databooks while typing" was active and a file was edited that was not a Java file
  • Fixed possible NullPointerException in the DataBooksView
  • "Auto Reload" and Auto Select" are now properly disabled if EPlug is not active on the project

Simply "Check for updates" in your Eclipse IDE.

JVx 2.3 is out

Post to Twitter

We're happy to announce that JVx 2.3 is available. The minor version update is more than a small update. It
comes with a bunch of new features. We think it's an update worth:

Here's the list of changes

  • Support linking with RoboVM

    It wasn't possible to create iOS applications with JVx because it had an internal problem. With 2.3 it will work.
    There's still a problem with RoboVM because JVx contains swing UI but if you remove the UI from the jar, everything
    will work!

  • Download via REST

    It's now possible to call actions which will return instances of IFileHandle, via generic REST services. The content
    will be sent back as binary stream (download).

  • CORS for REST

    Simply set the parameter: cors.origin to the allowed domain names (a comma separeted list).

  • Connection pooling

    It was possible to use connection pooling with JVx but with some limitations. The current support is an official solution without demand for additional source code. The only thing you should consider is that the initialization of the database should be moved to an event. The DBAccess class got new methods: eventConfigureConnection and eventUnconfigureConnection.
    Use configure to prepare the database session before you

  • Server-side hooks for event processing

    JVx 2.3 got invokeLater for server-side calls and we introduced the new interface ICallHandler.
    It has some very useful methods for better server control:

    public CallEventHandler<IBeforeFirstCallListener> eventBeforeFirstCall();
    public CallEventHandler<IAfterLastCallListener> eventAfterLastCall();
    public CallEventHandler<IBeforeCallListener> eventBeforeCall();
    public CallEventHandler<IAfterCallListener> eventAfterCall();

    public void invokeAfterCall(Runnable pRunnable);
    public void invokeAfterLastCall(Runnable pRunnable);
    public void invokeFinally(Runnable pRunnable);

  • Better Deployment support for VFS

    We had some crazy tweaks especially for some application servers with virtual file systems like JBoss. We removed the dirty code and replaced it with a more generic approach and now we have nice support for VFS and no more problems with WildFly.

  • Filter/Sort events added to IDataBook
    public DataBookHandler eventBeforeFilterChanged();
    public DataBookHandler eventAfterFilterChanged();

    public DataBookHandler eventBeforeSortChanged();
    public DataBookHandler eventAfterSortChanged();

  • Integration of external property files

    It's possible to include external property files into your application' config.xml:

          <accesscontroller>dummy value</accesscontroller>
       <property name="property.value" value="${value}"/>

    The property file (

    securitymanager.class = com.sibvisions.SecurityManager
    securitymanager.accesscontroller = com.sibvisions.AccessController
    value = value1

    The virtual result for reading values:

      <property name="property.value" value="value1"/>
  • Autodetection of tnsnames.ora

    It was possible to set the system property for an oracle JDBC driver. New JVx tries to find the location automatically and sets the property if path was found.

  • API changes

    We did two smaller API changes. The first one:

    LoggerFactory.destroy is now public

    The class AbstractSessionContext was removed without replacement. The only method, getMasterSession, was moved to ISessionContext. It's now easier to access the current master session in life-cycle object. It shouldn't be a problem for you because AbstractSessionContext was meant as internal class and not for public use. If you had a cast to AbstractSessionContext, simply remove the cast and everything will be fine.

We also have some smaller changes and bugfixes for you, but above list only contains the most important changes. For a full list of changes, please read the Changelog

VisionX 2.2 with OpenShift support

Post to Twitter

Our next VisionX release will support OpenShift. We wrote about OpenShift and our application test some weeks ago. It was so impressive that we did an integration in VisionX.
VisionX got additional menus and options for OpenShift and it handles complete communication. It's really end-user friendly. Usually, only developers can use OpenShift and create applications for the platform.

OpenShift platform was our preferred platform for VisionX because it has a complete REST API and a simple Java library. Many other platforms don't offer the same quality or are too complex for an integration. OpenShift itself has a simple frontend but it wasn't designed for end-users.

Why does an end-user need OpenShift?

To realize ideas.

Why should an end-user do that?

Why does and end-user need a website? ... to present itself or products.

Many end-users create Excel sheets or use app builders to realize ideas. The problem is often the deployment because and end-user can't deal with databases, application servers or PaaS providers. The same applies to startups.

VisionX is end-user friendly and enables innovation.

What we have in VisionX?

VisionX supports configuration of your OpenShift account. The only thing you need is an already activated OpenShift account. Simply register on OpenShift and that's it. The rest will be handled by VisionX. Don't create SSH keys or open tunnels to access your remote database or application server. VisionX will do all this tricky things for you.

We have a short Video for you. It demonstrates the OpenShift integration of VisionX. The first part shows configuration of a fresh OpenShift account. In the second part, we create a simple (unstyled) application and the last part is the deployment.

The whole video lasts 4:30 minutes. Have you ever created a full database application with menu, toolbar, user authentication, an input form and deployed in around 5 minutes?

Multi-IDE support for VisionX

(To be honest: Deployment wasn't as fast as shown in the video, because upload time can't be improved)

Next JVx and VisionX release?

Post to Twitter

Both products are code complete and JVx passed all tests. We're in the test phase with VisionX and do some smaller fixes, but it looks very stable.

We set the official release of VisionX 2.2 to August, 17th. We will release JVx 2.3 during the coming week (~ August, 7th).

VisionX 2.2 will come with some great new features like Java 8 + Multi-IDE support and our new MorphPanel.


It's a new UI component. You can use it to visualize a table of records (grid) and show record details as form in a tab area, as split panel, a popup or as replacement of your grid (= web mode).

It's soo useful. Usually you would create two or more screens for the same use-case but one screen with one MorphPanel is enough with VisionX 2.2.

A simple use-case: You have one master-data screen and want to show an edit screen for the records on double click or button click. You need one screen for showing master-data and another screen for the edit form. The master screen opens the edit screen with an additional parameter, to show the correct record in the edit screen... (boring).

Simply add a MorphPanel to your master-data screen, set Popup mode, design the popup and you're done. This is great for desktop applications and awesome for web applications!

Details and screenshots will follow!


Get ready for VisionX 2.2.

SourceForge outage and JVx

Post to Twitter

You know that we use SourceForge (SVN services) for our open source projects like JVx, Vaadin UI, JavaFX UI, Online Help and some others.

The whole platform had big problems and so we couldn't use our repositories as usual. It wasn't a real problem for us because we had backups and our local repositories were up-to-date, but it wasn't possible to build snapshots or create nightly builds.
Our build infrastructure is directly connected to our SVN repositories and so we had no chance to build our projects.

Since yesterday, all our repositories are online. We made some tests and everything was fine. We lost one full day (July, 17th) because SourceForge stopped working at July, 17th and backups were from July, 16th. But also not a problem because we had local copies.

We did some migration checkins and now, everything is online. Our SF repositories are up-to-date.
Our "nightly build" was started some minutes ago and everything was finished without problems.

So, we're back in the game.
(A big "Thank you" to all SF operators for their support, daily reports and countless hours of restoration)


We got some questions during last days and most of you asked us if it wouldn't be better to leave SF and use GitHub instead. We don't think this makes sense because such problems can happen with all providers - sure, they should never happen.

The migration effort from SF to GitHub is high and we don't have visible benefits. We know that git has some advantages compared to SVN but we don't need more than Source Code versioning and the checkin history. It's that simple. SF services aren't as fancy as GitHub services and the repository access via browser is better with GitHub, but this wasn't important for our decision.

It was important for us to use a big OpenSource provider and SF is a dinosaur in this area. We don't plan to leave SF but it's not impossible, e.g. if the environment changes.