You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Harish Krishnaswamy <hk...@comcast.net> on 2003/09/08 22:19:36 UTC
HiveMind feedback/questions
I put the Adder example together with a LoggingInterceptor in three
modules and its pretty slick. Although the free form schema gets my head
spinning ;). I think it'll take a little bit to get adjusted to living
without constraints! I like the fact that it can support both IoC and
SoC, nice! And the documentation is great.
I have a few questions:
1. What is rationale behind the names <service...> and
<extension-point...>? That would probably clarify my confusion with the
names. It got me a little confused initially,
<service-extension-point...> and <config-extension-point...> is more
intuitive to me.
2. How to debug deferred services when dynamic proxies are used?
3. In the BuilderFactory which service extension point id gets stored in
the point-id-property? For example, if I use a LoggingInterceptor like...
<extend-service service-id="hivemind.examples.Adder">
<interceptor service-id="hivemind.LoggingInterceptor" order="10"/>
</extend-service>
Thanks,
Harish
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: HiveMind feedback/questions
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Mixing and matching technologies is very cool. Some comments I made at the TSS were noted by the
Spring guys ... they are interested in adding line precise error reporting to Spring. Obviously, I
prefer HiveMind, and I'll continue to produce case studies to show why. Spring has a huge head
start in terms of components/services already packaged, which will be the growth area for HiveMind.
I really think HiveMind has found a sweet spot where you can get a lot accomplished with very little
code ... and very little XML. I'll take another look at Spring when I have a chance, but I don't
think the distributed configuration aspects of HiveMind are anywhere else, outside of Eclipse
plugins ... and the "digester-lite" stuff shouldn't be discounted either. Woops ... started
preaching there.
Anyway, that Tapestry+Spring doc is pretty darn cool. We want Tacos to contain working examples
along those lines, templates for all kinds of projects. Hasn't happened yet ... still looking for
some leadership I guess. Soon.
--
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: Colin Sampaleanu [mailto:colinml1@exis.com]
> Sent: Thursday, September 11, 2003 6:03 PM
> To: Tapestry development;
> springframework-developer@lists.sourceforge.net
> Subject: Re: HiveMind feedback/questions
>
>
> Anybody in the Tapestry world who finds HiveMind
> (http://jakarta.apache.org/commons/sandbox/hivemind/)
> interesting should
> probably also take a good look at Spring Framework
> (http://www.springframework.org/). I am unfortunately much
> more familiar
> with Spring than with HiveMind, so it wouldn't be fair for me
> to try to
> qualify which containter I think is 'better' (and an
> assertion like this
> is usually relative to the use-case anyways), but I think anybody can
> learn a lot by looking at both approaches. While the gross
> functionality
> is pretty similar, there are of course some fundamental
> differences in
> the approaches taken to implementation, configuration, and usage.
>
> Along with the container services, Spring does include a lot of other
> things, such as integration into the container and
> interceptor framework
> of a JDBC abstraction layer, some Hibernate support code,
> transactional
> wrapping, etc. There is also a UI layer which I haven't used
> so far as I
> prefer Tapestry.
>
> A couple of weeks ago I wrote an article on intergrating
> Tapestry with
> Spring. It does assume you are already familiar with both frameworks
> however. It's available at:
> http://www.springframework.org/docs/integration/tapestry.html
>
> Regards,
> Colin
>
>
> Harish Krishnaswamy wrote:
>
> > I put the Adder example together with a LoggingInterceptor in three
> > modules and its pretty slick. Although the free form schema gets my
> > head spinning ;). I think it'll take a little bit to get
> adjusted to
> > living without constraints! I like the fact that it can
> support both
> > IoC and SoC, nice! And the documentation is great.
> >
> > I have a few questions:
> > 1. What is rationale behind the names <service...> and
> > <extension-point...>? That would probably clarify my confusion with
> > the names. It got me a little confused initially,
> > <service-extension-point...> and
> <config-extension-point...> is more
> > intuitive to me.
> > 2. How to debug deferred services when dynamic proxies are used?
> > 3. In the BuilderFactory which service extension point id
> gets stored
> > in the point-id-property? For example, if I use a
> LoggingInterceptor
> > like...
> > <extend-service service-id="hivemind.examples.Adder">
> > <interceptor service-id="hivemind.LoggingInterceptor"
> order="10"/>
> > </extend-service>
> >
> > Thanks,
> > Harish
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: HiveMind feedback/questions
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Mixing and matching technologies is very cool. Some comments I made at the TSS were noted by the
Spring guys ... they are interested in adding line precise error reporting to Spring. Obviously, I
prefer HiveMind, and I'll continue to produce case studies to show why. Spring has a huge head
start in terms of components/services already packaged, which will be the growth area for HiveMind.
I really think HiveMind has found a sweet spot where you can get a lot accomplished with very little
code ... and very little XML. I'll take another look at Spring when I have a chance, but I don't
think the distributed configuration aspects of HiveMind are anywhere else, outside of Eclipse
plugins ... and the "digester-lite" stuff shouldn't be discounted either. Woops ... started
preaching there.
Anyway, that Tapestry+Spring doc is pretty darn cool. We want Tacos to contain working examples
along those lines, templates for all kinds of projects. Hasn't happened yet ... still looking for
some leadership I guess. Soon.
--
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: Colin Sampaleanu [mailto:colinml1@exis.com]
> Sent: Thursday, September 11, 2003 6:03 PM
> To: Tapestry development;
> springframework-developer@lists.sourceforge.net
> Subject: Re: HiveMind feedback/questions
>
>
> Anybody in the Tapestry world who finds HiveMind
> (http://jakarta.apache.org/commons/sandbox/hivemind/)
> interesting should
> probably also take a good look at Spring Framework
> (http://www.springframework.org/). I am unfortunately much
> more familiar
> with Spring than with HiveMind, so it wouldn't be fair for me
> to try to
> qualify which containter I think is 'better' (and an
> assertion like this
> is usually relative to the use-case anyways), but I think anybody can
> learn a lot by looking at both approaches. While the gross
> functionality
> is pretty similar, there are of course some fundamental
> differences in
> the approaches taken to implementation, configuration, and usage.
>
> Along with the container services, Spring does include a lot of other
> things, such as integration into the container and
> interceptor framework
> of a JDBC abstraction layer, some Hibernate support code,
> transactional
> wrapping, etc. There is also a UI layer which I haven't used
> so far as I
> prefer Tapestry.
>
> A couple of weeks ago I wrote an article on intergrating
> Tapestry with
> Spring. It does assume you are already familiar with both frameworks
> however. It's available at:
> http://www.springframework.org/docs/integration/tapestry.html
>
> Regards,
> Colin
>
>
> Harish Krishnaswamy wrote:
>
> > I put the Adder example together with a LoggingInterceptor in three
> > modules and its pretty slick. Although the free form schema gets my
> > head spinning ;). I think it'll take a little bit to get
> adjusted to
> > living without constraints! I like the fact that it can
> support both
> > IoC and SoC, nice! And the documentation is great.
> >
> > I have a few questions:
> > 1. What is rationale behind the names <service...> and
> > <extension-point...>? That would probably clarify my confusion with
> > the names. It got me a little confused initially,
> > <service-extension-point...> and
> <config-extension-point...> is more
> > intuitive to me.
> > 2. How to debug deferred services when dynamic proxies are used?
> > 3. In the BuilderFactory which service extension point id
> gets stored
> > in the point-id-property? For example, if I use a
> LoggingInterceptor
> > like...
> > <extend-service service-id="hivemind.examples.Adder">
> > <interceptor service-id="hivemind.LoggingInterceptor"
> order="10"/>
> > </extend-service>
> >
> > Thanks,
> > Harish
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
Re: HiveMind feedback/questions
Posted by Colin Sampaleanu <co...@exis.com>.
Anybody in the Tapestry world who finds HiveMind
(http://jakarta.apache.org/commons/sandbox/hivemind/) interesting should
probably also take a good look at Spring Framework
(http://www.springframework.org/). I am unfortunately much more familiar
with Spring than with HiveMind, so it wouldn't be fair for me to try to
qualify which containter I think is 'better' (and an assertion like this
is usually relative to the use-case anyways), but I think anybody can
learn a lot by looking at both approaches. While the gross functionality
is pretty similar, there are of course some fundamental differences in
the approaches taken to implementation, configuration, and usage.
Along with the container services, Spring does include a lot of other
things, such as integration into the container and interceptor framework
of a JDBC abstraction layer, some Hibernate support code, transactional
wrapping, etc. There is also a UI layer which I haven't used so far as I
prefer Tapestry.
A couple of weeks ago I wrote an article on intergrating Tapestry with
Spring. It does assume you are already familiar with both frameworks
however. It's available at:
http://www.springframework.org/docs/integration/tapestry.html
Regards,
Colin
Harish Krishnaswamy wrote:
> I put the Adder example together with a LoggingInterceptor in three
> modules and its pretty slick. Although the free form schema gets my
> head spinning ;). I think it'll take a little bit to get adjusted to
> living without constraints! I like the fact that it can support both
> IoC and SoC, nice! And the documentation is great.
>
> I have a few questions:
> 1. What is rationale behind the names <service...> and
> <extension-point...>? That would probably clarify my confusion with
> the names. It got me a little confused initially,
> <service-extension-point...> and <config-extension-point...> is more
> intuitive to me.
> 2. How to debug deferred services when dynamic proxies are used?
> 3. In the BuilderFactory which service extension point id gets stored
> in the point-id-property? For example, if I use a LoggingInterceptor
> like...
> <extend-service service-id="hivemind.examples.Adder">
> <interceptor service-id="hivemind.LoggingInterceptor" order="10"/>
> </extend-service>
>
> Thanks,
> Harish
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: HiveMind feedback/questions
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Just found out that eclipse extension-points, although majority of the
time are used to extend behavior like Hivemind services, can be used for
configuration data also just like the Hivemind extension-point. Your
earlier idea would have been in perfect accordance with eclipse:).
-Harish
Harish Krishnaswamy wrote:
>
>
> Howard M. Lewis Ship wrote:
>
>> --
>> 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: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] Sent:
>>> Monday, September 08, 2003 4:20 PM
>>> To: Tapestry development
>>> Subject: HiveMind feedback/questions
>>>
>>>
>>> I put the Adder example together with a LoggingInterceptor in three
>>> modules and its pretty slick. Although the free form schema gets my
>>> head spinning ;). I think it'll take a little bit to get adjusted to
>>> living without constraints! I like the fact that it can support both
>>> IoC and SoC, nice! And the documentation is great.
>>>
>>> I have a few questions:
>>> 1. What is rationale behind the names <service...> and
>>> <extension-point...>? That would probably clarify my confusion with
>>> the names.
>>
>>
>> The naming is a bit tricky. I eventually ended up with
>> <extension-point> and <extension> because
>> that part of HiveMind is very close to Eclipse's plugin model; I
>> decided that rather than have
>> competing names, I'd use the Eclipse names.
>>
>> To some degree, I wish I had gone with an earlier idea that I
>> discarded (can't remember why) where
>> an extension point could be either a configuration extension point, a
>> service extension point, or
>> both.
>>
> I had the same thought, but then I thought you might have
> differentiated them because of the special service contributions
> (create-instance, ...). The other way would have definitely been much
> more simpler. Also, I had all along thought that the Hivemind service
> was analogous to the eclipse extension-point because they both provide
> behavioral extensions, while Hivemind extensions as such only provide
> objects that have to be manipulated by a service or something, am I at
> a loss here?
>
>>
>>
>>
>>> It got me a little confused initially, <service-extension-point...>
>>> and <config-extension-point...> is more intuitive to me.
>>> 2. How to debug deferred services when dynamic proxies are used?
>>>
>>
>>
>> Place your breakpoints inside your service implementation class.
>> Proxies and interceptors shouldn't
>> need to be debugged. In some cases, there's a method in an abstract
>> class you can place breakpoints
>> in.
>>
> I was actually trying to trace the call-chain from RegistryBuilder and
> couldn't proceed after I hit the proxy but I guess I can switch the
> service to Singleton for this purpose, right? I shall try this tomorrow.
>
>>
>>
>> 3. In the BuilderFactory which service extension point
>>
>>> id gets stored in the point-id-property?
>>
>>
>> If you use the BuilderFactory to construct service "foo.bar.Baz",
>> then the point-id-property is used
>> to specify the property, of type String, to be set to "foo.bar.Baz".
>> Constructing and configuring
>> the core service implementation using the BuilderFactory is entirely
>> seperate from the interceptor
>> stack.
>>
>>
>> For example, if I use a
>>
>>> LoggingInterceptor like...
>>> <extend-service service-id="hivemind.examples.Adder">
>>> <interceptor service-id="hivemind.LoggingInterceptor" order="10"/>
>>> </extend-service>
>>>
>>
>>
>> Here, the property will be set to "hivemind.examples.Adder",
>> regardless of what interceptor(s) are
>> contributed in.
>>
>> --
>> 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: [HiveMind] HiveMind vs. Eclipse
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I think I see your point now. Eclipse is a platform and a registry of
extensions to the platform. HiveMind is just a registry of services and
configuration.
Howard M. Lewis Ship wrote:
>Eclipse just has <extension-point> and <extension>
>
>As with HiveMind, you can have <extension>s in many plug-ins contribute to the same
><extension-point>.
>
>The <extension-point> gets all the contributions in a DOM-like format (thinly disguised XML elements
>and attributes).
>
>Eclipse <extension-point>s can have a schema (in W3C Schema format, roughly), but that appears to
>only be used by the PDE (this is not verified, however). Eclipse doesn't have the equivalent of
>HiveMind's <schema>, <element>, <attribute> and <rules> for runtime (not buildtime) validation and
>conversion.
>
>Eclipse includes a special case for dealing with classpath issues when a contribution is the name of
>a class; it hooks into the right class loader and may activate the plugin when a class is
>instantiated. Beyond that, Eclipse doesn't have a service model.
>
I think this is where the disconnect is. It is exactly because of this
hook that I thought eclipse extensions are similar to services. But I
see your point that services have various models and that a service can
only be contributed to once. In that respect I agree that HiveMind
extension-points are more similar to the Eclipse extension-poits than
services. On another angle though, Eclipse is a platform and a registry
of extensions to the platform while HiveMind is just a registry of
services and configuration, nothing to extend, so from my understanding
so far, my names for today are <service-point...> and
<configuration-point...> :).
>
>Perhaps you are confused by the ability to pass parameters to a service implementation factory (such
>as hivemind.Builder)? That looks like an <extension> (and leverages the same code), but only a
>single module may contribute a service constructor, and therefore, there won't be multiple
><invoke-factory> elements for any given service. Multiple modules may contribute an <interceptor>.
>
>HiveMind <interceptor>, <service>, <extend-service>, <create-instance> and <invoke-factory> don't
>have any parallels in Eclipse, beyond the limited support for passing a class name as an attribute
>in a contribution. From code I've looked at, different plugins will cooperate by accessing each
>other's Plugin singleton's (via static methods).
>
>Also, to my knowledge, Eclipse is not expressly thread-safe. HiveMind is (to the best of my
>knowledge).
>
>
>Note: moved this over to Jakarta Commons Developer.
>
>--
>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: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
>>Sent: Tuesday, September 09, 2003 11:45 AM
>>To: Tapestry development
>>Subject: Re: HiveMind feedback/questions
>>
>>
>>
>>
>>Howard M. Lewis Ship wrote:
>>
>>
>>
>>>>>>-----Original Message-----
>>>>>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
>>>>>>Sent: Monday, September 08, 2003 4:20 PM
>>>>>>To: Tapestry development
>>>>>>Subject: HiveMind feedback/questions
>>>>>>
>>>>>>
>>>>>>I put the Adder example together with a
>>>>>>
>>>>>>
>>LoggingInterceptor in three
>>
>>
>>>>>>modules and its pretty slick. Although the free form
>>>>>>
>>>>>>
>>schema gets my
>>
>>
>>>>>>head spinning ;). I think it'll take a little bit to get adjusted
>>>>>>to living
>>>>>>without constraints! I like the fact that it can support
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>both IoC and
>>>>
>>>>
>>>>
>>>>
>>>>>>SoC, nice! And the documentation is great.
>>>>>>
>>>>>>I have a few questions:
>>>>>>1. What is rationale behind the names <service...> and
>>>>>><extension-point...>? That would probably clarify my
>>>>>>confusion with the
>>>>>>names.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>The naming is a bit tricky. I eventually ended up with
>>>>><extension-point> and <extension> because that part of
>>>>>
>>>>>
>>>>>
>>>>>
>>>>HiveMind is very
>>>>
>>>>
>>>>
>>>>
>>>>>close to Eclipse's plugin model; I decided that rather than have
>>>>>competing names, I'd use the Eclipse names.
>>>>>
>>>>>To some degree, I wish I had gone with an earlier idea that
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I discarded
>>>>
>>>>
>>>>
>>>>
>>>>>(can't remember why) where an extension point could be either a
>>>>>configuration extension point, a service extension point, or both.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I had the same thought, but then I thought you might have
>>>>differentiated
>>>>them because of the special service contributions (create-instance,
>>>>...). The other way would have definitely been much more
>>>>simpler. Also,
>>>>I had all along thought that the Hivemind service was
>>>>analogous to the
>>>>eclipse extension-point because they both provide behavioral
>>>>extensions,
>>>>while Hivemind extensions as such only provide objects that
>>>>have to be
>>>>manipulated by a service or something, am I at a loss here?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>The plugin API is very, very close to the extension points;
>>>
>>>
>>it doesn't really have the concept of a
>>
>>
>>>service.
>>>It does have special hooks that do the right class loader
>>>
>>>
>>thing when a contribution is the name of a
>>
>>
>>>class. Eclipse doesn't have the <rules> thing to convert the
>>>
>>>
>>contributions directly into Java
>>
>>
>>>objects ... most Eclipse plugins are full of code to walk
>>>
>>>
>>elements and attributes and do the
>>
>>
>>>conversions.
>>>
>>>
>>>
>>>
>>This is certainly one area where Hivemind overtakes Eclipse. Using
>>Hivemind to build Eclipse would have been a lot more simpler!
>>But I am
>>sorry, I still can't see difference between services and eclipse
>>extension points, is it because extension points cannot take
>>interceptor
>>and factory contributions? But conceptually though, from my
>>understanding, services and eclipse extension points can both take
>>behavioral contributions and Hivemind extension points
>>cannot. Sorry to
>>belabor the point, may be I have to do more reading.
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>It got me a little confused initially,
>>>>>><service-extension-point...> and
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>><config-extension-point...> is more
>>>>
>>>>
>>>>
>>>>
>>>>>>intuitive to me.
>>>>>>2. How to debug deferred services when dynamic proxies are
>>>>>>used?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Place your breakpoints inside your service implementation class.
>>>>>Proxies and interceptors shouldn't need to be debugged. In
>>>>>
>>>>>
>>>>>
>>>>>
>>>>some cases,
>>>>
>>>>
>>>>
>>>>
>>>>>there's a method in an abstract class you can place breakpoints in.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I was actually trying to trace the call-chain from
>>>>RegistryBuilder and
>>>>couldn't proceed after I hit the proxy but I guess I can switch the
>>>>service to Singleton for this purpose, right? I shall try
>>>>this tomorrow.
>>>>
>>>>
>>>>
>>>>
>>>Yes, that's a disadvantage of creating the code at runtime;
>>>
>>>
>>there's no "source code" for the
>>
>>
>>>debugger to step through. The advantages, even over
>>>
>>>
>>something like XDoclet, is much easier build
>>
>>
>>>time environment, and always perfectly in-sync, fewer
>>>
>>>
>>build-time artifacts (such as generated Java
>>
>>
>>>files), etc.
>>>
>>>
>>>
>>No argument here!
>>
>>
>>
>>>--
>>>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
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
[HiveMind] HiveMind vs. Eclipse
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Eclipse just has <extension-point> and <extension>
As with HiveMind, you can have <extension>s in many plug-ins contribute to the same
<extension-point>.
The <extension-point> gets all the contributions in a DOM-like format (thinly disguised XML elements
and attributes).
Eclipse <extension-point>s can have a schema (in W3C Schema format, roughly), but that appears to
only be used by the PDE (this is not verified, however). Eclipse doesn't have the equivalent of
HiveMind's <schema>, <element>, <attribute> and <rules> for runtime (not buildtime) validation and
conversion.
Eclipse includes a special case for dealing with classpath issues when a contribution is the name of
a class; it hooks into the right class loader and may activate the plugin when a class is
instantiated. Beyond that, Eclipse doesn't have a service model.
Perhaps you are confused by the ability to pass parameters to a service implementation factory (such
as hivemind.Builder)? That looks like an <extension> (and leverages the same code), but only a
single module may contribute a service constructor, and therefore, there won't be multiple
<invoke-factory> elements for any given service. Multiple modules may contribute an <interceptor>.
HiveMind <interceptor>, <service>, <extend-service>, <create-instance> and <invoke-factory> don't
have any parallels in Eclipse, beyond the limited support for passing a class name as an attribute
in a contribution. From code I've looked at, different plugins will cooperate by accessing each
other's Plugin singleton's (via static methods).
Also, to my knowledge, Eclipse is not expressly thread-safe. HiveMind is (to the best of my
knowledge).
Note: moved this over to Jakarta Commons Developer.
--
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: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> Sent: Tuesday, September 09, 2003 11:45 AM
> To: Tapestry development
> Subject: Re: HiveMind feedback/questions
>
>
>
>
> Howard M. Lewis Ship wrote:
>
> >>>>-----Original Message-----
> >>>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> >>>>Sent: Monday, September 08, 2003 4:20 PM
> >>>>To: Tapestry development
> >>>>Subject: HiveMind feedback/questions
> >>>>
> >>>>
> >>>>I put the Adder example together with a
> LoggingInterceptor in three
> >>>>modules and its pretty slick. Although the free form
> schema gets my
> >>>>head spinning ;). I think it'll take a little bit to get adjusted
> >>>>to living
> >>>>without constraints! I like the fact that it can support
> >>>>
> >>>>
> >>both IoC and
> >>
> >>
> >>>>SoC, nice! And the documentation is great.
> >>>>
> >>>>I have a few questions:
> >>>>1. What is rationale behind the names <service...> and
> >>>><extension-point...>? That would probably clarify my
> >>>>confusion with the
> >>>>names.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>The naming is a bit tricky. I eventually ended up with
> >>><extension-point> and <extension> because that part of
> >>>
> >>>
> >>HiveMind is very
> >>
> >>
> >>>close to Eclipse's plugin model; I decided that rather than have
> >>>competing names, I'd use the Eclipse names.
> >>>
> >>>To some degree, I wish I had gone with an earlier idea that
> >>>
> >>>
> >>I discarded
> >>
> >>
> >>>(can't remember why) where an extension point could be either a
> >>>configuration extension point, a service extension point, or both.
> >>>
> >>>
> >>>
> >>>
> >>I had the same thought, but then I thought you might have
> >>differentiated
> >>them because of the special service contributions (create-instance,
> >>...). The other way would have definitely been much more
> >>simpler. Also,
> >>I had all along thought that the Hivemind service was
> >>analogous to the
> >>eclipse extension-point because they both provide behavioral
> >>extensions,
> >>while Hivemind extensions as such only provide objects that
> >>have to be
> >>manipulated by a service or something, am I at a loss here?
> >>
> >>
> >>
> >
> >The plugin API is very, very close to the extension points;
> it doesn't really have the concept of a
> >service.
> >It does have special hooks that do the right class loader
> thing when a contribution is the name of a
> >class. Eclipse doesn't have the <rules> thing to convert the
> contributions directly into Java
> >objects ... most Eclipse plugins are full of code to walk
> elements and attributes and do the
> >conversions.
> >
> >
> This is certainly one area where Hivemind overtakes Eclipse. Using
> Hivemind to build Eclipse would have been a lot more simpler!
> But I am
> sorry, I still can't see difference between services and eclipse
> extension points, is it because extension points cannot take
> interceptor
> and factory contributions? But conceptually though, from my
> understanding, services and eclipse extension points can both take
> behavioral contributions and Hivemind extension points
> cannot. Sorry to
> belabor the point, may be I have to do more reading.
>
> >
> >
> >
> >>>
> >>>
> >>>
> >>>
> >>>>It got me a little confused initially,
> >>>><service-extension-point...> and
> >>>>
> >>>>
> >><config-extension-point...> is more
> >>
> >>
> >>>>intuitive to me.
> >>>>2. How to debug deferred services when dynamic proxies are
> >>>>used?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Place your breakpoints inside your service implementation class.
> >>>Proxies and interceptors shouldn't need to be debugged. In
> >>>
> >>>
> >>some cases,
> >>
> >>
> >>>there's a method in an abstract class you can place breakpoints in.
> >>>
> >>>
> >>>
> >>I was actually trying to trace the call-chain from
> >>RegistryBuilder and
> >>couldn't proceed after I hit the proxy but I guess I can switch the
> >>service to Singleton for this purpose, right? I shall try
> >>this tomorrow.
> >>
> >>
> >
> >Yes, that's a disadvantage of creating the code at runtime;
> there's no "source code" for the
> >debugger to step through. The advantages, even over
> something like XDoclet, is much easier build
> >time environment, and always perfectly in-sync, fewer
> build-time artifacts (such as generated Java
> >files), etc.
> >
> No argument here!
>
> >
> >--
> >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
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
Re: HiveMind feedback/questions
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Howard M. Lewis Ship wrote:
>>>>-----Original Message-----
>>>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
>>>>Sent: Monday, September 08, 2003 4:20 PM
>>>>To: Tapestry development
>>>>Subject: HiveMind feedback/questions
>>>>
>>>>
>>>>I put the Adder example together with a LoggingInterceptor in three
>>>>modules and its pretty slick. Although the free form schema
>>>>gets my head
>>>>spinning ;). I think it'll take a little bit to get adjusted
>>>>to living
>>>>without constraints! I like the fact that it can support
>>>>
>>>>
>>both IoC and
>>
>>
>>>>SoC, nice! And the documentation is great.
>>>>
>>>>I have a few questions:
>>>>1. What is rationale behind the names <service...> and
>>>><extension-point...>? That would probably clarify my
>>>>confusion with the
>>>>names.
>>>>
>>>>
>>>>
>>>>
>>>The naming is a bit tricky. I eventually ended up with
>>><extension-point> and <extension> because that part of
>>>
>>>
>>HiveMind is very
>>
>>
>>>close to Eclipse's plugin model; I decided that rather than have
>>>competing names, I'd use the Eclipse names.
>>>
>>>To some degree, I wish I had gone with an earlier idea that
>>>
>>>
>>I discarded
>>
>>
>>>(can't remember why) where an extension point could be either a
>>>configuration extension point, a service extension point, or both.
>>>
>>>
>>>
>>>
>>I had the same thought, but then I thought you might have
>>differentiated
>>them because of the special service contributions (create-instance,
>>...). The other way would have definitely been much more
>>simpler. Also,
>>I had all along thought that the Hivemind service was
>>analogous to the
>>eclipse extension-point because they both provide behavioral
>>extensions,
>>while Hivemind extensions as such only provide objects that
>>have to be
>>manipulated by a service or something, am I at a loss here?
>>
>>
>>
>
>The plugin API is very, very close to the extension points; it doesn't really have the concept of a
>service.
>It does have special hooks that do the right class loader thing when a contribution is the name of a
>class. Eclipse doesn't have the <rules> thing to convert the contributions directly into Java
>objects ... most Eclipse plugins are full of code to walk elements and attributes and do the
>conversions.
>
>
This is certainly one area where Hivemind overtakes Eclipse. Using
Hivemind to build Eclipse would have been a lot more simpler! But I am
sorry, I still can't see difference between services and eclipse
extension points, is it because extension points cannot take interceptor
and factory contributions? But conceptually though, from my
understanding, services and eclipse extension points can both take
behavioral contributions and Hivemind extension points cannot. Sorry to
belabor the point, may be I have to do more reading.
>
>
>
>>>
>>>
>>>
>>>
>>>>It got me a little confused initially,
>>>><service-extension-point...> and
>>>>
>>>>
>><config-extension-point...> is more
>>
>>
>>>>intuitive to me.
>>>>2. How to debug deferred services when dynamic proxies are
>>>>used?
>>>>
>>>>
>>>>
>>>>
>>>Place your breakpoints inside your service implementation class.
>>>Proxies and interceptors shouldn't need to be debugged. In
>>>
>>>
>>some cases,
>>
>>
>>>there's a method in an abstract class you can place breakpoints in.
>>>
>>>
>>>
>>I was actually trying to trace the call-chain from
>>RegistryBuilder and
>>couldn't proceed after I hit the proxy but I guess I can switch the
>>service to Singleton for this purpose, right? I shall try
>>this tomorrow.
>>
>>
>
>Yes, that's a disadvantage of creating the code at runtime; there's no "source code" for the
>debugger to step through. The advantages, even over something like XDoclet, is much easier build
>time environment, and always perfectly in-sync, fewer build-time artifacts (such as generated Java
>files), etc.
>
No argument here!
>
>--
>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
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
RE: HiveMind feedback/questions
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> >>-----Original Message-----
> >>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> >>Sent: Monday, September 08, 2003 4:20 PM
> >>To: Tapestry development
> >>Subject: HiveMind feedback/questions
> >>
> >>
> >>I put the Adder example together with a LoggingInterceptor in three
> >>modules and its pretty slick. Although the free form schema
> >>gets my head
> >>spinning ;). I think it'll take a little bit to get adjusted
> >>to living
> >>without constraints! I like the fact that it can support
> both IoC and
> >>SoC, nice! And the documentation is great.
> >>
> >>I have a few questions:
> >>1. What is rationale behind the names <service...> and
> >><extension-point...>? That would probably clarify my
> >>confusion with the
> >>names.
> >>
> >>
> >
> >The naming is a bit tricky. I eventually ended up with
> ><extension-point> and <extension> because that part of
> HiveMind is very
> >close to Eclipse's plugin model; I decided that rather than have
> >competing names, I'd use the Eclipse names.
> >
> >To some degree, I wish I had gone with an earlier idea that
> I discarded
> >(can't remember why) where an extension point could be either a
> >configuration extension point, a service extension point, or both.
> >
> >
> I had the same thought, but then I thought you might have
> differentiated
> them because of the special service contributions (create-instance,
> ...). The other way would have definitely been much more
> simpler. Also,
> I had all along thought that the Hivemind service was
> analogous to the
> eclipse extension-point because they both provide behavioral
> extensions,
> while Hivemind extensions as such only provide objects that
> have to be
> manipulated by a service or something, am I at a loss here?
>
The plugin API is very, very close to the extension points; it doesn't really have the concept of a
service.
It does have special hooks that do the right class loader thing when a contribution is the name of a
class. Eclipse doesn't have the <rules> thing to convert the contributions directly into Java
objects ... most Eclipse plugins are full of code to walk elements and attributes and do the
conversions.
> >
> >
> >
> >>It got me a little confused initially,
> >><service-extension-point...> and
> <config-extension-point...> is more
> >>intuitive to me.
> >>2. How to debug deferred services when dynamic proxies are
> >>used?
> >>
> >>
> >
> >Place your breakpoints inside your service implementation class.
> >Proxies and interceptors shouldn't need to be debugged. In
> some cases,
> >there's a method in an abstract class you can place breakpoints in.
> >
> I was actually trying to trace the call-chain from
> RegistryBuilder and
> couldn't proceed after I hit the proxy but I guess I can switch the
> service to Singleton for this purpose, right? I shall try
> this tomorrow.
Yes, that's a disadvantage of creating the code at runtime; there's no "source code" for the
debugger to step through. The advantages, even over something like XDoclet, is much easier build
time environment, and always perfectly in-sync, fewer build-time artifacts (such as generated Java
files), etc.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: HiveMind feedback/questions
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Howard M. Lewis Ship wrote:
>--
>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: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
>>Sent: Monday, September 08, 2003 4:20 PM
>>To: Tapestry development
>>Subject: HiveMind feedback/questions
>>
>>
>>I put the Adder example together with a LoggingInterceptor in three
>>modules and its pretty slick. Although the free form schema
>>gets my head
>>spinning ;). I think it'll take a little bit to get adjusted
>>to living
>>without constraints! I like the fact that it can support both IoC and
>>SoC, nice! And the documentation is great.
>>
>>I have a few questions:
>>1. What is rationale behind the names <service...> and
>><extension-point...>? That would probably clarify my
>>confusion with the
>>names.
>>
>>
>
>The naming is a bit tricky. I eventually ended up with <extension-point> and <extension> because
>that part of HiveMind is very close to Eclipse's plugin model; I decided that rather than have
>competing names, I'd use the Eclipse names.
>
>To some degree, I wish I had gone with an earlier idea that I discarded (can't remember why) where
>an extension point could be either a configuration extension point, a service extension point, or
>both.
>
>
I had the same thought, but then I thought you might have differentiated
them because of the special service contributions (create-instance,
...). The other way would have definitely been much more simpler. Also,
I had all along thought that the Hivemind service was analogous to the
eclipse extension-point because they both provide behavioral extensions,
while Hivemind extensions as such only provide objects that have to be
manipulated by a service or something, am I at a loss here?
>
>
>
>>It got me a little confused initially,
>><service-extension-point...> and <config-extension-point...> is more
>>intuitive to me.
>>2. How to debug deferred services when dynamic proxies are
>>used?
>>
>>
>
>Place your breakpoints inside your service implementation class. Proxies and interceptors shouldn't
>need to be debugged. In some cases, there's a method in an abstract class you can place breakpoints
>in.
>
I was actually trying to trace the call-chain from RegistryBuilder and
couldn't proceed after I hit the proxy but I guess I can switch the
service to Singleton for this purpose, right? I shall try this tomorrow.
>
>
> 3. In the BuilderFactory which service extension point
>
>
>>id gets stored in
>>the point-id-property?
>>
>>
>
>If you use the BuilderFactory to construct service "foo.bar.Baz", then the point-id-property is used
>to specify the property, of type String, to be set to "foo.bar.Baz". Constructing and configuring
>the core service implementation using the BuilderFactory is entirely seperate from the interceptor
>stack.
>
>
>For example, if I use a
>
>
>>LoggingInterceptor like...
>> <extend-service service-id="hivemind.examples.Adder">
>> <interceptor service-id="hivemind.LoggingInterceptor" order="10"/>
>> </extend-service>
>>
>>
>
>Here, the property will be set to "hivemind.examples.Adder", regardless of what interceptor(s) are
>contributed in.
>
>--
>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
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>
RE: HiveMind feedback/questions
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
--
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: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net]
> Sent: Monday, September 08, 2003 4:20 PM
> To: Tapestry development
> Subject: HiveMind feedback/questions
>
>
> I put the Adder example together with a LoggingInterceptor in three
> modules and its pretty slick. Although the free form schema
> gets my head
> spinning ;). I think it'll take a little bit to get adjusted
> to living
> without constraints! I like the fact that it can support both IoC and
> SoC, nice! And the documentation is great.
>
> I have a few questions:
> 1. What is rationale behind the names <service...> and
> <extension-point...>? That would probably clarify my
> confusion with the
> names.
The naming is a bit tricky. I eventually ended up with <extension-point> and <extension> because
that part of HiveMind is very close to Eclipse's plugin model; I decided that rather than have
competing names, I'd use the Eclipse names.
To some degree, I wish I had gone with an earlier idea that I discarded (can't remember why) where
an extension point could be either a configuration extension point, a service extension point, or
both.
> It got me a little confused initially,
> <service-extension-point...> and <config-extension-point...> is more
> intuitive to me.
> 2. How to debug deferred services when dynamic proxies are
> used?
Place your breakpoints inside your service implementation class. Proxies and interceptors shouldn't
need to be debugged. In some cases, there's a method in an abstract class you can place breakpoints
in.
3. In the BuilderFactory which service extension point
> id gets stored in
> the point-id-property?
If you use the BuilderFactory to construct service "foo.bar.Baz", then the point-id-property is used
to specify the property, of type String, to be set to "foo.bar.Baz". Constructing and configuring
the core service implementation using the BuilderFactory is entirely seperate from the interceptor
stack.
For example, if I use a
> LoggingInterceptor like...
> <extend-service service-id="hivemind.examples.Adder">
> <interceptor service-id="hivemind.LoggingInterceptor" order="10"/>
> </extend-service>
Here, the property will be set to "hivemind.examples.Adder", regardless of what interceptor(s) are
contributed in.
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org