On 14/03/2012 1:37 PM, Gordon Yorke wrote:
> 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
When I say the default value I am talking about what the value is
assumed to be when the element is not specified at all in the
persistence.xml file in a container environment. In that case a false
value is assumed. The "default" element in the XML schema only applies
if you say <exclude-unlisted-classes/>. It is set to true for
convenience, so one doesn't have to say
<exclude-unlisted-classes>true</exclude-unlisted-classes>.
> portable Java SE applications must list all managed persistence
> classes (section 8.2.1.6.4) .
Yes, to be portable in SE outside the container an application must
list all of the classes. We did not define whether a provider does or
doesn't do scanning. A portable application just can't assume that it does.
>>> 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.
The "exclude-unlisted-classes" option that started this whole discussion
was, as I mentioned earlier, targeted at the container scenario, so that
is what I was discussing primarily. In a container, annotation scanning
*does* take place by default, and having the entries in the XML mapping
file is only required if this option was turned on. If we can agree on
that then we can go on to discussing the situation outside the container
(when the exclude-unlisted-classes option is undefined, but when the
providers are minimally expected to use the classes listed in
persistence.xml).
> 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.
Neither was I. I said "in with", meaning "in" the <classes> element
"with" the other entities and embeddables.
>> 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.
It was where the entity objects were listed in Java SE. I guess now we
are having the discussion that you thought we were having earlier but
that I didn't know we were having? :-) The comparison still exists
between the entities and other objects, like entity listeners which
needed to be in the mapping file. The only difference is that converters
are identified by annotations.
> 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.
Sure.