I agree with Bill. If we could do this stuff in the JCP just
fine, there should be a way to do it here without too much
specification re-organization.
On 6/20/2018 11:47 AM, Bill Shannon
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.
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
_______________________________________________
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
|