Hi,
Niall Gallagher wrote:
> 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
Like I told you on the Grizzly malling list, it might be nice if you
could publish more information about your benchmark/platform/etc, and
more important, how you configured Grizzly :-) Let's have the discussion
on your(or Grizzly dev malling list ;-)
A+
- jeanfrancois
>
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
