A forked release - 0.100.0

[James Green]

Hi,

In the absence of movement on the "official" project I have taken the SVN trunk, made a few "light" touches and introduced it as the following:

https://github.com/jmkgreen/morphia

There are a couple of structural changes, sources reformatted and typos fixed, and javadoc improvements. I have also updated the Maven pom files to build correctly and to have a groupId of com.github.jmkgreen.morphia. Before I go further it would be reassuring if someone else would take the .jar files I've uploaded or download the git source tree and build it, then give it a whirl in a test environment.

If you used the Mapper directly, be advised it is now an interface, with a DefaultMapper implementation.

It it highly likely that the package names will have to change to avoid conflict, reflecting the com.github.jmkgreen.morphia root of the new Maven groupId. This will of course require changes to projects that wish to switch but hopefully a global find and replace will suffice for most. This rename has not yet occurred.

Aside from this "let's get started" work, I am considering adding annotations to permit data encryption/decryption. At present data encryption looks possible but rather more indirectly than perhaps it could be. My employer has an interest in seeing cryptography applied so easing this may be priority along with getting maven releases up and running. Some Java-EE examples are also likely.

Github certainly looks appealing from a collaboration perspective, so the involvement of others would be welcomed.

Thoughts please...

James

[Chuck May]

Forking can be a dicey affair, but in this case it seems justified.  I know there was talk at one point that Morphia would be merged into the main Java driver, but there seems to be no movement there.  Development also seems to have stalled.  It really doesn't need too much since it already works with the latest driver.  It would be nice to have aggregation support built-in someday.  

Once the artifacts gets deployed to Maven I would be willing to help out with the testing.

Chuck 

[Russell Bateman]

I'm confident that Scott's seen these postings. If he remains silent, then this is tacit approval that we move ahead. Thanks, James, for carrying the ball here. I will pick up what you do and use it once you establish checkpoints. I just don't have time to consecrate free hours to this project in an abstract sense--I'll just use it and if it works, keep using it.

[Shriram Shrikumar]

Hi,

I have checkout out the code from git and the tests seem to run apart from three (two of which are inconsistent). 

TestMapper.SingleLookup fails inconsistently(sometimes it works) on line 150 with A.loadCount returning 2

TestPerf.testAddressInsertPerf sometimes fails on the assert (line 142) but I suspect a performance test failure can likely be ignored.

There is also an error:

ListOfDoubleArrayMappingTest.testMapping which fails with the following stacktrace:

java.lang.RuntimeException: java.lang.RuntimeException: java.lang.RuntimeException: com.github.jmkgreen.morphia.mapping.MappingException: No usable constructor for [Ljava.lang.Double;

at com.github.jmkgreen.morphia.mapping.DefaultMapper.fromDb(DefaultMapper.java:510)

at com.github.jmkgreen.morphia.mapping.DefaultMapper.fromDBObject(DefaultMapper.java:256)

at com.github.jmkgreen.morphia.query.MorphiaIterator.convertItem(MorphiaIterator.java:66)

at com.github.jmkgreen.morphia.query.MorphiaIterator.processItem(MorphiaIterator.java:53)

at com.github.jmkgreen.morphia.query.MorphiaIterator.next(MorphiaIterator.java:48)

at com.github.jmkgreen.morphia.query.QueryImpl.get(QueryImpl.java:362)

at com.github.jmkgreen.morphia.DatastoreImpl.get(DatastoreImpl.java:493)

at com.github.jmkgreen.morphia.DatastoreImpl.get(DatastoreImpl.java:511)

at com.github.jmkgreen.morphia.mapping.ListOfDoubleArrayMappingTest.testMapping(ListOfDoubleArrayMappingTest.java:34)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:601)

at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)

at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)

at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)

at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)

at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)

at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)

at org.junit.runners.ParentRunner.run(ParentRunner.java:236)

at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)

at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Caused by: java.lang.RuntimeException: java.lang.RuntimeException: com.github.jmkgreen.morphia.mapping.MappingException: No usable constructor for [Ljava.lang.Double;

at com.github.jmkgreen.morphia.mapping.EmbeddedMapper.fromDBObject(EmbeddedMapper.java:151)

at com.github.jmkgreen.morphia.mapping.DefaultMapper.readMappedField(DefaultMapper.java:530)

at com.github.jmkgreen.morphia.mapping.DefaultMapper.fromDb(DefaultMapper.java:507)

... 32 more

Caused by: java.lang.RuntimeException: com.github.jmkgreen.morphia.mapping.MappingException: No usable constructor for [Ljava.lang.Double;

at com.github.jmkgreen.morphia.mapping.DefaultCreator.createInst(DefaultCreator.java:123)

at com.github.jmkgreen.morphia.mapping.DefaultCreator.createInstance(DefaultCreator.java:31)

at com.github.jmkgreen.morphia.mapping.DefaultCreator.createInstance(DefaultCreator.java:41)

at com.github.jmkgreen.morphia.mapping.DefaultCreator.createInstance(DefaultCreator.java:52)

at com.github.jmkgreen.morphia.mapping.EmbeddedMapper.readMapOrCollectionOrEntity(EmbeddedMapper.java:234)

at com.github.jmkgreen.morphia.mapping.EmbeddedMapper.readCollection(EmbeddedMapper.java:180)

at com.github.jmkgreen.morphia.mapping.EmbeddedMapper.fromDBObject(EmbeddedMapper.java:124)

... 34 more

Caused by: com.github.jmkgreen.morphia.mapping.MappingException: No usable constructor for [Ljava.lang.Double;

at com.github.jmkgreen.morphia.mapping.DefaultCreator.getNoArgsConstructor(DefaultCreator.java:146)

at com.github.jmkgreen.morphia.mapping.DefaultCreator.createInst(DefaultCreator.java:121)

... 40 more

Caused by: java.lang.NoSuchMethodException: [Ljava.lang.Double;.<init>()

at java.lang.Class.getConstructor0(Class.java:2721)

at java.lang.Class.getDeclaredConstructor(Class.java:2002)

at com.github.jmkgreen.morphia.mapping.DefaultCreator.getNoArgsConstructor(DefaultCreator.java:142)

... 41 more

How would you like me to log these? On github?

I am hoping to make some minor modifications to the code myself including:

* make it possible for BasicDAO to be defined using an interface as a type and mapping the concrete class

* potentially adding in a default no-arg constructor for helping deployment into Java EE environments.

I can package the changes up and send it across if I get it working.

Shri

[James Green]

Hi,

I just cloned the repo into a completely fresh local folder and ran mvn clean install. All worked fine.

The tests that fail inconsistently are testing performance and happen on my machine occasionally too. Wrong place to be running them really - needs a dedicated or at least otherwise idle CI server IMHO but I'm not sure where to acquire one on open source terms already hosted.

The RuntimeException looks odd, to be honest. In fact, Google knows only of one identical case - within Morphia, reported around one year ago. In my limited experience, weird RuntimeExceptions like this can be the result of partially stale files; running mvn clean clears things up. But since you have a new checkout I'm unsure.

The EE stuff I'm particularly interested in. It's an area Morphia should be able to fill a void. BasicDAO genuinely sounds like a base class so turning this into an interface may be counter-intuitive and would certainly cause grief for those of us extending it. I was thinking more along the lines of wrapping both Mongo and Morphia up within some CDI managed beans that produce injectable services factory-style. There seems little justification in making them EJBs given MongoDB does not have transactions. CDI sounds like a better fit to me.

Incidentally, this is brilliant: http://germanescobar.net/2010/04/4-areas-of-possible-confusion-in-jee6.html/

I now have Sonartype repo access granted and PGP signing automated. Can you try and get the build to work on your machine. If it works without changes I'll send the code to staging and get the ball rolling for a production release. If you can't get it to work at all submit a bug on github and include your environment, I'll try to reproduce.

Once a release is successfully into Maven Central I'll add some better content to the README.md for github - try to attract some more attention. Some examples of use would be great in Java SE and EE projects.

Thanks,

James

[James Green]

Hi,

I have opened a bug on my github fork about the mapping error. It seems to work with Java 6 but not Java 7 - the Double converter fails to fire leading to incorrect code being called later.

On 11 October 2012 17:02, Shriram Shrikumar <shriram....@gmail.com> wrote:

[James Green]

Hi,

This should now be fixed. There is, however, another test that now fails - only with openjdk7 it seems and not with openjdk6 or oraclejdk7. Could you try it?

Thanks,

James

On 11 October 2012 17:02, Shriram Shrikumar <shriram....@gmail.com> wrote: