You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding support for the Spring JDBC XML namespaces is fine. But, opening up all of Spring JDBC is potentially not a good idea.
Once access to JDBC is open, the next request will be for Spring transaction namespace support then for Spring AOP, etc, etc. We should be clear about drawing the line somewhere, ultimately we're targeting JEE as our platform and not Spring. Similarly, partial support for Spring features feels wrong. How do we define what is and is not supported?
If folks really want to develop on the full Spring stack, then the underlying modules are available. These could be included through manifest dependencies or deployment descriptors.
I think we should limit the scope of this task to adding support for the Spring JDBC XML namespace. Unless we come across specific use cases where folks need direct access to spring-jdbc, we should leave the majority of the API unexposed for now.
jamesnetherton
added a commit
to jamesnetherton/wildfly-camel
that referenced
this issue
Nov 3, 2015
See: Data access with JDBC
CrossRef: https://issues.jboss.org/browse/ENTESB-3953
The text was updated successfully, but these errors were encountered: