LiveOakClient

[peterson.dean]

I have a need for a few things such as security for GridFS and other features I have mentioned elsewhere.  I think I may have to attempt contributing.  I am looking at the code and I need a little help.  I was expecting to find a REST API implemented in java for readMembers, createMember, etc. using the JAX-RS specification.  Instead, it looks like the LiveOakClient.java file is converted into javascript at runtime for each application (akin to Direct Web Remoting).  Direct Web Remoting is an old javascript framework that would turn Java into javascript for use in the client.  To help get oriented, can you shed some light on how/where the code for hitting the url of a resource is located in the codebase or how the LiveOakClient is turned into javascript?  How do the requests get intercepted if no @Path annotations have been set?

I apologize if this is a basic question.  I come from a Spring and Websphere background.  I have spent some time with JBoss REST but only in relation to JAX-RS and RestEasy.

[kenfinni]

We'd be very excited to help you out with contributing to any areas of LiveOak!

Are you referring to LiveOakClient.java that's present within /modules/scripts? If so, all the code within the "scripts" module is specifically for Business Logic within LiveOak. Business Logic is our way of enabling an application developer to execute server side Javascript on REST endpoints as part of processing a REST request. Documentation on that aspect can be found here

LiveOak doesn't implement the JAX-RS specification, or any other REST frameworks.

The guts of the request handling is within the "container" module. liveoak/modules/container/src/main/java/io/liveoak/container/traversal at master · liveoak-io/liveoak · GitHub contains the code that's responsible for building up a series of "steps" where each step is one part of the URI path of the request. Then the TraversingResponder iterates through the generated steps, calling readMembers(), updateProperties(), createMember(), or deleteMember() as appropriate on the Resource.

No need to apologize, we have a lot of work to do on our documentation! Any tips or feedback on where we can specifically improve it would be greatly appreciated.

Ken