avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Centrally specified interfaces for Phoenix services
Date Fri, 21 Sep 2001 15:07:57 GMT
Following on from the threads "HTTP Server for Phoenix" (9th, 10th & 11 
Sept) and "Interoperations between blocks from diff classloaders" (3rd & 
4th January), I'd like to re consider a need that's going to crop up on 
us sooner or later:

   Apps in a Phoenix machine might not always be bound to their required 
services (bars within sars), they mught like to depend on a service 
outside the server application.

A good example has been pointed out to me after I wrapped Catalina in a 
phoenix block.  If we publish a addWebApp(String name, URL locn) method 
to the interface, a dependant app (e.g. FtpServer could provide it's own 
servlet to show state), it could not have the "Bay" block as a bar file 
in it's distribution as it would not be the only thing that would want 
to serve a page over HTTP over port 80.  But if the Bay application is 
cental, where would the common interfaces, Sun's servlet stuff in this 
case, reside?  The solution, a hack, was to place servlet.jar at the 
primordial level.

Basically we need to have interfaces available in some central way, 
where the implementation might be in one class loader, and its dependant 
app might/will be in another classloader.  


1) Central definition of interfaces (and exceptions)

    Pros : Simple solution
    Cons : Not version tolerant, though could have heretical version 
numbers in package or class names (ref LayoutManager2).  Only good for 
regular server concepts (HTTPServer) as opposed to bespoke concepts 
(company X's ABC Server)

2) Promotion of interfaces (and exceptions).  SAR file contains a jar of 
interfaces that it implements, it could hand it to the parent component 
(Phoenix) and Phoenix could make them available seperately, not 
necessarily at promordial level.  It's an RMI type concept, but RMI is 
overkill for several reasons, not least of which is the ill-defined 

   Pros : Can tolerate different versions.  Good for standards based 
services as well as bespoke ones.
   Cons : Difficult to implement


- Paul

To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

View raw message