Let me briefly emphasize the need to
standardize. While every modern Java EE runtime supports this,
until it is actually standardized, it gives detractors ammunition
to use the gap to continue to bash Java EE. Where this leaves
implementations like WebLogic and WebSphere ND is an interesting
question. Perhaps the right answer is that these guys continue to
remain Java EE implementations and not Jakarta EE implementations.
On 6/25/2018 1:07 PM, Ondrej Mihályi wrote:
Hi
> I wasn't saying to not have a programmatic approach, I
was just worried that this was the only option since in some
cases a declarative approach solves the problems.
I think we should promote the hollow JAR approach, it gives
a lot of flexibility and still allows packaging as an Uber
JAR. Payara Micro is about hollow JAR from day one and also
supports uber JAR. Thorntail started as an Uber JAR solution
but added a hollow JAr option. And Liberty and other solutions
allow similar options too. Hopefully one day we can also focus
on standardizing this or at least turning it into a Jakarta EE
blueprint
😉
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
I wasn't saying to not have a programmatic
approach, I was just worried that this was the only option
since in some cases a declarative approach solves the
problems.
And I had completely forgotten about the hollow jar
approach (I really liked when I read about this some
time ago). I totally agrees with your points and
Reza's. 😃
Hi,
I see.
But this approach seems like we are moving to
an Uberjar future, and like others here in the
discussion, like the thin wars approach and
like that the Application server handles the
infrastructure behind my application for me.
In my opinion, it's really not related to
uberjars at all. You have a war which contains
the definition of the needed resources and can
be deployed to any application server, with no
configuration.
Yet you can argue some configuration will
be needed for the server anyway (http thread
pools, ssl certificates, etc) so it's not a
problem to also contain the resources
configuration. But even if you prefer to
configure the server separately, there's a lot
of value in being able to easily configure the
basic stuff with little effort.
To give you a related example, in the
Security API we originally had an annotation
to create an in memory identity store, with
predefined users and passwords. It was only
intented for development, as password was
stored in code in plaintext. Someone raised
the concern that people could misuse it and
also use it in production, and so it was
removed.
It was a great feature for development and
demo purposes, and the same is true for
resource definition, and totally portable.
A separate topic are uberjars. I personally
think *hollow* uberjars are really the future,
which basically preserve the separation
between runtime and application. But in order
to be truly portable, I need to provision the
server in a standard way.
Of course that if this solution could be
managed by application servers and be
configurable in a standard way depending on
developer needs (By annotations, yaml files,
env variables, and things like this) while
maintaining the thin wars approach, maybe
this is the way we should follow. I think
most of the use cases will be satisfied with
a non programmatic way of flexibly define
it's resources(DataSource, JMS, ...)
definitions, while some other use cases,
like in-house frameworks will benefit of the
programmatic ways of controlling it's
resources.
I don't agree with no programmatic only
approaches. As I illustrated, with a
programmatic API you can easily create an
annotation, an XML, a YAML and a JSON file to be
processed by a CDI extension. It might sound low
level, but it isn't so much, specially with CDI
2.0 which greatly simplified extensions. The
same is not true when you only have an
annotation.
In-house frameworks originate from
limitations of the standard, and they provide
feedback that allows the standard to evolve. If
we only provide a declarative method, there's
little room for experimentation from users. With
a programmatic API everyone can explore and then
come back with a great annotation.
Don't get me wrong, I totally support
annotations. But I've sometimes missed the
flexibility of a pure code solution.
Hi Felipe and welcome!
Regards,
Guillermo González de Agüero
I just know what I
was digging into their code:
https://github.com/kumuluz/kumuluzee/blob/master/core/src/main/java/com/kumuluz/ee/factories/EeConfigFactory.java
They did some builders and things
like this to tackle the
configurations, they use this to
bootstrap the application, so
looking the way they did, we would
do something like externalize the
configuration, and have some core
component that generates the
defaults to us, and when needed we
would Override theses defaults to
met our needs. This is pretty much
how they do it.
Of course that the code shown
handles a lot more than just the
Datasource configuration, but we
can have an idea.
PS: If we have some KumuluzEE
guys in the discussion, this
would be a good time to show
up 😃
Regards,
Felipe
Any more info on that,
Felipe?
Unless people from Kumuluz
join the effort I doubt
anybody will push for
standardizing something from
Kumuluz because it's not a
well known API.
Best regards,
Ondrej Mihályi
Senior Payara Service
Engineer
Payara Server – Robust.
Reliable. Supported.
Hi guys, this is the
first time that I'm
posting something, so if
I say something wrong,
sorry 😅
I think that KumuluzEE
does some programatic
setup for it's
Configuration. Can it be
used as starting point
towards a standard?
Regards,
We
should really
ensure that
Annotation-based
API and
programmatic API
are equally
powerful. Ideally,
if they are as
similar as
possible.
In,
Java EE 8, some
things like
defining a
datasourc are only
possible with
annotations/XML.
What's worse, some
things are only
possible with XML,
such as some
configuration of
JPA in
persistence.xml.
Jakarta
EE really needs a
complete
programmatic API
to match the power
of
annotations/XML.
And the current
programmatic API
needs to be
improved so that
it's easy to
access and use.
For
example, Servlet
programmatic API
allows almost or
all power as
XML/annotations,
but with a very
complicated way.
Some things that
are easy with
web.xml are
programmatically
possible only with
lifecycle
listeners. It
would be much
better if for
example session
timeout and
tracking cookie
could be
configured
programmatically
like this:
@Configuration
public class
MySessionConfig
implements
ConfiguringWebSession
{
@Override
public void
configureWebSession(WebSessionConfig
config) {
config.setSessionTimeout(SESSION_TIMEOUT_IN_MINUTES);
config.getSessionCookieConfig().setName("MY_SESSION_COOKIE");
config.addSessionTrackingMode(COOKIE,
URL);
}
}
Instead of
figuring out how
to do it with a
ServletContextListener what I did in
my POC here.
For
@DataSourceDefinition, it could look like this:
@Configuration
public
class MyDataSource
implements
ConfiguringDataSource
{
@Override
public void
configureDataSource(DataSourceConfig
config) {
config.setName("java:global/MyApp/MyDataSource");
config.setClass(ClientDataSource.class);
...
ConfigImpl
configImpl =
config.unwrap(ConfigImpl.class);
configImpl.setPoolProperty("maxSize", 10);
}
}
There's
no way I know how
to do the above
programmatically,
only with
annotations or
web.xml.
The fact that the
programmatic API
lacks features
available on the
declarative options
is indeed
interesting.
With the CDI
facilities we now
have, it's pretty
easy to create
annotations that
just do anything
we want in a
portable way,
provided that
there's some
programmatic API
for it.
I can create a
new @CustomServlet
annotation and use
it to register
Servlets. But then
I will find there
are missing
features.
My personal
view is that
annotations are
great, but they
are only partially
typesafe and can
easily become too
big.
If we ensure a
solid programmatic
API, users will
get the ability to
define better
annotations (or
even XML) that
provide us
feedback to
improve ours.
That said, I
don't argue some
existing
annotations might
need to be
improved. This is
just a casual
thought on how to
approach the
topic.
In my opinion,
annotations
are great for
simple stuff.
For complex
configurations,
I prefer a
full blown
programmatic,
type safe and
object
oriented API.
Often the
best case is
to have a
consistent
triple way for
configuration:
1.
Annotations
2. XML
3.
Programmatic
This is
partially how
it works for
Servlets for
example, and
(less
consistent)
for JSF.
A Servlet
for example
can be
registered via
an annotation,
via XML or
using the
programmatic
API. The only
problem with
the Servlet
programmatic
API is that is
mysteriously
just lacks
some options
that
annotations
and XML do
have.
Kind
regards,
Arjan
A
pluggable
system for
dynamic
resource
definitions,
in addition to
staged and
config enabled
annotations.
That would
satisfy every
need.
I'm not sure
what you're
referring to
since Java EE
has always
required that
a
database be
part of every
configuration. We can't guarantee that the database
server is up,
that the
network cable
is connected,
the disk isn't
full, etc.,
but it has to
be possible
for the
customer to
address all
these
"availability"
problems and
then use the
database.
It has
more to do
with a
(simple)
database being
up and running
by default,
just like say
a JNDI
directory or a
JMS broker is
up and running
by default.
This database
can be a
simple
embedded one,
it just has to
be there by
default. In
Payara we have
such a
database, and
it's really
relatively
easy to
implement by a
vendor.
If they've
been standing
on the street
corner and
shouting into
the wind, I
haven't heard
it. If there
are real
issues, I very
much would
like to hear
them
and hopefully
they can be
addressed in
Jakarta EE.
They were
at least
mentioning it
in the Twitter
thread linked
in the opening
post.
The addition
of the Config
API to Jakarta
EE would help
us address
many of these
issues.
Indeed,
the Config API
is one the
pieces. The
concepts of
(config)
staging is
another one.
It's
essentially
another JSF
concept (which
borrowed it on
its turn from
Rails) that
probably
should be
available
system-wide.
Finally it's
the
configurable
datasource
(placeholders
in the
annotation/xml,
or otherwise).
You basically
need all these
three pieces
for the best
experience.
Kind
regards,
Arjan
_______________________________________________
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
_______________________________________________
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
|