Hello Johan and All!
I)
J> You can also choose to make your Avalon Container available thru JNDI.
Maybe we could look at how this is done by BasicDataSourceFactory
in DBCP? It looks like this code is readily pluggable both into
Tomcat and probably to many other Web/EJB servers.
This would probably(?) be cleaner then hooking a container in via
* servlet
* app listener
* filter
* staic factory method
II)
On the other hand I must confess that I like the filter variant
very much too. It
1) goes inline with SOC
we explicitly provide servlet with a container to fetch
service from
2) allowes us to provide servlets with container selectively
III)
However all goes well while we're Fortress/ECM style - that
is we can get anything from the universal container ServiceManager.
The cleanest application of Avalon to handling web requests
would probably allow the entities that actually service requests
(some avalon components maybe) to lookup only those components
from avalon container that they are allowed to.
That is it would be better to _have_ assembly.
And here I see the following options:
III.a) have only a single servlet, make it host
an avalon container and make all the handling
by avalon components living in this container
essentially this is bypassing all servlet spec
mechanisms for mapping requests to servlets
and re-implementing them on our own in the
avalon space
the typo.zip posted with one of my mails
is a work in progress of that kind
(not sure if it will reach production or not)
III.b) create our own Avalon+HTTP beast
in the lines of our discussion here, under
this topic with Ulrich:
UM> Yeah, obviously the servlet spec contains a lot of things that we don't
UM> need (JSP, deployment options...), but ServletRequest and
UM> ServletResponse support would be nice.
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
