axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Dean" <>
Subject RE: [AXIS2] Admin Tools
Date Thu, 11 Aug 2005 23:21:06 GMT
Thanks for the update.
1) Works good.  When doing the code generation on the server, is it appropriate to create
a scratch area somewhere underneath the axis2 web app for creating the intermediate web service
artifacts.  I know that WEB-INF/services is not the place since you monitor this area for
hot-deployment/updates.  I guess I could just use some configurable area outside the container's
space altogether.  That's probably more appropriate.
2) I figured out how to programatically perform hot-deployment by looking at the RepositoryListenerImpl
class.  But, why should I do it if the scheduler will call the listener on a timely manner
to do this automatically by monitoring the WEB-INF/services folder?  Are there any benificial
reasons to do it programatically?  How often is the refresh done automatically?  I didn't
see that this refresh time was configurable.


From: Ajith Ranabahu [] 
Sent: Thursday, August 11, 2005 12:34 AM
Subject: Re: [AXIS2] Admin Tools

Hi Tony,
To me it seems that you need to run the code generator on the fly, compile the code and then
host a service.(all within some code)
Here are some hints that you'll find useful.
1. Code generator can be easily invoked programmatically. See the in the
wsdl module for an example.
2. Once the classes are available, you can host the service programmatically (by invoking
the deployment) or for an easier solution generate a service archive and copy it to the repositiry

We still don't have anything resembling jws yet.

Hmmm... Seems to me that XMLBeans finds something confusing in the schema part. I will check,
thanks for pointing out the problem

On 8/11/05, Tony Dean <> wrote: 

	I'm trying to prototype a couple of things with the axis2 engine to see how it works (I down
loaded 0.9).  In particular, I want to start with a wsdl and generate the necessary artifacts.
 I'd like to do this from a web service (e.g. use a web service to generate other web services).
 I can generate the wsdl on the fly.  Can I then use your org.apache.axis2.deployment classes
to generate the artifacts and then hot deploy them in the current engine on the server?  Are
the admin classes ready to be poked?  I didn't see any samples and the javadoc is sparse in
this area.  Do you still have the notion of jws file in axis2?  I didn't know if that was
still an alternative to generating the wsdl.
	I also want to include attachments in my generated web services.  I took the doc-lit SwA
sample from WS-I BP Attachment document and tried to use wsdl2java to create the service deployment
code and I'm getting the following error:
	Exception in thread "main" java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
error: cvc-complex-type.2.4a: Expected elements 'annotation@
simpleType@http:// complexType@ group@
attributeGroup@ element@ a
	ttribute@ notation@' instead
of 'complexType' here in element schema@
	        at org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(
	        at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(
	        at org.apache.axis2.wsdl.WSDL2Code.main(
	        at org.apache.axis2.wsdl.WSDL2Java.main( :22)
	Caused by: org.apache.xmlbeans.XmlException: error: cvc-complex-type.2.4a: Expected elements
'annotation@ simpleType@ complexType@http:/
	/ group@ attributeGroup@
element@ attribute@ no
	tation@' instead of 'complexType' here in element schema@
	        at org.apache.xmlbeans.impl.schema.SchemaTypeSystemCompiler.compile(
	        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	        at sun.reflect.NativeMethodAccessorImpl.invoke (
	        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	        at java.lang.reflect.Method.invoke(
	        at org.apache.xmlbeans.XmlBeans.compileXmlBeans( :641)
	        at org.apache.axis2.wsdl.codegen.extension.XMLBeansExtension.engage(
	        ... 3 more
	It seems to not like attachment types of "base64Binary".  Are you aware of this problem?
	Here's the wsdl from the WS-I page:
	<?xml version="1.0" encoding="utf-8" ?>
	<wsdl:definitions xmlns:types=" "
	                  xmlns:xsd=" <>
	                  xmlns:wsdl=" <>
	                  targetNamespace=" <>
	        <xsd:schema targetNamespace=""
	            <xsd:import namespace="" />
	            <xsd:element name="ClaimDetail" type="types:ClaimDetailType"/>
	            <xsd:complexType name="ClaimDetailType">
	                    <xsd:element name="Name" type="xsd:string"/>
	                    <xsd:element name="ClaimForm" type="ref:swaRef"/>
	            <xsd:element name="ClaimRefNo" type="xsd:string"/> 
	    <wsdl:message name="ClaimIn">
	        <wsdl:part name="body" element="types:ClaimDetail"/>
	        <wsdl:part name="ClaimPhoto" type="xsd:base64Binary"/> 
	    <wsdl:message name="ClaimOut">
	        <wsdl:part name="out" element="types:ClaimRefNo"/>
	    <wsdl:portType name="ClaimPortType"> 
	        <wsdl:operation name="SendClaim">
	            <wsdl:input message="tns:ClaimIn"/>
	            <wsdl:output message="tns:ClaimOut"/>
	    <wsdl:binding name="ClaimBinding" type="tns:ClaimPortType">
	        <soapbind:binding style="document"
	        <wsdl:operation name="SendClaim">
	            <soapbind:operation soapAction=""/>
	                        <soapbind:body parts="body" use="literal"/>
	                        <mime:content part="ClaimPhoto" type="image/jpeg"/>
	                <soapbind:body use="literal" />
	Thank you for your efforts.
	Tony Dean
	SAS Institute Inc. 
	SAS... The Power to Know

Ajith Ranabahu 

View raw message