Re: JIRA / svn integration

Could be. I just checked my recent reports and they all have SVN Changes. I guess I just have to be more patient... :-) Kevin On 2/8/07, Patrick Linskey [EMAIL PROTECTED] wrote: Maybe just latency? The JIRA plugin periodically scans, I think. Maybe you just checked at a bad time? -Patrick

[jira] Created: (OPENJPA-137) Perform parameter validation for annotated callback methods

Perform parameter validation for annotated callback methods --- Key: OPENJPA-137 URL: https://issues.apache.org/jira/browse/OPENJPA-137 Project: OpenJPA Issue Type: Sub-task

[jira] Resolved: (OPENJPA-133) Can't find non-public callback methods with superclass or interface parameters

[ https://issues.apache.org/jira/browse/OPENJPA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Sutter resolved OPENJPA-133. -- Resolution: Fixed Modified the processing of the getMethod() method to find the designated

[jira] Created: (OPENJPA-138) More performance improvements for OpenJPA (lib and kernel)

More performance improvements for OpenJPA (lib and kernel) -- Key: OPENJPA-138 URL: https://issues.apache.org/jira/browse/OPENJPA-138 Project: OpenJPA Issue Type: Sub-task

Re: Bug in insert of bidirectionally mapped many-to-one relationships

Jeff- I don't think optional is being ignored ... if you try to commit an instance where testLookup is null, I bet we'll throw an exception as expected at commit time. It almost sounds as if we are identifying a circular foreign key, and so are issuing the key-linking update statement

Re: Bug in insert of bidirectionally mapped many-to-one relationships

Jeff- I was just reminded that we don't actually do any SQL statement re- ordering in order to optimize foreign key constraints in OpenJPA (this was one of the hold-backs from the contribution). We will always insert in the order in which you persist the instances. If you do tell OpenJPA

Re: Bug in insert of bidirectionally mapped many-to-one relationships

Just about right. When the SchemaFactory setting is enabled the update statement occurs regardless of the way I mark the many to one relationship optional attribute. Without the SchemaFactory setting, no update statement is ran only inserts, and the order is dependent on which object you

[jira] Commented: (OPENJPA-135) join fetch not returning duplicate references which not conforming to ejb3.0 spec

[ https://issues.apache.org/jira/browse/OPENJPA-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471518 ] Craig Russell commented on OPENJPA-135: --- Would it be possible for you to attach a simple test case to this

Why do we capture the call stack when close() is called?

Hi, I've noticed that we capture the current call stack (via an IllegalStateException creation) when close() is invoked on the AbstractBrokerFactory and when free() is invoked on BrokerImpl. Then, if or when assertOpen fails we include this exception (and call stack) as the cause of a new

Re: [jira] Created: (OPENJPA-126) EntityManagers cannot be serialized

Patrick, How do you see this feature be used? The only realistic/official usage I can see is during stateful session bean passivation in the EJB container. However there are also wording on the condition passivation can apply. E.g. In ejb-3_0-fr-spec-ejbcore.pdf Section 4.2. - A container may

RE: [jira] Created: (OPENJPA-126) EntityManagers cannot be serialized

How do you see this feature be used? The only realistic/official usage I can see is during stateful session bean passivation in the EJB container. Agreed; this will probably cover the majority of use cases. I imagine people would potentially use the feature with just straight HTTP sessions,

[jira] Commented: (OPENJPA-138) More performance improvements for OpenJPA (lib and kernel)

[ https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471535 ] Kevin Sutter commented on OPENJPA-138: -- To give everyone a heads up on the type of changes I plan to introduce

[jira] Created: (OPENJPA-139) PersistenceException merging an entity with a Calendar field.

PersistenceException merging an entity with a Calendar field. -- Key: OPENJPA-139 URL: https://issues.apache.org/jira/browse/OPENJPA-139 Project: OpenJPA Issue Type: Bug

[jira] Commented: (OPENJPA-138) More performance improvements for OpenJPA (lib and kernel)

[ https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471537 ] Patrick Linskey commented on OPENJPA-138: - Cache the Class instances for Configurations.newInstance()

Re: Why do we capture the call stack when close() is called?

On Feb 8, 2007, at 3:32 PM, Patrick Linskey wrote: It's there for debugging purposes. We could probably check for TRACE-level logging; if not enabled, the exception would not be created and the assertion would include a localized string instructing the user to turn on TRACE logging to get

[jira] Commented: (OPENJPA-138) More performance improvements for OpenJPA (lib and kernel)

[ https://issues.apache.org/jira/browse/OPENJPA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471580 ] Kevin Sutter commented on OPENJPA-138: -- Thanks for the insights, Patrick. Here are some new observations and

[VOTE] Move JPA API dependency from dev.java.net to geronimo version

It turns out that the JPA API we've been building against (the one from https://maven-repository.dev.java.net/repository/ javax.persistence/jars/persistence-api-1.0.jar) is not actually the final version of the spec: there are some minor (and binary- compatible) changes (some annotations