The spec JavaDoc for PUImpl implies that we should throw an exception: /** * @return The list of mapping file names that the persistence * provider must load to determine the mappings for the entity * classes. The mapping files must be in the standard XML * mapping format, be uniquely named and be resource-loadable * from the application classpath. * Each mapping file name corresponds to a <mapping-file> * element in the persistence.xml file. */
Of course, this is just the JavaDoc, and doesn't comment about the XML elements directly, but it probably stands to reason that the two are equivalent. -Patrick On 8/28/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > On 8/28/07, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > > <mapping-file> identifies a resource, not a file (despite the name). > > In general, we try to handle resources on the assumption that there > > might be more than one. > > > > Personally, I think that the current behavior is the most appropriate. > > Imagine that you are working on a project that has multiple teams > > contributing XML mapping files. What happens if each team builds a > > separate jar that contributes to the same PU but creates mapping files > > with the same names? The current behavior is more tolerant of such > > configurations. > > > After I wrote up the note on this topic, I was starting to think along these > same lines. This type of processing would also be consistent with the > processing of the generic orm.xml resource. > > I can see a strong case for throwing an exception if multiple > > resources are found, also -- that would be my second preference. > > > Agree. We either have to process all discovered resources with the given > name or we have to thrown an exception. At this point, I am leaning towards > allowing the current behavior of multiple xml mapping resources. Unless > someone finds a spec reference that indicates we're doing the wrong thing... > > Kevin > > I think that just choosing one would be undesirable, since it would > > lead to relatively unpredictable / unexpected behavior (even if we > > deterministically chose the first one available or something). > > > > -Patrick > > > > On 8/28/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > > Hi, > > > In a persistence.xml, I have a specific xml mapping file identified: > > > > > > <mapping-file>OrderOfInvocationORM.xml</mapping-file> > > > > > > I am finding that our processing in AbstractCFMetaDataFactory is looking > > for > > > and processing all instances of "META-INF/OrderOfInvocationORM.xml" in > > the > > > classpath, not just the first one. It just so happens that a test > > > environment that I am processing in had multiple versions of this file > > > available in the classpath (both my ejb and web modules). This multiple > > xml > > > mapping file processing surprised me. > > > > > > I understand where we need to search for multiple versions of the > > generic > > > "META-INF/orm.xml" file in the classpath, but I would have expected that > > we > > > only process a single instance of a specific named xml mapping file. > > > > > > Of course, you could argue that if you do have multiple copies available > > on > > > the classpath and we're only supposed to process one of them, which one > > do > > > we process? First, last, all of them as we do today? > > > > > > I've read through the spec and the Pro EJB3 book and although they imply > > a > > > single file will be processed, it's not explicit. So, I'm looking for > > any > > > other interpretations or findings in the spec that would indicate > > whether we > > > are processing correctly or not. > > > > > > Thanks, > > > Kevin > > > > > > > > > -- > > Patrick Linskey > > 202 669 5907 > > > -- Patrick Linskey 202 669 5907
