Re: Are Symbol files of Tomcat DLLs publicly available?

2017-12-04 Thread Suvendu Sekhar Mondal 
On Tue, Dec 5, 2017 at 1:28 AM, Mark Thomas  wrote:
> On 04/12/17 11:12, Suvendu Sekhar Mondal wrote:
>> Hello Everyone,
>>
>> I am investigating a Tomcat crash. Actually, JRE crashed due to
>> "access violation" error. It created a Windows memory dump file. I am
>> trying to analyze it win WinDbg. Problem I am facing is that lots of
>> Symbols (of tomcat7, jvm, java, tcnative-1, nio DLLs) are not
>> available to me. As a result WinDbg is giving me a Stack filled up
>> with DLL names and HEX values.
>>
>> In order to get some of them - mostly JRE related, I have already
>> reached out to Java forum:
>> https://community.oracle.com/thread/4102753. No response so far :(.
>>
>> Can someone please tell me how can I get Symbol files of Tomcat DLLs
>> like tomcat7 and tcnative-1? Are they publicly available?
>
> Exactly which versions do you need?

Sorry, Mark. I should have provide that information upfront. I am using:

Tomcat 7.0.55
JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
OS version: Windows Server 2012 R2

> I produced the binaries for the most recent of those and I probably
> still have the necessary files sat on a VM if they are recent(ish).
>
> Mark

Yeah, I know it's not that recent. Still, if you have it please let me know.

We tried to create PDB files for Java specific DLLs from OpenJDK, but
as you can see below, WinDbg rejected it.

* Symbol Loading Error Summary **
Module nameError
tomcat7No header information available :
srv*c:\mss*http://msdl.microsoft.com/download/symbols
jvmSignature does not match :
srv*c:\mss*http://msdl.microsoft.com/download/symbols
tcnative-1 No header information available :
srv*c:\mss*http://msdl.microsoft.com/download/symbols


Thanks!
Suvendu

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

RE: Trying to understand How Tomcat uses Keystore for SSL

2017-12-04 Thread Nicolas Therrien 
Agreed. I was thinking in terms of the TLS exchange during which the client 
uses the public key to send a symmetric key to the server.

I should have read the text further and more literally. Sorry about the 
confusion.

Nicolas Therrien ing.
Senior Software Engineer

Airbus DS Communications
home of VESTA®
200 Boul. de la Technologie, Suite 300
Gatineau, QC J8Z 3H6
Canada
819.931.2139  (DIRECT)
www.Airbus-DSComm.com




-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, December 4, 2017 2:58 PM
To: users@tomcat.apache.org
Subject: Re: Trying to understand How Tomcat uses Keystore for SSL

On 04/12/17 19:20, Nicolas Therrien wrote:
> " Asymmetric encryption uses a public and a 
>> private encryption key.  The public key, which as its name states, is 
>> public, i.e. it is available to all. The private key is and must be 
>> closely guarded.  A message encrypted with the private key can be 
>> decrypted by the public key and vis-a-versa."
> 
> This is not true.

Yes, it is true.

> 
> The principle of asymmetric encryption is based on the fact that this is a 
> one-way communication channel.  Only the public key can encrypt data, and 
> only the private key can decrypt data.

The above statement is incorrect.

> This is not reversible. The private key cannot be used to encrypt and the 
> public key cannot be used to decrypt.

So is the statement above.

> This is why it is called asymmetric, as opposed to symmetric where both ends 
> can both encrypt and decrypt.

Again, no.

It is called asymmetric because whichever key you use to encrypt, you
must use the other key to decrypt.

In symmetric encryption there is a single key that encrypts and decrypts.

As an aside, encrypting with the private key and decrypting with the
public key is a key element of how digital signatures work.

I recommend viewing the "Introduction to Tomcat and TLS" presentation
from this page:
https://urldefense.proofpoint.com/v2/url?u=http-3A__tomcat.apache.org_presentations.html=DwICaQ=V9FsLrJ7wYRfgsJ_KHoq2BENyO08hg3hD97KYyc_QQg=ZZk8MXVrcZaLkCc_2C7UFhVW7Nb2LjIIa0VSNP2uvtnzxufjwl_gt-oLYrhgql55=-88nWY3ukSpK6pjmbNDfKWWcmr0DUrFdu3QQktOfMLI=rGi1lxExpzMxuwq6pykrS5RJosFgcea37gIQJyaFiCg=

It is a little simplistic, but it covers the basics.

Mark

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

Re: Are Symbol files of Tomcat DLLs publicly available?

2017-12-04 Thread Mark Thomas 
On 04/12/17 11:12, Suvendu Sekhar Mondal wrote:
> Hello Everyone,
> 
> I am investigating a Tomcat crash. Actually, JRE crashed due to
> "access violation" error. It created a Windows memory dump file. I am
> trying to analyze it win WinDbg. Problem I am facing is that lots of
> Symbols (of tomcat7, jvm, java, tcnative-1, nio DLLs) are not
> available to me. As a result WinDbg is giving me a Stack filled up
> with DLL names and HEX values.
> 
> In order to get some of them - mostly JRE related, I have already
> reached out to Java forum:
> https://community.oracle.com/thread/4102753. No response so far :(.
> 
> Can someone please tell me how can I get Symbol files of Tomcat DLLs
> like tomcat7 and tcnative-1? Are they publicly available?

Exactly which versions do you need?

I produced the binaries for the most recent of those and I probably
still have the necessary files sat on a VM if they are recent(ish).

Mark

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

Re: Trying to understand How Tomcat uses Keystore for SSL

2017-12-04 Thread Mark Thomas 
On 04/12/17 19:20, Nicolas Therrien wrote:
> " Asymmetric encryption uses a public and a 
>> private encryption key.  The public key, which as its name states, is 
>> public, i.e. it is available to all. The private key is and must be 
>> closely guarded.  A message encrypted with the private key can be 
>> decrypted by the public key and vis-a-versa."
> 
> This is not true.

Yes, it is true.

> 
> The principle of asymmetric encryption is based on the fact that this is a 
> one-way communication channel.  Only the public key can encrypt data, and 
> only the private key can decrypt data.

The above statement is incorrect.

> This is not reversible. The private key cannot be used to encrypt and the 
> public key cannot be used to decrypt.

So is the statement above.

> This is why it is called asymmetric, as opposed to symmetric where both ends 
> can both encrypt and decrypt.

Again, no.

It is called asymmetric because whichever key you use to encrypt, you
must use the other key to decrypt.

In symmetric encryption there is a single key that encrypts and decrypts.

As an aside, encrypting with the private key and decrypting with the
public key is a key element of how digital signatures work.

I recommend viewing the "Introduction to Tomcat and TLS" presentation
from this page:
http://tomcat.apache.org/presentations.html

It is a little simplistic, but it covers the basics.

Mark

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

Re: Trying to understand How Tomcat uses Keystore for SSL

2017-12-04 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nicolas,

On 12/4/17 2:20 PM, Nicolas Therrien wrote:
> " Asymmetric encryption uses a public and a
>> private encryption key.  The public key, which as its name
>> states, is public, i.e. it is available to all. The private key
>> is and must be closely guarded.  A message encrypted with the
>> private key can be decrypted by the public key and vis-a-versa."
> 
> This is not true.
> 
> The principle of asymmetric encryption is based on the fact that 
> this is a one-way communication channel. Only the public key can 
> encrypt data, and only the private key can decrypt data.> This is
> not reversible. The private key cannot be used to encrypt and the
> public key cannot be used to decrypt.
While you are right that "this is not reversible" you are incorrect
that the private key cannot be used to encrypt. In fact, the private
key MUST be used to encrypt. This is the foundation of the TLS handshake
.

> This is why it is called asymmetric, as opposed to symmetric where 
> both ends can both encrypt and decrypt.
No, it's called asymmetric because there are two keys involved instead
of a single key.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlolojsACgkQHPApP6U8
pFiG4Q/9Hd+pIZgD8OOGVwhuBxPJIttzdSrypDwNVbecz9K4PjBR0ECSc5eiwteb
TLn4lbI5Rgrf0DkCnUa8mdc4Ej3ZMpUBpWCJztk9dMHgRBNQgZ0xzq3M2eTmmpI2
Pk7dDpp0H5m2dDASbCYOYe2q/i8FP2VxJuqa0cg0gVLkonEusU2WgfkoAB6uNDCQ
imiEjK5KoqNlZCK5AZJzmEE0ekD/R1d+JmOMjteDwtk9yF5JFJIFf9mYrRbsUz1U
ViEpWlQ9U0NbJ4wk7zboSjkzgUJdigNCzpHkqGa7aAwJM+yNEIbYw4Ipe1csdI9K
R7rzvoqx9bgb1U3LS5SO81nzlhCM7/8jVWYp4uIT6FqotAJcufUZ8tGgPzRV7WAe
ofrdBkn8UOY0A7P6yQ5KVkx2ADbenVQBCAzwrjhsBKdzG63bloyrwtOcyQ3evXR0
59zpAnNVz4fwebXAeO0MatKjfJbpWYEPUFBXW2L/++Zw1tUDcxn2exdvwzrN1QLz
Q2oFgX3vrc7zl5USTYoE/rtfomG94vwMjYPsILBE/E95gLazfTFszZ6PmOGonFEP
SZ0IBsqdYpC/mvJ0yNK3yukS2XYFIR03+dujSGkOVeHZqNe7EDhZWztJxCpX+yaE
H9DcNR2nU79pT8LjKwkvq8r2JNOVPtLEa3qBGWLqmq47u6Wx5OQ=
=HcjO
-END PGP SIGNATURE-

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

RE: Trying to understand How Tomcat uses Keystore for SSL

2017-12-04 Thread Nicolas Therrien 
" Asymmetric encryption uses a public and a 
> private encryption key.  The public key, which as its name states, is 
> public, i.e. it is available to all. The private key is and must be 
> closely guarded.  A message encrypted with the private key can be 
> decrypted by the public key and vis-a-versa."

This is not true.

The principle of asymmetric encryption is based on the fact that this is a 
one-way communication channel.  Only the public key can encrypt data, and only 
the private key can decrypt data.

This is not reversible. The private key cannot be used to encrypt and the 
public key cannot be used to decrypt.

This is why it is called asymmetric, as opposed to symmetric where both ends 
can both encrypt and decrypt.

Of course this text would require some rewrite, but in my opinion I think that, 
once fixed, the text would be useful and welcome.I give a lot of training 
about encryption and SSL within my company and I think there is not enough 
"end-to-end" articles on the subject.   SSL implies a lot of complex concepts 
all put together so, yes, it is hard and it deserves additional vulgarization.

You can send me updates of your text if you need a reviewer.

Nicolas Therrien ing.
Senior Software Engineer

Airbus DS Communications
home of VESTA®
200 Boul. de la Technologie, Suite 300
Gatineau, QC J8Z 3H6
Canada
819.931.2139  (DIRECT)
www.Airbus-DSComm.com




-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Monday, December 4, 2017 2:06 PM
To: users@tomcat.apache.org
Subject: Re: Trying to understand How Tomcat uses Keystore for SSL

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Don,

I haven't really read this, yet, but my first impression is that it provides a 
lot of background that we have tried NOT to repeat on the Tomcat site. The 
world doesn't need "another TLS background page."

As a beginning user, what would you think about having to be sent to other 
"background resources" before reading the Tomcat documentation?
I'd prefer not to "re-write the wheel", if you know what I mean.

- -chris

On 12/3/17 10:07 PM, Don Flinn wrote:
> Thanks Chuck
> 
> In plain text
> 
> Please comment on the following write-up.
> 
> Setting Up SSL for TomCat 1) Overview of Security for Tomcat
> 
> Security is hard, which by extension means setting up SSL is hard.
> One of the things that make this difficult is that there are multiple 
> layers of specifications.  In this explanation we are only go as deep 
> into the technical description as is necessary for you to understand 
> what is going on.
> 
> At the bottom layer of security is cryptography, which is based on 
> encryption.  We won’t go into encryption except to say that all 
> encryption protocols are breakable, except the One Time Pad, which is 
> impracticable. The principal of computer security is to make it very 
> difficult to break the encryption.  Using a modern desktop computer it 
> would take a little over 6.4 quadrillion years to crack the encryption 
> of a 2048 bit RSA certificate.  Note: practical quantum computers 
> large enough to negate this time estimate don't exist, yet
> 
> There are two encryption schemes that are of interest, asymmetric and 
> symmetric encryption.  Asymmetric encryption uses a public and a 
> private encryption key.  The public key, which as its name states, is 
> public, i.e. it is available to all. The private key is and must be 
> closely guarded.  A message encrypted with the private key can be 
> decrypted by the public key and vis-a-versa.
> 
> SSL or Secure Sockets Layer, is the high level security layer that we 
> are attempting to implement for for our implementation of Tomcat.  SSL 
> uses both asymmetric and symmetric encryption, but at the level we are 
> interested in we only deal with the former, while Tomcat and the other 
> parties like the browser deal with both.
> 
> In the scenario that we are addressing there are three parties 
> involved * your installation of Tomcat * the browser with whom you 
> wish to communicate and * the Certificate Authority or CA, e.g.
> letsencrypt, Comodo, etc.
> 
> In cryptography, a certificate authority or certification authority
> (CA) is an entity that issues digital certificates. A digital 
> certificate certifies the ownership of a public key by the named 
> subject of the certificate. This allows others (relying parties) to 
> rely upon signatures or on assertions made about the private key that 
> corresponds to the certified public key. A CA acts as a trusted third 
> party—trusted both by the subject (owner) of the certificate and by 
> the party relying upon the certificate. The format of these 
> certificates is specified by the X.509 standard.
> 
> In order to set up SSL, you want to get a private/public key pair and 
> what is called a Security Certificate or more properly, an X509 
> certificate. The Security Certificate contains information about who 
> you are and is attested to by

Re: Trying to understand How Tomcat uses Keystore for SSL

2017-12-04 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Don,

I haven't really read this, yet, but my first impression is that it
provides a lot of background that we have tried NOT to repeat on the
Tomcat site. The world doesn't need "another TLS background page."

As a beginning user, what would you think about having to be sent to
other "background resources" before reading the Tomcat documentation?
I'd prefer not to "re-write the wheel", if you know what I mean.

- -chris

On 12/3/17 10:07 PM, Don Flinn wrote:
> Thanks Chuck
> 
> In plain text
> 
> Please comment on the following write-up.
> 
> Setting Up SSL for TomCat 1) Overview of Security for Tomcat
> 
> Security is hard, which by extension means setting up SSL is hard.
> One of the things that make this difficult is that there are
> multiple layers of specifications.  In this explanation we are only
> go as deep into the technical description as is necessary for you
> to understand what is going on.
> 
> At the bottom layer of security is cryptography, which is based on 
> encryption.  We won’t go into encryption except to say that all
> encryption protocols are breakable, except the One Time Pad, which
> is impracticable. The principal of computer security is to make it
> very difficult to break the encryption.  Using a modern desktop
> computer it would take a little over 6.4 quadrillion years to crack
> the encryption of a 2048 bit RSA certificate.  Note: practical
> quantum computers large enough to negate this time estimate don't
> exist, yet
> 
> There are two encryption schemes that are of interest, asymmetric
> and symmetric encryption.  Asymmetric encryption uses a public and
> a private encryption key.  The public key, which as its name
> states, is public, i.e. it is available to all. The private key is
> and must be closely guarded.  A message encrypted with the private
> key can be decrypted by the public key and vis-a-versa.
> 
> SSL or Secure Sockets Layer, is the high level security layer that
> we are attempting to implement for for our implementation of
> Tomcat.  SSL uses both asymmetric and symmetric encryption, but at
> the level we are interested in we only deal with the former, while
> Tomcat and the other parties like the browser deal with both.
> 
> In the scenario that we are addressing there are three parties
> involved * your installation of Tomcat * the browser with whom you
> wish to communicate and * the Certificate Authority or CA, e.g.
> letsencrypt, Comodo, etc.
> 
> In cryptography, a certificate authority or certification authority
> (CA) is an entity that issues digital certificates. A digital
> certificate certifies the ownership of a public key by the named
> subject of the certificate. This allows others (relying parties) to
> rely upon signatures or on assertions made about the private key
> that corresponds to the certified public key. A CA acts as a
> trusted third party—trusted both by the subject (owner) of the 
> certificate and by the party relying upon the certificate. The
> format of these certificates is specified by the X.509 standard.
> 
> In order to set up SSL, you want to get a private/public key pair
> and what is called a Security Certificate or more properly, an X509
> certificate. The Security Certificate contains information about
> who you are and is attested to by the CA, whom the browser trusts.
> In some cases, like the CA letsencrypt, the trust of the CA by all
> browser is not yet there, so the certificate contains an
> intermediate CA whom the browsers trust and who attests for the CA
> who trusts your domain.  Each of the CA's, the root CA, who trusts
> us and intermediate who trusts the root CA, digitally sign (another
> specification) the certificate with their private keys, so that the
> browsers and other interested parties can verify the subject of
> the certificate. This is accomplished by using the CA's public key
> to assure that this certificate was signed by the root or
> intermediate CA with their private key.
> 
> The certificates and keys have specified binary structures so that
> they can be machine read.  This structure is defined by using an
> abstract notation called ASN.1, Abstract Syntax Notation One, which
> defines data types in a binary format.  A subset of ASN.1, BER
> defines how to encode each value type.  BER has more than one way
> to encode a data type, so there is DER, which gives a unique
> encoding to each of the BER data types.
> 
> A DER encoded certificate is an encoded binary form of the
> certificate. Binary data can not be sent over the internet, so for
> transportation they are base64 encoded, which transforms the binary
> bits into ASCII, which can then be sent over the internet.  Note
> base64 is not human readable but is NOT encryption.  Encoding and
> decoding can be done using a well known algorithm.  In essence PEM
> files are just base64 encoded versions of the DER encoded data.
> 
> Before we leave this section there is another distinction.

Re: Are Symbol files of Tomcat DLLs publicly available?

2017-12-04 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Suvendu,

On 12/4/17 6:12 AM, Suvendu Sekhar Mondal wrote:
> Hello Everyone,
> 
> I am investigating a Tomcat crash. Actually, JRE crashed due to 
> "access violation" error. It created a Windows memory dump file. I
> am trying to analyze it win WinDbg. Problem I am facing is that
> lots of Symbols (of tomcat7, jvm, java, tcnative-1, nio DLLs) are
> not available to me. As a result WinDbg is giving me a Stack filled
> up with DLL names and HEX values.
> 
> In order to get some of them - mostly JRE related, I have already 
> reached out to Java forum: 
> https://community.oracle.com/thread/4102753. No response so far
> :(.
> 
> Can someone please tell me how can I get Symbol files of Tomcat
> DLLs like tomcat7 and tcnative-1? Are they publicly available?

I thought tcnative was built without stripping symbols. Is it not? Hmm.

If you have a debugger, are you able to build tcnative from source?
That may be the best bet for you on short notice, since you can build
the DLL including whatever you will need for your local bugging.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlolkckACgkQHPApP6U8
pFhtYQ//VyMoJUIgksw7zluQqrofqL8YzpZ5N3k490OHk2A/MjV16maFBkq2Zgyc
MV4LWzPgU3AhtMsA/QXCaKPF5dynWorCQHr++6YB8uyx5EWo9loU1PEStUnyZYAz
F9qodU/ecUAx/yjt2B7kSaYquUP6j+dSJCinvMBOBBRHLIPHhlXyGhVw9EAUrMRA
iaHyn+1ioIF9LrliURSdL36vNUBHs2fORZhJvvB/I7dlXADrCEeSvU0YE9aRwjyT
FEVy7MCih83K5/+GwBLLglwrr85vZulDFJkJRH82hb0m0azG1d4iF2hmIk/bExu0
ksEzS5x9ptyFib6EZAIt/GIRWUKekp7QRZ/CHi5qjvBJo/cWqIZiSJPTYRtisDRm
gHXWbRB2JF6P/rNPDqvJJGlJ/9zor0ieCRptoX7gFW4EIcOEcPsTxPfpJg4YHj87
hT3jSgZP+QoDZhXwtwcCaNP5U7Ohsg0xceHNQUXSrtIDwEyWiWCyDCDoOZi+T7Ba
AJxLb8wDp1agVxM8Kkalrx1zb/061QK02lZP3U9MNLGLVkPVt4N/7lVB3Y5ajH45
xdPJCmWVMHEC8L/CfBEIMHH4mw6uM50L1S5yIDs/P5G4qQ/jV89/40xxopSfbCSx
6hQBBPRGjiETgM2ETOicgSPXW/kQtF8sgDnYmdfkYiuHn0jEiVM=
=gm19
-END PGP SIGNATURE-

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

Re: Parallel deployment without container managed sessions

2017-12-04 Thread Mark Thomas 
On 4 December 2017 10:25:35 GMT+00:00, malbinola  wrote:
>Hi All,
>we have been using the fantastic parallel deployment feature (PD) for
>years
>but now, after upgrading to Apache Shiro's native session management,
>it
>don't work anymore.
>
>Let's suppose that we have a deployed app named app##01.war on which we
>have
>several logged users. If we realease a new version of our webapp
>(app##02.war), after the webapp is started up by tomcat, users on the
>instance ##01 start receiving 401 Unauthorized from the server and they
>are
>automatically redirected to login page. Every request after the new
>release
>is treated as new session and redirected to the brand new release. 
>
>I read  here
>
> 
>that Tomcat makes some decision depending on sessions infos.
>It seems that the transition to Shiro's native session management
>completely
>blinds Tomcat, preventing it from understanding real session
>distribution
>over webapp's instances.
>This can have sense, sessions are now managed by shiro and not by
>Tomcat.
>So... Is there any module to extend in order to integrate into Tomcat's
>PD
>decision process and provide a such sort of bridge over Shiro's session
>manager?

Not that I am aware of.

>Any thougths?

If you can get Shiro to append the webapp version to the end of the session ID 
using the same format as Tomcat then it should start working as expected.

Mark


>
>Thank you,
>Matteo
>
>
>
>--
>Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


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

Are Symbol files of Tomcat DLLs publicly available?

2017-12-04 Thread Suvendu Sekhar Mondal 
Hello Everyone,

I am investigating a Tomcat crash. Actually, JRE crashed due to
"access violation" error. It created a Windows memory dump file. I am
trying to analyze it win WinDbg. Problem I am facing is that lots of
Symbols (of tomcat7, jvm, java, tcnative-1, nio DLLs) are not
available to me. As a result WinDbg is giving me a Stack filled up
with DLL names and HEX values.

In order to get some of them - mostly JRE related, I have already
reached out to Java forum:
https://community.oracle.com/thread/4102753. No response so far :(.

Can someone please tell me how can I get Symbol files of Tomcat DLLs
like tomcat7 and tcnative-1? Are they publicly available?

Thanks!
Suvendu

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

Parallel deployment without container managed sessions

2017-12-04 Thread malbinola 
Hi All,
we have been using the fantastic parallel deployment feature (PD) for years
but now, after upgrading to Apache Shiro's native session management, it
don't work anymore.

Let's suppose that we have a deployed app named app##01.war on which we have
several logged users. If we realease a new version of our webapp
(app##02.war), after the webapp is started up by tomcat, users on the
instance ##01 start receiving 401 Unauthorized from the server and they are
automatically redirected to login page. Every request after the new release
is treated as new session and redirected to the brand new release. 

I read  here

  
that Tomcat makes some decision depending on sessions infos.
It seems that the transition to Shiro's native session management completely
blinds Tomcat, preventing it from understanding real session distribution
over webapp's instances.
This can have sense, sessions are now managed by shiro and not by Tomcat.
So... Is there any module to extend in order to integrate into Tomcat's PD
decision process and provide a such sort of bridge over Shiro's session
manager?
Any thougths?

Thank you,
Matteo



--
Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html

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