Just a little history on this...
Originally, the JMS transport only used the JMS API's directly. I think the
version on the 2.0 branch still is that way. You may want to look at that as
a starting point if you need a custom version.
Around Aug/Sept 2008, Christian did a lot of work to refa
Sergey Beryozkin-5 wrote:
>
> Let me put it the other way. I haven't started this thread to complain
> about
> Spring, or start any debate about the use of Spring. What I'd like to
> convey
> is that IMHO it is in the interests of CXF to ensure that those
> integrators
> who prefer to provide no
Sergey Beryozkin-5 wrote:
>
> Don't really get it... Or is it the case of someone missing the point that
> some users of CXF just do not want to use Spring ?
>
I don't know, I just think it would be nice if there was a separate Apache
Banana project that consists of Spring but with its JARs re
Hi,
On Wed, Aug 4, 2010 at 6:53 PM, Sergey Beryozkin wrote:
>
>
> On Wed, Aug 4, 2010 at 6:30 PM, Glen Mazza wrote:
>
>>
>>
>> Sergey Beryozkin-5 wrote:
>> >
>> > This causes problems when doing non-Spring CXF deployments.
>> > Generally, we should really try to keep the Spring related code in
>
Hi
On Mon, Aug 2, 2010 at 3:00 PM, Tal Maayani wrote:
> Hi,
>
> According to your advice, in order to block DTD based XML attack one need
> to either use CXF version 2.2.9 or replace the default xml parser.
>
> there is an issue with (JAXRS) SourceProvider in 2.2.9 which I missed. But
this provi
On Wed, Aug 4, 2010 at 6:30 PM, Glen Mazza wrote:
>
>
> Sergey Beryozkin-5 wrote:
> >
> > This causes problems when doing non-Spring CXF deployments.
> > Generally, we should really try to keep the Spring related code in
> .spring
> > subpackages as it will make it simpler for CXF be integrated w
Don't really get it, care to explain ?
On Wed, Aug 4, 2010 at 6:30 PM, Glen Mazza wrote:
>
>
> Sergey Beryozkin-5 wrote:
> >
> > This causes problems when doing non-Spring CXF deployments.
> > Generally, we should really try to keep the Spring related code in
> .spring
> > subpackages as it will
Sergey Beryozkin-5 wrote:
>
> This causes problems when doing non-Spring CXF deployments.
> Generally, we should really try to keep the Spring related code in .spring
> subpackages as it will make it simpler for CXF be integrated with other
> similar frameworks or deployed in containers providin
On 08/04/2010 11:42 AM, Sergey Beryozkin wrote:
Hi Alessio
On Wed, Aug 4, 2010 at 10:02 AM, Alessio Soldanowrote:
Hi,
I'm working on a usecase requiring to enable WS-Reliable Messaging
programmatically. Basically I'm building up a Bus without using Spring and
I'd like to also have RM functi
Forwarding to Daniel for his opinions on this topic.
Rio
Original Message
Subject:Re: [jbossws-dev] CXF-2926
Date: Wed, 04 Aug 2010 11:37:38 +0200
From: Alessio Soldano
To: Richard Opalka
CC: Sergey Beryozkin , jbossws-dev
OK Richard, thanks.
Then you
Hi Alessio
On Wed, Aug 4, 2010 at 10:02 AM, Alessio Soldano wrote:
> Hi,
> I'm working on a usecase requiring to enable WS-Reliable Messaging
> programmatically. Basically I'm building up a Bus without using Spring and
> I'd like to also have RM functionalities on.
> That's actually possible, th
Hi,
I'm working on a usecase requiring to enable WS-Reliable Messaging
programmatically. Basically I'm building up a Bus without using Spring
and I'd like to also have RM functionalities on.
That's actually possible, the only issue I'm having right now seems to
be that, after manually creating
Hi Christian
Indeed, I can see JMSDestination & JMSFactory importing a lot of Spring
classes, so my last commit was futile, I started working yesterday on the
test which I did not finish, but that work will need to be parked for now...
In fact, I was definitely blind yesterday, removed Initializi
13 matches
Mail list logo
