http://tomee.apache.org/datasource-config.html
'Alternatively, a DataSource can be declared via properties in the <tomee-home>/conf/system.properties file or via Java VirtualMachine -D properties. ' This is what I'm planning to use (Java VirtualMachine -D properties) in a K8 cluster, should satisfy the portability and also plays good with the K8's config maps. -----Original Message----- From: Romain Manni-Bucau [mailto:[email protected]] Sent: Monday, May 14, 2018 3:04 AM To: [email protected] Subject: Re: [Newsletter] Re: [Newsletter] Re: Migration step of jtaManaged flag in context resources Le lun. 14 mai 2018 09:56, <[email protected]> a écrit : > So bottom line: There is no portable DataSource definition technique > as they are part of the container and hence container specific? > Yes, portable solution is an app datasource which breaks the injection pattern :( > -----Original Message----- > From: Romain Manni-Bucau <[email protected]> > Sent: Monday, May 14, 2018 10:52 AM > To: [email protected] > Subject: *EXT* [Newsletter] Re: [Newsletter] Re: Migration step of > jtaManaged flag in context resources > > Not portable but same as context.xml ;) > > @DataSourceDefinition is not too :( - properties are not > > Le lun. 14 mai 2018 07:57, <[email protected]> a écrit : > > > Hi Mark and Romain, > > > > thanks for your replies! > > > > Is the resources.xml approach a portable solution? E.g. if we want > > to support Wildfly in the future, which approach is the most portable? > > Tomee.conf doesn’t sound too portable :) > > > > Thanks and best > > Fabian > > > > -----Original Message----- > > From: Mark Struberg <[email protected]> > > Sent: Friday, May 11, 2018 10:27 AM > > To: [email protected] > > Subject: *EXT* [Newsletter] Re: Migration step of jtaManaged flag in > > context resources > > > > Hi Fabian! > > > > > > To give a bit more context: > > > > Having actual db connections configured inside a WAR or EAR is > > usually something you'd rather like to avoid. > > Having passwords checked in into your source repo, needing to > > recompile if you want to tweak the connection or credentials, etc > > All that is simply not a really good idea. > > > > This problem is imo best solved by separating off all configuration > > and kind of 'infrastructure' setup from your own appliaction source > > and provide it via the container. > > > > TLDR; I recommend configuring DataSources and stuff in the container > > and not in your WAR: Just use /conf/tomee.xml [1]. > > And you can ofc also encrypt your passwords [2] so they are not > > stored in plain text. > > > > LieGrue, > > strub > > > > > > [1] https://tomee.apache.org/configuring-datasources.html > > [2] https://tomee.apache.org/datasource-password-encryption.html > > > > > Am 09.05.2018 um 17:21 schrieb Romain Manni-Bucau > > ><[email protected] > > >: > > > > > > Hi > > > > > > Just use resources.xml > > > > > > Le mer. 9 mai 2018 14:05, <[email protected]> a > écrit : > > > > > >> Hi all, > > >> > > >> > > >> > > >> I haven been trying to migrate from TomEE 1.7.5 to 7.0.4 but I am > > >> currently stuck with the following problem: > > >> > > >> > > >> > > >> We have DataSources defined in webapp’s META-INF/context.xml as > > >> Tomcat <Resource> and there _*was*_ a flag called jtaManaged > > >> which apparently doesn’t exist in Tomcat 8.5 anymore. Problem is > > >> our persistence units are still JTA managed, so what I see in the log is: > > >> > > >> > > >> > > >> org.apache.openejb.config.AutoConfig deploy Found matching > > >> datasource: XXX but this one is not a JTA datasource > > >> > > >> > > >> > > >> An hence TomEE does the following: > > >> > > >> org.apache.openejb.config.AutoConfig setJtaDataSource Adjusting > > >> PersistenceUnit Auditing <jta-data-source> to Resource ID > > >> 'Default JDBC Database' from 'XXX > > >> > > >> org.apache.openejb.config.AutoConfig setNonJtaDataSource > > >> Adjusting PersistenceUnit Auditing <non-jta-data-source> to > > >> Resource ID 'Default Unmanaged JDBC Database' from 'null' > > >> > > >> > > >> > > >> How can I define a DataSource inside context.xml which is still > > >> JTA managed? Or what is the correct way to migrate such a scenario? > > >> Wrapping it in JTADataSourceWrapperFacory? > > >> > > >> > > >> > > >> Thanks in advance and best > > >> > > >> Fabian > > >> > > >> > > >> > > >
