On 14/03/2012 1:49 PM, michael keith wrote:
>
> 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?)
No, the default is true : "<xsd:element name="exclude-unlisted-classes"
type="xsd:boolean" default="true" minOccurs="0">" and portable Java SE
applications must list all managed persistence classes (section 8.2.1.6.4) .
>
>> 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 :-)
No, we disagree on whether @Converter classes will always be
discovered. Emmanuel's point and my point is that by default in Java SE
there is no way for a provider to find the *annotated* auto-apply
Converter classes. Users should have the option of listing the
annotated Converter classes within the list of managed classes in the
persistence.xml file.
>
>> 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 do not believe anyone is proposing listing converter classes within
other managed classes (ie .entities/embeddables and mapped
superclasses). That seems out of place to me.
> I guess we need to decide whether we want to go with architectural
> consistency or convenience. Both have merits and are valid arguments.
If it is architecturally inconsistent then why have the list of
annotated managed classes at all in the persistence.xml file ? There is
nothing inconsistent about continuing a configuration pattern that is
already defined in the specification.
For clarity, an element for converters should still be added to the
persistence-unit element in orm.xml for un-annotated classes but I
assumed that would be added later when the xsds are updated.