[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-community] About Profiles
|
Ondro,Those "relevant parts" would
have to be defined as part of the specs. A profile could not just
choose to pick portions of the spec without it being pre-defined by that
spec. So, maybe the SE portion of CDI 2.0 could be part of a "core
profile", but without a defined subset of Servlet, this "core
profile" would have to contain all or nothing of Servlet.
---------------------------------------------------
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/kevinwsutterFrom:
"Ondrej Mihályi"
<ondrej.mihalyi@xxxxxxxxxxx>To:
Jakarta EE community
discussions <jakarta.ee-community@xxxxxxxxxxx>Date:
05/21/2018 10:13 AMSubject:
Re: [jakarta.ee-community]
About ProfilesSent by:
jakarta.ee-community-bounces@xxxxxxxxxxx
I think for a core profile even complete
Servlet or CDI specs are an overkill. What is ths profile for? Should it
contain really what 80% of developers use or it should rather cover 80%
of their use cases? I think the first, we already have Web Profile to do
the second.IMHO, if there should be a core profile,
it should only contain relevant parts of Servlets and CDI. For Servlets:- ServletContext is valid and generous
enough- Security definitions are valid- Session tracking is probably also valid- On the other hand, Servlet, Filter and
HTTP APIs are very cumbersome, and even a blocker for some technologies
and approaches like reactive processing and NIOFor CDI:- dependency injection and contexts are
valid- but things like events, stereotypes,
decorators, portable extensions are not necessary and even very seldom
used (even if crucial in certain usecases)- new API for portable extensions introduced
in CDI 2.0 could be in core but the old API is too muchTo conclude, I would pick only necessary
parts of some specs into a core profile otherwise there's no point in having
it at all as it would already be too big to have a reasonable advantage
over Web Profile.Cheers,Ondrej MihályiSenior Payara Service Engineer
Payara Server – Robust.
Reliable. Supported.
E: ondrej.mihalyi@xxxxxxxxxxx| T: +1 415 523 0175 | M: +421 902 079 891
----------------------------------------------------------------------------------------------------------------------
Payara Services Limited, Registered office:
Unit 11, Malvern Hills Science Park, Geraldine Road, Malvern, WR14 3SZ
Registered in England and Wales: 09998946 | www.payara.fish| info@xxxxxxxxxxx| @Payara_Fish
From: jakarta.ee-community-bounces@xxxxxxxxxxx
<jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Richard Monson-Haefel
<rmonson@xxxxxxxxxxxxx>
Sent: 21 May 2018 16:15:33
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] About Profiles The Core should start out as small as possible providing
APIs that are most commonly used as a foundation for most technology domains.
Servlets serve this purpose well and should be included, but Servlets
are more akin to infrastructure for component models and processing than
they are a component model in and of themselves. Yes you can program using
the HTTP Servlet class (and even the more fundamental Servlet API) but
in most cases their is a programming model (e.g. JSP, JSF, REST ) layered
on top of the Servlet infrastructure. It’s the fact that Servlets
are foundational to many other programming models that they should be included.My recommendation is to maintain the Servlet programming
in the Core as well as the CDI model, because the CDI is so incredibly
flexible and like the Servlet model provides a foundation for many other
business components. So again, at a minimum, the Core should consist
of the following:Servlet APICDIInterceptorsAnnotationsConfigurationThere are other technologies that might be considered
such as JDBC which is the foundation of most JPA implementations and The
Connector Archiecture, which provides a very pluggable interface for other
types of systems, but the above list is the bare minimum I would start
with adding other technologies only as absolutely necessary. On Mon, May 21, 2018 at 2:50 AM reza_rahman <reza_rahman@xxxxxxxxx>
wrote:This is indeed a valid argument. I would say I am OK with
standardizing something like Netty or equivalent that is a level below
Servlet. It may be a good idea to start that discussion with the Servlet
EG. It's possible they might have an idea of how to solve this. Maybe a
Servlet Core can be evolved just like CDI now has a Core.I am not too married to Servlet the API. My main point
is to have something in the core that would be broadly (enough) accepted
as core in the server side by the market. I think in the foreseeable future,
that is something HTTP based (regardless of the threading model, flow model,
etc).It is worth keeping in mind we have always had APIs that
clearly belong mostly in Java EE but are not based on Servlet such as JPA
or JMS (both ultimately likely TCP based). Again, it's not about raw technical
merit but about market reality. To that end, while I know what you are
saying, perhaps it's a bit far fetched to think Servlet would become unimportant
to Java developers soon. Before deciding that's the case I would certainly
want to hear what the Servlet folks think. In general I have not been disappointed
in the decisions that the Servlet EG makes.Lastly, of course the core profile itself can evolve as
the market shifts (if it shifts). Even if we did start with Servlet, I
think it's reasonable to add an alternative model to the core as needed
and even deprecate Servlet if it becomes obvious that's what should be
done. Perhaps the one API to rule them all approach is also part of what
we need to think differently about? Why not just acknowledge that while
the core is minimal, that itself could be modular too.Sent via the Samsung Galaxy S7, an AT&T
4G LTE smartphone-------- Original message --------From: James Roper <james@xxxxxxxxxxxxx>
Date: 5/21/18 4:18 AM (GMT+01:00) To: jakarta.ee-community@xxxxxxxxxxxSubject: Re: [jakarta.ee-community] About Profiles Are servlets really necessary in the core? Yes, they may
have been central to Java EE for as long as Java EE has existed, but things
are changing, systems can no longer be seen is a big static state store
that can just be queried and updated with synchronous communication, rather
they are being build using streams, where the current state is in a constant
state of converging, but never actually getting there, and communication
is primarily asynchronous. Look at things like Kafka Streams and AWS Lambda
and Azure Event Grid - event based systems that are only concerned with
asynchronous messaging are rising rapidly in popularity at the moment.
And this isn't even that new, almost 10 years ago Heroku had both web dynos
and worker dynos - worker dynos had no HTTP interface, and you could argue
that deploying something that started an HTTP server to a worker dyno was
overkill. Now is a perfect opportunity to realign Jakarta EE with current
industry trends. And even for technologies that use synchronous communication,
look at the rise of things like gRPC - this does use HTTP, but not on top
of servlets. No one wants to deploy both a servlet HTTP server and a gRPC
server, that's too heavyweight. Other things like gRPC may well surface,
do we want the servlet API to get in the way of people using these new
technologies with Java EE?As a counter point against requiring servlets, the MicroProfile
messaging spec currently being developed will have no dependence on servlets,
and I anticipate that there will be many use cases where you'll deploy
services that use nothing but MicroProfile messaging for communication,
plus a database.Perhaps as little as 2 years ago, I would have agreed,
servlets are core. But I think there's a big shift at the moment, and a
decision to make servlets core today could leave Jakarta EE behind.On Mon, 21 May 2018 at 01:16, reza_rahman <reza_rahman@xxxxxxxxx>
wrote:You know I have a tremendous amount of respect for you,
but as I suggested the truth is that none of this is about technical merit.
Sometimes we really do need to just bow to where the market is driving
us and not fight it. Once we have the technology on firmer footing is the
time to explain to the marker why we are right. That's not now.The market demand from where I clearly have seen again
and again is allowing people to start with Java EE with nothing more than
Servlet and a la carte let them add whatever else on top. In addition there
is a viable smaller market for one or two sensible profiles. Right now
people also want fat jars and hollow uber jars.Giving people basically what we've been trying to push
for years plus some ability to remove things or define things is yet another
road to fighting another uphill battle that's honestly tiresome. The end
result of where we are today should be telling us loud and clear we need
to be thinking about these things differently going forward.Sent via the Samsung Galaxy S7, an AT&T
4G LTE smartphone-------- Original message --------From: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 5/20/18 4:40 PM (GMT+01:00) To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] About Profiles Hi,On Fri, May 18, 2018 at 11:30 PM, reza_rahman <reza_rahman@xxxxxxxxx>
wrote:I am totally with Mark on these particular
issues. Whatever the actual merits of the argument that we can argue endlessly,
the reality is that customers cite Java EE "weight" as a reason
to not adopt it with Docker/Cloud/Microservices, etc.It's true that this is being cited, although it's indeed
"weight' between quotes. With only a few exceptions I've seen the
actual weight (startup time / memory size / footprint on disk) of the supposedly
lighter weight solution actually been approximately the same size or even
bigger.People arguing that they use e.g. Tomcat because it starts
in 500ms and is only 7MB in size, but then they add 50MB worth of libraries
to /lib and an other 40MB of libraries to WEB-INF/lib. The combined whole
being just under 100MB in disk space.As a second point, a (standard) static config + pruning
tool would again address this concern, and I argue it can do even better
than any profile ever can.Kind regards,Arjan Additionally I believe other than minimizing
endless conflict with Spring folks over CDI, making clear what Java EE
is and how well adopted/not it is, a Servlet only core is also the right
answer to combat the criticism that Java EE is fat.Sent via the Samsung Galaxy S7, an AT&T
4G LTE smartphone-------- Original message --------From: Mark Little <mlittle@xxxxxxxxxx>
Date: 5/18/18 3:47 PM (GMT+01:00) To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] About Profiles On 18 May 2018, at 14:40, arjan tijms <arjan.tijms@xxxxxxxxx>
wrote:Hi,On Thu, May 17, 2018 at 1:46 PM, Mark Little <mlittle@xxxxxxxxxx>
wrote: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. I wonder, is there in practice any service / device where
a mere 50MB of disk space makes all the difference?You mean apart from cloud (yes, those 1 cent costs do
add up, and there’s private cloud deployments of which you may be unaware
and have some funky architectural choices behind them), IoT? Oh and maybe
it’s not just 50MB but some modern implementations can still be a bit
“plump” in some areas ;) 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.For that particular issue a static configuration (such
as liberty's server.xml and in limited way JBoss/WildFly's standalone.xml),
and/or the aforementioned prune tool would work just as well.And then we get into the world of portability. As a developer
I want to know a priori that my app will work across app servers and I
really don’t want to have to check when I do the migration. Having app
server A and B both say they support and are compliant with Profile X is
extremely useful. 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.Or a standardised static config, perhaps?And what would we call those static configs. Oh hold on,
let me suggest … profiles? ;)Kind regards,Arjan 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@xxxxxxxxxxx[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@xxxxxxxxxxx>
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 Littlemlittle@xxxxxxxxxx JBoss, by Red HatRegistered 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@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 Littlemlittle@xxxxxxxxxxJBoss, by Red HatRegistered 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@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 Littlemlittle@xxxxxxxxxxJBoss, by Red HatRegistered 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@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-- James Roper
Senior OctonautLightbend– Build reactive apps!
Twitter: @jroper_______________________________________________
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-- Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io
_______________________________________________
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