[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] @DataSourceDefinition
|
Not to defend the inclusion of multiple
categories of properties under @DataSourceDefinition(properties=...) but
there aren't necessarily only 2 categories of properties here. For example,
you could make an argument for 3 categories:1) properties of the DataSource implementation
defined by the JDBC driver2) properties of the connection pool3) properties that are entirely independent
of whether or not connections are pooled, such as a property that relates
to connection sharing or one that controls how to assign a query timeout
for statements.In some implementations, there will
be more than one type of pool to configure: a connection pool and a prepared
statement pool.Existing implementations that have dealt
with this in some way (possibly by choosing an order of precedence in which
to attempt to apply properties) will need to preserve that behavior for
compatibility. It would be wrong to change its current meaning because
that would involve breaking existing applications. Adding more categories
of properties to @DataSourceDefinition when the generic 'properties' already
exists will cause confusion and make the API harder to use for the majority
while clarifying a small minority of scenarios in which a property name
collision exists with the JDBC driver. I think we are better off
to leave 'properties' as the one way to specifying additional properties
of any sort for the annotation and deployment descriptor. If a new
programmatic means of configuring is defined, it might make sense to distinguish
the different types of properties there.In the specific example below, I don't
see the point of unwrap to vendor-specific ConfigImpl type in order to
set a connection pool property as a key/value pair. Why not just
dataSourceConfig.setConnectionPoolProperty(name, value) ? From:
"Ondrej Mihályi"
<ondrej.mihalyi@xxxxxxxxxxx>To:
Jakarta EE community
discussions <jakarta.ee-community@xxxxxxxxxxx>Date:
06/21/2018 03:04 AMSubject:
Re: [jakarta.ee-community]
@DataSourceDefinitionSent by:
jakarta.ee-community-bounces@xxxxxxxxxxx
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:@Configurationpublic 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.
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
From: jakarta.ee-community-bounces@xxxxxxxxxxx
<jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Guillermo
González de Agüero <z06.guillermo@xxxxxxxxx>
Sent: 20 June 2018 23:05:21
To: Jakarta EE community discussions
Subject: Re: [jakarta.ee-community] @DataSourceDefinition 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.é., 20 jun. 2018 22:49, arjan tijms <arjan.tijms@xxxxxxxxx>
escribió:Hi,
On Wed, Jun 20, 2018 at 10:44 PM Guillermo González de
Agüero <z06.guillermo@xxxxxxxxx>
wrote: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. Annotations2. XML3. ProgrammaticThis 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
