Doubt translation Spanish

[Evaldo Junior]

I have a doubt about the translation in spanish language, for the
translation in portguese exists in the Jira a master task, Translate
examples into Portuguese [Main Task], follow the link
https://issues.apache.org/jira/browse/TOMEE-2473.
 The new tasks for this,
are subtaks createds under the master task.
In the case of the spanish translation, exists a master task, or no. If
exists, please what the number of the master task of the spanish
translations ?


Regards,


Evaldo Junior

Re: [TCK] Servlet - Server push

[David Blevins]

Merged!

What an amazing end to the Jakarta EE 9 release day :)


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Dec 8, 2020, at 5:18 PM, Thiago Henrique Hupner  wrote:
> 
> Sure! I'll do right away
> 
> Em ter., 8 de dez. de 2020 às 22:17, David Blevins 
> escreveu:
> 
>>> On Dec 8, 2020, at 5:07 PM, David Blevins 
>> wrote:
>>> 
>>> PR merged :)
>>> 
>>> - https://github.com/apache/tomee-tck/pull/13
>>> 
>>> Thank you much, Thiago!  So amazing to see this kind of activity.  You
>> rock, Thiago!
>> 
>> Oh, we have another branch for the Jakarta EE 9 TCK here:
>> 
>> - https://github.com/apache/tomee-tck/tree/jakartaee9-tck
>> 
>> If you're up for pulling that commit over and submitting another PR,
>> awesome!  Otherwise I'll do a cherry pick tomorrow.
>> 
>> -David
>> 
>>> 
 On Dec 8, 2020, at 4:36 PM, David Blevins 
>> wrote:
 
 Wow, I did not expect to get an email like this so fast :)   It's
>> awesome.
 
 We build the ts.jte file dynamically in Groovy here:
 
 -
>> https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/SetupCommand.groovy#L37
 
 That code is basically there to take this input file:
 
 -
>> https://github.com/apache/tomee-tck/blob/master/src/test/resources/testsuite.properties
 
 ...and fill out any variables that would otherwise have to be hardcoded
>> (versions in jar names, etc.).  Then it overrides the ts.jte file that
>> comes with the TCK and that's the one that gets used.
 
 That said, there are still some hardcoded jar names, but... more
>> opportunities for contribution :)  We build other paths here:
 
 -
>> https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/CommandSupport.groovy#L155
 
 So the short answer is we can either do the work in the
>> testsuite.properties file or build the right path in initPaths and make the
>> generateTsJte function smart enough put it into the ts.jte.  Or some
>> combination of both.
 
 Side note: if you start digging into these groovy files and have an
>> urge to refactor them go ahead :)  We actually grabbed this setup from
>> Geronimo and it's only been minorly changed over the years.  Any kind of
>> love is welcome.
 
 
 --
 David Blevins
 http://twitter.com/dblevins
 http://www.tomitribe.com
 
> On Dec 8, 2020, at 3:48 PM, Thiago Henrique Hupner 
>> wrote:
> 
> Hi all!
> 
> I did some looking and most of the server push tests are failing
>> because
> the TCK client is failing to startup correctly.
> 
> https://tck.work/tomee/api/testlog/276/1607111275890
> 
> This is happening because in the command line to run the client is not
> specified the flow.jar library that is included in the
> jakartaee-tck/endorsedlib/flow.jar.
> 
> This jar has to be included in the java.endorsed.dirs property (but
>> only
> for JDK 8) or with -Xbootclasspath/a flag(to run with JDK 8 or higher).
> 
> I guess the change must be in the ts.jte, but I couldn't figure out
>> where
> this file is in the current setup.
> 
> Thanks
 
>>> 
>> 
>> 



smime.p7s
Description: S/MIME cryptographic signature

[GitHub] [tomee-tck] dblevins merged pull request #14: Add the endorsed.lib from TCK to run the client

[GitBox]

dblevins merged pull request #14:
URL: https://github.com/apache/tomee-tck/pull/14


   



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

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

[GitHub] [tomee-tck] Thihup opened a new pull request #14: Add the endorsed.lib from TCK to run the client

[GitBox]

Thihup opened a new pull request #14:
URL: https://github.com/apache/tomee-tck/pull/14


   The Servlet server push tests uses the flow.jar to
   make the HTTP/2 requests. However, as this jar add
   classes to java namespace, it has to be added to as endorsed lib



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

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

Re: [TCK] Servlet - Server push

[Thiago Henrique Hupner]

Sure! I'll do right away

Em ter., 8 de dez. de 2020 às 22:17, David Blevins 
escreveu:

> > On Dec 8, 2020, at 5:07 PM, David Blevins 
> wrote:
> >
> > PR merged :)
> >
> > - https://github.com/apache/tomee-tck/pull/13
> >
> > Thank you much, Thiago!  So amazing to see this kind of activity.  You
> rock, Thiago!
>
> Oh, we have another branch for the Jakarta EE 9 TCK here:
>
>  - https://github.com/apache/tomee-tck/tree/jakartaee9-tck
>
> If you're up for pulling that commit over and submitting another PR,
> awesome!  Otherwise I'll do a cherry pick tomorrow.
>
> -David
>
> >
> >> On Dec 8, 2020, at 4:36 PM, David Blevins 
> wrote:
> >>
> >> Wow, I did not expect to get an email like this so fast :)   It's
> awesome.
> >>
> >> We build the ts.jte file dynamically in Groovy here:
> >>
> >> -
> https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/SetupCommand.groovy#L37
> >>
> >> That code is basically there to take this input file:
> >>
> >> -
> https://github.com/apache/tomee-tck/blob/master/src/test/resources/testsuite.properties
> >>
> >> ...and fill out any variables that would otherwise have to be hardcoded
> (versions in jar names, etc.).  Then it overrides the ts.jte file that
> comes with the TCK and that's the one that gets used.
> >>
> >> That said, there are still some hardcoded jar names, but... more
> opportunities for contribution :)  We build other paths here:
> >>
> >> -
> https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/CommandSupport.groovy#L155
> >>
> >> So the short answer is we can either do the work in the
> testsuite.properties file or build the right path in initPaths and make the
> generateTsJte function smart enough put it into the ts.jte.  Or some
> combination of both.
> >>
> >> Side note: if you start digging into these groovy files and have an
> urge to refactor them go ahead :)  We actually grabbed this setup from
> Geronimo and it's only been minorly changed over the years.  Any kind of
> love is welcome.
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >>> On Dec 8, 2020, at 3:48 PM, Thiago Henrique Hupner 
> wrote:
> >>>
> >>> Hi all!
> >>>
> >>> I did some looking and most of the server push tests are failing
> because
> >>> the TCK client is failing to startup correctly.
> >>>
> >>> https://tck.work/tomee/api/testlog/276/1607111275890
> >>>
> >>> This is happening because in the command line to run the client is not
> >>> specified the flow.jar library that is included in the
> >>> jakartaee-tck/endorsedlib/flow.jar.
> >>>
> >>> This jar has to be included in the java.endorsed.dirs property (but
> only
> >>> for JDK 8) or with -Xbootclasspath/a flag(to run with JDK 8 or higher).
> >>>
> >>> I guess the change must be in the ts.jte, but I couldn't figure out
> where
> >>> this file is in the current setup.
> >>>
> >>> Thanks
> >>
> >
>
>

Re: [TCK] Servlet - Server push

[David Blevins]

PR merged :)

 - https://github.com/apache/tomee-tck/pull/13

Thank you much, Thiago!  So amazing to see this kind of activity.  You rock, 
Thiago!


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Dec 8, 2020, at 4:36 PM, David Blevins  wrote:
> 
> Wow, I did not expect to get an email like this so fast :)   It's awesome.
> 
> We build the ts.jte file dynamically in Groovy here:
> 
> - 
> https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/SetupCommand.groovy#L37
> 
> That code is basically there to take this input file:
> 
> - 
> https://github.com/apache/tomee-tck/blob/master/src/test/resources/testsuite.properties
> 
> ...and fill out any variables that would otherwise have to be hardcoded 
> (versions in jar names, etc.).  Then it overrides the ts.jte file that comes 
> with the TCK and that's the one that gets used.
> 
> That said, there are still some hardcoded jar names, but... more 
> opportunities for contribution :)  We build other paths here:
> 
> - 
> https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/CommandSupport.groovy#L155
> 
> So the short answer is we can either do the work in the testsuite.properties 
> file or build the right path in initPaths and make the generateTsJte function 
> smart enough put it into the ts.jte.  Or some combination of both.
> 
> Side note: if you start digging into these groovy files and have an urge to 
> refactor them go ahead :)  We actually grabbed this setup from Geronimo and 
> it's only been minorly changed over the years.  Any kind of love is welcome.
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
>> On Dec 8, 2020, at 3:48 PM, Thiago Henrique Hupner  wrote:
>> 
>> Hi all!
>> 
>> I did some looking and most of the server push tests are failing because
>> the TCK client is failing to startup correctly.
>> 
>> https://tck.work/tomee/api/testlog/276/1607111275890
>> 
>> This is happening because in the command line to run the client is not
>> specified the flow.jar library that is included in the
>> jakartaee-tck/endorsedlib/flow.jar.
>> 
>> This jar has to be included in the java.endorsed.dirs property (but only
>> for JDK 8) or with -Xbootclasspath/a flag(to run with JDK 8 or higher).
>> 
>> I guess the change must be in the ts.jte, but I couldn't figure out where
>> this file is in the current setup.
>> 
>> Thanks
> 



smime.p7s
Description: S/MIME cryptographic signature

[GitHub] [tomee-tck] dblevins commented on pull request #13: Add the endorsed.lib from TCK to run the client

[GitBox]

dblevins commented on pull request #13:
URL: https://github.com/apache/tomee-tck/pull/13#issuecomment-741365220


   Perfect!!



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

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

[GitHub] [tomee-tck] Thihup commented on pull request #13: Add the endorsed.lib from TCK to run the client

[GitBox]

Thihup commented on pull request #13:
URL: https://github.com/apache/tomee-tck/pull/13#issuecomment-741355011


   With this change:
   ```
   ./runtests --web tomee-plume com.sun.ts.tests.servlet.spec.serverpush
   1/-0/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#getNullPushBuilderTest - 
PASSED
   2/-0/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#serverPushCookieTest - 
PASSED
   2/-1/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#serverPushInitTest - FAILED
   3/-1/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#serverPushMiscTest - PASSED
   4/-1/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#serverPushNegtiveTest - 
PASSED
   5/-1/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#serverPushSessionTest - 
PASSED
   6/-1/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#serverPushSessionTest2 - 
PASSED
   7/-1/?0 - 
com/sun/ts/tests/servlet/spec/serverpush/Client#java#serverPushTest - PASSED
   ```



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

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

[GitHub] [tomee-tck] Thihup opened a new pull request #13: Add the endorsed.lib from TCK to run the client

[GitBox]

Thihup opened a new pull request #13:
URL: https://github.com/apache/tomee-tck/pull/13


   The Servlet server push tests uses the flow.jar to
   make the HTTP/2 requests. However, as this jar add
   classes to java namespace, it has to be added to as endorsed lib



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

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

Re: [TCK] Servlet - Server push

[David Blevins]

Wow, I did not expect to get an email like this so fast :)   It's awesome.

We build the ts.jte file dynamically in Groovy here:

 - 
https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/SetupCommand.groovy#L37

That code is basically there to take this input file:

 - 
https://github.com/apache/tomee-tck/blob/master/src/test/resources/testsuite.properties

...and fill out any variables that would otherwise have to be hardcoded 
(versions in jar names, etc.).  Then it overrides the ts.jte file that comes 
with the TCK and that's the one that gets used.

That said, there are still some hardcoded jar names, but... more opportunities 
for contribution :)  We build other paths here:

 - 
https://github.com/apache/tomee-tck/blob/master/src/test/script/openejb/tck/commands/CommandSupport.groovy#L155

So the short answer is we can either do the work in the testsuite.properties 
file or build the right path in initPaths and make the generateTsJte function 
smart enough put it into the ts.jte.  Or some combination of both.

Side note: if you start digging into these groovy files and have an urge to 
refactor them go ahead :)  We actually grabbed this setup from Geronimo and 
it's only been minorly changed over the years.  Any kind of love is welcome.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Dec 8, 2020, at 3:48 PM, Thiago Henrique Hupner  wrote:
> 
> Hi all!
> 
> I did some looking and most of the server push tests are failing because
> the TCK client is failing to startup correctly.
> 
> https://tck.work/tomee/api/testlog/276/1607111275890
> 
> This is happening because in the command line to run the client is not
> specified the flow.jar library that is included in the
> jakartaee-tck/endorsedlib/flow.jar.
> 
> This jar has to be included in the java.endorsed.dirs property (but only
> for JDK 8) or with -Xbootclasspath/a flag(to run with JDK 8 or higher).
> 
> I guess the change must be in the ts.jte, but I couldn't figure out where
> this file is in the current setup.
> 
> Thanks



smime.p7s
Description: S/MIME cryptographic signature

Re: Jakarta TCK

[Thiago Henrique Hupner]

Thanks! :)

Em ter., 8 de dez. de 2020 às 20:34, David Blevins 
escreveu:

> > On Dec 8, 2020, at 2:12 PM, Thiago Henrique Hupner 
> wrote:
> >
> > Hey David!
> >
> > Good to be remembered ;)
>
> :)
>
> > Thanks for the link.
> >
> > I've been contributing to the Piranha server lately helping to pass the
> > Servlet TCK, so I guess I've got some experience with the TCK.
> > I really would like to help. Probably I'll need some help setting up the
> > full TCK environment because I only have the Servlet and Pages TCK in my
> > machine.
>
> There'll be many people who will need help with the setup, so feel free to
> be extra noisy and ask a lot of questions.  All that will help improve the
> documentation so more people can join in the fun.  Here's what we have so
> far:
>
>  - https://github.com/apache/tomee-tck#getting-setup
>
> Meanwhile, you can get the test output and server logs from tck.work.
> For example here are the test failures for
> com.sun.ts.tests.servlet.spec.defaultcontextpath which has a table with
> "Package" and "Test":
>
>  -
> https://tck.work/tomee/tests?path=com.sun.ts.tests.servlet.spec.defaultcontextpath=1607347669779=FAILED
>
> If you click the link under "Package" you get these server logs and Maven
> output:
>
>  - https://tck.work/tomee/api/build/file/1607347669779/247
>
> If you click the link under "Test" you get the TCK test output:
>
>  - https://tck.work/tomee/api/testlog/247/1607347937486
>
> With that you've got the name of the test, all forms of server output and
> the test output.  It's enough to grab the test source and try and figure
> out on which line the test is failing and what expectation isn't met.
> People are always afraid of being too noisy and "bothering" others, but
> honestly hitting the list with even those findings is a great start.  It's
> enough to start a conversation on what the fix might be and where it should
> be (in the TCK or in TomEE).
>
> There are 300 failing tests, so if someone took even a small peak at each
> one and posted some quick analysis of each one that'd be no small
> contribution.  On that note, there is a feature to help deal with the
> volume of failures and focus on what might have the highest impact.  Here's
> a report of all the exceptions thrown by the failing Servlet tests and the
> number of tests impacted:
>
>  -
> https://tck.work/tomee/issues?path=com.sun.ts.tests.servlet==1607347669779=FAILED
>
> Indeed, actually debugging a test to figure out what the fix is definitely
> requires getting the TCK setup yourself.
>
> >
> > And sure it will help me give a better view of the web platform and how
> to
> > set up things for Piranha in the future too :)
> >
> > One question I have is with respect to issuing a pull request: I should
> > first open an issue at Jira then open a PR? This still confuses me a
> little.
>
> First is hit the list with a short "I'm looking to hack on a PR for X, any
> thoughts/tips before I start?"  After that it doesn't really matter what
> comes next PR or Issue.
>
> We used to use the Issues to automatically generate the changelog each
> release.  As long as we ensure there is a JIRA before we do the release,
> that's the final deadline.  Unfortunately, that system decayed due to
> change in JIRA APIs over time and isn't being used currently and as a
> result there is no changelog each release.  There's a whole other
> area/opportunity for contribution there.  Sometimes I question the need for
> JIRA anymore, but that's a whole other story. :)
>
> -David
>
> > Em ter., 8 de dez. de 2020 às 18:42, David Blevins <
> david.blev...@gmail.com>
> > escreveu:
> >
> >> Hey Thiago!
> >>
> >> Thought I saw your name on today's JakartaOne Livestream.  Here's a site
> >> that has the latest TomEE TCK results:
> >>
> >> - https://tck.work/tomee/projects
> >>
> >> We're at the stage where we're down to the last few hundred failures.
> >> This is where things get really detailed and is actually a great place
> to
> >> dive in and help.  In the earlier phases getting tests to pass is often,
> >> "we need someone to create/integrate an implementation of X spec" which
> is
> >> definitely heavy work.
> >>
> >> At this stage the issues are more like, "the spec says this, we do that,
> >> the TCK seems to do something entirely different."  In this phase it's a
> >> lot of reading test code, reading specifications to try and understand,
> >> having discussions here to get some consistent perspective then having
> >> conversations with other people on the Jakarta EE side.
> >>
> >> It's one large learning opportunity for all of us, myself included.  If
> >> anyone is excited about potentially becoming an expert in Jakarta EE
> >> through helping with the TCK, this is the phase to dig in.
> >>
> >> If this interests you, I recommend keeping an eye out for any threads
> with
> >> the "[TCK]" prefix and asking questions to get more information and help
> >> with the research.  If you're feeling really aggressive, you can 

[TCK] Servlet - Server push

[Thiago Henrique Hupner]

Hi all!

I did some looking and most of the server push tests are failing because
the TCK client is failing to startup correctly.

https://tck.work/tomee/api/testlog/276/1607111275890

This is happening because in the command line to run the client is not
specified the flow.jar library that is included in the
jakartaee-tck/endorsedlib/flow.jar.

This jar has to be included in the java.endorsed.dirs property (but only
for JDK 8) or with -Xbootclasspath/a flag(to run with JDK 8 or higher).

I guess the change must be in the ts.jte, but I couldn't figure out where
this file is in the current setup.

Thanks

Re: Jakarta TCK

[David Blevins]

> On Dec 8, 2020, at 2:12 PM, Thiago Henrique Hupner  wrote:
> 
> Hey David!
> 
> Good to be remembered ;)

:)

> Thanks for the link.
> 
> I've been contributing to the Piranha server lately helping to pass the
> Servlet TCK, so I guess I've got some experience with the TCK.
> I really would like to help. Probably I'll need some help setting up the
> full TCK environment because I only have the Servlet and Pages TCK in my
> machine.

There'll be many people who will need help with the setup, so feel free to be 
extra noisy and ask a lot of questions.  All that will help improve the 
documentation so more people can join in the fun.  Here's what we have so far:

 - https://github.com/apache/tomee-tck#getting-setup

Meanwhile, you can get the test output and server logs from tck.work.  For 
example here are the test failures for 
com.sun.ts.tests.servlet.spec.defaultcontextpath which has a table with 
"Package" and "Test":

 - 
https://tck.work/tomee/tests?path=com.sun.ts.tests.servlet.spec.defaultcontextpath=1607347669779=FAILED

If you click the link under "Package" you get these server logs and Maven 
output:

 - https://tck.work/tomee/api/build/file/1607347669779/247

If you click the link under "Test" you get the TCK test output:

 - https://tck.work/tomee/api/testlog/247/1607347937486

With that you've got the name of the test, all forms of server output and the 
test output.  It's enough to grab the test source and try and figure out on 
which line the test is failing and what expectation isn't met.  People are 
always afraid of being too noisy and "bothering" others, but honestly hitting 
the list with even those findings is a great start.  It's enough to start a 
conversation on what the fix might be and where it should be (in the TCK or in 
TomEE).

There are 300 failing tests, so if someone took even a small peak at each one 
and posted some quick analysis of each one that'd be no small contribution.  On 
that note, there is a feature to help deal with the volume of failures and 
focus on what might have the highest impact.  Here's a report of all the 
exceptions thrown by the failing Servlet tests and the number of tests impacted:

 - 
https://tck.work/tomee/issues?path=com.sun.ts.tests.servlet==1607347669779=FAILED

Indeed, actually debugging a test to figure out what the fix is definitely 
requires getting the TCK setup yourself.

> 
> And sure it will help me give a better view of the web platform and how to
> set up things for Piranha in the future too :)
> 
> One question I have is with respect to issuing a pull request: I should
> first open an issue at Jira then open a PR? This still confuses me a little.

First is hit the list with a short "I'm looking to hack on a PR for X, any 
thoughts/tips before I start?"  After that it doesn't really matter what comes 
next PR or Issue.

We used to use the Issues to automatically generate the changelog each release. 
 As long as we ensure there is a JIRA before we do the release, that's the 
final deadline.  Unfortunately, that system decayed due to change in JIRA APIs 
over time and isn't being used currently and as a result there is no changelog 
each release.  There's a whole other area/opportunity for contribution there.  
Sometimes I question the need for JIRA anymore, but that's a whole other story. 
:)

-David

> Em ter., 8 de dez. de 2020 às 18:42, David Blevins 
> escreveu:
> 
>> Hey Thiago!
>> 
>> Thought I saw your name on today's JakartaOne Livestream.  Here's a site
>> that has the latest TomEE TCK results:
>> 
>> - https://tck.work/tomee/projects
>> 
>> We're at the stage where we're down to the last few hundred failures.
>> This is where things get really detailed and is actually a great place to
>> dive in and help.  In the earlier phases getting tests to pass is often,
>> "we need someone to create/integrate an implementation of X spec" which is
>> definitely heavy work.
>> 
>> At this stage the issues are more like, "the spec says this, we do that,
>> the TCK seems to do something entirely different."  In this phase it's a
>> lot of reading test code, reading specifications to try and understand,
>> having discussions here to get some consistent perspective then having
>> conversations with other people on the Jakarta EE side.
>> 
>> It's one large learning opportunity for all of us, myself included.  If
>> anyone is excited about potentially becoming an expert in Jakarta EE
>> through helping with the TCK, this is the phase to dig in.
>> 
>> If this interests you, I recommend keeping an eye out for any threads with
>> the "[TCK]" prefix and asking questions to get more information and help
>> with the research.  If you're feeling really aggressive, you can even find
>> a failing test, dig into the source code and see if you can understand what
>> the test is asking for that we aren't doing then post some details on what
>> you find (even if what you find is more questions -- that seems to be the
>> typical result).
>> 
>> 
>> --

Re: Jakarta TCK

[Thiago Henrique Hupner]

Hey David!

Good to be remembered ;)

Thanks for the link.

I've been contributing to the Piranha server lately helping to pass the
Servlet TCK, so I guess I've got some experience with the TCK.
I really would like to help. Probably I'll need some help setting up the
full TCK environment because I only have the Servlet and Pages TCK in my
machine.

And sure it will help me give a better view of the web platform and how to
set up things for Piranha in the future too :)

One question I have is with respect to issuing a pull request: I should
first open an issue at Jira then open a PR? This still confuses me a little.

Thanks!

Em ter., 8 de dez. de 2020 às 18:42, David Blevins 
escreveu:

> Hey Thiago!
>
> Thought I saw your name on today's JakartaOne Livestream.  Here's a site
> that has the latest TomEE TCK results:
>
>  - https://tck.work/tomee/projects
>
> We're at the stage where we're down to the last few hundred failures.
> This is where things get really detailed and is actually a great place to
> dive in and help.  In the earlier phases getting tests to pass is often,
> "we need someone to create/integrate an implementation of X spec" which is
> definitely heavy work.
>
> At this stage the issues are more like, "the spec says this, we do that,
> the TCK seems to do something entirely different."  In this phase it's a
> lot of reading test code, reading specifications to try and understand,
> having discussions here to get some consistent perspective then having
> conversations with other people on the Jakarta EE side.
>
> It's one large learning opportunity for all of us, myself included.  If
> anyone is excited about potentially becoming an expert in Jakarta EE
> through helping with the TCK, this is the phase to dig in.
>
> If this interests you, I recommend keeping an eye out for any threads with
> the "[TCK]" prefix and asking questions to get more information and help
> with the research.  If you're feeling really aggressive, you can even find
> a failing test, dig into the source code and see if you can understand what
> the test is asking for that we aren't doing then post some details on what
> you find (even if what you find is more questions -- that seems to be the
> typical result).
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> > On Oct 30, 2020, at 6:56 AM, Thiago Henrique Hupner 
> wrote:
> >
> > Hi all,
> >
> > Is there any place where we can see the current results of the TCK?
> >
> > If not, it would be possible to use the Github Actions to run it?
> >
> > Thanks
> >
> > Thiago
>
>

Re: Jakarta TCK

[David Blevins]

Hey Thiago!

Thought I saw your name on today's JakartaOne Livestream.  Here's a site that 
has the latest TomEE TCK results:

 - https://tck.work/tomee/projects

We're at the stage where we're down to the last few hundred failures.  This is 
where things get really detailed and is actually a great place to dive in and 
help.  In the earlier phases getting tests to pass is often, "we need someone 
to create/integrate an implementation of X spec" which is definitely heavy work.

At this stage the issues are more like, "the spec says this, we do that, the 
TCK seems to do something entirely different."  In this phase it's a lot of 
reading test code, reading specifications to try and understand, having 
discussions here to get some consistent perspective then having conversations 
with other people on the Jakarta EE side.

It's one large learning opportunity for all of us, myself included.  If anyone 
is excited about potentially becoming an expert in Jakarta EE through helping 
with the TCK, this is the phase to dig in.

If this interests you, I recommend keeping an eye out for any threads with the 
"[TCK]" prefix and asking questions to get more information and help with the 
research.  If you're feeling really aggressive, you can even find a failing 
test, dig into the source code and see if you can understand what the test is 
asking for that we aren't doing then post some details on what you find (even 
if what you find is more questions -- that seems to be the typical result).


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Oct 30, 2020, at 6:56 AM, Thiago Henrique Hupner  wrote:
> 
> Hi all,
> 
> Is there any place where we can see the current results of the TCK?
> 
> If not, it would be possible to use the Github Actions to run it?
> 
> Thanks
> 
> Thiago



smime.p7s
Description: S/MIME cryptographic signature

Re: How can I help?

[David Blevins]

Hola, Jorge!

We have a great variety of things that the project needs:

 - help organizing the documentation
 - examples translated to Spanish
 - new examples for various MicroProfile and Jakarta EE apis
 - help passing the Jakarta EE 8 and 9 TCKs
 - help helping people who ask how they can help :)

Happy to guide you into any of these directions or any other area you might be 
interested in.

Don't be discouraged by the time it took for you to get a response.  See it as 
a sign that we need so much help people barely have time to answer questions 
like this.  That's a sign of how much help we need and in an environment like 
that there are endless ways to have impact.

Thank you so much for showing interest!


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Nov 25, 2020, at 8:47 AM, Jorge Luis Morales Reyes 
>  wrote:
> 
> My name is Jorge Morales Reyes. I'm a Java Web Developer from Nicaragua.
> 
> I would like to help in the Apache TomEE project.
> 
> -- 
> *Jorge Luis Morales Reyes*
> -- Claro: 8925-8285
> -- Mov: 8552-3626



smime.p7s
Description: S/MIME cryptographic signature

Re: [TCK] IvmContext: Naming context close

[David Blevins]

> On Dec 8, 2020, at 2:04 AM, Jean-Louis Monteiro  
> wrote:
> 
> Hi all,
> 
> Yesterday I worked on the EJB 3 failures related to naming context.
> I realized we were failing on a couple of tests and I've been able to fix
> them with configuration.
> 
> But the last one was regarding the close operation.
> Specification says
> 
> 10.4.4. Container Provider Responsibility
>> 
>> The container must ensure that the enterprise bean instances have only
>> read access to their environment variables. The container must throw the
>> javax.naming.OperationNotSupportedException from all the methods of the
>> javax.naming.Context interface that modify the environment naming context
>> and its subcontexts.
>> 
> 
> 
> Looking at the TCK, close() isn't considered as a method that modifies the
> naming context.
> 
> So I created ticket https://issues.apache.org/jira/browse/TOMEE-2935
> And fixed it with
> https://github.com/apache/tomee/commit/13bf774f480c7cf841fafda6e027833fb22892d0
> 
> What do you think?

Playing devils advocate, the tricky one here is apps have the ability to create 
a new InitialContext and close is simply the counterpart of that.  From that 
strict perspective, "new InitialContext" would also be illegal because it is 
not read-only.  That said, if close was considered legal I'd expect it to only 
affect that exact InitialContext instance created by the app.

That said, I've made an assumption this is in regards to 
javax.naming.InitialContext.  If in fact the app is grabbing and closing any 
other context instance, it'd definitely be wrong.

Do you have a source reference for the test?


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Limitations in Arquillian Embedded and Application Composer

[David Blevins]

Hi Juan,

Documentation these features would be a great contribution.  If you're 
interested in helping there, let's talk through what issues you see and you can 
contribute some documentation.  If there are issues that need to be fixed and 
are interested in code contribution opportunities too, I can do my best to 
guide you through.

BTW, love your email address :)


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Oct 31, 2020, at 11:59 AM, Juan Moreno  wrote:
> 
> Hi all!
> 
>   I've been testing an Application with Arquillian Embedded (Tomee) and
> Application Composer and I've noticed in some cases they don't show the
> real behavior. Do you have a wiki page or a place where I can find the
> limitations?
> 
> Regards
> Juan Moreno
> Software Developer



smime.p7s
Description: S/MIME cryptographic signature

Re: [TCK] JSTL x:transform failures

[Alex The Rocker]

I fear slightly less the extra issues that reverting to xalan might
bring to XSLT / XML Transform features than the impacts of
searializer.jar reintroduction. Indeed, when xalan.jar was removed, we
had to remove searializer.jar as well from our web apps otherwise our
webapps failed to start.

The relationships between xalan.jar and searializer.jar in the context
of TomEE are at this moment too fuzzy for me to feel comfortable with
such reintroduction.

I understand and I agree with the "do like Tomcat" objective, but then
why not remove the Xalan the dependency at this level, i.e., emulate
the ForEachTag's implementation with vanilla JAXP in Tomcat ?

Alexandre

Le mar. 8 déc. 2020 à 15:09, Jonathan Gallimore
 a écrit :
>
> We're looking to pass the TCK for both EE8 and EE9. This change would be
> needed on both counts.
>
> Both TomEE 8 and 9 use the exact same codebase, and one is simply a
> translation of the other into the jakarta. namespace.
>
> I understand your view, and also the issue you experienced with the
> Japanese character set. From your point of view, what would you like from
> the project to assure you that the problems you've previously seen don't
> appear again (or cause other issues)? We can definitely expand on tests in
> the project to increase levels of confidence and prevent regressions, I
> just think we need to agree on what those tests are.
>
> If I find another approach that can work, I'll present it here.
>
> Jon
>
> On Tue, Dec 8, 2020 at 1:46 PM Alex The Rocker  wrote:
>
> > In that case, could xalan-reintroduction be limited to TomEE 9.x ?
> > What's the urge with TomEE 8.x vs. impacts risks ?
> >
> > Le mar. 8 déc. 2020 à 14:39, Jonathan Gallimore
> >  a écrit :
> > >
> > > We fixed a specific issue by removing Xalan, but without realizing the
> > > impact on JSTL. We'll need to fix this one way or another. There's a
> > couple
> > > of options:
> > >
> > > 1. Re-introduce Xalan and patch it (which seems to be the common
> > > approach across the app servers)
> > > 2. Implement what we need with JAXP.
> > >
> > > At the moment, I'm more in favour of (1) for 2 reasons: its more of a
> > known
> > > quantity (we've used it before) than implementing our thing, and
> > secondly,
> > > it keeps us in line with Tomcat. Our mantra has always been "Be Tomcat" -
> > > if we went the JAXP route we're consciously doing something a little
> > > different, and going against the idea of "Be Tomcat".
> > >
> > > Jon
> > >
> > > On Tue, Dec 8, 2020 at 12:50 PM Alex The Rocker 
> > > wrote:
> > >
> > > > ForEachTag's class comment says "Implementation of ; tag
> > > > using low-level Xalan API."
> > > > Isn't there a way to emulate that with simple JAXP instead of
> > > > re-introducing the huge & unmaintained dependency on Xalan ?
> > > > As far as I remember, not only xalan.jar, but also serializer.jar had
> > > > to be removed (maybe in our apps, I don't remember), and that was a
> > > > bit chaotic. I'm scared at the idea of re-doing this error-prone
> > > > process in the reverse order, and who know how many unsolved bugs
> > > > Xalan fixed in vanilla JAXP will re-introduced on TomEE?
> > > >
> > > > Alexandre
> > > >
> > > > Le mar. 8 déc. 2020 à 13:39, Jean-Louis Monteiro
> > > >  a écrit :
> > > > >
> > > > > Quick update on this one ...
> > > > >
> > > > > Tomcat Taglib has a direct dependency on XParthContext
> > > > >
> > > >
> > https://github.com/apache/tomcat-taglibs-standard/blob/master/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ForEachTag.java
> > > > >
> > > > > This is available in Xalan
> > > > > So at this point, we have an issue in TomEE with xml:transform not
> > > > working.
> > > > > TCK or not, does not matter, it's not working.
> > > > >
> > > > > Long term would probably be to get Tomcat Taglib implementation to
> > use
> > > > JAXP
> > > > > APIs instead of straight Xalan.
> > > > > Short term would be to patch Xalan ourselves.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Tue, Dec 8, 2020 at 11:31 AM Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com> wrote:
> > > > >
> > > > > > Thanks.
> > > > > > Alexandre also replied on the ticket so I'll revert and see if I
> > can
> > > > find
> > > > > > a better solution.
> > > > > >
> > > > > > Thanks guys
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
> > > > > > jonathan.gallim...@gmail.com> wrote:
> > > > > >
> > > > > >> Yes - there's a bug with parsing Japanese characters with Xalan.
> > It
> > > > also
> > > > > >> looks like its not maintained any more.
> > > > > >>
> > > > > >> I was under the impression that the Transformer functionality was
> > > > part of
> 

Re: [TCK] JSTL x:transform failures

[Jean-Louis Monteiro]

I tried adding back Xalan and applying the patch mentioned.
I double checked the version of Xalan by default in the JDK (shaded under
com.sun.org.apache ...).

It's a Xalan 2.7.2 so that's the one I used as a starting point.

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


On Tue, Dec 8, 2020 at 3:09 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> We're looking to pass the TCK for both EE8 and EE9. This change would be
> needed on both counts.
>
> Both TomEE 8 and 9 use the exact same codebase, and one is simply a
> translation of the other into the jakarta. namespace.
>
> I understand your view, and also the issue you experienced with the
> Japanese character set. From your point of view, what would you like from
> the project to assure you that the problems you've previously seen don't
> appear again (or cause other issues)? We can definitely expand on tests in
> the project to increase levels of confidence and prevent regressions, I
> just think we need to agree on what those tests are.
>
> If I find another approach that can work, I'll present it here.
>
> Jon
>
> On Tue, Dec 8, 2020 at 1:46 PM Alex The Rocker 
> wrote:
>
> > In that case, could xalan-reintroduction be limited to TomEE 9.x ?
> > What's the urge with TomEE 8.x vs. impacts risks ?
> >
> > Le mar. 8 déc. 2020 à 14:39, Jonathan Gallimore
> >  a écrit :
> > >
> > > We fixed a specific issue by removing Xalan, but without realizing the
> > > impact on JSTL. We'll need to fix this one way or another. There's a
> > couple
> > > of options:
> > >
> > > 1. Re-introduce Xalan and patch it (which seems to be the common
> > > approach across the app servers)
> > > 2. Implement what we need with JAXP.
> > >
> > > At the moment, I'm more in favour of (1) for 2 reasons: its more of a
> > known
> > > quantity (we've used it before) than implementing our thing, and
> > secondly,
> > > it keeps us in line with Tomcat. Our mantra has always been "Be
> Tomcat" -
> > > if we went the JAXP route we're consciously doing something a little
> > > different, and going against the idea of "Be Tomcat".
> > >
> > > Jon
> > >
> > > On Tue, Dec 8, 2020 at 12:50 PM Alex The Rocker 
> > > wrote:
> > >
> > > > ForEachTag's class comment says "Implementation of ; tag
> > > > using low-level Xalan API."
> > > > Isn't there a way to emulate that with simple JAXP instead of
> > > > re-introducing the huge & unmaintained dependency on Xalan ?
> > > > As far as I remember, not only xalan.jar, but also serializer.jar had
> > > > to be removed (maybe in our apps, I don't remember), and that was a
> > > > bit chaotic. I'm scared at the idea of re-doing this error-prone
> > > > process in the reverse order, and who know how many unsolved bugs
> > > > Xalan fixed in vanilla JAXP will re-introduced on TomEE?
> > > >
> > > > Alexandre
> > > >
> > > > Le mar. 8 déc. 2020 à 13:39, Jean-Louis Monteiro
> > > >  a écrit :
> > > > >
> > > > > Quick update on this one ...
> > > > >
> > > > > Tomcat Taglib has a direct dependency on XParthContext
> > > > >
> > > >
> >
> https://github.com/apache/tomcat-taglibs-standard/blob/master/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ForEachTag.java
> > > > >
> > > > > This is available in Xalan
> > > > > So at this point, we have an issue in TomEE with xml:transform not
> > > > working.
> > > > > TCK or not, does not matter, it's not working.
> > > > >
> > > > > Long term would probably be to get Tomcat Taglib implementation to
> > use
> > > > JAXP
> > > > > APIs instead of straight Xalan.
> > > > > Short term would be to patch Xalan ourselves.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > >
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Tue, Dec 8, 2020 at 11:31 AM Jean-Louis Monteiro <
> > > > > jlmonte...@tomitribe.com> wrote:
> > > > >
> > > > > > Thanks.
> > > > > > Alexandre also replied on the ticket so I'll revert and see if I
> > can
> > > > find
> > > > > > a better solution.
> > > > > >
> > > > > > Thanks guys
> > > > > > --
> > > > > > Jean-Louis Monteiro
> > > > > > http://twitter.com/jlouismonteiro
> > > > > > http://www.tomitribe.com
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
> > > > > > jonathan.gallim...@gmail.com> wrote:
> > > > > >
> > > > > >> Yes - there's a bug with parsing Japanese characters with Xalan.
> > It
> > > > also
> > > > > >> looks like its not maintained any more.
> > > > > >>
> > > > > >> I was under the impression that the Transformer functionality
> was
> > > > part of
> > > > > >> the JDK, so I'm curious as to what is missing. I'll have a look
> at
> > > > that
> > > > > >> failing test. Looks like we're missing org.apache.xpath - looks
> > like
> > > > this
> > > > > >> is a little messy.
> > > > > >>
> > > > > >> Jon
> > > > > >>
> > > > > >> On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis 

Re: [TCK] JSTL x:transform failures

[Jonathan Gallimore]

We're looking to pass the TCK for both EE8 and EE9. This change would be
needed on both counts.

Both TomEE 8 and 9 use the exact same codebase, and one is simply a
translation of the other into the jakarta. namespace.

I understand your view, and also the issue you experienced with the
Japanese character set. From your point of view, what would you like from
the project to assure you that the problems you've previously seen don't
appear again (or cause other issues)? We can definitely expand on tests in
the project to increase levels of confidence and prevent regressions, I
just think we need to agree on what those tests are.

If I find another approach that can work, I'll present it here.

Jon

On Tue, Dec 8, 2020 at 1:46 PM Alex The Rocker  wrote:

> In that case, could xalan-reintroduction be limited to TomEE 9.x ?
> What's the urge with TomEE 8.x vs. impacts risks ?
>
> Le mar. 8 déc. 2020 à 14:39, Jonathan Gallimore
>  a écrit :
> >
> > We fixed a specific issue by removing Xalan, but without realizing the
> > impact on JSTL. We'll need to fix this one way or another. There's a
> couple
> > of options:
> >
> > 1. Re-introduce Xalan and patch it (which seems to be the common
> > approach across the app servers)
> > 2. Implement what we need with JAXP.
> >
> > At the moment, I'm more in favour of (1) for 2 reasons: its more of a
> known
> > quantity (we've used it before) than implementing our thing, and
> secondly,
> > it keeps us in line with Tomcat. Our mantra has always been "Be Tomcat" -
> > if we went the JAXP route we're consciously doing something a little
> > different, and going against the idea of "Be Tomcat".
> >
> > Jon
> >
> > On Tue, Dec 8, 2020 at 12:50 PM Alex The Rocker 
> > wrote:
> >
> > > ForEachTag's class comment says "Implementation of ; tag
> > > using low-level Xalan API."
> > > Isn't there a way to emulate that with simple JAXP instead of
> > > re-introducing the huge & unmaintained dependency on Xalan ?
> > > As far as I remember, not only xalan.jar, but also serializer.jar had
> > > to be removed (maybe in our apps, I don't remember), and that was a
> > > bit chaotic. I'm scared at the idea of re-doing this error-prone
> > > process in the reverse order, and who know how many unsolved bugs
> > > Xalan fixed in vanilla JAXP will re-introduced on TomEE?
> > >
> > > Alexandre
> > >
> > > Le mar. 8 déc. 2020 à 13:39, Jean-Louis Monteiro
> > >  a écrit :
> > > >
> > > > Quick update on this one ...
> > > >
> > > > Tomcat Taglib has a direct dependency on XParthContext
> > > >
> > >
> https://github.com/apache/tomcat-taglibs-standard/blob/master/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ForEachTag.java
> > > >
> > > > This is available in Xalan
> > > > So at this point, we have an issue in TomEE with xml:transform not
> > > working.
> > > > TCK or not, does not matter, it's not working.
> > > >
> > > > Long term would probably be to get Tomcat Taglib implementation to
> use
> > > JAXP
> > > > APIs instead of straight Xalan.
> > > > Short term would be to patch Xalan ourselves.
> > > >
> > > > Thoughts?
> > > >
> > > >
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > >
> > > > On Tue, Dec 8, 2020 at 11:31 AM Jean-Louis Monteiro <
> > > > jlmonte...@tomitribe.com> wrote:
> > > >
> > > > > Thanks.
> > > > > Alexandre also replied on the ticket so I'll revert and see if I
> can
> > > find
> > > > > a better solution.
> > > > >
> > > > > Thanks guys
> > > > > --
> > > > > Jean-Louis Monteiro
> > > > > http://twitter.com/jlouismonteiro
> > > > > http://www.tomitribe.com
> > > > >
> > > > >
> > > > > On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
> > > > > jonathan.gallim...@gmail.com> wrote:
> > > > >
> > > > >> Yes - there's a bug with parsing Japanese characters with Xalan.
> It
> > > also
> > > > >> looks like its not maintained any more.
> > > > >>
> > > > >> I was under the impression that the Transformer functionality was
> > > part of
> > > > >> the JDK, so I'm curious as to what is missing. I'll have a look at
> > > that
> > > > >> failing test. Looks like we're missing org.apache.xpath - looks
> like
> > > this
> > > > >> is a little messy.
> > > > >>
> > > > >> Jon
> > > > >>
> > > > >> On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis Monteiro <
> > > > >> jlmonte...@tomitribe.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > Been looking at the JSTL failures
> > > > >> >
> > > > >> >
> > > > >>
> > >
> http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED
> > > > >> >
> > > > >> > I realized that Xalan is missing from our distribution.
> > > > >> > Looks like it's been removed about a year ago.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >>
> > >
> https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4
> > > > >> >
> > > > >> > Does anyone have any clue on why?
> > > > 

Re: [TCK] JSTL x:transform failures

[Alex The Rocker]

In that case, could xalan-reintroduction be limited to TomEE 9.x ?
What's the urge with TomEE 8.x vs. impacts risks ?

Le mar. 8 déc. 2020 à 14:39, Jonathan Gallimore
 a écrit :
>
> We fixed a specific issue by removing Xalan, but without realizing the
> impact on JSTL. We'll need to fix this one way or another. There's a couple
> of options:
>
> 1. Re-introduce Xalan and patch it (which seems to be the common
> approach across the app servers)
> 2. Implement what we need with JAXP.
>
> At the moment, I'm more in favour of (1) for 2 reasons: its more of a known
> quantity (we've used it before) than implementing our thing, and secondly,
> it keeps us in line with Tomcat. Our mantra has always been "Be Tomcat" -
> if we went the JAXP route we're consciously doing something a little
> different, and going against the idea of "Be Tomcat".
>
> Jon
>
> On Tue, Dec 8, 2020 at 12:50 PM Alex The Rocker 
> wrote:
>
> > ForEachTag's class comment says "Implementation of ; tag
> > using low-level Xalan API."
> > Isn't there a way to emulate that with simple JAXP instead of
> > re-introducing the huge & unmaintained dependency on Xalan ?
> > As far as I remember, not only xalan.jar, but also serializer.jar had
> > to be removed (maybe in our apps, I don't remember), and that was a
> > bit chaotic. I'm scared at the idea of re-doing this error-prone
> > process in the reverse order, and who know how many unsolved bugs
> > Xalan fixed in vanilla JAXP will re-introduced on TomEE?
> >
> > Alexandre
> >
> > Le mar. 8 déc. 2020 à 13:39, Jean-Louis Monteiro
> >  a écrit :
> > >
> > > Quick update on this one ...
> > >
> > > Tomcat Taglib has a direct dependency on XParthContext
> > >
> > https://github.com/apache/tomcat-taglibs-standard/blob/master/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ForEachTag.java
> > >
> > > This is available in Xalan
> > > So at this point, we have an issue in TomEE with xml:transform not
> > working.
> > > TCK or not, does not matter, it's not working.
> > >
> > > Long term would probably be to get Tomcat Taglib implementation to use
> > JAXP
> > > APIs instead of straight Xalan.
> > > Short term would be to patch Xalan ourselves.
> > >
> > > Thoughts?
> > >
> > >
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Tue, Dec 8, 2020 at 11:31 AM Jean-Louis Monteiro <
> > > jlmonte...@tomitribe.com> wrote:
> > >
> > > > Thanks.
> > > > Alexandre also replied on the ticket so I'll revert and see if I can
> > find
> > > > a better solution.
> > > >
> > > > Thanks guys
> > > > --
> > > > Jean-Louis Monteiro
> > > > http://twitter.com/jlouismonteiro
> > > > http://www.tomitribe.com
> > > >
> > > >
> > > > On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
> > > > jonathan.gallim...@gmail.com> wrote:
> > > >
> > > >> Yes - there's a bug with parsing Japanese characters with Xalan. It
> > also
> > > >> looks like its not maintained any more.
> > > >>
> > > >> I was under the impression that the Transformer functionality was
> > part of
> > > >> the JDK, so I'm curious as to what is missing. I'll have a look at
> > that
> > > >> failing test. Looks like we're missing org.apache.xpath - looks like
> > this
> > > >> is a little messy.
> > > >>
> > > >> Jon
> > > >>
> > > >> On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis Monteiro <
> > > >> jlmonte...@tomitribe.com>
> > > >> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > Been looking at the JSTL failures
> > > >> >
> > > >> >
> > > >>
> > http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED
> > > >> >
> > > >> > I realized that Xalan is missing from our distribution.
> > > >> > Looks like it's been removed about a year ago.
> > > >> >
> > > >> >
> > > >> >
> > > >>
> > https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4
> > > >> >
> > > >> > Does anyone have any clue on why?
> > > >> > Obviously we won't pass the transform TCK without an XSLT Processor
> > like
> > > >> > Xalan. Adding it back solved most of the issues.
> > > >> >
> > > >> > --
> > > >> > Jean-Louis Monteiro
> > > >> > http://twitter.com/jlouismonteiro
> > > >> > http://www.tomitribe.com
> > > >> >
> > > >>
> > > >
> >

Re: Drop in TomEE WAR

[Jonathan Gallimore]

That's awesome, thanks Rod. I'll keep an eye for the mail on the users list.

Jon

On Tue, Dec 8, 2020 at 1:28 PM Jenkins, Rodney J (Rod) <
jenki...@nationwide.com> wrote:

> Jon,
>
> Thank you for the response.  I did not jump straight to bug.  I figured I
> missed something in the building of our image.
>
> I have passed along the request for the exception and a reproducer.  We
> cannot share the actual code base, but I did ask for something that will
> reproduce the error.  I am working on the stack trace now.
>
> Also, I will have the user email all of this to the users mailing list.  I
> think it is more fitting there.
>
> Thanks again,
> Rod.
>
>
> On 12/7/20, 3:38 PM, "Jonathan Gallimore" 
> wrote:
>
> Nationwide Information Security Warning: This is an EXTERNAL email.
> Use CAUTION before clicking on links, opening attachments, or responding.
> (Sender: dev-return-27511-JENKIR14=nationwide@tomee.apache.org)
>
>
> --
>
>
> Let's get a view on the exception and a reproducer. Sounds like a bug
> we'd
> want to iron out.
>
> Jon
>
> On Mon, Dec 7, 2020 at 4:59 PM Jenkins, Rodney J (Rod) <
> jenki...@nationwide.com> wrote:
>
> > All,
> >
> > Would anyone know what differences between the drop in WAR vs the
> full
> > install?  I am working with someone who is using our internally built
> > Docker image.  Our image is built with the drop in WAR.  If they use
> the
> > public container pulled from Dockerhub (built on the full TomEE
> version),
> > everything works fine.
> >
> > I am having them do a write up to send to the users list for some
> > support.The email to the user list will have the stack trace and
> > additional information.  However, I was hoping for someone provide
> an idea
> > as to what would be different.  The high level issue is:
> > javax.naming.NameNotFoundException
> >
> >
> > Thanks for any initial ideas,
> > Rod.
> >
> >
>
>
>

Re: [TCK] JSTL x:transform failures

[Jonathan Gallimore]

We fixed a specific issue by removing Xalan, but without realizing the
impact on JSTL. We'll need to fix this one way or another. There's a couple
of options:

1. Re-introduce Xalan and patch it (which seems to be the common
approach across the app servers)
2. Implement what we need with JAXP.

At the moment, I'm more in favour of (1) for 2 reasons: its more of a known
quantity (we've used it before) than implementing our thing, and secondly,
it keeps us in line with Tomcat. Our mantra has always been "Be Tomcat" -
if we went the JAXP route we're consciously doing something a little
different, and going against the idea of "Be Tomcat".

Jon

On Tue, Dec 8, 2020 at 12:50 PM Alex The Rocker 
wrote:

> ForEachTag's class comment says "Implementation of ; tag
> using low-level Xalan API."
> Isn't there a way to emulate that with simple JAXP instead of
> re-introducing the huge & unmaintained dependency on Xalan ?
> As far as I remember, not only xalan.jar, but also serializer.jar had
> to be removed (maybe in our apps, I don't remember), and that was a
> bit chaotic. I'm scared at the idea of re-doing this error-prone
> process in the reverse order, and who know how many unsolved bugs
> Xalan fixed in vanilla JAXP will re-introduced on TomEE?
>
> Alexandre
>
> Le mar. 8 déc. 2020 à 13:39, Jean-Louis Monteiro
>  a écrit :
> >
> > Quick update on this one ...
> >
> > Tomcat Taglib has a direct dependency on XParthContext
> >
> https://github.com/apache/tomcat-taglibs-standard/blob/master/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ForEachTag.java
> >
> > This is available in Xalan
> > So at this point, we have an issue in TomEE with xml:transform not
> working.
> > TCK or not, does not matter, it's not working.
> >
> > Long term would probably be to get Tomcat Taglib implementation to use
> JAXP
> > APIs instead of straight Xalan.
> > Short term would be to patch Xalan ourselves.
> >
> > Thoughts?
> >
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Dec 8, 2020 at 11:31 AM Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> >
> > > Thanks.
> > > Alexandre also replied on the ticket so I'll revert and see if I can
> find
> > > a better solution.
> > >
> > > Thanks guys
> > > --
> > > Jean-Louis Monteiro
> > > http://twitter.com/jlouismonteiro
> > > http://www.tomitribe.com
> > >
> > >
> > > On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> wrote:
> > >
> > >> Yes - there's a bug with parsing Japanese characters with Xalan. It
> also
> > >> looks like its not maintained any more.
> > >>
> > >> I was under the impression that the Transformer functionality was
> part of
> > >> the JDK, so I'm curious as to what is missing. I'll have a look at
> that
> > >> failing test. Looks like we're missing org.apache.xpath - looks like
> this
> > >> is a little messy.
> > >>
> > >> Jon
> > >>
> > >> On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis Monteiro <
> > >> jlmonte...@tomitribe.com>
> > >> wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > Been looking at the JSTL failures
> > >> >
> > >> >
> > >>
> http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED
> > >> >
> > >> > I realized that Xalan is missing from our distribution.
> > >> > Looks like it's been removed about a year ago.
> > >> >
> > >> >
> > >> >
> > >>
> https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4
> > >> >
> > >> > Does anyone have any clue on why?
> > >> > Obviously we won't pass the transform TCK without an XSLT Processor
> like
> > >> > Xalan. Adding it back solved most of the issues.
> > >> >
> > >> > --
> > >> > Jean-Louis Monteiro
> > >> > http://twitter.com/jlouismonteiro
> > >> > http://www.tomitribe.com
> > >> >
> > >>
> > >
>

Re: Drop in TomEE WAR

[Jenkins, Rodney J (Rod)]

Jon,

Thank you for the response.  I did not jump straight to bug.  I figured I 
missed something in the building of our image.

I have passed along the request for the exception and a reproducer.  We cannot 
share the actual code base, but I did ask for something that will reproduce the 
error.  I am working on the stack trace now.

Also, I will have the user email all of this to the users mailing list.  I 
think it is more fitting there.

Thanks again,
Rod.


On 12/7/20, 3:38 PM, "Jonathan Gallimore"  wrote:

Nationwide Information Security Warning: This is an EXTERNAL email. Use 
CAUTION before clicking on links, opening attachments, or responding. (Sender: 
dev-return-27511-JENKIR14=nationwide@tomee.apache.org)


--


Let's get a view on the exception and a reproducer. Sounds like a bug we'd
want to iron out.

Jon

On Mon, Dec 7, 2020 at 4:59 PM Jenkins, Rodney J (Rod) <
jenki...@nationwide.com> wrote:

> All,
>
> Would anyone know what differences between the drop in WAR vs the full
> install?  I am working with someone who is using our internally built
> Docker image.  Our image is built with the drop in WAR.  If they use the
> public container pulled from Dockerhub (built on the full TomEE version),
> everything works fine.
>
> I am having them do a write up to send to the users list for some
> support.The email to the user list will have the stack trace and
> additional information.  However, I was hoping for someone provide an idea
> as to what would be different.  The high level issue is:
> javax.naming.NameNotFoundException
>
>
> Thanks for any initial ideas,
> Rod.
>
>

Re: [TCK] JSTL x:transform failures

[Alex The Rocker]

ForEachTag's class comment says "Implementation of ; tag
using low-level Xalan API."
Isn't there a way to emulate that with simple JAXP instead of
re-introducing the huge & unmaintained dependency on Xalan ?
As far as I remember, not only xalan.jar, but also serializer.jar had
to be removed (maybe in our apps, I don't remember), and that was a
bit chaotic. I'm scared at the idea of re-doing this error-prone
process in the reverse order, and who know how many unsolved bugs
Xalan fixed in vanilla JAXP will re-introduced on TomEE?

Alexandre

Le mar. 8 déc. 2020 à 13:39, Jean-Louis Monteiro
 a écrit :
>
> Quick update on this one ...
>
> Tomcat Taglib has a direct dependency on XParthContext
> https://github.com/apache/tomcat-taglibs-standard/blob/master/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ForEachTag.java
>
> This is available in Xalan
> So at this point, we have an issue in TomEE with xml:transform not working.
> TCK or not, does not matter, it's not working.
>
> Long term would probably be to get Tomcat Taglib implementation to use JAXP
> APIs instead of straight Xalan.
> Short term would be to patch Xalan ourselves.
>
> Thoughts?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Dec 8, 2020 at 11:31 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> wrote:
>
> > Thanks.
> > Alexandre also replied on the ticket so I'll revert and see if I can find
> > a better solution.
> >
> > Thanks guys
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> >
> >> Yes - there's a bug with parsing Japanese characters with Xalan. It also
> >> looks like its not maintained any more.
> >>
> >> I was under the impression that the Transformer functionality was part of
> >> the JDK, so I'm curious as to what is missing. I'll have a look at that
> >> failing test. Looks like we're missing org.apache.xpath - looks like this
> >> is a little messy.
> >>
> >> Jon
> >>
> >> On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > Been looking at the JSTL failures
> >> >
> >> >
> >> http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED
> >> >
> >> > I realized that Xalan is missing from our distribution.
> >> > Looks like it's been removed about a year ago.
> >> >
> >> >
> >> >
> >> https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4
> >> >
> >> > Does anyone have any clue on why?
> >> > Obviously we won't pass the transform TCK without an XSLT Processor like
> >> > Xalan. Adding it back solved most of the issues.
> >> >
> >> > --
> >> > Jean-Louis Monteiro
> >> > http://twitter.com/jlouismonteiro
> >> > http://www.tomitribe.com
> >> >
> >>
> >

Re: [TCK] JSTL x:transform failures

[Jean-Louis Monteiro]

Quick update on this one ...

Tomcat Taglib has a direct dependency on XParthContext
https://github.com/apache/tomcat-taglibs-standard/blob/master/impl/src/main/java/org/apache/taglibs/standard/tag/common/xml/ForEachTag.java

This is available in Xalan
So at this point, we have an issue in TomEE with xml:transform not working.
TCK or not, does not matter, it's not working.

Long term would probably be to get Tomcat Taglib implementation to use JAXP
APIs instead of straight Xalan.
Short term would be to patch Xalan ourselves.

Thoughts?


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


On Tue, Dec 8, 2020 at 11:31 AM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Thanks.
> Alexandre also replied on the ticket so I'll revert and see if I can find
> a better solution.
>
> Thanks guys
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
>
>> Yes - there's a bug with parsing Japanese characters with Xalan. It also
>> looks like its not maintained any more.
>>
>> I was under the impression that the Transformer functionality was part of
>> the JDK, so I'm curious as to what is missing. I'll have a look at that
>> failing test. Looks like we're missing org.apache.xpath - looks like this
>> is a little messy.
>>
>> Jon
>>
>> On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>> wrote:
>>
>> > Hi,
>> >
>> > Been looking at the JSTL failures
>> >
>> >
>> http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED
>> >
>> > I realized that Xalan is missing from our distribution.
>> > Looks like it's been removed about a year ago.
>> >
>> >
>> >
>> https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4
>> >
>> > Does anyone have any clue on why?
>> > Obviously we won't pass the transform TCK without an XSLT Processor like
>> > Xalan. Adding it back solved most of the issues.
>> >
>> > --
>> > Jean-Louis Monteiro
>> > http://twitter.com/jlouismonteiro
>> > http://www.tomitribe.com
>> >
>>
>

Re: [TCK] JSTL x:transform failures

[Jean-Louis Monteiro]

Thanks.
Alexandre also replied on the ticket so I'll revert and see if I can find a
better solution.

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


On Tue, Dec 8, 2020 at 11:21 AM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Yes - there's a bug with parsing Japanese characters with Xalan. It also
> looks like its not maintained any more.
>
> I was under the impression that the Transformer functionality was part of
> the JDK, so I'm curious as to what is missing. I'll have a look at that
> failing test. Looks like we're missing org.apache.xpath - looks like this
> is a little messy.
>
> Jon
>
> On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis Monteiro <
> jlmonte...@tomitribe.com>
> wrote:
>
> > Hi,
> >
> > Been looking at the JSTL failures
> >
> >
> http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED
> >
> > I realized that Xalan is missing from our distribution.
> > Looks like it's been removed about a year ago.
> >
> >
> >
> https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4
> >
> > Does anyone have any clue on why?
> > Obviously we won't pass the transform TCK without an XSLT Processor like
> > Xalan. Adding it back solved most of the issues.
> >
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
>

[GitHub] [tomee] rzo1 commented on pull request #723: TOMEE-2933 - Updates to eclipselink 2.7.7

[GitBox]

rzo1 commented on pull request #723:
URL: https://github.com/apache/tomee/pull/723#issuecomment-740534565


   Fixed with 
https://github.com/apache/tomee/commit/c38f60e78e7cef40fb7d1b61962d5cffc756de2e



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

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

[GitHub] [tomee] rzo1 closed pull request #723: TOMEE-2933 - Updates to eclipselink 2.7.7

[GitBox]

rzo1 closed pull request #723:
URL: https://github.com/apache/tomee/pull/723


   



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

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

[GitHub] [tomee] rzo1 edited a comment on pull request #723: TOMEE-2933 - Updates to eclipselink 2.7.7

[GitBox]

rzo1 edited a comment on pull request #723:
URL: https://github.com/apache/tomee/pull/723#issuecomment-740529651


   Hi @jeanouii 
   
   I think, we did TOMEE-2933 twice :smile: 
   
   Nevertheless, the changes related to `cxf-rt-rs-sse` here might be worth a 
check. Otherwise: Please close this PR.
   



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

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

[GitHub] [tomee] rzo1 commented on pull request #723: TOMEE-2933 - Updates to eclipselink 2.7.7

[GitBox]

rzo1 commented on pull request #723:
URL: https://github.com/apache/tomee/pull/723#issuecomment-740529651


   Hi @jeanouii 
   
   I think, we did TOMEE-2933 twice :+1: 
   
   Nevertheless, the changes related to `cxf-rt-rs-sse` here might be worth a 
check. Otherwise: Please close this PR.
   



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

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

Re: [TCK] JSTL x:transform failures

[Jonathan Gallimore]

Yes - there's a bug with parsing Japanese characters with Xalan. It also
looks like its not maintained any more.

I was under the impression that the Transformer functionality was part of
the JDK, so I'm curious as to what is missing. I'll have a look at that
failing test. Looks like we're missing org.apache.xpath - looks like this
is a little messy.

Jon

On Tue, Dec 8, 2020 at 9:58 AM Jean-Louis Monteiro 
wrote:

> Hi,
>
> Been looking at the JSTL failures
>
> http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED
>
> I realized that Xalan is missing from our distribution.
> Looks like it's been removed about a year ago.
>
>
> https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4
>
> Does anyone have any clue on why?
> Obviously we won't pass the transform TCK without an XSLT Processor like
> Xalan. Adding it back solved most of the issues.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

[TCK] IvmContext: Naming context close

[Jean-Louis Monteiro]

Hi all,

Yesterday I worked on the EJB 3 failures related to naming context.
I realized we were failing on a couple of tests and I've been able to fix
them with configuration.

But the last one was regarding the close operation.
Specification says

10.4.4. Container Provider Responsibility
>
> The container must ensure that the enterprise bean instances have only
> read access to their environment variables. The container must throw the
> javax.naming.OperationNotSupportedException from all the methods of the
> javax.naming.Context interface that modify the environment naming context
> and its subcontexts.
>


Looking at the TCK, close() isn't considered as a method that modifies the
naming context.

So I created ticket https://issues.apache.org/jira/browse/TOMEE-2935
And fixed it with
https://github.com/apache/tomee/commit/13bf774f480c7cf841fafda6e027833fb22892d0

What do you think?

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

[TCK] JSTL x:transform failures

[Jean-Louis Monteiro]

Hi,

Been looking at the JSTL failures
http://ec2-54-173-218-40.compute-1.amazonaws.com:17171/tests?path=com.sun.ts.tests.jstl=1607347669779=FAILED

I realized that Xalan is missing from our distribution.
Looks like it's been removed about a year ago.

https://github.com/apache/tomee/commit/5f1b57af1b4f11638c8c9540fcc83feb618980a4

Does anyone have any clue on why?
Obviously we won't pass the transform TCK without an XSLT Processor like
Xalan. Adding it back solved most of the issues.

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