Re: New Java EE Schemas for Java EE Deployment Descriptors
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 wrote: > > On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu 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
Re: New Java EE Schemas for Java EE Deployment Descriptors
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 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 wrote: > > >> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu 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
Re: New Java EE Schemas for Java EE Deployment Descriptors
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 wrote: >> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu 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
Re: New Java EE Schemas for Java EE Deployment Descriptors
> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu 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
New Java EE Schemas for Java EE Deployment Descriptors
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 Happy coding! Gurkan
