Hello If it helps there are twi things to consider:
1. When we supported ee7 we made most of these descriptors at lowest cost which means we mainly let them pass and sometimes ignore some model part not used at runtime and let the actual runtime lib read it (typically jsf) 2. All the current models must not be modified in terms of API cause they are not internal since application composer is an user solution since some years My 2 cts would be that the only usage was to serialize it in object tree, now we have json built-in we can surely rationalize it and made it simpler and maybe limited to the actual usage. Being able to represent the server model in tomee core and change stuff here to impact the runtime does not work since ee6 and cdi anyway so no need to try, would be too costly for startup time or too complex/split to redo what the spec already does well probably. Le lun. 3 déc. 2018 02:59, David Jencks <david.a.jen...@gmail.com> a écrit : > > 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 > > > > > > > > >
