2016-08-12 15:35 GMT+02:00 Zachary Bedell <[email protected]>: > 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. > > Yep,
basically default pools we provide - tomee supports any pool but we only deliver DBCP and tomcat-jdbc integration in default binaries - the XADataSource is used as a Connection factory. It means the XA just gives connection (+ XAResource) to the pool and the pool can handle the user/pwd or not depending the impl and the way it works. > 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. > > Depends the pool and impl but generally the pool passes the username configured. If you don't see it and dont ask tomee to skip its defaults values, default Username is "sa" and can mess up a datasource impl configuration (and require a forced user depending how you configure it). > 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. > > Yes and not. I fully get your point of view but let's me try to explain mine: - with the single resource solution (same as @DataSourceDefinition properties which are undefinely related to the pool or datasource itself) you can't handle conflicts between the pool and datasource impl and you can misunderstand a parameter set on the wrong instance. Also you can have parameters wired to the wrong setter (ConnectionProperties) and can't keep using defaults and fix this issue without splitting in 2 resources the resources. So yes single resource definition works most of the time but also requires more validations to ensure you did what you think. - the migration can be made very easy using tomee Template or ResourceProvider API potentially linked to tomee server events. In this solution you would create the resource(s) in a shared jar (you add it in common.loader) and you can just wire the old config to tomee one. In clear: your users would get this jar (either automatically through a custom tomee packaging through tomee-maven-plugin or manually with a shared folder for instance) and just define: <Resource id="jdbc/myDs" type="DataSource" /> -no properties- and all the config would be handled by your converter. This would make the migration hurtless for all but 1 guy (the one writing the covnerter). > 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 > >> > >> > >> > >
