[ http://opensource.atlassian.com/projects/xdoclet/browse/XDT-1621?page=comments#action_17547 ]
R. Lemos commented on XDT-1621: ------------------------------- Hold on. It is not working so perfectly. The "pattern" attribute (in the "homeinterface" subtask), albeit being a simple immutable String, sticks to the first - not last, as expected - configuration ever seen. I'm still working on this, but would appreciate any help. 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
