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 <[EMAIL PROTECTED]> 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 <[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
