Re: Ideas for 2.2
Christian Schneider wrote: I would really like to see good osgi integration as we plan to rely quite heavily on osgi in the future. But as I myself are only starting on this I don´t know much about the details. Basically I would like to be able to connect the osgi internal services with cxf to communicate with the outside world. So a client should be able to simply use an osgi service. The provider of the service could then be simply a local bundle or a cxf based kind of binding component that does the remoting. I hope somthing like this will come from servicemix. Christian, The scenario you mention - client just using OSGi services as it would in a purely local case, but with CXF transparently providing the remoting capability - is exactly what Distributed OSGi / RFC 119 is all about. So I think you're in luck :) Cheers, Eoghan Daniel Kulp schrieb: 5) OSGi stuff - I know there are some OSGi enhancements in the works that could be pulled in: a) osgi http transport - this currently lives in ServiceMix, but could be pulled into CXF to work with other OSGi runtimes b) Distributed OSGi (RFC 119) - there is work being done to implement RFC 119 with CXF. There are some rules about releasing the IP for this though that is being investigated.
Re: Ideas for 2.2
I think our WSS4J interceptors really need to support "nonces"--IIRC
according to WS-Security w/UsernameToken profile web service calls
aren't really secure if those aren't included with the username,
password, and timestamp. I am still not sure if WSS4J supports the SAML
Token Profile, but that would also something we probably need. Having
WS-SecureConversation would not be very meaningful for either SAML or
UsernameTokens if we don't have the latter two working yet. (The other
profile--X.509--I don't know how well that is supported presently, but
if working, WS-SecureConversation then becomes sensible.)
Possibly also, an ability to support Sun's XWSS product in addition to
WSS4J (although I'm aware of the performance issues you had mentioned
earlier), a nice-to-have since Spring-WS apparently supports both.
Perhaps also WSDL 2.0?
Glen
2008-06-18 Daniel Kulp wrote:
> Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
> a little about ideas for the next versions.
>
> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> weeks (and maybe 2.0.8 as well). We've done a very good job of
> getting fixes out to our users in a timely manner and I'd like to keep
> that up, but I also would like to think about 2.2 a bit as well. I
> haven't created the 2.1.x fixes branch yet, but I probably will
> shortly if we start doing some new stuff toward 2.2.
>
> That said, here is my list of stuff that is "missing" and could be
> considered for 2.2:
>
> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff.Not
> supporting these is becoming increasingly problematic. Most likely,
> when I get back from my paternity leave, I'm going to start digging
> into these a bit. I haven't really read up on these yet (in depth) so
> any help would be greatly appreciated.
>
> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will
> actually generate some interfaces for xmlbeans, but the sample clients/
> servers are wrong (don't set the jaxb databinding) and I'm not sure if
> the interfaces even work unless you use a jaxws customization to force
> everything into bare mode. Cleaning this stuff up could be a 2.1.x
> "fix" as well.
>
> 3) JIBX data binding - This is probably the last major thing not
> ported from XFire. Not sure the demand on it though.
>
> 4) Extension via annotation - Benson and I have chatted about this off
> and on.Basically, we'd like to add hooks into the
> ReflectServiceFactoryBean so that registered listeners can get events
> about when things happen. Like when an interface is mapped to a
> ServiceInfo, a method is mapped to a OperaionInfo and
> BingingOperationInfo, etc...The listeners can then examine the
> Method object or Class object or whatever for any additional things
> it's interested in at runtime. This would allow for some custom
> annotations. Examples:
> Configure some logging:
> @Logging(in = "in.log", out = "out.log", fault = "")
> Configure and IDL location for the corba binding:
> @IDLLocation("file:/foo.idl")
> Add documentation to the wsdl:
> @WSDLAnnotation("This operation does XXX")
> etc...
> Some of the stuff in the JAX-WS frontend could then be re-written to
> use that. Processing of the @WebServiceFeature annotations and stuff
> could be re-implemented that way. The main thing here is to make
> some of the java-first things work a bit better/easier. (our own
> @Features annotation could be deprecated in favor of explicit
> annotations for the features we have)
>
> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> that could be pulled in:
> a) osgi http transport - this currently lives in ServiceMix, but
> could be pulled into CXF to work with other OSGi runtimes
> b) Distributed OSGi (RFC 119) - there is work being done to
> implement RFC 119 with CXF. There are some rules about releasing the
> IP for this though that is being investigated.
>
> 6) JMS transport enhancements - I keep wanting to update this a bit to
> leverage spring jms stuff a bit better to make it much easier to
> configure.
>
> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
> come up with them.
>
> 8) Web site update? I'd like to possibly create a quick logo and
> update the site a bit to look a bit less like confluence. This is a
> "would be nice anytime, not just for 2.2" type thing.
>
>
> I'm sure there will be a bunch of other enhancements as well.Stuff
> like performance/memory enhancements, etc...
>
> Anyway, thoughts? Other ideas? Comments?
>
>
> ---
> Daniel Kulp
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
>
>
>
Re: Ideas for 2.2
I would really like to see good osgi integration as we plan to rely quite heavily on osgi in the future. But as I myself are only starting on this I don´t know much about the details. Basically I would like to be able to connect the osgi internal services with cxf to communicate with the outside world. So a client should be able to simply use an osgi service. The provider of the service could then be simply a local bundle or a cxf based kind of binding component that does the remoting. I hope somthing like this will come from servicemix. For the short term the jms enhancements are my favourite. Configuring the jms destination and jms conduit is really non intuitive and it does not follow spring standard procedures. The most important thing for me is externalising the ConnectionFactory. This should be defined in a separate bean and only be referenced from conduit and destination. I think there are two main use cases here. 1. You want to define the ConnectionFactory yourself. In a spearate bean this will be easy 2. You want to fetch the factory from jndi. In this case I would like to use the spring jee extensions or again a simple bean java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory java.naming.provider.url=tcp://localhost:10001 The last thing about jms is that I would like to be able to select the connection and configure the queue and other settings in the address of the service. I really like the way camel handles jms. Perhaps this can be done like in camel. So perhaps it is possible to not need the jms destination and jms conduit configs at all. Best regards Christian Daniel Kulp schrieb: Now that 2.1.1 is being voted on, I'd like to step back a bit and talk a little about ideas for the next versions. First, most likely, we'll need to do a 2.1.2 release in about 6-8 weeks (and maybe 2.0.8 as well). We've done a very good job of getting fixes out to our users in a timely manner and I'd like to keep that up, but I also would like to think about 2.2 a bit as well. I haven't created the 2.1.x fixes branch yet, but I probably will shortly if we start doing some new stuff toward 2.2. That said, here is my list of stuff that is "missing" and could be considered for 2.2: 5) OSGi stuff - I know there are some OSGi enhancements in the works that could be pulled in: a) osgi http transport - this currently lives in ServiceMix, but could be pulled into CXF to work with other OSGi runtimes b) Distributed OSGi (RFC 119) - there is work being done to implement RFC 119 with CXF. There are some rules about releasing the IP for this though that is being investigated. 6) JMS transport enhancements - I keep wanting to update this a bit to leverage spring jms stuff a bit better to make it much easier to configure. Anyway, thoughts? Other ideas? Comments?
Re: Ideas for 2.2
Daniel Kulp wrote: 5) OSGi stuff - I know there are some OSGi enhancements in the works that could be pulled in: a) osgi http transport - this currently lives in ServiceMix, but could be pulled into CXF to work with other OSGi runtimes b) Distributed OSGi (RFC 119) - there is work being done to implement RFC 119 with CXF. There are some rules about releasing the IP for this though that is being investigated. Sergey and myself have been working on a CXF-based reference implementation of RFC 119, and we'd be on for contributing this to CXF once the IP is cleared by the OGSi expert group. Hopefuly this will happen within the next month or so. Cheers, Eoghan IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Ideas for 2.2
I like the idea of custom annotations for making the Java-first stuff
work better.
On Wed, 2008-06-18 at 11:17 -0400, Daniel Kulp wrote:
> Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
> a little about ideas for the next versions.
>
> First, most likely, we'll need to do a 2.1.2 release in about 6-8
> weeks (and maybe 2.0.8 as well). We've done a very good job of
> getting fixes out to our users in a timely manner and I'd like to keep
> that up, but I also would like to think about 2.2 a bit as well. I
> haven't created the 2.1.x fixes branch yet, but I probably will
> shortly if we start doing some new stuff toward 2.2.
>
> That said, here is my list of stuff that is "missing" and could be
> considered for 2.2:
>
> 1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff.Not
> supporting these is becoming increasingly problematic. Most likely,
> when I get back from my paternity leave, I'm going to start digging
> into these a bit. I haven't really read up on these yet (in depth) so
> any help would be greatly appreciated.
>
> 2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will
> actually generate some interfaces for xmlbeans, but the sample clients/
> servers are wrong (don't set the jaxb databinding) and I'm not sure if
> the interfaces even work unless you use a jaxws customization to force
> everything into bare mode. Cleaning this stuff up could be a 2.1.x
> "fix" as well.
>
> 3) JIBX data binding - This is probably the last major thing not
> ported from XFire. Not sure the demand on it though.
>
> 4) Extension via annotation - Benson and I have chatted about this off
> and on.Basically, we'd like to add hooks into the
> ReflectServiceFactoryBean so that registered listeners can get events
> about when things happen. Like when an interface is mapped to a
> ServiceInfo, a method is mapped to a OperaionInfo and
> BingingOperationInfo, etc...The listeners can then examine the
> Method object or Class object or whatever for any additional things
> it's interested in at runtime. This would allow for some custom
> annotations. Examples:
> Configure some logging:
> @Logging(in = "in.log", out = "out.log", fault = "")
> Configure and IDL location for the corba binding:
> @IDLLocation("file:/foo.idl")
> Add documentation to the wsdl:
> @WSDLAnnotation("This operation does XXX")
> etc...
> Some of the stuff in the JAX-WS frontend could then be re-written to
> use that. Processing of the @WebServiceFeature annotations and stuff
> could be re-implemented that way. The main thing here is to make
> some of the java-first things work a bit better/easier. (our own
> @Features annotation could be deprecated in favor of explicit
> annotations for the features we have)
>
> 5) OSGi stuff - I know there are some OSGi enhancements in the works
> that could be pulled in:
> a) osgi http transport - this currently lives in ServiceMix, but
> could be pulled into CXF to work with other OSGi runtimes
> b) Distributed OSGi (RFC 119) - there is work being done to
> implement RFC 119 with CXF. There are some rules about releasing the
> IP for this though that is being investigated.
>
> 6) JMS transport enhancements - I keep wanting to update this a bit to
> leverage spring jms stuff a bit better to make it much easier to
> configure.
>
> 7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
> come up with them.
>
> 8) Web site update? I'd like to possibly create a quick logo and
> update the site a bit to look a bit less like confluence. This is a
> "would be nice anytime, not just for 2.2" type thing.
>
>
> I'm sure there will be a bunch of other enhancements as well.Stuff
> like performance/memory enhancements, etc...
>
> Anyway, thoughts? Other ideas? Comments?
>
>
> ---
> Daniel Kulp
> [EMAIL PROTECTED]
> http://www.dankulp.com/blog
>
>
>
Re: [VOTE] Release CXF 2.0.7
+1 2.0.7 fix the bug CXF-1642 :) --G Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.0.7 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.7 release. Over 48 JIRA issues are resolved for 2.0.7 which is a large number of fixes for the 2.0.x branch. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.7 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.7 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIV83Qq8juObtVB0YRAk9IAJ94zSGaE98mw4z2UOdcCeX8HzAntACfb4Zv Px3oDUHzRTC53LDAs2yxIz8= =fif0 -END PGP SIGNATURE-
Ideas for 2.2
Now that 2.1.1 is being voted on, I'd like to step back a bit and talk
a little about ideas for the next versions.
First, most likely, we'll need to do a 2.1.2 release in about 6-8
weeks (and maybe 2.0.8 as well). We've done a very good job of
getting fixes out to our users in a timely manner and I'd like to keep
that up, but I also would like to think about 2.2 a bit as well. I
haven't created the 2.1.x fixes branch yet, but I probably will
shortly if we start doing some new stuff toward 2.2.
That said, here is my list of stuff that is "missing" and could be
considered for 2.2:
1) WS-Trust/WS-SecurePolicy/WS-SecureConversation stuff.Not
supporting these is becoming increasingly problematic. Most likely,
when I get back from my paternity leave, I'm going to start digging
into these a bit. I haven't really read up on these yet (in depth) so
any help would be greatly appreciated.
2) XMLBeans tooling - I started this a bit for 2.1.1. 2.1.1 now will
actually generate some interfaces for xmlbeans, but the sample clients/
servers are wrong (don't set the jaxb databinding) and I'm not sure if
the interfaces even work unless you use a jaxws customization to force
everything into bare mode. Cleaning this stuff up could be a 2.1.x
"fix" as well.
3) JIBX data binding - This is probably the last major thing not
ported from XFire. Not sure the demand on it though.
4) Extension via annotation - Benson and I have chatted about this off
and on.Basically, we'd like to add hooks into the
ReflectServiceFactoryBean so that registered listeners can get events
about when things happen. Like when an interface is mapped to a
ServiceInfo, a method is mapped to a OperaionInfo and
BingingOperationInfo, etc...The listeners can then examine the
Method object or Class object or whatever for any additional things
it's interested in at runtime. This would allow for some custom
annotations. Examples:
Configure some logging:
@Logging(in = "in.log", out = "out.log", fault = "")
Configure and IDL location for the corba binding:
@IDLLocation("file:/foo.idl")
Add documentation to the wsdl:
@WSDLAnnotation("This operation does XXX")
etc...
Some of the stuff in the JAX-WS frontend could then be re-written to
use that. Processing of the @WebServiceFeature annotations and stuff
could be re-implemented that way. The main thing here is to make
some of the java-first things work a bit better/easier. (our own
@Features annotation could be deprecated in favor of explicit
annotations for the features we have)
5) OSGi stuff - I know there are some OSGi enhancements in the works
that could be pulled in:
a) osgi http transport - this currently lives in ServiceMix, but
could be pulled into CXF to work with other OSGi runtimes
b) Distributed OSGi (RFC 119) - there is work being done to
implement RFC 119 with CXF. There are some rules about releasing the
IP for this though that is being investigated.
6) JMS transport enhancements - I keep wanting to update this a bit to
leverage spring jms stuff a bit better to make it much easier to
configure.
7) JAX-RS updates - to 0.7 at least. Maybe later versions as they
come up with them.
8) Web site update? I'd like to possibly create a quick logo and
update the site a bit to look a bit less like confluence. This is a
"would be nice anytime, not just for 2.2" type thing.
I'm sure there will be a bunch of other enhancements as well.Stuff
like performance/memory enhancements, etc...
Anyway, thoughts? Other ideas? Comments?
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
RE: [VOTE] Release CXF 2.1.1
+1 -- Pawel Lipka IT Architect AMG.net businesstechnology consulting http://www.amg.net.pl Łąkowa 11, 90-554 Lodz, tel/fax (42) 296 11 32 Tresc niniejszej wiadomosci moze byc poufna. Jezeli nie jestescie Panstwo jej adresatem, to rozprowadzanie lub wykorzystywanie zawartych tu informacji jest zabronione. -Original Message- From: Daniel Kulp [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 17, 2008 4:42 PM To: dev@cxf.apache.org Subject: [VOTE] Release CXF 2.1.1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.1.1 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1 release. Over 74 JIRA issues are resolved for 2.1.1 which is a large number of fixes. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.1.1 The distributions are in the "dist" directory. The "maven" directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1.1 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIV80oq8juObtVB0YRAiLyAJ9+HiWq61I9JZ01kRpr4g+L1O7woQCcCHbK G1xxwnA5MSe77DORVGTRy3o= =cx57 -END PGP SIGNATURE-
Re: [VOTE] Release CXF 2.0.7
+1 On Tue, Jun 17, 2008 at 4:44 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > This is a vote to release CXF 2.0.7 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.0.7 release. Over 48 JIRA issues are > resolved for 2.0.7 which is a large number of fixes for the 2.0.x branch. > > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.0.7 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.7 > > > Here is my +1. The vote will be open here for at least 72 hours. > > > - --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.4 (Darwin) > > iD8DBQFIV83Qq8juObtVB0YRAk9IAJ94zSGaE98mw4z2UOdcCeX8HzAntACfb4Zv > Px3oDUHzRTC53LDAs2yxIz8= > =fif0 > -END PGP SIGNATURE- > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
