cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Startup speed, XML, etc.....
Date Fri, 04 Mar 2011 09:53:02 GMT
Hi Dan

Some comments on the HTTP...

The HTTP stuff on the server side becomes a "challenge".   Right now, we
> have
> basically 3 implementations of the HTTPDestinationFactory:   jetty,
> servlet,
> and OSGi.    The user pretty much selects the one they want by importing
> the
> appropriate cxf-extension file and not the others in their spring config.
> While it works, there is a down side:  you can only have one
>  implementation
> in  you application.   Normally not a problem, but there IS the use case of
> a
> Servlet based application that may also want a service or two exposed on a
> specific jetty port  (like maybe for a decoupled client) that isn't under
> the
> servlet containers control.
>
> My proposal for that would be to put a single HTTPDestinationFactory in the
> http module that would hold onto a DestinationRegistry.   The OSGi and
> Servlet
> based things would just grab that DestinationRegistry for their
> dispatching.
> However, when the HTTPDestinationFactory is asked to create a destination
> for
> a "full" URL (like "http://localhost:8080/blah") instead of a path (like
> "/blah"), it would call on a delegate that the Jetty stuff would provide to
> it.   I need to think about this a bit more, but I think it would work
> fairly
> well.
>
>
I'd like to propose to view this refactoring in the context of the future
OSGI enhancements in general, particularly the one related to the http-osgi
transport. I feel there's an opportunity to make the http-osgi transport
deprecated which is mostly duplicating the http transport code, assuming we
can figure out how to make the whole CXF play nicely and more pro-actively
in OSGI. If we manage to have a top-level Activator (in trunk/distribution)
delegating to individual Activators (http, jaxws, jaxrs, and other key
modules) then in case of the HTTP transport it can follow a pure and
straight-forward OSGI way to get OSGI HTTP service, register as a servlet,
make itself configurable via Config manager, etc and make it all as dynamic
as it is in DOSGI...

thanks, Sergey


> Dan
>
>
>
>
> Running test - 2.4.0-SNAPSHOT
> Setup: 29086 51/sec
> Invoke: 42558 35/sec
> Setup config: 69839 21/sec
>
>
> Running test - 2.3.3
> Setup: 49732 30/sec
> Invoke: 62276 24/sec
> Setup config: 56164 26/sec
>
> Running test - 2.3.0
> Setup: 44233 33/sec
> Invoke: 56496 26/sec
> Setup config: 55305 27/sec
>
> Running test - 2.2.12
> Setup: 48193 31/sec
> Invoke: 55737 26/sec
> Setup config: 50582 29/sec
>
>
> Running test - 2.1.9
> Setup: 43944 34/sec
> Invoke: 47652 31/sec
> Setup config: 44550 33/sec
>
>
> Running test - 2.1.1
> Setup: 47335 31/sec
> Invoke: 48871 30/sec
> Setup config: 49255 30/sec
>
>



-- 
Sergey Beryozkin

Application Integration Division of Talend <http://www.talend.com>
http://sberyozkin.blogspot.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message