summaryrefslogtreecommitdiffstats
path: root/src/vpp-api/java/jvpp/gen
AgeCommit message (Collapse)AuthorFilesLines
2018-06-22jvpp: cleanup JNI generation code (VPP-1153)Marek Gradzki3-168/+286
Minor cleanup that includes unifying common Java to C and C to Java translation code. Change-Id: I14d63dbe06334c3bbfbde75043de04d2c08f3dfd Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2018-06-21jvpp: do not fail on type parsing errorMarek Gradzki1-5/+8
skip the type instead. Change-Id: I533c8e13c1b2d05c1ddc6dc36427bac010d7c19a Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2018-03-02jvpp: object model for jvpp generator (VPP-1184)Marek Gradzki19-2341/+2267
Introduces JSON parser which builds object model of Java API. Also rewrites JNI translation of typedefs to use per type translation functions instead of code inlining. Not covered: - integrate with vappigen plugin (VPP-1154) or vapi parser (VPP-1155) - use better templating engine (VPP-480) - improvements of generator structure (e.g. VPP-1186) Change-Id: I9e12d76c2f3c6ee041669f58e8a37917f656aa90 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2018-01-27jvpp: map VPP API enums to primitive typesMarek Gradzki2-3/+76
Adding enum support (VPP-1153) requires JVPP generator refactoring (see: VPP-1154, VPP-1155, VPP-480) As a workaround we just update all the mappings used for VPP API definitions to JAVA and C/JNI translation. Change-Id: I9dff83e5199039a1a46a3d4685ce57cdeeeb2014 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2018-01-27jvpp: use Python's logging APIMarek Gradzki9-32/+59
Change-Id: Iec437e4672af1f0d1a24458afb977ba6fbeba4ed Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-12-09jvpp: include all api files from @top_builddir@/vppMarek Gradzki1-5/+0
Currently: - vpe.api (supported previously) - stats.api - oam.api Change-Id: Iab48d5d142e9a1ea0a4f366352b1d9429cc47309 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-12-09jvpp: do not hardcode event sufixes (VPP-940)Marek Gradzki7-141/+175
JVpp maps request messages with replies for Java API user convenience, e.g.: - do not polute send APIs with messages other than requests/dumps, - allow callback registration only for replies/details and events. Since there are no conventions for event message naming (https://wiki.fd.io/view/VPP/API_Concepts#API_Conventions), jvpp should not limit events to messages that end with 'event' or 'counters' suffix. Instead jvpp should treat all messages except for requests/dumps as potential events. Such behaviour was introduced on Java API level by https://gerrit.fd.io/r/#/c/8377/ in order support reusing details messages as events (e.g. BFD events). This patch goes one step forward by relaxing rules at jvpp generation level. Change-Id: I2a35e9eb2a288b2cf02d36ca95e6cb13e76e19e3 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-12-07jvpp: unify notification handlingMarek Gradzki3-23/+7
Since introduction of dedicated SW Interface Event, there is no need for special handling of messages that can be both requests and events. Change-Id: I76575e32c6d5b19e9a1ca953e5841d8ac3de4de7 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-12-07jvpp: remove special request<>reply mappingsMarek Gradzki10-102/+28
Since L2FibTable removal and introduction of dedicated SW Interface Event, special message handling code can be removed. The patch also fixes issues found by Intelij's code inspection tool. Change-Id: Ic4b2fd12ac30c7627f4cd6769716e4bb52ec0b10 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-10-30jvpp: bugfix for deadlock in java future API (VPP-1037)Matej1-22/+38
- message sending method inside synchronization blocks causes deadlock between sending and receiving part - breaking atomicity of sending message and putting future with corresponding id to map needs additional handling by writer and receiver, regardless which part get access to sync block first will create new future and second one will complete it and remove from map, in case of dump calls where control ping reply is required as confirmation that all information were send, if ping reply is received before writer put future in map, reader will create regular control ping future instead and writer needs to made association between these two futures Change-Id: Id29a19be7a5319291a5e07cf931080610178f00c Signed-off-by: Matej <matej.perina@pantheon.tech>
2017-10-10jvpp: adding callbacks for all messages (VPP-914)Matej Perina8-87/+112
1) In the previous version callbacks were generated based on request-replay naming conventions. It turned out they were too strict in case of events (e.g. BFD sends Details messages as notifications). So now we generate callback for all messages, allowing to receive any message as notification.(callback_gen.py) 2) "notification" suffix is no longer added because all messages are treated same (dto_gen.py, jvpp_c_gen_.py) 3) name of property that holds notification/events changed in callback facade and future apis 4) JVppNotification.java is no longer used since all events are treated equally Change-Id: I13f6438affc3473040d63cd4acb3984d03e97482 Signed-off-by: Matej <matej.perina@pantheon.tech>
2017-10-03jvpp: added logs for sending and receiving event messages (VPP-982)Matej Perina5-0/+30
Change-Id: I47f9d12d934378f18c6f841b902af2a64ee7b187 Signed-off-by: Matej Perina <mperina@cisco.com>
2017-08-24jvpp: use (*env)->ExceptionClear before calling (*env)->ExceptionOccurredMarek Gradzki1-1/+4
Change-Id: I6cca455ead986cb8a507c84957a97a40b733b16c Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-08-16jvpp: suppress unwritten fields warrning found in DTO's hashCodeMarek Gradzki1-0/+2
DTOs fields are initialized by generated JNI code, so we can safely ignore FB.UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD. Coverity uses FindBugs to analyse Java code, so it should be possible to suppress some of the issues that are false positives or intentional. Change-Id: I1375f6123e3eb44db44065d603d9d81726161acb Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-08-16jvpp: move JVppReply's id out of synchronized blockMarek Gradzki2-15/+17
Should make Coverity stop thinking we try to synchronize reply.context. Change-Id: I97169e46b9c8f594836d6beb75b9f42dfc6e5bad Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-08-14jvpp: ignore messages if callback method is missing (VPP-548)Marek Gradzki1-0/+8
Change-Id: I6a06dbcd8339bd6645a6b02ae70154aa0885dcf8 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-08-11Dedicated SW Interface EventNeale Ranns1-2/+1
Change-Id: I06a10a4291e61aec3f1396d2514ed6fe3901897a Signed-off-by: Neale Ranns <neale.ranns@cisco.com> Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-05-30Flowprobe: Stateful flows and IPv6, L4 recordingOle Troan1-1/+1
Change-Id: I67839281623721bf42f0a918a53356143d9dc78a Signed-off-by: Ole Troan <ot@cisco.com> Signed-off-by: Pavel Kotucek <pkotucek@cisco.com> Signed-off-by: Ole Troan <ot@cisco.com>
2017-05-26Improve jvppgen object array member instantiationRobert Varga1-1/+1
Since all objects of the array have the same type, the object constructor is a loop invariant. Move the lookup out of the loop, making things faster. Change-Id: I631c72b59c6c63eccd49ede41c6dc0541c325db9 Signed-off-by: Robert Varga <robert.varga@pantheon.tech> Signed-off-by: Robert Varga <nite@hq.sk>
2017-05-26Fix JNI templatesRobert Varga1-0/+3
The JNI templates around array and object handling are wrong in the sense that they fail to delete local references for objects which have been assigned to fields/arrays. Fix this by invoking DeleteLocalRef. Change-Id: I1c31d81f4235d821ccd51c96be7b176f64284928 Signed-off-by: Robert Varga <robert.varga@pantheon.tech> Signed-off-by: Robert Varga <nite@hq.sk>
2017-05-20API: Cleaning up message naming that does not follow the conventionsOle Troan1-8/+1
is_address_reachable - Disabled so deleted cli_request - Renamed to cli vnet_summary_stats_reply - Renamed to vnet_get_summary_stats_reply bridge_domain_sw_if_details - Deleted, incorporated in main message l2_fib_table_entry - Renamed to l2_fib_table_details Change-Id: I93b7e8769a3ba7b4989b3c270270f575f386464f Signed-off-by: Ole Troan <ot@cisco.com> Signed-off-by: Marek Gradzki <mgradzki@cisco.com> Signed-off-by: Ole Troan <ot@cisco.com>
2017-05-15jvpp: fix memory allocation for variable lenght messages (VPP-841)Marek Gradzki4-22/+49
Change-Id: I9a46125e3cf9815c08cf8cca17713ec6e9121eae Signed-off-by: Marek Gradzki <mgradzki@cisco.com> (cherry picked from commit 307cfd8eb14ff7df04316ffa56f2c2481d650d7e)
2017-01-27jvpp: utilize per-message CRCs (VPP-544)Marek Gradzki2-4/+29
Since messages ids are no longer statically referenced, fixes also VPP-611. Change-Id: Ic8e6ee2b7f1142c185595347984d69350be25ac3 Signed-off-by: Marek Gradzki <mgradzki@cisco.com>
2017-01-01Move java,lua api and remaining plugins to src/Damjan Marion12-0/+2756
Change-Id: I1c3b87e886603678368428ae56a6bd3327cbc90d Signed-off-by: Damjan Marion <damarion@cisco.com>