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
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 --------
Date: 10/14/17 3:59 PM (GMT-05:00)
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
_______________________________________________
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