+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