Hi,
I would like to make a contribution to Jersey. I develop a light weight high performance HTTP container called Simple (
http://www.simpleframework.org). I have implemented a container and a factory similar to the container Jersey has provided for Grizzly.
Simple has been hosted on Maven for about a year now and so would fit in to the Maven build system provided for Jersey. The initial Jersey container implementation is hosted on my sourceforge.net subversion repository.
https://simpleweb.svn.sourceforge.net/svnroot/simpleweb/branches/4.1.2/security/src/jersey/
Simple is already integrated with the Restlet JAX-RS project (
http://www.restlet.org) and has the following features, which I believe would make it a useful contribution to Jersey.
1) Currently benchamarks at about twice as fast as Grizzly, Jetty, and AsyncWeb
http://www.simpleframework.org/performance/grizzly/run1/ScalabilityApacheBench.png
http://www.simpleframework.org/performance/grizzly/run2/ScalabilityApacheBench.png
2) Supports the full set of HTTP capabilities, including integrated multipart uploads, 100 continue, cookies, sessions, HTTP/1.0, HTTP/1.1, HTTPS
3) Build around NIO so has very low latencies
http://www.simpleframework.org/performance/grizzly/run1/LatencyApacheBench.png
http://www.simpleframework.org/performance/grizzly/run2/LatencyApacheBench.png
I plan to provide a full suite of tests for the container, similar to the Grizzly container tests. Also ill add support for HTTPS.
Is there any specific criteria that needs to be satisfied before a contribution is made?
Thanks,
Niall
--- On Fri, 2/13/09, Tatu Saloranta <cowtowncoder_at_yahoo.com> wrote:
> From: Tatu Saloranta <cowtowncoder_at_yahoo.com>
> Subject: Re: [Jersey] Jersey 1.0.2 released
> To: dev_at_jersey.dev.java.net
> Date: Friday, February 13, 2009, 11:06 AM
> --- On Fri, 2/13/09, Paul Sandoz <Paul.Sandoz_at_Sun.COM>
> wrote:
>
> > > One quick question on "natural" JSON:
> is that "truly natural"
> ...
> > or a lighter-weight mapping to accomodate for xml
> bindings?
> >
> > I would say we have tried to achieve as much of the
> former
> > as possible within the context of the JAXB framework
> while
> > minimizing the constraints of the latter.
>
> Ok, makes sense. So: [more] natural, but not
> "native".
>
> ...
> > In general we are finding this to be a hard problem
> because
> > different developers have different requirements and
> > expectations. For example some what namespaces
> represented
> > in JSON, or a way to support substitution.
>
> Absolutely. It is a hairy problem.
> But even ignoring namespace aspect, problem is the
> impedance between information models: xml is hierarchic,
> json resembles object/struct model (not real object model
> because it lacks identity, but similar).
>
> So challenge is similar to matching sql/objects
> (hibernate), and general xml/objects (that jaxb does).
>
> Of course, it is only a problem if one has to directly
> convert between xml and json -- theoretically that
> wouldn't need to be a requirement.
> After all, you can bind xml to/from objects, as well as
> json to/from objects, So since internally services only see
> objects, separate serializations could work independently.
> And if for some reason such transformation is needed, it
> could be done in 2 steps, from one format to object, then
> from object to result data format.
>
> And this is where direct dependencies to JAXB really become
> a problem. :-/
>
> > In part i think we need to set clear expectations on
> when
> > to use which mapping, or when not to use JSON.
>
> Yes -- in many ways, json support is just for
> interoperability; it's not really a first-class citizen.
> Which is good enough for many use cases of course, just not
> as good as support for xml.
>
> It would be nice if there was something more data format
> agnostic for Jersey to use as integration point, that JAXB
> could implement; instead of having to rely directly on JAXB
> itself.
> That is, a more general object/data binding framework. For
> Jersey, needs should be quite simple -- external data as
> byte stream, convert to/from objects passed to services
> users define.
> Conceptually that is the case already; types accepted and
> returned are annotated, without need for directly
> referencing machinery that does conversions.
>
> At this point this is just wishful thinking; with 1.x
> release it's not possible to change core API
> depedencies. But maybe for 2.0? ;-)
>
> -+ Tatu +-
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail:
> dev-help_at_jersey.dev.java.net
