Skip to main content

[jsr338-experts] Re: updated spec draft (converters)

  • From: Emmanuel Bernard <emmanuel.bernard@...>
  • To: jsr338-experts@...
  • Subject: [jsr338-experts] Re: updated spec draft (converters)
  • Date: Fri, 16 Mar 2012 16:20:16 +0100

It could, Hibernate uses something like that but you still need to list the 
packages when scanning is disable. Back to square one :)

On 15 mars 2012, at 01:21, Matthew Adams wrote:

> 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@...> 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@...
> skype:matthewadams12
> yahoo:matthewadams
> aol:matthewadams12
> google-talk:matthewadams12@...
> msn:matthew@...
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams



[jsr338-experts] Re: updated spec draft (converters)

(continued)

[jsr338-experts] Re: updated spec draft (converters)

Gordon Yorke 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

michael keith 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

Gordon Yorke 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

michael keith 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

Gordon Yorke 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

Linda DeMichiel 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

michael keith 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

Linda DeMichiel 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

michael keith 03/14/2012

[jsr338-experts] Re: updated spec draft (converters)

Matthew Adams 03/15/2012

[jsr338-experts] Re: updated spec draft (converters)

Emmanuel Bernard 03/16/2012

[jsr338-experts] Re: updated spec draft (converters)

Emmanuel Bernard 03/16/2012

[jsr338-experts] Re: [jpa-spec users] Re: updated spec draft (converters)

michael keith 03/14/2012
 
 
Close
loading
Please Confirm
Close