[ http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1621?page=comments#action_17554 ]
R. Lemos commented on XDT-1621: ------------------------------- Regarding this latter bug (the "pattern" attribute issue), I've found that it's due to the way xdoclet works internally. The generation engine is template driven only. I mean, when a template is running and needs to know some value (for example, the home class name of some entity bean), that one will be reconstructed every time. So, as this value may be affected by the "pattern" attribute (and others), as in the case of "home class name of some entity bean", this pattern is looked for over and over again (beans with declared home class name or home class pattern set aside). The best correction for this bug would need a complete rewrite of xdoclet, in a sense that some model should be created in memory beforehand. The templates should only query this fixed model. Since a complete rewrite of xdoclet is out of scope of this simple bug (introduced by me, by the way), I think it is just better to document this anywhere (here, as I am doing ;-) and to avoid using "pattern" attributes (and alike) with this new "multiple invocation of same task" feature. Or just use it when they are all equal in all invocations of the same subtask type. R. Lemos > Can't use the same subtask twice within a single run > ---------------------------------------------------- > > Key: XDT-1621 > URL: http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1621 > Project: XDoclet > Type: Bug > Components: Core > Versions: 1.2.3 > Reporter: R. Lemos > Assignee: xdoclet-devel (Use for new issues) > > > Consider an EJB Application having a couple of beans that are arranged in two > ejb-jar modules, and then packaged into one ear (enterprise application > archive). > In this setup, two deployment descriptors need to be generated. It is > possible to generate a descriptor for some beans, thanks to the > havingClassTag attribute. So one could configure xdoclet this way: > <ejbdoclet ...> > . > . > <deploymentdescriptor destdir="deployment/moduleXXX/META-INF" > havingClassTag="module.XXX"/> > </ejbdoclet> > So far so good. This snippet should be repeated two times for the two ejb-jar > modules. > The problem arises when the project grows in number of classes and, worse, > number of EJB modules. Multiple invocations of ejbdoclet inccurs in thousands > of java source files been read and analysed. > A simple workaround could be one single run of xdoclet with multiple > invocations of a subtask: > <ejbdoclet ...> > . > . > <deploymentdescriptor destdir="deployment/moduleA/META-INF" > havingClassTag="module.A"/> > <deploymentdescriptor destdir="deployment/moduleB/META-INF" > havingClassTag="module.B"/> > </ejbdoclet> > But this won't work since the subtasks are created in advance, when xdoclet > modules are registered [EMAIL PROTECTED] > xdoclet.DocletTask#registerModules()]. After that, each invocation will get > the same subtask object [EMAIL PROTECTED] > xdoclet.DocletTask#createDynamicElement()], and it will be reconfigured over > and over again. The result will be a kind of a merge of definitions, with the > former attributes being overwritten by the latter. > I propose a patch by which the subtasks retrieved are cloned before being > configured. This way, the subtask map populated in registerModules() is kept > "clean" (of configuration attributes), and each invocation will get its own > instance. > Each (well, actually not all of them) subclass of xdoclet.SubTask should have > its clone method overridden, to clone the fields that are mutable objects. > The patch that corrects the bug for the ejb deployment and home and business > interfaces follows: > --------------------------- cut here --------------------------- > diff -Naur xdoclet-1.2.3-original/core/src/xdoclet/DocletTask.java > xdoclet-1.2.3/core/src/xdoclet/DocletTask.java > --- xdoclet-1.2.3-original/core/src/xdoclet/DocletTask.java 2005-04-15 > 21:01:51.000000000 -0300 > +++ xdoclet-1.2.3/core/src/xdoclet/DocletTask.java 2006-03-30 > 13:10:20.000000000 -0300 > @@ -342,6 +342,8 @@ > if (subTask == null) { > throw new > BuildException(Translator.getString(XDocletMessages.class, > XDocletMessages.CREATE_TASK_ERROR, new String[]{name, getTaskName()})); > } > + subTask = (SubTask) subTask.clone(); > + > subTasks.add(subTask); > return subTask; > } > diff -Naur xdoclet-1.2.3-original/core/src/xdoclet/SubTask.java > xdoclet-1.2.3/core/src/xdoclet/SubTask.java > --- xdoclet-1.2.3-original/core/src/xdoclet/SubTask.java 2004-10-10 > 20:27:50.000000000 -0300 > +++ xdoclet-1.2.3/core/src/xdoclet/SubTask.java 2006-03-30 12:55:06.000000000 > -0300 > @@ -28,7 +28,7 @@ > * @created June 16, 2001 > * @version $Revision: 1.75 $ > */ > -public abstract class SubTask extends DocletSupport implements Serializable > +public abstract class SubTask extends DocletSupport implements Serializable, > Cloneable > { > private XJavaDoc _xJavaDoc; > @@ -225,4 +225,14 @@ > { > return _xJavaDoc; > } > + > + protected Object clone() { > + try { > + SubTask clone = (SubTask) super.clone(); > + clone.configParams = (ArrayList) > clone.configParams.clone(); > + return clone; > + } catch (CloneNotSupportedException e) { > + return null; > + } > + } > } > diff -Naur xdoclet-1.2.3-original/core/src/xdoclet/TemplateSubTask.java > xdoclet-1.2.3/core/src/xdoclet/TemplateSubTask.java > --- xdoclet-1.2.3-original/core/src/xdoclet/TemplateSubTask.java > 2005-04-15 21:01:51.000000000 -0300 > +++ xdoclet-1.2.3/core/src/xdoclet/TemplateSubTask.java 2006-03-30 > 13:03:25.000000000 -0300 > @@ -66,7 +66,7 @@ > * @see #setExtent(TemplateSubTask.ExtentTypes) > * @see #getExtent() > */ > - private List ofType = new ArrayList(); > + private ArrayList ofType = new ArrayList(); > /** > * You can control the extent in which the type search occurs. Valid > values are: <i>concrete-type</i> , <i> > @@ -900,4 +900,11 @@ > this.type = type; > } > } > + > + protected Object clone() { > + TemplateSubTask clone = (TemplateSubTask) super.clone(); > + clone.ofType = (ArrayList)clone.ofType.clone(); > + clone.packageSubstitutions = (ArrayList) > clone.packageSubstitutions.clone(); > + return clone; > + } > } > --------------------------- cut here --------------------------- > Note that this patch will correct the bug for other subtasks as well (in > fact, any subclass whose fields are immutable objects will be correctly > cloned). > Thanks > R. Lemos -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/xdoclet/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ xdoclet-devel mailing list xdoclet-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
