+1 for Nandana as the release manager..

thanks,
Thilina

On Wed, Jul 9, 2008 at 4:55 AM, Lahiru Sandakith <[EMAIL PROTECTED]>
wrote:

>
> +1 for Nandana as the Release Manager
>
> Regards
> Lahiru Sandakith
>
>
> On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <[EMAIL PROTECTED]>
> wrote:
>
>> Nandana,
>>
>> +1 from me for you to be the Release Manager for 1.4.1
>>
>> IMHO, we should use 1.4 branch. The *ONLY* change should be the
>> security change. Nothing more.
>>
>> thanks,
>> dims
>>
>> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
>> <[EMAIL PROTECTED]> wrote:
>> > I would like to volunteer to be the release manager for Axis2 1.4.1.
>> >
>> > I think we can fix the critical issues in the 1.4 branch (or a 1.4.1
>> branch
>> > ) and do the 1.4.1 release. I don't think doing 1.4.1 from the trunk is
>> the
>> > appropriate way as trunk is now java 1.5 and has lot of major changes
>> after
>> > Axis2 1.4 . However we can fix any issues that are not already fixed in
>> the
>> > trunk at the same time when we fix those in the branch.
>> >
>> > Hope this is oky with Axis2 release guidelines.
>> >
>> > thanks,
>> > nandana
>> >
>> > On Tue, Jul 1, 2008 at 6:39 PM, Davanum Srinivas <[EMAIL PROTECTED]>
>> wrote:
>> >>
>> >> IMHO, The logic is the same as for blockers. If there is a work
>> >> around, it's not a blocker. So i am +0 on a 1.4.1 since there is a
>> >> work around that can be documented.
>> >>
>> >> That said, If someone is willing to drive a 1.4.1 as the release
>> >> manager, please do go ahead.
>> >>
>> >> thanks,
>> >> dims
>> >>
>> >> On Tue, Jul 1, 2008 at 2:48 AM, Sanka Samaranayake <[EMAIL PROTECTED]>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > For the users who is already using 1.4 version, the workaround would
>> be
>> >> > to
>> >> > define policies in services.xml without using <wsa:PolicyAttachment>.
>> >> > Then
>> >> > the problem is that those policies will appear in <wsdl:PortType>
>> which
>> >> > is
>> >> > not correct but security will apply for both format of service URLs.
>> >> >
>> >> > Hence +1 for fixing that issue and do 1.4.1 release.
>> >> >
>> >> > Thanks,
>> >> > Sanka
>> >> >
>> >> >
>> >> > On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya
>> >> > <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> Hi,
>> >> >>    There are few issues with Axis2 1.4 / Rampart 1.4 with the new
>> >> >> policy
>> >> >> configuration. The new policy configuration which allows us to apply
>> >> >> policies to binding hierarchy is a great feature when in comes to ws
>> >> >> security policy configuration. It allows security policies to be
>> >> >> attached to
>> >> >> the correct attachment points. But there are few issues that need to
>> be
>> >> >> fixed in Axis2 1.4. I will list them below.
>> >> >>     1.) If we configure security using new configuration, service
>> can
>> >> >> be
>> >> >> accessed without security.
>> >> >>          In Axis2 1.4, a service is exposed in two EPRs (consider
>> SOAP
>> >> >> 1.1
>> >> >> binding).
>> >> >>            eg.
>> >> >>
>> >> >>
>> >> >>
>> http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
>> >> >>                http://localhost:8080/axis2/services/SecureService
>> >> >>           But if we you set the policies using the new
>> configuration,
>> >> >> if
>> >> >> you do a web service call to the older EPR, you can access the
>> service
>> >> >> without any security even though it is secured using the binding
>> >> >> hierarchy.
>> >> >> This happens because if we call the old EPR, it is not dispatched to
>> a
>> >> >> binding. But this leaves the service vulnerable. I think we should
>> >> >> dispatch
>> >> >> to one of the bindings may be using soap envelope version if we have
>> >> >> only
>> >> >> one binding with that soap version. We should have a way to dispatch
>> >> >> messages which comes to old EPR to one of the bindings else we
>> should
>> >> >> have
>> >> >> an option to disable that EPR.
>> >> >>
>> >> >>     2.) In the out flow, policies are not set correctly in the
>> binding
>> >> >> message.
>> >> >>           This is fixed in the trunk but this bug is there in Axis2
>> >> >> 1.4.
>> >> >>
>> >> >>    So the option we have is to configure security using the old
>> >> >> configuration. But then the problem is policies are attached to the
>> >> >> port
>> >> >> type which is the correct way to do if we have policies using
>> >> >> <service>,<operation><message> tags. But this makes Axis2 not
>> >> >> interoperable
>> >> >> as security policies should be attached to binding hierarchy
>> according
>> >> >> WS
>> >> >> Security policy specification. Ideally we should always use the new
>> >> >> configuration to apply security. And code generation also doesn't
>> work
>> >> >> correctly when the policies attached to the port type (polices are
>> not
>> >> >> correctly attached to the stub).
>> >> >>
>> >> >>    So I think it would be great if can consider a Axis2 1.4.1 with
>> >> >> these
>> >> >> things fixed.
>> >> >>
>> >> >> thanks,
>> >> >> nandana
>> >> >
>> >> >
>> >> > --
>> >> > Sanka Samaranayake
>> >> > WSO2 Inc.
>> >> >
>> >> > http://sankas.blogspot.com/
>> >> > http://www.wso2.org/
>> >>
>> >>
>> >>
>> >> --
>> >> Davanum Srinivas :: http://davanum.wordpress.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >
>>
>>
>>
>> --
>> Davanum Srinivas :: http://davanum.wordpress.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> Thanks
> Lahiru Sandakith
>
> http://sandakith.wordpress.com/
> GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F




-- 
Thilina Gunarathne - http://thilinag.blogspot.com

Reply via email to