geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: [EWS] Geronimo - EWS Deployment Team
Date Thu, 05 Feb 2004 16:35:09 GMT wrote:

> So we are in charge of the generation of Service's impl's code. And thinking
> about it it's right, this is a provider specific task.
> Thanks
> Luis Avila
> PD: what do you think about the idea to do a deployment planner in charge
> of do the ws-deployment?
>>-- Original Message --
>>Date: Thu, 5 Feb 2004 05:35:26 -0800 (PST)
>>From: Davanum Srinivas <>
>>Subject: Re: [EWS] Geronimo - EWS  Deployment Team
>>Let us step back a bit. There are two stages
>>Stage #1: Design/Coding Phase
>>Stage #2: Runtime
>>In stage #1, the web services developer will use the tools (the ones in
>>repository NOW) to
>>generate JSR 109 compliant artifacts like (All these items are packed into
>>the EAR):
>>- webservices.xml
>>- jaxrpcmapping.xml
>>- implementation of handlers
>>- implementation of server-side code
>>Note that the developer may choose to use a tool from a different vendor
>>to generate the EAR with
>>the exact same stuff. Ias and Srinath are working on tools for generating
>>the stuff for stage #1.
>>In stage #2, This is where you jump in, you will need to extract information
>>from the EAR and use
>>those information to hook up Geronimo and Axis. 
>>TIP: If you look at org.apache.axis.deployment.wsdd package in Axis, you
>>will see how Axis
>>currently uses information present in WSDD files to deploy the service.

You should also look in Geronimo's deployment module to see how its 
JSR88 provider is working. You should be able to perform Geronimo/Axis 
specific configuration using DDBean/DConfigBean operations. Given the 
incorporation of web-services into all the module types, it might be 
worth having a general purpose set of DConfigBeans available that any 
module deployer can use.

JSR88 does not provide you with a mechanism for modifying the EAR's 
content (or that of any other module) - everything you need should be 
incorporated in the deployment plan that gets written out by the 
DConfigBeans. There is one plan for each root module, so you will need a 
method for nesting per-module definitions inside the plan for an EAR.

>>TIP: If you look at EJBProvider in Axis, you will see how EJB's are currently
>>invoked from Axis

I had a look at that previously and it seemed to be invoking using the 
remote interface. I don't think this works in a compliant application. 
EJB2.1 has different container semantics for remote- and service- 
invocations and you will need to inject information into the call for it 
to to this.

You should hook up with David Blevins about hooking into the proxy 
system for EJB's. A way to do this would be by providing a hook on the 
EJB deployer that allows it to return a web-service specific proxy to you.


View raw message