Berin,
Ahh but only the interface (service) is extended, the impl (block) would not be.The service interface (which the block implements) is empty of methods, but there is plenty of scope for adding features to satisfy dependancy freaks. For instance one method that could be specified is :
void addServlet(String urlPat, Servlet servlet);
I'll book it into some CVS somewhere (other than Apache) soon as it looks like it's licensed with a BSD-like license. It could be useful until we have multiple HTTP servers being Avalon capable. That raises an impotant issue..... some modelling is due :
interface AvalonSocketServer extends Service {...} interface HTTPServer extends AvalonSocketServer {...} interface ServletHTTPServer extends HTTPServer {...} interface WARFileHTTPServer extends ServletHTTPServer {...} interface FtpServer extends AvalonSocketServer {...} interface DnsServer extends AvalonSocketServer {...} interface QotdServer extends AvalonSocketServer {...}
Arguably premature or unecessary.
I don't think that is all necessary. Maybe I need to double-check the use of socket serving isn't by extension, but I think that is a bad idea. The concept of a service is muddied when you _extend_ a service instead of _use_ it.
The way it should work is that the SocketServer receives the socket, and delegates it to the Block that is responsible:
80 -> HTTPServer (w/o TLS) 443 -> HTTPServer (w/TLS) 21 -> FTPServer 22 -> FTPServer 25 -> JAMES
yes, agree.
etc.
The HTTPServer would register the callback method to handle the ServerSockets. It should delegate the requests as it sees fit--with WAR mounting, Servlet routing, default FileServlet, and cacheing. Hopefully, you get the overall picture here.
But I am only on about modelling.
Think about our (one day) EJB server. It needs a webserver. Not just that it needs a WAR file capable web server.
<block name="fred-ejb" ..... <depends role="org.apache.avalon.services.WARFileHTTPServer"/> </block>
It should not matter whether the assembler uses Tomcat or Jetty, it should just work. To pad out WARFileHTTPServer a bit more it should have :
void deployWAR(String key, File warFile) throws WARDeploymentException;
void deployWAR(String key, URL warFile) throws WARDeploymentException;
void deployWAR(String key, InputStream warFile) throws WARDeploymentException ;
void deployWAR(String key, ClassLoader warFile) throws WARDeploymentException;
void unDeployWAR(String key) ..;
Protocol handlers should be ServerSocket handler, and do all the handshaking required.
yup. Berin - see my /clarified/ point :-)
- Paul
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
