| Re: [jakarta.ee-community] About Profiles / Servlet API |
That is one of those "Marked for Removal" things we heard Java 9 introduced:While JAXB and XML support may not matter to RESTful services entirely based on JSON some APIs that support both (I know e.g. Professional Social Networks like LinkedIn or XING offer both) won't work from Java 10 onward at least not without extra dependencies.That will certainly affect those parts of the Full Jakarta EE stack that use XML whether it's config files or business payload.I can't say if some protocols are also up for pruning in Java 11 or beyond but I would not be surprised either.Werner
_______________________________________________On Wed, May 23, 2018 at 1:57 PM, Werner Keil <werner.keil@xxxxxxxxx> wrote:Of course I would not bet that Oracle still offers some of these protocols in the JDK by default.Even something as trivial as JAXB/XML/XSD support failed when I tried to run it in Java 10 while it works for 8 (have not tried 9)Werner
On Wed, May 23, 2018 at 9:18 AM, Mark Little <mlittle@xxxxxxxxxx> wrote:I could argue this either way given how I've seen customers and
community use JBossAS over the years but putting my "no JAX-RS or
friends in the Core" hat on for a second, you could always say that no
matter what we do there's always implicitly the low level UDP/TCP
stacks provided by the JVM available to the Core developer should they
somehow feel they only want to use it, e.g., if there's a need for a
bootstrapping/handshake effort within whatever application they're
building.
Mark.
On Wed, May 23, 2018 at 6:56 AM, Ondrej Mihályi
<ondrej.mihalyi@xxxxxxxxxxx> wrote:
> To be honest, no, I don't think that any network API should be part of the
> core, at least not initially. I think that the core should be used in any
> usecase therefore I suggest including only cross-concern functionality
> (config, security, etc.) I see the core profile as just a common base for
> other profiles and not as a separate profile for building applications.
>
> Best regards,
> Ondrej Mihályi
> Senior Payara Service Engineer
> Payara Server – Robust. Reliable. Supported.
> E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
>
>
>
> Od: Guillermo González de Agüero
> Odoslané: utorok 22. mája, 21:38
> Predmet: Re: [jakarta.ee-community] About Profiles / Servlet API
> Komu: Jakarta EE community discussions
>
>
> This sounds pretty balanced. Do you see space on that core for a low level
> network api like Markus suggests? Or could it eventually interfere with e.g.
> a serverless profile?
>
> El mar., 22 may. 2018 16:25, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
> escribió:
>
> I agree that it makes sense to define what's Core and Complete profiles,
> though it may not make sense to use just Core or all of Complete to build
> and run applications. Rather, I think about them as a reference to be used
> for other profiles. All profiles should share core principles (Core
> profile). The Complete profile would define how all individual components
> should integrate, e.g. in case we want to combine 2 or more profiles or
> assemble a custom profile.
>
> The Core should really be just core, with only general-purpose components
> like DI (a subset of CDI), Config, Security, Testing, Logging, etc. There's
> no point in adding Servlets or JAX-RS or even asynchronous processing into
> the Core as it may not fit all use cases.
>
> On the other side, the Complete profile wouldn't be meant to be used in
> production and maybe only the RI would implement all of it. Most of the
> other implementations would be of a specific profile or multiple profiles
> for the usecases they aim at.
>
> Cheers,
> Ondrej Mihályi
> Senior 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: 22 May 2018 13:54:56
>
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
> I can see profiles that would not benefit from the Core, whatever that is,
> but then what is the platform we are defining? Is it simply a collection of
> specifications for which there is no common foundation (other than Java SE)?
> I don’t think that could be called a platform, do you? What is a platform?
>
> The other side of this coin is the “Full” or “Complete” profile. It has
> been suggested that the Complete Profile be a specification that bundles all
> of the specifications together and defines how they interoperate - all of
> them together. At first I thought this was over kill, but it’s actually
> another way to define the platform.
>
> Imagine that there was no Core and there was no Complete profiles. Instead
> their is a “Legacy” profile that captures the legacy Java EE platform and
> then a bunch of independent profiles like Reactive Streams, Web, REST, IoT,
> etc.
>
> Now, as a user or a vendor I want a Reactive Streams profile combined with a
> Legacy Profile. How are cross cutting concerned handled if security and
> transactions, for example, are not defined consistently across Reactive
> Streams and EJB, JMS or CDI? How do I use them in combination in a way that
> is portable?
>
> The argument for a Complete Profile is that: any new specification should
> automatically be compatable and be included in the next version of the
> Complete profile, so that portability when combining different
> specifications isn’t an issue. The argument for a Complete Profile makes
> sense if you want to ensure portability across the entire Jakarta EE
> ecosystem.
>
> The Complete Profile other side of the platform coin from Core. I don’t
> know if you can have a platform without one or the other, but I’m very open
> to hearing otherwise.
>
>
> On Tue, May 22, 2018 at 5:45 AM Ian Robinson <ian_robinson@xxxxxxxxxx>
> wrote:
>
> If we're going to set up JakartaEE to be a platform for the next 20 years
> then we're going to have to do some wildly different things alongside
> supporting what got us here in the first place. Profiles may be a way to
> help with that but not (in my opinion) if we restrict the way we think about
> them as being simple concentric circles around a single core. Different
> style of programming are going to need different profiles (defined sets) of
> technologies that may share some in common without necessarily having to
> have a single common minimum set of core technologies in all profiles.
> Reactive streams are a good example. The servlet spec (for example) is
> important to JakartaEE full and web profiles but doesn't need to be part of
> some future JakartaEE ReactiveStreams profile (if we worked on such a
> thing). It would still be part of the profiles for which its relevant
> including the full profile.
>
> I see near universal agreement that the the JakartaEE full profile will
> remain important, and it will grow. If we get new and smaller profiles right
> then they can support platform innovation without having to drag everything
> forward at the pace of the oldest. So I agree with James' final sentiment by
> thinking about it without the 4-letter c word.
>
>> I think a cloud native Jakarta EE is one that treats servlets as an option
>> chosen for the right use cases, not as a default in the core.
>
> Regards,
> Ian
>
> Ian Robinson
>
>
>
> From: James Roper <james@xxxxxxxxxxxxx>
> To: jakarta.ee-community@xxxxxxxxxxx
> Date: 22/05/2018 03:54
> Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
> Sent by: jakarta.ee-community-bounces@xxxxxxxxxxx
>
>
>
> Not sure where to put this reply since the thread seems to have split a
> couple of times, but to clarify my original suggestion.
>
> When I say synchronous communication, I'm not referring to IO. Whether the
> servlet API is blocking or not is not a consideration to me at least in
> whether it should be part of the core. Rather, the question is whether
> synchronous communication - ie, request/response, where both parties in the
> communication need to be actively participating in the communication for it
> to succeed, where one party being down leads to the other unable to proceed,
> synchronous communication is what I don't think should be in the core. The
> servlet API is inherently synchronous, if a client tries to send a message
> to a servlet, and the servlet isn't running, is overloaded, or is failing,
> the servlet won't get that message later when the problem is fixed, this is
> because it is based on synchronous (dictionary definition "at the same
> time", ie, both parties active at the same time) communication, whether it's
> using non blocking IO or not.
>
> The alternative, asynchronous communication, which typically uses message
> brokers as an intermediary transport, does not require both parties to be
> participating at the same time, so the sender can send the message
> regardless of whether the receiver is able to receive it at that time. In a
> world where deployments now consist of tens, hundreds even thousands of
> services, requiring all services to be running at the same time, which
> synchronous communication does, leads to a system that is fragile and far
> worse than a monolith. Hence, asynchronous communication is imperative in
> this world of cloud native services.
>
> I'm quite aware that Servlets aren't tied to HTTP, but they are tied to
> request/response, and this is the issue.
>
> I anticipate that in 5 years, most backend services will primarily just use
> asynchronous communication - the primary places that will use synchronous
> communication will be services that directly face users, where users need a
> timely response to their requests. In many architectures today, this is
> already the case.
>
> That's not to say Servlets are ever going to go away - it's not an either
> or, both synchronous and asynchronous communication are needed in all
> systems. But the current situation, where synchronous is the primary means
> of communication, reflected by the fact that the servlet spec is in the
> core, is coming to an end, and it's cloud native that is signalling the end
> of that. I think a cloud native Jakarta EE is one that treats servlets as an
> option chosen for the right use cases, not as a default in the core.
>
> On Tue, 22 May 2018 at 04:15, Werner Keil <werner.keil@xxxxxxxxx> wrote:
> You are aware that each of these standards are defined elsewhere (e.g.
> OASIS) therefore it is important to separate the specs (if you propose
> something underneath MQTT or AMQP this is simply the wrong place) and
> implementing solutions (this is what can be shaped or influenced here)
>
> Werner
>
>
> On Mon, May 21, 2018 at 8:05 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
> JMS is for applications accessing MOMs, which in turn use AMQP/MMQT.
> What I proposed is a layer UNDERNEATH AMQP/MMQT.
> -Markus
>
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Werner Keil
> Sent: Montag, 21. Mai 2018 19:47
>
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
> Of course AMQP / MMQT are message-based, so they are by nature closer to
> e.g. JMS.
> I can't say, what the just forming EE4J Messaging/JMS project might like to
> do about this, but having worked in a cross-cut between MQTT and JMS for
> major clients, I see potential for synergies between EE4J and IoT especially
> now they are both under the Eclipse umbrella
>
> Werner
>
>
> On Mon, May 21, 2018 at 7:37 PM, Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
> I also thought so but in fact Servlet API only works for request-response
> communication models, which is not given for at least UDP, AMQP and MMQT.
> IMHO you cannot implement AMQP / MMQT ontop of Servlet API.
>
> -Markus
>
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of Richard
> Monson-Haefel
> Sent: Montag, 21. Mai 2018 18:23
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles / Servlet API
> I’m not up to speed on everything Servlet, but I do like the idea of
> breaking it up so that you have an HTTP specific Servlet and a more general
> Servlet programming model that can be extended to the semantics of other
> application protocols. I think, to some degree, this already exists its
> just a matter of the Servlet provider supporting the stack desired (e.g.
> UDP/TCP/SCTP) and then having a higher level programming model for each
> application protocol (e.g. HTTP, AMQP).
> On Mon, May 21, 2018 at 11:07 AM Markus KARG <markus@xxxxxxxxxxxxxxx> wrote:
> I'd like to extend this idea by a new API for the UDP/TCP/SCTP layer: It
> might be useful to build the HTTP API layer (= former Servlet API) ontop of
> a new UDP/TCP/SCTP API layer which allows Servlet engines to replace the
> underlying transport technology easily. That API could wrap micro-servers
> dealing solely with data packets instead of application protocols. So not
> only HTTP would run ontop of that, but also AMQP or MQTT or even FTP. The
> bean driven by such a system would be a "Stream-let" or "Protocol-let" for
> example. So re-implementing the Servlet API would mean to write a
> "HttpProtocolLet", AMQP would use an "AmqpProtocolLet" etc. In the
> IoT-Environment this could be beneficial, and it would simply re-use the
> technical platform already existing e. g. in Grizzly.
>
> -Markus
>
>
> From: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] On Behalf Of arjan tijms
> Sent: Montag, 21. Mai 2018 17:58
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles
>
> Hi,
>
> On Mon, May 21, 2018 at 3:12 PM, Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx>
> wrote:
> I think that James didn't mean to toss out HTTP processing but that the
> servlet API isn't well suited for reactive processing. The Servlet spec is
> also huge, comparable to EJB and could be designed and split into multiple
> specs. Or even obsoleted by another more modern spec in a similar way as CDI
> is now obsoleting much of the EJB spec.
> I don't quite see the Servlet spec being deprecated / obsoleted, like EJB
> was.
> I do like the suggestion of splitting out the Servlet spec in parts.
> Specifically we could potentially have a core HTTP engine (like Netty,
> Grizzly, and Coyote), a "bare" Servlet API layer, and something like a
> higher level CDI based layer (making a simpler Servlet that's a proper CDI
> bean).
>
> Kind regards,
> Arjan
>
>
>
>
>
> Cheers,
> Ondrej Mihályi
> Senior 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:03:00
> To: Jakarta EE community discussions
> Subject: Re: [jakarta.ee-community] About Profiles
>
> James,
>
> I think you have missed something in the Servlet programming model. While
> its primarily used for HTTP requests its not bound to that model or even
> synchronous request/response messaging. Reactive Streams could work well
> within the Servlet model or form another programming model. If I’m wrong
> than Serlvets have changed more than I thought since I used them for pure
> TCP/IP processing back in 1998.
> I’m an advocate of Reactive Streams as a new
> programming/processing/messaging model, but it would be premature to toss
> out HTTP processing and Servlets in order to embrace Reactive Streams as the
> “one true” model. Having been around for a long time I can tell you that
> today’s silver bullet often becomes tomorrows legacy nightmare. I’ve lived
> through that transition at least a dozen times. There is no “one true”
> model. There is only those options that most useful now.
> I don’t believe that is the fate of Reactive Streams to become legacy, but
> at this point its not a widely adopted programming model and I think we need
> to serve the needs of the mass majority of developers who use HTTP and
> Servlets IN ADDITION TO introducing and supporting new methods like Reactive
> Streams.
> I would not make Reactive Streams a required part of the Core at this point,
> but as Reza pointed out the Core can evolve over time just as well as any
> profile. If Reactive Streams is introduced as a Specification and wrapped
> into a Profile on top of the Core, it could remain very lightweight while
> providing a powerful programming model for those interested in that
> paradigm.
> On Sun, May 20, 2018 at 9:18 PM James Roper <james@xxxxxxxxxxxxx> wrote:
> 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.
>
>
>
>
> _______________________________________________
> 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
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