Jakarta-ize your Specification document (if applicable)

[ederks85]

@hussainnm can you please specify which exact changes are still open for the core specification document? I will then process these.

This should apply for all files mentioned in: https://github.com/eclipse-ee4j/ejb-api/blob/master/spec/src/main/asciidoc/enterprise-beans-spec-core.adoc

I can of course go through the complete set of instructions as described in https://github.com/jakartaee/specification-committee/blob/master/steps_javaee_to_jakartaee.adoc, if thats the right place to start

[hussainnm]

As per the Release Plan, the following items needs to be updated in the spec document:

• Removal of methods relying on java.security.Identity
• Removal of methods relying on JAX-RPC
• Removal of deprecated EJBContext.getEnvironment() method
• Removal of Support for Distributed Interoperability
• Mark optional EJB 2.x API Group (Table 18 in EJB 3.2 Spec)

So any section that is relevant to the above points needs to be updated (removed/modified). Please look into these first.

Other items that need to be updated are:

• What's New in this release
• Acknowledgements
• Revision History
• Related Documents

[ederks85]

Code changes in #100

[OndroMih]

What about the term "EJB Container"? Is it OK to leave it unchanged or we need to rename it to something like "Enterprise Beans Container", "EB Container", or "JEB Container" (Jakarta Enterprise Beans)?

The JMS spec refers to the EJB Container (e.g. here) so I wonder whether we need to fix it and how.

[smillidge]

Specs I've worked on have used "Jakarta Enterprise Beans" and then just Enterprise Beans for shortening no acronym. Not sure if that is a policy though.

[OndroMih]

But "EJB Container" is a term defined in the specification, here: https://github.com/eclipse-ee4j/ejb-api/blob/02302609c4d1324d060fd703597727e7f47f4b55/spec/src/main/asciidoc/opt/ClientViewOfEntityBean.adoc#ejb-container.

It's not directly related to the name of the specification. It's similar to the @EJB annotation which we are also not going to change. Although we can change it since it wouldn't break the API, only impact other spec documents that use the term.

[keilw]

Maybe you could call it "Enterprise Beans Container" where there's enough space. I wouldn't do "JEB" let's not forget, that "JMS" in that case is also not the proper acronym any more, it would just be "JM" now ;-D

[hussainnm]

But "EJB Container" is a term defined in the specification, here: https://github.com/eclipse-ee4j/ejb-api/blob/02302609c4d1324d060fd703597727e7f47f4b55/spec/src/main/asciidoc/opt/ClientViewOfEntityBean.adoc#ejb-container.

It's not directly related to the name of the specification. It's similar to the @EJB annotation which we are also not going to change. Although we can change it since it wouldn't break the API, only impact other spec documents that use the term.

The optional document is still under review #96. "Enterprise Beans Container" is advised, since the goal is not to refer to any Oracle trademarked acronyms.

EJB is allowed in class, package or project name.

[ederks85]

In that case, I will use "Enterprise Beans Container" wherever applicable

[ederks85]

@hussainnm I have gone through the modify/remove items and will soon have a look at how much I can do for the remaining items that you mentioned

[ederks85]

Additional items to be covered as defined by @hussainnm :

When the Chapter 10 "Support for Distributed Interoperability" is removed from the Core Features document, there are references made within the document:

• Section 2.5 - Standard Mapping to CORBA Protocols refers to Chapter 10
• Section 15.7 Requirements for Clients (paragraph 3 refers to Section 10.5.5 System Value Classes)
• Section 10.5.4 Obtaining Stub and Client View Classes refers to Section 15.3 Packaging Requirements
• Chapter 8 Support for Transactions and Chapter 9 Exception Handling are referred from Chapter 10 but nothing specific to interoperability

[ederks85]

Hi,

Do these items actually need change because they are referred from the removed "Support for Distributed Interoperability" chapter? Are these paragraphs therefore become obsolete? I'm not sure though...

• Section 10.5.4 Obtaining Stub and Client View Classes refers to Section 15.3 Packaging Requirements
• Chapter 8 Support for Transactions and Chapter 9 Exception Handling are referred from Chapter 10 but nothing specific to interoperability

I'm not sure what to make from the Acknowledgements section. It now states that EJB is the result of efforts from the Enterprise Beans 3.2 Expert Group , conducted as part of JSR-345 under the Java Community Process Program. And then a lot of names.

I suppose it has to change to the Jakarta EE Specification Process (JESP), but what to make of the list of names?

[hussainnm]

For Chapter 8 and 9 no need to change anything. For Section 15.3 even I am not clear on the implications of the change. This is the relevant part in this section:

Generating the stubs is the responsibility of the container. The stubs are typically generated by the Container Provider’s deployment tools for each class that extends the EJBHome or EJBObject interfaces, or they may be generated by the container at runtime.

You can change the title for Acknowledgements to Acknowledgements for Enterprise Beans 3.2 and keep the content as it is.

Add a new Acknowledgement section that states the current release was done under JESP.

[ederks85]

I'm not sure if Hussain is available, otherwise anybody else that could review my PR?

[keilw]

Looks like there is a huge backlog of PRs, the oldest from 2017 ;-O

[ederks85]

That may be so, but why do you mention that? The PR referenced here is for ticking off a piece of the Jakarta EE 9 puzzle. It appears these others are less important then and not critical for EE 9?

[keilw]

If there's no conflict, then it should be possible to merge that.

[keilw]

Maybe some PRs could also be labeled, but not sure, if you can do that when raising it.

[ederks85]

Ah like that :). Well it seems that I can only change the title, not the labels

[ederks85]

The "Linked pull requests" field would also be a nice feature to use here imho. Will try to take these things into account in the future