You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2011/12/08 11:45:22 UTC
Different namespaces for CXF Blueprint and Spring schemas
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
Re: Different namespaces for CXF Blueprint and Spring schemas
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 08/12/11 18:26, Daniel Kulp wrote:
> On Thursday, December 08, 2011 6:15:27 PM Sergey Beryozkin wrote:
>> Hi Dan
> .......
>>
>> 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>
>
> This is basically what Aki was trying to do with RM and I kind of objected to
> which started the whole discussion. It more or less goes against the whole
> idea of 1:1 relationship between schema and namespace and does cause various
> other issues.
>
> For example, we now have a nice .htaccess file in place that redirects the
> namespace URL's to the appropriate schema so things like XML editors can
> easily pick them up and provide nice contextual information while editing the
> XML. If you have the same namespace mapped to two separate schemas, that no
> longer would work and we're right back to where we started with that.
I do agree. Actually, after signing off yesterday I recalled you
mentioning an .htaccess file but then figured we may get it redirecting
to intermediate pages, such as the one linked to below:
http://www.w3.org/2005/08/addressing/
and in principle we'd have a Blueprint and Spring links there pointing
to the actual schemas.
But then I thought it was kind of a 'warning' sign, we may be able to
bypass this issue with linking to the actual schema representation, but
it will just back-fire at some later stage; it does need to be a 1 to 1
relationship indeed as you indicated, better not break that...
>
> If we change the areas of core from the Spring specific types to xsd:anyType,
> we likely could do it. That's acutally how the ie nterceptor lists work
> already. I'm honestly not sure why the properties don't already do it that
> way.
>
> A good start might just be to identify the areas that are different between
> the schemas and just list them out. If flipping from mapType -> xsd:anyType
> would fix it in all the cases, it might just be worth doing.
>
Cheers, Sergey
> Dan
>
>
>> 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
>
Re: Different namespaces for CXF Blueprint and Spring schemas
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, December 08, 2011 6:15:27 PM Sergey Beryozkin wrote:
> Hi Dan
.......
>
> 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>
This is basically what Aki was trying to do with RM and I kind of objected to
which started the whole discussion. It more or less goes against the whole
idea of 1:1 relationship between schema and namespace and does cause various
other issues.
For example, we now have a nice .htaccess file in place that redirects the
namespace URL's to the appropriate schema so things like XML editors can
easily pick them up and provide nice contextual information while editing the
XML. If you have the same namespace mapped to two separate schemas, that no
longer would work and we're right back to where we started with that.
If we change the areas of core from the Spring specific types to xsd:anyType,
we likely could do it. That's acutally how the interceptor lists work
already. I'm honestly not sure why the properties don't already do it that
way.
A good start might just be to identify the areas that are different between
the schemas and just list them out. If flipping from mapType -> xsd:anyType
would fix it in all the cases, it might just be worth doing.
Dan
> 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
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Different namespaces for CXF Blueprint and Spring schemas
Posted by Aki Yoshida <el...@googlemail.com>.
2011/12/8 Daniel Kulp <dk...@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<sb...@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
Re: Different namespaces for CXF Blueprint and Spring schemas
Posted by Sergey Beryozkin <sb...@gmail.com>.
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<sb...@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
Re: Different namespaces for CXF Blueprint and Spring schemas
Posted by Daniel Kulp <dk...@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.
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<sb...@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
Re: Different namespaces for CXF Blueprint and Spring schemas
Posted by Sergey Beryozkin <sb...@gmail.com>.
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-configuration-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<sb...@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
Re: Different namespaces for CXF Blueprint and Spring schemas
Posted by Aki Yoshida <el...@googlemail.com>.
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-configuration-schemas-tt5052010.html
regards, aki
2011/12/8 Sergey Beryozkin <sb...@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