axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Reinhold" <>
Subject RE: rampart configs in policy.xml
Date Sat, 29 Sep 2012 14:18:00 GMT
I am not sure what that will cost the development community but it seems
logical that the policy file should only contain WS-*policy elements. I
won’t have to clean it up before giving it to a peer running something like
NetKernel. Likewise it would be convenient to obtain a policy from a peer
and not have to edit it to make it work with my Apache based server/client.
I could suggest the enhancement but how costly would that be for current


From: Martin Gainty [] 
Sent: Saturday, September 29, 2012 9:18 AM
Subject: RE: rampart configs in policy.xml


no conflict as long as the namespace (and its associated XSD) are unique for

<wsp:Policy xmlns:wsp=""
<ramp:RampartConfig xmlns:ramp=""> 

where the actual validating xsd is located at 

the target namespace attribute from the validating xsd is the xmlns:ramp
from RampartConfig so *there is targetNamespace redirection involved*
<xs:schema targetNamespace=""
elementFormDefault="qualified" attributeFormDefault="unqualified">

personally I dont like those redirections as it makes the developer and the
parser *hunt* for accompanying targetNamespace inside the registered xsds
if you want to suggest eliminating the targetNamespace redirect and go for
'direct approach' e.g.
<> ">  

i think a clear majority of axis2 developers and implementors would back you
*any enhancement that eliminates obfuscation makes the tool more
user-friendly and attracts more devs to implement this framework in their
business or institution*

go ahead and file the Request For Enhancement
Martin Gainty 
place long-winded disclaimer here


Subject: RE: rampart configs in policy.xml
Date: Sat, 29 Sep 2012 06:51:38 -0400

I just expected that the only entrants in the policy would be those from the
schemas. What happens if the rampart stuff is removed from the policy?  (I
would expect those entrants to be only in the apache-specific xmls.)


From: Martin Gainty [] 
Sent: Friday, September 28, 2012 9:16 PM
Subject: RE: rampart configs in policy.xml


Hello Brian

if you get a chance to look at sts-policy-asymm-binding.xml you will see
namespace assignments for both wssecurity
and policy schema xsd's located at

<wsp:Policy wsu:Id="1" 

is there a better way to ingest and parse the wssecurity and policy schemas?

Martin Gainty 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
dient lediglich dem Austausch von Informationen und entfaltet keine
rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire
informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
de ceci est interdite. Ce message sert à l'information seulement et n'aura
pas n'importe quel effet légalement obligatoire. Étant donné que les email
peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
aucune responsabilité pour le contenu fourni.



Subject: rampart configs in policy.xml
Date: Fri, 28 Sep 2012 20:17:35 -0400

Why is there rampart configuration information in policy.xml files? Aren’t
these policy files supposed to be based upon the WS-Policy and WS-Security
Policy standards? The rampart information makes them unusable in
client/service applications that are not based upon the Apache projects;
well, bypassing any parse and ignore.


Brian Reinhold


    tel 603 868 8411 x207



No virus found in this message.
Checked by AVG -
Version: 2012.0.2221 / Virus Database: 2441/5296 - Release Date: 09/28/12


No virus found in this message.
Checked by AVG -
Version: 2012.0.2221 / Virus Database: 2441/5298 - Release Date: 09/29/12

No virus found in this message.
Checked by AVG -
Version: 2012.0.2221 / Virus Database: 2441/5298 - Release Date: 09/29/12

View raw message