You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2001/09/09 20:45:34 UTC
HTTP Server for Pheonix
Folks,
I have ported the "Acme Serve" HTTP server (see
http://www.acme.com/java/) to be a phoenix application. I think
development stopped on this in 1996. It has a couple of custom
servlets, but basically is a decent filesystem exposing web server. It
used to be mainable, but now it uses Avalon's configuration as per usual.
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.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: HTTP Server for Pheonix
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>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) ..;
>>
>
>Sounds good except I wouldn't make the interface extend anything.
>
Not extend "Service"? OK...
>I guess the
>problem is that without a real-life test-case I don't think we are going to
>have an easy time defining a generic interface. For instance the in-JVM EJB
>container has a fairly incestuos relationship with servlet container and they
>have to share all sorts of resources (ie ClassLoader hierarchy is very
>specific as in shared JVM resources etc).
>
Incestuous - yes agree. Weblogic does all sorts of sharing beatween
beans and webserver. It shortcircuits (by default) RMI internally.
However, the plain contract with the webserver is one where the WAR
file is self contained and does use true RMI to interoperate with the
beans server. Perhaps that resource sharing version is one extension more :
interface ServletHTTPServer extends HTTPServer {...}
interface WARFileHTTPServer extends ServletHTTPServer {...}
interface ResourceSharingWARFileHTTPServer extends WARFileHTTPServer {...}
>It may be a good idea to have a bash at it but I would mark it as possibly
>changing in future or highly volatile or whatever - at least until we see
>some reali-life testing. Thoughts?
>
Yes agree. Refactor when necessary and based on merit.
This, if we do it, pushes down the road of a) standardized APIs for
/regular/ server components. Why? well, it a true multi service Avalon
machine we'd not have the http server as a block in a sar that also
conatined the ejb server ..... multiple other sars might need it (http
server) being accessible too. Can you remember all that deep thinking
we did with Fede about "promotion of interfaces" at Xmas (refer Fred &
Wilma demo classloaders), well all that's unecessary if you have a
centralized place for interfaces (for regular comps).
So in summary, in the assembly.xml, a block could depend on another
service that was outside of it's own sar file. I think that's the major
change here. That we're specifying regular services in Avalon
(irrespective of implementation) is incidental.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: HTTP Server for Pheonix
Posted by Peter Donald <do...@apache.org>.
On Tue, 11 Sep 2001 05:57, Paul Hammant wrote:
> >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) ..;
Sounds good except I wouldn't make the interface extend anything. I guess the
problem is that without a real-life test-case I don't think we are going to
have an easy time defining a generic interface. For instance the in-JVM EJB
container has a fairly incestuos relationship with servlet container and they
have to share all sorts of resources (ie ClassLoader hierarchy is very
specific as in shared JVM resources etc).
It may be a good idea to have a bash at it but I would mark it as possibly
changing in future or highly volatile or whatever - at least until we see
some reali-life testing. Thoughts?
--
Cheers,
Pete
--------------------------------------------------------------
"Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it" -- Richard Feynman
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: HTTP Server for Pheonix
Posted by Paul Hammant <Pa...@yahoo.com>.
Berin,
>>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.
>
Ahh but only the interface (service) is extended, the impl (block) would
not be.
>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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: HTTP Server for Pheonix
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
>
> Folks,
>
> I have ported the "Acme Serve" HTTP server (see
> http://www.acme.com/java/) to be a phoenix application. I think
> development stopped on this in 1996. It has a couple of custom
> servlets, but basically is a decent filesystem exposing web server. It
> used to be mainable, but now it uses Avalon's configuration as per usual.
Sounds good.
> 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
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.
Protocol handlers should be ServerSocket handler, and do all the handshaking required.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org