- This topic has 6 replies, 4 voices, and was last updated 19 years ago by Greg.
-
AuthorPosts
-
rjstMemberHi,
We’re now using myeclipse also for our EJB development, and I’d like to make a couple of questions/sugestions :
-Can myeclipse automatically know when it has to rerun xdoclet ? For example, if I change a xdoclet property in MyEclipse-Xdoclet (project properties), shouldn’t it know it has to run ? Also if methods are added to a bean it could run.
-I found some wrong code generation, I create a SessionBean with a remote interface (using the standard ejb doclet), and in the util object created, the generated getHome method uses local context instead of global context. Is there a way to fix this ?
-Since plenty of help is available for xdoclet, could the xdoclet properties show the help for any selected component ?
thanks
Ricardo
Riyad KallaMemberRicardo,
I am passing yoru comments on to the developers.
GregMember@rjst wrote:
-Can myeclipse automatically know when it has to rerun xdoclet ? For example, if I change a xdoclet property in MyEclipse-Xdoclet (project properties), shouldn’t it know it has to run ? Also if methods are added to a bean it could run.
At the moment the user must explicitly invoke xdoclet to run. We will look at the possibility of automating this in some of the areas you suggested.
@rjst wrote:
-I found some wrong code generation, I create a SessionBean with a remote interface (using the standard ejb doclet), and in the util object created, the generated getHome method uses local context instead of global context. Is there a way to fix this ?
What context do you mean, the jndi Context?
@rjst wrote:-Since plenty of help is available for xdoclet, could the xdoclet properties show the help for any selected component ?
The Xdoclet code assist in the java editor does have popup documentation with each xdoclet tag completion proposal. However, the Xdoclet conifguration UI doesn’t have any contextual help for tasks and subtasks.
rjstMemberHi,
Heres goes the generated getHome() method. It works because I changed COMP_NAME to JNDI_NAME. Notice that the comment still shows the original generated code. My xdoclet config only has remote interfaces.
/**
* Obtain remote home interface from default initial context
* @return Home interface for HistoryAccess. Lookup using COMP_NAME
*/
public static com.emation.automation.historyserver.remoteservices.interfaces.HistoryAccessHome getHome() throws javax.naming.NamingException
{
if (cachedRemoteHome == null) {
cachedRemoteHome = (com.emation.automation.historyserver.remoteservices.interfaces.HistoryAccessHome) lookupHome(null, com.emation.automation.historyserver.remoteservices.interfaces.HistoryAccessHome.JNDI_NAME, com.emation.automation.historyserver.remoteservices.interfaces.HistoryAccessHome.class);
}
return cachedRemoteHome;
}Another issue I have is that XDoclet, when run, doesn’t rewrite the interfaces. So, if they already exist, I have to delete them manually, if not they are not correctly regenerated.
thanks
Ricardo
GregMemberI see what your saying now about the JNDI versus COMP name. However, this Util class is getting generated by the EJB xdoclet module in the <util> subtask. This issue would need to be filed with the XDoclet guys on their PR system. http://opensource.atlassian.com/projects/xdoclet/secure/CreateIssue!default.jspa
As far as xdoclet recreating the interfaces, it will only recreate the interfaces if it detects a change to the underlying source or configuration. There may be some cases where it doesn’t figure this out just right and you have to delete the interface files or touch the source files to get xdoclet to regen.
majecekMemberadd this line in your file
@ejb.util generate="physical"
then run xdoclet on that file to generate the rest files.
It will use JNDI_NAME instead COMP_NAME
look here: http://xdoclet.sourceforge.net/xdoclet/tags/ejb-tags.html#@ejb_util__0__1_
GregMemberThanks for the tip.
-
AuthorPosts