I guess I just find that conceptually awkward. Our use case is that we have a single war that hosts a variety of CXF services imported from module jars. Each module is responsible for defining their own CXF server, and the war creates one CXF servlet for each module and places each one on their own context path. The war also makes certain common services available to each module via spring, which allows common singleton-type objects to be shared across multiple modules (things like datasources, caches, threadpools, etc)
Each module has no knowledge of any other module its deployed next to, which is why multiple modules may easily have overlapping addresses. We first came upon this issue when different modules defined different error handlers, which worked in each module independently, but broke when deployed. As a spring-based application, I suppose the assumption is that any singletons in the system would be spring-style singletons, isolated at the bean factory level. Not a show-stopper for us, but since JAX-RS is a very nice easy-to-use library, as usage spreads I wouldn't be surprised if this issue comes up again as CXF JAX-RS is deployed into wierder and wierder containers. An OSGi container with shared classloading comes to mind as an environment where this would break. -----Original Message----- From: Sergey Beryozkin [mailto:sbery...@progress.com] Sent: 06 March 2009 12:13 To: dev@cxf.apache.org Subject: RE: ProviderFactory singleton? 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.t...@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:sbery...@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.t...@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. -------------------------------------------------------------------------- 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.
