Closed GoogleCodeExporter closed 9 years ago
Also, just to clarify, ContentIdentifierImpl contains the id property, which is
what seems to be failing.
@Override
public Long getId() {
return this.id;
}
@Override
public void setId( Long id ) {
this.id = id;
}
Why a Long would be getting interpreted as a Serializable is mystifying to me.
Original comment by murp...@gmail.com
on 6 Jan 2015 at 8:00
Well, since you do not give the complete source my guess is that the
ContentIdentifierImpl class needs a single argument constructor, because your
YAML documents expects it (the document would be also helpful to see).
Solution 1:
public ContentIdentifierImpl(Long id) {
this.id = id;
{
Solution 2:
change YAML to avoid single argument constructor
Original comment by py4fun@gmail.com
on 6 Jan 2015 at 9:28
Thanks for the quick response.
After further investigation, I believe our problem is a combination of using
generics to define the type for the id from a super class and a possible JVM
bug (this this occurs sporadically). We are going to try to remove the generic
interface definition and see if that fixes the problem. The interfaces in
question are defined as such:
public interface ContentIdentifier extends Identifiable<Long>
then:
public interface Identifiable<ID extends Serializable> {
ID getId();
}
I will report back on the results.
Original comment by murp...@gmail.com
on 7 Jan 2015 at 1:38
Well, SnakeYAML does a lot of magic to support generics. If you can provide a
small test to reproduce the problem we can further investigate the cause.
In the past we also experienced different failures for different platforms (and
JDK versions). It may be related only to the platform you use.
Original comment by py4fun@gmail.com
on 7 Jan 2015 at 11:27
I wrote a test for this issue and does not fail.
Can you please check it ?
https://code.google.com/p/snakeyaml/source/detail?r=879e957656c95ca3e896988af2fd
d2e22bd244df
Original comment by py4fun@gmail.com
on 8 Jan 2015 at 5:53
I made some minor changes to your test case to better align with our code. I
put in a loop to run it 10,000 times since the problem occurs occasionally. No
error. When I can get a few minutes I will try to run it the same JVM as our
server and see what it does. Stay tuned.
Original comment by murp...@gmail.com
on 8 Jan 2015 at 8:07
I cannot reproduce within your test project, even running it a million times on
the same JVM producing the problem. I even included the same 1.14 dependency
that our project is using. I need to think a bit more on this and how it can be
reproduced. Thanks.
Original comment by murp...@gmail.com
on 9 Jan 2015 at 1:57
Original issue reported on code.google.com by
murp...@gmail.com
on 6 Jan 2015 at 7:52