On Feb 16, 2009, at 10:38 PM, Jeanfrancois Arcand wrote:
> 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 :-)
+1 in any performance discussion or presentation of results it is
important to disclose as much as possible so that others can
independently reproduce and verify.
Paul.
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>
