<shameless plug for own project>You could do it using Jakarta Commons Proxy quite easily!</shameless plug for own project>
You'd create a "delegating" proxy and an ApplicationStateObjectProvider. That way, every time that a method is called on the delegating proxy, it'd forward that call to the object provided by the ApplicationStateObjectProvider. -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Mark Reynolds Sent: Thursday, May 04, 2006 11:33 AM To: tapestry-user@jakarta.apache.org Subject: Re: Is it safe to inject HiveMind services into an ASO? Expanding on what James said and following up on a hint given by Howard in an earlier thread, I have been using the approach of injecting the ASO into services using the following approach: 1) create a proxy object that implements the same interface as the ASO, 2) the proxy is a threaded/pooled hivemind service, 3) the ApplicationStateManager is injected into the proxy, 4) when a method is called on the proxy, it looks up the ASO (which is the correct one due to the proxy being threaded) and passes through the method call. I inject the proxy into any service/dao that needs information from the ASO. It would be a nice enhancement in tapestry if such ASO proxies could be automatically created. -- Mark James Carman wrote: > Create a service which returns the "current" business object. That service > can lookup the ASO and get the key. Then, your client code just calls the > service. > > -----Original Message----- > From: Paul Field [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 02, 2006 11:46 AM > To: tapestry-user@jakarta.apache.org > Subject: Is it safe to inject HiveMind services into an ASO? > > > I would like to use an ASO that contains a business object. However, I > can't store the business object directly in the ASO because (a) it will be > serialized into the session (along with a lot of related objects) (b) it is > associated with a particular database session so needs to be re-created on > each request to ensure consistency. > > So, instead, I'm storing the key of the business object in the ASO. However, > that means that every piece of client code needs to know how to turn the key > into the business object - in my case, by knowing a data access object (DAO) > that can do it for them. So, here's an example ASO showing my current > approach: > > public class Preferences implements Serializable { > private long regionId; > > public Region getRegion(RegionDAO dao) { > return dao.getRegionForId(regionId); > } > > public void setRegion(Region region) { > regionId = region.getId(); > } > } > > > What I would really like to do is use HiveMind to inject the DAO and make my > ASO something like this: > > public class Preferences implements Serializable { > private transient RegionDAO dao; > private long regionId; > > public void setRegionDAO(RegionDAO newDao) { > dao = newDao; > } > > public Region getRegion() { > return dao.getRegionForId(regionId); > } > > public void setRegion(Region region) { > regionId = region.getId(); > } > } > > > So, I'd like to know if this is a safe thing to do. Assuming the preferences > might get serialized and re-loaded by the app server or passed around a > cluster, how do I make sure that the RegionDAO stays injected but doesn't > end up serializing itself (unless it can serialize some kind of stub). > > Thanks, > > Paul > > ------------------ > Paul Field > Global Markets Research IT > Deutsche Bank > --- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
