|
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.
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
Totally agree with a separated spec. +1
> 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
|
