| Summary: | RepeatableWriteUnitOfWork should not depend on javax.persistence.OptimisticLockException | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Blaise Doughan <blaise.doughan> |
| Component: | Eclipselink | Assignee: | Project Inbox <eclipselink.foundation-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | michael.f.obrien, tom.ware |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Blaise Doughan
>We already have 17 various dependencies to the JPA 2.0 plugin for other code such as the packages - annotations, config and, server(JBoss, SAP) >We should refactor or at least review all of these together with the RWOW dependency - moving RWOW could cause a large cascade of rebundling >RepeatableWriteUnitOfWork.java Line 549 rethrows as a JPA spec exception in this case /** * INTERNAL: * Wraps the org.eclipse.persistence.exceptions.OptimisticLockException in a * javax.persistence.OptimisticLockException. This conforms to the EJB3 specs * @param commitTransaction */ protected void commitToDatabase(boolean commitTransaction) { try { super.commitToDatabase(commitTransaction); } catch (org.eclipse.persistence.exceptions.OptimisticLockException ole) { > throw new javax.persistence.OptimisticLockException(ole); } } This dependency may or may not be avoidable. The problem is this dependency forces anyone using RepeatableWriteUnitOfWork to have java.persistence.jar on there classpath even if they are not using JPA. This is not a problem if JPA is the only user of this API, but if DBWS wanted to use it, then a JPA dependency would be introduced (for the sake of 1 exception). Setting target and priority. See the following page for details of what these fields mean: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |