Re: JAXB not available on Tomcat 9 and Java 10
Hi Christopher, unfortunately that didn't change the observable behavior - exact same error message as when the JARs were in the application's lib folder. so long ... Nicolai On 26.07.2018 17:37, Christopher Schultz wrote: > Nicolai, > > On 7/26/18 6:41 AM, Nicolai Parlog wrote: >> Hi! > >> TL;DR: On Java 10.0.1, a web app in Tomcat 9.0.8.0 has no access >> to JAXB even though its reference implementation is present on >> the class path. > >> (This looks like a bug to me, but "Before you report a bug" >> urged me to ask here first. :) ) > >> NOTE: I already asked [on >> StackOverflow](https://stackoverflow.com/q/51518781/2525313), >> where the question is a little more readable. > >> On to the details... > >> # The Situation > >> We have a web app that runs on Tomcat and depends on JAXB. >> During our migration to Java 9 we opted for adding [the JAXB >> reference implementation as a regular >> dependency](https://stackoverflow.com/a/48204154/2525313). > >> Everything worked when launching the app from the IDE [with >> embedded >> Tomcat](https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catali > >> na/startup/Tomcat.html), > > > but when running it on a real Tomcat instance, I get this error: > >> Caused by: java.lang.RuntimeException: >> javax.xml.bind.JAXBException: Implementation of JAXB-API has not >> been found on module path or classpath. - with linked exception: >> [java.lang.ClassNotFoundException: >> com.sun.xml.internal.bind.v2.ContextFactory] at [... our-code >> ...] Caused by: javax.xml.bind.JAXBException: Implementation of >> JAXB-API has not been found on module path or classpath. at >> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:278) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.ContextFinder.find(ContextFinder.java:421) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:721) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:662) >> ~[jaxb-api-2.3.0.jar:2.3.0] at [... our-code ...] Caused by: >> java.lang.ClassNotFoundException: >> com.sun.xml.internal.bind.v2.ContextFactory at >> jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.ja > >> va:582) > > > ~[?:?] >> at >> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders > >> .java:190) > > > ~[?:?] >> at java.lang.ClassLoader.loadClass(ClassLoader.java:499) ~[?:?] >> at >> javax.xml.bind.ServiceLoaderUtil.nullSafeLoadClass(ServiceLoaderUtil.j > >> ava:122) > > > ~[jaxb-api-2.3.0.jar:2.3.0] >> at >> javax.xml.bind.ServiceLoaderUtil.safeLoadClass(ServiceLoaderUtil.java: > >> 155) > > > ~[jaxb-api-2.3.0.jar:2.3.0] >> at >> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:276) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.ContextFinder.find(ContextFinder.java:421) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:721) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:662) >> ~[jaxb-api-2.3.0.jar:2.3.0] at [... our-code ...] > >> Note: > >>> Implementation of JAXB-API has not been found on module path >>> or classpath. > >> These are the relevant files in `webapps/$app/WEB-INF/lib`: > >> jaxb-api-2.3.0.jar jaxb-core-2.3.0.jar jaxb-impl-2.3.0.jar > >> What is going on here? > >> # What I tried > >> ## Adding JARs > >> Maybe it helps to add the JARs to Tomcat's class path in >> `setenv.sh`? > >> CLASSPATH= .../webapps/$app/WEB-INF/lib/jaxb-api-2.3.0.jar: >> .../webapps/$app/WEB-INF/lib/jaxb-impl-2.3.0.jar: >> .../webapps/$app/WEB-INF/lib/jaxb-core-2.3.0.jar: >> .../webapps/$app/WEB-INF/lib/javax.activation-1.2.0.jar > >> Nope: > >> Caused by: javax.xml.bind.JAXBException: ClassCastException: >> attempting to cast >> jar:file:.../webapps/$app/WEB-INF/lib/jaxb-api-2.3.0.jar!/javax/xml/bi > >> nd/JAXBContext.class >> to >> jar:file:.../webapps/$app/WEB-INF/lib/jaxb-api-2.3.0.jar!/javax/xml/bi > >> nd/JAXBContext.class. > > > Please make sure that you are specifying the proper ClassLoader. >> at >> javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.ja > >> va:157) > > > ~[jaxb-api-2.3.0.jar:2.3.0] >> at >> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:300) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:286) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.ContextFinder.find(ContextFinder.java:409) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:721) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:662) >> ~[jaxb-api-2.3.0.jar:2.3.0] at >> de.disy.gis.webmapserver.factory.DefaultWmsRequestFactory.initializeCo > >> mmandExtractor(DefaultWmsRequestFactory.java:103) > > > ~[cadenza-gis-webmapserver-7.7-SNAPSHOT.jar:7.6] >> at >>
Persist authenticated sessions across tomcat restarts
Hello, I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live servers: linux). I have successfully created a custom JAAS authentication, which works just fine. I have SSO enabled at the moment, but not sure if I really need it. I left the default StandardManager config in place, I do see the SESSIONS.ser get created upon a shutdown and I see it get removed upon startup, so I'm assuming it's reading it in... I'm expecting that once a user authenticates with the JAAS module one time, and has a valid session, if I restart tomcat on the backend, that user will NOT need to re-authenticate, but it appears to be kicking them back to the login screen after the restart, and it's not accepting their JSESSIONID cookie value, it's giving them a new one upon hitting a secured resource. >From what I've read, I believe that JAAS can cache an authenticated session, but it doesn't appear to be working for me. Is there something I'm missing? Also, I'm using form-login. Thank you, Tim
Re: FW: HttpServletResponse.sendError - missing message in error page
>
> -Original Message-
> From: Mark Thomas
> Sent: 26 юли 2018 г. 19:04
> To: Tomcat Users List
> Subject: Re: HttpServletResponse.sendError - missing message in error page
>
> On 26/07/2018 13:46, Assia Djambazova wrote:
> > Hello,
> >
> > I noticed that when using HttpServletResponse.sendError in Tomcat 7.0.90
> > with string message the message is no longer shown as the response is
> > displayed.
> >
> > I reproduce this with request to simple servlet:
> >
> >
> >
> > *public void doGet(HttpServletRequest request, HttpServletResponse
> > response) throws ServletException, IOException {
> > response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "TEST
> > ERROR MESSAGE");}*
> >
> > The result in the browser is different:
> >
> > In Tomcat 7.0.90 HTTP Status 500 ? Internal Server Error
>
> That question mark doesn't look right. I don't see it when I test this
> locally.
>
> > In Tomcat 7.0.88 HTTP Status 500 - TEST ERROR MESSAGE
> >
> > I think that this change is the cause [1]
>
> Correct.
>
> > However, this change looks incompatible with servlet spec and breaks our
> > integration tests. It seems to me from the spec [2] that the message should
> > be displayed: *The server defaults to creating the response to look like an
> > HTML-formatted server error page containing the specified message, setting
> > the content type to "text/html"*
>
> This is not a spec compliance issue. The ErrorReportValve is an optional
> component that is not enabled by default.
>
> (And the default settings of the ErrorReportValve) are spec compliant.)
>
> > I use the ErrorReportValve and showReport is set to false.
>
> Set showReport to true.
>
> > Reading [3]
> > doesn't clarify if error message is part of the error report or not and if
> > it should be displayed.
>
> It is implied but it could be clearer.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
Hi Mark,
> “It is implied but it could be clearer.”
Actually at least my logic leans to the other direction. The error
message is something that is provided to the end-users. It is meant to
be internationalized and be user-friendly. And you pass it via
sendError. However, error stack trace shouldn’t be visible and the
logic to hide it with showReport=false is good one. From one hand you
hide unnecessary and confusing info for end-users, plus you lower
security attacking vector to your app. And I can add that till version
7.0.88 it was working like that.
I agree that default ErrorReportValve is not something that has to be
backward compatible as the apps should have provided their own. Yet,
we were using the default as it was working very well and was covering
our needs.
Honestly I don’t see the purpose of this change. Here is the changed code:
7.0.88 > sb.append(smClient.getString("errorReportValve.statusHeader",
String.valueOf(statusCode), message)).append("");
7.0.90 > sb.append(smClient.getString("errorReportValve.statusHeader",
String.valueOf(statusCode), reason)).append("");
What is the reason to show ‘reason’ which is technical (like Internal
Server Error), instead of ‘message’ which is end-user text?
Can you rethink this change and if possible bring the old behavior?
Kind Regards,
Emil
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
