Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan

If I am understanding the nuances of this correctly, Microsoft would be happy to vote +1 to help move things along in this direction. This is so overdue at this point that any substantive progress is a positive development (and I do not have a clear view of what is taking so long).

Just for clarity though, Microsoft's position remains congruent with the majority community opinion gathered when Jakarta Config was created: https://reza-rahman.me/2021/04/10/jakarta-ee-microprofile-alignment-survey-results/. We hear the same feedback consistently from customers when this topic comes up. For example, longer term users/customers should be able to understand how to use Jakarta EE to portably configure data sources using property files, environment variables, Kubernetes Secrets, Azure Key Vault, or Azure Redis instead of the old XML configuration files.

On 10/27/2024 3:23 PM, Scott Stark wrote:
Regarding a comment in the doc about configuration and moving MP config into Jakarta, the easiest thing to do given the current state of Jakarta Config, which essentially boils down to: 
public interface Config {
    /**
     * Loads an object of the supplied {@code type} from the current {@link Config} <em>configuration path</em>.
     *
     * @param <T> the type of object to load
     * @param type the type of object to load; must not be {@code null}
     * @return the loaded object; never {@code null}
     * @exception NoSuchElementException if the requested object is not found.
     * @exception IllegalArgumentException if the supplied {@code type} was invalid for any reason
     * @exception NullPointerException if the supplied {@code type} was {@code null}
     */
    <T> T load(Class<T> type);

}

          

        

        
and some annotation for customizing the binding fields on a
          configuration POJO, Jakarta
            Config could just be released as is with a very simple POJO
            configuration object view with the details left to the
            implementation. Vendors supporting MP config would leverage
            that for the serialized forms, type conversion, etc. Specs
            would need to define their configuration POJOs. MP config
            could be the de facto portable format.

      

      

      

        
On Sun, Oct 27, 2024 at
          12:46 PM Reza Rahman via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx>
          wrote:

        

        
I
          am moving comments on my Jakarta EE 12 Google Doc

          (https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing)

          to Jakarta EE mailing lists when possible. The problem with
          Google Docs

          comments is that they do not scale very well, aren't very
          readable on

          smaller devices, and do not archive well. I will do so one
          email per

          comment. The person commenting is copied.

          

          Context: Why does replacing EJB matter?

          

          Josh Juneau (Community): Are there any comprehensive tutorials
          on how to

          utilize CDI rather than EJB for querying entities? It seems
          like these

          tutorials need to be made front and center in an effort to
          help steer

          people to CDI and to show that EJB is no longer needed in many
          cases.

          

          Reza Rahman (Microsoft): Good point. As of Jakarta EE 11, it
          is indeed

          possible to just use CDI now for basic CRUD in a transactional
          and

          thread safe manner with Jakarta Persistence. The same for EJB

          @Asynchronous and @Schedule. At the bare minimum, this is
          worthy of an

          Eclipse Foundation newsletter article and/or JakartaOne talk.
          The

          material could cover where EJB is not needed any more and
          where it is

          still needed. The title could be something attention grabbing
          like -

          "EJB is Dead, Long-Live CDI and Jakarta EE". We could also
          ensure a

          revised Jakarta EE 11 Tutorial can avoid using EJB when
          possible. Maybe

          Kito could comment on this? Additionally, the Marketing
          Committee has

          been sponsoring some guides. Could we consider already
          starting an EJB

          migration guide?

          

          On 10/22/2024 5:30 AM, Reza Rahman wrote:

          > Hi folks,

          >

          > I would like to see if we can define clear, compelling,
          and specific

          > scope for Jakarta EE 12 as part of the Steering Committee
          Program

          > Plan:

          > https://docs.google.com/presentation/d/1xUNDHMP_qTHH1wA3m0yCmWVf_sHp41Qd7Opq3FhgINs/edit?usp=sharing.

          > I believe this is of critical importance at this
          juncture. If I did

          > not think so, I would not bother trying. I have detailed
          all the

          > rationale here:

          > https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing.

          > For those that recall, something very similar was done
          for Jakarta EE

          > 11, so this isn't exactly without precedent.

          >

          > I would like to see if this can be done in the following
          couple of

          > weeks, when the Program Plan is due.

          >

          > Thanks,

          >

          > Reza

          >

          _______________________________________________

          jakarta.ee-community mailing list

          jakarta.ee-community@xxxxxxxxxxx

          To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

        

      

    

  

























  Back to the top