[Greg]

James,

There is no library named that to my knowledge. That message that you are seeing is a printout from the JSP validation. It has nothing to do with XDoclet running. What JDKs are configured in eclipse? (Window > Preference > Java > Installed JREs). What is the output if you type “java -version” at a console?

[eadon]

Oops, ignore/delete my last message, as I didn’t see Greg’s reply, as it was on a different page. 🙂

[eadon]

Hi,
Here are the details,
Installed JRE’s are the standard Sun J2EE JDK:
/opt/SUNWappserver/jdk
$ echo $JAVA_HOME
/opt/SUNWappserver/jdk
$ java -version
java version “1.4.2_04”
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b04)
Java HotSpot(TM) Client VM (build 1.4.2_04-b04, mixed mode)

[eadon]

Just to clarify, by Installed JRE’s – I meant in Eclipse preferences, from Window > Preference > Java > Installed JREs. There is only one:
/opt/SUNWappserver/jdk

[Greg]

In your XDoclet config, click on the jboss subtask and set the Version attribute to

4.0

instead of 4.0.2. Take a look at the following URL for possible jboss Version values:
http://xdoclet.sourceforge.net/xdoclet/ant/xdoclet/modules/jboss/ejb/JBossSubTask.html

[eadon]

Hi,
Sorry if I’m missing something. Where is this JBoss subtask? In preferences, in eclipse, there is myeclipse->XDoclet and under that there are Build and Code Assist. Searching those config pages, there is no sign of a JBoss subtask. Can you please indicate where it is?
I edited the .xdoclet file so that
<element name=”jboss” used=”true”>
….
<attribute name=”Version” value=”4.0.2″ used=”true”/>

is now:

<element name=”jboss” used=”true”>
….
<attribute name=”Version” value=”4.0″ used=”true”/>

But XDoclet is still not running. However the error message in .metadata/.log is now different, so I guess the above edit of .xdoclet to 4.0 worked. The new error message now reads:

!ENTRY org.eclipse.ant.ui 4 120 2006-01-23 16:52:37.589
!MESSAGE Error logged from Ant UI:
!STACK 0
java.net.SocketTimeoutException: Accept timed out
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:353)
at java.net.ServerSocket.implAccept(ServerSocket.java:448)
at java.net.ServerSocket.accept(ServerSocket.java:419)
at org.eclipse.ant.internal.ui.launchConfigurations.RemoteAntBuildListener$ServerConnection.run(RemoteAntBuildListener.java:97)

Eclipse is configured to use the Ant plug-in, and Ant runs correctly within Eclipse.
So XDoclet is still not running it seems, what are your suggestions to proceed? Is another edit of .xdoclet the remedy?
Thanks

[Riyad Kalla]

Check out this quickstart guide here: http://www.myeclipseide.com/images/tutorials/quickstarts/firstejb/
Starting with Figure 8 and continuing to Figure 14 shows you how to add the JBoss subtask to the EJB doclet.

[eadon]

OK, now I see where the subtask is, and I must have typed 4.02 instead of 4.0 – hence the problem! And a difficult one to diagnose at that, surely the error messages should not be so uninformative and misleading!
I was following that guide, by the way. This does not explain how to fix the problem with the “!ENTRY org.eclipse.ant.ui ” error message indicated above. Please could you advise? Is this another weird problem, or easily diagnosed?
Thanks for your assistance so far!

[eadon]

A clue! This page seems to indicate that this error is associated with a validation problem with ANT XML – associated with a bug in MyEclipse validation.
http://www.myeclipseide.com/PNphpBB2+file-printview-t-7354-start-15.html
As this is preventing myEclipse run XDoclet from working I am wondering if you can tell me if this bug is fixed and how to progress from here?

[Riyad Kalla]

James,
It is very hard for us to trouble shoot this issue through the forums since we’ve run through quite a few “off the bat” solutions that haven’t worked. Would you be able to mail us the project to support@genuitec.com ATTN Riyad with a link to this thread so I know why I’m getting the file?

[eadon]

Hi,
The original bug was the jboss version number format bug. The latest bug, the ANT error, was resolved by using a new eclipse workspace and importing the project. Thanks for your help guys. If I may make an observation: the latter bug may be a bug with Eclipse/plug-ins and difficult to resolve, so is perhaps out of your hands. But the former bug – stating the version number as x.x.x instead of x.x – that could have been avoided with validation. Also, a much more meaningful error message could have been generated. I would recommend that you fix this in your software. As myEclipse is not open source, I am unable to patch it myself 🙂
As for the latter ANT Error bug – I expect you guys should try to determine what it was about the workspace that caused this. You have my project, which is very minimal hello-world level stuff, so I would recommend the obvious, which no doubt you may be doing, which is to analyse it and then use that to generate a meaningful error message.
For me these my-Eclipse XDoclet bugs were the worst I have ever encountered, they cost me a lot of mucking about and time (albeit my spare time in this case). And I am reminded why open source software is superior to closed source software: the support, contrary to what Microsoft and others claim, is simply worse. I have never been help up two weeks by an open source bug! And this dispite your expert and very helpful assistence. This has been a very insightful experience. Thanks for your help and genuine time you put into helping me.

[eadon]

Just to clarify, I wasn’t really held up two weeks, I was only looking at the xDoclet stuff now and again, but my point holds. Also, if you wish, I can send you my workspace files for the workspace that was causing the ANT error, to assist in helping you reproduce the error, for better diagnostics.
Thanks

[Greg]

As far as the XDoclet problem, the reason I didn’t think it was a jboss version format bug there are very good and specific error messages for jboss version problems. I configured a project, set the jboss version to 4.0.2 and ran XDoclet. Below is the captured output from the Console:

Buildfile: C:\dev\ide\support\4.1GA\workspace\xdocletsupport\xdoclet-build.xml
N10004:

BUILD FAILED
C:\dev\ide\support\4.1GA\workspace\xdocletsupport\xdoclet-build.xml:36: 4.0.2 is not a legal value for this attribute

Total time: 6 seconds

This seems pretty straightforward. Granted, you do have to open the file and see which subtask is causing the error, so it could obviously use some improvement.

We pride ourselves on offering the industry’s best support and I think if you poll our users the overwhelming sentiment is that our support is superior to open-source alternatives as well as commerical. Regardless, we are sensitive to our user’s time and we understand your frustration for being held up 2 weeks in your development. Hopefully, our support responses will lead to quicker resolution next time you need us.

[eadon]

Hi,
Ah! OK so you do generate meaningful error messages for version, but I was unable to see them, as they are ANT error messages. The ANT message was not appearing in my console. If I had not had the ANT error, I would have seen the ANT error message. However I could only see the stack trace, and the stack trace was highly misleading, giving no clue about version. My point is, perhaps the stack trace should contain the same error as Ant displays, in which case I would have spotted the Version problem immediately. Hence my recommendation to have meaningful stack trace exceptions thrown, in case ANT is not working for whatever reason. So do not assume the user can see ANT error messages.
My second recommendation is, if ANT is not working, then put some helpful stuff in the stack trace, even a suggestion like, “try creating a new eclipse workspace and import your project.” The point is, myEclipse is supposed to be a RAD tool. Yet I found it pretty damned unfriendly in the sense of lousy stack trace diagnostics, and therefore, well not RAD. I am glad this error didn’t happen in a serious project. So I was not really held up, except on the EJB aspect of a personal project which I could route around.
So to summarise, I consider the uninformative stack trace generated by MyEclipse in both problems stated above to be a bug in MyEclipse. You support guys should willingly agree with me, as I have taken up much of your time, where as a meaningful stack trace would have found both problems immidiately. But I have to say, apart from that intense example user-unfriendliness, it is a very good tool.
Thanks again.

[eadon]

And to clarify, initially i did try creating a temporary new workspace early on, but it did not solve the problem, it only worked once the version number problem was finally diagnosed and fixed. I could only see the stack trace by examining the .log file. I have absolutely no idea why the new workspace idea worked once the version number problem was fixed. Until the meaningful stack trace bug is addressed, I would feel slightly nervous about recommending myEclipse to people, as I do not wish them to suffer misleading error messages when things go wrong. And yes, the 2nd problem was an environment problem solved by a new workspace but this too is a bug in its own right, whether in Eclipse or in MyEclipse. One conjecture I have was that I upgraded Eclipse, but was not prompted to start a fresh workspace. Perhaps that was a problem, I do not know. It is weird though, as everything except MyEclipse XDoclet was fine. So you really should address this more assertively as a bug you guys need to fix in my humble oppinion, rather than implying there is not really a problem. If I have to turn to support, then it’s bad!

[Author]

Posts