Re: [ee4j-community] Tomitribe commitment to EE4J

[reza_rahman <reza_rahman@xxxxxxxxx>]

Let's leave it alone. From my previous go at this, I am convinced discussing any of this in the CDI EG is a big waste of time.

I am sure all of it is fine in Java EE Concurrency. It's not too far fetched to think of pooling as an aspect of managing concurrently accessible resources.

Pooling has only very superficial similarities to bulkheads. The use cases as already explained by others is vastly different.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: "John D. Ament" <john.d.ament@xxxxxxxxx>

Date: 10/16/17 7:17 AM (GMT-05:00)

To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>

Subject: Re: [ee4j-community] Tomitribe commitment to EE4J

Reza,

Which *this* are you referring to? Pooled/PoolScoped?

At least one of my hopes is that CDI defines what the programming model looks like, not every feature of the programming model.  For CDI to take on pooling for instance, means that the support of pooling comes from the CDI spec, which is effectively one of the problems faced by the EJB spec - it defined too much.  CDI has already gone to far lengths to define this model, so I would hope its up to another spec to define how its used.  This also works hand in hand with some of the other callouts I've seen on this list - modularity in particular.

In Eclipse MicroProfile, we may have defined that pooling replacement already.  The classic example of a pool is effectively what is now coined as a bulkhead - limiting concurrent access to a single entry point.  We have annotations that define the concurrent accessors of the bean.  It hopefully shouldn't matter if its one instance or 10 instances to the caller, they all have to be modeled in a stateless fashion.

John

On Sun, Oct 15, 2017 at 9:04 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:

When I/others suggested this to the CDI EG in the past, they resisted for what seemed to me like non-technical reasons. Maybe they will change their mind this time and see reason. We can hope. Other than CDI, I don't even see where else @PoolScoped would fit.

I don't actually mind just throwing it in with the rest into Java EE Concurrency. What matters is making the functionality available to end users in the end.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------

From: arjan tijms <arjan.tijms@xxxxxxxxx>

Date: 10/14/17 3:59 PM (GMT-05:00)

To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>

Subject: Re: [ee4j-community] Tomitribe commitment to EE4J

Hi,

On Sat, Oct 14, 2017 at 8:07 PM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:

Personally I think @Pooled/@PoolScoped is best in CDI. The remainder of the EJB functionality can be pretty cleanly farmed out between Java EE Concurrency and JMS/JCA.

Despite the fact that we seem to want to make CDI somewhat smaller, I think this is indeed a very good suggestion. Thx! @Pooled feels basic enough to warrant being in CDI core indeed.

Things like the build-in beans for Principal and HttpServletRequest should really be moved to the specifications that own these artefacts in the first place. I already proposed for Java EE Security taking ownership of the Principal build-in bean.

Kind regards,

Arjan Tijms

 

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