cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject RE: ProviderFactory singleton?
Date Fri, 06 Mar 2009 12:12:51 GMT
OK. I'm not sure yet what would be the best way to tackle it.
How restrictive would it be if we said that every jaxrs:endpoint should
have its own unique address ? 

For ex, at the moment :

CXFServlet1 : /1/* links to beans1.xml 
CXFServlet2 : /2/* links to beans2.xml

jaxrs:server/@adress='/' in both beans1.xml and beans2.xml,
presumably relying on separate resource classes, say the one in
beans1.xml uses Resource.class with @Path("/r1") and the other one uses
Resource2.class with @Path("/r2")  

So one option would be to move /r1 and /r2 out of the resource classes
into corresponding jaxrs:server/@adress(es) and just have @Path("/") for
both resource classes.

One issue is that ProviderFactory is also used at the moment in the
client api, 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.

Mime
View raw message