|
To quote James Gosling: "I care a great
deal about Java EE but I personally stop at Servlet". Yes, a
tongue in cheek email. Please forgive.
On 5/3/2018 11:01 AM, Richard Monson-Haefel wrote:
Well, its a little early in the discussion to
say that the core is unless when its not even fully defined.
That said, the Abstract class analogy applies here as well.
It may be that implementing something with just the core
doesn’t make sense, that you need at least one profile to us
it. I don’t think that is true. I remember in 1997 writing
Serlvets without the benefits of any templating architecture
so you can use a raw platform, but it probably makes more
sense to use it with the profiles that match your problem
domain. If you come out of the box with say, a Legacy
Profile (compatable with what we call the Full Profile), a Web
Profile, and a MicroProfile that would address a lot of the
use cases. Other profiles for Reactive Streams, REST, WS, or
IoT, for example, could evolve over time.
-1
I don’t think that all profiles must include Servlet. I
think that Microprofile should not. I am doubt that we need
a core profile. I cannot imagine any implementation
implementing just core. If so, it’s useless to have it.
— Dmitry
> On 3 May 2018, at 16:34, Reza Rahman <reza_rahman@xxxxxxxxx>
wrote:
>
> 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
--
_______________________________________________
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
|
