Hi Gary
is there any chance you can share it somehow ? Perhaps opening a JIRA and attaching some sample configuration or indeed, juts
posting it to the list ? It will make it easier for me to start working on a fix..
Cheers, Sergey
----- Original Message -----
From: "Tong, Gary (IDEAS)" <[email protected]>
To: <[email protected]>; "Daniel Kulp" <[email protected]>
Sent: Monday, March 09, 2009 10:54 AM
Subject: RE: ProviderFactory singleton?
Hi Sergey,
I've done a bit of work to allow two overlapping addresses to be deployed side-by-side. It mostly involes doing all the
configuration within a child context. Small change really, which works fine except for the bit about the providers.
I think Dan is talking about the same deployment issues as I am. In OSGi you could have two bundles that both use CXF JAX-RS that
end up stomping all over each other's singletons. This really shouldn't happen, but some OSGi (most?) containers allow for shared
classloading in one fashion or another, which could cause issues.
Gary
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: 09 March 2009 10:38
To: Daniel Kulp; [email protected]
Subject: Re: ProviderFactory singleton?
Hi,
I wish someone explained me why things will get worse in OSGI, with
ProviderFactory.getInstance().
There's a direct relationship between any given endpoint and a ProviderFactory instance and ProviderFactory does not rely itself on
some FactoryFinders, etc...It's all quite straightforward really there and at the moment I don't see why things will fail in OSGI,
given that in fact I've seen CXF JAXRS working in OSGI, though withougt multiple endpoints being involved.
Is it because ProviderFactory has static fields ? Are we talking here about multiple CXF JAXRS bundles being loaded ? I guess we
will have multiple versions in this case so I don't see why classloading issues will arise in such cases. What is it that I'm
missing ? It simply encapsulates the requirement "try user providers first, delegate to the defulat ones as the last resort".
Each module has no knowledge of any other module its deployed next to, which is why multiple modules may easily have overlapping
addresses.
this is more intertesting to me really, as it's about the concrete problem which might occur at the deployment time. I honestly did
not know that it were possible to have multiple jaxrs:endpoints with identical address values working even only with default
providers involved (note, overlapping addresses, as in say '/bar' and '/' should work fine with per-endpoint providers), with CXF
servlets providing the needed uniqueness to the actual adresses. I'll need to think how it can be accomodated - I'm just not sure
yet how :-). Perhaps the validation rules invoked at the deployment time would ensure the uniqueness of jaxrs:endpoint addresses -
but that depends on the availability of such rules - and again - if things are expected to work with multiple endpoints having
identical @adress values then CXF JAXRS has to ensure per-endpoint providers don't clash with eath other.
thanks, Sergey
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:[email protected]]
Sent: 06 March 2009 11:44
To: [email protected]
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:[email protected]]
Sent: 06 March 2009 10:18
To: [email protected]
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:[email protected]]
Sent: 06 March 2009 09:14
To: [email protected]
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
[email protected]
http://www.dankulp.com/blog
--------------------------------------------------------------------------
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.
