Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] @DataSourceDefinition

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. 😃

On Sat, Jun 23, 2018 at 4:09 PM Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
Hi,

El sáb., 23 jun. 2018 19:36, Felipe <felipealvesdemoraes@xxxxxxxxx> escribió:
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.

On Fri, Jun 22, 2018 at 5:02 AM Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
Hi Felipe and welcome!

The code you linked looks like it reads the configuration from some persistent place. What I have in mind is more along the lines of this: http://undertow.io/undertow-docs/undertow-docs-2.0.0/index.html#undertow-servlet


Regards,

Guillermo González de Agüero

El jue., 21 jun. 2018 a las 18:25, Felipe (<felipealvesdemoraes@xxxxxxxxx>) escribió:
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] @DataSourceDefinition
 
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,
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);
    }
}

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. 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

Back to the top