Re: Aegis versus jaxrs

to look into it anyway, I'm sure we'll a have a cool JAX-RS AegisProvider eventually :-) Cheers, Sergey P.S. I'll be on holidays for the most part of August, so I won't be able to contribute to this thread during the next month On Thu, Jul 31, 2008 at 10:23 AM, Sergey Beryozkin [EMAIL

Re: Server Response Policy

Hi I reckon it would be useful if it were possible to explicitly state in the CXF WS-Policy feature that a given policy expression is inbound/outbound only. Perhaps another option is to provide reusable policy interceptors which could simply (and blindly) assert some policies using

Re: REST header case sensitivity in CXF-2.1.2 / Tomcat AJP

Hi John Thanks for posting the patch details - can you please create a JIRA and attach the patch to it ? The patch seems ok - but I'm wondering if there're any other code paths which might be affected by the change in the AbstractHttpConnector, say in the JAX-WS runtime ? Does your code works

RE: More on server response policies

Hi I agree with what Dan suggested - logging a message in a PolicyVerificationOutInterceptor should suffice in most cases. Few more comments. I think that asserting a policy on the outbound path makes sense only if a specification for a given policy expression explicitly states that it applies

Re: More on server response policies

Hi Fred I strat thinking this message gets a bit off-track :-) Few more comments. That's fine, in that the AssertionBuilder can render a decision about what interceptors to add to the chain. But that won't solve the bug I've identified. As we've said many times what will solve this

RE: More on server response policies

Hi, I'd like to try to summarize what we've talked at this thread. Fred - please feel free to challenge what I'm about to say :-) Original problem : server-side outbound Policy interceptor assumes that no policy alternative has been asserted on the outbound path and reports a failure by

Re: Wiki JAX-RS(JSR-311) documentation

Hi , fixed now - thanks for pointing it out Cheers, Sergey There are an error on page: http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html the code: jaxrs:providers bean ref=isProvider / bean ref=longProvider / /jaxrs:providers Should be: jaxrs:providers ref

RE: [VOTE] Release CXF 2.0.9

+1 Willem Jiang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.0.9 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.9 release. Over 37 JIRA issues are resolved for 2.0.9 which is a large

RE: Aegis versus jaxrs

of AbstractJAXBProvider, or so it seems to me. Am I missing anything? Anyway, I'm going to bang something together. On Fri, Oct 10, 2008 at 12:42 PM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Sergey, I'm not feeling like I'm doing a very good job of explaining myself here. It's probably

RE: Aegis versus jaxrs

? And are we really thrilled to have it all as (mistake-prone?) name-value pairs, instead of specific bean-ish properties? I've attempted to drag Dan into this discussion so that he can tell me to stop worrying. On Mon, Oct 13, 2008 at 9:26 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Benson

Re: How to support inheritance ?

Hi, Please consider switching to jax-rs. Perhaps seeing the other cxf jax-rs pioneers struggling to make things working with our JAX-RS being involved is not very encouraging :-), it's still a better move. We'll get the JAX-RS issues sorted out eventually and I reckon that the inhertitance is

Re: Aegis versus jaxrs

Hi Benson I missed your merge email to the jax-rs module, the one introducing the AegisProvider. Even though there might still be some work left to do there, this is great nonetheless, thanks. Perhaps Aegis fans such as Dan Diephouse will notice it too :-). In CXF JAX-RS we can support 3 data

Re: [VOTE] Release Apache CXF 2.1.3 (2nd try)

+1 On Saturday 18 October 2008 11:19:14 am Willem Jiang wrote: Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.2 release. Over 52 JIRA issues are resolved for 2.1.3. List of issues:

Re: Aegis versus jaxrs

Hi, I'm getting into trouble here now that I'm debugging a test case. readFrom takes ClassObject, not Class?. I don't see how the JAXB code could work, as it will try to obtain a type for 'Object.class', Unfortunately Class? does not compile. Plain Class is passed in to it from above and it

Re: Aegis versus jaxrs

Hi, First the good news - I heroically :-) fixed the AegisTest by adding a plain old cast when passing AegisTestBean.class and your provider works perfectly well. This is how it works for JAXB too. The RI/required section of the 1.0 FR calls for a MessageBodyReader that delivers

Re: Aegis versus jaxrs

, Sergey On Tue, Oct 21, 2008 at 9:55 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi, First the good news - I heroically :-) fixed the AegisTest by adding a plain old cast when passing AegisTestBean.class and your provider works perfectly well. This is how it works for JAXB too. The RI

Re: Aegis versus jaxrs

:-) Cheers, Sergey On Tue, Oct 21, 2008 at 1:15 PM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Do you participate in the JSR Process for this thing? As the FR stands, @Provider seems to be required. I don't participate - I started working with our JAX-RS impl at the time it was at 0.5

Jetty Continuations in CXF

Hi I'd like to continue the discussion on how to handle Jetty continuations[1] in CXF[2] here. In short the requirement is for CXF to be able to handle the application code (ServiceMix JBI consumers served by ServiceMix CXF BindingComponent in this case) doing explicit continuations. Ex. CXF

Upgrade to JAX-RS 1.0

Forwarding it to the right address... Hi, I've just updated a jax-rs frontend in 2.2-SNAPSHOT trunk to support JAX-RS 1.0 [1]. The following main changes in 1.0 (some of them came from 0.9) will affect CXF JAX-RS 0.8 users : 1. ProduceMime and ConsumeMime annotations have been renamed to

Re: Jetty Continuations in CXF

No. We don't want that. Whatever we do should work for other transports as well like JMS. Thus, this shouldn't be tied to jetty continuations directly. No, I'm not suggesting to tie it up to jetty continuations. Ex. try { invoke(); // continuation.suspend() somehow by the code being

Re: Jetty Continuations in CXF

Hi No. I actually expect this to be more important for the JMS folks than the HTTP folks which is why it needs to be transport independent. Basically, MOST HTTP users expect a fairly synchronous invokation path. That's pretty much how its always been so people using HTTP, unless they

Re: Jetty Continuations in CXF

:58:08 am Sergey Beryozkin wrote: No. We don't want that. Whatever we do should work for other transports as well like JMS. Thus, this shouldn't be tied to jetty continuations directly. No, I'm not suggesting to tie it up to jetty continuations. Ex. try { invoke

Re: Jetty Continuations in CXF

, Sergey On Wed, Nov 12, 2008 at 11:21 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi, I have had a look. At the moment I don't see why we would have to do this sort of sophisticated handling of continuations in CXF JettyDestination. With CXF, it's the the code being invoked further down the line

Re: Jetty Continuations in CXF

thing. On Tue, Nov 11, 2008 at 6:51 PM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi I have 10 threads involved, 5 control ones + 5 application ones, I see a loss of message approximately once in 5 cases. The fact that cont.resume() is done virtually immediately after cont.suspend() can

Re: Jetty Continuations in CXF

Hi, Question : how will SMX CXF Binding Component interact with (Jetty) continuations when dealing with CXF-originated invocations ? The Continuation wrappers will be available through an internal CXF input Message and through JAXWS WebServiceContext (or JAXRS one later on) - will CXF BC be

Re: Jetty Continuations in CXF

Hi, Continuations support for HTTP and JMS is on the trunk now, updates to the 2.1.x/2.0.x branches will be done next. JAXRS runtime will be updated independently. http://svn.apache.org/viewvc?rev=718565view=rev Any comments - let me know please Cheers, Sergey

Re: Jetty Continuations in CXF

JAXRS runtime will be updated independently. on 2.2-SNAPSHOT, 2.1.x - the documentation to be updated shorlty. In short, if you're on Jetty and do JAXRS you can rely on CXF Continuations API, with/without JAXWS involed at the same time. Apart from doing few usual typos :-), I've also

Re: Plan for CXF 2.2

Hi 2.2-SNAPSHOT supports JAXRS 1.0 api. Things which still need to be done to claim 100% support : - complete UriBuilder implementation (some of its methods are actually supported) - GenericEntity and FormParam support - coming shortly - a couple of new methods on UriInfo - support for HTTP

JAXRS : JavaScript client code generation

Hi Benson I was wondering, how realistic could it be to have some of the code in a frontend/javascript reused to have a client java script code generated which will be able to invoke on a JAXRS service ? I reckon it would be up to a custom JAXRS RequestHandler (which has an access to a

Re: JAXRS : JavaScript client code generation

, it will all be about doing some reflection on a resource class and generating either JavaScript or some form of description, etc... Cheers, Sergey On Tue, Dec 2, 2008 at 5:48 AM, Sergey Beryozkin [EMAIL PROTECTED] wrote: Hi Benson I was wondering, how realistic could it be to have some

Re: file path after transfer in cxf

You can get it in your jaxws application like this : @Resource WebServiceContext context; HttpServletRequest request = (HttpServletRequest)context.getMessageContext() .get(MessageContext.SERVLET_REQUEST); Cheers, Sergey - Original Message - From: Gill Bates

ServletDestination and baseAdddress

Hi Is there any specific reason why ServletDestination overrides AbstractHttpDestination.getBaseAddress() ? As far as I can see ServletDestination.getBaseAddress() has a bug in that it loses part of the address, specifically, the one specified as part of (CXF)Servlet url pattern. For ex,

Re: Issue with multiple CXF servlets (and proposed fix)

Hi, Since you include ...cxf.xml in the jaxrs spring configuration file, the jaxrs endpoint can't take the already created bus of the application context into consideration. The new created jaxrs endpoint will use its own context's bus instead using the already configured bus. To fix this

Re: Jaxen dependency

Hi, javascript component uses it too. But it's the use of Javen within the Aegis component which is problematic as Aegis databinding is used by DOSGI... Benson - is there any reason why Java(x) XPath can not be used instead ? Cheers, Sergey Hi all, I noticed that there is a dependency on

Re: Jaxen dependency

? David 2009/1/2 Benson Margulies bimargul...@gmail.com: The problem here is that Aegis also uses JDOM. On Fri, Jan 2, 2009 at 6:28 AM, Sergey Beryozkin sergey.beryoz...@progress.com wrote: Hi, javascript component uses it too. But it's the use of Javen within the Aegis component which is problematic

Re: Not out of Jaxen woods ...

Hi this dependency is less critical given that the JAXRS frontend is not used by DOSGI at the moment. Also, abdera allows for a custom parser implementation (which would not depend on axiom), so that would be the way to get rid of jaxen completely Cheers, Sergey From the jaxrs frontend. +-

Proposal to deprecate CXF HTTP Binding

Hi, I'd like to propose to have CXF HTTP Binding deprecated for the following reasons : 1. It's not mantained at all 2. CXF implements JAXRS which offers superior options toward building restful services 3. It adds to the overall build time and distribution size More specifically, I'd like

Re: Proposal to deprecate CXF HTTP Binding

yet that it will be close to what HTTPBinding provides and even it will be of some reasonable quality in time for 2.2 release... Cheers, Sergey +1 to deletion from the trunk for 2.2. On Tue, Jan 20, 2009 at 11:21 AM, Sergey Beryozkin sergey.beryoz...@progress.com wrote: Hi, I'd like

Re: UriBuilder.buildFromEncoded() spec interpretation

Hi Andy Thanks for sharing your thoughts...It all looks perfectly correct to me. You might also want to consider sending queries like this one to us...@jsr311.dev.java.net for some additional feedback/clarifications... Cheers, Sergey Hi, JAX-RS specification 1.0 for

Re: CXF 2.2 release

Hi, CXF 2.2 might get released in March. As far as the JAXRS implementation is concerned, the main focus is to continue stabilizing it, support multiparts, do some work with client api, and prepare it for TCK (though given the limited time frame we might not get it TCK-certified for 2.2

JAXRS: CXF-1991 (Re: svn commit: r738937)

Hi Andy I'm commenting on the dev list after seeing my comments for CXF-1991 lost due to server maintenance issues :-). Patch has been applied - thanks a million. I also completed the implementation of UriInfo.getMatchedURIs() for the template var substitutions to be taken into account.

Re: Issues with @Context injected fields in ExceptionMapper

Hi, It's been fixed, in 2.1.4/2.2 snapshots, thanks for tracing the problem and suggesting a fix... Cheers, Sergey Tong, Gary (FID) wrote: Hello, There seem to be issues with @Context-injected fields in ExceptionMapper, where it throws an NPE with this: public class MyMapper

Re: [VOTE] Release CXF 2.0.10

+1 - Original Message - From: Daniel Kulp dk...@apache.org To: dev@cxf.apache.org Sent: Tuesday, February 03, 2009 9:27 PM Subject: [VOTE] Release CXF 2.0.10

Re: [VOTE] Release CXF 2.0.10 (Take 2)

+1 On Thu, Feb 5, 2009 at 3:27 PM, Daniel Kulp dk...@apache.org wrote: (The issue with the J2EE has been corrected. This is a new vote on the new artifacts) Since it's been about 4 months since the 2.0.9 release, I decided to go ahead and do a 2.0.10 release along with 2.1.4. This is a

Re: TOC wiki URLs fail when accessed from main CXF site

Hi Andy I've never used a {toc} macro so I can't comment. But it looks like, if we look at say http://cwiki.apache.org/CXF20DOC/jax-ws.html that a pattern which has been followed so far is to introduce an entry page which repersents the content and then each link links to a seperate

Re: TOC wiki URLs fail when accessed from main CXF site

consistently that's why anchors are broken. Personally I would prefer to make this working instead invest much more into wiki pages rework :) cheers, andy. Sergey Beryozkin-2 wrote: Hi Andy I've never used a {toc} macro so I can't comment. But it looks like, if we look at say http

Re: JSON in CXF

to provide real control over the JSON. Thanks, Gary -Original Message- From: Sergey Beryozkin [mailto:sbery...@progress.com] Sent: 10 February 2009 10:48 To: dev@cxf.apache.org Subject: Re: JSON in CXF Hi Gary JSON via JAXB definitely leaves something to be desired. Do you reckon

Re: JSON in CXF

]} Seems like the JSON is generated via JAXB and an XMLStreamWriter, which unfortunately is too limited to provide real control over the JSON. Thanks, Gary -Original Message- From: Sergey Beryozkin [mailto:sbery...@progress.com] Sent: 10 February 2009 10:48 To: dev@cxf.apache.org Subject

Re: JSON in CXF

of any jaxb-quality, annotation-driven JSON serializers? 2) Are you guys interested in replacing the existing JSON provider, or making an alternative one available that allows a bit more control over how the JSON is rendered? Thanks, Gary -Original Message- From: Sergey Beryozkin

JAXRS: Client API - feedback is needed

Hi, Some initial work has been done for CXF JAXRS have its own Client API. The code is at [1]. Some of the design goals were to come up with at least something different compared to what other JAXRS implementations have (Jersey and RestEasy), reuse the existing JAXRS classes and approaches

[VOTE] Andrzej Michalec for committer

As you all know we've been looking for people to help us with our JAXRS project for a while. We've had some great feedback and a number of patches submitted from our JAXRS users which helped us tremendously. Andrzej Michalec (Andy) has been the first user who contributed in a major way to our

Re: JSON in CXF

Hi Gary 2) Are you guys interested in replacing the existing JSON provider, or making an alternative one available that allows a bit more control over how the JSON is rendered? I'd happy to consider replacing the existing one with a better quality one if it were JAXB driven as a number of

[RESULT] Andrzej Michalec for committer

Many thanks to all those who have voted. We have 11 +1s : binding votes : sergeyb, bimargulies, willem, freeman, ulhasb, seanc, eoghan, dkulp committers : davidb, bharathg community : dsantosh Thus the vote has passed Andy - welcome to the team :-) Cheers, Sergey

Re: Sun StaX versus JAX-RS

Hi Benson I presume it's JDK 6 which needs to be used ? I'll try to look asap - I do need to close few issues raised recently against JAXRS plus do a bit of client api cleanup before 2.2 goes out. Can this test be disabled when run as part of the Psjsxp profile if it blocks you ? I'll try to

Re: Sun StaX versus JAX-RS

Ok, thanks - I'll will look into it asap Cheers, Sergey You don't need jdk 1.6. This uses a maven depedency to get the parser independently. Yes, we'll find some way to spike the test if there's no solution. On Wed, Mar 4, 2009 at 5:52 AM, Sergey Beryozkin sbery...@progress.com wrote: Hi

Re: How to replace the output stream

, we should update the AbstractOutDatatbinding to accept the same config option. Dan On Wed March 4 2009 9:01:45 am Sergey Beryozkin wrote: Hi, I'm looking at https://issues.apache.org/jira/browse/CXF-2051 at the moment. The problem is that after some initial writes to an out message's

Re: svn commit: r750522 -

ok, I guess I misinterpreted the original hint. I'll get back to it tomorrow as I'm off now, will update the AbstractOutDatabindingInterceptor to check the message instead... By the way, what is the key idea behind the message contextual property as opposed to a plain message property (set on

Re: ProviderFactory singleton?

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

Re: ProviderFactory singleton?

. 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:sbery...@progress.com] Sent: 09 March 2009 10:38 To: Daniel Kulp; dev@cxf.apache.org Subject

Re: Issue with multiple CXF servlets (and proposed fix)

I see, thanks for reminding, I remember this post. I remember Willem suggesting removing explicit import statements altogether so I kind of forgot about it straight afterwards, but I guess it didn't make any difference ? I'll check myself too. I'll definitely look into it and try to fix it asap -

Re: ProviderFactory singleton?

classloading in one fashion or another, which could cause issues. Gary -Original Message- From: Sergey Beryozkin [mailto:sbery...@progress.com] Sent: 09 March 2009 10:38 To: Daniel Kulp; dev@cxf.apache.org Subject: Re: ProviderFactory singleton? Hi, I wish someone explained me why things will get

Re: ProviderFactory singleton?

/jaxrs/JAXRSClientServerResourceCreatedSpringProviderTest.java Cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org; 'Daniel Kulp' dk...@apache.org Sent: Tuesday, March 10, 2009 12:35 PM Subject: Re: ProviderFactory singleton? Hi Gary

Re: GSoC ideas....

Few more ideas. 1. Event publication bus extension, with Atom publisher being a concrete implementation. Specifically, this publisher should be capable of posting events as Atom entries to external Atom consumers or provide them as an Atom Feed for consumers to poll. Event publisher interface

Multiple HTTP methods per method in JAXRS (Re: Possibly retarded question)

I renamed the subject a bit :-) I don't think it's a bad idea per se. JAXRS does not prohibit multiple annotations per se (AFAIK), it's just undefined what happens. In CXF the first annotation is used, if you chnage the order then POST methods will be supported. I think we can basically support

Re: Multiple HTTP methods per method in JAXRS (Re: Possibly retarded question)

Don't make Roy Fielding have to come around to your house! This is funny :-) I think if you use GET and POST on the same URI then you are innappropriately 'crossing the streams' and making it ambiguous as to whether the invocation is idempotent or not. That is true. That said, one way of

Re: Status of 2.2......

Anyone have anything else to add? Any major blockers that would hold this up any longer? (I'm hoping not) I should be ok too - will do few minor updates to the client api plus fix few other minor issues Cheers, Sergey Keep in mind, I'm then hoping to do a 2.2.1 fairly quickly (4 weeks

RE: [VOTE] Release Apache CXF 2.2

+1 -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: 15 March 2009 18:58 To: dev@cxf.apache.org Subject: [VOTE] Release Apache CXF 2.2 This is a vote to release CXF 2.2 This release is a major step forward for CXF with several new features including: *

Re: Working towards a DOSGi 1.0 release

Hi, I'm quite keen to emded a JAXRS component into DOSGI as I reckon we now have all the pieces in place (proxy based client api support, and Benson's Aegis provider) so it should, fingers crossed, be a fairly straighforward exercise - but then you never know what could actually happen at the

Re: Working towards a DOSGi 1.0 release

? If its a bit further out, why not do a DOSGi 1.0 release based on CXF 2.2 and then do another 1.1 release with the JAXRS stuff as soon as 2.2.1 is out? Cheers, David 2009/3/26 Sergey Beryozkin sbery...@progress.com: Hi, I'm quite keen to emded a JAXRS component into DOSGI as I reckon we now

Re: JSON in CXF

Hi Gary I ended up writing my own converter for JSON that uses its own annotations seperate from JAXB. It's a pretty quick implementation, and only does what I need it to do. It depends on the JSON objects from json.org, which are also included in Jettison under a different package. The

Re: JSON in CXF

for GSoC, if it's not too late to submit projects. Rewriting Sun libraries? Working with JSON? Hells yeah. Cheers, Gary -Original Message- From: Sergey Beryozkin [mailto:sbery...@progress.com] Sent: 06 April 2009 12:01 To: dev@cxf.apache.org Subject: Re: JSON in CXF Hi Gary I ended up

Re: JSON in CXF

you want to give this to someone from GSoC? This could actually be a pretty sweet project. -Original Message- From: Sergey Beryozkin [mailto:sbery...@progress.com] Sent: 07 April 2009 12:14 To: dev@cxf.apache.org Subject: Re: JSON in CXF Hi Gary If you give me until next week I should

Re: svn commit: r763339 - in /cxf/trunk: rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/CXFNonSpringJaxrsServlet.java

Thanks Dan, indeed I forgot to add one file - will do shortly cheers, Sergey - Original Message - From: dk...@apache.org To: comm...@cxf.apache.org Sent: Wednesday, April 08, 2009 7:25 PM Subject: svn commit: r763339 - in /cxf/trunk:

Re: JAX-RS test failure with IBM JDK...

Hi Dan I'm working on trying to get things building/passing with the IBM JDK again. (mostly to attempt to get the Progress AIX builds to actually succeed) I'm getting this failure in JAX-RS: testSchemeHostPortQueryFragment(org.apache.cxf.jaxrs.impl.UriBuilderImplTest) Time elapsed: 0.003

Re: svn commit: r763742 - /cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/GenericHandlerWriter.java

When running system tests, I often do mvn test -Dtest=JAXRS*, to save the time, if I'm confident no other CXF functionality has been affected by the current JAXRS related changes. I always do now 'mvn clean install' when building frontend/jaxrs, as I've already been bitten by Eclipse and Maven

Re: Distributed OSGi Discovery implementation in CXF

Hi, Hi all, Over the past while I have done some experimentation around a possible implementation of the Distributed OSGi RFC 119 Discovery service. The current CXF-DOSGi codebase only contains the Distribution Software (DSW) component, which means that you need to configure the location of

Re: [VOTE] Release CXF 2.2.1

+1 cheers, Sergey 2009/4/21 Daniel Kulp dk...@apache.org: his is a vote to release CXF 2.2.1 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.2 release. Over 55 JIRA issues are resolved for 2.2.1. List of issues:

Re: Need Help with JAX-WS and JAX-RS example

@Path(/receive) public void receive(@PathParam(*/*)String itemXML) { System.out.println(itemXML); } @Post @PathParam value is wrong. @PathParam is meant to capture tempate variable instances, for ex @Path(/receive/{item}) public void receive(@PathParam(item)

Re: [VOTE] Release CXF dOSGi 1.0

+1 - Original Message - From: Eoghan Glynn eogl...@gmail.com To: dev@cxf.apache.org Sent: Friday, May 01, 2009 5:39 PM Subject: [VOTE] Release CXF dOSGi 1.0 Folks, I'm calling a vote to release CXF Distributed OSGi 1.0. The dOSGi subproject of CXF provides the Reference

Re: [Build Error] Missing Artifact

Hi http://people.apache.org/repo/m2-incubating-repository/org/apache/abdera/abdera-i18n/0.4.0-incubating/ contains this jar - may be it was a transient error ? cheers, Sergey - Original Message - From: rahul.soa rahul@googlemail.com To: dev@cxf.apache.org Sent: Monday, May 04,

CXF JAX-RS and RestEasy (Re: 2.2.2 release real soon....)

Hi, You're probably not interested, but I thought I'd throw it out there. We're definitely very interested in more people contributing to the CXF JAX-RS implementation. We're seeing high-quailty patches being contributed to the JAX-WS runtime from JBoss folks so obviously we'll be happy to

RE: Question about the JAXRS client's schema

to configure the transport for JAXRS endpoint, such as JMS transport or local transport. BTW, I found the @serviceClass does not work for JAXRS server, and I'm heading to fix it. Willem Sergey Beryozkin wrote: Hi Willem xsd:element name=invoker type=xsd:anyType minOccurs=0/ This one is a copy

RE: Question about the JAXRS client's schema

into the schema. But in Camel cxfrs URI, I added this resourcesClasses option like this cxfrs://http://localhost:9000?resourceClasses=org.apache.camel.component .cxf.jaxrs.testbean.CustomerService Willem Sergey Beryozkin wrote: Hi William Ok, I haven't thought about it that in Camel one may want

RE: svn commit: r780421

Hi Willem Thanks for this commit, just would like to clarify one thing about one of the comments in your test : + + !-- current JAXRSClient doesn't support the modelRef + jaxrs:client id=ModuleClient + serviceClass=org.apache.cxf.jaxrs.resources.BookStoreNoAnnotations +

RE: Time to move trunk to 2.3 and create 2.2.x fixes branch...

+1 Sergey On Fri, Jun 5, 2009 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: With 2.2.2 out the door, I think it's probably time to create a 2.2.x fixes branch and move trunk to targetting 2.3. Basically, there are things that should start coming in that are more than just bug fixes

Integrating JAX-RS runtime into DOSGi

Hi I'm planning to integrate the JAX-RS runtime into DOSGi. Both JAXRS endpoints and client proxies can be created either from Spring or programmatically and they can work with JAXB, Aegis, XmlBeans. First CXF minimal bundle needs to be updated to include cxf-frontend-jaxrs and depend on

RE: Integrating JAX-RS runtime into DOSGi

a JAXRSClientFactoryBean. Should all of these client-side proxy factories implement a common interface? I'll admit to being a little lost here, as I still can't figure out the difference between JaxWsClientFactoryBean and JaxWsProxyFactoryBean :( Thanks, Josh Sergey Beryozkin wrote: Hi

Re: [VOTE] Alessio Soldano for committer

+1 cheers, Sergey Daniel Kulp wrote: Alessio has been one of the primary driving forces behind getting CXF to be a certified JAX-WS provider for JBoss. As part of that work, he has identified several bugs/issues in CXF and has provided patches for many of them. He has also been helping

Re: Integrating JAX-RS runtime into DOSGi

Hi Josh What do you think about this idea. The factory which returns handlers can check first if a given service intents include HTTP but no SOAP and a frontend.jaxrs property is set, and if yes then it returns JaxRSPojoConfigurationTypeHandler which will do what PojoConfigurationTypeHandler

Re: Integrating JAX-RS runtime into DOSGi

Hi Josh This is super, thanks for starting the actual integration project. I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled. It is embedded inside cxf-minimal-bundle (2,3-SNAPSHOT) so there's no need to update single or multi bundle distributions. Yesterday I updated

Re: Integrating JAX-RS runtime into DOSGi

pathc to do with the JAXWS support ? I will apply it and proceed from there - will just add some simple demo... thanks, Sergey Thanks, Josh On Thu, Jun 11, 2009 at 3:34 AM, Sergey Beryozkin sbery...@progress.comwrote: Hi Josh This is super, thanks for starting the actual integration project

Re: Integrating JAX-RS runtime into DOSGi

There's some uinfortunate typo in my last message, hope David won't notice it :-) - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Sent: Thursday, June 11, 2009 5:11 PM Subject: Re: Integrating JAX-RS runtime into DOSGi Hi Josh Great, I'm

RE: Integrating JAX-RS runtime into DOSGi

2009 14:20 To: dev@cxf.apache.org Subject: Re: Integrating JAX-RS runtime into DOSGi I've attached the jaxws/jaxrs/databinding patch to https://issues.apache.org/jira/browse/CXF-2252 Thanks, Josh On Fri, Jun 12, 2009 at 3:19 AM, Sergey Beryozkin sbery...@progress.comwrote: Hi, I agree

Re: JAXRS : issues with AegisProvider

with AegisProvider Like I said. Given my current level of load, if you tee it up, I'll try to knock it down. But I need something that misbehaves. I'm sorry to have to ask for that silver platter. On Wed, Jun 17, 2009 at 8:43 AM, Sergey Beryozkin sbery...@progress.comwrote: For the purpose of the demo I

Re: svn commit: r785866

Thanks Benson :-) - Original Message - From: bimargul...@apache.org To: comm...@cxf.apache.org Sent: Thursday, June 18, 2009 1:31 AM Subject: svn commit: r785866 - in /cxf/trunk/rt/frontend/jaxrs/src: main/java/org/apache/cxf/jaxrs/provider/AbstractAegisProvider.java

Re: Integrating JAX-RS runtime into DOSGi

for it (while still using DOSGi under the hood)... thanks, Sergey Josh On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin sbery...@progress.comwrote: Hi, I've applied your patch and I've completed the initial integration of JAX-RS into DOSGi RI. As it often happens I underestimated a bit

Re: Whiteboard pattern for JAX-RS services

Hi Please see my comments with prefixed with S.B. I'm not sure how CXF keeps track of these providers now, but I assume there's a registry of some kind. Are the providers tied to specific jax-rs resources, or are they global? If it's a global registry, it should be trivial to add a

Re: svn commit: r789901 - /cxf/trunk/systests/src/test/java/org/apache/cxf/systest/servlet/SpringServletTest.java

Sorry, my fault. I was under the illusion there were no servlet system tests at all :-) I turned this specific test into a negative one, given that there's another test which tests the service listings working. Now, /services becomes available to applications if a hide-service-list-page

Re: Supprot for wrapped/unwrapped styles in Mapped convention for JSON

Hi I'm not sure yet - it appears JSONProvider may need to be updated to handle unwrapped cases. Does anyone know, is it already possible to do somehow in CXF ? Perhaps one workaround is to register a RequestFilter which will replace an InputStream on the inbound message with another stream

Re: Supprot for wrapped/unwrapped styles in Mapped convention for JSON

In fact, I can probably update JSON provider to do it. If it is set to operate in 'unwrapped' mode then it will append a class name to the stream, will do it shortly cheers, Sergey Sergey Beryozkin wrote: Hi I'm not sure yet - it appears JSONProvider may need to be updated to handle

  1   2   3   4   5   6   7   8   9   10   >