quinta-feira, 19 de setembro de 2019

Hello World, Kogito!

Kogito is what you need to bring business automation to the cloud!

Kogito Quarkus extension allows you to build applications on top of quarkus, bringing native business applications, developer joy and multiple useful extensions that can be used along with Kogito.

Here are some interesting links for you to get started with Kogito:

Kogito Get Started Guide

Kogito Quarkus Extension Guide

Kogito Examples

Kogito Tooling Installation

Kogito + Quarkus on VS Code Tutorial

If you are a video person there's also this:

Wondering about where Kogito came from? Read this blog from Kris.

Happy Coding!

quinta-feira, 7 de março de 2019

Hello World, Quarkus!

Today JBoss community released Quarkus. I could not wait to test it. Projects can be generated using the following archetype:

mvn io.quarkus:quarkus-maven-plugin:0.11.0:create      \
    -DprojectGroupId=org.fxapps                        \
    -DprojectArtifactId=quarkus-getting-started        \
    -DclassName="org.fxapps.GreetingResource"          \

With the project that was generated you can create native binaries and docker images from it. See the following video for a quick demo of a hello world application:

quinta-feira, 1 de novembro de 2018

Adding dynamic properties to a Javascript object in a GWT + JSInterop context

GWT is a framework that allows you to program the user interface of your application in Java and later it is compiled to Javascript, which will work across all browsers. The main advantage is that you don't have to care about minification of Javascript and compatibility across browsers, easy communication with server side and it is Java, you can use Java on server and client side. With Errai you have CDI (and more) on the client side, which means that you can make your application flexible and create pluggable components.
GWT in its later versions introduced JSInterop, a great way to call Javascript using Java. During the compilation the Java bean will be compiled to an equivalent Javascript code. This is good for Javascript objects with static properties, but knowing Javascript you will always find cases where the attribute name is dynamic, where the attribute is created "on the fly", for example:

var myObject = {
    someAttributeIJustCreated : "the value"

In Javascript myObject is a valid type, but this is not how things work with Java. During Javascript development it is handy to use such types and in some Javascript APIs you can't run away from it, for example, in C3.js to map a data X value you must create an attribute with the name of the column matching the column name where the X values will be found. To better understand this see the simple_multiple_xy.js example:


var chart = c3.generate({
    data: {
        xs: {
            data1: 'x1',
            data2: 'x2',
        columns: [
            ['x1', 10, 30, 45, 50, 70, 100],
            ['x2', 30, 50, 75, 100, 120],
            ['data1', 30, 200, 100, 400, 150, 250],
            ['data2', 20, 180, 240, 100, 190]

Notice that to tell that data1 x will x1 we will need to have an attribute of type data1. If you know the API you will see that data1 could be a String, but that I don't know how to map.
How do we map such cases using JSInteorp? After looking for it quite a while I found this github discussion and then the solution was simple:

* Make the attribute of type elemental2.core.JsObject
* Use the following code to create dynamic attributes:

JsObject jsObject = JsObject.create(null);
       .set("someCustomProperty", "someCustomValue");

And that's it! You can have properties of type JsObject in any object anotated with JsType, for example, if I want to create xs attributewith dynamic attributes (see the c3 object above), I can declare a property as follows:

    public native void setXs(JsObject xs);

See you in next post.

segunda-feira, 15 de outubro de 2018

Debugging error "Could not import XML from stream: invalid LOC header (bad signature)" when building a Thorntail application

Tl;DR: Check if there's corrupted JARs in your maven repository

When building a Thorntail 2.2.0.Final application I faced the error Could not import XML from stream: invalid LOC header (bad signature) when trying to build the JAR using mvn clean install. I could not find what is wrong, I just downloaded the application using Thorntail generator but I was not able to run it, so frustrating. When I used the -X flag I could see the error stack trace. The part that was causing the error was:

Caused by: java.util.zip.ZipException: invalid LOC header (bad signature)
    at java.util.zip.ZipFile.read (Native Method)
    at java.util.zip.ZipFile.access$1400 (ZipFile.java:60)
    at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse (DocumentBuilderImpl.java:339)
    at javax.xml.parsers.DocumentBuilder.parse (DocumentBuilder.java:121)
    at org.jboss.shrinkwrap.descriptor.spi.node.dom.XmlDomNodeImporterImpl.importAsNode (XmlDomNodeImporterImpl.java:65)
    at org.wildfly.swarm.tools.ModuleAnalyzer. (ModuleAnalyzer.java:53)
    at org.wildfly.swarm.tools.ResolvedDependencies.findModuleXmls (ResolvedDependencies.java:80)

If you check the full stack trace you can see that the problem is coming from some corrupted zip file in my local maven repository. The simply solution would be clean my local maven, but I didn't want to do that, so I had to debug ResolvedDependencies  class. Code is open, I cloned the thorntail project from github, imported the project tools to my Eclipse, checked the 2.2.0.Final TAG, configured remote Java application debug adding the tools projects in source tab:

Then I added a breakpoint to the point where the exception was thrown: 

Finally I run the maven using mvnDebug When you do this maven hangs waiting for a remote debugger to connect to it, then I had to go back to Eclipse and run my Remote Java Application goal:

When it stopped at my break point I was able to continue the debug execution in debug mode and back to ResolvedDependencies I could see what JAR was corrupted. After the debug session session I simply had to delete the JAR and run mvn clean install again and everything worked because maven re-downloaded the JAR, this time a not corrupted one :-)