Clifton C. Craig, Software Engineer Intelligent Computer Systems - A Division of GBG 2101 Embassy Drive Lancaster, PA 17603
Phone: 717-295-7977 ext. 621 Fax: 717-295-7683 [EMAIL PROTECTED] [EMAIL PROTECTED]
Clifton C. Craig wrote:
Alright, I think I found the problem but I can't see an easy solution here. The problem lies in the forAllMembers method in the AbstractProgramElementTagsHandler in the XDoclet source tree. As it iterates over each member in the forAllMethods tag it sets the class context of the body to the containing class. So as it descends into base classes they become the current class of the body's content. A simple solution would be to add a flatten attribute to these tags such that it would treat all parent class members as if they were to appear in the current class. See the following code in question:
for (Iterator j = members.iterator(); j.hasNext(); ) { XMember member = (XMember) j.next();
switch (forType) { case FOR_FIELD: setCurrentField((XField) member); break; case FOR_CONSTRUCTOR: setCurrentConstructor((XConstructor) member); break; case FOR_METHOD: setCurrentMethod((XMethod) member); break; default: throw new XDocletException("Bad type: " + forType); }
setCurrentClass(member.getContainingClass()); generate(template); } setCurrentClass(currentClass);
My revision would be as follows assuming flattenHierarchy is a method local boolean initialized from an equivalent tag attribute:
for (Iterator j = members.iterator(); j.hasNext(); ) { XMember member = (XMember) j.next();
switch (forType) { case FOR_FIELD: setCurrentField((XField) member); break; case FOR_CONSTRUCTOR: setCurrentConstructor((XConstructor) member); break; case FOR_METHOD: setCurrentMethod((XMethod) member); break; default: throw new XDocletException("Bad type: " + forType); }
if(false==flattenHierarchy) setCurrentClass(member.getContainingClass());
generate(template);
}
if(false==flattenHierarchy) setCurrentClass(currentClass);
This makes sense but seems impractical to do as it would involve either hacking XDoclet's source or re-implementing the whole dang class, packaging and registering it at generation time. Can somebody suggest a more practical solution here? My brain is frazzled!
Clifton C. Craig, Software Engineer Intelligent Computer Systems - A Division of GBG 2101 Embassy Drive Lancaster, PA 17603
Phone: 717-295-7977 ext. 621 Fax: 717-295-7683 [EMAIL PROTECTED] [EMAIL PROTECTED]
Clifton C. Craig wrote:
Hello,
I'm having a terrible time trying to globally specify transactional attributes for the getDXO (gets the Data Object) method in all my entity beans. They all extend my base entity bean class and none of them override this method. If I put the @ejb.transaction in the base class XDoclet picks it up in the template includes it for each of my entity beans but it incorrectly includes the name of the base class in the <ejb-name> element. Now what I end up with is this:
<container-transaction >
<method >
<ejb-name>com.icsaward.award.server.eb.state.State</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
<container-transaction >
<method >
<ejb-name>ICSBaseEntityBean</ejb-name>
<method-intf>Local</method-intf>
<method-name>getDXO</method-name>
<method-params>
</method-params>
</method>
<trans-attribute>Supports</trans-attribute>
</container-transaction>
It's all caused by this part of the template:
<XDtEjb:forAllBeans>
<XDtEjb:ifIsAConcreteEJBean>
<XDtClass:forAllClassTags tagName="ejb:transaction">
<container-transaction <XDtId:prefixedId prefix="MethodTransaction"/>>
<method <XDtId:prefixedId prefix="MethodElement"/>>
<ejb-name><XDtEjb:ejbName/></ejb-name>
<XDtClass:ifHasClassTag tagName="ejb:transaction" paramName="method-intf">
<method-intf><XDtClass:classTagValue tagName="ejb:transaction" paramName="method-intf" values="Home,Remote,LocalHome,Local"/></method-intf>
</XDtClass:ifHasClassTag>
<method-name><XDtClass:classTagValue tagName="ejb:transaction" paramName="method-name" default="*"/></method-name>
</method>
<trans-attribute><XDtClass:classTagValue tagName="ejb:transaction" paramName="type"/></trans-attribute>
</container-transaction>
</XDtClass:forAllClassTags>
<XDtMethod:forAllMethods>
<XDtMethod:ifHasMethodTag tagName="ejb:transaction">
<XDtEjbIntf:ifIsInterfaceMethod>
<XDtEjbIntf:forAllInterfaceViewTypes>
<container-transaction <XDtId:prefixedId prefix="MethodTransaction"/>>
<method <XDtId:prefixedId prefix="MethodElement"/>>
<ejb-name><XDtEjb:ejbName/></ejb-name>
<method-intf><XDtEjbIntf:methodIntf/></method-intf>
<method-name><XDtEjbIntf:interfaceMethodName/></method-name>
<method-params>
<XDtParameter:forAllMethodParams>
<method-param><XDtParameter:methodParamType/></method-param>
</XDtParameter:forAllMethodParams>
</method-params>
</method>
<trans-attribute><XDtMethod:methodTagValue tagName="ejb:transaction" paramName="type"/></trans-attribute>
</container-transaction>
</XDtEjbIntf:forAllInterfaceViewTypes>
</XDtEjbIntf:ifIsInterfaceMethod>
</XDtMethod:ifHasMethodTag>
</XDtMethod:forAllMethods>
</XDtEjb:ifIsAConcreteEJBean>
</XDtEjb:forAllBeans>
The context gets set to the base entity bean when it iterates over all the methods and as a result the ejbName tag returns the base class name instead of the current class. I've tried using the concreteFullClassName tag in the template hoping that it would pull in the name of the concrete class instead of its ancestor but that didn't work. I'm sure this is a common problem but I'm stuck. What is the work-around?
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
