global object

Discussion:

global object

Howard M. Lewis Ship

2003-01-10 02:14:06 UTC

I would like to discuss the global property added to IEngine.

I would like to see the solution fleshed out a little bit.

What I see is that, if there's a particularily named object in the servlet context, it is accessible from the IEngine. I have to assume the intent was to override ApplicationServlet.init() to provide Global. This is a bit different than how many other similar constructs, such as Visit, are implemented.

I would like to see:

1) An overridable method on AbstractEngine to create the Global.
2) A default implementation of getGlobal that checks for the Global in the servlet context and, if not present, creates and stores it into the servlet context.
3) A default implementation of createGlobal() that uses an app-spec property to define the name of the class to instantiate (i.e., same pattern as Visit).

Basically, Global should be just like Visit, except shared by all sessions/engines.

Because creating and storing the Global will not force the creation of a HttpSession, it should be done from setupForRequest(), like the many other shared objects (page source, template source, etc.).

I don't see that the Global should be any part of RequestContext.

I like the idea of Global; I'm increasingly enamored of solutions that leverage aggregation instead of inheritance.

I can whip my ideas together in a few minutes; I just wanted to see what Malcolm thinks of the changes.

----
Howard Lewis Ship
hlship-***@public.gmane.org
http://tapestry.sf.net

Malcolm Edgar

2003-01-10 07:56:53 UTC

Permalink

Hi Howard,

Yeah I don't mind if you move the global initialization out of
ApplicationServlet into AbstractEngine and have it place it in the
ServletContext, this would remove global code from ApplicationServlet and
RequestContext.

I think I was still thinking in terms of Servlets and initializing stuff in
init().

I think you will need to initialize global in setupForRequest() as it has
access to ServletContext. I would make the global servlet context attribute
key constant public so that JSP code can reference it.

Regards Malcolm

Subject: [Tapestry-contrib] global object
Date: Thu, 9 Jan 2003 21:14:06 -0500
I would like to discuss the global property added to IEngine.
I would like to see the solution fleshed out a little bit.
What I see is that, if there's a particularily named object in the servlet
context, it is accessible from the IEngine. I have to assume the intent
was to override ApplicationServlet.init() to provide Global. This is a bit
different than how many other similar constructs, such as Visit, are
implemented.
1) An overridable method on AbstractEngine to create the Global.
2) A default implementation of getGlobal that checks for the Global in the
servlet context and, if not present, creates and stores it into the servlet
context.
3) A default implementation of createGlobal() that uses an app-spec
property to define the name of the class to instantiate (i.e., same pattern
as Visit).
Basically, Global should be just like Visit, except shared by all
sessions/engines.
Because creating and storing the Global will not force the creation of a
HttpSession, it should be done from setupForRequest(), like the many other
shared objects (page source, template source, etc.).
I don't see that the Global should be any part of RequestContext.
I like the idea of Global; I'm increasingly enamored of solutions that
leverage aggregation instead of inheritance.
I can whip my ideas together in a few minutes; I just wanted to see what
Malcolm thinks of the changes.
----
Howard Lewis Ship
http://tapestry.sf.net

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Malcolm Edgar

2003-01-10 08:05:21 UTC

Permalink

One advantage of initializing the global in the Servlet.init() is that it is
done when the servlet is loaded, this may be an advantage in instantiating
heavy weight or time consuming global objects (e.g. loading a database/LDAP
cache or setting a connection pool) rather than doing initializing when the
ApplicationServlet/Engine is first hit.

regards Malcolm

Subject: Re: [Tapestry-contrib] global object
Date: Fri, 10 Jan 2003 15:56:53 +0800
Hi Howard,
Yeah I don't mind if you move the global initialization out of
ApplicationServlet into AbstractEngine and have it place it in the
ServletContext, this would remove global code from ApplicationServlet and
RequestContext.
I think I was still thinking in terms of Servlets and initializing stuff in
init().
I think you will need to initialize global in setupForRequest() as it has
access to ServletContext. I would make the global servlet context attribute
key constant public so that JSP code can reference it.
Regards Malcolm

Subject: [Tapestry-contrib] global object
Date: Thu, 9 Jan 2003 21:14:06 -0500
I would like to discuss the global property added to IEngine.
I would like to see the solution fleshed out a little bit.
What I see is that, if there's a particularily named object in the servlet
context, it is accessible from the IEngine. I have to assume the intent
was to override ApplicationServlet.init() to provide Global. This is a
bit different than how many other similar constructs, such as Visit, are
implemented.
1) An overridable method on AbstractEngine to create the Global.
2) A default implementation of getGlobal that checks for the Global in the
servlet context and, if not present, creates and stores it into the
servlet context.
3) A default implementation of createGlobal() that uses an app-spec
property to define the name of the class to instantiate (i.e., same
pattern as Visit).
Basically, Global should be just like Visit, except shared by all
sessions/engines.
Because creating and storing the Global will not force the creation of a
HttpSession, it should be done from setupForRequest(), like the many other
shared objects (page source, template source, etc.).
I don't see that the Global should be any part of RequestContext.
I like the idea of Global; I'm increasingly enamored of solutions that
leverage aggregation instead of inheritance.
I can whip my ideas together in a few minutes; I just wanted to see what
Malcolm thinks of the changes.
----
Howard Lewis Ship
http://tapestry.sf.net

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
-------------------------------------------------------
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Howard M. Lewis Ship

2003-01-10 11:59:07 UTC

Permalink

Yes, but those things could also be done using <extension> beans in the app
spec and setting the immediate flag on. Then the Global object could exist
to simplify access to those objects.

Actually, I've been picturing the Global object as the place where you stick
your EJB home and remote interfaces. If you look at the Vlib, it does this
using variables on the VlibEngine, and includes some retry logic that sets
them back to null on a RemoteException; this the Vlib is very good at riding
out JBoss restarts (when the Vlib is not running within JBoss).

----- Original Message -----
From: "Malcolm Edgar" <malcolm_edgar-***@public.gmane.org>
To: <tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Friday, January 10, 2003 3:05 AM
Subject: Re: [Tapestry-contrib] global object

Post by Malcolm Edgar
One advantage of initializing the global in the Servlet.init() is that it is
done when the servlet is loaded, this may be an advantage in instantiating
heavy weight or time consuming global objects (e.g. loading a

database/LDAP

Post by Malcolm Edgar
cache or setting a connection pool) rather than doing initializing when the
ApplicationServlet/Engine is first hit.
regards Malcolm

Subject: [Tapestry-contrib] global object
Date: Thu, 9 Jan 2003 21:14:06 -0500
I would like to discuss the global property added to IEngine.
I would like to see the solution fleshed out a little bit.
What I see is that, if there's a particularily named object in the servlet
context, it is accessible from the IEngine. I have to assume the intent
was to override ApplicationServlet.init() to provide Global. This is a
bit different than how many other similar constructs, such as Visit, are
implemented.
1) An overridable method on AbstractEngine to create the Global.
2) A default implementation of getGlobal that checks for the Global in the
servlet context and, if not present, creates and stores it into the
servlet context.
3) A default implementation of createGlobal() that uses an app-spec
property to define the name of the class to instantiate (i.e., same
pattern as Visit).
Basically, Global should be just like Visit, except shared by all
sessions/engines.
Because creating and storing the Global will not force the creation of a
HttpSession, it should be done from setupForRequest(), like the many other
shared objects (page source, template source, etc.).
I don't see that the Global should be any part of RequestContext.
I like the idea of Global; I'm increasingly enamored of solutions that
leverage aggregation instead of inheritance.
I can whip my ideas together in a few minutes; I just wanted to see what
Malcolm thinks of the changes.
----
Howard Lewis Ship
http://tapestry.sf.net

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
-------------------------------------------------------
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
-------------------------------------------------------
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Malcolm Edgar

2003-01-11 21:42:27 UTC

Permalink

I never even knew that the extension stuff existed. Yes, it sounds idea for
the job. I think global will be a great place for sticking EJB stuff.

regards Malcolm

To: "Malcolm Edgar"
Subject: Re: [Tapestry-contrib] global object
Date: Fri, 10 Jan 2003 06:59:07 -0500
Yes, but those things could also be done using <extension> beans in the app
spec and setting the immediate flag on. Then the Global object could exist
to simplify access to those objects.
Actually, I've been picturing the Global object as the place where you
stick
your EJB home and remote interfaces. If you look at the Vlib, it does this
using variables on the VlibEngine, and includes some retry logic that sets
them back to null on a RemoteException; this the Vlib is very good at
riding
out JBoss restarts (when the Vlib is not running within JBoss).
----- Original Message -----
Sent: Friday, January 10, 2003 3:05 AM
Subject: Re: [Tapestry-contrib] global object

Post by Malcolm Edgar
One advantage of initializing the global in the Servlet.init() is that

it
is

Post by Malcolm Edgar
done when the servlet is loaded, this may be an advantage in

instantiating

Post by Malcolm Edgar
heavy weight or time consuming global objects (e.g. loading a

database/LDAP

Post by Malcolm Edgar
cache or setting a connection pool) rather than doing initializing when

the

Post by Malcolm Edgar
ApplicationServlet/Engine is first hit.
regards Malcolm

and