~~~
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
 902 900 231 / 620 267 520
 http://www.twitter.com/oscarbou
 http://es.linkedin.com/in/oscarbou
 http://www.GesConsultor.com
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.
|
