Re: Schema generation issues
Hi Dan
thanks... I'm looking now at JAXBDatabinding's JAXBBeanInfo which looks like exactly what I need - I'm thinking of moving
JAXBBeanInfo and JAXBContextProxy into common/utils/jaxb as at the moment it's not quite feasible to reuse JAXBDataBinding as is
from JAX-RS due to different models. I'll be revisiting it once/if we do some WSDL2 generation
cheers, Sergey
Sergey,
On Thu July 2 2009 12:59:10 pm Sergey Beryozkin wrote:
I have problems with the JAXB schema generation.
Consider this bean :
@XmlRootElement(name=thebook, namespace=http://books;)
public class Book {
private int id;
public Book() { }
public int getId() { return id; }
public void setId(int ident) { id = ident; }
}
I think you should just add an
@XmlType(name = book, namespace=http://books;)
Attribute to it as well.The XmlRootElement defines a root element, but
doesn't do anything to specify how the type is mapped in.The XmlType
annotation does that.
Dan
JAXBContext generates these 2 schemas :
!-- Schema 1 --
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; version=1.0
targetNamespace=http://books; xs:import schemaLocation=schema2.xsd /
xs:element name=thebook type=book /
/xs:schema
!-- Schema 2 --
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; version=1.0
xs:complexType name=book
xs:sequence
xs:element name=id type=xs:int /
/xs:sequence
/xs:complexType
/xs:schema
The first problem I guess is to check if import in the first schema has
no 'namespace' attribute in which case I can have 'book' complex type
injected directly into the first schema. with the whole import being
removed. It can get quiote hairy if 'book' type improts some other types,
but it can be handled.
What I'm sure about is how to figure out that when we have say a method
public Resource() {
public Book getBook() {}
}
then how to ensure that Book is represented by {http://books}thebook
qualified name in the generated doc such as wadl...
it's not obvious to me how a link between Book and 'thebook' element can be
established given that this info (in XmlRootElement at the moment) may come
from various sources
thanks, Sergey
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
Re: Support for Json arrays
Hi,
No, we don't support yet serilalizing/deserializing explicit
collections/lists. I will attempt to fix it before 2.2.3, serializing bit at
least.
cheers, Sergey
Chaitanya-10 wrote:
Hi,
I have a JAX-RS method which takes an array of Employee objects as a
param. Employee class is given below.
@XmlRootElement
public class Employee {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
Unmarshalling of the JSON
{ employee : [ {name : abc}, {name : xyz} ] }
fails.
Does CXF support unmarshalling/marshalling of arrays?
I could not find a bug on this in the issue tracker and I am not sure if
this is a bug in CXF or Jettison. Please let me know if this issue is
already fixed in the latest release(Iam using CXF 2.2 sanpshot currently).
Thank you
Chaithanya.
--
View this message in context:
http://www.nabble.com/Support-for-Json-arrays-tp24409855p24417031.html
Sent from the cxf-dev mailing list archive at Nabble.com.
RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of
criteria. Another thing is that the JAX-RS selection algorithm does not
have be implemented literally the way it's documented in the spec,
rather the final result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to
apply a series of steps to determine which URL to use for the request.
Instead, CXF applies a path filter at the class level, and then returns
the first entry it finds. Specifically the code that does this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.EntryClassResourceInfo, MultivaluedMapString, String
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know about this.
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. We may monitor and store emails to
the extent permitted by applicable law.
RE: JAX-RS Request Matching Wierdness
Hi Gary
The thing is that JAX-RS does not allow for checking on the multiple
root resource classes - I think there was a discussion on cxf users list
about extending the selection algorithm - I don't mind if it would
actually make things simpler.
Please see few more comments prefixed with S.B below. Particularly I
don't understand why the use of subresources affects the complexity of
response objects
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 12 July 2009 11:52
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Sergey,
The problems come up in a number of situations, all involving multiple
service beans. The simplest case is the following:
public class AWebService {
@GET
@Path(/a)
public String a() {
return a;
}
}
public class BWebService {
@GET
@Path(/b)
public String b() {
return b;
}
}
One of the two will work, but not both.
This is of course the simplest case, but there are a number of other
more concrete use cases that cause issues. For instance, if I had the
following URLs:
GET /user
POST /user
GET /user/search?params
And I wanted to put the CRUD ops on UserWebService but the search stuff
on a SearchWebService that uses @Path(/{type}/search) then that
wouldn't work in CXF.
S.B :
Try
@Path(/user)
public class UserService {}
@Path(/user/)
public class SearchService {}
S.B : - note the trailing '/' in SearchService. It might do the trick
in other cases too
Also, for instance if I had the following urls:
GET /posts
GET /user
GET /user/{id}/posts
/posts would go on PostWebService and /user would go on UserWebService,
but if I wanted PostWebService to handle /user/{id}/posts as just a
specialized version of /posts that would be tricky with CXF. It's
doable with sub-resource locators, but then my response objects start
getting complicated.
S.B : I'm not quite sure why the use of subresources affects the
complexity of the response objects. Can you give an example please ?
Thanks,
Gary
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 11 July 2009 21:28
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of
criteria. Another thing is that the JAX-RS selection algorithm does not
have be implemented literally the way it's documented in the spec,
rather the final result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to
apply a series of steps to determine which URL to use for the request.
Instead, CXF applies a path filter at the class level, and then returns
the first entry it finds. Specifically the code that does this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.EntryClassResourceInfo, MultivaluedMapString, String
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know about this.
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. We may monitor and store emails to
the extent permitted by applicable law.
--
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. We may monitor and store emails to
the extent permitted by applicable law.
Re: JAX-RS Request Matching Wierdness
No problems - I've misread that part of the specification for a number of times
:-)
The spec allows for Objects or interfaces with no JAX-RS annotations classes be returned as subresources so what you suggest will
not work. That said it is something I'll keep in mind. In CXF you can set an 'enableStaticResoultion' property on a given endpoint
and it will result in a complete traversal at startup. So may be we can indeed optimize and possibly extend the selection
algorithm...
cheers, Sergey
- Original Message -
From: Tong, Gary gary.t...@morganstanley.com
To: dev@cxf.apache.org
Sent: Monday, July 13, 2009 12:09 PM
Subject: RE: JAX-RS Request Matching Wierdness
Ah nevermind. Just read the spec again and I realized that I had misread it
the first time and that CXF works as the spec says.
To be honest though, after reading the JSR the right way, the algorithm it
talks about actually seems a bit less functional than it
could be. I would think that a initial scan of all root resource classes at
startup and putting all valid resource/sub-resources
into a gigantic mapping, and then filtering that map for each request would be
a more robust way of doing things.
Anyway, thanks for looking into this.
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 12 July 2009 20:20
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
The thing is that JAX-RS does not allow for checking on the multiple root
resource classes - I think there was a discussion on cxf
users list about extending the selection algorithm - I don't mind if it would
actually make things simpler.
Please see few more comments prefixed with S.B below. Particularly I don't
understand why the use of subresources affects the
complexity of response objects
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 12 July 2009 11:52
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Sergey,
The problems come up in a number of situations, all involving multiple service
beans. The simplest case is the following:
public class AWebService {
@GET
@Path(/a)
public String a() {
return a;
}
}
public class BWebService {
@GET
@Path(/b)
public String b() {
return b;
}
}
One of the two will work, but not both.
This is of course the simplest case, but there are a number of other more
concrete use cases that cause issues. For instance, if I
had the following URLs:
GET /user
POST /user
GET /user/search?params
And I wanted to put the CRUD ops on UserWebService but the search stuff on a
SearchWebService that uses @Path(/{type}/search) then
that wouldn't work in CXF.
S.B :
Try
@Path(/user)
public class UserService {}
@Path(/user/)
public class SearchService {}
S.B : - note the trailing '/' in SearchService. It might do the trick
in other cases too
Also, for instance if I had the following urls:
GET /posts
GET /user
GET /user/{id}/posts
/posts would go on PostWebService and /user would go on UserWebService, but if
I wanted PostWebService to handle /user/{id}/posts as
just a specialized version of /posts that would be tricky with CXF. It's
doable with sub-resource locators, but then my response
objects start getting complicated.
S.B : I'm not quite sure why the use of subresources affects the
complexity of the response objects. Can you give an example please ?
Thanks,
Gary
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 11 July 2009 21:28
To: dev@cxf.apache.org
Subject: RE: JAX-RS Request Matching Wierdness
Hi Gary
So what is the concrete problem you're facing ?
FYI, it is the map that sorts resource classes according a number of criteria.
Another thing is that the JAX-RS selection algorithm
does not have be implemented literally the way it's documented in the spec,
rather the final result should be correct.
So let me know please what exactly is happening in your case
Thanks, Sergey
-Original Message-
From: Tong, Gary [mailto:gary.t...@morganstanley.com]
Sent: 11 July 2009 16:57
To: dev@cxf.apache.org
Subject: JAX-RS Request Matching Wierdness
Hello,
Hey guys, just fyi, CXF's jax-rs doesn't do request matching correctly.
According to JSR 311 in section 3.7.2, the jax-rs server is supposed to apply a
series of steps to determine which URL to use for
the request.
Instead, CXF applies a path filter at the class level, and then returns the
first entry it finds. Specifically the code that does
this is in
JAXRSUtils.selectResourceClass:
if (!candidateList.isEmpty()) {
Map.EntryClassResourceInfo, MultivaluedMapString, String
firstEntry =
candidateList.entrySet().iterator().next();
values.putAll(firstEntry.getValue());
return firstEntry.getKey();
}
Not sure if you guys know about this.
Cheers,
Gary
Re: DOSGI - problem with jax-ws
Hi I think you may need to import javax.jws.* into your service bundle. Can you give it a try please ? cheers, Sergey - Original Message - From: Björn Schütte bjo...@schuette.se To: dev@cxf.apache.org Sent: Thursday, July 16, 2009 10:39 AM Subject: DOSGI - problem with jax-ws Hi all, I have a problem getting the greeter sample to work with jax-ws frontend using the current cxf-dosgi-1.1-snapshot. The resulting wsdl is missing all type and operations definitions. I simply added he following properties to my activator: props.put(org.apache.cxf.ws.frontend, jaxws); props.put(org.apache.cxf.ws.databinding, jaxb); This results in a greeter server whos generated wsdl has no type definitions or operations. I tried adding the @WebService annotation to the impl class which did not help. Any hints? Regards Björn
Re: Support for Json arrays
I have just completed an initial work for supporting reading/writing explicit
collections or arrays.
Unfortunately, as far as JSON is concerned, only writing is supported. There
appears to be some issue at the Jettison level and we'll be trying to
identify it so that a Jettison JIRA can be opened. I'll keep you updated
Cheers, Sergey
Chaitanya-10 wrote:
Hi,
I have a JAX-RS method which takes an array of Employee objects as a
param. Employee class is given below.
@XmlRootElement
public class Employee {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
Unmarshalling of the JSON
{ employee : [ {name : abc}, {name : xyz} ] }
fails.
Does CXF support unmarshalling/marshalling of arrays?
I could not find a bug on this in the issue tracker and I am not sure if
this is a bug in CXF or Jettison. Please let me know if this issue is
already fixed in the latest release(Iam using CXF 2.2 sanpshot currently).
Thank you
Chaithanya.
--
View this message in context:
http://www.nabble.com/Support-for-Json-arrays-tp24409855p24517228.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: [OT] Fixing JAX-RS documentation
It actually does look much better now, thanks for taking care of it cheers, Sergey - Original Message - From: Daniel Kulp dk...@apache.org To: dev@cxf.apache.org Cc: Sergey Beryozkin sbery...@progress.com Sent: Friday, July 17, 2009 3:48 PM Subject: Re: [OT] Fixing JAX-RS documentation On Fri July 17 2009 9:05:09 am Sergey Beryozkin wrote: Hi, For some reasons, after Confluence has been updated, all the xml and code fragments at http://cwiki.apache.org/CXF20DOC/jax-rs.html look very messy. However, when I go into 'Edit' mode and then click 'Preview' then all is displayed perfectly well. What's going on ? Any hints will be appreciated Honestly, I'm not sure. I just re-exported the entire space and it now looks better, but still not great. We really need to get a real stylesheet and such for the website. Probably take the Camel styles and such and go with it. On my todo list. :-( -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Reusing CXF DataBindings in the JAX-RS implementation
Hi Until now it's not been possible to reuse existing CXF DataBinding implementations in CXF JAX-RS. For example, the JAX-RS impl provides its own versions of JAXB/Aegis/XMlBeans databindings by implementing JAX-RS MessageBodyProviders. Resolving this issue has been on the map for a while and we've also had a chat with Dan on IRC recently. I've just committed the initial code which makes it possible for users just to reuse the existing CXF DataBindings which is quite promising given that CXF DataBindings are very well stressed and tested. Those users who use JAXWS JAXRS will likely find it of use, as well as JAX-RS users who might spot some (temp) limitations in the CXF JAXRS message body providers. Here's how I've implemented it at the moment. If users register a databinding bean then what happens is that it will simply be wrapped as a JAXRS MessageBodyReader/Writer and registered as a JAX-RS provider. Its MessageBodyWriter.writeTo and MessageBodyWriter.readFrom delegate to DataBinding DataWriter/DataReader respectively. I think this approach works quite well but there's something I reckon may need to be improved. Particularly, in order to make JAX-RS resource classes' return/input classes for all the resource methods known to DataBinding implementations the JAXRS model classes like ClassResourceInfo OperationResourceInfo are being temporarily converted into a WSDL-centric Service/ServiceInfo/MessageInfp/etc model so that DataBinding.initialize(Service s) can be called. This in itself might become useful later on if we were to decide on supporting say WSDL2 but for the purpose of reusing the DataBindings it does not necessarily represents the best approach. It can get tricky for JAX-RS resources be represented well as WSDL-centric ones to meet different expectations of different bindings, something I found during the initial work. JAXRS resource methods might have parameters representing say queries, alongside with request bodies, etc. Perhaps the better option is for every DataBinding implementation is to have a method like setAllClasses(SetClass? classes) or setTypeInfo(MapClass?, Type info) which would represent an alternative option for initializing a databinding. Every CXF DataBinding would have to be updated slightly to use those classes instead of Service to gety initialized. JAXRS will create a required set/map and reflectively call such a method. This method might even make it into DataBinding interface if it's assumed that no users are directly interacting with DataBinding interfaces. Thoughts ? thanks, Sergey
RE: [VOTE] Release CXF 2.0.12
+1 Cheers, Sergey -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: 29 July 2009 18:36 To: dev@cxf.apache.org Subject: [VOTE] Release CXF 2.0.12 This is a vote to release CXF 2.0.12 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.11 release. Over 32 JIRA issues are resolved for 2.0.12 *Note:* as announced earlier this will be the last 2.0.x release of Apache CXF. Users are encouraged to start migrating to 2.2.x. List of issues: https://issues.apache.org/jira/browse/CXF/fixforversion/12313903 The Maven staging area is at: https://repository.apache.org/content/repositories/cxf-staging-001/ The distributions are in: https://repository.apache.org/content/repositories/cxf-staging-001/org/a pache/cxf/apache-cxf/2.0.12/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.0.12 Here is my +1. The vote will be open here for at least 72 hours. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
RE: [VOTE] Release CXF 2.2.3
+1 Cheers, Sergey -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: 29 July 2009 18:56 To: dev@cxf.apache.org Subject: [VOTE] Release CXF 2.2.3 his is a vote to release CXF 2.2.3 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.2.2 release. Over 86 JIRA issues are resolved for 2.2.3. List of issues: https://issues.apache.org/jira/browse/CXF/fixforversion/12313983 The Maven staging area is at: https://repository.apache.org/content/repositories/cxf-staging-003/ The distributions are in: https://repository.apache.org/content/repositories/cxf-staging-003/org/a pache/cxf/apache-cxf/2.2.3 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.3 Here is my +1. The vote will be open here for at least 72 hours. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
RE: [VOTE] Release CXF 2.1.6
+1 Cheers, Sergey -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: 29 July 2009 18:54 To: dev@cxf.apache.org Subject: [VOTE] Release CXF 2.1.6 This is a vote to release CXF 2.1.6 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.5 release. Over 74 JIRA issues are resolved for 2.1.6 List of issues: The Maven staging area is at: https://repository.apache.org/content/repositories/cxf-staging-002/ The distributions are in: https://repository.apache.org/content/repositories/cxf-staging-002/org/a pache/cxf/apache-cxf/2.1.6/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.6 Here is my +1. The vote will be open here for at least 72 hours. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
RE: JSON in CXF
Hi Gary
I added a simple test confirming Jettison can output the data meeting the
natural notation criteria. I thought I'd need to add a simple STAX writer
wrapper (which is something one can easily do now with JSONProvider anyway
whenever one wants to customize somehow the output being produced) but it
proved to be even simpler to achieve.
So given say Post Comment classes :
@XmlRootElement()
@XmlType(name = , propOrder = {title, comments })
public static class Post {
private String title;
private ListComment comments = new ArrayListComment();
public void setTitle(String title) {
this.title = title;
}
public String getTitle() {
return title;
}
public void setComments(ListComment comments) {
this.comments = comments;
}
public ListComment getComments() {
return comments;
}
}
public static class Comment {
private String title;
public void setTitle(String title) {
this.title = title;
}
public String getTitle() {
return title;
}
}
one can do :
JSONProvider p = new JSONProvider();
/**/
p.setSerializeAsArray(true);
p.setArrayKeys(Collections.singletonList(comments));
/**/
Post post = new Post();
post.setTitle(post);
Comment c1 = new Comment();
c1.setTitle(comment1);
Comment c2 = new Comment();
c2.setTitle(comment2);
post.getComments().add(c1);
post.getComments().add(c2);
ByteArrayOutputStream os = new ByteArrayOutputStream();
p.writeTo(post, (Class)Post.class, Post.class, Post.class.getAnnotations(),
MediaType.APPLICATION_JSON_TYPE, new MetadataMapString,
Object(), os);
which produces
{post:{title:post,comments:[{title:comment1},{title:comment2}]}}
So, when configuring JSONProvider from Spring, one should set two properties
:
* serializeAsArray = true
* arrayKeys = {comments}
arrayKeys allows to selectively nominate all the fields which need to be
serialized using a [] syntaxis
This kind of configuration is a bit low-level but it can do to get the right
output out
cheers, Sergey
Tong, Gary (IDEAS) wrote:
I think it's a limitation of the underlying JSON library. Something like:
@XmlRootElement
public class Foo {
@XmlElementWrapper(name=values)
@XmlElement(name=value)
private ListString values
}
Gives XML like:
foo
values
valuefoo/value
valuebar/value
/values
/foo
And json like:
{foo: {values: {value: [foo, bar]}}}
Whereas really, if this is an API that you want to publicize, you really
want:
{values: [foo, bar]}
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
Hi Gary
JSON via JAXB definitely leaves something to be desired.
Do you reckon it's the limitations of the underlying JSON library that we
use (Jettison) or do you refer to the insufficient number of hooks for our
JSON JAXRS reader/writer whiich would help in producing a better quality
JSON ?
Can you post some examples please - I hope it will help us to improve what
we have
Thanks, Sergey
Hi guys,
I really like how CXF provides both JSON and XML out of the box. However,
after working with the JSON serializer a bit, it's obvious that the JAXB
annotations translate poorly to JSON, and that while you have great
control over XML via JAXB, JSON via JAXB definitely leaves something to be
desired.
Do you guys know of any jaxb-quality, annotation-driven JSON serializers?
Cheers,
Gary
--
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation.
Morgan Stanley may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers. This is not
research and is not from MS Research but it may refer to a research
analyst/research report. Unless indicated, these views are the author's
and may differ from those of Morgan Stanley research or others in the
Firm. We do not represent this is accurate or complete and we may not
update this. Past performance is not indicative of future returns. For
additional information, research reports and important disclosures,
contact me or see https://secure.ms.com/servlet/cls. You should not use
e-mail to request, authorize or effect the purchase or sale of any
security or instrument, to send transfer instructions, or to effect any
other transactions. We cannot guarantee that any such requests received
via e-mail will be processed in a timely manner
Re: Reusing CXF DataBindings in the JAX-RS implementation
Hi I think what might make sense for a short term binary compatible type approach is to add a new interface like ClassSetDataBinding or something that defines the init(...) method that is needed for JAXRS. JAX-RS can then do instanceof on the databinding to see if it WILL work for it. That way, databindings that aren't designed for it, won't get picked up. We can update the databindings built into CXF so they do work. A thought I had would be to make the new init method be: void init(MapString, Object properties) where we document properties that may be set. The service model is one, the set of classes another. Are you suggesting that with properties like org.apache.cxf.databinding.classes one will be able to do : SetClass? allClasses = getAllClasses(model); ClassSetDataBinding csdb = (ClassSetDataBinding)dataBinding; csdb.init(org.apache.cxf.databinding.classes, allClasses); ? It should definitely work for JAX-RS. I'd probably opt for having 'shortcuts' for most commonly used properties by having more explicit methods like init(SetClass?) init(Service s) while retaining void init(MapString, Object properties) so csdb.init(org.apache.cxf.databinding.classes, allClasses); csdb.init(allClasses); would be equivalent. I'm ok though with having just void init(MapString, Object properties) cheers, Sergey Other things like extra schema locations, mtom related things, etc...The ReflectionServiceFactoryBean could be updated to use that method (if the databinding implements the new interface) to pass a map of all the configured endpoint properties. Thus, configuring some of the jaxb things could be simpler - just define them in jaxws:endpoint. It's also a lot more extensible in the future. Thoughts? Dan On Wed July 29 2009 7:03:15 am Sergey Beryozkin wrote: Hi Until now it's not been possible to reuse existing CXF DataBinding implementations in CXF JAX-RS. For example, the JAX-RS impl provides its own versions of JAXB/Aegis/XMlBeans databindings by implementing JAX-RS MessageBodyProviders. Resolving this issue has been on the map for a while and we've also had a chat with Dan on IRC recently. I've just committed the initial code which makes it possible for users just to reuse the existing CXF DataBindings which is quite promising given that CXF DataBindings are very well stressed and tested. Those users who use JAXWS JAXRS will likely find it of use, as well as JAX-RS users who might spot some (temp) limitations in the CXF JAXRS message body providers. Here's how I've implemented it at the moment. If users register a databinding bean then what happens is that it will simply be wrapped as a JAXRS MessageBodyReader/Writer and registered as a JAX-RS provider. Its MessageBodyWriter.writeTo and MessageBodyWriter.readFrom delegate to DataBinding DataWriter/DataReader respectively. I think this approach works quite well but there's something I reckon may need to be improved. Particularly, in order to make JAX-RS resource classes' return/input classes for all the resource methods known to DataBinding implementations the JAXRS model classes like ClassResourceInfo OperationResourceInfo are being temporarily converted into a WSDL-centric Service/ServiceInfo/MessageInfp/etc model so that DataBinding.initialize(Service s) can be called. This in itself might become useful later on if we were to decide on supporting say WSDL2 but for the purpose of reusing the DataBindings it does not necessarily represents the best approach. It can get tricky for JAX-RS resources be represented well as WSDL-centric ones to meet different expectations of different bindings, something I found during the initial work. JAXRS resource methods might have parameters representing say queries, alongside with request bodies, etc. Perhaps the better option is for every DataBinding implementation is to have a method like setAllClasses(SetClass? classes) or setTypeInfo(MapClass?, Type info) which would represent an alternative option for initializing a databinding. Every CXF DataBinding would have to be updated slightly to use those classes instead of Service to gety initialized. JAXRS will create a required set/map and reflectively call such a method. This method might even make it into DataBinding interface if it's assumed that no users are directly interacting with DataBinding interfaces. Thoughts ? thanks, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Reusing CXF DataBindings in the JAX-RS implementation
I'd prefer not to have a bunch of different init(..) methods on the interface
itself that everyone HAS to implement.
Ok, given this argument, I'm happy with having a single
void initialize(MapString, Object properties)
I guess I could've argued that perhaps only DataBindings shipped with CXF would implement such an interface thus they'd be capable
of handling specific typed methods while they'd also likely have to react somehow when seeing unsupported properties - but I reckon
we'd then need to answer the question like how many such utility methods this interface should have...So yeah, lets go for a single
loose initialize() method - it should work well,
thanks, Sergey
Basically, I think we should have:
interface PropertiesInitializedDataBinding extends Databinding {
void initialize(MapString, Object properties);
}
Then, we make our AbstractDataBinding implement that interface and add a
method like:
void initialize(MapString, Object properties) {
Service svc = properties.get(...Service);
if (svc != null) {
initialize(svc);
}
}
or similar. Other helper things (like the init(Set)) can be added to
AbstractDataBinding or similar and called from there.
Eventually (CXF 3.0), the initialize method above would get put in DataBinding
and the original one removed so only one initialize method would need to be
implemented.
I'd prefer not to have a bunch of different init(..) methods on the interface
itself that everyone HAS to implement.
Dan
On Thu July 30 2009 9:53:36 am Sergey Beryozkin wrote:
Hi
I think what might make sense for a short term binary compatible type
approach is to add a new interface like ClassSetDataBinding or
something that defines the init(...) method that is needed for JAXRS.
JAX-RS can then do instanceof on the databinding to see if it WILL work
for it. That way, databindings that aren't designed for it, won't get
picked up. We can update the databindings built into CXF so they do
work.
A thought I had would be to make the new init method be:
void init(MapString, Object properties)
where we document properties that may be set. The service model is one,
the set of classes another.
Are you suggesting that with properties like
org.apache.cxf.databinding.classes one will be able to do :
SetClass? allClasses = getAllClasses(model);
ClassSetDataBinding csdb = (ClassSetDataBinding)dataBinding;
csdb.init(org.apache.cxf.databinding.classes, allClasses);
?
It should definitely work for JAX-RS. I'd probably opt for having
'shortcuts' for most commonly used properties by having more explicit
methods like init(SetClass?) init(Service s) while retaining
void init(MapString, Object properties)
so
csdb.init(org.apache.cxf.databinding.classes, allClasses);
csdb.init(allClasses);
would be equivalent. I'm ok though with having just
void init(MapString, Object properties)
cheers, Sergey
Other things like extra schema locations, mtom
related things, etc...The ReflectionServiceFactoryBean could be
updated to use that method (if the databinding implements the new
interface) to pass a map of all the configured endpoint properties.
Thus, configuring some of the jaxb things could be simpler - just define
them in jaxws:endpoint.
It's also a lot more extensible in the future.
Thoughts?
Dan
On Wed July 29 2009 7:03:15 am Sergey Beryozkin wrote:
Hi
Until now it's not been possible to reuse existing CXF DataBinding
implementations in CXF JAX-RS. For example, the JAX-RS impl provides its
own versions of JAXB/Aegis/XMlBeans databindings by implementing JAX-RS
MessageBodyProviders.
Resolving this issue has been on the map for a while and we've also had
a chat with Dan on IRC recently.
I've just committed the initial code which makes it possible for users
just to reuse the existing CXF DataBindings which is quite promising
given that CXF DataBindings are very well stressed and tested. Those
users who use JAXWS JAXRS will likely find it of use, as well as
JAX-RS users who might spot some (temp) limitations in the CXF JAXRS
message body providers.
Here's how I've implemented it at the moment. If users register a
databinding bean then what happens is that it will simply be wrapped as
a JAXRS MessageBodyReader/Writer and registered as a JAX-RS provider.
Its MessageBodyWriter.writeTo and MessageBodyWriter.readFrom delegate to
DataBinding DataWriter/DataReader respectively.
I think this approach works quite well but there's something I reckon
may need to be improved. Particularly, in order to make JAX-RS resource
classes' return/input classes for all the resource methods known to
DataBinding implementations the JAXRS model classes like
ClassResourceInfo OperationResourceInfo are being temporarily
converted into a WSDL-centric Service/ServiceInfo/MessageInfp/etc model
so that
DataBinding.initialize(Service s) can be called.
This in itself might become useful later on if we were to decide on
supporting say
Re: Capturing the JaxRS outbound request data
Hi Eamonn Perhaps you can do the same way the (out) logging interceptor does it ? Can it capture the outbound message on the client side ? connection.getResponseCode() I thought your latest patch has fixed it ? thanks, Sergey Eamonn Dwyer-2 wrote: Hi is there a way of getting the exact stream of data sent by a JaxRS client to the service. As far as I can make out the JaxRS client populates the HttpURLConnection directly with the data and the call to connection.getResponseCode() results in the HttpURLConnection marshalling up the data and sending it on the wire. I don't see how I can get a hook to get the raw data. The issue doesn't seem to be the affect the response because in that case the JaxRSOutInterceptor comes into play and it writes the data to the CacheAndWriteOutputStream first. Thanks in advance Eamonn _ What can you do with the new Windows Live? Find out http://www.microsoft.com/windows/windowslive/default.aspx -- View this message in context: http://www.nabble.com/Capturing-the-JaxRS-outbound-request-data-tp24848337p24863892.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Reusing CXF DataBindings in the JAX-RS implementation
Will providing a set of classes be sufficient, when initializing a
DataBinding from JAX-RS ?
Should it be a map instead, for Type(s) from
Method.getGenericResponseType()
Method.getGenericResponseTypes()[index]
also be available ?
thanks, Sergey
dkulp wrote:
Basically, I think we should have:
interface PropertiesInitializedDataBinding extends Databinding {
void initialize(MapString, Object properties);
}
Then, we make our AbstractDataBinding implement that interface and add a
method like:
void initialize(MapString, Object properties) {
Service svc = properties.get(...Service);
if (svc != null) {
initialize(svc);
}
}
or similar. Other helper things (like the init(Set)) can be added to
AbstractDataBinding or similar and called from there.
Eventually (CXF 3.0), the initialize method above would get put in
DataBinding
and the original one removed so only one initialize method would need to
be
implemented.
I'd prefer not to have a bunch of different init(..) methods on the
interface
itself that everyone HAS to implement.
Dan
On Thu July 30 2009 9:53:36 am Sergey Beryozkin wrote:
Hi
I think what might make sense for a short term binary compatible type
approach is to add a new interface like ClassSetDataBinding or
something that defines the init(...) method that is needed for JAXRS.
JAX-RS can then do instanceof on the databinding to see if it WILL work
for it. That way, databindings that aren't designed for it, won't get
picked up. We can update the databindings built into CXF so they do
work.
A thought I had would be to make the new init method be:
void init(MapString, Object properties)
where we document properties that may be set. The service model is
one,
the set of classes another.
Are you suggesting that with properties like
org.apache.cxf.databinding.classes one will be able to do :
SetClass? allClasses = getAllClasses(model);
ClassSetDataBinding csdb = (ClassSetDataBinding)dataBinding;
csdb.init(org.apache.cxf.databinding.classes, allClasses);
?
It should definitely work for JAX-RS. I'd probably opt for having
'shortcuts' for most commonly used properties by having more explicit
methods like init(SetClass?) init(Service s) while retaining
void init(MapString, Object properties)
so
csdb.init(org.apache.cxf.databinding.classes, allClasses);
csdb.init(allClasses);
would be equivalent. I'm ok though with having just
void init(MapString, Object properties)
cheers, Sergey
Other things like extra schema locations, mtom
related things, etc...The ReflectionServiceFactoryBean could be
updated to use that method (if the databinding implements the new
interface) to pass a map of all the configured endpoint properties.
Thus, configuring some of the jaxb things could be simpler - just
define
them in jaxws:endpoint.
It's also a lot more extensible in the future.
Thoughts?
Dan
On Wed July 29 2009 7:03:15 am Sergey Beryozkin wrote:
Hi
Until now it's not been possible to reuse existing CXF DataBinding
implementations in CXF JAX-RS. For example, the JAX-RS impl provides
its
own versions of JAXB/Aegis/XMlBeans databindings by implementing
JAX-RS
MessageBodyProviders.
Resolving this issue has been on the map for a while and we've also
had
a chat with Dan on IRC recently.
I've just committed the initial code which makes it possible for users
just to reuse the existing CXF DataBindings which is quite promising
given that CXF DataBindings are very well stressed and tested. Those
users who use JAXWS JAXRS will likely find it of use, as well as
JAX-RS users who might spot some (temp) limitations in the CXF JAXRS
message body providers.
Here's how I've implemented it at the moment. If users register a
databinding bean then what happens is that it will simply be wrapped
as
a JAXRS MessageBodyReader/Writer and registered as a JAX-RS provider.
Its MessageBodyWriter.writeTo and MessageBodyWriter.readFrom delegate
to
DataBinding DataWriter/DataReader respectively.
I think this approach works quite well but there's something I reckon
may need to be improved. Particularly, in order to make JAX-RS
resource
classes' return/input classes for all the resource methods known to
DataBinding implementations the JAXRS model classes like
ClassResourceInfo OperationResourceInfo are being temporarily
converted into a WSDL-centric Service/ServiceInfo/MessageInfp/etc
model
so that
DataBinding.initialize(Service s) can be called.
This in itself might become useful later on if we were to decide on
supporting say WSDL2 but for the purpose of reusing the DataBindings
it
does not necessarily represents the best approach. It can get tricky
for
JAX-RS resources be represented well as WSDL-centric ones to meet
different expectations of different bindings, something I found during
How to disablle Aegis schema validation
Is there a property which can be used to disable Aegis schema validation ? thanks, Sergey -- View this message in context: http://www.nabble.com/How-to-disablle-Aegis-schema-validation-tp24920473p24920473.html Sent from the cxf-dev mailing list archive at Nabble.com.
RE: Web site look and feel....
Hi, The entry page looks good to me, it's different after all ! - though the users docs pages are still styled by Confluence. I'm quite happy with Confluence styles too but unfortunately, as you mentioned, it appears all the proper formatting is lost after a given page has been edited - at least in the JAX-RS space :-) If there was some Confluence fix available then may be we could still continue using Confluence styles, otherwise +1 to introducing new styles. cheers, Sergey -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: Tue 8/11/2009 9:22 PM To: dev@cxf.apache.org Subject: Web site look and feel I'm sure a couple of you have noticed that the upgrade that infrastructure did to confluence a few weeks ago has caused some trouble with the html export, particularly with code samples. Every time someone edits a page that contains code samples, I seem to have to re-export the entire space to fix it again. Quite annoying. One fix is to properly define our own styles and templates and such. This also has the advantage of making it look better. Basically, make it not look like a confluence space. I've copied the CXF space over to a new space (not the docs space) and have been playing with adapting the ServiceMix style sheets and layouts and such to CXF. (I like the SMX blue colors. I also played with the camel/activemq design, but I like the earth tones less) (then again, I'm VERY color blind, what the hell do I know about color?) Anyway, would everyone take a quick look at: http://cwiki.apache.org/CXFTEST/ And let me know what you think? If people are OK with it, I'll get everything switched to using it.Feel free to add/edit pages in that space to see how it would look, copy pages from the docs, etcWe can tweek it more later if need be, but I think we need to get something in place soon to work around the export issues. Thanks! -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Handling collections with Aegis in JAX-RS
Hi Benson I can't make the Aegis tests writing/reading collections working in CXF JAX-RS. I've found that AegisProviderTest#testReadWriteComplexMap is still @Ignored, it might've passed for you because it was @Ignored :-) I've also added testWriteCollections() (which writes ListAegisTestBean) to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, one of its internal classes to return ListBook. AegisJSONProvider extends AegisElementProvider, DataBindingJSONProvider extends DataBindingProvider which actually (in this case) delegates to Aegis DataBinding. AegisJSONProviderTest fails at the write time, it can't find the mapping for List. DataBindingJSONProviderTest fails early at the Aegis DataBinding initialization time for the same reason. I thought Lists were supported by default ? I haven't found any exam[le showing how a type mapping for Lists can be created. Can you please, whenever you have a chance, have a look at these tests ? thanks, Sergey
Re: How to disablle Aegis schema validation
Hi Benson I did write that test :-) That test demonstrates how CXF DataBindings can be wrapped (under the hood) into JAXRS providers. JAXB, Aegis and SDO (plus SDO JSON) are tested, I had to disable the Aegis test - I definitely did not enable the validation. Perhaps the validation is turned off when Aegis is used with SOAP ? I could not find a property which could do it... thanks, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Friday, August 14, 2009 1:58 PM Subject: Re: How to disablle Aegis schema validation I probably turned it on specifically in that test. On Fri, Aug 14, 2009 at 8:27 AM, Sergey Beryozkinsergey.beryoz...@iona.com wrote: Hi Some class path exception was reported by ab (ignorable) aegis test : http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSDataBindingTest.java I think it was coming from an Aegis validation interceptor... cheers, Sergey bimargulies wrote: It's off by default, isn't it? On Tue, Aug 11, 2009 at 11:58 AM, Sergey Beryozkinsergey.beryoz...@iona.com wrote: Is there a property which can be used to disable Aegis schema validation ? thanks, Sergey -- View this message in context: http://www.nabble.com/How-to-disablle-Aegis-schema-validation-tp24920473p24920473.html Sent from the cxf-dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/How-to-disablle-Aegis-schema-validation-tp24920473p24970904.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: How to disablle Aegis schema validation
Point me at the test. have a look please at http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSDataBindingTest.java (testGetBookAegis), endpoint with id 'aegisbook' is created here : http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/resources/jaxrs_databinding/WEB-INF/beans.xml thanks, Sergey On Thu, Aug 20, 2009 at 5:29 AM, Sergey Beryozkinsbery...@progress.com wrote: Hi Benson I did write that test :-) That test demonstrates how CXF DataBindings can be wrapped (under the hood) into JAXRS providers. JAXB, Aegis and SDO (plus SDO JSON) are tested, I had to disable the Aegis test - I definitely did not enable the validation. Perhaps the validation is turned off when Aegis is used with SOAP ? I could not find a property which could do it... thanks, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Friday, August 14, 2009 1:58 PM Subject: Re: How to disablle Aegis schema validation I probably turned it on specifically in that test. On Fri, Aug 14, 2009 at 8:27 AM, Sergey Beryozkinsergey.beryoz...@iona.com wrote: Hi Some class path exception was reported by ab (ignorable) aegis test : http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSDataBindingTest.java I think it was coming from an Aegis validation interceptor... cheers, Sergey bimargulies wrote: It's off by default, isn't it? On Tue, Aug 11, 2009 at 11:58 AM, Sergey Beryozkinsergey.beryoz...@iona.com wrote: Is there a property which can be used to disable Aegis schema validation ? thanks, Sergey -- View this message in context: http://www.nabble.com/How-to-disablle-Aegis-schema-validation-tp24920473p24920473.html Sent from the cxf-dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/How-to-disablle-Aegis-schema-validation-tp24920473p24970904.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Handling collections with Aegis in JAX-RS
Hi Benson As far as I remember writing a map (that is fixing the code) won't make a difference, I tried it when I spotted this test was still ignored... cheers, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Friday, August 21, 2009 1:34 PM Subject: Re: Handling collections with Aegis in JAX-RS Sergey, You have to be kidding me. The test (testReadWriteComplexMap) writes a plain bean and then expects to read a map. Of course if fails! --benson On Fri, Aug 21, 2009 at 6:38 AM, Sergey Beryozkinsergey.beryoz...@iona.com wrote: Hi Benson if you could look at any of these tests or at least point me in the right direction then it would be great. I know you're busy - so just look at it whenever you get a chance, not urgent... cheers, Sergey Sergey Beryozkin-2 wrote: Hi Benson I can't make the Aegis tests writing/reading collections working in CXF JAX-RS. I've found that AegisProviderTest#testReadWriteComplexMap is still @Ignored, it might've passed for you because it was @Ignored :-) I've also added testWriteCollections() (which writes ListAegisTestBean) to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, one of its internal classes to return ListBook. AegisJSONProvider extends AegisElementProvider, DataBindingJSONProvider extends DataBindingProvider which actually (in this case) delegates to Aegis DataBinding. AegisJSONProviderTest fails at the write time, it can't find the mapping for List. DataBindingJSONProviderTest fails early at the Aegis DataBinding initialization time for the same reason. I thought Lists were supported by default ? I haven't found any exam[le showing how a type mapping for Lists can be created. Can you please, whenever you have a chance, have a look at these tests ? thanks, Sergey -- View this message in context: http://www.nabble.com/Handling-collections-with-Aegis-in-JAX-RS-tp24933144p25076146.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Handling collections with Aegis in JAX-RS
Hi Benson I'm seeing all the Aegis write tests failing at the momentOr is it only me ? cheers, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Friday, August 21, 2009 5:00 PM Subject: Re: Handling collections with Aegis in JAX-RS All fixed now. I finally remembered the history of this. When you first inveigled me into working up the Aegis provider, I got as far as this test, and sent you email saying, 'OK, you fix the test, and I'll work out the rest of the kinks.' And then if you even fixed up the test I missed the email, so I never went back to it.
Re: Handling collections with Aegis in JAX-RS
I'm confused... Hudson has apparently run the build with your changes - I'll do the clean build cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Sent: Friday, August 21, 2009 6:19 PM Subject: Re: Handling collections with Aegis in JAX-RS Hmm... Still seeing them - Hudson has not run the build yet with the latest changes I've done 'mvn clean install' on rt/databinding/aegis and rt/frontend/jaxrs... By the way, I mean Aegis JAXRS tests cheers, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Friday, August 21, 2009 5:52 PM Subject: Re: Handling collections with Aegis in JAX-RS It appears to be you. I ran mvn in rt/databinding/aegis again, and still no hate mail from hudson as well. On Fri, Aug 21, 2009 at 12:39 PM, Sergey Beryozkinsbery...@progress.com wrote: Hi Benson I'm seeing all the Aegis write tests failing at the momentOr is it only me ? cheers, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Friday, August 21, 2009 5:00 PM Subject: Re: Handling collections with Aegis in JAX-RS All fixed now. I finally remembered the history of this. When you first inveigled me into working up the Aegis provider, I got as far as this test, and sent you email saying, 'OK, you fix the test, and I'll work out the rest of the kinks.' And then if you even fixed up the test I missed the email, so I never went back to it.
Re: Aegis versus JAR-RS versus XSI
Hi Benson AegisJSONProvider and DataBindingJSONProvider do set a namespace map which contain a namespace for the xsi prefix. What exactly JSON is saying ? Sergey bimargulies wrote: Now I've got problems. To make collections work in JAX-RS, I need to ensure that xsi:type gets written all the time. But JSON barfs on it. -- View this message in context: http://www.nabble.com/Aegis-versus-JAR-RS-versus-XSI-tp25085476p25086046.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Integrating JAX-RS runtime into DOSGi
Hi Have a look here please http://cxf.apache.org/distributed-osgi.html cheers, Sergey Demetris G wrote: Hey Sergei and Josh Is the DOSGi you are referring in the essay of an email below the Masters thesis I read once (and it became an open source branch of an apache project) or is this a separate design? We worked on a design calked p2pSOA the connected distributed OSGi containers over p2p technologies while exposing the endpt bundles as web services. So I am fairly interested in your discussion - I just want a quick clarification so I can position your work in my mind. Thanks On Aug 21, 2009, at 12:28 PM, Sergey Beryozkin sbery...@progress.com wrote: Hi Josh Can you please let me know if JAXB is being used for your JAX-RS endpoints ? I've spotted that for HTTP Service based JAX-RS endpoints no AegisProvider is being set - I'would actually like JAXB being used by default for JAXRS endpoints which will be consistent with the expectations of JAX-RS users in general - but I'd like to confirm first that JAXB is working ok in your case... thanks, Sergey Sergey, Thanks again for the detailed documentation you've provided in this thread. I was able to easily convert from JAX-WS to JAX-RS, which (I think) will make our lives even easier. Once we've got the ability to expose a single service with both of these frontends, I'll make use of that as well. I agree that the jaxrs.resource property is no longer needed, as you can simply register jaxrs resources as a dosgi services. Josh On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin sbery...@progress.com wrote: 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 how long it would take me to do it :-) but I'm quite happy now with what has been done so far. I haven't got a chance to write JAX-WS system tests yet - I was a bit constrained in time but judging from the code you did JAXWS/ databindings should be working nicely now - please feel free to add a system test, or either of us will do it asap. Now, the property names have actually changed and differ from those you provided in the patch. As David noted, it was recommended that DOSGI providers would use reverse domain names as prefixes to their custom configuration types, such as 'pojo' in case of DOSGI RI. Furthermore, 'pojo' was a bit constraining in that it did not reflect the fact that say SOAP or RS services were supported. Additionally, the DOSGI way is -- View this message in context: http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25086130.html Sent from the cxf-dev mailing list archive at Nabble.com.
Eclipse workspace sorts 'test' before 'main'
Hi After updating the source and rebuilding the workspace I can see 'src/test' being sorted before 'src/main'. I'm wondering, what might've caused it ? cheers, Sergey
Re: Eclipse workspace sorts 'test' before 'main'
I can't also run a JAXRS test in Eclipse which depends on AOP aspects, for some reasons aspectj is not added to the list of libraries even though it's in the list of dependencies in pom.xml... cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Sent: Wednesday, August 26, 2009 11:14 AM Subject: Eclipse workspace sorts 'test' before 'main' Hi After updating the source and rebuilding the workspace I can see 'src/test' being sorted before 'src/main'. I'm wondering, what might've caused it ? cheers, Sergey
Re: Integrating JAX-RS runtime into DOSGi
Hi Josh Thanks, this is exactly how providers are expected to be registered. http://hudson.zones.apache.org/hudson/job/CXF-DOSGi shows my changes have been picked up so it's a bug then. Have you tries the lastest build from snapshots or built the trunk yourself, including a trunk/distributuon ? I'll look into it... cheers, Sergey P.S. was about to ping you on #cxf but somehow I lost the connection - Original Message - From: Josh Holtzman jholtz...@berkeley.edu To: dev@cxf.apache.org Sent: Wednesday, August 26, 2009 5:02 PM Subject: Re: Integrating JAX-RS runtime into DOSGi Great, thanks Sergey. I just tried this, and wasn't able to read/write an arbitrary object. I've registered a MessageBodyReader and a MessageBodyWriter (actually, the same object) like so: FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter(); context.registerService(MessageBodyReader.class.getName(), fooReaderWriter, null); context.registerService(MessageBodyWriter.class.getName(), fooReaderWriter, null); I see that these services are in fact registered: --- objectClass = javax.ws.rs.ext.MessageBodyReader service.id = 41 objectClass = javax.ws.rs.ext.MessageBodyWriter service.id = 42 But when I try to access a Foo via JAX-RS, I get this: [9853...@qtp-998044-0 - /inspection/rest/foo] WARN org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body writer found for response class : Foo. Please let me know if I misunderstood the recipe for registering JAX-RS providers. I'll be out of the office until Monday, and will start digging into the CXF code to see what's going on when I return. Many thanks, Josh On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin sergey.beryoz...@iona.com wrote: Hi Josh I've updated the JAX-RS layer in DOSGi such that it will now discover JAXRS (and CXF specific providers) which have been registered as (global) OSGI services. At the moment I've decided not to use a ServiceTracker and instead a calling BundleContext is asked to exercise a filter expression which should catch JAXRS MessageBodyReader, MessageBodyWriter, ExceptionMapper, as well as CXF RequestHandler, ResponseHandler ParameterHandler. I'll attempt to optimize it later on One can disable such queries for such providers and also insist that only those global providers which have identified themselves (through a specific property) that they will work reliably with CXF can be used. Alternatively, one can register an array of service/endpoint -specific providers by using org.apache.cxf.rs.provider property, when registering an application service. Will document it tomorrow Give it a try please whenever you get a chance and let me know if it works for you cheers, Sergey Josh Holtzman wrote: Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS endpoints. Josh On Aug 21, 2009 6:28 PM, Sergey Beryozkin sbery...@progress.com wrote: Hi Josh Can you please let me know if JAXB is being used for your JAX-RS endpoints ? I've spotted that for HTTP Service based JAX-RS endpoints no AegisProvider is being set - I'would actually like JAXB being used by default for JAXRS endpoints which will be consistent with the expectations of JAX-RS users in general - but I'd like to confirm first that JAXB is working ok in your case... thanks, Sergey Sergey, Thanks again for the detailed documentation you've provided in this thread. I was ab... -- View this message in context: http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Integrating JAX-RS runtime into DOSGi
Oh, this is exactly the sort of message I was in need for in the end of the
long and difficult day :-)
Cool. If you could verify (later on today or next week when you're back) that
you could do
Dictionary props = new Hashtable();
props.put(org.apache.cxf.rs.provider, new Object[]{new FooReaderWriter()});
bundleContext.registerService(YourApplicationService.class.getName, new
YourApplicationServiceImpl(), properties);
This option will allow users to register per-service tuned FooReaderWriters, something one can do today with registering different
FooReaderWriter instances on a per-endpoint basis with jaxrs:endpoints
then it would be of help.
thanks for your help
Sergey
- Original Message -
From: Josh Holtzman jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:37 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Bah, my isReadable and isWriteable were wrong. Sorry, false alarm. This
works like a charm!
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin sbery...@progress.comwrote:
Hi Josh
Thanks, this is exactly how providers are expected to be registered.
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi
shows my changes have been picked up so it's a bug then. Have you tries the
lastest build from snapshots or built the trunk yourself, including a
trunk/distributuon ?
I'll look into it...
cheers, Sergey
P.S. was about to ping you on #cxf but somehow I lost the connection
- Original Message - From: Josh Holtzman jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:02 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Great, thanks Sergey. I just tried this, and wasn't able to read/write an
arbitrary object.
I've registered a MessageBodyReader and a MessageBodyWriter (actually, the
same object) like so:
FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
context.registerService(MessageBodyReader.class.getName(),
fooReaderWriter, null);
context.registerService(MessageBodyWriter.class.getName(),
fooReaderWriter, null);
I see that these services are in fact registered:
---
objectClass = javax.ws.rs.ext.MessageBodyReader
service.id = 41
objectClass = javax.ws.rs.ext.MessageBodyWriter
service.id = 42
But when I try to access a Foo via JAX-RS, I get this:
[9853...@qtp-998044-0 - /inspection/rest/foo] WARN
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message body
writer found for response class : Foo.
Please let me know if I misunderstood the recipe for registering JAX-RS
providers. I'll be out of the office until Monday, and will start digging
into the CXF code to see what's going on when I return.
Many thanks,
Josh
On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin
sergey.beryoz...@iona.com
wrote:
Hi Josh
I've updated the JAX-RS layer in DOSGi such that it will now discover
JAXRS
(and CXF specific providers) which have been registered as (global) OSGI
services. At the moment I've decided not to use a ServiceTracker and
instead
a calling BundleContext is asked to exercise a filter expression which
should catch JAXRS MessageBodyReader, MessageBodyWriter, ExceptionMapper,
as
well as CXF RequestHandler, ResponseHandler ParameterHandler. I'll
attempt
to optimize it later on
One can disable such queries for such providers and also insist that only
those global providers which have identified themselves (through a
specific
property) that they will work reliably with CXF can be used.
Alternatively, one can register an array of service/endpoint -specific
providers by using org.apache.cxf.rs.provider property, when
registering
an application service.
Will document it tomorrow
Give it a try please whenever you get a chance and let me know if it
works
for you
cheers, Sergey
Josh Holtzman wrote:
Hi Sergey. Yes, we are using JAXB with both JAX-RS and JAX-WS
endpoints.
Josh
On Aug 21, 2009 6:28 PM, Sergey Beryozkin sbery...@progress.com
wrote:
Hi Josh
Can you please let me know if JAXB is being used for your JAX-RS
endpoints
?
I've spotted that for HTTP Service based JAX-RS endpoints no
AegisProvider
is being set - I'would actually like JAXB being used by default for
JAXRS
endpoints which will be consistent with the expectations of JAX-RS
users
in
general - but I'd like to confirm first that JAXB is working ok in your
case...
thanks, Sergey
Sergey, Thanks again for the detailed documentation you've provided
in
this thread. I was ab...
--
View this message in context:
http://www.nabble.com/RE%3A-Integrating-JAX-RS-runtime-into-DOSGi-tp24127832p25138636.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: svn commit: r808545 -
Dan, thanks a million for merging all the jaxrs-related updates back to 2.2.x...I was planning to do it, I even updated cxf 2.2.x this morning :-) cheers, Sergey - Original Message - From: dk...@apache.org To: comm...@cxf.apache.org Sent: Thursday, August 27, 2009 6:18 PM Subject: svn commit: r808545 - in /cxf/branches/2.2.x-fixes: ./ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/ rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/ rt/frontend/jaxrs/src... Author: dkulp Date: Thu Aug 27 17:18:01 2009 New Revision: 808545 URL: http://svn.apache.org/viewvc?rev=808545view=rev Log: Merged revisions 808488 via svnmerge from https://svn.apache.org/repos/asf/cxf/trunk r808488 | sergeyb | 2009-08-27 12:17:42 -0400 (Thu, 27 Aug 2009) | 1 line JAXRS : improving the no-annotations feature Added: cxf/branches/2.2.x-fixes/systests/src/test/resources/jaxrs_non_spring/WEB-INF/resources.xml - copied unchanged from r808488, cxf/trunk/systests/src/test/resources/jaxrs_non_spring/WEB-INF/resources.xml cxf/branches/2.2.x-fixes/systests/src/test/resources/jaxrs_non_spring/WEB-INF/resources2.xml - copied unchanged from r808488, cxf/trunk/systests/src/test/resources/jaxrs_non_spring/WEB-INF/resources2.xml Modified: cxf/branches/2.2.x-fixes/ (props changed) cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/JAXRSServiceFactoryBean.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/ClassResourceInfo.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/OperationResourceInfo.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/UserOperation.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/model/UserResource.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/servlet/CXFNonSpringJaxrsServlet.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/ResourceUtils.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/main/resources/schemas/jaxrs.xsd cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/model/ClassResourceInfoTest.java cxf/branches/2.2.x-fixes/rt/frontend/jaxrs/src/test/java/org/apache/cxf/jaxrs/utils/ResourceUtilsTest.java cxf/branches/2.2.x-fixes/systests/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerNonSpringBookTest.java cxf/branches/2.2.x-fixes/systests/src/test/java/org/apache/cxf/systest/jaxrs/resources/resources.xml cxf/branches/2.2.x-fixes/systests/src/test/resources/jaxrs_non_spring/WEB-INF/web.xml cxf/branches/2.2.x-fixes/systests/src/test/resources/jaxrs_proxy/WEB-INF/beans.xml Propchange: cxf/branches/2.2.x-fixes/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Thu Aug 27 17:18:01 2009 @@ -1 +1 @@ -/cxf/trunk:782728-782730,783097,783294,783396,784059,784181-784184,784893,784895,785279-785282,785468,785621,785624,785651,785734,785866,786142,786271-786272,786395,786512,786514,786582-786583,786638,786647,786850,787200,787269,787277-787279,787290-787291,787305,787323,787366,787849,788030,788060,788187,788444,788451,788703,788752,788774,788819-788820,789013,789371,789387,789420,789527-789530,789704-789705,789788,789811,789896-789901,790074,790094,790134,790188,790294,790553,790637-790644,790868,791301,791354,791538,791753,791947,792007,792096,792183,792261-792265,792271,792604,792683-792685,792975,792985,793059,793570,794297,794396,794680,794728,794771,794778-794780,794892,795044,795104,795160,795583,795907,796022-796023,796352,796593,796741,796780,796994-796997,797117,797159,797192,797194,797231-797233,797442,797505,797517,797534,797581-797583,797587,797640,797651,797699,797882-797883,798344-798346,798363,798461,798479,798533,798551,798557,798561-798562,798570,798573,79! 858 4,798654,798748-798749,798816,798891,798929-798930,799245,799267,799439,799448,799637,799723-799724,799792,800453,800497-800498,801380-801381,801447,801962,802892,803056,803129,803419,803460,803493,803689,804002,804175,804276,805784,805907,805909,806020-806021,806023,806405-806406,806576,806602-806604,806620,806627,806631,806633,806638,806687,806876,806922,806979-806982,807181,807205,807295,807748,807807,808035,808069,808085,808107,808464
RE: Integrating JAX-RS runtime into DOSGi
Hi
I've implemented just now on the trunk. I have the unit test only
assuming that the calling BundleContext will be used to load the classes
- can you please verify it?
I'm not sure when exactly the Hudson build at
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/
Will start and finish, hopefully soon enough, tomorrow will be ready for
sure.
Alternatively please rebuild dsw/cxf-dsw and then the distribution
(single or multi) that you use...
thanks, Sergey
-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 10:38
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi
I'm using declarative services to register my endpoints, so it would be
useful for me to specify the provider property using class names rather
than
instances in the service properties. Perhaps something like this?
property name=org.apache.cxf.rs.provider
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
/property
Or is there some way to reference an object instance in DS that I'm
unaware
of?
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:45 PM, Sergey Beryozkin
sbery...@progress.comwrote:
Oh, this is exactly the sort of message I was in need for in the end
of the
long and difficult day :-)
Cool. If you could verify (later on today or next week when you're
back)
that you could do
Dictionary props = new Hashtable();
props.put(org.apache.cxf.rs.provider, new Object[]{new
FooReaderWriter()});
bundleContext.registerService(YourApplicationService.class.getName,
new
YourApplicationServiceImpl(), properties);
This option will allow users to register per-service tuned
FooReaderWriters, something one can do today with registering
different
FooReaderWriter instances on a per-endpoint basis with jaxrs:endpoints
then it would be of help.
thanks for your help
Sergey
- Original Message - From: Josh Holtzman
jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:37 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Bah, my isReadable and isWriteable were wrong. Sorry, false alarm.
This
works like a charm!
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin
sbery...@progress.com
wrote:
Hi Josh
Thanks, this is exactly how providers are expected to be registered.
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi
shows my changes have been picked up so it's a bug then. Have you
tries
the
lastest build from snapshots or built the trunk yourself, including
a
trunk/distributuon ?
I'll look into it...
cheers, Sergey
P.S. was about to ping you on #cxf but somehow I lost the connection
- Original Message - From: Josh Holtzman
jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:02 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Great, thanks Sergey. I just tried this, and wasn't able to
read/write
an
arbitrary object.
I've registered a MessageBodyReader and a MessageBodyWriter
(actually,
the
same object) like so:
FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
context.registerService(MessageBodyReader.class.getName(),
fooReaderWriter, null);
context.registerService(MessageBodyWriter.class.getName(),
fooReaderWriter, null);
I see that these services are in fact registered:
---
objectClass = javax.ws.rs.ext.MessageBodyReader
service.id = 41
objectClass = javax.ws.rs.ext.MessageBodyWriter
service.id = 42
But when I try to access a Foo via JAX-RS, I get this:
[9853...@qtp-998044-0 - /inspection/rest/foo] WARN
org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor - .No message
body
writer found for response class : Foo.
Please let me know if I misunderstood the recipe for registering
JAX-RS
providers. I'll be out of the office until Monday, and will start
digging
into the CXF code to see what's going on when I return.
Many thanks,
Josh
On Tue, Aug 25, 2009 at 7:21 PM, Sergey Beryozkin
sergey.beryoz...@iona.com
wrote:
Hi Josh
I've updated the JAX-RS layer in DOSGi such that it will now
discover
JAXRS
(and CXF specific providers) which have been registered as
(global)
OSGI
services. At the moment I've decided not to use a ServiceTracker
and
instead
a calling BundleContext is asked to exercise a filter expression
which
should catch JAXRS MessageBodyReader, MessageBodyWriter,
ExceptionMapper,
as
well as CXF RequestHandler, ResponseHandler ParameterHandler.
I'll
attempt
to optimize it later on
One can disable such queries for such providers and also insist
that
only
those global providers which have identified themselves (through a
specific
property) that they will work reliably with CXF can be used.
Alternatively, one can register an array of service/endpoint
-specific
providers by using org.apache.cxf.rs.provider property, when
RE: Integrating JAX-RS runtime into DOSGi
Missed 'would result in the array value being passed'...
-Original Message-
From: Sergey Beryozkin [mailto:sbery...@progress.com]
Sent: 31 August 2009 13:10
To: dev@cxf.apache.org
Subject: RE: Integrating JAX-RS runtime into DOSGi
Ok, I didn't know
property name=org.apache.cxf.rs.provider
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
/property
I'll look more into it...
Thanks, Sergey
-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 13:04
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi
This works when specifying a single property, but not as an array. In
other
words, this is fine:
property name=org.apache.cxf.rs.provider
value=org.whatever.MyJaxRsReaderWriter /
but this does not work:
property name=org.apache.cxf.rs.provider
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
/property
I seem to recall a general CXF issue with array properties in DS, so
this
may be completely unrelated to the JAX-RS stuff.
Thanks,
Josh
On Mon, Aug 31, 2009 at 1:35 PM, Sergey Beryozkin
sbery...@progress.comwrote:
Hi
I've implemented just now on the trunk. I have the unit test only
assuming that the calling BundleContext will be used to load the
classes
- can you please verify it?
I'm not sure when exactly the Hudson build at
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/
Will start and finish, hopefully soon enough, tomorrow will be ready
for
sure.
Alternatively please rebuild dsw/cxf-dsw and then the distribution
(single or multi) that you use...
thanks, Sergey
-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 10:38
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi
I'm using declarative services to register my endpoints, so it would
be
useful for me to specify the provider property using class names
rather
than
instances in the service properties. Perhaps something like this?
property name=org.apache.cxf.rs.provider
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
/property
Or is there some way to reference an object instance in DS that I'm
unaware
of?
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:45 PM, Sergey Beryozkin
sbery...@progress.comwrote:
Oh, this is exactly the sort of message I was in need for in the end
of the
long and difficult day :-)
Cool. If you could verify (later on today or next week when you're
back)
that you could do
Dictionary props = new Hashtable();
props.put(org.apache.cxf.rs.provider, new Object[]{new
FooReaderWriter()});
bundleContext.registerService(YourApplicationService.class.getName,
new
YourApplicationServiceImpl(), properties);
This option will allow users to register per-service tuned
FooReaderWriters, something one can do today with registering
different
FooReaderWriter instances on a per-endpoint basis with
jaxrs:endpoints
then it would be of help.
thanks for your help
Sergey
- Original Message - From: Josh Holtzman
jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:37 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Bah, my isReadable and isWriteable were wrong. Sorry, false alarm.
This
works like a charm!
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin
sbery...@progress.com
wrote:
Hi Josh
Thanks, this is exactly how providers are expected to be
registered.
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi
shows my changes have been picked up so it's a bug then. Have you
tries
the
lastest build from snapshots or built the trunk yourself,
including
a
trunk/distributuon ?
I'll look into it...
cheers, Sergey
P.S. was about to ping you on #cxf but somehow I lost the
connection
- Original Message - From: Josh Holtzman
jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:02 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Great, thanks Sergey. I just tried this, and wasn't able to
read/write
an
arbitrary object.
I've registered a MessageBodyReader and a MessageBodyWriter
(actually,
the
same object) like so:
FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
context.registerService(MessageBodyReader.class.getName(),
fooReaderWriter, null);
context.registerService(MessageBodyWriter.class.getName(),
fooReaderWriter, null);
I see that these services are in fact registered:
---
objectClass = javax.ws.rs.ext.MessageBodyReader
service.id = 41
objectClass = javax.ws.rs.ext.MessageBodyWriter
service.id = 42
But when I try to access a Foo via JAX-RS, I get
RE: Integrating JAX-RS runtime into DOSGi
Hi Josh
This should be fixed now. I've confirmed it by running the
locally-modified greeter_rest demo on Eclipse Equinox with its DS
service implementation... Unit test has also been there. Now, Equinox DS
passes a Spring[] so at the moment I'm assuming that it has to be String
array, as opposed to Object[].
Given that DS is likely implemented by Equinox only it should work just
fine.
Can you confirm it's working for you (after the build has been done) ?
So we have 3 options now for registering providers :
- registering providers as OSGI services
- providing an array of provider instances as an application service
property
- using declarative services
I'm not sure it is worth investigating the option of class-scanning the
application bundle - it would be more expensive. But may be I will later
on...
Thanks, Sergey
-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 13:04
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi
This works when specifying a single property, but not as an array. In
other
words, this is fine:
property name=org.apache.cxf.rs.provider
value=org.whatever.MyJaxRsReaderWriter /
but this does not work:
property name=org.apache.cxf.rs.provider
org.whatever.MyJaxRsReaderWriter,
org.whatever.SomeOtherReaderOrWriter
/property
I seem to recall a general CXF issue with array properties in DS, so
this
may be completely unrelated to the JAX-RS stuff.
Thanks,
Josh
On Mon, Aug 31, 2009 at 1:35 PM, Sergey Beryozkin
sbery...@progress.comwrote:
Hi
I've implemented just now on the trunk. I have the unit test only
assuming that the calling BundleContext will be used to load the
classes
- can you please verify it?
I'm not sure when exactly the Hudson build at
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi/
Will start and finish, hopefully soon enough, tomorrow will be ready
for
sure.
Alternatively please rebuild dsw/cxf-dsw and then the distribution
(single or multi) that you use...
thanks, Sergey
-Original Message-
From: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of
Josh Holtzman
Sent: 31 August 2009 10:38
To: dev@cxf.apache.org
Subject: Re: Integrating JAX-RS runtime into DOSGi
I'm using declarative services to register my endpoints, so it would
be
useful for me to specify the provider property using class names
rather
than
instances in the service properties. Perhaps something like this?
property name=org.apache.cxf.rs.provider
org.whatever.FooXmlReaderWriter,
org.whatever.SomeOtherReaderOrWriter
/property
Or is there some way to reference an object instance in DS that I'm
unaware
of?
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:45 PM, Sergey Beryozkin
sbery...@progress.comwrote:
Oh, this is exactly the sort of message I was in need for in the end
of the
long and difficult day :-)
Cool. If you could verify (later on today or next week when you're
back)
that you could do
Dictionary props = new Hashtable();
props.put(org.apache.cxf.rs.provider, new Object[]{new
FooReaderWriter()});
bundleContext.registerService(YourApplicationService.class.getName,
new
YourApplicationServiceImpl(), properties);
This option will allow users to register per-service tuned
FooReaderWriters, something one can do today with registering
different
FooReaderWriter instances on a per-endpoint basis with
jaxrs:endpoints
then it would be of help.
thanks for your help
Sergey
- Original Message - From: Josh Holtzman
jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:37 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Bah, my isReadable and isWriteable were wrong. Sorry, false alarm.
This
works like a charm!
Thanks,
Josh
On Wed, Aug 26, 2009 at 6:16 PM, Sergey Beryozkin
sbery...@progress.com
wrote:
Hi Josh
Thanks, this is exactly how providers are expected to be
registered.
http://hudson.zones.apache.org/hudson/job/CXF-DOSGi
shows my changes have been picked up so it's a bug then. Have you
tries
the
lastest build from snapshots or built the trunk yourself,
including
a
trunk/distributuon ?
I'll look into it...
cheers, Sergey
P.S. was about to ping you on #cxf but somehow I lost the
connection
- Original Message - From: Josh Holtzman
jholtz...@berkeley.edu
To: dev@cxf.apache.org
Sent: Wednesday, August 26, 2009 5:02 PM
Subject: Re: Integrating JAX-RS runtime into DOSGi
Great, thanks Sergey. I just tried this, and wasn't able to
read/write
an
arbitrary object.
I've registered a MessageBodyReader and a MessageBodyWriter
(actually,
the
same object) like so:
FooXmlReaderWriter fooReaderWriter = new FooXmlReaderWriter();
context.registerService(MessageBodyReader.class.getName(),
fooReaderWriter, null
Re: Seeming JAX-RS mistake
Hi Benson
This interface is meant to be used with types like JAXBContext or (JAXB)
Marshaller, I think it was introduced to let users overcome the issues with the
existing JAXB releases, for some specific types be handled by custom context
providers. For ex, JAXB providers would check if ContextResolverJAXBContext
was registered and then, say, ContextResolver.getContext(Foo.class) will be
called.
I think that in CXF if it were say CollectionFoo then a registered
ContextResolverJAXBContext, if any, would not be asked for a JAXBContext for
CollectionFoo but for Foo only
cheers, Sergey
- Original Message -
From: Benson Margulies
To: Sergey Beryozkin ; CXF Dev
Sent: Tuesday, September 01, 2009 12:26 AM
Subject: Seeming JAX-RS mistake
This can't work right for generic types (like collections), since it doesn't
use java.lang.reflect.Type.
public interface ContextResolverT {
/**
* Get a context of type codeT/code that is applicable to the supplied
* type.
* @param type the class of object for which a context is desired
* @return a context for the supplied type or codenull/code if a
* context for the supplied type is not available from this provider.
*/
T getContext(Class? type);
}
Re: WARNING: very big commit coming later today....
Hi Dan Did you finish the part 3 of this refactoring ? I'm setting up a custom JAXRS project in Eclipse and I still have to add a wsdl4j library to the list of dependencies though I've been able to drop quite a few dependencies compared to a similar project I set up earlier... Just in case, here is what I'm seeing : Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory' defined in class path resource [META-INF/cxf/cxf-extension-http-jetty.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: javax/wsdl/Port at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:480) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409) at java.security.AccessController.doPrivileged(Native Method) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164) at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:881) at org.apache.cxf.bus.spring.SpringBeanLocator.loadBeansOfType(SpringBeanLocator.java:72) at org.apache.cxf.transport.TransportFinder.loadAll(TransportFinder.java:138) at org.apache.cxf.transport.TransportFinder.findTransportForURI(TransportFinder.java:84) at org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFactoryForUri(DestinationFactoryManagerImpl.java:133) at org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpointInfo(AbstractJAXRSFactoryBean.java:102) at org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.createEndpoint(AbstractJAXRSFactoryBean.java:168) at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:83) cheers, Sergey dkulp wrote: OK. Part 1 (I have more ideas) is in. A default bus has gone from over 55 beans created and initialized down to 12. Startup time for the first Bus has dropped from 2.1 seconds on my machine to 0.9. After the jit warms up and classes loaded and such, subsequent Bus creation has dropped from 105ms to about 60. Obviously, a default bus isn't much use now as nothing is loaded and doing pretty much anything is going to start triggering other parts to load in. Thus, a full startup isn't as dramatic, but it's definitely a good start. Dan On Tue August 25 2009 9:40:37 am Daniel Kulp wrote: Just a warning, if I can get all the tests passing, I have a big commit coming in today (although broken across a couple commits that will all come at once) that touches a LOT of stuff. Basically, I'm trying to reduce the startup time. Specifically, the BusFactory.createDefaultBus() time.I've done some investigation and discovered a few things that are taking a lot of time: 1) JSR250 processing - this is actually fairly expensive the first time. Retrieving annotations is expensive and the JSR250 has to look at every field and method. The second time a class is used it's fast (cached), but that initial startup sucks. I've added a NoJSR250Annotations annotation that can be added to beans loaded from Spring to mark the class as not having any JSR250 annotations anywhere on it so the JSR250 processor can skip it. I've added this annotation to a bunch of places where it can be added. (not all beans can have it, obviously) This alone has about a 20% boost. 2) JAXB context creations - the JAXB based WSDL extensors are creating their JAXB context up front. If those extensors are never used (example: never use the CORBA binding) it's a pointless waste of time. I'm changing them to create them only if needed for parsing/writing. , 3) lazy-init=true - I'm going through all the cxf-extension-*.xml files and adding lazy-init=true to almost everything. I'm also updating other code to pull beans if needed. This has a huge affect of lower the number of beans created at startup. Right now, a default bus creates 57 beans up front, right away (and every one is run through the JSR250 processor).With some changes, I now have this down to 20 beans (and I think I
Re: svn commit: r809790 [1/3]
Hi Benson Are you planning to have AegisDatabinding supporting the PropertiesAwareDataBinding interface ? Or does 'padb' mean something else...I've looked at the source but AegisDatabinding is not implementing it yet. If you decide to implement it then JAXRS will pass MapClass, Type but it can pass SetType if it is what AegisDatabinding needs... thanks, Sergey - Original Message - From: bimargul...@apache.org To: comm...@cxf.apache.org Sent: Tuesday, September 01, 2009 2:13 AM Subject: svn commit: r809790 [1/3] - in /cxf/trunk/rt: databinding/aegis/src/main/java/org/apache/cxf/aegis/ databinding/aegis/src/main/java/org/apache/cxf/aegis/databinding/ databinding/aegis/src/main/java/org/apache/cxf/aegis/type/ databinding/aegis/src/main/... Author: bimargulies Date: Tue Sep 1 01:13:06 2009 New Revision: 809790 URL: http://svn.apache.org/viewvc?rev=809790view=rev Log: Merge branch 'aegispadb' into trunk
Failing JMS Continuations test (Was : Re: Back to normal.....)
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 started in the in-process mode, all the 5 client threads get their expected responses back after firing at the same time but it fails as soon as the Server2 is launched in a seperate process... Not quite sure yet what does it indicate at... cheers, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Failing JMS Continuations test (Was : Re: Back to normal.....)
After messing with setting up a logger for an out-process server (logging.properties were ignored after setting a java.util.logging.config.file property in a server launcher properties, perhaps there's some contention teher between the EmbeddedBroker and Server2 for the same file handler, not really sure), I found that if there was just a single client thread doing an invocation then the test would pass and the server would log/confirm the continuations were successfully created/suspended/etc from inside the application code. Having just 2 client threads results in no invocations coming into the application code at all - sounds like a configuration issue leading to the rejection or even the deadlock...Does anyone have the idea what might be going on ? Here is the config file : http://svn.apache.org/repos/asf/cxf/trunk/systests/uncategorized/src/test/java/org/apache/cxf/systest/jms/continuations/jms_test_config.xml (check the bean with id='jmsConf1', in my local snapshot I increased the values for (max)ConcurrentConsumers) I don't see what other config properties may need to be added (http://cxf.apache.org/docs/using-the-jmsconfigfeature.html) Just for the record here's the client test code : http://svn.apache.org/repos/asf/cxf/trunk/systests/uncategorized/src/test/java/org/apache/cxf/systest/jms/continuations/HelloWorldContinuationsClientServerTest.java and the service one : http://svn.apache.org/repos/asf/cxf/trunk/systests/uncategorized/src/test/java/org/apache/cxf/systest/jms/continuations/HelloWorldWithContinuationsJMS.java cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org Cc: Benson Margulies bimargul...@gmail.com Sent: Thursday, September 03, 2009 11:41 AM Subject: Failing JMS Continuations test (Was : Re: Back to normal.) 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 started in the in-process mode, all the 5 client threads get their expected responses back after firing at the same time but it fails as soon as the Server2 is launched in a seperate process... Not quite sure yet what does it indicate at... cheers, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
RE: Failing JMS Continuations test (Was : Re: Back to normal.....)
Thanks Dan for finding the actual issues with the ConduitSelector. One thing this test has confirmed is that the way JMS continuations are handled on the server side is pretty rock solid... Cheers, Sergey -Original Message- From: Daniel Kulp [mailto:dk...@apache.org] Sent: 03 September 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 worse on 2.2.x/2.1.x due to some additional thread safety issues in the JMSConduit on those branches. (trunk has a completely updated conduit that doesn't suffer the problem) Anyway, I'm hoping the next round of hudson builds will be good. :-) Dan On Thu September 3 2009 6:41:03 am Sergey Beryozkin wrote: 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 started in the in-process mode, all the 5 client threads get their expected responses back after firing at the same time but it fails as soon as the Server2 is launched in a seperate process... Not quite sure yet what does it indicate at... cheers, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: Handling collections with Aegis in JAX-RS
Hi Benson JSON has no idea of what namespaces so it needs to map namespaces to something, hence the need for a namespace map being setup. In simple cases it's now being done automatically... cheers, Sergey bimargulies wrote: Sergey, I've made it as far as the namespace issues with JSON, since the changes I've made to deal with generic types have made them worse. There's something here that I just don't follow. When the output is XML, all the namespaces just take care of themselves. Aegis assigns prefixes and 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 On Mon, Aug 24, 2009 at 8:58 AM, Sergey Beryozkin sergey.beryoz...@iona.com wrote: Hi Benson Thanks for spending your time on these tests, and fixing CXF 2401. I was also able to add few more tests, including the one which writes/reads a complex Map to/from JSON. AegisJSONProvider tries its best for users to avoid setting up a namespace map manually, but in cases when it does not guess properly the users would be able to overwrite namespaces and their prefixes as needed. This isssue would likely arise on the read side only, when CXF reads it. JSON is namespace-unaware so when reading, one needs to setup a namespace map for Jettison to report values like @ns1.bar to the JAXB reader... (but only if AegisJSONProvider has not guessed how to map prefixes to namespaces) There's a couple of issues I'd like to discuss. First one is that AegisJsonProviderTest.testReadWriteComplexMap does have to setup a namespace for a map root element, but it does not have to do it for testWrite/ReadCollection tests. I'm wondering, can it be avoided in cases when Maps are being written/read ? That is, can we modify createReader/Writer methods such that QNames for containers like Map/Collections and its member types are available ? Another one is that DataBindingJSONProvider test (aegis tests) still can not handle collections. I think the problem there is that when DataBindingProvider (the one DataBindingJSONProvider extends) is being initialized, it uses a workaround which we discussed in the other thread. Namely, it attempts to convert a JAXRS model info into WSDL-like one and set calls DataBinding.initialize(Service). It's quite limiting for a number of reasons, and one of them is that the generic types are not visible to data bindings So we introduced PropertiesAwareDataBinding interface and I've just updated the JAXRS code to call it like this : MapClass?, Type allClasses = getAllJAXRSResponseInputTypes(); MapString, Object props = new HashMapString, Object(); props.put(PropertiesAwareDataBinding.TYPES_PROPERTY, allClasses); ((PropertiesAwareDataBinding)db).initialize(props); At the moment no CXF DataBindings implement this newly introduced interface. I think the only way for DataBindingJSONProvider aegis tests which handle collections to start passing is for Aegis DataBinding to implement PropertiesAwareDataBinding and initialize itself using the provided MapClass?, Type, as opposed to Service. Would you be open to updating the Aegis databinding ? thanks, Sergey bimargulies wrote: I have a rather clear memory of working on these, there wasn't enough passing of Generic classes around. I'll go have a look. On Fri, Aug 21, 2009 at 6:38 AM, Sergey Beryozkinsergey.beryoz...@iona.com wrote: Hi Benson if you could look at any of these tests or at least point me in the right direction then it would be great. I know you're busy - so just look at it whenever you get a chance, not urgent... cheers, Sergey Sergey Beryozkin-2 wrote: Hi Benson I can't make the Aegis tests writing/reading collections working in CXF JAX-RS. I've found that AegisProviderTest#testReadWriteComplexMap is still @Ignored, it might've passed for you because it was @Ignored :-) I've also added testWriteCollections() (which writes ListAegisTestBean) to AegisJSONProviderTest. I also updated DataBindingJSONProviderTest, one of its internal classes to return ListBook. AegisJSONProvider extends AegisElementProvider, DataBindingJSONProvider extends DataBindingProvider which actually (in this case) delegates to Aegis DataBinding. AegisJSONProviderTest fails at the write time, it can't find the mapping for List. DataBindingJSONProviderTest fails early at the Aegis DataBinding initialization time for the same reason. I thought Lists were supported by default ? I haven't found any exam[le showing how a type mapping for Lists can be created. Can you please, whenever you have a chance, have a look at these tests ? thanks, Sergey -- View this message in context: http://www.nabble.com/Handling
RE: Possible alternative source of JSON
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...@gmail.com] Sent: 05 September 2009 22:40 To: CXF Dev Subject: Possible alternative source of JSON 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, if successful, 'natural' json, unencrusted with namespace glop, in both directions. The minus side of this would be that it doesn't help those people who want a JSON JAX-RS endpoint as a sort of instant side-effect of their preexisting stack of JAXB @nnotations or Aegis XML files or whatever. Personally, I think that I'd be coding something a whole lot more useful by adding this than by putting more lipstick on the pig of producing and consuming extremely ugly JSON via Aegis. Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already does the job, why do all that work? Not to mention the fact that Tatu is likely to prove responsive in case of need.
Re: Possible alternative source of JSON
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, if successful, 'natural' json, unencrusted with namespace glop, in both directions. The minus side of this would be that it doesn't help those people who want a JSON JAX-RS endpoint as a sort of instant side-effect of their preexisting stack of JAXB @nnotations or Aegis XML files or whatever. Personally, I think that I'd be coding something a whole lot more useful by adding this than by putting more lipstick on the pig of producing and consuming extremely ugly JSON via Aegis. Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already does the job, why do all that work? Let me ask you the other question. If users have already done Aegis, why would they want to bring in Jackson ? 'unqualified' Aegis will do exactly what they want too, as far as dealing with explicit collections/maps is concerned cheers, Sergey Not to mention the fact that Tatu is likely to prove responsive in case of need.
Re: JAX-RS and generics
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 to be written. So I don't think we should pass Object.class for MessageBodyWriterObject. If one would like to avoud doing casts during testing then it should be just MessageBodyWriterBook and I'm pretty sure the runtime will pass Book.class. Cheers, Sergey On Sat, Sep 5, 2009 at 1:57 PM, Benson Margulies bimargul...@gmail.comwrote: JAX-RS defines two fundamental interfaces: MessageBodyReaderT and MessageBodyWriterT, and providers implement. I claim that GENERIC providers that work for any object (like those corresponding to data bindings) should, themselves, be GENERIC, and implement MessageBodyXT, not MessageBodyXObject. Allow me to modulate this claim. I thought about it some more. If you want to define a class as 'implements MessageBodyXObject', fine. However, the right thing to pass to the ClassT argument will ALWAYS be Object.class. If you want to cue in the code to the sort of object in flight, use the Type argument further down the parameter list. I claim this because the whole API structure of MessageBodyX assumed this. It uses ClassT in a way that requires constant @SupressWarnings(unchecked) if the base is MessageBodyXObject. To put my money where my mouth is, as it were, I implemented this for the Aegis providers. When I did this, I discovered that the JAX-RS runtime code couldn't handle generic type providers. When the provider type is, say, AegisElementProviderBook then implemented interface comes up as MessageBodyReaderT, not MessageBodyReaderBook. So it is a TypeVariable, not a class or a ParameterizedType. I fixed the provider selection code to cope, but I didn't write the additionally complex code to look at bounds and insist that if there is a bound the type at hand be within it.
Re: JAX-RS and generics
Hi Benson In MessageBodyWriter.writeTo() it's actually Class? which is in the signature. And there's no return value. We could've implemented just MessageBodyWriter as opposed to MessageBodyWriterObject but it would stiill cause warning in the user test code I can agree that implementing MessageBodyWriterObject delegates the type-safety checks to the actual provider and thus makes that T thing useless. But for providers choosing to implement MessageBodyWriterBook the runtime will now ensure the class of the object to be written is assignable to Book.class (now that we've implemented the message body provides sorting requirement from JAXRS 1.1). Please don't get me wrong, may be it would be the best option indeed to go ahead with passing Object.class MessageBodyWriterObject - but I'm afraid it will turn the bunch of user providers out there broken... thanks, Sergey - Original Message - From: Benson Margulies bimargul...@gmail.com To: dev@cxf.apache.org Sent: Monday, September 07, 2009 1:06 PM Subject: Re: JAX-RS and generics Sergey, With Java generics, there's a pattern: T public T gloop(ClassT type, whatever) That pattern requires that you pass in the class of what you expect to get out. If XXXProvider implements MessageBodyReaderT, then it must have a implement the read API against the same T. You can't, legitimately, cast it to MessageBodyReaderBook. So, if AegisProvider implements MessageBodyReaderObject, and you want to write clean code that does not get warnings, you have to write: Object o = p.read(Object.class, ...) If it implements MessageBodyReaderT, you then AegisProviderBook does Book b = p.read(Book.class, ...) Now, if the people who invented JAX-RS have decided to ignore this pattern and force us to write code that needs @SuppressWarning(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 sbery...@progress.comwrote: 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)https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/ext/MessageBodyWriter.html#writeTo%28T,%20java.lang.Class,%20java.lang.reflect.Type,%20java.lang.annotation.Annotation%5B%5D,%20javax.ws.rs.core.MediaType,%20javax.ws.rs.core.MultivaluedMap,%20java.io.OutputStream%29 type - the class of object that is to be written. So I don't think we should pass Object.class for MessageBodyWriterObject. If one would like to avoud doing casts during testing then it should be just MessageBodyWriterBook and I'm pretty sure the runtime will pass Book.class. Cheers, Sergey On Sat, Sep 5, 2009 at 1:57 PM, Benson Margulies bimargul...@gmail.com wrote: JAX-RS defines two fundamental interfaces: MessageBodyReaderT and MessageBodyWriterT, and providers implement. I claim that GENERIC providers that work for any object (like those corresponding to data bindings) should, themselves, be GENERIC, and implement MessageBodyXT, not MessageBodyXObject. Allow me to modulate this claim. I thought about it some more. If you want to define a class as 'implements MessageBodyXObject', fine. However, the right thing to pass to the ClassT argument will ALWAYS be Object.class. If you want to cue in the code to the sort of object in flight, use the Type argument further down the parameter list. I claim this because the whole API structure of MessageBodyX assumed this. It uses ClassT in a way that requires constant @SupressWarnings(unchecked) if the base is MessageBodyXObject. To put my money where my mouth is, as it were, I implemented this for the Aegis providers. When I did this, I discovered that the JAX-RS runtime code couldn't handle generic type providers. When the provider type is, say, AegisElementProviderBook then implemented interface comes up as MessageBodyReaderT, not MessageBodyReaderBook. So it is a TypeVariable, not a class or a ParameterizedType. I fixed the provider selection code to cope, but I didn't write the additionally complex code to look at bounds and insist that if there is a bound the type at hand be within it.
Re: Restating some JAX-RS debates
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 it thinks that json has to follow the natural convention; and having Aegis users who are working with Map/List based interfaces to download jackson seems a bit harsh - in OSGI they'll also need to install another bundle [3] +1 to 'unqualified' Aegis for JSON but only when users have asked for it. I think it is a better solution than bringing a new dependency to CXF. Basically, if users are working with existing CXF DataBindings then they should be given an option to use then for creating JSON. So DataBindingJSONProvider can be told to produce 'unqualified' JSON in all cases (for Aegis, SDO, XMLBeans, etc). Not sure how it will work for cases when derived types are returned when Base is expected Sergey bimargulies wrote: I am hoping to attract some comments from other members of the community by gathering a few threads of debate between Sergey and myself in one place. If I misrepresent his side of these arguments I'm sure he'll let me know. I also plan to ask some questions on the user list. [1] The default JSON provider. I've been comparing the Jackson JSON provider to the JSONProvider in CXF. I see three possibilities: [a] Deprecate ours in favor of theirs [b] Document the fact that Jackson works with CXF and write up the tradeoffs. [c] Do nothing. I would like to see us at least take door [b]. Our JSONProvider has some issues: it consists of a combination of JAXB and Jettison. The latter has bugs that keep coming up. The former poses issues for some users, or so I am told. Jackson has some advantages, I think. The most notable is an annotation model that is small and straightforward for JSON production and consumptin. [2] The role of data binding providers. I can see why users would find a lot of value in the data binding providers when their content type is XML. The existing data bindings are all in the XML business; their various controls and options are all relevant. Work users put into setting them up is largely relevant, it not always sufficient (e.g. @XmlRootElement requirements). However, I think that there are caveats that deserve discussion in our documentation. Marking a transient property to be ignore, that's good all around. A production schema, on the other hand, may well have XML constructs that are not friendly to some sort of simple Javascript client. When we get to JSON, however, I'm much more skeptical. Even without the various bugs encountered in Jettison, the JSON you get when you push a complex pile of XML into Jettison is pretty convoluted. I offer a sort of a reduction argument: if the interface is a simple one, then no one needs a complex data binding, and if it is a complex one, expecting to use what comes out of the data binding + Jettison is likely to run into trouble. I'm not proposing to delete any code here, just to set expectations. [3] The role of Aegis in all of this Aegis has turned into a central point in these issues for several reasons. First, we put effort into making Aegis work with JAX-RS, so that people who wanted to avoid JAXB had an alternative. Then we noticed that Aegis always produces 'qualified' schemas. Then we noticed that Jettison's model of namespace management doesn't work for this purpose. It requires a static mapping of namespaces to prefixes, rather than a dynamic mapping as in XML itself. So, my view is that we should push Jackson as a solution to a JAXB-less mapping from Java to and from JSON. The alternative would be to invent 'unqualified' Aegis. (a) I don't know if I have time, (b) I fear that it will only expose a next layer of things people don't like, like the extra layer of elements in Aegis maps. Sergey is unpersuaded. Anybody else care to toss an opinion into the right? If someone else wants to jump on an option to make Aegis unqualified, don't think for a moment that I'll protest. -- View this message in context: http://www.nabble.com/Restating-some-JAX-RS-debates-tp25329761p25333768.html Sent from the cxf-dev mailing list archive at Nabble.com.
RE: D-OSGi and REST
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/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
Re: D-OSGi and REST
Hi Yes, we do, it is the CXF JAXRS implementation which is embedded inside the DOSGI RI but given that the RI is based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see 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 service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: 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/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks -- View this message in context: http://www.nabble.com/D-OSGi-and-REST-tp25572370p25635554.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: D-OSGi and REST
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... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same 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 based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see 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 service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: 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/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks -- View this message in context: http://www.nabble.com/D-OSGi-and-REST-tp25572370p25645394.html Sent from the cxf-dev mailing list archive at Nabble.com.
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 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 bundle. That probably should not make a difference but apparently java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) causes some early resolution ? Can you please uninstall CXF-DSW bundle and then install it again, so that it definitely has JAXRS classes available to it ? Another possibility is that some of the system bundles have say Jersey embedded ? thanks, Sergey - Original Message - From: Aaron Zeckoski (JIRA) j...@apache.org To: iss...@cxf.apache.org Sent: Tuesday, September 29, 2009 3:39 PM Subject: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup [ https://issues.apache.org/jira/browse/CXF-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated CXF-2452: Description: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); was: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup --- Key: CXF-2452 URL: https://issues.apache.org/jira/browse/CXF-2452 Project: CXF Issue Type: Bug Components: Distributed-OSGi Affects Versions: dOSGi-1.1 Environment: adz20:~ azeckoski$ java -version java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) Reporter: Aaron Zeckoski Priority: Critical Fix For: dOSGi-1.1 One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup
Actually, can you please reinstall [ 27] [Active ] [4] Apache CXF Bundle Jar (2.3.0.SNAPSHOT) and [ 29] [Resolved ] [4] CXF Distributed Software Bundle (1.1.0.SNAPSHOT) Oh...Apache CXF Bundle Jar (2.3.0.SNAPSHOT). It actually depends on jaxrs-api 1.1 now. I'm presuming you've replaced CXF-2.2.3 with the latest one. So then please uninstall [ 45] [Active ] [2] Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0) and install http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.1/ it should make a difference. cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org 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 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 bundle. That probably should not make a difference but apparently java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) causes some early resolution ? Can you please uninstall CXF-DSW bundle and then install it again, so that it definitely has JAXRS classes available to it ? Another possibility is that some of the system bundles have say Jersey embedded ? thanks, Sergey - Original Message - From: Aaron Zeckoski (JIRA) j...@apache.org To: iss...@cxf.apache.org Sent: Tuesday, September 29, 2009 3:39 PM Subject: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup [ https://issues.apache.org/jira/browse/CXF-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated CXF-2452: Description: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); was: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup --- Key: CXF-2452 URL: https://issues.apache.org/jira/browse/CXF-2452 Project: CXF Issue Type: Bug Components: Distributed-OSGi Affects Versions: dOSGi-1.1 Environment: adz20:~ azeckoski$ java -version java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) Reporter: Aaron Zeckoski Priority: Critical Fix For: dOSGi-1.1 One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JAXRS : moving to JAX-RS 1.1 api
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 'fromString' method plus new Request method). Should have it all supported in time for 2.3 (not sure about the optional EJB requirement though - will welcome contributions). More updartes to come later on. If you're playing with multi-bundle DOSGI distributions and replacing a shipped 2.2.3 bundle with 2.3-SNAPSHOT then please make sure http://repository.apache.org/snapshots/org/apache/servicemix/specs/org.apache.servicemix.specs.jsr311-api-1.1/1.4-SNAPSHOT/ is installed instead of org.apache.servicemix.specs.jsr311-api-1.0 A corresponding Maven dependency is here : dependency groupIdorg.apache.servicemix.specs/groupId artifactIdorg.apache.servicemix.specs.jsr311-api-1.1/artifactId version1.4-SNAPSHOT/version /dependency Sergey Hi, Now that we have CXF JAX-RS passing TCK for jax-rs 1.0 api, it's time to start thinking about updating the jax-rs api dependency to 1.1. The following changes might affect existing users : 1. javax.ws.rs.core.Response.Status.Family class has been removed and instead javax.ws.rs.core.Response.StatusType javax.ws.rs.core.Response.StatusType.Family have been added 2. As a result of 1, - public static javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response.status(javax.ws.rs.core.Response.Status) - public javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response.ResponseBuilder.status(javax.ws.rs.core.Response.Status) - public final javax.ws.rs.core.Response.Status.Family javax.ws.rs.core.Response.Status.getFamily() have been removed and instead - public static javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response.status(javax.ws.rs.core.Response.StatusType) - public javax.ws.rs.core.Response.ResponseBuilder javax.ws.rs.core.Response$ResponseBuilder.status(javax.ws.rs.core.Response.StatusType) - public final java.lang.String javax.ws.rs.core.Response.Status.getReasonPhrase() - public final javax.ws.rs.core.Response.StatusType.Family javax.ws.rs.core.Response.Status.getFamily() have been added. 3. new method javax.ws.rs.core.Response$ResponseBuilder javax.ws.rs.core.Request.evaluatePreconditions() has been added to Request interface So in summary: if you haven't used javax.ws.rs.core.Response.Status.Family or Response.status(Response.Status) or ResponseBuilder.status(Response.Status) then your application code won't be affected. If you have used Request helper befor then you'd only need to recompile but not change the code. Let me know please, by replying to this thread or pinging me on #cxf or directly if the above changes will affect you. If no users will have their (production) code affected then I see no reasons in postponing the move to jax-rs 1.1 api Thanks, Sergey [1] https://jsr311.dev.java.net/drafts/changelog.1.1.html
Re: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup
As it happens, the current jsr311-api 1.1 specs is missing a factory finder so the patch will be applied to it in the next few days, and I've sent Aaron a locally build jar... Aaron, Josh - thanks for experimenting with the latest and greatest bundles :-) and helping to spot the issue with the specs cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org 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 [ 27] [Active ] [4] Apache CXF Bundle Jar (2.3.0.SNAPSHOT) and [ 29] [Resolved ] [4] CXF Distributed Software Bundle (1.1.0.SNAPSHOT) Oh...Apache CXF Bundle Jar (2.3.0.SNAPSHOT). It actually depends on jaxrs-api 1.1 now. I'm presuming you've replaced CXF-2.2.3 with the latest one. So then please uninstall [ 45] [Active ] [2] Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0) and install http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.1/ it should make a difference. cheers, Sergey - Original Message - From: Sergey Beryozkin sbery...@progress.com To: dev@cxf.apache.org 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 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 bundle. That probably should not make a difference but apparently java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) causes some early resolution ? Can you please uninstall CXF-DSW bundle and then install it again, so that it definitely has JAXRS classes available to it ? Another possibility is that some of the system bundles have say Jersey embedded ? thanks, Sergey - Original Message - From: Aaron Zeckoski (JIRA) j...@apache.org To: iss...@cxf.apache.org Sent: Tuesday, September 29, 2009 3:39 PM Subject: [jira] Updated: (CXF-2452) DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup [ https://issues.apache.org/jira/browse/CXF-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Zeckoski updated CXF-2452: Description: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); was: One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup --- Key: CXF-2452 URL: https://issues.apache.org/jira/browse/CXF-2452 Project: CXF Issue Type: Bug Components: Distributed-OSGi Affects Versions: dOSGi-1.1 Environment: adz20:~ azeckoski$ java -version java version 1.6.0_15 Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) Reporter: Aaron Zeckoski Priority: Critical Fix For: dOSGi-1.1 One of the DOSGI bundles is failing to startup using Felix 2.0 as the container The exception and ps info from felix will be added in comments Here is the log of the attempt to startup and the exception at the end: http://pastebin.com/m4da7142 Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor called here is never actually reached. JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release CXF 2.1.7
+1 Sergey - Original Message - From: Daniel Kulp dk...@apache.org To: dev@cxf.apache.org Sent: Thursday, October 08, 2009 4:22 PM Subject: [VOTE] Release CXF 2.1.7
Re: [VOTE] Release CXF 2.2.4
+1 - Original Message - From: Daniel Kulp dk...@apache.org To: dev@cxf.apache.org Sent: Thursday, October 08, 2009 4:26 PM Subject: [VOTE] Release CXF 2.2.4
Build problems with CXF 2.2.4 in ServiceMix
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]
[INFO] Building Apache ServiceMix CXF Transport for NMR
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set: D:\Work\ServiceMix\features\cxf\cxf-transport-nmr\targ
et (included: [**], excluded: [])
[INFO] [cxf-common-xsd:xsdtojava {execution: generate-sources}]
[FATAL ERROR] org.apache.cxf.maven_plugin.XSDToJavaMojo#execute() caused a linka
ge error (java.lang.NoClassDefFoundError) and may be out-of-date. Check the real
ms:
[FATAL ERROR] Plugin realm = app0.child-container[org.apache.cxf:cxf-common-xsd:
2.2.4]
urls[0] = file:/D:/Work/ServiceMix/m2/org/apache/cxf/cxf-common-xsd/2.2.4/cxf-co
mmon-xsd-2.2.4.jar
urls[1] = file:/D:/Work/ServiceMix/m2/com/sun/xml/bind/jaxb-xjc/2.1.12/jaxb-xjc-
2.1.12.jar
urls[2] = file:/D:/Work/ServiceMix/m2/com/sun/xml/bind/jaxb-impl/2.1.12/jaxb-imp
l-2.1.12.jar
urls[3] = file:/D:/Work/ServiceMix/m2/javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.j
ar
urls[4] = file:/D:/Work/ServiceMix/m2/org/apache/geronimo/specs/geronimo-activat
ion_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar
urls[5] = file:/D:/Work/ServiceMix/m2/ant/ant/1.6.5/ant-1.6.5.jar
urls[6] = file:/D:/Work/ServiceMix/m2/ant/ant-nodeps/1.6.5/ant-nodeps-1.6.5.jar
urls[7] = file:/D:/Work/ServiceMix/m2/org/codehaus/plexus/plexus-utils/1.1/plexu
s-utils-1.1.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] = file:/D:/Work/apache-maven-2.2.1/bin/../lib/maven-2.2.1-uber.jar
Tried with Maven 2.2.1 and earlier versions...
What may be causing it ?
thanks, Sergey
Re: Build problems with CXF 2.2.4 in ServiceMix
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 dk...@apache.org
To: dev@cxf.apache.org
Cc: Sergey Beryozkin sbery...@progress.com
Sent: Tuesday, October 13, 2009 3:35 PM
Subject: Re: Build problems with CXF 2.2.4 in ServiceMix
Hmm
It looks like by removing common-utilities from the deps, we lost the stax-api
from the deps of the plugin. That's not good. :-(
If you add a stax-api (and maybe an impl like woodstox) to the dependencies,
that might work. Can you give that a try?
Dan
On Tue October 13 2009 5:27:05 am Sergey Beryozkin wrote:
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]
[INFO] Building Apache ServiceMix CXF Transport for NMR
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean {execution: default-clean}]
[INFO] Deleting file set:
D:\Work\ServiceMix\features\cxf\cxf-transport-nmr\targ et (included: [**],
excluded: [])
[INFO] [cxf-common-xsd:xsdtojava {execution: generate-sources}]
[FATAL ERROR] org.apache.cxf.maven_plugin.XSDToJavaMojo#execute() caused a
linka ge error (java.lang.NoClassDefFoundError) and may be out-of-date.
Check the real ms:
[FATAL ERROR] Plugin realm =
app0.child-container[org.apache.cxf:cxf-common-xsd: 2.2.4]
urls[0] =
file:/D:/Work/ServiceMix/m2/org/apache/cxf/cxf-common-xsd/2.2.4/cxf-co
mmon-xsd-2.2.4.jar
urls[1] =
file:/D:/Work/ServiceMix/m2/com/sun/xml/bind/jaxb-xjc/2.1.12/jaxb-xjc-
2.1.12.jar
urls[2] =
file:/D:/Work/ServiceMix/m2/com/sun/xml/bind/jaxb-impl/2.1.12/jaxb-imp
l-2.1.12.jar
urls[3] =
file:/D:/Work/ServiceMix/m2/javax/xml/bind/jaxb-api/2.1/jaxb-api-2.1.j ar
urls[4] =
file:/D:/Work/ServiceMix/m2/org/apache/geronimo/specs/geronimo-activat
ion_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar
urls[5] = file:/D:/Work/ServiceMix/m2/ant/ant/1.6.5/ant-1.6.5.jar
urls[6] =
file:/D:/Work/ServiceMix/m2/ant/ant-nodeps/1.6.5/ant-nodeps-1.6.5.jar
urls[7] =
file:/D:/Work/ServiceMix/m2/org/codehaus/plexus/plexus-utils/1.1/plexu
s-utils-1.1.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] = file:/D:/Work/apache-maven-2.2.1/bin/../lib/maven-2.2.1-uber.jar
Tried with Maven 2.2.1 and earlier versions...
What may be causing it ?
thanks, Sergey
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
RE: D-OSGi and REST
Hi, it is possible to execute bundles as RESTful resources on Felix without the need for JAX-RS annotations Yes with DOSGI RI... or the CXF libs? Quite possibly - but it will not be DOSGI RI then which will be used. Cheers, Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 21 October 2009 05:08 To: dev@cxf.apache.org Subject: Re: D-OSGi and REST Hi Sergey, it is possible to execute bundles as RESTful resources on Felix 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 does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same 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 based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see 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 service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: 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/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose bundles/beans as SOAP and REST services. I looked over the example listed on the D-OSGi web site but both Greeter examples are the same for SOAP and REST - unless I am missing something. Do you have any examples of RESTful bundles? Thanks
RE: D-OSGi and REST
Yes. Some information about the annotation-free mode is here : http://cxf.apache.org/docs/jax-rs.html#JAX-RS-RESTfulserviceswithoutanno tations cheers, Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 21 October 2009 05:17 To: dev@cxf.apache.org Subject: Re: D-OSGi and REST I think this is what you meant here probably with 'no annotations' .. and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml Demetris wrote: Hi Sergey, it is possible to execute bundles as RESTful resources on Felix 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 does not run under J2ME(I tested the single distribution and it didn't go far) What happened during that test ? Just curious... I haven't worked with J2ME so I don't have any recommendations, sorry... cheers, Sergey Demetris-2 wrote: Sergey one more question if you don't mind - you probably saw some of my earlier postings with Benson regarding running Web Services on mobiles. I can easily run KF or Equinox on mobiles and I can run some SOAP-based engines (ksoap-osgi) and open source Web Servers. I am leaning towards running REST-based services on mobiles - I know DOSGi does not run under J2ME (I tested the single distribution and it didn't go far) so I am hoping to follow another avenue along the same 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 based on CXF it's probably can be expected. But DOSGi is an open spec. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. You should have no problems publishing (RESTful) services on Knopflerfish as the DOSGI RI DSW component relies on the OSGI ServiceListener. It won't be possible to run the (REST GreeterService) client on Knopflerfish though untill it implements the relevant OSGI spec (RFC 119 ?), but it should not be too difficult to do. In meantime the only option on the client side is to load the bundles containing code explicitly consuming a remote service (using proxy-based or http-centric api)... cheers, Sergey Demetris-2 wrote: In other words, without trying to make this too convoluted, my question is do you guys use your own implementation of JAX-RS (instead of Jersey etc.). Thanks again Demetris wrote: Hi Sergey, I followed up on your info below in the distribution baseline - thanks, things are making a bit more sense now. Can I conceivably run this particular REST GreeterService and its client on any OSGi Web Server (how about Knopflerfish) with the JAX-RS libraries. I do see 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 service with its client by over p2p instead of over HTTP. Thanks Sergey Beryozkin wrote: 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/dosgi/samples/greeter/rest/GreeterSe rvice.java (note JAXRS annotations) and here : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/java/org/apache/cxf/dosgi/samples/greeter/rest/GreeterSe rvice2.java (has no annotations at all) but GreeterService2 uses this model : http://svn.apache.org/repos/asf/cxf/dosgi/trunk/samples/greeter_rest/int erface/src/main/resources/OSGI-INF/cxf/jaxrs/GreeterService2-model.xml some more info is here : http://cxf.apache.org/distributed-osgi-reference.html#DistributedOSGiRef erence-ServiceProviderpropertiesForConfiguringRESTfulJAXRSbasedendpoints andconsumers hope it helps Sergey -Original Message- From: Demetris [mailto:demet...@ece.neu.edu] Sent: 23 September 2009 08:13 To: dev@cxf.apache.org Subject: D-OSGi and REST Hi Sergey, you mentioned in the blog that users can now expose
RE: [VOTE] Release CXF 2.1.8 (take 2)
+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://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231051 1amp;version=12314302amp;styleName=Htmlamp;Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-009/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-009/org/ apache/cxf/apache-cxf/2.1.8 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.8 The vote will be open for 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
RE: [VOTE] Release CXF 2.2.5
+1 Sergey Forgot the list of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231051 1version=12314303styleName=HtmlCreate=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 have been a bunch of bug fixes and enhancements that have been done compared to the 2.2.4 release. Over 90 JIRA issues are resolved for 2.2.5 List of issues: The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-008/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-008/org/ apa che/cxf/apache-cxf/2.2.5 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.5 The vote will be open for 72 hours. I haven't had time to run the TCK on it yet, so I'll vote later, but I wanted to get the vote started. -- Christian Schneider --- http://www.liquid-reality.de
Re: Thoughts about dropping support for 2.1.x......
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 most of the other major open source projects that were tracking 2.1.x have already moved onto 2.2.x. ServiceMix, Camel, JBoss, etc... The remaining projects that are using 2.1.x seem to be stuck on a particular version (like Mule stuck on 2.1.3) and not tracking the fixes anyway. The main migration issue from 2.1.x to 2.2.x is the JAX-RS version (0.8 - 1.0). However, we aren't fixing any of the JAX-RS issues on 2.1.x anyway. Thus, that's not a real reason. If you are using JAX-RS, you definitely want the compliant implementation in 2.2. I agree Anyway, making 2.1.9 the end of the line should then make it such that when 2.3 is ready (hopefully in Q1), we can just keep 2 fixes branches active. Thoughts? Comments? +1. Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: [New feature] Logging in ATOM Feeds and pushing to client
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 additional configs/etc - At the moment the log events are embedded inside feeds, which is fine, especially when the batch size is greater than one...I feel it would make sense to let users choose that a single Atom entry (not wrapped by a feed) should be pushed if a batch size is equal to 1. Perhaps it can done by default (batch size1 - entry, =1 - feed of entries) but let users to enable/disable this entry-only delivery. For ex, the remote URI can point to some other feed (collection) which the client exposes to its own consumers, so it might be useful to let them simply point to a feed URI and CXF will just POST individual entries to it, it will be just a normal AtomPub collection update. And if users have chosen to push, say, only fatal log events, then sending an entry per log event would not put much stress on the CXF... - Atom specific : users should be able to choose how a log record is embedded inside a given entry. I like the idea of putting it into atom:entry:/atom:content of type application/xml, however some users may prefer the Atom extenstions, so it will be an atom:entry/log:logRecord...The latter option might work well for json given that Abdera supports JSON, not sure though...but also let add an html content to the entry/content, in addition to the xml content added directly to the entry element. - It would be nice to let users easily inject customized WebClients (ex, preferring JSON or set with some additional headers, etc) from Spring, but it may actually be quite easy to do, they'll have to reconfigure a WebDeliverer bean and possibly list a default retrier bean ? - I like the idea of letting users to select multiple loggers(packages)/levels...It should cover most of cases. Perhaps, going forward, we may let them choose not only by level but also by level and category, category only, etc... - At the moment, the delivery will stop if a single delivery fails, unless a retry strategy is configured. I think it is reasonable. But I'm thinking of having a property such as a 'send and forget' one, but we can enable it once WebClient start supporting one ways. That is mostly it, thanks, Sergey Recent builds started to expose initial effort of JAXRS extension in area of logging -- ability to handle log events, pack as ATOM Feeds and push to the client. Documentation is available here: http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-ATOMpushstylelogging. I would like to validate future steps with community so feel free to share your comments here. cheers, andy. -- View this message in context: http://old.nabble.com/-New-feature--Logging-in-ATOM-Feeds-and-pushing-to-client-tp26452485p26452485.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: [VOTE] Release CXF dOSGi 1.1
+1 thanks, Sergey - Original Message - From: Eoghan Glynn eogl...@gmail.com To: dev@cxf.apache.org 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 the Remote Services Specification version 1.0, Chapter 13 in the OSGi Compendium Specification [1]. The release notes contain a description of new features and issues fixed in this release: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/multi-bundle/src/main/release/release_notes.txt The staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-021 The various distributions can be downloaded as follows: - *Source:* https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.1 - *Multi-bundle:* https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.1 - *Single-bundle:* https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.1 This release is tagged with cxf-dosgi-ri-1.1 at: http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.1 The vote will remain open for at least 72 hours. Please consider this call to vote as my +1. Cheers, Eoghan [1] http://www.osgi.org/Download/Release4V42
Re: Status of Atom logging stuff....
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 Thanks! -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: org.apache.cxf.systest.jaxrs.JAXRSLoggingAtomPushTest stack traces and stuff
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 for it to avoid handling its own logging events... Sergey The org.apache.cxf.systest.jaxrs.JAXRSLoggingAtomPushTest is spitting all kinds of stuff out to stdout/stderr. Can that be fixed? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: svn commit: r892222 - in /cxf/dosgi/trunk/dsw/cxf-dsw/src: main/java/org/apache/cxf/dosgi/dsw/handlers/ test/java/org/apache/cxf/dosgi/dsw/handlers/
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 we let users have the same OSGI service exposed as SOAP and RESTful services, how will it work with this property being used ? Perhaps in this latter case org.apache.cxf.ws.address and org.apache.cxf.rs.address thanks, Sergey The we haven't refactored the JAX-RS handlers yet, see: http://old.nabble.com/Re%3A-Migrating-CXF-DOSGi-to-be-complaint-with-the-new-OSGi-Remote--Service-Admin-spec-p26826519.html But when we get to JAX-RS, it should also support the endpoint.uri property. If you have a single service that you want to expose through both using SOAP and REST we could make that possible by letting the user set org.apache.cxf.rs.address and org.apache.cxf.ws.address, since there's no overlap with these properties. Would that work for you? S.B : yes, it would, I think we're in agreement :-) cheers, Sergey Cheers, David
Spring 3 and SpringSecurity 2.0.4 tests
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 specific tests later on, given that they changed the package name for Secured annotation, etc cheers, Sergey
Re: JAXRS - POST
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 class and bean definition.
@Path(/)
@Produces(application/json)
public class HelloWorldImpl implements HelloWorld
{
@POST
@Produces(application/json)
@Consumes(application/json,application/xml)
It should be @Consumes({application/json, application/xml})
Also, pelase make sure ContentType of the HTTP request conatins either
application/json or application/xml and that it accepts
application/json
cheers, Sergey
@Path(/customers)
public Customer getCustomers() {
Customer customer = new Customer();
customer.setId(1);
customer.setName(Padma);
return customer;
}
}
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:jaxrs=http://cxf.apache.org/jaxrs;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxrs
http://cxf.apache.org/schemas/jaxrs.xsd
!-- do not use import statements if CXFServlet init parameters link to
this beans.xml --
import resource=classpath:META-INF/cxf/cxf.xml /
import
resource=classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml /
import resource=classpath:META-INF/cxf/cxf-servlet.xml /
jaxrs:server id=helloWorldService address=/helloWorld
jaxrs:serviceBeans
ref bean=helloWorld /
/jaxrs:serviceBeans
jaxrs:extensionMappings
entry key=json value=application/json /
entry key=xml value=application/xml /
/jaxrs:extensionMappings
/jaxrs:server
bean id=helloWorld class=com.tfs.pe.HelloWorldImpl /
/beans
Please help.
Thanks
Padma
--
View this message in context:
http://old.nabble.com/JAXRS---POST-tp26897610p26897610.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Questions regarding JAX-RS exception handling
Hi Cyrille Thanks for posting this proposal/analysis, please see some comments prefixed with S.B. below... cheers, Sergey Hello all, Here is a proposal of refactoring of both the JAXRS client-side and server-side, these refactoring could be separated one from the other. Please, let me know if it worth continuing this work. SERVER SIDE Move the ExceptionMapper handling from the JAXRSInvoker to a new JAXRSFaultOutInterceptor. Description : If an exception is associated with a Response via an ExceptionMapper, the fault interceptors chain is aborted and a new chain is triggered to render the Response. Pros : consistency between the JAXRS and JAXWS interceptor chains, for example, the ResponseTimeFeature can now count exceptions mapped to responses. Cons : a third interceptors chain is introduced for exceptions that are mapped to Response. It is a bit weird :-) S.B : It looks like the right approach going forward from a technical perspective. Note that at the moment JAXRSInvoker, in JAXRSInInterceptor and out JAXRSOutInterceptor are all trying to map exceptions to Responses given that the exceptions may be thrown from the application code (JAXRSInvoker mapping), from JAXRS message body readers or custom in filters (JAXRSInInterceptor mapping) or from JAXRS message body writers (JAXRSOutInterceptor mapping). Perhaps, the ExceptionMapper handling can indeed be moved from the JAXRSInvoker and JAXRSInInterceptor to the fault interceptor, but this fault interceptor should basically reuse the JAXRSOutInterceptor if/after it has managed to map a fault to the Response given that a Response created by a given ExceptionMapper still has to go through the chain of custom out filters and JAXRS writers. But there are few more things to consider : - JAXRSInInterceptor/JAXRInvoker in its final block clears thread local proxies (representing UriInfo/etc) which may've been injected into custom providers, including exception mappers, so these proxies will need to be available for these mappers and for JAXRS writers/outFilters (in case they need to handle the exception mapper Responses) if they will be invoked from the fault interceptors. So the fault interceptor will need to take care of clearing all the proxies injected into various providers in the end. - At the moment PhaseInterceptorChain will log all the faults which are coming through it. This is something which users may not always want. For example, a JAXRS application code might've logged the fact that a certain resource is not available and throw BookNotFoundException and expect a custom mapper to quietly turn it into 404. At the moment it will work as expected but if we move the mapping code from JAXRSInvoker and JAXRSInInterceptor to the fault one then more runtime logging will get done. I think one of CXF users was thinking of customizing PhaseInterceptorChain so that 'quiet' loggers can be plugged in but nothing has been done yet there AFAIK. So it all should work quite well, but we need to do a bit more analysis of what it would take to complete this refactoring on the server side... CLIENT SIDE === Extract the marshalling and exception processing logic from the jaxrs client to interceptors ; I only worked on the ClientProxyImpl, the work on the WebClient is still to do. Description : * the JAXRSResponseInterceptor builds the Response object (currently with the inputstream object). Remaining : complete the Response processing with the unmarshalling of the inputstream S.B. I guess this one should probably be handling both proxy and WebClient responses ? * the JAXRSCheckFaultInterceptor handles faults and the ResponseExceptionMapper processing S.B : one thing to be aware of here is that if either a code using proxy or WebClient explicitly expects a JAXRS Response object then it should get Response... Pros : consistency betwen JAXRS and JAXWS interceptor chains, for example, the ResponseTimeFeature can now count exceptions mapped to responses. Cons : I didn't find any :-) S.B : sounds good :-) Todo : complete the cleanup of the client Note : the ClientFaultConverter should NOT be 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 sbery...@progress.com wrote: 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 If an ExceptionMapper handles the exception : 1) The JAXRSInvoker returns a Response instead of throwing an Exception Yes, this is for JAXRS message body writers be able to handle whatever Response entity
Re: svn commit: r894409 - /cxf/branches/2.2.x-fixes/
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: serg...@apache.org To: comm...@cxf.apache.org Sent: Tuesday, December 29, 2009 3:09 PM Subject: svn commit: r894409 - /cxf/branches/2.2.x-fixes/ Author: sergeyb Date: Tue Dec 29 15:09:37 2009 New Revision: 894409 URL: http://svn.apache.org/viewvc?rev=894409view=rev Log: Unblocked revisions 817055 via svnmerge r817055 | sergeyb | 2009-09-20 18:08:08 +0100 (Sun, 20 Sep 2009) | 1 line JAXRS : moving to jax-rs 1.1 on the trunk only
RE: Questions regarding JAX-RS exception handling
as a result and no fault chains will be invoked to handle them given that it is not a real fault, at some later time some other thread will get back and pass through the JAXRSInInterceptor again so this is where we can have a leak after the given invocation has been suspended if we do a cleanup in the fault chain, possibly a number of times - may be we can fix it by updating JAXRSInInterceptor/JAXRSInvoker only if SuspendedInvocation has occured. What you've done so far seems very precise and quite perfect but as you see yourself the refactoring is becoming a bit complicated :-). In the end of the day, writing a simple FaultLogger which will block the extra logging or ensuring the cleanup always occurs is not a big deal, but before we commit to it I'd like us to explore an alternative solution. S.B So the possible alternative approach is to ensure an in/out fault chain is called explicitly even after we have mapped an exception to JAXRS Response with a custom ExceptionMapper. I'm not sure how to do it yet, may be we can add some method to PhaseInterceptorChain, say, getCurrentFaultChain. Or may we can add a property like org.apache.cxf.exception.convertedToResponse and rethrow the fault and update XMLOutFaultInterceptor to check this property and not to write out if it 's been set... What do you think ? thanks, Sergey Regarding your question about the client, I didn't touch the WebClient yet, it is on my todo list there should not be problems with it. I would prefer to focus on the server side right now and postpone the client side refactoring as the server side work is already pretty big :-) 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 sbery...@progress.com wrote: Hi Cyrille Thanks for posting this proposal/analysis, please see some comments prefixed with S.B. below... cheers, Sergey Hello all, Here is a proposal of refactoring of both the JAXRS client-side and server-side, these refactoring could be separated one from the other. Please, let me know if it worth continuing this work. SERVER SIDE Move the ExceptionMapper handling from the JAXRSInvoker to a new JAXRSFaultOutInterceptor. Description : If an exception is associated with a Response via an ExceptionMapper, the fault interceptors chain is aborted and a new chain is triggered to render the Response. Pros : consistency between the JAXRS and JAXWS interceptor chains, for example, the ResponseTimeFeature can now count exceptions mapped to responses. Cons : a third interceptors chain is introduced for exceptions that are mapped to Response. It is a bit weird :-) S.B : It looks like the right approach going forward from a technical perspective. Note that at the moment JAXRSInvoker, in JAXRSInInterceptor and out JAXRSOutInterceptor are all trying to map exceptions to Responses given that the exceptions may be thrown from the application code (JAXRSInvoker mapping), from JAXRS message body readers or custom in filters (JAXRSInInterceptor mapping) or from JAXRS message body writers (JAXRSOutInterceptor mapping). Perhaps, the ExceptionMapper handling can indeed be moved from the JAXRSInvoker and JAXRSInInterceptor to the fault interceptor, but this fault interceptor should basically reuse the JAXRSOutInterceptor if/after it has managed to map a fault to the Response given that a Response created by a given ExceptionMapper still has to go through the chain of custom out filters and JAXRS writers. But there are few more things to consider : - JAXRSInInterceptor/JAXRInvoker in its final block clears thread local proxies (representing UriInfo/etc) which may've been injected into custom providers, including exception mappers, so these proxies will need to be available for these mappers and for JAXRS writers/outFilters (in case they need to handle the exception mapper Responses) if they will be invoked from the fault interceptors. So the fault interceptor will need to take care of clearing all the proxies injected into various providers in the end. - At the moment PhaseInterceptorChain will log all the faults which are coming through it. This is something which users may not always want. For example, a JAXRS application code might've logged the fact that a certain resource is not available and throw BookNotFoundException and expect a custom mapper to quietly turn it into 404. At the moment it will work as expected but if we move the mapping code from JAXRSInvoker and JAXRSInInterceptor to the fault one then more runtime logging will get done. I think one of CXF users was thinking of customizing PhaseInterceptorChain so that 'quiet' loggers can be plugged in but nothing has been done yet there AFAIK. So it all should work quite well, but we need to do
Loading HTTP OSGI transport only when needed
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 which seems to work in this case is to remove a cxf osgi transport bits altogether from a bundle given that the user reporting the issue is not using this transport. This works but it is not ideal. I'm also thinking that may be DOSGI might be affected a bit too given that DOSGI users do not use this transport as well but will have a /cxf context busy already, not that they need '/cxf' but anyway... I'm just wondering, what options we might have here ? Perhaps one option is not to bundle this transport for cxf-minimal and cxf-jaxrs bundles ? Users who do need it, say ServiceMix users, can get it from the full bundle. Another option is to add a CXF OSGI HTTP transport BundleActivator and repackage META-INF/spring/cxf-osgi-transport.xml into say META-INF/cxf//spring/cxf-osgi-transport.xml. Our BundleActivator will somehow delegate to META-INF/cxf//spring/cxf-osgi-transport.xml, I don't know how yet, but I think, as far as I recall from writing SpringDM tests, it might be possible to point SpringDM to some custom location. However, before delegating, the BundleActivator will check, say a system property which if set would disable the osgi transport. Something along these lines. Thoughts ? cheers, Sergey P.S. I might not be able to contribute to this thread until this coming Thursday...
RE: Questions regarding JAX-RS exception handling
org.apache.cxf.exception.convertedToResponse and rethrow the fault and update XMLOutFaultInterceptor to check this property and not to write out if it 's been set... CLC: As I said above, I would see benefits in evolving the PhaseInterceptorChain to handle propagated exceptions. Adding methods to interact with the fault chain could be tricky as, in case of fault, the PhaseInterceptorChain 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 question about the client, I didn't touch the WebClient yet, it is on my todo list there should not be problems with it. I would prefer to focus on the server side right now and postpone the client side refactoring as the server side work is already pretty big :-) 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 sbery...@progress.com wrote: Hi Cyrille Thanks for posting this proposal/analysis, please see some comments prefixed with S.B. below... cheers, Sergey Hello all, Here is a proposal of refactoring of both the JAXRS client-side and server-side, these refactoring could be separated one from the other. Please, let me know if it worth continuing this work. SERVER SIDE Move the ExceptionMapper handling from the JAXRSInvoker to a new JAXRSFaultOutInterceptor. Description : If an exception is associated with a Response via an ExceptionMapper, the fault interceptors chain is aborted and a new chain is triggered to render the Response. Pros : consistency between the JAXRS and JAXWS interceptor chains, for example, the ResponseTimeFeature can now count exceptions mapped to responses. Cons : a third interceptors chain is introduced for exceptions that are mapped to Response. It is a bit weird :-) S.B : It looks like the right approach going forward from a technical perspective. Note that at the moment JAXRSInvoker, in JAXRSInInterceptor and out JAXRSOutInterceptor are all trying to map exceptions to Responses given that the exceptions may be thrown from the application code (JAXRSInvoker mapping), from JAXRS message body readers or custom in filters (JAXRSInInterceptor mapping) or from JAXRS message body writers (JAXRSOutInterceptor mapping). Perhaps, the ExceptionMapper handling can indeed be moved from the JAXRSInvoker and JAXRSInInterceptor to the fault interceptor, but this fault interceptor should basically reuse the JAXRSOutInterceptor if/after it has managed to map a fault to the Response given that a Response created by a given ExceptionMapper still has to go through the chain of custom out filters and JAXRS writers. But there are few more things to consider : - JAXRSInInterceptor/JAXRInvoker in its final block clears thread local proxies (representing UriInfo/etc) which may've been injected into custom providers, including exception mappers, so these proxies will need to be available for these mappers and for JAXRS writers/outFilters (in case they need to handle the exception mapper Responses) if they will be invoked from the fault interceptors. So the fault interceptor will need to take care of clearing all the proxies injected into various providers in the end. - At the moment PhaseInterceptorChain will log all the faults which are coming through it. This is something which users may not always want. For example, a JAXRS application code might've logged the fact that a certain resource is not available and throw BookNotFoundException and expect a custom mapper to quietly turn it into 404. At the moment it will work as expected but if we move the mapping code from JAXRSInvoker and JAXRSInInterceptor to the fault one then more runtime logging will get done. I think one of CXF users was thinking of customizing PhaseInterceptorChain so that 'quiet' loggers can be plugged in but nothing has been done yet there AFAIK. So it all should work quite well, but we need to do a bit more analysis of what it would take to complete this refactoring on the server side... CLIENT SIDE === Extract the marshalling and exception processing logic from the jaxrs client to interceptors ; I only worked on the ClientProxyImpl, the work on the WebClient is still to do. Description : * the JAXRSResponseInterceptor builds the Response object (currently with the inputstream object). Remaining : complete the Response processing with the unmarshalling of the inputstream S.B. I guess this one should probably be handling both proxy and WebClient responses ? * the JAXRSCheckFaultInterceptor handles faults and the ResponseExceptionMapper processing S.B : one thing to be aware of here
Re: Questions regarding JAX-RS exception handling
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 you suggested on both trunk and
2.2-fixes. It will be available in 2.2.6. Change is tracked in
[CXF-2622] ThreadLocal variables may not be cleared in case of
exception (1).
I will continue to work on the refactoring to get JAXRS monitoring
with exception counting for 2.3 and maybe 2.2.7 :-) .
S.B : please do, thanks. I'm just thinking may be we should target 2.3 only due to the minor issue to do with the fact that some
JAXRS users might need to register a custom FaultLogger in order to avoid some excessive logging ? We will document it in the
migration guide from 2.2.x to 2.3 ? Some more comments are below...
Cyrille
(1) https://issues.apache.org/jira/browse/CXF-2622
CLC: also convinced that risking to not cleanup thread locals is worrying,
CLC: can you confirm my understanding that thread locals are related to @Context and @Resource fields/setters and only apply to
RequestHandler, MessageBodyReader, serviceObject/Resource, MessageBodyWriter, ResponseHandler and ExceptionMapper ?
S.B : yes
CLC: if so, almost each thread local is easy to cleanup in a finally block
because its scope is limited to one single method :
CLC: the only challenge I see is limited : the serviceObject/Resource is injected thread locals in the JAXRSInInterceptors
and the cleanup is done in the JAXRSInvoker. I didn't yet figure how the thread locals are cleared if an exception occurs
between the two.
S.B : thanks for eliminating this potential source of leaks with your latest fix
CLC: as a general evolution, I would see great benefits in adding a finally semantic in the interceptors. I already saw use
cases with implementing circuit breaker patterns or invocation concurrency limitations (with semaphores) ; we do such
things on my project with try {} finally {} blocks in the service implementation because we fear leaks due to aborted chains
executions.
S.B : can you elaborate a bit more please ? Does handleFault meet this requirement or would you like to propose some enhancements
to the way PhaseInterceptorChain operates ?
CLC: Regarding the exception propagation to the servlet container, would it make sense to add a dedicated mechanism in the
PhaseInterceptorChain, I imagine it similar to the invocation suspension with the SuspendedInvocationException. A
PropagatedException would hold the underlying exception (ServletException, IOException or RuntimeExcetpion) and it would bubble
until the ServletController.invoke() where the actual exception would be thrown. It currently goes throught the step
..AbstractFaultChainInitiatorObserver - Error occurred during error handling, give up! that seems to be dedicated to abnormal
behaviors.
S.B : sounds interesting but would we need to update PhaseInterceptorChain to rewind the chain in the case of Propagated exception
? And perhaps doing some more coding around it ? Even if it is meant to be propagated, it should still go through the fault
chains, say for a management feature to work ? What do you think about updating AbstractFaultChainInitiatorObserver, for it to
check a propagated exception property on a message/exchange and if it is set then not to log ?
* XMLFaultOutInterceptor and StaxOutInterceptor are no longer invoked
in the faultOut chain, see JAXRSFaultOutInterceptor
CLC: I may not have been clear enough. If an exception is thrown, I propose to let the PhaseInterceptorChain handle it
normally, that is to say unwind the in interceptors chain (calling handleFault()) and to trigger the fault out chain. If the
exception is mapped to a response, the fault chain will render this response, otherwise, the fault chain will render the
exception in xml or propagate it to the servlet container.
S.B : ok. I guess I'm confused by the fact you said XMLFaultOutInterceptor would not be invoked ? But XMLFaultOutInterceptor is
the one which will render the exception in xml if no exception mapper has been found ?
CLC: I see one thing you may dislike : custom out interceptors must also be registered as out fault interceptors to be called
even if exceptions are thrown ; this is similar to the soap chains behavior.
S.B : this is probably ok, no problems here...
CLC: Do you see problems in handling the ExceptionMapper step as the first
step of the fault out chain ?
S.B : not really, should work ok...
CLC: The resource cleanup concern in the continuations scenario would be
fixed by the usage of finally blocks described above.
S.B : in JAXRSInInterceptor ?
CLC: As I said above, I would see benefits in evolving the PhaseInterceptorChain to handle propagated exceptions. Adding
methods to interact with the
Re: SOAP Monitoring console for CXF
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 database. Additional data is the service name, the operation name, the exception type and the stacktrace if the response is a fault, the response time, the status, the user agent, the encoding, http headers, etc. It also provides a mechanism so users can store their own additional data if they need to. What is your opinion about contributing some of this code to the rt/management module ? Cyrille and other experts can help. The rt/management conrtains a management featire which can be used to monitor both SOAP and RESTful services. And it looks like it can do most of what you've described above but perhaps you can help enhancing it for it to match what your interceptors can do ? The cxf console comes with 3 maven modules : - cxf-soap-console-dao : used for CRUD operation in database, use iBatis. MySQL is supported, I'll add Oracle and Postgres support soon since I need it, I might also add derby support. - cxf-soap-console-interceptors : the soap interceptors that users need to add to their webservices. They are basically extended versions of LoggingInterceptors from cxf. - cxf-soap-console-webapp : a webapp to show data stored by the interceptors (see attached screenshots) It is still in an alpha stage, here are some planned features ; - statistics by service - statistics by operation - jfreechart inclusion in the webapp - a search form - make it a cxf feature This is quite interesting. You may've seen we've discussed the possibility of introducing a rt/management-web module which will initially contain : - atom based pull/push logging support for individual jaxrs/jaxrs endpoints (thsi code is currently in CXF JAX-RS) with the eventual possibility to subscribe or register callback URIs from CXF /services page - CXF JAX-RS based endpoint for showing JMX-based data over HTTP for all CXF endpoints and providing more advanced management capabilities over time I hope this component will eventually turn CXF itself into a well-featured Web application on its own. We'll need to complete some intial support for the Atom pull logging stuff (nearly there) and then I will do the move. It looks like what you've done may be eventually added to this new CXF module. Others may have a different opinion though... cheers, Sergey I've attached the source code, some screenshots, and the ddl script to create the database. Maven should generate a war deployable in tomcat, mvn eclipse:eclipse will generate the eclipse projects. The datasource must be named jdbc/cxf/console. Has this any chance to be included in cxf or should I create a separate project on google code/sourceforge ? Regards, Rémi.
Re: JAXB and JAX-RS under CXF
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 much... Are you seeing any issues ? I'm thinking may be I've just done another piece of the documentation which is confusing ? One thing I'm saying there is that if you do not want to have your bundle modified for JAXB be supported at runtime as well as to explicitly annotate beans with @XmlRootElement and friends (that is, to import JAXB packages) then if it is JAX-RS only you can register a custom (CXF JAXRS) JAXBElementProvider and tell it to use JAXBElement internally and that is it... cheers, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 5:07 PM Subject: JAXB and JAX-RS under CXF Hi list, following the DOSGi reference [1] I see that it's not possible to use JAXB under JAX-RS but with JAX-WS. Is that correct? And what is the reason for it? Kind regards, Daniel [1] http://cxf.apache.org/distributed-osgi-reference.html
Re: [VOTE] Release CXF 2.1.9
+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 Apache CXF. Users are encouraged to start migrating to 2.2.x. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314380styleName=HtmlprojectId=12310511Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-056/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-056/org/apache/cxf/apache-cxf/2.1.9 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.9 The vote will be open for 72 hours. Here is my +1.
Re: JAXB and JAX-RS under CXF
Hi Please see a comment with S.B - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 6:07 PM Subject: Re: JAXB and JAX-RS under CXF Oh great thing Sergey, thanks for that answer. I just tried and it works just fine. In fact, documentation was either misleading or I misread. The documentation says This property has a limited value for JAXRS services as JAXB is supported by default, the only supported value is 'aegis' and it is a shortcut for registering an Aegis provider [...] which is a little hard to understand. One the one hand it says JAXB is supported, but on the other hand 'aegis' is the only value you're allowed to use. So this confused me. S.B : it kind of does not makse sense, now that I read it again. (CXF) JAXRS do not use (CXF)databindings as often as they use 'providers', technically both terms are probably identical, but I wanted to not require users to set this property given that they will probably want to register say a DataBindingProvider provider delegating to CXF Aegis as OSGI service, with some custom configuration, etc...That said, for simple cases, letting users just to do org.apache.cxf.rs.databinding=atom would also make sense... JAXB will be supported with or without org.apache.cxf.rs.databinding=jaxb but I'll look into simplifying the documentation and enhancing a bit the way this org.apache.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 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 much... Are you seeing any issues ? I'm thinking may be I've just done another piece of the documentation which is confusing ? One thing I'm saying there is that if you do not want to have your bundle modified for JAXB be supported at runtime as well as to explicitly annotate beans with @XmlRootElement and friends (that is, to import JAXB packages) then if it is JAX-RS only you can register a custom (CXF JAXRS) JAXBElementProvider and tell it to use JAXBElement internally and that is it... cheers, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 5:07 PM Subject: JAXB and JAX-RS under CXF Hi list, following the DOSGi reference [1] I see that it's not possible to use JAXB under JAX-RS but with JAX-WS. Is that correct? And what is the reason for it? Kind regards, Daniel [1] http://cxf.apache.org/distributed-osgi-reference.html -- M.Sc. Daniel Bimschas Institute of Telematics, University of Lübeck http://www.itm.uni-luebeck.de/users/bimschas Ratzeburger Allee 160, 23538 Lübeck, Germany Phone: +49 451 500 5389
Re: JAXB and JAX-RS under CXF
Hi, please see more comments inline snip/ 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 the error message: com.sun.istack.internal.SAXException2: unable to marshal type a.b.c.X as an element because it is missing an @XmlRootElement annotation S.B : Do those objects actually have @XmlRootElement ? Yes, they do. I use Pax Exam to set up a test case that marshalls the object to a byte[] and unmarshalls it afterwards from it. Do you know that error? S.B : yes, usually it is to do with @XmlRootElement being not present or, in OSGI case, being 'lost' at runtime, due to a missing import package value...You can condigure DOSGI RI to not require @XmlRootElement for JAXRS services... I checked the packaged bundle. It definitely has the JAXB annotation packages imported (which is no wonder as I'm using maven-bundle-plugin with bnd to generate the Manifest). S.B : for some reasons there're still invisible to the JAXB runtime. One of users reported a similar issue the other day, JAXB classes have been moved to a bundle separate from the application one. I don't recall what the fix was, it is just a visibility issue which can be solved at the OSGI level. Please attach a sample bundle if it won't work... How can I configure it for use without annotations? S.B : You'll need to register a custom JAXBElementProvider as a MessageBodyReader and MessageBodyWriter OSGI service and set a property on it (marshalAsJaxbElement). One will be able to do the same from Spring DM context once we fix the issue of discovering well-known spring beans... Why is CXF behaving different than plain JAXB? S.B : what exactly is different ? Just that plain works, and OSGi-based fails because of the errors mentioned above. But I guess that's misconfiguration. S.B : yes, it's an OSGI configuration issue. DOSGI can't help on its own...At the last resort try DynamicImport... cheers, 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 Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 6:07 PM Subject: Re: JAXB and JAX-RS under CXF Oh great thing Sergey, thanks for that answer. I just tried and it works just fine. In fact, documentation was either misleading or I misread. The documentation says This property has a limited value for JAXRS services as JAXB is supported by default, the only supported value is 'aegis' and it is a shortcut for registering an Aegis provider [...] which is a little hard to understand. One the one hand it says JAXB is supported, but on the other hand 'aegis' is the only value you're allowed to use. So this confused me. S.B : it kind of does not makse sense, now that I read it again. (CXF) JAXRS do not use (CXF)databindings as often as they use 'providers', technically both terms are probably identical, but I wanted to not require users to set this property given that they will probably want to register say a DataBindingProvider provider delegating to CXF Aegis as OSGI service, with some custom configuration, etc...That said, for simple cases, letting users just to do org.apache.cxf.rs.databinding=atom would also make sense... JAXB will be supported with or without org.apache.cxf.rs.databinding=jaxb but I'll look into simplifying the documentation and enhancing a bit the way this org.apache.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 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 much... Are you seeing any issues ? I'm thinking may be I've just done another piece of the documentation which is confusing ? One thing I'm saying there is that if you do not want to have your bundle modified for JAXB be supported at runtime as well as to explicitly annotate beans with @XmlRootElement and friends (that is, to import JAXB packages) then if it is JAX-RS only you can register a custom (CXF JAXRS) JAXBElementProvider and tell it to use JAXBElement internally and that is it... cheers, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 5:07 PM Subject: JAXB and JAX-RS under CXF Hi list, following the DOSGi reference [1] I see that it's not possible to use JAXB under JAX-RS but with JAX-WS. Is that correct
Re: JAXB and JAX-RS under CXF
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 project. But it looks like it is a container-specific issue ? Which one were you using originally, before switching to Equinox ? thanks, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Friday, January 22, 2010 4:13 PM Subject: Re: JAXB and JAX-RS under CXF Damnit. I just changed the Pax-Runner configuration to only use Equinox and now the tests pass, everything seems fine. 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 snip/ 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 the error message: com.sun.istack.internal.SAXException2: unable to marshal type a.b.c.X as an element because it is missing an @XmlRootElement annotation S.B : Do those objects actually have @XmlRootElement ? Yes, they do. I use Pax Exam to set up a test case that marshalls the object to a byte[] and unmarshalls it afterwards from it. Do you know that error? S.B : yes, usually it is to do with @XmlRootElement being not present or, in OSGI case, being 'lost' at runtime, due to a missing import package value...You can condigure DOSGI RI to not require @XmlRootElement for JAXRS services... I checked the packaged bundle. It definitely has the JAXB annotation packages imported (which is no wonder as I'm using maven-bundle-plugin with bnd to generate the Manifest). S.B : for some reasons there're still invisible to the JAXB runtime. One of users reported a similar issue the other day, JAXB classes have been moved to a bundle separate from the application one. I don't recall what the fix was, it is just a visibility issue which can be solved at the OSGI level. Please attach a sample bundle if it won't work... How can I configure it for use without annotations? S.B : You'll need to register a custom JAXBElementProvider as a MessageBodyReader and MessageBodyWriter OSGI service and set a property on it (marshalAsJaxbElement). One will be able to do the same from Spring DM context once we fix the issue of discovering well-known spring beans... Why is CXF behaving different than plain JAXB? S.B : what exactly is different ? Just that plain works, and OSGi-based fails because of the errors mentioned above. But I guess that's misconfiguration. S.B : yes, it's an OSGI configuration issue. DOSGI can't help on its own...At the last resort try DynamicImport... cheers, 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 Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 6:07 PM Subject: Re: JAXB and JAX-RS under CXF Oh great thing Sergey, thanks for that answer. I just tried and it works just fine. In fact, documentation was either misleading or I misread. The documentation says This property has a limited value for JAXRS services as JAXB is supported by default, the only supported value is 'aegis' and it is a shortcut for registering an Aegis provider [...] which is a little hard to understand. One the one hand it says JAXB is supported, but on the other hand 'aegis' is the only value you're allowed to use. So this confused me. S.B : it kind of does not makse sense, now that I read it again. (CXF) JAXRS do not use (CXF)databindings as often as they use 'providers', technically both terms are probably identical, but I wanted to not require users to set this property given that they will probably want to register say a DataBindingProvider provider delegating to CXF Aegis as OSGI service, with some custom configuration, etc...That said, for simple cases, letting users just to do org.apache.cxf.rs.databinding=atom would also make sense... JAXB will be supported with or without org.apache.cxf.rs.databinding=jaxb but I'll look into simplifying the documentation and enhancing a bit the way this org.apache.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 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 much... Are you seeing any issues ? I'm thinking may be I've just done another
Re: JAXB and JAX-RS under CXF
Excellent, thanks. Please ping the Felix team, and I'll play with this project too... cheers, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Friday, January 22, 2010 4:43 PM Subject: Re: JAXB and JAX-RS under CXF Sergey, I'm unsure if that is something that can be fixed at DOSGi level. I just made a demo project and attached it to this mail. I will also send it to the Apache Felix guys who hopefully can inspect the issue (if they care) :D because felix's the framework that doesn'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 project. But it looks like it is a container-specific issue ? Which one were you using originally, before switching to Equinox ? thanks, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Friday, January 22, 2010 4:13 PM Subject: Re: JAXB and JAX-RS under CXF Damnit. I just changed the Pax-Runner configuration to only use Equinox and now the tests pass, everything seems fine. 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 snip/ 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 the error message: com.sun.istack.internal.SAXException2: unable to marshal type a.b.c.X as an element because it is missing an @XmlRootElement annotation S.B : Do those objects actually have @XmlRootElement ? Yes, they do. I use Pax Exam to set up a test case that marshalls the object to a byte[] and unmarshalls it afterwards from it. Do you know that error? S.B : yes, usually it is to do with @XmlRootElement being not present or, in OSGI case, being 'lost' at runtime, due to a missing import package value...You can condigure DOSGI RI to not require @XmlRootElement for JAXRS services... I checked the packaged bundle. It definitely has the JAXB annotation packages imported (which is no wonder as I'm using maven-bundle-plugin with bnd to generate the Manifest). S.B : for some reasons there're still invisible to the JAXB runtime. One of users reported a similar issue the other day, JAXB classes have been moved to a bundle separate from the application one. I don't recall what the fix was, it is just a visibility issue which can be solved at the OSGI level. Please attach a sample bundle if it won't work... How can I configure it for use without annotations? S.B : You'll need to register a custom JAXBElementProvider as a MessageBodyReader and MessageBodyWriter OSGI service and set a property on it (marshalAsJaxbElement). One will be able to do the same from Spring DM context once we fix the issue of discovering well-known spring beans... Why is CXF behaving different than plain JAXB? S.B : what exactly is different ? Just that plain works, and OSGi-based fails because of the errors mentioned above. But I guess that's misconfiguration. S.B : yes, it's an OSGI configuration issue. DOSGI can't help on its own...At the last resort try DynamicImport... cheers, 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 Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 6:07 PM Subject: Re: JAXB and JAX-RS under CXF Oh great thing Sergey, thanks for that answer. I just tried and it works just fine. In fact, documentation was either misleading or I misread. The documentation says This property has a limited value for JAXRS services as JAXB is supported by default, the only supported value is 'aegis' and it is a shortcut for registering an Aegis provider [...] which is a little hard to understand. One the one hand it says JAXB is supported, but on the other hand 'aegis' is the only value you're allowed to use. So this confused me. S.B : it kind of does not makse sense, now that I read it again. (CXF) JAXRS do not use (CXF)databindings as often as they use 'providers', technically both terms are probably identical, but I wanted to not require users to set this property given that they will probably want to register say a DataBindingProvider provider delegating to CXF Aegis as OSGI service, with some custom configuration, etc...That said, for simple cases, letting users just to do org.apache.cxf.rs.databinding=atom would also make sense... JAXB
Re: JAXB and JAX-RS under CXF
Hi Daniel It is probably JDK 1.6 that you're using ? I think I did manage to expose JAXB beans on Felix using a single bundle distribution with 1.5 (by moodifying one of the existing DOSGi demos)... cheers, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Tuesday, January 26, 2010 10:01 PM Subject: Re: JAXB and JAX-RS under CXF Hi Sergey, thanks for your efforts. The only thing I had to do is to add javax.xml.bind.* packages to the boot delegation classpath of my OSGi environment. A point I simply didn't think about as most JRE-classes 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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Friday, January 22, 2010 4:43 PM Subject: Re: JAXB and JAX-RS under CXF Sergey, I'm unsure if that is something that can be fixed at DOSGi level. I just made a demo project and attached it to this mail. I will also send it to the Apache Felix guys who hopefully can inspect the issue (if they care) :D because felix's the framework that doesn'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 project. But it looks like it is a container-specific issue ? Which one were you using originally, before switching to Equinox ? thanks, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Friday, January 22, 2010 4:13 PM Subject: Re: JAXB and JAX-RS under CXF Damnit. I just changed the Pax-Runner configuration to only use Equinox and now the tests pass, everything seems fine. 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 snip/ 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 the error message: com.sun.istack.internal.SAXException2: unable to marshal type a.b.c.X as an element because it is missing an @XmlRootElement annotation S.B : Do those objects actually have @XmlRootElement ? Yes, they do. I use Pax Exam to set up a test case that marshalls the object to a byte[] and unmarshalls it afterwards from it. Do you know that error? S.B : yes, usually it is to do with @XmlRootElement being not present or, in OSGI case, being 'lost' at runtime, due to a missing import package value...You can condigure DOSGI RI to not require @XmlRootElement for JAXRS services... I checked the packaged bundle. It definitely has the JAXB annotation packages imported (which is no wonder as I'm using maven-bundle-plugin with bnd to generate the Manifest). S.B : for some reasons there're still invisible to the JAXB runtime. One of users reported a similar issue the other day, JAXB classes have been moved to a bundle separate from the application one. I don't recall what the fix was, it is just a visibility issue which can be solved at the OSGI level. Please attach a sample bundle if it won't work... How can I configure it for use without annotations? S.B : You'll need to register a custom JAXBElementProvider as a MessageBodyReader and MessageBodyWriter OSGI service and set a property on it (marshalAsJaxbElement). One will be able to do the same from Spring DM context once we fix the issue of discovering well-known spring beans... Why is CXF behaving different than plain JAXB? S.B : what exactly is different ? Just that plain works, and OSGi-based fails because of the errors mentioned above. But I guess that's misconfiguration. S.B : yes, it's an OSGI configuration issue. DOSGI can't help on its own...At the last resort try DynamicImport... cheers, 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 Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 6:07 PM Subject: Re: JAXB and JAX-RS under CXF Oh great thing Sergey, thanks for that answer. I just tried and it works just fine. In fact, documentation was either misleading or I misread. The documentation says This property has a limited value for JAXRS services as JAXB is supported by default, the only supported value is 'aegis' and it is a shortcut for registering an Aegis provider
RE: svn commit: r903784 - /cxf/branches/2.2.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSJmsTest.java
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/org/apache/cxf/sy stest/jaxrs/JAXRSJmsTest.java Author: dkulp Date: Wed Jan 27 18:59:27 2010 New Revision: 903784 URL: http://svn.apache.org/viewvc?rev=903784view=rev Log: Fix compile failure Modified: cxf/branches/2.2.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/sys test/jaxrs/JAXRSJmsTest.java Modified: cxf/branches/2.2.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/sys test/jaxrs/JAXRSJmsTest.java URL: http://svn.apache.org/viewvc/cxf/branches/2.2.x-fixes/systests/jaxrs/src /test/java/org/apache/cxf/systest/jaxrs/JAXRSJmsTest.java?rev=903784r1= 903783r2=903784view=diff == --- cxf/branches/2.2.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/sys test/jaxrs/JAXRSJmsTest.java (original) +++ cxf/branches/2.2.x-fixes/systests/jaxrs/src/test/java/org/apache/cxf/sys test/jaxrs/JAXRSJmsTest.java Wed Jan 27 18:59:27 2010 @@ -19,6 +19,7 @@ package org.apache.cxf.systest.jaxrs; +import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.InputStream; import java.util.HashMap; @@ -87,7 +88,8 @@ MessageConsumer consumer = session.createConsumer(replyToDestination); Message jmsMessage = consumer.receive(3000); org.apache.cxf.message.Message cxfMessage = new org.apache.cxf.message.MessageImpl(); -JMSUtils.retrieveAndSetPayload(cxfMessage, jmsMessage, null); +byte[] bytes = JMSUtils.retrievePayload(jmsMessage, null); +cxfMessage.setContent(InputStream.class, new ByteArrayInputStream(bytes)); Book b = readBook(cxfMessage.getContent(InputStream.class)); assertEquals(124L, b.getId()); assertEquals(JMS, b.getName());
Re: SOAP Monitoring console for CXF
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 to have save() method only ? All other methods have to do with managing/viewing/searching the
previously persisted exchanges which is not what PersistsIn/Out interceptors are interested in. Instead we can have a CXF JAXRS
endpoint (see below) in rt/management-web implementing an interface to do with searching the exchanges.
- please remove Statistics class, we can introduce it later on, when working on exposing exchanges over the web. Now, I'm also
thinking that may be we can ensure it can keep the data accumulated in JMX beans too...
- I appreciate you'd like to have a SOAP monitoring console but can you please
get the service and operation name the way
AbstractMessageResponseTimeInterceptor does ? This way JAXRS exchanges will
also be properly populated.
- should Exchange be a JAXB bean ? (we can worry about it later though). Should it be renamed ? Say ExchangeData or similar ? It is
just CXF also has Exchange
Basically I've removed all the spring-orm/ibatis part and I've added a
simple implementation of ExchangeDAO which logs to text files.
I was about to tell you that we can decide later on, when working on rt/management-web, how exactly the exchanges can be persisted
and how to build the views. Perhaps, by default we can reuse the file based storage. I'd be keen on relying on xslt to have a bunch
of prepaired html templates merged with XML data (say with the JAXB serialized Statistics) for nice views be created. May be we can
introduce some other light deps, GWT may be ?
Then if I need to log in a database I can use my ibatis implementation
by changing the spring configuration.
exactly
I'm not familiar at all with OSGI or JAX-RS, so I can't give you any
thought on this part yet :)
CXF JAXRS endpoint will just act as a simple controller. It won't matter it is SOAP or plain XML exchanges which are being
viewed/managed...Please see :
http://cwiki.apache.org/CXF20DOC/jax-rs.html
ex, you might have :
@Path(/exchanges)
public class Controller {
@GET @Path(/stats)
@Produces(text/xml, application/xml)
public Statistics getStats() {
// let JAXB serialize it and then the XSLTProvider will put it into a
nice view
return exchangeDaoReader.getStatistics();
}
...
}
cheers, Sergey
Regards,
Rémi.
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 statistics and
eventually expose it over
JMX. The idea of persisting exchanges and
ultimately showing them without JMX being involved seems to be
generally useful, but there
are quite a few depedencies/details in
the patch which would require users of the in/out persistence
interceptors to stick to specific
technologies like spring orm, etc,
but they may just want to save exchanges into a text file or push them
over a socket/http.
IMHO it would be useful to have persistence interceptors added to the
management feature but
it would be better to abstract away the
details of how a current exchange can be persisted. Example, I'd only
add say 2 interceptors
(in/out) plus, say, some simple
interface which can be used to save an exchange.
Next, we can have a demo showing one way (as shown in the patch) how
the exchanges can be
persisted.
I also have a question regarding the rt/management-web module : the
packaging is jar
in the pom.xml. Does it mean this is a
library that should be included by users in their own webapp or
should the packaging
be war instead ?
It will be a jar, but ultimately it will become a 'bundle' which is a
jar with its manifest
updated with few extra OSGI
instructions.
If this module is intended to be the management webapp, is it OK to
add spring-webmvc
dependency in it ?
The idea behind introducing this module is to let users do a number of
useful management-related
tasks over HTTP, by relying on the
existing CXF modules and technologies already available in JDK. Ex,
CXF JAXRS module can be
used to create various endpoints (one
will be used to let users subscribe to atom logging events, the other
one will actually let
users view the statisics amd possibly do
spme management operations, etc). I'd prefer to have a JAXRS endpoint
which could be used
to show the statistics and possibly the
exchanges persisted by various CXF 'working' endpoints.
Thoughts ?
thanks, Sergey
RE: JAXRSUriInfoTest test failure...
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 JAXRSUriInfoTest was failing in hudson and elsewhere so I fixed it on my machine by modifying the test, but could you re-look at it. I'm not sure if my fix was proper or if the original test was correct but the code isn't working. Thanks! -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Changing Message.REQUEST_URI and Message.HTTP_REQUEST_METHOD values
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 issues this minor refactoring might cause given that CXF code does not inline these properties given they're transient and it uses Message.REQUEST_URI and Message.HTTP_REQUEST_METHOD but not the explicit values... I'd like to ensure CXF JAXRS non-HTTP consumers can get additional headers set if needed and say org.apache.cxf.request.method is better than org.apache.cxf.message.Message.HTTP_REQUEST_METHOD Thoughts ? cheers, Sergey
Re: Apache Licensed JAX-RS Spec API JAR
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 solution (which is good but it is a specific one nonetheless) to do with the use of the OsgiLocator... cheers, Sergey Have you considered just using the ServiceMix versions of the JSR-311 spec? Code here: http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.0/ http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/jsr311-api-1.1/ Artefacts here: http://repo2.maven.org/maven2/org/apache/servicemix/specs/org.apache.servicemix.specs.jsr311-api-1.0/ http://repo2.maven.org/maven2/org/apache/servicemix/specs/org.apache.servicemix.specs.jsr311-api-1.1/ These are Apache licensed. Cheers, Eoghan On 11 February 2010 10:42, Rick McGuire rick...@gmail.com wrote: On 2/10/2010 4:07 PM, Bryant Luk wrote: Hi, We (some followers to Wink dev mailing list) were wondering if the CXF dev community would be interested in helping to contribute/consume a JAX-RS 1.0/1.1 API JAR for Geronimo's spec jars that were Apache licensed. I couldn't find an Apache licensed version of the JSR-311 spec. I see other communities that have implemented JSR specs are using Apache licensed of their specs. I don't know the exact procedure to contribute a spec api jar to Geronimo, but I don't think this would take too much effort considering that most of the JAX-RS spec is annotation/interface based with very few actual classes. Creating a JAX-RS spec jar is definitely in our plans, but it just hasn't happened yet because we haven't started looking at integrating this support yet. We even have a Jira open for this particular task: http://issues.apache.org/jira/browse/GERONIMO-5095 If you'd like to contribute code for this, the easiest way would be to attach a patch to that Jira issue. Rick On Wed, Feb 10, 2010 at 2:50 PM, Davanum Srinivasdava...@gmail.com wrote: Got it. i mis-remembered seeing a jax-rs api jar from geronimo. Looks like CXF uses the CDDL jar as well. May be we should ping them to see if they would be interested. +1 from me. -- dims On Wed, Feb 10, 2010 at 3:44 PM, Nicholas L Gallardo nlgal...@us.ibm.com wrote: +1 from me Bryant. There isn't a JSR spec for JAX-RS available in Geronimo as of yet. I don't know where they've come from in the past, but I'm assuming they've been contributed by the relevant technical teams/communities. The API jar currently in the maven repo is CDDL licensed. -Nick Davanum Srinivas ---02/10/2010 02:40:56 PM---Why can't we use the JSR spec from geronimo? :) Davanum Srinivasdava...@gmail.com 02/10/2010 02:40 PM Please respond to wink-...@incubator.apache.org To wink-...@incubator.apache.org cc Subject Re: Apache Licensed JAX-RS Spec API JAR Why can't we use the JSR spec from geronimo? :) -- dims On Wed, Feb 10, 2010 at 3:32 PM, Bryant Lukbryant@gmail.com wrote: Hi, I see that several Apache projects based on JSR specs have geronimo (Apache licensed) versions of the spec. Should we also consider contributing one for JAX-RS 1.0 and 1.1? I don't see one in the Maven repository that's Apache licensed. Thanks. -- Davanum Srinivas :: http://davanum.wordpress.com -- Davanum Srinivas :: http://davanum.wordpress.com
Re: threadlocal memory leak on shared_factory?
Hi It has been fixed : http://svn.apache.org/viewvc?rev=909411view=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 users can explicitly register jaxb or (default) json providers, which are the only two providers in the default list which have the contexts injected thanks a million for spotting it. Sergey Hello, I have built out a REST service that relies on the JAXBElementProvider for writing the response. However, I didn't explicitly add the JAXBElementProvider into provider configuration: jaxrs:server id=metaDataRestService address=/ jaxrs:serviceBeans ref bean=metaDataService / /jaxrs:serviceBeans jaxrs:providers ref bean=authenticationHandler / ref bean=runtimeExceptionMapper / /jaxrs:providers /jaxrs:server I was relying on the ProviderFactory.SHARED_FACTORY for supplying the JAXBElementProvider as the message writer. Everything functionally works fine but occasionally encounter OOM exceptions with the heap dump clearly pointing to large amounts of memory being held onto in the threadlocalproxy. After further investigation, it looks to me like the SHARED_FACTORY never registers its providers when they are used, so clearThreadLocalProxies are NEVER called on them. If i explicitly add the JAXBElementProvider the issues seems to have resolved the issue: bean id=jaxbProvider class=org.apache.cxf.jaxrs.provider.JAXBElementProvider / jaxrs:server id=metaDataRestService address=/ jaxrs:serviceBeans ref bean=metaDataService / /jaxrs:serviceBeans jaxrs:providers ref bean=authenticationHandler / ref bean=runtimeExceptionMapper / ref bean=jaxbProvider / /jaxrs:providers /jaxrs:server Has anyone else had problems with this happening? Can someone more familiar with the code base comment on this potential defect? It looks to me like maybe a simple fix could be to make sure handleMapper((List)candidates, ep, type, m); even if the SHARED_FACTORY is used. tags: threadlocal, threadlocalproxies, OutOfMemoryException, memory leak -- View this message in context: http://old.nabble.com/threadlocal-memory-leak-on-shared_factory--tp27555162p27555162.html Sent from the cxf-dev mailing list archive at Nabble.com.
How to have JAXB SchemaCompiler generating code for schema elements
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 configure SchemaCompiler to generate the code for xs:elements ? thanks, Sergey
Re: How to have JAXB SchemaCompiler generating code for schema elements
Hi Dan This is useful, I may play with it later on, and the hint to do with causing anonymous types be created is something we can advise to code-first users...I needed classes created from element for wadl:representation/@element values be resolved easier but I also ended up creating a map of 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 dk...@apache.org To: dev@cxf.apache.org Cc: Sergey Beryozkin sbery...@progress.com Sent: Wednesday, February 24, 2010 5:08 PM Subject: Re: How to have JAXB SchemaCompiler generating code for schema elements Since you are mucking in code, if you create a binding customization file that has a jaxb:globalBindings element with generateElementClass=true attribute, it will generate a class for the element. It's kind of an ugly class though and possibly not really usable. Dan On Tue February 23 2010 12:02:59 pm Sergey Beryozkin wrote: 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 configure SchemaCompiler to generate the code for xs:elements ? thanks, Sergey -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
Re: dOSGi: Change the startup of the DSW to Spring
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/inlcude DOSGI RI). Thus making DSW to start from Spring does not look like an ideal option to me...Also, as I noted in [1], we could find it more difficult to do things other than expressing service registration or dependencies requirements which is what you can do in Spring DM contexts cheers, Sergey - Original Message - From: Marc Schaaf m...@marc-schaaf.de To: dev@cxf.apache.org Sent: Thursday, February 25, 2010 9:33 AM Subject: dOSGi: Change the startup of the DSW to Spring Hi, with regard to [1] I would like to change the startup of the dOSGi DSW from a normal OSGi activator to Spring. This way the DSW would be started by the Spring OSGi Extender bundles which would solve an issue with the intent map loading. Currently the intent map is only successfully loaded by the DSW if the Spring OSGi Extender was started before. Are there any objections against this approach ? Thanks, Marc [1] http://issues.apache.org/jira/browse/DOSGI-66
Re: [VOTE] David Valeri for committer
+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 unit tests and such.The WS-Security stuff is a very complex area of code and he's doing a great job picking it up and fixing issues in it. Here's my +1. Vote will be open for at least 72 hours.
Re: [VOTE] Release CXF 2.2.7
+1 ! Sergey On Fri, Mar 19, 2010 at 1:21 AM, Daniel Kulp dk...@apache.org 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/secure/ReleaseNote.jspa?version=12314534styleName=HtmlprojectId=12310511Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-006/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-006/org/apache/cxf/apache-cxf/2.2.7/ This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.7 The vote will be open for 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Re: Google Summer of Code ideas.....
- 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 page plus provided an option to follow the links to the next/prev/etc pages - Simple HTML based console for displaying the exchange data (jaxws/jaxrs) persisted by PersistIn/Out interceptors; this console will communicate with a CXF JAXRS endpoint, all to be added to the rt/management-web; I'll be willing to act as a mentor cheers, Sergey On Fri, Mar 19, 2010 at 2:24 AM, Daniel Kulp dk...@apache.org wrote: The Google Summer of Code program is starting up. Last year, we had a very good project completed (SOAP/JMS Spec) and significant work started toward the SOAP/TCP stuff. At this point, it would be good to start collecting ideas that students may be interested in tackling. So, what really cool ideas do people have? :-) -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
Moving org.apache.cxf.jaxb.attachment from cxf-rt-databinding-jaxb to cxf-common-utilities
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 this moment of time, instead I suggest moving the package to a common-utilities component, which already has an org.apache.cxf.jaxb package. Any objections ? cheers, Sergey
Re: Moving org.apache.cxf.jaxb.attachment from cxf-rt-databinding-jaxb to cxf-common-utilities
Hmm...Those classes depend on the CXF Attachment class which lives in the api module built after the common-utilities. Moving it into rt/core, org.apache.cxf.attachment.jaxb, may not be the best idea. I'll probably just add copies to a rt/frontend/jaxrs, given that there won't be 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 sberyoz...@gmail.comwrote: 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 this moment of time, instead I suggest moving the package to a common-utilities component, which already has an org.apache.cxf.jaxb package. Any objections ? cheers, Sergey
Re: [GSOC][CXF-2736] Proposal for Simple and lightweight Atom HTML-based browser for CXF logs
Hi Tomasz thanks for your interest. I'd be happy to be a mentor. Just a couple of clarifications with respect to your proposal : - CXF JAXRS endpoint acting as an Atom Pull server has already been added to a rt/management component, I've briefly described it here : http://sberyozkin.blogspot.com/2010/02/use-your-favorite-atom-reader-to-view.html. I'll make sure that by the time you start working on this project the documentation will be up-to-date. To my knowledge, no existing atom readers support the paged/archived feeds well, thus the idea for the OTB browser has come up. Indeed, as you mentioned in your proposal, the same browser may be extended later on to support the viewing of the CXF exchanges, it is for this latter task when a dedicated CXF JAXRS endpoint will have to be added. - The question of security will need to be addressed as well. Most likely we'll need to use a WSSE UserToken for the Atom authentication, basic authentication over HTTPs may not be a practical solution for viewing the logs... Please post your ideas/questions to this thread when you start working and we'll be glad to help cheers, Sergey On Tue, Mar 30, 2010 at 11: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 create my proposal. I guess that Sergey Beryozkin will be mentor for this project. - Proposal in ASF wiki: http://wiki.apache.org/general/soc2010-cxf2736-proposal - Proposal in GSOC: http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/tomekopo/t126998466755 Any comments and suggestions are welcome. Thanks in advance for your feedback. Best Regards, Tomasz Oponowicz
Re: [jira] Commented: (CXF-2741) JAXB hang on JBoss 5.1.0
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) j...@apache.orgwrote:
[
https://issues.apache.org/jira/browse/CXF-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12852827#action_12852827]
Jeffrey Poore commented on CXF-2741:
It appears that this is some kind of subtle JVM bug. I took a grass roots
JBoss and put the war on it containing a minimal hello world service and it
runs fine without hanging. Then put our normal war on it, still runs fine.
We have some JNDI's that we add and some database connections, and it still
worked after adding those. Then I added in the extra JVM parameters we pass
in, and it hangs. I'm working on figuring out which one it is, but this is
not a CXF issue, so I'm resolving.
Thanks for your help gentlemen.
JAXB hang on JBoss 5.1.0
Key: CXF-2741
URL: https://issues.apache.org/jira/browse/CXF-2741
Project: CXF
Issue Type: Bug
Components: JAXB Databinding
Affects Versions: 2.2.6
Environment: JBoss 5.1.0.GA, Spring 2.5.6,
javax.ws.rs.jsr311-api 1.1
Reporter: Jeffrey Poore
We have been using CXF RESTFul services for a long time on jboss-4.2.3
with no issues. When we switched to JBoss 5.1.0.GA, things worked fine at
first, but we noticed that after a short period of uptime, requests began to
hang and time out. Debugging this issue, we tracked it to the synchronized
block in AbstractJAXBProvider.java:
{code}
JAXBElementProvider(AbstractJAXBProvider).getPackageContext(Class?)
line: 377
JAXBElementProvider(AbstractJAXBProvider).getJAXBContext(Class?, Type)
line: 354
JAXBElementProvider(AbstractJAXBProvider).createMarshaller(Object,
Class?, Type, String) line: 453
JAXBElementProvider.marshal(Object, Class?, Type, String, OutputStream,
MediaType) line: 296
JAXBElementProvider.writeTo(Object, Class?, Type, Annotation[],
MediaType, MultivaluedMapString,Object, OutputStream) line: 219
JAXRSOutInterceptor.serializeMessage(Message, Response,
OperationResourceInfo, boolean) line: 241
JAXRSOutInterceptor.processResponse(Message) line: 138
JAXRSOutInterceptor.handleMessage(Message) line: 77
PhaseInterceptorChain.doIntercept(Message) line: 243
OutgoingChainInterceptor.handleMessage(Message) line: 76
PhaseInterceptorChain.doIntercept(Message) line: 243
ChainInitiationObserver.onMessage(Message) line: 109
ServletDestination.invoke(ServletConfig, ServletContext,
HttpServletRequest, HttpServletResponse) line: 98
ServletController.invokeDestination(HttpServletRequest,
HttpServletResponse, ServletDestination) line: 406
ServletController.invoke(HttpServletRequest, HttpServletResponse) line:
139
CXFServlet(AbstractCXFServlet).invoke(HttpServletRequest,
HttpServletResponse) line: 142
CXFServlet(AbstractHTTPServlet).handleRequest(HttpServletRequest,
HttpServletResponse) line: 179
CXFServlet(AbstractHTTPServlet).doGet(HttpServletRequest,
HttpServletResponse) line: 108
CXFServlet(HttpServlet).service(HttpServletRequest, HttpServletResponse)
line: 617
CXFServlet(AbstractHTTPServlet).service(ServletRequest, ServletResponse)
line: 159
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
line: 290
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line:
206
ReplyHeaderFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
line: 96
ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
line: 235
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line:
206
StandardWrapperValve.invoke(Request, Response) line: 235
StandardContextValve.invoke(Request, Response) line: 191
SecurityAssociationValve.invoke(Request, Response) line: 190
JaccContextValve.invoke(Request, Response) line: 92
SecurityContextEstablishmentValve.process(Request, Response, HttpEvent)
line: 126
SecurityContextEstablishmentValve.invoke(Request, Response) line: 70
StandardHostValve.invoke(Request, Response) line: 127
ErrorReportValve.invoke(Request, Response) line: 102
CachedConnectionValve.invoke(Request, Response) line: 158
StandardEngineValve.invoke(Request, Response) line: 109
CoyoteAdapter.service(Request, Response) line: 330
Http11Processor.process(Socket) line: 829
Http11Protocol$Http11ConnectionHandler.process(Socket) line: 598
JIoEndpoint$Worker.run() line: 447
Thread.run() line: 619
{code}
Specifically, this method:
{code}
public JAXBContext getPackageContext(Class? type) {
if (type == null || type == JAXBElement.class) {
return null;
}
synchronized (packageContexts) {
String packageName =
