geronimo-dev mailing list archives

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