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.
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,
- 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
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.
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
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"
Currently in Automation,
content-typeis 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
- It makes HTTP Content-Type meaningless for us
- In some cases we enforce using a
application/json+nxautomation: this is meaningless and error prone
- We could use
Content-Typeheader to select adapters: this would avoid having
- In some cases we enforce using a
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 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
Userendpoint would benefit from this feature.
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