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 va
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 s
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.
On 06/12/11 10:42, 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.
Another approach COULD be to
Hi Willem,
thanks for the information.
This is certainly one option that we can take, which is similar to
option 2 but without the disadvantage of having duplicated classes or
having to maintain manually two almost identical schemas.
But it is kind of complex. I am feeling that everything would b
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.
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.
[1]https://svn.apache.org/repos/asf/camel/trunk/com
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 I would like to start a discussion on extending the usage of a
ClientCallbackHandler.
Currently the username for a a service consumer is rather static configured
via ws-security.username property. This works great for situations where a
user is fixed assigned to a service-consumer. But if diffe
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.
Another approach COULD be to create a "cxf-core" (not cxf-rt-core) bundl
>> WRT to changing packages, if you are really worried about backward
>> compatibility but would like to refactor the split packages out you
>> *could* consider renaming the package and creating a compatibility
>> bundle or fragment that contains the 'old' split packages and
>> delegates to the new
11 matches
Mail list logo
