isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: JRebel support
Date Wed, 05 Feb 2014 09:31:27 GMT
On 5 February 2014 06:52, GESCONSULTOR - Óscar Bou
<o.bou@gesconsultor.com>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 <
> o.bou@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 <dan@haywood-associates.co.uk>
> escribió:
> >
> >> On 3 February 2014 17:03, GESCONSULTOR - Óscar Bou
> >> <o.bou@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.
> >
> >
> >
> >
> >
>
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message