Hi Richard,
before you start programming too much, maybe you should contact Maxim
Petrashev who has tried to solve the same problem (see attached email
message).
Could you talk to him, find out if he has discussed this subject on the
XDoclet list and come back with a unified opinion about what is the best
thing to do?
Thanks a lot...
Matthias B.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Richard Kunze
> Sent: Tuesday, May 27, 2003 6:39 PM
> To: [EMAIL PROTECTED]
> Subject: [Andromda-devel] Re: [Andromda-user] Is anybody
> using the EJB cartridge?
>
>
> On Tuesday 27 May 2003 18:50, Matthias Bohlen wrote:
> > Hi Richard,
> >
> > yes, we are really using it.
> >
> > The trick is: XDoclet does not know at all about the *Impl classes.
> > Look at the build.xml file in the car-rental-system sample.
> We "patch"
> > the deployment descriptor with a <replace> task in Ant.
> This requires
> > a naming convention: Session beans must be named "Service"
> at the end.
> > See our web pages for details.
>
> Argh. That's ugly :-/ Especially so because you lose the
> ability to manually
> override/add xdoclet tags in the *BeanImpl class.
>
> > Cheers...
> > Matthias
> >
> > P.S.: If you know a nice way to make XDoclet accept the
> *Impl classes,
> > we'll throw away the ugly patch.
>
> I think I know a way - but unfortunately, it involves writing
> new XDoclet EJB
> templates. Well, I guess I'll bite the bullet and change the existing
> templates so that they use tag inheritance everywhere. If I'm
> lucky, the
> XDoclet folks accept them for the standard distribution. If
> not, I'll simply
> include the changed XDoclet templates in my AndoMDA cartridge
> and tell people
> to put the AndroMDA cartridge on the XDoclet classpath first
> in order to
> override the standard XDoclet templates.
>
> In any case, expect a (much improved, IMO :-) new EJB
> cartridge sometime
> within the next couple of weeks (I know, I've said that
> before - but I didn't
> plan on having to write a second set of templates :-)
>
> Bye,
>
> Richard
> --
> Richard Kunze
>
> [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
> Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, [EMAIL PROTECTED]
--- Begin Message ---
Title: Nachricht
|
Hi
Maxim,
thanks for your analysis about this subject. I have got two
questions:
* Did
you analyze XDoclet tag inheritance? Did'nt it work?
* Did
you discuss your solution on the XDoclet mailing list?
Cheers...
Matthias
Hello, Matthias.
Hope you are online...
I looked on car-rental-system sample and on
XDoclet.
1. XDoclet haven't support for define
custom-template for value which we have to put in
<ejb-class>-tag.
But this library have template for
ejb-jar.xml (file ejb-body.xdt ) in which there is the following
code:
<ejb-class><XDtEjb:concreteFullClassName/></ejb-class>
In transformation
time engine will call xdoclet.modules.ejb.EjbTagsHandler.concreteFullClassName-method:
public String
concreteFullClassName() throws XDocletException
{
if
(SessionTagsHandler.isSession(getCurrentClass()))
{
if
(DocletContext.getInstance().isSubTaskDefined(DocletTask.getSubTaskName(SessionSubTask.class)))
{
return
SessionTagsHandler.getSessionClassFor(getCurrentClass());
}
else
{
return
getCurrentClass().getQualifiedName();
}
}
else if
(BmpTagsHandler.isEntityBmp(getCurrentClass()))
{
if
(DocletContext.getInstance().isSubTaskDefined(DocletTask.getSubTaskName(EntityBmpSubTask.class)))
{
return
BmpTagsHandler.getEntityBmpClassFor(getCurrentClass());
}
else
{
return
getCurrentClass().getQualifiedName();
}
}
else if
(CmpTagsHandler.isEntityCmp(getCurrentClass()))
{
if
(DocletContext.getInstance().isSubTaskDefined(DocletTask.getSubTaskName(EntityCmpSubTask.class)))
{
return
CmpTagsHandler.getEntityCmpClassFor(getCurrentClass());
}
else
{
return
getCurrentClass().getQualifiedName();
}
}
else if
(MdbTagsHandler.isMessageDriven(getCurrentClass()))
{
return
MdbTagsHandler.getMessageDrivenClassFor(getCurrentClass());
}
else
{
return
null;
}
}
In general this code will return
return getCurrentClass().getQualifiedName();
We can't change behavior of this
method by setting of properties for instance of this
class.
But we can define in xdoclet.xml our
class, which inherit from EjbTagsHandler and override method
concreteFullClassName. In this method we can ask attribute "ejb-class" and if
it not null then return one, else return
super.concreteFullClassName.
In this case andromda can generate
source for Impl-class or bean class with xdoclet-tag ejb.bean with parameter
"ejb-class". It will be enough.
Example:
Before:
* @ejb.bean name="Administrator"
type="CMP" cmp-version="2.x"
*
local-jndi-name="org.andromda.samples.carrental.admins/Administrator/LocalHome"
*
jndi-name="org.andromda.samples.carrental.admins/Administrator/Home"
*
view-type="both"
*
primkey-field="id"
after:
* @ejb.bean name="Administrator"
type="CMP" cmp-version="2.x"
ejb-class="AdministratorBeanImpl"
*
local-jndi-name="org.andromda.samples.carrental.admins/Administrator/LocalHome"
*
jndi-name="org.andromda.samples.carrental.admins/Administrator/Home"
*
view-type="both"
*
primkey-field="id"
Other way - create own ejb-body.xdt - file (template file for
ejb-jar.xml) and do something the same...
I think 1st way (create child-class from
xdoclet.modules.ejb.EjbTagsHandler and
re-config xdoclet.xml) is very simple and enough clean.
Best regards,
Maxim
|
--- End Message ---
