[jira] Created: (OPENJPA-1386) Metamodel Generator does not handle field types that can hide another
Metamodel Generator does not handle field types that can hide another - Key: OPENJPA-1386 URL: https://issues.apache.org/jira/browse/OPENJPA-1386 Project: OpenJPA Issue Type: Bug Components: jpa Affects Versions: 2.0.0-M3 Reporter: Pinaki Poddar Assignee: Pinaki Poddar Fix For: 2.0.0-M4 If an entity declares fields of types that can hide each other by their simple name e.g. java.sql.Date sDate; java.util.Date uDate; Metamodel generator generates code that are not compilable because the field types are not qualified and hidden properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-1173) Update PostgreSQL support for 8.4.x
[ https://issues.apache.org/jira/browse/OPENJPA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-1173. --- Resolution: Fixed > Update PostgreSQL support for 8.4.x > --- > > Key: OPENJPA-1173 > URL: https://issues.apache.org/jira/browse/OPENJPA-1173 > Project: OpenJPA > Issue Type: Sub-task >Reporter: Tim McConnell >Assignee: Michael Dick > Fix For: 1.3.0, 2.0.0 > > Attachments: OPENJPA-1173.patch > > > Latest 8.4 drivers are out on the maven repos now... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Inner Class Entities
Hi Kevin/Pinaki, thanks to both of you for your comments. I'll investigate further to determine the full scope of this capability and document it accordingly. Pinaki Poddar wrote: Hi Tim, As those test cases demonstrate, OpenJPA can use non-anonymous inner classes as entities. At least when you are enhancing at build-time. Tim McConnell wrote: Hi, I'm wondering if there is any documentation, specifications, and/or known rules that govern the usage of Inner Classes as Entities ?? I haven't been able to find any although I do see a couple of examples of the @Entity being used on inner classes in some of the OpenJPA testcases. Unfortunately, those examples are not quite enough for me to fully understand the restrictions or implications. Thanks for any additional information... -- Thanks, Tim McConnell - Pinaki -- Thanks, Tim McConnell
[jira] Resolved: (OPENJPA-1328) Move cacheable class configuration to ClassMetaData
[ https://issues.apache.org/jira/browse/OPENJPA-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dick resolved OPENJPA-1328. --- Resolution: Fixed > Move cacheable class configuration to ClassMetaData > --- > > Key: OPENJPA-1328 > URL: https://issues.apache.org/jira/browse/OPENJPA-1328 > Project: OpenJPA > Issue Type: Bug > Components: datacache >Affects Versions: 1.2.0, 1.2.1 >Reporter: Jody Grassel >Assignee: Michael Dick > Attachments: OpenJPA_1.2.x_OJ1328.patch > > > I'm proposing to move the cacheable class configuration processing from the > datacache classes to ClassMetaData. The feature, introduced in OPENJPA-1045, > effectively works by returning null for ClassMetaData.getDataCacheName(), > where classes which should not be cached return null, otherwise the name of > the datacache they may be cached by is returned. > THe problem is that some third party datacache plugins are not reentrant, and > the existing ClassMetaData.isCacheable() makes use of the method call > getRepository().getConfiguration().getDataCacheManagerInstance(). This > invokes the initialization of the datacache, which may result in further > initialization/copying of CMD objects, which reenter the isCacheable() > method. If a third party datacache plugin is not reentrant safe, this can > cause a failure in the form of Exceptions or hung threads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Inner Class Entities
Hi Tim, As those test cases demonstrate, OpenJPA can use non-anonymous inner classes as entities. At least when you are enhancing at build-time. Tim McConnell wrote: > > Hi, I'm wondering if there is any documentation, specifications, and/or > known > rules that govern the usage of Inner Classes as Entities ?? I haven't been > able > to find any although I do see a couple of examples of the @Entity being > used on > inner classes in some of the OpenJPA testcases. Unfortunately, those > examples are > not quite enough for me to fully understand the restrictions or > implications. > Thanks for any additional information... > -- > Thanks, > Tim McConnell > > - Pinaki -- View this message in context: http://n2.nabble.com/Inner-Class-Entities-tp3994088p3996254.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
[jira] Commented: (OPENJPA-1385) Parameter in having clause of Criteria query not recognized
[ https://issues.apache.org/jira/browse/OPENJPA-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777259#action_12777259 ] Pinaki Poddar commented on OPENJPA-1385: This page not showing the SubVersion commits. But you can see it in Nabble [1]. [1] http://n2.nabble.com/svn-commit-r835628-openjpa-trunk-openjpa-persistence-src-main-java-org-apache-openjpa-persistence-cra-tc3996219.html#a3996219 > Parameter in having clause of Criteria query not recognized > --- > > Key: OPENJPA-1385 > URL: https://issues.apache.org/jira/browse/OPENJPA-1385 > Project: OpenJPA > Issue Type: Bug > Components: jpa, query >Affects Versions: 2.0.0-M3 >Reporter: Pinaki Poddar >Assignee: Pinaki Poddar > Fix For: 2.0.0-M4 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Visitor that collects query parameters ignores having clause. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-1385) Parameter in having clause of Criteria query not recognized
[ https://issues.apache.org/jira/browse/OPENJPA-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar resolved OPENJPA-1385. Resolution: Fixed > Parameter in having clause of Criteria query not recognized > --- > > Key: OPENJPA-1385 > URL: https://issues.apache.org/jira/browse/OPENJPA-1385 > Project: OpenJPA > Issue Type: Bug > Components: jpa, query >Affects Versions: 2.0.0-M3 >Reporter: Pinaki Poddar >Assignee: Pinaki Poddar > Fix For: 2.0.0-M4 > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Visitor that collects query parameters ignores having clause. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-1385) Parameter in having clause of Criteria query not recognized
Parameter in having clause of Criteria query not recognized --- Key: OPENJPA-1385 URL: https://issues.apache.org/jira/browse/OPENJPA-1385 Project: OpenJPA Issue Type: Bug Components: jpa, query Affects Versions: 2.0.0-M3 Reporter: Pinaki Poddar Assignee: Pinaki Poddar Fix For: 2.0.0-M4 Visitor that collects query parameters ignores having clause. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (OPENJPA-1380) Query not getting evicted from QueryCache
[
https://issues.apache.org/jira/browse/OPENJPA-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fay Wang closed OPENJPA-1380.
-
> Query not getting evicted from QueryCache
> -
>
> Key: OPENJPA-1380
> URL: https://issues.apache.org/jira/browse/OPENJPA-1380
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 1.2.1, 2.0.0
>Reporter: Catalina Wei
>Assignee: Fay Wang
> Fix For: 1.3.0, 2.0.0
>
>
> I'm running on OpenJPA 1.2.1
> The following query is added to the QueryCache:
> Query: org.apache.openjpa.kernel.queryi...@3afe3afe;
> candidate class: class com.ibm.usmi.datamodel.system.OperatingSystem;
> query: SELECT distinct
> OPERATINGSYSTEM1.OID,OPERATINGSYSTEM1.Guid,OPERATINGSYSTEM1.ObjectType,OPERATINGSYSTEM1.Name,REMOTESERVICEACCESSPOINT1.OID,REMOTESERVICEACCESSPOINT1.Guid,REMOTESERVICEACCESSPOINT1.ObjectType,REMOTESERVICEACCESSPOINT1.Name
> FROM OperatingSystem
> OPERATINGSYSTEM1,System_accessedVia_RemoteServiceAccessPoint
> SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1,RemoteServiceAccessPoint
> REMOTESERVICEACCESSPOINT1,RelationshipInfo RELATIONSHIPINFO1 WHERE
> OPERATINGSYSTEM1.OID = SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1.sourceId
> AND REMOTESERVICEACCESSPOINT1.OID =
> SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1.targetId AND
> (OPERATINGSYSTEM1.Guid = ?1) AND (OPERATINGSYSTEM1.OID = ?2) AND
> ((OPERATINGSYSTEM1.BuildNumber = ?3)) AND (REMOTESERVICEACCESSPOINT1.Guid =
> ?4) AND (REMOTESERVICEACCESSPOINT1.OID = ?5) AND
> ((REMOTESERVICEACCESSPOINT1.Port = ?6)) AND RELATIONSHIPINFO1.changedDate >
> ?7 and RELATIONSHIPINFO1.sourceOID=OPERATINGSYSTEM1.OID and
> RELATIONSHIPINFO1.relationshipType = ?8 and
> RELATIONSHIPINFO1.targetOID=REMOTESERVICEACCESSPOINT1.OID
> Later on, a record in RelationshipInfo is changed, which changes what should
> be returned from this query. I'd expect this to cause the cached query to
> get evicted from the QueryCache, but it is not. If I get the
> QueryResultCache, and evictAll RelationshipInfo.class, it still doesn't get
> removed. This seems to be because the AccessPath only contains
> OperatingSystem. I'd expect this to contain all entities that this query
> deals with:
> {OperatingSystem,
> System_accessedVia_RemoteServiceAccessPoint, RemoteServiceAccessPoint,
> RelationshipInfo}
> But the AccessPath only seems to contain the entity of what is returned from
> the query.
> What do I need to do so this query gets evicted like I'd expect.
> This problem can be easily reproduced by the following query:
> String jpql = "select p.name, c.name from OneOneParent p, OneOneChild c
> where " +
> "p.id = c.id and c.name = ?1";
> The query cache key is:
> "org.apache.openjpa.datacache.query...@d11db9a4
> [
> query:[select p.name, c.name from OneOneParent p, OneOneChild c where
> p.id = c.id and c.name = ?1],
> access path:[queryCache.OneOneParent],
> subs:true,
> ignoreChanges:false,
> startRange:0,
> endRange:9223372036854775807,timeout:-1
> ]".
> This problem can be resolved if access path in QueryKey also contains
> queryCache.OneOneChild.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OPENJPA-1380) Query not getting evicted from QueryCache
[
https://issues.apache.org/jira/browse/OPENJPA-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fay Wang reopened OPENJPA-1380:
---
> Query not getting evicted from QueryCache
> -
>
> Key: OPENJPA-1380
> URL: https://issues.apache.org/jira/browse/OPENJPA-1380
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 1.2.1, 2.0.0
>Reporter: Catalina Wei
>Assignee: Fay Wang
> Fix For: 1.3.0, 2.0.0
>
>
> I'm running on OpenJPA 1.2.1
> The following query is added to the QueryCache:
> Query: org.apache.openjpa.kernel.queryi...@3afe3afe;
> candidate class: class com.ibm.usmi.datamodel.system.OperatingSystem;
> query: SELECT distinct
> OPERATINGSYSTEM1.OID,OPERATINGSYSTEM1.Guid,OPERATINGSYSTEM1.ObjectType,OPERATINGSYSTEM1.Name,REMOTESERVICEACCESSPOINT1.OID,REMOTESERVICEACCESSPOINT1.Guid,REMOTESERVICEACCESSPOINT1.ObjectType,REMOTESERVICEACCESSPOINT1.Name
> FROM OperatingSystem
> OPERATINGSYSTEM1,System_accessedVia_RemoteServiceAccessPoint
> SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1,RemoteServiceAccessPoint
> REMOTESERVICEACCESSPOINT1,RelationshipInfo RELATIONSHIPINFO1 WHERE
> OPERATINGSYSTEM1.OID = SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1.sourceId
> AND REMOTESERVICEACCESSPOINT1.OID =
> SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1.targetId AND
> (OPERATINGSYSTEM1.Guid = ?1) AND (OPERATINGSYSTEM1.OID = ?2) AND
> ((OPERATINGSYSTEM1.BuildNumber = ?3)) AND (REMOTESERVICEACCESSPOINT1.Guid =
> ?4) AND (REMOTESERVICEACCESSPOINT1.OID = ?5) AND
> ((REMOTESERVICEACCESSPOINT1.Port = ?6)) AND RELATIONSHIPINFO1.changedDate >
> ?7 and RELATIONSHIPINFO1.sourceOID=OPERATINGSYSTEM1.OID and
> RELATIONSHIPINFO1.relationshipType = ?8 and
> RELATIONSHIPINFO1.targetOID=REMOTESERVICEACCESSPOINT1.OID
> Later on, a record in RelationshipInfo is changed, which changes what should
> be returned from this query. I'd expect this to cause the cached query to
> get evicted from the QueryCache, but it is not. If I get the
> QueryResultCache, and evictAll RelationshipInfo.class, it still doesn't get
> removed. This seems to be because the AccessPath only contains
> OperatingSystem. I'd expect this to contain all entities that this query
> deals with:
> {OperatingSystem,
> System_accessedVia_RemoteServiceAccessPoint, RemoteServiceAccessPoint,
> RelationshipInfo}
> But the AccessPath only seems to contain the entity of what is returned from
> the query.
> What do I need to do so this query gets evicted like I'd expect.
> This problem can be easily reproduced by the following query:
> String jpql = "select p.name, c.name from OneOneParent p, OneOneChild c
> where " +
> "p.id = c.id and c.name = ?1";
> The query cache key is:
> "org.apache.openjpa.datacache.query...@d11db9a4
> [
> query:[select p.name, c.name from OneOneParent p, OneOneChild c where
> p.id = c.id and c.name = ?1],
> access path:[queryCache.OneOneParent],
> subs:true,
> ignoreChanges:false,
> startRange:0,
> endRange:9223372036854775807,timeout:-1
> ]".
> This problem can be resolved if access path in QueryKey also contains
> queryCache.OneOneChild.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-1380) Query not getting evicted from QueryCache
[
https://issues.apache.org/jira/browse/OPENJPA-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fay Wang resolved OPENJPA-1380.
---
Resolution: Fixed
Fix Version/s: 1.3.0
> Query not getting evicted from QueryCache
> -
>
> Key: OPENJPA-1380
> URL: https://issues.apache.org/jira/browse/OPENJPA-1380
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 1.2.1, 2.0.0
>Reporter: Catalina Wei
>Assignee: Fay Wang
> Fix For: 1.3.0, 2.0.0
>
>
> I'm running on OpenJPA 1.2.1
> The following query is added to the QueryCache:
> Query: org.apache.openjpa.kernel.queryi...@3afe3afe;
> candidate class: class com.ibm.usmi.datamodel.system.OperatingSystem;
> query: SELECT distinct
> OPERATINGSYSTEM1.OID,OPERATINGSYSTEM1.Guid,OPERATINGSYSTEM1.ObjectType,OPERATINGSYSTEM1.Name,REMOTESERVICEACCESSPOINT1.OID,REMOTESERVICEACCESSPOINT1.Guid,REMOTESERVICEACCESSPOINT1.ObjectType,REMOTESERVICEACCESSPOINT1.Name
> FROM OperatingSystem
> OPERATINGSYSTEM1,System_accessedVia_RemoteServiceAccessPoint
> SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1,RemoteServiceAccessPoint
> REMOTESERVICEACCESSPOINT1,RelationshipInfo RELATIONSHIPINFO1 WHERE
> OPERATINGSYSTEM1.OID = SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1.sourceId
> AND REMOTESERVICEACCESSPOINT1.OID =
> SYSTEM_ACCESSEDVIA_REMOTESERVICEACCESSPOINT1.targetId AND
> (OPERATINGSYSTEM1.Guid = ?1) AND (OPERATINGSYSTEM1.OID = ?2) AND
> ((OPERATINGSYSTEM1.BuildNumber = ?3)) AND (REMOTESERVICEACCESSPOINT1.Guid =
> ?4) AND (REMOTESERVICEACCESSPOINT1.OID = ?5) AND
> ((REMOTESERVICEACCESSPOINT1.Port = ?6)) AND RELATIONSHIPINFO1.changedDate >
> ?7 and RELATIONSHIPINFO1.sourceOID=OPERATINGSYSTEM1.OID and
> RELATIONSHIPINFO1.relationshipType = ?8 and
> RELATIONSHIPINFO1.targetOID=REMOTESERVICEACCESSPOINT1.OID
> Later on, a record in RelationshipInfo is changed, which changes what should
> be returned from this query. I'd expect this to cause the cached query to
> get evicted from the QueryCache, but it is not. If I get the
> QueryResultCache, and evictAll RelationshipInfo.class, it still doesn't get
> removed. This seems to be because the AccessPath only contains
> OperatingSystem. I'd expect this to contain all entities that this query
> deals with:
> {OperatingSystem,
> System_accessedVia_RemoteServiceAccessPoint, RemoteServiceAccessPoint,
> RelationshipInfo}
> But the AccessPath only seems to contain the entity of what is returned from
> the query.
> What do I need to do so this query gets evicted like I'd expect.
> This problem can be easily reproduced by the following query:
> String jpql = "select p.name, c.name from OneOneParent p, OneOneChild c
> where " +
> "p.id = c.id and c.name = ?1";
> The query cache key is:
> "org.apache.openjpa.datacache.query...@d11db9a4
> [
> query:[select p.name, c.name from OneOneParent p, OneOneChild c where
> p.id = c.id and c.name = ?1],
> access path:[queryCache.OneOneParent],
> subs:true,
> ignoreChanges:false,
> startRange:0,
> endRange:9223372036854775807,timeout:-1
> ]".
> This problem can be resolved if access path in QueryKey also contains
> queryCache.OneOneChild.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-1051) [patch] Mappingtool doesn't check name conflicts if MappingDefaultsImpl is called with multiple columns.
[ https://issues.apache.org/jira/browse/OPENJPA-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777166#action_12777166 ] Ravi P Palacherla commented on OPENJPA-1051: Hi Pinaki, Thanks for your suggestions. After reviewing your comments, I agree that the current solution is a bit complex and will try to work on the solution you suggested. Regards, Ravi. > [patch] Mappingtool doesn't check name conflicts if MappingDefaultsImpl is > called with multiple columns. > > > Key: OPENJPA-1051 > URL: https://issues.apache.org/jira/browse/OPENJPA-1051 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 1.0.0, 2.0.0-M2 > Environment: OpenJPA Trunk. >Reporter: Ravi P Palacherla >Assignee: David Ezzio > Fix For: 1.1.1, 2.0.0-M2 > > Attachments: OPENJPA-1051_Trunk.patch > > > In OpenJPA implementation, it looks that > MappingDefaultsImpl.populateColumns can accept multiple columns > because it has Column[] signature. > If column name is longer than DBDictionary restriction (it's very short in > some databases. > For example, oracle max name length is 32), names are truncated. > > Because name conflict is detected based on actual Table info,given Column[] > data does not get checked. > So, if given Column[] have very long name and truncated name of these > Column[] is conflicted, > it could not be detected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-1384) ClassNotFoundException for custom DBDictionary used by EJB
[ https://issues.apache.org/jira/browse/OPENJPA-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B.J. Reed updated OPENJPA-1384: --- Attachment: OPENJPA-1384.patch In the DBDictionaryFactory.newDBDictionary method, OpenJPA tries to load the DBDictionary. Adding another catch to the code so that if a ClassNotFoundException is caught by the original attempt, then OpenJPA should try to load the class with the current thread's class loader. > ClassNotFoundException for custom DBDictionary used by EJB > -- > > Key: OPENJPA-1384 > URL: https://issues.apache.org/jira/browse/OPENJPA-1384 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 1.2.1 > Environment: EJB3 Web environment >Reporter: B.J. Reed >Assignee: B.J. Reed > Fix For: 1.2.2, 1.3.0, 2.0.0 > > Attachments: OPENJPA-1384.patch > > > Trying to use EJB3 and Servlets, I have a custom DBDictionary that I would > like to use. If I use the default DBDictionary, everything works fine. > When OpenJPA tries to load the custom DBDictionary, I get a ClassNotFound > Exception > [11/2/09 14:04:54:077 EST] 0030 BusinessExcep E CNTR0020E: EJB > threw an unexpected (non-declared) exception during invocation of method > "preLoadCache" on bean > "BeanId(STA_Test#STA_Service-EJB_Test.jar#AllowableValueEjb, null)". > Exception data: > com.siemens.soarian.se.soa.exception.SoarianUnknownException: Exception > ID: ErrorNamespace:se.sta.unknownRuntimeInRSF DisplayErrorCode:SRN1 > ErrorMessage:Exception caught at RSF in method: > > Caused by: fatal user error> org.apache.openjpa.persistence.ArgumentException: > com.siemens.soarian.se.persist.extensions.SoarianSQLServerJPADBDictionary > > at > org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:128) > > at > org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:66) > > at > org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:538) > > at > org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1265) > > at > org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:505) > > at > org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:430) > > at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:103 > at > org.apache.openjpa.conf.MetaDataRepositoryValue.instantiate(MetaDataRepositoryValue.java:68) > > at > org.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:83) > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:863) > > at > org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:854) > > at > org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:638) > > at > org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:183) > > at > org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142) > > at > org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana(EntityManagerFactoryImpl.java:192) > > at > com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:63) > > at > com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:27) > > at > com.ibm.ws.jpa.management.JPAEMPool.getEntityManager(JPAEMPool.java:126) > at > com.ibm.ws.jpa.management.JPATxEntityManager.getEMInvocationInfo(JPATxEntityManager.java:226) > > at > com.ibm.ws.jpa.management.JPAEntityManager.getDelegate(JPAEntityManager.java:367) > > at > org.apache.openjpa
[jira] Created: (OPENJPA-1384) ClassNotFoundException for custom DBDictionary used by EJB
ClassNotFoundException for custom DBDictionary used by EJB -- Key: OPENJPA-1384 URL: https://issues.apache.org/jira/browse/OPENJPA-1384 Project: OpenJPA Issue Type: Bug Components: jdbc Affects Versions: 1.2.1 Environment: EJB3 Web environment Reporter: B.J. Reed Assignee: B.J. Reed Fix For: 1.2.2, 1.3.0, 2.0.0 Trying to use EJB3 and Servlets, I have a custom DBDictionary that I would like to use. If I use the default DBDictionary, everything works fine. When OpenJPA tries to load the custom DBDictionary, I get a ClassNotFound Exception [11/2/09 14:04:54:077 EST] 0030 BusinessExcep E CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "preLoadCache" on bean "BeanId(STA_Test#STA_Service-EJB_Test.jar#AllowableValueEjb, null)". Exception data: com.siemens.soarian.se.soa.exception.SoarianUnknownException: Exception ID: ErrorNamespace:se.sta.unknownRuntimeInRSF DisplayErrorCode:SRN1 ErrorMessage:Exception caught at RSF in method: Caused by: org.apache.openjpa.persistence.ArgumentException: com.siemens.soarian.se.persist.extensions.SoarianSQLServerJPADBDictionary at org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:128) at org.apache.openjpa.jdbc.sql.DBDictionaryFactory.newDBDictionary(DBDictionaryFactory.java:66) at org.apache.openjpa.jdbc.conf.JDBCConfigurationImpl.getDBDictionaryInstance(JDBCConfigurationImpl.java:538) at org.apache.openjpa.jdbc.meta.MappingRepository.endConfiguration(MappingRepository.java:1265) at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:505) at org.apache.openjpa.lib.conf.Configurations.configureInstance(Configurations.java:430) at org.apache.openjpa.lib.conf.PluginValue.instantiate(PluginValue.java:103 at org.apache.openjpa.conf.MetaDataRepositoryValue.instantiate(MetaDataRepositoryValue.java:68) atorg.apache.openjpa.lib.conf.ObjectValue.instantiate(ObjectValue.java:83) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.newMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:863) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getMetaDataRepositoryInstance(OpenJPAConfigurationImpl.java:854) at org.apache.openjpa.kernel.AbstractBrokerFactory.makeReadOnly(AbstractBrokerFactory.java:638) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:183) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityMana(EntityManagerFactoryImpl.java:192) at com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:63) at com.ibm.ws.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:27) atcom.ibm.ws.jpa.management.JPAEMPool.getEntityManager(JPAEMPool.java:126) at com.ibm.ws.jpa.management.JPATxEntityManager.getEMInvocationInfo(JPATxEntityManager.java:226) at com.ibm.ws.jpa.management.JPAEntityManager.getDelegate(JPAEntityManager.java:367) at org.apache.openjpa.persistence.OpenJPAPersistence.cast(OpenJPAPersistence.java:63) at com.siemens.soarian.se.soa.server.EMFHelper.verifyConnectionMeetsStandards(EMFHelper.java:167) at com.siemens.soarian.se.soa.server.EMFHelper.getContainerEntityManager(EMFHelper.java:229) at com.siemens.soarian.se.soa.server.EMFHelper.getEntityManager(EMFHelper.java:109) at com.siemens.soarian.se.av.dao.AdaptabilityDAO.setupEM(AdaptabilityDAO.java:92) at
Re: Inner Class Entities
Good question, Tim. The JPA spec indicates that an Entity needs to be a top-level class (section 2.1 of JPA 2.0 spec). But, I noticed in our OpenJPA documentation that we have overridden the ability to define an Entity as final class with final methods. Section 1 [1] of the documentation indicates that OpenJPA doesn't add any restrictions to the Entity definition. So, although it's not stated, it looks like we are attempting to support inner classes due to your testcase findings. But, without proper documentation, I wouldn't count on it... If you want to test this out and write up the documentation, I'm sure the project would enjoy the help... :-) Thanks, Kevin [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#jpa_overview_pc_restrict On Thu, Nov 12, 2009 at 10:46 AM, Tim McConnell wrote: > Hi, I'm wondering if there is any documentation, specifications, and/or > known rules that govern the usage of Inner Classes as Entities ?? I haven't > been able to find any although I do see a couple of examples of the @Entity > being used on inner classes in some of the OpenJPA testcases. Unfortunately, > those examples are not quite enough for me to fully understand the > restrictions or implications. Thanks for any additional information... > -- > Thanks, > Tim McConnell >
[jira] Commented: (OPENJPA-1383) tests rely on US date formatting without setting the correct Locale
[
https://issues.apache.org/jira/browse/OPENJPA-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777073#action_12777073
]
Michael Dick commented on OPENJPA-1383:
---
Checked in changes to use DateFormat.SHORT and Locale.US - let me know if this
works for you.
> tests rely on US date formatting without setting the correct Locale
> ---
>
> Key: OPENJPA-1383
> URL: https://issues.apache.org/jira/browse/OPENJPA-1383
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions: 2.0.0-M2
>Reporter: Mark Struberg
>
> A few tests fail if built on a non-US locale (using de.AT here):
> {noformat}
> java.text.ParseException: Unparseable date: "10/01/2008 1:51 AM"
> at java.text.DateFormat.parse(DateFormat.java:337)
> at
> org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults.populate(TestJPQLMultiSelectTypedResults.java:73)
> at
> org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults.setUp(TestJPQLMultiSelectTypedResults.java:55)
> {noformat}
> tests in error:
> {noformat}
>
> testMultipleConstructor(org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults)
>
> testMultipleConstructorMixWithMultiSelect(org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults)
>
> testMultiSelect(org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults)
>
> testMultiSelect(org.apache.openjpa.persistence.criteria.results.TestTypedResults)
>
> testTypedJPQLQuery(org.apache.openjpa.persistence.criteria.results.TestTypedResults)
>
> testDateQuery(org.apache.openjpa.persistence.criteria.results.TestTypedResults)
> {noformat}
> Please manually set the proper Locale in the tests
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Inner Class Entities
Hi, I'm wondering if there is any documentation, specifications, and/or known rules that govern the usage of Inner Classes as Entities ?? I haven't been able to find any although I do see a couple of examples of the @Entity being used on inner classes in some of the OpenJPA testcases. Unfortunately, those examples are not quite enough for me to fully understand the restrictions or implications. Thanks for any additional information... -- Thanks, Tim McConnell
[jira] Commented: (OPENJPA-1248) LOB streaming does not work as expected
[ https://issues.apache.org/jira/browse/OPENJPA-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777049#action_12777049 ] Jeremy Bauer commented on OPENJPA-1248: --- Hi Milosz. I agree. It my not be worth the risk and/or effort if a huge number of changes are required to support Reader, especially given there hasn't been a request to support it on PostgreSQL. It might be a fun exercise, though. :-) Take a look at my patch for OPENJPA-1249. The bit of code that gets an underlying DBCP connection could be split out into a utility class and put to use for the PostgreSQL streaming support. The patch also includes a pom update with the connection property setting required to access the underlying DBCP connection. > LOB streaming does not work as expected > --- > > Key: OPENJPA-1248 > URL: https://issues.apache.org/jira/browse/OPENJPA-1248 > Project: OpenJPA > Issue Type: Bug > Components: jdbc >Affects Versions: 1.1.0, 1.2.0, 1.2.1, 1.3.0, 2.0.0 > Environment: Oracle, MySQL, PostgreSQL, SQL Server >Reporter: Milosz Tylenda > Attachments: failures.txt, TestReaderLob_oracle.log > > > TestReaderLob does not pass with any of the databases indicated in the test > case: Oracle, MySQL, PostgreSQL, SQL Server. TestInputStreamLob passes only > with MySQL and PostgreSQL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (OPENJPA-1381) IllegalStateException on query method call after named query is created twice.
[
https://issues.apache.org/jira/browse/OPENJPA-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Albert Lee reopened OPENJPA-1381:
-
Pinaki,
The fix works for setLockMode() but still need implementation to protect
getLockMode(). See my previous comment.
Thanks for getting this in so quickly.
Albert Lee.
> IllegalStateException on query method call after named query is created twice.
> --
>
> Key: OPENJPA-1381
> URL: https://issues.apache.org/jira/browse/OPENJPA-1381
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
>Affects Versions: 2.0.0
>Reporter: Albert Lee
>Assignee: Pinaki Poddar
> Fix For: 2.0.0-M4
>
>
> When a query method is called (e.g. setLockMode) on a named query that has
> been created twice, an IllegalStateException is thrown:
> Query q1 = em.createNamedQuery("");
>
> Query q2 = em.createNamedQuery("");
> q2.setLockMode(READ);
> 11078 test TRACE [Thread-4] Tests - Caught exception and continue:
> java.lang.IllegalStateException: Query is neither a JPQL SELECT nor a
> Criteria API query.
> 11078 test TRACE [Thread-4] DumpStack - java.lang.IllegalStateException:
> Query is neither a JPQL SELECT nor a Criteria API query.
> at
> org.apache.openjpa.persistence.QueryImpl.assertJPQLOrCriteriaQuery(QueryImpl.java:377)
> at
> org.apache.openjpa.persistence.QueryImpl.setLockMode(QueryImpl.java:396)
> at
> org.apache.openjpa.persistence.QueryImpl.setLockMode(QueryImpl.java:1)
> at
> org.apache.openjpa.persistence.lockmgr.SequencedActionsTest.launchCommonSequence(SequencedActionsTest.java:409)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (OPENJPA-1383) tests rely on US date formatting without setting the correct Locale
tests rely on US date formatting without setting the correct Locale
---
Key: OPENJPA-1383
URL: https://issues.apache.org/jira/browse/OPENJPA-1383
Project: OpenJPA
Issue Type: Bug
Affects Versions: 2.0.0-M2
Reporter: Mark Struberg
A few tests fail if built on a non-US locale (using de.AT here):
{noformat}
java.text.ParseException: Unparseable date: "10/01/2008 1:51 AM"
at java.text.DateFormat.parse(DateFormat.java:337)
at
org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults.populate(TestJPQLMultiSelectTypedResults.java:73)
at
org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults.setUp(TestJPQLMultiSelectTypedResults.java:55)
{noformat}
tests in error:
{noformat}
testMultipleConstructor(org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults)
testMultipleConstructorMixWithMultiSelect(org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults)
testMultiSelect(org.apache.openjpa.persistence.query.results.TestJPQLMultiSelectTypedResults)
testMultiSelect(org.apache.openjpa.persistence.criteria.results.TestTypedResults)
testTypedJPQLQuery(org.apache.openjpa.persistence.criteria.results.TestTypedResults)
testDateQuery(org.apache.openjpa.persistence.criteria.results.TestTypedResults)
{noformat}
Please manually set the proper Locale in the tests
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (OPENJPA-1382) make org.apache.openjpa.persistence.meta.AnnotationProcessor6 as service
[ https://issues.apache.org/jira/browse/OPENJPA-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter reassigned OPENJPA-1382: - Assignee: Pinaki Poddar > make org.apache.openjpa.persistence.meta.AnnotationProcessor6 as service > > > Key: OPENJPA-1382 > URL: https://issues.apache.org/jira/browse/OPENJPA-1382 > Project: OpenJPA > Issue Type: Improvement > Components: integration, tooling >Affects Versions: 2.0.0-M3 > Environment: windows XP,sun jdk6 >Reporter: zhouyanming >Assignee: Pinaki Poddar > Fix For: 2.0.0 > > > please add a file named "javax.annotation.processing.Processor" to > META-INF/services > file content is org.apache.openjpa.persistence.meta.AnnotationProcessor6 > otherwise we need specific classname use -processor argument > reduce > javac -processorpath openjpa-all-2.0.0-SNAPSHOT.jar -processor > org.apache.openjpa.persistence.meta.AnnotationProcessor6 *.java > to > javac -processorpath openjpa-all-2.0.0-SNAPSHOT.jar *.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (OPENJPA-1382) make org.apache.openjpa.persistence.meta.AnnotationProcessor6 as service
[ https://issues.apache.org/jira/browse/OPENJPA-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated OPENJPA-1382: -- Component/s: tooling integration Fix Version/s: 2.0.0 Remaining Estimate: (was: 0.17h) Original Estimate: (was: 0.17h) > make org.apache.openjpa.persistence.meta.AnnotationProcessor6 as service > > > Key: OPENJPA-1382 > URL: https://issues.apache.org/jira/browse/OPENJPA-1382 > Project: OpenJPA > Issue Type: Improvement > Components: integration, tooling >Affects Versions: 2.0.0-M3 > Environment: windows XP,sun jdk6 >Reporter: zhouyanming > Fix For: 2.0.0 > > > please add a file named "javax.annotation.processing.Processor" to > META-INF/services > file content is org.apache.openjpa.persistence.meta.AnnotationProcessor6 > otherwise we need specific classname use -processor argument > reduce > javac -processorpath openjpa-all-2.0.0-SNAPSHOT.jar -processor > org.apache.openjpa.persistence.meta.AnnotationProcessor6 *.java > to > javac -processorpath openjpa-all-2.0.0-SNAPSHOT.jar *.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-123) Test framework should allow tests that are expected to fail to be checked in
[ https://issues.apache.org/jira/browse/OPENJPA-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinaki Poddar resolved OPENJPA-123. --- Resolution: Fixed Fix Version/s: 2.0.0-M1 2.0.0-M2 2.0.0-M3 2.0.0-M4 We now have multiple mechanisms to suppress a test failure. > Test framework should allow tests that are expected to fail to be checked in > > > Key: OPENJPA-123 > URL: https://issues.apache.org/jira/browse/OPENJPA-123 > Project: OpenJPA > Issue Type: Bug > Components: build / infrastructure >Reporter: Patrick Linskey > Fix For: 2.0.0-M4, 2.0.0-M3, 2.0.0-M2, 2.0.0-M1 > > > Often, tests are developed before solutions are implemented. It should be > possible for us to check in such tests to svn without causing the build to > fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (OPENJPA-1047) Unique Constraint on sibling classes causes name conflict
[ https://issues.apache.org/jira/browse/OPENJPA-1047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776903#action_12776903 ] Pinaki Poddar commented on OPENJPA-1047: These commits 835292 & 293 are wrongly assigned to this issue. They actually pertains to OPENJPA-1046. > Unique Constraint on sibling classes causes name conflict > - > > Key: OPENJPA-1047 > URL: https://issues.apache.org/jira/browse/OPENJPA-1047 > Project: OpenJPA > Issue Type: Bug > Components: jpa >Affects Versions: 1.2.1 >Reporter: Pinaki Poddar >Assignee: Pinaki Poddar > Fix For: 2.0.0 > > > OpenJPA is not generating unique names for unique constraints properly. Shows > up when unique constrain is defined in sibling classes [1] > [1] > http://n2.nabble.com/UniqueConstraint-in-a-MappedSuperclass-not-working-tc2633410.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (OPENJPA-1046) Unique Constraint on MappedSupperClass causes NullPointerException
[
https://issues.apache.org/jira/browse/OPENJPA-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pinaki Poddar resolved OPENJPA-1046.
Resolution: Fixed
Fix Version/s: (was: 2.0.0)
2.0.0-M4
Commits are wrongly tagged as OPENJPA-1047
> Unique Constraint on MappedSupperClass causes NullPointerException
> --
>
> Key: OPENJPA-1046
> URL: https://issues.apache.org/jira/browse/OPENJPA-1046
> Project: OpenJPA
> Issue Type: Bug
> Components: jpa
>Reporter: Pinaki Poddar
>Assignee: Pinaki Poddar
> Fix For: 2.0.0-M4
>
>
> Defining UniqueConstraint on MappedSuperClass fails with NPE [1]
> @MappedSuperclass
> @Table(uniqueconstraint...@uniqueconstraint(columnNames={"ATTR_NAME",
> "OWNER"})})
> public abstract class Attribute {
> While it is debatable a @Table annotation is appropriate for
> @MappedSuperClass, the situation must be detected and warned more gracefully
> than a NPE.
> Also investigate whether UniqueConstraint on a MappedSuperClass should be
> supported.
> [1]
> http://n2.nabble.com/UniqueConstraint-in-a-MappedSuperclass-not-working-tc2633410.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
