Speaking of JPA 2.1 and Hibernate... please let me know off-list if you'd like to be reviewer for Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> ?
Thank you, Gary On Mon, May 6, 2013 at 11:22 AM, Nick Williams < [email protected]> wrote: > Thanks. I will keep both in mind. 4.3-beta3 should be out May 22. > > Nick > > On May 6, 2013, at 9:59 AM, Gary Gregory wrote: > > Yes, this is all good stuff, JPA 2.1 it is but: > > - Be aware that this Hibernate 4.3-beta1 bug might trip you up: > https://hibernate.atlassian.net/browse/HHH-8111 > - There is a Hibernate 4.3-beta2 bug that causes Java 7 to be required to > run certain kind of code, this should be fixed in the next beta. > > Gary > > > > > On Mon, May 6, 2013 at 10:49 AM, Nick Williams < > [email protected]> wrote: > >> If it would in theory work, we wouldn't actually need separate jpa20 and >> jpa21 packages, we could just create two entities, one for JPA 2.0 and one >> for JPA 2.1. My concern is that JPA providers scan the class path looking >> for entity annotations, and when a JPA 2.0 provider caused any of the >> @Convert-annotated classes to be loaded by the class loader, a >> NoClassDefFoundError would occur. >> >> Additionally, in order to achieve this we would need the JPA 2.1 spec on >> the class path during compile, and it would be impossible to prevent >> developers from accidentally using 2.1 API features in parts that we >> intended to use 2.0 API features only. >> >> The alternative would be to have "yet another jar" by moving the JPA >> appenders into separate modules ... one for JPA 2.0 and one for JPA 2.1. I >> don't think anyone here really likes that idea. >> >> No, I think we have to pick one and stick with it. Like I said, by the >> time Log4j 2 is released JPA 2.1 and a non-beta Hibernate 4.3 will be >> generally available (for that matter, Hibernate 5 is supposed to be out by >> the end of this year). Anyone who adopts Log4j 2 and wants to use the JPA >> Appender within 6-9 months of Log4j 2 release are very early adopters who >> most likely will also adopt JPA 2.1 early or will be willing to. By the >> time Log4j 2 turns a year old, JPA 2.1 will be the norm and JPA-next will >> be in progress. >> >> Also, important note I just found: Any Hibernate versions < 4.0 are >> considered archived and not supported. This means that for any Hibernate >> users using supported Hibernate versions (4.0+), the upgrade to JPA 2.1 >> will be a minor upgrade. No major upgrades required. I think that makes >> this much more palatable. >> >> Nick >> >> >> On May 6, 2013, at 9:27 AM, Gary Gregory wrote: >> >> Nice write up. I'm fine relying on JPA 2.0 as the minimum, I'm not so >> sure about 2.1; it is barely off the press and there is no released >> implementation yet, just a beta; Hibernate 4.3-beta2 just came out a couple >> of days ago. >> >> What about a jpa20 and jpa21 package? >> >> Gary >> >> >> On Mon, May 6, 2013 at 8:50 AM, Nick Williams < >> [email protected]> wrote: >> >>> As I wait on the beta6 release process to complete so that Ralph can >>> commit my first pass at the JDBC, JPA, and NoSQL Appenders, I wanted to >>> start a discussion about the JPA appender and JPA 2.1. (For reference, you >>> can see the new feature request here [1], and there is a patch attached to >>> that feature request containing my first pass at the Appenders.) >>> >>> Currently, the patch includes a JPA appender that requires JPA 2.0. >>> Hibernate isn't the only JPA provider out there, but since it's the most >>> popular I'll use it as an example here. Hibernate 3.5.0 or higher is >>> required for JPA 2.0 support. JPA 1 had a major drawback that caused it to >>> receive a lot of criticism from the community (including me): There was no >>> way to specify custom type converters, so if you had some kind of special >>> type (like a StackTraceElement, or a Marker, or a Message) that you wanted >>> to support you *had* to use a provider-proprietary API to do it, or >>> convert the value manually within the getter and setter. Many (again, >>> including me) were outraged when JPA 2.0 came out and it STILL did not have >>> support for custom types. >>> >>> So, when I created the JPA appender I created an abstract class >>> implementing LogEvent called LogEventWrapperEntity. This class provides >>> no-op setters to complement all of the getters defined in the interface >>> (because JPA requires setters, but we don't need them because log events >>> will be write-only). However, the end-user MUST implement ALL of the >>> getters specified in the LogEvent interface, because how these values are >>> converted will depend on which provider they use. I'm not 100% happy with >>> that, but it works. >>> >>> Enter JPA 2.1, whose final draft was approved two weeks ago and will be >>> released final literally any day now, and finally there is a way to specify >>> custom converters without depending on provider-specific APIs >>> (@javax.persistence.Convert and javax.persistence.AttributeConverter). >>> Using these, I could create AttributeConverters for StackTraceElement, >>> Throwable, Message, Marker, Level, Map<String, String>, >>> and ThreadContext.ContextStack. I could then create a more complete entity >>> with all of the getters already defined using default column names. Then, >>> if someone wanted to change one or more column names, they would only need >>> to override the getters whose column names they wanted to change, and they >>> wouldn't have to worry about type conversion. It would make using the JPA >>> Appender MUCH easier. >>> >>> Since JPA 2.1 is a minor version, this shouldn't so much be a problem, >>> except that people using Hibernate would need to upgrade to 4.3.0 or higher >>> ... a major upgrade if they're still on 3.5-3.7, but only a minor upgrade >>> if they're on 4.0+ already. Hibernate 4.3.0 is currently in beta but should >>> release soon, almost assuredly before Log4j 2 does. I know in both of my >>> $work environments we have a need for many custom converters and will be >>> upgrading ASAP when 4.3.0 comes out. >>> >>> So, what do you think? Which of these options do you prefer? >>> >>> 1) A harder-to-use JPA Appender that is more forgiving about which JPA >>> provider version you use, or >>> 2) A much easier-to-use JPA Appender that requires the absolute latest >>> JPA provider version? >>> >>> I lean towards 2. My thoughts are that by the time Log4j 2 becomes >>> widely used JPA 2.1 providers will be the norm, not brand new like they are >>> now. My bets are that the few people that will be using the JPA Appender >>> early on are likely already early adopters who will already be on JPA 2.1 >>> or don't mind upgrading. >>> >>> Nick >>> >>> [1] https://issues.apache.org/jira/browse/LOG4J2-229 >>> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second > Edition<http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
