<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. I can see a strong case for throwing an exception if multiple resources are found, also -- that would be my second preference. 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
