TCK Signature for EL API

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

TCK Signature for EL API

Volodymyr Siedlecki-2
Hello,

It appears the TCK Signature tests will not be relaxed (see 1 & 2),
and I'm wondering how Tomcat will proceed with the bnd annotation in
the EL API? Will it be removed in the next release?

Thank you,

Volodymyr

1) https://github.com/eclipse-ee4j/jakartaee-tck/issues/643 (Scott's
last comment)2) TCK Thread:
https://www.eclipse.org/lists/jakartaee-tck-dev/threads.html#01235
Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

markt
On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> Hello,
>
> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> and I'm wondering how Tomcat will proceed with the bnd annotation in
> the EL API? Will it be removed in the next release?

Currently, there are no plans to change the Tomcat code.

We do run the TCKs but take a pragmatic view of any failures. For
example, the Servlet TCK test that tests setting a context path in
web.xml always fails because Tomcat always overrides any such setting.
The Servlet spec allows this setting to be overridden but the TCK test
doesn't consider the possibility that a container will always do this.
Therefore we simply treat this as an expected failure. Full details for
all the TCKs we run can be found on the Wiki:

https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs

The EL signature test failure is another example of a failure that we
consider can be safely ignored.

Tomcat does not, and has not for many, many years, formally certified
against the Jakarta EE / Java EE TCKs. I am not aware of any user
request at any point in that time to complete formal certification.
Therefore, I expect that Tomcat will continue following its current
pragmatic approach to the TCKs.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

Romain Manni-Bucau
Hi,

AFAIK TomEE will try to be certified and will try to not fork as much as
possible Tomcat code so can be neat to solve it in particular when
relatively easy:

1. compile tomcat classes with bnd as of today
2. run bnd to get the manifest.mf (
3. post process tomcat classes to remove bnd from the .class
4. jar it

should solve the process and does not look crazy compared to what tomcat
already does, no?

Alternative is indeed to drop bnd since the manifest is quite easy to write
manually or with an ant task to filter the version for tomcat case, at
least for spec jars (it is harder for the impl but here bnd is fine).

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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :

> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> > Hello,
> >
> > It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> > and I'm wondering how Tomcat will proceed with the bnd annotation in
> > the EL API? Will it be removed in the next release?
>
> Currently, there are no plans to change the Tomcat code.
>
> We do run the TCKs but take a pragmatic view of any failures. For
> example, the Servlet TCK test that tests setting a context path in
> web.xml always fails because Tomcat always overrides any such setting.
> The Servlet spec allows this setting to be overridden but the TCK test
> doesn't consider the possibility that a container will always do this.
> Therefore we simply treat this as an expected failure. Full details for
> all the TCKs we run can be found on the Wiki:
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
>
> The EL signature test failure is another example of a failure that we
> consider can be safely ignored.
>
> Tomcat does not, and has not for many, many years, formally certified
> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> request at any point in that time to complete formal certification.
> Therefore, I expect that Tomcat will continue following its current
> pragmatic approach to the TCKs.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

markt
I've been playing with this a bit more and it appears we can simply
hard-code the "Require-Capability" header in el-api.jar.bnd

Having taken the time to look at the actual values generated for these
API JARs, this does look like something that would be simple to maintain
manually - especially for the API JARs where adding a new use of
ServiceLoader is likely to happen fairly rarely.

We should be able to remove the Bnd annotation in
- 10.0.x for 10.0.6 onwards
- 9.0.x for 9.0.46 onwards

We'll certainly do this for the API JARs. I think we'll leave it in
place for the implementation JARs

I have a few things on my TODO list at the moment but I don't see why I
shouldn't be able to get this done for the May set of releases.

Mark


On 01/04/2021 08:24, Romain Manni-Bucau wrote:

> Hi,
>
> AFAIK TomEE will try to be certified and will try to not fork as much as
> possible Tomcat code so can be neat to solve it in particular when
> relatively easy:
>
> 1. compile tomcat classes with bnd as of today
> 2. run bnd to get the manifest.mf (
> 3. post process tomcat classes to remove bnd from the .class
> 4. jar it
>
> should solve the process and does not look crazy compared to what tomcat
> already does, no?
>
> Alternative is indeed to drop bnd since the manifest is quite easy to write
> manually or with an ant task to filter the version for tomcat case, at
> least for spec jars (it is harder for the impl but here bnd is fine).
>
> 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :
>
>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
>>> Hello,
>>>
>>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
>>> and I'm wondering how Tomcat will proceed with the bnd annotation in
>>> the EL API? Will it be removed in the next release?
>>
>> Currently, there are no plans to change the Tomcat code.
>>
>> We do run the TCKs but take a pragmatic view of any failures. For
>> example, the Servlet TCK test that tests setting a context path in
>> web.xml always fails because Tomcat always overrides any such setting.
>> The Servlet spec allows this setting to be overridden but the TCK test
>> doesn't consider the possibility that a container will always do this.
>> Therefore we simply treat this as an expected failure. Full details for
>> all the TCKs we run can be found on the Wiki:
>>
>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
>>
>> The EL signature test failure is another example of a failure that we
>> consider can be safely ignored.
>>
>> Tomcat does not, and has not for many, many years, formally certified
>> against the Jakarta EE / Java EE TCKs. I am not aware of any user
>> request at any point in that time to complete formal certification.
>> Therefore, I expect that Tomcat will continue following its current
>> pragmatic approach to the TCKs.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

Jean-Louis MONTEIRO
That's awesome news.

I'm glad it's something that can be achieved without too much effort.
I understand and buy the pragmatic approach.

But at the same time, if we can do a step forward and get even closer to
being certified, that'd be great.

Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <[hidden email]> a écrit :

> I've been playing with this a bit more and it appears we can simply
> hard-code the "Require-Capability" header in el-api.jar.bnd
>
> Having taken the time to look at the actual values generated for these
> API JARs, this does look like something that would be simple to maintain
> manually - especially for the API JARs where adding a new use of
> ServiceLoader is likely to happen fairly rarely.
>
> We should be able to remove the Bnd annotation in
> - 10.0.x for 10.0.6 onwards
> - 9.0.x for 9.0.46 onwards
>
> We'll certainly do this for the API JARs. I think we'll leave it in
> place for the implementation JARs
>
> I have a few things on my TODO list at the moment but I don't see why I
> shouldn't be able to get this done for the May set of releases.
>
> Mark
>
>
> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> > Hi,
> >
> > AFAIK TomEE will try to be certified and will try to not fork as much as
> > possible Tomcat code so can be neat to solve it in particular when
> > relatively easy:
> >
> > 1. compile tomcat classes with bnd as of today
> > 2. run bnd to get the manifest.mf (
> > 3. post process tomcat classes to remove bnd from the .class
> > 4. jar it
> >
> > should solve the process and does not look crazy compared to what tomcat
> > already does, no?
> >
> > Alternative is indeed to drop bnd since the manifest is quite easy to
> write
> > manually or with an ant task to filter the version for tomcat case, at
> > least for spec jars (it is harder for the impl but here bnd is fine).
> >
> > 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :
> >
> >> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> >>> Hello,
> >>>
> >>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> >>> and I'm wondering how Tomcat will proceed with the bnd annotation in
> >>> the EL API? Will it be removed in the next release?
> >>
> >> Currently, there are no plans to change the Tomcat code.
> >>
> >> We do run the TCKs but take a pragmatic view of any failures. For
> >> example, the Servlet TCK test that tests setting a context path in
> >> web.xml always fails because Tomcat always overrides any such setting.
> >> The Servlet spec allows this setting to be overridden but the TCK test
> >> doesn't consider the possibility that a container will always do this.
> >> Therefore we simply treat this as an expected failure. Full details for
> >> all the TCKs we run can be found on the Wiki:
> >>
> >> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> >>
> >> The EL signature test failure is another example of a failure that we
> >> consider can be safely ignored.
> >>
> >> Tomcat does not, and has not for many, many years, formally certified
> >> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> >> request at any point in that time to complete formal certification.
> >> Therefore, I expect that Tomcat will continue following its current
> >> pragmatic approach to the TCKs.
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Jean-Louis
Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

Raymond Auge-3
I just wanted to make a note that removing the annotation will also mean
that the module-info.java will need to be manually managed since bnd also
generated that based on the annotations.

Just FYI,
- Ray

On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <[hidden email]>
wrote:

> That's awesome news.
>
> I'm glad it's something that can be achieved without too much effort.
> I understand and buy the pragmatic approach.
>
> But at the same time, if we can do a step forward and get even closer to
> being certified, that'd be great.
>
> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <[hidden email]> a écrit :
>
> > I've been playing with this a bit more and it appears we can simply
> > hard-code the "Require-Capability" header in el-api.jar.bnd
> >
> > Having taken the time to look at the actual values generated for these
> > API JARs, this does look like something that would be simple to maintain
> > manually - especially for the API JARs where adding a new use of
> > ServiceLoader is likely to happen fairly rarely.
> >
> > We should be able to remove the Bnd annotation in
> > - 10.0.x for 10.0.6 onwards
> > - 9.0.x for 9.0.46 onwards
> >
> > We'll certainly do this for the API JARs. I think we'll leave it in
> > place for the implementation JARs
> >
> > I have a few things on my TODO list at the moment but I don't see why I
> > shouldn't be able to get this done for the May set of releases.
> >
> > Mark
> >
> >
> > On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> > > Hi,
> > >
> > > AFAIK TomEE will try to be certified and will try to not fork as much
> as
> > > possible Tomcat code so can be neat to solve it in particular when
> > > relatively easy:
> > >
> > > 1. compile tomcat classes with bnd as of today
> > > 2. run bnd to get the manifest.mf (
> > > 3. post process tomcat classes to remove bnd from the .class
> > > 4. jar it
> > >
> > > should solve the process and does not look crazy compared to what
> tomcat
> > > already does, no?
> > >
> > > Alternative is indeed to drop bnd since the manifest is quite easy to
> > write
> > > manually or with an ant task to filter the version for tomcat case, at
> > > least for spec jars (it is harder for the impl but here bnd is fine).
> > >
> > > 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :
> > >
> > >> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> > >>> Hello,
> > >>>
> > >>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> > >>> and I'm wondering how Tomcat will proceed with the bnd annotation in
> > >>> the EL API? Will it be removed in the next release?
> > >>
> > >> Currently, there are no plans to change the Tomcat code.
> > >>
> > >> We do run the TCKs but take a pragmatic view of any failures. For
> > >> example, the Servlet TCK test that tests setting a context path in
> > >> web.xml always fails because Tomcat always overrides any such setting.
> > >> The Servlet spec allows this setting to be overridden but the TCK test
> > >> doesn't consider the possibility that a container will always do this.
> > >> Therefore we simply treat this as an expected failure. Full details
> for
> > >> all the TCKs we run can be found on the Wiki:
> > >>
> > >> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> > >>
> > >> The EL signature test failure is another example of a failure that we
> > >> consider can be safely ignored.
> > >>
> > >> Tomcat does not, and has not for many, many years, formally certified
> > >> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> > >> request at any point in that time to complete formal certification.
> > >> Therefore, I expect that Tomcat will continue following its current
> > >> pragmatic approach to the TCKs.
> > >>
> > >> Mark
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> --
> Jean-Louis
>


--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow
Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

markt
On 02/04/2021 13:58, Raymond Augé wrote:
> I just wanted to make a note that removing the annotation will also mean
> that the module-info.java will need to be manually managed since bnd also
> generated that based on the annotations.

That might be more problematic. Sigh. I'll look into that next week.

Mark


>
> Just FYI,
> - Ray
>
> On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <[hidden email]>
> wrote:
>
>> That's awesome news.
>>
>> I'm glad it's something that can be achieved without too much effort.
>> I understand and buy the pragmatic approach.
>>
>> But at the same time, if we can do a step forward and get even closer to
>> being certified, that'd be great.
>>
>> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <[hidden email]> a écrit :
>>
>>> I've been playing with this a bit more and it appears we can simply
>>> hard-code the "Require-Capability" header in el-api.jar.bnd
>>>
>>> Having taken the time to look at the actual values generated for these
>>> API JARs, this does look like something that would be simple to maintain
>>> manually - especially for the API JARs where adding a new use of
>>> ServiceLoader is likely to happen fairly rarely.
>>>
>>> We should be able to remove the Bnd annotation in
>>> - 10.0.x for 10.0.6 onwards
>>> - 9.0.x for 9.0.46 onwards
>>>
>>> We'll certainly do this for the API JARs. I think we'll leave it in
>>> place for the implementation JARs
>>>
>>> I have a few things on my TODO list at the moment but I don't see why I
>>> shouldn't be able to get this done for the May set of releases.
>>>
>>> Mark
>>>
>>>
>>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
>>>> Hi,
>>>>
>>>> AFAIK TomEE will try to be certified and will try to not fork as much
>> as
>>>> possible Tomcat code so can be neat to solve it in particular when
>>>> relatively easy:
>>>>
>>>> 1. compile tomcat classes with bnd as of today
>>>> 2. run bnd to get the manifest.mf (
>>>> 3. post process tomcat classes to remove bnd from the .class
>>>> 4. jar it
>>>>
>>>> should solve the process and does not look crazy compared to what
>> tomcat
>>>> already does, no?
>>>>
>>>> Alternative is indeed to drop bnd since the manifest is quite easy to
>>> write
>>>> manually or with an ant task to filter the version for tomcat case, at
>>>> least for spec jars (it is harder for the impl but here bnd is fine).
>>>>
>>>> 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :
>>>>
>>>>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
>>>>>> Hello,
>>>>>>
>>>>>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
>>>>>> and I'm wondering how Tomcat will proceed with the bnd annotation in
>>>>>> the EL API? Will it be removed in the next release?
>>>>>
>>>>> Currently, there are no plans to change the Tomcat code.
>>>>>
>>>>> We do run the TCKs but take a pragmatic view of any failures. For
>>>>> example, the Servlet TCK test that tests setting a context path in
>>>>> web.xml always fails because Tomcat always overrides any such setting.
>>>>> The Servlet spec allows this setting to be overridden but the TCK test
>>>>> doesn't consider the possibility that a container will always do this.
>>>>> Therefore we simply treat this as an expected failure. Full details
>> for
>>>>> all the TCKs we run can be found on the Wiki:
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
>>>>>
>>>>> The EL signature test failure is another example of a failure that we
>>>>> consider can be safely ignored.
>>>>>
>>>>> Tomcat does not, and has not for many, many years, formally certified
>>>>> against the Jakarta EE / Java EE TCKs. I am not aware of any user
>>>>> request at any point in that time to complete formal certification.
>>>>> Therefore, I expect that Tomcat will continue following its current
>>>>> pragmatic approach to the TCKs.
>>>>>
>>>>> Mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> Jean-Louis
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

Romain Manni-Bucau
Isn't it stable enough to use bcel or asm to write it?

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. 2 avr. 2021 à 16:41, Mark Thomas <[hidden email]> a écrit :

> On 02/04/2021 13:58, Raymond Augé wrote:
> > I just wanted to make a note that removing the annotation will also mean
> > that the module-info.java will need to be manually managed since bnd also
> > generated that based on the annotations.
>
> That might be more problematic. Sigh. I'll look into that next week.
>
> Mark
>
>
> >
> > Just FYI,
> > - Ray
> >
> > On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <[hidden email]>
> > wrote:
> >
> >> That's awesome news.
> >>
> >> I'm glad it's something that can be achieved without too much effort.
> >> I understand and buy the pragmatic approach.
> >>
> >> But at the same time, if we can do a step forward and get even closer to
> >> being certified, that'd be great.
> >>
> >> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <[hidden email]> a écrit :
> >>
> >>> I've been playing with this a bit more and it appears we can simply
> >>> hard-code the "Require-Capability" header in el-api.jar.bnd
> >>>
> >>> Having taken the time to look at the actual values generated for these
> >>> API JARs, this does look like something that would be simple to
> maintain
> >>> manually - especially for the API JARs where adding a new use of
> >>> ServiceLoader is likely to happen fairly rarely.
> >>>
> >>> We should be able to remove the Bnd annotation in
> >>> - 10.0.x for 10.0.6 onwards
> >>> - 9.0.x for 9.0.46 onwards
> >>>
> >>> We'll certainly do this for the API JARs. I think we'll leave it in
> >>> place for the implementation JARs
> >>>
> >>> I have a few things on my TODO list at the moment but I don't see why I
> >>> shouldn't be able to get this done for the May set of releases.
> >>>
> >>> Mark
> >>>
> >>>
> >>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> >>>> Hi,
> >>>>
> >>>> AFAIK TomEE will try to be certified and will try to not fork as much
> >> as
> >>>> possible Tomcat code so can be neat to solve it in particular when
> >>>> relatively easy:
> >>>>
> >>>> 1. compile tomcat classes with bnd as of today
> >>>> 2. run bnd to get the manifest.mf (
> >>>> 3. post process tomcat classes to remove bnd from the .class
> >>>> 4. jar it
> >>>>
> >>>> should solve the process and does not look crazy compared to what
> >> tomcat
> >>>> already does, no?
> >>>>
> >>>> Alternative is indeed to drop bnd since the manifest is quite easy to
> >>> write
> >>>> manually or with an ant task to filter the version for tomcat case, at
> >>>> least for spec jars (it is harder for the impl but here bnd is fine).
> >>>>
> >>>> 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :
> >>>>
> >>>>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> >>>>>> and I'm wondering how Tomcat will proceed with the bnd annotation in
> >>>>>> the EL API? Will it be removed in the next release?
> >>>>>
> >>>>> Currently, there are no plans to change the Tomcat code.
> >>>>>
> >>>>> We do run the TCKs but take a pragmatic view of any failures. For
> >>>>> example, the Servlet TCK test that tests setting a context path in
> >>>>> web.xml always fails because Tomcat always overrides any such
> setting.
> >>>>> The Servlet spec allows this setting to be overridden but the TCK
> test
> >>>>> doesn't consider the possibility that a container will always do
> this.
> >>>>> Therefore we simply treat this as an expected failure. Full details
> >> for
> >>>>> all the TCKs we run can be found on the Wiki:
> >>>>>
> >>>>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> >>>>>
> >>>>> The EL signature test failure is another example of a failure that we
> >>>>> consider can be safely ignored.
> >>>>>
> >>>>> Tomcat does not, and has not for many, many years, formally certified
> >>>>> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> >>>>> request at any point in that time to complete formal certification.
> >>>>> Therefore, I expect that Tomcat will continue following its current
> >>>>> pragmatic approach to the TCKs.
> >>>>>
> >>>>> Mark
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >> --
> >> Jean-Louis
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

markt
In reply to this post by Raymond Auge-3
On 02/04/2021 13:58, Raymond Augé wrote:
> I just wanted to make a note that removing the annotation will also mean
> that the module-info.java will need to be manually managed since bnd also
> generated that based on the annotations.

Good news. I compared the module-info.class files for the EL API jar and
the WebSocket API jar between the 9.0.45 release (that used the
annotation) and a current build from source (that doesn't use the
annotation) and they are identical. On that basis I think we have a
working solution.

Mark


>
> Just FYI,
> - Ray
>
> On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <[hidden email]>
> wrote:
>
>> That's awesome news.
>>
>> I'm glad it's something that can be achieved without too much effort.
>> I understand and buy the pragmatic approach.
>>
>> But at the same time, if we can do a step forward and get even closer to
>> being certified, that'd be great.
>>
>> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <[hidden email]> a écrit :
>>
>>> I've been playing with this a bit more and it appears we can simply
>>> hard-code the "Require-Capability" header in el-api.jar.bnd
>>>
>>> Having taken the time to look at the actual values generated for these
>>> API JARs, this does look like something that would be simple to maintain
>>> manually - especially for the API JARs where adding a new use of
>>> ServiceLoader is likely to happen fairly rarely.
>>>
>>> We should be able to remove the Bnd annotation in
>>> - 10.0.x for 10.0.6 onwards
>>> - 9.0.x for 9.0.46 onwards
>>>
>>> We'll certainly do this for the API JARs. I think we'll leave it in
>>> place for the implementation JARs
>>>
>>> I have a few things on my TODO list at the moment but I don't see why I
>>> shouldn't be able to get this done for the May set of releases.
>>>
>>> Mark
>>>
>>>
>>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
>>>> Hi,
>>>>
>>>> AFAIK TomEE will try to be certified and will try to not fork as much
>> as
>>>> possible Tomcat code so can be neat to solve it in particular when
>>>> relatively easy:
>>>>
>>>> 1. compile tomcat classes with bnd as of today
>>>> 2. run bnd to get the manifest.mf (
>>>> 3. post process tomcat classes to remove bnd from the .class
>>>> 4. jar it
>>>>
>>>> should solve the process and does not look crazy compared to what
>> tomcat
>>>> already does, no?
>>>>
>>>> Alternative is indeed to drop bnd since the manifest is quite easy to
>>> write
>>>> manually or with an ant task to filter the version for tomcat case, at
>>>> least for spec jars (it is harder for the impl but here bnd is fine).
>>>>
>>>> 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :
>>>>
>>>>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
>>>>>> Hello,
>>>>>>
>>>>>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
>>>>>> and I'm wondering how Tomcat will proceed with the bnd annotation in
>>>>>> the EL API? Will it be removed in the next release?
>>>>>
>>>>> Currently, there are no plans to change the Tomcat code.
>>>>>
>>>>> We do run the TCKs but take a pragmatic view of any failures. For
>>>>> example, the Servlet TCK test that tests setting a context path in
>>>>> web.xml always fails because Tomcat always overrides any such setting.
>>>>> The Servlet spec allows this setting to be overridden but the TCK test
>>>>> doesn't consider the possibility that a container will always do this.
>>>>> Therefore we simply treat this as an expected failure. Full details
>> for
>>>>> all the TCKs we run can be found on the Wiki:
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
>>>>>
>>>>> The EL signature test failure is another example of a failure that we
>>>>> consider can be safely ignored.
>>>>>
>>>>> Tomcat does not, and has not for many, many years, formally certified
>>>>> against the Jakarta EE / Java EE TCKs. I am not aware of any user
>>>>> request at any point in that time to complete formal certification.
>>>>> Therefore, I expect that Tomcat will continue following its current
>>>>> pragmatic approach to the TCKs.
>>>>>
>>>>> Mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> --
>> Jean-Louis
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

Raymond Auge-3
Great news! I'm both sad that the annotations caused you pain (the complete
opposite was intended) and happy that you managed to work around the
problem.

It's not by coincidence that BND uses the intermediate state of the
manifest to go between the annotations and the module info. However, I
wasn't sure that this would cover all cases particularly w.r.t. the service
loader handling. However, it appears it does.

Sincerely,
Ray


On Tue, Apr 6, 2021 at 10:39 AM Mark Thomas <[hidden email]> wrote:

> On 02/04/2021 13:58, Raymond Augé wrote:
> > I just wanted to make a note that removing the annotation will also mean
> > that the module-info.java will need to be manually managed since bnd also
> > generated that based on the annotations.
>
> Good news. I compared the module-info.class files for the EL API jar and
> the WebSocket API jar between the 9.0.45 release (that used the
> annotation) and a current build from source (that doesn't use the
> annotation) and they are identical. On that basis I think we have a
> working solution.
>
> Mark
>
>
> >
> > Just FYI,
> > - Ray
> >
> > On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <[hidden email]>
> > wrote:
> >
> >> That's awesome news.
> >>
> >> I'm glad it's something that can be achieved without too much effort.
> >> I understand and buy the pragmatic approach.
> >>
> >> But at the same time, if we can do a step forward and get even closer to
> >> being certified, that'd be great.
> >>
> >> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <[hidden email]> a écrit :
> >>
> >>> I've been playing with this a bit more and it appears we can simply
> >>> hard-code the "Require-Capability" header in el-api.jar.bnd
> >>>
> >>> Having taken the time to look at the actual values generated for these
> >>> API JARs, this does look like something that would be simple to
> maintain
> >>> manually - especially for the API JARs where adding a new use of
> >>> ServiceLoader is likely to happen fairly rarely.
> >>>
> >>> We should be able to remove the Bnd annotation in
> >>> - 10.0.x for 10.0.6 onwards
> >>> - 9.0.x for 9.0.46 onwards
> >>>
> >>> We'll certainly do this for the API JARs. I think we'll leave it in
> >>> place for the implementation JARs
> >>>
> >>> I have a few things on my TODO list at the moment but I don't see why I
> >>> shouldn't be able to get this done for the May set of releases.
> >>>
> >>> Mark
> >>>
> >>>
> >>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> >>>> Hi,
> >>>>
> >>>> AFAIK TomEE will try to be certified and will try to not fork as much
> >> as
> >>>> possible Tomcat code so can be neat to solve it in particular when
> >>>> relatively easy:
> >>>>
> >>>> 1. compile tomcat classes with bnd as of today
> >>>> 2. run bnd to get the manifest.mf (
> >>>> 3. post process tomcat classes to remove bnd from the .class
> >>>> 4. jar it
> >>>>
> >>>> should solve the process and does not look crazy compared to what
> >> tomcat
> >>>> already does, no?
> >>>>
> >>>> Alternative is indeed to drop bnd since the manifest is quite easy to
> >>> write
> >>>> manually or with an ant task to filter the version for tomcat case, at
> >>>> least for spec jars (it is harder for the impl but here bnd is fine).
> >>>>
> >>>> 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a écrit :
> >>>>
> >>>>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> It appears the TCK Signature tests will not be relaxed (see 1 & 2),
> >>>>>> and I'm wondering how Tomcat will proceed with the bnd annotation in
> >>>>>> the EL API? Will it be removed in the next release?
> >>>>>
> >>>>> Currently, there are no plans to change the Tomcat code.
> >>>>>
> >>>>> We do run the TCKs but take a pragmatic view of any failures. For
> >>>>> example, the Servlet TCK test that tests setting a context path in
> >>>>> web.xml always fails because Tomcat always overrides any such
> setting.
> >>>>> The Servlet spec allows this setting to be overridden but the TCK
> test
> >>>>> doesn't consider the possibility that a container will always do
> this.
> >>>>> Therefore we simply treat this as an expected failure. Full details
> >> for
> >>>>> all the TCKs we run can be found on the Wiki:
> >>>>>
> >>>>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> >>>>>
> >>>>> The EL signature test failure is another example of a failure that we
> >>>>> consider can be safely ignored.
> >>>>>
> >>>>> Tomcat does not, and has not for many, many years, formally certified
> >>>>> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> >>>>> request at any point in that time to complete formal certification.
> >>>>> Therefore, I expect that Tomcat will continue following its current
> >>>>> pragmatic approach to the TCKs.
> >>>>>
> >>>>> Mark
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >> --
> >> Jean-Louis
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow
Reply | Threaded
Open this post in threaded view
|

Re: TCK Signature for EL API

Martin Grigorov
Hi,

On Tue, Apr 6, 2021 at 7:22 PM Raymond Augé
<[hidden email]> wrote:

> Great news! I'm both sad that the annotations caused you pain (the complete
> opposite was intended) and happy that you managed to work around the
> problem.
>
> It's not by coincidence that BND uses the intermediate state of the
> manifest to go between the annotations and the module info. However, I
> wasn't sure that this would cover all cases particularly w.r.t. the service
> loader handling. However, it appears it does.
>

I am not sure how exactly BND works but at [1] I see that ServiceConsumer
annotation has retention policy CLASS.
Would it be possible to use SOURCE instead ? This way at compile time it
could be used to generate module-info.class and be discarded, i.e. the
annotation won't be in the API .class


1.
https://github.com/bndtools/bnd/blob/ba0bd37c2c33afe4ccfd8660b1a37b1c1ac52eaa/biz.aQute.bnd.annotation/src/aQute/bnd/annotation/spi/ServiceConsumer.java#L33


>
> Sincerely,
> Ray
>
>
> On Tue, Apr 6, 2021 at 10:39 AM Mark Thomas <[hidden email]> wrote:
>
> > On 02/04/2021 13:58, Raymond Augé wrote:
> > > I just wanted to make a note that removing the annotation will also
> mean
> > > that the module-info.java will need to be manually managed since bnd
> also
> > > generated that based on the annotations.
> >
> > Good news. I compared the module-info.class files for the EL API jar and
> > the WebSocket API jar between the 9.0.45 release (that used the
> > annotation) and a current build from source (that doesn't use the
> > annotation) and they are identical. On that basis I think we have a
> > working solution.
> >
> > Mark
> >
> >
> > >
> > > Just FYI,
> > > - Ray
> > >
> > > On Thu, Apr 1, 2021 at 4:40 AM Jean-Louis MONTEIRO <[hidden email]
> >
> > > wrote:
> > >
> > >> That's awesome news.
> > >>
> > >> I'm glad it's something that can be achieved without too much effort.
> > >> I understand and buy the pragmatic approach.
> > >>
> > >> But at the same time, if we can do a step forward and get even closer
> to
> > >> being certified, that'd be great.
> > >>
> > >> Le jeu. 1 avr. 2021 à 10:06, Mark Thomas <[hidden email]> a écrit :
> > >>
> > >>> I've been playing with this a bit more and it appears we can simply
> > >>> hard-code the "Require-Capability" header in el-api.jar.bnd
> > >>>
> > >>> Having taken the time to look at the actual values generated for
> these
> > >>> API JARs, this does look like something that would be simple to
> > maintain
> > >>> manually - especially for the API JARs where adding a new use of
> > >>> ServiceLoader is likely to happen fairly rarely.
> > >>>
> > >>> We should be able to remove the Bnd annotation in
> > >>> - 10.0.x for 10.0.6 onwards
> > >>> - 9.0.x for 9.0.46 onwards
> > >>>
> > >>> We'll certainly do this for the API JARs. I think we'll leave it in
> > >>> place for the implementation JARs
> > >>>
> > >>> I have a few things on my TODO list at the moment but I don't see
> why I
> > >>> shouldn't be able to get this done for the May set of releases.
> > >>>
> > >>> Mark
> > >>>
> > >>>
> > >>> On 01/04/2021 08:24, Romain Manni-Bucau wrote:
> > >>>> Hi,
> > >>>>
> > >>>> AFAIK TomEE will try to be certified and will try to not fork as
> much
> > >> as
> > >>>> possible Tomcat code so can be neat to solve it in particular when
> > >>>> relatively easy:
> > >>>>
> > >>>> 1. compile tomcat classes with bnd as of today
> > >>>> 2. run bnd to get the manifest.mf (
> > >>>> 3. post process tomcat classes to remove bnd from the .class
> > >>>> 4. jar it
> > >>>>
> > >>>> should solve the process and does not look crazy compared to what
> > >> tomcat
> > >>>> already does, no?
> > >>>>
> > >>>> Alternative is indeed to drop bnd since the manifest is quite easy
> to
> > >>> write
> > >>>> manually or with an ant task to filter the version for tomcat case,
> at
> > >>>> least for spec jars (it is harder for the impl but here bnd is
> fine).
> > >>>>
> > >>>> 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 jeu. 1 avr. 2021 à 09:19, Mark Thomas <[hidden email]> a
> écrit :
> > >>>>
> > >>>>> On 31/03/2021 20:14, Volodymyr Siedlecki wrote:
> > >>>>>> Hello,
> > >>>>>>
> > >>>>>> It appears the TCK Signature tests will not be relaxed (see 1 &
> 2),
> > >>>>>> and I'm wondering how Tomcat will proceed with the bnd annotation
> in
> > >>>>>> the EL API? Will it be removed in the next release?
> > >>>>>
> > >>>>> Currently, there are no plans to change the Tomcat code.
> > >>>>>
> > >>>>> We do run the TCKs but take a pragmatic view of any failures. For
> > >>>>> example, the Servlet TCK test that tests setting a context path in
> > >>>>> web.xml always fails because Tomcat always overrides any such
> > setting.
> > >>>>> The Servlet spec allows this setting to be overridden but the TCK
> > test
> > >>>>> doesn't consider the possibility that a container will always do
> > this.
> > >>>>> Therefore we simply treat this as an expected failure. Full details
> > >> for
> > >>>>> all the TCKs we run can be found on the Wiki:
> > >>>>>
> > >>>>> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
> > >>>>>
> > >>>>> The EL signature test failure is another example of a failure that
> we
> > >>>>> consider can be safely ignored.
> > >>>>>
> > >>>>> Tomcat does not, and has not for many, many years, formally
> certified
> > >>>>> against the Jakarta EE / Java EE TCKs. I am not aware of any user
> > >>>>> request at any point in that time to complete formal certification.
> > >>>>> Therefore, I expect that Tomcat will continue following its current
> > >>>>> pragmatic approach to the TCKs.
> > >>>>>
> > >>>>> Mark
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: [hidden email]
> > >>>>> For additional commands, e-mail: [hidden email]
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: [hidden email]
> > >>> For additional commands, e-mail: [hidden email]
> > >>>
> > >>>
> > >>
> > >> --
> > >> Jean-Louis
> > >>
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> --
> *Raymond Augé* (@rotty3000)
> Senior Software Architect *Liferay, Inc.* (@Liferay)
> OSGi Fellow
>