axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jung , Dr. Christoph" <christoph.j...@infor.de>
Subject Axis in theJ2ee environment *was* AW: JNDI support for EJBs
Date Wed, 10 Oct 2001 08:33:48 GMT
Wrt to JNDI:
------------
 
I would vote for simply using new InitialContext() (without fiddling with
the
properties) in EJBProvider since that leaves it to the runtime environment 
(system properties, ejb client container, ejb server container, ...) to
choose the 
right JNDI provider. 

For example, in the Jboss.net prototype, we already deploy EJB-based web
services as 
"java client application modules" (similar to "ejb modules", "connector
modules" and 
"web application modules") included in the .ear´s:

hello.ear:
	- META-INF/application.xml (<module> <java>hello.wsr</java></module>
<module> <ejb>hello.jar</ejb></module>)
	- hello.jar: 
		- META-INF/ejb.jar.xml
		- Bean&Interface bytecode
	- hello.wsr
		- META-INF/web-service.xml (basically an Axis deployment
descriptor with some extensions, see below)
		- special serializer bytecode

The web-service.xml could contain the ubiquitous <ejb-ref/> statements to
link the dedicated java:comp 
naming environment *for that web service module* to the global directory
(this is done by the container automatically)

  <!-- this is an extension to the Axis deployment descriptor which allows
to
       specify the naming environment for the deployed ws logic -->
  <ejb-ref>
	<ejb-ref-name>ejb/Hello</ejb-ref-name>
	<ejb-link>HelloWorld</ejb-link>
  </ejb-ref>
	
  <service name="Hello" pivot="EJBProvider">
   <!-- the final jndi name that this provider sits upon -->
   <option name="beanJndiName" value="java:comp/env/ejb/Hello"/>
   <option name="allowedMethods" value="*"/>
  </service>
 
In our modified version of the EJBProvider, we set the Thread context
classloader before the JNDI lookup and target invocation to the deployment
classloader of the targetted web service  (this has to do with the
service<->deployment classloader association that I was talking about in
several of my previous mailings):

    /**
     * Invoke the message by obtaining various common fields, looking up
     * the service object (via getServiceObject), and actually processing
     * the message (via processMessage).
     */
    public void invoke(MessageContext msgContext) throws AxisFault {
        
        // enter the right deployment-time classloader in order to
        // reinstall the right naming, security, etc. environment
        ClassLoader old=Thread.currentThread().getContextClassLoader();
 
Thread.currentThread().setContextClassLoader(msgContext.getClassLoader().get
Parent());
        
        try{
            super.invoke(msgContext);
        } finally {
            Thread.currentThread().setContextClassLoader(old);
        }
    }

Now, even when you are entering the Axis engine from two different (client)
EJB´s, the web service will operate
in its own environment and dispatch correctly to the target EJB.

Wrt to dependecies of axis.jar to various optional java packages: 
-----------------------------------------------------------------

I would propose that you introduce some "contrib" section for dedicated
serializers, 
providers, etc. that depend on, e.g., jndi.jar, jmxri.jar (I´ve got an
MBeanProvider that I 
could gladly donate there), jta.jar and whatever more. You should not have
to package them,
but just to distribute the source/byte-code seperately from axis.jar.

CGJ


Mime
View raw message