On 3/3/03 10:59 PM Steve Loughran <[EMAIL PROTECTED]> wrote:

> 
> ----- Original Message -----
> From: "Jens Schumann" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, March 03, 2003 13:36
> Subject: Re: Bug 17347 - Provider Lookup Fails within EARs


 
> I havent heard of anyone trying to do >1 engine per webapp; you can always
> multi-webapp if that is needed. We have to cache the engine somewhere, and
> its either a static variable, a JMX registration or a servlet context, and
> since we dont support JMX, servlet contexts are what you get (though I would
> like to also register the engine in JMX).

So you probably talk to the first person;). The framework we are using for
our internal purposes separates the access/rendering technology from the
actual business logic completely. Apart from the typical WEB/WAP
environments we are able to support several SOAP implementations /
configurations in parallel, using the same business logic behind. At the
moment we don't need multiple Axis Instances at the same time, but I believe
we will need it. The problem is that the current AxisBaseServlet prevents
own AxisServlet caching strategies - too many private methods.

> 
> The trouble with servlet contexts is what will we do when we start
> supporting other transports more seriously? we have dependencies on servlets
> deep into Axis, which is mixing layers too closely for my liking

After looking through the sources last week I doubt it will that easy to get
rid of those dependencies;).

The static accessor you suggested is one way to go, and we/I have chosen
this strategy a couple times. It looks like a dirty workaround, but we add
required references depending on the environment. The internal lookup tree
handles everything else.

Maybe we should take a look at the different transport mechanism too. In the
end I believe there will always be a JSP/Servlet container available, apart
from standalone applications. (If I remember correctly Axis makes heavy use
of reflection, which prevents usage inside of EJB. But, I don't know how to
solve certain issues without reflection ;)

Jens

Reply via email to