On 14/03/2012 1:11 PM, michael keith wrote:
>
>>>>>> 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).
exclude-unlisted-classes is true by default and so by default scanning
by the provider must be *enabled*. The scanning the container performs
is defined elsewhere. The only thing being discussed here is the auto
scanning and how the provider should be notified of the converter
classes when scanning is not enabled. Requiring an orm.xml file just to
list the converter classes seems out of place.