Hi David First of all, thank you for your clear and well written response (as always). I have been working (nearly 20 hours) to convert all openejb-jee and openejb-jee-sxc to formal standard EE 8 descriptors but it is a painful process for me. The generated schemas are not fit in to our current implementation and the current code base needs to be updated heavily. There are two options here:
- Stay with the current descriptor logic but it must be updated manually for every new/updated EE descriptors. Also, we need to validate descriptors which are written according to EE 8 descriptors with new namespaces. - Remove the old implementation and use the newly generated schemas (Lots of work, I really mean it) - Keep the old implementation, update each main class such as FacesConfig, EjbJar, Application etc. to use newly written delegate classes which delegate each method call to new classes. But, some codes are directly accessing the public fields of the old descriptors so it may not be fit. >From my perspective, now Jakarata EE allows us to use Jakarata EE TCK freely, so we may stick to EE descriptors and rethink to certify TomEE against these TCKs. Regards. Gurkan On Mon, Dec 3, 2018 at 2:33 AM 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 > > > > >
