On 14/03/2012 1:49 PM, michael keith wrote:
No, the default is true : "<xsd:element name="exclude-unlisted-classes"
On 14/03/2012 12:18 PM, Gordon Yorke wrote:
On 14/03/2012 1:11 PM, michael keith wrote:
exclude-unlisted-classes is true by default
There is an exclude-unlisted-classes setting in the persistence.xml file thatbut the flag that controls scanning for persistence related classes is in theI've uploaded a draft of the spec with the attribute converter additions to
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
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
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?
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.
*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).
No, by default it is false (but I hope that is what you mean?)
minOccurs="0">" and portable Java SE applications must list all managed
persistence classes (section 126.96.36.199.4) .
No, we disagree on whether @Converter classes will always be discovered.
and so by default scanning by the provider must be *enabled*.
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 :-)
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.
I do not believe anyone is proposing listing converter classes within other
Requiring an orm.xml file just to list the converter classes seems out of
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.
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 architecturalIf it is architecturally inconsistent then why have the list of annotated
consistency or convenience. Both have merits and
are valid arguments.
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.
[jsr338-experts] Re: updated spec draft (converters)