> 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
