Re: [Resin-interest] Reg. Resin Security Vulnerability

[BUSCH Steffen]

Hi,

can you post here:
https://groups.google.com/forum/#!forum/caucho-resin

I could offer you help in a couple of hours or tomorrow.
In the meantime you can already get these Java Cryptography Extension (JCE) 
Unlimited Strength Jurisdiction Policy Files 7.
http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html

Kind regards,
Steffen
Von: resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] Im Auftrag von Abhishek
Gesendet: Donnerstag, 11. Januar 2018 12:47
An: resin-interest@caucho.com
Betreff: [Resin-interest] Reg. Resin Security Vulnerability

Hello!

I am using resin-pro-4.0.41 with Java 7 and using below configuration for https 
configuration in "resin.properties"

# JSSE certificate configuration
# Keys are typically stored in the resin configuration directory.
jsse_keystore_type : jks
jsse_keystore_file : keys/server.keystore
jsse_keystore_password : adrs123

Following vulnerabilities has been identified in my setup:


1.   Diffie-Hellman group smaller than 2048 bits

2.   Disable Supports RC4 Cipher Algorithms, 3DES Cipher Suite, The Use of 
Static Key Ciphers, Using Commonly Used Prime Numbers

3.   Disable support of SSLv3, TLS 1.0 & TLS 1.1

4.   TLS/SSL Server is enabling the POODLE attack --> Has to be disabled

5.   TLS/SSL Server is enabling the BEAST attack --> Has to be disabled

6.   TLS/SSL Birthday attacks on 64-bit block ciphers (SWEET32) --> Has to 
be disabled

Please share if there is any configuration to handle these vulnerabilities

Regards,
Abhishek | HP: +91-8130370104 |
Email: abhisheksi...@nmsworks.co.in
NMSWorks Software PVT LTD | #C3, IITM Research Park, Taramani, Chennai, India - 
600113 |


[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]

Virus-free. 
www.avast.com


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin SSL_Protocol Configuration for TLS1.2

[BUSCH Steffen]

Hi,

These properties will be used in the cluster-default.xml and if you want to use 
only TLS 1.2 you can add the yellow marked addition:

  

  
${jsse_keystore_type?:'jks'}
${jsse_keystore_file}

  ${jsse_keystore_password}

TLSv1.2
  


Regards,
Steffen


Von: resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] Im Auftrag von Abhishek
Gesendet: Dienstag, 7. November 2017 07:44
An: resin-interest@caucho.com
Betreff: [Resin-interest] Resin SSL_Protocol Configuration for TLS1.2

Hello!

I am using resin-pro-4.0.41 and using below configuration for https 
configuration in "resin.properties"

# JSSE certificate configuration
# Keys are typically stored in the resin configuration directory.
jsse_keystore_type : jks
jsse_keystore_file : keys/server.keystore
jsse_keystore_password : adrs123

I am not able find any configuration related SSL Protocol to be used.

Please share if there is any configuration in which we can specify the protocol 
as TLS 1.2

Regards,
Abhishek | HP: +91-8130370104 |
Email: abhisheksi...@nmsworks.co.in
NMSWorks Software PVT LTD | #C3, IITM Research Park, Taramani, Chennai, India - 
600113 |


[Das Bild wurde vom Absender 
entfernt.]

Virus-free. 
www.avast.com


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] 'honor-cipher-order' is an unknown property of 'com.caucho.vfs.JsseSSLFactory'

[BUSCH Steffen]

In Resin 4.0.34 the new SSL configuration honor-cipher-order was introduced 
for OpenSSL.

With Java 8 this was also added to JSSE. See: 
https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html
Bottom of the page: Support cipher suites preference customization in JSSE


Would it be possible to add honor-cipher-order to 
com.caucho.vfs.JsseSSLFactory when Resin 4 is using a Java 8 JDK?

Kinrd regards,
Steffen


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] How to change SMTP config for health:PdfReport in Resin-Pro-4.0?

[BUSCH Steffen]

In health.xml I am able to specify a mail reference for example

  health:SendMail mail=${healthMailer}
toad...@yourdomain.com/to
health:OnStop/
  health:SendMail

where ${healthMailer} can be configured in resin.xml like this

  mail name=healthMailer
smtp-hostmail.yourdomain.com/smtp-host
smtp-port25/smtp-port
fromre...@yourdomain.com/from
  /mail


==But in health.xml there is also health:PdfReport configured to retrieve a 
PDF as attachment. But how do I refer to my configured the ${healthMailer} 
there? It seems that it is always trying to connect to localhost:25 in the 
logfiles?

  health:PdfReport
path${resin.root}/doc/admin/pdf-gen.php/path
reportRestart/report
period2h/period
mail-to${email}/mail-to
mail-from${email_from}/mail-from
health:OnRestart/
  /health:PdfReport


-- Steffen
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] How to change SMTP config for health:PdfReport in Resin-Pro-4.0?

[BUSCH Steffen]

Thanks Scott, I'm going to try the system-property, but I would prefer to just 
add a reference to the already configured javax.mail resource like this just to 
have a single place of SMTP configuration:

  health:PdfReport mail=${healthMailer}

-- Steffen


On 10/17/14, 6:59 AM, BUSCH Steffen wrote:
In health.xml I am able to specify a mail reference for example

  health:SendMail mail=${healthMailer}
toad...@yourdomain.commailto:ad...@yourdomain.com/to
health:OnStop/
  health:SendMail

where ${healthMailer} can be configured in resin.xml like this

  mail name=healthMailer
smtp-hostmail.yourdomain.com/smtp-host
smtp-port25/smtp-port
fromre...@yourdomain.commailto:re...@yourdomain.com/from
  /mail

Setting the system property mail.smtp.host should work.

It looks like we can add the smtp-host/smtp-port into the PdfReport, but it's 
not configurable currently.

-- Scott




==But in health.xml there is also health:PdfReport configured to retrieve a 
PDF as attachment. But how do I refer to my configured the ${healthMailer} 
there? It seems that it is always trying to connect to localhost:25 in the 
logfiles?

  health:PdfReport
path${resin.root}/doc/admin/pdf-gen.php/path
reportRestart/report
period2h/period
mail-to${email}/mail-to
mail-from${email_from}/mail-from
health:OnRestart/
  /health:PdfReport


-- Steffen




___

resin-interest mailing list

resin-interest@caucho.commailto:resin-interest@caucho.com

http://maillist.caucho.com/mailman/listinfo/resin-interest

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Migrating URL Rewriting from 3.1 to 4.0.41

[BUSCH Steffen]

Hi everyone,

I'm struggling with migration from Resin Pro 3.1.10 to Resin Pro 4.0.41 in 
context of URL Rewriting at the *HOST* Level.

Problem in a nutshell:

-   In 3.1 it was possible to change HOST level rewrite rules that are 
configured in an external file without an automatic host restart - no 
interruptions for web-apps.

-   In 4.0.41 I am not able to achieve this with the 4.0 syntax. Changing a 
rewrite rule in the external file will enforce a restart of the host by Resin 
- all web-apps are restarted.


Let me explain it more detailed:
In 3.1 I've been configuring URL rewrite rules in an external file named 
misc-and-adhoc-host-level-rewrite.conf = see below extracts from my 
configuration.

Whenever I'm changing the external configuration file 
misc-and-adhoc-host-level-rewrite.conf, then Resin 3.1 applies the changes 
and just logs the resin:message information

ð  But the really good thing is that all defined web-apps in Host will remain 
up and running without any interruptions.


Resin 3.1:

-- -- -- -- resin-3.1.conf extract -- -- -- --
!-- Primary Host with all webapps --
host host-name=www.example.com

  !-- creates the webapps directory for .war expansion --
  web-app-deploy path=webapps/

  rewrite-dispatch
!-- Ad Hoc Rewrite Rules such as forbidden ip address or miscellaneous 
(external) --
import 
path='${resin.root}/conf/rewrite/misc-and-adhoc-host-level-rewrite.conf' 
name=MiscAdHocHostLevelImportRewrite/

!-- And some other Host-Level Rewrite Rules --
  /rewrite-dispatch

  !-- ROOT / Homepage  --
  web-app id=/ root-directory=/home/stbu/homepage/live
resin:import 
path=${resin.root}/conf/web-app-ext-conf/root_homepage.conf/
  /web-app

  !-- many, many other web-apps --
/host
-- -- -- -- resin-3.1.conf extract -- -- -- --



-- -- -- -- misc-and-adhoc-host-level-rewrite.conf extract -- -- -- --
rewrite-dispatch xmlns=http://caucho.com/ns/resin;
  xmlns:resin=http://caucho.com/ns/resin/core;

  resin:messageExternal rewrite configuration read from '${__FILE__}' 
.../resin:message

  moved-permanently regexp=^/en/faq(/?)$
target=/en/frequently-asked-questions.jsp/

/rewrite-dispatch
-- -- -- -- misc-and-adhoc-host-level-rewrite.conf extract -- -- -- --




I know that rewrite-dispatch and at least moved-permanently (don't know yet 
about the other tags) are working in my resin-pro-4.0.41 because of 
backward-compat but I can't figure out how to achieve this with the new 
Resin-4.0 Syntax.


I tried three things:

1.) Just change moved-permanently to resin:MovedPermanently, but this will 
not work:
test-rewrite-4.xml:7: 'resin:MovedPermanently' is an unknown property of 
'com.caucho.server.rewrite.MatchRule'.


2.) Additionally changed the XMLNS in the external file from
rewrite-dispatch xmlns=http://caucho.com/ns/resin;
  xmlns:resin=http://caucho.com/ns/resin/core;
into
rewrite-dispatch xmlns=http://caucho.com/ns/resin;
  xmlns:resin=urn:java:com.caucho.resin

Still the same Error:
test-rewrite-4.xml:7: 'resin:MovedPermanently' is an unknown property of 
'com.caucho.server.rewrite.MatchRule'.


3.) As I can't find a container-tag in 4.0 Syntax like rewrite-dispatch 
where resin:MovedPermanently can be configured, I had to change my external 
config file from rewrite-dispatch to the host tag.

-- -- -- -- resin-4.0.xml extract -- -- -- --
!-- Primary Host with all webapps --
host host-name=www.example.com
...
  !-- creates the webapps directory for .war expansion --
  web-app-deploy path=webapps/

  !-- Ad Hoc Rewrite Rules such as forbidden ip address or miscellaneous 
(external) --
  resin:import path='${resin.root}/conf/rewrite/test-rewrite-4.xml'/

  !-- ROOT / Homepage  --
  web-app id=/ root-directory=/home/stbu/homepage/live
resin:import 
path=${resin.root}/conf/web-app-ext-conf/root_homepage.conf/
  /web-app

  !-- many, many other web-apps --
/host
-- -- -- -- resin-3.1.conf extract -- -- -- --


and the external file now looks like this:

-- -- -- -- test-rewrite-4.xml -- -- -- --
host xmlns=http://caucho.com/ns/resin;
xmlns:resin=urn:java:com.caucho.resin

  resin:messageExternal rewrite configuration read from '${__FILE__}' 
.../resin:message

  resin:MovedPermanently regexp=^/en/faq(/?)$
target=/en/frequently-asked-questions.jsp/

/host
-- -- -- -- test-rewrite-4.xml -- -- -- --



But now when I change the external file (for example to change one of the 
targets), the HostController detects the change and the whole Host as well as 
all the web-apps are stopped, restarted and Users are interrupted.

[14-10-15 12:50:42.933] {resin-port-8444-26}  INFO 
com.caucho.server.host.HostController 
/home/stbu/websrv/websrv-resin-4/conf/rewrite/test-rewrite-4.xml length is 
modified (309 - 313)
[14-10-15 12:50:42.934] {resin-port-8444-26}  INFO 

Re: [Resin-interest] Resin-Pro-4.0.40: Support for password-digest old-encoding=true algorithm=MD5/ ?

[BUSCH Steffen]

A conversion program would be really awesome. Nothing fancy or time consuming 
like file creation. Something that just takes old input as argument and prints 
the converted value to stdout would be enough.
Thanks a lot in advance.
-- Steffen




On 9/26/14, 2:28 AM, BUSCH Steffen wrote:
Hi Scott,

finally I'm preparing to move from Resin 3.1 to 4.0 and wondering if it would 
be possible if you could add legacy-support for the old-encoding feature to the 
XmlAuthenticator. I've been using it in many quite old 3.1 files like this:

  authenticator type=com.caucho.server.security.XmlAuthenticator
init
  password-digest old-encoding=true algorithm=MD5 /
  password-digest-realmnone/password-digest-realm
  pathpasswords.xml/path
/init
  /authenticator


Any chance?

Would a conversion program work for you? The old-encoding was an old bug where 
base64 wasn't implemented properly. I'd prefer to keep that code out of the 
main authentication code.

-- Scott




Thanks,
Steffen





___

resin-interest mailing list

resin-interest@caucho.commailto:resin-interest@caucho.com

http://maillist.caucho.com/mailman/listinfo/resin-interest

___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] MD5 base64 hash algorithm differences betweenresin 2 and 4

[BUSCH Steffen]

Alan,
while migrating from 2.1 to 3.1 we've had a similar issue and it could be 
solved by explicitly using old-encoding.
Maybe you could find useful information in this thread:
http://maillist.caucho.com/pipermail/resin-interest/2009-February/003334.html

-- Steffen



-Ursprüngliche Nachricht-
Von: resin-interest-boun...@caucho.com 
[mailto:resin-interest-boun...@caucho.com] Im Auftrag von Alan Wright
Gesendet: Mittwoch, 21. September 2011 15:51
An: General Discussion for the Resin application server
Betreff: [Resin-interest] MD5 base64 hash algorithm differences betweenresin 2 
and 4

--Scott thanks - preparedStatement.unwrap() did the job for using 
OraclePreparedStatement but given the JavaDoc warning about the cost of calling 
unwrap() we are have to make a policy decision to only use 
OraclePreparedStatement where we really need a feature such as named parameters 
--



I am still migrating from 2 to 4.00.22

Old logins are not working and it seems there is an acknowledged difference 
between the implementations of the algorithm between resin 2  4.

eg: password=  TzW4CeGhlPNePIaacjYO6w==  dbPassword(created under resin 2)=  
TzW4CeGhlPNePIaacjYODr  digest=  MD5-base64

It seems the difference is only for the last few characters.

Presumably if the difference in the implementation is just to do with the 
length of the generated string and/or padding then this could be relied upon.

If I implement a scheme to replace the correct encodings as users login can I 
rely on an assumption that the first 15 characters will match for the same 
password under each implementation to provide a good enough match that triggers 
an update of the database with the full/correct encoding?


I have seen reference in forums to a digest option old-encoding, is this 
still available?

If it is how would I amend the following to get a copy of the old digest value?

 PasswordDigest digest = new PasswordDigest();
 digest.setAlgorithm(MD5); // Must match resin.conf
 digest.setFormat(base64); // Must match resin.conf
 aPasswordDigest = digest.getPasswordDigest(userNameValue, 
userPassword);

If I can't rely 100% on the similarity of the first chars of the encoded 
password to identify valid logins and update the encoding I would like to be 
able to check the dbpassword against both encodings and update the db with the 
correct encoding as necessary.

Asking users for passwords is not an option and wholesale resetting of 
passwords is not ideal from a customer service perspective.


Thanks in advance for any clarification.


Regards



Alan







-- 


Alan Wright
Athene Systems

tel 0845 230 9803


Athene Systems Limited
Registered Office:
Shieling House
Invincible Road
Farnborough
GU14 7QU

Registered in England and Wales No. 3156080



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] IllegalAccessError with Resin-Professional4.0.20 and EclipseLink 2.2

[BUSCH Steffen]

)
  at
com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1
442)
  at
com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1
423)
  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:247)
  at
org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClas
sForName(PrivilegedAccessHelper.java:93)
  at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.findClass(En
tityManagerSetupImpl.java:697)
  at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.findClassFor
Property(EntityManagerSetupImpl.java:703)
  at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.updateServer
Platform(EntityManagerSetupImpl.java:532)
  at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(En
tityManagerSetupImpl.java:985)
  at
org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityMan
agerFactory(PersistenceProvider.java:187)
  at
com.caucho.env.jpa.PersistenceUnitManager.createDelegate(PersistenceUnit
Manager.java:422)
  at
com.caucho.env.jpa.PersistenceUnitManager.start(PersistenceUnitManager.j
ava:383)
  at
com.caucho.env.jpa.PersistenceManager.startPersistenceUnits(PersistenceM
anager.java:367)
  at
com.caucho.env.jpa.PersistenceManager.environmentConfigureEnhancer(Persi
stenceManager.java:638)
  at
com.caucho.loader.EnvironmentClassLoader.config(EnvironmentClassLoader.j
ava:918)
  at
com.caucho.loader.EnvironmentClassLoader.bind(EnvironmentClassLoader.jav
a:936)
  at
com.caucho.loader.EnvironmentClassLoader.start(EnvironmentClassLoader.ja
va:963)
  at com.caucho.server.webapp.WebApp.start(WebApp.java:3508)
  at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:6
79)
  at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAut
oRedeployAutoStrategy.java:77)
  at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java
:529)
  at
com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:170)
  at
com.caucho.server.webapp.WebAppContainer.start(WebAppContainer.java:713)
  at com.caucho.server.host.Host.start(Host.java:676)
  at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:6
79)
  at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAut
oRedeployAutoStrategy.java:77)
  at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java
:529)
  at
com.caucho.env.deploy.DeployContainer.start(DeployContainer.java:170)
  at com.caucho.server.host.HostContainer.start(HostContainer.java:542)
  at com.caucho.server.cluster.Server.start(Server.java:1234)
  at
com.caucho.server.cluster.ServletSystem.start(ServletSystem.java:72)
  at
com.caucho.env.service.ResinSystem.startServices(ResinSystem.java:515)
  at com.caucho.env.service.ResinSystem.start(ResinSystem.java:483)
  at com.caucho.server.resin.Resin.start(Resin.java:1031)
  at com.caucho.server.resin.Resin.initMain(Resin.java:1167)
  at com.caucho.server.resin.Resin.main(Resin.java:1469)
[11-09-02 10:23:25.972] {main} ProResin[id=default] started in 3943ms


= The web-app can't be started at all.


-- Steffen



  On 08/19/2011 10:23 AM, BUSCH Steffen wrote:
   The next evolution of our product (see also
   
  
 http://www.caucho.com/resin/press/wmaccess-delivers-data-services-usin
   g-
   resin/) has been quite successfully tested with most recent
  Resin Pro
   4.0.x versions as long as we were using EclipseLink version 2.1.x.
  
   Before heading into the next stage we needed to upgrade to
  EclipseLink
   version 2.2 and perform various tests on different
  Application Servers.
   Tomcat 6 passed, Websphere passed, but we have troubles 
 with Resin 
   4.0.20.
   Even EclipseLink 2.2 is packaged in the WAR, Resin's own
  EclipseLink
   Version 2.1.2.v20101206-r8635 from
  $RESIN_HOME/lib/eclipselink.jar is
   used.
   Our Application uses a Constructor of EclipseLink 2.2 which
  causes the
   IllegalAccessError.
  
  Try removing/replacing the eclipselink.jar from resin/lib. 
  Resin itself doesn't depend on eclipselink, so it's safe to 
 remove or 
  replace.
  
  -- Scott
  
 
 It's very likely that we need some time to run two versions 
 of our software in parallel. Therefore I've chosen the 
 remove $RESIN_HOME/lib/eclipselink.jar option in order to 
 allow each Web-App our software to use the eclipselink 
 version included in their individual WARs.
 
 However, when the $RESIN_HOME/lib/eclipselink.jar is removed, 
 a NoClassDefFoundError is thrown. This is the output / stack trace.
 
 
 [11-08-19 19:40:10.379] {main} resin.home = 
 D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20
 [11-08-19 19:40:10.379] {main} resin.root = 
 D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20
 [11-08-19 19:40:10.379] {main} resin.conf = 
 D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20\conf\resin.xml
 [11-08-19 19:40:10.379] {main}
 [11-08-19 19:40:10.379] {main} server= 127.0.0.1:6800
 (app-tier:default)
 [11

Re: [Resin-interest] IllegalAccessError with Resin-Professional4.0.20 and EclipseLink 2.2

[BUSCH Steffen]

 On 09/02/2011 10:35 AM, BUSCH Steffen wrote:
  Hi Scott,
 
  I've seen you've filed a bug #4722 after my last email from 19th of 
  August.
  http://bugs.caucho.com/view.php?id=4722
 
  It's already closed and marked as fixed in 4.0.21 so I've downloaded
  Resin-Pro-4.0.22 and deployed the WAR file
  (http://www.wmaccess.com/public/others/testapp-EclipseLink-2.2.war) 
  with included EclipseLink 2.2 again.
 
 If you're replacing/removing the eclipselink.jar, you also 
 need to move the resin-eclipselink.jar from the resin/lib 
 into the same classloader as your eclipselink override. (Or 
 put it into the project-jars so it's automatically copied.)
 

That's doesn't seems to be working here. Now there are ClassNotFound
exceptions for
org.eclipse.persistence.platform.server.resin.ResinPlatform 
That's a step-by-step list what I did based on your recommendation:

unzip resin-pro-4.0.22.zip
cd resin-pro-4.0.22
rm lib/eclipselink.jar
mv lib/resin-eclipselink.jar project-jars/
cd webapps
wget --no-verbose
http://www.wmaccess.com/public/others/testapp-EclipseLink-2.2.war
cd ..
resin.exe


And this is the output:

[11-09-02 20:30:56.653] {main} resin.conf =
D:\WMACCESS-4.0\container-testing\resin-pro-4.0.22\conf\resin.xml
[11-09-02 20:30:56.653] {main}
[11-09-02 20:30:56.653] {main} server= 127.0.0.1:6800
(app-tier:default)
[11-09-02 20:30:56.653] {main} stage  = production
[11-09-02 20:30:56.933] {main} WebApp[production/webapp/default/ROOT]
active
[11-09-02 20:30:57.073] {main}
WebApp[production/webapp/default/resin-admin] active
[11-09-02 20:30:57.494] {main}
WebApp[production/webapp/default/resin-doc] active
[11-09-02 20:31:07.641] {main} In-place class redefinition (HotSwap) is
available.
[11-09-02 20:31:07.968] {main} javax.persistence.PersistenceException:
Exception [EclipseLink-28018] (Eclipse Persistence Services -
2.2.0.v20110202-r8913):
org.eclipse.persistence.exceptions.EntityManagerSetupException
   Exception Description: Predeployment of
PersistenceUnit [JPA_TEST] failed.
   Internal Exception: Exception
[EclipseLink-28006] (Eclipse Persistence Services -
2.2.0.v20110202-r8913):
org.eclipse.persistence.exceptions.EntityManagerSetupException
   Exception Description: ClassNotFound:
[org.eclipse.persistence.platform.server.resin.ResinPlatform] specified
in [eclipselink.target-server] property.
   Internal Exception:
java.lang.ClassNotFoundException:
org.eclipse.persistence.platform.server.resin.ResinPlatform in
EnvironmentClassLoader[web-app:production/webapp/default/testapp-Eclipse
Link-2.2,STARTING]
[11-09-02 20:31:07.968] {main} javax.persistence.PersistenceException:
Exception [EclipseLink-28018] (Eclipse Persistence Services -
2.2.0.v20110202-r8913):
org.eclipse.persistence.exceptions.EntityManagerSetupException
   Exception Description: Predeployment of
PersistenceUnit [JPA_TEST] failed.
   Internal Exception: Exception
[EclipseLink-28006] (Eclipse Persistence Services -
2.2.0.v20110202-r8913):
org.eclipse.persistence.exceptions.EntityManagerSetupException
   Exception Description: ClassNotFound:
[org.eclipse.persistence.platform.server.resin.ResinPlatform] specified
in [eclipselink.target-server] property.
   Internal Exception:
java.lang.ClassNotFoundException:
org.eclipse.persistence.platform.server.resin.ResinPlatform in
EnvironmentClassLoader[web-app:production/webapp/default/testapp-Eclipse
Link-2.2,STARTING]
context /testapp-EclipseLink-2.2: context listener entry point.
context /testapp-EclipseLink-2.2: initializing EntityManagerFactory.
context /testapp-EclipseLink-2.2: EclipseLink version packaged in .war
file: 2.2.0.v20110202-r8913
context /testapp-EclipseLink-2.2: Loaded EclipseLink version:
2.2.0.v20110202-r8913
context /testapp-EclipseLink-2.2: Using EntityManagerFactory
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl@9d2f26
context /testapp-EclipseLink-2.2: Application classloader:
EnvironmentClassLoader[web-app:production/webapp/default/testapp-Eclipse
Link-2.2]
context /testapp-EclipseLink-2.2: EntityManagerFactory classloader:
EnvironmentClassLoader[web-app:production/webapp/default/testapp-Eclipse
Link-2.2]
context /testapp-EclipseLink-2.2: Invoking EclipseLink 2.2 constructor.
context /testapp-EclipseLink-2.2: Creating EntityManager
SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
further details.
[EL Info]: 2011-09-02 20:31:08.794--ServerSession(508556)--EclipseLink,
version: Eclipse Persistence Services - 2.2.0.v20110202-r8913
[EL Info]: 2011-09-02
20:31:09.308--ServerSession(508556)--file:/D:/WMACCESS-4.0/container-tes
ting/resin-pro-4.0.22/webapps/testapp-EclipseLink-2.2/WEB-INF/classes/_J

[Resin-interest] Resin 3.1.12 change logs?

[BUSCH Steffen]

I've just seen that there is a Resin 3.1.12 available for download.
Are there any change-logs?
 
This page stops at 3.1.9 plus a snapshot:
http://caucho.com/resin-3.1/changes/changes.xtp
 
-- Steffen
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] IllegalAccessError with Resin-Professional 4.0.20 and EclipseLink 2.2

[BUSCH Steffen]

The next evolution of our product (see also
http://www.caucho.com/resin/press/wmaccess-delivers-data-services-using-
resin/) has been quite successfully tested with most recent Resin Pro
4.0.x versions as long as we were using EclipseLink version 2.1.x.

Before heading into the next stage we needed to upgrade to EclipseLink
version 2.2 and perform various tests on different Application Servers.
Tomcat 6 passed, Websphere passed, but we have troubles with Resin
4.0.20.

A collegue of mine was able to isolate the issue and produced two very
simple, basic and standalone runable WAR's to reproduce it:
http://www.wmaccess.com/public/others/testapp-EclipseLink-2.1.war (6,59
MB)
http://www.wmaccess.com/public/others/testapp-EclipseLink-2.2.war (6,96
MB)

testapp-EclipseLink-2.1.war is packaged with EclipseLink Library version
2.1.1.v20100817-r8050
testapp-EclipseLink-2.2.war is packaged with EclipseLink Library version
2.2.0.v20110202-r8913

Both WAR files are using an in-memory HSQLDB as data source, so they can
be deployed without any other prerequisites. BTW: The .java source files
are included in both WARs. The WAR uses the contextPath as prefix in its
logging statements.


As already mentioned, the WAR with EclipseLink 2.1.1.v20100817-r8050
starts up properly. 
But the WAR with EclipseLink 2.2.0.v20110202-r8913 throws an
IllegalAccessError. Please find below the Output including the complete
Stack Trace of the IllegalAccessError:


Resin Professional 4.0.20 (built Fri, 15 Jul 2011 01:17:29 PDT)
Copyright(c) 1998-2010 Caucho Technology.  All rights reserved.
 
  1013253.license -- 2 Resin servers CPB Software
 
Starting Resin Professional on Fri, 19 Aug 2011 11:37:23 +0200 (CEST)
 
[11-08-19 11:37:24.368] {main} Proxy Cache disk-size=1024M
memory-size=64M
[11-08-19 11:37:24.571] {main} 
[11-08-19 11:37:24.571] {main} Windows XP 5.1 x86
[11-08-19 11:37:24.571] {main} Java(TM) SE Runtime Environment
1.6.0_03-b05, Cp1252, de
[11-08-19 11:37:24.571] {main} Java HotSpot(TM) Client VM 1.6.0_03-b05,
32, mixed mode, Sun Microsystems Inc.
[11-08-19 11:37:24.571] {main} 
[11-08-19 11:37:24.571] {main} user.name  = stbu
[11-08-19 11:37:25.257] {main} 
[11-08-19 11:37:25.272] {main} server listening to localhost:6800
[11-08-19 11:37:25.272] {main} 
[11-08-19 11:37:25.459] {main} 
[11-08-19 11:37:25.459] {main} resin.home =
D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20
[11-08-19 11:37:25.459] {main} resin.root =
D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20
[11-08-19 11:37:25.459] {main} resin.conf =
D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20\conf\resin.xml
[11-08-19 11:37:25.459] {main} 
[11-08-19 11:37:25.459] {main} server= 127.0.0.1:6800
(app-tier:default)
[11-08-19 11:37:25.459] {main} stage  = production
[11-08-19 11:37:25.787] {main} WebApp[production/webapp/default/ROOT]
active
[11-08-19 11:37:25.911] {main}
WebApp[production/webapp/default/resin-admin] active
[11-08-19 11:37:26.254] {main}
WebApp[production/webapp/default/resin-doc] active
[11-08-19 11:37:26.270] {main} Host[production/host/default] active
[11-08-19 11:37:26.270] {main} ProServer[id=default,cluster=app-tier]
active
[11-08-19 11:37:26.270] {main}   JNI keepalive: not available on Windows
[11-08-19 11:37:26.270] {main}   JNI: file, socket
[11-08-19 11:37:26.270] {main} 
[11-08-19 11:37:26.270] {main} 
[11-08-19 11:37:26.270] {main} http listening to *:8080
[11-08-19 11:37:26.426] {main} https listening to *:8443
[11-08-19 11:37:26.426] {main} 
[11-08-19 11:37:26.457] {main} ProResin[id=default] started in 2744ms
[11-08-19 11:37:39.476] {resin-51} In-place class redefinition (HotSwap)
is available.
context /testapp-EclipseLink-2.2: context listener entry point.
context /testapp-EclipseLink-2.2: initializing EntityManagerFactory.
context /testapp-EclipseLink-2.2: EclipseLink version packaged in .war
file: 2.2.0.v20110202-r8913
context /testapp-EclipseLink-2.2: Loaded EclipseLink version:
2.1.2.v20101206-r8635
context /testapp-EclipseLink-2.2: Using EntityManagerFactory
org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl@143691d
context /testapp-EclipseLink-2.2: Application classloader:
EnvironmentClassLoader[web-app:production/webapp/default/testapp-Eclipse
Link-2.2]
context /testapp-EclipseLink-2.2: EntityManagerFactory classloader:
sun.misc.Launcher$AppClassLoader@1a7bf11
context /testapp-EclipseLink-2.2: Invoking EclipseLink 2.2 constructor.
java.lang.IllegalAccessError: tried to access method
org.eclipse.persistence.internal.jpa.metadata.tables.TableMetadata.init
(Ljava/lang/String;)V from class servlet.Listener
 at servlet.Listener.contextInitialized(Listener.java:51)
 at com.caucho.server.webapp.WebApp.start(WebApp.java:3520)
 at
com.caucho.env.deploy.DeployController.startImpl(DeployController.java:6
70)
 at
com.caucho.env.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAut
oRedeployAutoStrategy.java:77)
 at
com.caucho.env.deploy.DeployController.startOnInit(DeployController.java
:523)
 at

Re: [Resin-interest] IllegalAccessError with Resin-Professional 4.0.20 and EclipseLink 2.2

[BUSCH Steffen]

 On 08/19/2011 10:23 AM, BUSCH Steffen wrote:
  The next evolution of our product (see also
  
 http://www.caucho.com/resin/press/wmaccess-delivers-data-services-usin
  g-
  resin/) has been quite successfully tested with most recent 
 Resin Pro 
  4.0.x versions as long as we were using EclipseLink version 2.1.x.
 
  Before heading into the next stage we needed to upgrade to 
 EclipseLink 
  version 2.2 and perform various tests on different 
 Application Servers.
  Tomcat 6 passed, Websphere passed, but we have troubles with Resin 
  4.0.20.
  Even EclipseLink 2.2 is packaged in the WAR, Resin's own 
 EclipseLink 
  Version 2.1.2.v20101206-r8635 from 
 $RESIN_HOME/lib/eclipselink.jar is 
  used.
  Our Application uses a Constructor of EclipseLink 2.2 which 
 causes the 
  IllegalAccessError.
 
 Try removing/replacing the eclipselink.jar from resin/lib. 
 Resin itself doesn't depend on eclipselink, so it's safe to 
 remove or replace.
 
 -- Scott
 

It's very likely that we need some time to run two versions of our
software in parallel. Therefore I've chosen the remove
$RESIN_HOME/lib/eclipselink.jar option in order to allow each Web-App
our software to use the eclipselink version included in their individual
WARs.

However, when the $RESIN_HOME/lib/eclipselink.jar is removed, a
NoClassDefFoundError is thrown. This is the output / stack trace.


[11-08-19 19:40:10.379] {main} resin.home =
D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20
[11-08-19 19:40:10.379] {main} resin.root =
D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20
[11-08-19 19:40:10.379] {main} resin.conf =
D:\WMACCESS-4.0\container-testing\resin-pro-4.0.20\conf\resin.xml
[11-08-19 19:40:10.379] {main}
[11-08-19 19:40:10.379] {main} server= 127.0.0.1:6800
(app-tier:default)
[11-08-19 19:40:10.379] {main} stage  = production
[11-08-19 19:40:10.706] {main} WebApp[production/webapp/default/ROOT]
active
[11-08-19 19:40:10.831] {main}
WebApp[production/webapp/default/resin-admin] active
[11-08-19 19:40:11.189] {main}
WebApp[production/webapp/default/resin-doc] active
[11-08-19 19:40:11.766] {main} In-place class redefinition (HotSwap) is
available.
[11-08-19 19:40:11.968] {main}
WebApp[production/webapp/default/testapp-EclipseLink-2.2] fail
[11-08-19 19:40:11.984] {main} java.lang.NoClassDefFoundError:
org/eclipse/persistence/platform/server/ServerPlatformBase
at
java.lang.ClassLoader.defineClass1(Native Method)
at
java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at
java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at
java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at
java.security.AccessController.doPrivileged(Native Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native
Method)
at
java.lang.Class.forName(Class.java:247)
at
com.caucho.loader.DynamicClassLoader.loadClassImpl(DynamicClassLoader.ja
va:1456)
at
com.caucho.loader.SystemClassLoader.loadClassImpl(SystemClassLoader.java
:237)
at
com.caucho.loader.DynamicClassLoader.loadClassImpl(DynamicClassLoader.ja
va:1454)
at
com.caucho.loader.DynamicClassLoader.loadClassImpl(DynamicClassLoader.ja
va:1454)
at
com.caucho.loader.DynamicClassLoader.loadClassImpl(DynamicClassLoader.ja
va:1454)
at
com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1
392)
at
com.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:1
373)
at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native
Method)
at
java.lang.Class.forName(Class.java:247)
at
org.eclipse.persistence.internal.security.PrivilegedAccessHelper.getClas
sForName(PrivilegedAccessHelper.java:93)
at
org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.findClass(En
tityManagerSetupImpl.java:697

Re: [Resin-interest] web-app pointing to war files directly?

[BUSCH Steffen]

It's possible - just use the archive-path directive such as:
web-app id=/foo document-directory=/var/www/foo 
archive-path=/var/www-deploy/foo.war

Check this for further details:
http://wiki.caucho.com/Archive-path


Regards,
Steffen
 

 -Ursprüngliche Nachricht-
 Von: resin-interest-boun...@caucho.com 
 [mailto:resin-interest-boun...@caucho.com] Im Auftrag von 
 Jeff Schnitzer
 Gesendet: Donnerstag, 22. Oktober 2009 07:46
 An: General Discussion for the Resin application server
 Betreff: [Resin-interest] web-app pointing to war files directly?
 
 Is it possible to configure a host web-app to use a war 
 file somewhere on the filesystem, or is the only way by 
 defining a web-app-deploy directory and copying my war into it?
 
 Ie, is it possible to do something like web-app id=
 document-directory=my.war ?
 
 Thanks,
 Jeff
 
 
 ___
 resin-interest mailing list
 resin-interest@caucho.com
 http://maillist.caucho.com/mailman/listinfo/resin-interest
 
 



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Resin-3.1.9 - rewrite-dispatch issue with query-param condition

[BUSCH Steffen]

Solved - just for the records, query-param provides two parameters: The request 
parameter name such as to and the value (regexp) to check for:

  rewrite-dispatch
!-- Rewrite former redirect.jsp activities --
moved-permanently regexp=^/redirect.jsp 
target=/rewrite-test/option-1.jsp
  when query-param=to regexp=06/06_01_02.html/
/moved-permanently
  /rewrite-dispatch

The 4.0 syntax and its example at 
http://caucho.com/resin-javadoc/com/caucho/rewrite/IfQueryParam.html was giving 
me a better understanding than the actual 3.1 documentation without example.

Steffen 


 -Ursprüngliche Nachricht-
 Von: BUSCH Steffen 
 Gesendet: Mittwoch, 27. Mai 2009 19:15
 An: 'General Discussion for the Resin application server'
 Betreff: Resin-3.1.9 - rewrite-dispatch issue with 
 query-param condition
 
 Dear all,
 
 I have some trouble with rewrite-dispatch in resin 3.1.9 
 Professional regarding the query-param condition.
 
 Previously with resin 2.1, I was using a simple JSP page to 
 perform some kinds of redirections due to usage of frames. 
 For example the URL:
 http://host/redirect.jsp?to=06/06_01_02.html has loaded a 
 page for let's say a pricing option-1 in its main content 
 with the outer frames as well.
 
 
 Now, with resin 3.1 the structure of the web-app is changed 
 and there is a single page called option-1.jsp and I would 
 like to rewrite requests to that former redirect.jsp to the 
 new page, but I have to consider the query param for the most 
 used invocations. I thought I can achieve this with the 
 following rewrite-dispatch block inside the host tag. For 
 a simple test case, I've configured it inside a web-app 
 called /rewrite-test:
 
 
   rewrite-dispatch
 !-- Rewrite former redirect.jsp activities --
 moved-permanently regexp=^/redirect.jsp 
 target=/rewrite-test/option-1.jsp
   when query-param=to=06/06_01_02.html/
 /moved-permanently
   /rewrite-dispatch
 
 So I thought that a request to 
 http://host/rewrite-test/redirect.jsp?to=06/06_01_02.html 
 should be moved with 301 to 
 http://host/rewrite-test/option-1.jsp due to the exact match 
 of the when query-param=... condition. But it does not 
 work, so I've enabled 'finest' debug using
 
   !-- Debug Logging   --
   log level=finest path=WEB-INF/debug_${webApp.name}.log
timestamp=[%H:%M:%S.%s] {%{thread}} 
format=[${app.contextPath}] ${log.level} 
 ${log.sourceClassName} (${log.sourceMethodName}) ${log.message}
 logger name=com.caucho.server.rewrite level=finest/
 logger name=com.caucho.server.connection.Form level=finest/
   /log
 
 and got this output:
 
 [18:49:27.309] {http--8080-1$11773344} [/rewrite-test] INFO 
 com.caucho.jsp.TldManager (initGlobal) Loading .tld files 
 from global classpath [18:49:34.681] {http--8080-1$11773344} 
 [/rewrite-test] FINEST 
 com.caucho.server.rewrite.RewriteDispatch (map) 
 rewrite-dispatch check uri '/redirect.jsp'
 [18:49:34.681] {http--8080-1$11773344} [/rewrite-test] FINER 
 com.caucho.server.rewrite.AbstractRuleWithConditions (map) 
 match .* '/redirect.jsp' -- '/redirect.jsp'
 [18:49:34.681] {http--8080-1$11773344} [/rewrite-test] FINE 
 com.caucho.server.connection.Form (parseQueryString) query: 
 to=06/06_01_02.html [18:49:34.681] {http--8080-1$11773344} 
 [/rewrite-test] FINER 
 com.caucho.server.rewrite.ConditionFilterChain (doFilter) 
 null ^/redirect.jsp '/redirect.jsp' -- '/rewrite-test/option-1.jsp'
 
 
 
 and that's what has been tracked by Firefox Live HTTP headers:
 
 GET /rewrite-test/redirect.jsp?to=06/06_01_02.html HTTP/1.1
 Host: localhost:8080
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; 
 rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
 Accept: 
 text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: de-de,en-us;q=0.7,en;q=0.3
 Accept-Encoding: gzip,deflate
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Keep-Alive: 300
 Connection: keep-alive
 
 HTTP/1.x 200 OK
 Server: Resin/3.1.9
 Content-Type: text/html
 Transfer-Encoding: chunked
 Date: Wed, 27 May 2009 17:07:02 GMT
 --
 
 
 
 
 Am I doing something wrong here? For me it looks like the 
 query-param condition is not working in this case.
 Thanks for any kind of hints or ideas.
 
 
 Steffen



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin-3.1.9 - rewrite-dispatch issue with query-param condition

[BUSCH Steffen]

Dear all,

I have some trouble with rewrite-dispatch in resin 3.1.9 Professional
regarding the query-param condition.

Previously with resin 2.1, I was using a simple JSP page to perform some
kinds of redirections due to usage of frames. For example the URL:
http://host/redirect.jsp?to=06/06_01_02.html has loaded a page for let's
say a pricing option-1 in its main content with the outer frames as
well.


Now, with resin 3.1 the structure of the web-app is changed and there is
a single page called option-1.jsp and I would like to rewrite requests
to that former redirect.jsp to the new page, but I have to consider
the query param for the most used invocations. I thought I can achieve
this with the following rewrite-dispatch block inside the host tag.
For a simple test case, I've configured it inside a web-app called
/rewrite-test:


  rewrite-dispatch
!-- Rewrite former redirect.jsp activities --
moved-permanently regexp=^/redirect.jsp
target=/rewrite-test/option-1.jsp
  when query-param=to=06/06_01_02.html/
/moved-permanently
  /rewrite-dispatch

So I thought that a request to
http://host/rewrite-test/redirect.jsp?to=06/06_01_02.html should be
moved with 301 to http://host/rewrite-test/option-1.jsp due to the exact
match of the when query-param=... condition. But it does not work,
so I've enabled 'finest' debug using

  !-- Debug Logging   --
  log level=finest path=WEB-INF/debug_${webApp.name}.log
   timestamp=[%H:%M:%S.%s] {%{thread}} 
   format=[${app.contextPath}] ${log.level} ${log.sourceClassName}
(${log.sourceMethodName}) ${log.message}
logger name=com.caucho.server.rewrite level=finest/
logger name=com.caucho.server.connection.Form level=finest/
  /log

and got this output:

[18:49:27.309] {http--8080-1$11773344} [/rewrite-test] INFO
com.caucho.jsp.TldManager (initGlobal) Loading .tld files from global
classpath
[18:49:34.681] {http--8080-1$11773344} [/rewrite-test] FINEST
com.caucho.server.rewrite.RewriteDispatch (map) rewrite-dispatch check
uri '/redirect.jsp'
[18:49:34.681] {http--8080-1$11773344} [/rewrite-test] FINER
com.caucho.server.rewrite.AbstractRuleWithConditions (map) match .*
'/redirect.jsp' -- '/redirect.jsp'
[18:49:34.681] {http--8080-1$11773344} [/rewrite-test] FINE
com.caucho.server.connection.Form (parseQueryString) query:
to=06/06_01_02.html
[18:49:34.681] {http--8080-1$11773344} [/rewrite-test] FINER
com.caucho.server.rewrite.ConditionFilterChain (doFilter) null
^/redirect.jsp '/redirect.jsp' -- '/rewrite-test/option-1.jsp'



and that's what has been tracked by Firefox Live HTTP headers:

GET /rewrite-test/redirect.jsp?to=06/06_01_02.html HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10)
Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 200 OK
Server: Resin/3.1.9
Content-Type: text/html
Transfer-Encoding: chunked
Date: Wed, 27 May 2009 17:07:02 GMT
--




Am I doing something wrong here? For me it looks like the query-param
condition is not working in this case.
Thanks for any kind of hints or ideas.


Steffen



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Different MD5-base64 digest passwords Resin 2.1 vs. Resin 3.1 with realm of none

[BUSCH Steffen]

Hi all,
 
I have a small Issue while trying to prepare the upgrade from Resin
2.1.14 to Resin 3.1 Snapshot as of 19th December with the Digest
Password in Resin XmlAuthenticator.
 
 
I used to have the following configuration in Resin 2.1.14
 
authenticator
  class-namecom.caucho.http.security.XmlAuthenticator/class-name
  init-param password-digest='MD5-base64'/
  init-param path='/home/stbu/passwords.xml' /
/authenticator

 
The passwords in the referenced file passwords.xml are for example like
this:
 
authenticator
  user name='myuser' password='cXSMXbxTmOz7Hv4lcVvrC3' role='resin' /
/authenticator

 
In 3.1 I have configured it as follows:
 
authenticator type=com.caucho.server.security.XmlAuthenticator
  init
password-digestMD5-base64/password-digest
password-digest-realmnone/password-digest-realm
path/home/stbu/passwords.xml/path
  /init
/authenticator
 
= I knew that the default realm is resin, so I've set it explicitly
to none so that I could reuse my old passwords.
But trying to login with the Username and Passwords are now rejected. 
 
 
The password used for 2.1.14 have been generated with this utility
class:
 
CODE
package com.example;
 
import com.caucho.http.security.PasswordDigest;
import javax.servlet.*;
 
public class Digest {
public static void main(String args[]) throws ServletException {
PasswordDigest digest = new PasswordDigest();
digest.setAlgorithm(MD5);
digest.setFormat(base64);
 
System.out.println(Preparing Password ' + args[1] + '
for User ' + args[0] + ');
String password = digest.getPasswordDigest(args[0],
args[1]);
System.out.println(Digest Password: ' +password +
');
}
 }
/CODE

java com.example.Digest myuser mypassword
Preparing Password 'mypassword' for User 'myuser'
Digest Password: 'cXSMXbxTmOz7Hv4lcVvrC3'

 
In order to investigate why the login is rejected, I extended the
utility class to allow the specification of the realm and used the 3.1
Jars of Resin to generate the password for a user and compare them
 
CODE
package com.example;
 
import com.caucho.http.security.PasswordDigest;
import javax.servlet.*;
 
public class Digest31 {
public static void main(String args[]) throws ServletException {
PasswordDigest digest = new PasswordDigest();
digest.setAlgorithm(MD5);
digest.setFormat(base64);
digest.setRealm(args[2]);
 
System.out.println(Preparing Password ' + args[1] + '
for User ' + args[0] + ' +  with realm ' + args[2] + ');
String password = digest.getPasswordDigest(args[0],
args[1]);
System.out.println(Digest Password: ' +password +
');
}
 }
/CODE

java com.example.Digest31 myuser mypassword none
Preparing Password 'mypassword' for User 'myuser' with realm 'none'
Digest Password: 'cXSMXbxTmOz7Hv4lcVvrtw=='

BTW: The same result is achieved when using the Calculate Digest on
the Login Page of /resin-admin.
 
 
The passwords look similar, but they are actually not the same - so the
rejection is clear. 
2.1: 'cXSMXbxTmOz7Hv4lcVvrC3'
3.1: 'cXSMXbxTmOz7Hv4lcVvrtw=='
 
 
 
Has anybody else got such problems and figured out how to solve it? 
I don't know how I have to set the init values for the XmlAuthenticator
in order to get the old passwords working. 
 
 
Thanks in advance
Steffen
 



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] override global classpath with webapp classpath

[BUSCH Steffen]

I think you're looking for the servlet-hack 
 http://caucho.com/resin/doc/env-tags.xtp#servlet-hack 
which should not be used in general! I would prefer any other solution, such as 
duplicating your 'common' but older oracle driver jar into the WEB-INF/lib of 
the other web-apps ...


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jason 
Deffenbaugh
Gesendet: Mittwoch, 8. Oktober 2008 19:20
An: resin-interest@caucho.com
Betreff: [Resin-interest] override global classpath with webapp classpath

We're configuring resin to connect to a db using an oracle db driver.
The driver jar is in ${server.root}/lib.  The problem is that for one webapp I 
need to change the version of the oracle driver so I put the new driver jar in 
WEB-INF/lib in the webapp.  Resin appears to be ignoring the local version of 
the driver class in favor of the global one.

Is there a way to configure resin to load the webapp local classpath first 
instead of the global one?

Thanks,

-Jason



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

[Resin-interest] Resin-Pro 3.1.7a and UnsatisfiedLinkError: nativeTruncate

[BUSCH Steffen]

Hi,
 
we are running Resin-Pro 3.1.7a on a Sun Solaris 10 Box with
successfully compiled JNI Code, but since upgrading from 3.1.6 our log
files are growing with Exceptions like this:
 
== debug.log ==
[2008.09.15 18:28:18.328]  [WebApp: ] WARNING
(com.caucho.util.ThreadPool) java.lang.UnsatisfiedLinkError:
nativeTruncate
[2008.09.15 18:28:18.328]   at
com.caucho.vfs.JniFilePathImpl.nativeTruncate(Native Method)
[2008.09.15 18:28:18.328]   at
com.caucho.vfs.JniFilePathImpl.truncate(JniFilePathImpl.java:363)
[2008.09.15 18:28:18.328]   at
com.caucho.vfs.Path.truncate(Path.java:940)
[2008.09.15 18:28:18.328]   at
com.caucho.log.AbstractRolloverLog.movePathToArchive(AbstractRolloverLog
.java:584)
[2008.09.15 18:28:18.328]   at
com.caucho.log.AbstractRolloverLog.access$100(AbstractRolloverLog.java:5
9)
[2008.09.15 18:28:18.328]   at
com.caucho.log.AbstractRolloverLog$ArchiveTask.run(AbstractRolloverLog.j
ava:827)
[2008.09.15 18:28:18.328]   at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
[2008.09.15 18:28:18.328]   at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
[2008.09.15 18:28:18.328]   at java.lang.Thread.run(Thread.java:595)
[2008.09.15 18:28:18.328] 
 
== jvm-trunk.log ==
[18:28:18.332] {resin-23} java.lang.UnsatisfiedLinkError: nativeTruncate
[18:28:18.332] {resin-23}   at
com.caucho.vfs.JniFilePathImpl.nativeTruncate(Native Method)
[18:28:18.332] {resin-23}   at
com.caucho.vfs.JniFilePathImpl.truncate(JniFilePathImpl.java:363)
[18:28:18.332] {resin-23}   at
com.caucho.vfs.Path.truncate(Path.java:940)
[18:28:18.332] {resin-23}   at
com.caucho.log.AbstractRolloverLog.movePathToArchive(AbstractRolloverLog
.java:584)
[18:28:18.332] {resin-23}   at
com.caucho.log.AbstractRolloverLog.access$100(AbstractRolloverLog.java:5
9)
[18:28:18.332] {resin-23}   at
com.caucho.log.AbstractRolloverLog$ArchiveTask.run(AbstractRolloverLog.j
ava:827)
[18:28:18.332] {resin-23}   at
com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
[18:28:18.332] {resin-23}   at
com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
[18:28:18.332] {resin-23}   at java.lang.Thread.run(Thread.java:595)
 
Our Environment is:
Resin-3.1.7a (built Thu, 04 Sep 2008 07:14:11 PDT)
Copyright(c) 1998-2008 Caucho Technology.  All rights reserved.
...
Starting Resin on Mon, 15 Sep 2008 18:33:50 +0200 (CEST)
 
[18:33:57.194] {main} Proxy Cache disk-size=1024M memory-size=64M
[18:33:57.311] {main} PingThread[] starting, checking []
[18:33:58.044] {main}
[18:33:58.066] {main} SunOS 5.10 sparcv9
[18:33:58.068] {main} Java(TM) 2 Runtime Environment, Standard Edition
1.5.0_09-b03, UTF-8, en
[18:33:58.070] {main} Java HotSpot(TM) 64-Bit Server VM 1.5.0_09-b03,
64, mixed mode, Sun Microsystems Inc.
...
[18:35:06.238] {main} Host[] active
[18:35:06.367] {main} WebApp[http://admin.caucho/resin-jmx-service]
active
[18:35:06.369] {main} Host[admin.caucho] active
[18:35:06.388] {main} Loaded Socket JNI library.
[18:35:06.401] {main} hmux listening to localhost:6800
[18:35:06.427] {main} http listening to *:8755
[18:35:06.778] {main} https listening to *:8756
[18:35:06.784] {main} Server[id=trunk,cluster=app-tier] active
[18:35:06.792] {main} Resin started in 76842ms
[18:36:00.010] {resin-pro-statistics} StatService[] cpu-load=1.53125


Does anybody know if this is a known Resin Bug or if something in the
environment is wrong?
 
 
Regards,
Steffen
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] FYI: 3.2.0 schedule

[BUSCH Steffen]

Scott,

the last snapshot for Resin 3.1 is from 11th of june 2008 at least on the 
download page. 
Based on your roadmap, the 3.1.7 release is scheduled for the next 3 to 4 
weeks. 

Would you mind to provide a new 3.1-snapshot in order to perform already some 
alpha tests to have enough time to report critical issues?

Regards,
Steffen


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Scott Ferguson
Gesendet: Mittwoch, 9. Juli 2008 19:13
An: General Discussion for the Resin application server
Betreff: [Resin-interest] FYI: 3.2.0 schedule

We're currently at week 8 of our planned 8 week schedule, but regression fixes 
and load testing will take about another 2 weeks before the 3.2.0 release.  The 
3.1.7 release would follow by a week or two.

There's been a number of significant changes to low-level infrastructure in 
3.2.0 which means we'll need to take extra testing care before the release.

The main changes are:

1. major rework of the socket and threading code to support comet and bam
   1a. this has also enabled extra JMX data for connection monitoring.
2. major rework of the distributed sessions for handle dynamic sessions (and 
improve reliability) 3. replace internal cluster hessian communication with bam 
for distributed jmx 4. enabling of dynamic servers, i.e. adding servers without 
modifying the configuration files 5. basic infrastructure for remote .war 
deployment, using a vcs (git) for a reliability store 6. reworking of the 
distribution, e.g. merging all the api jars into a javaee-16.jar to make 
embedding easier

So, it will take some more time than usual to get the final release out.

-- Scott


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] Ant and JSPCompiler

[BUSCH Steffen]

I think the Resin 3.0 JspCompiler needs the JSP files as arguments. We have 
accomplished that in this way:


!-- Definition of JSP files that should be precompiled to servlets --
fileset dir=${build.dir} id=jsp.precompile.fileset
  include name=**/*.jsp/
/fileset

!-- Convert fileset to single property, separated by space --
pathconvert pathsep= 
 property=jsp.precompile.files
 refid=jsp.precompile.fileset
/pathconvert


echoBatch Precompile of JSP Files/echo
java classname=com.caucho.jsp.JspCompiler
  classpathref=resin.jspc.classpath fork=true failonerror=true
  sysproperty key=java.util.logging.config.file 
value=${jsp.logging.properties}/
  arg value=-app-dir/
  arg value=${build.dir}/
  arg line=${jsp.precompile.files}/
/java


Please note, that this might fail on Windows Platform as there is a limitation 
of the argument length. But it works on our Unix Platform.


Regards,
Steffen



-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von rafael.munoz
Gesendet: Montag, 5. Mai 2008 15:17
An: resin-interest@caucho.com
Betreff: [Resin-interest] Ant and JSPCompiler


Hi

I'm trying to precompile my JSPs before the deploy phase, integrating this 
precompilation in my ANT build script.

I'm using Resin 3.0.19 so I can't use the new resin-ant.jar but I think that 
this ANT target should work:

target name=precompile-jsp description=precompile jsp
   echo message=precompiling JSPs: app-dir=${home.war}/
   java classname=com.caucho.jsp.JspCompiler fork=true 
  classpath refid=resin.classpath /
  arg line=-app-dir ${home.war} /
   /java
/target

But unfortunately it doesn't work: this generate the work and tmp directory but 
they're empty.

I have try passing a JSP and the JSP is precompiled without problem:
target name=precompile-jsp description=precompile jsp
   echo message=precompiling JSPs: app-dir=${home.war}/
   java classname=com.caucho.jsp.JspCompiler fork=true 
  classpath refid=resin.classpath /
  arg line=-app-dir ${home.war} /
  arg line=${home.war}/index.jsp /
   /java
/target

So my question is: have I to pass ALL my JSPs to JSPCompiler? Can't I just 
point to the root of my web app and just have all my JSP precompiled?
--
View this message in context: 
http://www.nabble.com/Ant-and-JSPCompiler-tp17061443p17061443.html
Sent from the Resin mailing list archive at Nabble.com.



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest




___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Re: [Resin-interest] R: [Fwd: httpd.sh stop]

[Busch, Steffen]

There is also a configuration directive, how long resin will wait for
requests to finish:
 http://www.caucho.com/resin-3.0/config/webapp.xtp#shutdown-wait-max
http://www.caucho.com/resin-3.0/config/webapp.xtp#shutdown-wait-max 
 

-Ursprüngliche Nachricht-
Von: Andrea Sodomaco [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 21. April 2007 11:03
An: 'General Discussion for the Resin application server'
Betreff: [Resin-interest] R: [Fwd: httpd.sh stop]


The answer is no.
 
I simply did a test. 
The following jsp does not complete the request if resin is stoped.


beginbr

% Thread.sleep(60L*1000L); %

end



 

Andrea Sodomaco

 

Andrea Sodomaco Consulenze Informatiche

Via Giacometti, 4 - 34146 TRIESTE

Tel.: 040 281648 / 338 3565702 - Fax: 040 46069349

www.sodomaco.it http://www.sodomaco.it/ 

 



 Original Message  
Subject:[Resin-interest] httpd.sh stop  
Date:   Thu, 19 Apr 2007 00:40:16 -0500 
From:   Martin Crundall  mailto:[EMAIL PROTECTED]
[EMAIL PROTECTED] 
Reply-To:   General Discussion for the Resin application server
mailto:resin-interest@caucho.com resin-interest@caucho.com  
To: General Discussion for the Resin application server
mailto:resin-interest@caucho.com resin-interest@caucho.com  


when httpd.sh stop is executed (resin 3.0.19) does resin finish dealing

with all pending requests before shutting down?



thanks,



martin







___

resin-interest mailing list

resin-interest@caucho.com mailto:resin-interest@caucho.com 

http://maillist.caucho.com/mailman/listinfo/resin-interest
http://maillist.caucho.com/mailman/listinfo/resin-interest 





___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest