| Re: [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC |
|
I have an overall concern about how a Jakarta specification will interact with the existing org.crac APIs. The org.crac APIs have been depended on by popular frameworks already (e.g. Spring) to provide integrations with CRaC already.
Overall, I believe Jakarta needs to support application libraries that already integrate with CRaC using the org.crac APIs. As David mentions, this library is externally defined. Yet I believe the success of a Jakarta CRaC specification for Jakarta applications
must accommodate applications that bind to org.crac.
Over the past few years Jakarta has been very much against depending on external APIs like MicroProfile config. It is unclear to me if the Jakarta working group will accommodate depending on org.crac for integrating into CraC and why that same accommodation
would not be just as applicable to MicroProfile config.
I believe we must use something like org.crac because I don't think we want to wait, possibly indefinitely, for CRaC to be fully integrated into the Java platform itself to define how the Jakarta platform and applications integrate with CRaC.
Tom Watson
From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> on behalf of David Blevins via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Sent: Thursday, October 8, 2026 2:34 PM To: jakarta.ee-spec@xxxxxxxxxxx <jakarta.ee-spec@xxxxxxxxxxx> Cc: David Blevins <dblevins@xxxxxxxxxxxxx> Subject: [EXTERNAL] [jakarta.ee-spec] [DISCUSSION] Creation+Plan Review for Jakarta CRaC Hi All!
First a quick note that though our process doesn't require discussion on this list before votes, I personally find it helpful. I suspect there was some discussion by those that can attend the Tuesday platform calls. Fully on board with the base concept that we should support CRaC. Handful of questions and musings. None of them should be interpreted as a preference or blocking. We don't need to have all the answers. Just trying to get a pulse. CRaC is defined externally, which is a pattern we've seen before in basically two shapes. CORBA for example was leveraged in the Java EE specs and EJB specs. But we didn't have a "Java CORBA" spec specifically. This made sense as we didn't produce any java libraries people would code against. Our goal was just to create rules and tests to guarantee CORBA was supported. The work then was done in the individual specs and platform spec. SOAP as a different pattern, though defined externally, did not have any bindings in Java so there was quite a bit of work. We both created a spec with API jar to get those bindings right, and then there was work in specific specs like EJB to integrate it there. CRaC is defined externally and already does have java bindings. Do we imagine adding any new java API for this or would we just leverage the existing API crac.org defines? If we don't imagine producing an API, do we need this as a separate spec or can the requirements go into a combination of the Platform and individual specs that want to support CRaC? If we do create a Jakarta CRaC spec, is the term CRaC trademarked? Do we have thoughts on how we could test people's compliance? In EJB we have session persistence with @PrePassivate and @PostActivate. Neither of them are testing in any Java EE TCK or Jakarta EE TCK. I never cared for that. Do we have thoughts on how we would not reach the same fate? Do we have any finger in the wind ideas on when the CRaC snapshot would be taken and retaken? There's a great deal of art to that part of it. I've used the feature and love it. Certainly you can do the pattern of deploy+init the app -> snapshot -> crac start. More and more I see value in deploy+init the app -> run warm-up load for hot-spotting -> snapshot -> crac start. Overall, I do want to convey great appreciation for the effort to get this as a requirement. -David _______________________________________________ jakarta.ee-spec mailing list jakarta.ee-spec@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec |