hi,
Is it allowed to merge the spring and blueprint versions of
configuration schemas and use the resulting schema for both cases?
If the answer is a definitive no, the rest of this mail can be
ignored. If the answer is yes or maybe, I would like to explain why I
am asking this question.
For the
Hi Aki，
If you take a look at the camel-blueprint [1], you will find the schema
is generated from JAXB annotated class and replace the target namespace
with the blueprint one.
In this way we could reuse the module class as much as possible.
Hi Benson
On 05/12/11 16:11, Benson Margulies wrote:
I translate Anne's answer just now as follows:
To return information to the client, it has to be 2xx. So in the
success case, it has to be 2xx. If it fails, we can do whatever we
prefer: 2xx and no CORS headers or 4xx. I'm with you on a 4xx.
On Tuesday, December 06, 2011 9:25:46 PM Willem Jiang wrote:
Hi Aki，
If you take a look at the camel-blueprint [1], you will find the schema
is generated from JAXB annotated class and replace the target namespace
with the blueprint one.
And I personally think that is a crappy solution. It
On Tuesday, December 06, 2011 10:42:41 AM Sergey Beryozkin wrote:
Hi
On 05/12/11 19:37, Daniel Kulp wrote:
On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote:
Big +1 from me on this (obviously). The fragment approach seems like a
sensible idea to me as a migration strategy.
I have no problem with the proposal, but I would like to point out that you
can accomplish much of it today using existing functionality. The call for
the SecurityConstants.USERNAME property is done via a contextual property.
Thus, it COULD be set via spring, but it can also be set in a
