With my recent attempt to configure HikariCP with wildfly, I wonder, with JCA in place, should I able to do a standard JCA specific configurations to adapt HikariCP connection pooling ?
Well, your question is quite confusing. Let's talk over key points:
It seems that you want to replace IronJacamar with HikariCP. This is impossible. Hikari is a JDBC connection pool while IronJacamar is a JCA container. Besides of connections pooling (not only JDBC ones, in fact) JCA container is also capable of resource adapters lifecycle control, message-driven beans handling, EJB-specific threads transformations on MDB calls and all that stuff.
About using HikariCP as a resource adapter inside JCA container: barely possible. You can, in fact, write a wrapper around Hikari to provide JCA-specific configuration as JCA is a wide spec without tight limitations. However, this will lead to additional overhead with no particular gain. The other problem would be persistence.xml handling on deployments: resource adapters are designed to live longer than any other deployment. Those are deployment-agnostic and just intended to provide some interface everybody could use. If you'll manage Hikari to be a JCA adapter, you will need to provide persistence info through it's activation spec. The only bright place here is that you can register Hikari DataSource in JNDI providing reliable source path for your persistence.xml. However, it's hard to predict whether your resource adapter will be instantiated before or after your JPA subsystem.
There's no particular reason to do so. The only gain Hikari could provide is speed. Java EE is not about speed, it's about reliability and standards-driven architecture. If you need THAT speed, you'd better stay on SE level avoiding all the container's overhead.