cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Different namespaces for CXF Blueprint and Spring schemas
Date Thu, 08 Dec 2011 18:15:27 GMT
Hi Dan
On 08/12/11 15:46, Daniel Kulp wrote:
>
> 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.
>
Thanks for the above info - I see it can be tricky to get a single 
physical schema document for both Blueprint and Spring;

What about having a single target  namespace even with one schema used 
by Spring & 2nd - by Blueprint, example:

<!-- Spring -->
<xs:xmlns targetNamespace="http://cxf.apache.org/core" 
xmlns:tns="http://cxf.apache.org/core">
<!-- Spring-aware schema -->
</xs:xmlns>

<!-- Blueprint -->
<xs:xmlns targetNamespace="http://cxf.apache.org/core" 
xmlns:tns="http://cxf.apache.org/core">
<!-- Blueprint-aware schema -->
</xs:xmlns>

Sorry if I did not clarify what I was actually after; I thought that if 
it could work in principle then we'd be able to experiment under the 
hood with various techniques which might let us collapse those 2 schemas 
into a single one, etc; and when needed do add

http://cxf.apache.org/blueprint/core (using this ns just as example) 
which would point to a schema offering something unique to CXF services 
deployed on Blueprint

But not sure if sharing the same target ns can actually work :-)

Cheers, Sergey
>
> 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



Mime
View raw message