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 >> JUnit in Action, Second Edition >> Spring Batch in Action >> 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 > JUnit in Action, Second Edition > Spring Batch in Action > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory
smime.p7s
Description: S/MIME cryptographic signature
