Play + MongoDB gives ClassCastException

[steven.headley]

Hello all,
I tried to deploy my Play application to openshift which uses
MongoDB as the Database. This application uploads an image to the
backend. It works fine locally, but when I try to upload an image
after a deploy to openshift i get:

ClassCastException occured : org.bson.types.ObjectId cannot be cast to
java.lang.Long
14:27:50,537 INFO [stdout] (http--127.1.2.1-8080-2)
14:27:50,537 INFO [stdout] (http--127.1.2.1-8080-2)
play.exceptions.JavaExecutionException: org.bson.types.ObjectId cannot
be cast to java.lang.Long
14:27:50,538 INFO [stdout] (http--127.1.2.1-8080-2) at
play.mvc.ActionInvoker.invoke(ActionInvoker.java:228)
14:27:50,538 INFO [stdout] (http--127.1.2.1-8080-2) at
play.server.ServletWrapper
$ServletInvocation.execute(ServletWrapper.java:540)
14:27:50,538 INFO [stdout] (http--127.1.2.1-8080-2) at play.Invoker
$Invocation.run(Invoker.java:265)


Below please find the code:

View:

#{extends 'main.html' /}
#{set title:'Home' /}
<ul>
#{list items:models.Event.findAll(), as:'event'}
<li>${event.id} <img src="@{Upload.getEvent(event.id)}" /><h2>$
{event.ticket}</h2></li>
<button onclick="playStream()">Listen Live</button>
#{/list}
</ul>

#{form @Upload.uploadEvent(), enctype:'multipart/form-data'}
<p class="field">
<label for="ticket">Ticket Information</label>
<input type="text" id="ticket" name="event.ticket" value="$
{event?.ticket}">
<span class="error">${errors.forKey('event.ticket')}</span>
</p>
<input type="file" name="event.image" />
<input type="submit" name="submit" value="Save" />
#{/form}


Controller:

public class Upload extends Controller {

public static void index() {
render();
}

public static void uploadEvent(Event event) {
Logger.info("Action executed ...Ticket = "+event.ticket);
Logger.info("Action executed ...Ticket = "+event.image);
event.save();
index();
}
public static void getEvent(Long id) {
Event event = Event.findById(id);
// response.setContentTypeIfNotSet(event.image.type());
notFoundIfNull(event);
notFoundIfNull(event.image);
renderBinary(event.image.get());
}
}


Model:

import com.google.code.morphia.annotations.Entity;


import play.data.validation.Required;
import play.modules.morphia.Blob;
import play.modules.morphia.Model;
import com.google.code.morphia.annotations.Id;


@Entity
public class Event extends Model {

@Required
public String ticket;

public Blob image;


}


Any help would be greatly appreciated


Regards

[green]

if you use Long as id, you need to put " morphia.id.type=Long " in your application.conf file. Check out  http://www.playframework.org/modules/morphia-1.2.4d/model#id 

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[steven.headley]

I did use My use: morphia.id.type=Long in my application.conf. I
forgot to post it.

On Jan 27, 1:43 am, green <greenlaw...@gmail.com> wrote:
> if you use Long as id, you need to put " morphia.id.type=Long " in your

> application.conf file. Check outhttp://www.playframework.org/modules/morphia-1.2.4d/model#id

[Dan Miller]

I was having the same issue. I ran play deps --sync and the issue was
resolved. I don't know why syncing the dependencies resolved the
problem however.

Dan

On Jan 27, 1:07 pm, "steven.headley" <steven.head...@gmail.com> wrote:
> I did use My use:morphia.id.type=Longin my application.conf. I

> forgot to post it.
>
> On Jan 27, 1:43 am, green <greenlaw...@gmail.com> wrote:
>
>
>
>
>
>
>

> > if you useLongasid, you need to put "morphia.id.type=Long" in your

[Brainztorm]

Hi Players,

I've had the same issue, for the record i resolved this by simply deleting the @Entity on the model class concerned by the cast exception, reload my browser, came back on the model class and undo the deletion of the @Entity.

Strange ... maybe there is some sort of cache somewhere for the entities witch is not flush when switch to "morphia.id.type=Long" ...

Have a good day ! :)

François.

> > > To post to this group, send email to play-framework@googlegroups.com.

> > > To unsubscribe from this group, send email to

> > > play-framework+unsubscribe@googlegroups.com.

[green]

Once you switched the id type you need to do a 'play clean' so that morphia enhancer has a chance to process your model class byte code for the updates. Deleting and adding @Entity roughly does the same thing, say, to invalidate the byte code cache in your harddisk.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/Ae1bpoyalwwJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[Brainztorm]

Thanks for the tip and your great module Green :)

@+

François.

[Brainztorm]

By the way, is there any risk (corruption/too much casts ...) using this feature ? ( morphia.id.type=Long + getId(Long.class))

[green]

I suppose the biggest concern is generate a Long ID needs to synchronized on the model class because it will lookup the last id value in your mongodb and update it. There is no real concern on casts except the code looks not very clean

On Thu, Jun 7, 2012 at 10:10 PM, Brainztorm <brain...@gmail.com> wrote:

By the way, is there any risk (corruption/too much casts ...) using this feature ? ( morphia.id.type=Long + getId(Long.class))

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/Ixq1__woY6IJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[François]

Thanks for your answer :)

 … but i'm afraid of leaving some important informations by using Long ids … the ObjectId is a special format :

"

• TimeStamp. This is a unix style timestamp. It is a signed int representing the number of seconds before or after January 1st 1970 (UTC).

• Machine. This is the first three bytes of the (md5) hash of the machine host name, or of the mac/network address, or the virtual machine id.

• Pid. This is 2 bytes of the process id (or thread id) of the process generating the object id.

• Increment. This is an ever incrementing value, or a random number if a counter can't be used in the language/runtime.

"

from http://www.mongodb.org/display/DOCS/Object+IDs

Maybe this format is useful when sharding or for replication identifying entities to handle them (i think of the machine part of the objectId spec) ?

What do you think ?

[François]

I think i've found my answer:

"

Using sequence numbers in a sharded / distributed environment is not 

scalable because you require a single central node to hand out those 

sequence numbers. At some point, you'll reach the limit of that node 

to hand out ID's. Since ObjectIDs are generated by clients without 

coordination, there is no bottleneck as you scale your system up.

"

From Jared Rosoff working at 10gen

"

One thing to note is that the ObjectIDs are actually created by the 

client. If you have multiple clients (potentially on multiple 

machines) you will be less likely to have "_id" collisions using 

ObjectIDs because of the structure of an ObjectID. In the context of 

sharding specifically (ignoring all the other issues previously 

mentioned in this thread) an ObjectID won't necessarily work better 

than a sequence and obviously isn't more compact than an int64.

"

From Bernie Hackett

source: http://groups.google.com/group/mongodb-user/browse_thread/thread/5b3794e1fc8b77b8

Thanks for your time and effort Green :)