[Building Sakai] Any Comments on org.codehaus.jackson ??

Thu Jun 20 06:08:59 PDT 2013

Wow, touchy much?

I was actually responding to a previous comment questioning whether EB was the best fit for REST overall, since Jackson/Jersey/REST/EB, you know, its all related.

I also said that I plan on looking at the performance of EB, the current provider for REST in Sakai, and obviously will contribute anything that is developed there back to the main code. If you really want to get into it, a number of enhancements relating to XML generation in EB were suggested to you 12 months ago that would make it the elements better defined and more compliant with expected XML generation, and be a huge improvement for external tools wanting to integrate with Sakai. And that went nowhere. So if you want to discuss those issues and the merits of what REST should be in Sakai, then lets get this on a new thread.

It's interesting that whenever anyone suggests possible improvements or modifications in this community it almost always gets a negative response about resourcing. I can cite many examples. It's almost like a discussion can't actually be had on anything because unless the proposer is going to be the one doing it, then you shouldn't even bring it up. Hardly encouraging for open discussion that someone might see and actually invest in...

On 20/06/2013, at 10:46 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:

>> Though it has been mentioned before that the providers should be versioned
>> like an API, so maybe they should all be in the one webapp?
> 
> Putting all providers under one webapp is a non-starter in my opinion.
> The entire point of EB was to distribute out control over endpoints
> (and entity management) to the various parts of the system (without
> causing classloader issues) and still have them all documented and
> under a central path (/direct). You would make it virtually impossible
> for contrib tools to make endpoints and I would consider this a major
> step backwards and I would -1 it if it were proposed.
> 
> Versioning could be handled without an overbearing change like that.
> /direct/1.1/thing/... where ... is the rest of the typical path.
> Leaving off the version number (like it is today) could simply use
> whatever the highest version is to avoid breaking the contract for all
> the apps out there.
> 
> That said, if you (or anyone) can find a way to put in some other
> mechanism and still be backwards compatible (and of course agree to
> maintain that change) then please feel free to make a branch and get
> to coding. I certainly welcome any improvements that do not break the
> current API contracts and don't degrade performance significantly.
> 
> However, I think you should stop hijacking this thread and start a new
> one if you want to continue to discuss this.
> -AZ
> 
> 
> On Thu, Jun 20, 2013 at 8:25 AM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> It would actually be pretty trivial to move all of the EB entity providers
>> over to a servlet style setup, map on the same paths using Jersey and keep
>> the same input and output config. Though we also need to honour the other
>> capabilities that can be performed through EB that may not have equivalents,
>> but not impossible.
>> 
>> The nontrivial part would be wiring up registration code so that separate
>> 'providers' in the various webapps could all participate under /direct.
>> Though it has been mentioned before that the providers should be versioned
>> like an API, so maybe they should all be in the one webapp?
>> 
>> I do like EB, but its possible to do what it does in other ways for sure.
>> Part of Project Keitai will actually be looking at the performance of Entity
>> Broker so this is a very timely discussion to be had.
>> 
>> cheers,
>> Steve
>> 
>> 
>> On 20/06/2013, at 8:55 PM, Adrian Fish <adrian.r.fish at gmail.com> wrote:
>> 
>> Scalatra uses Jackson for its JSON support.
>> 
>> http://www.scalatra.org/guides/formats/json.html
>> 
>> I wonder whether it's worth at some point discussing whether EB as it stands
>> is a good fit for actually mapping REST paths onto functionality?
>> ActionsExecutable does a RESTlet type job in that you can pick out path
>> components but in the end you just end up with an entity provider with one
>> big executable action and some private methods for handling the incoming
>> paths. What I'd like to do is just map paths onto handlers without
>> repeatedly writing path parsing boilerplate.
>> 
>> EB does a good job and fills a gap, but it has to be maintained so it's
>> perhaps worth considering whether we can use a more broadly used REST (and
>> JSON) framework.
>> 
>> Cheers,
>> Adrian.
>> 
>> 
>> On 20 June 2013 00:27, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>>> 
>>> Here's another perf comparison
>>> 
>>> 
>>> http://blog.novoj.net/2012/02/05/json-java-parsers-generators-microbenchmark/
>>> 
>>> Sent from my iPhone
>>> 
>>> On 20/06/2013, at 2:30, "Zach A. Thomas" <zach.thomas at gmail.com> wrote:
>>> 
>>> On the performance question, I have referred to this benchmark in the
>>> past:
>>> https://github.com/eishay/jvm-serializers/wiki
>>> 
>>> As for other options, can you recommend an alternative?
>>> 
>>> Zach
>>> On Jun 19, 2013, at 10:33 AM, Aaron Zeckoski <azeckoski at unicon.net> wrote:
>>> 
>>> 1) Jackson is the best/fastest JSON reader/writer and Object/JSON mapper.
>>> I would love to see us standardize on this. I am using in my own
>>> EntityProviders for output.
>>> 
>>> 
>>> That's an opinion I strongly disagree with so I would not be a fan of
>>> us standardizing on this at all. I would like to see some strong
>>> evidence to backup this statement. I attempted to use this for JSON
>>> handling in multiple projects and we settled on other options in every
>>> case (re: matterhorn, dspace, EB, etc.). The handling of maps and
>>> collections was especially problematic (at the time anyway).
>>> 
>>> 
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> 
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>> 
>>> 
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>> 
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>> 
>> 
>> 
>> 
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>> 
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile