cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aki Yoshida <elak...@googlemail.com>
Subject Re: Different namespaces for CXF Blueprint and Spring schemas
Date Thu, 08 Dec 2011 17:00:30 GMT
2011/12/8 Daniel Kulp <dkulp@apache.org>:
>
> Sergey,
>
>> Personally I'd be happy at this stage if we could agree that CXF schemas
>> will have, when possible a common namespace to be shared between Spring
>> & Blueprint
>
> For the most part, that's exactly what Johan and I have been doing whenever
> possible.   There are a couple like Coloc (coloc-feature.xsd) that we've been
> able to do that.
>
> The issue is that a bunch of the schemas import the spring schema  (like in
> core.xsd):
>
> <xsd:import namespace="http://www.springframework.org/schema/beans"
> schemaLocation="http://www.springframework.org/schema/beans/spring-
> beans.xsd"/>
>
> and as soon as you do that, you have some level of dependency on spring which
> we are trying to NOT have with blueprint.      For example, in core.xsd, the
> "properties" for the cxf:bus are of type:
>
> <xsd:element name="properties" type="beans:mapType" minOccurs="0">
>
> which is a spring defined schema type.   In blueprint, it is:
>
> <xsd:element name="properties" type="beans:Tmap" minOccurs="0">
>
> which would be the blueprint equivalent.  Obviously we could just define them
> as xsd:anyType or something like we do for the interceptorLists.   That
> definitely could be considered an option, but that also ruins some of the nice
> validation that could occur.
>
> It may also be possible to add some extra types in cxf-beans or something that
> will mimic both the blueprint and spring versions of those types, but I'm not
> really sure.

This is the line that I was thinking about, namely to define the
merged base types in one of our core schema with the documentation
describing the semantics of the attributes depending on the container
environment. We can use these types as the replacement for the BP or
spring version of those specific base types. We lose the strictness in
xml validation. But there is typically always a room between what
syntactically valid and what semantically valid. So, I think it is an
option to loosen the syntactic validation to gain some other benefits.

I will start trying out this approach for ws-rm.

regards, aki


>
> Dan
>
>
>
> On Thursday, December 08, 2011 11:49:07 AM Sergey Beryozkin wrote:
>> Hi Aki
>>
>> On 08/12/11 11:23, Aki Yoshida wrote:
>> > Hi Sergey,
>> >
>> > I think there is a possibility to use one schema that works for both
>> > of them, thereby making things a lot simpler. You will lose some
>> > degree of strictness in the combined schemas (i.e., certain attributes
>> > are available but have no associated semantics and simply ignored when
>> > configured in spring or one way or the other). But we can document
>> > this divergence in the merged schema's document/annotation elements.
>> >
>> > I am planning to take this approach for the ws-rm component. The
>> > background to this is
>> > tracked at
>> >
>> > http://cxf.547215.n5.nabble.com/thought-on-spring-and-blueprint-configur
>> > ation-schemas-tt5052010.html
>> Thanks for this link. I think it can be even up to a given module to
>> decide which strategy to follow; having a single schema to be used in
>> Spring and Blueprint is an option,
>> I'd still consider such a single schema being equally useful in both
>> cases and then if really needed have say a Blueprint specific schema
>> adding something new to the shared one;
>> There was some interest in CXF supporting CDI, I'm not sure if the
>> developers who volunteered to work on that still do anything or not :-),
>> but if it were to happen at some stage then the jaxrs frontend at least
>> would have 'problems' :-) with a single schema only case, though it is a
>> bit hypothetic at this stage.
>>
>> Personally I'd be happy at this stage if we could agree that CXF schemas
>> will have, when possible a common namespace to be shared between Spring
>> & Blueprint; it would be the next step then how to realize that at the
>> lower level at per-module basis, for example, using either of the 4
>> options listed in your email or some other approach
>>
>> Cheers, Sergey
>>
>> > regards, aki
>> >
>> > 2011/12/8 Sergey Beryozkin<sberyozkin@gmail.com>:
>> >> Hi
>> >>
>> >> At the moment we have different namespaces for Blueprint and Spring
>> >> schemas, example:
>> >>
>> >> "http://cxf.apache.org/blueprint/core"
>> >> "http://cxf.apache.org/core"
>> >>
>> >> and so on for all other namespaces.
>> >>
>> >> I'd like to propose to keep a single namespace, example,
>> >> "http://cxf.apache.org/core", etc.
>> >>
>> >> Spring schemas are located in /schemas resource folders,
>> >> and blueprint ones in /schemas-blueprint, so I guess Blueprint and
>> >> Spring will know where to look for their schemas.
>> >>
>> >> IMHO we should do before it is too late, it may be problematic now,
>> >> but may be that is what we should do for 2.6 and document it in the
>> >> Migration guide.
>> >>
>> >> Or is the idea that in Blueprint CXF might offer some features that
>> >> won't be possible in Spring ? That may be of interest but I guess in
>> >> that case we can have two namespaces for using in Blueprint:
>> >> "http://cxf.apache.org/blueprint/core"
>> >> "http://cxf.apache.org/core"
>> >>
>> >> with the former one identifying the schema which say imports the
>> >> schema
>> >> identified by the latter ns and adds some Blueprint centric extensions
>> >>
>> >> Thanks, Sergey
>> >>
>> >> --
>> >> Sergey Beryozkin
>> >>
>> >> Talend Community Coders
>> >> http://coders.talend.com/
>> >>
>> >> Blog: http://sberyozkin.blogspot.com
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com

Mime
View raw message