You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Viktor Szathmary <ph...@gmail.com> on 2005/05/10 06:33:11 UTC
hivemind impressions/comments/rant
Hello,
as a relatively new user of HiveMind, I thought I would share my
impressions/thoughts after applying it on a medium sized project.
Please take this as constructive criticsm. Some of the issues are just
part of the learning curve, some of them are due to the fact that it's
still in it's early stages, and some of them I feel are issues with
general approach taken.
HiveMind seems to be a mixture of an IoC/dependency management
container and a a POJO/XML data binding framework, with a bit of
xml-based scripting thrown in. No real issues with the IoC part - the
concept is well estabilished and I find it natural to think in these
terms. The headaches start with the OO/XML binding framework.
For simple dependencies, it's easy enough to set things up. The first
dubious point is the distinction between services and configurations.
IMHO this distinction really doesn't help at all: it doesn't add any
value to introduce two concepts, where one would be sufficient. Both
services and configurations are objects that get initialized via xml
declarations and have dependencies. It's not clear to me, at what
point a certain dependency should be a service or a config. A
configuration seems to be necessary when I want to create a reasonable
XML syntax (schema) for initializing objects of this kind later on
(and even though you can make the xml for configurations look
reasonable, they remain Lists which is an artifact that impacts the
domain object model).
I feel the XML configurations lack the simplicity and consistency
that's crucial for developers to effectively use the framework. What
would have been a few simple lines of java code (not to mention a
scripting language) become tedious pages of XML. I feel HiveMind
reinvents the XML/OO binding wheel once again, estabilishes it's own
schema language, variable substitutions etc. IMHO this is a critical
issue. It would be better to promote the Java based dependency
management APIs and expose them to direct manipulation, scripting
languages and your favorite java/xml binding framework, rather than
trying to reinvent this. Madness lies this way, and you can already
see the numerous dead corpses on the roadside :) - think Jelly, the
numerous wretched xml/oo mappers that would be best to forget, etc..
Registry initialization should be more flexible and support different
deployment scenarios that are not one jar/one hivemodule. A common
real-world example is environment-specific configurations. The
approach I implemented was a custom registry initialization sequence,
that after addDefaultModuleDescriptorProvider(), finds a
"hivemind.registry" in the classpath, and loads the further
hivemodules listed there (these are simple resource URIs that look
like classpath:/com/example/foo.xml or
file:/foo/myproject/config.xml), then loads further config resources
that were programmatically added (eg. from a testcase setUp()). I feel
this should be part of the framework - if you're interested I can send
the corresponding code.
Documentation needs to be more example-based (at the least give more
guidance on where in the reference to look for things). It's a real
headscratcher to figure out some of the functionality that is clearly
there (jndi, ejb remoting, etc). Guidelines/best practices should be
focused on.
Again, don't take the above as flamebait, but as a call for discussion
and improvements :) I think for HiveMind to succeed, it needs to
provide a very solid and simple core, and focus on it's essential
strenghts.
Best regards,
Viktor
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: hivemind impressions/comments/rant
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Viktor -
~ I'd like to thank you for your comments - none of which I viewed as
anything close to a rant. Yours are the types of comments I like to see
in that you name points and express your views directly. What caught my
eye initially - and it must be saying something because it's left to
your second to the last paragraph - was the documentation. I,
personally, hate writing it - but have come to appreciate its
importance. Just yesterday I informally started my solicitation for "any
user-based examples/documentation" in order to address that very
problem. [note to users/developers - this is a semi-formal request - if
you've got anything that can be used as a basis for any kind of
_user-based_ 'how-to', documentation, examples - feel free to contact me
off-list so I can get more put together to address this issue (<rant>and
don't say "Wiki" - they're good, but shouldn't be a replacement for good
online user documentation </rant>)]. In comparing Hivemind's site
documentation to other projects', there seems to be a lack of
'start-to-finish' getting started help. I'd like to alleviate that with
any assistance available.
~ To address your 'headaches' - I have no real views either way as to
Hivemind's syntax. To say it "reinvents" might be pushing the envelope a
little. Does it have its own? Most definitely. But which "pre-existing"
wheel would one choose otherwise? To a point I suppose you could say "I
want to use X so let me use X", but there would more than likely have to
be a) a configuration for that as well and b) some sort of mapping
between 'X' and Hivemind internally for the configuration to be
meaningful. Would it be ideal to have "1" way of writing XML
configurations across the the multitude of projects that use XML
configurations? Absolutely. 1 for Spring, Hibernate, Hivemind. Life
would be truly "good". But that isn't a reality. I believe that
addressing Hivemind configurations specifically - they are relatively
short and more meaningful than they were in the past. A clear
'lifecycle' would make the API easier to use, but that takes me back to
documentation/examples.
~ (You've got me on service vs. contribution - I use what works :-( )
~ As to your point about one jar/one hivemodule - I believe this would
be best provided as a component in and of itself. Maybe I read that
wrong, but to include it in Hivemind itself would require - yet more
configuration. [Granted - providing it as a service/contribution that
was 'off' unless configured would impose no greater configuration on a
user that didn't wish to utilize it, but then we get back to
documentation - let people know it's there and how to use it]
~ I have utilized Hivemind on a few projects of moderate size and
haven't felt the pain of 'tedious pages of XML' any more with Hivemind
than I have other projects that utilize XML configurations. I work on
component pieces - both in code and configuration. Not to say it's not
an issue, just not one I'm versed enough with to have a true opinion. It
wasn't until recently that I started stepping outside of my own sandbox
where I created all classes/interfaces and started to play in Sun's (my
foray into Hivemind w/ Swing) that I truly hit the
examples/documentation issues you raised. I believe that starting there
would be the best place to remedy most user problems. Not to say it
would make Hivemind perfect - just easier to see how to do what and when
- - thereby making it easier to make decisions as to whether it fits the
bill for a given task.
~ Thank you again for your comments.
Brian
Viktor Szathmary wrote:
| Hello,
|
| as a relatively new user of HiveMind, I thought I would share my
| impressions/thoughts after applying it on a medium sized project.
| Please take this as constructive criticsm. Some of the issues are just
| part of the learning curve, some of them are due to the fact that it's
| still in it's early stages, and some of them I feel are issues with
| general approach taken.
|
| HiveMind seems to be a mixture of an IoC/dependency management
| container and a a POJO/XML data binding framework, with a bit of
| xml-based scripting thrown in. No real issues with the IoC part - the
| concept is well estabilished and I find it natural to think in these
| terms. The headaches start with the OO/XML binding framework.
|
| For simple dependencies, it's easy enough to set things up. The first
| dubious point is the distinction between services and configurations.
| IMHO this distinction really doesn't help at all: it doesn't add any
| value to introduce two concepts, where one would be sufficient. Both
| services and configurations are objects that get initialized via xml
| declarations and have dependencies. It's not clear to me, at what
| point a certain dependency should be a service or a config. A
| configuration seems to be necessary when I want to create a reasonable
| XML syntax (schema) for initializing objects of this kind later on
| (and even though you can make the xml for configurations look
| reasonable, they remain Lists which is an artifact that impacts the
| domain object model).
|
| I feel the XML configurations lack the simplicity and consistency
| that's crucial for developers to effectively use the framework. What
| would have been a few simple lines of java code (not to mention a
| scripting language) become tedious pages of XML. I feel HiveMind
| reinvents the XML/OO binding wheel once again, estabilishes it's own
| schema language, variable substitutions etc. IMHO this is a critical
| issue. It would be better to promote the Java based dependency
| management APIs and expose them to direct manipulation, scripting
| languages and your favorite java/xml binding framework, rather than
| trying to reinvent this. Madness lies this way, and you can already
| see the numerous dead corpses on the roadside :) - think Jelly, the
| numerous wretched xml/oo mappers that would be best to forget, etc..
|
| Registry initialization should be more flexible and support different
| deployment scenarios that are not one jar/one hivemodule. A common
| real-world example is environment-specific configurations. The
| approach I implemented was a custom registry initialization sequence,
| that after addDefaultModuleDescriptorProvider(), finds a
| "hivemind.registry" in the classpath, and loads the further
| hivemodules listed there (these are simple resource URIs that look
| like classpath:/com/example/foo.xml or
| file:/foo/myproject/config.xml), then loads further config resources
| that were programmatically added (eg. from a testcase setUp()). I feel
| this should be part of the framework - if you're interested I can send
| the corresponding code.
|
| Documentation needs to be more example-based (at the least give more
| guidance on where in the reference to look for things). It's a real
| headscratcher to figure out some of the functionality that is clearly
| there (jndi, ejb remoting, etc). Guidelines/best practices should be
| focused on.
|
| Again, don't take the above as flamebait, but as a call for discussion
| and improvements :) I think for HiveMind to succeed, it needs to
| provide a very solid and simple core, and focus on it's essential
| strenghts.
|
| Best regards,
| Viktor
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCgGQhaCoPKRow/gARAlJNAJ0R4vCdc4XQApcHiMhiYXNNp3vYwACgrzkn
8tTGFnAiMrL027CmIr1ZFsQ=
=kUdf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: hivemind impressions/comments/rant (caching example)
Posted by Knut Wannheden <kn...@gmail.com>.
Viktor,
(Moving this over to the dev list now...)
On 5/11/05, Viktor Szathmary <ph...@gmail.com> wrote:
>
> Knut, that does look better. Ultimately, what I'd consider a
> simple/straightforward notation for defining things would be something
> like this:
>
> <module>
> <service-point id="StoreContent"
> interface="com.freshdirect.cms.application.ContentServiceI">
> <construct class="...">
> <propertyOne>foo</propertyOne>
> <propertyTwo>bar</propertyTwo>
> ...
> </construct>
> <interceptor>
> <construct class="com.freshdirect.cms.cache.ContentCacheInterceptor">
> <cacheType>Hybrid</cacheType>
> <multicastIP>${cms.cache.multicastIP}</multicastIP>
> <lruCacheSize>10000</lruCacheSize>
> </construct>
> </interceptor>
> </service-point>
> </module>
>
> The key here is:
>
> - allow bean properties (and constructor params) to be easily bound,
> with using identically named xml elements that are automatically
> mapped. Java type declarations provide a good enough schema
> declaration, one rarely has a desire to make the xml mapping
> different.
>
I think I can see what you're getting at. I can see two problems with
this approach. First you can unfortunately not access a constructor
parameter's name using Java reflection. Thus you have to map them by
position and / or type. IMO this is one of the main disadvantages of
constructor based dependency injection. The second problem is a
restriction in HiveMind: HiveMind's schema language cannot express
that the elements can have any name (as for example RelaxNG's
<anyName>). But this is something we could look into.
There are also some other minor problems one would have to solve, but
I think this is a very interesting idea. I should also mention that it
has been proposed that the <construct> element could for simple cases
be made more succinct by encoding the nested elements into a string.
See http://issues.apache.org/jira/browse/HIVEMIND-121 and
http://thread.gmane.org/gmane.comp.jakarta.hivemind.devel/1417 if you
are interested.
> - allow nesting declarations, so I don't have to flatten out simple
> hierarchical dependencies, which i found to be very common. (of course
> a good editor tool could alleviate this, but let's not fall into this
> trap, especially considering that there are no such tools yet).
>
I can remember this being requested before. IMHO it can sometimes save
you a few lines of XML, but as soon as you want to reuse those nested
elements you will want to move them to the top level anyway. I suppose
this would be the case with your cache interceptor.
I can also see that you dropped the CacheI implementation (SwarmCache)
here. I assume this was unintentional since you mentioned the CacheI
implementation and the AOP interceptor as separate objects in your
original posting.
Thank you for your insightful comments and suggestions!
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-dev-help@jakarta.apache.org
Re: hivemind impressions/comments/rant (caching example)
Posted by Viktor Szathmary <ph...@gmail.com>.
On 5/11/05, Knut Wannheden <kn...@gmail.com> wrote:
>
> 1. You should be able to use the MethodInterceptorFactory as is. This
>
> 2. I think you could get rid of the swarmCacheConfig configuration
Knut, that does look better. Ultimately, what I'd consider a
simple/straightforward notation for defining things would be something
like this:
<module>
<service-point id="StoreContent"
interface="com.freshdirect.cms.application.ContentServiceI">
<construct class="...">
<propertyOne>foo</propertyOne>
<propertyTwo>bar</propertyTwo>
...
</construct>
<interceptor>
<construct class="com.freshdirect.cms.cache.ContentCacheInterceptor">
<cacheType>Hybrid</cacheType>
<multicastIP>${cms.cache.multicastIP}</multicastIP>
<lruCacheSize>10000</lruCacheSize>
</construct>
</interceptor>
</service-point>
</module>
The key here is:
- allow bean properties (and constructor params) to be easily bound,
with using identically named xml elements that are automatically
mapped. Java type declarations provide a good enough schema
declaration, one rarely has a desire to make the xml mapping
different.
- allow nesting declarations, so I don't have to flatten out simple
hierarchical dependencies, which i found to be very common. (of course
a good editor tool could alleviate this, but let's not fall into this
trap, especially considering that there are no such tools yet).
regards,
viktor
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: hivemind impressions/comments/rant (caching example)
Posted by Knut Wannheden <kn...@gmail.com>.
Viktor,
I think there are a few things you could simplify in your HiveMind
configuration:
1. You should be able to use the MethodInterceptorFactory as is. This
would although require you to define your AOP interceptor as a service
into which you'd inject the StoreCache service. This would relieve you
from the burden of defining a interceptor factory service, schema, and
implementation.
2. I think you could get rid of the swarmCacheConfig configuration
(and the accompanying SwarmCacheConfiguration class). The way I
understand it you only use it to capture initialization data for the
StoreCache service. This is better declared directly in the
<construct> element for the StoreCache service implementation. What
leads me to this conclusion is that you only ever expect one
contribution to this configuration. But maybe you have other good
reasons for declaring a configuration...
You'd end up with something like:
<module>
<service-point id="StoreCache" interface="com.freshdirect.cms.cache.CacheI">
<invoke-factory>
<construct class="com.freshdirect.cms.cache.SwarmCache">
<service-id/>
<set property="cacheType" value="Hybrid"/>
<set property="multicastIP" value="${cms.cache.multicastIP}"/>
<set property="lruCacheSize" value="10000"/>
<!-- you could of course also define these as constructor
parameters... -->
</construct>
</invoke-factory>
</service-point>
<service-point id="CacheInterceptor"
interface="org.aopalliance.MethodInterceptor">
<invoke-factory>
<construct class="com.freshdirect.cms.cache.ContentCacheInterceptor"/>
<!-- assuming StoreCache is autowired -->
</invoke-factory>
</service-point>
<service-point id="StoreContent"
interface="com.freshdirect.cms.application.ContentServiceI">
...
...
<interceptor service-id="hivemind.lib.MethodInterceptorFactory">
<impl object="service:CacheInterceptor"/>
</interceptor>
</service-point>
</module>
Does this look better?
--knut
On 5/11/05, Viktor Szathmary <ph...@gmail.com> wrote:
> So, the real-world example (which as I said, is hopefully a bad one :)
>
> To provide some context (this part is non-hivemind specific) and the objective:
>
> - you have a domain-specific service interface (ContentServiceI in
> this case), that you will contribute the caching interceptor to.
>
> - you have a defined a CacheI interface that provides the basic
> get/put/remove for a generic object cache (you would like to plug in
> things like hashmap/ehcache/swarmcache/your favorite).
>
> - you have an AOP-alliance style interceptor that given a CacheI
> implementation, intercepts method calls to your domain-specific
> service and makes the appropriate cache get/puts around the method
> calls (it's called ContentCacheInterceptor)..
>
> - you wrote the adapter for SwarmCache to implement CacheI.
>
> Ok, that wasn't too bad or unusually mind-boggling :) Now on to the
> hivemind-specific tasks:
>
> First, looks like you will need an interceptor factory to explain
> hivemind that your ContentCacheInterceptor instances need a CacheI as
> a dependency. The class is just a few lines, and extends
> MethodInterceptorFactory...
>
> <service-point id="ContentCacheInterceptorFactory"
> parameters-occurs="1"
> interface="org.apache.hivemind.ServiceInterceptorFactory">
> <invoke-factory>
> <construct class="com.freshdirect.cms.cache.ContentCacheInterceptorFactory" />
> </invoke-factory>
> <parameters-schema>
> <element name="cache">
> <attribute name="object" required="true" translator="object"/>
> <rules>
> <push-attribute attribute="object" />
> <invoke-parent method="addElement" />
> </rules>
> </element>
> </parameters-schema>
> </service-point>
>
> Ok fine.. Let's bind our configurations to SwarmCache... (Turns out,
> the default configuration object in SwarmCache had some warts so you
> wrote an adapter for that as well... No big deal, just a small
> distraction - but you shall blame that on SwarmCache). Let's define
> the schema for it in hivemind...
>
> <schema id="SwarmCacheConfiguration">
> <element name="cacheConfiguration">
> <attribute name="cacheType" required="true">
> <!-- LRU, Auto, Timer, Hybrid -->
> </attribute>
> <attribute name="multicastIP"/>
> <attribute name="lruCacheSize"/>
> <attribute name="timerCacheTimeout"/>
> <conversion class="com.freshdirect.cms.cache.SwarmCacheConfiguration"/>
> </element>
> </schema>
>
> Ok, now you want to have a cache configuration, like so (details about
> the symbol source definitions omited for clarity, not everyone needs
> that anyway):
>
> <configuration-point id="swarmCacheConfig" schema-id="SwarmCacheConfiguration"/>
> <contribution configuration-id="swarmCacheConfig">
> <cacheConfiguration multicastIP="${cms.cache.multicastIP}"
> cacheType="Hybrid" lruCacheSize="10000"/>
> </contribution>
>
> And finally, you'll need a SwarmCache (implements CacheI) instance
> using this configuration. Since you have decided that cache
> configuration objects should be represented as a configuration in
> hivemind, not a service (after all its just a small data carrier, no
> biz logic, etc), you'll have to modify the constructor to take a List,
> and use the one-and-only element therein. Oops.. well, you're not
> gonna backtrack now, stuff needs to get done... :)
>
> <service-point id="StoreCache" interface="com.freshdirect.cms.cache.CacheI">
> <invoke-factory>
> <construct class="com.freshdirect.cms.cache.SwarmCache">
> <string>StoreCache</string>
> <configuration>swarmCacheConfig</configuration>
> </construct>
> </invoke-factory>
> </service-point>
>
> Finally (!), you can simply apply a caching interceptor on your
> service like this:
>
> <service-point id="StoreContent"
> interface="com.freshdirect.cms.application.ContentServiceI">
> ...
> ...
> <interceptor service-id="ContentCacheInterceptorFactory">
> <cache object="service:StoreCache" />
> </interceptor>
> </serivce-point>
>
> So, perhaps I'm too lazy or perhaps missed some essential points in
> the hivemind docs, but I found this a bit more involved than I
> consider reasonable :) It works, no doubt, but was far from a "simple,
> consistent, crisp, etc" experience...
>
> regards,
> viktor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: hivemind impressions/comments/rant (caching example)
Posted by Viktor Szathmary <ph...@gmail.com>.
So, the real-world example (which as I said, is hopefully a bad one :)
To provide some context (this part is non-hivemind specific) and the objective:
- you have a domain-specific service interface (ContentServiceI in
this case), that you will contribute the caching interceptor to.
- you have a defined a CacheI interface that provides the basic
get/put/remove for a generic object cache (you would like to plug in
things like hashmap/ehcache/swarmcache/your favorite).
- you have an AOP-alliance style interceptor that given a CacheI
implementation, intercepts method calls to your domain-specific
service and makes the appropriate cache get/puts around the method
calls (it's called ContentCacheInterceptor)..
- you wrote the adapter for SwarmCache to implement CacheI.
Ok, that wasn't too bad or unusually mind-boggling :) Now on to the
hivemind-specific tasks:
First, looks like you will need an interceptor factory to explain
hivemind that your ContentCacheInterceptor instances need a CacheI as
a dependency. The class is just a few lines, and extends
MethodInterceptorFactory...
<service-point id="ContentCacheInterceptorFactory"
parameters-occurs="1"
interface="org.apache.hivemind.ServiceInterceptorFactory">
<invoke-factory>
<construct class="com.freshdirect.cms.cache.ContentCacheInterceptorFactory" />
</invoke-factory>
<parameters-schema>
<element name="cache">
<attribute name="object" required="true" translator="object"/>
<rules>
<push-attribute attribute="object" />
<invoke-parent method="addElement" />
</rules>
</element>
</parameters-schema>
</service-point>
Ok fine.. Let's bind our configurations to SwarmCache... (Turns out,
the default configuration object in SwarmCache had some warts so you
wrote an adapter for that as well... No big deal, just a small
distraction - but you shall blame that on SwarmCache). Let's define
the schema for it in hivemind...
<schema id="SwarmCacheConfiguration">
<element name="cacheConfiguration">
<attribute name="cacheType" required="true">
<!-- LRU, Auto, Timer, Hybrid -->
</attribute>
<attribute name="multicastIP"/>
<attribute name="lruCacheSize"/>
<attribute name="timerCacheTimeout"/>
<conversion class="com.freshdirect.cms.cache.SwarmCacheConfiguration"/>
</element>
</schema>
Ok, now you want to have a cache configuration, like so (details about
the symbol source definitions omited for clarity, not everyone needs
that anyway):
<configuration-point id="swarmCacheConfig" schema-id="SwarmCacheConfiguration"/>
<contribution configuration-id="swarmCacheConfig">
<cacheConfiguration multicastIP="${cms.cache.multicastIP}"
cacheType="Hybrid" lruCacheSize="10000"/>
</contribution>
And finally, you'll need a SwarmCache (implements CacheI) instance
using this configuration. Since you have decided that cache
configuration objects should be represented as a configuration in
hivemind, not a service (after all its just a small data carrier, no
biz logic, etc), you'll have to modify the constructor to take a List,
and use the one-and-only element therein. Oops.. well, you're not
gonna backtrack now, stuff needs to get done... :)
<service-point id="StoreCache" interface="com.freshdirect.cms.cache.CacheI">
<invoke-factory>
<construct class="com.freshdirect.cms.cache.SwarmCache">
<string>StoreCache</string>
<configuration>swarmCacheConfig</configuration>
</construct>
</invoke-factory>
</service-point>
Finally (!), you can simply apply a caching interceptor on your
service like this:
<service-point id="StoreContent"
interface="com.freshdirect.cms.application.ContentServiceI">
...
...
<interceptor service-id="ContentCacheInterceptorFactory">
<cache object="service:StoreCache" />
</interceptor>
</serivce-point>
So, perhaps I'm too lazy or perhaps missed some essential points in
the hivemind docs, but I found this a bit more involved than I
consider reasonable :) It works, no doubt, but was far from a "simple,
consistent, crisp, etc" experience...
regards,
viktor
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: hivemind impressions/comments/rant
Posted by Viktor Szathmary <ph...@gmail.com>.
hi,
thanks for all the comments :) i guess the discussion should be moved
to hivemind-dev, but hey, the developers read this anyway, and users
probably don't mind either..
On 5/10/05, Knut Wannheden <kn...@gmail.com> wrote:
>
> On 5/10/05, Viktor Szathmary <ph...@gmail.com> wrote:
> >
> > For simple dependencies, it's easy enough to set things up. The first
> > dubious point is the distinction between services and configurations.
> > IMHO this distinction really doesn't help at all: it doesn't add any
>
> My first impression of HiveMind was also that this dichotomy of
> services and configurations was sort of arbitrary. After all they are
> in the end both mapped to POJOs... But after using HiveMind for a
> while I got to appreciate this distinction. I define configurations
> whenever I need to provide an extension point with which other modules
> can affect the behaviour of "my" services.
based on the other comments i feel the service/configuration dichotomy
is a general point of confusion (and there's also the
parameters-schema deal which i also have some trouble placing)... i
think these concepts must be unified - it would probably simplify the
hivemind core implementation, as well as make things straightforward
for users.
don't make users run around in circular thoughts along the lines: "oh,
ok should a DataSource be service, or is it a configuration? sounds
like a config, after all it's just a jndi name based lookup, there's
usually one, no biz logic, etc.. but it doesn't make sense for my
service to depend on more than one... so it's a service... but it's a
configuration option of the app... aaaargh.. " :-)
> > I feel the XML configurations lack the simplicity and consistency
> > that's crucial for developers to effectively use the framework. What
>
> IMHO the Hivemind "module descriptor language" is very well conceived
> in that the descriptors are very concise and crisp. Yet I agree with
it is true there are worse dialects out there (i don't like the spring
notation for example), but my idea of "concise and crisp" is at least
"no more verbose than constructing the same object directly in java"
and more like "as compact as ruby/yaml"... see below for some example
config-chunk i have, perhaps there are ways to simplify.it...
> http://thread.gmane.org/gmane.comp.jakarta.hivemind.devel/1388).
> Please join in on this if you have any concrete (or vague) ideas /
> opinions on this topic.
i will try to gather some thoughts and make further posts along this line...
> > Registry initialization should be more flexible and support different
> > deployment scenarios that are not one jar/one hivemodule. A common
>
> Would it help if the META-INF/hivemodule.xml mechanism were
> supplemented with a system property defining a list of descriptor
> URIs? I would be hesitant to add another configuration file with its
> own syntax.
the sub-module syntax is close enough, though it only allows
classpath-based loading, which is not ideal for me. i wrote a
ResourceUtil class that allows this style of addressing by adding the
classpath:/foo/bar.xml notation (along with the usual url protocols).
> I'd also be interested in how your code initializes the registry.
i will send the code for dissection to hivemind-dev later.
> > Documentation needs to be more example-based (at the least give more
>
> This is definitely something we need to improve upon. There are some
I strongly suggest copy-pasted hivemodule examples from real-world
apps (rather than artificial toy examples), with some additional brief
comments/explanatio. It's also easier to add some comments to
something that works, rather than coming up with some contrived
example... toy examples should be runnable starting points/demos, the
real-world examples would provide best practices.
For starters, here are some fragments from our app's hive-config, that
provide a pluggable caching interceptor on top of a service.. I'm
actually hoping that this is a bad example and someone will point out
that I have overcomplicated things and it could have been done in 5
lines... ;) Once discussed, we can post this on the wiki as well...
------ NOTE: lengthy example follows -------
Actually, the example got so long, that I will post it separately :)
viktor
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: hivemind impressions/comments/rant
Posted by Knut Wannheden <kn...@gmail.com>.
Viktor,
First off I'd like to say that this type of constructive critisism is
most appreciated.
On 5/10/05, Viktor Szathmary <ph...@gmail.com> wrote:
>
> For simple dependencies, it's easy enough to set things up. The first
> dubious point is the distinction between services and configurations.
> IMHO this distinction really doesn't help at all: it doesn't add any
> value to introduce two concepts, where one would be sufficient. Both
> services and configurations are objects that get initialized via xml
> declarations and have dependencies. It's not clear to me, at what
> point a certain dependency should be a service or a config. A
> configuration seems to be necessary when I want to create a reasonable
> XML syntax (schema) for initializing objects of this kind later on
> (and even though you can make the xml for configurations look
> reasonable, they remain Lists which is an artifact that impacts the
> domain object model).
>
My first impression of HiveMind was also that this dichotomy of
services and configurations was sort of arbitrary. After all they are
in the end both mapped to POJOs... But after using HiveMind for a
while I got to appreciate this distinction. I define configurations
whenever I need to provide an extension point with which other modules
can affect the behaviour of "my" services.
As you say a configuration is nothing but a collection (in HiveMind
1.1 it can also be represented as a Map), but that only affects your
domain model in so far that it corresponds to a one-to-many
relationship.
> I feel the XML configurations lack the simplicity and consistency
> that's crucial for developers to effectively use the framework. What
> would have been a few simple lines of java code (not to mention a
> scripting language) become tedious pages of XML. I feel HiveMind
> reinvents the XML/OO binding wheel once again, estabilishes it's own
> schema language, variable substitutions etc. IMHO this is a critical
> issue. It would be better to promote the Java based dependency
> management APIs and expose them to direct manipulation, scripting
> languages and your favorite java/xml binding framework, rather than
> trying to reinvent this. Madness lies this way, and you can already
> see the numerous dead corpses on the roadside :) - think Jelly, the
> numerous wretched xml/oo mappers that would be best to forget, etc..
>
IMHO the Hivemind "module descriptor language" is very well conceived
in that the descriptors are very concise and crisp. Yet I agree with
you that it would be good with a Java API to let you do the same thing
in other ways (be they more verbose or more succinct). This topic is
being discussed right now on the developer mailing list (see
http://thread.gmane.org/gmane.comp.jakarta.hivemind.devel/1388).
Please join in on this if you have any concrete (or vague) ideas /
opinions on this topic.
> Registry initialization should be more flexible and support different
> deployment scenarios that are not one jar/one hivemodule. A common
> real-world example is environment-specific configurations. The
> approach I implemented was a custom registry initialization sequence,
> that after addDefaultModuleDescriptorProvider(), finds a
> "hivemind.registry" in the classpath, and loads the further
> hivemodules listed there (these are simple resource URIs that look
> like classpath:/com/example/foo.xml or
> file:/foo/myproject/config.xml), then loads further config resources
> that were programmatically added (eg. from a testcase setUp()). I feel
> this should be part of the framework - if you're interested I can send
> the corresponding code.
>
Would it help if the META-INF/hivemodule.xml mechanism were
supplemented with a system property defining a list of descriptor
URIs? I would be hesitant to add another configuration file with its
own syntax.
I'd also be interested in how your code initializes the registry.
> Documentation needs to be more example-based (at the least give more
> guidance on where in the reference to look for things). It's a real
> headscratcher to figure out some of the functionality that is clearly
> there (jndi, ejb remoting, etc). Guidelines/best practices should be
> focused on.
>
This is definitely something we need to improve upon. There are some
good examples on the HiveMind site. I think we should promote these to
the front page (even in front of the reference documentation) and
enrich them with links to specific pages in the reference works. Other
thoughts.
Regards,
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org