I definitely like our current handling. I do think that the spec makes it a bit vague by mentioning that the names should be 'unique'. However, the spec certainly does not indicate that what we're doing is flagrantly incorrect.
-Patrick On 8/28/07, Kevin Sutter <[EMAIL PROTECTED]> wrote: > > Patrick, > I'm coming to a slightly different conclusion from the javadoc and spec... > > On 8/28/07, Patrick Linskey < [EMAIL PROTECTED]> wrote: > > > > 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. > > > The javadoc above indicates that the mapping files are > "resource-loadable". > And, section " 6.2.1.6 <http://6.2.1.6> mapping-file, jar-file, class, > exclude-unlisted-classes" of the JPA spec has the following sentence: "An > orm.xml file or other mapping file is loaded as a resource by the > persistence provider." > > Both of these references indicate that the mapping files should be treated > as "resources". Thus, I think our current processing of looking for all > instances via the classloader and merging the contents is the correct > processing. No exception processing should be considered. This > processing > would be consistent with our persistence.xml and orm.xml processing. > > Agree? > > Kevin > > -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 > > > -- Patrick Linskey 202 669 5907
