You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hivemind.apache.org by Andreas Winter <an...@gmx.org> on 2004/04/22 07:09:11 UTC
Service models
Hi,
as far as I understand, HiveMind supports two service models, one based on
the singleton pattern (one service per classloader), and one based on the
current thread (one service per thread).
I would suggest an extension of this model, where these two are special
cases:
Simple allow to get service from the registry based on a client-provided
object, ie. add a API like
getService(Object ref, String servicePoint, Class serviceClass)
to the registry.
I came around with this, when I tried to get a separate service for each
HTTPSession in a web application, which seems impossible with the current
models.
Maybe it is also useful to provide a special API to provide configuration
contributions programmatically.
Just some proposals
Andreas
This means
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Service models
Posted by Andreas Winter <an...@gmx.org>.
If you manage the state externally, you can even use a singleton service
(unless the service provides non-concurrent access to a resource).
I will scan the archives and try to make a proposal on the wiki.
- Andreas
Harish Krishnaswamy wrote:
> Ofcourse! The only way to use it right now is to keep the state in the
> session and the behavior in services! Search the mailing list archives
> (I think it'll be in jakarta commons dev archives) for the ideas that
> Geoff came up with.
>
> -Harish
>
> Andreas Winter wrote:
>
>> I think, this doesn't work. The service is associated with the thread.
>> The
>> same thread could start a different session when the next request
>> comes in, which would result in sharing the service between my session
>> and the newly
>> created. Even using the HiveMindFilter wouldn't help since it releases
>> the service to the pool as soon as the request finishs. I think, as
>> soon as I
>> have learned to work with the Wiki ;-), I start a discussion or design
>> proposal.
>>
>> - Andreas
>>
>>
>>
>>
>>> Yes, Geoff has been playing with this idea a while back. You may want
>>> to start a discussion on the wiki. For now, I suppose you can get the
>>> pooled service and store it in the session yourself?
>>>
>>> -Harish
>>>
>>> Andreas Winter wrote:
>>>
>>>
>>>
>>>> Not really, the "pooled" service model is a variant of the thread
>>>> service
>>>> model. Pooling is a concept which could be used with every service
>>>> model,
>>>> although it doesn't make much sense in the case of a singleton based
>>>> service.
>>>>
>>>> - Andreas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> There is also a "pooled" service model which is what you want.
>>>>>
>>>>> -Harish
>>>>>
>>>>> Andreas Winter wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> as far as I understand, HiveMind supports two service models, one
>>>>>> based
>>>>>>
>>>>>>
>>>>>
>>>>> on
>>>>>
>>>>>
>>>>>
>>>>>> the singleton pattern (one service per classloader), and one based on
>>>>>>
>>>
>>> the
>>>
>>>
>>>>>> current thread (one service per thread).
>>>>>>
>>>>>> I would suggest an extension of this model, where these two are
>>>>>> special
>>>>>> cases:
>>>>>>
>>>>>> Simple allow to get service from the registry based on a
>>>>>>
>>>
>>> client-provided
>>>
>>>
>>>>>> object, ie. add a API like
>>>>>>
>>>>>> getService(Object ref, String servicePoint, Class serviceClass)
>>>>>>
>>>>>> to the registry.
>>>>>>
>>>>>> I came around with this, when I tried to get a separate service for
>>>>>>
>>>
>>> each
>>>
>>>
>>>>>> HTTPSession in a web application, which seems impossible with the
>>>>>>
>>>
>>> current
>>>
>>>
>>>>>> models.
>>>>>>
>>>>>> Maybe it is also useful to provide a special API to provide
>>>>>>
>>>
>>> configuration
>>>
>>>
>>>>>> contributions programmatically.
>>>>>>
>>>>>> Just some proposals
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Service models
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Ofcourse! The only way to use it right now is to keep the state in the
session and the behavior in services! Search the mailing list archives
(I think it'll be in jakarta commons dev archives) for the ideas that
Geoff came up with.
-Harish
Andreas Winter wrote:
>I think, this doesn't work. The service is associated with the thread. The
>same thread could start a different session when the next request comes in,
> which would result in sharing the service between my session and the newly
>created. Even using the HiveMindFilter wouldn't help since it releases the
>service to the pool as soon as the request finishs. I think, as soon as I
>have learned to work with the Wiki ;-), I start a discussion or design
>proposal.
>
>- Andreas
>
>
>
>
>>Yes, Geoff has been playing with this idea a while back. You may want to
>>start a discussion on the wiki. For now, I suppose you can get the
>>pooled service and store it in the session yourself?
>>
>>-Harish
>>
>>Andreas Winter wrote:
>>
>>
>>
>>>Not really, the "pooled" service model is a variant of the thread service
>>>model. Pooling is a concept which could be used with every service model,
>>>although it doesn't make much sense in the case of a singleton based
>>>service.
>>>
>>>- Andreas
>>>
>>>
>>>
>>>
>>>
>>>
>>>>There is also a "pooled" service model which is what you want.
>>>>
>>>>-Harish
>>>>
>>>>Andreas Winter wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>as far as I understand, HiveMind supports two service models, one based
>>>>>
>>>>>
>>>>>
>>>>>
>>>>on
>>>>
>>>>
>>>>
>>>>
>>>>>the singleton pattern (one service per classloader), and one based on
>>>>>
>>>>>
>>the
>>
>>
>>>>>current thread (one service per thread).
>>>>>
>>>>>I would suggest an extension of this model, where these two are special
>>>>>cases:
>>>>>
>>>>>Simple allow to get service from the registry based on a
>>>>>
>>>>>
>>client-provided
>>
>>
>>>>>object, ie. add a API like
>>>>>
>>>>>getService(Object ref, String servicePoint, Class serviceClass)
>>>>>
>>>>>to the registry.
>>>>>
>>>>>I came around with this, when I tried to get a separate service for
>>>>>
>>>>>
>>each
>>
>>
>>>>>HTTPSession in a web application, which seems impossible with the
>>>>>
>>>>>
>>current
>>
>>
>>>>>models.
>>>>>
>>>>>Maybe it is also useful to provide a special API to provide
>>>>>
>>>>>
>>configuration
>>
>>
>>>>>contributions programmatically.
>>>>>
>>>>>Just some proposals
>>>>>Andreas
>>>>>
>>>>>
>>>>>
>>>>>This means
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Service models
Posted by Andreas Winter <an...@gmx.org>.
I think, this doesn't work. The service is associated with the thread. The
same thread could start a different session when the next request comes in,
which would result in sharing the service between my session and the newly
created. Even using the HiveMindFilter wouldn't help since it releases the
service to the pool as soon as the request finishs. I think, as soon as I
have learned to work with the Wiki ;-), I start a discussion or design
proposal.
- Andreas
> Yes, Geoff has been playing with this idea a while back. You may want to
> start a discussion on the wiki. For now, I suppose you can get the
> pooled service and store it in the session yourself?
>
> -Harish
>
> Andreas Winter wrote:
>
> >Not really, the "pooled" service model is a variant of the thread service
> >model. Pooling is a concept which could be used with every service model,
> >although it doesn't make much sense in the case of a singleton based
> >service.
> >
> >- Andreas
> >
> >
> >
> >
> >>There is also a "pooled" service model which is what you want.
> >>
> >>-Harish
> >>
> >>Andreas Winter wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>as far as I understand, HiveMind supports two service models, one based
> >>>
> >>>
> >>on
> >>
> >>
> >>>the singleton pattern (one service per classloader), and one based on
> the
> >>>current thread (one service per thread).
> >>>
> >>>I would suggest an extension of this model, where these two are special
> >>>cases:
> >>>
> >>>Simple allow to get service from the registry based on a
> client-provided
> >>>object, ie. add a API like
> >>>
> >>>getService(Object ref, String servicePoint, Class serviceClass)
> >>>
> >>>to the registry.
> >>>
> >>>I came around with this, when I tried to get a separate service for
> each
> >>>HTTPSession in a web application, which seems impossible with the
> current
> >>>models.
> >>>
> >>>Maybe it is also useful to provide a special API to provide
> configuration
> >>>contributions programmatically.
> >>>
> >>>Just some proposals
> >>>Andreas
> >>>
> >>>
> >>>
> >>>This means
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Service models
Posted by Geoff Longman <gl...@intelligentworks.com>.
I got pretty far with the session local stuff I had but I ran out of
available time.
I anyone is interested in I'm willing to pass it along. And, if any of it
looks useful for the hivemind-lib I'm willing to contirbute it.
Its not exactly what's been discussed in this thread but it might help..
Includes an HttpSession servlet filter that puts the request in a pooled
HttpSessionSource service. You can get/create a session by calling a method
on the service.
Also includes an interceptor and related services that will store/retrieve
properties of services to/from the session. Its modeled after the persistent
properties mechanism of Tapestry.
As I recall I had 96% test coverage. I ran out of time before I actually
tried it out in a web application.
Geoff
----- Original Message -----
From: "Harish Krishnaswamy" <hk...@comcast.net>
To: <hi...@jakarta.apache.org>
Sent: Thursday, April 22, 2004 10:01 AM
Subject: Re: Service models
> Yes, Geoff has been playing with this idea a while back. You may want to
> start a discussion on the wiki. For now, I suppose you can get the
> pooled service and store it in the session yourself?
>
> -Harish
>
> Andreas Winter wrote:
>
> >Not really, the "pooled" service model is a variant of the thread service
> >model. Pooling is a concept which could be used with every service model,
> >although it doesn't make much sense in the case of a singleton based
> >service.
> >
> >- Andreas
> >
> >
> >
> >
> >>There is also a "pooled" service model which is what you want.
> >>
> >>-Harish
> >>
> >>Andreas Winter wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>as far as I understand, HiveMind supports two service models, one based
> >>>
> >>>
> >>on
> >>
> >>
> >>>the singleton pattern (one service per classloader), and one based on
the
> >>>current thread (one service per thread).
> >>>
> >>>I would suggest an extension of this model, where these two are special
> >>>cases:
> >>>
> >>>Simple allow to get service from the registry based on a
client-provided
> >>>object, ie. add a API like
> >>>
> >>>getService(Object ref, String servicePoint, Class serviceClass)
> >>>
> >>>to the registry.
> >>>
> >>>I came around with this, when I tried to get a separate service for
each
> >>>HTTPSession in a web application, which seems impossible with the
current
> >>>models.
> >>>
> >>>Maybe it is also useful to provide a special API to provide
configuration
> >>>contributions programmatically.
> >>>
> >>>Just some proposals
> >>>Andreas
> >>>
> >>>
> >>>
> >>>This means
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Service models
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Yes, Geoff has been playing with this idea a while back. You may want to
start a discussion on the wiki. For now, I suppose you can get the
pooled service and store it in the session yourself?
-Harish
Andreas Winter wrote:
>Not really, the "pooled" service model is a variant of the thread service
>model. Pooling is a concept which could be used with every service model,
>although it doesn't make much sense in the case of a singleton based
>service.
>
>- Andreas
>
>
>
>
>>There is also a "pooled" service model which is what you want.
>>
>>-Harish
>>
>>Andreas Winter wrote:
>>
>>
>>
>>>Hi,
>>>
>>>as far as I understand, HiveMind supports two service models, one based
>>>
>>>
>>on
>>
>>
>>>the singleton pattern (one service per classloader), and one based on the
>>>current thread (one service per thread).
>>>
>>>I would suggest an extension of this model, where these two are special
>>>cases:
>>>
>>>Simple allow to get service from the registry based on a client-provided
>>>object, ie. add a API like
>>>
>>>getService(Object ref, String servicePoint, Class serviceClass)
>>>
>>>to the registry.
>>>
>>>I came around with this, when I tried to get a separate service for each
>>>HTTPSession in a web application, which seems impossible with the current
>>>models.
>>>
>>>Maybe it is also useful to provide a special API to provide configuration
>>>contributions programmatically.
>>>
>>>Just some proposals
>>>Andreas
>>>
>>>
>>>
>>>This means
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Service models
Posted by Andreas Winter <an...@gmx.org>.
Not really, the "pooled" service model is a variant of the thread service
model. Pooling is a concept which could be used with every service model,
although it doesn't make much sense in the case of a singleton based
service.
- Andreas
> There is also a "pooled" service model which is what you want.
>
> -Harish
>
> Andreas Winter wrote:
>
> >Hi,
> >
> >as far as I understand, HiveMind supports two service models, one based
> on
> >the singleton pattern (one service per classloader), and one based on the
> >current thread (one service per thread).
> >
> >I would suggest an extension of this model, where these two are special
> >cases:
> >
> >Simple allow to get service from the registry based on a client-provided
> >object, ie. add a API like
> >
> >getService(Object ref, String servicePoint, Class serviceClass)
> >
> >to the registry.
> >
> >I came around with this, when I tried to get a separate service for each
> >HTTPSession in a web application, which seems impossible with the current
> >models.
> >
> >Maybe it is also useful to provide a special API to provide configuration
> >contributions programmatically.
> >
> >Just some proposals
> >Andreas
> >
> >
> >
> >This means
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: Service models
Posted by Harish Krishnaswamy <hk...@comcast.net>.
There is also a "pooled" service model which is what you want.
-Harish
Andreas Winter wrote:
>Hi,
>
>as far as I understand, HiveMind supports two service models, one based on
>the singleton pattern (one service per classloader), and one based on the
>current thread (one service per thread).
>
>I would suggest an extension of this model, where these two are special
>cases:
>
>Simple allow to get service from the registry based on a client-provided
>object, ie. add a API like
>
>getService(Object ref, String servicePoint, Class serviceClass)
>
>to the registry.
>
>I came around with this, when I tried to get a separate service for each
>HTTPSession in a web application, which seems impossible with the current
>models.
>
>Maybe it is also useful to provide a special API to provide configuration
>contributions programmatically.
>
>Just some proposals
>Andreas
>
>
>
>This means
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org