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

I certainly hope you are right. Is there some fundamental differences with MicroProfile Config that's holding up progress? If so, anyone aware what those are?

On 10/28/2024 4:22 AM, werne...@xxxxxxxxx wrote:
MP Config was more or less a blueprint for Jakarta Config. Then the slate was wiped clean, so should that be reverted again?

I did not follow the activity in the Config spec recently, because I focussed more on Data on its way into Jakarta EE 11.
With vendor exchange and compromises here and there it got finished.

I assume, the old MP design was not abandoned for nothing, maybe some aspects of it are valuable, so everyone involved should work together the same way as we saw with Data, then it should hopefully be ready for Jakarta EE 12.

Werner

Scott Stark schrieb am Sonntag, 27. Oktober 2024 um 20:23:55 UTC+1:
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...@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...@xxxxxxxxxxx

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

            

          

        

      

      -- 

      You received this message because you are subscribed to the Google
      Groups "Jakarta EE Ambassadors" group.

      To unsubscribe from this group and stop receiving emails from it,
      send an email to jakartaee-ambassadors+unsubscribe@xxxxxxxxxxxxxxxx.

      To view this discussion visit https://groups.google.com/d/msgid/jakartaee-ambassadors/92369e3e-3238-4073-8095-d6d43ba55625n%40googlegroups.com.

    

  

























  Back to the top