vlingo / xoom-schemata Goto Github PK

The VLINGO XOOM Schema Registry.

License: Mozilla Public License 2.0

Java 86.95% ANTLR 0.73% Dockerfile 0.07% JavaScript 3.59% HTML 0.62% Shell 0.02% Svelte 7.67% CSS 0.10% SCSS 0.03% FreeMarker 0.23%

commands data envelope events jvm messaging schema schema-registry semantic-versioning vlingo vlingo-schemata

xoom-schemata's People

Contributors

Stargazers

Watchers

Forkers

wwerner bwehrle luteceo pflueras stevepavlin itsmoonrack yuer2016 kgtyflz6 isabella232

xoom-schemata's Issues

[UI] Add E2E test for loading source code

Schema versions w/o specification can be created using the HTTP API, but are not returned when querying

When POSTing a schema version like this

POST http://localhost:9019/organizations/{{orgId}}/units/{{unitId}}/contexts/{{contextId}}/schemas/{{schemaId}}/versions
Content-Type: application/json

{
  "organizationId": "{{orgId}}",
  "unitId": "{{unitId}}",
  "contextId": "{{contextId}}",
  "schemaId": "{{schemaId}}",
  "schemaVersionId": "",
  "description": "Initial revision.",
  "status": "Published",
  "previousVersion": "0.0.0",
  "currentVersion": "1.0.0"
}

The server returns 201 Created.
However, when querying afterwards, no versions are returned.

### Schema Versions of Schema
GET http://localhost:9019/organizations/{{orgId}}/units/{{unitId}}/contexts/{{contextId}}/schemas/{{schemaId}}/versions
Accept: application/json

The API calls can be found in rest-api-calls.http

[Compiler] Requesting Schema Source Code

The following GET will crash in the compiler.

curl -i -X GET -H "Accept: application/json" http://localhost:9019/code/{reference}/{language}

Concrete example:

Create each of Org:Unit:Context:Schema:Version
Query for the source code
Exception

E.g. /code/vlingo:PlatformDevelopment:io.vlingo.schemata:SchemaDefined:1.0.0/java

This is due to two problems:

The compiler is unfinished reimplementation from synchronous to asynchronous
There is no dependency resolver implementation; if one SchemaVersion has a dependency on another named SchemaVersion there is no way to resolve that dependency type.
There is only an in-memory "mock" resolver: CacheTypeResolver

[UI] Improve field validation

Currently, the only validation is that the Create button is only enabled if all fields are filled.

Vuetify has nice helpers for validation: https://vuetifyjs.com/en/components/forms

We can use it to e.g. check for syntactically valid version numbers and illegal chars in names, so the user has faster and more helpful feedback and the server isn't bothered to try things we already know to be invalid on the client.

Use Postgres Journal for Event Sourcing

Set up the Postgres Journal for Event Sourcing
Test that Postgres Journal writes and reads for vlingo/schemata

Validation errors on schema creation are not returned over HTTP

When creating a new Schema Version w/ incompatible previousVersion and currentVersion, an exception is thrown on the server but the HTTP request does not finish and report the error. The request times out eventually.

Example request (assuming Organization, Unit, Context and Schema exist):

POST http://localhost:9019/organizations/{{orgId}}/units/{{unitId}}/contexts/{{contextId}}/schemas/{{schemaId}}/versions
Content-Type: application/json

{
  "organizationId": "{{orgId}}",
  "unitId": "{{unitId}}",
  "contextId": "{{contextId}}",
  "schemaId": "{{schemaId}}",
  "schemaVersionId": "",
  "description": "Initial revision.",
  "specification": "event SchemaDefined { type eventType }",
  "status": "Published",
  "previousVersion": "1.0.1",
  "currentVersion": "1.0.0"
}

Exception on the server:

11:17:42.520 [pool-2-thread-12] ERROR io.vlingo.actors.Logger - Exception thrown by Resource execution
java.lang.IllegalArgumentException: Versions are incompatible: previous: 1.0.1 next: 1.0.0
	at io.vlingo.schemata.model.SchemaVersion.with(SchemaVersion.java:48) ~[classes/:na]
	at io.vlingo.schemata.model.SchemaVersion.with(SchemaVersion.java:33) ~[classes/:na]
	at io.vlingo.schemata.resource.SchemaVersionResource.defineWith(SchemaVersionResource.java:58) ~[classes/:na]
	at io.vlingo.http.resource.RequestHandler5.lambda$null$2(RequestHandler5.java:83) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.RequestExecutor.executeRequest(RequestExecutor.java:23) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.RequestHandler5.lambda$handle$3(RequestHandler5.java:83) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.RequestHandler5.lambda$execute$6(RequestHandler5.java:112) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.RequestExecutor.executeRequest(RequestExecutor.java:23) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.RequestHandler5.lambda$execute$7(RequestHandler5.java:113) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.RequestHandler.runParamExecutor(RequestHandler.java:55) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.RequestHandler5.execute(RequestHandler5.java:113) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.DynamicResource.lambda$dispatchToHandlerWith$0(DynamicResource.java:44) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.ResourceRequestHandlerActor.handleFor(ResourceRequestHandlerActor.java:28) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.http.resource.ResourceRequestHandler__Proxy.lambda$handleFor$0(ResourceRequestHandler__Proxy.java:32) ~[vlingo-http-0.8.9.jar:na]
	at io.vlingo.actors.LocalMessage.internalDeliver(LocalMessage.java:115) ~[vlingo-actors-0.8.9.jar:na]
	at io.vlingo.actors.LocalMessage.deliver(LocalMessage.java:47) ~[vlingo-actors-0.8.9.jar:na]
	at io.vlingo.actors.plugin.mailbox.concurrentqueue.ConcurrentQueueMailbox.run(ConcurrentQueueMailbox.java:101) ~[vlingo-actors-0.8.9.jar:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_212]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_212]
	at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_212]

[UI] Need Favicon

Use the vlingo logo for favicon.

https://vlingo.io/wp-content/uploads/vlingo-favicon.png

[Compiler] Implement the TypeResolver interface in SchemaVersionQueriesActor to resolve types

Right now the io.vlingo.schemata.query.SchemaVersionQueriesActor#resolve method is not fully implemented because it doesn't resolve correctly a type based on it's full qualified name.

We need to create a new query that will find the IDs:

organizationId
unitId
contextId
schemaId

based on their names, so the type can be resolved in the TBL_SCHEMAVERSIONS table.

Requests to update schema version description are handled by UnitCommands instead of SchemaVersionCommands

For updates to the schema version's description, an Exception is thrown:

08:33:28.235 [pool-2-thread-7] ERROR io.vlingo.actors.Logger - Default before resume recovery after: Invalid UUID string: 6ffcb30e-53c1-4ca7-8164-476fbc4e7da6/contexts/f4f8795d-6647-474b-8daf-a3250e83bbba/schemas/2e561b9b-7eb5-4ac6-819d-cec3bc56885f/versions/8b51a3e0-a4f6-4dbc-9080-b5e9bdff78f2
java.lang.IllegalArgumentException: Invalid UUID string: 6ffcb30e-53c1-4ca7-8164-476fbc4e7da6/contexts/f4f8795d-6647-474b-8daf-a3250e83bbba/schemas/2e561b9b-7eb5-4ac6-819d-cec3bc56885f/versions/8b51a3e0-a4f6-4dbc-9080-b5e9bdff78f2
	at java.util.UUID.fromString(UUID.java:194) ~[na:1.8.0_212]
	at io.vlingo.lattice.grid.GridAddressFactory.from(GridAddressFactory.java:45) ~[classes/:na]
	at io.vlingo.lattice.router.RoutableCommand.handleWithin(RoutableCommand.java:191) ~[classes/:na]
	at io.vlingo.lattice.router.CommandRouterWorkerActor.route(CommandRouterWorkerActor.java:32) ~[classes/:na]
	at io.vlingo.lattice.router.CommandRouter__Proxy.lambda$route$0(CommandRouter__Proxy.java:32) ~[classes/:na]
	at io.vlingo.actors.LocalMessage.internalDeliver(LocalMessage.java:115) ~[classes/:na]
	at io.vlingo.actors.LocalMessage.deliver(LocalMessage.java:47) ~[classes/:na]
	at io.vlingo.actors.plugin.mailbox.concurrentqueue.ConcurrentQueueMailbox.run(ConcurrentQueueMailbox.java:101) ~[classes/:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_212]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_212]
	at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_212]

It seems that instead of describeAs in SchemaVersionCommands, the command of the same name in UnitCommands is called. I currently can't see where this comes from.

To reproduce, create an org/unit/context/schema/schemaVersion and request the following:

PATCH http://localhost:9019/organizations/{{orgId}}/units/{{unitId}}/contexts/{{contextId}}/schemas/{{schemaId}}/versions/{{schemaVersionId}}/description
Content-Type: application/json

with a body of updated description.

Note that the content type needs to be application/json instead of text/plain, see vlingo/xoom-http#49

The analogue to update a schema version specification works as expected:

PATCH http://localhost:9019/organizations/{{orgId}}/units/{{unitId}}/contexts/{{contextId}}/schemas/{{schemaId}}/versions/{{schemaVersionId}}/specification
Content-Type: application/json

updated spec

Interesting to note that it calls a command of the same name but in a different class. The handler does reference the correct command in SchemaVersion commands.

[API] Handle invalid schema version state transitions

Currently, when executing an invalid schema version state transition via the API, the request returns 200 but does not execute the transition.

To reproduce, PATCH a body of Published against /organizations/<O>/units/<U>/contexts/<C>/schemas/<S>/versions/<V>/status of a version that is already deprecated or removed.

Compilation error in TypeDefinitionCompiler

Since 6ddcf3d#diff-ebfbce655b794498a2b1f38cf4dacb6cR68, we see an compilation error in TypeDefinitionCompiler:

... TypeDefinitionCompiler.java:[68,64] incompatible types: io.vlingo.schemata.query.SchemaVersionQueries cannot be converted to io.vlingo.schemata.codegen.processor.types.TypeResolver

This is b/c, while SchemaQueriesActor implements TypeResolver, SchemaQueries doesn't.

Server requires too much memory

After the recent updates to vlingo-wire (I suspect somewhere around vlingo/xoom-wire#13 and vlingo/xoom-wire@12f372d...10c9ded ), the server consumes roughly 4GB of memory. Trying to start the server w/ less memory leads to failures like in the exception below.
After giving the server 3.8G Xmx, startup works as expected.

This occured first in CircleCI b/c the server is killed by the system for consuming too much memory. After setting -Xmx to sth. below 3800m, the following exceptions are thrown.

java.lang.IllegalArgumentException: Actor instantiation failed because: ActorFactory failed actor creation for: Address[id=9223372036854775803, name=(none)]
	at io.vlingo.actors.Stage.createRawActor(Stage.java:659)
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448)
	at io.vlingo.actors.Stage.actorFor(Stage.java:143)
	at io.vlingo.http.resource.Server.startWith(Server.java:111)
	at io.vlingo.http.resource.Server.startWith(Server.java:81)
	at io.vlingo.http.resource.Server.startWith(Server.java:60)
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:68)
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87)
	at io.vlingo.schemata.Bootstrap.main(Bootstrap.java:96)
Caused by: java.lang.InstantiationException: ActorFactory failed actor creation for: Address[id=9223372036854775803, name=(none)]
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:139)
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75)
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656)
	... 8 more
Exception in thread "main" java.lang.NullPointerException
	at io.vlingo.actors.Stage.actorFor(Stage.java:152)
	at io.vlingo.http.resource.Server.startWith(Server.java:111)
	at io.vlingo.http.resource.Server.startWith(Server.java:81)
	at io.vlingo.http.resource.Server.startWith(Server.java:60)
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:68)
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87)
	at io.vlingo.schemata.Bootstrap.main(Bootstrap.java:96)

[UI] Reduce number of backend requests from the UI (SUGGESTION: Forecast-based, not empirically confirmed)

Currently, most things the UI requires are queried from the backend each time they are required.

This includes:

Units
Contexts
Schemata and Schemata Versions
Valid Categories and Status

While this makes state management between client and server easier, it is more chatty then stricly required.

Since the payloads are rather small, this is not a big issue now, but we should probably discuss the trade-off between state management complexities and responsiveness of the UI and network load.

[UI] Requesting Schema Source Code

Generated sources should be visible and downloadable via the UI.

[UI] Show notification when a new entity was saved and lock the create button until a field changed

[Compiler] Add support for default values

Right now the compiler does not support default values for basic types. You can take a look at the syntax in #22.

How to implement

Add support for the new syntax to the lexer: src/main/antlr4/io/vlingo/schemata/codegen/antlr/SchemaVersionDefinitionLexer.g4
Add support for the new syntax to the parser: src/main/antlr4/io/vlingo/schemata/codegen/antlr/SchemaVersionDefinitionParser.g4
Add new Value nodes for the specific types of default values (if needed): io.vlingo.schemata.codegen.ast.values
Change the Java backend to compile them: io.vlingo.schemata.codegen.backend.java.JavaBackend

[UI] Allow for editing existing Org/Unit/Context

Implement editing UI -> #87
Make UI use *.redefineWith handlers

Failing tests after update to 0.9.1-RC2

Since the update to 0.9.1-RC2, most unit tests in schemata fail with the exception below.

It seems the Grid c'tor has been replaced by static factory methods in this version as of vlingo/xoom-lattice@d1de410 which is still used in actors.World: https://github.com/vlingo/vlingo-actors/blob/master/src/main/java/io/vlingo/actors/World.java#L430

java.lang.IllegalStateException: World cannot create new stage: vlingo-schemata-grid because: io.vlingo.lattice.grid.Grid.<init>(io.vlingo.actors.World, io.vlingo.actors.AddressFactory, java.lang.String)

	at io.vlingo.actors.World.stageNamed(World.java:439)
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:37)
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87)
	at io.vlingo.schemata.BootstrapTest.testThatBootstrapStartsServerCleanly(BootstrapTest.java:18)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.NoSuchMethodException: io.vlingo.lattice.grid.Grid.<init>(io.vlingo.actors.World, io.vlingo.actors.AddressFactory, java.lang.String)
	at java.lang.Class.getConstructor0(Class.java:3082)
	at java.lang.Class.getConstructor(Class.java:1825)
	at io.vlingo.actors.World.stageNamed(World.java:430)
	... 25 more

[Compiler] Add support for arrays

Right now, neither the ANTLR4 parser nor the code generator support array types. Array types can be from any other basic type, but there are two constraints:

Array types from other basic types (like int or char) can contain default values in the form of:

int[] array = {1, 2, 3}

Array types from other complex types (like other types already created through schemata) can not contain default values.

How to implement

Add support for the array syntax to the lexer: src/main/antlr4/io/vlingo/schemata/codegen/antlr/SchemaVersionDefinitionLexer.g4
Add support for the array syntax to the parser: src/main/antlr4/io/vlingo/schemata/codegen/antlr/SchemaVersionDefinitionParser.g4
Change the FieldDefinition for adding support to ararys: io.vlingo.schemata.codegen.ast.FieldDefinition
Change the JavaBackend to support arrays: io.vlingo.schemata.codegen.backend.java.JavaBackend

[UI] Nodes in the schema selection tree need to be clicked twice to open

If a node is opened in the schema treeview, the loading icon flashes and the data is loaded in the background.

However, the node is not expanded and you need to click again to open it.

[UI] Implement E2E Tests

Implement E2E tests using https://www.cypress.io

We should at least test the following

The tests should run against a containerized version of the application so we can easily run it in CI builds

Accessing non-existing resources just hangs

Accessing non-existing resources just hangs w/o sending HTTP 404 response code.
io.vlingo.symbio.store.StorageException exception is thrown containing the message: No object identified by expression.

Sanitize descriptions in code generator

Currently, both the editor and the display support markdown formatting.
As (I think) the description will be rendered into the generated code's comments, we need to make sure that this does not break the target syntax.

This is also true for arbitrary comments.

[Domain] Review semantic version validation rules

Currently, a schema version of maj.min+1.patch or maj+1.min.patch cannot be created if preceeded by maj.min.patch in status Draft. A version of maj.min.patch+1 can be created.

It is not entirely clear to me what the actual business rules encompassing previousVersion, currentVersion and status should be.

Backward and Forward Compatibility Checks Required

When adding a new SchemaVersion with a major version pre-existing on an earlier SchemaVersion, the new version specification must be backward compatible with the former, and the former forward compatible with the latter.

Example:

Existing: SchemaVersion (1.0.0)
New: SchemaVersion (1.1.0)

SchemaVersion (1.1.0) must be backward compatible with SchemaVersion (1.0.0) and SchemaVersion (1.0.0) must be forward compatible with SchemaVersion (1.1.0).

This basically means:

All previous attributes have the same name as the new version.
All previous attributes are in the same order as the new version.
All previous attributes are of the same type as the new version.
Any new attributes are added onto the end of the new version.

These can all be determined by comparing the parsed results of both versions.

[Queries] Need Single Fetch Queries

Currently various queries require a pipeline of query resolutions
Need a table of pre-resolved types with FKs, or a set of join queries that resolve any type in a single query

This may not be the best choice for long-term, but currently it will help to simplify the queries for the source code requests and compiler seeking complex type dependencies.

Refactor E2E tests to use fixtures for org/unit/context/... instead of creating them via the UI in each test

Persistent updates in SchemataObjectStore not working as expected

After invetigating #64, it seems that updating persistent objects in schemata is broken in general.
If it is not and I'm just missing sth., I'd be very happy, so please to correct me if this is wrong.

Tests in io.vlingo.schemata.infra.persistence.SchemataObjectStoreTest seem to work, but the assertions currently used are too weak to uncover the issue.

Currently, it is only checked that the updated and the expected object are different, e.g. here: https://github.com/vlingo/vlingo-schemata/blob/master/src/test/java/io/vlingo/schemata/infra/persistence/SchemataObjectStoreTest.java#L178

When additionally asserting the updated fields like below, the tests fail.

assertEquals(updatedContextState.namespace, ((ContextState) queryInterest.singleResult.get().stateObject).namespace);
assertEquals(updatedContextState.description, ((ContextState) queryInterest.singleResult.get().stateObject).description);

Now, in HSQLDB against which the tests run, the unique constraints are turned off.
When running the test against Postgres (SchemataObjectStore.instance("~~dev~~ prod"); in https://github.com/vlingo/vlingo-schemata/blob/master/src/test/java/io/vlingo/schemata/infra/persistence/SchemataObjectStoreTest.java#L265), the tests fails with unique constraint violations like ERROR: duplicate key value violates unique constraint "context_parent_index" Detail: Key (organizationid, unitid)=(A343, U44) already exists.

After disabling the constaints, we see that actually a second row is inserted instead of the existing one being updated:

For ObjectStores, this shouldn't be the case, right?

Probably the root cause of #64.

Investigate failing E2E tests (entity updates for schema and context)

At the first glance, this looks suspiciously like #63.
The tests are skipped for now, see #87

Test implementation is in /src/test/e2e/cypress/integration/entity-updates.spec.ts.

REST Navigation Capabilities

Design and Create Queries for Hierarchy Navigation

Break this into task per query or query group

[Compiler] Build a new TypeResolver

A TypeResolver is a class that needs to be implemented so the compiler can find out which types are custom types defined in schemata. Right now there is no implementation of it, so the compiler itself is unusable in a real environment.

How to implement

Implement a type registry somewhere in schemata. @VaughnVernon can provide more info.
Implement a new class that implements the io.vlingo.schemata.codegen.processor.types.TypeResolver. You can see an example in the test code
NOTE: The InMemoryTypeResolver has been temporarily moved to src/main so the compiler will work for end-to-end tests.

[UI] Implement markdown editor for schema version descriptions

While we could have users write their schema version descriptions in markdown in a textarea, we could also integrate an editor w/ buttons for the casual markdowner & a preview.

There are already components out there that would work, but I haven't used them and can't say anything about their quality. E.g. https://github.com/DCsunset/vuetify-markdown-editor

OTOH, if we implement #34, we could probably use this editor for both the schema version spec and the description.

Patching against SchemaVersionResource#specifyWith does not update state

Patching against io.vlingo.schemata.resource.SchemaVersionResource#specifyWith creates a new row in HSQL and throws a unique constraint violated exception in Postgres.

[API] Return http error if requested code cannot be compiled

Currently, when requesting code for a specification that cannot be parsed,
the request hangs w/ sth. like the exception below.

We should return an HTTP error response in this case.

12:08:07.622 [pool-2-thread-4] DEBUG io.vlingo.actors.Logger - COMPILING:     khlkjljlk
line 1:4 mismatched input 'khlkjljlk' expecting {'command', 'data', 'document', 'envelope', 'event', 'metadata'}
12:08:07.656 [pool-2-thread-6] ERROR io.vlingo.actors.Logger - Message#deliver(): Exception: null for Actor: Actor[type=AntlrTypeParser address=GridAddress[id=6834f14a-f3a2-4c24-83da-b86420060825, name=(none)]] sending: parseTypeDefinition(java.io.InputStream, java.lang.String)
java.lang.NullPointerException: null
	at io.vlingo.schemata.codegen.parser.AntlrTypeParser.parseTypeDeclaration(AntlrTypeParser.java:68) ~[classes/:na]
	at io.vlingo.schemata.codegen.parser.AntlrTypeParser.parseTypeDefinition(AntlrTypeParser.java:51) ~[classes/:na]
	at io.vlingo.schemata.codegen.parser.TypeParser__Proxy.lambda$parseTypeDefinition$0(TypeParser__Proxy.java:29) ~[classes/:na]
	at io.vlingo.actors.LocalMessage.internalDeliver(LocalMessage.java:115) ~[classes/:na]
	at io.vlingo.actors.LocalMessage.deliver(LocalMessage.java:47) ~[classes/:na]
	at io.vlingo.actors.plugin.mailbox.concurrentqueue.ConcurrentQueueMailbox.run(ConcurrentQueueMailbox.java:101) ~[classes/:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_212]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_212]
	at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_212]
12:08:07.656 [pool-2-thread-6] ERROR io.vlingo.actors.Logger - DefaultSupervisorOverride: Failure of: GridAddress[id=6834f14a-f3a2-4c24-83da-b86420060825, name=(none)] because: null Action: Resuming.
java.lang.NullPointerException: null
	at io.vlingo.schemata.codegen.parser.AntlrTypeParser.parseTypeDeclaration(AntlrTypeParser.java:68) ~[classes/:na]
	at io.vlingo.schemata.codegen.parser.AntlrTypeParser.parseTypeDefinition(AntlrTypeParser.java:51) ~[classes/:na]
	at io.vlingo.schemata.codegen.parser.TypeParser__Proxy.lambda$parseTypeDefinition$0(TypeParser__Proxy.java:29) ~[classes/:na]
	at io.vlingo.actors.LocalMessage.internalDeliver(LocalMessage.java:115) ~[classes/:na]
	at io.vlingo.actors.LocalMessage.deliver(LocalMessage.java:47) ~[classes/:na]
	at io.vlingo.actors.plugin.mailbox.concurrentqueue.ConcurrentQueueMailbox.run(ConcurrentQueueMailbox.java:101) ~[classes/:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_212]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_212]
	at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_212]

[Build] Build vlingo-* dependencies in CI from scratch instead of pulling them from central

Due to the current versioning scheme, the contents of a non-SNAPSHOT dependency might change (for a thorough discussion see vlingo/xoom-actors#17).

With artifacts being cached either in .m2 or in proxies on the way from central to where ever the build runs, this leads to flakey builds.

To work around this until the mentionend issue is resolved, we just build the dependencies freshly in CI on each build

[UI] Refactor creation dialogs to remove duplicated query & state management code

[Backend] After updating to current 0.9.1-RC2 snapshot, the server fails to start

After pulling the changes of all dependencies (updates between 2019-10-30 and 2019-11-08), the server fails to start with the exception below.

The corresponding test io.vlingo.schemata.BootstrapTest#testThatBootstrapStartsServerCleanly also fails.

I checked whether the Definition args match the Actor's c'tor as indicated in the exception, but they do, see screenshot below.

Instead, the exception seems to be thrown during initialization of ServerActor from the Actor super c'tor when trying to create a new TestEnvironment. In io/vlingo/actors/testkit/TestEnvironment.java:17, TestWorld.Instance.get().world().stage() throws an NPE as TestWorld.Instance.get() returns null.

This happens in the unit tests as well as when running the application in dev or prod modes. In the latter cases, is it correct that no ActorFactory.threadLocalEnvironment is found?

java.lang.IllegalArgumentException: Actor instantiation failed because: ActorFactory failed actor creation for: Address[id=101, name=(none)]
	at io.vlingo.actors.Stage.createRawActor(Stage.java:659)
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448)
	at io.vlingo.actors.Stage.actorFor(Stage.java:406)
	at io.vlingo.actors.Actor.childActorFor(Actor.java:181)
	at io.vlingo.wire.fdx.bidirectional.ServerRequestResponseChannelActor.startProcessors(ServerRequestResponseChannelActor.java:161)
	at io.vlingo.wire.fdx.bidirectional.ServerRequestResponseChannelActor.<init>(ServerRequestResponseChannelActor.java:44)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:116)
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75)
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656)
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448)
	at io.vlingo.actors.Stage.actorFor(Stage.java:143)
	at io.vlingo.wire.fdx.bidirectional.ServerRequestResponseChannel.start(ServerRequestResponseChannel.java:54)
	at io.vlingo.http.resource.ServerActor.<init>(ServerActor.java:83)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:116)
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75)
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656)
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448)
	at io.vlingo.actors.Stage.actorFor(Stage.java:143)
	at io.vlingo.http.resource.Server.startWith(Server.java:111)
	at io.vlingo.http.resource.Server.startWith(Server.java:81)
	at io.vlingo.http.resource.Server.startWith(Server.java:60)
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:68)
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87)
	at io.vlingo.schemata.Bootstrap.main(Bootstrap.java:96)
Caused by: java.lang.InstantiationException: ActorFactory failed actor creation for: Address[id=101, name=(none)]
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:139)
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75)
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656)
	... 31 more
java.lang.IllegalArgumentException: Actor instantiation failed because: ActorFactory failed actor creation for: Address[id=9223372036854775802, name=server-request-response-channel]
	at io.vlingo.actors.Stage.createRawActor(Stage.java:659)
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448)
	at io.vlingo.actors.Stage.actorFor(Stage.java:143)
	at io.vlingo.wire.fdx.bidirectional.ServerRequestResponseChannel.start(ServerRequestResponseChannel.java:54)
	at io.vlingo.http.resource.ServerActor.<init>(ServerActor.java:83)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:116)
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75)
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656)
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448)
	at io.vlingo.actors.Stage.actorFor(Stage.java:143)
	at io.vlingo.http.resource.Server.startWith(Server.java:111)
	at io.vlingo.http.resource.Server.startWith(Server.java:81)
	at io.vlingo.http.resource.Server.startWith(Server.java:60)
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:68)
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87)
	at io.vlingo.schemata.Bootstrap.main(Bootstrap.java:96)
Caused by: java.lang.InstantiationException: ActorFactory failed actor creation for: Address[id=9223372036854775802, name=server-request-response-channel]
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:139)
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75)
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656)
	... 19 more
java.lang.IllegalArgumentException: Actor instantiation failed because: ActorFactory failed actor creation for: Address[id=9223372036854775803, name=(none)]
	at io.vlingo.actors.Stage.createRawActor(Stage.java:659)
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448)
	at io.vlingo.actors.Stage.actorFor(Stage.java:143)
	at io.vlingo.http.resource.Server.startWith(Server.java:111)
	at io.vlingo.http.resource.Server.startWith(Server.java:81)
	at io.vlingo.http.resource.Server.startWith(Server.java:60)
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:68)
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87)
	at io.vlingo.schemata.Bootstrap.main(Bootstrap.java:96)
Caused by: java.lang.InstantiationException: ActorFactory failed actor creation for: Address[id=9223372036854775803, name=(none)]
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:139)
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75)
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656)
	... 8 more
Exception in thread "main" java.lang.NullPointerException
	at io.vlingo.actors.Stage.actorFor(Stage.java:152)
	at io.vlingo.http.resource.Server.startWith(Server.java:111)
	at io.vlingo.http.resource.Server.startWith(Server.java:81)
	at io.vlingo.http.resource.Server.startWith(Server.java:60)
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:68)
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87)
	at io.vlingo.schemata.Bootstrap.main(Bootstrap.java:96)
13:27:13.779 [pool-2-thread-5] ERROR io.vlingo.actors.Logger - ActorFactory: failed actor creation. This is sometimes cause be the constructor parameter types not matching the types in the Definition.parameters(). Often it is caused by a failure in the actor constructor. We have attempted to uncover the root cause here, but that may not be available in some cases.
The root cause may be: java.lang.NullPointerException
See stacktrace for more information. We strongly recommend reviewing your constructor for possible failures in dependencies that it creates.
java.lang.NullPointerException: null
	at io.vlingo.actors.testkit.TestEnvironment.<init>(TestEnvironment.java:17) ~[classes/:na]
	at io.vlingo.actors.Actor.<init>(Actor.java:162) ~[classes/:na]
	at io.vlingo.wire.channel.SocketChannelSelectionProcessorActor.<init>(SocketChannelSelectionProcessorActor.java:49) ~[classes/:na]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_212]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_212]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_212]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_212]
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:116) ~[classes/:na]
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75) ~[classes/:na]
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656) ~[classes/:na]
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448) ~[classes/:na]
	at io.vlingo.actors.Stage.actorFor(Stage.java:406) ~[classes/:na]
	at io.vlingo.actors.Actor.childActorFor(Actor.java:181) ~[classes/:na]
	at io.vlingo.wire.fdx.bidirectional.ServerRequestResponseChannelActor.startProcessors(ServerRequestResponseChannelActor.java:161) ~[classes/:na]
	at io.vlingo.wire.fdx.bidirectional.ServerRequestResponseChannelActor.<init>(ServerRequestResponseChannelActor.java:44) ~[classes/:na]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_212]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_212]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_212]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_212]
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:116) ~[classes/:na]
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75) ~[classes/:na]
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656) ~[classes/:na]
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448) ~[classes/:na]
	at io.vlingo.actors.Stage.actorFor(Stage.java:143) ~[classes/:na]
	at io.vlingo.wire.fdx.bidirectional.ServerRequestResponseChannel.start(ServerRequestResponseChannel.java:54) ~[classes/:na]
	at io.vlingo.http.resource.ServerActor.<init>(ServerActor.java:83) ~[classes/:na]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_212]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_212]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_212]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_212]
	at io.vlingo.actors.ActorFactory.start(ActorFactory.java:116) ~[classes/:na]
	at io.vlingo.actors.ActorFactory.actorFor(ActorFactory.java:75) ~[classes/:na]
	at io.vlingo.actors.Stage.createRawActor(Stage.java:656) ~[classes/:na]
	at io.vlingo.actors.Stage.actorProtocolFor(Stage.java:448) ~[classes/:na]
	at io.vlingo.actors.Stage.actorFor(Stage.java:143) ~[classes/:na]
	at io.vlingo.http.resource.Server.startWith(Server.java:111) ~[classes/:na]
	at io.vlingo.http.resource.Server.startWith(Server.java:81) ~[classes/:na]
	at io.vlingo.http.resource.Server.startWith(Server.java:60) ~[classes/:na]
	at io.vlingo.schemata.Bootstrap.<init>(Bootstrap.java:68) ~[classes/:na]
	at io.vlingo.schemata.Bootstrap.instance(Bootstrap.java:87) ~[classes/:na]
	at io.vlingo.schemata.Bootstrap.main(Bootstrap.java:96) ~[classes/:na]

[Compiler] Backend for C#

We need a backend compiler for C#. We don't know if there is something like JavaPoet for C#, but because types are relatively simple, it might make sense to just do it manually.

An example implementation for Java can be found here: io.vlingo.schemata.codegen.backend.java.JavaBackend

Review why SchemataObjectStoreTest#testThatObjectStoreInsertsSchemaStateAndQuerys fails

[UI] Editing Fails On Existing Draft SchemaVersion

Create a new SchemaVersion
Attempt to edit it
The editor is not in edit mode and appears to be in error (text is red)

[Persistence] Make JDBC connection configurable

Currently, a H2 connection is hardcoded in io.vlingo.schemata.infra.persistence.JDBCConfiguration.

We should be able to configure different DB backends, preferably using env vars, so we can simply spin up another database (container) and let the schemata container connect to it.

Or are there other configuration mechanisms I am not aware of?

CQRS Query Model

Project Command Model Domain Events into a Query Model
The Command Model exists
Suggestion: Use Postgres StateStore for the Query Model
See Spec and Wireframes here: https://github.com/vlingo/vlingo-schemata/tree/master/docs

[UI] Creating New SchemaVersion Should Default Previous Version

On SchemaVersion editor, Previous Version defaults to blank
Suggest querying the tip version as the default
If no previous version, put 0.0.0 in the entry field

[Compiler] Allow the TypeResolver to call recursively the compiler for type definitions

Type definitions need to be compiled when queried from the database. Now the TypeResolver is asynchronous so it would allows us to reactively compile type definitions.

io.vlingo.schemata.codegen.processor.types.TypeResolver

We need to extend the TypeResolver interface in the SchemaVersionQueries protocol:

io.vlingo.schemata.query.SchemaVersionQueries

And probably we will need to change the TypeResolver to be able to compile TypeDefinitions from sources.

[UI] Allow for changing schema version states

Users should be able to change schema version state from the UI.
Valid state transitions:

Draft -> Published
Draft -> Removed
Published -> Deprecated
Deprecated -> Removed

[API] Schemata containing simple types cannot be retrieved via the API

When requesting the sources for a schema that contains at least one basic type not checked for in io.vlingo.schemata.codegen.processor.types.ComputableTypeProcessor#resolveType, the request hangs.
Schema not containing simple types can be retrieved, but after trying to retrieve one that does, a second try with a schema that worked before also fails.
If I'm not mistaken, this only happens with the TypeResolver in SchemaVersionQueriesActor, CacheTypeResolver did work with basic types.

When compiling the same schema within a test, the compilation works.

To reproduce via the http API:

Run all requests in src/test/resources/rest-api-calls.http starting from L:148 one after another
The last request (L:160) leads to the issue

To reproduce via the UI:

Open the UI
Create Org/Unit/Context/Schema/SchemaVersion
Use a specifciation containing a string property, see example
Navigate to the schema version in the treeview
Select the version
Request the generated sources by clicking Source

Minimal example spec:

event Foo {
    string bar
}

There already was a discussion on Slack, but I prefer having an issue to reference instead of searching within the chat history.

[UI] Implement code editor for schema version definitions

A simple text field for defining SchemaVersion specifications is not the best we can provide, IMHO.

Since we already have a specification grammar and things like https://microsoft.github.io/monaco-editor/ are out there, we can probably integrate a real editor.

We should discuss/research options.

[Docker] Make schemata app run within docker again

Currently, the app hangs when serving resources, but only when run within docker. Running the jar works as expected.

Steps to reproduce

Build the jar mvn package (⚠️ use JDK 1.8)
Run the jar java -jar target/vlingo-schemata-0.9.3-RC4-jar-with-dependencies.jar dev
Get the index curl localhost:9019/app/
-> This works as expected
Stop the server
Build the docker image: docker build . -t vlingo/vlingo-schemata
Run the docker image: docker run -p9019:9019 vlingo/vlingo-schemata
Get the index again curl localhost:9019/app/
-> The request hangs

@kbastani wrote an alternative implementation for serving static resources (https://github.com/vlingo/vlingo-xoom/blob/master/vlingo-xoom-server/src/main/java/io/vlingo/xoom/resource/CachedStaticFilesResource.java) using caches instead of re-reading resources from the FS that seems not to suffer from this issue.

[UI] Allow for refreshing schemata tree without reloading app

[Persistence] Organization / Unit / Context / etc. Names Should Be Unique

Currently creating organizations, units and contexts with the resp. same name is possible.
This can lead to them not being distinguishable from the UI. We could either also show the resp. IDs (but Users having to compare UUIDs is probably not the UX we're aiming for) or constrain the names to have to be unique.

Currently, this is possible:

vlingo / xoom-schemata Goto Github PK

xoom-schemata's People

Contributors

Stargazers

Watchers

Forkers

xoom-schemata's Issues

How to implement

How to implement

How to implement

Recommend Projects

Recommend Topics

Recommend Org