geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: WebContainers and WebConnectors
Date Sun, 10 Aug 2003 00:52:39 GMT


Jules Gosnell wrote:
> Greg Wilkins wrote:

>>    I don't expect the webconnector service to actually implement the
>>    connector - as JMX is not really the right sort of bus to push HTTP
>>    requests/responses over.  Instead I see the webconnectors pushing 
>> their
>>    configuration at the webcontainer - which will create the actual 
>> connector. 
> 
> 
> why not have the webconnector handshake with the webcontainer e.g. 
> through JMX then JNDI, to get hold of an object ref, then implement the 
> webconnector and hook directly to the webcontainer ? Since there is an 
> explicit dep between 'nector and 'tainer, if the 'tainers ref is 
> invalidated through reloading/deployment, the 'nectors will also be 
> reloaded/deployed around the 'tainer, rehandshaking and gettting a new, 
> valid object ref...
> 
> I don't like the idea of an empty 'nector, just there as a placeholder...

Well it is not empty.  It is the lifecycle and configuration manager
for a web connector.  It just so happens that this web connectors
is implemented on the other side of a JMX interface.

We could do some JMX,JNDI,whatever process and get a direct reference
to the container object and then call it directly - but I think
that circumvents the nature of the JMX bus and also pretty much
amounts to the same thing (that container and connector are implemented
as a single graph of real java objects).

But as I said to Aaron - it really is an implementation detail
where exactly the connector is implemented.  If the gezza bus developed
to the stage that HTTP requests & responses could be passed over
it - then the implementation could be changed with very little
user changes.

The important thing is to establish the webconnector lifecycle and
configuration as a geronimo managed service (rather than as
webcontainer specific detail).


>>    be terminated without due process.   This could be extended to work
>>    for sessions - ie a stopped connector would continue working for known
>>    sessions, but would reject requests without sessions (for gentle
>>    node in cluster shutdown - may not be required with mod_jk2?). 
> 
> 
> we need to decide whether this sort of fnality is a responsiblity of the 
> 'nector or lb - whichever it  is, they should be closely coupled. I have 
> a plan, but that comes under clustering, which I have not opened up on 
> yet to preserve bandwidth. But, I think I have the utimate resolution 
> for a self-partitioning, replication strategy for the 'tainer, with 
> fully integrated mod_jk[2]. The lb would be completely configured by the 
> cluster and would need no manual configuration. That's another story 
> that I can digress into if anyone is interested.

all ears....

Do you think session manager makes sense as a top level geronimo
service.

> gezza :-)
> 
> You're not trying to sneak in a bit of your own nomenclature there are 
> you ?

gerry, gezza, the g-man - ya got to be on friendly terms with your
projects!

>> I hope the get a skeleton of all this going in the next week or two.
> 
> 
> 
> I look forward to seeing it - does that mean I am excused and can put my 
> energies elsewhere ?

Well I did only say skeleton....  But thinking about externalizing
the sessions and clustering into geronimo services would be good.

cheers


-- 
Greg Wilkins<gregw@mortbay.com>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.          http://www.mortbay.com


Mime
View raw message