Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] Thoughts on the CN4J purpose

HI,

As a Java EE developer,  I have some idea to share. personally I think current status of Micro profile is not bad.

We have to consider there are a lot of enterprise applications, they work well. 

I hop there is a base profile(maybe Web profile), then two profiles have  their own missions: one for cloud native applications(light weight containers, such as Quarkus, etc), and one for traditional enterprise applications(run in the traditional application servers, such as  GF, Wildfly , Open Liberty etc.

So I hope there are two routes is OK for me.
1. base profile-> Cloud native profile(maybe the new MicroProfile)
2. base profile-> Enterprise profile(maybe the new Enterprise Profile)
(3.base profile-> Full Profile(includes 1, 2))

For adopting new features, I think a sandbox/incubator mechanism is required, provides public preview(allow changes, and incompatibility) more frequently. Application server vendors can provide it in its products, and developers can response against it before it is frozen and finalized in the spec.

I noticed there are a lot of discussion about replacement of EJB. Personally, I do not think EJB is bad, for enterprise applications, it is a great choice. Like the `@Transactional`, make some EJB components work without EJB is good,  such as schedule, mdb, lock etc.

As mentioned in former messages, why Spring/SpringBoot is the first choice of the Java newbie, personally, I have written a lot of Spring applications. For developers, it is easy to start a new application, it is easy to configure, run , and also easy to test using the popular test engine.

For Jakarta EE 10, I've read the plan and proposals, it is good. There are some points from my mind.
1. Erasing the gap between all specs is vital, united the IOC/Dependency Injection, Global exception handler, the new security context(instead of the one in EJB, jaxrs, webservice, etc), deprecating the duplicated the APIs as soon as possible.
2. Friendly configurations for different environments, easy to inject configuration values via `@Inject`, _expression_ language in annotation attributes etc. 
3. Provides the configurations by programmatic approaches, esp the JMS configurations, like Spring `@Configuration`,   configure everything(DataSources, Servlet WebApp Configuration, FacesConfig, JAXRS ResourceConfig, JPA EntityManagerFactory, JMS Connection Factory/Queue, Topic/JMSContext, etc ) via CDI `@Produces`.
4. Simplify the usage of JMS, provides more generic message sending and receiving, such as `JMSContext.send(a queue bean, message payload, acknowledge)`, and receive via CDI `@Observes`, easy to bridge messages to SSE, WebSocket, etc.
5. United application lifecycle events, can be listened by CDI `@Observes`, like Spring. In my before experience, I encountered some issues like EJB, JPA initialization in different orders in some application servers which caused EJB `@Singleton` intiailzer does not work as expected.
6. Draft an embedded container SPI to vendors, and providing a portable API to developers to boot an embedded container in a single line code(possible to run application via main method, like Spring Boot), allow developers to package the application with container in a single jar. Simplify the testing container bootstrap and usage of Arquillian., easy to mock and replace some of beans when testing in container, etc.

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach

GitHub: https://github.com/hantsy

Twitter: https://twitter.com/@hantsy

Medium: https://medium.com/@hantsy


On Tue, Jan 12, 2021 at 10:03 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Tue, Jan 12, 2021 at 2:02 PM Edwin Derks <ederks85@xxxxxxxxx> wrote:
This is a very good example of where it doesn't really matter from which platform the defined specification is maintained because a developer chooses a mix of ingredients for his app that happen to come from platform one, or platform two.

Correct, up till so far the APIs from both platform one and two agree to totally support each other. Meaning that e.g. Config is usable for all specs, and, say, the "Security Backbone" is used throughout all security specs. If I pic JWT as my authentication mechanism, and if I then define an additional identity store, it should be used. It should also be clear that if an app happens to define an authentication mechanism in web.xml and define JWT as the authentication mechanism what happens.

Kind regards,
Arjan Tijms


 
_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance

Back to the top