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.
Options --------
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 RemoteException.
Pros : Can tolerate different versions. Good for standards based services as well as bespoke ones.
Cons : Difficult to implement
Thoughts?
- Paul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
