Hold onto that; I'm getting close to checking in the refactored project, and we can 
apply the doc
change as a patch.  Good points, very helpful.

<extension> and <extension-point> ... if you check the blog, you'll see I changed the 
names to be
more consistent with Eclipse, but that's seeming like less and less of a good idea.  
Refactoring
this now is painful, but will be worse later.

How about:

<extension-point> --> <configuration> and
<extension> --> <contribution>
<extend-service> --> <service-contribution> ?

With similar changes to the API (i.e. Registry.getExtensionPointElements() ->
getConfigurationElements()) and elsewhere (i.e, set-extension-point -> 
set-configuration).

Let's let this percolate for a few days, hear what people are thinking in terms of 
intuitive naming.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Bill Lear [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 16, 2003 10:54 AM
> To: [EMAIL PROTECTED]
> Subject: [HiveMind] Suggestion for Bootstrap documentation addition
> 
> 
> I've just added my first interceptor.  Neat stuff.  I suggest 
> we add a section to the example (Bootstrap) to show how to do 
> this and how to configure the log4j properties (this was a 
> bit confusing for me).
> 
> Here is a sketch:
> 
> Debugging the Example Using a Logging Interceptor
> 
> Logging interceptors can be used to print out method 
> invocation, including parameters passed and results returned. 
>  Adding a logging interceptor to a service is easy: add an 
> interceptor clause to your HiveMind module, and set the log4j 
> debug property on this interceptor to print out the 
> information when the application is run.
> 
> So, for our example, first add a logging interceptor to the HiveMind
> module:
> 
> <?xml version="1.0"?>
> 
> <module id="hivemind.examples" version="1.0.0">
>     <service id="Adder" interface="hivemind.examples.Adder">
>         <create-instance class="hivemind.examples.impl.AdderImpl2"/>
> 
>         <interceptor service-id="hivemind.LoggingInterceptor"/>
>     </service>
> </module>
> 
> This interceptor will use the ID of the service within which 
> it is operating, in this case 'hivemind.examples.Adder'.
> 
> Next, set the debug level in the log4j.properties file by 
> catenating 'log4j.category.' with the service id:
> 
> log4j.category.hivemind.examples.Adder=debug
> 
> The complete log4j file now looks something like this:
> 
> log4j.rootCategory=WARN, A1 
> log4j.appender.A1=org.apache.log4j.ConsoleAppender
> log4j.appender.A1.layout=org.apache.log4j.PatternLayout
> log4j.appender.A1.layout.ConversionPattern=%r %c{1} [%p] %m%n 
> log4j.category.hivemind.examples.Adder=debug

May want a %c pattern, rather than %c{1}, so as to display all of 
"hivemind.examples.Adder".

> 
> Now type in 'ant run' from the top-level directory and you 
> should see the interceptor at work, printing out parameter 
> values on entry, and the result upon exit:
> 
> % ant run
>      ...
>      [java] 0 Adder [DEBUG] BEGIN add(11, 23)
>      [java] 5 Adder [DEBUG] END add() [34]
>      ...
> 
> You can also get rough execution times for the methods by 
> setting the pattern for the layout to include millisecond time values:
> 
> log4j.appender.A1.layout.ConversionPattern=<%p %d{ISO8601} %c{1}> %m%n
> 
> % ant run
>      ...
>      [java] <DEBUG 2003-09-16 09:46:02,034 Adder> BEGIN add(11, 23)
>      [java] <DEBUG 2003-09-16 09:46:02,054 Adder> END add() [34]
>      ...
> 
> This shows that the Adder add method took about 20 
> milliseconds to run.  [Q: is this time at all accurate?  Does 
> it include any interceptor overhead, or is it mostly the 
> method invocation?].

Java clock is very innacurate for short periods, less than around 60ms.

> 
> In any case, just a suggestion.
> 
> Next, I'm going to work on understanding extensions to 
> services. Not sure I like the terms, "extension" or 
> "extension-point". Configuring seems much less involved than 
> extending, and HiveMind extensions seem to be all about 
> configuring.  Since I don't fully understand it, though, once 
> I get through the doc and work through a few examples, I may 
> change my view.
> 
> 
> Bill
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to