As I read this thread, I keep thinking of package annotations in
package-info.java for global (or near-global, maybe for the annotated
package and optionally subpackages) configuration. Could this help
out here?
On Wed, Mar 14, 2012 at 3:07 PM, michael keith <michael.keith_at_oracle.com> wrote:
> On 14/03/2012 3:14 PM, Linda DeMichiel wrote:
>>
>>
>> On 3/14/2012 12:09 PM, michael keith wrote:
>>>
>>> That would certainly be consistent.
>>> Not as convenient, but definitely consistent :-)
>>>
>>> Another approach would be to go back to defining the annotation on an
>>> entity (i.e. like named queries, id generators and
>>> many other global things that we already define) and point to the
>>> converter class.
>>>
>>
>> That seems to me much less convenient. Unlike named queries (which are
>> just strings,
>> rather than objects), we don't need a class to attach converters to in
>> order to
>> define them outside of XML.
>>
>
> It's true, but there's something to be said for having a path to the class
> from a managed class.
>
>
>>> Example:
>>>
>>> @Converter(class=MyConverter.class autoApply=true)
>>> @Entity
>>> public class Employee { ... }
>>>
>>>
>>> On 14/03/2012 2:36 PM, Linda DeMichiel wrote:
>>>>
>>>> Currently @Converter has only one attribute, autoApply, although
>>>> we have open issues around scoping (extending to subclasses, etc).
>>>>
>>>> It occurs to me that we could approach autoApply converters as we
>>>> do default entity listeners, and require them to be listed in the
>>>> orm.xml. If we did this, we could dispense with the @Converter
>>>> annotation until such time as we needed it to further refine the
>>>> semantics.
>>>>
>>>> Opinions? Fire away :-)
>>>>
>>>> -Linda
>>>>
>>>>
>>>> On 3/14/2012 10:37 AM, 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 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.
>>>>
>>>>
>>
>
--
@matthewadams12
mailto:matthew_at_matthewadams.me
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12_at_gmail.com
msn:matthew_at_matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams