Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of sberyozkin@gmail.com
 designates 209.85.214.41 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=uBtBHmsByxs2pKa69q/IIDVeNsqXfSvUeSIV9BVYcv+MloIjBfIaJE3+TZ6IIBovwz
         120nFK4861vyILSLT0T+PMzkDmozg+aotmSFSJ2yobXM77Fbr+2InxFd3GPIbhLJ446y
         psVX1msIfRy796PJhtYWUyhNAyR1DXM1Yp5NM=
MIME-Version: 1.0
In-Reply-To: <201103031701.59210.dkulp@apache.org>
References: <201103031701.59210.dkulp@apache.org>
Date: Fri, 4 Mar 2011 09:53:02 +0000
Message-ID: <AANLkTinPgYK2FMxxNmcvM=Nsda1VCNHUvV-hYdb=Rr+A@mail.gmail.com>
Subject: Re: Startup speed, XML, etc.....
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: dev@cxf.apache.org
Content-Type: multipart/alternative; boundary=0016e6d9a37ea6077d049da51c88

--0016e6d9a37ea6077d049da51c88
Content-Type: text/plain; charset=ISO-8859-1

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

--0016e6d9a37ea6077d049da51c88--