Re: [VOTE] Release CXF 2.0.12
+1 /Eoghan 2009/7/29 Daniel Kulp dk...@apache.org: 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/apache/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.1.6
+1 /Eoghan 2009/7/29 Daniel Kulp dk...@apache.org: 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/apache/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: [VOTE] Release CXF 2.1.6
+1 -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: [VOTE] Release CXF 2.2.3
+1 -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: 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. This
Re: Reusing CXF DataBindings in the JAX-RS implementation
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. 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
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
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
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
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: SOAP/TCP project status...
Krzysztof, I've FINALLY had a chance to look at this. I've gone ahead and added it into the soap binding and wired it into the normal soap transport.It's definitely a good start. Still plenty of work to do, but the simple case is working. I've even tested it a bit with the Sun Glassfish calculator sample. I had to update a few things regarding the negotiated stuff, but it did do a full request/response. There's definitely quite a bit of work to be done on it for a complete solution, notable the fastinfoset support stuff, but the server side part is definitely a higher priority right now. I'll probably help out a bit on the client side now that you have the basics working since it's quite interesting. :-)I have other work to finish up first though. Dan On Mon July 27 2009 12:16:41 pm Daniel Kulp wrote: On Fri July 24 2009 5:37:16 pm Krzysztof Wilkos wrote: 2009/7/7 Daniel Kulp dk...@apache.org: I've get rid of XPP dependancy and rewritten utility class from metro, added Apache licence header, some javadocs and corrected code to match CXF convention. I also added more error handling. There are some javadocs left and maven poms. I have no experience with maven so I need some help. https://issues.apache.org/jira/secure/attachment/12414476/soaptcp.patch I'll take a look at this most likely tomorrow. I'm a bit swamped today. :-( Thanks! -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
