You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Jeffrey Hau <jh...@doc.ic.ac.uk> on 2002/06/17 20:33:37 UTC
How to enable Remote administor access??
when i tried to use the Admin class to process a WSDD document, i get
the following error
AxisFault:Remote Adminstratot access is not allowed.
anyone knows how to solve this problem?
thanks
Jeff
Re: Clarification about bean mapping
Posted by Ulrich Winter <ul...@gmx.de>.
David,
My understanding for your questions in B is, that
Webservices are designed so that the wsdl file is the interface
used for accessing that service from any language, which has a soap binding.
So if you implement the service in java, all you have at the client side ist
the wsdl
description - nothing else.
In your case, you want to use java at the server and client side. But that's
not the general case.
So assuming on the client side you have only the wsdl description, the
wsdl2java tool
needs to generate the bean classes, too.
I think one should strictly separate the server side and client side classes
in completely
different directories.
For C:
the beanMapping is only a shorthand for the general typeMapping element with
predefined serializer and deserializer attributes.
It's a shorthand if you manually write deployment descriptors.
Both forms are semantically equal.
D:
That question doesn't come up, if you strictly separate the client and the
server side.
The client uses only the tool-generated bean class. The server uses your
manually written class.
Bye,
Uli
--
--
ulrich.winter@gmx.de
Re: Clarification about bean mapping
Posted by Martin Jericho <ma...@jabcreative.com>.
Clarification about bean mappingAnswers inline...
----- Original Message -----
From: David Gadd
To: axis-user@xml.apache.org
Sent: Thursday, June 20, 2002 8:29 AM
Subject: Clarification about bean mapping
Hi,
I have some questions about using Java Beans in Axis. I'm hoping from these answers to supplment a "using Axis" article/documentation that I've been working on. Therefore I'll try and be as clear as possible with my questions.
A. JAVA BEAN SETUP SCENARIO
B. STANDARD GENERATION OF WSDL/STUBS/SKELETONS
C. DEPLOY.WSDD SETTING QUESTIONS
D. MODIFICATION OF THE '...IMPL' STUB FILE QUESTIONS
E. CONCLUSION
A. JAVA BEAN SETUP SCENARIO
I created two classes within a package called "jbpackage":
JavaBeanBuilder.java
MyBean.java
MyBean.java contains two private varaibles with getters and setters as below. I've told it to implement Serializable but my understanding is that Axis doesn't require that as long as it contains getters and setters. (Correct?)
Correct.
//MyBean.java
package jbpackage;
import java.io.Serializable;
public class MyBean implements Serializable {
private String firstName;
private String lastName;
public String getFirstName() {return firstName;}
public String getLastName() {return lastName;}
public void setFirstName(String text) {firstName = text;}
public void setLastName(String text) {lastName = text;}
}
JavaBeanBuilder sets String parameters as values in the bean and then returns the bean:
//JavaBeanBuilder.java
package jbpackage;
public class JavaBeanBuilder {
public MyBean buildBean(String firstName, String lastName) {
MyBean mb = new MyBean();
mb.setFirstName(firstName);
mb.setLastName(lastName);
return mb;
}
}
Normally you would just specify an interface for the main service class. eg:
public interface JavaBeanBuilder {
public MyBean buildBean(String firstName, String lastName);
}
Note also that you don't have to implement any of your getter/setter methods in your beans. You can just use public member fields, and axis will generate a class containing private members with associated getter and setter methods for you. This makes these classes easier to maintain, because there is much less clutter for readablility and less typing to add a new field. For example, you could use the following source code to generate exactly the same MyBean class:
public class MyBean {
public String firstName;
public String lastName;
}
Note however that if you try to go one step further and define it using an interface, AXIS will generate an abstract class, which is not what we want. Only the actual service class should be defined as an interface.
**********************************
B. STANDARD GENERATION OF WSDL/STUBS/SKELETONS
I do the following steps:
1) compile JavaBeanBuilder and MyBean
2) run Java2WSDL on JavaBeanBuilder to create the WSDL file.
3) run WSDL2Java on the wsdl file to generate the stubs and skeletons in a SUBPACKAGE to jbpackage called "jbws". This is important further down as duplicately-named classes are generated which are only distinguishable from the originals based on their package path.
4) This results in the following directory hierarchy:
/javabeanbuilder.wsdl
/jbpackage/JavaBeanBuilder.class
/jbpackage/JavaBeanBuilder.java
/jbpackage/MyBean.class
/jbpackage/MyBean.java
/jbpakcage/jbws/JavaBeanBuilder.java
/jbpakcage/jbws/JavaBeanBuilderService.java
/jbpakcage/jbws/JavaBeanBuilderServiceLocator.java
/jbpakcage/jbws/JavabeanbuilderSoapBindingImpl.java
/jbpakcage/jbws/JavabeanbuilderSoapBindingStub.java
/jbpakcage/jbws/MyBean.java
/jbpakcage/jbws/deploy.wsdd
/jbpakcage/jbws/undeploy.wsdd
Here is my directory structure:
/MyProject - root project directory
/MyProject/src/java - contains all manually written source files
/MyProject/src/java/jbpackage - contains source files for the main program
/MyProject/src/java/jbpackage/axis - contains source files to be fed into axis (eg MyBean.java and JavaBeanBuilder.java)
/MyProject/src/java/jbpackage/ws - contains source files which are to override generated axis classes (eg JavaBeanBuilderSoapBindingImpl.java)
/MyProject/build - contains ANT build files for main program
/MyProject/build/generated/bin/classes - contains generated class files for main program
/MyProject/build/generated/axis - contains files generated by axis (eg JavaBeanBuilder.wsdl)
/MyProject/build/generated/axis/bin/classes - contains class files used as input into Java2WSDL
/MyProject/build/generated/axis/bin/classes/jbpackage/axis/MyBean.class - class used in this example
/MyProject/build/generated/axis/bin/classes/jbpackage/axis/JavaBeanBuilder.class - class used in this example
/MyProject/build/generated/axis/src - contains java source files generated by WSDL2Java
/MyProject/build/generated/axis/src/jbpackage/ws/MyBean.java - generated java file used in this example
/MyProject/build/generated/axis/src/jbpackage/ws/JavaBeanBuilder.java - generated java file used in this example
Here is the build process:
1. Create the axis source files in /MyProject/src/java. Put them in a package called "jbpackage.axis"
2. Use the ANT build file in /MyProject/build with a target name of "AXIS" to generate the finished class files which end up in /MyProject/build/generated/bin/classes. Here are the steps performed by this target:
- Compile ONLY the files in /MyProject/src/java/jbpackage/axis into /MyProject/build/generated/axis/bin/classes. Note that these classes do not end up in your finished program.
- Run Java2WSDL on these classes to generate /MyProject/build/generated/axis/JavaBeanBuilder.wsdl
- Run WSDL2Java on the WSDL file to generate the java files in /MyProject/build/generated/axis/src, using the package "jbpackage.ws". Note that the generated source files shouldn't go into the same area with the rest of your source files.
- Compile these java files into /MyProject/build/generated/bin/classes
3. If necessary, copy /MyProject/build/generated/axis/src/jbpackage/ws/JavaBuilderSoapBindingImpl.java into the directory /MyProject/src/java/jbpackage/ws, and modify it implement the service methods.
4. Use the ANT build file in /MyProject/build with the default target to compile all the source files under /MyProject/src/java into /MyProject/build/generated/bin/classes. Note that this should EXCLUDE the files in /MyProject/src/java/jbpackage/axis.
Now you have a clean directory structure which completely separates generated files from your own source files. The main program uses only the bean classes in jbpackage.ws, so there are no _forced_ naming conflicts.
AXIS does not allow you (easily) to send and receive your existing beans in RPC calls. The generated bean classes are really only data containers. Your "real" MyBean, which also contains business logic, would appear in the "jbpackage" package, and would have a constructor that takes a jbpackage.ws.MyBean object as input, and a method which generates a jbpackage.ws.MyBean object. Note that if your real bean is called "MyBean", you might want to rename the generated bean to something else (eg MyBeanRPC) to avoid duplicate class names.
What I also do is create a class for each service method, so that the service class itself doesn't get too big if there are many methods. It also separates the code for what are probably completely unrelated methods.
This is the way I do things. It is not the only way, but I have found it to be the simplest and cleanest approach.
**********************************
C. DEPLOY.WSDD SETTING QUESTIONS
The deploy.wsdd file that has been auto-generated by the WSDL2Java utility uses DIFFERENT syntax than that recommended in the user guide:
1) The auto-generated deploy.wsdd refers to the bean within the service as a 'typeMapping' element:
<service name="javabeanbuilder" provider="java:RPC">
<parameter name="className" value="jbpackage.jbws.JavabeanbuilderSoapBindingImpl"/>
<operation name="buildBean" returnQName="return" >
<parameter name="in0" type="tns:string" xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"/>
<parameter name="in1" type="tns:string" xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"/>
</operation>
<parameter name="allowedMethods" value="buildBean"/>
<parameter name="scope" value="Session"/>
<typeMapping
xmlns:ns="urn:javabeanbuilder"
qname="ns:MyBean"
type="java:jbpackage.jbws.MyBean"
serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
/>
</service>
2) But the supplied user guide html document recommends the user of a 'beanMapping' element which includes an extra attribute called 'languageSpecificType' and LEAVES OUT the references to the serializer and deserializer attributes:
<beanMapping qname="ns:local" xmlns:ns="someNamespace"
languageSpecificType="java:my.java.thingy"/>
So, my first question is: once the WSDL2Java utility has auto-generated the deploy.wsdd file for a web service containing a bean, WHAT, IF ANY modifications should be manually made to the deploy.wsdd file? Are both solutions above "correct", but variations on approach. If true, which of the two is prefereable? Why?
Don't know about this one sorry!
**********************************
D. MODIFICATION OF THE '...IMPL' STUB FILE QUESTIONS
Assuming I now have the correct answers for section C above, there is still the issue of the fleshing out of the template found in "/jbpakcage/jbws/JavabeanbuilderSoapBindingImpl.java"
With simple classes being implemented as a web service, I would just import the original class, create an instance of it, and pass a method call to it. However, in this case, it gets complicated because there is a second class, the bean involved, and the WSDL2Java utility creates copies of the bean within the subpackage.
My attempted solution is convoluted, and I don't think it is correct. I import both the original class and original bean from the original "jbpackage". I then create a class level variable instance of the jbpackage.JavaBeanBuilder named "jbb". Then, within the buildBean method, I pass the 2 String parameters to the "jbb" object's buildBean method, and assign the return value to a newly create instance of jbpackage.MyBean named "mb".
I then simply transfer the values from this bean to a new instance of the jbpackage.jbws.MyBean. While this compiles, I think of it as a hack, and not resolving the problem.
Have a look:
package jbpackage.jbws;
import jbpackage.JavaBeanBuilder;
import jbpackage.MyBean;
public class JavabeanbuilderSoapBindingImpl implements jbpackage.jbws.JavaBeanBuilder {
jbpackage.JavaBeanBuilder jbb = new jbpackage.JavaBeanBuilder();
public jbpackage.jbws.MyBean buildBean(java.lang.String in0, java.lang.String in1)
throws java.rmi.RemoteException {
jbpackage.MyBean mb = jbb.buildBean(in0, in1);
jbpackage.jbws.MyBean mbws = new jbpackage.jbws.MyBean();
mbws.setFirstName(mb.getFirstName());
mbws.setLastName(mb.getLastName());
return mbws;
}
}
So, I don't think I have understood the solution to this problem (the problem of populating the template in the auto-generated SoapBindingImpl class) correctly.
Can someone provide me with a correct solution?
If you used all of the recommendations from section B, your classes would look like this:
Note:
- I do not use a jbpackage.JavaBeanBuilder class as you did in your code. It is very unlikely that you would want a single class to handle all of your services methods in reality
- I renamed the JavaBeanBuilder class to MyService, to indicate the fact that is represents a service with multiple method calls rather than a single method.
- I have also added another service method (getFullName) to clarify some of my other points
- I haven't compiled any of this so there could be typo's!
------------
package jbpackage.axis;
public interface MyService {
public MyBeanRPC buildBean(String firstName, String lastName);
public String getFullName(MyBeanRPC myBeanRPC);
}
------------
package jbpackage.axis;
public class MyBeanRPC {
public String firstName;
public String lastName;
}
------------
package jbpackage.ws;
import jbpackage.*;
import jbpackage.ws.impl.*;
public class MyServiceSoapBindingImpl implements MyService {
public MyBeanRPC buildBean(String firstName, String lastName) throws java.rmi.RemoteException {
return BuildBean.invoke(firstName, lastName);
}
public String getFullName(MyBeanRPC myBeanRPC) throws java.rmi.RemoteException {
return GetFullName.invoke(myBeanRPC);
}
}
------------
package jbpackage.ws.impl;
import jbpackage.*;
import jbpackage.ws.*;
public class BuildBean {
public static MyBeanRPC invoke(String firstName, String lastName) {
return new MyBean(firstName, lastName).toRPC();
}
}
------------
package jbpackage.ws.impl;
import jbpackage.*;
import jbpackage.ws.*;
public class GetFullName {
public static String invoke(MyBeanRPC myBeanRPC) {
return new MyBean(myBeanRPC).getFullName();
}
}
---------------
package jbpackage;
import jbpackage.ws.*;
public class MyBean {
private String firstName;
private String lastName;
public MyBean(String firstName, String lastName) {
this.firstName=firstName;
this.lastName=lastName;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName=firstName;
}
public String getLastName() {
return LastName;
}
public void setLastName(String lastName) {
this.lastName=lastName;
}
public String getFullName() {
// This method is just a trivial example of implementing the business logic of the class
return firstName+" "+lastName;
}
// The following constructor and method are required to convert from/to MyBeanRPC objects:
public MyBean(MyBeanRPC myBeanRPC) {
firstName=myBeanRPC.getFirstName();
lastName=myBeanRPC.getLastName();
}
public MyBeanRPC toRPC() {
MyBeanRPC myBeanRPC=new MyBeanRPC();
myBeanRPC.setFirstName(firstName);
myBeanRPC.setLastName(lastName);
return myBeanRPC;
}
}
E. CONCLUSION
My goal out of this would be able to write clear, repeatable documentation that explains how to start from a simple bean and a utility class that passes in or returns said bean and succesfully generates the WSDL, stubs, and skeletons (with modifications to the SoapBindingImpl class) to use the bean as a web service.
Thanks for any help anyone can give,
David Gadd
gaddzeit.com
I would appreciate any comments on this myself. I am relatively new to axis so I would be interested to compare this to any other approaches that people are using.
Martin Jericho
Re: Clarification about bean mapping
Posted by Heitzso <he...@bellsouth.net>.
One suggestion -- include a boolean attribute in the bean.
I did with
public boolean isSomething()
public void setIsSomething(boolean something)
and axis complained (I'm not that familiar w/ beans and the
method names came from a book I had on java beans).
Switched over to standard (but not recommended by
the book for boolean attributes)
public bootlean getSomething()
public void setSomething(boolean something)
and axis was happy.
Another, but more complicated example, would be
a bean that contained another bean. But there's no
trick there -- it just works.
On Wed, 2002-06-19 at 18:29, David Gadd wrote:
> Hi,
>
> I have some questions about using Java Beans in Axis. I'm hoping from
> these answers to supplment a "using Axis" article/documentation that
> I've been working on. Therefore I'll try and be as clear as possible
> with my questions.
>
> A. JAVA BEAN SETUP SCENARIO
> B. STANDARD GENERATION OF WSDL/STUBS/SKELETONS
> C. DEPLOY.WSDD SETTING QUESTIONS
> D. MODIFICATION OF THE '...IMPL' STUB FILE QUESTIONS
> E. CONCLUSION
>
> A. JAVA BEAN SETUP SCENARIO
>
> I created two classes within a package called "jbpackage":
>
> JavaBeanBuilder.java
> MyBean.java
>
> MyBean.java contains two private varaibles with getters and setters
> as below. I've told it to implement Serializable but my understanding
> is that Axis doesn't require that as long as it contains getters and
> setters. (Correct?)
>
> //MyBean.java
> package jbpackage;
> import java.io.Serializable;
>
> public class MyBean implements Serializable {
> private String firstName;
> private String lastName;
>
> public String getFirstName() {return firstName;}
> public String getLastName() {return lastName;}
> public void setFirstName(String text) {firstName = text;}
> public void setLastName(String text) {lastName = text;}
> }
>
>
> JavaBeanBuilder sets String parameters as values in the bean and then
> returns the bean:
>
> //JavaBeanBuilder.java
> package jbpackage;
>
> public class JavaBeanBuilder {
> public MyBean buildBean(String firstName, String lastName) {
> MyBean mb = new MyBean();
> mb.setFirstName(firstName);
> mb.setLastName(lastName);
> return mb;
> }
> }
>
> **********************************
>
> B. STANDARD GENERATION OF WSDL/STUBS/SKELETONS
>
> I do the following steps:
> 1) compile JavaBeanBuilder and MyBean
> 2) run Java2WSDL on JavaBeanBuilder to create the WSDL file.
> 3) run WSDL2Java on the wsdl file to generate the stubs and skeletons
> in a SUBPACKAGE to jbpackage called "jbws". This is important further
> down as duplicately-named classes are generated which are only
> distinguishable from the originals based on their package path.
> 4) This results in the following directory hierarchy:
> /javabeanbuilder.wsdl
> /jbpackage/JavaBeanBuilder.class
> /jbpackage/JavaBeanBuilder.java
> /jbpackage/MyBean.class
> /jbpackage/MyBean.java
> /jbpakcage/jbws/JavaBeanBuilder.java
> /jbpakcage/jbws/JavaBeanBuilderService.java
> /jbpakcage/jbws/JavaBeanBuilderServiceLocator.java
> /jbpakcage/jbws/JavabeanbuilderSoapBindingImpl.java
> /jbpakcage/jbws/JavabeanbuilderSoapBindingStub.java
> /jbpakcage/jbws/MyBean.java
> /jbpakcage/jbws/deploy.wsdd
> /jbpakcage/jbws/undeploy.wsdd
>
> **********************************
>
> C. DEPLOY.WSDD SETTING QUESTIONS
>
> The deploy.wsdd file that has been auto-generated by the WSDL2Java
> utility uses DIFFERENT syntax than that recommended in the user guide:
>
> 1) The auto-generated deploy.wsdd refers to the bean within the
> service as a 'typeMapping' element:
>
> <service name="javabeanbuilder" provider="java:RPC">
> <parameter name="className"
> value="jbpackage.jbws.JavabeanbuilderSoapBindingImpl"/>
> <operation name="buildBean" returnQName="return" >
> <parameter name="in0" type="tns:string"
> xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"/>
> <parameter name="in1" type="tns:string"
> xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"/>
> </operation>
> <parameter name="allowedMethods" value="buildBean"/>
> <parameter name="scope" value="Session"/>
>
> <typeMapping
> xmlns:ns="urn:javabeanbuilder"
> qname="ns:MyBean"
> type="java:jbpackage.jbws.MyBean"
> serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
> deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
> encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
> />
> </service>
>
> 2) But the supplied user guide html document recommends the user of a
> 'beanMapping' element which includes an extra attribute called
> 'languageSpecificType' and LEAVES OUT the references to the
> serializer and deserializer attributes:
>
> <beanMapping qname="ns:local" xmlns:ns="someNamespace"
> languageSpecificType="java:my.java.thingy"/>
>
>
> So, my first question is: once the WSDL2Java utility has
> auto-generated the deploy.wsdd file for a web service containing a
> bean, WHAT, IF ANY modifications should be manually made to the
> deploy.wsdd file? Are both solutions above "correct", but variations
> on approach. If true, which of the two is prefereable? Why?
>
> **********************************
>
> D. MODIFICATION OF THE '...IMPL' STUB FILE QUESTIONS
>
> Assuming I now have the correct answers for section C above, there is
> still the issue of the fleshing out of the template found in
> "/jbpakcage/jbws/JavabeanbuilderSoapBindingImpl.java"
>
> With simple classes being implemented as a web service, I would just
> import the original class, create an instance of it, and pass a
> method call to it. However, in this case, it gets complicated because
> there is a second class, the bean involved, and the WSDL2Java utility
> creates copies of the bean within the subpackage.
>
> My attempted solution is convoluted, and I don't think it is correct.
> I import both the original class and original bean from the original
> "jbpackage". I then create a class level variable instance of the
> jbpackage.JavaBeanBuilder named "jbb". Then, within the buildBean
> method, I pass the 2 String parameters to the "jbb" object's
> buildBean method, and assign the return value to a newly create
> instance of jbpackage.MyBean named "mb".
>
> I then simply transfer the values from this bean to a new instance of
> the jbpackage.jbws.MyBean. While this compiles, I think of it as a
> hack, and not resolving the problem.
>
> Have a look:
>
> package jbpackage.jbws;
>
> import jbpackage.JavaBeanBuilder;
> import jbpackage.MyBean;
>
> public class JavabeanbuilderSoapBindingImpl implements
> jbpackage.jbws.JavaBeanBuilder {
>
> jbpackage.JavaBeanBuilder jbb = new jbpackage.JavaBeanBuilder();
>
> public jbpackage.jbws.MyBean buildBean(java.lang.String in0,
> java.lang.String in1)
> throws java.rmi.RemoteException {
>
> jbpackage.MyBean mb = jbb.buildBean(in0, in1);
> jbpackage.jbws.MyBean mbws = new jbpackage.jbws.MyBean();
> mbws.setFirstName(mb.getFirstName());
> mbws.setLastName(mb.getLastName());
> return mbws;
> }
>
> }
>
> So, I don't think I have understood the solution to this problem (the
> problem of populating the template in the auto-generated
> SoapBindingImpl class) correctly.
>
> Can someone provide me with a correct solution?
>
> E. CONCLUSION
>
> My goal out of this would be able to write clear, repeatable
> documentation that explains how to start from a simple bean and a
> utility class that passes in or returns said bean and succesfully
> generates the WSDL, stubs, and skeletons (with modifications to the
> SoapBindingImpl class) to use the bean as a web service.
>
> Thanks for any help anyone can give,
>
> David Gadd
> gaddzeit.com
Clarification about bean mapping
Posted by David Gadd <dg...@mac.com>.
Hi,
I have some questions about using Java Beans in Axis. I'm hoping from
these answers to supplment a "using Axis" article/documentation that
I've been working on. Therefore I'll try and be as clear as possible
with my questions.
A. JAVA BEAN SETUP SCENARIO
B. STANDARD GENERATION OF WSDL/STUBS/SKELETONS
C. DEPLOY.WSDD SETTING QUESTIONS
D. MODIFICATION OF THE '...IMPL' STUB FILE QUESTIONS
E. CONCLUSION
A. JAVA BEAN SETUP SCENARIO
I created two classes within a package called "jbpackage":
JavaBeanBuilder.java
MyBean.java
MyBean.java contains two private varaibles with getters and setters
as below. I've told it to implement Serializable but my understanding
is that Axis doesn't require that as long as it contains getters and
setters. (Correct?)
//MyBean.java
package jbpackage;
import java.io.Serializable;
public class MyBean implements Serializable {
private String firstName;
private String lastName;
public String getFirstName() {return firstName;}
public String getLastName() {return lastName;}
public void setFirstName(String text) {firstName = text;}
public void setLastName(String text) {lastName = text;}
}
JavaBeanBuilder sets String parameters as values in the bean and then
returns the bean:
//JavaBeanBuilder.java
package jbpackage;
public class JavaBeanBuilder {
public MyBean buildBean(String firstName, String lastName) {
MyBean mb = new MyBean();
mb.setFirstName(firstName);
mb.setLastName(lastName);
return mb;
}
}
**********************************
B. STANDARD GENERATION OF WSDL/STUBS/SKELETONS
I do the following steps:
1) compile JavaBeanBuilder and MyBean
2) run Java2WSDL on JavaBeanBuilder to create the WSDL file.
3) run WSDL2Java on the wsdl file to generate the stubs and skeletons
in a SUBPACKAGE to jbpackage called "jbws". This is important further
down as duplicately-named classes are generated which are only
distinguishable from the originals based on their package path.
4) This results in the following directory hierarchy:
/javabeanbuilder.wsdl
/jbpackage/JavaBeanBuilder.class
/jbpackage/JavaBeanBuilder.java
/jbpackage/MyBean.class
/jbpackage/MyBean.java
/jbpakcage/jbws/JavaBeanBuilder.java
/jbpakcage/jbws/JavaBeanBuilderService.java
/jbpakcage/jbws/JavaBeanBuilderServiceLocator.java
/jbpakcage/jbws/JavabeanbuilderSoapBindingImpl.java
/jbpakcage/jbws/JavabeanbuilderSoapBindingStub.java
/jbpakcage/jbws/MyBean.java
/jbpakcage/jbws/deploy.wsdd
/jbpakcage/jbws/undeploy.wsdd
**********************************
C. DEPLOY.WSDD SETTING QUESTIONS
The deploy.wsdd file that has been auto-generated by the WSDL2Java
utility uses DIFFERENT syntax than that recommended in the user guide:
1) The auto-generated deploy.wsdd refers to the bean within the
service as a 'typeMapping' element:
<service name="javabeanbuilder" provider="java:RPC">
<parameter name="className"
value="jbpackage.jbws.JavabeanbuilderSoapBindingImpl"/>
<operation name="buildBean" returnQName="return" >
<parameter name="in0" type="tns:string"
xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"/>
<parameter name="in1" type="tns:string"
xmlns:tns="http://schemas.xmlsoap.org/soap/encoding/"/>
</operation>
<parameter name="allowedMethods" value="buildBean"/>
<parameter name="scope" value="Session"/>
<typeMapping
xmlns:ns="urn:javabeanbuilder"
qname="ns:MyBean"
type="java:jbpackage.jbws.MyBean"
serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
/>
</service>
2) But the supplied user guide html document recommends the user of a
'beanMapping' element which includes an extra attribute called
'languageSpecificType' and LEAVES OUT the references to the
serializer and deserializer attributes:
<beanMapping qname="ns:local" xmlns:ns="someNamespace"
languageSpecificType="java:my.java.thingy"/>
So, my first question is: once the WSDL2Java utility has
auto-generated the deploy.wsdd file for a web service containing a
bean, WHAT, IF ANY modifications should be manually made to the
deploy.wsdd file? Are both solutions above "correct", but variations
on approach. If true, which of the two is prefereable? Why?
**********************************
D. MODIFICATION OF THE '...IMPL' STUB FILE QUESTIONS
Assuming I now have the correct answers for section C above, there is
still the issue of the fleshing out of the template found in
"/jbpakcage/jbws/JavabeanbuilderSoapBindingImpl.java"
With simple classes being implemented as a web service, I would just
import the original class, create an instance of it, and pass a
method call to it. However, in this case, it gets complicated because
there is a second class, the bean involved, and the WSDL2Java utility
creates copies of the bean within the subpackage.
My attempted solution is convoluted, and I don't think it is correct.
I import both the original class and original bean from the original
"jbpackage". I then create a class level variable instance of the
jbpackage.JavaBeanBuilder named "jbb". Then, within the buildBean
method, I pass the 2 String parameters to the "jbb" object's
buildBean method, and assign the return value to a newly create
instance of jbpackage.MyBean named "mb".
I then simply transfer the values from this bean to a new instance of
the jbpackage.jbws.MyBean. While this compiles, I think of it as a
hack, and not resolving the problem.
Have a look:
package jbpackage.jbws;
import jbpackage.JavaBeanBuilder;
import jbpackage.MyBean;
public class JavabeanbuilderSoapBindingImpl implements
jbpackage.jbws.JavaBeanBuilder {
jbpackage.JavaBeanBuilder jbb = new jbpackage.JavaBeanBuilder();
public jbpackage.jbws.MyBean buildBean(java.lang.String in0,
java.lang.String in1)
throws java.rmi.RemoteException {
jbpackage.MyBean mb = jbb.buildBean(in0, in1);
jbpackage.jbws.MyBean mbws = new jbpackage.jbws.MyBean();
mbws.setFirstName(mb.getFirstName());
mbws.setLastName(mb.getLastName());
return mbws;
}
}
So, I don't think I have understood the solution to this problem (the
problem of populating the template in the auto-generated
SoapBindingImpl class) correctly.
Can someone provide me with a correct solution?
E. CONCLUSION
My goal out of this would be able to write clear, repeatable
documentation that explains how to start from a simple bean and a
utility class that passes in or returns said bean and succesfully
generates the WSDL, stubs, and skeletons (with modifications to the
SoapBindingImpl class) to use the bean as a web service.
Thanks for any help anyone can give,
David Gadd
gaddzeit.com
Re: How to enable Remote administor access??
Posted by Jeffrey Hau <jh...@doc.ic.ac.uk>.
On Mon, 17 Jun 2002, David Gadd wrote:
Hi David,
thanks for your help but after setting the 'enableRemoteAdmin' to true,
i still cannot deploy services remotely (i can now run the list
function), any idea why?
Jeff
>Jeff,
>
>from the user guide:
>
>Remote Administration
>Note that by default, the Axis server is configured to only accept
>administration requests from the machine on which it resides - if you
>wish to enable remote administration, you must set the
>"enableRemoteAdmin" property of the AdminService to true. To do this,
>find the "server-config.wsdd" file in your webapp's WEB-INF
>directory. In it, you'll see a deployment for the AdminService. Add
>an option as follows:
>
><service name="AdminService" provider="java:MSG">
> <parameter name="className" value="org.apache.axis.util.Admin"/>
> <parameter name="allowedMethods" value="*"/>
> <parameter name="enableRemoteAdmin" value="true"/>
></service>
>
>WARNING: enabling remote administration may give unauthorized parties
>access to your machine. If you do this, please make sure to add
>security to your configuration!
>
>David
>
>>when i tried to use the Admin class to process a WSDD document, i get
>>the following error
>>
>> AxisFault:Remote Adminstratot access is not allowed.
>>
>>anyone knows how to solve this problem?
>>
>>thanks
>>
>>Jeff
>
>
Re: How to enable Remote administor access??
Posted by David Gadd <dg...@mac.com>.
Jeff,
from the user guide:
Remote Administration
Note that by default, the Axis server is configured to only accept
administration requests from the machine on which it resides - if you
wish to enable remote administration, you must set the
"enableRemoteAdmin" property of the AdminService to true. To do this,
find the "server-config.wsdd" file in your webapp's WEB-INF
directory. In it, you'll see a deployment for the AdminService. Add
an option as follows:
<service name="AdminService" provider="java:MSG">
<parameter name="className" value="org.apache.axis.util.Admin"/>
<parameter name="allowedMethods" value="*"/>
<parameter name="enableRemoteAdmin" value="true"/>
</service>
WARNING: enabling remote administration may give unauthorized parties
access to your machine. If you do this, please make sure to add
security to your configuration!
David
>when i tried to use the Admin class to process a WSDD document, i get
>the following error
>
> AxisFault:Remote Adminstratot access is not allowed.
>
>anyone knows how to solve this problem?
>
>thanks
>
>Jeff