[jira] Updated: (WSCOMMONS-14) Neethi (WS-Policy): Policy objects need attributes

["Brian Hulse (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/jira/browse/WSCOMMONS-14?page=all ]

Brian Hulse updated WSCOMMONS-14:
---------------------------------

    Attachment: patch.zip

This is the first time I've created a patch so the chances of me getting this right are ... well ... pretty near zero, so if I have to rework this, let me know and I'll comply. I have reworked some of the base code since it doesn't make sense anymore to have things such as Id and base (which should be removed) as special cases ... they are simply attributes. However, they do have their own access methods for usuability's sake. Once they are treated the same, serialization/deserialization becomes much more straightforward.

> Neethi (WS-Policy): Policy objects need attributes
> --------------------------------------------------
>
>          Key: WSCOMMONS-14
>          URL: http://issues.apache.org/jira/browse/WSCOMMONS-14
>      Project: WS-Commons
>         Type: New Feature

>   Components: Policy
>     Reporter: Brian Hulse
>     Priority: Minor
>  Attachments: patch.zip
>
> The latest WS-Policy specification allows for the extensibility of attributes so the Policy object needs to allow for this. 
> I'll contribute a fix shortly just so I can try out the process. 
> p.s. It may seem trivial but this is actually the first in a cluster of issues that will be raised over the next week. The reason is that we have a set of really useful test cases we'd like to share but we'll have to put in a bit of groundwork before these will function properly. To start with, the issues will be around closer adherence to the specification and some additional usuability enhancements ... I'm a complete novice to the process ... so please bear with me!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [jira] Updated: (WSCOMMONS-14) Neethi (WS-Policy): Policy objects need attributes

[Sanka Samaranayake <sa...@apache.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian,

There have been some minor changes the codebase and the renaming of
commons/policy to commons/neethi as per the final preparation for
Apache Neethi 1.0.1 release.

Can u please recreate the patch using the latest codebase and upload a
new patch?

Thanks,
Sanka

Brian Hulse (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/WSCOMMONS-14?page=all ]
>
> Brian Hulse updated WSCOMMONS-14:
> ---------------------------------
>
>     Attachment: patch.zip
>
> This is the first time I've created a patch so the chances of me
getting this right are ... well ... pretty near zero, so if I have to
rework this, let me know and I'll comply. I have reworked some of the
base code since it doesn't make sense anymore to have things such as Id
and base (which should be removed) as special cases ... they are simply
attributes. However, they do have their own access methods for
usuability's sake. Once they are treated the same,
serialization/deserialization becomes much more straightforward.
>
>> Neethi (WS-Policy): Policy objects need attributes
>> --------------------------------------------------
>>
>>          Key: WSCOMMONS-14
>>          URL: http://issues.apache.org/jira/browse/WSCOMMONS-14
>>      Project: WS-Commons
>>         Type: New Feature
>
>>   Components: Policy
>>     Reporter: Brian Hulse
>>     Priority: Minor
>>  Attachments: patch.zip
>>
>> The latest WS-Policy specification allows for the extensibility of
attributes so the Policy object needs to allow for this.
>> I'll contribute a fix shortly just so I can try out the process.
>> p.s. It may seem trivial but this is actually the first in a cluster
of issues that will be raised over the next week. The reason is that we
have a set of really useful test cases we'd like to share but we'll have
to put in a bit of groundwork before these will function properly. To
start with, the issues will be around closer adherence to the
specification and some additional usuability enhancements ... I'm a
complete novice to the process ... so please bear with me!
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEWNti/Hd0ETKdgNIRAgFuAJ0QtUCND2x0E/NeBOcWnikzH1UmTACeOYHZ
fcLR/SA6G2q16Dog/EPXuzw=
=dx1O
-----END PGP SIGNATURE-----