Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4D702431.6000008@die-schneider.net>
Date: Fri, 04 Mar 2011 00:28:49 +0100
From: Christian Schneider <chris@die-schneider.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de;
 rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: Re: Startup speed, XML, etc.....
References: <201103031701.59210.dkulp@apache.org>
In-Reply-To: <201103031701.59210.dkulp@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sounds interesting. I am currently working on the camel-servlet module 
and thought about the same thing.
At the moment in camel servlet: is used to indicate a servlet based 
server. While jetty: is used for a jetty based.
I thought to use only http and choose based on full url with server 
(jetty) or without (servlet).

For the moment my focus is on removing the timing problem when creating 
a servlet in web.xml and a endpoint in spring.
I also solved it with a HttpRegistry. Unlike in CXF servlets and 
consumers both register with it and it connects both.
So this works a bit like the whiteboard pattern.

Btw. I think at the moment in CXF we use the whiteboard extender to 
register the osgi http servlet.
The problem with this is that it runs only with pax web. Should we do 
something about this?

Christian


Am 03.03.2011 23:01, schrieb Daniel Kulp:
> 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.
>
>
> 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
>
>

-- 
----
http://www.liquid-reality.de