0

I try to rebuild a scaffold faces plugin separately for some reasons, but found a really annoying bug, that I cannot solve.

java.lang.NoSuchMethodException: class org.metawidget.inspector.impl.BaseObjectInspectorConfig.setPropertyStyle(ForgePropertyStyle). Did you mean setPropertyStyle(PropertyStyle)?
    at org.metawidget.config.impl.BaseConfigReader$ConfigHandler.classGetMethod(BaseConfigReader.java:1633)

After trying some tricks, review the metawidget config codes, not found how to solve the problem.

scaffold setup --scaffoldType customfaces

works fine, but the

scaffold from-entity com.domain.entity.* --scaffoldType customfaces

fails.

Is anybody has a same issue? May I mess-up something?

Update#1:

The resource loading fails only, when run within forge console. JUnit test works fine. I assume, that metawidget plugin resource loader try to load metawidget-*.xml not from the new plugin but from the original scaffold-api's context.

Update#2:

The problem is somewehere deep in metawidget and forge relation. I found that if I use directly the SimpleResourceResolver.openResource(), the result is valid. But If I add the StaticHtmlWidget.setConfig(), the result is Unable to locate com/domain/customfaces/metawidget-entity.xml on CLASSPATH at the firs write() call. I have no idea, how to resolve this behavior.

Uyghur Lives Matter
  • 18,820
  • 42
  • 108
  • 144
azendh
  • 921
  • 8
  • 23
  • 1
    The problem is more interesting as I mentioned before, Te JUnit test I write, runs correctly. getShell().execute("scaffold from-entity com.domain.entity.* --scaffoldType customfaces --overwrite --targetDir /"); It may a forge console related problem? – azendh Sep 27 '12 at 14:46

1 Answers1

0

Possibly you're including the Metawidget JARs more than once? Forge uses JBoss Modules, so you must be careful how your classpath gets constructed.

The Metawidget error is basically saying that 'ForgePropertyStyle' is not of type 'PropertyStyle'. But (unless you've changed that code in your customfaces) ForgePropertyStyle does indeed extend PropertyStyle. So you must have two PropertyStyles on your classpath somehow?

Richard Kennard
  • 1,325
  • 11
  • 20
  • The cloned plugin also depends the metawidget-all artifact, but if I change the scope from `compile` to `test`, I can not install the plugin. I rename the `ForgePropertyStyle` to `CustomFacesPropertyStyle` (also the *Config), but the exception is the same: the plugin refer to the `ForgePropertyStyle` (the metawidget xml-s are modified, too). Do you have any idea, how to eliminate this problem. I am totally confused. – azendh Sep 28 '12 at 11:53
  • 1
    It is not ForgePropertyStyle/CustomFacesPropertyStyle that is the problem, so renaming won't help. The problem (I think) is you have two org.metawidget.inspector.impl.propertystyle.PropertyStyles on your classpath. You could try 1) removing the default scaffold-faces module and just having your custom one; 2) looking at https://github.com/forge/plugin-spring-mvc which is a similar plugin to yours (also uses Metawidget); 3) asking this question on forge-dev@lists.jboss.org – Richard Kennard Sep 29 '12 at 03:42
  • The problem is still not solved. I understand your answer, there are two metawidget-all jar in the classpath, but I cannot fix it: I may have not enought mavan skills. :( 1) is not the acceptagle soultion. 2) I check it out, but not found any difference, how to depend metawidget module. (As I try, this module is buggy with the current state) 3) still not try it, I hope anyone can help here. I think this is a maven-related issue, so I keep reading and trying :) – azendh Oct 01 '12 at 14:57
  • As I try `plugin-spring-mvc` still not works for me for other reasons. – azendh Oct 01 '12 at 16:05
  • Finally I try the first suggestion you tell. Remove the original faces plugin, and I confirmed not the duplication cause the problem. The metawidget's `SimpleWidgetResolver.openResource` could not load the resource. The problem exists *ONLY* when I run my command as a forge plugin within forge. If I run the command within an junit test (with `getShell.execute`), the resource loads properly, and plugin runs as well. – azendh Oct 02 '12 at 09:48