DOAG 2015 - I'm a speaker
![]() |
I'm a speaker at DOAG 2015 in Nuremberg. My talk will be about "Mobile applications with JavaFX" Read more. |
![]() |
I'm a speaker at DOAG 2015 in Nuremberg. My talk will be about "Mobile applications with JavaFX" Read more. |
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
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.
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:
public static class MyApplication extends Application
{
public MyApplication(UILauncher pLauncher)
{
super(pLauncher);
setName("Simple application");
setLayout(new UIBorderLayout());
UILabel lblHello = new UILabel("Hello JVx' vaadinUI");
lblHello.setFont(UIFont.getDefaultFont().deriveFont(UIFont.BOLD, 16));
lblHello.setHorizontalAlignment(IAlignmentConstants.ALIGN_CENTER);
//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.
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:
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);
tool.build("swarm-0.2-SNAPSHOT", target);
The Resolver was a simply code copy of BuildTool findArtifact method:
@Override
public ArtifactSpec resolve(ArtifactSpec pSpec) throws Exception
{
for (ArtifactSpec each : tool.dependencies())
{
if (each.file == null) {
continue;
}
if (pSpec.artifactId != null && !pSpec.artifactId.equals(each.artifactId)) {
continue;
}
if (pSpec.version != null && !pSpec.version.equals(each.version)) {
continue;
}
if (pSpec.packaging != null && !pSpec.packaging.equals(each.packaging)) {
continue;
}
if (pSpec.classifier != null && !pSpec.classifier.equals(each.classifier)) {
continue;
}
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!
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:
and use following dependency:
The release files are also available on SourceForge.
The complete Changelog.
We've added some annotations to our vaadin UI to support UI configuration without web.xml (deployment descriptor).
Check this:
public static class MyApplication extends Application
{
public MyApplication(UILauncher pLauncher)
{
super(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:
The main parameter defines the JVx application class. It's the inner class MyApplication, in our example.
It's that easy!
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
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.
VisionX 2.2.403 includes our current vaadin UI and it's based on vaadin 7.5.0.
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.
VisionX 2.2.403 creates project files for Eclipse, NetBeans and IntelliJ. Simply open existing projects and start coding.
It's now possible to encrypt configuration files.
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.
VisionX supports custom JDBC Urls (Developer feature). This feature could be relevant if you have an Oracle RAC or complex JDBC parameter.
VisionX got support for JavaFX applications. Simply start the live preview or create a desktop JavaFX application in three clicks.
VisionX supports WildFly 9, IoT applications and latest Tomcat versions.
The Edit panel is a brand new component. It's also called Morph panel because it changes the style.
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.
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.
A new version of EPlug is available. It's a smaller bugfix release.
Changes:
Simply "Check for updates" in your Eclipse IDE.
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
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!
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).
Simply set the parameter: cors.origin to the allowed domain names (a comma separeted list).
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
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 void invokeAfterCall(Runnable pRunnable);
public void invokeAfterLastCall(Runnable pRunnable);
public void invokeFinally(Runnable pRunnable);
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.
public DataBookHandler eventBeforeSortChanged();
public DataBookHandler eventAfterSortChanged();
It's possible to include external property files into your application' config.xml:
The property file (configuration.properties):
The virtual result for reading values:
It was possible to set the system property oracle.net.tns_admin for an oracle JDBC driver. New JVx tries to find the location automatically and sets the property if path was found.
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
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.
To realize ideas.
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.
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
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.
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!
Interested?
Get ready for VisionX 2.2.