Deploying WAR in TomEE

[mukund19]

I have my WAR inside webapps of TomEE. After delpoying, when I try to run the
application, it says it is not able to see the classes that are present
under Project/WEB-INF/classes.

I created the WAR file from eclipse by right clicking the project and
selecting Export as WAR file.

I also tried packaging those classes into a separate jar and loaded that jar
under WEB-INF/lib.

I am not sure why it is not able to see the classes that are undeployed
under WEB-INF/classes.

Could someone please help me with this ?


Error Log :

java.lang.NoClassDefFoundError: Could not initialize class
com.app.auth.AuthenticationService
com.app.auth.AuthenticationInit.doInit(AuthenticationInit.java:14)
org.zkoss.zk.ui.metainfo.InitiatorInfo.doInit(InitiatorInfo.java:148)
   
org.zkoss.zk.ui.metainfo.InitiatorInfo.newInitiator(InitiatorInfo.java:143)
org.zkoss.zk.ui.metainfo.PageDefinition.doInit(PageDefinition.java:396)
org.zkoss.zk.ui.impl.Initiators.doInit(Initiators.java:58)
org.zkoss.zk.ui.impl.UiEngineImpl.execNewPage0(UiEngineImpl.java:378)
org.zkoss.zk.ui.impl.UiEngineImpl.execNewPage(UiEngineImpl.java:312)
   
org.zkoss.zk.ui.http.DHtmlLayoutServlet.process(DHtmlLayoutServlet.java:215)
   
org.zkoss.zk.ui.http.DHtmlLayoutServlet.doGet(DHtmlLayoutServlet.java:136)
javax.servlet.http.HttpServlet.service(HttpServlet.java:624)
javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Users-f979441.html

RE: [Newsletter] Re: [Newsletter] Re: Migration step of jtaManaged flag in context resources

[Shultz, Dmitry]

http://tomee.apache.org/datasource-config.html

'Alternatively, a DataSource can be declared via properties in the 
/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:rmannibu...@gmail.com] 
Sent: Monday, May 14, 2018 3:04 AM
To: users@tomee.apache.org
Subject: Re: [Newsletter] Re: [Newsletter] Re: Migration step of jtaManaged 
flag in context resources

Le lun. 14 mai 2018 09:56,  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 
> Sent: Monday, May 14, 2018 10:52 AM
> To: users@tomee.apache.org
> 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,  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 
> > Sent: Friday, May 11, 2018 10:27 AM
> > To: users@tomee.apache.org
> > 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 
> > > > >:
> > >
> > > Hi
> > >
> > > Just use resources.xml
> > >
> > > Le mer. 9 mai 2018 14:05,  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  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  to Resource ID 
> > >> 'Default JDBC Database' from 'XXX
> > >>
> > >> org.apache.openejb.config.AutoConfig setNonJtaDataSource 
> > >> Adjusting PersistenceUnit Auditing  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
> > >>
> > >>
> > >>
> >
>

Re: TomEE Stable and OpenJDK

[Jonathan Gallimore]

Exact dates are hard to provide. As a rough idea, we'll need a OpenJPA
release, and I think Mark is kicking that off soon, and then I think we're
probably good to go. The TomEE release can take a week or to, depending on
any issues that crop up, and allowing enough time to vote.

Hope that is some help.

Jon

On Mon, May 14, 2018 at 2:48 PM, COURTAULT Francois <
francois.courta...@gemalto.com> wrote:

> Hello Romain and Mark,
>
> If I have understood you well, TomEE 8 will address µProfile 1.3  since
> its first version.
>
> But what about my first question regarding 7.0.5 ?
>
> Best Regards.
>
> -Original Message-
> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> Sent: lundi 14 mai 2018 15:17
> To: users@tomee.apache.org
> Subject: Re: TomEE Stable and OpenJDK
>
> Le lun. 14 mai 2018 13:16, COURTAULT Francois <
> francois.courta...@gemalto.com> a écrit :
>
> > Hello Mark,
> >
> > Thanks a lot for sharing the TomEE roadmap.
> >
> > My main concerns about TomEE are:
> > -  java 9 and above support (java 10 and 11)
> > - JavaEE 8 specification support
> > - µProfile follow up: no TomEE µProfile released yet whereas
> > others exist today like Payara micro, Wildfly Swarm for example.
> >
> > So first, java 9 and above support: when you say 7.0.5 in preparation
> > right now, could you provide us please a release date ?
> > Second, I have another question: TomEE 7.1.x will address µProfile
> > 1.3, right ? So why, TomEE 8.x won't address µProfile 1.3 at starting
> point ?
> >
>
> 8 will, 7.1 is still being discussed AFAIK
>
> The side note is you can import most of mp spec as any lib in any tomee
> distro since they never really depends on the container and rely - as any
> spec should - on cdi IoC for the wiring.
>
>
>
> > Best regards.
> >
> > -Original Message-
> > From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
> > Sent: dimanche 6 mai 2018 13:11
> > To: users@tomee.apache.org
> > Subject: Re: TomEE Stable and OpenJDK
> >
> > I'm running it in production with OpenJDK.
> >
> > Actually whenever you have some RHEL server then you will run on OpenJDK.
> > So those days everything which is in the Linux server area will almost
> > certainly run perfectly fine on OpenJDK.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 06.05.2018 um 12:10 schrieb Fredrik Jonson :
> > >
> > > Mark Struberg wrote:
> > >
> > >> I think what the download page fails to communicate is which EE
> > >> level it addresses.
> > >>
> > >> TomEE-1.7.x adresses the JavaEE 6 specifications, with minimum
> > >> requirement
> > >> Java7 (up to Java8)
> > >> TomEE-7.0.x adresses JavaEE 7, with minimum Java7, soon up to
> > >> Java11
> > >> (7.0.5 in preparation right now)
> > >> TomEE-7.1.x (wip) will address JavaEE7 + MicroProfile 1.3 with
> > >> minimum Java8 TomEE-8.0.x (wip) will address JavaEE8 + MicroProfile
> > >> 1.0 with minimum Java8
> > >
> > > Thanks for that clarification. It may seem obvious to people in the
> > > know, but it is interesting to see a statement on the upper bound of
> > > supported JDK/JRE version, as well as the lower bound. In addition
> > > to the supported Java EE version range, for the major Tomee versions.
> > >
> > > Now, just to be explicit here: Apart from EE certification, does the
> > > Tomee community consider OpenJDK on equal footing to OracleJDK when
> > > it comes to Tomee deployment? Is there any important reason not to
> > > recommend OpenJDK over, or at least on par with, OracleJDK?
> > >
> > > I'm asking because I still encounter a bit of hesitation towards
> > > migrating from OracleJDK to OpenJDK. It would be helpful if open
> > > source projects such as Tomee made a clear stance on OpenJDK.
> > >
> > > BTW, I also run Tomee 7.x on OpenJDK 8, and have not found any
> > > issues compared to OracleJDK. So, now we know there are more than
> > > one application deployed on Tomee and OpenJDK. :)
> > >
> > > --
> > > Fredrik Jonson
> > >
> >
> > 
> >  This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any unauthorized
> > use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> > for the message if altered, changed or falsified. If you are not the
> > intended recipient of this message, please delete it and notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus.
> >
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are 

RE: TomEE Stable and OpenJDK

[COURTAULT Francois]

Hello Romain and Mark,

If I have understood you well, TomEE 8 will address µProfile 1.3  since its 
first version.

But what about my first question regarding 7.0.5 ?

Best Regards.

-Original Message-
From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
Sent: lundi 14 mai 2018 15:17
To: users@tomee.apache.org
Subject: Re: TomEE Stable and OpenJDK

Le lun. 14 mai 2018 13:16, COURTAULT Francois < francois.courta...@gemalto.com> 
a écrit :

> Hello Mark,
>
> Thanks a lot for sharing the TomEE roadmap.
>
> My main concerns about TomEE are:
> -  java 9 and above support (java 10 and 11)
> - JavaEE 8 specification support
> - µProfile follow up: no TomEE µProfile released yet whereas
> others exist today like Payara micro, Wildfly Swarm for example.
>
> So first, java 9 and above support: when you say 7.0.5 in preparation
> right now, could you provide us please a release date ?
> Second, I have another question: TomEE 7.1.x will address µProfile
> 1.3, right ? So why, TomEE 8.x won't address µProfile 1.3 at starting point ?
>

8 will, 7.1 is still being discussed AFAIK

The side note is you can import most of mp spec as any lib in any tomee distro 
since they never really depends on the container and rely - as any spec should 
- on cdi IoC for the wiring.



> Best regards.
>
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
> Sent: dimanche 6 mai 2018 13:11
> To: users@tomee.apache.org
> Subject: Re: TomEE Stable and OpenJDK
>
> I'm running it in production with OpenJDK.
>
> Actually whenever you have some RHEL server then you will run on OpenJDK.
> So those days everything which is in the Linux server area will almost
> certainly run perfectly fine on OpenJDK.
>
> LieGrue,
> strub
>
>
> > Am 06.05.2018 um 12:10 schrieb Fredrik Jonson :
> >
> > Mark Struberg wrote:
> >
> >> I think what the download page fails to communicate is which EE
> >> level it addresses.
> >>
> >> TomEE-1.7.x adresses the JavaEE 6 specifications, with minimum
> >> requirement
> >> Java7 (up to Java8)
> >> TomEE-7.0.x adresses JavaEE 7, with minimum Java7, soon up to
> >> Java11
> >> (7.0.5 in preparation right now)
> >> TomEE-7.1.x (wip) will address JavaEE7 + MicroProfile 1.3 with
> >> minimum Java8 TomEE-8.0.x (wip) will address JavaEE8 + MicroProfile
> >> 1.0 with minimum Java8
> >
> > Thanks for that clarification. It may seem obvious to people in the
> > know, but it is interesting to see a statement on the upper bound of
> > supported JDK/JRE version, as well as the lower bound. In addition
> > to the supported Java EE version range, for the major Tomee versions.
> >
> > Now, just to be explicit here: Apart from EE certification, does the
> > Tomee community consider OpenJDK on equal footing to OracleJDK when
> > it comes to Tomee deployment? Is there any important reason not to
> > recommend OpenJDK over, or at least on par with, OracleJDK?
> >
> > I'm asking because I still encounter a bit of hesitation towards
> > migrating from OracleJDK to OpenJDK. It would be helpful if open
> > source projects such as Tomee made a clear stance on OpenJDK.
> >
> > BTW, I also run Tomee 7.x on OpenJDK 8, and have not found any
> > issues compared to OracleJDK. So, now we know there are more than
> > one application deployed on Tomee and OpenJDK. :)
> >
> > --
> > Fredrik Jonson
> >
>
> 
>  This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

Re: TomEE Stable and OpenJDK

[Romain Manni-Bucau]

Le lun. 14 mai 2018 13:16, COURTAULT Francois <
francois.courta...@gemalto.com> a écrit :

> Hello Mark,
>
> Thanks a lot for sharing the TomEE roadmap.
>
> My main concerns about TomEE are:
> -  java 9 and above support (java 10 and 11)
> - JavaEE 8 specification support
> - µProfile follow up: no TomEE µProfile released yet whereas others
> exist today like Payara micro, Wildfly Swarm for example.
>
> So first, java 9 and above support: when you say 7.0.5 in preparation
> right now, could you provide us please a release date ?
> Second, I have another question: TomEE 7.1.x will address µProfile 1.3,
> right ? So why, TomEE 8.x won't address µProfile 1.3 at starting point ?
>

8 will, 7.1 is still being discussed AFAIK

The side note is you can import most of mp spec as any lib in any tomee
distro since they never really depends on the container and rely - as any
spec should - on cdi IoC for the wiring.



> Best regards.
>
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
> Sent: dimanche 6 mai 2018 13:11
> To: users@tomee.apache.org
> Subject: Re: TomEE Stable and OpenJDK
>
> I'm running it in production with OpenJDK.
>
> Actually whenever you have some RHEL server then you will run on OpenJDK.
> So those days everything which is in the Linux server area will almost
> certainly run perfectly fine on OpenJDK.
>
> LieGrue,
> strub
>
>
> > Am 06.05.2018 um 12:10 schrieb Fredrik Jonson :
> >
> > Mark Struberg wrote:
> >
> >> I think what the download page fails to communicate is which EE level
> >> it addresses.
> >>
> >> TomEE-1.7.x adresses the JavaEE 6 specifications, with minimum
> >> requirement
> >> Java7 (up to Java8)
> >> TomEE-7.0.x adresses JavaEE 7, with minimum Java7, soon up to Java11
> >> (7.0.5 in preparation right now)
> >> TomEE-7.1.x (wip) will address JavaEE7 + MicroProfile 1.3 with
> >> minimum Java8 TomEE-8.0.x (wip) will address JavaEE8 + MicroProfile
> >> 1.0 with minimum Java8
> >
> > Thanks for that clarification. It may seem obvious to people in the
> > know, but it is interesting to see a statement on the upper bound of
> > supported JDK/JRE version, as well as the lower bound. In addition to
> > the supported Java EE version range, for the major Tomee versions.
> >
> > Now, just to be explicit here: Apart from EE certification, does the
> > Tomee community consider OpenJDK on equal footing to OracleJDK when it
> > comes to Tomee deployment? Is there any important reason not to
> > recommend OpenJDK over, or at least on par with, OracleJDK?
> >
> > I'm asking because I still encounter a bit of hesitation towards
> > migrating from OracleJDK to OpenJDK. It would be helpful if open
> > source projects such as Tomee made a clear stance on OpenJDK.
> >
> > BTW, I also run Tomee 7.x on OpenJDK 8, and have not found any issues
> > compared to OracleJDK. So, now we know there are more than one
> > application deployed on Tomee and OpenJDK. :)
> >
> > --
> > Fredrik Jonson
> >
>
> 
>  This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for
> the message if altered, changed or falsified. If you are not the intended
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission
> free from viruses, the sender will not be liable for damages caused by a
> transmitted virus.
>

Re: [Newsletter] Migration step of jtaManaged flag in context resources

[Mark Struberg]

Yup.

In my book the conf/tomee.xml is the most portable one. 
Becaue here you clearly defer all infrastructure configuration to the container.
Of course for WildFly, Payara, etc the way how to configure the infrastructure 
is different. But the WAR will be perfectly portable in this case.

LieGrue,
strub


> Am 14.05.2018 um 10:52 schrieb Romain Manni-Bucau :
> 
> Not portable but same as context.xml ;)
> 
> @DataSourceDefinition is not too :( - properties are not
> 
> Le lun. 14 mai 2018 07:57,  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 
>> Sent: Friday, May 11, 2018 10:27 AM
>> To: users@tomee.apache.org
>> 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 >> :
>>> 
>>> Hi
>>> 
>>> Just use resources.xml
>>> 
>>> Le mer. 9 mai 2018 14:05,  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  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  to Resource ID 'Default
 JDBC Database' from 'XXX
 
 org.apache.openejb.config.AutoConfig setNonJtaDataSource Adjusting
 PersistenceUnit Auditing  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
 
 
 
>> 

RE: TomEE Stable and OpenJDK

[COURTAULT Francois]

Hello Mark,

Thanks a lot for sharing the TomEE roadmap.

My main concerns about TomEE are:
-  java 9 and above support (java 10 and 11)
- JavaEE 8 specification support
- µProfile follow up: no TomEE µProfile released yet whereas others exist 
today like Payara micro, Wildfly Swarm for example.

So first, java 9 and above support: when you say 7.0.5 in preparation right 
now, could you provide us please a release date ?
Second, I have another question: TomEE 7.1.x will address µProfile 1.3, right ? 
So why, TomEE 8.x won't address µProfile 1.3 at starting point ?

Best regards.

-Original Message-
From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
Sent: dimanche 6 mai 2018 13:11
To: users@tomee.apache.org
Subject: Re: TomEE Stable and OpenJDK

I'm running it in production with OpenJDK.

Actually whenever you have some RHEL server then you will run on OpenJDK.
So those days everything which is in the Linux server area will almost 
certainly run perfectly fine on OpenJDK.

LieGrue,
strub


> Am 06.05.2018 um 12:10 schrieb Fredrik Jonson :
>
> Mark Struberg wrote:
>
>> I think what the download page fails to communicate is which EE level
>> it addresses.
>>
>> TomEE-1.7.x adresses the JavaEE 6 specifications, with minimum
>> requirement
>> Java7 (up to Java8)
>> TomEE-7.0.x adresses JavaEE 7, with minimum Java7, soon up to Java11
>> (7.0.5 in preparation right now)
>> TomEE-7.1.x (wip) will address JavaEE7 + MicroProfile 1.3 with
>> minimum Java8 TomEE-8.0.x (wip) will address JavaEE8 + MicroProfile
>> 1.0 with minimum Java8
>
> Thanks for that clarification. It may seem obvious to people in the
> know, but it is interesting to see a statement on the upper bound of
> supported JDK/JRE version, as well as the lower bound. In addition to
> the supported Java EE version range, for the major Tomee versions.
>
> Now, just to be explicit here: Apart from EE certification, does the
> Tomee community consider OpenJDK on equal footing to OracleJDK when it
> comes to Tomee deployment? Is there any important reason not to
> recommend OpenJDK over, or at least on par with, OracleJDK?
>
> I'm asking because I still encounter a bit of hesitation towards
> migrating from OracleJDK to OpenJDK. It would be helpful if open
> source projects such as Tomee made a clear stance on OpenJDK.
>
> BTW, I also run Tomee 7.x on OpenJDK 8, and have not found any issues
> compared to OracleJDK. So, now we know there are more than one
> application deployed on Tomee and OpenJDK. :)
>
> --
> Fredrik Jonson
>


 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

Re: [Newsletter] Re: [Newsletter] Re: Migration step of jtaManaged flag in context resources

[Romain Manni-Bucau]

Le lun. 14 mai 2018 09:56,  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 
> Sent: Monday, May 14, 2018 10:52 AM
> To: users@tomee.apache.org
> 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,  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 
> > Sent: Friday, May 11, 2018 10:27 AM
> > To: users@tomee.apache.org
> > 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
> > > > >:
> > >
> > > Hi
> > >
> > > Just use resources.xml
> > >
> > > Le mer. 9 mai 2018 14:05,  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  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  to Resource ID 'Default
> > >> JDBC Database' from 'XXX
> > >>
> > >> org.apache.openejb.config.AutoConfig setNonJtaDataSource Adjusting
> > >> PersistenceUnit Auditing  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
> > >>
> > >>
> > >>
> >
>

RE: [Newsletter] Re: [Newsletter] Re: Migration step of jtaManaged flag in context resources

[fabian-a . richter]

So bottom line: There is no portable DataSource definition technique as they 
are part of the container and hence container specific? 

-Original Message-
From: Romain Manni-Bucau  
Sent: Monday, May 14, 2018 10:52 AM
To: users@tomee.apache.org
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,  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 
> Sent: Friday, May 11, 2018 10:27 AM
> To: users@tomee.apache.org
> 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 
> > >:
> >
> > Hi
> >
> > Just use resources.xml
> >
> > Le mer. 9 mai 2018 14:05,  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  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  to Resource ID 'Default 
> >> JDBC Database' from 'XXX
> >>
> >> org.apache.openejb.config.AutoConfig setNonJtaDataSource Adjusting 
> >> PersistenceUnit Auditing  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
> >>
> >>
> >>
>


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Newsletter] Re: Migration step of jtaManaged flag in context resources

[Romain Manni-Bucau]

Not portable but same as context.xml ;)

@DataSourceDefinition is not too :( - properties are not

Le lun. 14 mai 2018 07:57,  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 
> Sent: Friday, May 11, 2018 10:27 AM
> To: users@tomee.apache.org
> 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  >:
> >
> > Hi
> >
> > Just use resources.xml
> >
> > Le mer. 9 mai 2018 14:05,  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  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  to Resource ID 'Default
> >> JDBC Database' from 'XXX
> >>
> >> org.apache.openejb.config.AutoConfig setNonJtaDataSource Adjusting
> >> PersistenceUnit Auditing  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
> >>
> >>
> >>
>

RE: [Newsletter] Re: Migration step of jtaManaged flag in context resources

[fabian-a . richter]

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  
Sent: Friday, May 11, 2018 10:27 AM
To: users@tomee.apache.org
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 :
> 
> Hi
> 
> Just use resources.xml
> 
> Le mer. 9 mai 2018 14:05,  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  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  to Resource ID 'Default 
>> JDBC Database' from 'XXX
>> 
>> org.apache.openejb.config.AutoConfig setNonJtaDataSource Adjusting 
>> PersistenceUnit Auditing  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
>> 
>> 
>> 


smime.p7s
Description: S/MIME Cryptographic Signature