Well, I don't recommend defining custom database data types unless you absolutely have to. En particular,, it looks like you would actually be better off with multiple rows in your UI_MSG_ALERT_T table than by cramming multiple role columns into it. Among other things, the necessary SQL is likely to be easier and you have more overall flexibility within Oracle and more portability in case your employer decides to do like Amazon did and get rid of Oracle in favor of some other DBMS where things work differently.
Beyond that, to get Oracle-specific features, you would generally have to cast the Connection object to an Oracle Connection. And that's a problem with a pooled JDBC Connection, since the Pool Connection is actually a façade for the real Connection. It has to be, since close() on a Pool Connection simply returns it to the pool, but close() on a "real" Connection destroys the network link to the database server. So in a webapp, you'd first have to get the Pool Connection via the DataSource, then de-reference it to get to the underlying Oracle Connection.
It's all somewhat messy and not to be done lightly. Better, as I said, to keep multiple records in UI_MSG_ALERT_T or have the roles column serve as a key to a second table with the actual values in it (Parent-child in a one-to-many relation).
Being persecuted doesn't in any way prove your righteousness or your beliefs. Many people get persecuted because they are repugnant or annoying. Or just because they can be.
Because those who mind don't matter and those who matter don't mind - Seuss. Tiny ad: