Re: [VOTE] Apache TomEE 9.1.3

[Mark Struberg]

lgtm

+1

txs and LieGrue,
strub

> Am 08.04.2024 um 11:33 schrieb Richard Zowalla :
> 
> Hello everyone,
> 
> This is a vote for the release of Apache TomEE 9.1.3
> 
> It contains some version upgrades (cxf, jackson, batchee) and security
> backports for the recent Tomcat CVEs.
> 
> Here are the hard facts:
> 
> ###
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1227/
> 
> 
> 
> tomee-9.1.3-rc1
> Testing TomEE 9.1.3
> 
> https://repository.apache.org/content/repositories/orgapachetomee-1227/
> 
> 
> 
> 
> ###
> 
> Binaries & Source:
> 
> https://dist.apache.org/repos/dist/dev/tomee/staging-1227/tomee-9.1.3/
> 
> ###
> 
> Tag:
> 
> https://github.com/apache/tomee/releases/tag/tomee-project-9.1.3
> 
> ###
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12354125
> 
> ###
> 
> Here is an adoc generated version of the changelog as well:
> 
> == Dependency upgrade
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4305[TOMEE-4305]
> Backport fix for CVE-2024-23672 for TomEE 9.x
> - link:https://issues.apache.org/jira/browse/TOMEE-4306[TOMEE-4306]
> Backport fix for CVE-2024-24549 for TomEE 9.x
> - link:https://issues.apache.org/jira/browse/TOMEE-4316[TOMEE-4316]
> BatchEE 1.0.4
> - link:https://issues.apache.org/jira/browse/TOMEE-4290[TOMEE-4290]
> Jackson 2.16.2
> - link:https://issues.apache.org/jira/browse/TOMEE-4304[TOMEE-4304]
> cxf-core 4.0.4
> 
> == New Feature
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-3902[TOMEE-3902]
> Introduce placeholder replacement to enable MDB activation properties
> to be more customizable
> 
> == Bug
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4295[TOMEE-4295]
> tomee-embedded-maven-plugin does not register microprofile endpoints
> 
> 
> ###
> 
> Please note:
> 
> Grype will report a vulnerability for 
> 
> apache-mime4j-core  0.8.7  0.8.10java-archive  GHSA-jw7r-rxff-
> gv24  Medium
> 
> which is shaded inside of "geronimo-mail_2.1_spec-1.0.0-M1.jar".
> 
> In it's current version, the dependency is _NOT_ used inside of
> geronimo mail impl, so unless you are using the shaded classes
> yourself, we are not affected here.
> There is also another mail thread related to mail.
> 
> For signature verification, you can check on the example script here:
> https://gist.github.com/rzo1/9fb1ca0d58e1fc982d596f2a94b10b32
> 
> ###
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h or as long as needed.
> 
> Gruß
> Richard
> 
> 
> P.S. On a personal note: This will be the last TomEE 9.1.x release I
> will be working on (no backports from my side anymore). I decided to
> invest my volunteer time in TomEE 10+ only. If someone else wants to
> maintain the 9.x line, I am happy to review related PRs.

Re: [VOTE] Apache TomEE 10.0.0-M1

[Mark Struberg]

+1

txs and LieGrue,
strub


> Am 02.04.2024 um 09:47 schrieb Richard Zowalla :
> 
> Hello everyone,
> 
> This is a vote for the release of Apache TomEE 10.0.0-M1.
> 
> It is a first milestone release of TomEE 10 targeting JakartaEE 10.
> Thanks to everyone who contributed code to make this happen.
> I would like to emphasise and give a shout out to all our volunteers
> who have done the hard work for EE10, which is also done in all our
> upstream dependencies like Tomcat, OWB, CXF, MyFaces, etc.
> 
> This milestone release is not fully compliant with JakartaEE 10 as we
> are missing some EE10 compatible versions of our dependencies (most
> notably CXF 4.1.x which isn't available yet).
> We do not pass the TCK, nor do we have a fully working TCK setup at the
> moment. However, our own full build is green [1] and so I am happy to
> call for a vote to release a first milestone of TomEE 10.
> 
> Here are the hard facts:
> 
> ###
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1226/
> 
> 
> 
> tomee-10.0.0-M1-rc1
> Testing TomEE 10.0.0-M1
> 
> https://repository.apache.org/content/repositories/orgapachetomee-1226/
> 
> 
> 
> 
> ###
> 
> Binaries & Source:
> 
> https://dist.apache.org/repos/dist/dev/tomee/staging-1226/tomee-10.0.0-M1/
> 
> ###
> 
> Tag:
> 
> https://github.com/apache/tomee/releases/tag/tomee-project-10.0.0-M1
> 
> 
> ###
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12352714
> 
> ###
> 
> Here is an adoc generated version of the changelog as well:
> 
> == Dependency upgrade
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4266[TOMEE-4266]
> ActiveMQ 5.16.7 / 5.18.3
> - link:https://issues.apache.org/jira/browse/TOMEE-4217[TOMEE-4217]
> Arquillian 1.7.0.Final
> - link:https://issues.apache.org/jira/browse/TOMEE-4307[TOMEE-4307]
> BatchEE 1.0.4
> - link:https://issues.apache.org/jira/browse/TOMEE-4235[TOMEE-4235]
> Bouncy Castle 1.75
> - link:https://issues.apache.org/jira/browse/TOMEE-4243[TOMEE-4243]
> Bouncy Castle 1.76
> - link:https://issues.apache.org/jira/browse/TOMEE-4278[TOMEE-4278]
> Commons CLI 1.6.0
> - link:https://issues.apache.org/jira/browse/TOMEE-4277[TOMEE-4277]
> Commons Codec 1.16.0
> - link:https://issues.apache.org/jira/browse/TOMEE-4274[TOMEE-4274]
> Commons DBCP 2.11.0
> - link:https://issues.apache.org/jira/browse/TOMEE-4275[TOMEE-4275]
> Commons Lang3 3.13.0
> - link:https://issues.apache.org/jira/browse/TOMEE-4310[TOMEE-4310]
> Commons Net 3.9.0
> - link:https://issues.apache.org/jira/browse/TOMEE-4308[TOMEE-4308]
> Fileupload 2 (Jakarta
> - link:https://issues.apache.org/jira/browse/TOMEE-4218[TOMEE-4218]
> HSQLDB 2.7.2
> - link:https://issues.apache.org/jira/browse/TOMEE-4221[TOMEE-4221]
> JUnit 5.9.3
> - link:https://issues.apache.org/jira/browse/TOMEE-4212[TOMEE-4212]
> Jackson 2.15.0
> - link:https://issues.apache.org/jira/browse/TOMEE-4216[TOMEE-4216]
> Jackson 2.15.1
> - link:https://issues.apache.org/jira/browse/TOMEE-4227[TOMEE-4227]
> Jackson 2.15.2
> - link:https://issues.apache.org/jira/browse/TOMEE-4276[TOMEE-4276]
> Jackson 2.15.3
> - link:https://issues.apache.org/jira/browse/TOMEE-4208[TOMEE-4208]
> Johnzon 1.2.20
> - link:https://issues.apache.org/jira/browse/TOMEE-4228[TOMEE-4228]
> Johnzon 1.2.21
> - link:https://issues.apache.org/jira/browse/TOMEE-4205[TOMEE-4205]
> Jose4j 0.9.3
> - link:https://issues.apache.org/jira/browse/TOMEE-4279[TOMEE-4279]
> Log4J2 2.21.1
> - link:https://issues.apache.org/jira/browse/TOMEE-4296[TOMEE-4296]
> MicroProfile JWT 2.1
> - link:https://issues.apache.org/jira/browse/TOMEE-4283[TOMEE-4283]
> OWB 4.0.1
> - link:https://issues.apache.org/jira/browse/TOMEE-4282[TOMEE-4282]
> Tomcat 10.1.16
> - link:https://issues.apache.org/jira/browse/TOMEE-4309[TOMEE-4309]
> Tomcat 10.1.20
> - link:https://issues.apache.org/jira/browse/TOMEE-4280[TOMEE-4280]
> WSS4J 3.0.2
> - link:https://issues.apache.org/jira/browse/TOMEE-4313[TOMEE-4313]
> XBean 4.24
> - link:https://issues.apache.org/jira/browse/TOMEE-4232[TOMEE-4232]
> bcprov-jdk15to18-1.74.jar
> - link:https://issues.apache.org/jira/browse/TOMEE-4220[TOMEE-4220]
> log4j 2.20.0 (integration)
> - link:https://issues.apache.org/jira/browse/TOMEE-4311[TOMEE-4311]
> log4j2 2.23.1
> - link:https://issues.apache.org/jira/browse/TOMEE-4312[TOMEE-4312]
> slf4j 2.0.12
> - link:https://issues.apache.org/jira/browse/TOMEE-4213[TOMEE-4213]
> snakeyaml version 2.0 mitigate CVE-2022-1471
> - link:https://issues.apache.org/jira/browse/TOMEE-4219[TOMEE-4219]
> xbeans 4.23
> 
> == New Feature
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4268[TOMEE-4268]
> Create MicroProfile OpenAPI Reader exemple
> - link:https://issues.apache.org/jira/browse/TOMEE-4281[TOMEE-4281]
> Improve logging when failing to load a class
> 
> == Bug
> 
> [.compact]
> - 

Re: [DISCUSS] Challenge against BatchEE TCK: com.ibm.jbatch.tck.tests.jslxml.CDITests#testCDILookup(...)

[Mark Struberg]

I did dig into the details of the current latest spec and it's really clear 
that CDI.current() to look up a BatchProperty is NOT supported by the spec!

https://github.com/eclipse-ee4j/batch-api/blob/master/spec/src/main/asciidoc/batch_programming_model.adoc#batchproperty-definition

"The @BatchProperty annotation identifies an injection as a batch property. A 
batch property has a name (name) and, in case of a field injection, also has a 
default value. @BatchProperty is used to assign batch artifact property values 
from Job XML to the batch artifact itself.
Note that @BatchProperty is used with the standard @Inject annotation 
(jakarta.inject.Inject) ..."

This clearly states it: no BatchProperty without @Inject!

Further down it is even clearer:

https://github.com/eclipse-ee4j/batch-api/blob/master/spec/src/main/asciidoc/batch_programming_model.adoc#method-parameter-and-constructor-parameter-injection-with-explicit-name
"A batch runtime must support injection of the CDI Bean representing the batch 
property via method parameter and constructor parameter injection, in addition 
to supporting field injection."

The valid options are:
* param injection
* ct injection
* field injection
but no CDI.current().select()...

Feel free to reference this when creating a TCK challenge.

txs and LieGrue,
strub


> Am 23.02.2024 um 09:01 schrieb Mark Struberg :
> 
> Please create a TCK Challenge and disable the test for now.
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 22.02.2024 um 20:09 schrieb Richard Zowalla :
>> 
>> Hi all,
>> 
>> I want to get consensus on filling a TCK challenge against the Batch
>> TCK. As written in the other thread, I am currently working on getting
>> a Jakarta Batch 2.1 ready version of Batch EE for usage in TomEE 10
>> [1]. The most significant change is, that CDI support is now required.
>> 
>> == Details
>> 
>> This implementation passes the Batch TCK with one exception [2]
>> 
>> com.ibm.jbatch.tck.tests.jslxml.CDITests#testCDILookup(...) 
>> 
>> This test uses dynamic CDI injections to resolve batch properties in a
>> non CDI batchlet [3]. As Geronimo BatchEE is a fork of the reference
>> impl with some neat adjustments, we are more or less using a producer
>> bean more or less similar to the reference impl: [4, 5]. The major
>> difference between both impls is, that we are using OWB while the
>> reference impl uses Weld.
>> 
>> So for the TCK test in question with this line 
>> 
>>  cdi.select(String.class, new BatchPropertyLiteral("prop1")).get();
>> 
>> in [6], the following will happen:
>> 
>> - OWB will invoke the producer in [4] with a NULL InjectionPoint 
>> - Weld will invoke the producer in [5] with a "fake" InjectionPoint
>> with InjectionPoint#getMember == NULL.
>> 
>> The JavaDoc of InjectionPoint [7] or more specifically of
>> InjectionPoint#getMember() does not tell us, if the return value can be
>> NULL.
>> 
>> However, we find a code example in the interface docs:
>> 
>> @Produces
>> Logger createLogger(InjectionPoint injectionPoint) {
>>return
>> Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName
>> ());
>> }
>> 
>> If InjectionPoint#getMember() can be NULL, this code example would
>> throw a NullPointerException. So from my point of view, Weld violates
>> the current JavaDoc of InjectionPoint by injecting a "fake"
>> InjectionPoint without a member. 
>> 
>> InjectionPoint#getBean can return NULL and it is stated, any other
>> method can't - intentionally cause an Instance only defines an
>> InjectionPoint when there is one.
>> 
>> So from my point of view the test relies on weld-specific behaviour as
>> there is an ambiquity in the CDI 4.0 spec / javadocs regarding
>> InjectionPoint#getMember() here. KUDOS to Thomas & Romain for helping &
>> tracking it down to the actual ambiquity in the Javadocs ;-)
>> 
>> In addition, the Jakarta Batch spec is rather explicit in its
>> definition in [8]. IMHO, it would be good for the spec to just delegate
>> the CDI spec and just write something like "As a consequence of the
>> previous section, an application must be able to get a CDI Bean with a
>> correct view of a batch property by using CDI" instead of adding
>> related details which require CDI knowledge.
>> 
>> Before thinking about raising a challenge, I already had a quick
>> discussion with Thomas and Romain about it and Romain suggested to put
>> up a PR for an updated test, which does an indirection to a bean, which
>> is here (+ some discu

Re: [DISCUSS] Challenge against BatchEE TCK: com.ibm.jbatch.tck.tests.jslxml.CDITests#testCDILookup(...)

[Mark Struberg]

Please create a TCK Challenge and disable the test for now.

txs and LieGrue,
strub


> Am 22.02.2024 um 20:09 schrieb Richard Zowalla :
> 
> Hi all,
> 
> I want to get consensus on filling a TCK challenge against the Batch
> TCK. As written in the other thread, I am currently working on getting
> a Jakarta Batch 2.1 ready version of Batch EE for usage in TomEE 10
> [1]. The most significant change is, that CDI support is now required.
> 
> == Details
> 
> This implementation passes the Batch TCK with one exception [2]
> 
> com.ibm.jbatch.tck.tests.jslxml.CDITests#testCDILookup(...) 
> 
> This test uses dynamic CDI injections to resolve batch properties in a
> non CDI batchlet [3]. As Geronimo BatchEE is a fork of the reference
> impl with some neat adjustments, we are more or less using a producer
> bean more or less similar to the reference impl: [4, 5]. The major
> difference between both impls is, that we are using OWB while the
> reference impl uses Weld.
> 
> So for the TCK test in question with this line 
> 
>   cdi.select(String.class, new BatchPropertyLiteral("prop1")).get();
> 
> in [6], the following will happen:
> 
> - OWB will invoke the producer in [4] with a NULL InjectionPoint 
> - Weld will invoke the producer in [5] with a "fake" InjectionPoint
> with InjectionPoint#getMember == NULL.
> 
> The JavaDoc of InjectionPoint [7] or more specifically of
> InjectionPoint#getMember() does not tell us, if the return value can be
> NULL.
> 
> However, we find a code example in the interface docs:
> 
> @Produces
> Logger createLogger(InjectionPoint injectionPoint) {
> return
> Logger.getLogger(injectionPoint.getMember().getDeclaringClass().getName
> ());
> }
> 
> If InjectionPoint#getMember() can be NULL, this code example would
> throw a NullPointerException. So from my point of view, Weld violates
> the current JavaDoc of InjectionPoint by injecting a "fake"
> InjectionPoint without a member. 
> 
> InjectionPoint#getBean can return NULL and it is stated, any other
> method can't - intentionally cause an Instance only defines an
> InjectionPoint when there is one.
> 
> So from my point of view the test relies on weld-specific behaviour as
> there is an ambiquity in the CDI 4.0 spec / javadocs regarding
> InjectionPoint#getMember() here. KUDOS to Thomas & Romain for helping &
> tracking it down to the actual ambiquity in the Javadocs ;-)
> 
> In addition, the Jakarta Batch spec is rather explicit in its
> definition in [8]. IMHO, it would be good for the spec to just delegate
> the CDI spec and just write something like "As a consequence of the
> previous section, an application must be able to get a CDI Bean with a
> correct view of a batch property by using CDI" instead of adding
> related details which require CDI knowledge.
> 
> Before thinking about raising a challenge, I already had a quick
> discussion with Thomas and Romain about it and Romain suggested to put
> up a PR for an updated test, which does an indirection to a bean, which
> is here (+ some discussion / details): [9]. 
> 
> Long story short:
> 
> - Did we miss something obvious? 
> - Does this consistute for a valid challenge against the Batch TCK? 
> - Any other thoughts on it?
> 
> Happy to get some opinions.
> 
> Gruß
> Richard
> 
> 
> [1] https://github.com/apache/geronimo-batchee/pull/21
> [2]
> https://github.com/eclipse-ee4j/batch-tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/tests/jslxml/CDITests.java#L287
> [3]
> https://github.com/eclipse-ee4j/batch-tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/artifacts/cdi/NonCDIBeanBatchlet.java
> [4]
> https://github.com/rzo1/geronimo-batchee/blob/jakarta/jbatch/src/main/java/org/apache/batchee/container/cdi/BatchProducerBean.java#L67
> [5]
> https://github.com/WASdev/standards.jsr352.jbatch/blob/master/com.ibm.jbatch.container/src/main/java/com/ibm/jbatch/container/cdi/BatchProducerBean.java#L96
> [6]
> https://github.com/eclipse-ee4j/batch-tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/artifacts/cdi/NonCDIBeanBatchlet.java#L51
> [7]
> https://jakarta.ee/specifications/cdi/4.0/apidocs/jakarta.cdi/jakarta/enterprise/inject/spi/injectionpoint
> [8]
> https://jakarta.ee/specifications/batch/2.1/jakarta-batch-spec-2.1#consequences-and-suggested-patterns
> [9] https://github.com/eclipse-ee4j/batch-tck/pull/69

OSGi information in TomEE 9 and 10

[Mark Struberg]

Hi!

Seems we do need to update our OSGi import declarations?
view-source:https://repo1.maven.org/maven2/org/apache/tomee/openejb-core/9.1.1/openejb-core-9.1.1.pom

  org.apache.openejb.jee.wls;version="[4.0,5)",
  org.apache.openejb.loader;version="[4.0,5)",
  org.apache.openejb.client;bundle-version="[4.0,5.0)";resolution:=optional,
  
org.apache.openejb.client.proxy;bundle-version="[4.0,5.0)";resolution:=optional,
  
org.apache.openejb.client.java;bundle-version="[4.0,5.0)";resolution:=optional,
  org.openejb.client;bundle-version="[4.0,5.0)";resolution:=optional,
  org.apache.openjpa.event;resolution:=optional;version="[2.1,3)",
  org.apache.openjpa.persistence;resolution:=optional;version="[2.1,3)",
  org.apache.webbeans.annotation;version="[1.1,2)",
  org.apache.webbeans.component;version="[1.1,2)",
  org.apache.webbeans.component.creation;version="[1.1,2)",
  org.apache.webbeans.config;version="[1.1,2)",
Sounds really outdated to me.

LieGrue,
strub

Re: [VOTE] TomEE 9.1.0

[Mark Struberg]

quick check looks fine

+1 (binding)

txs and LieGrue,
strub


> Am 06.06.2023 um 13:01 schrieb Richard Zowalla :
> 
> Hi all,
> 
> this is a vote for a release of Apache TomEE 9.1.0.
> 
> It is a maintenance release with some bug fixes and dependencies
> upgrades (MicroProfile 5, ActiveMQ, Johnzon, XBean, etc). 
> 
> It also fixes the latest Tomcat vulnerabilities (CVE-2023-28708, CVE-
> 2023-24998, CVE-2023-28709) by backporting and patching Tomcat inside
> the TomEE 9 build.
> 
> ###
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1217/
> 
> 
> 
> tomee-9.1.0-rc1
> Testing TomEE 9.1.0 RC1
> 
> https://repository.apache.org/content/repositories/orgapachetomee-1217/
> 
> 
> 
> 
> ###
> 
> Binaries & Source:
> 
> https://dist.apache.org/repos/dist/dev/tomee/staging-1217/tomee-9.1.0/
> 
> ###
> 
> Tag:
> 
> https://github.com/apache/tomee/releases/tag/tomee-project-9.1.0
> 
> 
> ###
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12353156
> 
> ###
> 
> Here is an adoc generated version of the changelog as well:
> 
> == Dependency upgrade
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4217[TOMEE-4217]
> Arquillian 1.7.0.Final
> - link:https://issues.apache.org/jira/browse/TOMEE-4204[TOMEE-4204]
> Bouncycastle 1.73
> - link:https://issues.apache.org/jira/browse/TOMEE-4187[TOMEE-4187]
> Commons FileUpload 1.5
> - link:https://issues.apache.org/jira/browse/TOMEE-4218[TOMEE-4218]
> HSQLDB 2.7.2
> - link:https://issues.apache.org/jira/browse/TOMEE-4221[TOMEE-4221]
> JUnit 5.9.3
> - link:https://issues.apache.org/jira/browse/TOMEE-4212[TOMEE-4212]
> Jackson 2.15.0
> - link:https://issues.apache.org/jira/browse/TOMEE-4216[TOMEE-4216]
> Jackson 2.15.1
> - link:https://issues.apache.org/jira/browse/TOMEE-4208[TOMEE-4208]
> Johnzon 1.2.20
> - link:https://issues.apache.org/jira/browse/TOMEE-4205[TOMEE-4205]
> Jose4j 0.9.3
> - link:https://issues.apache.org/jira/browse/TOMEE-4203[TOMEE-4203]
> Microprofile Config API 3.0.3, Fault Tolerance Impl 6.2.2, OpenTracing
> Impl 3.0.3
> - link:https://issues.apache.org/jira/browse/TOMEE-4141[TOMEE-4141]
> SmallRye on 9.x branch
> - link:https://issues.apache.org/jira/browse/TOMEE-4061[TOMEE-4061]
> Wrap up updates for TomEE 9.x
> - link:https://issues.apache.org/jira/browse/TOMEE-4220[TOMEE-4220]
> log4j 2.20.0 (integration)
> - link:https://issues.apache.org/jira/browse/TOMEE-4213[TOMEE-4213]
> snakeyaml version 2.0 mitigate CVE-2022-1471
> - link:https://issues.apache.org/jira/browse/TOMEE-4219[TOMEE-4219]
> xbeans 4.23
> 
> == Bug
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4181[TOMEE-4181]
> BCProv jar loses its signature during the patch process
> - link:https://issues.apache.org/jira/browse/TOMEE-4183[TOMEE-4183]
> TomEE 9.0.0 is not creating service in Windows 10 incompatible software
> - link:https://issues.apache.org/jira/browse/TOMEE-4189[TOMEE-4189]
> java.lang.ClassNotFoundException:
> org.apache.openejb.loader.SystemInstance
> - link:https://issues.apache.org/jira/browse/TOMEE-4192[TOMEE-4192]
> ApplicationComposers do not clear GC references on release
> - link:https://issues.apache.org/jira/browse/TOMEE-4174[TOMEE-4174]
> Port TOMEE-3779 to 9.x
> - link:https://issues.apache.org/jira/browse/TOMEE-4199[TOMEE-4199]
> jakartaee-api with tomcat classifier has too much in it
> - link:https://issues.apache.org/jira/browse/TOMEE-4112[TOMEE-4112]
> Performance Regression in bean resolution in EAR files
> 
> == Improvement
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4200[TOMEE-4200]
> Use ActiveMQ client jakarta instead of shading it in TomEE
> - link:https://issues.apache.org/jira/browse/TOMEE-4202[TOMEE-4202]
> Backport CVE fixes of Tomcat 10.1.x to 10.0.27
> 
> == Task
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4053[TOMEE-4053]
> Dependency properties cleanup
> 
> == Documentation
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4186[TOMEE-4186]
> Update download page for discontinued branches
> 
> == Wish
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4190[TOMEE-4190]
> RunWithApplicationComposer should support inheritance
> 
> == Fixed Common Vulnerabilities and Exposures (CVEs)
> 
> [.compact]
> - link:https://issues.apache.org/jira/browse/TOMEE-4187[TOMEE-4187]
> Commons FileUpload 1.5
> - link:https://issues.apache.org/jira/browse/TOMEE-4202[TOMEE-4202]
> Backport CVE fixes of Tomcat 10.1.x to 10.0.27
> 
> ###
> 
> Here is the dependency diff from 8.0.14 to 8.0.15 created with our
> release tools:
> 
>artifactId   from  to   
> --  
> jackson-annotations2.14.1   2.15.1 
> jackson-core   2.14.1   2.15.1 
> jackson-databind   

Re: [VOTE] JakartaEE API 9.1.1

[Mark Struberg]

+1

txs and LieGrue,
strub

> Am 16.05.2023 um 21:59 schrieb Richard Zowalla :
> 
> Hi all,
> 
> this is a vote for a maintenance of our JakartaEE 9.1 shade artifact
> 
> This bug fix release only fixes TOMEE-4199:
> https://issues.apache.org/jira/browse/TOMEE-4199
> 
> ###
> 
> Maven Repo:
> 
> https://repository.apache.org/content/repositories/orgapachetomee-1216/
> 
> ###
> 
> Source:
> 
> https://dist.apache.org/repos/dist/dev/tomee/staging-1216/
> 
> ###
> 
> Tag:
> 
> https://github.com/apache/tomee-jakartaee-api/releases/tag/jakartaee-api-9.1.1
> 
> 
> ###
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h or as long as needed.
> 
> Gruß
> Richard
> 

Re: [VOTE] Apache TomEE Patch Plugin 0.10

[Mark Struberg]

+1

LieGrue,
strub

> Am 02.01.2023 um 12:31 schrieb Jean-Louis Monteiro :
> 
> Hi,
> 
> I'd like to vote Apache TomEE Patch Plugin 0.10 up for vote. The changes
> are fairly minimal and consist of patching the source jar so that IDE isn't
> lost. This release is required so we can then quickly push 9.0.0 final.
> 
> Changes:
> 
> - TOMEE-4136 Support sources patching
> 
> Sources:
> 
> https://dist.apache.org/repos/dist/dev/tomee/tomee-patch-plugin_staging-1209/
> 
> Staging Nexus Repository:
> 
> https://repository.apache.org/content/repositories/orgapachetomee-1209
> 
> Tag:
> 
> https://github.com/apache/tomee-patch-plugin/tree/tomee-patch-parent-0.10
> 
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Jean-Louis
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: [VOTE] Apache TomEE 9.0.0

[Mark Struberg]

+1

LieGrue,
strub

> Am 03.01.2023 um 10:53 schrieb Jean-Louis Monteiro :
> 
> Hi all,
> 
> I'm very proud to call a vote for Apache TomEE 9.0.0 final. It's been
> almost a year since we certified the server using a bytecode enhancement
> approach. Even though it worked, it introduced a lot of restrictions
> especially with tooling (IDE, Arquillian, Embedded container, etc).
> 
> We started migrating the entire server to the new jakarta namespace and the
> 9.0.0 final is the result of such work. We fully passed the entire TCK for
> Jakarta EE 9.1 and cherry on the cake, we decided to address a long time
> request to support a newer version of MicroProfile. So I'm pleased to also
> announce that this version is fully MicroProfile 5.0 compliant.
> 
> - Sources
> https://dist.apache.org/repos/dist/dev/tomee/tomee_staging-1210/
> 
> - Maven staging repository
> https://repository.apache.org/content/repositories/orgapachetomee-1210
> 
> - Signing keys
> https://dist.apache.org/repos/dist/release/tomee/KEYS
> 
> - Changelog since last milestone
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12350136
> Sub-task
> 
>   - [TOMEE-3883 ] -
>   Update example 'mvc-resteasy' to use Server/API Bom - master branch
>   - [TOMEE-3950 ] -
>   Support for JWT token cookies
>   - [TOMEE-3951 ] - JWT
>   token groups claim is now optional
>   - [TOMEE-3952 ] -
>   Deprecate RSA keys of 1024 bit length
> 
> Bug
> 
>   - [TOMEE-4065 ] -
>   LoginToContinue interceptor fails on custom auth mechanism
>   - [TOMEE-4117 ] -
>   MicroProfile OpenAPI not generating model
>   - [TOMEE-4119 ] -
>   TomEEJsonbProvider triggered for */* mime types
>   - [TOMEE-4135 ] -
>   Unable to see TomEE version in Tomcat home page with Java 17
> 
> New Feature
> 
>   - [TOMEE-3946 ] -
>   MicroProfile JWT 2.0
>   - [TOMEE-4050 ] -
>   Retry and Refresh for MP JWT keys supplied via HTTP
>   - [TOMEE-4068 ] -
>   MicroProfile 5.0
>   - [TOMEE-4069 ] -
>   MicroProfile Config 3.0
>   - [TOMEE-4070 ] -
>   MicroProfile Fault Tolerance 4.0
>   - [TOMEE-4071 ] -
>   MicroProfile Health 4.0
>   - [TOMEE-4072 ] -
>   MicroProfile Metrics 4.0
>   - [TOMEE-4073 ] -
>   MicroProfile Rest Client 3.0
>   - [TOMEE-4074 ] -
>   MicroProfile OpenAPI 3.0
>   - [TOMEE-4075 ] -
>   MicroProfile OpenTracing 3.0
>   - [TOMEE-4076 ] -
>   Public Keys in OpenSSH format
>   - [TOMEE-4077 ] -
>   Public Keys in SSH2 format
>   - [TOMEE-4078 ] - RSA
>   keys PKCS 1 format
>   - [TOMEE-4079 ] -
>   Elliptic Curve JWS and JWE
>   - [TOMEE-4123 ] -
>   Implement @AroundConstruct from Interceptor 1.2
> 
> Improvement
> 
>   - [TOMEE-4080 ] -
>   Improved Logging for Public and Private Key resolution
>   - [TOMEE-4124 ] -
>   Remove timing of timing just for logging
> 
> Task
> 
>   - [TOMEE-3915 ] - Fix
>   Post release pom versioning for Master branch
> 
> Dependency upgrade
> 
>   - [TOMEE-4081 ] -
>   Jackson 2.13.4
>   - [TOMEE-4082 ] -
>   Woodstox 6.2.6
>   - [TOMEE-4103 ] -
>   Update woodstox-core to mitigate CVE-2022-40153
>   - [TOMEE-4107 ] -
>   Jackson 2.14.0
>   - [TOMEE-4109 ] -
>   Velocity 2.3
>   - [TOMEE-4110 ] -
>   Woodstox 6.4.0 (CVE-2022-40152)
>   - [TOMEE-4111 ] -
>   Upgrade bcel component in TomEE
>   - [TOMEE-4125 ] -
>   Update Apache CXF versions to 

Re: Geronimo future if any

[Mark Struberg]

The whole point of Geronimo is nowadays to provide common reusable EE parts for 
other ASF projects.
This is important for many projects which do not depend on TomEE. E.g. all the 
parts TomEE is actually using.

I do agree that those parts are moving a bit slower. But there is a very low 
boundary of becoming a committer in Geronimo and there are plenty of people 
around still.
A few pieces - like MP are indeed not actively maintained anymore. But others 
are, BatchEE being one of em, mail, txmgr, etc as well.

Splitting workforce is probably not the best solution but in the end it's a 
tomee community decision about how to move forward. 

The trend I do see is that EE is becoming bigger and bigger again. Adding 
functionality to the specs which are almost vendor specific and others which 
are very short lived is not helping. My personal preference would be to have 
libraries with a very small core which only implement the very core parts of a 
spec and having all the other features pluggable on top. This is not something 
which can be done easily in TomEE as here its about full spec compatibility. 
It's always a trade off.

LieGrue,
strub



> Am 20.11.2022 um 12:33 schrieb Jean-Louis Monteiro :
> 
> Hi all,
> 
> It's been a couple of months since it started. It never really landed but
> it's getting more and more obvious that there is absolutely no desire to
> keep the Geronimo project.
> 
> The goal of this email isn't really to discuss the reasons or argue if it
> should or not disappear, but more to discuss the impacts for TomEE itself.
> If you want to argue or discuss, you are more than welcome to do it on the
> Geronimo mailing list.
> 
> We do use from the Geronimo project (not exhaustive list, but good start)
> 
> - specs jars - they are mostly outdated and not sure anyone will do the
> jakarta translation. Is it still useful now that Jakarta is at Eclipse to
> have our own APIs? (used by other projects at Apache)
> 
> - Activation and Mail - maybe a good opportunity to create a
> tomee-activation and a tomee-mail project and take the source for jakarta
> translation (used by other projects at Apache)
> 
> - Connector and Transaction Manager - same we could grab those and create a
> specific project tomee-connector and tomee-transaction (used by other
> projects at Apache)
> 
> - BatchEE - to become tomee-jbatch
> 
> - xbean - low level libraries but it's a critical part in many aspects of
> TomEE. It can also become tomee-xbean (used by other projects at Apache)
> 
> - MP implementation - they will most likely be moved to dormant so the code
> remains accessible and it can be revived at any time
> 
> Note that for simplicity, we could create a tomee-foo with submodules so we
> could have all projects under the same github project. They do not have the
> same lifecycle so I went one-to-one at first glance.
> 
> Maybe some of them (or all) could also be TomEE submodules in the current
> tree. I'm just concerned that for modules that don't leave too much, we
> will have the build to become more complex and also take more time which is
> already an issue. I'd be tempted to look at TomEE and extract parts that
> don't leave too much or with a different lifecycle into their own project.
> 
> Thoughts?
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: [VOTE] Apache TomEE 8.0.11 - take 2

[Mark Struberg]

+1 (binding)

LieGrue,
strub

> Am 20.04.2022 um 13:26 schrieb Alex The Rocker :
> 
> Hello,
> 
> All tests finished, +1 (non binding)
> 
> Thanks,
> Alex
> 
> Le ven. 15 avr. 2022 à 22:26, Jean-Louis Monteiro
>  a écrit :
>> 
>> My own +1 (binding)
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 
>> 
>> On Fri, Apr 15, 2022 at 5:02 PM Daniel Cunha  wrote:
>> 
>>> +1
>>> 
>>> Em sex., 15 de abr. de 2022 às 11:37, Alex The Rocker <
>>> alex.m3...@gmail.com>
>>> escreveu:
>>> 
 Hello,
 
 So far so good:
 - Tested with IBM Semeru Runtimes 17.0.2 (aka OpenJ9) on a service
 running as Docker containers in K8S
 - Tested with a web app using JAX-RS, JAX-WS, JMS, Websockets &
 Servlets on a VM with CentOS 7 with IBM Semeru 11.0.4
 - Tested with a web app using JAX-RS and websockets on a VM with
 RockyLinux 8.5 and IBM Semery 11.0.4
 
 Early next week I have a much broader scope to give my final
 feedback/vote (non binding) on this release
 
 Thanks,
 Alex
 
 Le jeu. 14 avr. 2022 à 17:06, Jean-Louis Monteiro
  a écrit :
> 
> Hi All,
> 
> This is the first attempt at a vote for a release of Apache TomEE
>>> 8.0.11
> 
> I'd like to start with a big thank you and a big applause to Richard.
>>> He
> has been doing a tremendous work on the project and started to roll out
 his
> first release today. Per Apache rules, the release manager needs to be
>>> a
> TomEE PMC, that's why I'm starting this VOTE, but the work has been
>>> done
 by
> Richard, so thank you. Well done.
> 
> Maven Repo:
> 
>>> https://repository.apache.org/content/repositories/orgapachetomee-1200/
> 
> Binaries & Sources:
> 
>>> https://dist.apache.org/repos/dist/dev/tomee/staging-1200/tomee-8.0.11/
> 
> Tags:
> https://github.com/apache/tomee/releases/tag/tomee-project-8.0.11
> 
> Release notes:
> 
 
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12351352
> 
> Here are the releases notes
> Bug
> 
>   - [TOMEE-3840 ] -
>   TomEE WebProfile 8.0.9 does not start with security enabled
>   - [TOMEE-3848 ] -
>   Apache TomEE 8.0.6 onwards is packaged with quartz-2.2.4.jar
>   - [TOMEE-3860 ] -
>   Upgrade jackson-databind for CVE-2020-36518
>   - [TOMEE-3871 ] -
>   TomEE Plume is missing BatchEE / JCS Cache
>   - [TOMEE-3876 ] -
 BOM
>   generation corrupted under windows (slash problems)
>   - [TOMEE-3889 ] -
>   Invalid ObjectName for MDB listening to wildcard destination
>   - [TOMEE-3892 ] -
>   TomEE Maven Plugin does not allow to override default "-ea" in
 RemoteServer
> 
> Improvement
> 
>   - [TOMEE-3842 ] -
>   GitHub Actions fails for PullRequest Builds due to BOM auto
>>> generation
>   - [TOMEE-3851 ] -
>   Replace Google Analytics with ASF Matomo
>   - [TOMEE-3859 ] -
>   Update tomee.xml file so it refers to the right location
> 
> Task
> 
>   - [TOMEE-3852 ] -
>   Review the website in regard to external embedding of resources (JS,
 Fonts,
>   CSS)
>   - [TOMEE-3853 ] -
 Link
>   ASF Privacy Policy from TomEE Website
> 
> Dependency upgrade
> 
>   - [TOMEE-3841 ] -
>   Upgrade SLF4J to 1.7.36
>   - [TOMEE-3845 ] -
>   Upgrade Tomcat to 9.0.59
>   - [TOMEE-3855 ] -
>   Upgrade Tomcat to 9.0.60
>   - [TOMEE-3856 ] -
>   Upgrade to jackson 2.13.2
>   - [TOMEE-3858 ] -
>   Upgrade OpenJPA to 3.2.2
>   - [TOMEE-3872 ] -
>   Update Hibernate Integration to 5.6.7
>   - [TOMEE-3886 ] -
>   Upgrade tomcat to 9.0.62
>   - [TOMEE-3893 ] -
>   Upgrade to jackson 2.13.2.2
> 
> Documentation
> 
>   - [TOMEE-3814 ] -
>   Commented 

Re: [VOTE] Apache TomEE 8.0.10

[Mark Struberg]

+1 hopefully on the right end this time.

LieGrue,
strub


> Am 18.02.2022 um 12:11 schrieb Wiesner, Martin 
> :
> 
> Hi All,
> 
> +1
> 
> Conducted my tests as usual with J17 / MacOS.
> 
> Best
> Martin
> --
> https://twitter.com/mawiesne
> 
> 
> Am 15.02.2022 um 15:18 schrieb Jonathan Gallimore 
> mailto:jonathan.gallim...@gmail.com>>:
> 
> +1
> 
> Jon
> 
> On Fri, Feb 11, 2022 at 8:54 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
> 
> Hi All,
> 
> This is a first attempt at a vote for a release of Apache TomEE 8.0.10
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1193/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging_1193-TomEE-8.0.10/
> 
> Tags:
> https://github.com/apache/tomee/releases/tag/tomee-project-8.0.10
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12350706
> 
> Here are the releases notes
> Sub-task
> 
>  - [TOMEE-2117 ] -
>  Rework ProcessObserverMethod integration
>  - [TOMEE-2289 ] -
>  MicroProfile OpenAPI Example
>  - [TOMEE-2349 ] -
>  Ensure each module can generate javadoc jars on release
>  - [TOMEE-2350 ] -
>  Create a list of existing Javadoc using html
>  - [TOMEE-2351 ] -
>  MicroProfile OpenTracing Example for Distributed Microservices
>  - [TOMEE-2358 ] -
>  MicroProfile JWT rest-mp-jwt-claim Example
> 
> Bug
> 
>  - [TOMEE-2169 ] -
>  Interceptor Bean injection does not work for EJBs
>  - [TOMEE-2270 ] -
>  Java11: Unable to initialize agent with embedded-maven-plugin
>  - [TOMEE-2403 ] -
>  AutoConnectionTrackerTest fails randomly
>  - [TOMEE-2427 ] -
>  Align text above the pictures
>  - [TOMEE-2800 ] -
>  Issue : Unable to run EJB test cases for upgradation in current project
>  with Java 1.8 and WebLogic version 12.2.1.4 along with
> openejb.cxf.version
>  7.0.1 / openejb.cxf.version 8 jar.
>  - [TOMEE-2941 ] -
>  Regression: A connection factory created with TransactionSupport of
> "none"
>  only sending message when transaction completes
>  - [TOMEE-3777 ] -
>  
>  org.apache.openjpa.persistence.ArgumentException: The persistence
> provider
>  is attempting to use properties in the persistence.xml file to resolve
> the
>  data source ...
>  - [TOMEE-3816 ] -
>  Return "this" on stateless EJB method looses container transaction
>  management
>  - [TOMEE-3823 ] -
>  TomEE and Java 17 compatibility issue with Windows Service Tooling
>  - [TOMEE-3825 ] -
>  TomEE Maven Plugin does not wait for container startup, if
> "checkStarted"
>  is set to true
>  - [TOMEE-3832 ] -
>  JAX-RS TomEEJsonbProvider not registered in tomee-embedded-maven-plugin
>  when MicroProfile is present
> 
> New Feature
> 
>  - [TOMEE-2306 ] - New
>  Java EE Schemas for Java EE Deployment Descriptors
>  - [TOMEE-2584 ] -
> Java
>  11 compliancy
>  - [TOMEE-2706 ] - New
>  TomEE Embedded Bootstrap
> 
> Improvement
> 
>  - [TOMEE-1618 ] -
>  Replace three register maps in Container in favour of one
>  - [TOMEE-2277 ] -
>  Java11: module name for TomEE
>  - [TOMEE-2425 ] -
>  Generate TomEE-Cluster.html page
>  - [TOMEE-2519 ] - MP
>  JWT Logging Improvements
>  - [TOMEE-2847 ] -
>  Patch key `jakarta` namespace support
>  - [TOMEE-2949 ] -
>  Match TomEE tar and zip file syntax with extracted folder
>  - [TOMEE-3826 ] - Add
>  exclusion list maven config for patch plugin to preserve jars with
> signature
> 
> Wish
> 
>  - [TOMEE-2347 ] - Use
>  Asciidoc for all Javadoc
> 
> Task
> 
>  - [TOMEE-2285 ] -
>  Microprofile 

Re: [VOTE] Apache TomEE 8.0.9

[Mark Struberg]

sorry folks, my macbook mail  has a serious glitch in it's thread view. want to 
ship my +1 for the 8.0.10 vote since yesterday and keep failing :(
will reply to the correct mail after a reset of my mailbox 

> Am 18.02.2022 um 15:03 schrieb Mark Struberg :
> 
> +1 (binding)
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 23.12.2021 um 13:24 schrieb Jean-Louis Monteiro 
>> :
>> 
>> Hi All,
>> 
>> This is a first attempt at a vote for a release of Apache TomEE 8.0.8.
>> 
>> Maven Repo:
>> https://repository.apache.org/content/repositories/orgapachetomee-1188
>> 
>> Binaries & Source:
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1188_tomee-8.0.9/
>> 
>> Tags:
>> https://github.com/apache/tomee/tree/tomee-project-8.0.9
>> 
>> Release notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12350574
>> 
>> Here are the releases notes
>> Sub-task
>> 
>>  - [TOMEE-3596 <https://issues.apache.org/jira/browse/TOMEE-3596>] -
>>  Update example 'injection-of-connectionfactory' to use Server/API Bom
>>  - [TOMEE-3652 <https://issues.apache.org/jira/browse/TOMEE-3652>] -
>>  Update example 'quartz-app' to use Server/API Bom
>>  - [TOMEE-3682 <https://issues.apache.org/jira/browse/TOMEE-3682>] -
>>  Update example 'simple-mdb-and-cdi' to use Server/API Bom
>>  - [TOMEE-3683 <https://issues.apache.org/jira/browse/TOMEE-3683>] -
>>  Update example 'simple-mdb-with-descriptor' to use Server/API Bom
>>  - [TOMEE-3684 <https://issues.apache.org/jira/browse/TOMEE-3684>] -
>>  Update example 'simple-mdb' to use Server/API Bom
>> 
>> Bug
>> 
>>  - [TOMEE-3791 <https://issues.apache.org/jira/browse/TOMEE-3791>] - Ajax
>>  JSF not provided in 8.0.8 builds
>>  - [TOMEE-3792 <https://issues.apache.org/jira/browse/TOMEE-3792>] -
>>  Missing Public key in KEYS for Tomee
>>  - [TOMEE-3794 <https://issues.apache.org/jira/browse/TOMEE-3794>] -
>>  javaVersion() in org.apache.openejb.arquillian.common.Setup breaks for
>>  version strings with length lower than 3
>>  - [TOMEE-3795 <https://issues.apache.org/jira/browse/TOMEE-3795>] -
>>  Proxy class definition does not work in Java 17+
>>  - [TOMEE-3796 <https://issues.apache.org/jira/browse/TOMEE-3796>] -
>>  myfaces-api-2.3.9.jar is modified.
>>  - [TOMEE-3798 <https://issues.apache.org/jira/browse/TOMEE-3798>] -
>>  TomEE (8.0.8) is affected by CVE-2021-40690 vulnerability
>>  - [TOMEE-3803 <https://issues.apache.org/jira/browse/TOMEE-3803>] -
>>  RES_NOT_FOUND in Plume 8.0.8 JSF 2.3
>>  - [TOMEE-3818 <https://issues.apache.org/jira/browse/TOMEE-3818>] -
>>  Double url-decode of form parameters
>> 
>> Improvement
>> 
>>  - [TOMEE-3000 <https://issues.apache.org/jira/browse/TOMEE-3000>] - Run
>>  BOM Generation in every build
>>  - [TOMEE-3805 <https://issues.apache.org/jira/browse/TOMEE-3805>] -
>>  Website improvements - Release notes & CVEs
>>  - [TOMEE-3815 <https://issues.apache.org/jira/browse/TOMEE-3815>] -
>>  Additional logging in CdiService
>> 
>> Wish
>> 
>>  - [TOMEE-3797 <https://issues.apache.org/jira/browse/TOMEE-3797>] -
>>  Misassignment webapp->host hard to detect
>> 
>> Dependency upgrade
>> 
>>  - [TOMEE-3789 <https://issues.apache.org/jira/browse/TOMEE-3789>] -
>>  Upgrade ActiveMQ to 5.16.3
>>  - [TOMEE-3793 <https://issues.apache.org/jira/browse/TOMEE-3793>] -
>>  Upgrade xbean to 4.20
>>  - [TOMEE-3799 <https://issues.apache.org/jira/browse/TOMEE-3799>] -
>>  Upgrade Tomcat to 9.0.53
>>  - [TOMEE-3806 <https://issues.apache.org/jira/browse/TOMEE-3806>] -
>>  Upgrade Tomcat to 9.0.54
>>  - [TOMEE-3809 <https://issues.apache.org/jira/browse/TOMEE-3809>] -
>>  Upgrade to Johnzon 1.2.15
>>  - [TOMEE-3810 <https://issues.apache.org/jira/browse/TOMEE-3810>] -
>>  Upgrade Geronimo Java Mail 1.6 to 1.0.1
>>  - [TOMEE-3817 <https://issues.apache.org/jira/browse/TOMEE-3817>] -
>>  Upgrade Tomcat to 9.0.55
>>  - [TOMEE-3819 <https://issues.apache.org/jira/browse/TOMEE-3819>] -
>>  Aapche Tomcat 9.0.56
>>  - [TOMEE-3820 <https://issues.apache.org/jira/browse/TOMEE-3820>] -
>>  Apache OpenWebBeans 2.0.24
>>  - [TOMEE-3821 <https://issues.apache.org/jira/browse/TOMEE-3821>] -
>>  Apache OpenWebBeans 2.0.25
>> 
>> Documentation
>> 
>>  - [TOMEE-3811 <https://issues.apache.org/jira/browse/TOMEE-3811>] -
>>  Provide E-Mail Example with Velocity
>> 
>> 
>> (Developers - please review and adjust your tickets if necessary!)
>> 
>> Please VOTE:
>> 
>> [+1] Yes, release it
>> [+0] Not fussed
>> [-1] Don't release, there's a showstopper (please specify what the
>> showstopper is)
>> 
>> Vote will be open for 72 hours.
>> 
>> Thanks
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
> 

Re: [VOTE] Apache TomEE 8.0.9

[Mark Struberg]

+1 (binding)

txs and LieGrue,
strub


> Am 23.12.2021 um 13:24 schrieb Jean-Louis Monteiro :
> 
> Hi All,
> 
> This is a first attempt at a vote for a release of Apache TomEE 8.0.8.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1188
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1188_tomee-8.0.9/
> 
> Tags:
> https://github.com/apache/tomee/tree/tomee-project-8.0.9
> 
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12350574
> 
> Here are the releases notes
> Sub-task
> 
>   - [TOMEE-3596 ] -
>   Update example 'injection-of-connectionfactory' to use Server/API Bom
>   - [TOMEE-3652 ] -
>   Update example 'quartz-app' to use Server/API Bom
>   - [TOMEE-3682 ] -
>   Update example 'simple-mdb-and-cdi' to use Server/API Bom
>   - [TOMEE-3683 ] -
>   Update example 'simple-mdb-with-descriptor' to use Server/API Bom
>   - [TOMEE-3684 ] -
>   Update example 'simple-mdb' to use Server/API Bom
> 
> Bug
> 
>   - [TOMEE-3791 ] - Ajax
>   JSF not provided in 8.0.8 builds
>   - [TOMEE-3792 ] -
>   Missing Public key in KEYS for Tomee
>   - [TOMEE-3794 ] -
>   javaVersion() in org.apache.openejb.arquillian.common.Setup breaks for
>   version strings with length lower than 3
>   - [TOMEE-3795 ] -
>   Proxy class definition does not work in Java 17+
>   - [TOMEE-3796 ] -
>   myfaces-api-2.3.9.jar is modified.
>   - [TOMEE-3798 ] -
>   TomEE (8.0.8) is affected by CVE-2021-40690 vulnerability
>   - [TOMEE-3803 ] -
>   RES_NOT_FOUND in Plume 8.0.8 JSF 2.3
>   - [TOMEE-3818 ] -
>   Double url-decode of form parameters
> 
> Improvement
> 
>   - [TOMEE-3000 ] - Run
>   BOM Generation in every build
>   - [TOMEE-3805 ] -
>   Website improvements - Release notes & CVEs
>   - [TOMEE-3815 ] -
>   Additional logging in CdiService
> 
> Wish
> 
>   - [TOMEE-3797 ] -
>   Misassignment webapp->host hard to detect
> 
> Dependency upgrade
> 
>   - [TOMEE-3789 ] -
>   Upgrade ActiveMQ to 5.16.3
>   - [TOMEE-3793 ] -
>   Upgrade xbean to 4.20
>   - [TOMEE-3799 ] -
>   Upgrade Tomcat to 9.0.53
>   - [TOMEE-3806 ] -
>   Upgrade Tomcat to 9.0.54
>   - [TOMEE-3809 ] -
>   Upgrade to Johnzon 1.2.15
>   - [TOMEE-3810 ] -
>   Upgrade Geronimo Java Mail 1.6 to 1.0.1
>   - [TOMEE-3817 ] -
>   Upgrade Tomcat to 9.0.55
>   - [TOMEE-3819 ] -
>   Aapche Tomcat 9.0.56
>   - [TOMEE-3820 ] -
>   Apache OpenWebBeans 2.0.24
>   - [TOMEE-3821 ] -
>   Apache OpenWebBeans 2.0.25
> 
> Documentation
> 
>   - [TOMEE-3811 ] -
>   Provide E-Mail Example with Velocity
> 
> 
> (Developers - please review and adjust your tickets if necessary!)
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours.
> 
> Thanks
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: [VOTE] Apache TomEE 8.0.9

[Mark Struberg]

+1 with the new dist.

txs and LieGrue,
strub


> Am 23.12.2021 um 13:24 schrieb Jean-Louis Monteiro :
> 
> Hi All,
> 
> This is a first attempt at a vote for a release of Apache TomEE 8.0.8.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1188
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1188_tomee-8.0.9/
> 
> Tags:
> https://github.com/apache/tomee/tree/tomee-project-8.0.9
> 
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12350574
> 
> Here are the releases notes
> Sub-task
> 
>   - [TOMEE-3596 ] -
>   Update example 'injection-of-connectionfactory' to use Server/API Bom
>   - [TOMEE-3652 ] -
>   Update example 'quartz-app' to use Server/API Bom
>   - [TOMEE-3682 ] -
>   Update example 'simple-mdb-and-cdi' to use Server/API Bom
>   - [TOMEE-3683 ] -
>   Update example 'simple-mdb-with-descriptor' to use Server/API Bom
>   - [TOMEE-3684 ] -
>   Update example 'simple-mdb' to use Server/API Bom
> 
> Bug
> 
>   - [TOMEE-3791 ] - Ajax
>   JSF not provided in 8.0.8 builds
>   - [TOMEE-3792 ] -
>   Missing Public key in KEYS for Tomee
>   - [TOMEE-3794 ] -
>   javaVersion() in org.apache.openejb.arquillian.common.Setup breaks for
>   version strings with length lower than 3
>   - [TOMEE-3795 ] -
>   Proxy class definition does not work in Java 17+
>   - [TOMEE-3796 ] -
>   myfaces-api-2.3.9.jar is modified.
>   - [TOMEE-3798 ] -
>   TomEE (8.0.8) is affected by CVE-2021-40690 vulnerability
>   - [TOMEE-3803 ] -
>   RES_NOT_FOUND in Plume 8.0.8 JSF 2.3
>   - [TOMEE-3818 ] -
>   Double url-decode of form parameters
> 
> Improvement
> 
>   - [TOMEE-3000 ] - Run
>   BOM Generation in every build
>   - [TOMEE-3805 ] -
>   Website improvements - Release notes & CVEs
>   - [TOMEE-3815 ] -
>   Additional logging in CdiService
> 
> Wish
> 
>   - [TOMEE-3797 ] -
>   Misassignment webapp->host hard to detect
> 
> Dependency upgrade
> 
>   - [TOMEE-3789 ] -
>   Upgrade ActiveMQ to 5.16.3
>   - [TOMEE-3793 ] -
>   Upgrade xbean to 4.20
>   - [TOMEE-3799 ] -
>   Upgrade Tomcat to 9.0.53
>   - [TOMEE-3806 ] -
>   Upgrade Tomcat to 9.0.54
>   - [TOMEE-3809 ] -
>   Upgrade to Johnzon 1.2.15
>   - [TOMEE-3810 ] -
>   Upgrade Geronimo Java Mail 1.6 to 1.0.1
>   - [TOMEE-3817 ] -
>   Upgrade Tomcat to 9.0.55
>   - [TOMEE-3819 ] -
>   Aapche Tomcat 9.0.56
>   - [TOMEE-3820 ] -
>   Apache OpenWebBeans 2.0.24
>   - [TOMEE-3821 ] -
>   Apache OpenWebBeans 2.0.25
> 
> Documentation
> 
>   - [TOMEE-3811 ] -
>   Provide E-Mail Example with Velocity
> 
> 
> (Developers - please review and adjust your tickets if necessary!)
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours.
> 
> Thanks
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: [VOTE] Apache TomEE 8.0.8

[Mark Struberg]

+1

txs and LieGrue,
strub


> Am 01.09.2021 um 15:49 schrieb Jean-Louis Monteiro :
> 
> Hi All,
> 
> This is a first attempt at a vote for a release of Apache TomEE 8.0.8.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1186
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1186/
> 
> Tags:
> https://github.com/apache/tomee/tree/tomee-project-8.0.8
> 
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350177=Html=12312320
> 
> Here is an adoc generated version (Thanks Richard)
> 
>> = Apache TomEE 8.0.8 Release Notes
>> :index-group: Release Notes
>> :jbake-type: page
>> :jbake-status: published
>> == Dependency upgrade
>> [.compact]
>> - link:https://issues.apache.org/jira/browse/TOMEE-2990[TOMEE-2990]
>> BatchEE 0.6
>> - link:https://issues.apache.org/jira/browse/TOMEE-3750[TOMEE-3750]
>> BatchEE 1.0.0
>> - link:https://issues.apache.org/jira/browse/TOMEE-2987[TOMEE-2987] CXF
>> 3.4.3
>> - link:https://issues.apache.org/jira/browse/TOMEE-3756[TOMEE-3756]
>> HSQLDB 2.3.4
>> - link:https://issues.apache.org/jira/browse/TOMEE-3772[TOMEE-3772]
>> JUnit 4.13.2
>> - link:https://issues.apache.org/jira/browse/TOMEE-3734[TOMEE-3734]
>> Johnzon 1.2.11
>> - link:https://issues.apache.org/jira/browse/TOMEE-3755[TOMEE-3755]
>> Johnzon 1.2.13
>> - link:https://issues.apache.org/jira/browse/TOMEE-3770[TOMEE-3770]
>> Johnzon 1.2.14
>> - link:https://issues.apache.org/jira/browse/TOMEE-3732[TOMEE-3732]
>> MyFaces 2.3.9
>> - link:https://issues.apache.org/jira/browse/TOMEE-3753[TOMEE-3753]
>> OpenJPA 3.2.0
>> - link:https://issues.apache.org/jira/browse/TOMEE-2997[TOMEE-2997]
>> OpenSAML V3.4.6
>> - link:https://issues.apache.org/jira/browse/TOMEE-2809[TOMEE-2809]
>> OpenWebBeans 2.0.22
>> - link:https://issues.apache.org/jira/browse/TOMEE-2998[TOMEE-2998]
>> Tomcat 9.0.45
>> - link:https://issues.apache.org/jira/browse/TOMEE-3760[TOMEE-3760]
>> Tomcat 9.0.48
>> - link:https://issues.apache.org/jira/browse/TOMEE-3773[TOMEE-3773]
>> Tomcat 9.0.50
>> - link:https://issues.apache.org/jira/browse/TOMEE-3787[TOMEE-3787]
>> Tomcat 9.0.52
>> - link:https://issues.apache.org/jira/browse/TOMEE-2939[TOMEE-2939]
>> bcprov-jdk15on 1.67
>> - link:https://issues.apache.org/jira/browse/TOMEE-3765[TOMEE-3765]
>> bountycastle 1.69
>> - link:https://issues.apache.org/jira/browse/TOMEE-3764[TOMEE-3764]
>> commons-dbcp 2.3.0
>> - link:https://issues.apache.org/jira/browse/TOMEE-3759[TOMEE-3759]
>> commons-io 2.10.0
>> - link:https://issues.apache.org/jira/browse/TOMEE-2972[TOMEE-2972]
>> latest OWB version run on Java16
>> - link:https://issues.apache.org/jira/browse/TOMEE-2988[TOMEE-2988]
>> xbean 4.18+ (Java 16 support)
>> == New Feature
>> [.compact]
>> - link:https://issues.apache.org/jira/browse/TOMEE-3730[TOMEE-3730] Add
>> JSONP and JSONB Providers JAX-RS Client
>> - link:https://issues.apache.org/jira/browse/TOMEE-2365[TOMEE-2365]
>> Implement Java EE Security API from EE 8
>> - link:https://issues.apache.org/jira/browse/TOMEE-2966[TOMEE-2966]
>> Provide a pure JUnit5 OpenEJB Extension
>> - link:https://issues.apache.org/jira/browse/TOMEE-2977[TOMEE-2977]
>> Provide a ApplicationComposer JUnit 5 Extension
>> - link:https://issues.apache.org/jira/browse/TOMEE-2993[TOMEE-2993] API
>> pom for each TomEE distribution
>> == Bug
>> [.compact]
>> - link:https://issues.apache.org/jira/browse/TOMEE-3774[TOMEE-3774]
>> Problems with master branch in Windows 10
>> - link:https://issues.apache.org/jira/browse/TOMEE-3731[TOMEE-3731]
>> Remove non-compliant JAX-RS Provider sorting
>> - link:https://issues.apache.org/jira/browse/TOMEE-3768[TOMEE-3768]
>> TomEE plus is affected by CVE-CVE-2021-30468 vulnerability related to
>> Apache CXF
>> - link:https://issues.apache.org/jira/browse/TOMEE-2125[TOMEE-2125]
>> Datasource config: MaxWait, timeBetweenEvictionRunsMillis and
>> MinEvictableIdleTimeMillis are ignored
>> - link:https://issues.apache.org/jira/browse/TOMEE-3727[TOMEE-3727]
>> Ensure java.io.File is not seen as a JSONB serializable type
>> - link:https://issues.apache.org/jira/browse/TOMEE-3728[TOMEE-3728]
>> Ensure java.io.Reader is not seen as a JSONB serializable type
>> - link:https://issues.apache.org/jira/browse/TOMEE-3729[TOMEE-3729] Do
>> not scan classpath for @Provider when there is a JAX-RS Application
>> - link:https://issues.apache.org/jira/browse/TOMEE-2968[TOMEE-2968]
>> Postgres connection error when a password contains "}"
>> - link:https://issues.apache.org/jira/browse/TOMEE-3740[TOMEE-3740] Fix
>> Test Failures in "openejb-core" introduced during TCK work
>> - link:https://issues.apache.org/jira/browse/TOMEE-3743[TOMEE-3743]
>> TomEEJsonbProvider not registered anymore as of TomEE 8.0.7? Causes failing
>> REST-services.
>> - link:https://issues.apache.org/jira/browse/TOMEE-3739[TOMEE-3739] Fix
>> JAX-RS landscape / regressions introduced during TCK Work
>> - link:https://issues.apache.org/jira/browse/TOMEE-3752[TOMEE-3752]

Re: [VOTE] Release Apache TomEE 8.0.7 and 9.0.0-M7

[Mark Struberg]

+1

LieGrue,
strub


> Am 03.05.2021 um 17:01 schrieb David Blevins :
> 
> Ok, folks,
> 
> Here we go.  Again, bear in mind we need these binaries for the Jakarta EE 
> 9.1 release ballot today.  Any issues and we can roll a Apache TomEE 8.0.8 
> and Apache TomEE 9.0.0-M8 asap.  I think we should plan on doing that anyway, 
> so feel free to say call it straight out when reporting "I found x issue we 
> should fix in 8.0.8"
> 
> 
> TomEE Patch Plugin v0.5
> https://repository.apache.org/content/repositories/orgapachetomee-1182/
> 
> Apache TomEE 8.0.7
> https://repository.apache.org/content/repositories/orgapachetomee-1183/
> 
> Apache TomEE 9.0.0-M7
> https://repository.apache.org/content/repositories/orgapachetomee-1184/
> 
> This vote will be open for 72 hours.  Please vote +1, 0, -1.  When voting -1, 
> please state the reason.
> 
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 

Re: Potential release vote for 8.0.7 and 9.0.0-M7

[Mark Struberg]

 +1
LieGrue,strub

On Monday, 3 May 2021, 11:30:50 CEST, Alex The Rocker 
 wrote:  
 
 +1 (non-binding) for this 8.0.7 release, I'll test it as soon as link
to binaries is available !

Alex

Le lun. 3 mai 2021 à 10:24, David Blevins  a écrit :
>
> Dear Community.
>
> The time has come :)
  

Re: [DISCUSS] Retiring the "tomee" webapps from TomEE 8

[Mark Struberg]

yup, the webapp was always kind of a a half baked solution imo.
When you just need CDI, then one can use OWB natively in the app on an 
unmodified Tomcat.
If one needs the fully blown EE features, then TomEE is a perfect fit and well 
tested.
I think the complexity added with the web app dropin is not justified by the 
benefits.

LieGrue,
strub


> Am 18.04.2021 um 01:06 schrieb David Blevins :
> 
> Digging up this old discussion thread on removing the tomee-foo-webapp 
> modules.
> 
> At the moment our TCK progress is essentially halted due to issues created by 
> the complexity of these webapps and how we build the server.
> 
> The crux of the issue is that we're getting duplicate jars in our war files 
> which causes the TCK runs to encounter startup errors and fail before any 
> tests are run.  Here's an example:
> 
>$ curl -O 
> https://repository.apache.org/content/groups/snapshots/org/apache/tomee/apache-tomee/8.0.7-SNAPSHOT/apache-tomee-8.0.7-20210417.052409-158-plume.zip
>  
> 
>$ unzip -l apache-tomee-8.0.7-20210417.052409-158-plume.zip | grep cxf-core
>  1431799  04-17-2021 05:23   
> apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-core-3.5.0-SNAPSHOT.jar
>  1431799  04-17-2021 05:23   
> apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-core-3.5.0-20210417.035622-203.jar
> 
> There are duplicates of basically any SNAPSHOT dependency.  Sometimes 
> there'll be duplicates even of openejb-core.  I've checked the sha256 hashes 
> on the duplicate jars like the above and in most cases they are different, 
> meaning we're getting two different builds of the SNAPSHOT showing up.
> 
> When we go to run the TCK we encounter issues as there are parts of the TCK 
> that are standalone (no server) and we need to construct a classpath of 
> specific jars.  That will fail like so:
> 
>Caused by: java.lang.Exception: Found more than one file to be included 
> into path; dir=target/apache-tomee-plume-8.0.7-SNAPSHOT/lib, 
> includes=cxf-rt-rs-client-*.jar, excludes=null; found: 
> /Users/dblevins/work/apache/tomee-tck/target/apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-rt-rs-client-3.5.0-20210417.035728-202.jar:/Users/dblevins/work/apache/tomee-tck/target/apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-rt-rs-client-3.5.0-SNAPSHOT.jar
>at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native 
> Method)
>at sun.reflect.NativeConstructorAccessorImpl.newInstance 
> (NativeConstructorAccessorImpl.java:62)
>at sun.reflect.DelegatingConstructorAccessorImpl.newInstance 
> (DelegatingConstructorAccessorImpl.java:45)
>at java.lang.reflect.Constructor.newInstance (Constructor.java:423)
>at org.codehaus.groovy.reflection.CachedConstructor.invoke 
> (CachedConstructor.java:77)
>at 
> org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke 
> (CachedConstructor.java:71)
>at 
> org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor
>  (ConstructorSite.java:84)
>at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor 
> (CallSiteArray.java:52)
>at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor 
> (AbstractCallSite.java:192)
>at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor 
> (AbstractCallSite.java:200)
>at openejb.tck.util.PathBuilder.append (PathBuilder.groovy:89)
> 
> What's worse is that this issue seems somewhat random.  Sometimes you get 
> away with no duplicate jars.
> 
> Additionally, if you need to rebuild the server binary (say plume) to test a 
> one line change it takes quite a while because we need to build several 
> binaries first.  The tomee/tomee-webapp/ module builds a war that feeds into 
> the tomee/tomee-plume-webapp/ module which feeds into tomee/apache-tomee/ 
> which produces all the actual zips, tars.  Here's how big the target 
> directories are for those three modules after a build:
> 
>$ du -sh tomee/tomee-webapp/target/ tomee/tomee-plume-webapp/target/ 
> tomee/apache-tomee/target/
> 37M   tomee/tomee-webapp/target/
>206M   tomee/tomee-plume-webapp/target/
>1.1G   tomee/apache-tomee/target/
> 
> Overall we produce 3.3GB in our build.  To get your one-line change up to the 
> internet for a TCK run, you need to up load an insane amount of binaries.  On 
> an EC2 box with extremely good internet connection it takes about 2 hours to 
> do a snapshot deploy.
> 
> A snapshot that is broken and unusable.
> 
> I think I can fix our duplicate jar issue and get things working, but FYI 
> that doesn't really fix our build.  We'll need to do more serious work to get 
> that in shape.
> 
> 
> -David
> 
> 
>> On May 23, 2019, at 1:28 AM, David Blevins  wrote:
>> 
>> We have a bit of unused legacy with regards to the following webapps:
>> 
>>   34M tomee-microprofile-webapp-8.0.0-M3.war
>>   58M tomee-plume-webapp-8.0.0-M3.war
>>   51M 

Re: some TomEE 8 work towards Java16 support

[Mark Struberg]

 Hi Vincente!
There have been a few subtle details. Mostly in the area of EAR support. 
OpenEJB uses some internal classes from OWB. And some of those got refactored 
to improve performance to use the NotifiactionManager directly. But this meant 
that some events did not get sent to Observers registered in EAR/lib jars. I've 
fixed that now with introducing a WebappNotificationManager and moved the 
delegation logic of events over from the BeanManager.With that change all the 
TCKs within our main build are green again.
And yes, will also upgrade OpenJPA and release it soon.

But it would be way cool if you could test the current master with your app and 
give some feedback!But let me first update OpenEJB for the latest xbean-asm9 as 
well.
Will ping back when done.
txs and LieGrue,strub

On Tuesday, 2 March 2021, 16:22:44 CET, Vicente Rossello 
 wrote:  
 
 Hi,

I made a PR some time ago with updates in xbean-asm, OWB and CXF to support
jdk 16 (no refactors, just upgrades).  It's working fine with JDK 16 on our
application (excluding openJPA).

The only problem right now is that OpenJPA is using xbean-asm8, but a
snapshot will do as well.

https://github.com/apache/tomee/pull/693
Just in case it helps a bit.

Best regards,
Vicente.

On Tue, Mar 2, 2021 at 8:07 AM Mark Struberg 
wrote:

> hi there!
>
> I'm right now in the middle of some refactoring to update TomEE8 to the
> latest OWB version.
> I also did need to tweak some internals to better deal with eventing for
> EARs.
> It's mostly corner cases like making sure that things like
> ProcessInjectionPoint triggered by InjectionFactory#createInjectionTarget
> also end up in parent EAR libs.
> Right now running the full build with all the TCKs. The CDI TCKs do all
> pass again already.
>
> Will keep you updated...
>
> LieGrue,
> strub
>
>
  

some TomEE 8 work towards Java16 support

[Mark Struberg]

hi there!

I'm right now in the middle of some refactoring to update TomEE8 to the latest 
OWB version.
I also did need to tweak some internals to better deal with eventing for EARs.
It's mostly corner cases like making sure that things like 
ProcessInjectionPoint triggered by InjectionFactory#createInjectionTarget also 
end up in parent EAR libs.
Right now running the full build with all the TCKs. The CDI TCKs do all pass 
again already.

Will keep you updated...

LieGrue,
strub

Re: [VOTE] Release Apache TomEE 8.0.6

[Mark Struberg]

+1

txs and LieGrue,
strub


> Am 14.01.2021 um 17:05 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> This is a first attempt at a vote for a release of Apache TomEE 8.0.6.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1179
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1179/tomee-8.0.6/
> 
> Source code:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1179/tomee-8.0.6/tomee-project-8.0.6-source-release.zip
> 
> Tags:
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-8.0.6
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12349403
> 
> (Developers - please review and adjust your tickets if necessary!)
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours.
> 
> Thanks
> 
> Jon

Re: [VOTE] Apache TomEE javaee-api-8.0.5

[Mark Struberg]

Hi!

The CDI api glitch is in AnnotationLiteral#hashCode. A nasty copy error 
which Arne Limburg from the OWB team discovered and fixed.

https://issues.apache.org/jira/browse/GERONIMO-6784 



LieGrue,
strub


> Am 10.11.2020 um 15:04 schrieb exabrial12 :
> 
> What's the "hasCode glitch in the CDI-2.0 API"?
> 
> Also, MyFaces 2.3.7 just released, not sure if that's available to get in :)
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: [VOTE] Apache TomEE javaee-api-8.0.5

[Mark Struberg]

uhhh, didn't see this one. Not sure it already got fixed. Can you please verify?

Txs and LieGrue,
strub


> Am 10.11.2020 um 15:38 schrieb Alex The Rocker :
> 
> Hello,
> 
> Is this update fixing https://issues.apache.org/jira/browse/TOMEE-2618 
> <https://issues.apache.org/jira/browse/TOMEE-2618> ?
> 
> Alex
> 
> Le lun. 19 oct. 2020 à 22:30, Mark Struberg
> mailto:strub...@yahoo.de.invalid>> a écrit :
>> 
>> Hi ladies!
>> 
>> I'd like to call a VOTE on Apache TomEE javaee-api-8.0.5.
>> 
>> This mostly contains updates to newer bugfix releases of some spec jars. 
>> Including an important hasCode glitch in the CDI-2.0 API.
>> 
>> The staging repo is:
>> https://repository.apache.org/content/repositories/orgapachetomee-1176/
>> 
>> 
>> The source zip can be found at
>> https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/
>>  
>> <https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/><https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/
>>  
>> <https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/>>
>> sha1 is f6e91c15a8f2e08d2c2ad0f42b03df386287992c
>> 
>> Please VOTE
>> 
>> [+1] go ship it
>> [+0] meh, don't care
>> [-1] stop, there is a ${showstopper}
>> 
>> The VOTE is open for 72h
>> 
>> Here is my own one for the start.
>> +1 (binding)
>> 
>> txs and LieGrue,
>> strub

Re: [VOTE] [RESULT] Apache TomEE javaee-api-8.0.5

[Mark Struberg]

hi!

The VOTE did pass with the following:

+1: Jean-Louis, Jon, Daniel Cunha, Cesar, DavidB, Daniel Dos Santos, Richard, 
Mark

No -1 nor 0.

I'll go on with the release tasks and also update TomEE8.

LieGrue,
strub

> Am 19.10.2020 um 22:30 schrieb Mark Struberg :
> 
> Hi ladies!
> 
> I'd like to call a VOTE on Apache TomEE javaee-api-8.0.5.
> 
> This mostly contains updates to newer bugfix releases of some spec jars. 
> Including an important hasCode glitch in the CDI-2.0 API.
> 
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomee-1176/
> 
> 
> The source zip can be found at
> https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/
>  
> <https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/>
> sha1 is f6e91c15a8f2e08d2c2ad0f42b03df386287992c
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> Here is my own one for the start.
> +1 (binding)
> 
> txs and LieGrue,
> strub

Re: [VOTE] Apache TomEE javaee-api-8.0.5

[Mark Struberg]

hehe yes, 'generic femininum' ;)

LieGrue,
strub

> Am 21.10.2020 um 03:15 schrieb David Blevins :
> 
> +1 for both the release and starting your email with "ladies" :)
> 
> If women have to be constantly read, "hey guys", seems only fair we should 
> experience that from time to time :)
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
>> On Oct 19, 2020, at 1:30 PM, Mark Struberg  wrote:
>> 
>> Hi ladies!
>> 
>> I'd like to call a VOTE on Apache TomEE javaee-api-8.0.5.
>> 
>> This mostly contains updates to newer bugfix releases of some spec jars. 
>> Including an important hasCode glitch in the CDI-2.0 API.
>> 
>> The staging repo is:
>> https://repository.apache.org/content/repositories/orgapachetomee-1176/
>> 
>> 
>> The source zip can be found at
>> https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/
>>  
>> <https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/>
>> sha1 is f6e91c15a8f2e08d2c2ad0f42b03df386287992c
>> 
>> Please VOTE
>> 
>> [+1] go ship it
>> [+0] meh, don't care
>> [-1] stop, there is a ${showstopper}
>> 
>> The VOTE is open for 72h
>> 
>> Here is my own one for the start.
>> +1 (binding)
>> 
>> txs and LieGrue,
>> strub
> 

[VOTE] Apache TomEE javaee-api-8.0.5

[Mark Struberg]

Hi ladies!

I'd like to call a VOTE on Apache TomEE javaee-api-8.0.5.

This mostly contains updates to newer bugfix releases of some spec jars. 
Including an important hasCode glitch in the CDI-2.0 API.

The staging repo is:
https://repository.apache.org/content/repositories/orgapachetomee-1176/


The source zip can be found at
https://repository.apache.org/content/repositories/orgapachetomee-1176/org/apache/tomee/javaee-api/8.0-5/
 

sha1 is f6e91c15a8f2e08d2c2ad0f42b03df386287992c

Please VOTE

[+1] go ship it
[+0] meh, don't care
[-1] stop, there is a ${showstopper}

The VOTE is open for 72h

Here is my own one for the start.
+1 (binding)

txs and LieGrue,
strub

Re: [DISCUSS] release javaee-api-8.0.5?

[Mark Struberg]

Hmm, 
we do not have any jakarta dependencies at all, why did we add the EPL license?
This should get removed.

LieGrue,
strub


> Am 18.10.2020 um 23:12 schrieb Mark Struberg :
> 
> hi!
> 
> I've update the javaee-api to the latest releases from geronimo.
> The most important fix is for a hashcode flaw in cdi-2.0.
> 
> If nobody objects, then I'll roll a release tomorrow.
> It is committed and I also did deploy it to the ASF public snapshots 
> repository.
> 
> txs and LieGrue,
> strub
> 

[DISCUSS] release javaee-api-8.0.5?

[Mark Struberg]

hi!

I've update the javaee-api to the latest releases from geronimo.
The most important fix is for a hashcode flaw in cdi-2.0.

If nobody objects, then I'll roll a release tomorrow.
It is committed and I also did deploy it to the ASF public snapshots repository.

txs and LieGrue,
strub

Re: [VOTE] Release Apache TomEE 7.0.9

[Mark Struberg]

+1

LieGrue,
strub


> Am 05.08.2020 um 22:49 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> I am delighted to present a vote for Apache TomEE 7.0.9
> 
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1175/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1175/tomee-7.0.9/
> 
> Source code:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1175/tomee-7.0.9/tomee-project-7.0.9-source-release.zip
> 
> Tags:
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-7.0.9
> 
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12348295
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours.
> 
> Here is my +1.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release TomEE 7.1.4

[Mark Struberg]

+1

LieGrue,
strub


> Am 05.08.2020 um 22:43 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> I am delighted to present a vote for Apache TomEE 7.1.4
> 
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1174/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1174/tomee-7.1.4/
> 
> Source code:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1174/tomee-7.1.4/tomee-project-7.1.4-source-release.zip
> 
> Tags:
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-7.1.4
> 
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12348433
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours.
> 
> Here is my +1.
> 
> Thanks
> 
> Jon

Re: [VOTE] Missing artifact - TomEE 8.0.4

[Mark Struberg]

+1

LieGrue
strub

> Am 11.08.2020 um 10:58 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> We're missing an artifact on our download page for TomEE 8.0.4 Webprofile
> (thanks Richard Zowalla for pointing this out).
> 
> This is already in Maven:
> https://repo1.maven.org/maven2/org/apache/tomee/apache-tomee/8.0.4/, but
> was missed in the staging directory for the vote, and hence is missing from
> the promotion to the website.
> 
> I don't know if a vote is needed to add the missing artifact, but I think
> it covers us well to have one anyway. Here's the reference to the original
> vote:
> 
> https://lists.apache.org/thread.html/r5d6b2fe8998da647fdcf405ab721e6f882d40f271b9a92527257bd45%40%3Cdev.tomee.apache.org%3E
> 
> I've added the missing artifacts to the staging area here:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1173/tomee-8.0.4/
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release TomEE 8.0.4 and 9.0.0-M2

[Mark Struberg]

+1 binding

LieGrue and thanks Jon!
strub


> Am 22.07.2020 um 16:34 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> I am delighted to present a vote for Apache TomEE 9.0.0-M2 and Apache TomEE
> 8.0.4.
> 
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1173/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1173/tomee-8.0.4/
> 
> Source code:
> TomEE 8.0.4:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1173/tomee-8.0.4/tomee-project-8.0.4-source-release.zip
> TomEE Jakarta Conversion for 9.0.0-M2:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1173/tomee-8.0.4/apache-tomee-9.0.0-M2-source-release.zip
> 
> Tags:
> 
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-project-8.0.4
> https://gitbox.apache.org/repos/asf?p=tomee-jakarta.git;a=tag;h=refs/tags/tomee-9.0.0-M2
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12348414
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours.
> 
> Here is my +1.
> 
> Thanks
> 
> Jon

Re: Jakarta EE 9 TCK information (in progress)

[Mark Struberg]

cool, thanks. Much easier as having to build the TCK suit oneself ;)

LieGrue,
strub


> Am 16.06.2020 um 01:34 schrieb David Blevins :
> 
> Got some information from Ed Bratt over Jakarta EE slack.
> 
> I've not dug into any of this, but wanted to pass it along immediately as the 
> situation is fluid.
> 
> Nightly builds of the Jakarta EE 9 TCK are here:
> 
> - 
> http://download.eclipse.org/ee4j/jakartaee-tck/master/nightly/jakartaeetck-9.0.0.zip
> - 
> https://download.eclipse.org/ee4j/jakartaee-tck/master/nightly/jakartaeetckinfo.txt
> 
> Here's the current plan for releasing a Jakarta EE 9.0.0-M1 TCK this week:
> 
> - https://github.com/eclipse-ee4j/jakartaee-tck/issues/328
> 
> Here's the status of GlassFish against the standalone TCKs (not the one 
> above):
> 
> - 
> https://ci.eclipse.org/jakartaee-tck/job/standalonetck-nightly-build-run-master/59/junit-reports-with-handlebars/testSuitesOverview.html
> 
> Here's the status of GlassFish with the overall Jakarta EE 9 TCK (the one 
> above):
> 
> - 
> https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-run-master/43/junit-reports-with-handlebars/testSuitesOverview.html
> 
> I'm going to try to see if I can get anything running on TomEE with the 
> bytecode-modified dist.
> 
> I'm super rusty in this department, so I suspect it will be painful :)  Wish 
> me luck. :)
> 
> 
> -David
> 

Re: [VOTE] Release TomEE 8.0.2

[Mark Struberg]

+1

LieGrue,
strub

> Am 14.05.2020 um 15:27 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a third attempt at releasing of TomEE 8.0.2. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1168
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1168/tomee-8.0.2
> 
> Tag:
> 
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-8.0.2
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12346650
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release TomEE 7.0.8

[Mark Struberg]

+1

LieGrue,
strub

> Am 19.05.2020 um 16:23 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a first attempt at releasing of TomEE 7.0.8. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1170
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1170/tomee-7.0.8
> 
> Tag:
> 
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-7.0.8
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12346649
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release TomEE 7.1.3

[Mark Struberg]

+1

LieGrue,
strub


> Am 19.05.2020 um 16:15 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a first attempt at releasing of TomEE 7.1.3. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1169
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1169/tomee-7.1.3
> 
> Tag:
> 
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-7.1.3
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12347033
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Move javaee-api to Git.

[Mark Struberg]

+1 (binding)

LieGrue,
strub


> Am 29.04.2020 um 23:39 schrieb Cesar Hernandez :
> 
> Hi,
> 
> As a follow up from the `Javax -> Jakarta rename` thread [1]
> I would like to propose moving the existing SVN javaee-api repo [2] to
> Git[3] to enable wider visibility and collaboration either via GitHub or
> gitbox.apache.org.
> 
> I will create the Apache JIRA Infra migration ticket after the vote has
> passed.
> 
> [ ] +1 approve the release move javaee-api repo to Git
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> [1]
> https://lists.apache.org/thread.html/refb945e599cad66d8508a540fa5801fd2b04682424e9e29b4e6dd7b4%40%3Cdev.tomee.apache.org%3E
> [2] https://svn.apache.org/repos/asf/tomee/javaee-api/
> [3] https://gitbox.apache.org/
> -- 
> Atentamente:
> César Hernández.

Re: javax -> jakarta

[Mark Struberg]

FYI: also started a discussion over at geronimo-dev. Ray had some good feedback.

https://lists.apache.org/thread.html/rffa51b77d13a6ab6423ed6cdf531a1483848b6965fe0c67b2263ff48%40%3Cdev.geronimo.apache.org%3E
 
<https://lists.apache.org/thread.html/rffa51b77d13a6ab6423ed6cdf531a1483848b6965fe0c67b2263ff48@%3Cdev.geronimo.apache.org%3E>

LieGrue,
strub



> Am 22.04.2020 um 07:30 schrieb Mark Struberg :
> 
> Hi Cesar!
> 
> EPLv2 is basically LGPL but allows sub-licensing.
> 
> https://www.eclipse.org/legal/epl-2.0/faq.php#h.tokw8l7u084o 
> <https://www.eclipse.org/legal/epl-2.0/faq.php#h.tokw8l7u084o>
> 
> "that means that if you have modified EPL-2.0 licensed source code and you 
> distribute that code or binaries built from that code outside y. our company, 
> you must make the source code available under the EPL-2.0."
> 
> See the license text for the full details:
> https://www.eclipse.org/legal/epl-2.0/ 
> <https://www.eclipse.org/legal/epl-2.0/>
> 
> I'd say that makes not much problems to us, but 
> 
> a.) whenever we package some binary which includes some EPLv2 artifact 
> (tomee.zip) we need to properly attribute this.
> b.) whenever we change or repackage EPLv2 source code (javaee-api) we need to 
> make those parts available.
> 
> b is not tragic for us but all DOWNSTREAM users also need to do it IF they 
> change the source code. 
> 
> Nothing tragic, but we need to comply to it. Probably well worth it. That's 
> why I started the discussion.
> And of course there's the OSGi thingy...
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 21.04.2020 um 17:01 schrieb Cesar Hernandez :
>> 
>> Hi Mark,
>> 
>> I'm didn't notice the licensing aspect you mention on b).
>> What would be the work need it, for example in java-ee-api, to add the
>> reciprocity you are mentioning?
>> Just a license header change?
>> 
>> El dom., 19 abr. 2020 a las 3:34, Mark Struberg (> <mailto:strub...@yahoo.de.invalid>>)
>> escribió:
>> 
>>> Hi folks!
>>> 
>>> While moving over to jakartaee we need to discuss which specs we want to
>>> include in our maven builds.
>>> 
>>> We have a jakarta.* branch for the geronimo specs since a year.
>>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
>>> <http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/> <
>>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
>>> <http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/>>
>>> In fact, this was the first ever attempt whether moving the packages was
>>> possible at all.
>>> 
>>> The other possible option would be to use the now existing official
>>> packages from eclipse.
>>> There are a few issues with those though.
>>> 
>>> a.) they are not OSGi capable. Not a bit deal for most, but there are
>>> projects like karaf, Camel, etc which make use of OSGi.
>>> I have not checked whether Eclipse has plans to add this feature to their
>>> official artifacts. Anyone?
>>> 
>>> b.) The EPLv2 is a weak copyleft license. So it still requires some
>>> reciprocity. ALv2 does not.
>>> https://apache.org/legal/resolved.html <
>>> https://apache.org/legal/resolved.html 
>>> <https://apache.org/legal/resolved.html>>
>>> See section 3 in https://www.eclipse.org/legal/epl-2.0/ 
>>> <https://www.eclipse.org/legal/epl-2.0/>
>>> I think this would be fine as long as we make sure not to modify it. Our
>>> java-ee-api super-jar might be such a case.
>>> 
>>> c.) Software Maintenance
>>> With maintaining our own versions of the specs we can rather quickly test
>>> out new features currently under discussion. This would be harder if we do
>>> not maintain those sources ourselves.
>>> Of course this also has downsides: we _need_ to maintain it and we need to
>>> make sure it finally is binary compatible. Checking signatures and stuff...
>>> 
>>> For the record: Apache Tomcat still maintains all the apis for themselves
>>> as well:
>>> https://github.com/apache/tomcat/tree/master/java/jakarta
>> 
>> 
>> 
>> -- 
>> Atentamente:
>> César Hernández.
> 

Re: javax -> jakarta

[Mark Struberg]

Hi Cesar!

EPLv2 is basically LGPL but allows sub-licensing.

https://www.eclipse.org/legal/epl-2.0/faq.php#h.tokw8l7u084o 
<https://www.eclipse.org/legal/epl-2.0/faq.php#h.tokw8l7u084o>

"that means that if you have modified EPL-2.0 licensed source code and you 
distribute that code or binaries built from that code outside y. our company, 
you must make the source code available under the EPL-2.0."

See the license text for the full details:
https://www.eclipse.org/legal/epl-2.0/ <https://www.eclipse.org/legal/epl-2.0/>

I'd say that makes not much problems to us, but 

a.) whenever we package some binary which includes some EPLv2 artifact 
(tomee.zip) we need to properly attribute this.
b.) whenever we change or repackage EPLv2 source code (javaee-api) we need to 
make those parts available.

b is not tragic for us but all DOWNSTREAM users also need to do it IF they 
change the source code. 

Nothing tragic, but we need to comply to it. Probably well worth it. That's why 
I started the discussion.
And of course there's the OSGi thingy...

LieGrue,
strub



> Am 21.04.2020 um 17:01 schrieb Cesar Hernandez :
> 
> Hi Mark,
> 
> I'm didn't notice the licensing aspect you mention on b).
> What would be the work need it, for example in java-ee-api, to add the
> reciprocity you are mentioning?
> Just a license header change?
> 
> El dom., 19 abr. 2020 a las 3:34, Mark Struberg ( <mailto:strub...@yahoo.de.invalid>>)
> escribió:
> 
>> Hi folks!
>> 
>> While moving over to jakartaee we need to discuss which specs we want to
>> include in our maven builds.
>> 
>> We have a jakarta.* branch for the geronimo specs since a year.
>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
>> <http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/> <
>> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
>> <http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/>>
>> In fact, this was the first ever attempt whether moving the packages was
>> possible at all.
>> 
>> The other possible option would be to use the now existing official
>> packages from eclipse.
>> There are a few issues with those though.
>> 
>> a.) they are not OSGi capable. Not a bit deal for most, but there are
>> projects like karaf, Camel, etc which make use of OSGi.
>> I have not checked whether Eclipse has plans to add this feature to their
>> official artifacts. Anyone?
>> 
>> b.) The EPLv2 is a weak copyleft license. So it still requires some
>> reciprocity. ALv2 does not.
>> https://apache.org/legal/resolved.html <
>> https://apache.org/legal/resolved.html 
>> <https://apache.org/legal/resolved.html>>
>> See section 3 in https://www.eclipse.org/legal/epl-2.0/ 
>> <https://www.eclipse.org/legal/epl-2.0/>
>> I think this would be fine as long as we make sure not to modify it. Our
>> java-ee-api super-jar might be such a case.
>> 
>> c.) Software Maintenance
>> With maintaining our own versions of the specs we can rather quickly test
>> out new features currently under discussion. This would be harder if we do
>> not maintain those sources ourselves.
>> Of course this also has downsides: we _need_ to maintain it and we need to
>> make sure it finally is binary compatible. Checking signatures and stuff...
>> 
>> For the record: Apache Tomcat still maintains all the apis for themselves
>> as well:
>> https://github.com/apache/tomcat/tree/master/java/jakarta
> 
> 
> 
> -- 
> Atentamente:
> César Hernández.

javax -> jakarta

[Mark Struberg]

Hi folks!

While moving over to jakartaee we need to discuss which specs we want to 
include in our maven builds.

We have a jakarta.* branch for the geronimo specs since a year.
http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 

In fact, this was the first ever attempt whether moving the packages was 
possible at all. 

The other possible option would be to use the now existing official packages 
from eclipse. 
There are a few issues with those though.

a.) they are not OSGi capable. Not a bit deal for most, but there are projects 
like karaf, Camel, etc which make use of OSGi.
I have not checked whether Eclipse has plans to add this feature to their 
official artifacts. Anyone?

b.) The EPLv2 is a weak copyleft license. So it still requires some 
reciprocity. ALv2 does not.
https://apache.org/legal/resolved.html 
See section 3 in https://www.eclipse.org/legal/epl-2.0/
I think this would be fine as long as we make sure not to modify it. Our 
java-ee-api super-jar might be such a case.

c.) Software Maintenance
With maintaining our own versions of the specs we can rather quickly test out 
new features currently under discussion. This would be harder if we do not 
maintain those sources ourselves.
Of course this also has downsides: we _need_ to maintain it and we need to make 
sure it finally is binary compatible. Checking signatures and stuff... 

For the record: Apache Tomcat still maintains all the apis for themselves as 
well:
https://github.com/apache/tomcat/tree/master/java/jakarta

Re: [VOTE] Release javaee-api 7.0-2

[Mark Struberg]

+1

LieGrue,
strub


> Am 26.03.2020 um 20:50 schrieb Jean-Louis Monteiro :
> 
> +1
> 
> Le jeu. 26 mars 2020 à 17:58, David Blevins  a
> écrit :
> 
>> +1
>> 
>> 
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 
>>> On Feb 25, 2020, at 12:13 PM, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>> 
>>> Hi
>>> 
>>> This is a vote for an updated Java EE spec jar. This has a key change,
>>> which is to use the Tomcat API libraries from 8.5.51 as opposed to 8.5.6.
>>> 
>>> This is required to fix an issue in the TomEE builds
>>> where javax.el.ExpressionFactory#getClassNameServices was returning the
>>> first line of the ASF license header as opposed to a class name, and this
>>> being released is a pre-requisite for any further TomEE releases.
>>> 
>>> *SVN TAG*
>>> https://svn.apache.org/repos/asf/tomee/javaee-api/tags/javaee-api-7.0-2/
>>> 
>>> *Sources*
>>> 
>> https://repository.apache.org/service/local/repositories/orgapachetomee-1163/content/org/apache/tomee/javaee-api/7.0-2/javaee-api-7.0-2-source-release.zip
>>> 
>>> *Binaries*
>>> 
>> https://repository.apache.org/service/local/repositories/orgapachetomee-1163/content/org/apache/tomee/javaee-api/7.0-2/javaee-api-7.0-2.zip
>>> 
>>> please VOTE
>>> [+1] all fine, ship it
>>> [+0] don't care
>>> [-1] stop, because ${reason}
>>> 
>>> The VOTE is open for 72h. Here's my +1.
>>> 
>>> Many thanks
>>> 
>>> Jon
>> 
>> 

Re: [VOTE] Release javaee-api 8.0-4

[Mark Struberg]

whoops, missed my 

+1


LieGrue,
strub

> Am 19.03.2020 um 16:02 schrieb Mark Struberg :
> 
> Yes, you folks are right, we can still ship another updated version after 
> that.
> Let's get this out to the streets!
> 
> +1
> 
> LieGrue,
> strub
> 
> 
>> Am 19.03.2020 um 14:55 schrieb Zowalla, Richard 
>> :
>> 
>> +1
> 

Re: [VOTE] Release javaee-api 8.0-4

[Mark Struberg]

Yes, you folks are right, we can still ship another updated version after that.
Let's get this out to the streets!

+1

LieGrue,
strub


> Am 19.03.2020 um 14:55 schrieb Zowalla, Richard 
> :
> 
> +1

Re: CVE-2020-8840 on TomEE 8.0.1

[Mark Struberg]

cool, thanks!

LieGrue,
strub

> Am 13.03.2020 um 19:12 schrieb Jonathan Gallimore 
> :
> 
> That search is a neat trick. I'd suggest we remove that dependency, build,
> and see how the JMS TCK tests look.
> 
> Jon
> 
> On Fri, Mar 13, 2020 at 5:28 PM Mark Struberg 
> wrote:
> 
>> Actually it just seems to be used in the leveldb adapter and the
>> partitioning support.
>> So afaict it is purely optional for us?
>> 
>> https://github.com/apache/activemq/search?p=3=jackson_q=jackson
>> <
>> https://github.com/apache/activemq/search?p=3=jackson_q=jackson
>>> 
>> 
>> 
>> and yeah, it potentially creates problems due to json-p clashes.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 13.03.2020 um 17:58 schrieb Mark Struberg >> :
>>> 
>>> Hi and thanks, Richard!
>>> 
>>> I think we should get rid of it. And it also shows one of the challenges
>> of the TomEE project: we consume a lot of other projects. Actually for 95%
>> of TomEE problems we need to fix some upstream project. Or improve it.
>>> 
>>> In this case the right solution would have been to reach out for the
>> ActiveMQ team and simply remove the direct need for Jackson.
>>> We've done that for CXF as well btw.
>>> And now we need to finally do it for ActiveMQ as well.
>>> 
>>> This is what people often do not see. For every line Romain and I touch
>> in TomEE we have about 200 lines we touch in other projects upstream.
>>> Don't be afraid, those communities are awesome as well!
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>>> Am 13.03.2020 um 15:25 schrieb Zowalla, Richard <
>> richard.zowa...@hs-heilbronn.de>:
>>>> 
>>>> Hi,
>>>> 
>>>> I think the explanation is here
>>>> 
>> http://tomee-openejb.979440.n4.nabble.com/Why-jackson-and-jonhzon-shipped-with-latest-TomEE-td4689451.html
>>>> 
>>>> Best,
>>>> Richard
>>>> 
>>>> Am Freitag, den 13.03.2020, 14:19 +0100 schrieb Alex The Rocker:
>>>>> Hello,
>>>>> 
>>>>> I fully agree with Mark's remark : why would TomEE ever need jackson
>>>>> nice it has johnzon?
>>>>> Duplicating JSON-P implementations should like a bad idea...
>>>>> 
>>>>> Kind regards,
>>>>> Alexandre
>>>>> 
>>>>> Le ven. 13 mars 2020 à 12:29, Mark Struberg
>>>>>  a écrit :
>>>>>> 
>>>>>> Btw, why do we ship jackson anyway?
>>>>>> We used to have Johnzon only. Jackson is imo not required.
>>>>>> What was the reason we re-introduced it?
>>>>>> 
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>>> Am 11.03.2020 um 11:26 schrieb dkwakkel :
>>>>>>> 
>>>>>>> 
>>>>>>> FasterXML jackson-databind 2.0.0 through 2.9.10.2 lacks certain
>>>>>>> xbean-reflect/JNDI blocking, as demonstrated by
>>>>>>> org.apache.xbean.propertyeditor.JndiConverter.
>>>>>>> 
>>>>>>> 8.0.1 ships jackson-databind-2.10.0.jar and xbean-reflect-
>>>>>>> 4.14.jar
>>>>>>> 
>>>>>>> CVE score is 9.8, so can we expect soon TomEE 8.0.2 with this fix
>>>>>>> in it?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Sent from:
>>>>>>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>>> 
>> 
>> 

Re: CVE-2020-8840 on TomEE 8.0.1

[Mark Struberg]

Actually it just seems to be used in the leveldb adapter and the partitioning 
support.
So afaict it is purely optional for us?

https://github.com/apache/activemq/search?p=3=jackson_q=jackson 
<https://github.com/apache/activemq/search?p=3=jackson_q=jackson>


and yeah, it potentially creates problems due to json-p clashes.

LieGrue,
strub


> Am 13.03.2020 um 17:58 schrieb Mark Struberg :
> 
> Hi and thanks, Richard!
> 
> I think we should get rid of it. And it also shows one of the challenges of 
> the TomEE project: we consume a lot of other projects. Actually for 95% of 
> TomEE problems we need to fix some upstream project. Or improve it. 
> 
> In this case the right solution would have been to reach out for the ActiveMQ 
> team and simply remove the direct need for Jackson.
> We've done that for CXF as well btw.
> And now we need to finally do it for ActiveMQ as well.
> 
> This is what people often do not see. For every line Romain and I touch in 
> TomEE we have about 200 lines we touch in other projects upstream.
> Don't be afraid, those communities are awesome as well!
> 
> LieGrue,
> strub
> 
> 
>> Am 13.03.2020 um 15:25 schrieb Zowalla, Richard 
>> :
>> 
>> Hi,
>> 
>> I think the explanation is here 
>> http://tomee-openejb.979440.n4.nabble.com/Why-jackson-and-jonhzon-shipped-with-latest-TomEE-td4689451.html
>> 
>> Best,
>> Richard
>> 
>> Am Freitag, den 13.03.2020, 14:19 +0100 schrieb Alex The Rocker:
>>> Hello,
>>> 
>>> I fully agree with Mark's remark : why would TomEE ever need jackson
>>> nice it has johnzon?
>>> Duplicating JSON-P implementations should like a bad idea...
>>> 
>>> Kind regards,
>>> Alexandre
>>> 
>>> Le ven. 13 mars 2020 à 12:29, Mark Struberg
>>>  a écrit :
>>>> 
>>>> Btw, why do we ship jackson anyway?
>>>> We used to have Johnzon only. Jackson is imo not required.
>>>> What was the reason we re-introduced it?
>>>> 
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>>> Am 11.03.2020 um 11:26 schrieb dkwakkel :
>>>>> 
>>>>> 
>>>>> FasterXML jackson-databind 2.0.0 through 2.9.10.2 lacks certain
>>>>> xbean-reflect/JNDI blocking, as demonstrated by
>>>>> org.apache.xbean.propertyeditor.JndiConverter.
>>>>> 
>>>>> 8.0.1 ships jackson-databind-2.10.0.jar and xbean-reflect-
>>>>> 4.14.jar
>>>>> 
>>>>> CVE score is 9.8, so can we expect soon TomEE 8.0.2 with this fix
>>>>> in it?
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Sent from: 
>>>>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: CVE-2020-8840 on TomEE 8.0.1

[Mark Struberg]

Hi and thanks, Richard!

I think we should get rid of it. And it also shows one of the challenges of the 
TomEE project: we consume a lot of other projects. Actually for 95% of TomEE 
problems we need to fix some upstream project. Or improve it. 

In this case the right solution would have been to reach out for the ActiveMQ 
team and simply remove the direct need for Jackson.
We've done that for CXF as well btw.
And now we need to finally do it for ActiveMQ as well.

This is what people often do not see. For every line Romain and I touch in 
TomEE we have about 200 lines we touch in other projects upstream.
Don't be afraid, those communities are awesome as well!

LieGrue,
strub


> Am 13.03.2020 um 15:25 schrieb Zowalla, Richard 
> :
> 
> Hi,
> 
> I think the explanation is here 
> http://tomee-openejb.979440.n4.nabble.com/Why-jackson-and-jonhzon-shipped-with-latest-TomEE-td4689451.html
> 
> Best,
> Richard
> 
> Am Freitag, den 13.03.2020, 14:19 +0100 schrieb Alex The Rocker:
>> Hello,
>> 
>> I fully agree with Mark's remark : why would TomEE ever need jackson
>> nice it has johnzon?
>> Duplicating JSON-P implementations should like a bad idea...
>> 
>> Kind regards,
>> Alexandre
>> 
>> Le ven. 13 mars 2020 à 12:29, Mark Struberg
>>  a écrit :
>>> 
>>> Btw, why do we ship jackson anyway?
>>> We used to have Johnzon only. Jackson is imo not required.
>>> What was the reason we re-introduced it?
>>> 
>>> 
>>> LieGrue,
>>> strub
>>> 
>>>> Am 11.03.2020 um 11:26 schrieb dkwakkel :
>>>> 
>>>> 
>>>> FasterXML jackson-databind 2.0.0 through 2.9.10.2 lacks certain
>>>> xbean-reflect/JNDI blocking, as demonstrated by
>>>> org.apache.xbean.propertyeditor.JndiConverter.
>>>> 
>>>> 8.0.1 ships jackson-databind-2.10.0.jar and xbean-reflect-
>>>> 4.14.jar
>>>> 
>>>> CVE score is 9.8, so can we expect soon TomEE 8.0.2 with this fix
>>>> in it?
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Sent from: 
>>>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: [VOTE] Release javaee-api 8.0-4

[Mark Struberg]

ETA is soon. The question is whether we handle jpms right now.
Do we at all?
And how do we cope with it for our aggregator spec jar?

LieGrue,
strub


> Am 13.03.2020 um 12:17 schrieb Jonathan Gallimore 
> :
> 
> What's the ETA on the Geronimo spec work, Mark? I think the shade plugin
> has various transformers which can be configured to do what you want. Happy
> to help out with it.
> 
> Jon
> 
> On Fri, Mar 13, 2020 at 10:51 AM Mark Struberg 
> wrote:
> 
>> wait Jon, right now preparing geronimo spec versions with module names.
>> 
>> Automatic-Module-Name: javax.persistence
>> 
>> Btw, how to handle a single jar which is a shade of MULTIPLE maven modules?
>> 
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 25.02.2020 um 21:09 schrieb Jonathan Gallimore <
>> jonathan.gallim...@gmail.com>:
>>> 
>>> Hi
>>> 
>>> This is a vote for an updated Java EE spec jar, with one single change
>> over
>>> javaee-api:8.0-3, which is to use the Tomcat API libraries from 9.0.31 as
>>> opposed to 9.0.22.
>>> 
>>> This is required to fix an issue in the TomEE builds
>>> where javax.el.ExpressionFactory#getClassNameServices was returning the
>>> first line of the ASF license header as opposed to a class name, and this
>>> being released is a pre-requisite for any further TomEE releases.
>>> 
>>> *SVN TAG*
>>> https://svn.apache.org/repos/asf/tomee/javaee-api/tags/javaee-api-8.0-4/
>>> 
>>> *Sources*
>>> 
>> https://repository.apache.org/service/local/repositories/orgapachetomee-1162/content/org/apache/tomee/javaee-api/8.0-4/javaee-api-8.0-4-source-release.zip
>>> 
>>> *Binaries*
>>> 
>> https://repository.apache.org/service/local/repositories/orgapachetomee-1162/content/org/apache/tomee/javaee-api/8.0-4/javaee-api-8.0-4.zip
>>> 
>>> please VOTE
>>> [+1] all fine, ship it
>>> [+0] don't care
>>> [-1] stop, because ${reason}
>>> 
>>> The VOTE is open for 72h. Here's my +1.
>>> 
>>> Many thanks
>>> 
>>> Jon
>> 
>> 

Re: CVE-2020-8840 on TomEE 8.0.1

[Mark Struberg]

Btw, why do we ship jackson anyway?
We used to have Johnzon only. Jackson is imo not required.
What was the reason we re-introduced it?


LieGrue,
strub

> Am 11.03.2020 um 11:26 schrieb dkwakkel :
> 
> 
> FasterXML jackson-databind 2.0.0 through 2.9.10.2 lacks certain
> xbean-reflect/JNDI blocking, as demonstrated by
> org.apache.xbean.propertyeditor.JndiConverter.
> 
> 8.0.1 ships jackson-databind-2.10.0.jar and xbean-reflect-4.14.jar
> 
> CVE score is 9.8, so can we expect soon TomEE 8.0.2 with this fix in it?
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: [VOTE] Release javaee-api 8.0-4

[Mark Struberg]

wait Jon, right now preparing geronimo spec versions with module names.

Automatic-Module-Name: javax.persistence

Btw, how to handle a single jar which is a shade of MULTIPLE maven modules?


LieGrue,
strub



> Am 25.02.2020 um 21:09 schrieb Jonathan Gallimore 
> :
> 
> Hi
> 
> This is a vote for an updated Java EE spec jar, with one single change over
> javaee-api:8.0-3, which is to use the Tomcat API libraries from 9.0.31 as
> opposed to 9.0.22.
> 
> This is required to fix an issue in the TomEE builds
> where javax.el.ExpressionFactory#getClassNameServices was returning the
> first line of the ASF license header as opposed to a class name, and this
> being released is a pre-requisite for any further TomEE releases.
> 
> *SVN TAG*
> https://svn.apache.org/repos/asf/tomee/javaee-api/tags/javaee-api-8.0-4/
> 
> *Sources*
> https://repository.apache.org/service/local/repositories/orgapachetomee-1162/content/org/apache/tomee/javaee-api/8.0-4/javaee-api-8.0-4-source-release.zip
> 
> *Binaries*
> https://repository.apache.org/service/local/repositories/orgapachetomee-1162/content/org/apache/tomee/javaee-api/8.0-4/javaee-api-8.0-4.zip
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h. Here's my +1.
> 
> Many thanks
> 
> Jon

Re: [VOTE] Release TomEE 7.1.2

[Mark Struberg]

+1

LieGrue,
strub


> Am 08.01.2020 um 11:23 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a second attempt at roll of a TomEE 7.1.2. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1159/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1159/tomee-7.1.2/
> 
> Tag:
> 
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-7.1.2
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12345660
> 
> The previous votes were cancelled after an issue was found with TomEE 7.1.2
> (https://issues.apache.org/jira/browse/TOMEE-2758) and the release for
> 7.0.7 had incorrect artifacts. This binary should be the same as the
> previous one, with the exception of the addition of jakarta.activation jar,
> which was included in TomEE 7.1.1 and removing it potentially would cause
> breaking changes.
> 
> Please note that this version does not include Xalan or serializer as TomEE
> does not require these for normal operation. If your application uses
> Xalan, you will need to include it, and its dependencies (e.g. serializer)
> in your application itself.
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release TomEE 7.0.7

[Mark Struberg]

+1

LieGrue,
strub


> Am 14.01.2020 um 17:13 schrieb Jonathan Gallimore 
> :
> 
> This is my +1. Please note this is for 7.0.7 (not 7.1.2) as stated in the
> first line of the email.
> 
> On Wed, Jan 8, 2020 at 10:27 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> Hi All,
>> 
>> Here's a second attempt at roll of a TomEE 7.1.2. Please can you take a
>> careful look, review, test and provide feedback.
>> 
>> Maven Repo:
>> https://repository.apache.org/content/repositories/orgapachetomee-1160/
>> 
>> Binaries & Source:
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1160/tomee-7.0.7/
>> 
>> Tag:
>> 
>> 
>> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-7.0.7
>> 
>> Release notes:
>> 
>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12345659
>> 
>> The previous votes were cancelled after an issue was found with TomEE
>> 7.1.2 (https://issues.apache.org/jira/browse/TOMEE-2758) and the release
>> for 7.0.7 had incorrect artifacts. I apologise for the incorrect artifacts
>> being presented for vote, and I'm grateful for everyone's feedback.
>> 
>> Please VOTE:
>> 
>> [+1] Yes, release it
>> [+0] Not fussed
>> [-1] Don't release, there's a showstopper (please specify what the
>> showstopper is)
>> 
>> Vote will be open for 72 hours or as needed.
>> 
>> Thanks
>> 
>> Jon
>> 

Re: [VOTE] Release TomEE 8.0.1

[Mark Struberg]

+1

LieGrue,
strub

> Am 08.01.2020 um 11:18 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a second attempt at roll of a TomEE 8.0.1. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1161/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1161/tomee-8.0.1/
> 
> Tag:
> 
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-8.0.1
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12346179
> 
> The previous votes were cancelled after an issue was found with TomEE 7.1.2
> (https://issues.apache.org/jira/browse/TOMEE-2758) and the release for
> 7.0.7 had incorrect artifacts. The binary here should be the same as the
> previous vote, so if you were ok with that, theoretically this one should
> be ok too - but please check.
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release Tomee 7.1.2

[Mark Struberg]

+1

tested with a few big apps.

LieGrue,
strub


> Am 19.12.2019 um 08:26 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a first attempt at roll of a TomEE 7.1.2. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1157/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1157/tomee-7.1.2/
> 
> Tag:
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-7.1.2
> 
> Release notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12345660
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release TomEE 8.0.1

[Mark Struberg]

+1

LieGrue,
strub


> Am 19.12.2019 um 08:19 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a first attempt at roll of a TomEE 8.0.1. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1156/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1156/tomee-8.0.1/
> 
> Tag:
> 
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-8.0.1
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12346179
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release TomEE 7.0.7

[Mark Struberg]

+1

LieGrue,
strub


> Am 19.12.2019 um 16:54 schrieb Jonathan Gallimore 
> :
> 
> Hi All,
> 
> Here's a first attempt at roll of a TomEE 7.0.7. Please can you take a
> careful look, review, test and provide feedback.
> 
> Maven Repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1158/
> 
> Binaries & Source:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1158/tomee-7.0.7/
> 
> Tag:
> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-
> 
> 7.1.2
> 
> Release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12345659
> 
> Please VOTE:
> 
> [+1] Yes, release it
> [+0] Not fussed
> [-1] Don't release, there's a showstopper (please specify what the
> showstopper is)
> 
> Vote will be open for 72 hours or as needed.
> 
> Thanks
> 
> Jon

Re: [VOTE] Release javaee-api 8.0-3

[Mark Struberg]

+1

LieGrue,
strub


> Am 09.12.2019 um 23:09 schrieb Jonathan Gallimore 
> :
> 
> Hi
> 
> This is a vote for an updated Java EE spec jar, with one single change over
> javaee-api:8.0-2:
> 
> TOMEE-2690 make sure to not exclude default ProviderLocator and Activator.
> 
> This is a pre-requisite for releasing TomEE 8.0.1 and allows the drop-in
> .war files and the standalone OpenEJB server to work (these were broken in
> 8.0.0).
> 
> *SVN TAG*
> https://svn.apache.org/repos/asf/tomee/javaee-api/tags/javaee-api-8.0-3/
> 
> *Sources*
> https://repository.apache.org/content/repositories/orgapachetomee-1154/org/apache/tomee/javaee-api/8.0-3/javaee-api-8.0-3-source-release.zip
> 
> *Binaries*
> https://repository.apache.org/content/repositories/orgapachetomee-1154/org/apache/tomee/javaee-api/8.0-3/javaee-api-8.0-3.zip
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h. Here's my +1.
> 
> Many thanks
> 
> Jon

Re: [VOTE] Release Apache TomEE 8.0.0 (take 3)

[Mark Struberg]

post +1

And thanks for rolling the release!

LieGrue,
strub


> Am 15.09.2019 um 19:21 schrieb Daniel Dias Dos Santos 
> :
> 
> +1
> --
> 
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
> 
> 
> Em dom, 15 de set de 2019 às 12:32, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> escreveu:
> 
>> Here is my +1
>> Thanks Jon
>> 
>> Le sam. 14 sept. 2019 à 06:20, David Salter  a
>> écrit :
>> 
>>> +1 from me.
>>> 
>>> Tried it on some of my apps that work on 8M3.  Mainly JPA/JAX-RS/MP.
>>> 
>>> David.
>>> 
>>> 
>>>  On Fri, 13 Sep 2019 13:49:42 +0100 Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> wrote 
 Hi All,
 
 Here's a third attempt at roll of a TomEE 8.0.0. Please can you take a
 careful look, review, test and provide feedback.
 
 Maven Repo:
 
 <
>> https://repository.apache.org/content/repositories/orgapachetomee-1145
 
 <
>> https://repository.apache.org/content/repositories/orgapachetomee-1146
 
 
>> https://repository.apache.org/content/repositories/orgapachetomee-1147
 
 Binaries & Source:
 
 <
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1145/tomee-8.0.0/
 
 <
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1146/tomee-8.0.0/
 
 
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1147/tomee-8.0.0/
 
 Library diffs with 8.0.0-M3:
 
 
>>> 
>> https://dist.apache.org/repos/dist/dev/tomee/staging-1147/tomee-8.0.0/DIFF.txt
 
 Tag:
 
 
>>> 
>> https://gitbox.apache.org/repos/asf?p=tomee.git;a=tag;h=refs/tags/tomee-8.0.0
 
 Release notes:
 
 
>>> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12312320=12344635
 
 Please VOTE:
 
 [+1] Yes, release it
 [+0] Not fussed
 [-1] Don't release, there's a showstopper (please specify what the
 showstopper is)
 
 Vote will be open for 72 hours or as needed.
 
 Thanks
 
 Jon
 
>>> 
>>> 
>> 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

Yes, that's a sane approach.
EPL just requires us to have it mentioned in every downstream NOTICE iiuc.

From the EPL v2 [1]

3.1 If a Contributor Distributes the Program in any form, then:
• a) the Program must also be made available as Source Code, in 
accordance with section 3.2, and the Contributor must accompany the Program 
with a statement that the Source Code for the Program is available under this 
Agreement, and informs Recipients how to obtain it in a reasonable manner on or 
through a medium customarily used for software exchange; and...


For TomEE we'd need to add it to our NOTICE for example, right [2]?

This is likely not a problem for TomEE, but might be something to know if some 
project has a fat-jar approach. In this case this weak-copyleft semantic also 
spreads over to the customer project. Not a show-stopper, but something to 
consider.

LieGrue,
strub

[1] https://www.eclipse.org/legal/epl-2.0/
[2] https://github.com/apache/tomee/blob/master/NOTICE


> Am 04.09.2019 um 23:51 schrieb David Blevins :
> 
>> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau  wrote:
>> 
>> No I guess it was right, "that are" ;) = fork @G only when we need to
>> change some impl/default provider.
> 
> Right.  A few things in my mind at least:
> 
> - Industry health: we (Apache) are the only other implementations of 
> Activation, JavaMail, JACC and similar "impl" specs.  If we give up on the 
> impls we have, the industry collapses down to one impl and then what is the 
> point of a spec?
> 
> - Competitiveness: we have seen performance issues reported against our 
> impls.  I distinctly remember one for JACC several years ago.  Where there 
> are issues, there are also potential advantages.  If we can handle it, let's 
> keep our impls and be competitive.
> 
> Where there is no actual impl I don't see any gain for the effort even if 
> small.
> 
> - Unavoidable EPL dependence: We're not likely to write a new Java compiler 
> any time soon, so we're stuck with the EPL forever.
> 
> - Likelyhood of increased EPL dependence: Given it is the default choice in 
> Jakarta, more things will be created under it we may need.
> 
> - Decreasing helping hands: Projects at Apache are switching over to the EPL 
> libraries, so we will have fewer people willing to type in APIs for 
> already-thin legal reasons.
> 
> 
> -David
> 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB

LieGrue,
strub

> Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau :
> 
> @Mark: didn't change with jakarta donation? can you open a ticket on
> jakartee tracker please?
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le mer. 4 sept. 2019 à 15:04, Mark Struberg  a écrit :
> 
>> No, this is an intended situation.
>> When one fully passes the TCK then you get the EFSL. This 'removes' the
>> copyleft nature of the EPL.
>> The details are quite nested in the legal papers, but that's it basically.
>> 
>> If we just upgrade our existing API to be binary compat then we have no IP
>> issues.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau >> :
>>> 
>>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
>> for us.
>>> That said it is good to reuse the same GAV for end users so we might ask
>> jakarta to double license its api jars?
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> 
>>> 
>>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> a écrit :
>>> Yep that was the point.
>>> So I was asking if we should do the same yes or not.
>>> 
>>> That seems to be your opinion Romain.
>>> Mark on the other end is having some doubts about the license.
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>> 
>>> 
>>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
>> wrote:
>>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>>> a écrit :
>>> 
>>>> Thanks Romain. I'm fine with using Eclipse jars if from a legal point
>> of
>>>> view, it works.
>>>> Otherwise, I'd like to split our spec jars.
>>>> 
>>>> What about MicroProfile?
>>>> 
>>> 
>>> We already agreed to not redo the API and use microprofile jars.
>>> 
>>> 
>>>> It's the same license and we are using them in our MicroProfile
>>>> implementations.
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>> 
>>>> 
>>>> On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg >> 
>>>> wrote:
>>>> 
>>>>> depends what their license is. EPL is (weak) copyleft. Thus I would
>> like
>>>>> to avoid exposing it downstream as api.
>>>>> 
>>>>> LieGrue,
>>>>> strub
>>>>> 
>>>>> 
>>>>>> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>>>>> rmannibu...@gmail.com>:
>>>>>> 
>>>>>> If we still can't reuse jakata artifacts (their license is ok and
>> there
>>>>> is
>>>>>> no impl reference inside so we should just use them, right?) it
>> sounds
>>>>>> natural
>>>>>> 
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>> https://github.com/rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <
>>>>> 
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>>>>> jlmonte...@tomitribe.com>
>>>>>> a écrit :
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I was digging into some other specifications and see what would
>> pass
>>>>>>> Jakarta TCK and realized that geronimo-security_1.0_spec content
>>>>> actually
>>>>>>> mixes 2 specifications.
>>>>>>> 
>>>>>>> https://github.com/eclipse-ee4j/security-api
>>>>>>> 
>>>>>>> and
>>>>>>> 
>>>>>>> https://github.com/eclipse-ee4j/jaspic
>>>>>>> 
>>>>>>> I thought the initial intent was to create a specific artifact per
>>>>>>> specification.
>>>>>>> Mixing them is a bit annoying from a certification perspective.
>>>>>>> It's also not clean because in Tomcat for instance, there is
>> already
>>>>>>> jaspic API so it becomes a duplicate.
>>>>>>> 
>>>>>>> Would it be possible to split them up in 2 artifacts?
>>>>>>> 
>>>>>>> --
>>>>>>> Jean-Louis Monteiro
>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>> http://www.tomitribe.com
>>>>>>> 
>>>>> 
>>>>> 
>> 
>> 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

No, this is an intended situation.
When one fully passes the TCK then you get the EFSL. This 'removes' the 
copyleft nature of the EPL.
The details are quite nested in the legal papers, but that's it basically.

If we just upgrade our existing API to be binary compat then we have no IP 
issues.

LieGrue,
strub


> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau :
> 
> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for us.
> That said it is good to reuse the same GAV for end users so we might ask 
> jakarta to double license its api jars?
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro  
> a écrit :
> Yep that was the point.
> So I was asking if we should do the same yes or not. 
> 
> That seems to be your opinion Romain.
> Mark on the other end is having some doubts about the license.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau  
> wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro 
> a écrit :
> 
> > Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
> > view, it works.
> > Otherwise, I'd like to split our spec jars.
> >
> > What about MicroProfile?
> >
> 
> We already agreed to not redo the API and use microprofile jars.
> 
> 
> > It's the same license and we are using them in our MicroProfile
> > implementations.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg 
> > wrote:
> >
> >> depends what their license is. EPL is (weak) copyleft. Thus I would like
> >> to avoid exposing it downstream as api.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >> >
> >> > If we still can't reuse jakata artifacts (their license is ok and there
> >> is
> >> > no impl reference inside so we should just use them, right?) it sounds
> >> > natural
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> > <https://rmannibucau.metawerx.net/> | Old Blog
> >> > <http://rmannibucau.wordpress.com> | Github <
> >> https://github.com/rmannibucau> |
> >> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> >> > <
> >> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> >
> >> >
> >> >
> >> > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >> > a écrit :
> >> >
> >> >> Hi all,
> >> >>
> >> >> I was digging into some other specifications and see what would pass
> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> >> actually
> >> >> mixes 2 specifications.
> >> >>
> >> >> https://github.com/eclipse-ee4j/security-api
> >> >>
> >> >> and
> >> >>
> >> >> https://github.com/eclipse-ee4j/jaspic
> >> >>
> >> >> I thought the initial intent was to create a specific artifact per
> >> >> specification.
> >> >> Mixing them is a bit annoying from a certification perspective.
> >> >> It's also not clean because in Tomcat for instance, there is already
> >> >> jaspic API so it becomes a duplicate.
> >> >>
> >> >> Would it be possible to split them up in 2 artifacts?
> >> >>
> >> >> --
> >> >> Jean-Louis Monteiro
> >> >> http://twitter.com/jlouismonteiro
> >> >> http://www.tomitribe.com
> >> >>
> >>
> >>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

depends what their license is. EPL is (weak) copyleft. Thus I would like to 
avoid exposing it downstream as api.

LieGrue,
strub


> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau :
> 
> If we still can't reuse jakata artifacts (their license is ok and there is
> no impl reference inside so we should just use them, right?) it sounds
> natural
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro 
> a écrit :
> 
>> Hi all,
>> 
>> I was digging into some other specifications and see what would pass
>> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
>> mixes 2 specifications.
>> 
>> https://github.com/eclipse-ee4j/security-api
>> 
>> and
>> 
>> https://github.com/eclipse-ee4j/jaspic
>> 
>> I thought the initial intent was to create a specific artifact per
>> specification.
>> Mixing them is a bit annoying from a certification perspective.
>> It's also not clean because in Tomcat for instance, there is already
>> jaspic API so it becomes a duplicate.
>> 
>> Would it be possible to split them up in 2 artifacts?
>> 
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 

Re: TOMEE-2618 Reconcile javax.activation dependencies

[Mark Struberg]

I'd rather roll a Geronimo-activation-1.2 spec.

EPL is a weak copyleft license. That means shipping with an EPL dependency has 
a legal impact on downstream consumers. That's the reason why it is only CatB.
Rolling the few missing enhancements should really be easy.

LieGrue,
strub

> Am 13.08.2019 um 06:33 schrieb David Blevins :
> 
> With the latest Java 11 changes we have two copies and versions of the 
> javax.activation specification in our dist.  
> 
> - geronimo-activation_1.1_spec (via javaee-api-8.0)
> - jakarta.activation-1.2.1.jar
> 
> The Jakarta EE 8 version of Activation should be 1.2.  There is no Geronimo 
> Activation 1.2 available.
> 
> https://issues.apache.org/jira/browse/TOMEE-2618
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 

Re: Upgrade BVal to official (not patched) one

[Mark Struberg]

I can probably help with that a bit. Just ping me if you need something.

LieGrue,
strub


> Am 05.08.2019 um 20:16 schrieb Thomas Andraschko 
> :
> 
> I would like to release 2.0.3, as it contains some fixes and performance
> boosts, if you are ok with using the official bval
> 
> Jean-Louis Monteiro  schrieb am Mo., 5. Aug.
> 2019, 18:24:
> 
>> Following up on this thread.
>> What version would you recommend?
>> 
>> On Maven central we have
>> https://search.maven.org/search?q=g:org.apache.bval
>> I believe it's 2.0.2 but wanted to double check
>> 
>> 
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 
>> 
>> On Mon, Jul 29, 2019 at 10:20 AM Thomas Andraschko <
>> andraschko.tho...@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> there were some "possible issues" with bval in the last months,
>> especially:
>>> 
>>> https://issues.apache.org/jira/browse/BVAL-174
>>> (also see https://www.mail-archive.com/dev@bval.apache.org/msg01042.html
>> )
>>> 
>>> and
>>> 
>>> https://issues.apache.org/jira/projects/BVAL/issues/BVAL-175
>>> 
>>> both are no issues from our perspective @bval side (please feel free to
>>> join the discussions there).
>>> 
>>> I would really like to see the bval upgrade for the next milestone or
>> even
>>> the final release.
>>> If you are ok with the upgrade, we would prepare a bval release.
>>> 
>>> It's a big boost in the startup performance and with those changes, we
>>> almost have the same startup time as with 7.x.
>>> 
>>> Best regards,
>>> Thomas
>>> 
>> 

Re: tomee-patch release staging?

[Mark Struberg]

whoops, kk. What I usually do is to add a comment to all staging repos I close. 
That way we know quickly what it is supposed to do.
Especially in bigger projects with many artifacts like geronimo, tomee, owb, 
etc it helps tremendously. In G we often have 5 staging repos open in parallel. 
Ofc this is a manual step release managers have to do.

LieGrue,
strub

> Am 06.08.2019 um 07:58 schrieb David Blevins :
> 
> I was wrong :)  We did need that.  I was supposed to click release on that 
> one as it contained the patched bval from the M3 release.
> 
> I've quickly replaced it, so things are all fine.  Mental note to use the 
> same staging repo should we need to do that again -- which we hopefully won't 
> any time soon.
> 
> 
> -David
> 
> 
>> On Aug 4, 2019, at 11:40 PM, Mark Struberg  wrote:
>> 
>> Done.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 05.08.2019 um 08:28 schrieb David Blevins :
>>> 
>>> Go ahead and drop it.  Thank you!
>>> 
>>> Good catch.
>>> 
>>> -- 
>>> David Blevins
>>> http://twitter.com/dblevins
>>> http://www.tomitribe.com
>>> 
>>>> On Aug 4, 2019, at 11:15 PM, Mark Struberg  
>>>> wrote:
>>>> 
>>>> Good morning!
>>>> 
>>>> While releasing Johnzon-1.1.13 I stumbled across a TomEE staging repo from 
>>>> May
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1134
>>>> 
>>>> Can we drop this, or is it still needed?
>>>> 
>>>> LieGrue,
>>>> strub
>>> 
>> 
> 

Re: tomee-patch release staging?

[Mark Struberg]

Done.

LieGrue,
strub


> Am 05.08.2019 um 08:28 schrieb David Blevins :
> 
> Go ahead and drop it.  Thank you!
> 
> Good catch.
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
>> On Aug 4, 2019, at 11:15 PM, Mark Struberg  wrote:
>> 
>> Good morning!
>> 
>> While releasing Johnzon-1.1.13 I stumbled across a TomEE staging repo from 
>> May
>> https://repository.apache.org/content/repositories/orgapachetomee-1134
>> 
>> Can we drop this, or is it still needed?
>> 
>> LieGrue,
>> strub
> 

Re: JIRA cleanup

[Mark Struberg]

I've now at least moved the open ones from M3 to M4.

LieGrue,
strub


> Am 05.08.2019 um 08:16 schrieb Mark Struberg :
> 
> another thing I noticed.
> 
> 
> 8.0.0-M3 got released, but the JIRA version still has many open tickets on 
> this version.
> I suggest to move all those to 8.0.0-M4 and close all resolved tickets and 
> mark M3 as released.
> 
> Who want's to do it?
> 
> LieGrue,
> strub

JIRA cleanup

[Mark Struberg]

another thing I noticed.


8.0.0-M3 got released, but the JIRA version still has many open tickets on this 
version.
I suggest to move all those to 8.0.0-M4 and close all resolved tickets and mark 
M3 as released.

Who want's to do it?

LieGrue,
strub

tomee-patch release staging?

[Mark Struberg]

Good morning!

While releasing Johnzon-1.1.13 I stumbled across a TomEE staging repo from May
https://repository.apache.org/content/repositories/orgapachetomee-1134

Can we drop this, or is it still needed?

LieGrue,
strub

Re: [VOTE] TomEE 8.0.0-M3 (staging-1136) - take two

[Mark Struberg]

whoops, replied to wrong vote.

+1

LieGrue,
strub

Am Donnerstag, den 23.05.2019, 01:43 -0700 schrieb David Blevins:
> Ok, the extra libraries have been removed and new M3 build created.  Vote will
> be open for 72 hours or as needed.
> 
> Maven Repo:
> 
>  - https://repository.apache.org/content/repositories/orgapachetomee-1136/
> 
> Binaries & Source:
> 
>  - https://dist.apache.org/repos/dist/dev/tomee/staging-1136/tomee-8.0.0-M3
> 
> Binary comparison:
> 
>  - 
> https://dist.apache.org/repos/dist/dev/tomee/staging-1136/tomee-8.0.0-M3/DIFF.txt
> 
> Here is a diff of the staging-1135 and staging-1136 builds.
> 
> apache-tomee 8.0.0-M3 webprofile (staging-1136)
> 
>   DEL ant-1.10.5.jar [2216.65 ko]
>   DEL ant-launcher-1.10.5.jar [18.83 ko]
>   DEL codemodel-2.3.2.jar [159.21 ko]
>   DEL dtd-parser-1.4.1.jar [62.47 ko]
>   DEL istack-commons-tools-3.0.8.jar [29.29 ko]
>   DEL jaxb-xjc-2.3.2.jar [903.20 ko]
>   DEL relaxng-datatype-2.3.2.jar [19.88 ko]
>   DEL rngom-2.3.2.jar [315.64 ko]
>   DEL xsom-2.3.2.jar [415.37 ko]
> 
>   change: -3.59 MB
>   total : 41.72 MB
> 
> apache-tomee 8.0.0-M3 microprofile (staging-1136)
> 
>   DEL ant-1.10.5.jar [2216.65 ko]
>   DEL ant-launcher-1.10.5.jar [18.83 ko]
>   DEL asm-all-5.0.3.jar [241.64 ko]
>   DEL codemodel-2.3.2.jar [159.21 ko]
>   DEL dtd-parser-1.4.1.jar [62.47 ko]
>   DEL istack-commons-tools-3.0.8.jar [29.29 ko]
>   DEL jaxb-xjc-2.3.2.jar [903.20 ko]
>   DEL relaxng-datatype-2.3.2.jar [19.88 ko]
>   DEL rngom-2.3.2.jar [315.64 ko]
>   DEL xsom-2.3.2.jar [415.37 ko]
> 
>   change: -3.80 MB
>   total : 44.57 MB
> 
> apache-tomee 8.0.0-M3 plus (staging-1136)
> 
>   DEL ant-1.10.5.jar [2216.65 ko]
>   DEL ant-launcher-1.10.5.jar [18.83 ko]
>   DEL asm-all-5.0.3.jar [241.64 ko]
>   DEL codemodel-2.3.2.jar [159.21 ko]
>   DEL dtd-parser-1.4.1.jar [62.47 ko]
>   DEL istack-commons-tools-3.0.8.jar [29.29 ko]
>   DEL jaxb-xjc-2.3.2.jar [903.20 ko]
>   DEL relaxng-datatype-2.3.2.jar [19.88 ko]
>   DEL rngom-2.3.2.jar [315.64 ko]
>   DEL xsom-2.3.2.jar [415.37 ko]
> 
>   change: -3.80 MB
>   total : 61.36 MB
> 
> apache-tomee 8.0.0-M3 plume (staging-1136)
> 
>   DEL ant-1.10.5.jar [2216.65 ko]
>   DEL ant-launcher-1.10.5.jar [18.83 ko]
>   DEL asm-all-5.0.3.jar [241.64 ko]
>   DEL codemodel-2.3.2.jar [159.21 ko]
>   DEL dtd-parser-1.4.1.jar [62.47 ko]
>   DEL istack-commons-tools-3.0.8.jar [29.29 ko]
>   DEL jaxb-xjc-2.3.2.jar [903.20 ko]
>   DEL relaxng-datatype-2.3.2.jar [19.88 ko]
>   DEL rngom-2.3.2.jar [315.64 ko]
>   DEL xsom-2.3.2.jar [415.37 ko]
> 
>   change: -3.80 MB
>   total : 68.20 MB
> 
> 
> 
> 

Re: [VOTE] TomEE 8.0.0-M3 (staging-1135)

[Mark Struberg]

+1 (binding)

LieGrue,
strub


Am Freitag, den 17.05.2019, 16:05 +0900 schrieb David Blevins:
> Ok, finally vote time!
> 
> Maven Repo:
> 
>  https://repository.apache.org/content/repositories/orgapachetomee-1135/
> 
> Binaries & Source:
> 
>  https://dist.apache.org/repos/dist/dev/tomee/staging-1135/tomee-8.0.0-M3
> 
> I'll create the tag in git if the vote passes.
> 
> Vote will be open for 72 hours or as needed.
> 
> If someone would like to help with cleaning JIRA for the release notes, that
> would be fantastic.
> 
> 

Re: Jakarta EE namespace discussion

[Mark Struberg]

And here is some more in-depth technical information
https://struberg.wordpress.com/2019/05/06/the-way-forward-for-jakartaee-packages/

Already trying out how well Option C (big-bang, Davids 1) would work and what 
borders we'd hit.

Copying over what I wrote on the tomcat list:
---
I've also already started to migrate a few spec packages.
The current work in progress is available here:
https://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/

I've already test-migrated over Apache OpenWebBeans CDI container.
Of course with TCK and servlet integration disabled for now as Arquillian and 
Tomcat first needs to be ported.
https://github.com/struberg/openwebbeans/tree/jakarta

I'm right now tinkering with Tomcat.
And boy, tomcat has way more dependencies than I'd like. 
And it would help if it would finally be migrated to use Maven, but I spare you 
that ;)

As soon as I've something decently working then I'll share!



LieGrue,
strub


> Am 07.05.2019 um 17:54 schrieb David Blevins :
> 
> Hi All,
> 
> On the Jakarta EE side of the fence, we've issued statements last week Friday 
> that modification of javax as originally intended will not be allowed.  Here 
> are two tweets with information:
> 
> - https://twitter.com/mmilinkov/status/1124252441288032256
> - https://twitter.com/dblevins/status/1124398525138128896
> 
> At this moment, there's a discussion going on the Jakarta EE Platform dev 
> list on how to move forward with a rename of `javax` to `jakarta`.  Your 
> voice as a user is encouraged on this tread and list.
> 
> - https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html
> - https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev  
> (subscribe)
> 
> Additionally, there's a Jakarta EE community hangout scheduled for tomorrow 
> 8am Pacific.  This is open to everyone.  Details here:
> 
> - https://twitter.com/JakartaEE/status/1125741766559375365
> 
> If you have any TomEE specific thoughts or concerns a user, feel encouraged 
> to voice them, ask questions as much as you'd like here.
> 
> Ultimately, what is decided on the Jakarta EE Platform Dev list will have 
> implications over here, but certainly any TomEE community discussion in 
> parallel is also completely welcome.
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 

Re: [VOTE] [RESULT] release Apache TomEE javaee-api 8.0-1

[Mark Struberg]

Good morning!

The VOTE did pass with the following:

+1 Mark, Alex Rabelo, Jean-Louis, Ivan, Daniel, Richard, Jon, Cesar

No -1 nor 0

txs to all who reviewed and voted!

I'll go on with the release steps.

LieGrue,
strub




> Am 10.04.2019 um 22:41 schrieb Mark Struberg :
> 
> Hi!
> 
> We've fixed the following 2 (important) tickets:
> https://issues.apache.org/jira/browse/TOMEE-2490
> https://issues.apache.org/jira/browse/TOMEE-2508
> 
> The JPA-2.2 update is required for updating to OpenJPA-3.1.0.
> 
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachetomee-1133
> 
> The source repo can be found under
> https://repository.apache.org/content/repositories/orgapachetomee-1133/org/apache/tomee/javaee-api/8.0-1/
> sha1 is dd3b5d43d266378e56f245943e63a9981b9b1b5e
> 
> 
> Please VOTE:
> 
> [+1] yeah, ship it!
> [+0] meh, don't care
> [-1] nah, because ${showstopper}
> 
> The VOTE is open for 72h
> 
> txs and LieGrue,
> strub

Re: [VOTE] release Apache TomEE javaee-api 8.0-1

[Mark Struberg]

+1

LieGrue,
strub


> Am 10.04.2019 um 22:41 schrieb Mark Struberg :
> 
> Hi!
> 
> We've fixed the following 2 (important) tickets:
> https://issues.apache.org/jira/browse/TOMEE-2490
> https://issues.apache.org/jira/browse/TOMEE-2508
> 
> The JPA-2.2 update is required for updating to OpenJPA-3.1.0.
> 
> The staging repo is
> https://repository.apache.org/content/repositories/orgapachetomee-1133
> 
> The source repo can be found under
> https://repository.apache.org/content/repositories/orgapachetomee-1133/org/apache/tomee/javaee-api/8.0-1/
> sha1 is dd3b5d43d266378e56f245943e63a9981b9b1b5e
> 
> 
> Please VOTE:
> 
> [+1] yeah, ship it!
> [+0] meh, don't care
> [-1] nah, because ${showstopper}
> 
> The VOTE is open for 72h
> 
> txs and LieGrue,
> strub

[VOTE] release Apache TomEE javaee-api 8.0-1

[Mark Struberg]

Hi!

We've fixed the following 2 (important) tickets:
https://issues.apache.org/jira/browse/TOMEE-2490
https://issues.apache.org/jira/browse/TOMEE-2508

The JPA-2.2 update is required for updating to OpenJPA-3.1.0.

The staging repo is
https://repository.apache.org/content/repositories/orgapachetomee-1133

The source repo can be found under
https://repository.apache.org/content/repositories/orgapachetomee-1133/org/apache/tomee/javaee-api/8.0-1/
sha1 is dd3b5d43d266378e56f245943e63a9981b9b1b5e


Please VOTE:

[+1] yeah, ship it!
[+0] meh, don't care
[-1] nah, because ${showstopper}

The VOTE is open for 72h

txs and LieGrue,
strub

[DISCUSS] will release javaee-api-8.0-1

[Mark Struberg]

Hi!

Gonna do a release for the javaee-api 8.

There are 2 important tickets which have been fixed:
https://issues.apache.org/jira/browse/TOMEE-2490 dead-lock in JSON-P api
https://issues.apache.org/jira/browse/TOMEE-2508 update to JPA-2.2

Please shout if I should wait a bit.

LieGrue,
strub

Fwd: [VOTE] Release Apache OpenJPA-3.1.0

[Mark Struberg]

FYI.

OpenJPA-3.1.0 vote is otw.

LieGrue,
strub

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Mark Struberg 
> Betreff: [VOTE] Release Apache OpenJPA-3.1.0
> Datum: 6. April 2019 um 14:52:00 MESZ
> An: openjpa-dev 
> Antwort an: d...@openjpa.apache.org
> 
> hi folks!
> 
> We have fixed tons of enhancements and bugs in OpenJPA for our 3.1.0 release.
> One of the main improvements is to move to a native JavaEE8 level - JPA-2.2.
> Please note that we implemented many JPA-2.2 features but not all yet. 
> We will work towards implementing the rest of the missing 2.2 stuff in the 
> next bugfix releases.
> 
> 
> Here are the fixed tickets:
> 
> Sub-task
> 
>   • [OPENJPA-2710] - Create and update to geronimo-jpa_2.2_spec
> Bug
> 
>   • [OPENJPA-1993] - Deadlock Potential with ORM XML Processing
>   • [OPENJPA-2555] - Timestamp precision from manual schema not respected
>   • [OPENJPA-2567] - TINY/MEDIUM/LONG TEXT fields for MySQL and MariaDB 
> are not supported
>   • [OPENJPA-2673] - Table is not created in openjpa 3.0.0-SNAPSHOT and 
> OSGi
>   • [OPENJPA-2704] - The openjpa.jdbc.Schema no longer overrides orm.xml 
> default
>   • [OPENJPA-2733] - Subquery parameters are incorrectly assigned
>   • [OPENJPA-2742] - SchemaTool fails with MySQL
>   • [OPENJPA-2746] - OpenJPA Karaf feature is not complete
>   • [OPENJPA-2756] - PostgreSQL requires escaping of search strings in 
> all versions
>   • [OPENJPA-2757] - upgrade to xbean-asm7 to support Java11
>   • [OPENJPA-2761] - problem inserting more than 4000 charcters in oracle 
> XMLTYPE column
>   • [OPENJPA-2764] - Map path expression tests behave random
>   • [OPENJPA-2768] - XMLStore SAXParser doesn't distinguish between 
> element and extent
>   • [OPENJPA-2770] - false boolean literal doesn't work
>   • [OPENJPA-2771] - It seems like h2 'unlimited' is not "LIMIT 0" but 
> rather "LIMIT -1"
>   • [OPENJPA-2772] - list of h2 reserved words is incomplete
>   • [OPENJPA-2777] - Indices specified using javax.persistence.Index 
> annotation are not being created
>   • [OPENJPA-2780] - ReverseMappingTool does not generate @Enumerated 
> annotation
>   • [OPENJPA-2781] - OpenJPA need internet connection to read the 
> persistence.xml
> Improvement
> 
>   • [OPENJPA-2745] - Clean up try-catch implementation for DB2Dictionary
>   • [OPENJPA-2747] - Upgrade to JPA 2.2 and use javax.persistence-api spec
>   • [OPENJPA-2748] - commons-collections should be updated to most recent 
> version
>   • [OPENJPA-2750] - commons-dbcp need to be updated to most recent 
> version
>   • [OPENJPA-2751] - Code clean-up should be performed
>   • [OPENJPA-2752] - More libraries can be updated
>   • [OPENJPA-2753] - Create profiles to start various databases via Docker
>   • [OPENJPA-2755] - support MySQL DATETIME and TIMESTAMP fractions 
> (milliseconds, nanos)
>   • [OPENJPA-2773] - set minIdle to > 0 in DBCPDriverDataSource
>   • [OPENJPA-2775] - hsqldb doesn't support NullTable to retrieve meta 
> information
> Task
> 
>   • [OPENJPA-2744] - commons-pool should be updated to most recent version
>   • [OPENJPA-2754] - update to latest dbcp and verify moving from 
> maxActive to maxTotal
>   • [OPENJPA-2758] - JPA 2.2 compliance
> Dependency upgrade
> 
>   • [OPENJPA-2784] - update docs before our release
> 
> 
> The staging repository is at:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1005/
> 
> The source release is at
> https://repository.apache.org/content/repositories/orgapacheopenjpa-1005/org/apache/openjpa/openjpa-parent/3.1.0/
> sha1 is 1aea7cfff20c3a5fed57fb41fb1fcd4784b999ae
> 
> I've pushed the release branch to my github repo 
> https://github.com/struberg/openjpa/tree/release-3.1.0
> 
> 
> Please VOTE:
> 
> [+1] yeah, ship it!
> [+0] meh, don't care
> [-1] nah, because ${showstopper}
> 
> The VOTE is open for 72h
> 
> txs and LieGrue,
> strub

Re: [DISCUSS] version of our next javaee-api

[Mark Struberg]

 Oki great!
We should do a sigtest and if that is fine we can go on and release it as 
well.I've created a sigtest run script in various spec projects.Just look at 
json_1.1 for example.
LieGrue,strub


On Monday, 11 March 2019, 12:07:43 CET, Roberto Cortez 
 wrote:  
 
 Hum… JL mentioned that he merged 
https://github.com/apache/geronimo-specs/pull/14 
<https://github.com/apache/geronimo-specs/pull/14>

It seems to be there:
https://github.com/apache/geronimo-specs/tree/trunk/geronimo-security_1.0_spec 
<https://github.com/apache/geronimo-specs/tree/trunk/geronimo-security_1.0_spec>

Thanks!

Cheers,
Roberto

> On 9 Mar 2019, at 13:34, Mark Struberg  wrote:
> 
> I've only upgraded the various versions of our dependencies so far.I did not 
> add anything new. Not sure if we have that already.
> 
>    On Friday, 8 March 2019, 11:46:37 CET, Roberto Cortez 
> wrote:  
> 
> +1
> 
> Does this include the security api as well?
> 
>> On 8 Mar 2019, at 06:41, Mark Struberg  wrote:
>> 
>> David is right, next will be 8.0-1
>> 
>> 8.0 is for JavaEE8, -1 is the first update.
>> 
>> LieGrue,
>> Strub
>> 
>>> Am 07.03.2019 um 21:37 schrieb exabrial12 :
>>> 
>>> I'd stick to https://semver.org/ whenever possible :) This also helps Nexus
>>> and Maven make correct decisions.
>>> 
>>> 8.0.1 would be a bugfix, 8.1.0 would be new APIs are added but all old APIs
>>> remain, 9.0.0 would be old apis removed and possibly new stuff added.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
  

Re: [DISCUSS] version of our next javaee-api

[Mark Struberg]

 I've only upgraded the various versions of our dependencies so far.I did not 
add anything new. Not sure if we have that already.

On Friday, 8 March 2019, 11:46:37 CET, Roberto Cortez 
 wrote:  
 
 +1

Does this include the security api as well?

> On 8 Mar 2019, at 06:41, Mark Struberg  wrote:
> 
> David is right, next will be 8.0-1
> 
> 8.0 is for JavaEE8, -1 is the first update.
> 
> LieGrue,
> Strub
> 
>> Am 07.03.2019 um 21:37 schrieb exabrial12 :
>> 
>> I'd stick to https://semver.org/ whenever possible :) This also helps Nexus
>> and Maven make correct decisions.
>> 
>> 8.0.1 would be a bugfix, 8.1.0 would be new APIs are added but all old APIs
>> remain, 9.0.0 would be old apis removed and possibly new stuff added.
>> 
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
  

Re: [DISCUSS] version of our next javaee-api

[Mark Struberg]

David is right, next will be 8.0-1

8.0 is for JavaEE8, -1 is the first update.

LieGrue,
Strub

> Am 07.03.2019 um 21:37 schrieb exabrial12 :
> 
> I'd stick to https://semver.org/ whenever possible :) This also helps Nexus
> and Maven make correct decisions.
> 
> 8.0.1 would be a bugfix, 8.1.0 would be new APIs are added but all old APIs
> remain, 9.0.0 would be old apis removed and possibly new stuff added.
> 
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

[DISCUSS] version of our next javaee-api

[Mark Struberg]

Hi folks!
I've fixed some nasty bugs in our javaee-api (mostly updated to important 
geronimo-spec bug fixes) and would love to release it soon.The currently 
released version has a number javaee-api-8.0.Right now the version in the pom 
is 8.0.1-SNAPSHOT.So when rolling a release should we go to 8.1 or 8.0.1?
LieGrue,strub

Re: JakartaEE TCK

[Mark Struberg]

I went through this yesterday night. 
Over here it was mainly missing spec jars.
The TCK also compiles against tons of internal Glassfish classes, proprietary 
databasess I've never heard of, etc.
I eventually gave up yesterday :)

Can you probably share some of the compile errors you got?

LieGrue,
strub

> Am 15.01.2019 um 13:14 schrieb Jonathan Gallimore 
> :
> 
> Ok - still the same.
> 
> On Tue, Jan 15, 2019 at 12:09 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> Good spot... Let's try that
>> 
>> Jon
>> 
>> On Tue, Jan 15, 2019 at 11:58 AM Bruno Baptista 
>> wrote:
>> 
>>> Hey Jon,
>>> 
>>> On the Jakarta TCK min requirements they mention that it requires Ant
>>> 1.10.5+
>>> 
>>> That might explain some errors.
>>> 
>>> Bruno Baptista
>>> https://twitter.com/brunobat_
>>> 
>>> 
>>> On 15/01/19 11:53, Jonathan Gallimore wrote:
 need to change JAVA_HOME and ANT_HOME to match your environment. I'm
 using Ant 1.9.13 and OpenJDK 8/Hotpsot from AdoptOpenJDK.
>>> 
>> 

Re: Jakarta EE TCK

[Mark Struberg]

+1 and thanks!

Also am interested to run the JPA related tests over at OpenJPA.

LieGrue,
strub


> Am 15.01.2019 um 00:34 schrieb Jonathan Gallimore 
> :
> 
> Thanks, I'll update that and I have couple of changes to commit as well.
> 
> Jon
> 
> On Mon, 14 Jan 2019, 23:23 David Blevins  
>>> On Jan 12, 2019, at 1:28 PM, David Blevins 
>> wrote:
>>> 
>>> All,
>>> 
>>> I've opened a request to have the code we've been using to run the
>> former Java EE TCK opened so everyone can run the new Jakarta EE TCK.
>>> 
>>> - https://issues.apache.org/jira/browse/INFRA-17633
>> 
>> Infra said this is basically self serve, so I cracked in on this one.
>> This took a huge amount of work (see INFRA-17633 if interested), but the
>> svn repo is now migrated to git and is now public.
>> 
>> - https://github.com/apache/tomee-tck
>> 
>> The private svn repo should now be considered dead and all work done in
>> the above repo.  Note the README.md is outdated and refers to the Java EE
>> TCK.
>> 
>> Jon, I'll let you have the honors of updating the README. :)
>> 
>> 
>> -David
>> 
>> 
>> 

JakartaEE TCK

[Mark Struberg]

Hi folks!

The EE8 TCKs are now open source.

https://github.com/eclipse-ee4j/jakartaee-tck

But was anyone able to build this?

Or does anybody know if there is already a published zip like we had with the 
closed TCKs?

txs and LieGrue,
strub

Re: Move to Gitbox?

[Mark Struberg]

+1, at minimum the ee-api project should also be moved to gitbox.

LieGrue,
strub

> Am 28.12.2018 um 22:59 schrieb Jean-Louis Monteiro :
> 
> +1
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, Dec 13, 2018 at 4:12 PM Roberto Cortez 
> wrote:
> 
>> I’ve just remembered about this:
>> 
>> How about other repos not part of the main tomee one but sitting in the
>> project that are on SVN?
>> https://svn.apache.org/repos/asf/tomee/ <
>> https://svn.apache.org/repos/asf/tomee/>
>> 
>> I would like to at least have the javaee-api project moved to Git as well.
>> 
>> What do you think?
>> 
>> Cheers,
>> Roberto
>> 
>>> On 13 Dec 2018, at 10:13, Jean-Louis Monteiro 
>> wrote:
>>> 
>>> Thank you
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>> 
>>> 
>>> On Thu, Dec 13, 2018 at 11:12 AM Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> wrote:
>>> 
 Ticket filed. https://issues.apache.org/jira/browse/INFRA-17417
 
 I believe its basically automated - the git-wip remote will become a
>> gitbox
 remote. I'll ask about the PRs.
 
 Jon
 
 On Thu, Dec 13, 2018 at 10:06 AM Jean-Louis Monteiro <
 jlmonte...@tomitribe.com> wrote:
 
> Do you know how smooth it will be?
> I mean, what about current PRs?
> 
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Thu, Dec 13, 2018 at 10:58 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> Looks like we have good support for this, so I'll get this started.
>> 
>> Jon
>> 
>> On Tue, Dec 11, 2018 at 11:44 AM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>> 
>>> Hi Folks
>>> 
>>> It appears that the git-wip service is going to be retired, and the
>>> repositories are going to be migrated over to Gitbox -
>>> https://gitbox.apache.org/.
>>> 
>>> We can voluntarily move to GitBox anytime between now and January 9th
>>> 2019. After January 9th, Infra will require us to move to move within
> one
>>> month by February 7th 2019.
>>> 
>>> I propose that we be proactive and look to move now, and we should
 get
>> the
>>> benefits of better GitHub integration, which given that we are seeing
>>> bigger numbers of PRs coming through GitHub, this seems to make sense
> to
>> me.
>>> 
>>> I'm happy to work with infra, and provide guidance to everyone on
 this
>>> list. We don't necessarily need a vote, but we do need consensus on
> this
>>> list in order to move ahead.
>>> 
>>> Are there any objections or other feedback?
>>> 
>>> Many thanks
>>> 
>>> Jon
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
 
>> 
>> 

Re: Is TomEE ready to ship for Santa? - Conducting pre-xmas releases: 7.0.6, 7.1.1, 8.0.0-M2

[Mark Struberg]

+1, just ping me if you need some help.

LieGrue,
strub

> Am 13.12.2018 um 17:57 schrieb Jonathan Gallimore 
> :
> 
> There's some stuff I need to finish backporting, but I'm generally in
> favour. We have a Johnzon vote in progress, and could do with an OWB
> release for the 7.0.x and 7.1.x branches.
> 
> Jon
> 
> On Thu, Dec 13, 2018 at 12:16 PM Wiesner, Martin <
> martin.wies...@hs-heilbronn.de> wrote:
> 
>> Hey guys,
>> 
>> Richard (Z, @rzo1) and me are having some coffee in the office and are
>> discussing several ideas. One them is that we’d like to propose that TomEE
>> project kicks out a pre-xmas release for 7.1.1 and/or 7.0.6, and even more
>> interesting: a 8.0.0-M2 milestone preview.
>> 
>> The rationale behind it is that we all might get (more) valuable feedback
>> on the current state by the TomEE community. With many bugs fixed and
>> improvements made recently, it might be worth considering such a step.
>> 
>> What do you all think of our proposal? Any opinions much welcome.
>> 
>> Best
>> Martin
>> --
>> https://twitter.com/mawiesne
>> 
>> 

Re: Java 11 status

[Mark Struberg]

 The problem is that the unit tests in OpenJPA do not pass with the old pool. 
So for getting OpenJPA-3.0.1 we need commons-pool. 
OpenJPA-3.0.0 still uses xbean-asm6. Means different package.We would need to 
package both xbean-asm6 and xbean-asm7 if we want to ship TomEE with 
OpenJPA-3.0.0.
LieGrue,strub

On Saturday, 10 November 2018, 22:52:48 CET, Jean-Louis Monteiro 
 wrote:  
 
 Agreed. Probably we don't need to wait for it. At least we could do a M2
which is Java 11 ready.



Le sam. 10 nov. 2018 à 21:49, Romain Manni-Bucau  a
écrit :

> Shouldnt be the case Mark since openjpa is not bound to a pool - except in
> tests - and tomee default pool is not dbcp2 but tomcat-jdbc. So it is not a
> requirement but more a nice to have IMHO. Also not a regression since last
> release so not a blocker ;).
>
>
> Le sam. 10 nov. 2018 21:02, Mark Struberg  a
> écrit :
>
> >  We also need to wait for commons-pool and commons-dbcp. I fixed a
> > deadlock in the pool.Only after that I'll be able to release OpenJPA.
> > LieGrue,strub
> >
> >    On Friday, 9 November 2018, 21:02:13 CET, Mark Struberg
> >  wrote:
> >
> >  Right now I do a lot of OpenJPA hacking.
> > One of the tasks is to also support xbean-asm7.
> > That should go into openjpa-3.0.1.
> >
> > What is the timeframe we want to target?
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.11.2018 um 14:18 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >:
> > >
> > > I don't have the list handy but tomee will need at least some
> --add-opens
> > > etc to run on java11 (you can add it in setenv.sh) - likely for unsafe
> > and
> > > the agent.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> > >
> > >
> > > Le ven. 9 nov. 2018 à 14:09, Thomas Andraschko <
> > andraschko.tho...@gmail.com>
> > > a écrit :
> > >
> > >> (e.g. Tomcat and DeltaSpike still uses the old namespace it's in
> > >> web/beans.xml)
> > >>
> > >> Am Fr., 9. Nov. 2018 um 13:35 Uhr schrieb Thomas Andraschko <
> > >> andraschko.tho...@gmail.com>:
> > >>
> > >>> Also looks like XML unmarshalling is broken:
> > >>>
> > >>> Caused by: javax.xml.bind.UnmarshalException: unerwartetes Element
> > (URI:"
> > >>> http://java.sun.com/xml/ns/javaee;, lokal:"interceptors"). Erwartete
> > >>> Elemente
> > >>> sind
> <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
> > >>>    at
> > >>>
> > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
> > >>> (UnmarshallingContext.java:744)
> > >>>    at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> > >>> (Loader.java:262)
> > >>>    at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
> > >>> (Loader.java:257)
> > >>>    at
> > >>>
> > >>
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
> > >>> (Loader.java:124)
> > >>>    at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
> > >>> (Loader.java:105)
> > >>>    at
> > >>> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
> > >>> (StructureLoader.java:268)
> > >>>    at
> > >>>
> > >>
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
> > >>> (UnmarshallingContext.java:574)
> > >>>    at
> > >>>
> > >>
> >
> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
> > >>> (UnmarshallingContext.java:556)
> > >>>    at
> > com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
> > >>> (SAXConnector.java:168)
> > >>>    at org.xml.sax.helpers.XMLFilterImpl.startElement
> > >>> (XMLFilterImpl.

Re: Java 11 status

[Mark Struberg]

 We also need to wait for commons-pool and commons-dbcp. I fixed a deadlock in 
the pool.Only after that I'll be able to release OpenJPA.
LieGrue,strub

On Friday, 9 November 2018, 21:02:13 CET, Mark Struberg 
 wrote:  
 
 Right now I do a lot of OpenJPA hacking.
One of the tasks is to also support xbean-asm7.
That should go into openjpa-3.0.1.

What is the timeframe we want to target?

LieGrue,
strub


> Am 09.11.2018 um 14:18 schrieb Romain Manni-Bucau :
> 
> I don't have the list handy but tomee will need at least some --add-opens
> etc to run on java11 (you can add it in setenv.sh) - likely for unsafe and
> the agent.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> Le ven. 9 nov. 2018 à 14:09, Thomas Andraschko 
> a écrit :
> 
>> (e.g. Tomcat and DeltaSpike still uses the old namespace it's in
>> web/beans.xml)
>> 
>> Am Fr., 9. Nov. 2018 um 13:35 Uhr schrieb Thomas Andraschko <
>> andraschko.tho...@gmail.com>:
>> 
>>> Also looks like XML unmarshalling is broken:
>>> 
>>> Caused by: javax.xml.bind.UnmarshalException: unerwartetes Element (URI:"
>>> http://java.sun.com/xml/ns/javaee;, lokal:"interceptors"). Erwartete
>>> Elemente
>>> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
>>>    at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
>>> (UnmarshallingContext.java:744)
>>>    at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
>>> (Loader.java:262)
>>>    at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
>>> (Loader.java:257)
>>>    at
>>> 
>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
>>> (Loader.java:124)
>>>    at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
>>> (Loader.java:105)
>>>    at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
>>> (StructureLoader.java:268)
>>>    at
>>> 
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
>>> (UnmarshallingContext.java:574)
>>>    at
>>> 
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
>>> (UnmarshallingContext.java:556)
>>>    at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
>>> (SAXConnector.java:168)
>>>    at org.xml.sax.helpers.XMLFilterImpl.startElement
>>> (XMLFilterImpl.java:551)
>>>    at
>>> org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
>>> (JaxbJavaee.java:293)
>>>    at
>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
>>> (AbstractSAXParser.java:510)
>>>    at
>>> 
>> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
>>> (XMLNSDocumentScannerImpl.java:374)
>>>    at
>>> 
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
>>> (XMLDocumentFragmentScannerImpl.java:2708)
>>>    at
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
>>> (XMLDocumentScannerImpl.java:605)
>>>    at
>>> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
>>> (XMLNSDocumentScannerImpl.java:112)
>>>    at
>>> 
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
>>> (XMLDocumentFragmentScannerImpl.java:534)
>>>    at
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
>>> (XML11Configuration.java:888)
>>>    at
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
>>> (XML11Configuration.java:824)
>>>    at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
>>> (XMLParser.java:141)
>>>    at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
>>> (AbstractSAXParser.java:1216)
>>>    at
>>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
>>> (SAXParserImpl.java:635)
>>>    at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
>>>    at
>&

Re: Java 11 status

[Mark Struberg]

Right now I do a lot of OpenJPA hacking.
One of the tasks is to also support xbean-asm7.
That should go into openjpa-3.0.1.

What is the timeframe we want to target?

LieGrue,
strub


> Am 09.11.2018 um 14:18 schrieb Romain Manni-Bucau :
> 
> I don't have the list handy but tomee will need at least some --add-opens
> etc to run on java11 (you can add it in setenv.sh) - likely for unsafe and
> the agent.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le ven. 9 nov. 2018 à 14:09, Thomas Andraschko 
> a écrit :
> 
>> (e.g. Tomcat and DeltaSpike still uses the old namespace it's in
>> web/beans.xml)
>> 
>> Am Fr., 9. Nov. 2018 um 13:35 Uhr schrieb Thomas Andraschko <
>> andraschko.tho...@gmail.com>:
>> 
>>> Also looks like XML unmarshalling is broken:
>>> 
>>> Caused by: javax.xml.bind.UnmarshalException: unerwartetes Element (URI:"
>>> http://java.sun.com/xml/ns/javaee;, lokal:"interceptors"). Erwartete
>>> Elemente
>>> sind <{}trim>,<{}decorators>,<{}scan>,<{}alternatives>,<{}interceptors>
>>>at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent
>>> (UnmarshallingContext.java:744)
>>>at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
>>> (Loader.java:262)
>>>at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportError
>>> (Loader.java:257)
>>>at
>>> 
>> com.sun.xml.bind.v2.runtime.unmarshaller.Loader.reportUnexpectedChildElement
>>> (Loader.java:124)
>>>at com.sun.xml.bind.v2.runtime.unmarshaller.Loader.childElement
>>> (Loader.java:105)
>>>at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.StructureLoader.childElement
>>> (StructureLoader.java:268)
>>>at
>>> 
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement
>>> (UnmarshallingContext.java:574)
>>>at
>>> 
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement
>>> (UnmarshallingContext.java:556)
>>>at com.sun.xml.bind.v2.runtime.unmarshaller.SAXConnector.startElement
>>> (SAXConnector.java:168)
>>>at org.xml.sax.helpers.XMLFilterImpl.startElement
>>> (XMLFilterImpl.java:551)
>>>at
>>> org.apache.openejb.jee.JaxbJavaee$JavaeeNamespaceFilter.startElement
>>> (JaxbJavaee.java:293)
>>>at
>>> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement
>>> (AbstractSAXParser.java:510)
>>>at
>>> 
>> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement
>>> (XMLNSDocumentScannerImpl.java:374)
>>>at
>>> 
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next
>>> (XMLDocumentFragmentScannerImpl.java:2708)
>>>at
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
>>> (XMLDocumentScannerImpl.java:605)
>>>at
>>> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next
>>> (XMLNSDocumentScannerImpl.java:112)
>>>at
>>> 
>> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument
>>> (XMLDocumentFragmentScannerImpl.java:534)
>>>at
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
>>> (XML11Configuration.java:888)
>>>at
>> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
>>> (XML11Configuration.java:824)
>>>at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
>>> (XMLParser.java:141)
>>>at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
>>> (AbstractSAXParser.java:1216)
>>>at
>>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse
>>> (SAXParserImpl.java:635)
>>>at org.xml.sax.helpers.XMLFilterImpl.parse (XMLFilterImpl.java:357)
>>>at
>>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0
>>> (UnmarshallerImpl.java:258)
>>>at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
>>> (UnmarshallerImpl.java:236)
>>>at
>> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal
>>> (UnmarshallerImpl.java:288)
>>>at org.apache.openejb.jee.JaxbJavaee.unmarshalJavaee
>>> (JaxbJavaee.java:133)
>>>at org.apache.openejb.config.ReadDescriptors.readBeans
>>> (ReadDescriptors.java:691)
>>>at org.apache.openejb.config.DeploymentLoader.mergeBeansXml
>>> (DeploymentLoader.java:1196)
>>>at org.apache.openejb.config.DeploymentLoader.addBeansXmls
>>> (DeploymentLoader.java:1184)
>>>at org.apache.openejb.config.DeploymentLoader.createWebModule
>>> (DeploymentLoader.java:1098)
>>>at org.apache.openejb.config.DeploymentLoader.createWebModule
>>> (DeploymentLoader.java:823)
>>>at org.apache.openejb.config.DeploymentLoader.load
>>> (DeploymentLoader.java:234)
>>>at 

Re: [VOTE][RESULT] Release Apache TomEE 8.0.0 MILESTONE 1

[Mark Struberg]

Btw Romain is technically still PMC member as the board didn't yet ack his 
removal.
So we even have 5 binding +1  :D

LieGrue,
strub

> Am 19.10.2018 um 17:19 schrieb Roberto Cortez :
> 
> Hi,
> 
> Yeah. Sorry, I was travelling.
> 
> Here are the votes:
> 
> + 1 Binding: David, Jean Louis, Mark and Jon.
> +1 Non Binding: Romain, César, Richard, Matthew, Roberto
> 
> And the vote PASSES! :)
> 
> Thank you everyone for participating. I will proceed now with the remaining 
> tasks to promote the release.
> 
> Cheers,
> Roberto 
> 
>> On 19 Oct 2018, at 11:46, Jonathan Gallimore  
>> wrote:
>> 
>> +1. Let me know if I can help at all.
>> 
>> On Fri, Oct 19, 2018 at 11:30 AM Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> wrote:
>> 
>>> Maybe time to close the vote and promote the staging repo?
>>> 
>>> 
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>> 
>>> 
>>> On Thu, Oct 18, 2018 at 11:30 AM Mark Struberg 
>>> wrote:
>>> 
>>>> +1
>>>> looks good enough for a first release ;)
>>>> 
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>>>> 
>>>>> Am 17.10.2018 um 18:31 schrieb Mark Struberg >>>> :
>>>>> 
>>>>> On travel, will review tonight.
>>>>> 
>>>>> Sent with autocorrect...
>>>>> 
>>>>>> On 17.10.2018, at 16:05, Richard Monson-Haefel <
>>> monsonhae...@gmail.com>
>>>> wrote:
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>> On Tue, Oct 16, 2018 at 3:29 PM Jonathan Gallimore <
>>>>>> jonathan.gallim...@gmail.com> wrote:
>>>>>> 
>>>>>>> +1
>>>>>>> 
>>>>>>> Many thanks for working on the release Roberto!
>>>>>>> 
>>>>>>> Jon
>>>>>>> 
>>>>>>> On Mon, Oct 15, 2018 at 1:13 AM Roberto Cortez
>>>> >>>>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi everyone,
>>>>>>>> 
>>>>>>>> I’ve tried to push all the required stuff to have a Milestone
>>> version
>>>>>>>> release of TomEE 8. Please, realize that this is no way a FINAL
>>>> release
>>>>>>> and
>>>>>>>> it doesn’t need to be perfect. We may have several Milestone
>>> versions
>>>>>>> until
>>>>>>>> we reach a Final one.
>>>>>>>> 
>>>>>>>> Some of us, are doing sessions on Oracle Code One next week, so it
>>>> would
>>>>>>>> be nice if we could use an actual release instead of a SNAPSHOT.
>>>>>>>> 
>>>>>>>> For this, I’ve released 3 projects: Java EE 8 API, a patched version
>>>> of
>>>>>>>> BVal2 with our groupId and TomEE itself.
>>>>>>>> 
>>>>>>>> Staging Repos:
>>>>>>>> 
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1124 <
>>>>>>>> 
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1124>
>>>>>>>> (EE8 API)
>>>>>>>> 
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1125 <
>>>>>>>> 
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1125>
>>>>>>>> (BVal 2)
>>>>>>>> 
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1127 <
>>>>>>>> 
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1127>
>>>>>>>> (TomEE)
>>>>>>>> 
>>>>>>>> Source:
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/javaee-api-8.0-source-release.zip
>>>>>>>> <
>>>>>>>> 
>>>>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/javaee-api-8.0-source

Re: [VOTE] Release Apache TomEE 8.0.0 MILESTONE 1

[Mark Struberg]

+1
looks good enough for a first release ;)


LieGrue,
strub


> Am 17.10.2018 um 18:31 schrieb Mark Struberg :
> 
> On travel, will review tonight.
> 
> Sent with autocorrect...
> 
>> On 17.10.2018, at 16:05, Richard Monson-Haefel  
>> wrote:
>> 
>> +1
>> 
>> On Tue, Oct 16, 2018 at 3:29 PM Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>> 
>>> +1
>>> 
>>> Many thanks for working on the release Roberto!
>>> 
>>> Jon
>>> 
>>> On Mon, Oct 15, 2018 at 1:13 AM Roberto Cortez >>> 
>>> wrote:
>>> 
>>>> Hi everyone,
>>>> 
>>>> I’ve tried to push all the required stuff to have a Milestone version
>>>> release of TomEE 8. Please, realize that this is no way a FINAL release
>>> and
>>>> it doesn’t need to be perfect. We may have several Milestone versions
>>> until
>>>> we reach a Final one.
>>>> 
>>>> Some of us, are doing sessions on Oracle Code One next week, so it would
>>>> be nice if we could use an actual release instead of a SNAPSHOT.
>>>> 
>>>> For this, I’ve released 3 projects: Java EE 8 API, a patched version of
>>>> BVal2 with our groupId and TomEE itself.
>>>> 
>>>> Staging Repos:
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1124 <
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1124>
>>>> (EE8 API)
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1125 <
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1125>
>>>> (BVal 2)
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1127 <
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1127>
>>>> (TomEE)
>>>> 
>>>> Source:
>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/javaee-api-8.0-source-release.zip
>>>> <
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/javaee-api-8.0-source-release.zip
>>>>> 
>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/bval-parent-2.0.0-nonfinal-57300f3-source-release.zip
>>>> <
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/bval-parent-2.0.0-nonfinal-57300f3-source-release.zip
>>>>> 
>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/tomee-project-8.0.0-M1-source-release.zip
>>>> <
>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/tomee-project-8.0.0-M1-source-release.zip
>>>>> 
>>>> 
>>>> Dist Area:
>>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/ <
>>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/>
>>>> 
>>>> JIRA:
>>>> https://issues.apache.org/jira/projects/TOMEE/versions/12341354 <
>>>> https://issues.apache.org/jira/projects/TOMEE/versions/12341354>
>>>> 
>>>> Unfortunately, I was not able to add my key to the KEYS files. I believe
>>>> someone on the PMC needs to do it, but I did upload it to
>>>> http://pgp.mit.edu/ <http://pgp.mit.edu/>, where Nexus checks for the
>>>> keys when closing the repo. Here is the direct url:
>>>> http://pgp.mit.edu/pks/lookup?op=vindex=0x3D4683C24EDC64D1 <
>>>> http://pgp.mit.edu/pks/lookup?op=vindex=0x3D4683C24EDC64D1>
>>>> 
>>>> A special thanks to Jon, for helping me out through the process! Thank
>>> you!
>>>> 
>>>> Please vote:
>>>> +1: Release
>>>> 0: I don’t care
>>>> -1 Do not release because ...
>>>> 
>>>> The vote will be open for 3 days or the consensus is binding (At least 3
>>>> binding votes).
>>>> 
>>>> Cheers,
>>>> Roberto
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
> 

Re: [VOTE] Release Apache TomEE 8.0.0 MILESTONE 1

[Mark Struberg]

On travel, will review tonight.

Sent with autocorrect...

> On 17.10.2018, at 16:05, Richard Monson-Haefel  wrote:
> 
> +1
> 
> On Tue, Oct 16, 2018 at 3:29 PM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> +1
>> 
>> Many thanks for working on the release Roberto!
>> 
>> Jon
>> 
>> On Mon, Oct 15, 2018 at 1:13 AM Roberto Cortez >> 
>> wrote:
>> 
>>> Hi everyone,
>>> 
>>> I’ve tried to push all the required stuff to have a Milestone version
>>> release of TomEE 8. Please, realize that this is no way a FINAL release
>> and
>>> it doesn’t need to be perfect. We may have several Milestone versions
>> until
>>> we reach a Final one.
>>> 
>>> Some of us, are doing sessions on Oracle Code One next week, so it would
>>> be nice if we could use an actual release instead of a SNAPSHOT.
>>> 
>>> For this, I’ve released 3 projects: Java EE 8 API, a patched version of
>>> BVal2 with our groupId and TomEE itself.
>>> 
>>> Staging Repos:
>>> https://repository.apache.org/content/repositories/orgapachetomee-1124 <
>>> https://repository.apache.org/content/repositories/orgapachetomee-1124>
>>> (EE8 API)
>>> https://repository.apache.org/content/repositories/orgapachetomee-1125 <
>>> https://repository.apache.org/content/repositories/orgapachetomee-1125>
>>> (BVal 2)
>>> https://repository.apache.org/content/repositories/orgapachetomee-1127 <
>>> https://repository.apache.org/content/repositories/orgapachetomee-1127>
>>> (TomEE)
>>> 
>>> Source:
>>> 
>>> 
>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/javaee-api-8.0-source-release.zip
>>> <
>>> 
>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/javaee-api-8.0-source-release.zip
 
>>> 
>>> 
>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/bval-parent-2.0.0-nonfinal-57300f3-source-release.zip
>>> <
>>> 
>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/bval-parent-2.0.0-nonfinal-57300f3-source-release.zip
 
>>> 
>>> 
>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/tomee-project-8.0.0-M1-source-release.zip
>>> <
>>> 
>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/tomee-project-8.0.0-M1-source-release.zip
 
>>> 
>>> Dist Area:
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/ <
>>> https://dist.apache.org/repos/dist/dev/tomee/tomee-8.0.0-M1/>
>>> 
>>> JIRA:
>>> https://issues.apache.org/jira/projects/TOMEE/versions/12341354 <
>>> https://issues.apache.org/jira/projects/TOMEE/versions/12341354>
>>> 
>>> Unfortunately, I was not able to add my key to the KEYS files. I believe
>>> someone on the PMC needs to do it, but I did upload it to
>>> http://pgp.mit.edu/ , where Nexus checks for the
>>> keys when closing the repo. Here is the direct url:
>>> http://pgp.mit.edu/pks/lookup?op=vindex=0x3D4683C24EDC64D1 <
>>> http://pgp.mit.edu/pks/lookup?op=vindex=0x3D4683C24EDC64D1>
>>> 
>>> A special thanks to Jon, for helping me out through the process! Thank
>> you!
>>> 
>>> Please vote:
>>> +1: Release
>>> 0: I don’t care
>>> -1 Do not release because ...
>>> 
>>> The vote will be open for 3 days or the consensus is binding (At least 3
>>> binding votes).
>>> 
>>> Cheers,
>>> Roberto
>>> 
>>> 
>>> 
>>> 
>> 

Re: TomEE8 / Upgrade MyFaces

[Mark Struberg]

+1

LieGrue,
strub

> Am 09.10.2018 um 09:42 schrieb Thomas Andraschko 
> :
> 
> Hi,
> 
> i read on the BVal mailing list, that you would like to release TomEE8 soon.
> Could someone update MyFaces to the latest release? (
> https://issues.apache.org/jira/browse/TOMEE-2236)
> It's quite important as it contains many fixes.
> 
> Thanks.
> 
> Best Regards,
> Thomas

Re: How to release snapshot dependencies in a TomEE release (Re: TomEE 8 Release Notes Preview)

[Mark Struberg]

The primary way should imo ALWAYS to help the other projects we rely on to get 
the releases out.
Falling back on a tomee internal release is only a last effort if the other 
projects are not responsible.

LieGrue,
strub


> Am 28.09.2018 um 23:50 schrieb David Blevins :
> 
>> On Sep 28, 2018, at 3:00 AM, Roberto Cortez  
>> wrote:
>> 
>> While we wait for the official BVal release, I plan do create a preview 
>> release of TomEE 8 so we can start trying it out and hopefully speed up the 
>> process. Please, let me know if anyone has any feedback.
> 
> As a community we've done ad-hoc releases other projects on a frequent basis 
> when best case scenario (they release their code) doesn't pan out.
> 
> I doug around to try and refresh my own memory.  
> 
> Pre-2013 we would use svn as a maven repo and push builds in with the version 
> number suffixed with the svn version indicating the source.  The groupIds 
> were left the same:
> 
> - https://svn.apache.org/viewvc/openejb/repo/org/apache/xbean/?pathrev=1432803
> 
> This meant we had to include https://svn.apache.org/repos/asf/openejb/repo/ 
> as a repository in the TomEE/OpenEJB pom.xml so we could release.  When the 
> project was renamed to tomee and that path changed to  
> https://svn.apache.org/repos/asf/tomee/repo/ all those old builds broke.
> 
> Post-2013 we would copy the source into our section of svn, update the 
> groupId to ours with ".patch" appended, then add "nonfinal-" to 
> the version number and release it to mvn central.
> 
> - svn log -v http://svn.apache.org/repos/asf/tomee/deps | less
> - 
> https://mvnrepository.com/artifact/org.apache.openejb.patch/openjpa-kernel/2.4.0-nonfinal-1598334
> 
> This would be done as part of the TomEE release that needed them, such that 
> the Nexus staging repo contained both TomEE 1.2.3 and say OpenJPA 
> 2.4.0-nonfinal-1598334.  When the project voted, it'd be voting on all the 
> binaries.  In your case it would be TomEE, BVal and Geronimo validation spec.
> 
> You could potentially do a separate vote for BVal and Geronimo validation 
> spec.  If the project's get their releases up for a vote, great we use those 
> releases for TomEE 8.  If not, we have something to fall back on.  The 
> benefit of this is you would not have to keep rerolling these two each time 
> you have to reroll TomEE 8 release binaries.  I swore we did this once, but I 
> couldn't find the vote thread as I don't recall exactly what artifact it was.
> 
> Anyway, hope this helps.  It likely should be added to our release process 
> documentation.
> 
> 
> -David
> 

[ANNOUNCE] Welcome Roberto Cortez as new Apache TomEE committer

[Mark Struberg]

Good morning ladies and gents!

It's a great pleasure to announce that Roberto Cortez has accepted our 
invitation to become an Apache TomEE committer!

Welcome Roberto!

your Apache TomEE PMC

Re: [VOTE] Release Apache TomEE 7.1.0 (take 2)

[Mark Struberg]

checked with an app.
sigs fine, source zip hash oh, rat ok.

+1

LieGrue,
strub


> Am 03.09.2018 um 23:22 schrieb Jonathan Gallimore 
> :
> 
> Hi Everyone,
> 
> Here is the first roll of TomEE 7.1.0. Please can you take a look and
> vote? Everyone,
> committer or not, is encouraged to test and vote.
> 
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1120
> 
> Source zip:
> https://repository.apache.org/content/repositories/orgapachetomee-1120/org/apache/tomee/tomee-project/7.1.0/tomee-project-7.1.0-source-release.zip
> 
> Dist area:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1120/
> 
> Legal:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1120/legal.zip
> 
> Keys:
> https://dist.apache.org/repos/dist/release/tomee/KEYS
> 
> Please vote:
> +1: Release
> -1 Do not release because ...
> 
> The vote will be open for 3 days or the consensus is binding (At least 3
> binding votes).
> 
> Here is my +1.
> 
> Many thanks
> 
> Jon

Re: [VOTE] Release Apache TomEE 7.1.0

[Mark Struberg]

Is this really a common case?

I'd rather would continue the vote and ship a 7.0.1 shortly afterwards (say 2 
weeks).

That way we can get feedback from users and improve upon it.

LieGrue,
strub


> Am 31.08.2018 um 17:25 schrieb Thiago Veronezi :
> 
> Sweet! Tx!
> 
> []s,
> Thiago.
> 
> 
> 
> On Fri, Aug 31, 2018 at 11:20 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> Assuming we re-roll (which looks likely), yes, I'll include it.
>> 
>> Jon
>> 
>> On Fri, Aug 31, 2018 at 4:12 PM Thiago Veronezi 
>> wrote:
>> 
>>> The change I did for the the Injection of Application seems to be out of
>>> this release. :/
>>> 
>>> 
>>> 
>> https://github.com/apache/tomee/commit/bf929780ae384de305388594c7227c73a3193f9a
>>> https://issues.apache.org/jira/browse/TOMEE-2201
>>> 
>>> Do you mind if we add it to 71x?
>>> 
>>> []s,
>>> Thiago.
>>> 
>>> 
>>> On Fri, Aug 31, 2018 at 11:01 AM Jonathan Gallimore <
>>> jonathan.gallim...@gmail.com> wrote:
>>> 
>>>> Roberto - did you have a test/sample app for this?
>>>> 
>>>> Looks like the microprofile zip is short of a NOTICE file, and that
>> would
>>>> need to include the same notices as webprofile, plus this one:
>>>> 
>>>> (
>>>> 
>>>> 
>>> 
>> https://bitbucket.org/b_c/jose4j/src/7f9624414a1baf752adbc61d4a1be16253eeec23/NOTICE.txt?at=master=file-view-default
>>>> )
>>>> -
>>>> jose4j
>>>> Copyright 2012-2015 Brian Campbell
>>>> 
>>>> EcdsaUsingShaAlgorithm contains code for converting the concatenated
>>>> R & S values of the signature to and from DER, which was originally
>>>> derived from the Apache Santuario XML Security library's SignatureECDSA
>>>> implementation. http://santuario.apache.org/
>>>> 
>>>> The Base64 implementation in this software was derived from the
>>>> Apache Commons Codec project.
>>>> http://commons.apache.org/proper/commons-codec/
>>>> 
>>>> JSON processing in this software was derived from the JSON.simple
>>> toolkit.
>>>> https://code.google.com/p/json-simple/
>>>> -
>>>> 
>>>> Thoughts?
>>>> 
>>>> Other than that I can't see any issues.
>>>> 
>>>> Jon
>>>> 
>>>> 
>>>> On Fri, Aug 31, 2018 at 2:39 PM Jean-Louis Monteiro <
>>>> jlmonte...@tomitribe.com> wrote:
>>>> 
>>>>> +1
>>>>> 
>>>>> Thank you very much Jon for the release and Roberto for the
>>> microprofile
>>>>> work
>>>>> 
>>>>> --
>>>>> Jean-Louis Monteiro
>>>>> http://twitter.com/jlouismonteiro
>>>>> http://www.tomitribe.com
>>>>> 
>>>>> On Fri, Aug 31, 2018 at 1:33 PM, Mark Struberg
>>> >>>> 
>>>>> wrote:
>>>>> 
>>>>>> +1
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> 
>>>>>>> Am 30.08.2018 um 12:24 schrieb Jonathan Gallimore <
>>>>>> jonathan.gallim...@gmail.com>:
>>>>>>> 
>>>>>>> Hi Everyone,
>>>>>>> 
>>>>>>> Here is the first roll of TomEE 7.1.0. Please can you take a look
>>> and
>>>>>>> vote? Everyone,
>>>>>>> committer or not, is encouraged to test and vote.
>>>>>>> 
>>>>>>> Staging repo:
>>>>>>> 
>>>> https://repository.apache.org/content/repositories/orgapachetomee-1119
>>>>>>> 
>>>>>>> Source zip:
>>>>>>> https://repository.apache.org/content/repositories/
>>>>>> orgapachetomee-1119/org/apache/tomee/tomee-project/7.
>>>>>> 1.0/tomee-project-7.1.0-source-release.zip
>>>>>>> 
>>>>>>> Dist area:
>>>>>>> https://dist.apache.org/repos/dist/dev/tomee/staging-1119/
>>>>>>> 
>>>>>>> Legal:
>>>>>>> 
>>> https://dist.apache.org/repos/dist/dev/tomee/staging-1119/legal.zip
>>>>>>> 
>>>>>>> Keys:
>>>>>>> https://dist.apache.org/repos/dist/release/tomee/KEYS
>>>>>>> 
>>>>>>> Please vote:
>>>>>>> +1: Release
>>>>>>> -1 Do not release because ...
>>>>>>> 
>>>>>>> The vote will be open for 3 days or the consensus is binding (At
>>>> least
>>>>> 3
>>>>>>> binding votes).
>>>>>>> 
>>>>>>> Many thanks
>>>>>>> 
>>>>>>> Jon
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: [VOTE] Release Apache TomEE 7.1.0

[Mark Struberg]

+1

LieGrue,
strub


> Am 30.08.2018 um 12:24 schrieb Jonathan Gallimore 
> :
> 
> Hi Everyone,
> 
> Here is the first roll of TomEE 7.1.0. Please can you take a look and
> vote? Everyone,
> committer or not, is encouraged to test and vote.
> 
> Staging repo:
> https://repository.apache.org/content/repositories/orgapachetomee-1119
> 
> Source zip:
> https://repository.apache.org/content/repositories/orgapachetomee-1119/org/apache/tomee/tomee-project/7.1.0/tomee-project-7.1.0-source-release.zip
> 
> Dist area:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1119/
> 
> Legal:
> https://dist.apache.org/repos/dist/dev/tomee/staging-1119/legal.zip
> 
> Keys:
> https://dist.apache.org/repos/dist/release/tomee/KEYS
> 
> Please vote:
> +1: Release
> -1 Do not release because ...
> 
> The vote will be open for 3 days or the consensus is binding (At least 3
> binding votes).
> 
> Many thanks
> 
> Jon

Re: TomEE 8 Release Notes Preview

[Mark Struberg]

yes, fear that.

LieGrue,
strub

> Am 29.08.2018 um 17:59 schrieb Roberto Cortez :
> 
> I did some cleanup.
> 
> Unfortunately, in some cases I don’t have enough permissions to resolve the 
> issues or change the fix version.
> 
> I guess that to have the right permission I would need to be a committer, 
> right?
> 
> Cheers,
> Roberto
> 
>> On 29 Aug 2018, at 10:10, Roberto Cortez  wrote:
>> 
>> Hi David,
>> 
>> Thank you for your detailed email.
>> 
>> I’ll try to cleanup the JIRA issues based on your comments. 
>> 
>> Cheers,
>> Roberto
>> 
>>> On 29 Aug 2018, at 04:21, David Blevins  wrote:
>>> 
>>> First, huge thank you for putting effort into ensuring the release notes 
>>> are clear!  It's an under appreciated and usually thankless job.  However, 
>>> communicating change on a new major version is critical and you just get 
>>> one chance to build excitement.
>>> 
>>> 
 On Aug 28, 2018, at 9:02 AM, Roberto Cortez  
 wrote:
 
 Hi, 
 
 I’m trying to compile a list of things regarding the TomEE 8 Release. 
 Right now, this is our preview for the Release Notes from JIRA:
 
 Bug
>>> 
>>> My memory is perhaps off, but I thought bugs came after New Features and 
>>> Improvements on the generated release notes.  If they haven't in the past, 
>>> we should likely do that for this one.
>>> 
• [TOMEE-2206] - Support for Enum injection in Microprofile JWT
>>> 
>>> I think this is an improvement vs bug. Perhaps even moved to tasks.
>>> 
>>> It's always been a stance of the project that unreleased features can't 
>>> have bugs.  The intent of Bug is to communicate "you may have encountered 
>>> this in a previous release and it is now fixed."  We want user's to be able 
>>> to rely on this meaning.
>>> 
>>> It's natural to want to do it, but here's how I was able to convince myself 
>>> it wasn't the right thing.  This usage of "bug" essentially means, "We 
>>> noticed we weren't quite as done as we thought after the first commit of 
>>> this feature.  It's never been released so you could never have encountered 
>>> it in production and if you are alarmed by it or hopeful it solves a 
>>> problem you had, that'd be silly of you.  It's just an ignorable note that 
>>> we had to continue working on the feature longer than we thought, 
>>> considerately mixed in with critical things that affect your daily life."
>>> 
>>> Once that thought entered my brain, it started changing neural pathways and 
>>> I've been unable to get rid of it.
>>> 
>>> Joking aside, the result for users is that our release notes start to 
>>> become a puzzle of potential misinformation.
>>> 
 New Feature
• [TOMEE-2209] - MicroProfile 1.2 Support
• [TOMEE-2210] - MicroProfile 1.3 Support
• [TOMEE-2211] - MicroProfile 1.2 Support - Configuration 1.1
• [TOMEE-2212] - MicroProfile 1.2 Support - Fault Tolerance 1.0
• [TOMEE-2213] - MicroProfile 1.2 Support - JWT Propagation 1.0
• [TOMEE-2214] - MicroProfile 1.2 Support - Health Check 1.0
• [TOMEE-2215] - MicroProfile 1.2 Support - Metrics 1.0
• [TOMEE-2216] - MicroProfile 1.3 Support - Config 1.2
• [TOMEE-2217] - MicroProfile 1.3 Support - Metrics 1.1
• [TOMEE-2218] - MicroProfile 1.3 Support - Rest Client 1.0
• [TOMEE-2219] - MicroProfile 1.3 Support - Open API 1.0
>>> 
>>> We should yank the duplicate entries and just talk net-net.  People can 
>>> assume Configuration 1.2 also includes 1.1 and 1.0.  If we completely 
>>> implement MicroProfile 1.3, we can say that and not mention 1.2.  If we do 
>>> not fully implement MicroProfile 1.3, the above didn't help me understand 
>>> the status.
>>> 
>>> On the individual MicroProfile specifications, I would not refer to them as 
>>> "MicroProfile 1.3 Support - Config 1.2", but simply "MicroProfile 
>>> Configuration 1.2"
>>> 
>>> - It will search better in Google
>>> 
>>> - Some specs like Metrics 1.0 are in MP 1.2 and 1.3.  Showing it as "MP 
>>> 1.2" could mean it was introduced in 1.2 and hasn't changed in 1.3.  It 
>>> could mean Metrics is at 1.1 in MP 1.3, but we don't implement it yet.  It 
>>> could mean Metrics was removed entirely in MP 1.3 so we only mention it as 
>>> a MP 1.2 feature.  Unless you know enough not to need the release notes, 
>>> you won't know which.
>>> 
>>> You're right in that we need a complete list of other new features, 
>>> particularly our complete Java EE 8 status has to be listed here as well.
>>> 
 Improvement
• [TOMEE-2195] - Compile Error in 
 /src/main/java/org/apache/openejb/config/AnnotationDeployer
>>> 
>>> We should probably move that one to tasks.
>>> 
• [TOMEE-2196] - keyStoreFile Property is Empty in Embedded Container
• [TOMEE-2221] - Use a Jsonb aware JAX-RS Provider
• [TOMEE-] - Enable create-tables for EclipseLink in Moviefun 
 example
• [TOMEE-2224] - update to apache-parent-21 for sha512
>>> 
>>> Picky I 

Re: deploying a TomEE snapshot right now.

[Mark Struberg]

Roberto, did you figure what's wrong after the CXF update?I might find a bit 
time to look into it today as well. Cannot guarantee though.


LieGrue,strub
   On Monday, 27 August 2018, 13:53:37 CEST, Roberto Cortez 
 wrote:  
 
 
The CXF version update it looks like it broke the tests. I'll try to have a 
look.    On Saturday, August 25, 2018, 3:26:56 PM GMT+1, Matthew Broadhead 
 wrote:  
 
 thanks for the link.  so it looks like i can grab the latest binary at 
https://repository.apache.org/content/groups/snapshots/org/apache/tomee/apache-tomee/8.0.0-SNAPSHOT/

On 25/08/18 16:18, Romain Manni-Bucau wrote:
> http://repository.apache.org/snapshots/
>
> Le sam. 25 août 2018 15:55, Matthew Broadhead
>  a écrit :
>
>> where do the snapshots end up?
>>
>> On 24/08/18 22:49, Roberto Cortez wrote:
>>> Thank you!
>>>
>>>> On 24 Aug 2018, at 19:42, Mark Struberg 
>> wrote:
>>>> Sure, just started it. Should be avail in 15 minutes.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>> Am 24.08.2018 um 19:54 schrieb Roberto Cortez
>> :
>>>>> Hi Mark,
>>>>>
>>>>> Can you please deploy an updated snapshot version of BVal as well? The
>> current deployed snapshot doesn’t have the latest fixes to pass the BVal
>> TCK.
>>>>> Thanks!
>>>>>
>>>>> Cheers,
>>>>> Roberto
>>>>>
>>>>>> On 24 Aug 2018, at 13:07, Mark Struberg 
>> wrote:
>>>>>> Yes indeed.
>>>>>>
>>>>>> 8.0.0-SNAPSHOT that is.
>>>>>>
>>>>>> LieGrue,
>>>>>> strub
>>>>>>
>>>>>>> Am 24.08.2018 um 13:55 schrieb Alex The Rocker >> :
>>>>>>> Hi Mark,
>>>>>>>
>>>>>>> Could you please be a little bit more precise on "which next" release
>>>>>>> you're talking about? I've been deploying a snapshot too from 7.0.6
>>>>>>> snapshots repository & successfully test it with Java 11 EA 25,
>>>>>>> including embedded ActiveMQ.
>>>>>>> Are you on your side talking 7.0.6, 7.1 or 8 "next release" ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexandre
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le ven. 24 août 2018 à 13:44, Mark Struberg
>>>>>>>  a écrit :
>>>>>>>> hi folks!
>>>>>>>>
>>>>>>>> I'm right now deploying a TomEE snapshot with the versions which
>> will most probably make it into the next release.
>>>>>>>> Means CXF update, OWB update, Johnzon update + new parent pom.
>>>>>>>>
>>>>>>>> Happy to get feedback!
>>>>>>>>
>>>>>>>> LieGrue,
>>>>>>>> strub
>>