[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
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
