Re: [VOTE] Apache TomEE 9.0.0-M8

[Jean-Louis Monteiro]

Thanks Jon,

Created 2 issues (TOMEE-4007 and TOMEE-4008) under
https://issues.apache.org/jira/browse/TOMEE-3862


--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Mon, Jul 4, 2022 at 12:46 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> +1
>
> Couple of notes:
>
> * woodstox-core appears to have gone _back_ some versions (6.2.4 -> 5.2.1)
> * something is pulling in ASM as opposed to using the xbean-asm9-shaded
>
> I don't think either of these should block the release, but we ought to
> have a look as development moves forward.
>
> Thanks for rolling the release!
>
> Jon
>
> On Tue, Jun 28, 2022 at 11:01 PM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > Hi,
> >
> > As discussed, here is the vote for Apache TomEE 9.0.0-M8. This milestone
> > differs from previous 9.x in the sense that we migrated all TomEE code to
> > the new jakarta namespace. Previously, we used bytecode relocation but
> most
> > of the integration was broken (tests, arquillian, etc).
> >
> > We are still working on some regressions and fixes in order to pass all
> TCK
> > for Jakarta EE 9.1. But starting to gather feedback can only help sooner
> > rather than later.
> >
> > This is a maintenance release with minor fixes and dependencies upgrades.
> >
> > Maven staging repo
> > https://repository.apache.org/content/repositories/orgapachetomee-1205/
> >
> > Binaries and sources
> > https://dist.apache.org/repos/dist/dev/tomee/tomee-9.0.0-M8
> >
> > Github Tag
> > https://github.com/apache/tomee/tree/tomee-project-9.0.0-M8
> >
> > Commit hash
> > 12e5dd91fe34affa775a68d5341576b417530008
> >
> > Release Notes
> > https://issues.apache.org/jira/projects/TOMEE/versions/12350178
> >
> > Sub-task
> >
> >- [TOMEE-3861 ] -
> >Upgrade to apache-parent-26
> >- [TOMEE-3865 ] -
> >Switch arquillian to the new Servlet 5 protocol
> >- [TOMEE-3866 ] -
> >Upgrade Hibernate to 5.6.7 / Hibernate Validator to 7.0.2 (Jakarta
> > Artifact)
> >- [TOMEE-3868 ] -
> >Remove SAAJ Axis 1 provider
> >- [TOMEE-3869 ] -
> >Remove JAX-RPC
> >- [TOMEE-3870 ] -
> >Remove Management J2EE
> >- [TOMEE-3877 ] -
> No
> >interface view EJB proxies broken on JDK16+
> >- [TOMEE-3879 ] -
> Add
> >missing --add-opens options to itests/failover
> >- [TOMEE-3881 ] -
> Add
> >JDK --add-opens to our scripts in openejb-standalone
> >- [TOMEE-3920 ] -
> Fix
> >TomEE :: Web Examples :: Moviefun Rest
> >- [TOMEE-3922 ] -
> >Patch Tomcat JasperInitializer and create jira
> >- [TOMEE-3925 ] -
> Fix
> >Websocket TLS Basic Auth
> >- [TOMEE-3926 ] -
> Fix
> >Webservice SSL Client Certificate Example
> >- [TOMEE-3930 ] -
> fix
> >arquillian-tomee-moviefun-example
> >- [TOMEE-3931 ] -
> fix
> >example/cucumber-jvm
> >- [TOMEE-3932 ] -
> >Migration tips and tricks
> >- [TOMEE-3939 ] -
> Fix
> >Jakarta Mail API with Apache Velocity Templating
> >- [TOMEE-3940 ] -
> Fix
> >TomEE :: Examples :: JakartaMail API
> >- [TOMEE-3943 ] -
> Fix
> >TomEE :: Examples :: Multiple JPA providers
> >- [TOMEE-3944 ] -
> Fix
> >TomEE :: Examples :: Simple EAR :: Functional Tests
> >- [TOMEE-3953 ] -
> Fix
> >TomEE :: Examples :: JPA with EclipseLink
> >- [TOMEE-3954 ] -
> Fix
> >TomEE :: Examples :: JPA with Hibernate and arquillian
> >- [TOMEE-3956 ] -
> Fix
> >TomEE :: Connector Examples :: Connector in WAR
> >- [TOMEE-3957 ] -
> Fix
> >TomEE :: Examples :: DeltaSpike @ConfigProperty
> >- [TOMEE-3958 ] -
> Fix
> >TomEE :: Examples :: DeltaSpike Exception Handling
> >- [TOMEE-3959 

Re: [VOTE] Apache TomEE 9.0.0-M8

[Jonathan Gallimore]

+1

Couple of notes:

* woodstox-core appears to have gone _back_ some versions (6.2.4 -> 5.2.1)
* something is pulling in ASM as opposed to using the xbean-asm9-shaded

I don't think either of these should block the release, but we ought to
have a look as development moves forward.

Thanks for rolling the release!

Jon

On Tue, Jun 28, 2022 at 11:01 PM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Hi,
>
> As discussed, here is the vote for Apache TomEE 9.0.0-M8. This milestone
> differs from previous 9.x in the sense that we migrated all TomEE code to
> the new jakarta namespace. Previously, we used bytecode relocation but most
> of the integration was broken (tests, arquillian, etc).
>
> We are still working on some regressions and fixes in order to pass all TCK
> for Jakarta EE 9.1. But starting to gather feedback can only help sooner
> rather than later.
>
> This is a maintenance release with minor fixes and dependencies upgrades.
>
> Maven staging repo
> https://repository.apache.org/content/repositories/orgapachetomee-1205/
>
> Binaries and sources
> https://dist.apache.org/repos/dist/dev/tomee/tomee-9.0.0-M8
>
> Github Tag
> https://github.com/apache/tomee/tree/tomee-project-9.0.0-M8
>
> Commit hash
> 12e5dd91fe34affa775a68d5341576b417530008
>
> Release Notes
> https://issues.apache.org/jira/projects/TOMEE/versions/12350178
>
> Sub-task
>
>- [TOMEE-3861 ] -
>Upgrade to apache-parent-26
>- [TOMEE-3865 ] -
>Switch arquillian to the new Servlet 5 protocol
>- [TOMEE-3866 ] -
>Upgrade Hibernate to 5.6.7 / Hibernate Validator to 7.0.2 (Jakarta
> Artifact)
>- [TOMEE-3868 ] -
>Remove SAAJ Axis 1 provider
>- [TOMEE-3869 ] -
>Remove JAX-RPC
>- [TOMEE-3870 ] -
>Remove Management J2EE
>- [TOMEE-3877 ] - No
>interface view EJB proxies broken on JDK16+
>- [TOMEE-3879 ] - Add
>missing --add-opens options to itests/failover
>- [TOMEE-3881 ] - Add
>JDK --add-opens to our scripts in openejb-standalone
>- [TOMEE-3920 ] - Fix
>TomEE :: Web Examples :: Moviefun Rest
>- [TOMEE-3922 ] -
>Patch Tomcat JasperInitializer and create jira
>- [TOMEE-3925 ] - Fix
>Websocket TLS Basic Auth
>- [TOMEE-3926 ] - Fix
>Webservice SSL Client Certificate Example
>- [TOMEE-3930 ] - fix
>arquillian-tomee-moviefun-example
>- [TOMEE-3931 ] - fix
>example/cucumber-jvm
>- [TOMEE-3932 ] -
>Migration tips and tricks
>- [TOMEE-3939 ] - Fix
>Jakarta Mail API with Apache Velocity Templating
>- [TOMEE-3940 ] - Fix
>TomEE :: Examples :: JakartaMail API
>- [TOMEE-3943 ] - Fix
>TomEE :: Examples :: Multiple JPA providers
>- [TOMEE-3944 ] - Fix
>TomEE :: Examples :: Simple EAR :: Functional Tests
>- [TOMEE-3953 ] - Fix
>TomEE :: Examples :: JPA with EclipseLink
>- [TOMEE-3954 ] - Fix
>TomEE :: Examples :: JPA with Hibernate and arquillian
>- [TOMEE-3956 ] - Fix
>TomEE :: Connector Examples :: Connector in WAR
>- [TOMEE-3957 ] - Fix
>TomEE :: Examples :: DeltaSpike @ConfigProperty
>- [TOMEE-3958 ] - Fix
>TomEE :: Examples :: DeltaSpike Exception Handling
>- [TOMEE-3959 ] - Fix
>TomEE :: Examples :: DeltaSpike I18n
>- [TOMEE-3960 ] - Fix
>TomEE :: Examples :: DeltaSpike ProjectStage
>
> Bug
>
>- [TOMEE-2420 ] -
>Incorrect "Wall of fame" page layout
>- [TOMEE-3739 ] - Fix
>JAX-RS landscape / regressions introduced during TCK Work
>- [TOMEE-3740 

[GitHub] [tomee] rzo1 commented on pull request #891: Tomee 3955

[GitBox]

rzo1 commented on PR #891:
URL: https://github.com/apache/tomee/pull/891#issuecomment-1173561075

   Thanks @tichovz 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee] rzo1 merged pull request #891: Tomee 3955

[GitBox]

rzo1 merged PR #891:
URL: https://github.com/apache/tomee/pull/891


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee] rzo1 merged pull request #892: TOMEE-3800 - DBCP 2.9.0

[GitBox]

rzo1 merged PR #892:
URL: https://github.com/apache/tomee/pull/892


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: TomEE 9.x - from javax to jakarta namespace

[Jean-Louis Monteiro]

Forgot the big thank you to everyone and special kudos to Richard.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Mon, Jul 4, 2022 at 10:49 AM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Hi,
>
> Bumping this thread up
> Not yet at the point where I'm clear on what path to use regarding the
> API, but it's been a while so I wanted to provide some status.
>
> You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2.
> This is the first real milestone for TomEE with the actual source code
> migrated to jakarta. It means that full packaged distributions (WebProfile,
> MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But the
> application composer, the JUnit support, even Arquillian are now fully
> migrated. We had to do a lot of shading/relocation of certain libraries on
> our side because libraries were not yet ready.
>
> We've worked very hard but we are finally looking good. We still have a
> few failures on our build to solve, but the platform TCK + CDI + BVal are
> looking good with less than 50 failures of 35K tests.
>
> Please remember this is a milestone and we are all still working on it.
> Any feedback is appreciated and will help.
>
> We started also upgrading our MicroProfile support to the latest one. So
> far Config, Health and Metrics are fully migrated and passing the TCK. We
> are actively working on MicroProfile JWT. And we'll be proceeding with the
> others when possible.
>
> If you haven't done it yet, please try it and feel free to vote.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
>> Hi,
>>
>> quick feedback before getting into more details
>>
>> A/ or this alternative
>> Geronimo Specs were not available in the Jakarta namespace. We are
>> starting to move some of them like Activation and Mail. Other than that, we
>> mainly have Eclipse produced APIs for Jakarta.
>> I'm not sure if we want to migrate our Geronimo Specs jars or use the
>> stock Jakarta APIs. Important note, if we do, we may not need the
>> jakartaee-api because there is already a Uber jar for Jakarta within the
>> different profiles. Should we get our user to use it as provided. And on
>> our side, should we create just a bom in our project and get the job done?
>>
>> Some APIs are also more or less implementations and vice versa. This is
>> the case for mail, faces, and some more as you mentioned. I'm fine
>> including Mail provider + Geronimo Mail spec in the jakartaee-api jar but
>> mind that in the past some users wanted to use Sun implementation and it
>> will be harder
>>
>> D/ what about inconsistencies like ...
>> Some implementations can be switched, for example Faces. Which is also a
>> mess because API and IMPL are linked together. I had previously the Faces
>> API but of course you need the implementation as well, same as for mail.
>> But Plume uses Mojorra. So we are in the situation where we need to pick
>> one or the other.
>>
>> B/ or this alternative ...
>> Tomcat classifier because we don't want to cheap with APIs already
>> provided in Tomcat with the risk of not being fully aligned. So we use
>> Tomcat APIs. Should we go the way around and remove Tomcat APIs from the
>> final distribution and get rid of the Tomcat classifier?
>>
>> Note sure if my reply is clear, hopefully it helps.
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>>
>> On Thu, May 26, 2022 at 3:23 AM David Blevins 
>> wrote:
>>
>>> Thanks so much for this.  I even started creating one myself early this
>>> morning, ... then the rest of the day happened LOL
>>>
>>> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
>>> jlmonte...@tomitribe.com> wrote:
>>> >
>>> > Here it is
>>> >
>>> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
>>>
>>> Looks like we've yanked out Faces, JSTL, Mail, etc.  I suspect we're
>>> trying to hit the line of not including APIs that are implementations.  The
>>> real trick is even HttpServlet is completely dependent on the servlet
>>> container in the same way Faces, Mail, JSTL, etc are dependent on their
>>> implementations.  I'm not too sure if Activation is also considered an
>>> implementation as well -- I'm not sure off-hand if there is a separate
>>> implementation jar.
>>>
>>> I know we didn't include mail in our javaee-api jar, so excluding is
>>> following that logic.  I also know we have the
>>> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything very
>>> close to the way we've now done it in jakartaee-api-9.1-M2-SNAPSHOT.jar
>>>
>>> How do we want to handle this?
>>>
>>> Seems our options are:
>>>
>>>  A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
>>> identical in missing many specs.  There is no uber jar people can compile
>>> against that has most everyth

Re: TomEE 9.x - from javax to jakarta namespace

[Jean-Louis Monteiro]

Hi,

Bumping this thread up
Not yet at the point where I'm clear on what path to use regarding the API,
but it's been a while so I wanted to provide some status.

You may have noticed the VOTE thread going on regarding TomEE 9.0.0-M2.
This is the first real milestone for TomEE with the actual source code
migrated to jakarta. It means that full packaged distributions (WebProfile,
MicroProfile, Plume and Plus ZIP/TAR.GZ) should be mostly working. But the
application composer, the JUnit support, even Arquillian are now fully
migrated. We had to do a lot of shading/relocation of certain libraries on
our side because libraries were not yet ready.

We've worked very hard but we are finally looking good. We still have a few
failures on our build to solve, but the platform TCK + CDI + BVal are
looking good with less than 50 failures of 35K tests.

Please remember this is a milestone and we are all still working on it. Any
feedback is appreciated and will help.

We started also upgrading our MicroProfile support to the latest one. So
far Config, Health and Metrics are fully migrated and passing the TCK. We
are actively working on MicroProfile JWT. And we'll be proceeding with the
others when possible.

If you haven't done it yet, please try it and feel free to vote.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Thu, May 26, 2022 at 1:28 PM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Hi,
>
> quick feedback before getting into more details
>
> A/ or this alternative
> Geronimo Specs were not available in the Jakarta namespace. We are
> starting to move some of them like Activation and Mail. Other than that, we
> mainly have Eclipse produced APIs for Jakarta.
> I'm not sure if we want to migrate our Geronimo Specs jars or use the
> stock Jakarta APIs. Important note, if we do, we may not need the
> jakartaee-api because there is already a Uber jar for Jakarta within the
> different profiles. Should we get our user to use it as provided. And on
> our side, should we create just a bom in our project and get the job done?
>
> Some APIs are also more or less implementations and vice versa. This is
> the case for mail, faces, and some more as you mentioned. I'm fine
> including Mail provider + Geronimo Mail spec in the jakartaee-api jar but
> mind that in the past some users wanted to use Sun implementation and it
> will be harder
>
> D/ what about inconsistencies like ...
> Some implementations can be switched, for example Faces. Which is also a
> mess because API and IMPL are linked together. I had previously the Faces
> API but of course you need the implementation as well, same as for mail.
> But Plume uses Mojorra. So we are in the situation where we need to pick
> one or the other.
>
> B/ or this alternative ...
> Tomcat classifier because we don't want to cheap with APIs already
> provided in Tomcat with the risk of not being fully aligned. So we use
> Tomcat APIs. Should we go the way around and remove Tomcat APIs from the
> final distribution and get rid of the Tomcat classifier?
>
> Note sure if my reply is clear, hopefully it helps.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Thu, May 26, 2022 at 3:23 AM David Blevins 
> wrote:
>
>> Thanks so much for this.  I even started creating one myself early this
>> morning, ... then the rest of the day happened LOL
>>
>> > On May 25, 2022, at 1:56 PM, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> wrote:
>> >
>> > Here it is
>> >
>> https://gist.github.com/jeanouii/9bb6c14bdde227e2fed83fd73db3a646/revisions
>>
>> Looks like we've yanked out Faces, JSTL, Mail, etc.  I suspect we're
>> trying to hit the line of not including APIs that are implementations.  The
>> real trick is even HttpServlet is completely dependent on the servlet
>> container in the same way Faces, Mail, JSTL, etc are dependent on their
>> implementations.  I'm not too sure if Activation is also considered an
>> implementation as well -- I'm not sure off-hand if there is a separate
>> implementation jar.
>>
>> I know we didn't include mail in our javaee-api jar, so excluding is
>> following that logic.  I also know we have the
>> jakartaee-api-9.1-M2-SNAPSHOT-tomcat.jar, which cuts out everything very
>> close to the way we've now done it in jakartaee-api-9.1-M2-SNAPSHOT.jar
>>
>> How do we want to handle this?
>>
>> Seems our options are:
>>
>>  A. Leave jakartaee-api-X.jar and jakartaee-api-X-tomcat.jar nearly
>> identical in missing many specs.  There is no uber jar people can compile
>> against that has most everything.  People would need to discover which
>> specs are missing and pull them in individually.
>>
>>  B. Eliminate having two jars, there is now just
>> jakartaee-api-X-tomcat.jar (which we call jakartaee-api-X.jar).  There is
>> no uber jar people can compile against that has most everything.  People
>> would need to discover which specs are missing and pull them in
>> indiv