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/06/20 20:21:24 UTC
2.0.1 & 2.1 Releases
Yes, its that time - we get to start thinking about post 2.0 releases! (and
2.0 isn't even fully out yet - but its close ;-))
First: 2.0.1. I think its important to follow up with bug fix releases quite
often in general, but especially after the first release. We'll see a lot
more people start to use CXF once 2.0 is out I believe. And I'm sure they'll
find all sorts of bugs. So I'd like to propose that we follow up with
2.0.1within 3-4 weeks of
2.0 (i.e. vote on it 3-4 weeks from today).
The question of 2.1 is a bit more complex. I see several things on the
possible agenda for 2.1:
- JAX-WS 2.1 & JAXB 2.1
- Refactoring the build better to help with the tool dependency issues
- WS-SX (Trust, SecureConversation, SecurityPolicy)
- WS RM 1.1?
- Better REST service support - WADL, JSR 311 early draft?
- WSDL 2? (I see this one as increasingly irrelevant as there has been
almost no take up of WSDL 2, and I think it'd be a distraction for us right
now)
- SCA integration? (coincidentally, I noticed the Fabric3 team has started
CXF integration)
- Others? I'm sure there are many other important issues out there...
I see two philosophies by which we can release 2.1
1. The fixed time philosophy - i.e. We do a release every 8-10 weeks
2. The fixed feature set philosophy - i.e. we do a release only once these
features are ready
I'm a much bigger fan of philosophy #1 as I think it serves users much
better. But I am open to to either provided we make frequent bug fix
releases for 2.0. The one constraint that I see on 2.1 is that we will need
to do JAX-WS 2.1 TCK testing which will take how ever long it takes. So even
if we go by the "fixed time" philosophy, our window can't be smaller than
the time it takes to implement those APIs and do TCK testing.
Thoughts?
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Patch for fixing log4j warning in CXF samples
Posted by William Tam <em...@gmail.com>.
I belive if log4j jar is not in your classpath, you won't see the warning
(since log4j logger is not activated).
On 6/21/07, Paibir, Ajay <aj...@iona.com> wrote:
>
> Was not able to reproduce the log4j warnings in couple of samples tested
> in the cxf kit.
> May be something with my environment.
> Does anybody else see log4j related errors during build or run of
> samples?
>
> Ajay
>
> > -----Original Message-----
> > From: Paibir, Ajay [mailto:ajay.paibir@iona.com]
> > Sent: 21 June 2007 18:14
> > To: cxf-dev@incubator.apache.org; Bhole, Ulhas
> > Subject: RE: Patch for fixing log4j warning in CXF samples
> >
> > I will apply it.
> >
> > Ajay.
> >
> > > -----Original Message-----
> > > From: Ulhas Bhole [mailto:ulhas.bhole@iona.com]
> > > Sent: 21 June 2007 18:16
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Patch for fixing log4j warning in CXF samples
> > >
> > > Sorry forgot to attach the patch file.
> > >
> > > -- Ulhas
> > >
> > > On Thu, 2007-06-21 at 18:13 +0100, Ulhas Bhole wrote:
> > > > Hi,
> > > >
> > > > Here is a patch for fixing the log4j warning that appears
> > > from samples
> > > > during code generation and client and server run.
> > > >
> > > > Can someone review it and apply it for me?
> > > >
> > > > Regards,
> > > >
> > > > Ulhas Bhole
> > > >
> > > > ----------------------------
> > > > IONA Technologies PLC (registered in Ireland) Registered Number:
> > > > 171387 Registered Address: The IONA Building, Shelbourne
> > > Road, Dublin
> > > > 4, Ireland
> > >
> > > ----------------------------
> > > IONA Technologies PLC (registered in Ireland) Registered
> > > Number: 171387 Registered Address: The IONA Building,
> > Shelbourne Road,
> > > Dublin 4, Ireland
> > >
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road,
> > Dublin 4, Ireland
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
Re: Patch for fixing log4j warning in CXF samples
Posted by Ulhas Bhole <ul...@iona.com>.
Hi Dan,
I realised that and hence not applying the patch.
Doing some more investigation.
-- Ulhas
On Thu, 2007-06-21 at 14:24 -0400, Daniel Kulp wrote:
> On Thursday 21 June 2007 13:58, Paibir, Ajay wrote:
> > Was not able to reproduce the log4j warnings in couple of samples
> > tested in the cxf kit.
> > May be something with my environment.
> > Does anybody else see log4j related errors during build or run of
> > samples?
>
> You won't. We don't ship log4j with CXF so you won't see the warning at
> all. Thus, for CXF, there isn't a point in setting this.
>
> Dan
>
>
> >
> > Ajay
> >
> > > -----Original Message-----
> > > From: Paibir, Ajay [mailto:ajay.paibir@iona.com]
> > > Sent: 21 June 2007 18:14
> > > To: cxf-dev@incubator.apache.org; Bhole, Ulhas
> > > Subject: RE: Patch for fixing log4j warning in CXF samples
> > >
> > > I will apply it.
> > >
> > > Ajay.
> > >
> > > > -----Original Message-----
> > > > From: Ulhas Bhole [mailto:ulhas.bhole@iona.com]
> > > > Sent: 21 June 2007 18:16
> > > > To: cxf-dev@incubator.apache.org
> > > > Subject: Re: Patch for fixing log4j warning in CXF samples
> > > >
> > > > Sorry forgot to attach the patch file.
> > > >
> > > > -- Ulhas
> > > >
> > > > On Thu, 2007-06-21 at 18:13 +0100, Ulhas Bhole wrote:
> > > > > Hi,
> > > > >
> > > > > Here is a patch for fixing the log4j warning that appears
> > > >
> > > > from samples
> > > >
> > > > > during code generation and client and server run.
> > > > >
> > > > > Can someone review it and apply it for me?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Ulhas Bhole
> > > > >
> > > > > ----------------------------
> > > > > IONA Technologies PLC (registered in Ireland) Registered Number:
> > > > > 171387 Registered Address: The IONA Building, Shelbourne
> > > >
> > > > Road, Dublin
> > > >
> > > > > 4, Ireland
> > > >
> > > > ----------------------------
> > > > IONA Technologies PLC (registered in Ireland) Registered
> > > > Number: 171387 Registered Address: The IONA Building,
> > >
> > > Shelbourne Road,
> > >
> > > > Dublin 4, Ireland
> > >
> > > ----------------------------
> > > IONA Technologies PLC (registered in Ireland)
> > > Registered Number: 171387
> > > Registered Address: The IONA Building, Shelbourne Road,
> > > Dublin 4, Ireland
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> > Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Patch for fixing log4j warning in CXF samples
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 21 June 2007 13:58, Paibir, Ajay wrote:
> Was not able to reproduce the log4j warnings in couple of samples
> tested in the cxf kit.
> May be something with my environment.
> Does anybody else see log4j related errors during build or run of
> samples?
You won't. We don't ship log4j with CXF so you won't see the warning at
all. Thus, for CXF, there isn't a point in setting this.
Dan
>
> Ajay
>
> > -----Original Message-----
> > From: Paibir, Ajay [mailto:ajay.paibir@iona.com]
> > Sent: 21 June 2007 18:14
> > To: cxf-dev@incubator.apache.org; Bhole, Ulhas
> > Subject: RE: Patch for fixing log4j warning in CXF samples
> >
> > I will apply it.
> >
> > Ajay.
> >
> > > -----Original Message-----
> > > From: Ulhas Bhole [mailto:ulhas.bhole@iona.com]
> > > Sent: 21 June 2007 18:16
> > > To: cxf-dev@incubator.apache.org
> > > Subject: Re: Patch for fixing log4j warning in CXF samples
> > >
> > > Sorry forgot to attach the patch file.
> > >
> > > -- Ulhas
> > >
> > > On Thu, 2007-06-21 at 18:13 +0100, Ulhas Bhole wrote:
> > > > Hi,
> > > >
> > > > Here is a patch for fixing the log4j warning that appears
> > >
> > > from samples
> > >
> > > > during code generation and client and server run.
> > > >
> > > > Can someone review it and apply it for me?
> > > >
> > > > Regards,
> > > >
> > > > Ulhas Bhole
> > > >
> > > > ----------------------------
> > > > IONA Technologies PLC (registered in Ireland) Registered Number:
> > > > 171387 Registered Address: The IONA Building, Shelbourne
> > >
> > > Road, Dublin
> > >
> > > > 4, Ireland
> > >
> > > ----------------------------
> > > IONA Technologies PLC (registered in Ireland) Registered
> > > Number: 171387 Registered Address: The IONA Building,
> >
> > Shelbourne Road,
> >
> > > Dublin 4, Ireland
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road,
> > Dublin 4, Ireland
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
> Ireland
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Patch for fixing log4j warning in CXF samples
Posted by "Paibir, Ajay" <aj...@iona.com>.
Was not able to reproduce the log4j warnings in couple of samples tested
in the cxf kit.
May be something with my environment.
Does anybody else see log4j related errors during build or run of
samples?
Ajay
> -----Original Message-----
> From: Paibir, Ajay [mailto:ajay.paibir@iona.com]
> Sent: 21 June 2007 18:14
> To: cxf-dev@incubator.apache.org; Bhole, Ulhas
> Subject: RE: Patch for fixing log4j warning in CXF samples
>
> I will apply it.
>
> Ajay.
>
> > -----Original Message-----
> > From: Ulhas Bhole [mailto:ulhas.bhole@iona.com]
> > Sent: 21 June 2007 18:16
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Patch for fixing log4j warning in CXF samples
> >
> > Sorry forgot to attach the patch file.
> >
> > -- Ulhas
> >
> > On Thu, 2007-06-21 at 18:13 +0100, Ulhas Bhole wrote:
> > > Hi,
> > >
> > > Here is a patch for fixing the log4j warning that appears
> > from samples
> > > during code generation and client and server run.
> > >
> > > Can someone review it and apply it for me?
> > >
> > > Regards,
> > >
> > > Ulhas Bhole
> > >
> > > ----------------------------
> > > IONA Technologies PLC (registered in Ireland) Registered Number:
> > > 171387 Registered Address: The IONA Building, Shelbourne
> > Road, Dublin
> > > 4, Ireland
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered
> > Number: 171387 Registered Address: The IONA Building,
> Shelbourne Road,
> > Dublin 4, Ireland
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road,
> Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Patch for fixing log4j warning in CXF samples
Posted by "Paibir, Ajay" <aj...@iona.com>.
I will apply it.
Ajay.
> -----Original Message-----
> From: Ulhas Bhole [mailto:ulhas.bhole@iona.com]
> Sent: 21 June 2007 18:16
> To: cxf-dev@incubator.apache.org
> Subject: Re: Patch for fixing log4j warning in CXF samples
>
> Sorry forgot to attach the patch file.
>
> -- Ulhas
>
> On Thu, 2007-06-21 at 18:13 +0100, Ulhas Bhole wrote:
> > Hi,
> >
> > Here is a patch for fixing the log4j warning that appears
> from samples
> > during code generation and client and server run.
> >
> > Can someone review it and apply it for me?
> >
> > Regards,
> >
> > Ulhas Bhole
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered Number:
> > 171387 Registered Address: The IONA Building, Shelbourne
> Road, Dublin
> > 4, Ireland
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered
> Number: 171387 Registered Address: The IONA Building,
> Shelbourne Road, Dublin 4, Ireland
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Patch for fixing log4j warning in CXF samples
Posted by Ulhas Bhole <ul...@iona.com>.
Sorry forgot to attach the patch file.
-- Ulhas
On Thu, 2007-06-21 at 18:13 +0100, Ulhas Bhole wrote:
> Hi,
>
> Here is a patch for fixing the log4j warning that appears from samples
> during code generation and client and server run.
>
> Can someone review it and apply it for me?
>
> Regards,
>
> Ulhas Bhole
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Patch for fixing log4j warning in CXF samples
Posted by Ulhas Bhole <ul...@iona.com>.
Hi,
Here is a patch for fixing the log4j warning that appears from samples
during code generation and client and server run.
Can someone review it and apply it for me?
Regards,
Ulhas Bhole
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: 2.0.1 & 2.1 Releases
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi Fred, in the example you are giving below, the feature does get installed twice (or shall I say the interceptors are installed twice), though what I am not sure is whether or not it is justified to use <cxf:bus> as a root scope of configuration. In concept, a CXF endpoint gets its configuration and features (in most cases, features map to interceptors) installed from bus, bindings and endpoint, but does this mean bus configuration is the root scope configuration or the default configuration? A CXF user, in most cases, I believe they should only understand and care about the <jaxws:endpoint> configuration. Of course, it is a very valid use case that you might want to say I want to apply this WS-Policy feature to all my three <jaxws:endpoint>, or you define a WS-Policy feature and you say this feature should apply to all <jaxws:endpoint> by default if there is no override. How to do this (but not using <CXF:bus>), is the thing we need to figure out. ;-)
Cheers,
Jervis
-----Original Message-----
From: Fred Dushin [mailto:fred@dushin.net]
Sent: 2007?6?21? 23:26
To: cxf-dev@incubator.apache.org
Subject: Re: 2.0.1 & 2.1 Releases
On Jun 20, 2007, at 10:09 PM, Dan Diephouse wrote:
> Are you thinking about a case where two features might add the same
> interceptors to an InterceptorProvider? Can you explain a little
> bit more
> the case where multiple features are adding the same interceptors to a
> Bus/Client/Server?
Exactly. E.g., what would happen in the following case (where we
have a fictional cxf:bus feature):
{{{
<cxf:bus>
<jaxws:features>
<acme:MyFeature ... />
</jaxws:features>
</cxf:bus>
<jaxws:endpoint name="{http://www.acme.com}WhizzBangPort">
<jaxws:features>
<acme:MyFeature ... />
</jaxws:features>
</jaxws:endpoint>
}}}
Is there one feature instance installed, or 2?
Maybe we need a notion of default features, as in
{{{
<cxf:bus>
<jaxws:defaultFeatures>
<acme:MyFeature ... />
</jaxws:defaultFeatures>
</cxf:bus>
}}}
which are only installed if they are not explicitly overridden by an
endpoint or client feature, but I don't think implementing that is
trivial, since the runtime doesn't really know anything about
features, per se. It just knows what interceptors are.
/Fred
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: 2.0.1 & 2.1 Releases
Posted by Fred Dushin <fr...@dushin.net>.
On Jun 20, 2007, at 10:09 PM, Dan Diephouse wrote:
> Are you thinking about a case where two features might add the same
> interceptors to an InterceptorProvider? Can you explain a little
> bit more
> the case where multiple features are adding the same interceptors to a
> Bus/Client/Server?
Exactly. E.g., what would happen in the following case (where we
have a fictional cxf:bus feature):
{{{
<cxf:bus>
<jaxws:features>
<acme:MyFeature ... />
</jaxws:features>
</cxf:bus>
<jaxws:endpoint name="{http://www.acme.com}WhizzBangPort">
<jaxws:features>
<acme:MyFeature ... />
</jaxws:features>
</jaxws:endpoint>
}}}
Is there one feature instance installed, or 2?
Maybe we need a notion of default features, as in
{{{
<cxf:bus>
<jaxws:defaultFeatures>
<acme:MyFeature ... />
</jaxws:defaultFeatures>
</cxf:bus>
}}}
which are only installed if they are not explicitly overridden by an
endpoint or client feature, but I don't think implementing that is
trivial, since the runtime doesn't really know anything about
features, per se. It just knows what interceptors are.
/Fred
Re: 2.0.1 & 2.1 Releases
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 6/20/07, Fred Dushin <fr...@dushin.net> wrote:
>
>
> I think we need to think long and hard about how WS-SecurityPolicy
> fits into the current WS-Security interceptor.
>
> As a start, I'd recommend we remove any WSS4J-isms in the exposed
> interfaces (programmatic and configuration), and instead focus on
> exposing these through JAX-WS features.
>
We can then focus on how WS-SecurityPolicy objects clash/complement
> features defined statically in config.
Yeah. The current ws-security stuff is very basic and is in desperate need
of an overall as we do the WS-SX stuff. We need to make sure the
WSSecurityFeature API, SecurityPolicy and WS-SX stuff all align well, which
is no trivial task. Or maybe it is - I honestly am not enough of a SecPol/SX
expert to comment. Maybe we can start a wikipage and start capturing
requirements/ideas.
Before we do any more feature work, though, I think we need to get a
> definition of jaxws:features at Bus scope, though I think there may
> be a slight semantic disconnect there. The beauty of defining things
> at Bus scope is that it can serve as a fallback/default mechanism for
> configuration that is not defined on a specific client or endpoint.
https://issues.apache.org/jira/browse/CXF-742 - I targeted this for 2.0.1
But the way the AbstractFeature stuff is defined, setting "features"
> on an InterceptorProvider, when the InterceptorProvider is a Bus, is /
> additive/ on the ultimate list of interceptors -- it's not, in
> particular, a default fallback mechanism. (Please correct me if I've
> got that wrong) So I think a little more design work needs to go
> into that.
Are you thinking about a case where two features might add the same
interceptors to an InterceptorProvider? Can you explain a little bit more
the case where multiple features are adding the same interceptors to a
Bus/Client/Server?
Thanks,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: 2.0.1 & 2.1 Releases
Posted by Fred Dushin <fr...@dushin.net>.
I think we need to think long and hard about how WS-SecurityPolicy
fits into the current WS-Security interceptor.
As a start, I'd recommend we remove any WSS4J-isms in the exposed
interfaces (programmatic and configuration), and instead focus on
exposing these through JAX-WS features.
We can then focus on how WS-SecurityPolicy objects clash/complement
features defined statically in config.
Before we do any more feature work, though, I think we need to get a
definition of jaxws:features at Bus scope, though I think there may
be a slight semantic disconnect there. The beauty of defining things
at Bus scope is that it can serve as a fallback/default mechanism for
configuration that is not defined on a specific client or endpoint.
But the way the AbstractFeature stuff is defined, setting "features"
on an InterceptorProvider, when the InterceptorProvider is a Bus, is /
additive/ on the ultimate list of interceptors -- it's not, in
particular, a default fallback mechanism. (Please correct me if I've
got that wrong) So I think a little more design work needs to go
into that.
-Fred
On Jun 20, 2007, at 2:21 PM, Dan Diephouse wrote:
> - WS-SX (Trust, SecureConversation, SecurityPolicy)
Re: 2.0.1 & 2.1 Releases
Posted by Oisin Hurley <oh...@iona.com>.
On 20 Jun 2007, at 14:21, Dan Diephouse wrote:
> I see two philosophies by which we can release 2.1
> 1. The fixed time philosophy - i.e. We do a release every 8-10 weeks
Very much a big +1 from the Eclipse STP Team on this one :)
best regards
Oisin
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: 2.0.1 & 2.1 Releases
Posted by Bozhong Lin <bl...@iona.com>.
+ to vote 2.0.1 release in 3-4 weeks from today, and limit release to
bug fixes only, no new features.
+1 to do release in every 8-10 weeks timeframe, it is very important to
maintain regular release as the community is growing.
As for those possible new stuff for 2.1 release, we have to be realistic
about timeframe (8-10 weeks) and set some high priority features to work
on. I deem JAX-WS 2.1 and JAXB 2.1, Better REST service support -
WADL/JSR 311, SCA integration, and build refactoring. I am sure there
will be a lot of bug fixes also.
For things beyond 2.1 release, I also see following possible agendas:
- better dynamic language support (refactoring JavaScript support, add
more dynamic language support such as JRuby, Groovy)
- JSON support
- Some more transport support such as SMTP?
Cheers,
Bo
Dan Diephouse wrote:
> Yes, its that time - we get to start thinking about post 2.0 releases!
> (and
> 2.0 isn't even fully out yet - but its close ;-))
>
> First: 2.0.1. I think its important to follow up with bug fix releases
> quite
> often in general, but especially after the first release. We'll see a lot
> more people start to use CXF once 2.0 is out I believe. And I'm sure
> they'll
> find all sorts of bugs. So I'd like to propose that we follow up with
> 2.0.1within 3-4 weeks of
> 2.0 (i.e. vote on it 3-4 weeks from today).
>
> The question of 2.1 is a bit more complex. I see several things on the
> possible agenda for 2.1:
> - JAX-WS 2.1 & JAXB 2.1
> - Refactoring the build better to help with the tool dependency issues
> - WS-SX (Trust, SecureConversation, SecurityPolicy)
> - WS RM 1.1?
> - Better REST service support - WADL, JSR 311 early draft?
> - WSDL 2? (I see this one as increasingly irrelevant as there has been
> almost no take up of WSDL 2, and I think it'd be a distraction for us
> right
> now)
> - SCA integration? (coincidentally, I noticed the Fabric3 team has
> started
> CXF integration)
> - Others? I'm sure there are many other important issues out there...
>
> I see two philosophies by which we can release 2.1
> 1. The fixed time philosophy - i.e. We do a release every 8-10 weeks
> 2. The fixed feature set philosophy - i.e. we do a release only once
> these
> features are ready
>
> I'm a much bigger fan of philosophy #1 as I think it serves users much
> better. But I am open to to either provided we make frequent bug fix
> releases for 2.0. The one constraint that I see on 2.1 is that we will
> need
> to do JAX-WS 2.1 TCK testing which will take how ever long it takes.
> So even
> if we go by the "fixed time" philosophy, our window can't be smaller than
> the time it takes to implement those APIs and do TCK testing.
>
> Thoughts?
Re: 2.0.1 & 2.1 Releases
Posted by Bernd Schuller <b....@fz-juelich.de>.
Hi,
on possible 2.1 features: what about XMLBeans support?
Best regards,
Bernd.
Dan Diephouse wrote:
[...]
>
> The question of 2.1 is a bit more complex. I see several things on the
> possible agenda for 2.1:
> - JAX-WS 2.1 & JAXB 2.1
> - Refactoring the build better to help with the tool dependency issues
> - WS-SX (Trust, SecureConversation, SecurityPolicy)
> - WS RM 1.1?
> - Better REST service support - WADL, JSR 311 early draft?
> - WSDL 2? (I see this one as increasingly irrelevant as there has been
> almost no take up of WSDL 2, and I think it'd be a distraction for us right
> now)
> - SCA integration? (coincidentally, I noticed the Fabric3 team has started
> CXF integration)
> - Others? I'm sure there are many other important issues out there...
>
--
Dr. Bernd Schuller
Central Institute for Applied Mathematics
Forschungszentrum Juelich GmbH
mail b.schuller@fz-juelich.de
phone +49 2461 61 8736
fax +49 2461 61 6656
blog http://www.jroller.com/page/gridhaus
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv.
Vorsitzender)