[Fiware-middleware] Current status

Dmitri Rubinstein Dmitri.Rubinstein at dfki.de
Thu Jan 8 10:00:48 CET 2015


Hi Christof,

On 01/08/15 09:13, Marti Christof (mach) wrote:
> Hi Dimitri
>
>  From a developer point of view, what option do I have to return, that no value is found?
> - Exception (not supported at the moment)

IMO this is a correct way.

> - null value (very common in Java, but fails at the moment)

Structs can't be null, this is violation of the contract in the IDL.

> - special ErrorObject or error states (very uncommon in Java. Requires change of interface or definition of a dummy ExchangeRate object)

What really happens here is that implementation on the server is 
incorrect in terms of the IDL contract. So server should return internal 
server error response, which we don't support as well.

>
> To my knowledge CDR is supporting NULL values. Corba did not allow this because of the pass by value principle.

CORBA supports null for interfaces and valuetypes, also see here:

https://community.oracle.com/thread/1694972?start=0&tstart=0

And we do not support any of them.

> I think it is very limiting if we do not support NULL/NIL values in KIARA.

IMO this is a question of IDL contract. When IDL specifies

ExchangeRate lookup(string from, string to);

developer expects that server will always return ExchangeRate. When you 
would like to say that lookup can also return null I would define 
something like this:

optional<ExchangeRate> lookup(string from, string to);

meaning that either you get ExchangeRate value or null. This also allows 
to generate serialization/deserialization code that takes care of null.

But I would prefer that we implement exceptions first.

Best,

Dmitri

>
> BR
> Christof
>
>
>> On 07.01.2015, at 23:09, Dmitri Rubinstein <dmitri.rubinstein at dfki.de> wrote:
>>
>> Hi Christof,
>>
>> regarding the bug on the server side that you mention. I am not sure
>> that this is a bug when you mean operation:
>>
>> ExchangeRate lookup(string from, string to);
>>
>> ExchangeRate is not nullable so returning null is incorrect. I think
>> serialization and protocol that we use do not support this.
>>
>> Best,
>>
>> Dmitri
>>
>> On 07.01.2015 12:22, Marti Christof (mach) wrote:
>>> Happy new year everybody
>>>
>>> I hope you had a happy christmas and a good start of the new year.
>>> I spent a few nice days in the alps with my family (at my brothers house) and finally had the chance to enjoy some snow.
>>> The rest of the time I was mostly working on KIARA to catch up with some open work.
>>>
>>> Already before the vacation I started to create a demo application to be used in the user manual.
>>> Writing the manual without this or with a too simple example was pointless.
>>> - https://github.com/christofmarti/KiaraCurrencyConverter
>>> (It makes sense to transfer it to the Github FIWARE Middleware organisation, but I have no rights to do so)
>>> The build.gradle file also contains tasks to run server and client and to build runnable jars.
>>>
>>> The example app shows also a bug in the current KIARA implementation. It throws a NPE on the server side, when a function returns a null value.
>>> The idea is also to extend the example app with additional features (annotations, exceptions, etc) as soon they are available.
>>>
>>> The example app is using the kiaragen-gradle-plugin I had to write, to make the process for the developer as easy as possible.
>>> - https://github.com/christofmarti/kiaragen-gradle-plugin (also should be transferd to FIWARE Middleware)
>>> Using this plugin, the generation of the support classes is as simple and automatic as possible.
>>> As soon the plugin is moved and the artefacts are pushed to maven-central we can register it in the gradle plugin catalog.
>>> One nice feature of the gradle plugin is, that the package of the generated classes is generated based on the relativ path of the IDL file to the idl source directory .
>>> e.g. src/main/idl/com/example/KiaraCurrencyConverter.idl will generate classes in package com.example (can be overridden, by setting an explicit javaPackage)
>>>
>>> Finally during the process I had to adopt kiaragen and some minor changes in IDLParser and KIARA.
>>> I made all the changes in the “deploytools” branch of each project.
>>> - https://github.com/FIWARE-Middleware/kiaragen/tree/deploytools
>>> - https://github.com/FIWARE-Middleware/IDL-Parser/tree/deploytools
>>> - https://github.com/FIWARE-Middleware/KIARA/tree/deploytools
>>>
>>> To run the demo application you have to do a "gradle install" of IDLParser, kiaragen and KIARA in the “deploytools" branch (+ gradle install of the gradle-plugin)
>>> This is deploying the jars to the local maven repo, where they are picked up if required. This is not required, as soon we push the released versions to maven central.
>>> I did not merge them to the master branch yet, because I would like to let you first verify the changes.
>>>
>>> To make the kiaragen-gradle-plugin work I had to modify quite some code in kiaragen. Not so much in the main generate process, but in parsing and handling the command line parameters and also how some of the parameters work.
>>> For the parsing the command line parameters I am using commons-cli, which makes code to set up and parse options much more readable.
>>> The ‘example' option is now only a binary flag declaring, that the server, client, gradle examples should be generated. If missing only the support classes are generated. To declare different variants I added the platform option (current possible values ‘java’ [default] and ‘gradle’ which also generates the build.gradle example files)
>>> All the parsing is now in the main method and the Kiaragen class has getters and setters to access the options. Whit this it can now also be used from other java classes (e.g. the kiaragen-gradle-plugin)
>>> Additionally I added capsule (https://github.com/puniverse/capsule) using the capsule-gradle resp. capsule-maven plugin to build the runnable jars.
>>> All the changes are commented in the commit messages.
>>>
>>> Finally (this week) I continued to update and complete the user manual integrating the example app, gradle-plugin, etc.
>>> https://docs.google.com/document/d/17RmZZlJf78IEJOLxiiSHBND1zqD6jr9kuWT947f_1ms/edit#
>>> The basic structure of the user manual is now also much clearer:
>>> 1. Intro
>>> 2. Description of the Example App and basic steps (quick example)
>>> 3. Setting up the dev environment
>>> 4. Building a KIARA RPC application
>>>    (Explaining the steps in detail using the most common options)
>>> 5. KIARA RPC Application Programmer Interface
>>>    (Explaining the concepts and the API in detail. Less formal version of the API specification)
>>> 6. KIARA Interface Definition Language
>>>    (Explaining the syntax and options of the IDL files and the type mappings.
>>>    Basically a less formal version of the API specification)
>>>
>>> Im am currently updating and extending chapter 3 and 4 (for which I basically needed all the above preparations)
>>> The idea of Chapter 5 and 6 are basically Developer friendly extracts and explanations from the specification using the above example to explain some additional features.
>>>
>>> Open actions:
>>> - validate changes in the “deploytools” branch (epros, dfki)
>>> - merge deploytools to main (master) branch in kiragen, IDLparser, KIARA
>>> - fix the “bug” throwing NPEs when functions are returning null values
>>> - move kiaragen-gradle-plugin and KiaraCurrencyConverter to FIWARE Middleware oranization
>>>   (Github lets me transfer repos to an organization, but I would need create rights)
>>> - make repos public
>>> - push artefacts to maven-central (Instructions in KIARA/Contribute.md)
>>>   (I have the account and can do it if OK.)
>>> - register kiaragen-gradle-plugin on plugins.gradle.org
>>> - review the install manual (https://docs.google.com/document/d/1mjJkvFAydgh_yjeQ7hP8rpxMxdBvtNaHY1RX54ZH3_M/edit#)
>>> - complete the user manual
>>>
>>> !! Unfortunately I am out of office from today until Saturday. I can react sporadically on emails and work some time in the evenings, but not during the day.
>>>
>>> Best regards
>>> Christof
>>> ----
>>> InIT Cloud Computing Lab - ICCLab http://blog.zhaw.ch/icclab
>>> Institut of Applied Information Technology - InIT
>>> Zurich University of Applied Sciences - ZHAW
>>> School of Engineering
>>> Phone: +41 58 934 70 63
>>> Skype: christof-marti
>>>
>>>
>>>
>>> _______________________________________________
>>> Fiware-middleware mailing list
>>> Fiware-middleware at lists.fi-ware.org
>>> https://lists.fi-ware.org/listinfo/fiware-middleware
>>>
>>
>> _______________________________________________
>> Fiware-middleware mailing list
>> Fiware-middleware at lists.fi-ware.org
>> https://lists.fi-ware.org/listinfo/fiware-middleware
>




More information about the Fiware-middleware mailing list

You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy   Cookies policy