| Re: [jakarta.ee-community] About Profiles |
And yes, a lot of this is taken from (and perhaps echoing) what Jason Greene started with the thread "A Composable Platform Over Profiles". A significant difference being that I am talking about specific versions of specs which are certified to work together with a given Jakarta EE version rather than certifying their combination at a minimum version level assuming backward compatibility. Of course, the app server vendor would have to certify their choice of implementations across their application platform for any given version of Jakarta EE.-MrinalOn Thu, May 10, 2018 at 4:09 AM, Mrinal Kanti <design@xxxxxxxxxxx> wrote:This is very similar to how applications are certified on any Linux distribution even when different distributions may have different set of packages in their profiles (such as desktop or server). In this case, the packages that each distro bundles in a profile (say desktop) vary greatly from vendor to vendor. But since applications are certified against the platform (rather than a profile) things work consistently across all possible combinations of packages.Each app server vendor would have their own Equinox P2 (or some form of OBR) repository with certified implementations of specs for any given Jakarta EE version. If this can be achieved, then perhaps we won't even need profiles. Solution providers would just need to certify their solutions on app server vendor's platform version (associated with Jakarta EE version) rather than certifying it on various Jakarta EE profiles (such as web, full etc.).All that app server vendors would have to do is to provide a light-weight kernel (something similar to WSO2 carbon) and a standard way to pull in the relevant bits via a product configurator which can be commonly used for introspecting dependencies for Jakarta EE apps as well as vendor's container services and for third-party service providers.So if we approach Jakarta EE profile in the lines of an Eclipse package distro, a lot of those inconsistencies (in terms of different implementations) can be avoided within the ecosystem of a single app server vendor (read their enterprise platform). Whether its a app server vendor providing distinctive value added container services on top of various low level Jakarta EE specs or various third party service providers providing their niche services on the enterprise platform - everybody would have a single repository to pick the certified implementations (not just specs) so long as they are in the same app server vendor's application platform within any given Jakarta EE version.The current Eclipse platform with the Equinox P2 repository addresses this very efficiently. Even though we have multiple official "eclipse packages" - consisting of various combination of features, everything just works consistently for everyone - whether developers using it as an IDE or RCP app builders.Thanks Mariano for addressing it from multiple perspectives.I am trying to emphasize that we should also take the implementations into consideration rather than just talking about the profile as a certified aggregate of individual specs. By implementation, I mean not only implementations of specs, but also value added container services for each app server vendor and external service providers.Implementing a similar approach in Jakarta EE would mean standardizing on the concept of such a repository which could be consistently implemented across "application platforms" of each vendor. Osgi already provides much of the foundation for implementing this and we already have WSO2 taking a step in this direction with their middleware platform.-MrinalOn Thu, May 10, 2018 at 2:27 AM, Mariano Amar <mariano.amar@xxxxxxxxxx> wrote:@MrinalJust to do the TL;DR version:You have only three possibilities, and two of them depend on the client using your implementation:1) The client is a server/profile/etc vendor: It's their job, as the vendor integrating your implementation as part of their server/platform/service, to find out any deps your solution needs. If they don't, their solution won't even run, much less pass the TCKs needed for their certification.2) The client is going to use your implementation as part of their non-server product: They'll be embedding your solution into theirs, so they won't be using straight JPA calls, or they'll define their profile from the get go based on what they need.3) You want to give both the possibility of JPA calls, or an in-built solution: You'll provide some way of configuring your implementation to switch between hardcoded calls to your in-built solution and whatever JPA impl is in the environment.AVISO DE CONFIDENCIALIDAD DE CORREO ELECTRÓNICO
Esta comunicación contiene información que es confidencial y también puede contener información privilegiada. Es para uso exclusivo del destinatario. Si usted no es el destinatario tenga en cuenta que cualquier distribución, copia o uso de esta comunicación o la información que contiene está estrictamente prohibida. Si usted ha recibido esta comunicación por error por favor notifíquelo por correo electrónico(info@xxxxxxxxxx) o por teléfono (+54 11 3249 7503)
This communication contains information that is confidential and may also be privileged. It is for the exclusive use of the recipient. If you are not the intended note that any distribution, copying or use of this communication or the information it contains is strictly prohibited. If you have received this communication in error please notify us by email(info@xxxxxxxxxx) or phone (+54 11 3249 7503)
On Wed, May 9, 2018 at 5:46 PM, Mariano Amar <mariano.amar@xxxxxxxxxx> wrote:@MrinalThe profile doesn't *handle* anything. It's just a spec/cert that you check for.If you are a vendor implementing your own jakarta server, then you'll make sure all your fiddly bits integrate correctly (or, at least, good enough to pass the TCKs needed to tack that "JakartaEE Profile X Certified" badge on the tin). If you ever change any of your libraries/modules (be it home grown or a third party), you'll have to re-check for that cert, so that's still on the vendor.If you are a vendor of any solution that will run on a server, and you have a hard dependency on a specific JakartaEE API, then you will explicitly document your unmet dependencies, or provide your own (and then hardcoding over it). That way, your users know what they need to look for in their servers/providers.On the same page, if you are a JakartaEE user of any kind, you'll need to make sure you are running the app on a stack with the correct APIs available, be it by using a server with a certification for a complete enough profile, or by (once again) providing your own.The only relevance profiles have on this is as lists of available APIs on your current environment, for you to provide any missing deps you might need.Following your example:1) If you have a caching solution, with your own JPA certifiable implementation of persistence, why would you care if the environment has JPA? You're still going to use your home-grown solution.2) If you will work directly over the JPA API, then you wouldn't care about shipping your own implementation of that. You'd tell everybody they need JPA in their environment for your solution to work. Then, it'll be irrelevant what profile or environment the user is on, as long as they make sure to have a JPA implementation available.3) If you want to distribute your home-grown solution as another JPA implementation, you're free to do so, separately from your Cache solution. Then, it follows the same logic as (2)4) If you want to have both general JPA use, and your homegrown solution embedded into your caching solution, then you also build in some logic for the user to configure which one they want to use (or, if you're daring enough, for your solution to find out which option to switch to based on the current environment), and then switch between straight calls to the JPA API, and calls to your embedded solution accordingly.None of this is changing, since this is how Java works (add implementations to the classpath/modpath, then call their APIs from your code), irrelevant of what we want to do with JakartaEE.The point of profiles is to not just know an implementation of an API works on spec, but that your environment won't implode because of weird interactions *between* those implementations.You still need to know the list of deps you need for anything to run correctly. Profiles just reduce your list from a hundred versioned deps, to a single (or more, depending on the solution we end up mostly agreeing on) versioned profile cert, plus a few dozen non-spec versioned deps.AVISO DE CONFIDENCIALIDAD DE CORREO ELECTRÓNICO
Esta comunicación contiene información que es confidencial y también puede contener información privilegiada. Es para uso exclusivo del destinatario. Si usted no es el destinatario tenga en cuenta que cualquier distribución, copia o uso de esta comunicación o la información que contiene está estrictamente prohibida. Si usted ha recibido esta comunicación por error por favor notifíquelo por correo electrónico(info@xxxxxxxxxx) o por teléfono (+54 11 3249 7503)
This communication contains information that is confidential and may also be privileged. It is for the exclusive use of the recipient. If you are not the intended note that any distribution, copying or use of this communication or the information it contains is strictly prohibited. If you have received this communication in error please notify us by email(info@xxxxxxxxxx) or phone (+54 11 3249 7503)
On Wed, May 9, 2018 at 4:52 PM, Mrinal Kanti <design@xxxxxxxxxxx> wrote:-MrinalWhat about service providers (say, caching)?Should the Jcache implementation ship it own version of JPA (and its implementation)? If so, then what happens when the user upgrades their application from one profile (which does not have JPA) to another (that has JPA)?
How about the scenario when the spec implementation refers to other specs which are not referred in the spec itself. For example, if a Jcache implementation uses JPA to persist cached objects (for distributed access or failover) then how would the profile handle this (assuming Jcache spec has no association with the JPA spec)?On Wed, May 9, 2018 at 10:44 PM, Scott Stark <sstark@xxxxxxxxxx> wrote:A given distribution incorporating implementations from different vendors is just a detail. What matters is that the distribution has gone through the trouble of certifying the behavior of a test suite/TCK for a profile that provides some level of confidence that a user can write applications that combine a the apis from a profile and have the app run on different distributions.This is also the point of profile specification in my view. A given spec should not be making references to every other possible spec they can be combined with. Rather, a profile specification should define the integration requirements and have corresponding TCK tests for validation of those requirements.On Mon, May 7, 2018 at 10:34 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:Hi,On Mon, May 7, 2018 at 7:14 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:...I believe that Glassfish and IBM fully implement Java EE 8 but no one would be required to implement the full profile.They provide the full platform, but don't implement it fully themselves.GlassFish for instance bundles Weld (CDI), and Hibernate Validator (Bean Validation).IBM bundles MyFaces (JSF), OWB (Weld), EclipseLink (JPA), BVal (Bean Validation), etc.That’s the whole point of having sub-profiles.That's more the definition of a sub-profile, not necessarily the point of it ;)I'm not sure if a bloated product line-up with a dozen profiles really makes things easier for users.It’s not boated, it simple the largest profile from which the sub-profiles are derived.Just to be sure, I didn't mean the full profile is bloated, but that having a plethora of different profiles makes for a bloated product line-up.I was just remembered today about the many models that Apple had in its line-up before Steve Jobs returned. One of the first things Steve Jobs did was to slash all those barely different models (essentially, "profiles" of a base Mac model), and simplify things by having a small product line-up.Kind regards,Arjan
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y