-1 for
MP Config.
Unless
the MP Folks
can commit on
„mature
Features“ (a
bi like the
maturity Level
of CNCF) that
won’t suddenly
receive
breaking
changes and
they also
guarantee to
provide a
Jakarta first
Roadmap where
e.g. MP Config
is migrated to
the „jakarta“
Namespace and
newest Jakarta
release ASAP
before any
other MP specs
it is not
ready to be
included in
any Jakarta EE
profile I’m
afraid.
Implementations
may use it at
their own risk
but we already
see how badly
that affects
and slows down
Jakarta NoSQL
and its
implementations.
Werner
Gesendet
von Mail für
Windows 10
Hi,
Just
thinking about
Core from
another
perspective,
is having it
contain
exactly what
EE and MP have
in common.
So that
could be, for
now:
Following this
Core profile,
both the rest
of EE and the
rest of MP
could depend
on it.
I agree
persistence is
too much for
Core. While
the issue is
that most
microservices
do persist
data, the
sources are
often varied
including
simply
messaging and
some
microservices
merely perform
orchestration
of one kind or
the other.
Reza Rahman
Jakarta EE
Ambassador,
Author,
Blogger,
Speaker
Please note
views
expressed here
are my own as
an individual
community
member and do
not reflect
the views of
my employer.
> On Mar
23, 2021, at
7:27 AM, Lukas
Jungmann <lukas.jungmann@xxxxxxxxxx>
wrote:
>
> On
3/18/21, 6:07
PM,
"jakartaee-platform-dev
on behalf of
Emily Jiang
via
jakartaee-platform-dev"
<jakartaee-platform-dev-bounces@xxxxxxxxxxx on
behalf of jakartaee-platform-dev@xxxxxxxxxxx>
wrote:
>
> Do we
need to put
Data Access on
the list?
Microservices
normally need
to access a
database. Do
we want to add
JPA or JNoSQL
or something
else?
>
> This is
good question.
Both might be
too big for
the "core".
OTOH, when I
look the
JNoSQL stuff
and compare
that with
current
Persistence, I
think, it
would probably
make sense to
define sth
like
"persistence-core"
containing
annotations
common to both
of them + some
lightweight
EntityManager/EntityManagerFactory
like
interface(s)
offering just
basic CRUD
operations
with some
unwrap method
eventually and
nothing more.
A Map.Entry or
an item in the
List could
then be seen
as trivial
implementation
of the
"Entity" from
the
"persistence-core".
It could be
even part of
existing
common-annotations
API. Seeing
jakarta.persistence.Entity
and
jakarta.nosql.mapping.Entity
together
reminded me
times figuring
out what type
of Node is the
code I have to
work with
using - is it
org.w3c.dom.Node or javax/jakarta.xml.soap.Node? - and that can be
confusing for
users in some
cases in the
future.
>
> thanks,
> --lukas
>
>
> Thanks
> Emily
>
>
>
> On
Thu, Mar 18,
2021 at 2:59
PM Reza Rahman
<reza_rahman@xxxxxxxxx>
wrote:
>
>
> With
regards to
deployment
models, I
think it is
best to leave
it completely
open. The
problem is
that the dust
hasn’t quite
settled yet
and there are
several
options that
make sense to
one extent or
the other:
thin wars,
fat/uber jars
and hollow
jars. I bet it
would be hard
to get
complete
consensus on
which
deployment
models should
be required.
> With
regards to
Configuration,
one can live
with XML but
it is far from
ideal. I think
it is best to
aim for
property files
via a
Configuration
specification.
In addition, a
fully
Java/annotation
way of
configuration
could also be
explored but I
think it is a
lower
priority. If
you look at
Spring Boot
specifically,
the properties
based
configuration
mechanism
seems to have
won out for
the most part.
In order to
get the Core
Profile out in
time for
Quarkus
perhaps it is
best to leave
configuration
unspecified at
least
initially.
>
> Most
folks here are
probably aware
of this
analysis of
the various
ways of
bringing
Configuration
into Jakarta
EE: https://reza-rahman.me/2021/02/09/your-input-needed-to-determine-path-for-jakarta-ee-microprofile-alignment/ <https://reza-rahman.me/2021/02/09/your-input-needed-to-determine-path-for-jakarta-ee-microprofile-alignment/>.
I think it
should help
make the
discussion a
bit easier.
All options
are workable,
but this would
be the order
for me: A2,
A1, B, C. B I
think carries
too many
unnecessary
risks and
complexities.
C I think
really sends a
poor message
to the
community as
to the
relationship
between
Jakarta EE and
MicroProfile.
I think
effectively
what you are
proposing is
C.
>
> Reza
RahmanJakarta
EE Ambassador,
Author,
Blogger,
Speaker
>
> Please
note views
expressed here
are my own as
an individual
community
member and do
not reflect
the views of
my employer.
>
>
>
> On Mar
18, 2021, at
6:41 AM,
Dmitry
Kornilov <dmitry.kornilov@xxxxxxxxxx>
wrote:
>
>
>
>
> We
talked a lot
about which
specs should
or should not
be included in
the core
profile. I
would like to
go a little
beyond this
topic and talk
about two
things which
are not clear
to me. The
first is what
kind of
deployment
model should
we use?
>
>
Logically it
should support
the standard
Jakarta EE
deployment
model assuming
using war/ear
archives and
supporting
multiple
deployments.
It will
provide
maximum
portability
between
Jakarta
profiles. On
the other hand
it’s an
overhead for
the smallest
profile. In
the most cases
microservice
is one
application,
so multiple
applications
support maybe
not needed.
XML-based
deployment
descriptors
are something
from the last
century. We
actually don’t
want to
include any
XML processing
specs to the
core profile
and even made
them optional
in the main
Jakarta
profile. I am
trying to say
that maybe
deployment
specification
needs a rework
to support
more modern
approach like
yaml or json
files or even
be based on
configuration
spec. It’s one
of the
options.
Another option
would be using
executable jar
files the same
way as in
Spring Boot,
Helidon,
Quarkus, etc.
This approach
has many
advantages
such as
unnecessary
class loading
madness,
potential
GraalVM
native-image
support, etc.
>
>
Another topic
is
configuration.
There is no
doubt that
configuration
specification
is needed in
Jakarta.
Potentially we
can use
MicroProfile
Config, but we
immediately
have namespace
problems. IMO,
Jakarta
profile must
use/depend on
Jakarta
specifications
only. Recently
I talked with
Tomas Langer
(Helidon
architect) and
he had an idea
of creating a
minimalistic
config
specification
in Jakarta
which contains
one annotation
-
@ConfigValue.
More
functionality
can be added
later.
MicroProfile
Config can
depend on
Jakarta
Config. It
will make
possible using
MP Config
implementations
in Core
Profile
implementations.
It makes sense
to me.
>
> I
would like to
hear your
opinions.
>
> --
Dmitry
>
>
> On 18.
3. 2021, at
10:51, Dmitry
Kornilov <dmitry.kornilov@xxxxxxxxxx>
wrote:
>
>
>
>
> On 17.
3. 2021, at
23:44, Emily
Jiang via
jakartaee-platform-dev
<jakartaee-platform-dev@xxxxxxxxxxx>
wrote:
>
> I
think the
Cloud Profile
from Ivar's
doc https://docs.google.com/presentation/d/1THhvjZazSFpDE95rqtcdQXgBQxa-B3aMFksq8xKJo08/edit#slide=id.g786c259e4b_0_101 <https://docs.google.com/presentation/d/1THhvjZazSFpDE95rqtcdQXgBQxa-B3aMFksq8xKJo08/edit#slide=id.g786c259e4b_0_101>should
be renamed to
the core
profile and
the list is a
good start. By
the way, I
don't want to
see EJB on the
Core profile
list. CDI is
the
replacement
for EJB.
>
>
> I
think this
list can be
further
shortened to:
>
> JAX-RS
> JSON-B
>
Annotation
> Bean
Validation
> CDI
> Config
>
Security
>
> CDI
contains
Injection, no
need to
mention
Injection I
think.
>
> Since
we have
JSON-B, do we
still need
JSON-P?
>
>
>
>
>
> We
need both
JSONP and
JSONB.
>
>
> --
Dmitry
>
>
>
>
> Thanks
> Emily
>
>
>
> On
Wed, Mar 17,
2021 at 3:14
PM arjan tijms
<arjan.tijms@xxxxxxxxx>
wrote:
>
>
> Hi,
>
>
> On
Wed, Mar 17,
2021 at 3:33
PM Reza Rahman
<reza_rahman@xxxxxxxxx>
wrote:
>
>
> I
think either
it is best to
leave Web
Profile mostly
alone (and
maybe prune
it) or use it
as a more
effective
replacement to
Full Profile
(and basically
treat the Full
Profile as
mostly
legacy).
>
>
> I
would like to
see the latter
option.
Speaking with
my Piranha
Cloud hat on;
we're not
looking
forward to
implementing
things like
the
Application
Client
Container, EAR
support, and
some of the
more obscure
aspects of
Corba and EJB2
and whatever
else still
lingers in
EJB-full.
>
> Moving
at least
Concurrency
and
Authorization
to Web Profile
(for
Authorization,
perhaps for
simplicity
make it a
sub-spec of
Security), and
perhaps a
Messaging lite
(Messaging
with only the
newer,
simplified
API) and Mail,
would make the
Web Profile
essentially
the Legacy
Free Profile
that has been
talked about
before.
>
> When
Concurrency
absorbs most
of the still
useful
EJB-based
services in an
CDI version,
EJB-lite can
be safely
pruned from
the Web
Profile, IMHO.