Re: Axis GBean is deployable?

[Venkat Reddy <vr...@gmail.com>]

David, Thanks for the valuable clarification !

I thought Geronimo will use Axis core for its SOAP stack and EWS code
for JSR-921 support. I'm aware that both need tailoring to fit into
Geronimo architecture. Is there any document or discussion that talks
more about this? I'm interested in contributing in the areas of
integrating Axis and EWS with Geronimo. What's the to-do list for this
area of work? How is the webservices support for Geronimo is being
planned ?

Thanks
Venkat


On Mon, 28 Feb 2005 08:19:47 -0800, David Jencks <da...@yahoo.com> wrote:
> -- Current state of axis integration --
> 
> There are currently 2 sets of code for axis integration, and they may
> look mingled together.  There's Srinath's original work, in the axis
> module in org/apache/geronimo/axis, and there's my work, in
> axis-builder and org/apache/geronimo/axis/client.  I think David
> Blevins is about to commit some server-side code.
> 
> Srinath's original work, including the Axis gbean, doesn't fit into the
> geronimo architecture very well, especially including the separation of
> deployment and runtime phases.  It also appears to have a very
> Axis-centric view of the world that I don't feel is entirely
> appropriate for existence in an application server.  This code has not
> been maintained for several months and is not currently used in
> Geronimo.
> 
> When I started looking into service-references for web services in
> geronimo, it was with fairly good understanding of the geronimo
> architecture, but no knowledge of web services or axis.  I found it
> easiest to "learn by doing" and extend the techniques commonly used in
> geronimo to axis, attempting to use exactly the features we need.   So
> far the results have resulted in a service-ref implementation that
> dispenses with code generation and run-time deployment descriptor
> interpretation.  Instead of code generation I'm using CGlib proxies,
> and instead of the wsdd file I'm directly configuring axis
> configuration objects and serializing them.  Although so far the
> results seem good, we won't know for sure until the server side
> implementation is complete.
> 
> thanks
> david jencks
> 
> 
> On Feb 28, 2005, at 7:26 AM, Venkat Reddy wrote:
> 
> > I tried deploying the modules/axis/src/plans/plan1.xml using the
> > deploy tool and couldn't proceed much even after making some changes
> > to the plan such as changing the gronimo-kernel dep version to
> > 1.0-SNAPSHOT etc.
> >
> >  The latest error i have is -
> > Deployment failed
> >   Server reports: org.apache.geronimo.common.DeploymentException:
> > org.apache.geronimo.gbean.InvalidConfigurationExceptio
> > n: Could not load class
> > org.apache.geronimo.j2ee.deployment.EARConfigBuilder
> > org.apache.geronimo.kernel.InternalKernelException:
> > org.apache.geronimo.common.DeploymentException: org.apache.geronimo.
> > gbean.InvalidConfigurationException: Could not load class
> > org.apache.geronimo.j2ee.deployment.EARConfigBuilder
> >         at
> > org.apache.geronimo.kernel.jmx.KernelDelegate.invoke(KernelDelegate.jav
> > a:232)
> >
> > Any thoughts?
> >
> > Thanks
> > Venkat
> >
> 
>

Re: Axis GBean is deployable?

[Srinath Perera <he...@gmail.com>]

Sorry for the late answer, David Blevins say he will move some ews
code in to the geronimo (I think that is the commit David's mention).
Thanks David for clarification as I too trying to catch up the things 

Venket If you can lend a hand I will also try to help if I can to get
around the things
Thanks
Srinath

On Tue, 1 Mar 2005 12:00:29 -0800, David Jencks <da...@yahoo.com> wrote:
> 
> On Mar 1, 2005, at 4:42 AM, Venkat Reddy wrote:
> 
> > David, Thanks for the valuable clarification !
> >
> > I thought Geronimo will use Axis core for its SOAP stack and EWS code
> > for JSR-921 support.
> 
> When I looked at EWS it looked to me as if it did 2 things:
> 1) code generation of stubs
> 2) partial translation of jaxrpc-mapping file to wsdd xml file. As far
> as I can tell this mapping translation is completely ignoring the
> javabean property to xml element name mapping and the exception
> mapping.
> 
> After examing the generated code it looked to me as if it would be
> easier to use a cglib proxy solution than to compile the generated code
> from EWS.
> One of the basic principles behind geronimo is that we "compile" all
> xml deployment descriptors into binary gbean configurations ready to be
> loaded and started at runtime.  Following this principle, if we were to
> use wsdd, we would have to preprocess it during deployment into the
> actual objects that configure axis, and serialize those.  AFAICT this
> would involve major surgery on the axis deployment system.  I believe
> it is much simpler simply to process the j2ee deployment descriptors
> directly into the appropriate axis configuration objects, entirely
> skipping the wsdd file format.  We've done this, and I don't see
> anything else in EWS that we can use.
> 
> In particular we have some code that, using the XmlBeans schema type
> model, completely analyzes the jaxrpc mapping and attempts to set up
> the correct TypeDesc and exception mapping for axis.  The exception
> mapping in particular is not quite complete for simple types.
> 
> Lets consider our use of Axis.
> 
> We are attempting to set up each service reference and web service
> (POJO or EJB) as an independent entity.  I think this is more or less
> required by the independent lifecycles of j2ee components.  For
> instance, a service reference gets "compiled" during deployment into a
> Service instance that is serialized to be bound into jndi.  This
> serialized object includes all the axis configuration objects needed to
> run the service reference, and some setup code to build the
> non-serializable parts of axis.  In particular it includes the type
> mapping info and the TypeDesc objects.
> 
> The service-reference code is fairly far along and I think deals with
> pretty much everything required.  I'm sure there are plenty of bugs but
> these are not yet too evident without much working on the server side.
> 
> For the server-side, we have some code to dispatch from jetty to POJO
> and EJB web services, and some wiring in place to deploy this properly,
> but the actual code to configure axis is not yet committed: David
> Blevins is IIUC progressing rapidly and we may see something in the
> next few days.  I believe he is following the same path of setting up
> an independent entity for each web service, configured for exactly the
> needs of that web service.
> 
> POJO web services, being part of a web app, get deployed as a gbean
> similar to the servlet gbean.  For jetty, the servlet gbean is
> JettyServletHolder, and we have a JettyAxisPOJOWebService gbean
> subclass that is (or, more accurately, will be) specialized to hold the
> axis ws stack and the actual web service object.  Deployment of a POJO
> ws proceeds from the web app deployer (JettyModuleBuilder) which
> recognizes that a servlet is not a servlet but a POJO ws, copies a
> template of this JettyAxisPOJOWebService gbean, and hands the resulting
> GBeanData to the AxisBuilder together with the relevant info from the
> webservices.xml deployment descriptor.  AxisBuilder is expected to
> configure this GBeanData with whatever is necessary to construct the
> fully functional axis stack when the gbean is started.
> 
> EJB web services are not part of a web app.  Therefore we have an
> adapter, JettyWebServiceHandler, that plugs into jetty and forwards
> calls to the web service to the EJB container.  To jetty, this looks
> like a web app, but the important point is that it gets only calls to
> the specific ejb.  Currently the xfire implementation is hooked up to
> use this, although the architecture there with a ws gbean separate from
> the ejb container gbean is not compatible with the JACC security
> requirements.  To meet the JACC requirements that the security be
> checked before the handler chain is entered, we think we will have to
> install the ws stack inside the EJBContainer, and use a partially
> separate interceptor chain for ws invocations from that for "regular"
> ejb invocations.  In any case I anticipate deployment proceeding by the
> OpenejbModuleBuilder handing the partially configured EJBContainer
> GBeanData to AxisBuilder together with the relevant portions of the
> webservices.xml deployment descriptor: AxisBuilder will add whatever is
> needed to construct the fully functional axis stack when the gbean is
> started.
> 
> I think this architecture will let us support multiple web containers,
> multiple web service stacks, and possibly multiple ejb containers.  We
> can handle multiple web containers by each providing a template gbean
> like JettyAxisPOJOWebService as  "servlet" holder, one for each web
> service implementation, and each providing an ejb invoker similar to
> JettyWebServiceHandler.  We can handle multiple web service
> implementations by each knowing how to configure a POJO "servlet"
> holder gbean and an ejb container gbean.  We might be able to support
> multiple ejb containers through standardization of the invocation
> interface between the JettyWebServiceHandler-like object and the ejb
> container, and through standardization of the interface between the
> ends of the ws stack and the space in the ejb container in which it
> fits.
> 
> 
> >  I'm aware that both need tailoring to fit into
> > Geronimo architecture. Is there any document or discussion that talks
> > more about this? I'm interested in contributing in the areas of
> > integrating Axis and EWS with Geronimo. What's the to-do list for this
> > area of work? How is the webservices support for Geronimo is being
> > planned ?
> 
> Any contribution would be most welcome.  I'd certainly appreciate your
> opinion from the axis side about how much sense this makes.  A code
> review would be very good.    You may spot some large holes we've
> fallen into without noticing :-)
> 
> One relatively minor point that you could probably clear up quickly is
> as follows.  I noticed that the generated EWS code waited until the
> first Call object is constructed to install the type mappings for the
> service. Is this required or would it be possible to install the type
> mappings as soon as the service is deserialized and the appropriate
> internal components created and initialized?  My cglib-based code
> follows this, but could be noticeably simpler if we could set up the
> type mappings sooner.
> 
> Many thanks,
> david jencks
> 
> >
> > Thanks
> > Venkat
> >
> >
> > On Mon, 28 Feb 2005 08:19:47 -0800, David Jencks
> > <da...@yahoo.com> wrote:
> >> <snip>
> 
>

Re: Axis GBean is deployable?

[David Jencks <da...@yahoo.com>]

On Mar 1, 2005, at 4:42 AM, Venkat Reddy wrote:

> David, Thanks for the valuable clarification !
>
> I thought Geronimo will use Axis core for its SOAP stack and EWS code
> for JSR-921 support.

When I looked at EWS it looked to me as if it did 2 things:
1) code generation of stubs
2) partial translation of jaxrpc-mapping file to wsdd xml file. As far 
as I can tell this mapping translation is completely ignoring the 
javabean property to xml element name mapping and the exception 
mapping.

After examing the generated code it looked to me as if it would be 
easier to use a cglib proxy solution than to compile the generated code 
from EWS.
One of the basic principles behind geronimo is that we "compile" all 
xml deployment descriptors into binary gbean configurations ready to be 
loaded and started at runtime.  Following this principle, if we were to 
use wsdd, we would have to preprocess it during deployment into the 
actual objects that configure axis, and serialize those.  AFAICT this 
would involve major surgery on the axis deployment system.  I believe 
it is much simpler simply to process the j2ee deployment descriptors 
directly into the appropriate axis configuration objects, entirely 
skipping the wsdd file format.  We've done this, and I don't see 
anything else in EWS that we can use.

In particular we have some code that, using the XmlBeans schema type 
model, completely analyzes the jaxrpc mapping and attempts to set up 
the correct TypeDesc and exception mapping for axis.  The exception 
mapping in particular is not quite complete for simple types.

Lets consider our use of Axis.

We are attempting to set up each service reference and web service 
(POJO or EJB) as an independent entity.  I think this is more or less 
required by the independent lifecycles of j2ee components.  For 
instance, a service reference gets "compiled" during deployment into a 
Service instance that is serialized to be bound into jndi.  This 
serialized object includes all the axis configuration objects needed to 
run the service reference, and some setup code to build the 
non-serializable parts of axis.  In particular it includes the type 
mapping info and the TypeDesc objects.

The service-reference code is fairly far along and I think deals with 
pretty much everything required.  I'm sure there are plenty of bugs but 
these are not yet too evident without much working on the server side.

For the server-side, we have some code to dispatch from jetty to POJO 
and EJB web services, and some wiring in place to deploy this properly, 
but the actual code to configure axis is not yet committed: David 
Blevins is IIUC progressing rapidly and we may see something in the 
next few days.  I believe he is following the same path of setting up 
an independent entity for each web service, configured for exactly the 
needs of that web service.

POJO web services, being part of a web app, get deployed as a gbean 
similar to the servlet gbean.  For jetty, the servlet gbean is 
JettyServletHolder, and we have a JettyAxisPOJOWebService gbean 
subclass that is (or, more accurately, will be) specialized to hold the 
axis ws stack and the actual web service object.  Deployment of a POJO 
ws proceeds from the web app deployer (JettyModuleBuilder) which 
recognizes that a servlet is not a servlet but a POJO ws, copies a 
template of this JettyAxisPOJOWebService gbean, and hands the resulting 
GBeanData to the AxisBuilder together with the relevant info from the 
webservices.xml deployment descriptor.  AxisBuilder is expected to 
configure this GBeanData with whatever is necessary to construct the 
fully functional axis stack when the gbean is started.

EJB web services are not part of a web app.  Therefore we have an 
adapter, JettyWebServiceHandler, that plugs into jetty and forwards 
calls to the web service to the EJB container.  To jetty, this looks 
like a web app, but the important point is that it gets only calls to 
the specific ejb.  Currently the xfire implementation is hooked up to 
use this, although the architecture there with a ws gbean separate from 
the ejb container gbean is not compatible with the JACC security 
requirements.  To meet the JACC requirements that the security be 
checked before the handler chain is entered, we think we will have to 
install the ws stack inside the EJBContainer, and use a partially 
separate interceptor chain for ws invocations from that for "regular" 
ejb invocations.  In any case I anticipate deployment proceeding by the 
OpenejbModuleBuilder handing the partially configured EJBContainer 
GBeanData to AxisBuilder together with the relevant portions of the 
webservices.xml deployment descriptor: AxisBuilder will add whatever is 
needed to construct the fully functional axis stack when the gbean is 
started.

I think this architecture will let us support multiple web containers, 
multiple web service stacks, and possibly multiple ejb containers.  We 
can handle multiple web containers by each providing a template gbean 
like JettyAxisPOJOWebService as  "servlet" holder, one for each web 
service implementation, and each providing an ejb invoker similar to 
JettyWebServiceHandler.  We can handle multiple web service 
implementations by each knowing how to configure a POJO "servlet" 
holder gbean and an ejb container gbean.  We might be able to support 
multiple ejb containers through standardization of the invocation 
interface between the JettyWebServiceHandler-like object and the ejb 
container, and through standardization of the interface between the 
ends of the ws stack and the space in the ejb container in which it 
fits.




>  I'm aware that both need tailoring to fit into
> Geronimo architecture. Is there any document or discussion that talks
> more about this? I'm interested in contributing in the areas of
> integrating Axis and EWS with Geronimo. What's the to-do list for this
> area of work? How is the webservices support for Geronimo is being
> planned ?

Any contribution would be most welcome.  I'd certainly appreciate your 
opinion from the axis side about how much sense this makes.  A code  
review would be very good.    You may spot some large holes we've 
fallen into without noticing :-)

One relatively minor point that you could probably clear up quickly is 
as follows.  I noticed that the generated EWS code waited until the 
first Call object is constructed to install the type mappings for the 
service. Is this required or would it be possible to install the type 
mappings as soon as the service is deserialized and the appropriate 
internal components created and initialized?  My cglib-based code 
follows this, but could be noticeably simpler if we could set up the 
type mappings sooner.

Many thanks,
david jencks

>
> Thanks
> Venkat
>
>
> On Mon, 28 Feb 2005 08:19:47 -0800, David Jencks 
> <da...@yahoo.com> wrote:
>> <snip>