|
To be honest with you, I opposed not
including Servlet in MicroProfile too. The reason for this is
twofold and nothing much to do with just the bare technical merits
of Servlet alone: it would have kept the focal point of the
platform centralized unequivocally on Servlet and also because the
vast majority of things that attempt to build upon anything Java
EE most often use Servlet as a bootstrap point and certainly not
CDI (the most prominent example being Spring).
I think we've created a situation in MicroProfile now that the
Spring guys might have a hard time adopting that API even if they
wanted to. A more judicious path in my view would have been to
adopt CDI only when it makes total sense, adopt Java SE
wholeheartedly, and stick to AtInject as much as possible as a
baseline. I was hoping we could correct these things with Jakarta
EE or at least the Servlet part. I really think one of our big
mistakes throughout the years has been fighting market realities
too much instead of judiciously adapting to them in the name of
technical merit alone. I don't think it has worked and I think we
need to think differently at this juncture in terms of marketing
too.
On 5/3/2018 10:55 AM, Richard Monson-Haefel wrote:
Good points. Keep in mind that I have not stated
what the Core is, only that CDI be part of the core. In other
discussions on this topic I have argued that Servlets also be
part of the core. I would also include interceptors, but
beyond that I’m not sure. I think there needs to be more in
the core than CDI, Servlets, and Interceptors but I’m not sure
what that would be. Servlets are, I agree, critical to the
identity of Jakarta EE and can be the foundation, in addition
to CDI, to many profiles. But things in the Core need not be
leveraged by every profile. If MicroProfile makes more sense
without Servlets, than so be it it. The purpose of the core
is to provide a foundation that profiles can build on - not a
foundation that every profile is required to use exhaustively.
To be
honest, I am totally supportive of CDI being a key Jakarta
EE
technology and simultaneously totally opposed to CDI being
part of the
core Jakarta EE profile. Whatever the technical merit, the
reality is
that this will instantly juxtapose Jakarta EE as a platform
with Spring
- which by far will be more popular than CDI in the
foreseeable future.
While defining core as Servlet does not completely guarantee
this, a
core based on Servlet is what will make Jakarta EE beyond
question the
most pervasive and relevant Java server-side technology in
the
foreseeable future and the most amenable to broad
collaboration. There
is tremendous marketing value in that for Jakarta EE.
On 5/3/2018 10:03 AM, Adam Bien wrote:
>
>> On 3. May 2018, at 15:49, Richard Monson-Haefel
<rmonson@xxxxxxxxxxxxx>
wrote:
>>
>> I agree with Steve that Jakarta EE should
centralize around CDI, but I think some technolgoies (e.g.
JDBC and JMS) can have Java SE implementations. That should
be up to each working group for each technology. That said,
when doing Jakarta EE the Core of the platform should
require use of CDI when components for application logic are
needed.
> +1 CDI should be the core.
>
> We should also transfer the EJB "added value"
(discussed several times) to CDI, then we could deprecate
EJB and make the core or main profile leaner.
>
>
>> On Wed, May 2, 2018 at 12:21 PM Steve Millidge
(Payara) <steve.millidge@xxxxxxxxxxx> wrote:
>> I personally don’t think it’s possible for each
specification to support bare metal Java SE or always ship
standalone. What this will lead to is a further
proliferation of security models, bean models etc. as each
specification reinvents the wheel independently of others.
There is already not enough consistency across
specifications. Spring provides a level of consistency as
everything is built on a centralised DI framework and in
general individual Spring projects don’t attempt to be
usable outside of the Spring framework. We need to bring
this consistency of approach across Jakarta EE and this will
require dependencies between specifications and perhaps a
centralisation around CDI as the baseline specification.
>>
>>
>>
>> I don’t think we should strive for JPA to be
standalone and independent of say CDI and JTA. Also I don’t
think JAX-RS should reinvent a bean model when it could be
based on CDI. It is currently crazy that JAX-RS annotations
are not bean defining for example. It is these
inconsistencies that make Jakarta EE harder to learn and
develop against over other frameworks.
>>
>>
>>
>> On the point of not developing for a server, where
is the thread handling, transaction handling, http handling,
socket handling etc? SpringBoot just packages a server up
inside the application when creating an uber jar . This is
semantically no different to deploying an application on a
Jakarta EE server or using a technology like Payara Micro to
build an uber jar. Server runtimes are always there even
when they are denied via marketing. Jakarta EE is different
to Spring in that it will have multiple competing
implementations of the specifications and the
implementations will likely manifest themselves as “servers”
that is what makes it unique.
>>
>>
>>
>> Steve
>>
>>
>>
>>
>>
>> From: jakarta.ee-community-bounces@xxxxxxxxxxx
<jakarta.ee-community-bounces@xxxxxxxxxxx>
On Behalf Of reza_rahman
>> Sent: 02 May 2018 13:14
>> To: Michael Remijan <mjremijan@xxxxxxxxx>;
Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>
>>
>> Subject: Re: [jakarta.ee-community] A Composable
Platform Over Profiles
>>
>>
>>
>> I think you are basically saying all Jakarta EE
specifications should support bare metal Java SE (or make
minimal assumptions about a profile), ship standalone and
have a standalone TCK.
>>
>>
>>
>> I do think this is essential going forward.
>>
>>
>>
>> Sent via the Samsung Galaxy S7, an AT&T 4G LTE
smartphone
>>
>>
>>
>> -------- Original message --------
>>
>> From: Michael Remijan <mjremijan@xxxxxxxxx>
>>
>> Date: 5/1/18 3:02 PM (GMT-05:00)
>>
>> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
>>
>> Subject: Re: [jakarta.ee-community] A Composable
Platform Over Profiles
>>
>>
>>
>>> I argue that a better approach would be to
define the platform as a palette of composable standards[1]
>>
>>
>>
>> I completely support this but I don't think it
takes it far enough. For an "enterprise" standard to
survive in the coming years, I think it must become more
"Spring like" meaning the standard must become a framework
of libraries which development teams can import into their
application in any combination they see fit. I truly
believe if JakartaEE continues to develop specifications for
a *server*, then it won't survive the coming years.
Organizations just don't move their servers fast enough.
They are slow to upgrade existing servers and forget about
moving to a different EE server. Organizations typically
are OK with updating libraries and frameworks - they don't
care what's running inside the server - just as long as they
don't need to update the server itself.
>>
>> It's not uncommon for me to see the latest and
greatest frameworks and libraries shoehorned into 10+ year
old EE servers because organizations can't move on their
server technology. Granted, this is not all organizations.
But, it is a huge appeal of Spring being able to bring in
new features without server updates.
>>
>>
>>
>>
>>
>>
>>
>> On Tuesday, May 1, 2018 01:11:23 PM
CDT, Jason Greene <jason.greene@xxxxxxxxxx>
wrote:
>>
>>
>>
>>
>>
>> Over the years there has been vigorous debate about
what makes the perfect profile. “Should spec X be included
or not?” “Should we create a “plus” variant of the web
profile?" “How many profiles is too many?" “How many is too
few?" Recent threads you can see the topic rising again with
Stable and Legacy profile proposals, and debate about
whether or not JAX-WS should be part of the platform.
>>
>>
>>
>> A related issue is that EE compliance is overly
strict. An implementor must ship exactly what a profile
defines, with limited exceptions on variation. As an
example, a certified web or full implementation can’t ship a
newer version of the Servlet API, even though it’s fully
backwards compatible. The default run mode / config of the
implementation is also not allowed to enable a subset of the
profile, even though the implementor’s primary audience may
not need all of the specified technologies.
>>
>>
>>
>> The idea behind a rigid platform certainly had
merit, and it arguably led to the very strong level of
portability across containers we enjoy today. However, this
one-size-fits-all approach just no longer fits the current
state of software, with developers expecting a high degree
of application specific tailoring.
>>
>>
>>
>> I argue that a better approach would be to define
the platform as a palette of composable standards[1], where
profiles define only what must be available for a developer
to choose from, and only limit the version of a given
standard to the minimum that must be provided[2]. Under this
model there is less of a need to define a perfect profile,
since it can be freely adjusted by the developer to fit his
or her needs. Instead, all that matters is that we have a
sensible array of choice.
>>
>>
>>
>> [1] It’s worth noting that this would require the
TCK to be split up, as discussed previously, to facilitate
the flexibility required in testing a near arbitrary
combination of standards.
>>
>>
>>
>> [2] For clarity, the full and web profiles would
still be versioned (8.0 etc) as today, this is just a rule
softening to support variation.
>>
>>
>>
>> --
>>
>> Jason T. Greene
>>
>> Chief Architect, JBoss EAP
>>
>> Red Hat
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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
>> --
>> 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
> _______________________________________________
> 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
|
