Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of plinskey@gmail.com designates
 64.233.166.179 as permitted sender)
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:content-transfer-encoding:content-disposition:references;
        b=buDDzxW5wZOpD6fIxBgnR751HUhq7DDGOb3zZhBXsk/KLlS05AkSMXq6XJf5IU54j4xLPipenFL3XH+ztBDVJDi6WBV5PUUOW1HeTocZvPhsxPjx3tuk963vCfIDrUe7YmMY1vpuxl1waYo4bEDv+uZ8NNyBjOFM3vdrWgf0Qy8=
Message-ID: <7262f25e0708291148q2a9ed5bdif911100df46bd350@mail.gmail.com>
Date: Wed, 29 Aug 2007 11:48:56 -0700
From: "Patrick Linskey" <plinskey@gmail.com>
To: dev@openjpa.apache.org
Subject: Re: multiple xml mapping files found on classpath
In-Reply-To: <46D5B991.3020108@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <89c0c52c0708280924n6cd682d7i8cca8cfac49adde4@mail.gmail.com>
	 <89c0c52c0708280954v10072b80o10667aa023a5408b@mail.gmail.com>
	 <7262f25e0708281030tc3a5e06o842a2139471d172c@mail.gmail.com>
	 <89c0c52c0708281458y20430e8dw2d165d0420e7da00@mail.gmail.com>
	 <7262f25e0708281501o19f79ee5o27c318b181fa85dc@mail.gmail.com>
	 <46D52CED.5050400@Sun.COM>
	 <7262f25e0708290912x29c67801wae82e1597719d140@mail.gmail.com>
	 <46D59E32.6050102@Sun.COM>
	 <7262f25e0708291031s26f66880wa9314034c274af1b@mail.gmail.com>
	 <46D5B991.3020108@Sun.COM>

> Since PURoot URI can be calculated

How, portably?

> BTW, I did not understand what you meant by "manual specification of
> orm.xml files."

I meant that the user can specify different XML file URLs, which they
can then ensure are unique.

-Patrick

On 8/29/07, Sahoo <Sahoo@sun.com> wrote:
> I think it is possible. Since PURoot URI can be calculated, one can use
> java.net.URI API to get an absolute URI from the relative URI
> "META-INF/orm.xml," and read the resource. About orm.xml files in
> related jar files, does OpenJPA support this in non-container
> environment? The spec (see persistence_1_0.xsd) says jar-file element is
> not applicable for non-container environment. If a provider wants to
> support it, I think it should first get URIs for each referenced jar
> file, and it can then use java.util.JarFile API to read "META-INF/orm.xml."
>
> BTW, I did not understand what you meant by "manual specification of
> orm.xml files."
>
> Thanks,
> Sahoo
>
> plinskey@gmail.com wrote:
> > Yes, but here is no portale way to disambiguate in the non-container
> > enment (that I am aware of, at least). If the user has so configured
> > the classpath, and wants isolation, the manual specification of
> > orm.xml files is always available.
> >
> > Things are different, of course, in the in-container case.
> >
> > -Patrick
> >
> > On 8/29/07, Sahoo <Sahoo@sun.com> wrote:
> >
> >> Patrick Linskey wrote:
> >>
> >>>> By the way, how does OpenJPA search the default mapping
> >>>> file(META-INF/orm.xml)? I hope it does not search using
> >>>> ClassLoader.getResources() API.
> >>>>
> >>>>
> >>> I would assume that we use a call like that at some point in the
> >>> non-container environment... why?
> >>>
> >>>
> >> Depending on user's classpath settings, getResources("META-INF/orm.xml")
> >> can potentially return more number of resources than what the provider
> >> should be looking at.
> >>
> >> Thanks,
> >> Sahoo
> >>
> >>> -Patrick
> >>>
> >>> On 8/29/07, Sahoo <sahoo@sun.com> wrote:
> >>>
> >>>
> >>>> This is yet another source of non-portability of JPA applications. I
> >>>> know about a fairly widely used, spec compliant JPA provider which
> >>>> behaves very differently in this scenario. Its *default* behavior is to
> >>>> throw an exception. It can be configured to just log a warning and
> >>>> continue using the first available resource by that name - which I agree
> >>>> is a very dangerous option for reasons already mentioned in this email
> >>>> thread.
> >>>>
> >>>> I think it is worth raising this issue to the expert group so that the
> >>>> spec can be *corrected*.
> >>>>
> >>>> By the way, how does OpenJPA search the default mapping
> >>>> file(META-INF/orm.xml)? I hope it does not search using
> >>>> ClassLoader.getResources() API.
> >>>>
> >>>> Thanks,
> >>>> Sahoo
> >>>>
> >>>> Patrick Linskey wrote:
> >>>>
> >>>>
> >>>>> 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 <kwsutter@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Patrick,
> >>>>>> I'm coming to a slightly different conclusion from the javadoc and
> >>>>>>
> >> spec...
> >>
> >>>>>> On 8/28/07, Patrick Linskey < plinskey@gmail.com> 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 < kwsutter@gmail.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> Patrick Linskey
> >>>>>>> 202 669 5907
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >
>


-- 
Patrick Linskey
202 669 5907