Return-Path: 
 <dev-return-5950-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org>
Delivered-To: apmail-openjpa-dev-archive@www.apache.org
Received: (qmail 52016 invoked from network); 28 Aug 2007 16:54:48 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 28 Aug 2007 16:54:48 -0000
Received: (qmail 86257 invoked by uid 500); 28 Aug 2007 16:54:43 -0000
Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org
Received: (qmail 86236 invoked by uid 500); 28 Aug 2007 16:54:43 -0000
Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@openjpa.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@openjpa.apache.org>
List-Post: <mailto:dev@openjpa.apache.org>
List-Id: <dev.openjpa.apache.org>
Reply-To: dev@openjpa.apache.org
Delivered-To: mailing list dev@openjpa.apache.org
Received: (qmail 86227 invoked by uid 99); 28 Aug 2007 16:54:43 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 09:54:43 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of kwsutter@gmail.com designates
 64.233.182.189 as permitted sender)
Received: from [64.233.182.189] (HELO nf-out-0910.google.com) (64.233.182.189)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Aug 2007 16:54:38 +0000
Received: by nf-out-0910.google.com with SMTP id b2so1525281nfb
        for <dev@openjpa.apache.org>; Tue, 28 Aug 2007 09:54:17 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Sp8wQMk2HpSIHE9miuUTMDw4ceoEoOaNyjh9Sdx5pHIgM8busu7qcBrqt+3xKM1sFPK/mBVAxQZKtdL4IViNZffe9b8GaA7ph1zN1IYaWYQwIAthEVG4mehectqVcWDI1g8fC/eTVD4clVe4UXFOZ03K4VKPMK/vRASovS+HRL4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=gUC79xBNYMsQq9TYHyucI+Ypl+wn9es5JN5nXaWIaF1uN1nIPusG50zQG4/lNFn18ygbuP7tyPbe7+sop/jpR0S9zlKZx5NBuOexNr9zkZ+xFw6VpSp6NlB9COkA3Xne3casQ5PtKRVrKlfzMcdLoYYRKTaen02P7N3dtv9hPR8=
Received: by 10.115.32.1 with SMTP id k1mr1331900waj.1188320054687;
        Tue, 28 Aug 2007 09:54:14 -0700 (PDT)
Received: by 10.114.75.15 with HTTP; Tue, 28 Aug 2007 09:54:14 -0700 (PDT)
Message-ID: <89c0c52c0708280954v10072b80o10667aa023a5408b@mail.gmail.com>
Date: Tue, 28 Aug 2007 11:54:14 -0500
From: "Kevin Sutter" <kwsutter@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: multiple xml mapping files found on classpath
In-Reply-To: <7262f25e0708280933s61d1f79aqefdf3306a60b4384@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_134707_1457920.1188320054658"
References: <89c0c52c0708280924n6cd682d7i8cca8cfac49adde4@mail.gmail.com>
	 <7262f25e0708280933s61d1f79aqefdf3306a60b4384@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_134707_1457920.1188320054658
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 8/28/07, Patrick Linskey <plinskey@gmail.com> 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 <kwsutter@gmail.com> 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
>

------=_Part_134707_1457920.1188320054658--