| I agree that there shouldn't be duplication of functionality (or similar functionality) across different Specs. If a spec, such as JAX-RS, requires functionality of another spec (such as the Security API), then make it an optional soft dependency. That way if the developer does not wish to use the Security API, they wouldn't have to include it.
Think of it this way...if a security vulnerability were found in an API, it is much easier to deal with it in the one API, rather than search for other specs that have similar implementations or duplicate functionality.
To the root of the discussion, it seems to make sense to have a resource spec that could define general functionality and configurability for things like @DataSourceDefinition.
Agreed that a platform needs consistency with respect to the cross cutting concerns of the platform, and what those concerns are should be called out in the various profile level specs.
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
|
