> I suggest you have a read here:
> https://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support
> The documentation covers the details you need to correctly configure
Tomcat
> and SSL and links to a related page about SSL configuration.
> Notice the line:
> Each secure connector must
Alternatively, see this :
https://wiki.shibboleth.net/confluence/display/SP3/JavaHowTo
On 16.03.2021 21:18, Christopher Schultz wrote:
Robert,
On 3/16/21 14:33, Robert Turner wrote:
Chris,
I'm not sure if it will do what you want, but when sourcing Java-based SAML
libraries for our use as
Yes, that's the one. It's not tied to the OneLogin service or any other. We
are successfully using it against Google Workspace SAML authentication, and
against test servers running KeyCloak, and hoping to use it against
Microsoft Azure as well (but I haven't confirmed that it definitely works
Robert,
On 3/16/21 14:33, Robert Turner wrote:
Chris,
I'm not sure if it will do what you want, but when sourcing Java-based SAML
libraries for our use as an SP, I too found that most of the libraries were
much larger and more complicated that I thought necessary. We went with the
(limited but
On Tue, Mar 16, 2021, 11:46 Robert Turner wrote:
> I suggest you have a read here:
> https://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support
> The documentation covers the details you need to correctly configure Tomcat
> and SSL and links to a related page about SSL configuration.
Chris,
I'm not sure if it will do what you want, but when sourcing Java-based SAML
libraries for our use as an SP, I too found that most of the libraries were
much larger and more complicated that I thought necessary. We went with the
(limited but simple to use) OneLogin libraries for our use
All,
I've got a system which is accepting one-legged, signed SAML responses
from trusted third parties and going all the right things. It's working
great.
It's time to look at doing the opposite: assembling our own SAML
responses, signing them, and sending them to another party.
I'm sure
I suggest you have a read here:
https://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support
The documentation covers the details you need to correctly configure Tomcat
and SSL and links to a related page about SSL configuration.
Notice the line:
Each secure connector must define at
> If you look at the stack trace, it tells you what the problem is:
> Caused by: java.lang.IllegalArgumentException: No SSLHostConfig
> element was found with the hostName [_default_] to match the
> defaultSSLHostConfigName for the connector [https-openssl-nio-8443]
> So it no longer looks like
If you look at the stack trace, it tells you what the problem is:
Caused by: java.lang.IllegalArgumentException: No SSLHostConfig
element was found with the hostName [_default_] to match the
defaultSSLHostConfigName for the connector [https-openssl-nio-8443]
So it no longer looks like you are
> Please provide full stacktrace
Please find full catlina log and I have already shared server.xml in trail
mail
16-Mar-2021 21:26:54.263 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
[Server/Service/Connector] failed to set property [compressableMimeType]
to
Please provide full stacktrace
On Tue, 16 Mar 2021 at 22:49, wrote:
>
> >> Your more recent exception log didn't include the "caused by" exception
> > --
> >> which is the actual failure details. Double-check that and make sure
> > it's
> >> the same issue.
> >>
> >> Also, use netstat to confirm
>> Your more recent exception log didn't include the "caused by" exception
> --
>> which is the actual failure details. Double-check that and make sure
> it's
>> the same issue.
>>
>> Also, use netstat to confirm you aren't using the ports already.
> Changing
>> it may just find another conflict
On 3/16/21 3:57 PM, dku...@ccilindia.co.in wrote:
Your more recent exception log didn't include the "caused by" exception
--
which is the actual failure details. Double-check that and make sure
it's
the same issue.
Also, use netstat to confirm you aren't using the ports already.
Changing
> Your more recent exception log didn't include the "caused by" exception
--
> which is the actual failure details. Double-check that and make sure
it's
> the same issue.
>
> Also, use netstat to confirm you aren't using the ports already.
Changing
> it may just find another conflict (although
Your more recent exception log didn't include the "caused by" exception --
which is the actual failure details. Double-check that and make sure it's
the same issue.
Also, use netstat to confirm you aren't using the ports already. Changing
it may just find another conflict (although less likely).
Thanks Chris, for sure we've got an upgrade on the roadmap for the next quarter
so we'll give the latest 8.5 a try.
Cheers.
/rt.
On 2021-03-16, 9:39 AM, "Christopher Schultz"
wrote:
Rick,
Any chance you can try-out 8.5.latest? Your version is super old. It's
possible it's a bug
Rick,
Any chance you can try-out 8.5.latest? Your version is super old. It's
possible it's a bug that was fixed in the (distant?) past.
-chris
On 3/16/21 09:33, Trudeau, Rick (Nokia - CA/Ottawa) wrote:
On 2021-03-04, 2:45 PM, "Trudeau, Rick (Nokia - CA/Ottawa)"
wrote:
Chris,
> Deepak,
> You already have some service listening on port 80 (IIS maybe?)
>
>
> from mobile (sorry for typos ;)
>
> We have changed the port still getting same error
> Maybe you have the same port configured twice in your conf/server.xml?
> Please post *all* elements from your
On 2021-03-04, 2:45 PM, "Trudeau, Rick (Nokia - CA/Ottawa)"
wrote:
Chris,
On 2021-03-04, 12:07 PM, "Christopher Schultz"
wrote:
Rick,
On 3/3/21 09:23, Trudeau, Rick (Nokia - CA/Ottawa) wrote:
>
> Tomcat version: 8.5.34
>
> Hello,
Deepak,
On 3/16/21 09:03, dku...@ccilindia.co.in wrote:
You already have some service listening on port 80 (IIS maybe?)
from mobile (sorry for typos ;)
We have changed the port still getting same error
Maybe you have the same port configured twice in your conf/server.xml?
Please post
Alex,
On 3/15/21 23:48, My Subs wrote:
On Mon, 15 Mar 2021 11:25:17 -0500 Christopher Schultz
wrote
> Alex,
>
> On 3/13/21 10:20, My Subs wrote:
> > On Fri, 12 Mar 2021 20:24:48 -0500 Christopher Schultz
wrote
> >
> > >
> > > Alex,
> > >
> > >
You already have some service listening on port 80 (IIS maybe?)
from mobile (sorry for typos ;)
We have changed the port still getting same error
16-Mar-2021 18:09:38.299 INFO [main]
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
["http-nio-81"]
16-Mar-2021 18:09:38.363
You already have some service listening on port 80 (IIS maybe?)
from mobile (sorry for typos ;)
On Tue, Mar 16, 2021, 18:36 wrote:
> Dear All,
>
> Unable to start tomcat 10.0.4 and getting error Failed to initialize
> component.
> /conf/server.xml configuration as below.
>
>
It's saying port 80 is already in use. Make sure another process (like IIS)
isn't using the port already, or change your configuration to a different
port.
You can use 'netstat' (with options) to determine which process is using
the port already.
On Tue., Mar. 16, 2021, 07:36 , wrote:
> Dear
Dear All,
Unable to start tomcat 10.0.4 and getting error Failed to initialize
component.
/conf/server.xml configuration as below.
Getting below error in catalina log
Server version name: Apache Tomcat/10.0.4
Server built: Mar 5 2021 11:07:15 UTC
Server version
On 16/03/2021 02:48, Rob Sargent wrote:
Last sentence of Introduction on
https://tomcat.apache.org/tomcat-9.0-doc/logging.html
If it used directly or indirectly by your logging library then
elements of it will be shared across web applications because it is
loaded by the system
Rob,
Thanks for that info. It looks correct to me. You have defined the
correct factory for Tomcat's own JDBC pool are you are correctly casting
to an instance of a DataSource from that pool.
That caused me to go back and take a closer look at your original report.
It appears from the class
28 matches
Mail list logo
