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:49:59 -0400

On 14/03/2012 12:18 PM, Gordon Yorke wrote:
> 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

No, by default it is false (but I hope that is what you mean?)

> and so by default scanning by the provider must be *enabled*.

Correct.

> The scanning the container performs is defined elsewhere.

We're not talking about container scanning, just provider scanning.

> 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.

Yes. So far you have mostly just restated what I said above, so we're
good up to this point :-)

> Requiring an orm.xml file just to list the converter classes seems out
> of place.

Putting mapping information in our mapping file is exactly the right
place, and is the way we designed it from the beginning. Listing them in
with the entities/embeddables and mapped superclasses is clearly more
convenient, but not architecturally the correct place for them to be. I
guess we need to decide whether we want to go with architectural
consistency or convenience. Both have merits and are valid arguments.