On 3 February 2014 17:03, GESCONSULTOR - Óscar Bou <[email protected]>wrote:
> > > > We find DN enhancer problems quite a lot (nearly on each BDD execution): > - This one regarding abstract classes. > - Another quite common regarding duplicated fields (jdoXXX fields). > > Both of them are solved by slightly changing the class and forcing Eclipse > to recompile and the DN enhancer to run. So it's an old friend. Be sure I'm > not trying to manually instantiate it. > > OK... Jeroen and I see the second, must admit haven't seen the first. > > I've run the enhancer again before executing the webapp and on this last > execution finally seems solved (we have 4-5 "dom" modules, similar to > "estatio-dom" and "estatio-dom-italy", but for different Bounded Contexts, > that must be enhanced "in order" - taking into account dependencies between > them -). > > That sounds like quite a hassle. I wonder if the first issue arises because of these multiple modules ... is the abstract class in one of them, and the concrete class in the other? Also, I have a theory that the duplicate field error is because the Eclipse DN plugin spawns off the DN enhancer multiple times (each in a separate Java process), and they (incorrectly) end up enhancing all the domain classes on their classpath, not just the code in their module. Would it be worth (temporarily) merging these modules into a single module, and seeing if that reduces/eliminates the number of errors? ~~~ Whatever, there's definitely something broken with the DN enhancer plugin. But I don't think there's any ticket open on the DataNucleus JIRA for Andy to look into. My suspicion is that he would want a clearly defined reproducable issue, which I don't know that we have at the moment. Another avenue might be to see if Andy would provide an in-memory API so that the enhancement can be performed within the JRebel plugin itself. That would then let us eliminate the DN plugin completely. > > Regarding: > > 6. Those "ValuationDimension$$EnhancerByCGLIB$$258191d0" classes are > coming from the WrapperFactory, which is probably from integration tests? > Not quite sure what the interaction is there, shouldn't matter, I think, > but a bit odd. > > > > We "abuse" the original intention of the WrapperFactory. > We've nearly standarized that, when an action is invoked from another > action in the domain, it will always be "wrapped". > That way, we can apply the same business logic restrictions applied to > users to the interactions between Domain Entities at the Domain Level. > When that's not possible (mainly due to always-hidden or always-disabled > properties, and they have a modifyXXX method) we directly call the > modifyXXX or simply remove the "wrap" and make a comment justifying it. > > We've found it really useful for detecting nulls passed as parameters, or > values that didn't comply with the "autoComplete" or "choices" > restrictions, on BDD tests. > > I know it was not originally intented for that, but is that "conceptually > wrong"? > > No, that's fine... and I'm glad that's working for you. For Isis 2.0 (which I'm starting to think about), was mulling over the idea that this every pojo would always be enhanced in a similar way, so that it can provide access to its Oid and ObjectAdapter, such that it is "self-describing". Will probably use javassist rather than cglib, though (as I'm using for the new @RequestScoped services). > ---- > > I've just seen that there are some exceptions when initializing the webapp. > > Seems they are happening because when initializing a Domain Service, those > classes are loaded and, perhaps, the "environment" has not been yet > properly initialized by JRebel. Is it possible? > > Don't think so... > Or simply due to some misspelling... Because see > that eventOccurrence.class name is misspelled. On the filesystem the first > character is in uppercase: EventOccurrence.class > > ...Yes, I think that's more likely. If you are on Windows, then (because it is case preserving but case insensitive), it'll mask this error. At any rate, you should fix it. > > at org.apache.isis.core.webserver.WebServer.run(WebServer.java:92) > at org.apache.isis.core.webserver.WebServer.main(WebServer.java:68) > at org.apache.isis.WebServer.main(WebServer.java:25) > java.lang.RuntimeException: cannot find > com.xms.framework.risk.domain.model.materialization.eventOccurrence: > com.xms.framework.risk.domain.model.materialization.EventOccurrence found > in com/xms/framework/risk/domain/model/materialization/eventOccurrence.class > at > org.zeroturnaround.bundled.javassist.CtClassType.getClassFile2(JRebel:194) > at > org.zeroturnaround.bundled.javassist.CtClassType.getAnnotations(JRebel:541) > at > org.zeroturnaround.bundled.javassist.CtClassType.getAnnotations(JRebel:526) > at > com.danhaywood.isis.tool.jrebelplugin.IsisJRebelPlugin.isPersistenceCapable( > IsisJRebelPlugin.java:362) > at com.danhaywood.isis.tool.jrebelplugin.IsisJRebelPlugin.access$700( > IsisJRebelPlugin.java:50) > at > com.danhaywood.isis.tool.jrebelplugin.IsisJRebelPlugin$2.processSafely( > IsisJRebelPlugin.java:242) > at com.danhaywood.isis.tool.jrebelplugin.IsisJRebelPlugin$2.process( > IsisJRebelPlugin.java:198) > at com.zeroturnaround.javarebel.xU.a(JRebel:257) > at com.zeroturnaround.javarebel.xU.a(JRebel:246) > at com.zeroturnaround.javarebel.xU.a(JRebel:218) > at > com.zeroturnaround.javarebel.SDKIntegrationImpl.runBytecodeProcessors(JRebel:120) > at com.zeroturnaround.javarebel.xE.transform(JRebel:50) > at java.lang.ClassLoader.defineClass(ClassLoader.java) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.zeroturnaround.javarebel.xr.defineRebelClass(JRebel:168) > at com.zeroturnaround.javarebel.Bq.a(JRebel:638) > at com.zeroturnaround.javarebel.xt.a(JRebel:261) > at com.zeroturnaround.javarebel.xb.a(JRebel:174) > at com.zeroturnaround.javarebel.xt.loadReloadableClass(JRebel:319) > at > com.zeroturnaround.javarebel.SDKIntegrationImpl.findReloadableClass(JRebel:85) > at com.zeroturnaround.javarebel.xJ.findReloadableClass(JRebel:16) > at java.net.URLClassLoader.findClass(URLClassLoader.java) > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > > ----- > > > As this is an IT Monitoring service, it's not needed for debugging with > JRebel. Simply after removing it, I can add a field and the webapp updates > it ! > > After that, I've added a simple action to update the value of the newly > created field. When trying to reload the entity page, the following > exception is thrown: > > at org.mortbay.jetty.bio.SocketConnector$Connection.run( > SocketConnector.java:228) > at org.mortbay.thread.QueuedThreadPool$PoolThread.run( > QueuedThreadPool.java:582) > Caused by: java.lang.NullPointerException > at org.apache.isis.viewer.wicket.model.mementos.ActionMemento.<init>( > ActionMemento.java:53) > at org.apache.isis.viewer.wicket.model.mementos.ActionMemento.<init>( > ActionMemento.java:45) > at > org.apache.isis.viewer.wicket.model.mementos.ObjectAdapterMemento$Functions$4.apply( > ObjectAdapterMemento.java:396) > OK, I noticed this issue today as well, while demo'ing something to Jeroen. Not sure why this didn't show up for me before, but I've just committed and pushed a change which hopefully fixes. Let me know how you get on... Dan PS: one other thing to raise: JRebel seems to be quite slow in loading classes. But - even though I have rebel.xml set up to just reload the domain classes - it seems to monitor everything (ie all of the Isis classes too), which probably explains the slowness. The JRebel docs [1] suggest that it is possible to filter using an <include> tag, but it doesn't seem to work for me. Interesting in knowing how you get on with it. [1] http://manuals.zeroturnaround.com/jrebel/standalone/config.html#include
