Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] About Profiles

Unfortunately Java Jigsaw does not go as far when it comes to proper module isolation as say OSGi, but it also defines a certain level of exposed or consumed modules.
Therefore it should not be a problem if e.g. a certain implementation used a JPA or persistence mechanism under the hood while the actual business application uses another one. I work with Keycloak right now and it also comes with Hibernate, but our business code uses other forms of persistence. 
If Keycloak was to implement JSR 375 some day as user of the JSR 375 API you may also find such implementation to use Hibernate or other ways to access its IdentityStore, but that does not mean you also have to use the same JPA implementation in your application.

Werner



On Wed, May 9, 2018 at 9:52 PM, Mrinal Kanti <design@xxxxxxxxxxx> wrote:
What about service providers (say, caching)?

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)?

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)?

-Mrinal

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-community



_______________________________________________
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-community



_______________________________________________
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-community



Back to the top