I disagree with bundling things into a deployment. Personally I am in favour of managed runtimes and thin wars. I know many people do like self assembly of their runtime mixed into their application
however I don’t feel that is ultimately the best direction for Jakarta EE.
Similarly I think the APIs should be consistent across the whole of Jakarta EE. Cross cutting concerns like security should be implemented once and all other specs should depend on that api. Personally
I’m not in favour of specs striving to be standalone if it detriments platform consistency.
Steve
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx>
On Behalf Of Guillermo González de Agüero
Sent: 22 June 2018 09:09
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] @DataSourceDefinition
As long as the specs are just CDI extensions that can be easily plugged in and upgraded, I don't see an issue with splitting them.
The problem comes when specs are forced to be bundled in the server (think EJB, Servlet) and you have no way to add some missing API, or you're just stuck with an old version.
If I had a "JAX-RS Profile" server and then I had to move to another profile to add security facilities, then I'd agree with the concern. But if that's a matter of adding a new "security" dependency to my war and nothing more, I don't see
any drawback, but a great benefit in consistency between APIs.
Guillermo González de Agüero
We need to find a balance between the required dependencies and the independence.
Because otherwise there is no point in having profiles for instance if everything is linked to everything. Then you only have one thing called full.
You could ask yourself; does Spring MVC has its own security methods, or is it dependent on Spring Security? And in
ASP.NET MVC, does that have its own security methods, or does it depend on the facilities from .NET?
Or look at it from another point of view.
Does JAX-RS needs its own persistence, or does it depend on JPA and JDBC for that?
If it doesn't have its own persistence, and its okay to depend on something else for that, why isn't it okay to depend on something else for security?
Yet another point if view: should JSF introduce its very own security system? If not, why is this not okay for JSF to do, but is it okay for JAX-RS?
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.
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.
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:
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.
_______________________________________________
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
_______________________________________________
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
|
