You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dan Diephouse <da...@envoisolutions.com> on 2007/03/11 23:21:08 UTC
Release Update
Hi folks,
We're getting to the point that I think we're closing in on our next
release. So I'd like to recap the big issues that are outstanding that I
see:
- WS-Security & SecureConversation & Trust - I would really really like to
see us be able to support this for interop with WCF.
- Tooling refactoring
(this includes cleanup of java2wsdl in runtime, I want to see wsdl
generation using the service model from our service factories before a
release)
- JAX-WS TCK Testing (see below)
- CXF-28: Nice XML - we should finish moving away from our property editors
to spring 2.0 handlers
- We have no service routing story or examples
- schema duplication in common/metacode?
- Other open JIRAs
We are also in BIG need of documentation. Specifically:
- Using Spring 2.0 config syntax
- HTTP Transport
- WS-RM
- WS-Policy
- XFire migration docs
- Using Aegis databinding
- Using WSDL2Java & Java2WSDL in Maven & Ant
At this point I see the following features probably being pushed to 2.1:
- WSDL 2.0 support
- XMLBeans support (this may or may not be possible to integrate in as part
of the Aegis module, the big question is tooling - any volunteers?)
- Any other WS-* work
Re: JAX-WS - Can someone do some legwork and check if Apache will let us do
a 2.0 final release without passing the TCK? Then we can focus on passing
the TCK for 2.1. This would involve starting a discussion on
general@incubator. If we are positioning ourselves as just a JAX-WS
implementation I can see how they wouldn't let us do release. But I think
there are a lot of uses which don't center around JAX-WS that we focus on.
For instance, there are a lot of XFire users who aren't using the JAX-WS
features and so I would like to get them migrating ASAP so I can consolidate
bug fixes in one place. As long as we're clear that compliance is not
claimed we should be ok.
What other items do people see?
I think we should target starting a vote by March 30th, but we have a fair
amount to do before then I think you can see. Please claim any JIRA issues
you intend to tackle so its easier to see who is planning on working on
what. I'm incredibly excited to get a new release out. CXF is looking great
and its time for the world to really start using it!
(BTW, I am focusing in on the security specifications this week unless
someone else wants to volunteer. I could definitely spend some more time on
routing or Aegis instead)
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Release Update
Posted by Dan Diephouse <da...@envoisolutions.com>.
Just saw that you have a page in the wiki:
http://cwiki.apache.org/confluence/display/CXF/WS-Policy+Framework
Cool :-) One suggestion, you might want to put that in the CXF20DOC wiki
under the developer section as opposed the CXF wiki.
Regards,
- Dan
On 3/15/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> OK, good to know. I think the development guide could possibly come
> between 2.0-RC and 2.0.
>
> Any chance you can give a quick rundown of the current WS-Policy
> integration for someone who is looking at doing WS-SecurityPolicy
> integration?
>
> - Dan
>
> On 3/14/07, Andrea Smyth <an...@iona.com> wrote:
> >
> > Hi Dan,
> >
> > Outstanding issues for WS-RM (e.g. persistence) and WS-Policy make the
> > March 30th target seem a bit unlikely from my point of view. And these
> > issues do not include documentation. Especially for WS-Policy we will
> > need a development guide to help users develop domain specific
> > assertions.
> > If we are not aiming at another milestone but a real CXF release, I
> > would prefer these features being more rounded off if not altogether
> > completed rather than come up with many restrictions in READMEs - it
> > will give a better overall impression IMO.
> >
> > Cheers,
> > Andrea.
> >
> > Dan Diephouse wrote:
> >
> > > Hi folks,
> > >
> > > We're getting to the point that I think we're closing in on our next
> > > release. So I'd like to recap the big issues that are outstanding that
> > I
> > > see:
> > >
> > > - WS-Security & SecureConversation & Trust - I would really really
> > > like to
> > > see us be able to support this for interop with WCF.
> > > - Tooling refactoring
> > > (this includes cleanup of java2wsdl in runtime, I want to see wsdl
> > > generation using the service model from our service factories before a
> > > release)
> > > - JAX-WS TCK Testing (see below)
> > > - CXF-28: Nice XML - we should finish moving away from our property
> > > editors
> > > to spring 2.0 handlers
> > > - We have no service routing story or examples
> > > - schema duplication in common/metacode?
> > > - Other open JIRAs
> > >
> > > We are also in BIG need of documentation. Specifically:
> > > - Using Spring 2.0 config syntax
> > > - HTTP Transport
> > > - WS-RM
> > > - WS-Policy
> > > - XFire migration docs
> > > - Using Aegis databinding
> > > - Using WSDL2Java & Java2WSDL in Maven & Ant
> > >
> > > At this point I see the following features probably being pushed to
> > 2.1:
> > > - WSDL 2.0 support
> > > - XMLBeans support (this may or may not be possible to integrate in as
> >
> > > part
> > > of the Aegis module, the big question is tooling - any volunteers?)
> > > - Any other WS-* work
> > >
> > > Re: JAX-WS - Can someone do some legwork and check if Apache will let
> > > us do
> > > a 2.0 final release without passing the TCK? Then we can focus on
> > passing
> > > the TCK for 2.1. This would involve starting a discussion on
> > > general@incubator. If we are positioning ourselves as just a JAX-WS
> > > implementation I can see how they wouldn't let us do release. But I
> > think
> > > there are a lot of uses which don't center around JAX-WS that we focus
> > > on.
> > > For instance, there are a lot of XFire users who aren't using the
> > JAX-WS
> > > features and so I would like to get them migrating ASAP so I can
> > > consolidate
> > > bug fixes in one place. As long as we're clear that compliance is not
> > > claimed we should be ok.
> > >
> > > What other items do people see?
> > >
> > > I think we should target starting a vote by March 30th, but we have a
> > > fair
> > > amount to do before then I think you can see. Please claim any JIRA
> > > issues
> > > you intend to tackle so its easier to see who is planning on working
> > on
> > > what. I'm incredibly excited to get a new release out. CXF is looking
> > > great
> > > and its time for the world to really start using it!
> > >
> > > (BTW, I am focusing in on the security specifications this week unless
> >
> > > someone else wants to volunteer. I could definitely spend some more
> > > time on
> > > routing or Aegis instead)
> > >
> > > - Dan
> >
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Release Update
Posted by Dan Diephouse <da...@envoisolutions.com>.
OK, good to know. I think the development guide could possibly come between
2.0-RC and 2.0.
Any chance you can give a quick rundown of the current WS-Policy integration
for someone who is looking at doing WS-SecurityPolicy integration?
- Dan
On 3/14/07, Andrea Smyth <an...@iona.com> wrote:
>
> Hi Dan,
>
> Outstanding issues for WS-RM (e.g. persistence) and WS-Policy make the
> March 30th target seem a bit unlikely from my point of view. And these
> issues do not include documentation. Especially for WS-Policy we will
> need a development guide to help users develop domain specific assertions.
> If we are not aiming at another milestone but a real CXF release, I
> would prefer these features being more rounded off if not altogether
> completed rather than come up with many restrictions in READMEs - it
> will give a better overall impression IMO.
>
> Cheers,
> Andrea.
>
> Dan Diephouse wrote:
>
> > Hi folks,
> >
> > We're getting to the point that I think we're closing in on our next
> > release. So I'd like to recap the big issues that are outstanding that I
> > see:
> >
> > - WS-Security & SecureConversation & Trust - I would really really
> > like to
> > see us be able to support this for interop with WCF.
> > - Tooling refactoring
> > (this includes cleanup of java2wsdl in runtime, I want to see wsdl
> > generation using the service model from our service factories before a
> > release)
> > - JAX-WS TCK Testing (see below)
> > - CXF-28: Nice XML - we should finish moving away from our property
> > editors
> > to spring 2.0 handlers
> > - We have no service routing story or examples
> > - schema duplication in common/metacode?
> > - Other open JIRAs
> >
> > We are also in BIG need of documentation. Specifically:
> > - Using Spring 2.0 config syntax
> > - HTTP Transport
> > - WS-RM
> > - WS-Policy
> > - XFire migration docs
> > - Using Aegis databinding
> > - Using WSDL2Java & Java2WSDL in Maven & Ant
> >
> > At this point I see the following features probably being pushed to 2.1:
> > - WSDL 2.0 support
> > - XMLBeans support (this may or may not be possible to integrate in as
> > part
> > of the Aegis module, the big question is tooling - any volunteers?)
> > - Any other WS-* work
> >
> > Re: JAX-WS - Can someone do some legwork and check if Apache will let
> > us do
> > a 2.0 final release without passing the TCK? Then we can focus on
> passing
> > the TCK for 2.1. This would involve starting a discussion on
> > general@incubator. If we are positioning ourselves as just a JAX-WS
> > implementation I can see how they wouldn't let us do release. But I
> think
> > there are a lot of uses which don't center around JAX-WS that we focus
> > on.
> > For instance, there are a lot of XFire users who aren't using the JAX-WS
> > features and so I would like to get them migrating ASAP so I can
> > consolidate
> > bug fixes in one place. As long as we're clear that compliance is not
> > claimed we should be ok.
> >
> > What other items do people see?
> >
> > I think we should target starting a vote by March 30th, but we have a
> > fair
> > amount to do before then I think you can see. Please claim any JIRA
> > issues
> > you intend to tackle so its easier to see who is planning on working on
> > what. I'm incredibly excited to get a new release out. CXF is looking
> > great
> > and its time for the world to really start using it!
> >
> > (BTW, I am focusing in on the security specifications this week unless
> > someone else wants to volunteer. I could definitely spend some more
> > time on
> > routing or Aegis instead)
> >
> > - Dan
>
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Release Update
Posted by Andrea Smyth <an...@iona.com>.
Hi Dan,
Outstanding issues for WS-RM (e.g. persistence) and WS-Policy make the
March 30th target seem a bit unlikely from my point of view. And these
issues do not include documentation. Especially for WS-Policy we will
need a development guide to help users develop domain specific assertions.
If we are not aiming at another milestone but a real CXF release, I
would prefer these features being more rounded off if not altogether
completed rather than come up with many restrictions in READMEs - it
will give a better overall impression IMO.
Cheers,
Andrea.
Dan Diephouse wrote:
> Hi folks,
>
> We're getting to the point that I think we're closing in on our next
> release. So I'd like to recap the big issues that are outstanding that I
> see:
>
> - WS-Security & SecureConversation & Trust - I would really really
> like to
> see us be able to support this for interop with WCF.
> - Tooling refactoring
> (this includes cleanup of java2wsdl in runtime, I want to see wsdl
> generation using the service model from our service factories before a
> release)
> - JAX-WS TCK Testing (see below)
> - CXF-28: Nice XML - we should finish moving away from our property
> editors
> to spring 2.0 handlers
> - We have no service routing story or examples
> - schema duplication in common/metacode?
> - Other open JIRAs
>
> We are also in BIG need of documentation. Specifically:
> - Using Spring 2.0 config syntax
> - HTTP Transport
> - WS-RM
> - WS-Policy
> - XFire migration docs
> - Using Aegis databinding
> - Using WSDL2Java & Java2WSDL in Maven & Ant
>
> At this point I see the following features probably being pushed to 2.1:
> - WSDL 2.0 support
> - XMLBeans support (this may or may not be possible to integrate in as
> part
> of the Aegis module, the big question is tooling - any volunteers?)
> - Any other WS-* work
>
> Re: JAX-WS - Can someone do some legwork and check if Apache will let
> us do
> a 2.0 final release without passing the TCK? Then we can focus on passing
> the TCK for 2.1. This would involve starting a discussion on
> general@incubator. If we are positioning ourselves as just a JAX-WS
> implementation I can see how they wouldn't let us do release. But I think
> there are a lot of uses which don't center around JAX-WS that we focus
> on.
> For instance, there are a lot of XFire users who aren't using the JAX-WS
> features and so I would like to get them migrating ASAP so I can
> consolidate
> bug fixes in one place. As long as we're clear that compliance is not
> claimed we should be ok.
>
> What other items do people see?
>
> I think we should target starting a vote by March 30th, but we have a
> fair
> amount to do before then I think you can see. Please claim any JIRA
> issues
> you intend to tackle so its easier to see who is planning on working on
> what. I'm incredibly excited to get a new release out. CXF is looking
> great
> and its time for the world to really start using it!
>
> (BTW, I am focusing in on the security specifications this week unless
> someone else wants to volunteer. I could definitely spend some more
> time on
> routing or Aegis instead)
>
> - Dan
Re: Release Update
Posted by Bozhong Lin <bl...@iona.com>.
FYI, I just posted any email to Apache general mailing list regarding to
JAX-WS TCK thing.
Cheers,
Bo
Dan Diephouse wrote:
> Hi folks,
>
> We're getting to the point that I think we're closing in on our next
> release. So I'd like to recap the big issues that are outstanding that I
> see:
>
> - WS-Security & SecureConversation & Trust - I would really really
> like to
> see us be able to support this for interop with WCF.
> - Tooling refactoring
> (this includes cleanup of java2wsdl in runtime, I want to see wsdl
> generation using the service model from our service factories before a
> release)
> - JAX-WS TCK Testing (see below)
> - CXF-28: Nice XML - we should finish moving away from our property
> editors
> to spring 2.0 handlers
> - We have no service routing story or examples
> - schema duplication in common/metacode?
> - Other open JIRAs
>
> We are also in BIG need of documentation. Specifically:
> - Using Spring 2.0 config syntax
> - HTTP Transport
> - WS-RM
> - WS-Policy
> - XFire migration docs
> - Using Aegis databinding
> - Using WSDL2Java & Java2WSDL in Maven & Ant
>
> At this point I see the following features probably being pushed to 2.1:
> - WSDL 2.0 support
> - XMLBeans support (this may or may not be possible to integrate in as
> part
> of the Aegis module, the big question is tooling - any volunteers?)
> - Any other WS-* work
>
> Re: JAX-WS - Can someone do some legwork and check if Apache will let
> us do
> a 2.0 final release without passing the TCK? Then we can focus on passing
> the TCK for 2.1. This would involve starting a discussion on
> general@incubator. If we are positioning ourselves as just a JAX-WS
> implementation I can see how they wouldn't let us do release. But I think
> there are a lot of uses which don't center around JAX-WS that we focus
> on.
> For instance, there are a lot of XFire users who aren't using the JAX-WS
> features and so I would like to get them migrating ASAP so I can
> consolidate
> bug fixes in one place. As long as we're clear that compliance is not
> claimed we should be ok.
>
> What other items do people see?
>
> I think we should target starting a vote by March 30th, but we have a
> fair
> amount to do before then I think you can see. Please claim any JIRA
> issues
> you intend to tackle so its easier to see who is planning on working on
> what. I'm incredibly excited to get a new release out. CXF is looking
> great
> and its time for the world to really start using it!
>
> (BTW, I am focusing in on the security specifications this week unless
> someone else wants to volunteer. I could definitely spend some more
> time on
> routing or Aegis instead)
>
> - Dan
Re: Release Update
Posted by James Mao <ja...@iona.com>.
Hi,
> - Tooling refactoring
> (this includes cleanup of java2wsdl in runtime, I want to see wsdl
> generation using the service model from our service factories before a
> release)
FYI, We already use the runtime service factory to generate the wsdl in
java2wsdl tool in tools2
> - Using WSDL2Java & Java2WSDL in Maven & Ant
We do have maven plugin and ant macro to do the wsdl2java, but we don't
have the plugin/macro to do the java2wsdl
Cheers,
James.
Re: The implementation of a simple service routing. WAS: RE: Release Update
Posted by Dan Diephouse <da...@envoisolutions.com>.
Nice work Jervis.
I think we both share a lot of the same concerns about this approach. Some
thoughts:
1. From a CXF point of view an address is typically associated with one
service/endpoint. It seems odd to require people to register each service on
a different endpoint and then have another endpoint which routes between
them. From a conceptual point of view a user wants to associate multiple
services with a single endpoint. Or, in your example, what if the user just
wants to expose the http://localhost:9027/SoapContext/SoapPort endpoint and
not http://localhost:9027/SoapContext1/SoapPort?
I guess there are a few ways around this. The simplest would be to use some
kind of local service transport which the mediation interceptor could route
with.
Endpoint.publish("service://service1", service1);
Endpoint.publish("service://service2", service2);
Endpoint.publish("http://localhost/myService", routingService);
There is also the means that I outlined in that email that you linked to in
your previous email.
2. Complexity - I think this one is easier to fix. We can create helper
classes to set up the routing. For instance something like this:
XPathRoutingServerFactory service = new XPathRoutingServerFactory();
service.route("/foo/service1', "service://service1");
service.route("/foo/service2', "service://service2");
service.setAddress("http://localhost/myService");
Server server = service.create();
Or it could use Camel (which is looking very cool btw).
Maybe we can a look at making our 1:1 association with Endpoints and
addresses a little looser as I think that would be conceptually a lot
better. I don't really know what all this entails though. I'll try to take a
look into it the next two days.
- Dan
On 3/23/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Hi, I've been experimenting a bit on the service routing lately, the
> result has been put on the wiki:
> http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing. So it
> works ((I will check in a system test shortly), my main concern though, is
> that this implementation does not seem to be very "simple", it does require
> a fair amount of knowledge of CXF internal. Not sure if it is appropriate to
> expose this to CXF userland. Anyway, I am open to any comments&suggestions.
>
> Thanks,
> Jervis
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 2007?3?17? 3:32
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Release Update
> >
> >
> > On 3/15/07, Liu, Jervis <jl...@iona.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > > Sent: 2007?3?15? 21:44
> > > > To: cxf-dev@incubator.apache.org
> > > > Subject: Re: Release Update
> > > >
> > > >
> > > > Hi Jervis,
> > > >
> > > > I wanted to ensure that we can setup an endpoint on a URL
> > and route to
> > > > different services based on headers (such as ws-a) or other
> > > > logic. I made a
> > > > series of proposals about how to do this a while back, but I
> > > > don't think we
> > > > ever came to any concrete conclusion.
> > > >
> > > Ok, I see what you mean. I believe you are referring to
> > this proposal [1].
> > > One thing I have not figured out from the proposal yet is
> > how we know the
> > > addresses of services to which the routing service is about
> > to redirect?
> > > Through some kind of registries or a configuration loaded
> > from a separate
> > > file or a WSDL extension.? Once this kind of discussion
> > gets started, I do
> > > not see how it can end by the end of this release. Service
> > routing is a huge
> > > topic anyway. However we will have much less to worry about
> > if we are not
> > > after a complete resolution of service routing. For
> > example, if we only
> > > support the routing among different endpoints within the
> > same Destination,
> > > would this feature be considered helpful for some certain
> > use cases? Reading
> > > your proposal, I believe this is also what you want to do,
> > start from sth
> > > simple first. If this is the case, I am ready to get my
> > hands dirty now.
> > >
> > > BTW, I am in a traveling at the moment, I may not respond
> > in time until I
> > > get back to office next Tuesday.
> > >
> > > [1].
> > >
> > http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
> 612.mbox/%3c7b774c950612021343x513c2783o128a032ba93923bb@mail.gmail.com%3e
>
>
>
> Yes, I'm really just concerned about the simple case. Namely being able to
> create some type of routing endpoint which routes to other types of
> services. My main use cases is versioning of services. Ideally many
> services
> can share the same URL and I can route by headers or the namespace of the
> body part.
>
> Regarding how to know what services to route to - I think its up to the
> user
> to write that code. I was kind of envisioning that it'd be an interceptor
> that a user writes. We could build something more formal like a registry,
> but we would need something low level first :-)
>
> - Dan
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
The implementation of a simple service routing. WAS: RE: Release Update
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi, I've been experimenting a bit on the service routing lately, the result has been put on the wiki: http://cwiki.apache.org/confluence/display/CXF20DOC/Service+Routing. So it works ((I will check in a system test shortly), my main concern though, is that this implementation does not seem to be very "simple", it does require a fair amount of knowledge of CXF internal. Not sure if it is appropriate to expose this to CXF userland. Anyway, I am open to any comments&suggestions.
Thanks,
Jervis
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 2007?3?17? 3:32
> To: cxf-dev@incubator.apache.org
> Subject: Re: Release Update
>
>
> On 3/15/07, Liu, Jervis <jl...@iona.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 2007?3?15? 21:44
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Release Update
> > >
> > >
> > > Hi Jervis,
> > >
> > > I wanted to ensure that we can setup an endpoint on a URL
> and route to
> > > different services based on headers (such as ws-a) or other
> > > logic. I made a
> > > series of proposals about how to do this a while back, but I
> > > don't think we
> > > ever came to any concrete conclusion.
> > >
> > Ok, I see what you mean. I believe you are referring to
> this proposal [1].
> > One thing I have not figured out from the proposal yet is
> how we know the
> > addresses of services to which the routing service is about
> to redirect?
> > Through some kind of registries or a configuration loaded
> from a separate
> > file or a WSDL extension.? Once this kind of discussion
> gets started, I do
> > not see how it can end by the end of this release. Service
> routing is a huge
> > topic anyway. However we will have much less to worry about
> if we are not
> > after a complete resolution of service routing. For
> example, if we only
> > support the routing among different endpoints within the
> same Destination,
> > would this feature be considered helpful for some certain
> use cases? Reading
> > your proposal, I believe this is also what you want to do,
> start from sth
> > simple first. If this is the case, I am ready to get my
> hands dirty now.
> >
> > BTW, I am in a traveling at the moment, I may not respond
> in time until I
> > get back to office next Tuesday.
> >
> > [1].
> >
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
612.mbox/%3c7b774c950612021343x513c2783o128a032ba93923bb@mail.gmail.com%3e
Yes, I'm really just concerned about the simple case. Namely being able to
create some type of routing endpoint which routes to other types of
services. My main use cases is versioning of services. Ideally many services
can share the same URL and I can route by headers or the namespace of the
body part.
Regarding how to know what services to route to - I think its up to the user
to write that code. I was kind of envisioning that it'd be an interceptor
that a user writes. We could build something more formal like a registry,
but we would need something low level first :-)
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Release Update
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 3/15/07, Liu, Jervis <jl...@iona.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 2007?3?15? 21:44
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Release Update
> >
> >
> > Hi Jervis,
> >
> > I wanted to ensure that we can setup an endpoint on a URL and route to
> > different services based on headers (such as ws-a) or other
> > logic. I made a
> > series of proposals about how to do this a while back, but I
> > don't think we
> > ever came to any concrete conclusion.
> >
> Ok, I see what you mean. I believe you are referring to this proposal [1].
> One thing I have not figured out from the proposal yet is how we know the
> addresses of services to which the routing service is about to redirect?
> Through some kind of registries or a configuration loaded from a separate
> file or a WSDL extension.? Once this kind of discussion gets started, I do
> not see how it can end by the end of this release. Service routing is a huge
> topic anyway. However we will have much less to worry about if we are not
> after a complete resolution of service routing. For example, if we only
> support the routing among different endpoints within the same Destination,
> would this feature be considered helpful for some certain use cases? Reading
> your proposal, I believe this is also what you want to do, start from sth
> simple first. If this is the case, I am ready to get my hands dirty now.
>
> BTW, I am in a traveling at the moment, I may not respond in time until I
> get back to office next Tuesday.
>
> [1].
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200612.mbox/%3c7b774c950612021343x513c2783o128a032ba93923bb@mail.gmail.com%3e
Yes, I'm really just concerned about the simple case. Namely being able to
create some type of routing endpoint which routes to other types of
services. My main use cases is versioning of services. Ideally many services
can share the same URL and I can route by headers or the namespace of the
body part.
Regarding how to know what services to route to - I think its up to the user
to write that code. I was kind of envisioning that it'd be an interceptor
that a user writes. We could build something more formal like a registry,
but we would need something low level first :-)
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Release Update
Posted by "Liu, Jervis" <jl...@iona.com>.
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 2007?3?15? 21:44
> To: cxf-dev@incubator.apache.org
> Subject: Re: Release Update
>
>
> Hi Jervis,
>
> I wanted to ensure that we can setup an endpoint on a URL and route to
> different services based on headers (such as ws-a) or other
> logic. I made a
> series of proposals about how to do this a while back, but I
> don't think we
> ever came to any concrete conclusion.
>
Ok, I see what you mean. I believe you are referring to this proposal [1]. One thing I have not figured out from the proposal yet is how we know the addresses of services to which the routing service is about to redirect? Through some kind of registries or a configuration loaded from a separate file or a WSDL extension.? Once this kind of discussion gets started, I do not see how it can end by the end of this release. Service routing is a huge topic anyway. However we will have much less to worry about if we are not after a complete resolution of service routing. For example, if we only support the routing among different endpoints within the same Destination, would this feature be considered helpful for some certain use cases? Reading your proposal, I believe this is also what you want to do, start from sth simple first. If this is the case, I am ready to get my hands dirty now.
BTW, I am in a traveling at the moment, I may not respond in time until I get back to office next Tuesday.
[1]. http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200612.mbox/%3c7b774c950612021343x513c2783o128a032ba93923bb@mail.gmail.com%3e
> My main motivation for want to get this in before the release
> is that I feel
> it might change our APIs or their behavior.
>
> - Dan
>
> On 3/14/07, Liu, Jervis <jl...@iona.com> wrote:
> >
> > Hi, I have some free time this month and I can pick up
> either the XML
> > Catalogs story (provide a more complete support for XML
> Catalogs, which is
> > part of our JAX-WS compliance stories) or I can start
> working on the service
> > routing story first as Dan has listed below, if we think
> the service routing
> > is a more important feature for this release. Dan, could you please
> > elaborate on the details of service routing, like the
> requirement and
> > expectation for this release. I presume its something
> related to XFire
> > service routing migration, right? Thanks.
> >
> > Cheers,
> > Jervis
> >
> > > -----Original Message-----
> > > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > > Sent: 2007?3?12? 6:21
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Release Update
> > >
> > >
> > > Hi folks,
> > >
> > > We're getting to the point that I think we're closing in
> on our next
> > > release. So I'd like to recap the big issues that are
> > > outstanding that I
> > > see:
> > >
> > > - WS-Security & SecureConversation & Trust - I would really
> > > really like to
> > > see us be able to support this for interop with WCF.
> > > - Tooling refactoring
> > > (this includes cleanup of java2wsdl in runtime, I want
> to see wsdl
> > > generation using the service model from our service
> factories before a
> > > release)
> > > - JAX-WS TCK Testing (see below)
> > > - CXF-28: Nice XML - we should finish moving away from our
> > > property editors
> > > to spring 2.0 handlers
> > > - We have no service routing story or examples
> > > - schema duplication in common/metacode?
> > > - Other open JIRAs
> > >
> > > We are also in BIG need of documentation. Specifically:
> > > - Using Spring 2.0 config syntax
> > > - HTTP Transport
> > > - WS-RM
> > > - WS-Policy
> > > - XFire migration docs
> > > - Using Aegis databinding
> > > - Using WSDL2Java & Java2WSDL in Maven & Ant
> > >
> > > At this point I see the following features probably being
> > > pushed to 2.1:
> > > - WSDL 2.0 support
> > > - XMLBeans support (this may or may not be possible to
> > > integrate in as part
> > > of the Aegis module, the big question is tooling - any
> volunteers?)
> > > - Any other WS-* work
> > >
> > > Re: JAX-WS - Can someone do some legwork and check if Apache
> > > will let us do
> > > a 2.0 final release without passing the TCK? Then we can
> > > focus on passing
> > > the TCK for 2.1. This would involve starting a discussion on
> > > general@incubator. If we are positioning ourselves as
> just a JAX-WS
> > > implementation I can see how they wouldn't let us do release.
> > > But I think
> > > there are a lot of uses which don't center around JAX-WS that
> > > we focus on.
> > > For instance, there are a lot of XFire users who aren't using
> > > the JAX-WS
> > > features and so I would like to get them migrating ASAP so I
> > > can consolidate
> > > bug fixes in one place. As long as we're clear that
> compliance is not
> > > claimed we should be ok.
> > >
> > > What other items do people see?
> > >
> > > I think we should target starting a vote by March 30th, but
> > > we have a fair
> > > amount to do before then I think you can see. Please claim
> > > any JIRA issues
> > > you intend to tackle so its easier to see who is planning on
> > > working on
> > > what. I'm incredibly excited to get a new release out. CXF is
> > > looking great
> > > and its time for the world to really start using it!
> > >
> > > (BTW, I am focusing in on the security specifications
> this week unless
> > > someone else wants to volunteer. I could definitely spend
> > > some more time on
> > > routing or Aegis instead)
> > >
> > > - Dan
> > > --
> > > Dan Diephouse
> > > Envoi Solutions
> > > http://envoisolutions.com | http://netzooid.com/blog
> > >
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Release Update
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Jervis,
I wanted to ensure that we can setup an endpoint on a URL and route to
different services based on headers (such as ws-a) or other logic. I made a
series of proposals about how to do this a while back, but I don't think we
ever came to any concrete conclusion.
My main motivation for want to get this in before the release is that I feel
it might change our APIs or their behavior.
- Dan
On 3/14/07, Liu, Jervis <jl...@iona.com> wrote:
>
> Hi, I have some free time this month and I can pick up either the XML
> Catalogs story (provide a more complete support for XML Catalogs, which is
> part of our JAX-WS compliance stories) or I can start working on the service
> routing story first as Dan has listed below, if we think the service routing
> is a more important feature for this release. Dan, could you please
> elaborate on the details of service routing, like the requirement and
> expectation for this release. I presume its something related to XFire
> service routing migration, right? Thanks.
>
> Cheers,
> Jervis
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: 2007?3?12? 6:21
> > To: cxf-dev@incubator.apache.org
> > Subject: Release Update
> >
> >
> > Hi folks,
> >
> > We're getting to the point that I think we're closing in on our next
> > release. So I'd like to recap the big issues that are
> > outstanding that I
> > see:
> >
> > - WS-Security & SecureConversation & Trust - I would really
> > really like to
> > see us be able to support this for interop with WCF.
> > - Tooling refactoring
> > (this includes cleanup of java2wsdl in runtime, I want to see wsdl
> > generation using the service model from our service factories before a
> > release)
> > - JAX-WS TCK Testing (see below)
> > - CXF-28: Nice XML - we should finish moving away from our
> > property editors
> > to spring 2.0 handlers
> > - We have no service routing story or examples
> > - schema duplication in common/metacode?
> > - Other open JIRAs
> >
> > We are also in BIG need of documentation. Specifically:
> > - Using Spring 2.0 config syntax
> > - HTTP Transport
> > - WS-RM
> > - WS-Policy
> > - XFire migration docs
> > - Using Aegis databinding
> > - Using WSDL2Java & Java2WSDL in Maven & Ant
> >
> > At this point I see the following features probably being
> > pushed to 2.1:
> > - WSDL 2.0 support
> > - XMLBeans support (this may or may not be possible to
> > integrate in as part
> > of the Aegis module, the big question is tooling - any volunteers?)
> > - Any other WS-* work
> >
> > Re: JAX-WS - Can someone do some legwork and check if Apache
> > will let us do
> > a 2.0 final release without passing the TCK? Then we can
> > focus on passing
> > the TCK for 2.1. This would involve starting a discussion on
> > general@incubator. If we are positioning ourselves as just a JAX-WS
> > implementation I can see how they wouldn't let us do release.
> > But I think
> > there are a lot of uses which don't center around JAX-WS that
> > we focus on.
> > For instance, there are a lot of XFire users who aren't using
> > the JAX-WS
> > features and so I would like to get them migrating ASAP so I
> > can consolidate
> > bug fixes in one place. As long as we're clear that compliance is not
> > claimed we should be ok.
> >
> > What other items do people see?
> >
> > I think we should target starting a vote by March 30th, but
> > we have a fair
> > amount to do before then I think you can see. Please claim
> > any JIRA issues
> > you intend to tackle so its easier to see who is planning on
> > working on
> > what. I'm incredibly excited to get a new release out. CXF is
> > looking great
> > and its time for the world to really start using it!
> >
> > (BTW, I am focusing in on the security specifications this week unless
> > someone else wants to volunteer. I could definitely spend
> > some more time on
> > routing or Aegis instead)
> >
> > - Dan
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Release Update
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi, I have some free time this month and I can pick up either the XML Catalogs story (provide a more complete support for XML Catalogs, which is part of our JAX-WS compliance stories) or I can start working on the service routing story first as Dan has listed below, if we think the service routing is a more important feature for this release. Dan, could you please elaborate on the details of service routing, like the requirement and expectation for this release. I presume its something related to XFire service routing migration, right? Thanks.
Cheers,
Jervis
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 2007?3?12? 6:21
> To: cxf-dev@incubator.apache.org
> Subject: Release Update
>
>
> Hi folks,
>
> We're getting to the point that I think we're closing in on our next
> release. So I'd like to recap the big issues that are
> outstanding that I
> see:
>
> - WS-Security & SecureConversation & Trust - I would really
> really like to
> see us be able to support this for interop with WCF.
> - Tooling refactoring
> (this includes cleanup of java2wsdl in runtime, I want to see wsdl
> generation using the service model from our service factories before a
> release)
> - JAX-WS TCK Testing (see below)
> - CXF-28: Nice XML - we should finish moving away from our
> property editors
> to spring 2.0 handlers
> - We have no service routing story or examples
> - schema duplication in common/metacode?
> - Other open JIRAs
>
> We are also in BIG need of documentation. Specifically:
> - Using Spring 2.0 config syntax
> - HTTP Transport
> - WS-RM
> - WS-Policy
> - XFire migration docs
> - Using Aegis databinding
> - Using WSDL2Java & Java2WSDL in Maven & Ant
>
> At this point I see the following features probably being
> pushed to 2.1:
> - WSDL 2.0 support
> - XMLBeans support (this may or may not be possible to
> integrate in as part
> of the Aegis module, the big question is tooling - any volunteers?)
> - Any other WS-* work
>
> Re: JAX-WS - Can someone do some legwork and check if Apache
> will let us do
> a 2.0 final release without passing the TCK? Then we can
> focus on passing
> the TCK for 2.1. This would involve starting a discussion on
> general@incubator. If we are positioning ourselves as just a JAX-WS
> implementation I can see how they wouldn't let us do release.
> But I think
> there are a lot of uses which don't center around JAX-WS that
> we focus on.
> For instance, there are a lot of XFire users who aren't using
> the JAX-WS
> features and so I would like to get them migrating ASAP so I
> can consolidate
> bug fixes in one place. As long as we're clear that compliance is not
> claimed we should be ok.
>
> What other items do people see?
>
> I think we should target starting a vote by March 30th, but
> we have a fair
> amount to do before then I think you can see. Please claim
> any JIRA issues
> you intend to tackle so its easier to see who is planning on
> working on
> what. I'm incredibly excited to get a new release out. CXF is
> looking great
> and its time for the world to really start using it!
>
> (BTW, I am focusing in on the security specifications this week unless
> someone else wants to volunteer. I could definitely spend
> some more time on
> routing or Aegis instead)
>
> - Dan
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>