Re: New Java EE Schemas for Java EE Deployment Descriptors

[Gurkan Erdogdu]

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 b

Re: Merging Old and New Websites - Volunteers Needed

[Karan Malhi]

I will start taking a look at these this week.

On Sun, Dec 2, 2018 at 4:07 AM David Blevins 
wrote:

> > On Dec 1, 2018, at 5:41 PM, David Blevins 
> wrote:
> >
> > I'm attempting to get this to a point where we can crowd source some
> non-automatable tasks.
> [...]
> > To get there I just need to 1) minimally improve the index pages to have
> groups and 2) add the jbake headers to all the files
>
> Ok, indexing is in and JBake headers added.
>
>  - http://tomee.apache.org/tomee-8.0/docs/
>  - http://tomee.apache.org/tomee-8.0/examples/
>
> Those preliminary groups are not anything near polished.  Consider them
> inspiration, but restriction.  Feel free dramatically change the groups.
> My intent is to do enough to show what can be done so others can be
> productive.
>
> > What I'm imaging we can all do in a divide and conquer fashion:
> >
> > - Categorize each document for an intelligent looking index
> > - Review each document for formatting issues
> > - Convert markdown documents to asciidoc
> > - Fix inconsistent h1, h2, h3 etc usage
> > - Update branding to "TomEE" from "OpenEJB"
> > - Ensure each has a title
> > - Check links
>
> Open season on docs.  Let the PRs fly!  What we need is people to dig in
> here and here:
>
>  - https://github.com/apache/tomee/tree/master/docs
>  - https://github.com/apache/tomee/tree/master/examples
>
> And create PRs like these commits:
>
>  -
> https://github.com/apache/tomee/commit/bdee81d34c60644b755621254a535d0d8757eb21
>  -
> https://github.com/apache/tomee/commit/e2190a47c211c870680d761efd6d025d935546c7
>
> While you're in there, make sure the document has a "title=Foo"
>
> I cannot stress enough the groupings you see do not reflect human action,
> so do not get fussed with questions like "Why didn't he group this one as
> CDI, it's clearly CDI???"  I took an old index that was a bout 5 years
> stale and used it to seed the groups like so:
>
>  -
> https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/AddGroups.java
>
> So what you see a machine could do and did.  We need humans to put some
> thought into the best way to organize and put groups in that make sense.
>
> If you'd like to build the docs locally, run this long command and then
> open your browser to http://localhost:8080
>
>  - git clone g...@github.com:apache/tomee-site-generator.git && cd
> tomee-site-generator && mvn clean compile -Djbake.http=true
>
> That will clone the site repo and build it, which will in turn pull down
> all the related TomEE branches.
>
>
> -David
>
>

-- 

Karan Singh Malhi

Re: How can I help?

[Hayri Cicek]

Wow this awesome, thank you ☺

/Hayri

Den mån 3 dec. 2018 04:36 skrev David Blevins :

> > On Nov 30, 2018, at 11:12 AM, Hayri Cicek  wrote:
> >
> > Links to PR's
> > https://github.com/apache/tomee/pull/168
> >
> > https://github.com/apache/tomee/pull/163
>
> These should both be in now! :)
>
> Thank you so much, Hayri!
>
>
> -David
>
>

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  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 decisions

Re: How can I help?

[David Blevins]

> On Nov 30, 2018, at 11:12 AM, Hayri Cicek  wrote:
> 
> Links to PR's
> https://github.com/apache/tomee/pull/168
> 
> https://github.com/apache/tomee/pull/163

These should both be in now! :)

Thank you so much, Hayri!


-David

[GitHub] tomee pull request #168: Minor changes

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tomee/pull/168


---

Documentation Contribution Opportunities

[David Blevins]

Hello hopeful contributors!

As of this weekend we have two new index pages for our documentation on the 
website:

 - http://tomee.apache.org/tomee-8.0/docs/
 - http://tomee.apache.org/tomee-8.0/examples/

The source for each of these index pages is generated by walking over each 
Markdown or Asciidoc file in these two sections of the main repo and looking 
for an `index-group=Foo` header in the document.  That's how they get grouped.

 - https://github.com/apache/tomee/tree/master/docs
 - https://github.com/apache/tomee/tree/master/examples

In the 'docs' directory alone there are 165 files that have "Unrevised" as the 
header or no header at all.  We need to get a header on all 165 of them.



If you're looking for a way to contribute, there are 165 of them right there.  
At 15 minutes each document that's 2475 minutes or 41.25 hours of community 
work.

  ^  ^  ^  ^   ^  ^  ^  ^  ^  ^  ^  ^   ^  ^  ^  ^  ^  ^  ^  ^   ^  ^  ^  ^  ^  
^  ^  ^   ^  ^  ^  ^  ^  ^  ^  ^   ^  ^  ^  ^  ^  ^  ^  ^   ^  ^  ^  ^

:)

What we need is each doc to be reviewed, checked for any formatting issues such 
as inconsistent h1, h2, h3 usage, then make your best guess on what the topic 
is (JavaMail, JMS, CDI, JPA, etc), then set that as the header 
`index-group=JMS` and submit a PR along with any updates to the document you 
think are good (maybe none at all) 

Here's a couple sample commits:

 - 
https://github.com/apache/tomee/commit/bdee81d34c60644b755621254a535d0d8757eb21
 - 
https://github.com/apache/tomee/commit/e2190a47c211c870680d761efd6d025d935546c7


If you'd like to build the docs locally, run this long command and then open 
your browser to http://localhost:8080

 - git clone g...@github.com:apache/tomee-site-generator.git && cd 
tomee-site-generator && mvn clean compile -Djbake.http=true


On the formatting inconsistencies:

 - We use to use Confluence.  There are actually some pages still with that old 
format.
 - Some docs randomly start at h3 or h5.  They need to start at h1 and strictly 
not jump to h3 without an h2 in the middle.
 - If you have the energy to convert it from Markdown to Asciidoc, yay!

We need to do this for both the docs and examples.

 - https://github.com/apache/tomee/tree/master/docs
 - https://github.com/apache/tomee/tree/master/examples


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

Re: How can I help?

[David Blevins]

Hi Daniel, just saw your PR come in -- Amazing! :)


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Nov 30, 2018, at 6:19 PM, Daniel Dias Dos Santos 
>  wrote:
> 
> Hi folks,
> 
> My name is Daniel,  today @dblevins me sent the  following link (
> https://www.tomitribe.com/blog/tomee-for-the-holidays/) .
> 
> I think an very good initiative and I would like of help in something .
> 
> My experience in Open Source is low, I begin with MVC 1.0 (
> https://github.com/mvc-spec) and I did a little each for help, like report
> bugs, writing tutorials, help in site and some lecture for this one
> featuring JSR.
> 
> A of tutorials is with Tomcat and Tomee using the RestEasy (
> https://medium.com/danieldiasjava/jsr-371-mvc-1-0-com-tomcat-tomee-45f9638f276c)
> (pt-br) .
> 
> thanks.
> 
> --
> 
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava

[GitHub] tomee issue #168: Minor changes

[dblevins]

Github user dblevins commented on the issue:

https://github.com/apache/tomee/pull/168
  
This one should be in now!


---

[GitHub] tomee pull request #163: final parameters and use of diamond operator

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tomee/pull/163


---

Re: Looking to contribute

[David Blevins]

Hi Brant!

Really excellent to see you on the list.  Sorry for the delayed response, I was 
going heads-down on the website and didn't manage to get into bed till 6am my 
time.

See my 'Documentation Contribution Opportunities' email for a place to jump in.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Nov 30, 2018, at 6:46 PM, Brant Oliver  wrote:
> 
> Hi all,
> 
> How can I get in on the fun and start contributing? I joined the list a few
> days ago and seems like  a lot of cool efforts are going on with
> consolidating documentation and making it easy for the new members of the
> community to get ramped up.
> 
> In a previous job I was fortunate enough to use TomEE and BatchEE as well
> as meet members of Tomitribe.
> 
> I’d be new to contributing to the open source world, but have done some
> Java development in the past.
> 
> Thanks!
> Brant

[GitHub] tomee-site-generator pull request #7: TOMEE-2312 - Link to examples in foote...

[Daniel-Dos]

GitHub user Daniel-Dos opened a pull request:

https://github.com/apache/tomee-site-generator/pull/7

TOMEE-2312 - Link to examples in footer not found .

issue create -> https://issues.apache.org/jira/browse/TOMEE-2312

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Daniel-Dos/tomee-site-generator TOMEE-2312

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomee-site-generator/pull/7.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #7


commit 073415e3538d73d7bb4e2d6bc2b6462c4c3a585b
Author: Daniel Dias 
Date:   2018-12-03T02:51:51Z

TOMEE-2312 - Link to examples in footer not found .




---

Re: New Java EE Schemas for Java EE Deployment Descriptors

[David Jencks]

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

[David Blevins]

> 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 th

Re: [TOMEE-2287] Histogram Prometheus Output

[Michael Redlich]

Hi Ivan:

I just tried to push a new branch to the tomee git repository.  When I
executed *git push  *, I used my own GitHub
account for authentication, but knowing that it might fail anyway, I
received the following message:

*Username for 'https://github.com ': mpredli01*
*Password for 'https://mpredl...@github.com
':*
*remote: Permission to apache/tomee.git denied to mpredli01.*
*fatal: unable to access 'https://github.com/apache/tomee.git/
': The requested URL returned error:
403*

I assume I would need my own authentication to the tomee git repository?
Please advise on how to proceed.  Thanks!

Mike.




On Thu, Nov 29, 2018 at 6:41 AM Ivan Junckes Filho 
wrote:

> Hi Michael,
>
> These are some commands that may help you.
>
> #Create a branch from master
> git checkout -b 
>
> #List the remotes you have
> git remote -v
>
> #Create a new remote
> git remote add  
>
> #Push to the remote branch
> git push  
>
>
>
> On Thu, Nov 29, 2018 at 8:25 AM Michael Redlich  wrote:
>
>> Hi Romain:
>>
>> Thanks for all the background information on this!  I certainly appreciate
>> it.
>>
>> Mike.
>>
>> On Wed, Nov 28, 2018 at 10:47 AM Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> wrote:
>>
>> > Hello Michael,
>> >
>> > in prometheus, histograms are not represented directly like their class
>> > and the prometheus representation is done through an endpoint and not a
>> > body writer as per microprofile spec - can likely be enhanced but it is
>> not
>> > needed today since you rarely want a single metrics in the output (see
>> >
>> https://github.com/apache/geronimo-metrics/blob/master/geronimo-metrics-common/src/main/java/org/apache/geronimo/microprofile/metrics/common/prometheus/PrometheusFormatter.java#L140
>> > for an impl)
>> >
>> > Now, geronimo-metrics provides for you the prometheus endpoints so you
>> > don't need to implement it on your side, did you set the system
>> property geronimo.metrics.jaxrs.activated=true
>> > ?
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau  |  Blog
>> >  | Old Blog
>> >  | Github
>> >  | LinkedIn
>> >  | Book
>> > <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>> >
>> >
>> > Le mer. 28 nov. 2018 à 16:43, Ivan Junckes Filho > >
>> > a écrit :
>> >
>> >> Hi Michael, could you please push it to a remote branch so I can take a
>> >> look?
>> >>
>> >> On Wed, Nov 28, 2018 at 1:26 PM Michael Redlich 
>> >> wrote:
>> >>
>> >> > Hello everyone:
>> >> >
>> >> > I am making progress implementing a Metrics Histogram example.
>> Please
>> >> see
>> >> > the following code:
>> >> >
>> >> > @Path("/histogram")
>> >> > @GET
>> >> > @Produces(MediaType.TEXT_PLAIN)
>> >> > // @Produces(MediaType.APPLICATION_JSON)
>> >> > public Histogram histogramStatus() {
>> >> > Metadata metadata = new Metadata("items", MetricType.HISTOGRAM,
>> >> > "degrees F");
>> >> > metadata.setDescription("A histogram of recent temperatures.");
>> >> > Histogram temps = metrics.histogram(metadata);
>> >> > for(int temp = 80; temp < 100; ++temp) {
>> >> > temps.update(temp);
>> >> > }
>> >> > return temps;
>> >> > }
>> >> >
>> >> >
>> >> > In APPLICATION_JSON mode (commented), the output is as expected.
>> >> However,
>> >> > in TEXT_MODE, I get the following message:
>> >> >
>> >> > No message body writer has been found for class
>> >> > org.apache.geronimo.microprofile.metrics.impl.HistogramImpl,
>> >> > ContentType: text/plain
>> >> >
>> >> > I haven't been able to find a way to correct this, especially since
>> the
>> >> > Counter Metric didn't require a body writer.
>> >> >
>> >> > I would appreciate any help.  Thanks!
>> >> >
>> >> > Mike.
>> >> >
>> >> > --
>> >> > *Code*, *Write*, *Cycle*, *Run*, *Drink*,
>> >> > *Sleep ... Repeat*
>> >> >
>> >> > *InfoQ  Java Queue Editor*
>> >> > https://about.me/mpredli 
>> >> > https://twitter.com/mpredli
>> >> > https://redlich.net/
>> >> > https://javasig.org/
>> >> > *Laissez Les Bon Temps Rouler*
>> >> >
>> >>
>> >
>>
>> --
>> *Code*, *Write*, *Cycle*, *Run*, *Drink*,
>> *Sleep ... Repeat*
>>
>> *InfoQ  Java Queue Editor*
>> https://about.me/mpredli 
>> https://twitter.com/mpredli
>> https://redlich.net/
>> https://javasig.org/
>> *Laissez Les Bon Temps Rouler*
>>
>

-- 
*Code*, *Write*, *Cycle*, *Run*, *Drink*,
*Sleep ... Repeat*

*InfoQ  Java Queue Editor*
https://about.me/mpredli 
https://twitter.com/mpredli
https://redlich.net/
https://javasig.org/
*Laissez Les Bon Temps Rouler*

[GitHub] tomee pull request #226: Fixing major JavaDoc errors for Tomee

[dalexandrov]

GitHub user dalexandrov opened a pull request:

https://github.com/apache/tomee/pull/226

Fixing major JavaDoc errors for Tomee

Here are just some of the most visible JavaDoc errors fixed.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dalexandrov/tomee master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomee/pull/226.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #226


commit 8a8d2f013242a921fe7f8146025d750c466b0a6b
Author: dalexandrov 
Date:   2018-12-02T15:59:26Z

Fixing major JavaDoc errors for Tomee




---

Re: How can I help?

[Richard Monson-Haefel]

Hi Jose,

I thought for sure you responded to this email but I can't find my response
so I may have missed it. If I did, I hope you will excuse the tardiness of
my reply.  I'm excited to read your email and I can't wait to see you on
the forums and making your first commits to TomEE!

I'm currently working on a beginners guide but it's in the works, so
instead of pointing you to that I'm going to ask you to join the
dev@tomee.apache.org mailing list and introduce yourself with the subject
line "How can I help?".  We have at least a half dozen folks already
helping others get started. You should feel free to ask them as many
questions as you want and on the mailing list to get started!

The first thing you'll need to do is to subscribe to the dev mailing list.
Here are the instructions I have given others:

To get started send an email from the email address you want to use to the
TomEE developers mailing list (dev-subscr...@tomee.apache.org). After you
send the subscribe request, the list manager will send you a confirmation
e-mail in reply.  You must reply to this e-mail to complete the process. If
you have not received the confirmation request, check that it has not been
marked as spam.  A confirmation will put you on the
dev@tomee.apache.org mailing
list where you can talk to the rest of the community!

Once your subscription is confirmed (sometimes it takes a few hours), send
a message to dev@tomee.apache.org with the Subject line "How can I help?"
and write a little bit about yourself like where you live and what you
might be interested in working on. You will probably be given some tasks
outside your interest area just to get you started, but once you get the
hang of it you can move to a specific area if you want.

I'm really looking forward to seeing you on the list and learning more
about you. Welcome to the adventure!

Richard
p.s. I've CCed the dev@tomee.apache.org mailing list so they know you are
coming.


On Thu, Nov 22, 2018 at 3:30 PM Jose Henrique Ventura <
jose.vent...@protonmail.com> wrote:

> Hi Guys,
>
> Today I stepped by Richard Monson-Haefel's tweet where he describes his
> journey with Open Source projects and
> I really liked the initiative of encouraging developers to join an Open
> Source project. I know that there are many Open Source project around there
> but I think there is a lack of information of how people can get started
> with.
>
> I'm really interested in getting started with an Open Source project
> especially now with Jakarta EE and MicroProfile.
>
> I'm interested and I would like to know "How can I help?". =)
>
> Best Regards,
> José Henrique Ventura.
> https://josehenriqueventura.github.io
>
> Sent with ProtonMail  Secure Email.
>
>

-- 
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.tomitribe.com/

Re: Merging Old and New Websites

[Alex The Rocker]

Hello David,

Done: JIRA 2307 to JIRA 2311 created (yes, that's 5 JIRAs in a row) to
capture these requirements on documentation / overall TomEE site
layout.
May the force be with Web Designers!

Kind regards,
Alexandre

Le dim. 2 déc. 2018 à 13:27, David Blevins  a écrit :
>
> These are all great suggestions.  If you can file them as jiras of type 
> "documentation" that would be very helpful.
>
> > On Dec 1, 2018, at 11:56 PM, Alex The Rocker  wrote:
> >
> > 1.  This site must have navigation links, or better : breadcrumbs
> > link, in all its pages.
> > Let me take an example: when I click on the link you gave as an
> > example: 
> > http://tomee.apache.org/tomee-7.1/examples/application-composer.html,
> > I arrive on a page which is missing the "context" : I should see that
> > I am in a documentation page for TomEE version 7.1, subsection
> > Examples, and I should be allowed to navigate from this page to "The
> > root of all TomEE docs / The root of all TomEE 71 docs / The root of
> > all Examples of TomEE 7.1 docs".
> > Alternative would be to show a TOC (Table Of Contents) next to
> > all pages, but I personally find TOCs takes to much reading space,
> > whereas breadcrumbs, if well designed (don't use too long identified
> > for each "nesting") only take a short space, usual at the top of the
> > displayed page (but under other navigation elements, like the Search
> > bar, see #3 below).
>
> We should definitely get that in there.  I'll be moving on to see if we can 
> get javadoc in, but if someone wants to hack this is a great task.
>
>
> > 2. It would be nice to have (not mandatory) a way to switch from
> > version 7.1 of this page to 7.0 and 8.0.
> >
> > 3. A missing feature is a Search bar  in the top of all pages,
> > allowing to search documentation / examples on TomEE site.
> >
> > 4. Would it be possible to add a "day / night switch button" ? (see
> > the Sun/Moon icon at the top right hand side of this site:
> > https://docs.influxdata.com/telegraf/v1.9/data_formats/template-patterns/),
> > I love this one, but it's a  matter of taste here :)
>
> Way out of my skill, but perhaps there's an enthusiastic developer out there 
> :)
>
> > 5. (hard) Access to the site from mobiles sucks, requires zooming.
> > Ideally the styles should implement responsive web design to nicely
> > fit pages in small displays.
>
> We're using twitter bootstrap, which should be responsive except for tables.  
> There's no way to make tables responsive as far as I know.
>
> The margins look a little tight on the mobile version which should be 
> tweaked, but other than that it looks responsive.  If you have a couple pages 
> that don't look good (tables aside), that would be helpful.
>
>
> -David
>

Re: Merging Old and New Websites

[David Blevins]

These are all great suggestions.  If you can file them as jiras of type 
"documentation" that would be very helpful.

> On Dec 1, 2018, at 11:56 PM, Alex The Rocker  wrote:
> 
> 1.  This site must have navigation links, or better : breadcrumbs
> link, in all its pages.
> Let me take an example: when I click on the link you gave as an
> example: http://tomee.apache.org/tomee-7.1/examples/application-composer.html,
> I arrive on a page which is missing the "context" : I should see that
> I am in a documentation page for TomEE version 7.1, subsection
> Examples, and I should be allowed to navigate from this page to "The
> root of all TomEE docs / The root of all TomEE 71 docs / The root of
> all Examples of TomEE 7.1 docs".
> Alternative would be to show a TOC (Table Of Contents) next to
> all pages, but I personally find TOCs takes to much reading space,
> whereas breadcrumbs, if well designed (don't use too long identified
> for each "nesting") only take a short space, usual at the top of the
> displayed page (but under other navigation elements, like the Search
> bar, see #3 below).

We should definitely get that in there.  I'll be moving on to see if we can get 
javadoc in, but if someone wants to hack this is a great task.


> 2. It would be nice to have (not mandatory) a way to switch from
> version 7.1 of this page to 7.0 and 8.0.
> 
> 3. A missing feature is a Search bar  in the top of all pages,
> allowing to search documentation / examples on TomEE site.
> 
> 4. Would it be possible to add a "day / night switch button" ? (see
> the Sun/Moon icon at the top right hand side of this site:
> https://docs.influxdata.com/telegraf/v1.9/data_formats/template-patterns/),
> I love this one, but it's a  matter of taste here :)

Way out of my skill, but perhaps there's an enthusiastic developer out there :)

> 5. (hard) Access to the site from mobiles sucks, requires zooming.
> Ideally the styles should implement responsive web design to nicely
> fit pages in small displays.

We're using twitter bootstrap, which should be responsive except for tables.  
There's no way to make tables responsive as far as I know.

The margins look a little tight on the mobile version which should be tweaked, 
but other than that it looks responsive.  If you have a couple pages that don't 
look good (tables aside), that would be helpful.


-David
 

Re: Merging Old and New Websites - Volunteers Needed

[David Blevins]

> On Dec 1, 2018, at 5:41 PM, David Blevins  wrote:
> 
> I'm attempting to get this to a point where we can crowd source some 
> non-automatable tasks.  
[...]
> To get there I just need to 1) minimally improve the index pages to have 
> groups and 2) add the jbake headers to all the files

Ok, indexing is in and JBake headers added.  

 - http://tomee.apache.org/tomee-8.0/docs/
 - http://tomee.apache.org/tomee-8.0/examples/

Those preliminary groups are not anything near polished.  Consider them 
inspiration, but restriction.  Feel free dramatically change the groups.  My 
intent is to do enough to show what can be done so others can be productive.

> What I'm imaging we can all do in a divide and conquer fashion:
> 
> - Categorize each document for an intelligent looking index
> - Review each document for formatting issues
> - Convert markdown documents to asciidoc
> - Fix inconsistent h1, h2, h3 etc usage
> - Update branding to "TomEE" from "OpenEJB"
> - Ensure each has a title
> - Check links

Open season on docs.  Let the PRs fly!  What we need is people to dig in here 
and here:

 - https://github.com/apache/tomee/tree/master/docs
 - https://github.com/apache/tomee/tree/master/examples

And create PRs like these commits:

 - 
https://github.com/apache/tomee/commit/bdee81d34c60644b755621254a535d0d8757eb21
 - 
https://github.com/apache/tomee/commit/e2190a47c211c870680d761efd6d025d935546c7

While you're in there, make sure the document has a "title=Foo" 

I cannot stress enough the groupings you see do not reflect human action, so do 
not get fussed with questions like "Why didn't he group this one as CDI, it's 
clearly CDI???"  I took an old index that was a bout 5 years stale and used it 
to seed the groups like so:

 - 
https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/AddGroups.java

So what you see a machine could do and did.  We need humans to put some thought 
into the best way to organize and put groups in that make sense.

If you'd like to build the docs locally, run this long command and then open 
your browser to http://localhost:8080

 - git clone g...@github.com:apache/tomee-site-generator.git && cd 
tomee-site-generator && mvn clean compile -Djbake.http=true

That will clone the site repo and build it, which will in turn pull down all 
the related TomEE branches.


-David

New Java EE Schemas for Java EE Deployment Descriptors

[Gurkan Erdogdu]

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

Re: Merging Old and New Websites

[Romain Manni-Bucau]

If it helps I have an antora setup ([1]) to generate another doc site with
most of these features - think only the day/night thing is missing, it uses
tags to manage versions - overridable by branches.

Side note: when we did the new site we decided to not merge with the old
one cause too much stuff was outdated and was causing issues, did you plan
to clean it now it has been merged?

[1] https://github.com/Talend/component-runtime/tree/master/documentation

Le dim. 2 déc. 2018 08:56, Alex The Rocker  a écrit :

> Hello David,
>
> Thanks for trying to make TomEE site more readable and accessible!
>
> I would like to suggest a few more enhancements to make this site as
> useful and easy to use as it deserves:
>
> 1.  This site must have navigation links, or better : breadcrumbs
> link, in all its pages.
>  Let me take an example: when I click on the link you gave as an
> example:
> http://tomee.apache.org/tomee-7.1/examples/application-composer.html,
> I arrive on a page which is missing the "context" : I should see that
> I am in a documentation page for TomEE version 7.1, subsection
> Examples, and I should be allowed to navigate from this page to "The
> root of all TomEE docs / The root of all TomEE 71 docs / The root of
> all Examples of TomEE 7.1 docs".
>  Alternative would be to show a TOC (Table Of Contents) next to
> all pages, but I personally find TOCs takes to much reading space,
> whereas breadcrumbs, if well designed (don't use too long identified
> for each "nesting") only take a short space, usual at the top of the
> displayed page (but under other navigation elements, like the Search
> bar, see #3 below).
>
> 2. It would be nice to have (not mandatory) a way to switch from
> version 7.1 of this page to 7.0 and 8.0.
>
> 3. A missing feature is a Search bar  in the top of all pages,
> allowing to search documentation / examples on TomEE site.
>
> 4. Would it be possible to add a "day / night switch button" ? (see
> the Sun/Moon icon at the top right hand side of this site:
> https://docs.influxdata.com/telegraf/v1.9/data_formats/template-patterns/
> ),
> I love this one, but it's a  matter of taste here :)
>
> 5. (hard) Access to the site from mobiles sucks, requires zooming.
> Ideally the styles should implement responsive web design to nicely
> fit pages in small displays.
>
> Disclaimer: I am not a web designer, but I've been participating to
> couple of design reviews...
>
> Kind regards,
> Alexandre
>
>
> Le dim. 2 déc. 2018 à 02:41, David Blevins  a
> écrit :
> >
> > Alright folks!
> >
> > Updated site published and with a refreshed CSS that is more readable.
> >
> >  - http://tomee.apache.org/tomee-7.1/examples/application-composer.html
> >  - http://tomee.apache.org/tomee-8.0/docs/configuring-javamail.html
> >
> > I'm attempting to get this to a point where we can crowd source some
> non-automatable tasks.  What I'm imaging we can all do in a divide and
> conquer fashion:
> >
> >  - Categorize each document for an intelligent looking index
> >  - Review each document for formatting issues
> >  - Convert markdown documents to asciidoc
> >  - Fix inconsistent h1, h2, h3 etc usage
> >  - Update branding to "TomEE" from "OpenEJB"
> >  - Ensure each has a title
> >  - Check links
> >
> > To get there I just need to 1) minimally improve the index pages to have
> groups and 2) add the jbake headers to all the files
> >
> > After that everyone can start hacking on docs too.  Then I'll move on to
> seeing if we can get javadoc generated and published as part of all this.
> Then we'll be able to reference them in our docs, which will be very handy
> and also provide some motivation to actually write javadoc in the first
> place :)
> >
> >
> > -David
> >
>