users@jpa-spec.java.net

[jpa-spec users] [jsr338-experts] Re: updated spec draft (converters)

From: michael keith <michael.keith_at_oracle.com>
Date: Wed, 14 Mar 2012 12:11:16 -0400

>>>>> I've uploaded a draft of the spec with the attribute converter
>>>>> additions to the document
>>>>> downloads area, http://java.net/projects/jpa-spec/downloads.
>>>>>
>>>>> The converter changes can be found in sections 3.7, 10.5, and
>>>>> 11.1.10-11.
>>>>>
>>>>> The following open issues are pending:
>>>>>
>>>>> * Conversion of @Id and @Version.
>>>>>
>>>>> * Explicit listing of converters in persistence.xml file. I'm
>>>>> not sure I understand what
>>>>> was being proposed here.
>>>>
>>>> When the archive is not scanned (it's an option in
>>>> persistence.xml), the provider has no way of finding the list of
>>>> converters unless the user explicitly list them in persistence.xml
>>>> like it does list classes.
>>>>
>>>
>>> OK, thanks -- so would you propose that they simply be listed using
>>> the class element?
>>
>> These are O/R mapping classes. Why would they be listed in
>> persistence.xml? The flag to not scan for annotations (the
>> xml-mapping-metadata-complete option) is in the orm.xml mapping file,
>> that is where I would expect to specify these when not using
>> annotations, right?
> but the flag that controls scanning for persistence related classes is
> in the persistence.xml file as is the list of persistence related
> classes. By default the provider is not allowed to scan for classes.
> Many deployments occur without any orm.xml.
There is an exclude-unlisted-classes setting in the persistence.xml file
that *disables* scanning for entities, embeddables and mapped
superclasses, but by default the provider is supposed to scan (when
running in a container - outside the container it is not defined). This
option was only added to enable a persistence unit to disable some
classes from being considered even though they were in the same JAR.
In any case, my point was that this is an object-relational mapping
class and by design we have always tried to keep the O/R mapping
concepts in the orm.xml file (when we are talking about not relying upon
the annotation sensing, which I believe was the point).