Seiten

Mittwoch, 25. Januar 2017

Nested Builder

If you're working with the Builder Pattern, you might find your relations growing complex. The NestedBuilder class lets proxies serve as parents and children at the same time...  
The full article you could find on DZONE : https://dzone.com/articles/nested-builder

Mittwoch, 11. Juni 2014

Big data collections with MapDB

This article gives a short overview over the open source software MapDB which is now in version 1.0.3.

What is MapDB?

Original designed as a storage engine for an astronomical desktop application it had two design goals minimal overhead and simplicity. Over the time the engine had evolved and the third goal provide an alternative Java memory model was added. So now it is a storage engine which is specialized for big data collections and for that has some cool features.
For example:
  • Write to Heap, OffHeap, File or TempFile
  • Synchronization of Maps/TreeMaps/Sets and Queues 
    • Maps can also be build with composite keys
    • bidirectional maps
    • synchronization between maps (in case you have a 1-N association)
  • Caching
    • expiration on disk usage, access or write time
  • Compression
  • Faceting aka Histogram
  • Simulated Auto-Increment
  • Transactions (Note: a single transaction can only be used once)
  • Querying

Small Example

The following example shows the simplicy in the context of IoT where i put 10 million temperature values into a collection which is backed by an off-heap and group the values into five groups (cold, fresh, warm, hot and burns). For filling the cache i also use auto increment.
public class TemperatureRepository {
    private final Atomic.Long keyinc;
    private ConcurrentHashMap<String, Long> histogram;
    private HTreeMap<Long, Integer> temperatureMap;

    public TemperatureRepository() {
        //Create off-heap memory cache
        temperatureMap = DBMaker.newCache(1.0);

        //Get Autoincrement counter
        DB db = new DB(temperatureMap.getEngine());
        keyinc = db.getAtomicLong("map_temp");

        // histogram, category is a key, count is a value
        histogram = new ConcurrentHashMap<String, Long>(); //any map will do

        // bind histogram to primary map
        // we need function which returns category for each map entry
        Bind.histogram(temperatureMap, histogram, (key, value) -> {
            String ret = null;

            if (value < 0) {
                ret = "cold";
            } else if (value < 10) {
                ret = "fresh";
            } else if (value < 20) {
                ret = "warm";
            } else if (value < 30) {
                ret = "hot";
            } else {
                ret = "burns";
            }
            return ret;
        });
    }

    public void add(int temperature) {
        temperatureMap.put(keyinc.incrementAndGet(), temperature);
    }

    public void printHistogram() {
        System.out.println(histogram);
    }

    public static void main(String[] args) {
        TemperatureRepository temperatureRepository = new TemperatureRepository();
        new Random().ints(-10,40).parallel().limit(1_000_000).forEach(e-> temperatureRepository.add(e));
        temperatureRepository.printHistogram();
    }
}

Fazit


Until now i had not the chance to use MapDB in a productive environment but on our playground at www.rapidpm.org it makes a very good impression.

Sonntag, 25. Mai 2014

Vaadin Valo: The new theme (since version 7.3)

Vaadin's roadmap 

Vaadin released the most current release 7.2 in the middle of may. It offers some interesting features like responsive layouts for components (letting components react on size changes and set new css-styles depending on the current size), native support for IE11 and improved push channel with support for long polling, Tomcat 8, Wildfly 8, Glassfish 4, Jetty 9.1. To be honest, I didn't already try all new features.

As you can read on their roadmap (here or here) the next release 7.3 (to be released in june) will contain a new theme called 'Valo' which looks pretty nice and which I wanted to try for a new project. There are already two alpha versions available for it and I will show you later in this post how I got it running.

Then there will be a version 7.4 which will contain a new component 'Grid' which seems to become very important. By now the Table-component seems to be one of the core components used in Vaadin-applications. If we believe the Vaadin guys, Grid will become Table's big brother with lots of improvements and new functions that the Table can't offer (e.g. dynamic row heights). I'm very curious about it and it really seems to become a big component because its release will be splitted in two parts. A first version of Grid will be released with version 7.4 but the following release 7.5 will mainly focus on extending the Grid-component.

Valo

Let's focus on the new theme 'Valo'. The Vaadin guys posted a preview-picture of the new styles and in my opinion this looks really nice:

https://vaadin.com/image/image_gallery?uuid=ee33077b-bf15-42a3-bd37-b2d2955502e9&groupId=10187&t=1396549547676


As I already wrote it will be included in release version 7.3 in june. There are already two beta versions - alpha1 and alpha2 - which you can use to start experimenting.

Here is what I did to get a Vaadin-Project running with the new theme in version 7.3.0.alpha2 (I mainly followed the instructions from the release notes but at some points I had to go a slightly different way):


  1. Create a new maven project from the vaadin archetype "vaadin-archetype-application" with version 7.3.0.alpha2
  2. mvn clean install
  3. Navigate to the exploded war-directory and from there navigate to WEB-INF/lib
  4. Extract "vaadin-themes-7.3.0.alpha2.jar" as it contains the needed "valo" folder
  5. Copy the folder VAADIN/themes/valo (from the extracted vaadin-themes-7.3.0.alpha2 folder) to the folder src/main/webapp/VAADIN/themes in your Vaadin-project. The "valo" folder should now exist next to your "mytheme"-folder.
  6. Change the content of the "mytheme.scss"-file in your "mytheme"-folder to the following:
    // Any variables you wish to override should be done before importing Valo
    
    // Modify the base color of the theme
    $v-app-background-color: hsl(200, 50%, 50%);
    
    @import "../valo/valo";
    
    @mixin mytheme {
      @include v-valo;
    }
  7. Install ruby (because it contains the needed sass-compiler which will be included in the final 7.3-release but which is not included in the alpha-version). You can download and install it from http://www.rubyinstaller.org/. I installed it on Windows and after installing it I used the console to install the sass-compiler via ruby by entering the following command: gem install sass
  8. Navigate via console to your project and into the folder src/main/webapp/VAADIN/mytheme
  9. Enter the following command: sass styles.scss styles.css
  10. Go into your project's pom.xml. Comment out the <goal>compile-theme</goal> - entry in the "vaadin-maven-plugin". Look at the update at the end of this posting for more explaination on this.
  11. Build (e.g. by running mvn install) and deploy your war file to your web-/applicationserver - Done!
IMPORTANT: Have a look at your styles.css-file in your mytheme-folder before trying to deploy the application. It should be filled with many thousands of lines. And THAT is the right content. If you have a content like
@import "../valo/valo";

.mytheme {
 name: v-valo args: []
}
then the vaadin sass-compiler (which doesn't work in that alpha version) was run, which overwrites the right content and crashes our theme! This might happen if you didn't comment out the goal-entry from the vaadin-maven-plugin (see step 10) and then run a mvn install.

I was wondering why the styles.css was overwritten when a mvn install was executed because this normally only happens after a vaadin:compile-theme task (from the vaadin maven plugin) was run and I didn't expect that task to be run when executing a install-task. But as it seems..it does. <-- Update: Step 10 will fix that.

Result

That's how the Vaadin-Sample-Application looks like with Valo:



Beautiful, isn't it?

----------

Update 27.05.2014:
In the first version of this posting step 10 was "Check if the styles.css has the right content" and I wrote that I couldn't run mvn install because it overwrote the styles.css with the wrong content. So I had to let my IDE make the war-file instead of using mvn install. I fixed that now.

Explaination: The task "compile-theme" from the vaadin-maven-plugin tries to compile the content of styles.scss and write the compiled content to styles.css (I don't know how that scss-stuff works in detail). BUT the compiler used by the compile-theme-task doesn't work in the used alpha-version (the Vaadin guys say it will work in the final release). Because it doesn't work we need to install a compiler which works the correct way (we do this by installing ruby and running the command from step 8 and 9). After running that command the styles.css is valid and we don't want to run the compile-theme task anymore because it will overwrite the styles.css with invalid content. The vaadin-maven-plugin says by its <execution> --> <goal>-entries that those <goal> entries should be run when mvn package or install is called. That's the reason why we have to comment out the compile-theme-task in our pom.xml. After doing that we can just use mvn install as always and then deploy the war-file.

Mittwoch, 21. Mai 2014

Simple Forge for Rapid Development

This article covers the simple usage of Forge to build up an application (or at least an almost complete stack for a prototype).
So what is Forge? It is a command line tool to create and configure Java projects. You can setup different modules (for example cdi or jpa) and Forge generates all resources needed. This can be anything from java classes to deployment descriptors right up to java test classes or JSF files. On top of that this behavior is incremental, so that you can use it at any time you want.

The setup of the modules is done by Convention over Configuration so that everything is quite simple and comprehensible. The Command line also supports tab-completion and makes the usage very fluent.

You may ask why not Forge 2 (it is already in version 2.5.0). It is faster and a little bit easier but it lacks in one point: the Arquillian module is currently not migrated but it is planed.

Example
At first we have to tell Forge to use defaults. Then we create a project with name forgetest and the topLevelPackage de.bischinger. With this a Maven War project is created.
[no project] Development $ set ACCEPT_DEFAULTS true;
[no project] Development $ new-project --named forgetest --topLevelPackage de.bischinger;
After this you can see that the shell changes from "no project" to your project name "forge test".
Now we want to add persistence namely Hibernate and WildFly (creates a persistence.xml and adds dependency to pom.xml)
[forgetest] forgetest $ persistence setup --provider HIBERNATE --container WILDFLY;
Create a JPA entity customer with a required field name. For this we need also to setup JPA validation.
[forgetest] forgetest $ validation setup --provider HIBERNATE_VALIDATOR;
[forgetest] forgetest $ entity --named Customer --package de.bischinger.model;
[forgetest] Customer.java $ field string --named name;
[forgetest] Customer.java $ constraint NotNull --onProperty name;
The interesting part is once again that after the creation the shell switches to the created context so that you can easily create the fields. You can also list the context with ls.

Now we want to build a simple JSF UI for the customer entity. At first we need to setup Scaffold which generates our UI.
[forgetest] Customer.java $ scaffold setup;
[forgetest] Customer.java $ scaffold from-entity de.bischinger.model.Customer.java;
After this we can build our application with build and after deploying (which can also be done with Forge but this would be another topic) we can see the following JSF-Page. On the left side is our link to the customers where we can already create, search and delete customers. It also has a paging feature.
Ok - the GUI still must be customized but this is again another topic. The point is that i have spent so much time in the past to reach a state like this - now it is possible within just 2 minutes.

But we are not finished yet - what about tests? For this we can install the Arquillian plugin into our project. We setup Arquillian to use a WildFly-Managed-Container with JUnit after which we can create our tests.
[forgetest] Customer.java $ forge install-plugin arquillian;
[forgetest] Customer.java $ arquillian setup --containerName WILDFLY_MANAGED --testFramework junit;
[forgetest] Customer.java $ arquillian create-test --class de.bischinger.model.Customer.java;
Done.

Conclusion

From my point of view this tool is worth a lot. I can integrate and configure almost any standard technology (JPA, Validation...) i want in no time. This way i can really concentrate on the business. Forge is nicely integrated in the JBoss Developer Studio, it can also be used on any shell and it is easy to understand. The generated sources can also be studied to familiarize with unknown technologies.

Mittwoch, 14. Mai 2014

CDI ContextResolver Pattern 2.0

What is the ContextResolver Pattern?
It is a pattern describe by Sven Ruppert (here) to solve the following problem.

The Problem
A service has several implementations which are provided to clients depending on a specific environment context (for example: test- or developmentcontext) on the service side. The client does not know about the context and the environment context must be dynamically configurable.

The Solution
Decouple the service creation from the context resolving by introducing
  • a ContextResolver which determines the current context and returns an annotation literal
  • a Service Context Qualifier
  • a service producer which uses the servicecontextqualifier
With that you can develop very flexible and extendable modules or applications which can be dynamically configured at runtime.

The Evolution
The previous version is implemented with CDI extensions which is a little bit harder to understand and needs a javax.enterprise.inject.spi.Extension file. So here is the improved version which uses only plain CDI-Producers and therefore should be easier to understand.

The client:
@Inject
@DemoLogicContext
Instance<DemoLogic> demoLogicInst;

The producer:
public class DemoLogicProducer
{
 @Produces
 @DemoLogicContext
 public DemoLogic create(BeanManager beanManager, @Any Instance<ContextResolver> contextResolvers)
 {
  return ManagedBeanCreator.createManagedInstance(beanManager, contextResolvers, DemoLogic.class);
 }
}

The ContextResolver:
public class DemoLogicContextResolver implements ContextResolver
{
 @Inject
 Context context;

 @Override
 public AnnotationLiteral<?> resolveContext(Class<?> targetClass)
 {
  //Determines the context and returns annotionliteral 
  return context.isUseB() ? new MandantB.Literal() : new MandantA.Literal();
 }
}

The ManagedBeanCreator:
public class ManagedBeanCreator
{
 public static <T> T createManagedInstance(BeanManager beanManager, Instance<ContextResolver> contextResolvers,
   Class<? extends T> clazz)
 {
  //FindFirst
  for (ContextResolver contextResolver : contextResolvers)
  {
   AnnotationLiteral<?> annotationLiteral = contextResolver.resolveContext(DemoLogic.class);
   Set<Bean<?>> beans = beanManager.getBeans(clazz, annotationLiteral);

   //Create CDI Managed Bean
   Bean<?> bean = beans.iterator().next();
   CreationalContext<?> ctx = beanManager.createCreationalContext(bean);
   return (T) beanManager.getReference(bean, clazz, ctx);
  }
  return null;
 }
}

The sources can be found here.

Have fun coding.

Montag, 12. Mai 2014

Mocking IoT Tinkerforge Sensors

A couple of days have passed since the TinkerForge-API has been published on maven central. But what can you do with if there is no hardware around. This was my situation as i wanted to try it out and play with the weatherstation from jaxenter (weatherstation).
So what can you do now? You can either mock the hardware sensor and struggle with the protocol of the sensors or you can mock the software sensor. The latter approach seems easier to me. So lets start.
If you only want to have a single value request (e.g. getTemperature()) the task is easy. You only have to override the method on sensor instantiation.
new BrickletTemperature("dV6", new IPConnection()){
    @Override
    public short getTemperature() throws TimeoutException, NotConnectedException {
           return 42;
    }
};
The more interesting task is to hack the callback listeners so that you continuously get measured values. Ok, this would be no real data but it should be sufficient for testing and playing. To hack the sensor we need to dive a little bit into the internals of the sensors. If you add a listener to a sensor it is put into an internal list which is processed if a specific callback event (for example for temperature) is fired. In this process the changed value is passed.
So the task is to create a thread which fires a specific callback event on a sensor.
//Creates Standard-BrickletTemperature with injected IPConnection
BrickletTemperature brickletTemperature = new BrickletTemperature("kjh6", ipConnection);

//Determine the callback event constants (note: callbackreached listeners are ignored)
List ints = new ArrayList<>();
Field[] declaredFields = deviceClass.getDeclaredFields();
for (Field declaredField : declaredFields) {
    String fieldName = declaredField.getName();
    if (fieldName.startsWith("CALLBACK_") && !fieldName.endsWith("REACHED")) {
         declaredField.setAccessible(true);
         int callbackIndex = declaredField.getInt(device);
         ints.add(callbackIndex);
    }
}

//Creates a Value generator for the bricklet
try {
      createBrickletMock(ipConnection, brickletTemperature, (byte) 200, ints);
} catch (NoSuchMethodException e) {e.printStackTrace();}
The callback events of each sensor are mapped to a constant in the sensor class which starts with CALLBACK (callback reached events have CALLBACK_<name>_REACHED) so that you can use reflection to read the values.
static <Bricklet extends Device> void startCallbackListenerThread(IPConnection ipcon, Device bricklet, byte startValue, List<Integer> callbackIndizes) throws NoSuchMethodException {
        Class<IPConnection> ipConnectionClass = IPConnection.class;
        Method callDeviceListener = ipConnectionClass.getDeclaredMethod("callDeviceListener", Device.class, byte.class, byte[].class);
        callDeviceListener.setAccessible(true);

        //start thread for each callback event
        for (int callbackIndex : callbackIndizes) {
            new Thread(() -> {

                try {

                    Random random = new Random();
                    while (true) {

                        //Generates values -1, 0 or 1
                        int randomDiff = random.nextInt(3) - 1;

                        //Invoke on device
                        callDeviceListener.invoke(ipcon, bricklet, (byte) callbackIndex, new byte[]{0, 0, 0, 0, 0, 0, 0, 0, (byte) (startValue + randomDiff), 0});


                        //wait 5s
                        Thread.sleep(THREAD_SLEEP_MILLIS);
                    }
                } catch (IllegalAccessException | InvocationTargetException | InterruptedException e) {
                    e.printStackTrace();
                }
            }).start();
        }
    }
So have fun coding.

Sonntag, 13. April 2014

Java8 CompletableFuture for JavaFX and CDI Part II

The last part was describing how you could reach the goal to make the order of some dependent method calls independent. Now we will see, how we could use this for the combination of CDI and JavaFX.
If you want to have CDI managed Controllers inside your JavaFX application you have to deal with the two life cycles. The init from CDI and the init from JavaFX. If you are combining both technologies, you will have the problem that the order of the livecycle steps are not always in the same order. Depending from the technology that will start, the order of the init methods will change. For CDI it is the method with the annotation Postconstruct and for JavaFX the method initialize.
Well, lets see what you could do..
For this example I will start with the FXMLoader. Check the Method setControllerFactory. You will see, that after the creation of the Controller instance the method initInstance() will be called.
 
@Singleton
public class FXMLLoaderSingleton {

    private @Inject @CDILogger Logger logger;
    private @Inject Instance<CDIJavaFxBaseController> instance;

    private final ClassLoader cachingClassLoader = new FXClassLoader(FXMLLoader.getDefaultClassLoader());
    private final Map<Class, FXMLLoader> class2LoaderMap = new HashMap<Class, FXMLLoader>();

    public FXMLLoader getFXMLLoader(Class clazz) {
        final Map<Class, FXMLLoader> loaderMap = class2LoaderMap;
        final String name = clazz.getName();
        if (loaderMap.containsKey(clazz)) {
            if (logger.isDebugEnabled()) {
                logger.debug("fx loader fuer diese klasse schon in der map " + name);
            }
        } else {
            final String fxmlFileName = clazz.getSimpleName() + ".fxml";
            if (logger.isDebugEnabled()) {
                logger.debug("fxmlFileName -> " + fxmlFileName);
            }
            final URL resource = clazz.getResource(fxmlFileName);
//            FXMLLoader loader = new CDIFXMLLoader(resource);
            FXMLLoader loader = new FXMLLoader(resource);
            loader.setClassLoader(cachingClassLoader);
            loader.setControllerFactory(new Callback<Class<?>, Object>() {
                @Override
                public Object call(Class<?> param) {
                    final Class<JavaFXBaseController> p = (Class<JavaFXBaseController>) param;
                    final JavaFXBaseController controller = instance.select(p).get();
                    controller.initInstance(); //trigger async call
                    return controller;
                }
            });
            try {  
                final Class<?> aClass = Class.forName(clazz.getName() + "Controller");
                final CDIJavaFxBaseController call = (CDIJavaFxBaseController) loader.getControllerFactory().call(aClass);
                loader.setController(call);
            } catch (ClassNotFoundException e) {
                logger.error(e);
            }
            loaderMap.put(clazz, loader);
        }
        return loaderMap.get(clazz);
    }

    private FXMLLoaderSingleton() {
    }
}

The method initInstance() will trigger the init-process. Inside the method the task will be called async. The task itself will wait until the CDi and JavaFX init will be ready. After this the method initBusinessLogic will be called. This means, thet the developer only will have to implement the method initBusinessLogic and he will be sure that all init stuff is done.
Happy coding ;-)
public abstract class JavaFXBaseController implements CDIJavaFxBaseController {

    public static final String DONE = "done";

    private boolean mockModusActive = false;
    public boolean isMockModusActive() {
        return mockModusActive;
    }
    public void setMockModusActive(boolean mockModusActive) {
        this.mockModusActive = mockModusActive;
    }

    public abstract void cleanUp();

    public abstract void setI18n();

    private @Inject @CDILogger Logger logger;

    private Boolean initCompleteCDI = false;
    private Boolean initCompleteFX = false;

    public CompletableFuture supplyAsync;

    @Override
    public final void initInstance(){
        final CachedThreadPoolSingleton instance = CachedThreadPoolSingleton.getInstance();
        supplyAsync = CompletableFuture.supplyAsync(task, instance.cachedThreadPool);
        if (logger.isDebugEnabled()) supplyAsync.thenAccept(logger::debug);  //logger
    }

    public final Supplier task = ()-> {
//        Warten bis alle true
        while(! (initCompleteCDI && initCompleteFX) ){
            try {
                //evtl loggen
                if (logger.isDebugEnabled()) {
                    logger.debug("initCompleteCDI = " + initCompleteCDI);
                    logger.debug("initCompleteFX = " + initCompleteFX);
                    logger.debug("getClass().getName() = " + getClass().getName());
                }
                TimeUnit.MILLISECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
                return e.toString();
            }
        }

        if (logger.isInfoEnabled()) {
            logger.info("initBusinessLogic() => called now");
        }
        final boolean fxApplicationThread = Platform.isFxApplicationThread();
        if ( ! fxApplicationThread){
            Platform.runLater(this::initBusinessLogic);
        } else {
            initBusinessLogic();
        }


        if (logger.isInfoEnabled()) {
            logger.info("initBusinessLogic() => done now");
        }
        return DONE;
    };

    @PostConstruct
    public final void postconstruct(){
        if (logger.isDebugEnabled()) {
            logger.debug("PostConstruct mockModusActive == " + mockModusActive);
        }
        cdiPostConstruct();
        initCompleteCDI = true;
        if (logger.isDebugEnabled()) {
            logger.debug("postconstruct ready " + getClass().getName());
        }
    }

    public abstract void cdiPostConstruct();

    @Override
    public final void initialize(URL url, ResourceBundle resourceBundle) {
        if (logger.isDebugEnabled()) {
            logger.debug("initialize mockModusActive== " + mockModusActive);
        }
        initializeFX(url, resourceBundle);
        initCompleteFX = true;
        if (logger.isDebugEnabled()) {
            logger.debug("initialize ready " + getClass().getName());
        }
    }


    protected abstract void initializeFX(URL url, ResourceBundle resourceBundle);
    /**
     * wird nach der init von CDI und JavaFX aufgerufen,
     * egal in welcher Reihenfolge die init durchlaufen wird.
     *
     * ein blockierender method call
     *
     */
    public abstract void initBusinessLogic();
}

Dienstag, 8. April 2014

Dynamic WADL with CDI

The WADL (Web Application Definition Language) is used to describe HTTP-based applications which means that JAXRS applications can and are described by that. Typically it is generated (static or dynamic) with the jersey maven plugin (detailed informations can be found here). But for some reason i could not use either maven nor the jersey plugin. So i had to do it on my own and used it as a little finger exercise. The main goal was to achieve dynamic wadl generation for a JAXRS application. The working steps were relativly easy:
  • Create a JAXB-Model from the current WADL-Specification
  • Create a CDI-Based design for JAXRS resources
In the end you only have to provide a producer class which creates a @Wadl Class[] and inject an instance of @Wadl  @WadlApplication.

@Path("/")
public class MyResource
{
 @Inject
 @Wadl
 @WadlApplication
 Instance<Application> applicationInstance;

 @GET
 @Produces(MediaType.APPLICATION_XML)
 public Application getRoot(@Context UriInfo uriInfo)
 {
  return getWadl(uriInfo);
 }
}

 As a simple example assume that you have a TinkerForge MasterBrick connected to a RaspberryPi. Addionally you want to provide a JAXRS-Resource for every connected sensor. With the sample code below you are now able to extend the WADL dynmically.

public class WadlClassProducer
{
 @Inject
 @SensorAnno
 @Any
 Instance<SensorResource> sensorInstances;

 @Produces
 @Wadl
 public Class[] create()
 {
  List<Class<?>> clazzList = new ArrayList<Class<?>>();
  for (SensorResource sensor : sensorInstances)
  {
   clazzList.add(sensor.getResourceClass());
  }
  return clazzList.toArray(new Class[0]);
 }
}

The sources can be found here.

Freitag, 28. März 2014

Java8 CompletableFuture for JavaFX and CDI Part I

Java8 CompletableFuture for JavaFX and CDI Part I Java8 will give you a few more tools to solve concurrency problems.
One of them is the CompletableFuture. I will show you, how you could sync the
two different init-cycles from CDI and JavaFX with this.

CDI and JavaFX are using a life-cycle during the init process.
For CDI you can use the method that is annotated with the
AnnotationLiteral @Postconstruct and for JavaFX you can use the method initialize(..)
If you want to have a method that is called after both others are finished you have to think
about the problem that it is not clear which method is called first.
To show more in detail what the problem is let us think about the following.
 
private String pattern;
private SimpleDateFormat sdf;

//beispielhaft für eine init
public void createSDF(){
    this.sdf = new SimpleDateFormat(this.pattern);        
}

//beispielhaft für eine init
public void newPattern(final String pattern) {
    this.pattern = pattern;
}

public String format(final Date date){
    return sdf.fomat(date);
}
To use the method format(..) you must use the methods newPattern(..) and createSDF first.
But both in the right order like the following code snipp.
 
newPattern("yyyy.MM.dd");
createSDF();
final String s = versionAB.format(new Date());
System.out.println("s = " + s);
If you are calling first createSDF(..) for example you will get an exception.
But thinking to the problem with CDI and JavaFX it must be valid to do something like the following.
 
createSDF();
newPattern("yyyy.MM.dd");

final String s = versionAB.format(new Date());
System.out.println("s = " + s);
The method creatdSDF(..) is called before newPattern(..).
The solution is quite simple. The method call from createSDF must be non blocking but
waiting with the execution until newPattern(..) was called.
The same with format(..). This method call must wait until both are finished but itself it
is an blocking method call. This is to give the developer the feeling he expected,
if he is working with the result from format(..).
To solve this we have to booleans called initCompleteA and initCompleteB.
Both are false in the beginning. If newPattern(..) is called initcompleteA will be true,
and initCompleteB will be true after the method creatSDF() is ready.
 
public void newPattern(final String pattern) {
    this.pattern = pattern;
    initCompleteA=true;
    System.out.println("newPattern = " + pattern);
}
public void createSDF(){
    CompletableFuture<Void> supplyAsync
        = CompletableFuture
        .supplyAsync(taskCreateSDF, cachedThreadPool);
    supplyAsync.thenAccept(System.out::println);
}
public Supplier<Void> taskCreateSDF = ()-> {
    while(! initCompleteA ){
        try {
            System.out.println("createSDF is waiting" );
            TimeUnit.MILLISECONDS.sleep(4);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    sdf = new SimpleDateFormat(pattern);
    initCompleteB = true;
    return null;
};
The Method format(..) now is only waiting for both...
 
public Supplier<String> task = ()-> {
//Warten bis alle true
    while(! (initCompleteA && initCompleteB) ){
        try {
            System.out.println("initCompleteA = " + initCompleteA);
            System.out.println("initCompleteB = " + initCompleteB);
            System.out.println("pattern = " + pattern);
            System.out.println("sdf = " + sdf);
            TimeUnit.MILLISECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
    return sdf.format(this.date);
};
private Date date;

public String format(final Date date){
    this.date = date;
    supplyAsync = CompletableFuture
        .supplyAsync(task, cachedThreadPool);
    try {
        return supplyAsync.get();
    } catch (InterruptedException | ExecutionException e) {
        e.printStackTrace();
    }
    return "";
}
The example you will find at http://stash.rapidpm.org/projects/PUB/repos/jaxenter.de-0016-async-calls/browse
The next Part will show how we have to implement the JavaFX CDI bootstrapping to use this.

Montag, 17. März 2014

Lego Mindstorms EV3 Components: Color Sensor - Part 1

In this and in our next postings on our Lego Mindstorms series we will have a closer look at the EV3 color sensor. Today we will use the sensor's ability of detecting and distinguishing different colors.

Meanwhile version 0.7.0 of the lejos api was released. But in this tutorial we will still use the 0.6.0-release as 0.7.0s changes weren't dramatic. So you should be able to run the same program with 0.7.0, too.

The robot

The only task the robot will do in this tutorial is: Detecting colors and tell us which color was detected. So in fact we only need the sensor. No motors or something like that is needed. But as we already have a robot from our last articles on the infrared sensor we will take that one and only switch the infrared sensor with the new color sensor.



The parcours

We built a stick with different colors: red, green, yellow and blue. We will hold the different colors in front of the robot's sensor and the robot should give feedback on the detected color by letting the background-LED of the brick's buttons illuminate in the same color. One exception: If blue is detected the program should exit.


The color sensor API

Like the infrared sensor the color sensor has different modes for different tasks. The infrared sensor for example had modes to detect signals of an infrared source or to detect objects and their distance to the robot.
There is a mode for every task a sensor can execute. To detect different colors we need the color sensor's colorIDMode. Once the sensor is in the right mode we only need to call colorSensor.getColorID to get the detected color.

Sounds easy, IS easy. Here comes the code.

The code

We have two classes this time: The Main-class and the ColorRecognizerThread-class. First, let's look at the (really small) main-class:

public class Main {


    public static void main(String[] args) throws InterruptedException {
        final EV3ColorSensor colorSensor = new EV3ColorSensor(SensorPort.S2);
        final SensorMode mode = colorSensor.getColorIDMode();
        final ColorRecognizerThread colorRecognizerThread = new ColorRecognizerThread(colorSensor);

        colorRecognizerThread.start();

        Button.waitForAnyPress();
    }

}

In contrast to our earlier postings we don't need a DifferentialPilot this time because the robot doesn't have to move. So the only things we do is instantiating a new ColorSensor-Instance and set it to the colorIDMode. Then we instantiate a ColorRecognizerThread (which extends Thread) and give it the color sensor object as a constructor parameter. In that thread we will implement the logic to detect colors and let the LED illuminate in the same color.
After starting the thread we wait for any button press as always so that our program won't just exit after starting the thread.

The ColorRecognizerThread looks like the following:

public class ColorRecognizerThread extends Thread {

    private EV3ColorSensor colorSensor;

    public ColorRecognizerThread(final EV3ColorSensor colorSensor) {
        this.colorSensor = colorSensor;
    }

    @Override
    public void run() {
        while(true){
            final int colorId = colorSensor.getColorID();
            switch (colorId){
                //RED
                case 0:
                    Button.LEDPattern(2);
                    break;
                //GREEN
                case 1:
                    Button.LEDPattern(1);
                    break;
                //BLUE
                case 2:
                    Button.LEDPattern(4);
                    threadSleep(2000);
                    Button.LEDPattern(0);
                    System.exit(0);
                //YELLOW
                case 3:
                    Button.LEDPattern(3);
                    break;
                default:
                    Button.LEDPattern(0);
            }
        }
    }

    private void threadSleep(final int ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

}

The constructor is easy as it only saves the color sensor object into a private variable so that we can use it in the run-method.
The really interesting part is the run-method of course, which is called when starting the thread in the main class. We have a deadloop as we want the robot to detect colors continuously. In that loop we get the color found by the color sensor by calling the getColorID()-Method. As you can see it returns an integer. By having a look at the sources (Color.java) we find out which integer value stands for which color:

    public static final int RED = 0;
    public static final int GREEN = 1;
    public static final int BLUE = 2;
    public static final int YELLOW = 3;
    public static final int MAGENTA = 4;
    public static final int ORANGE = 5;
    public static final int WHITE = 6;
    public static final int BLACK = 7;
    public static final int PINK = 8;
    public static final int GRAY = 9;
    public static final int LIGHT_GRAY = 10;
    public static final int DARK_GRAY = 11;
    public static final int CYAN = 12;
    public static final int BROWN = 13;
    public static final int NONE = -1;

So, after getting the id we have a "switch case"-statement for that id. If the found color is red, green or yellow we just want the background-LED of the brick to illuminate in the same color (case 0, 1 and 3). Maybe you are curious why the integer parameter for the Button.LEDPattern-method doesn't match with the integer values from the Color-class. Well, the LED doesn't have a pattern for all of the colors. It has 9 different patterns in total (thanks to tigger from the forum for that information!)

0: turn off button lights
1/2/3: static light green/red/yellow
4/5/6: normal blinking light green/red/yellow
7/8/9: fast blinking light green/red/yellow
>9: same as 9.
 If the color blue is found (case 2) I wanted the program to do the following: Turn the light of the color sensor of and exit the program. The api says that we can use the setFloodlight(int color)-method for that by calling it with Color.NONE:

/**
* Used to turn on or off the floodlight by color. If the sensor has multiple light colors,
* you can control which color is turned on or off. If the color does not exist, it does
* nothing and returns false. You can turn the floodlight off by using Color.NONE.
But this throws an exception if you look at the sources of EV3ColorSensor (the default case of the switch-statement):

public boolean setFloodlight(int color)
    {
        int mode;
        switch (color)
        {
        case Color.BLUE:
            mode = COL_AMBIENT;
            break;
        case Color.WHITE:
            mode = COL_COLOR;
            break;
        case Color.RED:
            mode = COL_REFLECT;
            break;
        default:
            // TODO: Should we ignore a wrong color or throw an exception?
            throw new IllegalArgumentException("Invalid color specified");
        }
        switchMode(mode, SWITCH_DELAY);
        // TODO Auto-generated method stub
        return true;
    }

But I never the less wanted to give some optic signal to show that the program is exiting. Turning off the LED wasn't enough because we already turn it of in our default case of our switch statement in the ColorRecognizerThread. In the end I decided to let the LED display the pattern 4 (blinking green) for two seconds before exiting the program. The threadSleep-method was just created to have the try-catch out of our run-method (because it looks stupid).

That's all.

The result

And here is the tiny result (watch on youtube for better quality):





Montag, 10. März 2014

Lego Mindstorms EV3 Components: Infrared Sensor - Part 3

This is the last part of our articles on the mindstorm's infrared sensor. After looking at the abilities of the remote sensor to recognize objects and commands from the remote control we will now have a closer a look on the functionality of finding an infrared signal sent by the remote control constantly.

In february the lejos api had a new release - 0.6.0-ALPHA, so while using the 0.5.0-ALPHA-release in our last articles we will by now use the 0.6.0-release.

The robot

We will use the robot from the last two articles on the infrared sensor again, and of course we will use the remote control. If you haven't checked the infrared articles already ( Part 1/Part 2) you should do so.

The parcours

There is the robot and there is the remote control. In this part we want to tell the robot: Hold a distance of about 20-35cm to the remote control!
Which means that if we move the remote control nearer to the robot, it should move backwards and if we move the remote control away from the robot it should follow. We will only use the toggling button this time. If it is toggled and sending a signal, the robot should care about holding the right distance to the remote control. The program will exit if the signal ends (the button is untoggled).

The infrared sensor API

As announced in our last part on the infrared sensor we will use the SeekMode this time to receive the relative position and distance of the remote control.

What we will need to instantiate therefore is: the infrared sensor and a RangeFinderAdaptor for the infrared sensor.

As soon as we instantiated a RangeFinderAdapter we can use its getRanges()-method which returns all required information to let the robot find the remote control and its position.

We will use a thread which will check those informations continuously so that the robot will always react to changes of the remote controls position.

Let us directly jump to the finished code and see how it works in detail.

The code

We have two classes this time: The Main-class and the InfraredSignalCheckerThread-class. First, let's look at the main-class:

public class Main {

    protected final static double PILOT_SPEED = 60.0;
    protected final static int PILOT_ACCELERATION = 500;
    protected final static double WHEEL_DIAMETER = 30.0f;
    protected final static double DISTANCE_BETWEEN_WHEELS = 170.0;

    public static void main(String[] args) throws InterruptedException {

        final DifferentialPilot pilot = new DifferentialPilot(WHEEL_DIAMETER, DISTANCE_BETWEEN_WHEELS, Motor.C, Motor.B);
        final EV3IRSensor infraredSensor = new EV3IRSensor(SensorPort.S2);
        final RangeFinderAdaptor rangeFinderAdaptor = new RangeFinderAdaptor(infraredSensor.getSeekMode());
        final InfraredSignalCheckerThread checkerThread = new InfraredSignalCheckerThread(rangeFinderAdaptor, pilot);

        configurePilot(pilot);
        checkerThread.start();

        Button.waitForAnyPress();
    }

    private static void configurePilot(final DifferentialPilot pilot) {
        pilot.setAcceleration(PILOT_ACCELERATION);
        pilot.setRotateSpeed(PILOT_SPEED);
        pilot.setTravelSpeed(PILOT_SPEED);
    }
}

First, we instantiate the pilot and the infraredSensor as always. Then we instantiate the RangeFinderAdapter which gets the infrared-sensor's SeekMode as a parameter. The RangeFinderAdapter will return all informations on the remote control's position. We then instantiate a InfraredSignalCheckerThread which gets the adaptor to check the remote control's position continuosly and the pilot to let the robot react on the remote control's position.

After the instantiations we set the pilot's speeds and start the thread. So now let's have a look at our Thread-class:

public class InfraredSignalCheckerThread extends Thread {

    private RangeFinderAdaptor adaptor;
    private DifferentialPilot pilot;
    private boolean isMoving = false;
    private  boolean isBearing = false;

    public InfraredSignalCheckerThread(final RangeFinderAdaptor adaptor, final DifferentialPilot pilot){
        this.adaptor = adaptor;
        this.pilot = pilot;
    }

    @Override
    public void run() {
        while(true){
            final float bearing = adaptor.getRanges()[0];
            final float distance = adaptor.getRanges()[1];
            if(distance < 129.0f && distance > 127.0f && bearing < 1.0f){
                System.exit(0);
            }
            doBearing(bearing);
            doMoving(distance);
        }
    }

    private void doBearing(final float bearing) {
        if(bearingIsOk(bearing)){
            isBearing = false;
        }
        else {
            if(bearing > 5.0f){
                pilot.rotateRight();
                isBearing = true;
            } else {
                pilot.rotateLeft();
                isBearing = true;
            }
        }
    }

    private void doMoving(final float distance) {
        if(!isBearing){
            if(!isMoving){
                pilot.quickStop();
            }
            if(distanceIsOk(distance)){
                pilot.quickStop();
                isMoving = false;
            }
            else {
                if(distance < 25.0f){
                    pilot.backward();
                } else {
                    pilot.forward();
                }
                isMoving = true;
            }
        }
    }

    private boolean bearingIsOk(final float bearing) {
        if(bearing < 5.0f && bearing > -5.0f){
            return true;
        }
        return false;
    }

    private boolean distanceIsOk(final float distance) {
        if(distance >20.0f && distance < 35.0f){
            return true;
        }
        return false;
    }
}

The constructor is easy as it only saves the adaptor and the pilot into private variables so that we can use them in the run-method. If you have a look at the private variables you will see that there are two boolean attributes isBearing and isMoving. We need those variables because we want to robot to first react on direction changes of the remote control (which is done by rotating), and we don't want the robot to react on distance changes (which is done by moving forwards/backwards) until the bearing has finished.

Okay, let's have a look at the run-method which is called when we start the thread in the main-class.
We need two information on our remote control: The relative bearing to the robot and the distance to the robot. As said earlier, the getRanges()-Method returns those information. Here is what the api says:
/**
     * return a sample provider for the IR sensor operating in seek mode
     * The provider returns the bearing and distance to one or more IR beacons.
     * Up to four
     * beacons (on different channels 0-3) can be detected. Each beacon has an
     * associated two byte value (so the beacon on channel 0 will have values
     * in locations 0 and 1 in the array. The first location contains the relative
     * bearing to the beacon, the second the distance.

     * The bearing values range from -12 to +12 (with values increasing clockwise
     * when looking from behind the sensor. A bearing of 0 indicates the beacon is
     * directly in front of the sensor. Distance values (0-100) are in cm and if no
     * beacon is detected a bearing of 0 and a distance of 255 is returned.

So, we only care for the first two floats of the array because we only have one remote control. And we want the bearing-information of it ([0]) and the distance-information ([1]).

After writing those informations into float variables we check, if the information are valid: The api says, if no signal is found the value of bearing will be 0 and the distance will be 255. So first, we check this case and exit the program if no signal is found (I found out, that if no signal is sent, the distance value is 128.0 and not 255 as written in the api).

If the values are valid (a signal was received we call the methods doBearing and doMoving). Those methods will make the robot first react on direction changes of the remote control, and then react on distance changes afterwards. Let's have a closer look at these two methods, first the doBearing-Method:

private void doBearing(final float bearing) {
        if(bearingIsOk(bearing)){
            isBearing = false;
        }
        else {
            if(bearing > 5.0f){
                pilot.rotateRight();
                isBearing = true;
            } else {
                pilot.rotateLeft();
                isBearing = true;
            }
        }
    }

private boolean bearingIsOk(final float bearing) {
        if(bearing < 5.0f && bearing > -5.0f){
            return true;
        }
        return false;
    }

First, we check if the bearing is okay, which means that the remote control is more or less directly in front of the robot. As said in the api that value can be anything between -12 and 12 (I found out, that this value can be anything between -25 and 25). So we tell the program, if the value is between -5 and 5 the bearing is okay and the reaction of the robot has finished. If the bearing is not okay, we tell the robot to rotate right of the bearing is greater than 5, or rotate left if the value is lower than -5. While rotating, we tell the program, that the robot is reacting to the bearing, by setting the isBearing-attribute to true. By the rotation the bearing value will approach to 0. When that's the case we tell the program, that the robot has finished its reaction and set the isBearing variable to false.

And here's the doMoving-Method:

private void doMoving(final float distance) {
        if(!isBearing){
            if(!isMoving){
                pilot.quickStop();
            }
            if(distanceIsOk(distance)){
                pilot.quickStop();
                isMoving = false;
            }
            else {
                if(distance < 20.0f){
                    pilot.backward();
                } else {
                    pilot.forward();
                }
                isMoving = true;
            }
        }
    }
private boolean distanceIsOk(final float distance) {
        if(distance >20.0f && distance < 35.0f){
            return true;
        }
        return false;
    }

When the doBearing-method has finished, the doMoving-method will start. But we only want to react on the remote control's distance if the robot has finished it's reaction to the bearing. So we first check, if the robot is not bearing any longer. The second "if" that follows now is a bit tricky: We check, if the robot is moving as a result from the doMoving-Method or as a result from the doBearing-method. If it NOT moving as a result of the doMoving-method, it should stop because then we have the case, that the robot is still rotating as a reacting to the bearing (we didn't tell the program to stop rotating any time in the doBearing-method). So after that, we check if the remote control's distance is okay (which means the remote control is in a distance of 20 to 35cm) to the robot. If that is the case the robot should stop and we mark the isMoving-attribute as false. If the distance is NOT okay we tell the robot to move backwards of the distance is less then 25 (because it should "flee" from the remote control) or move forwards if the distance is greater than 35 (because it should "follow" the remote control).

The result

And here is the result (watch on youtube for better quality):





Freitag, 28. Februar 2014

Wildfly/JBoss: How to secure customer passwords

If you are familiar with Wildfly/JBoss you might now that you can easily configure your system to use JAAS database authentication for the login process of your customer. Because it is considered bad practice to store passwords in clear text a hash-algorithm (e.g. SHA256, MD5) can be specified to encrypt them. Further informations can be found under here.

The problem with that approach is that your passwords will be vulnerable to dictionary and rainbowtable attacks (refresh your knowlegde here).
One way to face this problem is to use salted hashed passwords but the standard DatabaseServerLoginModule does not support that. But you can use this extension of the DatabaseServerLoginModule.
The configuration is fairly easy:

Wildfly/JBoss Konfiguration

1. Create module
Create the new module de.rtner.security.main and configure the module.xml like this
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="de.rtner.security">
    <resources>
        <resource-root path="PBKDF2-1.0.4.jar"/>
        <resource-root path="SaltedDatabaseLoginModule-1.0.4.jar"/>
    </resources>
   <dependencies>
        <module name="javax.api"/>
        <module name="javax.servlet.api"/>
        <module name="org.jboss.as.web-common"/>
        <module name="org.jboss.logging"/>
        <module name="org.picketbox"/>
        <module name="sun.jdk"/>
    </dependencies>
</module>
Both declared jars must also be present in that folder.

2. Update module.xml of picketbox.

Every custom login module has to be declared as a dependencies in the module.xml of picketbox. So just add this line:
<module name="de.rtner.security"/>
3. Update standalone.xml
<login-module code="de.rtner.security.auth.spi.SaltedDatabaseServerLoginModule" flag="required" module="de.rtner.security">
 <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
 <module-option name="principalsQuery" value="select password from User where login=?"/>
 <module-option name="rolesQuery" value="select role, 'Roles' from UserRole where login=?"/>
 <module-option name="hmacAlgorithm" value="HMacSHA256"/>
 <module-option name="formatter" value="de.rtner.security.auth.spi.PBKDF2HexFormatter"/>
 <module-option name="engine" value="de.rtner.security.auth.spi.PBKDF2Engine"/>
 <module-option name="engine-parameters" value="de.rtner.security.auth.spi.PBKDF2Parameters"/>
</login-module>

The password encryption can be done with the following function.
private String createPbKdF2Passwort(String password) throws NoSuchAlgorithmException
{
 PBKDF2Formatter formatter = new PBKDF2HexFormatter();
 SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
 byte[] salt = new byte[8];
 sr.nextBytes(salt);
 int iterations = 1000;
 PBKDF2Parameters p = new PBKDF2Parameters("HmacSHA256", "ISO-8859-1", salt, iterations);
 PBKDF2Engine e = new PBKDF2Engine(p);
 p.setDerivedKey(e.deriveKey(password));
 return formatter.toString(p);
}

Have fun coding.

Donnerstag, 20. Februar 2014

are you missing the ? operator from project coin?

How to get rid of 90% boiler plate code from NPE-save model - surfing?
What I am meaning with modell surfing? For example you have a class DemoClassA.
Inside DemoClassA you have an instance of DemoClassB.
Inside DemoClassB you have an instance of DemoClassC. And so on..

You need something like the following.

String value = demoClassA.getDemoClassB().getDemoClassC().getValue();
The bad thing is if your valid model could have ClassB or ClassC with null. You only have to show the value inside your GUI if the complete getter - cascade will be valid. The first would be something like this.

  
 DemoClassB valueB = demoClassA.getDemoClassB();
 if(demoB != null){
    DemoClassC demoC = demoB.getDemoClassC();
    if(demoC != null){
     String value = demoC.getValue();
    }
 }
A lot of booooring code. Project Coin had something with Wildcards.
 
 String value = demoClassA?.getDemoClassB()?.getDemoClassC()?.getValue();
 
This is really nice, but it was not accepted. So I had do something like this for myself.
One main point will be that the objects are ready initialized and I could not change the source code from this part. Other languages as plain Java are not allowed. No other frameworks, no AOP and something like this. Puuhh.. what else?
I was thinking about the newsletter nr 180 (http://www.javaspecialists.eu/archive/Issue180.html) from Heinz Kabutz. He explained how to generate static Proxy Classes. This was a good point to start from.
The key concept is the generating of Proxy Classes on the fly if they are needed. Via Reflection the real Subject is analysed and the Proxy generated. He is instanciating the new proxy class and the real subject with the default constructor. For my project this was not helpfull, because the model was grown over the last 10 years. Nearly no default constructor is available and the project owner was building something like a RMI Lazy Loading inside the persistent model. This model itself is used directly inside Swing.. hmmmmm nothing was I really want to use...
Changing the old code is very time consuming.
On the other side I was writing a lot of this if != null code.
So I decided to write a Proxy that I can use on initialized objects. This must be recursive to get the NPE save getter cascades. Based on Heinz code, I started to write a VirtualProxySourceGeneratorOnExistingObject to stop the instance creation on the real Subject.
public class VirtualProxySourceGeneratorOnExistingObject extends VirtualProxySourceGenerator {

    public VirtualProxySourceGeneratorOnExistingObject(
            Class subject, Class realSubject) {
        super(subject, realSubject, Concurrency.OnExistingObject);
    }
    protected void addRealSubjectCreation(PrintWriter out,  String name, String realName) {
        out.printf(" public %s realSubject;%n", name);
        out.println();
        out.printf(" private %s realSubject() {%n", name);
        out.println(" return realSubject;");
        out.println(" }");
    }
}  
After this I changed the VirtualProxySourceGeneratorto use this VirtualProxySourceGeneratorOnExistingObject and changed it in a way that a getter method will generate a new Proxy for the next realSubject.
public abstract class VirtualProxySourceGenerator {

    protected final Class subject;
    protected final Class realSubject;
    private final String proxy;
    private CharSequence charSequence;
    private Concurrency type;

    public VirtualProxySourceGenerator(
            Class subject, Class realSubject, Concurrency type) {
        this.subject = subject;
        this.realSubject = realSubject;
        this.type = type;
        this.proxy = makeProxyName(subject, type);

    }

    private static String makeProxyName(Class subject, Concurrency type) {
        return "$$_" + subject.getName().replace('.', '_') +
                "Proxy_" + Integer.toHexString(System.identityHashCode(
                subject.getClassLoader())) + "_" + type;
    }

    public String getProxyName() {
        return proxy;
    }

    public CharSequence getCharSequence() {
        if (charSequence == null) {
            StringWriter sw = new StringWriter();
            generateProxyClass(new PrintWriter(sw));
            charSequence = sw.getBuffer();
        }
        //System.out.println("charSequence = " + charSequence.toString());
        return charSequence;
    }

    private void generateProxyClass(PrintWriter out) {
        addClassDefinition(out);
        addProxyBody(out);
        out.close();
    }

    private void addProxyBody(PrintWriter out) {
        addRealSubjectCreation(out, subject.getName(), realSubject.getName());
        addProxiedMethods(out);
        out.println("}");
    }

    protected abstract void addRealSubjectCreation(PrintWriter out, String name, String realName);


    private void addClassDefinition(PrintWriter out) {
        addImports(out);
        out.printf("public class %s %s %s {%n",
                proxy, getInheritanceType(subject), subject.getName());
    }

    private String getInheritanceType(Class subject) {
        return subject.isInterface() ? "implements" : "extends";
    }

    protected void addImports(PrintWriter out) {

    }

    private void addToStringIfInterface(PrintWriter out) {
        if (subject.isInterface()) {
            out.println();
            out.println(" public String toString() {");
            out.println(" if(realSubject() == null ) return \"NullObjectHolder in \" + this.getClass() ;");
            out.println(" return realSubject().toString();");
            out.println(" }");
        }
    }

    private void addProxiedMethods(PrintWriter out) {
        for (Method m : subject.getMethods()) {
            addProxiedMethod(out, m);
        }
        addToStringIfInterface(out);
    }

    private void addProxiedMethod(PrintWriter out, Method m) {
        if (Modifier.isFinal(m.getModifiers())) return;
        addMethodSignature(out, m);
        addMethodBody(out, m);   //NPE da val ger getter gefuellt wird

        final Class returnType = m.getReturnType();
        if (returnType == void.class) out.printf(");%n }%n");
        else {
            out.printf(");%n");  //end of orig method.. start proxy additional stuff
            final boolean aFinal = Modifier.isFinal(returnType.getModifiers());
            if (!returnType.isPrimitive() && !returnType.isArray() && ! aFinal ){
                final String typeName = returnType.getTypeName();
                final String proxyGenerator = "org.rapidpm.module.se.commons.proxy.ProxyGenerator";
                final String concurrency = "org.rapidpm.module.se.commons.proxy.Concurrency";
                out.printf(" if (val == null) { System.out.println(\" val == null for method  + " +m.getName()+ "\");} %n");
                out.printf(typeName + " proxyObj = " + proxyGenerator+ ".make("+typeName+".class, "+typeName+".class, " +concurrency+"."+type.toString()+"); %n");

                if (type.equals(Concurrency.OnExistingObject)){
                    out.printf("try { %n");
                    out.printf("    proxyObj.getClass().getDeclaredField(\"realSubject\").set(proxyObj, val);  %n");
                    out.printf("} catch (IllegalArgumentException | IllegalAccessException | NoSuchFieldException | SecurityException e) {  %n");
                    out.printf("    e.printStackTrace(); %n");
                    out.printf("}  %n");
                }
                out.printf(" return proxyObj; %n");
            } else {
                out.printf(" return val; %n");
            }
                out.printf("%n}%n");
        }
    }

    private void addMethodSignature(PrintWriter out, Method m) {
        out.printf("%n public %s", Util.prettyPrint(m.getReturnType()));
        out.printf(" %s(", m.getName());
        addParameterList(out, m);
        out.printf(") {%n ");
    }

    private void addParameterList(PrintWriter out, Method m) {
        Class[] types = m.getParameterTypes();
        for (int i = 0; i < types.length; i++) {
            String next = i == types.length - 1 ? "" : ", ";
            out.printf("%s p%d%s", Util.prettyPrint(types[i]), i, next);
        }
    }

    private void addMethodBody(PrintWriter out, Method m) {
        addMethodBodyDelegatingToRealSubject(out, m);
    }

    private void addMethodBodyDelegatingToRealSubject(PrintWriter out, Method m) {
        //hole result
        final Class returnType = m.getReturnType();
        if (returnType == void.class) out.printf("realSubject().%s(", m.getName());
        else if(m.getName().equals("toString")){
            out.println("String val;");
            out.println(" if(realSubject() == null ) val = \"NullObjectHolder in \" + this.getClass() ; ");
            out.printf(" else val = realSubject().%s(", m.getName());
        } else if(m.getName().startsWith("get") && ! returnType.isPrimitive()){
            String name;
            if (returnType.isArray()) name = returnType.getSimpleName();
            else name = returnType.getName();
            out.println(name + " val;");
            out.println(" if(realSubject() == null ) val = null ; ");
            out.printf(" else val = realSubject().%s(", m.getName());   
        } else {
            String name;
            if (returnType.isArray()) name = returnType.getSimpleName();
            else name = returnType.getName();
            out.println(name + " val;");
            out.printf("val = realSubject().%s(", m.getName());  

        }
        addMethodCall(out, m);
    }

    private void addMethodCall(PrintWriter out, Method m) {
        Class[] types = m.getParameterTypes();
        for (int i = 0; i < types.length; i++) {
            String next = i == types.length - 1 ? "" : ", ";
            out.printf("p%d%s", i, next);
        }
    }
}
The result is really cool. see the following code ;-)
       DemoClassA demoClassA = new DemoClassA();
        demoClassA.demoClassB = null;

        final String value = proxy(demoClassA).getDemoClassB().getDemoClassC().getValue();
        System.out.println("value = " + value);

You can navigate the full path. no NPE! No boiler plate code!
@Test
    public void testGenerator00X() throws  Exception {
        DemoClassA demoClassA = new DemoClassA();
        demoClassA.demoClassB = null;

        final String value = proxy(demoClassA).getDemoClassB().getDemoClassC().getValue();
        System.out.println("value = " + value);

    }

private DemoClassA proxy(DemoClassA demoClassA) {
        final Class<DemoClassA> aClass = (Class<DemoClassA>) demoClassA.getClass();
        final DemoClassA demo = ProxyGenerator.make(aClass, aClass, Concurrency.OnExistingObject);

        final Class<? extends DemoClassA> aClassProxy = demo.getClass();
        try {
            aClassProxy.getDeclaredField("realSubject").set(demo,demoClassA );
        } catch (IllegalArgumentException | IllegalAccessException | NoSuchFieldException | SecurityException e) {
            e.printStackTrace();
        }
        return demo;
    }
You can now use every getter.. not NPE. Only the result will be an null. This was exactly what I needed to get only the valid values from the model if they are available. This means, that you could proxy an object after you have initialized it. The full source code is available under : https://bitbucket.org/rapidpm/modules on the develop branch. I will merge it into the version 2.0 as generic pattern and CDI managed...

Montag, 17. Februar 2014

CDI EJB-Remote Context for wildfly

This article shows how ejb remote clients can be configured and connected in a more dynamic way.

Within wildfly (current version 8.0.0.Final) there are several possibilities to connect ejb remote clients. Descriptions can be found on:

The Problem


You have an application for two (or more) tenants which are identical but are deployed on different machines. Customers should be able to switch between those tenants without restarting the application. Additionally the code itself should not depend on tenant specific code.
As far as i know this would be necessary with the standard approach (jboss-ejb-client.properties) given above.

A Solution


After some consideration i have identified the following five components which are needed to implement this feature.
  • Component that creates WildFly ejb remote connections
  • Component that produces the JNDI-Context
  • Component that holds the selected tenant-key for the client
  • Component that maps the tenant-keys to connection properties
  • CDI-Modul Qualifier

Putting them together leads to the following UML:



To keep the example as simple as possible i have decided to use the ejb-remote-quickstart example and extend it with the jndicontext module. The current implementation uses a simple property file which holds the following data.
tenant1.host=localhost
tenant1.port=8080
tenant1.username=test
tenant1.password=test
tenant1.noanonymous=false

tenant2.host=192.168.0.104
tenant2.port=8080
tenant2.username=test
tenant2.password=test
tenant2.noanonymous=false

The Fazit


The resulting service locator just has to use the JndiSession (in this example the RemoteEJBClient) which technically holds the tenant key and can be set from the GUI.
public class RemoteEJBClient {
    @Inject @JndiContextAnno
    Instance<Context> contextInstance;

    @Inject
    JndiSession jndiSession;
    //...snip
    private RemoteCalculator lookupRemoteStatelessCalculator() throws NamingException {
        Context context = contextInstance.get();
        //...snip
    }
}

public class CDIBootStrapper {
    public static void main(String[] args) throws Exception
    {
        WeldContainer weld = new Weld().initialize();
        RemoteEJBClient client = weld.instance().select(RemoteEJBClient.class).get();

        client.getJndiSession().setTenantKey("tenant1");
        client.invokeStatelessBean();

        client.getJndiSession().setTenantKey("tenant2");
        client.invokeStatelessBean();
    }
)
So the code looks very clean and in comparison to jboss-ejb-client.properties way more functional.
The sources can be found on https://bitbucket.org/abischof/injectablejndicontext.
Have fun coding... ;)

Donnerstag, 13. Februar 2014

Raspberry Wildfly Cluster for less than 300€

So WildFly 8 is final now.
In this article i like to show how you can create a development/testing wildly cluster with raspberry pis and only one power supply.

I have bought:
  • 5x Raspberry Pis (Model B) with Wireless USB-Adapters
  • 1x 10-Port USB 2.0 Hub
  • 5x USB to Micro USB Adpapter

The Raspberries are configured with Raspbian Wheezy (wlan auto), JDK 8 and Wildfly 8 Final.
In this combination you have to remove the '-server' from the domain.sh otherwise WildFly won't start.

The WildFly Configuration can be made within 5 minutes.
  1. Master
    1. Create management user admin (./add-user.sh)
    2. Create a management slave user for each of your pi slaves (./add-user.sh)
      • Remember the secret value at the end of this process for each slave (e.g.<secret value="MTIzNDU=" />)
    3. Bind the interfaces to the public interface (e.g. 192.168.0.103) 
  2. Slave
    1. Configure host.xml with the slave name of 1.1
      • <host name="slave1" xmlns="urn:jboss:domain:2.0">
    2. Configure the server identity
      • <server-identities> <secret value="MTIzNDU="/> </server-identities>
    3. Bind the interfaces to master and public interface (e.g. 192.168.0.104)
      • To simply the typing i have written a small script that takes the master-ip and the bind-ip
      • #MasterAdress
        MASTER_ADDRESS=$1
        
        # Bind Addresses
        BIND_ADDRESS=$2
        
        JBOSS_BIND_ADDRESS_MANAGEMENT=$BIND_ADDRESS
        JBOSS_BIND_ADDRESS=$BIND_ADDRESS
        JBOSS_BIND_ADDRESS_UNSECURE=$BIND_ADDRESS
        
        sudo ./domain.sh -Djboss.bind.address.unsecure=$JBOSS_BIND_ADDRESS_UNSECURE -Djboss.bind.address.management=$BOSS_BIND_ADDRESS_MANAGEMENT -Djboss.bind.address=$JBOSS_BIND_ADDRESS -Djboss.domain.master.address=$MASTER_ADDRESS
Ready. Now you can deploy any archive either to main-server-group (just a domain) or other-server-group (full cluster).

Montag, 10. Februar 2014

JDK8/Streams are cool? Here is the answer. ;-)

Today I was preparing a few slides for my next JUG talk. For this if started with a normal piece of code like the following.
  
    public List<List<Integer>> generateDemoValueMatrix() {
        final List<List<Integer>> resultMatrix = new ArrayList<>();
        final Random random = new Random();
        for(int anzahlKurven = 0; anzahlKurven <ANZAHL_KURVEN; anzahlKurven++){
            final List<Integer> result = new ArrayList<>();
            for (int i = 0; i < 10; i++) {
                final int nextInt = random.nextInt(100);
                result.add(nextInt);
            }
            resultMatrix.add(result);
        }
        return resultMatrix;
    }

Next step would be the creation of two methods...
  
    public List<List<Integer>> generateDemoValueMatrix() {
        final List<List<Integer>> result = new ArrayList<>();
        for(int anzahlKurven = 0; anzahlKurven <ANZAHL_KURVEN; anzahlKurven++){
            final List<Integer> demoValuesForY = generateDemoValuesForY();
            result.add(demoValuesForY);
        }
        return result;
    }
    public List<Integer> generateDemoValuesForY() {
        final Random random = new Random();
        final List<Integer> result = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            final int nextInt = random.nextInt(100);
            result.add(nextInt);
        }
        return result;
    }
Ok, look´s like always... booooring.... So I started with Streams..
    public List<List<Integer>> generateDemoValueMatrix() {
        return Stream
                .generate(this::generateDemoValuesForY)
                .limit(ANZAHL_KURVEN)
                .collect(Collectors.toList());
    }
    public List<Integer> generateDemoValuesForY(){
        final Random random = new Random();
        return Stream
                .generate(() -> {
                    return random.nextInt(100);
                })
                .limit(10)
                .collect(Collectors.toList());
    }
Not really better.. only new syntax.. now reducing the syntax..
    public List<List<Integer>> generateDemoValueMatrix() {
        return Stream
                .generate(this::generateDemoValuesForY)
                .limit(ANZAHL_KURVEN)
                .collect(Collectors.toList());
    }
    public List<Integer> generateDemoValuesForY(){
        final Random random = new Random();
        return Stream
                .generate(() -> random.nextInt(100))
                .limit(10)
                .collect(Collectors.toList());
    }

But Random offer something new.
    public List<List<Integer>> generateDemoValueMatrix() {
        return Stream
                .generate(this::generateDemoValuesForY)
                .limit(ANZAHL_KURVEN)
                .collect(Collectors.toList());
    }
    public List<Integer> generateDemoValuesForY(){
        return new Random()
                .ints(0, 100)
                .limit(10)
                .boxed()
                .collect(Collectors.toList());
    }
Combining both methods..
    public List<List<Integer>> generateDemoValueMatrix() {
        final Random random = new Random();
        return Stream.generate(
                    () -> Stream.generate(
                            () -> random.nextInt(100))
                            .limit(10)
                            .collect(Collectors.toList())
                )
                .limit(ANZAHL_KURVEN)
                .collect(Collectors.toList());
    }
OK, not short enough.. we could it better..
    public List<List<Integer>> generateDemoValueMatrix() {
        return Stream.generate(
                () -> new Random()
                        .ints(0, 100)
                        .limit(10)
                        .boxed()
                        .collect(Collectors.toList())
                ).limit(ANZAHL_KURVEN)
                .collect(Collectors.toList());
    }
Uuuppsss.. static imports possible.. ;-)
    public List<List<Integer>> generateDemoValueMatrix() {
        return generate(() -> new Random()
                .ints(0, 100)
                .limit(10).boxed().collect(toList())
        ).limit(ANZAHL_KURVEN).collect(toList());
    }
Now compare with the first and decide ;-) Streams are cool ? I think so!!

Lego Mindstorms EV3 Components: Infrared Sensor - Part 2

In this second part on the mindstorm's infrared sensor we will focus on the remote control and the ability of the remote sensor to recognize commands from that remote control respectively. There are multiple buttons on that remote control and we will control the robot by pressing different buttons.

The robot

We will use the robot from the first part as it already uses the infrared sensor. The mindstorm's remote control looks like the following:


There are two buttons on the left (red) and two buttons on the right (blue). There is a fifth button at the top center which is (in contrast to all other buttons) a toggling button. So if you press it one time, the remote control sends a signal continuously until the button is pressed a second time. Before taking the photo I pressed that button one time to activate the green signal led. We will use that toggle button on the next part of the infrared sensor articles.
The red slider at the bottom center is for selecting a frequency channel. You can select four channels and the current channel is shown in the red circle under the toggling button.

The parcours

There is the robot and there is the remote control. The aim is to press different buttons on the remote control to control and move the robot. We will use the two buttons on the left to let the robot rotate left/right, respectively the two buttons on the right to let the robot move forwards/backwards. When more than one button is pressed, the program should exit.


The infrared sensor API

There are two relevant modes for the infrared sensor. The distance mode and the seek mode. We used the former implicitly in the last article and we will use it in this one because it offers the possibility to receive commands from the infrared remote control. The latter can be used to receive the position and the distance of the remote control to the robot (the next tutorial will use the seek mode).

It's very easy to receive a command from the remote control. The only method we will use is infraredSensor.getRemoteCommand(0);
This will return an integer value which represents the pressed button on the remote control (e.g. the left upper button on the remote control will return 1). The parameter of the method is also an integer value which represents the frequency channel which we use on the remote control. You can select one of four different channels (via the red slider on the remote control). In this case we use channel 0 (which is called channel 1 on the remote control).

That's it. We don't need RangeFinderAdaptors, RangeFeatureDetectors or anything like that this time. So let's directly jump to the finished code and see how it works.

The code

There are two classes. The Main-class and an InfraredSignalCheckerThread, which extends Thread and contains the logic for received commands from the remote control.

Let's start with the Main-Class:

import lejos.hardware.Button;
import lejos.hardware.motor.Motor;
import lejos.hardware.port.SensorPort;
import lejos.hardware.sensor.EV3IRSensor;
import lejos.robotics.navigation.DifferentialPilot;

public class Main {

    protected final static double NINETY_DEGREES = 90.0;
    protected final static double PILOT_SPEED = 100.0;
    protected final static int PILOT_ACCELERATION = 500;
    protected final static double WHEEL_DIAMETER = 30.0f;
    protected final static double DISTANCE_BETWEEN_WHEELS = 170.0;

    public static void main(String[] args) throws InterruptedException {

        final DifferentialPilot pilot = new DifferentialPilot(WHEEL_DIAMETER, DISTANCE_BETWEEN_WHEELS, Motor.C, Motor.B);
        final EV3IRSensor infraredSensor = new EV3IRSensor(SensorPort.S2);
        final InfraredSignalCheckerThread checkerThread = new InfraredSignalCheckerThread(infraredSensor, pilot);

        configurePilot(pilot);
        checkerThread.start();
        Button.waitForAnyPress();
    }

    private static void configurePilot(final DifferentialPilot pilot) {
        pilot.setAcceleration(PILOT_ACCELERATION);
        pilot.setRotateSpeed(PILOT_SPEED);
        pilot.setTravelSpeed(PILOT_SPEED);
    }
}

If you've (hopefully) read our last article on the infrared sensor, you will recognize that the Main-class became a bit smaller this time. We don't have to configure anything on the infrared sensor.
First we create instances for the pilot and the infrared sensor again. The new thing is the InfraredSignalCheckerThread which extends Thread. This class contains all the logic for received commands. The logic is implemented in a Thread-extending class because we want to listen continuously for any received commands. The created instance of the InfraredSignalCheckerThread needs the infraredSensor-object of course and it needs the pilot (because we will control/move the robot corresponding to the pressed button on the remote control).

After we created the instances we configure the pilot and start the checkerThread. That's it. Let's have a look at the InfraredSignalCheckerThread-class now.

The InfraredSignalCheckerThread-class:

import lejos.hardware.sensor.EV3IRSensor;
import lejos.robotics.navigation.DifferentialPilot;

public class InfraredSignalCheckerThread extends Thread {

    private EV3IRSensor infraredSensor;
    private DifferentialPilot pilot;

    public InfraredSignalCheckerThread(final EV3IRSensor infraredSensor, final DifferentialPilot pilot){
        this.infraredSensor = infraredSensor;
        this.pilot = pilot;
    }

    @Override
    public void run() {
        while(true){
            final int remoteCommand = infraredSensor.getRemoteCommand(0);
            switch (remoteCommand){
                case 0:
                    pilot.quickStop();
                    break;
                case 1:
                    pilot.rotateLeft();
                    break;
                case 2:
                    pilot.rotateRight();
                    break;
                case 3:
                    pilot.forward();
                    break;
                case 4:
                    pilot.backward();
                    break;
                default:
                    System.out.println("button combination pressed..exiting...");
                    System.exit(0);
            }
        }
    }
}

Let's have a look at the run-method. As you can see we have an infinite loop. In that loop we get an integer command from the method infraredSensor.getRemoteCommand(0). The given parameter (0) means that the infrared sensor should listen at frequency channel 0 (remember the red slider on the remote control for selecting a channel).
So now the thread is checking for any commands on channel 0 continuously. As next we check which command was sent. The different buttons send different integer values. Here is the documentation from within the EV3IRSensor-class:

/** The button values are:
* 1 TOP-LEFT
* 2 BOTTOM-LEFT
* 3 TOP-RIGHT
* 4 BOTTOM-RIGHT
* 5 TOP-LEFT + TOP-RIGHT
* 6 TOP-LEFT + BOTTOM-RIGHT
* 7 BOTTOM-LEFT + TOP-RIGHT
* 8 BOTTOM-LEFT + BOTTOM-RIGHT
* 9 CENTRE/BEACON
* 10 BOTTOM-LEFT + TOP-LEFT
* 11 TOP-RIGHT + BOTTOM-RIGHT
* (0 means no buttons pressed)
*/

So, as you can see if no button is pressed on the remote control the method will return 0. The four buttons we want to use return 1, 2, 3 and 4.
Knowing these return values the switch statement becomes very easy to understand. If no button is pressed the robot shouldn't move. If the top left button is pressed the robot should rotate to the left and so on, we just call the corresponding methods of the DifferentialPilot-class to control the motors. If more than one button is pressed at a time the program should exit.

The result

And here is the result (watch on youtube for better quality):



Some words on complications that I had while writing the program: After starting the CheckerThread I had to wait around 30 seconds before pressing a button on the remote control. I have no explaination for that but when I pressed any button earlier the robot moved very jerkily. I tried different workarounds like Thread.sleep() and Delay.ms() in the main-method and the checker-thread. I also tried a timer in the CheckerThread which printed a message on the console to tell the user that the program isn't yet ready if he tried to press any button during those first 30 seconds. But none of these attempts worked.