Hi, Dan.
> 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... I've recompiled Isis and now I can add actions, modify their signature, and runs perfectly !!! El 04/02/2014, a las 01:00, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> escribió: >> ~~~ >> 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. > > > I don't have neither a clear case, and sure it's something broken ... Working > a bit at least on an Isis project (like Estatio) I'm sure he can find a > case... > > The abstract class is in one module, and concrete classes on another. I also > suspect that having more than 1 domain module can raise to a higher number of > enhancement problems, but since now we could handle them. > > The in-memory API would be perfect, as it would also allow to implement the > same solution also on the BDD SystemInitializer (or some other BDD > component). > > That's the main point where we are suffering those DN Enhancer problems. > > > A new programmer joined the team 2 weeks ago. It became productive nearly > immediatly, simply writing BDD tests and the entities and actions derived > from that. He had no need to see the web UI and I was confident that all was > ok. That's Isis :-)) > > But the biggest disappointment is the DN Enhancer failures... > > >> 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). > > > Seems interesting... But perhaps "always enhanced" entities would be "harder" > to debug? I suspect it can conflict with some common technologies, but not > sure... > For me, using the wrapper is "just enough". > > >>> 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. > > > But the point is that I'm in Mac, other mates on Windows, and the file is > properly spelled (in uppercase). Seems that it's JRebel or the plugin what > is misspelling the class filename? But that's only when initializing... After > that phase, all seems to work ok. The misspelling exception was shown for all > classes imported by that Drools rules file that was created on the Service > initialization. > >> 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... > > I'll recompile and try it again. > > >> >> 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 > > > I also noticed that class reloading was also slow... Thanks for the link. > I'll play with those options. > > > Thanks again, > > Oscar > > > > > El 04/02/2014, a las 00:17, Dan Haywood <d...@haywood-associates.co.uk> > escribió: > >> On 3 February 2014 17:03, GESCONSULTOR - Óscar Bou >> <o....@gesconsultor.com>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 > > > Óscar Bou Bou > Responsable de Producto > Auditor Jefe de Certificación ISO 27001 en BSI > CISA, CRISC, APMG ISO 20000, ITIL-F > > <contactenos.html.gif> 902 900 231 / 620 267 520 > <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou > > <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou > > <blog.png> http://www.GesConsultor.com > > <gesconsultor_logo_blue_email.png> > > > Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen > información reservada que no puede ser difundida. Si usted ha recibido este > correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al > remitente mediante reenvío a su dirección electrónica; no deberá copiar el > mensaje ni divulgar su contenido a ninguna persona. > Su dirección de correo electrónico junto a sus datos personales constan en un > fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de > mantener el contacto con Ud. Si quiere saber de qué información disponemos de > Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito > al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: > Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), > y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su > responsabilidad comprobar que este mensaje o sus archivos adjuntos no > contengan virus informáticos, y en caso que los tuvieran eliminarlos. > > > > >
