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,
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 '/',
> 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?
H
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
On Thu March 5 2009 11:22:23 pm Benson Margulies wrote:
> The current validation API assumes that validation is a feature of a
> reader. That's not really what we want here, exactly, and I'm not sure
> how to get there. We have a StaX stream, and a portion of the events
> on it should correspond to
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 thei
They've recently setup the hudson instances to allow them to deploy snapshots
to the Nexus instance using a special "snapshot" account. Thus, we could now
have automated builds that do deploys of snapshots. We couldn't really do
that previously without giving out some authentication stuff s
I'm sure tired of making snapshots, so I'm in favor!
On Fri, Mar 6, 2009 at 11:13 AM, Daniel Kulp wrote:
>
> They've recently setup the hudson instances to allow them to deploy snapshots
> to the Nexus instance using a special "snapshot" account. Thus, we could now
> have automated builds that
I am +1 on the idea because of the more regular latest snapshots.
-- Ulhas
Daniel Kulp wrote:
They've recently setup the hudson instances to allow them to deploy snapshots
to the Nexus instance using a special "snapshot" account. Thus, we could now
have automated builds that do deploys of sna
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
10 matches
Mail list logo
