Hi,
I am following the discussion and it all makes a lot of sense, still
have to think more though...
Anyway, there is one place I can help you : the Dao generation.
I am doing (almost) all what you say for DAO generation in BMP.
First I find my DAO:
public void setEntityContext(EntityContext ctx){
if (cat.isDebugEnabled()) cat.debug("setEntityContext()");
// Get DAO class
dao = getDAO();
dao.init(this);
}
It is hardcoded but could be automated as well by xdoclet
I still to refactor so that the init() command could disappear should be
done inside the getDao(EntitySupport es)
It is only there for the DAO to have the callback to the entity.
My getDao is xdoclet generated:
/**
* @hm:dao-method
*/
protected abstract PurRequisitionDAO getDAO();
I don't use a factory but a deployment specific to define my DAO : an
ejb-ref entry to define my specific DAO (and using merge feature to
change it in different implementations)
@ejb:env-entry name="mydao" value="com.abc.dao.ForumJDBCDAO"
type="java.lang.String"
In entitybmp-custom I generated it like this:
<XDtMethod:forAllMethods>
<XDtMethod:ifHasMethodTag tagName="hm:dao-method">
<XDtMethod:forAllMethodTags tagName="hm:dao-method">
protected <XDtMethod:methodType/> getDAO()
{
String EJB_NAMESPACE="java:comp/env/";
<XDtMethod:methodType/> dao=null;
Object ref=null;
try{
javax.naming.InitialContext ctx=new
javax.naming.InitialContext();
ref=ctx.lookup(EJB_NAMESPACE+"mydao");
String daoStr =(String)
javax.rmi.PortableRemoteObject.narrow(ref,String.class);
// this last line is BS now I look again at my code :(
dao =
(<XDtMethod:methodType/>)Class.forName(daoStr).newInstance();
return dao;
}catch(javax.naming.NamingException e){
cat.error("Naming Exception on "+daoName,e);
return null;
}catch(Exception e){
cat.error("Exception on "+daoName,e);
return null;
}
}
</XDtMethod:forAllMethodTags>
</XDtMethod:ifHasMethodTag>
</XDtMethod:forAllMethods>
The DAO is defined as an attribute of the entity :
protected PurRequisitionDAO dao;
(with a common interface to different DAO implementations)
Then all commons "dao'ted" methods are xdoclet-generated, I define a
method in my entity bean :
/**
* Find a PR using its Reference
* @hm:dao-call name="findByReference"
*/
public abstract Collection ejbFindByReference(String reference)
throws FinderException;
Same for ejbLoad, fbpk, ..... Eaaaaaaasy :)
And it is generated using this piece of code :
<XDtMethod:forAllMethods>
<XDtMethod:ifHasMethodTag tagName="hm:dao-call">
<XDtMethod:forAllMethodTags tagName="hm:dao-call">
public <XDtMethod:methodType/>
<XDtMethod:methodName/>(<XDtParameter:parameterList/>)
<XDtMethod:exceptionList/>{
if (cat.isDebugEnabled())
cat.debug("<XDtMethod:methodName/>()");
return dao.<XDtMethod:methodTagValue tagName="hm:dao-call"
paramName="name"/>(<XDtParameter:parameterList
includeDefinition="false"/>);
}
</XDtMethod:forAllMethodTags>
</XDtMethod:ifHasMethodTag>
</XDtMethod:forAllMethods>
So really what differs from your approach is the DAO factorization.
Mine is deployment specific, yours is runtime specific.
So yours is better and I will try to see how to xdoclet it. A default
env-entry based implementaion will be used and could be extends to
implements specifics.
Then since it seems all this makes sense, I will make it part of xdoclet
if there are any objections (using an entitybmp-dao.j merging)
Regards,
Vincent.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Rickard
> Sent: mardi 18 décembre 2001 1:24
> To: [EMAIL PROTECTED]
> Cc: Ara Abrahamian; [EMAIL PROTECTED]
> Subject: Re: [Xdoclet-user] Entity BMP, EJB2.0
>
>
> J. Matthew Pryor wrote:
>
> > Care to share any further insights about your approach?
>
>
> I have a few more notes that might be useful to you.
>
> Each entity is an XDoclet-enabled abstract bean that extends
> a generic
> base class EntitySupport. In the implementation of ejbLoad() in
> EntitySupport I have this:
> public void ejbLoad() throws EJBException, RemoteException
> {
> dao.load();
> }
> i.e. the load behaviour is delegated to a DAO object. The DAO is
> reponsible for the mapping between the instance and
> persistent storage.
> The DAO object is inited in setEntityContext(), also in EntitySupport
> since it is generic:
> public void setEntityContext(EntityContext aContext) throws
> EJBException, RemoteException
> {
> ctx = aContext;
> dao = DAOFactoryBuilder.getFactory().getDAO(this);
> }
> By having a factory for the factory I can have multiple
> strategies for
> persistence and simply choose by setting the right factory to be
> returned from getFactory(). Currently I have JDBC, XML, and CMP (i.e.
> the DAO does nothing). JDBC is for production, XML is for development
> and testing, and CMP is for the cases where a CMP engine can
> take care
> of things. I can easily extend this list by making new DAO's
> and a new
> factory for them, and this without having to change my code at all.
>
> As you can see the DAO object is associated with the instance in the
> getDAO() call, so there's no need to pass it in during load()
> invocations.
>
> The DAO is also responsible for the finders, so right now I
> have 4 DAO
> classes per entity: a base class with abstract finder
> methods, and one
> for each persistence method with concrete invocations of the finder
> methods. In my entitybeans finder methods I can then do like this:
> /**
> *
> */
> public ForumPK ejbFindByPrimaryKey(ForumPK id)
> throws FinderException
> {
> return (ForumPK)((ForumDAO)dao).findByPrimaryKey(id);
> }
> i.e. I cast the DAO to the entity-specific base class, and
> invoke the
> finder on it. This invokes either JDBCForumDAO.findByPrimaryKey() or
> XMLForumDAO.findByprimaryKey() (the CMP case won't call the beans
> ejbFindByPrimaryKey method in the first place).
>
> By doing this I can begin coding a new entity with an XML DAO
> implementation, which is useful because everything ends up in
> readable
> and editable XML files. When it is tested, I code the JDBC
> DAO, and test
> it for stability only (feature tests have been done with XML
> already),
> and use that for production.
>
> In this way I get the rapid development style of using XML, and the
> scalability and transactional features of using JDBC.
>
> Makes sense?
>
> /Rickard
>
> --
> Rickard Öberg
> Chief Architect, TheServerSide.com
> The Middleware Company
>
>
> _______________________________________________
> Xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
>
>
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
