Hi,
--- On Mon, 2/16/09, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM> wrote:
> From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
> Subject: Re: [Jersey] Jersey HTTP Container Contribution
> To: dev_at_jersey.dev.java.net
> Date: Monday, February 16, 2009, 1:38 PM
> 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 ;-)
Sure no problem, we can continue on either. I will send a mail to Grizzly dev if that suits. Ill provide the code and command used to run Grizzly on the tests I have performed.
Niall
> 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
