isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
Subject Re: JRebel support
Date Wed, 05 Feb 2014 06:52:47 GMT
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?

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.

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.

If that would be the case, we could also ask for the DN Enhancer plugin to only enhance those
classes that have changed.

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