It’s been a very long time since I worked with these, but I do remember that switching to the openejb customized classes was a very big improvement. I think it’s definitely worth having an object tree representing the deployment descriptor where the objects make sense. David Jencks Sent from my iPhone
On Dec 2, 2018, at 3:33 PM, David Blevins <david.blev...@gmail.com> wrote: >> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu <cgerdo...@gmail.com> wrote: >> >> Hi folks, >> I am working on the Java EE schema update to support Java EE 7 and Java EE8 >> schemas which are specified in >> https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html >> >> Seems that two modules openejb-jee and openejb-jee-accessor modules are >> mostly updated by manually after generated by xjc compiler. Moreover, I did >> not able to find the any XJB binding file. >> >> In pom.xml, there is a plugin (jaxb2-maven-plugin) but seems that it is not >> working correctly. >> Do you have any comment on these modules? We need to generate codes >> automatically without updating any manual intervention. >> >> Currently we only support Java EE 6 schemas and using the trick (updating >> newer namespaces to Java EE 6 old namespace) and do not support Java EE7 >> and 8 deployment descriptors. >> >> Here is the JIRA Issue: >> https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2306 > > Hi Gurkan, > > I've added David Jencks to the thread in case he's around and wants to give > some of his historical perspective. He is retired and enjoying life, so I > suspect he won't, but it never hurts. > > There's long pro-customization and anti-customization history on this topic > between OpenEJB/Geronimo. We've done it both ways in both projects, this is > a rough timeline -- years are approximate: > > - OpenEJB & Geronimo anti-customization: 2003 - 2006 > - OpenEJB pro-customization, Geronimo anti-customization 2006-2009 > - OpenEJB & Geronimo pro-customization: 2009 onward > > There really is no easy answers without pain points. Both project started as > you say, generating automatically without any customizations, and committers > on both projects eventually shifted away from it. There's a trade-off and it > comes down to where you want the benefits and where you're willing to live > with the cost. This is a high-level perspective of what we all noticed. > > - Read-only generated tree: > - pro: easy when schemas change once every 2-3 years > - con: inability to customize pushes complexity into consuming code > year-round > > - Generated then customized tree: > - pro: increasingly easier to to consume year-round > - con: hard when schemas change once every 2-3 years > > The con of "Generated then customized tree" really only applies to existing > schemas that change. New schemas introduced can easily be generated. > > The story arch of this goes basically both OpenEJB and Geronimo used > generated trees that were not checked into the source. The pain points > associated with that resulted in OpenEJB trying it differently when OpenEJB 3 > was launched in 2006. Geronimo kept with generated trees believing manually > changing them was a mistake. After a few years on both projects and everyone > having the experience with both approaches, Geronimo eventually removed it's > generated tree and switched the whole server over to using the optimized > OpenEJB JAXB tree. > > This topic comes up every few years when it is time to update the > descriptors, which is completely natural. > > The topic of customized or not is particularly challenging when you don't > control the schema. There are a few terrible aspects of the Java EE schemas > that make it really hard to work with "pure." > > - Created it's own String type > - No polymorphism/reuse for types like SessionBean, EntityBean, > MessageDrivenBean > - Doesn't use enums many places where it should > > These are only a few highlights. Some of the decisions made around the Java > EE schemas in 1999 wouldn't be considered best practice today, but will never > be changed due to backwards compatibility reasons. So we have the double > challenge of it being a schema we don't control on top of it being a schema > that is not written with tools like JAXB in mind that hadn't been invented. > > In practice how this played out for the Java EE schemas is that your code > that consumed it didn't feel like "java" code. > > - It was strongly-typed, but none of those types had any relationship to each > other so you're duplicating the same logic over and over again. You get the > cost of Java's type system, but none of the benefits. > > - There are few enums so the relationship between strings has to be "in your > code" not in the class that holds the strings. > > - Your code isn't dealing with java.lang.String 80% of the time but > org.apache.openejb.jee.String, so not only are you doing double null-checks > on the wrapper and inner value, but when you get the value you have to always > use the fully qualified `java.lang.String` reference because they have the > same name. > > In the end this ends up being less about automatic-generation vs > manual-generation, but what is the best way to consume and compensate for 20 > years of legacy decisions and schemas that were designed only for xml use in > mind. > > At this point pushing those legacy decisions into the code would mean a > considerable rewrite of much of the runtime and at least 900 tests. > > As a principle, automatic-generation that is never customized can definitely > work. In practice for Java EE specifically, it doesn't play out well because > the schemas don't "think" like java. > > Incredibly valuable topic. I'm glad you raised it. Still an open discussion > despite this email being long :) I put extra energy into the response so we > can all have the same context and start the conversation where the last ones > left off. > > We should probably have the conversation to all of our satisfaction and then > document this so we aren't searching for this thread in 2 years during > Jakarta EE 9. > > > -David > > > >
