openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <>
Subject Re: Metamodel generates ListAttribute for arrays instead of SingularAttribute
Date Wed, 06 Jul 2011 13:08:40 GMT
I know I am late to this party, but just to give more concreteness to the
scenario that Mike was describing...

I was working with a customer that hit this exact situation.  The metamodel
code generated by Dali was not processable by our OpenJPA runtime.  When
this customer would generate his metamodel classes with OpenJPA, then
OpenJPA would process just fine.  Without digging into the exact situation
sufficiently, I thought the problem was with Dali and a bug report was
opened against Dali.

As we dug into the situation a bit further, we discovered the JPA spec
references that Mike outlined previously.  And, thus this conversation...

I just wanted to document that this wasn't just some wild testing or unique
scenario that we dreamed up.  It was a real (WebSphere) customer that hit
this problem and we're trying to figure out the proper source of the error
and get it cleaned up.


On Thu, Jun 30, 2011 at 11:37 AM, Michael Dick <>wrote:

> The issue was raised to me via Dali. Based on this discussion I'd say that
> their metamodel generator handles byte[] correctly, suggesting they add a
> feature to use ours seems a bit backwards.
> I suspect that fixing it would be more difficult than I'd like. That said,
> we don't persist generic arrays unless they use @PersistentCollection, if
> we
> have FieldMetaData whenever we make a decision, it shouldn't be too bad.
> -mike
> On Thu, Jun 30, 2011 at 11:14 AM, Pinaki Poddar <>
> wrote:
> > You also mentioned that the canonical metamodel must match what Dali
> > decided
> > for byte[] as SingularAttibute (which, of course, is a gray area because
> > JPA
> > spec is almost silent about arrays of any component type). In fact, Dali
> > folks, if they have provision for each vendor, allow the vendo to
> generate
> > these metamodel classes rather than generating by themselves o using a
> > specific providers tooling.
> >
> > But given that ali-compliance is also a 'requirement', the source code
> > generation of annotation processor also needs to be tweaked. My hunch is
> > treating arrays differently based on its component type is not going to
> be
> > pretty overall.
> >
> > -----
> > Pinaki
> > --
> > View this message in context:
> >
> > Sent from the OpenJPA Developers mailing list archive at
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message