| Re: [jakarta.ee-community] @DataSourceDefinition |
We should be careful by making the specs to dependent on each other.My current client just uses JAX-RS in an OSGI environment. I don't think they like the fact that they have to add some additional specs/implementions to the mix._______________________________________________On Fri, 22 Jun 2018 at 01:23, Werner Keil <werner.keil@xxxxxxxxx> wrote:More precisely the whole javax.ws.rs.core.SecurityContext; is redundant in JAX-RS now, and should either at least extend the one from ES or be replaced by it whichever is technically more feasible._______________________________________________Werner
On Fri, Jun 22, 2018 at 1:19 AM, Werner Keil <werner.keil@xxxxxxxxx> wrote:And so should be an alignment between Enterprise Security (JSR-375) and JAX-RS, deprecating and eventually pruning redundant methods like isCallerInRole() now in SecurityContext.On Fri, Jun 22, 2018 at 1:09 AM, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:Password aliasing was dropped due to lack of time/resources. It's another thing that should be solved with Jakarta EE.
On 6/20/2018 4:15 PM, Guillermo González de Agüero wrote:
El mié., 20 jun. 2018 a las 21:43, Bill Shannon (<bill.shannon@xxxxxxxxxx>) escribió:
arjan tijms wrote on 06/20/18 09:05 AM:
> Hi,
>
> There's not necessarily a problem with @DataSourceDefinition being in the
> Common Annotations spec, although there is the mentioned issue with
> configurability and the generic attributes that the @DataSourceDefinition
> takes without specifying whether and how they should go to the pool vs the
> data source.
Some of this is unspecified or weakly specified because there was no agreement
among vendors as to how it should work.
>
> I'm a great fan of @DataSourceDefinition, but it has always been a bit of an
> issue that it essentially merges two other concepts in one; the data source
> and the connection pool. Many other proprietary mechanisms (like for example
> GlassFish) have two separate definitions for that.
It's always seemed like a feature to me that you only have to deal with one
concept instead of two.
I'm with you. I have always used the GlassFish connection pool+resource with a 1:1 relationship.
>
> Additionally, a small data storage spec might be orthogonal to the
> requirements of evolving @DataSourceDefinition, but these two efforts might be
> combined. Although it's just a proposal, I was half thinking about a
> replacement @DataSourceDefinition that does have the separate pool and data
> source concept, together with an actual available (embedded) database. As you
> know all too well (you closed my issue for it back then :P) Java EE doesn't
> really have a runtime available database, even though it's generally thought
> it has one.
I'm not sure what you're referring to since Java EE has always required that a
database be part of every configuration. We can't guarantee that the database
server is up, that the network cable is connected, the disk isn't full, etc.,
but it has to be possible for the customer to address all these "availability"
problems and then use the database.
>
> At the same time, our friends from Apache/TomEE, Mark Struberg and Romain,
> have been crying for over a decade now that @DataSourceDefinition is
> absolutely bad and can't be used for anything. While I respectfully disagree
> with that (we've used @DataSourceDefinition for tons of real life projects),
> it might be interesting to finally get to the bottom of what these two are
> actually complaining about, and see if we can address that.
If they've been standing on the street corner and shouting into the wind, I
haven't heard it. If there are real issues, I very much would like to hear them
and hopefully they can be addressed in Jakarta EE.
The addition of the Config API to Jakarta EE would help us address many of these
issues.
Interestingly, password aliasing was already discussed for Java EE 7 (https://github.com/javaee/javaee-spec/blob/master/download/password-aliasing-ee7-proposal.pdf). I wasn't there at that time. Does anybody know what happened to it?
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community