[http] updates

[Stephen McConnell <mc...@apache.org>]

Timothy:

Just a note to let you know that I've made some changes to the http 
stuff.  I've defined a new interface org.apache.avalon.http.Handler (in 
the http/api package) and this basically declares the servlet style 
service operation.  I've updated the holder class to include a Servlet 
adapter class which simply redirects HTTP service requests to the 
component.

Next step is to resolve path to component mapping (currently hardwired 
to the component partition name). I'll be looking at this point point 
later this weekend - current thoughts are that we should:

   (a) update the model listener to look for context components
   (b) get the context component to locate handler components
   (c) have path to component mapping declared under the context
       component configuration

The current model listener should be revamped as a configurable http 
context instance that handles the location of the component to handle an 
incoming request.  Anyway, I've just uploaded the a binary snapshot of 
3.3 to http://dpml.net/merlin/distributions/3.3/snapshots/20040206/ if 
you want to play with it this weekend.

To run the http test all you need to do is:

   merlin block:avalon-http/test

Then look at the content via http://localhost:8080/test/primary

Cheers, Steve.

-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|


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

Re: [http] updates

[Timothy Bennett <ex...@comcast.net>]

Timothy Bennett wrote:

> 
> Next step for facilities in my mind are things like JMS servers, FTP 
> servers, and SMTP servers.  All of these are high on my priority list, 
> as I'm going to need all of these facilities to address requirements of 
> current and future applications built on Avalon technology.

In fact, let me further state that in the same way the merlin assembler 
distinguishes *servlet* components as specialized component, I would 
further propose that this same facility be extended to recognize the 
work that Aaron Farr has done in regard to Message Driven Services. 
IOW, a *special* component recognized in the merlin facilities that 
denotes that this component will *handle* a receipt of a JMS message via 
queue or subscription in the same way (conceptually) that the servlet 
component *handles* the receipt of an HTTP message.

Bottom-line is that we have these *transport* level facilities that need 
to be supported, but equally we need a framework for easily attaching 
handlers (components) to do something with the messages that arrive over 
the various transports.

I also forgot to add web services to the facility list above.



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

Re: [http] updates

[Timothy Bennett <ex...@comcast.net>]

Stephen McConnell wrote:
> 
> Timothy:
> 
> Just a note to let you know that I've made some changes to the http 
> stuff.  I've defined a new interface org.apache.avalon.http.Handler (in 
> the http/api package) and this basically declares the servlet style 
> service operation.  I've updated the holder class to include a Servlet 
> adapter class which simply redirects HTTP service requests to the 
> component.
> 

This is great news, Steve.  I did mess around with the http updates you 
did last weekend and earlier this week.  Truly great stuff.  It's on its 
way to be something really exciting.  Servlet-as-Avalon-component 
promises to be really nice step in streamlining and stabilizing almost 
all of the real server applications I use Avalon technology for.

> Next step is to resolve path to component mapping (currently hardwired 
> to the component partition name). I'll be looking at this point point 
> later this weekend - current thoughts are that we should:
> 
>   (a) update the model listener to look for context components
>   (b) get the context component to locate handler components
>   (c) have path to component mapping declared under the context
>       component configuration
> 
> The current model listener should be revamped as a configurable http 
> context instance that handles the location of the component to handle an 
> incoming request.

This is similar to a *responder management* block that I built for use 
with the old Jetty-Phoenix block (re-factored and re-branded as 
avalon-http in the merlin source).  This is an important step in tying 
the web server to the routing of inbound HTTP requests to a servlet 
component for handling.

Some more things that I want to add on the plate to enhance the Jetty 
web server facility are:

(1) Support for deployment of web applications
(2) Support for the loading of custom user-specific Jetty listeners 
(such as the HTTPS listener I've built on top of a commercial SSL toolkit)
(3) Support for the dynamic starting/stopping of Jetty listeners (i.e. 
so that I can make my web server stop responding to HTTP requests 
without shutting down merlin)
(2) Exposure of more of Jetty's web server configuration, including but 
not limited to:
    (a) security realms and basic authentication
    (b) Jetty's server monitoring instrumentation and reporting hooks
    (c) various configurable params like socket/response timeout, etc.

This is just for starters :)

> Anyway, I've just uploaded the a binary snapshot of 
> 3.3 to http://dpml.net/merlin/distributions/3.3/snapshots/20040206/ if 
> you want to play with it this weekend.
> 
> To run the http test all you need to do is:
> 
>   merlin block:avalon-http/test
> 
> Then look at the content via http://localhost:8080/test/primary
> 

Good work so far, I look forward to peeking at these changes, and 
helping make the above action items a reality.

One further note about the notion of merlin kernel-side facilities, of 
which this web server is an example of.  I don't know if this particular 
idea of mine makes sense to the larger merlin community, but I think 
merlin facilities are a legitimate place to allow kernel plug-ins for 
other server-esque functionality.

I've recently ported Paul Hammett's old Phoenix HSQL server component to 
not only run under merlin AND use the latest HSQL 1.7.x version, but 
I've built database connection pooling into the component itself, and 
exported a getConnection() service out of the block.  To me, this 
represents the power of composite component blocks.  Now, I've got some 
clean-up to do on this code before I release it to the general world for 
consumption, but the point is that IMO this is another candidate for a 
facility in merlin.  How often does one find themselves needing an 
embedded database for their merlin-hosted applications?  For me, almost 
always (same with web server).

Next step for facilities in my mind are things like JMS servers, FTP 
servers, and SMTP servers.  All of these are high on my priority list, 
as I'm going to need all of these facilities to address requirements of 
current and future applications built on Avalon technology.



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