Re: Unable to set up ssl

2013-08-05 Thread Oleg Andreyev
There are no handmade changes in config.xml. It's the same as in 
geronimo-tomcat7-javaee6-web-3.0.1-bin.tar.gz


On 08/03/2013 10:04 PM, thiyagu_r wrote:

Please share the config.xml

Sent from my iPhone

On Aug 3, 2013, at 10:23 AM, Oleg Andreyev [via Apache Geronimo]
[hidden email] /user/SendEmail.jtp?type=nodenode=3987095i=0 wrote:


Hi,

Last days I tried to set up SSL on Geronimo 3.0.1 and finally had to
admit defeat.

My steps:

- Downloaded 3.0.1 (Linux x64, Web profile, run with Oracle JDK 1.6.0_14)
- Changed ports to 80/443 in config-substitution.properties
- Log in to Web console
- Created new keystore, enabled it, generated key, CSR, imported answer
from CA

No errors so far. The key looks like:

Version: 3
Subject: CN=xxx.y.com http://xxx.y.com, OU=Domain
Control Validated
Issuer: SERIALNUMBER=10688435, CN=Starfield Secure Certification
Authority, OU=http://certificates.starfieldtech.com/repository,
O=Starfield Technologies, Inc., L=Scottsdale, ST=Arizona, C=US
Serial Number: 2292395462585499
Valid From: Fri Aug 02 20:15:19 EDT 2013
Valid To: Wed Jul 30 16:46:03 EDT 2014
Signature Alg: SHA1withRSA
Public Key Alg: RSA
critical ext: 2.5.29.15
critical ext: 2.5.29.19
non-critical ext: 2.5.29.14
non-critical ext: 1.3.6.1.5.5.7.1.1
non-critical ext: 2.5.29.31
non-critical ext: 2.5.29.32
non-critical ext: 2.5.29.37
non-critical ext: 2.5.29.35
non-critical ext: 2.5.29.17

Also I have changed Web servers/TomcatWebSSLConnector to set correct
keystoreFile and keystore password and stop/start it.

So, I tried connect with https and after some time The connection was
reset. And I see error in geronimo log:
2013-08-02 20:19:22,861 ERROR [JIoEndpoint]
java.lang.NullPointerException
 at
org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:525)

 at
org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:230)
 at java.lang.Thread.run(Thread.java:619)

I describe this attempts because it is most appropriate to documentation
but I tried different JDK, geronimo 3.0.0, keystore created by keytool
and so on.

Any clue?



If you reply to this email, your message will be added to the
discussion below:
http://apache-geronimo.328035.n3.nabble.com/Unable-to-set-up-ssl-tp3987094.html

To start a new topic under Users, email [hidden email]
/user/SendEmail.jtp?type=nodenode=3987095i=1
To unsubscribe from Users, click here.
NAML
http://apache-geronimo.328035.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml




View this message in context: Re: Unable to set up ssl
http://apache-geronimo.328035.n3.nabble.com/Unable-to-set-up-ssl-tp3987094p3987095.html
Sent from the Users mailing list archive
http://apache-geronimo.328035.n3.nabble.com/Users-f328036.html at
Nabble.com.




Re: Unable to set up ssl

2013-08-05 Thread Ivan
Hi,

Per the stacktrace, it looks like the executor was not configured correctly.

In Geronimo 3.0.*, the var/catalina/server.xml is used as the tomcat
container configuration file, could you show us that file ? I guess that
the ssl connector was updated incorrectly in that file. You may also
compare that file with the original one to check what was changed.

Thanks.


2013/8/5 Oleg Andreyev oandre...@opensourcestrategies.com

 There are no handmade changes in config.xml. It's the same as in
 geronimo-tomcat7-javaee6-web-**3.0.1-bin.tar.gz


 On 08/03/2013 10:04 PM, thiyagu_r wrote:

 Please share the config.xml

 Sent from my iPhone

 On Aug 3, 2013, at 10:23 AM, Oleg Andreyev [via Apache Geronimo]
 [hidden email] /user/SendEmail.jtp?type=**nodenode=3987095i=0
 wrote:

  Hi,

 Last days I tried to set up SSL on Geronimo 3.0.1 and finally had to
 admit defeat.

 My steps:

 - Downloaded 3.0.1 (Linux x64, Web profile, run with Oracle JDK 1.6.0_14)
 - Changed ports to 80/443 in config-substitution.properties
 - Log in to Web console
 - Created new keystore, enabled it, generated key, CSR, imported answer
 from CA

 No errors so far. The key looks like:

 Version: 3
 Subject: CN=xxx.y.com http://xxx.y.com, OU=Domain

 Control Validated
 Issuer: SERIALNUMBER=10688435, CN=Starfield Secure Certification
 Authority, 
 OU=http://certificates.**starfieldtech.com/repositoryhttp://certificates.starfieldtech.com/repository
 ,
 O=Starfield Technologies, Inc., L=Scottsdale, ST=Arizona, C=US
 Serial Number: 2292395462585499
 Valid From: Fri Aug 02 20:15:19 EDT 2013
 Valid To: Wed Jul 30 16:46:03 EDT 2014
 Signature Alg: SHA1withRSA
 Public Key Alg: RSA
 critical ext: 2.5.29.15
 critical ext: 2.5.29.19
 non-critical ext: 2.5.29.14
 non-critical ext: 1.3.6.1.5.5.7.1.1
 non-critical ext: 2.5.29.31
 non-critical ext: 2.5.29.32
 non-critical ext: 2.5.29.37
 non-critical ext: 2.5.29.35
 non-critical ext: 2.5.29.17

 Also I have changed Web servers/TomcatWebSSLConnector to set correct
 keystoreFile and keystore password and stop/start it.

 So, I tried connect with https and after some time The connection was
 reset. And I see error in geronimo log:
 2013-08-02 20:19:22,861 ERROR [JIoEndpoint]
 java.lang.NullPointerException
  at
 org.apache.tomcat.util.net.**JIoEndpoint.processSocket(**
 JIoEndpoint.java:525)

  at
 org.apache.tomcat.util.net.**JIoEndpoint$Acceptor.run(**
 JIoEndpoint.java:230)
  at java.lang.Thread.run(Thread.**java:619)

 I describe this attempts because it is most appropriate to documentation
 but I tried different JDK, geronimo 3.0.0, keystore created by keytool
 and so on.

 Any clue?


 --**--**
 

 If you reply to this email, your message will be added to the
 discussion below:
 http://apache-geronimo.328035.**n3.nabble.com/Unable-to-set-**
 up-ssl-tp3987094.htmlhttp://apache-geronimo.328035.n3.nabble.com/Unable-to-set-up-ssl-tp3987094.html

 To start a new topic under Users, email [hidden email]
 /user/SendEmail.jtp?type=**nodenode=3987095i=1

 To unsubscribe from Users, click here.
 NAML
 http://apache-geronimo.**328035.n3.nabble.com/template/**
 NamlServlet.jtp?macro=macro_**viewerid=instant_html%**
 21nabble%3Aemail.namlbase=**nabble.naml.namespaces.**
 BasicNamespace-nabble.view.**web.template.NabbleNamespace-**
 nabble.view.web.template.**NodeNamespacebreadcrumbs=**
 notify_subscribers%21nabble%**3Aemail.naml-instant_emails%**
 21nabble%3Aemail.naml-send_**instant_email%21nabble%**3Aemail.namlhttp://apache-geronimo.328035.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
 



 --**--**
 

 View this message in context: Re: Unable to set up ssl
 http://apache-geronimo.**328035.n3.nabble.com/Unable-**to-set-up-ssl-**
 tp3987094p3987095.htmlhttp://apache-geronimo.328035.n3.nabble.com/Unable-to-set-up-ssl-tp3987094p3987095.html
 

 Sent from the Users mailing list archive
 http://apache-geronimo.**328035.n3.nabble.com/Users-**f328036.htmlhttp://apache-geronimo.328035.n3.nabble.com/Users-f328036.html
 at
 Nabble.com.





-- 
Ivan


Re: Classes generated on runtime (javassist) classloader issue

2013-08-05 Thread Ivan
It is possible that javassist from the server side was used. Could you try
to use hidden-class in your geronimo-web.xml to prevent using javassist
from Geronimo server.

*hidden*-*classes*filterjavassist/filter/*hidden*-*classes*

Hope it helps.


2013/8/5 dkateros dkate...@gmail.com

 Hello,

 I stumbled on this issue while testing an application with the geronimo
 3.01
 release (currently runs on geronimo 2.2 for development and Websphere 8.5
 for production).

 This application creates concrete classes on runtime based on abstract
 classes that exist on compile time.

 Imagine the following scenario (extremely naive, but demonstrates the
 issue).

 public abstract class Foo { //exists on compile time
SetString strings; //package visible
 }

 public class FooConcreteEnhanced extends Foo { //generated on runtime
 public FooConcreteEnhanced() { strings = new HashSetString(); }
 }

 When the app attempts to instantiate FooConcreteEnhanced, the following
 error is thrown:

 java.lang.IllegalAccessError: tried to access field pkg.Foo.strings from
 class pkg.FooConcreteEnhanced

 This might be caused if the runtime package of the classes is different,
 which happens if the two classes are loaded by two different classloaders.
 Changing the access modifier of strings to protected circumvents the
 problem, but is not desirable, since a lot of the app's unit tests rely on
 package visibility of fields.

 Is there any configuration available that I might use to force the
 generated
 classes to be loaded by the same class loader of the apps build time
 classes?

 PS: Note that the javassist.ClassPool instance that hosts the generated
 classes is scoped on the jars of my application (as opposed to being scoped
 on the default javassist ClassPool that might be loaded by a parent
 classloader in case the application server loads the javassist library for
 other reasons - like WebSphere 8.5 does).



 --
 View this message in context:
 http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097.html
 Sent from the Users mailing list archive at Nabble.com.




-- 
Ivan


Re: Classes generated on runtime (javassist) classloader issue

2013-08-05 Thread dkateros
Thank you for your reply Ivan.

When we migrated the app to WAS 8.5, we faced a problem that was caused by
this exact situation you describe: javassist was already loaded by the
parent classloader. We did not change that, instead we scoped the javassist
classpool singleton we use to create the runtime classes to our code (we
were using the default classpool before). Long story short the app runs now
on WAS 8.5 with the default parent first classloading policy.

However, your idea is quite good. I will try to hide the javassist.*
namespace from our app's classloader using the geronimo-web.xml
configuration you suggest and I will post my findings here.

It will take a few days (currently on vacation).

Regards // Dimitris



--
View this message in context: 
http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097p3987102.html
Sent from the Users mailing list archive at Nabble.com.