|
Modular run-times and thin wars are not
mutually exclusive (neither are uber-jars or profiles). Open
Liberty certainly shows this pretty effectively and so does
Thorntail (formerly WildFly Swarm) with hollow uber jars. In
addition, it would be great if we could also allow for the JPMS
way. Options from Java EE vendors is what customers have asked for
as opposed to the one size fits all approach (that include an uber
jars only approach).
On 6/23/2018 1:36 PM, Felipe wrote:
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.
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.
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.
Hi,
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
|
