Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] About Profiles
+1

Was one of the reasons we didn’t include servlet in MP 1.0. Adoption of MP doesn’t appear to have been impacted by that decision.

Mark.


On 21 May 2018, at 16:41, Jason Greene <jason.greene@xxxxxxxxxx> wrote:

JAX-RS is quite a bit different though in that it is a closer representation of HTTP and is quite a bit more flexible. It doesn’t prescribe a particular encoding model (e.g. JAXB). One could argue it’s servlet part 2.

On May 18, 2018, at 3:56 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:

It's close but I would not include JAX-RS or JSON-P.  You know as well as I do that while JAX-RS and JSON-P is the standard today it won't be in five or ten years.  DCE, CORBA IIOP, SOAP/XML they all have a limited lifespan. 

On Fri, May 18, 2018 at 9:47 AM, Mark Little <mlittle@xxxxxxxxxx> wrote:
I'd suggest a core profile is what we aimed for with MP 1.0 :)

On Fri, May 18, 2018 at 3:43 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:


On Fri, May 18, 2018 at 8:17 AM Mariano Amar <mariano.amar@xxxxxxxxxx> wrote:
My +1 for most of the bullet points, except:

  • A vendor should have the freedom to offer the user the option of reducing/optimizing the runtime that implements a particular profile (which may be also enhanced by the vendor or the user with additional APIs), for example, by removing API implementations not in use by a particular app, or creating a runtime specific for a particular app and link externally to the deployment or bundle everything together in a fat jar, or perform any packaging optimization that can improve consumption in a containerized/cloud environment (e.g. bundle the app, the runtime and a customized version of the jvm to form an executable).
This point should NOT be part of the profiles.

I'd be very happy if we could get this one into a spec of its own, then have it added to every single profile.
I'd love to have this as a spec, mainly, because it would make it easier to move between environments/vendors/impls (or, at least, it wouldn't add another set of migration issues).
The specifics of the implementations, as always, would be left on the vendors hands, but we might be able to at least define a general definition for what we would want the mechanism to do, and maybe a couple standard config schemas (parameters, values, maybe some standard format for XML/JSON/whatever languages to use for config), that the vendor could extend as they wish... Something similar to the way the JVM is configured, where we have a set of standard params, values, gcs, etc for every JVM, then every vendor has added extras as needed/wanted.

Doesn’t the new module system cover this?



  • A vendor could offer the user the ability to create their own custom profiles by starting from scratch, in which case the resulting configuration is not considered "certified".
Just as with the previous bullet point, this is way outside of the realm of profiles.
Again, this could be a spec or project on itself, for some kind of tool or tech.


We need to keep the differences between Spec, Profile, and Impl in mind.
The profile should be the spec/doc/cert/etc that allows us to define a set of standardized platforms/environments/stacks/APIs for the Java Community to work on (be it vendors with impls and certs, or users with envs).

+1


We can't forget that profiles serve two main purposes: environment/stack standardization and certification.
Anything that strays from those two should not be considered as part of a profile, but specs and techs that could be part of, or used to extend, a profile.

+1



Also, going back to the bullet point about inheritance, I agree that we should make sure we keep the profiles as decoupled as viable, but we need to make sure of a few things:
  1. We should be careful not to end up with dozens of utterly unrelated profiles (make sure the vendor needs don't supercede the users/community needs). If every single implementation in the wild has their own profile, then profiles become pretty much worthless.

+1
  1. While we might find it very difficult, or even illogical, to keep every single profile inheriting from a base one (just to allow a certain interoperability between all profiles), we should still have at least an ordered hierarchy.
    Maybe we could define more than one "base" profile, and then sub-profiles for each base? For example, we could have a base for each type of environment/server/stack (app server, web server, mobile, cloud, desktop), which would be the equivalent of the current full profile (every single API that might make sense in that environment), then have a few pared down profiles for each (just as the web profile is a sub-set of the full profile).

I’ve always had in mind a “Core Profile”. The Core Profile is basically the absolutely minimum things that any profile should have.  There are lots of possibilities here but lets remember that the purpose of Jakarta EE is “enterprise applications” which mean that we should be thinking of compontized business logic.  Designing a profile that runs on an embedded device would be outside of that scope.  Designing a profile that allows the processing of information from a web of embedded devices would be within the scope.

If the foundation of Jakarta EE is support for business components and cross cutting concerns than the Core Profile, the profile on which all other profiles may be based, would specify one or more component models and some subset of cross cutting concerns as well as standardized configuration.  

In that case, I would suggest CDI, Interceptors, Annotations, Servlets, and Security as a minimum.  

I include Servlets because the processing of HTTP/TCP requests is at the core of so many technologies over the past 25 years.  I would not require JSP or JSF in the Core because those are specific to a web browser presentation, but any profile could add a technology on top of the Core to extend the Servlet model. The Web Profile might, for example, include the Core and JSP and JSF.  

CDI is, I think, is an obvious choice here. It’s use is rapidly spreading to everything from EJB-style business components to beans in JSF and JSP to MIcroProfile.   

Interceptors are an excellent way to introduce new functionality including cross cutting concerns (e.g. Transations). 

Finally, I think Security is the one cross-cutting concern that must be part of the Core. At the very least it should address authentication, authorization, and encryption of communications (e.g. HTTPS).

The Core Profile would not have to be the only base profile - eventually there could be another - but I think it provides a solid foundation for getting started.




  1. Following that mindset, we could still have a Full Profile at the top, then a first level of base profiles, followed by one or more levels of less general profiles (e.g., Micro as a level two subset of Cloud)

On the matter of naming, I'd always connect the term "Full Profile" to the one with every single spec, including the legacy ones (that's why it's the full profile, it has everything)
I'd call the legacy free profile something indicative of that ("Legacy Free Full Profile", and its permutations, sound horrible to me, but I can't get any better idea right now).

I prefer “Legacy Profile” for what we now call Java EE and “Full Profile” for everything all together. That idea of a “Full Profile” is important because in order for Jakarta EE to be a true platform all the different APIs have to be able to work together even if they are not specifically described within the same profile.  That way, a vendor can offer a product that supports multiple profiles without fear of conflicts between profiles.






Mariano Amar

Senior Consultant

email/hangouts: mariano.amar@wes-it.com
skype: marianoamar

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 Fri, May 18, 2018 at 6:58 AM, Dimitris Andreadis <dandread@xxxxxxxxxx> wrote:
On 18/05/2018 08:21, Richard Monson-Haefel wrote:
I have some comments in line ...

On Thu, May 17, 2018 at 7:07 PM, Dimitris Andreadis <dandread@xxxxxxxxxx> wrote:

I've posted my own summary before and didn't get any feedback, so re-posting in case it got lost in this thread. Do people agree on those guidelines related to profiles?

  • We need to define "some" profiles for certification and portability purposes.
+1 
  • A vendor may claim compliance to one or more profiles
+1 
  • Specs should have stand alone TCKs so they can be tested separately and profiles could have additional tests that test profiles as collections of APIs (profile platform tests).
+1 
  • Profiles don't necessarily need to inherit from each other, but they could.
+1  I would also say that a profile can be a combination of profiles plus some added value.  Not sure if that would be used but it should be possible. 
  • Within a profile a vendor may package a newer version of a prescribed spec, if it's compatible.
+1 IF, they also provide the older version specified by the profile or the newer version is backward compatable with the version specified in the profile. 
  • Within a profile a vendor may provide additional APIs. This doesn't change the profile itself.
+1 
  • Within a profile a vendor may let the user add support for additional APIs.
+1 
  • A vendor should have the freedom to offer the user the option of reducing/optimizing the runtime that implements a particular profile (which may be also enhanced by the vendor or the user with additional APIs), for example, by removing API implementations not in use by a particular app, or creating a runtime specific for a particular app and link externally to the deployment or bundle everything together in a fat jar, or perform any packaging optimization that can improve consumption in a containerized/cloud environment (e.g. bundle the app, the runtime and a customized version of the jvm to form an executable).
+1 I think you are talking about modules here, in which case I agree. 
  • A vendor could offer the user the ability to create their own custom profiles by starting from scratch, in which case the resulting configuration is not considered "certified".
+0 I don't know what this means so I can't support it.
People have expressed interest in building their own custom configurations/profiles by choosing an arbitrary collection of APIs. What I wanted to convey is that this is a valid usecase and a vendor may provide this ability, however, it will be clear that the resulting configuration cannot be considered Jakarta EE "certified".

Obviously the idea is that profiles provide to the users different minimum baselines they can enhance and use to build their apps in a portable fashion, while giving enough space to Jakarta EE implementors to compete and innovate on features and performance/deployment optimizations.

As to what the exact profiles should be, if we believe that backwards compatibility is important, we should provide the existing

  • Java EE Full profile, (Jakarta EE Full Legacy profile?)
  • Java EE Web profile, (Jakarta EE Web profile, if still relevant)
+1 

Then for new apps we should be probably looking at new/modern:

  • Jakarta EE All profile, with non needed legacy APIs removed and new ones (possibly) added
  • Jakarta EE Micro profile, geared towards microservices
+0 I don't know about the "All" profile or at least the name of it.  Seems like this would simply be a new profile - why call it "All"?
In absence of a better name, this is just indicative :) We basically need a name to indicate this is the new "Full" profile with all the interesting/active existing EE APIs plus the Microprofile ones, but we also want to distinguish it from the existing (or lets say legacy) Full.

We could just as have, Full & Full Legacy to distinguish between the two.


Again, profiles could inherit from each other, but I don't see that as a requirement, while the proposed names are just indicative.

Cheers

/Dimitris

Dimitris Andreadis
Engineering Director
Red Hat JBoss EAP/WildFly
On 17/05/2018 15:48, Kevin Sutter wrote:
+1, Mark.  We (IBM) were able to capitalize on the defined WebProfile for Java EE 6 for our early WebSphere Liberty offerings.  Our customers were demanding "Java EE" for Liberty, but we knew we couldn't deliver the full platform in these early releases of Liberty.  (Actually, we didn't even know if we *wanted* to deliver the full Java EE platform on Liberty at that time...)  Having a defined WebProfile in Java EE 6 allowed us to satisfy these customer requirements in a timely manner.  We were able to pass the defined subset of CTS/TCK tests for the WebProfile and this defined compliance with the standard provided the necessary assurances to our customers that Liberty was a real application server.

Since that time, we have decided that Liberty should also be compliant with the full platform.  But, that decision would not cause us to promote a single profile (or platform) for Jakarta EE.  We need subsets of functionality defined as profiles to allow more flexibility for both the developers/vendors implementing the technology and the customers that consume the technology.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        Mark Little <mlittle@xxxxxxxxxx>
To:        Jakarta EE community discussions <jakarta.ee-community@eclipse.org>
Date:        05/17/2018 08:28 AM
Subject:        Re: [jakarta.ee-community] About Profiles
Sent by:        jakarta.ee-community-bounces@eclipse.org



Dominik, you may feel that my examples are not valid but that doesn't
mean they are actually invalid :) The discussions around profiles date
back many years in the JCP and unfortunately I'm not able to check at
the moment as to whether those were public. But suffice it to say we
(Red Hat), IBM, Oracle and many others here, including users, provided
examples of why profiles were a good thing and necessary based on many
many years of real world use cases and thousands of customers asking
for precisely that sort of thing. As I said earlier though, you are
not alone in only wanting to have the full profile and that's fine
too. Maybe others, such as Tomitribe who only provide the WebProfile,
will chime in with some examples of their own but I can tell you that
since Red Hat implemented both the WebProfile and full profile in our
community and product app servers we have seen significant adoption of
both and those developers make the choice based on some of the reasons
I gave and they clearly understand why and believe their actions are
valid too :)

Mark.

On Thu, May 17, 2018 at 1:59 PM, Dominik Hufnagel
<mail@xxxxxxxxxxxxxxxxxxx> wrote:
> Well, there certainly are users which are not happy with just the full
> profiles and I am sure there are reasons. I do not say there is no need for
> more profiles, but until now I have not seen reasons for it, which justifies
> it.
>
> For me, your arguments do not justify the complexity for users having to
> choose between profiles. If I start a project and having to make decisions
> on what profile to use, how would that be less expensive than running a
> cloud machine with 50MB more for years? Let’s take AWS for example, where a
> block storage costs about 0.1-0.2$ per GB per Month.
>
> Regarding boot times, may you/one can specify what fast means? I have a
> wildfly app booting in < 10 seconds where a spring boot app I am currently
> working on (with almost just REST interfaces) needs > 15 seconds to boot.
>
>
>
> If you think about the buzzword IoT, then clearly the full profile may not
> suit. But I am not sure if this has to be covered under Jakarta EE.
>
>
>
> I am with you in terms of complexity and portability. For small
> applications, where mostly one war or app is deployed, it would be
> beneficial to be able to configure the Application Server (DB, JMS-Queues,
> …) with any mechanism from inside the war (let’s say a properties file or
> something). I would love to see such mechanisms in Jakarta EE, but this is
> not really related to profiles.
>
>
>
> I also think it would be beneficial to have a legacy profile for the stuff
> that is not anymore ‘state ot the art’, so that the main profile could be
> more lean.
>
>
>
> To be clear: I have no final opinion about this topic yet. I just like to
> see some valid arguments for having more profiles or for not have more
> profiles. What I also did not see in this discussion so far, are examples
> for profiles and how they fit together. This would help getting a clearer
> image of the needs from those who argue for having more profiles.
>
>
>
> Dominik
>
>
>
> Von: jakarta.ee-community-bounces@eclipse.org
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] Im Auftrag von Mark Little
> Gesendet: Donnerstag, 17. Mai 2018 13:47
>
>
> An: Jakarta EE community discussions <jakarta.ee-community@eclipse.org>
> Betreff: Re: [jakarta.ee-community] About Profiles
>
>
>
> This isn’t just about vendor choice. You are certainly not alone in being
> happy with the full profile option. However, there are other classes of
> users/developers that aren’t and these have existed since the dawn of J2EE.
> For example, some people want to deploy their favour app server on to
> constrained devices which may be running on the cloud where an additional
> 50MB costs real money when run for hours or days or weeks or longer. Some
> developers want to reduce the maintenance complexity or boot time of their
> favourite app server by stripping out those capabilities they don’t want.
> Now you could argue that these developers could just do this themselves
> anyway, e.g., JBossAS has supported this kind of pruning from the start.
> However, if you want portability and interoperability of your apps so you’re
> not tied to a specific app server implementation/vendor, having standardised
> profiles is the right approach.
>
>
>
> Mark.
>
>
>
>
>
> On 16 May 2018, at 23:16, Dominik Hufnagel <mail@xxxxxxxxxxxxxxxxxxx> wrote:
>
>
>
> As a user of JavaEE, I do not get the idea behind having multiple profiles.
> May someone can explain the benefits for users? If I can have a single
> profile with all available features, I would take it and I do not bother
> using a server which is 50MB larger of one with a „smaller“ profile. I can
> understand that it could be harder for vendors to enter the market having to
> provide the full profile. But for me, this would not be an argument for
> using smaller profiles. I’d rather take a server from a vendor which offers
> me the full profile.
>
>
>
> If I would use the MicroProfile and want to have JPA, do I have to add
> external dependencies? I really like some of the new APIs of the
> MicroProfile and would be happy to see them coming to JakartaEE.
>
> Dominik
>
>
>
>
>
> Von: jakarta.ee-community-bounces@eclipse.org
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] Im Auftrag von Mark Little
> Gesendet: Mittwoch, 16. Mai 2018 11:42
> An: Jakarta EE community discussions <jakarta.ee-community@eclipse.org>
> Betreff: Re: [jakarta.ee-community] About Profiles
>
>
>
> Hopefully others have responded already but … it’s for both: quick summary …
> vendors so they can ensure conformance and users so they can ensure
> portability and interoperability of their apps.
>
>
>
> Speaking with my MicroProfile hat on, I for one would not want to trade the
> current MicroProfile for a full Jakarta EE profile and neither would our
> users.
>
>
>
> Mark.
>
>
>
>
>
> On 7 May 2018, at 17:33, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
>
>
>
> So then the first question is perhaps; who wants profiles and benefits from
> it? Is a profile intended for vendors or for users?
>
>
>
>
>
> ---
>
> Mark Little
>
> mlittle@xxxxxxxxxx
>
>
>
> JBoss, by Red Hat
>
> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
> Road, Co. Cork.
> Registered in the Companies Registration Office, Parnell House, 14 Parnell
> Square, Dublin 1, Ireland, No.304873
> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
> Keith Phelan, Matt Parson (USA)
>
>
>
> _______________________________________________
> 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
>
>
>
> ---
>
> Mark Little
>
> mlittle@xxxxxxxxxx
>
>
>
> JBoss, by Red Hat
>
> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
> Road, Co. Cork.
> Registered in the Companies Registration Office, Parnell House, 14 Parnell
> Square, Dublin 1, Ireland, No.304873
> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
> Keith Phelan, Matt Parson (USA)
>
>
>
>
> _______________________________________________
> 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


_______________________________________________
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


_______________________________________________
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
--
Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io


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

---
Mark Little

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

Back to the top