hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: Help with Interfaces and services
Date Wed, 20 Jul 2005 15:34:04 GMT
So, let me get this straight.  You have one DAO implementation class that
basically acts upon a single persistent object.  So, your application is
okay with only being able to operate upon a single persistent object per
thread (you are using a threaded model for your persistent objects)?  What I
would do is make my DAOs threaded and have HiveMind inject a fresh
persistent object into the DAO when it instantiates them...

<implementation service-id="CategoryDAO">
    <construct class="com.myco.dao.BaseDAO">
      <set-object property="persistentObject"
value="instance:com.myco.domain.Category" />

Does that make sense to you?  By the way, why are you writing a CRUD
framework and not using one that's pre-built for you (such as JDO or
Hibernate)?  In my experience, it's just easier to go with an existing
framework.  They've already encountered all of the pitfalls that you are
going to encounter by trying to write it on your own.  

-----Original Message-----
From: Vinicius Carvalho [] 
Sent: Wednesday, July 20, 2005 10:47 AM
Subject: Re: Help with Interfaces and services

Well I'm building a CRUD framework based on Tapestry 4, Hivemind,
HiveUtils, AspectWerkz and Java 5 :D. I hope It will be a LGPL
framework one day.

So here's the point:
I have only one single DAO class on the entire framework (we already
succesfully use this approach with spring here)
On spring we create as many DAO beans as we want, they are all from
the same type, but differ on their pojo injections. So ProductDAO and
CategoryDAO would be the same the only difference is that one gets
Product injected while the other gets Category, got it ;)

I'm trying to get rid of Spring (please don't understand it wrong, I
love Spring, but I think Hivemind could handle the problem, so no need
for spring).

Hence the need to have my persistent pojos managed by hivemind :D

PS: I chose AspectWerkz for the same reason, we used SpringAOP on our

On 7/20/05, James Carman <> wrote:
> Why would you have HiveMind manage your persistent objects?
> -----Original Message-----
> From: Vinicius Carvalho []
> Sent: Tuesday, July 19, 2005 8:20 PM
> To:
> Subject: Help with Interfaces and services
> Hello there! I was doing some tests here and found out that even
> though hivemind no longer requires a interface I can't cast a service
> to it's implementation class. Someone please correct me here.
> I have this scenario:
> <service-point id="produto"
>         <create-instance class="com.cs.model.persistence.Produto"
> model="threaded"/>
> </service-point>
> <service-point id="categoria"
> interface="com.cs.model.persistence.BaseEntity">
>         <create-instance class="com.cs.model.persistence.Categoria"
> model="threaded"/>
> </service-point>
> Well those are not "real" services, they're only persistent pojos that
> I need hivemind to control for me (inject on my DAOs)
> Well, So I got this test case ok:
> public class ProdutoServiceTest extends HiveMindTestCase {
>         private Registry registry;
>         @Override
>         protected void setUp() throws Exception {
>                 registry = buildFrameworkRegistry("/conf/hivemodule.xml");
>         }
>         public void testInsert() throws Exception{
>                 IProduto produto = (Produto)
> registry.getService("com.cs.tcrud.produto",BaseEntity.class);
>         }
> Well I get an ClassCastException at this point. Well I know program to
> interface is a good practice, but what about some implementation
> specific methods? I'm 100% sure I'm doing something wrong ;) Could
> someone give me a help on this?
> Thanks
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message