openliberty / yoko

Yoko ORB used by OpenLiberty, derived from Apache Geronimo

The Yoko ORB

Yoko is a CORBA 2.3 compliant ORB implementation to support interprocess communication. It is an open-source project maintained by IBM, forked from Apache Yoko.

Build Requirements

1. SDKMAN, to manage the toolchain, including installing Java, Gradle

Steps to build Yoko

1. From the root of the project, run sdkman env install to obtain the toolchain. (one-time step)
2. Run sdk env to initialise the environment.
3. Run gradle build to build and test Yoko.

Testify

Testify is an open-source generic framework used for testing with Junit 5 across multiple threads and forked processes.

Docs

The documentation for Testify can be found at https://openliberty.github.io/yoko

yoko's Issues

Ensure legal information is correct for testibus

Add/Update dependencies to all other yoko modules

Trace to yoko.verbose.retry=FINEST: stack traces at decision points

Decide on Docs Framework

Requirements for this include:

• Must use ACSII
• Have Versioning

Trace to yoko.verbose.retry=FINE: decision points

Trace to yoko.verbose.giop=FINER: parsed header

Trace to yoko.verbose.marshal=CONFIG: marshalling settings?

Trace to yoko.verbose.retry=FINER: endpoint info?

Testibus Module

As a

developer

I want to

add Testibus to my project dependencies

so that

my project will pull binaries and compile against them

• move testify packages to io.openliberty.testibus
• add dependencies to other yoko modules
• add succinct README
• ensure license information present in built jar
• check copyright
• release engineering
• sign and seal built jars
• upload (e.g. to maven central)

add tests for existing function

Use reference counting

Yoko needs more reference counting.

Trace to yoko.verbose.oa=FINEST: other poa operations

Check stream size

Decide on Docs Framework

Trace to yoko.verbose.connection=FINEST: request count / in-flight request counts

Trace to yoko.verbose.request=CONFIG: client/server request interceptors addition

Trace to yoko.verbose.request=FINER: object key, service contexts

Add Diagrams For the docs

A start for this has been made here

Trace to yoko.verbose.oa=CONFIG: poa manager creation, poa creation (with policies)

Convert all existing main() methods in the framework into actual tests

Build the coverage reports using Github actions and add them to the Testibus framework code

Trace to yoko.verbose.ior=CONFIG: IOR Interceptor addition

Fields declared as non-serializable classes should be marshalled as abstract values

Historically fields of non-serializable class types have been marshalled as abstract interfaces, which has caused interoperability issues with other Java ORBs.

The OMG Java-to-IDL 1.4 specification in section 4.3.11 specifies that they should be marshalled as abstract values. This means that no discriminator octet is required before the value itself is marshalled.

Move the tests that test the test framework into the new module

Trace to yoko.verbose.oa=FINER: object activation

Testibus User Guide

As a

developer

I want to

read the User Guide

so that

I can understand how to use Testibus

• Decide on and create infrastructure for docs
• Describe the bus concept as used in Testibus
• Describe how to use the bus across threads, and across (sub) processes
• Describe how to make the framework more verbose
• Describe how to enable j.u.l logging per-test / per-testcase
• Describe how to extend annotations

Trace to yoko.verbose.marshal=FINER: version mismatches

copySystemException() may have incorrect logic

This method sets the cause as the original exception so there will always be a duplicated exception in the exception chain.
The call chain regarding completion status is confusing and may misreport the completion status.
This method may be unnecessarily defensive — consider just using the original system exception or upgrading the copySystemException() method to produce a closer replica of the original.

Trace to yoko.verbose.connection=CONFIG: ORB connection timeouts etc

Trace to yoko.verbose.retry=CONFIG: retry count, hop count, etc.

Trace to yoko.verbose.giop=FINEST: complete packet (hex / no ascii / no ebcdic)

Trace to yoko.verbose.request=FINEST: negotiated contexts

Trace to yoko.verbose.connection=FINER: connection level negotiation — code sets, codebase, YASF

Create CI pipelines using Github actions to build and test automatically on PRs to the testibus main

Build docs on how to use the CI pipelines (if necessary)

Move testibus packages to new module in Yoko called Yoko-Testibus

Present our Project at the Hub - Thursday, 13th October

11 - 12

Need to get more information about this event:

• What do we need to bring to this presentation (do we have a table? do we need to bring visuals?)
• How can we make our project digestible and enjoyable? (visuals)

Trace to yoko.verbose.marshal=FINE: value types / nesting levels

Decide on Docs Framework

Create Docs Skeleton - Ready for updates when they come

When Docs framework chosen, create a skeleton using said framework, ready to add information to it as we gain said knowledge

Trace to yoko.verbose.connection=FINE: open / close / accept connection to endpoint

Testibus Unit Testing

As a*

Developer

I want to

run, examine, and extend the existing unit tests

so that

I can do agile development

• move the (very few) tests that test the test framework into the new module
• convert existing main() methods in the framework into actual tests
• add tests for existing function

Trace to yoko.verbose.types=FINE: type lookup (local and remote)

Trace to yoko.verbose.giop=CONFIG: GIOP settings?

Add succinct README to the new Testibus module

Trace to yoko.verbose.giop=FINE: conversation (endpoints plus packet types and sizes)

Trace to yoko.verbose.marshal=FINEST: every read call ever (i.e. current tracing, ported to the verbose loggers)

Trace to yoko.verbose.oa=FINE: poa manager activation, poa manager state changes

Trace to yoko.verbose.types=FINEST: full type listing

Testibus CI

As a

contributor

I want to

get test results for my pull requests

so that

I have confidence my code changes are good

• Build and test automatically on PRs to relevant branch (currently testibus-main)
• Build docs (if necessary)
• Add coverage reports for Testibus framework code