> There is a "randomly" failing continuations test that I've asked Sergey
> to look at, but it's failing on on the branches. If he cannot find a
> fix tomorrow, I'll @Ignore it for a bit.
Looking into it now... The initial observation is that it is always green if the test server (Server2) is
gorized/src/test/java/org/apache/cxf/systest/jms/continuations/HelloWorldWithContinuationsJMS.java
cheers, Sergey
- Original Message -
From: "Sergey Beryozkin"
To:
Cc: "Benson Margulies"
Sent: Thursday, September 03, 2009 11:41 AM
Subject: Failing JMS
2009 18:54
To: dev@cxf.apache.org
Cc: Sergey Beryozkin; Benson Margulies
Subject: Re: Failing JMS Continuations test (Was : Re: Back to
normal.)
OK. I'm pretty sure Sergey and I tracked this down to some thread
safety
issues in the ConduitSelector. However, it was made even wor
nd StaX writes them. Admittedly, if Aegis ever
> forgot to assign a prefix StaX would just go add an xmlns=, but I don't
> (yet) think that this is something that happens.
>
> Do you have any idea why the JSON environment ends up being so much more
> fussy?
>
> --benson
Hi
I'm concerned it may be not be portable, that is the providers which
work with other JAXRS implementations will end up being unusable in CXF.
You may be right but I've seen the number of providers which implement
MessageBodyX and then cast them internally. For ex to Feed or
Entry, etc.
Let me
Users can easily wrap Jackson if they prefer. We can add a property to
existing providers which will allow for namespaces be dropped altogether
during the serialization if users prefer to parse JSON manually.
Cheers, Sergey
-Original Message-
From: Benson Margulies [mailto:bimargul...@gm
oviders - perhaps I might just add a system test showing how Jackson
can be wrapped.
cheers, Sergey
- Original Message -
From: Benson Margulies
To: CXF Dev ; Sergey Beryozkin
Sent: Saturday, September 05, 2009 2:41 PM
Subject: Aegis + JSON = Chaos in namespaces
I've c
http://wiki.fasterxml.com/JacksonInFiveMinutes
It looks to me as if a Jackson 'provider' would be a pretty straightforward
construction. To be clear, there's be no CXF DataBinding in the process at
all. Jackson maps pojos to JSON and vica versa.
The plus side of this is that it would yield, i
it very ugly JSON. Completely impractical
> when
> reading the stuff. I can see no way to make it work in a live application.
> I
> also can't see why anyone would want this, as compared to what comes out
> of
> the Jackson provider. Which can be tuned with annotations, etc
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/ext/MessageBodyWriter.html#writeTo(T,%20java.lang.Class,%20java.lang.reflect.Type,%20java.lang.annotation.Annotation[],%20javax.ws.rs.core.MediaType,%20javax.ws.rs.core.MultivaluedMap,%20java.io.OutputStream)
type - the class of object that is
("unchecked"), well,
I'm sad but I'll stop sending email. Since my generic AegisProvider passes
tests, however, ...
On Mon, Sep 7, 2009 at 5:50 AM, Sergey Beryozkin wrote:
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/ext/MessageBodyWriter.html#writeTo(T,%20java.l
Hi
[1] +1 to b. yes it does, I haven't tried but users can wrap whatever
providers they want into their custom JAXRS providers. I'd rather do a
system test showing users they can do if they want.
possible pros : jackson will do natural JSON easily
possible cons : it's convention-based, that is
there and DataBindingJSONProvider will be able to do it
for SDO and XMLBeans too.
Will some users think Jackson is simpler/better ? No problems. But I'm
pretty sure in a number of cases there won't be a need for bringing in
Jackson for those users who are already working with CXF DataBin
complex changes.
All of this highlights a tension between 'do development in trunk and merge
back' and 'make radical changes in trunk.' Dan?
On Tue, Sep 8, 2009 at 12:04 PM, Sergey Beryozkin wrote:
Hi Benson
Revision 811687 contains both Aegis and JAXRS changes so I'd lik
Hi Benson
Revision 811687 contains both Aegis and JAXRS changes so I'd like to get it
merged to 2.2.x...
Can you let me know what other Aegis-related changes need to be merged to 2.2.x
first before the revision 811687 can be merged to 2.2.x and compiled there ?
thanks, Sergey
Hi
Have a look please at
http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/
it is indeed virtually identical to a soap based greeter demo but
the difference is here :
http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int
erface/src/main/java/org/apache/cxf/
ee
>> you are using Felix and
>> Equinox in your examples so I am assuming the answer is yes.
>> What do you guys add to such a service with the
>> cxf-dosgi-ri-singlebundle-distribution_1.0.0?
>> The reason I am asking is because I want to connect the REST servi
lines. If you have any advice on this I
> would greatly appreciate it.
>
> Thanks and regards
>
> Sergey Beryozkin wrote:
>> Hi
>>
>> Yes, we do, it is the CXF JAXRS implementation which is embedded inside
>> the
>> DOSGI RI but given that the RI is
I can't open the JIRA due to a timeout.
Yes, I've seen Josh reporting a similar issue and I did verify I could start
the cleanly build DOSGi distribution in Equinox 3.5.
I'm just thinking, can it be an ordering issue ? In the bundles list you posted
a JAXRS bundle is listed after a CXF DSW bundl
- Original Message -
From: "Sergey Beryozkin"
To:
Sent: Tuesday, September 29, 2009 3:52 PM
Subject: Re: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle
(1.1.0.SNAPSHOT) fails on startup
I can't open the JIRA due to a timeout.
Yes, I've seen Josh repor
I meant to send this message earlier on.
I've updated the 2.3-SNAPSHOT (trunk only) to depend on the jax-rs api 1.1 two
weeks ago. I'll create JIRA subtasks later on, but
the 3 JAX-RS requirements have already been implemented earlier on (sorting of
message body providers by type, support for a
I'll also have to fix http://issues.apache.org/jira/browse/CXF-2202
cheers, Sergey
- Original Message -
From: "Daniel Kulp"
To:
Sent: Tuesday, September 29, 2009 5:02 PM
Subject: 2.2.4 and 2.1.7
It's been just over 8 weeks since 2.2.3 and 2.1.6 went out. Thus, according
to or
h the specs
cheers, Sergey
- Original Message -
From: "Sergey Beryozkin"
To:
Sent: Tuesday, September 29, 2009 3:59 PM
Subject: Re: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle
(1.1.0.SNAPSHOT) fails on startup
Actually, can you please reinstall
+1
Sergey
- Original Message -
From: "Daniel Kulp"
To:
Sent: Thursday, October 08, 2009 4:22 PM
Subject: [VOTE] Release CXF 2.1.7
+1
- Original Message -
From: "Daniel Kulp"
To:
Sent: Thursday, October 08, 2009 4:26 PM
Subject: [VOTE] Release CXF 2.2.4
Hi,
I started working on a ServiceMix features pacth to do with the updates to cxf
osgi http transport last week and built a patch with 2.2.4-SNAPSHOT.
I'm hoping to submit a patch today but being stuck with the following build
failure when updated the CXF version to 2.2.4 :
INFO] -
Yep, adding cxf-common-utilities to the list of plugin dependencies fixes the
problem, thanks.
Perhaps we should add a note to the release notes or migration quide on the
wiki ? I can do it...
cheers, Sergey
- Original Message -
From: "Daniel Kulp"
To:
Cc: "Sergey B
Thanks
Sergey Beryozkin wrote:
> Hi
>
> no problems at all - your questions are welcome.
>
>
>> I know DOSGi does not run under J2ME(I tested the single distribution
and
>> it didn't go far)
>>
>
> What happened during that test ? Just curious...
ix
> without the need for
> JAX-RS annotations or the CXF libs? Felix has a full-featured HTTP
> bundlified server?
>
> Thanks
>
> Sergey Beryozkin wrote:
>> Hi
>>
>> no problems at all - your questions are welcome.
>>
>>
>>> I know DOSGi
Hi,
Issue1.
There's a custom BadgerFish provider available in the system test area :
http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/BadgerFishProvider.java
So please feel free to copy the source and use it as a custom provider in your
own pr
s type converters so JSONProviders will allow injecting them too
Also, as far as that Client/Consumer issue is concerned : you can probably just use jaxb.index (starting from 2.2.4) instead of
@XmlSeeAlso and friends
thanks, Sergey
Thank you.
Chaithanya.
- Original Message -
From: "Serg
+1
On Nov 15, 2009, at 6:07 AM, Daniel Kulp wrote:
>
> This is a vote to release CXF 2.1.8
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.7 release. Over 25 JIRA issues
> are resolved for 2.1.8
>
>
> List of issues:
>
https:/
+1
Sergey
> Forgot the list of issues:
>
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231051
1&version=12314303&styleName=Html&Create=Create
>
> Dan
>
> On Sat November 14 2009 8:09:03 pm Daniel Kulp wrote:
>
>> This is a vote to release CXF 2.2.5
>>
>> Once again, there h
Hi
Question for everyone.
What are peoples thoughts about making 2.1.9 (in January) the last of the
2.1.x line?
2.2.x will have been out for 10 months by then so users definitely should have
had plenty of time to migrate. 2.2.x is generally a simple migration from
2.1.x. I think m
Hi Andy
I've just had a chance to read the documentation you put in place, I think it is very impressive. Just CC-ing to the dev list, as
this feature is still being developed, given that CXF 2.2.6 will only be released early next year.
I have just few comments. They're more about some additio
+1
thanks, Sergey
- Original Message -
From: "Eoghan Glynn"
To:
Sent: Wednesday, November 25, 2009 5:31 PM
Subject: [VOTE] Release CXF dOSGi 1.1
Folks,
I'm calling a vote to release CXF Distributed OSGi 1.1.
The dOSGi subproject of CXF provides the Reference Implementation of th
+1
thanks, Sergey
- Original Message -
From: "Daniel Kulp"
To:
Sent: Thursday, December 03, 2009 3:48 PM
Subject: [VOTE] Cyrille Le Clerc for committer
Cyrille has submitted several patches to various management and logging
related things for CXF starting way back in Februa
Hi
Quick question about the Atom logging stuff...
Is this intended for 2.2.6 or just for 2.3? Just wondering if I need to
merge it back or not.
I was planning to backmerge the Andy's commits, just haven't had a chance yet.
I'll unblock the relevant revisions if needed
cheers, Sergey
There were a couple of System.out.println() statements printing nice feeds :-),
they've been removed now.
Note the AtomPushEngine might do System.err.println() occasionally, but I believe it is the only way AtomPushEngine can log itself,
at least at the moment. I'm not sure how feasible it is fo
Hi
Now that both JAXWS and JAXRS operations can be monitored over JMX (hope
Cyrille will confirm it later on), I reckon it would be cool to let users issue
_manage queries against individual endpoints and get an HTML view, rather than
having to launch a JConsole, ex :
GET http://myjaxwsservice
Hi,
Possibly yes for DOSGI, DOSGI RI project is a higher-level project given
that it incorporates CXF, and there is a link to the Distributed OSGi
project from the main CXF page so moving the issues part into a separate
JIRA should not affect the visibility of the project, as far as users
checking
Hi David
Author: davidb
Date: Fri Dec 18 11:16:42 2009
New Revision: 89
URL: http://svn.apache.org/viewvc?rev=89&view=rev
Log:
Added support for old way of configuring endpoint location back in. The following properties on the exposed services are now
equivalents and can be set to a va
Hi David
The endpoint.uri is a new property that's introduced in the OSGi Remote
Service Admin spec. This is now the standard way to configure the endpoint
URI. The old properties are still supported for backward compatibility.
This endpoint.uri property will work JAXRS services as well ?
If
Hi,
The jaxrs spring security system tests should be paasing now with -Pspring3, I did a minor update to the spring aop helper to ensure
double cglib proxies are handled ok...
I actully tried with updating the tests to use SpringSecurity 3.0.RC2, but I'd consider introducing SpringSecurity 3.0
Hi Cyrille
Please see comments inline
Dear all,
I am looking at the consistency of exception handling among JAX-WS
and JAX-RS. My primary goal is to ensure cxf management metrics (JMX)
are consistent.
Here are few questions :
SERVER SIDE JAXRS EXCEPTION MAPPER
Hi
Hi,
I tried to create a RestFul JSON service with CXF. The example works for GET
method. When i try the same with POST method, i get ".No operation matching
request path found" error message.
URL I hit is: http://localhost:8081/SampleRestProject/helloWorld/customers.
Find below resource c
declared as an "In Fault
Interceptor" for JAXRS endpoints (specially important for the client)
as the ClientFaultConverter tries to unmarshall a SOAP XML exception.
Cyrille
--
Cyrille Le Clerc
clecl...@xebia.fr
http://blog.xebia.fr
On Mon, Dec 21, 2009 at 6:54 PM, Sergey Beryozkin wrote
Just to let everyone know that I'm not planning to update a jax-rs version in 2.2.x but need to backmerge some of the fixes which
are also applicable to 2.2.x and which have been merged to the trunk as part of 817055
- Original Message -
From:
To:
Sent: Tuesday, December 29, 2009 3:0
Hi
I'm thinking of introducing a new rt/management-web module which will
depend on the rt/management and rt/frontend/jaxrs.
The idea is that all CXF endpoints will be able to optionally depend on
it and get :
- atom pull and push logging support with the ability to subscribe from
a /services
> S.B agreed :-)
Please tell me if it makes sense to continue to work on this,
Cyrille
(1) see org.apache.cxf.systest.jaxrs.CustomOutFaultInterceptor in jaxrs systest
On Tue, Dec 29, 2009 at 12:48 PM, Sergey Beryozkin
wrote:
>
> Hi Cyrille
>
> Thanks for posting this proposal/an
Hi
Some users have reported that the CXF HTTP OSGI transport is causing issues in
OSGI containers depending on the Spring DM 1.0.2 or earlier, due to Spring DM
eagerly loading the CXF HTTP OSGI context but failing to deal with the
(spring-)osgi-compendium related elements.
The only solution w
eptorChain simply invokes a fault MessageObserver that just
>> happens to hold a fault interceptor chain but the MessageObserver interface
>> doesn't hold such a meaning. More over, the fault chain is created on demand.
What do you think ?
thanks, Sergey
Regarding your qu
Hi Cyrille
Thanks for fixing it, a very important fix indeed and sorry for a delay in
replying to this thread.
Please see some comments inline, I'll do some snips along the way...
thanks, Sergey
Hello Sergey,
I added thread local variables cleanup in
JAXRSInInterceptor.handleFault() as yo
Hi
I'm thinking of removing the http-osgi dependency from cxf-minimal and
cxf-jaxrs bundles only.
Here're the reasons why :
1. The issue has been reported against a CXF JAX-RS bundle
2. CXF Minimal is used by DOSGi RI which uses its own (more dynamic)
approach toward allocating contexts (I'd
Hi
Hi,
I wrote a soap monitoring tool for cxf and I'd like to make it open
source. I'd like to know if it could be included in cxf package since I
think it could be useful to other cxf users.
Basically it's just two soap interceptors that store requests, responses
and some more data in a datab
t
per service which means that they don't have to share a context, but
they do share the port as they're all served by a single OSGi HTTP
Service underneath.
We don't use the http-osgi component from CXF for this AFAIK, so I
have no objection to your proposal.
Best regards,
D
+1
cheers, Sergey
On Jan 19, 2010, at 6:44 PM, Daniel Kulp wrote:
This is a vote to release CXF 2.2.6
Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.2.5 release. Over 78 JIRA issues
are resolved for 2.2.6.
List of issues:
https://is
Hi
It is possible. It has to work, you do not even has to enable it for JAXRS; for DOSGI-RI/JAX-RS it is a default databinding given
that the JAXRS spec requires the JAXB support OTB so I thought asking users to explictly add org.apache.cxf.rs.databinding=jaxb just
to enable JAXB would be too m
+1
Daniel Kulp wrote:
This is a vote to release CXF 2.1.9
Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.1.8 release. Over 43 JIRA issues
are resolved for 2.1.9
*Note:* as announced earlier this will be the last 2.1.x release of Apac
ache.cxf.rs.databinding property is handled...
thanks, Sergey
Thanks for the clarification and the impressively fast response!
Regards,
Daniel
Am 20.01.2010 um 18:20 schrieb Sergey Beryozkin:
Hi
It is possible. It has to work, you do not even has to enable it for JAXRS; for DOSGI-RI/JAX-RS it is a d
ed in the JVM?
Kind regards,
Daniel
Am 21.01.2010 um 13:01 schrieb Sergey Beryozkin:
Hi
Please see a comment with S.B
- Original Message - From: "Daniel Bimschas"
To:
Sent: Wednesday, January 20, 2010 6:07 PM
Subject: Re: JAXB and JAX-RS under CXF
Oh great thing Sergey,
Is it using a different JAXB implementation at all? And if yes, is it possible to switch to the implementation included in the
JVM?
Kind regards,
Daniel
Am 21.01.2010 um 13:01 schrieb Sergey Beryozkin:
Hi
Please see a comment with S.B
- Original Message - From: "Daniel Bi
e. Are you
interested in a tiny Maven-based project demonstrating the issue?
Am 22.01.2010 um 16:58 schrieb Sergey Beryozkin:
Hi,
please see more comments inline
just one more question. I converted a plain (non-OSGi) JAX-RS project to DOSGi-based CXF. Now, for some of my JAXB annotated
classes I get
#x27;t work.
Regards,
Daniel
Am 22.01.2010 um 17:21 schrieb Sergey Beryozkin:
Ok, great it started working for you... Do you reckon that something can actually be fixed at the DOSGI level ? If yes then
indeed, please open a DOSGI issue and attach a proj
Dan
On Wed December 30 2009 1:11:28 pm Sergey Beryozkin wrote:
Hi
I'm thinking of introducing a new rt/management-web module which will
depend on the rt/management and rt/frontend/jaxrs.
The idea is that all CXF endpoints will be able to optionally depend on
it and get :
- atom pul
Hi
That was the original "goal" of the api module, but it hasn't worked out very
well. Part of it is due to the "common-utilities" module which is really
"other api's that really should have just been part of API". Another part is
the tooling API's are completely separate as well (tools-com
are usually present by default.
Kind regards,
Daniel
Am 22.01.2010 um 17:46 schrieb Sergey Beryozkin:
Excellent, thanks. Please ping the Felix team, and I'll play with this project
too...
cheers, Sergey
- Original Message - From: "Daniel Bimschas"
To:
Sent: Friday, J
Thanks Dan, sorry about it, was too confident it was the same code on
2.2.x...
-Original Message-
From: dk...@apache.org [mailto:dk...@apache.org]
Sent: 27 January 2010 18:59
To: comm...@cxf.apache.org
Subject: svn commit: r903784 -
/cxf/branches/2.2.x-fixes/systests/jaxrs/src/test/java/o
Hi
Hi,
I have submitted the interceptor part as a patch in jira :
https://issues.apache.org/jira/browse/CXF-2641.
thanks. Personally, I'm not sure we can commit it just yet. The existing response time management feature is a light weight
component whose goal is to collect some operation sta
Hi Rémi
Hi,
I've updated CXF-2641 with a new patch (which can be applied to the
2.2.x branch or to the trunk) so that maven dependencies don't need to
be changed.
thanks for your effort. I hope you agree the code is getting much better now.
Some more comments :
- can you update ExchangeDAO t
Hi Rémi
Thanks...
Does anyone has any objections to committing the Rémi's patch ?
IMHO it makes sense to have 'helper' interceptors for users be able to persist exchange details and kind of 'break free' from JMX,
as far as the management is concerned. I've nothing against JMX , it is just about
Hi Dan
I did the JIRA issue fix in a hurry in the morning, sorry.
Your fix is a good one, thanks
Sergey
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: 05 February 2010 19:44
To: dev@cxf.apache.org
Subject: JAXRSUriInfoTest test failure...
Sergey,
The JAXRSUriI
Hi
I'd like to update the values of Message.REQUEST_URI and
Message.HTTP_REQUEST_METHOD from
"org.apache.cxf.message.Message.REQUEST_URI" and
"org.apache.cxf.message.Message.HTTP_REQUEST_METHOD" to
"org.apache.cxf.request.uri" and "org.apache.cxf.request.method" respectively.
I do not see any
Hi
I'm playing with a custom MessageObserver implementation showing how to
redirect requests to either SOAP or JAXRS endpoint
sharing a 'virtual' address, that is we have a
jaxws:endpoint/@address=/a/b and jaxrs:server/@address=/a with the JAXRS
root resource having
a '/b' @Path.
I need t
Hi Eoghan,
the resulting artifact has an OSGI Locator embedded. This may not be that bad in itself, but it includes some extra bits which
non-OSGI consumers won't need and as briefly discussed on the Jersey list, it will 'force' all OSGI users which will depend on it to
rely on a specific solut
Hi
It has been fixed :
http://svn.apache.org/viewvc?rev=909411&view=rev
I think many users do explicitly configure providers and if not then they do not see a continious growth (perhaps due to the same
threads coming in back) so noone has reported it yet...CC-ing to the users list so that user
One JMS-related test is failing on 2.2.x, I'll fix it tomorrow as I have to
sign off now...
Cheers, Sergey
Hi
I've started working on the wadl-first code generation (well not quite the
wadl-first one yet...) and I'm using the code I've 'borrowed' from the
DynamicClientFactory from cxf-rt-databinding-jaxb. At the moment I can only see
files corresponding to schema types being generated.
How can I con
ments with anonymous types if needed.
Next question : when JAXBContext generates a schema, is it possible to
configure it to optionally use anonymoos types, may work ok for cases when
types are not reused across multiple diff elements...
cheers, Sergey
- Original Message -
From: S
schema element names to type names which I'm using as a last resort to actually resolve
wadl:representation/@element...
thanks, Sergey
- Original Message -
From: "Daniel Kulp"
To:
Cc: "Sergey Beryozkin"
Sent: Wednesday, February 24, 2010 5:08 PM
Subj
Hi
My concern is that the way intents maps are loaded is the implementation detail of DSW and even though using Spring is what we use
at the moment to load them I'm feeling we should not exclude other options (to make it easier for 'interested' OSGI non-Spring aware
containers to integrate/inlc
+1
Sergey
On Tue, Mar 9, 2010 at 4:09 PM, David Bosschaert wrote:
> Hi all,
>
> I would like to propose Marc Schaaf as a committer for CXF. Marc has
> written a tremendous amount of code for CXF-DOSGi (which he provided
> as patches to JIRA), making it compliant with the OSGi 4.2 Remote
> Servi
+1
> Daniel Kulp wrote:
>
>> David's been doing a good job lately of answering questions on the mailing
>> lists and getting involved there. He's also submitted several high quality
>> patches for the ws-security and security-policy stuff. The patches are all
>> very complete with excellent un
+1 !
Sergey
On Fri, Mar 19, 2010 at 1:21 AM, Daniel Kulp wrote:
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.2.6 release. Over 55 JIRA issues
> are resolved for 2.2.7.
>
> List of issues:
>
> https://issues.apache.org/jira/secur
- Simple and lightweight Atom HTML-based browser supporting feed links
(next/previous/first/last) based on the existing CXF JAXRS WebClient API to
be added to a rt/management-web component and which will be used for
browsing the CXF logs. This browser will let users see the contents of the
current
Hi
I need to update a JAXRS JAXBElementProvider to create attachment
marshallers/unmarshallers for a xop packaging format be supported.
cxf-rt-databinding-jaxb/org.apache.cxf.jaxb.attachment has all the classes I
need but I'm not sure I should add a strong dependency on
cxf-rt-databinding-jaxb at
a need to override addSwaRefAttachment()... It is strange indeed
addSwaRefAttachment() is available at the JAXB level...
And then I'll refactor some code into AttachmentUtil in the core
cheers, Sergey
On Fri, Mar 19, 2010 at 3:26 PM, Sergey Beryozkin wrote:
> Hi
>
> I need to update a JAXR
1:40 PM, Tomasz Oponowicz <
tomasz.oponow...@gmail.com> wrote:
> Hi,
>
> I want to attend the GSOC, and get involved into open source. I chose
> project called "Simple and lightweight Atom HTML-based browser for CXF
> logs" (CXF-2736) from suggestions in JIRA . Finally I
Hi Jeffrey
thanks for resolving this issue, it's been a tricky one :-). It would be
interesting to know which JVM parameter is 'to blame'...
cheers, Sergey
On Fri, Apr 2, 2010 at 3:12 PM, Jeffrey Poore (JIRA) wrote:
>
>[
> https://issues.apache.org/jira/browse/CXF-2741?page=com.atlassian.ji
nto a FIQL query and issue a request (please see
http://sberyozkin.blogspot.com/2010/03/cxf-jaxrs-search-extensions.html).
This probably can be captured by your 'filtering' task. I'll actually need
to enhance AtomPullServer too for such queries be supported...
thanks, Sergey
>
Hi
I've been looking recently at extending the CXF WS-Security component such
that a current UsernameToken could be used by custom interceptors
to authenticate a user with the external security systems and, if possible,
provide enough information for CXF to populate a SecurityContext [1] to be
use
at 4:02 PM, Alessio Soldano wrote:
> Hi Sergey,
> needless to say, I really like this.
> Just ping me of course when you move to the JBossWS side of this topic to
> do the tests.
> Cheers
> Alessio
>
>
> Sergey Beryozkin wrote:
>
>> Hi
>>
>> I
ation *without* the callbackhandler
> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
> ).
> If you can repeat the same with CXF, great!
>
I really don't follow why you refer to Metro, what is to do with the use of
CXF ?
Sergey
>
> Glen
>
>
>
typo, missed 'not'
"I'm sorry but this does *not* sounds convincing."
On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin wrote:
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza wrote:
>
>>
>> Sergey, be careful with your first reason-
ts a simplified
UsernameTokenProcessor but ultimately it also delegates to a subclass.
Thanks for linking to that WSS4J jira. When CXF gets upgraded I can simplify
the implementation dramatically by removing a Processor impl.
hope it makes things clearer
cheers, Sergey
On Wed, Apr 7, 2010 at 5:22 PM, Sergey
Hi Glen
On Wed, Apr 7, 2010 at 6:25 PM, Glen Mazza wrote:
>
>
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza wrote:
>
> >
> > Sergey, be careful with your first reason--that of using the
> > CallbackHandlers
> > to *return* passwords, that's an old erroneous design apparently since
>
ServiceMix components
> authentication service abstraction of JAAS. Whatever solution we have for
> 1
> and 2 would help out the component if the ServiceMix authentication service
> abstraction could be wired up in lieu of whatever we provide out of the
> box.
>
>
I'
Hi Łukasz
Thanks for your proposal.
In fact, a number of users have already asked about OAuth, so I think it
will be a good enhancement. Please note SOAP users have asked as well, so as
far as the communication between the Consumer and server-side OAuth filters
is concerned, it may be worth suppor
some new cxf soap-based component supporting OpenAuth)
cheers, Sergey
2010/4/9 Sergey Beryozkin
> Hi Łukasz
>
> Thanks for your proposal.
> In fact, a number of users have already asked about OAuth, so I think it
> will be a good enhancement. Please note SOAP users have asked as
Hi
Seeing this exception when building rt/core :
Exception in thread "Thread-8" java.lang.ExceptionInInitializerError
at java.io.File.deleteOnExit(File.java:939)
at org.apache.cxf.helpers.FileUtils.delete(FileUtils.java:155)
at org.apache.cxf.helpers.FileUtils.removeDir(Fi
101 - 200 of 1543 matches
Mail list logo
