+.5 It is always good for Axis to be nice to users like yourself who want to use Axis and extend implementation classes. Being able to customize Axis is one of its strengths.
On the flip side, having a zillion little function calls makes the code hard to read and maintain and this change may only ever benefit your use case. So I would say submit the patch in a Jira bug/enhancement. Probably won't make 1.2 but could easily go in shortly there-after. If you can refactor in a clean way, then it will be goodness. Note that I am not speaking for the entire team on this, just myself. -- Tom Jordahl Macromedia Server Development > -----Original Message----- > From: Matthew-J Watson [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 31, 2005 3:45 AM > To: [email protected] > Subject: Issues with Extensibility of CommonsHttpSender/HttpSender > > Hi Guys, > > This email is directed towards the developers, but may also be of interest > to users. > > I am trying to get an AXIS SOAP client (tried 1.1 and 1.2rc3) to > authenticate with a server which is using the microsoft SPNEGO > authorization scheme (similar to basic auth, but uses kerberos tokens > instead) - It works fine from C# etc but I'm trying to write a test > harness in java. > > SPNEGO works like basic auth in: > client -> server: GET xxx > server->client: 401 with WWW-Authenticate: Negotiate > client->server GET xxx with Authorization: Negotiate > base64endocdedkerberostoken... > > The classes that do the authorization are the > org.apache.axis.transport.http.CommonsHttpSender and > org.apache.axis.transport.http.HttpSender. > We have plugin classes that extend the commons-httpclient to do client > side SPNEGO handling and so want to use the CommonsHttpSender to make > things easier. > > The problem is, we need to HttpClient.getState().setCredentials() with a > custom credential on the client before executing the method. Due to the > way this class is written, we have had to copy the entire class to our own > version and modify the methods. If we had a mechanism for plugging into > HttpSender, it would suffer from the same problems. Extending either > sender without completely replacing it is impossible. > > I'd consider submitting a patched version which would be more extensible > (i.e. make more methods and protected ones at that, where at least we'd be > able to intercept the HttpClient before and after the execute was called > and set the credentials in a derived class) but I'd like to get feedback > from other developers first who have more experience with the code (I'm on > day 2 now). > > Any opinions? > > Matthew Watson > > > > -- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. >
