Troubleshooting exceptions due to bad annotations

[andrew.rw.robinson]

I have a bug that is resulting in:

SEVERE: Error Rendering View[/conference/index.xhtml]
java.lang.IllegalArgumentException: create method not found
 at org.jboss.seam.Component.callComponentMethod(Component.java:1127)
 at org.jboss.seam.Component.callCreateMethod(Component.java:1107)
 at org.jboss.seam.Component.newInstance(Component.java:1096)
 at org.jboss.seam.Component.getInstance(Component.java:1044)
 at org.jboss.seam.Component.getInstance(Component.java:1027)
 at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:43)
 at com.sun.facelets.el.LegacyELContext$LegacyELResolver.getValue(LegacyELContext.java:134)
 at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
...
Caused by: java.lang.NoSuchMethodException: $Proxy202.begin()
 at java.lang.Class.getMethod(Class.java:1581)
 at org.jboss.seam.Component.callComponentMethod(Component.java:1116)
 ... 54 more

Is there any "easy" way of trying to determine what I screwed up? I wrote several classes without testing then just slapped a page view on these beans, so it isn't easy to tell which session bean I have a bug in.

The most helpful part seems to be the caused by section, but the "$Proxy202" isn't helpful at all.

Any ideas on how to track this down?

Thanks,
Andrew

[jcruise]

I just had a similar error from adding a factory method annotation. The problem was that the method was private instead of public.

The only way that I've found to reliably track down this sort of error is to have the Seam source available and watch it in the debugger.

On the upside I am getting a bit more familiar with Seam's mechanics and less dependent on the docs. On the downside, the discovery learning mode is quite time-consuming :)

Cheers
J

[andrew.rw.robinson]

I found the problem, I had two EJBs registered under the same name. One was supposed to be deleted (I guess I forgot to delete it) and it was registering on top of the other one. The old one had a bug in it (the begin method was not on the @Local interface of the EJB).

What stinks with EJB instead of POJO is that the resulting class is "$Proxy###" instead of a class name. It would be nice to know what interface the proxy implements. Oh well.

[jcruise]

I've just migrated my app from ADF-Faces/JSP/Spring/Hibernate/JBPM to ADF-Faces/Facelets/Seam/EJB3. I didn't much enjoying taking on EJB - it slows down deployment, complicates class loading, debugging is ugly ... however, every time I thought about rolling back I held off because of the conciseness and elegance of the resultant Seam based source code. I found the uber-annotations approach is a bit confusing at first but now fear that I am getting addicted ...

I figure that this will be the way to go in the long run - I just hope that in time I will be able to redelpoy my app in more than twice without a server restart and that the restart will take less than 2.5 mins. :D

Cheers
J

[gavin.king]

I agree that the proxy names are unhelpful. This also causes me problems from time to time. Add a feature request to JBoss EJB3 JIRA.

[andrew.rw.robinson]

http://jira.jboss.com/jira/browse/EJBTHREE-485

[jjarkko]

I too hate the current Proxy naming strategy. Is there a way to give a vote for the EJBTHREE-485 request ? ;)

[gavin.king]

Sure. Vote in JIRA.