Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] @DataSourceDefinition
Hi,

There's not necessarily a problem with @DataSourceDefinition being in the Common Annotations spec, although there is the mentioned issue with configurability and the generic attributes that the @DataSourceDefinition takes without specifying whether and how they should go to the pool vs the data source.

I'm a great fan of @DataSourceDefinition, but it has always been a bit of an issue that it essentially merges two other concepts in one; the data source and the connection pool. Many other proprietary mechanisms (like for example GlassFish) have two separate definitions for that.

Additionally, a small data storage spec might be orthogonal to the requirements of evolving @DataSourceDefinition, but these two efforts might be combined. Although it's just a proposal, I was half thinking about a replacement @DataSourceDefinition that does have the separate pool and data source concept, together with an actual available (embedded) database. As you know all too well (you closed my issue for it back then :P) Java EE doesn't really have a runtime available database, even though it's generally thought it has one.

At the same time, our friends from Apache/TomEE, Mark Struberg and Romain, have been crying for over a decade now that @DataSourceDefinition is absolutely bad and can't be used for anything. While I respectfully disagree with that (we've used @DataSourceDefinition for tons of real life projects), it might be interesting to finally get to the bottom of what these two are actually complaining about, and see if we can address that.

Kind regards,
Arjan



On Wed, Jun 20, 2018 at 5:54 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
What's the problem with @DataSourceDefinition(s) being in the Common Annotations spec?  It seems silly to create a new spec for just two annotations.

arjan tijms wrote on 6/20/18 6:02 AM:
With the separate spec, do you mean to move only @DataSourceDefinition there, or also say @MailSessionDefinition?

@MailSessionDefinition is already part of JavaMail, and I think it's good practice that a spec that owns certain artefacts should define/own the associated annotations.

For example, @ViewScoped is a CDI annotation for JSF, and it should be owned by JSF (not CDI). JSF merely uses CDI.

So -1 on moving @DataSourceDefinition, @MailSessionDefinition, @JMSDestinationDefinition, etc to a resources spec.
That does brings us back to @DataSourceDefinition, which doesn't have a "real" spec to back it (it's part of common annotations). For this another option could be to create a small "data storage spec", which could define the data source, connection pool and an actual embedded data base.

Thoughts?

Kind regards,
Arjan





On Wed, Jun 20, 2018 at 2:01 PM Jeyvison Nascimento <jeynoronha@xxxxxxxxx> wrote:
Totally agree with a separated spec. +1 

Em qua, 20 de jun de 2018 às 05:26, Adam Bien <abien@xxxxxxxxxxxxx> escreveu:


> On 20. Jun 2018, at 07:52, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
>
> Hi,
>
> I totally agree this is an essential point to manage. All these annotations need to be integrated with the Config JSR, and additionally we need annotations to create the missing resources, like thread pools.
>
> I'm not sure about moving @DataSourceDefinition to the JPA spec. The annotation is useful even when not using JPA. Moving resource definitions to the JCA spec also doesn't seem fair. Perhaps we need a "Resource Definition" spec?

+1 for a standalone spec. JMS, ThreadPools etc. also need configuration.
>
>
> Regards,
>
> Guillermo González de Agüero
>
> El mié., 20 jun. 2018 a las 1:25, reza_rahman (<reza_rahman@xxxxxxxxx>) escribió:
> Thanks for bringing this here and out of Twitter limbo. This is actually bigger than just data source. All resource definitions need this capability. In addition we need a unified strategy to manage "stages". Today we have disjointed and underspecified efforts in CDI and JSF. This is one of the things I had long hoped the original proposal for the configuration JSR would address properly. It hasn't happened yet sadly.
>
> Can this finally be fixed with Jakarata EE?
>
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
>
> -------- Original message --------
> From: arjan tijms <arjan.tijms@xxxxxxxxx>
> Date: 6/19/18 4:12 PM (GMT-05:00)
> To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
> Subject: [jakarta.ee-community] @DataSourceDefinition
>
> Hi,
>
> As suggested by Reza, a continuation of
>
> https://twitter.com/fe_amoraes/status/1004184072795586560
>
> There's a couple of things that were being discussed there, but configurability of the annotation was the prime concern.
>
> Mark Struberg additionally remarked several aspects where underspecified.
>
> It was mentioned that Payara and JBoss/WildFly already support placeholders inside the @DataSourceDefinition annotation and XML variant. Liberty doesn't support that yet, but appeared to be interested.
>
> Together with a concept of "stage", to select between known in-archive config sets, the ability to provide an external config set, additionally password-aliasing, and finally the ability to replace a data source fully via server mechanisms (admin console, etc) it's possible to setup a quite comprehensive and workable system.
>
> However, none of that is standardised yet.
>
> Specifically the fact that @DataSourceDefinition does not distinguish between properties intended for the pool and and properties intended for the data source itself, can be troublesome.
>
> Maybe it would be an idea if @DataSourceDefinition (or a modern replacement thereof) moved to the JPA spec, to that a more consistent trio of connection pool, data source and persistence unit can be easily defined.
>
> Kind regards,
> Arjan Tijms
>
> _______________________________________________
> 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