cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: ProviderFactory singleton?
Date Fri, 06 Mar 2009 16:36:30 GMT
On Fri March 6 2009 7:12:51 am Sergey Beryozkin wrote:
>
> One issue is that ProviderFactory is also used at the moment in the
> client api,

Doesn't the Client API also use the Bus?   Could/Should it?   (example: does 
it currently use the HTTPConduit/transport?)   If so, hanging this off the bus 
is probably the best idea.    I definitely agree that Singletons are a really 
bad idea.   It actually will get worse with OSGi as classloaders and stuff are 
different so that singleton could end up holding onto things and exposing 
things from other applications. 

Dan


> though an endpoint info representation is also created
> there. So we might in principle have a thread local endpoint info
> storage, such that ProviderFactory.getInstance() would use thread-local
> endpoint info as a key to get the actual ProviderFactory instance.
> Perhaps a simpler option is to just keep a ProviderFactory instance with
> a given Endpoint. I need to think about it - it's getting a bit tight
> now, as 2.2 is likely to go out quite soon so such a change may not make
> it into the trunk say next week...
>
> But do you think the possible update as suggested above would not be
> quite acceptable in your case, even as a workaround? I'd like to
> understand better when it may be unrealistic to ensure that different
> endpoints have their own addresses : perhaps there're policies on which
> uri patterns go to web.xml or to resource classes, etc ?
>
> Cheers, Sergey
>
>
>
> -----Original Message-----
> From: Tong, Gary (IDEAS) [mailto:Gary.Tong@morganstanley.com]
> Sent: 06 March 2009 11:44
> To: dev@cxf.apache.org
> Subject: RE: ProviderFactory singleton?
>
> > Is it when you have multiple CXF servlets, each of them referencing
>
> different spring configuration files ?
>
> Yes exactly.
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozk@progress.com]
> Sent: 06 March 2009 10:18
> To: dev@cxf.apache.org
> Subject: RE: ProviderFactory singleton?
>
> Hi Gary
>
> I've updated a bit ProviderFactory on the trunk, there's a default
> ProviderFactory which hosts the default providers and a ProviderFactory
> instance per every endpoint address, for ex,
> ProviderFactory.getInstance() and ProviderFactory.getInstance("/") would
> return an instance keyed by '/', etc.
> So I thought that an endpoint address, as specified by jaxrs:endpoint,
> would be a unique enough key for ProviderFactory instances.
>
> Do you have the case where multiple endpoints share the same
> jaxrs:endpoint/@address ?
>
> Is it when you have multiple CXF servlets, each of them referencing
> different spring configuration files ?
>
> Cheers, Sergey
>
> -----Original Message-----
> From: Tong, Gary (IDEAS) [mailto:Gary.Tong@morganstanley.com]
> Sent: 06 March 2009 09:14
> To: dev@cxf.apache.org
> Subject: ProviderFactory singleton?
>
> Been looking through the code, and why is ProviderFactory a singleton?
> I would think it would be tied to a bus or a server.  It differentiates
> by address, but currently I'm working on something with two side-by-side
> CXF servlets that load completely different CXF configurations.  In this
> case, providers declared in one server are bleeding into the other
> because the ProviderFactory uses a singleton.
>
> Worth fixing?  Also, are there any other uses of singletons in the
> system that maybe should be looked at?
>
> Cheers,
> Gary
>
> ------------------------------------------------------------------------
> --
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this email
> is prohibited when received in error.
>
> ------------------------------------------------------------------------
> --
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not intend to waive confidentiality or privilege. Use of this email
> is prohibited when received in error.

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message