New Java EE Schemas for Java EE Deployment Descriptors

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

New Java EE Schemas for Java EE Deployment Descriptors

Gurkan Erdogdu-5
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
Reply | Threaded
Open this post in threaded view
|

Re: New Java EE Schemas for Java EE Deployment Descriptors

David Blevins-2
> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: New Java EE Schemas for Java EE Deployment Descriptors

David Jencks-3

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 <[hidden email]> wrote:

>> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu <[hidden email]> 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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: New Java EE Schemas for Java EE Deployment Descriptors

Romain Manni-Bucau
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 <[hidden email]> 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 <[hidden email]> wrote:
>
> >> On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu <[hidden email]> 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
> >
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: New Java EE Schemas for Java EE Deployment Descriptors

Gurkan Erdogdu-5
In reply to this post by David Blevins-2
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 <[hidden email]>
wrote:

> > On Dec 2, 2018, at 2:59 AM, Gurkan Erdogdu <[hidden email]> 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
>
>
>
>
>