Skip to main content

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

  • From: michael keith <michael.keith@...>
  • To: jsr338-experts@...
  • Cc: Gordon Yorke <gordon.yorke@...>
  • Subject: [jsr338-experts] Re: updated spec draft (converters)
  • Date: Wed, 14 Mar 2012 12:49:59 -0400
  • Organization: Oracle Corporation


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.


[jsr338-experts] updated spec draft (converters)

Linda DeMichiel 03/07/2012

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

Emmanuel Bernard 03/12/2012

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

Linda DeMichiel 03/12/2012

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

Emmanuel Bernard 03/13/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)

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