Create a service wrapper around
DatabaseConnection.getReadConnection(). This will put the
eager-loading mechanism on your side.
Alternately, put in proper synchronization semantics on
DatabaseConnection static methods.l
Use of statics in an application using Tapestry IoC is a design smell.
On Mon, Jul 27, 2009 at 12:55 AM, <p.stavrini...@albourne.com> wrote:
> Hi,
>
> Before I open a jira for this I have devised an coded example to illustrate
> it, and hopefully get some comments:
>
> //Example: The shell of an eagerloaded service
> public class ImageService {
>
> /** Cache to hold thumbnail images */
> private static ConcurrentHashMap<Integer, Thumbnail> imageCache_ = new
> ConcurrentHashMap<Integer, Thumbnail>();
>
>
> public void preloadImageCache() {
> DbConnection connection = null;
> try {
> //Sometimes this turns into a Null Pointer Exception
> as another eagerloaded service sets up the connection pool etc.
> //this service should start up after that one, but
> this is not always the case in practice??
> connection = DatabaseConnection.getReadConnection();
> //database query
> } catch (Exception e) {
> //handle exception
> }
> }
>
>
> public static ImageService build() {
> return new ImageService();
> }
>
> public ImageService() {
> preloadImageCache();
> }
> }
>
> //Workaround: adding a dependency on the other eagerloaded service solves it,
> but this is not a practical solution if there are many of these services
> public class ImageService {
>
> /** Cache to hold thumbnail images */
> private static ConcurrentHashMap<Integer, Thumbnail> imageCache_ = new
> ConcurrentHashMap<Integer, Thumbnail>();
>
>
> public void preloadImageCache() {
> DbConnection connection = null;
> try {
> connection = DatabaseConnection.getReadConnection();
> //database query
> } catch (Exception e) {
> //handle exception
> }
> }
>
>
> public static ImageService build(SiteInitialise siteInitialise) {
> return new ImageService(siteInitialise);
> }
>
> public ImageService(SiteInitialise siteInitialise) {
> if(siteInitialise.isConnectionOk())
> preloadImageCache();
> }
> }
>
> If there is a way to ensure the ordering of eagerloaded services, then this
> is not an issue, perhaps this is a regression from the fix to
> http://issues.apache.org/jira/browse/TAPESTRY-2267 ? otherwise I am surprised
> that others have not come across this, perhaps I have missed something?
>
> Cheers,
> Peter
>
>
> ----- Original Message -----
> From: "Peter Stavrinides" <p.stavrini...@albourne.com>
> To: "Tapestry Mailing List" <users@tapestry.apache.org>
> Sent: Friday, 24 July, 2009 15:59:20 GMT +02:00 Athens, Beirut, Bucharest,
> Istanbul
> Subject: Tapestry 5 IoC Eagerloading and ordering of services
>
> Hi everyone,
>
> Is it possible to control the ordering of eagerloaded IoC services,
> especially if the services exist is separate but dependent IoC modules.
>
> I found an issue http://issues.apache.org/jira/browse/TAPESTRY-2267 that
> states these service proxies are claimed and loaded collectively, however no
> mention is made of how to ensure the correct ordering of these claimed
> services?
>
> Any help with this would be greatly appreciated.
>
> Kind regards,
> Peter
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
