reference to ecfi.resourceFacade before it is assigned
Brought to you by:
jonesde
Menu
▾
▴
#20 reference to ecfi.resourceFacade before it is assigned
I am trying to run my first simple test. I have a setupSpec method that does the usual ExecutionContext.ec = Moqui.getExecutionContext()
It throws the error below:
DynamoDBCrud > classMethod FAILED
java.util.ServiceConfigurationError: org.moqui.context.ExecutionContextFactory: Provider org.moqui.impl.context.ExecutionContextFactoryImpl could not be instantiated: java.lang.NullPointerException: Cannot invoke method getLocationReference() on null object
at java.util.ServiceLoader.fail(ServiceLoader.java:207)
at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
at org.moqui.Moqui.<clinit>(Moqui.java:44)
at java.lang.Class.forName(Class.java:247)
at DynamoDBCrud.setupSpec(DynamoDBCrud.groovy:25)</clinit>
Caused by:
java.lang.NullPointerException: Cannot invoke method getLocationReference() on null object
at org.moqui.impl.entity.EntityFacadeImpl.loadEecaRulesAll(EntityFacadeImpl.groovy:416)
at org.moqui.impl.entity.EntityFacadeImpl.<init>(EntityFacadeImpl.groovy:80)
at org.moqui.impl.context.ExecutionContextFactoryImpl.initEntityFacade(ExecutionContextFactoryImpl.groovy:420)
at org.moqui.impl.context.ExecutionContextFactoryImpl.getEntityFacade(ExecutionContextFactoryImpl.groovy:413)
at org.moqui.impl.context.ExecutionContextImpl.getEntity(ExecutionContextImpl.groovy:95)
at org.moqui.impl.context.ExecutionContextFactoryImpl.getExecutionContext(ExecutionContextFactoryImpl.groovy:455)
at org.moqui.impl.context.ResourceFacadeImpl.getLocationReference(ResourceFacadeImpl.groovy:202)
at org.moqui.impl.context.ExecutionContextFactoryImpl.initComponentLibAndClasses(ExecutionContextFactoryImpl.groovy:309)
at org.moqui.impl.context.ResourceFacadeImpl.<init>(ResourceFacadeImpl.groovy:83)
at org.moqui.impl.context.ExecutionContextFactoryImpl.<init>(ExecutionContextFactoryImpl.groovy:151)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345)
... 4 more
Running test: test classMethod(DynamoDBCrud)
It starts on the line in the ExecutionContextFactoryImpl (151) where resourceFacade is created, but it ends up referencing the ecfi.resourceFacade later on.
I read up on ThreadLocal, but I cannot understand how:
this.activeContext.set(ec) (ecfi.454 - off a line) ends up calling:
eci.getEntity?
I have two EntityDataresouceFactory objects - one for MySQL and one for DynamoDB.
Related
Which version of Moqui are you using? The line numbers don't exactly match up with the trunk head, and if I remember right I ran into this a while back and fixed it... but quite a while back.
Also, what does your init code look like? Is it on github or somewhere that I could grab to try to reproduce this locally?
David,
I have cleaned up my repo (I guess I should thank you :0); it is at
https://github.com/byersa/ccoach.git It is just the runtime dir.
It is a private repo, but I added you as a collaborator - but I would have
thought that I could just have given you read access, but I did not see a
way to do that - not that I care, just think I am missing something.
I put it at the same level as moqui and cd to component/ccoach and run
"gradle --info test". I tested it on a clean remote clone, so it should
reproduce as described.
Thanks,
-Al
On Sat, Dec 8, 2012 at 1:53 AM, David E. Jones jonesde@users.sf.net wrote:
Related
Bugs: #20
Oh, and i am using the latest version - as of Dec 3.
On Sat, Dec 8, 2012 at 3:35 PM, Al Byers byersa@automationgroups.comwrote:
Related
Bugs: #20
Thanks for the additional details Al. I'm onsite with a client this coming week so it may be a bit before I can get to this.
Some things I wondered based on your notes here:
are there any errors higher up in the log? there could be an error preventing one of these from initializing completely
right after the start it should show the location of the runtime directory and the moqui-conf file to use, are these what you expect?
What makes me wonder most is that it sounds like you are running from the moqui/runtime/component/ccoach directory instead of the moqui directory, and unless you have taken care of certain things this will cause problems.
David,
Thanks for looking at this. See below.
On Sun, Dec 9, 2012 at 8:52 PM, David E. Jones jonesde@users.sf.net wrote:
DynamoDBCrud STANDARD_OUT
--- 0 [ Test worker] INFO
impl.context.ExecutionContextFactoryImpl
Initializing Moqui ExecutionContextFactoryImpl
-Al
Related
Bugs: #20
I'm trying here Al, but this is a mess.
It looks like you're running with a directory structure like this (based on what I found in your build.gradle file):
It is usually easier to put the runtime directory under the moqui directory (ie replace the default one), but in theory this should work.
However, I ran into a few issues:
running "gradle test" from the ccoach/component/ccoach directory points to "/lib" as the lib directory (ccoach/component/ccoach/lib), which doesn't exist, but there is a ccoach/lib so I changed build.gradle to point to "/../../lib"
the ccoach/component/ccoach/screen/ccoach/dojo directory is a symlink to a directory that doesn't exist on my machine, so I'm getting an error about that when running, so I deleted that symlink
in your test you are using the "Person" entity and in your ccoach directory you have a mantle directory, but it is empty; then I see you have a Person entity defined in the ccoach/component/ccoach/entity/CCoachEntities.xml file, but it is in a transactional_nosql group which doesn't exist, or which an error says doesn't, ie I'm getting this error:
org.moqui.entity.EntityException: Cannot get JDBC Connection for group-name [transactional_nosql] because it has no DataSource
At this point, I'm giving up... find an easier way to reproduce this or at least write up some running instructions and I'll reconsider taking a look at it.
I would recommend simplifying your deployment:
You could put your runtime directory under the moqui directory, or use some other approach to make it easier to drop in.
Use the main build.gradle file in moqui/ and add a reference to the build.gradle in your component by adding it to the settings.gradle file (just like the moqui/framework/build.gradle is)
If your moqui fork on github contains the entire project and you are planning to build and run from source instead of using the binary build (the executable war file) from moqui, you might as well just add everything to your forked moqui repo in the runtime directory instead of using a separate component
It would actually complicate things in some ways, but making your Amazon Dynamo stuff a separate component that is built separately and just expected to be on the classpath for scripts or for builds would be cleaner overall, and is a better way to make it reusable
I'll add an example of source that needs building in a component along with a build.gradle file in that component and an entry in the settings.gradle file to demonstrate that.
In general though, it's probably a worthwhile goal to make this stuff easier to drop in somewhere and run. This is a lot easier if you don't have anything that requires building before running, but obviously that is required for some things.
Also if you don't need to modify anything in the runtime directory keeping your app as only a component instead of the entire runtime directory is a better way to go. The idea is to drop in app and other components when deploying stuff built on moqui. If a component requires a change to the moqui-conf XML file then mention it in a README and/or include a patch... keeping in mind that moqui-conf files are deployment-specific and so need to be tailored if anything different from the standard ones is needed.
Last edit: David E. Jones 2012-12-10
Looking at the logs from running one last time... it did get past the point of initializing the ExecutionContext and ExecutionContextFactory to the point where it was actually trying to run the tests.
Unfortunately this means that I was not able to reproduce the issue you were running into Al... everything initialized just fine.
It might be necessary to do what I mentioned in my last message and just put everything into your forked moqui repo so that it is possible to just check that out and run a single command (ie gradle test from the moqui directory) in order to try it.
With so many steps, and guessing at steps, to get things arranged in the filesystem and then get the thing to run I have no idea if I did it the same way you did, or if you have changes in the moqui-fork or something else is different from how I tried running it. In other words, you need to get this to a better defined way to reproduce it, and a checkout plus single command is the easiest way to do this.
David,
Thanks so much for wading through this. I will be implementing your
suggestions, but I have a couple of deployment questions:
I think a lot of people coming to moqui may also be new to git. What is
the suggested pattern for setting up a dev environment if you do not want
any of the components that come with moqui? Do a "git rm" on each
component? Then clone mantle into the runtime? Put your own, separately
managed components in the .gitignore file?
What is the best way to handle content libraries like the dojo one? In
ofbiz, I would have them as a separate webapp, but I don't see how to
include them in moqui if I am running in the "gradle run" mode, as opposed
to the tomcat/war mode.
-Al
On Mon, Dec 10, 2012 at 7:26 AM, David E. Jones jonesde@users.sf.netwrote:
Related
Bugs: #20
This might be a better discussion for the LinkedIn group... as bad as the threaded (or rather non-threaded) comments are there, they are worse here on SourceForce (the whole automatic quoting of a previous message is annoying... whatever happened to hierarchical message trees like JavaLobby used to have, and probably still does?)
Anyway, for #1: there are so many different potential needs and preferences within organizations that this is hard to say. Just like with SVN there are lots of options. The biggest difference with git is that it is so easy to do vendor branches (ie a "fork") that there is no reason to avoid it like there was with SVN.
For #2: this is the reason why you'd want to control the runtime directory, or in some way or other specify and control the root screen (default is the webroot.xml screen, but that can be changed in the moqui-conf XML file).
Basically just decide where you want the stuff to go, and put it there relative to the webroot screen. If you want a "dojo" directory that static content is served through, and you don't want to modify the webroot screen or its corresponding webroot directory, then just put the content in a component with a dojo.xml file and corresponding dojo directory, and mount that dojo.xml screen under the webroot screen using a record in the SubscreensItem entity's table.
Remember that you have various tools for dropping things into the subscreen hierarchy, and even in your component/screen directory you can have multiple screen XML files that are mounted in totally different places.
David,
I followed your directions, and the problem went away for me, too.
Thanks,
-Al
On Mon, Dec 10, 2012 at 7:37 AM, David E. Jones jonesde@users.sf.netwrote:
Related
Bugs: #20