| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@739528 13f79535-47bb-0310-9956-ffa450edef68
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
and from org.osoa.sca.annotations to org.oasisopen.sca.annotation to reflect the new package names in the OASIS Open SCA specifications.
To do this, I:
* Renamed the org.osoa.sca package to org.oasisopen.sca using Eclipse refactoring
* Renamed the org.osoa.sca.annotations package to org.oasisopen.sca.annotation using Eclipse refactoring
* Did a global search and replace for all remaining instances of the old org.osoa package names and replaced with the new org.oasisopen version
Hopefully, I have not missed too many instances of the old package name
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@738490 13f79535-47bb-0310-9956-ffa450edef68
|
| |
|
|
| |
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@723439 13f79535-47bb-0310-9956-ffa450edef68
|
| |
|
|
|
|
| |
authentication schema across binding.ws and binding.jm. No authentication is actually performed here. That is left for users to provide their own policy interceptors. However tokens are passed and security Subjects/Principals are created. This exercise has highlighted some awkwardness in the process of building policy implementations. I'll post about this on the mail list.
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@695374 13f79535-47bb-0310-9956-ffa450edef68
|
|
|
points. Generic username/password processing is added as an interceptor. Specific axis configuration is performed by new logic specific to binding.ws which is invoked if the basic auth policy is present (we need to think about this mechanism). I added a binding-ws-axis2-policy module as a replacement for policy-security-ws but haven't moved over to it yet. I also added a message header map to Message but have only been experimenting to date.
git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@692411 13f79535-47bb-0310-9956-ffa450edef68
|
