Home >> All

•	xdoclet.ant.* (6)	•	xdoclet.ejb.* (1)	•	xdoclet.jmx.* (1)
•	xdoclet.loader.* (7)	•	xdoclet.modules.* (195)	•	xdoclet.retest.* (86)
•	xdoclet.tagshandler.* (17)	•	xdoclet.template.* (6)	•	xdoclet.test.* (2)
•	xdoclet.util.* (7)	•	xdoclet.web.* (1)

• xdoclet: Javadoc index of package xdoclet.


Package Samples:

• xdoclet.modules.jboss.ws
• xdoclet.modules.jboss.net
• xdoclet.ant.modulesbuilder
• xdoclet.ant
• xdoclet.loader
• xdoclet.tagshandler
• xdoclet.template
• xdoclet.util
• xdoclet.retest.bean.ejb.base
• xdoclet.retest.bean.ejb.ejb
• xdoclet.retest.ref.ejb.ejb
• xdoclet.retest.ref.ejb.interfaces
• xdoclet.retest.test.ejb
• xdoclet.retest.test
• xdoclet.retest.util
• xdoclet.retest
• xdoclet.test.xdoclet
• xdoclet.test
• xdoclet.modules.apache.axis.ejb
• xdoclet.modules.apache.bsf

Classes:

• WebSphereWebXmlSubTask: Generates WebSphere specific deployment descriptors for Web modules. The following files are generated: ibm-web-bnd.xmi and ibm-web-ext.xmi. NOTE: Since the WebSphere specific deployment descriptors depend on that id's are set in the web.xml file you must genererate it with useIds set to true, e.g. <deploymentdescriptor useIds="true"/> . This Ant task defines the following attributes (the rest of the attributes in the list below comes from its baseclass): virtualHostName reloadInterval reloadingEnabled defaultErrorPage additionalClassPath fileServingEnabled directoryBrowsingEnabled serveServletsByClassnameEnabled ...
• XDocletMessages: All messages resource keys should be defined in a Messages class, per package, as constants. The class is named like this: XDocletMessages, or XDocletEjbDdMessages, i.e. full package name prefixed (making pointing to them easier). They should not be referenced literally in any place, because it's easy to misspell it. Using Messages class means this possibility is zero. Another benefit is that wherever you need to reference a resource key from another package, you just use a phrase like xdoclet.ejb.Messages.class and not the literal, and that means if we refactor the code (change packages) a refactoring ...
• EntityBmpSubTask: Creates "entity bean classes" for BMP entity EJBs. The classes are derived from the abstract entity bean class. Attention: To give the developer more control over when the EJB becomes dirty (data changed) there is now a method called "makeDirty()" in the generated wrapper class. To use this please add to your EJB an abstract method called "makeDirty" and call it when you change data w/o using the setter methods. As example you could store the Data Object instead of storing all the attributes one by one (be aware that you have to clone the data object before storing to avoid side effects).
• WebSphereSubTask: Generates WebSphere specific deployment descriptors for EJB modules. The following files are generated: ibm-ejb-jar-bnd.xmi, ibm-ejb-jar-ext.xmi and Schema.dbxmi. NOTE: Since the WebSphere specific deployment descriptors depend on that id's are set in the ejb-jar.xml file you must genererate it with useIds set to true, e.g. <deploymentdescriptor useIds="true"/> . This Ant task defines the following attributes (the rest of the attributes in the list below comes from its baseclass): datasource currentBackendId
• ReplaceCopy: Extension of Ant's Copy task that uses XDoclet's template engine to copy instead of Ant's plain copy. It will scan each file for occurrences of <XDtAnt:property name="some.ant.property"/> and replace them with the associated Ant property value. This is similar to using the standard <copy> Ant built-in task with a nested <filterset> element, but this task uses a pull mechanism (ant properties are pulled from the ant environment by the copied files) instead of a push mechanism (where Ant pushes explicit values into the copied files).
• ReturnObjectList: Holds a list of objects which are used when returning objects from a method. For ever sucessive call to next the next object in the list will returned. When there are no more objects in the list, either an assertion error will be thrown - if the last object should not be reused the last object that was in the list will be returned - if the last object should be reused If the verify method is called and there are objects still in the list an assertion error will be thrown.
• ExternalizerSubTask: Externalizes key-value paired tags to whatever configured file (be it xml or properties file). It's useful for simple key-value properties or xml files. For now only properties files are supported. It supports i18n and l10n, so generated files follow java.util.ResourceBundle naming convention. Parameters "language", "country" and "variant" are reserved and used for this purpose.
• TemplateParser: Subclass of Template Engine that do not generate anything but only parse the document. The TagHandlers have a callback entry to this method to set in it anything they want to. This class was introduced for parsing .j files and return a list of merge files needed for the generation. The timestamp checking can then verify all files involved in a generation and bypass the generation if -nothing has changed-.
• SubTask: An abstract base class for all sub-tasks. Common code and the contract is defined here. Because of the way Ant is designed all setter methods automatically are settable config parameters. Note that by default init() method inherits default setting from the containing task via DocletContext. Setter methods in sub-task gives the user finer control over config parameters of the sub-task.
• JBossXmlServiceTemplateSubTask: Generates a {servicefile}-service.xml file for JBoss mbean configuration. This can help you see what you can set in an mbean, you can just fill in your values and deploy. Currently there is a limitation that only managed attributes with getters show up in the results, however there is a comment for those with only a setter. It treats read-only managed attributes as if they can be written.
• JBossXmlDocSubTask: Generates a skeleton {0}-service.xml file for JBoss mbean configuration. This can help you see what you can set in an mbean, you can just fill in your values and deploy. Currently there is a limitation that only managed attributes with getters show up in the results, however there is a comment for those with only a setter. It treats read-only managed attributes as if they can be written.
• TemplateEngine: The default template engine used by derived SubTasks. It looks for XML-ish strings, just like JSP tag libraries. There's no support for scriptlets, because it's cleaner to use and implementing the XML-ish tags is easy, they are not heavyweight like jsp taglib implementations and there's no need for something like taglib.tld.
• StrutsFormSubTask: Generates a Struts ActionForm, based on an entity EJB. More information on Struts is available on the Struts website , or the ActionForm API .
• ActionFormSubTask: Generates a Struts ActionForm, based on a POJO. More information on Struts is available on the Struts website , or the ActionForm API .
• ModulesGrandBuilderTask: Loops over all modules and builds each one. It builds modules the module depends on first. The module dependency is specified in a module.xml file in the root of each module. It's based on Ant's dependency checking code. Refer to that code for more details.
• InfoSubTask: Extracts tag values from classes and method docs and generates an HTML report that summarizes all occurrences of this tag in a source tree. This task can be used to generate TODO lists or any list with metrics about the occurrence of a certain tag.
• ConfigParameter: Allows to set configuration parameters that will be included in the element as attribute value pair. The following input <configParam name="foo" value="bar"/> will give <foo>bar</foo>
• HibernateCfgSubTask: Generate the hibernate.cfg.xml file. It lists all of the properties as well as a property for each hbm.xml file. This file can be used for creating and installing a SessionFactory in JNDI as well as launching Hibern8IDE.
• DataObjectSubTask: Creates "data objects" for Entity EJBs. This task is currently being deprecated in favour of Value Object which is more powerful in terms of relationships (1-1, 1-n and n-m).
• XmlValidator: This handler implementation is capable of providing dtds from a local storage instead of accessing them over the net. Further, it will throw an exception if the parsed xml is not acording to the DTD it specifies.
• TranslatorTagsHandler: Wrapper around the xdoclet.util.Translator , allowing text in generated files to be localised using the resource bundles generated by the externalizer subtask.
• TagDefTagsHandler: The implementation of TagDef template tag. It's mainly designed for use by end users that want to define template tags of their own but don't want to touch xdoclet's tag mapping file and modify the jar file.

Home | Contact Us | Privacy Policy | Terms of Service