It's been a while since I published a tech report. We made some changes in the way we handled them internally, adjusting the process a bit. But here it is again! It's a little shorter than usual, but hopefully we'll publish more than once a month.

What's on tap:


 

 

Core Session Management


Florent is cleaning up CoreSession management: NXP-13148. Goal is to make sure that sessions are always removed as soon as they are no more used, as currently, there are some situations where the linked vcs connection is already freed, and the core session is still alive, which means that we keep an object that would never have any chance to connect and be used again. With Stéphane's work on database connection, it is the beginning of a virtuous cycle on freeing all objects that are useless at all the levels: datasources, vcs pool, core sessions, and then Seam beans. This task will open the way to a less stateful Seam/JSF web app, increasing its scalability and simplifying programmation patterns.

 

Elasticsearch Integration


After completing some tests and benchmarking on Elasticsearch, we have started the Java integration. The umbrella task is NXP-14007. We are just beginning to have a way to start Elasticsearch with a Nuxeo Server and index/query Documents.

Not surprisingly, we are finding the same constraints we had previously with Compass integration (Nuxeo 5.3 and before), but the good news is that Nuxeo now offers more infrastructure:

  • Transactional test infrastructure,

  • WorkManager,

  • Improved post commits, and

  • JSON Marshaling.


In the current state, we have a service with a default configuration:

  • Support for indexing and re-indexing

  • Support for query (including security filtering)

    • In native Query DSL

    • In NXQL

    • With PageProviders




Simplified ACLs


Florent created NXP-14045 for Simplified ACLs. It mostly means removing the ability to have negative permissions (deny), beside the deny everything (= block inheritance) that is still accepted. This simplifies the computation that is executed in the hierarchy to know the permissions of a user on a document. It thus allows some interesting optimisations, and is anyway likely to be needed by the Elasticsearch indexing.

WAR Packaging


We recently had several customers wanting to deploy on JBoss or WebSphere. We know that making Nuxeo deploy in dynamic mode on several application servers needs a lot of work. However, doing this using a static WAR:

  • Should be much simpler, and

  • Should be enough for most use cases.


This also mean that we will have to completely embedding DataSource management in Nuxeo, and Isolating the nuxeo.war class loader to avoid lib conflicts.

NXP-14087 was created for this purpose. It is not a big task and It will be added to the roadmap as it is identified as an important

REST API


We have gathered all the feedback we got since the release of Nuxeo Platform 5.8 and the beta version of the Nuxeo REST API. Goal is to have a definitively stable and great api for 6.0. Do not hesitate to give your feedback too!

Improve HTTP Return Codes


In some cases we don't return the expected/valid http return code.

  • Bad return code in DELETE NXP-14076

  • CREATE returns 200 instead of 201


Problem with JSON typing


It looks like the default marshaling is not correct: in the JSON stream "everything is string"

=> https://jira.nuxeo.com/browse/NXP-12614

Content Types


Currently in Automation, content-type is not handled by an HTTP header, but inside the JSON stream. This design comes with several flaws:

  • The client code needs to do something like jsonResult.value

  • When posting back the data to the server, the client needs to re-encapsulate in a JSON structure like[javascript] { "entity-type": "IoApplication", "value": { ...real data here ... } } ) [/javascript]

  • It makes HTTP Content-Type meaningless for us

    • In some cases we enforce using a Content-Type like application/json+nxautomation: this is meaningless and error prone

    • We could use Content-Type header to select adapters: this would avoid having '/@bo/' urls




Hopefully, we should be able to make the change while keeping compatibility: both models should be able to work in parallel so that we don't have to update all Automation Client libraries.

Business Adapters


Business adapters are not that easy to use:

  • Same issue on the PUT adapter as the id problem we had on the Document end point,

  • Add support for DELETE on adapter,

  • Automatic name generation via Adapter.


We need to extend the Business adapters to entities that are not DocumentModel: typically the User endpoint would benefit from this feature.

Extend Bindings


We have been talking about adding new bindings that could make the developer's life easier:

  • Call an operation using a GET request

    • Useful to retrieve a Blob and display it as an image

    • This creates potential security issues



  • Add QueryString parameters in the REST API

    • ex: create a version when updating a Document