Re: Tomcat and JAX-RPC support

[Jean-Louis MONTEIRO]

It makes sense.

+1

Le ven. 6 janv. 2023 à 11:50, Mark Thomas  a écrit :

> Tomcat (all versions) currently ships a JNDI factory for JAX-RPC 1.1.
> This factory was added in Tomcat 6 (Java EE 5).
>
> Java EE 5 (Tomcat 6) encouraged new applications to use JAX-WS rather
> than JAX-RPC.
>
> Java EE 6 (Tomcat 7) marked JAX-RPC as "Proposed Optional".
>
> Java EE 7 (Tomcat 8) marked JAX-RPC as "Optional".
>
> Jakarta EE 9 (Tomcat 10.0) removed JAX-RPC from the Jakarta platform.
>
> Tomcat 10.1 and Tomcat 11 still include the JNDI factory for JAX-RPC.
>
> I would like to propose deprecating JAX-RPC support in 10.1 and earlier
> and removing it in Tomcat 11. Ideally, I'd like to remove JAX-RPC
> support in Tomcat 10.1 but it is too late to do that now 10.1.x is stable.
>
> Given there have been no user questions about this that I can remember,
> I do not propose replacing this with the Jakarta XML Web Services
> equivalent.
>
> Thoughts?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: TC 10.1 TestMessageBytes.testConversionPerformance() fails sometimes

[Jean-Louis MONTEIRO]

I agree.
It's a good test and it has very well done the job.

+1 with the approach. Seems reasonable

Le sam. 12 nov. 2022, 12:23, Mark Thomas  a écrit :

> On 11/11/2022 14:39, Rémy Maucherat wrote:
> > On Fri, Nov 11, 2022 at 3:24 PM Rainer Jung 
> wrote:
> >>
> >> FYI: the performance check TestMessageBytes.testConversionPerformance()
> >> seems to fail sometimes for various Linux variants and JVM versions. It
> >> fails in 13 out of 116 combinations of Linux distro, JVM version and
> >> provider and connector.
> >>
> >> When failing, it complains, that the non-optimised version is faster,
> >> then the optimised one. The speed difference is between one and 24
> percent.
> >>
> >> The system on which the tests run is CPU limited. Most failures seem to
> >> happen with JDK 17, but that could be just because during those runs
> >> might have been most concurrent things happening on the underlying
> >> virtualization host.
> >>
> >> Maybe one could move the testConversionPerformance test into a separate
> >> class handled by the existing test.excludePerformance?
> >
> > I never had the test fail, but looking at the output of the test it's
> > quite close.
> > 1313899820 1102482207
> > 1049725589 991728960
> > 849182074 917795195
> > So the first two iterations would fail, but the test passes because
> > the final one is slightly faster. The comment says it should be 3x to
> > 4x faster, it's not happening anymore. It simply means the char to
> > bytes of the JVM got better in newer versions.
>
> I see similar results.
>
> For Java 11 I see almost an order of magnitude improvement with the
> optimised version. For Java 17 the optimised version has a marginal
> benefit. It is close enough that the test coudlk fail over a large
> number of runs.
>
> To some extent, the test has done its job. It has told us when we can
> remove the optimisation - once the minimum version is Java 17.
>
> What if we adjusted the test so it din't run on Java 17 and later and we
> comment the optimisation (and the test) to remind us to remove it once
> Java 17 is the minimum version?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: JSTL issue

[Jean-Louis MONTEIRO]

Hi,

I went ahead and pull the code into a draft PR.
I'd appreciate any feedback or guidance.

https://github.com/apache/tomcat/pull/418

Lemme know if that's ok.
I believe I should maybe open something in the bug tracker?

Thanks

Le mer. 5 mai 2021 à 16:38, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Jean-Louis,
>
> On 5/5/21 09:49, Jean-Louis MONTEIRO wrote:
> > Now that we crossed the finish line with TomEE compatibility, I'd like
> > to give back the BOM changes according to this discussion.
> >
> > I did the updated and created another subclass for
> > DefaultServletEncodingBaseTest
> > image.png
> > Did some fixes around that test to take the changes into account.
> > I'll see if I can get this to fully pass
> >
> > image.png
> >
> > Good news, it's backward compatible as we wanted.
> > I may post if I need some help or guidance.
> >
> > As soon as it's done, I believe we want a bugzilla ticket so I can link
> > it to a PR?
>
> All the images were stripped from the list-posting.
>
> Either Bugzilla or GitHub PR is fine.
>
> -chris
>
> > Le jeu. 15 avr. 2021 à 19:19, Christopher Schultz
> > mailto:ch...@christopherschultz.net>> a
> > écrit :
> >
> > Mark,
> >
> > On 4/15/21 04:57, Mark Thomas wrote:
> >  > If we wanted to address this and provide a way to allow JSTL to
> > have the
> >  > control over the included content required to pass this TCK test
> > then we
> >  > could modify 'useBomIfPresent' as follows:
> >  >
> >  > - true   - no change - remains the default
> >  >
> >  > - false  - no change
> >  >
> >  > - ignore - as current false but does not strip the BoM from the
> > output
> >
> > I might re-name the "ignore" case to "pass-through" to be perfectly
> > clear about what's happening. "Ignore" might be mis-interpreted to
> mean
> > that the BOM would be removed. "Pass-through" makes it clear that the
> > BOM will still be sent IMHO.
> >
> > -chris
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > <mailto:dev-unsubscr...@tomcat.apache.org>
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > <mailto:dev-h...@tomcat.apache.org>
> >
> >
> >
> > --
> > Jean-Louis
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: JSTL issue

[Jean-Louis MONTEIRO]

Hi,

Now that we crossed the finish line with TomEE compatibility, I'd like to
give back the BOM changes according to this discussion.

I did the updated and created another subclass for
DefaultServletEncodingBaseTest
[image: image.png]
Did some fixes around that test to take the changes into account.
I'll see if I can get this to fully pass

[image: image.png]

Good news, it's backward compatible as we wanted.
I may post if I need some help or guidance.

As soon as it's done, I believe we want a bugzilla ticket so I can link it
to a PR?


Le jeu. 15 avr. 2021 à 19:19, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Mark,
>
> On 4/15/21 04:57, Mark Thomas wrote:
> > If we wanted to address this and provide a way to allow JSTL to have the
> > control over the included content required to pass this TCK test then we
> > could modify 'useBomIfPresent' as follows:
> >
> > - true   - no change - remains the default
> >
> > - false  - no change
> >
> > - ignore - as current false but does not strip the BoM from the output
>
> I might re-name the "ignore" case to "pass-through" to be perfectly
> clear about what's happening. "Ignore" might be mis-interpreted to mean
> that the BOM would be removed. "Pass-through" makes it clear that the
> BOM will still be sent IMHO.
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: Implementing web.xml default-context-path

[Jean-Louis MONTEIRO]

Thanks for the feedback.

Actually I was not looking for Mark or the Tomcat community to change their
minds. But for some guidance on how to hack something to get this test
to pass.

I've been able to do it in TomEE which was the goal.
Now, I'm totally with you guys. If this is in your opinion a bad use case
with a bad specification solution, we should challenge the feature and then
the test.

Le mer. 5 mai 2021 à 11:22, Romain Manni-Bucau  a
écrit :

> Le mer. 5 mai 2021 à 11:19, Mark Thomas  a écrit :
>
> > On 05/05/2021 09:58, Rémy Maucherat wrote:
> > > On Sun, May 2, 2021 at 3:17 PM Jean-Louis MONTEIRO  >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Still working on getting TomEE certified for Jakarta EE 9.1
> > >> We are using latest Tomcat 10.x and we indeed see now only one failure
> > as
> > >> described here
> > >>
> > >> https://cwiki.apache.org/confluence/display/TOMCAT/Servlet+TCK+5.0
> > >>
> > >> I understand this is not really a critical thing to be certified for
> > >> Tomcat.
> > >> And I also understand this is not something the community agrees on.
> > >>
> > >> But I'd like, for the sake of getting TomEE certified, to pass this
> test
> > >> and therefore I'm looking at a way to patch it on our side.
> > >>
> > >> Would you be able to help in giving pointers on how to do it?
> > >>
> > >> Any help is appreciated at this point.
> > >>
> > >
> > > We already talked about this (bad) "feature" quite a bit in the past.
> > > Unless there's a big surprise:
> > > - This needs intrusive and annoying change to the deployer
> > > - The benefit to actual users seems to be zero
> > > - The feature is optional
> > > As a result, I doubt Mark will change his mind [I am not enthusiastic
> > > either] and I still don't understand how it is a mandatory TCK test.
> >
> > +1 allowing this feature opens up a huge mess of deployment edge cases
> > that the Tomcat deployment process was designed very carefully to avoid.
> >
> > > So ... I think you can come up with a hack instead: a Catalina listener
> > > could be added to the Context, then it could configure the rewrite
> valve
> > to
> > > do the url mapping. It should be enough to make this work.
> >
> > Another option would be to challenge the TCK test on the grounds the
> > spec allows containers to override any default-context-path setting but
> > the TCK assumes this isn't going to happen (in Tomcat it will always
> > happen).
> >
>
> +1 to challenge this test, if there is a consensus it is wrong no point to
> keep it year after year IMHO.
>
>
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> >
>


-- 
Jean-Louis

Implementing web.xml default-context-path

[Jean-Louis MONTEIRO]

Hi,

Still working on getting TomEE certified for Jakarta EE 9.1
We are using latest Tomcat 10.x and we indeed see now only one failure as
described here

https://cwiki.apache.org/confluence/display/TOMCAT/Servlet+TCK+5.0

I understand this is not really a critical thing to be certified for Tomcat.
And I also understand this is not something the community agrees on.

But I'd like, for the sake of getting TomEE certified, to pass this test
and therefore I'm looking at a way to patch it on our side.

Would you be able to help in giving pointers on how to do it?

Any help is appreciated at this point.


-- 
Jean-Louis

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Jean-Louis MONTEIRO]

Le lun. 26 avr. 2021 à 20:48, Mark Thomas  a écrit :

> On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote:
> > JAAS, JASPIC and Jakarta Security are all different.
>
> My mistake. I knew JASPIC had a slightly bigger rename than most specs
> and incorrectly thought it became Jakarta Security. It actually became
> Jakarta Authentication. All previous references from me in this thread
> to "Jakarta Security" should be read as "Jakarta Authentication".
>

No problem.


>
> > Tomcat does not implement Jakarta Security so removing JAAS creates a gap
> > in my opinion.
> >
> > I'd second Romain, JASPIC requires a SAM to be implemented by the
> > application.
> >
> > Long story short, I'd probably deprecate for 10.x and target a removal
> for
> > 11.x
>
> In the normal course of things 10.1 would have been 11.0 but we are
> taking the opportunity align Jakarta EE major version and Tomcat major
> version as well as have a (much) shorter support lifespan for 10.0
> (Jakarta EE 9) as that is seen as a transitional release.
>
> Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10.
>

Sorry I missed that information.
So it appeared to be a bit too aggressive to deprecate and remove.


>
> Mark
>
>
> > Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :
> >
> >> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> >> repo I found the following:
> >>
> >> 
> >> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> >> framework for J2EE v1.4, based on the  >> href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> >> Request 196 to enhance container-managed security and promote
> >> 'pluggable' authentication mechanisms whose implementations would be
> >> container-independent.
> >> 
> >>
> >> JSR became JASPIC (now Jakarta Security) and Tomcat has an
> implementation.
> >>
> >> Searching through the mailing lists I found the following references to
> >> usage of the JAASRealm (going back ~5 years).
> >>
> >> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> >> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> >> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> >> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> >> [5] User wanting access to HttpServletRequest during auth
> >>
> >> Most, if not all, of those have better solutions available than the JAAS
> >> Realm. And those wanting some form of custom auth do have the "proper"
> >> Jakarta Security API to work with.
> >>
> >> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> >> Any objections to immediate deprecation with removal planned for 10.1.x?
> >>
> >> Mark
> >>
> >>
> >> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> >> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> >> [3] http://markmail.org/message/wki275i5yhlg3yyo
> >> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> >> [5] http://markmail.org/message/fm4ggo3ge4r47gar
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: [PROPOSAL] Deprecate JAAS Realm in 10.0.x and remove in 10.1.x

[Jean-Louis MONTEIRO]

JAAS, JASPIC and Jakarta Security are all different.
Tomcat does not implement Jakarta Security so removing JAAS creates a gap
in my opinion.

I'd second Romain, JASPIC requires a SAM to be implemented by the
application.

Long story short, I'd probably deprecate for 10.x and target a removal for
11.x

Le lun. 26 avr. 2021 à 18:17, Mark Thomas  a écrit :

> In reviewing references to Java EE (and J2EE) remaining in the Tomcat 10
> repo I found the following:
>
> 
> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication
> framework for J2EE v1.4, based on the  href="https://www.jcp.org/en/jsr/detail?id=196;>JCP Specification
> Request 196 to enhance container-managed security and promote
> 'pluggable' authentication mechanisms whose implementations would be
> container-independent.
> 
>
> JSR became JASPIC (now Jakarta Security) and Tomcat has an implementation.
>
> Searching through the mailing lists I found the following references to
> usage of the JAASRealm (going back ~5 years).
>
> [1] Tomcat 7 user using JAAS based auth to an LDAP server
> [2] Tomcat 9 user using SPNEGO with the JAAS realm
> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm
> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm
> [5] User wanting access to HttpServletRequest during auth
>
> Most, if not all, of those have better solutions available than the JAAS
> Realm. And those wanting some form of custom auth do have the "proper"
> Jakarta Security API to work with.
>
> Therefore, I'm not currently seeing a good reason to keep the JAASRealm.
> Any objections to immediate deprecation with removal planned for 10.1.x?
>
> Mark
>
>
> [1] http://markmail.org/message/ndvr5ilxovoo4ins
> [2] http://markmail.org/message/5ocdnmqvvlvjsxas
> [3] http://markmail.org/message/wki275i5yhlg3yyo
> [4] http://markmail.org/message/av2sv6g4kgm6ouu4
> [5] http://markmail.org/message/fm4ggo3ge4r47gar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: JSTL issue

[Jean-Louis MONTEIRO]

Hi,

I definitely value the feedback and thoughts.

I understand and I agree it's unlikely to be a real world use case.
I am happy to give it a try to improve the flag and submit a PR for it.

I'll make sure to fire a new TCK build with everything (servlet, jsp, etc)
so we have more confidence in the fix.

Thanks

Le jeu. 15 avr. 2021 à 10:57, Mark Thomas  a écrit :

> On 15/04/2021 09:03, Jean-Louis MONTEIRO wrote:
> > I've got an answer from JSTL team.
> > Here it is
>
> 
>
> >> 1. Jakarta Tags Specification Section 7.4 details the 
> tag:
> >> c:import
> >> <
> https://github.com/eclipse-ee4j/jstl-api/blob/master/spec/src/main/asciidoc/jakarta-stl.adoc#74-cimport
> >
> >>
> >> Within this, it details the following: Character Encoding : The
> >>  for import-encoded.txt does not include an encoding so the
> >> default encoding is used: ISO-8859-1
>
> 
>
> >> At this point from a Jakarta Tags perspective, I believe the golden file
> >> is correct.
>
> Thanks for passing that on.
>
> The Default Servlet improvements were written from the perspective of
> including static content with a variety of encodings where the correct
> encoding was not always known (or maintaining an accurate mapping of
> encoding to resource would impose a significant overhead).
>
> JSTL is coming from the perspective that the encoding of the included
> target is always known.
>
> Currently Tomcat provides the 'useBomIfPresent' option to control the
> BoM handling. The current values are:
>
> - true  - BoM is stripped if present and any BoM found used to determine
>the encoding used to read the resource. This is the default.
>
> - false - BoM is stripped and resource is read using the configured file
>encoding (which will be the platform default if not explicitly
>configured)
>
> If we wanted to address this and provide a way to allow JSTL to have the
> control over the included content required to pass this TCK test then we
> could modify 'useBomIfPresent' as follows:
>
> - true   - no change - remains the default
>
> - false  - no change
>
> - ignore - as current false but does not strip the BoM from the output
>
> This would have no impact on existing users but using the new ignore
> option would allow the JSTL TCK to pass.
>
> I do wonder if this use case has any real world consequences. For that
> to be that case there would need to be an application where:
> - JSTL was importing static resources
> - the content of static resource started with the same bytes as a valid
>BoM
>
> That seems unlikely as the BoM values look to have been chosen to avoid
> this. While it is (very?) unlikely, it isn't impossible so I'm not
> against this change. Normally, I'd worry about regressions but the test
> case coverage is good in this area.
>
> Any objections to implementing this? Thoughts on a better solution?
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: JSTL issue

[Jean-Louis MONTEIRO]

I've got an answer from JSTL team.
Here it is

Here is my take:
>
>1. Jakarta Tags Specification Section 7.4 details the  tag:
>c:import
>
> <https://github.com/eclipse-ee4j/jstl-api/blob/master/spec/src/main/asciidoc/jakarta-stl.adoc#74-cimport>
>
> Within this, it details the following: Character Encoding : The
>  for import-encoded.txt does not include an encoding so the
> default encoding is used: ISO-8859-1
>
>1. If I were to do the following: charEncoding="UTF-16"/> then we would not see the BOM since the proper
>encoding is used and would see the actual text in the file rather than
>garbled characters which is what the test is actually looking for, see
>below.
>
> This test is just checking the following:
>
> <%-- If encoding is not specified, and no encoding is specified in the
>  response of the imported resource, the default of ISO-8859-1
>  will be used. --%>
>
> As to whether or not to strip the BOM when the content type of the file
> uses a BOM and the content type being used does not use a BOM I disagree
> that it should be removed, and here is why:
>
>-
>
>The encoding defaults to ISO-8859-1 which as far as I know doesn't use
>the BOM so just including the text as is in the  seems
>reasonable to me.
>-
>
>Tomcat remove the BOM from the file even when the ISO-8859-1 encoding
>is used to read the UTF-16 encoded text which I don't see how that
>improves anything. It sounds like this is stripped outside of any Jakarta
>Tags or Jakarta Pages specification and is done as a specific change to
>Tomcat since Tomcat last was executed against the TCK.
>
> At this point from a Jakarta Tags perspective, I believe the golden file
> is correct.
>





Le mer. 14 avr. 2021 à 10:16, Jean-Louis MONTEIRO  a
écrit :

> Thanks for the answer.
>
> Do you mind adding the comment in the issue?
> I can copy/paste if not. It's just to give context to others
>
> Thanks
>
> Le mar. 13 avr. 2021 à 21:44, Mark Thomas  a écrit :
>
>> On 13/04/2021 20:17, Jean-Louis MONTEIRO wrote:
>> > Hi guys,
>> >
>> > I have one JSTL issue and I'd need your feedback on it.
>> > https://github.com/eclipse-ee4j/jstl-api/issues/140
>> >
>> > Can you guys have a look and let me know what you think?
>>
>> That looks like a side-effect of the various improvements we made to the
>> Default Servlet to do a better job of including content with a variety
>> of (potentially incompatible) encodings.
>>
>> Generally, I'd expect the BoM to be skipped.
>>
>> Historically, Tomcat didn't skip the BoM, so the original golden file
>> was generated on that basis.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
> --
> Jean-Louis
>


-- 
Jean-Louis

TCK WebSocket Failures

[Jean-Louis MONTEIRO]

Hi,

I've got some TCK failures

com.sun.ts.tests.websocket.ee.jakarta.websocket.session.WSClient#getRequestURITest
com.sun.ts.tests.websocket.ee.jakarta.websocket.session.WSClient#setTimeout1Test

com.sun.ts.tests.websocket.spec.servercontainer.addendpoint.WSClient#getRequestURITest
com.sun.ts.tests.websocket.spec.servercontainer.addendpoint.WSClient#setTimeout1Test

On the getRequestURITest, it fails because of

TCKBasicEndpoint OnOpenTCKTestServer openedsession
from Server is open=TRUETCKTestServer received String:
testName=getRequestURITestTCKTestServer: getRequestURI
returned=ws://localhost:57637/ws_session_web/TCKTestServer?test1=value1=value2=value3TCKTestServer:
getRequestURI returned
queryString=test1=value1=value2=value3TCKTestServer:
getRequestURI returned scheme=ws
> [MessageValidator] Scanning for search string: 'TCKBasicEndpoint OnOpen' 
> starting at index location: 0
> [MessageValidator] Found search string: 'TCKBasicEndpoint OnOpen' at index '0
> [MessageValidator] Scanning for search string: 'TCKTestServer opened' 
> starting at index location: 23
> [MessageValidator] Found search string: 'TCKTestServer opened' at index '31
> [MessageValidator] Scanning for search string: 'session from Server is 
> open=TRUE' starting at index location: 51
> [MessageValidator] Found search string: 'session from Server is open=TRUE' at 
> index '59
> [MessageValidator] Unable to find the following search stringTCKTestServer: 
> getRequestURI returned=/ws_session_web/TCKTestServer' at index: 156
> [MessageValidator] Scanning for search string: 'TCKTestServer received 
> String: testName=getRequestURITest' starting at index location: 91
> [MessageValidator] Found search string: 'TCKTestServer received String: 
> testName=getRequestURITest' at index '99
> [MessageValidator] Scanning for search string: 'TCKTestServer: getRequestURI 
> returned=/ws_session_web/TCKTestServer' starting at index location: 156
> 04-14-2021 14:14:35:  ERROR: Test Failed
> com.sun.ts.lib.harness.EETest$Fault: Test Failed
>
> Shouldn't this be requestURI.getPath()
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/websocket/ee/jakarta/websocket/session/WSTestServer.java#L291

Investigating the 2 others ...

-- 
Jean-Louis

Re: JSTL issue

[Jean-Louis MONTEIRO]

Thanks for the answer.

Do you mind adding the comment in the issue?
I can copy/paste if not. It's just to give context to others

Thanks

Le mar. 13 avr. 2021 à 21:44, Mark Thomas  a écrit :

> On 13/04/2021 20:17, Jean-Louis MONTEIRO wrote:
> > Hi guys,
> >
> > I have one JSTL issue and I'd need your feedback on it.
> > https://github.com/eclipse-ee4j/jstl-api/issues/140
> >
> > Can you guys have a look and let me know what you think?
>
> That looks like a side-effect of the various improvements we made to the
> Default Servlet to do a better job of including content with a variety
> of (potentially incompatible) encodings.
>
> Generally, I'd expect the BoM to be skipped.
>
> Historically, Tomcat didn't skip the BoM, so the original golden file
> was generated on that basis.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

JSTL issue

[Jean-Louis MONTEIRO]

Hi guys,

I have one JSTL issue and I'd need your feedback on it.
https://github.com/eclipse-ee4j/jstl-api/issues/140

Can you guys have a look and let me know what you think?

-- 
Jean-Louis

Re: TCK Failures on WebSocket

[Jean-Louis MONTEIRO]

That is in line with the "negdep" sub package Mark mentioned.
I will need to work to exclude the deployment failures in this situation.

Thanks a lot for the information

Le jeu. 8 avr. 2021 à 15:43, Konstantin Kolinko  a
écrit :

> чт, 8 апр. 2021 г. в 16:10, Jean-Louis MONTEIRO :
> >
> > Hi,
> >
> > I am running WebSocket TCK on TomEE and I'm having some issues.
> > Wondering if I missed some configuration.
> >
> > Essentially the TCK is deploying an application with this class
> >
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/websocket/negdep/onmessage/pasrv/nomoreendpoints/OnMessageServerEndpoint.java
> >
> > It fails to deploy
> >
> > Caused by: jakarta.websocket.DeploymentException: De multiples
> > paramètres de message sont présents sur la méthode [echo] de la classe
> >
> [com.sun.ts.tests.websocket.negdep.onmessage.srv.binarybytebufferint.OnMessageServerEndpoint]
> > qui a été annotée avec OnMessage
> >at
> org.apache.tomcat.websocket.pojo.PojoMethodMapping$MessageHandlerInfo.(PojoMethodMapping.java:543)
> >at
> org.apache.tomcat.websocket.pojo.PojoMethodMapping.(PojoMethodMapping.java:139)
> >at
> org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:154)
> >at
> org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:278)
> >at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:126)
> >
> >
> > From the wiki, Tomcat is supposed to be passing the WebSocket TCK.
> > Do you have pointers to help?
>
> 1. Your link above are for class in package "nomoreendpoints".
>
> 2. but the package name mentioned in the message is
> "*.binarybytebufferint.*".
>
>
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/websocket/negdep/onmessage/pasrv/nomoreendpoints/OnMessageServerEndpoint.java
>
>
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/websocket/negdep/onmessage/srv/binarybytebufferint/OnMessageServerEndpoint.java
>
> Either way, both classes are annotated with
> "@ServerEndpoint("/invalid")" and that path suggests that they are
> expected to fail.
>
>
> WebSocket spec (1.1) says that the requirements for methods annotated
> with @OnMessage are stated in javadoc for that annotation.
>
>
> https://cwiki.apache.org/confluence/display/TOMCAT/Specifications#Specifications-JavaAPIforWebSocket
> https://docs.oracle.com/javaee/7/api/javax/websocket/OnMessage.html
>
> 
> Each websocket endpoint may only have one message handling method for
> each of the native websocket message formats: text, binary and pong.
> 
>
> The class in package "nomoreendpoints":
> - It has two methods to handle text messages (full vs partial). It is
> not allowed.
>
> The class in package "binarybytebufferint":
> - Invalid parameters to handle partial binary messages. (expected:
> ByteBuffer + boolean, actual: ByteBuffer + int).
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: Jakarta EE - JASPIC TCK (nightly)

[Jean-Louis MONTEIRO]

Small update ...

I sent some PRs

https://github.com/eclipse-ee4j/jakartaee-tck/pull/706
https://github.com/eclipse-ee4j/jakartaee-tck/pull/707

When this gets merged, we are 100% coverage.
Tomcat 10.x JASPIC implementation is Jakarta EE 9.1 compatible



Le jeu. 12 nov. 2020 à 19:30, Jean-Louis MONTEIRO  a
écrit :

> Hi,
>
> Bumping this thread up. Sorry for the late reply. Been very busy getting
> Jakarta EE 9 out. Ballot if open till next Friday, so back into this issue.
>
> I created 2 tickets regarding JASPIC and I need to open another one for
> the issue discussed in this thread.
>
> https://github.com/eclipse-ee4j/jakartaee-tck/issues/570
> https://github.com/eclipse-ee4j/jakartaee-tck/issues/571
>
> I agree we need to clarify this part, as it looks most likely like a TCK
> bug.
> Anyway, thanks for the thoughts.
>
>
> Le jeu. 23 juil. 2020 à 16:18, Mark Thomas  a écrit :
>
>> Comments in line.
>>
>> On 22/07/2020 10:19, Jean-Louis MONTEIRO wrote:
>> > Hi,
>> >
>> > Small update on the progress.
>> > Passed: 52 and Failed: 9
>> >
>> > I had a lot of random passed/failed for quite a while and finally found
>> > the reason yesterday.
>>
>> I took a look at running these myself for Tomcat. There is a lot of
>> fiddly setup required. I may come back to this but for now I have other
>> priorities.
>>
>> > I'd be interested in having some thoughts
>> >
>> > AuthenticatorBase uses by default CallbackHandlerImpl
>> >
>> > The CallbackHandlerImpl will create the GenericPrincipal for the subject
>> > based on the supported callbacks (CallerPrincipalCallback
>> > and GroupPrincipalCallback).
>> >
>> > The AuthenticatorBase will pull the GenericPrincipal from the subject
>> > and do the register.
>> >
>> > Long story short, the TCK calls the CallbackHandlerImpl twice with the
>> > CallerCallback and another time with CallerCallback + GroupCallback. We
>> > end up having 2 GenericPrincipal in the subject, one with the name only
>> > and another one with the name and roles.
>> >
>> > JASPIC
>> > TCK
>> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaspic/tssv/module/servlet/TSServerAuthModule.java#L371
>> >
>> > See
>> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/jaspic/CallbackHandlerImpl.java#L96
>> >
>> > Issue is that AuthenticatorBase pulls the first one available.
>> > See
>> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/AuthenticatorBase.java#L956
>> >
>> > It will randomly pull the GenericPrincipal with the name only or the
>> > GenericPrincipal with the name and the roles.
>>
>> Nice find. That must have been a real pain to track down.
>>
>> I've been reading through the Jakarta Authentication specification (it
>> should be essentially identical to the previous JASPIC spec).
>>
>> From 3.8.3.1
>> 
>> ... handle a CallerPrincipalCallback using the clientSubject as argument
>> to the callback. If more than one module of a context uses the
>> CallbackHandler to handle this callback, the context is responsible for
>> coordinating the calls such that the appropriate caller principal value
>> is established.
>> 
>>
>> context here is referring to ServerAuthContext.
>>
>> I think, in this case, the ServerAuthContext is being provided by the
>> TCK so my first impression is that this is a TCK bug.
>>
>> I think this is worth raising on the Jakarta Authentication mailing lists.
>>
>> > I did a fork in TomEE of the CallbackHandlerImpl to merge the
>> > GenericPrincipal in the name is the same and switched the
>> > CallbackHandlerImpl class in the BasicAuthenticator valve.
>>
>> Yes, that is the same solution I thought of. Rather than add the newly
>> created GenericPrincipal to the Subject's private credentials, see if
>> the new GenericPrincipal has the same name as an existing
>> GenericPrincipal and if it does merge them.
>>
>> I'm not sure that would be safe to do in the general case though.
>>
>> Mark
>>
>>
>> >
>> > Hope it's more or less clear ;-)
>> > Some thoughts would be very helpfup
>> >
>> >
>> > Le ven. 17 juil. 2020 à 18:21, Mark Thomas > > <mailto:ma...@apache.org>> a écrit :
>> >
>> > On 17/07/2020 16:56, Jean-Louis MONTEIRO wrote:
>> > > Hi,
>> &

Re: TCK Failures on WebSocket

[Jean-Louis MONTEIRO]

Thanks. I'll look at how to treat those.

I have 2 more failures under
com.sun.ts.tests.websocket.ee.javax.websocket.session.WSClient
<https://tck.work/tomee/api/build/file/1617771682192/1342>
And 2 under
com.sun.ts.tests.websocket.spec.servercontainer.addendpoint.WSClient
<https://tck.work/tomee/api/build/file/1617771682192/1400>

But I'll investigate first and reach out if needed.

Le jeu. 8 avr. 2021 à 15:35, Mark Thomas  a écrit :

> On 08/04/2021 14:10, Jean-Louis MONTEIRO wrote:
> > Hi,
> >
> > I am running WebSocket TCK on TomEE and I'm having some issues.
> > Wondering if I missed some configuration.
> >
> > Essentially the TCK is deploying an application with this class
> >
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/websocket/negdep/onmessage/pasrv/nomoreendpoints/OnMessageServerEndpoint.java
> >
> > It fails to deploy
>
> That is expected. From memory all the ...negdep... tests are expected to
> fail deployment.
>
> Mark
>
>
> >
> > Caused by: jakarta.websocket.DeploymentException: De multiples
> > paramètres de message sont présents sur la méthode [echo] de la classe
> >
> [com.sun.ts.tests.websocket.negdep.onmessage.srv.binarybytebufferint.OnMessageServerEndpoint]
> > qui a été annotée avec OnMessage
> > at
> org.apache.tomcat.websocket.pojo.PojoMethodMapping$MessageHandlerInfo.(PojoMethodMapping.java:543)
> > at
> org.apache.tomcat.websocket.pojo.PojoMethodMapping.(PojoMethodMapping.java:139)
> > at
> org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:154)
> > at
> org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:278)
> > at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:126)
> >
> >
> >  From the wiki, Tomcat is supposed to be passing the WebSocket TCK.
> > Do you have pointers to help?
> >
> > Thanks
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

TCK Failures on WebSocket

[Jean-Louis MONTEIRO]

Hi,

I am running WebSocket TCK on TomEE and I'm having some issues.
Wondering if I missed some configuration.

Essentially the TCK is deploying an application with this class
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/websocket/negdep/onmessage/pasrv/nomoreendpoints/OnMessageServerEndpoint.java

It fails to deploy

Caused by: jakarta.websocket.DeploymentException: De multiples
paramètres de message sont présents sur la méthode [echo] de la classe
[com.sun.ts.tests.websocket.negdep.onmessage.srv.binarybytebufferint.OnMessageServerEndpoint]
qui a été annotée avec OnMessage
   at 
org.apache.tomcat.websocket.pojo.PojoMethodMapping$MessageHandlerInfo.(PojoMethodMapping.java:543)
   at 
org.apache.tomcat.websocket.pojo.PojoMethodMapping.(PojoMethodMapping.java:139)
   at 
org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:154)
   at 
org.apache.tomcat.websocket.server.WsServerContainer.addEndpoint(WsServerContainer.java:278)
   at org.apache.tomcat.websocket.server.WsSci.onStartup(WsSci.java:126)


>From the wiki, Tomcat is supposed to be passing the WebSocket TCK.
Do you have pointers to help?

Thanks

-- 
Jean-Louis

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  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  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 1 avr. 2021 à 09:19, Mark Thomas  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: dev-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: dev-h...@tomcat.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

[TCK] JSTL failure

[Jean-Louis MONTEIRO]

Hi,

I have been using Tomcat Taglib (shaded with Xalan and Serializer).
Works quite well on TomEE but I have one failure I'd like to discuss with
you before possibly opening a challenge.

https://tck.work/tomee/tests?path=com.sun.ts.tests.jstl=1608116575927=FAILED

I have fixed 4 or the 5,
but com.sun.ts.tests.jstl.spec.core.urlresource.importtag.JSTLClient is
still failing and I don't understand how to fix it.

Here is the JSP
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.jsp

Here is the expected result
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/positiveImportEncodingNotSpecifiedTest.gf

The first file imported is
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/encoding/Encoding.jsp

And the second
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/web/jstl/spec/core/urlresource/importtag/import-encoded.txt

In the golden file, there seems to be 2 extra characters.
Here is the full log file for the test run

https://tck.work/tomee/api/testlog/1218/1608116849515

Any thoughts?
The result from Tomcat looks ok to me unless I missed something.



-- 
Jean-Louis

Re: EE 8 / 9 TCK status

[Jean-Louis MONTEIRO]

No I did not. Thanks for the pointer. I'll check it out

Le mar. 17 nov. 2020 à 10:18, Romain Manni-Bucau  a
écrit :

> Hi JL,
>
> did you check
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs out?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 17 nov. 2020 à 10:16, Jean-Louis MONTEIRO  a
> écrit :
>
> > Hello community,
> >
> > I'm working on the TCK in the TomEE project which leverages Tomcat.
> > I was running the TCK and I realized JSTL/JSP/Servlet/WebSockets aren't
> > 100% green.
> >
> > I'm questioning my setup. That's why I wanted to ask if you guys spent
> time
> > running the TCK against Tomcat. And if yes, is Tomcat 100% compatible?
> >
> > --
> > Jean-Louis
> >
>


-- 
Jean-Louis

EE 8 / 9 TCK status

[Jean-Louis MONTEIRO]

Hello community,

I'm working on the TCK in the TomEE project which leverages Tomcat.
I was running the TCK and I realized JSTL/JSP/Servlet/WebSockets aren't
100% green.

I'm questioning my setup. That's why I wanted to ask if you guys spent time
running the TCK against Tomcat. And if yes, is Tomcat 100% compatible?

-- 
Jean-Louis

Re: Jakarta EE - JASPIC TCK (nightly)

[Jean-Louis MONTEIRO]

Hi,

Bumping this thread up. Sorry for the late reply. Been very busy getting
Jakarta EE 9 out. Ballot if open till next Friday, so back into this issue.

I created 2 tickets regarding JASPIC and I need to open another one for the
issue discussed in this thread.

https://github.com/eclipse-ee4j/jakartaee-tck/issues/570
https://github.com/eclipse-ee4j/jakartaee-tck/issues/571

I agree we need to clarify this part, as it looks most likely like a TCK
bug.
Anyway, thanks for the thoughts.


Le jeu. 23 juil. 2020 à 16:18, Mark Thomas  a écrit :

> Comments in line.
>
> On 22/07/2020 10:19, Jean-Louis MONTEIRO wrote:
> > Hi,
> >
> > Small update on the progress.
> > Passed: 52 and Failed: 9
> >
> > I had a lot of random passed/failed for quite a while and finally found
> > the reason yesterday.
>
> I took a look at running these myself for Tomcat. There is a lot of
> fiddly setup required. I may come back to this but for now I have other
> priorities.
>
> > I'd be interested in having some thoughts
> >
> > AuthenticatorBase uses by default CallbackHandlerImpl
> >
> > The CallbackHandlerImpl will create the GenericPrincipal for the subject
> > based on the supported callbacks (CallerPrincipalCallback
> > and GroupPrincipalCallback).
> >
> > The AuthenticatorBase will pull the GenericPrincipal from the subject
> > and do the register.
> >
> > Long story short, the TCK calls the CallbackHandlerImpl twice with the
> > CallerCallback and another time with CallerCallback + GroupCallback. We
> > end up having 2 GenericPrincipal in the subject, one with the name only
> > and another one with the name and roles.
> >
> > JASPIC
> > TCK
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaspic/tssv/module/servlet/TSServerAuthModule.java#L371
> >
> > See
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/jaspic/CallbackHandlerImpl.java#L96
> >
> > Issue is that AuthenticatorBase pulls the first one available.
> > See
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/AuthenticatorBase.java#L956
> >
> > It will randomly pull the GenericPrincipal with the name only or the
> > GenericPrincipal with the name and the roles.
>
> Nice find. That must have been a real pain to track down.
>
> I've been reading through the Jakarta Authentication specification (it
> should be essentially identical to the previous JASPIC spec).
>
> From 3.8.3.1
> 
> ... handle a CallerPrincipalCallback using the clientSubject as argument
> to the callback. If more than one module of a context uses the
> CallbackHandler to handle this callback, the context is responsible for
> coordinating the calls such that the appropriate caller principal value
> is established.
> 
>
> context here is referring to ServerAuthContext.
>
> I think, in this case, the ServerAuthContext is being provided by the
> TCK so my first impression is that this is a TCK bug.
>
> I think this is worth raising on the Jakarta Authentication mailing lists.
>
> > I did a fork in TomEE of the CallbackHandlerImpl to merge the
> > GenericPrincipal in the name is the same and switched the
> > CallbackHandlerImpl class in the BasicAuthenticator valve.
>
> Yes, that is the same solution I thought of. Rather than add the newly
> created GenericPrincipal to the Subject's private credentials, see if
> the new GenericPrincipal has the same name as an existing
> GenericPrincipal and if it does merge them.
>
> I'm not sure that would be safe to do in the general case though.
>
> Mark
>
>
> >
> > Hope it's more or less clear ;-)
> > Some thoughts would be very helpfup
> >
> >
> > Le ven. 17 juil. 2020 à 18:21, Mark Thomas  > <mailto:ma...@apache.org>> a écrit :
> >
> > On 17/07/2020 16:56, Jean-Louis MONTEIRO wrote:
> > > Hi,
> > >
> > > Following up on this thread.
> > > Pretty old I know. Haven't seen more recent topics on JASPIC and
> > Jakarta
> > > EE TCK.
> > >
> > > I tried to invest some time in TomEE to run the JASPIC TCK which is
> > > fully relying on Tomcat.
> > > I have counted 68 tests under the package com.sun.ts.tests.jaspic
> > >
> > > The wiki says 100+ so dunno where I'm missing some.
> > >
> > > Long story short, after some time configuring the thing, I've got
> > >
> > > Passed: 38
> > > Failed: 30
> > >
> > > Anyone looked at it

Re: TCK status

[Jean-Louis MONTEIRO]

Thanks Mark for the update.
Some specs are final already.

Some are still being worked on, like WebSocket which is a bit late at
the moment.
If you are willing to help on this one, feel free to jump in.

Le sam. 3 oct. 2020 à 20:39, Mark Thomas  a écrit :

> Hi all,
>
> I mentioned TCK status during a couple of ApacheCon presentations.
> Having checked the current status I thought it would be worth sending a
> brief note to the list. More detail is on the wiki:
> https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+TCKs
>
> The short version is:
>
> - EL: all tests pass
> - JSP: all tests pass (once the TCK regression is fixed)
> - WebSocket: all tests pass
> - Servlet: one failure (expected)
>
> So, all good. No issues.
>
> Mark
>
> P.S. If you are wondering the servlet failure is because Tomcat ignores
> any suggested context path in web.xml and will ALWAYS derive the context
> path from the file name to avoid ambiguities and conflicts.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: Jakarta EE - JASPIC TCK (nightly)

[Jean-Louis MONTEIRO]

Hi,

Small update on the progress.
Passed: 52 and Failed: 9

I had a lot of random passed/failed for quite a while and finally found the
reason yesterday.

I'd be interested in having some thoughts

AuthenticatorBase uses by default CallbackHandlerImpl

The CallbackHandlerImpl will create the GenericPrincipal for the subject
based on the supported callbacks (CallerPrincipalCallback
and GroupPrincipalCallback).

The AuthenticatorBase will pull the GenericPrincipal from the subject and
do the register.

Long story short, the TCK calls the CallbackHandlerImpl twice with the
CallerCallback and another time with CallerCallback + GroupCallback. We end
up having 2 GenericPrincipal in the subject, one with the name only and
another one with the name and roles.

JASPIC TCK
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaspic/tssv/module/servlet/TSServerAuthModule.java#L371

See
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/jaspic/CallbackHandlerImpl.java#L96

Issue is that AuthenticatorBase pulls the first one available. See
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/AuthenticatorBase.java#L956

It will randomly pull the GenericPrincipal with the name only or the
GenericPrincipal with the name and the roles.

I did a fork in TomEE of the CallbackHandlerImpl to merge the
GenericPrincipal in the name is the same and switched the
CallbackHandlerImpl class in the BasicAuthenticator valve.

Hope it's more or less clear ;-)
Some thoughts would be very helpfup


Le ven. 17 juil. 2020 à 18:21, Mark Thomas  a écrit :

> On 17/07/2020 16:56, Jean-Louis MONTEIRO wrote:
> > Hi,
> >
> > Following up on this thread.
> > Pretty old I know. Haven't seen more recent topics on JASPIC and Jakarta
> > EE TCK.
> >
> > I tried to invest some time in TomEE to run the JASPIC TCK which is
> > fully relying on Tomcat.
> > I have counted 68 tests under the package com.sun.ts.tests.jaspic
> >
> > The wiki says 100+ so dunno where I'm missing some.
> >
> > Long story short, after some time configuring the thing, I've got
> >
> > Passed: 38
> > Failed: 30
> >
> > Anyone looked at it already since Feb 2019?
>
> I'm probably the most likely candidate and I haven't looked at it.
>
> Mark
>
>
> >
> >
> > Le lun. 11 févr. 2019 à 21:34, Mark Thomas  > <mailto:ma...@apache.org>> a écrit :
> >
> > All,
> >
> > I've started to look at the Jakarta EE JASPIC TCK.
> >
> > Again a nightly build so usual caveats apply.
> >
> > Progress is being tracked here:
> > https://cwiki.apache.org/confluence/display/TOMCAT/JASPIC+TCK
> >
> > Hmm.
> >
> > This TCK seems very different to the standalone TCKs for the other
> specs
> > we implement.
> > - Deployment is significantly more complex. Rather than just WARs
> there
> >   are some JARS that need to be extracted and rename from EARs.
> > - It seems to need the RI up and running for the tests.
> >
> >
> > I'm giving up on this for now. I may come back to it at some point
> but I
> > think it is more likely that I won't.
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > <mailto:dev-unsubscr...@tomcat.apache.org>
> > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > <mailto:dev-h...@tomcat.apache.org>
> >
> >
> >
> > --
> > Jean-Louis
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: Jakarta EE - JASPIC TCK (nightly)

[Jean-Louis MONTEIRO]

Hi,

Following up on this thread.
Pretty old I know. Haven't seen more recent topics on JASPIC and Jakarta EE
TCK.

I tried to invest some time in TomEE to run the JASPIC TCK which is fully
relying on Tomcat.
I have counted 68 tests under the package com.sun.ts.tests.jaspic

The wiki says 100+ so dunno where I'm missing some.

Long story short, after some time configuring the thing, I've got

Passed: 38
Failed: 30

Anyone looked at it already since Feb 2019?


Le lun. 11 févr. 2019 à 21:34, Mark Thomas  a écrit :

> All,
>
> I've started to look at the Jakarta EE JASPIC TCK.
>
> Again a nightly build so usual caveats apply.
>
> Progress is being tracked here:
> https://cwiki.apache.org/confluence/display/TOMCAT/JASPIC+TCK
>
> Hmm.
>
> This TCK seems very different to the standalone TCKs for the other specs
> we implement.
> - Deployment is significantly more complex. Rather than just WARs there
>   are some JARS that need to be extracted and rename from EARs.
> - It seems to need the RI up and running for the tests.
>
>
> I'm giving up on this for now. I may come back to it at some point but I
> think it is more likely that I won't.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Re: Plans to get GenericPrincipal to inherit CallerPrincipal?

[Jean-Louis MONTEIRO]

Hello Mark,

Thanks for the quick response.
I was checking out if there were plans for it.

Glad it's on your radar.
I'm currently writing an Apache implementation on the TomEE side for the
Security API.

So definitely interested.
Would it help if I create a ticket to track the progress?


Le lun. 6 juil. 2020 à 14:50, Mark Thomas  a écrit :

> On 06/07/2020 12:43, Jean-Louis MONTEIRO wrote:
> > Hi,
> >
> > I would like to know if there are any plans to get GenericPrincipal to
> > inherit CallerPrincipal?
> > From a backward compatibility perspective, it does not seem to hurt
> > because the getName() is already in the GenericPrincipal.
> >
> > The question comes because I was reading the Java Security API and this
> > chapter
> >
> https://javaee.github.io/security-spec/spec/jsr375-spec.html#_caller_principal_types
> >
> > Seems to advise that app server should inherit from CallerPrincipal.
>
> JSR-375 was released after Java EE 8 - i.e. too late for Tomcat 9.
>
> Tomcat implements JASPIC, now Jakarta Authentication. We do need to look
> at what is changed in that spec for Jakarta EE 9 (Tomcat 10) - which
> should be very little.
>
> I don't think anyone has looked at looked at the Jakarta Security 2.0
> spec for Jakarta EE 9 (Tomcat 10). I agree having GenericPrincipal
> extend CallerPrincipal should be low impact. However, it would need to
> be looked at in the wider context of the entire spec. We can't just pick
> a single class. Taking a quick look the spec depends on CDI which Tomcat
> does not support. Adding a dependency to that JAR just to extend
> CallerPrincipal seems a little excessive at this point.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

-- 
Jean-Louis

Plans to get GenericPrincipal to inherit CallerPrincipal?

[Jean-Louis MONTEIRO]

Hi,

I would like to know if there are any plans to get GenericPrincipal to
inherit CallerPrincipal?
>From a backward compatibility perspective, it does not seem to hurt because
the getName() is already in the GenericPrincipal.

The question comes because I was reading the Java Security API and this
chapter
https://javaee.github.io/security-spec/spec/jsr375-spec.html#_caller_principal_types

Seems to advise that app server should inherit from CallerPrincipal.

Thanks

-- 
Jean-Louis

Re: FW: JSR 236 with tomcat 8

[Jean-Louis MONTEIRO]

Hi,

works out of the box in TomEE.

JLouis

Le Tue Nov 25 2014 at 11:55:42, shailendra singh shailendra...@outlook.com
a écrit :

 After posting my question to Tomcat users mailing list I realized that I
 should have posted my question to this mailing list.  Hence this email.

 Some of the information is already mentioned in my previous email which I
 sent to Tomcat users mailing list.

 Basically I am trying to figure out what is the proper way to do multi
 threading in a servlet container like tomcat.  Java EE spec mentions that
 it should be done using JSR 236 api but I am unable to find a way to do so
 as it seems that available implementations for this JSR have dependency on
 EJB api. So if JSR 236 is for doing multi threading in an application
 server then what is/are the options for servlet containers like tomcat?

 - Shailendra

 From: shailendra...@outlook.com
 To: us...@tomcat.apache.org
 Subject: RE: JSR 236 with tomcat 8
 Date: Tue, 25 Nov 2014 05:53:46 +




 JSR 236 seems to be only way to create managed threads in Java EE
 servlet/ejb containers. I am working on a framework (piston -
 http://github.com/koyadume/piston-master) which I am supporting on tomcat
 only. Since this framework is based on Java EE 7, I can't use TomEE at this
 moment.

 I would like to split some tasks in multiple parallel tasks in my
 framework. As it is advised not to create own threads in a Java EE
 servlet/containers, I would like to avoid using Java SE concurrency
 utilities to solve this issue. This is the issue which JSR 236 tries to
 solve. Hopefully this makes my intention clear.


  Date: Mon, 24 Nov 2014 22:36:55 -0500
  Subject: Re: JSR 236 with tomcat 8
  From: john.d.am...@gmail.com
  To: us...@tomcat.apache.org
 
  Concurrency utils is specific to app servers, where applications are
  generally unable to create or manage threads.  This is an old EJB
  limitation.
 
  This limitation is not present in servlet containers.
 
  Why do you think you need them?
 
  On Mon, Nov 24, 2014 at 9:58 PM, shailendra singh
  shailendra...@outlook.com wrote:
   Hi,
  
   I am looking for a way to use JSR 236 with tomcat 8.  Can someone
 please suggest a way to achieve this?
  
   - Shailendra
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 

AuthenticatorBase bug using SSL?

[Jean-Louis MONTEIRO]

Hello guys,

I'm currently facing an issue with the BaseAuthenticator.
Before opening a issue on the bug tracker, I'd like to get your opinion
guys.

The use case is simple: use an HTTPS tomcat connector with mutual
authentication (CLIENT-CERT).

It does not involve at all any front serveur like Apache HTTPD.

Everything works fine until you want to add the SSLAuthenticator valve with
the preemptive mode.
At the end of the invoke method (AuthenticatorBase), the presence of the
X509 certificate is checked under the usual key (ie.
request.getAttribute(Globals.CERTIFICATES_ATTR)).

This works fine when using an Apache HTTPD front, but does not work with
tomcat SSL connectors cause the request is not populated.

If you check the Authenticate of the SSLAuthenticator that should be invoke
is a certificate is found, if nothing is found in the request under the
usual key, the following is done before trying again

request.getCoyoteRequest().action(ActionCode.REQ_SSL_CERTIFICATE, null);

Roughly and simply speaking, the certificat is going to be extracted from
the coyote request and the entry in the HTTP request is populated.

I'm wondering why it's not done also in the AuthenticatorBase?
It makes it impossible to use the preemptive mode with the SSLAuthenticator
valve.

I think creating a getRequestCertificate() method in the AuthenticatorBase
that wraps up the logic of calling or not the coyote request would do the
trick. Then it's just a matter of using it in the invoke method
(AuthenticatorBase) or in the authenticate (SSLAuthenticator).

Feedback welcome so that I can create a JIRA and submit a patch if you want.

-- 
Jean-Louis

Re: AuthenticatorBase bug using SSL?

[Jean-Louis MONTEIRO]

2014-08-06 16:19 GMT+02:00 Mark Thomas ma...@apache.org:

 On 06/08/2014 14:54, Jean-Louis MONTEIRO wrote:
  Hello guys,
 
  I'm currently facing an issue with the BaseAuthenticator.
  Before opening a issue on the bug tracker, I'd like to get your opinion
  guys.

 The members of this list include both men and women. Please use a more
 inclusive term than guys.


My apologize if I offended someone, it was definitely my intention.

I've always used you guys when addressing a group of men, or a group of
women, or a group of mixed gender.
English is not my main langage, that's why I probably abused the term.

Never heard girls or ladies complaining until now. Amazing situation that a
guy is actually complaining :)

Not the purpose of the post nor the mailing list.
Thanks anyway for the answer, I gonna open an issue.

Jean-Louis

Re: request.getUserPrincipal() returns null in a ServletRequestListener#requestInitialized in tc-7.0.54

[Jean-Louis MONTEIRO]

It should return at least always a non null principal AFAIR, isn't it?


2014-08-04 19:33 GMT+02:00 Mark Struberg strub...@yahoo.de:

 Hi!

 I've recently found out that getUserPrincipal() returns null in a Listener
 [1].
 I remember that this used to return the correct Principal in older
 versions (might be some time already).
 Also from reading the spec I assumed it should work.

 Any infos on this?

 LieGrue,
 strub


 [1]
 http://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tomcat7/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityListener.java




-- 
Jean-Louis

Re: request.getUserPrincipal() returns null in a ServletRequestListener#requestInitialized in tc-7.0.54

[Jean-Louis MONTEIRO]

oups thanks Romain


2014-08-04 22:09 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:

 Returns a java.security.Principal object containing the name of the
 current authenticated user. If the user has not been authenticated,
 the method returns null.


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-08-04 22:04 GMT+02:00 Jean-Louis MONTEIRO jeano...@gmail.com:
  It should return at least always a non null principal AFAIR, isn't it?
 
 
  2014-08-04 19:33 GMT+02:00 Mark Struberg strub...@yahoo.de:
 
  Hi!
 
  I've recently found out that getUserPrincipal() returns null in a
 Listener
  [1].
  I remember that this used to return the correct Principal in older
  versions (might be some time already).
  Also from reading the spec I assumed it should work.
 
  Any infos on this?
 
  LieGrue,
  strub
 
 
  [1]
 
 http://svn.apache.org/repos/asf/openwebbeans/trunk/webbeans-tomcat7/src/main/java/org/apache/webbeans/web/tomcat/TomcatSecurityListener.java
 
 
 
 
  --
  Jean-Louis

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




-- 
Jean-Louis

Re: Reg: Availability of Tomcat 7.0.51 for download

[Jean-Louis MONTEIRO]

Hi,

AFAIK, Tomcat 7.0.51 won't get published.
The 7.0.52 hit Apache repo and the download page should be updated soon I
guess.

JLouis


2014-02-19 10:57 GMT+01:00 Tushar Agrawal tushar_agra...@symantec.com:

 Hello,

 We are using Tomcat in one of the Symantec product. I would like to know
 by when Tomcat 7.0.51 will be available for download?

 Currently we are using Tomcat 7.0.42. Because of CVE-2014-0050, a DoS
 vulnerability, we have to update Tomcat to 7.0.51. We presume later version
 would have fix for this vulnerability.
 Note that we cannot update to Tomcat 8.0.3 (beta) that has fix for above
 vulnerability.

 I would appreciate if you can share Tomcat 7.0.51 release dates.

 Thank you.

 Regards,
 Tushar




-- 
Jean-Louis

Re: Reg: Availability of Tomcat 7.0.51 for download

[Jean-Louis MONTEIRO]

Do you plan to also update the
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html page
And of course the home page http://tomcat.apache.org/

Thanks anyway for the release and the great job.

JLouis


2014-02-19 13:43 GMT+01:00 Violeta Georgieva miles...@gmail.com:

 2014-02-19 11:59 GMT+02:00 Jean-Louis MONTEIRO jeano...@gmail.com:
 
  Hi,
 
  AFAIK, Tomcat 7.0.51 won't get published.
  The 7.0.52 hit Apache repo and the download page should be updated soon I
  guess.

 Tomcat 7.0.52 is available on the download page.

 Enjoy.

 Regards
 Violeta

  JLouis
 
 
  2014-02-19 10:57 GMT+01:00 Tushar Agrawal tushar_agra...@symantec.com:
 
   Hello,
  
   We are using Tomcat in one of the Symantec product. I would like to
 know
   by when Tomcat 7.0.51 will be available for download?
  
   Currently we are using Tomcat 7.0.42. Because of CVE-2014-0050, a DoS
   vulnerability, we have to update Tomcat to 7.0.51. We presume later
 version
   would have fix for this vulnerability.
   Note that we cannot update to Tomcat 8.0.3 (beta) that has fix for
 above
   vulnerability.
  
   I would appreciate if you can share Tomcat 7.0.51 release dates.
  
   Thank you.
  
   Regards,
   Tushar
  
  
 
 
  --
  Jean-Louis




-- 
Jean-Louis

Re: Reg: Availability of Tomcat 7.0.51 for download

[Jean-Louis MONTEIRO]

Awesome!

JLouis


2014-02-19 13:55 GMT+01:00 Violeta Georgieva miles...@gmail.com:

 2014-02-19 14:53 GMT+02:00 Jean-Louis MONTEIRO jeano...@gmail.com:
 
  Do you plan to also update the
  http://tomcat.apache.org/tomcat-7.0-doc/changelog.html page
  And of course the home page http://tomcat.apache.org/

 They are updated, just refresh them.

 Regards
 Violeta

  Thanks anyway for the release and the great job.
 
  JLouis
 
 
  2014-02-19 13:43 GMT+01:00 Violeta Georgieva miles...@gmail.com:
 
   2014-02-19 11:59 GMT+02:00 Jean-Louis MONTEIRO jeano...@gmail.com:
   
Hi,
   
AFAIK, Tomcat 7.0.51 won't get published.
The 7.0.52 hit Apache repo and the download page should be updated
 soon I
guess.
  
   Tomcat 7.0.52 is available on the download page.
  
   Enjoy.
  
   Regards
   Violeta
  
JLouis
   
   
2014-02-19 10:57 GMT+01:00 Tushar Agrawal 
 tushar_agra...@symantec.com
 :
   
 Hello,

 We are using Tomcat in one of the Symantec product. I would like to
   know
 by when Tomcat 7.0.51 will be available for download?

 Currently we are using Tomcat 7.0.42. Because of CVE-2014-0050, a
 DoS
 vulnerability, we have to update Tomcat to 7.0.51. We presume later
   version
 would have fix for this vulnerability.
 Note that we cannot update to Tomcat 8.0.3 (beta) that has fix for
   above
 vulnerability.

 I would appreciate if you can share Tomcat 7.0.51 release dates.

 Thank you.

 Regards,
 Tushar


   
   
--
Jean-Louis
  
 
 
 
  --
  Jean-Louis




-- 
Jean-Louis

Re: Any ETA on 7.0.48 vote?

[Jean-Louis MONTEIRO]

+1
Would be great if we could get a 7.0.48.

Thanks
Jean-Louis


2013/12/1 Bob DeRemer bob.dere...@thingworx.com

 Is a vote on 7.0.48 expected anytime in the near future?

 Thanks,
 Bob




-- 
Jean-Louis