I would use code similar to below. The idea is to:
1) locate the SOAP service (wsdl2java should have generated a Locator)
2) Instantiate the stub class.
3) Set the username and password in the stub.
4) Make the SOAP call to a remote method.

The names of the Locator and Stub classes have been changed below to protect the innocent, but you'll get the idea. The answer to your question are the calls to the setUsername() and setPassword() methods. These are provided by the org.apache.axis.client.Stub class that your stub extends.

package client;

import client.stub.MySOAPServiceLocator;
import client.stub.HelloSoapBindingStub;


public class TestVersion
{
 public static void main( String[] args ) throws Exception
 {
 // Instantiate the webservice request.
 MySOAPServiceLocator l = new MySOAPServiceLocator();
 HelloSoapBindingStub tstub = (HelloSoapBindingStub) l.getHello();

 // Get the version from the SOAP service.
 // Assumes that the SOAP service has a method named "getVersion"
 // that returns a String.
 String version = null;
 try
 {
 tstub.setUsername( "user1" );
 tstub.setPassword( "pass1" );
 version = tstub.getVersion();
 System.out.println("Version: " + version);
 }
 catch( org.apache.axis.AxisFault af )
 {
 System.out.println("WRONG LOGIN: "+af.getMessage());
 }
 }
}

Your method likely will not be named "getHello". In the Locator code generated by wsdl2java, you should see a few methods that return your Stub. In mine, I see that one method has no arguments and one takes a URL object as an argument to return the Stub.

For example, I have web service named "FTSCMI" with a lengthy wsdl.
When I run wsdl2java (using ant), I get 4 files:

CmiSOAP.java (contains an interface)
CmiSOAPService.java (contains an interface)
CmiSOAPServiceLocator.java (contains the service locator)
FTSCMISoapBindingStub.java (contains the stub)

You should see methods in the stub that correspond to the web methods exposed in your web service. Using those methods from the Stub class will save some pain and helps isolate the SOAP stuff from your client-side business code. This works for me with MIME/DIME attachments and plain parameters....I can't say that I've used Java Objects as parameters since I usually have to interop with MS .Net

I may be able to whip out a complete example using authentication in the next day or so. Note that I'm running JBoss-3.2.5 and I use the axis service that is embedded by JBoss as /jboss-net.

r,
Lance

I have run Axis 1.1 installed as a war under JBoss and JBoss-net services in the same server instance without any trouble. Using JBoss-net (which is also built on Axis 1.1) has an advantange in that you don't need to mess with the Axis deploy/undeploy descriptors or plug your apps under the Axis.war directory structure.

I really like packaging the webservices as separate WSRs and deploying them like other EARs or WARs - by just dropping them into the server's deploy directory.

But, moving forward in JBoss-4, we're supposed to use the ws4ee way of doing things. It's still Axis 1.1 based as far as I've read, but the deployment mechanics are J2EE 1.4 compliant. I'm experimenting with ws4ee with the intent to port all my webservices over to the "church approved" way of doing things.

r,
Lance