On 5 February 2014 06:52, GESCONSULTOR - Óscar Bou <[email protected]>wrote:
> Regarding this: > > > >> > >> 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've noticed that just changing one file, forces JRebel to reload all (or > near all) classes on the "domain" Module. > Does it happen the same to you? > Yeah... in fact, I've found that JRebel seems to monitor everything in my workspace. Given I have all of Isis source code in it, that's quite a lot of monitoring it's doing. Actually, for me, that's quite convenient when I'm changing framework code, but it doesn't seem that the <include> tag is working. > If so, I suspect it can be related also to DN Enhancer, as changing one > file seems to force the DN Enhancer plugin to enhance all classes in that > project, not just the changed one. As it originates changes on .class files > in /target-ide, JRebel reloads all them. > > Even if the DN enhancer changes all the domain classes, that's still only a small number compared to what I think JRebel is monitoring. But you might well be right that the DN enhancer does more work than it should, as well. > And, as JRebel seems not to be "specially fast" on that, all that > combination originates a slow reload of 20 (or more) classes in my case. > > As per above, I think it's monitoring lots and lots of classes. There is some JRebel logging that can be enabled, might be worth looking at that more closely. > If that would be the case, we could also ask for the DN Enhancer plugin to > only enhance those classes that have changed. > > In my IsisJRebelPlugin, I have the packagePrefix property which is used to restrict the classes I process. so if we can get an in-memory enhancement API, then we could deal with it there. Cheers Dan > Thanks, > > Oscar > > > > > > > > -------- > > 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 < > [email protected]> 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 <[email protected]> > escribió: > > > >> 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 > > > > > > Ó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. > > > > > > > > > > > > > > > >
