Re: EagerLoad service doesn't use PerThread service correctly
I would subclass TapestryFilter; override init() to get the service
and store it somewhere (i.e., a static variable somewhere). Override
destroy() to clear out the static variable (to avoid memory leaks).
On Tue, Jul 29, 2008 at 2:39 PM, Franz Amador <[EMAIL PROTECTED]> wrote:
>
> Thanks again. Putting the registry in the ServletContext looks right, but
> I'm not sure it's enough for my use case. I need access to the Hibernate
> session from deep in the bowels of my legacy ORM framework, and the
> ServletContext is not easily accessible from there. I may just be stuck
> with a static.
>
>
> Howard Lewis Ship wrote:
>>
>> I went looking for the best way to do this, and didn't find anything I
>> like. Certainly, avoiding static fields is a step in the right
>> direction.
>>
>> I'm going to quickly implement
>> https://issues.apache.org/jira/browse/TAPESTRY-2540
>>
>> Once you have the Registry, you have the keys to the castle!
>>
>> On Fri, Jul 25, 2008 at 10:21 AM, Franz Amador <[EMAIL PROTECTED]> wrote:
>>>
>>> Thanks, Howard. Splitting my per-thread service into interface and
>>> implementation did the trick.
>>>
>>> My intent, by the way, is to have all threads share the singleton
>>> eager-load
>>> service but for some of that service's behavior to be per-thread,
>>> provided
>>> by the per-thread service. This is an odd arrangement, I admit. Here's
>>> the
>>> problem I'm trying to solve:
>>>
>>> I have a legacy app that uses JSPs and a home-brew ORM framework. I'm
>>> trying to migrate it to use T5 and Hibernate. Until it's completely
>>> converted, both the old and the new parts must coexist. For this to
>>> work,
>>> the legacy ORM must use the same transactions as Hibernate. I'm doing
>>> this
>>> by having the legacy ORM get its connections from Hibernate.
>>>
>>> I'm configuring Hibernate using Tapestry IoC, so how does my legacy ORM
>>> get
>>> access to it? The answer is my eager-load service, whose real name is
>>> T5IocAccess. T5IocAccess has a static "instance" variable that its
>>> constructor sets to point to itself; this allows the legacy part of the
>>> app
>>> to obtain the T5IocAccess instance (via a static "get()" method).
>>> T5IocAccess must be eager-load to ensure that this static variable gets
>>> populated immediately.
>>>
>>> The per-thread service is a Hibernate session manager, which the legacy
>>> ORM
>>> obtains via T5IocAccess.
>>>
>>> This works, but it raises a broader question. What is the best way for
>>> legacy code to gain access to services managed by Tapestry IoC? I
>>> created
>>> my T5IocAccess service, with its static instance variable, because I saw
>>> no
>>> other way.
>>>
>>>
>>> Howard Lewis Ship wrote:
This looks like an issue ... I think EagerLoad is not compatible with
non-singleton scopes.
What does it mean to eager load a service that is, in fact, used in
multiple threads?
Ah, here's the issue; when you bind a class, not an interface, as a
service, it automatically uses singleton scope. Only proxiable
services can have non-singleton scope, and that means an interface and
an implementation. Tapestry should detect this and throw an
exception.
On Thu, Jul 24, 2008 at 11:01 AM, Franz Amador <[EMAIL PROTECTED]>
wrote:
>
> I have an EagerLoad service that uses a PerThread service. I expected
> the
> EagerLoad service to hold a reference to a proxy to the PerThread
> service
> so
> that the actual instance of the PerThread service that is used depends
> upon
> the thread calling the EagerLoad service. Instead, the EagerLoad
> service
> is
> getting a reference to an actual instance of the PerThread service, not
> to a
> proxy, so the same instance of the PerThread service is getting used by
> all
> threads that call the EagerLoad service. This surely can't be right.
> Here's a very simplified example:
>
> public class AppModule {
>public static void bind(ServiceBinder binder) {
>binder.bind(EagerLoadService.class);
>binder.bind(PerThreadService.class);
>}
> }
>
> @EagerLoad
> public class EagerLoadService {
>public EagerLoadService(PerThreadService perThreadService) {
>// prints "class PerThreadService", not a proxy class!
>System.out.println(perThreadService.getClass());
>}
> }
>
> @Scope(PERTHREAD_SCOPE)
> public class PerThreadService {
> }
>
> Is this a bug? Am I confused about how this should work? All help
> appreciated.
>
> --
> View this message in context:
> http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18637337.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscri
Re: EagerLoad service doesn't use PerThread service correctly
Thanks again. Putting the registry in the ServletContext looks right, but
I'm not sure it's enough for my use case. I need access to the Hibernate
session from deep in the bowels of my legacy ORM framework, and the
ServletContext is not easily accessible from there. I may just be stuck
with a static.
Howard Lewis Ship wrote:
>
> I went looking for the best way to do this, and didn't find anything I
> like. Certainly, avoiding static fields is a step in the right
> direction.
>
> I'm going to quickly implement
> https://issues.apache.org/jira/browse/TAPESTRY-2540
>
> Once you have the Registry, you have the keys to the castle!
>
> On Fri, Jul 25, 2008 at 10:21 AM, Franz Amador <[EMAIL PROTECTED]> wrote:
>>
>> Thanks, Howard. Splitting my per-thread service into interface and
>> implementation did the trick.
>>
>> My intent, by the way, is to have all threads share the singleton
>> eager-load
>> service but for some of that service's behavior to be per-thread,
>> provided
>> by the per-thread service. This is an odd arrangement, I admit. Here's
>> the
>> problem I'm trying to solve:
>>
>> I have a legacy app that uses JSPs and a home-brew ORM framework. I'm
>> trying to migrate it to use T5 and Hibernate. Until it's completely
>> converted, both the old and the new parts must coexist. For this to
>> work,
>> the legacy ORM must use the same transactions as Hibernate. I'm doing
>> this
>> by having the legacy ORM get its connections from Hibernate.
>>
>> I'm configuring Hibernate using Tapestry IoC, so how does my legacy ORM
>> get
>> access to it? The answer is my eager-load service, whose real name is
>> T5IocAccess. T5IocAccess has a static "instance" variable that its
>> constructor sets to point to itself; this allows the legacy part of the
>> app
>> to obtain the T5IocAccess instance (via a static "get()" method).
>> T5IocAccess must be eager-load to ensure that this static variable gets
>> populated immediately.
>>
>> The per-thread service is a Hibernate session manager, which the legacy
>> ORM
>> obtains via T5IocAccess.
>>
>> This works, but it raises a broader question. What is the best way for
>> legacy code to gain access to services managed by Tapestry IoC? I
>> created
>> my T5IocAccess service, with its static instance variable, because I saw
>> no
>> other way.
>>
>>
>> Howard Lewis Ship wrote:
>>>
>>> This looks like an issue ... I think EagerLoad is not compatible with
>>> non-singleton scopes.
>>>
>>> What does it mean to eager load a service that is, in fact, used in
>>> multiple threads?
>>>
>>> Ah, here's the issue; when you bind a class, not an interface, as a
>>> service, it automatically uses singleton scope. Only proxiable
>>> services can have non-singleton scope, and that means an interface and
>>> an implementation. Tapestry should detect this and throw an
>>> exception.
>>>
>>> On Thu, Jul 24, 2008 at 11:01 AM, Franz Amador <[EMAIL PROTECTED]>
>>> wrote:
I have an EagerLoad service that uses a PerThread service. I expected
the
EagerLoad service to hold a reference to a proxy to the PerThread
service
so
that the actual instance of the PerThread service that is used depends
upon
the thread calling the EagerLoad service. Instead, the EagerLoad
service
is
getting a reference to an actual instance of the PerThread service, not
to a
proxy, so the same instance of the PerThread service is getting used by
all
threads that call the EagerLoad service. This surely can't be right.
Here's a very simplified example:
public class AppModule {
public static void bind(ServiceBinder binder) {
binder.bind(EagerLoadService.class);
binder.bind(PerThreadService.class);
}
}
@EagerLoad
public class EagerLoadService {
public EagerLoadService(PerThreadService perThreadService) {
// prints "class PerThreadService", not a proxy class!
System.out.println(perThreadService.getClass());
}
}
@Scope(PERTHREAD_SCOPE)
public class PerThreadService {
}
Is this a bug? Am I confused about how this should work? All help
appreciated.
--
View this message in context:
http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18637337.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>> --
>>> Howard M. Lewis Ship
>>>
>>> Creator Apache Tapestry and Apache HiveMind
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>> --
>> View this mes
Re: EagerLoad service doesn't use PerThread service correctly
I went looking for the best way to do this, and didn't find anything I
like. Certainly, avoiding static fields is a step in the right
direction.
I'm going to quickly implement
https://issues.apache.org/jira/browse/TAPESTRY-2540
Once you have the Registry, you have the keys to the castle!
On Fri, Jul 25, 2008 at 10:21 AM, Franz Amador <[EMAIL PROTECTED]> wrote:
>
> Thanks, Howard. Splitting my per-thread service into interface and
> implementation did the trick.
>
> My intent, by the way, is to have all threads share the singleton eager-load
> service but for some of that service's behavior to be per-thread, provided
> by the per-thread service. This is an odd arrangement, I admit. Here's the
> problem I'm trying to solve:
>
> I have a legacy app that uses JSPs and a home-brew ORM framework. I'm
> trying to migrate it to use T5 and Hibernate. Until it's completely
> converted, both the old and the new parts must coexist. For this to work,
> the legacy ORM must use the same transactions as Hibernate. I'm doing this
> by having the legacy ORM get its connections from Hibernate.
>
> I'm configuring Hibernate using Tapestry IoC, so how does my legacy ORM get
> access to it? The answer is my eager-load service, whose real name is
> T5IocAccess. T5IocAccess has a static "instance" variable that its
> constructor sets to point to itself; this allows the legacy part of the app
> to obtain the T5IocAccess instance (via a static "get()" method).
> T5IocAccess must be eager-load to ensure that this static variable gets
> populated immediately.
>
> The per-thread service is a Hibernate session manager, which the legacy ORM
> obtains via T5IocAccess.
>
> This works, but it raises a broader question. What is the best way for
> legacy code to gain access to services managed by Tapestry IoC? I created
> my T5IocAccess service, with its static instance variable, because I saw no
> other way.
>
>
> Howard Lewis Ship wrote:
>>
>> This looks like an issue ... I think EagerLoad is not compatible with
>> non-singleton scopes.
>>
>> What does it mean to eager load a service that is, in fact, used in
>> multiple threads?
>>
>> Ah, here's the issue; when you bind a class, not an interface, as a
>> service, it automatically uses singleton scope. Only proxiable
>> services can have non-singleton scope, and that means an interface and
>> an implementation. Tapestry should detect this and throw an
>> exception.
>>
>> On Thu, Jul 24, 2008 at 11:01 AM, Franz Amador <[EMAIL PROTECTED]> wrote:
>>>
>>> I have an EagerLoad service that uses a PerThread service. I expected
>>> the
>>> EagerLoad service to hold a reference to a proxy to the PerThread service
>>> so
>>> that the actual instance of the PerThread service that is used depends
>>> upon
>>> the thread calling the EagerLoad service. Instead, the EagerLoad service
>>> is
>>> getting a reference to an actual instance of the PerThread service, not
>>> to a
>>> proxy, so the same instance of the PerThread service is getting used by
>>> all
>>> threads that call the EagerLoad service. This surely can't be right.
>>> Here's a very simplified example:
>>>
>>> public class AppModule {
>>>public static void bind(ServiceBinder binder) {
>>>binder.bind(EagerLoadService.class);
>>>binder.bind(PerThreadService.class);
>>>}
>>> }
>>>
>>> @EagerLoad
>>> public class EagerLoadService {
>>>public EagerLoadService(PerThreadService perThreadService) {
>>>// prints "class PerThreadService", not a proxy class!
>>>System.out.println(perThreadService.getClass());
>>>}
>>> }
>>>
>>> @Scope(PERTHREAD_SCOPE)
>>> public class PerThreadService {
>>> }
>>>
>>> Is this a bug? Am I confused about how this should work? All help
>>> appreciated.
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18637337.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator Apache Tapestry and Apache HiveMind
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18656018.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---
Re: EagerLoad service doesn't use PerThread service correctly
Thanks, Howard. Splitting my per-thread service into interface and
implementation did the trick.
My intent, by the way, is to have all threads share the singleton eager-load
service but for some of that service's behavior to be per-thread, provided
by the per-thread service. This is an odd arrangement, I admit. Here's the
problem I'm trying to solve:
I have a legacy app that uses JSPs and a home-brew ORM framework. I'm
trying to migrate it to use T5 and Hibernate. Until it's completely
converted, both the old and the new parts must coexist. For this to work,
the legacy ORM must use the same transactions as Hibernate. I'm doing this
by having the legacy ORM get its connections from Hibernate.
I'm configuring Hibernate using Tapestry IoC, so how does my legacy ORM get
access to it? The answer is my eager-load service, whose real name is
T5IocAccess. T5IocAccess has a static "instance" variable that its
constructor sets to point to itself; this allows the legacy part of the app
to obtain the T5IocAccess instance (via a static "get()" method).
T5IocAccess must be eager-load to ensure that this static variable gets
populated immediately.
The per-thread service is a Hibernate session manager, which the legacy ORM
obtains via T5IocAccess.
This works, but it raises a broader question. What is the best way for
legacy code to gain access to services managed by Tapestry IoC? I created
my T5IocAccess service, with its static instance variable, because I saw no
other way.
Howard Lewis Ship wrote:
>
> This looks like an issue ... I think EagerLoad is not compatible with
> non-singleton scopes.
>
> What does it mean to eager load a service that is, in fact, used in
> multiple threads?
>
> Ah, here's the issue; when you bind a class, not an interface, as a
> service, it automatically uses singleton scope. Only proxiable
> services can have non-singleton scope, and that means an interface and
> an implementation. Tapestry should detect this and throw an
> exception.
>
> On Thu, Jul 24, 2008 at 11:01 AM, Franz Amador <[EMAIL PROTECTED]> wrote:
>>
>> I have an EagerLoad service that uses a PerThread service. I expected
>> the
>> EagerLoad service to hold a reference to a proxy to the PerThread service
>> so
>> that the actual instance of the PerThread service that is used depends
>> upon
>> the thread calling the EagerLoad service. Instead, the EagerLoad service
>> is
>> getting a reference to an actual instance of the PerThread service, not
>> to a
>> proxy, so the same instance of the PerThread service is getting used by
>> all
>> threads that call the EagerLoad service. This surely can't be right.
>> Here's a very simplified example:
>>
>> public class AppModule {
>>public static void bind(ServiceBinder binder) {
>>binder.bind(EagerLoadService.class);
>>binder.bind(PerThreadService.class);
>>}
>> }
>>
>> @EagerLoad
>> public class EagerLoadService {
>>public EagerLoadService(PerThreadService perThreadService) {
>>// prints "class PerThreadService", not a proxy class!
>>System.out.println(perThreadService.getClass());
>>}
>> }
>>
>> @Scope(PERTHREAD_SCOPE)
>> public class PerThreadService {
>> }
>>
>> Is this a bug? Am I confused about how this should work? All help
>> appreciated.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18637337.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18656018.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EagerLoad service doesn't use PerThread service correctly
This looks like an issue ... I think EagerLoad is not compatible with
non-singleton scopes.
What does it mean to eager load a service that is, in fact, used in
multiple threads?
Ah, here's the issue; when you bind a class, not an interface, as a
service, it automatically uses singleton scope. Only proxiable
services can have non-singleton scope, and that means an interface and
an implementation. Tapestry should detect this and throw an
exception.
On Thu, Jul 24, 2008 at 11:01 AM, Franz Amador <[EMAIL PROTECTED]> wrote:
>
> I have an EagerLoad service that uses a PerThread service. I expected the
> EagerLoad service to hold a reference to a proxy to the PerThread service so
> that the actual instance of the PerThread service that is used depends upon
> the thread calling the EagerLoad service. Instead, the EagerLoad service is
> getting a reference to an actual instance of the PerThread service, not to a
> proxy, so the same instance of the PerThread service is getting used by all
> threads that call the EagerLoad service. This surely can't be right.
> Here's a very simplified example:
>
> public class AppModule {
>public static void bind(ServiceBinder binder) {
>binder.bind(EagerLoadService.class);
>binder.bind(PerThreadService.class);
>}
> }
>
> @EagerLoad
> public class EagerLoadService {
>public EagerLoadService(PerThreadService perThreadService) {
>// prints "class PerThreadService", not a proxy class!
>System.out.println(perThreadService.getClass());
>}
> }
>
> @Scope(PERTHREAD_SCOPE)
> public class PerThreadService {
> }
>
> Is this a bug? Am I confused about how this should work? All help
> appreciated.
>
> --
> View this message in context:
> http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18637337.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
EagerLoad service doesn't use PerThread service correctly
I have an EagerLoad service that uses a PerThread service. I expected the
EagerLoad service to hold a reference to a proxy to the PerThread service so
that the actual instance of the PerThread service that is used depends upon
the thread calling the EagerLoad service. Instead, the EagerLoad service is
getting a reference to an actual instance of the PerThread service, not to a
proxy, so the same instance of the PerThread service is getting used by all
threads that call the EagerLoad service. This surely can't be right.
Here's a very simplified example:
public class AppModule {
public static void bind(ServiceBinder binder) {
binder.bind(EagerLoadService.class);
binder.bind(PerThreadService.class);
}
}
@EagerLoad
public class EagerLoadService {
public EagerLoadService(PerThreadService perThreadService) {
// prints "class PerThreadService", not a proxy class!
System.out.println(perThreadService.getClass());
}
}
@Scope(PERTHREAD_SCOPE)
public class PerThreadService {
}
Is this a bug? Am I confused about how this should work? All help
appreciated.
--
View this message in context:
http://www.nabble.com/EagerLoad-service-doesn%27t-use-PerThread-service-correctly-tp18637337p18637337.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
