Comments (19)
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
from enterprise-beans.
In that case, I will use "Enterprise Beans Container" wherever applicable
from enterprise-beans.
Code changes in #100
from enterprise-beans.
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.
from enterprise-beans.
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.
from enterprise-beans.
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.
from enterprise-beans.
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
from enterprise-beans.
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.
from enterprise-beans.
@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
from enterprise-beans.
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
from enterprise-beans.
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?
from enterprise-beans.
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.
from enterprise-beans.
I'm not sure if Hussain is available, otherwise anybody else that could review my PR?
from enterprise-beans.
Looks like there is a huge backlog of PRs, the oldest from 2017 ;-O
from enterprise-beans.
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?
from enterprise-beans.
If there's no conflict, then it should be possible to merge that.
from enterprise-beans.
Maybe some PRs could also be labeled, but not sure, if you can do that when raising it.
from enterprise-beans.
Ah like that :). Well it seems that I can only change the title, not the labels
from enterprise-beans.
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
from enterprise-beans.
Related Issues (20)
- EJB tests dependant on JAX-RPC, have been pruned in Jakarta EE 9 CTS HOT 1
- Interop tests have been pruned in Jakarta EE 9 CTS
- Incorrect description in javadoc of EJBTransactionRolledbackException HOT 7
- Update signature tests for repeatable @Schedule HOT 1
- Add tests for repeatable @Schedule
- Create Contribution Questionnaire for 4.0.0
- 4.0.0 Release finalization steps HOT 10
- 4.0.0 EJB Staging duplicate HOT 4
- Compatibility certification request for Eclipse Glassfish 6.0 for Enterprise Beans 4.0 (part of Jakarta EE 9) HOT 1
- [TCK] EJB 3.2 timers issue with endDate HOT 2
- [TCK] Read-only naming context and close() HOT 4
- [spec] Broken links in Specification documents
- We need a 4.0.1 service release to add module-info.class
- Allow Schedule attributes loaded from Jakarta Config
- Add cron expression support in Schedule
- Add simple fixed rate support in Schedule
- Upgrade jakarta.transaction-api from 2.0.0 to 2.0.1
- Timer schedule increment value 0 HOT 1
- Security Best Practices
- Lost user context in EJB @Remote inside ManagedBean HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from enterprise-beans.