Skip to main content

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

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