Menu
▾
▴
webmacro-devel — Discuss development issues related to the core of WebMacro
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
| 2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
| 2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ke...@su...> - 2003-07-16 19:34:27
|
How about just wipeMyTool? ;-} But seriously, how about cleanupTools()? Keats -------Original Message------- From: Brian Goetz <br...@qu...> Sent: 07/16/03 01:46 PM To: Marc Palmer <ma...@an...> Subject: Re: Re: [Webmacro-devel] More pruning > > > Aren't you defeating your own argument here? If people like you don't care, > they won't pay by calling close() and GC will take care of it just as you > want it. No, but with all the myriad proposals floating around, I'm not surprised that this is all confusing. My positions: - NO finalizer on Context. - No _required_ close/free/destroy/cleanup method on Context -- 99% of what Context does can be handled by GC. - I am not opposed to a subscription-based mechanism for context tools, where they can register a listener, and have an optional method for "signal all the listeners now." But we don't entirely need this -- I'm find with letting tools clean themselves via finalizers or the like. You're right, for frameworks, it doesn't matter at all. But I'm thinking about the trivial WM case, and minimizing the complexity of the basic pattern. I don't like the idea of having a method called "close" but telling people "well, you don't have to use that if don't want to." > If you happen to use CTs that require cleanup then you should call > close(), but as you have stated this is a tiny minority of CTs, and > as such is unlikely to be called. Maybe naming, but not 'close'. How about 'callDestructorsForContextToolsThatCantWipeThemselves', or something like that :) |
|
From: Brian G. <br...@qu...> - 2003-07-16 17:46:49
|
> Aren't you defeating your own argument here? If people like you don't care, > they won't pay by calling close() and GC will take care of it just as you > want it. No, but with all the myriad proposals floating around, I'm not surprised that this is all confusing. My positions: - NO finalizer on Context. - No _required_ close/free/destroy/cleanup method on Context -- 99% of what Context does can be handled by GC. - I am not opposed to a subscription-based mechanism for context tools, where they can register a listener, and have an optional method for "signal all the listeners now." But we don't entirely need this -- I'm find with letting tools clean themselves via finalizers or the like. You're right, for frameworks, it doesn't matter at all. But I'm thinking about the trivial WM case, and minimizing the complexity of the basic pattern. I don't like the idea of having a method called "close" but telling people "well, you don't have to use that if don't want to." > If you happen to use CTs that require cleanup then you should call > close(), but as you have stated this is a tiny minority of CTs, and > as such is unlikely to be called. Maybe naming, but not 'close'. How about 'callDestructorsForContextToolsThatCantWipeThemselves', or something like that :) |
|
From: Marc P. <ma...@an...> - 2003-07-16 17:26:12
|
On Wed, 16 Jul 2003 10:05:27 -0700, Brian Goetz <br...@qu...> wrote:
>> Hmmm, well why not have explicity Context "close()" paradigm? It's
>> standard resource allocation stuff. Worst case scenario, we end up with
>> the GC collecting the Context and close() getting called implicitly from
>> the finalizer.
>
> Either of these suggestions seems like the worst of both worlds.
>
> 1. Why force users to call context.close? Why can't they just let it
> get garbage collected like everything else, when 99.99% of the time,
> no one is using anything in the context that requires cleanup? Why
> make most Context users pay (in convenience) for the sins of the few
> using tools which require cleanup?
Aren't you defeating your own argument here? If people like you don't care,
they won't pay by calling close() and GC will take care of it just as you
want it.
If you happen to use CTs that require cleanup then you should call close(),
but as you have stated this is a tiny minority of CTs, and as such is
unlikely to be called.
Once again... it doesn't matter if you don't call it, in the sense that you
were proposing a GC-only solution (as is now in CVS) anyway.
Adding close() gives people the option to hasten the release of resources
if this is an issue for them. As a framework write, I can trivially make
sure close() is called and it is never a concern for my developers.
> 2. If anything has to be finalized, it's NOT going to be the context.
> Finalization is expensive and really plays havoc with garbage
> collection. It takes several full GCs for an object with a finalizer
> to be collected. Why make every WM user pay the GC costs of that? If
> you're going to use finialization, do it in the tools requiring
> cleanup, not in the Context.
Agreed.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Brian G. <br...@qu...> - 2003-07-16 17:05:47
|
> Hmmm, well why not have explicity Context "close()" paradigm? It's standard > resource allocation stuff. Worst case scenario, we end up with the GC > collecting the Context and close() getting called implicitly from the > finalizer. Either of these suggestions seems like the worst of both worlds. 1. Why force users to call context.close? Why can't they just let it get garbage collected like everything else, when 99.99% of the time, no one is using anything in the context that requires cleanup? Why make most Context users pay (in convenience) for the sins of the few using tools which require cleanup? 2. If anything has to be finalized, it's NOT going to be the context. Finalization is expensive and really plays havoc with garbage collection. It takes several full GCs for an object with a finalizer to be collected. Why make every WM user pay the GC costs of that? If you're going to use finialization, do it in the tools requiring cleanup, not in the Context. |
|
From: Marc P. <ma...@an...> - 2003-07-16 16:59:03
|
On Wed, 16 Jul 2003 09:51:57 -0700, Brian Goetz <br...@qu...> wrote:
>> How about a totally trivial solution. Add a new method to ContextTool:
>>
>>
>> boolean isDestroyRequired();
>>
>> CTs implement this and return true if they want their destroy() called.
>> This way we have a complete contract for it - implement destroy()
>> accordingly if you return true from isDestroyRequired, and if you never
>> need it just return false and don't do anything in destroy().
>
> You are missing the hard part -- how does the Context know when its
> done? The question is whether we have to make the user explicitly
> destroy the context, which I don't want to force all users to do just
> because some tools I've never seen want this.
Hmmm, well why not have explicity Context "close()" paradigm? It's standard
resource allocation stuff. Worst case scenario, we end up with the GC
collecting the Context and close() getting called implicitly from the
finalizer.
That's a worst case the same as what we have now (no recycle() method any
more), and a best case where the programmer reads the docs and calls
context.close() in a finally block just like they close streams.
I don't see a problem here. Either way it will go away eventually, and for
those of us with brain cells, it will go away quickly.
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-16 16:56:01
|
On Wednesday, July 16, 2003, at 12:53 PM, ke...@su... wrote: > It seems that pinging has been disabled. I can still do a tracert and > nslookup and the site is still up. apparently our DNS server flipped out this morning... couldn't resolve the hostname. > Aren't you administering this box? yep. and the box itself is just fine. eric > > Keats > > -------Original Message------- > From: "Eric B. Ridge" <eb...@tc...> > Sent: 07/16/03 11:30 AM > To: web...@li... > Subject: [Webmacro-devel] www.webmacro.org name resolution? > >> >> can anyone resolve www.webmacro.org? wtf? > > eric > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Webmacro-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webmacro-devel >> |
|
From: <ke...@su...> - 2003-07-16 16:53:08
|
It seems that pinging has been disabled. I can still do a tracert and nslookup and the site is still up. Aren't you administering this box? Keats -------Original Message------- From: "Eric B. Ridge" <eb...@tc...> Sent: 07/16/03 11:30 AM To: web...@li... Subject: [Webmacro-devel] www.webmacro.org name resolution? > > can anyone resolve www.webmacro.org? wtf? eric ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Webmacro-devel mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
|
From: Brian G. <br...@qu...> - 2003-07-16 16:52:18
|
> How about a totally trivial solution. Add a new method to ContextTool: > > > boolean isDestroyRequired(); > > CTs implement this and return true if they want their destroy() called. > This way we have a complete contract for it - implement destroy() > accordingly if you return true from isDestroyRequired, and if you never > need it just return false and don't do anything in destroy(). You are missing the hard part -- how does the Context know when its done? The question is whether we have to make the user explicitly destroy the context, which I don't want to force all users to do just because some tools I've never seen want this. > How this is handled internally by WM is then opaque to the CT writer, and > we can optimise it any way we like (have a pre-populated Set of all CTs > that do require destroy() and just iter that). iter it WHEN? |
|
From: Marc P. <ma...@an...> - 2003-07-16 16:48:37
|
On Wed, 16 Jul 2003 09:37:55 -0700, Brian Goetz <br...@qu...> wrote:
>> Ehh.. I don't get this. A developer -may-adhere to the contract, but he
>> is equally free to just -not-do the cleanup?
>
> Some tools require cleanup. Most don't. If you use a tool that
> requires cleanup and you want those to be cleaned up other than
> through finalization, tell the context when you're done with it.
> Most users don't use such tools, so they're fine.
I agree with the sentiment about having a contract that does not have to be
completely honoured... it doesn't sit well.
How about a totally trivial solution. Add a new method to ContextTool:
boolean isDestroyRequired();
CTs implement this and return true if they want their destroy() called.
This way we have a complete contract for it - implement destroy()
accordingly if you return true from isDestroyRequired, and if you never
need it just return false and don't do anything in destroy().
How this is handled internally by WM is then opaque to the CT writer, and
we can optimise it any way we like (have a pre-populated Set of all CTs
that do require destroy() and just iter that).
Having said that, I still think the separate interface approach is nicer -
so there is no destroy() method in the CT interface. It's tidier.
Marc
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Brian G. <br...@qu...> - 2003-07-16 16:38:21
|
> Ehh.. I don't get this. A developer -may- adhere to the contract, but he > is equally free to just -not- do the cleanup? Some tools require cleanup. Most don't. If you use a tool that requires cleanup and you want those to be cleaned up other than through finalization, tell the context when you're done with it. Most users don't use such tools, so they're fine. |
|
From: Eric B. R. <eb...@tc...> - 2003-07-16 15:30:58
|
can anyone resolve www.webmacro.org? wtf? eric |
|
From: Marc P. <ma...@an...> - 2003-07-16 15:16:49
|
It's in CVS.
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: <ke...@su...> - 2003-07-16 14:13:50
|
I like this callback approach -- similar to a listener, but simpler.
We could probably make things even simpler by automating the destructor registration. Two approaches leap to mind, at tool load time check if it implements Destroyable. Alternatively this could be based on a configuration, e.g.,
ContextToolsWithDestructors: DbTool, SocketTool
Keats
-------Original Message-------
From: Brian Goetz <br...@qu...>
Sent: 07/15/03 06:59 PM
To: ke...@su...
Subject: Re: Re: [Webmacro-devel] More pruning
>
>
>So what's the best design for doing this sort of thing? The listener
>approach is appealing because then only tools that need this
functionality
>would register themselves, so very few listeners would actually be
>managed. Plus this is analogous to the model used by HttpSessions and
>ServletContexts.
>
>Is the overhead really that great?
The performance overhead is negligible.
However, the issue you raise below, requiring the WM user to explicitly
free the Context is not really negligible, as the lifecycle methods at all
levels bubble up to the the level of the user's consciousness.
So what if we add these:
class Context {
...
public void registerDestructor(Destructor dtor) {
destructors.add(dtor); }
public void destroy() { /* iterate through destructors */ }
}
which don't affect anyone who's not going to use them. To be polite, we
can teach WMServlet about it. And tools that hold things like connections
should still probably use finalizers, just in case none of the explicit
mechanisms do their job. That seems OK to me.
>I suppose an alternative is to put the onus on the Servlet developer to
>handle the cleanup if they want to use these kinds of tools. WMServlet
>makes a call to a stub method called destroyContext() after each
>request. A developer could use a method like this to go into the context
>and find resources that need to be released. This is more work for the
>developer, but since this isn't used much, it might make sense to do it
>this way.
--
Brian Goetz
Quiotix Corporation
br...@qu... Tel: 650-843-1300 Fax: 650-324-8032
http://www.quiotix.com
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Webmacro-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
|
|
From: Marc P. <ma...@an...> - 2003-07-16 10:53:39
|
On Wed, 16 Jul 2003 11:25:02 +0100, Marc Palmer <ma...@an...> wrote:
> Brian - I am trying this source and it is not working properly.
>
> I can't access context tools, they are classed as UndefinedMacro(s):
>
> org.webmacro.PropertyException$NoSuchMethodException: No public method
> HTMLEncode(property:node.Value) on variable $Text of class
> org.webmacro.engine.UndefinedMacro at jndi:/localhost/ignition/WEB-
> INF/templates/docs/includes/renderchildren.wmt:144.45
>
> Note that it says $Text is an UndefinedMacro. In the previous source
> revisions this was not the case.
1. TestContextToolAccess unit test added and verified test failed.
2. Bug fix for Broker committed to CVS.
i.e. it's working now :-)
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Marc P. <ma...@an...> - 2003-07-16 10:28:41
|
On Tue, 15 Jul 2003 23:42:24 -0700, Brian Goetz <br...@qu...> wrote:
> I'm about to check in some more ripping out of the old and unwelcome...
>
> From last week:
> - FW has been made entirely internal and getFastWriter deprecated
> - Added write, evaluteAsString, evaluateAsBytes methods to Template
>
> About to check in:
> - Eliminate the "ascii hack" from FW
> - Move all tools and tools loading into Broker, so Context doesn't have
> to deal with it
> - Make Context super-lightweight
Brian - I am trying this source and it is not working properly.
I can't access context tools, they are classed as UndefinedMacro(s):
org.webmacro.PropertyException$NoSuchMethodException: No public method
HTMLEncode(property:node.Value) on variable $Text of class
org.webmacro.engine.UndefinedMacro at jndi:/localhost/ignition/WEB-
INF/templates/docs/includes/renderchildren.wmt:144.45
Note that it says $Text is an UndefinedMacro. In the previous source
revisions this was not the case.
I will see if I can find the problem... but this is more uncharted water
for me. If you can fix it I would be grateful.
I will try to add a unit test for Context tool access.
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: <web...@st...> - 2003-07-16 07:57:36
|
On Tue, 15 Jul 2003, Brian Goetz wrote:
|
| >So what's the best design for doing this sort of thing? The listener
| >approach is appealing because then only tools that need this functionality
| >would register themselves, so very few listeners would actually be
| >managed. Plus this is analogous to the model used by HttpSessions and
| >ServletContexts.
| >
| >Is the overhead really that great?
|
| The performance overhead is negligible.
|
| However, the issue you raise below, requiring the WM user to explicitly
| free the Context is not really negligible, as the lifecycle methods at all
| levels bubble up to the the level of the user's consciousness.
|
| So what if we add these:
|
| class Context {
| ...
| public void registerDestructor(Destructor dtor) { destructors.add(dtor); }
| public void destroy() { /* iterate through destructors */ }
| }
|
| which don't affect anyone who's not going to use them. To be polite, we
| can teach WMServlet about it. And tools that hold things like connections
| should still probably use finalizers, just in case none of the explicit
| mechanisms do their job. That seems OK to me.
|
| >I suppose an alternative is to put the onus on the Servlet developer to
| >handle the cleanup if they want to use these kinds of tools. WMServlet
| >makes a call to a stub method called destroyContext() after each
| >request. A developer could use a method like this to go into the context
| >and find resources that need to be released. This is more work for the
| >developer, but since this isn't used much, it might make sense to do it
| >this way.
Ehh.. I don't get this. A developer -may- adhere to the contract, but he
is equally free to just -not- do the cleanup?
I feel that -either- one require the developer to do the cleanup (which I
don't like - I already -hate- DB Connection-getting and -closing), or
there aren't any such "suggestions" at all.
I develop a framework. If this "suggested destroy - contract" is in there,
I will have to always destroy the Contexts, as I don't know what others
will put into the configuration - even though I (as the framework
developer) don't use this at all.
Endre.
|
|
From: <web...@st...> - 2003-07-16 07:33:05
|
On Tue, 15 Jul 2003, Brian Goetz wrote:
|
| >>I think we need some solid use cases first, and then can come up with a
| >>strategy. Care to describe what your current tools do?
| >
| >Just because we haven't written X doesn't mean we shouldn't allow X to
| >work well.
|
| Only if we have already
| - agreed what X is AND
| - agreed that X is something we want to work well.
|
| Right now, it all feels very abstract to me. The fact that I've not yet
| seen a use case that needs it argues that it may well be needless
| abstraction.
|
| >+1 for getting rid of destroy(), but only if it is replaced with a
| >listener mechanism so that CTs can be told when they are no longer needed
| >by WM, without waiting for GC.
|
| Bear in mind that these mechanisms have a cost. You have to keep track of
| your listeners, and you force users into a mode of explicit
| deallocation. I don't want users to have to call Context.destroy -- I want
| to let it get garbage collected.
This is an extremely good point. Do I actually have to do Context.destroy
now? (It's been a long time since I've been "so far into" the WM, it's
abstracted quite a bit away on our system..). So I really have to do a try
{ do stuff with the context } finally { context.destroy() } -type thing to
code completely correctly?
I (now) totally agree: drop the entire lifecycle-thing..!
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
|
|
From: Brian G. <br...@qu...> - 2003-07-16 06:42:40
|
I'm about to check in some more ripping out of the old and unwelcome... From last week: - FW has been made entirely internal and getFastWriter deprecated - Added write, evaluteAsString, evaluateAsBytes methods to Template About to check in: - Eliminate the "ascii hack" from FW - Move all tools and tools loading into Broker, so Context doesn't have to deal with it - Make Context super-lightweight - Eliminate Context pooling - Eliminate WebContext pooling - Eliminate reference counting for WM and Broker -- use garbage collection - Eliminate the Clock thread (for you, Endre) - Eliminate most lifecycle methods from WebMacro, WM, Context, Broker -- use garbage collection instead - Eliminate instance pooling in LogSystem -- each Broker gets its own LogSystem Next: - Eliminate profiling -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Marc P. <ma...@an...> - 2003-07-15 23:08:04
|
On Tue, 15 Jul 2003 15:59:12 -0700, Brian Goetz <br...@qu...> wrote:
> The performance overhead is negligible.
>
> However, the issue you raise below, requiring the WM user to explicitly
> free the Context is not really negligible, as the lifecycle methods at
> all levels bubble up to the the level of the user's consciousness.
>
> So what if we add these:
>
> class Context {
> ...
> public void registerDestructor(Destructor dtor) { destructors.add(dtor);
> }
> public void destroy() { /* iterate through destructors */ }
> }
>
> which don't affect anyone who's not going to use them. To be polite, we
> can teach WMServlet about it. And tools that hold things like
> connections should still probably use finalizers, just in case none of
> the explicit mechanisms do their job. That seems OK to me.
Yes, this sounds good to me too, a listener mechanism :)
How about ContextDestroyListener instead of Destructor though? It's less
generic but it makes the functionality clearer.
Cheers
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Brian G. <br...@qu...> - 2003-07-15 22:59:51
|
>So what's the best design for doing this sort of thing? The listener
>approach is appealing because then only tools that need this functionality
>would register themselves, so very few listeners would actually be
>managed. Plus this is analogous to the model used by HttpSessions and
>ServletContexts.
>
>Is the overhead really that great?
The performance overhead is negligible.
However, the issue you raise below, requiring the WM user to explicitly
free the Context is not really negligible, as the lifecycle methods at all
levels bubble up to the the level of the user's consciousness.
So what if we add these:
class Context {
...
public void registerDestructor(Destructor dtor) { destructors.add(dtor); }
public void destroy() { /* iterate through destructors */ }
}
which don't affect anyone who's not going to use them. To be polite, we
can teach WMServlet about it. And tools that hold things like connections
should still probably use finalizers, just in case none of the explicit
mechanisms do their job. That seems OK to me.
>I suppose an alternative is to put the onus on the Servlet developer to
>handle the cleanup if they want to use these kinds of tools. WMServlet
>makes a call to a stub method called destroyContext() after each
>request. A developer could use a method like this to go into the context
>and find resources that need to be released. This is more work for the
>developer, but since this isn't used much, it might make sense to do it
>this way.
--
Brian Goetz
Quiotix Corporation
br...@qu... Tel: 650-843-1300 Fax: 650-324-8032
http://www.quiotix.com
|
|
From: <ke...@su...> - 2003-07-15 22:50:49
|
We probably could and should deprecate all the context tools that don't use the context in favor of functions. However, the "context-aware" tools like $Form, $Request, etc are still quite useful. To give a concrete example of a custom tool that uses destroy(), we created a ResultSetIteratorTool that can take a SQL expression and return an Iterator that wraps a ResultSet. The tool has to close the ResultSet and release the connection when the request is done. (I realize this is not the preferred aproach for a Web application, but it works great for our desktop app.) I can see similar applications requiring other resources, like files, sockets, HTTP connections etc. So what's the best design for doing this sort of thing? The listener approach is appealing because then only tools that need this functionality would register themselves, so very few listeners would actually be managed. Plus this is analogous to the model used by HttpSessions and ServletContexts. Is the overhead really that great? I suppose an alternative is to put the onus on the Servlet developer to handle the cleanup if they want to use these kinds of tools. WMServlet makes a call to a stub method called destroyContext() after each request. A developer could use a method like this to go into the context and find resources that need to be released. This is more work for the developer, but since this isn't used much, it might make sense to do it this way. Keats -------Original Message------- From: Brian Goetz <br...@qu...> Sent: 07/15/03 05:47 PM To: ma...@an... Subject: Re: [Webmacro-devel] More pruning > > >Well FWIW I think nuking CTs is probably a good idea too, if we can still >get the same $Form functionality etc. > >I've never used a CT, and when I eventually understood the difference >between a CT and an app-supplied helper, I couldn't really see how useful >they are except for saving a few lines of code. They're like functionality built into the context that you don't have to explicitly put there. That's pretty useful, and it allows sites to extend WM on their own by building their own tools for their own specific stuff and having it appear "built in." I personally don't use them often, but I can see how they are very useful. I don't see that nuking them will gain us much. At this point, their impact on the code and on performnace is minimal, and people DO use them. We can encourage people to use global functions instead, now that we have them. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Webmacro-devel mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webmacro-devel > |
|
From: Brian G. <br...@qu...> - 2003-07-15 21:47:56
|
>Well FWIW I think nuking CTs is probably a good idea too, if we can still >get the same $Form functionality etc. > >I've never used a CT, and when I eventually understood the difference >between a CT and an app-supplied helper, I couldn't really see how useful >they are except for saving a few lines of code. They're like functionality built into the context that you don't have to explicitly put there. That's pretty useful, and it allows sites to extend WM on their own by building their own tools for their own specific stuff and having it appear "built in." I personally don't use them often, but I can see how they are very useful. I don't see that nuking them will gain us much. At this point, their impact on the code and on performnace is minimal, and people DO use them. We can encourage people to use global functions instead, now that we have them. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Brian G. <br...@qu...> - 2003-07-15 21:46:03
|
>okay, so if we nuke the idea of context tools, all of this can go away too! Right, but the overhead of this right now is small and the value of backward compatibility is large. I agree that 98% of what tools do now can be done better with functions. But people use tools, and so if we can support existing tools at a low cost, that's preferable. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Marc P. <ma...@an...> - 2003-07-15 21:44:35
|
On Tue, 15 Jul 2003 14:07:40 -0700, Brian Goetz <br...@qu...> wrote:
>
>> right, but isn't there still special logic in Context.java in .get()
>> that says "oh, we don't have <keyname>, let me see if we have a
>> ContextTool by that name"?
>
> Yes, there is. Now it asks the Broker instead of the context (which is a
> big win because now the context starts out truly empty, instead of
> populated with tools.) But that's really it for special tool logic.
> There's no way to add a tool to the context -- you only get the tools
> loaded through the broker's configuration. Of course, you can put
> objects in the context.
Well FWIW I think nuking CTs is probably a good idea too, if we can still
get the same $Form functionality etc.
I've never used a CT, and when I eventually understood the difference
between a CT and an app-supplied helper, I couldn't really see how useful
they are except for saving a few lines of code.
In reality, applications usually provide the helpers, not the config (CTs).
In this regard, the Ignition framework app does not use CTs at all, and in
fact CTs cause a problem because I can't seem to ask the WM API for the
list of context tools that exist, so I can't provide runtime help for them.
Cheers
--
Marc Palmer
Contract Java Consultant/Developer
w a n g j a m m e r s
java and web software design
experts with an ethical outlook
http://www.wangjammers.org
|
|
From: Eric B. R. <eb...@tc...> - 2003-07-15 21:41:02
|
On Tuesday, July 15, 2003, at 05:07 PM, Brian Goetz wrote: >> right, but isn't there still special logic in Context.java in .get() >> that says "oh, we don't have <keyname>, let me see if we have a >> ContextTool by that name"? > > Yes, there is. Now it asks the Broker instead of the context (which > is a big win because now the context starts out truly empty, instead > of populated with tools.) But that's really it for special tool > logic. There's no way to add a tool to the context -- you only get > the tools loaded through the broker's configuration. Of course, you > can put objects in the context. okay, so if we nuke the idea of context tools, all of this can go away too! eric |
237 messages has been excluded from this view by a project administrator.
