Is there anything that explains the effective differences between the single resource versus dual resource approach? I'm coming from a mostly JBoss background, and I don't have anything to relate to the idea of the two things being separated.
With a single resource, are both connection pooling & XA still functional? I haven't had to pass both User and UserName to the single resource. Passing only User worked with plain-text passwords and also works with the "PasswordVault cipher:X:asdf" approach. I kind of like having a single resource from a simplicity standpoint. Also, selfishly, I have to roll out a migration manual for 100 or so people in our org to move 50-ish applications over the next year. The single resource approach will make more sense based on their background and save me headaches, assuming there aren't drawbacks to using it. Thanks for the clarification, Zac Bedell > On Aug 11, 2016, at 17:12, Romain Manni-Bucau <[email protected]> wrote: > > Hi > > This is expected using a single resource for pool AND XADataSource, try > splitting it in 2 resources: http://tomee.apache.org/datasource-config.html > > Short summary is you define twice the password on 2 different instances and > oracle xadatasource doesnt know it at all. Using cipher: notation tomee > handles it before injecting the value for the xadatasource and the pool > transparently. > > Le 11 août 2016 22:16, "Zachary Bedell" <[email protected]> a écrit : > >> Not sure whether this falls under wrong documentation or incorrect >> behavior, but I found the existing docs for setting up encrypted database >> passwords for Oracle XA datasources don't work in TomEE 7.0.1. >> >> My goal is to use a custom PasswordCipher since we have apps with >> encrypted passwords for a legacy application server. It would be >> convenient to enable using the existing encrypted password strings without >> having to decrypt / re-encrypt them. I wrote a custom PasswordCipher, >> created META-INF entries, and setup the resources.xml entries as described >> in http://tomee.apache.org/examples-trunk/datasource- >> ciphered-password/README.html. >> >> 1) Created my.package.PasswordCipher, implements org.apache.openejb.cipher. >> PasswordCipher. >> >> 2) Added META-INF/org.apache.openejb.cipher.PasswordCipher/mycipher which >> contains my.package.PasswordCipher, ensured that and the class are in a JAR >> in lib. >> >> 3) resource.xml contains: >> <Resource id="myPool" type="DataSource"> >> JdbcDriver oracle.jdbc.xa.client.OracleXADataSource >> JdbcUrl jdbc:... >> User mewho >> Password Y2hhbmdlbWU= >> PasswordCipher mycipher >> InitialSize 10 >> MaxActive 50 >> MaxIdle 10 >> MaxWait 15000 >> ValidationQuery "SELECT sysdate FROM DUAL" >> TestOnBorrow true >> TestOnReturn true >> TestWhileIdle true >> TimeBetweenEvictionRunsMillis 60000 >> AccessToUnderlyingConnectionAllowed true >> JtaManaged true >> </Resource> >> >> The password was never decrypted in this case. I verified with both >> debugger breakpoints & System.out's that my PasswordCipher's decrypt method >> was never called. >> >> I had to remove Password & PasswordCipher from the Resource and use >> "VaultPassword cipher:mycipher:Y2hhbmdlbWU=" instead. That works. >> >> I've run into other situations where Oracle XA seems to behave a little >> differently than other datasource types in TomEE (including requiring >> "User" instead of "UserName" as the property key), though I'm not clear on >> why that is. >> >> Is this something where the documentation needs an "except OracleXA" >> addition, a change in behavior in TomEE 7.0.1 (which I'm using) that the >> docs haven't caught up with, or a bug? >> >> What I've got now looks like it works, but if it's not the "right" way, >> I'd prefer to change it and hopefully not end up broken at some point in >> the future. >> >> Best regards, >> Zac Bedell >> >> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
