| Re: [jakarta.ee-community] @DataSourceDefinition |
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_______________________________________________On Thu, Jun 21, 2018 at 1:12 PM Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx> wrote:_______________________________________________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.
E: ondrej.mihalyi@xxxxxxxxxxx | T: +1 415 523 0175 | M: +421 902 079 891
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Felipe <felipealvesdemoraes@xxxxxxxxx>
Sent: Thursday, June 21, 2018 5:55:52 PM
To: jakarta.ee-community@xxxxxxxxxxx
Subject: Re: [jakarta.ee-community] @DataSourceDefinitionHi 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,Felipe
On Thu, Jun 21, 2018 at 6:04 AM Ondrej Mihályi <ondrej.mihalyi@xxxxxxxxxxx> wrote:
_______________________________________________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);
}
}
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] @DataSourceDefinitionThe 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. 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