Difference between revisions of "VPP/Java API/Plugin support"

From fd.io
< VPP‎ | Java API
Jump to: navigation, search
m
(→‎Problems needs to be solved)
 
(2 intermediate revisions by the same user not shown)
Line 9: Line 9:
 
* JVppRegistry holds a map of callback interfaces for JVppCore and plugins (generated together with JNI implementations based on provided api files).
 
* JVppRegistry holds a map of callback interfaces for JVppCore and plugins (generated together with JNI implementations based on provided api files).
  
−
* when API user sends a message, JVppRegistry delegates the call to JNI implementation provided by the particular plugin.
+
* when API user sends a message, JVppRegistry delegates the call to JNI implementation provided by the particular plugin
  
 
* when JNI code receives reply, it asks the registry for appropriate callback interface and invokes callback method that corresponds to the received message reply
 
* when JNI code receives reply, it asks the registry for appropriate callback interface and invokes callback method that corresponds to the received message reply
  
−
== Problems needs to be solved ==
+
== TODO ==
  
−
* check if single connection can be used (solve linking and shared memory issues) - prototype in progress
+
* util.py stores workarounds for messages that are not following vpe.api naming conventions. It needs to be extensible, just in case vpp plugins have their own peculiarities
−
* provide FutureJVppFacade and CallbackJVppFacade for all plugins (prototype in progress)
+
* test jvpp_gen package installation on centos7
−
* util.py that stores workarounds for messages that are not following vpe.api naming conventions needs to be extensible, just in case vpp plugins have their own peculiarities
+
−
* Java binding generator for plugins should be easily referenced during plugin build (ideally new fd.io project).
+

Latest revision as of 15:00, 16 August 2016

This page is a design proposal for Java API to support VPP plugins.

Architecture

http://yuml.me/edit/cf23df5c

Main assumptions

  • JVppRegistry holds a map of callback interfaces for JVppCore and plugins (generated together with JNI implementations based on provided api files).
  • when API user sends a message, JVppRegistry delegates the call to JNI implementation provided by the particular plugin
  • when JNI code receives reply, it asks the registry for appropriate callback interface and invokes callback method that corresponds to the received message reply

TODO

  • util.py stores workarounds for messages that are not following vpe.api naming conventions. It needs to be extensible, just in case vpp plugins have their own peculiarities
  • test jvpp_gen package installation on centos7
Retrieved from "https://wiki.fd.io/index.php?title=VPP/Java_API/Plugin_support&oldid=2512"