Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] R: R: Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

Hi Ondro,

 

Thanks for referencing the MicroProfile REST Client project.  I was also thinking of that as an alternative to remote EJB, for internally-used client-server applications.  The key similarity with EJB is the ease of type-safe programming in a natural Java way on both client and server sides.  Other EJB-related features are useful to our applications also (declarative/annotated transactions, declarative/annotated security, lifecycle management and pooling, tuning parameters like timeouts).  But I feel like the core use case, that would be nice to see continue in Jakarta EE, is mainly being able to rapidly develop client-server interaction using type-safe Java interfaces and classes.

 

Thanks,

Jim

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Ondro Mihályi via jakartaee-platform-dev
Sent: Thursday, August 3, 2023 11:42 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Ondro Mihályi <mihalyi@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] R: R: Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

**Warning! This email originated from outside the organization. Do not open attachments unless you recognize the sender. If you suspect this email is malicious, use the "Report Phish" button.
Replies to this email will go to jakartaee-platform-dev-bounces@xxxxxxxxxxx .**

Certainly, having 4 different attempts to support gRPC in Jakarta EE area is a pretty solid argument to look into standardization of gRPC in Jakarta EE. There's already an attempt to bring this standard with the Jakarta RPC project: https://projects.eclipse.org/projects/ee4j.rpc

 

However, remote EJBs are a different concept than gRPC. It's more like a wrapper over an underlying RPC technology. Usually, remote EJBs are implemented over Java RMI/IIOP protocol, but there are implementations over other protocols (Payara has a partial implementation over HTTP, WebLogic offers using a proprietary T3 protocol). So, to me, remote EJB to RMI or gRPC is like Jakarta Data over JPA. It abstracts the technical details and allows to simplify remote calls so that they look like local calls. Without thinking about the protocol or some stub generation. If Jakarta EE offers calling CDI beans remotely, via pluggable protocols, 

 

I think that would be a real innovation in Jakarta EE. One existing example, which already achieves this partially, is MicroProfile REST Client - you can just turn a CDI bean into a REST endpoint with a few annotations, and call methods on a client stub to call remote CDI beans. If we can add this to Jakarta EE and support calling remote EJBs on top of REST API, it could be really interesting - a good old simple approach with new technologies. gRPC could be just another option for how to call remote EJBs.


All the best,

Ondro Mihalyi

 

Director, Jakarta EE expert

OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee

Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

 

On Thu, Aug 3, 2023 at 10:19 AM Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Hello everyone,

over this years, making an example, we have seen ejb entities become a new specification in jpa (taking an example from hibernate) but the concepts of ejb entities have not disappeared but have been brought into a new specification/standard.

Another example DeltaSpike,Spring Data gave birth to the new Jakarta Data spec for jakarta ee 11.

Maybe ejb should do the same too and the new jakarta-rpc(gRPC) project, placed on top of cdi, could be a trailblazer to evolve to transit the ejb towards the use of gRPC which today is already done in this application server:

Today grpc is a standard, gRPC is widely used and recognized by CNCF, there are examples and solutions of using seata(distributed transaction solution) with grpc, in cloud environments it is widely supported by various api-gateways(nginx,APISIX,shenyu ), native solutions by cloudfare, easily manageable within the various cloud-providers.

Complex systems such as alibaba(aliexpress) or alipay make extensive use of gRPC(apache dubbo) and seata.io to solve rmi, transaction, and security in distributed environments.

The jakarta enterprise platform has the task of evolving but without removing features and concepts and preserving backwards compatibility of features and being vendor / provider neutral.

It bears the credibility of the jakarta api standard and specification and the foundation upon which the entire java platform is built.

Let me quote a sentence by Emily Jiang taken from jakarta data thread, "a new spec(jakarta rpc or ejb on cdi/grpc) would demonstrate the innovative aspect of Jakarta EE. I think we have to put the standard body work before any single implementation. With the success of Jakarta EE, any implementation of Jakarta EE will benefit. Granted, if the Jakarta EE releases don't add much, it's much easier to certify. However, we must ask for the value of certifying it if only to help our end users for all the benefits this brings. The Jakarta EE community needs to increase its popularity with some useful innovations but without forgetting/removing the existing and successful ones."

 

Thanks

Angelo Rubini


Da: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
Inviato: mercoledì 2 agosto 2023 17:56
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Angelo Rubini <angelorubini@xxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] R: Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

Out of curiosity: any (real) enterprise interested in migrating to these patterns for new apps? Recall we were already dropping them 10 years ago due to their drawbacks and since it is mainstream to solve it differently I wonder how it would still sit anywhere in today's worls. I can hear the "free migration" voice but it will not be free for sure and not just a sed in package names so not sure there is a point in going that way.

Want remoting on top of CDI -> JAXRS, Websocket, ...

Want security propagation -> there is a spec about it

Want XA -> use XA with your JTA CDI usage

 

Indeed bean pooling is not working out of the box but this one is not straight forward (even if impl is) cause it covers multiple workarounds more than features so it should likely be split in concurrency spec to cover:

* throttling (potentially on an application scoped instance),

* instance pooling (which is a poor throttling impl with drawbacks so don't abuse it please) which is just a CDI interceptor basically (or context if you are motivated but breaks some tracking and usage from other beans so require custom context handling in most cases :s) but the challenge there is to define all the pool related behavior in a portable way but not sure anyone would love this new @Stateless(poolDefinition= @StatelessPoolDefinition(....)) kind of API needed to make it reliable in apps (having random instances without being able to control when is risky in practise)

 

So overall the idea would be to ensure to not try to copy something which is desired to be deleted since JavaEE 6 in a new package without realizing it is already there somehow.

 

If it is about simplifying some configuration, let's do it but in what was cited nothing works out of the box, it just looks like it does but most of the time you spend a week doing the actual configuration to control the behavior properly - don't say me you never saw a local transaction used instead of a XA one for ex ;).


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book

 

 

Le mer. 2 août 2023 à 17:43, Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :

Hi all, absolutely original thread is ejb lite to cdi, but probably the concern of all of us and possible deletion of jakarta ee(formerly j2ee) 
platform component based model.
That said, a solid pillar of the jakarta ee model is the ability to implicitly 
decorate/request (by annotation or xml descriptor) non-functional services directly to the container. 
The ejb model means for many companies to have the possibility to invoke the methods
of the components remotely, perform the invocation of these remote methods in a distributed transaction,
in security and with authentication mechanisms, simply by asking them to the container.
Whatever path you want to take, you can't help but bring these aspects (enterprise)
currently used and reliable in many companies into the new versions.
Have you ever tried to porting ejb full to apache dubbo,seata is unmanageable lines and lines of code.....

Thanks

Angelo Rubini

 


Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di lenny--- via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: mercoledì 2 agosto 2023 17:12
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: lenny@xxxxxxxxxxxxx <lenny@xxxxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

100% agreed.

 

My proposal is to still retire EJB, but have the currently-missing features ported to CDI:

- Remote EJBs (javax.ejb.Remote -> jakartaee.cdi.Remote interface)

- Pooled beans (add jakarta.cdi.Stateless stereotype)

 

Both remote and pooled could even be optional implementations, that are local / no-op if not implemented.

 

Unless I am forgetting something else (I am sure I am) this should be very simple as a matter of Spec work :)



On Aug 2, 2023, at 5:59 AM, Ondro Mihályi via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

 

First, this thread wasn’t originally about remote EJBs but about rebasing EJB light (not remote) onto CDI. So that there’s only single container solution and EJBs build on top of it. Then many people expressed that remote EJBs are still useful, which increases the motivation to improve EJB as a whole (light as well as remote) and not conserve it as a legacy API.

 

As to the discussions whether we should put effort into into improving remote EJB or rather support some other modern options, I think we should pause and think for a while. What do we want Jakarta EE provide? 

 

I think it’s better to cover usecases rather than technology. We should strive to provide a solid solution for remote calls. With both text and binary format. Not think whether we it should be done using Java RMI or REST or Websockets, those thoughts should come later. We should provide solutions for messaging too, for manipulation with standard formats (XML, JSON, maybe YAML or anything that is widely used). We should support patterns that people use widely. Jakarta EE should be easy to use and standardize what people often do.

 

So I suggest we rethink EJB as a specification for remote calls (remote EJBs or even gRPC or something else) and a specification for business components with transactions, synchronization, etc. (EJB lite as a starting point, but we could add support for distributed patterns like Saga, Actors, etc)

 

Ondro

 

On Tue, 1 Aug 2023 at 10:37, Romain Manni-Bucau via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Well thing is that it never had been standard and always had been very vendor dependent (for good reasons IMHO).

Don't get me wrong, I'm for EE to provide solutions adapted to today's need but innovation is by design not in EE (risk to fail is too high and therefore adoption would be too low as some child projects proved).

And today there is not a mainstream solution, some will use actors, others the plain old compensation pattern, other will stick to XA until perf become an issue etc...

So all EE can do is to enable these cases without being too much opiniated cause it would fail to cover main cases.

Standardizing is a very hard task and the best choices are often to not do in this area rather than doing wrong - it is how I see it.

Doing wrong makes the spec rejected and the platform bloated, postponing until there is a clear standard and added value doesn't bother anything.

EE can enhance the experience a lot in several area but don't think it is one (as data or nosql are not for ex).

Starting by embracing functional and reactive programming, being message passing friendly etc are area which can easily benefit from some investment.

Trying to normalize the state management in a distributed system is too solution dependent to become a promoted feature and providing interfaces you have to impl everytime is quite pointless so think it is where EE should assume to stop: enable all cases but don't force patterns.

 



Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book

 

 

Le mar. 1 août 2023 à 10:30, Angelo Rubini <angelorubini@xxxxxxxxxx> a écrit :

Absolutely agree, 
but if in the 90s they managed to standardize it with ejb 1.1 providing a model that allows companies to focus on developing code for business and not to manage lines and lines of code for non-functional requirements(like EJB Remoting CMT mode)),
today with jakarta ee 11 I think it should be the same challenge by providing a standard that in addition to doing what it already does (easy rmi, easy managed transaction, easy security), expands (and does not reduce) with new features,
for example standardizing Ejb transaction model behind by Seata (https://seata.io) for handle transactions implicitly.
Java EE 5 and 6 have embraced the soap standard and all derivatives, ws-transaction, wsdl 1.0/2.0 are now discontinued,
many companies prefer and continue to much prefer using the ejb 3.0 model for backend side communications for their reliability,
portability, easy and efficiency and above all because they are a standard that lasts over time (as is the java language with a classic example of the StringTokenizer class) and are not a trend of the moment.
i think jakarta ee absolutely must ALSO do new and better things, if they did it in the 90's why shouldn't they do it today?

Angelo Rubini

 


Da: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
Inviato: martedì 1 agosto 2023 09:52
A: Angelo Rubini <angelorubini@xxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] R: Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

@Angelo: is there any convergence of vendors in these features? Don't think so. Is there a will today to promote XA? Don't think so too, it is documented how to not use it and why avoiding it (mainly scalability).

So really think it is a 1990 debate, sure vendors must be able to keep these features but also think spec should just ignore them as of today, in particular when the promoted goal since javaee 6 is to be able to deprecated EJB and it is actually reached since currently missing features are no more relevant in today's app IMHO.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book

 

 

Le mar. 1 août 2023 à 09:43, Angelo Rubini <angelorubini@xxxxxxxxxx> a écrit :

As already written by David Blevins (tomitribe) use Jakarta REST or GraphQL, gRPC, zeroC Ice or apache i dubbo for anything a 3rd party would invoke, 
but for internal communication you can get some amazing functionality from remote EJBs,
a very good example is the good portability and ease of use of incoming and outgoing ejb transaction and remote function (with binary protocol for best performance).

An alternative solutions like this(but not standard):

 

Best regards

Angelo Rubini

 


Da: Romain Manni-Bucau <rmannibucau@xxxxxxxxx>
Inviato: martedì 1 agosto 2023 09:15
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Angelo Rubini <angelorubini@xxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] R: Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

Think we are already covered with websockets which are a good replacement (likely better today than http2 based protocol which are still highly attacked) and using a binary protocol and light client wrapper you get at least an as good solution than EJB but more portable by design and proxy friendly.

That said, RMI based solution were often slow due to the classloading involved (so don't think remote ejb are really a pro when based on it) and even HTTP 1/1 did very good progress using pooling (compared to original times) and this also makes almost all the http binary optim pointless (thinking to ajp which is not really needed today for perf in practise).

 

So think this can be a more emotional thread than technical.

 

Technically the only pro would be portability - vendor specific things can always be done and don't need to hit the spec.

gRPC or graphql portability are almost a joke due to the related stacks and choices so think focusing on what is widely used like websockets and preparing http2 maturity is way sufficient at jakarta level.

 

At abstraction level not sure much can be done cause any infra requirements would bother some vendor or be overkill if not used so probably best to boot a library project than a platform solution IMHO.


Romain Manni-Bucau
@rmannibucau |  Blog | Old BlogGithub | LinkedIn | Book

 

 

Le mar. 1 août 2023 à 09:04, Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :

 

Hi All,

it is important to preserve functionality such as ejb remoting. 
Many business applications use ejb remoting to communicate in their backends, for best perfomance vs soap/rest protocol.

 

In the EJB 1.1 Specification, Sun Microsystem in according to OMG integrate RMI over CORBA IIOP(Standard deFacto and more use in the years 80/90).

Most corba client invoke Ejb method from c++, ada etc by Corba Client.

Why not reproduce same scenario for HTTP2/gRPC herea?

Http2 has more fearture like Corba TCP Connection(Single Connection,Multiplezing, priority).

The good base of RMI-IIOP based to OMG Corba(IDL+IIOP/GIOP Message) have most power.

gRPC promote an rpc over http2(only efficient alternative for REST JSON+HTTP), but there are more work for developer.

  • generate proto interface(on java there is java interface by OMG IDL ),
  • generate and populate stub code(on Ejb this is gratis with Runtime Stub Generation/Downloading feature).
  • generate and populate skeleton code(on Ejb this is gratis with Runtime Skeleton Generation feature).
  • for a server-to-server communication is a good choice ejb-to-ejb communication, and support distributed transaction managed by conintainer.
  • The EJB CMT Feature (EJB container managed transaction inbound outbound) is power feature.

An interesting project is jakarta-RPC but in this moment is very distance from Remote EJB.

 

Best regards

Angelo Rubini

 


Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di Steve Millidge (Payara) via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: venerdì 28 luglio 2023 19:26
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

Agree it is also used by a lot of Payara customers.

 

 


From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Brian Stansberry via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Sent: Friday, July 28, 2023 6:17:47 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

Agreed. The WildFly and EAP implementation of remote EJB is very heavily used.

 

On Mon, Jul 24, 2023 at 10:15 PM David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

I also know quite a lot of people using remote EJBs in their backend architecture.  It’s a perfectly valid usage.

 

Reminder to everyone as well, remote EJBs != binary protocol.  Implementations can use any protocol they want (REST included).

 

I know we have a ton of features in OpenEJB's protocol around optionally layering over http, client-side load-balancing, dynamic client/server discovery over UDP or TCP, sending updated lists of available servers to clients as part of routine responses, robust failover options, security features, observable events for all internal activity, metrics built into the protocol that allow for end-to-end awareness of serialization time vs invocation time vs network time.

 

Definitely I’d use Jakarta REST for anything a 3rd party would invoke, but for internal communication you can get some amazing features out of remote EJBs.

 

 

-- 

David Blevins

 

On Jul 24, 2023, at 11:43 AM, lenny--- via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

 

Well put.

💯



On Jul 24, 2023, at 1:41 PM, Doyle, James, K via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

 

Hi,

 

I’d just like to chime in as a long-time Java EE / Jakarta EE user.  Our organization has a large, critical application that has used remote EJBs for many years, even as we changed implementations (WebLogic, JBoss).  I agree with the ease-of-use of remote EJBs, particularly for internal applications where we control the client and server, and have had similar thoughts about the future of Jakarta EE and EJB.  We could move these services to HTTP REST on top of JAX-RS.  But the simplicity of declaring a Java interface of methods and programming the client and server directly to it has been fairly productive for our developers, and would be missed if we used REST as the replacement.  I’ve been wondering whether there would be a successor to remote EJB functionality, since it’s been said that remoting is not a goal of CDI.

 

Thanks,

Jim Doyle

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxxOn Behalf Of lenny--- via jakartaee-platform-dev
Sent: Friday, July 21, 2023 11:42 PM
Subject: Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?

 

What I am specifically talking about is RPC as implemented by Remote EJB part of the spec.

I remember those days very fondly where you can just call remote methods with two annotations, and it actually worked and was easy!

 

 

On Jul 21, 2023, at 8:51 PM, hantsy bai via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

 

Java EE includes a XMLRPC before SOAP, personally I do not think RPC should be back again.

 

---

Regards,

Hantsy Bai

Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker

 

 

On Sat, Jul 22, 2023 at 12:37 AM Romain Manni-Bucau via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Doesnt RPC means nothing? Some will say GraphQL (others will hate it), some will say gRPC (same), others will say JSON-RPC, others will just bring back SOAP to life.

RPC is likely a synonym to "single endpoint for multiple handlers" but without a format (JSON in EE for ex to stay consistent) and a transport it is undefined and hard to integrate (as were remote EJB between services when not the same vendor and version).

So on EE side the one making the most sense is likely JSON-RPC since it will enable to be interoperable and optimized but guess it can start a lot of debates we should maybe avoid to work on a stronger and lighter platform instead?


Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

 

 

Le ven. 21 juil. 2023 à 17:54, Lenny Primak via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :

Yes, Payara has EJB over HTTP and gRPC currently, but that’s proprietary. 

I think there should be some kind of RPC plan post-EJB on the spec level. 

 

On Jul 21, 2023, at 10:41 AM, Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:



Hi,

 

On Fri, 21 Jul 2023 at 01:14, <lenny@xxxxxxxxxxxxx> wrote:

Just out of curiosity, is EJB-deprecation-in-favor-of-CDI going to contain RPC of some kind?

 

EJB Lite would not, as Remote Beans are only in EJB Full. EJB Full is way too complex I think to ever rebase on CDI without making it a totally different spec.

 

Listening to the industry “weak signals” it sounds like RPC is coming back into fashion.

Would hate to miss that hype, especially that remote EJB-type RPC already exists and well-understood and tested…

Bring back remote EJBs? in CDI form?

 

I did something in Payara that approximated this. There were plans to take that even further, but you know how these things go.

 

 

Kind regards,

Arjan Tijms

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


 

--

Brian Stansberry

Principal Architect, Red Hat JBoss EAP

He/Him/His

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


Back to the top