Re: trying to run JPA Console inside Intellij IDEA results in this....

[Marc Logemann]

Just looking around in OpenJPA code i wonder why my enhanced
Distribution.class is calling the ProxySetupStateManager.providedIntField()
Method (which always throws Exceptions) instead of calling
StateManagerImpl.class method.

I am really wondering if nobody is using OpenJPA in the JPA console from
Jetbrains IDEA IDE.



2016-09-22 21:59 GMT+02:00 Marc Logemann :

> Compiled from "Distribution.java"
>
> public class de.netversys.domain.Distribution extends 
> de.netversys.domain.AbstractEntity
> implements org.apache.openjpa.enhance.PersistenceCapable {
>
>
> So. Yes. it is enhanced. Same goes for other classes i checked. Must be
> something different.
>
> 2016-09-22 10:15 GMT+02:00 Mark Struberg :
>
>> oh another thing which makes me curious.
>>
>> IIRC then we only use the
>> ProxySetupStateManager.java:230in case of subclassing if the entities
>> did not get properly enhanced at all.
>>
>> This means you are not using build-time enhancement and also no javaagent.
>>
>> Can you please check the classfile?
>>
>> $> javap -c target/classes/de/netversys/domain/Distribution.class | less
>>
>>
>> And check whether the class has a PersistenceCapable interface in the
>> bytecode.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> > On Thursday, 22 September 2016, 8:02, Mark Struberg
>>  wrote:
>> > > Yes, it contains the number of the field it has problems with as int.
>> >
>> > Counting of fields start with the uppermost entity class. The fild
>> numbers get
>> > generated during enhancement.
>> >
>> > LieGrue,
>> > Strub
>> >
>> >
>> >>  Am 21.09.2016 um 23:25 schrieb Marc Logemann
>> > :
>> >>
>> >>  And when u look at the stacktrace on this line:
>> >>
>> >>  at de.netversys.domain.Distribution.pcProvideField(Distribution.java)
>> >>
>> >>  you see a method which wouldnt be there if the class is not enhanced
>> right?
>> >>
>> >>  2016-09-21 22:00 GMT+02:00 Mark Struberg :
>> >>>  MappedSuperclasses should not be any problem. At least if it got
>> > enhanced as well. Are you missing this probably?
>> >>>
>> >>>  LieGrue,
>> >>>  strub
>> >>>
>> >>>
>> >>>
>> >>>  On Wednesday, 21 September 2016, 21:57, Marc Logemann
>> >  wrote>
>> >>>  >Hi,
>> >>>  >
>> >>>  >
>> >>>  >yeah. Every entity extends AbstractEntity which is a
>> > MappedSuperclass.
>> >>>  >
>> >>>  >
>> >>>  >2016-09-21 20:15 GMT+02:00 Mark Struberg
>> > :
>> >>>  >
>> >>>  >Hi Marc!
>> >>>  >>
>> >>>  >>Is the entity Distribution part of a supertype/subtype
>> > constellation aka inheritance?
>> >>>  >>Does this class 'extends' something? And where do these
>> > classes reside?
>> >>>  >>
>> >>>  >>
>> >>>  >>LieGrue,
>> >>>  >>strub
>> >>>  >>
>> >>>  >>
>> >>>  >>
>> >>>  >>
>> >>>  >>
>> >>>  >>
>> >>>  >>> On Wednesday, 21 September 2016, 18:27, Marc Logemann
>> >  wrote:
>> >>>  >>> > can somebody hint me where i need to look out for?
>> > Quite weird message
>> >>>  >>>
>> >>>  >>>
>> >>>  >>> [2016-09-21 18:24:13] > > fatal user error>
>> >>>  >>> org.apache.openjpa. persistence.ArgumentException: Errors
>> > encountered while
>> >>>  >>> resolving metadata.  See nested exceptions for details.
>> >>>  >>> [2016-09-21 18:24:13] java.lang.RuntimeException:
>> >>>  >>> 
>> >>>  >>> org.apache.openjpa. persistence. PersistenceException:
>> > Unexpected attribute
>> >>>  >>> type "int" for persistence-capable class
>> >>>  >>> "de.netversys.domain. Distribution"
>> >>>  >>> is detected. If the entity is packaged in a jar file, this
>> > may be caused by
>> >>>  >>> one or more inherited class of

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Marc Logemann]

Compiled from "Distribution.java"

public class de.netversys.domain.Distribution extends
de.netversys.domain.AbstractEntity implements
org.apache.openjpa.enhance.PersistenceCapable {


So. Yes. it is enhanced. Same goes for other classes i checked. Must be
something different.

2016-09-22 10:15 GMT+02:00 Mark Struberg :

> oh another thing which makes me curious.
>
> IIRC then we only use the
> ProxySetupStateManager.java:230in case of subclassing if the entities did
> not get properly enhanced at all.
>
> This means you are not using build-time enhancement and also no javaagent.
>
> Can you please check the classfile?
>
> $> javap -c target/classes/de/netversys/domain/Distribution.class | less
>
>
> And check whether the class has a PersistenceCapable interface in the
> bytecode.
>
> LieGrue,
> strub
>
>
>
>
> > On Thursday, 22 September 2016, 8:02, Mark Struberg
>  wrote:
> > > Yes, it contains the number of the field it has problems with as int.
> >
> > Counting of fields start with the uppermost entity class. The fild
> numbers get
> > generated during enhancement.
> >
> > LieGrue,
> > Strub
> >
> >
> >>  Am 21.09.2016 um 23:25 schrieb Marc Logemann
> > :
> >>
> >>  And when u look at the stacktrace on this line:
> >>
> >>  at de.netversys.domain.Distribution.pcProvideField(Distribution.java)
> >>
> >>  you see a method which wouldnt be there if the class is not enhanced
> right?
> >>
> >>  2016-09-21 22:00 GMT+02:00 Mark Struberg :
> >>>  MappedSuperclasses should not be any problem. At least if it got
> > enhanced as well. Are you missing this probably?
> >>>
> >>>  LieGrue,
> >>>  strub
> >>>
> >>>
> >>>
> >>>  On Wednesday, 21 September 2016, 21:57, Marc Logemann
> >  wrote>
> >>>  >Hi,
> >>>  >
> >>>  >
> >>>  >yeah. Every entity extends AbstractEntity which is a
> > MappedSuperclass.
> >>>  >
> >>>  >
> >>>  >2016-09-21 20:15 GMT+02:00 Mark Struberg
> > :
> >>>  >
> >>>  >Hi Marc!
> >>>  >>
> >>>  >>Is the entity Distribution part of a supertype/subtype
> > constellation aka inheritance?
> >>>  >>Does this class 'extends' something? And where do these
> > classes reside?
> >>>  >>
> >>>  >>
> >>>  >>LieGrue,
> >>>  >>strub
> >>>  >>
> >>>  >>
> >>>  >>
> >>>  >>
> >>>  >>
> >>>  >>
> >>>  >>> On Wednesday, 21 September 2016, 18:27, Marc Logemann
> >  wrote:
> >>>  >>> > can somebody hint me where i need to look out for?
> > Quite weird message
> >>>  >>>
> >>>  >>>
> >>>  >>> [2016-09-21 18:24:13]  > fatal user error>
> >>>  >>> org.apache.openjpa. persistence.ArgumentException: Errors
> > encountered while
> >>>  >>> resolving metadata.  See nested exceptions for details.
> >>>  >>> [2016-09-21 18:24:13] java.lang.RuntimeException:
> >>>  >>> 
> >>>  >>> org.apache.openjpa. persistence. PersistenceException:
> > Unexpected attribute
> >>>  >>> type "int" for persistence-capable class
> >>>  >>> "de.netversys.domain. Distribution"
> >>>  >>> is detected. If the entity is packaged in a jar file, this
> > may be caused by
> >>>  >>> one or more inherited class of the entity not being
> > packaged in the same
> >>>  >>> jar file. Please check all inherited class(es) are
> > packaged in the same jar
> >>>  >>> file.
> >>>  >>> at
> >>>  >>> org.apache.openjpa.meta. ProxySetupStateManager.
> > providedIntField( ProxySetupStateManager.java: 230)
> >>>  >>> at de.netversys.domain. Distribution.pcProvideField(
> > Distribution.java)
> >>>  >>> at
> >>>  >>> org.apache.openjpa.meta. ProxySetupStateManager.
> > setProxyData( ProxySetupStateManager.java: 62)
> >>>  >>> at
> >>>  >>> org.apache.openjpa.meta. ClassMetaData.resolveMeta(
> > ClassMetaData.java:1927)
> >>>  >>

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Marc Logemann]

And when u look at the stacktrace on this line:

at de.netversys.domain.Distribution.pcProvideField(Distribution.java)

you see a method which wouldnt be there if the class is not enhanced right?

2016-09-21 22:00 GMT+02:00 Mark Struberg :

> MappedSuperclasses should not be any problem. At least if it got enhanced
> as well. Are you missing this probably?
>
> LieGrue,
> strub
>
>
>
> On Wednesday, 21 September 2016, 21:57, Marc Logemann <
> marc.logem...@gmail.com> wrote>
> >Hi,
> >
> >
> >yeah. Every entity extends AbstractEntity which is a MappedSuperclass.
> >
> >
> >2016-09-21 20:15 GMT+02:00 Mark Struberg :
> >
> >Hi Marc!
> >>
> >>Is the entity Distribution part of a supertype/subtype constellation aka
> inheritance?
> >>Does this class 'extends' something? And where do these classes reside?
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Wednesday, 21 September 2016, 18:27, Marc Logemann <
> marc.logem...@gmail.com> wrote:
> >>> > can somebody hint me where i need to look out for? Quite weird
> message
> >>>
> >>>
> >>> [2016-09-21 18:24:13] 
> >>> org.apache.openjpa. persistence.ArgumentException: Errors encountered
> while
> >>> resolving metadata.  See nested exceptions for details.
> >>> [2016-09-21 18:24:13] java.lang.RuntimeException:
> >>> 
> >>> org.apache.openjpa. persistence. PersistenceException: Unexpected
> attribute
> >>> type "int" for persistence-capable class
> >>> "de.netversys.domain. Distribution"
> >>> is detected. If the entity is packaged in a jar file, this may be
> caused by
> >>> one or more inherited class of the entity not being packaged in the
> same
> >>> jar file. Please check all inherited class(es) are packaged in the
> same jar
> >>> file.
> >>> at
> >>> org.apache.openjpa.meta. ProxySetupStateManager. providedIntField(
> ProxySetupStateManager.java: 230)
> >>> at de.netversys.domain. Distribution.pcProvideField( Distribution.java)
> >>> at
> >>> org.apache.openjpa.meta. ProxySetupStateManager. setProxyData(
> ProxySetupStateManager.java: 62)
> >>> at
> >>> org.apache.openjpa.meta. ClassMetaData.resolveMeta(
> ClassMetaData.java:1927)
> >>> at org.apache.openjpa.meta. ClassMetaData.resolve(
> ClassMetaData.java:1808)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. processBuffer(
> MetaDataRepository.java:829)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. resolveMeta(
> MetaDataRepository.java:726)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository.resolve(
> MetaDataRepository.java:650)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaDataInternal(
> MetaDataRepository.java:418)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaData(
> MetaDataRepository.java:389)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaData(
> MetaDataRepository.java:472)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getClassMetaData( JPQLExpressionBuilder.java: 175)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> resolveClassMetaData( JPQLExpressionBuilder.java: 151)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getCandidateMetaData( JPQLExpressionBuilder.java: 241)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getCandidateMetaData( JPQLExpressionBuilder.java: 211)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getCandidateType( JPQLExpressionBuilder.java: 204)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. access$200(
> JPQLExpressionBuilder.java:79)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder$
> ParsedJPQL.populate( JPQLExpressionBuilder.java: 2426)
> >>> at org.apache.openjpa.kernel. jpql.JPQLParser.populate(
> JPQLParser.java:60)
> >>> at
> >>> org.apache.openjpa.kernel. ExpressionStoreQuery.
> populateFromCompilation( ExpressionStoreQuery.java:162)
> >>> at org.apache.openjpa.kernel. QueryImpl.newCompilation(
> QueryImpl.java:672)
> >>> at
> >>> org.apache.openjpa.kernel. QueryImpl. compilationFromCache(
> QueryImpl.java:653)
> >>> at
> >>> org.apache.openjpa.kernel. QueryImpl. compileForCompilation(
> QueryImpl.java:619)
> >>> at
> >>> org.apache.openjpa.kernel. QueryImpl.compileForExecutor(
> QueryImpl.java:681)
> >>> at org.apache.openjpa.kernel. QueryImpl.compile(QueryImpl. java:588)
> >>> at
> >>> org.apache.openjpa. persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl. java:996)
> >>> at
> >>> org.apache.openjpa. persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl. java:978)
> >>> at
> >>> org.apache.openjpa. persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl. java:101)
> >>> at
> >>> com.intellij.jpa.remote.impl. RemoteEntityManagerImpl. createQuery(
> RemoteEntityManagerImpl.java: 39)
> >>>
> >>
> >
> >
> >
>

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Marc Logemann]

Hi,

no. All classes are enhanced of course. Tripple-checked that before i
posted IMO there would be a different ErrorMessage when a class is not
enhanced anyway.

marc

2016-09-21 22:00 GMT+02:00 Mark Struberg :

> MappedSuperclasses should not be any problem. At least if it got enhanced
> as well. Are you missing this probably?
>
> LieGrue,
> strub
>
>
>
> On Wednesday, 21 September 2016, 21:57, Marc Logemann <
> marc.logem...@gmail.com> wrote>
> >Hi,
> >
> >
> >yeah. Every entity extends AbstractEntity which is a MappedSuperclass.
> >
> >
> >2016-09-21 20:15 GMT+02:00 Mark Struberg :
> >
> >Hi Marc!
> >>
> >>Is the entity Distribution part of a supertype/subtype constellation aka
> inheritance?
> >>Does this class 'extends' something? And where do these classes reside?
> >>
> >>
> >>LieGrue,
> >>strub
> >>
> >>
> >>
> >>
> >>
> >>
> >>> On Wednesday, 21 September 2016, 18:27, Marc Logemann <
> marc.logem...@gmail.com> wrote:
> >>> > can somebody hint me where i need to look out for? Quite weird
> message
> >>>
> >>>
> >>> [2016-09-21 18:24:13] 
> >>> org.apache.openjpa. persistence.ArgumentException: Errors encountered
> while
> >>> resolving metadata.  See nested exceptions for details.
> >>> [2016-09-21 18:24:13] java.lang.RuntimeException:
> >>> 
> >>> org.apache.openjpa. persistence. PersistenceException: Unexpected
> attribute
> >>> type "int" for persistence-capable class
> >>> "de.netversys.domain. Distribution"
> >>> is detected. If the entity is packaged in a jar file, this may be
> caused by
> >>> one or more inherited class of the entity not being packaged in the
> same
> >>> jar file. Please check all inherited class(es) are packaged in the
> same jar
> >>> file.
> >>> at
> >>> org.apache.openjpa.meta. ProxySetupStateManager. providedIntField(
> ProxySetupStateManager.java: 230)
> >>> at de.netversys.domain. Distribution.pcProvideField( Distribution.java)
> >>> at
> >>> org.apache.openjpa.meta. ProxySetupStateManager. setProxyData(
> ProxySetupStateManager.java: 62)
> >>> at
> >>> org.apache.openjpa.meta. ClassMetaData.resolveMeta(
> ClassMetaData.java:1927)
> >>> at org.apache.openjpa.meta. ClassMetaData.resolve(
> ClassMetaData.java:1808)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. processBuffer(
> MetaDataRepository.java:829)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. resolveMeta(
> MetaDataRepository.java:726)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository.resolve(
> MetaDataRepository.java:650)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaDataInternal(
> MetaDataRepository.java:418)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaData(
> MetaDataRepository.java:389)
> >>> at
> >>> org.apache.openjpa.meta. MetaDataRepository. getMetaData(
> MetaDataRepository.java:472)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getClassMetaData( JPQLExpressionBuilder.java: 175)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> resolveClassMetaData( JPQLExpressionBuilder.java: 151)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getCandidateMetaData( JPQLExpressionBuilder.java: 241)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getCandidateMetaData( JPQLExpressionBuilder.java: 211)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder.
> getCandidateType( JPQLExpressionBuilder.java: 204)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder. access$200(
> JPQLExpressionBuilder.java:79)
> >>> at
> >>> org.apache.openjpa.kernel. jpql.JPQLExpressionBuilder$
> ParsedJPQL.populate( JPQLExpressionBuilder.java: 2426)
> >>> at org.apache.openjpa.kernel. jpql.JPQLParser.populate(
> JPQLParser.java:60)
> >>> at
> >>> org.apache.openjpa.kernel. ExpressionStoreQuery.
> populateFromCompilation( ExpressionStoreQuery.java:162)
> >>> at org.apache.openjpa.kernel. QueryImpl.newCompilation(
> QueryImpl.java:672)
> >>> at
> >>> org.apache.openjpa.kernel. QueryImpl. compilationFromCache(
> QueryImpl.java:653)
> >>> at
> >>> org.apache.openjpa.kernel. QueryImpl. compileForCompilation(
> QueryImpl.java:619)
> >>> at
> >>> org.apache.openjpa.kernel. QueryImpl.compileForExecutor(
> QueryImpl.java:681)
> >>> at org.apache.openjpa.kernel. QueryImpl.compile(QueryImpl. java:588)
> >>> at
> >>> org.apache.openjpa. persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl. java:996)
> >>> at
> >>> org.apache.openjpa. persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl. java:978)
> >>> at
> >>> org.apache.openjpa. persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl. java:101)
> >>> at
> >>> com.intellij.jpa.remote.impl. RemoteEntityManagerImpl. createQuery(
> RemoteEntityManagerImpl.java: 39)
> >>>
> >>
> >
> >
> >
>

Re: trying to run JPA Console inside Intellij IDEA results in this....

[Marc Logemann]

Hi,

yeah. Every entity extends AbstractEntity which is a MappedSuperclass.

2016-09-21 20:15 GMT+02:00 Mark Struberg :

> Hi Marc!
>
> Is the entity Distribution part of a supertype/subtype constellation aka
> inheritance?
> Does this class 'extends' something? And where do these classes reside?
>
>
> LieGrue,
> strub
>
>
>
>
>
> > On Wednesday, 21 September 2016, 18:27, Marc Logemann <
> marc.logem...@gmail.com> wrote:
> > > can somebody hint me where i need to look out for? Quite weird
> message
> >
> >
> > [2016-09-21 18:24:13] 
> > org.apache.openjpa.persistence.ArgumentException: Errors encountered
> while
> > resolving metadata.  See nested exceptions for details.
> > [2016-09-21 18:24:13] java.lang.RuntimeException:
> > 
> > org.apache.openjpa.persistence.PersistenceException: Unexpected
> attribute
> > type "int" for persistence-capable class
> > "de.netversys.domain.Distribution"
> > is detected. If the entity is packaged in a jar file, this may be caused
> by
> > one or more inherited class of the entity not being packaged in the same
> > jar file. Please check all inherited class(es) are packaged in the same
> jar
> > file.
> > at
> > org.apache.openjpa.meta.ProxySetupStateManager.providedIntField(
> ProxySetupStateManager.java:230)
> > at de.netversys.domain.Distribution.pcProvideField(Distribution.java)
> > at
> > org.apache.openjpa.meta.ProxySetupStateManager.setProxyData(
> ProxySetupStateManager.java:62)
> > at
> > org.apache.openjpa.meta.ClassMetaData.resolveMeta(
> ClassMetaData.java:1927)
> > at org.apache.openjpa.meta.ClassMetaData.resolve(
> ClassMetaData.java:1808)
> > at
> > org.apache.openjpa.meta.MetaDataRepository.processBuffer(
> MetaDataRepository.java:829)
> > at
> > org.apache.openjpa.meta.MetaDataRepository.resolveMeta(
> MetaDataRepository.java:726)
> > at
> > org.apache.openjpa.meta.MetaDataRepository.resolve(
> MetaDataRepository.java:650)
> > at
> > org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(
> MetaDataRepository.java:418)
> > at
> > org.apache.openjpa.meta.MetaDataRepository.getMetaData(
> MetaDataRepository.java:389)
> > at
> > org.apache.openjpa.meta.MetaDataRepository.getMetaData(
> MetaDataRepository.java:472)
> > at
> > org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(
> JPQLExpressionBuilder.java:175)
> > at
> > org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.
> resolveClassMetaData(JPQLExpressionBuilder.java:151)
> > at
> > org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.
> getCandidateMetaData(JPQLExpressionBuilder.java:241)
> > at
> > org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.
> getCandidateMetaData(JPQLExpressionBuilder.java:211)
> > at
> > org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(
> JPQLExpressionBuilder.java:204)
> > at
> > org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$200(
> JPQLExpressionBuilder.java:79)
> > at
> > org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$
> ParsedJPQL.populate(JPQLExpressionBuilder.java:2426)
> > at org.apache.openjpa.kernel.jpql.JPQLParser.populate(
> JPQLParser.java:60)
> > at
> > org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(
> ExpressionStoreQuery.java:162)
> > at org.apache.openjpa.kernel.QueryImpl.newCompilation(
> QueryImpl.java:672)
> > at
> > org.apache.openjpa.kernel.QueryImpl.compilationFromCache(
> QueryImpl.java:653)
> > at
> > org.apache.openjpa.kernel.QueryImpl.compileForCompilation(
> QueryImpl.java:619)
> > at
> > org.apache.openjpa.kernel.QueryImpl.compileForExecutor(
> QueryImpl.java:681)
> > at org.apache.openjpa.kernel.QueryImpl.compile(QueryImpl.java:588)
> > at
> > org.apache.openjpa.persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl.java:996)
> > at
> > org.apache.openjpa.persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl.java:978)
> > at
> > org.apache.openjpa.persistence.EntityManagerImpl.
> createQuery(EntityManagerImpl.java:101)
> > at
> > com.intellij.jpa.remote.impl.RemoteEntityManagerImpl.createQuery(
> RemoteEntityManagerImpl.java:39)
> >
>

trying to run JPA Console inside Intellij IDEA results in this....

[Marc Logemann]

can somebody hint me where i need to look out for? Quite weird message


[2016-09-21 18:24:13] 
org.apache.openjpa.persistence.ArgumentException: Errors encountered while
resolving metadata.  See nested exceptions for details.
[2016-09-21 18:24:13] java.lang.RuntimeException:

org.apache.openjpa.persistence.PersistenceException: Unexpected attribute
type "int" for persistence-capable class "de.netversys.domain.Distribution"
is detected. If the entity is packaged in a jar file, this may be caused by
one or more inherited class of the entity not being packaged in the same
jar file. Please check all inherited class(es) are packaged in the same jar
file.
at
org.apache.openjpa.meta.ProxySetupStateManager.providedIntField(ProxySetupStateManager.java:230)
at de.netversys.domain.Distribution.pcProvideField(Distribution.java)
at
org.apache.openjpa.meta.ProxySetupStateManager.setProxyData(ProxySetupStateManager.java:62)
at
org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1927)
at org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1808)
at
org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:829)
at
org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:726)
at
org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:650)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:418)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:389)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:472)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:175)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:151)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:241)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:211)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:204)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$200(JPQLExpressionBuilder.java:79)
at
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:2426)
at org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:60)
at
org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:162)
at org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:672)
at
org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:653)
at
org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:619)
at
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:681)
at org.apache.openjpa.kernel.QueryImpl.compile(QueryImpl.java:588)
at
org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:996)
at
org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:978)
at
org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:101)
at
com.intellij.jpa.remote.impl.RemoteEntityManagerImpl.createQuery(RemoteEntityManagerImpl.java:39)

Re: weird bug with order by (2.4.1)

[Marc Logemann]

I recently migrated to 2.4.1 from 2.4.0 because of this bug. So negative on
this one.

In the meantime i discovered why MariaDB has index problems. Its not
because of the second order parameter, but because of the second order
parameter which is the same field in a different table but with ASC order.
The ASC is the thing but of course the second parameter shouldnt be there
at all.

I suspect its because of the "join fetch". Just for the record, of course i
dont use @OrderBy on the relation. If i do it on the 1:n relation in
question, i get this: ORDER BY t0.oid DESC, t24.distribution_oid ASC,
t24.distribution_oid
ASC LIMIT ?, ?

Perhaps i try to downgrade a bit more because i am quite sure that this
problem is new somehow i did another upgrade from an older version to
2.4.0 a few weeks ago.

regards
marc


2016-09-10 9:48 GMT+02:00 Mark Struberg :

> Hi Marc!
>
> Can you please try with 2.4.0?
> Is the generated query the same or without the column?
>
> LieGrue,
> strub
>
>
>
>
> On Saturday, 10 September 2016, 2:14, Marc Logemann <
> marc.logem...@gmail.com> wrote:
>
>
> >
> >
> >Hi,
> >
> >i suspect i found a bug which has bad consequences on MariaDB not using an
> >index anymore. Lets take this JPAQL:
> >
> >select d from Distribution d join fetch d.distributionContainerList where
> >d.client = ?1 and d.deleted = ?2 order by d.oid desc
> >
> >My Distribution entity is quite big when it comes to 1:n relations and
> >stuff. So i wont get into the details here, but this  JPAQL will result in
> >the following SQL (compressed because too big otherwise):
> >
> >SELECT t0.oid, t0.jpaversion, t0.created, t0.createdby, ...
> >FROM distribution t0 LEFT OUTER JOIN dist_altfrom t1 ON t0.altfrom_oid
> >= t1.oid
> >LEFT OUTER JOIN clients t3 ON t0.client_oid = t3.oid LEFT OUTER
> >JOIN
> >cmrcarrier t17 ON t0.cmrcarrier_oid = t17.oid LEFT OUTER JOIN
> >countries
> >t20 ON t0.empf_country = t20.isocode2 LEFT OUTER JOIN users t21 ON
> >t0.user_oid = t21.oid INNER JOIN dist_container t24 ON t0.oid =
> >t24.distribution_oid LEFT OUTER JOIN countries t2 ON t1.country =
> >t2.isocode2 LEFT OUTER JOIN address t4 ON t3.address_oid = t4.oid
> >LEFT
> >OUTER JOIN bankaccount t6 ON t3.bankaccount_oid = t6.oid LEFT
> OUTER
> >JOIN communication t7 ON t3.communication_oid = t7.oid LEFT OUTER
> >JOIN
> >persons t8 ON t3.cperson_oid = t8.oid LEFT OUTER JOIN bankaccount
> >t10
> >ON t3.nnbankaccount_oid = t10.oid LEFT OUTER JOIN workplaces t11
> ON
> >t3.workplaceoid = t11.oid LEFT OUTER JOIN address t18 ON
> >t17.address_oid = t18.oid LEFT OUTER JOIN communication t19 ON
> >t17.communication_oid = t19.oid LEFT OUTER JOIN persons t22 ON
> >t21.person_oid = t22.oid LEFT OUTER JOIN workplaces t23 ON
> >t21.workplaceoid = t23.oid LEFT OUTER JOIN distribution t25 ON
> >t24.old_distribution_oid = t25.oid LEFT OUTER JOIN countries t5 ON
> >t4.country_id = t5.isocode2 LEFT OUTER JOIN communication t9 ON
> >t8.communication_oid = t9.oid LEFT OUTER JOIN balance t12 ON
> >t11.balance = t12.oid LEFT OUTER JOIN balance t13 ON t11.balance2
> =
> >t13.oid LEFT OUTER JOIN clients t14 ON t11.client_oid = t14.oid
> >LEFT
> >OUTER JOIN printer t15 ON t11.labelprinter = t15.oid LEFT OUTER
> >JOIN
> >printer t16 ON t11.laserprinter = t16.oid
> >WHERE (t0.client_oid = ? AND t0.deleted = ?)
> >ORDER BY t0.oid DESC, t24.distribution_oid ASC LIMIT ?, ?
> >
> >
> >Just look at the order by clause in the SQL. It correctly used t0.oid
> >because JPAQL said so. But why on earth is there another order clause with
> >the field "t24.distribution_oid" ?? This is a back reference for a 1:n
> >relation from Table "dist_container" back to "distribution".
> >
> >The real problem is: as soon as there is another sorting parameter from a
> >joined table, MariaDB doesnt use my ForeignKey Index anymore and does a
> >FULL-Scan on the t24 table, which is pretty heavy on a multi million
> >records table. When i leave out that ugly t24.distribution_oid ordering
> >field, everything is fast and ok.
> >
> >Can anyone explain to me how this ordering field gets into the picture?
> >
> >thanks
> >marc
> >
> >
> >
>

weird bug with order by (2.4.1)

[Marc Logemann]

Hi,

i suspect i found a bug which has bad consequences on MariaDB not using an
index anymore. Lets take this JPAQL:

select d from Distribution d join fetch d.distributionContainerList where
d.client = ?1 and d.deleted = ?2 order by d.oid desc

My Distribution entity is quite big when it comes to 1:n relations and
stuff. So i wont get into the details here, but this  JPAQL will result in
the following SQL (compressed because too big otherwise):

SELECT t0.oid, t0.jpaversion, t0.created, t0.createdby, ...
FROM distribution t0 LEFT OUTER JOIN dist_altfrom t1 ON t0.altfrom_oid
= t1.oid
LEFT OUTER JOIN clients t3 ON t0.client_oid = t3.oid LEFT OUTER
JOIN
cmrcarrier t17 ON t0.cmrcarrier_oid = t17.oid LEFT OUTER JOIN
countries
t20 ON t0.empf_country = t20.isocode2 LEFT OUTER JOIN users t21 ON
t0.user_oid = t21.oid INNER JOIN dist_container t24 ON t0.oid =
t24.distribution_oid LEFT OUTER JOIN countries t2 ON t1.country =
t2.isocode2 LEFT OUTER JOIN address t4 ON t3.address_oid = t4.oid
LEFT
OUTER JOIN bankaccount t6 ON t3.bankaccount_oid = t6.oid LEFT OUTER
JOIN communication t7 ON t3.communication_oid = t7.oid LEFT OUTER
JOIN
persons t8 ON t3.cperson_oid = t8.oid LEFT OUTER JOIN bankaccount
t10
ON t3.nnbankaccount_oid = t10.oid LEFT OUTER JOIN workplaces t11 ON
t3.workplaceoid = t11.oid LEFT OUTER JOIN address t18 ON
t17.address_oid = t18.oid LEFT OUTER JOIN communication t19 ON
t17.communication_oid = t19.oid LEFT OUTER JOIN persons t22 ON
t21.person_oid = t22.oid LEFT OUTER JOIN workplaces t23 ON
t21.workplaceoid = t23.oid LEFT OUTER JOIN distribution t25 ON
t24.old_distribution_oid = t25.oid LEFT OUTER JOIN countries t5 ON
t4.country_id = t5.isocode2 LEFT OUTER JOIN communication t9 ON
t8.communication_oid = t9.oid LEFT OUTER JOIN balance t12 ON
t11.balance = t12.oid LEFT OUTER JOIN balance t13 ON t11.balance2 =
t13.oid LEFT OUTER JOIN clients t14 ON t11.client_oid = t14.oid
LEFT
OUTER JOIN printer t15 ON t11.labelprinter = t15.oid LEFT OUTER
JOIN
printer t16 ON t11.laserprinter = t16.oid
WHERE (t0.client_oid = ? AND t0.deleted = ?)
ORDER BY t0.oid DESC, t24.distribution_oid ASC LIMIT ?, ?


Just look at the order by clause in the SQL. It correctly used t0.oid
because JPAQL said so. But why on earth is there another order clause with
the field "t24.distribution_oid" ?? This is a back reference for a 1:n
relation from Table "dist_container" back to "distribution".

The real problem is: as soon as there is another sorting parameter from a
joined table, MariaDB doesnt use my ForeignKey Index anymore and does a
FULL-Scan on the t24 table, which is pretty heavy on a multi million
records table. When i leave out that ugly t24.distribution_oid ordering
field, everything is fast and ok.

Can anyone explain to me how this ordering field gets into the picture?

thanks
marc

Re: [VOTE] Release Apache OpenJPA-2.4.0

[Marc Logemann]

Hi,

hoped for JPA 2.1 compliance..



2015-04-19 17:03 GMT+02:00 Mark Struberg :

> It’s a great pleasure to call a VOTE for releasing Apache OpenJPA-2.4.0.
>
> OpenJPA-2.4.0 implements the JPA-2.0 specification.
>
> The staging repository can be found here:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/
>
> The Release Notes can be found in the file
> openjpa-project/RELEASE_NOTES.html and online under:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310351&version=12325298
>
> The SVN source TAG is (1674626):
> https://svn.apache.org/repos/asf/openjpa/tags/openjpa-parent-2.4.0/
>
> The source release can be found here:
>
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/openjpa-parent/2.4.0/openjpa-parent-2.4.0-source-release.zip
>
> The binary release is here:
>
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1000/org/apache/openjpa/apache-openjpa/2.4.0/apache-openjpa-2.4.0-binary.zip
>
> My Key can be found here
> https://svn.apache.org/repos/asf/openjpa/KEYS
>
>
> The VOTE will be open for 72 hours.
> [+1] approve
> [+0] meh, don’t care
> [-1] stop, I’ve found a ${fish} in there
>
>
> txs and LieGrue,
> your OpenJPA team

MariaDB vs. MySQL

[Marc Logemann]

Hi,

i am fighting weird issues with an openjpa application on MariaDB while all
these are non existant on MySQL. Things like "fetch join" are just
different or better said with openjpa 2.2.0 and MariaDB problematic in some
JPQLs.

I even see different SQLs being created from the same JPAQL Queries. Is
this possible at all?

Thanks for infos.

Re: behavior change from 2.1.0 to 2.2.0 on persist

[Marc Logemann]

Rick,

thanks for pointing out. I will check this too. But regardless of the
outcome, i think we will recode the stuff which is affected, because its
better coding style to load related entities and point the managed entities
to the desired other entities. This way people know whats going on without
relying on any ORM magic.


2014-06-02 18:26 GMT+02:00 Rick Curtis :

> Marc --
>
> I'm thinking that there was a change in cascade persist behavior that you
> might be running into.
>
>
> http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/jpa_2.2.html#jpa_2.2_cascadePersist
>
>
> On Mon, Jun 2, 2014 at 9:53 AM, Marc Logemann 
> wrote:
>
> > Kevin,
> >
> > thanks for fast feedback. To your questions:
> >
> > 1) of course we could do the em.find() and do it the way it should be
> done
> > ;-)
> >
> > 2) no, we have not tried using em.merge(), this would be an option we
> could
> > check out.
> >
> > And yes. WE dont want to persist the CustomerType since its already
> there.
> > We just want to create the relationship.
> >
> > Thanks again. And now we will happily wait for Java8 Support in your
> > bytecode enhancer  so that we could upgrade to latest Version of OpenJPA
> > instead of being stuck to 2.2.0 ;-)
> >
> > Marc
> >
> >
> > 2014-06-02 16:11 GMT+02:00 Kevin Sutter :
> >
> > > Hi Marc,
> > > Sorry for the troubles.  Technically, it looks like you were lucky and
> > > coding to a bug in the OpenJPA code.  Since you just created this
> > > CustomerType, we have to assume that it's unmanaged.  And, we can't
> > > automatically cascade the persist operation to this unmanaged entity.
> >  And,
> > > in your particular case, we wouldn't want to persist this entity since
> it
> > > already exists.
> > >
> > > Just to be clear, you don't want this CustomerType to be persisted,
> > right?
> > > You are just creating this to satisfy the relationship from Person,
> > right?
> > >
> > > A couple of ideas come to mind...
> > >
> > > 1)  Can you do an em.find() operation on your CustomerType?  I realize
> > this
> > > is an extra SQL, but then this CustomerType would be managed and
> satisfy
> > > the requirement.
> > >
> > > 2)  Have you tried using em.merge(p) instead of em.persist(p)?  The
> merge
> > > should do either the update or insert based on the state of the object.
> > > When we get to the CustomerType, we might have to do the extra SQL to
> > > determine if it exists already, but then we should be okay.  This JIRA
> > [1]
> > > from the 2.2.0 Release Notes [2] makes me think this might work...
> > >
> > > Maybe somebody else has some ideas on how to get around this scenario.
> > >
> > > [1]  https://issues.apache.org/jira/browse/OPENJPA-1896
> > > [2]
> > >
> http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
> > >
> > >
> > >
> > >
> > > On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann  >
> > > wrote:
> > >
> > > > Hey,
> > > >
> > > > we recently switched to 2.2.0 (cant go higher because we use Java8)
> and
> > > we
> > > > found a change in behavior.
> > > >
> > > > Asumme we created a new Entity which looks like this:
> > > >
> > > > Person.java
> > > > --
> > > > int oid
> > > > String name
> > > > CustomerType adress
> > > >
> > > >
> > > > we created the object like so:
> > > >
> > > > Person p = new Person();
> > > > p.setName("foo);
> > > >
> > > > CustomerType ct = new CustomerType();
> > > > ct.setOid(1); // THIS OID already exists and we want to map the
> > existant
> > > > object to Person
> > > >
> > > > p.setCustomerType(ct);
> > > >
> > > > persist(p);
> > > >
> > > >
> > > > =
> > > >
> > > > In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with
> this
> > > oid
> > > > and loads it automaticly and the child object is "managed". With
> 2.2.0
> > > this
> > > > is no longer the case and we get a "Unmanaged bla bla bla Exception".
> > We
> > > > relied on that behavior heavily and the rewrite is a tough for all
> > areas.
> > > > Is there some kind of config setting where i can set the "old
> > behavior".
> > > Or
> > > > was this old behavior a bug? ;-)
> > > >
> > > > Thanks for hints.
> > > >
> > > > Marc
> > > >
> > >
> >
>
>
>
> --
> *Rick Curtis*
>

Re: behavior change from 2.1.0 to 2.2.0 on persist

[Marc Logemann]

Kevin,

thanks for fast feedback. To your questions:

1) of course we could do the em.find() and do it the way it should be done
;-)

2) no, we have not tried using em.merge(), this would be an option we could
check out.

And yes. WE dont want to persist the CustomerType since its already there.
We just want to create the relationship.

Thanks again. And now we will happily wait for Java8 Support in your
bytecode enhancer  so that we could upgrade to latest Version of OpenJPA
instead of being stuck to 2.2.0 ;-)

Marc


2014-06-02 16:11 GMT+02:00 Kevin Sutter :

> Hi Marc,
> Sorry for the troubles.  Technically, it looks like you were lucky and
> coding to a bug in the OpenJPA code.  Since you just created this
> CustomerType, we have to assume that it's unmanaged.  And, we can't
> automatically cascade the persist operation to this unmanaged entity.  And,
> in your particular case, we wouldn't want to persist this entity since it
> already exists.
>
> Just to be clear, you don't want this CustomerType to be persisted, right?
> You are just creating this to satisfy the relationship from Person, right?
>
> A couple of ideas come to mind...
>
> 1)  Can you do an em.find() operation on your CustomerType?  I realize this
> is an extra SQL, but then this CustomerType would be managed and satisfy
> the requirement.
>
> 2)  Have you tried using em.merge(p) instead of em.persist(p)?  The merge
> should do either the update or insert based on the state of the object.
> When we get to the CustomerType, we might have to do the extra SQL to
> determine if it exists already, but then we should be okay.  This JIRA [1]
> from the 2.2.0 Release Notes [2] makes me think this might work...
>
> Maybe somebody else has some ideas on how to get around this scenario.
>
> [1]  https://issues.apache.org/jira/browse/OPENJPA-1896
> [2]
> http://openjpa.apache.org/builds/2.2.0/apache-openjpa/RELEASE-NOTES.html
>
>
>
>
> On Mon, Jun 2, 2014 at 7:48 AM, Marc Logemann 
> wrote:
>
> > Hey,
> >
> > we recently switched to 2.2.0 (cant go higher because we use Java8) and
> we
> > found a change in behavior.
> >
> > Asumme we created a new Entity which looks like this:
> >
> > Person.java
> > --
> > int oid
> > String name
> > CustomerType adress
> >
> >
> > we created the object like so:
> >
> > Person p = new Person();
> > p.setName("foo);
> >
> > CustomerType ct = new CustomerType();
> > ct.setOid(1); // THIS OID already exists and we want to map the existant
> > object to Person
> >
> > p.setCustomerType(ct);
> >
> > persist(p);
> >
> >
> > =
> >
> > In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with this
> oid
> > and loads it automaticly and the child object is "managed". With 2.2.0
> this
> > is no longer the case and we get a "Unmanaged bla bla bla Exception". We
> > relied on that behavior heavily and the rewrite is a tough for all areas.
> > Is there some kind of config setting where i can set the "old behavior".
> Or
> > was this old behavior a bug? ;-)
> >
> > Thanks for hints.
> >
> > Marc
> >
>

behavior change from 2.1.0 to 2.2.0 on persist

[Marc Logemann]

Hey,

we recently switched to 2.2.0 (cant go higher because we use Java8) and we
found a change in behavior.

Asumme we created a new Entity which looks like this:

Person.java
--
int oid
String name
CustomerType adress


we created the object like so:

Person p = new Person();
p.setName("foo);

CustomerType ct = new CustomerType();
ct.setOid(1); // THIS OID already exists and we want to map the existant
object to Person

p.setCustomerType(ct);

persist(p);


=

In 2.1.0 OpemJPA knew that there is a CustomerType in the DB with this oid
and loads it automaticly and the child object is "managed". With 2.2.0 this
is no longer the case and we get a "Unmanaged bla bla bla Exception". We
relied on that behavior heavily and the rewrite is a tough for all areas.
Is there some kind of config setting where i can set the "old behavior". Or
was this old behavior a bug? ;-)

Thanks for hints.

Marc

Re: not a recognized entity

[Marc Logemann]

Hi,

doesnt make any difference. Still the same error. Even tried it on a complete 
new build server @amazon. Of course it doesnt make any difference if i do it 
just by running "ant test" on shell, or by using the CI server. I could comment 
this specific test to see if its the only issue. This error appears after 
running 10 tests successfully.

I really wonder why the junit ANT task behaves differently than my production 
build. I never had this issue before and we build the product since ages. 

Anything more i can do ? Can you elaborate on this weird error message. I mean, 
it doesnt make much sense what OpenJPA wants to tell me


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de





Am 01.10.2012 um 18:22 schrieb Rick Curtis :

> Marc -
> 
> For giggles, can you try to run with the property
> openjpa.MetaDataRepository=Preload=true ?
> 
> I've seen similar issues in the past and they had to do with initialization
> of the MetaDataRepository when running with multiple EntityManagers(across
> muitple threads).
> 
> Thanks,
> Rick
> 
> On Sun, Sep 30, 2012 at 5:02 PM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> now the third message, nearly giving up. I now defined the entities via
>> MetaDataFactory poperty and now i get:
>> 
>> [getDHLLeitcode] 
>> org.apache.openjpa.persistence.ArgumentException: An error occurred while
>> parsing the query filter "select a from DP_PLZ_DA a where a.plz = ?1 and
>> LOWER(a.oname) = ?2". Error message: The name "DP_PLZ_DA" is not a
>> recognized entity or identifier. Perhaps you meant DP_PLZ_DA, which is a
>> close match. Known entity names: [User, CarrierMapping, GLSBox, ContactNN,
>> AlternateSender, BlackBoxMapping, DP_STRA_DB, Distribution,  Balance,
>> FtpConnection, AccountingHistory, SameDayDelivery, DeliveryAddress,
>> DP_ORT_DA, Country, DHLAccountingClientSettings, Notification,
>> EdiConnection, PriceMatrix, TrackTraceSetting, AZCPR00F,
>> PackagingDimension, Device, CarrierService, Workplace, CostCentre,
>> JobTrigger, CmrCarrier, EmailConnection, NumberRange, Client, Right,
>> NVListener, Document, DPDVersion, Contact, DP_PLZ_DA, DPDDepot,
>> Configuration, DistributionContainer, CustomsOffice, DistributionItem, GLN,
>> Communications, Address, Role, BankAccount, Label, Printer, Person] at
>> org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119)
>> 
>> Look at:
>> 
>> "The name "DP_PLZ_DA" is not a recognized entity or identifier. Perhaps
>> you meant DP_PLZ_DA, which is a close match."
>> 
>> What does that mean? This is quite weird isnt it? This message makes no
>> sense at all and leaves me puzzled.
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> Am 30.09.2012 um 23:24 schrieb Marc Logemann :
>> 
>>> Hi,
>>> 
>>> just read some more about it. Now i know that Spring has nothing to do
>> with submitting the persitent classes list to OpenJPA. It seems that for
>> some classes i have no problem because the VM loaded the entity before
>> issueing the JPQL query. While loading the entity in the VM, it gets
>> "listed". During "normal" runtime i dont have these problems because the
>> nature of the application lifecycle is completely different as opposed to
>> unit testing in a CI server. As it seems i have several options now:
>> Listing them in persistence.xml or using OpenJPA openjpa.MetaDataFactory
>> arguments.
>>> 
>>> Dont know if this solves all of my questions but i think i am getting
>> closer to the answer
>>> 
>>> 
>>> ---
>>> regards
>>> Marc Logemann
>>> http://www.logemann.org
>>> http://www.logentis.de
>>> 
>>> 
>>> 
>>> 
>>> Am 30.09.2012 um 22:30 schrieb Marc Logemann :
>>> 
>>>> Hi,
>>>> 
>>>> after hours of researching i am lost. Perhaps someone can help out. In
>> my CI server i am getting a stacktrace like this:
>>>> 
>>>> [getDHLLeitcode] org.apache.openjpa.persistence.ArgumentException: An
>> error occurred while parsing the query filter "select d from DP_ORT_DA d
>> where lower(d.oname) = ?1". Error message: The name "DP_ORT_DA" is not a
>> recognized entity or identifier. Perhaps you meant DP_PLZ_DA, which is a
>> close match. Known entity names: [User, CarrierMapping, Device, GLSBox,
>> CostCentre, Workplace, 

Re: not a recognized entity

[Marc Logemann]

Hi,

now the third message, nearly giving up. I now defined the entities via 
MetaDataFactory poperty and now i get: 

[getDHLLeitcode]  
org.apache.openjpa.persistence.ArgumentException: An error occurred while 
parsing the query filter "select a from DP_PLZ_DA a where a.plz = ?1 and 
LOWER(a.oname) = ?2". Error message: The name "DP_PLZ_DA" is not a recognized 
entity or identifier. Perhaps you meant DP_PLZ_DA, which is a close match. 
Known entity names: [User, CarrierMapping, GLSBox, ContactNN, AlternateSender, 
BlackBoxMapping, DP_STRA_DB, Distribution,  Balance, FtpConnection, 
AccountingHistory, SameDayDelivery, DeliveryAddress, DP_ORT_DA, Country, 
DHLAccountingClientSettings, Notification, EdiConnection, PriceMatrix, 
TrackTraceSetting, AZCPR00F, PackagingDimension, Device, CarrierService, 
Workplace, CostCentre, JobTrigger, CmrCarrier, EmailConnection, NumberRange, 
Client, Right, NVListener, Document, DPDVersion, Contact, DP_PLZ_DA, DPDDepot, 
Configuration, DistributionContainer, CustomsOffice, DistributionItem, GLN, 
Communications, Address, Role, BankAccount, Label, Printer, Person] at 
org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119)

Look at:

"The name "DP_PLZ_DA" is not a recognized entity or identifier. Perhaps you 
meant DP_PLZ_DA, which is a close match."

What does that mean? This is quite weird isnt it? This message makes no sense 
at all and leaves me puzzled. 

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 30.09.2012 um 23:24 schrieb Marc Logemann :

> Hi,
> 
> just read some more about it. Now i know that Spring has nothing to do with 
> submitting the persitent classes list to OpenJPA. It seems that for some 
> classes i have no problem because the VM loaded the entity before issueing 
> the JPQL query. While loading the entity in the VM, it gets "listed". During 
> "normal" runtime i dont have these problems because the nature of the 
> application lifecycle is completely different as opposed to unit testing in a 
> CI server. As it seems i have several options now: Listing them in 
> persistence.xml or using OpenJPA openjpa.MetaDataFactory arguments. 
> 
> Dont know if this solves all of my questions but i think i am getting closer 
> to the answer
> 
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 
> Am 30.09.2012 um 22:30 schrieb Marc Logemann :
> 
>> Hi,
>> 
>> after hours of researching i am lost. Perhaps someone can help out. In my CI 
>> server i am getting a stacktrace like this:
>> 
>> [getDHLLeitcode] org.apache.openjpa.persistence.ArgumentException: An error 
>> occurred while parsing the query filter "select d from DP_ORT_DA d where 
>> lower(d.oname) = ?1". Error message: The name "DP_ORT_DA" is not a 
>> recognized entity or identifier. Perhaps you meant DP_PLZ_DA, which is a 
>> close match. Known entity names: [User, CarrierMapping, Device, GLSBox, 
>> CostCentre, Workplace, JobTrigger, AlternateSender, ContactNN, 
>> BlackBoxMapping, CmrCarrier, DP_STRA_DB, EmailConnection, Distribution, 
>> NumberRange, Balance, Client, Right, NVListener, FtpConnection, 
>> AccountingHistory, Document, SameDayDelivery, DPDVersion, Contact, 
>> DeliveryAddress, DistributionContainer, DP_PLZ_DA, DPDDepot, Configuration, 
>> CustomsOffice, Country, DHLAccountingClientSettings, Notification, 
>> EdiConnection, PriceMatrix, GLN, Communications, TrackTraceSetting, Address, 
>> BankAccount, Role, Printer, Label, AZCPR00F, PackagingDimension, Person]
>> [15:13:47][getDHLLeitcode] > error> org.apache.openjpa.persistence.ArgumentException: An error occurred 
>> while parsing the query filter "select d from DP_ORT_DA d where 
>> lower(d.oname) = ?1". Error message: The name "DP_ORT_DA" is not a 
>> recognized entity or identifier. Perhaps you meant DP_PLZ_DA, which is a 
>> close match. Known entity names: [User, CarrierMapping, Device, GLSBox, 
>> CostCentre, Workplace, JobTrigger, AlternateSender, ContactNN, 
>> BlackBoxMapping, CmrCarrier, DP_STRA_DB, EmailConnection, Distribution, 
>> NumberRange, Balance, Client, Right, NVListener, FtpConnection, 
>> AccountingHistory, Document, SameDayDelivery, DPDVersion, Contact, 
>> DeliveryAddress, DistributionContainer, DP_PLZ_DA, DPDDepot, Configuration, 
>> CustomsOffice, Country, DHLAccountingClientSettings, Notification, 
>> EdiConnection, PriceMatrix, GLN, Communications, TrackTraceSetting, Address, 
>> BankAccount, Role, Printer, Label, AZCPR00F, PackagingDimension, Person] at 
>> org.apache.openjpa.kernel.exps.AbstractExpres

Re: not a recognized entity

[Marc Logemann]

Hi,

just read some more about it. Now i know that Spring has nothing to do with 
submitting the persitent classes list to OpenJPA. It seems that for some 
classes i have no problem because the VM loaded the entity before issueing the 
JPQL query. While loading the entity in the VM, it gets "listed". During 
"normal" runtime i dont have these problems because the nature of the 
application lifecycle is completely different as opposed to unit testing in a 
CI server. As it seems i have several options now: Listing them in 
persistence.xml or using OpenJPA openjpa.MetaDataFactory arguments. 

Dont know if this solves all of my questions but i think i am getting closer to 
the answer....


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 30.09.2012 um 22:30 schrieb Marc Logemann :

> Hi,
> 
> after hours of researching i am lost. Perhaps someone can help out. In my CI 
> server i am getting a stacktrace like this:
> 
> [getDHLLeitcode] org.apache.openjpa.persistence.ArgumentException: An error 
> occurred while parsing the query filter "select d from DP_ORT_DA d where 
> lower(d.oname) = ?1". Error message: The name "DP_ORT_DA" is not a recognized 
> entity or identifier. Perhaps you meant DP_PLZ_DA, which is a close match. 
> Known entity names: [User, CarrierMapping, Device, GLSBox, CostCentre, 
> Workplace, JobTrigger, AlternateSender, ContactNN, BlackBoxMapping, 
> CmrCarrier, DP_STRA_DB, EmailConnection, Distribution, NumberRange, Balance, 
> Client, Right, NVListener, FtpConnection, AccountingHistory, Document, 
> SameDayDelivery, DPDVersion, Contact, DeliveryAddress, DistributionContainer, 
> DP_PLZ_DA, DPDDepot, Configuration, CustomsOffice, Country, 
> DHLAccountingClientSettings, Notification, EdiConnection, PriceMatrix, GLN, 
> Communications, TrackTraceSetting, Address, BankAccount, Role, Printer, 
> Label, AZCPR00F, PackagingDimension, Person]
> [15:13:47][getDHLLeitcode]  error> org.apache.openjpa.persistence.ArgumentException: An error occurred 
> while parsing the query filter "select d from DP_ORT_DA d where 
> lower(d.oname) = ?1". Error message: The name "DP_ORT_DA" is not a recognized 
> entity or identifier. Perhaps you meant DP_PLZ_DA, which is a close match. 
> Known entity names: [User, CarrierMapping, Device, GLSBox, CostCentre, 
> Workplace, JobTrigger, AlternateSender, ContactNN, BlackBoxMapping, 
> CmrCarrier, DP_STRA_DB, EmailConnection, Distribution, NumberRange, Balance, 
> Client, Right, NVListener, FtpConnection, AccountingHistory, Document, 
> SameDayDelivery, DPDVersion, Contact, DeliveryAddress, DistributionContainer, 
> DP_PLZ_DA, DPDDepot, Configuration, CustomsOffice, Country, 
> DHLAccountingClientSettings, Notification, EdiConnection, PriceMatrix, GLN, 
> Communications, TrackTraceSetting, Address, BankAccount, Role, Printer, 
> Label, AZCPR00F, PackagingDimension, Person] at 
> org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119)
>  at 
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:195)
> 
> 
> Now this looks quite easy because normally it means that the queried entity 
> "DP_ORT_DA" is not an entity. Either not enhanced or somehow not registered. 
> First of all, it is enhanced. I reverse engineered the class file which 
> resides in my CI (continius integration) server work dir. Because i use 
> spring, entities get auto-registered without the need listing them in 
> persistence.xml. Really exciting is that OpenJPA proposes or suggest using 
> DP_PLZ_DA, because this is registered. This is weird because this class is in 
> the same package and is of course also enhanced as the other entity as well. 
> 
> Of course i dont have this problem when doing a production build. Its only in 
> my CI server which uses mainly the same ANT tasks for enhancing and stuff. 
> What can i do to debug this further? Getting low on ideas how to debug it 
> Thanks.
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 

not a recognized entity

[Marc Logemann]

Hi,

after hours of researching i am lost. Perhaps someone can help out. In my CI 
server i am getting a stacktrace like this:

[getDHLLeitcode] org.apache.openjpa.persistence.ArgumentException: An error 
occurred while parsing the query filter "select d from DP_ORT_DA d where 
lower(d.oname) = ?1". Error message: The name "DP_ORT_DA" is not a recognized 
entity or identifier. Perhaps you meant DP_PLZ_DA, which is a close match. 
Known entity names: [User, CarrierMapping, Device, GLSBox, CostCentre, 
Workplace, JobTrigger, AlternateSender, ContactNN, BlackBoxMapping, CmrCarrier, 
DP_STRA_DB, EmailConnection, Distribution, NumberRange, Balance, Client, Right, 
NVListener, FtpConnection, AccountingHistory, Document, SameDayDelivery, 
DPDVersion, Contact, DeliveryAddress, DistributionContainer, DP_PLZ_DA, 
DPDDepot, Configuration, CustomsOffice, Country, DHLAccountingClientSettings, 
Notification, EdiConnection, PriceMatrix, GLN, Communications, 
TrackTraceSetting, Address, BankAccount, Role, Printer, Label, AZCPR00F, 
PackagingDimension, Person]
[15:13:47][getDHLLeitcode]  
org.apache.openjpa.persistence.ArgumentException: An error occurred while 
parsing the query filter "select d from DP_ORT_DA d where lower(d.oname) = ?1". 
Error message: The name "DP_ORT_DA" is not a recognized entity or identifier. 
Perhaps you meant DP_PLZ_DA, which is a close match. Known entity names: [User, 
CarrierMapping, Device, GLSBox, CostCentre, Workplace, JobTrigger, 
AlternateSender, ContactNN, BlackBoxMapping, CmrCarrier, DP_STRA_DB, 
EmailConnection, Distribution, NumberRange, Balance, Client, Right, NVListener, 
FtpConnection, AccountingHistory, Document, SameDayDelivery, DPDVersion, 
Contact, DeliveryAddress, DistributionContainer, DP_PLZ_DA, DPDDepot, 
Configuration, CustomsOffice, Country, DHLAccountingClientSettings, 
Notification, EdiConnection, PriceMatrix, GLN, Communications, 
TrackTraceSetting, Address, BankAccount, Role, Printer, Label, AZCPR00F, 
PackagingDimension, Person] at 
org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119)
 at 
org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:195)


Now this looks quite easy because normally it means that the queried entity 
"DP_ORT_DA" is not an entity. Either not enhanced or somehow not registered. 
First of all, it is enhanced. I reverse engineered the class file which resides 
in my CI (continius integration) server work dir. Because i use spring, 
entities get auto-registered without the need listing them in persistence.xml. 
Really exciting is that OpenJPA proposes or suggest using DP_PLZ_DA, because 
this is registered. This is weird because this class is in the same package and 
is of course also enhanced as the other entity as well. 

Of course i dont have this problem when doing a production build. Its only in 
my CI server which uses mainly the same ANT tasks for enhancing and stuff. What 
can i do to debug this further? Getting low on ideas how to debug it Thanks.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: update null relation on merge()

[Marc Logemann]

i have not configured a detachState somewhere, so i guess its the default...

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 24.08.2012 um 11:50 schrieb Boblitz John :

> Which detached state are you using?
> 
>> -Ursprüngliche Nachricht-----
>> Von: Marc Logemann [mailto:l...@logemann.org] 
>> Gesendet: Freitag, 24. August 2012 11:43
>> An: users@openjpa.apache.org
>> Betreff: Re: update null relation on merge()
>> 
>> 1:1 relations are eager by default And eager could be 
>> only a loading issue. I have a "merge" issue here.
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> Am 24.08.2012 um 11:28 schrieb Boblitz John 
>> :
>> 
>>> Good Morning,
>>> 
>>> I had this often and one solution is to set the FetchType 
>> to EAGER for 
>>> the Relationship.
>>> 
>>> Cheers,
>>> 
>>> John
>>> 
>>>> -Ursprüngliche Nachricht-
>>>> Von: Marc Logemann [mailto:m...@logemann.org]
>>>> Gesendet: Freitag, 24. August 2012 11:17
>>>> An: users@openjpa.apache.org
>>>> Betreff: update null relation on merge()
>>>> 
>>>> Hi,
>>>> 
>>>> i am facing something like described here:
>>>> 
>>>> http://openjpa.208410.n2.nabble.com/null-values-not-updating-t
>>>> d3224059.html
>>>> 
>>>> We get a JSON graph from frontend, let Spring deserialize it to a 
>>>> java object (with OID set) and want to change the existing 
>> object in 
>>>> the db. This works for simple attribtues likes Strings and 
>> so but not 
>>>> for 1:1 relations. If we set it to "null" in the frontend, 
>> we want to 
>>>> change the 1:1 relation to null. Instead it leaves the 1:1 
>> relations 
>>>> untouched with the old object reference in it.
>>>> 
>>>> The OpenJPA docs once said: "When attaching null fields in these 
>>>> cases, OpenJPA cannot distinguish between a field that was 
>> unloaded 
>>>> and one that was intentionally set to null. In this case, OpenJPA 
>>>> will use the current detach state setting to determine how 
>> to handle 
>>>> null fields: fields that would have been included in the detached 
>>>> state are treated as loaded, and will in turn set the 
>> corresponding 
>>>> attached field to null."
>>>> 
>>>> At this point i dont know what to do. Spring knows its detached 
>>>> because we submit our @Id Field => OID with a valid and existant 
>>>> value but the merge itself just ignores null values for 
>> 1:1 relations 
>>>> and leaves them as they were. Is there any sensible way to tell 
>>>> OpenJPA to merge "null"
>>>> relations differently?
>>>> 
>>>> ---
>>>> regards
>>>> Marc Logemann
>>>> http://www.logemann.org
>>>> http://www.logentis.de
>>>> 
>>>> 
>>>> 
>>>> 
>> 

Re: update null relation on merge()

[Marc Logemann]

1:1 relations are eager by default And eager could be only a loading issue. 
I have a "merge" issue here.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 24.08.2012 um 11:28 schrieb Boblitz John :

> Good Morning,
> 
> I had this often and one solution is to set the FetchType to EAGER for the
> Relationship.
> 
> Cheers,
> 
> John
> 
>> -----Ursprüngliche Nachricht-
>> Von: Marc Logemann [mailto:m...@logemann.org] 
>> Gesendet: Freitag, 24. August 2012 11:17
>> An: users@openjpa.apache.org
>> Betreff: update null relation on merge()
>> 
>> Hi,
>> 
>> i am facing something like described here:
>> 
>> http://openjpa.208410.n2.nabble.com/null-values-not-updating-t
>> d3224059.html
>> 
>> We get a JSON graph from frontend, let Spring deserialize it 
>> to a java object (with OID set) and want to change the 
>> existing object in the db. This works for simple attribtues 
>> likes Strings and so but not for 1:1 relations. If we set it 
>> to "null" in the frontend, we want to change the 1:1 relation 
>> to null. Instead it leaves the 1:1 relations untouched with 
>> the old object reference in it. 
>> 
>> The OpenJPA docs once said: "When attaching null fields in 
>> these cases, OpenJPA cannot distinguish between a field that 
>> was unloaded and one that was intentionally set to null. In 
>> this case, OpenJPA will use the current detach state setting 
>> to determine how to handle null fields: fields that would 
>> have been included in the detached state are treated as 
>> loaded, and will in turn set the corresponding attached field 
>> to null."
>> 
>> At this point i dont know what to do. Spring knows its 
>> detached because we submit our @Id Field => OID with a valid 
>> and existant value but the merge itself just ignores null 
>> values for 1:1 relations and leaves them as they were. Is 
>> there any sensible way to tell OpenJPA to merge "null" 
>> relations differently?
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 

update null relation on merge()

[Marc Logemann]

Hi,

i am facing something like described here:

http://openjpa.208410.n2.nabble.com/null-values-not-updating-td3224059.html

We get a JSON graph from frontend, let Spring deserialize it to a java object 
(with OID set) and want to change the existing object in the db. This works for 
simple attribtues likes Strings and so but not for 1:1 relations. If we set it 
to "null" in the frontend, we want to change the 1:1 relation to null. Instead 
it leaves the 1:1 relations untouched with the old object reference in it. 

The OpenJPA docs once said: "When attaching null fields in these cases, OpenJPA 
cannot distinguish between a field that was unloaded and one that was 
intentionally set to null. In this case, OpenJPA will use the current detach 
state setting to determine how to handle null fields: fields that would have 
been included in the detached state are treated as loaded, and will in turn set 
the corresponding attached field to null."

At this point i dont know what to do. Spring knows its detached because we 
submit our @Id Field => OID with a valid and existant value but the merge 
itself just ignores null values for 1:1 relations and leaves them as they were. 
Is there any sensible way to tell OpenJPA to merge "null" relations differently?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: org.apache.openjpa.util.LongId cannot be cast to MyDomainObject

[Marc Logemann]

Then i dont get the "referencedColumnName" Feature, because the db field of the 
@ID fields doesnt need to be declared, this JPA does already know. 
I will migrate it nevertheless and leave out the "referencedColumnName" 
completely.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.12.2011 um 09:39 schrieb Boblitz John:

> Hello Marc,
> 
> You stated: "Please note that referencedColumnName value is not the primary 
> key. "
> 
> Accorging to the Manual (13.8.4) - the referencedColumnName is 
> "The name of the primary key column being joined to.  If there is only one 
> identity
> field in the related entity class, the join column name defaults to the name 
> of the
> identity field's column."
> 
> Regards,
> 
>  
> 
> John
> 
>  
> 
> Who is General Failure, and why is he reading my hard disk?
> 
> 
> 
> 
> 
> 
> 
> 
>> -Ursprüngliche Nachricht-
>> Von: Marc Logemann [mailto:l...@logemann.org] 
>> Gesendet: Donnerstag, 22. Dezember 2011 17:55
>> An: users@openjpa.apache.org
>> Betreff: Re: org.apache.openjpa.util.LongId cannot be cast to 
>> MyDomainObject
>> 
>> Hi,
>> 
>> The customer has the same database, the same application 
>> (same build and stuff like that) and same everything. This is 
>> what freaks me out ;-) Of course something must be different...
>> I compared the schema several times and they are the same.
>> 
>> Turning on Trace is quite impossible on a production machine. 
>> I would rather do a DB migration and use the primary key 
>> "oid"  as foreign key constraint instead of some random string field.
>> 
>> Perhaps i can get my hands on another machine which is not 
>> production and also results in that error. Then i could do 
>> remote debugging. But even with remote debugging turned on, 
>> its not likely that i fully understand whats wrong.
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> Am 22.12.2011 um 17:00 schrieb Kevin Sutter:
>> 
>>> Hi Marc,
>>> I'm not seeing anything wrong with your object model 
>> definition.  But, 
>>> it definitely looks like OpenJPA is getting confused on this join 
>>> column reference (string id) and the type of the primary 
>> key (long).  
>>> Have you been able to verify that the database schemas are 
>> consistent 
>>> with the object model?  Does your customer and your development 
>>> system(s) use the same database type (ie. mysql)?  I really 
>> don't think it's a data issue.
>>> It looks more like a data-definition issue either in the 
>> object model 
>>> or the database itself.
>>> 
>>> How about your persistence unit definition?  Does the customer 
>>> environment and your development environment use the same 
>>> persistence.xml?  For example, do you dynamically sync the database 
>>> schema with the object model, or do you pre-create the 
>> database schema via ddl?
>>> 
>>> I'd start with turning on Trace and comparing the flows to 
>> see where 
>>> there are differences.
>>> 
>>> BTW, I totally agree with your comment that OpenJPA is too 
>> complex to 
>>> comprehend in just a few hours...  :-)
>>> 
>>> Good luck,
>>> Kevin
>>> 
>>> On Wed, Dec 21, 2011 at 5:21 PM, Marc Logemann 
>>  wrote:
>>> 
>>>> Hi,
>>>> 
>>>> me again. This time with something i also dont get.
>>>> 
>>>> OrderPosition.class
>>>> ---
>>>>  @XmlTransient
>>>>  @ManyToOne
>>>>  @JoinColumn(name = "con_ship_id", referencedColumnName = "id")
>>>>  ContainerShipment containerShipment;
>>>> 
>>>> ContainerShipment.class
>>>> ---
>>>>  @XmlTransient
>>>>  @Id
>>>>  @GeneratedValue(strategy = GenerationType.TABLE, generator =
>>>> "contShipGen")
>>>>  @TableGenerator(name = "contShipGen", table = "jpa_sequence", 
>>>> pkColumnName = "ID",
>>>>  pkColumnValue = "ContainerShipment", valueColumnName = 
>>>> "SEQUENCE_VALUE", initialValue = 2000, allocationSize = 2)
>>>>  long oid;
>>>> 
>>&g

Re: org.apache.openjpa.util.LongId cannot be cast to MyDomainObject

[Marc Logemann]

Hi,

The customer has the same database, the same application (same build and stuff 
like that) and same everything. This is what freaks me out ;-) Of course 
something must be different...
I compared the schema several times and they are the same.

Turning on Trace is quite impossible on a production machine. I would rather do 
a DB migration and use the primary key "oid"  as foreign key constraint instead 
of some random string field.

Perhaps i can get my hands on another machine which is not production and also 
results in that error. Then i could do remote debugging. But even with remote 
debugging turned on, its not likely that i fully understand whats wrong.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 22.12.2011 um 17:00 schrieb Kevin Sutter:

> Hi Marc,
> I'm not seeing anything wrong with your object model definition.  But, it
> definitely looks like OpenJPA is getting confused on this join column
> reference (string id) and the type of the primary key (long).  Have you
> been able to verify that the database schemas are consistent with the
> object model?  Does your customer and your development system(s) use the
> same database type (ie. mysql)?  I really don't think it's a data issue.
> It looks more like a data-definition issue either in the object model or
> the database itself.
> 
> How about your persistence unit definition?  Does the customer environment
> and your development environment use the same persistence.xml?  For
> example, do you dynamically sync the database schema with the object model,
> or do you pre-create the database schema via ddl?
> 
> I'd start with turning on Trace and comparing the flows to see where there
> are differences.
> 
> BTW, I totally agree with your comment that OpenJPA is too complex to
> comprehend in just a few hours...  :-)
> 
> Good luck,
> Kevin
> 
> On Wed, Dec 21, 2011 at 5:21 PM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> me again. This time with something i also dont get.
>> 
>> OrderPosition.class
>> ---
>>   @XmlTransient
>>   @ManyToOne
>>   @JoinColumn(name = "con_ship_id", referencedColumnName = "id")
>>   ContainerShipment containerShipment;
>> 
>> ContainerShipment.class
>> ---
>>   @XmlTransient
>>   @Id
>>   @GeneratedValue(strategy = GenerationType.TABLE, generator =
>> "contShipGen")
>>   @TableGenerator(name = "contShipGen", table = "jpa_sequence",
>> pkColumnName = "ID",
>>   pkColumnValue = "ContainerShipment", valueColumnName =
>> "SEQUENCE_VALUE", initialValue = 2000, allocationSize = 2)
>>   long oid;
>> 
>>   @Column(name = "id")
>>   String id;
>> 
>>   @OneToMany(mappedBy = "containerShipment", cascade = CascadeType.ALL,
>> fetch = FetchType.EAGER)
>>   List orderPositions;
>> 
>> 
>> Please note that referencedColumnName value is not the primary key. Its
>> just a simple String/varchar field.
>> 
>> Following Stack produced. Even more scary. This stack doesnt appear on my
>> developer machine with test DB, but on customer machine with different
>> dataset. So it looks data related but i cant be for sure because i have not
>> seen any data problems in the DB.
>> Thanks again for hints. It seems that inside TransferFieldManager, there
>> is a LongId on field index = 12 instead of a ContainerShipment. But i dont
>> know why its there… As i said, i cant say for sure because on my
>> development machine everything is fine which makes debugging a little bit
>> hard. Its also not that easy to fully understand the OpenJPA code. Its just
>> too complex to analyze in a few hours.
>> 
>> 
>> 
>> 
>> org.apache.openjpa.persistence.PersistenceException:
>> org.apache.openjpa.util.LongId cannot be cast to
>> de.logentis.bwh.model.ContainerShipment
>> FailedObject: SELECT cs FROM ContainerShipment cs [java.lang.String]
>>   at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:1008)
>>   at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:907)
>>   at
>> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1041)
>>   at
>> org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:280)
>>   at
>> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2381)
>>   at
>> org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrategy.loadElement(RelationToManyI

org.apache.openjpa.util.LongId cannot be cast to MyDomainObject

[Marc Logemann]

at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassCastException: org.apache.openjpa.util.LongId cannot 
be cast to de.logentis.bwh.model.ContainerShipment
at 
de.logentis.bwh.model.OrderPosition.pcReplaceField(OrderPosition.java)
at 
org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:3162)
at 
org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2596)
at 
org.apache.openjpa.kernel.StateManagerImpl.storeObject(StateManagerImpl.java:2586)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setMappedBy(JDBCStoreManager.java:505)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:431)
at 
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:333)
at 
org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112)
at 
org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1027)
    at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:985)
... 86 more
---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

weird java.util.EmptyStackException

[Marc Logemann]

 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:662)
Caused by:  
org.apache.openjpa.persistence.PersistenceException: null
at 
org.apache.openjpa.kernel.QueryImpl.createExecutor(QueryImpl.java:764)
at 
org.apache.openjpa.kernel.QueryImpl.compileForDataStore(QueryImpl.java:707)
at 
org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:689)
at org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1529)
at 
org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:124)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:309)
at 
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:331)
at 
org.springframework.data.jpa.repository.query.JpaQueryExecution$CollectionExecution.doExecute(JpaQueryExecution.java:77)
at 
org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:54)
at 
org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:93)
at 
org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:83)
at 
org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:343)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:155)
... 47 more
Caused by: java.util.EmptyStackException
at java.util.Stack.peek(Stack.java:85)
at 
org.apache.openjpa.persistence.criteria.CriteriaQueryImpl.ctx(CriteriaQueryImpl.java:464)
at 
org.apache.openjpa.persistence.criteria.RootImpl.toValue(RootImpl.java:76)
at 
org.apache.openjpa.persistence.criteria.PathImpl.toValue(PathImpl.java:178)
at 
org.apache.openjpa.persistence.criteria.Expressions.toValue(Expressions.java:66)
at 
org.apache.openjpa.persistence.criteria.Expressions$Equal.toKernelExpression(Expressions.java:854)
at 
org.apache.openjpa.persistence.criteria.PredicateImpl.toKernelExpression(PredicateImpl.java:152)
at 
org.apache.openjpa.persistence.criteria.CriteriaExpressionBuilder.evalFilter(CriteriaExpressionBuilder.java:216)
at 
org.apache.openjpa.persistence.criteria.CriteriaExpressionBuilder.getQueryExpressions(CriteriaExpressionBuilder.java:75)
at 
org.apache.openjpa.persistence.criteria.CriteriaQueryImpl.getQueryExpressions(CriteriaQueryImpl.java:418)
at 
org.apache.openjpa.persistence.criteria.CriteriaBuilderImpl.eval(CriteriaBuilderImpl.java:83)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.(ExpressionStoreQuery.java:762)
at 
org.apache.openjpa.kernel.ExpressionStoreQuery.newDataStoreExecutor(ExpressionStoreQuery.java:179)
at 
org.apache.openjpa.kernel.QueryImpl.createExecutor(QueryImpl.java:749)
... 62 more
---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: weird JDO Exception when using OpenJPA 2 Enhancer

[Marc Logemann]

ok guys. Got it. **/domain searched in a weird package that was generated by a 
webservice framework and most likely something jdo relevant sneaked into it. I 
specified the folder now with using ** so that i am in full control of the 
enhancer ;-)

Really scary to see a persistence API popping up i stopped using years ago ;-)

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 07.10.2011 um 19:01 schrieb Marc Logemann:

> Hi,
> 
> something weird is going on. i added a new directory in my ANT task like this:
> 
> 
>
>
>
>
>
>
>
> 
> Now with the newly added folder. I am getting the following exception. Note 
> that i checked all my sources if there is any reference to javax.jdo but 
> there is none:
> 
> /Users/ml/Development/java/projects/bwh/build.xml:112: 
> java.lang.IllegalArgumentException: java.lang.NoClassDefFoundError: 
> javax/jdo/spi/PersistenceCapable
>   at 
> org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:175)
>   at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
>   at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>   at org.apache.tools.ant.Task.perform(Task.java:348)
>   at org.apache.tools.ant.Target.execute(Target.java:390)
>   at org.apache.tools.ant.Target.performTasks(Target.java:411)
>   at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
>   at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
>   at 
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
>   at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
>   at org.apache.tools.ant.Main.runBuild(Main.java:809)
>   at org.apache.tools.ant.Main.startAnt(Main.java:217)
>   at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
>   at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at com.intellij.rt.ant.execution.AntMain2.main(AntMain2.java:32)
> Caused by: java.lang.IllegalArgumentException: 
> java.lang.NoClassDefFoundError: javax/jdo/spi/PersistenceCapable
>   at serp.util.Strings.toClass(Strings.java:164)
>   at serp.util.Strings.toClass(Strings.java:108)
>   at 
> org.apache.openjpa.lib.meta.ClassArgParser.parseTypes(ClassArgParser.java:164)
>   at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4659)
>   at 
> org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
>   at 
> org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:171)
>   ... 21 more
> 
> If i remove the include and use the one which is currently commented out. 
> Everything works fine as it did years before i am clueless..
> 
> 
> Thanks for any pointer.
> 
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 

weird JDO Exception when using OpenJPA 2 Enhancer

[Marc Logemann]

Hi,

something weird is going on. i added a new directory in my ANT task like this:










Now with the newly added folder. I am getting the following exception. Note 
that i checked all my sources if there is any reference to javax.jdo but there 
is none:

/Users/ml/Development/java/projects/bwh/build.xml:112: 
java.lang.IllegalArgumentException: java.lang.NoClassDefFoundError: 
javax/jdo/spi/PersistenceCapable
at 
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:175)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.ant.execution.AntMain2.main(AntMain2.java:32)
Caused by: java.lang.IllegalArgumentException: java.lang.NoClassDefFoundError: 
javax/jdo/spi/PersistenceCapable
at serp.util.Strings.toClass(Strings.java:164)
at serp.util.Strings.toClass(Strings.java:108)
at 
org.apache.openjpa.lib.meta.ClassArgParser.parseTypes(ClassArgParser.java:164)
at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4659)
at 
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
at 
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:171)
... 21 more

If i remove the include and use the one which is currently commented out. 
Everything works fine as it did years before i am clueless..


Thanks for any pointer.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: IntId cannot be cast to ContainerShipment with FetchType.EAGER

[Marc Logemann]

hmm. it seems to be a data issue but a strange one. If the child entity 
(OrderPosition) has no reference to an entity in ContainerShipment (parent), i 
will get this stack trace. Normally i would think that attribute 
List orderPositions would be null in ContainerShipment and 
everything is fine but somehow i need at least one "n" relation. Never 
experienced this

Here is my back reference in OrderPosition. 

@ManyToOne
@JoinColumn(name = "con_ship_id", referencedColumnName = "id")
ContainerShipment containerShipment;
 
still confused.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 29.08.2011 um 23:57 schrieb Marc Logemann:

> Hi,
> 
> aother openjpa thing. Most likely again not a bug but i will try ;-)
> 
> I have a normal 1:n relation in my ContainerShipment class which works pretty 
> well.
> 
>@OneToMany(mappedBy = "containerShipment", cascade = CascadeType.ALL)
>List orderPositions;
> 
> but as soon as i annotate with FetchType.EAGER...
> 
>@OneToMany(mappedBy = "containerShipment", cascade = CascadeType.ALL, 
> fetch = FetchType.EAGER)
>List orderPositions;
> 
> i get this stack trace and i really dont have a clue. I checked gazillions of 
> things w/o success. I also made sure that every record as a perfect relation 
> so that i can be sure thats not a data content issue. Any ideas?
> 
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> root cause java.lang.ClassCastException: 
> org.apache.openjpa.util.IntId cannot be cast to 
> de.logentis.bwh.model.ContainerShipment
>   de.logentis.bwh.model.OrderPosition.pcReplaceField(OrderPosition.java)
>   
> org.apache.openjpa.kernel.StateManagerImpl.replaceField(StateManagerImpl.java:3162)
>   
> org.apache.openjpa.kernel.StateManagerImpl.storeObjectField(StateManagerImpl.java:2596)
>   
> org.apache.openjpa.kernel.StateManagerImpl.storeObject(StateManagerImpl.java:2586)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setMappedBy(JDBCStoreManager.java:505)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:431)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:333)
>   
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112)
>   
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
>   org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1027)
>   org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:985)
>   org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:907)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1041)
>   org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:280)
>   
> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2381)
>   
> org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrategy.loadElement(RelationToManyInverseKeyFieldStrategy.java:90)
>   
> org.apache.openjpa.jdbc.meta.strats.RelationCollectionInverseKeyFieldStrategy.loadElement(RelationCollectionInverseKeyFieldStrategy.java:76)
>   
> org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.processEagerParallelResult(StoreCollectionFieldStrategy.java:312)
>   
> org.apache.openjpa.jdbc.meta.strats.StoreCollectionFieldStrategy.loadEagerParallel(StoreCollectionFieldStrategy.java:246)
>   
> org.apache.openjpa.jdbc.meta.FieldMapping.loadEagerParallel(FieldMapping.java:916)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1114)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1067)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:438)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:333)
>   
> org.apache.openjpa.kernel.DelegatingStoreManager.initialize(DelegatingStoreManager.java:112)
>   
> org.apache.openjpa.kernel.ROPStoreManager.initialize(ROPStoreManager.java:57)
>   org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:1027)
>   org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:985)
>   org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:907)
>   
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1041)
>   org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:280)
>   
> org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2381)
>   org.apache.openjpa

IntId cannot be cast to ContainerShipment with FetchType.EAGER

[Marc Logemann]

mpleJpaRepository.java:434)

org.springframework.data.jpa.repository.support.SimpleJpaRepository.findAll(SimpleJpaRepository.java:303)

org.springframework.data.jpa.repository.support.SimpleJpaRepository.findAll(SimpleJpaRepository.java:260)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)

org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.executeMethodOn(RepositoryFactorySupport.java:361)

org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:342)

org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)

org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:155)

org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
$Proxy135.findAll(Unknown Source)

de.netstorsys.controller.rest.ContainerShipmentRestController.showAll(ContainerShipmentRestController.java:51)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)

org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)

org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:426)

org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:414)

org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790)

org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)

org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)

org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:549)
javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)

org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)

---
regards
Marc Logemann

Re: Like issue with @Embedded attribute with Spring Data JPA

[Marc Logemann]

thanks Pinaki. The spring guys finally admitted that its their fault ... your 
answer helped a lot to convince them ;-) I somehow knew it before but my voice 
was not loud enough

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 29.08.2011 um 22:38 schrieb Pinaki Poddar:

>> at org.apache.openjpa.persistence.criteria.PathImpl.get(PathImpl.java:270)
>> at
>> org.springframework.data.jpa.repository.query.JpaQueryCreator.toPredicate(JpaQueryCreator.java:204)
> 
> Looks like Spring (JpaQueryCreator) is building a Criteria query from form
> input. That code needs to split the dot separated path to individual path
> segments. 
> 
>> Do you expect a object-graph string in this method? 
> no.
> 
> -
> Pinaki Poddar
> Chair, Apache OpenJPA Project
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/Like-issue-with-Embedded-attribute-with-Spring-Data-JPA-tp6735592p6739467.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: Like issue with @Embedded attribute with Spring Data JPA

[Marc Logemann]

Sorry, the JpaQueryBuilder.class is part of Spring Data. The relevant OpenJPA 
class is PathImpl.class of course. 

This Method fails:

public  Path get(String attName) {
Type type = this.getType();
if (type.getPersistenceType() == PersistenceType.BASIC) {
throw new IllegalArgumentException(this + " is a basic path and can 
not be navigated to " + attName);
}

Members.Member next = (Members.Member) 
   ((ManagedType)type).getAttribute(attName);
return new PathImpl(this, next, next.getJavaType());
}

"attName" has the value "pickBarcode.orderId" in my case. Do you expect a 
object-graph string in this method? If yes, it should work because 
pickBarcode.orderId is in fact part of my AlphaScan Class.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 28.08.2011 um 22:41 schrieb Marc Logemann:

> Hi,
> 
> in the Spring Data Forum we are discussing a problem which might be a OpenJPA 
> Bug. Please visit this thread as it contains all the stuff one needs to check 
> this issue:
> http://forum.springsource.org/showthread.php?113890-issue-with-Like-Or-and-nested-Properties-in-SpringData-JPA
> 
> I am coding against OpenJPA 2.1.0 and the problem arises when JpaQueryBuilder 
> will create a Like Predicate. 
> 
> Little stack trace also here ;-)
> 
> Caused by: java.lang.IllegalArgumentException: Attribute 
> "pickBarcode.orderId" of any not found in de.logentis.bwh.model.AlphaScan
>   at 
> org.apache.openjpa.persistence.meta.AbstractManagedType.notFoundException(AbstractManagedType.java:734)
>   at 
> org.apache.openjpa.persistence.meta.AbstractManagedType.getAttribute(AbstractManagedType.java:237)
>   at 
> org.apache.openjpa.persistence.meta.AbstractManagedType.getAttribute(AbstractManagedType.java:461)
>   at 
> org.apache.openjpa.persistence.criteria.PathImpl.get(PathImpl.java:270)
>   at 
> org.springframework.data.jpa.repository.query.JpaQueryCreator.toPredicate(JpaQueryCreator.java:204)
>   at 
> org.springframework.data.jpa.repository.query.JpaQueryCreator.create(JpaQueryCreator.java:102)
>   at 
> org.springframework.data.jpa.repository.query.JpaQueryCreator.create(JpaQueryCreator.java:51)
>   at 
> org.springframework.data.repository.query.parser.AbstractQueryCreator.createCriteria(AbstractQueryCreator.java:90)
>   at 
> org.springframework.data.repository.query.parser.AbstractQueryCreator.createQuery(AbstractQueryCreator.java:68)
>   at 
> org.springframework.data.jpa.repository.query.PartTreeJpaQuery.createCountQuery(PartTreeJpaQuery.java:101)
>   at 
> org.springframework.data.jpa.repository.query.JpaQueryExecution$PagedExecution.doExecute(JpaQueryExecution.java:106)
>   at 
> org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:55)
>   at 
> org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:100)
>   at 
> org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:89)
>   at 
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:336)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:155)
>   ... 30 more
> 
> pickBarcode is an embedded attribute in AlphaScan and orderId is an attribute 
> in PickBarcode. When issueing the same query without like, everything is 
> fine. Spring Data JPA abstracts developers form creating the queries 
> themselves and instead we only need to create an interface with a method name 
> which exposes the query with some special syntax.
> 
> THanks for input on this. I could easily debug this stuff but i really dont 
> want to dig through OpenJPA internals. But if i can help by providing some 
> variables values or something, i am willing to help solving this.
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 

Like issue with @Embedded attribute with Spring Data JPA

[Marc Logemann]

Hi,

in the Spring Data Forum we are discussing a problem which might be a OpenJPA 
Bug. Please visit this thread as it contains all the stuff one needs to check 
this issue:
http://forum.springsource.org/showthread.php?113890-issue-with-Like-Or-and-nested-Properties-in-SpringData-JPA

I am coding against OpenJPA 2.1.0 and the problem arises when JpaQueryBuilder 
will create a Like Predicate. 

Little stack trace also here ;-)

Caused by: java.lang.IllegalArgumentException: Attribute "pickBarcode.orderId" 
of any not found in de.logentis.bwh.model.AlphaScan
at 
org.apache.openjpa.persistence.meta.AbstractManagedType.notFoundException(AbstractManagedType.java:734)
at 
org.apache.openjpa.persistence.meta.AbstractManagedType.getAttribute(AbstractManagedType.java:237)
at 
org.apache.openjpa.persistence.meta.AbstractManagedType.getAttribute(AbstractManagedType.java:461)
at 
org.apache.openjpa.persistence.criteria.PathImpl.get(PathImpl.java:270)
at 
org.springframework.data.jpa.repository.query.JpaQueryCreator.toPredicate(JpaQueryCreator.java:204)
at 
org.springframework.data.jpa.repository.query.JpaQueryCreator.create(JpaQueryCreator.java:102)
at 
org.springframework.data.jpa.repository.query.JpaQueryCreator.create(JpaQueryCreator.java:51)
at 
org.springframework.data.repository.query.parser.AbstractQueryCreator.createCriteria(AbstractQueryCreator.java:90)
at 
org.springframework.data.repository.query.parser.AbstractQueryCreator.createQuery(AbstractQueryCreator.java:68)
at 
org.springframework.data.jpa.repository.query.PartTreeJpaQuery.createCountQuery(PartTreeJpaQuery.java:101)
at 
org.springframework.data.jpa.repository.query.JpaQueryExecution$PagedExecution.doExecute(JpaQueryExecution.java:106)
at 
org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:55)
at 
org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:100)
at 
org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:89)
at 
org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:336)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:155)
... 30 more

pickBarcode is an embedded attribute in AlphaScan and orderId is an attribute 
in PickBarcode. When issueing the same query without like, everything is fine. 
Spring Data JPA abstracts developers form creating the queries themselves and 
instead we only need to create an interface with a method name which exposes 
the query with some special syntax.

THanks for input on this. I could easily debug this stuff but i really dont 
want to dig through OpenJPA internals. But if i can help by providing some 
variables values or something, i am willing to help solving this.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: same jpa query generates different SQLs

[Marc Logemann]

Hi,

the issue is: https://issues.apache.org/jira/browse/OPENJPA-1955

Seems nobody cared so far ;-) Feel free to vote up (if this is possible). 

Greetings to Fabian Lange btw. Just noticed you both work for the same company. 
He knows me from Nokia-Siemens back then.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 07.04.2011 um 14:52 schrieb Tobias Trelle:

> 
> Marc Logemann wrote:
>> 
>> created an issue for it. Thanks for your ideas to make the cache
>> disablement query based
>> 
> 
> Dear Marc,
> 
> can you please provide a link to this issue? I'm facing the same problem
> with OpenJPA 2.0.1 und DB2 V9:
> 
> I have a query based on two Date parameters (amongst others). The first time
> the query is executed, it runs fine and uses SQL type DATE:
> 
> 
>...
>WHERE ((t0.A = ? OR t0.B = ? OR t0.C= ?) AND t0.Z >= ? AND t0.Z <= ?) 
> [params=(int) 41140, (int) 41140, (int) 41140, (Date) 2010-08-01, (Date)
> 2010-12-31]
> 
> 
> The second execution looks like this ...
> 
> 
>...
>WHERE ((t0.A= ? OR t0.B= ? OR t0.C= ?) AND t0.Z >= ? AND t0.Z <= ?) 
> [params=(int) 41140, (int) 41140, (int) 41140, (Timestamp) 2010-08-01
> 14:47:05.812, (Timestamp) 2010-12-31 14:47:05.812]
> 
> 
> ... and fails with 
> 
>   DB2 SQL Error: SQLCODE=-181, SQLSTATE=22007
> 
> because the DB2 column is of type DATE.
> 
> Will we run into performance issues if we disable the QuerySQLCache? Our
> persistence unit uses only two named queries.
> 
> Cheers,
> Tobias
> 
> 
> 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/same-jpa-query-generates-different-SQLs-tp6081417p6249868.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

great News!

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 25.03.2011 um 15:56 schrieb Rick Curtis:

> Marc -
> 
> This problem is fixed[1] in the 2.1.x stream and trunk.
> 
> [1] http://issues.apache.org/jira/browse/OPENJPA-1965
> 
> Thanks,
> Rick
> 
> On Thu, Mar 24, 2011 at 12:57 PM, Rick Curtis  wrote:
> 
>>> I have heard it said that "programmatic javac compiler for debugging"
>> means that you have a junit testcase which calls com.sun.tools.javac.Main.
>> 
>> I heard it somehow involved a chicken and some sort of voodoo dance. :)
>> 
>> 
>> On Thu, Mar 24, 2011 at 11:27 AM, Michael Dick 
>> wrote:
>> 
>>> On Thu, Mar 24, 2011 at 10:40 AM, Marc Logemann  wrote:
>>> 
>>>>> 
>>>>>> you are late.
>>>>> Not really. The code was written two years ago, with a programmatic
>>> javac
>>>>> compiler for debugging ;)
>>>> 
>>>> 
>>>> thats not what i meant. I meant in following our discussion on the list
>>> ;-)
>>>> When i am old and skilled i will check again what you mean with
>>>> "programmatic javac compiler for debugging" :-) until that time point, i
>>>> continue doing this poor "implement a copy/pasted processor and write
>>> some
>>>> println statements in there" (c) hrhr.
>>>> 
>>> 
>>> I have heard it said that "programmatic javac compiler for debugging"
>>> means
>>> that you have a junit testcase which calls com.sun.tools.javac.Main. That
>>> way you can debug your junit (or your own main method) and step into the
>>> compilation process.
>>> 
>>> -mike
>>> 
>> 
>> 

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Am 24.03.2011 um 17:27 schrieb Michael Dick:

> On Thu, Mar 24, 2011 at 10:40 AM, Marc Logemann  wrote:
> 
>>> 
>>>> you are late.
>>> Not really. The code was written two years ago, with a programmatic javac
>>> compiler for debugging ;)
>> 
>> 
>> thats not what i meant. I meant in following our discussion on the list ;-)
>> When i am old and skilled i will check again what you mean with
>> "programmatic javac compiler for debugging" :-) until that time point, i
>> continue doing this poor "implement a copy/pasted processor and write some
>> println statements in there" (c) hrhr.
>> 
> 
> I have heard it said that "programmatic javac compiler for debugging" means
> that you have a junit testcase which calls com.sun.tools.javac.Main. That
> way you can debug your junit (or your own main method) and step into the
> compilation process.
> 
> -mike

ahh now i get it. This sounds smart. To be honest, i never ever dealt with 
com.sun.tools.javac.Main directly during my 8 years of java development ;-)

My way was also quite nice because now i have my own AnnotationProcessor 
variant, which will stay active until you guys fix the one in the 2.1.x 
release... or i can use Ricks patched jar of course.

Marc

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

> 
>> you are late. 
> Not really. The code was written two years ago, with a programmatic javac
> compiler for debugging ;)


thats not what i meant. I meant in following our discussion on the list ;-) 
When i am old and skilled i will check again what you mean with "programmatic 
javac compiler for debugging" :-) until that time point, i continue doing this 
poor "implement a copy/pasted processor and write some println statements in 
there" (c) hrhr.

Marc

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

you are late. We basically figured out all the issues. I also presented a fix 
and Rick supplied a patched jar and hopefully this fix will make it into the 
next 2.1 release.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 24.03.2011 um 14:25 schrieb Pinaki Poddar:

>> Debugging is also not that easy within an ANT process. Perhaps someone give
> me an hint how to proceed.
> 
> Invoke javac compiler programmatically. Pass "opejpa.metamodel" in compiler
> argument. 
> You will require tools.jar in your classpath. 
> 
> -
> Pinaki 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/MetaModel-creation-with-Aopenjpa-generate-true-tp6200077p6204075.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Hi,

i am quite sure that there were a lot more jars when i had the single ALL 
dependency in my ivy setup. 
Dont have the time to prove right now. In fact one dont need the service file 
when using the -processor flag in javac.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 24.03.2011 um 14:00 schrieb Pinaki Poddar:

> Hi,
>  The annotation processing requires dependency on openjpa-all jar. Can you
> please explain why you declared dependencies to individual module jars but
> not the consolidated openjpa jar? 
> 
>> I dont want to inlcude "openjpa" as a whole because i want to leave
> out unneeded clutter. 
>But it seemed to be OK to include 3/4 individual openjpa*.jar -- that
> looks more cluttered to me.
> 
> Anyway, our service file packaging will not cope with the individual
> jar dependencies as you have described. You need to have a single openjpa
> jar in your classpath
> 
>  To generate canonical metamodel classes using OpenJPA has two
> pre-requisites
>   1. compiler classpath must have consolidated openjpa jar
>   2. Compiler argument -Aopenjpa.metamodel=true must be set 
> 
> 
> 
> 
> -
> Pinaki 
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/MetaModel-creation-with-Aopenjpa-generate-true-tp6200077p6203998.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Hi,

this is nearly impossible because its not an Entity which makes the problem 
here. Its a package. I have no idea how to unit test that. Perhaps you can try 
creating 
a simple package with JAXB generated classes in it and try to reproduce:

1) create a very simple XSD file
2) run the JAXB compiler via ANT (then you should have some classes in 
myweirdpackage)





  

3) put at least one Entity in domain package (parent of myweirdpackage)
4) run the MetaModel compiling step

Does this help?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 20:45 schrieb Rick Curtis:

> Marc -
> 
> Give this[1] patch a shot. If you can help me come up with a test Entity
> model that exposes this problem I have a pretty good chance of being able to
> get it into 2.1.1.
> 
> [1]
> http://people.apache.org/~curtisr7/patches/annotation_processor_patch.jar
> 
> Thanks,
> Rick
> 
> On Wed, Mar 23, 2011 at 11:29 AM, Marc Logemann  wrote:
> 
>> +1 for the patch on AnnotationProcessor6 for the 2.1.x release line.
>> Of course this would make my life easier. I could drop my own variant.
>> I always like using framework classes instead of patched-own-versions.
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> Am 23.03.2011 um 17:20 schrieb Rick Curtis:
>> 
>>>> BTW it was a bit of a mess to create my own version of this class
>> because
>>> SourceAnnotationHandler.class has a lot of package private methods which
>> are
>>> used by AnnotationProcessor6. So i also needed to clone that class too.
>>> g. :-)
>>> I could easily create a patch to put on top of the existing
>>> AnnotationProcessor6 if that would make your life easier? (You're running
>>> 2.1.x right?)
>>> 
>>>> I am quite sure that there are not that much people out there using the
>>> MetaModel feature at all. Because first you need to use Criteria API
>> which
>>> is probably also not THAT widespreaded so far. This could be the reason
>> why
>>> this bug is not mentioned somewhere.
>>> +1
>>> 
>>> Thanks,
>>> Rick
>>> 
>>> On Wed, Mar 23, 2011 at 11:03 AM, Marc Logemann  wrote:
>>> 
>>>> Hi,
>>>> 
>>>> hope i could help a bit in researching this. For now i will use my own
>>>> variant of AnnotationProcessor6.
>>>> 
>>>> BTW it was a bit of a mess to create my own version of this class
>> because
>>>> SourceAnnotationHandler.class has a lot of package private methods which
>> are
>>>> used by AnnotationProcessor6. So i also needed to clone that class too.
>>>> g. :-)
>>>> 
>>>> I am quite sure that there are not that much people out there using the
>>>> MetaModel feature at all. Because first you need to use Criteria API
>> which
>>>> is probably also not THAT widespreaded so far. This could be the reason
>> why
>>>> this bug is not mentioned somwhere.
>>>> 
>>>> But software development is crazy. You start using Criteria API because
>> its
>>>> somewhat typesafe in conjunction with MetaModel and now you are fighting
>>>> with AnnotationProcessor. Not really where we make our money. But on the
>>>> other hand its a challenge to find out why things break.
>>>> 
>>>> ---
>>>> regards
>>>> Marc Logemann
>>>> http://www.logemann.org
>>>> http://www.logentis.de
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Am 23.03.2011 um 16:55 schrieb Rick Curtis:
>>>> 
>>>>> Yes that seems reasonable. I'll get that taken care of sometime this
>>>>> afternoon.
>>>>> 
>>>>> I'd like to get another JIRA opened up to investigate the JAXB
>>>>> packageElements problem
>>>>> 
>>>>> Thanks,
>>>>> Rick
>>>>> 
>>>>> On Wed, Mar 23, 2011 at 10:51 AM, Marc Logemann 
>> wrote:
>>>>> 
>>>>>> For the time being, how about the following fix in openjpa trunk:
>>>>>> 
>>>>>> /**
>>>>>>  * The entry point for java compiler.
>>>>>>  */
>>>>>>  @Override
>>>>>> public boolean process(Set annos,
>>>>>> RoundEnvironment roundEnv) {
>>>&

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

+1 for the patch on AnnotationProcessor6 for the 2.1.x release line.
Of course this would make my life easier. I could drop my own variant.
I always like using framework classes instead of patched-own-versions.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 17:20 schrieb Rick Curtis:

>> BTW it was a bit of a mess to create my own version of this class because
> SourceAnnotationHandler.class has a lot of package private methods which are
> used by AnnotationProcessor6. So i also needed to clone that class too.
> g. :-)
> I could easily create a patch to put on top of the existing
> AnnotationProcessor6 if that would make your life easier? (You're running
> 2.1.x right?)
> 
>> I am quite sure that there are not that much people out there using the
> MetaModel feature at all. Because first you need to use Criteria API which
> is probably also not THAT widespreaded so far. This could be the reason why
> this bug is not mentioned somewhere.
> +1
> 
> Thanks,
> Rick
> 
> On Wed, Mar 23, 2011 at 11:03 AM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> hope i could help a bit in researching this. For now i will use my own
>> variant of AnnotationProcessor6.
>> 
>> BTW it was a bit of a mess to create my own version of this class because
>> SourceAnnotationHandler.class has a lot of package private methods which are
>> used by AnnotationProcessor6. So i also needed to clone that class too.
>> g. :-)
>> 
>> I am quite sure that there are not that much people out there using the
>> MetaModel feature at all. Because first you need to use Criteria API which
>> is probably also not THAT widespreaded so far. This could be the reason why
>> this bug is not mentioned somwhere.
>> 
>> But software development is crazy. You start using Criteria API because its
>> somewhat typesafe in conjunction with MetaModel and now you are fighting
>> with AnnotationProcessor. Not really where we make our money. But on the
>> other hand its a challenge to find out why things break.
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> Am 23.03.2011 um 16:55 schrieb Rick Curtis:
>> 
>>> Yes that seems reasonable. I'll get that taken care of sometime this
>>> afternoon.
>>> 
>>> I'd like to get another JIRA opened up to investigate the JAXB
>>> packageElements problem
>>> 
>>> Thanks,
>>> Rick
>>> 
>>> On Wed, Mar 23, 2011 at 10:51 AM, Marc Logemann  wrote:
>>> 
>>>> For the time being, how about the following fix in openjpa trunk:
>>>> 
>>>>  /**
>>>>   * The entry point for java compiler.
>>>>   */
>>>>   @Override
>>>>  public boolean process(Set annos,
>>>> RoundEnvironment roundEnv) {
>>>>  if (active && !roundEnv.processingOver()) {
>>>>  Set elements = roundEnv.getRootElements();
>>>>  for (Element e : elements) {
>>>>   if (e instanceof TypeElement)
>>>>  process((TypeElement) e);
>>>>  }
>>>>  }
>>>>  return true;
>>>>  }
>>>> 
>>>> 
>>>> We simply ignore "PackageElement", "ExecutableElement",
>>>> "TypeParameterElement" and "VariableElement". (These are the other
>>>> Subinterfaces of Element)
>>>> 
>>>> With this we dont get into trouble and we have time to elaborate on the
>>>> real problem. roundEnv.getRootElements() simply can return also
>>>> PackageElements. Why this is only the case for this package with JAXB
>> file
>>>> is something which one need to research. Thats definitely something in
>> the
>>>> javax.annotation.processing area of the JDK. But there  must be a reason
>>>> that getRootElements() returns Element and not TypeElement ;-)
>>>> 
>>>> ---
>>>> regards
>>>> Marc Logemann
>>>> http://www.logemann.org
>>>> http://www.logentis.de
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Am 23.03.2011 um 16:41 schrieb Rick Curtis:
>>>> 
>>>>>> 
>>>>>>> still a bit clueless
>>>>>> 
>>>>> 
>>>>> Me too. I just started digging into some of the annotation processor
>> code
>>>> to
>>>>> see if I can learn something today So when you swallowed the
>>>> exception
>>>>> everything worked fine?
>>>>> 
>>>>> Thanks,
>>>>> Rick
>>>> 
>>>> 
>> 
>> 

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Hi,

hope i could help a bit in researching this. For now i will use my own variant 
of AnnotationProcessor6. 

BTW it was a bit of a mess to create my own version of this class because 
SourceAnnotationHandler.class has a lot of package private methods which are 
used by AnnotationProcessor6. So i also needed to clone that class too.  g. 
:-)

I am quite sure that there are not that much people out there using the 
MetaModel feature at all. Because first you need to use Criteria API which is 
probably also not THAT widespreaded so far. This could be the reason why this 
bug is not mentioned somwhere.

But software development is crazy. You start using Criteria API because its 
somewhat typesafe in conjunction with MetaModel and now you are fighting with 
AnnotationProcessor. Not really where we make our money. But on the other hand 
its a challenge to find out why things break.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 16:55 schrieb Rick Curtis:

> Yes that seems reasonable. I'll get that taken care of sometime this
> afternoon.
> 
> I'd like to get another JIRA opened up to investigate the JAXB
> packageElements problem
> 
> Thanks,
> Rick
> 
> On Wed, Mar 23, 2011 at 10:51 AM, Marc Logemann  wrote:
> 
>> For the time being, how about the following fix in openjpa trunk:
>> 
>>   /**
>>* The entry point for java compiler.
>>*/
>>@Override
>>   public boolean process(Set annos,
>> RoundEnvironment roundEnv) {
>>   if (active && !roundEnv.processingOver()) {
>>   Set elements = roundEnv.getRootElements();
>>   for (Element e : elements) {
>>if (e instanceof TypeElement)
>>   process((TypeElement) e);
>>   }
>>   }
>>   return true;
>>   }
>> 
>> 
>> We simply ignore "PackageElement", "ExecutableElement",
>> "TypeParameterElement" and "VariableElement". (These are the other
>> Subinterfaces of Element)
>> 
>> With this we dont get into trouble and we have time to elaborate on the
>> real problem. roundEnv.getRootElements() simply can return also
>> PackageElements. Why this is only the case for this package with JAXB file
>> is something which one need to research. Thats definitely something in the
>> javax.annotation.processing area of the JDK. But there  must be a reason
>> that getRootElements() returns Element and not TypeElement ;-)
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> Am 23.03.2011 um 16:41 schrieb Rick Curtis:
>> 
>>>> 
>>>>> still a bit clueless
>>>> 
>>> 
>>> Me too. I just started digging into some of the annotation processor code
>> to
>>> see if I can learn something today So when you swallowed the
>> exception
>>> everything worked fine?
>>> 
>>> Thanks,
>>> Rick
>> 
>> 

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

For the time being, how about the following fix in openjpa trunk:

/**
 * The entry point for java compiler.
 */
@Override
public boolean process(Set annos, RoundEnvironment 
roundEnv) {
if (active && !roundEnv.processingOver()) {
Set elements = roundEnv.getRootElements();
for (Element e : elements) {
if (e instanceof TypeElement)
process((TypeElement) e);
}
}
return true;
}


We simply ignore "PackageElement", "ExecutableElement", "TypeParameterElement" 
and "VariableElement". (These are the other Subinterfaces of Element)

With this we dont get into trouble and we have time to elaborate on the real 
problem. roundEnv.getRootElements() simply can return also PackageElements. Why 
this is only the case for this package with JAXB file is something which one 
need to research. Thats definitely something in the javax.annotation.processing 
area of the JDK. But there  must be a reason that getRootElements() returns 
Element and not TypeElement ;-)

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 16:41 schrieb Rick Curtis:

>> 
>>> still a bit clueless
>> 
> 
> Me too. I just started digging into some of the annotation processor code to
> see if I can learn something today So when you swallowed the exception
> everything worked fine?
> 
> Thanks,
> Rick

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Correction:

> With my program, i get a result of course because i dont leave the process on 
> error ;-) But this is the solution. 

This is NOT the solution i meant.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 16:38 schrieb Marc Logemann:

> Puuuh. Its me again.
> 
> I am gone the hard route and created my own variant of AnnotationProcesso:
> 
>@Override
>public boolean process(Set annos, RoundEnvironment 
> roundEnv) {
>if (active && !roundEnv.processingOver()) {
>Set elements = roundEnv.getRootElements();
>for (Element e : elements) {
>try {
>System.out.println("Element inside Set --> "+ e);
>process((TypeElement) e);
>} catch (RuntimeException e1) {
>System.out.println("Error -->"+ e);
>}
>}
>}
>return true;
>}
> 
> 
> with more logging and something strange can be seen:
> 
> ...
>[javac] Element inside Set --> 
> de.netversys.carriers.tourline.process.TourlineRoutingBarcode
>[javac] Element inside Set --> 
> de.netversys.carriers.tourline.process.TourlineSenderBarcode
>[javac] Element inside Set --> de.netversys.carriers.bartolini.domain.xml
>[javac] Error -->de.netversys.carriers.bartolini.domain.xml
> 
> 
> The "-->" lines is the output before the process() call in the for loop which 
> i coded in there.
> 
> The last line is interessting. This is not a class, this is a package! (with 
> JAXB generated stuff in it)
> 
> Now the error message
> java.lang.ClassCastException: com.sun.tools.javac.code.Symbol$PackageSymbol 
> cannot be cast to javax.lang.model.element.TypeElement
> 
> makes sense because he says something about PackageSymbol. Now more questions 
> comes up than it solves. Why is this package inside the Element Set ??
> Its a normal package under one of my domain packages. But inside this 
> package, there are only JAXB generated classes.
> 
> Perhaps JAXB generated classe with its ObjectFactory stuff is handled 
> differently by the JDK Annotation framework. But i have other places with 
> JAXB stuff in it. Cant be the issue.
> 
> With my program, i get a result of course because i dont leave the process on 
> error ;-) But this is the solution. 
> 
> 
> still a bit clueless
> 
> --
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 
> Am 23.03.2011 um 15:51 schrieb Rick Curtis:
> 
>> Marc -
>> 
>> Can you narrow down the Entity which is having the problem so we can write a
>> unit test?
>> 
>> Thanks,
>> Rick
> 

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Puuuh. Its me again.

I am gone the hard route and created my own variant of AnnotationProcesso:

@Override
public boolean process(Set annos, RoundEnvironment 
roundEnv) {
if (active && !roundEnv.processingOver()) {
Set elements = roundEnv.getRootElements();
for (Element e : elements) {
try {
System.out.println("Element inside Set --> "+ e);
process((TypeElement) e);
} catch (RuntimeException e1) {
System.out.println("Error -->"+ e);
}
}
}
return true;
}


with more logging and something strange can be seen:

...
[javac] Element inside Set --> 
de.netversys.carriers.tourline.process.TourlineRoutingBarcode
[javac] Element inside Set --> 
de.netversys.carriers.tourline.process.TourlineSenderBarcode
[javac] Element inside Set --> de.netversys.carriers.bartolini.domain.xml
[javac] Error -->de.netversys.carriers.bartolini.domain.xml


The "-->" lines is the output before the process() call in the for loop which i 
coded in there.

The last line is interessting. This is not a class, this is a package! (with 
JAXB generated stuff in it)

Now the error message
java.lang.ClassCastException: com.sun.tools.javac.code.Symbol$PackageSymbol 
cannot be cast to javax.lang.model.element.TypeElement

makes sense because he says something about PackageSymbol. Now more questions 
comes up than it solves. Why is this package inside the Element Set ??
Its a normal package under one of my domain packages. But inside this package, 
there are only JAXB generated classes.

Perhaps JAXB generated classe with its ObjectFactory stuff is handled 
differently by the JDK Annotation framework. But i have other places with JAXB 
stuff in it. Cant be the issue.

With my program, i get a result of course because i dont leave the process on 
error ;-) But this is the solution. 


still a bit clueless

--
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 15:51 schrieb Rick Curtis:

> Marc -
> 
> Can you narrow down the Entity which is having the problem so we can write a
> unit test?
> 
> Thanks,
> Rick

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

one more thing. 

You have something like this in the second process() method:

private boolean process(TypeElement e) {

catch (Exception e1) {
logger.error(_loc.get("mmg-process-error", e.getQualifiedName()), 
e1);
return false;
} finally {
...


This is cool if get an error in the real process but this one here:

public boolean process(Set annos, RoundEnvironment 
roundEnv) {
if (active && !roundEnv.processingOver()) {
Set elements = roundEnv.getRootElements();
for (Element e : elements) {
process((TypeElement) e);
}
}
}

is the caller and we dont have any logging here if the cast fails. This leaves 
a user in a unpleasant situation when something goes wrong on that line (as it 
is with my situation).
As every java developer know "a cast can fail" and i would like to see a 
logging for that to and a re-throw after that.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 15:51 schrieb Rick Curtis:

> Marc -
> 
> Can you narrow down the Entity which is having the problem so we can write a
> unit test?
> 
> Thanks,
> Rick

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Thats exactly  what i am trying the last 10 minutes but its not that easy 
because he doesnt process alphabetically or something. In fact i have more than 
30 entities which are not processed. One of those is the problem of course.
the  thingy doesnt reveal very much. 
I just see many lines like these:

[javac] Note: Generating canonical metamodel source code 
"src/de/netversys/domain/JobTrigger_.java"
[javac] Note: Generating canonical metamodel source code 
"src/de/netversys/domain/Label_.java"
...


Dont even know if this is a trace output or just the usual clutter which comes 
out anyway. Debugging is also not that easy within an ANT process. Perhaps 
someone give me an hint how to proceed. I really dont want to recompile the 
AnnotationProcessor6 class.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 15:51 schrieb Rick Curtis:

> Marc -
> 
> Can you narrow down the Entity which is having the problem so we can write a
> unit test?
> 
> Thanks,
> Rick

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Hi.

thx for pointing out the -processor thingy. This works basically and i dont 
have to worry what kind of jar to include or to check where the service file is 
(the openjpa team should really think about putting it to 
openjpa-persistence.jar again).

So i see a lot of metamodel classes got generated but during this process i got 
this:

[javac] An annotation processor threw an uncaught exception.
[javac] Consult the following stack trace for details.
[javac] java.lang.ClassCastException: 
com.sun.tools.javac.code.Symbol$PackageSymbol cannot be cast to 
javax.lang.model.element.TypeElement
[javac] at 
org.apache.openjpa.persistence.meta.AnnotationProcessor6.process(AnnotationProcessor6.java:207)
[javac] at 
com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:625)
[javac] at 
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:554)
[javac] at 
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:699)
[javac] at 
com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:981)
[javac] at 
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
[javac] at com.sun.tools.javac.main.Main.compile(Main.java:353)
[javac] at com.sun.tools.javac.main.Main.compile(Main.java:279)
[javac] at com.sun.tools.javac.main.Main.compile(Main.java:270)
[javac] at com.sun.tools.javac.Main.compile(Main.java:69)
[javac] at com.sun.tools.javac.Main.main(Main.java:54)


So now my build fails and this before my very own classes get compiled. I get a 
lot of metamodel classes and within that process that ClassCastException occurs.



---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 15:03 schrieb Rick Curtis:

>> If you try manually adding the services entry, do the metamodel classes get
> generated correctly?
> 
> Perhaps you could try? 
> 
> Thanks,
> Rick
> 
> On Wed, Mar 23, 2011 at 8:59 AM, Michael Dick wrote:
> 
>> Hi,
>> 
>> The services file was intentionally moved under
>> OPENJPA-1622<https://issues.apache.org/jira/browse/OPENJPA-1622>.
>> It's not clear from the JIRA why it was moved, but my guess is that it was
>> causing problems with the aggregate jars or OSGi.
>> 
>> I'm not sure that's a lot of help. If you try manually adding the services
>> entry, do the metamodel classes get generated correctly?
>> 
>> -mike
>> 
>> On Wed, Mar 23, 2011 at 8:54 AM, Marc Logemann  wrote:
>> 
>>> Thats what i gussed at the same time (and sent to the list) as you can
>> see
>>> ;-)
>>> I will check my deps. I dont want to inlcude "openjpa" as a whole because
>> i
>>> want to leave out unneeded clutter.
>>> 
>>> But one thing is weird. The class "AnnotationProcessor6" which is the
>> main
>>> actor in this game is in openjpa-persistence-2.1.0.jar, wouldnt you
>> expect
>>> the service definition in the very same jar file? I do
>>> 
>>> --
>>> regards
>>> Marc Logemann
>>> http://www.logemann.org
>>> http://www.logentis.de
>>> 
>>> 
>>> 
>>> 
>>> Am 23.03.2011 um 14:46 schrieb Rick Curtis:
>>> 
>>>> Try adding a dependency on "openjpa". I'm guessing that the services
>>> file[1]
>>>> isn't packaged in any of your dependencies.?
>>>> 
>>>> [1] META-INF/services/javax.annotation.processing.Processor
>>>> 
>>>> Thanks,
>>>> Rick
>>>> 
>>>> On Wed, Mar 23, 2011 at 7:26 AM, Marc Logemann 
>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> i want to create metamodel classes during build time. So i did that:
>>>>> 
>>>>>  >>>> optimize="false"
>>>>> deprecation="false" failonerror="true" target="1.6"
>>>>> memoryinitialsize="512m" memorymaximumsize="512m">
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> 
>>>>> see the compilerarg feature. The other stuff was already in my
>> build
>>>>> 
>>>>> But i dont see any results. I see no classes being generated
>> somewhere.
>>> I
>>>>> also dont see any warnings or stuff in the build itself. I am using
>>> these
>>>>> dependencies related to OpenJPA
>>>>> 
>>>>>  >> rev="2.1.0"
>>>>> conf="default->default,sources,javadoc"/>
>>>>>  >>>> rev="2.1.0" conf="default->default,sources,javadoc"/>
>>>>>  >> rev="2.1.0"
>>>>> conf="default->default,sources,javadoc"/>
>>>>>  >>>> rev="2.1.0"
>>>>>  conf="default->default,sources,javadoc"/>
>>>>>  >> name="openjpa-persistence-jdbc"
>>>>> rev="2.1.0"
>>>>>  conf="default->default,sources,javadoc"/>
>>>>>  >>>> name="geronimo-jpa_2.0_spec" rev="1.1"/>
>>>>> 
>>>>> 
>>>>> Can anybody tell me whats wrong?
>>>>> 
>>>>> 
>>>>> ---
>>>>> regards
>>>>> Marc Logemann
>>>>> http://www.logemann.org
>>>>> http://www.logentis.de
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>> 

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Thats what i gussed at the same time (and sent to the list) as you can see ;-)
I will check my deps. I dont want to inlcude "openjpa" as a whole because i 
want to leave out unneeded clutter.

But one thing is weird. The class "AnnotationProcessor6" which is the main 
actor in this game is in openjpa-persistence-2.1.0.jar, wouldnt you expect the 
service definition in the very same jar file? I do....

--
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 14:46 schrieb Rick Curtis:

> Try adding a dependency on "openjpa". I'm guessing that the services file[1]
> isn't packaged in any of your dependencies.?
> 
> [1] META-INF/services/javax.annotation.processing.Processor
> 
> Thanks,
> Rick
> 
> On Wed, Mar 23, 2011 at 7:26 AM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> i want to create metamodel classes during build time. So i did that:
>> 
>>   > optimize="false"
>>  deprecation="false" failonerror="true" target="1.6"
>> memoryinitialsize="512m" memorymaximumsize="512m">
>>   
>>   
>>   
>>   
>> 
>> see the compilerarg feature. The other stuff was already in my build
>> 
>> But i dont see any results. I see no classes being generated somewhere. I
>> also dont see any warnings or stuff in the build itself. I am using these
>> dependencies related to OpenJPA
>> 
>>   > conf="default->default,sources,javadoc"/>
>>   > rev="2.1.0" conf="default->default,sources,javadoc"/>
>>   > conf="default->default,sources,javadoc"/>
>>   > rev="2.1.0"
>>   conf="default->default,sources,javadoc"/>
>>   > rev="2.1.0"
>>   conf="default->default,sources,javadoc"/>
>>   > name="geronimo-jpa_2.0_spec" rev="1.1"/>
>> 
>> 
>> Can anybody tell me whats wrong?
>> 
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> 

Re: MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Hmmm. I dont find the service definition file in any of the openjpa jars. 
According to specs, the file should be named:

META-INF/services/javax.annotation.processing.Processor

I cant find such a file anywhere. 

Am i wrong?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.03.2011 um 13:26 schrieb Marc Logemann:

> Hi,
> 
> i want to create metamodel classes during build time. So i did that:
> 
>   deprecation="false" failonerror="true" target="1.6" 
> memoryinitialsize="512m" memorymaximumsize="512m">
>
>
>
>
> 
> see the compilerarg feature. The other stuff was already in my build
> 
> But i dont see any results. I see no classes being generated somewhere. I 
> also dont see any warnings or stuff in the build itself. I am using these 
> dependencies related to OpenJPA
> 
> conf="default->default,sources,javadoc"/>
> conf="default->default,sources,javadoc"/>
> conf="default->default,sources,javadoc"/>
> rev="2.1.0"
>conf="default->default,sources,javadoc"/>
> rev="2.1.0"
>conf="default->default,sources,javadoc"/>
> name="geronimo-jpa_2.0_spec" rev="1.1"/>
> 
> 
> Can anybody tell me whats wrong?
> 
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 

MetaModel creation with -Aopenjpa.generate=true

[Marc Logemann]

Hi,

i want to create metamodel classes during build time. So i did that:







see the compilerarg feature. The other stuff was already in my build

But i dont see any results. I see no classes being generated somewhere. I also 
dont see any warnings or stuff in the build itself. I am using these 
dependencies related to OpenJPA









Can anybody tell me whats wrong?


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: same jpa query generates different SQLs

[Marc Logemann]

Hi,

created an issue for it. Thanks for your ideas to make the cache disablement 
query based

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 02.03.2011 um 19:10 schrieb Jeremy Bauer:

> Marc,
> 
> I'm glad that worked for you.  You could actually just exclude that query
> for the time being, that way you still get caching benefits for your other
> statements.  To exclude the query you can either set the query hint via
> query.setHint("openjpa.hint.IgnorePreparedQuery", true)  on the query or
> exclude it via persistence property:
> 
>  value="true(excludes='select o FROM Order o where o.createdYmd = ?1
> order by o.id')"/>
> 
> You can get more specifics on cache exclusion in this section of the OpenJPA
> manual[1].
> 
> That should get you by for the time being, but please open a JIRA for this
> problem so that it gets fixed.
> 
> [1]
> http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_cache_querysql.html
> 
> -Jeremy
> 
> On Wed, Mar 2, 2011 at 10:51 AM, Marc Logemann  wrote:
> 
>> Hi Jeremy,
>> 
>> thanks for your instant feedback. I directly tried your suggestion and now
>> it works. So there is a bug in the cache implementation with regard to Type
>> Mappings.
>> And its not a DB2 thingy because i am using MySQL ;-)
>> 
>> if you need more infos in the error case, i am willing to help if you
>> want I would like to see this solved because disabling the cache means
>> decreasing the performance somehow right?
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> Am 02.03.2011 um 17:31 schrieb Jeremy Bauer:
>> 
>>> Hi Marc,
>>> 
>>> I'm wondering if this isn't caused by an inconsistent parameter type
>> mapping
>>> as a result of using the QuerySQLCache. I saw a similar issue a few weeks
>>> ago, but it was oddly specific to DB2 on zOS. Please try:
>>> 
>>> 
>>> 
>>> -Jeremy
>>> 
>>> On Wed, Mar 2, 2011 at 9:43 AM, Marc Logemann  wrote:
>>> 
>>>> Hi,
>>>> 
>>>> i am totally astonished:
>>>> 
>>>> I am using this query:
>>>> 
>>>>  public List findByDate(Date date) {
>>>> 
>>>>  TypedQuery query = getEntityManager().
>>>>  createQuery("select o FROM Order o where o.createdYmd = ?1
>>>> order by o.id", Order.class);
>>>> 
>>>>  query.setParameter(1, date, TemporalType.DATE);
>>>>  return query.getResultList();
>>>>  }
>>>> 
>>>> This query is called by a service class which is scheduled ever 30
>> seconds.
>>>> See the caller:
>>>> 
>>>>  // get yesterdays Date
>>>>  Date today = new Date();
>>>>  Calendar calendar = Calendar.getInstance();
>>>>  calendar.setTime(today);
>>>>  calendar.add(Calendar.DATE, -1);
>>>>  Date yesterday = calendar.getTime();
>>>> 
>>>>  List list = orderDao.findByDate(yesterday);
>>>> 
>>>> 
>>>> Now, on the second run, the query parameter is of type timestamp with
>> full
>>>> time specified, giving me 0 records of course. First query returns
>> records
>>>> because there TemporalType seems to work. See log.
>>>> 
>>>> FIRST RUN ->
>>>> 
>>>> [DEBUG myScheduler-3 16:36:30] |  executing
>>>> prepstmnt 1488869003 SELECT t0.oid, t0.`_version`, t1.oid,
>> t1.`_version`,
>>>> t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
>>>> t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
>>>> t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype,
>>>> t2.printed, t2.printedby, t2.totalprice, t1.boxtype, t0.created,
>>>> t0.createdymd, t0.custnr, t3.oid, t3.jpatype, t3.`_version`,
>> t3.addresstype,
>>>> t3.city, t3.company, t3.country, t3.department, t3.email, t3.firstname,
>>>> t3.gender, t3.lastname, t3.middlename, t3.phone, t3.zip,
>> t3.postofficebox,
>>>> t3.street, t3.housenr, t3.title, t3.deliverymode, t0.greenoption,
>>>> t0.ordernr, t4.oid, t4.jpatype, t4.`_version`, t4.addresstype, t4.city,
>>>> t4.company, t4.country, t4.department, t4.email, t4.firstname,
>> t4.gender,
>>>> t4.lastn

Re: same jpa query generates different SQLs

[Marc Logemann]

Hi Jeremy,

thanks for your instant feedback. I directly tried your suggestion and now it 
works. So there is a bug in the cache implementation with regard to Type 
Mappings. 
And its not a DB2 thingy because i am using MySQL ;-)

if you need more infos in the error case, i am willing to help if you want 
I would like to see this solved because disabling the cache means decreasing 
the performance somehow right?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 02.03.2011 um 17:31 schrieb Jeremy Bauer:

> Hi Marc,
> 
> I'm wondering if this isn't caused by an inconsistent parameter type mapping
> as a result of using the QuerySQLCache. I saw a similar issue a few weeks
> ago, but it was oddly specific to DB2 on zOS. Please try:
> 
> 
> 
> -Jeremy
> 
> On Wed, Mar 2, 2011 at 9:43 AM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> i am totally astonished:
>> 
>> I am using this query:
>> 
>>   public List findByDate(Date date) {
>> 
>>   TypedQuery query = getEntityManager().
>>   createQuery("select o FROM Order o where o.createdYmd = ?1
>> order by o.id", Order.class);
>> 
>>   query.setParameter(1, date, TemporalType.DATE);
>>   return query.getResultList();
>>   }
>> 
>> This query is called by a service class which is scheduled ever 30 seconds.
>> See the caller:
>> 
>>   // get yesterdays Date
>>   Date today = new Date();
>>   Calendar calendar = Calendar.getInstance();
>>   calendar.setTime(today);
>>   calendar.add(Calendar.DATE, -1);
>>   Date yesterday = calendar.getTime();
>> 
>>   List list = orderDao.findByDate(yesterday);
>> 
>> 
>> Now, on the second run, the query parameter is of type timestamp with full
>> time specified, giving me 0 records of course. First query returns records
>> because there TemporalType seems to work. See log.
>> 
>> FIRST RUN ->
>> 
>> [DEBUG myScheduler-3 16:36:30] |  executing
>> prepstmnt 1488869003 SELECT t0.oid, t0.`_version`, t1.oid, t1.`_version`,
>> t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
>> t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
>> t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype,
>> t2.printed, t2.printedby, t2.totalprice, t1.boxtype, t0.created,
>> t0.createdymd, t0.custnr, t3.oid, t3.jpatype, t3.`_version`, t3.addresstype,
>> t3.city, t3.company, t3.country, t3.department, t3.email, t3.firstname,
>> t3.gender, t3.lastname, t3.middlename, t3.phone, t3.zip, t3.postofficebox,
>> t3.street, t3.housenr, t3.title, t3.deliverymode, t0.greenoption,
>> t0.ordernr, t4.oid, t4.jpatype, t4.`_version`, t4.addresstype, t4.city,
>> t4.company, t4.country, t4.department, t4.email, t4.firstname, t4.gender,
>> t4.lastname, t4.middlename, t4.phone, t4.zip, t4.postofficebox, t4.street,
>> t4.housenr, t4.title, t4.deliverymode, t4.order_oid, t0.iscardowner,
>> t0.cost, t0.currency, t0.pricing, t0.paymenttype, t0.printed, t0.printedby,
>> t0.totalprice FROM orders t0 LEFT OUTER JOIN boxes t1 ON t0.box_oid = t1.oid
>> LEFT OUTER JOIN address t3 ON t0.oid = t3.order_oid LEFT OUTER JOIN address
>> t4 ON t0.invaddress_oid = t4.oid LEFT OUTER JOIN orders t2 ON t1.oid =
>> t2.box_oid WHERE (t0.createdymd = ?) AND (t3.jpatype IS NULL OR t3.jpatype
>> IN (?)) ORDER BY t0.ordernr ASC [params=(Date) 2011-03-01, (int) 2]
>> 
>> SECOND RUN ->
>> 
>> [DEBUG myScheduler-2 16:37:00] |  executing
>> prepstmnt 154018541 SELECT t0.oid, t0.`_version`, t1.oid, t1.`_version`,
>> t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
>> t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
>> t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype,
>> t2.printed, t2.printedby, t2.totalprice, t1.boxtype, t0.created,
>> t0.createdymd, t0.custnr, t3.oid, t3.jpatype, t3.`_version`, t3.addresstype,
>> t3.city, t3.company, t3.country, t3.department, t3.email, t3.firstname,
>> t3.gender, t3.lastname, t3.middlename, t3.phone, t3.zip, t3.postofficebox,
>> t3.street, t3.housenr, t3.title, t3.deliverymode, t0.greenoption,
>> t0.ordernr, t4.oid, t4.jpatype, t4.`_version`, t4.addresstype, t4.city,
>> t4.company, t4.country, t4.department, t4.email, t4.firstname, t4.gender,
>> t4.lastname, t4.middlename, t4.phone, t4.zip, t4.postofficebox, t4.street,
>> t4.housenr, t4.title, t4.deliverymode, t4.order_oid, t0.iscardowner,
>> t0.cost, t0.currency, t0.pricing, t0.paymenttype, t0.printed, t0.printedby,
>> t0.totalprice FROM

same jpa query generates different SQLs

[Marc Logemann]

Hi,

i am totally astonished:

I am using this query:

public List findByDate(Date date) {

TypedQuery query = getEntityManager().
createQuery("select o FROM Order o where o.createdYmd = ?1 
order by o.id", Order.class);

query.setParameter(1, date, TemporalType.DATE);
return query.getResultList();
}

This query is called by a service class which is scheduled ever 30 seconds. See 
the caller:

// get yesterdays Date
Date today = new Date();
Calendar calendar = Calendar.getInstance();
calendar.setTime(today);
calendar.add(Calendar.DATE, -1);
Date yesterday = calendar.getTime();

List list = orderDao.findByDate(yesterday);


Now, on the second run, the query parameter is of type timestamp with full time 
specified, giving me 0 records of course. First query returns records because 
there TemporalType seems to work. See log.

FIRST RUN ->

[DEBUG myScheduler-3 16:36:30] |  executing 
prepstmnt 1488869003 SELECT t0.oid, t0.`_version`, t1.oid, t1.`_version`, 
t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created, 
t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid, 
t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype, t2.printed, 
t2.printedby, t2.totalprice, t1.boxtype, t0.created, t0.createdymd, t0.custnr, 
t3.oid, t3.jpatype, t3.`_version`, t3.addresstype, t3.city, t3.company, 
t3.country, t3.department, t3.email, t3.firstname, t3.gender, t3.lastname, 
t3.middlename, t3.phone, t3.zip, t3.postofficebox, t3.street, t3.housenr, 
t3.title, t3.deliverymode, t0.greenoption, t0.ordernr, t4.oid, t4.jpatype, 
t4.`_version`, t4.addresstype, t4.city, t4.company, t4.country, t4.department, 
t4.email, t4.firstname, t4.gender, t4.lastname, t4.middlename, t4.phone, 
t4.zip, t4.postofficebox, t4.street, t4.housenr, t4.title, t4.deliverymode, 
t4.order_oid, t0.iscardowner, t0.cost, t0.currency, t0.pricing, t0.paymenttype, 
t0.printed, t0.printedby, t0.totalprice FROM orders t0 LEFT OUTER JOIN boxes t1 
ON t0.box_oid = t1.oid LEFT OUTER JOIN address t3 ON t0.oid = t3.order_oid LEFT 
OUTER JOIN address t4 ON t0.invaddress_oid = t4.oid LEFT OUTER JOIN orders t2 
ON t1.oid = t2.box_oid WHERE (t0.createdymd = ?) AND (t3.jpatype IS NULL OR 
t3.jpatype IN (?)) ORDER BY t0.ordernr ASC [params=(Date) 2011-03-01, (int) 2]

SECOND RUN ->

[DEBUG myScheduler-2 16:37:00] |  executing 
prepstmnt 154018541 SELECT t0.oid, t0.`_version`, t1.oid, t1.`_version`, 
t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created, 
t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid, 
t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype, t2.printed, 
t2.printedby, t2.totalprice, t1.boxtype, t0.created, t0.createdymd, t0.custnr, 
t3.oid, t3.jpatype, t3.`_version`, t3.addresstype, t3.city, t3.company, 
t3.country, t3.department, t3.email, t3.firstname, t3.gender, t3.lastname, 
t3.middlename, t3.phone, t3.zip, t3.postofficebox, t3.street, t3.housenr, 
t3.title, t3.deliverymode, t0.greenoption, t0.ordernr, t4.oid, t4.jpatype, 
t4.`_version`, t4.addresstype, t4.city, t4.company, t4.country, t4.department, 
t4.email, t4.firstname, t4.gender, t4.lastname, t4.middlename, t4.phone, 
t4.zip, t4.postofficebox, t4.street, t4.housenr, t4.title, t4.deliverymode, 
t4.order_oid, t0.iscardowner, t0.cost, t0.currency, t0.pricing, t0.paymenttype, 
t0.printed, t0.printedby, t0.totalprice FROM orders t0 LEFT OUTER JOIN boxes t1 
ON t0.box_oid = t1.oid LEFT OUTER JOIN address t3 ON t0.oid = t3.order_oid LEFT 
OUTER JOIN address t4 ON t0.invaddress_oid = t4.oid LEFT OUTER JOIN orders t2 
ON t1.oid = t2.box_oid WHERE (t0.createdymd = ?) AND (t3.jpatype IS NULL OR 
t3.jpatype IN (?)) ORDER BY t0.ordernr ASC [params=(Timestamp) 2011-03-01 
16:37:00.001, (int) 2]

I have completely no clue what to do now ;-) Thanks for input.



---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: missing openjpa-src.jar

[Marc Logemann]

Hi,

always thought it behaves the same except for some maven specific plugin 
specifications inside POM. Anyway. Will fiddle around with all that. 
For now it works and my setup is a little bit cleaner/lighter than using 
.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 01.03.2011 um 19:00 schrieb Michael Dick:

> Just read up (a little) on ivy. My comments about openjpa-persistence-jdbc
> were assuming it would pull the same dependencies as maven - which might not
> be the case.
> 
> This:   conf="default->default,sources,javadoc"/> should still work though.
> 
> -mike
> 
> On Tue, Mar 1, 2011 at 11:37 AM, Michael Dick wrote:
> 
>> Off the top of my head you should only need openjpa-persistence-jdbc to get
>> 'most' of the JPA function. That should pull in lib,kernel,jdbc, and
>> persistence as dependencies for you.
>> 
>> Or just
>> > conf="default->default,sources,javadoc"/>
>> 
>> Which will probably grab everything (should be smaller than apache-openjpa
>> though).
>> 
>> -mike
>> 
>> 
>> On Tue, Mar 1, 2011 at 10:03 AM, Marc Logemann  wrote:
>> 
>>> Yeah. You have this dependency page when it comes to plain old jars,
>>> manually managed, but with Maven, one needs advice what kind of artifacts
>>> one needs for what kind of situation:
>>> 
>>> I stopped using this dep:
>>> 
>>> >> conf="default->default,sources,javadoc"/>
>>> 
>>> (there i had no sources and a lot of stuff was downloaded)
>>> 
>>> Now i use:
>>> 
>>>  >> rev="2.1.0" conf="default->default,sources,javadoc"/>
>>>  >> rev="2.1.0" conf="default->default,sources,javadoc"/>
>>>  >> conf="default->default,sources,javadoc"/>
>>>  >> rev="2.1.0" conf="default->default,sources,javadoc"/>
>>>  >> name="openjpa-persistence-jdbc" rev="2.1.0"
>>> conf="default->default,sources,javadoc"/>
>>>  >> name="geronimo-jpa_2.0_spec" rev="1.1"/>
>>> 
>>> But i perhaps one or two lines are useless. I would like to see a page
>>> where these different dependencies are explained. There are some more where
>>> i guessed from the name that they are not cruical.
>>> 
>>> 
>>> ---
>>> regards
>>> Marc Logemann
>>> http://www.logemann.org
>>> http://www.logentis.de
>>> 
>>> 
>>> 
>>> 
>>> Am 01.03.2011 um 16:32 schrieb Kevin Sutter:
>>> 
>>>> We do have this page that describes the various openjpa dependencies and
>>> how
>>>> they are packaged (or not) with the openjpa distributions:
>>>> 
>>>> http://openjpa.apache.org/build-and-runtime-dependencies.html
>>>> 
>>>> But, the maven dependency information seems to be "missing"...  Adding
>>> it to
>>>> this page seems like the logical location...
>>>> 
>>>> Kevin
>>>> 
>>>> On Tue, Mar 1, 2011 at 9:19 AM, Michael Dick >>> wrote:
>>>> 
>>>>> At one time there was a wiki page with this information (I think), but
>>> I
>>>>> can't find right now.
>>>>> 
>>>>> I did find an old mailing list post that might be a good starting
>>>>> point<http://markmail.org/message/j3nzhnn6pg7uwnk3>.
>>>>> 
>>>>> 
>>>>> Let us know if this is what you need and we'll see if we can get an up
>>> to
>>>>> date version added to the website.
>>>>> 
>>>>> -mike
>>>>> 
>>>>> On Mon, Feb 28, 2011 at 7:37 PM, Marc Logemann 
>>> wrote:
>>>>> 
>>>>>> Ah sorry. Used the wrong maven dependency in my ivy setup. But still
>>>>>> wondering where i can find a documention about the various parts of
>>>>> openjpa
>>>>>> you can get via Maven and its meanings. Right now i am in trial and
>>> error
>>>>>> mode which of them i really need
>>>>>> 
>>>>>> ---
>>>>>> regards
>>>>>> Marc Logemann
>>>>>> http://www.logemann.org
>>>>>> http://www.logentis.de
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Am 01.03.2011 um 02:15 schrieb Marc Logemann:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> i am really missing a src jar. And while i am thinking about it. it
>>>>> would
>>>>>> be nice if this would be shipped on request via Maven Reps as well.
>>>>>>> 
>>>>>>> ---
>>>>>>> regards
>>>>>>> Marc Logemann
>>>>>>> http://www.logemann.org
>>>>>>> http://www.logentis.de
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>> 

Re: missing openjpa-src.jar

[Marc Logemann]

Yeah. You have this dependency page when it comes to plain old jars, manually 
managed, but with Maven, one needs advice what kind of artifacts one needs for 
what kind of situation:

I stopped using this dep:

  

(there i had no sources and a lot of stuff was downloaded)

Now i use:








But i perhaps one or two lines are useless. I would like to see a page where 
these different dependencies are explained. There are some more where i guessed 
from the name that they are not cruical.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 01.03.2011 um 16:32 schrieb Kevin Sutter:

> We do have this page that describes the various openjpa dependencies and how
> they are packaged (or not) with the openjpa distributions:
> 
> http://openjpa.apache.org/build-and-runtime-dependencies.html
> 
> But, the maven dependency information seems to be "missing"...  Adding it to
> this page seems like the logical location...
> 
> Kevin
> 
> On Tue, Mar 1, 2011 at 9:19 AM, Michael Dick wrote:
> 
>> At one time there was a wiki page with this information (I think), but I
>> can't find right now.
>> 
>> I did find an old mailing list post that might be a good starting
>> point<http://markmail.org/message/j3nzhnn6pg7uwnk3>.
>> 
>> 
>> Let us know if this is what you need and we'll see if we can get an up to
>> date version added to the website.
>> 
>> -mike
>> 
>> On Mon, Feb 28, 2011 at 7:37 PM, Marc Logemann  wrote:
>> 
>>> Ah sorry. Used the wrong maven dependency in my ivy setup. But still
>>> wondering where i can find a documention about the various parts of
>> openjpa
>>> you can get via Maven and its meanings. Right now i am in trial and error
>>> mode which of them i really need
>>> 
>>> ---
>>> regards
>>> Marc Logemann
>>> http://www.logemann.org
>>> http://www.logentis.de
>>> 
>>> 
>>> 
>>> 
>>> Am 01.03.2011 um 02:15 schrieb Marc Logemann:
>>> 
>>>> Hi,
>>>> 
>>>> i am really missing a src jar. And while i am thinking about it. it
>> would
>>> be nice if this would be shipped on request via Maven Reps as well.
>>>> 
>>>> ---
>>>> regards
>>>> Marc Logemann
>>>> http://www.logemann.org
>>>> http://www.logentis.de
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 

Re: missing openjpa-src.jar

[Marc Logemann]

Ah sorry. Used the wrong maven dependency in my ivy setup. But still wondering 
where i can find a documention about the various parts of openjpa you can get 
via Maven and its meanings. Right now i am in trial and error mode which of 
them i really need

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 01.03.2011 um 02:15 schrieb Marc Logemann:

> Hi,
> 
> i am really missing a src jar. And while i am thinking about it. it would be 
> nice if this would be shipped on request via Maven Reps as well.
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 

missing openjpa-src.jar

[Marc Logemann]

Hi,

i am really missing a src jar. And while i am thinking about it. it would be 
nice if this would be shipped on request via Maven Reps as well.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

"join fetch" doesnt work as expected

[Marc Logemann]

Hi,

assume this code:

Query query = getEntityManager().createQuery("SELECT b FROM Box b JOIN 
FETCH b.order.orderPositions WHERE b.id = ?1");
query.setParameter(1, boxId);
List boxList = query.getResultList();

The relationship is:

box  <-- 1:1 ---> order <-- 1:n --> orderPositions

When doing this query, i would expect that the orderPositions are attached but 
they are null (order is attached to the box as expected but thats 1:1) . I 
checked this right after the query.getResultList() call.
What am i missing here?

thanks for infos.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: CURRENT_DATE and OpenJPA 2

[Marc Logemann]

Thx for the property hint. Should i file a bug because of CURRENT_DATE ? Cant 
think that this doesnt work because this would be quite a killer bug right? :-)

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 23.09.2010 um 15:34 schrieb Michael Dick:

> Hi Marc,
> 
> I'm not familiar with the current_date function but what you're saying
> sounds right.
> 
> To answer your minor question on parameter logging, you need to add the
> following property to persistence.xml :
>  value="PrintParameters=true"/>.
> 
> It's a change from previous versions, due to concerns about logging
> sensitive data, there's some content in the infocenter at
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_logging_channels,
> but it's still easy to miss if you're used to the old behavior.
> 
> Regards,
> -mike
> 
> On Thu, Sep 23, 2010 at 4:33 AM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> The following query:
>> 
>> Query query = em.createQuery("select count(d) from Order o,
>> IN(o.deliveryAddress) d " +
>>   "where o.createdYmd = CURRENT_DATE and d.deliveryMode =
>> ?1");
>> 
>> generates the following SQL:
>> 
>> SELECT COUNT(t1.oid) FROM orders t0 INNER JOIN address t1 ON t0.oid =
>> t1.order_oid WHERE (t0.createdymd IS NULL AND t1.deliverymode = ?)
>> [params=?]
>> 
>> Why the where part with "IS NULL" ? Current_date should be applied there
>> shouldnt it?
>> 
>> One minor question: What can i do that OpenJPA logs the params real values
>> instead of "?"   ?
>> 
>> Thanks
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> 

CURRENT_DATE and OpenJPA 2

[Marc Logemann]

Hi,

The following query:

Query query = em.createQuery("select count(d) from Order o, 
IN(o.deliveryAddress) d " +
"where o.createdYmd = CURRENT_DATE and d.deliveryMode = ?1");

generates the following SQL:

SELECT COUNT(t1.oid) FROM orders t0 INNER JOIN address t1 ON t0.oid = 
t1.order_oid WHERE (t0.createdymd IS NULL AND t1.deliverymode = ?) [params=?]

Why the where part with "IS NULL" ? Current_date should be applied there 
shouldnt it?

One minor question: What can i do that OpenJPA logs the params real values 
instead of "?"   ?

Thanks

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: OpenJPA 1.2.x - weird inverse 1:n problem

[Marc Logemann]

Hi,

trying to narrow it down myself and asking if i am right: Can it be that i need 
to manually manage the inverse relationship before persist?

This would mean that i need to do something like that before persisting:

for(DeliveryAddress dAddress : order.getDeliveryAddresses()) {
dAddress.setOrder(order);
}

Looks weird because i thought the provider can do this magic for me :-)

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 16.09.2010 um 15:43 schrieb Marc Logemann:

> Hi,
> 
> i am getting crazy. Hope someone can point me to the right spot. Suppose the 
> following tables:
> 
> DB-Table: orders
> 
> oid int
> ...
> 
> 
> DB-Table: Adress
> --
> oid int
> order_oid
> 
> 
> 
> Now my classes:
> 
> @Entity
> @Table(name = "orders")
> public class Order {
>@Id
>@GeneratedValue(strategy = GenerationType.IDENTITY)
>@Column(name = "oid")
>int oid;
> 
>@OneToMany(mappedBy = "order", fetch = FetchType.EAGER, cascade = 
> CascadeType.ALL)
>List deliveryAddresses;
>
> })
> 
> @Entity
> public class DeliveryAddress extends Address {
>  (Id and Table annotation from superclass. Id field is also "oid")
> 
>@ManyToOne(cascade = CascadeType.ALL)
>@JoinColumn(name="order_oid", referencedColumnName="oid")
>Order order;
> }
> 
> 
> Now when i persist my order table, everything is fine but the foreign key 
> "order_oid" inside the address table is null. Same goes on for other mappings 
> as well. Whats the problem here?
> 
> Thanks.
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 

OpenJPA 1.2.x - weird inverse 1:n problem

[Marc Logemann]

Hi,

i am getting crazy. Hope someone can point me to the right spot. Suppose the 
following tables:

DB-Table: orders

oid int
...


DB-Table: Adress
--
oid int
order_oid



Now my classes:

@Entity
@Table(name = "orders")
public class Order {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "oid")
int oid;

@OneToMany(mappedBy = "order", fetch = FetchType.EAGER, cascade = 
CascadeType.ALL)
List deliveryAddresses;

})

@Entity
public class DeliveryAddress extends Address {
  (Id and Table annotation from superclass. Id field is also "oid")

@ManyToOne(cascade = CascadeType.ALL)
@JoinColumn(name="order_oid", referencedColumnName="oid")
Order order;
}


Now when i persist my order table, everything is fine but the foreign key 
"order_oid" inside the address table is null. Same goes on for other mappings 
as well. Whats the problem here?

Thanks.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: entities not detected properly in JUnit Test case (OpenJPA 1.2.2)

[Marc Logemann]

Hi,

thanks for this pretty straight answer. But one more thing that bothers me. Why 
is this only an issue while testing? When my app is running, i am pretty sure 
that i dont use the DP_PLZ_DA class somewhere in the code before the worfklow 
with the query arrives. So why does it work in normal runtime mode?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 06.09.2010 um 23:26 schrieb Rick Curtis:

>> So why does OpenJPA fail on registering Entities?
> 
> The problem is that when you don't list your entities, OpenJPA doesn't know
> that the alias 'DP_PLZ_DA' is an Entity until the x.y.z.DP_PLZ_DA class is
> loaded. If you were to look at an enhanced Entity you would see that OpenJPA
> adds a static initializer that will register each Entity with OpenJPA.
> 
> An alternative to calling "new DP_PLZ_DA();" would be to add something like
> this to each of your testcases.
> 
> // List each Entity that this test is going to use.
> private Class[] _entities = new
> Class[]{x.y.z.DP_PLZ_DA.class,x.y.z.DP_PLZ_DB.class,etc... };
> 
> Thanks,
> Rick
> 
> On Mon, Sep 6, 2010 at 4:14 PM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> i am using a pretty straightforward Spring/OpenJPA JUnit Testcase scenario:
>> 
>> @RunWith(SpringJUnit4ClassRunner.class)
>> @ContextConfiguration(locations = "/appContext.xml")
>> public class DHLLeitcodeCreatorTest {
>>  ...
>>  @Test
>>   public void getDHLLeitcode() {
>>   someBean.superDuperAction();
>>  }
>> }
>> 
>> I am not explicitely declaring my entities in persistence.xml. Its all
>> autodetected via Annotations. (at least during normal runtime).
>> 
>> Inside superDuperAction(), a lot of queries are fired against OpenJPA. It
>> fails on the first Query saying that it cant find Entity DP_PLZ_DA (weird
>> class name, i know).
>> 
>> "Error message: The name "DP_PLZ_DA" is not a recognized entity or "
>> 
>> Now when i do this:
>> 
>>  @Test
>>   public void getDHLLeitcode() {
>>  DP_PLZ_DA df = new DP_PLZ_DA();
>>  someBean.superDuperAction();
>>  }
>> 
>> It works and it can find the Entity. But why in gods name do i need to
>> instantiate the class by myself in order to get detected? During normal
>> runtime, this is no problem. Kevin Sutter reported something similar here (
>> http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14459507)
>> but i thought i can solve this by upgrading to 1.2.2 but i was mistaken.
>> 
>> So why does OpenJPA fail on registering Entities?
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> 

entities not detected properly in JUnit Test case (OpenJPA 1.2.2)

[Marc Logemann]

Hi,

i am using a pretty straightforward Spring/OpenJPA JUnit Testcase scenario:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = "/appContext.xml")
public class DHLLeitcodeCreatorTest {
   ...
   @Test
public void getDHLLeitcode() {
someBean.superDuperAction();
   }
}

I am not explicitely declaring my entities in persistence.xml. Its all 
autodetected via Annotations. (at least during normal runtime). 

Inside superDuperAction(), a lot of queries are fired against OpenJPA. It fails 
on the first Query saying that it cant find Entity DP_PLZ_DA (weird class name, 
i know). 

"Error message: The name "DP_PLZ_DA" is not a recognized entity or "

Now when i do this:

   @Test
public void getDHLLeitcode() {
   DP_PLZ_DA df = new DP_PLZ_DA(); 
   someBean.superDuperAction();
   }

It works and it can find the Entity. But why in gods name do i need to 
instantiate the class by myself in order to get detected? During normal 
runtime, this is no problem. Kevin Sutter reported something similar here 
(http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14459507) but i 
thought i can solve this by upgrading to 1.2.2 but i was mistaken.

So why does OpenJPA fail on registering Entities?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

re-attach entity and then persisting doesnt work

[Marc Logemann]

Hi,

with latest stable OpenJPA i have a problem which might be there because of 
misunderstanding on my side.

For instance take these PC class:

Class A {
public int oid;
public String name;
public B classB;
}

Class B {
public int oid;
public String name;
}


Now my appCode:
--

A classA = new A();
a.setName("foo");

B classB = someDao.findClassB();
classA.setB(classB); // classB is detached for this example

em.persist(classA);


=

When i do this, i am getting the exception that i cant persist a detached class 
(classB). This is okay and i am aware of that. Now i tried to attach "B" to the 
context before persisting via:

em.merge(classB);

Really interessting is that after the merge, the call to 
OpenJPAEntityManager.isDetached() still returns TRUE. Consequently i still cant 
persist "A". 

So my overall problem is that i cant persist a new Entity when this new entity 
has a detached object inside the graph because i cant bring the detached object 
back into the current context.

Thanks for hints.




---
regards
Marc

marked for Rollback only problem

[Marc Logemann]

dInvocation.proceed(ReflectiveMethodInvocation.java:149)
 at 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
 ... 34 more

-- 
Marc Logemann - LOGENTIS GmbH
geschäftsführender Gesellschafter
Westerbreite 7 - 49084 Osnabrück
Tel. +49 (0)541 - 80049791
Fax  +49 (0)541 - 9778172
Mob. +49 (0)177 - 8220182
http://www.logentis.de
m...@logentis.de

*** Enterprise Versandlogistik: http://www.netversys.de

Sitz der Gesellschaft: Osnabrück | Geschäftsführer: Marc Logemann | 
Handelsregisternummer: Amtsgericht Osnabrück, HRB 201057 | UstIdNr: DE 814858920

Re: slow Query (but not the SQL itself) (OpenJPA 1.2.x)

[Marc Logemann]

Hi,

i found out that some one-to-one relations in the Superclass added some heavy 
performance penalties. I ve not seen it in the SQL logs though. Perhaps i 
missed it.
Cant comment on the detachment. It seems that its not the problem at all in my 
case.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 03.12.2009 um 14:53 schrieb Rick Curtis:

> Marc -
> 
> In the case where you call em.find(...) and it takes 500ms how long does
> that operation take if the result doesn't need to be detached? The reason I
> ask is that I've been doing some performance work and we found that in some
> instances we are spending way too much time detaching Entities.
> 
> -- 
> Thanks,
> Rick
> 
> On Thu, Dec 3, 2009 at 6:06 AM, Marc Logemann  wrote:
> 
>> Hi,
>> 
>> i am facing some weird performance issues. Given this  JPA Query:
>> 
>> public class SomeDao {
>>   @SuppressWarnings("unchecked")
>>   public Object getMetaData(Foo.class, long oid) {
>>   Object o = em.find(clazz, client);
>>   return o;
>>   }
>> ..
>> }
>> 
>> 
>> @Entity
>> @VersionColumn(name = "jpaversion")
>> @Table(name = "foo")
>> public class Foo extends BasicClientMetaData {
>> 
>>   @Id
>>   @Column(name = "client_oid")
>>   private long client;
>> ...
>> }
>> 
>> @MappedSuperclass
>> public class BasicClientMetaData implements MinMaxWeightAware {
>> 
>> 
>>   @Column(name = "custnr")
>>   private String customerNumber;
>> 
>>   @Column(name = "maxweight")
>>   private float maxWeightStandard;
>> ..
>> }
>> 
>> When i call the getMetaData() of SomeDao.class (which is transactional and
>> gets detached when its returned to the caller), i measured 500ms for this
>> operation. The underlying SQL only consumes 20ms which i checked by setting
>> the SQL log level to TRACE.
>> 
>> Why is there such a difference? I mean, detaching cant be such an issue
>> from performance perspective. I only have this issue with exactly these kind
>> of classes (children of BasicClientMetaData).
>> 
>> But i also have other classes which have the @MappedSuperclass which work
>> without performance problems. Does anyone have a hint where i can look out
>> for?
>> 
>> 
>> thanks.
>> 
>> ---
>> regards
>> Marc Logemann
>> http://www.logemann.org
>> http://www.logentis.de
>> 
>> 
>> 
>> 
>> 

Re: slow Query (but not the SQL itself) (OpenJPA 1.2.x)

[Marc Logemann]

small correction :


public class SomeDao {
   @SuppressWarnings("unchecked")
   public Object getMetaData(Class clazz, long oid) {
   Object o = em.find(clazz, oid);
   return o;
   }
..
}


CALLER: 

Object o = someDao.getMetaData(Foo.class, 1);

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 03.12.2009 um 13:06 schrieb Marc Logemann:

> Hi,
> 
> i am facing some weird performance issues. Given this  JPA Query:
> 
> public class SomeDao {
>@SuppressWarnings("unchecked")
>public Object getMetaData(Foo.class, long oid) {
>Object o = em.find(clazz, client);
>return o;
>}
> ..
> }
> 
> 
> @Entity
> @VersionColumn(name = "jpaversion")
> @Table(name = "foo")
> public class Foo extends BasicClientMetaData {
> 
>@Id
>@Column(name = "client_oid")
>private long client;
> ...
> }
> 
> @MappedSuperclass
> public class BasicClientMetaData implements MinMaxWeightAware {
> 
> 
>@Column(name = "custnr")
>private String customerNumber;
> 
>@Column(name = "maxweight")
>private float maxWeightStandard;
> ..
> }
> 
> When i call the getMetaData() of SomeDao.class (which is transactional and 
> gets detached when its returned to the caller), i measured 500ms for this 
> operation. The underlying SQL only consumes 20ms which i checked by setting 
> the SQL log level to TRACE.
> 
> Why is there such a difference? I mean, detaching cant be such an issue from 
> performance perspective. I only have this issue with exactly these kind of 
> classes (children of BasicClientMetaData).
> 
> But i also have other classes which have the @MappedSuperclass which work 
> without performance problems. Does anyone have a hint where i can look out 
> for?
> 
> 
> thanks.
> 
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
> 
> 
> 
> 

slow Query (but not the SQL itself) (OpenJPA 1.2.x)

[Marc Logemann]

Hi,

i am facing some weird performance issues. Given this  JPA Query:

public class SomeDao {
@SuppressWarnings("unchecked")
public Object getMetaData(Foo.class, long oid) {
Object o = em.find(clazz, client);
return o;
}
..
}


@Entity
@VersionColumn(name = "jpaversion")
@Table(name = "foo")
public class Foo extends BasicClientMetaData {

@Id
@Column(name = "client_oid")
private long client;
...
}

@MappedSuperclass
public class BasicClientMetaData implements MinMaxWeightAware {


@Column(name = "custnr")
private String customerNumber;

@Column(name = "maxweight")
private float maxWeightStandard;
..
}

When i call the getMetaData() of SomeDao.class (which is transactional and gets 
detached when its returned to the caller), i measured 500ms for this operation. 
The underlying SQL only consumes 20ms which i checked by setting the SQL log 
level to TRACE.

Why is there such a difference? I mean, detaching cant be such an issue from 
performance perspective. I only have this issue with exactly these kind of 
classes (children of BasicClientMetaData).

But i also have other classes which have the @MappedSuperclass which work 
without performance problems. Does anyone have a hint where i can look out for?


thanks.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: inverse OneToMany relation - getting weird

[Marc Logemann]

cant answer your question because i am not that deep into the whole  
JPA topic (from an internal dev standpoint) but i will try the  
InverseManger with my test classes to see what happens.

I will report back

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de



Would be interessting to know if this keeps being this way in  
Version 2.
But on the other hand, it wont kill you to set the backref, you  
just have to
know it in the first place. And now i finally created test classes  
for all
that mapping stuff so that i can fiddle around with various  
mappings in a

short timeframe w/o boostrapping my J2EE app.



It isn't changed in the JPA 2.0 spec (which is nearly finalized). We  
could
change the default for OpenJPA though (basically turn on  
InverseManager
automatically). I'd have to think about that a bit (it makes me  
nervous
messing with the contents of a user's POJO without explicitly being  
told to

do so).

What do other people think?

-

Re: Detached entities, version attribute and optimistic concurrency control

[Marc Logemann]

Hi,

i dont get why you manually want to modify the JPAVERSION attribute.

If you dont want to keep the detached object in the session (thats  
what we do), you
must at least remember the OID (object id) of the Document, find it  
again from the

persistenceManager and then do the changes on the object and
persist/merge again.

Manually setting the version attribute makes no sense at all because  
you really want the
ORM layer to manage the version attribute and only he knows best when  
someone

modified your data and throws an OptimisticException when this happened.

Regarding the bloated HTTPSession. We just speak of a CRUD based  
application where
you are just on the way modifying a record dont you? How big can the  
object model
for that specific GUI can be? After that you can easily remove the  
detached entities

from the session.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 14.11.2009 um 09:38 schrieb Nikhil Patwardhan:



Hi,

I'm new to OpenJPA and I have been trying to create a small prototype
demonstrating how I can use it as a JPA compliant persistence  
provider in a

J2EE web applications. In one of my use cases, I do the following:

1) Look up an entity(Class name:Document, for instance) using em.find 
() in

the service layer. The entity has a version field.

2) Detach the entity by closing the em.

3) Pass the detached entity to the presentation layer (a JSP) which  
shows a
screen to update various fields of the entity. The UI also has a  
field for

the version attribute which is sent back on submit.

4) Submit the data back, create a new Document object, set the  
fields and

call em.merge(document) inside a transaction.

This code fails in step 4 with the following exception when I try to  
set the

version attribute on the Document object before calling merge().
---
org.apache.openjpa.persistence.InvalidStateException: Detected  
attempt to

modify field "core.persistence.Document.docVer" with value strategy
"restrict".

Am I missing something here? My approach here is to set the version
attribute obtained from the UI on the entity to be merged so that  
optimistic

concurrency control would come into play to find out
if the entity has been updated since the last read. If version  
attribute

cannot be set on an entity, I might have to keep the detached entity
obtained from find() in HttpSession and then use it when the updated  
data is
submitted. But I'm wondering if keeping entities in session is a  
good idea,

as it can make the session bloated with entities.

--
View this message in context: 
http://n2.nabble.com/Detached-entities-version-attribute-and-optimistic-concurrency-control-tp4003522p4003522.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: inverse OneToMany relation - getting weird

[Marc Logemann]

Hi,

thanks for your infos on that. I will stick with setting the backrefs  
manually as you did it and keep chosing the @ManyToOne on the child.  
What strikes me even more is that you can just do that:


public class Team {

...

@OneToMany(cascade = CascadeType.PERSIST, mappedBy = "team")
public List players;
}

public class Player {



@ManyToOne
public Team team;

}


So no ElementJoinColumn or JoinColumn as i would need to if using  
unidirectional links from parent to child. Makes kind of sense because  
now mapping the parent in the child class, i dont need to tell him  
where the FK thingy is. Now its just a direct mapping and the defaults  
are ok to map to the FK field "team_oid" in the Player Table.


To me the documentation is lacking heavily in exactly this spot.  
Because it turns out that the bidirectional mapping of a child-FK- 
Mapping is completely different as the unidirectional one because then  
we would need all that ElementJoinColumn magic. Took me one day to  
figure this out and you helped me in getting the facts straight that  
the ORM layer is not that smart as i believed. For me, OpenJPA could  
easily figure the backrefs for itself, at least it looks as it could  
do so.


Would be interessting to know if this keeps being this way in Version  
2. But on the other hand, it wont kill you to set the backref, you  
just have to know it in the first place. And now i finally created  
test classes for all that mapping stuff so that i can fiddle around  
with various mappings in a short timeframe w/o boostrapping my J2EE app.


Again, thanks a lot for your help.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 13.11.2009 um 19:09 schrieb Michael Dick:


Hi Marc,

The example I sent was something I hacked together to populate a  
database
using your model. Basically it creates 3 Fathers with 2 children for  
each of

them. Hopefully that didn't distract you too much.

The real issue is setting the backrefs. In JPA the application must  
maintain
both sides of a bi-directional relationship (on your Java objects).  
There's

some wording in the spec to this effect which I can drag up if you're
interested.

The other thing that might be worth noting is that when you add
mappedBy="something" JPA will consider the Many side (in your case  
Child, or
Player) the _owner_ of the relationship. Using the @Embedded  
annotations may

reverse the owners - but you need to remove the mappedBy attribute of
@OneToMany. It's the owner of the relationship which matters "most".

So for general JPA use I definitely recommend setting both sides of  
the

relationship to make sure they get persisted properly.

That said, OpenJPA does provide a mechanism to manage the inverse  
side of

relationships for you. You can read about it in the users guide here :
http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/manual.html#ref_guide_inverses 
.

It sounds like it's exactly what you're looking for.

Hope this helps.  If you have other questions keep posting.

-mike

On Fri, Nov 13, 2009 at 11:39 AM, Marc Logemann   
wrote:



Hi,

for the records, i am using 1.2.0.

To your question: i am only doing that (sorry, i changed my example  
to be

Team->Player, instead of Father->Child) :

  Player p = new Player();
  p.setName("Huiboo");
  List list = new ArrayList();
  list.add(p);

  Team t = new Team();
  t.setName("VfL");
  t.setPlayers(list);
  em.persist(t);

So yes, i am only setting the child references in the list and i dont
manually set the backreference. To be honest,  i dont understand your
example too well. I wouldnt expect that i need to do the  
backreferences

manually.

At this point i know something that works without setting backrefs
manually, but this looks also quite weird to me because i must use  
OneToOne

on the child. If i do the mapping on the Team (Father) like this:

  @OneToMany(cascade = CascadeType.PERSIST)
  @ElementJoinColumn(name = "team_oid", referencedColumnName = "oid")
  public List players;

and then do the mappedBy in the child (player)

  @OneToOne(mappedBy = "players")
  public Team team;

Then i have my bidirectional link and i also have the FK column  
filled like

if i wouldnt use the mappedBy.

Would you recommend doing it like you have done it? As i said, i  
would

expect the ORM layer to work out the back reference because i already
defined the relationship via setting childs to a list, why telling  
the

childs again to which object they belong?

Thanks for being with me on that one. Appreciate that.



---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 13.11.2009 um 18:27 schrieb Michael Dick:


Hi Marc,


Are you setting the relationship for both the Father and Child  
entities?


I see the behav

Re: inverse OneToMany relation - getting weird

[Marc Logemann]

Hi,

for the records, i am using 1.2.0.

To your question: i am only doing that (sorry, i changed my example to  
be Team->Player, instead of Father->Child) :


Player p = new Player();
p.setName("Huiboo");
List list = new ArrayList();
list.add(p);

Team t = new Team();
t.setName("VfL");
t.setPlayers(list);
em.persist(t);

So yes, i am only setting the child references in the list and i dont  
manually set the backreference. To be honest,  i dont understand your  
example too well. I wouldnt expect that i need to do the  
backreferences manually.


At this point i know something that works without setting backrefs  
manually, but this looks also quite weird to me because i must use  
OneToOne on the child. If i do the mapping on the Team (Father) like  
this:


@OneToMany(cascade = CascadeType.PERSIST)
@ElementJoinColumn(name = "team_oid", referencedColumnName = "oid")
public List players;

and then do the mappedBy in the child (player)

@OneToOne(mappedBy = "players")
public Team team;

Then i have my bidirectional link and i also have the FK column filled  
like if i wouldnt use the mappedBy.


Would you recommend doing it like you have done it? As i said, i would  
expect the ORM layer to work out the back reference because i already  
defined the relationship via setting childs to a list, why telling the  
childs again to which object they belong?


Thanks for being with me on that one. Appreciate that.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 13.11.2009 um 18:27 schrieb Michael Dick:


Hi Marc,

Are you setting the relationship for both the Father and Child  
entities?


I see the behavior you describe if I do this :
   Father f;
   Child c;
   for (int i = 0; i < nFathers; i++) {
   f = new Father();
   f.setChildren(new ArrayList());
   em.persist(f);

   for(int j = 0 ; j < nChildren; j++ ) {
   c = new Child();
//c.setFather(f);
   f.getChildren().add(c);
   em.persist(c);
   }


Uncommenting c.setFather(f); fixes the problem. If that doesn't help  
let me
know which version of OpenJPA and which database you're using and  
I'll try

to recreate.

-mike

On Fri, Nov 13, 2009 at 10:33 AM, Marc Logemann   
wrote:



Hi,

what you have done works of course but thats not my problem because  
thats

what i had before i wanted to do the inverse. Your example simply
demonstrates how to use ElementJoinColumn and i am pretty aware of  
that ;-)

The problem starts when using mappedBy on the children inside Father.

When i am doing it as you described it in your email before, i am  
at least
not getting any errors back but instead he inserts a "null" in my  
FK field.


  @ManyToOne
  @ForeignKey
  @JoinColumn(name="team_oid", referencedColumnName="oid")
  public Team team;

I am really clueless. It simply cant be so hard and uncommon to  
make an

inverse OneToMany with a FK field in the child table.

I googled for hours and all example i ve found just dont work.



---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 13.11.2009 um 17:17 schrieb Michael Dick:


Hi Marc,


Did some more reading and I was wrong about the use case for the  
@Element

annotations. The @Element annotations allow you to specify the FK
constraint
on the One side of a @OneToMany, so your annotations would look  
like this

:

@Entity
public class Father extends Person {
 @OneToMany
 @ElementForeignKey
 @ElementJoinColumn(name="father_oid", referencedColumnName="oid")
 Collection children;
. . .
}

@Entity
public class Child extends Person {
 @ManyToOne
 private Father father;
. . .
}

It appears to be functionally identical to using @JoinColumn and
@ForeignKey
on the Child class, but the documentation is a bit sparse on this
annotation..

There are several examples in our unit tests though. For example

openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/ 
persistence/jdbc/mapping/bidi/ParentWithAutoIdentity.java

looks somewhat similar to your model.

Hope this helps,
-mike


-- Forwarded message --
From: Michael Dick 
Date: Fri, Nov 13, 2009 at 9:52 AM
Subject: Re: inverse OneToMany relation - getting weird
To: users@openjpa.apache.org


Hi Marc,

I think the @ElementForeignKey and @ElementJoinColumn annotations  
are
intended to be used with non-entity types (ie  
PersistentCollections).


If Child is an entity you'd want to use @ForeignKey and @JoinColumn
instead
(I gave this a quick try and it looks like it worked for me).

Regards,
-mike


On Fri, Nov 13, 2009 at 7:03 AM, Marc Logemann   
wrote:


Hi,


after struggling for several hours, i need to ask for help.

Following scenario.

DB Table: Father

Re: inverse OneToMany relation - getting weird

[Marc Logemann]

Hi,

what you have done works of course but thats not my problem because  
thats what i had before i wanted to do the inverse. Your example  
simply demonstrates how to use ElementJoinColumn and i am pretty aware  
of that ;-) The problem starts when using mappedBy on the children  
inside Father.


When i am doing it as you described it in your email before, i am at  
least not getting any errors back but instead he inserts a "null" in  
my FK field.


@ManyToOne
@ForeignKey
@JoinColumn(name="team_oid", referencedColumnName="oid")
public Team team;

I am really clueless. It simply cant be so hard and uncommon to make  
an inverse OneToMany with a FK field in the child table.


I googled for hours and all example i ve found just dont work.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 13.11.2009 um 17:17 schrieb Michael Dick:


Hi Marc,

Did some more reading and I was wrong about the use case for the  
@Element
annotations. The @Element annotations allow you to specify the FK  
constraint
on the One side of a @OneToMany, so your annotations would look like  
this :


@Entity
public class Father extends Person {
   @OneToMany
   @ElementForeignKey
   @ElementJoinColumn(name="father_oid", referencedColumnName="oid")
   Collection children;
. . .
}

@Entity
public class Child extends Person {
   @ManyToOne
   private Father father;
. . .
}

It appears to be functionally identical to using @JoinColumn and  
@ForeignKey

on the Child class, but the documentation is a bit sparse on this
annotation..

There are several examples in our unit tests though. For example
openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/ 
persistence/jdbc/mapping/bidi/ParentWithAutoIdentity.java

looks somewhat similar to your model.

Hope this helps,
-mike


-- Forwarded message --
From: Michael Dick 
Date: Fri, Nov 13, 2009 at 9:52 AM
Subject: Re: inverse OneToMany relation - getting weird
To: users@openjpa.apache.org


Hi Marc,

I think the @ElementForeignKey and @ElementJoinColumn annotations are
intended to be used with non-entity types (ie PersistentCollections).

If Child is an entity you'd want to use @ForeignKey and @JoinColumn  
instead

(I gave this a quick try and it looks like it worked for me).

Regards,
-mike


On Fri, Nov 13, 2009 at 7:03 AM, Marc Logemann   
wrote:



Hi,

after struggling for several hours, i need to ask for help.

Following scenario.

DB Table: Father
---
INT oid



DB Table: Childs

INT oid
INT father_oid
...

Java Entity: Father
--
...
@OneToMany(cascade = CascadeType.PERSIST, mappedBy = "father")
private List childList;

Java Entity: Child
--
...
@ManyToOne(cascade = CascadeType.PERSIST)
@ElementForeignKey
@ElementJoinColumn(name="father_oid", referencedColumnName="oid")
protected Father father;


When i try to persist a Father, i am getting:


org.apache.openjpa.persistence.ArgumentException: Field  
"Father.childList"
declares "Child.father" as its mapped-by field, but this field is  
not a

direct relation. at..

Ok, then i changed Child to:

Java Entity: Child
--
...
@ManyToOne(cascade = CascadeType.PERSIST)
@Column(name = "father_oid")
protected Father father;


When i now do persist a Father object, both DB records (Father and  
Childs)
are filled with records but the FK column in Child (father_oid) is  
empty. So
the FK relation is broken but it did persist childs, which is  
somehow weird.


So whatever i do, i never get a fully persisted graph with correct FK
values.

Can anyone give me a hint what i am doing wrong here?


Thanks a lot.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

inverse OneToMany relation - getting weird

[Marc Logemann]

Hi,

after struggling for several hours, i need to ask for help.

Following scenario.

DB Table: Father
---
INT oid



DB Table: Childs

INT oid
INT father_oid
...

Java Entity: Father
--
...
@OneToMany(cascade = CascadeType.PERSIST, mappedBy = "father")
 private List childList;

Java Entity: Child
--
...
@ManyToOne(cascade = CascadeType.PERSIST)
@ElementForeignKey
@ElementJoinColumn(name="father_oid", referencedColumnName="oid")
protected Father father;


When i try to persist a Father, i am getting:

  
org.apache.openjpa.persistence.ArgumentException: Field  
"Father.childList" declares "Child.father" as its mapped-by field, but  
this field is not a direct relation. at..


Ok, then i changed Child to:

Java Entity: Child
--
...
@ManyToOne(cascade = CascadeType.PERSIST)
@Column(name = "father_oid")
protected Father father;


When i now do persist a Father object, both DB records (Father and  
Childs) are filled with records but the FK column in Child  
(father_oid) is empty. So the FK relation is broken but it did persist  
childs, which is somehow weird.


So whatever i do, i never get a fully persisted graph with correct FK  
values.


Can anyone give me a hint what i am doing wrong here?


Thanks a lot.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: strange JPA Enhance stack

[Marc Logemann]

Craig,

my intention was not  to rant against SERP :-)

I already filed a JIRA. I will report things there if i see something  
new during my tests...


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 19.05.2009 um 21:57 schrieb Craig L Russell:


Hi Marc,

As Mike says, we could be a bit more friendly. By the way, SERP has  
been very reliable so this hasn't been much of an issue to date.


Could you please file a JIRA so we don't forget about it?

Thanks,

Craig

On May 19, 2009, at 5:53 AM, Michael Dick wrote:


Hi Marc,

Sounds like an unchecked exception thrown by Serp and we could be a  
bit
friendlier about how we handle it. At least dumping the classname  
that we're
trying to load would help. Adding a try / catch might be helpful.  
Which

version of OpenJPA are you using?

My guess is that it is OpenJDK related and the compiled class is not
matching Serp's expectation. I haven't seen this exception before  
though and

I can't tell you why you're getting it.

-mike

On Tue, May 19, 2009 at 3:46 AM, Marc Logemann   
wrote:



David,

no, have not done this. Its quite a hughe effort to create a  
project from
scratch and deploy it to SCM and configure TeamCity to "compile/ 
test" it. I
still think its not a library issue because i use ivy within ANT  
and the
build system resolves libs the same way as its done on each  
developer
machine. The stack doesnt look like a missing lib to me. And its  
definitely
also not an ANT issue because i am using the same ANT Target on  
the dev

machines.

I hoped somebody who developed the enhancer can tell something  
about the
stack. I mean something like "this problem can only occur under  
this or that

condition".

In any way... do we agree that an IllegalArgumentException in SERP  
shouldnt
be the first Exception on the stack ? I definitely would expect an  
Enhancer
Exception saying whats wrong on an upper level. Something like  
"Enhancement
failed on Class X" or something. The root cause would be of course  
the SERP

exception.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 18.05.2009 um 16:29 schrieb Rick Curtis:




-Marc

Any luck with the suggestion that David made?


David Beer-2 wrote:



On Sat, 16 May 2009 15:32:36 +0200
Marc Logemann  wrote:

Hi Marc

Can't seem that it is OpenJDK 6 related as I use it here for  
both my

development and continous build system (hudson under tomcat).

Are you using Ant or Maven with the build process. I have seen  
on lists
that this can sometimes be a problem. Can you create a small  
project
which has say just one class to enhance and see if that works  
through
you build system. I am thinking that it may be a classpath or  
library

problem.

David




--
View this message in context:
http://n2.nabble.com/strange-JPA-Enhance-stack-tp2912505p2933425.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.






Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@sun.com
P.S. A good JDO? O, Gasp!

Re: strange JPA Enhance stack

[Marc Logemann]

Mike,

i am using:

conf="default->default,sources,javadoc"/>


I am 80% sure its OpenJDK related because the rest of the story is  
absolutely the same compared what our people do on their dev machines  
but nobody uses OpenJDK 6 on the dev machines. So thats why we never  
had problems with that before.


Now the big question is... how to solve :-) I could start patching the  
Enhancer classes to get a little bit more info out of it. And i can  
increase the Enhancer logging level and hope for more infos there.  
Another opportunity would be to use the latest version of Serp and see  
what goes on then. Unfortunately SERP seems to be a library which only  
JPA folks use so i have not much hope that a newer version will fix it.


Will report back if i have some more infos Perhaps its worth a  
JIRA, then we can log things. Its hard to track infos on maillists  
over time.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 19.05.2009 um 14:53 schrieb Michael Dick:


Hi Marc,

Sounds like an unchecked exception thrown by Serp and we could be a  
bit
friendlier about how we handle it. At least dumping the classname  
that we're
trying to load would help. Adding a try / catch might be helpful.  
Which

version of OpenJPA are you using?

My guess is that it is OpenJDK related and the compiled class is not
matching Serp's expectation. I haven't seen this exception before  
though and

I can't tell you why you're getting it.

-mike

On Tue, May 19, 2009 at 3:46 AM, Marc Logemann   
wrote:



David,

no, have not done this. Its quite a hughe effort to create a  
project from
scratch and deploy it to SCM and configure TeamCity to "compile/ 
test" it. I
still think its not a library issue because i use ivy within ANT  
and the

build system resolves libs the same way as its done on each developer
machine. The stack doesnt look like a missing lib to me. And its  
definitely
also not an ANT issue because i am using the same ANT Target on the  
dev

machines.

I hoped somebody who developed the enhancer can tell something  
about the
stack. I mean something like "this problem can only occur under  
this or that

condition".

In any way... do we agree that an IllegalArgumentException in SERP  
shouldnt
be the first Exception on the stack ? I definitely would expect an  
Enhancer
Exception saying whats wrong on an upper level. Something like  
"Enhancement
failed on Class X" or something. The root cause would be of course  
the SERP

exception.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 18.05.2009 um 16:29 schrieb Rick Curtis:




-Marc

Any luck with the suggestion that David made?


David Beer-2 wrote:



On Sat, 16 May 2009 15:32:36 +0200
Marc Logemann  wrote:

Hi Marc

Can't seem that it is OpenJDK 6 related as I use it here for both  
my

development and continous build system (hudson under tomcat).

Are you using Ant or Maven with the build process. I have seen on  
lists
that this can sometimes be a problem. Can you create a small  
project
which has say just one class to enhance and see if that works  
through
you build system. I am thinking that it may be a classpath or  
library

problem.

David




--
View this message in context:
http://n2.nabble.com/strange-JPA-Enhance-stack- 
tp2912505p2933425.html

Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: strange JPA Enhance stack

[Marc Logemann]

David,

no, have not done this. Its quite a hughe effort to create a project  
from scratch and deploy it to SCM and configure TeamCity to "compile/ 
test" it. I still think its not a library issue because i use ivy  
within ANT and the build system resolves libs the same way as its done  
on each developer machine. The stack doesnt look like a missing lib to  
me. And its definitely also not an ANT issue because i am using the  
same ANT Target on the dev machines.


I hoped somebody who developed the enhancer can tell something about  
the stack. I mean something like "this problem can only occur under  
this or that condition".


In any way... do we agree that an IllegalArgumentException in SERP  
shouldnt be the first Exception on the stack ? I definitely would  
expect an Enhancer Exception saying whats wrong on an upper level.  
Something like "Enhancement failed on Class X" or something. The root  
cause would be of course the SERP exception.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 18.05.2009 um 16:29 schrieb Rick Curtis:



-Marc

Any luck with the suggestion that David made?


David Beer-2 wrote:


On Sat, 16 May 2009 15:32:36 +0200
Marc Logemann  wrote:

Hi Marc

Can't seem that it is OpenJDK 6 related as I use it here for both my
development and continous build system (hudson under tomcat).

Are you using Ant or Maven with the build process. I have seen on  
lists

that this can sometimes be a problem. Can you create a small project
which has say just one class to enhance and see if that works through
you build system. I am thinking that it may be a classpath or library
problem.

David




--
View this message in context: 
http://n2.nabble.com/strange-JPA-Enhance-stack-tp2912505p2933425.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Fwd: strange JPA Enhance stack

[Marc Logemann]

 org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de





Anfang der weitergeleiteten E-Mail:


Von: Marc Logemann 
Datum: 17. Mai 2009 11:03:04 MESZ
An: users@openjpa.apache.org
Betreff: Re: strange JPA Enhance stack

Just to clarify. I am using  exactly same build file (ANT) with the  
same task on the Ingegration server as on our development machines.  
In fact the server checkouts the original source and does what  
every developer does. Thats the idea of continous build server isnt  
it? :-)


The only difference i see is the JDK but it can be also something  
else though The classpath (at least user classpath) should be  
100% the same because i am using ivy and again the server uses the  
same ivy file than every developer.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 16.05.2009 um 17:38 schrieb David Beer:


On Sat, 16 May 2009 15:32:36 +0200
Marc Logemann  wrote:


Us. Sorry. Wrong assumption: its not EMMA related. It must be
something else perhaps OpenJDK 6 related?


Hi Marc

Can't seem that it is OpenJDK 6 related as I use it here for both my
development and continous build system (hudson under tomcat).

Are you using Ant or Maven with the build process. I have seen on  
lists

that this can sometimes be a problem. Can you create a small project
which has say just one class to enhance and see if that works  
through
you build system. I am thinking that it may be a classpath or  
library

problem.

David

Re: strange JPA Enhance stack

[Marc Logemann]

Just to clarify. I am using  exactly same build file (ANT) with the  
same task on the Ingegration server as on our development machines. In  
fact the server checkouts the original source and does what every  
developer does. Thats the idea of continous build server isnt it? :-)


The only difference i see is the JDK but it can be also something else  
though The classpath (at least user classpath) should be 100% the  
same because i am using ivy and again the server uses the same ivy  
file than every developer.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 16.05.2009 um 17:38 schrieb David Beer:


On Sat, 16 May 2009 15:32:36 +0200
Marc Logemann  wrote:


Us. Sorry. Wrong assumption: its not EMMA related. It must be
something else perhaps OpenJDK 6 related?


Hi Marc

Can't seem that it is OpenJDK 6 related as I use it here for both my
development and continous build system (hudson under tomcat).

Are you using Ant or Maven with the build process. I have seen on  
lists

that this can sometimes be a problem. Can you create a small project
which has say just one class to enhance and see if that works through
you build system. I am thinking that it may be a classpath or library
problem.

David

Re: strange JPA Enhance stack

[Marc Logemann]

Us. Sorry. Wrong assumption: its not EMMA related. It must be  
something else perhaps OpenJDK 6 related?


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 16.05.2009 um 15:17 schrieb Marc Logemann:

Ok guys, i give you a hint: It does work when i disable EMMA  
instrumentation. Why is it a problem when i let the EMMA instrument  
the classes? I wanted to use it because of code coverage statistics  
and its supported out of the box by TeamCity.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 16.05.2009 um 15:09 schrieb Marc Logemann:


Hi,

today we installed our Continous build system (TeamCity) and we  
tried to run our first automated build on Linux with OpenJDK 6.  
Even though our build works on all client computers it fails with  
the same (ivy resolved) build path on OpenJDK 6 wih the following  
stack. Perhaps someone can comment on this:


[15:06:10]: [jpaenhance] openjpac
[15:06:11]: [openjpac] java.lang.IllegalArgumentException: 5
[15:06:11]: [openjpac] at  
serp.bytecode.Code.getInstruction(Code.java:2131)

[15:06:11]: [openjpac] at serp.bytecode.Local.getEnd(Local.java:113)
[15:06:11]: [openjpac] at  
serp.bytecode.Local.updateTargets(Local.java:155)
[15:06:11]: [openjpac] at  
serp.bytecode.LocalTable.updateTargets(LocalTable.java:163)

[15:06:11]: [openjpac] at serp.bytecode.Code.read(Code.java:2031)
[15:06:11]: [openjpac] at  
serp.bytecode.Attributes.readAttributes(Attributes.java:152)
[15:06:11]: [openjpac] at serp.bytecode.BCMember.read(BCMember.java: 
365)
[15:06:11]: [openjpac] at serp.bytecode.BCClass.read(BCClass.java: 
123)
[15:06:11]: [openjpac] at serp.bytecode.BCClass.read(BCClass.java: 
144)
[15:06:11]: [openjpac] at  
serp.bytecode.Project.loadClass(Project.java:139)
[15:06:11]: [openjpac] at  
org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4491)
[15:06:11]: [openjpac] at  
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java: 
89)
[15:06:11]: [openjpac] at  
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java: 
172)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[15:06:11]: [openjpac] at  
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[15:06:11]: [openjpac] at  
sun 
.reflect 
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[15:06:11]: [openjpac] at  
sun 
.reflect 
.DelegatingMethodAccessorImpl 
.invoke(DelegatingMethodAccessorImpl.java:43)
[15:06:11]: [openjpac] at  
java.lang.reflect.Method.invoke(Method.java:616)
[15:06:11]: [openjpac] at  
org 
.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: 
106)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Task.perform(Task.java:348)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Target.execute(Target.java:357)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Target.performTasks(Target.java:385)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeTarget(Project.java:1306)
[15:06:11]: [openjpac] at  
org 
.apache 
.tools 
.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeTargets(Project.java:1189)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Main.runBuild(Main.java:758)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Main.startAnt(Main.java:217)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

[15:06:11]: [openjpac] java.lang.IllegalArgumentException: 5
[15:06:16]: Ant output:
at serp.bytecode.Local.updateTargets(Local.java:155)
at serp.bytecode.LocalTable.updateTargets(LocalTable.java:163)
at serp.bytecode.Code.read(Code.java:2031)
at serp.bytecode.Attributes.readAttributes(Attributes.java:152)
at serp.bytecode.BCMember.read(BCMember.java:365)
at serp.bytecode.BCClass.read(BCClass.java:123)
at serp.bytecode.BCClass.read(BCClass.java:144)
at serp.bytecode.Project.loadClass(Project.java:139)
at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4491)
at  
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java: 
89)
at  
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java: 
172)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java: 
288)

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:616)
at  
org 
.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: 
106)

at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at

Re: strange JPA Enhance stack

[Marc Logemann]

Ok guys, i give you a hint: It does work when i disable EMMA  
instrumentation. Why is it a problem when i let the EMMA instrument  
the classes? I wanted to use it because of code coverage statistics  
and its supported out of the box by TeamCity.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 16.05.2009 um 15:09 schrieb Marc Logemann:


Hi,

today we installed our Continous build system (TeamCity) and we  
tried to run our first automated build on Linux with OpenJDK 6. Even  
though our build works on all client computers it fails with the  
same (ivy resolved) build path on OpenJDK 6 wih the following stack.  
Perhaps someone can comment on this:


[15:06:10]: [jpaenhance] openjpac
[15:06:11]: [openjpac] java.lang.IllegalArgumentException: 5
[15:06:11]: [openjpac] at  
serp.bytecode.Code.getInstruction(Code.java:2131)

[15:06:11]: [openjpac] at serp.bytecode.Local.getEnd(Local.java:113)
[15:06:11]: [openjpac] at  
serp.bytecode.Local.updateTargets(Local.java:155)
[15:06:11]: [openjpac] at  
serp.bytecode.LocalTable.updateTargets(LocalTable.java:163)

[15:06:11]: [openjpac] at serp.bytecode.Code.read(Code.java:2031)
[15:06:11]: [openjpac] at  
serp.bytecode.Attributes.readAttributes(Attributes.java:152)
[15:06:11]: [openjpac] at serp.bytecode.BCMember.read(BCMember.java: 
365)

[15:06:11]: [openjpac] at serp.bytecode.BCClass.read(BCClass.java:123)
[15:06:11]: [openjpac] at serp.bytecode.BCClass.read(BCClass.java:144)
[15:06:11]: [openjpac] at  
serp.bytecode.Project.loadClass(Project.java:139)
[15:06:11]: [openjpac] at  
org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4491)
[15:06:11]: [openjpac] at  
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java: 
89)
[15:06:11]: [openjpac] at  
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:172)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[15:06:11]: [openjpac] at  
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[15:06:11]: [openjpac] at  
sun 
.reflect 
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[15:06:11]: [openjpac] at  
sun 
.reflect 
.DelegatingMethodAccessorImpl 
.invoke(DelegatingMethodAccessorImpl.java:43)
[15:06:11]: [openjpac] at  
java.lang.reflect.Method.invoke(Method.java:616)
[15:06:11]: [openjpac] at  
org 
.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: 
106)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Task.perform(Task.java:348)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Target.execute(Target.java:357)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Target.performTasks(Target.java:385)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeTarget(Project.java:1306)
[15:06:11]: [openjpac] at  
org 
.apache 
.tools 
.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeTargets(Project.java:1189)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Main.runBuild(Main.java:758)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Main.startAnt(Main.java:217)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

[15:06:11]: [openjpac] java.lang.IllegalArgumentException: 5
[15:06:16]: Ant output:
at serp.bytecode.Local.updateTargets(Local.java:155)
at serp.bytecode.LocalTable.updateTargets(LocalTable.java:163)
at serp.bytecode.Code.read(Code.java:2031)
at serp.bytecode.Attributes.readAttributes(Attributes.java:152)
at serp.bytecode.BCMember.read(BCMember.java:365)
at serp.bytecode.BCClass.read(BCClass.java:123)
at serp.bytecode.BCClass.read(BCClass.java:144)
at serp.bytecode.Project.loadClass(Project.java:139)
at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4491)
at  
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java: 
89)
at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java: 
172)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java: 
288)

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:616)
at  
org 
.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: 
106)

at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java: 
1337)

at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at  
org 
.apache 
.tools 
.ant.helper.DefaultExecutor.executeTargets

strange JPA Enhance stack

[Marc Logemann]

Hi,

today we installed our Continous build system (TeamCity) and we tried  
to run our first automated build on Linux with OpenJDK 6. Even though  
our build works on all client computers it fails with the same (ivy  
resolved) build path on OpenJDK 6 wih the following stack. Perhaps  
someone can comment on this:


[15:06:10]: [jpaenhance] openjpac
[15:06:11]: [openjpac] java.lang.IllegalArgumentException: 5
[15:06:11]: [openjpac] at serp.bytecode.Code.getInstruction(Code.java: 
2131)

[15:06:11]: [openjpac] at serp.bytecode.Local.getEnd(Local.java:113)
[15:06:11]: [openjpac] at serp.bytecode.Local.updateTargets(Local.java: 
155)
[15:06:11]: [openjpac] at  
serp.bytecode.LocalTable.updateTargets(LocalTable.java:163)

[15:06:11]: [openjpac] at serp.bytecode.Code.read(Code.java:2031)
[15:06:11]: [openjpac] at  
serp.bytecode.Attributes.readAttributes(Attributes.java:152)

[15:06:11]: [openjpac] at serp.bytecode.BCMember.read(BCMember.java:365)
[15:06:11]: [openjpac] at serp.bytecode.BCClass.read(BCClass.java:123)
[15:06:11]: [openjpac] at serp.bytecode.BCClass.read(BCClass.java:144)
[15:06:11]: [openjpac] at serp.bytecode.Project.loadClass(Project.java: 
139)
[15:06:11]: [openjpac] at  
org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4491)
[15:06:11]: [openjpac] at  
org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
[15:06:11]: [openjpac] at  
org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:172)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[15:06:11]: [openjpac] at  
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[15:06:11]: [openjpac] at  
sun 
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 
57)
[15:06:11]: [openjpac] at  
sun 
.reflect 
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 
43)
[15:06:11]: [openjpac] at java.lang.reflect.Method.invoke(Method.java: 
616)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: 
106)
[15:06:11]: [openjpac] at org.apache.tools.ant.Task.perform(Task.java: 
348)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Target.execute(Target.java:357)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Target.performTasks(Target.java:385)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeTarget(Project.java:1306)
[15:06:11]: [openjpac] at  
org 
.apache 
.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java: 
41)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.Project.executeTargets(Project.java:1189)
[15:06:11]: [openjpac] at org.apache.tools.ant.Main.runBuild(Main.java: 
758)
[15:06:11]: [openjpac] at org.apache.tools.ant.Main.startAnt(Main.java: 
217)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
[15:06:11]: [openjpac] at  
org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

[15:06:11]: [openjpac] java.lang.IllegalArgumentException: 5
[15:06:16]: Ant output:
at serp.bytecode.Local.updateTargets(Local.java:155)
at serp.bytecode.LocalTable.updateTargets(LocalTable.java:163)
at serp.bytecode.Code.read(Code.java:2031)
at serp.bytecode.Attributes.readAttributes(Attributes.java:152)
at serp.bytecode.BCMember.read(BCMember.java:365)
at serp.bytecode.BCClass.read(BCClass.java:123)
at serp.bytecode.BCClass.read(BCClass.java:144)
at serp.bytecode.Project.loadClass(Project.java:139)
at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4491)
at org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java: 
89)
at org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java: 
172)

at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
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:616)
at  
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: 
106)

at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at  
org 
.apache 
.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java: 
41)

at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
at org.apache.tools.ant.Main.runBuild(Main.java:758)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)



---
regards
Marc Logemann
http://www.logemann.org
http

automatic merge / persist

[Marc Logemann]

Hi,

suppose the following code:

@Transactional
public void bar() {
foo();
}

public void foo() {
MyJPAEntity entity = someJPADao.getEntity();
entity.setName("foo");
}


When running this code, would you expect that entity gets persisted /  
updated? In method "foo", the object entity is a detached instance of  
MyJPAEntity when coming back from the DAO. And now i really wonder why  
this detached instance gets "merged" (aka updated) when i leave bar().


I migrated my codebase from Kodo/JDO and there, MyJPAEntity wouldnt  
have been updated without an explicit re-attach. Any explanations  
welcome.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: Can't query against a MappedSuperclass

[Marc Logemann]

In the same documentation the following is stated and this was always  
my definition of querying mappedSC.


Section 1.3

"A mapped superclass is a non-entity class that can define persistent  
state and mapping information for entity subclasses. Mapped  
superclasses are usually abstract. Unlike true entities, you cannot  
query a mapped superclass, pass a mapped superclass instance to any  
EntityManager or Query methods, or declare a persistent relation with  
a mapped superclass target. You denote a mapped superclass with the  
MappedSuperclass marker annotation. "


So whats correct here? The Note says the opposite...  Perhaps it  
should be made clearer but i always thought that the note is not true,  
because in my code, i experienced the same as Jim.


So any feedback from the core team appreciated

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 20.04.2009 um 21:38 schrieb jim weaver:



I have the following:

@MappedSuperclass class A { }
@Entity class B extends A { }
@Entity class C extends A { }

and I try to do this type of query: SELECT a FROM A a

I receive error message "An error occurred while parsing the query  
filter
"SELECT a FROM A a".  Error message:   The name "A" is not a  
recognized
entity or identifier.  Perhaps you meant B, which is a close match.   
Known

entity names: [B, C]"

A is defined in my persistence.xml and my tables do have the inherited
fields from it so I'm pretty sure jpa is recognizing it.

The OpenJPA doc says that the query is supported.this is from  
the 1.2.0

doc:

Note
OpenJPA allows you to query on mapped superclasses. A query on a  
mapped

superclass will return all matching subclass instances.


--
View this message in context: 
http://n2.nabble.com/Can%27t-query-against-a-MappedSuperclass-tp2665700p2665700.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: detachment of fetch-groups doesnt work

[Marc Logemann]

here we go: https://issues.apache.org/jira/browse/OPENJPA-1030

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 09.04.2009 um 13:05 schrieb Marc Logemann:


Hi,

explicitly detaching is only possible via OpenJPA product API right?  
No, i have not done that explicitly, it was implicit at context end.
And yes, as written earlier, i experimented with all 3 DetachState  
levels and "all" worked like expected. I even had an annoyance with  
"loaded" when explicitly defined in contrast to leaving it out  
alltogether.


I will file a jira with mainly my main mail from yesterday.....

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 09.04.2009 um 12:30 schrieb Craig L Russell:


It's worth a JIRA.

Detachment occurs either at context end or at explicit detach.

Does this anomalous behavior occur if you explicitly detach your  
entities, or only implicitly at context end?


And have you changed the openjpa.DetachState configuration property  
which governs how objects are detached?


Craig

On Apr 8, 2009, at 11:57 PM, Marc Logemann wrote:


is this worth a JIRA ?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 08.04.2009 um 23:50 schrieb Tedman Leung:


just as additional information, this is also true about any lazy
PersistentCollection too. I found that if I accessed the  
collection while
it is in an attached state the values are available, but as soon  
as it
becomes detached the collection becomes null even if I had just  
accessed

it prior to detachment.

I'm not entirely sure if this is a bug or if it's suppose to work  
this way

when detached.

On Wed, Apr 08, 2009 at 05:18:48PM +0200, Marc Logemann wrote:

Hi,

with OpenJPA 1.2.0 i am having some problems detaching  
attributes which

are in a fetch-group. My persistence.xml is:



My Domain class header:

@FetchGroups({
@FetchGroup(name="posDetail", attributes={
@FetchAttribute(name="deliveryAddresses")
})
})
public class Order {

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL, fetch =
FetchType.LAZY)
List deliveryAddresses;
...
}

(in fact i also have the @LoadFetchGroup("posDetail")  to be  
sure.)


Now when i am leaving my DAO layer which means that the  
persistence
contexts ends, the delivery address is "null" even though its in  
the

fetch group. I even queried for the fetch group in the DAO before
leaving it via:

OpenJPAQuery oQuery =  
OpenJPAPersistence.cast(em.createQuery("select o

from Order o where o.oid = ?1"));
oQuery.setParameter(1, oid);
//
oQuery 
.getFetchPlan().setMaxFetchDepth(3).addFetchGroup("posDetail");

List list = oQuery.getResultList();
if(list != null && list.size() > 0)  {
return (Order)list.iterator().next();
}

I know it must be a detach issue because with the following
persistence.xml it works (but i definitely wont use this config in
production)



Am i missing something here? When i debug my DAO, the  
deliveryAddress

attribute is populated but as soon as i leave my DAO, its lost.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de






--
   Ted Leung

ted...@sfu.ca


I can speak Canadian, American, Australian, and little English.





Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@sun.com
P.S. A good JDO? O, Gasp!

Re: detachment of fetch-groups doesnt work

[Marc Logemann]

Hi,

explicitly detaching is only possible via OpenJPA product API right?  
No, i have not done that explicitly, it was implicit at context end.
And yes, as written earlier, i experimented with all 3 DetachState  
levels and "all" worked like expected. I even had an annoyance with  
"loaded" when explicitly defined in contrast to leaving it out  
alltogether.


I will file a jira with mainly my main mail from yesterday.....

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 09.04.2009 um 12:30 schrieb Craig L Russell:


It's worth a JIRA.

Detachment occurs either at context end or at explicit detach.

Does this anomalous behavior occur if you explicitly detach your  
entities, or only implicitly at context end?


And have you changed the openjpa.DetachState configuration property  
which governs how objects are detached?


Craig

On Apr 8, 2009, at 11:57 PM, Marc Logemann wrote:


is this worth a JIRA ?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 08.04.2009 um 23:50 schrieb Tedman Leung:


just as additional information, this is also true about any lazy
PersistentCollection too. I found that if I accessed the  
collection while
it is in an attached state the values are available, but as soon  
as it
becomes detached the collection becomes null even if I had just  
accessed

it prior to detachment.

I'm not entirely sure if this is a bug or if it's suppose to work  
this way

when detached.

On Wed, Apr 08, 2009 at 05:18:48PM +0200, Marc Logemann wrote:

Hi,

with OpenJPA 1.2.0 i am having some problems detaching attributes  
which

are in a fetch-group. My persistence.xml is:



My Domain class header:

@FetchGroups({
 @FetchGroup(name="posDetail", attributes={
 @FetchAttribute(name="deliveryAddresses")
 })
})
public class Order {

 @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, fetch =
FetchType.LAZY)
 List deliveryAddresses;
...
}

(in fact i also have the @LoadFetchGroup("posDetail")  to be  
sure.)


Now when i am leaving my DAO layer which means that the persistence
contexts ends, the delivery address is "null" even though its in  
the

fetch group. I even queried for the fetch group in the DAO before
leaving it via:

OpenJPAQuery oQuery =  
OpenJPAPersistence.cast(em.createQuery("select o

from Order o where o.oid = ?1"));
 oQuery.setParameter(1, oid);
 //
oQuery 
.getFetchPlan().setMaxFetchDepth(3).addFetchGroup("posDetail");

 List list = oQuery.getResultList();
 if(list != null && list.size() > 0)  {
 return (Order)list.iterator().next();
 }

I know it must be a detach issue because with the following
persistence.xml it works (but i definitely wont use this config in
production)



Am i missing something here? When i debug my DAO, the  
deliveryAddress

attribute is populated but as soon as i leave my DAO, its lost.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de






--
Ted Leung
 
ted...@sfu.ca


I can speak Canadian, American, Australian, and little English.





Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@sun.com
P.S. A good JDO? O, Gasp!

Re: detachment of fetch-groups doesnt work

[Marc Logemann]

is this worth a JIRA ?

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 08.04.2009 um 23:50 schrieb Tedman Leung:


just as additional information, this is also true about any lazy
PersistentCollection too. I found that if I accessed the collection  
while

it is in an attached state the values are available, but as soon as it
becomes detached the collection becomes null even if I had just  
accessed

it prior to detachment.

I'm not entirely sure if this is a bug or if it's suppose to work  
this way

when detached.

On Wed, Apr 08, 2009 at 05:18:48PM +0200, Marc Logemann wrote:

Hi,

with OpenJPA 1.2.0 i am having some problems detaching attributes  
which

are in a fetch-group. My persistence.xml is:



My Domain class header:

@FetchGroups({
   @FetchGroup(name="posDetail", attributes={
   @FetchAttribute(name="deliveryAddresses")
   })
})
public class Order {

   @OneToMany(mappedBy = "order", cascade = CascadeType.ALL, fetch =
FetchType.LAZY)
   List deliveryAddresses;
...
}

(in fact i also have the @LoadFetchGroup("posDetail")  to be  
sure.)


Now when i am leaving my DAO layer which means that the persistence
contexts ends, the delivery address is "null" even though its in the
fetch group. I even queried for the fetch group in the DAO before
leaving it via:

OpenJPAQuery oQuery =  
OpenJPAPersistence.cast(em.createQuery("select o

from Order o where o.oid = ?1"));
   oQuery.setParameter(1, oid);
   //
oQuery.getFetchPlan().setMaxFetchDepth(3).addFetchGroup("posDetail");
   List list = oQuery.getResultList();
   if(list != null && list.size() > 0)  {
   return (Order)list.iterator().next();
   }

I know it must be a detach issue because with the following
persistence.xml it works (but i definitely wont use this config in
production)



Am i missing something here? When i debug my DAO, the deliveryAddress
attribute is populated but as soon as i leave my DAO, its lost.

---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de






--
  Ted Leung
   
ted...@sfu.ca


I can speak Canadian, American, Australian, and little English.

Re: inefficient mapping

[Marc Logemann]

Hi,

the queries are not slow. There are just a hell lot of queries but you  
are right. THe problem is that i ve done EAGER fetching quite  
extensively and it makes no sense to load all positions when i just  
want to show a list of orders in the first place. So i really need to  
invest some more brain into fetch-groups or making more classes  
transactional than just my DAOs.


Unfortantely i have problems with fetch-groups and detachment  
currently. So things are crazy these days :)


It seems it was time that i get into problems so that i really dig  
into the workings of OpenJPA. Good in the long run. Thx for your  
support.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 08.04.2009 um 20:03 schrieb Paul Copeland:


Marc -

If all the join columns are indexed it should not be too slow.   You  
could put the same SQL into an "explain" analysis tool to  
investigate it.  For a start run the SQL outside JPA and see how  
many rows are returned.


Notice you are getting an orderpos, an order, a boxes, and two  
adresses in every row with these EAGER fetches (we don't see how  
Address and Boxes are mapped).  At some point the memory  
requirements might be an issue.  If the ResultSets are large and you  
need all this in memory you might want to look into   
openjpa.jdbc.LRSSize.


- Paul

On 4/8/2009 2:09 AM, Marc Logemann wrote:

Paul,

thx for pointing out that @ElementJoinColumn is definitely not  
needed here. I removed them and at least everything works but  
unfortunately as slow as before. My example was a simple one  
because i dont wanted to show of the real one, but now since i  
really dont know what to do, i must do it.


My Model ( i leave out some bits because of verbosiy):

@Entity
@Table(name = "orders")
public class Order {

   @Id
   @GeneratedValue(strategy = GenerationType.IDENTITY)
   int oid;

   @OneToOne(cascade = CascadeType.PERSIST)
   @JoinColumn(name = "invaddress_oid", unique = true, nullable =  
false, updatable = false)

   Address invoiceAddress;

   @OneToMany(mappedBy = "order" , cascade = CascadeType.ALL, fetch  
= FetchType.EAGER)

   List deliveryAddresses;
...

@Entity
public class DeliveryAddress extends Address {

   @OneToMany(mappedBy = "deliveryAddress",cascade =  
CascadeType.ALL, fetch = FetchType.EAGER)

   List orderPositions;

   @XmlTransient
   @ManyToOne(cascade = CascadeType.REFRESH)
   Order order;
...

@Entity
@Table(name = "orderpos")
public class OrderPosition {

   @Id
   long oid;

   @ManyToOne(cascade = CascadeType.REFRESH)
   @JoinColumn(name = "address_oid")
   DeliveryAddress deliveryAddress;


Thats it. So basically i need some backreferences that when i query  
for OrderPositions, i also get the parent DeliveryAddress. The same  
for DeliveryAddress because i need infos on the Order. The DB looks  
straighforward with foreign keys as usual.


Now my JPA Query is trivial: "select o FROM Order o"

This produces a SQL query for each and every OrderPosition like this:

[..]
[DEBUG http-8080-1 10:45:11] |   
executing prepstmnt 1716186906 SELECT t1.oid, t1.jpatype,  
t1._version, t1.addresstype, t1.city, t1.company, t1.country,  
t1.department, t1.email, t1.firstname, t1.gender, t1.lastname,  
t1.middlename, t1.phone, t1.zip, t1.postofficebox, t1.street,  
t1.housenr, t1.title, t2.oid, t2._version, t2.cleared, t2.id,  
t2.lastused, t2.orderid, t2.boxtype, t1.deliverymode, t3.oid,  
t3._version, t3.created, t3.createdymd, t3.custnr, t3.ordernr,  
t4.oid, t4.jpatype, t4._version, t4.addresstype, t4.city,  
t4.company, t4.country, t4.department, t4.email, t4.firstname,  
t4.gender, t4.lastname, t4.middlename, t4.phone, t4.zip,  
t4.postofficebox, t4.street, t4.housenr, t4.title, t4.box_oid,  
t4.deliverymode, t4.ORDER_OID, t3.iscardowner, t3.cost,  
t3.currency, t3.pricing, t3.paymenttype, t3.printed, t3.printedby,  
t3.totalprice FROM orderpos t0 INNER JOIN address t1 ON  
t0.address_oid = t1.oid LEFT OUTER JOIN boxes t2 ON t1.box_oid =  
t2.oid LEFT OUTER JOIN orders t3 ON t1.ORDER_OID = t3.oid LEFT  
OUTER JOIN address t4 ON t3.invaddress_oid = t4.oid WHERE t0.oid  
= ? [params=(long) 37]


[DEBUG http-8080-1 10:45:11] |  [2  
ms] spent
[DEBUG http-8080-1 10:45:11] |   
executing prepstmnt 1843485325 SELECT t1.oid, t1.jpatype,  
t1._version, t1.addresstype, t1.city, t1.company, t1.country,  
t1.department, t1.email, t1.firstname, t1.gender, t1.lastname,  
t1.middlename, t1.phone, t1.zip, t1.postofficebox, t1.street,  
t1.housenr, t1.title, t2.oid, t2._version, t2.cleared, t2.id,  
t2.lastused, t2.orderid, t2.boxtype, t1.deliverymode, t3.oid,  
t3._version, t3.created, t3.createdymd, t3.custnr, t3.ordernr,  
t4.oid, t4.jpatype, t4._version, t4.addresstype, t4.city,  
t4.company, t4.country, t4.department, t4.email, t4.firstname,  
t4.gender, t4.lastname, t4.middlename, t4.phone, t4.zip,  
t4.postofficebox, t4.street, t4.ho

detachment of fetch-groups doesnt work

[Marc Logemann]

Hi,

with OpenJPA 1.2.0 i am having some problems detaching attributes  
which are in a fetch-group. My persistence.xml is:





My Domain class header:

@FetchGroups({
@FetchGroup(name="posDetail", attributes={
@FetchAttribute(name="deliveryAddresses")
})
})
public class Order {

@OneToMany(mappedBy = "order", cascade = CascadeType.ALL, fetch =  
FetchType.LAZY)

List deliveryAddresses;
...
}

(in fact i also have the @LoadFetchGroup("posDetail")  to be sure.)

Now when i am leaving my DAO layer which means that the persistence  
contexts ends, the delivery address is "null" even though its in the  
fetch group. I even queried for the fetch group in the DAO before  
leaving it via:


OpenJPAQuery oQuery = OpenJPAPersistence.cast(em.createQuery("select o  
from Order o where o.oid = ?1"));

oQuery.setParameter(1, oid);
//  
oQuery.getFetchPlan().setMaxFetchDepth(3).addFetchGroup("posDetail");

List list = oQuery.getResultList();
if(list != null && list.size() > 0)  {
return (Order)list.iterator().next();
}

I know it must be a detach issue because with the following  
persistence.xml it works (but i definitely wont use this config in  
production)




Am i missing something here? When i debug my DAO, the deliveryAddress  
attribute is populated but as soon as i leave my DAO, its lost.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

Re: inefficient mapping

[Marc Logemann]

Paul,

thx for pointing out that @ElementJoinColumn is definitely not needed  
here. I removed them and at least everything works but unfortunately  
as slow as before. My example was a simple one because i dont wanted  
to show of the real one, but now since i really dont know what to do,  
i must do it.


My Model ( i leave out some bits because of verbosiy):

@Entity
@Table(name = "orders")
public class Order {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
int oid;

@OneToOne(cascade = CascadeType.PERSIST)
@JoinColumn(name = "invaddress_oid", unique = true, nullable =  
false, updatable = false)

Address invoiceAddress;

@OneToMany(mappedBy = "order" , cascade = CascadeType.ALL, fetch  
= FetchType.EAGER)

List deliveryAddresses;
...

@Entity
public class DeliveryAddress extends Address {

@OneToMany(mappedBy = "deliveryAddress",cascade =  
CascadeType.ALL, fetch = FetchType.EAGER)

List orderPositions;

@XmlTransient
@ManyToOne(cascade = CascadeType.REFRESH)
Order order;
...

@Entity
@Table(name = "orderpos")
public class OrderPosition {

@Id
long oid;

@ManyToOne(cascade = CascadeType.REFRESH)
@JoinColumn(name = "address_oid")
DeliveryAddress deliveryAddress;


Thats it. So basically i need some backreferences that when i query  
for OrderPositions, i also get the parent DeliveryAddress. The same  
for DeliveryAddress because i need infos on the Order. The DB looks  
straighforward with foreign keys as usual.


Now my JPA Query is trivial: "select o FROM Order o"

This produces a SQL query for each and every OrderPosition like this:

[..]
[DEBUG http-8080-1 10:45:11] |   
executing prepstmnt 1716186906 SELECT t1.oid, t1.jpatype, t1._version,  
t1.addresstype, t1.city, t1.company, t1.country, t1.department,  
t1.email, t1.firstname, t1.gender, t1.lastname, t1.middlename,  
t1.phone, t1.zip, t1.postofficebox, t1.street, t1.housenr, t1.title,  
t2.oid, t2._version, t2.cleared, t2.id, t2.lastused, t2.orderid,  
t2.boxtype, t1.deliverymode, t3.oid, t3._version, t3.created,  
t3.createdymd, t3.custnr, t3.ordernr, t4.oid, t4.jpatype, t4._version,  
t4.addresstype, t4.city, t4.company, t4.country, t4.department,  
t4.email, t4.firstname, t4.gender, t4.lastname, t4.middlename,  
t4.phone, t4.zip, t4.postofficebox, t4.street, t4.housenr, t4.title,  
t4.box_oid, t4.deliverymode, t4.ORDER_OID, t3.iscardowner, t3.cost,  
t3.currency, t3.pricing, t3.paymenttype, t3.printed, t3.printedby,  
t3.totalprice FROM orderpos t0 INNER JOIN address t1 ON t0.address_oid  
= t1.oid LEFT OUTER JOIN boxes t2 ON t1.box_oid = t2.oid LEFT OUTER  
JOIN orders t3 ON t1.ORDER_OID = t3.oid LEFT OUTER JOIN address t4 ON  
t3.invaddress_oid = t4.oid WHERE t0.oid = ? [params=(long) 37]


[DEBUG http-8080-1 10:45:11] |  [2 ms]  
spent
[DEBUG http-8080-1 10:45:11] |   
executing prepstmnt 1843485325 SELECT t1.oid, t1.jpatype, t1._version,  
t1.addresstype, t1.city, t1.company, t1.country, t1.department,  
t1.email, t1.firstname, t1.gender, t1.lastname, t1.middlename,  
t1.phone, t1.zip, t1.postofficebox, t1.street, t1.housenr, t1.title,  
t2.oid, t2._version, t2.cleared, t2.id, t2.lastused, t2.orderid,  
t2.boxtype, t1.deliverymode, t3.oid, t3._version, t3.created,  
t3.createdymd, t3.custnr, t3.ordernr, t4.oid, t4.jpatype, t4._version,  
t4.addresstype, t4.city, t4.company, t4.country, t4.department,  
t4.email, t4.firstname, t4.gender, t4.lastname, t4.middlename,  
t4.phone, t4.zip, t4.postofficebox, t4.street, t4.housenr, t4.title,  
t4.box_oid, t4.deliverymode, t4.ORDER_OID, t3.iscardowner, t3.cost,  
t3.currency, t3.pricing, t3.paymenttype, t3.printed, t3.printedby,  
t3.totalprice FROM orderpos t0 INNER JOIN address t1 ON t0.address_oid  
= t1.oid LEFT OUTER JOIN boxes t2 ON t1.box_oid = t2.oid LEFT OUTER  
JOIN orders t3 ON t1.ORDER_OID = t3.oid LEFT OUTER JOIN address t4 ON  
t3.invaddress_oid = t4.oid WHERE t0.oid = ? [params=(long) 38]

[..]


As you can imagine, having thousands or even millions of  
OrderPositions some time, this gets quite ugly. Now the big question  
is, why is this the case? In my test DB i have "only" 1520 postions  
and even that produces a 14 seconds "wait" for the Queries being  
processed.


Sorry for supplying so much text but i think you cant make it much  
shorter. Right now i am quite clueless and this mapping is already in  
production and each day it gets more worse gr.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 08.04.2009 um 06:49 schrieb Paul Copeland:


Hi Marc -

I wonder what kind of database schema that produces. Normally you  
would have OneToMany on one side and ManyToOne on the other side,  
with the mappedBy on the OneToMany side.  This is the classical way  
the foreign keys work in relational database models.  I think you do  
not need ElementJoinColumn as the defaults wi

inefficient mapping

[Marc Logemann]

Hi,

i am getting this and because i have some severe performance problems  
with our OpenJPA based app, i wanted to ask for help:


[INFO 02:06:25] Log4JLogFactory$LogAdapter.info(80) | Inefficient  
mapping: You have declared that field  
"de.logentis.bwh.model.RetourePosition.retoure" is mapped by  
collection "de.logentis.bwh.model.Retoure.retourePositionList".  The  
mapping would be much more efficient if instead you map  
"de.logentis.bwh.model.RetourePosition.retoure" and declare that  
"de.logentis.bwh.model.Retoure.retourePositionList" is mapped by it.


My domain model:

@Entity
@Table(name = "retoure")
@VersionColumn(name = "_version")
public class Retoure {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "oid")
long oid;

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER)
@ElementJoinColumn(name = "retoure_oid", referencedColumnName =  
"oid")

List retourePositionList;

---

@Entity
@VersionColumn(name = "_version")
@Table(name = "retourepos")
public class RetourePosition {

@Id
@Column(name = "oid")
@GeneratedValue(strategy = GenerationType.IDENTITY)
long oid;

@OneToOne(mappedBy = "retourePositionList", cascade =  
CascadeType.REFRESH, fetch = FetchType.EAGER)

Retoure retoure;

---

Table Info: "retoure_oid" is a foreign key field in the "retourepos"  
table that points to the "oid" field of the "retoure" table.


To me this looks like a good way but the warning says something else.  
I tried to change the mapping so that the actual mapping will be done  
in "retoure" atrtribute and just do a "mappedBy" reference on  
"retourePositionList" but then it wont work at all. When i read the  
warning, i would exactly expect that this would work. So what am i  
doing wrong here?


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de

same @Id on mapped superclass

[Marc Logemann]

Hi,

following domain model:

@MappedSuperclass
public class BasicMetaData  {

@Id
@Column(name = "oid")
private long oid;
...
}

@Entity
@VersionColumn(name = "jdoversion")
@Table(name = "foo1")
public class MetaData1 extends BasicMetaData {
}

@Entity
@VersionColumn(name = "jdoversion")
@Table(name = "foo2")
public class MetaData2 extends BasicMetaData {
}


Now  i have a oid value of "1" in the DB for MetaData1. When i try to  
use also "1" as oid for MetaData2 and try to persist, i am getting an  
exception because Entity MetaData1 is somehow in the same "ID space".  
So is it correct that one cant define an ID field in a mapped  
Superclass when the IDs have their own "counter".


In this example, OpenJPA even thinks that MetaData2 is a detached  
instance of type MetaData1 because it looks in its cache and sees an  
OID with value 1 but for  complete different entity.


To make it short? I must define the OID field on the subclasses right?


Marc

Re: FilterListener again

[Marc Logemann]

I just got my own message again in the list which i sent some days  
ago if other also got this, please ignore, this one is already  
disussed 


Marc



Am 03.03.2009 um 18:29 schrieb Marc Logemann:


Hi,

ok, since feebdack on this one doesnt seem to work out and i only  
found fragments of a functionality i was sure that is in the current  
release of openJPA, i found out that FilterListener was just dropped  
out in terms of features (it was there when this product was called  
Kodo).


There "was" a documentation regarding all this which you can see here:
http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_enterprise_queryext.html#ref_guide_enterprise_queryext_jdoql

But as it seems, nobody cared so far to implement this in the  
current JPQL parser. And thats where the fun starts because i always  
thought that a Kodo->OpenJPA migration is a no brainer. Its really  
sad because the backend site of this feature (Filter Extensions)  
should be there and only because the JPQL parser (compared to the  
JDO Parser back in Kodo) does only understand the default JPA spec  
grammar, its left out.


IMO this was a brilliant feature of Kodo. So this a hughe step  
backwards I will checkout if MethodQL helps me somehow.  
Interessting that noone (especial no Kodo user) ever mentioned this  
in the list. Cant be that i am the only one using some more advanced  
Query features of Kodo.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 03.03.2009 um 01:37 schrieb Marc Logemann:


Hi,

unfortunately i got no response on my last thread:

http://n2.nabble.com/docs-concerning-FilterListener-and-other-extension-points-td2386615.html#a2387075

Is there nobody who can help me out with FilterListener aka custom  
Functions in JPQL ? There is definitely no docs on them and no  
discussions at all


I have a query which looks like this:

  Query query = em.createQuery("select d from DP_PLZ_DA d where  
" +
  "(d.plz = ?1 and lower(d.oname24) = ?2) or (d.plz = ?1 and  
d.oname24.ext:soundex(?3))")


the soundex() function is my custom FilterListener but no matter  
how i try to call this custom function, the JPQL Parser just jumps  
into my head and complaining about the JPQL syntax.


Is there anyone on this planet who knows how to trigger custom  
functions like these?


A little bit scaring is that there is almost no community support  
on OpenJPA. Is IBM the only using it? :-)


Marc

Re: FilterListener again

[Marc Logemann]

Hi,

ok, since feebdack on this one doesnt seem to work out and i only  
found fragments of a functionality i was sure that is in the current  
release of openJPA, i found out that FilterListener was just dropped  
out in terms of features (it was there when this product was called  
Kodo).


There "was" a documentation regarding all this which you can see here:
http://people.apache.org/~mprudhom/openjpa/site/openjpa-project/manual/ref_guide_enterprise_queryext.html#ref_guide_enterprise_queryext_jdoql

But as it seems, nobody cared so far to implement this in the current  
JPQL parser. And thats where the fun starts because i always thought  
that a Kodo->OpenJPA migration is a no brainer. Its really sad because  
the backend site of this feature (Filter Extensions) should be there  
and only because the JPQL parser (compared to the JDO Parser back in  
Kodo) does only understand the default JPA spec grammar, its left out.


IMO this was a brilliant feature of Kodo. So this a hughe step  
backwards I will checkout if MethodQL helps me somehow.  
Interessting that noone (especial no Kodo user) ever mentioned this in  
the list. Cant be that i am the only one using some more advanced  
Query features of Kodo.


---
regards
Marc Logemann
http://www.logemann.org
http://www.logentis.de




Am 03.03.2009 um 01:37 schrieb Marc Logemann:


Hi,

unfortunately i got no response on my last thread:

http://n2.nabble.com/docs-concerning-FilterListener-and-other-extension-points-td2386615.html#a2387075

Is there nobody who can help me out with FilterListener aka custom  
Functions in JPQL ? There is definitely no docs on them and no  
discussions at all


I have a query which looks like this:

   Query query = em.createQuery("select d from DP_PLZ_DA d where  
" +
   "(d.plz = ?1 and lower(d.oname24) = ?2) or (d.plz = ?1 and  
d.oname24.ext:soundex(?3))")


the soundex() function is my custom FilterListener but no matter how  
i try to call this custom function, the JPQL Parser just jumps into  
my head and complaining about the JPQL syntax.


Is there anyone on this planet who knows how to trigger custom  
functions like these?


A little bit scaring is that there is almost no community support on  
OpenJPA. Is IBM the only using it? :-)


Marc

MethodQL completely broken isnt it?

[Marc Logemann]

Hi,

since Filter Extension wont work as discussed, i wanted to use  
MethodQL as explained in Chapter 9 Section 5. I used mainly the same  
stuff explained in the docs:


---

OpenJPAEntityManager oem = OpenJPAPersistence.cast(emf);
OpenJPAQuery q = oem.createQuery("openjpa.MethodQL",  
"com.xyz.Finder.getByName");


// set the type of objects that the method returns
q.setResultClass(Person.class);

// parameters are passed the same way as in standard queries
q.setParameter("firstName", "Fred").setParameter("lastName", "Lucas");

// this executes your method to get the results
List results = q.getResultList();

---

First of all, when doin this, i am getting a complaint on parameters  
like that:


  
org.apache.openjpa.persistence.ArgumentException: The parameter name  
or position "firstName" passed to execute() is not valid.  All map  
keys must be a declared parameter name or a number matching the  
parameter position. Native queries only allow the use of positional  
parameters.



Then i tried positional parameters like setParameter(1, "foo");

With that there is no exceptiom but the params parameter of the method  
signature s empty!


public static ResultObjectProvider fooMethod(StoreContext ctx,  
ClassMetaData meta, boolean subclasses,
   Map params,  
FetchConfiguration fetch);


Besides all this, i am wondering how to trigger the in-Memory Method  
exaplained in the docs later on. The method here has a different  
signature but somehow i must tell the query to use in-memory right?  
Otherwise the framework will always call the method siganture i showed  
above.


So right now i am not being able to somehow reimplement my custom  
filter extension i used with Kodo back then. MethodQL was my only hope  
to solve all this. Please comment on these bugs if they are bugs  
but i dont know how to do something wrong here


Marc

Re: cannot apply class transformer without LoadTimeWeaver

[Marc Logemann]

have just seen thats its mentioned in: 
https://issues.apache.org/jira/browse/OPENJPA-72

Its not that a hughe bug, because its only a warning which could be  
suppressed with better detection. but it has 3 votes if that means  
something :)


Marc

Am 03.03.2009 um 13:12 schrieb Marc Logemann:


Hi,

this issue was discussed by Hoeller and Linskey more than a year ago  
and its still there. See here:


http://forum.springframework.org/archive/index.php/t-44299.html

What is the solution here?

Marc

cannot apply class transformer without LoadTimeWeaver

[Marc Logemann]

Hi,

this issue was discussed by Hoeller and Linskey more than a year ago  
and its still there. See here:


http://forum.springframework.org/archive/index.php/t-44299.html

What is the solution here?

Marc

FilterListener again

[Marc Logemann]

Hi,

unfortunately i got no response on my last thread:

http://n2.nabble.com/docs-concerning-FilterListener-and-other-extension-points-td2386615.html#a2387075

Is there nobody who can help me out with FilterListener aka custom  
Functions in JPQL ? There is definitely no docs on them and no  
discussions at all


I have a query which looks like this:

Query query = em.createQuery("select d from DP_PLZ_DA d where  
" +
"(d.plz = ?1 and lower(d.oname24) = ?2) or (d.plz = ?1 and  
d.oname24.ext:soundex(?3))")


the soundex() function is my custom FilterListener but no matter how i  
try to call this custom function, the JPQL Parser just jumps into my  
head and complaining about the JPQL syntax.


Is there anyone on this planet who knows how to trigger custom  
functions like these?


A little bit scaring is that there is almost no community support on  
OpenJPA. Is IBM the only using it? :-)


Marc

Re: docs concerning FilterListener and other extension points

[Marc Logemann]

Hi,

some more detailed questions on custom functions. I found that:

http://openjpa.apache.org/builds/latest/docs/javadoc/org/apache/openjpa/jdbc/kernel/exps/JDBCWildcardMatch.html

The example in this javadoc is this line of JPAQL:

"address.street.ext:wildcardMatch (\"?ain*reet\")"

I dont bother about wildcardMatch itself but i am wondering if this  
".ext:" notation is somewhere defined. I crawled the JPA specs and  
found no reference to it. So is there a custom OpenJPA-JPAQL parser or  
something? In fact i can see no reference to custom functions in JPA  
at all. This makes me mad. Really wild guessing here.


At this point i have my custom function (aka FilterListener) installed  
via persistence.xml like this:


value="de.logentis.openjpa.LevenshteinDistanceMatch"/>


Can i go on with something like this in my JPAQL ? :

Query query = em.createQuery("select p from Person p where  
p.name.ext:levenshteinMatch(?1, 8))");


Of course my Filter accepts two arguments and returns the name of the  
written function via getTag().


Thanks for infos and when i through all this, i would love to  
contribute some examples in the examples folder of the distro!


Marc

docs concerning FilterListener and other extension points

[Marc Logemann]

Hi,

i am on the way migrating a 120+ domain classes app from Kodo (jdo) to  
OpenJPA. But since we were power users of kodo with a whole lot of  
custom functions and extensions we need to rebuild them in OpenJPA.  
Unfortunately i found no docs at all regarding this. The official  
openJPA docs contains nothing and even the examples are non-existant  
for these topics. Back in Kodo times, there were some examples for  
custom mappings and functions.


Can someone point me to something? I mean, someone should know about  
this right? :-) Even if i would start with looking into  
org.apache.openjpa.kernel.exps.StringContains which could work as  a  
blueprint, i still dont know how to register stuff.


Thanks for info on the state of affairs.

Marc